体会客户现场
来源:互联网 发布:淘宝买衣服怎么问客服 编辑:程序博客网 时间:2024/06/10 19:06
敏捷宣言中,其中一点就是强调客户现场。其宗旨是要求客户在开发现场提供业务方面的指导,开发人员重点关注技术方面。如果没有客户在场,则需要提供一个可以充当客户角色的人员,例如软件构架师。最近负责了一个法国的开源项目的外包工作,采用的就是客户现场。
法方派驻一人在项目组,为我们讲解需求,提供已有模块的技术支持,对开发过程中的不确定的地方进行解释。虽然和法方可以通过skype交流,但是这种面对面的交流无疑是效果最好的,最有效率的,避免了很多容易出现的误会。同时,对于一些已有模块的改动,有人在现场指导,肯定比通过email让人能更快上手。
好坏是通过比较而知的。以前在HW经历过CMM开发流程。HW的IPD,CMM流程在业内来说应该算是比较规范的,具有一定的代表性。开发组首先从系统组得到DS,以此写出需求分析,这里的需求分析完全是开发人员的主观臆断,并不一定符合客户的真实想法。开发人员也没有途径能得到客户的真实想法。虽然SRS写完后,会召集相关人员进行检视,但是限于相关人员精力有限,能力有限等原因,一般是检视不出什么关键问题的。而且很多需求系统组其实也是一知半解,估计其也没有机会能和客户面对面交流。SRS定后,一般是不能再改了,除非在技术实现上有难度,或者实现结果与设计有出入。另外,HW要求实现要和SRS完全一致,不能有一丝差异。这主要是测试部门提出的。测试部门希望能够降低测试验收的难度,避免出现任何待讨论的东西,这样也可以降低对测试人员素质的要求。这样的话,测试人员的需求验收一般就不用付出太大的脑力劳动,只要对照文档就可以了(验收测试都是手工进行的)。
因为客户的真实意愿是不知道的,所以就由测试人员充当了客户的角色。测试人员也是本着宁可多一万,不能少一个的原则(他们也有来自下游的压力)。就把这种压力传达给开发人员。这就是开发人员和测试人员不断扯皮的根源。测试人员往往会要求开发人员作出十全十美的方案。殊不知每种方案都是有利有弊的。所以开发人员经常会收到测试人员提出的一些在技术上难以解决的问题。多数时候,测试人员为了不承担责任,不会给出建议的解决方案的,同时,研发人员给出的解决方案,测试人员又认为不可接受。这个时候,如果有客户代表在现场说明,我要的是什么样子。相信一切争论都可以避免。客户真实意愿不明朗,是整个研发体系效率不高的一个重要原因。对于hw这样的大公司来说,每个项目组都有一个客户在现场是不太现实。但是可以派驻和客户交流需求的那个人。一件事情,传的人越多,就越容易走样。每个人都在其中加入了自己的理解。
目前这个项目,在实施过程中,除了人员的技术水平因素外,没有在业务方面产生任何的误解,冗余,遗漏,在效率方面还是控制的很不错的。
一直想写敏捷越狱,一直没有时间。要忙的事情太多了。
法方派驻一人在项目组,为我们讲解需求,提供已有模块的技术支持,对开发过程中的不确定的地方进行解释。虽然和法方可以通过skype交流,但是这种面对面的交流无疑是效果最好的,最有效率的,避免了很多容易出现的误会。同时,对于一些已有模块的改动,有人在现场指导,肯定比通过email让人能更快上手。
好坏是通过比较而知的。以前在HW经历过CMM开发流程。HW的IPD,CMM流程在业内来说应该算是比较规范的,具有一定的代表性。开发组首先从系统组得到DS,以此写出需求分析,这里的需求分析完全是开发人员的主观臆断,并不一定符合客户的真实想法。开发人员也没有途径能得到客户的真实想法。虽然SRS写完后,会召集相关人员进行检视,但是限于相关人员精力有限,能力有限等原因,一般是检视不出什么关键问题的。而且很多需求系统组其实也是一知半解,估计其也没有机会能和客户面对面交流。SRS定后,一般是不能再改了,除非在技术实现上有难度,或者实现结果与设计有出入。另外,HW要求实现要和SRS完全一致,不能有一丝差异。这主要是测试部门提出的。测试部门希望能够降低测试验收的难度,避免出现任何待讨论的东西,这样也可以降低对测试人员素质的要求。这样的话,测试人员的需求验收一般就不用付出太大的脑力劳动,只要对照文档就可以了(验收测试都是手工进行的)。
因为客户的真实意愿是不知道的,所以就由测试人员充当了客户的角色。测试人员也是本着宁可多一万,不能少一个的原则(他们也有来自下游的压力)。就把这种压力传达给开发人员。这就是开发人员和测试人员不断扯皮的根源。测试人员往往会要求开发人员作出十全十美的方案。殊不知每种方案都是有利有弊的。所以开发人员经常会收到测试人员提出的一些在技术上难以解决的问题。多数时候,测试人员为了不承担责任,不会给出建议的解决方案的,同时,研发人员给出的解决方案,测试人员又认为不可接受。这个时候,如果有客户代表在现场说明,我要的是什么样子。相信一切争论都可以避免。客户真实意愿不明朗,是整个研发体系效率不高的一个重要原因。对于hw这样的大公司来说,每个项目组都有一个客户在现场是不太现实。但是可以派驻和客户交流需求的那个人。一件事情,传的人越多,就越容易走样。每个人都在其中加入了自己的理解。
目前这个项目,在实施过程中,除了人员的技术水平因素外,没有在业务方面产生任何的误解,冗余,遗漏,在效率方面还是控制的很不错的。
一直想写敏捷越狱,一直没有时间。要忙的事情太多了。
- 体会客户现场
- 体会客户现场
- 论现场跟客户演示软件产品
- IT项目客户现场服务规范
- 解读极限编程的十二大原则——现场客户
- 解读极限编程的十二大原则——现场客户
- 在现场如何面对oracle的服务客户
- 在现场如何面对oracle的服务客户
- 客户现场进行路由设置及环境搭建的过程
- 失败的一次客户现场软件实施经历总结
- 客户现场更新数据库和程序的步骤
- 在客户现场项目中编译java源文件
- 项目管理中与客户交流的一些体会
- 为什么老板利用激励提升在客户现场工作员工的生产力,反而可能降低对客户的价值?
- Subversion实践案例——客户现场模式的分布式开发
- 2011年10月19日星期三(客户现场总结)
- UNIX网络编程——为每个客户现场分派一个线程(简单示例参考)
- 体会!
- writely is cool!
- 大家好!
- Powered by django的中文站点
- SQL Server实用经验与技巧大汇集
- 黄花城之行-未到四海
- 体会客户现场
- 管理中的帕金森定律
- 谈谈打字
- [原创]Memcache的使用和协议分析详解
- C++学习笔记-后台服务程序开发模式
- 利用Servlet实现文件的下载
- 玫瑰和刺
- crond 自动运行每天重启计算机
- javascript 简单高效判断数据类型 系列函数 By shawl.qiu