求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
 
产品团队管理经验一枚
 

2011-06-07 来源:网络

 

有那么零零碎碎的五年时间,我一直在做媒体。08年初转型产品设计,从头组建产品部,策划-交互-用研-视觉-运营这些职能都包括进去,跟进过的大大小小新新旧旧五花八门的产品20多款。我在这个位置上待了大约15个月,按照个人习惯,做过不少制度化的组织流程尝试。今天忽来兴致,觉得过往经验也不妨拿出来讲一讲。

1、团队

起步

我刚受命组建产品部的时候,确定下来的人大概只有3位策划,2位视觉(兼交互),2位运营。后面才逐渐扩到三四十人。还好,第一批成员中不乏强者。起步的时候不一定摊子很大,但一定要有核心成员;或者换个说法,如果一开始找不到核心成员,你就没法顺利起步。

指望通过常规渠道很快招到人才是不可能的,常规渠道招到的90%是可造之材,但不是来之能战的人才。所以要靠特殊渠道拉来的核心成员,去指导外招人员,带动初始业务。何谓“特殊渠道”呢?就是人拉人,考验你关系网和号召力的时候到了。如果连一定量的人脉资源,个人影响力都没有,那你也没资格爬到中高层去。也就是个基层干部。

分工

拉人加上外招,第一个季度凑齐了十来人,业务线也清理了出来。按产品归类,分成了3个产品策划组,1个视觉交互组和1个运营组。我对每个策划组有一些特殊的安排。

首先设一名策划经理,当然也是主策划。

再设一名策划,在主策划的管理下完成产品设计。与主策划在性格上不冲突,能力上有互补性。

再设一名用研人员——多半是应届生或者刚转行过来的人——另由专人指导其工作。我有这么一种考虑,用户访谈也好,用户意见的收集整理也好,可用性测试也好,都很繁琐。虽然人人都知道“从用户需求出发”这句屁话,但舍得耐心,不厌其烦,能长期踏实关注用户的人其实是很少的。大部分都在耍小聪明,以为自己能见微知著,隔岸观火。大部分都跑去看别家的产品创新而不是用户反应,都希望自己能“与众不同”。

像这样的趋势,越是聪明人,或者越是自以为智商高有地位的人,就越难以避免。我自己都避免不了。道理谁都明白,就是没法逼自己去干麻烦琐碎的活儿,至少是没法长期持续地干下去。所以我专门让新兵来做这个事情。首先新兵的耐性会好一点,服从性也会强一点;其次,我一直认为新兵应该多做信息整理类而不是创造类的工作,用硬性任务来逼迫他长期大量地接触用户。他对用户了解越深,相当于策划的底子越扎实,用任务来代替培训是我一贯带新兵的方式。

那么应届生或者刚转行过来的人,是否永远做繁琐的用研工作呢?不会的。随着技能日趋熟练,用研不可能占据他100%的时间,我估计最多50%。一个季度后他的视野打开了,可以更多参与策划讨论;半年后可能独立做一些策划;一年后又有其他新兵加入,此君愿意的话就正式转去做策划了。大概是这么一条发展曲线。从这条路走到策划职业上去,我认为会很稳当,同时也保证了策划组总能得到丰富可靠的用户研究资料。

组里的最后一名成员通常被称为技术策划。当初设这个特殊位置的出处是因人立事,恰好有几名程序员转过来做策划,因为“受不了成天去实现别人提交的离谱方案”,打算自己弄个靠谱的出来。当时我想,也算是新兵,但让程序员去做用研不现实啊,其他策划又没一个懂技术,那就从技术角度提出策划意见吧,并负责开发协调——他们与开发人员应该是有共同语言的,不至于鸡同鸭讲。

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

效果

以上分工的好处我已经讲的很清楚了,那执行中是否与预期吻合呢?

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

在策划经理这部分,我之前有个困惑,是策划技能比较强的合适一点呢,还是产品管理比较强的合适?最后前者胜出。原因很简单,定位规划与进度调控,我随时可以插手进来,就算出现短板我也能弥补;但如果策划经理不是从普通策划升上去的,他的策划技能不够强,必然对组内其他策划人员依赖太大。而基层干部(甚至包括中层)明显是堵枪眼的干活,什么地方有缺口,你自己就要冲上去堵。不可能把策划执行的事情全部丢给下属,期待他们能做得尽善尽美,自己指点江山。这样搞的风险太大了,下属扛不住怎么办?你的位置又没有人事资源的调度权,只好与小组同归于尽。

