Смена подрядчика: как не наступить на старые грабли
Привет! Меня зовут Анна, я возглавляю направление бизнес-решений ИТ-компании SimbirSoft. За более чем 20 лет работы нам приходилось не раз «спасать» ИТ-продукты после разных ситуаций у клиентов, в том числе после предыдущего подрядчика. Сегодня об этом и поговорим. Расскажу, что и как делать в этой ситуации.
К подрядчику, который перенимает продукт от предыдущей команды, требования зачастую выше, чем к тем, кто был до него. Создать продукт с нуля легче, чем переделывать за кем-то. Для этого нужно:
- проанализировать состояние того, что досталось от предшественников – не только код, но и процессы, документацию, иные наработки
- выяснить, что с этим делать, что можно переиспользовать, принимая во внимание все возможные риски
- определить, что лучше переписать заново
- решить, как довести продукт до ума, если это требуется, и далее его эффективно развивать.
Смена подрядчика – это непростой и ответственный процесс, поэтому сначала предлагаем критически оценить текущую команду, действительно ли в ней причина.
А может и не стоит менять подрядчика?
Перед принятием решения о смене подрядчика стоит внимательно изучить:
- Артефакты, по которым планировался проект: предварительная оценка проекта, коммерческое предложение, оценка рисков и даже предварительное ТЗ.
Возможно, вы все еще опираетесь на те данные, которые были изначально, а проект претерпел изменения, и у вас все еще устаревшие ожидания и неверное представление о текущей ситуации. - Процессы разработки, коммуникации в команде.
Возможно, вам стоит скорректировать процессы работы на проекте, принимать участие в планировании спринтов, получать отчеты и присутствовать на ретроспективах или дейли-митингах, фиксировать изменения и договоренности. Вполне вероятно, что стоит добавить в команду управленца, тимлида, который поможет взять дело в руки. В результате текущая команда будет работать “как часы” и показывать желаемые результаты. - Этапы разработки и наличие специалистов на проекте.
Есть вероятность, что какие-то члены команды занимаются не своим делом: тестировщик должен тестировать, а не писать ТЗ, выявлять и согласовывать требования должен аналитик, а не разработчик, регрессионное тестирование надо заменить автотестами и делать это должен специально обученный для этого человек, а не «кто-то из текущего состава, который когда-то это видел и трогал». И не стоит пропускать важные этапы работ, например: не выяснив четко требования к фиче и начав ее реализовывать, вы рискуете переделывать ее несколько раз (а это время и деньги).
Анализ этой информации позволит сделать переоценку проекта, скорректировать процессы работы команды или дополнить ее новыми специалистами с необходимой квалификацией. Например, вы понимаете, что для решения определенного блока задач на проекте нужен DevOps или какой-то другой специалист, которого у вас нет. Значит вам нужно будет просто взять его на аутстаф. В этом случае костяк команды останется прежним, вы просто ее усилите.
Одна компания из сферы металлургии обратилась к нам за аудитом процессов ИТ-разработки на текущем проекте. Среди основных проблем, которые побудили их обратиться за экспертным мнением: трудности во взаимодействии между подкомандами и подразделениями, а также срыв сроков по важным задачам и релизам, невыполнение приоритетных для бизнеса фич. Наши специалисты выявили узкие места в процессе управления и разработки. В частности, низкий уровень планирования и недостаточное взаимодействия внутри команды, недостаточную проработку и описание задач в таск-трекере, выход за дедлайны, перегруз руководителя проекта и т.п. По итогам наши эксперты подготовили рекомендации по всем направлениям, в том числе с учетом масштабирования системы. В завершение привели список метрик, по которым клиент смог отслеживать внедрение улучшений. В результате клиенту удалось сохранить команду, усилив ее нужными специалистами, и наладить процессы разработки.
Всё-таки стоит: на что обратить внимание
Если вы все-таки приняли решение работать с новой командой и выбрали несколько компаний (по рекомендациям/отзывам, соответствию технического стека и опыту в вашей сфере), какой же следующий шаг? Спросите компанию, как они «перенимают продукт» и был ли у них подобный опыт?
Как правило, за некоторыми исключениями, схема выглядит следующим образом:
- Изучение продукта – новый подрядчик должен разбираться в идее и бизнес-цели продукта, чтобы в дальнейшем понимать, какие задачи пользователи и бизнес должны решать с помощью него.
- Аудиты – подрядчик должен знать, в каком состоянии к нему приходит продукт и как с этим «наследием» работать дальше.
- Опираясь на результаты аудита и планы заказчика по улучшению продукта (бэклог), подрядчик решает, что:
– нужно исправить немедленно
– мешает эффективному развитию (ключевое слово «эффективное»)
– сделать для «гармоничного» развития продукта.
- После составления плана – классическая схема разработки: Аналитика+Дизайн+Разработка+Тестирование+Релиз.
Приступив к разработке без проведения исследования «наследия», вы рискуете усугубить ситуацию и «закопать» проект еще глубже. Это схоже с тем, как лечить пациента без постановки диагноза – можно угадать и вылечить, а можно....
Что должен спросить подрядчик
Что было
- Причины смены подрядчика
- Боли: что конкретно не устраивает
- Бизнес-потребности: для чего/ кого продукт делается
Что есть
- Отношения со старой командой: можно ли с ними взаимодействовать
- Исходники: есть ли они, где находятся, хранилась ли версионность и т.п.
- Наличие каких-либо полезный артефактов: техническая документация, ТЗ, руководства и т.п.
- Отчеты каких-либо предыдущих исследований
Что будет
- Ожидания клиента от новой команды и от продукта: цели сейчас и на несколько лет вперёд
- Время, которое клиент будет уделять проекту
Эти вопросы подтвердят: компания имеет опыт приемки проектов и знает, что делать. Такой подрядчик поможет разобраться, на какой стадии находится ваш проект сейчас и чего ждать в будущем.
P.S. Аудит: что новый подрядчик должен вам предложить
Объем аудита зависит от продукта и его назначения. Если задача приложения – продавать, то недостаточно написать идеальный код. Для начала нужно изучить впечатления пользователей от приложения, проверить User Experience (UX). Если он не соответствует задачам бизнеса – приложение не будет продавать. В этом случае – спасать надо не код, а интерфейс (дизайн, дизайн, UX writing, UI), т.е. ту часть, которая взаимодействует с клиентом. Итак, что может входить в аудит:
- аудит кода (обязательно)
- тестирование функционала (обязательно)
- аудит архитектуры, БД, инфраструктуры (крайне желательно)
- UX-аудит
- аудит процессов (полезно провести, чтобы понять, как ранее разрабатывалось приложение)
- аудит документации (ТЗ, руководства, мануалы, инструкции)
- аудит на соответствие требованиям регуляторов (аудит безопасности, соответствия законодательству, например ФЗ-152 и т.п.)
Даже учитывая тот факт, что аудит больше нужен команде разработки, а не заказчику, как минимум по результатам процедур должны быть созданы:
- отчет о текущем состоянии;
- рекомендации к исправлению.
Важно! Опытный подрядчик предлагает один или несколько возможных вариантов решения проблемы. Вы сможете выбрать наиболее подходящий вам, опираясь на бюджет, требования и сроки.
Один из последних наших примеров по «спасению» логистического сервиса. Понимая, что предыдущая команда разработки не укладывается в установленные сроки и подозревая, что в результате страдает и качество кода, клиент обратился к нам за аудитом, поскольку ранее уже имел опыт работы с нами. Далее мы провели клиенту полный аудит (в соответствии со списком выше), дали рекомендации, и он принял решение сменить команду.
Кроме того, результаты могут быть неожиданными: иногда проще сделать всё с нуля, чем переделать то, что есть. Возможно, после аудита вы поймете, что можно скорректировать что-то в старой команде и не менять её. Подробнее о нашем подходе – здесь.