产品经理如何深入日常工作思维导图

7.24日工作（括号内为实际结果）

7.24日复盘总结

（1）PRD写的文字太多，看起来很乱，建议精简一些，多给效果图和流程图。

（2）每次修改需求，要给出一份明确的变更文档，如果在PRD请用红色备注说明，尤其是功能上的不要说改就该。

（3）XXX功能逻辑说明不清楚，导致上线特殊情况下无法判断处理，出现异常。需要补充逻辑说明，紧急修改。

（4）7.1.4版本需求太多了，最后2天拿掉了一个已经做了一半的功能，下次要写清楚重要程度，以及开发顺序。

（1）技术因特殊情况请假，导致版本进度延缓，功能未完全处理，不得已拿掉。时间预留过少，要考虑特殊情况的时间预留。

（2）版本进度执行效率不足，无法按照预期时间节点完成对应的功能。技术总监要多管理。

（3）变更2次需求，1次逻辑思考不全，1次追加需求为了满足核心用户的需求。

项目临上线前1天，技术没有开发完成，测试无法通过，某个功能无法正常使用，整个项目组弥漫着压抑的氛围，全体成员都在加班。这时，在交流过程中，产品和技术产生了不愉快，吵了起来，长久的压抑导致矛盾一触即发，双方心态已经爆炸，此时无法再进行开发任务。最后经过调节，双方又坐回座位上继续闷声工作，最终项目延期，上线出现多余bug，各方反馈均不良。

实际情况很简单，功能只是需要调通就可以，但由于项目压力过大，超过了人心里承受范围之外，人变得更敏感和脆弱，写出来的东西也不尽如意。从本质上分析，老板要求产品达到的目标没有完成，产品又将压力又转移到技术上，虽然都是都是为了完成工作，但最终缺产生了不同结果。如果是你会怎么办。

这件事的发生，让我第一次了解人的情绪上的突发事件，为了实现功能而去实现，完全忽略整个实现过程是万万不可取的，每个人都有心情很down、压力很大的时候，尤其是当这种情绪，连带入工作当中，更是催生了更多的矛盾。虽然互联网一直强调结果导向，但是没有过程哪来结果，长期的压制，只会让潜在的矛盾加深。

所以说，对于产品经理来说，心态真是太重要了，一个强大的内心，是产品经理承受压力的根本，如果自己先爆炸，那么其他人也不会好起来。

总是在讲沟通，已经被说烂了。这里强调“提前”二字，什么事提前说出来比事后说出来有效果得多。比方说，我想要XX功能，希望你提前做一下，如果有问题，你可以随时来找我，尤其是逻辑和技术实现的问题，时间最好在今天和明天，你看咋样？这时，技术一般会同意，有问题也会及时反馈；如果不同意，那么可以找到问题所在，然后再去解决。

提前说明开发进度周期，提前说明开发工作，提前说明变更内容，提前协调资源，提前写好各类文档，这样不会让事情到了最后，处于一个无法挽回的地步，你做的每一步，都让事情提前有一个缓冲的地带，这样方便任务的执行。

党支部有个会议，叫做“民主生活会”，旨在发扬民主，开展积极的思想斗争，总结经验教训，以以诚相见、与人为善的态度开展批评，达到统一思想，增强团结，互相监督，共同提高的目的。

有时都觉得自己做的工作很多，时间久了，便会开始有抱怨的情绪，我做了这么多，还不够么！我都写的够完善了，还要怎样！工作都堆积这么多，还要再给我加活。

但仔细想想，为什么做的功能没有被理解？为什么写了很多，缺不被接受？为什么我的方案再一次被否决？为什么规划没有执行下去？自己到底有什么样的问题。

