产品管理产品团队管理经验谈Word文件下载.docx

产品管理产品团队管理经验谈Word文件下载.docx

《产品管理产品团队管理经验谈Word文件下载.docx》由会员分享，可在线阅读，更多相关《产品管理产品团队管理经验谈Word文件下载.docx（8页珍藏版）》请在冰豆网上搜索。

指望通过常规渠道很快招到人才是不可能的，常规渠道招到的90%是可造之材，但不是来之能战的人才。

所以要靠特殊渠道拉来的核心成员，去指导外招人员，带动初始业务。

何谓“特殊渠道”呢？

就是人拉人，考验你关系网和号召力的时候到了。

如果连壹定量的人脉资源，个人影响力均没有，那你也没资格爬到中高层去。

也就是个基层干部。

分工

拉人加上外招，第壹个季度凑齐了十来人，业务线也清理了出来。

按产品归类，分成了3个产品策划组，1个视觉交互组和1个运营组。

我对每个策划组有壹些特殊的安排。

首先设壹名策划经理，当然也是主策划。

再设壹名策划，于主策划的管理下完成产品设计。

和主策划于性格上不冲突，能力上有互补性。

再设壹名用研人员——多半是应届生或者刚转行过来的人——另由专人指导其工作。

我有这么壹种考虑，用户访谈也好，用户意见的收集整理也好，可用性测试也好，均很繁琐。

虽然人人均知道“从用户需求出发”这句屁话，但舍得耐心，不厌其烦，能长期踏实关注用户的人其实是很少的。

大部分均于耍小聪明，以为自己能见微知著，隔岸观火。

大部分均跑去见别家的产品创新而不是用户反应，均希望自己能“和众不同”。

像这样的趋势，越是聪明人，或者越是自以为智商高有地位的人，就越难以避免。

我自己均避免不了。

道理谁均明白，就是没法逼自己去干麻烦琐碎的活儿，至少是没法长期持续地干下去。

所以我专门让新兵来做这个事情。

首先新兵的耐性会好壹点，服从性也会强壹点；

其次，我壹直认为新兵应该多做信息整理类而不是创造类的工作，用硬性任务来逼迫他长期大量地接触用户。

他对用户了解越深，相当于策划的底子越扎实，用任务来代替培训是我壹贯带新兵的方式。

那么应届生或者刚转行过来的人，是否永远做繁琐的用研工作呢？

不会的。

随着技能日趋熟练，用研不可能占据他100%的时间，我估计最多50%。

壹个季度后他的视野打开了，能够更多参和策划讨论；

半年后可能独立做壹些策划；

壹年后又有其他新兵加入，此君愿意的话就正式转去做策划了。

大概是这么壹条发展曲线。

从这条路走到策划职业上去，我认为会很稳当，同时也保证了策划组总能得到丰富可靠的用户研究资料。

组里的最后壹名成员通常被称为技术策划。

当初设这个特殊位置的出处是因人立事，恰好有几名程序员转过来做策划，因为“受不了成天去实现别人提交的离谱方案”，打算自己弄个靠谱的出来。

当时我想，也算是新兵，但让程序员去做用研不现实啊，其他策划又没壹个懂技术，那就从技术角度提出策划意见吧，且负责开发协调——他们和开发人员应该是有共同语言的，不至于鸡同鸭讲。

这样，完整的4人产品策划组就搭建起来了。

效果

之上分工的好处我已经讲的很清楚了，那执行中是否和预期吻合呢？

我事后分析，这样安置最大的好处是策划-交互-用研职能放于同壹个产品组里，齐心协力长期共事，彼此之间的摩擦降到最小，对产品的了解程度提升到最高，归属感非常强，避免了部门政治和流程损耗。

于策划经理这部分，我之前有个困惑，是策划技能比较强的合适壹点呢，仍是产品管理比较强的合适？

最后前者胜出。

原因很简单，定位规划和进度调控，我随时能够插手进来，就算出现短板我也能弥补；

但如果策划经理不是从普通策划升上去的，他的策划技能不够强，必然对组内其他策划人员依赖太大。

而基层干部（甚至包括中层）明显是堵枪眼的干活，什么地方有缺口，你自己就要冲上去堵。

不可能把策划执行的事情全部丢给下属，期待他们能做得尽善尽美，自己指点江山。

这样搞的风险太大了，下属扛不住怎么办？

你的位置又没有人事资源的调度权，只好和小组同归于尽。

