您团队的每日风险评估

Question

假设您领导4位开发人员的团队。您多久会估算一次项目的风险？您如何看待每日估算？你认为每天更新的潜在问题（基于与团队的早间站立会议）作为简短的摘要电子邮件发布是好主意吗？也许您会考虑在您的团队中传播另一种形式的风险分析文档？

Answer 1

每日站立 - 完成正确 - 是降低项目风险的好方法，因为它可以增加团队成员之间的沟通，并帮助您更早发现问题。但是，站立不会花费太长时间，否则它本身就会成为一种威胁 - 如果人们认为会延长会议时间，就会避免提出潜在的问题。我不会将风险的正式计算作为每日站立的一部分，但会使用每日站立的结果在重大新问题出现时触发重新分析。您可能还希望根据您拥有并愿意承受的风险程度安排频率的定期重新分析。

Answer 2

作为开发者，我不喜欢每天早上开会。我假设你在白天仍与团队交谈，每个团队成员也会互相交谈。如果这是真的，那么每个人都应该非常清楚正在发生的事情。只要确保如果出现一些重大问题，您可以立即获得通知并每周开一次会议，以便在有人遗漏某些内容的情况下弥补进展。

如果有很多人在使用该项目并且无法在物理上弥补生成代码的速度，那么这当然是错误的

Answer 3

每日估算肯定不是一个好主意，它不会增加很多价值。有时在S / W中一天没有太大变化。 当然，每周估算是最低限度，也是必须的。我观察到，每周计划与每周状态进行比较时总是存在差异。任何错过两周的可能性都会成为风险或至少需要注意。

我反对每日评估的原因是因为我相信给开发者提供计划和交付的自由。但这取决于你所领导的人的类型。

Answer 4

我曾参与过小型，中型和大型项目，我不能说我曾经看过每两周（每两周）进行一次不到一次的风险评估，在某些情况下，它们每月进行一次（个人每月两次将是我的推荐。）

风险管理的关键是在重新审核项目风险之前留出足够的时间。这为项目经理提供了足够的时间来评估意外事件和迁移是否有效，并让团队有时间决定风险是否或多或少（概率），以及风险缓解技术是否减少了任何记录风险的影响。

您还需要为被分配了一个或多个风险所有权的个人分配足够的时间来评估和报告缓解措施。突发事件。换句话说，它的优势在于通过例行审查 - 但是必须有足够的时间才能使它变得有用。

编辑：显然，这不是那种应该限制在严格计划中的任务。如果有必要，您可以将风险评估更紧密地安排在一起，以满足项目的需要（即，如果有必要，转移到每周评论，然后在稳定期间缩减等）。

重要的是不要让工作/任务失效，或停止报告/提出新的风险。

编辑（2）：对不起，我错过了问题的另一个方面。如何处理向团队（以及其他利益相关者）报告/传达风险？ -

在基本层面，我要说你需要能够记录风险项目并根据概率和估计影响权衡它们，并且还能够将它们分配给各个团队成员（所有权）。版本控制在这里至关重要！

如何执行此操作将取决于您的团队/项目的性质等。有很多方法可以跟踪信息（电子表格，例如可以通过电子邮件发送给外部各方），SharePoint列表等等。 （通常是PM）必须拥有该过程的所有权，以免被遗忘！

您可能希望避免发送电子邮件（恕我直言），因为它有一种不能正确存储或记录的习惯。

Answer 5

初始风险分析应在项目开始时进行，然后由项目的复杂性和总体风险水平决定，制定计划。每日风险分析（正式）似乎过度了 - 如果你需要每天见到真实/新风险，那么项目可能需要重新思考（比如分析你徒步旅行的每一步......如果你需要那么做也许加息不应该发生。我发现使用相同类型的通信来报告（向团队）最有效的报告，它减少了信息的重新处理。一个简单的电子表格（谷歌docs）具有风险名称，状态，分配和缓解计划就足够了。

Answer 6

有很多种风险，有些可以在你的团队内部处理，有些则不能。应该在每天讨论团队内部（如果你做的话）。但是，不要让你的会议超过10-15分钟。如果某些事情需要谈论它超过一两分钟，那么仅与有关人员单独会面是值得的。如果可以在一天内处理某些事情，请记得第二天早上检查。否则，将其写在卡上，在电路板上标记，这需要几秒钟。

宏观级别风险或仅由团队无法处理的风险应至少每周更新一次。每周，我都会向客户写一份报告，风险是本报告的主要部分（而且客户最喜欢的一部分）。你和客户一起玩的越开放，如果事情变得更暗，事情就越好。始终伴随着风险提及当前采取的行动，以尽量减少这种风险。 例如：低于X MB RAM的计算机性能低下。我们正在研究方法Y和Z以提高性能，但这些方法存在风险且容易出错。我们建议提高分钟。规范。到W GB的Ram

Answer 7

似乎很明显，但要记住永远不要犯同样的错误：我看到“风险”进度报告重复同样（明显有缺陷的）缓解行动，当完全相同时不起作用风险在两周前实现。这让我很困惑..

保持真实。如果您不知道如何降低风险，请将其保留在列表中。