网站项目成功管理实践(刘振飞)

74 阅读 0 评论 49 点赞

我是靠谱客的博主辛勤火车，最近开发中收集的这篇文章主要介绍网站项目成功管理实践(刘振飞)，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

网站项目成功管理实践

刘振飞

—发表在《程序员》杂志2005年第8期58~62页的原文—

在开始做 http://133.newsky.cn之前，我已经明白网站的开发与产品开发没有什么不同。不过在2004年离开微软中国研发中心Office组的时候，我对网站开发仍一无所知，这主要是因为我之前没有任何互联网研发的背景。虽然对传统软件产品的研发管理比较有经验，但从未接触过Internet 相关的项目。

从零开始与网站开发亲密接触

去年我接手第一个网站项目 http://www.okooo.com开发时，并没有做网站的经验，只能试着按照以前我参与做Microsoft Office 时的方法来做：

首先是打造一个便于公司内部沟通交流的内部网，其中包含“传统软件”研发需要的三个工具：文档库（存放公司各项目的文档）、 CVS（保存项目的各种源代码）、BugFree （记录项目的各种缺陷）；

然后，抓住“需求、开发、测试”三个环节：

l 要做好规划、明确需求。 为什么要做这个网站、要达到什么目标？特别是需求，要详细到每个页面的每个区域放置什么内容。网站需求应该由对业务最熟悉的人来定义，他负责按照我要求的规范（详细程度）来写出每一部分需求文档，并放入文档库中。每完成一个页面定义，我就召集开发、测试人员来阅读、讨论，这样全部需求写完的时候，项目组成员对整个网站就有了一个清晰的认识。

l 需求明确才进入开发阶段。 首先是定义数据库——有多少张表、每张表中有多少个字段。我和开发组长反复讨论，搞清楚这些表定义能否涵盖全部需求，这是最关键的一步，决定着下面编码能否顺利进行。数据库定义后，就是网站后台管理的编码实现，也就是对一张张表进行管理（增、删、改）。当后台管理完成时，项目的大部分就大功告成了。用户看到的前台页面仅仅是内容展示——把一张张表中的数据取出来按照最初的需求放置到页面的各个位置。所有的代码都用CVS 管理起来。

l 网站测试和开发同步进行。 后台管理每完成若干张表的管理，测试人员立即开始测试。这就像流水线，开发完一部分，立刻测试；同样的，网站前台展示开发时也一样需要测试人员跟进。发现的每一个Bug都用BugFree 记录下来跟踪处理过程。

l 数据统计跟上。 网站后台各个表的任何改动要准确记录，决不允许出现不知道谁修改了数据库内容的情况。其次，网友访问网站的日志要做好统计，每天结束的时候就能准确的看到当天的用户访问数据。这些数据对网站运营极其重要。

四个月后，我的第一个网站项目顺利上线。所有参与该项目的同事感觉都很新鲜，因为以前他们在做网站时，基本上是一个人“包干”一个频道，简单构思一下就开始写程序、边写边想、相互独立。后来，我跟一位曾在某门户网站工作过的高级工程师朋友介绍了上面的做法，他非常认同和赞赏，得到他的认可我也很兴奋。

随后接触到的很多网站技术人员，让我发觉作坊式做法同样存在于互联网公司，网站在重复多年前传统软件的老路：一个“大虾”很厉害，搞定一个频道或一个网站的方方面面，离开他谁都玩不转；代码中处处留着他的灵感，人走了，网站维护就成了大难题：没有文档、没有统一的编码规范、没有测试记录。

其实无论传统软件、网站、还是游戏等等软件产品 /项目，都是程序员用一行行代码敲出来的，只要像微软软件研发那样抓住需求、开发、测试这三个环节，其管理都极其类似。因此当我进入http://133.newsky.cn 网站项目的时候，信心十足：我能把它管好！

打造一个网站开发的品牌项目

