锁定老帖子 主题:关于用户故事这件事
该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2005-12-02
partech兄上面举的例子我觉得就挺危险的,如果按照kent的这个隐喻,就等于把开发团队的命运交到“司机”手中了。做小东西还好,失败了公司也能承受,但是做大了,不管做什么都要有一个成本核算和风险管理。这种“现场客户是司机”的做法第一个就通不过风险评估。项目真失败了,谁承担责任?总不能是客户吧,就中国这个环境。
照我们的经验,这个开车的应该还是我们自己团队中的人,客户团队可以参与进来,但他们只是配角,关键时候能提个醒儿就不错了。 另外我记得partech兄以前说过,小版本发布,客户很可能根本就不感兴趣,对于什么开发计划他们就更懒得理。 一句话,引入现场客户,首先要通过风险评估。控制不了风险,那还是咱们自己人来开车更好。 |
|
返回顶楼 | |
发表时间:2005-12-02
snomile 写道 partech兄上面举的例子我觉得就挺危险的,如果按照kent的这个隐喻,就等于把开发团队的命运交到“司机”手中了。做小东西还好,失败了公司也能承受,但是做大了,不管做什么都要有一个成本核算和风险管理。这种“现场客户是司机”的做法第一个就通不过风险评估。项目真失败了,谁承担责任?总不能是客户吧,就中国这个环境。
照我们的经验,这个开车的应该还是我们自己团队中的人,客户团队可以参与进来,但他们只是配角,关键时候能提个醒儿就不错了。 另外我记得partech兄以前说过,小版本发布,客户很可能根本就不感兴趣,对于什么开发计划他们就更懒得理。 一句话,引入现场客户,首先要通过风险评估。控制不了风险,那还是咱们自己人来开车更好。 危险麽? 客户团队的成员本来就包括了通常意义上的开发人员,如:测试员、产品经理、客户代理、交互设计员。里面已经有自己人了,自己人的主要任务是分析清楚哪些是客户的真正重要的需求,哪些是锦上添花的东西,以及紧迫的程度。 开发团队主导的过程,有可能会导致,开发出来的产品,不是客户需要的。 开发人员经常抱怨,客户老是变来变去,没完没了,经常出现这样的情景,就有可能是开发人员当司机导致的。 好了,如果你觉得这个隐喻危险,那我换一下,“打的”,客户是打的的人,司机是经过专业训练的驾驶员,并且要熟悉道路,打的的人,告诉实际去哪里,司机负责具体的驾驶;但是打的的人为了防止司机绕路,可以指定具体的线路。。。。。。 |
|
返回顶楼 | |
发表时间:2005-12-05
所以说客户团队这个名字容易误导人,让人认为真的是客户构成的团队,其实真实的客户在里面只是一个辅助角色——与传统开发过程中客户的地位没什么区别。
|
|
返回顶楼 | |
发表时间:2005-12-05
那么我们去打的,我们也成辅助角色了,出租车司机到成了老大。赫赫
客户团队强调的是,开发应由客户的价值来主导。 |
|
返回顶楼 | |
发表时间:2005-12-08
partech 写道 开发团队主导的过程,有可能会导致,开发出来的产品,不是客户需要的。 开发人员经常抱怨,客户老是变来变去,没完没了,经常出现这样的情景,就有可能是开发人员当司机导致的。 有了客户团队,就能避免这样的问题了吗? 你如何解决客户团队内部的客户和业务人员之间的矛盾? 把业务分析人员从传统的开发团队中剥离出来放到“客户团队”之中,我觉得只是一种文字游戏而已 如果这个业务人员不行,那开发团队照样会陷入无休止的需求变更。而这个业务人员是无法负起责任的,最终用户依然可以推卸责任。 |
|
返回顶楼 | |
发表时间:2005-12-09
clamp 写道 有了客户团队,就能避免这样的问题了吗? 你如何解决客户团队内部的客户和业务人员之间的矛盾? 把业务分析人员从传统的开发团队中剥离出来放到“客户团队”之中,我觉得只是一种文字游戏而已 如果这个业务人员不行,那开发团队照样会陷入无休止的需求变更。而这个业务人员是无法负起责任的,最终用户依然可以推卸责任。 你这里提到的一半问题,涉及到人和人交往的问题,这已经超过了过程的范畴。 另外,业务人员行不行,也同过程无关。不能象神化一样,指望人能完成超过他能力的事情。 基于每种角色都有局限性的事实,客户团队的构成,应当仅可能的广泛,让各种角色都能发出声音,这样就可以提高开发系统的成功可能。 |
|
返回顶楼 | |
发表时间:2005-12-09
partech 写道 clamp 写道 有了客户团队,就能避免这样的问题了吗? 你如何解决客户团队内部的客户和业务人员之间的矛盾? 把业务分析人员从传统的开发团队中剥离出来放到“客户团队”之中,我觉得只是一种文字游戏而已 如果这个业务人员不行,那开发团队照样会陷入无休止的需求变更。而这个业务人员是无法负起责任的,最终用户依然可以推卸责任。 你这里提到的一半问题,涉及到人和人交往的问题,这已经超过了过程的范畴。 另外,业务人员行不行,也同过程无关。不能象神化一样,指望人能完成超过他能力的事情。 基于每种角色都有局限性的事实,客户团队的构成,应当仅可能的广泛,让各种角色都能发出声音,这样就可以提高开发系统的成功可能。 这不是人和人交往的问题,而是涉及到合同执行边界的问题,也就是需求变更的责任到底由谁来负。 "客户团队"内部有冲突时,尤其是客户团队中的实际用户和业务代表发生冲突时,由谁来做最后决策? 需求范围控制的责任由谁来负责? 从控制需求和沟通成本的角度考虑,客户团队的构成不应当尽可能的广泛,但是客户团队获取需求的来源应当尽可能广泛。 |
|
返回顶楼 | |
发表时间:2005-12-09
clamp 写道 这不是人和人交往的问题,而是涉及到合同执行边界的问题,也就是需求变更的责任到底由谁来负。
"客户团队"内部有冲突时,尤其是客户团队中的实际用户和业务代表发生冲突时,由谁来做最后决策? 需求范围控制的责任由谁来负责? 从控制需求和沟通成本的角度考虑,客户团队的构成不应当尽可能的广泛,但是客户团队获取需求的来源应当尽可能广泛。 还记得敏捷宣言的内容吗? 需求是可以协商和变化的。协调和交流不好才可能产生冲突。 来源广泛是没办法保证的,这完全依赖于做需求的人的个人能力,如果他忽视了某些用户,那么风险仍然存在。 客户在项目中,是一等公民,而不是二等。客户有权得到有用的系统,用户有权要求易用的系统,而能够保证这点最有效的方法,就是让他们直接参与。 而这样的做法,会有效的减少冲突,因为客户参与了开发。 |
|
返回顶楼 | |
发表时间:2005-12-10
partech 写道 clamp 写道 这不是人和人交往的问题,而是涉及到合同执行边界的问题,也就是需求变更的责任到底由谁来负。
"客户团队"内部有冲突时,尤其是客户团队中的实际用户和业务代表发生冲突时,由谁来做最后决策? 需求范围控制的责任由谁来负责? 从控制需求和沟通成本的角度考虑,客户团队的构成不应当尽可能的广泛,但是客户团队获取需求的来源应当尽可能广泛。 还记得敏捷宣言的内容吗? 需求是可以协商和变化的。协调和交流不好才可能产生冲突。 来源广泛是没办法保证的,这完全依赖于做需求的人的个人能力,如果他忽视了某些用户,那么风险仍然存在。 客户在项目中,是一等公民,而不是二等。客户有权得到有用的系统,用户有权要求易用的系统,而能够保证这点最有效的方法,就是让他们直接参与。 而这样的做法,会有效的减少冲突,因为客户参与了开发。 我认为你一直在不加区分的使用“客户”、“用户”、“客户团队”这样一些概念,我很反对这样的做法。 按照我的理解,“客户”就是甲方,也就是签定合同的,客户是一个整体,客户不是一个单独的个人。 “用户”,是最终使用开发完成的系统的个人,用户是一个个的个人。 “客户团队”,是和项目有关的,提出具体项目需求的一个团队,客户团队应当尽量代表“客户”的利益。客户团队中和客户方面有关的人一般包括领导+项目负责人+用户代表。 在这里,必须要区分的就是“用户”和“客户”的区别,最终要使用系统的个人的需求往往有可能和“客户”的整体需求相矛盾,尤其是在推广管理型系统时。 “若干个具体用户需求的集合”不完全等价于“客户”需求 了解/平衡/控制“客户团队”中不同人员的需求,考察这些需求是不是完整的反映了“客户”需求,我认为这是需求开发方面最大的难点,而无论是传统需求分析方法还是敏捷方法,都没有解决这个问题。 用户故事只是一种需求分析的方法,它也不能解决这个问题。 敏捷方法中对这个问题的解决有贡献的是尽早的提交系统,从而使得客户内部不同用户之间的矛盾可以最快的反应出来,强迫客户方面解决这个问题。 |
|
返回顶楼 | |
发表时间:2005-12-11
客户和用户的矛盾其实比较好处理,因为不是开发团队同客户/用户的矛盾。
属于他们自己的内部矛盾。开发团队可以要求他们取得一致后,再给一个答复。 从讨论中可以看出,你们开发中,似乎总是充满了各种很难调和的“矛盾”。究竟为什么会有这么多矛盾勒? 同客户打交道固然繁琐,无味。但想想整天辛勤工作的主要目的不就是为了支持客户正常或更好的运作吗?多加几分理解和耐心,很多问题就会烟消云散。解决矛盾的最好方法就是培养不产生矛盾的环境,祝顺利。 |
|
返回顶楼 | |