项目来源通常可区分客户合同项目、内部产品更新换代。客户合同项目由于受到客户直 接约束，有固定的工期，而且需求往往很不稳定，很多时候客户只指定一个大概的需求范围，由开发商在应标的时候列出能实现的功能需求、环境支持和开发费用， 在多家开发商应标的情况下，客户有可能综合多家厂家的功能，要求开发商实现，还有一些项目客户只提出研究方向，根本没有具体的需求细节；内部产品更新换代 需求相对稳定一些，而且工期也相对宽松，比较容易把握，但产品的需求是连续的，产品需要不停的升级增加新功能才有生命力；由于需求的稳定性不同，往往需要 比较好的开发模型来支持，否则很容易发生到了项目后期才发现实现的功能与实际应用需求不符，达不到使用效果，导致项目失败；开发模型的不同，需要管理的力 度也不同，管理花费的时间也不同；

　　下图是笔者多年总结的开发模型选择经验：


　　·瀑布模型因为需求稳定，实现细节明确，只要需求理解正确，设计没有出现大的错误，基本上按照需求分析-》设计-》编码-》单元测试-》集成-》集成测试-》验收-》发布走下来，过程任务明确，很少出现文档代码重复评审的情况，开发人员可以专心地按阶段进行开发工作，管理也非常简单，只要把握好每个项目成员的进度，基本上可以确保完成任务了。

　　·原型演化模型因为需求不稳定，实现细节不明确，很多东西需求摸索之后才能明白怎么做、能否实现，这个时候需要快速地做出原型，在做原型的时候确定技术要点， 分辨这些要点以现有项目组的水平是否能够按时完成，如果无法完成，需要向客户解释为什么，对有可能出现技术延误的功能需要提前取得客户的谅解，以便以后追 加费用或者放到二期完成，因为在项目开发过程中需要不停地与用户交流，修改需求、设计、代码，工作量比较难估计，项目追踪难度高，这个时候项目经理需要建 立需求矩阵、风险列表，一项一项的解决问题，协调项目成员，不停调整项目计划保证后面的工作评估尽量贴近实际，以免失控，管理工作将占项目经理大部分时 间，可以说在这三个模型中项目进度是最难把握的。

　　·喷泉模型适应于产品升级开发，产品不停地更新换代，不断的增加功能，通常不会一下子全部实现所有功能，最好是分期实现，降低风险，早日回收开发成本，这种开发-》测试-》发布-》开发-》测试-》发布的螺旋回溯式开发继保证了产品的延续性也保证了产品的稳定性，管理灵活，暂时实现不了的需求可以推后等技术成熟的时候在立项完成，管理难度中级，并且这种模型在测试人员足够的情况下可转为测试驱动型开发，项目经理重点关注每天实现了哪些功能、出现了哪些Bug,可动态每天安排工作。

　　·瀑布模型的关键要素理解需求和架构设计，原型演化模型的关键是快速原型和管理协调，喷泉模型注重需求分期稳定实现和测试，总之选择适当的开发模型可优化工作 安排，更好地调配资源，关注开发模型中的重点工作要素。（在现实中，由于受限于公司制度和资源，很多时候项目经理无法自由选择开发模型，很多公司没有测试 人员，评审流程僵化，无法承受原型演化模型管理要求）

　　人员控制
　　无论是哪种开发模型，都 必须贯彻“以人为本”的原则，拉动开发人员工作积极性是保证项目顺利完成的重重之重，每一个人都希望自己的劳动成果得到别人的尊重，因此经常表扬项目成员 中做得比较好是一个美德，非常容易做到，经常质疑成员的能力不信任成员常常是项目失败的主要原因之一；项目经理需要时不时主动向开发人员询问进度、有没有 问题，不应该等待开发人员汇报问题，很多项目经理把问题归结于开发人员没有主动汇报是不对，往往等到开发人员汇报的时候问题已经非常严重了，不要轻率认为 开发人员能够及时发现所有问题；在项目开发中，安排成员做错误的事情是大顾忌，不但做的人没有成就、没有绩效，也会影响领导威信；每天了解所有成员的进度 是好事，既能拉近人员之间的距离，也能更好的把握人员的状态。

　　可采用一些工具来简化组员的汇报工作，让开发人员专注于开发，不要让组员多重汇报，多重汇报会让开发人员非常不耐烦，也占时间。（我曾经就碰到一个主管，在公司要求的每日工作汇报上还要写项目工作汇报文档又要在一个dotProject的工具上填写，最后还要更新Project文档，还把这些工作当作重点考核，真是不厌其烦）

　　时间控制

　　在三种模型中时间的控制 要求是不同的。瀑布模型阶段清晰,保证每一个阶段能按时完成即可以顺利完成项目，原型演化模型就不是那么好控制了，应该以功能划分，精确控制每一个功能的 完成时间才能顺利完成项目，对难度特高耗时长的功能要做好无法完成的准备，确定不能完成的功能要尽早与客户沟通放弃，喷泉模型要求比较松，一般以功能划分 时间，也可按需求、设计、编码、测试来划分。总之“先紧后松”是原则，在项目前期尽量多做工作。如果最好能够把开发人员的时间安排到小时，控制开发人员每 小时的工作，在估计时间的时候不要考虑加班的情况（有些项目经理很极端的，项目一开始就考虑加班，也不知道是不是在领导面前表示项目很紧张），否则真的需 要额外时间就很麻烦了。

　　需求管理

　　几乎所有的人都认为需求很重要，确实需求是立项的关键也是产品推广成功的关键要素，怎么能不重要呢！所以需求是一定要管理的，确定需求的范围项目开发首先要做的事情，尤其是原型演化模型必须建立需求矩阵，一条一条地解决需求不明的问题。

　　风险控制

    需求不明是最大的风险，其次是人员风险，其他硬件资源、软件工具资源也是风险来源，与用户良好互动，与组员融洽协作是解决风险主要办法，硬件资源、软件工具资源解决的手段很多，注意不要成为进度的绊脚石。