Из аутсорса в инхаус: чек-лист по передаче проекта
Несколько месяцев назад наш клиент решил развивать продукт самостоятельно и собрать свою инхаус-команду. А мы в MobileUp решили собрать чек-лист приемки проекта для владельцев продуктов/руководителей/менеджеров. Рассказываем, как перенять проект и выстроить работу на своей стороне, не потеряв в качестве. Делимся чек-листом и другими наблюдениями.
Неплохой текст, но слишком сладенько получилось. На деле обычно всё не так радужно, чуть меньше пони и аромата малины. Часто проекты передаются с большим количеством проблем, хорошо если не фундаментально-архитектурных. Ну, в смысле, решаемых без глубокого переписывания в первые полгода. Хорошо, когда для релиза после приёмки его не приходится радикально дописывать и шлифовать, как по качеству так и по фичам.
Нет здесь ничего о спорных моментах по закрытию всех актов, приёмок и прочей документации и долгов по аналитике, проектированию, разработке и дизайну.
Ни слова о потенциальном конфликте команды аутсорсера и ин-хауз команды, точнее есть некая вялая критика домашней команды в выражениях "они какие-то слабомотивированные". На деле, найти нормальный контакт на уровне разработки очень тяжело, практически никакого интереса сотрудничать у команды аутсорса нет, они уже двумя ногами в новых проектах сидят и любое взаимодействие с домашней командой не входит ни в сферу интереса их самих, ни в интересы их руководителей, от ПМов до деливери.
Ну и 3-4 недели на весь процесс перехода разработки это конечно мало. 3-4 месяца для большого проекта с командой человек в 20 из разработчиков, аналитиков, дизайнеров, менеджеров и тестировщиков 3-4 недели это очень сжатые темпы. Интересно, чем вы так довели заказчика, что он в таком авральном режиме забирал проект домой)
О передаче проектов знаю не понаслышке, бывал по обе стороны этого процесса и не раз.
Но если я вдруг ошибаюсь, то рад за вас. Но всё же текст больше похож на рекламу типа "смотрите какие мы пупсики, мы даже с уходящим заказчиком розовые и пушистые"))))
Кирилл, спасибо за фидбэк и справедливые комментарии
Хочу обратить внимание, что изначальная цель статьи была не в описании конкретного кейса передачи проекта, а в создании чек-листа для владельцев продукта. Мы хотели сократить наш опыт до краткого плана, что стоит сделать/проверить/на что обратить внимание, поэтому не стали освещать множество деталей.
Вы задаете очень жизненные и действительно любопытные вопросы. Пожалуй, чтобы осветить их все нужна отдельная статья, но я постараюсь кратко прокомментировать
Говоря о тех долге и его закрытии. В качестве своего кода мы уверены, хотя, конечно, в большом проекте рефакторинг становится уже перманентным и всегда есть что поправить. Команда клиента была в курсе реального состояния проекта и мы предоставили им план, как бы мы хотели закрыть техдолг, что поменять/порефакторить. Техлид инхаус команды внес в этот план свои правки и выделил нам ту часть, которую они хотели бы выполнить нашими руками. Остальное команда взяла под свое крыло. Ничего криминального в их решении не вижу.
Хороший поинт по поводу коммуникации с командой - тема правда сложная, дрим тим за эти несколько месяцев мы не создали, но необходимые вопросы закрывались в срок.
Что касается клиента, то мы сотрудничали без перерыва в течение 7 лет и очень гордимся этим кейсом. Думаю, даже длительность нашего сотрудничества уже может что-то сказать о том, насколько клиент был доволен или не доволен нашей работой. Наверно, все-таки истинные причины ухода мог бы сказать сам клиент, но мы получили положительную обратную связь и благодарность за свою работу