产品研发团队管理实操版.docx

《产品研发团队管理实操版.docx》由会员分享，可在线阅读，更多相关《产品研发团队管理实操版.docx（20页珍藏版）》请在第一文库网上搜索。

1、产品研发团队管理实操版导语：作者作为一个典型的从一线产品经理成长起来的小组长，在这个成长的过程中专业能力不断提高，也经历了不少辛酸血泪。本文作者将与你一同分享团队管理的实操经验，希望这些总结和感悟，能够帮助到很多跟作者一样的成长中的初级管理者!作者是一个典型的从一线产品经理成长起来的小组长,网上有很多讲解团队管理的文章，大都是偏理论的，作者的这个分享是比较偏实操的，是一些拿来即可用的方法工具，希望作者的这些总结和感悟，能够帮助到很多跟作者一样的成长中的初级管理者。先说一下团队的情况。首先是组织架构层面,这个团队原来就是一个纯粹的研发团队，由研发组长和三个研发小组组成。在作者进组之前，这个团队大

2、概运营这30个小工具，这些工具的用户量或大或小，成熟度也不一。作者是2018年12月份进的组，是这个团队的第一个产品经理,直接挂在研发组长下面。2023年组织架构调整，独立出来了一个产品组，2023年下半年产品组长和研发组长双双异动了，产品组长空缺了一段时间。从2023年12月份作者开始暂代组长，也来了一个新的研发组长。2023年5月份研发组长异动,新来了一个产品组长，兼任研发组长。20235至今2018.122023.1研发组长研发小组研发小组研发小组产JRff1ABC产品里临时AIISWB产品组长B研发小组研发小组研发小蛆产品蛆长我组员B蛆员C2023.22023.8研发组长产品组长Z研发

3、小组研发小蛆研发小蛆珏=Rff1sr：ABC我蛆员B蛆员CO2023.12-2023.5研发组长产品组长（我的代）iI；iII研智、组研管蛆研誓组组员A组员B组员C其次是在人员配比方面，这个组研发人数一直都是40人左右。但之前是没有产品经理的产品经理的人数也不是从0忽然一下子增到10的，而是从1个2个一3个，经历了3年多时间慢慢增加到10个的。另外这个组之前也是没有前端的从2023年下半年开始有了自己的前端,经过1年的时间发展到4个前端。总结来说，这个组花了三年多的时间才达到了各种角色人员配比平衡的一个状态。从2018年年底作者进组一直到2023年年底的这段时间，作者基本上就是一个大头兵。这段

4、时间的专业能力成长很快，也充满了辛酸泪，回头单开一篇分享，以下的分享和总结就从作者暂代组长开始说起。一、接收团队后的三座大山不管是空降过来还是从内部成长起来的管理者，新接手一个团队之后基本上都需要解决以下三个问题：1 .定义团队价值和目标2 .招聘合适的人、定义这些人的分工、建立各种协作机制3 .做好年度、季度、月度工作规划、借助管理手段确保绩效落地如果是空降过来的管理者,还会有一个额外的过程，就是知人一识人T用人一建立信任和权威。对于产品组内而言，作者倒是没有这个过程，因为作者是第一个产品经理，是最熟悉产品的，也熟悉所有一线工作的同事，之前就已经建立了一些专业权威。但是跟作者合作的这个研发组

5、长以及他底下的小组长是都换过的，所以跟他们之间有一个磨合和建立信任的过程。2023年上半年合作的这个研发组长是其他组的研发老人，之前就认识,所以整个建立信任的过程还是挺快的，作者们从一起工作到产出一些成果不过就是一个月的时间。2023年空降的这个领导就不一样，对于他来说（作者现在领导），当时他就有建立信任和权威的这么一个过程,作者跟他磨合了有大概三个月的时间，才开始有一些真正的产品/团队管理上的动作。下面展开讲一讲作者解决三座大山的过程和感悟。1.定义团队价值和目标整个2023年团队是比较混乱的，直接领导和间接领导都变了两回，大家对于2023年在做的事情又有一些不认可，再加上这个团队原来人均运