所以策划经理最好是委任于有成功策划经验的人,而不是有管理经验的人。当然二者兼顾最好,但哪有这么多人才给你挑选。

普通策划没什么好说的,关键是与策划经理的相性、互补性。他们两人名为上下级,实际上是搭档关系。是否具备配合上的默契度,就需要我在分组的时候多加考量。

用研人员的设置有两个目的,第一点是锻炼新兵,这点基本上成功了。通过长期接触用户,他们的产品感都很快提了起来,在组内讨论时能代表用户提出可靠的意见,减少策划中的自说自话。第二点是为产品设计提供用研资料,却不太成功。因为策划经理还没建立起来用研指导策划的意识,或者不下相关任务,或者下很含混、无从入手的任务。靠谱一点的用研单子很多是我跨级安排,但组内对结果的重视程度也不太高。用研人员又太嫩,不习惯自己给自己提单,主动参与到策划过程中去。

此外,我还有一点失误是,只安排他们做用研工作,很少叮嘱他们,同时也要自学策划技能。这样在一年后,用研人员并不能如我期待的完成独当一面的策划,更多作为项目助理,策划顾问的角色,帮助策划人员提高方案的准确度。

最后总结一下技术策划的角色吧,这回我的设想完全失败。普通程序员转型产品设计是比较困难的。如果他们以策划的身份长期了解某一款产品,那么提出技术思维的好的策划点,这没问题,但仅仅如此还不够。程序员大多对界面策划、交互设计、页面文案这些UI/UE的东西不够敏感,对前台细节的把握不够细致,策划上有明显的短板,能出好点子但不容易完成一整套方案。那如果做开发协调呢?我大错特错的一点是,这需要很强的主动沟通意愿,灵活的矛盾协调技巧。障碍完全不在“语言相通”这一点上,典型的程序员风格反而构成了缺陷。

此外,对前台细节的模糊,也使得程序员更多负责纯粹的功能开发协调,界面开发由他人跟进,反而带来了多接口的混乱。到最后技术策划自己也比较沮丧,觉得无从发挥。至少是在我这边偏重前台设计的产品项目里无从发挥。

2、业务

流程

刚建立产品部的时候,我自己也是个产品新人,心里没底,还专门跑到杭研——对,就是我现在待的这个杭研来取经。拿一个小本本记满了密密麻麻的几页纸回去。这次取经对我最大的帮助倒不是纸上的内容,而是在交谈时,对项目流程的规范意识有所加强。

前前后后还在网上看了不少项目管理资料,天花乱坠矣,其实没什么用。我现在觉得,产品设计最重要的是意识,了解和尊重用户的意识,流程背后的节奏感比流程本身更关键。正确的方式未必能增强到位的意识,希望用繁琐到刻板的流程来提高策划可靠性,缘木求鱼耳。关键是带动团队多用产品,多观察用户,主管要根据团队和项目的情况来定流程,而不是硬套一个“科学管理方式”上去。

当然,一些基础性、普适性的流程还是要遵守的,不然就太山寨了。但你在网上看到的,听说的越复杂的管理方式,可能越发不适合你。倒不是说人家错了,而是人家的复杂度建立在他特有的团队和项目背景上,你不要随便生搬过来。反倒是管理方式越简单,适应性也就越强。

计划

各国都有各国的国情。

我这个产品部的国情呢,就是开发资源特别少,同一时间跟进十款左右的大大小小的产品,频道又死催死催,再加上一个特别苛刻的老大坐镇——也就是我。因此采用了步步紧逼的计划控制方式。

每个月的月末,策划经理都要报下个月的任务节点给我,精确到某一天,每个组拆分出十几个节点来。这份时间表由我与策划经理共同协商确认,他点头我也点头,然后所有项目的下月计划被罗列在一张巨大的mindmanager图表上群发部门邮件——单单这么做自然是不够的,脱离了监控的计划都是废纸。因此我在每个周末会对着这张表,把下周“到点”的任务整理到我自己的每日计划上面去,一到时间就晃悠过去问,做完了吧?给我看看。

当然也不是每个点都检查,有个随机率,但至少要检查50%的任务节点。到点没完成怎么办呢?没关系,你可以提前几天跟我解释理由,再把这个月的时间表重排一次。

那如果没解释(或不接受解释)又没完成呢?

