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