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