风险作为一门科学诞生于16世纪的文艺复兴时期，它源于意大利的“risicare”，意思是“敢于”。1955年，美国宾夕法尼亚大学沃顿商学院——施耐德教授，第一次提出了“风险管理”的概念，且适用于各行各业。

大多数IT圈中的管理者，都存在这样的侥幸心理：“风险发不发生，尚且未可知，花那么多精力做风险管理，没这个必要吧……”

风险管理的过程，是风险的可视化过程。风险可能无处不在，但风险管理更应有的放矢。

尽管我们可以借助历史经验、数据分析，使得策划越来越贴近实际。然而，在丰满的理想面前，现实总是显得骨感了一些。而监控管理才是项目的实际情况。策划作为监控的输入，明确了监控什么，在执行发生显著偏差后，需要采取纠正措施，并更新计划。
因此，“在项目开发的整个生命周期里，策划不仅仅只有一个计划表，也并不是一次性工作。”策划与监控形成的管理闭环，才是保障项目按时、按质、按量的核心。因此，今天的主题是软件项目的监控管理。

工作经验告诉我，很多PM都觉得带队这个事，是个“所谓重要”，但“一定不紧急”的事。可我又常常听到PM说“人手不够，公司又不招人，只能天天加班”。于是乎，我决定聊聊带队这个事，毕竟“一个好汉三个帮”，一个项目必然要靠大家啊~

需求不是魑魅魍魉，需求管理解决方案也没有Bug，需求仍然做不好，是因为你没有运用设计思维，“像设计师一样思考”。

需求啊，需求……谁人欢喜，谁人愁……今天，我们就说说软件开发的需求管理。

作为一项兼顾长短期利益的工作，度量不是几张表单就能搞定的。按照我们今天所讲的内容，你需要（拿出小本本记下来呦~）

一、确定度量的目标。
二、结合特定的项目与度量目标，匹配合适的度量项。
三、 按照3 Tips，对选择的度量项分别进行梳理。
四、坚持下去。
五、遇到问题，寻求专业人士的帮助。

看，PM如何利用项目计划，打赢与市场和老板的“翻身仗”！

时间估计不足，导致的软件项目失败，比其他所有原因导致的项目失败加在一起还要多。——Frederick P. Brooks Jr. 写于20世纪70年代

进入90年代，Capers Jones也在他的报告Applied Software Measurement：Global Analysis of Productivity and Quality中表示，“过度紧张的、或不合理的进度表，可能是对所有软件项目最具破坏力的影响因素”。

无论是时间估计不足，还是不合理的进度表，全指向了软件估算。因此，准确的软件估算是进行合理计划项目、推进项目、顺利完成项目的基石。今天，我们就来说说这个话题。

尽管说话的艺术对沟通有极大的帮助，但我们无法奢望每个人，都成为语言艺术的大师。因此，在工作的环境中，我们要求的沟通与协调是以完成工作为目标的。
为了达成这样的目标，同时减少语言艺术等因素带来的干扰，我们要将沟通与协调定义到基本的工作过程中去，并进行管理和优化。

对配置管理的系统梳理：

目的：在软件项目生命周期中，维持工作产品的完整性和一致性，减少由配置问题引起的混乱，提高软件开发生产率，降低成本。
核心：管理变更
关键实践：
- 最简易的配置管理——版本控制
- 配置管理策划
- 软件项目中到底什么应该受控？——配置项
- 符合项目需求的配置管理系统
- 建立和发布Baseline
- 配置管理真正的核心过程——跟踪和控制变更
- 软件开发过程的“库存盘点”——配置项状态报告
- 配置和QA的深度合作——配置审计

尽管过程管理一直在优化工作任务对目标的支撑程度，细化过程管理的颗粒度——“最小单元”。但技术型的行业特性，会导致所谓的“最小单元”也仍然存在一定独立性，需要人来发挥自身的聪明才智。

因此，在领导能力方面，贯穿始终的一个目标，就是利用各种手段，不断的开发与提升人员和团队的能力，使之可以充分服务于项目目标和公司目标。

今天这期节目，我们完成了PM核心能力架构的五个成熟度等级的阐述。从1级的建立正确的管理意识；经过2级、3级，不断深化PM的管理精准度，以4级的量化数据为依据，促进5级持续不断的正向改进循环。