Pull to refresh

Comments 63

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

Я веду жж-сообщество на эту тему, запощу сейчас ссылку на вашу статью, если вы не против.
UFO just landed and posted this here
А при чем здесь молодые начальники? Такие ошибки коррелируют не только с начальниками :) А по-поводу последнего пункта, самого главного, почему вы сами так уверены в правильности своего мнения?
UFO just landed and posted this here
Ошибки совершают все, а начальники просто больше других обязаны на них(ошибках) учиться, что, возможно, автор статьи и делает :)
Я, если честно, ошибок в контексте статьи так и не увидел. Сленг местами действительно есть, но он не критичен. Картинки это скрины реального риск листа в живом проекте.

В общем, если есть замечания по сути статьи, готов обсуждать, пока предмета обсуждения не вижу.
Именно такими благими речами и вымощена дорога в проектный «не рай».
PMBOK с его формулировками и обощениями, безусловно красив как академический труд.
На практике управление проектами даже среднего размера, редко приходит к таким детерменированным проблемам и способам их решения.
Балансирование между целями и ограниченими проекта, делает списко рисков, обычным списком проблем, а не инструментом управления.

Уж лечше перечить раздел PMBOK про управление stakeholders

вы описываете симптомы отсутствия работы руководителя проекта как таковой. безусловно, когда риски никто не ищет, и никто ими не занимается, это «не рай» для проекта.

PMBOK это опыт полумиллиона руководителей проектов, собранный в течение 40 лет. поверьте, проблема не в нем, а в том, что в 95% наших проектов с рисками не работает никто.
Католическая церковь имеет более милиарда приверженцев, среди них президенты, выдающие ученые, опытные руководители проектов — это ли не аргумент в пользу верности Библейской трактовки?

PMBOK не более чем академический труд, с определенной долей верности описывающий рекомендуемую общую практику.

К тому же PMBOK не специализирован.

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

Замечание про 95% возможно и верное, но слабо коррелирует с успешностью проектов.
Менеджмент не точная наука, к тому же связанная с управлением людьми.
Работа с людьми, и их целями это чаше балансированение, чем пошаговое решение проблем
Я в управление рисками не верю. Хотя сам около года занимался этим достаточно плотно, был консультантом консультантов по управлению рисками, скажем так.

Хотя в основе идеи лежат весьма здравые постулаты, но на практике результат недостижим в части отраслей и областей. Может и нигде, не знаю. Почему? Всех интересующихся отсылаю к книге Нассима Талеба "Черный лебедь", а от себя приведу два примера:

1. «Центр внедрения ПРОТЕК» Руководство его было весьма задвинуто на управлении рисками, фактически, в Москве они были пионерами и новаторами риск-менеджмента. Они описывали, выявляли и управляли рисками. Итог? Пожалуйста:
МОСКВА, 12 авг — РИА Новости. Мосгорсуд в среду приговорил бывшего главу Федерального фонда обязательного медицинского страхования (ФОМС) Андрея Таранова к семи годам лишения свободы в колонии строгого режима и к штрафу в размере 1 миллиона рублей, передает корреспондент РИА Новости из зала суда.
Остальных фигурантов громкого дела о коррупции в ФОМС, на основе ранее вынесенного обвинительного вердикта присяжных, суд приговорил на сроки от 1,5 до девяти лет лишения свободы.
Полтора года в колонии-поселении, согласно приговору, проведет вице-президент «Центр внедрения „Протек“ Виталий Смердов.
Этот риск учтен не был (скорее всего, я деталей их кухни не знаю).

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

