Sales 案例

最新推荐文章于 2024-09-17 21:44:43 发布

程序猿凯撒

最新推荐文章于 2024-09-17 21:44:43 发布

阅读量1k

点赞数

分类专栏：项目管理文章标签：文档测试工作任务 asp.net 单元测试

项目管理专栏收录该内容

2 篇文章 0 订阅

订阅专栏

Sales 案例

在这个项目中，我 (DM) 主要负责项目的整个开发过程。

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

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

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

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

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

最后阶段，项目虽然按时提交了，但是都是组员加班换来的，总结得失如下：

成功之处：

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

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

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

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

失败之处：

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

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

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

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

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