项目需求该怎么做（四）

第二盏：学习业务知识。

    千万不要误会作需求就是将客户的想法记录下来，远比这复杂。作需求实际上是一个双方沟通的过程，将自己的想法用双方都能明白的语言表述出来。在我们行业应用系统的需求调研中就是客户描述自己的业务及想法，需求调研人员据此做出应对方案。所以，如果我们没有提前做业务知识的相关储备，那么沟通将会无法进展下去，或是很容易获取错误的需求信息。
  对业务知识的学习过程有多种途径。首先咱们不太可能进入一个完全陌生的业务领域，我指的是在需求调研阶段之前大多会有项目建设方案或或技术规范书之类的文档存在，通过对这种类型文档的阅读咱们大致可以了解项目的业务范围，再根据某些关键字到网上搜索该业务的相关介绍，有选择性的重点记录一些行业术语。等对客户的业务〔先仅限于合同相关的业务〕摸索出了大致的框架后，还可以在网上搜索关于此类业务的解决方案〔可以到竞争对手的网站上查询〕，如果运气不错，可以down到系统演示视频或试用版，用以了解此类系统大概构成，对我们的系统有无参考价值。
  另外在调研过程中也是一个很好的学习机会，但前提是你必须对业务知识有提前的储备〔可以用上述的方法来获取〕，否则一旦让客户知道我们对他们的业务一窍不通，其后果是对我们产生了怀疑，有谁愿意在值得怀疑的事情上浪费大把的时间呢？所以，在需求调研过程中只能起到对原有业务知识的细化以及理解程度的深化的作用。否则咱们一穷二白的去，到时候还是一无所有的回。
  在调研过程中很可能会接触到我们没接触过的专业术语或业务情景。这个时候，我们会面临是否向客户请教的问题，那要取决于我们是否已经取得用户的信任而定。如果还没有得到用户的信任，我一般先不对客户所谈的业务情景发出任何的评论，仅用笔和纸记录下来。等沟通结束就立即对这些不理解的业务上网寻求认知，再结合用户所谈的内容大致的制定出解决的办法，第二天再与客户交流时，心中有了底气，就可以对这些问题展开了讨论以抓取更多的需求信息。用咱们通俗的话讲，在于客户沟通打交到的过程中，咱们自己有时不懂也要装一下懂，我这里的装懂不是指满嘴跑火车的夸夸其谈，而更多是策略性的回避。

第三盏：规范实施流程。
  不管咱们是用重量级的cmmi项目过程管理还是选择了轻量级的敏捷项目管理，都必须让客户体会到咱们做事的专业方法及态度。不管是用户需求也好或是用户故事也好，其目的就是在于客户沟通的过程中获取客户想要什么的信息。倘若项目规模较大，涉及多部门，多业务，甚至与多系统的接口，那么需求调研过程必须是有序的且灵活可调整的，调研结果是可确认的同时又是可变更的。嗯，咱们面临的就是这些矛盾。
  首先得有计划，凡事预则立，不预则费。是统一规划、分步实施，还是分步规划、分步实施。这个问题会关系需求调研计划的制定。不过这也没多大关系，计划也不是不可调整的，但一定要有。随着调研过程的深入，发现现场调研环境不如我们所预估的乐观，需求之间关联也并不相互独立而存在业务关联。调整我们的计划以适应现场的变化，并将计划的新版本与客户项目负责人确认，同时寻求他的帮助。这样，我们会知道一段时间内〔或许很短〕要做什么，什么才是目标，同时也可随时检验我们的工作离目标还有多远。
  其次，咱需要有统一的模版记录用户的描述，也就是我在上一篇博客中提到的《需求规格书》。如果采用敏捷的方法，就使用用户故事模版。模版的好处在于让我们遵循统一的方式来与客户做有效的沟通，也可以避免我们漏掉某些细节问题。我们大多时候没有强大的客户资源让我们不停的与客户反复的交流，往往通过一次两次的反复沟通就深入到需求的细节中。因此，模版是指导我们调研工作的方向，同时也可作为调研的成果呈现给客户。敏捷方法强调双方的沟通而不是正规的文档，但其沟通的结果最终会整理成一个个体现用户价值的用户故事，这同样也可以交付给用户。
  最后，在条件允许的情况下要极力促成需求评审会议。在会议上将我们需求调研成果向客户团队展示，对所有的需求做简单的回顾，只讨论我们的系统会做什么，不涉及怎么做。因为我们在调研过程中会搜集各种角色用户的需求，每个人只会谈及自己所那部分的业务需求。借此会议，也可以让大对系统或某个子系统有全貌的了解，同时也表明我们的需求调研阶段暂时结束，进入到设计开发阶段。需求评审会上需要向客户说明的一点是后续的工作中我们乐于接收需求的变更，不要给客户带来要对需求承担责任的压力，因为谁也无法保证客户的业务是一成不变的，我们的系统在不断重构的过程中应该考虑业务易发生变更的地方并使其便于灵活调整。