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

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

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

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

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

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

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

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

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