需求实例化学习的第一次心得

这两天在尝试学习并实践需求实例化,主要是应用需求实例化五步法来分析一个需求。五步法本身来说是一种套路,包括“定系统”、“找用户”、“找意图”、“定场景”、“列功能”这具体的五步。之所以想进行这方面的学习和尝试,主要是最近两个月团队在开发新系统的过程中遇到不少问题。其中之一就是在完成了一些功能后,经常会发现漏掉了一些东西,比如一些异常场景考虑的不全,容错性不够,功能实现的逻辑有错误,性能效率方面的系统性功能考虑不足,一些技术障碍到了开发中、甚至是编码后才发现。总得来说就是搞了半天编码后,完成了的东西还问题多多。
这个结果很明显是研发环节中有些步骤做得不够,这才导致问题发现的比较晚。之前听说了多次需求分析五步法,因此想学习了解下这个方法是否可以有助解决这个问题。而我对它的期望则是希望通过运用这个套路,可以在开发阶段之前就能识别出前面的所有这些问题,以便开发人员可以在开发过程中尽量的不犯错。并且通过这个过程能知道最终如何检验这个需求是正确实现了,并且也满足非功能性的要求。
学习的过程中遇到了不少的问题,还好有经验丰富的龚同学给以了不少指点。不过目前为止还遗留了不少的问题。其中一个最大的疑问是感觉这五步法也并不能100%的保证分析完成后就可以识别出所有的问题点。具体来说,在我想象中,五步法的每一步都是承前启后的,后一步可以依赖前一步的结果进行进一步深入的分析,并最终得到所有的问题点。然而,到了第五步“列功能”的时候,感觉并不能仅仅从第四步“列场景”的输出中就得到所有的结果,有不少想到的问题点都是来自于突然的灵感,又或者是以往的经验。那么如果是这样的话,这些灵光一闪的发现在我不使用五步法的时候也有出现过,那这五步法到底和我以前的土办法有什么区别呢?
自己稍微想了想,个人觉得五步法带来的好处在于几点。第一,这种套路是一种固定模式,可以帮助分析过程的开展是稳定的,是按照一个轨迹逐层深入的,并且可以不停迭代的。相比我之前的随意的分析手段,它具备更稳定的结果输出,也就提高了每次分析后识别出问题的概率。如果是那种随意的分析手段,每一次的变数很大,也许哪天我的脑袋不灵光,那就有较大的概率遗漏问题点,这种方式的波动就很剧烈。第二,分析的过程中通过记录各种阶段性输出结果,而不是凭脑袋空想,可以避免遗忘已得到的成果。第三,在反复回顾这些阶段性输出时,可以帮助我们获得新的灵感和洞察,也就是提高我们灵光一闪出现的概率。
总的来说,我觉得五步法的套路并不能百分之百的保证我们可以识别出所有问题点,我想世界上也不存在这样的方法。但是它可以获得相对稳定的收益,就好比投资和投机获得的收益率的区别一样,前者波动小,后者波动极大。而且今天晚上的COP讨论会上,龚同学分享的心得体会也印证了我的这些想法。我想五步法或者是其他的一些分析方法,更多的是一种启发式的过程,它不能保证完美的结果,但可以提供获得新洞察的机会。

推荐阅读更多精彩内容