Стартапы гордятся своей свободой и отсутствием жёстких правил. В свою очередь, чем крупнее становится компания, тем больше она нуждается в корпоративной культуре и правилах работы. Из первичного бульона хаоса, устных договорённостей и личных связей неизбежно формируются рельсы рабочих процессов в виде событийно-ролевой модели и рабочих артефактов. Другими словами, субъекты и объекты трудовых будней компании.
Меня зовут Евгений Иванов, я Agile Cluster Lead кластера Облачные технологии в компании MWS Cloud — команды, которая создала MWS Cloud Platform. И в этой статье я расскажу, почему мы считаем наш кластер анклавом процессных практик и какие плюшки и сложности мы с этого имеем. На тему наших процессов мой коллега Саша Стерлигов уже написал подробную статью.
Итак.
Учитывая размеры и возраст организации, можно не искать в амбулаторной карте диагноз enterprise — это очевидно и видно из космоса. Enterprise со всеми вытекающими: большим количеством команд, сложной ролевой структурой и огромным набором разношёрстных встреч для синхронизации происходящего на описанном периметре.
Не секрет, что на таких масштабах трижды благословенная самоорганиза��ия скорее напоминает безродный самотёк, который без должного контроля утечёт совершенно не по тому руслу и не в то море.
С какого-то момента в крупных организациях де-факто стало стандартом создавать специальные подразделения, отвечающие за разработку и внедрение правил работы, чтобы придать процессам правильную форму.
Постулаты о той самой «правильной форме» в виде ролей, набора событий, артефактов, принципов целеполагания и т. п. обычно оформляются в плейбуки, кукбуки и прочие корпоративные сборники рецептов счастливой, а главное — эффективной жизни.
Все эти атрибуты крупной и сформировавшейся организации есть и у нас: общекорпоративные правила и центры практик, которые отвечают за разработку и внедрение этих правил.
Наличие данных правил делает рабочие процессы едиными, понятными и во многом эффективными. Но не зря несколькими абзацами выше я назвал наш кластер анклавом. Дело в том, что словно Гонконг в Китае, мы хоть и являемся частью чего-то большего, основные правила рабочих процессов мы формируем сами.
Такое положение дел не следует считать ни проявлением сепаратизма, ни процессным нигилизмом, ни выражением недоверия к разработанным практикам. Верить в самостоятельное формирование эффективной и слаженной работы огромной корпорации без централизованных практик можно с тем же успехом, что верить в плоскую Землю.
Почему же мы сознательно отказались от предлагаемых практик и пошли по пути самоформирования? Из-за этапа жизни продукта, который мы создаём. Облако MWS Cloud Platform публично анонсировали 30 октября 2025-го. На сегодняшний день наш продукт существует на рынке всего несколько месяцев, которым предшествовали два года активной разработки.
По устоявшейся классификации рынка, нас смело можно отнести к стартапам, хоть и с недетскими амбициями. Почему же мы не использовали готовую модель процессных практик, а пошли по собственному пути, вкладываясь ещё и в самостоятельное выстраивание процессов?
В первую очередь из-за того, что в фокусе внимания был именно создаваемый продукт, а не способ его создания. Процессная и продуктовая зрелость — два тесно связанных явления, и их взаимосвязь содержит несколько нюансов. Сейчас расскажу подробнее.
Сначала продукт, потом процессы
По крайней мере, не раньше. Связано это с тем, что проложенные рельсы процессной эффективности могут привести к созданию абсолютно не того продукта, который должен оказаться на рынке. Да, я про ситуацию, когда с минимальными задержками и очень коротким Time-to-Market на рынок выводится то, что… никто потом не покупает.
До выхода на рынок наш продукт измерялся количеством коммитов да покрытием тестов, а не количеством клиентов и P&L. И точно не оценивался через призму скорости pipeline и продолжительности Lead Time.
Развивать в первую очередь продуктовую зрелость — мысль не просто очевидная, но и довольно старая (упоминается в «Маркетинговой близорукости» Теодора Левитта, 1960 г.) и распространённая (идея развивается множеством авторов, например, Эриком Рисом в его «Бизнесе с нуля», 2011).
Красота процессов всегда была второстепенной относительно создаваемого объекта.
Только после того как продукт полюб��т и начнут покупать, можно заниматься снижением стоимости разработки, разгонять Lead Time и бороться с потерями. Другими словами, продолжать создавать хороший продукт, но меньшими силами, увеличивая тем самым прибыль.
В этом месте следует сделать важную ремарку: процессную зрелость (события, роли, артефакты) не следует путать с инженерной (языками программирования, подходами к архитектуре, ИБ и пр.). Если первую мы открыто признаём растущей, то вторая уже на старте была сформирована с большим запасом прочности. А иначе технически сложный продукт и не создать.
Процессы не даются бесплатно
Готовые фреймворки предлагают комплекс правил для ролей и типовых ситуаций. Например, Scrum говорит про Разработчиков, Скрам-Мастера, Владельца продукта и пять событий на уровне команды; SAFe 6.0, в свою очередь, декларирует десятки ролей и событий.
(Пере)строить команду из состояния А в состояние В — задача не на один день.
Не забудьте про настройку инструментов, обеспечивающих задуманные процессы (таск-трекера, дашбордов, личных кабинетов на портале с указанием ролей), и прибавьте затраты на проведение обучения на всех уровнях (обучать будете сами или наймёте внешних специалистов?). Посчитали? Вычтите полученное значение из ресурсов, направленных на создание продукта. Если результат этого мысленного эксперимента вас устраивает — уверен, вы на правильном пути. Строительство процессов не стало заметным якорем в создании продукта.
Как несложно догадаться, с самого начала создания MWS Cloud Platform мы не хотели видеть якорей в своей работе. Ни свисающих за бортом, ни т��м более цепляющихся за дно.
Таким образом не был развёрнут ни один известный фреймворк. Мы не реализовывали описанные кем-либо «целевые процессы». Мы заведомо понимали, что на данном этапе ролевая модель определяется исключительно потребностью в определённых фокусах внимания (например, «Дежурный L3», отвечающий за работу с инцидентами), а не согласованным на уровне компании документом.
Отдавая предпочтение эволюционному подходу, мы не просто экономим время и ресурсы, но и сохраняем лояльность членов команд.
Но если каждая новая роль, каждое новое событие создаётся для решения конкретной проблемы или текущей задачи, — это не вызывает вопросов и ненужного сопротивления.
Хорошо, здесь я слукавил: конечно, без сопротивления и вопросов не обойтись даже при описанном сценарии. Но, во-первых, присутствует «IKEA-эффект»: созданное своими руками (мозгами?) ценится гораздо выше; во-вторых, при признании реализованного подхода неэффективным: роль, событие, артефакт и прочее просто списываются в утиль, уступая место новым идеям и решениям.
И перед тем как я буду обвинён в велосипедостроительстве, уточню: в данном случае свобода заключается не в возможности добавлять то, что кажется полезным в данный момент, а в праве отказываться от того, что больше не служит актуальным потребностям компании.
Другими словами, то, что не считается сейчас нужным из готового фреймворка, — просто не используется. Уберите от экранов детей, чтобы мы могли сказать страшное: «если бы мы считали, что ретроспектива сейчас не нужна — её бы не было». Не потому, что не видим в ней смысла. А потому, что содержание определяется потребностью, а не сформированными правилами. (Можете вернуть детей к экранам.)
Исходя из этой логики, не приходится поддерживать те вещи, до которых нашим потребностям ещё предстоит дорасти. Это заметно экономит силы и не позволяет сохранять фокус на действительно нужных вещах (в первую очередь — создаваемому продукту).
Вопреки всеобщему тренду в компании, мы мало внимания уделяли непосредственной скорости разработки: Lead Time и Time-to-Market. А вот встречи, посвящённые инцидентам на проде, в какой-то момент были ежедневными. Не потому, что стенды развалились в первый месяц работы, а потому, что первостепенный фокус — на обеспечении стабильной работы у клиентов.
За качество процессов не нужно отчитываться
Если вы никогда не работали в энтерпрайзе, эта мысль может показаться вам странной. Однако современные реалии диктуют необходимость измерять эффективность каждого запущенного механизма, не исключая подразделений, отвечающих непосредственно за процессы. KPI и OKR де-факто являются стандартом управленческой деятельности. Это подтверждают, например, коллеги из Skolkovo.
Процессы должны быть эффективными, а эффективность — измеряемой. Как обеспечить последнее — каждая компания решает сама, и самый частый способ, который наблюдал автор этих строк за свой карьерный путь, — это создание дашбордов разной степени сложности, точности и объективности.
То, что не может быть измерено автоматикой, — собирается вручную через анкеты, тесты и опросники. Прохождение любого опроса — тоже не бесплатная штука для компании. Хотя в этом нет проблемы, если по результатам собранных данных принимаются важные управленческие решения, которые влияют на дальнейшую работу.
Однако как только собранные показатели прорастают до финансовых ведомостей исполнителей — наступает эра слайдо-ориентированного программирования. Можно не быть отличником по показателям, а чувствовать себя в безопасности в середине списка. А место в середине ещё нужно обеспечить. Вот и получается, что порой фокус с создания продукта смещается на затраты, необходимые для обеспечения себе безопасного места в рейтинге команд.
Выбранный нами путь самостоятельности полностью избавил нас от необходимости задумываться о наличии экзистенциальных проблем своего существования. Нам больше нравится, когда о нас судят по технологической надёжности и финансовым показателям, а не по тому, растёт ли наш Velocity.
Преимущества
Выше я рассмотрел предпосылки к выбранному пути, настало время рассказать о том, что же мы получили.
Фокус на главном
Возможно, однажды на какой-то конференции мы расскажем о том, какие у нас классные подходы, но сейчас мы фокусируемся на другом. И уже сейчас мы готовы рассказать о своём продукте — MWS Cloud Platform. Наше облако было написано за два года, что очень быстро для создания решений такого масштаба.
Два последние года перед командами стояла главная задача — выйти на рынок с конкурентным продуктом. В ближайшее время нам предстоит нарастить функционал. Например, реализовать живую миграцию и интегрировать во все продукты сервис аудитных логов и как можно быстрее пережить продуктовый пубертат через доработки на основании обратной связи первых клиентов. И уже после этого — полноценно обратить внимание на подкапотную кухню с целью оптимизации собственных процессов и снижения затрат.
Гибкость процессов
Настоящая свобода не в возможности добавить то, что тебе нравится, а отказаться от того, что стало обременять работу.
Считается, что потребительский спрос — штука непостоянная. Нужно регулярно проверять гипотезы и развивать то, что оказалось востребовано, и выводить из оборота то, что безвозвратно устарело. И чем быстрее это будет сделано, тем быстрее мы принесём пользу клиенту.
По какой-то причине этот подход часто не распространяется на собственные процессы и форматы работы. Петля обратной связи от команд до следующей версии ранбука может составлять от нескольких недель до нескольких месяцев.
Наши изменения занимают дни при нормальном течении событий и часы, если сильно психануть. Такая скорость позволяет оперативно избавляться от неэффективного груза быстрее, чем ракета от отработанной ступени. Ну окей, не так же быстро, но метафора очень нравится. Очень хочется быть как ракета: несёшься такой, выбрасываешь ставшее ненужным, а потом раз — и вообще космос. Блеск.
Вовлечение
Когда каждый имеет возможность инициировать процессную инвентаризацию и предложить добавить что-то новое, списать устаревшее или защитить то, что считает полезным, — вовлечение участников процесса гораздо выше, чем при внедрении практик, принесённых со стороны.
А там, где выше вовлечение, — выше ответственность.
То, что работает плохо, — результат наших ошибок, и то, что работает — хорошо, результат наших правильных решений. Понимание причинно-следственной связи от собственных действий и полученного результата сильно повышает вовлечение и ответственность, а ещё это хорошая возможностью проявить инициативу для тех, кому это важно. А это в свою очередь дополнительный мотиватор в работе для множества коллег.
Все ключевые изменения, связанные с процессами и подходами к работе, выносятся на регулярную встречу с открытой повесткой, где в режиме дискуссий и сбора обратной связи идеи не просто полируются об общественное мнение, но и формируются рабочие группы в режиме реального времени.
Теперь о недостатках
А их нет. Шучу, конечно. Если бы описанный подход не имел недостатков, процессный консалтинг перестал бы существовать, а профессия Agile-коуча не была бы такой востребованной.
Повышенная ответственность
В предыдущем разделе я говорил про ответственность. И это не просто ответственность — это очень высокая ответственность.
Акционеров и высокое руководство мало интересуют фреймворки команд, их беспокоят дыры в финансовых отчётах. И если в какой-то момент наши показатели поедут вниз — внешний анализ ситуации с уверенной лёгкостью объявит одной из причин отсутствие общепринятых правил, и глобализация будет неизбежна. Мы свободны, пока эффективны.
Появление ряда практик с запозданием
Надеюсь, у вас не сложилось впечатления, что вместо использования готовых и проверенных (хорошо продающихся на рынке :) инструментов мы изобретаем велосипеды.
Мы на самом деле используем довольно много практик из популярных фреймворков (например, Product Increment Planning (PIP) из SAFe или Change Advisory Board (CAB) из ITIL), практик экстремального программирования (CI/CD, TDD и пр.) и прочих разных подходов, описанных в интересных книжках и статьях.
Однако выбранный нами подход к собственному развитию со значительной долей скепсиса смотрит на любой инструмент, который может затормозить текущий ритм работы. Поэтому практически не бывает инструментов «на вырост», которые бы предлагали полноценные фреймворки, превентивно предлагающие инструменты для решения многих распространённых проблем.
Таким образом, некоторые инструменты в нашей работе появляются с небольшим запозданием: часто первой на горизонте должна появиться проблема, которую этот инструмент будет решать.
При таком подходе мы, например, пересмотрели ролевую модель работы с инцидентами и создали два новых бота только после выхода в прод ключевых сервисов. Реализованные идеи были весьма очевидными в упомянутом процессе, однако для инвестиции ресурсов в данную автоматизацию сначала нужно было испытать реальную потребность, при которой ручной труд уже не соответствовал потребностям в скорости работы.
Отсутствие масштабирования
Мы — часть большой организации, во многом живущей по общим правилам. Наша свобода самоопределения — это исключение из правил, которое возможно только в ситуации наличия этих самых правил.
Если бы каждое направление в компании пользовалось собственными правилами — это в значительной мере ставило бы под угрозу саму компанию: как минимум затраты на синхронизацию и поддержание коммуникаций значительно выросли бы, как максимум — наступил бы масштабный хаос.
Людям свойственно не тратить энергию на активности, пользу от которых они себе плохо представляют. Ввиду своей профессиональной деятельности я год от года вижу, как на PI-планированиях (особенно первых в жизни компаний) команды с нескрываемым удивлением узнают о двух традиционных вещах:
Один и тот же функционал делают сразу два направления («а чего вы с нами не согласовали? Мы уже два месяца этим занимаемся»).
Какую-то из фундаментальных фичей не делает никто («мы думали, у вас это уже в работе»).
Таким образом, быть исключением из общей массы возможно только при наличии той самой общей массы. Причём довольно стабильной и богатой, чтобы позволить экспериментальные области вроде нашего кластера.
Итог
Описанный мною опыт — это нечто большее, чем пересказ нашего опыта, который может быть полезен тем, кто попробует повторить его. Во многом это рассуждения на тему современного положения дел на рынке enterprise-процессов.
Практики — как еда: для молодых стартапов требуется рацион для быстрого роста, для взрослых продуктов — для поддержания массы. Учитывая скорость нашего развития, мы не нашли подходящих для себя практик среди предлагаемых в компании (и вне её) и начали «готовить сами». Мы совершенно сознательно пошли по пути развития собственных процессов, при котором важную роль играют не скорость разработки, а скорость экспериментов при неизменном фокусе на продукте.
Какой бы путь вы ни выбрали — я желаю, чтобы у вашего продукта всё получилось и ваши команды получали удовольствие от того, что они делают.
