产品经理如何深入日常工作

最近一件事对我感触比较大，与不下10个产品同学聊天，发现一个现象，产品初期在日常工作中总是觉得不得章法，做起事来，很混乱无序，琐碎的事情占据了自身太多的时间，进而导致项目推进缓慢，工作不出成果。

那么，今天我便结合自身经验和产品同学的反馈来说说如何深入日常工作。

Situation1：提前制定计划

计划表的形式可以有多种：写在本子上、写在excel上、写在每日清单上……目的是明确自己应该做什么事情，完成什么事情，思考什么事情。这份计划可简略，只有几个字的说明；也可详细，确认各个工作内容和时间结点。仁者见仁智者见智，适合自己工作的为最好。

比如说：我会将每天的工作写在本子上，这个本子作为日常记录，包含：各类需求、实际bug、计划工作、完成情况、总结、创意点子、网上的理论、需要思考内容等等。以一日工作记录为例：

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

（1）bug池整理，新增bug内容（新增11，解决8）

（2）7.1.4复盘总结，结果上报给总监（已上报，待沟通）

（3）制作发包清单——确定发包无误，给boss确认下（初版）

（4）邀请活动，低保真原型设计（ok）

（5）分享报告，底部二维码设计+文案，对接UI和策划（7.26查看）

（6）下班前看看技术进度，收集问题（√）

特殊bug，XX公司公告数据异常；

思考一下，工作2小时勿扰的功能；

有空去找找国外企业级软件的盈利模式。品牌定位，策略。

有了这份计划，可以将每天的工作清晰的列出来，然后逐个去解决，有利于梳理逻辑，保证工作效率。当然这份计划也不是非常的详细，没有时间的说明，以及任务的重要程度。这里仅提供了一个可参考的方法，小伙伴可以自行的去创造设计，最终保证日常工作的执行，项目的顺利推进才是最为重要的。

定期的去回顾这些内容，可以迸发出新的创意火花，让自己能够时刻的去接受新的理论，新的知识，推动自己去实现一件非工作上的事情，提升产品思维。

Situation2：定期总结

产品经理的总结，我认为有两类是必须要做的，其一是项目复盘总结（每次项目上线后的总结）；其二是日常工作总结。

项目复盘总结

提出这个观点，是我在人人都是产品经理上学到的经验，使用起来确实有效，有利于找出当前团队的不足，软件设计上的缺陷，更可以提升团队的参与度，让成员都能明白每个版本的意义，明确后续开发的重点。对于产品经理来说，这类复盘，可以让你更好的掌握团队的实际情况，提升自己在团队中的形象，当然有问题别人指出也要虚心接受，别人的问题也要及时讲清楚，防止再次出现这类问题。

这篇文章《项目复盘思路：产品上线后要如何做复盘？》总结很到位，推荐给大家！

7.24日复盘总结

技术观念总结：

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

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

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

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

产品观念总结：

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

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

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

日常工作总结

产品经理日常工作很多，各类事件都会遇到，因此定期的总结，可以让自己时刻站在主线的位置而不被其他工作带偏了。经常总结，可以提高个人的总结能力和逻辑能力，使自己能在混乱中分清楚主次关系，梳理思路；同时在整理中，能够产生新的创意点子，利于延展思维。对于汇报而言，也是相当有帮助，可以清晰的说出当前版本或是本周团队的工作情况。

7月第4周总结

项目工作进度比预期稍微慢点，一天左右能解决，下周三能开始测试（晚1天）。周报页面需要加入一个能力图，样式还要调整（让UI思考思考）。写一个注册流程图，包含第三方注册、手机注册，技术有点蒙，下周一对接。

老板说让考虑增加上一页、下一页功能，当前没有，与技术沟通一下能不能加。

企业办公，私有云和公有云，能不能作为卖点，考虑下，收集资料，和老板沟通一下。

Situation3：应对突发事件的准备

这里的突发事件，不单指项目的突发事件，还有人的突发事件。

举个例子（项目+人的突发事件）：

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

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

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

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

学会提前沟通

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

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

学会自我批评和接受批评

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

自我批评

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

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

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

接受批评

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

学会提前制定制度

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

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

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

事后，发现了问题所在：

• 第一，测试已经提前测通过了，下班正常回家；
• 第二，由于一些需求小变动，技术需要通宵改代码，管理层、产品以及当事人没有仔细去测，在测试没有将最新功能测试通过的情况下，就把问题包发给了项目发布人，并反馈无误；
• 第三，发布人确认，并在第二天上午将软件包发到群里，在领导指示下，提前将包发布上线；
• 第四，由于当天通宵，多数人没在，没人及时下载，并未留意和反馈这个问题；
• 第五，当发布成功后，产品下载最新版本，看到了问题所在，但为时已晚。

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

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

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

最后的一些建议

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

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

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

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

作者：zouguokana

来源：人人都是产品经理