研发管理组织架构

小白的白

0 H; V5 D5 e( b. X/ |: F! V# i

• 篮框：业务线
• 横向：职能线：黄色的小人是业务负责人
• 强调一点：不是所有的职能和层级都是需要的。
  ( j; F* g3 q5 j3 x; n, `; j

各位看官请注意接下来重点来了：层级多少不重要， 核心是形成一个个的业务团队，且每个团队都需要一个负责人 职能线主要是做专业支持，相对来讲重要性会低一些。 至于其他的重点，请各位看官随我慢慢看来

所有的团队首先必须是业务团队

啥叫业务团队呢，就是一定要有业务目标。 一般来讲，对于直接盈利的产品或者项目，作为业务团队是好理解的。业务目标也是好定义的。无论是日活还是增长，是盈利还是营收都是好定的。

那内部支撑团队呢？是否是业务团队呢？比如内部ERP， 中台， DevOps? 如果没有目标，那么为什么要投入呢？ ERP一定是为了提效 中台一定是为了避免重复造轮子，提高研发速度，拉通数据，提供大数据分析得基础。 * DevOps，当然也是为了缩短研发上线周期。

那么从目标分析，ERP的业务指标就是为某个部门缩短了多少处理时长，解决了多少成本。 而中台提供的服务全都可以换算产值，也可以简单定义服务的使用频率。 DevOps也是减少了多少发布时间，提高了多少发布次数等等。 最终的结果还是可以归结为实际的业务目标。 总结下来即是：所有团队都是业务团队

那么为什么所有的团队首先必须是业务团队呢？ 那就还是那句话，我做了一堆的功能，但是我的使用部门没有提升能效，没有降低使用部门的成本，那么我的ERP除了自high，价值在哪里呢？ 团队的存在必须要有其价值！ 所以重点中的重点，请记住： 所有的团队首先必须是业务团队

负责人必须要有全部的责任和权利

全部的责任： 作为一个产品或者一个事业线，事情做不好当然都是这个人的主责。不管是他的下属没做好，还是他下属的下属没做好，甚至是第三方出了问题。锅都是这个人的。 因为他是责任人，方向是他选的，合作方是他选的，人是他选的。当然他主要负责。至于他内部怎么定责是他的问题。当然作为好的上级领导，是可以给予非常专业的建议和指导哒。当然这个负责人即不听建议，自己又做不好，那就不要留着过年了。 全部的权利： 啥叫全部的权利呢，人事组建的权利，利益分配的权利，任务安排的权利，有且仅能有负责人全权掌握，当然他也可以去做权利下放。 全部的全力其实才是最难达到的状态。兰胖自身的经历之中，绝大部分上级boss都喜欢插手下级的具体事务。比如对正在进行迭代插入一个其实不那么紧急的需求。比如强制要求产品必须要这个色系等等。最严重的的，兰胖遇到过插手绩效的和插手人员组成的（这里控制预算，成本，薪资都是可以的，但绝不能插手选谁不选谁）。

话分两头， 作为上级的话，兰胖建议放手让下属去做，出了事帮下属抗就好了。这样下属才能成长，上级后面才会更轻松。 确定下级组织的业务目标，如果业务目标是长期的，短期内也可以确认交付目标 月度或者季度地确认目标达成情况，没有达成要定责，达成了，超过了要及时表彰和激励。 * 如果觉得自己定的目标太轻松了，请在下一个周期提高难度。

作为下级的话，如果上级就是喜欢插手，但如果插手的非常专业，那就愉快的接受吧。如果非常非常不专业的插手，甚至是会导致你的绩效目标成反向增长的。恩，要么做个乖宝宝，面向领导编程；要么赶紧留意好的机会吧。（兰胖遇到过非专业插手，且插手的内容和业务增长完全相反，且推锅给下属，且是有邮件证明的情况硬推的领导。恩~，兰胖的心理建设能力得到的巨大的提升。）

如何组建业务团队呢

• 首先要有明确的业务目标
• 其次确认业务目标的负责人（一般小团队这个负责人就是老板大人，大一点则可能是事业线总裁，产品负责人，产品经理，甚至可能是技术经理，运维总监，算法总监。）
• 最后是负责人确认在怎样的预算下下还需要什么样的人来补全团队就好了
• 业务组织是动态的，是可以回收和释放的
  

如果释放和回收资源

根据业务目标发展的情况（天花板了，ROI低了，战略方向变化了，甚至业务黄了），这个时候业务线就可以根据情况将资源释放回资源池。 资源池可以是职能线，也可以是上级领导，然后重新分配或者放入回收站。

总结

组织架构的搭建还是以业务目标为起点。将业务目标和具体的人绑定，给予与责任同等的权利和资源额度 这个时候组织就基本搭建完成了。剩下的是根据规划的业务目标确认组织运行的健康程度就好（也就是业务的增长是否与预期相符）

cichishia

讲的很清晰