05年2月18日：项目启动，开始整体规划

在我加入金环天朗的时候，这个网站就已经存在了，而最开始的计划也只是对原有的网站进行局部改版。但是等我深入了解后，大吃一惊：

u 规划／需求：原有网站没有经过认真规划就匆忙上马，只有部分的简单示意图，对于每个页面具体区域的功能描述和逻辑过程还是依赖口头沟通。没有独立的后台管理，依赖于 WAP 业务的后台，内容展示力不从心。

u 页面设计：美工因为还有其它工作所以有一定程度的拖延，没有时间观念，整个设计方案没有经过整体评估，导致后来许多细节没有按照计划实现，页面设计先后由两人分头独立完成，导致部分风格不一致。

u 开发：技术实现一直处在救火的状态，没有规划，没有步骤，没有主次之分，没有时间观念。代码的结构非常散乱，没有可用的文档查询，开发人员走了，给以后接手的人带来极大的麻烦。代码没有规范、没有注释。归结起来就是可读性很差。

u 测试：没有任何测试，开发人员简单试一试就直接上线了！

u 内容：网站内容维护没有专人负责，逐渐处于无人答理的状态。

总之，原来的网站有太多不尽人意之处，和同类网站比起来差距较大，市场人员无法推广，技术人员很难维护，动不动就出错。只能另起炉灶，推倒重做一个全新的网站。

对一家 SP公司而言，做网站是打通让用户消费的通道。从常远看，内容为王，但短期内通道为王：就是让用户很容易找到公司提供的内容。因为WAP业务非常依赖于运营商的门户排名，一个业务放在运营商WAP门户上，第一屏和第二屏有着本质的不同，愿意翻到第2屏上的用户可能少一半或更多！所以SP 要想尽一切办法来摆脱对门户的唯一依赖，必须能用别的通道让用户很方便的找到你的业务。而网站就是最好的宣传通道，是公司产品最重要的展示平台。网站研发的目标就是尽快打通联通、移动用户的消费通道，把公司生产出来的产品（图、铃、文字）方便地展示给更多的手机用户。

这个 http://133.newsky.cn 网站是面向中国联通用户的，其设计目标是：

Ø 1~3 年内不需要改动大框架

Ø 公司业务内容的精美展示、销售平台

Ø 在同行中有很强的竞争力

Ø 老板可以拿出来给投资人演示

为了达成这个设计目标，我和项目组花了近一个月的时间来制定完整规划。

	规划	需求	美工	开发	测试	运营
2005-2-18	收到老板 Email ，项目启动
2005-3-22	完成规划	启动前台展示需求的定义
2005-4-04		开始后台管理需求定义
2005-4-12		完成需求定义。确定后面的时间进度： 6/15 正式上线运营！	开始后台管理页面设计	开始网站数据库的设计
2005-4-15				完成“后台管理详细设计”的文档
2005-4-16				开始后台管理的编码
2005-4-21			开始前台展示页面设计
2005-4-26				完成后台管理的编码
2005-4-28					引入测试组，开始后台管理的测试
2005-5-10				两名新人到岗，开始前台展示的编码
2005-5-23						确定运营组成员及分工
2005-5-31				主要编码结束
2005-6-08					测试完毕	开始录入内容
2005-6-12						内容全部上线
2005-6-15	http://133.newsky.cn正式上线运营，向公司全体同事通报！
2005-6-22	完成 Postmortem( 项目总结 ) ，为下个移动网站项目做准备

明确的研发流程应该是一个开发团队的固定资产，从这点上，我建立了一套项目研发流程，并为其提供工具支撑：

Ø 认识老网站的现状、确定新网站的设计目标；对新网站的总体设计图纸进行反复讨论，确定网站研发的四个总原则（灵活的后台、以专题为网站细胞、丰富的资讯、翔实的内容）；明确人员分工、并预告项目执行的几个关键点。

