Управление огнем как часть работы руководителя

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

    image

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

    Невидимый пожар

    Неожиданно вспыхнувший лесной пожар придал соревнованиям по спортивному ориентированию неповторимую динамику и зрелищность.
    Для начала представлюсь. Алексей Тришин, руководитель проектов в одной замечательной ИТ-компании. Обладатель сертификатов PMP, PRINCE2, ITIL и еще нескольких других. Работа с рисками – один из ключевых моментов моей работы.

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

    Бывает? Каждый раз это служит показателем того, что вы недостаточно контролировали результат своей работы. Где-то махнули рукой, где-то не обратили внимания, а где-то понадеялись на русский авось. Однако проблема может возникнуть независимо от того, насколько сильно вы верите в свою удачливость.

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

    Дело в том, что на самом деле, приступая к какой-либо работе, вы УЖЕ находитесь в эпицентре «пожара». Правда, еще не знаете об этом. Давайте попробуем разобраться, что с этим можно сделать.

    Пожарный отряд

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

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

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

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

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

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

    Лом, лопата и топор

    — Да кто мы такие, чтобы противостоять силам природы?! Всего лишь пылинки на окраине Вселенной.
    — …, Петрович! Бери лопату и убирай снег!

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

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

    Реестр рисков

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

    Небольшой пример (вырезал из реального и уже закрытого проекта) ниже:

    image

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

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

    Пример рисков на этапе планирования

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

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

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

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

    И хорошо, если это своя команда – можно выяснить заранее, договориться, предусмотреть замену, в конце концов. А если точка срабатывания риска на стороне заказчика? Часто бывает, что заказчик чувствует гораздо меньшую ответственность и, завалившись более приоритетными делами, будет откладывать приемку в последнюю неделю несколько раз подряд. В итоге проект не будет завершен в срок.

    Таким образом можно подсветить и взять в дальнейшую работу как минимум два риска:

    Риск 1

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

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

    Вероятность. Если нет каких-то вводных данных, то воспользуйтесь хотя бы субъективным мнением «не сезон», например. И проставьте подходящий уровень. Здесь я бы отметил вероятность как низкую.

    Статус. Мы еще ничего не сделали, только идентифицировали риск, поэтому ставим «Новый».

    Комментарий. Здесь лог работ по риску. Пишем «уточнить у участников команды проекта» или «запросить информацию у отдела кадров».

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

    Риск 2

    Формулировка. Риск, что приемка будет задержана по причине отсутствия или занятости представителя заказчика. Это может оказать влияние на сроки сдачи проекта.

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

    Вероятность. Стоит учитывать дополнительные факторы, как мне кажется. Заинтересованность заказчика, условия его работы. Для начала я бы обозначил «Низкую» вероятность данного риска, так как заказчик обратился к нам, следовательно – у него есть потребность. Можем ожидать некоторую вовлеченность и участие в проекте.

    Статус. Новый, мы же только-только определили его.

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

    Рисков больше, на самом деле. Специалист может заболеть, уволиться. Могут налагаться пени за просрочку, и заказчик не пойдет на ослабление сроков сдачи, так как ему выгоднее потянуть время. Поставщик может не справиться со сроками доставки оборудования, или же оборудование может оказаться бракованным или вообще не тем, что было заказано.

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

    Карта рисков

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

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

    Ниже пример диаграммы из другого проекта (сделано в Excel). По оси абсцисс у нас располагается влияние (Impact), чем дальше вправо – тем сильнее влияние на проект. По оси ординат – вероятность (Probability) наступления события. R1…Rn – это номера рисков из реестра, используем в качестве подписи.

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

    image

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

    Первые три столбца – ссылки на другую вкладку, чтобы значения автоматически подставлялись. Столбцы D и E определяют цифровые значения риска, чтобы диаграмма построилась корректно. В столбцах G и H, как можно увидеть, у меня промежуточная, техническая таблица соответствия, чтобы VLOOKUP (в русской версии – ВПР) мог правильно подставить значения.

    image

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

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

    image

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

    image

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

    Секретный огнетушитель

    Ключевым же составляющим, которое помогает обеспечивать безопасность, я считаю общение.

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

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

    Приведу небольшой пример.

    Настройка оборудования, до завершения задачи один день по графику, в очередной раз связываюсь с инженером в надежде услышать, что все закончено.
    — Привет, Костя, как дела с настройкой?
    — Привет. Нормально. Почти закончили. Правда, там остался один момент с настроечкой, которую еще не совсем понятно, как делать.
    Где-то здесь у меня в мыслях начинает загораться красная лампочка – к задаче нужно приступать с пониманием того, как будет осуществляться работа. Для инженера в данном случае какой-то из элементов настройки непонятен – это значит, что требуется дополнительное исследование вопроса, а оно может затянуться. Уточняю.
    — А что за настроечка? Сложное что-то?
    — Да там… *поток технических деталей, в которых, к сожалению, я не разбираюсь*
    — Понятно (нет). Что делать-то планируешь с этим?
    — Еще не знаю. Посмотрю в интернете, что пишут на этот счет…
    Лампочка горит уже сильнее
    — …вероятно нужно будет обратиться к производителю, спросить у них.
    Все, стоп-сигнал. Инженер потратит часа два-три на поиск решения, есть вероятность, что он не найдет решения, и мы будем вынуждены обратиться к производителю. А такое обращение может легко затянуться на несколько дней.

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

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

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

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

    Итог


    К слову сказать, даже умение управлять рисками на уровне PMI-RMP (Risk Management Professional) не сможет вас обезопасить на 100%.

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

    Важно понимать, что управление рисками – это навык. Его тоже можно и нужно развивать. Теоретическую часть можно почерпнуть из стандартов по управлению проектами (например: PMBOK, PRINCE2) или пройдя специализированные курсы. Практической же частью вам следует заниматься самостоятельно, каждый день.

    Извлекайте уроки, учитесь на своих и чужих ошибках. И тогда количество «пожаров» будет неуклонно сокращаться, а успешный результат станет куда более достижимым. Удачи!
    • +13
    • 5.9k
    • 6
    ICL Services
    102.38
    Цифровые технологии для бизнеса
    Share post

    Comments 6

      0
      Все, стоп-сигнал. Инженер потратит часа два-три на поиск решения, есть вероятность, что он не найдет решения, и мы будем вынуждены обратиться к производителю. А такое обращение может легко затянуться на несколько дней.

      Я договариваюсь с инженером, что вернусь к нему за новостями через два-три часа

      В принципе всё верно, но как-то однобоко и незавершенно.
      Я в данном случае про то, что не описано, например, про то как выявлять риски, как определять степень влияния и вероятность возникновения, как актуализировать эти свойства и т.п.

      Ну а то что ни словом не упомянуты Contingency plan и Mitigation plan и вовсе выглядит странно. Вот это вот «договариваюсь с инженером» совершенно несерьезный подход.
        0
        Здравствуйте!
        Согласен, стоило рассказать про качественно\количественный анализ, привести более детальный разбор шкалы и, разумеется, про реакцию на риск. Спасибо, что подсветили, принял к сведению.
        0
        Тем не менее, мне кажется близким этот образ, когда я говорю об управлении рисками, потому как последствия неправильного контроля могут быть, порой, не менее драматичными.

        Напомнило бородатый анекдот
        Идет медведь по лесу, видит — машина горит. Сел в нее и сгорел.

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

          2. Про риски на этапе планирования.
          Согласовать с заказчиком… Подсветить… Заручиться согласием и со спокойной совестью продолжать работать над остальной частью проекта
          Где ключевое действие?! Где то, что надо делать после любого согласования, «подсвечивания» и «заручения» с каждым участником проекта?!

          3. Про «секретный огнетушитель». Вообще-то эта часть статьи про обязательные мероприятия. Коммуникации — это ядро работы ПМ, про какие-такие секретные штуки идёт речь? Вся работа ПМ строится через общение; почти все артефакты — только для самого ПМ, они сами по себе ничего не делают. Сделали контрольный звонок, узнали о проблеме, взяли на заметку — вот он, оказывается, секрет работы! Н-да. Вообще говоря, ждал в этом месте, как будет раскрыта тайна управления рисками на стороне заказчика. Но нет, выбран элементарный пример из учебника для первоклашек — как круто можно поставить галочку о проделанной работе.
          В зависимости от критичности, нормальный ПМ уже названивал бы другим инженерам, искал у вендора, поставщика, коллег контакты нужного спеца (инженерам на объекте часто не до обзвона и поиска людей, у них не всегда есть доступ к ресурсам, которые как раз ПМ может обеспечить).
          Не, гораздо приятнее отсчитать 2-3 часа и перезвонить, узнать, что поздно пить Боржоми. Элементарно: день подходит к концу, никого уже не поймать, нужные свои и чужие люди на завтра уже распланированы на другие задачи/города/отпуски и т.п. Поэтому завтра потребуется в два раза больше усилий и времени; итого день потерян. Заметим, в этом диалоге с инженером ПМ вообще никак не озаботился ни предложением инженеру орг. помощи, ни прорисовкой дальнейших вариантов развития событий. А инженер даже, как правило, не подозревает о критичности задачи, у него нет перед глазами всех этих красивых Гантов и прочих ваших X Plans. Ему гораздо интереснее покопаться в этой задаче, поэтому сам он может и не попросить о помощи, и не спросить о сроках.
            0
            Здравствуйте, спасибо за развернутый комментарий. Попробую ответить по порядку.

            Про притчу.
            Возможно, выбранная притча не на 100% отвечает тому посылу, который хотелось заложить. Как вижу — вопрос возник у вас. Значит, вероятно, что кто-то еще тоже задается этим вопросом. Поэтому немного разверну подробнее свою мысль.
            Моя рекомендация заключается в том, чтобы при анализе рисков команда была разносторонней (но вовлеченной в проект). И, если проводить сессию по анализу рисков, то получится, что на взятый для примера вопрос «коллеги, давайте подумаем, что может у нас пойти не так во время миграции» будут поступать разные комментарии.
            Специалист сетевой поддержки сразу подумает про организацию VLAN, открытие маршрутов, настройку фаерволов и т.д. Специалист серверной поддержки будет подсвечивать риски связи с контроллером домена, дублирования имен, каких-то проблем интеграций приложений и компонентов между собой, еще что-то.
            Если кого-то из специалистов не будет на встрече, например, по поддержке баз данных, то риск того, что SQL Server может элементарно не запуститься после переезда, останется невыявленным и, соответственно, неконтролируемым.
            В роли же «зрячего» для команды может выступить архитектор, эксперт широкого профиля, который уже проводил такую миграцию и сможет по пунктам рассказать, где с чем можно столкнуться и как с этим работать.

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

            Про секретный огнетушитель.
            Здесь в некоторых моментах позволю себе не согласиться с вашей точкой зрения.
            Полностью согласен, что коммуникации – основной инструмент работы ПМ. Однако в данной главе я обращаюсь к тем людям, которые по каким-то причинам пренебрегают коммуникациями и не уделяют им достаточно внимания. Человек может знать, что коммуникации важны, но по факту их не использовать. Поэтому я подсвечиваю этот пункт еще раз, чтобы у читателя была возможность еще раз переосмыслить свой подход к коммуникациям.
            Не согласен с тем, что артефакты только для самого ПМа. Заказчики проекта зачастую хотят знать, как именно будет осуществляться проект. Это серьезные инвестиции, поэтому правила работы должны быть согласованы и соблюдаться в течение проекта. Также вопросы периодически возникают у команды, и данные артефакты помогут на них ответить.
            Согласен с тем, что пример взят элементарный. Это сделано намеренно, все-таки целевая аудитория – те, кто слабо знаком с управлением рисками, а не матерые ПМы, каждый из которых обладает приличным опытом и багажом собственных инструментов и может сам написать с десяток статей.

            Мне показалось интересным ваше видение реакции ПМа на выявленный риск в разговоре с инженером. Если вы обратите внимание на теорию Дугласа Макгрегора (Теория X и теория Y), то увидите, что там описывается два разных подхода к управлению людьми. Менеджер типа X, думаю, поступил бы именно так, как вы говорите. Однако, я, скорее, отношусь ко второму типу управленцев, которые в большинстве случаев доверяют сотрудникам. Этот подход тоже работает.
            Безусловно, в данной ситуации стоит уточнить нужна ли помощь, сколько времени может занять поиск решения, степень уверенности инженера в своей способности решить ситуацию и прочее. Менеджер должен помогать команде. Однако мне это показалось настолько само собой разумеющимся, что я даже не стал упоминать этого в диалоге. Прошу прощения за это недопонимание.

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

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

            Извините, если слишком длинно получилось и еще раз спасибо за обратную связь.
            0
            Раз ввязался, то продолжу )
            1. Про притчу.
            Значит, мои слова были непрозрачны. И притча-то к месту, и к методике вообще никаких вопросов, всё верно. Я был лишь против разжёвывания применительно к притче, потому как сразу щёлкает тумблер анализа в голове, начинаешь вдумываться в притчу и оказывается, что она не выдерживает никакой критики (например, мудрецы, особенно слепые, отличаются от обычных смертных способностью думать, анализировать, поэтому такая ситуация невозможна). Более-менее опытные спецы даже без архитектора в своём анализе будут автоматически учитывать смежные области хотя бы в силу опыта, а не только своих знаний, не говоря уже об учёте явно формулируемых выводов других спецов. Т.е. прямая противоположность притче.

            2. Про риски.
            Я там специально не стал прямо прописывать ответ ). Повторюсь, можно распрекрасно всё вышеперечисленное нами выполнить, но в итоге остаться у разбитого корыта только из-за того, что вы не акцентировали (но ведь знаете про это, уверен) внимание на том, что должно быть в результате согласований и пр. — зафиксированное подтверждение коммуникации. Например, кратко набросали в письме человеку о чём договорились. Дальше можно много расшифровывать, т.к. вид фиксации сильно зависит от многих условий, но смысл, надеюсь, понятен. Нет фиксации — смело повышаем на ступень вероятность негативного сценария.

            3. Огнетушитель.
            Вот чем полезна письменная фиксация ). Я же сказал "почти все артефакты", тем самым выделил то, что речь о большинстве их. Ну кто будет в здравом уме говорить, что офиц. (или формальные) документы только для ПМ.
            И ещё раз про фиксацию ). ПМ не должен быть (в идеальном случае, конечно) X или Y, но должен вести себя сообразно ситуации, и поэтому я начал с "в зависимости от критичности...", вложив туда как раз всю предыдущую и текущую работу ПМ по оценке тех же рисков. А прямо из вашего текста и получилась та странная картина с галочкой. И это не про «доверие сотрудникам». Люди не роботы. Инженер (здесь вообще про любого сотрудника), как и любой человек, может неправильно оценить своё время, может забыть о каких-то из многих внешних факторах (но которые у вас в ваших артефактах, и перед глазами). Ваш простой вопрос:
            1) даёт (напоминает) инженеру варианты решения задачи;
            2) автоматически запускает его переоценку ситуации;
            3) может дать психологическую поддержку.
            Поэтому, если уж делается пример с диалогом, да ещё для тех, «кто слабо знаком с управлением рисками» (что, кстати, противоречит "это показалось настолько само собой разумеющимся"), то в этом случае не стоит упускать крайне важный фрагмент коммуникации.
            Про информирование команды всё верно. Поэтому "как я понял, ваш опыт говорит, что инженер не имеет..." — ни в коем случае. Я хотел лишь сказать, что полностью всеми планами, всеми сроками управляет ПМ. Остальные сотрудники, как правило, не обладают возможностью обозревать всю картину проекта, которая, как правило, динамически меняется. Они точно не знают (и не всегда должны знать и помнить) всех факторов. В данном диалоге от краткого повторения/напоминания/уточнения планов (вех) с сотрудником вряд ли будет хуже.

            Я тем более не гений формулировок, поэтому коротко не получилось. Есть надежда, что поняли друг друга )

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