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

В заказной разработке такой сценарий особенно актуален. Одновременно идёт около 25 проектов, у каждого свои сроки, клиент и состав команды. Хочется усилить контроль, чаще встречаться, детальнее проверять планы, смотреть отчёты. Но руководители проектов начинают тратить время на объяснение задержек, а решения о приоритетах по-прежнему приходится принимать наверху.

Я вижу тут три связанные ошибки.

Первая - принимал полную загрузку за эффективность. Если разработчик занят весь день, это ещё ничего не говорит о том, сколько задач завершено и передано клиенту. Когда специалист переключается между четырьмя проектами, каждый менеджер видит работу над своей задачей, начинаетс сбалансированная дележка ресурсов. В общем портфеле растут незавершённые работы и время ожидания. Дополнительный найм при таком порядке может увеличить число одновременно открытых задач, не ускорив завершение.

Вторая - разбирал срывы по отдельным проектам. Менеджер показывал свой план, и в нём всё,очнь убедительно. Но один аналитик или разработчик мог числиться сразу в нескольких планах. Приоритеты существовали внутри проектов, но не на уровне компании. Конфликт обнаруживался, когда уже требовалось переносить срок или объясняться с клиентом.

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

Порядок пришлось менять через общую картину портфеля: сколько задач в работе, где они стоят без движения, какие специалисты перегружены и кто вправе менять приоритеты. Мы ввели сопоставление плана с фактом и стали разбирать причины задержек на уровне всего потока, а не только отчётов отдельных менеджеров. В результате очередь сократилась примерно на 30%, а количество завершённых работ за сопоставимый период выросло на 20%.

Цифры показали цену прежних решений: время руководителей уходило на согласования, разработчиков - на переключения, а клиентов - на ожидание. Теперь перед предложением нанять людей, усилить контроль или потребовать новый отчёт я сначала проверяю загрузку, очередь и правила принятия решений. Изменение процесса исправляет не каждую задержку. Но пока руководитель не видит общую картину, он рискует снова оплатить ту же ошибку временем команды и деньгами компании.