网站项目成功管理实践（下）

 

http://bugfree.1zsoft.com/Doc/PM2.htm

发表在《程序员》杂志2005年第9期52~67页的原文
编者按：在上期的文章中，我们分享了http://133.newsky.cn项目的实施过程，然而，一些在时间之外的内容却被忽略掉，如项目范围、人才、资金、进度、精神因素以及制度（尤其是文档制度）等各个方面，本文试图用一种“横切面”的方式来关注项目实施，也为项目经理在管理项目时，提供一些有效的思路。
网站项目成功管理实践（下）

记者/孟岩欧阳璟

背景说明è四个人的角色分工：
刘振飞：项目经理，负责整个项目的规划、协调工作。2005-1-1加盟公司。
蔡志宏：需求定义，从头参与规划。2004-11-8加盟。旧版网站的非正式“项目经理”。
朱伟波：开发组长，并参与规划和后台管理的需求定义。2005-2-22加盟，项目刚启动。
张春艳：测试组长，负责北京分公司所有业务的测试工作。2005-3-7加盟。测试组在项目前期（规划、设计）参与较少，整个测试组是随着这个项目逐步建立的。

《程序员》：刘振飞，你好。对于任何一个项目来说，项目经理所面临的责任都是最大的。这尤其表现在整个项目是否有明确的目标。请你谈谈你当时对http://133.newsky.cn这个项目的看法，而当时明确的项目目标是怎样一步步制定出来的？

刘振飞：明确的目标是整个项目组齐心协力努力的“指南针”。作为项目组长，首先要把Stakeholder们对项目的要求吃透、并从技术上把握可行；然后要让整个团队理解这个目标：做什么、为什么、怎么做、如何分工、何时做出来、分阶段到达什么状态。

我是分三步确定目标的。首先是了解旧网站的情况。经过和原来负责旧网站研发的蔡志宏以及开发和美工人员深入沟通后，我发现旧网站是个“烂泥滩”，所以把实际情况解释给管理层，说服他们另起炉灶，推倒重做一个全新的网站。

第二步是吸取旧网站的教训，确定新网站的总体构想、设计原则、新版“图纸”。我、蔡志宏、朱伟波还有当时的美工形成一个“核心小组”，反复开会讨论，结合公司现有的业务及人力资源情况，逐步明确图片、铃声、文字这三类主要的WAP内容如何在网站上有效展示。

第三步是把“核心小组”的整体思路报告给管理层和项目组成员，听取大家的反馈意见，逐步明确这个网站的目标和设计方案。我分别在3月9日、17日、21日召集会议，给众人介绍我们第二步的讨论成果，请大家站在不同的角度去审核，不断吸取合理化建议并最终达成一致意见。最后明确这个项目的目标如下图所示：

示意图：整体规划统一整个项目组的前进方向

其实我还跟项目组内部讲过另外两个“非正式”但更长远的目标：
（1）把整个项目流程管理好，给公司树立一个“样板工程”：项目应该这么做；
（2）通过这个项目打造有良好素养的团队，逐步培养大家正规的项目研发意识。

示意图：用了1个月的时间来进行规划，确定目标、统一思想

《程序员》：定义需求的时候统一的指导思想是什么？在项目进行中，需求的变更是怎样管理的？你是否曾经面对来自上层的压力，怎样面对？需求工程师是否能理解，并按照预期的规划工作？

蔡志宏：我们一开始就意识到网站的核心功能并不是诸如导航条摆在左边还是右边的问题，而是要让公司产品能够得到最好的展示，为此确定我们要做展示的几个核心部分。我们牺牲掉部分美观来换取一种整齐划一的思路。这就像大型超市一样，也许每一个货物区都有自己的的货架摆放形式会更好，但是同一个形式也有它自己的优势。

对于SP的网站来说，关键是你有一张好图吸引用户，不是花哨的页面来蛊惑他，蛊惑用户将付出超出产品制作本身的很大的精力，这是实战经验。花哨的页面布局形式能够在最初上线的时候让所有人满意，但是在运作的过程中会发生很多的问题，因为为了花哨，长期下来是要付出技术、美工等很多精力的。

核心的展示模块确定之后，我们也面临了这个图标放到右边好看，那个文字放到左边好看等一些需求变更建议，有些建议来自于高层，但是这都没有影响到需求的最终定义。当然，一些细节上的建议仍然被采纳，这个队伍虽然是“武断”的，但还是个开放的队伍。