А бывает и еще хуже: только что человек соберется съездить в Кисловодск, — тут иностранец прищурился на Берлиоза, — пустяковое, казалось бы, дело, но и этого совершить не может, потому что неизвестно почему вдруг возьмет — поскользнется и попадет под трамвай! Неужели вы скажете, что это он сам собою управил так? Не правильнее ли думать, что управился с ним кто-то совсем другой? — и здесь незнакомец рассмеялся странным смешком.
я в управление рисками не верю тоже, равно как и в вас, например. вы есть, управление рисками тоже есть. приходится как-то с этим жить :)
Отличный комментарий.
Первый же серьезный неучтенный риск ломает всю эту стройную систему.
из-за того, что может случиться все, что угодно, не использовать риск-менеджмент?
Скорее искать баланс в ее использовании. В статье описан метод ее весьма глубокого внедрения, с довольно большими трудозатратами, но не раскрыты ее слабые стороны.
Трудозавтраты составляют 60 часов в месяц, на команду в 15 человек. Вся команда в месяц вырабатывает 15*(40 часов неделя * 4 недели) = 2400 часов. Из 2400 на риски тратится 2,5% времени. Это нормально.
Риск-менеджмент придумали изначально большие дяди для больших корпораций. Потом средние дяди из средних компаний решили, что они не хуже. А в итоге маленькие дяди из маленьких компаний, численностью 15 человек — исказили идею до неузнаваемости, зато «внедрили» и сэкономили на бумаге 400 человекочасов ежемесячно.
Большие дяди тоже экономят только на бумаге, но у них «так принято», под это выделяются астрономические бюджеты и заняты этим куча народу. Имеет смысл занятия ради занятия.

Если предположить, что может случиться нечто невообразимое, что перевернет все с ног на голову и это «нечто» — случится обязательно, и результат наставания этого «нечто» в абсолютном выражении превышает эффект от внедрения риск-менеджмента за минусом расходов на риск менеджмент… Ничего личного, просто математика…

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

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

Талеб нынче популярен, но его теория не очень то конструктивна. Талебы как гиены существуют за счет других видов, охотясь за редкими событиями.
Вы как-то слишком увлеклись законами Мёрфи и забыли про типичные вероятности. Да — кирпич на голову упасть может хоть сейчас, но вероятность этого на несколько порядков меньше, чем вероятность того, что накроется сервер в пиковый момент.
Прямо анекдот какой-то развели про вероятность от мужчины и женщины с динозавром.
Вы правы! Серьезный неучтенный, но реализовавшийся риск ломает систему. Не управляя рисками, мы имеем полное множество неучтенных рисков (т.к. не учитываем никакие из них). Управляя рисками, мы имеем множество неучтенных рисков меньше. ИМХО, именно на это и направлено управление рисками.
Вы не верите в абсолютное управление рисками, то есть в то, что можно учесть 100% всех рисков и заранее к ним подготовиться — и правильно делаете. Но ведь риск-менеджмент не об этом, а о том, чтобы учесть хотя бы часть значимых рисков и тем самым увеличить вероятность успеха.

Отрицать управление рисками — значит полностью полагаться на случай.

Вот вам мой любимый пример: вождение автомобиля. Вы ведь перед перекрестком притормаживаете, не так ли? Или, полагаясь на случай, педаль в пол? И конечно, даже самое внимательное вождение не исключает ДТП, потому что вы никогда не владеете ситуацией на 100%.
Если у меня будет выбор, проверить тормоза перед выездом или заняться вместо этого расчетом риска встречи с оболбанным нарком на перекрестке — я тормоза проверю.
Во-первых, в примере который вы привели у вас никогда не будет такого выбора «или-или». Во-вторых, уважаемый мною Т. Нассиб, говорит что «не имеет значения насколько вероятно событие, расматривать надо то, насколько значительный результат будет получен, если оно случится», поэтому вам прийдется подумать и о тормозах и о нарке на перекрестке, и еще заодно о десятке рисков возникших на дороге. И тогда, возможно, вы доедете до пункта «Б» :)
Вообще если так рассуждать, то действительно можно совсем ничем не управлять. А просто полагаться на волю случая. Сам Таллеб пишет с одной стороны о том, что есть ассиметричность случайности и как следствие ассиметричность ожидания от этой случайности. С другой стороны о том, что предпринимая хоть какие-то действия мы увеличиваем вероятность успешного исхода событий. Да, выгода это тоже вероятность, поэтому Тостой лучший писатель, нежели миллион обезъянок. :)
Он как трейдер предпочитает играть по стратегии положительной ассиметрии (не знаю как это называется научно), а чаще всего наступает событие с глубоким отрицательным ожиданием… Вот тогда все управление рисками — в баню. :)
хорошая статья. За нее не жалко и карму плюсануть.
4 часа в неделю для того, что можно сделать за максимум час по почте?

