7月28日参加了曹大的付费网课：产品经理入门——如何有效沟通需。这是曹大第一次开网课，报名费是99元，因为是第一次网课，曹大只是为了进行产品测试，最后将报名费用都返给了大家。现在将曹大讲的一些主要干货分享给大家：

 一、目标一致性原则

目标一致性，就是你要确保研发和你，对产品的理解，定义，用户目标，运营目标，有相对一致的认识。但这里还有个前提，更首先的是，你要确保你自己，对产品的理解，定义，用户目标，运营目标，和你的老板有一致的认识；如果产品经理自己都没有想清楚这个需求的背后逻辑，那么研发就很难认可你这个需求的价值。

初阶产品经理，甚至很多有经验的产品经理，都会很想当然的以为，研发对你所提需求的背景和自己一样了解。或者，有更恶劣的，认为研发不需要了解。我写了文档你去实现就好，不要考虑这么多，这是非常恶劣的一个思考方式。研发如果了解不足，或者有误解，会产生怎样的问题呢？

1、如果文档不规范，研发自由发挥余地很大，可能做出来的东西跟你想要的就完全不是一回事了。

2、就算文档很规范，研发也都按文档实现了，但是，也可能存在一些认知问题，导致如下两个结果：

（1）研发会基于自己对产品运营，产品目标的理解，做结构上或性能上的准备，比如说，大量时间用于无用功，这种事情特别特别特别常见。很多时候，你们发现研发效率很低，不是研发不干活，是把活干拧巴了。

（2）其二是完全相反，仅仅满足于功能实现，可能该做的准备没有做，导致性能考虑不足，运营支持度考虑不足。这也是特别特别特别常见的问题！怎么强调都不过分。

你可能知道，这个产品要做成什么样子，要有什么功能，要有什么角色，用户怎么用，但核心去追问一下，这个产品真正的核心目标，产品价值，是怎么定义的，如果你是跟随产品总监，或老板定义的项目，这个问题一定要事先搞清楚，否则很可能你把东西做出来，但在老板眼里，其实你完全不在状况。

解决方案：

在功能诉求之前，让技术理解产品的真实目的，目标用户群，业务诉求，运营途径，推广途径等。对产品涵盖范围要有清晰的认识和了解。在目标一致性的原则下，研发可能有更有效率的实现方式和解决途径，这时候，鼓励他们参与讨论，是非常有意义的。当然，最终决策权还在产品经理的手中。

二、产品需求文档的规范性

产品文档要包括以下几个部分：

1、要有总纲

产品文档首先应该列出总纲，也就是上文提出的，整体目标的定义；描述产品需求定义，用户目标及产品目标定义，相关边界定义。描述产品构成，功能视图的清单，基本操作流程，角色构成，主要数据构成。最好能用流程图，或大纲图，让研发首先对产品有一个完整的认识。

另外，关于目标一致性原则，文档要体现，但不能只用文档体现，必须当面交流沟通清楚，文档只是一个确认和重复的过程，不是说我文档提到了就可以不沟通的，有些研发真不看背景信息的，直接咔嚓咔嚓编码，最后发现很多问题的时候，说你没写清楚。

我认为总纲主要是要把需求的目标和业务逻辑（服务逻辑）梳理清楚。

2、界面和交互

（1）界面布局（下面说的视图就是产品界面）

就是基于不同角色、不同终端的视图说明。一个产品，使用者可能存在多个角色，比如网课，有讲师端，有学员端，还有系统管理端，至少三个角色，后面还会细分，比如系统管理又有客服，数据分析，以及Boss不同角色。除了角色呢，还有不同的终端，以前简单，说互联网产品都是pc端，而绝大部分都是网页端体现，现在是pc和移动终端，所以，每个功能视图，都要说明是哪个角色，在哪个终端的体现。

