Разработка MVP в симбиозе: как подружить инхаус-команду с аутсорсерами
Думаете, организовать работу в связке «инхаус — аутсорс» сложно? Понимаем, страшно же: вдруг подрядчик профакапит свою часть, команды не сработаются, а от блестящей идеи стартапа останется только богатый жизненный опыт. Но если правильно выстроить процессы, можно получить крутой результат, от которого выиграют все.
Привет, меня зовут Эльвира, я проджект-менеджер в Purrweb — студии разработки MVP для стартапов и бизнеса. Мы часто делаем продукты в симбиозе с клиентом. Например, если нужно помочь с аналитикой, фронтендом или дизайном мобильного приложения.
Аутсорс часто выручает, когда на разработку в инхаусе мало времени или нужно добавить в продукт уникальную экспертизу. Но в начале сотрудничества у некоторых клиентов возникает опасение: а что, если команды не сработаются? А вдруг проект пойдет не по плану: конфликты, недоделки, ночной фикс багов — такие сценарии могут здорово напугать.
Но хочу вас успокоить: так бывает не всегда. А в проектах с хорошо организованным менеджментом не бывает и вовсе. В статье дам пошаговую инструкцию, которая поможет подружить инхаус с аутсорсом. Читайте, перенимайте и пользуйтесь на здоровье.
Шаг 1. Познакомить команды и презентовать им план работ
Бывает так, что в начале проекта команды видят друг в друге конкурентов. Но на моем опыте это происходит из-за недостатка коммуникации. На этапе знакомства важно донести до инхауса, что их не хотят заменить, просто каждый будет отвечать за свои задачи. А до аутсорса — что никто не будет учить команду правильно работать или ставить под сомнение их экспертизу.
⭐ Лайфхак: чем больше общения между всеми участниками проекта, тем быстрее уходит конкуренция. В среднем команды привыкают друг к другу за пару недель, при условии что вы правильно представили их друг другу и обеспечили условия для дальнейшего общения.
Вот как правильно познакомить инхаус- и аутсорс-команды 👇🏻
✔️ Организовать общую встречу — перед началом работы представьте команды друг другу. Проведите установочный митинг: на нем стоит разобрать глобальный пул задач и определить критерии конечного результата разработки. Так каждый сотрудник проекта с первого созвона будет знать, кто и за что отвечает.
✔️ Наметить первые шаги внутри команд — у каждой команды будут свои задачи, из которых строится общий результат. На следующих встречах вы сможете «подружить» внутренние планы между собой и наметить контрольные точки проекта.
Больше о контрольных точках в разработке MVP мы рассказывали в этой статье.
Кейс из практики. Однажды мы работали над приложением для вендинговых автоматов — умных холодильников с готовой едой Vendify. Нам предстояло сделать дизайн, а еще архитектуру для фронтенда, чтобы он мог общаться с железом и бэкендом клиента. Мы собрали команду из проектного менеджера, UI/UX-дизайнера и двух фронтенд-разработчиков.
Сначала подготовили концепт интерфейса: сделали темную тему, под стать холодильнику. А еще прикрепили фотокарточки — реальные продукты из вендингов Vendify. Чтобы зафиналить этап, познакомили дизайнера с клиентом, хотя обычно стараемся не грузить творческих сотрудников созвонами. Это решение помогло быстро утвердить правки и двигаться дальше.
Стек (набор инструментов) заказчики выбрали сами. На бэке они использовали Ruby on Rails, а мы работали с React Native. Бэк и фронт писали параллельно, а ход работы и важные решения обсуждали в Slack или на созвонах. В итоге уложились в сроки и зафиналили MVP за шесть недель.
Смотрите, каким получилось приложение для Vendify 👇🏻
Шаг 2. Назначить сроки, ответственных и рассчитать KPI
Глобальные договоренности по проекту должны быть едиными. Разумеется, у каждой команды есть внутренние показатели, но нужно назначить и общие дедлайны. Так инхаус и аутсорс смогут «встретиться на середине моста» и вовремя зафиналить продукт.
Чтобы синхронизироваться по срокам и промежуточным результатам, я рекомендую создать несколько чатов и обо всем договариваться в них 👇🏻
- Общий чат по проекту с заказчиком — чтобы устанавливать главные договоренности. А вот информации по ходу работы там должно быть немного, иначе можно запутаться.
- Отдельный чат для разработчиков — чтобы обеспечить контакт ребят, которые работают с кодом. Например, когда одна команда пишет бэк, а вторая — фронт.
Для хорошего результата важно обеспечить прозрачность коммуникации и не уходить общаться в личку. Иначе вторая команда не поймет, как продвигается разработка и всё ли получается сделать в срок. Например, однажды у меня была ситуация, когда тимлид установил новые договоренности, а я была не в курсе. Так делать не стоит.
⭐ Лайфхак: чтобы грамотно определить договоренности по проекту, подготовьте контракт с эндпоинтами. Эндпоинты — это перечень пунктов в API или описание способов, с помощью которых одна команда взаимодействует с другой. Здесь важно договориться, в каком формате и кто будет отправлять информацию, а еще кто и как будет ее принимать.
Контракт с эндпоинтами поможет не стопорить разработку. С ним бэкенд и фронтенд могут работать параллельно. В ином случае фронт будет ждать бэка, чтобы уже в реальности посмотреть, что и как тот отдает. С контрактом всё будет прозрачно.
Кейс из практики. Нужно было адаптировать CRM производителя сельхозтехники Koblik Group под мобильную версию. За флоу отвечал наш системный аналитик. Ему предстояло понять, какие функции нужны менеджерам компании для работы в полях. Он общался с заказчиком и выявлял их потребности. Без лишних функций CRM клиента сократилась до трех разделов: «Календарь», «Партнеры» и «Интересы».
Разработку начали с проектирования. Процесс был непростым: разработчики на стороне клиента оказались заняты внутренними задачами. Но ежедневная связь в чате, созвоны и здоровая взаимопомощь помогли избежать факапов и ускорили работу. В итоге мы сделали понятный API-контракт. В нем описали, какие данные поддерживает приложение, какие запросы будут поступать на сервер и что ожидать в ответ. Благодаря контракту разработка заняла всего два месяца.
Листайте галерею, чтобы увидеть финал нашей работы с Koblik Group 👇🏻
Шаг 3. Дать доступ всем участникам к любой информации по проекту
Таск-трекеры, хранилища и файлы, где лежит важная информация по проекту, должны быть открыты для всех. Так можно сразу предоставить доступ, как только появляется что-то новое. В этом случае у команд не будет задержек в работе и участники смогут оперативно найти нужные данные.
У проекта также должна быть общая доска в любом таск-трекере, например в Jira или Clickup. Даже если для какой-то из команд это окажется неудобным, будет общее видение проекта и возможность свериться с глобальными целями. А еще общая доска поможет участникам проекта чувствовать себя частью большой команды, а не разрозненными группами.
⭐ Лайфхак: не ведите таск-трекер ради таск-трекера. Если вашей команде неудобно работать на общей доске, договоритесь, кто и для каких целей будет ее использовать. Например, можно сделать несколько уровней, где будут фиксироваться задачи по разным этапам разработки.
Шаг 4. Наладить коммуникацию и погрузить команды в продукт
Интересно, что некоторые люди всё еще боятся созвонов или считают их излишними. Мне кажется, что проговаривать голосом важно не только промежуточные результаты, но и некоторые непонятные моменты.
⭐ Лайфхак: если вы спустя 5–10 сообщений не понимаете коллегу, лучше созвониться. Это экономит время всех участников проекта. В переписке есть много подводных камней: можно потратить на сообщения целый день и всё равно неправильно увидеть ситуацию.
Чтобы не срывать дедлайны по спринтам и контрольным точкам, мы внедряем в работу техническое проектирование и риск-менеджмент. Суть в том, что возможные проблемы и риски лучше просчитать еще до старта проекта. Заранее продумать «пути отхода», а не искать решение, когда твоя или чужая команда уже в огне.
Кейс из практики. Нам доверили сделать приложение для криптокошелька Broex. Чтобы приступить к разработке, нужно было быстро разобраться в мире крипты. Клиент пришел к нам с готовой веб-версией продукта, а вот с мобильным приложением не задалось. Нам предстояло зарелизить кросс-платформенное приложение, чтобы сразу выйти в App Store и Google Play, причем используя бэкенд, который писали не мы.
Для работы с блокчейном и криптовалютой мало уметь хорошо разрабатывать приложения, в этом нужно разбираться глубже. Понимать, как происходит покупка, обмен, перевод и вывод криптовалюты. И не забыть про округления, подсчет баланса и комиссию. В общем, изучать тему нам пришлось максимально подробно. В ином случае мы не смогли бы работать с бэком заказчика и обеспечить для пользователей удобный и безопасный флоу.
Покажем парочку экранов из приложения 👇🏻
Шаг 5. Вместе собираться на показ промежуточных результатов
Процесс работы над продуктом мы по классике делим на спринты. Один спринт — один этап разработки. Чтобы синхронизироваться в течение спринта и обсудить его результаты, мы постоянно общаемся в разных форматах.
Вот все важные встречи и обсуждения 👇🏻
✔️ Дейли — ежедневная летучка для синхронизации внутри команд. Если вы работаете в связке «инхаус — аутсорс», проводить дейлики всем вместе каждый день необязательно. Но встретиться на 15 минут со своей командой — это must have.
✔️ Синки — текстовые дейлики. Их не всегда нужно проводить каждый день. Но если чувствуете, что проекту недостает прозрачности, смело пробуйте этот формат.
✔️ Викли — еженедельная встреча, на которой обсуждают накопившиеся вопросы. Обычно приглашаем на нее обе команды, чтобы не потерять связь друг с другом (и с реальностью).
✔️ Ретро — встреча, на которой подводим итоги спринта. Здесь можно и нужно рефлексировать. Задача этапа — понять, что получилось классно, а над чем еще стоит поработать.
⭐ Лайфхак: не молчите, если что-то идет не так. Отражайте это в синках, в чате разработки или на дейликах.
Шаг 6 (при желании клиента). Подвести проект к выдаче в инхаус
Бывает так, что после совместной работы клиент забирает проект полностью в инхаус. Это не должно стать трагедией для аутсорс-команды, как и не должно стать стрессом для инхауса клиента.
Рассказываем, как отпустить проект в большое плавание, на примере кейса Purrweb 👇🏻
Кейс из практики. Мы разработали MVP для дистанционного ремонта в Эмиратах. Приложение Settler помогает контролировать этот трудоемкий процесс из любой точки мира.
Пользователь может наблюдать за этапами ремонта: что уже готово, что в процессе и что планируется сделать в будущем. А еще мы добавили во флоу контроль за расходами: бюджет проекта, чеки и счета. Нам удалось сэкономить клиенту больше 12 000 $ на технологиях, а потом он всё-таки решил развивать проект со своей командой.
Чтобы переход Settler в инхаус получился максимально нетравматичным, мы продумали универсальный план. Делимся им с вами 👇🏻
✔️ Собрали документацию. Мы подготовили документ с доступами ко всем сервисам и перечислили неприоритетные баги в отдельном файле. А еще сверились по критериям приемки и оставили клиенту результаты тест-кейсов.
✔️ Обновили UI kit. Привязали все стили, варианты и состояния. Собрали файл в Figma со всеми экранами и сделали в нем удобную навигацию по сценариям и ролям.
✔️ Собрали файл с планами и идеями развития, которые обсуждали с клиентом. Со стороны клиента был продакт-менеджер — сделали для него документ, в котором описали все сущности в панели администратора, роли и основные флоу. А еще дали советы по подбору команды.
✔️ Провели созвоны по процессам внутри проекта и сделали онбординг. Рассказали новым сотрудникам о том, как всё устроено в коде и какие инструменты мы использовали. Затем ответили на вопросы и передали код.
✔️ Сделали чат с разработчиками. Это облегчило работу команды на первых порах и помогло справиться с трудностями.
Листайте галерею, чтобы посмотреть дизайн и флоу Settler 👇🏻
Коротко: как организовать работу в формате «инхаус — аутсорс»
✅ Проведите установочную встречу для всех участников проекта. Распределите роли и обсудите глобальные цели.
✅ Создайте несколько чатов: первый — чтобы фиксировать глобальные договоренности, второй — чтобы обсуждать ход разработки. Общайтесь только в чатах, а в личках не общайтесь.
✅ Сделайте общую доску по проекту и откройте доступ для всех участников. Не забудьте и о доступах к отдельным хранилищам и файлам.
✅ Встречайтесь со своей командой на дейликах, чтобы наметить планы на день. И раз в одну-две недели — с клиентом, чтобы не упустить контрольные точки.
✅ Не молчите, если что-то идет не по плану. Разговаривайте с коллегами на созвонах или в чате.
✅ Если планируете забрать проект в инхаус, запросите у подрядчика документацию по проекту и вместе проведите онбординг для своей команды.
Если вы хотите узнать больше о том, как работать с аутсорс-командами, приходите к нам на сайт. А в комментариях рассказывайте: какими лайфхаками пользуетесь для сотрудничества в формате «инхаус — аутсорс»? 👇🏻
Блин, как к людям приходят эти гениальные идеи стартапов? То холодильники, то ремонт в Дубаях…
А как можно посчитать все риски до старта проекта? Не предугадаешь ведь, если кто-то из сотрудников, например, заболеет… Или речь о каких-то других рисках?
Прям все риски не получится просчитать и минимизировать:) Но хотя бы существенную часть получится.
Мы это делаем так:
1. С командой в рамках часа накидываем любые идеи, где и что может пойти не так. Сюда попадают как больничные или смены тиммейтов по какой-то причине, так и проблемы с интеграциями сторонних сервисов или особенности тестирования продукта.
2. Дальше проектный менеджер и тимлид оценивают разрушительность последствий и вероятность каждого риска. Так мы определяем, что вероятнее пойдет не так, и что больше всего повлияет на проект — на предотвращении этого надо будет сфокусироваться.
3. В итоге составляем план по предотвращению наступления риска и план отходной — что будем делать, если риск все же наступил.
У вас много рассказано про превентивные меры. Ну а что например делать, если кто-то все-таки поругался?
Если кто-то начинает ругаться, не стоит бояться. Это значит, что команда сделала первый шаг к формированию внутрикомандных правил =)
На этом этапе важно сделать 2 вещи:
1. Помочь ребятам в моменте решить проблему: выслушать обе стороны и прийти к компромиссу.
2. А дальше важно выявить правило/урок на будущее, чтобы подобные ситуации больше не возникали.
Например, тестировщик не так или не туда перетаскивал карточки в Jira, а это бесило разработчика. Первое — мирим разработчика и тестировщика, говорим разработчику, что тестировщик не из злых намерений это делал =) Второе — фиксируем и доносим до команды тестировщиков следующее: «чтобы разработчики не злились, дорогие тестировщики, перетаскивайте карточки вот так».
Интересно, но как участники проекта будут больше общаться, если по сути каждый из них сидит над своей задачей, а видятся они раз в 1–2 недели?
Если инхаус и аутсорс командам нужен общий созвон только один раз в 1-2 недели — это же отлично =) Никто не отвлекается от работы, времени на обсуждения уходит мало, а результат делается.
На нашей практике так происходит очень редко. Чаще на небольших проектах с логикой средней сложности. Там основная коммуникация идет на старте. В случае если же проект сложный, неизбежно будет больше коммуникации.