​​🤯 Ошибки при планировании сроков

Менеджеру присылают ТЗ клиента на оценку. На основе этой оценки оформят договор и будут разрабатывать продукт. Менеджер собирает встречу с разработчиком, чтобы оценить проект, готовит большую excel табличку, диаграмму Гантта. В табличке указаны грубые оценки на реализацию фичей, инфраструктуры. Посчитано время тестировщиков и менеджеров в процентах от оценки разработки, заложены риски.

Контракт подписан. Разработка идет, проходит месяц, два, и становится очевидно, что проект не сдадут вовремя. За счет заложенных рисков и наценки в рейте, в минус не уйдем, но и особо не заработаем. Почему так произошло? Ведь заложили риски, учли инициализацию, требования написаны, где мы ошиблись?

👉 В работе над ошибками планирования, стоит обратить внимание на то КАК мы считаем время разработчика и размазываем это время по календарю.

👉 Кто-то считает, что разработчик может в неделю делать 30 часов, кто-то больше, кто-то меньше. Если вы прикидываете это время на глаз, то обратитесь к реальной картине и проанализируйте как расходуется время разработки сейчас.

Что необходимо заложить?
Вот список того, из чего может состоять спринт, на примере 1-го разработчика.

Не производственные затраты:

👩‍💻Scrum: daily standup, планирование, демо, ретро, грумминг/backlog refinement - 5 часов.
👩‍💻Тет-а-тет встречи с руководителем - 1 час.
👩‍💻Код ревью - 2 часа.
👩‍💻Непредвиденные встречи, общение, фокус-фактор - 3 часа.

Производственные затраты:

👨‍💻Баги - 2 часа.
👨‍💻Решение обращений пользователей в техподдержку - 1 час.
👨‍💻Техдолг - 2 часа.
👨‍💻Продуктовые задачи - 16 часов.
👨‍💻Мелкие хотелки (замените логотип, сделайте выгрузку, добавьте ссылку) - 2 часа.
👨‍💻Технические проекты (вещи, которые не нужны пользователю, но нужны разработке, чтобы проект комфортно жил - настройка мониторинга, масштабируемость) - 4 часа.

👩‍💻Бонус: Непопадание в оценки. У нас есть метрика, которая показывает насколько мы попадаем в оценки, из нее вытекает погрешность для планирования, у каждой команды она своя - 3 часа.

👉 Определите, какие пункты для вас актуальны и впишите свои данные в гугл табличке, чтобы лучше понимать capacity своей команды для верхнеуровнего планирования.

Еще эта табличка поможет найти узкие места в команде и заняться вопросами попадания в оценки, написания кода с должным качеством или просто поискать ответ на вопрос: "А что это мы так много разговариваем?".

#разработка