0°

需求过程中经常被忽略的环节

现在很多软件公司经常会遇到这样的问题。


以用户为代表的业务方抱怨不知道如何描述所谓的需求,因为产品或需求人员总是问一些“奇怪的问题”;我们提出的需求要么实现速度慢,要么根本就没解决我们的问题。


需求分析人员总是抱怨和客户沟通不能,他们不能理解我们在说什么,我们不能理解他们想要表达什么;他们总是有各种理由在正在开发的版本中增加新的功能。


其实大家都在很好的履行本职工作。

业务方关注的是把自己遇到的问题描述清楚,期待技术团队能够帮自己解决问题。

需求分析/产品团队关注实现细节,通过各种方法将客户需求有效的表达清楚,追求这一实现过程的最优解。


但是,不知道大家有没有发现,这中间少了一层。

少的这一层就是“需求架构”。

需求过程中经常被忽略的环节

之前我写过一个系列文叫做“又见树木,又见森林”。

我们在做解决方案也好,产品也好,在做之前首先要弄清楚目标和方向。

架构就是站在顶层,自顶向下,由整体到局部进行事项解决的一种方法。

——《软件需求十步走》



需求架构师就是将业务诉求和价值远景进行组织和分析后,对需求进行规划,然后再给到需求开发人员,也就是我们的需求分析师和产品经理。


其实,在很多公司有这样的角色,他们会负责写MRD,进行高层级的价值分析。


需求规划具体来说包括6项任务。

《软件需求十步走》中描述的比较“教科书”,我顺道对每点谈谈我自己的经验。


业务研究


主要是对业务资料进行采集、收集,然后进行分类整理。


这是我们熟悉的一项任务,但是在需求规划过程中,这个业务研究的范围会更大一些。


因为我们要做规划,并不是做需求开发,所以除了一些常见的业务资料,比如业务流程、人员分工等,还需要对客户的企业规划、市场动向、我们所在企业的发展目标进行资料的收集和分析。


这不是一个短期就能完成的任务,最好我们能有计划有目的的在日常的工作中就开展起来,不断积累。

这样就不至于临危受命,两眼一抹黑。


要知道,信息量不全的情况下,做任何的决策,风险都是巨大的。

资料的完备程度越高,业务研究的越深入,决策的风险就会大大减轻。


应用建模


用结构化的形式和功能数据归约的方法对业务研究成果进行研究。


我们在业务研究之后,还需要进行应用建模。

比如使用流程图还展示业务过程,使用组织架构图来展示角色关系,使用时间轴来展示发展历程等等。


鉴于大部分的信息和资料都是描述性的,我们需要使用抽象的方法,将这些研究成果进行结构化、可视化的整理和建模。


系统规划


根据业务研究中的组织结构、业务事项、业务数据规模和用户对业务目标的期望,并结合应用建模的成果,对支撑这种规模和应用所需的所有信息进行规划。


一家公司想要做知识管理系统,我们通过业务研究和应用建模,再结合客户的软硬件条件发现需要分阶段实现。

那么每个阶段要实现什么目标,建设什么内容,都属于系统规划的内容。


更常见的应用是制定“产品路线图”。


分析计算


将上述三步的结果录入到仿真分析平台中,进行业务逻辑正确性分析、业务所需系统支撑能力、业务发展能力的计算,并给出数据结果,对上述三步的结果进行修正。


所谓的分析计算使用什么工具,如何具体执行,在我看来,取决于你的项目和产品类型。

大部分的互联网产品,或者重前端的产品,可以使用原型进行分析,通过制定一些指标来获取反馈。


而有部分的产品或项目在进行底层框架选择的时候,可以使用一些POC进行分析验证。


如果发现之前的一些信息不一致或者无法很好的达成目标,那么就需要对之前的产出进行修正并再次进行验证。


报告编制


对上述产出进行文字化的正式的描述和说明。

不要无视这个步骤,因为你自己都很清楚,过上两三个月,很多出自你口的信息,你也记不清了。


规划评审


规划评审的主要目的是为了让各个关键关系人达成一致,获得认可。

在规划阶段发现问题并去解决,影响会小很多。



规划影响的是方向

方向如果不正确,再多的努力不仅是事倍功半,更可能是自掘坟墓。


在规划结束后就进入了我们熟知的需求开发环节,包括:需求获取、需求分析……


我们做了太多“埋头拉车”的工作,要知道“抬头看路”更加重要。




小婧是一名行走在实践路上的资深业务分析师(BA),如果想与我同行,就请关注我吧!

需求过程中经常被忽略的环节



「点点赞赏,手留余香」

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