Кейсы роста
Epic Growth
1562

Как управляет процессами Микаэл Ян: ноль очередей, 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

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

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

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Epic Growth", "author_type": "self", "tags": [], "comments": 8, "likes": 9, "favorites": 53, "is_advertisement": false, "subsite_label": "growth", "id": 114418, "is_wide": false, "is_ugc": true, "date": "Mon, 23 Mar 2020 13:26:37 +0300", "is_special": false }
0
8 комментариев
Популярные
По порядку
Написать комментарий...
0

"готовили и делали ресерч, дискавери, готовили бэклог, чтобы они были в состоянии ready"

Первые слова не английские, конечно. 

Ответить

Комментарий удален

0

Не знал до этого комментария, кто этот парень, полез в поиск: «Сервис ManyChat Микаэла Яна, сына основателя ABBYY...» - и дальше половина выдачи такая же.

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

Ответить
0

Там папаша очень активно руку приложил в успех сыночка. От перевоза в Америку и денежек, до связей и прочих полезных бонусов. Поверьте, у вас бы были деньги, вы бы тоже какой-нибудь сайт запустили. Человек хороший, только не дано ему стартаперство. Зазубрил какие-то слова, произносит без понимания их значения.

Ответить
–2

Это все правда, только вот это его единственное достижение - быть сыном кого-то. И эта статья это доказывает.

Ответить
0

Вас ни как не угодить, если сын тратит отцовские деньги на лево, говорите что он мажорчик, сам ничего значительного не сделал. Добивается успеха - все благодаря отцу.

Ответить
–1

Я не говорою, что это плохо, как и то, что плохо быть "мажорчиком". Конкретно здесь человек и его бизнес - пустышка. Может хоть старается, за это можно уважать, но разумеется, перенимать подобный опыт я бы не стал.

Ответить
–2

"в какой-то момент мы смотрим, а у нас уже компонентные команды: есть фронтенд, бэкенд, отделы дизайна и продукта."

С самого начала какая-то непонятка.

Я вот в офис Яндекса прихожу, смотрю, а там команды есть свои, делают что-то, создают. Ну, я, конечно, к этому отношения никакого не имею, откуда они там взялись, хер его знает. 

Ответить

Прямой эфир