Материал подготовлен с участием экспертов Morizo — Андрея Свинцова, исполнительный директор, и Веры Кряжовой, директора по заказной разработке. До 24% проектов Morizo относятся к таким проектам-эстафетным палочкам.

Содержание:

1. Почему меняют технического подрядчика
2. Заказчику:
   • Как контролировать передачу проекта
   • Что получить от предыдущего подрядчика при передаче проекта
   • Как передать проект новому подрядчику
3. Подрядчику, принимающему проект:
   • Стоит ли браться за проект?
   • Как принять проект: пошаговая инструкция с элементами чек-листа
4. Подрядчику, отдающему проект: как его правильно передать.
5. Заключение

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

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

Откуда они берутся? Мы видим три причины:

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

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

• Подрядчик «изжил себя».
  Проект перерос возможности исполнителя. Тот не справляется с объёмом или сложностью задач, или требованиями времени (например, не умеет внедрять ИИ). Проекту нужен кто-то посильнее.

Наши наблюдения: в 60% случаев передача проекта от одного подрядчика к другому решает проблемы и помогает достигнуть цели, в 40% — усугубляет ситуацию, потому что передача проведена неправильно. Давайте разберёмся, что значит правильная передача и как не сделать ситуацию ещё печальнее.

Заказчику

Как успешно передать проект

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

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

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

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

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

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

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

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

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

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

Доступы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы подрядчик, принимающий проект

Стоит ли браться за проект от другого подрядчика?

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

1. Сопоставьте требования по проекту со своими возможностями и целями. Они зависят от стратегии развития вашего бизнеса и бизнеса заказчика, включают отраслевую специализацию, технологический стек, особенно если нужна интеграция разных систем, существующий на проекте «зоопарк технологий», масштаб работ и требования к уровню сервиса. Если вы не в силах оказать поддержку 24/7, но она нужна заказчику, проблемы появятся в первый же месяц — скорее всего, в пятницу вечером.
2. Проанализируйте риски проекта, особенно в части передачи информации и доступов. Если предыдущий подрядчик по договору не обязан отдать вам исходные коды или описание архитектуры, а продукт частично является его интеллектуальной собственностью, вы ничего не получите даже через суд. Более того, в такой ситуации вы не по своей вине можете оказаться в реестре недобросовестных поставщиков, а это начало конца.
3. Оцените финансовую целесообразность принятия рисков. Если доходность проекта ниже принятой средней в вашей бизнес-модели, а заказчик не готов обсуждать изменения бюджета в случае форс-мажора, проект превратится в русскую рулетку.

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

Как принять проект: пошаговая инструкция

Сейчас в Morizo 24% чужих проектов, ставших своими. Мы создали инструкцию по приёмке таких проектов. Её разрабатывали руководитель отдела заказной разработки, тим-лиды ключевых стеков, группа тендеров и юридический отдел. Эти 7 шагов помогут вам правильно начать работу и не завести себя в тупик.

Шаг 1: Определите требования, ожидания и цели заказчика

Важно сразу прояснить и зафиксировать ключевые моменты сотрудничества:

1. Цели проекта: какие задачи бизнеса и пользователей он решает.
2. Ожидаемые результаты: функционал, количество пользователей, сроки, повышение рейтинга, перенос офлайн-функционала в онлайн и т. д.
3. Приоритеты: сроки, интеграции, тесты. Например, важнее сначала внедрить новые возможности или устранить существующие проблемы.
4. Ожидания и требования к процессу: формат постановки задач, приёмки результатов, коммуникации сторон. Устраивает ли общение на статусах раз в неделю или важен ответ менеджера в течение 2 часов после обращения.
5. Методологию разработки и финансовую модель. При гибкой разработке бюджет также должен увеличиваться по мере роста задач. При фиксированном бюджете договоритесь, какой объём работ покрывает оплата, зафиксируйте количество итераций правок, порядок управления дополнительными сметами и механизмы предупреждения о возможном перерасходе часов. Бывают случаи, когда именно на этом этапе заказчик осознаёт: великие замыслы и радикальные изменения сейчас ему не по карману и … возвращается к более дешёвому подрядчику. Лучше узнать об этом до заключения договора.

Списку можно не следовать, но тогда есть риск стать очередным подрядчиком, не «оправдавшим надежд».

Шаг 2: Проанализируйте негативный опыт заказчика

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

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

Шаг 3: Уточните законодательные требования в сфере заказчика/проекта, актуальные на момент передачи

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

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

Каждый проект — на экспертизу к юристам.

Шаг 4: Задокументируйте состав и параметры работ, требуемые результаты, а также все юридические формальности

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

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

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

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

Шаг 5: Проведите ликбез для заказчика

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

Примеры тем для «онбординга заказчика»:

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

Шаг 6: Согласуйте содержание и регулярность отчётов, а также стандарты оформления документов (ГОСТ или внутренние)

Очевидная вещь, которая, тем не менее, стоит очень дорого.

В отчёте указывают: задействованных специалистов, часы, поставленные задачи, этапы работ, процент выполнения и прогноз по завершению.

Если заказчик работает по стандартам, сертификатам или ГОСТам, эту особенность нужно зафиксировать на этапе первого отчёта, чтобы потом всё не переделывать.

Шаг 7: Составьте матрицу ответственности для всех участников проекта

Матрица ответственности позволяет чётко распределить роли и задачи между всеми вовлечёнными сторонами — вашей командой, заказчиком и предыдущими подрядчиками.

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

Теперь вы сделали максимум. По опыту Morizo, эти 7 шагов помогают избежать недопонимания, финансовых рисков и повторения ошибок прошлых подрядчиков. Чёткая документация и прозрачные договорённости — лучшая основа успешного сотрудничества.

Если вы подрядчик, передающий проект

Что важно для передающей стороны

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

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

Шаг 1: Составьте и согласуйте план передачи проекта

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

Если проект просят отдать без доработок, также зафиксируйте это письменно.

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

И не забудьте передать документацию, что нужно доработать.

Шаг 2. Обеспечьте полную передачу знаний

Этап включает в себя:

1. Подготовку и передачу всех материалов и документации: актуальные ТЗ, исходный код, комментарии, отчёты о тестировании, контакты всех причастных. Беспорядок в документации нанесёт ущерб вашей репутации.
2. Передачу доступов и отключение своих сотрудников от рабочих аккаунтов.
3. Онбординг нового подрядчика.
4. Предоставление консультаций по всем возникающим вопросам
5. Закрытие юридических формальностей. Если остались какие-то замечания, которые необходимо устранить, их важно отразить в самом акте или отдельном документе к нему. Кроме того, если по договору исключительные права переходят только после подписания специального акта, составьте и подпишите его дополнительно к основному акту приёмки-передачи работ.

Шаг 3. Подготовьте отчёт для заказчика

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

1. какие основные задачи были решены;
2. какие вызовы стояли;
3. каких результатов достигли;
4. каких результатов достичь не удалось и почему;

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

А ещё можно дать небольшую статистику по совместной работе: сколько часов потрачено, сколько задач решено, атак отражено, заказов обработано и т. д.

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

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

Итого

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

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

Материал опубликован на сайте GlobalCIO.

Оригинал: https://globalcio.ru/discussion/55577/