一开始靠训人,还把每周的任务节点写在办公区白板上,延误依旧此起彼伏。最后我创造了一个“雷”的仪式出来,也就是在mindmanager图表上,对没完成的节点标记为“雷”的图标,每周固定对部门群发“本周雷况通报”的邮件,哪个组踩雷一颗,哪个组踩雷两颗,月会上也作汇总通报。你们当然可以想象到,踩雷比较多的组,在月度和季度考核时一定会吃亏,具体的惩罚措施不便细说。

实施这个微型仪式后,内部对时间计划的重视度果然大有提升,这也是管理的秘诀,惩罚措施越是透明公开,效果也就越好。人是社会性的动物,把他放到一个社会环境里去奖惩,放到四周目光的焦点上去,此时温和的通告比拉到小黑屋怒斥更令人印象深刻。

记得在“打雷”一个季度后,产品部的进度控制意识已有相当的改善,踩雷案例寥寥无几。按此发展下去,我就可以放松监控,给大家更多的灵活度,不必总是做个凶巴巴的拿摩温。不过,我能精确了解计划情况,并在重要节点参与策划案的讨论确认,也是这种计划管理方式的另一个好处。否则同时推进十几个产品项目(大中小混杂),不这么盯的话我自己早就乱成一团了。仅仅靠周报和例会于事无补。

培训

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

对于策划的成长,我重视的不仅仅是分配好任务这一点,还包括让每份调研材料,每份策划案都摆到会议上去交流讨论。通过共享产品资料,共享思考的过程,来达到取长补短共同提高的效果。

这个会议通常是组内的例会(4-5人),每周两次,每次平均90分钟。每个人的阶段性成果都要在会议上介绍,每份策划案必须通过会议讨论后才能确认。以我之见,类似例会的好处在于“加速信息的流通与交换”,对帮助每个人的业务成长大有益处。唯一缺陷是,由于会议过于频繁,必须有老道的会议主持人才能产生正面效果。如果策划经理不擅开会,而我又未能参加,则适得其反。

另一项可取的培训制度,则是我发明的“曝料会”。每周二上午,由某个组到投影会议室介绍2-3款他们认为“有意思”的互联网产品,无主题限制,可能介绍产品局部也可能是整体,每个组每个月轮到一次。曝料会不强制参加,但大半个部门都会主动前往。目的是有规律地引导每个成员去了解一些重要产品,尤其是国外的新产品新动向。

曝料会在产品部大概进行了3个季度,后来我还带到了杭研,现在仍在组织之中。通过会上的讲解,每个人的产品视野都可以凭借他人的发现而拓展开来。会议气氛非常活泼,有问有答,欢声笑语。但一段时间后,大家从个人爱好出发的“发现”有限,讲空了就搜肠刮肚……这如何是好?

不怕,我随后又增加了“悬赏曝料”环节。意思是有人主动提出来想了解的某个网站,然后悬赏,多半是“3听红牛”之类,看谁愿意在下次曝料会上讲解。结果呢,出这份悬赏的多半是我自己,也算是用某种愉快的方式分配市场调研任务。最重的一次赏金大约是价值50元的零食,讲解Facebook connect,开会之前就把零食高高堆在桌子上,讲完后,我把一大捆零食往她面前用力一推,众人鼓掌,哄笑。

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

比如说部门博客“露点”,类似于XX公司UED研究博客这样。部门初建时我就弄了一个,希望大家写,我带头,结果没人响应,作者全是我。这事儿靠讲道理没用,我强制每个组每个月至少要发一篇日志,行,那写吧,敷衍得很。最后搞得大家都很没趣。结论是我不要以己推人,认为自己爱写则同行都爱写,尤其在工作繁忙之余,没几个人像我这样热衷于研究总结聒噪。甚至连我写的日志他们也不爱看,我在自己部门里的读者是很少的,现在也一样,出口型创作。

又比如说部门月会,我为了提高策划经理的会议发言技巧,要求他们在月会上轮流介绍上个月的产品进展——每人只给5分钟时间,精确计时。讲之前所有人领张表格,匿名给策划经理打分,台风评分内容评分,最后交给我汇总后通报分数结果。这个分数没有任何作用,就是策划经理自评“发言水平”的参考坐标,民主评分的结果也比较客观。但令我失望的是,4位策划组长,几乎没有一人会为了拿一次高分而作半小时的准备,抱着无所谓的态度,甚至难得见到谁为此准备一回PPT。我的演说家养成计划宣布失败。

