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

Пoддeржкa и сoпрoвoждeниe прoeктoв: пoдрoбнo oб oпытe. Нeсoвпaдeниe oжидaния с рeaльнoстью
Чaстo мeнeджeр дaёт oбeщaния с увeрeннoстью, чтo eгo кoмaндa вытянeт всё, нo этo нe тaк. С чужoй кoмaндoй мoгут склaдывaться нeпрoстыe oтнoшeния. Бeз тaкoгo знaкoмствa eсть вeрoятнoсть, чтo прoблeмы дaдут o сeбe знaть тoгдa, кoгдa придёт пoрa улучшaть прoeкт и внeдрять нoвыe функции. Нeдeля, двe или мeсяц — срoк зaвисит oт рaзмeрoв прoeктa. Рeдaктoр кoмпaнии Лaйв Тaйпинг Aндрeй Рудeнкo пoгoвoрил с кoллeгaми, чтoбы узнaть o вoзмoжныx слoжнoстяx, и пoнять, чтo нужнo сдeлaть, чтoбы oбe стoрoны oстaлись дoвoльны и дoлгo рaбoтaли вмeстe. Чтo этo зa прoeкт?». «Кaкиe у вaс плaны в дoлгoсрoчнoй и крaткoсрoчнoй пeрспeктивe? Этo врeмя, кoгдa вы   ничeгo нe знaeтe и нe oбязaны знaть прo прoeкт. Дaтa публикaции: 26.09.2017  

Клиeнты чaстo oбрaщaются к IT-студиям с прoсьбoй взять прoeкт нa пoддeржку и рaзвитиe. Eсли вы   в гневе от прочитанного, если вы   не узнаёте себя в этих утверждениях и считаете сказанное наглой крамолой — смело пишите об этом в комментариях. Из чего складывается грамотный приём проекта

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

«Что вам не нравилось в старой команде, а что нравилось?»

«Какие у вас планы?»

«У вас уже есть документ с имеющимися на проекте багами?»

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

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

старый менеджер уходит с проекта и сменяется новым;

работа со старой командой обходилась клиенту дорого и вынудила его искать вариант дешевле;

старая команда развалилась или ей   не хватает компетенций, и теперь нужна команда, которая владеет нужными технологиями;

над проектом начинали работу фрилансеры, изначально не замотивированные на успешный продукт. Менеджер сверяется с бумажкой, а команда разносит задачи в системе управления версиями? Старая команда
Она может оставить у клиента положительные воспоминания о себе даже если им   пришлось расстаться. Чтобы оправдать ожидания, менеджеру, как ни странно, нужно заниматься своей работой: разговаривать, спрашивать, отвечать и объяснять. К таким относятся мобильное приложение для заказа туристических услуг RocketGo и приложение для удалённых консультаций по вопросам здоровья. Опыт хабраблогера. «Как происходит стыковка планов менеджера и команды?». Обязательно работайте по SLA. В нём прописывается ситуация, в которой потребовался этот документ, объём поддержки (количество часов в месяц), роли на проекте, время реакции в зависимости от статуса задачи (критическая, срочная, обычная), что будет результатом реагирования, а также как планируется и оплачивается время руководителя проекта, разработчика, тестировщика, аналитика и дизайнера. Это даст вам почву для выводов. Если если работа пойдёт по канбану, то должна быть канбан-доска, а если по SCRUM, то product backlog. Как минимум должно быть ТЗ. Ок. Или MVP не оправдал ожиданий клиента. Отказать, потому что код неподдерживаемый — право руководителя проекта, но о возможном отказе клиента нужно предупредить заранее. Приёмочное тестирование не вскрывает всех проблем проекта. Также Иван рекомендует спросить, как часто происходит стыковка. ВАЖНО! Этому правилу нас научил один инициативный клиент, пришедший к нам развивать уже работающий проект. Что в работе с ней было хорошо, а что — не очень?». Но эстафеты с передачей проекта от команды к команде ещё не достаточно плотно вошли в повседневность. Чем может помочь новый менеджер? Работа по SLA — это результат переговоров. Ответы могут колебаться в диапазоне от «мы   работаем без методологии» до «у нас свой особенный SCRUM». В практике Лайв Тайпинг был случай, когда предыдущая команда проекта откровенно саботировала передачу проекта, обвиняя нас в некомпетентности. Если менеджер внедряет своих людей в чужую команду, стоит узнать, продуктовая   ли это команда или фрилансеры. Исполнитель имеет право отказаться, но это должно оговариваться с клиентом на самых ранних этапах. «Какими полномочиями обладает менеджер?». «Где план проекта?». Статья основателя и исполнительного директора компании Sibirix Владимира Завертайлова. Фрилансеры! Среди тендеров от крупных клиентов большинство — именно такие. Но через два-три месяца ситуация меняется кардинально, так что не теряйте времени. Основные вопросы
Работа и жизнь научила: прежде чем браться за неизвестный проект, менеджеру нужно задать клиенту следующие вопросы:

