Всем привет!

На связи Дима Абрамов.

Последние полтора года, я — директор по продукту Kaiten. Это такой инструмент для визуализации рабочих процессов в компании (aka система управления задачами/проектами, aka таск трекер). Несмотря на обилие конкурентов на рынке, на данный момент, мы единственный продукт, который позволяет увидеть все рабочие процессы в компании в одном окне браузера. Это круто и моя роль тут — сделать, чтобы Кайтен вырос в 10 раз за год.

Помимо этого, я активно продвигаю в мир Канбан-метод, немножко обучаю Скраму и прочим Agile-подходам. С 2014 по 2018 год был ко-фаундером и CPO в успешном AdTech стартапе. Провожу совместно с Юрой Агеевым ProductTank Moscow.

Вторая неделя онлайн-программы “Product Mindset” посвящена работе с командой.

Хочу сразу сделать важную оговорку: если вы хотите запустить новый продукт, в мамином гараже, с двумя своими друзьями/ко-фаундерами, то прямо сейчас вам не столь важен навык работы с командой. Три человека могут быть командой без процессов, без подходов, просто писать код. Однако, если вы планируете расти или уже сейчас работает или хотите работать в компании, где людей уже больше трёх — тогда эти навыки резко становятся необходимыми.

В этом модуле, мы будем учиться:

• Определять стадию развития продукта
• Подбирать способ организации процесса работы в зависимости от стадии
• Визуализировать процесс, чтобы сделать его управляемым
• Запустить оптимизацию ваших процессов, чтобы быстрее расти, зарабатывать деньги, выходить на IPO

Поехали!

---

Определяем стадию развития продукта

Зачем?

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

Суть

Есть такая концепция Жизненный Цикл Стартапа, по сути он применим не только к стартапам, но и к любым продуктам. Жизненный цикл описывает стадии, через которые проходит стартап, на пути от идеи продукта до взрослого бизнеса. Вся концепция умещается на одной картинке.

Я не буду подробно описывать все стадии, это не тема этой недели, пройдусь кратко.

Сначала вы ищите проблему рынка, ищете кого-то кто ищет решения этой проблемы, потом вы делаете MVP, чтобы получить с клиента деньги (что является единственным подтверждением того, что ваш продукт кому-то нужен).

После того, как с помощью MVP вы поняли, что хоть кто-то да интересуется вашим продуктам — вы начинаете тестировать много-много гипотез, чтобы найти Product / Market Fit (PMF), состояние, когда вы поняли что есть определенный рынок, где клиенты хотят платить вам, за ваш продукт.

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

После нахождения Channel / Product Fit, вы фокусируетесь на росте, тестируете новые и новые каналы, оптимизируете их, и быстро-быстро растете, пока не захватываете большую долю рынка и не выходите на определенное плато, когда рост замедляется уже от того, что емкость рынка исчерпана.

Каждая стадия жизненного цикла может стать последней. Об этом надо просто помнить, но особо не париться 😉

Про работу на каждой стадии можно написать и прочитать кучу книг, но нам важно не это. Чтобы определить как лучше организовать процесс — важно понимать на чем фокусируется каждая стадия, а именно:

• Стадии до достижения Product / Market Fit — это стадии, где важна только скорость тестирования гипотез. Нам не важно качество продукта, нам не важна мощность технологии, нам не важен бренд, нам не важен маркетинг, нам нужно быстро тестировать гипотезы, пока не найдем PMF. Если на этой стадии у вас 20 разработчиков, 10 маркетологов, 20 дизайнеров и свой самолет – есть подозрение, что вы что-то делаете не так.

Тестирование гипотез — это получение знания, мы фокусируемся на скорости получения знания

• Начиная с достижения PMF, у нас появляется две цели:
  • Тестировать новые гипотезы, чтобы получать знания о том, как расти, привлекать новых пользователей, удерживать старых и тд
  • Реализовывать то, что мы узнали, тестируя гипотезы, чтобы обеспечить клиентов продуктом хорошего качества.
• В процессе роста и с наступлением Maturity, компания может поделиться на большое количество команд, у каждой из которых будет своя цель, но это уже сильно зависит от структуры, сегодня мы обсудим базовые принципы.

Процессы, целью которых является получение знания — мы будем называть Discovery, процессы, целью которых является создание продукта хорошего качества — Delivery, таким образом, мы выяснили, что до нахождения PMF у нас есть только Discovery процесс, а дальше — Discovery и Delivery.

Итог

Мы должны знать стадию развития нашего продукта и основные цели, на которых должна фокусироваться наша команда(ы).

Что почитать?

5 PHASES OF THE STARTUP LIFECYCLE: MORGAN BROWN ON WHAT IT TAKES TO GROW A STARTUP

Выбираем способ организации процессов

Зачем?

Правильная организация рабочих процессов, позволит нашей команде сфокусироваться на правильных целях.

Суть

Есть много разных фреймворков и подходов к организации работы, самые известные и модные на сегодняшний день: Scrum и Kanban-метод. Дабы не устраивать холивары, сразу скажу: Скрам и Канбан-метод не конкуренты, помогают достигать разных задач и вообще не противоречат друг другу. Вы можете применить Канбан-метод, чтобы оптимизировать вашу работу по скраму (круто, да?).

Скрам — организационный фреймворк (aka каркас), созданный для организации командной работы над продуктом.

Kanban-метод — это метод визуализации и оптимизации любого рабочего процесса для достижения Fit-for-Purpose, с помощью математики и научного подхода.

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

Так как суть Канбан-метода в оптимизации любого процесса — вы можете использовать его хоть завтра. Какой бы у вас процесс ни был, вы можете начать его оптимизировать. Суть Скрама — в регулярных поставках инкремента продукта с заданым уровнем качества, которые в свою очередь подразумевают два момента: у вас есть продукт, который надо инкрементить и вы можете продумать цель по инкременту продукта, хотя бы на неделю.

Если вспомнить выводы из предыдущего абзаца, можно заметить, что Скрам отлично подходит к ситуациям, когда одной из целей команды является “Реализовывать то, что мы узнали, тестируя гипотезы, чтобы обеспечить клиентов продуктом хорошего качества”, то есть к Delivery-процессу.

• Минутка холивара про области применимости Скрама

Задача Канбан-метода в случае Discovery процесса — оптимизировать процесс таким образом, чтобы максимально быстро тестировать каждую гипотезу, что отлично совпадает с нашей целью.

Может показаться, что я однозначно утверждаю: Discovery — Канбан, Delivery — Скрам, но это не так. В Кайтене, например, оба процесса организованы с помощью Канбан-метода и у нас никогда не было Скрама, а в моей предыдущей команде — везде был скрам. Всё, что нужно понимать, это то, что у Скрама есть серьезные ограничения в применении, потому что это полноценный каркас, например, вы не можете работать по скраму, если у вас часть работы отдается на аутсорс. Уважайте создателей подхода и не называйте Скрамом процесс, который им не является, это усложнит всем жизнь.

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

• Визуализируйте рабочие процессы
• Ограничьте одновременно выполняемую работу
• Управляйте потоком работы
• Сделайте политики явными
• Внедрите циклы обратной связи
• Улучшайте и эволюционируйте ваш процесс с помощью экспериментов

Для начала, хватит визуализации и ограничений — прирост в производительности вы уже ощутите (проверено на сотнях команд).

Итог

Для организации работы с помощью какого-то фреймворка – надо знать области его применимости. Используйте Scrum, если вы работаете в Delivery процессе и, если он подходит по критериям самого Scrum. Используйте Kanban-метод, для того, чтобы запустить работу над процессами, особенно в Discovery стадиях.

Во всех частных случаях — рассматривайте разные варианты и выбирайте фреймворк в зависимости от ситуации, серебряной пули не существует.

Почитать

Во-первых, читайте первоисточники по инструментам, а именно гайды (есть на русском и английском, но лучше всегда оригинал):

The Scrum Guide

КРАТКОЕ РУКОВОДСТВО ПО КАНБАНУ

Ну, а для тех, кто хочет углубится в тему, можно обратиться к книгам:

• Scrum. Jeff Sutherland (перевод не очень, лучше оригинал)
• Kanban. David Andersen
• Kanban from inside. Mike Burrows

Книг больше, но дальше уже можете лично у меня спросить, в зависимости от темы.

