Category: путешествия

promo psilonsk february 12, 2015 18:07 17
Buy for 100 tokens
Ранее в сериале: История первая: договор Ариадны История вторая: лыжи, смоктульки и чаевые История третья: мертвец и розетка ​*** — Послушай, Леша, послушай меня, милый мой друг. Ты же менеджер проектов, так? Ты же не дебил, правильно? Я тебе на пальцах объясняю, а ты понять не можешь.…

Родос Колосский



Родос прекрасен. Особенно прекрасен он для семейного отдыха в этот период года - в центральной полосе России наступает унылая дождливость и тревожное ожидание осенней депрессии, а тут светит солнце, температура воздуха колеблется от +31 днем до +26 ночью, да и температура воды не сильно от этих значений отстает. Вдвойне прекрасен Родос для восстановления растраченных в проектных баталиях менеджерских сил, ибо ничто не лечит нервы лучше, чем зелень лавра, доходящая до дрожи.
Collapse )

Если есть вопросы - задавайте. )

Эми Чуа «Боевой гимн матери-тигрицы»



Сегодня в нашем рецензионном прицеле необычная мишень - книга Эмили Чуа «Боевой гимн матери-тигрицы». Она не совсем про менеджмент, хотя, если вдуматься, она как раз и есть квинтэссенция менеджмента - ведь это книга о воспитании детей.
Collapse )

Про консалтинг и апельсиновый тест: ответы



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

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

Менеджеры, которые говорят "это невозможно", проваливают тест с апельсиновым соком. Менеджеры, которые говорят "да, сделаем без проблем", проваливают тест с апельсиновым соком.
Правильный же ответ банален:
Collapse )

Упражнение для менеджера: тест с апельсиновым соком



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

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

О малом предпринимательстве и непомерных налогах

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

Оффтоп

В городе Лондон, на Оксфорд-стрит, лежит чистый и хорошо выбритый бомж, пьет кофе из Старбакса и читает "Ангелы и демоны". Помахал мне рукой и улыбнулся. Ну никакого стыда, я его даже фоткать не стал.

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

Как управлять рисками в проектах. Часть 3. Ранжирование рисков

The_rope-walker_34x24

Все посты на эту тему:
Как управлять рисками в проектах. Часть 1. Начало
Как управлять рисками в проектах. Часть 2. Поиск рисков
Как управлять рисками в проектах. Часть 3. Ранжирование рисков
Как управлять рисками в проектах. Часть 4. Стратегия реагирования на риск
Как управлять рисками в проектах. Часть 5. Все происходит из-за денег, сынок


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

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

Лирическое отступление. Может показаться, что для определенной категории проектов какие-то риски нехарактерны в принципе. Например, для проектов разработки софта, природные явления, вроде бы, малоинтересны. Я тоже так думал, пока в 2005 году наша команда, ключевые разработчики которой жили в Штатах, не столкнулась с последствиями урагана Катрина. Догадайтесь, в каком городе жили эти разработчики. Правильно, в Новом Орлеане. Поэтому в этом году наша команда последствия урагана Сэнди даже не заметила, не считая пары дней простоя. Люди хорошо учатся на своих ошибках.

Ну так вот, проверили вы источники, обратились к своему опыту, вспомнили о чужом, и больше идей у вас нет. Но внутреннее чутье не велит останавливаться – вы явно что-то забыли. И тут вас осеняет: «Женааааа!», – кричите вы, откидываясь на диванную подушку. «Иди сюда, разговор есть!» 
И правильно – когда все личные резервы поиска рисков исчерпаны, пора привлекать вашу проектную команду. Собираетесь вы с проектной командой и устраиваете мозговой штурм – просите ваших коллег по проекту назвать риски, которые они видят. И это работает. Потому что у каждого есть свои тревоги по поводу успешности проекта. Гарантированно назовут такие, о которых вы забыли!

Проектная команда опрошена. Жена подсказала пару интересных рисков, связанных с особенностью пищеварения кошки (и вы уже купили специальный наполнитель для дорожного лотка), напомнила о непоседливости ребенка (и вы уже скачали на свой айпад десяток мультиков).  Вдруг еще что-то забыли? Пора позвонить тестю и лучшему другу, один из них бывший дальнобойщик, а второй каждый год на машине возит семью в Анапу. Оба – эксперты в вопросе организации дальних поездок, хотя в вашу проектную команду и не входят. Эксперты беспристрастны, это люди со стороны, они не так, как команда, вовлечены в проект и не сильно заинтересованы в его провале или успехе. В реальном проектном мире экспертами могут выступать люди, которым вы доверяете или, реже, специально приглашенные специалисты.

