Pull to refresh

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

Reading time 6 min
Views 13K
О чем? И для кого?

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

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

Как стоит действовать в таких ситуациях? Что делать, если разработка затягивается, хотя все идет все так, как вы изначально планировали вместе с клиентом? И для клиента у вас нет объективного ответа на этот вопрос, кроме стандартной причины: «задача оказалась больше, чем мы думали».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для опытных

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

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

Для новичков

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

Для всех

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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


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

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

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

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

Articles