Вплоть до прошлого года один из способов, которым я определял этапы, в значительной степени основывался на том, как я или моя команда и я должны работать над проектом.
Однако с этим подходом есть проблема: для тех из нас, кто пытается включить отзывы клиентов в процесс разработки, им не так просто взять жаргон, который мы используем, и при этом заставить их понять его.
С этой целью я начал немного по-другому оценивать вехи проекта WordPress, чтобы они были немного более удобными для клиентов, но при этом по-прежнему понимали, как команда разработчиков может выполнить то, что необходимо для обеспечения функциональности.
Вехи проекта WordPress
Подумайте на мгновение о том, когда вы в последний раз отвечали за создание пользовательского плагина или интеграцию пользовательской функциональности в проект WordPress. Возможно, он включал что-то вроде:
- Импорт данных в базу данных WordPress,
- Сделайте информацию доступной для просмотра и редактирования из области администрирования WordPress,
- Отображать информацию в интерфейсе таким образом, чтобы ее можно было отсортировать, например, по значениям столбцов,
- Данные можно обновлять с помощью другого импорта или управлять из области администрирования,
- И, возможно, некоторые другие сопутствующие функции.
Если вы хотите разбить это на язык разработчиков, вы будете много говорить об определенных вещах, касающихся импорта, анализа данных, целостности данных и так далее. И все это на 100% правильно, и все так и должно быть с точки зрения разработчика.
Но если вы используете программное обеспечение для управления проектами (которое мы недавно остановили на Asana ), эти типы вех не помогут, когда вы привлекаете пользователей в проект.
- Как они должны знать что-либо о деталях процесса импорта?
- Как они должны понимать технические особенности создания чего-то сортируемого?
- Есть ли способ легко описать им алгоритм, который даже имеет значение?
Я бы сказал нет. Итак, как мы можем сделать вехи проекта WordPress более доступными? Я не знаю, является ли мой ответ надежным ответом, но это то, что мы пробовали, и это, кажется, работает относительно хорошо, но это просто:
- Клиенты часто думают о своих проектах в отношении страниц (или чего-то связанного),
- Поскольку мы, как разработчики, можем работать в этом контексте, мы можем определить общедоступный проект, чтобы разбить задачи на постраничную основу.
Таким образом, вехи проекта WordPress становятся больше задачами для каждой страницы, а оставшиеся задачи — более «общей» вехой.
Несколько слов о технических аспектах
Все упомянутое выше работает хорошо, когда вы вовлекаете клиента в определенные части проекта, но все равно остается вопрос: «Что нам делать с более техническими аспектами?»
И при этом это может быть что угодно, от того, как вы собираетесь организовать свои интерфейсы, классы, методы и так далее, до того, как вы собираетесь реализовать определенный алгоритм. В любом случае, дело в том, что необходимо провести более глубокое техническое обсуждение. Итак, что мы делаем с ними, когда обсуждаем вехи проекта WordPress?
Есть несколько вариантов:
- Настройте отдельную веху, группу задач, проектов, обсуждение, все, что позволяет ваша система, и оставьте это между вами и вашей командой.
- Используйте проблемы GitHub, проекты GitHub, вики, Trello или другую систему,
- Храните информацию в другом приложении, доступном для всех разработчиков, но изолированном от клиента.
Конечно, это создает немного больше накладных расходов, но я обнаружил, что чем больше информации вы распространите по частям своего проекта, тем успешнее может быть проект.
Когда информация упускается, разбросана, не используется или не детализируется, становится все труднее управлять ею по мере продвижения проекта, особенно во время будущих итераций.
Суть в том, что я считаю важным разбить вехи проекта WordPress на части, чтобы заказчику было легко понять, какая работа выполняется, и чтобы у вас и вашей команды был способ управлять тем, что делается.
Как вы это сделаете, очевидно, зависит от вас, но я считаю, что это стоит того, чтобы потратить время на настройку.