Жизненный цикл проекта в организации: как избежать бюрократизации на ранних этапах

Управление проектами в организации — это не только следование методологии (Agile, Waterfall, Scrum), но и понимание самой компании и стадии разработки ее планов. Модель жизненного цикла организации Ицхака Адизеса вполне применима к проектам внутри организации. Однако ключевой ошибкой многих компаний является перенос проверенных практик управления на ранние этапы, что приводит к бюрократии, копированию действий и в конечном итоге провалу проекта.

• Как стадия организационного развития (по Адизесу) влияет на структуру проекта?
• Почему строгое разделение функциональности на этапе «Go-Go» наносит ущерб?
• Как объединить проекты разного уровня зрелости в рамках одной компании?

Жизненный цикл организации и проектов: теория Адизеса

Адизес выделил 10 стадий развития компании, но пять из них являются ключевыми для управления проектами:

1. «Выживание» (ухаживание) — есть идеи, но нет четкого процесса.
2. «Come, come» (ребенок) — активное начало, высокая энергия, но слабая структура.
3. «Go-Go» — для масштабирования, прежде всего, необходимо справиться с кризисом.
4. «Юность» (отрочество) — формализация процессов и возникновение бюрократии.
5. Главное - баланс гибкости и контроля.

Проекты внутри компании повторяют этот цикл, но адаптируются к зрелости самой организации.

Почему на этапе "Давай-давай" нельзя дробить функции

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

✅ Формальность вместо результатов — Сотрудники начнут «выполнять» свои KPI вместо того, чтобы решать проблемы.

✅ Увеличение административных расходов — больше времени тратится на отчетность, чем на саму работу.

✅ Потеря гибкости — любые изменения требуют одобрения.

Примеры из практики.

Обратите внимание: Папки для документов. Несколько идей по организации хранения.

Однако после интеграции в основную структуру банка возникли следующие ситуации:

• Отделы по обеспечению соответствия, которые требуют одобрения каждого изменения,
• Юристы задерживают выпуск новых функций,
• Отдел отчетности ежедневно запрашивает показатели.

Результат: Через год проект был закрыт из-за потери темпов и роста затрат.

Как совмещать проекты разной зрелости в одной компании

Организация может находиться на зрелой/золотой стадии, но при этом начинать новые проекты в режиме «Давай-Давай». Решением является гибридная модель управления:

🔹Для зрелых проектов — четкие процессы, матрица RACI, регулярные обзоры.

🔹 Для новых инициатив — кросс-функциональные команды, минимум бюрократии.

Пример: Яндекс (структурно зрелый) использовал отдельный «гаражный» подход при запуске Яндекс.Плюс (2020:

• Небольшая автономная команда,
• Быстрые эксперименты без длительных согласований,
• Метрика «время от идеи до запуска» важнее отчетности.

Результат: сервис быстро привлек 5 миллионов пользователей.

Когда формализация необходима?

Переход к масштабированию, когда все вопросы роста решены, продукт запущен в производство, а все затраты стабильны или понятны их изменения, можно приступать к построению и разделению функционала. Сигнал:

• Конфликты возникают из-за дублирования функций.
• Принятие решения занимает слишком много времени.
• Из-за отсутствия стандартов качество снижается.

Но важно не перегружать процесс проекта на раннем этапе.

Вывод

1. На ранних стадиях проекта («Go Go») требуется плоская структура и кросс-функциональность.
2. Жесткое разделение ролей с самого начала будет сдерживать скорость и инновации.
3. Проекты на разных уровнях зрелости могут сосуществовать в одной компании.

Я прекрасно понимаю, что вы хотите внедрять «лучшие практики» в новые проекты, использовать все свои знания))) Другими словами, вам нужно больше сопереживать людям, структурам, самому проекту.

Ты в порядке? Поделитесь примерами из своей практики в комментариях.