需求评审的目标
- 了解需求的动机、目标、方案、排期等,为开发设计、测试设计做准备;
- 降低需求设计本身的不完整、不一致、不准确等出现的可能性
- 通过评审尽可能降低团队成员理解的不一致性
- 提早考虑排期风险、实现风险
需求评审可能存在的问题
- 产品的频繁变更,前后实现不一致。这里是说,需求本身的不合理导致产品方面的频繁修改上线。 举一个实际的项目例子:当时新来了一个PM,决定读首页的筛选进行改版,结果上线之后发现不符合用户需求,下次需求就立马改回来了。
- 产品实现方案不合理。这里主要是说,需求评审中直接详细对接了技术实现方案,与第三方对接方案等,结果技术人员评审后,发现与现有的实现冲突、违背,或者如此实现技术方面的改动太大了。
- 需求的预期目标不明确。这类问题是需求评审时常见的一类问题,特别是对效益不太容易评估的产品。 例如,曾经做过一个给公司内部运营人员使用的一款web产品,经过了两年多的迭代后,每次在需求评审时,仍然没有清晰的产品迭代目标。
- 需求过大,而评审文档本身脉络不是十分清晰。举一个这种需求产生的问题: 当时要做一个大型的消息平台,但产品人员与技术人员分隔两地,于是产品人员采用视频/语言的方式来进行需求评审,结果评审后,大家一脸茫然,不知所以。后来产品人员不得已又进行了2次的面对面需求评审,才最终把评审做完
需求的开发视角
- 需求是否技术上可实现、实现成本是多大、目前人力资源是否可支持?
- 需求本身可以带来多大的业务价值,与技术投入成本是否匹配?(避免投入过大,产出过小)
- 需求实现方案是否可验证,有无更轻便的实现方案?
- 实现方案上对用户、技术架构等会带来哪些不利影响?
- 需求是否粒度过小,使得产品琐碎功能累积,过多占用人力?
- 需求是否粒度过大,从而导致开发风险、进度难以预估?
需求的测试视角
测试视角除了上述的开发视角需要考虑的方面外,通常还会考虑以下方面:
- 整个产品方案在可测性方案有哪些阻碍,目前是否可100%支撑?
- 是否需要和第三方人员大交道,中间不可知时间成本有多大,留多少时间buffer?
- 需求粒度大小,复杂程度,使用的技术方案,测试需要提前做哪些准备?
- 需求实现的目标用户、用户习惯是怎么样?
- 需求对应的访问量是多大,是否需要压测评估?