标签：
产品经理日常工作中的不确定性因素，无外乎功能bug和需求变更。大概有哪些要点，可以在产品运营的角度，通过预先调研和事前确认，达到有所准备呢？本文试列六点来抛砖。
1、实现上的问题
（1）掌握需求涉及的数据表概况
这是后五点的基础，如字段类型、范围，取什么、怎么取，返回到哪里，返回以后影响哪些现有字段等（在人员变动剧烈的大环境下，这一步往往并非易事）；
（2）内外部协同
正如军事地图的“边缘”最容易被突破一样，在跨模块、跨域等多方接口处是bug最为频发之处，也容易出现三不管地区，有必要特别关注接口处的数据情况，尤其是目前’开放‘的大形势下，合作方接口的问题是不确定性的’大户‘；
（3）流程本身缺陷
逻辑再周全，怎奈数据源头不匹配，越老的系统该情况越严重。老实说如果不做好第一步基本数据情况收集，根本无法绕过这些地雷，造成完全失控。理论上讲，收集流程本身缺陷，还能为业务流程的改革提供参考。怎么说呢？从it反过来推动商务，或许始终也就是理论上讲讲而已。
2、性能隐患
（1）需求涉及的字段中，哪几个是访问最为频繁的，具体有多频繁。最为频繁的字段（及其上下级父子）在同期项目中是否有重叠，具体重叠程度；
（2）需求所在页面，是否是并发高发的关键页面，或者是否会产生关联影响，包括上下级相关页面；
（3）如果是举办活动，是否做好了功能和监测上的多方面预备。
3、不同时效的应对
区分长期、周期、一次性、有可能多次重复的一次性。
一次性可以采取半自动半人工的山寨方案，加快实现进度；
周期性的可以考虑开发工具，提高复用能力；
中间状态，有可能多次重复的，根据历史经验，一部分一部分地实现工具化。
4、中途需求变更
事先考虑不涉及逻辑、可能会变动的地方，如数据的数量，更新的频率。培养这方面“常识”和“习惯”，在需求里就提出冗余，做提前考虑。
考虑可能会增加的复杂关联和全新逻辑，并提前预估这些变更的工作量。
确实发生了无法拒绝的巨大需求变更怎么办？理论上通过所谓“挖掘需求方的真实目的，来加以引导，实现双赢”来处理需求变更，实际工作中并没有这么理想化，需求变更涉及复杂的利益纠葛，往往就是没办法双赢，尽量凭专业判断，尽可能不要卷入阵营（实际上还是看团队文化，随缘吧）。
5、体验
关键流程（如购物车，支付页面）是否增加了额外步骤，或有所影响。如果涉及，尽可能不要碰关键流程，采取异步等平行方式，避免风险失控。关键位置的哪怕小小文字修改，也需加倍谨慎。
任何一个细节都考虑性能，页面打开和响应速度是一切用户体验的基础，尽可能让运维角度的思考渗透在潜意识里。
6、监测
对现有监测部署的影响，全局意识，不仅要保证新需求的正确监测，也要保证不影响已有的其他监测。
考虑cookie以及js等互相影响，同业务反复确认监测的互相覆盖特性。
数据监测的注意点：重点考虑加上和撤下两个时点，是否有异常走势。？
s捕获数据，服务器log监测，业务数据等常见监测角度，根据具体需求，选择关注的侧重点。
文章来源：人人都是产品经理
标签：