6、维着一个小工具，小组之间几乎没有联系，所以这个团队的成员，不管是产品还是研发，普遍是I:匕较迷茫的，对这个部门的目标和价值普遍没有认知，也不太认可自己在做的事，基本上可以用一盘散沙来形容这个团队。作者跟研发组长接手之后，恰逢组内制定2023年工作计划。对于手上拿的这30个工具，作者跟研发组长一致认为需要聚焦，作者们按照工具的建设成熟度、使用范围大小、工具本身的差异化价值的大小，给所有工具的后续发展做了一个分类。工具建设成熟度工具使用范围差异化价值后续建设方向高大高重点建设-低推进下线低小高按需建设把那些有一定成熟度的、在整个集团范围内都有差异化价值的工具拿出来作为后续重点建设的工具；那些没有差

7、异化价值的工具，不论使用面大小，通通都做下线处理，让用户迁移到集团的其他同类工具上；那些有差异化价值但是建设尚不成熟的工具，作者们尽量不扩大使用面，按需建设。这样一波操作下来,其实就只剩下了5个工具是作者们要重点建设的，在这个事之后作者们也建立了一个价值准则作者们只做整个集团范围内有差异化价值的工具,并且要做精做好,绝不重复造轮子。后来这个价值准则和作者们对于这些工具的处理方式也得到了大家的普遍认可,所以大家有了第一个共同认同的目标一推进下线这些不太可能产生大价值的工具。但是作者们选出来了接下来要重点的建设的工具，并不等于就定义清楚了团队的目标和价值，那5个工具之间还是几乎没有关联，大家仍然不

8、知道作者们为什么而存在。老实说作者当时不具备定义目标和价值的能力,没有那个senseo之前当大头兵的时候，作者就只管建工具、推广使用、降本增效就完事儿了，根本没有从公司的角度想过作者们解决了公司的什么问题，后来才知道价值的一些基本维度营业成本、运营效率、销售收入、客户体验。B端产品价值维度企业需求B端产品价值生产资料需求生产力当时就到混沌学园里听课，去学习定义问题思考问题的一些最基本的逻辑，去看案例，再对照自己的工作。当时针对保留的这5个工具，具体做了几件事：1 .站在公司的视角、用户的视角上看这些工具解决的到底是怎样的一个问题，产生的价值属于什么维度。2 .去市场里找同类产品，搞清楚自己做的

9、这个工具到底是不是市场化的一个产品，市场上是怎么量化这个工具的价值的。3 .把这些工具当B端产品看，定义清楚这些工具的客户、用户、合作伙伴。4 .理想情况下这个工具的产品架构、能力清单。最后总结出几个视角下作者们工具的价值： 公司视角下，提高特定类型需求的研发效率、同时控制系统安全风险。 业务视角下，提升客户导入效率、提升一线运营效率。 产品视角下，为公司贡献基础技术组件，未来有商业化的可能。接下来全年目标的定义也自然是根据这几个价值点来的，类似于降低客户导入周期系统安全防护能力建设商业化项目应用和收入1总的来说这个阶段倒用不上多少管理技巧，主要是考验管理者的认知能力，具体又表现为几个方面：1

10、 .多角度看待问题的能力：从部门、公司、行业、市场等不同层次不同视角来看待问题。2 .定义关键问题的能力：作者们到底要解决的是谁的什么问题，如果你定义的问题对于任可一个角色来说都不是问题，那这个问题或许确实是个问题，但没有价值。3 .把价值转化为目标的能力：当定义了一个有价值的问题后，那么用什么手段来解决这个问题呢，作者们要建一个怎样的产品能力或运营体系，达到怎样的一个目标，怎么衡量目标是否达到了。2.招聘.分工、协作招聘一个人的时候，并不是说有了编制就随便招一个人，人也不是越多越好。作者是从以下几个维度来评估是不是要新招人手的：1 .公司是不是有编制和预算？有的话才能考虑加入，否则只能替换现

