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

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

Иногда так и происходит. Но бывает и иначе. Компания растёт, задачи становятся сложнее, меняются технологии, появляются новые требования. Или просто оказывается, что ожидания бизнеса и возможности подрядчика больше не совпадают.

В этот момент возникает вопрос, которого многие опасаются: как сменить подрядчика так, чтобы ничего не сломалось? Да и стоит ли вообще это делать, либо следовать принципу, что коней на переправе не меняют?

Хорошая новость в том, что сама по себе смена команды — не проблема. Настоящие проблемы возникают тогда, когда проект становится заложником одного исполнителя, а знания о системе существуют только "в головах" нескольких разработчиков. Причём некоторые решения невозможно объяснить иначе, кроме как "так исторически сложилось".

Когда действительно стоит задуматься о смене подрядчика

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

Однако есть признаки, которые говорят о системных проблемах:

• сроки постоянно сдвигаются без понятных причин;
• стоимость доработок растёт, а объяснения становятся всё менее прозрачными;
• команда перестаёт предлагать решения и только выполняет отдельные поручения;
• документация отсутствует или давно не обновлялась;
• любое изменение сопровождается неожиданными ошибками;
• бизнес не понимает, как развивается система и какие у неё ограничения;
• проект фактически зависит от одного разработчика.

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

Хороший подрядчик не боится отпускать клиентов

Есть один показатель профессионализма, о котором редко говорят. Некоторые компании пытаются удержать клиента не качеством работы, а зависимостью. Можно услышать фразы вроде:

• «Кроме нас в этом проекте никто не разберётся».
• «Если смените подрядчика, придётся всё переписывать с нуля».

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

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

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

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

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

Хороший новый подрядчик не начинает с программирования

Есть и другая крайность.

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

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

• Почему здесь нет привычного модуля?
• Почему интеграция работает именно так?
• Зачем используется такая структура данных?
• Почему этот процесс нельзя упростить?

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

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

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

С чего должна начинаться передача проекта

Первый этап — не разработка. Первый этап — знакомство с системой.

Обычно новая команда:

• получает доступы;
• разворачивает проект в тестовой среде;
• проводит технический аудит;
• изучает архитектуру;
• анализирует инфраструктуру;
• проверяет резервное копирование;
• знакомится с интеграциями;
• оценивает качество кода;
• фиксирует технические риски.

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

Если документации нет

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

В этом случае новая команда постепенно восстанавливает знания о системе:

• описывает архитектуру;
• документирует интеграции;
• фиксирует настройки инфраструктуры;
• создаёт инструкции по развёртыванию;
• составляет карту сервисов.

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

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

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

• Проводите ли вы аудит перед началом разработки?
• Как проходит передача проекта?
• Что делать, если часть доступов отсутствует?
• Кто будет восстанавливать документацию?
• Как организована поддержка после передачи?
• Как принимаются технические решения?
• Кто отвечает за коммуникацию с заказчиком?

Ответы на эти вопросы позволяют понять не только уровень технической экспертизы команды, но и зрелость её процессов.

Смена подрядчика — это передача ответственности, а не борьба

Иногда кажется, что смена подрядчика — это почти всегда конфликт. На самом деле профессиональная передача проекта выглядит совсем иначе.

Предыдущая команда помогает передать накопленные знания. Новая — уважительно относится к уже проделанной работе и не торопится объявлять все существующие решения неправильными.

Обе стороны понимают, что главная цель — не доказать свою правоту, а сохранить стабильную работу бизнеса. Именно поэтому лучший подрядчик — не тот, кто говорит: «Без нас этот проект не выживет». И не тот, кто с первого дня обещает переписать всё заново. Лучший подрядчик — тот, кто способен принять чужую работу, разобраться в ней, сохранить всё ценное и только потом начать развивать систему дальше.