«Почему вы   расстались со старой командой? Сейчас мы   поддерживаем и развиваем около 20   проектов наших клиентов, среди которых треть — изначально не наша разработка. Менеджер предлагает выбрать из двух условий: либо клиент платит деньги за поддержку по схеме Time &   Material (и это значит, что задача может быть выполнена когда угодно в границах оплаченного времени), либо работа идёт по SLA и клиент платит абонентскую плату (и это значит, что команда бронируется на конкретное количество часов). Раньше мы   дорабатывали и поддерживали только те   проекты, которые делали для клиентов сами. Смысл продукта
Как code review с технической стороны, команда со стороны бизнес-модели и процессов продукта должна вернуться к «исходной стадии» и получить ответы на ключевые вопросы:

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

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

«Что происходит? Предложить рефакторинг. Поправить их сейчас или подождать — решать клиенту. SLA
SLA (Service Level Agreement, или «соглашение об уровне услуг») — это документ, регламентирующий рабочие отношения клиента и поддержки. Логи встреч и переписок — это адвокаты обеих сторон. Если договор заключен, начните работать над приёмочным документом. Задача новой команды — найти правильный путь, поверить в этот путь и передать эту уверенность клиенту. Если нет, то менеджер не контролирует работу. И Лайв Тайпинг, и наши коллеги из других студий будут рады работать с качественно другими фрилансерами: мотивированными, не выдающими джуниорский результат за плод 16-часовых усилий, готовыми стать полноценными членами команды. Он   описывает проект, его функциональность и баги. Его подход оказался действительно более эффективным, но у другой команды остался на душе неприятный осадок. Планы стыкуются вручную? Переписывать с нуля ничего не нужно — переработка частями станет нормальным компромиссом. Нужно понимать, что в будущем рефакторинг удешевит разработку и поддержку. Спустя некоторое время команде может прийти осознание, что проект находится далеко не в самом пристойном виде. Теперь новой команде нужно задокументировать баги, оставшиеся от старой. Это создало условия, в которых самой популярной услугой студий мобильной и веб-разработки стала техподдержка и развитие проекта. В сфере разработки сайтов и мобильных приложений это очень распространённый и очень непростой случай. Но внедрение новых функций и работа с зависимостями — это уже другая история. Эти вопросы адресуются максимально большому количеству людей — от разработчиков до начальства. Приёмочный документ застрахует новую команду от ответственности за проблемы, оставшиеся после прежней команды, и сэкономит время и нервы всем участникам проекта. Наша практика показывает, что он   может длиться от недели до месяца. Вывод
Независимо от причины, по которой проект уходит в другие руки, от менеджера и новой команды ждут спасения. Дорабатывать или переписывать. Так что совет менеджерам: либо уважайте чужие рабочие подходы и не лезьте в стилистику пускай не идеального, но поддерживаемого кода, либо откажитесь от людей. В формате устной договорённости такие вещи оставлять нельзя. Этот вопрос связан с предыдущим. Приёмочное тестирование
Итак, договор на поддержку заключен. Какая у него приоритетная функциональность и чем этот приоритет подкреплён? Согласно терминологии «Стратоплана», этот месяц называется «медовым». Статья директора по развитию компании Progressive Media Александра Живетьева. Работа с чужой командой
Для менеджера отношения c   другой командой могут обернуться кошмаром. Как устроена техническая поддержка у нас в студии. Возможно, у предыдущего менеджера была такая   же проблема. Решив, что код, технологии и архитектура никуда не годные, он   начал работать согласно своему видению. Такая ситуация может повториться и у вас, но под другим соусом, причём не играет роли, хочет команда расстаться с проектом или не хочет. По какой методологии планируется работа и отслеживается прогресс?». Тендерная площадка WORKSPACE поможет выбрать оптимального исполнителя. Полностью вебинар можно посмотреть здесь. Как бы цинично это ни звучало, чувствами вторых в данном контексте можно пренебречь — работа есть работа. Что почитать по теме

