神刀安全网

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

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

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 共读《软件需求最佳实践》01

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址