入职两个月，提升效率的5个小方法

影响工作效率的因素有很多，但不同时期的产品人遇到的都不一样。作者作为一个入职两个月的产品新人，总结了自己提升效率的5个小方法，与大家分享。

初入职场的第二个月，主要是从策划5个效率需求中摸索提升工作效率的方法：“把时间花在能用合适的方法做有结果的事儿上！”

应届毕业生初为PM，可能时常会在同一个需求中重复返工多次；可能时常会不知道怎么将上一次任务中学到的方法运用到下一个任务中；可能时常会感觉“好像在完成「老师」布置的作业”；甚至会时常感到沮丧…

但是，让我慢慢磨合和平衡的，正是合适应届生提升工作效率的方法。因此借此文章，记录这个月总结出来的效率方法，时刻提醒自己。

什么是效率

我认为， 效率是把时间花在能用合适的方法做有结果的事儿上 。这里的疑问在于：

1. 怎么花？
2. 什么是有结果的事儿
3. 什么是合适的方法

1. 怎么花

工作时间是需要分配的，个人习惯是完成当日工作+总结当日工作。完成当日工作这一点和「合适的方法」相关，下面阐述。总结当日工作这一点分为组内总结和个人总结。组内总结在我们部门叫做「站会」，目的在于避免重复造轮子的可能性和了解同事的工作内容是否与自己手头上的任务有关系，以便在有疑问时更好的沟通。

个人总结的时间我通常会用在晚饭后，回顾当日任务进度，细致到自己是如何拆分的、是怎么做的、和谁沟通了什么、是否有结果（若无下一步打算怎么做）、哪些是可以明确今日完成的、哪些是明日的工作计划…，每日坚持，便可知道自己每天的计划是否完成，学到什么。

图1：每日工作review

2. 什么是有结果的事儿

可能会有一些应届生和我一样，认为自己做的都是一个个明确的任务，那不就是有结果的事儿嘛。直到有一天，我询问导师一个完全是出于个人好奇的问题，导师反问我：“这个问题对你工作进度是有帮助的吗”，那时我意识到如果要提升工作效率，就需要找正确的人去询问能够推动任务出结果的问题。

补充一点，并不是说目的为「好奇、只是想知道而已」的问题就不要问，是鼓励刚入职场的我们去了解和询问更多的，只是需要明确：要事第一。

3. 什么是合适的方法

这里挺矛盾的。「合适的」本来就是非常个人的，适合我的方法不一定适合你。在此希望对过去一个月学习到的能够切实提升本人工作效率的方法进行总结性记录，以便在遇到效率瓶颈时提醒自己；若刚好读到这里的你也能收获一二，那真是太好嘞。

（1）拆分任务至最小颗粒度

通常接收到一个大任务的时候，会不清楚该如何开始。那是因为将任务作为一个整体看，通常会看不全看不懂。所以需要把任务拆分至最小颗粒度，一步一步去完成。拆分的原则是以每步中我能做到最小的点去列list，通常这种方法可以在每日工作review中得以练习和使用。以近期完成的一个提升效率的需求「在套餐活动配置页新增一键复制功能」作为该方法论的沉淀。

图2：对近期实际需求的颗粒度拆分

以上是对一个业务小功能策划时的最小颗粒度拆分，大体上就是将自己会去如何完成这个需求策划的每一步列下来。其实关于第一步——列出使用方使用该功能的场景，就可再拆分为如下图所示。任务拆分能够让目标更明确，任务项更清晰，更明白自己现在应该做什么、应该思考什么。

图3：个人沉淀如何做「需求分析」

（2）多做一步

一则小故事能够更好地理解为什么及怎么多做一步：「老板让员工去买橘子。A员工直接买了一袋橘子回来；B员工在买橘子的过程中，询问不同类型的橘子特点；价格；味道等，最后将这些信息带回来给了老板，并询问老板买橘子的目的且根据目的提出了自己认为选择哪种橘子的建议」。这个小故事里老板并没有让员工去询问橘子的信息，只是B员工考虑到了老板为什么要买橘子，买来的橘子会产生什么影响。

