推荐订阅源

写给未来的自己看，文档逐步更新中。。。

当前国内企业都面临的相同的问题，项目周期短、需求变化多，为了占领市场都要求项目能够短、平、快，这样给项目

管理带来了很大的挑战，从我经历的几个项目来看就是遇到了这些问题，也在这些问题上了很大的亏，今日得闲将之前

的经验教训进行一次总结。

一、正常，按照项目计划上线的项目

1. 确定需求范围（Scope），详细理解需求并给出需求分析文档

　　业务提出的需求，往往是只关注本次的需求点，他们并不关心程序系统中，因为这个需求所涉及到的开发的部分，

例如：本次需求需要增加一个属性（如：用户备注）到订单中，业务人员只会关心备注在什么预订环节加入，格式是什么

但确容易忽略其他地方的影响，如果我的账户中订单管理是否需要进行修改，及下订单后对后续自动确认流程的影响等。

这些影响点都是需要了解系统和了解需求的项目管理者来进行评估，一旦这个地方没有想到就会对后面评估工时，开发程序

造成很大影响，也许在都会影响到测试阶段，这时候回头在对遗漏的问题进行补充开发，是已经很郁闷的事情，而且往往因为

比较紧急开发质量就会下降。

2. 通过需求分析文档，充分估计好工时，测试工时测试相关人员给出

　　业务需求一定要进行详细的分析，并形成详细的文档说明，此文档即可以以此来评估详细的工时情况，也为设计开发做依据，

还可以为测试人员的测试用例等提供详细的依据，一般在国内的一些公司，大的项目才有详细的分析文档，我的建议项目无论

大小都还是需要一个详细的分析文档的，因为往往业务的需求文档只是业务人员在以业务运营为中心，或者已项目赢利为中心

编写出来的文档，并不是真正能拿过来给设计、开发人员开发代码使用的，需求分析文档要从系统的角度将业务的需求转化为

设计开发使用的文档。

　　充分估计工时是否非常重要的，而且估计工时切忌一点就是工时估计不足，导致给后面的开发带来很大的压力，从我的几个

下项目来看我自己的工时估计就是偏紧，有几次都是把工时给估计不足，导致后面的开发加班、测试阶段也要加班，到最后质量

也不是很高，也给项目上线带来了很大风险，当然我也知道别不估底了，可是为什么还会估计不足呢，我总结了一下，主要还是

没有一个详细的文档分析，没有把每一项开发内容都一一列举出来再估计工时，这就会导致一旦以一个大目标来估计工时，一般

来说都是偏低的，因为没有详细分析一定会有遗漏的地方，这个是我的工作经验告诉我。开发工时能正确评估出来后，测试要给

出合理的测试工时。 

3. 制定好项目的详细开发测试计划

　　制定好详细的开发测试计划，详细的开发计划在项目管理中是否非常重要的一个环节，这是一个项目的控制的主线，详细的

开发计划给项目以很好的指导作用，那如何才能制定一个详细的开发计划呢，我一般从各个环节详细的开始，第一需求分析、

第二概要设计、第三详细设计、第四开发阶段、第五测试阶段、第六部署阶段。

我们重点说说开发阶段的控制：

 　 （1）分配组内成员的开发内容，在小型的系统中，或者未分层的系统中，我们都是按照一个功能点由一个人从前端到后端统一

进行开发，这个好处是功能和工作划分比较明确，但是不好的地方也是挺多的，首先层次划分会出现问题，导致分层和层次功能

不明确，有些逻辑层的逻辑可能就会到了前端展示层去了，这就破坏了层次结构，另外因为是一个从前端到后端都要做开发，这样

要求的开发人员的技术也是比较高，从当前的IT发展来看，术业有专攻，能将层次分开，使用不同长处的人才才是比较好的开发团队

本次我们采用MVC的架构，实现了前后台开发分开。

      （2）开发过程进行CodeReview工作，CodeReview是一个贯穿一个整个开发过程中的一个非常重要的环节，他能保证代码的规范

性和质量高低，CodeReview工作可以由负责人进行，也可以由组内成员相互进行CodeReview检查，这样也可以提高组内成员的水平，

CodeReview并不仅仅是找各个开发人员的开发问题，主要的还是培养开发团队的专业水平，CodeReview也要抓住重点，如果在时间比较

紧张的情况下一定要对项目中重要和关键环节进行详细的CodeReview工作，比如在系统的性能方面就要加大CodeReview的力度，保证

性能的质量，我们都知道实现一个功能没有不能完成的，但是完成的质量如何是有高有低的。所以是很需要进行CodeReview进行检查的。

　　（3）单元测试不能缺少。　

 详细内容后续。。。

4. 制定好项目的上线计划

二、非正常，按照上线时间已定倒推上线计划的项目