发布于 

读《有效需求分析》

最近在一个技术群里看到张逸大佬强力推荐一本关于需求分析的书《有效需求分析》,于是在 Kindle 上下单了,读完后有一种相见恨晚的感觉。

本书特点

从书中的一些案例可以看出,作者擅长 ToB 软件的需求分析,如果您是从事的 ToB 软件的相关工作,那阅读本书时会有更多的共鸣。

书中有大量的案例,阅读起来不仅不枯燥,反倒觉得挺有意思,特别是一些日常生活中例子,能引发我们更多的思考。

每一个章节都有能落地的产物输出,所有的产物整合在一起就是完整的需求文档,可以让你不仅知道一些理论,还知道怎么落地。

我们常见的问题

1、辛辛苦苦开发的系统,跟客户演示的时候达不到客户的预期;

2、上线后,客户反复提出“变更”,从客户视角来看是功能没有按要求完成,从开发的视角感觉客户在百般刁难;

3、边界难以控制,已经按照“要求”完成了,客户还不断提出新的东西。

读完这本书可以立即解决这些问题吗?答案肯定是不能,但能给我们带来启发和思考,能让我们在解决这些问题的路上往前迈进一步。

书中的内容不少,本文只是我结合自己的认知把觉得重要的点展开来说说。

什么是需求

什么是需求?书中给出了一个非常精炼的回答:现实和期望之间的差距。就是中间这个差距需要我们去思考、调研,这是一个迭代的过程,直到最后达到期望甚至超过期望,如果用了一些错误的方法,或者被客户牵着鼻子走,最后结果可能还不如现实。

方案不是需求

开篇例举的一个生活中的小例子充分说明了什么是需求,什么是方案:

晚上小孩吵着说要吃饼干,最后给了点面包,小孩吃完就乖乖睡着了,在这里吃饼干是方案,需求是小孩的肚子饿了,当没有饼干时,可以使用第二种方案,给他吃面包也可以解决这个需求问题。

如果客户的接口人稍微懂点技术,在做需求调研时就很容易提出方案级的需求,这时就需要警惕了,需要用一些问题来深挖背后的真实需求,比如:

  • 为什么会有这样一个项目,是因为同行业都有?还是因为内部管理需要?
  • 这个系统是哪些角色的人用?能解决他们什么问题?
  • 没有这个系统的时候现在是怎么来解决这些问题的?
  • 用户使用这功能的频率是多少?这功能如果做砸了,对谁影响最大?

如果能挖到真实的需求,就可以根据情况来制定最优方案了。如果我们“完美”地满足了客户提出的“方案级需求”,最终的结果未必能让客户满意,客户通常善于发现问题,提出问题,但给出的方案往往不能完美解决问题。

在公司的内部其实也存在着这种问题,比如项目团队的同事在遇到产品满足不了的功能时,需要给产品提需求,经常看到的需求描述是:

  • 在某某功能模块添加一种按钮类型;
  • 在某某地方需要多一种搜索条件的配置。

这些都是方案,而不是需求,项目的同事根据自己的理解和认知完成了从需求到方案的转换,而这个方案很多时候并不是最优。

所以每每收到这种“需求”时,会马上跟项目的同事反复确认客户到底想要什么,了解到真实背景后,才能结合产品的功能给出合适的解决方案。

干系人

任何企业准备上一套系统有各种各样的原因,可能是为了提高生产效率、提高协同办公效率,也可能是为了做一些政绩。所以针对不同的场景,我们首先需要找出这个系统的相关干系人。

识别干系人有几个重要的判断标准:

  • 是否是关键部门复杂人?
  • 是否对项目有一票否决权?
  • 系统上线是否对大量的使用者产生负面影响?比如:工作模式改变等
  • 识别出的人员是否与项目有直接关系?

如果能够准确的识别关键关系人,还需要对关系人进行分析:

  • 同一类如果有多个干系人,需要选出最有代表性的一个;
  • 不同干系人之间是否有利益冲突;
  • 干系人的专业背景、兴趣爱好(方便日后沟通);
  • 不同的干系人在各自角色上希望项目能解决什么问题?
  • 对项目的落地有什么担心?

做项目不光是要做好事,关键还要能搞定人,能让重点干系人感受到系统的价值,项目就容易成功。

我认为项目的前期最核心的就是上面两个步骤:挖出核心诉求和找出重点干系人。剩下的就是分解需求进行开发实现了。不同的团队对需求分解和开发实现肯定都有适合自己的方式和方法,具体可以去阅读本书,下面说说在项目需求调研过程中经常会忽略的非功能性需求。

非功能性需求

非功能性需求通常指,安全性、性能、扩展性、稳定性等等,这些非常重要,但也是最容易被我们忽视掉的。

非功能性需求针对不同的客户或系统会有不同的侧重点,比如:

  • 费控系统对计算的准确性要求高,接口需要做幂等处理等等;
  • 客户是集团性质的企业,而且系统是全员使用,并发量大,性能上有较高的要求;
  • 一些合资企业,系统需要进行多语言支持,可能还会进行跨地域部署;
  • 事业单位、政府机构对 UI 层面会有独到的见解;
  • 公检法司的项目中会对安全性要求比较高,包括可能有些数据列需要加密。

这些非功能性的需求在调研阶段应该和功能性需求一起同步进行,根据客户的特征进行分析和识别,最终作为开发交付的一个检查项进行检查。

上面列举的都是和系统本身相关的一些要求,除此之外,还有很多的外在因素也是在前期调研时就应该考虑的,比如:

  • 客户希望上线的时间节点?
  • 如果功能较多,能不能进行分期交付?
  • 客户有没有明确的技术上的要求,比如不能使用 Windows 部署,或者开发语言只能使用 Java?
  • 有没有历史系统需要做数据迁移?如果有需要达到什么样的目标,是整体切换还是需要双系统并存一段时间进行逐步替换?
  • 是否需要和第三方系统进行对接?如果需要,需要知道第三方系统的接口人信息以及接口规范。

现在各种各样的书籍琳琅满目,感兴趣的书买了,就有机会去阅读,这是我一直以来的一个观点,做需求每个项目负责人都有自己的方法,但多读书学习一些方法和技巧,没准哪天就能用上了。再说了,多读书,往上可以提升我们的格局和眼界,往下也能夯实和固化我们的能力。

希望本文对您有所帮助!