Несколько месяцев назад наш клиент решил развивать продукт самостоятельно и собрать свою инхаус-команду. А мы в MobileUp решили собрать чек-лист приемки проекта для владельцев продуктов/руководителей/менеджеров. Рассказываем, как перенять проект и выстроить работу на своей стороне, не потеряв в качестве. Делимся чек-листом и другими наблюдениями.
Пошаговая передача проекта
Клиент занимался подбором, поиском и передачей проекта не один, а при помощи стороннего менеджера. Процесс длился порядка 4 месяцев и был разбит на несколько этапов.Такая длительность передачи была связана с объемом проекта, а также с тем, что у нас не было жесткого дедлайна.
Этап 1 – Знакомство и погружение
Погружение в проект, над которым мы работали более 7 лет – задача со звездочкой. Этап занял порядка 3-4 недель и начался с общего созвона команд. Мы познакомились, определили последующие шаги взаимодействия, зафиксировали зоны ответственности.
Также команде клиента требовалось с нуля настроить всю инфраструктуру на своей стороне: начиная от постановки задач в Jira, заканчивая настройкой CI/CD. Мы помогали разбираться в нюансах и отвечали на вопросы.
Этап 2 – Совместная работа
Нам показалось отличной идеей поработать над оставшимися задачами и выкатить финальные релизы вместе. Стоит отметить, что у клиента не было дедлайна передачи, скорее наоборот – хотелось сделать все плавно и не спеша, поэтому идею поддержали все.
Однако результаты радовали не так сильно: разработчики со стороны клиента были менее предсказуемы с точки зрения оценки выполнения задач, а также у них была своя внутренняя нагрузка, которую мы не контролировали. Это задерживало процесс, и мы отказались от идеи совместной работы, чтобы не затягивать с релизами, которые мы старались выпускать каждые 2 недели.
Этап 3 – Рефакторинг
Появление новых опытных разработчиков на проекте означает новые взгляды на архитектуру и инструменты. Важно обсудить техдолг и привести проект в максимально оптимальный для команды вид. Мы сформировали перечень задач, обсудили их необходимость и актуальность и учли предложения команды клиента.
Этот этап был последним для нас с точки зрения написания кода, но не последним во всем процессе.
Этап 4 - Консультирование
Мы не сжигали мосты в день последнего релиза, а договорились, что следующий месяц будем работать в консультативном режиме. Клиент забронировал порядка 16 часов работы нашей команды. Таким образом, при любых вопросах/проблемах мы могли подключить наших специалистов и помочь.
Чек-лист приемки
Документация
Мы передали следующую документацию:
- Технические задания
- Техническая документация (тех проектирование, описание архитектуры)
- Планы работ
- Гайды (например, по запуску проекта, тестированию, релизам)
- Тест-кейсы
- Отчеты о запуске автотестов
Вся она хранилась на Google Drive, к которому клиенту был предоставлен доступ.
Список инструментов
Мы составили таблицу со ссылками на инструменты, статусами выданного доступа и тестовыми учетными записями, если они имелись. Такой наглядный формат помог команде быстрее погрузиться и понять, чем мы пользуемся и у кого запросить доступ.
Дизайн
Мы использовали Figma, которую клиент скопировал к себе и выдал нам доступ на редактирование до конца передачи проекта. То есть мы вели работы уже в пространстве заказчика. Этот вариант оказался удобнее, чем передавать права нашего документа.
Код
Мы передавали коды платформ iOS и Android, автотесты и backend. Изначально мы предоставили команде доступ к нашему репозиторию, а после завершения всех работ они скопировали себе актуальный репозиторий. Это самый простой вариант передачи.
Оплаты и счета
Очевидно, но стоит проверить, что все акты подписаны, инвойсы оплачены и ни у одной из сторон нет открытых вопросов по документам и бухгалтерии.
Техдолг
Мы описали и оценили техдолг, который хотели сами взять в работу. Эту информацию мы посчитали важной для будущего развития проекта и тоже передали клиенту.
Учетные записи
После финальной передачи проекта нужно удалить учетки подрядчиков/клиентов и проверить, что в вашей инфраструктуре не осталось кого-то из другой команды.
Важные обстоятельства
Здесь мы хотим отметить моменты, которые периодически волновали нас и на которые стоит обратить внимание при приемке проекта и формировании команды.
Организация работы новой команды
Создание гармоничной эффективной команды – это сложно. Вы можете подобрать технических гениев, но, если внутри не будет коммуникации и слаженной работы, результаты вряд ли вас удовлетворят.
Периодически мы замечали, что в команде клиента многие работали как будто сами по себе, и проекту это явно не на пользу. Чтобы сработаться, нужно время, и его стоит закладывать в план работ. А еще – понимать, что первые пару месяцев новая команда будет менее эффективной, чем старая.
Подбор менеджера
Продолжая прошлый поинт: стоит взять в новую команду опытного менеджера, который грамотно организует работу. В нашем кейсе Jira переносили разработчики, а организационными вопросами занимался человек, который ранее не имел подобной зоны ответственности в проекте. При этом наш менеджер не обладал полномочиями управления новой командой. Конечно, с этим вполне можно жить, но иногда это было не очень комфортно.
Фидбэк по команде
Больше всего при передаче проекта работали и контактировали с новой командой именно мы, а не сам клиент. Иногда нас смущали некоторые моменты коммуникаций или формата работы – и эту обратную связь мы периодически эскалировали до клиента. На наш взгляд, информация о том, как ведет себя команда «в бою», важна и может помочь в дальнейшем.
Синхронизация
Иногда нам не хватало понимания того, чем занималась команда. Особенно это чувствовалось при попытке организовать совместную работу. Здесь помогут общие созвоны раз в неделю – для сверки направления движения и текущих задач.
Отпускаем с благодарностью
Скажем честно, было волнительно передавать проект, который мы развивали несколько лет. Мы не меньше клиента переживали о сохранении качества и темпов разработки. Но все получилось.
Этапы передачи проекта могут отличаться, и не всегда все будет гладко. Но, на наш взгляд, главное – быть небезразличным к продукту и поддерживать новую команду. Мы искренне радуемся успехам ребят и держим за них кулачки, верим, что все будет хорошо.
Автор Юлия Ларионова
Редактор Елена Майорова
Все ваши догадки верны, думаю все было ровно так как вы описали в комменте, а не так как написано в статье. Грустно, когда айти-компания не описывает кейсы правдиво,но как никак это статья направленная на «зацени какие мы классные,даже если это не так». Так же статья односторонняя и нет мнения о передаче от принимающей команды, даже если эта команда была не довольна процессами и состоянием кодовой базы и объемом технического долга, этого мы из статьи узнать не можем. Думаю долги по направлениям решались днями и ночами перед передачей по максимуму,что возможно было осилить за это время,чтобы так же показать себя и состояние проекта клиенту лучше чем есть на самом деле. Но у меня так же как и у вас сложилось мнение,что клиент от них сбежал, по какой причине можно только гадать, возможно проблема в команде которая даже судя по статье бегала жаловаться клиенту на его команду,вместо выявления проблем на своей стороне и это кринжово. Или же дело было не в выполнении договорённостей перед клиентом по поставке фич,что повлекло за собой срыв всех сроков релизов фич которые в свою очередь были очень важны клиенту с точки зрения бизнеса, это остается тайной, а хотелось бы раскрытия этой темы с работой над ошибками, что было бы честно к читателю и к самим себе. Если вдруг догадки не правдивы, вы конечно же молодцы,что так расстались с клиентом.
Спасибо за коммент 🙂
Достаточно подробно ответила в прошлом комментарии и постаралась осветить все интересующие моменты.
Еще раз выделю, что основной ценностью статьи мы посчитали именно краткий чек-лист, который могут использовать владельцы продуктов, а не кейс передачи конкретного проекта, поэтому многие детали взаимодействия не зафиксированы для краткости повествования.
Но все ваши вопросы справедливы и теперь у нас есть мысли об еще одной статье :)
Шикарная статья, спасибо 💥
Неплохой текст, но слишком сладенько получилось. На деле обычно всё не так радужно, чуть меньше пони и аромата малины. Часто проекты передаются с большим количеством проблем, хорошо если не фундаментально-архитектурных. Ну, в смысле, решаемых без глубокого переписывания в первые полгода. Хорошо, когда для релиза после приёмки его не приходится радикально дописывать и шлифовать, как по качеству так и по фичам.
Нет здесь ничего о спорных моментах по закрытию всех актов, приёмок и прочей документации и долгов по аналитике, проектированию, разработке и дизайну.
Ни слова о потенциальном конфликте команды аутсорсера и ин-хауз команды, точнее есть некая вялая критика домашней команды в выражениях "они какие-то слабомотивированные". На деле, найти нормальный контакт на уровне разработки очень тяжело, практически никакого интереса сотрудничать у команды аутсорса нет, они уже двумя ногами в новых проектах сидят и любое взаимодействие с домашней командой не входит ни в сферу интереса их самих, ни в интересы их руководителей, от ПМов до деливери.
Ну и 3-4 недели на весь процесс перехода разработки это конечно мало. 3-4 месяца для большого проекта с командой человек в 20 из разработчиков, аналитиков, дизайнеров, менеджеров и тестировщиков 3-4 недели это очень сжатые темпы. Интересно, чем вы так довели заказчика, что он в таком авральном режиме забирал проект домой)
О передаче проектов знаю не понаслышке, бывал по обе стороны этого процесса и не раз.
Но если я вдруг ошибаюсь, то рад за вас. Но всё же текст больше похож на рекламу типа "смотрите какие мы пупсики, мы даже с уходящим заказчиком розовые и пушистые"))))
Кирилл, спасибо за фидбэк и справедливые комментарии
Хочу обратить внимание, что изначальная цель статьи была не в описании конкретного кейса передачи проекта, а в создании чек-листа для владельцев продукта. Мы хотели сократить наш опыт до краткого плана, что стоит сделать/проверить/на что обратить внимание, поэтому не стали освещать множество деталей.
Вы задаете очень жизненные и действительно любопытные вопросы. Пожалуй, чтобы осветить их все нужна отдельная статья, но я постараюсь кратко прокомментировать
Говоря о тех долге и его закрытии. В качестве своего кода мы уверены, хотя, конечно, в большом проекте рефакторинг становится уже перманентным и всегда есть что поправить. Команда клиента была в курсе реального состояния проекта и мы предоставили им план, как бы мы хотели закрыть техдолг, что поменять/порефакторить. Техлид инхаус команды внес в этот план свои правки и выделил нам ту часть, которую они хотели бы выполнить нашими руками. Остальное команда взяла под свое крыло. Ничего криминального в их решении не вижу.
Хороший поинт по поводу коммуникации с командой - тема правда сложная, дрим тим за эти несколько месяцев мы не создали, но необходимые вопросы закрывались в срок.
Что касается клиента, то мы сотрудничали без перерыва в течение 7 лет и очень гордимся этим кейсом. Думаю, даже длительность нашего сотрудничества уже может что-то сказать о том, насколько клиент был доволен или не доволен нашей работой. Наверно, все-таки истинные причины ухода мог бы сказать сам клиент, но мы получили положительную обратную связь и благодарность за свою работу