постоянные изменения и реорганизация

В предыдущем посте мы убедились, что оказались на этапе развития «Давай-давай» по Адизесу, а также обозначили 5 основных проблем, характерных для этого этапа. Сегодня я хочу подробнее рассказать, как именно эти сложности проявлялись в нашей практике и каким образом мы с ними справлялись — начнем с темы постоянных изменений. В скобках я буду указывать PAEI-код каждой активности, а в заключении мы подведем итог, как же выглядел наш код на этом этапе.

Постоянные изменения

По Адизесу, организация на этапе «Давай-давай» уже успешно работает и зарабатывает деньги, порой даже больше, чем может эффективно использовать. Это подталкивает к стремительному и порой безрассудному расширению: компании выходят на несвязанные рынки, запускают широкую линейку товаров, хватаются за любую идею. Успех порождает ещё больше ресурсов — и возникает потребность в новом витке роста. Получается замкнутый круг.

Адизес образно сравнивает такие компании с детьми, которые постоянно вырастают из своей одежды: «Штаны, которые ещё на прошлой неделе волочились по полу, сегодня едва прикрывают лодыжки». Именно так выглядело и наше развитие. Мы существенно расширили штат (Е) — и тут же столкнулись с текучкой. Едва удалось стабилизировать ситуацию за счёт контроля перегрузок и документирования процессов (А), как бизнес поставил новую задачу: ускориться за счёт сокращения времени на исправление багов. Мы внедрили модульные тесты (АI) — количество ошибок снизилось, а время на их устранение сократилось. Но тут же последовал новый запрос: ускорить поставку фич (P).

Мы снова отреагировали: стандартизировали практики разработки (A), начали переиспользовать код (PA), создали единую дизайн‑систему (PAI). И снова — новый вызов: бизнес захотел независимых релизов для разных продуктовых команд.

На всё это накладывались внешние факторы: пандемия, санкции, необходимость импортозамещения. Они тоже требовали порой радикальных реорганизаций (I). Каждое такое изменение не просто меняло процессы — оно заставляло нас полностью перестраиваться. Работать по‑старому под новые завышенные требования было невозможно. При этом критически важной становилась сильная А‑функция: нужно было повышать эффективность здесь и сейчас, в краткосрочной перспективе.

Заметьте: способов повысить эффективность (AI) оказалось множество, и все они требовали внимания. Если бы мы попытались взяться за всё сразу, ничего бы не вышло. Мой личный девиз того периода звучал так: «Схватимся за всё — не вывезем ничего». Мы сознательно выбирали 2–3 ключевых направления на квартал, но внутри каждого прорабатывали сразу несколько подходов (EI). К примеру, чтобы сократить время на исправление багов, мы не только внедряли модульные тесты, но и активно продвигали принципы Low coupling/High cohesion — это помогало упростить взаимосвязи в коде и снизить его сложность (I).

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

Итог Могу уверенно сказать: мы действительно прошли через постоянную и серьёзную реорганизацию. Мы учились осваивать А‑функцию, фокусироваться на самых важных задачах и концентрировать усилия там, где они давали максимальный эффект — всё в точном соответствии с предсказаниями методологии Адизеса.

Последние 5–6 лет прошли для нас в режиме непрерывной трансформации (I). Каждый квартал мы работали чуть иначе, чем предыдущий: поток изменений не останавливался ни на секунду (E). Но, оглядываясь назад, я понимаю: мы не просто выжили в этой турбулентности — мы выработали навык эффективно работать в условиях постоянных перемен. В будущих публикациях вы ещё не раз увидите, как этот опыт помогал нам решать новые задачи.