База знаний

Чек-лист: как безболезненно передать проект новому
ИТ-подрядчику

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

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

Как сделать так, чтобы передача проекта не повлияла негативно на работу всего бизнеса?

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

Запросить документацию

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

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

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

Получить артефакты работ

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

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

Получить все доступы

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

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

Организовать онбординг новой команды

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

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

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

Обсудить кейс

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

Что учесть при передаче проекта: главное

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

Кратко повторим пункты, которые нужно учитывать при передаче проекта:

Проверьте, есть ли в документации все данные, которые вы запрашивали в договоре;
Получите доступы к сервисам, которые были использованы в процессе работы;
Изучите артефакты: откройте все файлы, проверьте их работоспособность и посмотрите, все ли данные загрузили разработчики;
Если нужно, запросите 1-3 встречи, чтобы включить в работу нового подрядчика или инхаус команду;
Определите, какую информацию о проекте можно использовать в кейсе и готовы ли вы помогать подрядчику в подготовке к премиям и конкурсам.

Давайте обсудим ваш проект

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