Как управляет процессами Микаэл Ян: ноль очередей, Scrum, кросс-функциональные команды на 100 человек

В Epic-подкасте номер 10 Микаэл Ян (кофаундер и СЕО ManyChat) рассказал, какие принципы помогли построить крутую и эффективную продуктовую команду. Конечно, не сразу: построили функциональные команды по Scrum, поделились на кросс-функциональные, внедрили методологию LeSS и переросли её.

Мы начинали ManyChat вдвоем. Потом появилась полноценная команда, спринты, всё по классике Scrum. Потом пришли ещё 10 человек, 15... 20… в какой-то момент мы смотрим, а у нас уже компонентные команды: есть фронтенд, бэкенд, отделы дизайна и продукта.

Time to market, время от идеи до релиза выросло, мне даже стыдно говорить до каких цифр: 1,5–2 месяца… Да, практически «Сбербанк». Но для больших команд это приемлемо, для 25 человек — нет. Но это недолго продлилось. Мы решили, что всё рушим, переформатируем менеджеров, которые оказались узкими горлышками.

Увольнять никого не пришлось, мы объяснили менеджерам, что сейчас у нас не будет никакого фронтендовского одеяла, у нас просто все, каждый, фронты будут сидеть в кросс-функциональных командах, там будет менторство, но это не будет прямое начальство. И никто не уволился, все остались.

Когда у тебя уже много команд, ты не можешь делать единый Scrum, поэтому мы внедряли large skills Scrum.

После внедрения мы выпустили все недоделки, которые копили не один месяц. Наше комьюнити, наши пользователи даже немножко офигели, потому что каждую неделю мы какие-то major штуки релизили. Это было очень классно.

Но в какой-то момент кросс-функциональная команда начала расслаиваться на две части. Были продакты и дизайнеры, которые готовили и делали ресерч, дискавери, готовили бэклог, чтобы они были в состоянии ready. И была часть команды, которая занималась деливери.

Всё стало превращаться в конвейер, потому что один спринт — команда занимается определением, второй спринт — имплементацией. И вроде бы команда одна и та же, но в процессе спринта она делает две разные вещи. А это во многом и противоречит философии того, чтобы всей командой накидывались на задачу и были доступны.

Чем это плохо? Тем, что вся задержка возникает в очередях. Все работали, была полная загрузка ресурсов, но у всех не хватило времени. И Scrum с этим борется. Ты перестаешь думать категориями утилизации ресурсов, то, что все должны работать каждую минуту. И начинаешь думать над тем, чтобы донести ценность пользователю.

А это во многом значит, что какие-то люди в какой-то момент не будут работать. И главной их задачей будет в этот момент — быть доступными.

Откуда идёт конвейерная идея? Она идет из идеалистического представления, что у тебя задача идет сквозь предсказуемый этап разработки. Сначала продакт определил задачу, потом дизайнер её подизайнил, ничего не спрашивая у продакта и не согласуя ни с кем другим.

Он ее дизайн и сделал проект. Все там сразу идеально, никто к нему не вернется за доработками. Потом это взял в работу фронт или бэк. Но такого никогда не бывает!

Как только у тебя одна из этих компетенций недоступна, у тебя возникает очередь. Человек думает: «Ага, задача стоит, я возьму что-нибудь ещё. У меня свой стек задач. Мне же нужно быть загруженным. Я ответственный член команды, я хочу как можно лучше приложить свои силы».

И он начинает работать над следующей задачей. Он занят. Другому человеку нужна помощь, а первый уже не может сразу подойти. У него кладется задача в стек. И образуется пробка. Каждый загружен на 100% и ничего не делается.

Бывало такое, что ты едешь, и в какой-то момент встаешь в пробку, ползешь и ползешь. Полчаса ползешь, 40 минут, час и думаешь, где же эта перевернутая фура, где эта авария, где эта стройка, которая сократила все до одной полосы, что мы так долго стоим? И потом в какой-то момент все просто начинают ехать. И ты думаешь: «Откуда образовалась пробка?»

Эта пробка возникает из-за слишком большой концентрации машин. Кто-то начинает перестраиваться, и все начинают оттормаживаться. Если с вертолета посмотреть на то, как идет пробка, то морда пробки все время отъезжает, а сзади хвост достраивается.

Почему в Америке на многих шоссе есть рамповые светофоры, которые работают по 1–3 секунде? Зачем 3 секунды держать машину на въезде? А они считают с помощью датчиков, сколько машин на дороге и контролируют задержку, чтобы держать правильную концентрацию машин на дороге.

Представь, что твои задачи — это машины, а полосы — это люди. Если поток машин-задач плотный и ты попробуешь передать задачу на другую полосу (другому человеку), то эта полоса встанет. И потом происходит коллапс на всём шоссе.

Почему Scrum за максимальную кросс-функциональность? Когда две функции может исполнить один человек, то появляется вариабельность, можно не в эту полосу, а в другую перестроиться.

Самая быстрая разработка там, где человек знает, что он хочет сделать, знает, какой ему нужен дизайн, знает все необходимые для этого инструменты — у него ноль очередей. По той же причине все хотят разработчика, который в случае чего может и дизайн подкорректировать в Figma и еще какие-то простые вещи сделать.

Фронт очень сильно пересекается с дизайном, если что-то не доделано, ему не нужно писать дизайнеру: «Слушай, ты точно уверен, что у тебя там было 10 пикселей? У нас по системе 15…». Ты послал это сообщение, а дизайнер на ланче, он пришел через час, продолжил свою задачу, через 3 часа из flow вынырнул, посмотрел сообщение от разработчика — в итоге из-за 10 пикселей 4 часа задача простояла в очереди.

Алексей Писаревский (СЕО Mobio): мне кажется, что в агентстве такую штуку построить нереально. В целом спринты, ретроспективы работают. Это я и в личной жизни применяю активно, и в команде. Садишься, разбираешь ошибки. И в том числе учу ребят их правильно разбирать. В общем, точечно какие-то практики мы берем из этого всего. Но клиентский бизнес сильно отличается от продуктового.

Больше про рост продуктов и growth-процессы — в Telegram-канале Epic Growth Channel.