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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для опытных

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

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

Для новичков

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

Для всех

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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


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

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

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

Понимаю, что текст может восприниматься как смесь инструкций и внутренних регламентов компании. Но в любом случае работа менеджеров состоит из стандартных и нестандартных задач и, на мой взгляд, если научиться решать стандартные задачи быстро и просто, то можно сэкономить очень много времени на по-настоящему нетривиальную работу и получить в разы больше полезного опыта.
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 11

    0

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

      0

      Отвечу за автора: прошу за дополнительную фичу дополнительных денег.

        0
        Я может быть неправильно выразился, извините, попробую исправиться.

        В ТЗ есть фраза которая неявно трактуется (ничего не поделаешь, ТЗ подписано). Фича оценивается в X человеко-часов, но представитель со стороны клиента описывая функциональность детализирует ее так, что формально она подходит под описание в ТЗ, но оценивается в 3*X человеко-часов. На уверения и доказательства что это не то что написано в ТЗ не реагирует и отказывается урезать другие части проекта (даже те, что особо не влияют работу продукта — рюшечки). Грозиться отменить приемку проекта, если это не будет реализовано и подать в суд за срыв сроков.

        Вот о какой ситуации я говорил.
          0
          Окей, допустим переговоры провалились.

          Сроки можно за скобками оставить — нагнал на фичу втрое больше людей и успел (если есть ресурсы).

          Если вычитание из ожидаемой прибыли проекта 2*Х (для простоты — прибыль в часах) дает положительное число — сжимаем зубы и делаем.

          Если отрицательное, допустим оно равно M, то смотрим:
          1) Если М больше, чем уже потрачено человеко-часов на проект — закрываем проект.
          2) Если М меньше — делаем проект и молимся*, чтобы второй такой фразы не было.

          * на самом деле не молимся, а внимательно читаем ТЗ и анализируем риски.
          • UFO just landed and posted this here
              0

              Эти 3X больше вашего риск буфера на фазе проекта? Вы работаете с подрядчиком или только внутренними ресурсами?

                0
                На лицо явно ошибка человека, разработавшего ТЗ. Почему в процессе работы над fixed-price проектом происходит детализация? Либо люди, которые оценивали работу в X ч-часов не удосужились детализировать требования.
                Что делать:
                — обсудить с командой, чтобы у всех было видение ситуации,
                — обсудить с клиентом вместе с людьми, которые писали ТЗ. Понять, кто же все-таки неправ (вендор или клиент)
                — если вендор неправ (обычно так и бывает :)) попробовать закончить проект в сроки и за тот же бюджет. Да, поговорить с руководством, взять дополнительных разработчиков, пожертвовать собственным бонусом. Если это невозможно, объяснить все это клиенту. Да, он может обращаться в суд, но тогда, скорей всего он вообще не увидит проекта, либо получит низкокачественный продукт. По идее такие вещи должен уже решать не конкретный ПМ, а sales или аккаунт-менеджер. Может быть они в баню сходят с клиентом :) Если клиент мелкий и ненужный — то можно и забить на него.
                И еще — в договоре fixed-price всегда нужно прописывать штрафные санкции за срыв сроков, но всегда прописывать максимальную сумму штрафа. Например, 1% от суммы за день просрочки, но не более 10%… Тогда деньги (за минусом макс 10%) будут получены.
                • UFO just landed and posted this here
                    0
                    Я думаю, еще есть смысл всегда в обсуждении требований опираться на договоренности. Клиенты хорошо понимают, если вы говорите, что ТЗ можно трактовать как им нужно, но в диалоге при планировании проекта функционал был очерчен именно так.
                  0
                  Всегда сложно быть в такой ситуации. Я думаю, направления дествий такие:

                  1. Попытаться разубедить клиента. Безусловно, если это подходящее решение
                  2. Анализ заложенных заранее рисков и применение их на данную фитчу
                  3. Поиск компромисса с клиетом. Это как раз «Процесс пересмотра скоупа проекта в условиях изменения функциональности без изменения бюджета» — из статьи

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

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

              Only users with full accounts can post comments. Log in, please.