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

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

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

Начну с вопроса, чем отличается платформенная модель от продуктовой?

Платформенная модель или функциональная - это классическая модель процесса разработки с функциональным разделением команд. В такой модели обычно есть один владелец продукта, один менеджер проекта и функциональные команды аналитиков, дизайна и разработки, например, Android, iOS, web frontend, backend. В каждой такой платформе есть один тимлид и несколько разработчиков. Т.е. каждая команда - это отдельная функция, которая обслуживает все продукты (части одного проекта).

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

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

Начальные условия (дано)

У нас была классическая схема:

Все задачи от бизнеса аккумулировал и приносил в команду владелец продукта.

Процесс разработки: скрам (плюс/минус).

Трансформация

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

Целевая схема трансформации:

Должны были быть сформированы пять продуктовых команд. Для этого уже приняли на работу соответствующее число владельцев продукта.

Сомнения?

Конечно! У команды было очень много вопросов.

Основной вопрос: Какую цель мы хотим достичь таким переходом?

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

Комментарий: Да, у нас была проблема в том, что фичи выходили на платформах несинхронно. Бывало, что выход фичи на других платформах опаздывал на пару месяцев. Но на то были определенные причины: технические и ресурсные. 

Главное сомнение: А точно нам подходит эта модель? Текущих ресурсов команды недостаточно, чтобы прийти к целевой схеме.

Ответ: Многие крупные компании успешно применяют эту модель (карго культ?!). Вопросы с ресурсами будем решать по ходу.

А дальше все просто:

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

Какие решения нашел менеджмент: 

1. Некоторых разработчиков поднять на уровень техлидов, тем самым уменьшив команду разработки еще на пять человек.

2. Оставшихся разработчиков распределить по командам. Те команды, которым не досталось разработчиков, должны были “шарить” их с другими командами. 

3. Продуктовые команды должны были использовать общие ресурсы дизайнеров и QA. 

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

Все, хватит вопросов и критики, запускаемся…

Какие возникли проблемы

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

1. Техлид продукта - вчерашний разработчик платформы

Новоиспеченные техлиды по факту стали системными аналитиками. И им это не понравилось. И через пару месяцев они все захотели вернуться в разработку. Также ситуация осложнялась тем, что техлидами сделали молодых ребят, которые были уровня мидл-разработчик (плюс/минус), и им недоставало опыта для этой работы. К тому же позиция техлида подразумевает работу с людьми, а это не всем разработчикам подходит.

2. Один разработчик от платформы в команде

1. Bus-factor в команде стал критическим. Всего один человек. Отпуск, болезнь и целая платформа продукта встала. 

2. Разработчики стали работать в одиночку. Некому провести код-ревью, не с кем обсудить какие-то детали проекта и т.д. А это оказывает негативное влияние на людей, привыкших работать в команде.

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

3. Неправильно сформированные продукты

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

2. Граница между продуктами была сильно размыта, поэтому часто возникали спорные ситуации, чья это проблема и кто должен ее решать. Из-за чего решение проблемы затягивалось на очень длительный срок. От этого сильно страдали клиенты.

4. Недостаток самостоятельных ресурсов у продуктов

1. Команды, у которых не было своих разработчиков, месяцами ждали реализации своих даже очень простых фичей. Опять же, из-за изолированности продуктов и нежелания владельцев коммуницировать друг с другом и делиться разработчиками. В общем, шаринг разработчиков не работал (недавно в книге Д. Рейнвотера “Как пасти котов” прочитал, что подобные матричные схемы для разработчиков недопустимы).

2. Конкуренция за общие ресурсы. Вообще в ИТ продуктовая модель пришла из бизнеса, а там давно известно, что такая модель ведет к конкуренции продуктов между собой. Есть интересная статья на Хабре про это. В моем случае, у продуктов не было своих дизайнеров и тестировщиков, и за эти ресурсы шла неприятная кулуарная борьба.

5. Отсутствие тимлида, как прослойки между менеджментом и разработкой

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

Что в итоге

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

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

На мой взгляд, главная причина провала в том, что эта трансформация была искусственной. У команды не было естественных предпосылок для такой трансформации (физическое расширение команды и/или естественное формирование продуктов внутри проекта). Команда была небольшая и она нормально работала.

p.s. Сейчас мне уже кажется, что вся эта трансформация случилась, потому что кто-то просто преследовал свои личные корыстные цели.

Спасибо за внимание.

Подписывайтесь на мой канал в телеграмме @ar2code.