京东物流王梓晨：打造全栈团队，你要避开这些大坑

我叫王梓晨，来自京东物流研发系统架构部，现在负责京东物流 GIS 团队。今天， 我想和大家分享的是如何打造全栈团队。

首先假设现在有一支团队叫“如此团队”，里面的成员如下：

我们的 PM（产品经理）叫小汪，他提出的需求是设计一个“航空母舰”；
我们的业务负责人 Business Owner，给他取名叫伟哥；
同样还有些 RD（研发工程师），就叫他们小明和小强好了，他们的 leader 叫大猫；
团队里的 QA (测试) 同学叫小丽。

现在，这些团队成员因岗位设置不同，职责自然也不同。但是在相互沟通的过程中，却产生了一些问题。这并不是奇怪的现象，在日常工作中很多团队都会遇见同样的情况。

场景 1 ：沟通不畅怎么办？给你“好看”的

第一个场景，RD（研发团队）的领导大猫有一天跟大家说：现在已经进入到了集成测试阶段，需要和其他部门一起进行联调测试，所以从现在开始必须做到 bug 日清。

不久之后，大猫查看 jira 等工具，发现依旧有很多 bug。这时候，大猫就开始问研发工程师小明是什么情况？小明说这不是自己的 bug 啊，PRD(产品需求文档) 上就是这么写的。测试小丽同学却说不是这个意思，PRD 上写的是另一种情况。争执不下，无奈最后搬出 PM（项目经理）小汪来裁判，仔细听了小明和小丽各自的阐述后，无奈地摇摇头说，都没理解到位！

我们经常会遇到同样的沟通场景，但出现的原因是什么？该如何解决？我建议可以从看板辅助开始。

说白了，就是建立一套透明可视化、标准化的流程。这是一个普通的看板，Idea 列代表 user story 还是一个萌芽，需要进一步孵化。进入到 PO 产品阶段，需要细化需求，鱼骨图似的不断的问为什么。之后才能进入到 Backlog 阶段，在此阶段，产品负责人需要分解出任务列表并确定优先级事项；最后才是开发测试，开发和测试都要包含 to do / doing 和 done。有一些任务出现问题时，可以先把它放在一边。当任务进入迭代时，你会发现这些问题是没有价值的。那么我们再回想一下，刚才关于 bug 做到日清的问题，对照看板的内容来看：

在 Idea 到 PO (Product Owner 产品负责人) 这个阶段，产品负责人应该把业务的投入产出比分析清楚，并且能把业务需求转化为开发需求。最后当整个需求要进行开发的时候，再把它拆分出任务列表并确定优先级，作为整个迭代的开始。

在进入 Backlog 的时候，产品、研发和测试三方的同学应当一起把产品所有验证点核对一下，要捋清楚环节和重要的收益点。

像之前出现的问题，很明显能看到，是开发、测试和产品之间没有进行沟通，基本是靠 PRD（产品需求文档）来传递信息。所以我们应该遵循的首要原则是，文档只能用作留档和以后的追诉，不能代替沟通的作用。

场景 2 ：责任不清、互相推诿怎么办？

这个场景也很常见：某次大家一起开晨会，研发团队领导大猫说需求需要下周四上线，大家评估一下可以吗？研发同学说没问题，测试同学小丽也说问题也不大。快到时间时，大猫问进展得怎样了？研发同学说已经搞定了；但小丽说，B 系统那个接口根本调试不通，数据库也访问不通，集成的测试也还没写，周四可能没办法上线了。

这个问题对于看板来说，就是交付开发和开发完成的问题。现在我给大家细说一下。

在交付开发的时候，to do / doing / done 是来梳理需求的。因为之前在 backlog 阶段，研发已经和产品经理、测试一起讨论过这个需要了（to do），如果在这个环节大体上来梳理清楚，就能真正做了 (doing)。在 done 的时候，一定要把单元测试写好，且整体代码覆盖率要达到 90% 以上，同时也要帮助下一个测试环节的同学部署好测试环境。

而测试也分为 to do / doing / done 。在 to do 这个阶段可以和开发并行，在这个阶段就去整理每一个业务验证点，形成并梳理最后的集成测试，之后就可以准备上线了。那在测试完成到上线的时候应该需要做些什么？

一个全栈团队需要做以下这些事情：最起码的基本配置要解决，代码最起码要把它推到到 git 上，同时把代码下载下来。要完成这样的集成测试，需要把整个业务条线都整理清楚；集成测试做完后，一定要检查线上的环境。