尽管在初期的规划非常完善，然而限于时间要求，有些想法在该目前的项目中仍然没能实现。

示意图：把网站各页面分成模块，分块定义，形成需求Spec文档

朱伟波：以前在别的公司做项目时就是因为需求不断变更问题，遇到过很大的麻烦，所以这个项目一开始时我就再三强调需求的重要性。目前公司的开发模式还比较简单。领导一句话做什么就做什么，什么需求以及文档都是开发人员根据自己的理解来做，往往在开发中途可能由于各种原因领导的要求产生了变化。这样导致需求不断变更，直接影响了开发的进度。了解了这个情况后我就直接找过振飞，认真地谈过这个问题，并一再强调要重视它。很高兴振飞在这方面很支持我的看法，让大家都知道不可以随便改需求。

当然在开发过程中由于公司的业务要求，产品经理（蔡志宏）有过几次需求的变更。我的态度还是比较强硬，大的需求一定不能随便动（因为项目时间很紧，开发人员迟迟未能到位，需求要是不断变更，对开发人员是致命打击）。经常和蔡志宏沟通，尽量保持一致意见。我记得快做完后台管理时出现了一个致命的漏洞，极大的压力也造成了情绪上的不稳定，还好在总体设计时我就就注意到了扩展的灵活性，所以在大家的精心协助下很顺利的达成一致的意见，并最终在规定的时间里完成了项目的开发。

刘振飞：完整准确的需求定义决定着整个项目的成败。需求对项目组的作用就像剧本对电影剧组的重要性一样。同样的，项目一旦进入开发实现阶段时，只能做局部的小改动、最好是不要动。为什么这个项目规划要花掉整体1/4的时间？我就是要在一开始的时候，让大家集思广益，把各种情况都摆出来、理清楚，把以后可能的潜在变化都消灭在这个阶段。同时我一再给公司领导、蔡志宏（详细需求定义者）灌输这样的理念：需求必须明确、大家讨论清楚，然后就不能轻易改动了，所以多花些时间在前期规划、书写Spec及讨论上是非常划算的。看起来“浪费”了不少时间在文档书写和讨论上，但却节省了未来大量的维护时间。

       五一节后按计划开始网站前台展示的开发工作，我突然收到部门领导的Email，问能否停止这个第1步联通网站项目，转向原计划第2步那个移动网站的研发。我立即给领导解释：项目到这个阶段就像登山到了半山腰，所有人都憋着一口气瞄准山顶，这个时候突然告诉大家“咱们爬错了，赶紧换旁边那座山”吧，队员们会是什么感觉？所谓“一鼓作气，再而竭，三而衰”。当时那个项目还不具备启动的条件；况且我也需要通过这个项目来磨合队伍。还好我说服了他，这件事没有影响到项目组。

作为项目经理，一定要从善意的角度去理解领导的“多变”和需求的变化。但作为一线指挥官，要在项目前期做规划和需求定义时集思广益，尽可能避免可以预测的变化。当变化来临时，要把真实的状况摸清楚——一些变化是必须接受的，一些是讨论后可以变通接受的，还有一些是要想法拒绝的：你需要拿出负责任的决策，不能盲目服从。

《程序员》：在项目规划过程中，你是怎样预测进度的？最关键的开发环节是如何保证进度的？采用了哪些方法来保证进度能及时有效、保质保量地执行？

朱伟波：作为开发组长，首先在项目规划中就要根据需求明确可能用到的技术，并初步估算时间。但最重要的是需要充分的考虑环境因素，如领导的支持程度、人员的到位时间、以及需求的精确程度、甚至公司做项目的风格（取决于领导的风格）等。项目是不是会经常的变动、能否得到大家的支持，都是我要事前需要考虑的，有了这些信息，就可以大致估算项目的开发实际需要多长时间了。

为保证质量，我们事先需要认真的做总体概要设计，这样对以后的开发起到了一个很好的指导作用。采用一个好的架构对项目成功的重要性不言而喻，对以后的扩展性、维护都起到很好的作用。在这个项目里我和振飞都重视这一点，振飞特意多给我一天的时间来做该项目的设计工作。

再一个就是上面提到的，定义需求时一定要考虑周全、把握好，不能说变就变。

