求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
     
   
分享到
传统产品经理混进互联网的感受
 

发布于2013-6-09

 

  回忆刚加入腾讯电商的时候,一切都让初上手的笔者心里很忐忑,这里木有传统项目的大计划,木有非常清晰的传统标准需求规格说明书,各种木有,大家都 是短打上阵,迅速奔跑。同时项目小而密集,一周两次发布,需求如雨而来,与已往所做过的动辄一两年,再短也得三个月以上的项目相比,实在有点灵巧得超出预 期,一度颠覆了笔者对项目这一概念的认知。所幸遇到了不错的导师,还有很给力的兄弟们。在半年的摸索和试探里,兄弟们被笔者几经折腾,依然一如既往的支 持,感谢导师和团队的兄弟们。如今半年过去,各种苦涩的纠结,甜美的回味,写下来与各位分享,恳请各位高手拍砖指点。

  行文之前,先做个概要的铺垫,按时间顺序,将要展开的内容要点如下:

  多看多问,小步演进;明确方向,聚焦重点;

  梳理流程,培养习惯;鼓励沟通,增进效率;

  明晰责任,接口清晰;适度计划,有序敏捷;

  理念宣导,水到渠成;开放合作,共同成长。

  这些内容都是从初加入团队至今的体会,也是一路走过来历程,自然不只是以上的泛泛概要,且看一一展开。

  多看多问,小步演进

  每一个有理想的青年,在被委以重任的时候,都希望自己立马能运筹帷幄,气死诸葛赛过子房,三把火一烧,令旗所至莫不如臂使指。事实上理想很丰满,现实很骨感,三把火下来,要么是烧得一锅焦黑,要么是烧得一锅夹生。

  多亏导师一再叮嘱,要求多看多问,因此笔者就静悄悄的把自己的火把给灭了,静下心来好好观察。这时候问了自己三个问题:

  1、 电商整体的开发模式是什么样的;

  2、 团队目前面对的问题是什么;

  3、 项目经理在这个团队的位置在哪里;

  要把这三个问题回答完是一篇很长的文章,在此不多说什么,这里表达的意思在于,当PM们初到一个新团队时,是以一个中医望闻问切的方式来介入,还是以 目前流行的暴力强拆的方式来介入。特别是传统IT项目经理出身的同学,必须正视互联网在项目管理方面的特殊性,需要柔性融入,小步推进,在保持团队产出的 情况下,进一步提升团队效率。

  笔者在初入团队的时候,自然是用的望闻问切:

  - 望,望团队气氛,所处环境,工作方式;

  - 闻,有人可能会问,团队有可以被闻到的东西吧,告诉你有的,那就是团队成员身上散发出来的情绪的味道,人家一般不说也不写在脸,但用心是可以闻到的;

  - 问,上面提的三个是问自己的,除此外还要问团队,比如问团队自身觉得哪里感觉不舒服,哪里感觉很麻烦,总归以探知当前痛点为目标;

  - 切,表象看过,就得深入的来了解,切就是扎实的去切入一些实际工作,从实践中来验证,来发现各种好的要保留的亮点,以及各种要调整的痛点。

  下面笔者来分享下初期笔者们搞的水果会的故事,这也是个关于望闻问切的故事。

  小技巧分享之水果会:刚到组内的时候,初看一轮,很不习惯,发现居然没有例会,是为望。继续深入发现新来的同学,不仅是笔者本人,在初期都散发着惆怅 的味道,因为距离感消除起来有点难,是为闻。一轮访谈下来,同志们普遍反应例会还是需要开的,只是没人有空来组织,是为问。初入的头两周,没有例行的固定 时间来集中进行各种交流与反馈,让日常的各项工作很难整体集中统筹起来,此为切。把脉完毕,开始对症下药,团队例会必须开,团队建设也必须开搞,但是,是 分开做?还是合起来做?笔者的答案是合起来,既是团队例会,又是常规团队建设。怎么做呢?首先与开发Leader沟通,争取了些经费,在每期例会上买上一 些水果,例会名为水果会,先谈正事,后吃水果敞开交流,例会的气氛活跃了很多,而且正事团建两相宜。

  项目管理是件很灵活的事,望闻问切能让笔者们一开始就是以团队的需求来作为切入点,进而打开符合团队长期利益的持续改进之门。同时各种以人为本的小技巧或许能收到奇效,大家尽可以挥洒创意,做到更好。

  明确方向,聚焦重点

  在开始这部分的时候,先提几个很实际的问题在前面:

  - 团队天天很忙,但各方仍然说没支持到,怎么办?

  - 需求从很多方向来,可做可不做,怎么办?

  - 各种零散咨询,支持要求满天飞,怎么办?

  这些问题现实中在老团队里很普遍,作为一个运作了很多年的团队,我们团队其实挺苦逼,除了电商主平台外,其它各项业务都有支持,你来我往好不热闹,但是团队成员只有那么多,颇有疲于奔命的架势。

  在经过第一轮的望闻问切后,可以发现以团队目前的人力情况,只能对现有的主平台进行全力支持,否则确实是力有不逮。因此团队内部已经高度一致的希望把支持的业务进行聚焦,重回到主平台的支持和基础技术框架本身的持续改进上来,只是一直没有想好来怎么进行切割聚焦。

  这对团队而言是一件迫在眉睫的事情,得不到好的处理,就会把团队拖到一个个泥塘里,在这个泥塘里,各个上游无法得到充分满足,自己苦于奔命,下游测试 与运维也一样深陷其中。这个时候,需要帮助团队一起来进行团队方向的确定,然后找各级老板沟通,重新定位团队的位置与目标,进行适当的业务切割。

  有人问,你说聚焦就聚焦啊,太水了,木得干货,那咱就上干货,团队在打算聚焦时,进行了以下考虑:

  1、目前支撑的业务中,是否都与公司及部门战略相合?

  2、公司及部门战略显示不适宜由笔者们支撑的业务,是否可以整体逐步移交出去?

  3、公司及部门战略显示应由笔者们支撑的业务,是否可以把高度定制化部分移交出去?

  4、这些移交是否会对公司及部门的长期利益造成损害?

  前三点,是团队在进行业务筛选时的一些要点,而最后一点是团队决定是否移交的终极原则。如果违背第4条,奉劝大家就不要提移交了,这必须是团队份内的 事。因为有产品经理们和技术Leader的长期积累,聚焦方案出来得比较快,同时非常幸运的是,团队的聚焦尝试得到了各位领导的大力支持,最终某些业务被 全移交,某些业务定制化部分被移交,很顺畅的实现了再次聚焦。

  如果一个团队已经处于疲于奔命状态,那么一定需要审视下自己的业务,关注下团队是否还是聚焦在自己的主业务上,精力是有限的,毕竟团队里的兄弟都不是叶问。

  梳理流程,培养习惯

  团队初步融入了,业务也聚焦了,问题仍然有,比如:

  - 需求仍然飞舞,开发排期依然困惑无比,怎么办?

  - 开发兄弟做了很多工作,但外界仍然一再的问,你们到底在做什么,怎么办?

  - 产品经理每每要想知道进度就只能找到对应开发兄弟时常催问,怎么办?

  - 测试天天反馈说,这转测的也太随机了,忽而来一个,忽而又来一个,没有个计划也没个通知,怎么办?

  - 运维说你们的发布太乱了,太随意了,怎么办?

  - 其他各兄弟部门说,想要跟你们合作,需求到底要肿么提,提了你们会不会做,怎么办?

  其实这一堆的问题,都是涉及到流程的问题,具体而言,就是需求找谁提,需求达到什么标准可以排期,测试什么时候介入,信息在哪里公布等等。

  工欲善其事,必先利其器,工具是非常重要的,有的人用微软的Project,有人用Excel,也有人只用白板。电商一直用的是公 司自研的研发管理平台,老实说这个平台工具并不算是较完美的工具,但是结合现实灵活运用好,也能给团队带来较大的帮助。因此结合研发管理平台,解决以上的 问题团队用了以下的办法:

  1、 所有需求都必须提到研发管理平台,需求都必须经过产品组的产品经理接入,解决需求来源的问题;

  2、 所有需求都必须产品经理与对应开发评审过后才能流转到需求就绪,产品组必须在组内对需求评级,这样有效解决了排期难的问题,排期目标变得明确;

  3、 排期权收归项目经理与开发Leader手上,把控入口,让开发及后续执行流程得到保障,也有效避免了所谓的黑活;

  4、 排期与评审时,开发、测试、产品三方共同参与,解决了测试直到转测才知情的问题,也有效促进了各环节的积极沟通与协作;

  5、 向外界约定,所有进度与需求信息从研发管理平台获取,借助研发管理平台实现信息透明。

  事实上所出的措施并不多,但产生的效果是很显著的,目前团队的常规排期会,每周只需不到半小时的时间,测试与开发协作也顺畅了很多,需求流程清晰,各 方也不会再困惑于怎么提交需求。由于所有的信息都在研发管理平台上流转了起来,信息高度的被集中,同时具备了可信度,且随时可探查。任何人想知道团队在做 什么都变得很简单,打开团队的研发管理平台,都在那里,最大限度的利用工具做到信息的公开透明。

  流程并不需要很复杂,流程在这里的作用是让事情有章可循,让工作顺畅有序,好的流程不带来麻烦,只带来有序、效率和透明的工作信息。不是因为规范而需要流程,是因为效率,秩序和沟通而需要流程。

  小技巧分享:应用研发管理平台在实践中最痛苦的莫过于,让每一条信息的状态与实际情况进行同步。刚开始的时候,大多数人都是不习惯去系统里同步状态 的,笔者团队也有这样的苦恼。为了改善这种情况,启用了个无伤大雅的惩罚措施,每周例会审查时,如果有人没有及时更新,那么就必须捐十块钱到团队的水果基 金。开发leader和团队成员一视同仁,在此感谢兄弟们,在笔者屡次找兄弟们要水果基金时,兄弟的积极配合,欣慰的是,现在收基金越来越难了,因为这代 表着同步状态已经成了一种习惯,再次感谢兄弟们的配合。

  象征性小捐献也好,类似小红花小蔫花也罢,真实目标是在流程执行过程中促进习惯的养成,最终产生新的习惯来主动驱动流程,使之融入团队的血液之中。互 联网人都是主动,积极,有独立思想的人,催工的鞭子并不适宜挥舞在这里。在这里好的团队是不用催的,好的团队是兄弟们都会主动的习惯性把所有好的,或不好 的消息传递过来,然后大家伙一起去解决,或一起去欢呼。

  鼓励沟通,增进效率

  笔者也是个老程序员,仍然清晰的记得以下几个比较鲜明的场景:

  - Boss问,为什么做成这样子,答曰产品让干的,Boss批曰,猪脑啊让干啥干啥;

  - 做了个牛逼的产品正等表扬,这天Boss发了嘉奖邮件,木有自己名字,悲愤不已,心头升起小小的幽怨,不满积攒中;

  - 又见兄弟慨叹怀才不遇,Boss有眼无珠,悄悄然裸辞远去,心生悲凉。

  稍年长后回顾,真的是Boss无眼么,真的是产品不靠谱么,非也非也,只是自己放弃了表达的权力,被动,被动,一再被动,从而真的就把自己藏到墙角里去,于司于已,两不落好。

  每个闷骚的程序员心里都住着一个哲学家,笔者最愿用装满饺子的茶壶来比喻开发的兄弟们。他们都很有才,但是他们都很沉默。无论多么不合理的需求,他们 都习惯性的轻微抵抗后,就开始埋头专心的想着去怎么实现。无论做出的产品多么牛逼,在庆祝邮件里即便没有列上他们的名字,他们也只会默默的在心里感慨下苦 逼而已。很多人说,这跟效率有关系吗?笔者要说,大有关系,非常有关系!

  笔者至今工作也不算太长,以经验论,相比较而言一个乐于表达自己心情,时常保持心情愉悦的开发兄弟,是最有战斗力的开发兄弟,也是最不可能默默的跳槽 让你郁闷到哭的开发兄弟;一个乐于分享的开发兄弟,是能最快成长,也最能帮助提高整个团队战斗力的开发兄弟;一个能在需求涌来时,敢于且擅于表达正确意见 的开发兄弟,就像一尊门神,是个能保证团队的产出永远是高质量的开发兄弟。

  团队半年里在这方面的做法是:

  - 开设双周分享,每期让开发兄弟们上去分享自己的心得与体会;

  - 在需求评审时,要求至少要问到为什么、有没有其它更好方案等;

  - 鼓励兄弟们互相间的沟通,鼓励兄弟们从RTX里走出来,面对面的交流;

  - 鼓励兄弟们就自己的工作、团队的各方面提出优化建议;

  - 例会上,虽然研发管理平台已经有足够的信息,仍然要求兄弟们进行自由表达。

  每个开发兄弟都是一座富矿,PM们要让兄弟们不只是会茶壶口微微冒热气,PM们还要让兄弟们勇于把茶壶盖打开,亮出自己一肚子的热腾腾细细煮好的饺 子,之后就静待神奇的收获吧。以笔者团队的双周分享为例,每一期的内容和分享时的妙语连珠都时常让人赞叹不已。现在,团队的目标是,下半年,争取让部分开 发兄弟走上整个电商的大讲堂。

  沟通是个很系统的工程,我们没有办法可以一下子提高所有人的沟通能力,但是我们可以去鼓励沟通行为的本身,从而提高沟通的意愿与能力。

  明晰责任,接口清晰

  责任是一件很有趣事情,一旦分摊到很多人身上,大家就会习惯性的将其从自己身上寄托到其他人身上,这与高尚与否无关,就像笔者老家常说的,一龙治水粮满仓,二龙治水河底干。

  在笔者的团队,起初相关矛盾会出现在两个地方:

  - 需求状态不透明,不能快速哪些需求可以进行排期,哪些需求其实已经发布完;

  - 外部向团队提需求时,可能是找TL,可能是找几个产品经理中的某一个,也有可能直接是找开发兄弟或项目经理;

  这其实导致了一些混乱,第一点解决比较简单的,需求都可以进行充分拆解,落实到人,一来责任清晰了,二来工作量评估也可以更为准确。再辅以前述的水果 会基金捐献制度,需求状态的流转更及时可信。目前流程定下来后,经过一段时间以来的实施,大家已经形成了每天去查看状态并流转的好习惯,水果基金的捐款收 取难度是越来越高了。

  第二点就会比较麻烦些,需要团队内外双向的互动来推动,最后定了几条基本的准则:

  - 所有需求,都必须由产品组进行对接评估,通过后再与开发侧、测试侧共同评审;

  - 开发人员,开发Leader和项目经理在接到外部需求时,需引入相应产品经理介入跟进;

  - 产品组按目前业务方向,对人员进行分工,明确相关责任与接口方向,在各方来提需求时,可以方便的找到对应的产品接口人。

  曾经需求来时,开发组就像草船借箭中的草人,每每被劈头盖脸的需求直接轰击,膝盖都不知道中了多少箭。几板斧下来,首先是进行产品组,开发组的责任划 分,然后进一步定位好产品接口人,一下子天空清净,蝗虫箭雨再也没有了,需求开始像涓涓流水从产品组缓缓而来。在此感谢产品组兄弟们在前线的辛苦工作与支 持。

  在兄弟们被各种外来的嘈杂折腾得烦不胜烦的时候,我们应去倾听各种报怨,鼓励说出真实的心声,从而想办法通过厘清责任,重新界定各自的权力与义务,来让事情重新顺畅清爽起来。

  适度计划,有序敏捷

  初到团队的时候,每每有人问笔者:

  - 可不可以快些,更快一些,咱们不是要敏捷么?

  - 为什么要去做计划,难道咱们不要更快的响应么?

  - 团队没有时间可浪费,难道咱们不能拍完脑袋就立即实现,看看效果么?

  等等诸如此类,似乎快就是敏捷,敏捷就是快;似乎因为会变化就完全不需要规划;似乎一切就是极快的响应,极快的去试,而不需要方向性的指导与评估。那么团队有没有可能做到,既不失于规划,又不失于快速?

  先回到笔者团队的现实,初入团队内的时候,团队内的计划性是比较弱的,强调的是按周排期快速响应各种业务需求。在接手时候,排期已经成了较大的问题, 让所有人头痛不已,同时较远期的规划也变得艰难,在日复一日的埋头苦干中,没有空去看方向。因此决定还是进行适度的计划,来让团队在可预期的一段时间内, 对即将开始的工作有个大致的预期,同时仍然开启周常规迭代,来对零散紧急的需求进行响应。整个计划链与常规紧急响应调整后现状如下:

  上图中,计划外需求有几个分支,如紧急且复杂的需求,将按照优先级依据一进一出的原则进入当月的月度计划,在项目型迭代中进行开发;不紧急且复杂的需求,则放入下月月度计划。

  在这种长短迭代结合的协作之下,笔者团队可以较有效的使产品保有一定的规划性,同时又能对日常紧急需求进行及时响应。有适度计划带来的秩序和节奏,又不失敏捷的交付与响应。

  很难说这种方式是敏捷还是传统的RUP,这更像是参考两者后量体裁衣的实践,没有包治百病的最优方法论,是为没有银弹。笔者在此抛个砖,希望所有团队都能给自己裁出一身合体的好衣裳。

  理念宣导,水到渠成

  “我手执钢鞭将你打!……”阿Q兄当年有个梦想就是拿着钢鞭当领导。咱能学他么?好歹也是受过高等教育的,再说了,咱就一普通 PM,手上也还真就没有钢鞭!是不是没了钢鞭事情就没法推了呢,美帝和我党用历史经验告诉大家,宣传工作才是一个组织的传家宝。回到地面,当大家在一个团 队内推行一些措施时,真的感觉不是容易的事情,以下几个问题是通常会被挑战到的:

  - 团队运转得好好的,为什么要按这些措施做?

  - 这样做会有什么好处与弊端?

  - 软性抗拒,应付性的处理下,等不催了就悄悄的停掉。

  当然,还会有其它的一些问题,暂列几个典型的做个样例,在推行的过程中,发起人推得辛苦,执行的伙计们也接受得辛苦。个人经验,在一项措施要被推行前,事先的宣导是很重要的,即要在推行前,在团队内进行一系列的导向性宣传,且必须真的以团队长远利益为出发点。

  宣导的目的是在事前清理掉可能的误会区,这会有效的防止在执行中误会频生,引出各种牵强的解释,甚至引发冲突;同时团队也有机会在事前做好充分的思想 准备,消解可能遇到的阻力,引发愿意尝试的动力。如果确实是一项好的措施,也确实对团队有益,那么在事先充分的宣导后,必然可以水到渠成,事半功倍。

  分享下笔者团队推行双周分享的事吧,团队曾经是有过双周分享的,但由于忙等种种原因,没有持续下来。现如今重新开张,如何来调动大家的积极性呢?我们专注于去发掘分享对大家的益处,一定要是实实在在的好处,这些好处大致如下;

  - 双周分享可以给到大家舞台,让大家尝试去展示自己所长;

  - 双周分享可以让大家吸收其他人的经验成果,开阔眼界;

  - 分享前的准备,可以有效的总结自己的经验,促进自己成长;

  - 分享能力是个人综合能力很重要的一环,并且有助于在司内长期发展。

  等等诸如此类,实实在在绝无虚假的益处。宣导的一定是可信的,真实不虚的,为团队成员着想的,这样团队成员才会愿意相信,愿意投入精力来做这件事情。目前团队的双周分享是很不错,每期同志们都会积极准备,而且讲起来也是各具风采。

  开放合作,共同成长

  这个话题比较大,开放合作是大势所趋,就像QQ网购在前些天接入了支付宝,腾讯也在去年开始了倡导整个大平台的开放。双赢的组织和个人,会得到更多正向的支撑与反馈,从而让团队能在更健康的氛围中持续壮大。

  这个部分说不上什么经验之谈,更多的是一份寄语,腾讯电商,乃至整个腾讯,大方面需要各个Group的合作,小方面要各产品组、开发组、测试组、运维 组、运营组之间的精诚合作,大家才能一起水涨船高。落实到个人,对开发而言需要去尝试理解产品经理们KPI的压力,对产品经理而言要尝试去体谅开发和测试 这些后端兄弟的琐碎与不易,团队之间互相理解,互相扶持,大家一起和电商共同成长。

  在笔者团队,团队也会有一些尝试,比如开发团队的大讲堂,并不局限于开发技术分享的本身,总是会邀请产品经理、运营、测试来分享他们的工作与体会,从而促进各方的理解与合作。

  笔者前述的部分业务高度订制部分移交各业务部门自己处理,在这件事上,其实也是从合作的角度出发,各自做自己最擅长的事,笔者团队提供底层技术平台,业务方按自己的意愿更快速的响应定制,各展所长,在合作中双赢。

  同时,团队也在致力于运营平台的建设,最大限度的将相关的运营合作能力开放出来,让运营可以对程序的结果进行个例的自主优化,该平台的上线,很多运营的同学给予了极其热烈的欢迎,这是团队与运营的合作双赢。

  还有团队的鼓励沟通,明确职责与接口,这些都是为了让个人和团队更为开放,能够更地好去分工合作,形成集体的战斗力。

  开放与合作,团队会一直进行下去,团队的未来,一定是更开放的,也是更懂合作的。

  最后的结语

  零散的写了很多,从传统到互联网项目,乍一接触会感觉反差比较大,但骨子里,大家都是希望团队稳定、效率高,执行有序、质量高,信息透明、互信高。私 心里深深以为,这之间距离确实有,但并不会比想象中的更远。有很多东西都是相通的,比如都应该是以人为本,以计划为工具,以流程建立团队风俗,以绩效为目 标。执行层面粒度与倾向性或有不同,大的脉络仍然是一脉相承。

  最后列些个人感受到差异,给大家参考下。计划是重要的,但并不是唯一重要的,比如团队必须随时响应更高优先级的突发需求;项目不一定是要规划得大而全 整体交付的,大的项目其实是可以拆小来做的,比如保持快速小步的迭代,持续交付;流程不一定是要卡得死死的,其实可以抓大放小,保持团队的自主性,比如在 团队成熟后,可以尝试把部分排期权下放;优先级并不是一成不变的,其实每过一段时间优先级可能就转换了,因此需要时常进行更新调整;再比如团队是必须珍惜 爱护好的,因为互联网是由无数小型项目串起来的大事业,你将与你的团队在N多的小项目里一起同行到永远。

  项目管理,其实没有成法可照搬照抄,不同的团队,不同大环境,都会有自己不同的实践选择,操作上无优劣之分,只有是否最适合自己团队的考量。在此抛砖一块,期望得到更多的回应,互相交流促进。


 
分享到
 
 


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


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


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