3 года мы пытаемся увеличить производительность команды за счёт привлечения аутсорса к решению задач. Всё осложняется тем, что аутсорс нам нужен не для того, чтобы сделать какое-то внешнее решение, вроде сайта или отдельной страницы, но для того, чтобы разрабатывать что-то в нашем core-решении. 

Сама постановка задачи «увеличить производительность за счёт аутсорса» выглядит довольно спорной, но это тема для другой статьи. 

Бизнес сказал «Надо», мы пошли думать, как это организовать.

О нас

Мы классическая in-house команда разработки. Работаем по scrum, подстроив все процессы под себя, чтобы они были полезными для нас. Главный урок, который мы вынесли, пока настраивали процессы — чтобы всё заработало, нужно полностью понимать зачем это делается и какую пользу мы получим. 

Первый блин комом

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

К нам пришел бизнес и сказал: либо вы нанимаете людей и сразу начинаете нужные нам работы, либо берете аутсорс. Таких слов как «время на onboarding» никто слышать не хотел. 

С учётом того, что среднее время найма в нашу команду было 3-4 месяца, выбор был очевиден.

Мы были молодые и неопытные (в работе с аутсорсом), такие слова как техническое задание, у нас не особо использовались (у нас же scrum и бизнесовые проработки, а техническую реализацию продумывала сама команда). Стряхнув пыль с университетских воспоминаний, мы написали техническое задание. Наша компания уже сотрудничала с организацией, которая предоставляла услуги аутсорса, поэтому мы написали им и спустя какое-то время нам был предоставлен человек, который соответствовал нашим представлениям о том, кто нам нужен.

Срок был 3 месяца, но спустя примерно 2.5 месяца нам был предоставлен pull request.

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

Времени, на то, чтобы аутсорс успел всё переделать и заставить это работать у нас не оставалось. Пришлось в максимально сжатые сроки переписывать большую часть того, что нам предоставили, в ущерб текущим задачам. 

Какие мы сделали выводы? Нужно постоянно держать руку на пульсе того, что делает аутсорс. Это могут быть еженедельные 15-и минутные встречи, какие-то отдельные законченные кусочки, которые может посмотреть команда и оперативно дать обратную связь. 

Попытка #2

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

1. Новый функционал должен был существовать в отдельном микросервисе.

2. Микросервис изначально проектировался для работы с аутсорсом — готовые скрипты запуска, подробный README, максимально простой код и готовый пример реализации.

3. Выбирали исполнителей не среди тех, кого рекомендует компания, а на внешнем ресурсе.

4. Подготовили канал для быстрых коммуникаций.

5. Сделали предварительное техническое исследование и подготовили его для передачи аутсорсу.

На этот сроки были намного меньше — всего месяц. По нашим меркам этого было более чем достаточно. 

Не совсем по плану всё пошло с момента поиска исполнителя. Вместо пары-тройки дней, на это ушло две недели. Кто-то нам не отвечал, кто-то, после прочтения задания, поднимал цену. 

Второй проблемой были коммуникации. Хоть у нас и был канал для быстрой связи, качество этой связи оставляло желать лучшего. На все наши вопросы мы получали примерно одного содержания: «Все в порядке, работаем». В этот момент мы должны были насторожиться. 

Первую версию мы получили через две недели. Чтобы не тратить время QA, первым на результат взглянули разработчики, которые писали исследование и готовили сервис для работы аутсорса.

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

К счастью, время у нас ещё было, так что мы, указав на проблемы, попросили их исправить. 

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

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

Внутри команды мы провели очередной большой разбор почему всё пошло не по плану:

1. Отдали на аутсорс реализацию того, что требовало какого-то минимального внутреннего исследования перед реализацией — проблемы обнаруживались во время реализации, но чаще были связаны с тем, что отсутствовала какая-либо документация для внешнего сервиса и мы полагались только на собственные собранные данные.

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

3. Не просили разбивать работы на небольшие кусочки, чтобы можно было давать комментарии до того, как это станет слишком сложно.

И снова frontend

На данный момент работа нашей команды с аутсорсерами продолжается, и мы выделили 2 ключевых направления:

1. Разделение монолитного frontend приложения.

2. Написание нового функционала.

Оба направления мы решили отдать на аутсорс под нашим контролем.

Разделение монолита

Само по себе направление максимально простое — копировать код из монолита и вставить его в новое приложение. 

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

Мы будто бы забыли всё, что узнали до этого момента, так что у нас были только периодические встречи (1-2 раза в неделю), где мы синхронизировались по текущем статусу переноса. К счастью, учитывая, что сама по себе работа не требовала какого-то понимания бизнес-логики, так что сам процесс переноса проходил максимально легко.

Новый функционал

Это направление намного интереснее. Нужно было синхронизировать работу аутсорс с работой нашей команды — с backend часть и с дизайном.

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

Самое сложное, с чем мы столкнулись — любовь аутсорса делать всю задачу одним большим куском. Это очень тяжело с точки зрения принимающей команды:

1. Нужно сделать review огромного количество кода.

2. Нужно протестировать огромное количество функционала.

3. Если на этапе тестирования или ревью появляются какие-то проблемы, то предсказуемость времени результата падает, из-за чего такие задачи могут не успевать за спринт, в котором мы рассчитываем их закрыть.

Мы всё ещё настраиваем процессы работы по данному направлению, потому что отказываться от него не собираемся в среднесрочной перспективе.

Немного выводов

• настраивать постоянные коммуникации, короткие итерации;

• отдавать декомпозируемые задачи, чтобы легко можно было отслеживать прогресс и проблемы;

• по возможности, использовать стандартные командные процессы;

• при подключении аутсорса к продуктовой разработке организовывать работу внутри команды, как членов команды;

• предоставлять информацию как тестировать, чтобы они могли сам проверять;

• аутсорсерсы могут писать тесты, чтобы снизить нагрузку на QA;

• использовать фича-тогглеры, чтобы выкладывать код, который не будет доступен конечным пользователям;

• по возможности подготавливать обособленную изолированную среду, чтобы не было проблем с доступами;

• если сложная область и непроверенные аутсорсеры, то лучше сначала нанять консультанта на постановку задач или разобраться самому;

• аутсорс работает хорошо в случае четких постановок (ТЗ, постановки, критерии приемки);

• при найме большого количества разработчиков учитывать загрузку QA, возможно нужно нанимать QA аутсорсера.