Как правильно передавать технические проекты новому разработчику

Передача ИТ-проекта новому подрядчику – распространённая, но не всегда успешная практика: теряется информация, опыт, что-то ломается в коде или процессе.

Как правильно организовать передачу и на что обратить внимание, рассказывают Андрей Свинцов, исполнительный директор ИТ-компании Morizo (входит в E-Promo Group), и Александр Туник, директор по продуктам «Рейтинга Рунета». До 24% проектов Morizo относятся к таким проектам-эстафетным палочкам.

Из-за чего меняют технического подрядчика

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

Откуда они берутся? Есть три причины:

1. Подрядчик просто не справляется с работой.
   Регулярно нарушает сроки, значительно превышает бюджет, не может удержать качество на нужном уровне. Несмотря на попытки заказчика разобраться с проблемами, ситуация не улучшается.
2. Проблемы в коммуникации и сервисе.
   Подрядчик формально справляется, но заказчика не устраивает информирование о ходе проекта или коммуникация в целом. Возможно, стороны просто не нашли общий язык. Это скорее конфликт личностей, чем технологические проблемы, но он приводит к тому, что для достижения результата нужно прикладывать в разы больше усилий.
3. Подрядчик «изжил себя».
   Проект перерос возможности исполнителя: он не справляется с объёмом или сложностью задач, требованиями времени (например, не умеет внедрять ИИ).

По нашим наблюдениям, в 60% случаев передача проекта решает проблемы и помогает достигнуть цели, а в 40% – усугубляет ситуацию.

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

Причин провала две:

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

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

Рассмотрим алгоритм правильной передачи проекта.

Что нужно получить от предыдущего подрядчика

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

1. Документы и данные

Перечень документов зависит от проекта и его стандартов. Идеально, когда подрядчик отдаёт все, что погружает в историю и специфику проекта: техническую документацию, описание стека и архитектуры, инструкции по развёртыванию, описания окружений, CI/CD, API и интеграций, комментарии в коде, перечни ПО с указанием использованных версий.

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

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

2. Доступы

25% клиентов Morizo, пришедших от другого подрядчика, сталкивались с убытками и простоем из-за отсутствия нужных доступов.

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

Этапы передачи проекта новому подрядчику

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

На эту тему можно написать диссертацию, поэтому остановимся на самых важных пунктах.

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

Так вы избежите повторения проблем.

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

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

2. Уточните стратегию и цели проекта

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

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

Новый подрядчик не знает ваш бизнес, он не отвечает за стратегию его развития. Ваша задача – погрузить его в контекст и направить.

3. Опишите свои ожидания от сотрудничества

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

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

4. Назначьте ответственного со своей стороны

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

Без такого человека даже самый квалифицированный подрядчик не сможет эффективно принять и развивать проект из-за затягивания сроков принятия решений.

5. Решите, что нужно контролировать

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

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

6. Будьте готовы к изменениям в процессах

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

Это другая компания, у неё свои особенности. Здесь важно разобраться, что устраивает обе стороны, и найти оптимальный вариант. Всем известный пример: заказчик вместо просьбы «поиграть со шрифтами» предоставляет референсы, что нравится, а что неприемлемо. Со стороны клиента это сразу четыре звена процесса: назначение ответственного, поиск вариантов, их согласование и передача подрядчику.

7. Дайте новому подрядчику время на адаптацию

Ему точно понадобится время на погружение. Продолжительность этого периода зависит от масштаба и сложности проекта.

Сначала новый подрядчик будет работать медленнее, оценки сроков будут приблизительными, он будет задавать много вопросов – и, да, делать ошибки. Это нужно принять: он берёт новый проект, чужой код, чужие процессы.

По нашему опыту, адаптация занимает не меньше месяца.

Выводы

Если свести всё сказанное выше к нескольким пунктам:

1. Взвесьте все «за» и «против». Передача почти наверняка потребует перестройки процессов, вовлечения.
2. Не рвите отношения с предыдущим подрядчиком, а вовлеките его в процесс, чтобы получить всё необходимое для дальнейшей работы над проектом.
3. Подготовьтесь эмоционально: передача никогда не происходит быстро и безболезненно.
4. Не концентрируйтесь исключительно на технической части: нового подрядчика нужно погрузить в контекст.
5. Подумайте, что стоит поменять на вашей стороне.
6. И дайте новому подрядчику время. Это инвестиция, которая окупится за счёт снижения затрат вашей команды на контроль и исправления в будущем.