3、协作

困境

产品部自我组建开始就处在一个很尴尬的位置,之前没这个部门,产品相关业务一片蛮荒。等到部门成立,同时服务9个频道,又面对高标准严要求的提单,打算一步与国际形势接轨。问题是开发资源就我的综合评估,仅为全部提单与时间目标所需的1/2。频道也不管这个,只找产品部的麻烦——你接的产品项目单子你要负责到底。妈的我又管不到技术部……

结果产品部被卡在频道与技术部之间,里外不是人。具体情况很复杂,也没必要细说。这个时候我却起不到很好的外交作用,自负嘛,做不到低声下气地一个个内容总监找过去,请求人家体谅。我不出头说软话,频道就更不给面子,只看客观结果不考虑客观困难,哪怕明知道这个困难主要在技术资源上,也单单找产品部的晦气。

专员

在产品部成立的前两个季度,因为上述的困境,我被搞得很惨,部门支持度很低,快扛不住了,怎么办?出头说软话去?不可能!我只好跟团队推心置腹,要和频道对口人员多沟通,多解释,争取他们的体谅。这个道理策划经理当然也明白,可他们比我的情商还要低,还不乐意跟频道解释因由。不仅不解释,有2个组连策划过程中的沟通都很不够,闷头苦干,把频道晾到一边去,好像在搞暗箱操作。

这时,连我都忍不下去了。按说对别人的提单有归属感是好事,但你也不能甩开频道自己弄啊。产品做出来终归是别人用,不是你用啊。我知道你们内向,要面子,沟通嫌麻烦顾虑多,但独断独行的结果就是吃力不讨好。或者你单方面以为已经沟通到了,但有没有效果,有多大效果都不去管。反复跟他们讲“密切交流,理解万岁”的大道理没用,训斥甚至惩罚、评C都没用。我没辙了,难道只能撤换策划经理吗?

未必。人力调度的精髓在于“搭配”这两个字。我之前不是安排了用研人员在每个策划组吗?招聘他们的标准之一就是擅长沟通。随后我给每个用研人员增加了一项任务,负责本组的“频道关系协调”,搞搞公关,并让沟通积极主动的他们作为唯一的频道接口,恐吓说,频道认可度在个人考核中起码要占到1/3的比重。

这项安排把内向、骄傲、沉默的策划经理解放了出来,把谦逊亲切的用研人员推到频道面前,让合适的人去做合适的事,对频道关系有很大改善,但还不够彻底,我又使了一个大招……要求执行产品周报制度。

周报

什么叫产品周报呢?就是每个组的用研人员,在周五下班前,把项目本周情况发一封邮件给频道的相关人员。策划进展开发进展都写在一起。看起来很简单吧,我却是第一个以及唯一这样做的公共部门。

我一直有个观点,人人都是客户,对产品部来说频道也是客户,所以必须从分析客户需求做起。并不是每个频道客户都蛮不讲理,大部分时候他们要求的是知情权,了解提单进展情况。这很合理嘛,如果我们能非常透明地保持与频道的实时沟通,让他们了解每一个环节的成绩与障碍,相信频道也能更理解产品部的努力与资源困境。

话虽如此说,如果频道很少主动过问,策划经理做不到及时交流,而用研人员的沟通又不够全面系统,怎么办?人治不如法治,我最拿手的事情就是定制度,定规范。随后我和用研人员一起定了个产品周报的模板,用统一格式写清楚针对贵频道的产品提单,本周做了什么事情,到达什么阶段,遇到什么问题,下周工作计划,简简单单的一封邮件,周五下班前发给每个频道并抄送我。这样他们就知情了,不会觉得自己面对的是个黑箱子。从周报中发现哪里不对头,也能及早与我们商量解决。

不仅仅如此,因为接收产品周报的频道人员通常级别不高,我还要为整个产品部做一点公关。于是每个月的最后一天,我会对所有主编以上人员群发一份简洁的产品部月报,把全部项目进展列一份清单,免得大家说不知道你们产品部在干什么。废话,开发人员少项目周期长,一季度下来发不了几个版本,哪里像你们天天都在发稿子做专题。

类似的一系列措施执行下来,效果非常明显。一半频道对产品部的评价提高到了80分以上,09年一季度在公共部门里高分率第一。但还有一半频道,单子丢给你就不管了,既不看周报也不作日常交流,单方面的要求达不到就发飙。那我真没辙了……我脾气也不好,上去就吵。善哉,刚烈有罪。

