Ежедневная оценка риска для вашей команды
Предположим, что вы руководите командой из 4 разработчиков. Как часто вы оцениваете риск проекта? Что вы думаете о ежедневной оценке? Считаете ли вы, что ежедневные обновления потенциальных проблем (основанные на утренних встречах с командой), публикуемые в виде короткого итогового электронного письма, являются хорошей идеей? Может быть, вы бы рассмотрели еще одну форму документа по анализу рисков, распространяемого среди вашей команды?
7 ответов
Ежедневная работа - правильно сделано - это отличный способ снизить риск для вашего проекта, потому что он увеличивает объем общения между членами команды и помогает вам обнаружить проблемы раньше. Однако противостояние не может занять слишком много времени, иначе оно само станет угрозой - люди избегают поднимать потенциальные проблемы, если думают, что это продлит встречу. Я бы не стал делать формальный расчет риска частью ежедневной проверки, но использовал бы результаты ежедневной проверки, чтобы инициировать повторный анализ при возникновении значительных новых проблем. Вы также можете запланировать регулярный повторный анализ с частотой, зависящей от степени риска, который вы имеете и готовы терпеть.
Ежедневная оценка, конечно, не очень хорошая идея, она не добавляет много ценности. Иногда не так много изменений в день в S/W. Конечно, еженедельная оценка - это минимум, а также необходимость. Я заметил, что всегда есть разница, когда еженедельный план сравнивается со статусом Еженедельный. Кроме того, любая поставка, которая пропускает две недели, становится риском или, по крайней мере, требует внимания.
Причина, по которой я против ежедневных оценок, заключается в том, что я верю в то, что разработчики могут свободно планировать и поставлять. Хотя это зависит от того, какими людьми ты руководишь.
Как разработчик, я не люблю встречаться каждое утро. Я предполагаю, что вы все еще разговариваете с командой в течение дня, и каждый член команды тоже разговаривает друг с другом. Если это правда, то все должны быть в курсе происходящего. Просто убедитесь, что если есть какие-то серьезные проблемы, вы сразу же получите информацию и проводите встречи раз в неделю, чтобы наверстать упущенное, если кто-то что-то пропустил.
Это, конечно, было бы неверно, если над проектом работает много людей и физически невозможно справиться со скоростью создаваемого кода.
Я работал над малыми, средними и крупными проектами, и я не могу сказать, что когда-либо видел обзоры рисков, проводимые менее одного раза в две недели (каждые две недели). В некоторых случаях они проводились один раз в месяц (лично дважды месяц был бы моей рекомендацией).
Ключом к управлению рисками является предоставление достаточного времени, прежде чем вы пересмотрите риск проекта. Это дает руководителю проекта достаточно времени, чтобы оценить, являются ли непредвиденные обстоятельства и миграция допустимыми, и дать группе время для принятия решения о том, являются ли риски более или менее вероятными (вероятность), и снизили ли методы снижения риска влияние любых зарегистрированных рисков.
Вам также необходимо выделить достаточно времени для лиц, которым было поручено владение одним или несколькими рисками, чтобы оценить и сообщить о мерах по смягчению и непредвиденных обстоятельствах. Другими словами, его сила в рутинном обзоре, но должно пройти достаточно времени, чтобы он был полезен.
Редактировать: Очевидно, что это не та задача, которая должна быть ограничена жестким графиком. Если это станет необходимым, вы можете запланировать анализ рисков ближе друг к другу в соответствии с потребностями проекта (т. Е. При необходимости перейти к еженедельным обзорам, а затем сократить масштаб во время стабилизации и т.д.)
Важно не упустить работу / задачи или прекратить сообщать / поднимать новые риски.
Изменить (2): Извините, я пропустил еще один аспект вопроса. Как вести отчетность / сообщать о рисках команде (и, возможно, другим заинтересованным сторонам?) -
На базовом уровне я бы сказал, что вам нужна способность записывать элементы риска и взвешивать их в соответствии с вероятностью и предполагаемым воздействием, а также иметь возможность назначать их различным членам команды (владение). Контроль версий здесь очень важен!
То, как вы это сделаете, будет зависеть от характера вашей команды / проекта и т. Д. Существует множество способов отслеживать информацию (электронную таблицу, например, которую можно отправить по электронной почте внешним сторонам), список SharePoint и т. Д. Кто-то (обычно PM) должен взять на себя ответственность за процесс, чтобы он не был забыт!
Возможно, вы захотите избежать электронной почты (IMHO), поскольку она имеет привычку не храниться или записываться правильно.
Есть много видов рисков, некоторые могут быть обработаны в вашей команде, некоторые нет. Внутри команды следует говорить в ежедневной (если вы делаете один). Однако не позволяйте вашей встрече ускользать более 10-15 минут. Если что-то требует разговора об этом более минуты или двух, стоит провести отдельную встречу только с заинтересованными людьми. Если что-то можно обработать в течение дня, просто не забудьте проверить это на следующее утро. В противном случае, напишите это на карточке, отметьте на доске, это займет несколько секунд.
Риск на макроуровне, или те, которые не могут быть обработаны одной командой, должны обновляться, по крайней мере, еженедельно. Каждую неделю я пишу отчет клиенту, риск является основным разделом этого отчета (и один клиент нравится больше всего). Чем больше вы будете играть с клиентом, тем лучше будет, если станет темнее. Всегда сопровождайте упоминание о риске с действиями, предпринимаемыми в настоящее время, чтобы минимизировать это. Пример: Низкая производительность на компьютере с менее чем X МБ ОЗУ. Мы работаем над методами Y и Z, чтобы улучшить производительность, но они опасны и подвержены ошибкам. Мы рекомендуем поднимать мин. спекуляция в ГБ ОЗУ
Первоначальный анализ рисков должен быть выполнен в начале проекта, а затем, в зависимости от сложности и общего уровня риска проекта, составить график. Ежедневный анализ рисков (формальный) кажется чрезмерным - если вам нужно ежедневно встречаться с реальными / новыми рисками, тогда проект, вероятно, необходимо переосмыслить (например, анализировать каждый шаг, который вы делаете в походе... если вам нужно это сделать тогда, возможно, поход не должен состояться. Я обнаружил, что использование одного и того же типа связи для составления отчетов (для команды) является наиболее эффективным, это сокращает переработку информации. Простая электронная таблица (Google документы) с указанием названия риска, статуса, назначенного и плана смягчения последствий.
Это кажется очевидным, но не забывайте никогда не повторять одну и ту же ошибку дважды: я видел, как в отчетах о "риске" повторялись одни и те же (явно ошибочные) смягчающие действия, которые не работали, когда тот же самый риск материализовался двумя неделями ранее. Это озадачивает меня..
Держи это по-настоящему. Если вы не знаете, как снизить риск, все равно оставьте его в списке.