产品经理基本功:迭代时间管理

0 评论 14362 浏览 105 收藏 7 分钟

这个时代,对产品经理的综合能力要求逐渐增高,需要展开的多线程工作也变多了,因此懂得时间管理就显得十分重要,本文就此分享了个人在产品迭代中的时间管理探索、实践、感悟。

业务目标压力越来越大,从业人员竞争也在不断加剧,倒逼产品经理必须能“上得厅堂,下得厨房”。

在这个时代,产品经理光会写需求是不行的,还要了解一些业务、学会一点设计、看懂几句代码、会玩几次地推、懂一些管理…需要做的事情是如此的纷繁复杂,没有几把时间管理的刷子,还真难玩得转。

我们的产品按照角色,分成了多个职能团队:1个产品经理团队、3个开发团队、1个设计团队、1个测试团队、1个运营团队。从业务上,我们把产品拆分为多个小产品,每个小产品的交付由跨职能团队负责,跨职能团队中有产品经理、开发、测试、设计、运营等角色。在产品研发过程上,我们采用了敏捷的Scrum方式。

缩短迭代周期要量力而行

Scrum给出的迭代周期建议是2~4周。

在产品初期,为了实现从0到1的交付,我们花费了几个月的时间。在这段时间里,我们经历了成长的烦恼:规划的不断调整、研发各阶段的衔接磨合、全手工测试的折磨…随着产品交付能力的不断增强,我们才把迭代周期逐步缩短为1个月,直至2周。

周围有些团队刚开始就强行推行2周、甚至1周的迭代周期,最终结局都是:交付遥遥无期、团队成员互相抱怨…

因此,迭代周期的选择要量力而行,产品经理需要根据产品所处的阶段、团队成员磨合情况、持续集成部署进度等多种因素合理进行选择。

高效的会议才有价值

一提到敏捷,马上就有人说敏捷就是开会多:每日站会、计划会、回顾会、演示会…每天光开会了,手头工作白天做不完,只能加班了。

开会确实有利于达成群体共识、识别风险。

但是,频繁的开会总是打断手头的工作,让人恼火。长时间的会议也让人昏昏欲睡。

本文刚写到这里,突然旁边的同事传来一声喊“又要开会啊!?”可见大家对开会的“深恶痛绝”。

下图给出的是我们产品在迭代i的各种会议(不含每日站会、回顾会)。

在产品初期,一开会总是全体参加,会议室都坐不下。但大多数人没有发言的机会,参与度不高,大家都在玩手机。为了改变这一状况,我们做了一些调整:

为了减少记忆成本,对会议的具体时间也做了固定。

对于开会时间过长的问题,主要措施是要限制话唠,限定会议及发言的时间盒缩短会议时间,超时发红包(很大的红包,呵呵)。

 按照迭代顺序梳理待办事项

产品经理每天做的事情很多很杂,想一件做一件肯定是不行的。

我的经验是每天早上在手机上的记事本中,按照迭代顺序写出今天的待办事宜。

比如目前处于迭代20,那么今天我可能需要 跟进迭代18之前的运营数据分析、组织迭代19的正式发布、验收迭代20的需求、编写迭代22的产品需求…

然后根据重要性、紧急程度,再排做一个排序,确定哪些先做,哪些后做。

持之以恒地学习、实践、总结

产品经理的时间很容易被每个迭代紧凑的任务填满。即使有点空余时间,也被碎片化了,读书也成了一种奢望。现在,在飞机上或者火车上安安静静地读一本书几乎成了最幸福的事情。

下图是我在每个迭代中的一个学习时间安排。方法很简单,贵在坚持。

  • 每天早上早到公司30分钟,阅读人人都是产品经理的文章 或者 读书,并做好收藏、标注或笔记。
  • 每周末对本周学过的、有价值的内容进行复读。
  • 每个迭代对在实践中用过的知识进行总结回顾,逐步提炼,持续构建自己的知识体系。 

小结

当产品经理,后悔两年;不当产品经理,后悔一辈子。

产品经理之路多艰,做好迭代的时间管理,这条路或许可以走得有节奏一点,顺一点。

 

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!