作为一个全栈团队，一定要非常清楚每个环节潜在交付物的定义；当然其中最重要的一点是，上线之前一定要做好回滚方案。

全栈团队成员应该具备什么样的技能？

接下来，我要分享的是全栈型团队成员都应该具备什么样的技能？首先从领导来说。

首先，全栈型领导应该做一个服务型领导，要对整个团队的任何情况负责，团队出现了任何问题，第一责任人肯定是领导，而不是团队里的任何一个成员。这样的领导绝不是控制大家，而是更多挖掘大家的主观能动性。同时，这样的领导一定需要有个人魅力，要自律，最好还能有一些幽默感。当然，其实最重要的一点，不要扛着下属的猴子，避免把团队成员应该承担的具体责任落到自己身上，否则你就会成为整个团队的瓶颈。

其次，全栈团队一定要讲究执行力。这里想和大家分享京东的人事与组织铁律十四条里的几条原则。第一条是“No No No 原则”，但凡涉及到用户体验以及公司发展的需求，无论是谁提的都不能说 No，一定要给出解决方案；第二条是“24 小时原则”，所有邮件必须 24 小时内回复；第三条是“会议三三原则”，一个会议时长不要超过 30 分钟，PPT 不要超过 3 页，PPT 里应该都是干货，同一事件决策不超过 3 次，否则升级处理，保持沟通的高效；第四条谁发起谁负责，成为第一责任人，如果出现问题，处理问题的同时应该立刻上报风险，让所有的团队成员知道。

最后，全栈型团队一定是自组织团队，自组织就是要多问个 Why ，同时需要每个人都有这样的习惯。当边界出现模糊的时候，需要有个人有主人翁精神站出来协调整个事情。

场景 3：与下属沟通，怎样才是正确的姿势？

再接着看下一个场景，研发同学小明最近感觉很困惑，一边想学习新框架，一边业务需求太多根本忙不过来，天天加班到十一二点，该怎么办？小明对领导大猫“吐槽”，这时候大猫可以有三种思维方式：

第一种思维方式是理性统领。他会觉得每个技术人都会经历这样的阶段，慢慢地熟悉和习惯就好了。所以对小明的疑惑，就随便应付一下。

第二种思维方式是感性统领。大猫会问小明是不是最近状态不好？那你回家好好睡一觉，明天再战。但是这么做其实也不能从根本解决问题。

第三种思维方式是同理关怀。大猫会帮助小明分析，为什么想要学习新框架？知识获取来源于哪？哪些需求是紧迫且重要的？是不是有些需求可以放到二期来做？作为团队领导，应该切实去帮助员工解决问题，而前面的那两项基本没有什么用。

我们还是拿研发团队领导大猫来举例。大猫说，你应该在上线后确认 checklist 里的内容是否执行到位，观察上线一小时后才走；你要看一下 CPU load 是多少？Disk 是多少？这可能是技术人一直以来的沟通方式，但现在是作为领导来沟通，如果总是以这种形式，大家会心里有什么感受？

这就是我要讲的同理心，更多时候是倾听，那倾听应该要注意什么？我觉得要注意两点。

第一，放下假设。我在每次和我的团队成员去沟通的时候，我必须放空自己，把所有的假设全部去掉。

第二，要注意倾听。在倾听过程中呢，一定要站在对方的视角，只有站在他的角度，才能正确的帮助他来进行分析。

场景 4 ：如果下属工作走偏了，该怎么办？

这里有另外一个场景，领导大猫问小明这个季度主要做了哪些工作？小明回答说做了一堆的需求，每天都忙成狗。大猫接着问下周的计划？小明说，持续学习，比如我在做 Nginx+Lua，想在前面加一层网关，或者也可以看看 Open resty 的源码吧。

很显然，小明是没有清晰计划的。这时候就需要领导来引导下属进行目标管理。这个目标管理，不只是简单的 OKRS，并且我们一定要细化。

针对不同的目标，我们把它细化为门槛是什么？目标是什么？挑战是什么？这些都不能是统一一个标准。同时应该对定性和定量做一下区分，并且要给它们做不同的权重。

做到这些以后，每天做的工作都要对它进行细化，每天强迫自己做一个总结和计划，每周、每月、每季度都应当如此。当你自己对这部分内容能不断的给它做总结和反馈的时候，你慢慢地就发现你在这个过程当中成长了很多。

还有一个就是部门沟通。在部门沟通和汇报的时候，一定要注意结构化沟通，就是要结论先行，然后再逐层次细化。

场景 5 ：领导的职责界限在哪里？