Мониторинг и контроль — всего лишь 30 минут для команды из 15 человек?
Ежедневные отчеты команды? Вы о багтрекерах слышали?

О каком управлении рисками можно говорить если вы бездумно тратите время команды на бесполезные митинги и явно ошибаетесь с оценкой на время контроля?

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

Первый абзац — вообще финиш. Чисто так для сравнения: Социальные аспекты руководства, или как же всё таки «пинать» сотрудников. 2 года спустя

 

В этом месте я принял душ и решил расписать подробнее

 

Во-первых, про ваши примеры:
1. Это — не риск. Время на сборку должно быть заложено изначально.
2. Вы должны это делать или нет? Если должны поддерживать Mac, то время на тестирование должно быть заложено изначально. Если не должны, то вас это не должно волновать.
3. Это — работа ваша и, иногда, лидов. Риском никак являться не может
4. Этот риск вне вашей компетенции. За это ответственен админ. Подобные вещи должны входить в резерв, который вы в любом случае обязаны закладывать.
5. Прописывается в договоре сразу. Не риск.
6. Аналогично п. 5
7. Во-первых, узкие места не поменяются. Так что проблем тут не будет. Во-вторых, должны было быть заложено время на апгрейд сервера с самого начала. В-третьих, проблема может быть в разных конфигурациях (софта) серверов. В этом случае надо при старте проекта сделать схожие конфигурации.
8.… Завтра может случиться землетрясение — опоздаем с разработкой новый фазы
9. Оговаривается в договоре
10. Не риск. Это проблема тех, кто оценивал время на тестирование.

Итого вы ошибки ваши, тех кто составляет договора, ошибки лидов перекладываете в «риски».

Во-вторых, про ваши подсчеты:
1. Время на митинги можно смело умножать в 2.5-3 раза. К ним нужно готовиться, нужно прерывать текущую задачу, нужно выпить кофе после митинга, нужно включиться в работу после кофе.
2. Можно не гипотетическое «Положив, что критичный риск отбирает у проекта минимум 40 человеко-часов, получаем от 400 человеко-часов экономии ежемесячно», а конкретную статистику?
хороший коммент, а про душ посмеялся…
1. В зависимости от сложности проекта и опытности команды иногда случается так, что время и силы, затрачиваемые на сборку, возрастают.
2. Работа на Mac может быть из разряда «nice to have». Вспомнить о том, что мака до сих пор нет, иногда полезно. Если на поздней стадии вспомнили — вполне себе риск (а раньше не вспомнят, потому что раньше это «не риск»).
3. Статус у тикетов могут не обновлять, потому что, например, есть более приоритетные тикеты. Если у команды есть подозрение, что большинство из этих тикетов не вполне соответствуют текущему состоянию дел, и можно их сильно подвинуть в приоритете — стоит их протестировать и обновить статус.
4. Админ (или тот, кто выполняет его роль) может входить в команду проекта (а иногда и не один) ;-)
5.…

В общем, что то мне надоело писать. Суть — вы придираетесь, могут быть и такие риски вполне, они вполне понятны и нормально так раскрывают суть подхода — т.е. задачу свою в качестве примера выполняют на пять баллов.

