Способность качественно оценивать временные затраты на разработку — один из ключевых навыков хорошего управляющего процессом разработки. Ошибочные прогнозы сроков завершения задач, как свидетельствует мой личный опыт, является одним из если не основных источников боли для руководителей, то весьма масштабным.
Практики, позволяющие не полагаться в этом вопросе на удачу и попытки угадать время, требуемое для реализации той или иной идеи в коде просты и доступны всем. Планирование — это вполне себе обычная работа, и для ее выполнения требуются вполне определенные действия.
Сформулировать описания функциональности
Основа хорошего планирования, хорошо сформулированное описание функциональности, которое необходимо реализовать. Лучший на мой взгляд способ — это достаточно давно придуманный формат пользовательских историй или шаблонов поведения (use cases):
Как пользователь, я хочу оплатить заказ пластиковой картой
Чем хороша такая формулировка? Ясностью. Хороший управляющий сознательно ограничивает объем информации доступный участникам для обсуждения. Чем меньше информации, тем меньше вероятность совершения ошибки.
Что у нас здесь есть? Во-первых, однозначно указан потребитель реализуемого функционала — зарегистрированный пользователь, ранее уже разместивший заказ. Во-вторых, требуемый функционал достаточно четко ограничен в объеме используемых данных и во времени. В третьих, выполняемое потребителем действие атомарно. Последний момент очень важен. Последовательности или не дай бог нелинейные последовательности действий указываемые в описании функциональности — это дорога прямиком в ад. Причем для всех участников процесса.
Субъективно я для себя вывел что идеальными представляются формулировки, подразумевающие что потребитель делает нечто, что не требует больше минуты или пары минут времени для осведомленного пользователя. Осведомленным пользователем в данном случае считаем такого пользователя, который выполняет означенное действие в первый раз именно в нашем приложении, но ранее уже выполнял похожие действия возможно какими-нибудь другими способами или в других приложениях.
Определить списки задач
Что дальше? Дальше необходимо каждое из описаний функциональности разбить на задачи. Делать это необходимо вместе с разработчиком, который предположительно будет выбранную функциональность реализовывать. Что включать в список задач? Если разработчик видит задачу впервые и ранее не касался ее, то буквально все действия, которые предположительно могут потребоваться, включая исследовательские и коллаборационные:
- Изучить документацию по интеграции с платежным шлюзом, касающуюся части платежей пластиковыми картами
- Согласовать со специалистами платежного шлюза выбранный способ подключения и осуществления платежей
- Согласовать с руководителем проекта выбранный способ подключения и осуществления платежей
- Реализовать хранение и извлечение данных, необходимых для взаимодействия с платежным шлюзом (идентификаторы клиента, ключи безопасности)
- Реализовать получение и подготовку данных о заказе, который будет оплачен
- Разработать (подключить предоставленную платежным шлюзом) форму для ввода данных пластиковой карты пользователем
- Реализовать передачу данных о заказе и его стоимости в форму оплаты
- Реализовать получение, обработку и сохранение данных об успешном выполнении платежа
- Реализовать обработку ошибок, произошедших в ходе выполнения оплаты
- Реализовать отображение пользователю квитанции о выполнении оплаты
- Реализовать отображение пользователю сообщения об ошибках, произошедших в ходе выполнения оплаты
Чем более подробный список, тем ближе к реальности будет оценка времени на разработку. После того, как список готов, попросите разработчика поставить оценку в конце описания каждого из пунктов в рабочих часах. Просуммируйте часы и предполагайте что на получившееся время можно примерно ориентироваться. Почему я говорю примерно? Потому что планы, никогда не выдерживают встречи с реальностью. Запланировать все невозможно, и неожиданности почти всегда всплывают в ходе работы. И чем подробнее будет ваш список задач, тем меньше неожиданностей может произойти, и тем меньше дополнительного времени потребуется для того, чтобы разобраться с этими неожиданностями.
По мере выполнения пунктов в списке задач, попросите разработчика указывать фактически затраченное на задачу время, таким образом у вас появится возможность оценить качество вашего планирования.
Инструменты
Я не сторонник дорогих или не очень понятных инструментов планирования, с покером, диаграммами сгорания и story point-ами. Я считаю в управлении следует полагаться на здравый смысл и принцип сохранения простоты.
Для успешной визуализации управления процессом разработки достаточно тривиальных средств, таких как Трелло или доски проектов Github. И там и там описания функциональности можно оформить в виде карточек в списках, и к каждой из карточек можно прикрепить список задач с указанием прогноза по времени выполнения просто в виде числа через тире в конце описания:
Как пользователь, я хочу оплатить заказ пластиковой картой — 30ч
Ничто не мешает руководителю проекта при этом добавить к описанию еще и уже фактически затраченное время. Это можно делать каждый вечер, в конце рабочего дня:
Как пользователь, я хочу оплатить заказ пластиковой картой — 30ч — 15ч
Отставание от графика при этом можно выявлять на достаточно ранних этапах работы, обсуждать с разработчиком складывающуюся ситуацию и предпринимать корректирующие действия и как миниум оповещать заказчика о возможном отставании и его причинах, которые весьма часто бывают вполне себе объективными.
