How to properly transfer a project from one contractor to another

Привет! Меня зовут Наташа Тарасова, и я уже 6 лет работаю в AGIMA, из которых 2 года руковожу проектным офисом. За это время я повидала разного: были многолетние проекты, которые мы делали под ключ, были короткие, в которых мы отвечали за отдельные этапы. Где-то нам приходилось работать самостоятельно, где-то с командами других агентств.

Но неизменным оставалось одно: мы всегда соблюдали правила хорошего тона.

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

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

Сложности, которые возникают при передаче проекта, известны. Но почему-то из раза в раз разные компании допускают одни и те же ошибки.

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

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

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

Вот примеры того, что надо задокументировать и передать:

А еще:

Ни одна часть продукта не должна остаться «голой».

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

Любой тестировщик без подготовки разберется, где находится авторизация и регистрация. Скорее всего, он быстро этот функционал проверит. А вот чтобы понять, что проверять в задаче «Добавить КИД в полисы и методы для их вывода», ему точно понадобится время и ответы команды разработки.

Или документация.

3. Думайте о будущем, когда создаете доступы.

Например, на этапе MVP в спешке вы можете зарегистрировать какой-то интегрируемый сервис на тимлида подрядчика. Просто потому, что он с ним чаще работает и ему оттуда нужны СМС-сообщения для команды. И вообще вы ему доверяете.

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

4. Привлекайте экспертов со следующего этапа.

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

Поэтому полезно брать в команду тех, кто будет работать над продуктом на следующем этапе. Особенно это резонно, если у команды возникают вопросы типа:

• А как это будет, если изменятся условия?
• А откуда и куда будут идти данные?
• А какая гибкость здесь предусмотрена?

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

Кто подойдет лучше всего:

• системный аналитик — его функции могут быть переданы бизнес-аналитику (но только если тот обладает нужными компетенциями) или он может быть самостоятельной единицей;
• тимлид команды разработки или архитектор — это тоже вполне может быть один специалист;
• Backend-разработчик — чтобы выявить узкие места в логике;
• Frontend-разработчик — чтобы выявить недостающие состояния или правила поведения элементов на экране;
• продуктовый аналитик — чтобы выявить устаревшие сценарии и спрогнозировать поведение пользователей.
  

Всем этим ребятам в совокупности понадобится часов 20–40. И это будет намного дешевле, чем заложить риски на неопределенность функционала. Привлекать хедов и специалистов, работающих руками, полезно. Фронтендер, может, и не увидит общей логики функционала, как увидит архитектор или тимлид, но он не упустит отсутствие ховера и примера анимации в нужном месте.

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

Но происходит обратное. Каждая вторая студия задает вопросы, указывает на нестыковки и предлагает свои способы с ними справиться:

• работать по формату Time & Materials, чтобы переложить риски на заказчика;
• установить ограничения на функционал, чтобы вовремя предложить оправданный допкост;
• заложить риски и надеяться не проиграть потом по цене;
• провести дорогое предпроектное обследование, чтобы выявить все узкие места, а потом пересмотреть предложение.

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

5. Будьте аккуратнее с новыми технологиями при работе вдолгую.

У студий и агентств иногда появляется новая идея, которую они очень-очень хотят развивать. Я их понимаю. Вы тоже наверняка понимаете. Глаза горят, все разговоры только о ней — о новой технологии, которая перевернет мир. Хороший пример — chatGPT, Midjourney и другие хайповые нейросети.

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

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

Вопросов — море. Прежде чем согласиться на эксперимент, задайте их себе несколько раз.

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

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

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

Обсудите, как будут выстроены отношения с командой после завершения проекта.

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

Конечно. И вот чем:

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

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

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

Сначала небольшая история.

Эта история закончилась печально. Команда получила лишний стресс в момент переезда. Разумеется, мы восприняли происходящее как сбой, который не смогли предотвратить. Благо, мы быстро сообразили, что происходит на самом деле.

Что в итоге? Заказчик мог получить от нас любую помощь по подготовке к переходу, а вместо этого делал двойную работу. За остаток периода поддержки ему всё равно пришлось заплатить в соответствии с договором.

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

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

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

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

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

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

В списке этапов было вот что:

• этап формирования гипотез;
• этап разработки UI-концепции;
• этап разработки UX-прототипов;
• этап проведения UX-тестирования прототипов на разной целевой аудитории (и готовность предоставить контакты активной ЦА);
• этап разработки финальных дизайн-макетов.
  

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

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

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

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

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

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

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