Алгоритм принятия чужого проекта, или что делать, когда у менеджеров случается медовый месяц. Ниже мы   говорим о действиях, которых советуем придерживаться клиенту и менеджеру, чтобы грамотно передать и принять проект, не забыть о рисках и не довести сотрудничество до беды. Чем больше в проекте энтропии, тем больше времени займёт этот этап. Бывают перебои в соединении, природные катаклизмы и прочее, но мы   обсуждаем штатные ситуации. Чем дольше команда работает на проекте, тем больше она покрывает функциональность своим хорошим кодом. Чтобы всецело постичь код, команде нужно начать кодить. Сервис работает БЕСПЛАТНО как для заказчиков, так и для исполнителей. Хотя клиенту в первую очередь хочется знать от менеджера точные сроки и планы в то время, как его команда ещё не залезла внутрь проекта, спешить нельзя: работу стоит начать с этапа «давайте сначала разберёмся, посмотрим, как там что устроено», оформить его как первый этап поддержки, а после него уже составить отдельный план. Саппорт как тенденция
Вот продукт, который созрел до существенных доработок. «Какие выводы сделал менеджер?». Встречи на этой стадии должны быть очень частыми. «Есть   ли задокументированные баги в багтрекере?». Если команда — это коллаборация новой команды и сторонних специалистов, стоит проявлять тактичность и не говорить, что ваше кунг-фу лучше чьего-то ещё, даже если это так. Мы   заметили, что у фрилансеров нет привычки работать по корпоративным принципам, они очень редко держатся душой и сердцем за продукт и не болеют   им; они просто зарабатывают деньги и не заинтересованы ни в релизе, ни в успехе, и под конец с ними просто расстанутся. Одной — если не единственной — из них стала школа менеджеров «Стратоплан». Возможно, клиент вот уже очень давно ушёл совсем не туда со старыми командами. Это нужно для того, чтобы за чужие баги не отвечала новая команда. Если она должна передать проект новой команде, то передача может сорваться просто из-за вредности. А ещё клиенту нравится,…
…когда есть лидер, который соберёт команду, будет контролировать её   и гарантировать качество своим присутствием. Документировать баги можно хоть в Google Документе, приложив фото и видео и пошагово описав действия и то, к чему они приводят. И вот грядёт волнительный разговор. От этого зависит хотя   бы то, может   ли менеджер изменить принцип чёрного ящика на другой. Описывать проблемы нужно максимально конкретно. Может   ли он   нанимать, увольнять, премировать и депремировать людей? Хотя упорный и самоотрешённый менеджмент позволяет создавать продукт и с вольнонаёмными специалистами (но это не точно);

клиент развивал проект своими силами, но решил сосредоточиться на продажах и оказании услуг, а всю техническую сторону отдать внешней команде. Если задокументированных багов нет, то должен быть этап приёма с последующим баг-репортом. Все устные и письменные обсуждения также фиксируются. Следующим исполнителем стала региональная команда, маленькая и с кучей проблем: недоступность разработчиков, непрозрачные процессы, плохой менеджмент, плохое тестирование. Прогнозировать сроки нужно с учётом возможных рисков, о которых должен знать клиент. Ок. Как мы   писали SLA. Возня в куче плохого кода сулит бюджетные и морально-физические потери обеим сторонам процесса, и с таким кодом как причиной проблемы на проекте совсем не хочется работать: надстроишь хорошее своё — и всё сломается. Контроль осложняется, когда подразделения в компаниях существуют в вакууме и работают по принципу чёрного ящика: положи в меня задачу, назначь срок и приходи за результатом, только не стой над душой. Какая его услуга — центральная? Менеджеру и клиенту нужно обсудить на берегу, как коммуницировать, какими инструментами пользоваться и как построить работу, чтобы сгладить переход от одной команды к другой. База проекта насчитывает более 10 500 агентств. Но скорость реакции — понятие относительное. Новость о том, что код старый и не поддерживаемый, гипотетически может навести клиента на мысли, что старая команда его обманывала. Мнение хабраблогера. Другой случай был связан с внедрением в устоявшуюся команду, начинавшую этот проект, разработчика с очень высокой самооценкой. Поэтому менеджер должен честно сказать клиенту, что команда не будет заниматься внедрением новых функций, пока не сделает code review, то есть не вникнет в устройство проекта и кода. И таких случаев много. Пропишите в нём типы задач по степени критичности, время реакции на каждую и результат реагирования и укажите, кто за что отвечает. Около года назад мы   поняли, что их уже достаточно много, сформировали в компании отдел техподдержки, прописали процессы работы и реагирования на запросы клиентов и начали принимать на поддержку проекты, разработанные другими командами. Ниже будет рассказано, каким аспектам проекта нужно уделить внимание, чтобы укрепить эти столпы. Когда вы   хотите идти в релиз?». С чужой командой могут складываться непростые отношения. Этого времени хватит, чтобы разобраться в нюансах кода, изучить архитектуру и технологии. Code review
Для клиента новая команда — это волшебная таблетка, которая исцелит проблемный проект. Создавать его начала одна топовая компания. Что нужно сделать, чтобы каждая сторона осталась довольна. Это нужно, чтобы закладывать время. Стыковка — это уверенность в том, что дата окончания разработки, озвученная клиенту, одна и та   же для менеджера и разработчиков.

Комментирование и размещение ссылок запрещено.

Комментарии закрыты.