Решаем стандартные для PMов проблемы на проектах. Часть 1

О чем? И для кого?

Случалось ли с вами, такое, что клиент увеличивает количество работ для вашей команды, хотя его требование, в принципе подходит под ТЗ?

Бывали ли ситуации, когда разработка затягивается, но не по вине вашей команды?

Не возникали ли у вас вопросы, как стоит действовать в ситуации, если разработка затягивается, хотя все идет как изначально планировали вместе с клиентом. И для клиента у вас нет объективной причины, кроме фразы “задача оказалась больше чем мы думали”.

В статье я стараюсь описать, что нужно сделать в первую очередь в той или иной ситуации и, что нужно обязательно не забыть.

Предупреждение

Сразу хочу предупредит, что мы не работаем по какому-то из Agile фреймворков, но мы используем большое количество практик Agile, которые подходят под наши процессы. Поэтому вы не увидите в статье таких слов как “спринт” или “стори поинт”. Я думаю, что представленные инструкции есть куда расширять, но в тоже время они могут быть основой и помогать в работе менеджера.

Процесс разработки замедляется по независящим от вас обстоятельствам (сторонние разработчики/недостаток данных от клиента).

Допустим лицо от которого зависит задержка уже оповещено, вы чувствуете слабое продвижение по вашему вопросу и нужно что-то делать.

1. Необходимо понять в какой момент эта ситуация начнет на самом деле влиять на сроки разработки.

   Если у вас есть запас времени, то нужно его четко оценивать. И важно не упустить этот момент, потому что не всегда все карты есть на руках. Что-то нужно узнать у своей команды или руководства и результат может быть неожиданным.

2. Отнять от полученных сроков буфер и сообщить в письме о проблеме. В письме обязательно указать сроки и последствия. Это письмо должно быть написано формально и подчеркивать серьезность указанных фактов.

   Это действие как предупредительный выстрел в воздух. Его можно повторять несколько раз, но только в случае если сроки сдачи в безопасности.

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

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

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

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

5. Дальнейшие действия сильно различаются в зависимости от природы компромисса и достойны отдельных инструкций.

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

Для опытных

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

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

Для новичков

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

Для всех

Вообще идея инструкций появилась с одной простой целью. Не изобретать велосипед каждый день, а зафиксировать набор определенных действий и экономить “мыслетопливо” (если вы понимаете о чем я).

Клиент просит сделать работы не планируемые вами (вне оценки), но подходящие под ТЗ.

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

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

2. После того как мы поняли, что это точно должно быть сделано и если нет точного понимания. Что нужно делать? Лучше запросить этот функционал в письменном виде, в идеале с примерами. Так же сразу обсудить возможные облегченные варианты этого функционала.

   Возможно на самом деле клиент имеет в виду что-то, что вы и так собираетесь делать и вы просто друг друга не поняли. Как вы понимаете в 1ом и 2ом этапе мы пытаемся понять, придется ли на самом деле менять свои планы разработки.

3. Запустить процесс пересмотра скоупа проекта в условиях изменения функциональности без изменения бюджета

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

Самое сладенькое

Я уверен что с процессом оптимизации бюджета встречался каждый пиэм, который работал на fixed price проекте. Я попытался объединить общепринятые действия в этой ситуации в одном списке. Но помимо действий я считаю, что нужно обратить внимание на акценты и мелочи, которые важно не забывать на этапах.

Процесс пересмотра скоупа проекта в условиях изменения функциональности без изменения бюджета

1. Четко понять приоритет фитчи по отношению к остальным и риски по ее созданию.

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

2. По возможности подготовить вариант исхода для клиента без потерь в качестве продукта.

   Смысл пункта достаточно прост, если клиент воспользовался спецификациями в свою пользу, то и вы явно можете также. В этой ситуации лучше начать обзор скоупа снизу по приоритетам фитч. Какие вопросы стоит себе задавать при поиске?

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

   Важно ни в коем случае не вычитать из бюджета тестирование, рефакторинг, ревью и. т. п. важные процессы проекта!

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

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

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

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

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

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

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

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

6. Следующим шагами должны быть перепланирование работ согласно новым требованиям и гладкое продолжение пректа

Что получилось?

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

Автор: maltsev_ivan703

Источник ^[1]