Мозговой штурм провели, экспертов опросили. Что еще? Да хватит, уверяю вас. Тут не так важно вспомнить все сразу, сколько начать анализ рисков и делать это регулярно. Оптимальная частота – раз в неделю. Это означает, что каждую неделю надо проводить мозговой штурм с командой, общаться с экспертами (для этого они должны быть в курсе хода проекта), просматривать план и другие документальные источники.
На самом деле наука управления рисками предложит вам еще с десяток методов поиска. Но, поверьте, если вы хорошо с ними знакомы и используете, вы вряд ли дочитали до этого места. ))

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

Лирическое отступление. Мозговой штурм – самый эффективный способ не только потому, что помогает выявить риски в проекте. Он хорош, прежде всего тем, что дает возможность команде встретиться по умному поводу и свободно общаться. Как ни странно, это сплачивает гораздо лучше, чем пиво в пятницу (даже если все спорят и кричат). Мне вспоминается, как я работал в крупной компании, и один из менеджеров собирал нас всех на кухне, чтобы рассказать про то, как он в молодости покупал творог на базаре, но не купил его, а зато напился. Всегда была одна и та же дурацкая история, но обраставшая все новыми и новыми деталями.  Два десятка человек мучались, слушая этот бред. Дело было давно, но чувство раздражения по поводу бездарно потраченного времени у меня осталось до сих пор.


Кстати, а как поступать с рисками, которые мы так и не выявили? И жену спросили, и всех родственников помучали, и знакомым позвонили, и план проверили, и все-все, вроде, учли, но осталось же что-то, о чем забыли?
Как бы вы поступили с рисками, которые есть, но вы их не знаете? (пишите в комментах)

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

«Насколько возможно возникновение этого риска?»
и
«Сильно ли риск повлияет на проект?»

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

Так и в реальных проектах – возможность проявления риска сильно зависит от внутренней организации проекта. Именно поэтому сложно придумать универсальный (и понятный) алгоритм для качественного оценивания возможности возникновения риска. Но существует простой способ: а давайте разделим все риски по возможности возникновения на 4 группы:

A. Незначительная возможность возникновения.
B. Низкая возможность возникновения.
C. Средняя возможность возникновения.
D. Высокая возможность возникновения.


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

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

Разбираемся со вторым вопросом: «Сильно ли риск повлияет на проект?» Логика абсолютно такая же: что русскому хорошо, то немцу – смерть. На один проект риск повлияет очень сильно, на другой – очень слабо. В нашем модельном примере про автопутешествие, риск поломки какого-то узла на джипе может оказаться фатальным для машины, а владелец отечественного автомобиля прикрутит эту хреновину проволокой и еще пятьсот километров проедет.
По аналогии, воздействие риска на проект (точнее последствия этого воздействия) будем тоже описывать четырьмя состояниями, например, так:

A. Незначительные последствия.
B. Средние последствия.
C. Значимые последствия.
D. Критические последствия.


С этими параметрами поступаем так же, как с предыдущими: приписываем каждому риску одно из четырех значений.

Там четыре параметра, тут четыре параметра – пора их связать и построить таблицу, в которой по вертикали будет один параметр, а по горизонтали – другой:

risk matrix 2

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

Она помогает нам ранжировать риски в проекте. Вот смотрите, каждой возможности возникновения соответствует своя степень воздействия на проект. Например, пара «Незначительная возможность возникновения» – «Незначительные последствия». Нужно ли нам беспокоиться о риске с такими параметрами? Нет, пока не стоит. Это какое-то почти невозможное событие, да еще и почти на нас не влияющее. Назовем это «низким риском». А если риск описывается парой «Средняя возможность возникновения» – «Средние последствия»? Тут уже надо беспокоиться и думать, что делать с этим риском. Такие риски назовем «средними». И так далее – выделим еще, например, «высокие риски» и «критические риски».

А можно ли было нарисовать ее иначе? Например, поставить ячейке «Средняя возможность возникновения» –«Средние последствия» значение "низкий риск"? Конечно. Все зависит от проекта, только вы определяете, как вам ранжировать риски.

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

