Спасибо за статью! Ничего личного, но все же выводы и решения у вас несколько поверхностные. Я и сам похожие выводы делал в прошлом, когда факапил сроки своих первых проектов. Однако эти выводы никак не помогали решить проблему в будущем, это повторялось снова.
Другое дело – когда каждый член команды действительно отвечает за свой участок. В том числе и своими деньгами. Вы сразу заметите, как повышается точность оценки сроков.Нет. Просто теперь каждый сотрудник начинает резко очерчивать свою зону ответственности по букве ТЗ. И получается что отдельные части готовы, а в целом нифига не работает, и кто за это отвечает - тоже непонятно. Проект не сдан, но все по-отдельности молодцы, еще и за премией придут. Кроме того, очень сложно опытных программеров посадить на оплату за результат - они от этого нервничают и увольняются, потому как за дверьми стоит толпа хедхантеров с жирными фиксовыми офферами по ТК РФ, печеньками и танцовщицами go-go в красивых офисах.

Причин невыполненной работы всего 2 в природе: тот, кто отвечает за неё, сделал недостаточное количество действий либо у него недостаточная квалификация.Тоже нет. Есть третья (и очень частая) причина - задача не вполне точно сформулирована, допускает разночтение, не вполне продумана реализация, цепочка заказчиков и исполнителей понимают ее по-разному (или вообще не понимают). Тревожный звоночек - это оценка задачи для конечного исполнителя более чем в 1 день - нужна более глубокая декомпозиция.

Если руководитель проекта не умеет внутри каждой итерации правильно выявлять причину, по которой срок съезжает, и работать с ней, ему не удастся выпустить проект вовремя.Чаще всего руководитель обнаруживает съезжание сроков уже в конце проекта, когда поздно что-то исправлять.

Что же делать?

Во-первых, agile и короткие спринты никто не отменял. Это не серебряная пуля, но процесс реально становится куда более прозрачным и управляемым. Отсюда же вытекает очень простое правило - как можно быстрее запускать в prod MVP и дальше заниматься его доработками по спринтам. И "продавать" эту идею заказчику, даже если он гос. и контракт у вас по 44-ФЗ (у меня были такой опыт).

И еще, саму по себе идею оценки сроков можно перевернуть с ног на голову: сначала фиксируете срок запуска MVP (например, месяц), и идете к команде выяснять, что и как они в него успеют сделать. Несколько итераций челночной дипломатии между командой и заказчиком - и вы получите куда более точную цифру чем при классической оценке от задачи. Чем короче срок, тем точнее будет оценка.