视图最核心的，是页面布局，不论是手机终端，还是pc终端，不论是app，网页，还是客户端，都是页面布局，哪里放什么，哪里有什么。页面上的元素，通常主要包括图片，图标，文案（固定的内容），信息和数据（与请求相关的交互内容），交互操作项（比如搜索，排序或点击等）。

（2）数据逻辑

比如说，我们在游戏页，看到一个推荐相关游戏，在商品页，看到一个推荐相关商品。这是一个信息数据的展示，但背后的逻辑是什么，算法是什么。

一种，是产品经理有明确的逻辑，比如说，最新新闻，基于时间逆序显示多少条；比如说，最热新闻，可能是基于最近几天的点击率逆序显示多少条。这个是明确的数据逻辑，但产品经理也要写出来，也许你不写，研发自己发挥，可能最热新闻这里，就把系统所有历史新闻基于点击率逆序，那么可能最热新闻就十年不变的挂着陈冠希艳照门，这就不好了。

另外一种，是产品经理没有明确的逻辑，但有明确的目标，比如说，这里有一个相关游戏推荐，但这个相关游戏的目标是什么？是点击率，好，这是目标，如何产生高点击率的相关推荐，产品经理可能不知道算法策略，需要程序员思考，但至少要让他知道目标是什么。

（3）交互逻辑

鼠标停留有什么效果，点击有什么效果，哪里可以点击，哪里不可以点击，滑动是什么效果，这些都是操作。些页面元素是可以操作的，是如何操作的，操作后的反馈是什么，操作后是否进入新的视图或链接到其他视图，这些都是要标注清楚的。 

（4）异常和容错性说明

用户输入错，用户输入异常，用户搜索无结果，相关信息不存在的时候，页面应该如何提示，反馈。如果产品不提供任何说明，可能研发就会自行其是，如果研发有一定产品意识，这个地方是可以处理好的，但这样的研发可遇不可求。如果这些研发都能考虑的很好，要我们产品经理又有什么用呢。

比如，我这个页面显示附近的信息，如果附近没有信息，会提示什么。我这里需要输入账号密码，如果用户输入错误需要提示什么。以此类推……容错在很多时候也是产品竞争力，比如典型如搜索引擎，google和百度其实都有很强的搜索容错能力，但这个话题技术性太强，就不展开了。

三、测试与反馈

1、要进行单元测试

每个模块，每个独立的功能特性，其实理论上应该是可以测试的。单元测试的目的是在研发早期发现问题，尽早纠正问题，但由于产品研发早期，相关视图和功能不完整，所以很多产品人员不知道怎么做单元测试，或者认为这是一个纯粹的技术工作。的确，单元测试更多是技术原型，技术可行性的测试，但产品人员如果有参与，有意识的去了解，对产品的质量和研发周期把握会更有效果。更何况，很多初级的技术人员根本没这个意识。

单元测试，要有测试目标，这个要和研发一起确认。单元测试，不要求全责备，比如说，基于已有的数据，我只测试一下相关推荐的逻辑对不对，或者只测试某个关键业务流程的操作是否和预期一致。明确测试目标，测试角色，测试流程，以及测试用例，这是做好测试的前提。

尤其是开发周期较长的项目，如果中间没有任何测试，什么时候去问，都说正在研发中，结果导致产品失控，出来后发现很多问题已经不好修改了。

2、整体测试

整体测试，又分线上环境测试和测试环境测试，一般企业研发会分测试环境和线上环境，正常情况下线上环境跟测试环境应该是完全一致的，但也出现过一些不一致的情况。例如，为了提高网站的访问速度，通常都会将图片、js、css等静态文件存储到七牛等云存储空间，开启融合CDN，如果在本地服务器修改了图片、样式等，但是没有刷新文件预取。就会因为缓存的问题，CDN加速等问题导致线上的文件没有更新。所以，测试环境测试无误后，上线了也要最终确认一遍。

3、反流程测试

