最近1件事对我感触比较大，与不下10个产品同学聊天，发现1个现象，产品早期在平常工作中总是觉得不得章法，做起事来，很混乱无序，琐碎的事情占据了本身太多的时间，进而致使项目推动缓慢，工作不出成果。
那末，今天我便结合本身经验和产品同学的反馈来讲说如何深入平常工作。
Situation1：提早制定计划计划表的情势可以有多种：写在本子上、写在excel上、写在逐日清单上……目的是明确自己应当做甚么事情，完成甚么事情，思考甚么事情。这份计划可简略，只有几个字的说明；也可详细，确认各个工作内容和时间结点。仁者见仁智者见智，合适自己工作的为最好。
比如说：我会将每天的工作写在本子上，这个本子作为平常记录，包括：各类需求、实际bug、计划工作、完成情况、总结、创意点子、网上的理论、需要思考内容等等。以1日工作记录为例：
7.24日工作（括号内为实际结果）
（1）bug池整理，新增bug内容（新增11，解决8）
（2）7.1.4复盘总结，结果上报给总监（已上报，待沟通）
（3）制作发包清单——肯定发包无误，给boss确认下（初版）
（4）约请活动，低保真原型设计（ok）
（5）分享报告，底部2维码设计+文案，对接UI和策划（7.26查看）
（6）下班前看看技术进度，搜集问题（√）
特殊bug，XX公司公告数据异常；
思考1下，工作2小时勿扰的功能；
有空去找找国外企业级软件的盈利模式。品牌定位，策略。
有了这份计划，可以将每天的工作清晰的列出来，然后逐一去解决，有益于梳理逻辑，保证工作效力。固然这份计划也不是非常的详细，没有时间的说明，和任务的重要程度。这里仅提供了1个可参考的方法，小火伴可以自行的去创造设计，终究保证平常工作的履行，项目的顺利推动才是最为重要的。
定期的去回顾这些内容，可以迸发出新的创意火花，让自己能够时刻的去接受新的理论，新的知识，推动自己去实现1件非工作上的事情，提升产品思惟。
Situation2：定期总结产品经理的总结，我认为有两类是必须要做的，其1是项目复盘总结（每次项目上线后的总结）；其2是平常工作总结。
项目复盘总结提出这个观点，是我在人人都是产品经理上学到的经验，使用起来确切有效，有益于找出当前团队的不足，软件设计上的缺点，更可以提升团队的参与度，让成员都能明白每一个版本的意义，明确后续开发的重点。对产品经理来讲，这类复盘，可让你更好的掌握团队的实际情况，提升自己在团队中的形象，固然有问题他人指出也要虚心接受，他人的问题也要及时讲清楚，避免再次出现这类问题。
这篇文章《项目复盘思路：产品上线后要如何做复盘？》总结很到位，推荐给大家！
平常工作总结7.24日复盘总结
技术观念总结：
（1）PRD写的文字太多，看起来很乱，建议精简1些，多给效果图和流程图。
（2）每次修改需求，要给出1份明确的变更文档，如果在PRD请用红色备注说明，特别是功能上的不要说改就该。
（3）XXX功能逻辑说明不清楚，致使上线特殊情况下没法判断处理，出现异常。需要补充逻辑说明，紧急修改。
（4）7.1.4版本需求太多了，最后2天拿掉了1个已做了1半的功能，下次要写清楚重要程度，和开发顺序。
产品观念总结：
（1）技术因特殊情况请假，致使版本进度延缓，功能未完全处理，不得已拿掉。时间预留过少，要斟酌特殊情况的时间预留。
（2）版本进度履行效力不足，没法依照预期时间节点完成对应的功能。技术总监要多管理。
（3）变更2次需求，1次逻辑思考不全，1次追加需求为了满足核心用户的需求。
产品经理平常工作很多，各类事件都会遇到，因此定期的总结，可让自己时刻站在主线的位置而不被其他工作带偏了。常常总结，可以提高个人的总结能力和逻辑能力，使自己能在混乱中分清楚主次关系，梳理思路；同时在整理中，能够产生新的创意点子，利于延展思惟。对汇报而言，也是相当有帮助，可以清晰的说出当前版本或是本周团队的工作情况。
Situation3：应对突发事件的准备7月第4周总结
项目工作进度比预期略微慢点，1天左右能解决，下周3能开始测试（晚1天）。周报页面需要加入1个能力图，样式还要调剂（让UI思考思考）。写1个注册流程图，包括第3方注册、手机注册，技术有点蒙，下周1对接。
老板说让斟酌增加上1页、下1页功能，当前没有，与技术沟通1下能不能加。
企业办公，私有云和公有云，能不能作为卖点，斟酌下，搜集资料，和老板沟通1下。
这里的突发事件，不单指项目的突发事件，还有人的突发事件。
举个例子（项目+人的突发事件）：
项目临上线前1天，技术没有开发完成，测试没法通过，某个功能没法正常使用，全部项目组弥漫着压抑的氛围，全部成员都在加班。这时候，在交换进程中，产品和技术产生了不愉快，吵了起来，久长的压抑致使矛盾1触即发，双方心态已爆炸，此时没法再进行开发任务。最后经过调理，双方又坐回坐位上继续闷声工作，终究项目延期，上线出现过剩bug，各方反馈均不良。
实际情况很简单，功能只是需要调通就能够，但由于项目压力过大，超过了人心里承受范围以外，人变得更敏感和脆弱，写出来的东西也不尽如意。从本质上分析，老板要求产品到达的目标没有完成，产品又将压力又转移到技术上，虽然都是都是为了完成工作，但终究缺产生了不同结果。如果是你会怎样办。
这件事的产生，让我第1次了解人的情绪上的突发事件，为了实现功能而去实现，完全疏忽全部实现进程是万万不可取的，每一个人都有心情很down、压力很大的时候，特别是当这类情绪，连带入工作当中，更是催生了更多的矛盾。虽然互联网1直强调结果导向，但是没有进程哪来结果，长时间的压抑，只会让潜伏的矛盾加深。
所以说，对产品经理来讲，心态真是太重要了，1个强大的内心，是产品经理承受压力的根本，如果自己先爆炸，那末其他人也不会好起来。
学会提早沟通总是在讲沟通，已被说烂了。这里强调“提早”2字，甚么事提早说出来比事后说出来有效果很多。比方说，我想要XX功能，希望你提早做1下，如果有问题，你可以随时来找我，特别是逻辑和技术实现的问题，时间最好在今天和明天，你看咋样？这时候，技术1般会同意，有问题也会及时反馈；如果不同意，那末可以找到问题所在，然后再去解决。
提早说明开发进度周期，提早说明开发工作，提早说明变更内容，提早调和资源，提早写好各类文档，这样不会让事情到了最后，处于1个没法挽回的地步，你做的每步，都让事情提早有1个缓冲的地带，这样方便任务的履行。
学会自我批评和接受批评党支部有个会议，叫做“民主生活会”，旨在发扬民主，展开积极的思想斗争，总结经验教训，以以诚相见、与人为善的态度展开批评，到达统1思想，增强团结，相互监督，共同提高的目的。
自我批评有时都觉得自己做的工作很多，时间久了，便会开始有抱怨的情绪，我做了这么多，还不够么！我都写的够完善了，还要怎样！工作都堆积这么多，还要再给我加活。
但仔细想一想，为何做的功能没有被理解？为何写了很多，缺不被接受？为何我的方案再1次被否决？为何计划没有履行下去？自己到底有甚么样的问题。
这时候，下班后我会多待1个小时左右，仔细想一想本日工作的得失情况，通过本身的认知，来修整自己的方法和理论。时刻提示自己，工作永久都是干不完的，如果拼命去追逐工作的完成，只会产生过剩的工作，而且必须要对自己的范围有1个明确的界限，知道自己能够需要做甚么，能够做甚么，能够做到甚么程度，从第3方的角度来看待自己，了解自己是属于甚么类型（比如项目管理型、功能型、商业型、数据型），然后逐渐的制定工作，展开工作，总结工作。所以，产品经理通过自我批评进行深层次的认知，在有限时间内去做正确、重要的事（沟通调和、汇报、深入思考，解决重要问题），逐渐排除琐碎、零散的事。
接受批评工作前3个月，我的认知1直停留在老板和总监的意见上，他们在工作中给我提出了多有用的建议，我也会朝着这个方向去改去做，后来发现，单单这样不利于解决基层的工作，由于认知的方向不同，其思考方向有偏差；斟酌的实际情况不同，其结果就会有偏差。所以，通过每次的复盘总结，凝听各个部门对产品和对我的评价，了解哪些是做的不到位的地方，接受批评（虽然说每次都很难受，有1次竟然被说产品就是垃圾，根本不会有效果，我的心呐…），可以明确的了解到各个部门的实际情况，有益于解决当前所面临的各类问题。通过他人的批评，更能认知到自己的不足，虽然不1定都对，但也提供了1个解决问题的思路，下次在面临这些情况的时候，能够成心识的以适合的方式来解决，这样双方都舒服。
学会提早制定制度临阵磨枪效果总是差能人意。俗语说的好，无规矩不成方圆，这个规矩就是应对各类突发事件的解决标准，有了规矩，到了关键的时候才不会手忙脚乱。
在1次版本上线的进程中，发到各个平台的软件包，下载后出现了严重的闪退现象，结果用户反馈负面反馈极具增多，用户大量流失。
我在想，为何多环节的卡控还是出现了这类情况！我们1有技术把关、2有测试把关、3有产品把关、4有项目发布人把关、5有上线前所有人下载最新版本的操作，怎样还是致使了这样的现象。
事后，发现了问题所在：
- 第1，测试已提早测通过了，下班正常回家；
- 第2，由于1些需求小变动，技术需要通宵改代码，管理层、产品和当事人没有仔细去测，在测试未将最新功能测试通过的情况下，就把问题包发给了项目发布人，并反馈无误；
- 第3，发布人确认，并在第2天上午将软件包发到群里，在领导唆使下，提早将包发布上线；
- 第4，由于当天通宵，多数人没在，没人及时下载，并未留意和反馈这个问题；
- 第5，当发布成功后，产品下载最新版本，看到了问题所在，但为时已晚。
经过这次事件惨重的教训，让我深入的明白了制度的重要性，那些约定成俗的规矩，在关键的时候总是会出漏子，实际明文规定的制度，才能在平常工作中，最大限度的避免非正常情况的出现，让各个岗位明确责任意识，从而保证项目的推动，和版本的更新。
为此，我制定了1份“版本上线前确认清单”
清单虽然简单，单确保了产品上线前的最后1步，从实际效果来说至那以后，版本发布再没出现严重的bug问题，各岗位均能依照方法履行下去。
最后的1些建议产品新人在早期，最容易堕入1个误区，不懂就要及时的去问，而实际是要将问题精炼，捉住重点，深入分析。最好是买个本子，将遇到每个问题都要马上记录下来，每天在下班前好好思考1下有价值的问题，然后去查找1些资料辅以左证，写出几行结论或方案，最后在下班前或是工作前半小时内与相干的负责人交换讨论，如果没法解决，可以在会议上将问题抛出来讨论。
产品经理的成长，都是在平常中点滴做起的，不管你的师傅都牛逼，有多会带人成长，可以明确的说白给的终究不会去珍惜，自己努力去获得的，才是你未来立身的根本。快速通过老板、总监、师傅等，来提高自己的眼界，找到核心方法，提升项目经验，才是本身核心竞争力的基础。工作中他人所给予给你的，终究还是要通过本身的消化才能被自己吸收。
1个真正优秀的产品经理，不是做好了1个项目他人称赞，而是在他人都说不行的时候，能站出来讲我可以试试，以这类独立解决问题的心态去做事，总会是进步很快。即便遇到自己没法解决的困难，也能够有同牛人交换的共同话语。产品经理不要惧怕跳坑里，而是要有爬出坑的勇气，面对逆境的坚毅，再1次次的失败中，不断修正自己的理论和方法，对下1次的失败有充足的准备，万1没有失败呢？你就成功地跳出了坑。
写这篇文章的意义在于希望每个产品经理都能独立思考平常中的工作，脱离出本身思惟的窘境，逼迫自己去成长，去担当，为了团队负责，为了产品负责，成为团队中的核心人物，成为那个能带领全部团队的人。
作者：zouguokana
来源：人人都是产品经理