刘振飞：在3月21日完成规划时老板问我：网站何时可以做出来？我说必须等到详细需求明确以后才能知道。随后的半个多月，我和几个同事共同把需求文档整理出来，直到4月12日的集体会议上，才非常明确地写下各个阶段的进度。并将项目最后的日期定为6月15日。这其中产生了几十份Spec。

       当项目进度明确后，后面就是监督落实的事情了：需求不清楚时，立即请蔡志宏给出解释；页面制作落伍时，紧盯美工人员；开发完一块功能，就启动测试工作。尤其在接近尾声的时候，一旦发现延迟的就立即找出原因，如果在Feature和时间发生冲突时，我就需要及时给开发人员做出抉择：Cut Feature还是延迟时间？

示意图：项目经理要每天关注各个环节推进的速度是否和预期的一样

《程序员》：当时你对公司申请了哪些人力资源？在人员方面的预计是怎样计算的？打算怎样利用这些资源？招聘过程中的标准分别是什么？

刘振飞：根据旧网站的实践、公司现有人力资源的情况，然后我们“核心小组”依照以前各自的经验，确定这个网站研发需要的人力资源：

?         前台需求定义：1人（蔡志宏）
?         后台需求定义：2人（刘振飞、朱伟波）
?         美工设计制作：1人
?         开发组：3人（组长朱伟波）
?         测试组：5人（组长张春艳）

其中开发组有2人是新招聘，考虑到这个项目及未来的工作要求，对开发工程师的要求是：有较丰富的Java开发经验，为人踏实肯干、能吃苦。我很高兴把伟波招聘进来，他的Java功力很深厚，顾全大局，工作认真负责，团队意识很强。

       测试组不仅仅为这个网站服务，而是为整个北京分公司的业务测试负责。我对测试人员的要求是：喜欢测试工作，有测试经验，学习能力强（因为SP是个新兴行业）。我也很高兴招聘到春艳这样有好几年经验的同事，她对测试流程、规范、测试文档都非常熟悉，帮我扛住了“测试”这一重要环节。

       志宏比我早加盟公司，对业务非常熟悉，有很丰富的互联网从业经验。在项目规划和需求定义的时候，他经常会冒出很多新鲜的创意和点子。项目结束的时候我跟他开玩笑：忙乎了四个月，其实就是我带着一帮人把他的想法落实了。

《程序员》：团队其他同事最初是否对你制定的目标非常认同？大家认为这个项目与之前所做的项目区别将会是在哪里？你是怎样维系团队氛围的？

蔡志宏：我们是抱有革新态度在做这个项目的，它从思想上不同于一般的网站。开发之前，振飞和公司上层有很好的沟通，使这个项目从上到下有了很好的共识，所以大目标明确，也能得到了公司的全方位支持。大家对做这个项目为公司带来的收益和重要性有了理解，加上对公司的归属感，大家就都比较敬业。

朱伟波：这个项目是我来公司不久做的第一个项目，不知道大家以前是怎样看待项目开发的。我曾听到了很多不同的质疑：这是内部的项目为什么要这么赶呢？为什么一定要在规定的时间里完成？这个项目并不能直接为公司带来很多效益为什着急去完成呢等等。也许在原来做项目的思想下，大家心里有很多为什么，对这个项目还抱着一种试探，并没有重视它。

但欣慰的是，领导对这个项目还是很重视的。我刚来公司，没有历史包袱，还是按我原来做项目的成功经验按部就班。事后证明我的判断是对的——这个项目和我原来做过的项目，其区别就是打破一家公司做项目的风格。“打破”就带来压力！试想，如果这个项目失败了，说明该公司原来做项目的混乱风格未尝不可，而我们的努力也就付之一炬了。

由于每个人的做事风格不一样，也会有这样那样的问题。但是在振飞的揉和下大家还是能很好的融入到这个项目团队中，最终解决问题，完成任务。

张春艳：刚来公司时，分配给我的任务就是测试旧版133新天地网站、熟悉联通WAP业务。在测试旧版网站过程中，发现问题不少如下：

1、内容不够丰富，不吸引用户；

2、页面的展现力不强，感觉比较枯燥；

3、程序不够稳定，常出现HTTP Error 500、404错误；

4、有些很重要的功能都没有实现（如搜索功能）；

5、N久也不会更新一次内容（大概是因为更新一次很麻烦吧！）；

6、没有需求、没有目标，测试属于没有目的状态，需要凭借经验和感觉进行盲目测试。

对于测试这样的网站，我认为没有太大意义，早应该进行改版或推翻重做。所以对振飞制定的项目目标十分认同，并希望协助很好完成。我理解这个项目与公司其他项目区别：

