【中生代59期直播实录-Paypal张军】 | 研发，产品，架构，业务，项目管理五角关系下的多元组织架构建设
张军 中生代技术
张军
现任Paypal上海风控中心基础平台部门研发经理，主要负责公司大数据平台，异步服务框架的研发工作，同时也是Paypal开源项目分布式机器学习项目Shifu的作者之一。
毕业于南京大学，先后在SAP, Autodesk等多家外企研发部门任职，2012年加入Paypal至今先后参与公司移动风控埋点系统，风控服务系统以及风控大数据平台的研发管理工作。
请输入标题 abcdefg
课程简介
管理是带人的艺术同时也是协调的艺术，研发作为公司组织架构中有机的一环， 必须要和不同的团队协同工作才能发挥出自己最大的价值，本文主要介绍不同组织架构下各个工种之间的合作与冲突，通过实际案例讲解如何调整组织架构以解决不必要的磨擦， 同时从研发团队的角度出发如何协调好不同团队之间的合作以及如何扩大研发团队在组织中的影响力
前言
工作过几年特别是在管理岗位的朋友们肯定对一个词很熟悉，那就是重组英文也就是re-org，有一句格言讲到这世界上唯一不会变的就是改变本身，这句话用在公司的组织架构上也非常合适，在同一个阶段不同的组织架构可能产生完全不同的结果，今天我们就结合实际谈一谈在IT特别是互联网企业中的组织架构安排及利弊。
在谈组织架构之前我来先明确一下出场选手以及他们在组织中的角色和定位
- 研发 —— 必选
每个互联网公司都会有自己的研发团队，在我看来研发团队的最大职责就是两个字：交付。在规定的时间内高质量的完成产品的开发，并且交付给内部或者外部的用户使用。作为研发中最底层的平台部门来说，往往还肩负一部分创新以及研究的职能。 - 产品 —— 必选
虽然现在产品经理是互联网公司的必备，但是与研发不同，产品团队在不同公司的定位或者职责其实经常是有差异的。在我看来产品团队的职责在于制定产品中长期规划和定位，对外宣传自己的产品以及监督产品的交付质量。 - 业务 —— 必选
业务团队的职责也是两个字：业绩。 具体的来说就是想方设法的给公司挣钱，包括推销产品，维护客户关系等等。当然了我们风控部门业务的职责往往是给公司省钱而不是直接挣钱。 - 架构 —— 可选
互联网公司往往会在研发团队以外设立独立的架构团队，架构团队的职责在于制定平台和产品中长期技术规划，综合的研发部门的技术需求制定公司的技术选型以及不同产品的技术架构。其实明眼人都看的出很多时候架构师的工作和研发是有或多或少的重叠的，后文我们会展开。 - 项目管理 —— 可选
项目管理往往是中大型公司才有的配置，当公司部门众多，往往会出现山头林立各自为战的情况，对于一些大的项目或者产品，这时候就需要一个独立的项目管理团队负责跟进协调不同团队之间的进度以及关系，从高点保证整个项目的进度。
康威定律讲到”organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”中文简单的说就是组织的产品和系统都是组织内部结构的外部体现，在此我深以为然，在加入Paypal风控团队的五年来，经历了很多次的重组，下面我来结合具体实际讲一下不同的架构的利弊
- 研发，业务，产品相互独立
优点：不同的研发团队之间容易合作，公司层面更容易统一推进技术的升级，不同业务线的技术团队之间联系比较紧密，容易做到技术共享避免重复的投资。
实例：在这段时期内我司全面完成了从C++ 系统到Java系统的升级，老的C++系统难于维护，在CTO的组织下全面进行了技术升级。
缺点：这种架构主要的缺点有两个
a. 因为研发和产品业务不在同一个组织内，信息并不能及时共享，合作的效率并不是很高，分歧容易升级,导致扯皮的时间发生。特别是当研发的高层和产品主管有不同意见时，因为双方不在同一体系内就会造成决策周期过长，执行效率低等各种问题，一线员工也会容易产生挫败感
b. 研发属于成本中心，而产品和业务部门属于不同的成本中心和利润中心，所所以业务上产生的发展很难直接反应到研发部门的升职加薪上面，从而导致研发一线员工的升职周期普遍慢于业务线
实例：在这种情况下，新业务和产品的推进比较慢。
-
为了解决这个问题，公司进行了基于事业部的重组，将服务于一条业务线的研发，产品，业务，架构划归到一起
优点：服务于同一业务线的不同团队做到了一荣俱荣，一损俱损，大家信息共享，共同进退。从大的方向上决策周期变短，产品的推进流程显著加快，分歧更容易化解而不是升级。
缺点：不同技术团队之间的交流相对减少。
实例：研发团队的升职加薪周期变短，战斗力显著增加 - 前面讲了大业务线的不同架构，下面我来讲一下技术团队内部的调整，刚才我们看到架构团队和研发团队是平行存在的，这样的安排同样也存在优点和缺点。
优点：独立的架构团队不容易陷入具体技术细节，从大的方向规划数据的流动和不同产品之间的集成，比如更加平衡的考虑支付系统和风控系统的对接
缺点：架构团队的产出很难量化，并且缺乏制度保障。架构师因为不写代码远离一线，容易得出不切实际的设计，同时出现问题时架构师又很容易将责任推给具体实现。造成架构和研发团队之间的摩擦和不信任。
基于以上原因，我们将架构团队分散拆解进不同的研发团队，每个团队的架构下放入研发团队最为首席工程师，同时要求必须要参与具体的开发实现，出现问题也需要上线做支持。
优点：架构师更加熟悉一线业务，设计的架构也更接地气，架构和研发之间的摩擦减少。
缺点：架构师升职空间缩小，一些希望转架构的资深工程师也觉得上升空间不够没有动力，同时因为架构的话语权变小，设计的前瞻性不足。
实例：架构团队被拆解的1年多时间内，风控团队一直沿用已有的系统设计，随着业务的发展逐渐开始落伍。
有鉴于此，在解散风控架构团队一年多以后，又重组了架构团队，但是从前的一些缺点也并没有得到有效解决。
- 产品团队的下沉
基于和架构类似的问题，我们分解下沉了产品团队，这样在风控组织内部，每个产品的研发和产品都汇报给一个总监。
优点：决策周期进一步缩短，产品和研发之间的合作更加紧密，沟通增加，信息更加透明。
缺点：产品经理普遍反映上升空间变小，研发经理和对口产品经理之间容易出现责任划分不清，因为研发经理也会深度参与产品的各种讨论，很多产品经理感觉自己的空间被挤压。
实例：为了解决产品经理上升空间的问题，风控团队引入首席产品经理的角色，让资深的产品经理不用纠结于产品的时间线等细节，而把更多的时间用于规划思考产品的中远期规划。
讲完了组织架构，我来具体的谈一下如何扩大研发在组织内影响力和话语权
看过上面这幅漫画的程序员都会笑一笑，作为研发团队来说最核心的竞争力肯定是持续交付的能力，但是交付的能力其实和影响力是息息相关的，影响力大的研发团队可以拒绝不合理的请求，反之就只能苦逼的加班加点。
影响力环理论 —— 理解，影响，控制
- 理解你的客户
- 你的目标是什么，你对我团队的期望是什么
- 你喜欢的工作方式是什么，你希望如何获取信息
- 你希望得到什么样类型的具体信息，你希望给你的信息是固定格式的吗
- 共同画出蓝图
- 定义目标和期望的产出
- 明确优先级和重要性
- 确定时间线
- 设置合作者的期望
- 明确共同工作中合作伙伴对我团队的期望
- 共同确认我团队的能力范围，什么是超出我团队的期望
- 进一步确认合作伙伴的需求和喜好
- 进一步提出问题
- 深度理解双方的共同利益来创造双赢
- 多问对方开放性问题
- 倾听对方的反馈并及时确认自己的理解是否正确
- 给出承诺
- 达成统一的执行计划并且双方确认
对于不同的利益方，我们可以坚持这几个步骤，因为共同的期望和一致的达成长期下来研发团队的产出将是稳定并且高质量的，并且因为有效沟通模式的建立，我们和不同利益方也容易建立信任并且达到共赢，对于研发团队来说必须要做到一诺年金，给出承诺前要书面确认清楚各方的期望产出，承诺一旦做出，必须说到做到。
从我个人的经验来说，我的团队在近几年内从来没有违背过给客户的任何承诺，总是在规定的时间内完成了和客户共同制定的产出，这样在长期的合作中，团队的在组织内的声望很高，相应的话语权也就扩大，客户非常愿意和我分享自己的想法并且征求我以及团队的意见。
达成一致的模型
在合作中最困难的往往是如何达成一致，包括对于结果和时间线的期望，我们可以通过上面的六个步骤实现：
- 做出充分的准备
- 明确你谈话的目的
- 明确自己的底线和期望(must have and good to have)
- 多方了解合作方的兴趣和需求
- 确定共同目标
- 倾听对方的需求
- 不要急于提出解决方案
- 确认你的理解是否正确
- 确定共同的目标
- 建立信任
- 换位思考
- 确定共同的利益以及明确不同的利益点
- 确定解决方案
- 解放思想
- 着眼于共同的利益和目标
- 进一步深入探讨不同的思路
- 达成解决方案以及备用方案
- 给出承诺
- 要完成什么
- 谁来做
- 什么时候做完
- 完成的定义是什么
- 有力执行
- 及时检查进度
- 改善不足
在实际的工作中，过多的沟通好于过少的沟通，我们要理论结合实践，适时对照理论检查自己的疏漏，及时的做出有效沟通，这样就能逐步扩大自己团队的影响力迈向成功的未来。