Правильная оценка сроков и декомпозиция задач⁠⁠

Попробую описать все на пальцах, коротко и ясно, как правильно оценивать сроки больших проектов и разбивать их на задачи.

Если вы еще не в курсе, на канале "Самоучки IT (Управление проектами)" https://t.me/+NfVrLMxdKS0yNDNi регулярно публикуется материал обо всех тонкостях управления проектами в IT-сфере. Так что подписывайтесь и не пропускайте интересное!

Начнем с того, что точно предсказать, когда все будет готово, на 100% не получится. Всегда найдутся какие-то неожиданные проблемы, риски и прочие непредвиденные обстоятельства. Но это не значит, что надо бросать все на самотек! Наоборот, есть проверенные методы, чтобы минимизировать ошибки в оценках и не слишком все запороть.

Начнем с самого главного — как разделить огромный проект на кусочки, чтобы потом можно было их нормально спланировать и рассчитать примерные сроки. Тут два основных подхода — маршрутная и технологическая декомпозиция.

Маршрутная — когда смотришь на все глазами пользователя. Допустим, в мессенджер надо добавить фичу отправки контента. Тогда декомпозиция будет такая: сначала показать окно, потом добавить список контактов, потом текстовое поле для сообщения, потом саму кнопку отправки и в конце реализовать поиск. Все разбивается на простые шаги и состояния так, как их видит обычный юзер.

Плюсы такого подхода — он быстрый, его можно провести без больших технических познаний. Минусы — разные задачи могут оказаться совсем несопоставимыми по сложности и времени. Ну и зачастую получается линейная последовательность, где одна задача жестко завязана на предыдущую. Если где-то произойдет задержка, все остальное тоже сдвинется по срокам.

Второй подход — технологическая декомпозиция. Тут уже надо погружаться в низкоуровневые детали: какие модули, библиотеки, компоненты нужно будет переписать, какие новые добавить. Эта штука более точная, ее можно распараллелить при правильном проектировании. Но требуются серьезные экспертные знания об архитектуре и самом продукте.

На практике часто используют комбо из двух подходов. Сначала делается маршрутная декомпозиция на высоком уровне: к примеру, "пустое окно" -> "окно с контактами" -> "окно с текстом" и т.д. А потом каждый такой переход детализируется уже технологически — что именно надо допилить, какие модули затронуть.

После того как мы задекомпозировали весь бардак, идем дальше. Строим общий граф задач, выделяем в нем критический путь — это цепочка обязательных задач, которые четко зависят друг от друга. Именно протяженность этого критического пути и определяет минимальные сроки реализации фичи.

Дальше распихиваем задачи по спринтам. Тут тоже есть негласные правила: в один спринт нельзя брать блокирующие друг друга задачи, каждая задача должна умещаться в один спринт и т.д. В идеале в конце последнего спринта функционал будет полностью готов. Но это в идеале!

На самом деле, первоначальные сроки почти всегда затягиваются и сдвигаются. Поэтому финальный дедлайн надо рассчитывать с огромным запасом, ожидая все возможные проблемы. Берем все задачи и удваиваем их предполагаемую длительность на всякий случай. Добавляем время на отпуска, болезни, ротацию команды. Плюс закладываем циклы тестирования, возвратов, мелких доделок после релиза.

Ну и под конец обязательно пересчитываем длину критического пути с учетом всех рисков. И уже после этого называем финальную дату сдачи проекта. Может, она будет совсем нерадостной, но хотя бы реалистичной! Получилось все понятно?

А если вдруг что-то осталось неясным, обязательно читайте разъясняющий материал на канале "Самоучки IT (Управление проектами)" https://t.me/+NfVrLMxdKS0yNDNi