1、一个不赚钱但为公司所有赚钱项目服务的一个项目；

2、是公司当时唯一有规划的项目，让每个人都心中有数，到了哪个时间段该做什么事。其他项目基本处于混乱的状态，只有提交到测试这边才知道有这么回事；

3、测试方法不同与其他项目：a、时间计划安排上的不同：有头有尾，且留给测试的时间足够充裕，对测试的质量给了一个很好的前提。其他项目经常处于救火状态，下午提交测试，下班前就要求完成，没有思考和准备的时间；b、测试方案和方法上，在可重用的流程上首先启动了Test Case的概念并加以执行；c、需求文档的准备给测试做了很好的铺垫。

刘振飞：项目的目标不是我一个人拍脑壳想出来的，而是结合领导的要求、公司的实际情况逐步从小范围到大范围反复讨论后确立的，项目组的每个人在规划阶段结束的时候，都非常明确两个问题的答案：这个网站做成什么样、为什么。

大家对整体规划认识一致后，后面需求、美工、开发、测试、运营等各个环节的工作就可以“统一思想”，因为有了明确的共同奋斗目标。作为项目经理，我做的就是定期把各个环节的进展告诉整个项目组，做到信息透明。一个目标明确、互相信任、尊重、团结的队伍，再把项目组的信息公开出来，就能够保持良好的团队气氛。

《程序员》：从需求、测试和开发各方面看，是否支持你的目标？大家对这个项目有信心么？信心源自何处？你是怎样鼓励团队中其他同事的？

蔡志宏：这个项目中有许多值得讨论的事情。首先在各个环节上都有很突出的创新，难得的就是这一点，一是因为各个环节的负责人均是老手，有创新的实力；二是一些气氛方面的因素，振飞的专业精神感染了我们，振飞有时候比较容易着急，但是他有一个核心的优点就是简单，我们基本上不用过多去考虑和他沟通的方式，只要把信息传达到了即可，这样的一个项目经理可以节约很多的时间成本和脑细胞。

现在的一般的公司里面有许多不适合创新性思维的项目经理，对上不会沟通，对下也不会激发，天天板着个脸，这样很难做出什么有创新的项目，我觉得程序员写的是程序，但是程序员并不是一个程序。

朱伟波：在同一个目标下，我就只有一个想法是要按时按质的完成项目。很多老员工对公司原来开发的模式感觉不是很好，都希望能换一种模式。在这种心理下都希望能很好的完成项目，来证明自己；同时也可以在规范法下学到很多新的做法，所以大家的热情都比较高，希望通过正规的开发流程学到很多以前学不到的规范，这对参于项目的人员来说是一个很好的经历。

当遇到困难时，我们都能坐下来很好的商量、讨论。再有就是领导的大力支持，让我们对这个项目看到了很大的希望，让大家都能把热情投入到项目里。

张春艳：从完成这个项目的测试来说，信心源自明确的目标、合理的计划及各部分之间的配合。对测试组来说，蔡志宏需求的配合和朱伟波开发部的配合都不错。测试组提出的疑问及Bug会及时得到开发组的回复，或是解决或是经振飞确认可以延期解决或可以不解。不会出现有一个问题没人搭理的情况。

刘振飞：经过2004年第一个网站的实践，我非常有信心，可以把在微软Office组学到的产品研发流程和项目管理方法移植到网站项目中。每个环节的同事在每个阶段应该做什么事情，要让每个人都非常清楚；项目组的任何信息都是公开透明的。同时作为项目经理，不要有任何“官架子”，大家在人格上都是平等的；出了意外情况的时候我要第一个及时做出反应，给出经过认真讨论、协商后的可接受的解决方案。

某个环节、某个人做的好，要在整个项目组及时提出表扬，特别出色的要争取申请公司的奖励；某个环节、某个人做的不好，私下里要及时批评，找出原因和解决办法，避免重复同样的错误。当然，关键时候某个环节比较劳累的时候，要请相关的同事撮顿饭、缓口气，搞研发的人既是理性的，又是感性的，大家都需要得到认可。

《程序员》： 我们看到你的项目管理依赖大量的文档。目前这种文档化的方法似乎在开发人员中不受理解和欢迎，而且在理论界也受到了不少批评，大家怎么看待这个问题？以团队成员的亲身体验来说，文档的作用是什么？如何恰当地使用文档？

