Расстрелять нельзя помиловать: собираем продуктовую команду по методу Сталина

Привет, на связи Аспро. Разрабатываем готовые сайты на 1С-Битрикс, но сейчас не об этом. В начале года мы, как и многие IT-компании в свое время, столкнулись с проблемой. Из года в год растет стоимость разработки — пользователи требуют большего, поэтому технологии становятся сложнее. Как следствие, увеличиваются срок разработки и затраты: зарплаты, стоимость ПО, рекламные бюджеты. А вот прибыль расти не спешит.

На 2021 год мы поставили сверхцель — выпустить 10 продуктов. Ведь так мы заработаем много денег. А на них можно купить крутые штуки, вроде лошади или трех наборов Lego по акции 2+1.

Логика была простая: в 2020 году мы выпустили 1 решение и заработали денег. Если в 2021 году доведем до релиза 10 проектов, то заработаем 10 денег. Чистая математика, ничего личного, просто бизнес.

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

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

Так образовалось несколько схожих в разработке продуктов, что позволило применить метод Сталина. Суть в том, чтобы дать идентичную задачу нескольким командам и отслеживать их прогресс на разных стадиях. При этом в группах не должно быть «общих» сотрудников, только куратор. Работают команды обособленно. На самом деле, многие используют этот метод, просто не знают, что он так называется.

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

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

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

Мы предложили ребятам самостоятельно провести анализ рынка и продумать функционал для новых продуктов. Так у всех был шанс проявить себя и примерить новые роли. Затем провели конкурс, по итогам которого сформировались две продуктовые команды по 4 человека: продакт-менеджер, маркетолог, дизайнер и программист.

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

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

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

План был такой:

К сожалению, произошло недопонимание: вместо «УЛОЖИТЬСЯ В СРОК» команды почему-то услышали «План разработки носит сугубо рекомендательный характер». Но если без шуток, то мы сильно переоценили продуктивность сотрудников в сверхурочное время. Ошибку увидели, ошибку учли.

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

Не все команды в полном составе дошли до финальной черты в 100 установок. Кто-то оказался не готов к работе в проектных командах. Им пришлось сказать «Вы самое слабое звено, прощайте». И коллеги просто вернулись к привычным обязанностям.

Ни для кого не секрет, что для бизнеса время — деньги. То, что разработка заняла у нас вдвое больше запланированного — плохой результат. Ошибок было много, но мы пересмотрели рабочие процессы и отметили их в базе знаний для следующих команд. Прозрачность метода помогла определить сильные и слабые стороны работников и «узкие места» производственного процесса.

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

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

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

Но некоторые удачные решения мы все же сохранили:

Увы, наш эксперимент с дизайнером-продуктологом не удался (ну кто бы мог подумать?). Интерес сотрудника угас, а должной отдачи мы не получили. Да и вообще все участники команд очень устали от проекта и друг от друга. Ребята как будто прошли боевые действия. У некоторых до сих пор ПТСР.

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

Мы не стали принципиально менять подход и чинить то, что не сломано. Лишь немного поправили процесс работы команд:

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

Лежат ли они на поверхности? Да. Хотели бы мы их знать до начала наших приключений? Тоже да.

Отмечайте трудности, проводите анализ и в итоге вы придете к комфортному для себя формату. Вернемся, когда еще наломаем дров (: