hello，大家好！我是小婧。今天是国庆假期的第一天，不知道你有怎样美好的计划。我们的共读活动从今天开始啦，希望大家能和小婧一起完成共读的任务。建议的方式是，你先自己读完《软件需求最佳实践》这本书的第一章，然后再来看小婧写的下面的内容，最后记得将你的所想以留言的方式写在下面哦。祝大家假期愉快，阅读愉快！

2016-10-01 《软件需求最佳实践》徐锋著

第1章 需求实践现状分析

本章从分析软件失败的根源入手，对问题现象进行了描述，紧接着对问题进行了分析，最后提出了解决方案。

1.软件项目失败的根源

通过权威的报告，我们可以看出：
“软件项目十大败因”中，有五项是与软件需求直接相关的。
A 不完整的需求
什么样的需求才是完整的呢？这点显然需要由用户代表来做评定。而因为以下的原因，阻碍了用户代表进行需求完整性的判定：

• a“软件需求规格说明书”写的太多技术化，用户代表看不懂。
• b 验证变成了确认。
• c 试图让一个人看完整个“软件需求规格说明书”，并且指出错误。

*小婧：这点其实在我工作的领域非常常见，我们一般在做完需求规格后会经历评审，其实是一种转阶段的标志，也就是说客户代表签字确认，我们这个阶段算是结束。但是客户代表是否能真正代表所有客户，我们并不能确定，就连客户也不能确定。所以很少有客户能在这个阶段指出我们需求规格中的错误。另外，更加明显的是，客户能看得懂我们需求规格的内容很少，最多能看懂业务流程图，对于我们进行的其他技术化的描述，完全看不懂。如果我们再不进行解说，只是丢给用户代表去看，成效其实非常低，只是走个过场，签个字罢了。

B缺乏用户参与

• a事不关己高高挂起
• b逃离无趣区
• c被你赶走

C不切实际的用户期望
D需求变更频繁

• a需求变更分析不到位
• b用户并未察觉变更的代价
  E提供了不再需要的

*小婧：哪些功能需要，哪些功能不需要，这点到底由谁说了算？曾经遇到过开发说，用户肯定不会这么做的，是个正常人就肯定不会这么操作。但是事实上，用户还真就这么操作了。有的时候我们花费了很大的精力去完成一项功能，但是并不知道这个功能用户到底试用的情况是怎样的。大家都听说过二八原则：系统中20%的功能被80%的用户使用，另外20%的功能可能一次都不会被用到。那么我们如果把我们80%的精力都花在这20%的功能的改进上，是不是会更有效率呢？如何统计是个问题，但是研发同事肯定有办法，不论是记录日志，还是暗藏计数器，或者统计某个webservice调用次数，都是办法。定期的收集这些数据，为我们的产品做改进是非常有目的性和效率的。

2.透过表象，分析本质

A需求变更频繁
虽然同样是需求变更，其诱因也是不同的，有的是对原有需求的背离，有的是原有需求的遗漏，有的是业务流程变化引起的……针对不同的病症有不同的原因，要用不同的药。

*小婧：其实我觉得每个软件产品、软件项目的性质不同，其需求变更的种类也会不一样。不需要很教条的按照书上的分类方法去进行分类。但是，肯定是要分类的，特别是对一些经常发生的类型进行细分，即划分子类。只有统计、分析后，我们才能更好的去解决这个问题。而不是变更了，也不找原因，下次接着变。我以前遇到一个事例，原先我们产品的表单有一个选项“其他”，后来客户说应该叫“其它”，让我们改。我们改了后，月底统计分析时出问题了，统计出了两个QITA。这就是变更没做好分析。解决方法其实应该用相同的code进行统计，而不是直接取值。

B上线阻力大

• a利益冲突

*小婧：我觉得这部分问题发生的原因就是干系人分析做的不到位。

• b工作量增大

*小婧：这个问题在项目实施中非常常见，比如以前请假就打个电话或者发个邮件说一声，现在要上OA走提交申请单走流程。这个部分我觉得“洗脑”很重要，我们要向用户阐明，从整个企业的层面来说，这样做的好处。

• c运行效果差

*小婧：这在传统软件行业非常普遍，就是故事编的挺好，牛皮吹的挺大，真正实施后却用不起来。也就是方案无法落地。

• d完全崩溃

*小婧：对非功能需求的忽视，往往会导致这样的问题。而需求人员在进行非功能需求的分析时总是采取“定性”的方式：高可靠性，高灵活性……这类无法测试，无法验证的等于没说。最好是制定全系统通用的非功能性指标，进行量化。

3.方法论与需求工作

A.计算模式

*小婧：我刚工作的时候，C/S架构大行其道，很多用户用C/S用习惯了，总是以C/S的标准要求我们B/S的系统，于是我们要设计出“暂存”的功能……但是随着现在互联网时代的开启和到来，这种现象已经好很多了。

B.软件工程方法论

*小婧：关于传统的“瀑布”和迭代的“敏捷”之争，我已经不想多说什么了。我想说的是，一切不做重构的敏捷就是耍流氓。别总想着为不写文档找借口。

C.开发思想

• a.成熟度
• b.溯源
• c.了解局限性

*小婧：不知道别的团队怎么样，我们的团队在这个方面很谨慎。一般要对一项新的技术进行充分的预研、论证、demo、测试后，再找需求、开发团队、测试团队进行评审评估是否可以使用，再小面积的从边缘的模块开始尝试。新技术的学习成本太高，如果公司没有那个时间和人力的投入去研究，那么还是对已经比较成熟的技术进行评估和应用比较好。

小婧是一名行走在产品路上的资深业务分析师（BA），如果想与小婧同行就请关注我吧！