Практические аспекты выбора между продуктовой разработкой и аутсорсингом: сроки, качество и управляемость команды.
В первой части статьи мы рассмотрели два популярных заблуждения о работе в продуктовых и аутсорсинговых IT-компаниях и выяснили, что объективная оценка качества и признание заслуг разработчиков не зависят от типа компании.
Главное - как распределена ответственность за будущий результат и как построены отношения между заказчиком и разработчиками.
Партнёрство это или слепое выполнение техзадания?
Разберёмся с тремя другими иллюзиями.
Аутсорс - своеобразный конвейер, где клиенты приходят и уходят по-быстрому. Главное - сдать проект вовремя. Работать при этом приходится в жёстких рамках, ведь сроки нельзя срывать.
Продукт - это всегда долгосрочные отношения. Над одним продуктом можно работать годами, вкладывать в него душу, растить его, как цветок или как ребёнка. Это другой, более высокий уровень отношений, чем «конвейерная сборка».
Проекты крупного IT-интегратора - далеко не «сайтик запилить».
Они предполагают огромный объём работ, часто на несколько лет: сложная интеграция или доработка уникальных модулей.
Рабочие отношения в таком случае ближе к партнёрским.
Они долгосрочные, а в парадигме Agile вообще не ограничены по срокам: улучшать продукт можно бесконечно.
Многие из наших клиентов поддерживают с нами многолетнее сотрудничество.
Это и непрерывное развитие продукта, и принятие сложных управленческих решений, и совершенствование подходов. Например, для одного из крупных интернет-магазинов мы решили изменить архитектуру: переходим на микросервисы, полностью меняем frontend.
Это необходимо, чтобы клиент мог добиться новых амбициозных целей, которые он ставит перед собой на 2020-2021 годы.
Для заказчиков из другой компании мы собрали все разрозненные сервисы в единую экосистему.
Больше года мы работали над цифровизацией их бизнеса.
Разработали правила построения архитектуры системы, создали несколько сервисов. Например, сервис распознавания документов, мобильное приложение для сотрудников склада, микросервисы маршрутизации заказов в конвейерных лентах и многое другое.
Требования по срокам, конечно, есть всегда.
Любой бизнес имеет дело с ограниченным количеством ресурсов и не может ждать поставки ценности бесконечно.
Однако продуктовый подход подразумевает, что нужно делать не больше фич в единицу времени - нужно делать самые ценные, приоритетные фичи, выбирая их из backlog'а.
Риски же за оценку времени команда определяет самостоятельно и ежедневно, как самостоятельно определяет и объём работ. И сроки всё чаще прогнозируются на кварталы и полугодия, а вместо фич мы начинаем говорить с клиентом про результат.
Это важнейший навык, который и отличает команду инженеров от команды кодеров подобно тому, как машинистку ценят за количество знаков, а писателя - за смысл.
Разработка на заказ считается скучной, потому что здесь всегда нужно думать о бизнес-показателях. Из аутсорсинговых компаний сотрудники часто бегут, если их переводят на проект, который им не интересен.
В продуктовых компаниях можно дорабатывать и развивать уже существующий успешный продукт (такой, например, как продукты «Яндекса»). Это кажется легче (основная часть продукта уже готова), к тому же приятно участвовать в работе над полезным софтом, которым пользуются тысячи людей.
Инженер - не тот, кто штампует сферических коней в вакууме, пусть и очень красивых и с необычными фичами.
Это тот, кто решает прикладные задачи с максимальной экономической эффективностью.
Интересные задачи присутствуют и при заказной разработке, если видеть в заказчике не разового клиента, а партнёра навсегда, и относиться к своей работе ответственно. К тому же аутсорс-компании часто более свободны в выборе технологий.
Если интересно освоить что-то новое - вперёд!
Ведь для заказчика главное - достичь бизнес-целей.
Если это можно сделать быстрее, ему всё равно, какими технологиями пользуются IT-специалисты. Например, у нас пара талантливых ребят решили изучить Ruby и перешли на соответствующий проект за два спринта!
Так им удалось подобрать лучшее решение для задач клиента и освоить новый стек. А если бы они предложили сменить стек в продуктовой компании?
Это вряд ли возможно для продукта, который «кормит» всю команду. У нас допустимы ротации между проектами.
Если проект категорически «не зашёл», разработчик может перейти в другую команду с другими задачами.
В аутсорсинговой компании мало внимания уделяют качеству кода. Ожидается, что после сдачи проекта исполнитель не увидит его в будущем, и поэтому не несёт за него особой ответственности. Обратная сторона этой проблемы: может «прилететь» проект после вот такого вот кодера, и разгребать накопившиеся проблемы придётся тебе.
Разработчик делает свою часть продукта с нуля и не имеет дела с чьим-то чужим кодом.
И в продуктовой, и в аутсорсинговой компании есть общая боль.
Это привязка к чужому старому коду, если приходишь работать с продуктом не с самого старта.
Проблема решится, когда высокая культура кода будет принята среди всех разработчиков независимо от того, в какой компании они работают.
Волшебную таблетку от чужого некачественного кода не изобрели - он есть при любом типе разработки. Кстати, известная история: в 2014-2015 годах Microsoft уволила почти всю команду тестирования Windows.
Это было связано с новой парадигмой тестирования продуктов, новой продуктовой и кадровой политикой.
После этого разработчики стали жаловаться на качество кода собственной компании, да и пользователи заметили, что багов стало больше.
Аутсорс-разработка восхищает именно отсутствием всего лишнего. В компаниях, которые специализируются на сложных решениях, главную роль играет как раз культура разработки.
В отличие от продуктовых компаний, у нас нет времени собирать огромное количество людей с модными должностями, тратить всё время на бесконечные совещания и «размывать» цели.
Мы очень часто слышим от разработчиков, что в продуктовой компании можно потратить день на размышления об архитектуре. Хм, возможно.
Но как часто продукт в реальности пробует новую архитектуру, новый подход? В сложной аутсорс-разработке для того, чтобы протестировать что-то новое, нужно просто перейти в другую продуктовую команду или на новый проект. А разнообразие метрик и типов направлений расширяет картину мира.
Итак, в этой и предыдущей статьях мы рассмотрели пять типичных возражений разработчиков против работы в аутсорс-компаниях.
На самом деле это мифы, сегодня аутсорс и продуктовая культура не противоположны.
Развивать продуктовое мышление можно и нужно в любой компании, а предрассудки об аутсорсе в большинстве случаев уже устарели.
Главное в продуктовом мышлении - каким образом выстроено целеполагание и ответственна ли команда за продуктовые метрики.
