《产品研发过程实践》（18）需求人员

作者:asky 日期:2007-04-29

字体大小: 小中大

需求人员，是一个项目成功还是失败的，最重要的一环（我不想讲，是最重要的几环中的一环，事实上，任何人员，都决定着项目的生死，我们说他是最重要的一环，是因为我们绝大多数项目，失败的首要原因是项目需求模糊，混乱）。

做为一个需求人员，你需要分析客户的需求列表，进行需求获取，需求分析的工作，并且为团队整体工作，打下一个良好的基础。同时，在项目过程中，我希望他能够有相当的精力，来维护整个需求文档，因为这是我们开发软件的唯一的一份准则。

目前，需求获取和需求分析方面，有一些很不错的资料，在Xprogrammer和ITURL网站中，都有很大的篇幅去说明在和客户沟通过程中的一些注意事项，以及使用各种工具，来分析，挖掘需求的技巧。而且，不管你使用什么工具，不管你使用何种分析方式，我们还是需要认识到，需求分析，还是需要很大程度上依靠着需求人员的经验。这些经验往往是最难获取的，也是最决定成败的一件事情。

其他的不多说了，事实上，在绝大多数小型项目中（7-8人的项目组，半年以下的研发时间），我强烈建议不设置专门的需求人员（也许有些人说这是小作坊，小作坊也没有什么不好的，我们最关心的是产生出来的东西是什么，而不是到底如何产生出来的，流程是为目的服务的，而不是以流程本身做为目的的。），由PM（我希望他必须具有良好的沟通能力和一些些商业知识以及谈判技巧），技术设计人员（他首先应该具备清晰的思路，能够在需求阶段从技术角度提出一些解决方案，以供客户选择，并且我希望他能够把在需求过程中，所吸收到的东西，能够贯穿到项目全部过程中），测试主管（我首先需要他具备良好的整体思维能力，能够敏锐地发现需求的不完善或者不完整的地方，他需要从可测试性的角度来看待需求）；一起来进行需求的获取和分析。

在需求获取和分析阶段，有几个问题，是绝对不能犯的：

1.          过多地从设计、开发角度，而不是从客户本身来考虑问题。当然，这一点有时候是难以避免的，比如我们很多项目，是在合同额已经确立的情况下，才进行需求的获取和分析，所以，严格意义上要完全避免这个问题，是难以做到的。比如我举一个例子，用户系统的用户注册量有几千万甚至更多，而且对登录速度要求很高，你会如何做？我想你一定会倾向于使用LDAP来做这一块。但是，过于多地考虑如何实现，就不应该了。在需求阶段，我们还是讨论实现什么，而不去考虑如何实现的问题。

