俗话说，操持赶不上变革快，无论需求文档做得如何细致，考虑得如何全面，总会有些难以预见的需求变更在每天困扰着我们。开拓职员苦恼，产品运营职员更苦恼，毕竟谁也不愿意捂着脸一遍一各处求人改需求。
但是，虽然天下充满未知的变革，但是有一些大的方向还是可以把握的，无论是产品运营还是开拓职员，都可以在需求确立以及需求评审时多多考虑一下姬小光说的这些方面，相信一定可以减少一些后期的变更本钱。
下面这些内容紧张是从开拓职员的视角考虑的，多数基于姬小光的个人履历，难免有失落偏颇，不当之处还望示正。当然，如不嫌弃，感兴趣的产品和运营职员也可以稍作参考。
1. 细节变更需求
在项目初期，如果产品职员没有想清楚需求的细节，那么细节的变更可以说是无法避免的。那么作为开拓职员唯一能做的便是，在设计程序构造和逻辑的时候，只管即便预留出可扩展的能力。比如模块的增删，字段的增减，页面样式的微调等，除此之外也没什么好办法了。别灰心，这都不是事儿。
2. 跨平台需求
跨平台需求有时候来的非常暗藏，每每最初方案的时候觉得可以先在一个平台考试测验一下，比如先方案了 PC 端，但是 PC 真个某些功能又会忽然很急匆匆的想移植到移动端。
而需求职员每每会想当然的认为，功能差不多，只要挪一下就可以了（平移过去/拼过去）。或者是，页面长的差不多，就改成移动真个大小就可以了（缩一下）。殊不知各个平台无论在架构支配，还是操作体验上都有着寰宇之别，如果不提前方案好，那一定是个大坑。
3. 扩展需求
无论是什么样的业务，随着业务量的增长，以及产品运营职员希望的膨胀，都会催生出各种扩展需求。任何固天命量的，都会增加。任何单一须要的，都会变成多个。
比如页面上设计了三个商品推举位，就要预留出变成六个、九个，乃至分页的能力。一个接口是给某个业务专用的，某天就可能变成通用的。一个大略的静态页面，某天就可能变成附带管理后台的繁芜系统。对付扩展性需求，要反复确认，不必过度优化，但也要留出合理的扩展空间。
4. 非常流需求
非常流需求每每随意马虎被忽略，或者多有疏漏。常见的非常流有图片数据加载不出，图片不存在，接口挂掉，网速慢，未登录，登录态丢失，查询出错，查询无数据，内容溢出，用户输入溢出，用户输入造孽，视觉遮挡不可用等等等等。
那么，对应这些非常流情形，就要有配套的前端提示给用户，勾引用户进行其他操作。这些非常流每每会在设计稿和文档中遗漏掉，比如各种非常提示浮层，须要登录态的操作，结果登录态丢失等等，都须要有对应的勾引。
5. 内容运营需求
所有静态的内容，都可能变成运营需求。静态广告位可能变成轮播广告位，轮播广告位可能变成须要运营后台填写数据，而不是直接写去世在页面里。或者某一天可能变成从其余一个自动数据源拉取数据。
关于内容运营需求，评审初期可以确认好运营频次，如果是个把月才改一次的，险些不耗人力的，那也没必要都搞工具。但是如果每天改一次，或者觉得运营内容的韶光已经影响到正常的事情，或者远远大于写个工具的韶光，那还是老诚笃实开拓个运营工具吧。
6. 内容校验需求
上面既然说到运营工具了，那么作为运营工具一定是由运营职员自己来填写。既然是非技能职员填写，操作就难免要傻瓜一点，或者说非技能一点，只管即便操作简洁，并且可以校验输入。如果由于运营职员多打了个空格，活着多写了个英文逗号系统就挂了，那该当算谁不尽责呢？
还有，能分别运营的字段要分别运营，由于有的时候虽然内容看上去是合在一起的，但是常常会有部分修正的需求，不如分开两个字段。比如广告位链接和埋点 tag，链接可能常常换，但固定位置的 tag 值就不会换，以是分开运营会好一些。
7. 内容复用需求
运营同学的事情是很辛劳的，设想一下每天一边开着 excel ，一边开着你的运营系统一个字段一个字段填写的时候，就知道画面有多美了。以是，运营填写的数据一定是有复用需求的。
比如 h5 页面上运营的数据，有可能还须要给原生 app 利用，乃至给 pc 端也用一套数据。一个广告图片和链接，可能被插入到多个页面的顶部或底部，一起更新。多多沟通复用需求，可以随手拯救一大波运营妹子。
8. 内容历史需求
既然运营妹子这么不随意马虎，那么事情量 KPI 如何衡量呢？这么辛劳再没人知道不是太惨了？以是，运营的数据一样平常是要有历史的。
如果就一个坑位，每次都改掉内容来更新，上一次的就没了，那么鬼知道我一天改了多少次？一周做了多少次更新？当然，这里更倾向工具类的需求了，不过我重点要说的是，有运营需求，就可能有运营的历史记录需求。
9. 排序&打标需求
排序需求实在也是内容运营需求的一种，无论是运营填写的还是自动拉取的内容，永久都会有调度顺序的需求。不同的坑位对应不同的关注度，不同的视觉焦点，浏览路径。运营每每须要通过调度位置或者加些标记来突出某些内容。
比如商品列表，可能近期有几个商品比较好卖，就挪到前面，打上 hot 或者 new 的标记，从而匆匆成更多的销量。对付排序和打标需求，每每从后台开始就要预留可扩展字段，到前端也要可以方便的调度位置和加 icon 标记才行。
10. 筛选需求
对应于排序和打标，筛选也是常常用到的。比如我搜集了一坨数据，又只想挑一部分来展示，这时候每每须要一个可以方便操作的地方，类似帖子加精，评论置顶等等。商品类的数据筛选需求就更多啦，不过一样平常可以集成在搜索功能中，作为通用接供词给。但是，运营同学手动填写的数据再进行筛选，那功能就只能业务侧自己设计了，可以根据须要增加不同的筛选字段供运营同学填写。
11. 数据统计需求
数据统计需求是很随意马虎失落控的一种需求，产品运营最初每每以为我要个 PV UV 啥的就够用了，过几天可能说能不能统计下这个按钮的点击量，再过几天可能恨不得把所有的操作都埋点，再加上访问路径、购买路径、转化率、蹦失落率、页面勾留韶光、点击热图、鼠标轨迹……再给我出个月度季度报表，趋势图等等。
这里，对付数据统计需求一定要评审时梳理好，乃至我以为可以独立于正常的需求，作为单独的数据统计需求整体梳理后提出。
12. 翻旧账需求
我实在找不到更贴切的词汇了。翻旧帐的意思便是，凡事进到我系统里的数据，都希望有个方便的形式可以看到。比如用户创建的 UGC，一定要有个唯一的地址可以看到这个资源。用户录入的信息，要有个方便的地方可以导出，或者下载 excel。纵然当前的需求不须要你展示历史记录或者以前的任何内容，也要预留出方便的查询接口备用。
13. 报销需求
这个有点诡异，报销关我鸟事？
当然关。许多大公司的报销流程都很严格，毕竟是涉及到钱的问题。那么对付涉及到钱的活动来说，唯一的凭据可能便是你数据库里的数据了。以是有关钱的需求，最好开始就确认好报销须要哪些内容，比如用户的真实手机等等（确认是真人参与活动，没有造假），以此来作为终极报销的凭据，否则就只能运营同学自己出血了。
14. 扩容需求
当业务量稳步上升时就会伴随着扩容的需求，尤其当访问量骤增的时候，快速扩容就迫不及待了。扩容包含很多方面，一些性能方面的问题会在高并发史迅速凸显，比如：查询低效，PHP慢速，无静态化 web，并发压力大等等。
此时关于性能优化的统统知识都可以派上用场了，静态化、缓存、查询优化、锁表等等。而机器扩容也没那么大略，除了机器内容的复制还有相应做事的批量启动，定时任务的实行，日志的归集等等。
以是，如果评估时估量业务会有爆发性增长（如微信活动），在资金许可的情形下不妨多准备些机器，总比一发布就挂了强。
15. 安全需求
这一点放到了末了，同样也是最主要的。安全问题包含的范围非常广泛，虽然有专业的同事卖力安全以及运维干系的事情，但是在需求初期如果能轻微做些戒备就会避免很多问题。一样平常的公司都会有个根本的安全规范，比如如何防止 XSS, CSRF 攻击，如何防止 SQL 注入，如何屏蔽脚本攻击等。
还有一些外部接口须要鉴权的，有时可能做了基本的鉴权，确没有更高等的防护。比如一个人虽然登录了，可以看到自己的某些资料，但是如果这个登录的用户还可以通过相同的接口查看其他人的某些信息，那便是安全问题了。有可能这个信息是存储在相对独立的表中，并没有严格挂在这个用户id下，那么查询的时候就一定要再检讨一下数据和用户的对应关系。
对付安全需求，普通前后台开拓职员能做的实在并不多，能按部就班做好这些根本防护就不随意马虎了。加上公司公共的安全扫描平台，基本上可以杜绝绝大部分安全问题了。之以是写到这里单独列一条，还是希望大家要对安全足够重视。
综上所述，绝大部分的隐性需求都是有迹可寻的。然并卵，即便沟通再明确，邮件再确认，改来改去啪啪啪打脸，该做的需求还是要做，以是，节哀吧。
作者：姬小光，微信公众号“姬小光（ID：hi-laser）”
本文由 @姬小光 原创发布于大家都是产品经理。未经容许，禁止转载。
题图来自Unsplash，基于CC0协议