用户是否会如愿按照你所期待的流程操作产品呢？这个真不一定。你希望用户是a,b,c,d这样操作，用户有没有可能 a,c,b,d呢。 现实中有这样的案例，就好比我们网课系统的问题，用户从官方公众号进入，选择课程，点击付费，这是一个标准流程，但如果用户从别人分享进入课程，点击付费，怎么就出问题了，类似这样的问题其实还有很多。 刚才讨论区里提到的一些问题也属于这类问题，说明我们自己的测试也是不达标的。

4、数据规模及并发压力测试

你一个应用刚开始，只有几百条信息，你觉得所有操作响应都很快，你很欣慰，但数据到了几百万条的时候，是不是还可以这样。同样的功能，同样的诉求，1万条记录，100万条记录，1亿条记录，100亿条记录，这个处理方法和系统架构是完全不同的，当然，我们创业初期没必要考虑过于长远，淘宝刚开始还用开源软件做了一年呢，开始不用过度考虑，但我建议至少你要做第一步的准备。说到底还是个度的问题，过度考虑性能和并发会太浪费技术资源，但完全不考虑你业务发展起来的时候真就欲哭无泪。、

5测试反馈

你要先做好问题的分类，哪些是可用性的问题，哪些是操作体验的问题，哪些是运营支持上的问题，哪些可能算不上问题，只是一些建议和想法。列好分类后，列好严重程度，以及优先级。有些问题可能很严重，但未必紧急，可能这部分业务暂时不开展，或者相关市场资源还没准备就绪。所以要把优先级，严重程度分开标记。

四、需求边界

什么是需求边界？我们定义一个功能，定义一个数据逻辑，但我们要知道，技术有研发成本，同一个功能，一个数据逻辑，如果我们知道用户诉求的边界在哪里，可能就会减少很多无用功，提升研发效率。

1、数据覆盖率边界

有个例子我经常提的，百度，淘宝，google，搜索结果都是不会超过100页的，很少人意识到这一点，为什么？大翻页是个典型的技术问题，不管用商业数据库，还是自己的索引结构，大翻页的效率损失都是很可怕的。不论你用百度，用google，用淘宝，你会翻超过100页么？这就是需求边界。如果你把这部分需求屏蔽掉，技术问题就解决了，那你说，我搜不到怎么办，换关键词会不会，换搜索条件会不会，你真的会翻100+页么？

2、数据精确率边界

再举个例子：以前还有一个朋友，做app 市场数据排名跟踪，跟我说存储量太大，我说你存的什么东西，存每天，每个app的排名变化，我就说一点，我说作为app的管理者也好，作为竞品分析也好，这个app今天第五名，明天第三名，这个变动是有意义的，对吧。这个app今天105名，明天103名，这个变动有意义么？

什么意思呢？如果排名低于多少名，并且变动少于一个比例，这个数据不用记录，展现的时候就取前一天的数据，一条直线，这个变动没意义。什么时候变动超过这个比例了，再记录，结果，数据存储规模一下子减少了2/3还不止，那每天的系统处理效率也提高了。

还有一个精确度的边界问题，当然，我们希望说数据是完全精准，完全精确的，但有时候，你容忍度宽一点，系统设计的复杂度就低很多。

3.功能性边界

功能性边界，可以理解为功能的灵活度和完整度的问题。尤其是后台的需求，需求的提出方总是希望后台配置的越灵活越好，每个参数都可以自定义，数据显示的越完整越好，想看什么纬度的数据都可以。这样就会带来研发成本的显著提升，因为有的参数，可能一年就只需要改一次，根本就不需要在后台增加修改入口；如果不对产品的功能性边界进行界定，就会造成开发资源的巨大浪费。

五、产品经理需要了解的一些技术知识

曹大建议产品经理要了解最常见的三个性能指标：数据规模，每秒响应频次，最大并发诉求；安全风险相关概念：SQL注入，跨站脚本，XSS攻击，撞库攻击，cc攻击；以及架构相关概念。