项目管理沙龙第八次聚会纪要

长平狐 发布于 2012/10/23 14:16
阅读 92
收藏 0

【开源中国 APP 全新上线】“动弹” 回归、集成大模型对话、畅读技术报告”

项目管理沙龙第八次聚会纪要

本次沙龙依然是NSEC的敏捷经验总结。这次依然谈到了客户与需求的问题。因为客户和开发组不在同一个地区,所以客户完全没有参与到项目的开发工作,所有的沟通都通过项目经理来进行。从开发人员的角度看,需求变化最大的问题是开发人员无法确定是否真的是对客户有用的。客户首先是自己有很多的想法,变来变去,PM也因为距离的关系,无法和客户面对面沟通,所以也就只能拍脑袋和猜谜语。结果开发人员心里没底,做不出成就感,心情自然也就好不起来。引出的问题就是:开发人员到底怎么办?

面对这种情况,经过讨论,大家认为首先还是要充分信任PM,但是PM也有责任去和客户充分沟通。这个时候,我们一直强调的“原型法”就会有很大的作用。原型工具可以有很多种,比如一连串简单的html页面,或者一个ppt演示。前者的好处是可以快速地完整演示一个流程,后者的好处是可以将一些用户界面效果也同时演示出来。总之,原型工具就是那种可以快速构建,快速抛弃的东西。非常适合用在客户需求不稳定甚至不成形的情况下。

实际上,NSEC的需求问题根源并不在客户,也不在PM,而是和其他大多数项目一样,缺少了一个角色,“业务分析师”,简称BA。许多项目的BA都由PM担任,或者商务人员担任,但是他们要么身兼多职,要么没有受过专门的业务分析训练,无法充分引导客户的需求,结果就造成了需求不明确,不稳定等问题。引用沙龙成员的一句话:程序员不反对变更,但是反对浪费!

BA的作用很重要,在敏捷结对中,BA的结对对象就是客户代表。他的工作就是负责引导客户,让他们的需求变得更明确,更稳定。原型法是一种很好的需求引导方法,就像我们一直强调的,“客户不知道自己要什么,但是明确知道自己不要什么”,原型法的作用就是让客户能够不断地否定自己的想法,最终形成一个明确稳定的客户想要的东西。这个也就是项目组梦寐以求的“稳定的”需求。其实BA的工具远远不止这些,“语法分析”也是BA的工作利器。根据客户所说的语句,将其划分为名词、动词、形容词和主语、谓语、宾语。根据每一个词语的特性,我们可以整理出一系列有针对的问题。一个有经验的BA,只要客户不断地开口说话,就会将客户的所有需求都问出来。具体的方法,我们可以在以后的沙龙中详细探讨。

NSEC的另外一个问题是客户不定期不定时地要求项目组发布成果。针对这种情况,我们觉得自动化构建和上次谈到的UAT环境就很有作用了。这种问题的出现,根源其实还是在客户需求的不稳定上。当然,定期发布成果并让客户能够感受到进度的变化,也是非常重要的。

“没有验收标准文档”是另外一个NSEC的问题。从我们的角度看,这个是中国几乎所有项目的共同问题。理论上,我们会在中标之后对客户进行需求调研,然后把形成的需求规格说明书作为合同的附件,并以此作为客户验收的标准。实际上能够做到这种程度的项目几乎没有,即使做到了,这个合同附件中的需求也会在开发过程中不断地变更,最终变得面目全非。有经验的人肯定会拿出“变更控制”的办法来,可是实际项目过程中,有多少客户愿意每次需求变更都来签字呢?又有多少客户代表因为要签字就放弃需求变更呢?答案都是“很少”甚至“没有”。很多项目就是因为限制客户变更需求,或者变更需求过程中和客户经常产生不愉快,导致客户关系恶化,最终项目失败。这个也是“传统”项目和“敏捷”项目的最大的区别。

从敏捷的角度去看,项目组完全接受变更所带来的影响,但是所有的变更都不能影响当前正在进行的迭代过程,所有的变更最快也要到下一个迭代才能生效。但是真的有紧急的需求变更怎么办?事实上并不存在什么“紧急”的需求变更,因为所有的需求的实现都是需要有时间的,需求是一种未来性质的东西,项目组一定要把“需求”和“BUG”区分清楚,不能用解决BUG的方法去应对“需求变更”(这个也是大多数项目组常犯的错误,任务没有优先级的结果就是经常性的加班)。针对一个需求变更,除非它能够让当前迭代的某个任务即刻作废,我们才需要即时改变迭代的任务安排,否则本次迭代不受影响。

没有验收标准文档是一个问题,但是“依赖客户进行测试”是另外一个更严重的问题。因为之前所讲的客户不定期要求项目发布,所以项目组在发布的时候的时间都很紧张,加上平时没有充分的测试,所以项目组就希望客户能够抽出人力去做验收测试。实际上,客户几乎不会去做什么认真的测试。有与会成员认为“依赖客户进行测试”本身就是项目的一种失败。


原文链接: http://www.cnblogs.com/BigTall/archive/2011/11/27/2265397.html
加载中
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部