11、有人。2 .目前的总工作量是不是让团队严重超载了，除去那些可做可不做的工作外，团队是否需要高强度加班才能完成全年目标？加人是不是能提升团队产能？如果工作量严重超载，并不是一定要加入进来，可以考虑降低目标；如果不能降低目标，也要看加人是不是能提升产能，如果可以提升则可以考虑加人；如果不能提升产能，就要考虑去提升现有人的能力；3 .是不是找到了新的价值点，有一个很大的问题需要专门的人来解决？这个人来了之后跟其他人的分工是不是能划的清楚？如果是有新问题要解决，一般考虑新招人，但如果不能把相关的活都拆出来给到这个人，则要考虑调整现有人的职能分工，否则新人来了会施展不开拳脚，还会降低其他人的生产力。4

12、.团队中是不是有人出问题了，明显不能胜任工作？这个时候是招一个新的人替换现有人，不需要新的编制。同时也还是要从不同的维度考察这个人，即便真的要淘汰，也要做到管理留痕。如果决定要招新人了，首先得定义清楚你想要一个什么样的人，给这个人打上标签，这样才好招。常见的通用标签有：1 .要一个经验丰富的还是一个初级选手？取决于你需要怎样的人才梯队。2 .要一个男同学还是女同学？不同性SiJ会给团队带来不一样的力量补充。3 .要一个基础能力扎实（学习能力等坯是要一个领域经验丰富的？通常在市场上很难找到基础能力又扎实，又刚好做过这个工作的同学。当时作者的情况是团队非常年轻，作者居然是当产品经理时间最长的人,需

13、要一些有经验的人；团队女性比较多，需要男性力量平衡下；作者个人更看重基础能力扎实的，过来之后再学习相关领域知识，关键是作者在市场上也找不到做过类似产品的人。时间线上，先是淘汰了几个在意愿和价值观上不达预期的人，换进来踏实肯干的应届生，再同时换掉了能力不及预期的人，然后补充了两个经验丰富的人。在淘汰人的过程中，都是给他们找了下家的，这些人的能力并不是非常差，只是不适合这个团队。折腾下来，花了一年多时间才组建出一个相对健康的团队。良好的分工是提升团队生产力和个人成就感最基本的条件，如果职能重合，不仅是浪费资源，同时会打击个人积极性，因为这个活干出来的业绩有争议，还得分人一半，搁谁谁都不愿意。另外一

14、个,团队分工并不是一成不变的，需要根据当时的目标和人手动态调整，像作者自己的团队，分工职能是一个季度一调。作者自己做职能分工的时候遵循以下几个原则： 每个人必须有一整块的活，这块活略微超出这个人的现有能力，可以独立考核，可以支撑这个人成长、出业绩、晋升。 每个人的分工对他的能力要求跟这个人的特点尽量匹配，具体说来这个活是要求抽象能力、架构能力，还是要求执行能力、需求分析能力，还是要求沟通协调能力等等。 人人都能互相备份，包括大家能备份作者，不存在一个活说只有一个人能干，所以至少一年会有一次大的职能调整，作者每个季度侧重跟进的产品也不一样。说实话做分工也不是一个简单的活，要求你自己对产品架构径熟

15、烂于心,对目标的实现路很清楚，团队成员才能不被你的分工相互拖累，才能在你的分工设计下相互配合，做到1+1=2而不是1+12,但其实1+12也是很多团队常见的现象。由于所有产品基本上都是作者都干过，对于产品非常熟悉，所以分工对于作者来说不是太费劲，但也中间也出过问题，说完招聘、分工，再说说协作。依据整个产品从需求调研到上线运营的流程，协作分为好几大块，产品内部协作、产研协作、产研测协作、产品运营协作。正常来说就按研发流程来即可，但总有一些不在正常研发流程内的场景，例如客户反馈线上问题时，作者们如何能快速解决线上问题，并及时修复缺陷，例如迭代日历中给的测试时间太紧张怎么办。这些问题都没有标准的工作流程，每个团队有他自己的行事风格，所以只能是拉上关键人讨论行得通的协作流程和职能分工，监督执行，并反复优化这个流程。但在协作过程中有一个要注意的就是,不能偏袒产品团队,不要有屁股,要客观地看问题判责任，否则自己就会失去公信力，一单研发不认可你这个人了，之后所有的协作、协调都会变得困难。3.工作规划和落地执行这部分要求一丢丢专业能力和一些基本的管理方法。在工作规划方面,自己要能定清楚年度目标，拆解到季度。落地执行方面，就是通用的项目管理能力和戴明循环。这部分更多是