2017-07-28，caoz 在他的网课产品「易灵微课」里，做了一堂《产品经理入门 - 如何有效沟通》讲座，作为 caoz 的朋友兼三脚猫产品经理，自然去学习了。但最近「知识星球」自己遇到一堆事（直到现在 iOS 版都还没恢复上架），心境其实是乱的，没有认真学和整理。
这几天打算静下来，继续高效率地学习和工作，就从这里开始吧。
以下为 caoz 的讲课内容，我只做些许整理、润色。
—
很多公司对产品经理定义不同的，共性最大的两部分职责是：
- 产品需求设计；
- 研发沟通协调。
有争议的工作范畴主要是：
- 产品需求之前的市场调研分析；
- 产品上线后，后续的运营决策支持及反馈。
这个讲座只涉及研发的沟通协调，想解决的问题是：
- 我提出了需求，研发也表示知道了，但做出来的东西为什么和我提出的不一样？
- 我提出的是个很简单的需求，为什么研发说要做很长时间，甚至说不能做？
- 我提出了需求，研发也做出来了，也顺利上线了，但运营中常存在奇怪的问题，经常出故障，或者想做一些运营调整，特别难。
我没有最终的解决方案，只是分享在这方面我的思考、尝试，以及我所遇到的一些典型问题的原因分析，希望对各位有兴趣从事产品经理职业的同学有帮助。列举的场景都是小公司、创业公司、新人产品经理所容易犯的错误，不一定适合大公司或者比较有经验的产品经理。
今天分五个话题
第一个话题是目标一致性原则。 第二个话题是产品文档规范。 第三个话题是测试与反馈。 第四个话题是需求边界。 第五个话题是产品人员需要了解的一些技术常识。
目标一致性原则#
目标一致性是指：要确保研发和你对产品的理解（至少包括产品定义、用户目标、运营目标）有相对一致的认识。
有个隐含的前提是：你要确保你自己的认识和你的老板一致。
你可能知道，这个产品要做成什么样子，要有什么功能，要有什么角色，用户怎么用，但应该追问：这个产品真正的核心目标和产品价值是怎么定义的？如果你是跟随产品总监，或老板定义的项目，这个问题一定要事先搞清楚，否则很可能你把东西做出来，但在老板眼里，其实你完全不在状况。
搞清楚之后，要让研发也知道。初阶产品经理与研发沟通最容易犯的错误就是：我以为我知道的背景常识你也知道。
背景常识包括但不限于：这个产品的意义和价值是什么？这个产品的核心用户群是谁？这个产品的目标市场是什么？这个产品的运营特点是什么？这个产品的涵盖范围是什么？
研发如果了解不足，可能会产生的问题有：
- 如果文档不规范，研发自由发挥余地很大，可能做出来的东西跟你想要的完全不是一回事；
- 就算文档很规范，研发也都按文档实现了，存在一些认知问题，也可能导致：
- 会基于自己对产品运营，产品目标的理解，做结构上或性能上的准备，比如说，大量时间用于无用功，这种事情特别特别特别常见。很多时候，你们发现研发效率很低，不是研发不干活，是把活干拧巴了。
- 仅仅满足于功能实现，可能该做的准备没有做，导致性能考虑不足，运营支持度考虑不足。这也是特别特别特别常见的问题！怎么强调都不过分。
所以，在功能诉求之前，要让技术理解产品的真实目的、目标用户群、业务诉求、运营途径、推广途径等。对产品涵盖范围要有清晰的认识和了解。
在目标一致性的原则下，适当允许和鼓励技术参与产品讨论和功能规划。
因为今天我们强调的一个目标是什么呢，是研发效率，通过有效沟通提升研发效率，那么，在目标一致性的原则下，研发可能有更有效率的实现方式和解决途径，这时候，鼓励他们参与讨论，是非常有意义的。当然，最终决策权还在产品经理的手中。
此外，从沟通技巧来说，要求研发对产品目标进行确认。要求研发在一段时间内，一起回述目标，发现问题点。
回述目标是一个很有效的沟通方法，让对方按他的理解重述一下这个项目的背景和目标。这样就很容易发现双方理解上的歧义。我发现，很多情况下，对方表示完全明白了，但回述的时候，明显和自己的目标是有偏差的，或者对关键的一些要素明显疏漏了。
在目标确认和目标沟通的过程中，几个常见的误区如下
- 过多考虑变通性和适应性，技术准备过剩。
- 上面问题的反面，失去变通性和适应性，导致技术准备不足。
- 未考虑运营手段需求。
- 对数据规模，请求频次无准备，无概念。
特别强调运营手段（比如说分享邀请好友等活动，比如说做市场渠道跟踪的活动，或者比如说代理策略等，都是运营诉求），举两个例子：
- 游戏行业，有人问我这个问题，感觉很多小团队，小公司都可以做出好游戏，而且分服机制下，性能的问题一般不太凸显，那么技术在游戏领域的价值在哪里。我的答复是，好的技术架构，让游戏的运营更简单，更灵活，你有什么运营诉求，直接可以简单配置实现；坏的技术架构，就各种不支持，或者需要长时间二次开发才能支持。
- 电商领域，有个业绩不错的淘品牌，要出淘，做官网，营销能力也很强，老板把自己都搞成微博网红了，很拼的；但自己官网运营活动，一搞秒杀就崩溃。后来我帮他们去看了代码结构，缓存的架构设计问题，积重难返。
产品文档规范#
一些大公司对产品文档有非常严格的规定，从我的角度讲，我不是那种特别强调流程规范性和复杂性的人，其实我认为产品文档并不需要特别复杂，核心在于把东西说清楚，让研发能理解透。
但很多小公司的产品文档，往往过于简陋，仅仅表达了某种产品的期望，而一些非常需要明确的地方都十分模糊，所以，这里强调一下，简单不等于简陋，不需要长篇大论或者说非常繁冗的格式，但一些核心要素不可或缺。
产品文档首先应该列出总纲，也就是上文提出的，整体目标的定义，描述清楚产品需求定义，用户目标及产品目标定义，相关边界定义。
描述产品构成，功能视图的清单，基本操作流程，角色构成，主要数据构成。最好能用流程图，或大纲图，让研发首先对产品有一个完整的认识，切忌不要一上来就是视图1、功能1、视图2、功能2。
强调一下，关于目标一致性原则，文档要体现，但不能只用文档体现，必须当面交流沟通清楚，文档只是一个确认和重复的过程，不是说我文档提到了就可以不沟通的，有些研发真不看背景信息的，直接咔嚓咔嚓编码，最后发现很多问题的时候，说你没写清楚。
总纲之后，就是根据角色，根据功能项的视图描述页了。
一个产品，使用者可能存在多个角色，比如网课，有讲师端，有学员端，还有系统管理端，至少三个角色，后面还会细分，比如系统管理又有客服，数据分析，以及Boss不同角色。除了角色呢，还有不同的终端，以前简单，说互联网产品都是pc端，而绝大部分都是网页端体现，现在是pc和移动终端，所以，每个功能视图，都要说明是哪个角色，在哪个终端的体现。
视图最核心的，是页面布局，不论是手机终端，还是pc终端，不论是app，网页，还是客户端，都是页面布局，哪里放什么，哪里有什么，那么，很多缺乏经验的产品经理，或者一些创业团队，把这个做完，觉得，大功告成了，程序员一看不就明白了么？这就是很多问题所在了。
页面上的元素，通常主要包括图片，图标，文案（固定的内容），信息和数据（与请求相关的交互内容），交互操作项（比如搜索，排序或点击等）。
常见的问题是，只提供了页面基本元素，却没有给予后面的一些逻辑，程序员只能脑补其中的逻辑。
- 数据逻辑
比如说，我们在游戏页，看到一个推荐相关游戏，在商品页，看到一个推荐相关商品。这是一个信息数据的展示，但背后的逻辑是什么？
- 有时候产品经理有明确的逻辑，比如说，最新新闻，基于时间逆序显示多少条；比如说，最热新闻，可能是基于最近几天的点击率逆序显示多少条。这个是明确的数据逻辑，但产品经理也要写出来，也许你不写，研发自己发挥，可能最热新闻这里，就把系统所有历史新闻基于点击率逆序，那么可能最热新闻就十年不变的挂着陈冠希艳照门，这就不好了。
- 有时候产品经理没有明确的逻辑，但有明确的目标，比如说，这里有一个相关游戏推荐，但这个相关游戏的目标是什么？是点击率，好，这是目标，如何产生高点击率的相关推荐，产品经理可能不知道算法策略，需要程序员思考，但至少要让他知道目标是什么。
- 你要把目标说出来，可能是点击率，也可能是别，比如综合收入或其他。
- 要跟程序员过一遍这里的逻辑，要确认这个逻辑是可行的，效果是可以持续跟踪和优化的。
你不说，技术人员脑补，优秀的技术人员也许会做的很好，但如果技术人员也缺乏行业经验和目标认知，也许就会做出很不靠谱的设计。
数据逻辑中还包括一个重要的原则，需求边界，后面单独展开。
- 交互操作逻辑
鼠标停留有什么效果，点击有什么效果，哪里可以点击，哪里不可以点击，滑动是什么效果，这些都是操作。
哪些页面元素是可以操作的，是如何操作的，操作后的反馈是什么，操作后是否进入新的视图或链接到其他视图，这些都是要标注清楚的。
产品设计者如果觉得，我把页面元素都摆出来了，你难道不知道这个地方可以点击么？你难道不知道这个点击链接的是之前的某个视图么？运气好，研发知道；运气不好，真的不知道。
- 异常和容错性的一些说明
用户输入错，用户输入异常，用户搜索无结果，相关信息不存在的时候，页面应该如何提示，反馈，如果产品不提供任何说明，可能研发就会自行其是，如果研发有一定产品意识，这个地方是可以处理好的，但这样的研发可遇不可求。
这个标注，让研发可以理解即可，比如你简单的做个页面布局的范例，分A,B,C,D四个区块，其中B是一个猜你喜欢的功能，然后文档描述一下，说猜你喜欢这个功能的目标是什么，测试标准是什么。
然后说明这里的每个内容展现格式，链接到哪里，也许是前面另一个视图。
比如，我这个页面显示附近的信息，如果附近没有信息，会提示什么。 比如，我这里需要输入账号密码，如果用户输入错误需要提示什么。 以此类推。
这里多说一句，容错在很多时候也是产品竞争力，比如典型如搜索引擎，google和百度其实都有很强的搜索容错能力，但这个话题技术性太强，就不展开了。
回顾一下，文档的规范，需要：
- 有总纲。有整体流程、产品目标、角色构成、运营策略，以及不同视图之间的关联关系。要让研发对系统有一个完整性的认识。
- 总纲之下，是基于不同角色、不同终端的视图，具体的产品描述基于视图。视图首先要明确是什么角色，在什么终端的体现。视图应包括如下信息：
- 页面元素和布局；
- 数据逻辑（含需求边界）；
- 交互操作逻辑；
- 异常、容错和错误提示；
再次强调：文档不能替代沟通。
测试与反馈#
大公司会有独立的测试部门，小公司，创业公司往往没有这部分的人力资源。测试与反馈也是非常重要的产品与研发沟通的范畴。
测试本身是一个专门的很深入的领域，但我们说，产品经理，并不是说要成为测试领域的专才，但是：一要参与测试；二要能就测试给出研发合理的反馈。这样才可以更好的进一步协调和确保产品质量和进度。
- 要有单元测试的概念。每个模块，每个独立的功能特性，理论上应该是可以测试的。
单元测试的目的是在研发早期发现问题，尽早纠正问题，但由于产品研发早期，相关视图和功能不完整，所以很多产品人员不知道怎么做单元测试，或者认为这是一个纯粹的技术工作。
的确，单元测试更多是技术原型，技术可行性的测试，但产品人员如果有参与，有意识的去了解，对产品的质量和研发周期把握会更有效果。更何况，很多初级的技术人员根本没这个意识。
早期问题发现不了，那么后期的弥补成本，就会远大于早期。
那么，如何开展单元测试？
单元测试，不要求全责备，因为产品不具备完整性，所以首先要确认测试目标，这是和研发一起确认的，产品经理不能认为研发是一个功能，一个功能按次序完成的，很可能有相当的时间用于基础架构，然后快速的实现所有功能。
但一些基础功能特性，是可以优先测试的。而测试的时候，交互界面可能很不友好，或者只是一些临时的显示，但你要明确，你的测试目标是什么。
比如说，基于已有的数据，我只测试一下相关推荐的逻辑对不对，或者只测试某个关键业务流程的操作是否和预期一致。
明确测试目标，测试角色，测试流程，以及测试用例，这是做好测试的前提。
但这里强调，产品必须和研发协调进行单元测试，单元测试的目的是有效保障研发效率，以及尽早发现和确认研发中的问题，如果为了测试，而打乱了正常的开发节奏，延误了正常的开发周期，是得不偿失的。
最怕的是什么呢，开发周期很长，而中间没有任何测试，什么时候去问，都说正在研发中，结果导致产品失控，出来后发现很多问题已经不好修改了。
- 整体测试，又分线上环境测试和测试环境测试。
一般企业研发会分测试环境和线上环境，正常情况下线上环境跟测试环境应该是完全一致的，但也出现过一些不一致的情况。
案例：我们以前也遇到过测试环境压力测试完全没问题的系统，线上出现了数据库崩溃，后来分析发现两个环境的数据库版本不一致，对同一条SQL的解析，默认用到的索引不一样，改用强制索引后问题解除。当然这是一个技术问题，但类似的情况很多知名公司也遇到过。经常有这样的场景，测试环境一切正常的系统，半夜趁用户少的时候更新发布，然后团队睡觉休息去，结果早上起来发现重大运营事故。所以线上环境测试这个步骤，真的是有必要的。
测试环境测试是可以做破坏性测试的，而线上环境测试一定要谨慎的多，那么测试的时候一定要区分环境和目标。
所谓破坏性测试，比如发大量的垃圾数据，做各种可能导致系统崩溃或数据库损坏的尝试，以及做一些删除和不可逆转的批量更新操作等等。
我知道这么说很low，很多人可能觉得这太小儿科了，但稍微不注意的话，这样的教训是血淋淋的。
- 关于测试用例
第一：正常流程测试，这是基本都知道的，就是我按照所预期的正常用户的操作流程，操作方式进行测试，看产品功能的完成度，以及可用性。
第二：限制性测试，我输入超长内容，输入带特殊符号的内容，我查询一些错误或者混淆的关键词，我频繁输入错误的账号和密码，我看看系统对这种限制性内容的设计，对错误性信息的提示，对容错性的设计，是否符合预期，是否符合产品目标。是否会出现不应该的提示，或者是否会出现一些系统错误或可能导致信息泄露的技术错误提示。是否会出现一些可能导致安全问题的输入验证不全。这都是限制性测试的目的，但这块后面需要一点技术理解力。我第五个话题会再展开。
第三：反流程测试，用户是否会如愿按照你所期待的流程操作产品呢？这个真不一定。你希望用户是a,b,c,d这样操作，用户有没有可能 a,c,b,d呢。 现实中有这样的案例，就好比我们网课系统的问题，用户从官方公众号进入，选择课程，点击付费，这是一个标准流程，但如果用户从别人分享进入课程，点击付费，怎么就出问题了，类似这样的问题其实还有很多。 刚才讨论区里提到的一些问题也属于这类问题，说明我们自己的测试也是不达标的。
第四：数据规模及并发压力测试，你一个应用刚开始，只有几百条信息，你觉得所有操作响应都很快，你很欣慰，但数据到了几百万条的时候，是不是还可以这样。数据规模和并发压力往往伴生而来，以前我说过，当年山寨icq的，除了腾讯QQ（当时叫oicq），还有好几家，大家起步都差不多，当时的产品特点也基本没区别，为什么今天QQ是一个几千亿美元的公司，其他几家怎么消失了？其实原因特别简单，到100万活跃用户的时候，只有QQ还能继续发展，其他的统统不行了。
我做CNZZ的时候，我当时从开始设计数据结构的时候，就开始做压力测试，功能和视图还都没有去写，就开始对核心特性做压力测试，看看是不是能撑得住数据量，能不能撑得住并发请求，有信心了，才开始去完成代码和功能。
同样的功能，同样的诉求，1万条记录，100万条记录，1亿条记录，100亿条记录，这个处理方法和系统架构是完全不同的，当然，我们创业初期没必要考虑过于长远，淘宝刚开始还用开源软件做了一年呢，开始不用过度考虑，但我建议至少你要做第一步的准备。说到底还是个度的问题，过度考虑性能和并发会太浪费技术资源，但完全不考虑你业务发展起来的时候真就欲哭无泪。
第五：安全性测试，技术话题，暂不展开。
- 关于测试反馈
你测试的结果，如何反馈给研发。一股脑的把问题发给研发，这很容易给对方带来困扰。
你要先做好问题的分类，哪些是可用性的问题，哪些是操作体验的问题，哪些是运营支持上的问题，哪些可能算不上问题，只是一些建议和想法。
列好分类后，列好严重程度，以及优先级。
有些公司会有一些 bug 管理工具，这是最好的，如果没有，用 excel 也不是不可以，但是这些要列出来。有些问题可能很严重，但未必紧急，可能这部分业务暂时不开展，或者相关市场资源还没准备就绪。所以要把优先级，严重程度分开标记。
那么测试反馈出来后，也需要跟进研发的解决，如果有可能，还是建议搞一套bug跟踪系统。这个具体我现在有点落伍，也不知道哪个更好，网上搜一下有很多，不要找特别复杂，所谓功能特别强大的，没必要，找大家都容易理解的，容易实施的就好。
总结：
- 测试是贯穿研发周期的事情，不要所有问题都到那边说，做完了，你们看看吧，才发现，各种不对劲。这样解决成本太高了，要跟研发沟通，不同阶段需要有不同的模块，单元测试，这样进度才是可控的。但测试目标一定要跟研发沟通，按照他们的正常研发流程配合进行，切忌为了测试导致打乱研发节奏，这就得不偿失了。
- 测试用例包括正常流程测试，限制性测试，反流程测试，性能压力测试，安全性测试。
- 测试反馈不要一股脑的罗列，要做好分类，严重性和紧急度的标记。
- 跟进测试反馈，建议有一套测试反馈的系统。
- 测试反馈是基于问题的，但反馈后，可以继续和人沟通，有些解决方案，可以听听研发的想法。还是那句话，目标一致性最重要，如果研发和你目标一致，解决问题的方法并非一成不变。
需求边界#
什么是需求边界？我们定义一个功能，定义一个数据逻辑，但我们要知道，技术有研发成本，同一个功能，一个数据逻辑，如果我们知道用户诉求的边界在哪里，可能就会减少很多无用功，提升研发效率。
数据量边界#
说个自己的例子：
CNZZ 的第一个版本，是我独立开发的，当然后来一些交互页面阿飞有调整的。现在的版本已经没有我的代码了，这个例子我以前公号文章也提过，当时我做这个产品的时候，其实我即是产品，又是研发，所以没有什么沟通成本，这个东西代码量不大，后来很多技术高手看到代码都很鄙夷，觉得技术含量不高，而且问题也蛮多，他们说的也对。
但这个产品，我讲一点，我的研发周期，也就两周，而且不是说从早到晚每天都在写程序，每天可能也就写不到两个小时，真的，两周，业余时间写的，平均每天不到两个小时编码。 发布出来没多久，成为市场第一。
为什么能这么短时间写一个完整的统计系统，不是因为我编码能力强，而是因为我懂得取巧。
这个产品策略问题回头可以慢慢解释，和今天课题无关
产品策略是一个取舍的过程。
这个取巧，就是需求边界，后来我看到有些研发团队做同样的事情，花了很多的时间和精力，其实大部分浪费在做无用功。
有个例子我经常提的，百度，淘宝，google，搜索结果都是不会超过100页的，很少人意识到这一点，为什么？大翻页是个典型的技术问题，不管用商业数据库，还是自己的索引结构，大翻页的效率损失都是很可怕的。
以前很多论坛社区，大家都知道，用户是很少翻几百页的，但搜索引擎的蜘蛛会翻，以前很多论坛社区，因为网页内容很多，白天用户多的时候屁事没有，半夜崩溃了，不知道原因，仔细一查，半夜蜘蛛来爬，把数据库爬死了，为什么蜘蛛会爬死数据库？因为蜘蛛一直在翻页。
回头来说，这里的关键是什么，不论你用百度，用google，用淘宝，你会翻超过100页么？这就是需求边界。如果你把这部分需求屏蔽掉，技术问题就解决了，那你说，我搜不到怎么办，换关键词会不会，换搜索条件会不会，你真的会翻100+页么？
cnzz 里我做的时候，也有类似的策略，比如说，我们说一个网站有 top refer， top page，最多的来路，最多的访问页面，有个做统计的团队，说大网站的这个数据量很大，怎么存？ 我说，我问你一点，你去问站长，去查看这个数据的时候，会翻多少页？长尾页面的访问量会统计在汇总里，但不需要每个长尾页面都统计到，这就是需求边界。而他们技术，花大量时间试图解决这个数据规模的问题，就是无用功。
以前还有一个朋友，做 app 市场数据排名跟踪，跟我说存储量太大，我说你存的什么东西，存每天，每个 app 的排名变化，我就说一点，我说作为 app 的管理者也好，作为竞品分析也好，这个 app 今天第五名，明天第三名，这个变动是有意义的，对吧。这个app今天105名，明天 103 名，这个变动有意义么？
什么意思呢？如果排名低于多少名，并且变动少于一个比例，这个数据不用记录，展现的时候就取前一天的数据，一条直线，这个变动没意义。什么时候变动超过这个比例了，再记录，结果，数据存储规模一下子减少了 2/3 还不止，那每天的系统处理效率也提高了。
精确度的边界#
当然，我们希望说数据是完全精准，完全精确的，但有时候，你容忍度宽一点，系统设计的复杂度就低很多。
cnzz 当时是国内第一个号称实时统计的平台，实时统计其实是很有意义的，很多其他统计平台当时要不没意识，要不觉得实现成本太高，其实我也是取巧，是每分钟刷新数据的，并不是完全实时，你刷新页面还需要几秒钟呢，看数据最快还要半分钟呢，我给你提供一分钟的处理间隔，基本可以满足用户对实时数据的这个需求了。全实时有必要么？
数据覆盖率边界#
我们都希望数据一条都不要丢，但实际上，cnzz 这种嵌入式代码，本身在网络环境里，自然就会有百分之几的数据损失，这个是所有统计系统无法避免的，包括 google analytics 在内，谁也躲不开，这时候你说你百分百不丢数据，你根本体现不出你的优势来。
cnzz 我做的那个版本，在每分钟做数据处理的时候，有一个日志切割的过程，这个过程，其实是有可能丢失一点点数据的，但比例很低，有没有千分之一不好说，但这个对这种第三方统计系统来说，其实真的没关系，自然损失的比例远高于这个比例。这也是一个需求边界的问题。如果硬要解决这个问题，技术成本可能要提高非常多倍。