所以策划经理最好是委任于有成功策划经验的人，而不是有管理经验的人。

当然二者兼顾最好，但哪有这么多人才给你挑选。

普通策划没什么好说的，关键是和策划经理的相性、互补性。

他们俩人名为上下级，实际上是搭档关系。

是否具备配合上的默契度，就需要我于分组的时候多加考量。

用研人员的设置有俩个目的，第壹点是锻炼新兵，这点基本上成功了。

通过长期接触用户，他们的产品感均很快提了起来，于组内讨论时能代表用户提出可靠的意见，减少策划中的自说自话。

第二点是为产品设计提供用研资料，却不太成功。

因为策划经理仍没建立起来用研指导策划的意识，或者不下关联任务，或者下很含混、无从入手的任务。

靠谱壹点的用研单子很多是我跨级安排，但组内对结果的重视程度也不太高。

用研人员又太嫩，不习惯自己给自己提单，主动参和到策划过程中去。

此外，我仍有壹点失误是，只安排他们做用研工作，很少叮嘱他们，同时也要自学策划技能。

这样于壹年后，用研人员且不能如我期待的完成独当壹面的策划，更多作为项目助理，策划顾问的角色，帮助策划人员提高方案的准确度。

最后总结壹下技术策划的角色吧，这回我的设想完全失败。

普通程序员转型产品设计是比较困难的。

如果他们以策划的身份长期了解某壹款产品，那么提出技术思维的好的策划点，这没问题，但仅仅如此仍不够。

程序员大多对界面策划、交互设计、页面文案这些UI/UE的东西不够敏感，对前台细节的把握不够细致，策划上有明显的短板，能出好点子但不容易完成壹整套方案。

那如果做开发协调呢？

我大错特错的壹点是，这需要很强的主动沟通意愿，灵活的矛盾协调技巧。

障碍完全不于“语言相通”这壹点上，典型的程序员风格反而构成了缺陷。

此外，对前台细节的模糊，也使得程序员更多负责纯粹的功能开发协调，界面开发由他人跟进，反而带来了多接口的混乱。

到最后技术策划自己也比较沮丧，觉得无从发挥。

至少是于我这边偏重前台设计的产品项目里无从发挥。

2、业务

流程

刚建立产品部的时候，我自己也是个产品新人，心里没底，仍专门跑到杭研——对，就是我当下待的这个杭研来取经。

拿壹个小本本记满了密密麻麻的几页纸回去。

这次取经对我最大的帮助倒不是纸上的内容，而是于交谈时，对项目流程的规范意识有所加强。

前前后后仍于网上见了不少项目管理资料，天花乱坠矣，其实没什么用。

我当下觉得，产品设计最重要的是意识，了解和尊重用户的意识，流程背后的节奏感比流程本身更关键。

正确的方式未必能增强到位的意识，希望用繁琐到刻板的流程来提高策划可靠性，缘木求鱼耳。

关键是带动团队多用产品，多观察用户，主管要根据团队和项目的情况来定流程，而不是硬套壹个“科学管理方式”上去。

当然，壹些基础性、普适性的流程仍是要遵守的，不然就太山寨了。

但你于网上见到的，听说的越复杂的管理方式，可能越发不适合你。

倒不是说人家错了，而是人家的复杂度建立于他特有的团队和项目背景上，你不要随便生搬过来。

反倒是管理方式越简单，适应性也就越强。

计划

各国均有各国的国情。

我这个产品部的国情呢，就是开发资源特别少，同壹时间跟进十款左右的大大小小的产品，频道又死催死催，再加上壹个特别苛刻的老大坐镇——也就是我。

因此采用了步步紧逼的计划控制方式。

每个月的月末，策划经理均要报下个月的任务节点给我，精确到某壹天，每个组拆分出十几个节点来。

这份时间表由我和策划经理共同协商确认，他点头我也点头，然后所有项目的下月计划被罗列于壹张巨大的mindmanager图表上群发部门邮件——单单这么做自然是不够的，脱离了监控的计划均是废纸。

因此我于每个周末会对着这张表，把下周“到点”的任务整理到我自己的每日计划上面去，壹到时间就晃悠过去问，做完了吧？

给我见见。

当然也不是每个点均检查，有个随机率，但至少要检查50%的任务节点。

到点没完成怎么办呢？

没关系，你能够提前几天跟我解释理由，再把这个月的时间表重排壹次。

