Как принимать чужой проект

Впервые статья была опубликована на сайте CMS Magazine.

Саппорт как тенденция

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

Раньше мы дорабатывали и поддерживали только те проекты, которые делали для клиентов сами. Около года назад мы поняли, что их уже достаточно много, сформировали в компании отдел техподдержки, прописали процессы работы и реагирования на запросы клиентов и начали принимать на поддержку проекты, разработанные другими командами. Сейчас мы поддерживаем и развиваем около 20 проектов наших клиентов, среди которых треть — изначально не наша разработка. К таким относятся мобильное приложение для заказа туристических услуг RocketGo и приложение для круглосуточной связи с доктором «Мой Доктор».

Почему проекты передают на доработку

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

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

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

Основные вопросы

Работа и жизнь научила: прежде чем браться за неизвестный проект, менеджеру нужно задать клиенту следующие вопросы:

1. «Почему вы расстались со старой командой? Что в работе с ней было хорошо, а что — не очень?». Это нужно для формирования клиентских ожиданий.
2. «Какие у вас планы в долгосрочной и краткосрочной перспективе? Когда вы хотите идти в релиз?». Это нужно, чтобы закладывать время.
3. «Есть ли задокументированные баги в багтрекере?». Это нужно для того, чтобы за чужие баги не отвечала новая команда. Если задокументированных багов нет, то должен быть этап приёма с последующим баг-репортом.

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

1. «Что происходит? Что это за проект?». Эти вопросы адресуются максимально большому количеству людей — от разработчиков до начальства. Первый месяц работы на проекте — самое подходящее время его задать. Согласно терминологии «Стратоплана», этот месяц называется «медовым». Это время, когда вы ничего не знаете и не обязаны знать про проект. Но через два-три месяца ситуация меняется кардинально, так что не теряйте времени.
2. «Кто — команда? По какой методологии планируется работа и отслеживается прогресс?». Ответы могут колебаться в диапазоне от «мы работаем без методологии» до «у нас свой особенный SCRUM». Это даст вам почву для выводов.
3. «Где план проекта?». Этот вопрос связан с предыдущим. Если если работа пойдёт по канбану, то должна быть канбан-доска, а если по SCRUM, то product backlog. Как минимум должно быть ТЗ.
4. «Как происходит стыковка планов менеджера и команды?». Стыковка — это уверенность в том, что дата окончания разработки, озвученная клиенту, одна и та же для менеджера и разработчиков. Планы стыкуются вручную? Ок. Менеджер сверяется с бумажкой, а команда разносит задачи в системе управления версиями? Ок. Также Иван рекомендует спросить, как часто происходит стыковка.
5. «Менеджер видит прогресс?». Если нет, то менеджер не контролирует работу. Возможно, у предыдущего менеджера была такая же проблема. Контроль осложняется, когда подразделения в компаниях существуют в вакууме и работают по принципу чёрного ящика: положи в меня задачу, назначь срок и приходи за результатом, только не стой над душой.
6. «Какими полномочиями обладает менеджер?». Может ли он нанимать, увольнять, премировать и депремировать людей? От этого зависит хотя бы то, может ли менеджер изменить принцип чёрного ящика на другой.
7. «Какие выводы сделал менеджер?».

Полностью вебинар можно посмотреть здесь.

Из чего складывается грамотный приём проекта

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

Старая команда

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

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

Code review

Для клиента новая команда — это волшебная таблетка, которая исцелит проблемный проект. Броситься в омут с головой и стать залогом чужого счастья очень заманчиво, но факт есть факт: есть вещи, лежащие вне чьих-то возможностей. Поэтому менеджер должен честно сказать клиенту, что команда не будет заниматься внедрением новых функций, пока не сделает code review, то есть не вникнет в устройство проекта и кода.

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

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

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

Посмотрите это видео и послушайте ещё немного аргументов в пользу code review.

Приёмочное тестирование

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

Чем дольше команда работает на проекте, тем больше она покрывает функциональность своим хорошим кодом. Сначала это частичные правки, но со временем такой код закроет весь проект, и когда какая-то проблема проявит себя, она списывается на новую команду. Команда может с этим не согласиться, но нужны доказательства, и таковыми станет документ по итогам приёмочного тестирования, включающий всю функциональность и баги. Это задача, за успех которой отвечают и клиент, и исполнитель, а ещё это забота о времени друг друга и страховка от контрпродуктивных разборок на тему «Вот этот баг — он новый или унаследованный?».

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

ВАЖНО! Все устные и письменные обсуждения также фиксируются. Логи встреч и переписок — это адвокаты обеих сторон.

