关于需求分析

为什么要做需求分析

什么是过度设计? 不会发生的事情你考虑了并且为它做足了准备, 就是过度设计. 所以判断是不是过度设计很困难, 需要对未来演化有很强的判断力

需求分析必然会涉及到以下内容

我们不一定要在需求分析的文档中完整的回答这些问题, 需求文档的分析目的不是回答这些问题.

但是我们梳理需求的过程中, 我们无法回避对这些问题的思考

大家也许会认为, 这是CEO和产品经理这样的角色需要回答的, 而不是架构师需要回答的

但是要成为顶级架构师,只是被动的接收产品需求是不够的

所以架构师自己亲身近距离的接触用户, 与用户沟通, 体会用的诉求是有必要的

用户的需求变化是缓慢的, 真正改变的是需求的满足方式. 而需求满足方式的变化, 深层次来说,背后往往由技术迭代所驱动, 所以产品经理是需要一定的技术高度的, 他不一定要了解技术的原理, 但一定要深刻理解新技术的边界, 顶级的产品经理甚至要比技术开发人员更清楚某项技术能做什么, 不能做什么

如何做需求分析

心态第一, 心理得装着用户 除了需要在心里对需求反复推敲的严谨态度外, 对用户反馈的尊重之心也很重要

对问题刨根问底,找到根源需求 有很多用户反馈需求的时候, 往往已经带着他自己给出的解决方案. 这种需求反馈已经属于二次加工的需求, 不是原始需求, 这个时候我们要多问, 多推敲. 把它还原到不带任何技术实现假设的根源需求

需求分析 - 图1

根源需求可能有非常非常多的技术方案可以满足它, 他们上面示意图中的小圆点是一个个用户反馈的需求, 在用户提这些需求的时候, 往往可能带着他熟悉的技术方案的烙印

对于我们明显不关系的需求, 上图的小红点, 相对容易排除在外. 但是对于小绿点决策上就比较难了, 不做? 可能会丢失用户, 做如果我们收放宽一点, 产品需求就会被放大, 最后做出一个四不像产品

理清需求后, 要对需求进行归纳整理 将需求分别归类到不同子类别中, 另一方面, 形成需求的变化点和稳定点的基本判断

在需求分析时, 要区分需求的变化点和稳定点. 稳定点往往是系统的核心能力, 变化点则需要对应的考虑扩展性上的问题

需要明确的是, 当我们说需求的变化点和稳定点时, 这是站在我们要设计的产品角度来说的

比如我们要设计一台计算机, 那么多样化的外部设备是一个变化点, 但是如果今天是在设计一台显示器, 问题域就完全变了. 需求的变化点和稳定点就完全发生了变化.

本质上来说, 对变化点的梳理, 是一次产品边界的确立过程, 所谓的开放性设计, 就是说我把这个功能交给了合作伙伴, 但是我得考虑怎么和和合作伙伴配合的问题

开放性设计并不是一个纯粹的用户需求问题, 它通常涉及技术方案的探讨, 因此, 产品边界的确立不是一个纯需求, 也不是一个纯技术, 而是两者合二为一的过程

对变化的梳理至关重要, 产品功能必须是收敛的, 必须是可完成的.

如果某个子类别的需求呈现出发散而无法收敛的趋势, 那么团队一定要做下来一起去反复推敲, 不断拷问, 不断明确响应需求的正确姿势到底为何

需求分析的目标和最终结果, 都是要最终形成清晰的产品定义, 产品定义并不是简单的产品需求的归类

需求分析 - 图2

产品是桥, 它一端连接了用户需求, 一端连接了先进的技术, 所以产品定义不可能做到和技术方案完全没有关系

明确产品中有哪些元素(资源), 以及这些资源的各类操作方式 如果我们从技术视角来理解, 这就是定义对象和方法, 当然仅仅是这么理解. 实际上我们一个技术上的对象方法, 从产品需求角度会有多条路径的操作方式来达到相同的目的

产品如何满足用户需求进行确认 用户的使用场景未必全部是我们的产品能直接满足的, 面向特定的行业, 有可能需要相应的行业解决方案, 把我们的产品整合进去

需求分析 - 图3

我们要避免把行业方案视为产品的一部分, 需要我们用更加开放的心态来看待这个事情, 优先寻找合作伙伴来一起完成这类行业的需求覆盖

产品定义还需要考虑市场策略, 我们的产品如何进入市场, 和既有市场格局中的其他主流方案解决的关系是怎样的?

需求分析 - 图4

我们希望获取的用户，可能大部分都已经有一个既有的产品和技术方案，在满足他的需求。在考虑如何让客户从既有方案迁移到我们的产品后，我们确定产品的边界时又会复杂很多。

在一些极其关键的市场，我们有可能会把迁移需求视作产品需求的一部分。但更多的情况下，我们产品上只为这些市场上的主流方案提供迁移路径，而不是完整的迁移方案。