成功和失败的项目管理比较

之前在一家公司应聘，被问过这个问题；在新的岗位从事工作，见过的公司多了，成功和失败的案例都不少，总结一下成功的和失败的特点，作为参考和总结。

在我看来，一个项目和产品无非是[b]需求-设计-开发-测试-发布[/b]五个阶段的是最佳实践，那么项目也就是最佳实践。不同的项目和产品，各个阶段有不同的比例，根据项目的技术难度和开发周期而定，不一而论。但是无论比例如何，这五个阶段要成功的关键，都是要能化繁为简，在纷乱的变更和难题中，找到最佳最简的解决方案，一击致命。

需求是第一步，其实需求的获取和管理，没那么可怕的，关键是做的人的素质，对技术的把握力和沟通能力。

我从事过两个很成功的项目的需求：

1个是技术总监亲自做的需求，老外，美籍华人。整个系统他都了如指掌，在和客户谈需求的时候，他很清楚什么可以做，什么不可以做。旁边有下手负责记录和整理会议纪要，回来会整理成规范的use case文档，发过来。由我先审核一遍，不明白的地方沟通（这里回头说一下沟通方式），等待反馈，一般1个回合搞定，然后就流入设计阶段。

这里成功的因素有3个

1. 强有力的需求开发者

技术总监做客户沟通，当然这个对于大多数企业来说是不可能。但是需求开发者的层次越高，那么需求的质量就越高，项目的效果也就越好。国内的企业，一般喜欢用不太懂开发的市场人员去做需求开发，不是说都不好，只是这样的效果，好的很少。

当然，其实做需求开发，重要的是沟通能力和写作能力。这个见下面一条。

2. 详细规范，清晰明了的需求文档

其实需求文档无须言必谈用例（Use Case），用例图，那些条条框框实在很烦人，而且说实话，我就没见过国内的写得很规范的这种用例文档，老外愿意不厌其烦的写好所有的细节，这个我佩服，但是不见得这个就是最佳的表达方式。根据项目的实际情况，信息明了的文档，准确的业务描述，比起一堆用例图和无用的文字好的的哦，再配上一些好的设计图，胜过形式主义的千言万语。

3. 开发方leader的审核和反馈
作为off board一方的开发leader，对需求是第二道把关了，如果不能很好的根据开发团队的现状和系统的理解，做出对需求的有效判断，那么需求的有效按期开发，就不可能很好的完成。

第二个成功案例比较现实。基本不懂技术细节的业务经理，和客户做沟通交流，记录所有的需求，梳理归档后，和技术经理沟通，决定哪些是可以本版本发布，哪些是下个版本发布，哪些不发布。

这种模式比较可行，相信很多公司也有这个条件，要点2个：

1. 业务经理的沟通和文档能力

2. 技术经理的审核力

3. 两者默契的配合

设计——适度设计

我最讨厌Scrum之处，莫过于Scrum对设计的忽略了。典型的场景是一个功能点给某个人了，不需要设计，不需要评审，开始Coding吧，也不理会模块的大小，重要性，交互集。当然了，这和公司的实施策略不合理有关，但是更多的也是遵循了Scrum原则的结果。不要过度设计，不代表不设计。这样做出来的程序，功能简单的还好；功能复杂的，如果那个人能力不行，很容易就需要推倒重做，即便那个人能力不错，也容易出现做出来以后，和其它人员的代码对不上号的情况，又需要几个Story来做所谓的集成。

其实我当然不是提倡八股文形式的cmmi评审，项目有个Technical Leader，在任何业务或者技术需求确定后，在做之前评估一下，是否需要设计。需要的话，分配或者自己做好个设计，然后群发讨论一下，大家看了之后，都明白你做的思路，并且提出意见，在没有意见的时候，就可以开始做了。

交流——公开可追溯的交流

说到需求和设计，都设计到一个迭代的概念，就是都不是一次成型的，肯定需要讨论。作为一种远程交互的结果，我们最容易遇到的一个难题莫过于著名的“邮件陷阱”。大部分的交流都在邮件群发中完成，最后能沉淀到文档的东西不多，就是沉淀了，设计的过程，思路，也不会写入文档。真知灼见往往埋没在邮件的海洋。而过了一段时间后，不用说讨论者离职，就算不离职，他自己也很难在邮件的海洋中，找到这些设计的蛛丝马迹，除非他有非常优秀的个人工作习惯和资料整理能力。

这个问题在国外现在已经有很简单的解决方案，就是“黑板”，借助web 2.0的项目管理软件，例如BaseCamp之类的，道理很简单，有什么设计，需求，都是起一个讨论（Discuss），简单的就直接图片加文字，复杂的就上传附件，然后相关人员围绕着这个topic，在这个discuss下，各抒己见，每个回复都会发邮件给相关人。实现很简单，和论坛差不多，但是作用确很大。所有的讨论，都保留在这个讨论中，也就是数据库。邮件只是个通知，没有任何实质内容，新来的人员，只要把相关的讨论（Discuss）都看完，就可以了解相关的设计和需求，不同人的见解和思路。

这就是公开而可追溯的交流。


编码——定时编码法

说到定时编码法，其实和定时工作法一样。很多程序员写代码喜欢不做计划，拿了需求就开始写，一边写一边做别的事情，回复邮件，浏览网页什么的，效率很低，写着写着也就不知道自己写什么了，更别说现在的开心网干扰。

定时编码法，也是国外现在比较流行的方法。其实一个程序员真正有效的工作时间，一天也就1，2小时。在这段时间内，程序员应该先做好规划，自己接下来的编码应该达到什么的目的？设立一个可见的milestone，不要超过2小时。

然后，关掉你的IM，邮件，网页，开始全神贯注的聚焦于你要做的事情，一气呵成，在规定时间内完成。漂亮的话，给自己点鼓励。这个和结对编程是不矛盾的，可以共用，关键点是时间不能太长，要定时，要全神贯注。在完成工作的同时，提高自己的专注力等素质。


单元测试——交叉单元测试

食不厌精，脍不厌细，写单元测试要有这样的精神。尤其是关键模块的单元测试。良好的单元测试，应该在各个层面有良好的覆盖率，言之有物，像一张防护网一样，在重构或者修改功能代码出错时，及时的报错。而不是“Keep Silience”。对关键的业务逻辑和核心逻辑，测试用例的覆盖一定要细而密。对于Web层，不建议用单元测试覆盖，可以在人工或者自动化的功能测试中，进行Web层测试。

与其提倡结对编程，我更提倡交叉单元测试。一个人写自己的测试，无论如何都有惯性思维在里面的，而交叉的单元测试，可以提早发现很多想当然的问题。而新手的单元测试水平，也可以在老手的带动下，得到很好很快的提高。


功能测试——细粒度的自动化


集成和构建——尽可能统一，差异最小化

每日构建这个是最基本的事情了，无须多说。在小型和本地单库合作项目中，用Subversion，基本没什么问题了。在大型的团队开发中，要设计好分库的事情，分离出变与不变的部分。分开库存储。多变而多人协作的模块，可能需要建很多流。尽可能的优化合并的流程。


零差异：开发环境和实施环境尽可能的零差异，开发的版本和运行版本避免差异。