段时间了，一直没时间真正动手用一用。我看这个项目就不错，不算太大，就用它试试吧！”。
“好主意！”，大家纷纷表示赞同。
……
“约定时间已经过去1个月，现在项目进展到底如何了？什么时候可以交付？”，客户方CIO质问到。
分析员小张：“现在主要困扰我们的是一些需求细节一直存在变化，开发团队又有了一些人离职，所以……”（真正的情况是：由于团队第一次使用Hibernate，有些数据访问层的问题一直没有有效解决，导致进展不断失控。）
现在许多名称中包含“需求分析”、“系统分析”之类的职位，大多是由技术骨干担任的，因此在工作中很少从业务角度进行分析，更多还是追求技术框架、新技术。对于这种现象，究其根源，关键还在于“技术能力”对他们的未来发展更为重要，而“业务能力”却不是那么重要。但为了使需求工作有更好的提高，我会强烈呼吁那些Title上有“分析”之类名称的人们，加强业务分析吧！
编程人员：断章取义
对于第4幅图，可以用一句生动的话来概括：“你要绳子，我给你了；你要木板，我也给你了；你为什么说这不是你想要的呢？”。我想程序员也有类似的问题想问自己的客户，“你要文本框，我提供了；你要一个表单，我也有了；你为什么说这个程序不是你想要的呢？”。这让我想起了这样一幕：
案例&场景：
叮铃铃……，程序员小赵的电话急促地响起。小赵刚接起电话就听到了对面迫不急待地抱怨声“仓库管理员反应，入库模块没法使用！你马上查一下，尽快解决一下！”。
小赵放下电话就开始Check out、Builder、Run、Debug……等一系列操作。经过一番测试之后，小赵没好气地提起电话回复说：“这些客户真是笨！这哪有问题，肯定是操作上出了问题！我怎么用都是好的，你们客户服务的人也应该加强对用户的培训，别什么事都扔给我们！”。
……
可是，问题仍然没有解决！开发人员到了现场一看，终于发现了问题的所在：这是一套基于B/S的仓库管理系统，在入库时，仓库管理员首先需要录入入库单，然后填入“验收情况”，最后点击“入库”按钮。但当仓库管理员录入完入库单，逐一验过入库货物之后再回到电脑前时，等待他的却是一个令其不知所措的问题，Session超期！
一肚子气的小赵一个电话就打到需求分析员小钱那里：“你们的需求是怎么写的！这么重要的东西也不写明白，我们怎么知道填完入库单后要验货那么长时间，才填写验收情况呀！”。
“哦，这也算是需求吗？如果这也算的话，那我们岂不成了业务人员了！”，小钱很强势地回答到。
这是需求吗？也许很多读者会有不同的看法！但如果缺乏对业务场景的了解，又如何能够真正理解需求呢？断了“业务场景”之章，必将导致取出的“需求”之义有所偏差呀！
作者简介：中国系统分析员顾问团软件工程首席顾问，中国软件技术大会杰出贡献专家，资深咨询顾问。主要研究领域为需求工程、系统分析与设计、软件估算，致力于推动软件工程方法论的落地应用。本文节选（并改编）于笔者新著《软件需求最佳实践：SERU过程框架原理与应用》（电子工业出版社博文视点）
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
