从开发角度聊聊如何在需求确立和需求评审阶段洞悉隐性需求？

不想捂着脸求人改需求？来看工程师怎么说！前段时间，在交互设计阶段如何发现思维盲区，减少开发与视觉的返工。今天让腾讯前端@姬小光 从开发角度聊聊如何在需求确立和需求评审阶段洞悉隐性需求，无论是开发人员还是产品，都能用上！

减少改稿同款教程：《减少返工！如何发现交互设计中的思维盲区？》

俗话说，计划赶不上变化快，无论需求文档做得如何细致，考虑得如何周全，总会有些难以预料的需求变更在每天困扰着我们。开发人员苦恼，产品运营人员更苦恼，毕竟谁也不愿意捂着脸一遍一遍地求人改需求。

但是，虽然世界充满未知的变化，但是有一些大的方向还是可以把握的，无论是产品运营还是开发人员，都可以在需求确立以及需求评审时多多考虑一下小鸡君说的这些方面，相信一定可以减少一些后期的变更成本。

下面这些内容主要是从开发人员的视角考虑的，多数基于小鸡君的个人经验，难免有失偏颇，不当之处还望指正。当然，如不嫌弃，感兴趣的产品和运营人员也可以稍作参考。

在项目初期，如果产品人员没有想清楚需求的细节，那么细节的变更可以说是无法避免的。那么作为开发人员唯一能做的就是，在设计程序结构和逻辑的时候，尽量预留出可扩展的能力。比如模块的增删，字段的增减，页面样式的微调等，除此之外也没什么好办法了。别灰心，这都不是事儿。

跨平台需求有时候来的非常隐蔽，往往最初规划的时候感觉可以先在一个平台尝试一下，比如先规划了 PC 端，但是 PC 端的某些功能又会忽然很急促的想移植到移动端。

而需求人员往往会想当然的认为，功能差不多，只要挪一下就可以了（平移过去/拼过去）。或者是，页面长的差不多，就改成移动端的大小就可以了（缩一下）。殊不知各个平台无论在架构部署，还是操作体验上都有着天壤之别，如果不提前规划好，那必然是个大坑。

无论是什么样的业务，随着业务量的增长，以及产品运营人员欲望的膨胀，都会催生出各种扩展需求。任何固定数量的，都会增加。任何单一需要的，都会变成多个。

比如页面上设计了三个商品推荐位，就要预留出变成六个、九个，甚至分页的能力。一个接口是给某个业务专用的，某天就可能变成通用的。一个简单的静态页面，某天就可能变成附带管理后台的复杂系统。对于扩展性需求，要反复确认，不必过度优化，但也要留出合理的扩展空间。

异常流需求往往容易被忽略，或者多有疏漏。常见的异常流有图片数据加载不出，图片不存在，接口挂掉，网速慢，未登录，登录态丢失，查询出错，查询无数据，内容溢出，用户输入溢出，用户输入非法，视觉遮挡不可用等等等等。

那么，对应这些异常流情况，就要有配套的前端提示给用户，引导用户进行其他操作。这些异常流往往会在设计稿和文档中遗漏掉，比如各种异常提示浮层，需要登录态的操作，结果登录态丢失等等，都需要有对应的引导。

所有静态的内容，都可能变成运营需求。静态广告位可能变成轮播广告位，轮播广告位可能变成需要运营后台填写数据，而不是直接写死在页面里。或者某一天可能变成从另外一个自动数据源拉取数据。

关于内容运营需求，评审初期可以确认好运营频次，如果是个把月才改一次的，几乎不耗人力的，那也没必要都搞工具。但是如果每天改一次，或者感觉运营内容的时间已经影响到正常的工作，或者远远大于写个工具的时间，那还是老老实实开发个运营工具吧。

上面既然说到运营工具了，那么作为运营工具一定是由运营人员自己来填写。既然是非技术人员填写，操作就难免要傻瓜一点，或者说非技术一点，尽量操作简洁，并且可以校验输入。如果因为运营人员多打了个空格，活着多写了个英文逗号系统就挂了，那应该算谁不尽责呢？

还有，能分别运营的字段要分别运营，因为有的时候虽然内容看上去是合在一起的，但是经常会有部分修改的需求，不如分开两个字段。比如广告位链接和埋点 tag，链接可能经常换，但固定位置的 tag 值就不会换，所以分开运营会好一些。

运营同学的工作是很辛苦的，设想一下每天一边开着 excel ，一边开着你的运营系统一个字段一个字段填写的时候，就知道画面有多美了。所以，运营填写的数据一定是有复用需求的。比如 h5 页面上运营的数据，有可能还需要给原生 app 使用，甚至给 pc 端也用一套数据。一个广告图片和链接，可能被插入到多个页面的顶部或底部，一起更新。多多沟通复用需求，可以随手拯救一大波运营妹子。

