项目开发 | 转载 | 需求评审与技术评审
转载自 知乎：项目经验 需求评审与技术评审 ，文字未改，格式有改动。
文章目录
- 0. 序
- 1. 需求评审
- 2. 技术评审
0. 序
做开发应该对需求评审，技术评审并不陌生。
但常有小伙伴抱怨，需求评审会参加了不少，会上定下来的东西却不多，需求朝令夕改也是常态。久而久之，需求评审就变成了立项动员会，走个过场，没起到实际作用，开发小伙伴当然不想参加啦。
那有人说了，技术评审应该不会这样了吧，毕竟是开发内部自己讨论。但从我的实践经验来看，也不一定，大家规划的好好的摩天大楼，盖着盖着就变成了草房的事情也发生过。
现实就是这样魔幻。本文，我将站在开发的角度，结合真实经验，给大家说说，怎样开好需求评审会，技术评审会。
1. 需求评审
需求评审，是产品，开发和测试的双向沟通（诶诶？怎么会把测试拉进来？没错，我司需求评审就是要求测试参与，原因后面会讲到）。
产品就好像老师在台上讲，但开发，测试作为学生不能（断句）不懂装懂，有问题一定要大胆提出来！我们强调双向沟通！以免发生需求评审会上，开发拍着胸脯说，没问题没问题，开发到一半才发现实现不了，灰溜溜地跑去给产品说，然后双方大打出手的事情。
那么需求评审需要做哪些事情呢？
- 原型图
- 理解需求
- 定结论
- 通知相关人员
原型图
作为开发，测试，我们对需求没什么话语权。但是！在需求评审会上，我们要求产品必须给出原型图！就算没蓝湖画的，在笔记本上画，那也得有照片！
俗语说：说者无意，听者有心。人说出来的，和自己心里想的，不一定匹配！同一句话，不同人也会理解出不同意思！
而落在画面上的原型图可以消除这种差异。点这里出这个弹框，如果这样还能理解出花样来，那你的脑洞优秀的。
需求评审会决定之后的开发方向，如果方向都错了，然后就没有然后了。
建议
- 使用线上原型图工具，这样大家通过一个地址都能看到。
- 如果中途修改了需求，尽快更新到原型图上，并通知大家。
定结论
如果一个会议开完都没有结论，那就等于没开。所以我们至少得确定以下几点：
- 开发，测试理解了需求解决的业务问题。
- 需求优先级
- 参与人员，时间节点
- 通知相关部门
开发，测试理解了需求解决的业务问题
首先，需要开发纠正一个观念，那就是——产品要求的我做就是了，其他的我一概不管。我说了，产品需求会是一个双向沟通的过程。在过需求时，开发在理解需求后，最好根据自己的经验，对原型做出评价。
什么意思呢，举个栗子，产品新增了一个用户退款的需求，用户不用联系客服，自助退款。这时，我会把自己代入用户的角色，来看看用原型图的方式退款，一，是否能完成操作流程，二，是否方便，三，同类产品退款功能是怎么做的。同时，我也会把自己代入管理员的角色，后台，退款要不要自动操作？如果需要人工介入，管理员怎么操作？退款人数过多，是否需要批量操作？如何审计？可能会出现哪些风险？
比如，别人退款都是按一个套路做的，产品搞个特立独行的设计，我脑袋里模拟了一下，哪有这样搞的啊，那我就得提出来呀——你这是什么鱼唇的需求？！我第一个不同意这门亲事！
再比如，我发现操作到某一步骤，我想反悔，而原型图上没有相关功能，那我就得提问。
重要的不是喷，你得提出你的观点！ 你得提出产品没有看到，没有想到的地方。帮助产品去补完原型。 产品改不改需求是ta的事，但你必须参与其中。互联网公司大家都是阅历相近的人，大多都是讲道理的，产品觉得你说的有道理，ta自然会去改。
这样，就避免了一部分做到中途改需求的事发生（当然，可不能百分百不改需求，但我这样做之后，自感需求变动较之前少了很多）。当然，产品不改，那我们就拿小本本记着，毕竟开发没有决定权。
如果需求有不理解的地方，或者有歧义的地方，无论开发，测试都应该当场提问。坚持需求不明确就不动工！
测试为什么要理解需求？你测试都不知道这个需求在搞什么事情，你测啥？
建议
需求不合理处，提出同行一般解决方案。
若你提出的方案被产品否决，记录下来，等待正式服用户验证（也许这种做法也不是错的，只是不常见，万一用户接受呢？万一用户喜欢呢？现实是很魔幻的）。
需求不明确不动工。
需求优先级
如果只有一个需求，break。
如果有多个需求，必须确定优先级。这个没什么好说的，永远先开发最重要的需求，就算项目延期，至少核心功能还能上。
参与人员，时间节点
这个也没什么好说的。这里着重说一下时间问题。
有时，有些需求不急，产品不会给死线，但从我的经验来看，没有时间节点=没有目标，没有目标=根本没人会主动去做。
还有时，产品不定时间节点，我们吭哧吭哧一会儿搞完了，产品又说这个需求不搞了（呵呵，你这个善变的人）。
所以，不管需求急不急，也定一个时间节点吧，产品不定时间的需求也不要慌着去搞。
如何评估开发时间？其实这是一个无解的问题，你一定对下面的场景非常熟悉：
产品：什么时候能做完？
开发：大概XXX天吧。。。（心虚）
产品：啊？这么久？不行啊！这时候做出来黄花菜都凉啦。
开发：那你什么时候要？
产品：当然是越快越好啦，再不济，也得XXX号之前吧。
开发：好。。。好吧（哭唧唧）
一般而言，开发对死线没有话语权，不过问题你总得回答吧，这里给出我的方式：
首先确认产品的死线定的是上线时间，还是提测时间，还是开发完成时间。这点非常重要！你不问他不说，最后大家都哦豁（GG的意思）！
开发天数=预估天数*风险系数。
预估天数根据经验定，风险系数根据团队研发效率定（这个系数一般是1.x，当然也可以是0.x）。
这里测试也要给到测试时间。测试知道开发死线，也可以变相监督开发按时完成（因为那天ta会找你要测试地址呀）。
建议
- 每个需求定下时间节点。
- 明确时间节点到底是上线时间，还是提测时间，还是开发完成时间。
- 任何需求变化通知开发Leader，而不是具体开发人员，Leader没通知到开发是Leader的失职。
通知相关部门
有些需求需要其他部门配合，在需求评审会结束后立刻通知相关部门。
某次，有个需求需要其他部门提供接口，这事在很久之前碰过一次。我们这边开发的时候没有通知对方，结果我们都开发完了，正准备找他们联调的时候，才发现他们根本没开始做。。。因为我不知道呀，你没告诉我呀！
建议
- 确定合作方接口人，大小事宜只找接口人。
- 对方最好能提供他们的死线。
- 需求评审会的结论，必须落到协同办公工具上，然后发送给每一位与会者。
- 对于极善变的产品，保留第一版代码，设计，因为大概率ta都会改回去（这不是段子，这不是段子，这不是段子）。
2. 技术评审
技术评审会比需求评审稍微好一些，毕竟都是圈内人。但会议的目的是定结论：
选型——语言？必须
架构——单体？负载集群？分布式？必须
框架——组件？版本？必须
中间件——可选
风险及预防措施——并发？大流量？异常？必须！别告诉我没风险！
前后端对接——可选
后端需要考虑的东西很多，这里不细讲，后面会单独讨论。
后端
技术评审，我个人倾向敲得越细越好。
我也是从小项目干过来的。那时候项目小，需求一下来，根本不用技术评审，一梭子代码就敲上了。也会时常遇到搞到一半大修大改，甚至推翻重来的情况。但毕竟是小项目，就算艹了重来，时间也够。可后来随着项目规模越来越大，吃过几次大亏之后发现，对于中大型项目，如果搞到中途才发现路走不通，基本就没退路了！
那要细到什么程度？
对于后端，你得把所有接口，入参，出参，过程查询哪些表，更新哪些表，经过哪些中间件，在业务流程中，各个接口如何配合，全部在脑戴里过一遍！
什么？这太变态了？不，从我的经验来看，即使做到这种程度，在开发过程中还是有的改！你一定听过8分时间设计，2分时间编码的理论。 我最早也对此嗤之以鼻，但现在却奉为圣经。从效果上看，这样做，虽然不能保证完全不改，但至少可以保证不会推翻重来！
前端
对于和前端对接的项目，最好在评审时拉上前端，先简要描述一下接口的出入参，让前端评估是否需要修改参数，字段。别自己先做出来了，粗暴的丢给前端，前端一接，这也是问题，那也是问题。
至于出现矛盾，前后端谁改的问题，我认为要秉承公平原则：
- 分页的事儿总该你后端做吧，那就别让前端假分页。
- 数据格式转换的事儿，最好也让后端来做。
- 数据展示，要拼接一些字段，这个事儿前端就别让后端冗余字段了吧，自己拼吧。
- 前端需要一些额外参数辅助，后端就帮忙加一下。
- 后端对参数格式有要求，前端传的时候就帮忙转一下。
- 等等
谁也别让谁养成了坏毛病，该谁干就谁干，久而久之，默契了，就不会出这么多幺蛾子了。一般来说，即使前后端一起评审，开发过程也难免需要前或后端改动，但我们尽量在前期规避掉大部分。
建议
- 事先约定错误码，包括HTTP码，和业务逻辑码。
- 后端给出在线接口文档，不要自己写，用工具生成。
- 如果团队氛围活跃，要避免争论不休，当有多个方案，或没有优质方案时，使用最保守的那一个（我是保守派）。
- 如果团队氛围沉闷，要一锤定音，Leader要定下方案，即使错的，也要执行，团队必须要有执行方向。
- 技术评审会的结论，必须落到协同办公工具上，然后发送给每一位与会者。
最后
虽然开发专注于技术，但你会发现文中很多重点却不在技术，而是在做人做事方面。你会换位思考，站在他人的角度看问题，你尊重他人，才会去想这个事应该我来做，你会揣测他人的意图，ta表达的到底是不是这个意思，等等。
我一向认为，开发，技术是硬实力，它关乎做不做得出来的问题，沟通协作是软实力，它关乎做不做得好的问题。
我自己虽然技术不怎么样，但做事的时候，会去主动思考这些问题，会尽量让大家配合得更丝滑一些，大家和和气气，顺顺利利地朝同一目标整活，这难道不香吗。
本文到此结束，谢谢大家。欢迎提出意见，也欢迎参与讨论。
项目开发 | 转载 | 需求评审与技术评审相关推荐
- 项目经验 需求评审与技术评审
序 做开发应该对需求评审,技术评审并不陌生. 但常有小伙伴抱怨,需求评审会参加了不少,会上定下来的东西却不多,需求朝令夕改也是常态.久而久之,需求评审就变成了立项动员会,走个过场,没起到实际作用,开发 ...
- 产品开发中，TR是技术评审节点。
在工作中,我们经常可以听到以下的声音: "我们不进行评审,是因为我们项目比较特殊,没有时间--". "我们的项目已经进行了测试,不需要再进行评审了". &quo ...
- 产品经理入门03：需求评审和技术评审
一.需求评审 需求可实现性评估的重要确认阶段 (一)参会者 产品经理 开发团队(前端/后端开发工程师) 交互设计师及视觉设计师 测试工程师 (二)筹备 原型图demo PRD (三)内容 逻辑上是否合 ...
- 大数据项目开发案例_大数据分析技术——项目案例2（房价数据分析上）
1 二手房房价分析简述 在现在这个社会,房子成为绝大多数人心中难以抹去的痛:不仅在于它的价格高不可攀,也在于我们多少有些囊中羞涩.若不是得益于亲朋好友相助.父母相帮,估计依靠着我们这点微薄的薪水去购房 ...
- 大数据项目开发案例_大数据分析技术——项目案例1（猫眼电影数据分析上）...
壹 猫眼Top100电影数据分析概述 从这一节开始,我们就综合利用已学到的一些分析技术来尝试做一些比较复杂的实际数据分析项目.在这些实际的项目案例中,我们将会看到一个完整的数据分析流程:数据清理--数 ...
- 【jeecg-boot项目开发crm】：平台技术点——day05【Java定时任务解决方案：九、触发器，调度器概念整理】：图灵课堂
九.触发器,调度器概念整理 1 触发器的优先级 1. 1判断错过触发的条件和产生的原因 1.2错过触发之后要怎么处理呢[下面给出策略] 默认使用的策略: SimpleTrigger[常用]: new* ...
- SpringMVC+Mybatis框架集成开发基础——项目开发流程——01
项目开发一般流程: 1.描述项目的主要功能及各个模块的功能 2.系统采用的技术方案 3.创建E-R模型图(实体关系模型图,数据库) 4.搭建数据库环境.创建数据库表及表间约束 5.搭建项目 ...
- 基于 uni-app 和 uni-cloud 小程序项目开发实战
基于 uni-app 和 uni-cloud 小程序项目开发实战 前言 一.技术栈 二.环境搭建 三.项目功能介绍 1.地图地点搜索及路线规划 2.uniCloud服务空间 3.AI识图 4.上拉框组 ...
- 技术总监之路——App项目开发流程
App项目开发流程 一. 需求阶段 1. 初期由leader或者项目责任人和PM沟通下阶段开发计划,确认需求的可行性和优先级等初步达成共识 2. 接下来PM提供详细UE文档(需求颗粒感尽可能小)发起三 ...
最新文章
- zabbix添加端口监控
- ALEIDoc EDI(1)--OverView
- hpg8服务器系列指示灯意思,HP Proliant GEN8服务器指示灯说明
- 2 0 2 0 年 第 十 一 届 蓝 桥 杯 - 省赛 - Python大学组 - A. 门牌制作
- matlab fgetl用法,Matlab fgetl strsplit 函数
- C#水晶报表，窗体不显示，闪退
- 2016年百度面试题
- 影子系统 是怎么一回事!-间歇博客
- 计算机函数sumif怎么用,怎么用sumif函数求和
- 卸载精灵(bue directx) r4.0 完美版 绿色
- 用Photoshop制作2寸照片方法
- 红帽8培训笔记2day
- [转载] 晓说——第19期：千年科举那些事——官场
- vue循环请求同一个接口，等接口返回数据之后在进行下次循环
- 我，32岁程序员，三十而立，扛起了整个家
- 读书笔记-精准努力-勇敢地直面问题
- Linux 系统操作之U盘挂载(mount)及卸载(umount)
- SSL 1580——泽泽在埃及
- 【Matlab多目标优化求解】粒子群算法求解配电网抢修优化问题【含源码 777期】
- Blender及其游戏引擎