在这个项目中，我(DM)主要负责项目的整个开发过程。<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

     开始前,客户(这里的客户是指外包公司)已经将一些文档资料(包括系统雏形(UI)、功能需求说明书、和台湾银行的一些接口资料等)发了过来，刚开始有3个人参与，<?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />7月2日 项目开始启动，客户来我公司首先做流程上的讲解，并且将所讲内容用AniCam录了下来，方便我们反复听取；然后是我们依照客户的讲解消化后再讲给客户听，一是帮我们熟悉系统，二是让客户确认我们对系统的理解究竟对不对，从而减少理解上的落差； 之后就是时间的安排和人员的分配， 最后达成共识 ： 所有数据库设计、规格书撰写、coding格式及工作都有我们来完成，客户负责操作说明撰写和真正客户的需求沟通。

     初期 ，主要是熟悉流程和一些设计文档的撰写，包括数据库设计、规格书(和福瑞博德的UC差不多功能，但是更详细具体)，我当时要求组员把自己负责的那部分要画出流程图来，然后拿给客户确认，但是当时客户并没有做任何说法，对与不对都没有说，因为考虑到时间问题，所以就没有停下来等客户的确认而继续做后面的工作。

     第二阶段 ，所有文档都已经写完，已经开始了很大一部分的代码撰写工作，这时客户方有变动，他们开始参与代码的撰写工作，于是他们提出一套他们自己定义的代码规范(最典型的是原来所有用JS做的检核都要换成验证控件)，要求按他们的规则来写，最糟糕的是他们没有通过我来传达而是直接去找组员，这样组员已经私下开始修改了，而我丝毫不知情，等第二阶段快要提交时，才发现进度落后了一大截，组员不是在做第二阶段，而是在修改第一阶段，而提交时间一到，这时我们不能按时提交，客户很生气，说我们承诺的事没有按时完成，而组员也心里很不平衡，说是客户让他们改的他们就改了，这个时候我请求客户第二阶段稍稍延迟，第三阶段会给他们提前完成，以弥补我们的过失，同时要求组员加班，调动其他组组员过来帮忙，这样第二阶段在稍稍延迟的情况下提交了过去。

     第三阶段 ，鉴于我管理上的疏漏，我要求组员只和客户沟通业务上问题，公司内部人员调配、工作进度、工作安排等有我和客户沟通，而且要求组员每天汇报工作进展状况，没有我的同意，不允许私自给客户改东西。虽然我们外包给了客户，由客户负责管理，但是我采取了另一种方法，在客户管理我们的同时我们也在管理客户，就是所有需求都要求客户写成文档，口头说不算，我收到正式文档后发给组员，组员仔细解读后再依照自己的理解另整理一份文档有我发给客户，等客户确认后我们才动工，如果客户不确认或客户对此业务也是不清不楚我们就不做，如果客户已经确认了，我们就依照正式文档做，这样就责任很明确了。如果真正的客户需求有变，那么如果要按新需求做新的改动，则我们要重新商定提交时间，如果客户认可商定时间我们就做修改，如果客户不认可我们就不做修改，这样责任明确，相互管理，沟通起来就顺畅多了。

     第四阶段 ，客户嫌我们提交的代码品质低， 为了做好品质管控 ， 我采取两种测试方法 ， 一是 让组员自己做单元测试， 二是 两人或多人做交叉测试， 然后提交给我后我再一次整体测试 ，将bug按数量、难度系数等分类统计，然后作为考核绩效，和最终项目奖金挂钩，这样品质就相对高了很多。(当时公司没有QA，一切测试都是工程师自己)。

     最后阶段，项目虽然按时提交了，但是都是组员加班换来的，

总结得失如下：

成功之处：

1 、 项目有系统雏形(UI)、功能需求说明书、接口资料等，能使开发人员更快的掌握系统。

2 、 用AniCam做了录音，方便重复听取，帮助开发人员熟悉系统，使开发进度加快。

3 、 开发人员自己讲解系统业务能使开发人员在最短时间内掌握系统。

4 、 客户做了确认，责任分明，以免产生纠纷。

失败之处：

1 、 被客户所摆布、跟着客户要求走，而忘了最初的共识，虽然客户是我们的上帝， 但是不能认为客户的所有需求都是对的 ，要考虑到时间、成本。

2 、 沟通不及时、沟通上有落差，沟通方法不正确， 开发人员应只沟通业务问题 ，而不应涉及公司机密及其他影响项目进度等的问题。

3 、 责任不明确、客户没给予明确的确认，责任归属不清。

4 、 管理上的疏忽, 对组员开发情况掌握的不及时，未能做到提前预防。

5 、 测试不过关，没有专门的QA做测试，测试时间紧、测试不够细致认真。

6 、 第一次用C#+asp.net做web开发，所有开发人员都是新手
(案例完) 

 

#5楼  2006-05-12 11:41 tototo [ 未注册用户]

感觉你们的做法应该是开发人员从调研到设计开发测试一条龙的做 。开始看效率的确很高，不过越到后面问题越多。不是由专人沟通，到最后怎么统一文档？？而且如果开发人员离职，这个担子怎么接？？而且进度怎么把握？谁的工作量大？？开发人员在获取后期变更的时候是不是会偷工减料？？^_^

应该要有人专职来负责和客户的沟通，并统一改写那些变更文档，然后与客户确认。其实与客户讨论和确认很花费时间的，，在一个系统没有成型前，客户是不会花太多精力去看，也不会去想，乙方要主动一点，必须要时刻准备沟通，因为客户的想法在变，开发人员这边实现系统功能也可能出现不少问题。

虽然沟通浪费了不少时间，但为最终的项目的成功降低了很多风险，值得花费的，这个深有体会，以前一个项目从开始到最后交接之前跟客户关系好得不得了，到最后好像成了仇家，就是这个鸟原因。