既然运营妹子这么不容易，那么工作量 KPI 如何衡量呢？这么辛苦再没人知道不是太惨了？所以，运营的数据一般是要有历史的。

如果就一个坑位，每次都改掉内容来更新，上一次的就没了，那么鬼知道我一天改了多少次？一周做了多少次更新？当然，这里更偏向工具类的需求了，不过我重点要说的是，有运营需求，就可能有运营的历史记录需求。

排序需求其实也是内容运营需求的一种，无论是运营填写的还是自动拉取的内容，永远都会有调整顺序的需求。不同的坑位对应不同的关注度，不同的视觉焦点，浏览路径。运营往往需要通过调整位置或者加些标记来突出某些内容。

比如商品列表，可能近期有几个商品比较好卖，就挪到前面，打上 hot 或者 new 的标记，从而促成更多的销量。对于排序和打标需求，往往从后台开始就要预留可扩展字段，到前端也要可以方便的调整位置和加 icon 标记才行。

对应于排序和打标，筛选也是经常用到的。比如我搜集了一坨数据，又只想挑一部分来展示，这时候往往需要一个可以方便操作的地方，类似帖子加精，评论置顶等等。商品类的数据筛选需求就更多啦，不过一般可以集成在搜索功能中，作为通用接口提供。但是，运营同学手动填写的数据再进行筛选，那功能就只能业务侧自己设计了，可以根据需要增加不同的筛选字段供运营同学填写。

数据统计需求是很容易失控的一种需求，产品运营最初往往觉得我要个 PV UV 啥的就够用了，过几天可能说能不能统计下这个按钮的点击量，再过几天可能恨不得把所有的操作都埋点，再加上访问路径、购买路径、转化率、蹦失率、页面停留时间、点击热图、鼠标轨迹。。。再给我出个月度季度报表，趋势图等等。

这里，对于数据统计需求一定要评审时梳理好，甚至我觉得可以独立于正常的需求，作为单独的数据统计需求整体梳理后提出。

我实在找不到更贴切的词汇了。翻旧帐的意思就是，凡事进到我系统里的数据，都希望有个方便的形式可以看到。比如用户创建的 UGC，一定要有个唯一的地址可以看到这个资源。用户录入的信息，要有个方便的地方可以导出，或者下载 excel。即使当前的需求不需要你展示历史记录或者以前的任何内容，也要预留出方便的查询接口备用。

这个有点诡异，报销关我鸟事？当然关。许多大公司的报销流程都很严格，毕竟是涉及到钱的问题。那么对于涉及到钱的活动来说，唯一的凭据可能就是你数据库里的数据了。所以有关钱的需求，最好开始就确认好报销需要哪些内容，比如用户的真实手机等等（确认是真人参与活动，没有造假），以此来作为最终报销的凭据，否则就只能运营同学自己出血了。

当业务量稳步上升时就会伴随着扩容的需求，尤其当访问量骤增的时候，快速扩容就迫在眉睫了。扩容包含很多方面，一些性能方面的问题会在高并发史迅速凸显，比如查询低效，PHP慢速，无静态化 web，并发压力大等等。

此时关于性能优化的一切知识都可以派上用场了，静态化、缓存、查询优化、锁表等等。而机器扩容也没那么简单，除了机器内容的复制还有相应服务的批量启动，定时任务的执行，日志的归集等等。所以，如果评估时预计业务会有爆发性增长（如微信活动），在资金允许的情况下不妨多准备些机器，总比一发布就挂了强。

这一点放到了最后，同样也是最重要的。安全问题包含的范围非常广泛，虽然有专业的同事负责安全以及运维相关的工作，但是在需求初期如果能稍微做些防范就会避免很多问题。一般的公司都会有个基础的安全规范，比如如何防止 XSS, CSRF 攻击，如何防止 SQL 注入，如何屏蔽脚本攻击等。

还有一些外部接口需要鉴权的，有时可能做了基本的鉴权，确没有更高级的防护。比如一个人虽然登录了，可以看到自己的某些资料，但是如果这个登录的用户还可以通过相同的接口查看其他人的某些信息，那就是安全问题了。有可能这个信息是存储在相对独立的表中，并没有严格挂在这个用户id下，那么查询的时候就一定要再检查一下数据和用户的对应关系。

对于安全需求，普通前后台开发人员能做的其实并不多，能按部就班做好这些基础防护就不容易了。加上公司公共的安全扫描平台，基本上可以杜绝绝大部分安全问题了。之所以写到这里单独列一条，还是希望大家要对安全足够重视。

综上所述，绝大部分的隐形需求都是有迹可寻的。然并卵，即便沟通再明确，邮件再确认，改来改去啪啪啪打脸，该做的需求还是要做，所以，节哀吧。

以上就是从开发角度聊聊如何在需求确立和需求评审阶段洞悉隐性需求介绍，希望这篇教程能对大家有所帮助！