项目管理中的WBS

今天听了WBS分解的培训课程，结合以往的经验，感觉理论基础还是非常重要的。以往只是闷头走，凭感觉，靠探索，碰了钉子再总结的做法，在今天理论知识的指导下，颇有醍醐灌顶的感觉。
其实，在讲的过程中，并没有举太多的案例或是项目理论，讲师根据公司业务的特点和项目特点，有针对性的介绍了WBS的重要性和做法。因为是结合公司的案例，和自身工作关系密切，所以听起来接受很快。
下面是把我自己感兴趣的内容记载下来，
一、项目目标分析
1. 问题（项目的理由）
2. 解决方案（产品的描述）
3. 质量目标

每次在做项目的时候，知道项目的目的，但是要落实在笔上，反而不好说明。现在知道了，正着不好说明的，那就逆着写。先说明不做项目，会有哪些损失？（做项目的理由出来了）要避免这些损失，可以从哪方面来解决（解决方案出来了）？怎么来考核效果（指标也出来了）

二、交付内容
这个项目完成，每个阶段的产物是什么？也就是交付物是什么？要说清楚

三、风险界定
1. 限制条件
2. 假设条件
3. 界外条件

如果不是经常做同类的项目，风险并不容易界定。很多风险都是靠经验来界定的。是否有别的（非经验）的方法？可以在做WBS的时候，就能做到

四、WBS步骤
1. 头脑风暴
2. 定结构
3. 领任务并确定时间
4. 排序

WBS的分解，是用案例的方式展开的。举的是outing的例子。 很有意思，大家都能主动参与。大家的想法都说出来后，讲师按照内容，把杂乱的内容，归类到各个总结构中。相当于是第一级。

第一级的分类，也很有说法，it公司的流程比较类似，需求-设计-开发-测试-上线-反馈。做项目，一级分类基本类似，有了模板，下一次的任务分解，主要是下面的任务更换一下就ok了

各个分类下的子任务明确后，放在WBS图表上，通过图表，一些风险问题就有可能体现出来。比如，某个模块下的任务少，可能是一些问题没有考虑到，会存在一些风险

上面讲的是头脑风暴和定结构，接下来就是领任务和确定时间了。领任务比较好定，确定时间可能会不准确。这里介绍一个“三点估算法”。期望值=（最乐观预算+最可能值+最悲观值）/3。不过，在网上查了一下，很多人觉得估算还是个经验值。

五、头脑风暴的实施
1. 先说一下头脑风暴的3不原则
不批评、不排斥、不评论
2. 计划
同心圆计划（10人以下）、交付件计划（10人以上）
头脑风暴看似很简单，就是把大家意见收集汇总。我以前就是这种想法。结果有一次我独立主持一次头脑风暴，囧打法了，当时会议室乱成一团，大家你争我仪，我一人站在前面却无法控制。归结原因，就是自己对如何管理头脑风暴不懂。

头脑风暴很重要的一点，是不要评价其他人的想法和意见，要把所有想法意见都归总，然后分门别类，这样，就可以看出来结构重点，然后再抽取精髓。这样的头脑风暴才能成功。如果攻击其他人的建议，那就不是头脑风暴了。有机会的话，我还要再练练这个