蔡志宏：这个项目在严格的时间控制下完成的，振飞为每一个小的环节设置了一个Deadline，包括一个小图标的制作，我很佩服他可以这么精确的统计到工作量，做那么多的Excel表格和PPT来管我们。网站上线之后，我吃惊的发现在服务器的CVS目录里面居然有上百个这样的文档，这些文档中的有许多是用来记录每次开会的情况和随之而来的工作分配，事无巨细！我想如果微软的Office要是这样做出来的话，那肯定要拿好几个电脑来装这些文件。

朱伟波：文档是软件生命周期必不可少的东西。为了让项目能有一个清晰且强壮的结构，就要做总体设计，具体到运用什么技术，使用该技术对我们日后有什么好处、要承担那些风险，以及采用什么样的结构来开发等等，这些都一一记录下了，为下一步的开发做好准备。

在开发前我们还写了一份详细的概要文档，这份文档主要记录了日后开发的细节，比如包路径、代码的规范、需要的辅助类、每个包下放什么东西、公用类的简介、用法等等。这些文档为日后我们查询起到了举足轻重的作用，为后续补充进来的人员起到了很好的引领作用。在开发过程中依据这些详细的文档能衡量代码、判断思想是否一致、风格是否统一等等。

文档的作用主要是规范行为和风格，让大家有一标准，避免在开发过程中走一些不必要的弯路。当然，在制定文档时需要全面考虑——要可实施。如果事先在写文档时不能考虑周全，那么可能直接导致项目失败。

张春艳：文档是主要的工作产品之一，好的文档可以推进后续的工作顺利执行。如：好的测试用例，第一、可以作为执行测试的依据和参考资料之一；第二、如果公司的测试人员流动，新来的测试人员不会无从下手；第三、文档也是公司的财富之一。

刘振飞：不要去写那些走形式、对项目没有实质意义的文档，比如变了味的所谓ISO9000或CMM认证的那些文档、极其复杂混乱的UML文档：每个人心里都很清楚那种文档没有用处，但还不得不写，劳民伤财，非常可笑。

文档的作用就是把问题想清楚、记下来，让别人能够看懂、能接手进行维护。比如需求Spec的作用是帮助需求定义人把需求细节真正想清楚，对该模块进行详细定义：功能描述、逻辑、界面、如何使用，就是站在用户的角度去细化、去说明。需求Spec首先要自己想明白、并以别人能够理解的文字记录下来，作为开发的“合同”。Spec要及时更新，反映最新的状态。
当然在实践中，中小企业的项目研发进度都赶的比较急，把文档细化到什么程度、如何保持更新，都是比较头痛的事情。

示意图：项目有几十份各种格式的文档，有效的文档对项目成功极其重要

《程序员》：除了文档，还有那些制度是你在这个项目中新建立起来的？如何保证这些制度的被理解和被执行？

蔡志宏：除了文档，就是无所不在的BugFree（http://bugfree.1zsoft.com）系统了，这让我想到一句话，“体制化是这样一种东西，一开始你排斥它，后来你习惯它，直到最后你离不开它。”开始的时候大家都比较讨厌那个叫BugFree的那东西，实在是麻烦，感觉一个很小的事情都要发一个Bug，觉得纯粹是在浪费时间。后来发现这东西有它不可替代的好处，一个问题从出现开始到最后解决都有它跟踪，效率反而提高了许多，尽管在后来对哪些问题应该发Bug进行了一些争论并做了调整，但是BugFree系统在这个项目中起到了很重要的作用。

朱伟波：在这次开发过程中使用了CVS作为我们的版本控制，我们规定在上传代码到CVS时一定需要写注释，以便事后能很快的查询。在开发组内部开了一个会议，我重申了上传代码时写注释的重要性，并当场上传了一些不带注释的代码，让大家来恢复到我所需要的版本——在这种情况下大家很难一下就恢复到自己想要的版本。通过这种方法让大家意识到自己原先的不规范的地方，统一认识，为保证下一步的研发打下了坚实的基础。

还有就是写程序时要符合公司的代码规范，其实就是在符合Sun公司的规范前提下统一我们代码的规范性。做到这一点其实是很难的，大家来着不同的环境，以前接触的人也是不同。这就要求大家都坚持一个共同认可的标准，并严格的执行这一标准。我很庆幸的是大家都能很好的坚持我们公司制定的代码规范，并且在我们公司的代码检查中顺利的通过了考核。

