对于一个刚毕业的产品新人来说，一上手就哐哐被安排了两个大项目，而且还没有人带，导致我踩了无数的坑。当然我要感谢我总监心这么大，就这么放心的让我去干了……毕竟有些坑是非踩不可的，早踩早吸取经验，也算是一种成长吧。做产品呀，最重要心态要好~
那么我就以一个踩过无数坑的小白的粗浅认识，来总结一下我2018年做产品的心得吧。希望日后再回顾这篇文章时，可以欣慰不曾再犯同样的错误。（为区分“产品经理”这个职务和“互联网产品”这个东西，以下简称产品经理为PM，互联网产品为APP）
PM是一个什么样的角色？个人觉得，PM，就是千万用户的发声者。PM肯定是最了解用户的人，并且可以站在用户的角度来审视自己做的APP到底是好是坏，然后自信的提出“这里不行，要改”。当别人提出质疑时，可以很自信地反驳“我看了10万条用户反馈；拉了500人的用户群，每天以普通用户的身份和他们聊天；我发了100个社区动态，每一篇都可以获得用户100赞以上。没有人比我更懂用户！”这就是我总监在做管理者之前的日常，这样的自信，谁还能反驳呢。如果要让别人心服口服，就必须做到别人无法超越。
PM一定是高要求的人，不能放弃对高品质结果的追求，不能太好说话，不能这也行那也行。因为PM后面还有设计、开发，如果第一道关就不严格，后面就会一点点打折，最后出来的效果可能只能达到预期的60%了。
怎么挖掘需求？
1. 多用自家的APP。把自己当成是普通用户，按照自己的需要去用APP，然后在使用过程中感受自己的心理变化：用到什么功能的时候会觉得下次还想用；用到什么功能的时候感觉眉头一紧，搞不懂怎么用，或者和自己预想的操作结果发生了偏差。心理变化是很微妙且一瞬即逝的，所以要刻意练习，练习放大自己的心理感受，这一点我还没做得很好，下次试试用笔或手机记录下来吧。
2. 多用别人家的APP。同样类型的APP，使用下来，一定会有一个最为喜爱的，至于为什么宠儿是这一个，就非常值得研究了。比如你拍了一张好看的照片想要分享给大家看，微信朋友圈、QQ空间、ins、微博……你第一反应是上传到哪里？如果是我，我会首先上传朋友圈，为什么——因为朋友圈有很多我的朋友，他们会给我点赞，受到赞我会很开心。这么一想，微信就很值得研究了呀，它是如何做到现在的用户规模的？它的使用体验是怎么做的？它的每一次版本更新为什么要这么做？……
作为PM新人，可能很多时候都是接到一个需求就着手开始做了，这个时候，个人觉得，比起临时抱佛脚的竞品分析，平时使用APP的积累更加重要。当你对一个功能束手无策的时候，如果脑海里立马就可以蹦出“我记得某某APP有这样的逻辑，我学一下”那就是很高效的一种办法了。能做到这样，就必须要多用各种各样的APP，大致理解它们的逻辑。
不要报以鄙视的心态去看任何一个能安装到你手机上的APP，也许它界面真的很丑，也许它体验真的很渣，但是它一定有它存在的合理性。不能轻易去否定一个team的成果，几个人几十个人的头脑，加起来总不会蠢到哪里去吧。至于他们会什么这么做，也许是资源限制，也许是市场需要，这就需要深入研究了。
3. 多接触用户。了解自己的用户，才能更好地了解他们需要什么样的产品，他们的需求到底是啥。多看用户反馈，能够来反馈的人，一定是真的喜欢这个APP，希望它做得更好，所以他们的意见很有参考价值。多看用户评论，社区类的、短视频类的产品，有很多用户之间的互动，比如我没事的时候就喜欢刷抖音，而且每条必看评论，评论里会发现很多有意思的人，有的时候看一些评论，你会觉得“卧槽，居然有人会这么想？”没办法，这就是用户呀，有着各种奇妙的想法和心里感受。
了解别人家是怎么做的，为什么这样做；了解自家的用户需要什么样的功能，这样，才能挖掘出真正的好的需求。
怎么写需求？
1. 确定需求列表。拿到一个项目课题的时候，先挖掘需求，然后整合这些需求，按照APP的框架用脑图把需求列表先画出来，然后做取舍，哪些要做，哪些不做，哪些下一个版本做。需求列表中只需要写明“做什么”，不需要写“怎么做”，比如：天猫精灵APP项目→设置→音量设置-手机调节天猫精灵音量。列出自己的需求列表之后，一定要及时和老大沟通，反复讨论，反复确认。首先要确保在“项目大体逻辑”这个大方向上自己的想法和老大的想法保持在统一战线。否则如果按照自己的想法往下做，错了就是完全自己背锅，如果是老大的决定，那至少大家都不会怪一个新人。
2. 画高保真原型图。确定做什么之后，就是怎么做了，我学到的习惯，是先画出原型图，再写相关的逻辑，原型图画出来，界面上需要什么元素有了，写逻辑的时候就基本不会漏掉某些功能。如果没有头绪，不知道怎么画图，最基本的办法，看看市面上类似的产品，把图copy下来。年少轻狂的时候，我对于copy这件事也是嗤之以鼻，总觉得那是一种很low的手段。但是认清现实之后就发现，“抄”也是一门艺术。创新固然是牛逼的，但是如果我自己做的创新就是不如市面上有的，那我为什么不吸取他们好的地方呢？“抄”来的界面只是最表层的东西，具体的逻辑、这句文案怎么写、这条分割线怎么放、这个按钮什么样式，这些全都是我自己研究出来的东西呀。
做PM不能没有UI的感觉，如果只会写逻辑，那跟UI设计师沟通的时候就会非常吃力，你看到一个UI界面，你感觉不对，但就是说不出哪里不对，是不是很难受？如果你可以一眼看出这个字号不对，这个配色不是我们APP有的配色，这个行高有问题，那么就会在UI设计时占有主动权，也可以push设计做得更好。怎么训练自己对UI的感觉呢？copy+思考，这里指的是平时有空的时候，临摹各家做得好的APP界面，像素级copy，边画边思考，为什么这么布局，图片尺寸为什么是这样，字间距、行高为什么是这样，字号、配色为什么是这样的。这样做的效果也许不会在平时工作中立竿见影，但是潜移默化的会让自己有一点UI的分寸吧。拒绝做设计师口中的傻逼PM。
3. 画交互逻辑图。简单来说，就是页面之间的跳转，页面元素的点击之类的，需要整体列出来，一个一个界面排好，用箭头指示这一步跳转到下面那一步，之类的。这一个步骤，在大项目中非常重要，如果不梳理整体的逻辑，而是直接开始写每个界面的逻辑，就会纠结在细枝末节上，而对整体失去把握。画出一份这样的逻辑图之后，跟老大、业务方、开发沟通的时候，就会轻松很多，可以让他们先在脑海里对这个项目形成一个大致的概念，这样他们也不至于看着你的需求懵逼，不知道这是个什么鬼东西。
4. 地毯式写需求。如上述，已经画出了原型图，那么就可以开心的写逻辑了。对照页面上的元素，从头到尾，一个一个来。五字秘诀“增删改跳空”——交互（点击、跳转……）、显示（最大字数、图片尺寸、配色及蒙层……）、规则（出现、消失、位置、变更……）、特殊情况（网络问题、为空情况、错误问题……）。
怎么沟通？
1. 换位思考。PM最常沟通的人应该算是程序员吧，程序员每天都跟代码打交道，他们对于一个需求的理解方式一定和PM是不同的，但是恰好PM写的需求是给他们看的，所以必须要让他们看得懂。这就需要换位思考，既然我的思考方式他们不理解，那么就试试他们的方式来思考。
2. 确保理解。因为大家对需求理解不一致的缘故，最后做出来的东西根本不是我最初想要的，然后要不就是我妥协，要不就是改代码，反正搞得大家都不会很愉快。这是我曾经踩过的坑，如果我可以确认大家都对需求有统一的认知，那就可以避免这个问题。上面有提到，画整体的逻辑图，就是帮助其他同事理解我的需求的方式之一，首先让他们对项目有一个整体的概念，要让他们先知道我要做的是一个什么东西，我为什么要做这个东西，他们理解需求来源和整体之后，就不会跑太偏了。
我遇到过很坑的，可能也是比较常见的沟通失误，就是讲完需求，跟开发确认是不是都理解了，然后开发大大们很愉快的说理解了呀。但是做的过程中再确认，就发现，嗯？？？怎么和我说的不一样啊，理解偏差了啊……避免这个问题，大概就只能反复和开发沟通吧，就是多讲几遍，给他们灌输，讲一遍，问一遍“我表达清楚了么？”然后最好让他们复述一遍看是否有偏差，这样反复确认。麻烦也没办法，总比代码写完了再来改要好，一定要先确保需求没问题再开始写代码。
3. 不要放弃对结果的高要求。如果你想做一个100分的好结果，你把项目交给设计、开发之后，他们出来的结果打个折，可能就只剩下80分、60分了……PM是一个把控全局的角色，首先要坚定自己对结果的高要求，不能自己这里就先给了一个80分，那后面分数就只会越来越低。举个例子，如果一个设计稿出来，不去挑毛病、不去优化，直接就去开发了，开发过程中还有样式的偏差，那最后做出来的页面根本就不能看了。但如果在设计阶段可以有更高的要求，逼一把设计师，出多几稿，对比得出最好的，那后面就会稳妥很多。任何时候，都要想着“我要做到100分，做到最好”，那如果客观原因做不到100分，最后出来的结果也不会差太多。
4. 需求变更咋整呢？就可能心态要好吧，拥抱变化，以不变应万变吧。需求变更是不可能避免的，因为业务方总会有新想法，老大总觉得做得不够好。变更一定要及时，第一时间先通知开发暂停相关需求开发，将大致逻辑告诉他们。然后再尽快整理文档同步。这样做可以节省下开发不必要功能的时间，时间就是金钱，能省一点是一点。因为过多的需求变更，引起开发小情绪的时候，等他们冷静一下后再把需求要这么做的理由跟他们讲清楚，理由一定得有理有据且逻辑清楚，加上业务方面和公司利益方面的考虑效果更佳。开发们也是讲道理的，而且相当敬业，所以不会打死PM的。
以上，大概就是2018年我做PM踩过了一堆坑之后的个人经验吧。都说PM要望天，但是我个人觉得自己现在基础技能掌握的还不够，所以总结的都比较浅显易懂，比较适合日常工作。期待一下我2019年的成长，是不是可以有更多望天的体会？到时候再来总结吧。