«После нас никакого потопа»: объясняю, как передавать проект от одного подрядчика другому

Руководитель проектного офиса AGIMA делится 10 правилами, которые сделают проект прозрачным для заказчика и подрячиков.

«После нас никакого потопа»: объясняю, как передавать проект от одного подрядчика другому

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

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

Что я имею в виду, проще объяснить на примере. Предположим, к нам приходит заказчик с интересным проектом. Раньше этим проектом занималась другая компания, но не сложилось. Мы начинаем погружаться в проект и понимаем, что ничего не понимаем. Где доступы? Как выглядит архитектура? Какие технологии использовали? Где нам взять таких специалистов? Правила хорошего тона — вести проект так, чтобы его в любой момент было не стыдно передать дальше по цепочке.

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

Почему я вообще об этом говорю

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

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

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

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

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

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

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

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

10 правил, как сделать проект прозрачным

  1. Четко определитесь с границами ответственности каждого подрядчика внутри проекта и обозначьте их для всех.

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

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

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

2. Документируйте всё, что возможно.

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

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

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

  • к макетам интерфейса должен прилагаться UI-кит и описание;
  • к реализованной фиче — техническое задание;
  • к задаче — критерии завершенности (DoD) и критерии готовности (DoR);
  • к API — спецификация;
  • к подключаемым сервисам — список доступов.

А еще:

  • архитектурные схемы или описанные потоки данных;
  • тест-кейсы;
  • инструкция администратора.

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

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

Хороший тест для самопроверки: представьте, что вы только что присоединились к проекту. Уверены ли вы, что знаете куда идти? А если знаете, то потому что это очевидно или потому что вы хорошо разобрались в проекте? А если это будете не вы?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. Коробка коробке рознь.

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

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

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

7. Берегите и пользуйтесь экспертизой.

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

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

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

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

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

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

8. Составьте план перехода проекта в новые руки. Вместе.

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

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

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

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

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

9. Напишите кейс. Хотя бы согласуйте :)

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

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

10. Не пренебрегайте лучшими практиками и промежуточными процессами. Данные почти всегда лучше, чем экспертная оценка.

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

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

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

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

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

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

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

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

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

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

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

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

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

2121
19 комментариев

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

2
Ответить

Вот согласна с вами. Тоже интересно, как же выработать эту привычку.

1
Ответить

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

1
Ответить

Попробуйте использовать корпоративный софт. У него есть функции, позволяющие в 2 клика перенести данные уволенного сотрудника без потерь)

1
Ответить

Был опыт, когда собирали в районе полу года все артефакты по проекту. Когда все системно, это прекрасно!

1
Ответить

Очень полезная статья, спасибо!

1
Ответить

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

1
Ответить