Каждая компания двигается по шкале от незрелой к зрелой и обратно. Это всегда динамика. Сегодня вы образец, завтра вы устаревшая помойка. Если 10 лет назад для наведения порядка внедрялся какой‑нибудь «каскадо‑водопадный PMI», 5 лет назад гибко‑адаптивный Agile‑OKR, то сейчас есть динамика к культуре проведения экспериментов*.
Случилось это по разным причинам, одной из них считаю изменение горизонта планирования и задачи на сокращение издержек. На сегодня, нужно планировать либо на 30 лет вперед и бороться за новые рынки (в том число создавать их), либо сосредоточиться исключительно на текущей выручке.
*Статья состоит из двух блоков — критика и предложение. Контекст: продуктовая ИТ компания среднего уровня, не стартап и не из ТОП 50.
Критика. Трудности классических подходов
Символ порядка — предиктивный (PMI, водопадный подход), который можно описать: долго планируем + долго делаем по плану работ, но снижаем риски. Все участники довольны, так как у них есть план, сроки и бюджет, где можно долго отчитываться с умным видом по контрольным точкам. Недовольны только пользователи. На данный момент, подход является похоронным бюро для ИТ проекта. На момент выхода продукта вашу долю рынка заберут другие, вы получите никому ненужный софт, единственное, с чем хорошо справляется — освоение нужной суммы. В сфере госов, этот подход — единственный возможный, его минусы обычно решаются доп. соглашением, что дает хоть какое‑то поле для маневра и выпуска, действительно, чего‑то нужного или рабочего. Доп.соглашение — попытка вырулить за счет Agile, что означает — получили обратную связь — внесли правки.
Собственно Agile. Тут в теории все отлично, а на практике, как правило, перед нами всегда только Agile — театр. Этот театр наблюдать лучше всего со стороны. Выглядит это обычно следующим образом: в вашей компании, выборочно (!), соблюдаются ритуалы. Всегда есть подобие стендапа, если кто‑то из руководства прочитал еще пару страниц, то у вас будут рабочие доски и какое‑то линии на этих самых досках назовут — Канбаном. Если руководство прямо очень поверило в Agile, то у вас даже могут быть ретро. А за этой сценой всегда будет стоять обычный контракт или выигранный конкурс на 100 «модулей» в год, или на «разработка согласно ТЗ».
Ключевой принцип Agile, когда платят за то, что все «стараются» — на деле, представляю себе только...не придумал даже где (помогите к комментах, фантазии не хватило).
Дальше у нас идет гибрид. Если не вдаваться в терминологию, то он про то, как в работу за которую платят, встраивать что‑то в интересах пользователя. Если в ИТ что‑то получилось, то там был гибрид.
Гибрид: допустим, у нас есть то, за что компании платят. то есть вы решаете какую‑то острую проблему вашего клиента. Обычно это означает, что кому‑то за что‑то нужно будет отчитаться. Осталось придумать, как к этому добавить, то, что будет работать, еще и лояльного пользователя.
Раньше можно было, вторую (рабочую) часть назвать продуктовым подходом и начать «опрашивать клиентов». Назвать всю деятельность Agile и совмещать театр с выполнением ТЗ — более менее рабочая история. Но получается много противоречий и, самое неприятное — очень дорого. Противоречия в том, что нужно контролировать, то, что не нужно контролировать и нанимать непонятных людей с высокими ЗП, которые непонятно что делают, но все как один, вносят вклад в продукт. По крайней мере, по их словам.
У продуктов с подобным подходом к управлению, финансовые модели — оставляют желать лучшего. И как только вы окажитесь на уровне руководителя с буквой «С» (генеральный либо директора направления) рассказывать истории про перспективы, будет крайне сложно. И по текущим реалиям, вас «попросят» сократить издержки. В результате чего, на данный момент мы переходим на кризисный гибрид.
Предложение. Кризисный гибрид
В основе, так или иначе, что‑то за что платят (контракт, ТЗ, договор, внедрение, консалтинг, сроки, содержание и тому подобное) От классического типа отношений никуда ни деться. К этому прибавляем задачу на сокращение издержек и, все же, попытку создать что‑то рабочее для пользователя. Так как без лояльного пользователя, продукт скорее всего, не будет финансово интересным. Внедрение, продвижение, сопровождение — будет съедать всю доходную часть.
Внедряется кризисный гибрид, особенно в компании с проектным подходом, таким образом: отсекаем все лишнее от agile и оставляем только короткий цикл обратной связи от пользователя через проверку гипотез. Что подтвердилось в цифре — делаем, что нет — не тратим деньги. Подход не новый, но актуальный, как никогда.
Особенности кризисного гибрида:
Занимается тестами гипотез — один отдел для всех продуктов. Уходим от дублирования похожих (одинаковых) идей.
Продуктовые команды фокусируются на разработку, поставку и удержание текущих клиентов, пользовательские пути, UX и тому подобное
Маркетинг тоже лучше всего сделать общим. Помогает с дополнительными продажами (up и cross sale)
По итогу получается операционный блок + команда R&D без раздутой штатки из непонятных управленцев.
Естественно, не все продукты нужно кидать в этот кризисный портфель. Если у продукта все хорошо, то его, как и его команду не нужно трогать.
Кризисный гибрид можно использовать, как альтернативу закрытию направления или как пилотный проект по переходу к продуктовому управлению.
Подход хорошо «продается» руководству, как идея. Отличается от модных «давайте наймем еще 5 человек в продукт» на «давайте фокусироваться на пользовательском опыте с минимальными затратами».
Артефакты и требования для кризисного гибрида:
Реестр продуктов (список всех фич и продуктов). Помогает понять масштаб катастрофы.
Хотя бы одна метрика стыда — отток пользователей (Churn Rate). Остальные метрики — приятный бонус. Иначе вы не поймете пользуются ли действительно вашими продуктами.
Формализация гипотез по простой формуле: «Мы считаем, что если сделать (А), то это приведет к (Б). Успех проверим по метрике (Я)». Если нет гипотезы по формуле — то нет задачи в работу. Это самое главное — отваливается много бестолковой работы.
Смелая команда. Находим наших любимых еретиков, из моей прошлой статьи, где меня забросали помоями. Это про тех людей, которые все понимают и хотят показывать реальный результат и работу. Берем их в команду экспериментов. Еретиками они должны быть из‑за того, что вам нужна другая культура для быстрой работы и смелых идей. Если дошло до кризисного гибрида, то культура проверки гипотез в компании не работает.
П.С. Наблюдается ли в последние пару лет, что‑то похожее в ваших компаниях и работе? Либо кризисный гибрид добрался пока только до нас?)
На своем канале в ТГ пишу про текущие работы и самообучение. Сейчас основная тема — продуктовые подходы.
В базе я project, на канале можно встретить посты на тему управления проектами, например, по книге Путь Камикадзе. Спасение безнадежных проектов.
Комментарии (4)
Pusk1
29.09.2025 06:18Есть впечатление, что ajile и кризисный подход одно и то же. Интерактивная разработка с ожидаемой и проверяемой ценностью на каждом этапе. Не путать со скрамом и другими довольно жёстким фреймворками. Принципы Kanban как бы ортогональны. Если горе менеджеры наплодили 53 этапа на доске, то больших им успехов. В промышленности, когда цикл от заказа до поставки занимает от полугода, отлично работают и жёсткие календарных планы и кабан.
Sergio_P Автор
29.09.2025 06:18Я бы не сказал, что одно и то же, в кризисной основная часть работы происходит до разработки, акцент именно на этап до. Плюсом нет никаких кросс-функциональных команд.
M_AJ
Всегда удивляли разговоры о менеджменте ИТ проекта, без конкретного уточнения, какой именно ИТ проект имеется в виду. Ведь есть принципиальная разница в том, делаем мы финтех стартап для масс маркета, или автопилот для авиалайнера. И то и другой ИТ продукт, но если для первого требования могут меняться быстро и кардинально, то для второго нет, и там вполне может быть применен и водопад.
Я думал классический эджайл так и работает – мы что-то делаем, в это время аналитики смотрят метрики, занимаются А/Б-тестами и на основе всего этого решается куда двигаться дальше. Может быть это и не так работает в реальности, я не знаю – не менеджер, но мне кажется, что если это просто назвать новыми красивыми словами типа "кризисный гибрид", то это внезапно заработает.
Sergio_P Автор
Для этого добавляю в самом начале "продуктовая ИТ компания". Автопилот или транспортная логистика, в моем понимание не ИТ проекты продуктовой компании. Согласен, что все сейчас ИТ, но проекты, в которых требования не меняются годами - еще нужно поискать. Мне кажется, это уже скорее исключение, о котором надо писать.
В классическом agile большой состав сотрудников + в чистом виде Agile практически не бывает, только разве что на уровне команды разработки, про что я и пишу. Когда сокращают бюджеты, то классический agile не выживает, отсюда я и говорю, о минимальном наборе, который позволяет оставаться в рынке.