【转】一个新手PM的含泪教训

我们WP7会议助手的第一个迭代周期终于结束了，作为一个从零开始的新手PM，通过一个月的工作确实碰了很多壁也长了很多见识，在这里就和大家分享一下我的经验教训，希望能给更多人以帮助。

1， 相比开发，PM更像个体力活，在谈论技巧之前，先确认你有打不完的鸡血和使不完的精力。

作为整个产品的保姆，PM对产品各个细节的掌握远远高于其他团队成员，同时，团队负责人的责任感会让你不停去思考可能需要做的事情，再加上各种讨论，各种会议，和各种人沟通，各种处理应急状况，其实对PM的精力要求非常之高，难怪听我Mentor说过他夫人在谷歌刚入职PM时每晚3点睡觉，现在才知道，哪怕是很小的项目，也很具有挑战性。

2， 相比开发，PM获得的成就感类型是不同的，确定你喜欢这种感觉。

相信写过程序的朋友都有感觉，敲完代码和de完bug时那种兴奋是难以言喻的，然后Pm不一样，每天的各种琐事并不会带给自己太多成就感，也许你可以说产品成型后会很满足，但其实一个周期并不短，这个美好的愿望不一定能支撑你勤奋得工作到周期结束，同时，风险的阴影又一只尾随，这需要Pm能错日常工作中获得满足，并能承受压力。

3， 合适的teambuilding是有益的，但做好了teambuilding不代表一劳永逸。

我们的周期开始之前，我就请大家吃了顿丰盛的晚饭帮助团队融洽感情，包括平时一块活动出行，可以说我们团队的氛围是不错的，但是其实这还不够，一个Pm还必须有用自己的旺盛精力和热情带领成员的能力，我这点上深感不足，比如时常犯困，这会影响他人也打不起精神，这也是我强调1的原因所在。

4， 商议产品细节时pm 应该多做功课，并对自己的方案有信心，有主见。

事实上，不是所有团队成员都会非常用心的去构思产品细节，而Pm有这义务，所以，无论是否团队讨论细节，Pm都得有自己的方案，并在产生争议或者团队迷惑时能够站出来带领团队继续前进。

5， 做任务分工时没有最细，只有更细。

这也是我血的教训之一，我们使用的是VS2010的TFS，一开始我们分task粒度很大，后来发现粒度大了对开发人员来说很不可控，对个人而言，一般4，5小时的任务是能有明确的目标和动力的，再长就容易带来拖延的借口，而由于我们的任务粒度大都很粗，导致一开始都很没有目标，经常一两天过去了也没完成什么东西，同时TFS的日志也没办法给出多少诊断。后来改进后，发现项目的burn down图呼啦一下从下降又陡增不少，真是汗颜。

6， 在周期进行时，遇到产品设计变故，尽量少改动团队日程。

碰到这种问题，最好不要重新设计，新增backlog，而是先把争议部分搁置，照预想完成所有其他工作，防止团队因此整体进度落后。

7， 整个产品设计过程中，用户场景文档就是团队的圣经。

这个比喻是一位外籍PM教授我们的，当时我说的产品方案和交与他看得用户场景不符合，被他严重鄙视。在团队进行中，时刻可能因为变故和思维发散产生新想法，改动旧设计，检验他们的唯一办法就是用户场景设计。与此同时，用户场景文档也要时刻更新，就像宪法一样，与时俱进，但改动要全组共同通过。