Но об этом в следующий раз.

(продолжение следует)

Пирамида планирования: как рождаются коварные планы

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

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

Чтобы конкретика появилась, кроме распаленного воображения нужно еще декомпозировать видение и определить цели проекта и критерии их достижения (я уже писал, как важно для успеха проекта правильно формулировать его цели, и к чему приводит их отсутствие). Что нужно, чтобы воплотить видение в жизнь? Как мы определяем, что видение воплотилось (читай, что цели достигнуты)? Куда конкретно мы идем? В отличие от видения, цели описываются измеримыми величинами. В нашем примере это могут быть географические, ценовые, временные, погодные, технические параметры. Например, целями проекта может быть поездка на своей машине с палатками в окрестности Туапсе на неделю в июле, приобретение бутылки мартини в «Пятерочке», совмещение отпусков двух участников, покупка шезлонгов и т.д. А могут быть и другие цели –  полет на частном самолете на Сицилию, аренда виллы на месяц и заполнение бассейна самым дорогим мартини. Цели разные, а видение практически не поменялось – удовольствие от отпуска и романтическая обстановка присутствуют в обоих случаях. Благодаря такой инвариантности целей, появляются альтернативные пути развития проекта, чем активно пользуются консультанты, показывая клиентам эти альтернативы и направляя проект в нужное русло.

Когда цели определены и согласованы участниками проекта, можно переходить к еще большей конкретике – формировать требования. Требования – это те характеристики, которыми должен обладать конечный результат проекта, чтобы цели были достигнуты. В нашем отпускном примере требования звучали бы так: «Температура воздуха не ниже 28 градусов», «Температура воды не ниже 25 градусов», «Дождя нет», «C любимой не поссорился» и т.д. Критерии - количественные характеристики достижения целей. Например, «Дождя нет» = на ладонь, расположенную параллельно земле, за три минуты не упало ни одной капли.

Когда требования и критерии формализованы и согласованы, можно переходить к формированию WBS (Work Breakdown Structure). По-русски это называется «структура декомпозиции работ». WBS – это список работ, которые нужно выполнить для достижения целей проекта и удовлетворения его требований. Работы в WBS связаны друг с другом, самая распространенная связь «старт-финиш» – для начала одной работы нужно завершить одну или несколько других. В WBS работы иерархичны – есть крупные фазы проекта, которые состоят из более мелких этапов, которые, в свою очередь, состоят из задач, а те из подзадач, результатов и контрольных точек. Такая «матрешка» поддерживается всеми инструментами планирования и позволяет отслеживать как проект в целом, так и отдельные его детализированные части. Какие еще бывают зависимости задач можно почитать, например, здесь (вы это и так все прекрасно знаете, просто напоминаю на всякий случай).
Замечу, что на этапе построения WBS еще ничего не сказано о связи работ к исполнителям и сроками, сначала важно нарисовать саму структуру. Составляя WBS, нужно очень разумно подойти к детализации работ. Если расписывать каждую мелочь, на составление плана уйдет много времени, но к цели нас это не приблизит и рисков проектных не снимет, зато мы обязательно в деталях запутаемся. Не стоит писать такую WBS:

  • Открыть водительскую дверь машины

  • Перенести через порог правую ногу

  • Ступить на пол машины

  • Сесть в водительское кресло

  • Поставить левую ногу рядом с правой

  • Перенести правую ногу на педаль тормоза

  • И т.д.

Достаточно написать:

  • Отправиться в путь на машине

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

Итак, мы получили следующую картинку:

В этой пирамиде все кирпичики связаны. Захотел поменять график – меняй WBS. Понадобилось скорректировать требования – получай изменения и в WBS, и в графике проекта. Ну а тому, кто изменил в середине проекта видение, можно только посочувствовать. Догадайтесь, что будет с его проектом и сколько это будет стоить. :-)

Ну и последнее на сегодня. Черчилль как-то сказал, что любой умный человек может составить план победы в войне, если он не отвечает за осуществление этого плана. Менеджерам проектов не повезло (да нет, конечно же им повезло!) – они отвечают не только за планирование, но и за претворение этих планов в жизнь. И они нуждаются в методах, которые позволили бы сделать путь исполнения плана менее тернистым. И такие методы есть. Но это уже другая история. :-)

А вы планируете так же? Какие методы применяете?