Comments 26
Вполне полезная статья. И как раз, хотелось бы прочитать в «более широком» спектре.
Особенно интересует процесс автоматизации учета рисков.
Особенно интересует процесс автоматизации учета рисков.
Вот здесь: http://pmo.ru/riskology/ доступны инструментальные средства для оценки рисков Вашего проекта. Посмотрите — возможно, это то, что Вы ищите.
Спасибо за статью.
Есть у меня проблема, которая, как я понял решается в основном только опытом PM. Как рассчитывать время? Глупый вроде вопрос, но сколько книг\статей прочитал так и не понял. Как узнать сколько времени затратит команда на эту задачу? А с учётом рисков?
Я понимаю, что универсального ответа нет, но может просто поделитесь своим опытом расчета? Когда вы только начинали работу.
Есть у меня проблема, которая, как я понял решается в основном только опытом PM. Как рассчитывать время? Глупый вроде вопрос, но сколько книг\статей прочитал так и не понял. Как узнать сколько времени затратит команда на эту задачу? А с учётом рисков?
Я понимаю, что универсального ответа нет, но может просто поделитесь своим опытом расчета? Когда вы только начинали работу.
Когда ты начинаешь работать с новой командой, то есть два варианта развития событий:
1. (Идеал) В компании есть учет времени выполнения проектов, работает какая либо методология управления проектами. В этом случае есть шанс, что просмотрев выполненные проекты данной командой, ты составишь для себя некое представление об способностях каждого члена команды… а так же, если команда сплоченная, и о системном эффекте их совместной работы (есть такой термин эмерджентность).
2. (Реалии). Увы ни о каком учете времени, задач и вообще никто нечего не знает. Тут только на собственных шишках получать опыт. Ну правда можно уменьшить последствия рисков. Взять старого PM менеджера (или кого нибудь на него похожего), засесть с ним за чашкой кофе/пива/колы/молочного коктейля и выпытать кто есть кто, и что от него ждать.
1. (Идеал) В компании есть учет времени выполнения проектов, работает какая либо методология управления проектами. В этом случае есть шанс, что просмотрев выполненные проекты данной командой, ты составишь для себя некое представление об способностях каждого члена команды… а так же, если команда сплоченная, и о системном эффекте их совместной работы (есть такой термин эмерджентность).
2. (Реалии). Увы ни о каком учете времени, задач и вообще никто нечего не знает. Тут только на собственных шишках получать опыт. Ну правда можно уменьшить последствия рисков. Взять старого PM менеджера (или кого нибудь на него похожего), засесть с ним за чашкой кофе/пива/колы/молочного коктейля и выпытать кто есть кто, и что от него ждать.
2 вариант думаю ближе к реалии, вы правы, но что делать, если не старого PM, т.к. команда и проект новые + не могу сравнить с конкурентами, т.к. продукт новый и нет аналога на рынке?
Делаешь начальную оценку трудоемкости..(пальцем в небо), заручаешься пониманием команды (смогут / не смогут; делали раньше/ не делали), делаешь запас времени и денег и приступаешь к работе.
После этого на контрольных точках делаешь ревизию проекта: что сделано и что нет. На основании этого оцениваешь персонал и трудоемкость задач. Чем чаще это будет сначала, тем лучше… можно сразу скорректировать сроки, бюджет, либо убить проект.
После этого на контрольных точках делаешь ревизию проекта: что сделано и что нет. На основании этого оцениваешь персонал и трудоемкость задач. Чем чаще это будет сначала, тем лучше… можно сразу скорректировать сроки, бюджет, либо убить проект.
Спасибо за отзыв.
Универсального ответа действительно нет.
Но есть методики, которые могут помочь оценить трудоёкость предполагаемой работы: экспертные оценки, групповые оценки, использование исторических данных и т.п.
Чуть позже планирую осветить эти методы в других публикациях.
В данном топике я предполагал, что чистая трудоёмкость уже определена.
Универсального ответа действительно нет.
Но есть методики, которые могут помочь оценить трудоёкость предполагаемой работы: экспертные оценки, групповые оценки, использование исторических данных и т.п.
Чуть позже планирую осветить эти методы в других публикациях.
В данном топике я предполагал, что чистая трудоёмкость уже определена.
Основные вопросы:
1. Что такое риски?
2. Что является риском, а что нет?
Попробую ответить кратко:
1. Риск — это то, что влияет на проект, но происходит НЕ по инициативе руководителя проекта.
2. Имеет смысл учитывать только те риски, которыми руководитель проекта может реально управлять. Остальное — форс-мажер. (Перекликается с цитатой Тома Де Марко.)
1. Что такое риски?
2. Что является риском, а что нет?
Попробую ответить кратко:
1. Риск — это то, что влияет на проект, но происходит НЕ по инициативе руководителя проекта.
2. Имеет смысл учитывать только те риски, которыми руководитель проекта может реально управлять. Остальное — форс-мажер. (Перекликается с цитатой Тома Де Марко.)
Замечательная статья.
Но хотелось бы немножечко откомментировать кое-что.
Берем первую диаграмму, показываем ее заказчику — отлично. Он представляет себе реальное время, которое мы заложили.
Показываем ее же исполнителям. Вот здесь, мне кажется небольшая засада. Чисто психологическая. Человек будет внутренне исходить из того, что у него на задачу времени «синенькое+красненькое». И выкладываться будет исходя из этого времени, даже если ему четко растолкуют, что красненькое, это резерв. Соответственно, в случае наступления рискового события есть шанс, что исполнитель использует все время еще до его наступления.
Есть мысли, как этого избежать?
У меня так только одна :). Иметь разные диаграммы на разные случаи жизни. Одну для РП, одну для исполнителей, одну для Заказчика.
Но хотелось бы немножечко откомментировать кое-что.
Берем первую диаграмму, показываем ее заказчику — отлично. Он представляет себе реальное время, которое мы заложили.
Показываем ее же исполнителям. Вот здесь, мне кажется небольшая засада. Чисто психологическая. Человек будет внутренне исходить из того, что у него на задачу времени «синенькое+красненькое». И выкладываться будет исходя из этого времени, даже если ему четко растолкуют, что красненькое, это резерв. Соответственно, в случае наступления рискового события есть шанс, что исполнитель использует все время еще до его наступления.
Есть мысли, как этого избежать?
У меня так только одна :). Иметь разные диаграммы на разные случаи жизни. Одну для РП, одну для исполнителей, одну для Заказчика.
Я думаю ваш вариант наилучший.
Мне кажется, что это в значительной мере усложняет работу PM. Достаточно одного раза, чтобы ваша команда узнала о существовании второго плана для Заказчика, и после этого описанная вами ситуация повторится.
Я практикую другой подход: добавлять контрольные точки. Точкой может быть завершение некой части проекта… или просто конкретная дата. После этого можно проанализировать состояние проекта и предпринять некие действия.
Кроме того, необходимо работать с персоналом. Сюда входит как разъяснения, что нужно от человека и какая перед ним стоит задача, так и какие последствия это вызовет, и много еще чего.
Я практикую другой подход: добавлять контрольные точки. Точкой может быть завершение некой части проекта… или просто конкретная дата. После этого можно проанализировать состояние проекта и предпринять некие действия.
Кроме того, необходимо работать с персоналом. Сюда входит как разъяснения, что нужно от человека и какая перед ним стоит задача, так и какие последствия это вызовет, и много еще чего.
При определённом уровне зрелости команда вполне может и знать о существовании «другого» плана. Это не всегда является проблемой. Проблемой может стать Ваше отношение к команде.
Если люди почувствуют, что Вы искусственно занижаете допустимые сроки, игнорируя объективную потребность времени.
Если поймут, что Вы игнорируете мнение экпертов, тех, кто действительно понимает, сколько нужно усилий.
Если осознают, что Вы фактически «продавливаете» сроки.
В этом случае можно очень быстро потерять доверие команды. И вот тогда уже действительно придётся выкручиваться.
Если люди почувствуют, что Вы искусственно занижаете допустимые сроки, игнорируя объективную потребность времени.
Если поймут, что Вы игнорируете мнение экпертов, тех, кто действительно понимает, сколько нужно усилий.
Если осознают, что Вы фактически «продавливаете» сроки.
В этом случае можно очень быстро потерять доверие команды. И вот тогда уже действительно придётся выкручиваться.
Прочитав в вашем комментарии про контрольные точки (про которые я, конечно же и раньше знал), пришел к выводу о том, как можно было бы оптимально иметь один план для всех, но при этом исключить работу программиста как синенькое+красненькое. К примеру у нас проект разбит на несколько контрольных точек, после которых имеем функционал, который заказчик апрувит и платит деньги по расписанию проекта. У программистов делаем 2/3 зарплаты окладом, 1/3 зарплаты премией. Контрольная точка, когда должно быть все готово назначается заранее до даты отправки клиенту. Время между контрольной точкой и датой отправки = время на риски. Если программисты не укладываются к контрольной точке, а работают как синенькое+красненькое, то недосчитываются части премии (о чем уведомляются ПМ'ом или системой, если она настолько продвинута).
В дополнение, я пропагандирую подход, когда премии недосчитывается не один программист, а все, кто в данный момент занят на данном проекте. Таким образом, коллективная ответственность повышается, мы имеем один план для клиента и сотрудников, мы замотивировали сотрудников работать не всё время включая риски, а укладываться в безрисковый срок, мы замотивировали других программистов помогать тем, у кого есть проблемы с реализацией задачи.
В дополнение, я пропагандирую подход, когда премии недосчитывается не один программист, а все, кто в данный момент занят на данном проекте. Таким образом, коллективная ответственность повышается, мы имеем один план для клиента и сотрудников, мы замотивировали сотрудников работать не всё время включая риски, а укладываться в безрисковый срок, мы замотивировали других программистов помогать тем, у кого есть проблемы с реализацией задачи.
Да, Вы абсолютно правы. Так называемый закон Паркинсона говорит нам о том, что работа стремиться занять всё выделенное на неё время.
Если по каким-либо причинам мы не можем себе позволить прозрачное планирование (политический обстоятельства, внешние факторы и т.п.), то наиболее выгодным является возможность иметь несколько планов в зависимости от потребностей.
Если по каким-либо причинам мы не можем себе позволить прозрачное планирование (политический обстоятельства, внешние факторы и т.п.), то наиболее выгодным является возможность иметь несколько планов в зависимости от потребностей.
Статья действительно хорошая! Выскажу мнения насчет посчета времени.
Когда я начинаю подсчитывать время я всегда дроблю проект на как можно мелкие задачи, ведь если вам сказать, что нужно подняться на Эверест — это покажется нереально, а важно верить и видить свою цель. Так уж сложилось у меня, что я обжегся не раз на прогнозах програмистов, поетому всегда умножаю время на 2 (для каждого програмиста коэфициент свой :), также закладываю время на код-ревью.
Когда говорю с коиентом, стараюсь выбить как можно больше дополнительного времени, но при этом обусловлюю возможность досрочной здачи, мотивирую я это тем, что лучше, чтобы мыстраховались ирасчитывали на реалистические сроки, а если пулучится быстрее от этого будет лучше двум сторонам.
Вспомнилась одна стандартная фраза для собеседования:«Выне успеваэте здать проектили задачу до установленого срока, сегодня пятница вечер, а нужно на понедельник утро, ваши действия?». Правильный ответ — поставить в извесность менеджера проектов. К этому я и приучаю своих сотрудников. Но при этом для клиента у меня один график, для програмистов и других сотрудныков второй график с малениким люфтом, а для себя я знаю где и какой у меня есть запас.
Когда я начинаю подсчитывать время я всегда дроблю проект на как можно мелкие задачи, ведь если вам сказать, что нужно подняться на Эверест — это покажется нереально, а важно верить и видить свою цель. Так уж сложилось у меня, что я обжегся не раз на прогнозах програмистов, поетому всегда умножаю время на 2 (для каждого програмиста коэфициент свой :), также закладываю время на код-ревью.
Когда говорю с коиентом, стараюсь выбить как можно больше дополнительного времени, но при этом обусловлюю возможность досрочной здачи, мотивирую я это тем, что лучше, чтобы мыстраховались ирасчитывали на реалистические сроки, а если пулучится быстрее от этого будет лучше двум сторонам.
Вспомнилась одна стандартная фраза для собеседования:«Выне успеваэте здать проектили задачу до установленого срока, сегодня пятница вечер, а нужно на понедельник утро, ваши действия?». Правильный ответ — поставить в извесность менеджера проектов. К этому я и приучаю своих сотрудников. Но при этом для клиента у меня один график, для програмистов и других сотрудныков второй график с малениким люфтом, а для себя я знаю где и какой у меня есть запас.
За попытку поднять тему респект. Но весь топик можно свести к принципу «Имейте запас по времени при планировании задач проекта». Если же автор имел что то другое, то увы… это осталось за границей моего понимания.
Системный подход управления рисками (методология PMbok) уже поднимался на Хабре. habrahabr.ru/blogs/pm/73571/
Системный подход управления рисками (методология PMbok) уже поднимался на Хабре. habrahabr.ru/blogs/pm/73571/
Да-да, поднимался. Посмотрите, пожалуйста, внимательно на введение. Там я указал ссылку на эту статью и объяснил, что рассматриваю проблему с другой стороны.
«Запас по времени» — это слишком общая формулировка. Каждый «запас» должен быть обоснован, иначе Вам не удастся защитить свои оценки как перед руководством, так и перед заказчиком. Как минимум, нужно быть честным перед самим с собой. В первую очередь, Вам самому себе надо объяснить, почему Вы закладываете больше времени, чем это нужно в идеальных условиях. Иногда это нужно делать в явном виде (выделение отдельных рисковых задач), иногда сознательно скрывать, распределяя между задачами.
«Запас по времени» — это слишком общая формулировка. Каждый «запас» должен быть обоснован, иначе Вам не удастся защитить свои оценки как перед руководством, так и перед заказчиком. Как минимум, нужно быть честным перед самим с собой. В первую очередь, Вам самому себе надо объяснить, почему Вы закладываете больше времени, чем это нужно в идеальных условиях. Иногда это нужно делать в явном виде (выделение отдельных рисковых задач), иногда сознательно скрывать, распределяя между задачами.
1. Так и не нашел в книге «Scrum and XP from the Trenches» тот самый подход по аналогии с которым вы предлагаете распределять работы, вызванные рисками, по другим работам. Подскажите номер страницы, чтоб я мог понять.
2. У вас статья названа «Управление рисками ПРИ ОЦЕНКЕ трудоемкости… » а по тексту вы к диаграммам ганта обращаетесь, которые обычно рисуют уже ПОСЛЕ оценки. Нестыковочка…
3. В начале статьи вы приводите примеры того, что такое риск а что не риск. А потом, в списке понятий вы не написали «что такое риск». Если есть трудности — предлагаю определение из книги Hall, Elaine. Managing Risk. Reading: Addison Wesley, 1997. «Risk is a consequence of the uncertainty in our work, not a reflection of our own ability.”
2. У вас статья названа «Управление рисками ПРИ ОЦЕНКЕ трудоемкости… » а по тексту вы к диаграммам ганта обращаетесь, которые обычно рисуют уже ПОСЛЕ оценки. Нестыковочка…
3. В начале статьи вы приводите примеры того, что такое риск а что не риск. А потом, в списке понятий вы не написали «что такое риск». Если есть трудности — предлагаю определение из книги Hall, Elaine. Managing Risk. Reading: Addison Wesley, 1997. «Risk is a consequence of the uncertainty in our work, not a reflection of our own ability.”
1. Глава: «5.2 Velocity – a useful metric for reality checks», а точнее стр. 13. Я не прадлагал «распределять работы», я предлагал распределять дополнительную трудоёмкость. В книге, на которую я ссылаюсь, нет указания поступать именно так. Аналогию я увидел только в том, как учесть неидеальность оцененной трудоёмкости. В моём случае, эта «неидеальность» обуславливается рисками.
2. Статья называется «Учёт рисков при оценке трудоёмкости ПО и планировании проекта». Обратите внимание на выделенные слова.
3. Да, спасибо за определение. Учту.
2. Статья называется «Учёт рисков при оценке трудоёмкости ПО и планировании проекта». Обратите внимание на выделенные слова.
3. Да, спасибо за определение. Учту.
Чем «Распределять дополнительную трудоемкость » отличается от «распределять работы»?
Все что я нашел на стр 13 — предлагается планировать с запасом изза неидеальности оценки. Неоригинально, но бесспорно.
Ок, сместимся от оценок в сторону планирования…
То что на трудоемкость, следующую из рисков, надо откладывать запас по времени, и этот запас можно распределять в календарном плане проекта как минимум 3мя разными способами — это тривиально.
Вы и в прошлой статье и в этой сосредоточились на оценке трудоемкости, следом за Макконелом. Макконел и правда хоть и говорит о software estimation ( что существенно шире ) в своей презентации приводит примеры time estimation.
Но риски влияют не только на сроки выполнения работ, а и на стоимость (которая складывается не только из потраченных человекочасов) и на функциональность продукта. И в крупном проекте вы могли бы это почувствовать, но из статьи как то не видно. Впрочем, если вы разработчик, то что вам стоимость?
Все что я нашел на стр 13 — предлагается планировать с запасом изза неидеальности оценки. Неоригинально, но бесспорно.
Ок, сместимся от оценок в сторону планирования…
То что на трудоемкость, следующую из рисков, надо откладывать запас по времени, и этот запас можно распределять в календарном плане проекта как минимум 3мя разными способами — это тривиально.
Вы и в прошлой статье и в этой сосредоточились на оценке трудоемкости, следом за Макконелом. Макконел и правда хоть и говорит о software estimation ( что существенно шире ) в своей презентации приводит примеры time estimation.
Но риски влияют не только на сроки выполнения работ, а и на стоимость (которая складывается не только из потраченных человекочасов) и на функциональность продукта. И в крупном проекте вы могли бы это почувствовать, но из статьи как то не видно. Впрочем, если вы разработчик, то что вам стоимость?
Статья, пардон, бесполезная. Для теоретиков.
Про риски знаю одну стоящую книгу «Вальсируя с медведями».
Про риски знаю одну стоящую книгу «Вальсируя с медведями».
Не за что извиняться. Негативный отзыв — тоже отзыв. Спасибо.
Насчёт «теоретиков». В статье, скорее, именно чисто практический взгляд. В теории так не должно быть. В теории с рисками нужно всегда бороться, избегать и минимизировать их.
На практике же (по разным причинам) не все риски удаётся победить и минимизировать. Именно поэтому их приходится учитывать.
Методы учёта рисков (помимо их митигации), описанные в этой статье, в течение длительного времени в том или ином виде применялись мной и моими коллегами на очень крупном проекте. Возможно, они не самые правильные, но они позволяли нам защитить как своих коллег-разработчиков, так и себя самих от многих проблем. В этом топике я попытался обобщить опыт и выделить ключевые направления.
Насчёт «теоретиков». В статье, скорее, именно чисто практический взгляд. В теории так не должно быть. В теории с рисками нужно всегда бороться, избегать и минимизировать их.
На практике же (по разным причинам) не все риски удаётся победить и минимизировать. Именно поэтому их приходится учитывать.
Методы учёта рисков (помимо их митигации), описанные в этой статье, в течение длительного времени в том или ином виде применялись мной и моими коллегами на очень крупном проекте. Возможно, они не самые правильные, но они позволяли нам защитить как своих коллег-разработчиков, так и себя самих от многих проблем. В этом топике я попытался обобщить опыт и выделить ключевые направления.
Sign up to leave a comment.
Учёт рисков при оценке трудоёмкости ПО и планировании проекта