Жизненный цикл проекта в организации: как избежать бюрократизации на ранних этапах
Управление проектами в организации — это не просто следование методологиям (Agile, Waterfall, Scrum), это понимание стадий развития как самой компании, так и её инициатив. Модель Ицхака Адизеса, описывающая жизненный цикл организации, очень применима к проектам внутри неё. Однако ключевая ошибка многих компаний — перенос зрелых управленческих практик на ранние этапы, что приводит к бюрократизации, имитации деятельности и, в конечном итоге, к провалу проектов.
- Как стадии развития организации (по Адизесу) влияют на структуру проектов?
- Почему на этапе "Давай-давай" жёсткое разделение функций губительно?
- Как совмещать проекты разной зрелости в одной компании?
Жизненный цикл организации и проектов: теория Адизеса
Адизес выделяет 10 стадий развития компании, но для проектного управления ключевыми являются 5:
- "Выживание" (Courtship) – идея есть, но нет чётких процессов.
- "Давай-давай" (Infant) – активный старт, высокая энергия, но слабая структура.
- "Быстрый рост" (Go-Go) – масштабирование, первые кризисы управления.
- "Юность" (Adolescence) – формализация процессов, появление бюрократии.
- "Расцвет" (Prime) – баланс гибкости и контроля.
Проект внутри компании повторяет этот цикл, но с поправкой на зрелость самой организации.
Почему на этапе "Давай-давай" нельзя дробить функции
На старте проекта ключевая задача — быстро проверить гипотезу, а не выстраивать идеальные процессы. Если в этот момент внедрить жёсткое разделение ролей, произойдёт следующее:
✅ Формализация вместо результата – сотрудники начнут "отрабатывать" свои KPI, а не решать задачу.
✅ Рост overhead-затрат – больше времени уходит на отчёты, чем на работу.
✅ Потеря гибкости – любые изменения требуют согласований.
Пример из практики. В 2021 году один из российских банков запустил стартап-проект по цифровому кредитованию. Команда из 5 человек (разработчик, аналитик, маркетолог, продакт, финансист) работала в плоской структуре, быстро тестируя гипотезы. Через 6 месяцев проект вышел на окупаемость.
Но после интеграции в основную структуру банка появились:
- отдел compliance, требующий согласования каждого изменения,
- юристы, замедляющие выпуск новых фич,
- отдел отчётности, запрашивающий метрики ежедневно.
Итог: через год проект закрыли из-за потери скорости и роста издержек.
Как совмещать проекты разной зрелости в одной компании
Организация может находиться в стадии "Зрелость/ Расцвет", но запускать новые проекты в режиме "Давай-давай". Решение — гибридная модель управления:
🔹 Для зрелых проектов – чёткие процессы, RACI-матрицы, регулярный аудит.
🔹 Для новых инициатив – кросс-функциональные команды, минимум бюрократии.
Пример Компания "Яндекс" (зрелая структура) при запуске "Яндекс.Плюса" (2020) использовала отдельный "гаражный" подход:
- небольшая автономная команда,
- быстрые эксперименты без долгих согласований,
- метрика "время от идеи до релиза" важнее отчётности.
Результат: сервис быстро набрал 5 млн подписчиков.
Когда формализация необходима?
Переход к Масштабированию, когда уже все вопросы роста решены, продукт поставлен на поток, все косты стабильны, или понятны их изменения, тогда можно структурировать, начать разделение функции. Сигналы:
- Появляются конфликты из-за дублирования функций.
- Решения принимаются слишком долго.
- Качество падает из-за отсутствия стандартов.
Но важно не перегружать проект процессами раньше времени.
Вывод
- Ранние стадии проекта ("Давай-давай") требуют плоской структуры и кросс-функциональности.
- Жёсткое разделение ролей на старте убивает скорость и инновации.
- В одной компании могут сосуществовать проекты с разными уровнями зрелости.
Я очень понимаю, что хочется внедрить на новых проектах "лучшие практики", применить все свои знания))) Другими словами, надо чувствовать, побольше эмпатии к людям, к структуре, к самому проекту.
А как у вас? Делитесь примерами из практики в комментариях.