需求评审

作者: 墨绳 | 来源:发表于2019-01-08 23:13 被阅读2次

全文指精评,业务形式确定,技术解决方案基本通过,说明评审细节


1 评审前

同业务方,确定好业务方案,评审前业务方案是要定稿的,防止后期变来变去

同技术方,将业务中的核心流程和重难点同技术负责人沟通,确保解决方案技术可实现,如果方案不可实现评审也就没有意义了

同整体技术团队,组建一个项目群,至少提前一天将准备好的原型、文档、设计稿等文件发到群里,供大家对内容有一个基本的认识

复杂性的内容准备好整体框架的说明和最小化的案例,以便在技术不懂业务的情况时让技术快速理解业务


2 评审中

2.1 评审要达到的目标

让技术了解业务,能根据业务做出相应的判断

让技术明确解决方案,按照既定思路开发产品

确定理解处与不理解处的边界,不理解处明确哪里不理解,清晰记录问题

2.2 讲解方式

先讲为什么做、怎么做、带来的收益是什么,让技术了解做这件事情的价值,激发动力

再讲产品解决方案,按剥洋葱方案讲(金字塔思维)

1.讲整体的结构,说明产品的基本框架,数据流转的整体情况,结合最小案例。先讲正向整体流程,在大家对整体明确后讲逆向流程

2.讲结构拆分的细节、讲模块之间的关联关系、数据的具体流转形式,结合最小案例。按模块,每个模块先讲正向流程,再讲逆向流程

3.讲具体的解决方案,讲产品细节交互讲字段样式。拆分到最小单元,正向、逆向、特殊情况组合起来讲

4.每一层讲完后进行一次简单复述,帮大家建立每层的框架

5.整体讲完后说下整体分了几层去讲的,每层之间怎么关联,帮大家在思维里建立一个整体的框架

2.3 评审注意事项

要有问题终结者的精神。遇到问题要敢于体出来能解决的绝不拖到会后,千万不要在没明确问题边界的时候说先放一放一会再说,那是给自己挖坑,后面要填掉这个坑要付出的时间精力会成倍增加,这是一个提高工作效率的关键点

每个环节每个模块讲完之后都要问大家懂没懂,没懂是哪里没懂,明确问题边界,清晰记录下问题,可以存疑,但要明确疑问点是什么。

可以站在技术放的角度思考问题,但遇到困难事不要轻易妥协,评审有时候是一个博弈问题,其实大部分问题产品的立场坚定了,压力到位了,技术都能解决


3 评审后

解决要及时:解决问题必须及时,能当天解决就当天解决

信息要同步:解决后通知相关人员必须到位,不要遗漏,技术、测试、美工相关的人都要通知到位


总结

评审前:和业务确定业务方案、和技术负责人确定技术方案可实现、自己准备好原型图文档设计稿并提前发布

评审中:层层剥洋葱说明整体框架,每个环节要结合案例明确易懂,要有一定要说明白的决心

评审后:问题马上解决,解决后马上同步相关人员,不可遗漏

相关文章

  • 项目开发流程及注意事项

    一、项目流程 需求宣讲、需求评审 交互评审 UI评审 开发方案评审 接口评审 测试用例评审 开发 测试 上线 验收...

  • 需求评审

    我们多少都是站在自己的立场上进行设计,可能由于知识面、能力、牛角尖、盲区等原因,这些设计存在这样或那样的问题,甚至...

  • 需求评审

    一,目的 1,让所以人都明确需求的背景和目的 2,提前确认和统一产品需求实现的过程和方法 3,让参与者明确知道工作...

  • 需求评审

    晚上9点钟被产品经理拉去参加需求评审,产品经理为了解决长表单内定位到报错字段的体验问题,提出了一个表单内分页需求。...

  • 需求评审

    已经好几天没有更新文章了,本打算在简书上写写工作中的事儿,以满足日更的目的。然而,工作中好像也没有那么多有趣...

  • 需求评审

    1、需求评审的重要性 在软件项目中,需求分析是最开始的工作,同时也是最重要的工作。 2、需求评审的关键 2.1 充...

  • 需求评审

    全文指精评,业务形式确定,技术解决方案基本通过,说明评审细节 1 评审前 同业务方,确定好业务方案,评审前业务方案...

  • 需求评审

    需求评审是为了发现问题,确定产品的方向。 内部评审: 需要产出低保真原型行,在同一产品线的不同产品经理之间讨论,大...

  • 需求评审

    需求评审会是产品经理发起的设计研发测试运营等相关方参与的一个活动,使用产品原型和需求文档讲解产品需求,让各方达成共...

  • 需求评审

    今天开需求评审会议,大家对原型其实没有太多的问题,更多还是针对开发实施进度存疑。 开发负责的一个同事,针对技术侧有...

网友评论

    本文标题:需求评审

    本文链接:https://www.haomeiwen.com/subject/dguirqtx.html