张春艳：公司在测试这一环节的起步较晚，基本上是在今年的3月份才组建起了一只测试团队，还有很多人认为测试是一个可有可无的过场。还好有领导的支持与认可，我们测试组努力把工作做得漂亮，证明自己存在的价值。用我们的实战来告诉大家，测试不是随随便便就能完成的，而是一件有始有终、有流程、有规范、非常严谨的一项保证产品质量的工作。

在133网站的测试中，我们就是这样证明了测试组存在的意义：

1、根据振飞制定的规划，我们按时完成了测试进度，没有拖延录入及上线时间。

2、首次采用Test Case的方法完成下载流程的测试，并且取得了很好的效果。此次的Test Case还可以移植到以后网站的日常监控测试中。

3、测试效果体现。（1）保证后期录入人员在录入时不出基本错误；（2）利用边界值的测试方法，提前测试出录入后前台展示可能不美观的情况，便于在录入前给出提示或硬性规定（如输入的专题名的长度等），来保证前台的展示效果和录入的效率；（3）为了使大数据量的用户访问情况下不出问题，我对首页进行了100人同时访问的压力测试。

4、在6月15日上线前，做最后的回归测试，保证上线产品的质量。通过此轮的测试，至今还没有得到公司内部或外部对网站出错问题的反馈。

刘振飞：除了要求需求、开发、测试文档外，我逐步建立了如下制度：

★ 严格的进度控制，每个环节都要遵守自己同意的进度

★ 用CVS来管理文档和代码

★ Java编码要有规范

★ 每一个功能模块都必须经过测试

★ 项目进展情况定期通报给全组同事

★ 有延迟的时候要立即提出来，及时找到补救办法

★ 项目完了要及时总结，验尸报告不是走过场

       当然我不可能在短短四个月中通过这一个项目把这些制度都打造的很完美。关键是通过这个项目给大家灌输这些意识，通过以后的工作实践不断强化，真正形成好习惯。这些制度其实都是研发中的基本素质、本来就该这么做，所以面对这么多人、这么多事，我一个人有时难免有疲累、孤独的感觉，很多时候只能抓住大的方面，一些细节只能忽略了，是很无奈的事情。

《程序员》：尽管133项目的完成已经非常不错了，但在你的项目中仍然会再次提到“验尸报告”这个词，你认为项目还有哪些不足之处。

蔡志宏：我是第一次参与“验尸报告”，感觉很新鲜。的确在最后结束的时候，大家和振飞面对面的单独总结了各个环节的工作，对整个项目的运作有了更宏观的视野，大家都站在一个更加高的角度来看待我们完成的工作。

朱伟波：我觉得一个人的成长是在一件事即将结束的时候。在做项目时我没时间过多的考虑去用什么新技术、用什么新概念、会有什么不足等等。这些都是在项目结束阶段时我们总结所得，回顾项目过程时能发现有那些不足，这样就有时间来考虑在下一个项目里用什么东西来弥补不足的地方。

我们开发组和振飞一起总结出来项目的不足有：（1）美工的工作进度缓慢，在很大的时间里直接影响到开发的进度。（2）我们不应该让美工的开发和代码的开发并行的来完成，使得很多的代码重复。（3）代码的开发和测试的同步也是一个不可取的做法，在测试组前期测出的大量Bug，可是当研发继续往下走后这些Bug就不存在了。（4）还有一点就是当我们完成这个项目研发后，网站营运人员迟迟不能到位，内容跟不上。这是我们事先没有考虑到的。

张春艳：任何一个项目都不会十全十美，就像一个再好的软件也不会没有Bug一样。不是只有做得不好的项目才需要“验尸报告”。我觉得“验尸报告”是这个项目中很好的一个环节。不仅可以把好的东西继承下来，还把不足的地方提出来，给以后的项目作为经验。

刘振飞：Everything that has a beginning has an end. 项目总结最重要作用的就是“承前启后，继往开来”，表扬与自我表扬相结合、批评与自我批评相结合，不能走过场。不仅要在以后的工作发扬光大成功的地方，更要解决这个项目中曾经存在的问题，真正做到“吃一堑长一智”。

示意图：133网站项目的“验尸报告”

       通过我这一年多的实践，痛感研发管理不仅仅是某个项目内部管理的事情，它涉及到整个公司的发展战略、领导层素质、员工能力、薪酬体系乃至企业文化的建设，仅仅从项目管理的层面去解决问题的成效将是非常有限的，这是一个系统工程，靠一人之力来完善是不现实的。欢迎《程序员》的读者朋友就项目管理一起交流心得，我的Email是：

[e-mail] 。