还是拿场景来说，研发团队领导大猫说，要做一款时效类的产品，为了足够快只做到本地缓存就可以。小明听了之后说，本地缓存是有限的，JVM 的 Max 对内存不确定得配到多大才足够，否则容易导致 OOM。大猫想了想说，那就做内存集群。小明回答说，如果做个内存集群，那就可以做 Shard 和 schedule，那为什么要做一个这么复杂的集群？

作为一个服务型领导，你不应该事无巨细，你需要做的是确定每一个边界设计合理的检查点，在风险来临之前及早地发现它，并且尽快地解决它。假设你交给小明一个任务，小明不能把它完成得很好，这时你不要让另一个人替代他的工作，否则小明会很有挫败感。最好的办法是找个人和小明一起分析，以小明为主来向来进行汇报，这样更有助于小明的个人成长。

刚才说的这个例子就是动机债的问题，那么什么是动机债？

作为一个领导来说，首先要做好方向上的指引，确定好方向，定好边界和检查点后交给团队成员。当然，对于风险要有预判性。比如这个成员可能会遇到什么样的问题，可以找谁辅助，在什么阶段辅助等等，这些都是要提前规划好的。

其次是员工满意度。团队领导必须做到言必行，行必果，它的每一个承诺必须得如实来履约。最后，是一定要做适当的授权。授权的意义是培养有潜质的成员成为新的领导，来承担更多的责任。同时还要注意，因为工程师心理都“很脆弱”，所以一定要注意他在组织中的地位，要让他感觉到自己是不可或缺的一部分。

作为全栈团队的领导，如何激励团队和创新？

我的场景故事分享完了，其他部分是一些小枝节，全栈团队基本是一个有差异性的团队，它是由不同水平的成员构成。针对这样差异性的团队，我们需要给它营造一个比较好的环境，有利于成员发挥创造力和灵感，能进行及时的思考和反思。

比如说组织复盘或者做一些创新游戏、破冰游戏等等来调动团队气氛，我认为这是作为 Leader 是非常重要的。其次，差异性的团队应该从三个方面来综合考虑，一是自主权，二是能力，三是地位。

我们要明白每一个人都是独立的、不可替代的。不是说谁代码写得快，谁就是团队里最好的。在此基础上还要保持一定的秩序，在某些方面要做到公开透明。比如说绩效，谁是 A 谁是 C 都要做到公开透明。

对于成员来说，有时候可能需要你和他做深入沟通，要做一对一的专项辅导。对人才的梯度建设，京东有一个五星管理法就是把人分为金子、钢、铁，以及铁锈这四个部分。

· 金子是最好的，能力和价值观是最棒的；

· 80% 的人都是钢，就是价值观很好，能力一般；

· 铁就是能力可能一般，价值观还不错；

· 铁锈可能能力很棒，但是价值观不行，这种人一定要第一个从团队中把他踢出，他一定会影响到整个团队士气，非常可怕。

在观察成员的时候，我们需要注意某个成员是如何处理人际关系，包括处理组织内部关系和组织外部关系，处理个人和 HR、IT 运维支持之间的关系，这个一定能反应出来这个人的综合素质。如果他在各个方面都处理非常好，那么这个人一定是个非常不错的人。

以上都是激励团队和成员的一些方法，接下来是说创新。创新是发展之本，那么具体该如何做到呢？

· 持续地解决问题；

· 团队之间一定要善于分享，彼此肯定；

· 善良勇敢。

这些是每个团队里面大部分人都应该必备的一些因素。在有节奏冲刺的时候，我们需要做到团队目标和规则清晰，主动参与并能做到积极的反馈，这样才能成为团队创新之本。

今天我把试图打造全栈技术团队之路上的一些经验和踩过的坑分享给大家，未完待续，全栈团队，我们依旧在路上。

---

TGO鲲鹏会，系极客邦科技旗下高端技术人聚集和交流的组织，旨在组建全球最具影响力的科技领导者社交网络，线上线下相结合，为会员提供专享服务。目前，TGO鲲鹏会已在北京、上海、杭州、广州、深圳、成都、硅谷、台湾、南京、厦门、苏州十一个城市设立分会，武汉分会即将成立。现在全球拥有在册会员 740 余名，60% 为 CTO、技术 VP、技术合伙人。

会员覆盖了 BATJ 等互联网巨头公司技术领导者，同时，阿里巴巴王坚博士、同程艺龙技术委员会主任张海龙、苏宁易购 IT 总部执行副总裁乔新亮已经受邀，成为 TGO 鲲鹏会荣誉导师。

如果你想和这些优秀的科技领导者们一起前行，欢迎点击「报名表单，申请加入」。