Sales 案例
在这个项目中，我(DM)主要负责项目的整个开发过程。
开始前客户(这里的客户是指外包公司)已经将一些文档资料(包括系统雏形(UI)、功能需求说明书、和台湾银行的一些接口资料等)发了过来，刚开始有3个人参与，
初期，主要是熟悉流程和一些设计文档的撰写，包括数据库设计、规格书(和福瑞博德的UC差不多功能，但是更详细具体)，我当时要求组员把自己负责的那部分要画出流程图来，然后拿给客户确认，但是当时客户并没有做任何说法，对与不对都没有说，因为考虑到时间问题，所以就没有停下来等客户的确认而继续做后面的工作。
第二阶段，所有文档都已经写完，已经开始了很大一部分的代码撰写工作，这时客户方有变动，他们开始参与代码的撰写工作，于是他们提出一套他们自己定义的代码规范(最典型的是原来所有用JS做的检核都要换成验证控件)，要求按他们的规则来写，最糟糕的是他们没有通过我来传达而是直接去找组员，这样组员已经私下开始修改了，而我丝毫不知情，等第二阶段快要提交时，才发现进度落后了一大截，组员不是在做第二阶段，而是在修改第一阶段，而提交时间一到，这时我们不能按时提交，客户很生气，说我们承诺的事没有按时完成，而组员也心里很不平衡，说是客户让他们改的他们就改了，这个时候我请求客户第二阶段稍稍延迟，第三阶段会给他们提前完成，以弥补我们的过失，同时要求组员加班，调动其他组组员过来帮忙，这样第二阶段在稍稍延迟的情况下提交了过去。
第三阶段，鉴于我管理上的疏漏，我要求组员只和客户沟通业务上问题，公司内部人员调配、工作进度、工作安排等有我和客户沟通，而且要求组员每天汇报工作进展状况，没有我的同意，不允许私自给客户改东西。虽然我们外包给了客户，有客户负责管理，但是我采取了另一种方法，在客户管理我们的同时我们也在管理客户，就是所有需求都要求客户写成文档，口头说不算，我收到正式文档后发给组员，组员仔细解读后再依照自己的理解另整理一份文档有我发给客户，等客户确认后我们才动工，如果客户不确认或客户对此业务也是不清不楚我们就不做，如果客户已经确认了，我们就依照正式文档做，这样就责任很明确了。如果真正的客户需求有变，那么如果要按新需求做新的改动，则我们要重新商定提交时间，如果客户认可商定时间我们就做修改，如果客户不认可我们就不做修改，这样责任明确，相互管理，沟通起来就顺畅多了。
第四阶段，客户嫌我们提交的代码品质低，为了做好品质管控，我采取两种测试方法，一是让组员自己做单元测试，二是两人或多人做交叉测试，然后提交给我后我再一次整体测试，将bug按数量、难度系数等分类统计，然后作为考核绩效，和最终项目奖金挂钩，这样品质就相对高了很多。(当时公司没有QA，一切测试都是工程师自己)。
最后阶段，项目虽然按时提交了，但是都是组员加班换来的，总结得失如下：
成功之处：
1、 项目有系统雏形(UI)、功能需求说明书、接口资料等，能使开发人员更快的掌握系统。
2、 用AniCam做了录音，方便重复听取，帮助开发人员熟悉系统，使开发进度加快。
3、 开发人员自己讲解系统业务能使开发人员在最短时间内掌握系统。
4、 客户做了确认，责任分明，以免产生纠纷。
失败之处：
1、 被客户所摆布、跟着客户要求走，而忘了最初的共识，虽然客户是我们的上帝，但是不能认为客户的所有需求都是对的，要考虑到时间、成本。
2、 沟通不及时、沟通上有落差，沟通方法不正确，开发人员应只沟通业务问题，而不应涉及公司机密及其他影响项目进度等的问题。
3、 责任不明确、客户没给予明确的确认，责任归属不清。
4、 管理上的疏忽, 对组员开发情况掌握的不及时，未能做到提前预防。
5、 测试不过关，没有专门的QA做测试，测试时间紧、测试不够细致认真。
6、 第一次用C#+asp.net做web开发，所有开发人员都是新手
(案例完)
委外项目开发全过程注意事项
一、需求分析
1、 掌握系统业务流程，需求，差异等
2、 搜集相关文件，整理新的缺少文件，提出所需的其它文件
二、沟通
1、 和客户沟通
1)、项目开始前先让客户准备好充分的文件，如接口数据、规格书、项目注意事项、录音文件等
2)、在项目没有正式开始以前要仔细阅读相关文件，相关开发人员要频繁聚集讨论，提出争议点
3)、沟通时要以文件方式解读客户所表达的意思，减小落差
2、 和同事沟通
1)、项目负责人和组员的沟通，要了解组员的能力、实际遇到的问题；分配任务后要定时考察，看分配的任务是否合适，按时提交工作任务。从客户方取得信息要第一时间内mail给项目所有参与人员
2)、全面了解项目，了解组员能力，做到分配任务尽量合适
3)、同事之间的相互沟通，可以相互请教、讨论、学习
三、项目实际开发过程
1、 整理和规范注意事项，项目过程中依据注意事项进行
2、 列出详细的功能清单、项目跟踪表
3、 熟悉业务，及时和客户沟通
4、 明确我方和客户的责任
