Брошенные проекты: что делать, если подрядчик по разработке больше не может работать с Россией

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

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

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

К сожалению, это абсолютно реальные причины. Заказчики оказываются с «брошенным» проектом и полным непониманием, что делать с ним дальше.

Что делать с незавершенным проектом

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

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

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

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

Читайте по теме: 8 антикризисных лайфхаков от предпринимателей-гостей подкаста «Несладкий бизнес»

Чаще всего мы сталкиваемся со следующими ошибками:

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

Из рук в руки. Организация разработки

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

• Все остановилось на этапе дизайна. Если у клиента есть исходники нормального качества, можно дорабатывать то, что есть. В противном случае придется вернуться на этап аналитики и создавать дизайн заново.
• Если все «замерло» на стадии верстки, необходимо провести ее тестирование. Если обнаружатся «дыры» в логике, понадобится изменять дизайн. Если с логикой все в порядке, то проверяется адаптивность верстки и отсутствие багов под различными браузерами, чтобы определить, можно ли взять ее в дальнейшую работу.
• Если клиент приносит «почти готовый проект», то нужно смотреть код, его качество. Как он структурирован, есть ли история изменений, соблюдаются ли стандарты, учитывает ли требования безопасности. Проверить параметры базы данных. Если сайт на «Битриксе» — сколько и какие сторонние модули используются, есть ли модификации ядра.
  Проверить интеграции — работают или нет, по каким причинам перестали функционировать и так далее. По итогам аудита можно будет поставить диагноз проекту, оценить объем и стоимость работ, определиться с дальнейшими шагами.

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

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

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

Это позволяет не писать ТЗ на весь объем доработок, а разбить задачи по степени их важности и самые актуальные сразу забрать в работу. Мы, например, работаем двухнедельными спринтами — блоками задач от 60 часов.

Читайте также:

Запуск востребованного FinTech-продукта в кризис: что необходимо учесть?

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

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

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

Как выбирать подрядчика в 2022 году

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

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

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

• Поинтересуйтесь составом команды разработчиков: сколько человек работают в офисе, отдаются ли задачи на аутсорс и в каком объеме. Удаленных специалистов лучше привлекать на автономные задачи, а потому их общий процент не должен превышать 20-30%.
• Обратите внимание, как развивалась команда в последние месяцы, были ли сокращения, каков процент новичков? Если в проекте участвуют джуны или стажеры, это не повод отказываться от исполнителя, но стоит уточнить, как контролируется качество их работы.

Советы заказчикам

В нынешней турбулентной ситуации вероятность остаться с незавершенным проектом на руках возрастает в разы. Снизить риски помогут пять простых правил:

• Не привязывайте себя к одному исполнителю, выбирайте широко распространенные технологии;
• Тщательно выбирайте исполнителей;
• С особой осторожностью выбирайте сторонние интеграции, отдавая предпочтение отечественным вендорам;
• После каждого этапа требуйте от исполнителя артефакты. У вас должны быть все материалы для продолжения проекта;
• Не работайте «в стол», запускайте MVP и сразу наполняйте проект реальным контентом, корректируйте планы с учетом обратной связи.

Фото: Unsplash