前言
刚入行时，我曾经在一个小公司做产品助理。公司2个产品助理，5个开发，直接领导就是老板。一心想要做个靠谱的产品经理的我，工作非常努力，一丝不苟。
每次需求评审时，开发一般都反馈方案没什么问题。但到了开发阶段，开发时不时就会把我叫过去，跟我确认细节问题。一两次还好，可次数多了，开发难免会不耐烦。尤其是为了按期上线，开发不得不加班干活的时候。
带着愧疚和自责，我在很多群里，请教了很多人。大家似乎也给不出太多的操作性强的意见，只是告诉我“跟你的经验有关”、“经验多了，自然就想的全了”、“多被开发怼几次，你就习惯了”。
那个时候，困扰我的问题是：
- 为什么我的方案漏掉了这么多的细节？
- 为什么有些需求细节我就是想不到？
- 为什么有的人对需求细节非常敏感？
后来，在某位大神的指导下，我用系统性的方法，彻底地解决了这个问题。如今，我的产品方案在开发的过程中，几乎不需要我花时间去澄清需求细节。在参加其他同事的产品方案评审时，总能很快发现方案的漏洞，帮助部门同事输出质量更高的产品方案。
什么是对需求细节的敏感度？
什么是需求细节
在一个没有专职交互设计师的产研团队中，产品经理做的详细方案，一般都要深入到每一个功能、每一个功能点、每一个交互：
- 默认状态下，显示什么元素？各个元素之间是什么关系？各元素如何布局？
- 输入了非法内容时，怎么处理？什么时候检查内容的合法性？检查规则是什么？
- 有什么隐藏的功能？什么时候触发？触发后如何处理？
- ······
这每一个问题，都可能涉及到一个或多个功能点。
对一个功能进行详细描述的功能点，就是需求细节。
[图片上传失败...(image-7b8be5-1609301099136)]
例如，在一个手机号码输入框中，存在以下需求细节：
- 当输入的数字达到11位时，就不允许再继续输入；
- 输入框只允许输入数字；
- 输入框默认提示文案；
- 输入框输入任意数字时，右侧出现删除icon，点击清空输入框；
- 输入框获取焦点时，调用输入法数字键盘；
- ······
对需求细节不敏感的表现
一个功能，是由很多个功能点组成的。但如果我们对需求细节不敏感，到底有多少个功能点，我们很可能完全没概念。做出来的产品方案经常遗漏功能点，甚至不知道，原来这个功能还有这么多的细节。因此，在做方案时，只能想到哪些就写哪些。
那如何判断我们对需求细节是否敏感呢？
1.产品方案详细描述部分往往非常简单，没多少内容
正常情况下，一份完整的产品方案，对细节的描述是非常详细和完整的。每个页面、每个模块、每个功能有哪些功能点，都会详细说明。
而如果我们对需求细节不敏感，由于不知道有哪些功能点，详细描述部分往往非常简单。只是大致描述了一下流程，并对每个元素做简单的说明。
2.害怕需求评审，经常被质疑
即使我们对需求细节不敏感，大部分时候，我们也是知道自己的方案存在漏洞的。但又因为能力和经验不足，无法发现方案中的漏洞。
产品方案偶尔出点小问题，是一个再正常不过的事情。如果频繁出现很多漏洞，会让整个团队对我们失去信心，“被迫养成”事事深究细节、时时质疑合理性的习惯。
因为方案不够完整，导致害怕开需求评审会议、害怕被提问。
另一方面，因为方案不够完整，开发习惯性地质疑，导致我们对需求评审更恐惧。最后进入一个恶性循环。
3.日常工作大量的时间都在向开发澄清需求
开发在遇到需求不明确或需求细节遗漏的时候，往往会有3种做法：
- 根据自己的理解和经验，自行补充需求细节，完成开发；
- 直接无视，忽略掉；
- 找我们确定后，再开发。
如果是第一种做法，除非开发长期跟我们合作，很有默契。否则，大概率他做出来的东西，跟我们期望中的不一样。等到项目验收或上线后被发现，最后承担责任的也大概率是我们，因为是产品方案有问题。
如果是第二种做法，大概率会报错。结果跟第一种差不多。
最理想的情况是第三种，开发主动找我们确定，再继续开发。但即便是最理想的情况，也会大幅度占用开发和我们正常的工作时间，造成严重的团队工作效率低下。
对开发来说，原本应该用来专注于写代码的时间，被迫用于思考需求细节的漏洞、找产品确认问题、催促产品补充方案。最后自然会导致开发效率下降。
而对于我们来说，原本应该用来做其他事情的时间，被迫用于澄清需求细节、补充产品方案、与开发讨价还价、到处认错道歉。工作效率之低下，可想而知。
为什么对需求细节不敏感
对一个东西不敏感，大部分时候都是因为没有相关经验或没了解过。
人类的一些基础能力，是被刻入基因世代遗传的。比如，婴儿不舒服的时候，就会哭。但大部分的能力，是后天习得的。
一个没有见过别人开车、没有学过开车的人，是不可能赢过赛车手的。他只需要报个驾校，大概率上，他很快拿到驾照，成为一名合格的司机。
但此时的他，仅仅是一名司机。离赢过赛车手还很远。
要想成为高手，就必须要加上大量的、重复的训练。要想对需求细节敏感，就要有丰富的项目经验。
然而，现实是很残酷的。市场不会等到我们有很丰富的项目经验时，才要求我们做出一个功能点完整的产品方案，我们能亲手设计的产品也是有限的。
那难道就没有方法快速提升对需求细节的敏感度了吗？答案是有的！
如何提升需求细节敏感度？
高尔基说：“书是人类进步的阶梯。”因为书把人类文明发展过程中的绝大多数经验和知识都记录下来了。
后人只需要通过书学习和研究已有的经验和知识，就可以掌握。通过进一步实践，甚至能在这个基础上，发展和创造出更多的经验和知识。
毛主席在指挥反围剿之前，也没什么军事指挥经验，只是在湖南新军中，做过一年的步兵。但他通过研读各代兵家的典籍，参透了军事指挥的真谛，创造性地指挥各大野战军、摧枯拉朽般消灭了蒋总统的美式军队。
主流产品中对需求细节的处理，就如同书籍中对经验和知识的记录。是我们学习和研究的宝贵资料。
对需求细节的敏感度，是可以通过学习和研究主流产品来获得和提升的。
互联网和移动互联网发展到今天，大部分行业和领域，都已经非常成熟。同类型的产品，数量非常多。
由于研发团队能力和关注重点不一样，不同的产品对需求细节的处理质量参差不齐。但主流产品大多会处理的很好。因此，主流产品非常具有代表性，极具分析价值。
1.选择一个具体的功能模块，或小功能
由于我们要学习和研究的对象是需求细节，那就必须要落实到功能的最小颗粒度。选一个要研究的功能模块、或一个小功能。
例如，要研究点赞功能的需求细节。我们就可以挑选微信朋友圈的点赞功能、今日头条资讯详情页的点赞功能、知乎的点赞功能来研究。
2.拆解功能，逐个体验，一一验证
选定一个功能后，从内容展示、操作流程、交互设计、异常处理等多个维度，将功能拆解到最小颗粒。
拆解微信朋友圈的点赞功能：
- 从内容展示维度：点赞按钮的位置、取消点赞按钮的位置、已点赞好友的信息显示位置、点赞好友信息取值规则、多个点赞好友的排序规则、多个点赞好友如何分隔、数据权限如何控制；
- 从操作流程维度：如何操作一次点赞、如何取消点赞、如何查看点赞好友名片、点赞后如何通知用户；
- 从交互设计维度：点击点赞icon后有什么动效设计、取消点赞后有什么动效设计；
- 从异常处理维度：点赞好友数过多如何显示、点赞时内容已被删除如何处理、点赞时网络异常如何处理等等。
拆解后，逐个体验主流产品处理这些需求细节的方式，即便条件不满足，也要想办法创造条件去满足。
通过细致的体验，我得到以下结果：
- 点赞和取消点赞的按钮都放置在气泡中；
- 在内容发布时间下方显示点赞好友信息；
- 若好友有备注名，则显示备注名；若无备注名，显示昵称；
- 当有多个好友点赞时，按最后一次点赞的时间正序排列；
- 多个点赞好友之间，用逗号分隔；
- 仅当点赞人也是你的好友时，才显示好友信息；
- 点赞时，需先点击右下方的icon，再点击气泡中的【赞】；
- 取消点赞时，同样需先点击右下方的icon，再点击气泡中的【取消】；
- 点击点赞记录中的好友信息，会跳转到好友名片页面；
- 点赞后，通过朋友圈通知功能通知用户；
- 其他好友对这条内容点赞后，通过朋友圈通知功能通知用户；
- 点击【赞】和【取消】icon时，icon会放大；
- 点赞数过多，是否会完全显示，暂无法验证；
- 点赞内容被删除时，会toast提示内容已删除；
- 点赞时，若网络异常，本地显示点赞成功，待网络恢复后再上传到服务器；
- ······
看起来，已经是非常完整了，但对需求细节敏感的你，一定还可以找到更多的需求细节。
3.循环往复，大量分析
学习研究完一个产品，再去研究另一个产品的类似功能。最终，我们就能敏感地知道这个功能所有的需求细节。
通过日复一日的训练，我们逐渐能够举一反三。即使是一个我们没有研究过的功能，也会比大多数人更敏感、做出更完整的方案。
2年前，我在大佬的知道下，仔细研究过几个主流产品的需求细节，并输出了详细的功能分析文章。之后，虽然没有坚持继续输出功能分析系列文章，但研究主流产品的习惯，却一直保留了下来。这给我个人的成长，带来了很多的价值。
总结
产品经理技能的提升，从来都没有什么捷径。正确的方法，的确能事半功倍，但也是建立在足够的“事”上。
一个技能的炉火纯青，从来都不是什么简单的事情。卖油翁说：“无他，但手熟尔！”简单的几个字，背后是多少次练习，我们无从得知，但一定有付出艰辛的努力。
不走捷径，就是最好的捷径。
