这个时代，对全网营销经理的综合能力要求逐渐增高，需要展开的多线程工作也变多了，因此懂得时间管理就显得十分重要，本文就此分享了个人在产品迭代中的时间管理探索、实践、感悟。
业务目标压力越来越大，从业人员竞争也在不断加剧，倒逼产品经理必须能“上得厅堂，下得厨房”。
在这个时代，产品经理光会写需求是不行的，还要了解一些业务、学会一点设计、看懂几句代码、会玩几次地推、懂一些管理…需要做的事情是如此的纷繁复杂，没有几把时间管理的刷子，还真难玩得转。
我们的产品按照角色，分成了多个职能团队：1个产品经理团队、3个开发团队、1个设计团队、1个测试团队、1个运营团队。从业务上，我们把产品拆分为多个小产品，每个小产品的交付由跨职能团队负责，跨职能团队中有产品经理、开发、测试、设计、运营等角色。在产品研发过程上，我们采用了敏捷的Scrum方式。
缩短迭代周期要量力而行
Scrum给出的迭代周期建议是2~4周。
在产品初期，为了实现从0到1的交付，我们花费了几个月的时间。在这段时间里，我们经历了成长的烦恼：规划的不断调整、研发各阶段的衔接磨合、全手工测试的折磨…随着产品交付能力的不断增强，我们才把迭代周期逐步缩短为1个月，直至2周。
周围有些团队刚开始就强行推行2周、甚至1周的迭代周期，最终结局都是：交付遥遥无期、团队成员互相抱怨…
因此，迭代周期的选择要量力而行，产品经理需要根据产品所处的阶段、团队成员磨合情况、持续集成部署进度等多种因素合理进行选择。
高效的会议才有价值
一提到敏捷，马上就有人说敏捷就是开会多：每日站会、计划会、回顾会、演示会…每天光开会了，手头工作白天做不完，只能加班了。
开会确实有利于达成群体共识、识别风险。
但是，频繁的开会总是打断手头的工作，让人恼火。长时间的会议也让人昏昏欲睡。
本文刚写到这里，突然旁边的同事传来一声喊“又要开会啊！？”可见大家对开会的“深恶痛绝”。
下图给出的是我们产品在迭代i的各种会议（不含每日站会、回顾会）。
在产品初期，一开会总是全体参加，会议室都坐不下。但大多数人没有发言的机会，参与度不高，大家都在玩手机。为了改变这一状况，我们做了一些调整：
为了减少记忆成本，对会议的具体时间也做了固定。
对于开会时间过长的问题，主要措施是要限制话唠，限定会议及发言的时间盒，缩短会议时间，超时发红包（很大的红包，呵呵）。
按照迭代顺序梳理待办事项
产品经理每天做的事情很多很杂，想一件做一件肯定是不行的。
我的经验是每天早上在手机上的记事本中，按照迭代顺序写出今天的待办事宜。
比如目前处于迭代20，那么今天我可能需要跟进迭代18之前的运营数据分析、组织迭代19的正式发布、验收迭代20的需求、编写迭代22的产品需求…
然后根据重要性、紧急程度，再排做一个排序，确定哪些先做，哪些后做。
持之以恒地学习、实践、总结
产品经理的时间很容易被每个迭代紧凑的任务填满。即使有点空余时间，也被碎片化了，读书也成了一种奢望。现在，在飞机上或者火车上安安静静地读一本书几乎成了最幸福的事情。
下图是我在每个迭代中的一个学习时间安排。方法很简单，贵在坚持。
每天早上早到公司30分钟，阅读人人都是产品经理的文章或者读书，并做好收藏、标注或笔记。
每周末对本周学过的、有价值的内容进行复读。
每个迭代对在实践中用过的知识进行总结回顾，逐步提炼，持续构建自己的知识体系。
当产品经理，后悔两年；不当产品经理，后悔一辈子。
产品经理之路多艰，做好迭代的时间管理，这条路或许可以走得有节奏一点，顺一点。
