Если вы фрилансер и работаете над несколькими заказами, или когда есть несколько несвязанных направлений, например, работа, обучение и семья, то сгруппировать задачи по проектам кажется очень просто: каждому направлению свой проект. А что делать, когда вы работаете над сложным продуктом, включающим разные направления: разработка, поддержка, реклама, соцсети, исследования?
Каким образом, сгруппировать задачи в проекты, чтобы получить наглядное представление по каждому направлению? Выделить каждое направление в отдельный проект - тогда общая картина будет размазываться и сложно будет отследить общий прогресс. Сформировать единый проект для продукта - не увидишь деталей и не отследишь, если какое-то направление проседает. Расскажу как это делаю я на примере планирования WinGo Plan.
Принцип группировки задач и выделения проектов
Для себя я решила проблему следующим образом: я формирую проекты по направлениям с учетом людей, на которых они завязаны, например, для WinGo Plan у меня созданы проекты:
- WinGo Mobile - road map (план разработки) iOS и Android версий. Функциональность под iOS и Android в основном совпадает, поэтому они объединены в один проект.
- WinGo Web - веб-версия в конце прошлого года отставала по функциональности, нужно было нагонять, мы внедряли большое количество изменений, поэтому WinGo Plan Web выделен в отдельный проект.
- My WinGo Plan - проект, в котором я веду задачи, несвязанные с разработкой: продвижение, custdev (общение с пользователями), общение с партнерами и возможными инвесторами. Эти задачи завязаны на мне, поэтому и проект один.
- WinGo Plan promo site - часть сайта, где размещается описание планировщика, преимущества. Но это отдельный большой пласт работы, поэтому выделен в отдельный проект.
Есть и другие проекты, связанные, например, с бизнес-задачами, заказной разработкой или с подготовкой квартиры для сдачи в аренду. И еще, как правило, у меня есть отдельный проект для текущих задач, о нем расскажу в другой раз.
Детальное планирование проекта - roadmap
Я выделила основные направления, сформировала под них проекты. А затем начинаю планировать каждый проект.
В проекте WinGo Mobile каждый этап кроме последнего - это версия приложения. Выглядит это так:
- WinGo iOS 5.0 - упрощение создания проекта, изменения интерфейсов,
- WinGo Plan iOS 5.1 - мастер создания проектов и подсказки,
- WinGo Plan 5.3 - цели и onboarding, раздел Актуальное,
- WinGo Plan Android 5.0, WinGo Plan Android 5.1, WinGo Plan Android 5.2 - по порядку выхода версий,
- Идеи на будущее.
В названии этапа - номер версии и основные доработки, которые в нее войдут. У ближайших этапов есть конкретные даты - время, когда обновление должно быть отправлено в App Store или Google Play. По мере продвижения вперед даты появляются у последующих этапов.
Последний этап почти в каждом проекте я выделяю для идей, мыслей и задач на будущее. Туда очень удобно скидывать идеи, задачи, пока не включенные ни в один из этапов. А если в голове пока нет четкой структуры проекта, то часто именно с него я и начинаю. Собираю идеи, валидирую, а потом распределяю задачи по этапам.
В итоге получается roadmap - наглядное представление для меня и команды, в котором видно что, как и когда мы разрабатываем. Куда мы движемся и с какой скоростью.
Детальное планирование проекта для разработки новой версии
Roadmap показывает картину в целом, а процесса разработки, для команды я обычно:
- формирую аналогичный проект с этапами по версиям или
- выделяю каждую в отдельный проект.
Проект разработки с этапами по версиям
Единый проект для разработки, аналогичный проекту-roadmap, удобен когда в комнате используются отдельные системы, например, для баг-трекинга (отслеживания исправления ошибок), чек-листы для тестирования также ведутся в отдельном документе, а мне как руководителю нужно видеть картину целиком и понимать где мы сейчас находимся, успеваем или есть затык.
В этом случае задачи каждого этапа (версии) в основном повторяются:
- Разработка;
- Оценка корректности (перед тем, как версия попадет к тестировщику, я обычно сама ее просматриваю и оцениваю: все ли реализовали как было задумано, все ли на месте и удобно);
- Исправление замечаний;
- Тестирование;
- Исправление ошибок;
- Повторное тестирование;
- Подготовка материалов для публикации;
- Отправка на публикацию;
- Публикация.
Иногда появляются дополнительные задачи, например повторная исправление багов и третья итерация тестирования, подготовка контента и т.п. После успешной публикации в App Store или Google Play этап закрывается и мы переходим к следующему.
Для каждой версии свой проект
Если в команде не используются другие системы, то удобнее выделять каждую версию в отдельный проект. Тогда задачи из предыдущего примера становятся этапами.
- Разработка - с перечислением доработок функциональности (этап просто копируется из проекта roadmap);
- Тестирование - сюда в качестве задач можно добавить чек-листы, но их все-таки лучше вести отдельно;
- Исправление багов - задачи - это обнаруженные баги;
- Повторное тестирование;
- Подготовка материалов (“Что нового”, текстов, скриншотов и т.п.), необходимых для публикации обновления;
- Отправка на публикацию.
После того, как версия прошла рассмотрение и опубликована в сторе, проект завершается и создается новый - для новой версии.
Как видите, даже в одной и той же ситуации - планирование разработки новой функциональности WinGo Plan - проекты можно сформировать совершенно по-разному. Все зависит конкретной ситуации: размера команды, использования других систем, частоты выпуска версий и того, как и что вам нужно отслеживать.
У многих есть собственный удачный или удачный опыт систематизации задач. Поделитесь вашим опытом, напишите через форму обратной связи или в комментариях в LinkedIn