😳 Менеджер проектов внутри матрицы
Классический путь менеджера проектов выглядит так: специалист в небольшой компании -> менеджер проектов в ней же -> менеджер в крупной компании. Это нормально: однажды у всех появляется желание порулить чем-нибудь масштабным. Но при переходе в крупную компанию поджидает менеджера масса сюрпризов. Если же управлять приходится внутренними проектами, сюрпризов будет еще больше.
В небольших компаниях у менеджера максимум два-три проекта, часто одной тематики или для одного клиента. Делают их небольшие команды, подчиняются они менеджеру проектов напрямую, он их и мотивирует, и следит за профессиональным развитием, и заявление на отпуск подписывает, и конфликты разруливает. Решения в таких компаниях принимаются быстро. До самого высокого босса рукой подать, и если он не полный идиот, то проекту всегда поможет.
И вот попадает наш менеджер, скажем, в банк с матричной оргструктурой. И понеслось. С одной стороны, есть все признаки проекта – ответственный менеджер, ограниченные сроки и бюджет, уникальный результат и план его достижения, проектная команда. С другой стороны, есть нюансы, которые нужно учесть, чтобы не сесть в лужу и не посадить туда проект.
Вот что важно понимать:
1. Для сотрудников в матрице работа в проекте – побочная деятельность. Есть еще масса иных обязанностей. Специалисты по взысканию разрабатывают методы взысканий и работают с клиентами по просроченной задолженности. Маркетинг занимается исследованиями рынка и ищет пути для продвижения услуг. Розничная сеть отвечает за продажи. И т.д. В этой жизни проекты на сто пятьдесят шестом месте, даже если декларируется обратное. Время на них выделяется по остаточному принципу, ведь за невыполнение основной работы по голове не погладят, а за невыполнение задач по проекту ничего не будет. А проектную премию ты еще попробуй получи.
2. Что еще хуже, по остаточному принципу выделяются и сами сотрудники для проектов. В матричной структуре, характерной для крупных российских компаний, своих подчиненных у менеджера проекта нет. Он обычно запрашивает у руководителей подразделений сотрудников в проект, а те уже выделяют кого получится. А лучшие люди всегда заняты непроектной работой. Конкуренции за участие в проекте нет – кому хочется взвалить на себя дополнительные неоплачиваемые обязанности?
3. Исчезает само понятие «проектная команда». Если в прошлой своей жизни менеджер имел дело со сплоченной группой людей, объединенных одной целью, то теперь это просто сотрудники с набором функций. Можно сразу отложить на дальнюю полку Peopleware и ей подобные книги, где воспевают идеи кристаллизации команды и рассказывают, как это здорово, когда все сидят в одной комнате. Ничего этого не будет – в лучшем случае люди выполнят свою часть работы.
4. Меняется и роль менеджера. Теперь ему важно не только быть интегратором и двигателем проекта, но и стать жестким контролером. Теперь только он заинтересован в успехе проекта.
5. В крупных организациях подразделения не просто плохо ладят друг с другом – враждуют. Случаи откровенного саботажа и нарушения договоренностей при выполнении проектных работ воспринимаются почти как норма. Со стороны это выглядит довольно странно. Казалось бы, что делить айтишникам с рисковиками? Почему юристы не могут договориться с бизнес-аналитиками? Зачастую такие конфликты – просто следствие подковерной борьбы руководителей за власть и влияние. Но менеджеру проектов от этого не легче, ему нужны согласованные действия всех участников проекта!
6. Часто менеджер играет еще и роль буфера между исполнителем и лицом с последней подписью в акте выполненных работ. Обычная практика — затягивание последней подписи, откладывание оплат за очередной этап. За все это отдуваться менеджеру проекта.
Что же делать в этой ситуации?
Классический путь менеджера проектов выглядит так: специалист в небольшой компании -> менеджер проектов в ней же -> менеджер в крупной компании. Это нормально: однажды у всех появляется желание порулить чем-нибудь масштабным. Но при переходе в крупную компанию поджидает менеджера масса сюрпризов. Если же управлять приходится внутренними проектами, сюрпризов будет еще больше.
В небольших компаниях у менеджера максимум два-три проекта, часто одной тематики или для одного клиента. Делают их небольшие команды, подчиняются они менеджеру проектов напрямую, он их и мотивирует, и следит за профессиональным развитием, и заявление на отпуск подписывает, и конфликты разруливает. Решения в таких компаниях принимаются быстро. До самого высокого босса рукой подать, и если он не полный идиот, то проекту всегда поможет.
И вот попадает наш менеджер, скажем, в банк с матричной оргструктурой. И понеслось. С одной стороны, есть все признаки проекта – ответственный менеджер, ограниченные сроки и бюджет, уникальный результат и план его достижения, проектная команда. С другой стороны, есть нюансы, которые нужно учесть, чтобы не сесть в лужу и не посадить туда проект.
Вот что важно понимать:
1. Для сотрудников в матрице работа в проекте – побочная деятельность. Есть еще масса иных обязанностей. Специалисты по взысканию разрабатывают методы взысканий и работают с клиентами по просроченной задолженности. Маркетинг занимается исследованиями рынка и ищет пути для продвижения услуг. Розничная сеть отвечает за продажи. И т.д. В этой жизни проекты на сто пятьдесят шестом месте, даже если декларируется обратное. Время на них выделяется по остаточному принципу, ведь за невыполнение основной работы по голове не погладят, а за невыполнение задач по проекту ничего не будет. А проектную премию ты еще попробуй получи.
2. Что еще хуже, по остаточному принципу выделяются и сами сотрудники для проектов. В матричной структуре, характерной для крупных российских компаний, своих подчиненных у менеджера проекта нет. Он обычно запрашивает у руководителей подразделений сотрудников в проект, а те уже выделяют кого получится. А лучшие люди всегда заняты непроектной работой. Конкуренции за участие в проекте нет – кому хочется взвалить на себя дополнительные неоплачиваемые обязанности?
3. Исчезает само понятие «проектная команда». Если в прошлой своей жизни менеджер имел дело со сплоченной группой людей, объединенных одной целью, то теперь это просто сотрудники с набором функций. Можно сразу отложить на дальнюю полку Peopleware и ей подобные книги, где воспевают идеи кристаллизации команды и рассказывают, как это здорово, когда все сидят в одной комнате. Ничего этого не будет – в лучшем случае люди выполнят свою часть работы.
4. Меняется и роль менеджера. Теперь ему важно не только быть интегратором и двигателем проекта, но и стать жестким контролером. Теперь только он заинтересован в успехе проекта.
5. В крупных организациях подразделения не просто плохо ладят друг с другом – враждуют. Случаи откровенного саботажа и нарушения договоренностей при выполнении проектных работ воспринимаются почти как норма. Со стороны это выглядит довольно странно. Казалось бы, что делить айтишникам с рисковиками? Почему юристы не могут договориться с бизнес-аналитиками? Зачастую такие конфликты – просто следствие подковерной борьбы руководителей за власть и влияние. Но менеджеру проектов от этого не легче, ему нужны согласованные действия всех участников проекта!
6. Часто менеджер играет еще и роль буфера между исполнителем и лицом с последней подписью в акте выполненных работ. Обычная практика — затягивание последней подписи, откладывание оплат за очередной этап. За все это отдуваться менеджеру проекта.
Что же делать в этой ситуации?
Как выжить в таких условиях и успешно выполнять свою работу?
1. Успокоиться – не вы первый сталкиваетесь с такой ситуацией. Рассматривайте ее как интересный профессиональный и жизненный опыт.)
2. Основное оружие менеджера в любом проекте – это коммуникации. Здесь же навыки выстраивания отношений и связей приобретают особое значение. Вы должны найти тех людей, которым результаты проекта важны. Это непростая задача, но, решив ее, вы получите союзников и единомышленников.
3. И еще раз о коммуникациях. Познакомьтесь со всеми подразделениями, со всеми руководителями, станьте узнаваемым и создайте о себе как можно более позитивное мнение. Перейдите на «ты» с коллегами из других подразделений, это тоже разрушает барьеры.
4. Нужно наладить контакт со спонсором – топ-менеджером, который заинтересован в успехе проекта. Спонсор должен быть погружен в проект как можно глубже. Часто встречайтесь с ним, рассказывайте о результатах и не скрывайте проблем. Правильно настроенный спонсор – грозное оружие в умелых руках и хороший инструмент для разрушения барьеров и преодоления сопротивления. Отсутствие заинтересованного спонсора – верная гибель проекта.
5. Сделайте проект максимально прозрачным для всех вовлеченных в него людей. Рассылайте отчеты о ходе проекта. Не реже раза в неделю организовывайте встречи ключевых участников для обсуждения его статуса, дальнейших задач и возникающих проблем. Это не поможет кристаллизации команды, но сделает проект частью жизни участников, уменьшит вероятность отторжения. Не забывайте хвалить участников проекта – люди обращают на это внимание, им это приятно, это запоминается.
6. Если в компании развита бюрократия (гарантирую, что так оно и есть), в ней наверняка внедрен и какой-то регламент по выполнению проектов. Работать по нему наверняка невозможно, да и не нужно, но лучше держать его под рукой – ссылки на утвержденный регламент могут слегка остудить пыл противников. В бюрократической среде вес утвержденного и подписанного документа увеличивается.
7. Фиксируйте все решения в письменном виде. Никаких устных договоренностей и обещаний. Это правило справедливо для любого проекта, но тут его выполнение обязательно и критично для успеха.
Ну и самое главное... May the Force be with you.)
1. Успокоиться – не вы первый сталкиваетесь с такой ситуацией. Рассматривайте ее как интересный профессиональный и жизненный опыт.)
2. Основное оружие менеджера в любом проекте – это коммуникации. Здесь же навыки выстраивания отношений и связей приобретают особое значение. Вы должны найти тех людей, которым результаты проекта важны. Это непростая задача, но, решив ее, вы получите союзников и единомышленников.
3. И еще раз о коммуникациях. Познакомьтесь со всеми подразделениями, со всеми руководителями, станьте узнаваемым и создайте о себе как можно более позитивное мнение. Перейдите на «ты» с коллегами из других подразделений, это тоже разрушает барьеры.
4. Нужно наладить контакт со спонсором – топ-менеджером, который заинтересован в успехе проекта. Спонсор должен быть погружен в проект как можно глубже. Часто встречайтесь с ним, рассказывайте о результатах и не скрывайте проблем. Правильно настроенный спонсор – грозное оружие в умелых руках и хороший инструмент для разрушения барьеров и преодоления сопротивления. Отсутствие заинтересованного спонсора – верная гибель проекта.
5. Сделайте проект максимально прозрачным для всех вовлеченных в него людей. Рассылайте отчеты о ходе проекта. Не реже раза в неделю организовывайте встречи ключевых участников для обсуждения его статуса, дальнейших задач и возникающих проблем. Это не поможет кристаллизации команды, но сделает проект частью жизни участников, уменьшит вероятность отторжения. Не забывайте хвалить участников проекта – люди обращают на это внимание, им это приятно, это запоминается.
6. Если в компании развита бюрократия (гарантирую, что так оно и есть), в ней наверняка внедрен и какой-то регламент по выполнению проектов. Работать по нему наверняка невозможно, да и не нужно, но лучше держать его под рукой – ссылки на утвержденный регламент могут слегка остудить пыл противников. В бюрократической среде вес утвержденного и подписанного документа увеличивается.
7. Фиксируйте все решения в письменном виде. Никаких устных договоренностей и обещаний. Это правило справедливо для любого проекта, но тут его выполнение обязательно и критично для успеха.
Ну и самое главное... May the Force be with you.)
👾 История о том, как неправильно создавать продукты
Жил-был мальчик по имени Адам Мясников. Он полюбил программирование, а оно полюбило его. Поэтому в юном возрасте он начал писать компьютерную игру и потратил на это - та-дам! - 13 лет.
Красиво и подробно эта история изложена изрядно повзрослевшим и поумневшим автором вот в этом видео (осторожно: быстрый инглиш):
https://youtu.be/2b0tSu0QDQ0
Ну а мне бы хотелось обратить ваше внимание на интересный проектный аспект этой тринадцатилетней эпопеи: Адам говорит, что четко исполнил все задуманное, все задачи, которые он запланировал, были выполнены, все функции были реализованы.
И это ошибка, весьма характерная для начинающих менеджеров. В реальности, где проекты не длятся по 13 лет, потому что клиенты не готовы ждать так долго, подобная ситуация невозможна - у каждой задачи, у каждой клиентской "хотелки" есть приоритет. Одна из обязанностей менеджера проектов - помочь заказчику установить, какие свойства будущего продукта критичны, какие - важны, какие стоит отложить на будущее, а без каких и вовсе можно обойтись. Управляя набором этих приоритетов, менеджер управляет объемом проекта - и так влияет на сроки и бюджет.
Неловко говорить об азбучных истинах, но опыт показывает, что многие современные менеджеры не понимают даже этого. Кто не верит - посмотрите видео еще раз.)
Если бы юный Адам знал о приоритизации, он бы выделил из огромного набора планируемых к выполнению задач только самые важные и сократил бы всю историю в несколько раз (там много других нюансов, одна возня с тенями и текстурами чего стоит, но они для нас менее интересны).
А вообще Адам вызывает уважение - вот это верность идее, вот это твердость желания достигнуть цель. Ну и выводы парень сделал верные. )
Не забывайте о приоритетах.
Жил-был мальчик по имени Адам Мясников. Он полюбил программирование, а оно полюбило его. Поэтому в юном возрасте он начал писать компьютерную игру и потратил на это - та-дам! - 13 лет.
Красиво и подробно эта история изложена изрядно повзрослевшим и поумневшим автором вот в этом видео (осторожно: быстрый инглиш):
https://youtu.be/2b0tSu0QDQ0
Ну а мне бы хотелось обратить ваше внимание на интересный проектный аспект этой тринадцатилетней эпопеи: Адам говорит, что четко исполнил все задуманное, все задачи, которые он запланировал, были выполнены, все функции были реализованы.
И это ошибка, весьма характерная для начинающих менеджеров. В реальности, где проекты не длятся по 13 лет, потому что клиенты не готовы ждать так долго, подобная ситуация невозможна - у каждой задачи, у каждой клиентской "хотелки" есть приоритет. Одна из обязанностей менеджера проектов - помочь заказчику установить, какие свойства будущего продукта критичны, какие - важны, какие стоит отложить на будущее, а без каких и вовсе можно обойтись. Управляя набором этих приоритетов, менеджер управляет объемом проекта - и так влияет на сроки и бюджет.
Неловко говорить об азбучных истинах, но опыт показывает, что многие современные менеджеры не понимают даже этого. Кто не верит - посмотрите видео еще раз.)
Если бы юный Адам знал о приоритизации, он бы выделил из огромного набора планируемых к выполнению задач только самые важные и сократил бы всю историю в несколько раз (там много других нюансов, одна возня с тенями и текстурами чего стоит, но они для нас менее интересны).
А вообще Адам вызывает уважение - вот это верность идее, вот это твердость желания достигнуть цель. Ну и выводы парень сделал верные. )
Не забывайте о приоритетах.
YouTube
The Game That Time Forgot
The true story of how I spent 13 years making a video game.
Download: https://adambutcher.itch.io/tobias-and-the-dark-sceptres
Written and Directed by @AdamButcherFilm
"Awe Baby" photo from @johnengler
Download: https://adambutcher.itch.io/tobias-and-the-dark-sceptres
Written and Directed by @AdamButcherFilm
"Awe Baby" photo from @johnengler
Мне в команду нужен технический специалист. Мы называем таких инженерами по внедрению.
Нужно быть готовым в ближайшие пару лет (или больше) анализировать логи, писать запросы и скрипты, разбирать инциденты, настраивать стенды, помогать менеджерам в проектах и клиентам в технических вопросах.
Нужно знать линукс, sql, иметь представление о программировании и голову на плечах.
С нас - разумный поток задач, трудоустройство по ТК, приятный коллектив и вменяемое начальство.
Если вам интересно, пришлите мне резюме на psilonsk@gmail.com, в теме письма без кавычек напишите "ИВ 2019".
Нужно быть готовым в ближайшие пару лет (или больше) анализировать логи, писать запросы и скрипты, разбирать инциденты, настраивать стенды, помогать менеджерам в проектах и клиентам в технических вопросах.
Нужно знать линукс, sql, иметь представление о программировании и голову на плечах.
С нас - разумный поток задач, трудоустройство по ТК, приятный коллектив и вменяемое начальство.
Если вам интересно, пришлите мне резюме на psilonsk@gmail.com, в теме письма без кавычек напишите "ИВ 2019".
☔️ Как управлять рисками в проектах. Часть 1.
Говорить об управлении рисками правильнее всего на языке теории вероятностей. Но такой рассказ будет интересен только выпускникам мехмата, и точно не поможет обычному менеджеру начать управлять рисками. Так что обойдемся без математики. )
Итак, что такое риск в управлении проектами? Риск – это негативное событие, которое может произойти и повлиять на проект.
Давайте разберем это определение. Во-первых, риск – это негативное событие. Предположим, вы выходите на улицу, и у вас в кармане лежит сто рублей. И при этом карман дырявый, вам все некогда его зашить. Можно ли при таком раскладе потерять этот стольник? Да, конечно. Значит, есть возможность негативного события – потери денег. Это и будет риск.
Но при этом вполне возможно, что вы сами найдете оброненные кем-то сто рублей. Редко, но бывает же! Найти деньги – это для вас уже явно позитивное событие. Позитивные события обычно называются не рисками, а потенциальными возможностями, управление ими ничем не отличается от управления рисками. С точки зрения технологий менеджмента, события нейтральны, а эмоциональную окраску им придают люди. Но вот что интересно, даже в компаниях, в которых внедрена система управления рисками, никто не управляет потенциальными возможностями, по крайней мере, с помощью риск-инструментов. Ни в проектах, ни в операционной деятельности. То ли из-за того, что возможностями и рисками управляют разные люди (и разные подразделения компании), то ли из-за того, что никто не верит в хорошее и потому даже не пытается этим хорошим управлять.
Во-вторых, риск – это событие, которое может произойти. Нас не интересуют события, которые абсолютно точно произойдут. Если мы ожидаем такое событие, и оно на нас повлияет, то нет смысла управлять им как риском. Это событие для нас – просто очередная задача, которую нужно запланировать и выполнить. Нас не волнуют и события, которые абсолютно точно произойти не могут. Нет события – нет проблемы, нечем управлять. Вообразим, что мы отправляемся на машине из Москвы в Красноярск. Какие неприятности могут поджидать нас по дороге? Ну, например, мы можем проколоть шину. Это событие может произойти, а может и не произойти. Значит, это риск, которым мы должны управлять. Какие еще? Мы можем устать и захотеть спать. Нужно ли управлять этим событием как риском? Нет, не нужно – расстояние 4000 км преодолеть за рулем без отдыха невозможно, поэтому мы не должны относиться к этому событию как к имеющему вероятностную природу. Оно гарантированно произойдет, мы гарантированно устанем! Значит, нужно просто запланировать, в каких точках маршрута мы будем отдыхать, и сколько времени мы будем это делать. Нужно ли нам бояться, что по дороге мы встретим агрессивно настроенного тиранозавра? Нет, не нужно, мы его точно не встретим (они вымерли, если кто не в курсе), поэтому для нас такого риска нет, управлять им не надо.
В-третьих, риск влияет на проект. Нас не интересуют события, которые не влияют на наш проект. Мы собираемся ехать в Красноярск, и волнует ли нас, что в Египте вчера акула съела двух ливийских туристок? Мы искренне сочувствуем туристкам, и признаем, что нападение акулы – явный риск. Но по пути в Красноярск мы можем не обращать на него внимания.
Итак, еще раз: риск – это негативное событие, которое может произойти и повлиять на проект.
Очевидно, что влиять на сами события мы не можем – ни акуле, ни шине, ни желанию спать, ни потере ста рублей не прикажешь не случаться. Чем же мы тогда управляем, если не можем влиять на события? Мы управляем их влиянием на нас.
Управлять рисками нужно для того, чтобы избежать действия негативных событий или ослабить его.
Говорить об управлении рисками правильнее всего на языке теории вероятностей. Но такой рассказ будет интересен только выпускникам мехмата, и точно не поможет обычному менеджеру начать управлять рисками. Так что обойдемся без математики. )
Итак, что такое риск в управлении проектами? Риск – это негативное событие, которое может произойти и повлиять на проект.
Давайте разберем это определение. Во-первых, риск – это негативное событие. Предположим, вы выходите на улицу, и у вас в кармане лежит сто рублей. И при этом карман дырявый, вам все некогда его зашить. Можно ли при таком раскладе потерять этот стольник? Да, конечно. Значит, есть возможность негативного события – потери денег. Это и будет риск.
Но при этом вполне возможно, что вы сами найдете оброненные кем-то сто рублей. Редко, но бывает же! Найти деньги – это для вас уже явно позитивное событие. Позитивные события обычно называются не рисками, а потенциальными возможностями, управление ими ничем не отличается от управления рисками. С точки зрения технологий менеджмента, события нейтральны, а эмоциональную окраску им придают люди. Но вот что интересно, даже в компаниях, в которых внедрена система управления рисками, никто не управляет потенциальными возможностями, по крайней мере, с помощью риск-инструментов. Ни в проектах, ни в операционной деятельности. То ли из-за того, что возможностями и рисками управляют разные люди (и разные подразделения компании), то ли из-за того, что никто не верит в хорошее и потому даже не пытается этим хорошим управлять.
Во-вторых, риск – это событие, которое может произойти. Нас не интересуют события, которые абсолютно точно произойдут. Если мы ожидаем такое событие, и оно на нас повлияет, то нет смысла управлять им как риском. Это событие для нас – просто очередная задача, которую нужно запланировать и выполнить. Нас не волнуют и события, которые абсолютно точно произойти не могут. Нет события – нет проблемы, нечем управлять. Вообразим, что мы отправляемся на машине из Москвы в Красноярск. Какие неприятности могут поджидать нас по дороге? Ну, например, мы можем проколоть шину. Это событие может произойти, а может и не произойти. Значит, это риск, которым мы должны управлять. Какие еще? Мы можем устать и захотеть спать. Нужно ли управлять этим событием как риском? Нет, не нужно – расстояние 4000 км преодолеть за рулем без отдыха невозможно, поэтому мы не должны относиться к этому событию как к имеющему вероятностную природу. Оно гарантированно произойдет, мы гарантированно устанем! Значит, нужно просто запланировать, в каких точках маршрута мы будем отдыхать, и сколько времени мы будем это делать. Нужно ли нам бояться, что по дороге мы встретим агрессивно настроенного тиранозавра? Нет, не нужно, мы его точно не встретим (они вымерли, если кто не в курсе), поэтому для нас такого риска нет, управлять им не надо.
В-третьих, риск влияет на проект. Нас не интересуют события, которые не влияют на наш проект. Мы собираемся ехать в Красноярск, и волнует ли нас, что в Египте вчера акула съела двух ливийских туристок? Мы искренне сочувствуем туристкам, и признаем, что нападение акулы – явный риск. Но по пути в Красноярск мы можем не обращать на него внимания.
Итак, еще раз: риск – это негативное событие, которое может произойти и повлиять на проект.
Очевидно, что влиять на сами события мы не можем – ни акуле, ни шине, ни желанию спать, ни потере ста рублей не прикажешь не случаться. Чем же мы тогда управляем, если не можем влиять на события? Мы управляем их влиянием на нас.
Управлять рисками нужно для того, чтобы избежать действия негативных событий или ослабить его.
А если, несмотря на все наши ухищрения, негативное событие произошло? Тогда это уже не риск, а материализовавшийся риск, иными словами – проблема.
Момент, когда риск материлиализуется и превращается в проблему, называют событием риска. Как же узнать, в какой момент риск стал проблемой? Вот смотрите, еще секунду назад мы ехали с ветерком по прекрасной федеральной трассе. И вдруг – пшшшш... Шина-то проколота. Конечно, из кабины машины не видно, как огромный ржавый гвоздь входит в правое переднее колесо. Событие риска произошло, но мы его не видим. Зато машина вильнула в сторону, она уже едет как-то не так, и мы слышали странный хлопок. Т.е. мы узнали о том, что событие риска произошло, по некоторым признакам, симптомам, которые называются индикаторами риска. Именно отслеживание этих индикаторов – одна из основных задач при управлении рисками.
На самом-то деле управлением рисками мы занимаемся в нашей жизни каждый день, даже не задумываясь об этом. Вот представьте, просыпаетесь вы – а за окном зима. Вы думаете: «Ага, холодно стало. Не замерзнуть бы по пути на работу. А то замерзну, заболею, буду кашлять, не смогу пойти на свидание в пятницу. А хочется. Что же делать? Надену-ка я шарф потеплее и ботинки вместо кроссовок... А вдруг все таки замерзну? Ну, тогда зайду в кафе по дороге, выпью горячего кофе.» Все эти мысли пролетают в вашей голове мгновенно, вы их на уровне сознания даже не фиксируете. И так – во многих делах. Управление рисками на уровне подсознания – естественное и необходимое условие нашего выживания.
Если же вывести этот процесс на сознательный уровень и формализовать, то получится, что управление рисками состоит из нескольких универсальных этапов:
1. Выявить риски. Мы определяем как можно больше негативных событий, которые могут на нас повлиять. На этом этапе для каждого найденного риска также нужно выявить индикаторы возникновения. «Ого, а за окном-то зима! Значит, существует риск замерзнуть!» Каковы индикаторы этого риска? Например, уши покалывает и вы их «не чувствуете». Как получили такой индикатор – все, замерзли.
2. Оценить степень воздействия риска. Как известно, в бизнесе существует только то, что можно измерить количественно. Поэтому для каждого найденного риска необходимо ответить на два вопроса:
2.a «Насколько возможно возникновение этого риска?» и
2.b «Насколько сильно будет его влияние?».
Как правильно ответить на эти вопросы, что значит «насколько возможно» и «насколько сильно»? Об этом мы еще поговорим. )
3. Придумать, какие действия нужно совершить, чтобы риск не наступил. Можем ли мы сделать так, чтобы негативное событие не произошло или произошло, но не повлияло на нас? Или повлияло, но незначительно?
4. Придумать, какие действия нужно совершить, если риск материализуется и станет проблемой. Что мы будем делать, если негативное событие произошло? Кому звонить, куда бежать?
Достаточно ли вышеописанного? Нет. Риски не статичны. Они то появляются, то исчезают. Их параметры могут меняться со временем. Если риск замерзнуть в январе весьма высок, то в июле он явно ниже. Зато в июле можно объесться незрелыми сливами, а в январе – вряд ли. Поэтому управление рисками – процесс непрерывный.
И к нашим этапам управления добавляется еще один:
5. Регулярно следить, не появились ли новые риски, и так же регулярно просматривать список старых рисков, не изменились ли их параметры?
(продолжение следует)
Момент, когда риск материлиализуется и превращается в проблему, называют событием риска. Как же узнать, в какой момент риск стал проблемой? Вот смотрите, еще секунду назад мы ехали с ветерком по прекрасной федеральной трассе. И вдруг – пшшшш... Шина-то проколота. Конечно, из кабины машины не видно, как огромный ржавый гвоздь входит в правое переднее колесо. Событие риска произошло, но мы его не видим. Зато машина вильнула в сторону, она уже едет как-то не так, и мы слышали странный хлопок. Т.е. мы узнали о том, что событие риска произошло, по некоторым признакам, симптомам, которые называются индикаторами риска. Именно отслеживание этих индикаторов – одна из основных задач при управлении рисками.
На самом-то деле управлением рисками мы занимаемся в нашей жизни каждый день, даже не задумываясь об этом. Вот представьте, просыпаетесь вы – а за окном зима. Вы думаете: «Ага, холодно стало. Не замерзнуть бы по пути на работу. А то замерзну, заболею, буду кашлять, не смогу пойти на свидание в пятницу. А хочется. Что же делать? Надену-ка я шарф потеплее и ботинки вместо кроссовок... А вдруг все таки замерзну? Ну, тогда зайду в кафе по дороге, выпью горячего кофе.» Все эти мысли пролетают в вашей голове мгновенно, вы их на уровне сознания даже не фиксируете. И так – во многих делах. Управление рисками на уровне подсознания – естественное и необходимое условие нашего выживания.
Если же вывести этот процесс на сознательный уровень и формализовать, то получится, что управление рисками состоит из нескольких универсальных этапов:
1. Выявить риски. Мы определяем как можно больше негативных событий, которые могут на нас повлиять. На этом этапе для каждого найденного риска также нужно выявить индикаторы возникновения. «Ого, а за окном-то зима! Значит, существует риск замерзнуть!» Каковы индикаторы этого риска? Например, уши покалывает и вы их «не чувствуете». Как получили такой индикатор – все, замерзли.
2. Оценить степень воздействия риска. Как известно, в бизнесе существует только то, что можно измерить количественно. Поэтому для каждого найденного риска необходимо ответить на два вопроса:
2.a «Насколько возможно возникновение этого риска?» и
2.b «Насколько сильно будет его влияние?».
Как правильно ответить на эти вопросы, что значит «насколько возможно» и «насколько сильно»? Об этом мы еще поговорим. )
3. Придумать, какие действия нужно совершить, чтобы риск не наступил. Можем ли мы сделать так, чтобы негативное событие не произошло или произошло, но не повлияло на нас? Или повлияло, но незначительно?
4. Придумать, какие действия нужно совершить, если риск материализуется и станет проблемой. Что мы будем делать, если негативное событие произошло? Кому звонить, куда бежать?
Достаточно ли вышеописанного? Нет. Риски не статичны. Они то появляются, то исчезают. Их параметры могут меняться со временем. Если риск замерзнуть в январе весьма высок, то в июле он явно ниже. Зато в июле можно объесться незрелыми сливами, а в январе – вряд ли. Поэтому управление рисками – процесс непрерывный.
И к нашим этапам управления добавляется еще один:
5. Регулярно следить, не появились ли новые риски, и так же регулярно просматривать список старых рисков, не изменились ли их параметры?
(продолжение следует)
🌪 Как управлять рисками в проектах. Часть 2.
Почему вообще менеджеры проектов занимаются управлением рисками? К этому очень располагает сама природа проекта. Напомню, что проект – это совместная работа группы людей для получения уникального результата за ограниченное время и деньги. Группа людей (проектная команда) тоже временная. Там, где есть люди, ограничения денег и времени, стремление получить ранее не существовавший результат и т.д., возникает огромное число неопределенностей. И на пути к результату проекта этих неопределенностей еще больше. А вдруг мы не успеем сделать эту задачу к 16 декабря? А вдруг Вася, наш самый опытный сотрудник, внезапно уволится? А вдруг большие боссы нам не дадут денег на последний этап проекта? В общем, проект – отличная среда для управления рисками.
Вернемся теперь к нашему алгоритму управления рисками и рассмотрим этапы детально. На первом этапе мы должны выявить риски. Но откуда их взять? Если речь идет о несложных, «бытовых» задачах, скажем, подготовке к автомобильному путешествию в Красноярск, то тут все более-менее понятно, для выявления рисков нужен водительский опыт и здравый смысл. Хорошо также, если мы управляем проектом в знакомой нам сфере – там тоже ясно с какими проблемами мы можем столкнуться. А что делать, если нам поручили рулить проектом в совершенно незнакомой области? К счастью, у этой задачи есть решение – поиск следует начинать с анализа возможных источников рисков.
Оказывается, если выписать риски проекта (просто написать все, что придет в голову), то все они группируются по следующим категориям:
Люди (болезни, увольнения, саботаж и прочие проявления человеческого фактора).
Технологии (риски, связанные с ИТ-системами, оборудованием, технологическими подходами).
Бизнес-процессы (все организационные и процессные риски).
Организации (риски, которые порождают компании-клиенты и конкуренты, поставщики, подрядчики).
Государство и законодательство (регуляторы, проверки, изменения законов).
Природные явления (природные катастрофы, особенно те, у которых красивые женские имена).
Этот список не догма. Если вам хочется выделить большее число категорий или вы нашли крупную категорию, важную для вашего проекта, но которую я не указал, смело добавляйте в список источников рисков.
Вы заметили, в чем проблема? Мы понимаем откуда брать риски, но список источников очень общий. Поэтому следующий шаг – его детализация.
Во-первых, проектные риски удобнее делить на внешние и внутренние. Первый тип рисков порождается внешними по отношению к проекту причинами. Их следует искать в окружении проекта – в поставщиках и подрядчиках, государстве, клиентах. Второй тип рисков, угрожает проекту изнутри. К внутренним рискам относятся все потенциальные проблемы вашей организации, в проектной команде, в используемых вами технологиях, бюрократии.
Во-вторых, есть смысл детализировать каждый из перечисленных источников. Возьмем, к примеру, категорию «Люди». Кто у нас источник неприятностей внутри проекта? Проектная команда, управляющий комитет (можно и нужно поименно!) и спонсор. Кто может доставить беспокойство снаружи? В результате получим список с ФИО всех потенциальных злодеев.
Это упражнение следует проделать для каждого выделенного нами источника рисков, на выходе получится требуемая карта.
Может сложиться впечатление, что систематизация источников рисков трудная и будет отнимать много времени. Это не так. Трудно будет только с самым первым проектом. Во втором вы уже будет просто просматривать источники и добавлять новые или удалять лишние. В одной организации источники рисков от проекта проекту меняются не сильно. Сделав пару проектов, вы получите отличный шаблон для последующих.
Важно: анализ источников рисков нужен, чтобы риски выявить. Не страшно, если вы припишете технологический риск источнику «Природные явления». Гораздо хуже, если вы забудете про какие-то риски и не будете к ним готовы.
Обратите внимание – мы пока до самих рисков даже не добрались, мы получили только их источники.
Почему вообще менеджеры проектов занимаются управлением рисками? К этому очень располагает сама природа проекта. Напомню, что проект – это совместная работа группы людей для получения уникального результата за ограниченное время и деньги. Группа людей (проектная команда) тоже временная. Там, где есть люди, ограничения денег и времени, стремление получить ранее не существовавший результат и т.д., возникает огромное число неопределенностей. И на пути к результату проекта этих неопределенностей еще больше. А вдруг мы не успеем сделать эту задачу к 16 декабря? А вдруг Вася, наш самый опытный сотрудник, внезапно уволится? А вдруг большие боссы нам не дадут денег на последний этап проекта? В общем, проект – отличная среда для управления рисками.
Вернемся теперь к нашему алгоритму управления рисками и рассмотрим этапы детально. На первом этапе мы должны выявить риски. Но откуда их взять? Если речь идет о несложных, «бытовых» задачах, скажем, подготовке к автомобильному путешествию в Красноярск, то тут все более-менее понятно, для выявления рисков нужен водительский опыт и здравый смысл. Хорошо также, если мы управляем проектом в знакомой нам сфере – там тоже ясно с какими проблемами мы можем столкнуться. А что делать, если нам поручили рулить проектом в совершенно незнакомой области? К счастью, у этой задачи есть решение – поиск следует начинать с анализа возможных источников рисков.
Оказывается, если выписать риски проекта (просто написать все, что придет в голову), то все они группируются по следующим категориям:
Люди (болезни, увольнения, саботаж и прочие проявления человеческого фактора).
Технологии (риски, связанные с ИТ-системами, оборудованием, технологическими подходами).
Бизнес-процессы (все организационные и процессные риски).
Организации (риски, которые порождают компании-клиенты и конкуренты, поставщики, подрядчики).
Государство и законодательство (регуляторы, проверки, изменения законов).
Природные явления (природные катастрофы, особенно те, у которых красивые женские имена).
Этот список не догма. Если вам хочется выделить большее число категорий или вы нашли крупную категорию, важную для вашего проекта, но которую я не указал, смело добавляйте в список источников рисков.
Вы заметили, в чем проблема? Мы понимаем откуда брать риски, но список источников очень общий. Поэтому следующий шаг – его детализация.
Во-первых, проектные риски удобнее делить на внешние и внутренние. Первый тип рисков порождается внешними по отношению к проекту причинами. Их следует искать в окружении проекта – в поставщиках и подрядчиках, государстве, клиентах. Второй тип рисков, угрожает проекту изнутри. К внутренним рискам относятся все потенциальные проблемы вашей организации, в проектной команде, в используемых вами технологиях, бюрократии.
Во-вторых, есть смысл детализировать каждый из перечисленных источников. Возьмем, к примеру, категорию «Люди». Кто у нас источник неприятностей внутри проекта? Проектная команда, управляющий комитет (можно и нужно поименно!) и спонсор. Кто может доставить беспокойство снаружи? В результате получим список с ФИО всех потенциальных злодеев.
Это упражнение следует проделать для каждого выделенного нами источника рисков, на выходе получится требуемая карта.
Может сложиться впечатление, что систематизация источников рисков трудная и будет отнимать много времени. Это не так. Трудно будет только с самым первым проектом. Во втором вы уже будет просто просматривать источники и добавлять новые или удалять лишние. В одной организации источники рисков от проекта проекту меняются не сильно. Сделав пару проектов, вы получите отличный шаблон для последующих.
Важно: анализ источников рисков нужен, чтобы риски выявить. Не страшно, если вы припишете технологический риск источнику «Природные явления». Гораздо хуже, если вы забудете про какие-то риски и не будете к ним готовы.
Обратите внимание – мы пока до самих рисков даже не добрались, мы получили только их источники.
Вспомним теперь, что мы рассматриваем только проектные риски. На каких столпах стоит все управление проектами, чем рулит менеджер? Качеством проекта, его содержанием, сроками и стоимостью. Поэтому все риски стоит рассматривать именно как угрозу этим параметрам.
Как это выглядит на практике? Берем источник риска, например, «Люди». Для каждого человека определяем, как он может негативно повлиять на проект, какое его действие (бездействие) снизит качество, задержит сроки сдачи, увеличит стоимость. Тут главное не переборщить – не надо совсем уж в детали погружаться, лучше начать с самого очевидного.
Повторяем это упражнение для всех источников. В этот момент вы поймете, достаточно ли подробно вы проработали их карту.
Вы ведь чувствуете, что чего-то не хватает? ) Правильно чувствуете. Ведь если делать список рисков проекта только на основе источников, этот процесс никогда не закончится. Но тут нам на помощь придет самый главный проектный документ – план-график проекта.
Именно план, в котором перечислены задачи, сроки, люди – главный генератор рисков, ограничитель и связующее звено в иерархии рисков, полученных из разных источников.
Начинающие менеджеры рисуют красивый список рисков, продумывают, как ими управлять, а план у них живет параллельной жизнью. При этом часть рисков, полученных из иерархии источников, совпадает с рисками, генерируемыми планом, но этого никто не замечает. А ведь каждая (!) задача в плане – гарантированный риск с точки зрения сроков, стоимости, качества, людей и ресурсов. Нет ли здесь противоречия с тем, что мы говорили в прошлый раз –запланированная задача не риск, она гарантированно случится? Противоречия нет, все в порядке. Сама по себе, конечно, задача случится, но ее сроки, стоимость и качество – большая неопределенность. Именно потому и важно использовать план – в нем перечислены события, которые гарантированно произойдут, и которых нет в иерархии источников рисков.
Также надо заметить, что, помимо плана, в качестве источника риска нужно рассматривать любой проектный документ (вдруг вы забыли что-то перенести в план).
А что делать с рисками, о которых мы даже не догадались? Все проверили: и план, и источники, а вдруг есть что-то, о чем мы совсем забыли? Об этом позже.)
Итоги сегодняшнего рассказа. Для поиска рисков нужно проанализировать проект снаружи и изнутри. Чтобы риски было легче искать, нужно воспользоваться иерархической структурой источников рисков. Риски у нас проектные, они затрагивают стоимость, сроки и качество. Для поиска рисков правильно использовать план проекта и иерархию источников.
Теперь понятно, где искать риски и что это за риски. А как их искать и в каком виде результат поиска должен быть представлен? И дальше-то что делать?
(продолжение следует)
Как это выглядит на практике? Берем источник риска, например, «Люди». Для каждого человека определяем, как он может негативно повлиять на проект, какое его действие (бездействие) снизит качество, задержит сроки сдачи, увеличит стоимость. Тут главное не переборщить – не надо совсем уж в детали погружаться, лучше начать с самого очевидного.
Повторяем это упражнение для всех источников. В этот момент вы поймете, достаточно ли подробно вы проработали их карту.
Вы ведь чувствуете, что чего-то не хватает? ) Правильно чувствуете. Ведь если делать список рисков проекта только на основе источников, этот процесс никогда не закончится. Но тут нам на помощь придет самый главный проектный документ – план-график проекта.
Именно план, в котором перечислены задачи, сроки, люди – главный генератор рисков, ограничитель и связующее звено в иерархии рисков, полученных из разных источников.
Начинающие менеджеры рисуют красивый список рисков, продумывают, как ими управлять, а план у них живет параллельной жизнью. При этом часть рисков, полученных из иерархии источников, совпадает с рисками, генерируемыми планом, но этого никто не замечает. А ведь каждая (!) задача в плане – гарантированный риск с точки зрения сроков, стоимости, качества, людей и ресурсов. Нет ли здесь противоречия с тем, что мы говорили в прошлый раз –запланированная задача не риск, она гарантированно случится? Противоречия нет, все в порядке. Сама по себе, конечно, задача случится, но ее сроки, стоимость и качество – большая неопределенность. Именно потому и важно использовать план – в нем перечислены события, которые гарантированно произойдут, и которых нет в иерархии источников рисков.
Также надо заметить, что, помимо плана, в качестве источника риска нужно рассматривать любой проектный документ (вдруг вы забыли что-то перенести в план).
А что делать с рисками, о которых мы даже не догадались? Все проверили: и план, и источники, а вдруг есть что-то, о чем мы совсем забыли? Об этом позже.)
Итоги сегодняшнего рассказа. Для поиска рисков нужно проанализировать проект снаружи и изнутри. Чтобы риски было легче искать, нужно воспользоваться иерархической структурой источников рисков. Риски у нас проектные, они затрагивают стоимость, сроки и качество. Для поиска рисков правильно использовать план проекта и иерархию источников.
Теперь понятно, где искать риски и что это за риски. А как их искать и в каком виде результат поиска должен быть представлен? И дальше-то что делать?
(продолжение следует)
🌪 Лирическое отступление
Стал писать про риски - стал получать кучу писем с вопросами.)
Может показаться, что для определенной категории проектов какие-то риски нехарактерны в принципе. Например, риски, связанные с природными явлениями, для проектов разработки софта.
Я тоже так думал, пока в 2005 году наша команда, ключевые разработчики которой жили в Штатах, не столкнулась с последствиями урагана Катрина. Догадайтесь, в каком городе жили эти разработчики. Правильно, в Новом Орлеане. Поэтому в 2012 году наша (уже другая) команда последствий урагана Сэнди даже не заметила, не считая пары дней простоя.
Люди хорошо учатся на своих ошибках. Хотя лучше учиться на чужих.
Учет природных рисков очень важен не только для американских команд, но и для огромной армии современных стартаперов - любителей жить в теплых азиатских странах, где к ураганам добавляются землетрясения и цунами.
Управление рисками - управление проектами по-взрослому. Берегите свои проекты и себя.
Стал писать про риски - стал получать кучу писем с вопросами.)
Может показаться, что для определенной категории проектов какие-то риски нехарактерны в принципе. Например, риски, связанные с природными явлениями, для проектов разработки софта.
Я тоже так думал, пока в 2005 году наша команда, ключевые разработчики которой жили в Штатах, не столкнулась с последствиями урагана Катрина. Догадайтесь, в каком городе жили эти разработчики. Правильно, в Новом Орлеане. Поэтому в 2012 году наша (уже другая) команда последствий урагана Сэнди даже не заметила, не считая пары дней простоя.
Люди хорошо учатся на своих ошибках. Хотя лучше учиться на чужих.
Учет природных рисков очень важен не только для американских команд, но и для огромной армии современных стартаперов - любителей жить в теплых азиатских странах, где к ураганам добавляются землетрясения и цунами.
Управление рисками - управление проектами по-взрослому. Берегите свои проекты и себя.
🌦 Как управлять рисками в проектах. Часть 3.
В управлении рисками важна регулярность. Надо не реже раза в неделю проводить:
Поиск рисков командой проекта.
Поиск новых рисков в плане проекта.
Поиск в реестре источников рисков.
Опрос экспертов.
Напомню, что еще в первой части моего рассказа мы хотели оценить степень воздействия риска на проект. Для каждого найденного риска ответим на два вопроса:
«Насколько возможно возникновение риска?»
и
«Сильно ли риск повлияет на проект?»
Что значит «насколько возможно»? Внутренняя шкала для ранжирования вида неопределенности у каждого человека своя. Но зависит она, в основном, от его видения проекта. Предположим, мы планируем проект автопутешествия к морю и выявили два риска: «Автомобиль сломается в дороге» и «Нас оштрафуют за превышение скорости». Как рассматривал бы возможность материализации этих рисков молодой водитель на новом джипе? Про первый риск он сказал бы: «Вряд ли это произойдет! У меня новая отличная машина, я в ней уверен». Про второй он сказал бы: «Да, это очень возможно! Дорога незнакомая, я люблю быструю езду. Наверняка попадусь!» А как оценил бы эти риски человек пенсионного возраста на стареньком отечественном автомобиле? На первый вопрос он ответил бы: «Очень возможно, машина старая, бывает, подводит. А уж на таком расстоянии...» А про второй сказал бы: «Вряд ли, я езжу медленно, годы не те».
Так и в реальных проектах – возможность проявления риска сильно зависит от проекта. Поэтому сложно придумать универсальный алгоритм для оценивания возможности возникновения риска. Но существует простой способ: а давайте разделим все риски по возможности возникновения на 4 группы:
A. Незначительная возможность возникновения.
B. Низкая возможность возникновения.
C. Средняя возможность возникновения.
D. Высокая возможность возникновения.
Я специально избегаю терминов из теории вероятностей, ну ее, не в ней дело.
Ну а дальше вы просто смотрите внимательно на каждый риск и приписываете ему возможность возникновения по этой шкале. Почему градаций четыре, а не сто четыре? Да пожалуйста, если ваш инструментарий позволяет ранжировать возможность возникновения риска с такой точностью, вы молодец. Почему градаций не три? Тоже понятно – такое ранжирование превратится в фарс, вы будете всем рискам приписывать среднюю возможность возникновения, и управлять рисками не получится. Так что больше четырех можно, меньше – нет.
Разбираемся со вторым вопросом: «Сильно ли риск повлияет на проект?» Логика такая же: что русскому хорошо, то немцу – смерть. На один проект риск повлияет очень сильно, на другой – очень слабо. В нашем примере про автопутешествие, риск поломки какого-то узла на джипе может оказаться фатальным для машины, а владелец отечественного автомобиля прикрутит эту хреновину проволокой и еще пятьсот километров проедет.
По аналогии, воздействие риска на проект (точнее, последствия этого воздействия) будем тоже описывать четырьмя состояниями:
A. Незначительные последствия.
B. Средние последствия.
C. Значимые последствия.
D. Критические последствия.
С этими параметрами поступаем так же, как с предыдущими: приписываем каждому риску одно из четырех значений.
Там четыре параметра, тут четыре параметра – пора их связать и построить таблицу. Эта таблица называется матрицей рисков, любой менеджер проектов ее может представить с закрытыми глазами.
Она помогает нам ранжировать риски в проекте: каждой возможности возникновения соответствует своя степень воздействия на проект. Например, пара «Незначительная возможность возникновения» – «Незначительные последствия». Нужно ли нам беспокоиться о риске с такими параметрами? Нет, пока не стоит. Это почти невозможное событие, да еще и на нас не влияющее. Назовем это «низким риском». А если риск описывается парой «Средняя возможность возникновения» – «Средние последствия»? Тут уже надо беспокоиться и думать, что делать с этим риском. Такие риски назовем «средними». Так же выделим «высокие риски» и «критические риски».
А можно ли было нарисовать ее иначе? Например, поставить ячейке «Средняя возможность возникновения» – «Средние последств
В управлении рисками важна регулярность. Надо не реже раза в неделю проводить:
Поиск рисков командой проекта.
Поиск новых рисков в плане проекта.
Поиск в реестре источников рисков.
Опрос экспертов.
Напомню, что еще в первой части моего рассказа мы хотели оценить степень воздействия риска на проект. Для каждого найденного риска ответим на два вопроса:
«Насколько возможно возникновение риска?»
и
«Сильно ли риск повлияет на проект?»
Что значит «насколько возможно»? Внутренняя шкала для ранжирования вида неопределенности у каждого человека своя. Но зависит она, в основном, от его видения проекта. Предположим, мы планируем проект автопутешествия к морю и выявили два риска: «Автомобиль сломается в дороге» и «Нас оштрафуют за превышение скорости». Как рассматривал бы возможность материализации этих рисков молодой водитель на новом джипе? Про первый риск он сказал бы: «Вряд ли это произойдет! У меня новая отличная машина, я в ней уверен». Про второй он сказал бы: «Да, это очень возможно! Дорога незнакомая, я люблю быструю езду. Наверняка попадусь!» А как оценил бы эти риски человек пенсионного возраста на стареньком отечественном автомобиле? На первый вопрос он ответил бы: «Очень возможно, машина старая, бывает, подводит. А уж на таком расстоянии...» А про второй сказал бы: «Вряд ли, я езжу медленно, годы не те».
Так и в реальных проектах – возможность проявления риска сильно зависит от проекта. Поэтому сложно придумать универсальный алгоритм для оценивания возможности возникновения риска. Но существует простой способ: а давайте разделим все риски по возможности возникновения на 4 группы:
A. Незначительная возможность возникновения.
B. Низкая возможность возникновения.
C. Средняя возможность возникновения.
D. Высокая возможность возникновения.
Я специально избегаю терминов из теории вероятностей, ну ее, не в ней дело.
Ну а дальше вы просто смотрите внимательно на каждый риск и приписываете ему возможность возникновения по этой шкале. Почему градаций четыре, а не сто четыре? Да пожалуйста, если ваш инструментарий позволяет ранжировать возможность возникновения риска с такой точностью, вы молодец. Почему градаций не три? Тоже понятно – такое ранжирование превратится в фарс, вы будете всем рискам приписывать среднюю возможность возникновения, и управлять рисками не получится. Так что больше четырех можно, меньше – нет.
Разбираемся со вторым вопросом: «Сильно ли риск повлияет на проект?» Логика такая же: что русскому хорошо, то немцу – смерть. На один проект риск повлияет очень сильно, на другой – очень слабо. В нашем примере про автопутешествие, риск поломки какого-то узла на джипе может оказаться фатальным для машины, а владелец отечественного автомобиля прикрутит эту хреновину проволокой и еще пятьсот километров проедет.
По аналогии, воздействие риска на проект (точнее, последствия этого воздействия) будем тоже описывать четырьмя состояниями:
A. Незначительные последствия.
B. Средние последствия.
C. Значимые последствия.
D. Критические последствия.
С этими параметрами поступаем так же, как с предыдущими: приписываем каждому риску одно из четырех значений.
Там четыре параметра, тут четыре параметра – пора их связать и построить таблицу. Эта таблица называется матрицей рисков, любой менеджер проектов ее может представить с закрытыми глазами.
Она помогает нам ранжировать риски в проекте: каждой возможности возникновения соответствует своя степень воздействия на проект. Например, пара «Незначительная возможность возникновения» – «Незначительные последствия». Нужно ли нам беспокоиться о риске с такими параметрами? Нет, пока не стоит. Это почти невозможное событие, да еще и на нас не влияющее. Назовем это «низким риском». А если риск описывается парой «Средняя возможность возникновения» – «Средние последствия»? Тут уже надо беспокоиться и думать, что делать с этим риском. Такие риски назовем «средними». Так же выделим «высокие риски» и «критические риски».
А можно ли было нарисовать ее иначе? Например, поставить ячейке «Средняя возможность возникновения» – «Средние последств
ия» значение "низкий риск"? Конечно. Все зависит от проекта, и только вы определяете, как ранжировать риски.
Интуитивно понятно, что в красную зону этой матрицы попали риски, с которыми надо что-то делать. А в зеленую – пока можно подождать.
Ну а теперь мы сможем определить для каждого ранга свою стратегию управления.
(продолжение следует)
Интуитивно понятно, что в красную зону этой матрицы попали риски, с которыми надо что-то делать. А в зеленую – пока можно подождать.
Ну а теперь мы сможем определить для каждого ранга свою стратегию управления.
(продолжение следует)
☄ Как управлять рисками в проектах. Часть 4.
Существует четыре стратегии реагирования на риск:
Мы можем риск принять.
Мы можем от него уклониться.
Мы можем его передать другому.
Мы можем снизить его влияние.
Принятие риска означает, что мы осведомлены о нем, но просто не знаем, что с ним делать, или не хотим ничего делать. Принимая риск, мы не меняем ни план проекта, ни команду, ни иные проектные параметры.
Какие же риски принимать? Во-первых, вызванные действиями непреодолимой силы – мы ничего не можем с ними сделать. Во-вторых, риски с низким рангом – мы ничего не хотим с ними делать. В-третьих, мы должны все риски, о которых ничего не знаем. Неизвестное можно только принять.
Принимая риск, мы сохраняем его в проекте. Все гадости, которые этому риску сопутствуют, по-прежнему висят над нами и готовы нас порадовать.
Принятие не означает «махнуть рукой на проблему и сложить лапки». Это не фатализм, это осознанное решение ничего не делать. Принимая риск, необходимо увеличивать бюджет проекта – резервные средства помогут нам пережить последствия риска. Риски стоит принимать, если все остальные стратегии применить не получилось. Сначала попробуйте от него уклониться.
Уклонение от риска предполагает, что мы перестроим работу так, чтобы исключить риск из нашего проекта. Как мы можем уклониться от риска «Дорожные условия в автомобильной поездке ухудшатся из-за дождя»? Да просто: мы никуда не поедем. Или поедем, но не в Красноярск, а в Ташкент, там осенью с погодой получше. Можно ли считать это уклонением? Нет, это жульничество! Ведь мы изменили цели проекта! Теперь у нас уже новый проект, с новыми целями и планом. Но если не менять цели, как уклоняться от риска? Один из способов – прояснить требования и, не затрагивая целей проекта, постараться сократить список задач, которые нужно сделать.
Что делать, если уклониться от риска нельзя? Можно попробовать передать его другому.
В отличие от принятия риска, когда мы можем резервировать собственные средства, при передаче риска мы используем заемные средства. С передачей риска знакомы все, кто оформлял страховку на автомобиль. Любой страховой продукт – передача риска.
В проектах риск передается, например, привлечением вендора по модели fixed price. Как только мы заключили с вендором контракт, все риски за проект должен нести он.)
Конечно, так не бывает. Вендором можно прикрыться, если дойдет до разборок на высшем уровне, но на нашем уровне вендор сам источник рисков.)
Передача риска отлично работает в финансовой сфере, но плохо – в управлении проектами.
А что делать, если ни одна из описанных стратегий не подошла? Остается последний вариант – снизить влияние риска.
Снижение влияния риска – это понижение его ранга. Посмотрите на матрицу рисков – ранг зависит от возможности возникновения и от последствий воздействия риска на проект. Уменьшая один из этих параметров, мы понижаем ранг риска.
Статистика показывает, что управленцы обычно работают с последствиями, начинают придумывать, как их уменьшить. Это понятно – последствия можно потрогать, выразить в деньгах, товарах, синяках. С возможностью возникновения хуже, потому что за пределами моего рассказа ее называют вероятностью, и обращаться с ней умеют только выпускники мехмата, и то не все.
Вернемся к проекту про автомобильную поездку и рассмотрим риск «Можно проколоть шину». Как нам снизить влияние риска? Можно уменьшить последствия – взять запасное колесо. Тогда на трассе мы его поменяем, и, хотя риск воздействует на проект (мы же потратили 15 минут и испачкали руки), влияние незначительно. А можно снизить возможность возникновения – выбрать дорогу с лучшим покрытием или колеса повышенной прочности.
Итак, для каждого риска в проекте нужно выбрать стратегию реагирования: принятие, уклонение, передачу или снижение ранга.
(продолжение следует)
Существует четыре стратегии реагирования на риск:
Мы можем риск принять.
Мы можем от него уклониться.
Мы можем его передать другому.
Мы можем снизить его влияние.
Принятие риска означает, что мы осведомлены о нем, но просто не знаем, что с ним делать, или не хотим ничего делать. Принимая риск, мы не меняем ни план проекта, ни команду, ни иные проектные параметры.
Какие же риски принимать? Во-первых, вызванные действиями непреодолимой силы – мы ничего не можем с ними сделать. Во-вторых, риски с низким рангом – мы ничего не хотим с ними делать. В-третьих, мы должны все риски, о которых ничего не знаем. Неизвестное можно только принять.
Принимая риск, мы сохраняем его в проекте. Все гадости, которые этому риску сопутствуют, по-прежнему висят над нами и готовы нас порадовать.
Принятие не означает «махнуть рукой на проблему и сложить лапки». Это не фатализм, это осознанное решение ничего не делать. Принимая риск, необходимо увеличивать бюджет проекта – резервные средства помогут нам пережить последствия риска. Риски стоит принимать, если все остальные стратегии применить не получилось. Сначала попробуйте от него уклониться.
Уклонение от риска предполагает, что мы перестроим работу так, чтобы исключить риск из нашего проекта. Как мы можем уклониться от риска «Дорожные условия в автомобильной поездке ухудшатся из-за дождя»? Да просто: мы никуда не поедем. Или поедем, но не в Красноярск, а в Ташкент, там осенью с погодой получше. Можно ли считать это уклонением? Нет, это жульничество! Ведь мы изменили цели проекта! Теперь у нас уже новый проект, с новыми целями и планом. Но если не менять цели, как уклоняться от риска? Один из способов – прояснить требования и, не затрагивая целей проекта, постараться сократить список задач, которые нужно сделать.
Что делать, если уклониться от риска нельзя? Можно попробовать передать его другому.
В отличие от принятия риска, когда мы можем резервировать собственные средства, при передаче риска мы используем заемные средства. С передачей риска знакомы все, кто оформлял страховку на автомобиль. Любой страховой продукт – передача риска.
В проектах риск передается, например, привлечением вендора по модели fixed price. Как только мы заключили с вендором контракт, все риски за проект должен нести он.)
Конечно, так не бывает. Вендором можно прикрыться, если дойдет до разборок на высшем уровне, но на нашем уровне вендор сам источник рисков.)
Передача риска отлично работает в финансовой сфере, но плохо – в управлении проектами.
А что делать, если ни одна из описанных стратегий не подошла? Остается последний вариант – снизить влияние риска.
Снижение влияния риска – это понижение его ранга. Посмотрите на матрицу рисков – ранг зависит от возможности возникновения и от последствий воздействия риска на проект. Уменьшая один из этих параметров, мы понижаем ранг риска.
Статистика показывает, что управленцы обычно работают с последствиями, начинают придумывать, как их уменьшить. Это понятно – последствия можно потрогать, выразить в деньгах, товарах, синяках. С возможностью возникновения хуже, потому что за пределами моего рассказа ее называют вероятностью, и обращаться с ней умеют только выпускники мехмата, и то не все.
Вернемся к проекту про автомобильную поездку и рассмотрим риск «Можно проколоть шину». Как нам снизить влияние риска? Можно уменьшить последствия – взять запасное колесо. Тогда на трассе мы его поменяем, и, хотя риск воздействует на проект (мы же потратили 15 минут и испачкали руки), влияние незначительно. А можно снизить возможность возникновения – выбрать дорогу с лучшим покрытием или колеса повышенной прочности.
Итак, для каждого риска в проекте нужно выбрать стратегию реагирования: принятие, уклонение, передачу или снижение ранга.
(продолжение следует)
⛷ Как стратегия уклонения от риска работает в реальности
Был у меня однажды проект – мы создавали в банке сеть платежных терминалов. Первоначальные планы были грандиозными: платежный терминал, в котором можно и счет мобильного телефона пополнить, и за квартиру заплатить, и за интернет, и взнос по кредиту сделать. А сроки внедрения были очень короткими, не больше полутора месяцев.
Налицо серьезный риск: задержка проекта из-за того, что надо подружить терминал, процессинг и внутренние финансовые системы банка. Интеграция, да еще с участием нескольких компаний, – это долго.
Мы проанализировали ситуацию и поняли, что основная цель проекта не в том, чтобы дать клиенту много функций, а разгрузке касс. Клиенты пришли сделать взнос по кредиту, сотрудники отделения перегружены, не могут выполнять другие функции. Падают продажи, а люди стоят в очереди.
А значит долой телефоны и квартплату, оставляем только функцию погашения кредита. Тогда можно связать терминал с банковскими системами без участия процессинга. Нет интеграционной задачи – сроки сокращаются.
Так избавляются от лишнего и сосредотачиваются на главном, не меняя цели проекта.
Был у меня однажды проект – мы создавали в банке сеть платежных терминалов. Первоначальные планы были грандиозными: платежный терминал, в котором можно и счет мобильного телефона пополнить, и за квартиру заплатить, и за интернет, и взнос по кредиту сделать. А сроки внедрения были очень короткими, не больше полутора месяцев.
Налицо серьезный риск: задержка проекта из-за того, что надо подружить терминал, процессинг и внутренние финансовые системы банка. Интеграция, да еще с участием нескольких компаний, – это долго.
Мы проанализировали ситуацию и поняли, что основная цель проекта не в том, чтобы дать клиенту много функций, а разгрузке касс. Клиенты пришли сделать взнос по кредиту, сотрудники отделения перегружены, не могут выполнять другие функции. Падают продажи, а люди стоят в очереди.
А значит долой телефоны и квартплату, оставляем только функцию погашения кредита. Тогда можно связать терминал с банковскими системами без участия процессинга. Нет интеграционной задачи – сроки сокращаются.
Так избавляются от лишнего и сосредотачиваются на главном, не меняя цели проекта.
⚡️Как управлять рисками в проектах. Часть 5.
Оценок, о которых мы говорили в прошлый раз, для управления рисками может быть недостаточно. Иногда риски нужно в чем-то измерять, и чаще всего для этого используют денежные единицы. Помимо простоты и универсальности, к этому располагает и сама природа риска , ведь он может повлиять на прибыльность проекта и всей компании. Кроме того, все три существенные характеристики проекта (бюджет, сроки и качество) легко выражаются в деньгах.
Для устрашения начальства иногда полезно показать, сколько компания потеряет, не выполнив ту или иную задачу, а начальство реагирует на деньги, как сеттер на утку, так что своей цели вы достигнете.
Конечно, не всегда легко понять «денежные последствия» от невыполнения запланированной задачи. В таких случаях имеет смысл подняться на один уровень в иерархии задач проекта и оценить в деньгах более крупную задачу, в состав которой входит труднооцениваемая.
Заменяет ли оценка рисков в деньгах оценки по матрице рисков ? Нет, но дополняет – начальство хорошо понимает язык денег. Менеджеру стоит подумать о представлении самых важных рисков именно в таком виде.
Если же речь идет о маленькой компании, где менеджер, по счастливой случайности, еще и основатель, и где берегут каждую копейку, то стоит подумать о представлении рисков в денежном формате.
Но есть еще один аспект управления рисками, связанный с деньгами.
Представьте, что вам понадобился кефир, и вы посылаете своего ребенка купить бутылочку (можете представить на месте ребенка любого близкого и любимого человека, да хотя бы и себя самого). Между вашим домом и магазином находится широкое шоссе, по которому непрерывно с огромной скоростью несутся машины. Есть риск: пострадать, переходя дорогу. Как им управлять?
Можно принять риск. В этом случае мы с замиранием сердца ждем свой кефир, считая, что все будет хорошо.
Можно уклониться от риска. Ну его, этот кефир, можно в молоко хлебушка накрошить, назавтра будет простокваша, по вкусу почти то же самое.
Можно передать риск, не обязательно ведь посылать в магазин своих родственников, можно попросить вредную соседку из первого подъезда.)
Мы можем снизить влияние риска. И это самый интересный вариант, ради него весь разговор и затевался. Как можно снизить влияние риска? Понизив ранг. Например, уменьшив возможность его возникновения. Для этого надо объяснить ребенку правила дорожного движения, научить его переходить дорогу только на зеленый сигнал светофора и только по «зебре», внимательно следя за окружающей обстановкой.
Но разве этого достаточно? Ведь речь идет о серьезной опасности, грозящей дорогому человеку! Что же еще можно сделать? Да многое!
Можно заказать частный вертолет, который перенесет его через опасную дорогу. Можно построить подземный переход или пешеходный мост, и поход за кефиром станет совершенно безопасным, машины туда не доберутся. Почему же никто так не делает? Потому что это очень дорого. Нам проще вообще отказаться от кефира, чем ради одной бутылки нести такие расходы на управление риском.
Ровно то же происходит и в реальной жизни – иногда проще отказаться от проекта, чем тратить огромные деньги на управление рисками.
Или, что бывает чаще, отказаться от управления рисками, раз это так дорого. ) Кстати, в нашем примере легко можно удорожить любую из стратегий. Можно ведь выбрать вместо соседки службу доставки магазина...
Итак, еще раз: рисками имеет смысл управлять до тех пор, пока предлагаемые стратегии не становятся слишком дорогими. В тот момент, когда риск требует привлечения больших средств, либо останавливаются на самом дешевом варианте выбранной стратегии, либо меняют ее на другую.
Оценок, о которых мы говорили в прошлый раз, для управления рисками может быть недостаточно. Иногда риски нужно в чем-то измерять, и чаще всего для этого используют денежные единицы. Помимо простоты и универсальности, к этому располагает и сама природа риска , ведь он может повлиять на прибыльность проекта и всей компании. Кроме того, все три существенные характеристики проекта (бюджет, сроки и качество) легко выражаются в деньгах.
Для устрашения начальства иногда полезно показать, сколько компания потеряет, не выполнив ту или иную задачу, а начальство реагирует на деньги, как сеттер на утку, так что своей цели вы достигнете.
Конечно, не всегда легко понять «денежные последствия» от невыполнения запланированной задачи. В таких случаях имеет смысл подняться на один уровень в иерархии задач проекта и оценить в деньгах более крупную задачу, в состав которой входит труднооцениваемая.
Заменяет ли оценка рисков в деньгах оценки по матрице рисков ? Нет, но дополняет – начальство хорошо понимает язык денег. Менеджеру стоит подумать о представлении самых важных рисков именно в таком виде.
Если же речь идет о маленькой компании, где менеджер, по счастливой случайности, еще и основатель, и где берегут каждую копейку, то стоит подумать о представлении рисков в денежном формате.
Но есть еще один аспект управления рисками, связанный с деньгами.
Представьте, что вам понадобился кефир, и вы посылаете своего ребенка купить бутылочку (можете представить на месте ребенка любого близкого и любимого человека, да хотя бы и себя самого). Между вашим домом и магазином находится широкое шоссе, по которому непрерывно с огромной скоростью несутся машины. Есть риск: пострадать, переходя дорогу. Как им управлять?
Можно принять риск. В этом случае мы с замиранием сердца ждем свой кефир, считая, что все будет хорошо.
Можно уклониться от риска. Ну его, этот кефир, можно в молоко хлебушка накрошить, назавтра будет простокваша, по вкусу почти то же самое.
Можно передать риск, не обязательно ведь посылать в магазин своих родственников, можно попросить вредную соседку из первого подъезда.)
Мы можем снизить влияние риска. И это самый интересный вариант, ради него весь разговор и затевался. Как можно снизить влияние риска? Понизив ранг. Например, уменьшив возможность его возникновения. Для этого надо объяснить ребенку правила дорожного движения, научить его переходить дорогу только на зеленый сигнал светофора и только по «зебре», внимательно следя за окружающей обстановкой.
Но разве этого достаточно? Ведь речь идет о серьезной опасности, грозящей дорогому человеку! Что же еще можно сделать? Да многое!
Можно заказать частный вертолет, который перенесет его через опасную дорогу. Можно построить подземный переход или пешеходный мост, и поход за кефиром станет совершенно безопасным, машины туда не доберутся. Почему же никто так не делает? Потому что это очень дорого. Нам проще вообще отказаться от кефира, чем ради одной бутылки нести такие расходы на управление риском.
Ровно то же происходит и в реальной жизни – иногда проще отказаться от проекта, чем тратить огромные деньги на управление рисками.
Или, что бывает чаще, отказаться от управления рисками, раз это так дорого. ) Кстати, в нашем примере легко можно удорожить любую из стратегий. Можно ведь выбрать вместо соседки службу доставки магазина...
Итак, еще раз: рисками имеет смысл управлять до тех пор, пока предлагаемые стратегии не становятся слишком дорогими. В тот момент, когда риск требует привлечения больших средств, либо останавливаются на самом дешевом варианте выбранной стратегии, либо меняют ее на другую.
📩 📩 О двойных продуктовых стандартах и супераппах
Вот интересно устроен продуктовый мир. Если известный банк вдруг начинает предлагать нам билеты в кино или бронирует столик в ресторане – это для всех ок. Если поисковая система сдает нам машины в аренду, подписывает на просмотр сериала или музыку – это ни у кого не вызывает недоумения. Если почтовый сервис вдруг доставляет нам еду или рекомендует, какую недвижимость купить, – это тоже воспринимается нормально.
Все это обсуждается по всем каналам и называется суперприложением. Лучшие продуктовые менеджеры и их команды день и ночь трудятся, чтобы только сделать еще одного доброго советчика и старательного помощника по расходованию наших честно заработанных. )
Но если вдруг несчастная Почта России осмелится выставить на продажу банку кильки в томатном соусе, модель пожарной машины и альбом с репродукциями Тропинина, а заодно поможет сделать седенькой старушке денежный переводик и предложит лотерейный билетик, то все встают в позу, кричат, что почта занимается не тем, и не так, и не с теми.
Откуда двойные стандарты, почему так несправедливо? ))
Вот интересно устроен продуктовый мир. Если известный банк вдруг начинает предлагать нам билеты в кино или бронирует столик в ресторане – это для всех ок. Если поисковая система сдает нам машины в аренду, подписывает на просмотр сериала или музыку – это ни у кого не вызывает недоумения. Если почтовый сервис вдруг доставляет нам еду или рекомендует, какую недвижимость купить, – это тоже воспринимается нормально.
Все это обсуждается по всем каналам и называется суперприложением. Лучшие продуктовые менеджеры и их команды день и ночь трудятся, чтобы только сделать еще одного доброго советчика и старательного помощника по расходованию наших честно заработанных. )
Но если вдруг несчастная Почта России осмелится выставить на продажу банку кильки в томатном соусе, модель пожарной машины и альбом с репродукциями Тропинина, а заодно поможет сделать седенькой старушке денежный переводик и предложит лотерейный билетик, то все встают в позу, кричат, что почта занимается не тем, и не так, и не с теми.
Откуда двойные стандарты, почему так несправедливо? ))
🚮 Без капчи
Обожаю, когда хорошо оплачиваемая продуктовая команда с неглупым менеджером во главе добавляет капчу на страницу регистрации пользователя. Нормальные люди так не делают. Нормальные люди о пользователе заботятся. Они знают, что вопросы отделения ботов от людей волнуют только их, а не пользователя.
Боишься ботов? Анализируй поведение посетителя, применяй интеллектуальные методы выявления роботов. Небось не с Терминатором бьешься. Можно сделать невидимое поле на форме – робот его заполнит, а человек нет. Профи знают еще миллион остроумных способов не погружать человека в капчевое болото.
Ну и отдельный шампур в аду приготовлен для любителей показать пользователю пятнадцать мутных фоток и попросить его «отметить изображения, содержащие автобус».
И эти люди потом еще смеют говорить что-то о UX.
Обожаю, когда хорошо оплачиваемая продуктовая команда с неглупым менеджером во главе добавляет капчу на страницу регистрации пользователя. Нормальные люди так не делают. Нормальные люди о пользователе заботятся. Они знают, что вопросы отделения ботов от людей волнуют только их, а не пользователя.
Боишься ботов? Анализируй поведение посетителя, применяй интеллектуальные методы выявления роботов. Небось не с Терминатором бьешься. Можно сделать невидимое поле на форме – робот его заполнит, а человек нет. Профи знают еще миллион остроумных способов не погружать человека в капчевое болото.
Ну и отдельный шампур в аду приготовлен для любителей показать пользователю пятнадцать мутных фоток и попросить его «отметить изображения, содержащие автобус».
И эти люди потом еще смеют говорить что-то о UX.
🚖 Яндекс.Такси: хищный оскал геймификации
С удивлением узнал, что у меня, пользователя Яндекс.Такси, теперь есть рейтинг. Следите за руками: Яндекс делает продукт -> я им пользуюсь за свои деньги -> Яндекс позволяет таксистам меня оценивать.
Перед выходными мой рейтинг был 4.82. Я-то, когда узнал о его существовании, ожидал твердую пятерку. ) Я считал, что меньше и быть не может – я всегда трезв, чист и вежлив. Я не любитель задушевных бесед с таксистами, но это уж, извините, мое право.
Кто же из водителей так мной недоволен? Тот, который поехал, не дождавшись, пока я обойду машину и сяду в нее? Или тот, кто так и не нашел меня, потому что «непонятно, где ты вообще стоишь»? Или тот, кто долго жаловался, что приходится всех возить за 350 рублей по пробкам, и не дождался дружеского сочувствия? Но это еще ладно. Сегодня мой рейтинг уже 4.74. Пять поездок в выходные, от 10 до 30 минут, в нескольких городах. Я-то о нововведении узнал до выходных, и сознательно проводил эксперимент «повысь свой рейтинг». Был еще приветливее, чем обычно, улыбался и оставлял чаевые. Не помогло. ))
Но ладно, то мои страдания. Но что будет с развитием продукта? До введения рейтингов пассажиры (напомню – это продукт для них, они за него платят) не придирались к водителям. Громко играет радио «Шансон»? Душно, не работает кондиционер? Не слишком чистый салон? Барахло в багажнике, некуда чемодан втиснуть? Пассажиры все равно ставили оценку выше, чем могли бы. У нас народ добрый, жалостливый.
А теперь пассажиры стали участником продуктовой геймификации. Только никто их об этом не предупредил и не рассказал правила игры. Это как если бы Овечкин проснулся с волейбольным мячом и в лыжах на теннисном корте – во что мы вообще играем-то?
Это Россия, ребята. Здесь эмоции побеждают логику уже много сотен лет. Водители будут мстить пассажирам, а пассажиры – водителям. Уровень терпимости к ошибкам теперь ниже нуля: «Ты меня не к тому подъезду вызвал!» «Да? А у тебя сиденье скрипучее и в салоне рыбой воняет!»
Продуктовые метрики Яндекса, построенные на таких сомнительных данных, будут гарантированно ошибочны. И по этим метрикам будут приниматься неверные решения о развитии продукта. А Яндекс – это компания, которая меняет мир, по крайней мере, в отдельно взятой стране. Да еще и почти монополист на нескольких рынках.
Как вы думаете, для чего будут использоваться рейтинги? Правильно, для определения стоимости поездки, что бы там ни писали маркетологи. Но это только начало. Потом ведь можно будет ввести эту практику для всех сервисов компании. А после и другие конторы подтянутся. Сейчас работодатели просматривают соцсети перед приемом человека на работу. Почему не включить в список мониторинга и его рейтинг в сервисах Яндекса? Индикатор ничуть не хуже.
В итоге мы дружно придем к системе социального кредита, как в Китае и в «Черном зеркале». Это понятно, весь мир туда придет. Но зачем так торопиться-то?
Как ни посмотри – неправильная продуктовая история получается: «У вас рейтинг был равен пяти, но вы проиграли в игру, в которую мы с вами играем по неизвестным для вас правилам, и теперь наши услуги для вас еще дороже, а будете возникать – вообще в такси забаним».
Правильная продуктовая история: «У вас сейчас рейтинг равен нулю и стоимость поездки 1000 р. Но вы можете получать дополнительные баллы и повышать свой рейтинг по вот таким правилам, и тогда все будет гораздо дешевле».
Чувствуете разницу? Еще бы продукт-менеджер Яндекс.Такси ее почувствовал.
С удивлением узнал, что у меня, пользователя Яндекс.Такси, теперь есть рейтинг. Следите за руками: Яндекс делает продукт -> я им пользуюсь за свои деньги -> Яндекс позволяет таксистам меня оценивать.
Перед выходными мой рейтинг был 4.82. Я-то, когда узнал о его существовании, ожидал твердую пятерку. ) Я считал, что меньше и быть не может – я всегда трезв, чист и вежлив. Я не любитель задушевных бесед с таксистами, но это уж, извините, мое право.
Кто же из водителей так мной недоволен? Тот, который поехал, не дождавшись, пока я обойду машину и сяду в нее? Или тот, кто так и не нашел меня, потому что «непонятно, где ты вообще стоишь»? Или тот, кто долго жаловался, что приходится всех возить за 350 рублей по пробкам, и не дождался дружеского сочувствия? Но это еще ладно. Сегодня мой рейтинг уже 4.74. Пять поездок в выходные, от 10 до 30 минут, в нескольких городах. Я-то о нововведении узнал до выходных, и сознательно проводил эксперимент «повысь свой рейтинг». Был еще приветливее, чем обычно, улыбался и оставлял чаевые. Не помогло. ))
Но ладно, то мои страдания. Но что будет с развитием продукта? До введения рейтингов пассажиры (напомню – это продукт для них, они за него платят) не придирались к водителям. Громко играет радио «Шансон»? Душно, не работает кондиционер? Не слишком чистый салон? Барахло в багажнике, некуда чемодан втиснуть? Пассажиры все равно ставили оценку выше, чем могли бы. У нас народ добрый, жалостливый.
А теперь пассажиры стали участником продуктовой геймификации. Только никто их об этом не предупредил и не рассказал правила игры. Это как если бы Овечкин проснулся с волейбольным мячом и в лыжах на теннисном корте – во что мы вообще играем-то?
Это Россия, ребята. Здесь эмоции побеждают логику уже много сотен лет. Водители будут мстить пассажирам, а пассажиры – водителям. Уровень терпимости к ошибкам теперь ниже нуля: «Ты меня не к тому подъезду вызвал!» «Да? А у тебя сиденье скрипучее и в салоне рыбой воняет!»
Продуктовые метрики Яндекса, построенные на таких сомнительных данных, будут гарантированно ошибочны. И по этим метрикам будут приниматься неверные решения о развитии продукта. А Яндекс – это компания, которая меняет мир, по крайней мере, в отдельно взятой стране. Да еще и почти монополист на нескольких рынках.
Как вы думаете, для чего будут использоваться рейтинги? Правильно, для определения стоимости поездки, что бы там ни писали маркетологи. Но это только начало. Потом ведь можно будет ввести эту практику для всех сервисов компании. А после и другие конторы подтянутся. Сейчас работодатели просматривают соцсети перед приемом человека на работу. Почему не включить в список мониторинга и его рейтинг в сервисах Яндекса? Индикатор ничуть не хуже.
В итоге мы дружно придем к системе социального кредита, как в Китае и в «Черном зеркале». Это понятно, весь мир туда придет. Но зачем так торопиться-то?
Как ни посмотри – неправильная продуктовая история получается: «У вас рейтинг был равен пяти, но вы проиграли в игру, в которую мы с вами играем по неизвестным для вас правилам, и теперь наши услуги для вас еще дороже, а будете возникать – вообще в такси забаним».
Правильная продуктовая история: «У вас сейчас рейтинг равен нулю и стоимость поездки 1000 р. Но вы можете получать дополнительные баллы и повышать свой рейтинг по вот таким правилам, и тогда все будет гораздо дешевле».
Чувствуете разницу? Еще бы продукт-менеджер Яндекс.Такси ее почувствовал.
🦹🏻♀ О рисках удаленки 🦹
Хороший менеджер всегда рассматривает возможности развития своего продукта или выполнения проекта наилучшим образом. Очень хороший менеджер еще и думает о рисках.
Как все пишут, нынешняя нестабильная ситуация полна прекрасных возможностей. И это правда: онлайн-бизнес на подъеме, предприимчивые стартаперы создают новые продукты. Но, как это всегда бывает в неспокойные времена, наружу сразу лезет всякая мошенническая гниль.
Так что давайте не о возможностях, а о рисках – для вас и ваших команд.
1. Сейчас люди пишут про себя в инете, нисколько не таясь. «Наша компания перешла на удаленку, а офис опустел!» Не надо так. Вас читают не только менеджеры-энтузиасты, но и энтузиасты более широкого профиля.
2. То же про болтливых партнеров. Многим будет приятно узнать, что юристы из компании, которая вас обслуживает, все на удаленке. Как быстро они среагируют, если что?
3. Видите новый сервис по доставке еды с привлекательными ценами? Нашли новый онлайн-кинотеатр с баснословно низкой стоимостью подписки? В восторге, что неизвестная никому площадка пригласила известного эксперта для онлайн-тренинга? Это вполне могут быть фейковые сервисы, которым интересны только данные ваших банковских карт.
4. Некоторые компании из-за перехода на удаленку сокращают штат, отменяют премии, понижают зп. Так они плодят недовольных, которые вполне могут и просто навредить, и поделиться инсайдерской информацией с конкурентами.
Не надо так с людьми, особенно если вы реально не тонете.
5. Наверняка кто-то в вашей команде покупал туры на ближайшее время, весна же. Пусть дважды проверят, не является ли очередное сообщение о возврате денег за билеты или отель уловкой мошенников.
6. Вы из финансовой сферы или у вас столь популярный нынче финтеховский продукт? Вы в зоне риска – готовьтесь к возможным целевым атакам.
7. Ну и не забывайте про гигиену: двухфакторную авторизацию при удаленном доступе к ресурсам компании, разграничении прав, жестких политиках использования лицензионного софта, средствах мониторинга действий пользователя, использовании VPN и т.д.
Берегите себя, свои команды и продукты.
Хороший менеджер всегда рассматривает возможности развития своего продукта или выполнения проекта наилучшим образом. Очень хороший менеджер еще и думает о рисках.
Как все пишут, нынешняя нестабильная ситуация полна прекрасных возможностей. И это правда: онлайн-бизнес на подъеме, предприимчивые стартаперы создают новые продукты. Но, как это всегда бывает в неспокойные времена, наружу сразу лезет всякая мошенническая гниль.
Так что давайте не о возможностях, а о рисках – для вас и ваших команд.
1. Сейчас люди пишут про себя в инете, нисколько не таясь. «Наша компания перешла на удаленку, а офис опустел!» Не надо так. Вас читают не только менеджеры-энтузиасты, но и энтузиасты более широкого профиля.
2. То же про болтливых партнеров. Многим будет приятно узнать, что юристы из компании, которая вас обслуживает, все на удаленке. Как быстро они среагируют, если что?
3. Видите новый сервис по доставке еды с привлекательными ценами? Нашли новый онлайн-кинотеатр с баснословно низкой стоимостью подписки? В восторге, что неизвестная никому площадка пригласила известного эксперта для онлайн-тренинга? Это вполне могут быть фейковые сервисы, которым интересны только данные ваших банковских карт.
4. Некоторые компании из-за перехода на удаленку сокращают штат, отменяют премии, понижают зп. Так они плодят недовольных, которые вполне могут и просто навредить, и поделиться инсайдерской информацией с конкурентами.
Не надо так с людьми, особенно если вы реально не тонете.
5. Наверняка кто-то в вашей команде покупал туры на ближайшее время, весна же. Пусть дважды проверят, не является ли очередное сообщение о возврате денег за билеты или отель уловкой мошенников.
6. Вы из финансовой сферы или у вас столь популярный нынче финтеховский продукт? Вы в зоне риска – готовьтесь к возможным целевым атакам.
7. Ну и не забывайте про гигиену: двухфакторную авторизацию при удаленном доступе к ресурсам компании, разграничении прав, жестких политиках использования лицензионного софта, средствах мониторинга действий пользователя, использовании VPN и т.д.
Берегите себя, свои команды и продукты.
🚇 Экстренная связь ☎️
Так и вижу, как в задымленном вагоне происходит массовый беспорядок и прочие чрезвычайные обстоятельства, а кто-то пытается связаться с машинистом по этой инструкции (см. картинку).
Да нет конечно. Видится только криворукий инженер и безголовый копирайтер, которые вместо системы экстренной связи сделали непригодную для использования дрянь. Ну и менеджер у них был соответствующий.
Интересно, кто-нибудь тестировал эту инструкцию на реальных пользователях? Вот вам и UX.
Так и вижу, как в задымленном вагоне происходит массовый беспорядок и прочие чрезвычайные обстоятельства, а кто-то пытается связаться с машинистом по этой инструкции (см. картинку).
Да нет конечно. Видится только криворукий инженер и безголовый копирайтер, которые вместо системы экстренной связи сделали непригодную для использования дрянь. Ну и менеджер у них был соответствующий.
Интересно, кто-нибудь тестировал эту инструкцию на реальных пользователях? Вот вам и UX.
🩳 Штаны и удаленка 👙
Все пишут, что важно сохранить на время удаленной работы привычный стиль жизни. Вставать в то же время. Не работать, лежа на диване. Одеваться, как на работу. И это правда, но дело не только в поддержании рабочего ритма и самоорганизации.
Дело еще в том, что shit happens.
Только расслабился – и ой. А случается ведь все тогда, когда не ждешь.
Надели вы хорошую рубашку, красивый дорогой галстук, пиджак от Бриони. Сели на фоне однотонной бежевой стены, включили конференц-связь. А брюки решили не надевать – брюк же по скайпу и зуму не видно… Не ведитесь! Обязательно что-нибудь случится. Прибежит кошка, дернет провод, камера упадет под стол. Телефон выскользнет из рук и тоже упадет под стол. Ноутбук глюкнет. Или вы просто забудетесь и во время телеконференции встанете, чтобы размяться. Или пройтись вокруг стола, подумать. Как вы это на работе делаете всегда. Только на работе вы в брюках, а не в семейных трусах оригинальной расцветки в горошек. Или вовсе без них.
А еще, если коснуться своего изображения на камере во время скайп-конференции, то камера с фронтальной переключится на обычную. А там вовсе не ваше благородное лицо, там что угодно ведь может быть. Zoom при старте конференции любит произвольно включить камеру. А вы не планировали, вы в носу ковыряли. Конфуз.
А у кого-то на кухне гора грязных тарелок с объедками. Или на стене плакаты с изображением нетрадиционных отношений. А хоть бы и традиционных – клиенту, начальнику или вашей команде разве хочется на них смотреть? Клиент же заказывал новую версию вашего суперпродукта, а не экскурсию в мир ваших фантазий. А у кого-то вообще денег хватило только на ремонт одной стены, а остальные красили масляной краской еще в 1981-м.
Подумайте, как вы на удаленной работе выглядите для других.
Ну и не забывайте надеть брюки. Это самое важное. )
Все пишут, что важно сохранить на время удаленной работы привычный стиль жизни. Вставать в то же время. Не работать, лежа на диване. Одеваться, как на работу. И это правда, но дело не только в поддержании рабочего ритма и самоорганизации.
Дело еще в том, что shit happens.
Только расслабился – и ой. А случается ведь все тогда, когда не ждешь.
Надели вы хорошую рубашку, красивый дорогой галстук, пиджак от Бриони. Сели на фоне однотонной бежевой стены, включили конференц-связь. А брюки решили не надевать – брюк же по скайпу и зуму не видно… Не ведитесь! Обязательно что-нибудь случится. Прибежит кошка, дернет провод, камера упадет под стол. Телефон выскользнет из рук и тоже упадет под стол. Ноутбук глюкнет. Или вы просто забудетесь и во время телеконференции встанете, чтобы размяться. Или пройтись вокруг стола, подумать. Как вы это на работе делаете всегда. Только на работе вы в брюках, а не в семейных трусах оригинальной расцветки в горошек. Или вовсе без них.
А еще, если коснуться своего изображения на камере во время скайп-конференции, то камера с фронтальной переключится на обычную. А там вовсе не ваше благородное лицо, там что угодно ведь может быть. Zoom при старте конференции любит произвольно включить камеру. А вы не планировали, вы в носу ковыряли. Конфуз.
А у кого-то на кухне гора грязных тарелок с объедками. Или на стене плакаты с изображением нетрадиционных отношений. А хоть бы и традиционных – клиенту, начальнику или вашей команде разве хочется на них смотреть? Клиент же заказывал новую версию вашего суперпродукта, а не экскурсию в мир ваших фантазий. А у кого-то вообще денег хватило только на ремонт одной стены, а остальные красили масляной краской еще в 1981-м.
Подумайте, как вы на удаленной работе выглядите для других.
Ну и не забывайте надеть брюки. Это самое важное. )