Ø 在没有公司内部网的情况下，我先搭建两个工具：用于保存各种文档和源代码的 TortoiseCVS(客户端)+CVS(服务器端)，用于缺陷管理的BugFree。为每个项目搭建一个CVS模块，其中都有四个子目录：Spec(需求文档)、Design(设计文档)、Code(源代码)、Test(测试文档) 。

示意图：网站项目的CVS目录

然后是人力资源，我在规划中提出了非常明确的人力资源需求：

Ø 前台需求定义： 1 人（蔡志宏）

Ø 后台需求定义： 2 人（刘振飞、朱伟波）

Ø 美工设计制作： 1 人

Ø 开发： 3 人

Ø 测试： 5 人

Ø 运营： 5 人

然而，当时的情况却是项目组人员迟迟无法到位：美工只有一个兼职的、时间无法保证；只有一个开发组长；没有测试人员；网站运营人员不能确定。针对这样的情况，我的任务还包括了招聘相关人员及时到位。

在整体上完成上述工作以后，时间已经是 3月22 日了，事实上，在整个项目启动初期的准备阶段是一个非常重要的工作，清晰的项目规划也为后来的工作扫清了很多障碍。这就是俗话说的“磨刀不误砍柴工”。

05年3月22日：开始定义网站需求

网站需求特别难以确定，为了解决这个问题，我将整个需求定义划分为三个主要的部分：

1．网站前台展示的定义

我首先和负责定义需求的蔡志宏确定了需求 Spec文档模板，然后他根据首页、二级、三级页面逐个页面、逐个模块的去定义：展示什么内容，大概的模样（最终样式由美工负责）。这样每个页面都被分解成一块块的“部件”，一个“部件”由一份Spec描述，比如下面是“首页公告栏区域需求定义”Spec 的示意图。

示意图：首页公告栏区域的需求定义Spec

每完成若干相关联的 Spec ，我就召集美工、开发人员开会讨论（本应该也叫上测试和运营人员，但当时还没有人），大家站在不同的角度去看看有无问题，并最终确认下来。

2．联通用户消费流程的定义

用户消费流程涉及到收费问题，必须把每个细节都要搞清楚。这个需求由我负责，先形成一份 PPT 文档，在大范围内征求大家的意见，然后细化每个细节：从用户访问我们的首页开始，如何登录，如何转向联通网站，如何扣费等每个细节必须想到。

3．网站后台管理的定义

根据网站前台的需求，我和开发组长朱伟波来设计数据库定义，确定多少张表、每张表中有什么字段。然后从运营人员的登录页面开始设计，用PPT 把每张页面的示意图以及逻辑关系都展示出来，然后把需求、开发、美工召集起来一起讨论，看看是否符合运营人员的习惯、是否有遗漏的地方。

需求文档要想清楚后再写下来，让别人读得懂。定义好的需求 Spec是整个项目开发的“合同”，马虎不得。在需求定义的3周中（其中前台展示的需求用了2周、后台管理的需求用了1 周），每写出来若干相关的需求文档，就在项目组内讨论一次，最终明确下来。需求文档一旦成型以后，就必须严格按照需求文档编写设计代码，尽量控制需求的变化。这不但要求我们在最开始的需求分析阶段做好最充分的准备工作，而且还需要作为项目经理的我，顶住一些来自各方意见的压力。幸运的，我们团队还是非常好的坚持下来了：

示意图：上线后的首页公告栏区域——完全根据Spec中的需求定义来实现

然而，另外的一个问题是，需求文档很容易“老旧”、跟不上最新的变化，需求定义人也懒得去更新，因为开始编码后谁都不去注意需求文档了。为了解决这个问题，我就在后台管理的每一张表的维护页面上，增加一个“ Spec”按钮，点击后就可以看到相关的需求文档Spec 列表了。这样做有两个好处：一方面运营人员可以很方便的看到最初是怎么设计这块功能的；另一方面也把需求定义者的工作暴露在全体同事面前，文档写的好坏是一目了然。