那如果没解释（或不接受解释）又没完成呢？

壹开始靠训人，仍把每周的任务节点写于办公区白板上，延误依旧此起彼伏。

最后我创造了壹个“雷”的仪式出来，也就是于mindmanager图表上，对没完成的节点标记为“雷”的图标，每周固定对部门群发“本周雷况通报”的邮件，哪个组踩雷壹颗，哪个组踩雷俩颗，月会上也作汇总通报。

你们当然能够想象到，踩雷比较多的组，于月度和季度考核时壹定会吃亏，具体的惩罚措施不便细说。

实施这个微型仪式后，内部对时间计划的重视度果然大有提升，这也是管理的秘诀，惩罚措施越是透明公开，效果也就越好。

人是社会性的动物，把他放到壹个社会环境里去奖惩，放到四周目光的焦点上去，此时温和的通告比拉到小黑屋怒斥更令人印象深刻。

记得于“打雷”壹个季度后，产品部的进度控制意识已有相当的改善，踩雷案例寥寥无几。

按此发展下去，我就能够放松监控，给大家更多的灵活度，不必总是做个凶巴巴的拿摩温。

不过，我能精确了解计划情况，且于重要节点参和策划案的讨论确认，也是这种计划管理方式的另壹个好处。

否则同时推进十几个产品项目（大中小混杂），不这么盯的话我自己早就乱成壹团了。

仅仅靠周报和例会于事无补。

培训

刚才已经讲过了，我带团队的风格是用任务来代替培训，根据每个人的情况去定制合理的任务，让团队于执行过程中成长起来（过几天我仍要专门发壹篇日志写“如何带好新兵”）。

对于策划的成长，我重视的不仅仅是分配好任务这壹点，仍包括让每份调研材料，每份策划案均摆到会议上去交流讨论。

通过共享产品资料，共享思考的过程，来达到取长补短共同提高的效果。

这个会议通常是组内的例会（4-5人），每周俩次，每次平均90分钟。

每个人的阶段性成果均要于会议上介绍，每份策划案必须通过会议讨论后才能确认。

以我之见，类似例会的好处于于“加速信息的流通和交换”，对帮助每个人的业务成长大有益处。

唯壹缺陷是，由于会议过于频繁，必须有老道的会议主持人才能产生正面效果。

如果策划经理不擅开会，而我又未能参加，则适得其反。

另壹项可取的培训制度，则是我发明的“曝料会”。

每周二上午，由某个组到投影会议室介绍2-3款他们认为“有意思”的互联网产品，无主题限制，可能介绍产品局部也可能是整体，每个组每个月轮到壹次。

曝料会不强制参加，但大半个部门均会主动前往。

目的是有规律地引导每个成员去了解壹些重要产品，尤其是国外的新产品新动向。

曝料会于产品部大概进行了3个季度，后来我仍带到了杭研，当下仍于组织之中。

通过会上的讲解，每个人的产品视野均能够凭借他人的发现而拓展开来。

会议气氛非常活泼，有问有答，欢声笑语。

但壹段时间后，大家从个人爱好出发的“发现”有限，讲空了就搜肠刮肚……这如何是好？

不怕，我随后又增加了“悬赏曝料”环节。

意思是有人主动提出来想了解的某个网站，然后悬赏，多半是“3听红牛”之类，见谁愿意于下次曝料会上讲解。

结果呢，出这份悬赏的多半是我自己，也算是用某种愉快的方式分配市场调研任务。

最重的壹次赏金大约是价值50元的零食，讲解Facebookconnect，开会之前就把零食高高堆于桌子上，讲完后，我把壹大捆零食往她面前用力壹推，众人鼓掌，哄笑。

但我的花招也不是次次均能得手。

比如说部门博客“露点”，类似于XX公司UED研究博客这样。

部门初建时我就弄了壹个，希望大家写，我带头，结果没人响应，作者全是我。

这事儿靠讲道理没用，我强制每个组每个月至少要发壹篇日志，行，那写吧，敷衍得很。

最后搞得大家均很没趣。

结论是我不要以己推人，认为自己爱写则同行均爱写，尤其于工作繁忙之余，没几个人像我这样热衷于研究总结聒噪。

甚至连我写的日志他们也不爱见，我于自己部门里的读者是很少的，当下也壹样，出口型创作。

又比如说部门月会，我为了提高策划经理的会议发言技巧，要求他们于月会上