引言
凡事预则立，不预则废。项目策划作为项目正式开始后的第一步工作，决定了今后项目的走向和成败，其重要意义无需多言。然而在实践中，相当多的项目策划只是在表象上满足了一些标准模型或者公司体系，使得项目策划流于形式。作者就项目策划几个常见问题分享自身经验，并结合笔者所在飞创公司的实践给读者一些启发。
在项目管理处于起步阶段的组织中，对项目策划的认识常常仅局限于进度表。CMMI模型对项目策划阶段的成果物范围给出了明确指导。在飞创公司（CMMI5级成熟度），一份全面的项目策划内容通常应包含：定量管理计划（含项目目标及达成策略）、根据组织标准过程集（OSSP）进行项目过程裁剪形成项目定义过程（PDSP）、工作任务分解（WBS）、项目估算、进度表、环境管理计划、关键依赖计划、测试计划、沟通管理计划（即干系人管理）、培训计划、风险管理、度量计划、配置管理计划、QA计划等。
如果项目管理人员不能理解为什么要做这些计划，或使用了错误的方法，仅仅在表象上完成了项目策划工作，自然无法发挥策划的作用。根据笔者参与的近百个项目经验发现，项目目标管理、项目生命周期模型选择、项目估算、干系人管理等过程虽然看似简单，但也经常会成为项目策划中的薄弱环节。
一、目标管理：要目标驱动，而不是随波逐流
项目目标是项目努力的方向，一个成功的项目应该以目标为导向，而不是随波逐流、“打哪指哪”。目标决定了项目实施的策略。例如一些对质量要求非常高的系统，会以上线后零缺陷作为目标，这就决定了项目在开发、测试、上线等环节要采取非常严格的实施方案。目标可能来源于两个方面：组织目标、干系人期望。而后者是实践中最为常见的目标来源。在进行项目目标管理时，经常出现的问题主要有：
1）只有主观目标，无量化目标。主观目标在判断是否达成目标时容易引起歧义，而量化目标精准客观，由此制定的实施方案自然而言的更有针对性。
2）未识别目标优先级。项目当然期望在各方面都达成目标，但是目标之间出现冲突也是常有之事。质量目标第一、进度目标其次、成本目标最次是较为常见的目标排序。在这种目标排序下，当项目组发现质量存在风险时，可能会采取延期或加大投入（例如增加测试）等策略。
3）只有目标没有实现策略。如果没有将目标实现策略进行清晰的阐述，目标管理仍然流于形式，这也是目标管理中最为常见的问题。典型的目标管理策略必须是可执行且无二义性。如果你看到的目标实现策略类似于“加强单元测试和集成测试”，该策略显然无法执行。如果目标实现策略是“单元测试100%语句覆盖，集成测试覆盖全部内外部接口”，任何人都会清楚该怎样实施。
在飞创公司，项目组使用定量管理计划进行量化的目标管理。计划主要包含以下几个部分：
1、目标分类（质量/成本/进度）
2、目标项（缺陷密度/生产率/延期率等明确的计算公式）
3、组织级基线（组织级PCB中的上限、中值、下限作为参考值）
4、项目目标
5、CPK（表示过程能力的高低，用于评价目标达成能力的指数，当CPK<1时，表示项目目标达成存在风险，需要制定目标达成的措施。）
6、目标设定的理由及达成目标的措施
7、目标跟踪人(谁来负责跟踪此目标)
8、目标跟踪频率（里程碑/某活动完了）。
此计划依赖于组织级有大量可用的历史数据积累，形成组织级基线供参考。成熟度低的组织无法形成有效的组织级基线，如果希望尽可能给组织提供参考基线，可采用一些业界通用的指标给项目组参考（例如验收测试缺陷密度低于0.2个/千行），或者使用竞争对手的指标数据等做法都是常用做法。
二、生命周期模型，你选对了吗？
项目生命周期模型，可以简单理解为项目各个过程之间的衔接，对项目是否能达成目标起到至关重要的作用。最常见的生命周期模型有：瀑布、增量、迭代。
1）瀑布模型要求需求、设计、实现、测试等过程按顺序进行，只有上一个工程完了之后才能进入下一个工程。这种模型的弊端是：只有在项目结束后客户才能真正看到软件。因此更加适用于需求清晰、需求变更可能性低、技术风险低的项目。如果项目特点不符合上述特点，可能就会带来大量的返工，不但成本面临超支，而且质量和进度都存在风险。
注：飞创公司在维护性开发（指在原有系统基础上进行升级改造）的项目中，一般都会选择瀑布式模型。这种项目的特点是具有成熟的架构，以客户需求相对明确。为了弥补“客户只有在最后一刻才能看到可运行软件”这一不足，一般会采取“通过demo演示，邀请客户对需求和设计文档进行评审、里程碑总结”等多种方式降低风险。
2）增量模型的特点是，需求一次性完成，然后将需求分批进行开发。每一批开发都要完成一个完整的设计、实现、测试，因此每批开发都是可交付客户使用的。这种模型带来的好处是：客户能够较早的使用到软件，尽早满足客户高优先级需求，为客户实现业务价值。因此这种模型适用于需求清晰、需求变更可能性较少、客户对于尽早使用软件有较强意愿。
3）迭代模型在敏捷开发流行的今天也较为常见。它与增量模型的区别是，每个迭代都在不断完善需求、设计、实现、测试。迭代模型的本质是，让客户对每个版本进行体验，项目组通过客户真实的体验和反馈来摸清楚真正的需求，并通过重构来完善技术架构。因此，客户的参与对迭代模型能否成功非常关键。迭代模型适用于需求和技术架构都不明确的项目。这种模型的风险是，如果早期版本质量不够好，会影响到客户对质量的印象。
注：飞创公司在对市场的产品开发项目中，经常使用的模型是迭代模型。这种项目需求都相对模糊，变更频繁，架构也是需要逐步完善，一些市场客户也比较愿意通过试用新产品来配合公司进行产品的需求和架构验证，因此迭代模型是比较好的选择。这种看似灵活的模型在给予项目组更多发挥空间的同时，也要求项目对每个版本有明确的规划。比较常见的版本规划方案是，在首个版本完成基本的架构以及产品的重要核心功能，后续版本按照客户反馈来继续完善功能和结构。
三、项目估算，永恒的主题也是难题
项目估算的最终目的是估算工作量，为排定进度表提供依据。没有估算就无法保证进度计划的合理性，在进度管理时也无法有效使用挣值管理方法，而且在排定进度表时，极易导致资源分配不合理。常见的项目估算通常分为三步：
1）进行工作任务分解（WBS）；
2）针对WBS的每一个叶子节点进行规模估算；
3）通过规模与效率值计算出工作量。
有的组织会省略第二步，直接对WBS的叶子节点进行工作量估算，最后将每个叶子节点的工作量求和得到总工作量。
无论使用哪种方法，在估算过程中都可能会遇到一些常见问题，笔者将结合自身经验给予解答：
问:WBS究竟应该分解到什么程度？
答:WBS分解的越细，对项目范围的管理越准确，项目估算结果也会越准确。但是，项目估算活动本身也需要时间成本，项目经常因为来不及对需求做深入了解而无法进一步拆解WBS。笔者推荐根据每个叶子节点的工作量估算结果来确认WBS是否分解到位。飞创公司要求项目每个叶子节点的工作量尽可能不超过5人日，最长不能超过2周。这是因为进度表经常使用WBS的叶子节点作为一条任务。一般情况下，项目至少每周要跟踪一次进度。如果你的老板或客户要求你每天都需要做进度跟踪，那么只有将WBS拆解到叶子节点1人日的粒度。
问:如何进行规模估算？
答:常见的规模有代码行、FP功能点。除此之外，一切你能数出来并且能估计出效率的度量项都可以用来作为规模进行估算，例如页面数，button数，use case数。即使两个成果物的规模相同，工作量也可能会有较大差异。因此针对不同类型的成果物，还会使用诸如“难易度”等属性加以区分。飞创公司以代码行做规模，并且将代码行进一步区分为前台页面代码规模、数据库代码规模、后台代码规模，其目的就是避免同一规模的代码生产效率差别较大，造成估算误差。
问:有没有既科学又不太复杂的方法能够指导估算过程？
答:宽带Delphi法、PERT法、类比法、专家法都符合这一需求。需要注意的是，大部分宣称使用专家法的项目都在错误的使用这一方法。专家判断法可以按照下面的步骤执行：
1）召集人提前将估计所用的输入资料，如项目需求，估计书（估计书中应该已填写负责初始估计的专家（简称专家1））等发给所有参加估计的专家，所有专家应该提前熟悉所有的资料；
2）专家1应提前完成所负责估计的成果物的规模估计；
3）召集人如期组织所有专家召开估计会议；
4）专家1应在估计会议上向其它专家介绍个人估计结果并说明估计理由；
5）其它专家提出各自的意见，大家要充分讨论理解上的差异直到达成共识；
6）根据集体讨论的结果给出最终的调整估计值；
7）召集者记录最终估计值，必要时记录相关估计说明。
从上述专家法的标准步骤来看，很多项目只是专家在进行估算，而并非真正使用了专家法。
问:需求不明确，估算的不准怎么办？
答:估算的技术和方法是无法解决这种问题的。如果需求不明确，即使再有经验的专家也无法做出精确估算。对于这种项目，笔者建议尽早和相关方明确提出需要进行多次估算。如果想要获得比较精确的估算值，并且估算的时间又不能太晚时，在项目需求规格确定后再次进行估算是一个比较好的选择。
四、干系人管理也要有套路
干系人管理意义在于通过对干系人施加影响，减轻干系人对项目产生负面影响的可能，提高产生正面影响的几率。干系人管理一般分为两步：
1）识别干系人；
2）制定干系人管理计划。
飞创公司为便于项目组进行干系人识别，将干系人从来源上区分为“项目组内部”、“公司内部”、“客户”、“第三方”四种类型，并要求项目组制定不同的沟通策略，以实现有效的干系人管理。
根据干系人的需求或期望来制定相应的管理策略。一般可以采用干系人分析矩阵制定不同的策略。如下图：
一般情况下，对于权力高利益高的干系人，项目将会尽可能的满足其需求。对于权力高利益低的角色将会进行重点管理。对于权力低利益也低的干系人，将会采用观察策略。对于权力低利益高的干系人将会密切保持沟通。
总结
好的项目策划应该是在项目管理团队积极思考之下制定完成的，而不是单纯为了满足QA或者组织体系要求。因此，做项目策划必须要走心。同时，运用好的策划方法能让项目策划如虎添翼，也能增强项目策划的可信度。
然而项目计划做的再完美，始终逃离不开项目具有渐进明细这一基本特性。当前软件行业，无论是从事互联网开发，还是业务系统开发，很难见到计划一次性就能全部制定完的情况，滚动式的计划越来越普遍。因此，计划逐渐成为了贯穿项目始终的一项工作任务。只有我们掌握了更好的技巧，少走弯路，才能让这项重要工作事半功倍。
