Как передать разработку новому подрядчику и не уничтожить проект

Смена подрядчика может быть связана с несколькими причинами. Перечислим самые распространенные из них.

Подрядчик ушел с рынка

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

Подрядчику не хватает кадров или квалификации

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

Работа текущего подрядчика перестала устраивать

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

Требуется диверсификация рисков зависимости от подрядчика

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

Как снизить риски зависимости от подрядчика

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

1. Документируйте создаваемую систему и поддерживайте документацию в актуальном состоянии Обязательно включайте в проект работы по созданию пользовательской и технической документации. Мы, как компания, которая помогает осуществлять переход к новому подрядчику, часто сталкиваемся с ситуациями, когда документация отсутствует или создается для «галочки», не отражая реальную картину. Иногда бывает так, что документация создается на старте проекта, но потом о ней забывают. Если отмечать все изменения, которые вносятся в систему, новая команда сможет быстрее разобраться в проекте и начать над ним работу. Качественная и актуальная документация облегчит развитие и доработку системы.

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

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

3. Подключайте нескольких подрядчиков к работе над большими проектами

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

4. Обеспечьте доступ к коду и всей инфраструктуре проекта

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

5. Обеспечьте внутреннюю экспертизу в отношении разрабатываемой системы

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

Как подготовиться к передаче системы

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

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

Если права принадлежат вам, переходите к следующему шагу — выбору варианта передачи. Варианты могут быть следующими:

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

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

• Перевод проекта инхаус. В крупных компаниях, как правило, есть ИТ-отдел, который может взять на себя задачи подрядчика по доработкам и техническому сопровождению.

Замена подрядчика — кейсы из практики «КОРУС Консалтинг»

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

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

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

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

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

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

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

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

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

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

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

Этапы передачи системы

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

1. Подготовка кода.

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

2. Документация.

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

3. Передача кода.

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

4. Проверка получения.

Далее вам нужно убедиться, что подрядчик передал то, что нужно, и другая сторона это получила.

5. Тестирование кода.

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

6. Обратная связь.

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

7. Передача дополнительной информации.

После этого новая команда получает недостающие артефакты.

8. Проверка работоспособности.

Новый подрядчик проверяет функциональность системы и тестовое окружение.

9. Оценка перспектив продолжения работы с новым подрядчиком.

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

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

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