当前位置:首 页 > IT客 > 查看文章

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

IT客 你是第1586个围观者 0条评论 供稿者: 标签:, ,

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

这家伙很懒,什么都没写!

—— zhaorong

zhaorong
你可能也喜欢Related Posts
众说纷纭Comments
大眼 可爱 大笑 坏笑 害羞 发怒 折磨 快哭了 大哭 白眼 晕 流汗 困 腼腆 惊讶 憨笑 色 得意 骷髅 囧 睡觉 眨眼 亲亲 疑问 闭嘴 难过 淡定 抗议 鄙视 猪头
小提示:直接粘贴图片到输入框试试
努力发送中...
  • 评论最多
  • 最新评论
  • 随机文章
footer logo
未经许可请勿自行使用、转载、修改、复制、发行、出售、发表或以其它方式利用本网站之内容
Copyright © zhaorong All Rights Reserved. 滇ICP备15006105号-1