Как определять сроки и контролировать их выполнение

Сроки – третий по важности параметр для клиента, после наличия у командыквалификации для выполнения проекта и его стоимости. Как часто сроки затягиваются? Средний показатель по отрасли – 50%. Это значит, что в каждом втором проекте происходит отставание от первоначально заявленных сроков окончания разработки. Приятно отметить, что мы отличаемся в лучшую сторону, и наш показатель ниже.

А вот и наш любимый клиент, давненько вас не видели.
Одна из важных причин того, что мы чаще других «вписываемся» в обещанное время: мы активно работаем с клиентом, стараясь заранее исключить все риски по невыполнению  обязательств с его стороны. Как известно, в половине случаев задержки происходят не по вине исполнителя. Заказчик может не прислать необходимые данные, прислать не те, не тогда, забыть связать с нужным контактным лицом, не успеть прислать комментарии по выполненному этапу, в конце концов вообще пропасть и не реагировать на сообщения несколько недель. Это плохо, потому что сбивается темп разработки проекта и рушатся внутренние планы по загрузке работников. В начале проекта всегда необходимо выяснять у клиента, насколько оперативно он будет реагировать на твои запросы и как часто будет на связи. Если что-то произошло невовремя по его вине, зафиксируй этот момент. Если потом клиент спросит «а почему проект сдается на месяц позже?», тебе будет что ответить. 
Но остается еще часть проектов, которые задерживаются по нашей вине. Причины могут быть разными, от неправильной оценки сроков, до разгильдяйства программистов или авралов на параллельных проектах, куда пришлось отдать ресурсы.

Ups, I did it again...
Первое – если ты видишь, что нет шансов сдать проект вовремя, сразу сообщи клиенту. Тактика страуса не поможет – в данном случае пол как раз бетонный. Чем позже клиент узнает о том, что проект не будет выполнен в срок, тем больше негатива и проблем ты получишь. У клиента есть свои планы, свой бизнес, своя запланированная последовательность действий, в которой он опирается на обещанные тобой сроки. Если что-то не срастается – сразу же сообщай. Если потом каким-то чудом ты успеешь в срок – ну, отлично.

Как правило, разумные клиенты, особенно с опытом заказа IT-проектов, готовы к тому, что сроки могут быть затянуты, и учитывают это. Твое сообщение не будет для них шоком. Чтобы сгладить неудобство, можно предложить клиенту компенсацию в виде дополнительных бесплатных услуг по суппорту или созданию нового функционала. Бывает, что задержка вызвана тем, что при оценке проекта не было учтено каких-то существенных вещей, особенно часто это бывает в нестандартных проектах, опыта разработки которых у нас еще не было. В этом случае нужно объяснить клиенту, что мы были излишне оптимистичны при оценке, и сроки сорваны не из-за того, что мы сидим и ничего не делаем. Но в любом случае это наш косяк, и за него нужно нести ответственность. 

Что делать, чтобы таких ситуаций не происходило? 

Во-первых, называй сроки с запасом. Не надо умножать в разы, это может стать фактором, из-за которого клиент откажется от разработки у нас, но разумный запас всегда нужно накидывать. 
Второе – убедись, что ты можешь начать проект вовремя. Что все исполнители освободятся в нужное время от предыдущих проектов, что там не назревает задержек, что никто не запланировал отпуск и так далее. Обязательно это учитывай. 
Третье – разбей проект на этапы и мониторь срок выполнения каждого этапа. Клиент может знать об этих майлстоунах или не знать, но внутри команды они должны быть, и ты должен контролировать сроки выполнения определенного объема работы к определенному сроку. Если какой-то этап не пройден вовремя – это звоночек, который должен заставить тебя или ускорить процесс на следующих этапах, или, если это невозможно – идти «сдаваться» клиенту. 
Чем сложнее проект, тем тяжелее правильно оценить сроки. Поэтому, если мы делаем что-то уникальное и совершенно новое (а мы часто работаем над такими проектами) – необходимо договориться с клиентом о том, что финальные сроки выполнения всего проекта невозможно точно определить на его старте, и эти сроки могут сдвигаться по ходу разработки проекта, и скорее всего проект будет делаться по этапам. Клиенты, заказывающие нечто очень нестандартное, как правило понимают сложность поставленной задачи и готовы к пересмотру сроков в ключевых точках в процессе работы.

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