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