Пару лет назад мне довелось принять участие в переходе из функциональной модели разработки в продуктовую. На мой взгляд, переход неудачный, а потому полученный опыт имеет особенную ценность.
Я наблюдал эту трансформацию с позиции тимлида одной из платформенных команд, поэтому у меня была возможность видеть изменения самого процесса работы над проектом, что позволило мне понять причины возникших проблем, которые привели к провалу всей этой истории.
Я хочу описать получившуюся структуру команды с ее новыми характеристиками, которые стали причиной возникших трудностей, которые, в свою очередь, не позволили достичь поставленных целей.
Начну с вопроса, чем отличается платформенная модель от продуктовой?
Платформенная модель или функциональная - это классическая модель процесса разработки с функциональным разделением команд. В такой модели обычно есть один владелец продукта, один менеджер проекта и функциональные команды аналитиков, дизайна и разработки, например, Android, iOS, web frontend, backend. В каждой такой платформе есть один тимлид и несколько разработчиков. Т.е. каждая команда - это отдельная функция, которая обслуживает все продукты (части одного проекта).
Продуктовая модель или дивизионная - это модель, при которой деление ведется не по функциям, а по продуктам. Каждый продукт обладает всем необходимым для того, чтобы поддерживать свою работу, т.е. самостоятельно выполняет все необходимые функции. Такая продуктовая команда состоит из владельца продукта, дизайнера, QA, аналитика и разработчиков с каждой платформы, на которой этот продукт представлен. Т.е. каждая команда - это отдельный продукт, который представлен на всех платформах.
Лично я ничего не имею против этих моделей, каждая из них призвана решать свои задачи. Но модели должны адекватно подбираться к текущим условиям.
Начальные условия (дано)
У нас была классическая схема:
Менеджер | 1 |
Владелец продукта | 1 |
Команда дизайнеров | 3 |
Архитектор | 1 |
Команда QA | 7 |
Три группы разработки: Android, iOS, web | по 5-7 разработчиков в команде и одному тимлиду |
Все задачи от бизнеса аккумулировал и приносил в команду владелец продукта.
Процесс разработки: скрам (плюс/минус).
Трансформация
В один прекрасный день руководство компании собрало всех руководителей с целью презентовать новую структуру команды, к которой мы должны были прийти. Нам показывали красивые слайды и рассказывали, как мы здорово будем работать по новой схеме. Таких совещаний было довольно много.
Целевая схема трансформации:
Должны были быть сформированы пять продуктовых команд. Для этого уже приняли на работу соответствующее число владельцев продукта.
Сомнения?
Конечно! У команды было очень много вопросов.
Основной вопрос: Какую цель мы хотим достичь таким переходом?
Ответ: Устранить рассинхрон по платформам для новых фичей. Выделение продуктовых направлений должно было позволить выпускать фичу одновременно на всех платформах.
Комментарий: Да, у нас была проблема в том, что фичи выходили на платформах несинхронно. Бывало, что выход фичи на других платформах опаздывал на пару месяцев. Но на то были определенные причины: технические и ресурсные.
Главное сомнение: А точно нам подходит эта модель? Текущих ресурсов команды недостаточно, чтобы прийти к целевой схеме.
Ответ: Многие крупные компании успешно применяют эту модель (карго культ?!). Вопросы с ресурсами будем решать по ходу.
А дальше все просто:
Каждая команда должна была состоять из владельца продукта, платформенных разработчиков и техлида, который мог бы технически вести эту команду. Т.к. нужно было сформировать аж 5 команд, то мы тут же уперлись в ресурсы.
Какие решения нашел менеджмент:
Некоторых разработчиков поднять на уровень техлидов, тем самым уменьшив команду разработки еще на пять человек.
Оставшихся разработчиков распределить по командам. Те команды, которым не досталось разработчиков, должны были “шарить” их с другими командами.
Продуктовые команды должны были использовать общие ресурсы дизайнеров и QA.
В итоге получилось, что в каждой продуктовой команде было максимум по одному платформенному разработчику, а в некоторых командах были платформенные дыры без разработчиков, и такие команды вынуждены были одалживать разработчиков в других командах.
Все, хватит вопросов и критики, запускаемся…
Какие возникли проблемы
Все возникшие проблемы были следствием некоторых характеристик получившейся структуры. Я буду описывать характеристику и проблемы, которые из-за нее возникли:
1 Техлид продукта - вчерашний разработчик платформы.
Новоиспеченные техлиды по факту стали системными аналитиками. И им это не понравилось. И через пару месяцев они все захотели вернуться в разработку. Также ситуация осложнялась тем, что техлидами сделали молодых ребят, которые были уровня мидл-разработчик (плюс/минус), и им недоставало опыта для этой работы. К тому же позиция техлида подразумевает работу с людьми, а это не всем разработчикам подходит.
2 Один разработчик от платформы в команде
Bus-factor в команде стал критическим. Всего один человек. Отпуск, болезнь и целая платформа продукта встала.
Разработчики стали работать в одиночку. Некому провести код-ревью, не с кем обсудить какие-то детали проекта и т.д. А это оказывает негативное влияние на людей, привыкших работать в команде.
Скорость разработки продукта очень сильно снизилась. Если раньше, работая в платформенной команде, над фичами одного продукта могло работать несколько разработчиков, то теперь продуктовая команда должна рассчитывать только на силы одного разработчика.
3 Неправильно сформированные продукты
У двух из пяти продуктовых команд не было достаточно задач, чтобы непрерывно нагружать хотя бы одного платформенного разработчика. По этой причине разработчики в этой команде сильно скучали. Так как продукты были изолированы, тимлид больше не мог перераспределять ресурсы, планированием занимался сам владелец продукта. В результате одни разработчики маялись бездельем или делали какие-то мелкие скучные задачи, а другие очень долго делали свои фичи в одиночку.
Граница между продуктами была сильно размыта, поэтому часто возникали спорные ситуации, чья это проблема и кто должен ее решать. Из-за чего решение проблемы затягивалось на очень длительный срок. От этого сильно страдали клиенты.
4 Недостаток самостоятельных ресурсов у продуктов
Команды, у которых не было своих разработчиков, месяцами ждали реализации своих даже очень простых фичей. Опять же, из-за изолированности продуктов и нежелания владельцев коммуницировать друг с другом и делиться разработчиками. В общем, шаринг разработчиков не работал (недавно в книге Д. Рейнвотера “Как пасти котов” прочитал, что подобные матричные схемы для разработчиков недопустимы).
Конкуренция за общие ресурсы. Вообще в ИТ продуктовая модель пришла из бизнеса, а там давно известно, что такая модель ведет к конкуренции продуктов между собой. Есть интересная статья на Хабре про это. В моем случае, у продуктов не было своих дизайнеров и тестировщиков, и за эти ресурсы шла неприятная кулуарная борьба.
5 Отсутствие тимлида, как прослойки между менеджментом и разработкой
Хороший тимлид оберегает своих разработчиков практически от всех контактов с менеджерами. В получившейся схеме тимлида у команды не осталось, а разработчики были вынуждены общаться напрямую с владельцами продуктов, которые не были техническими специалистами. Это общение частенько проходило очень эмоционально. Двух разработчиков команда потеряла именно по этой причине.
Что в итоге
Получившаяся модель не смогла достичь поставленной цели. Платформы так и не смогли синхронизировать функционал. А продукты так и не стали самостоятельными.
В первые пару месяцев команда лишилась четырех разработчиков. А еще через некоторое время и сами зачинщики этой трансформации благополучно ушли в другую компанию реализовывать свои блестящие идеи там. Команде ничего не оставалось, как перестроиться в некую гибридную схему, чтобы хоть как-то сгладить выше описанные проблемы.
На мой взгляд, главная причина провала в том, что эта трансформация была искусственной. У команды не было естественных предпосылок для такой трансформации (физическое расширение команды и/или естественное формирование продуктов внутри проекта). Команда была небольшая и она нормально работала.
p.s. Сейчас мне уже кажется, что вся эта трансформация случилась, потому что кто-то просто преследовал свои личные корыстные цели.
Спасибо за внимание.
Подписывайтесь на мой канал в телеграмме @ar2code.