Визуализируем процесс

Зачем?

Seeing is believing. Какой бы фреймворк мы не выбрали, нам нужно видеть работу, чтобы ей управлять. Большая проблема, с которой человечество столкнулось в 20 веке — появление интелектуальной работы (наша с вами). Интелектуальную работу НЕ ВИДНО, чтобы ее контролировать — надо сделать её видимой.

Суть

Самый простой способ визуализировать рабочий процесс – использовать доски и карточки. Это можно делать в офисе на стене с помощью стикеров, либо в любом онлайн инструменте, типа Trello или Kaiten.

Чтобы смоделировать доски, надо выяснить какие стадии есть у процесса и какая единица работы их проходит, например, у Discovery единицей работы может являться гипотеза, которая проходит стадии “формулирование”, “проведение эксперимента”, “сбор данных”, “анализ данных”, “готово”. Последнюю колонку, можно разделить на две подколонки “подтверждена” и “опровергнута”, чтобы сразу видеть соотношение (и радоваться, сколько мы знаем неработающих гипотез 😉 ).

Вот пример Discovery процесса в Кайтене. Lead Time — среднее время работы по гипотезе от старта и до вывода, основная метрика, которую надо сокращать.

Про доски, надо помнить несколько best practice:

• У человека из команды, в идеале должна быть ровно одна доска, на которой он смотрит на задачи, которые ему надо делать. Если досок несколько и на всех моя работа — мне приходится выбирать какая задача важнее, это когнитивная нагрузка + я просто выберу более приятную. В рамках одной доски мне сразу однозначно ясно, какая задача самая важная.
• Задача не должна двигаться по доске влево (например Разработка → Тестирование → Разработка) Нахождение карточки в определенной колонке показывает нам, что карточка прошла все предыдущие стадии, мы уже вложили в нее ресурсы и значит завершить её важнее, чем задачу левее. Если мы будем жонглировать задачами туда обратно — мы будем путаться и фокусироваться не на доведении задач до конца, а на жонглировании ими. Вместо этого, лучше использовать блокировки (на физической доске можно использовать красный стикер), блокировка покажет нам, что мы не можем передвинуть задачу в Готово, потому что тестировщик нашел баг.
• По доске должно быть понятно, что происходит. Не надо проектировать “идеальный процесс”, визуализируйте для начала то, что есть, тогда вы сможете контролировать ситуацию и внедрять изменения постепенно.

После того, как вы отобразили свои процессы на досках — вы можете принимать информированные решения и быстро видеть их результаты на досках, а также в метриках, если вы решите их собирать.

Итог

После того, как вы отобразили свои процессы на досках — вы можете принимать информированные решения и быстро видеть их результаты на досках, а также в метриках, если вы решите их собирать (мы же продакты, мы любим метрики).

Почитать или посмотреть

Более подробно про визуализацию я рассказывал на прошлом ProductSense, вот запись

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

Начинаем оптимизировать наши процессы

Зачем?

Ну мы же зачем-то делали все это?)))

Чтобы быть лидерами рынка, мы должны работать быстрее, эффективнее, правильнее конкурентов, так давайте наши процессы нам в этом помогут.

Как?

Для того, чтобы улучшать наши рабочие процессы, нам понадобятся:

• Петли обратной связи, а если по простому — регулярные встречи команды, направленные на разные аспекты процесса
• Ограничения, которые помогут нам фокусироваться на правильных вещах
• Правила, которые позволят нам сократить когнитивную нагрузку, и больше времени уделять полезной работе
• Метрики, чтобы эффективность отслеживать

Встречи

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

Ежедневная синхронизация (aka стендап, aka дейли скрам, aka летучка) — встреча с одной маленькой целью “синхронизироваться всей командой”, то есть узнать кто чем занят, как двигаются задачи, где проблемы.

Самый стандартный вариант дейли — это ответ каждым человеком на три вопроса “Что я делал вчера?”, “Что я буду делать сегодня?”, “Какие я вижу преграды/проблемы?”.

Я рекомендую альтернативный сценарий встречи, когда вместо того, чтобы идти по людям, мы идем по задачам справа налево и задаем вопрос “Что нам мешает передвинуть эту карточку в следующий столбец прямо сейчас?”. Такой вопрос отлично фокусирует команду на доведении задач до конца.

