Автор: Полина Копруджу, консультант-методолог департамент EPM «Корус Консалтинг»
Столько написано книг и статей, о том, как правильно вести проекты и передавать их от одних исполнителей другим, но почему-то каждый раз в подобной ситуации появляются какие-то «нюансы». Смена консультанта может означать потерю уникальных знаний и опыта, которые были накоплены в процессе работы над проектом. Также консультанты часто выступают связующим звеном между командой и заказчиком. Их уход может нарушить установленные коммуникации, что приведет к недопониманию и задержкам в принятии решений. Это может затруднить дальнейшую реализацию задач и привести к ошибкам, сбоям в графиках, перерасходу бюджета и неэффективному распределению ресурсов, что негативно скажется на имидже компании в целом. Это основные проблемы, но вообще этот список может быть очень и очень длинным.
Меня зовут Полина Копруджу, я консультант-методолог в департаменте EPM «Корус Консалтинг». Проект, о котором пойдет речь, был проектом по автоматизации расчета себестоимости произведенной продукции. Как правило, подобные проекты считаются одними из наиболее сложных и неоднозначных, т.к. бизнес – пользователи выбирают самостоятельно в методологиях расчетов себестоимости, какие подходы использовать, какие допущения применять при разработке, и не всегда выбранные подходы совпадают с «общепринятыми».
Сегодня, когда я уже достаточно долго проработала с этим клиентом, увидела все отдаленные последствия наших решений, я для себя сформировала небольшую памятку по передаче проекта.
На что обращать внимание, когда принимаешь проект в середине реализации
Посмотреть на уровень документирования
И здесь точно не стоит полагаться на свою экспертизу, надеясь, что «такие проекты я делал сто раз». Очень важно не только прочитать документацию, но прочитать ее осознанно, еще лучше четко представить использование этой документации на практике.
До ухода коллеги в декрет я сделала расчет в Excel по согласованной с заказчиком методологии, чтобы предварительно согласовать результат, который клиент получит после реализации в системе. Благодаря этому ни у кого не должно было возникнуть разногласий. Это работает почти всегда 😊
Например, в моем случае была согласованная методология, которая насчитывала более 100 страниц, но были описаны и согласованы с заказчиком только общие подходы расчетов, без деталей, которые впоследствии оказались важными. Это был как раз тот случай, о котором я писала, выше: не всегда выбранные подходы совпадают с так называемыми «общепринятыми».
Важно не только «примерить» документацию, но и согласовать подходы с заказчиком. Важно заложить дополнительное время на эти этапы.
В моем случае времени на дополнительные согласования не осталось, поэтому, несмотря на проделанную работу по уточнению требований (но не их согласования), изначально функционал был реализован не так, как ожидал заказчик, что привело к изменениям в реализованном функционале и осложнило этап приемочного тестирования для всей команды. В такой ситуации постарайтесь максимально четко фиксировать все обсуждения и договоренности – это поможет избежать недопониманий и разногласий в будущем.
Если консультант, который должен был передавать проект, уже ушел, я бы советовала начинать с тщательного изучения всех доступных материалов, обращая особое внимание на ключевые документы, такие как методологии, технические задания и отчеты о проделанной работе. Если в документации есть пробелы или неясности, не стесняйтесь задавать вопросы команде или заказчику. Для ускорения процесса изучения документации структурируйте ее, это позволит систематизировать информацию, и составьте план изучения, чтобы ничего не упустить.
Если документация сложная, можно сформировать для себя упрощенные версии или инструкции. Очень круто в этом помогает использование инструментов для организации и управления документацией, такие как Confluence или Notion.
Если часть задач по разработке уже реализована, важно ознакомиться с кодом, чтобы понять архитектуру и основные компоненты.
Если есть возможность, организуйте установочные встречи с представителями заказчика, чтобы обсудить ключевые аспекты решения, бизнес-цели и функциональные требования. Это поможет понять их ожидания и приоритеты и уже с учетом этого контекста составлять план работ.
Очень важно заранее сообщить заказчику о предстоящей смене участников, подтвердить свою готовность взять на себя ответственность за проект, а также убедить заказчика, что несмотря на такие форс-мажорные обстоятельства, проект будет закончен в оговоренные/скорректированные сроки. На встречах нужно внимательно слушать заказчика, задавать вопросы о его требованиях и пожеланиях – это поможет построить доверительные отношения и показать, что вы заботитесь о его потребностях.
При первоначальном планировании проекта важно учитывать вероятные риски, в том числе уход аналитика, разработчика (увольнение / декрет / другой проект), особенно, если в такой роли сотрудник привлекается в единственном числе, то есть необходимо закладывать резервы на мероприятия по передаче проекта, а при возникновении такого риска обязательно обсуждать это совместно с заказчиком, чтобы снизить вероятность негативного восприятия смены ведущего участника.
Передачу проекта следует рассматривать как этап проекта со своими сроками, результатами. Поэтому я рекомендую составить и согласовать с обеими сторонами детальный план передачи проекта.
В качестве этапов такого маленького подпроекта я бы запланировала следующие шаги:
определение перечня участников: важно понимать, какое время понадобиться уделять передающему и принимающему сотруднику, каким образом организовать высвобождение ресурсов для этого;
составление и систематизация документации, а также планирование встреч для разбора возникающих вопросов;
погружение нового участника в проект: организовать встречу для знакомства с командой заказчика, на которой можно было бы обсудить подходы в организации работ. С приходом нового консультанта в процедуры обсуждения и согласования могут быть внесены изменения, например, создан новый регламент, если он окажется удобнее текущего. В целом, подключение нового человека всегда можно использовать для модернизации хода работ, что позволит повысить эффективность проекта.
В моей ситуации во время перехода мы так и сделали. Раньше на проекте все встречи по сборам требований записывались, а по их окончанию формировалось краткое мемо встречи, где описывались основные моменты, которые обсуждались. Позже, при поиске ответов на возникшие вопросы, нужно было переслушивать встречи, искать таймкоды, где это обсуждалось. На это уходило очень много времени. Поэтому к существующим мемо по моей инициативе мы добавили согласование целевых решений, которые представляли собой файл с описанием требований заказчика и примером реализации. Такие решения согласовывали на каждое новое требование. Целевое решение описывали максимально детально: были прописаны все возможные сценарии использования системы, варианты ее поведения в каждом описанном случае, в каких блоках, на каких аналитиках будет реализован функционал.
Это решение увеличило трудоемкость на первоначальном этапе, но достаточно сильно сократило время, затрачиваемое при возникновении спорных ситуаций – мы уже не пересматривали встречи, не спорили, заставляя читать/слышать друг друга между строк, а обращались к согласованному документу. Если каких-то требований там не оказывалось, то и мы, и заказчик понимали, что это новое требование, выходящее за рамки проекта.
Важно закладывать время на случай непредвиденных ситуаций, продумывать необходимые меры для возврата к нормальному рабочему ритму и планировать для этого ресурсы.
Хорошим вариантом, при наличии возможности, будет организация небольшого периода параллельной работы, когда передающий и принимающий сотрудники будут совместно заниматься проектом. Это позволит принимающему сотруднику лучше понять проект, а передающему – плавно передать свои знания и задачи. Такой вариант возможен, когда переход несрочный. В моем случае коллега уходила в декрет, и мы смогли заранее запланировать время, когда проектом будут заниматься два аналитика, один из которых будет с течением времени погружаться в проект все больше и больше, а второй – постепенно выходить из него. Помимо очевидных плюсов для нас, как исполнителей, такой подход позволил заказчику постепенно привыкнуть к новому участнику и убедиться, что это никак не отражается на качестве результата.
Параллельный период работы так же позволит на регулярной основе проводить совместные собрания для оценки прогресса передачи проекта.
Следуя этим рекомендациям, можно в значительной степени минимизировать риски потери качества и смещения сроков при передаче ИТ-проекта.
В заключение, хотелось бы сказать, что передачу проекта следует рассматривать как отдельный этап, учитывая его в планировании сроков и стоимости. В этот процесс должны быть вовлечены все участники проекта, так как смена консультанта — это не только проблема исполнителя, но и общая задача команды, заинтересованной в соблюдении бюджета, сроков и качества. Успех проекта зависит от согласованных действий и открытого диалога между всеми сторонами.
Открытый диалог и взаимодействие между всеми участниками – ключ к решению любых проблем, возникающих в ходе реализации проекта.
