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

Поэтому никто никогда не может оценить точно сроки. Ошибаются все.

Перезакладывание по срокам

Обычно по срокам идёт перезакладывание, то есть менеджер зная что разработчик не может точно оценить работу умножает оценку на некий фактор. Например, накидывает сверху ещё 50%.

Это выливается в ущерб заказчику, так как он переплачивает, но так делают чтобы подстраховаться от провала по срокам.

Но даже перезакладывание не всегда спасает, так как ошибка хорошо разбирающегося в задаче разработчика может быть в 3-5 раз. Не в полтора, не в два раза, а в 3-5 раз.

И это если разработчик очень чётко знает задачу, представляет как её делать, опытен и уже делал подобные задачи.

Если же нет, то запросто может быть ошибка x10. Такое перезаложить невозможно.

Как избежать перезакладывания?

Борются с этим так, во-первых работают “спринтами” или “итерациями”, когда у команды на неделю-две есть некоторая цель, по ней идёт работа, что успели то успели. Далее в следующей итерации (спринте) или продолжаем или корректируем курс.

Во-вторых, оценивается в таком случае не фикс на весь проект а-ля “3 ляма” а расходы на команду в месяц.

Команда определённого состава, сбалансированная по скиллам, будет тратить столько денег сколько часов каждого специалиста заложено в план умноженное на часовую ставку.

Это уже более предсказуемо.

Вместо того чтобы пытаться угадать будущее, мы определяем какая команда нам нужна и сколько приблизительно мы готовы потратить времени на разработку и отсюда уже получаем ориентировочный бюджет на проект.

Фиксируем только одно

Учитывая непредсказуемый характер разработки, в своём плане мы можем зафиксировать только что-то одно.

Фиксируя конечный результат, становится непредсказуемым срок, за который мы достигнем требуемого результата. Чем точнее определили результат, тем меньше места для манёвра и тем более непредсказуемым станосится срок выполнения.

Фиксируя срок, мы получаем результат неопределённого качества. Каким будет результат и не закончится ли вся история провалом, будет зависеть от профессионального уровня команды.

Можно попытаться зафиксировать и точный результат и срок, но тогда на порядок вырастает риск вообще не справиться с задачей. Либо пролететь по срокам, либо по качеству. Этот печальный итог повсеместно наблюдается там, где договариваются на такие условия.

Как двигаться к цели, не ставя жёсткие сроки?

Как тогда работая по спринтам не крутиться в бесконечном колесе доработок а достигать определённых целей в нужный срок?

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

2. Ставится цель, например “за три спринта сделать чаты”.

3. Сама фича чатов бьётся на части, “задачи”.

4. Эти задачи отправляются в беклог.

5. Задачи в беклоге ранжируются по приоритету. Например текст в чате более важен, чем прикрепление файлов. Поэтому его помещаем выше в списке.

6. Далее эти задачи достаются по одной и идут в спринт в разработку, выполняя каждую мы движемся к цели.

Контролируем беклог

Параллельно разработке Project Manager или же Product Manager, или тимлид следит за тем, что команда идёт с нужной скоростью, и успевает за намеченные спринты выполнить все необходимые задачи.

Он же решает проблемы если “не успеваем” — либо скипаем задачу, либо упрощаем, либо увеличиваем сроки (последнее нежелательно).

Беклог регулярно обновляется: переставшее быть актуальным выкидывается из него, меняется приоритет задач чтобы в работу бралось только самое актуальное.

Результат

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

Иногда и при такой работе будет срываться срок, но все остальные подходы дают результат сильно хуже.