2.          让技术为沟通买单，我记得，在一次面试中，对方公司的老总问过我一个问题：“如果你们团队中，PM和技术人员对于需求的认知不同，那么你如何办”。很简单，我们也许都错了，去问客户，不要怕问客户，害怕别人觉得你很烦，甚至觉得客户很难相处。于是，自己设想一个过程，这种由于沟通的缺乏，而使得工作白费的事情恐怕太多了吧。不要让技术为沟通买单，也许很多技术出身的人员会倾向于这一点，希望通过自己多完成一些工作，来弥补自己在沟通上的不足，但是经验表明，这种解决方式根本就是南辕北辙。我举一个例子，在一次部署过程中，我们的一个高级工程师，在配置短信网关的时候，发现以前配置完成的短信网关，不能正常工作了。当时我们怀疑是运营商的短信中心发生了一些问题（结果证明也是如此），我们的工程师去和运营商沟通，运营商的一个技术人员说我们做错了（但是实际上并没有错，而且这一点在北京的同事给予了支持，说明了很多次并没有问题）。但是我们的工程师不再愿意和对方进行沟通了，让我们发送了一份CMPP协议，并且磕了1个下午来学习CMPP，然后开始现场修改代码（并且没有做好版本控制，以至于找不到当时调试通过的代码了），而且更奇怪的是，这次修改代码的目的仅仅是想按照别人说的做，然后肯定还是不能联通，以此证明对方是错误的。我很奇怪这样的解决方式，难道我们真的认为，一个下午的CMPP协议的学习，能够顶得上别人半年的开发经验吗？而且和运营商的工程师如此较劲，有必要吗？为什么不进行再次沟通呢？即使再次沟通存在困难，为什么不通过我们的合作公司（我们和他们一起做这个项目），和运营商进行沟通呢？答复是：我不想别人认为我们不懂CMPP！这件事情的结果有三：第一，合作公司认为，为什么你们的程序如此不稳定？突然好，突然不好的，而且很不理解，为什么你们不能提供一份通过连通性测试的结果，来证明你们是正确的？第二，现场大量代码的修改，而且缺乏版本控制，使得代码最后只能回滚到到现场的第一天的状态，所有在现场所做的调试工作，全部白费了；第三，我们的两个现场工程师几乎通宵了3天，看着他们疲惫的眼神，我简直不知道应该如何去说，说你不称职吧，有点不忍心，毕竟如此旺盛的斗志是我希望看见的，表扬你吧，我简直觉得这种忙碌是自己折腾出来的。请记住，无论你做什么职位，在哪个领域，如果缺少良好的沟通意识和沟通能力，都将使你的工作很难推进。我能够理解沟通中存在的难度，至少在我们很多工程师的心目中，他比在4个小时内，读懂整个CMPP协议要困难，但是，无论你如何认为，也无论你技术能力多么出色，企图用技术手段来解决沟通问题，是不太现实的。

3.          不要自以为是；这一点我说过很多次，这里就不展开了，老老实实地向你的客户学习，他们才是你的老师，而且他们以前没有IT系统辅助他们的工作，他们那么多年也能工作得很好，所以不存在你教他们应该如何做他们的工作，你只是辅助他们更轻松，更方便得完成他们已经完成得很好的工作。记住这一点，不要自以为是！

4.          尽可能的简单，你今天落实下来的工作，将来都是要实现在代码中的，今天一段100字的需求描述，可能需要你在设计阶段付出20人时的时间，在编码阶段花费30-40人时，在测试阶段付出50-60人时，在维护阶段付出100以上的人时，同时，也存在也许能力不足，导致的概念混乱，而导致的高昂的平衡成本，这是极其划不来的。不要仅仅把成本想成一段代码，在整个软件过程中，这将随着时间增长，而增加可怕得多的成本。如果你不明白这一点，请首先去明白这一点，不然你将把项目组带入灾难中。

最后说一句，为什么对于小型的团队（当然，上百人的项目组，项目费用几千万甚至上亿，团队在N个国家进行日不落的开发和测试，项目经理在1年中仅仅在视频会议上见过2次等等，这种项目，我没有做过，而且也很明白一点，这份文档中，所列出的很多经验和教训，并不适合这种项目，因为在这种项目中，无所谓成本高或者成本低，你必须依赖于非面对面沟通）来说，我建议需求人员由项目组成员来一起做？理论上来说，应该有独立的需求人员，然后传递需求规约书或者需求描述给下面的设计人员，但是，这将使得需求人员的压力非常大，他因为不知道后续阅读者会是谁，从而需要把所有的细节都包含进入文档，这将使得文档非常庞大和难以维护；同时更可怕的一点是，需求规约书是用自然语言进行描述的，进行一次需求的传递，必然发生理解上的扭曲。那么我们也许更好的选择是，那就是尽可能地让项目组成员加入需求过程。OK，我的概念是，在最容易错误的领域内，即使多投入一些成本，还是有必要的。这一点，是我在项目实践过程中的一个坚持，因为我不是理论派的人，我只知道，在项目过程中，进行大量的人员层次划分，将使得沟通成本急剧上升，所以，但凡有可能，对于一般的小团队项目来说，还是多讲一些实际，少讲一些理论比较好一些。