Как подключить внешних IT-специалистов к существующему проекту и не завалить его

Приветствуем вас в блоге томского IT-сообщества! Здесь мы пишем об интересных кейсах и опыте томских IT-компаний по разработке и продвижению своих продуктов. А еще мы проводим медиаконференцию «Город IT 2020: продуктовый сезон», где будем обсуждать темы, которые будут затрагиваться в этом блоге. Больше информации о Городе IT 2020 можно найти тут.

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

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

Чтобы решить эту проблему, можно найти полноценную выделенную аутсорс-команду разработчиков (Dedicated Team) или же частично расширить внутреннюю команду за счет внешних специалистов (Team Extension).

Team Extension: Вы усиливаете собственную команду с помощью внешних IT-специалистов, заполняющих пробелы в недостающих экспертизах.

Dedicated Team: Вы доверяете разработку проекта аутсорсинговой компании. Сформированная специально для вас, она является отдельной единицей со своим менеджментом и внутренней структурой.

Team Extension: Вы управляете разработкой самостоятельно. Вы отвечаете за постановку задач, сроки, бюджет и качество работ. Вендор отвечает за качество и доступность инженеров, соответствие грейдов и масштабирование.

Dedicated Team: Разработкой управляет поставщик выделенной команды. Состав команды может меняться в процессе согласно требованиям проекта. Как правило, поставщик услуги отвечает за сроки, качество работ и бюджет.

Team Extension: Вы можете свободно распределять ответственность между разработчиками из внутренней команды и внешними специалистами. Все стратегически важные компетенции остаются внутри компании. Вы быстро и эффективно дополняете свою команду нужными экспертами. Возможность подключить Smart-сервисы: Agile Software Management, Technology Architect on Demand и другие.

Dedicated Team: Сфокусируйтесь на бизнес-задачах, пока ваш партнер занимается подбором специалистов, управлением проектом, контролем качества и доставкой. Вендор отвечает за техническое «счастье» IT-специалистов, их вовлеченность и мотивацию. Поставщик услуги берет на себя часть рисков, связанных с проектом. Возможность подключить сервис Squad-Based Development для большей гибкости и своевременного реагирования на изменения рынка.

Team Extension: Возможны проблемы с коммуникацией внутренних и внешних разработчиков из-за различий в культурах их компаний. Разработчикам нужно больше времени на онбординг. Модель Team Extension может оказаться дорогостоящей для краткосрочных проектов.

Dedicated Team: Клиент обладает меньшим контролем над процессом разработки. На формирование подходящей проекту выделенной команды может уйти немало времени. Модель Dedicated Team малоэффективна на краткосрочных проектах.

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

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

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

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

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

Не стоит пренебрегать этапом исследования (Discovery Phase). Исходя из нашего опыта, для средних проектов этот этап составляет 20-40 часов, а для крупных — от одного до двух месяцев. Помимо всего прочего, это отличная возможность выяснить, соответствует ли вендор вашим ожиданиям.

Преимущества такого подхода:

Один наш заказчик хотел запустить новый сервис, не имеющий аналогов. Им были частично сформированы требования. При первоначальной оценке проекта мы выявили несколько неопределенных моментов, которые могли негативно сказаться на бюджете. Стартовать в этих условиях было опасно. Была запущена Discovery Phase. Аналитики изучили архитектуру, проработали Delivery-план, что позволило более точно определить сроки, оптимизировать бюджет и снизить риски заказчика.

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

Отсутствие понимания рисков может привести к следующим последствиям:

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

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

У нас богатый опыт работы с большой часовой разницей, вплоть до 14 часов. Самое важное в распределенной команде — правильная коммуникация, но любую коммуникацию ломает разница в таймзонах. Долго решаются вопросы, медленно обрабатываться запросы и принимаются изменения (Pull Requests). Задача, которая решалась бы в офисе за час, в распределенной команде с большой часовой разницей может решаться два-три дня.

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

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

Перед началом работы следует пообщаться с руководителем, который будет вести ваш проект, и обсудить с ними детали менеджмента. Часть работ в рамках проектной деятельности вам может оказаться попросту не нужна, какие-то работы можно осуществлять самостоятельно, а о существовании некоторых вы даже не подозревали. В обязанности руководителя проекта могут входить (или не входить):

Перед началом сотрудничества важно понять, как выстроены грейды у вендора. Ведь у всех свои представления о Junior-, Middle- и Senior-разработчиках. В одной компании к Senior выдвигаются одни требования, а в другой — совсем иные. При этом помните, что между «грейдами» и «ролями» участников проекта очень большая разница. Например, тимлидом может быть Middle-специалист с хорошими навыками менеджера.

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

Этот момент актуален для модели Dedicated Team. Следует опасаться компаний, которые не предоставляют возможности прямого общения с разработчиками. Общение с выделенной командой или отдельными специалистами через третьих лиц может замедлить процесс разработки и вылиться в недопонимание, которое может навредить проекту.

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

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

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

Что нужно обязательно сделать, нанимая внешних IT-специалистов:

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

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

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

В распределенных командах гибкие навыки (Soft Skills) играют ничуть не меньшую роль, чем профессиональные характеристики разработчиков (Hard Skills). Согласно нашему исследованию, в котором приняли участие 291 CTO средних и крупных IT-компаний, сегодня техническим специалистам важно развивать следующие Soft Skills:

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

Если вендор практикует заключение Service Level Agreement (SLA), тщательно изучите этот документ. Он является гарантом обеспечения надлежащего уровня качества услуг, за которые вы платите. Если же заключить SLA возможности нет, постарайтесь на старте зафиксировать договоренности в виде устава или иного документа. Важно прописать такие моменты, как:

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

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

Расширение команды с помощью модели Team Extension подходит далеко не всем. Для успешной интеграции разработчиков в существующую команду нужно обладать опытом управления, обеспечивать качественный онбординг, уметь правильно ставить задачи, точно оценивать сроки и бюджет. Если вы не уверены в своих силах, безопаснее всего воспользоваться сервисом Dedicated Team, где ответственность в управлении и часть рисков перекладываются на плечи вендора.

Надеемся, этот гайд был для вас полезен. Если у вас остались вопросы, CTO компании Sibedge Всеволод Мороцкий с радостью на них ответит.