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

Смена подрядчика и подключение к проекту еще одной команды — сложный и многоэтапный процесс, требующий тщательной подготовки. Если заранее учесть все факторы, от которых зависит, насколько успешной будет передача ИТ-системы новому подрядчику, можно застраховать себя от большинства рисков, избежать увеличения бюджета и сроков подключения нового подрядчика к проекту. Как подготовиться к смене команды, чтобы это не потребовало избыточных вложений, а проект вовремя завершился? Что поможет не ошибиться в выборе партнера? Как проходит передача системы новой команде на практике? Об этом рассказали специалисты ГК «КОРУС Консалтинг»: руководитель направления заказной разработки департамента «Логистика» Елена Никитина и CTO Авенир Воронов.

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

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

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

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

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

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

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

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

• Документируйте создаваемую систему и поддерживайте документацию в актуальном состоянии 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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