PM工作中常见问题及解决方法

http://blog.csdn.net/cutesource/article/details/5685537

如何在一般情况下进行工作量的评估？

• 类比估算法：根据类似的项目工作量进行预估，再对估计值根据具体情况进行调整。

• 参数估算法：我们公司可能缺乏这方面的数据支持，比如通过估计某个项目可能会有的代码行数，配备的成员技能，来进行估计。举个例子，某个项目的代码行估计可能会有10000行，一个一般技能的开发工程师一天可以完成的代码行为500行，那么开发需要的时间可能就是20人日。
  

• 三点估算法：目的是为了尽量降低估算的不确定性。估算时对一个功能点分别估算最悲观的估算值、最乐观的估算值、最可能的估算值，最后确定的估算值=(最悲观的估算值+最乐观的估算值+4*最可能的估算值)/6。

• Delphi法：由一组专家对项目进行估算。
  具体的步骤为：
  1，组织者发给每位专家一份软件系统的规格说明合一张记录估算值的表格，请专家估算。
  2，专家详细研究软件规格后，对该软件提出最乐观的估算值、最可能的估算值和最悲观的估算值。
  3，组织者对专家表格中的答复进行整理，计算每位专家的平均值E=（最悲观的估算值+最乐观的估算值+4*最可能的估算值）/6，然后计算出期望值：E=(E1+E2+....+EN)
  4，综合结束后，再组织专家无记名填表格，比较估算偏差，并查找原因。
  5，上述过程重复多次，最终可以获得一个多数专家共识的软件规模。
  

• 团队估算法：类似与Delphi法，但是形式比较松散，参与评估的团队成员包括项目组的各个角色，大家一起对某一个功能点提出自己的估计值，如果比较接近则计算一个平均值作为估算值；如果差别比较大，则由每个人发表意见说明自己的评估理由，然后进行第二轮评估，直到评估值比较接近。

• 计划扑克：Delphi法的一种演变。敏捷扑克的每种花色均是一组13张牌组成的估算扑克牌，牌正面上印刷有供估算用的数字与符号，数字分别是1/2，1~10和20，符号为“！”，代表一些未知情况，如无法提供准确估算值等。一般我们推荐4到8人参与估算；人数太少，会使估算结果偏差很大，人数太多，会拉长估算时间，降低估算效率。估算时，我们经常会估算相对值，而不是绝对值。注意不要深入研究代码编写细节，这些是实际开发是再去解决的问题。一般情况下，最多3轮就可以得出一个比较统一的意见。如果3轮之后依然没有得到一个统一的意见，比如第四轮出牌结果依然是2，5，5，8；那么Scrum Muster应当立即中断该条目的估算，取平均值或其他大家比较能接受的值作为估算结果。没有任何一种估算是高可靠度的，扑克也不例外，扑克估算的目的就是为了能够在一个尽可能短的时间内，让团队成员更加多的了解需要做的工作，同时顺带得到一个可接受的估算结果。

其实每一种估算方法都仅仅是估算，估算的结果就可能是不准确的，所以首先不要有概念估算的结果和实际的结果一定是一致的。估算时项目经理要根据具体情况灵活运用各种估算方法，综合各种方法所长，让估算结果尽量接近实际值。

如何在需求不明确情况下进行工作量的评估？

• 给量级的评估，由于需求不明确，所以估计不可能准确，误差很可能比较大。

• 储备：储备要留足，需求越不明确储备越要多。

• 先总后分：需求不明确也要有一个限度，项目的整体范围，整体框架还是要确定了才能接手项目的。

• 接受计划改变的必然性，既然需求不明确，那么计划的改变可能性是非常大的，需要提前和相关各位沟通到位。 

如何在跨部门情况下进行工作量的评估？

• 各个部门负责给出自己部分的工作量评估。

• 有专门的接口人负责协调资源，给出评估结果。

• 信任，很多时候我们并不了解对方的工作和流程，所以信任很重要。

• 信任的同时，尽可能多的了解对方的工作内容，积累经验，对未来的判断做准备。 

如何进行进度计划的安排？

理论基础：PDM(单代号网络图)，关键路径法和关键链法，时间提前量和滞后量。

具体步骤：

• 首先细分项目的每个功能点，针对功能点制定出我们需要进行的工作。

• 整理每项工作之间的逻辑关系，形成一个网络图。

• 评估每项工作的工作量。

• 安排每项工作对应的负责人。

• 根据具体负责人以及工作量调整网络图。

• 安排储备工作时间。

• 排出具体的进度计划

需求变更如何处理？

• 事前：
  丑话当先，变更流程还是要有的。
  变更流程可以分需求变更的规模，按大、中、小来区别对待，制定不同的流程。
  

• 事中：
  执行过程中可能需要灵活应对了，对于需求的优先级和紧迫性需要有一个把握 。不是不能变，但对流程还是要坚持的，否则乱了只能是自己。如果发布时间不能改变，需求又是一定要完成的，那我们就只能从其他方面来想办法了。这个可以参考六边形。
  

• 事后：
  对人对事进行总结，未来对于类似的事情，相同的人，我们就需要更多的考虑需求变更的风险了。

对于前期需求不明确的项目如何控制需求范围？

• 前期需求的细节可以不清晰，但是整个项目的大范围需要确定。

• 项目的整体设计最好不要迭代，或者说不要做迭代的打算，一开始就对整体设计做一个统一的规划。

• 整体设计完成后，再对每个部分的功能分别来看。划分每个部分的系分功能点，各个功能点之间的优先级，是否需求已经明确，与其他功能点之间是否有关联等。

• 对已经比较清晰的功能点，并且与其他功能点之间的关联不是非常紧密的，先进行开发、测试。同时细化未清晰的功能点。

• 对于需求变更的控制重点把控。

• 这需要看项目经理的全局观，是否能对项目的整体设计，功能点间的关联关系有一个比较到位的把握。