这时，下班后我会多待1个小时左右，仔细想想今日工作的得失情况，通过自身的认知，来修整自己的方法和理论。时刻提醒自己，工作永远都是干不完的，如果拼命去追逐工作的完成，只会产生多余的工作，而且必须要对自己的范围有一个明确的界限，知道自己能够需要做什么，能够做什么，能够做到什么程度，从第三方的角度来看待自己，了解自己是属于什么类型（比如项目管理型、功能型、商业型、数据型），然后逐步的制定工作，开展工作，总结工作。所以，产品经理通过自我批评进行深层次的认知，在有限时间内去做正确、重要的事（沟通协调、汇报、深入思考，解决重要问题），逐步排除琐碎、零散的事。

工作前三个月，我的认知一直停留在老板和总监的意见上，他们在工作中给我提出了多有用的建议，我也会朝着这个方向去改去做，后来发现，单单这样无益于解决基层的工作，因为认知的方向不同，其思考方向有偏差；考虑的实际情况不同，其结果就会有偏差。所以，通过每次的复盘总结，聆听各个部门对产品以及对我的评价，了解哪些是做的不到位的地方，接受批评（虽然说每次都很难受，有一次居然被说产品就是垃圾，根本不会有效果，我的心呐…），可以明确的了解到各个部门的实际情况，有利于解决当前所面临的各类问题。通过别人的批评，更能认知到自己的不足，虽然不一定都对，但也提供了一个解决问题的思路，下次在面临这些情况的时候，能够有意识的以合适的方式来解决，这样双方都舒服。

临阵磨枪效果总是差强人意。俗话说的好，无规矩不成方圆，这个规矩就是应对各类突发事件的解决标准，有了规矩，到了关键的时候才不会手忙脚乱。

在一次版本上线的过程中，发到各个平台的软件包，下载后出现了严重的闪退现象，结果用户反馈负面反馈极具增多，用户大量流失。

我在想，为什么多环节的卡控还是出现了这种情况！我们一有技术把关、二有测试把关、三有产品把关、四有项目发布人把关、五有上线前所有人下载最新版本的操作，怎么还是导致了这样的现象。

经过这次事件惨痛的教训，让我深刻的明白了制度的重要性，那些约定成俗的规矩，在关键的时候总是会出漏子，实际明文规定的制度，才能在日常工作中，最大限度的避免非正常情况的出现，让各个岗位明确责任意识，从而保证项目的推进，以及版本的更新。

为此，我制定了一份“版本上线前确认清单”

清单虽然简单，单确保了产品上线前的最后一步，从实际效果来讲至那以后，版本发布再没出现严重的bug问题，各岗位均能按照方法执行下去。

产品新人在初期，最容易陷入一个误区，不懂就要及时的去问，而实际是要将问题精炼，抓住重点，深入分析。最好是买个本子，将遇到每一个问题都要马上记录下来，每天在下班前好好思考一下有价值的问题，然后去查找一些资料辅以佐证，写出几行结论或方案，最后在下班前或是工作前半小时内与相关的负责人交流讨论，如果无法解决，可以在会议上将问题抛出来讨论。

产品经理的成长，都是在日常中点滴做起的，无论你的师傅都牛逼，有多会带人成长，可以明确的说白给的终究不会去珍惜，自己努力去获取的，才是你未来立身的根本。快速通过老板、总监、师傅等，来提高自己的眼界，找到核心方法，提升项目经验，才是自身核心竞争力的基础。工作中别人所给予给你的，最终还是要通过自身的消化才能被自己吸收。

一个真正优秀的产品经理，不是做好了一个项目别人称赞，而是在别人都说不行的时候，能站出来说我可以试试，以这种独立解决问题的心态去做事，总会是进步很快。即使遇到自己无法解决的难题，也可以有同牛人交流的共同话语。产品经理不要害怕跳坑里，而是要有爬出坑的勇气，面对逆境的坚毅，再一次次的失败中，不断修正自己的理论和方法，对下一次的失败有充足的准备，万一没有失败呢？你就成功地跳出了坑。

写这篇文章的意义在于希望每一个产品经理都能独立思考日常中的工作，脱离出自身思维的困境，强迫自己去成长，去担当，为了团队负责，为了产品负责，成为团队中的核心人物，成为那个能带领整个团队的人。