Стартап: 5 человек, продукт полезен, маркетинг прекрасен, команда сворачивает горы, получает инвестиции и масштабируется. Тот же стартап через год: 50 человек, сроки по фичам в огне, маркетинг в огне, все выгорают. Разберёмся в проблемах и решениях, а также дадим проверенный инструмент.

Дмитрий Васин, Аккредитованный тренер от Kanban University (USA ,Seattle)
Сертифицированный Scrum-мастер.

«Компания после масштабирования — это качественно другая компания», — Дмитрий Васин.

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

Игнорировать проблему. Работать как раньше уже не получается, а новых знаний ещё нет. Ответы на вопросы откладывают и потом вовсе игнорируют. Сроки выхода релизов ползут, время на обсуждения задач тоже. Команда не выполняет план и не может прогнозировать результат. Появляются все больше «костылей», что со временем снижает скорость разработки.

Управлять людьми, а не процессами. Управление интеллектуальным трудом сильно отличается от управления материальным производством.  

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

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

Ниже рассмотрим решения, которые сработали на примере компании «Инвитро».

Описываем взаимодействия в компании: кто за что отвечает

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

Как и во многих технологических компаниях, в «Инвитро» процесс разработки продукта был разделён на две основные части: этап исследования и этап создания. 

Этап исследования в английской терминологии называют discovery.  Здесь идёт изучение проблемы, которую необходимо решить. Команда фокусируется на исследовании рынка, конкурентов, пользователей, создании прототипов и тестировании гипотез. Цель этапа — определить, что необходимо создать и какие функции должны быть включены в продукт, чтобы удовлетворить потребности рынка. За это в «Инвитро» отвечал департамент маркетинга.

Этап непосредственного создания продукта называют delivery. На этом этапе команда фокусируется на создании, тестировании и запуске продукта. Цель этапа — продукт, который полностью соответствует требованиям, выявленным на этапе исследования, и который будет успешно использоваться. За это в «Инвитро» отвечал IT-департамент.

Разделение процесса разработки продукта на «исследование» и «создание» помогает повысить вероятность успешного запуска. Каждая команда больше сосредоточена на ключевых аспектах своего этапа и  лучше управляет рисками. Это уменьшает количество исправлений и изменений на более поздних этапах разработки.

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

Недовольный маркетинг

Ищем и собираем недовольства команды и сбои системы

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

Далее самые популярные темы, которые вызывают конфликты в команде. В «Инвитро» мы столкнулись со всеми:

Маркетинг недоволен разработкой:

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

Команда разработки недовольна маркетингом:

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


Выстраиваем процессы взаимодействий заново

Система эффективна тогда, когда мы нашли её ключевое ограничение и можем им управлять. Это блестяще описано в теории ограничений Голдратта. 

Мы же на практике сделали следующее: вернулись к первому шагу и описали, какой мы хотим видеть свою систему.

​​Маркетинг бесконечно генерирует фичи. Фонтан идей — это пример дивергентного мышления, творчество мы поощряем. Но чтобы от творчества была польза, нужно добавить конвергентное мышление: считать пользу, приоритизировать, отсекать лишнее.

Ранее команда разработки получали задачи от разных менеджеров, по разным каналам:

  • по рабочему телефону;
  • по корпоративной почте;
  • через сообщения в личных мессенджерах;
  • устно в коридоре офиса;
  • в баг-трекере.

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

Вспоминаем ошибку №2 — работаем с процессами, а не людьми. 

Мы изменили процессы коммуникации и добавили новые роли: аналитик со стороны разработки и продакт-менеджер со стороны маркетинга. 

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

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

Таким образом, продакт и аналитик фильтровали задачи по тому, какую ценность они несут и сколько ресурсов требуют. Это помогло обеим командам discovery и delivery выстроить понятные коммуникации и спокойный рабочий процесс. 

Компания смогла адаптироваться к резкому росту и выйти на новый уровень

Внедрение организационных изменений заняло 8 месяцев. За это время мы жёстко упорядочили работу и при этом сохранили творческую независимость специалистов. Сроки выхода новых фич на рынок сократилась с 98 до 26 дней. Атмосфера внутри команды перестала быть стрессовой: сотрудники стали проводить больше времени вместе вне работы.

Изменения в организации отразились и на продукте: посещаемость нового сайта увеличилась с 2 млн до 10 млн в месяц, а выручка по цифровым каналам увеличилась в 68 раз.

Ресурсы, которые помогут разобраться в теории организационных изменений:

«Проектирование социальных систем в меняющемся мире» — книга профессора лингвистики Генриха Банати, где он впервые описал модель дивергенции-конвергенции;

«Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию» — книга Уильяма Детмера о теории ограничений физика Элияху Голдратта. Теория базируется на поиске ограничений в системах и влиянии на них.