在进行数据口径统一整理这个效率需求时，其实是一个繁琐但结果能够提升业务方提取数据进行分析和开发读取数据来源的准确度80%以上的任务，因此过程中需要十分仔细和反复确认。当时在开发同事记录实际取数来源时，一并将自己对于该数据口径定义的理解及应该是以哪张报表为基准也记录下来了，后者即这位开发同事「多做一步」的体现。当考虑到这份数据口径统一表最终测试会进行最终的基准表确认，这位开发同事提供了多一种口径定义参考的对象，以便测试做出更准确的决定。

所以至于我而言，这个任务我需要多做一步——整理出数据字典。目的在于分类不同的模块，制定口径和定义修改的模板，便于日后其他同事调取和修改。这也是提升工作效率的方法，提升的虽然不是即时效率，但是从长远来看，提升的是更多同事对数据管理的效率。

（3）一个模块解决一个问题

一个页面由很多个小单元模块组成，搜索框、导航栏、内容列表等。尽量达成模块的单一性，即一个模块只解决一个问题。在分类单元模块时，也是辨别这是一个页面还是一个页面的其中一个模块。例如用户在拼团时支付成功，进入到「拼团详情页」；那么拼团中、拼团成功、拼团失败时，是一个页面还是一个小单元模块？

图4：拼团「订单状态页」的小单元模块组成

梳理过后，其实拼团状态区为该页面中的一个小单元模块。这个模块里根据用户行为又可以拆分成3个小模块，即文案提醒、拼团进度、功能按钮。综上来看，一个模块可以解决用户不同行为下模块内容长什么样子这一个问题，但是实际上已经包含了拼团多个流程。希望在今后的任务中，也能学会通过模块拆分去解决一个一个问题，提高现有组件的可复用性。

（4）问问题的效率

问问题，是找谁问什么问题，目的是得到你想要的结果。

找谁。如果有导师的我（我们），会想着第一时间找导师问。但是反过来想，为什么要问导师呢？是因为这是他负责的业务，或只是因为这是快捷、方便的做法？如果是后者，那其实是在自己的舒适圈里“遨游”而已。突破舒适圈，可以从找对的人问问题开始。

图：找谁问问题

问什么问题。第一是先要克服害怕起争执的心理。因为害怕争执，就会拐着弯儿问问题，问着问着迷失了目的，导致沟通时长增加和效率降低。

第二是问核心问题。如果不知道怎么去询问，那就直接将自己的目的告诉对方。上周做的关于APP展示课时明细查询的需求，需要对现有赠课进行分类、取数、最后展示在APP页面里。为了得到接近家长的用户体验，我直接找了5位班主任沟通。告诉正在做什么需求+我找你要问什么（目的）+将原型给他看/提出AB方案让他选择，最后得到了修改思路和一些新的场景，平均耗时5分钟。但遇到复杂的问题，不知道下一步怎么做时，直接告诉对方目的（我要得到什么），在彼此的沟通中或许就能找到下一步的思路了。

（5）积累做事情的底层方法

每天都会记录很多场景，提出需求意见然后落实；在做不同需求中也会积累很多方法。但是等这个需求上线后，这些方法应该如何运用到下一个需求中，这是应该去总结的–做事情的底层方法。自己在做拼团需求的一个反思就是，我只总结我怎么做拼团的，那以后别人就会认为我只会做拼团；如果我总结在做拼团过程中，怎么进行模块复用、怎么和开发沟通、怎么获取场景、怎么提高需求文档编写能力…，这些做事情的底层方法，是可以大大提高做其他任务的效率。

在做方法复盘时，应该更加具体的描述通过什么努力，得到什么结果，自己进行了什么修改，还有哪些问题可能需要借力；例如：「我通过将做好的APP课时查询明细原型给5位班主任和相关业务负责的同事看，得到了一些反馈结果，分别是1、2、3…；然后我修改了获取课时明细为总课时明细，因为用户对于总课时更能理解是什么意思；最后参考了花瓣网的一些交互设计修改了tab的交互。」

以上便是我这个月来，通过做大大小小的需求，总结出来的一些做事情的底层方法，会继续在下一个需求中努力运用、继续探索、提高效率。

 

本文由 @莫琳 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议