去年今时，做完旧选股宝1.0，开了个人公众号，写了一篇《没经验的小菜鸟PM，历经九曲十八弯后，也能写项目总结了》，当时记录了自己做的不好的点点list。今年今时，做完新选股宝1.0，也想写一篇总结，这个给自己最大感（ji）触（tang）的点，与君共勉。（原来我都开始写鸡汤了啊艾玛）
“是时候”用时间表了
不知道有多少人是真正意识到时间表是重要的。你可能在文章里读到这个观点，也可能在一些交流会上听别人说这个观点，你会觉得很对，但是，看看、听听过后，转眼就不记得了。
但是，产品经理这个岗位，每天都需要”铲平”围绕产品的各方人员的意见、建议、需求、需要的资源协调等等，同时还要去研究什么对用户好，什么对产品好。
岗位性质决定了你并不能一心一意只做一件事，在你身边，全是“各种污”，等着你去“铲平”。
你可能会觉得自己每天都很忙，但是一周、一月后，你未必会回答得出自己都干了什么。
这次，让我意识到时间表的重要性的，有两个时刻：
1、上周，也就是1.0版本上线前的最后一周，我们还在设计Logo、下载落地页、App的欢迎页和开屏页。
这些东西其实并不是临时才想到要做的，而是一早就在计划中，只是，并没有把它严格的放在时间表里。同时也没有很好的预估难度以及预估设计的时长和一些其他变量因素，这点会放在下一个部分中进行详细描述。
2、又一次做版本1.0，整体看，做事比从前条理一些，心态比从前淡定一些，而不会像一年前，整天都乱悠悠。但是今天在回想这一整个月的经过，发现自己居然不能很好的列出来自己到底做了什么，这个让我感觉到恐慌。
所以，真的是时候去好好列时间表来“适当”规范自己啦~
用什么“时间表”呢
要去用，也要知道如何用、用哪些。
在讲铲平经理的时间表之前，我想描述一个类似层级关系的例子来总体感受下先，那就是现在很盛行的OKR制度：
公司年目标是什么？
细分的Q1、Q2、Q3、Q4的季度目标分别是什么？
围绕自己的季度目标，自己要做的是什么？
（只是大概借用层级，其他制度细节并不做具体展开）
那其实铲平经理一般会用到的几张时间表，从大到小，差不多也是酱婶儿的：
1、产品线的生命周期表：
说实话，这个实在是太高端了，至少没个6、7年经验，是搞不定的。
这个我就不详细说惹，反正就算说了，也是YY，并不是什么实战经验，等我4年后再来填这个坑，哈哈哈。
今天反省了一下去年总体的一个工作方式，有个很大的问题就是：
什么意思呢？一个好的”需求池”，应该有以下一些行为：
把可能OK的需求放进来；
给所有的需求列个大概的优先级，并随时根据情况调整；
不断踢掉不再可能OK的需求；
管理好”需求池“，自然就会有一个需求时间表啦。有关于需求池的管理问题，看来日后经验丰富一些阔以总结一下，啊哈。
3、单个项目进度表
根据需求池里的需求优先级，确认好该版本要做哪些内容后，就开始开发了。
一般的互联网公司貌似是么有项目经理的，根据不同的管理方法，要么是产品经理、要么是技术总负责人或者两人同时进行管理。
项目进度表有几个好处，大家应该都知道：
成员之间对项目的各个时间有概念，总体来说不会有项目遥遥无期的无力感；
每个人知道自己每天要做什么，做不完会有啥后果，可能会有个群体鞭策力吧；比如：设计师不能按时完成设计稿/后端不按时完成接口->前端和移动端可能会延迟 ->测试会可能延迟 -> 项目会延迟…
每个人知道别人每天要干什么，这样比较方便配合。
铲平经理会对某个功能需要多少人配合、要做多久慢慢积累概念，慢慢就“虽然我不会码代码，但是我知道大概原理和时间惹”的“经验”。这种积累多了，应该也能体现在产品设计上，总之有好处咯。
注：列项目进度不是最最重要的，一定要先要确定清楚什么事由谁做。上文提到的最后一礼拜还在做宣传图，很大部分原因是因为一开始是给一个设计师做，因此顺着这个设计师完成功能稿之后的时间去安排。只是后来因为一些原因，把那些宣传图给了另一个设计师去做，那另一位设计师的时间就非常紧惹，当然跟我本身文案功底差，需要一直改文案也有关系，吐血三升。
4、个人成长阶段时间（目标）表【鸡汤！鸡汤！鸡汤！】
我自己就有这个毛病，不喜欢短期目标，总喜欢在有激情的时候，给自己立个大目标。然后呢？坚持了几天，就没有然后了。
如果经常这样的话，心情不稳定的时候，就容易很负面，觉得自己什么都做不好、什么都不会。
酱紫，其实是很不健康的，不管是工作，还是其他方面。
第一次无意识尝试、然后发现短期目标的可操作性，是跑10km。
第一次跑10km的时候，前6公里我还ok的，到了6公里之后，开始觉得自己跑不动了，不想跑了，但是又给自己10km的目标，不想怂，就又跑，但是跑不动怎么办呢？我就盯着马路的灯看，跑过这个灯，就盯下一个灯，跑过这个灯，就盯下一个灯，盯着盯着就感觉身心没有其他，只有一盏盏灯了，然后就到了10km。
盯着灯的时候，就觉得我离它很近，只需要几步就好，一个个几步就到了跑完后面的4k咯。
喜欢立大目标的人，都比较心急，比如我，但是心急真的是吃不了热豆腐的。选个小目标，踏踏实实沉下心来走，走走走，再选个小目标，走走走…
某天回头看的时候，会发现，你就这样走过了曾经雄心壮志设定的但总也完不成大目标。
（描述好像很不错的样纸，but瑶纸童鞋正在努力甩掉急躁的心，尝试建立小目标…）
5、日工作时间表
这个就是用来搞清楚自己每天要干什么、在干什么的表啦。不管是用来安排自己一天的工作还是用来回溯自己一天的工作，都是极好的。不然，就会出现我上文不知道自己一个月干嘛了的怨念感。
这个其实很像花钱这件事。每个人每天都在花钱，你可能记得一笔钱花哪儿去了，但你记得一天的花销、一周的花销、一月的花销是多少、花哪儿去了咩？应该很多人都搞不清楚的。
从大学开始我就记账，到现在5年了吧。最初的原因很简单，就是觉得每个月没钱的莫名其妙。记了一段时间后，发现自己的消费习惯了，就开始计划每个月的预算计划，虽然到现在还是不能好好执行，但是至少并不会像时间一样，花哪儿去都不知道。
时间比钱更宝贵，更要知道花哪儿去了，是不是…
经常提醒自己时间表的存在好吗
定了时间表但不去执行，不但浪费制定表的时间，还打击了自己的小心脏。
辣么，怎么坚持做呢？
这点我做的非常不好啦，不过在慢慢改善中。
工具暂时推荐桌面日历+桌面便签，日历用来记录每天要做的事情，便签用来记录一段时间要做的事情或者其他备忘都阔以…
一定尽量铺满屏幕！因为太显眼了！假装看不到都不行！
然后加个学习互助微信群或者qq群什么的，在群里说明自己的目标，然后每天打卡根据完成度打卡。
自我监督力量不够的时候，求助于旁人，并不是一件丢脸的事情，啊哈。
好惹，有关于这部分的总结就酱紫吧…
最后，有关于项目进度表我再简单说一下：项目进度表并不只是为了那张表，而是：
1、各成员在评估自己时间的时候，会去回顾要做的需求、怎么做、大概用时多久，这给了程序猿们一个再一次理解需求、思考需求的时间；
2、各成员能够信息一致，协同一致；
遇到过这种情况的：技术团队按照功能模块进行安排时间，然而设计师按照页面逻辑流程进行安排时间，这样对导致一个问题，就是设计师做的图，开发暂时用不上，开发需要的图，设计师暂时给不了，这就坑爹了。
3、项目需要有容错时间；
可能谁生病请假啦，或者突然遇到某个问题比较大，或者公司没网络啦等等总是有可能的。没有进度表，怎么去定容错后的deadline呢。
4、项目进度表需要被监督和执行；
早会啊，每天说下自己昨天干了啥，今天要干啥，需要什么支持，每人可能最多就是1-2分钟的事情。