Приёмочное тестирование не вскрывает всех проблем проекта. Чтобы всецело постичь код, команде нужно начать кодить. Именно кодить — code review может закончиться только тем, что разработчики скажут: «Ок, мы знаем, что делать». Но внедрение новых функций и работа с зависимостями — это уже другая история.

SLA

SLA (Service Level Agreement, или «соглашение об уровне услуг») — это документ, регламентирующий рабочие отношения клиента и поддержки. В нём прописывается ситуация, в которой потребовался этот документ, объём поддержки (количество часов в месяц), роли на проекте, время реакции в зависимости от статуса задачи (критическая, срочная, обычная), что будет результатом реагирования, а также как планируется и оплачивается время руководителя проекта, разработчика, тестировщика, аналитика и дизайнера.

Работа по SLA — это результат переговоров. Менеджер предлагает выбрать из двух условий: либо клиент платит деньги за поддержку по схеме Time & Material (и это значит, что задача может быть выполнена когда угодно в границах оплаченного времени), либо работа идёт по SLA и клиент платит абонентскую плату (и это значит, что команда бронируется на конкретное количество часов).

В формате устной договорённости такие вещи оставлять нельзя.

Смысл продукта

Как code review с технической стороны, команда со стороны бизнес-модели и процессов продукта должна вернуться к «исходной стадии» и получить ответы на ключевые вопросы:

1. Для кого этот продукт?
2. Какая его услуга — центральная?
3. Какая у него приоритетная функциональность и чем этот приоритет подкреплён?

Возможно, клиент вот уже очень давно ушёл совсем не туда со старыми командами. Задача новой команды — найти правильный путь, поверить в этот путь и передать эту уверенность клиенту.

А ещё клиенту нравится,..

…когда есть лидер, который соберёт команду, будет контролировать её и гарантировать качество своим присутствием.

Кризисные ситуации и конфликты

Медленная реакция на запросы

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

Несовпадение ожидания с реальностью

Часто менеджер даёт обещания с уверенностью, что его команда вытянет всё, но это не так. Свои обещания менеджер должен страховать буфером времени на случай форс-мажорных ситуаций, а клиент должен знать, что за риски его ожидают.

Работа с чужой командой

Для менеджера отношения c другой командой могут обернуться кошмаром. В практике Лайв Тайпинг был случай, когда предыдущая команда проекта откровенно саботировала его передачу, обвиняя нас в некомпетентности. Такая ситуация может повториться и у вас, но под другим соусом, причём не играет роли, хочет команда расстаться с проектом или не хочет.

Другой случай был связан с внедрением в устоявшуюся команду, начинавшую этот проект, разработчика с очень высокой самооценкой. Решив, что код, технологии и архитектура никуда не годные, он начал работать согласно своему видению. Его подход оказался действительно более эффективным, но у другой команды остался на душе неприятный осадок. Так что совет менеджерам: либо уважайте чужие рабочие подходы и не лезьте в стилистику пускай не идеального, но поддерживаемого кода, либо откажитесь от людей.

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

Фрилансеры! Наши представления о вас базируются только на нашем же опыте работы с вами. Но и Лайв Тайпинг, и наши коллеги из других студий будут рады работать с качественно другими фрилансерами: мотивированными, не выдающими джуниорский результат за плод 16-часовых усилий, готовыми стать полноценными членами команды. Обратите на себя внимание — напишите нашему менеджеру по работе с подрядчиками Тамаре: hr@ltst.ru.

Вывод

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

Всё начинается с вопросов клиенту:

1. «Что вам не нравилось в старой команде, а что нравилось?»
2. «Какие у вас планы?»
3. «У вас уже есть документ с имеющимися на проекте багами?»

После этого менеджер и клиент оговаривают время, которому команда уделит знакомству с кодом. Неделя, две или месяц — срок зависит от размеров проекта.

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

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

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

Прогнозировать сроки нужно с учётом возможных рисков, о которых должен знать клиент.

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

Что почитать по теме

• Алгоритм принятия чужого проекта, или что делать, когда у менеджеров случается медовый месяц. Вебинар Ивана Селиховкина из компании «Стратоплан».
• Поддержка и сопровождение проектов: подробно об опыте. Статья директора по развитию компании Progressive Media Александра Живетьева.
• Как устроена техническая поддержка у нас в студии. Статья основателя и исполнительного директора компании Sibirix Владимира Завертайлова.
• Дорабатывать или переписывать. Мнение хабраблогера.
• Как мы писали SLA. Опыт хабраблогера.