Также, вы утверждаете, что все риски надо планировать, тогда они не случатся. Но вот беда в том, что все запланировать сразу не получится, и обязательно что то вылезет. Так вот автор нам как бы рассказывает о том, как надо строить работу, чтоб последствия от непредусмотренных ситуаций были минимальными. С этой задачей (ну, как мне кажется) статья тоже очень даже хорошо справляется.
1. ПМ со стажем проектов на 50к человеко-часов (смотрим профиль автора) не может запланировать время на сборку? Вы издеваетесь?
2. Ну вспомнили. Ну приняли решение либо делать, либо не делать. Оценили. Какой тут риск? Не входило в изначальную оценку? А резерв на что?
3. Сколько времени будет обновить статусы тикетов? Это не риск, а банальная организация процесса разработки. Надо проверить статусы, тратиться время из резерва. И делается втык что статусы не поддерживаются в актуальном состоянии.
4. Тогда админу надо дать много человеко-часов с запасом, т.к. в большинстве случаев он может работать параллельно команде.

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

Ради чего тратятся эти 160 человеко-часов в месяц? Есть статистика?
тому, что время на сборку не было запланировано, может быть сотня причин. в том числе, безусловно, это может быть и ошибка ПМа (не обязательно ваша, кстати, проект вам могли передать на полпути). управление рисками отвечает на вопрос «что делать сегодня?», не выясняя «кто виноват вчера?».

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

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

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

ПМ получает зарплату за то, что риски его проекта выявляются и погашаются до того, как становятся проблемами, а проект не сдвигается по датам.
Нельзя все подряд оценивать в точки зрения «может произойти, а может и нет». Вы заказчику будете говорить «с вероятностью 80% проект будет готов к такому-то сроку»?

На погашение рисков не нужно время? Вы это самое время возьмете либо из резервов, либо измените сроки.

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

А вообще, спасибо: вы мне подкинули отличную тему для собеседования на должность PM:)
>>Вы заказчику будете говорить «с вероятностью 80% проект будет готов к такому-то сроку»?

это высший пилотаж управления проектами. думаю, со временем, я именно так и буду говорить. ПМ, который говорит что проект закончится вовремя с вероятностью 100% — врет.
… И с вами никто не будет работать. Никому не нужны вероятности. Нужен результат. Конкретный результат к конкретному сроку.

Это — не высший пилотаж. Это — непонимание целей вашего работодателя и вашего заказчика.
Просто приведу небольшой пример: приходит к вам заказчик и говорит: «Я хочу сделать сайт к презентации моего нового продукта такого-то числа». Ответ «с вероятностью N%» означает потерю заказчика.

Если же ваша фирма — сама себе заказчик, то в любом случае есть планирование бюджета. Причем планирование не только на этот конкретный проект, а вообще на все. Я понимаю, что PM'у все равно что там происходит у ответственных за деньги, но их никак не может устроить «с вероятностью...» Им нужны конкретные сроки, чтобы можно было построить план на месяц/полгода/год/5 лет вперед.
безусловно, нужно говорить «йес сер» на любую дату, чтобы заказчик согласился, даже понимая, что к этой дате мы не успеем. незачем думать, что может нам помешать, считать вероятности и последствия и так далее. случилась проблема, переоценили сроки и поехали дальше.

на месте заказчика, я бы больше всего боялся таких вот ПМов, готовых на все. что я хотел бы увидеть на его месте, так это таблицу в духе: дата окончания — ключевые риски — вероятность успеть. чем дальше дата, тем меньше рисков и тем выше вероятность, ну и так далее.
Если не успеть, то надо так и сказать. В чем проблема?

Либо вы можете успеть и говорите об этом, либо не можете. Третьего не дано. «Можем с такой-то вероятностью», приравнивается к «не можем».
в таком случае, честно было бы говорить всегда «не можем». хотя бы потому, например, что в любой момент к вам в офис может приехать обэп и вынести компьютеры. вы скажете, что вероятность этого невелика. я соглашусь — невелика, но она есть.

