Смена подрядчика и подключение к проекту еще одной команды — сложный и многоэтапный процесс, требующий тщательной подготовки. Если заранее учесть все факторы, от которых зависит, насколько успешной будет передача ИТ-системы новому подрядчику, можно застраховать себя от большинства рисков, избежать увеличения бюджета и сроков подключения нового подрядчика к проекту. Как подготовиться к смене команды, чтобы это не потребовало избыточных вложений, а проект вовремя завершился? Что поможет не ошибиться в выборе партнера? Как проходит передача системы новой команде на практике?
Причины ухода подрядчика.
Подрядчик ушел с рынка.
Эта причина была особенно распространенной в 2022 году, однако она не теряет своей актуальности и сейчас. Не все западные вендоры продолжают сотрудничать с российскими компаниями и готовы дорабатывать приобретенные ими системы. Кроме того, вендор может уйти с рынка из-за банкротства или сменить сферу деятельности.
Подрядчику не хватает кадров или квалификации.
Такие ситуации возникают, когда бизнесу нужно развивать ИТ-систему, а подрядчик не может выделить необходимое количество специалистов или у команды нет необходимых компетенций.
Работа текущего подрядчика перестала устраивать.
Например, если партнер провел значительные кадровые перестановки или обновил команду, это может сказаться на качестве работы. Кроме того, оно может снизиться из-за изменений процессов внутри команды, ее выгорания, увольнения ключевых сотрудников в проекте.
Требуется диверсификация рисков зависимости от подрядчика.
При постоянной работе с одним партнером у компании возникает сильная зависимость от него. Чтобы снизить риски, которые она влечет, компании часто подключают к крупным проектам еще одну команду.
Как снизить риски зависимости от подрядчика.
Чтобы нивелировать риски, связанные с передачей проекта другой команде, стоит еще на старте проекта проработать шаги, которые позволят сократить зависимость от одного подрядчика. Это позволит перейти к работе с новой командой быстрее и с меньшими затратами. Однако даже если сотрудничество с текущим подрядчиком проходит без сбоев, снижение рисков зависимости все равно может оказаться полезным.
1. Документируйте создаваемую систему и поддерживайте документацию в актуальном состоянии.
Обязательно включайте в проект работы по созданию пользовательской и технической документации. Иногда бывает так, что документация создается на старте проекта, но потом о ней забывают. Если отмечать все изменения, которые вносятся в систему, новая команда сможет быстрее разобраться в проекте и начать над ним работу. Качественная и актуальная документация облегчит развитие и доработку системы.
2. При заключении договора убедитесь, что у вашей компании будут исключительные права на все артефакты, созданные в рамках проекта.
Бывают ситуации, когда права на исходный код, документацию, макеты и другие артефакты принадлежали подрядчику, создавшему систему, а не компании, которая выступала заказчиком разработки. Чтобы застраховать себя от юридических рисков, еще на этапе составления договора следите за тем, чтобы правообладателем выступала ваша компания.
3. Подключайте нескольких подрядчиков к работе над большими проектами
Если вы создаете масштабную систему, делите ее на блоки и подключайте к разработке несколько команд. В случае, если вы закончите сотрудничество с одним из партнеров, другой сможет разобраться в задачах быстрее, чем совершенно новая команда, так как уже будет погружен в проект. К тому же вам будет легче передать задачи команде, с которой у вас уже налажены взаимоотношения и не придется тратить время на выстраивание рабочих процессов. При этом важно, чтобы заказчик выделил руководителя проекта и технического архитектора со своей стороны, а команды регулярно обсуждали, как идет работа — это поможет вести ее согласованно и синхронно. Также это облегчит передачу задач от одного подрядчика другому, если в этом возникнет необходимость. Подключение к проекту нескольких команд требует больше затрат, чем сотрудничество с одним подрядчиком, поэтому важно понять, насколько такие меры целесообразны. Если риски оцениваются выше, чем затраты на содержание нескольких команд, стоит разделить задачи проекта между разными подрядчиками.
4. Обеспечьте доступ к коду и всей инфраструктуре проекта
Ведите разработку на собственных ресурсах — если на вашей стороне будут находиться среда разработки, репозиторий, макеты, система управления проектами, это минимизирует зависимость от подрядчика и облегчит передачу проекта другому партнеру. Если же разработка ведется на ресурсах подрядчика, нужно позаботиться о доступе к коду. Без этого передать разработку не получится. Кроме того, важно обеспечить себе доступ к инфраструктуре проекта: доменному имени (личному кабинету в регистраторе), площадкам размещения мобильных приложений, лицензиям и другим артефактам, которые связаны с проектом.
5. Обеспечьте внутреннюю экспертизу в отношении разрабатываемой системы
Важно, чтобы ваши сотрудники знали, как работает создаваемая система. Если со стороны заказчика над проектом будут работать руководитель проекта, технический архитектор (а в идеале и аналитик), то это поможет создать внутри компании такую же глубокую экспертизу, какой обладает команда-исполнитель
Как подготовиться к передаче системы?
Если ваша компания приняла решение о передаче системы новому подрядчику, прежде всего нужно проконсультироваться с юристами и выяснить, кому принадлежат права на разработку. В случае, когда правообладателем является подрядчик, надо обсудить вопрос приобретения прав. Это может потребовать дополнительных затрат, но будет дешевле, чем создавать систему с нуля. Большинство разработчиков заинтересованы в лояльности бывшего клиента и готовы к этому разговору.
При покупке коробочного решения вендоры часто не передают исходный код клиенту. Это влечет за собой риск, что система не будет дорабатываться в соответствии с индивидуальными запросами компании — если вендор развивает продукт самостоятельно, у него в приоритете будут те изменения, которые отвечают потребностям большинства пользователей. Поэтому при выборе поставщика ИТ-системы лучше отдавать предпочтение крупным вендорам: они обычно имеют обширную сеть партнеров, к которым можно обратиться за доработками. Если же вы уже приобрели решение и столкнулись с невозможностью критичных для вашего бизнеса изменений, стоит провести с вендором переговоры о выкупе кода и передать его новому подрядчику.
Если права принадлежат вам, переходите к следующему шагу — выбору варианта передачи. Варианты могут быть следующими:
• Полная передача системы другому подрядчику. Это самый сложный путь, при котором от проекта отключается прежняя команда, а новая только знакомится с ним.
• Подключение к разработке команды второго подрядчика. Этот вариант предполагает, что свежие задачи на доработку системы передаются новому партнеру, а прежний продолжает выполнять задания, которые получил ранее. Так система постепенно передается новому исполнителю. Достоинство этого варианта состоит в том, что он позволяет в комфортном режиме и с помощью небольших задач оценить работу нового подрядчика, пока основной блок работ остается в ведении старого партнера. Чтобы параллельная работа двух подрядчиков была эффективной, нужно грамотно разграничить зоны их ответственности.
• Перевод проекта инхаус. В крупных компаниях, как правило, есть ИТ-отдел, который может взять на себя задачи подрядчика по доработкам и техническому сопровождению.
Этапы передачи системы.
План, который поможет в комфортном режиме передать разработку новой команде и не затянуть этот процесс.
1. Подготовка кода.
В идеале перед передачей проекта нужно попросить прежнюю команду провести чистку кода, убрав избыточную информацию и артефакты, которые уже не актуальны. Кроме того, подрядчик, сотрудничество с которым завершается, должен зафиксировать версию для передачи, в том числе по состоянию тестов.
2. Документация.
После этого команде нужно актуализировать описания структуры проекта, функциональности, тестирования, сборки и выкатки.
3. Передача кода.
На этом этапе вы должны зафиксировать объем кода, размер архива или контрольную сумму файла. Если доступ к коду есть только у подрядчика, нужно попросить об этом его. Важно, чтобы все участники процесса понимали, как отправлять код и где он будет храниться. Нужно обеспечить безопасность данных, поэтому их лучше передавать в защищенном хранилище.
4. Проверка получения.
Далее вам нужно убедиться, что подрядчик передал то, что нужно, и другая сторона это получила.
5. Тестирование кода.
Затем команде, получившей код, следует его протестировать и проверить, совпадают ли результаты тестов до и после его передачи. Например, если перед отправкой кода 90% тестов были «зеленые», этот результат должен сохраниться и после получения.
6. Обратная связь.
На этой стадии новый подрядчик дает обратную связь о том, как работает система, каких документов и артефактов не хватает. Чтобы этот период не затягивался, нужно фиксировать каждую коммуникацию между партнерами и выкладывать артефакты в открытый доступ для всех интересантов.
7. Передача дополнительной информации.
После этого новая команда получает недостающие артефакты.
8. Проверка работоспособности.
Новый подрядчик проверяет функциональность системы и тестовое окружение.
9. Оценка перспектив продолжения работы с новым подрядчиком.
Вы оцениваете, как новая команда разрабатывает переданную систему. Проверить качество работы подрядчика можно давая ему те же технические задания, что и прежнему, и наблюдая, укладывается ли он в оговоренные сроки и соблюдает ли необходимые требования.
Заключение.
Смена подрядчика — процесс, который требует тщательной подготовки, высокой вовлеченности со стороны заказчика и финансовых затрат. Именно поэтому, задумываясь о сотрудничестве с новым партнером, нужно взвесить все «за» и «против» перехода и заранее предусмотреть возможные риски. Прежде чем менять команду, важно убедиться, что других способов исправить ситуацию не осталось, и только тогда инициировать передачу системы новому исполнителю.
Когда решение о передаче разработки уже принято, нужно понять, есть ли в вашей компании сотрудник, который имеет подобный опыт, понимает, как правильно выстроить процесс подключения к проекту новой команды, и готов взять на себя ответственность за переход. Если такого специалиста нет, нужно обратиться к сторонней компании, обладающей необходимой экспертизой. Профессиональные консультанты подскажут, как грамотно подготовиться к смене подрядчика или привлечению к работе над проектом еще одной команды, а также помогут решить эту задачу в приемлемые для бизнеса сроки.