最近看了很多PRD,发现一个特别重要的点,大家在输出需求的时候会更关注策略逻辑,功能交互等规则,逻辑类内容。

但是,现实中我们会经常看到因为非逻辑性错误导致产品失败的一些案例,严重可能会引起线上事故。

比如在互联网医疗行业,如果线上出售的药品包含OTC(over the counter,非处方药)药品,这种情况下,页面交互设计体验再好,不符合行业规范都是无法通过应用市场审核,甚至面临行政处罚。

因此,产品经理在定义策略产品的需求时,除了逻辑规则,更多应该关注非规则类约束。

1.可解释性

“可解释”广义上是指在用户需要了解或解决一件事情时,他们可以获得所需要的信息,主要是为了提升用户对于产品的信任度,在个性化推荐系统中就有很多的应用。

亚马逊的首页的一个推荐模块,在模块的左上角会标记“根据您的所购商品推荐商品”,这是根据用户最近的行为给出的推荐解释。

除了上述类型的推荐解释,还可以应用商品本身的特色来进行推荐解释。下图是京东为你推荐模块,其中“甄选健康原料”,“重量仅522g”,“商场同款”等都是一种推荐策略产品可解释性的表现。

写需求文档,这三个点注意一下

京东为你推荐的推荐解释

2.数据安全机制设计

产品安全性是近几年被频繁提及的一个话题,尤其是用户个人数据的安全,这其中尤为重要的就是用户数据的授权使用环节。

Facebook泄露数以亿计的用户数据,导致很多用户的信息被不明机构滥用,被视为近十年最严重的数据泄露事故,这其中更让人不解的是很多用户竟然不明不白的就授予了产品个人数据的使用权。

数据在策略产品中的重要性不言而喻,因此获取用户数据授权是其中的一个必需的流程。在设计用户数据授权策略时,需要考虑:

哪些数据需要获得用户的授权?

授权的期限是多长?

关闭授权后的再触发机制怎么设计?

随着大众数据安全意识的提高,滥用用户数据,甚至泄露用户数据会对企业造成难以估计的影响,因此用户数据的安全性需要在策略需求中重点考虑。下图是饿了么在获取QQ登录的授权页:

写需求文档,这三个点注意一下

用户在互联网产品上的行为可以分为两种:显性行为和隐形行为。显性行为是指用户主动发起的,如:点击,评论,赞同,评分等等;隐形行为是指并非用户主动产生的,而是产品通过一定的手段收集到的用户行为,如:停留,注意力等。

产品在使用由用户主动发起的行为数据时,产品经理来只需要设计好对应的授权协议,并且保证用户的知情权,让用户不会觉得被侵犯;但是,对于隐形行为的使用则更可能触犯用户的个人隐私,主要包含个人的私生活、日记、照相薄、生活习惯、通信秘密、身体缺陷等等。

在设计个性化推荐系统的时候,经常会用到用户的浏览行为来推测用户的偏好以及意图,在制定推荐召回策略的时候,会把涉及到个人隐私的行为或者商品进行过滤,保证用户在产品端的体验。

3.性能的评估

按照通用的定义,软件性能是软件的一种非功能特性,它关注的不是软件是否能够完成特定的功能,而是在完成该功能时展示出来的品质,也就是说软件性能是衡量软件完成任务质量高低的一个标准。比如响应时间,吞吐量,并发用户数,资源利用率等,都可以用来衡量一个软件的运行情况。

在很多团队的软件项目管理中,软件性能会在软件研发完成之后,由专业的测试人员来进行测试,产品经理则不会关注。但是对于策略产品来讲,性能是必须要关注的一个点,因为大部分策略需求都需要用到数据来进行运算和逻辑开发,这其中带来的不确定性极有可能引发线上事故。

作为策略产品经理不必太过关注系统层面的性能,比如接口性能,研发人员在架构设计阶段会进行评估的。但是,需要在策略需求阶段对当前产品的数据需求进行预研。主要包括两个方面:

首先,是当前产品数据现状的调研,比如当前页面近一个月日均流量数据,峰值流量等,并且在PRD中进行陈述,主要是为了给研发工程师在开发过程中进行正确的架构设计;

其次,是针对策略需求中涉及到软件性能的指标进行正确的定义。比如在人群画像标签的计算当中,哪些标签是需要实时计算同步,哪些标签需要离线计算、T+N同步,两种需求的解决方案完全不一样,明显前一个需求对系统时效性的要求更高。

如果涉及到接口服务的调用,还需要为接口提供方提供数据预研结果,比如QPS(每秒查询率,Queries-per-second),它是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准,以便对方评估调用可行性。QPS一般的计算方式如下所示:

QPS=(总PV数 * 80%) / (每天秒数 * 20%)

即每天80%的访问集中在20%的时间,这20%时间叫做峰值时间。

以上就是在输出策略需求的时候,需要注意的一些非规则类约束条件。