我们到底要做多细的计划

有人说计划就是要细，精确到小时，这样才可控。

有人说计划赶不上变化，手中无计划做到心中有计划即可。跟着变化走就是计划。

作为一个管理人员来说，他肯定是希望实时的监控到项目的进展，能及时发现风险。有些管理人员恨不得半天报告一次进度，可能在某些行业中，这种做法是必须的。但是我个人认为在IT行业中半天做一次进度报告，未免有点夸张。

计划到底要多细，以下是我个人对制作计划颗粒度的一些理解和看法，如有不对之处，请指出，勿拍砖。（注：本人长期从事的是产品开发，对软件产品开发有一点一点的心得。）哈哈哈^_^

第一点：计划是必须要有的。没有计划就没有目标，没有目标就没有动力，没有动力整个项目就像是一潭死水，随时面临挂的风险。我个人认为产品的开发应结合瀑布式开发和敏捷开发。而不是仅仅依靠一种模式。瀑布式开发周期比较长，开发完成了，产品也过时了。敏捷开发在做项目时比较合适，但是在做软件产品开发过程中一味的强调敏捷，会带来产品的定位不准，给产品的核心价值带来迷茫。因为我认为将两者结合是不错的选择，瀑布式开发指定好产品的定位以及核心技术，用敏捷开发来快速响应软件产品定制的功能需求。

第二点：软件产品首先得制定大的方向，定期提出新的产品概念。这些概念需要结合市场并得到反馈的，同时销售部门也需要时间去灌输这种概念，因此这种概念得提前很长时间。

第三点：根据大的方向将产品开发拆分成多个里程碑，根据里程碑来制定相应的计划。我个人觉着结合产品功能的优先级以及一个季度的开发周期等因素制定软件里程碑是一个比较合理的模式。因为在产品的开发过程中你会有接受到来自四面八方的用户一些需求和理念，用一个季度做为一个时间段来吸收和消化这些需求是不长也不短的。如果没有什么重大需求变更或增加，里程碑尽量不要推延，因为里程碑推延往往会给其他部门（例如：销售部，产品实施部）带来不便。如果期间遇到大的需求改动，有两种方式解决：

A、加班。我想在大部分的IT公司，都是选择这种方式的。我个人是比较反感加班的，我一般要求高效率的工作，因此我一般都是采用第二种方式。（当然必要的加班是不可避免的）

B、 在满足必要功能的前提下，将其他开发计划顺延到下一个里程碑中。

第四点：根据里程碑再进行拆分成月计划。

第五点：将月计划拆分成周计划，周计划相对来说是比较灵活的。个人认为计划拆分到周计划颗粒度是比较合适的，太短的计划作为管理人员你得花更大的心思去做，太长的计划很难控制到开发进度。在做周计划时，应尽量将优先级高的功能放在前期，因为在开发过程中随时会面对用户一些紧急需求更改，为了不影响整体软件的功能。

第六点：周计划实施完后，总结是不可避免的。每周的部门例会花30分钟来总结是很有必要的，在汇报的同时，也锻炼了下属的演讲能力。

转载于:https://www.cnblogs.com/foolishfox/archive/2011/07/27/2117921.html