4、总结

稀里哗啦写了这么多,可以看出来一件事情,就是我很爱搞制度。这在网站部是出了名的,却是个坏名声。大佬有个说法是制度越少越好,多了就没效果,或者说约束多了就互相冲抵、稀释。我觉得这是错的。下属是否重视制度,在于是否有配套的监控奖惩,这个制度是否能刺激到他。但制度越多,监控奖惩的管理成本就越高,把管理变成一桩体力活。所以大佬很不赞同。

如果管起来这么辛苦,我为什么还要搞许多制度出来呢?

因为很多道理靠喊口号提高觉悟是没有用的,靠抽查和骂人也没用。上面写得很清楚,比如没有用研人员和配套的提单要求,我怎么督促策划组坚持做用户研究呢?没有每月计划监控与雷仪式,我怎么督促大家提高进度意识呢?没有曝料会,我怎么督促大家保持产品研究呢?没有产品周报,我怎么督促大家与频道积极沟通呢?

“督促”这两个字如果不想变成空话,屁话,就必须拿出有规律的监控奖惩在后面撑着,最好再加上“仪式化”的效果放大器,那就是制度。

这时有人可能要质疑我,你招聘更合适的人不就行了吗,你的团队进度意识不够强,研究热情不够高,沟通意愿不够主动,这明明是人的问题啊。

是的,是人的问题。但在广州这个地方,针对产品人才,在提高招聘效果和加强制度监督之间,后者对我更实用一些。更重要的是,制度执行的目的不是做拿摩温,而是用制度来引导团队,培养好的习惯和氛围。制度执行到某个时间段,大家都接受它了,变成一种习以为常的做事方式,这时再放松监控,管理成本也就下去了。制度本身不会地久天长存在,而是与时俱进。我追求的也不是招聘“完人”,而是团队的共同进步。

举例来讲,我09年调动到杭州,整个工作环境变得厉害,以前的很多制度都不适用了,必须放弃掉哪怕是成功的经验,然后根据新的环境去设计新的制度。

另一个关键点是,设计制度与设计产品没两样,用户是你的下属。设计前要做用户调研,实施后也要做效果分析,灵活调整这些制度——改进它或者放弃它,别死扛着放不下去面子。如果用户体验很差,执行效果很差,就算你“令出如山”也顶屁用。如果制度的改良能提高体验和效果,别人未必在乎你“朝令夕改”。当然改版不能太频繁,有个节奏上的度。

那么,我辛辛苦苦搞了这么多制度,最终的效果怎么样?部门氛围倒是积极上进,团队凝聚力很强,然则5个季度里产品部拿了4个C,不是倒数第一就是倒数第二。气得有次我在机场对大佬怒吼:“2C辞退,你为什么还不开除我!”

既然我这么冒火,说明对考核结果不服(过几天再发一篇分析考核制度建设性的日志)。但这个事情没法谈,你是考核的loser啊,你说什么都会被认为是自我辩解,“狡辩”嘛,“找理由”嘛。算球,我在月会时几次对部门大声讲,我不服考核,但必须服从管理。我仍然以A部门的荣誉感与大家并肩奋斗。我们并不为了考核而工作,而是为了自己的产品追求努力工作。

唉,现在已经没有这个产品部的独立编制了,部门重组了,人全散了,我那5个季度的团队建设心血荡然无存。不过,管理经验都能带走,我也完成了从媒体内容到产品设计的转型。严格说起来,还是应该感谢网站部给我这个转型的机会。我对自己管内容中心那5个季度的评分是65,对管产品业务那5个季度的评分是75,一步步成长起来是件美好的事情,至少比怨天尤人,自以为怀才不遇更好。

向各奔前程的兄弟们凌空致意。



正视研发管理才是高水平竞争
需求是如何变成产品原型的
产品经理能力模型解说—把控
产品经理的正确定位
谁是合格的产品经理?
产品管理与产品营销的区别
更多...   


统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
SCRUM过程实践
敏捷测试-简单而可行


某博彩企业 产品经理与产品管理
北京 研发团队与工作管理
广东金赋信息 敏捷开发过程与项目管理
某支付平台 软件配置管理与发布管理
富士 软件外包项目管理与进度管理
塞孚耐 基于Scrum的敏捷开发
更多...