大家好，我是人间三月半，一个求生欲很强的产品经理。
2019年，我从校园走入职场，从用户增长运营转为了一名产品经理，从职场新人到参与第一次绩效考核，这一年发生了太多的改变，甚至改变了我个人中短期的职业规划，因此2019年对我自己而言，是非常重要且不平凡的一年。
我曾和我爸妈解释过我的工作:类似在工地上画图纸的，只不过我们不是盖房子，我们是做软件；我爸妈似懂非懂，但是回了一句我觉得很懂的话:那你们这个好弄啊，现在好多小工程，都不用画图纸的了，都有现成的。
"都有现成的"，我爸没说出口的下一句，应该是"你们照着抄就行了"。照着抄，不会出错，能让甲方满意，能让施工工人们理解，能让最终的交付成果符合预期，这就差强人意了~这让我想到大学的时候参加商业创新类比赛，比赛周期3个月，可能大家可能会花2个半月来讨论"创新"，那时候听到的最多的就是"不行，这个和xxx有什么区别"，"这个别想了，xxx已经做了"...最终讨论出来一套，听着很创新，实则拼凑了几个产品到一起的四不像，用半个月草草的写一份万字BRD交到组委会...这样草率且四不像的作品，最终的结果不会很好，最终取得好名次的项目，要么选题非常创新，以至于大家可以忽视了它计划书中的不足；要么项目已经落到实处，执行的卓有成效；
齐白石说，学我者生，似我者死。做为一个产品新人，2019年，遇到了几位超级棒的导师，几位乐于share的同事，也一直尝试在向他们学习，积累一些简单的总结，写在这里，与大家分享，请大家指正。
个人方法论1:为与不为
保留天马行空的思维方式，但是在工作中脚踏实地。刚开始接触一个新项目的时候，脑子里一堆pi想法:用户等级勋章，去中心化的内容分发，做弹幕流推荐，雷达找剧，看剧小黑屋...Yesil和Le.Yo两位哥，听了后给的反馈出奇一致:想法都挺好，但是目前没必要，这些想法的出发点是什么，拉新？留存？活跃？转化？体验？口碑？现阶段产品的主要重心是什么，那么上述的出发点是否可以通过别的方式进行满足？Fine，3个月过去了，我的那些pi想法依然还在，只是他们在我脑子里的优先级下降了，我当下有更重要的功能/目的需要满足，当然如果后面有可能，我也愿意和大家再一起脑暴这些idea。
个人方法论2:五思而后行
考虑一个需求时，思考为什么要做，不做会怎么样，没做的时候替代方案是怎样，是否一定要现在做，需要投入多大的精力做？即思考:需求目的，需求内容，需求影响，需求紧急程度，需求重要性。常说产品经理需要将企业利益与用户利益统一，面对用户诉求时，面对企业诉求时，更需要冷静的分析因果关系，做有准备的人，不做被需求推着走的躯壳。
个人方法论3:不学，则无术
各个岗位的能力模型都可以用"道，术，力"三层来概括，对应到产品经理这个岗位，产品大局观，产品感，是为道，对一个行业、一种模式、一个产品的认知，对于商业产品敏锐的嗅觉，我最喜欢听产品大佬们说一些自己的看法，不仅仅是交互体验上，不仅仅是功能层面上的，更多的是他们对于某些行业的深入了解及大量的实践经验后得出的真知灼见，往往三两句，道出迷惘，希望以后有更多这样的机会可以学习，交流，让自己的产品感更敏锐；而第三层"力"，我理解就是执行力，和付出的精力多少，这个每个人的情况不同。主要想说说工作方法，是为产品经理的术，不同细分领域的产品经理需要不同的业务能力，这里总结几个不同类型的产品经理都需要注重培养的工作方法，以时刻激励自己:①工作流程标准化（业务沟通-需求分析-市场调研/竞品分析-需求list-流程图-原型-需求评审-PRD），可能在实际工作过程中，流程会删减或重复，但是在脑子里需要一直有这样的流程图，时刻提醒自己；②了解一定的技术基础，前端，后台，数据，都和产品的工作密不可分，这一年在这方面最大的收获是看完了一本《给产品经理讲技术》，最大的遗憾也是于此，停留在了解名词和简单沟通的基础上，希望2020年，自己能够学习的更深入一点，也更有利于了解，自己的产品如何在开发哥哥的手中更好的实现。③善于总结，勤于分析，学会表达。如何把自己能够收集到的信息，总结的信息，发现的方法，提取有价值的部分，以合适的展现形式，无论是文字，表格，还是图片，最终输出成成果，2020年我已经在逐渐培养这样的习惯了，希望自己能够坚持这样的习惯，尝试输出一些有价值的东西。
个人方法论4:检查好了再"交卷"
保存之前，学会Review。自己的标准程序每一步结束后，review一下！无论是需求分析还是原型，PRD，越早考虑清楚越节省效率，否则等到PRD交付开发、测试后，再去弥补、修改的成本都是非常大的，最后影响整个项目组的进度，这就真是产品经理背锅了。以下是我基于网上的一个版本，结合我在工作中遇到的真真切切的疏忽，在交付一份原型，一份文档前，必须要review的点:增、删、改，查，显、算、传，异:
增:这份文档，这个版本，增加了哪些功能，增加了哪些页面，这些增加的原因和出发点是否合理，会影响哪些用户的哪些方面，是否满足了需求沟通时定下的需求内容，是否描述清楚了。
删:和增反着来，这个版本干掉了什么页面，什么功能，什么按钮，什么文案，牵涉到的端、接口的影响范围有多大，删，比增更需要慎重。
改:版本更改的地方都有哪些？页面、文案的修改功能、权限的修改逻辑、规则的修改，这些改动内容都合理么？
查:根据产品设定的用户使用场景一步一步拆解，检查流程是否存在问题？查页面布局是否合理（ios 安卓 web），是否符合用户操作习惯？
显:初始状态下如何显示（预加载）？正常情况下，如何显示？加载过程中怎么显示？加载失败怎么显示？不同屏幕尺寸如何显示？不同系统类型/机型/浏览器类型是否考虑充分？
算:你设定的规则怎么算？算法是否执行的通？放在前端算还是后端算？
传:从接口拿还是前端写死？用户的哪些数据存到服务器哪些写到本地？接口同步后台同学了没？哪些前端写死，为什么？数据埋点同步数据同事了没？我经常在这个环节出问题，一开始没有考虑到后面的可拓展性，往往后面花大把时间来fix
异:我做产品经理负责的第一个模块是一个普通的短信验证码登录，jc把工作分给我，我20分钟连交互到文档发给他了，然后被上了产品第一课。登录成功并不复杂，但是异常情况却又非常多种。哪些字段类型、用户操作是合法？缺省值怎么办？非法值怎么办？网络错误怎么办？接口异常怎么办？被杀死怎么办？哪些异常能避免，异常出现了如何解决...你永远不知道你的用户是怎么操作你的产品的，多思考一点，总不会出错。
可能做这样的review会耗费一些时间，但是对于我这样的小白产品来说，从一开始养成这样的习惯，后面熟练起来，在一开始考虑的时候，就能够想的明白，自然而然的可以省下很多的麻烦。要从测试、开发小哥哥小姐姐看你文档的角度考虑，把更多的时间放在思考上，而不是一份文档敲定后，后面不断的被测试、开发、运营挑战。
记得刚来公司的时候，有一次测试用例评审前，我问Lucas，测试用例评审我去干啥啊？Lucas这样和我说:测试是你的产品上线前最后的检查员，你是否完全信任他理解了你的需求文档？测试的一句"ok"，是否能够让你放心？而建立这样的信任的前提，就是确定出一份详尽、完整的测试用例。
个人方法论5:学会沟通
在2019年的后半年中，完整的经历了一个项目的从0到1阶段，作为一个产品新人着实在沟通上从前辈那里学习到了很多，一开始我总是遇到啥需要决策的就问，我问一句，领导回一句，多半是反问，我就再陈述，继续问...可能循环了好多个回合，最后才能阐述清楚一个问题，后来跟着Le.Yo学会了如何与上级沟通:目前遇到的问题是什么，影响范围有哪些，我们给出的建议有哪几个，各自的优劣势是什么，最后，我们建议哪一个。这样发给上级，让上级更能够了解我们的诉求，最终推动解决这个问题，毕竟，领导们天天比较忙嘛~沟通问题上，我的总结主要根据不同的岗位角色，有各自需要侧重点:
对直属领导—向上管理，信息透明化
主动向领导汇报非常非常非常重要，不要自己闷头干活。执行落地这件事不是空喊口号，在实际过程中，一个项目可能会卡在多个流程节点，业务沟通群、需求沟通群等，我建议把直属上级拉进群，让他知道你解决了哪些问题，当前真正卡在哪个环节，着实有利于提高效率
对需求方—同级沟通能力
我发现很多人做需求，当然也包括我自己，和业务的沟通交流只在需求之前，当真正开始产品设计后，沉溺此中无法自拔，把业务忘得一干二净，抛之脑后。等到运营同学主动来问，需求啥时候上线啊，或者上线后，业务说，这功能没法用啊.....还有一种情况就是俺经常遇到的，功能上线了，没有及时同步给大家，大家某天突然惊叹:卧槽这个功能都有了。这真是一件让人尴尬的事情，如果把工作过程中，同步给各方牵涉人员，让大家实时的知悉或者想查询进度的时候，有可查的地方，才能杜绝上面这样的问题。和业务方之间的沟通流程应是：需求前期沟通，深刻理解其诉求；需求文档完成后二次找其确认；需求开发过程中，进度及时同步（按每周或项目节点同步）
对开发哥—需求跟进能力
项目排期不是形式主义，而是驱动开发，驱动一个项目组一起按时完成项目的一个约束条件。如果项目没有正常上线，先审视自己是不是没有做好需求的过程管理。这不仅仅是项目经理的工作，作为一个产品经理，你是否知道开发每天完成了需求的多少进度？距离提测或者上线时间节点，是否有延期风险？若感知到风险，如何解决？风险控制是一个持续性的过程。这些都是产品要做的工作，做好需求开发的过程管理，项目才能如期的上线。
于深圳回合肥过年的路上无聊写的，平安落地，希望2020年，自己能够多做一些，在产品经理的成长之路，继续向优秀的前辈们、同事们学习，把学习-总结-分析-输出的方法论继续践行，继续做一个求生欲极强的产品经理。
附一张一年发一次的图
