Проект может задерживаться на несколько недель, хотя каждый отдел выполняет свою работу вовремя. Продажи заключили договор, аналитик подготовил требования, разработчики выполнили задачи. Но клиент недоволен сроками, а руководители не могут договориться, как же так и что делать?. Часто причина находится между этапами, один отдел считает работу завершенной, а следующий ещё не может её начать. В заказной разработке это особенно заметно на переходе от продаж к производству. Менеджер согласовал стоимость и срок, получил подпись клиента и передал проект. Для продаж сделка закрыта. Но при подготовке технического задания выясняется, что часть требований не определена, интеграции требуют дополнительного исследования, а обещанный срок не учитывает загрузку специалистов, потому что после предварительного согласования все тысячу раз поменялось. Аналитик возвращает вопросы менеджеру, тот обращается к клиенту. Пока идут уточнения, разработчики переключаются на другие проекты, а после получения ответов приходится заново согласовывать ресурсы. Ни один участник не обязательно нарушил собственные обязанности. Проблема в том, что компания не определила, какой результат одного этапа должен получить следующий, спровоцировав хаос и тушение пожаров. Здесь возникает игра в пинг понг , руководитель видит задержку разработки и требует ускориться. Производственная команда показывает переписку с продажами. Продажи объясняют, что клиент изменил требования. Начинается разбор ответственности, хотя полезнее восстановить последовательность событий. Берем список проектов и начинаем детализировать, я бы начал с пяти-десяти проектов (в зависимости от их количества и объема), сроки которых заметно отклонились от плана. По каждому нужно установить четыре даты, когда предыдущий этап объявил работу завершённой, когда следующий принял результат, когда фактически приступил к работе и когда вернул задачу на уточнение. Это позволяет отделить время выполнения от времени ожидания. Например, аналитик потратил на требования три рабочих дня, но приступил к ним только через неделю после передачи сделки. Затем дважды возвращал документ на уточнение. В отчёте по загрузке видны три дня работы аналитика. В календарном сроке проекта - почти две недели. Если подобные задержки повторяются, дополнительный аналитик не обязательно решит проблему. Сначала стоит изменить правила передачи. Для перехода от продаж к производству я бы зафиксировал минимальный состав входных данных: согласованный объём, ограничения, требования к интеграциям, критерии приёмки и зафиксированные допущения. Производство должно иметь право не принимать проект без критически важной информации. При этом нужен ответственный за устранение замечаний и срок их обработки, иначе право отказа создаст новую очередь. Для нестандартных договоров полезна предварительная техническая оценка ещё до обещания клиенту окончательной цены и сроков. Результат изменений проверяется не количеством новых регламентов. Я смотрю на долю проектов, принятых с первого раза, количество возвратов, время между передачей и стартом работ, а также общий срок от договора до сдачи. Именно переходы позволяют обнаружить потери, которые не видны в отчётах отдельных подразделений. Когда у каждого этапа определены условия завершения и приёмки, руководителю проще управлять сроками всего проекта, а не выяснять после задержки, какой отдел должен был задать недостающий вопрос.