这六点,可帮你在产品设计初期减少不确定因素

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

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

jianshaobuquedingyinsu

1、实现上的问题

(1)掌握需求涉及的数据表概况

这是后五点的基础,如字段类型、范围,取什么、怎么取,返回到哪里,返回以后影响哪些现有字段等(在人员变动剧烈的大环境下,这一步往往并非易事);

(2)内外部协同

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

(3)流程本身缺陷

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

2、性能隐患

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

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

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

3、不同时效的应对

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

  • 一次性可以采取半自动半人工的山寨方案,加快实现进度;
  • 周期性的可以考虑开发工具,提高复用能力;
  • 中间状态 ,有可能多次重复的,根据历史经验,一部分一部分地实现工具化。

4、中途需求变更

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

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

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

5、体验

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

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

6、监测

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

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

数据监测的注意点:重点考虑加上和撤下两个时点,是否有异常走势。?

s捕获数据,服务器log监测,业务数据等常见监测角度,根据具体需求,选择关注的侧重点。

 

作者:scvhuang

来源:http://www.jianshu.com/p/ef2fc054f8e5

本文由 @scvhuang 授权发布于人人都是产品经理,未经作者许可,禁止转载。

您的赞赏,是对我创作的最大鼓励。
2人打赏

评论( 1

登录后参与评论
  1. 设计

    回复
加载中