示意图：每个后台表管理页面上都有个Spec按钮，指向对应的需求文档列表

充分的需求定义保证了整个项目能够准时完工，这也是我们这个项目能够取得圆满成功的原因之一。需求确定之后，后面开发、测试的时间就基本明确下来了。

05年4月12日：数据库设计，正式编码开发

有了完整的需求文档后，接下来就进入开发阶段。如同前面提及的，首先需要完成的是数据库的设计。其实早在需求定义期间，我和朱伟波就已经开始数据库定义，确定多少张表、每张表中有什么字段。我们花费了三天左右的时间来对后台数据库进行详细的设计，并产生出设计文档。

示意图：新天地网站2005版后台数据库定义.doc

然而，光有需求和详细设计文档还不够，开发团队需要保持要一种一致的风格，这一点要求所有的程序员对代码有责任感。因此在这个阶段之前（ 3/16~4/12），我就让公司所有的Java 工程师多次讨论，并最后确定一份“编码规范”，这样网站真正开始写代码的时候，就有一个明确的规范来约束代码的书写。

对于软件项目来说，经常会有一些出乎意料的情况发生。比如，本来计划有两个开发人员做后台管理，结果因为沈阳联通的一个合作项目需求紧急配合，只好临时抽调一个人去支援，毕竟网站是公司内部可以控制的，导致后台开发只有朱伟波一个“光杆司令”，那一段他连续十余天加班到晚上 11:30！这样高强度、高压力的工作状态，不是每个程序员都能承受的。经过朱伟波的努力，终于在十天时间内将所有的后台编码全部完成（4月16日至4月26 日）。

紧接下来，从 5月10日开始，专门为网站开发配备的两个Java程序员到位，朱伟波首先给他们介绍后台管理和Struts技术。随后分工：首页、3个铃声二级、3个图片二级、杂志、热门推荐、精彩专题等，每人承担几个频道的实现，分头阅读对应的需求文档并随时找蔡志宏讨论不清楚的地方。当理解需求之后，由朱伟波协调，三个人分头开始进行前台展示页面的编码工作，加班加点，在5月31 日基本结束。

05年4月28日：与开发并行的测试

在这个项目之前，整个公司是没有测试人员的！这不得不让我大为惊讶，一个 SP公司没有测试怎么行！所以在这个项目进行的同时我启动测试人员招聘工作，最终成立了一支5 人组成的测试组，负责所有业务的测试。

当网站后台管理编码完成后， 4/28立即启动测试工作：后台管理中的首页管理、动画、声音、彩图、专题、资讯由专人负责测试，发现一个问题就在BugFree中记录一个Bug。通过BugFree的跟踪和记录，可以让某些问题不必累积到最后才解决。随着网站前台展示开发在5 月中旬启动，测试工作也在并行跟进：每个频道、每个页面都有专人负责检查，这样尽可能的把各种潜在的问题揪出来，免除后患。

示意图：用BugFree来管理网站项目中的Bug

很遗憾的是，因为测试组搭建的比较晚、测试任务又比较重，他们需要花费很长时间去熟悉公司的各种业务，所以在这个网站项目中，对测试文档部分（比如测试用例）我并没有要求，只要把问题发现出来上 Bug就好了。这就是项目管理中的Trade-Off ：抓住主要矛盾、抓大放小。这个项目结束后，测试组已经逐步成熟、磨合好了，我才开始强调测试文档的重要性，每个业务测试时一定要同步完成相关的测试文档（计划、用例、测试结果等），测试时就按照相关的测试文档进行。这样以后复测就能省掉很多时间，换个人测试也很方便上手。

经过一个多月的努力，测试组的同事基本上完成了网站所有频道、页面的检查工作（ 6月8 日）。

05年5月23日：迟到的运营组开始运转

