Comments 6
Все, стоп-сигнал. Инженер потратит часа два-три на поиск решения, есть вероятность, что он не найдет решения, и мы будем вынуждены обратиться к производителю. А такое обращение может легко затянуться на несколько дней.
Я договариваюсь с инженером, что вернусь к нему за новостями через два-три часа
В принципе всё верно, но как-то однобоко и незавершенно.
Я в данном случае про то, что не описано, например, про то как выявлять риски, как определять степень влияния и вероятность возникновения, как актуализировать эти свойства и т.п.
Ну а то что ни словом не упомянуты Contingency plan и Mitigation plan и вовсе выглядит странно. Вот это вот «договариваюсь с инженером» совершенно несерьезный подход.
Тем не менее, мне кажется близким этот образ, когда я говорю об управлении рисками, потому как последствия неправильного контроля могут быть, порой, не менее драматичными.
Напомнило бородатый анекдот
Идет медведь по лесу, видит — машина горит. Сел в нее и сгорел.
UFO just landed and posted this here
Здравствуйте, спасибо за развернутый комментарий. Попробую ответить по порядку.
Про притчу.
Возможно, выбранная притча не на 100% отвечает тому посылу, который хотелось заложить. Как вижу — вопрос возник у вас. Значит, вероятно, что кто-то еще тоже задается этим вопросом. Поэтому немного разверну подробнее свою мысль.
Моя рекомендация заключается в том, чтобы при анализе рисков команда была разносторонней (но вовлеченной в проект). И, если проводить сессию по анализу рисков, то получится, что на взятый для примера вопрос «коллеги, давайте подумаем, что может у нас пойти не так во время миграции» будут поступать разные комментарии.
Специалист сетевой поддержки сразу подумает про организацию VLAN, открытие маршрутов, настройку фаерволов и т.д. Специалист серверной поддержки будет подсвечивать риски связи с контроллером домена, дублирования имен, каких-то проблем интеграций приложений и компонентов между собой, еще что-то.
Если кого-то из специалистов не будет на встрече, например, по поддержке баз данных, то риск того, что SQL Server может элементарно не запуститься после переезда, останется невыявленным и, соответственно, неконтролируемым.
В роли же «зрячего» для команды может выступить архитектор, эксперт широкого профиля, который уже проводил такую миграцию и сможет по пунктам рассказать, где с чем можно столкнуться и как с этим работать.
Про риски на этапе планирования.
Откровенно говоря, я не понял, что именно вы хотите подсветить в этом моменте. Под действием я понимаю определение стратегии ответа на риск и последующую работу и контроль, согласно подготовленному плану. Выявили, что инженер может быть в отпуске – пошли к инженеру\руководителю\в отдел кадров. Спросили, согласовали, что проект обеспечен ресурсами, зафиксировали в реестре. Если необходимо, то подсветили где-то еще, в зависимости от требуемого уровня коммуникаций – в отчете каком-нибудь, например. И все, риск проработан, закрыт. В случае, если я совсем неправильно вас понял, то опишите подробнее, пожалуйста.
Про секретный огнетушитель.
Здесь в некоторых моментах позволю себе не согласиться с вашей точкой зрения.
Полностью согласен, что коммуникации – основной инструмент работы ПМ. Однако в данной главе я обращаюсь к тем людям, которые по каким-то причинам пренебрегают коммуникациями и не уделяют им достаточно внимания. Человек может знать, что коммуникации важны, но по факту их не использовать. Поэтому я подсвечиваю этот пункт еще раз, чтобы у читателя была возможность еще раз переосмыслить свой подход к коммуникациям.
Не согласен с тем, что артефакты только для самого ПМа. Заказчики проекта зачастую хотят знать, как именно будет осуществляться проект. Это серьезные инвестиции, поэтому правила работы должны быть согласованы и соблюдаться в течение проекта. Также вопросы периодически возникают у команды, и данные артефакты помогут на них ответить.
Согласен с тем, что пример взят элементарный. Это сделано намеренно, все-таки целевая аудитория – те, кто слабо знаком с управлением рисками, а не матерые ПМы, каждый из которых обладает приличным опытом и багажом собственных инструментов и может сам написать с десяток статей.
Мне показалось интересным ваше видение реакции ПМа на выявленный риск в разговоре с инженером. Если вы обратите внимание на теорию Дугласа Макгрегора (Теория X и теория Y), то увидите, что там описывается два разных подхода к управлению людьми. Менеджер типа X, думаю, поступил бы именно так, как вы говорите. Однако, я, скорее, отношусь ко второму типу управленцев, которые в большинстве случаев доверяют сотрудникам. Этот подход тоже работает.
Безусловно, в данной ситуации стоит уточнить нужна ли помощь, сколько времени может занять поиск решения, степень уверенности инженера в своей способности решить ситуацию и прочее. Менеджер должен помогать команде. Однако мне это показалось настолько само собой разумеющимся, что я даже не стал упоминать этого в диалоге. Прошу прощения за это недопонимание.
От себя добавлю вам небольшую рекомендацию. Как я понял, ваш опыт говорит, что инженер не имеет представления о зависимости последующих работ от результата его деятельности и не заинтересован в успешном результате проекта. На самом деле обеспечить такое понимание и создать заинтересованность – задача ПМа.
Команда должна быть в курсе состава работ, их сроков, критичности, календарного графика и (в том числе) имеющихся артефактов. Разумеется, могут быть требования по конфиденциальности. Однако, когда команда получает информацию, она проникается проблемой и задачей, это помогает сплотиться в единый коллектив, имеющий общую цель. Эффективность вырастает в разы. Поэтому настоятельно рекомендую учитывать это во время проектных работ.
Извините, если слишком длинно получилось и еще раз спасибо за обратную связь.
Про притчу.
Возможно, выбранная притча не на 100% отвечает тому посылу, который хотелось заложить. Как вижу — вопрос возник у вас. Значит, вероятно, что кто-то еще тоже задается этим вопросом. Поэтому немного разверну подробнее свою мысль.
Моя рекомендация заключается в том, чтобы при анализе рисков команда была разносторонней (но вовлеченной в проект). И, если проводить сессию по анализу рисков, то получится, что на взятый для примера вопрос «коллеги, давайте подумаем, что может у нас пойти не так во время миграции» будут поступать разные комментарии.
Специалист сетевой поддержки сразу подумает про организацию VLAN, открытие маршрутов, настройку фаерволов и т.д. Специалист серверной поддержки будет подсвечивать риски связи с контроллером домена, дублирования имен, каких-то проблем интеграций приложений и компонентов между собой, еще что-то.
Если кого-то из специалистов не будет на встрече, например, по поддержке баз данных, то риск того, что SQL Server может элементарно не запуститься после переезда, останется невыявленным и, соответственно, неконтролируемым.
В роли же «зрячего» для команды может выступить архитектор, эксперт широкого профиля, который уже проводил такую миграцию и сможет по пунктам рассказать, где с чем можно столкнуться и как с этим работать.
Про риски на этапе планирования.
Откровенно говоря, я не понял, что именно вы хотите подсветить в этом моменте. Под действием я понимаю определение стратегии ответа на риск и последующую работу и контроль, согласно подготовленному плану. Выявили, что инженер может быть в отпуске – пошли к инженеру\руководителю\в отдел кадров. Спросили, согласовали, что проект обеспечен ресурсами, зафиксировали в реестре. Если необходимо, то подсветили где-то еще, в зависимости от требуемого уровня коммуникаций – в отчете каком-нибудь, например. И все, риск проработан, закрыт. В случае, если я совсем неправильно вас понял, то опишите подробнее, пожалуйста.
Про секретный огнетушитель.
Здесь в некоторых моментах позволю себе не согласиться с вашей точкой зрения.
Полностью согласен, что коммуникации – основной инструмент работы ПМ. Однако в данной главе я обращаюсь к тем людям, которые по каким-то причинам пренебрегают коммуникациями и не уделяют им достаточно внимания. Человек может знать, что коммуникации важны, но по факту их не использовать. Поэтому я подсвечиваю этот пункт еще раз, чтобы у читателя была возможность еще раз переосмыслить свой подход к коммуникациям.
Не согласен с тем, что артефакты только для самого ПМа. Заказчики проекта зачастую хотят знать, как именно будет осуществляться проект. Это серьезные инвестиции, поэтому правила работы должны быть согласованы и соблюдаться в течение проекта. Также вопросы периодически возникают у команды, и данные артефакты помогут на них ответить.
Согласен с тем, что пример взят элементарный. Это сделано намеренно, все-таки целевая аудитория – те, кто слабо знаком с управлением рисками, а не матерые ПМы, каждый из которых обладает приличным опытом и багажом собственных инструментов и может сам написать с десяток статей.
Мне показалось интересным ваше видение реакции ПМа на выявленный риск в разговоре с инженером. Если вы обратите внимание на теорию Дугласа Макгрегора (Теория X и теория Y), то увидите, что там описывается два разных подхода к управлению людьми. Менеджер типа X, думаю, поступил бы именно так, как вы говорите. Однако, я, скорее, отношусь ко второму типу управленцев, которые в большинстве случаев доверяют сотрудникам. Этот подход тоже работает.
Безусловно, в данной ситуации стоит уточнить нужна ли помощь, сколько времени может занять поиск решения, степень уверенности инженера в своей способности решить ситуацию и прочее. Менеджер должен помогать команде. Однако мне это показалось настолько само собой разумеющимся, что я даже не стал упоминать этого в диалоге. Прошу прощения за это недопонимание.
От себя добавлю вам небольшую рекомендацию. Как я понял, ваш опыт говорит, что инженер не имеет представления о зависимости последующих работ от результата его деятельности и не заинтересован в успешном результате проекта. На самом деле обеспечить такое понимание и создать заинтересованность – задача ПМа.
Команда должна быть в курсе состава работ, их сроков, критичности, календарного графика и (в том числе) имеющихся артефактов. Разумеется, могут быть требования по конфиденциальности. Однако, когда команда получает информацию, она проникается проблемой и задачей, это помогает сплотиться в единый коллектив, имеющий общую цель. Эффективность вырастает в разы. Поэтому настоятельно рекомендую учитывать это во время проектных работ.
Извините, если слишком длинно получилось и еще раз спасибо за обратную связь.
UFO just landed and posted this here
Sign up to leave a comment.
Управление огнем как часть работы руководителя