0°

共读DAY001《软件需求最佳实践》01


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

第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),如果想与我同行,就请关注我吧!

共读DAY001《软件需求最佳实践》01






「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论