研发人员做出来的网站只是一个空空的框架，没有实际的内容填上去，网站就无法上线——打个比方，研发人员把“大楼”盖好了，还需要运营人员把“内部装修”做好。然而面对人员的稀缺和内部调整，一直到5月23日才确定运营组长及组员分工，他们匆匆进入角色，一面熟悉网站后台管理，一面准备内容。6月8 日才开始正式的网站内容录入。

在此期间，整个项目组都进入了最后的冲刺阶段。为了确保 6月15 日网站能够上线，我开始将工作日往后倒推，每一周甚至每一天，需求、美工、开发、测试、运营等环节需要到达什么状态，必须做到心中有数；每天都要盯着进度，一旦有了延误，必须立即找到原因和补救方法。如果实在忙不过来，我就要做出决定砍掉哪些可以延缓的功能模块。

示意图：项目最后突击的日志

05年6月15日：网站正式上线！

值得庆祝的日子到来了。 6月15日凌晨我正式向全公司同事报告这个网站正式上线。这是我自己主持研发的第二个网站，也是我非常用心管理的一个项目。我想留下一个参考样板，为公司其他项目的管理摸索经验。我认为这是一个成功的项目是因为：

ü 做出来的网站符合最初的规划和需求定义；

ü 按照需求定义完成的时候 (4月12日)确定的进度向前推进，6月15 日上线是两个月前就确定的；

ü 整个项目执行过程中，规划、需求、开发、测试等环节均按照预定轨道前进，没有出现大的纰漏。

整个项目组成员在网站上线后都非常兴奋，这应该是公司到目前最成功的一个项目管理实践。公司领导对这个项目的研发表示非常满意。现在的情况是，休整 2周后，7月4日按计划我们又启动了第2步移动网站的研发；另外对历史遗留的众多WAP 业务的整理开始提上议事日程。我需要更多时间、耐心和细心，和需求、开发、测试等各个环节的同事们密切配合，把公司各个业务的项目都理出头绪来、让研发部为公司业务的不断成长做出贡献，也让技术人员工作“累身不累心”，不要总是“救火”，要能看到辛苦工作的成效。

网站和产品开发没有什么不同！

按我整理的时间表和项目计划，对照微软的流程，你会发现，我完全是按照微软“传统软件”的研发流程去管理这个网站项目，略有不同的地方是，这个网站项目的时间跨度比较小（只有 4 个月），而且人力资源有限，美工、开发、测试三个环节我只能是并行处理、流水作业，以尽量缩短项目的整体时间。

	规划和需求阶段	开发阶段	测试阶段	发布阶段
主参与人	Planner 与 PM 驱动	开发人员推动	测试人员推动	PM ，产品经理，运营管理等执行
阶段成果	目标描述 (Vision) 详细需求文档 (Spec) 日程进度表	M1, M2, … Code Complete	集成测试 Bug-Fix, Check-in Dogfood Beta1, beta2, … (Triage) Zero Bug Release	Show-Stopper bug Release Candidate(RC) Sign-off RTM (Ready To Release)

我也算是“把微软先进的软件研发理念和中国中小企业的具体情况相结合”吧，其中最难的是把项目研发流程的理念灌输给全组同事以统一认识，并能有效的执行下去。很多时候要靠我不断的去 PUSH 各个环节，做的比较累，但在完成之后，很有成就感，尤其是针对一个团队不断发展和成熟，所做的努力是显而易见的。

—发表在《程序员》杂志2005年第7期57~67页的原文—

背景说明 è 四个人的角色分工：

刘振飞：项目经理，负责整个项目的规划、协调工作。 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 要及时更新，反映最新的状态。

当然在实践中，中小企业的项目研发进度都赶的比较急，把文档细化到什么程度、如何保持更新，都是比较头痛的事情。

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

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

蔡志宏： 除了文档，就是无所不在的Bug Free（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是：liuzf@pku.org.cn 。