равно как есть еще тысяча рисков, на которые вы закрываете глаза. если вы мне, как заказчику, обоснуете свое «можем» как 95% вероятность попадания в дату, я буду с вами работать. если это будет просто честное пионерское не буду, наверное.
Вам самим-то не смешно? )
мне скорее грустно. больше половины проектов валится из-за того, что ПМы забивают на риски уже на старте. серьезные проекты, длиной в полгода и больше, приносят серьезные убытки обоим сторонам.

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

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

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

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

Опять же, в зависимости от команды может быть очень даже эффективно тратить 160 человеко-часов в месяц. И эффективно ли их тратить вообще в принципе (или сколько их тратить, и тратить ли вообще) — это вопрос, который в данной статье не рассматривается. Здесь говорится про то, как их тратить.

Т.е. если у вас нет рисков на проекте — не тратьте. Достаточно 15-ти минутных совещаний — не тратьте час. Ну и т.д., здравый смысл никто не отменял.
Хотел бы добавить, что я предпочитаю сам отвечать за свои ошибки. Если проект не уложился в заложенный резерв, то отвечать за это мне. Проблема в том, что бюджет не резиновый и я не могу закладывать время на падения сервера, к примеру.
спасибо за комментарий. все верно — любые ошибки, совершенные или потенциальные, перекладываются в риски. вне зависимости от того, кто виноват, проекту будет плохо, если риск случится. хороший ПМ риск этот погасит, плохой — скажет, что это чужая проблема и надует щеки.

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

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

Зачем собирать всю команду в одном месте и в одно время вместо того, чтобы попросить «ко вторнику пришлите все возможные риски в проекте по почте»? И человек в любое удобное для него время без отрыва от работы это сделает.

Можно все же конкретную статистику по работоспособности вашей схемы?

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

статистика работоспособности в статье вроде как описана. расходы подсчитаны более-менее точно, доходы — грубо, но достаточно, чтобы показать что они на порядок выше расходов. если присмотреться к критичным рискам, то видно, что их последствия гораздо серьезнее, чем работа/простой пары человек в течение пары дней (40 часов).

управление рисками полезно — именно об этом я и пишу в статье.
> Ежедневные отчеты команды? Вы о багтрекерах слышали?

В проектах свет клином не сошелся на одних разработчиках. Есть и другие члены команды: маркетологы, эйчары, редактора, и т.д. в зависимости от проекта. Их всех Вы тоже в багтрекер загоните???
UFO just landed and posted this here
UFO just landed and posted this here
+несколько. Я тоже был удивлен увидев в примеров вместо рисков какие-то текущие конфигурационные проблемы.

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

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

Классика расчетов это определение суммы для каждого риска, которая надо на его устранение. Сумму умножаем на вероятность. Потом это дело все суммируем и получаем бюджет на риски, так сказать н/з :). Книги говорят о том, что такой бюджет обычно составляет ~8% от стоимости проекта.
дельное замечание, спасибо. я исходил их того, что не всегда ПМ управляет бюджетом проекта в его денежном выражении, чаще он оперирует трудозатратами (человеко-часами). в этом случае человеко-часы и есть его «деньги».
Проекты разные бывают. Но полностью с Вами согласен, т.к. сам оперирую лишь трудозатратами.
Какие это книги? Для каких бюджетов? Что-то мне подсказывает, что это опыт какого-нибудь Microsoft'a, где и 1% — очень много. PM'ы, с которыми я общался, говорят цифрах близких к 100%.
Культ карго? :) С умом надо использовать управление рисками. Ставить их во главу угла, мне кажется, опасно! В целом поддерживаю автора, статья адекватная!
А почему не рассказали про стратегию Avoid, т.е. избегание риска?

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

Крайне спорное утверждение. А как же планирование, контроль, коммуникации? ;)
Sign up to leave a comment.

Articles