«После нас никакого потопа»: объясняю, как передавать проект от одного подрядчика другому
Руководитель проектного офиса AGIMA делится 10 правилами, которые сделают проект прозрачным для заказчика и подрячиков.
Привет! Меня зовут Наташа Тарасова, и я уже 6 лет работаю в AGIMA, из которых 2 года руковожу проектным офисом. За это время я повидала разного: были многолетние проекты, которые мы делали под ключ, были короткие, в которых мы отвечали за отдельные этапы. Где-то нам приходилось работать самостоятельно, где-то с командами других агентств.
Но неизменным оставалось одно: мы всегда соблюдали правила хорошего тона.
Чтобы таких проблем не возникало, компания-заказчик может следовать простым правилам. В этой статье я объясню, как выстроить отношения с подрядчиками так, чтобы всем было комфортно на любом этапе: от конфетно-букетного начала до момента, когда в проект нужно передать другой команде — например, инхаус.
Почему я вообще об этом говорю
Существует много стереотипов об агентствах заказной разработки. И хотя некоторые из них имеют под собой реальное основание, всё же большинство не выдерживают никакой критики. Один из таких стереотипов звучит примерно так: задача любого агентства — «подсадить» заказчика на свои услуги, максимально привязать к своим сотрудникам и экспертизе.
Мы любим и умеем работать с заказчиками годами. И надеемся, что так и будет дальше. Но важно понимать, что залог долгих и крепких отношений не только в отлаженных внутренних процессах исполнителя и заказчика, но и в умении исполнителя сотрудничать с другими командами.
Как правило, агентство в таких ситуациях начинает тянуть одеяло на себя или, наоборот, сдается. Но есть и такие компании, которые смело отвечают: «Конечно, давайте мы вместе поработаем и подстроимся друг под друга». Но получится ли?
Сложности, которые возникают при передаче проекта, известны. Но почему-то из раза в раз разные компании допускают одни и те же ошибки.
Ниже я объясняю, как настроить процессы на проекте таким образом, чтобы при переходе проекта от команды к команде никаких вопросов ни у кого не возникало.
Эти правила, конечно, будут интересны агентствам, которые занимаются заказной разработкой. Но в первую очередь я пишу их для заказчиков — именно вам нужно на берегу договориться с подрядчиком, как сделать проект прозрачным для всех.
10 правил, как сделать проект прозрачным
- Четко определитесь с границами ответственности каждого подрядчика внутри проекта и обозначьте их для всех.
Не загоняйте себя в ловушку, а агентство — в условия обманутых ожиданий. Это нормально периодически напоминать исполнителю, что проект должен быть отчуждаемым, даже если вы рассчитываете работать с этой командой долго. Хорошее агентство не оставит попыток развить с вами отношения. Поэтому они заинтересованы в том, чтобы сделать проект круто.
А круто сделанный проект можно в любой момент передать в инхаус-команду или другому подрядчику.
При работе же нескольких команд обязательно добейтесь того, чтобы границы ответственности были установлены до начала работ и согласованы между всеми участниками проекта. Любое непонимание и размытость обязательно приведет к лишним расходам.
2. Документируйте всё, что возможно.
Агентство должно помнить, что они делают продукт не для того, чтобы его обслуживать в будущем. Конечно, не исключено, что они действительно будут этим заниматься, но исходить из этой мысли при разработке вредно.
Вот примеры того, что надо задокументировать и передать:
- к макетам интерфейса должен прилагаться UI-кит и описание;
- к реализованной фиче — техническое задание;
- к задаче — критерии завершенности (DoD) и критерии готовности (DoR);
- к API — спецификация;
- к подключаемым сервисам — список доступов.
А еще:
- архитектурные схемы или описанные потоки данных;
- тест-кейсы;
- инструкция администратора.
Ни одна часть продукта не должна остаться «голой».
Соблюдать это правило должны не только подрядчики, но и сам заказчик. Всегда приятно передавать и получать проект, о котором заботились. А еще это снизит градус неопределенности, когда подключится новая команда. Ее оценки будут точнее. Да, документация отнимает время, но больше времени и нервов вы потратите на передачу дел и исправления, если ее не будет.
Любой тестировщик без подготовки разберется, где находится авторизация и регистрация. Скорее всего, он быстро этот функционал проверит. А вот чтобы понять, что проверять в задаче «Добавить КИД в полисы и методы для их вывода», ему точно понадобится время и ответы команды разработки.
Или документация.
3. Думайте о будущем, когда создаете доступы.
Например, на этапе MVP в спешке вы можете зарегистрировать какой-то интегрируемый сервис на тимлида подрядчика. Просто потому, что он с ним чаще работает и ему оттуда нужны СМС-сообщения для команды. И вообще вы ему доверяете.
Даже если это было очень удобно в процессе, убедитесь, что в конце концов всё доступно и переведено на сотрудников вашей команды. Это позволит вам потом передать все ключи нужному специалисту. Ни агентству, ни вам не захочется оказаться в ситуации, когда доступы нужны срочно, а сотрудник другой компании (!) недоступен.
4. Привлекайте экспертов со следующего этапа.
Продукт кто-то будет развивать. Когда сформированы бизнес-требования, приходят проектировщики. Когда разработаны прототипы, за проект берутся дизайнеры. После дизайна и бизнес-требований работать начинают системные аналитики. После них — разработчики. Потом команда поддержки.
Поэтому полезно брать в команду тех, кто будет работать над продуктом на следующем этапе. Особенно это резонно, если у команды возникают вопросы типа:
- А как это будет, если изменятся условия?
- А откуда и куда будут идти данные?
- А какая гибкость здесь предусмотрена?
Все эти вопросы можно задать огромному количеству специалистов. И тогда еще на ранних этапах можно будет понять, что дизайн не проработан или, например, масштабируемость архитектуры недостаточная. Вместо того чтобы предлагать команде «заложить риски на доработку дизайна», пригласите их в валидации этого дизайна поучаствовать.
Кто подойдет лучше всего:
- системный аналитик — его функции могут быть переданы бизнес-аналитику (но только если тот обладает нужными компетенциями) или он может быть самостоятельной единицей;
- тимлид команды разработки или архитектор — это тоже вполне может быть один специалист;
- Backend-разработчик — чтобы выявить узкие места в логике;
- Frontend-разработчик — чтобы выявить недостающие состояния или правила поведения элементов на экране;
- продуктовый аналитик — чтобы выявить устаревшие сценарии и спрогнозировать поведение пользователей.
Всем этим ребятам в совокупности понадобится часов 20–40. И это будет намного дешевле, чем заложить риски на неопределенность функционала. Привлекать хедов и специалистов, работающих руками, полезно. Фронтендер, может, и не увидит общей логики функционала, как увидит архитектор или тимлид, но он не упустит отсутствие ховера и примера анимации в нужном месте.
К нам регулярно поступают запросы на разработку сайтов или мобильных приложений на этапе, когда дизайн-макеты или прототипы готовы заранее. Мы беремся за декомпозицию проекта, изучаем макеты, находим нестыковки и уточняем сценарии пользователя у потенциального заказчика. В этот момент, как это часто бывает, заказчик уже завершил отношения с дизайн-командой, выработал весь бюджет и совсем не хочет возвращаться обратно. Он уверен, что макеты получились, и сейчас нам, потенциальным разработчикам, должно быть проще, а оценки наши будут точнее.
Но происходит обратное. Каждая вторая студия задает вопросы, указывает на нестыковки и предлагает свои способы с ними справиться:
- работать по формату Time & Materials, чтобы переложить риски на заказчика;
- установить ограничения на функционал, чтобы вовремя предложить оправданный допкост;
- заложить риски и надеяться не проиграть потом по цене;
- провести дорогое предпроектное обследование, чтобы выявить все узкие места, а потом пересмотреть предложение.
Вроде хотели сделать дешевле, быстрее и проще, а получилось дороже и сложнее. Мы тоже этого не хотели. Как разработчики, мы максимально счастливы, когда нам всё понятно. И счастливы дать вам точную оценку и взять за нее ответственность, не боясь выйти в минус в конце проекта.Как помочь себе этого избежать — написано в заголовке этого пункта.
5. Будьте аккуратнее с новыми технологиями при работе вдолгую.
У студий и агентств иногда появляется новая идея, которую они очень-очень хотят развивать. Я их понимаю. Вы тоже наверняка понимаете. Глаза горят, все разговоры только о ней — о новой технологии, которая перевернет мир. Хороший пример — chatGPT, Midjourney и другие хайповые нейросети.
Конечно, пробуйте, экспериментируйте, применяйте. Но! Если возникнет шальная мысль положить совсем новую технологию в основу продукта — подумайте 100 раз.
Причины чисто прикладные. Что будет с технологией завтра? Не вырастет ли до небес абонентская плата за доступ? Не появится ли ограничения по правам использования? Будет ли сообщество развивать технологию, или это станет игрушкой на два-три месяца? Найдутся ли специалисты, чтобы это поддерживать за адекватную стоимость? Или они превратятся в редких дорогих ископаемых-любителей?
Вопросов — море. Прежде чем согласиться на эксперимент, задайте их себе несколько раз.
6. Коробка коробке рознь.
Не только дорогие специалисты и выбранный стек технологий могут нести риски своей уникальностью. Как ни странно, это еще может быть и коробочная версия продукта. Прежде чем решить, что вы готовы взять «коробку» в основу продукта, убедитесь, что она достаточно распространена. Так вы будете уверены, что ее будут обновлять, а вы найдете людей, которые умеют с ней работать.
Делать самописный продукт в мире готовых решений тоже не нужно. Но не ставьте себя в ситуацию, когда вам будет доступна лишь «закупка у единственного поставщика». Лучше исследуйте рынок, посмотрите, кто и какие аналоги использует.
Как правило, коробочное решение, особенно в Enterprise-продуктах, не покрывает нужный функционал полностью. Поэтому нужно убедиться, что у поставщика есть несколько партнеров, которые смогут его доработать. А еще удостоверьтесь, что вы сможете найти специалистов для дальнейшей поддержки.
7. Берегите и пользуйтесь экспертизой.
Обсудите, как будут выстроены отношения с командой после завершения проекта.
Представим, что вы планируете нанять целый штат сотрудников для развития продукта, который создается сейчас в студии заказной разработки. Вам всё нравится, и хочется, чтоб было так же классно, но свое. Может ли в этом помочь сама студия?
Конечно. И вот чем:
- проконсультирует новую команду, проведет презентации и разработает инструкции — в рамках отдельных сессий или вообще на регулярной основе;
- составит требования к вакансии;
- выберет подходящие резюме из всех откликов;
- поможет увеличить количество откликов благодаря уточненным требованиям;
- проведет технические собеседования;
- проведет онбординг и будет контролировать новых специалистов;
- проследит за соблюдением стандартов разработки и качеством кода;
- сможет выделить специалистов в новую команду под вашим управлением в формате аутстаффа.
Да, специалиста, который был на проекте в одной команде, можно еще «выкупить» отдельно для работы в другой. Важно понимать, что в этом случае у вас будет больше ответственности. Зато адаптация новой команды к проекту пройдет мягко — под чутким контролем человека, который этот проект знает как свои пять пальцев.
Крупная студия заказной разработки формирует команды под новые проекты в несколько раз чаще, чем любая продуктовая компания. И уж тем более она понимает, кто потребуется для поддержки проекта, в котором сама принимает участие, как надолго нужен специалист и насколько в нем будет смысл. Берите и пользуйтесь этой возможностью — ваши HR будут вам благодарны.
8. Составьте план перехода проекта в новые руки. Вместе.
Сначала небольшая история.
Эта история закончилась печально. Команда получила лишний стресс в момент переезда. Разумеется, мы восприняли происходящее как сбой, который не смогли предотвратить. Благо, мы быстро сообразили, что происходит на самом деле.
Что в итоге? Заказчик мог получить от нас любую помощь по подготовке к переходу, а вместо этого делал двойную работу. За остаток периода поддержки ему всё равно пришлось заплатить в соответствии с договором.
Поэтому золотое правило: комфортный, расписанный по дням и по часам план перехода проекта из рук в руки облегчит жизнь в первую очередь вам самим. А подрядчик обязательно поможет его составить и учесть все подводные камни переезда.
9. Напишите кейс. Хотя бы согласуйте :)
Не так расстраивает проект, который закончился, как проект, который закончился в полной тишине. Поэтому оставьте возможность агентству рассказать об этом проекте, а себе — возможность собрать красивое воспоминание о том, как он начинался. Но главное, что вы получите от кейса — это PR и пополнение вашего собственного портфолио. Как правило, всё это вам достанется от агентства еще и бесплатно по вечной ссылке.
А если вы еще будете готовы представлять вместе с агентством проект в различных рейтингах и наградах — цены вам как заказчику не будет.
10. Не пренебрегайте лучшими практиками и промежуточными процессами. Данные почти всегда лучше, чем экспертная оценка.
Расскажу один из моих любимых примеров редизайна небольшого сайта. Ссылку пока дать не могу, но не исключаю, что в будущем она появится, пока простите за анонимность. Кейс очень простой, но он так прекрасен своей простотой, что я не перестаю восхищаться подходом заказчика.
Заказчик обратился к нам только за редизайном — команда разработки у него своя. Кроме самого сайта и подробного гайдлайна, у него было следующее:
- результаты UX-тестирования текущего сайта;
- перечень блокеров, выявленных пользователями;
- портреты целевой аудитории;
- перечень блокеров, которые выявил сам заказчик при попытках достичь целей сайта;
- список этапов, которым должен следовать подрядчик.
В списке этапов было вот что:
- этап формирования гипотез;
- этап разработки UI-концепции;
- этап разработки UX-прототипов;
- этап проведения UX-тестирования прототипов на разной целевой аудитории (и готовность предоставить контакты активной ЦА);
- этап разработки финальных дизайн-макетов.
Это очень здоровый подход к редизайну. Собрать данные, список блокеров, сформировать цель, предусмотреть этапность, сформировать видение look-and-feel, отделить дизайн от проектирования и приступить к детализированным макетам лишь убедившись, что мы движемся правильно со стороны интерфейсов. Каждый предыдущий этап призван минимизировать ошибки следующего.
Но главное — нам не пришлось убеждать заказчика в том, что это правильный и хороший путь. Он пришел с этим пониманием сам. Не скажу, что у нас был невероятно огромный бюджет и сроки на эту работу — но они были адекватными.
Мне даже неловко писать об этом проекте как о чем-то исключительном, но это действительно так. Мы смогли избежать конфликтов, избыточных итераций правок на многих промежуточных этапах, на которых в большинстве проектов они случаются — у нас были ответы на текущие и будущие вопросы. Мы привлекали команду продуктовых аналитиков еще до того, как открыли проект в Фигме. И результаты будущего исследования не свалились нам как снег на голову — потому что мы работали со сформированными гипотезами и перечнем известных проблем.
Никому не пришлось дважды платить и даже лишний раз нервничать. Зато мы лишний раз убедились, что хорошие процессы помогают развитию продукта, а не просто обвешивают его ритуалами и ненужными цифрами.
Это были мои 10 правил для компаний, которые работают с агентствами заказной разработки. Передавать проект из рук в руки бывает сложно и нервно, но если следовать этой инструкции, то проблем быть не должно.
Конечно, я не скажу, что мы не расстраиваемся, когда наше участие в интересном проекте заканчивается, и что мы совсем лишены профессиональной ревности. Но мы, как и большинство наших коллег по рынку, всегда помним, что готовим проект не для себя, а для заказчика. Поэтому принцип «после нас хоть потоп» — это не про нас. После нас никакого потопа.
Так что не бойтесь делать проекты с теми, с кем хочется. Даже если кажется, что всех этих ребят будет очень сложно сочетать между собой. Удачи!
Если у вас возникли вопросы, то я с радостью отвечу на них в комментариях под статьей — я всё читаю. А еще у AGIMA есть телеграм-канал об управлении проектами — там в чатике тоже можно спрашивать.
Очень часто сталкивались с такой проблемой даже внутри компании, когда человек увольняется и источников исходников не остается... Как же привить это в привычку менеджеров/клиентов, которые ранее работали на проекте вести все прозрачно ?
Вот согласна с вами. Тоже интересно, как же выработать эту привычку.
Это должно быть прописано в ваших регламентах, как один из обязательных пунктов - ведение документации проекта. Конечно, многие ленятся, но если ввести как обязательный пункт начнет работать.
Попробуйте использовать корпоративный софт. У него есть функции, позволяющие в 2 клика перенести данные уволенного сотрудника без потерь)
Был опыт, когда собирали в районе полу года все артефакты по проекту. Когда все системно, это прекрасно!
Очень полезная статья, спасибо!
Правильный пункт — документация. Еще и погружаться в процесс новые сотрудники будут быстрее. На счет компаний не уверена, все равно скажут, что все не так оформили.
Наташа, спасибо! Прикольная статья получилась. 💚
Интересный опыт! Возьму на заметку
Очень информативно и полезно к прочтению. Спасибо автору!
А если уже понял, что подрядчик глубоко в проекте, то как от него, грубо говоря, отделиться? Надо вместе с ним разработать план? А если он не хочет, увиливает?
Интересненько)
Спасибо за статью, интересно!
Передача проекта от одного подрядчика другому может быть сложным и трудоемким процессом. Однако, если вы следуете определенным шагам, вы можете сделать этот процесс более эффективным и менее стрессовым. Ниже приведены некоторые рекомендации, которые помогут вам передать проект от одного подрядчика другому:
1. Определите причины передачи проекта: Прежде чем начать передачу проекта, определите причины, по которым вы хотите передать его другому подрядчику. Это может быть связано с изменением бизнес-стратегии, неспособностью текущего подрядчика выполнить работу или любой другой причиной.
2. Составьте список задач: Составьте список задач, которые должен выполнить новый подрядчик. Это поможет вам не забыть ничего важного и даст возможность новому подрядчику лучше понять объем работы.
3. Подготовьте документацию: Подготовьте документацию, которая поможет новому подрядчику понять проект и его требования. Это может включать в себя технические спецификации, планы проекта, бюджет, график выполнения работ и другие документы.
4. Свяжитесь с новым подрядчиком: Свяжитесь с новым подрядчиком и обсудите с ним детали проекта, требования и сроки выполнения работ. Объясните ему, почему вы решили передать проект и как он может помочь вам достичь целей.
5. Передайте проект: Передайте проект новому подрядчику и убедитесь, что он полностью понимает задачи и требования. Предоставьте ему всю необходимую документацию и ресурсы для успешного выполнения работ.
6. Контролируйте выполнение работ: Контролируйте выполнение работ новым подрядчиком и убедитесь, что он выполняет задачи в соответствии с требованиями и сроками. Если возникают проблемы, свяжитесь с ним и попробуйте решить их вместе.
7. Завершите проект: Когда проект будет завершен, убедитесь, что все задачи выполнены в соответствии с требованиями и удовлетворяют вашим ожиданиям. Отправьте письменное подтверждение новому подрядчику о завершении проекта и благодарите его за работу.
ChatGPT постарался? Весьма неплохие пункты:)
"Правила хорошего тона — вести проект так, чтобы его в любой момент было не стыдно передать дальше по цепочке."
Мне кажется, это правило должно работать в любой сфере, круто когда чувствуешь, что твоя ответственность гораздо шире, чем рамки конкретно выполненной задачи!
Ну да, передавать проект это уметь надо) У нас вообще был случай когда сотрудник за пол часа до начала рабочего дня написал что увольняется и все, больше не появлялся)
А я правильно понимаю, что этой статьей вы учите клиентов подключать разные конторы к своим проектам?
Зачем?
Как будто это что-то плохое :)