产品团队管理经验谈

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

产品团队管理经验谈

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

1、团队

起步

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

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

分工

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

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

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

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

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

那么应届生或者刚转行过来的人,是否永远做繁琐的用研工作呢?不会的。随着技能日趋熟练,用研不可能占据他100%的时间,我估计最多50%。一个季度后他的视

野打开了,可以更多参与策划讨论;半年后可能独立做一些策划;一年后又有其他新兵加入,此君愿意的话就正式转去做策划了。大概是这么一条发展曲线。从这条路走到策划职业上去,我认为会很稳当,同时也保证了策划组总能得到丰富可靠的用户研究资料。

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

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

效果

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

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

在策划经理这部分,我之前有个困惑,是策划技能比较强的合适一点呢,还是产品管理比较强的合适?最后前者胜出。原因很简单,定位规划与进度调控,我随时可以插手进来,就算出现短板我也能弥补;但如果策划经理不是从普通策划升上去的,他的策划技能不够强,必然对组内其他策划人员依赖太大。而基层干部(甚至包括中层)明显是堵枪眼的干活,什么地方有缺口,你自己就要冲上去堵。不可能把策

划执行的事情全部丢给下属,期待他们能做得尽善尽美,自己指点江山。这样搞的风险太大了,下属扛不住怎么办?你的位置又没有人事资源的调度权,只好与小组同归于尽。

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

普通策划没什么好说的,关键是与策划经理的相性、互补性。他们两人名为上下级,实际上是搭档关系。是否具备配合上的默契度,就需要我在分组的时候多加考量。用研人员的设置有两个目的,第一点是锻炼新兵,这点基本上成功了。通过长期接触用户,他们的产品感都很快提了起来,在组内讨论时能代表用户提出可靠的意见,减少策划中的自说自话。第二点是为产品设计提供用研资料,却不太成功。因为策划经理还没建立起来用研指导策划的意识,或者不下相关任务,或者下很含混、无从入手的任务。靠谱一点的用研单子很多是我跨级安排,但组内对结果的重视程度也不太高。用研人员又太嫩,不习惯自己给自己提单,主动参与到策划过程中去。此外,我还有一点失误是,只安排他们做用研工作,很少叮嘱他们,同时也要自学策划技能。这样在一年后,用研人员并不能如我期待的完成独当一面的策划,更多作为项目助理,策划顾问的角色,帮助策划人员提高方案的准确度。

最后总结一下技术策划的角色吧,这回我的设想完全失败。普通程序员转型产品设计是比较困难的。如果他们以策划的身份长期了解某一款产品,那么提出技术思维的好的策划点,这没问题,但仅仅如此还不够。程序员大多对界面策划、交互设计、页面文案这些UI/UE的东西不够敏感,对前台细节的把握不够细致,策划上有明显

的短板,能出好点子但不容易完成一整套方案。那如果做开发协调呢?我大错特错的一点是,这需要很强的主动沟通意愿,灵活的矛盾协调技巧。障碍完全不在“语言相通”这一点上,典型的程序员风格反而构成了缺陷。

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

2、业务

流程

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

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

当然,一些基础性、普适性的流程还是要遵守的,不然就太山寨了。但你在网上看到的,听说的越复杂的管理方式,可能越发不适合你。倒不是说人家错了,而是人

相关文档
最新文档