怎样在产品设计初期减少不确定因素

（本文是2011年还在麦考林时候的随笔，偶尔翻出来，现在似乎仍然适用，从被动应对问题，到主动预测问题，是入门到资深的必经之路。）

产品日常工作中的不确定性因素，无外乎功能bug和需求变更。大概有哪些要点，可以在产品运营的角度，通过预先调研和事前确认，达到有所准备呢？本文试列六点来抛砖。

1、实现上的问题

首先是掌握需求涉及的数据表概况，这是后五点的基础，如字段类型、范围，取什么、怎么取，返回到哪里，返回以后影响哪些现有字段等（在人员变动剧烈的大环境下，这一步往往并非易事）；

其次是内外部协同，正如军事地图的“边缘”最容易被突破一样，在跨模块、跨域等多方接口处是bug最为频发之处，也容易出现三不管地区，有必要特别关注接口处的数据情况，尤其是目前’开放‘的大形势下，合作方接口的问题是不确定性的’大户‘；

第三是流程本身缺陷。逻辑再周全，怎奈数据源头不匹配，越老的系统该情况越严重。老实说如果不做好第一步基本数据情况收集，根本无法绕过这些地雷，造成完全失控。理论上讲，收集流程本身缺陷，还能为业务流程的改革提供参考。（怎么说呢，从it反过来推动商务，或许始终也就是理论上讲讲而已）

2、性能隐患

需求涉及的字段中，哪几个是访问最为频繁的，具体有多频繁。最为频繁的字段（及其上下级父子）在同期项目中是否有重叠，具体重叠程度；

需求所在页面，是否是并发高发的关键页面，或者是否会产生关联影响，包括上下级相关页面；

如果是举办活动，是否做好了功能和监测上的多方面预备。

3、不同时效的应对

区分长期、周期、一次性、有可能多次重复的一次性。

一次性可以采取半自动半人工的山寨方案，加快实现进度；

周期性的可以考虑开发工具，提高复用能力；

中间状态 ，有可能多次重复的，根据历史经验，一部分一部分地实现工具化。

4、中途需求变更

事先考虑不涉及逻辑、可能会变动的地方，如数据的数量，更新的频率。培养这方面“常识”和“习惯”，在需求里就提出冗余，做提前考虑。

考虑可能会增加的复杂关联和全新逻辑，并提前预估这些变更的工作量。

确实发生了无法拒绝的巨大需求变更怎么办？理论上通过所谓“挖掘需求方的真实目的，来加以引导，实现双赢”来处理需求变更，实际工作中并没有这么理想化，需求变更涉及复杂的利益纠葛，往往就是没办法双赢，尽量凭专业判断，尽可能不要卷入阵营（实际上还是看团队文化，随缘吧）。

5、体验

关键流程（如购物车，支付页面）是否增加了额外步骤，或有所影响。如果涉及，尽可能不要碰关键流程，采取异步等平行方式，避免风险失控－－关键位置的哪怕小小文字修改，也需加倍谨慎。

任何一个细节都考虑性能，页面打开和响应速度是一切用户体验的基础，尽可能让运维角度的思考渗透在潜意识里。

6、监测

对现有监测部署的影响，全局意识，不仅要保证新需求的正确监测，也要保证不影响已有的其他监测。

考虑cookie，js等互相影响，同业务反复确认监测的互相覆盖特性。

数据监测的注意点：重点考虑加上和撤下两个时点，是否有异常走势。js捕获数据，服务器log监测，业务数据等常见监测角度，根据具体需求，选择关注的侧重点。

大致先到此为止。