Ретроспектива — регулярная встреча, на которой мы абстрагируемся от текущих задач и смотрим глобально на весь наш процесс работы. Наша цель — найти способы улучшить процесс, чтобы он был более эффективен. Здесь самое время погенерить идеи для изменения процесса и придумать эксперименты, чтобы эти идеи проверить.

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

Ограничения

Тут все просто, есть такая штука “Закон Литтла”, он был выведен еще в прошлом веке и относился к массовому обслуживанию (например очереди в магазине). Однако он довольно универсален. Переводя на человеческий язык, суть закон Литтла: Чем меньше задач одновременно в работе, тем быстрее делается каждая задача. Л — Логика, но почему-то никто не верит =(

Чтобы применить закон Литтла и получить от него пользу — достаточно ограничивать количество карточек в каждой рабочей колонке, а также во всех промежуточных очередях, если они есть. Тогда вся команда, вместо того, чтобы начинать сотню новых клёвых задач — будет сначала завершать текущие.

Правила

Правила в каждой команде свои, но одно я порекомендую

Самая важная задача та, которая висит максимально близко к колонке “Готово” (правее)

Я только что убил необходимость приоритезировать начатую работу 😉

Метрики

Чтобы понимать, оптимизируете ли вы процесс или ухудшаете, нужны какие-то метрики. Самые простые и полезные — это Lead Time (время от начала работы по карточке до её завершения) и Эффективность потока (отношение времени непосредственной работы по карточке, ко всему времени Lead Time)

Если средний Lead Time помогает вам отслеживать скорость и оценивать сроки, то эффективность потока, открывает огромные возможности по оптимизации простоев. Например, довольно стандартная эффективность потока у команд, которые не заморачиваются процессами — ~10%, то есть из 10 дней за которые команда закрывает задачу — только 1 день тратится на реальную работу, а остальные 9 — это ожидание в очередях, блокировки и тд, ужасно.

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

Итог

Наладив процесс с помощью ограничений и правил, вы можете регулярно улучшать его, используя петли обратной связи (регулярные встречи) и анализируя метрики.

Почитать

Цель. Эльяху Голдратт — если вдруг еще не читали, эта книжка must-read по теории ограничений

Полезная статья про еще один инструмент работы с метриками процесса — кумулятивную диаграмму потока: Накопительная диаграмма потока

Как оценивать задачи, используя только цифры Lead Time: Почему команды неправильно оценивают сроки выполнения задач, и как с этим бороться

Немного подробнее, про процесс именно в молодом продукте/стартапе: Step-By-Step. Как наладить устойчивый рабочий процесс в стартапе

Домашнее задание!

Много букв написал, надо и задание дать какое-то.

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

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

Задание #1. Определяем стадию развития продукта

Тип: персональное

Это будет набор кейсов, в котором вам будут предложены разные описания продуктов, а вам надо будет решить, на какой стадии развития он находится. В некоторых кейсах, данных для определения может быть недостаточно (если вы так считаете, то прямо так в ответе можно и написать).

1. Онлайн школа английского языка, привлекла несколько раундов инвестиций, растёт каждый год в три раза по выручке, клиенты с высокой вероятностью рекомендуют школу друзьям. В штате 100 разработчиков.
2. Мобильный крипто-кошелек, провел ICO и поднял на нем $275млн, приложение скачали 10 миллионов раз. В компании запущен маркетинг, в штате 70 разработчиков.
3. Система управления предприятием, сложный b2b продукт, средний чек 1000$ в месяц. Есть первые 100 клиентов, которые стабильно платят и не уходят за год и дольше. В штате 5 человек, инвестиций не привлекали. Окупаются.
4. Сервис уборок в доме. Провели первые 50 уборок, найдя клиентов на фб. Привлекли seed-round от акселератора. 5 человек в штате.

Срок: 2 марта, 23:59
Форма сдачи: https://productsense.typeform.com/to/dSbb8m

Задание #2. Визуализируем рабочие процессы

Тип: командное

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

Вы можете создавать доски в любой системе или, вообще, нарисовать. Но самый простой вариант — создать аккаунт на команду в Кайтене и сконфигурировать доски там. Триал период на 3 недели позволит вам абсолютно бесплатно выполнить задание, а если команда решит вести внутреннее взаимодействие там, просто напишите нам в чат, Product Mindset и мы продлим триал до конца программы.

Срок: 2 марта, 23:59
Формат сдачи: https://productsense.typeform.com/to/kyej3O (нужно будет прислать ссылки на скриншоты/картинки досок по двум кейсам)

Кейс 1

Продуктовый b2c стартап на стадии роста.

Growth team: Продакт + Маркетолог + Дизайнер (Тестируют гипотезы роста, ищут гроус-хаки, пытаются сделать “клюшку” из графика количества пользователей)

Retention team: Продакт + Аналитик + 2 UX Дизайнера (Сфокусированы на Retention, стараются сделать так, чтобы пользователи долго не уходили из продукта, придумывают новые фичи, валидируют и отдают в разработку, если они нужны для ретеншена)

Development team: 5 разработчиков + 3 тестировщика + 1 админ (Разрабатывают фичи, которые им накидали продуктовые команды, занимаются техническим улучшением системы, фиксят баги. Работают по Скраму)

Кейс 2

Взрослый b2b продукт

Core-product team: 3 Продакта (у каждого своя целевая метрика) и 2 аналитика работают над основным продуктом

Growth team: продакт + аналитик (ищет новые пути развития)

Разработка: 50 человек, разбиты на 5 команд (им прилетают фичи от Core продактов и от тех поддержки)

Дизайн агентство, на аутсорсе обслуживает и Core-product team, и Growth team. Мы не знаем кто там и сколько людей, это аутсорсеры, ставишь задачу делают

Задание #3. Решение кейсов

Тип: командное

Задание сложное и выходит за рамки теории, которую я описал, однако хороший продакт должен уметь взаимодействовать с командой. В этом задании вам будут даны ситуации, в которых есть какая-то командная проблема. Вам надо придумать, что вы сделаете в этих ситуациях, чтоб решить конфликт, наладить процесс и т.д. Решать такие кейсы командой — еще сложнее, вам понадобится умение договариваться и искать компромиссы.

Идеально правильных ответов нету, но есть точно неправильные. Я разберу частые ошибки на вебинаре после этой недели.

Срок: 2 марта, 23:59
Формат сдачи: https://productsense.typeform.com/to/XPIfqz (по каждому кейсу командой нужно будет сформулировать описание вашего дальнейшего поведения на 500-1000 символов)

Кейс 1

Вы руководите продуктовой командой. Последнее время, вы заметили, что разработка делает фичи всё дольше и дольше. Вы решили посмотреть на статистику и видите такую картину:

На графике каждая область — количество задач в одной из колонок (внизу легенда).

Другие графики вам недоступны, на доске разработки вы действительно видите карточки в работе, вас никто не обманывает, но всё таки сроки все длиннее.

Что будете делать?

Кейс 2

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

Три месяца назад вы ходили к тимлиду разработки и говорили, что такое количество ошибок — это плохо, он сказал, что разберется, однако видимо ничего не меняется. Вы не программист и сами не знаете в чем там дело, однако подозреваете, что программисты просто “пилят фичи”, забив на техническое совершенство.

Как будете решать проблему?

Кейс 3

Вы руководитель “команды роста” стартапа. Цель команды — искать крутые способы резко вырастить показатели продукта. Вы тестируете много разных гипотез, однако последние несколько у вас никаких прорывов, гипотезы не подтверждаются, настроение в команде паршивое.

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

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

Как поступите?

Задание #4*. Тест по теории Scrum и Kanban

Тип: персональное

Задание со звездочкой, потому что я мало что написал про сами подходы, чтобы качественно ответить на вопросы, вам нужно будет изучить материал самостоятельно, однако гарантирую, что на вопросы из теста можно будет ответить только на базе гайдов (скрам-гайд и канбан-гайд).

Срок: 2 марта, 23:59
Формат сдачи: прохождение теста (будет в четверг, 28 февраля)

---

И еще разок, от организаторов

СРОК СДАЧИ ЗАДАНИЙ: 2 марта, 23:59