Разработка

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

Редактор: Анастасия Тищенко

Время чтения: 5 минут

12 февраля 2024

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

Откуда приходят проекты

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

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

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

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

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

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

”

Передача проектов с недостаточной документацией и непонятной архитектурой увеличивает риски, замедляет сроки и ухудшает клиентский опыт

Дмитрий Романов

Технический директор
ГК «Цифровые привычки»

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

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

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

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

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

Регулярные ревизии документации помогают избежать устаревания и обеспечивают актуальность информации для всех участников проекта, включая новых сотрудников или сторонних подрядчиков. Особое внимание стоит уделить доступности документации: она должна быть организована в удобной форме, чтобы любой заинтересованный специалист мог легко найти нужную информацию. Мы часто используем системы управления проектами Confluence или GitHub, чтобы хранить и поддерживать документацию в актуальном состоянии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Старайтесь документировать все данные письменно, фиксировать договоренности и определить, кто именно из сотрудников на стороне заказчика и исполнителя отвечает за передачу проекта.