Причины срыва сроков в IT-проекте

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

В ходе составления ТЗ исполнитель считает, сколько потребуется времени на проект. Например, он посчитал, что разработка с участием одного программиста займет 200 часов: стандартная нагрузка в месяц на разработчика — 140 часов, значит, для реализации требуется 1,5 месяца. Но по факту по истечении этого времени проект не готов. Почему?

Несвоевременное получение информации от заказчика. Это, кстати, встречается в каждом первом проекте. Например, в проекте заложена интеграция сайта с 1С. Однако специалист со стороны заказчика уходит в отпуск как раз в тот момент, когда до нее дошло дело. Руководитель проекта со стороны заказчика не подумал об этом заранее. Казалось бы, ничего страшного: дождемся специалиста из отпуска и передадим все, что нужно. Но для разработчика такая ситуация плоха тем, что простои никто оплачивать не будет. Чтобы не терять в заработке, разработчика переводят на другой проект. К тому времени, когда заказчик предоставляет информацию, разработчик уже не может легко вернуться к исходному проекту, поскольку уже плотно занимается другим проектом.
Нет контроля со стороны заказчика. Продолжим на приведенном выше примере. несмотря на то, что на проект заложено 200 часов и 1,5 месяца, исполнитель может получить срочный или более выгодный заказ от другого клиента. При отсутствии должного контроля в виде регулярных встреч и отчетов по проекту разработчика с этого проекта могут перевести на срочный/выгодный проект, потому что он лучше всех справляется с такого рода задачами.
Затягивание согласований со стороны заказчика. Например, исполнитель разработал дизайн и ждет утверждения неопределенное время, вносит правки — и снова ждет. При этом команда разработчиков под проект уже выделена и ждет отмашки для старта работ. В случае подобных простоев и затягиваний есть риск, что эту команду переведут на другие проекты. Когда же со стороны заказчика будут утверждены правки, уже им придется ждать, когда освободятся специалисты для их проекта.
Недооценка стоимости проекта. Это, пожалуй, самая серьезная проблема. Масштаб недооценки зависит от качества ТЗ: чем оно хуже, тем больше будет недооценка. Для заказчика недооценка кажется привлекательной, потому что стоимость проекта меньше. На самом же деле это очень плохо, потому что при кажущейся экономии на выходе получится сырой продукт. Если разработчикам потребуется больше зафиксированного в документах времени, то проект окажется убыточен для исполнителя. Он будет вести переговоры с заказчиком об увеличении бюджета, и при отрицательном результате может остановить работу над проектом и перекинуть команду на другие работы. Заказчик же рискует либо получить усеченный функционал, либо вообще остаться без какого-либо продукта.

Больше о взаимодействии заказчика с исполнителем читайте здесь.