20-技术领导力300讲

开篇词 | 卓越的团队，必然有一个卓越的领导者

管理大师彼得·德鲁克说：“组织的目的，就是让平凡的人做出不平凡的事。”然而，不是任何一群平凡的人聚集到一起，都能做出不平凡的事。甚至一群优秀的人聚集到一起，也可能只是一个平庸的组织。

因为，大到一个国家，小到一个团队，任何一个卓越的组织，都必须有一个卓越的领导者。领导者是一个组织的灵魂，在很大程度上决定了组织所能达到的高度。

技术团队同样如此，管理者的战略眼光、管理方法、人格魅力等，都会给团队的工作结果带来决定性的影响。

但技术管理者面临的具体问题又有其独特之处。虽然 CTO、技术 VP、技术总监等职位的职责各有偏重，但总的来说，技术管理者对内要负责技术选型、产品功能实现、团队成员培养、技术人员考核等等；对外则要承担扩大公司技术影响力、为公司招募更多优秀研发人员，发展潜在客户等职责。

因为工作关系，我们有机会经常与技术管理者交流。在这一过程中我们发现，技术管理者面临的问题往往是相通的，每一个技术人在通向技术高管的路上都要趟过无数个坑。比如“如何与其他部门的负责人高效沟通？”“如何制定科学的绩效考核方法？”“面对新的技术趋势应该如何布局？”“怎样做好技术人员招聘？”等等。

关于这些问题，通过其他优秀的技术领导者在实践中总结的方法论来学习和提升，是最为高效的方式。因为人类之所以能够取得今天的成就，就是因为我们可以通过阅读等方式，不断地在前行者的基础上再进一步。

而即便你已经一路升级打怪，成为了一名优秀的 CTO，你仍然会面临许多挑战：行业格局瞬息万变、技术浪潮风起云涌、资本市场残酷善变，更不要说公司新加入的高管很可能与你气场不合，你与公司商定的股权分配方案可能存在隐患……

在这一背景之下，极客时间推出了“技术领导力 300 讲”专栏。这是一个针对技术高管的付费专栏，由阿里、腾讯、AWS 等上百家知名互联网公司的优秀技术领导者和 CEO 共同贡献和维护，专栏内容涵盖前沿技术、趋势分析、团队管理、软性技能等技术管理者关注的重点问题。该专栏希望通过体系化、有洞见的课程来帮助技术管理者提升认知，升华自我。

“技术领导力 300 讲”专栏中的每篇文章，都是这些身经百战的管理者们基于实践经验的总结和提炼。专栏作者中，有些曾经获得“最具价值 CTO”的荣誉，对于团队管理有自己的独到方法；有些从 CTO 进阶为 CEO，对于 CTO 和 CEO 应该如何相处有着深刻理解；有些带领技术团队从无到有完成核心系统架构，助力公司业务实现百倍增长……

每周五，我们还将邀请一位技术大神或互联网大佬，回答你感兴趣的问题。他们将以更高的高度，带来不一样的资讯和思辩。一些以往只能在新闻里看到的名字，你也将有机会与他们直接对话。

我们将陪伴你一整年的时间，用六大模块为你详解技术领导力：

一、格局与战略。这部分内容将帮助你打开视野，理解卓越技术领导者的核心能力的概念和价值，像 CEO 一样思考商业，让技术与商业战略协同，确立管理者能力模型。

二、团队管理。这部分涵盖人员招聘、绩效考核、团队文化建设、研发管理等内容，将通过大量实战经验，帮你清楚认识领导力提升的有效途径，掌握领导力提升的工具与方法。

三、职场软技能。通过这部分内容，你将了解如何更好地沟通、如何向上管理、如何打造个人品牌、如何管理情绪等等。令你在工作中游刃有余，从此踏上领导力提升的新旅程。

四、跳槽与创业。有时候，选择比努力更重要，所以我们建议你先做好充分的准备。我们将和你一起探讨期权、套现、合伙人、商业模式等话题，让的你人生进阶之路更加平稳。

五、技术趋势解读。让你快速了解最新的技术与趋势，比如区块链、人工智能、运维技术发展到了哪个阶段，你的企业是否还在用老旧的技术解决别人早已经轻车熟路的问题。

六、国家政策解读。一个卓越的领导者，一定是顺势而为的。我们会邀请行业专家深入分析解读国家机构最新发布的产业政策，助力你洞察先机。

希望一年之后，你已经成为了更好的自己。

“技术领导力 300 讲”是一个全年专栏，在专栏的详情页中我们列出了全年六大模块中的具体话题，供你参考。下面是近四周将会具体更新的课程，后续还有更多精彩内容，欢迎订阅。

大咖对话 | 万玉权：如何招到并培养核心人才

你好！

本周“大咖对话”的嘉宾依然是连尚网络副总裁、WiFi 万能钥匙事业群 CEO 万玉权，拥有 10 多年互联网研发和管理经验，目前负责 WiFi 万能钥匙核心产品和技术研发管理及热点画像业务，在连尚网络期间，完成了核心系统架构从 1.0 到 2.0 的改进。

上周，我们和他聊了 CTO 到 CEO 的转变之路，以及高效团队打造等话题，其中谈到人才管理时，万玉权认为“兵不在多，而在于精”，本周，我们就跟他深入聊了聊他对于人才战略的认知。

极客时间：在您看来，人才成长过程中，最重要的特质是什么？

万玉权： 总结一下，可以归纳为“明确目标，享受过程”。

首先，在职业发展路径中，无论是初入职场的新人，还是企业的领导者，都需要明确自己的目标，这就像航船需要知道灯塔的位置一样重要。只有明确目标，才能够知道自己前行的方向。

同时，在这过程中，你的目标不要随着时间、职位、薪资等外界因素的变化而变化。这里我举个反例，有些人在职业发展过程中，往往会因为追求高薪资、年终奖、特斯拉等附加物质，而改变自己的目标，最终导致迷失方向。在我看来，这些都是不可取的行为，当你的事业目标达成之后，这些附加物质自然会随之而来。所以，确定你的目标，坚定并坚持去实现它。

以我自己为例，2013 年，我加入 WiFi 万能钥匙，从最初的程序员到技术经理再到现在的事业群 CEO，我的目标一直很笃定，就是希望能够在这个平台上实践属于自己的架构思维和技术理想，研发出服务千万级甚至上亿级用户的产品。最初，确立这个目标的时候，作为程序员的我认为，能够做出这样的产品很牛，而尽管之后的职位一直在变，我的这个想法也没变过。

其次，在实现目标的过程中，要学会享受。打个比方，我将自己比作一名舞者，练了十几年基本功，现在，我想在 WiFi 万能钥匙这个舞台上跳一段舞，并尽情享受这跳舞的整个过程。我一直都以这样的状态面对工作，面向目标，乃至于到现在，尽管我已经不写程序，已经转向管理了，我依然享受每天所经历的事情，无论过程开心与否，对我来讲，都非常有价值，因为每一天，都是向着目标前进的一天。

对于我的团队，我也是按照这两点来要求大家，要求每个人都明确自己的目标，并学会享受实现目标的过程。事实证明，这对于提升团队效率非常有效。

WiFi 万能钥匙里有很多 13 年、14 年就加入跟随团队的老员工，他们像我一样，在这里历经了不同的岗位，接受过许多新挑战，他们都一步一步实现了自己的目标，比如从最初的程序员，到现在成为技术总监、技术 VP。他们很清楚自己在这个地方要做什么，也时常跟我聊天，一起沟通自己在这个团队的目标与发展路径。

极客时间：以您的经验来看，如何招到合适的人才呢？

万玉权： 公司长远发展的核心推动者是人才，我个人认为，兵不在多，而在于精。所以，我们非常注重人才的挑选与培养。挑选人才时，我们主要看重两点，第一点是价值观，第二点是能力。

首先，最重要的考核因素就是人才的品质，即价值观。如果员工的价值观与公司不符，即使能力再强，他也很难真正为公司创造多少价值。

具体在面试中，可以考察候选人对之前公司的企业文化的看法及认同程度，还可以考察他对之前公司制度的遵守程度，或对企业文化的践行程度。可以让他举一些实际的例子来说明。

其次，要考核的是人才自身的能力，是否能够胜任本职工作。其实，简历经过筛选之后，挑选出的多数人都是合格的胜任者。如果在实际工作中，他难以胜任，基本都脱离不了两个原因：一是价值观偏差，工作态度问题；二是之前的工作经历和方向与新工作不太匹配。

但是，在招人时，你很难保证，你招进来的人或被你拒绝的人就一定合适或一定不合适，所以出现了试用期。对于人才管理，必须依靠制度，依靠流程，依靠规范。

在试用期阶段，我们会定期与新人沟通，比如入职一周后沟通一次，入职一个月的时候沟通一次，入职三个月的时候再聊一次。尽管现在团队已经很大了，但对于新招进来的中层干部或专家类人才，我依旧会亲自与他们定期沟通，而其他岗位的员工，就由相应部门的负责人进行沟通辅导。除了直属领导的沟通， HRBP 也会定期与新人沟通，帮助他们解决疑惑与工作中遇到的困难。

另外，新人会有一名专属导师，帮助他熟悉公司流程，熟悉业务情况，制订阶段性目标、绩效和计划等，并根据完成情况去做综合评判。如果发现价值观明显不符，我们会先帮助他进一步了解公司的文化与价值观；如果是工作岗位不匹配，我们会先对他进行调岗，帮助他再一次尝试。

如果在诸多尝试之后，新人依然不能胜任工作，我们也会主动解聘。还有一种情况是员工踩到公司的红线，比如贪污受贿、数据泄密、威胁公司信息安全等，那么，无论是谁，价值观匹配度多高，能力多强，都必须马上终止劳动合同。

极客时间：在人才招进来之后，您会如何对他们进行培养？

万玉权： 在人才培养方面，我的观点是先成就员工，再成就团队，最后成就企业。我们要给每个员工足够多的成长机会，让他对公司有归属感，找到自己的目标与追求，认为在这里无论是输入还是输出，都有价值。

每个人都有长板和短板，在用人时，要看到大家的长板。当我需要达成某个目标的时候，就要找出拥有这方面能力的员工，再依据每个人的特长进行目标拆解，使结果达到极致。

待目标达成之后，就要抽出时间与精力找到每个人的短板，再通过内部经验分享、读书交流、业务培训或参加类似 TGO 这样的技术交流平台，帮助员工提升。

在我看来，作为一名管理者，需要同时注重员工的长板效应与短板效应，并主动沟通，了解他们的诉求与困难点，对症下药，帮助他们提升自己，以此提升团队战斗力。

目前，对于短板较明显的同学，我们更多的是以一种辅导的方式，帮助他成长。同时，我们也会跟他积极沟通，看他是不是愿意调岗，毕竟很可能另一个岗位就是他的长板所在。

不同公司对调岗的的做法不太一样，比方在腾讯，员工入职两年后，会强制要求轮岗。不轮岗说明两个问题，要么是他能力不行，只能在这个岗位；要么是学习态度不行，或学习能力不行，综合来看就是不符合公司的人才要求。

而 WiFi 万能钥匙对于员工的发展不会设限，不强制固定岗位，也不强制轮岗。只是我们过往的实践中，发现很多人在岗位的转变过程中，获得了很多成长。

举个例子，我们团队中有一名部门负责人，最初是测试人员，只负责产品测试，但他做事认真细心，且责任心强，有强烈的责任感，除了做好本职工作，他还会去考虑整个产品相关的工作，比如从产品研发到运营，再到用户数据分析等，都愿意去思考。另外，他还经常主动与团队沟通，各方面表现都非常好，初步具备了团队 Leader 的条件。

在这种情况下，你需要给他足够的机会，让他去尝试。可能刚开始尝试其他岗位时，他会有些迷茫，有些不知所措，与之前的表现也相差较大，但这时，你应该主动帮助他，给予他指导，经过几个轮回的试炼，他就会迅速成长，真正做好 Leader 这个角色。

可以说，任何人的成长路径都是之字形，所谓之字形成长，就是从一个点盘桓旋曲而上至另一个点，在这过程中，需要经历许多磨砺。因此，对于内部的人才培养，也应该本着这样的态度与方式。

大咖对话 | 万玉权：高效团队的关键，以目标为导向，用数据来说话

你好！

本周作客“大咖对话”的嘉宾是连尚网络副总裁、WiFi 万能钥匙事业群 CEO 万玉权，拥有 10 多年互联网研发和管理经验，目前负责 WiFi 万能钥匙核心产品和技术研发管理及热点画像业务。在连尚网络期间，完成了核心系统架构从 1.0 到 2.0 的改进，以及推送系统、数据采集、账户系统以及分布式搜索、分布式存储、分布式缓存等系统的设计和研发。

极客时间：您从 CTO 转变为 CEO，在这个角色转变的过程中，您有哪些思维和认知上的转变？

万玉权：2013 年，我加入 WiFi 万能钥匙，从最初的程序员到技术经理到事业群 CTO，再到现在的事业群 CEO，一路走来，其中的变化都经历过。

CTO 与 CEO 的区别，有一句很通俗的话，即“CEO 吹过的牛，CTO 要将它实现”。另外，CTO 以技术为主导，他的责任比较明确，主要是通过技术实现各种需求，关注技术趋势，平台战略实施和技术团队的培养等，其他的事情都有 CEO 在前面帮你担着。

而 CEO 负责的范围会更广，除了公司的日常管理之外，还需要负责技术、产品、商务、运营、数据等诸多方面。更重要的是需要清楚公司的战略方向，所以，对 CEO 综合能力的要求会非常高。

在我看来，CEO 的视角要更宏观一些、看得更远一些，要多去思考公司战略与整个行业的变化情况。至于一些具体的执行问题，则可以丢给下面的团队去做，这样，我可以从具体的事物细节中抽身出来，他们也能得到更多的锻炼机会和成长空间。

很多管理人员会进入一个误区，他会去享受权利带来的快感，却不知道怎么培养团队成员。在我看来，一名合格的领导者，不在于自己的能力有多大，而在于能够培养出多少更优秀的人才；也不在于自己能够做多少事，而在于能带领团队做多少事。一个人一天不眠不休也只能工作 24 小时，但如果能将方法传承给团队，培养出 10 个和你一样优秀的人，那工作效率就能够翻 10 倍。

极客时间：在角色转化过程中，您如何提升自己，弥补短板？

万玉权：一个很真实的体会是，要跟老板多汇报，多总结、多思考，再跟团队多交流。

从一个角色转化到另一个角色，更多的是熟悉的过程。以商务为例，之前，程序员出身的我跟商务之间的关系是“八竿子也打不到一起”。当这样一个团队交托到我手上的时候，我心里是很没底的。

但万变不离其宗，关键是抓住其本质，即目标。商务团队必然是有明确目标的，而有了明确的目标后，事情就好做了。毕竟我作为 CEO，并不需要深入到具体的执行层级，而是要站在一定的高度，把目标拆解清楚，然后跟商务团队确定要在什么阶段实现什么目标，有哪些资源可以使用。至于具体怎么落实，怎么达成目标，就可以放权给商务团队的负责人，让他放手去做。

我从技术经理到 CTO，再到 CEO 的转变过程中，都是在用这样的方式解决问题，即先明确目标，再拆解成具体的执行步骤，然后制定一个标准要求自己，最后不断思考、细化、总结自己的学习方法。

另外，之前我提到要跟老板多汇报，很多技术人可能在向上沟通上存在一些疑惑。对此，我的建议是，客观、真实地反映现状。

因为工作不是一锤子买卖，需要你踏踏实实的做业务，无论业绩是好是坏，你都要如实反映你的情况。同时，一定要思考清楚业绩差的原因，总结经验教训，并提出下一步的解决方案。你把症状和解决方案都说清楚，老板才能认可你的提议。当然，如果数据增长，也需要总结出促进增长的原因，并且要能表达清楚。

在实际中，不能只汇报增长，不汇报下降，也不可以将功绩放大，把问题缩小，这些都是不可取的行为，非常不利于公司经营。因为，数据偏差容易导致老板误判业务的实际情况，最终影响他对业务的决策，更严重的可能会影响到公司整体的战略。

另外，真实、客观地反映问题，让大家知道业务真实的发展情况，还能得到其他与会者的建议，他们能从另外的视角给你一些建议，帮助你找到盲点，更加全面的分析问题，沉淀总结出属于自己的方法论，帮助你进一步的成长。

极客时间：您现在负责 WiFi 万能钥匙的产品和研发管理，关于打造高效团队，能分享您的经验吗？

万玉权：目前 WiFi 万能钥匙有 1000 多人的团队，其中技术团队占到一半以上，要管理这样庞大的团队，是一个非常大的考验。从我的经验来看，可以从三个方向出发来提升团队整体效率。

1. 明确目标，并拆解目标

作为领导者，一定要结合公司战略，明确当前阶段的目标，这是根本。团队目标都是根据企业战略而来的，在企业的整体战略中，各个团队需要发挥哪些作用，为企业创造哪些价值，会被考核哪些成果……所有这些形成了团队目标。

以 WiFi 万能钥匙为例，今年我们事业群就一个核心的业务指标，而这个指标从集团下到我这里后，我就需要对这个目标进行拆解。

目标必然会导向某个结果，而达成结果的过程必然可以被拆解成不同的步骤。拆解目标的过程，关键是要结合产品或业务，以 WiFi 万能钥匙为例，我们要经过新增、活跃、留存等五个步骤才能得到预期的结果。因此，我们就可以把目标拆解成这五个步骤，并确定每一个步骤需要负责的工作，以及工作的产出，例如每一个步骤完成后的转化率。

2. 重组团队

目标拆解完之后，就要调整组织架构，重组团队去对应相应的目标。

现在互联网公司比较流行两种组织结构，一种是按照职能划分，一种是按照垂直的业务划分。之前提到，我把目标拆解成了 5 个步骤，我就把这 5 个步骤划分给 5 个不同的团队去做。这样做的好处是，每个团队的目标非常明确，考核的 KPI 也非常明确。团队成员也会比较清晰和聚焦，能够劲往一处使，只要想着把事情做好就好。

在重组之前，我们团队是典型的按照职能划分，因此，一个团队可能会面对各方的多个需求，比如技术团队，就会有不同产品的不同需求汇聚过来，而技术团队也只是被动的接受这些需求，想的也只是按照要求及时交付。

而重组之后，从产品经理到研发负责人，到下面的研发团队、测试团队等，整条线上的不同功能的员工是一个小团队。而这个团队就背起属于他们的业务指标，对一个非常明确的 KPI 负责，也不会被各种各样的需求给扰乱到，每天耽误在各种沟通、扯皮中。

这样做的好处是，首先，技术团队有动力去深度钻研，打个比方，除了产品，研发在设计技术架构的时候，也会去思考，这个功能加进去，能不能对团队的核心指标有帮助。大家的方向一致，做某一个功能点，他的第一反应是，这能不能促进我的业务目标，即转化率的提升，能的话就继续做；不能的话就需要再仔细衡量。以往，这可能仅仅是产品需要去思考的东西。

作为领导者，我非常清晰的感觉到，团队从之前只是为了完成任务的做事方式，到现在变成了有明确目标的，自驱动的做事。大家都会自下而上的主动去想这件事情到底要怎么做才能做好，团队整体效率得到了非常大的提高。

同时，好多可做可不做的功能就会在这个环节中被过滤掉，最后的效果是，团队做事情会比原来更有深度。

我们是在今年第二季度实行了这样的团队重组，也见证了这种模式的好处，在如今 Wi-Fi 万能钥匙这么大量级的基础上，我们在第二季度又实现了 10% 的增长，这是一个了不起的成绩。

3. 以结果和数据说话

值得注意的是，每个步骤所需的团队规模不一样，可能第二个步骤只需要三四个人，一个产品带三个研发就能搞定，但你必须给他确定明确的职责，定下明确的 KPI，让他去做这个事。

在拆分完的步骤中，可能最前面做增长的团队，跟后面做活跃的团队、做留存的团队没有什么关联，但他们都在一条线上，从最后的考核结果来看，我能够考核每一步的转化率是多少，然后根据这个考核结果来分配每个团队奖金的权重。

因此，在实际执行中，如果发现某一步的转化率特别低，负责人就要及时同步数据，一个一个环节去突破，最终找出问题的根结所在，然后不断调整策略，去提高该步骤的转化率，达成最终的目标。

有了数据之后一切就非常清楚，不过你过程中做了什么，我们就拿数据、拿结果来说话。这也符合我们价值观的数据至上这一点。总的来说，以目标为导向，用结果来说话。所有任务都要确定目标，都要做到有数据来量化，不管是哪个岗位。

当然，在这个过程中，还需要注意防止唯 KPI 论的出现，防止团队为了实现业务指标而为所欲为。这就需要更好的践行公司的价值观，剔除不符合价值观的行为，同时，我作为领导者也要做好把关工作。

实行团队重组后，我能明细感觉到团队成员的自驱动性明显增强，团队效率也显著提高，我也要比去年轻松很多，能抽出更多时间来思考更多战略、行业相关的问题。最终，我们要达成的目标是，变管理为服务，变管控为赋能，将想象力与创造力归还给员工，使员工发挥自驱能力去完成目标。

大咖对话 | 不可替代的Java：生态与程序员是两道护城河

你好！

本周作客“大咖对话”的嘉宾是杨晓峰，他目前是 Java 核心类库北京团队 leader，首席工程师。2011 年加入 Oracle Java 团队，经历了从 JDK 7 到 JDK 11 的研发过程，目前领导 Java 核心类库北京团队，专注于 JDK 核心类库新特性的测试和开发，希望对 Java 技术的演进和普及做出贡献。

极客时间：目前您的工作中，技术和管理各自占的比重大概是多少？有什么心得？

杨晓峰：技术和管理各占一半一半，因为我不做人事管理，更多的是属于技术 leader。Leader 和 manager 是不同的，对 leader 来说，一方面思考更多的是团队未来的技术路线图，并要做好短期和长期的计划；另一方面要让团队有士气、让团队出成果，每个人都清楚自己的目标，实现自己的价值。

首先，作为技术上的带头人，一定要弄明白未来的方向什么是对的、什么是错的。这个对错是带引号的，并非那种绝对的对错，而是要清楚公司整体的目标与未来一段时间内的规划，作为 leader 定出的路线图要与部门或是公司的整体方向保持一致。

如果 leader 对目标的理解有偏差，很可能团队辛辛苦苦做事，最后却得不到认可，这是很伤士气的。因此，在具体的操作上，作为 Leader，会积极地去和我的上级和合作团队去沟通，保证我带着大家走的路是没有走偏的。

其次，我所涉及的管理，更多的是让团队出成果、有士气，攻克前路上的难点，而有成果是有士气的保证。比如现在我们的目标，就是把 JDK 11 发布计划里的内容，按照既定周期把相关任务高质量的完成好。

在具体执行中，我的原则是不能把目标设定的太大，即使是一个大的目标，最好也采用迭代的方式，把它拆分成一个一个小的可验证的里程碑。这样做的好处是团队能一直看到成果，了解自己所做事情的价值，否则人是很难保持一个长久的状态的。如果在被认可之前走太久的话，难免会感觉到倦怠与疲惫。

这些都是一些实际执行中的做法，并没有太多高大上的东西，但对我来说，带团队就是这样一步一步踏踏实实往前走。

当然，每个产品的要点不一样，对 Java 来说，质量是首先要保证的，对质量的要求会远远高于对数量和对速度的要求。因为 Java 是一个非常基础的平台，它也是整个 Java 生态的基础，一旦它出了问题，就会波及在它之上的所有工具、产品、厂商，影响会非常非常大，因此基础平台必须要谨慎。

但对于创业期的产品来说，可能会以一些可接受的质量代价来换取速度，这些都是要看实际情况来判断的。

极客时间：Java 已经更新到版本 10，但有调查显示目前绝大部分的程序员仍在使用 Java 8，不知道这一数据是否准确？判断是否迁移需要考量哪些关键因素？

杨晓峰：的确是这样，目前大部分用户还在使用 Java 8，还有人在使用 Java 7，甚至是 Java 6，但与此同时，新版本的热度和接受度在不断提高。主要原因有以下两点：

第一个原因，语言版本升级从来不是个一蹴可就的事情。Java 是一个基础平台，它的生态中包涵大量类库工具，比如 Maven、Spring、Guava 等，还有各种基于它的基础产品，比如 Cassandra、Hadoop 等。

对一个严肃的厂商来说，升级不是一个简单的事情，选择升级 Java 的前提是所有主要开源类库、软件、第三方厂商产品都已经支持了新版本。很高兴的是，目前主流的项目都已经逐渐完成了对 Java 10 等新版本的支持。除此之外，还得考虑新版本中有什么特性是自己必须的，能对自己的效率产生很大提高的，还有安全、性能等不同角度的考量。而这个过程必然是需要一定时间的。

第二个原因，在过去的发版模式里，Oracle 为每个大的 Java 版本都提供了长期升级，JDK 8 按目前计划至少到明年年初才会停止免费升级，相当于免费升级了 5 年。坦白说，对比主流产品，Java 的免费支持周期，从任何角度来说都不能算短，背后是厂商大量的、持续的、默默无闻的投入。

如果想升级的话，成熟的 JDK10，或者即将发布的 JDK 11 都会是一个好的选择。例如，JDK 11 是一个长期支持版本，按照目前的发布计划，它会有非常长的支持周期。这是一个非常重要的考虑因素，Java 这么多年起起伏伏，但却能一直稳定保持在编程语言第一的位置，跟背后有一个可信厂商的持续投入是分不开的。

另外，从新特性的角度出发，新版本里，从强大的 ZGC、更好的 G1 到基本的字符串改进，再到各种基础类库、协议，各方面都有非常大的提高，不是修修补补，而是本身能力的巨大提升。因此，虽然升级到新版本会有一些学习曲线，但一定是值得的。

极客时间：现在很多新语言都极具冲击力，您能谈谈 Java 目前面临的最大挑战，以及未来的发展趋势么？

杨晓峰：虽然现在各种新语言活跃，但我认为 Java 面临的最大的挑战并不在于外部语言的冲击，而是计算模式和场景的变化。

过去十几年里，Java 平台主要的投入都致力于让它可以在那种大吞吐量的、长期运行的服务器端跑的好。

但云计算兴起后，微服务、Serverless 等新的计算模式对编程语言的技术要求变成支持快速启动、高数据密度、短时间运行的工作负载等。另外像大数据、人工智能、深度学习这些领域，会更看中语言对数据的运算能力等。

而这些方面恰恰是 Java 仍然需要进一步改进的。目前，Java 也在不断精进、不断加强这些方面的能力，比如 Amber，旨在大大改善 Java 的开发效率，让语法变得简单，更加符合现代的编程思维；比如 Valhalla，旨在提高 Java 的数据处理能力，支持更加高效的数据处理和复杂数据类型等；比如 Panama，旨在解决和本地代码交互的效率等问题；比如 Loom，旨在让并发相关的开发变得更高效和平易近人，还有引入 Fiber 等类似协程的机制。

除了不断提升基础能力、提升应用性能之外，Java 也在积极做瘦身，去掉一些已经退出历史舞台的技术，甩掉一些包袱，让自己变得更简洁、更高效。

极客时间：您能用一句话来概括 Java 的核心竞争力么？能进一步介绍一下吗？

杨晓峰：Java 最大的核心竞争力来源于全球超过 1200 万的 Java 程序员，庞大的 Java 生态，海量的类库、工具、产品构建的无所不能的竞争力。

从语言特性来讲，Java 有它的优势，比如扩展性、可靠性、安全性、强大的 JVM 等。你可以重新设计一个语言，去掉 Java 的历史包袱，保留 Java 的长处，还能吸收其他语言的优点。然而，Java 已经聚集起来的生态是不可替代的，如果真想替代，那将是一个庞大的不可估量的投资，另外重复制造轮子的价值是什么呢。

很多问题不是靠语言本身能解决的，而是要靠语言衍生出的各种类库和工具，因此，选择了 Java 就相当于选择了一个最可靠的一站式解决平台。比如想搭建微服务框架，在 Java 生态中能找到各种快速搭建的框架和方案，还能找到足够多的优秀程序员。

总结来说，Java 有着世界上最完整的生态、最庞大的程序员群体。目前，从小型设备到超大规模的应用开发中，Java 几乎是不可替代的，真正的大规模系统很少能够离开 Java。

大咖对话 | 从几个工程师到2000+个工程师的技术团队成长秘诀

你好！

每周五是《技术领导力 300 讲》的“大咖对话”时间，本周与我们对话的嘉宾是斑马资本合伙人、原去哪儿网 CTO、TGO 鲲鹏会北京分会会员吴永强。

在去哪儿期间，他建立了世界上访问量最高的旅游搜索引擎。在公司发展过程中，又成功地带领技术团队支持公司转型为以移动为核心的在线旅游平台。在团队建设上，他成功将去哪儿的技术团队从几个工程师扩展到 2000+ 个工程师的规模。

本周，我们邀请他来分享自己伴随公司成长过程中的收获，以及转型投资人的心得体会。

Q：作为 CTO 伴随着创业公司（去哪儿网）一步步成长，到最终上市，你最大的收获是什么？

A：伴随一家公司从小成长到大，是一段奇妙的旅程，途中有欣喜，痛苦，焦虑，兴奋，什么样的场景、困难都会遇到，就如同我们伴随着孩子成长一样，孩子成长的过程，同时也是父母跟随成长的过程。我在去哪儿的工作历程，收获良多，我就挑几个对我影响比较大的说一下：

首先，人是企业最重要的财富和资源，一个公司的成长伴随的是人的成长和团队的成长，一个公司就是所有员工的集合，公司所有人的集合的高度决定了公司发展的高度。所以要能够吸引好的人才，并且让这些人才在企业的平台上不断经历磨练，不断学习，不断进步。作为企业就应该从一开始就重视建立并改进自己的企业文化、激励机制、组织结构，为人才在内部的发展提供动力、平台。

去哪儿技术团队，从几个人开始，发展到两千多人，基本经历几个阶段。第一阶段，是以熟人为主，这时候团队很小，更多是依靠核心人员过去积累的人脉，快速地建立起团队，这时候大家之间都很熟悉、信任，而且都战斗在业务的第一线，通常这个阶段的问题是很小的。

第二阶段是社招为主，这一阶段业务快速扩张，业务的复杂度也快速上升，急需更多的人才加入进来，同时公司有了一定的知名度，也能招到非常多优秀的人才。

这个阶段的问题主要是，人员来自四面八方，各自有各自的文化底色和做事的方法，同时技术分工变得复杂，很多人会离业务越来越远，这个阶段，如何能够保持原来建立的以业务为核心的技术文化不被稀释，同时能够将大家融合在一起，形成合力，是一个技术管理者需要解决的大问题。

第三个阶段，是自己培养人才的阶段，这个阶段主要的人才来自于各大高校的校招。经验告诉我们，这是目前唯一能够大批量招到优秀人才的途径，所幸去哪儿在技术团队只有六十个人的时候就开始尝试校招，这对后面几年公司业务大发展的时候，解决人才的储备和发展起到了决定性的作用。

校招进来的同学的选、用、育、留，又是一个非常不同的课题，我们在这些同学身上花了大量的时间和资源，做了很多不同的尝试，去培养他们技术、管理、业务等多方面的能力，很高兴看到的是，目前去哪儿网的大部分中坚力量都来自于我们当年的校招。

其次，技术部门的定位问题，我向来认为业务是一个企业的核心。业务的发展壮大是保证技术部门得到足够投入并得到发展的关键。那么如何扎根于业务，同时对业务有自己的深刻的洞察，就是一个技术管理者日常最重要的工作。

技术的积累和发展有自己独特的规律和步调，必须对业务目前和未来面临的技术挑战有一个清晰的认识，技术部门就有了当前运行的重心，也能对未来的挑战做技术和人才上的储备。在业务的挑战到来的时候，才不至于临时抱佛脚。

另外，一个企业的发展历程如同一首交响乐，各个部门在不同的发展阶段，所处的位置和扮演的角色是不同的，如何能够在企业不同发展阶段，对技术部门进行准确的定位是非常重要的。

在轮到技术部门作为主角的时候，就要勇于承担责任，发挥技术部门的优势，促进公司业务的发展；在轮到做配角的时候，也能安心、全力支持其他部门的工作，踏踏实实做好技术的积累和对未来的准备工作。只有这样，企业才能快速、和谐地向前发展。

Q：对于技术人拓展个人能力，你有哪些建议？

A：我想讲讲我自己认为的一些比较有意思的建议：

懂业务，我经常开玩笑说，懂业务的技术，就像流氓会武术，多懂些公司的业务，会对我们日常跟产品、业务部门的沟通有很大的好处，也能看得懂各种业务上的变化。对自己在技术上的判断有特别大的帮助，特别是在优先级、重要性的判断准确性上，是那些不懂业务的技术人所不能比拟的。

通常一个懂业务的技术人，在公司的发展速度都是比别人快很多的，而且也比较容易晋升到关键岗位。即使是换工作，选择加入哪家公司，又或者去创业，一个懂业务的技术人，大家可以想象会有多少优势吧。

深度 / 广度并重，我认为人的知识要形成 T 字形的结构，有一个专长的方向，这是一竖，同时要掌握相关的知识，这是一横，这两个方向是相互促进的。

没有一定的宽度，其实你的专长深度是有限的，没有一定的深度，横跨的知识就会很松散，而且很难形成结构，大家应该都有这个经验，你在一个方向感到进步很慢，去涉猎一下相关的知识，很多时候就能帮你打开原来方向的困局。

现在的技术工作分工很细，我觉得这是计算机技术发展到成熟阶段的标志，但是技术人自己不能被分工所束缚，简单举例说，你做前端工作，光会前端技术会极大限制你的发展，跟前端相关的操作系统、网络、硬件、产品的基础知识都是需要涉猎和掌握的，而且能把这些知识形成有机的结构。

我遇到过的大牛，都是有这样的知识结构，甚至都对人文，历史有一定的研究，他们把知识当成一个体系。

人的技术，一个技术人的发展，不可避免会遇到人方面的问题，尤其对高端技术人的发展非常重要。高端技术人的日常工作大概是 40% 跟人相关，30% 跟业务相关，剩下 30% 才跟技术相关。我认为掌握人的技术，有两点非常重要：一是懂表达，二是懂尊重。

懂表达就是如何能将自己的理解用大家容易接受和理解的方式表达出来，这个对于建立和扩大自己的影响力非常关键。

懂尊重，就是要帮助他人成长，好的技术人都容易有英雄情结，视比自己水平低的人如草芥，沟通基本以鄙视为主，所以必须从内心深处尊重其他人，才能建立和发展好一个技术团队。

Q：离开去哪儿之后，你成了一名投资人，转型过程中你遇到过哪些障碍？

A：确切说我目前还没有做大的转型，如果让我选择，技术和投资之间，我一定毫不犹豫选择技术。因此目前在投资方面我依然侧重于技术，以及帮助我们投资的公司的技术团队如何能运作得更好。

和在企业做事不同的是，投资有他独特的知识结构以及运作流程，这部分我之前基本是空白，所以现阶段，能做和正在做的就是努力向有经验的同事学习，希望自己能够早日“毕业”。

另外，作为一个技术人员，我跟很多工程师一样，思考问题相对保守，同时习惯于在过程中不断收集信息，学习知识，积累自己对这件事情的信心，这个和投资非常不一样，投资相对来说更加宏观、更加趋势性，时间点也更加急迫，就需要你作出抉择。当然成熟的优秀投资者都有一套自己的方法论来处理这些问题，但这个的确是我目前正在努力去适应、学习和解决的最重要的障碍。

作者简介
吴永强，斑马资本合伙人兼董事总经理、原去哪儿网 CTO、TGO 鲲鹏会北京分会会员。专注技术管理、大数据、云计算等领域，并具有非常丰富的实战经验。

大咖对话 | 以产生价值判断工程师贡献——读者留言精选

你好！

欢迎来到本周的“大咖对话”环节。不知不觉，“技术领导力 300 讲”专栏已经更新了 4 个月，走过了三分之一的路程。

在这四个月里，我们邀请到了近 40 位 CTO、技术 VP、有技术背景的 CEO 等技术领导者来分享他们的实践与经验，话题涉及技术领导者的核心能力、高效技术团队的打造、高效研发流程的建设、技术团队的考核与激励、技术团队文化的建设、空降管理者该如何平稳落地、技术领导者的产品思维等多个方向。

不少读者踊跃留言，分享了他们的观点，也留下了他们的疑问。本周的“大咖对话”环节就筛选出了往期留言中具有代表性的问题，并邀请了相应的大咖来回答。你可以点击文中链接，回顾之前的文章。

在《如何高效管理 8000+ 规模的技术团队》一文中，有读者留言问道：“文中提到要打造一个数据化管理体系，把 IT 管理的对象数据化，想请教一下，数据收集的具体维度是什么呢？如何衡量一个工程师的贡献度到底有多大呢？是看代码量，修复 bug 数量，还是攻克关键问题的数量等，能分享你们的具体做法么？”

苏宁易购 IT 总部执行副总裁乔新亮：我们数据收集的维度分两个方向，第一个是数字化资产，第二个是工程师对数字化资产的贡献。

首先，数字化资产会包括产品、系统、服务等资产，以服务中的用户体验为例，它的数据化考量维度就是响应速度快不快、异常情况多不多、服务可用性高不高、响应时间的 SOA 满足率怎么样等。

其次，每一个数字化资产都会对应到某个工程师或工程师团队，他们会负责这个数字化资产的开发、测试、维护等，因此，衡量工程师的贡献度，是从结果出发的。读者提的问题可能更多的是站在开发者的角度，衡量他做了什么，而我们是从整体的、偏宏观一点的角度出发，不管他写了多少代码、解决多少问题，只看他最后产生了什么价值，比如他参与开发的系统响应速度控制在了多少以内等。

另外，我们的衡量细度也不是具体到人，而是看具体贡献情况，看是以小团队为单位还是以人为单位，如果是以团队为单位，那就是公司将评价数据分配给团队后，再由团队分配到个人，得根据具体的情况调整。

在《让细节的“病毒”感染你的团队》一文中，有读者留言问道：“关注细节的确有益于把控系统，但如何保证当技术领导者介入细节后不让团队成员对你形成依赖呢？另外，越级介入一些系统，是否会导致基层员工的不创新、不思考呢？”

白山 CTO 童剑：第一个问题，如何防止团队成员形成依赖，我们可以从以下几个方面出发：

培养关注细节的文化 ;

建立制度，使细节变成一种流程 ;

多提出问题，让团队成员来思考解决办法，给他们空间让他们按自己方法去解决 ;

启发式引导，不要一上来就告诉他问题和办法，而是要引导他们发现问题，启发出解决办法；

管理者是逐步退出的。

第二个问题，如何避免形成基层员工的不创新、不思考，我们可以从以下几个方面出发：

管理者并非越级介入，关注细节的文化形成后，团队中每个人都重视细节， 高层与中层确认细节即可，不影响底层开发。

管理者对细节的关注和参与，就像教练一样，是传授给员工更好的做事方法。

管理者对细节的关注和参与，也是以身作则，给员工做出示范，既给员工压力，也让员工有榜样学习。

对于基层员工，鼓励创新与思考，管理者对其开发细节的关注，是为了帮助基层员工更好的完成开发。

基层员工更多是从开发的角度思考，而中层和高层的领导者需要从使用者的角度设计产品功能，领导者的参与过程中会给基层员工带来更多的视野，对基层员工本身也是一种提升与培养

文化是一种彼此交流的基础，我们有招聘的“洁癖”，大家有共同愿景，不会因为上层的过多介入而失去主观能动性，乔布斯说“A 级人才的自尊心不需要呵护”，同样“对于 A 级人才也不必担心上层介入会对其产生负面影响”。

在《建立有效的员工淘汰机制》一文中，有读者问道：“对于“合格但不合适”的员工，要怎么处理呢？又该如何确定赔偿方案呢？”

好买财富平台架构部技术总监王晔倞：在我的经验中，这种情况一般分为两种，“试用期”与“正式期”：

1. 试用期阶段，这时不需要客气，直接说明不合适的原因即可，也不需要任何赔偿 。这种情况的发生很大程度上是由于公司和员工对岗位职责的界定不清晰而引发的。

为了预防这种情况，如果试用期为 6 个月，可以采取 2 个月考核一次的方式，前 2 个月可以安排对方做一些验证其技能的工作，甚至可以设定一些无中生有的任务，后 2 个月可以安排对方做一些验证其价值观的工作，如项目经理等推动与沟通偏多的工作，最后留出 1 个月，如果对方不合适的话，留出让其重新找工作的时间，这样做基本可以达到好聚好散的目的。

2. 正式期阶段，这时有两种做法，硬开和不硬开。硬开的话，按照劳动法，肯定是按照 N+1 的方式来赔偿的，如果对方非常较真，一般情况下是无法拿出量化的具体依据来证明其表现不好的。 不硬开的话，可以通过谈话、调岗等手段进行，至少让他觉得你们的企业还挺 Nice 的，不至于产生负面印象。

所以我觉得，关键在于试用期的把关，如果无法守住这一关，光想在正式期采取“有利于公司”的方式开除员工，既不合理，也不可取。

在《定制高效研发流程》一文中，有读者留言问道：“特赞币的做法确实挺好，不过这个虚拟货币的价值是什么呢？各角色为什么要去获取它呢？”

黄勇：特赞币只是一种工具，它用于解决研发和业务之间的高效协作问题，业务提需求需要“花币”，业务提反馈可以“赚币”，币的总数是恒定的（在一定条件下会考虑增发），币在业务与研发之间进行流通。

这样，业务提需求是一件需要付出成本的事情，确保所提的需求都是真正的痛点，同时，研发也能尽可能快地收集业务反馈，进一步验证产品的价值。对于优先级较高的需求，业务也可以花费更多的币在这项需求上，研发也会更加重视该需求。

在《  验证研发团队价值的绩效考核机制》一文中，有读者问道：“关于个人 OKR 部分想请教一下，个人 OKR 分为个人成长和团队贡献，那制定的个人成长和贡献怎么来评估是合理的，可执行的呢？”

黄勇：我在“组织架构篇”中提到过“职能团队”，该团队主管的职责就是帮助队员制定合理的  OKR，目的就是帮助他们得到成长，只有队员成长了，主管才会成长。

另外，每个人将自己的  OKR  制定完毕后，需要在对应的职能团队中分享，其他队员或主管可提出一些要求，修正或丰富这份  OKR，可以将其看做是  OKR  评审，而这样的评审可以是正式会议，也可以随机探讨，可以一次也可以多次。

OKR  均由自己制定，并由职能团队评审，当大家觉得没问题了才算合理，其实这里包括两方面，一是个人的追求，二是团队对自己的期望。

在《CEO 实话实说：我需要这样的 CTO》一文中，有读者问道：“您提到 CTO 需要有进化的能力，我理解就是学习能力，大家平时也都会学习，但多数是学了、理解了、用了，就完了，是否需要以学位、证书等方式加持呢？”

乂学教育创始人栗浩洋：我说的进化能力，绝不仅仅只是学习能力。它其实更多的意味着一种自我摧毁和自我扭曲的能力，就好像老鹰要把自己身上的羽毛全部啄光一样；就好像一个打乒乓球的奥运冠军，要学打网球的時候，完全不能用自己过去的套路，不能用手腕，而要用整個腰身的力量一样。进化是要改变自己过去的思维习惯，完全变成另外一种物种。

这个时候其实会遇到很多不习惯、不舒适甚至是痛苦的地方，当然也能从中发掘很多有趣的地方。所以我觉得学位、证书的加持只是一小部分，并不是必须的，重要的是他是否真的学会了知识、开拓了思维。甚至可能他只是完全的自学，或者是跟身边的人去学习，也能够完成进化。关键是他自己了解了新的知识，在进化到新领域时转变了一些旧有的思维、行为习惯，以及能夠驾驭新的环境。

结语： 本期筛选了管理细度、研发流程、绩效考核、员工淘汰等多个方向的问题，希望作者们的回答也能解答你的疑问。

感谢你陪伴“技术领导力 300 讲”专栏走过这四个月的时光，如果你对专栏有任何意见或建议，欢迎后台留言，留言被选中的同学将获得极客时间 10 元代金券。

感谢你的收听，我们下期再见。

大咖对话 | 余沛：打造以最佳交付实践为目标的技术导向

你好！

本周作客大咖对话的依然是同程艺龙副总裁、研发中心负责人余沛，其在 2012 年加入艺龙旅行网后，先后担任技术总监、首席架构师、CTO，除负责过基础架构、分布式计算、酒店垂直搜索引擎等一线工作外，也持续的推动公司在技术方向上的全面转型、技术委员会体系建立、技管分离等管理相关工作。在加入艺龙之前就职于百度，负责自动化运维相关系统建设。今天，我们和他聊了聊 CTO 的使命与职责，以及技术文化等话题。

极客时间：在您看来，CTO 的使命与具体职责是什么？又该如何衡量 CTO 的表现？

余沛： 使命与职责可以从两个不同的角度来看，自上向下和自下向上分别有不同的视角和答案。

1. 自上而下

自上而下自然是指站在公司或 CEO 的角度来看待这个问题，他们对技术条线有着怎样的期望、想达成怎样的使命。我认为这个答案就是以最优性价比（成本、时间）来交付业务的预期目标。衡量方式也很简单，就是从质量和效率两个维度衡量技术条线的业务交付能力。

2. 自下而上

除了完成公司、老板的期待外，技术人员自己也是有追求的，他们希望自己、以及技术团队能为公司创造更大的价值，通过以技术为主的手段，摸索、论证新的产品、业务甚至商业模式，并投入实践，帮助公司获得业务增长。

以 AI 为例，这两年 AI 已从技术领域的研究走向前台，进入公众视角。最初，非技术领域的人可能难以判断 AI 具体能给业务带来何种直接帮助，这时，技术人员应主动站出来，往前多走一步，研究、思考、并实践其怎样与业务特点相结合、在哪些点上能够帮助业务获得创新、突破。

自下向上的衡量也很简单，就是看由技术驱动的创新和改进，在公司业务中的地位、对业务增长的帮助，以及在此过程中，技术条线的工程师们所获得的存在感、荣誉感和归属感是否强烈。

这里我想多聊一下技术人员的存在感、荣誉感和归属感。优秀的工程师，待遇薪酬当然很重要，但他们往往更看重自己的付出在公司成长过程中起到多大的正面作用，公司又是否认可他们的能力与付出。如果答案都是确定的，那他们自然会有归属感和荣誉感。

以我们所在的垂直领域为例，很多年前，在地域性很强烈的本地产品排序案例中，最早产品的排序是由负责当地的运营人员来调整决定的，因为从行业惯性来看他们更熟悉当地产品的情况、更清楚当地的运营状况，丰富的经验赋予他们有更好的技巧来手动调整产品排序，以维持一个不错的转化率。

而在技术方面，我们开始利用大数据、利用用户行为进行更精细的分析，利用机器学习的算法来做机器排序、或者个性化排序。初期的训练模型出来后，AB 测试的结果并不如运营人员手工调整的效果好，这时大家总会有一些疑问，但以技术方向来讲，这一定是趋势与方向。经过不断的迭代、优化算法和调整模型，最终结果便会远远优于人工排序。

这时，技术人员自身会有很强烈的荣誉感，因为你的技术确实在某方面能帮助公司成长，等到这些结果落下“实锤”以后，其他部门的同事也会对技术条线同事的工作从质疑到认同，并真切认可技术的价值。而不是技术人自己说做了多牛的架构、写了多少代码，却难有人认可这些技术到底对业务有何种帮助。

极客时间：作为 CTO，对于中层技术管理者的培养，您有哪些经验？

余沛： 首先强调重要的一点是，技术团队还是要尽量扁平化、尽量减少一些中间层级。当然这跟团队规模与业务结构也有很大关系。回归话题，对于培养中层技术管理者，可以从两方面出发，一是培养中层管理对管理工具和管理方法的合理利用；二是帮助公司打造技术文化，以相对降低管理中层技术管理的成本。这两点其实是相对的，技术文化强一些，管理工具和管理方法就可以相对弱一点；反之，如果没有良好的技术文化，就不得不通过高昂的管理成本来进行管理。这当然不是一个很好的状态。

具体的培养理念，我们更倾向于让中层管理者有能力成为和一线同学一起往前冲的领头人，而不是站在背后执鞭指挥的纯管理。至少在技术领域，我也相信一线的工程师更愿意跟随有使命感、以身作则、以能力服众的 Leader。

同时，我们也会尽量检视，避免中层管理者过早脱离一线，成为“站在后面执鞭指挥的人”。我们曾经定下一套“CDR”指标，来度量中层技术管理者和高级别的技术专家。所谓 CDR 指标即 Code、Document、Review。我们期望中层管理，仍然不要太脱离一线，虽然他们身兼团队培养、项目管控、应急指挥等管理职能，但仍然要在这三个指标上有对应的完成度。要么与团队一起完成部分核心代码，要么参与重要系统的设计文档，或者帮助团队成员做 code review，提交有意义的 comment。至少在 CDR 的其中一方面有突出贡献，总之不能太脱离一线。

包括我自己，即使现在大部分精力与管理相关，但依然会不定期参与部分系统的讨论、评审。不敢完全脱手。技术管理者坚持不脱离技术岗，其实更能带动文化并将它更好的传递下去。

顺便说一句题外话，在 CDR 三个指标中，我很想强调一下 Document 的重要性。我们从来不认为文档是交付过程中的一个任务。我们一直强调：代码是思考的产出，而文档就是思考的过程。我们见过很多工程师，认为写文档麻烦、浪费时间，不做设计直接 coding，边写、边思考、边改。其实以建筑工程为对比就能明白，你见过没有图纸就开始施工的工程吗？为什么就能允许不做设计、不落地文档就开始写代码呢？还美其名曰“快速交付”。

再怎么样求快，也应该在写代码之前有一个良好的设计过程。文档并不是为了产出一个 file，而是在过程中思考、梳理逻辑。撰写文档看似会在前期花费一些时间，但在写完后转成 coding 的过程中就能够一气呵成，整体速度其实并比直接闷头 coding、发现不对又删了改，改了删来得慢。

当然，互联网领域竞争激烈，公司业务发展快速，产品模式迭代快速，大家都在追求快时，如何能说服运营、产品及技术人员坚持速度与质量并行，很大程度上还是与文化挂钩。

极客时间：您之前提到技术文化，那同程艺龙的技术文化是什么？又是如何打造落地的呢？

余沛： 我们的技术文化很简单，就是“简单、匠心、交付”这三点。

先来看简单。 简单有两个层面，一是做人简单，二是做事简单。

技术人其实真的是非常单纯简单友好的群体。，我们希望能将这种简单保持下去，不要将问题复杂化。比如面对一个问题时，大家能就事论事、拿数据说话，不用因为顾虑对方是上级或者其它的办公室原因而难以启齿，以最直接有效的方法来解决问题。

其次，将简单的原则沿用到做事中，做技术的同学都应该清楚：事情越复杂，则出错的几率越大。

在技术上，我们不赞成求多、炫技，而是更倾向于做减法。比如，为了实现某个功能需要做一个架构，在初步的架构设计中需要十个组件，这时，我们一般会鼓励大家想办法做减法，将组件变成 8 个、7 个，或者 6 个，尽量将它简化。

另外，即使今天看起来很好很适用的技术系统，我们也要随着时间的推移去持续做减法、优化。就像衣橱中的衣服，换季时不合身了就要敢于淘汰。

举个例子，很多前年前团购很火爆的时候，我们在系统中有很多团购相关的模块与服务，如今业务形态早已变化，相应的逻辑如果还在流程中存在，其实是一种负担，也容易因为业务萎缩后，过少维护而引起其它地方的问题。

况且互联网公司的人员变动较为频繁，如果你没有在合适的时间调整架构、优化内容，等过了 N 年之后再去清理它们，到时已经无人能懂这些代码，也可能没有人熟悉风险点有哪些。自然会面临极大风险。所以，我们提倡及时简化、优化系统架构。

再来看匠心。 简单和匠心不冲突，就像苹果的产品，虽然它的设计理念趋向简单，但确实从很多细节中能够感受到非常用心。

我们有时会检视一些不太好的系统，发现它们并不只有一两处糟糕的实现，而是从整体到细节都没有用心，一片糟糕。在我看来，一个优秀的工程师，做一个优秀的设计，可以把事情做少、做简单，但质量要高，至少达到 95 分以上，否则后期返工、维护的成本会更高。

我们曾经有一个基础组件系统的研发，出了第一版设计，不合格，被评审打回，之后的第二版、第三版依旧不合格，依旧被打回重做，这样来回返工六七次才通过。看起来似乎对交付有一些影响。但是这个系统，上线后持续运行了四年几乎无故障。我们还是希望在交付时间能够接受的前提下，尽可能的养成匠人精神，无论对个人还是对系统而言，都是终身受益的。

另外，需要强调的是，匠心与交付也并不冲突。匠心不代表成本要从 1 变到 10，花费超额的成本来成就匠心。而是要求我们在做事的过程中，将心注入，追求极致。否则，原本一天就能交付的工作，由于的“匠心”要额外花费十天才能完成，又会与公司目标冲突。

对如今的互联网行业来说，快速交付是一个非常重要的能力。快速交付不意味着质量上的妥协，很多时候，这是一个态度的问题。以炒菜为例，优秀的厨师与差劲的厨师，用在“炒”的时间和步骤其实不会相差太多，好与坏的区别取决于用不用心，而这“用心”其实包括前期的食材、工具的准备、平时的训练、对理念和目标的思考等，这才是更重要的。

而在技术方面，所谓的匠心也不是单纯指在写代码时吹毛求疵，关注注释有几种写法、括号应该怎么换行，而是写代码前，有没有用心思考与梳理，这才是差距所在。

最后来看交付。 技术人员往往更关注自己的技术，比如用了哪些新技术、算法有多牛、架构有多好，等等。但是我们希望，技术最终能与公司目标结合。比如算法很牛，那它对业务交付产生了多大的价值，是提升了转化率，还是优化了用户体验？

在简单和匠心之外，我们会更多强调，技术的最终目标是要完成交付，而不是为了炫技而做技术。因此，我们也会以交付来衡量技术人员的产出。

之所以把交付写进技术文化中，是因为文化可以自发的影响人。其实在互联网公司，所有程序员都知道要交付，因为不交付就无法完成 KPI，最终无法完成目标。

但简单的把交付写进 KPI，其实是一个被动的过程，而如果能把关注交付当做一种文化，它就会变为主动性，促使技术人自发地、更优雅地去思考结果与目标，也会更愿意思考自己的技术对公司产生了什么价值。

极客时间：将技术文化落实到每个成员，具体会做哪些事情？

余沛： 技术文化的打造是一个潜移默化的过程，具体到落实的话，可以通过鼓励符合文化的行为来进行引导。

以匠心为例，工程师写完代码，他认为已经合格了，完成了交付，而他的上级在帮他 Review 代码时，会非常认真，会去思考还有没有优化的空间，如果有，团队就开会讨论能够优化的部分，再给出较为全面的优化建议。而不是大家一看反正代码也能运行，就很容易的给你通过。

同样，对于交付也是如此，我们每一次内部评奖时，都会问候选人一个最终问题，即你的代码或架构的受益人是谁？他们获得了怎样的好处？

这样造成的结果是，以前评奖时，很多人都会列举自己做了哪些特别厉害的技术，而现在，他们会自发思考，我做的事情最终会交付怎样的成果，能对谁产生怎样的价值，这就是文化潜移默化的魅力所在。

大咖对话 | 余沛：进阶CTO必备的素质与能力

你好！

本周作客大咖对话的是同程艺龙副总裁、研发中心负责人余沛，其在 2012 年加入艺龙旅行网后，先后担任技术总监、首席架构师、CTO，除了直接负责过一线的基础架构相关系统、分布式计算、OTA 垂直搜索引擎等工作外，同时推动了公司在技术方向上的全面转型、技术委员会体系的建立、技管分离等管理类工作。在加入艺龙之前，曾就职于百度，负责自动化运维相关系统建设。今天，我们和他聊了聊 CTO 的素质与能力，以及如何提升等话题。

极客时间：您好，能先简单介绍下您和您目前负责的工作方向吗？

余沛：我于 2012 年加入艺龙任技术总监，当时，首要任务是建立一支基础架构相关的研发团队，并解决困扰公司技术发展的两个问题。一是公司的技术栈需要从沿用超过 10 年以上的 Windows 体系全面转向 Linux 生态体系，在技术、架构、以及人员的转型问题；二是帮助公司搭建起支撑转型的一系列基础平台问题。

上述两个任务在达到一定的里程碑之后，又任艺龙的首席架构师，工作逐渐从平台类技术开始转向帮助公司直接业务提升的诸多业务类系统。2014 年底升任艺龙网 CTO，全面负责艺龙的技术团队管理工作。

去年年底，同程与艺龙合并后，我有幸担任新公司研发中心负责人，继续负责公共研发团队，以支持各业务线的基础及公共类研发任务。

极客时间：从技术总监成长为 CTO，您觉得哪些能力与素质的提升最重要？

余沛：在我看来，素质与能力可以从两个不同的维度来谈。

素质维度

作为技术 Leader，肯定是要先具备比较扎实的技术功底、以及相当广阔的技术视野。技术领域还是要先有内功，再谈管理；我们很难看到一个人在专业方向上不见长、却还能够把技术团队管理得漂亮的。

虽然技术到了一定深度之后能够更好的触类旁通，但先决条件是：你首先要在某个领域有过较深投入与研究，具备扎实的技术功底，才能更好的对宏观领域、多个技术方向有比较靠谱的辨识及判断能力。这有点类似于武侠小说中，只有自身先拥有一定功力，成为某个领域的高手，才能对其他门派的武功有速成，或者对好坏轻重的判断能力。

当然，技术领域的更新、变化总是很快，对于一些新领域、新工程的具体细节的掌握，可能不见得多于新进的年轻人。但如果你曾在某个领域有过相当的投入与研究，那么，做为一名技术管理者，至少能够在大的格局与方向上仍然有相当的把握能力。

能力维度

我认为，成为一名合格的技术领导者，至少应当具备四种能力。

1. 对业务的理解能力

首先，在任何的商业公司中，技术的本质也是要为生产服务，帮助业务及产品完成的对应的价值实现。事实上，也不存在纯粹为技术而技术的商业公司。

其次，在互联网这个开放的环境及氛围下，大多数的应用类技术，其普及的周期越来越短、高端技术的平民化越来越快，能够形成技术垄断的领域越来越少。抛开商业规模形成的规模效应壁垒外，已经很少存在某个通用领域的技术只有你会，而别人没有解决方案（其实现不一定一致）的情况。

在这种前提下，互联网公司面临的技术难点往往衍生于其自身的业务独特性。以前经常讲的高可用、高并发、自动化运维、分布式，等等，这些曾经高大上的话题，在通用解决方案上已经没有什么新鲜的难以解决的困扰。许多方案都已经公开化，相应的人才也因流动性分布在许多公司。我还记得很多年前，NOSQL、DB 读写分离、hadoop 应用等应用技术都能在各种技术大会上引起聚焦，现在，它们早已是很多公司的入门标配了。

真正的难点在于，你的业务场景中存在的那些独特场景，以及为了解决这些特性需要的技术方案。如果一名技术 Leader 对自身的业务特性了解不够深入，则很难触达真正的痛点，帮助业务解决技术方面的难题。你可能是一名搜索专家，能够很轻易地构建一套传统的分布式搜索引擎，但是面对机票、酒店或电商等领域时，他们对于搜索的要求、难点在哪？传统的经验能够起到什么样的作用？还需要构建哪些额外的体系才能解决这些困难？这都需要与业务一起、有耐心的深入下去，才能够真正理解。

2. 资源分配及收益的判断能力

在我看来，无论何种规模大小的技术管理者，都要不断做资源分配和收益判断。对于技术投入本身（无论人力的投入，还是设备的投入），也应该从成本与收益的角度判断。当然，不同的公司其资源规模不同，不仅仅是互联网行业，再扩大来看，其实所有行业及领域都是这样，对外看是收益，对内看成本。

当你是一名一线的研发人员时，总是对于技术实现怀有很大的热情，期望技术架构趋近完美，在技术规模上求大求广，追求技术指标极致完美。但当你站在技术 Leader 的位置时，这种差异就像是战场上，从一名武功高强、骑着千里马冲在第一线的战士，变成在战场后方的指挥所里，指挥战术、调度兵种打仗的将军。你要学会去思考，如何合理的调动人员与技术资源，一千个需求摆在面前，怎么分配技术人员？一千个应用要上线，要买多少服务器才够支撑？每年那么多技术热点出现，每一个都号称要改变世界、改变未来，而你只有 100 个每天都加班赶工的研发，这些热点跟还是不跟？这些人员还招不招？

拥有海量资源做小量产出不算本事，如何把资源的配置发挥到极致，帮助业务以尽可能小的成本获得尽可能大的收益？当一些热点技术出现时，思考一下以公司现状适不适合投入这一波新技术热潮？该投入多大的精力去研究它？或者在不同的阶段，掷以多大的资源投入？

以技术及业务项目的投入为例，花费了半年时间做重构，确实解决了许多技术问题，也有更好的扩展性和高性能，但这对于一个预期生命周期只有一年半载的业务而言，收益有多大？一个业务项目，预期生命周期很长、收益较高，初期为了快速上线做了很多技术上的妥协，后期在什么时候来还前期欠下的技术债务？决策在什么时间点、额外花费多少时间或人力成本来解决这些问题，才能在业务发展和技术支撑方面获得较好的平衡？

再以新技术的投入为例，历史已经给出了许多案例，有些公司对新技术操之过急，耗费巨大人力、财力，导致消耗过度而死。结果，等新技术在渡过最初的高成本孵化期后，其他公司可能只需要较少的投入就能追上来。也有对新技术的反应迟钝的公司，等别人应用落地后才进入，又发现为时已晚。

当然，有时候慢一下无伤大雅，“慢”并不是 0 和 1 的差别，即并非投入和不投入的差别，而是分阶段合理计算投入产出比的问题。

3. 对团队的建设能力

众所周知，团队与人才是一个公司的灵魂，合理的人才梯队建设对公司未来的发展影响极大。作为技术 Leader，如何在技术领域内吸纳人才、培养人才以及构建适合公司业务结构的梯队，是一个需要长期思考、复盘的重要命题。

在规模较大的公司，由于品牌、文化、待遇等方面的影响，对于中高端研发人员的吸引会比中小规模的公司更有优势。让我印象深刻的是，在上家公司时，能够源源不断的收到优势简历。来到艺龙时，在招聘方面确实感受到相当的落差和压力，也只能客观的去面对事实。相对于金字塔尖的公司，越往下它的影响力越有所减弱，吸纳人才的难度也会随之增加。

在品牌影响力存在弱势，薪酬待遇也需要遵循市场普遍认可的成本管控的情况下，如何解决团队的建设问题，确实经常困扰着我们。我认为，先做好两件事肯定是有价值的，一是对内和工程师们一起，创建良好的技术文化及氛围；二是对外打造良好的公司技术品牌影响力。

尤其在许多以业务为重导向的公司，如果规模没有达到一定体量，对内、对外，技术的发声和影响都相对弱势。做为技术 Leader，如何既在公司内建立起良好的工程师文化，又能让业务、产品认同技术的价值，尤其是认同技术人员的价值，而不仅是把技术人员当成实现需求的工具（比如老牛、长工），让技术团队既能在工程项目中获得成就感，也能跟随公司在业务提升中获得荣誉感。同时，也能将自己公司沉淀下来的优秀技术理念、技术经验与技术氛围向外展示，吸纳更多的优秀人才，让外面的人也知道并认可这是一个很适合一起奋斗、一起成长的平台。

4. 协调与沟通能力

至少在国内，绝大部分的互联网公司中，纯技术驱动的公司是不存在的，技术一定与产品和业务紧密结合。我套改一句《三体》中的法则：在公司发展过程中，各个部门对资源的需求是不断增加的，而公司的资源总量在一定的阶段是有限的。这种广义上的资源包括了一切，如对某件事情的决策权限、薪酬福利及晋升、公开的荣誉、时间的分配等等。因此，技术在与公司其它职能共同合作时，一但牵扯到资源的重新组织时，如何有效的沟通，或者为有效的沟通创建良好的条件与规则，也非常考验技术 Leader。

毕竟从数量上讲，确实多数研发出身的人员都是简单、直接、专业性很强的“红脖子”。两个技术人员之间沟通还能相杀相爱，一但跨职能沟通时，就很可能你说你的，我说我的，牛头不对马嘴，仅剩鄙视相杀了。缺乏有效沟通环境的结果，往往就是看哪个部门的声音大或权力大。并不能对公司产生正向价值。

举个例子，在某些电商场景的业务风控中，熟悉产品运营、有多年风控经验的业务人员，在系统中依赖规则平台配置了很多风控规则。一直将业务风险控制在一个比较好的区间。直到有一天，技术人员通过机器学习的方法将这一过程自动化，在初期阶段可能效果未必比人工配置的结果好。如果这个业务有强烈的业务指标管控，且主导权最开始并不在研发职能内，那么在初期如何有效沟通，影响、说服业务部门愿意尝试和接受这样的技术项目引入？（毕竟出错了砸人家饭碗、成功了也是砸人家饭碗啊。）

诸如此类涉及到职能、部门之间的协调，如果技术 Leader 不能帮助公司建立起良好的沟通环境、不能帮助工程师们争取到良好的协同氛围，整天只是带着研发人员追求技术万岁的话，很难帮助技术在业务发展中进步，也很难帮助技术人员在公司内得到相应应的地位和成长空间。

极客时间：对于从技术管理者向 CTO 进阶的人，该如何提升这四方面的能力？

余沛：我有两点建议。第一点，一定要更加深入，也更加广泛的参与并了解公司的核心业务，跟随公司的核心业务一起成长。从横向维度思考业务，从纵向维度思考用何种合理的技术解决方案，这样才能对公司的整体技术方向作出完善的规划。

最好亲身到一线核心业务里走一趟，站在外面看跟亲身体验一遍是完全不同的感受。假如你是空降过来的，也务必说服老板创造条件，把自己先放进核心业务里去看看，哪怕这个核心业务原来并不由技术主导。在此过程中，再用自己的技术专业眼光，帮助公司重新审视业务。

比如某个工作一直由运营负责，他们会遵循一贯的做事方法，由于专业能力、惯性思维，可能想不到可以利用某项技术改进来更好的完成工作，而你尝试了解之后，很有可能发现技术可以在某个点帮助到他们，让他们事半功倍。

第二点，尽快将自己的目标从较为单一的技术类目标，或者项目进度完成指标，转变为公司的业务目标，力争把技术与业务这两条线聚合到一起。这非常重要，因为，只有将两条线聚合到一起，你才会更多地以公司、业务的视角，从资源分配和收益等角度去思考问题、判断现状。否则，若长期只关注技术，就会忽略背后需要的投入与产出，成本与收益等问题，无法顾全公司大局。

最后，我相信，技术团队中单项能力的最强者未必是 CTO，相反，如果 CTO 是公司中技术最牛的人，离开他运维也不行、安全也不行、架构也不行了，那才是最危险的。

CTO 的职能，一是把控好技术方向，清楚认知公司业务在哪些方向需要用到什么样的技术；二是帮助公司培养具体领域的技术强者；如果还有第三项，那就是在年会抽奖时还能 review 一下抽奖程序的代码。（开玩笑）

因此，技术管理者要成长为 CTO 的关键点首先在于观念的转变，打造好一个素质的骨骼与四个能力的肌肉。不仅能够帮助公司利用最优的成本解决问题，也能够让研发工程师们过得很 happy。还得让外面的优秀人才源源不断地跳入。

大咖对话 | 刘俊强：云计算时代技术管理者的应对之道

你好！

本周大咖对话的嘉宾是腾讯云资深架构师刘俊强，曾任迅雷技术总监、某互联网公司技术副总裁，有着 10 年以上互联网开发经验和 8 年以上技术管理经验。之前，他与大家分享了 2019 年云计算的相关趋势，今天，我们将继续探讨这样的趋势对技术管理者有何影响。

极客时间：在您看来，面对这样的云计算趋势，技术管理者要如何应对呢？
刘俊强：之前提到，2019 年云计算的趋势主要体现在五大方面，分别是：云服务市场将继续增长强劲；混合云和多云（Poly-Cloud）将逐渐成为主流；自动化将不可或缺；合规性和安全性将受到重视；云服务将依然是新技术的最佳试验地。

作为技术管理者，一般会负责技术团队组建与培养、技术规划与选型、成本优化以及前瞻技术调研等，那么根据职责来看云计算趋势对技术管理者的影响就比较显而易见了，简化而言主要会有以下影响：

1. 如何制定公司的云战略；
2. 云服务的深入使用对团队的影响。

在我们开始谈影响之前，作为技术管理者、技术决策者，首先需要明确业务上云的原因和需要，这里我整理了云计算报告里一些企业选择上公有云的原因，可以对比着来看看哪些是你同样在关注的：

1. 减少基础设施投资；

2. 资源扩展速度快；

3. 降低 TCO（总体拥有成本）；

4. 提高 IT 服务交付速度；

5. 更灵活地应对不断变化的市场；

6. 同业内已有典型应用案例；

7. 提升客户服务品质；

8. 政府或主管机构要求。

极客时间：您能具体分享一下如何制定公司的云战略吗？
刘俊强：我们首先要明确的是，使用云是一种手段而不是目的，我们的目的是实现 IT 现代化，通过标准化和自动化的云战略来辅助实现最终目的。在明确了最终目的后，采用云计算是不可避免的趋势和手段，因此，制定云战略对于企业来说十分有必要。所谓云战略是定义了使用云的动机与目标的文档或手册，那么作为技术管理者，我们该如何制定属于自己企业和团队的云战略呢？

在开始制定云战略之前，建议先回顾下之前所说上云的好处，我在这里重新做了下简单的汇总整理，好处主要有以下几点：

1. 降低基础设施成本：通过云端各类计算资源和弹性等，来降低基础设施的总体拥有成本；

2. 提高 IT 效率：将 IT 团队从基础设施硬件管理中解放，转向提供基础设施服务来提升效率；

3. 新市场开拓：通过云服务商全球的基础设施，方便将业务部署到新市场地域；

4. 加速应用交付：云计算提供了近即时的计算资源访问服务，减少了应用开发到部署的时间消耗；

5. 增加自动化：自动化能够提升 IT 团队的效率，云服务商提供了众多的自动化工具和系统；

关于如何制作云战略文档，Gartner、Microsoft 等都有一些介绍和示例，总的来说，他们的云战略文档制定者的角色是 CIO 或 VP of IT ，一般需要向 CEO 或董事会进行汇报，篇幅比较长所以不建议直接选用，但是其中制定云战略的思路和方法是可以借鉴的，可以让企业的上云思路更为清晰，而不仅仅是简单的 Lift-and-shift （平行迁移）。下面我将云战略制定步骤简化一下，使其对技术管理者来说更具备实操性：

步骤一：明确用云目的，使用云计算能够带来诸多业务优势，确定使用云的动机和目的是制定云战略的重要基础，一般情况下企业仅需满足前面所提到的好处中的两到三项作为主要目标即可。

步骤二：规划云产品组合，是使用混合云、全公有云抑或是多云策略，需要技术管理者根据企业长短期目标来进行规划，除了云部署模式选择外，还有 IaaS、PaaS、SaaS 这些服务对应企业业务模块情况以及上云规划。例如服务模型的选择上，对于 DevOps 接受度高的企业可以选用 DevOps 类 SaaS 服务，如代码托管、项目管理系统等，数据库中间件、消息中间件等 PaaS 类服务就很适合开发运维人员配备不够充足的企业组织使用，再者如对于核心数据资产放置在云端不放心的企业，可以采用混合云的方式进行部署。

步骤三：克服常见云挑战，企业在使用云计算时通常会面临一些云挑战，常见的有云管理控制、成本以及 IT 文化。云管理控制包括多个维度，如资产、运维以及财务等，需要结合云厂商的访问控制工具进行角色和流程定义，另外云管理控制的重要挑战是云安全，云产品不同于传统的基础设施架构，需要专门制定云安全架构和 IT 操作规范；云计算可以减少基础设施成本是主要优势之一，但是使用云计算需要更为精细地管理资源使用，才能够将成本优化最大化；深入使用云会对现有技术团队工作方式和文化形成挑战，具体内容在文章后面内容会介绍到。

步骤四：构建云战略成功的能力，如果要成功执行制定的云战略，需要开发培养出一些跟云计算相关的能力。例如，云端安全加固、云计算资源选型及计费模型、云原生架构能力以及云端数据隔离等是保障云战略成功的必要能力。

步骤五：做好团队变革准备，云的深入使用会带来组织上新角色的出现，流程的改变，甚至于组织架构的改变。

云战略制定好后的具体实施需要进行规划和部署，这里有个简单的云战略路线图的示例图供参考：

一般情况下我们将云战略实施分为三个角色：

筹备组：负责整体云战略的规划与实施节奏把控，一般由各关联职能与业务线负责人组成；

技术实施组：负责整体云战略的具体实施，包括但不限于上云资源评估、应用系统架构改造、资源管理系统适配以及应用迁移上云等，一般由运维与开发人员组成；

支持组：负责云战略规划和实施中的支持性工作，包括但不限于 IT
资源采买模式变更、云安全审计等，一般由采购、财务以及安全专家等人员组成。

整体云战略实施过程一般分为以下几个阶段：

筹划与 PoC 验证阶段：该阶段需要明确云战略的目标以及计划，然后再进行概念验证，如云端实验工作室，让团队对云的使用更为熟悉和了解，该阶段的最后输出为云战略实施计划，并做好团队内部沟通与云战略公示；

云服务商评估阶段：该阶段根据自身业务特点对云服务商提供的产品进行测试与选型试验；

云战略实施阶段：该阶段需要根据云战略来评估安全风险、架构调整风险点等，并开始对系统架构进行调整、对运维管理系统进行修改、落实数据迁移方案等以适配迁移上云的目标，本阶段是整个过程中最重要的，也是持续时间最长的阶段；

总结阶段：该阶段主要对云战略实施的最终结果进行总结复盘，并根据企业业务需要和发展阶段，制定下一阶段的云战略。

极客时间：云服务的深入使用对团队有何影响呢？技术管理者要如何应对呢？
刘俊强：云服务的普遍使用会给团队带来一些影响，正如我们之前提到的云管理控制、成本以及 IT 团队文化等常见的云挑战，当然这些挑战和影响跟企业使用云的程度也是有相关的，一般情况下将团队使用云的程度分为以下几个阶段：

观察者阶段：企业正在开发云战略和实施计划，但目前尚未将应用部署到云上，希望评估适合的云模型和云产品，并评估哪些应用和服务可以部署到云上。

初级用户阶段：企业正处于 PoC （概念验证）阶段，或是初始上云阶段，希望获取云计算使用经验以确定未来项目部署模式。

中级用户阶段：企业已在云上部署了多个项目或应用，希望扩大和改进云计算资源的使用。

高级用户阶段：企业已大量使用云基础设施，并正在寻求优化云运营和云成本。

不同企业对云的熟悉和使用程度是不一样的，因此不同阶段企业的技术管理者面临的挑战和团队影响也将是不一样的，这里我简单用表格示意下：

不难看出，随着云熟悉程度的加深，技术管理者们所面对的挑战和影响是不一样的，在观察者阶段和初级用户阶段，更多需要的是明确上云的策略和云产品的使用，这里需要技术管理者帮助团队学习对应的新技能，并带领团队沉淀下云的使用经验，以帮助后续项目或应用上云。

到了中级用户和高级用户阶段，技术管理者们所面临的问题又不一样，在这两个阶段，会有更多的团队和角色参与到云的管理控制中，例如安全团队、财务团队等，而云端安全、云端架构与传统架构、安全会有差异，因此需要专门进行设计和评估。另外由于云端资源采买的便利性，如何界定是否适合采买、已有资源是否浪费以及项目独立核算等问题都需要财务团队介入。

在变为高级用户阶段时，组织架构上甚至会产生类似技术委员会这样的组织，一般是云战略委员会，负责企业云使用的整体规划和设计，以及组织架构和流程改进等事务。

另外在团队成员构成上，原先的架构师、安全专家及运维工程师等角色都需要对其进行云端技能补全，使其转变为云架构师、云安全专家和 DevOps 工程师，以使技术团队能更好地适应大量使用云后的改变。

综上所述，我们不难发现云计算的大量采用对于技术管理者的挑战，不光体现在业务应用迁移上云的难点和风险，在团队云计算相关技能培养、组织架构等方面也面临不小的挑战，技术管理者需要保持清醒的头脑，对于自身企业的云战略有着良好的规划，以此为指引来应对这些挑战。

大咖对话 | 刘俊强：谈谈我对2019年云计算趋势的看法

你好！

本周大咖对话的嘉宾是腾讯云资深架构师刘俊强，云计算经过最近五年产品能力的不断完善、云产品的持续新增和稳定性的逐步增强，使得大家已经能够广泛接受云计算的理念，并积极思考如何在自身业务中使用云计算。今天，我们主要聊了聊他关于 2019 年云计算趋势的看法。

极客时间：您能先简单分享一下您对 2019 年云计算趋势的理解吗？
刘俊强：首先需要说明的是，在未特殊说明的情况下，我之后提到的所有云市场都指公有云市场，也就是我们一般所熟知的三类服务：laas(基础设施即服务)、Paas(平台即服务) 以及 SaaS(软件即服务)，另外还有一类是 Gartner 提出的 BPaaS(业务流程即服务)。这三类服务的关系我就不在此赘述了，简单以下图做个解释。

根据最近几年的技术发展和云计算行业的成⻓，我对于 2019 年云计算趋势的理解主要有以下 5 点:

1. 云服务市场将继续强劲增⻓；

2. 混合云和多云 (Poly-Cloud) 将逐渐成为主流；

3. 自动化将不可或缺；

4. 合规性和安全性将受到重视；

5. 云服务将依然是新技术的最佳试验地。

根据 Gartner 给出的数据，2018 年全球公有云市场规模为 1758 亿美金，另据中国信通院的数据，2018 年中国公有云市场规模为 382.5 亿人⺠币。从规模⻆度来看，公有云已经是不小的市场了，同时还保持着不错的增⻓率。全球公有云市场每年都保持着约 20% 以上的增⻓，中国公有云市场的增⻓则每年为 30% 以上。

下面的图表就是 Gartner 对全球公有云市场规模作出的预测，据预测，2019 年全球公有云收入将增⻓17.3%，总额达到 2062 亿美元，其中 IaaS 是市场增⻓最快的部分，达到了 27.6%。

下面的图表则是中国信通院对中国公有云市场规模做出的预测，据预测，2019 年中国公有云收入将增⻓36.2%，总额达到 521.1 亿人⺠币。

过去几年，公有云市场的快速增⻓离不开企业对云的接受及使用程度的提升，根据 IDG 和中国信通院的数据 (IDG 数据针对非中国地区，信通院数据针对中国)，目前非中国地区企业对云的接受程度如下:

73% 的企业已使用云服务，另有 17% 的企业将在 1 年内使用；

到 2019 年预计 90% 的企业会将应用放在云上，这一数据到 2021 年预计将为 100%。

下图是由 IDG 调研的非中国地区企业对云服务的接受情况：

而据中国信通院的调研，54.7% 中国企业已使用云服务，并成逐年增⻓的趋势。由此可以看出，不论是中国企业还是境外企业对云服务的接受程度都是在逐步提升的，而除了接受使用程度在提升外，企业的云计算预算也在增⻓，预算增⻓率可能保持到 30% 以上。

随着云计算市场产品和解决方案的不断增⻓和完善，显而易⻅的是，2019 年云计算服务市场依旧会强劲增⻓，并且云服务将对企业的协作和工作模式产生更深远的影响。

极客时间：您提到混合云和多云 (Poly-Cloud) 将逐渐成为主流 ，能详细分享一下您对此的看法吗？
刘俊强：公有云并不是银弹，不是一种适用于所有类型需求的解决方案，不是全部企业都能够像 Netflix 那样将全部基础设施放在公有云上。对于具有特定需求的企业来说，全部基础设施迁移上云是一项极为艰巨的任务，而混合云模式提供了一种过渡的解决方案。

混合云将现有的本地基础设施与公有云服务混合在一起，通过混合云模式，企业能够以自己的节奏来过渡到公有云，同时还能够保持灵活性与实施效率。目前还是有不少企业有自己的 IDC，通过混合云模式可以帮助企业在 享受公有云的弹性和产品能力的同时，还能够减少全量迁移的压力、降低过渡⻛险和总体成本，同时还能够进行灵活的私有云、公有云资源分配，2019 年企业对公有云接受程度的提升，也势必带来混合云模式选用的增⻓。

多云 (Poly-Cloud 或 Multi-Cloud) 则是近几年兴起的另一个概念，意指企业不将全部业务放置在一个云服务提供商身上，他们会根据自己的策略，将不同种类的业务分配给不同的云服务提供商， 例如根据云服务商的产品服务能力专⻓进行选择。有的企业则是根据云服务商与企业业务间的关系进行选择，还有的企业根据 “云不可知论” 追求跨供应商的可移植性。不论如何，多云的选用策略也将成为越来越多企业的部署模型，因为对于企业而言明显能够感受到的好处就有以下两点:

能避免单一供应商绑定，拥有更高的灵活性和成本优化优势；

供应商故障和灾难发生后，能最大程度保证业务可用性。

但多云部署策略的选用并非全是好处，有些前置条件和问题也是需要注意的，比如需要企业技术决策者根据企业的长短期目标来进行云产品组合的规划。

极客时间：您之前提到了自动化、安全性等方面的趋势，能详细分享一下您对此的看法吗？
刘俊强：首先要强调的是，自动化将是不可或缺的。随着最近几年微服务、Service Mesh 等架构设计⻛格被普遍接受和选用，容器服务也逐步成为主流，Docker 及 K8S 已经成为了容器和编排的实际标准而被众多企业选用。在我看来，公有云的容器服务将成为主流，因为容器技术可以帮助企业以一种快速、可靠、一致化的方式部署应用，容器和编排服务本身作为软件工具，也会有缺陷和安全⻛险的问题，而公有云供应商的云容器服务能够很好地帮助企业进行这些问题的解决和规避，因为他们拥有更庞大的集群规模和研发人员投入。

不可否认的是，容器化改造不光是在部署环节的改进，实际上是软件或应用全生命周期的改造， 因此在架构设计、开发、测试及部署环节上都会有相应的改变。容器化改造、微服务架构设计⻛格选用等，都势必会造成应用系统的增多，增加开发、测试及部署的复杂程度，会带来应用系统的管理成本上升，所以如何在软件生命周期实现自动化、部署自动化以及云计算资源管理自动化是各个企业需要调研的问题。

另外，企业将越来越重视合规性和安全性。举个例子，此前欧盟推出了 GDPR (一般数据保护条例)，旨在对欧盟公⺠的数据保护法律进行大规模改革， 所有向公⺠出售和存储个人信息的公司都不能对数据有太多控制。比如根据 GDPR 规定，数据收集者不能用隐藏默认的方式获取用户许可，必须提前进行明确的提示与询问，获得允许后才可使用用户数据；收集之后，需要为用户提供查看收集数据概览及用途，还需要具备用户删除功能等。

不遵守规定的企业可能会面临欧盟严厉的惩罚。如果企业要在欧洲发展业务，必然需要考虑遵守 GDPR，除了公有云提供商本身遵守外，企业自身应用也需要遵守。而随着互联网近十年的快速发展，法律法规上将会出现更多的保护条例限制，因此合规性也将越发受到重视。

在安全性方面，近几年 MongoDB、ElasticSearch 等勒索事件的爆发，安可以看出全漏洞每年是呈增加趋势的，而在选用公有云解决方案后，并不代表着就不会有云安全漏洞了，企业业务在上云之前做好云安全规划是非常重要的事情。云安全解决方案需要 IT 和安全团队采用新的操作模型，来减少上云后安全漏洞的产生以及漏洞产生后的范围控制等。

极客时间：在您看来，云计算理念的广泛普及，对新技术有何推动作用呢？
刘俊强：简单来说，云服务将依然是新技术的最佳试验地。近几年有很多技术名词新产生或变得再次火热起来，如人工智能、5G、物联网、边缘计算以及无服务函数计算等。公有云不光是这些技术的试验地，也是这些新兴技术的关键推动因素，会与新技术形成很好的⻜轮效应，使得新技术能够快速地使用到应用中去，同时也将帮助新技术快速收集问题以帮其改进。

比如，5G 技术的到来，可以给物联网提供更多的应用场景，同时，5G 技术提供了更快和更大带宽的移动网络服务，最终使得物联网设备或无人驾驶汽⻋产生更大容量的数据回传到云服务进行处理；而边缘计算，也就是在网络边缘进行数据处理以优化云计算，能够很好适应 5G 技术普及后的大容量数据回传和计算需求，通过边缘计算运行实时服务，简化来自物联网设备的数据流量，并提供实时本地数据分析，将核心数据和分析结果回传至云计算中心节点。不难看出，5G 和物联网的发展，势必会带来云计算和云存储的使用增加。

另外，通过无服务函数计算服务，可以不用虚拟机或容器就能够进行计算任务，当数据存储或数据连接在云端时，无服务函数计算允许开发人员在没有任何基础设施的情况下构建和运行应用程序服 务，帮助企业提高效率、减少工作量和成本，结合物联网、大数据等场景能够很好地简化开发与部署。

总的来说，云计算会继续快速发展并最终像水电一样的便捷和基础，新的技术和解决方案也必将在云计算最先普及和使用，企业如何根据自身业务特点使用云计算来提升组织效能和竞争力，是接下来从业人员需要重点考虑的问题。

大咖对话 | 创业就是把自己过去的经验快速的产品化

你好！

本周作客“大咖对话”的嘉宾是经纬创投董事总经理熊飞。熊飞曾先后在腾讯和阿里巴巴担任产品经理，负责过腾讯网社区产品的设计及策划、B2B 收费类产品、企业级电子商务等产品工作。2011 年，他加入经纬中国，负责考察、筛选及评估互联网领域的投资机会。这一次，我们和他聊了聊企业级服务领域的创业。

Q：这段时间有媒体说，中国的 to B 时代终于来了，你怎么看？当下企业级服务领域的机会在哪里？

A：这个很清晰，我也是蛮赞同的，之所以这样说有几个原因。

首先，任何行业的春天都是需求驱动的，to B 的一个必然的驱动力就是人力成本逐年的快速提高。5、6 年前，一个人两三千一个月，一台电脑五六千，现在反过来了，人才越来越贵，电脑越来越便宜。

其次，各行各业系统性进入供大于求。也就是说，5 年再往前，你生产出来产品就可以赚钱，大家就拼命的建工厂，扩销售团队。但是现在大家想的是，我的良品率怎么提高一点，或者我的销售费用怎么再下降一些。这些要靠软件来解决。

再次，80 后的 CEO、掌门人开始接班。因为第一批 80 后也快 40 岁了，很多民营企业的掌门人都是 80 后了。对于他们来说，利用软件信息化来管理，是一个必然的趋势。

对于开发者来说，有几个领域是很大的机会。第一个是数据，因为数据每年都在翻番的暴涨，基本上我觉得每三年 10 倍，可能 10 年后就一千倍了，过去的技术栈已经很难去服务好未来的架构了。数据还有了新的各种各样的格式，比如图数据，IOP 的数据，所以我觉得数据无论是从它的规模，还是实时性，还是新的数据格式，创业都有巨大的机会。

第二个，新的技术架构，比如说容器的生态，比如软件定义网络，软件定义存储。在各个领域都有很多新的架构，在这些技术架构里边不管是做安全，做运维，还是做各种各样的这个架构下的产品，都有很多大的机会。

第三个是机器学习带来的一些机会，比如机器学习带来的安全的机会。还有机器学习在商业上的应用，可能通用的商业应用像人力、CRM 目前创业机会没有那么的大。但是在垂直行业的商业应用，比如农业、金融、医疗，机会都非常大。

Q：作为技术人，如何去把握住上述创业机会？

A：首先是要先人一步，因为企业级创业基本上打磨产品，做出一个不错的产品，至少要一到两年的周期。如果等风口来了再创业，一两年后产品出来已经赶不上了。你得先人一步看到这个所谓的风口，比如说两三年前做分布式数据库或容器生态的创业，必须要有这样的一个判断力和格局。

然后，要找到自己独有的经验。我觉得企业服务级创业不是 20 出头的年轻人能做的，它需要你过去的一些先进的经验。比如你原来是在京东做电商相关的大数据，或者原来在阿里云做实时数据，在这个领域有一流的经验，你去创业其实是一个把自己过去的经验快速的产品化，快速的形成商业价值的过程。

第三，必须要是个大市场，而且必须是系统完整的解决方案。说实话，技术创业怎么都能创，比如说我做个小的数据采集也可以，我做个小的集成公司也可以，但这个意思就不是太大了。所谓大市场是说，你能不能做软件定义存储，能不能做在线数据分析，能不能做分布式数据库？必须是个大市场，才能最后做出一个大公司。而且呢，要避免把这个事情给科技化，它本质上是一个产品化的东西。产品化指的是，我有个引擎特别厉害，但别人肯定不是想买个引擎，别人想买的是一个数据的方案，这个数据的方案怎么能够解决他的问题，这个是特别重要的。

我们有一个投资的观点是：创业的天花板比创业的增长速度要重要几十倍。这个怎么理解呢？就印证了我说的大市场。你看京东 2004 年成立，当年的 GMV 大概 1000 万人民币，2016 年大概是 9000 亿人民币 GMV，12 年涨了九万倍，大家觉得特别厉害。但是客观来说，年化增长只有 150%。你只要每年涨 150%，12 年就九万倍了。现在很多人觉得，我每年要涨 150%，300%，500%，殊不知你的天花板在哪里。因为增长是一个复利效应，就算是每年 100% 的增长，10 年也一千倍了，一个一年 5000 万收入的公司，10 年之后能做到 500 亿的收入吗？可能对 99% 的公司来说是天方夜谭。所以你现在最重要的事不是说我今年把增长从 100% 提到 150%，而是可以把增速降一降，全力投入到未来把天花板再提高 10 倍的工作中去。

为什么我们一直强调大市场，因为如果不是大市场，可能投完之后三年四年，还是每年有几倍的增长，感觉也挺爽的。但是三四年之后呢，就没增长了，因为天花板到了。反观大市场，可能有些公司每年翻番的增长，早期还不显山不露水，但是三年五年之后这个公司很快就做得很大。

Q：对于企业级服务的创业公司来说，获取及维护种子用户是比较头疼的事情，这方面有什么建议吗？

A：早期的种子客户，我觉得要符合几个条件：特别痛，不怕死，不怕麻烦。

“特别痛”是最基础的。你换位思考，我是个还不错的企业，我为什么要选一个初创公司的产品呢？公司特别小，我还担心它倒了。一定是他特别痛，你的产品刚好能把他特别痛这个事解决的特别好。

第二个“不怕死”。过去已经痛的不行了，再不上你的东西，他的业务也要崩掉了，或者是他天天写脚本，自己也崩溃了。你这个产品不是很成熟，没问题，上。

第三个“不怕麻烦”，也是因为特别痛。产品没什么像样的界面，都没关系，咱们赶快上。

我觉得千万不要去找那些所谓大公司，好像付钱能力很高，但是他没有那么痛，又怕死又怕麻烦。我经常说，你早期客户一定要去找产品价值高的客户，而不是商业价值高的客户。他虽然可能只付你二三十万，但是他特别痛，他比你还着急想尽快上线，这个是最好的客户。锻炼了产品，锻炼了业务。

创业公司很容易掉进“贪大求快”的坑。贪大就是特别想做大客户，大客户有几个问题，第一它流程特别长，把小企业给拖死了。第二，大客户需求多，很容易变成一个定制化项目。第三呢，大客户往往反应不敏捷，你跟他搞半天，其实最后是没有口碑的。

求快指的是什么？很多公司容易做着做着就做项目去了，比如有一个客户给我提了 100 项需求，我现在的产品只能满足 30 项，但是我一看，这个项目两百万，我就干了，70 个需求反正先定制化帮他解决了，这一搞就把自己拖死了。反过来，给我四五十个需求的客户只能付我 30 万，但这个才是真正磨产品和产品化。我觉得最优秀的公司都是产品化的公司，你什么时候听过 Oracle 给你做定制？没有的。一点一点的通过时间去做产品化积累，才能通过产品化做到最牛的公司。

我还有一个建议，就是不要去迎合资本市场。资本市场大家都是说马上要有收入，但是好的产品其实是需要磨的，产品一旦出来了，快速地验证了，融资就会变得非常顺利。所以早期大家不要在乎一城一池的得失，避免贪大求快，所有的精力应该集中在我们的产品能力怎么快速提升，怎么把产品化越做越好。这是最高的目的，而不是收入、PR 这些东西。

大咖对话 | 如何打造自我驱动型的技术团队？

你好！

本周作客“大咖对话”的嘉宾是青云 QingCloud CTO 甘泉。他拥有 18 年软件开发相关工作经验，曾先后在华为、IBM  软件实验室、百度等公司任职，对 Linux 操作系统、网络、存储以及分布式系统架构、软件工程等方面有比较深入的理解。今天，我们和他聊了聊如何打造自我驱动型的技术团队。

极客时间：以您的经验来看，如何做好技术团队管理，提升技术团队效率？

甘泉：软件开发是一个创新密集型的领域，同时它的创新越来越多的来自工程师，而不是管理者。因此，作为技术团队的管理者，就需要顺应这个变化，转变自己的管理模式。

第一，要鼓励自我驱动。 以前，通常是公司高层或领导者直接驱动，下面的程序员戏称自己是码农，领导让做什么就做什么。但现在，我们要鼓励他们的自我驱动，让工程师自己身体内部的马达转动起来，让他们自己考虑下一步该往哪里走，怎么才能做到最好？作为管理者，你要做的是设定一个目标，然后想办法让他们自我驱动的往前走，这是一个比较大的转变。

第二，要大胆放权。 既然要鼓励自我驱动，就不能把程序员锁得死死的，所以大胆放权。坦白讲，不少管理者都非常在乎自己手中的权利，不舍得放权。但其实大可放宽心，因为你放出去的权利还是你的，你能放出去就还能收回来，所以大胆放权，这个并不会对你造成什么伤害，管理者要有这个心胸。

第三，要避免纯管理者模式。 我见很多纯管理者，他们制定了公司的管理制度，他们会觉得之所以管不好，就是因为制度做的还不够好。我也认同，管理制度是有用的，但作为技术管理者，一定要想明白，如果你的公司都是能人、每个人都能非常高效的工作，那么你就不需要管理制度。

你之所以需要管理制度，是因为里面有一些庸人，这些庸人总是犯错或偷懒，所以需要制度来避免他们犯错。但你制定越多的管理制度，减少庸人犯错机会的同时，你也是在惩罚那些能人，给他们树立了太多的条条框框，让他们动弹不得。所以，作为一个管理者，你在制定这些管理制度的时候，一定需要克制自己内心的冲动，不要去做扼杀创新的事情。

举例来说，我们之前推出了分布式数据库 RadonDB 和分布式块存储 NeonSAN，这两个产品就是比较典型的例子，都是我完全放权给了它们的负责人，由负责人自我驱动，最后打造出了非常优秀的产品。

这里有两个关键因素，一个是幸运因素，这点无需避讳，能找到这样两个人是我的幸运。对我而言，他们比千军万马都要有用，这也是我常说的，有创造力的人要远比那些普通工程师有价值得多。

另一个因素是，管理者有没有给他们创造一个能自我发挥的空间。其实，相关的事情他们之前在别的公司也做过，那为什么之前没有做成，在青云就做成了呢？总的来说，就是我们给予了他们合适的阳光、雨露、土壤，给了他们能发芽、成长、结果的环境，激发了他们的潜能，把他们从看上去很普通的技术人，变成了青云的 Super Star，这是我作为公司的管理者需要去做到的。

我一直很反对管理者驱动太多，因为在那种情况下，你实际上是在为你个人去管理，是在维系你的权利，并没有为公司的核心竞争力增长这个目标去管理，这两者之间有很大的区别。

极客时间：您提到大胆放权，那如何确定放权对象呢？如何控制试错成本？

甘泉：这个其实不是问题，首先，放权的前提是他已经获得了你的信任，而你信任他的前提，必然是他以往的表现足够好。其次，放权并不是说把事情丢给对方之后，就完全不管了，如果真这么做，那就是管理者的失职了。

放权其实也是分阶段的，刚开始的时候，其实只是表示我准备好信任你了，但在你还没有真正做出成果之前，我们彼此之间的信任是有保留的。

这个阶段，作为管理者，需要去了解他的项目进度、Review 他的项目质量，Check 他有没有 On Schedule、有没有 Off Track，这些在项目初期都是需要密切关注的。当然，如果出现情况，大家应该就事论事，公平的去讨论，取得共识。

因此，说是放权，其实中间有很多实操的环节，实际上是付出了更大的精力的。

之后等他们做出成果，证明他们值得信任后，那我当然就敢完全放权给他们了，就像我上面举的例子，比如 NeonSAN 这个产品，下一代该往那个方向走、下一个规划应该是什么样的，作为 CTO 我都听对方的，因为他已经值得我信任了。但是达到这个 level 的人不多，每一个都是公司最重要的资产。

另外，我们并不会把资源完全往这些人身上倾斜，对于普通程序员，我们也会提供平等的机会。如果你有想法，我也会按照他们的标准给你创造一个自由的空间，看看你能不能抓住机会。

如果你抓不住，那没办法，说明你能力还不够，可以待在这个层级继续练级，但有的人就抓住了机会，往上进入另一个层级。这样，青云的员工就慢慢沉淀出不同的层次，但这样大家是心悦诚服的，因为这个划出来的层级，并不是我指定的，而是大家自己争取来的，由大家的能力来决定的。

所以，真正的平等并不是说在待遇上每个人均贫富，而是要给每个人相同的机会，机会的平等才是真正的平等。

极客时间：据您的介绍，青云的环境能极大的激励技术人成长，那么培养出 Super Star 之后如何留住他们呢？

甘泉：技术管理之所以难是因为你面对的是人，人是善变的，比机器要难管，但是这也有好处，因为人是有感情的。如果你给了他们机会，把他们培养成今天这样的人，他们会感谢你的。说他们会转身就走，我是不信的。

就算他们被挖走了，就算拿到了比青云更高的薪水，但是成长空间呢？大公司一个萝卜一个坑，挖他过去，需要的就是他之前在青云练就的能力与积累的知识。一旦这些知识贡献给了他们，又没有青云这样自我成长的环境，很可能最后耗光自己的积累与价值。

因此，我并不会像别的公司那样，把研发跟外界隔绝，生怕别人来挖。我反而会努力把他们培养成 Super Star，同时努力把他们推出去，支持他们多去参加大会、去做宣讲，建立自己的影响力。做管理者还是要有胸怀。

话说回来，那些纯粹为了钱的人也到不了 Super Star 这个 level，之前就会离开了。所以我也不会在这些人身上花费气力，走就走，没关系，留下来的、沉淀下来的才是公司最重要的一批人，是公司整个文化传播的种子。

极客时间：在您看来，技术管理者最重要的品质是什么？

甘泉：管理者最重要的一个品质是要有确定性。何谓确定性？就是指，你作为管理者，不管你在还是不在，团队都会按照一个共识去做事情。就算你不在，大家也都敢放心大胆的这么去做，因为你给了他们确定性，让他们知道这么做是对的，大家能知道对错、知道好坏。

最怕的就是管理者自身的不确定，因为大家会不由自主的去研究领导、去试探领导的边界，如果管理者不确定，那团队成员的精力可能就都放在琢磨领导身上，而不是琢磨事情上了。

尤其是对于自我驱动的团队而言，领导的确定性对于下属有着决定性的意义，你不可能让员工自我驱动的同时，又要不断的琢磨你的喜好，这样他会很迷茫，不知道该往哪个方向驱动了。

最后，如果你能确定性延续下去，就可能达到“无为而治”这样极高的管理境界，可能看着管理者什么都没做，但其实整个公司都在他的 Control 之下，按照统一的价值观做事。这样的团队，战斗力怎么会不高呢？

大咖对话 | 如何高效管理8000+规模的技术团队

你好！

本周作客“大咖对话”的嘉宾是苏宁易购 IT 总部执行副总裁乔新亮。乔新亮拥有 16 年企业架构规划设计和系统集成的工作经历，曾任 IBM 全球咨询服务部副合伙人，现担任苏宁易购集团 IT 总部执行副总裁，全面负责苏宁易购技术管理和项目管理工作，在苏宁转型的历程中，亲历了苏宁技术团队从上百人到 8000 人的急速扩张及发展。

极客时间：苏宁现在的技术团队有 8000 多人，您如何管理如此大规模的技术团队呢？

乔新亮：这几年苏宁一直在快速扩张，技术团队从四年前的 1000 多人，发展到现在的 8000 多人，到今年年底肯定会超过一万人。在这个快速扩张的过程中，涌进来了很多不同背景、不同水平的人，给管理带来很大的挑战。

我们的做法是打造一个数据化管理体系，力争做到不管进来的人是什么背景、什么水平，都能顺利的融入到这个体系里面，能有发展的空间、能发挥自己的能力，否则就会很麻烦，会冲垮苏宁原本的团队、流程、文化等所有东西。

而体系的基础是数据，整个业务、交易都要去做数据化。举例来说，今天，我们对每一个上到生产的服务都有管理，服务之间的关系也有管理，包括这些服务之间的契约是否清晰、每个服务的响应时间是多少等，全都被数据化，并纳入体系管理。

我们会根据这些数据做宏观的把控，规划苏宁的前进方向，同时，我们也会把这些数据提供给各个团队，赋能给他们，让他们依据这些数据自我管理。

总的来说，我们这些年一直在努力做的，就是把 IT 管理的对象数据化，并以此为基础建立体系化的技术管理机制，并把数据赋能给各个管理团队，让小到一个经理，大到上面的总监、总经理都能看到他们团队各方面的数据，然后以此为依据进行管理。

到这时候，当体系真正搭建起来之后，团队是 1000 人和 8000 人就没有太大的关系了，我能管 1000 人，就能管 8000 人，甚至再扩张到上万人也没有问题。未来，我们还可能会把这套体系作为对外输出的苏宁云的一部分，甚至是其中的核心价值部分。

极客时间：有了体系和数据之后，您具体是如何执行管理的呢？

乔新亮：简单的说，就是产品化，一切以产品的维度来管理。当这些数据被汇集起来之后，会先汇总到产品，而不是人，因为产品才是更贴近业务、对用户或客户更有价值的东西。汇总到产品之后，再将评价数据具体分配到团队、个人，而这中间都依赖于此前的数据化基础。

此外，苏宁的管理也从原来的偏向架构技术的管理，到今天所有的都围绕着产品和核心能力。具体来说，就是所有的内容，包括架构、稳定性、安全性、项目等都会汇总到一个产品维度去看，以架构管理为例，最终我要看的就是这个架构对产品有什么价值、能产生多少价值。

我们在实践中也发现，这套数据化管理体系再加上相应的绩效管理，对整个团队的倾向性影响是非常大的，基本能做到指哪打哪。这样就可以做到在一定时间内聚焦在某些方面，把这些方向做到一定成熟度后，就可以相对弱化它，再去强化其他方面，这样公司整体就能一块一块地补上薄弱部分，最后形成一个优秀的整体。

比如我们经常组织的稳定性月、安全月、用户体验月等活动，就是聚焦大家，让大家一起去着重提升某个方向。

这点也是我觉得在管理中很重要的，就是一定要在一定时间内聚焦，不能铺得太开，否则一方面是研发团队忙不过来，也做不到极致优秀，就可能失去动力；另一方面，站在用户的角度，他们也没法看到产品特别明显的进步。

所以，管理既要有完美主义，又要有不完美主义。从大处着眼，你得想得完美一点，规划得完美一点；从小处着手，你就得接受你在聚焦的点之外，系统还存在的不完美之处。而在这个过程中，管理者需要不停地用数据去衡量，看看当前的方向与进度是否需要修正。

另外还有一个更大的好处在于，原来绩效考核可能是一个月甚至是一个季度的，现在变成了实时反馈，大家就知道自己该往哪个方向努力。这就像打仗一样，现在已经能指挥到单兵了，而且是实时指挥，这在过去没有数据化的时候是很难做到的。

极客时间：在如此体系化的管理之下，如何激发技术人员的积极性呢？

乔新亮：我之前谈到，所有的管理都得有数据，然后都得有评判，但评判不代表批判，一般的管理都比较倾向于惩罚，但我们希望用激励代替管理，尽量减少“管”的部分。

比方说一个产品，原本是 60 分，极致的目标是 100 分，现在团队做到了 80 分，可以说它还差 20 分，但我更希望是鼓励他们提高了 20 分，如果他们真的做到了 100 分，那更是要大大地鼓励与奖励。

我们希望在苏宁的技术管理体系里面打造一个激励机制，鼓励员工们不断向上，鼓励大家不断解决问题，不断提高自己水平。

除了传统的激励措施之外，苏宁也在打造一个内部创业机制，每一个团队都可以申请以创业公司的方式去推进，也就是驱动型的创业生态。

而什么叫创业公司，说的俗一点，他创业成功了，他就财务自由了。我们也是用一样的方式，比如说，顶层的，你的产品能够去占领市场，或者底层的，你的产品能为公司占领市场做出贡献，你就能不断拿到融资，不断拿到苏宁云的天使、VC、PE。

以后可能大家的薪资构成就是月薪、奖金、股权和期权，也有完整的体系，相当于是拿着薪资在创业。这样做，除了能激发主观能动性以外，也会给团队以压力。简单来说，团队就是一个创业公司，而创业公司是有压力的，如果你把钱花完了还没有达到目标，那么你就是失败了，没什么可说的。而如果你成功了，你就能获得更多的资源，拿完天使拿 VC，拿完 VC 拿 PE，一直拿上去，相对来说会更公平。

同时，这样的机制也能把更多的优秀人才吸引进来，毕竟我们可以给对方提供平台、基础设施、客户关系等各种资源，还可以提供资本支持，降低对方的创业风险，让他们可以在一个没那么紧迫的环境里好好打磨产品、实现想法。

目前，这个内部创业机制我们还在完善，最终，我们希望能用投资代替管理，以此来解决整个激励问题。想想看，如果真的能把八千到一万个人的主观能动性激励出来，让他们觉得是在为自己拼搏，那一定会带来很多不一样的变化。

不过也不能急，当这边的体系还没建立起来的时候，传统的管理肯定是要继续的，要慢慢的、有序的切到这边来。

极客时间：在打造苏宁的数字化管理体系的过程中，您遇到的最大的挑战是什么？

乔新亮：最大的一个挑战还是利益和信任问题。我们必须要承认，一个管理者他有好的地方，肯定也有不好的地方，这是很正常的事情，如果所有都很好的话，也就不需要管理了。

所以，一开始说要数据化，把所有数据都呈现出来的时候，大家会觉得我的所有问题都暴露在了阳光底下，会被所有人都看到，会觉得不高兴，甚至会抵制。

这个时候，作为最高管理者，你要打消大家的这种想法，不要让对方觉得你搞这个数据化是为了找他问题，而是要让他觉得，你的本质是想帮他成功、帮他把管理做好。

所以，要想消解对方的抵触，改变他们的想法，首先就是要沟通，一定要跟对方说清楚讲明白这件事情对他们的好处。毕竟他们也是团队管理者，下面可能也带着几十、几百号人的团队，他们对管理也有痛点，而这个数据出来之后，对他们管理自己的团队也是有好处的。

简单来说，就是要让自己跟他们站在一边，不要跟他们站在对立面，而是要表现出我给你提供数据、提供工具、提供手段，是来帮助你做管理的。

其次就是一定不要先上绩效，要先出数据，让大家看到这么做的好处。一旦先跟绩效挂上钩，那么大家的反弹一定是非常厉害的，甚至会出现隐藏作假的现象。像之前提到的数据，一定要留有几个月的缓冲时间，让他们看到数据的好处，当基于这些数据，大家都有了实质的提升之后，再慢慢把它跟绩效考核结合起来。

所以，管理者一定不要跟那些被管理的对象站在对立面，也不要高高地站在神坛上，而是要变成他们的盟友，要打心底里相信，我现在做的事情是对对方有好处的，是在帮助对方提升。

至于之后真正收集数据、搭建系统的过程，我反而觉得只是项目推进的问题，真正难的还在于人心，在于如何建立这种信任机制，这一点，甚至比管理本身更重要。

大咖对话 | 季昕华：以不变的目的应对多变的技术浪潮

你好！

本周作客大咖对话的是 UCloud 联合创始人兼 CEO 季昕华，他有着超过 15 年 IT 及互联网行业管理经验，曾就职于华为、腾讯、盛大，历任经理、副总经理、首席安全官、CEO 等职位，曾全面负责腾讯安全体系建设、盛大云计算平台的研发及管理，对云计算、安全行业具有丰富的经验和深刻的见解。今天，我们和他聊了聊创业、技术管理等相关话题。

极客时间：您为什么会选择云计算作为您的创业方向呢？

季昕华：看过我的经历都知道，我原本是做安全的，但是创业的话，一方面觉得安全的市场不够大，未来发展空间比较有限。另一方面，我之前的工作中接触了很多黑客，他们技术不错，却只能通过写木马、写病毒谋生，所以想试试能不能给这些人提供一个好的环境，让他们能够通过技术合法的挣钱。而云计算正是这样一个方向，能够让每一个有能力写代码的人，都可以利用云平台的资源发展起来、挣到钱。

我们公司的使命就是“用云计算帮助梦想者推动人类进步”。有很多技术人有很好的想法，也有很好的技术，只是缺少资源，我们希望能通过我们的服务帮助这类梦想者实现梦想。过去几年，我们支持的公司中，接近 80% 的都是这样的创业公司，其中很大一部分都已经成功了，而且现在规模越来越大。

极客时间：您觉得云计算行业当前的发展趋势是怎样的？

季昕华：云计算经过十年左右的发展，整体行业已经趋于成熟，但整个市场其实才刚刚开始。目前国内云计算市场规模已经突破千亿大关，但市场渗透率只有 5%-7%，非常低，仍然处于相对早期的阶段。

不过，当前市场正处于飞速增长的阶段，像我们公司基本上每年都能达到百分之百以上的增长。整体的客户规模也在不断扩大，以 UCloud 为例，从最初的游戏客户，到电商客户、O2O、互联网金融，再到现在的传统行业，如银行、医疗、政府等都开始尝试云计算，整体规模越来越大。

至于云计算创业，云计算的概念一直非常火，我们 2012 年刚开始创业的时候，云计算领域的创业公司非常多，竞争非常激烈，但之后随着我们的快速增长，回过头去看，发现跟上的、留下的公司越来越少了。不管在哪个行业，公司是否能活下来，最关键的一点就是你能否为客户创造价值，其次是能否用好的、新的技术持续为客户创造价值。这两点是最关键的，一是能创造价值，二是能持续的创造价值。

举个例子，我们有个客户是典型的电商公司，平时有很多电商流量，在 618、双 11 等时候又有很多突发流量需要响应。它本身也有一些服务器，如果全面转向云服务的话，自己的服务器就浪费闲置了，对此，我们以他们的需求为驱动，提出了混合云方案，在接管对方服务器的同时，提供部分云服务，实现了业务的弹性，也提高了公司的整体价值。

另外，我们还成立了 UEP 组织，帮助客户融资、找流量、做广告等等。我们是第一家帮客户在地铁里做广告的云计算公司，后来这个方式也被阿里和腾讯借鉴了。其实归根到底，我们做这一切的核心目的都是为了帮助客户，毕竟只有客户业务做得好了、赚钱了，他们才会愿意把钱花给我们。

极客时间：作为先行的技术创业者，您会给想创业的技术人哪些建议？

季昕华：我是技术出身的，在创业的过程中遇到了很多困难，踩过很多坑。现在回过头来总结一下，技术人创业首先要做好准备，我们都知道创业很辛苦，但实际上，创业只会比你想象的更辛苦，一定要做好心理准备。

其次，技术人在创业过程中一定要发挥自己的技术优势。当然，创业不同阶段需要做的事情不同，当公司规模达到一定阶段后，你反而要放弃自己所有的技术优势，去做那些你可能不擅长，但又必须得做的事情，比如销售、市场、财务、投融资等。

其实，以我作为创业公司 CEO 的角度来看，技术创业可以分为四个阶段。第一个阶段，做自己想做的事情；第二个阶段，去做那些不想做，但又必须得做得事情；第三个阶段：找到一群合适的人，去帮你做那些你不想做，也不擅长的事情；最后一个阶段，有机会去做那些自己内心真正想做的事情。

目前，我还处在第三阶段，还在努力找一些合适的人，来做那些我不想做但是又必须做的事情。

极客时间：新技术、新模式层出不穷，在您看来，该怎样应对这不断变化的技术浪潮？

季昕华：技术一直在不断变化，每年都有各种各样的技术趋势出现，而应对技术浪潮，最核心的要点就是，变化的是技术，不变的是目的，这一点非常关键。

在我看来，任何技术都是为商业服务的，所以我们要围绕我们的商业目的、商业手段去选择所需的技术。

在互联网行业，一般产品研发有三种模式：第一种是技术驱动型，技术特别好，舍我其谁，只有我能干、谁也干不了；第二种是竞争对手跟随型，绝不捣乱，老大干什么、我就干什么；第三种是用户需求满足型，用户要什么、我就干什么。

UCloud 就属于第三种，公司存在的价值是为用户创造价值，当你为用户创造价值的时候，用户才会真正给你收益，你才能给员工回报、给股东回报，这才是一个完整的公司生态链。

极客时间：关于技术团队管理，能否分享一些您的经验呢？

季昕华：要做好技术团队管理，我觉得以下这几点比较关键：第一，要有一个比较大的梦想，这是非常重要的；第二，要让技术人员感知到，他们做的事情在直接对客户产生价值，让他们有成就感；第三，要坚持技术导向，让技术人员觉得他们能在这里学到东西，比如如何处理大规模的海量并发任务等，这些是技术人员比较感兴趣的。

而技术人在转向管理的时候，面临的最大的问题就是思维上的转变。举个例子，某个问题自己几分钟就能搞定，但交给下属可能需要好几天才行，这时作为技术 leader 就一定要克制自己，不要亲自去解决问题，否则虽然对解决问题有帮助，但对团队管理却并无好处。

这就是挑战所在，其实就是看你能不能放弃自己的技术优势，给团队机会，让年轻的团队按照你的方向和思路往前走，给他们带去成长，这样你自己才能有更好的成长。

大咖对话 | 对人才的长期投资是人才体系打造的根本

你好！

本周作客“大咖对话”的嘉宾是 Comcast 全球副总裁、FreeWheel 高级副总裁容力博士，在加入 FreeWheel 之前，他曾就职于雅虎和微软，具备多年技术管理经验，并在搜索广告、展示广告和视频广告领域拥有深厚的知识储备和业务理解。今天，我们和他聊了聊如何打造自己的人才体系。

极客时间：以您的经验来看，如何打造高效的研发团队？

容力：作为一家以技术创新为主要发展手段的新兴企业，我们在市场上面对的是全球顶级的竞争对手，因此，一支高效的有持续活力的研发团队是我们的竞争基础。我们会从以下几点出发：

优秀人才是打造高效研发团队的基础，因此，在招贤纳士时我们始终秉承“Hire the Best”的基准和原则。但 Hire the Best 的难点在于，不能只看他现在会什么，而是要预测他将来是否能更快地学到更多。技术人的学习能力，其个人长期的潜质和潜力应该在面试环节得到更多的加分。

技术引领的创新是我们公司从创立伊始就一直秉承的公司文化，也就是工程师文化。我们认为这样的工程师文化，为我们营造了一种浓厚的技术氛围，能促使研发团队持续高效运转。

优秀的管理层是必要条件，我们鼓励从研发一线选拔出积累了丰富的实操经验、具备国际视野和深厚技术背景的管理人，从管理层面 empower 潜心研究前沿技术领域的技术大牛。

持续不断地优化流程，使其适应变化，结合 project 和 squad 模式对资源进行有效管理，并根据优先级合理分配资源。

管理层非常重视跟员工之间充分、开放地沟通。比如技术层面和商业模式层面的信息，都可以在领导层和员工之间做到充分的沟通和共享，使得员工能更好地把握整体方向、理清事情的优先级，做对公司最重要的事情。另外，大家做事都是本着平等开放的原则，不会因为说话的人不同，就对他提出的问题或者方案持有不同的态度，不因人废言，更不因言废人。这样做更能激发大家的积极性，充分发挥每一位员工的创造力。

极客时间：FreeWheel 非常注重人才培养，那您能否分享一下 FreeWheel 的人才培养体系？

容力：对人才的长期投资是我们搭建人才培养体系的根本出发点，我将从人才招聘、人才培养、人才留存三个方面分享一下 FreeWheel 的做法。

首先是人才招聘方面：

FreeWheel 有着自己的“文化基因”，我们始终鼓励技术引领创新，加上多年对行业的深厚理解和积淀，造就了今天的市场地位。我们所做的事情时刻反映着我们的理念，我们认为，理念和价值观的契合是十分重要的，在这个前提下，我们能为他带来什么、他能为公司带来什么、双方能否达到长期的互相认同——这三点是我们在甄选人才时始终在强调的。

我们认为人才培养是一个长期的投资，所以我们非常看重候选人的发展潜力，强调对市场和业务的理解。

我们看中人才的国际视野，我们的定位和立意是全球化，即我们研发的产品，是为全球客户服务的，而不是为某一个或几个特定的国家服务，因此，我们的技术团队、我们的员工必须具备国际视野。

其次是人才培养方面：

我们为技术人提供技术路线和管理路线两条上升路径，两者并不互斥，他们可以根据自己的兴趣与特长选择适合自己的道路。

FreeWheel 建立了非常完备的培训系统，设有专门的培训团队，并划拨专门的培训预算。我们会为员工提供不同维度的培训机会，包括技术培训（技术分享、技术大会、专业培训、技术书籍等）、软技能培训（英文、演讲、领导力、沟通等）和业务培训（高端视频市场及广告业务方面）。

最后是人才留存方面：

打造归属感和个人影响力。我们团队所研发的产品的每一个功能，都是客户迫切需要，并且能为他们带来明显收益的，因此每一个人的工作重要性和回报都显而易见，每一个人都在时刻对公司发挥着个人影响力。这样的高要求，加上十分紧密的团队合作、带 FreeWheel“文化基因”的做事方式，最终会带给个人强烈的归属感。

轮岗制。加强全球各部门之间的沟通，加深工程师对不同区域市场的理解，是轮岗制设立的初衷。前面我提到我们很看重员工的国际视野，轮岗制正是建立和提升我们员工国际视野的有效机制。尤其是我们的轮岗不仅仅是在纽约和北京两地，也包括了美国西海岸以及欧洲，并且是多向而不是单向的。

极客时间：在您看来，好的技术团队组织架构是怎样的？不同阶段该如何做好规划？

容力：当一家创新公司从初创走向在市场引领者地位时，如何“不忘初心”，坚持以技术创新作为导向，保持企业的活力，是摆在管理者面前的一个难题。

在我看来，一个高效的技术团队应该以任务导向为主，人际导向为辅，并需要具备以下特征：

目标和任务是明确的；

共同的行为准则是明确的；

如何衡量绩效是明确的；

决策是高效迅速的。

此外，不同阶段，技术团队的侧重点也不同。

首先是初创阶段，与所有初创公司一样，大家有明确的共同目标，组织架构和人际关系作为辅助手段的作用尚不显著。

其次是百人规模阶段，100 人是通常可保持稳定相互关系的一个阈值。此时，团队正式从“部落”进入到“村落”阶段，必须要建立两级管理制度，并明确分工。在这个阶段，团队之间如何协调会成为管理层必须关心留意的一个问题。

接着千人规模又是一个新的阶段，FreeWheel 现在就处于这个阶段，我们全球有约 800 位工程师，北京占 300 余人。此时的团队从“村落”进化到“城镇”，在管理中尤其需要注意以下几点：

需要不定期审视组织架构并对其进行优化；

为确保团队的高效，需保证团队上下对企业愿景和使命的理解高度一致；

保持竞争力（狼性），有些公司鼓励内部项目竞争，我们则希望通过别的方式，尤其是希望以技术竞争替代项目竞争达到同样目的，Hackathon 是一个例子。

极客时间：在您看来，一个优秀的技术人最应该具备的能力或素养是什么？该如何更好的培养、锻炼这一能力呢？

容力：正如我之前提到的，优秀的技术人他应该要具备强技术硬实力、国际化视野、对业务逻辑和市场需求的理解力，以及扩散自身影响力的个人软实力。不过，对技术人才的要求是随着大环境的变化在不断变化着的，这一点是技术管理者在建立人才体系时需要注意的。

大咖对话 | 张建锋：创业可以快而大，也可以小而美

你好！

本周作客大咖对话的嘉宾是永源中间件共同创始人张建锋，原红帽公司 JBoss 应用服务器核心开发组成员，曾供职于金山软件、IONA 科技公司，在分布式计算、企业应用设计、移动行业应用、DevOps 等技术领域有丰富的实战经验和自己的见解。今天我们聊了聊技术创业的相关话题。

Q：您能先简单介绍下自己，以及您目前主要负责的工作方向吗？

张建锋：我的工作一直在技术领域，曾供职于金山软件、IONA 科技公司、红帽软件等，2015 年出来创业，负责公司的经营管理和技术方向的把控。目前，我们的主要业务是国内中间件技术相关的内容，包括产品、二次开发、咨询、培训，等等，下一步的方向可能是云计算相关产品。

Q：您为什么会选择中间件作为创业方向，当前的市场情况如何呢？

张建锋：我先回答第一个问题，选择中间件作为创业方向，有三个原因，第一，很简单，以往的工作经验都与中间件技术相关，对这个领域比较熟悉。

第二，我们认为中间件在国内市场还未达到它应有的规模，国外做中间件软件的大公司较多，比如甲骨文、IBM 等等，虽然这两大公司从操作系统、中间件、数据库到应用系统都有提供，但是中间件依然拥有非常重要的地位，甚至在 21 世纪初，中间件带来的收入占据了整体营收的大比重。我个人觉得，国内也应该有这样量级的软件企业，作为一个有技术追求的人，我们应该做这件事。

第三个原因是，在很多企业项目中，中间件都占据重要的位置，但是国内的采购行业几乎都在用国外中间件产品，这其实是一个机会，国内也可以有这样的厂商能够提供优秀的产品和服务。

第二个问题，对于中间件目前的市场情况，从微观角度审视，发展态势不是很好，但从宏观角度来看，仍然有较大的探索空间。

在云计算兴起以前，国内的技术软件市场分三大部分，即操作系统、中间件和数据库，操作系统大家都很熟悉，比如 Windows、Mac OS 等，数据库有甲骨文、IBM 等公司，而中间件是介于操作系统与应用程序之间的软件，我们在使用中间件的时候，一般是由一组中间件集合在一起，构成一个平台，而其中必须包含通信中间件，相当于中间件是平台和通信的集合。

云出现以后，中间件的角色发生了一些变化，国内规模较大的互联网公司都有专门的中间件团队，而且目前很多云服务商提供的解决方案中就包含了许多中间件相关的内容，等于将中间件囊括进云的解决方案中了，亚马逊、阿里云等解决方案中都包含有消息系统相关的产品和服务，这原本都是中间件的范畴。

尽管如此，中间件软件的价值依旧值得我们将其作为创业方向，只是面对云的冲击，我们不能固步自封，需要适应市场变化、调整方向，向着与云计算融合的方向发展，从这个方向中探索出更广阔的市场空间。

Q：在这样更偏技术软件的方向创业，您觉得需要注意哪些问题？

张建锋：我觉得很重要的一点就是要保证健康的现金流，现在大多数面向 C 端的互联网创业公司，都是选择先用融资的方式做大公司规模，再找到某个市场点切入并快速发展的模式。这样的模式风险会比较大，投资、融资是一种重要的资金流转方式，但当资本环境发生变化时，融资这条路就会受到很大的影响。

坦白讲，互联网行业、软件行业、电子行业的成本都比较高，如果融资方面的供血不足，公司可能就会出现各种各样的运营危机。从公司运营的角度来讲，能够获得外部融资是一件好事，可互联网行业把融资看得太重了，好像没有融资就不会成功一样。我个人认为，我们创业时，可以把融资当作锦上添花，它能够帮助我们更快速的发展，但也需要考虑到没有融资的情况下，公司如何能够存活并健康发展。

再者，一家创业公司最终能否成功，很大程度取决于它的商业模式是否成熟。能够将商业模式理顺，提供具有竞争力的产品和服务，同时保证健康的现金流量，这样，无论处于什么样的经济环境，创业公司都可以存活，甚至稳步向前发展。

不过当前创业圈的现状是，很多创业公司都没有没有成熟的盈利模式，或者它的盈利点难以支撑它的成本，所以就会依赖于融资，希望资本的钱进来之后能够推动它先更快速的发展，等规模上来之后再找到盈利模式。但是，资本最终都要找到一个退出机制，如果在市场不景气的情况下，难以找到令人满意的退出机制，就没有人愿意冒险投资，创业公司赖以生存的资金来源自然也就断掉了。特别是在这两年，受市场大环境影响，整个投资环境都呈现出收缩态势，不少创业公司都受到了很大的冲击。

另外，我们作为 B 端的技术创业公司，还需要注意的一点是，一定要耐着性子打磨技术，先打磨出一些领先性或具有独特竞争力的产品和服务。这可能跟 C 端的、面向用户的创业不太一样。

以我们为例，我们在中间件这个领域有着多年的积累和领悟，能在此基础上打造出行业领先的产品。同时，相对国外的软件公司，我们对国内市场有更深的理解，能够按照国内市场的技术产品需求，做出针对性的改进。软件本身没有国界，但对于客户来说，不同国家、不同地区，都有着不同的需求，所以，即使是国外的大公司在国内做生意，多少还是会有一些水土不服，而我们作为本地人，更了解本地市场与客户的需求，提供的产品与服务也会更适用。

Q: 作为技术出身的创业者，您对技术人创业有何建议？

张建锋：技术人创业并不是件容易事，但如果你选择创业，要么将注意力主要集中于技术，找一位非常合适的合伙人来承担技术之外的事情；要么自己走出舒适圈，既把控技术方向，又学着去管理团队、运营公司，接触各种各样的人，学习各种各样的技能等。这两条路其实各有各的困难与挑战，就看你怎么选择了。

以我自己为例，我目前是既负责公司经营又把控技术方向，这样能够全面地了解创建和运营一家公司的各个方面。在我看来，技术很重要，但不是最重要，商业部分也很重要，这就需要我们向团队内外的各个角色学习，包括销售、市场、财务等，了解各方面的相关知识，同时也需要学会和人打交道，无论是对内部的团队成员，还是对外部的客户，我们都需要做好沟通。

另外，目前很多媒体或投资者的口径是，好像创业只有一条路，就是一定要瞄准上市目标，追求公司快速发展，争做行业第一，争做独角兽。但其实创业并非只有这一条路，快而大不错，小而美也很好，你其实可以选择一个自己喜欢的技术方向切入，做到能在行业立足的规模，很多 B 端的或者跟地域关联比较密切的行业，都能提供这样的选择。这样压力没有那么大，也能在创业路上见识更多的风景，不断丰富自己，不断获得成长。

目前我就处在这样的状态，能够在熟悉的领域比较自由的做一些自己喜欢的事，已经非常开心了。总之，如果你有想法，希望能做出一家行业数一数二的独角兽公司，那是非常值得敬佩的选择，但如果你只是想做一些自己喜欢的事，那找准方向，做一家小而美的公司也未尝不可。毕竟人生有着许多不同的选择，我们不能武断的说哪种选择就是对的，哪种选择就是错的。

大咖对话 | 彭跃辉：保持高效迭代的团队是如何炼成的

你好！

本周作客大咖对话的嘉宾是 Keep CTO 彭跃辉，曾于 2010 年加入豌豆荚，从零开始搭建豌豆荚的应用搜索，打造最全、最准、最快的内容库。2016 年加入 Keep，搭建近 200 人的技术团队，带领团队快速迭代，通过内容、数据和智能打造运动的闭环，Keep 长期稳居健康健美的榜首。今天我们主要与他聊了聊搭建高效团队相关的话题。

极客时间：您能先简单介绍下自己，以及您目前主要负责的工作方向吗？
彭跃辉：我毕业后加入豌豆荚，主要做应用搜索、内容库相关的工作，2016 年 3 月份来到 Keep，当时 Keep 的技术团队大概有 20 多人，现在整个团队有 200 多名技术人员，成功搭建了一个迭代稳定高效的技术团队。目前主要专注于运动领域，包括 Keep APP、智能硬件、线下体验空间等。

极客时间：那在搭建高效的技术团队上，能否分享一下您的经验呢？

彭跃辉：在团队搭建及管理方面，我可以分享一下我们的做法，主要有四点。

第一，引入 OKR，并把它定位成沟通和管理工具，使团队对目标的理解保持一致。我们在确定每个团队的核心目标时，不论向上还是向下，都会进行几轮沟通，确保大家理解一致。核心目标确定后，会从多个维度考虑怎样衡量这个目标，一般会将目标数字化，划分为具体的数据指标，相当于 OKR 中的关键结果。，再根据 OKR 去设定每个季度的 Roadmap，这样做的好处是大家的目标会统一。同时，在执行的过程中，我们会每三个月 Review 一次，并在 Review 的过程中对目标进行调整。

第二，提倡数据驱动，不管是技术优化还是产品功能，甚至是算法，我们都会去设计它的数据指标，像一些比较长期的改动，我们都会设定较多的 AB 测试，通过 AB 测试验证我们的改动对用户是否有效。为了做这件事，我加入 Keep 的第一件事就是搭建数据系统，现在被叫做数据中台，相当于提供了一套可以交互的数据查询系统。除此之外，我们还搭建了 BI，即商业智能分析及调度系统，进一步用好数据。

当然，在打造数据中台期间我们也遇到了很多挑战，其中数据是最核心的一个问题，确保数据准确就花了很多时间。数据不准确有很多方面的原因，有可能是因为对目标的定义不清楚，也有可能是产品经理提的需求不够准确。即使目标是准的，需求也是准的，但在开发的过程中，不同开发人员的技术能力不一样，有时候也会导致数据不准确。再到后面进行数据分析的时候也会出现很多问题，比如每个部门对数据的理解不同，等等。

为此，我们做了一些工具来解决这些问题，比如需求评审时更细致，在开发过程中进行灰度测试、半自动化测试等，以及搭建数仓等基础设施，把公司内各部门对相关数据的定义统一起来，使数据的维护与管理在一个统一的系统中进行。现在，不仅技术、产品、运营、市场等部门的同事在使用跟数据相关的系统，我们也正在跟财务、市场等部门对接，将一些财务相关的数据也打通，从而提高公司整体的运营效率。

第三，工具的使用，我们鼓励团队成员使用工具来提高效率，并给予一定的费用支持。我们现在用的是 Phabricator，这是 Facebook 的一个代码管理和项目管理的工具，通过 Phabricator 我们进行敏捷迭代，基本保持每两周一个迭代的频率，给用户提供一个稳定的版本，除非过年，或者十一期间可能会有延期发版的情况。除了 Phabricator ，我们还会使用谷歌的一些套件，如日历、邮箱、共享文档等，我们比较提倡通过在线的方式来评论、协作和交流工作。

第四，做好技术人员的成长路线，主要会从两个方面着手，首先，打造技术人员的专业定级体系，这点很重要。我们会从多个维度去定义一个工程师的级别，很多工程师选择走专业路线，那他得知道自己当前的位置在哪，要到下一个级别还有哪些欠缺等。我们从 2017 年 10 月份开始对技术人的专业定级，给他们提供了一个明确的成长路线，我们也会根据定好的级别来调整他们的薪水、奖金等，逐步打造了一个相对完善的技术职级体系。

我们每年都有两次技术定级的答辩，到高级工程师的级别后，此后每一个小级别的晋升都需要进行答辩。答辩规则是 5 到 7 人评审，两票否决制，一旦有两个人否决，则答辩失败。

其次，组织内部分享和外部交流，我们内部每一个小组，都会有半年到一年的分享计划，也会经常跟一些其他行业的人沟通、交流。我们和谷歌、苹果的合作较多，每年都会挑选优秀的员工去参加 Google IO、WDDC 等大型会议，由公司承担机票、酒店等费用。另外，我们是腾讯投资的公司，所以也会去参加腾讯举办的各种培训。

一般团队的架构都是三角形的，级别越高的人越少，处在三角形底边的人更多，但我们现在正在通过以上提到的这些方法，慢慢让这个三角形的底部变窄，相当于将初级技术能力者的比例减少，增加中层级别甚至高级别的技术专家，将整个团队往精英化方向打造。

极客时间：Keep 现在基本稳定保持两周迭代一次版本，这是一个很大的挑战，能否分享一下你们在这个过程中遇到的困难？你们又是如何解决的呢？

彭跃辉：中间的确是遇到过很多挑战，最初，保持两周迭代的问题是我们的交付内容不能得到保障，从产品到技术再到测试，每个环节都可能出现问题导致最后影响到迭代周期与质量。反思过后，我们明确了整个流程，以及每个职能在各个环节要做的事。在实践中，基于两周迭代一次这个事实，我们将整个迭代分成几个不同的环节，虽然每两周一个迭代，但你可以认为这两周是一个开发、测试的周期，而我们在每个迭代开始前一周，就会开始需求的评审评估，并在当周内将需求确定，然后在迭代开始前就制定好具体的排期表，明确各个职能在不同阶段和不同时间点该交付什么内容。

到第二阶段，业务增长后变得复杂了，团队成员也增多了，很多时候项目需要依赖其他部门，这时就会发现项目对接或项目推进上出现了一些问题。对此，我们为每个小项目设定一位总负责人，他来负责跟其他技术团队对接，他会去推进前端、后端、客户端等整个流程。

另外，我们会在每一个迭代中，都产出一份数据报告及质量报告，数据报告更多是产品功能层面上的数据表现，包括技术改进、优化的数据等。质量报告会显示一些版本信息，比如崩溃率、首页加载时间、某些业务核心指标等，相当于质量部（包含 QA 和运维 SRE）每两周输出一份质量报告。各个职能的成员就可以根据这些数据，有针对性的提升和优化本部门的效率和质量。这样也就形成了一个较为完善的迭代和反馈优化的节奏。

极客时间：在您看来，技术人如果想走上管理路线，该如何打开边界提升自己的管理能力呢？

彭跃辉：我们现在对技术管理者的要求分为三部分，第一部分是技术能力，他需要具备把某功能或某业务实现并实现好的能力，我们会通过质量、效率等维度评估。技术能力是技术管理者最基础的一项能力，除了自身成长外，我们也会提供各种技术学习活动，比如内部分享、外部交流，以及利用更复杂的项目去锻炼中层管理者等。

第二部分是对业务的理解能力，比如，你需要知道这个业务未来的方向，以及你的技术架构如何为这个业务服务，包括在当前阶段，应该做什么事情，不应该做什么事情。我们希望技术 leader 能够发现业务的问题并解决它，从而推进业务进一步发展。我们有很多功能都是由技术 Leader 提出并推进的，包括从提出需求，到落地需求，再到负责相关数据的整个迭代过程。

针对技术管理者的业务理解能力，我们会定期组织大家针对业务中存在的问题进行开放性讨论，让大家畅所欲言，从实践结果来看，这个方法比较有效。另外，针对公司中层管理者以及其前线的管理者，我们会统一组织管理能力培训，包括领导力、沟通、文化、绩效、财务等诸多方面的能力。

第三部分是创新能力，对于创业公司来说，会比较看中技术 leader 的创新能力。我们会鼓励技术 leader 去做一些有挑战的事情，比如我们会把 hackathon 中产生的一些点子，落地到产品中做成某项功能。比如最近要上线的游泳记录硬件，它可以记录游泳的姿势、游泳的距离等，就是在 hackathon 中产生的 idea。

以上三点是我们对技术管理者的要求，如果技术人想走上管理路线的话，可以参考一下，有针对性的做一些学习和锻炼。

大咖对话 | 彭跃辉：解决用户痛点就是立足于市场的秘诀

你好！

本周作客大咖对话的嘉宾是 Keep CTO 彭跃辉，曾于豌豆荚从零搭建了豌豆荚的应用搜索，打造最全、最准、最快的内容库。2016 年加入 Keep，搭建近 200 人的技术团队，带领团队快速迭代，通过内容、数据和算法打造运动的闭环，Keep 长期稳居健康健美的榜首。今天，我们跟他聊了聊创业打造产品的秘诀，以及在 AI 方面的实践与探索。

极客时间：Keep 在短短几年内成长为如今的明星产品，同时拥有极高的用户粘性，有什么秘诀吗？
彭跃辉：相较于其他互联网 App，Keep 一亿多的用户几乎都来自于自然流量，只有不到 10% 的用户是买过来的。其实，我们之前也复盘过，为什么能做到现在这个规模，主要有三个因素。

第一点是定位，健身行业比较垂直，而运动与健康正是处于上升期的领域，Keep 能稳定发展的原因很大一部分是源于健身行业的发展，越来越多的人对自己的身材与健康更加在意。

第二点是解决用户痛点，我们做 Keep 的初心，就是为了解决用户的一些痛点。从这个角度来看，Keep 解决用户痛点相较于其他产品更加深入。最初，我们定位于为初级的用户服务，这样能让更多人参与进来，从而沉淀更多用户数据，随着用户规模逐渐扩大之后，我们将整个内容体系做了一次升级，使它越来越专业，越来越体系化，并且持续不断的生产内容。

我们希望能够真正帮到用户，举个例子，与传统健身房相比，说直白点，很多传统健身房是在挣那些不去运动的用户的钱，但我们的线下体验店是按次收费。从用户角度出发，体验会好很多。体验店现在还只有一种模式，就是小团课，但满课率及用户复购率都比较高。目前 Keep 这两个指标在整个行业中也是遥遥领先的。

其实，Keep 刚推出时还有很多竞品，但目前来看，在健身品类上，第二名、第三名与 Keep 的差距已经非常大了，这也证明我们在解决用户痛点这条路上越走越远，越来越好了。

第三点原因是，Keep 的团队比较爱学习、爱探索，一家创业公司遇到的问题会很多，在解决问题的过程中，我们的团队会主动学习，寻求突破边界。比如 2017 年第三季度，老板将之前 APP 的定位扩展为 APP+ 硬件 + 线下体验场景的定位，用数据将三者串联起来，打造运动闭环。

极客时间：创业有苦有乐，您能跟大家分享一下自己印象最深的踩坑经验吗？
彭跃辉：不同阶段的坑不一样，在早期，我们面临最大的问题是如何将产品做起来，那时资源并不充足，需要做很多取舍，最后只能比较粗放的将产品上线，导致后来花费了很长时间来还这些技术债，甚至是整个架构的重构。同时，在这个过程中，业务还得继续高速往前跑，我们形容这段过程是“在高速上开着车，还要给车换轮胎”。这个阶段最痛苦的就是平衡技术重构与业务进度，但想要将两件事情都做好，让二者并驾齐驱其实很难，这中间的纠结反复，现在想起来还是深有感触。

然后在成长阶段，从外部数据看，Keep 在健身领域已经有一定的领先优势了，这时，面临的问题是如何突破自己，但现实情况是，团队中大部分人都还没有达到突破的能力或者还未找到突破的方向。因此我们不管是品类扩张，还是探索不同领域都走了很多弯路。

第三阶段的挑战是未来做什么，你必须找到下一个突破点和增长点。因此，我们开始搭建运动闭环，将之前 APP 的定位扩展为 APP+ 硬件 + 线下体验场景的定位，用数据将三者串联起来，更好地为用户服务。

硬件最大的作用是它和用户能有更多的触点，能够采集更多用户数据，比如用户戴着手表，交互的次数会更多，采集的数据也会更准确，帮助我们为用户提供更多更具针对性的指导。

综上三点，第一阶段的挑战是从 0 到 1 将产品做出来，以及如何平衡业务与技术；到了第二阶段，已经在某个小领域成为了 Top1 选手后，面临的问题就变成了如何更好的扩张品类；第三阶段的问题是未来的发展方向。目前，我们处在第二阶段与第三阶段之间，既需要继续扩张品类，又需要探索新的突破点，因此当下最大的挑战可能就是接受更多不确定性。

极客时间：Keep 与 AI 结合较为成功，能分享下你们在 AI 方面的实践与探索吗？
彭跃辉：我先回答第一个问题，Keep 的定位一直比较清楚，一方面要让更多人运动，另一方面是让更多人有效地运动。与 AI 结合的目的也是想让更多人动起来，但其实这件事有点反人性，为什么呢？

因为很多 AI 的应用场景都是利用人性的弱点，使人更加沉迷，我们则相反，是想着怎么用科技手段，让用户在冬天也能运动，以及在运动时，产品如何跟用户互动等。

我们将场景、内容、数据和算法这四个环节与健身领域结合。首先，场景方面，Keep 走的比较靠前，无论是大型器械、运动设备等硬件，还是线下体验场景，都利用人工智能手段采集数据。而有了场景及更多的用户数据之后，就更加便于我们建设内容库和知识图谱。

举个例子，我们会对场景数据进行收集，包括位置、室内和室外的温度、湿度、PM2.5 以及天气情况等，然后可以根据位置推荐附近适合跑步的路线，或是根据天气给用户提供运动建议等等。将内容与场景结合，更好地服务用户。

目前，我们的内容有两类，一类是我们的健身课程，是整个行业中较全、较准的一个内容库，另一类是用户产生的内容，比如用户的社区交互、运动后反馈提交的内容等。我们也从中收集用户数据，挖掘数据价值。

基于这些数据，我们会先描绘出用户的行为画像，然后再与算法结合后做出精准推荐，比如 APP 上的智能训练计划，就是数据的落地，它会根据用户的用户画像，以及当前的运动情况，给用户推荐适合的运动课程。举个例子，很多女生会跳过俯卧撑这个动作，那系统就会针对当前用户的情况降低难度，将动作改为跪式俯卧撑，甚至扶墙俯卧撑。我们会根据用户的交互与反馈对这个课程的做相应的调整。

除此以外，还有硬件与 AI 结合帮助算法落地，比如即将上线的智能运动手环，用户游泳时佩戴它，它会自动帮用户记录游泳距离、游姿等，未来也能够记录网球、羽毛球等球类运动的用户数据。

极客时间：另外，人工智能跟运动领域结合的话，未来的趋势是什么？
彭跃辉：运动健身与 AI 结合的趋势有两方面，一方面是运动智能硬件，因为可穿戴设备能进一步拉近与人的距离，并且就目前来看，大部分穿戴设备都逐渐走向了运动健康领域。Keep 在智能硬件方面也在持续探索，比如我们最近在做体感传感的尝试，用户在运动时，他们的动作会被投放出来，与虚拟教练做对比，从中可以看到自己的动作哪里不标准等等。

另一方面在视觉方向，比如在 Keep APP 上有些入口，能通过用户身体的正面和侧面照片来识别用户的体态、体脂情况。测试结果显示的数据比大部分体脂秤都要准。因为体脂秤的原理比较简单，不同的人差别也比较大，而 AI 识别相当于先构建一个用户 3D 的身体情况，再计算腹部、腰部、臀部等数据。

除此以外，AI 可以从运动视频、人体图片中抽出用户动作的关键点，比如膝关节、肩关节等，从而了解用户在运动过程中的关节运动情况，判断用户动作是否标准。这一个方向我们已经有了探索，目前已经能在线下的场景提供给用户尝试使用了，不过因为对数据计算的要求较高，这个功能目前还未在 APP 上线。

正如之前提到的，公司发展第三个阶段的挑战是要探索未来做什么，而人工智能正是当前非常显著也非常有前景的方向，因此，运动健康和人工智能的很多方向我们都在尝试探索。

大咖对话 | 徐毅:如何提升员工的活力与动力

你好！

本周作客大咖对话的嘉宾是华为云 DevCloud 首席技术布道师徐毅，也是华为 Cloud BU 软件开发云产品部、华为研发能力中心特聘敏捷专家顾问，前 IBM 大中华区敏捷及 DevOps 卓越中心主管，前惠普企业服务资深敏捷顾问，前诺基亚移动设备敏捷及精益教练，前诺基亚网络全球敏捷转型中心精益及敏捷教练，拥有 10+ 年行业经验。今天，我们跟他聊了聊如何提升员工的活力，以及他对敏捷的认知。

极客时间：您之前的采访中提到活⼒是让效率之轮滚动起来的动力之源，那在具体的实践中，该如何提升员工的活力呢？

徐毅：活力方面，首先要理解新时代我们员工的动力在哪里，我比较推荐咱们的技术 Leader 们可以学习一下丹·平克的《驱动力》这本书，作者认为适合现代知识工作者的驱动力 3.0 包括三个要素，自主（Autonomy）、目的（Purpose）和专精（Mastery）。

先来看自主，我一般会举例说，如果一个人要做什么、怎么做都无法做主，那这个人就被管死了。作为中国人，我们可以回想一下自己的成长经历，尤其是中学时代，学什么、怎么学都没有什么可选择的余地，所以逃课的人很多。当然，怎么释放自主，也不是说马上把这些选择权给到员工就行了，就好比前面这些学生突然进入寄宿制大学就跟放羊一样，也是不行的，必须有个过程，这方面呢，我推荐参考下图中理查德·哈克曼（Richard Hackman）的职权模型，要逐步地培养自主能力。

再来看目的，一个非常具体的小例子，就是我们平时大家交流需求，越大的组织越容易出这种问题。当基层员工拿到一个需求的时候，其实已经不是需求，而是一个开发任务了，他们可能都不理解这个任务为什么是这样的，但是当架构师或者 SE（系统工程师）讲完需求问他们“大家有什么问题”的时候，都陷入了中国式沉默，也就是说心里其实有不懂，但都不知道怎么问出来或者担心问了太简单的问题被鄙视。我的建议就是，我们能不能在讲需求的时候，讲清楚这个开发任务、这个功能、这个特性需求实现之后，使用这个功能特性的人，那个用户，他们会有什么样的变化，是不是生活会变得更美好一些？如果我们的工程师在开发代码的时候，也都能在心中想着这段代码所服务的那个人，我会说这是一种充满爱的开发。

最后，关于专精，我通常会在这里问听众一个问题，“中国人说一技之长，那么给大家 20 秒时间，你觉得你的一技之长是什么？”，但多次演讲下来，会举手说自己清楚自己一技之长的人寥寥无几。这是一个非常危险的信号，就好像我们每天过着昏昏庸庸的生活，忙来忙去，不知道自己的核心能力是什么，万一遇到职业生涯的变化，例如公司裁员啥的，就很容易陷入迷茫和恐慌。不说那么极端的情况，就说平常，如果不清楚自己的能力，我们又怎么能够有意识地去提升自己的能力、持续精进呢？虽然有 10000 小时理论，但后来也有澄清，那需要是刻意练习的 10000 小时，而不是 1 个小时用 10000 次啊。

华为公司的研发队伍相当庞大，在实际推动的时候，研发能力中心这种公司级部门、各个产品线产品部自己的相关部门、研究所的相关部门等等各个部门都会发挥自己的作用：一方面是发起这个能力，让大家意识到这件事情的重要性；另一方面是在各地造势，让大家可以接触到最新的信息、知道工作效率高的团队和个人榜样，知道公司重视这个方面；还有一方面当然就是提供理论和实践方面的指导，以及协助引进外界的大牛跟我们介绍外界的先进经验和理念，以及让优秀的基层团队和个人得到宣传，被大家所知道。总之就是从各个层面全方面大家一起来推动。

极客时间：您有很多敏捷相关的经验，但⽬前国内谈论敏捷的声⾳好像变少了，您是怎么看待这⼀情况的呢？

徐毅：这其实是一个很正常的情况。我记得 InfoQ 在 2011 年的时候做过敏捷宣言十年的专题报道，请一些敏捷宣言签署人和业界专家针对敏捷的发展发表意见，我记得有一位专家就说过，或许十年后敏捷这个名字已经被人们所遗忘，但敏捷的精神却已经无所不在。当然，也有很多的抱怨，也有写批评意见说，现在感觉有种趋势，凡是好的都是敏捷的，这就没有办法讨论了。其实技术成熟度曲线总结得很好，敏捷从某种角度来讲，也可以用这个曲线来看待，我想敏捷现在应该处于光明期吧，虽然也已经越来越普及，但是其实很多组织的敏捷程度还很低，只是号称敏捷而已。

另一方面，大家可能都听说过创新鸿沟的技术采用曲线，用它的角度来看，2001 年应该算是创新者发明了“敏捷”，直到今天 2018 年，我觉得我们也只能说是刚刚过了早期采用者阶段，越来越多的企业开始谈论和走向敏捷，应该说是早期大众开始动起来了。同时，跟敏捷平级的其他主张也开始冒头，例如 DevOps、设计思维，它们相对敏捷来说位于曲线周期的更前面一些，自然也就会显得更时尚、更新颖、更趋势，敏捷就会显得更过时、更平淡。

还有就是，近些年我们看到组织领域、管理咨询领域也开始谈论敏捷，它们谈的敏捷和传统研发群体所谈论的敏捷又有所不同，可能是内容不同，也可能是层面、看角度不同。我想，从整体形势的角度来看，就是这样。

另一个层面，我前些年非常关注国内敏捷教练角色的情况，其实它的梯队是断档的，但是要做好敏捷，敏捷教练又是很重要的一类角色。早些年的时候，大众都不太知道敏捷教练这个角色是干嘛的，更多的人把它跟 Scrum Master 混为一谈，而近些年，各家企业都开始大量招聘各种级别的敏捷教练，从团队级别到汇报给 PMO、技术 VP、CIO、CTO 各种级别的都有。这在我看来，意味着各家企业开始接受敏捷教练是一个常规角色，是提升组织敏捷能力的一个关键手段。说手段，是因为我认为敏捷教练从某个角度来讲，最终的目的是要把自己的位置做没，做到组织不再需要他们。

在这个回答里，我就不讲非常具体的点了，感兴趣的朋友可以留言或者评论跟我交流。简言之呢，就是说，敏捷的声音变少了，是因为有更多其他的新趋势和新技术点冒出来了，另一方面是因为敏捷已经逐渐被大家接受是必要的，也就少了很多“要不要”的争议，更多的变成了“怎么做”的更深度的交流，从战略层面下沉到了战术层面，就好像是从大众市场到了垂直领域，所以大众感知度就降低了。

但是，这其实是更艰巨的时刻，因为这意味着敏捷必须要和各行各业、各家企业的具体场景结合，敏捷实践者需要更深度地理解敏捷精神的道法术器各个层面，灵活运用敏捷方法和实践解决具体问题，另一方面也要敞开胸怀去迎接和消化敏捷领域的新内容以及其他新领域的发展变化。

极客时间：华为云 DevCloud 能为开发者和企业带来哪些好处？其核⼼竞争⼒是什么？

徐毅：华为云 DevCloud 我们目前的宣传主要是强调“一站式云端 DevOps 平台，集成华为 30 年研发实践和前沿理念”，所以我们能够带给开发者和企业的好处最直接来说，就是这样的一个平台以及它所承载的先进理念和华为研发实践。

平台，解决的是生产力的问题，所谓工欲善其事必先利其器，DevCloud 首先提供的就是针对企业常见研发挑战的一个智能高效的研发平台。另外，生产力和生产关系是要匹配的，落后的生产关系会阻碍生产力的发挥，我们是通过逐渐开放华为 30 年研发能力提升的理念和实践，来协助客户实现人力物力资源节约和效率提升，提质增效、提高企业自身的行业竞争力。除了 DevCloud 平台之外，我们也会逐渐地提供专业咨询服务，全方位覆盖，助力企业研发转型升级。目前 5 人以下可以免费使用 DevCloud，欢迎大家尝试，大家有任何意见建议也都非常欢迎提给我们改进。

华为云非常重视开发者，我们有开发者一站式服务中心，也有创新扶持计划，在开发资源、开发平台、应用服务等各个方面支持开发者，也有华为云学院为开发者学习课程、提升能力、获取认证提供帮助，这些都在华为云官网上可以找到。DevCloud 也服务于这一使命，一方面我们在不断地完善产品，让开发者可以在我们平台上更顺畅地完成开发全程，另一方面，我们也提供各种实训课程帮助开发者提升能力，比如涵盖区块链、AI、大数据、容器等不同内容的 21 天特色实战营。

总体来讲，作为 DevCloud 一员，我的个人感受是我们其实是为华为公司的愿景“把数字世界带入每个人、每个家庭、每个组织，构建万物互联的智能世界”服务的。而我们的切入点，就是云上开发。要构建这样的智能世界，软件开发会变得越来越重要，软件开发的企业和开发者是其中非常重要的一环。从某个角度来讲，我们是在致敬开发者，跟大家一起携手共建未来万物互联的智能世界。

最后，在此感谢能够有这个机会跟大家交流。网络的交流，表达观点难以全面，如有问题或建议，欢迎给我留言交流，谢谢大家！

大咖对话 | 徐毅：打造高效研发团队的五个维度及相关实践

你好！

本周作客大咖对话的嘉宾是华为云 DevCloud 首席技术布道师徐毅，也是华为 Cloud BU 软件开发云产品部、华为研发能力中心特聘敏捷专家顾问，前 IBM 大中华区敏捷及 DevOps 卓越中心主管，前惠普企业服务资深敏捷顾问，前诺基亚移动设备敏捷及精益教练，前诺基亚网络全球敏捷转型中心精益及敏捷教练，拥有 10+ 年行业经验。今天，我们跟他聊了聊高效研发团队打造相关的话题，以及华为在这方面的相关实践。

极客时间：您好，能先简单介绍⼀下您和您⽬前主要负责的⼯作⽅向吗？

徐毅：感谢极客时间的邀请，很高兴能够跟大家分享我们在技术领导力方面的经验。

目前，我在华为公司担任华为云 DevCloud 的首席技术布道师，以及负责我们的专家服务相关的工作，之前是在公司的研发能力中心负责团队及个体效率提升的研发能力工作。

布道师这个头衔在国内可能还属于比较新鲜的事物，所以我先稍微介绍一下。DevCloud 是我们将华为 30 年研发能力积累对外开放的一个出口，我们也称之为是软件开发云，从名字就可以看出来，它跟云有很大的关系。云计算近些年发展得很快，在云上进行软件开发相比以前在 PC 机上进行软件开发，研发的环境和人员的技能等各方面都发生了变化，当然，更大的变化是业务形态。

由于有这么多的变化，对我们的主要受众，也即软件研发人员和企业来讲，DevCloud 背后所承载的理念可能是一种颠覆性的理念，而这种理念的转变，对于更好地理解和使用软件开发云是至关重要的。布道师的工作，顾名思义，也就是去传播这种理念、思想，让更多人接触、了解和理解这种新颖的研发方式，学会和掌握使用我们的软件开发云产品。而专家服务，则是通过为企业提供更全方位的从规划到落地的完整的培训、咨询等各种服务，配合产品的使用，更顺畅地实现研发的转型升级，提升研发效率。

极客时间：关于打造⾼效的研发团队，可否分享⼀下您的实践与经验？应该从哪⼏个维度出发呢？

徐毅：先简单铺垫一下，我的经验来看，做任何事情，道法术器各个层面都不可缺。

首先，在道的层面，我认为高效的团队和个人是提升研发效率的关键。这么说不是否认整体研发方法论的重要性，只是想强调，任何的方法论都依赖于基层执行人员的能力和纪律，所以说打造好基层的团队和个人是方法论生效的基础。比如前些年敏捷热门的时候，大家就很纠结说敏捷到底对人的能力素质有没有要求。其实我觉得这个事情很简单，如果把方法论比喻成算法，比如说加法、乘法、幂，那么 1+1+1=3、2+2+2=6，111=1、222=8，每一个团队和个人更强了，整体的效率和产出肯定会更高一些。

明确了这个理念之后，我们再来看法的层面。华为的风格是先谈问题，再谈方案。效率这个事情，我们也是先从收集影响效率的问题出发，大家反馈的问题非常多非常全面。进行一定的梳理和分类之后，我们发现最常见的是如下四类问题，我在之前的文章中也提到过：

1. 软件工程师不能聚焦编码，被各种非编码活动影响：我们在一些团队进行了时间统计分析，各种日常事务里面，团队周边协作与支撑工作是消耗时间占比最高的，跨团队的联动开发等一些工作也非常消耗时间、效率也很低；

2. 打断问题：员工工作的时候经常被突发事务打算，然后就需要去处理，一些团队的统计数据显示，平均每个小时打断 7 次以上，平均编码持续时间不到 10 分钟，这个可能大家也有所耳闻，前段时间还有朋友圈文章调侃华为非著名提示音“Welcome to Join the Conference”，而关于打断的危害，有个调查认为 3-5 分钟的打断，会需要 23 分钟才能恢复到原来状态，大家可以想想看这个对效率的影响有多大；

3.P L（Project Leader）直接价值贡献少：作为基层项目团队的 Leader，PL 不仅要管好项目执行、管好团队，我们也希望他们能够有大量时间投入到特性交付，毕竟 PL 都是团队里面技术能力相对拔尖的人，不写代码的话就太可惜了。但实际情况是 PL 被很多事务所牵扯，在项目管理和团队建设方面投入很多时间，而特性交付只有不到 20% 的时间占比；

4. 新员工写代码、老员工解问题：这个估计在很多地方都是常见问题，原因嘛也很简单。交付压力大，谁上？熟练肯定做得快，那就老员工上。新员工干嘛呢，自己写代码，可能就挖出很多坑，有了坑出了问题，肯定要赶紧解决问题啊，那谁能够更快的解决问题呢？老员工。但这样，一方面不是最有效地发挥老员工才干和作用的方式，另一方面也不利于维护老员工的动力和积极性。还有另一个统计数据是，我们发现高职级的人员代码产出相比低职级人员没有优势。

这些问题肯定要解决，但怎么解决呢？我们结合自身的效率问题，以及业界罗伯特·凯利（Robert Kelley）教授的研究成果，选择从如下五个维度去提升研发团队和个人的效率：
1. 活力：也就是人的动力动机，如果一个人没有主观能动性，我们给他们再好的方法、工具，恐怕都没有用，如果下面四个维度构成了效率之轮，那么活动这个维度就是让轮子滚动起来的动力之源；

2. 贡献：包括硬产出和软影响力多方面，主要思路是希望通过更好地汇集和展示团队与员工的贡献情况，一方面是提升员工的成就感，增强周边的认同，另一方面也是帮助员工观察自己情况、持续改进；

3. 能力：识别出我们需要具备的技能和能力项，持续地度量以及采取针对性的措施去提升技能能力水平，这会涉及到知识管理和应用方面的内容；

4. 管理：团队和个人的时间管理、工作任务管理等方面的管理水平，通过推广优秀实践、优秀工具等方法，来提升改进；

5. 协同：协同协作很难简单地说越多越好或者越少越好，都是要看具体的情况，但一定要减少不必要的协作浪费和投入。

极客时间：您提到从这几个维度去提升研发团队和个人的效率，那在具体实践中，你们是怎么做的呢？

徐毅：这些维度，我们在具体操作中，也有各不相同的方式。其中一种，是从时间记录和分析开始，也是前面提到过的，我们会在一些团队进行时间统计分析。然后就从最希望优化的时间入手，比如说，我们发现团队被打扰、被打断的情况很严重，严重到有的工程师戏称说自己是“白天抽空编码”，于是先在一些团队试点静默时间，固定上午或下午一个时间段是静默时间，IM 工具下线，专心干活。

当然，在开始静默之前，也都要告知周边团队和一些相关人员，让大家知道我们在这个时间段会静默。而且也建议团队选择一位联系人，在静默期间，处理紧急问题，可以隔一段时间再轮换。尝试之后，试点团队的反馈很好，所以后来这个实践也被大范围的推广，甚至有整个研究所、整个产品部集体静默的。静默时间能够给我们的工程师尽量的挤出一整块一整块的时间可以专心使用，但也一定要想好如何利用这块时间，以及如何做好紧急事件的处理计划。

有些比较积极的团队，参与了我们的试点，安装了时间统计工具，运行在后台，统计不同应用程序消耗的时间，然后我们再把这个时间统计进行汇总分析，从中寻找改进的机会点。其实我们前面提到的很多问题，也都是通过这些时间统计工具得到的时间数据来说话的。

改进方面，方法上，主要还是推荐时间管理的方法、技巧、经验，以及提供时间数据给（参与试点安装了工具的）员工帮助他们了解自身的情况。从影响范围更大的角度来看，更有效的，还是给大家推荐好用的工具。

工欲善其事必先利其器，我们目前并不缺少好的工具，但可能很多人并不知道有更好的工具可以使用，那我们就可以根据得到的信息，定点推给具体某位员工，建议他 / 她可以使用某款工具。比如，某产品线在分析试点团队的时间数据时候发现，有的员工有 10% 的时间都花费在了“explorer.exe”（我们工作环境以 windows 为主）上。那员工使用文件资源管理器干嘛呢？极大可能是要在电脑里寻找某个文件，但是我们为什么一定要找呢，可以搜嘛，所以就通过邮件推送信息给这些员工，建议他们使用 Everything 软件。

除了这类小工具，更重要的还是员工每天工作需要使用的作业工具。大家可能因为种种原因并没有使用最新、最好的工具，还有可能因为彼此的配置、环境等各方面的差异，而导致研发过程中浪费很多时间在集成、联调等环节。

在这方面的问题上，我们发现云化研发这个场景还是有不少的优势，如果把大部分的研发工作都放在云上，而不是每个人的本地环境，那么一致性以及工具最新版本的升级等各方面的问题都会更容易解决。华为内部就有专门的工具团队，开发基于云化场景的研发工具链，从项目管理、需求管理到编译构建、流水线到部署、发布全流程打通，同一个研发团队或开发部的人员都在同一套云化工具链上进行开发。同时，在工具链的背后，是我们云化研发的方法论和能力在支撑。

当我们把整个作业过程全部都放到云上之后，我们会发现能够更容易去度量一个需求的周期时间以及各个环节的问题，以此来牵引团队的改进。相比刚才讲的小工具，这个就是大工具方面的改进。我目前所在的 DevCloud，可以简单理解为就是这套工具链和能力方法体系的对外输出版，感兴趣的话，华为云官网上就有入口，可以尝试使用。

另外一方面，目前公司整体都非常重视优秀工程师的作用，强调搞技术也可以到很高的职级，在职业发展上铺平道路，还通过内部刊物等各种手段宣传介绍优秀工程师的事迹和经验，营造氛围，也鼓舞更多的工程师积极向上，磨炼自身的能力，加入优秀工程师的行列。也有部分研究所，在研究所范围内组织高效工程师的专属俱乐部，把当地的优秀工程师聚集起来，定期交流彼此的经验，也会邀请公司内部和业界大牛给他们开小灶，也在尝试是否可以在研究所地域层面给这些高效工程师提供一定的优待，比如专属的停车位等。还有一些产品部，对大家公认的高效工程师，会奖励机械键盘、大屏显示器、人体工程座椅、专用鼠标垫等各种优厚待遇，鼓励大家向榜样学习。

在具体工作任务层面，有的产品部针对前面提到的老员工问题，在部门层面，把部分优秀员工，从 PL 团队拎出来，组成“首席工程师”团队，不在 PL 团队承接任务，而是在部门层面自行挑选工作任务，给予他们相当的自主性，可以自己选择去解决难题或者挑选自己比较感兴趣的工作任务，很好地激活了老员工的工作动力。

公司各团队在这方面的积极性非常高，产生了很多的实践，我们内部还总结成册，出了这么一本“打造高效研发团队”的内部实践册，以供有需要的团队参考使用。也建立了内部的实践社区，供大家交流，补充最新的实践。也会有定期的内部大会，各研究所各产品部的优秀团队，大家会聚集在一起，分享各自的经验、交流学习。

大咖对话 | 技术人创业前衡量自我的3P3C模型

你好！

本周作客“大咖对话”的嘉宾是线性资本创始合伙人王淮。他是原 Facebook 中国籍的第二位工程师和第一位研发经理。做过 News Feed 和 Social Ads 后台，写过虚拟货币的前端，调过支付安全的大数据模型。还担任大众点评、百姓网和 CSDN 的 CEO 顾问。今天，我们和他聊了聊技术人创业前的考量和准备。

极客时间：根据你的观察，技术人创业最容易踩哪些坑？

王淮：我觉得最容易踩的一个坑就是太把自己的技术当回事。技术人创业，从最初的技术到最后做成一个成功的商业之间，还要经历技术的产品化、产品的商业化这两个大坎。

这两次都是生死劫，很多技术人都经历不了这两次成长，最后可能只有 5% 有机会成长为一个好的技术流派的企业家。

创业不是一个纯粹的技术性问题，纯技术研究类的工作可能只占到整体的 1/3，剩下的 1/3 都是工程性工作，如软件、体验、交互等，就是把技术变成一个别人可用的产品。因为普通用户一般不会关心你背后的技术如何，他只关心他的问题有没有被解决。

前面部分更像 Research，后面部分更像 Development，然后其他工作，如销售、市场、品牌、法务等又会占到剩下的 1/3。

一般来说，初期的时候，也就是 B 轮之前，技术占的比重会更高，但等到 B 轮之后，非技术相关的比重会越来越高。

而对于我们来说，技术是出发点，但我们的终点是要投一个能够成长起来的成功商业。因此，我们在选择技术人的时候，技术之外的能力有缺陷没关系，关键是意识，要能意识到创业不仅仅是一个纯粹的技术性问题，要能认识到自己技术之外的弱项，然后有这种意识想去成长起来，有学习意愿和学习能力的。

我们会很看重他们的这种意识，如果如果没有，反而依旧局限在技术中，那我们会觉得这个人的思维是比较狭隘的，就不会选择这样的投资对象。

极客时间：技术人创业之前要做很多准备，那具体要问自己哪些问题呢？##

王淮：我们内部衡量创业者的时候有一个 3P3C 的框架模型，如果你有意向创业的话，可以根据这个框架反观一下自己。

第一个 P 是 Professional，专业。 我们对专业的要求是，对于你想解决的问题，你过去是否有很深的积累。如果只是突发奇想地对某一个问题产生了商业兴趣，然后想创业，这种人我们是很少碰的。

我们投的人，会希望他创业想干的事情能跟他过去的积累之间有一定程度的重叠，一般希望这种重叠能够在 40% 到 60% 之间。重叠度太高，可能就是在重复过去的事情，会少一些创新；重叠度太少，那过去的积累对未来能起的作用就比较少了。

举例来说，我们投的神策，他们就是把之前在百度积累的数据采集、整理、分析等能力产品化，同时针对电商、金融等不同业务领域构建定制化的数据分析模型，打造了杀手锏式的产品。这些定制化的产品就是他们在原本的数据基础能力之上的创新，也是我们认为的专业的体现。

第二个 P 是 Passionate，激情。 这种激情并不是外表体现出来的那种风风火火的样子，而是指对一件事情的激情，表现在是否对某件事情有那种发自内心的好奇心，然后有持续性的深度的思考。尤其是在那种跟他想要解决的问题有关，但却没那么熟悉的点上，他愿不愿意做更多的深度思考。这种长期的思考会带来刻画在灵魂中的热情。

第三个 P 是 Persistent，坚持。 创业是一件长期的、艰难的事情，可能你刚开始有创业想法的时候，会觉得阳光普照，每天都充满激情干劲，但等到真正创业之后，你会面对很多狂风暴雨，经历各种磨难考验。

因此，在和创业者沟通时，我们会考量他在面对困难时的坚持能力，会通过各种假设，跟他们探讨未来可能遇到的挑战与风险，比如腾讯跟你做同样的事情你会怎么做等。

这并不是我们对他或他在做的事情有多大的负面看法，而是我们很看重创始人、创始团队在面对这些困难的时候，体现出来的处事态度，比如是否能冷静的思考、是否拥有解决一切难题的自信、是否能做出相应的战略分析等。

接下来再谈谈 3 个 C。

第一个 C 是 Crucial，决断。 原来你当工程师的时候，你可能只需要把问题解决、管好自己的一亩三分地就行了。但创业不是这样，创业的时候，你必须把自己有限的资源，投入到最有机会让你成功的那个切入点中去。因此，你就必须要做全盘打算、必须要有取舍、必须要有决断。

以员工为例，虽然对创业公司来说，一方面招人是个大难题，另一方面对方可能是从最初就跟随你的老员工，但当你发现对方已经不合适的时候，一定要有决断，要 Fire Fast。

第二个 C 是 Consistent，一致。 这其实是人品方面的问题，老实讲，我们对创业者其实没有特别强的道德要求，只是希望他们能遵循一个最起码的底线就是言行一致，不能想一套、说一套、做的时候又是另一套。

是，创业是一个战场，你可以采取一些策略去迷惑麻痹别人，但对内，跟你应该信任的对象，比如投资人、合伙人、员工等沟通时，就应该至少做到思言行一致。这是我们的要求，别小看了这一点，做起来还真的不是很容易，尤其是在面对那些利益相关的事情的时候。

第三个 C 是 Credible，可信的。 信用是需要很长时间积累的，也是一个很难的过程。但一个有信用的、靠得住的人，即使这次创业不成功，但从长远来看，也是迟早能成事的，毕竟不管是合作伙伴还是投资人都会更愿意跟这样的人合作。比如说合伙人，可能就因为他信得过你，他就愿意在你什么都还没有的时候，放弃其他很好的机会，跟你一起打拼。

总的来说，这 3P3C 六个点是我们关注的最核心的东西，而前面 5 点最后都会体现在 Credible 上。我们跟创业者的所有沟通、交流，最后都是为了能在这六个点上对对方有一个深度的可量化的认知。

极客时间：技术人创业时，找到合适的合伙人是非常关键的一点，那在合伙人的选择上，你认为有哪些权衡和考虑点？

王淮：第一，是知根知底。 合伙人是一个非常长期的选择，一旦出问题就会很致命。你会天天跟你的合伙人聊很多各种各样的东西，可能你跟他待在一起的时间要比家人还多。这个人一旦选错，你就会郁闷很长时间，而且万一不成了要分开，造成的影响不比离婚来得小。因此，知根知底、互相信任是非常重要的。

第二，是互补性。 对技术型的创业者来说，如果能找到彼此信任的、非技术偏商业的合伙人当然很棒，但如果没有，大家都是做技术的，那一个偏产品、一个偏技术，也是可以接受的，毕竟那种理想的互补型团队太难得了。另外，商业型的人才也可以等到之后 A 轮的时候再去补充，因此，第二点就没有第一点知根知底来得关键。

而这两个权衡点就衍生出一个对技术人的要求，那就是技术人在平时工作生活中，应该尽量多做一些人脉的积累，要在平时的合作中，尽量去交几个知心的、能够互相认可的朋友。这里的认可不仅仅体现在具体做事上，还包括在平时的为人处世上。

另外，技术人也要更 Open 自己，不仅仅要去接触技术、产品等比较容易接触的伙伴，还要多去接触些销售、BD、人事等方方面面的人。即使他不会成为你创业时的合伙人，但至少你碰到相关问题的时候，可以找到人商量。

以投资人为例，其实平时投资人跟创业者的接触是很有限的，初期往往很难很快就达成深度的认可。但如果你们之前就有过接触，彼此已经认识了解对方了，那投资人产生信任的速度就会更快，确定投资的概率也就更高。

虽然这对技术人来说不是一件容易的事情，但如果你有创业的想法，就一定要 Open 自己，一定要把门打开、广泛纳贤，汇集吸取多方的思考，毕竟创业这件事一定是不能把自己关在屋子里闭门造车的。

大咖对话 | 技术人真正需要的是升维思考

你好！

今天与我们对话的嘉宾是七牛云创始人兼 CEO 许式伟。

许式伟曾在金山、盛大等知名互联网公司担任重要技术岗位，从事核心产品研发。2011 年，他与吕桂华一起创立七牛云，专注以数据为中心的公有云服务市场。此外，他也是国内 Go 语言实践圈子公认的 Go 语言专家，著有国内第一本 Go 语言图书《Go 语言编程》。今天我们请他来聊一聊技术人怎样提升产品思维，以及如何把握商业趋势。

Q：技术管理者为什么必须具备产品思维？怎样提升产品思维？

A：产品思维从本质上讲，就是业务思维，就是要去思考产品的用户价值，甚至更进一步需要考虑商业的层面，思考怎么才能卖出更高的价格或者卖更多的产品，从而产生更大的营收和利润。

技术管理者首先是一个管理者，为一个团队的前途负责，其次才是一个技术人员。我认为管理者最核心的能力不是团队管理能力，而是以下这两点：1）判断力：如何避开错误的和没必要做的事情，集中精力到最必要和最正确的事情上，从而让团队尽量少做无用功；2）协调能力：如何和其他团队进行高效协同，从而为团队构建最好的工作环境。

要达到以上两个能力，都需要以超脱技术，也超脱自己团队的全局视角看问题，即以达成大家共同目标的角度去看问题。我们平时强调沟通时经常说要学会换位思考，其实真正需要的是升维思考。为达成自己的目标，就得将自己的目标和大目标进行强关联。归根到底就是需要比较强大的产品思维。

提升产品思维关键是要提升思考方法。从代码和架构提升到业务层，从后方的研发办公室前移到客户现场，并理解到自己所做的工作对于客户的影响面，从而真正意识到公司里每一个岗位对于完成客户需求所各自具备的重要性，从而学会收起自己的自大心理，真正尊重公司里的每一位同事。尊重是换位思考的关键前提。这些理解将能非常有效的反向指导团队的工作。

Q：技术人创业，如何准确地把握商业发展的趋势？

A：我得泼盆冷水，一个人是否懂技术对于把握商业趋势并没有明显关联性。尽可能了解行业发展趋势的唯一办法就是深入而透彻的研究这个行业。因此对于这个问题我唯一的建议是：别把自己的技术能力当回事。就算之前是技术大佬，也应该把自己当小白，怀着敬畏之心好好学习商业知识，认真倾听用户的声音，洞察需求的演进方向。不要死抱着自己的技术荣誉不放。

最最重要的是，要热爱自己做的产品。只有热爱产品的人才会没日没夜的琢磨产品的细节，才能切身感受到用户仍然未决的痛点。所谓商业发展，不就是更好的解决客户的痛点吗？

所以技术人创业，我的建议是在思考商业发展趋势的时候，不妨先忘记自己是个技术人，要把自己看做是个产品人。技术人的视角是怎么把东西做出来，而产品人的视角是用户怎么用这个产品。当然，懂技术的产品人是有一定优势的，如果他的技术视野足够宽广的话，他就有可能先于他人发现将技术应用于新市场的机会。

Q：创业公司如何更好地树立技术品牌？

A：我们早期在产品都还没正式上线的时候就写了《Go 语言编程》这本书，看起来特别的不务正业，但事实上我们有自己非常明确的目的。一方面写书是最好的说明自己是某方面专家的方式，另一方面在那个时间点选择 Go 语言也非常能够说明我们团队的独到眼光和品味。结合一些规模较小的高端架构类技术交流会议上的密集分享，我们就快速成功打造出了七牛云这个技术品牌。

从我们七牛云自身的实践看来，树立一个良好的技术品牌确实可以帮助公司吸引更多的优秀技术人才，并进而吸引而非技术类人才的加盟。要做到这一点，不仅仅需要大量的精力投入，相应的资金支持也不可或缺。

从树立技术品牌的角度看，我觉得最关键是要先定义好公司的技术主线，并致力于成为这条主线的行业内第一的地位。比如我们七牛云的技术主线就是围绕海量数据的复杂系统工程，从语言的选择，架构的选择，产品的设计和发展都围绕着这条主线。因为大多数创业公司的产品都不是像我们七牛云这样的技术类产品，因此打造技术品牌会更有难度一些，但也很容易找到很多方法。所有品牌建设方法中，参与开源社区的工作被证明是效果非常突出的一种方式。建议大家尝试一下。

Q：说到 Go 语言，七牛是全球第一个用 Go 写的云存储，也是第一个用 Go 写的云服务。你觉得现在 Go 语言的发展情况怎么样？

A：我与 Go 语言的缘分始于 2007 年，但真正开始使用是 2011 年 6 月，我们离开盛大创新院创办七牛云的时候。当时我面临着第三次技术选型，我很坚决地选择了 Go 语言，因为我认为 Go 真的是一门革命性的语言，它的流行将对产业发展具重大意义。

到了 2014 年，在七牛云决定进入大数据领域时，我们再一次面临技术选型问题。坦白说，我们还是纠结了一段时间的。从生态来说，选择 Java，或者某种 JVM 平台的语言有非常显著的优势。但我们认为未来 Go 会占领整个基础设施领域，而大数据无疑是其中极具关键意义的一个领域。所以面向现在做选型，还是面向未来做选型，这是一个问题。

在做了非常细致的思考之后，我们大数据的负责人陈超决定用 Go 做 Pandora。他的理由是：极低的学习成本，极低的心智负担。如果用 Scala，新人入职要培训，还要担心写出糟糕的 Scala 代码。但是用 Go 新人不培训直接上岗，几次 Code Review 完后基本就能够知道怎么写出质量不错的 Go 代码了。

现在，Go 已经不再是一门小众语言。越来越多人在用 Go，喜欢上 Go。某一天通过 Google Trends 搜索 golang 发现全世界 Go 最火的地区是在中国时，那一刻真的很开心。

我知道有一些人很期望 Go 语言特性的迭代。但是如果你抱有这种想法可能会失望，因为 10 年内 Go 不会发生太大的变化。对远期需求变化的预测和把控能力，是 Go 最大的魅力之一。这一点上能够和 Go 相比的是 C 语言，但因为 Go 要解决的问题更多，做到这一点实际上也更难。接下来 Go 语言仍然会继续深耕服务端开发的生态，同时积极探索其他潜在的应用市场。

大咖对话 | 技术管理者应该向优秀的体育教练学习

你好！

今天做客“大咖问答”的是 Rancher Labs 联合创始人及 CEO 梁胜博士。梁胜是耶鲁大学计算机博士，Java 语言和 JVM 的领导设计与开发者。2008 年他创建了 Cloud.com，因此被誉为“CloudStack 之父”。2011 年 Cloud.com 被 Citrix 收购，梁胜成为 Citrix 首位华人 CTO。2014 年，他创立了如今全球领先的容器管理公司 Rancher Labs。关于如何衡量技术团队的效率和产出，梁胜表达了他的观点。

Q：技术团队如何科学地做绩效考核？

A：这个问题其实很难简单地去回答，因为大公司和小公司会差得很远，不同公司的实际情况也有很大的差别。我感觉最近一段时间，OKR 确实比较流行，也有很多公司在实行。不过绩效管理是个很难的课题，现在也并没有得到很好的解决，不管是以前的 KPI，还是现在的 OKR，我感觉没有太大的本质上的差别。

关于如何科学地做绩效管理，是存在较大争议的，因为影响绩效的因素太多，比如员工具体做事的方法、业务的成绩、产品最终在市场上成功的程度。我看到很多公司虽然制定了很复杂的 KPI 或 OKR，但并没有把这些因素很好地融入，实际上也起不了太大的作用。并且 KPI 是半年到一年才制定一次，实际上对员工的影响也不是特别的大。

KPI 或 OKR 说到底就是个目标，目标制定了以后，关键是怎么达到，这才是管理者真正应该关注的。员工肯定是希望达到目标的，但是有可能没有掌握正确的方法，或者能力不足，作为管理者，要通过有效的管理方法，帮助员工达到目标。

一个技术团队的产出，很多时候并不是基层员工能够决定的。举个例子，有两个技术团队，他们的聪明程度一样，用功程度一样，工作强度也一样，但是他们奋斗一年之后，两个团队可能会有非常不同的产出。一个团队的产品非常成功，卖得很好，对于公司来讲，产出就非常大。而另一个技术团队的产品方向错了，等于一年的时间白费了，对于公司来讲就没有产出。这不是技术团队的错，他们只是完成管理层指派的任务。所以技术团队的产出不能用写了多少行代码、攻克了多少技术难题来衡量。还有些员工会想办法把自己的 OKR 制定得很容易达到，这样到季度末看他的完成情况都没有问题，但是对公司来说没什么价值。

所以用 KPI 或 OKR 来考核，漏洞太多了。我个人觉得管理者对员工主观的考核，或者同事间彼此的考核更重要，是不可或缺的。有的员工，可能技术能力很强，但是对同事的态度非常差，把团队的气氛搞得很差。他的 KPI 可能每一项都超额完成，你看不到他存在的问题。所以主观考核是很有必要的，不是说有了 KPI 或 OKR，人就成了机器人了，那还要管理者干嘛，搞个项目管理软件不就行了。

具体考核方法上，比如给大家发一张问卷，让大家从技术能力、团队精神、工作态度等方面，给部门其他同事打分，实际上是很管用的。KPI 或 OKR 更加适合大公司，因为公司大了以后，主观的判断力就会下降，使用绩效管理工具可以避免一些不公平的现象。

Q：以你的经验来看，如何打造高效的研发团队？

A：首先要看“高效”怎么定义，我的定义就是“这个团队取得的经济价值”。所以高效的技术团队，首先要做高效的事情。中国最高效的团队在哪里？我认为一定是在百度、阿里、腾讯、京东、华为，不管团队里的人是不是最牛的，都是高效的。

实际上技术团队对业务的成功有非常大的直接影响力，这一点一定要不断地给技术人员灌输。你一定要做对的事情，做的事情一定要有价值。我在国内看到很多技术团队，真的每个人都很投入，都很努力，但是做的事情错了，领导者没有把握好方向。一眨眼两年、三年过去了，花费了这么多时间和心血，但是最终我们不能认为这个团队是高效的。

上面这个前提满足了，其次才是做事情的效率的问题。当然，不可能所有事情一上来都能看得很准。技术人员在发现做事情的方向出现了偏差，或者这个事情本身价值不大的情况下，一定要及时调整方向。如果你没有决策权，你可以跟你的主管提出来。如果你的主管坚持一条路走到黑，或者他虽然认同你的观点但无力改变，这个时候你还不如脱离这个团队，至少去了别的团队还可能会高效一点。

我接触过很多技术团队的管理者，在我看来，他们对具体事情的关心远远不够。什么意思呢，就是他们只关注大方向。在我看来，商业竞争和游泳、篮球等等体育竞赛实际上是一样的，体育竞赛最后只有一个奥运冠军，每个行业最终也只有一个第一。运动员要怎么培养呢？如果教练来了之后，只是给运动员定个 PKI，比如“今年要进入三强”或者“三分球进球率要达到 80%”，这样的教练有什么用呢？你去看看那些知名的教练，他们可是每天盯得很紧的，一个动作做得不对都会马上来纠正，我们的技术管理者跟教练比起来差得太远了。在我看来，大部分技术管理者可以提升的空间是很大的。

Q：你觉得一个技术领导者的“领导力”主要体现在哪些地方？

A：技术领导者首先要把握方向，如果你没有跟对人，或者没有做对事，那么不仅耽误了自己的时间，还把团队成员的时间都耽误了，这是很悲惨的。所以一定要花很多时间和精力，搞清楚自己在做什么，要训练自己的眼光。你把这个问题想透了，并且能够很好地传递给团队的人，那你就是领导者，你的团队也必然很有动力。

其次是执行力。在技术方面，对具体问题的洞察能力，对公司、团队、业务存在的问题能够及时发现和提出。这种能力需要通过不断的训练来提高，也是每一位技术领导者都需要努力去修炼的。

我觉得比尔·盖茨就是一个非常典型的优秀的技术领导者，他在上世纪 70 年代就预见到将来家家户户都会拥有个人电脑，所以他去做了操作系统，这就是“做对的事情”。但是具体做事情的时候，他也非常关心细节。大家知道乔布斯也非常关心细节。所以能够把技术产品做到最好的人，都是对产品、技术、体验、质量这些事情非常在乎的，真的像一个教练一样，调教出了一批优秀的人，这些人现在也成了各大公司的领导者。

大咖对话 | 未来技术负责人与首席增长官将如何协作？

你好！

本周与我们对话的嘉宾是 GrowingIO 创始人 &CEO、国家千人计划专家、畅销图书《首席增长官》作者张溪梦。

作为前 LinkedIn 首位做变现盈利的数据科学家，张溪梦对于如何用数据分析来增加销售，促进产品的研发效率、做更好的风险控制等很有见解。本周，我们邀请他来和大家聊聊技术人创业，以及技术人如何利用自身优势帮助企业驱动增长。

Q：作为技术出身的创业者，你认为技术人创业需要注意哪些问题？

A：在过往十年中，大部分技术人在创业过程中也许都还仅仅关注公司内部事务，比如研发团队搭建、产品进度安排、营销策略等诸多方面。我觉得这种思维在过去没有问题，因为那时技术工具不完善，我们需要运用工具提高效率，同时完成各种任务。

但这种相对传统的思维现在正经历巨大转变。这种思维转变并非单单针对勇于创业的技术人，实际也同样影响着 CEO、产品经理、营销人。那就是，无论你是做技术做业务，还是做分析做营销，都必须转变成以客户为中心的思维方式。

虽然技术团队是服务于内部的团队，但这个团队的直接负责对象始终是用户，因此技术人要更多地了解我们的用户是从哪儿来的，如何帮助用户获取更多产品价值，用户能否持续使用产品，一定要用户思维导向。

与此同时，技术领导者也需要不断提高自身整合能力。在过去十几年，对于创业者来说很多底层工具可能就已经是非常大的技术挑战了，技术人需要自己去攻克。但当这些工具越来越多的被商品化、产品化时，这就要求我们的技术领导者去做更上层的技术。举个例子，IDC 数据中心之上出现了云，云之上又出现了云平台，之后就是各种应用。这就像一个金字塔，底层地基不断往上搭建，底下就会被各种厂商进行商品化、产品化。

一个好的技术领导者必须能够转化自己的思维，考量未来如何变得更高效，这是一个从开发者到管理者的角色转换。如何借助自己的专业知识快速整合资源，如何分配核心资源，服务企业内部以及我们的客户：这就变得非常重要。

Q：怎样找到合适的合伙人？在合伙人的选择上，你认为有哪些权衡和考虑点？

A：回国之后我看了一本书叫《创新者的窘境》，里面提到一个观点，“不完善的、成本低的会迅速的往上成长，替换掉既有的高级的所谓昂贵的服务。”因此我觉得，在现在这个时代，如何善用各种资源去聚合，是我对合伙人的一种最基本的考量。

我期待合伙人，不应仅是一个纯专注执行和交付的部门，否则这会经常陷入把活都干了，却还是经常受到指责的困境中。他们应该具备商业思维，只有具备商业思维，他们才能知道哪些资源用的是对的，哪些资源用的是错的。只有深入了解了我们用户，这样才能知道对外产品和对内服务如何更好的提升效率。我个人认为，对合伙人的最核心需求，就是增长，真正的技术领导者必须要能更高效地支持公司的业务增长。

另一点就是要求更高的视野，他能够深入到每一个业务步骤里面去，甚至可以深入到每一个细节里面去，不但掌握产品，也了解内部的各种营销系统，能够把分散的各个部门变成有凝聚力的团体，满足我们客户的需求。

Q：你认为“首席增长官”取代“首席营销官”会成为一种趋势吗？未来技术负责人与首席增长官将如何协作？

A：在过往几年中，中国整个商业环境发生了天翻地覆的变化，流量红利、人口红利、资本红利三个因素都在产生着不可预期的剧变。以前业务增长就是销售团队的工作、是产品团队的工作、是首席营销官的工作，但其实我觉得这种思维要做一个很大的变化。企业使命里面第一点是要创造价值，企业想生存下来必须要持续增长，否则这家企业就在衰减。那么，首席增长官成了必然趋势。

与此同时，数字经济的便利性以及选择的多样性让消费者随时随地都可能被那些当下打动他的品牌吸引从而付费，这样的背景让 CMO 必须变身增长工程师，而不仅仅是精通 campaign 的打造以及品牌的传播。这就需要我们的技术负责人站出来。做什么呢，利用技术来实现增长，用数据驱动决策。

比如提出 Growth Hacker（增长黑客）概念的 Sean Ellis，他也参加过 GrowingIO 举办的增长大会。Growth Hacking 这个概念是他在 2010 年提出来的，Hacking 代表的是技术，因为以往增长都是业务去驱动的。Ellis 认为未来的企业想在剧烈竞争的商业环境下胜出，必须要实现三个核心元素的结合，第一个元素，他提出来的是 Programming，因为有了技术，放大效率就很高；第二，必须要具备营销思维，要变成一个营销人；另外一点就是如何平衡工程和业务，这就需要数据支撑。因此，如果想实现高效持续的增长，就需要未来技术负责人与首席增长官把技术、营销、数据连起来，用技术来驱动业务增长。

Garther 也做过增长相关的洞察分析，他们预测在全球商业价值最高的公司里面，25% 的业绩应该是公司内部具有创业精神的 CTO 来用技术来达成的，Garther 认为这是企业挖掘更多商业价值的核心力量。

过去，我一直在做数据分析，从用户身上收集数据然后到存储到分析到 BI，然后到了机器学习、模型深度分析，在这一过程中，技术领导者帮助我更高效实现数据分析，从而产生更多商业价值。可见，技术领导者一方面把自己的产品服务赋能给用户， 另一方面就是帮助未来的首席增长官更高效的进行增长，而非单纯的产品研发。

最后，对于技术领导者，只有具备更高的战略思维，善用技术与工具帮助企业驱动增长，做更多的创新与尝试，并将之产品化，要把价值交给更多人。

大咖对话 | 李昊：创业公司如何做好技术团队绩效考核？

你好！

本周作客大咖对话的嘉宾是满帮集团高级技术总监兼联席委员会主席李昊，拥有超过 10 年的技术管理经验，目前在满帮管理超过 500 人的团队。对于高速发展的创业公司而言，如何保证项目的按时保质交付看起来是对研发管理者的一个基本要求，但这背后其实需要织架构、流程规范、绩效考核和团队文化等各方面技术管理，今天我们就和李昊聊了聊其中如何做好组织架构和绩效考核这两个方向的话题。

极客时间：您能简单介绍一下您和您目前负责的工作内容吗？
李昊：我工作后一直在外企从事研发和技术管理工作，在 IBM 做过存储、在 Ericsson 做过基站、在 Myriad 做过前后端。几年前开始创业，加入货车帮之前，在 TestBird 做分管技术产品运营的 VP。2016 年 11 月加入货车帮后，货车帮又和运满满在 2017 年底合并成立了满帮集团。目前我在货车帮这边管理整个技术体系以及平台产品运营、企业效能等部门。

目前的满帮集团是中国干线物流的独角兽公司，通过人、车、货等多个维度的业务拓展，建立起包括信息、交易、金融、能源等在内的多个事业群，在这个数万亿规模的赛道上独占鳌头。

极客时间：在公司高速发展的过程中，如何在保证项目按时保质交付的同时，构建技术团队完善的人员、组织架构和可持续的绩效考核机制呢？

李昊：项目按时保质交付看起来是对研发管理者的一个基本要求，但其实背后的组织架构、流程规范、绩效考核和团队文化等各方面技术管理的基础工作必须都做扎实，才能做到。这环环相扣的四个方面，每个都可以写一本很厚的书，但我们这里主要聊聊发展比较快的创业公司里面，怎么做组织架构和绩效考核。

先说团队和组织架构的搭建。无论是在 TestBird 还是在货车帮，我在这上面都花了很多时间，这几年下来面试的人肯定有 3 位数了，但时间花得是值得的，因为人和组织是任何事业的根基。而团队和组织架构搭建的要点，我觉得有这么几个：

首先，一定要按公司的客观发展阶段来搭建团队。早期创业公司是非常目标导向的，成本也非常紧张，这个时候人往往不是很多，组织架构的设置也不会很复杂。在技术团队，要多招通才，保证技术水平出色并且有共同价值观的人进来，这样沟通成本低，大家在条件受限时能高效地解决实际问题。成熟期之后的公司，更加的职能导向，需要在每个职能条线上都有更加专业的人加入，把产品、运营、设计、前端、后端、测试、运维、安全等专业条线搭建起来。这个阶段的难度在于如何看方向，定战略和要结果了。

其次，对于一线员工来说，他的直接主管实际上就代表着公司。很多员工觉得公司好或者不好，其实就是他的直接 leader 好或者不好。所以在团队不断壮大的过程中，基层的技术负责人和一线经理这一层的管理能力一定要跟上。有很多创业公司在高速发展的过程中，一些研发干得不错的员工被直接提成了管理者，但是又没有管理和领导能力的培训跟上，结果导致了很多问题。

在组织架构和文化价值观定下来之后，绩效考核相对来说是比较容易的。因为组织架构决定了谁来考核，价值观决定了绩效导向。但是在我们这个行业，真正做得好的公司其实不多，因为技术团队在软件领域要考核输出是很困难的，原因主要在于：

1. 和生产制造或者销售等工作不同，软件开发等工作很多是“无形的”，一套软件系统在财务上是算作无形资产的；

2. 对软件工作任务的拆解也是比较主观的，我们经常干的事情就是让技术负责人做一个评估就当成 deadline；

3. 设计和开发、部署工作并不是分阶段进行的而是并行的（特别是现在“敏捷”了之后）。

因为这些特点，之前技术团队的绩效考核往往呈现两方面的问题：

1. 关注输出的总功而不是有用功；

2. 关注个人的而不是团队的（这方面很需要向体育行业学习，从 NBA 到英超，现在逐渐都有一些对团队的统计，比如有些主力球星没有在场上的时候，整个团队的传球次数和进攻效率等等，来追求团队输出的最大化）。

举个例子，国内有的技术团队在绩效考核的时候计算代码行数。只要稍微理性一点我们都知道，同样的问题被 10 行代码解决了，要比 1000 行代码好得多。我们每天都说要还技术债，实际上代码本身是最大的技术债：一旦有代码被写出来，它的维护和变更都会产生巨大的代价。但同样的，另一个极端：用尽量少的代码解决问题，也不值得推荐，因为如果代码太追求技巧，其他人看不懂，可维护性会变差。

再比如，有些技术团队衡量绩效看迭代中的 story points。但它更多的是说明团队的总功（velocity），而不是效能（productivity）。用它来作为绩效标准会有两个问题：

1. 它是一个相对值，同一个团队处于不同的上下文时输出也不一样，跟踪比较的意义不大；

2. 一旦被当成绩效，团队会把“完成”尽量多的 story 当成目标，可能造成有用功比例降低，甚至是影响团队之间的协作。

还有一些公司会统计人力资源利用率，如打卡、记录工时等等都算是这种思路的实现方式。一方面，这些被记录下来的时间里面肯定有不少水分。更重要的问题是，高资源利用率意味着团队其实没有时间来响应需求的变更和插入，以及现有系统的优化。数学里面的排队原理说明，一旦资源利用率达到 100%，lead time 就会趋于无穷大，也就是说，当你资源利用率非常高的时候，很可能你要完成一个事情的时间是趋于无穷大的（到处都在排期，到处都是死锁）。

所以，我经常看到国内的团队因为研发负责人没法找到科学的方法说明自己团队的绩效，就先把 996 搞起来，感觉是用挺悲壮的方式告诉老板“我们很拼吧”。其实 996 无非是人月神话的变种，我自己是不建议长期搞的。

那关于创业公司的绩效管理我自己的心得是：

首先，人少的时候不必追求方法论。十几二十个人的时候，老大自己拍板就行了。如果这个阶段你谁好谁坏都不知道，或者你拍下来的结果还沟通不下去，那这个老大就不要当了。

然后，在人慢慢多起来的时候，就要找对指标，业内有句话说的很好，“没有错误的 KPI 搞不垮的团队和公司”，在实践中，主要有以下几个要点，供大家参考：

任何面向不信任员工设计的指标最好都不要有，比如前面提到的把工作时长和绩效挂钩。大部分人到创业公司是想做事的，不要把大家逼成上班的心态。

先考察团队，再考察个人。我们会通过一些指标来衡量整个技术团队的能力，比如效率方面的上线次数，lead time，质量方面的 MTTR，回滚次数等等，都有考察。个人绩效方面，我们是 OKR 结合 KPI 来做。OKR⾃底向上，体现个人成长的需求，主要影响职级，不直接影响绩效，是⽬标管理工具；KPI⾃顶向下，根据团队的性质不同，侧重点不同，决定了绩效考核结果，同时也直接影响职级和年终奖。

这些指标要尽量的标准化，可视化，公开化。比如我们的团队指标是有专门的 Dashboard 的，因为只有可度量的才是可优化的。再比如我们个人的 OKR 也是放 Confluence 上互相可见，一方面这样可以让员工了解其他同事的工作和目标，另一方面这样还增加了团队的横向一致性。

这里讲了很多，主要是希望能够为其他的技术管理者提供一些在创业公司里进行组织架构和绩效管理的经验，作为大家进行这部分工作时的一个参考。毕竟，在一个公司里面销售等团队的绩效是相对比较容易衡量的，而产品技术团队的成本很好计算，价值却很难衡量，所以常常被划成所谓的“成本中心”。越是这样，就越需要有一套合理的组织架构，再通过科学的考核机制，用简单易懂，对日常工作侵入和干扰少的方式，通过数据来衡量和验证自己的价值。

大咖对话 | 李智慧：技术人如何应对“互联网寒冬”

你好！

本周大咖对话的嘉宾是同程艺龙交通首席架构师、极客时间《从 0 开始学大数据》专栏作者李智慧，曾担任阿里巴巴技术专家、Intel 亚太研发中心架构师、宅米和 WiFi 万能钥匙 CTO，长期从事大数据、大型网站架构的研发工作。今天，他主要与大家分享了技术人如何成长，以及“互联网寒冬”下技术人发展与转型的选择等话题。

极客时间：在您的成长过程中，印象最深刻的一件事是什么？
李智慧：在我的职业生涯里面，比较重要的一次机会是在 2006 年获得的，也就是十几年前。那时我在方正参与当时一个最热的项目，算是当时中国最大的软件外包项目，方正特别成立了一个部门去做这个项目。

因为项目比较大并且比较新，部门也刚刚成立，最开始大概只有三五个人在做，但我们在中关村这边包了一层楼，规划是要把人坐满的。由于这是对日的项目，公司里面技术不错的都会派到日本去跟客户对接事情，其余的留在国内。在项目启动后，日本客户找了一家咨询公司给出了前端、中间服务器、后端的技术方案，大概三层的布局。有了架构，客户的需求也过来了，之后就是要考虑怎么把这个架构方案落地。那时我们每天在查资料、学习，但怎么去做、怎么把项目落地，一直没人去说。

有一天我可能是比较着急，就去跟项目经理说：“这些技术方案，它最终还要落实成代码的。这个代码谁来写？框架间通讯谁来做？这件事情应该怎么推？”没想到过了几天项目经理找到我说“要不你来做吧”。当时我研究生刚刚毕业，经验也不是很多，但我很快就答应了下来。

项目经理是周五找到我的，到周日晚上的时候，我就做出了一个基本的设计，把整个流程和开发视图画了出来。经过评审后，大家都说看起来似乎还不错，然后就开始按照这个架构进行设计开发。之后部门里面其他同事也参与到了整个框架和架构设计的开发中来，后来测试跑通以后，整个框架就算是出来了。之后项目按照原计划运转起来，上百个工程师都逐步招入进来，很快就把一整层楼坐满了。

因为开发业务代码的时候必须要遵照开发流程和框架去做，而这个流程设计和框架是我带人做的，所以后面不管是测试还是异常处理，都要过来找我。把这个项目做完以后，我的心态也不再是刚毕业那样了。上百号人做技术决策的时候，都过来找你，这个时候你会有一种责任感，或者是有一种新的视角，这种视角跟以前在别人的框架约束下做开发是完全不一样的。

这段经历，一方面让我从做开发到做架构，获得了新技能，做开发是在别人画的框里面去做你的业务，而架构是你站在全局的视角去思考问题。另一方面，是让我从另一个视角去观察和思考问题，很多关注的点和思考的点都是不一样的，比如看待一个新技术，我会考虑背后的设计和优缺点，以及为我所用时我要关注什么等等。这种视野给我带来的帮助非常大。

当时这件事对我来说是一个机会，迈过这个坎，也就把握住了这个机会。成长的过程中，一定会有一些机会出现在你面前，有的看起来比较随机，就像我刚才讲的机会突然就出现在面前，如果当时我犹豫一点或者对自己不自信，放过这个机会，人生可能就不一样了。所以当机会出现在你面前的时候，要有勇气把握这个机会。

极客时间：在您看来，技术人怎样才能更好的成长？
李智慧：技术人大都很忙碌，每天都在忙忙碌碌地上班下班或者加班，然后我就在想自己每天的工作到底在干什么。后来我总结了一下，做事情的时候可以分成两种角色：生产者和消费者。

学习本身其实是一种消费，每天忙着去读书，看起来是在学习，但是学完以后你的生活和工作因此改变了吗？或者说有产出和输出吗？如果没有，每天的日子还是老样子，工作和生活也没有改变，这样的学习和玩一会手机、看一会抖音在本质上并没有太大的区别。所以一定要输出一些东西，比如你在公司里面做一个项目或者做一个产品，当然也可以写一本书，或者是在极客时间开一个专栏，总之就是你一定要有产出，让自己成为生产者而不仅仅是单纯的消费者。

你要能够输出让别人消费的东西，这样你就会有成长，会变得不一样。我做事情的时候，总会想我到底是在做什么，是生产还是消费，是输出还是接收。如果我是在生产，大家是不是愿意去消费我生产的东西。比如在公司，我不仅仅是研究新的架构、框架和技术，我还希望自己能从头把它做出来。我希望其他人能够用我做出来的东西，希望自己在工作中是有产出的，这样我会更踏实一点，并且有产出，就会很有收获，也能很快的进步。

极客时间：很多人觉得 90 后员工比较自我，很难管，您是怎么看待的呢？
李智慧：网上关于 90 后会有些言辞，觉得 90 后太自我，考虑别人太少，但我自己是很欣赏 90 后的。我的态度是，一个人如果不知道自己想要什么，那么也不会给别人想要的东西，这在公司里来说是不负责任的。你只有知道自己想要什么，对自己负责，才可能为公司创造真正有价值的东西。

我想说的是，你要做自己的主人，要对自己负责。举个反例，我小的时候一直都是比较乖宝宝类型的，小时候听父母的，上学听老师的，工作听领导的。突然有一天，就是一瞬间惊醒：我这么听你们的，你们会对我负责吗，父母会养我一辈子吗，老师能保证我的将来吗，领导会让我在公司干一辈子吗？你如果不能对我负责，我都听你的有什么用。谁能对我负责？只有自己对自己负责。

你要知道自己想要的是什么，你去付出你该付出的，然后得到你该得到的。比如去学习、去努力、去提高自己。如果你付出了以后，依然得不到，那就去寻找新的机会。

你对自己负责，就是对公司负责，我一直以来都是这个观点。如果天天老板让做什么就做什么，等到最后事情没做好，就会觉得反正是老板让做的、反正是领导让做的，最后大家互相抱怨，根本没有意义。如果你觉得这件事情不该做、没有意义，那就跟他说不要做，这件事情没有意义的，我们有更好的办法。如果你真的有这样的想法，有这样的能力和实力，那就说出来，肯定会得到别人的认可的。这样对自己负责任，在公司也有主人翁的意识。

极客时间：很多人都认为现在是互联网寒冬，比较有危机感，您是怎么看的？
李智慧：我加入阿里巴巴的那一年也赶上金融危机，我面试的时候问了一下，大家都在裁人，为什么阿里巴巴还在招人。当时的 HR 跟我说这是马总的判断，马总认为越是到了寒冬的时候，越要吸引优秀的人才进来，为了冬天过去以后，可以做好储备和积淀。我对马云还是比较佩服的，而且这个道理也很浅显，冬天一定会过去的，日子一定会好的。如果你在冬天的时候冻得瑟瑟发抖，那等冬天过去以后，你肯定还是那个老样子。

在我看来，如果你觉得自己是努力的、优秀的、聪明的、愿意奋斗的那种人，那么寒冬对你来讲就是一次机会，因为未来一定会变好的。而如果你觉得寒冬淘汰的是你的话，那你肯定是会被淘汰的，寒冬就是淘汰掉那些投机的、不努力的、没有什么真本领却虚张声势的人。这其实是你的机会啊，把那些人淘汰掉，这个世界是留给你的，等到冬天过去，当一切变好的时候，这些最好的东西都是留给你的。

另外想聊一下转型这件事，寒冬是你的机会，但寒冬不是你转型的理由，转型是一件时刻都在发生的事情，最主要的还是要去思考，哪些领域和技术是未来的潮流。

我在 Intel 做大数据的时候，我们组里面有几个从 Intel 其他部门转岗过来的同学，之前是做 Linux 内核开发的，当时我觉得这个世界上写代码、做开发，最顶尖的可能就是开发操作系统了，而操作系统的内核开发，更是顶尖中的顶尖。我问他你之前做的是所有程序员梦想的工作，为什么要跑过来做大数据开发呢？

他的回答是，Linux 已经非常成熟和稳定了，变化已经非常小了，他做了 3 年的进程调度和内核算法，向 Linux 社区提交了一行代码，还被拒绝了。这对他来讲是非常痛苦的，也不是一个好的兆头。那么未来在哪里呢？当时最火爆的是大数据，他们就转岗做大数据了。后来其中一个同学去一家专门做大数据的创业公司当 VP，另一位同学在一家快要上市的公司做大数据平台总监。

我在极客时间上的专栏是关于大数据的，大家也可以关注一下大数据方面的潮流。如果你觉得这是潮流，这是未来发展的方向，是机会，你就去做。不用把它看得有多大有多艰难，别人能做到的，你要相信自己也能做得到。

关于转型，我的另一个建议是不要被动转型。我还有一个做开发的同学，因为在意老板比自己年轻这件事，跳了几次槽，结果都不是很好。他以前也是非常资深的工程师，跳了几次槽之后，从开发转做咨询，也算是转型。他也抱怨说，这次转型真的是太失败了，实际上他转型的目标和理由，是要离开比他年轻的老板，这种转型是被动的，也不是很好的理由。

但是人总是有出路的，后来这个同学不做 IT 了，出去开了一家鸭脖店，现在是整个上海地区周黑鸭最大的代理商，名下有将近 30 家的店铺，很让人吃惊。他这个转型转得更大，但肯定是痛定思痛想明白了，来了一次大的转型，反而很成功。

所以，这个世界变化很快，转型真的是无处不在的。人们都在顺应这个时代在发展，你要主动做好这种转型的准备，而不是说因为寒冬，或者其他什么理由去转型。你要去看时代的潮流，从正向去转型，把握住方向，而不是走投无路才去转型。当然走投无路再去转，也是一种转，但是肯定是提前做好准备，并且自己思考清楚会更好。

大咖对话 | 杨育斌：技术领导者要打造技术团队的最大化价值

你好！

本周作客大咖对话的是蓝盾 CTO、信息安全专家杨育斌，目前主要从事信息安全、云计算、网络应急体系等领域的技术创新、开发管理与战略规划工作。先后承担国家级、省部级、市级科研课题 40 余项，获得国际发明专利 1 项，国家发明专利 20 余项。今天，我们主要和他聊了聊高效技术团队的管理理念。

极客时间：能分享一下您近期关注的领域么在信息安全领域，您比较关注哪方面，有什么新的想法？

杨育斌：目前，我比较关注智慧安全这个方向，如何用人工智能技术改变传统信息安全被动的局面，从而实现进一步发展。

利用人工智能技术，帮助业务系统上云的同时，又能更好的抵御数据安全、网络安全、虚拟主机安全等主要安全威胁。

人工智能强大的学习能力，在越来越多的数据面前显得游刃有余，而且越来越多的数据也对人工智能的自我学习和提升有很多帮助。利用人工智能技术，我们能更好的进行病毒样本学习，攻击特征学习，以提供智能的基础设施平台，更智能的进行攻击防护。

另外，我也一直在关注构建大安全生态这件事。我们要做安全，但是不要局限在信息安全，而是要做大安全。在我看来，安全是一种能力，它会渗透并有机融合到云计算、移动互联网、物联网中，形成必须的技术能力与服务体系，最终嫁接到更大的 IT 生态体系上，发挥更大的作用，这也是大安全生态的力量所在。

而且，对比国内外信息安全的发展比例、产品构成比例与盈利构成比例，差异非常明显。国内以硬件和软件产品为主，大部分的销售收入主要来自于硬件和软件，比如防火墙、入侵检测等产品，而安全服务的占比非常低。

但在国外正好相反，比如在美国，安全服务的市场要比安全硬件和软件市场大得多。其主要原因在于，如今许多客户的资产包括数据、系统、网络，都在云端及各种智能硬件上运行了，他不再需要防火墙这样形态的安全守门人，不再需要有个软件跑在实际系统上了，他更需要的是安全服务，是专家型的安全服务，这也是目前蓝盾及国内许多安全同行发力的一个方向。

极客时间：可以分享一下您的技术团队与您的管理理念吗？

杨育斌：我们研发技术团队有六百人左右，虽然，团队规模在国内同行中不是最大的，但团队效率可以说是最高的。举个例子，去年 (2017 年)，我们在国内市场的利润达到了四亿人民币，平摊到技术团队，每个人的人均利润可以超过国内很多技术团队。

我总结了团队高效率的原因，主要有三点：

发挥团队成员的个体潜力；

定时与业务单元高效沟通；

团队协同与组织优化。

首先是第一点，发挥团队成员潜力。在我看来，一名技术领导者最大的使命就是激发团队成员的潜力，并且最大程度地将它发挥出来。包括在招聘人才时，我们也要想着如何发掘应聘者的潜力，我并不以招聘岗位的工作内容评判应聘者是否合适，而是发掘他的优点，判断他是否值得引进。

举个例子，应聘者来面试技术岗位，可能他没有达到岗位要求，但我发现他口才很好，沟通能力很强。这时我会尝试将他培养成一名销售工程师，他只需了解一些技术基础、产品知识以及竞争性解决方案，并向市场和潜在客户进行有效传导灌输，也能够给公司创造价值。

另外，我非常鼓励大家说出自己的新想法，只要对产品、营销有推动作用，都会获得相应的奖励，以此强调和推动公司内部创新合作的氛围。

第二点是团队之间需要及时沟通，发现问题，解决问题。我们每两周会有一次沟通会议，保证业务与技术的定期对接。会议中，我们会根据市场的一线情报与反馈对研发等方向进行及时调整。这种小步快跑的模式是很多公司欠缺的，而我希望让我们的技术团队非常关注业务发展，注重客户的实际需求，所以我会保持这种每两周一次的沟通节奏。

第三点是注重团队合作，当团队人数达到一定数量，都会遇到内部合作问题，因为大团队之下，每个小团队可能都会对自己产出的东西存在一种保护意识，而这会导致内部之间的合作出现隔阂。

我们的方法是打破藩篱，共同协作，灵活利用资源。比如共建组件库，我们有一个专门负责技术资源整合的团队，整合所有研发团队能够公用的组件，提高效率。如果一个小团队需要爬虫组件，他们可以直接在共享组件库中寻找，只需对组件做一些修正、优化工作，就可以实现运用，省去了他们重新开发的时间与精力。并且，他们还需要将优化后的组件重新上传至共享组件库中，方便别人再次取用。这也是我们在人员成本降低后，效率还可以继续提高的原因之一。

极客时间：您对技术领导力有怎样的认知？

杨育斌：首先，技术必须与业务配合，才能够为公司创造高价值，片面强调技术领先，脱离业务实际，并不是技术领导者应该去提倡的做法。直白的说，技术领导者不能光想着怎么烧钱，烧出一个技术领先来，也要想着怎样为公司创造价值，在最少成本的情况下为公司创造最大价值。

其次，我认为，领导力可以理解为教练，或是团队的鼓动者，作为技术领导者，必须不断地鼓动团队战斗力，推动公司业务发展。比如公司已经上市，进入平稳发展期，可能会遇到团队中一些核心成员开始懈怠的问题，此时，作为技术领导者，就需要调动他们积极性，同时，要去思考如何在外部寻求更多的资源来为公司增添新的动力。

因为企业在经营过程中，一定是追求成本最小化和效益最大化的，团队氛围松散，业务停滞，一定不利于企业营收。而科技公司的人员成本又高，所以，如何充分运用团队能力，生产更大的效益，就是每个技术领导者需要思考的问题。

在我看来，作为一名技术领导者，必须具备两个基础能力：

勤于思考，保持敏感。比如，当公司已经解决温饱问题，进入下一个阶段时，可能会出现两种情况，一种情况是，安于现状，满足于过往的成就，认为沿着目前的步伐继续前进就行了。此时，技术领导者需要保持对技术变革的敏感，做好准备，思考下一步的方向。

面对未来，拥有危机意识，每个企业，都会在平稳、顺利的时候，放松警惕，此时一旦松懈就可能被对手，或市场的新兴力量超越。对于这点，过往的案例不在少数。

所以，技术领导者必须在不同的阶段有不同的思考，思考如何保持目前的积极状态，或如何能够继续前进，应对未来的各种不确定因素。

在此，对于一些有志成为 CTO 的年轻技术人，我也想说说我的建议。

首先，必须一步一个脚印，稳固自己的基础。其次，不断学习，拓宽自己的知识面，你要从专才变成全才，除了学习技术，还要学习业务、运营、管理、投资、融资等诸多方向的知识。

然后，想法要多，更要胆大，为什么有些公司最终没能再向前一步，就是因为局限于自己的思维、局限于自己的技术架构、局限于市场保有率中，没能进行突破。作为一个技术领导者，你一定要思考如何突破，如何再进一步。最后，要快速将自己的想法落地，再根据结果反馈，快速迭代。

极客时间：您认为技术类的公司在面向公众传播时，应该怎样打造企业的技术影响力？

杨育斌：我认为最重要的一点是需要承担一定的社会责任，具体做法包括两点：

第一，正确表达技术所能带来的变革和进步，技术的变革是必然趋势，传统企业也会在技术变革过程中打磨自己，适应新的时代。

第二，不要将技术神化，给公众制造焦虑与恐惧，以我所在安全行业为例，遇到信息安全事件，有些公司为了显示自己的技术高深，会将事件夸大，而这样的行为就违背了技术推动社会进步的意义。

大咖对话 | 池建强：做产品不要执着于打造爆款

你好！

本周作客“大咖对话”的嘉宾是池建强，现任极客邦科技总裁，从零开始打造了 IT 类知识服务产品极客时间。加入极客邦前，曾服务于洪恩软件、用友集团和锤子科技等公司。

极客时间：根据您的观察，技术人创业容易踩哪些坑？

池建强：技术人创业其实就是跳出技术的圈子，从另一个维度，比如产品、商业模式上去寻找更多的可能性，这个过程同样充满挑战和乐趣，创业的时候要专注在这个过程上，而不是技术领域。在不同的阶段使用合适的技术解决相关场景的业务需求，创业者需要的不是炫技，而是提供能够为业务服务的技术。

人们常说，一件商品最重要的是质量，但是提高产品质量最关键的是精准的把握用户需求的本质。否则，无论产品质量多好，功能多么丰富，如果不是用户需要的，那么这个产品就是不成功的，是某种程度的自嗨。技术也是同样的道理。

另外，在领域的选择上，技术人容易根据自己之前的经验选一些看起来是降维打击的创业方向，也容易掉进自己的思维陷阱。

很多朋友做烦了 toC（面向普通消费者）的产品，认为 toB （面向企业）是个大市场，一头扎进去也会发现很难，不仅仅是客户难伺候，个性化和通用软件也会不停的打架。规模化还是 Case by Case ，都是艰难的选择。

有些人则烦透了企业客户，开始做 toC 的创业，也难，因为 toC 的产品做出来容易，用户认可和规模化则是个大难题。数据增长和日活是很多 toC 产品迈不过去的坎，转化和收入也更是让人焦虑不已。

有些人适合做 toC 的产品，有些人适合 toB，这个需要每个创业者自己去探索和选择。我自己喜欢做个人消费者的产品，更有意思，更挑战，也更平民化。

有朋友问我，哪个更容易哪个更难呢？天下没有容易的事，都难。重要的是你的选择和坚持。

另外，创业和在大公司打工不同。大公司资源丰富，你做到总监级别，很多琐事是不需要关注的，公司作为平台会提供你想要的各种资源，你只需要专注于某个领域进行突破就好了。有时候这种平台之上的成功容易造成一种错觉：原来我真的很牛！

其实并不是这样，平台隐形的力量不可忽视。一旦开始创业，财务、行政、市场、运营方方面面的事情都需要创业者去操心，可谓事无巨细，也许员工的座椅都需要你决定用哪个牌子。这时候就需要找到能和你互补的合伙人，把自己不擅长的事情交给别人去做，自己去做最擅长的业务和产品。

发挥自己的长板，让别人补足你的短板，这就是现代的木桶理论。

极客时间：您创业至今，从零开始打造了极客时间这一产品，在这个过程中，您最大的挑战和收获分别是什么？能以具体事例来辅助阐述么？

池建强：从零开始做一个产品是非常独特和有价值的事情，事实上很少有人能从头开始参与一个产品的构建过程。有的人是中途加入，有的人是整个平台已经成形之后添砖加瓦。我个人能够主导极客时间这个产品，实在是一件幸运的事。

在打造产品的过程中会遇到各种各样的问题，如何组建团队，如何选择技术体系，如何进行产品定义，如何首次发布产品，如何迭代，如何触达你的用户等等，限于篇幅，我简单介绍几个感触比较深的点。

1. 不要想打造爆款产品

首先，每个产品的出现都有原因和相关的背景。公司愿意投入人力物力去研发一款产品，自然希望产品一发布即大获成功，比如：在发布产品的那一刻，你会觉得，如果你的手指向苍穹，就能看到电闪雷鸣；你登上山峰，千年的冰雪就会融化成水；你走上舞台，就会有千百双手在挥舞……但事实是并不会这样。

大部分情况下什么都没有发生。爆款产品是因为真的“爆”了，才被叫做爆款，很少有人开始的时候就说要打造爆款，因为说了也没什么用。大部分产品都是一点一点长起来了，微信也不例外，只不过由于腾讯的用户体量，微信的起点更高罢了。事实上很多爆款都是黑天鹅事件，而黑天鹅事件是可遇不可求的。

2. 一个成功产品有其增长曲线图

那么一个成功产品的增长曲线是什么呢？大概是这样的：

发布，获得初始用户，拉起一条增长曲线，然后失去新鲜感，数据下降，保持在一个低水平线上，反复迭代，挣扎，试错，找到真正的用户需求点，很多产品在这个阶段就死掉了，活下来的继续前行，直到找到那个数据上扬的拐点……

知道了这一点，我们就不用苛求自己的产品上线后马上一飞冲天。从心理上接受这个事情，我们就能更加从容自由地去迭代和尝试。正如 Airbnb 创始人 Brian Chesky 所说的那样：“如果你的产品发布后没人买账的话，那么不妨再发布一次。”反正你是小公司，没人关心你的产品到底发布了几次。

产品发布之后，一般会有一个数据拉升的曲线，之后就是不断的迭代了。迭代就涉及到功能和版本规划，极客时间初期版本基本上是没有规划的，1.0.0 发布之后，需求和用户反馈即扑面而来，我们只能且战且行，临时计划，随时发布。两周之后，差不多有了比较细致的计划，一月一个大版本，一个小版本，迭代着往前跑。

有计划就行了吗，并不是这样，因为计划赶不上变化，甚至很多变化是不可控的。

3. 计划赶不上变化

在做产品的过程中我们会遇到各种意想不到的问题，比如产品延期，人员变动，产品特性用户不买账，甚至你计划好上线的运营活动会因为苹果不给过审，白白等待两个星期错过最佳时期……

遇到变化怎么办？分析问题，解决问题，根据用户的反馈做出更好的解决方案，复盘，打样，然后再次制定计划和执行。

有人会觉得如果总是变那干脆不要计划了，这也是不可取的。邱岳老师在他的产品专栏里说过，没有任何作战计划在与敌人遭遇之后依然有效，但做计划的过程依然是必要的。缺乏计划会让产品失掉节奏感，员工失去方向，并且很难专注。计划制定的过程，本身是一个制定战略，统一思想，上下齐心的过程。也就是说，大家要登船渡海，扬帆起航了，得弄个罗盘，定好灯塔，然后再出发，这样在行进的过程中，无论怎么折腾，总的方向不会有大的偏差。

4. 遇到挫折怎么办？不要有侥幸心理

我们在做系统开发的时候经常会遇到这样的问题，生产系统好好的谁也没动，也没有大的流量进来，一切都有条不紊，然后系统突然就挂了。这时候我们会下意识的以为是偶然事件并祭出杀手锏「重启试试」。重启能够撑一阵子，但是很快又挂了，往返几次，工程师们才会意识到是真的出了问题，开始从代码和日志中寻找蛛丝马迹。这种情况常有发生，一般是因为数据或流量突破了某个边界，或者设计的时候没有考虑某种状态的变化。你只有找到了真正的原因，才能彻底解决问题。

记住墨菲定律，当你认为要出问题的时候，就一定会出问题，决不能有侥幸心理。

5. 寻找外援

程序员解决研发中碰到的问题喜欢钻牛角尖，看起来不达目的誓不休，但你可能解决的是个陈旧的问题，别人早就解决了一千遍，你搞不定只是因为你不知道而已。所以，当我们被某个问题卡了很久的时候，就该去寻求帮助了。这种帮助可以是公司内部的，也可以是公司外部的。

我们在开发这款产品的过程中得到了很多朋友的帮助，得到、知识星球、微信、微信读书的朋友，他们都给了非常好的意见或建议。这时候有人就会问了，你这是有资源，我们没有资源怎么去找外援呢？

要知道创业者的资源也不是从天下掉下来的，而是付出自己的时间和资源置换的。如何获取资源呢？

一，打铁还需自身硬，你自己得有真本事。

二，把自己知道的东西分享给别人。我经常会获得一些陌生人的帮助，问起原因，说是 MacTalk 的某一篇文章对其有极大的帮助。说实话我已经记不起是什么文章了。

三，构建健康的社交圈子。有些人能够成为生死之交，有些可以成为朋友，有的人能在关键时候能够互相帮助。不要太计较得失，在有可能的情况下尽最大努力帮助别人。

资源是相互吸引的，你想要资源，首先自己也得有资源，否则你有什么资格免费获得别人的帮助呢？

极客时间：现在有不少观点是技术人要具备产品思维，您能分享一下您的观点么？具体落地的话，该怎样提升产品思维呢？

池建强：技术人学习一些产品知识，对自己有百利无一害。

工程师如果对产品很有感觉，和产品经理沟通起来会更加顺畅，而不是你说什么我就做什么。在很多互联网公司工程师都具备很强的产品思维，甚至一些技术产品本身就是工程师主导研发的。

还有一些技术人会直接转成产品经理，腾讯的马化腾就非常推崇技术出身的产品经理，他说：

产品和服务是需要大量技术背景的，我们希望的产品经理是非常资深的，做过前端、后端开发的技术研发人员晋升而来。好的产品最好交到一个有技术能力、有经验的人员手上，这样会让大家更加放心。

很多产品经理对核心能力的关注不够，不是说完全没有关注，而是没有关注到位。核心能力不仅仅是功能，也包括性能。对于技术出身的产品经理，特别是做后台出来的，如果自己有能力、有信心做到对核心能力的关注，肯定会渴望将速度、后台做到极限。

事实上，现在很多顶尖的产品经理，当年都是喜欢编程的少年人。

还有一些技术人出来创业，这时候就需要关注产品的整个生命周期，而不是局限在技术领域，产品思维就越发重要了。

要不要学习产品构建的知识呢？无论从哪个方面讲 —— 理解、协作、沟通、转行、创业 —— 这个答案一定是肯定的。技术人了解产品知识，不仅能够加速自己的成长，降低沟通成本，形成更好的协作关系，甚至未来，你去主导一款自己的产品也是非常可能的。

如何提高产品思维呢？这是个非常大的话题，很难在一篇文章里讲清楚。我们特地在极客时间开设了三个产品专栏，让资深的产品专家，从实际的场景出发为大家剖析产品的诞生、增长、数据能力和商业意识等，有兴趣的话大家可以了解一下。当然，专栏只是地图和指引，所有的知识，都需要你在实战中演练和打磨。

祝好运。

大咖对话 | 焦烈焱：从四个维度更好的激发团队创造力

你好！

本周作客“大咖对话”的是普元信息 CTO 焦烈焱，他全面负责普元信息技术与产品的运营工作，是公司技术发展战略的重要决策人。焦烈焱在企业技术架构方面有二十余年的经验，长期致力于分布式环境的企业计算、SOA 与云计算技术研究与实践。

本周，我们跟他聊了聊 CTO 需要具备的能力，以及如何激发团队创造力等话题。

极客时间：您能先简单介绍一下您自己么？

焦烈焱：大家好，我是焦烈焱，现在在普元信息担任 CTO。2001 年我加入普元，从程序员做起，慢慢成长为 Team Leader、架构师，到最后成为 CTO，这是一个很漫长的过程，在技术理念、做事方法、团队建设、人际关系等诸多方面，都会有比较大的转变。其中很典型的一点就是，我要花更多的时间去“务虚”，去做思考、做沟通、做规划等相关事情，同时，你走得越高，你“务虚”的时间就要越多。

极客时间：您觉得一个优秀的 CTO 应该具备哪些方面的素质与能力？

焦烈焱：关于 CTO，我觉得最重要的一个能力是能把事情做好。我们 CEO 对于 CTO 的要求就两点，第一是要有对未来的预见与洞察；第二是要能激发团队的创造力。在他看来，如果能做好这两点，那至少能打 80 分以上。

当然，不同公司的 CTO 承担的职责不同，有些 CTO 从事的工作可能更像传统意义上的 CIO。之前我在美国参加一个 Gartner 的会，他们去采访通用电气的 CEO，问他对 CIO 到底有什么样的要求，他回答，“我没什么其他要求，就一个，保证系统稳定运行就好了”。这句话听起来很简单，但真正要做好，面临的挑战还是挺多的。

首先，要面对业务快速发展带来的挑战。 如果业务量一上来，你的系统架构就支撑不了，那就不叫系统稳定运行了，而是根本无法满足业务要求。比较好的方法是在系统架构设计之初，就对业务未来的发展有一定的预测，搭建一个能支撑现有业务量 10 倍数的架构。当然，这中间还涉及到资源评估的事情，因为资源永远是不够的，需要把有限的资源用到最重要的地方去。

其次，要清楚需要什么技术，以及它能对业务起到什么样的作用。 比如，要搭建一个 Hadoop 集群，需要 300 台机器，有些老板会问你这么做的原因及目的，那你就需要用对方听得懂的话语跟他解释清楚。如果能把这件事讲清楚，那至少作为一个 CTO 或 CIO 是及格的。

再往上，要让技术对业务方向起到推动或引领的价值，也就是技术能帮助企业解决核心竞争力的问题。这时，技术的价值已经不再仅仅是满足业务需求了，还要能够提前预判，做到领先业务一步，引导业务发展，甚至是在原有业务基础上，开拓出新的方向。如果能做到这一点，你作为 CTO 的能力必将又上一个台阶。

其实，以上提到的几点也可以看做是 CTO 与 CEO 有效沟通、获得 CEO 信任的出发点，核心就是要站在业务的视角来考虑问题，来思考公司整体对技术的要求是怎样的，而不是只站在技术的角度。

极客时间：能具体分享一下如何站在业务视角思考吗？

焦烈焱：普元做了这么多年，其实取得了不少成绩，从最开始的时候，跟客户讲我们的理念，大家都不理解，觉得不靠谱，到现在很多人认同我们，这是一个非常艰难，但也非常值得自豪的过程。

不过，虽然我们取得了不少成绩，但我们也犯过不少错误、做坏过很多产品。很多时候，你感觉你看到了未来的技术方向，但实际上真正做出来的东西，跟你的想象以及公司的业务之间会有很大的差距。

举个例子，我们之前曾做过一个 UI 可视化的产品，因为那个时候 UI 开发非常麻烦，会花费很多精力。我们的初衷是提供这么一个产品，简化大家的 UI 开发过程，但产品出来后推给客户时，反馈却并不好，因为这其实并不是他们的痛点。这个产品就失败了，后来就没有再做下去了。

这样的失败在普元并不罕见。我们做过很多失败的产品，这些产品从技术的角度来讲都是非常不错的，但关键是这些技术、这些产品有没有跟公司的商业目标匹配起来，有没有跟公司当时的能力匹配起来，这是导致失败的主要原因。

普元一路走来摸爬滚打，就是掉进坑里再爬起来，再掉进去，再爬出来的过程。但回过头来想，犯错误并不要紧，人都是在错误里成长起来的，没有什么是能一蹴而就的。关键是，你爬起来之后要复盘总结，不要再掉到同样的坑里去。

极客时间：您提到激发团队创造力，具体有哪些做法呢？

焦烈焱：激发团队创造力是 CTO 能力中非常重要的一部分，从我的实践来讲，可以从以下 4 个要点出发。

第一，要有责任感。作为 CTO，你首先需要有责任感。中国女排奥运会夺冠，在接受记者采访时，郎平说，比赛的成绩是跟队员的未来密切相关的，所以，你能不能打出好成绩，不仅关于你自己，更关于整个团队别人的前途。

这句话给我留下的印象很深，这就是责任感。说回到带团队，公司把这么重要的事情交给你；团队那么多兄弟相信你愿意跟着你；客户信任你愿意用你的产品，你就需要对他们负责。

这会带来很大的压力，但这些压力应该是激励你、迫使你不断前进，想办法把事情做得更好。

第二点，要有效沟通。沟通其实就是讲故事。团队人少的时候，你可以一个一个跟对方沟通，一遍不行说两遍三遍，总能说清楚。但当团队大了，人数超过 150 人之后，就很难用亲情、友情、人与人之间的关系等情感的方式去沟通。

你需要的是讲故事，用故事去沟通效果最好。当你在说业务发展、愿景的时候，其实就是在讲故事，而把这个故事讲好，自然能把你想要团队做的事、希望他们达成的目标传达给他们，带着他们一起向上走。

第三，要树立合适的愿景。跟团队讲故事的时候必然会聊到愿景，可以说愿景是故事的核心。但我们树立的愿景要切合公司发展步伐，不能走得太远太前。

比如我们之前踩过一个坑，2004 年左右，普元就提出了类似云计算的愿景，但那个愿景太超前了，行业还没有发展到那一个阶段，导致无论是跟公司内部还是公司外部提我们愿景的时候，大家都不理解，觉得不靠谱。最终，这个愿景对公司发展起到的拉动作用是极其细微的。

因此，我们预见 5 年之后的行业情形是最合适的，预见 10 年就太远了，对公司当前的发展并没有太大的好处。

第四，要有匠人精神。这个词现在被说的有点多了，但一家企业必须找到自己最擅长的领域，然后专注的打磨，将其做到极致，变成自身的核心竞争力。现在很多领域都有赚钱的机会，但如果不是跟自己核心相关的话，就要懂得取舍。

我们的创新可能都是时间熬出来的，我们掉过无数的坑，经历过无数次的错误，但是我们想办法从坑里爬出来，一步一个脚印把事情做好。一个产品做了废，废了再做，可能要磨四遍、五遍才有突破。而在这个过程中，我们也能不断去思考怎么把技术跟业务做更好的结合。

大咖对话 | 玉攻：四个维度看小程序与App的区别

你好！

本周大咖对话的嘉宾是蚂蚁金服资深技术专家，蚂蚁金融科技产品研发团队主管玉攻，目前主要负责金融级云产品的架构和研发工作。2015 年加入蚂蚁金服，并作为金融科技核心创始团队成员，领导和创立了蚂蚁金服的第一代 PaaS 云平台产品蚂蚁金融云。

小程序从一开始的无人看好，到后来的风生水起，再到急转直下，现在又要重回巅峰，诸多互联网巨头纷纷发力小程序，那小程序与 App 之间的区别是什么，如何才能更好的发掘小程序的价值，玉攻与我们分享了他的观点。

极客时间：在您看来，小程序和 App 之间最主要的区别是什么？小程序会取代 App 吗？
玉攻：不会，小程序不会取代 App，从用户的角度来看，在一些高频的使用场景，App 的地位从不曾被动摇。一般情况下，用户每天打开使用频率最高的 App 不会超过 10 个。只有一些低频使用的 App 非常适合小程序实现。

从大型企业的角度来看，大型互联网公司往往会采用“App+ 小程序”的模式，小程序会极大地提升 App 用户的活跃度，甚至会成为整个业务产品矩阵中的一部分，但不会替代 App。

从个人开发者和中小型企业的角度来看，小程序的研发和推广成本远远低于 App，在研发初期和新业务试错环节，小程序会优于 App。但随着企业发展成熟，需求增加，功能要求更丰富时，App 的优势就凸显出来了。

从业务的角度，如果某项业务需要短时间依附于大平台生态，借助平台的力量发展，那么小程序要明显优于 App。但当业务逐渐成熟并且被市场认可之后，平台的局限性也会逐渐显现出来，由小程序转向 App 就成了必然。

说到底，小程序和 App 并不矛盾，但是小程序绝对不可能取代 App 的价值。大厂会并行走两条路，App 负责高频场景，小程序负责拉新试错。对于一些快速成长的创业公司，我建议从小程序做起，因为一开始就做 App 的成本非常高，但是先开发小程序，就可以用最低的成本去验证业务的创新性和市场接受度。如果业务上能成功，再去扩展业务模式，继续用小程序或者做成一款 App 都可以，所以在一开始用小程序相对来说性价比更高。

小程序近两年确实出现了一些爆款，但在这些爆款背后，其实大多数小程序都死掉了，探究其背后的原因，是因为很多人并没有搞懂小程序的持续迭代，不清楚小程序需要与场景深度结合。由于小程序开发成本低，所以市场上大量小程序都存在很快上线却缺乏维护的问题，没有精心运营，小程序的迭代就成了“死棋”；另外，很多开发者还没有意识到小程序与 App 的区别，只是简单地将 App 现有功能移植到小程序上，在产品形态上只注重功能而忽视了小程序最看重的场景问题，这就解释了为什么有的人开发的 App 活跃度还不错，但转战到小程序却满盘皆输的原因。

对于小程序的未来，我希望小程序的发展不再局限于某一个平台，而是某个操作系统的小程序，甚至成为一种“新型 App”。不过目前阶段，还是要分清小程序和 App 有不同的用处，要根据客群、使用频率来决定最后选择小程序还是 App。

极客时间：支付宝为什么要做小程序，而支付宝小程序又有哪些独特的地方？
玉攻：支付宝小程序其实是一个极简的服务工具，这与支付宝的定位不谋而合。支付宝小程序可以帮助用户在生活 / 商业的场景下开发出一些创新型的业务。其实大多数人很多时候并没有意识到自己正在使用的就是支付宝小程序，比如很多人每天去蚂蚁森林浇水，其实蚂蚁森林就是一款支付宝小程序。

支付宝小程序集成了支付宝最核心的一些能力，比如支付、交易、信用、风控、AR 等等，所以在支付宝小程序里我们可以实现很多有创意的想法。举个例子，充电宝其实是基于 [街电] 这样的一个小程序，充分利用支付宝用户的信用和支付能力，产生的一种新型的商业模式。在我看来，支付宝小程序的初衷就是让大众的生活变得更方便，帮助企业更快地触达客户，让创新无处不在。

支付宝小程序是一个前端技术，整个浏览器内核采用 UC 浏览器的内核，WebView 的稳定性和兼容性非常不错，Crash 率只有一般系统 WebView 的 1/5。另外，UC 内核针对内存做了大量的优化，包括图片的内存、渲染内存、JS 内存、峰值内存管理。支付宝小程序的内核启动逻辑是 v8 引擎 CodeCache 深度优化，这使得 JS 代码解析和编译时间减少 40% 左右。首页的加载和渲染对于冷启动非常关键，为了减少用户在首页显示前的等待时间，支付宝小程序采用离线缓存的方式优化加载流程。

整个阿里经济体在做小程序的时候，强调统一的技术架构和多端投放，我并不希望小程序变成巨头进行技术垄断的手段，或者说技术封闭的一个边界。小程序最大的价值在于真正服务客户，让客户受益，给客户提供更多的渠道，获取更大的流量。

目前在阿里体系里，我们想做统一的小程序，也就是支付宝小程序不仅在支付宝里可以使用到，在其他平台如天猫、淘宝、高德等也可以使用。比如打车，用户既可以从高德平台进入，也可以从支付宝的平台进入；比如某个特卖的小程序，用户有可能是从淘宝的渠道进入，也有可能是从支付宝的渠道进入。所以支付宝小程序不是单一的，它的背后是有强大的“矩阵”在支撑。开发支付宝小程序，表面上获得的是支付宝的渠道优势，其实它背后是整个阿里经济体系的支持。这是其他平台所没有的优势。

极客时间：普通开发者如何才能更好的发掘小程序的价值呢？
玉攻：其实支付宝小程序云是一个非常好的选择，它能让开发者不需要关心证书、运维、扩容，不需要关心被黑客攻击，只需要专注写好自己的代码和业务逻辑即可。

平台技术一直是我非常感兴趣的方向。我在 IBM 参与过 WebSphere 这样的应用服务器，我也做过 Java 开发。技术的发展在这十几年的时间里，基本实现了基础设施的“云化”。整个业界在最开始做云的时候，真的是“云里雾里”。随着认知的成熟，我们发现云其实是一层一层的，最下面一层叫做 IaaS，相当于把计算存储网络的资源“云化”，所谓的云化就是能够让更多的人以共享的方式使用到这些资源，而不需要自己去做比如购买机器、物理机、买机房设置网络等等这些事情。这个阶段我们称为 Cloud-Based。对于金融行业来说，要想实现云化，其实是需要心理斗争的。但当我们心里迈过这个门槛的时候，我们就进入到 PaaS 层面。

PaaS 层面要解决的问题就是让应用变得更舒服一点。比如原来要开发一个应用，需要考虑如何设计中间件、网关、流控、分布式架构等，当中间件云化之后，需要做的就是保证上层业务的实现，让业务衍生成为一个能够支持一定规模的互联网的产品，这个阶段就是 Cloud-Ready。我在做中间件的时候，发现中间件的未来其实已经往 PaaS 层面发展，中间件的云化可以帮助上层业务更容易地享受到基础设施的便利性。

而我们现在要走的一个方向，其实跟支付宝小程序云服务未来的发展方向是一致的，也就是 Cloud-Native。现在技术圈比较火的就是 Serverless，就是你已经不关心服务器这件事情了，所有的基础设施，包括运维，都已经由云厂商帮助你去解决，而你真正需要关注的只是你的应用和你的业务逻辑。这其实就是支付宝小程序云服务的发展的轨迹。

大咖对话 | 王坚：我从不吃后悔药

你好！

本周大咖对话的嘉宾是王坚，他是 2050 志愿者，阿里云创始人，阿里巴巴技术委员会主席。日前，极客邦科技创始人兼 CEO 霍泰稳 Kevin 与王坚在极客 Live 进行了一次精彩的直播，聊了他对于自己、对于技术人、对于世界的诸多想法与思考，带来了不一样的王坚。本文特意筛选了直播中关于技术人成长、管理等相关的话题分享给大家，希望你能有所收获。

Kevin：在您看来，一个优秀的技术人应该具备哪些特质？

王坚：写好代码当然是最重要的，代码都写不好，再说别的都不靠谱，这是技术使用层面的问题，是最基本的。但一个好的技术人不仅该知道如何使用技术，还要有能力创造新技术，这可能是我们国内技术人面临的最大挑战。

使用技术和创造技术是两个不同的概念，并不是说谁比谁更高级。我们的历史责任应该是为全世界创造技术，比如从语言这个角度讲，我们能否为世界贡献一门语言，这并不是说要“为国争光”，而是说要对世界有贡献，要想一想我们能为这个世界做点什么。

除此之外，还要保持年轻的心态。而保持年轻心态的关键就是要享受现在所做的事情，只要你真正热爱一件事，做起来就会觉得是种享受。如果将享受理解成远离你现在的工作，这是件很悲剧的事情。有些人希望一辈子都生活在海边，这本身没有错，但如果觉得只有去海边度假才是享受生活，这就是个问题了。对我而言，我每天都坐在海边，享受自己所做的事，做对做错都不重要，做好做坏也不重要，不要以结果的好坏作为判断你是否享受的标准。

Kevin：您对于管理有何心得体会？

王坚：说真的，做管理还是挺难的，如果允许我自夸一下的话，我觉得所谓的创新工作或治理工作，这方面的直觉会相当重要，至少对我来讲是这样。任何优秀的管理方法，管理者都要对流程非常清楚，但这里面也有一个诀窍，就是你要精准地知道，哪些是你要做的事情，哪些事情一定不做。

很多时候，我们最艰难的环节都卡在“纠结”这件事情上，于是以花时间做了一些本来可做可不做的事情，浪费了一些原本可以花在必做事情上的时间。这个判断的过程对我来说是依靠直觉完成的，作为管理者，对于流程的严格管理是必要的，但相信直觉一样也很重要。直觉是支配你的巨大资源，有了它你才会进入流程的管理，这方面我的体会蛮深的。

大部分时候，要平衡商业、技术和管理这三者的关系，确实会遇到一些困难，对我自己而言，这时候最重要的就是要接受别人的帮助。我经常会讲，一个人有长处其实是很危险的一件事，因为他的短处是需要别人帮忙填补的，但很多人看不到这一点。

我觉得我最大的长处，并不是我自己有多优秀，而是我可以心安理得地接受别人的帮助，比如 2050，就是我接受别人的帮助，而不是我帮助别人。如果你管理上比较弱，在这方面就要多接受别人的帮助，如果不能接受，那就会是个灾难，不要试图去做你明知道做不好的事情。适时接受他人援手，也是一个人成长最后的挑战。

Kevin：和马云在一起工作是一种什么样的体验？

王坚：我知道，很多人想了解和马云一起工作是一种什么体验，对此我觉得非常幸运，我还是更喜欢叫他马总，这是对他的尊称，能够有机会跟他在一起工作，对我的帮助非常大，和他相处也没什么压力。

大家都知道他在公众面前做了很多次演讲，我可能是少数真正理解他为什么会那样讲的人之一。很多时候，我可以明白他的所思所想，他说出的话和他的思想保持着高度的一致性，这让我非常佩服。他是真正从解决社会问题的角度来看待所有事情的人，你可以从他身上学到很多东西，包括对企业家的尊重和对中小企业的尊重。

同时，马总也是一位非常谦虚的人，他经常说自己不懂技术，我会跟他讲，懂不懂技术并不是核心问题。他真心地尊重技术，有时我甚至觉得，他比一些懂技术的人还要尊重技术。

我经常讲，阿里是一个平台，很多人在阿里工作的时候，他（她）的能量被放大了，边界随之扩张，学到的东西自然也变多了。人和人之间原本没有那么大的差别，但你身处潮流的中心，边界又足够大，自然就可以做很多事情，学很多别人学不到的东西，对你的成长就会有更多帮助。

其实，我们做技术也是在拓展业务的边界，业务会反过来推动技术的发展。我定义业务和技术的关系，是铁轨跟火车头的关系，这里并不是说铁轨一定是业务或技术，这二者都没问题。

你很难讲，是火车头还是铁轨将你带到一个地方的，因为铁路不修到那里，火车就到不了那儿；铁轨修到了那里，没有火车也无法抵达，这二者是统一的，这就是他们之间的关系。我认为，业务在推进技术，技术也在创造崭新的业务，在今天这个时代，这二者是一体的，这也是我说这是最好的时代的理由之一。

Kevin：咱们最后快问快答几个问题。
Q1：您认为自己做过最牛逼的事情是什么？
王坚：今年做的最牛逼的事情就是让志愿者来办一个大会（2050）。

Q2：有最后悔的事情吗？是什么？
王坚：真没有最后悔的事情，我这人从来不吃后悔药，真没有什么感到后悔的事情。

Q3：过去对您触动最大的一件事是什么？
王坚：阿里云做到后面，我发现自己接触到了整个社会，这是我第一次发现有那么多人要用云计算，世界变得如此开阔。这件事对我触动很大，让我改变了很多想法，阿里云折射出社会的一面，打开了一扇崭新的大门。

Q4：做过最尴尬的事情是什么？
王坚：我从学校到研究院，又到阿里，最尴尬的事情就是整天都有人问我，这跟你学心理学有没有关系？我说有关系是不对的，说没关系也是不对的，这就是最尴尬的地方。怎么说都得说点理由出来，但其实一点理由都没有，这就是最尴尬的事情。

Q5：作为阿里巴巴的首席技术官，您会写代码吗？
王坚：我真的会写代码，只不过我今天写的代码对公司的贡献已经微乎其微了，还是不说的为好。

Q6：最近有哪些新的感悟？
王坚：谈不上新的感悟，如果一定要说，那就是做了 2050 和城市大脑之后就会觉得，我之前讲的那句话是对的，这真的是人类历史上少数几次最好的时代，而不是笼统的好时代。

Q7：最近看的一本书，或者是电影是什么？
王坚：最近我看了很多书，不止一本，电影倒是没怎么看。我今天看了一本书，内容讲纸是从哪里来的，我觉得蛮有意思的。那些非常日常的东西，很多人会忘记他们的出处。我们经常会去追求一些看起来很深奥的东西，但那些东西却并不能告诉你有价值的道理，倒是那些看似非常普通的事情，可以告诉你一些非常朴素的道理。

Q8：您的口头禅是什么？我很幸运吗？
王坚：大家都觉得我的口头禅是“不知道我说清楚了没有”，但“我很幸运”这个确实是我最近经常讲的，真的不是客气话，是我的心里话。

Q9：您最害怕的三件事是什么？
王坚：别说三件事，连一件害怕的事我都讲不出。这个世界还是很宽容的，你就是要面对那些应该面对的问题。站在我的角度，我自己没有什么特别害怕的事情，我只是在想如何能让这个世界变得人人都可以享受其中，不仅仅是物质层面的，还有精神层面的，这可能是我想得比较多的。

Q10：您最敬佩的人是谁？
王坚：这个问题很难回答，我最早看维纳写的书，那时候年纪比较轻，就觉得特别敬佩他，但年纪大了一些以后可能就没有那种感觉了，我只能说我年纪轻的时候曾经敬佩过的就是这些人。因为他们在很多人尚没有能力描述清楚的时候，他们就可以做一些比较清晰而有逻辑地表达了。

另外，很多时候我觉得最好不要用“最”字，比如说刚才讲到的马云，再比如比尔·盖茨，还有一些书籍的作者我都很敬佩。再比如最早阿里云的一些客户，我也是真的很敬佩他们，没有他们就没有我，这是我自己的真实感受。

Q11：最不满意自己的事情，或者最不满意自己的地方是什么？
王坚：跟 Kevin 认识那么久还是第一次做直播，这个话是什么意思呢？其实世界真的很大，你只能遇到很小的一部分，跟 Kevin 那么熟也只不过接触了这么一点，这是我最不满意的地方，我应该更多地接触一下这个世界。

Q12：博士给我们这些热爱科技的年轻人能不能说几句话？
王坚：第一句，这是年轻人可以创造未来的时代，你真的要打起精神来。第二句，要相信天是蓝蓝的天，乐观是解决问题的必要因素，世界上有很多的问题和挑战，依靠乐观是可以解决一部分的，也是我们年轻人给这个世界带来的很棒的东西。我曾经和人讲，年轻人是最后去解决这个世界问题的人，你不乐观，这个世界就没有未来。我们真的应该努力让这个世界变得更好，让大家都能享受在这个星球上的生活。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

大咖对话 | 王平：从人、事、价值观、文化等维度看技术团队转型

你好！

今天作客大咖对话的嘉宾是前 Mobvista CTO 王平，在 Mobvista 负责公司整体商业变现技术体系的构建和管理。此前先后在百度、高德就职。在百度，作为凤巢核心成员，负责凤巢流量变现商业产品的技术管理。随后加入高德担任商业变现总监，负责产品和技术管理。多年职业生涯一直活跃于互联网商业变现领域的风口，对行业技术体系构建有深刻理解。

今天，我们跟他聊了聊出海创业的趋势 ，以及公司技术转型中的挑战与实践。

极客时间：您之前在 Mobvista 接触过很多移动出海的案例，以您对海外市场的了解和观察，能分享一下当前移动出海的趋势吗？对于创业者，有何建议呢？
王平：自 2010 年中国移动互联网出海的浪潮兴起，近 9 年的时间里，中国移动出海的产品历经工具类应用的百花齐放，到安全、桌面类应用和轻型游戏的爆发式增长和洗牌，再到娱乐内容类产品的迭代与崛起，目前已经进入稳定发展阶段。

前几年，移动出海成为热点的主要原因有两方面，一是当时国内的移动互联网市场经过将近十年的发展后已经慢慢趋于饱和，移动互联网的人口红利也已经被慢慢消耗完了，很多行业都从蓝海市场变成了红海市场。而与此同时，海外的市场就相当广阔了，比如像南美洲、印度、东南亚这些国家和地区，他们当时移动互联网发展的程度与规模远落后于国内，人口红利和蓝海市场优势依然存在，对于中国的创业者而言，还具备相对的竞争优势。

二是国内的创业者走得比较领先，他们经历了移动互联网的爆发式发展，等于是以一种高维的状态去向低维的市场进攻，有非常大的优势。从这些角度来看，相较国内的激烈竞争，海外的市场机会非常多，这也是当时越来越多的中国创业者选择出海的原因。

现在临近 2019 年，再去审视出海，局势和环境又有了较大的变化。首先，5 年前所谓的国内海外的信息差几乎已经不存在，现在每个人都知道出海有机会，都知道出海怎么买量、知道怎么判断流量质量；其次，流量的聚合效应在加强，头部玩家在不断进行行业整合，比如阿里布局东南亚电商、今日头条做海外版今日头条；最后，出海产品在往内容类、社交类、购物类产品等转型的过程中，往往面临着规模化瓶颈，至少在东南亚、两印等国家和地区是很明显的，因为从文化语言的角度来看，那不是一个国家。

因此，以我对海外市场的了解和观察，创业者出海依然有机会，但是在市场选择、产品方向选择上需要谨慎。现在海外已经不再是蓝海市场，竞争已经充分，没有了信息差和经验差的绝对优势，接下去拼得还是创业者的战略、产品、市场等真正的内功修为。

另外，虽然早年间，大家是认为国内创业越来越难，才去寻求外部市场，也尝到了甜头。但是，近几年，国内的创业局面，发生了一些根本性的改变。首先，市场依旧很大，依旧有很多机会，比如典型的拼多多，通过三四线城市下沉，以及去中心化的营销模式创新，挖掘了一个极大的市场蛋糕。所以不是不存在市场，而是我们没有发现市场。

其次，随着中国自身的发展，已经进入了产业升级的轨道，越来越多的出现了传统行业和互联网的碰撞机会，这将会诞生一大批各个领域的互联网 + 公司，而且各个领域都有机会，像 VIPKID、钉钉等就是典型代表。所以大家不妨可以思考下国内市场的空间。

最后，我认为目前的互联网发展到了一个十字路口，不久的将来一定会引来生产力级别跃迁和变革的机会，比如物联网、AI 领域。若有人能掌握生产力级别的核心竞争力，必然将引领未来的发展趋势。所以，对于有技术追求的创业者，不妨多关注和死磕技术竞争力。这条路很难，只有心怀梦想不畏艰难的人，才有机会。

极客时间：您之前在 Mobvista 主导了公司的技术转型，能否分享一下您的这段经历吗？
王平：Mobvista 早期是一家商务运营驱动的公司，团队让我加入的初心是希望进行技术转型，原因在于广告行业本质是数据业务，是解决广告和流量匹配效果的业务。

回顾 Mobvista 的技术转型路线，经历了人、事、价值观、文化四个关键阶段，前三者几乎同时进行，并稳定持续近 2 年，文化是在 2016 年底开始思考和推进的，很遗憾，离开前并没有完成真正的落地。

人才战略是我最早推进的事情，没有人才储备，就没有所谓的技术驱动。在早期半年内，我们搭建了一支核心团队，未来团队几乎以此为基础展开。

事的角度，我们梳理了业务和技术体系，确定了一系列的重点业务和技术专项，全力解决重点核心工作以求突破，又通过“事”来以战养兵，很多未来的核心方向都是这个过程中发展起来的。

伴随着人和事的推进，我们在这个过程中确定了团队当时的价值观，主要有：以终为始、有分工无边界、有功必奖有过必究等。

然而，上述举措在团队规模 150 人以内是能 work 的，但超过 150 人以后，就会发现团队的管理遇到了很大的效率和执行问题。这是发生在 2016 年底。随后，经过思考后认识到，需要通过文化去凝聚团队，之前的价值观还只是一种做事方式，并没有形成一种文化。2017 年，我做的重要的事情之一就是技术团队文化的构建。

极客时间：能否分享一下，在具体的执行层面，您是如何打造技术团队文化的呢？
王平：首先，我想再强调一下文化的重要性。文化跟团队人数是绝对相关的，之前提到，当团队规模超过 150 人之后，管理者能明显感觉到团队管理难度的差异，很多事情的执行与落地会比之前困难很多，很多管理层想法在传递过程中会有非常严重的损耗，你会发现一切好像都变成了一个相对不可控的状态。

为了解决这些问题，我花费了很多时间去处理并思考，发现一个比较有意思的事情是，出了问题，大家复盘之后会发现是某个操作流程或规范上有缺陷，处理方法自然是去完善这些地方。

但这么做其实存在极大的问题，原因在于，如果真的企图通过流程机制或规范的不断完善细化，来解决整个管理中遇到的问题，几乎是一个不可能完成的任务，因为规则是不可能穷尽的。同时，必须要认知到一点，规则制定得越细，团队成员可发挥的空间就越少。

而之所以会出现上面提到的诸多问题，归根到底是因为人多了，而不同的人的想法、追求、价值观都是有差别的。因此，解决问题的关键点就落到了，如何让大家在公司或技术团队范畴内，拥有统一的价值观或文化上。

打个比方，社会有其自身的道德价值观，也有其法律，但法律只能规定整个社会的道德底线，而没法定义上限。整个社会的道德体现最终取决于其价值观，比如尊老爱幼，这句话就是价值观或文化的体现，它有很多延展和体现，我们能用四个字概括，却不可能在法律法规里一一规定到底什么样的行为是尊老爱幼的行为，相信大家都能体会。这其实跟公司的流程规范有些类似，都只能定义底线。

这种价值观或文化的另一个好处是，能在很多灰度地带，引导大家自动选择一个相对正确的行动方向，也能避免去制定极其详细繁杂的流程规范和机制。这是我对文化的一个思考。

确定思路之后，就要去打造属于技术中心的统一的价值观和文化。在具体的执行层面，首先，我需要一个能够在文化建设方面帮助到我的人，我的做法是招聘了一位 HRBP，来帮助我一起把文化这件事做好。毕竟文化构建对于我来讲是一个相对陌生的课题，而这在一定范畴内又是属于 HR 体系的事情，专业的事情交给专业的人来做，这是非常重要的。

接下来就是一些围绕文化的实践，比如要先确定整个技术团队的文化是什么，以及我们怎么解读这个文化，哪些案例是最能体现文化内涵的，等等。

当时我定下的技术团队的文化是敬畏技术、追求卓越，再把之前一些执行层面的价值观（以终为始、有分工无边界、有功必奖有过必究等），以及很多现实中的案例完善进去，形成对文化的解读。

确定文化是什么之后，就需要在整个公司层面、各个场合去不断强化这个文化，不断强调哪些价值观、哪些行为会被公司认可，比如通过平时的一些奖励机制，引导团队成员的行为逐渐靠近我们文化所推崇的行为。

坦白说，这个文化落地的过程中存在很多挑战，举个最典型的例子，团队之所以会出现这样那样的问题，很大概率上是因为中层管理团队已经在文化和价值观上出现了偏差。那你推动文化落地的时候，必然会在中层管理团队这儿就感受到一些阻力，比如推脱说现在业务很紧，如果在质量保障工作上投入更多精力的话，就可能会影响到业务的进度，给你出一个选择难题。

但这中间的逻辑是存在问题的，乍一看，业务很忙，那自然要把更多的精力聚焦在业务上，把业务做得漂亮，但长远来看，减少了放在质量保障上的时间精力，质量保障没有做好的话，接下来反而会出更多的问题，影响到业务。

因此，我也做好了准备，先对整个中层管理团队做一个整体的 Check，看他们的文化和价值观取向是否一致，如果出现差异极大的同学，就必须要重新调整。这是一个比较艰难的事情，但为了文化的顺利落地，这件事情是一定要去做的。毕竟，当团队扩张到更大规模的时候，文化与价值观能否统一，会决定整个团队的精神面貌以及未来的战斗力。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

大咖对话 | 王平：如何快速搭建核心技术团队

你好！

今天大咖对话的嘉宾是前 Mobvista CTO 王平，在 Mobvista 负责公司整体商业变现技术体系的构建和管理。此前先后在百度、高德就职。在百度，作为凤巢核心成员，负责凤巢流量变现商业产品的技术管理。随后加入高德担任商业变现总监，负责产品和技术管理。多年职业生涯一直活跃于互联网商业变现领域的风口，对行业技术体系构建有深刻理解。

今天，我们跟他聊了聊如何搭建核心团队，以及如何做好跨地域沟通等话题。

极客时间：据了解，您主导了公司的技术转型，并在早期半年内，搭建了一支核心团队，能否分享一下您当时的做法，以及是如何吸引核心人才加入的呢？
王平：首先肯定是要先做一个人才盘点，我们当时盘点下来，大概需要 6 个核心成员，包括运维、测试、算法、工程、业务等领域的相关负责人，后来这个核心班子扩展到了 8 个人。

那这些核心成员如何来呢？就需要开源和节流两方面结合，所谓开源，就是外部招聘，所谓节流，就是内部培养。而在当时的情况下，内部培养出的人才是远远赶不上需求的，开源，即外部招聘就成了重点。

首先，要确定人才在哪儿。当时我们团队在向技术方向转型，一个很现实的问题是，公司在广州，但广州这边的技术人才储备是不够的，同时，整个广告行业的人才分布也大多集中在北京。基于这个角度，我们人才战略的第一个决策就是在北京成立一个研发中心，解决了人才在哪里的问题，这是招聘中非常关键的环节。

其次，要确定所需人才类型。当时，广州的技术团队主要是 PHP 后台研发相关的人才，人才盘点后，发现还缺乏两类人才，一类是算法人才，一类是能够支撑流量高并发、低延时、高稳定性的工程架构相关人才。确定去哪儿、招什么人这两点之后，团队组建的基调就定下来了，接下来就是具体的搭班子环节了。

其实，早期组建团队，技术 leader 的个人影响力是非常重要的，比如当时 6 个核心成员中，就有 3 个人是通过我自己的关系挖来的，剩下的再通过招聘和内部提拔来补充。

至于如何吸引这些核心人才的加入，有几个关键点。

首先，你做的事情要能引起他们的兴趣，这是非常重要的一点，也是能不能把大家聚在一起的先决条件。技术在广告领域有很多可做的事情，包括当时我们有一个比较成功的变现产品，日活接近 2 个亿。如此大流量的产品，背后的算法、工程都有很大的挑战，也能带给大家很大的成就感。

其次，对于公司未来发展，要给出一个相对公正客观的分析。我自己加入，本身就代表我是非常看好这件事的，因此，在招聘时，我会跟候选者分享我对未来的看法。至于对方是否认可，就要看双方的互相选择了，也取决于对方认不认可我们在做的事情。但对于创业公司来说，这种冒险精神是非常必要的，如果没有冒险精神，大家很难走到一起创业。

最后，作为创业公司一定要在待遇上给到位，特别是金钱上不能给特别多的话，期权就得到位。对于核心人才，我们当时在期权上做了比较多的倾斜，越早期加入，倾斜的比重就越大，毕竟这些人才过来也是需要冒风险的。

极客时间：您提到 Mobvista 的技术团队分布在广州、北京两地，能分享一些您在跨地域沟通和管理上的经验吗？
王平：目前，整个 Mobvista 有 180 位左右的技术人员，涵盖研发、QA 和运维，基本是以 1：1 的比例分布在北京和广州两地。另外，还有我们在海外收购的公司中也有研发团队，所以还涉及到跨国团队的沟通问题，都非常具有挑战性。

对于每家公司来说，沟通都是非常重要的一件事情，即使是面对面沟通，都有可能出现误差，更不用说跨地域沟通，出现问题的可能性就更大了。在实际管理中，我们一般会从以下几个方面出发去尽量解决。

首先，在业务划分阶段就做好准备，尽量让不同地区团队负责的业务都相对独立，减少跨地域沟通的频次，从根本上解决这个问题。目前我们在这方面做得还不错。

其次，即使各地区的业务相对独立，依旧无法避免跨地域沟通，这时就需要我们有一个定期的沟通机制，从管理团队和一线执行团队两个层面做好沟通。

管理团队层面，我们规定每周必须有一次当面的沟通会议，同步之前的工作进展，明确之后的工作规划。同时，对于遇到的问题，比如哪些问题需要在短时间内就解决，哪些是中长期的问题需要持续关注，都要在管理团队内达成共识。

一线执行团队层面，我们会通过视频会议的方式，尽可能减少信息沟通中产生的偏差。同时对于一些重要项目，我们会安排相关人员出差，通过这些方式尽量去环节跨团队沟通的问题。但如果说完全解决这个问题，这几乎是不现实的，跨团队沟通中的问题或多或少都会存在，我们作为技术 leader，要做的就是尽量把这些问题控制在一个相对能够忍受的范围内。

其实，不论是本地沟通，还是跨地域沟通，对于一个团队来讲，最重要的事情就是成员是否能知道团队的目标在哪里，以及是以什么样的路线去达成目标。另外，在想着目标前进的过程中，已经走到哪里，未来还将走向哪里，这些对于整个团队来讲都是非常重要的信息，也许不是所有的同学都关注，但我相信，优秀的同学一定会主动关心这些信息。

因此，作为管理者，我们就需要在团队层面做一些事情，安排一些场合，比如季度沟通会，来对整个团队做阶段性的复盘，并对阶段性目标进行重新锚定。如果跟之前设定的目标有差异，就要说明为什么会产生偏差，以及在这样的偏差下，我们要做哪些调整，下个季度还要做什么事，等等。

这些信息，我们都会在全体范围内做集体性的沟通，确保在大的战略和战术执行层面，大家获得的信息都在一个基本面上。但坦白的说，这件事是其实是做给优秀的人、愿意主动关心团队动向的人看的。

极客时间：最后，对于有志于成为 CTO 的技术人，您有哪些建议？
王平：如果想往 CTO 这个方向发展，首先不要把自己定义成一个单纯的技术型人员，因为当你往更大的事业和格局去走时，你要把自己技术人员的身份先放一放，要更多的考虑业务，考虑自己如何把技术和业务结合起来，推动公司业务往前走。

公司之所以是公司，它有它的商业模式和生存之道，这时，如果你的目标不能和公司目标很好的结合起来，就很难成为公司发展中的关键人物。所以，首先要做的就是把自己技术人的身份先放一放，稍微淡化一下。

第二点是管理，很多技术人的单兵作战能力很强，有时难免会觉得别人的技术都不如自己，跟其他人组成小团队做项目，效率还不如自己一个人上来得快。但如果你的职业目标 CTO，那就一定要从单兵作战的思路演变成团队作战的思路。在这种情况下，管理就是一件非常重要的事情，你需要想办法走出舒适区，想办法做好管理相关的工作，比如如何制定整个团队的目标，如何拆解目标，如何带领团队一步一步实现目标等等。同时，管理并不像技术有定式，需要你在这个过程中不断实践、反思、复盘，直至找到最适合自己的管理实践。

最后，也是最重要的一点是，就是要选择一个适合自己的、能长久去做的事业方向，具体来说，可以考虑以下几个因素：一，选择的方向是否具备社会价值，是否能对人们的生活产生深远的影响；二，选择的方向是否具备战略纵深，不是 3~5 年就到头的，而是可以做 5~10 年，甚至更长远的做下去的；三，选择自己喜欢的事情，这里的喜欢不是单纯的爱好，而是你相信这件事，哪怕到最后失败你都坚信这事是对的，你依旧有热情沉浸其中去享受。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

大咖对话 | 王鹏云：技术人创业该如何选择合伙人？

你好！
本周作客大咖对话的嘉宾是蓝创中心总经理，蓝标产品技术委员会主席王鹏云，他也是前多盟联合创始人，前蓝标移动广告集团 CTO，曾任百度高级工程师、魔时网 CTO、139 移动互联研发总监，在营销领域深耕十多年，目前专注于技术创业孵化，今天我们的话题是技术人创业过程中容易踩到的坑，希望能给你带来一些借鉴意义。

极客时间：根据您的观察，技术人创业容易踩哪些坑，需要注意哪些问题？
王鹏云：这些年，我自己有过几次创业经历，也见过很多的技术创业者，包括联合创始人、CTO 以及技术人自己做 CEO 等，总结技术人创业陷入的主要误区有三个。

一是考虑问题以技术为先，因为他最熟悉的是技术，而且很多技术创业者有极强的技术自信，他在很多相对成功的大公司待过，自己的那套技术已经在应用中取得了较大成功，所以出来创业就会有极强的技术自信，容易以技术为先考虑问题。

不能说技术优先是绝对错误的，如果企业是纯粹的技术领先驱动型公司，技术优先就没有问题，你拓展的是技术边界，比如 AI，在这个领域中，如果你公司的技术一马当先，这时以技术为先考虑问题是 OK 的。我之所以称技术优先为误区，是因为如今绝大部分创业公司都不是真正以技术为核心驱动，多数情况下你的核心技术门槛没有那么高，你能做，很多公司也能做。你公司的核心竞争力不是来自于技术独到性或技术领先性，这时再用技术为先的思路主导，往往会将更核心的目标忘掉。

二是过度技术化，所谓“过度技术化”是在推进业务的过程中，可能很多工作是可以由人工完成的，比如用 Excel 来统计分析，而技术人往往看不过去，会说“这玩意怎么还那么落后呢”，想将这种工作方式技术化。我认为，技术化应该有一个节点选择，即在合适的时间、合适的环境和条件下做技术化，而不是将所有问题都用技术方式解决，这是很大的误区。

这个误区容易导致的问题是什么呢？首先是过度的技术投入，其次，浪费了很多业务抢占市场机会的时间。我们知道，要用技术化的方式来实现某个功能，并且相对成型，需要大量的技术投入、时间投入和精力投入。一方面技术投入成本增加，另一方面，时间、精力也是一种耗损。可能人工方式看起来比较土，但相对来说却能够较快的完成目标。因此，对于技术化的选择还需要考虑时机，过早使用太技术化的方式不是一个明智的选择。

三是过度理性，在创业过程中，理性是很重要的，但技术人往往容易过度理性，做任何判断与决策，都希望有数据支撑，这不可能，因为创业本来就是九死一生，甚至 99% 失败，只有 1% 是成功的。其中有非常多难以用理性方式去把握的东西，甚至有很多运气的成分、感性的成分。很多时候，创业需要狂热、突围、狂奔。另外，创业很多时候都需要我们对商业、对行业有洞察和直觉，而这需要有嗅觉和敏锐性，不能所有决定都依赖于数据，有些数据可能是脏数据、假数据，这时难道我们不做决策了？不往前走了吗？你拍着脑袋也得往前走。过度理性会让自己变得裹足不前，甚至被一些错误数据引导到错误的结论中。

那我们应该怎么尽量避免这些误区呢，我认为主要有两点，首先，从主观上讲，一定要压制自己的技术人思维，意识到问题的存在，即使你的技术确实很强，也一定要压制自己的技术冲动，理解其他方式的合理性，理性地看待问题。

其次，开阔眼界，了解技术之外的东西，比如产品、销售、行业现状与未来以及企业之间的协同模式，等等。虽然我们了解的这些知识不见得能在工作中“学以致用”，但这有利于我们能以更全面的视角思考问题。另外，当你了解了社会与行业，再来反推公司的商业价值，以及如何让商业价值变现，就相当于了解全局，再跳回来审视局部，这样能避免踩更多的坑。

其实，上面提到的几个误区，我自己以前多多少少都经历过，因此有一些切身体会。除了技术方面的坑，还可能有合伙人的坑，商业合作的坑，视角的坑，业务拓展的坑，变现的坑，投资的坑，等等，坑非常多。

我想说的是，选择创业，就不是在别人搭好的平台和既定的规则、清晰的约束下去做事情，你只要做好自己边界范围内的事，看准边界在哪里，完成既定目标就好，或有所突破更好。创业真的是一件无边无际的事情，最底层的约束其实就是法律，除法律外，在没有约束的情况下做事，就非常容易迷失方向，跌跌撞撞踩很多坑。虽然踩坑无法避免，但我们可以尽量少踩，因此就需要我们开阔眼界，至少可以用一些常识让自己少踩坑。虽没有经历过，但大体上有直觉，知道某件事的运行规律，这样，当你做一些具体的决策和判断时，就可以尽量遵循规律，不符合规律的就绕着它走，不是所有事情都要不撞南墙不回头，脑袋没那么硬，撞几下可能就不行了。

极客时间：技术人创业，在合伙人的选择上，您认为有哪些权衡和考虑点？一个优秀的创业团队又应该具备哪些特质呢？
王鹏云：我一直认为合伙创业是这个世界上特别难的一件事，比结婚还难，因为这个团队所经历的事情要比家庭复杂得多，正如阿里巴巴的做大做强之路，中间经历了多少时间和磨难，这绝不是一个家庭能够比拟的。合伙的问题也非常复杂，合伙人内斗其实是很多公司死亡的主要原因，内斗有各种各样的原因，各种各样的情形，我甚至见过最严重的情况已经到了团队斗的唯一目的是把对方送到局子里去。

至于创业合伙要注意什么？我当然可以列出很多要点，但在实操过程中，你会发现依旧有很多问题是这些要点覆盖的，不过总的来说，选择合伙人可以衡量五个方面。

首先，最重要的是要有契约精神，承诺就要尽最大努力兑现，并对达成一致的决定不反悔。吃亏也认。只有这样，大家才能形成一个比较良好的协作模式，否则个人具有再强的能力、再高远的洞察、再丰厚的资源、再宽广的人脉都难以预料你的合伙人哪天与你反目相视。有契约精神之后，多方可依赖，再多延伸一点就是志同道合，有句话说“志不同不相为谋”，目标的差异可能导致很多问题的出现，只有目标一致，才能同心同力。

第二，有主有从，创业团队共同商量决策没问题，但不能因为哥们义气齐头并进，一定要有一把手，因为大多“商量着办事”的企业发展到最后，瓶颈都非常明显。因此，不管决策人身上有这样那样的缺点，但他是你们最初共同选定、认可的人，那就遵照契约精神，在遇到各种分歧时，该妥协妥协，该配合配合，最后达成一致继续往前走。

第三，能力互补，这点也很关键，有的初创团队几个人都是技术，或几个人都是商务，这样的团队短板非常明显，并且弥补短板时不得不用一些你完全没有把握的人来做，风险很大，因此，团队合伙人最好能力不同，分布于技术、产品、商务、市场等几个方向，能够有所互补，比如，在视角方面，大家的关注点就不同，有些人比较有远见，有些人可能更关注落地。

第四，合伙人数最好是奇数，三个是相对比较好的数字，人太多，达成一致的困难更大，人太少又容易缺乏足够的视角。如果只有一个人，那你的短板就是公司最大的短版，没有核心的伙伴来帮你补齐你所欠缺的能力，因此三个人可能是最好的一种合伙团队模式。

第五，合伙人人选最好是前同事，从各种合伙人的选择来看，有亲人、朋友、前同事、陌生人等，在我看来，前同事可能是一个较好的选择。前同事好在哪呢？一是对目标的理解更容易达成一致，彼此对事情的理解相对有认同感，因为曾经共同做过一些事，三观和认知可能更贴近；二是与前同事之间有更好的协同基础，也了解对方的能力、短板、做事风格等，这点也是陌生人合伙的不足；三是能够撕破脸皮，这点很重要也容易被忽略，朋友、兄弟创业最大的问题就是容易在出现问题时撕不下脸，觉得争吵会伤害彼此的感情与关心，结果导致负面情绪积少成多，一旦爆发就可能是不共戴天的仇人。而同事之间互相争辩讨论问题已经是一种协作方式，大家成天吵来吵去的，没有关系，万一争不成，彼此以前也不是兄弟，即使以后不合伙了，也不会夹杂那么多感情去处理问题。当然这不能一概而论，但以我看了那么多以及结合自己的经验来讲，选择与前同事共同创业会更加稳定。

至于创业团队，在我见过的创业团队中，其实不睦的情况多于和睦的，但能走下来的团队有三个共同点，首先是具有契约精神，之前也提到过这一点，也许有个别和睦的情况是依赖于兄弟之间的信任，但不论如何，承诺过就努力兑现，基于契约精神才能有更多理解与支持。我看到很多初创团队，之所以一路走来，不离不弃，就是因为困难时共赴难关，才坚守住这个合伙团队。

其次是能够互相理解，即使你不同意他的做法，但你理解他做事的合理性。比如你是技术，从技术视角看可能不认同销售的决定或方法，这只是因为你没有真正做过销售，不理解其中的难处，但是你理解他做这样决定的合理性。因为你相信，他有契约精神，做那件事情一定不是为了把其余几个人都坑了，谋他一己私利，而是为了大家的共同目标，为了集体利益而为。

除了契约精神和互相理解外，还有一点是良好的默契，默契与契约精神有差别，默契更多是私下彼此信任，产生了工作中达成一致的更多可能，如果合伙人私交较浅，则更多趋向于遵守契约精神，无论是哪一类，这样的团队都会走的比较稳。

大咖对话 | 王鹏云：管理方式的差异是为了更好地实现企业商业价值

你好！
本周作客大咖对话的嘉宾是蓝创中心总经理，蓝标产品技术委员会主席王鹏云，他也是前多盟联合创始人，前蓝标移动广告集团 CTO，曾任百度高级工程师、魔时网 CTO、139 移动互联研发总监，在营销领域深耕十多年，同时拥有多年技术管理经验。今天我们和他聊了聊技术管理方法与技术人创业如何把握商业方向这两个话题，若你有不同观点，欢迎在留言区进行讨论。

极客时间：您能简单介绍一下您自己和您目前所负责的工作方向吗？
王鹏云：我是产品和技术出身，2004 年硕士毕业后就加入百度，算是百度比较早期的成员，2007 年离开百度开始创业，陆续有过几次不同领域的创业经历，包括社交网络、移动相关的社群、工具等。2010 年创立多盟，后来发展成国内比较大的几个移动广告平台之一，我们在 2015 年被蓝色光标收购，此后我一直在蓝色光标工作。2017 年年底我把多盟的工作陆续交给原来的团队，投入全部精力创立了现在的蓝色光标技术创新孵化中心，重点关注大营销领域的创新创业，如广告、社会化传播、公关等等。

极客时间：您觉得在技术管理方法上，互联网公司与蓝色光标这样偏传统的企业有何不同，能否分享下您的感悟？
王鹏云：蓝色光标代表具有两个特质的传统公司，一是规模较大，蓝标目前有五六千员工，二是工作比较个性化，它不是基于一个固有的平台，比如我们认为淘宝是一个平台，上面商家数量虽然很多，但他们是基于一种共同的工作模式，而蓝标是以大客户的营销服务为主，主要根据客户需求和客户差异去安排工作，因此每个项目组或每个产品线的工作都差异很大，管理工作内容的个性化程度也非常高，灵活性非常高。

其实，所谓的传统企业与互联网企业的技术管理方式差异，我认为主要是依赖不同，互联网公司更多依赖于平台、技术等，而蓝标这样的传统公司更依赖个人及团队的能力和智慧，其中个人素质非常关键，因此对人才的依赖性会比较强。

另外，蓝标没有 CTO。它的业务当然也会涉及产品与技术，但它不是基于产品与技术来构建团队，而是基于服务价值，这就是很大的区别。可能很多公司的模式是，我有一款产品，然后基于这款产品，进行研发、运营、推广、商务合作等各方面工作，而蓝标是基于客户，给客户营销服务，其中可能需要产品支持，但并不是以产品为核心。

来蓝标之前，我一直在互联网公司工作，工作模式都还比较相近，来蓝标之后，切身感到很多不同的工作方式，以及组织管理架构的不同，我还没有去过更传统的公司，比如传统制造企业，肯定又会有很多的不一样。从这个角度来讲，其实最终所谓的这些差异，都是为了服务于你所要实现的商业价值，为了推进商业价值的实现，每个公司会采取不同的组织架构与形态。比如蓝标会以业务和客户价值为先导，反推我需要什么样的技术工具，需要什么样的数据来支撑业务运行。因此，蓝标的成员构成多数是业务与客户服务相关人员，技术和产品是相对较小的群体，主要以支撑业务和客户服务为工作重心。而互联网公司就会以产品和技术为主。

极客时间：您拥有多年的 CTO 经历，并且在负责技术创新孵化中心的过程中，接触过很多 CTO，您觉得一个优秀的 CTO 应该是怎样的？
王鹏云：这个问题应该很多人都回答过，也提到了 CTO 应该具备的几大特质，但从我自己多年的经历以及实操经验来看，没有一个 CTO 能够完备的做到这些点，我觉得没有最标准的 CTO 所应该具备的特质要求，只有合适的 CTO。所谓的“合适”，就是如何用产品、技术、平台、工具等作为支撑，帮助企业的商业价值在最好的时间和场景下落地。

企业有各种形态，包括互联网（产品、工具、游戏、平台）、传统广告业、传统制造业、传统生产企业，等等，每个企业对 CTO 的要求都不太一样，甚至有些企业根本没有 CTO。之前有个蛮火的讨论是“CTO 该不该写代码”，在我看来不能单看这个问题的是与否，我们需要考虑 CTO 的工作中需不需要他写代码。比如 CTO 负责的是公司最核心的技术驱动，那他写代码是必须的，他必须带领技术团队完成这项使命，但如果在相对成熟、比较传统的业务中，CTO 需要做的就是优化工具，支撑业务，并审时度势这个业务现阶段需要什么样的产品和技术，然后设计最合适的支撑体系，而不是写代码、做系统架构等，这些交给技术总监来做就足够了。

因此，我认为 CTO 不要给自己套太多的框，比如“我好久没写代码了，技术是不是退步了，心里好慌，是不是应该多分配点精力在写代码上”等等，如果你所在的公司、所处的位置不需要你写代码，而你却将精力纠结于这件事上，反而可能会落下更重要的事情。

极客时间：技术人创业，该如何准确地把握商业发展趋势？
王鹏云：创业的核心一定是实现商业价值，并达成双向收益，你给用户贡献你的价值，同时你也能把钱收回来，这两项缺一不可。原因很简单，只收钱，不提供价值就是骗子公司，只贡献价值收不回钱，这样的公司难以维持。一个可持续发展的公司是一定是双向收益的，在此过程中，最主要的是关注大势、理解大势，然后顺势而为。

有些大势是显性的，有些是隐性的，比如乔布斯发明苹果是不是大势？我认为是，不过很多人觉得是乔布斯创造了一个大势，但在我看来，智能手机在当时是隐性的大势，因为当时的市场满足不了用户对于智能手机的需求，但需求已经是真实存在的。在苹果之前，已经有一些手机可供用户处理文档、存储音乐等，用户知道智能手机可以做这么多事情，他们的需求已经被唤醒，呼之欲出了，这时乔布斯做了苹果，满足了这个需求，所以大势一下爆发。

顺势而为很重要，而如何理解大势并不是一个可以快速入门的知识，它需要我们持续的关注与思考理解，并融合与洞察这个行业的运行与变化，以及了解社会中各阶层、各领域的人是如何思考，如何行事的，你了解的信息越多，对宏观大势的理解就越准确、越深刻，之后再做创业方向的选择，就会更完备。

另外，我建议在当前环境下，创业不要想太多，不要再去想太多颠覆平台的事，而是多想想怎么利用平台，在平台上做好事。都说现在是互联网下半场，但下半场不代表没有机会了，而是意味着在一些成熟的领域，大平台已经形成，此时创业颠覆大平台的可能性越来越小，但基于大平台延伸到别的领域做事情的机会并不少，比如产业互联网，基于原来的平台去改造产业和升级产业。这个市场盘子并不小，动辄都是千亿万亿级别，善于利用资源能帮助我们走的更远。至于具体的创业方向的选择，每个领域都不同，要结合我们自身的特点与能力、结合行业机会与自己拥有的资源去做选择。

大咖对话 | 王龙：利用 C 端连接 B 端实现产业互联网是下半场的重中之重

你好！

本周大咖对话的嘉宾是腾讯云副总裁王龙，具有多年中、德、美三国工作经验，曾就职于 eBay、西门子、VMware、猎豹移动等跨国公司，现在在腾讯云内部负责大数据和 AI 相关产品和服务。今天，他跟我们聊了云未来的发展趋势、开发者如何更好地使用云服务等话题。

极客时间：目前，云发展的现状如何？它未来发展的难点和趋势是什么？

王龙：云，在国内外已经成为软件开发者的首选服务，几个云厂商的财报和分析公司的报告也显示，包括 IaaS 和 PaaS 在内的云计算市场依然以超过 40% 的速度在增长。未来数年内，世界范围内整个基础设施市场的 80% 以上将由云来提供。

纵观历史，在云计算发展的这些年里，不管云上做了多少产品和服务，其实都离不开云最本质的价值体系：自服务、高弹性、按需提供、免运维，这些特性也让云服务天然成为开发者和创业者的最佳合作伙伴。

云的发展趋势和云提供的服务，一定是随着行业和技术趋势以及开发者需求的变化而变化。开发者除了利用平台和技术工具提高工作效率之外，还需要更多的启发创新、验证产品、验证商业模式的机会。腾讯云也希望能够在这些方面更全面地帮助开发者。

我们都知道软件应用架构一般都分为好几层，与之对应的云服务也大致分为三层：IaaS，PaaS 和 SaaS。过去十几年，每一层的云服务都在持续地进化，而这些进化大都是由行业和应用的发展推动的。例如移动互联网的大爆发，就推动了 DevOps、容器化、云原生服务的快速发展。

未来几年，如同几位互联网领袖所说的，互联网即将进入下半场——产业互联网。产业互联网是企业信息化、数字化、智能化转型的必然趋势。这一趋势又与各种层面的新技术遥相呼应，相互促进，这既包括 5G、IoT 这样的基础设施技术，也包括容器、无服务计算、CD／CI／DevOps 这样的平台技术，还包括微信小程序这样新的应用场景，更包括大数据、人工智能这一纵贯各个层次的核心技术能力。

腾讯在成立云与智慧产业事业群的时候就已经看到，在泛互联网领域人口红利已经达到了饱和的时候，利用 C 端连接 B 端实现产业互联网是互联网下半场的重中之重。线上线下连接需求的增加，会使得大量的新技术开始涌现，如之前提到的 5G、IoT、AI、大数据等等，都将持续处于蓬勃发展的阶段。

此时，开发者会面临各种技术选型，比如应该选用什么样的平台？应该选用什么样的工具？对云来说也是如此，当面临不断更新迭代的技术能力、算法模型和各行各业的新需求，要真正实现降本增效、快速创新，云需要提供哪些功能？需要解决哪些问题？ 这些都需要云厂商和开发者密切沟通和协作。

而从开发者的角度来说，需要充分了解行业的新趋势、以及支持这些新趋势的新技术，才能更好的开发新应用，并开发更好的、适应时代需求的新应用。腾讯云的目标，就是想要帮助开发者更快、更有效的实现这一目标。

极客时间：腾讯云目前面临的挑战是什么？差异化的打法在哪里？

王龙：就差异化而言，腾讯云的能力来自于整个腾讯自身的技术积累，比如在微信小程序开发的能力、视频和直播相关的能力、即时通讯相关的能力、大数据分析、机器学习和深度学习平台等等，这些都是腾讯云二十年积累下来的差异化能力。

就挑战而言，在腾讯云内部更被认为是机遇。在这一新技术和新应用层出不穷的时代，我们希望能为开发者提供更好的服务，让开发者更高效地创新，更有力地帮助各行各业实现信息化、数字化、智能化转型。 为了实现这一个目标，一方面我们紧密结合产业，了解产业和技术发展的新趋势，另一方面，我们也需要和开发者更多地沟通和交流，更好的链接开发者和各个产业。

比如，当开发者都在讨论微信小程序时，我们就提供了小程序开发平台服务，包括云存储、云数据库、云函数、语音助手、图像识别等一系列能够帮助开发更好、更有创新性的微信小程序。

当大数据和人工智能成为风口的时候，我们就迅速地提供了包括 EMR、ES、机器学习和深度学习平台等服务。同时为了适应人工智能的快速发展，我们尽可能的兼容各种框架，提供更多的算法和模型，让每个行业的开发者都能够找到自己需要的服务，更快速地落地应用，帮助他们的客户。

在前不久，企业软件（2B）服务在腾讯集团内部的战略地位被拔高，第三季度的财报也首次展示了腾讯云的规模和高速增长趋势。这反应了腾讯对于这一业务方向持续投入的决心，也显示了腾讯云在过去数年得到了行业客户、开发者、用户以及公司决策层的认可。 我们相信，腾讯云有决心、也有能力为行业、为开发者提供最可靠的各种云服务，也能够成为开发者源源不断的创新源泉。

极客时间：目前整体互联网市场环境不太乐观，对开发者和云发展最大的影响是什么？

王龙：整体软件市场环境不乐观，投融资环境冷却下来，加上一些国际形势的影响，行业里普遍面临融资困难。但其实对于开发者和云厂商来说，反而是一个密切合作的重要推动力。

之前投融资环境比较好，充斥资本热情的时候，会让大家忘记商业模式的本质，会出现很多 to VC（风险投资）的企业。现在这种情况会促使大家更谨慎地审视产品的价值，更小心的验证自己的商业模式。而最早云的诞生原因就是为了帮助开发者和合作伙伴降本增效、快速创新，这些能力都是开发者在当前环境中最需要的。

我觉得每经历一轮这样的低谷，云和开发者的能力都会得到更好地锻炼，也都会为下一轮的增长打下更好的基础。

极客时间：在这种环境下，作为一名技术管理者应当如何帮助内部团队渡过这段时期？

王龙：我在中国、德国和美国做管理有十几年的时间，经历过几个经济周期。不管大环境如何，我认为总的管理方法论是不变的。首先，要目标清晰。要给团队制定短、中、长期的战略目标和规划，这个规划一定要明确和可衡量。其次，要帮助团队里的各层级负责人，驱动他们把目标分解给下一级团队能理解的小目标来执行。最后，要非常关注团队成长，要帮助成员获得更多的知识，获得更宽广的视野。只有成员不断成长，团队才能不断成长。

在跨部门的协调方面，我个人有一些总结。其实不管是跨部门还是和合作伙伴、客户的协调，最重要的一点是要具备同理心。通过同理心来寻找共同共目标、共同利益点。具体来说，就是要多站在对方的立场上考虑问题，只有这样，双方的合作才能变得更加顺畅。当然，最好在具体执行层面就把两边团队乃至个人的小目标对齐。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

大咖对话 | 童剑：用合伙人管理结构打造完美团队

你好！

本周作客“大咖对话”的嘉宾是童剑，国内云计算领域知名专家和早期实践者。现担任白山云科技联合创始人兼 CTO，负责公司技术产品战略的实施、技术人才培养和研发管理工作，助力白山云链布局。童剑毕业于北京大学光华管理学院获 MBA 学位。1999 年至 2016 年初就职于新浪，离职时任新浪研发中心总经理，积累了丰富的互联网技术及云计算、大数据等行业经验。

极客时间：能简单介绍一下您的工作经历么？

童剑：我的工作经历比较简单，加入白山之前一直在新浪工作了 16 年。很多人会通过跳槽来换岗位、换环境，我则是通过在公司内部的努力，争取自己感兴趣的工作机会。

刚加入新浪那几年，我做的是基础的技术开发，因为对新事物和新技术的强烈求知欲，工作之外很多时候都是在自己学习、研究新技术。后面转去做安全，在这个过程中看到很多公司技术体系与管理上的不足，也意识到安全管理一定程度是治标不治本的。安全最大的问题，是和不完善的技术体系的斗争。

2005 年公司也意识到基础技术平台的重要性，我带了一个小团队去研发一系列统一的技术平台，包括：动态应用平台、数据库平台、存储平台、CDN 平台、虚拟化平台等，并在公司内推广使用，把公司的技术体系统一化、标准化，解决原本各个业务、各团队技术孤岛的问题。

2009 年时新浪所有的业务已经全部运行在统一的技术平台上，使新浪率先成为业内技术平台统一化的公司。这个平台持续发展超过 10 年，并在后来有力支撑了微博从诞生到爆发式发展。

2010 年我们基于之前已有的技术积累，推出了国内最早的公有云计算平台 SAE（SinaAppEngine），并陆续推出了新浪微盘、云存储应用、新浪云等产品。

经过那几年的锻炼，我的技术能力得到了很大的提升，也知道怎样带领一个团队，怎样把自己业务推广出去，怎样跟内部“客户”处好关系、做好服务。当时最深刻的一个感受就是要有服务意识。那几年是各方面能力飞速提升的一个阶段。

职业发展中，我也经历了是否要转型纯管理岗位的抉择，也承担了更多不同业务的研发管理历练，以及晋升技术总监、研发中心总经理这些岗位的变化。对我来说，只要能够做事，不断有新的挑战，就有留下来的理由。在这个过程中，我也从一名技术人员，成长为了一名合格的技术管理者。

极客时间：离开新浪后，为什么会选择加入白山呢？

童剑：离开新浪后，我就以联合创始人兼 CTO 的身份加入了白山，到现在已经两年多，当时吸引我的一个很大的原因就是创始团队“合伙人管理结构”的理念。

大部分初创公司创始人都不会太多，一般是 3、4 个人，但白山创立之初就组建了一个 13 人规模的合伙人团队，其理念不是打造巨轮而是编成联合舰队，每个合伙人都是舰船的掌舵人，大家一起带着业务、带着公司往前发展，效果可能比 CEO 一个人指挥的巨轮更好。

我跟我们 CEO 开始接触的时候，公司已经有 10 位合伙人加入了，而且每个人都非常资深，彼此之间也都长期合作过。最后组成的 13 人团队，在我看来也是接近于完美的团队，每个人都能充分发挥自己的长处，而在不了解的领域，也能有其他成员帮忙补齐。

从个人发展角度来说，我们应该不断强化自己的优势，提升自己的长板，打造自己的核心竞争力；但从团队发展的角度出发，我们应该尽量找到合适的人，与自己互补的人，让团队没有短板。

比方说我之前的背景主要是做产品和技术，而创始人团队的其他人在商务、市场、CDN 等领域非常优秀，这样我跟团队的互补性就比较强，彼此都能发挥自己最大的力量。

另外，因为每个合伙人都非常资深，平均有着 17 年的从业时间，不论是经验还是资源都很丰富，所以，他们能更快的为公司找到更合适的人才，也能把相关领域的经验、方法带给大家，保证团队在问题和业务的探讨上有开阔的视野。

比如我们有两位在美国工作很多年的合伙人，他们非常了解美国的商业氛围和的文化，拥有对于海外业务和客户的经验，就对我们开拓海外市场非常有帮助。

再比如 CFO，大多数创业公司到 C 轮、D 轮才有专职的 CFO，不过我们一开始就有 CFO 加入，而且非常资深，他在白山之前有过 3 个上市公司 CFO 的经历。因此，我们在财务运作上做得非常好，能够做到以最低的投入实现业务上快速增长，同时，我们对于资金的使用效率也是业界顶尖的。

这就是我们合伙人机制，每个人都很资深，我们就像在大海里往前推进的联合舰队一样，每个掌舵人都能够很好的去把握方向。

极客时间：从大公司技术高管到创业公司 CTO，遇到的最大挑战是什么？

童剑：挑战还是挺多的，最主要的还是新业务的建立和突围。我刚加入的时候，白山在做 CDN 业务，并决定后续要开展云存储和云聚合的业务。

第一个挑战是面向云后市场的云聚合产品怎么做。国内市场还没有云聚合产品的概念，云后市场应该如何布局，都是我们当时要思考的。

根据 Gartner 报告，我们将云后市场定义为 6 大细分市场，包括：云安全、iPaaS 云集成、API 管理、云中介、多云管理、iTOM 云运维管理。在结合了业务方向、团队特点、国内云市场情况后，我们最终确定下来通过云聚合产品布局云安全、iPaaS 云集成、API 管理三大细分市场，采用战略投资的方式进入云中介、多云管理、iTOM 云运维管理市场。

还有一个挑战是，在公司快速成长的过程中，技术怎样才能够服务好客户。我们的做法是关注技术体系的完善，同时不断改进技术管理思路，让技术管理的方法、工具被更多的核心团队成员接受。这样，在公司快速发展，客户越来越多的情况下，我们也能跟上步伐，不断提升服务质量。

值得骄傲的是，我们团队在这方面非常给力，团队的学习能力非常强。工作中提出的问题，大家给出的建议，团队很快就能吸收、消化并落地。

目前，我们技术管理的体系已经比较完善，虽然后面还有很长的路要走，但至少这个阶段所做的事情已经足以支撑目前的需求。而随着公司未来的发展，我们还会逐渐的迭代、改进，让其符合每个阶段的目标需求。

极客时间：能分享一下白山在服务架构方面的创新吗？

童剑：关于服务创新，我们说得最多的是“乐高式松耦合架构”，这是我们的一个技术理念，希望所有的技术都是松耦合架构的。当一个客户需求提过来时，我们要对这个客户的需求做开发定制，在这个架构下，当我把这个功能模块开发出来之后，直接接入到架构里就能运行了，像搭积木一般灵活自如。

在很多传统的软件开发模式里，一个新的需求提过来之后，开发人员需要在一个很庞大的代码库里编码修改，才能完成功能的交付。这样做的复杂度高、灵活度低，同时，因为代码太复杂，有些功能还不好添加，就算想办法加了，之后也会产生很多麻烦的问题。

而通过“乐高式松耦合”的架构，就能极大避免这些情况，同时也让我们的开发效率和实施安全性有了更大的提升。

过去，软件行业对客户的需求都是以月为单位进行实施和交付，而现在我们能够做到以周、甚至以天为单位进行快速开发、快速交付，这也是我们作为一家新的创业公司更有优势的地方。

我们可以按照自己心目中最理想的方式去构建结构体系，保证我们在产品开发和交付上快速迭代、小步快跑，开发效率得到极大提升，开发模式也更加灵活。

* 作者简介*

童剑，白山联合创始人兼首席技术官，TGO 鲲鹏会北京分会董事会成员 & 学习委员。前新浪研发中心总经理，2016 年 5 月加盟白山，迅速搭建和完善各产品线技术梯队，构筑云链产品技术体系，带领团队推出云存储、云聚合产品，助力白山抢先布局云后市场。

大咖对话 | 管理者是首席铲屎官？

你好！

本周作客“大咖对话”的嘉宾是陈皓。网名左耳朵耗子，独立运营技术博客酷壳 CoolShell，也是极客时间《左耳听风》专栏的作者。他拥有 20 年软件开发及相关工作经验，在团队管理、项目管理，以及程序员个人成长等方面拥有自己独特的见解和方法。今天，我们和他探讨了该如何修炼成优秀的技术管理者。

极客时间：在您看来，如何才能打造高效的研发团队呢？

陈皓：管理基本上是三个事，管人、管事和自我管理。

管人的意思就是管团队，除了要招聘到很好很强的人才，组建一个很强的团队，并不断提高团队的实力之外，还需要做的是激发团队的热情，培养他们的主人翁精神，这样才能够更高效地开发日益复杂的软件产品、解决日益困难的技术问题。因此，管理者需要在各个方面都坚持比较高的标准，并不断得提高团队的能力标准。

管事的意思是要找准方向，如果你的方向是错的，即使你有一个好的团队，也是没法高效起来的。另外，找到正确的方向之后，还要落地执行，而在执行过程中，会有各种各样的问题需要你去解决，包括对第三方的依赖、条件受限（时间不够、人力不足）、以及各种没有考虑到的项目风险。有时，一个小问题就可能会影响到整个项目的进度。所以，如何把复杂的逻辑简化掉（简化而不是简陋），如何把复杂的问题拆解成小问题并各个击破，如何在受限的条件下抓重点，如何说服别人统一大家的目标……这些都是管理者需要负责的。

自我管理的意思是说管理者自身的素质和自我的成长，通常来说，管理者就是这个团队的天花板，如果管理者自己不成长，那么团队就会受限，所以，管理者要修炼自己硬技能和软技能等各方面的能力，包括个人魅力、沟通能力等，从而提高自己的影响力。所谓影响力并不在于职位高低，而是当别人有困难的时候，是否会想到向你寻求建议或支持。一个 leader 的关键素养就是要能服众，能获得团队和客户的信任，之后，自然会赢得老板的信任。

如果这三个方向能做好，那一定能打造出一个非常好的研发团队。

极客时间：一位优秀的技术管理者必备的能力和素质有哪些？

陈皓：好的管理者一定要具备两个素质，一是明白自己的定位，二是能激励团队。

先来说第一个素质，自我定位。 要明白作为管理者，是来帮助团队，而不是阻碍他们前进、阻碍他们创新的。因此，如果你懂，你就一起来干，如果你不懂，那就相信团队，放手让团队去做，千万别外行领导内行，这是非常不好的做法。

我一直戏称 leader 是首席铲屎官，团队在前进的过程中，一定会遇到很多阻碍，这时候就需要 leader 在前面把这些不好的东西都解决掉。

比如跨团队合作时，跟其他团队的沟通与协调；比如团队遇到不合理的流程时，leader 需要将其不断优化；比如遇到团队内影响士气的不和谐声音时，leader 就需要狠得下心去解决；比如面对客户、老板等压力时，leader 需要一肩承担等等。

当然，这里不是说就不能给团队压力了，而是说不能把没有经过过滤的负面的外部压力直接传递给团队。你给团队的压力，一定是你已经消化过的、跟团队整体成长相关的正面压力。

因此，管理者肯定是孤独的，哭得自己哭、压力得自己扛，但取得的成绩、获得的好处一定得交给整个团队。最糟糕的做法就是成绩是自己的，问题是团队的，这样一定会导致众叛亲离。

再来说第二个素质，能激励团队，也就是能驱动团队成员有主人翁精神、有 ownership。技术研发是知识密集型项目，不能沿用传统的“命令与控制”Command & Control 的管理方法。这种管理模式之下，大家多会觉得所做的事情与我无关，是你老板的事情。

激发主人翁精神的一个关键就是让团队成员有参与感，而要让他们获得参与感就需要赋予他们建议权甚至是决定权。同时，领导者需要往后退一步，把命令变成协作和引导。

所谓协作，就是我们彼此帮助，团队的事务和进度不是来自于老板的鞭打，而是来自团队成员间的相互协作，同时管理者还要兼顾到员工的兴趣点，你为他们实现理想，他们才会为你实现理想。

所谓引导，就是我不再以指令和控制的形式告诉你要做什么，而是通过给出一些问题、提供一些工具或方法让团队成员自己找到答案，管理者这时要做的不是一个奴隶主，而是一个教练或是一个老师，传道授业解惑。

这里的关键其实就是看管理者的心胸够不够大，能不能容忍员工犯错，错误是成长的关键，只有痛过，才会真正努力。另外，管理者还要多问问自己，你是更多地关注事情的结果，还是员工的价值与成长；你是更多地关注眼下的事情，还是长远的目标。

在协作和引导这两种方式的共同效益下，员工会有非常高的参与感和归属感。当然，当你需要去攻坚、去打硬仗的时候，还是需要 Command & Control，但这不应该成为常态，而是只在特殊情况下采取的特殊手段。

在具体执行中，一个比较好的方法就是变问答题为选择题。问答题就是员工会问这事怎么做，这个问题怎么解，而你告诉他该这么做，这样的模式下，员工永远成长不起来，团队也不会变强。

选择题就是引导员工，下次再说什么事，先拿出一二三个方案，列出每个方案的优缺点，并给出他们看好的方案，你再在其中做选择，这样就会逼着他们去想各种解决方案。同时，如果每次他们的选择跟你的相似，那么就表明他们已经锻炼出来了，可以自己做决定了，你也就可以放权给他们了。

给员工放权的多少是一个团队是否强大的表现。最差的管理是家长式的保姆式的管理。

极客时间：如何才能找到适合自己的管理风格呢？

陈皓：我之前讲了那么多，其实都只是我的管理经验，我的管理更偏人性化风格一点，但每个人的管理风格是不一样的，也没有哪一种定式的风格是最好的。

在管理的象限图中，第一象限是团队，第二象限是质量，第三象限是流程，第四象限是成本。

不同的管理风格会偏重不同的象限，而且一个管理者最多只能偏重其中的两项，而且还不能是处在对角线上的。因为对角线都是有冲突的，比如太注重流程，团队就会没有活力，或者关注质量，成本就难免会变高等。另外，相邻的两个象限是互补的，比如好的质量必须要好的团队和高效的流程来保证。

每个人的管理风格都是不一样的，而我的风格更偏重团队和质量这两点。大家也可以做一些测试来测自己的管理风格，比如当系统出现故障的时候，你会怎么办？是先惩罚人，还是先弥补流程，还是先总结错误。其中并没有哪个答案是标准答案，就看你选择什么，而你的选择会展示你的偏好。

最后，没有定式的管理方法，找到自己的管理风格是最重要的。

大咖对话 | 胡哲人：技术人创业要跨过的思维坎

你好！

本周作客大咖对话的嘉宾是流利说联合创始人兼 CTO 胡哲人，在创立流利说前，他曾任美国著名互联网大数据 AdTech 公司 Quantcast 资深软件工程师，负责多个核心产品功能的前后端开发，拥有丰富的大型软件和大数据分析系统的架构经验。今年 9 月，流利说在纽约证券交易所挂牌上市，被誉为“AI+ 教育”第一股。今天，我们和他聊了聊创业、管理相关的话题。

极客时间：能分享一下您当时为什么选择回国创业？

胡哲人：创业之前，我一直在湾区工作做程序员。选择做工程师，包括我最初选择计算机行业的初衷，都是希望能把一个产品从无做到有。正好在那个时间点遇到了志同道合的朋友，国内创业也正蓬勃兴起，就决定一起回国创业。

从我下决定到回到国内，前后不到一个月时间，真的是很快的一个决定，完完全全的“从心”，follow my heart。

现在回过头去看，还是蛮佩服那个时候的自己的，因为真正创业之后，才意识到这是一件多么困难的事情，一路走来处处都是挑战，需要全身心的投入。但可能正是因为我对创业的困难没有那么了解，当时才会那么快的做下决定。

当然，现在来看，这个决定是非常正确的，我非常享受这个把事情从 0 做到 1，再从 1 扩张到 100 的过程。在这个过程中，我克服了很多挑战，接触了很多之前没有接触过的人和事，看到了很多不一样的风景，对很多事也有了不一样的思考和感悟，这让我收获了非常大的成长。

极客时间：您提到有很多挑战，那您创业以来遇到的最大的挑战是什么？

胡哲人：一个比较大的挑战是，创业后，我逐渐地从工程师的角色转到更偏管理者的角色。老实讲，我之前并没有管理过这么大的团队，在这样一个角色转变的过程中，遇到了很多挑战。

其中之一就是思维上的转变，最最开始的时候，我其实对做管理有一点排斥或者说胆怯。因为之前一直在做技术，面对的是机器和代码，所有东西都由 0 和 1 构成，比较简单明了，而做管理的话，面对的是人，远比 0 和 1 要复杂，也担心自己是否能把管理做好。

当然在之后的实践过程中，我慢慢发现了自己在管理方面的一些特长和优势，也找到了技术团队管理的要点，形成了自己的管理风格。

极客时间：您能分享一下您的管理风格吗？

胡哲人：因为我之前在湾区的经历，我会希望我的风格能更接近湾区的管理方式。

作为管理者本身，我觉得非常重要的一点是，自己要做好榜样。在很多事情上，我对团队有怎样的要求，那我自己也要达到这样的要求，甚至做到更好，起到榜样作用。古语有言，知之非难，行之不易，你怎么做要比你怎么说重要得多。

而在具体的管理上，我不提倡 micromanagement，也就是微观管理，把管理做得特别细。我会在把公司目标和当前要做的事情跟团队传达清楚的情况下，授权给团队，给团队更多的自由度，让他们能自主的去思考、去执行。

另外，毕竟我管理的是技术团队，所以我相信代码可以解决很多问题。我们应该尽可能的去用代码治理，而不是靠人治。

比如，当我们遇到问题，或内部需要做一些事情的时候，我的第一反应就是，这件事是否能够用工具或机器等手段自动化的去解决，之后又是否能够自动化的发现类似问题并解决。现在，这也已经成为我们团队很多 leader 的第一反应。

我比较幸运的是，我的管理风格恰好跟公司当前在做的事情比较吻合——用技术手段解决英语学习问题，能在这样的环境里去推行实践这样的管理风格。

极客时间：在线教育行业的竞争十分激烈，流利说的竞争力是什么呢？

胡哲人：我们的做法跟很多在线教育产品不太一样，我们是真正用技术、用 AI 等手段解决教育环节中的问题。用人工智能技术为用户提供 AI 英语老师，然后基于机器学习、深度学习等技术，为用户提供个性化的学习课程，提高英语学习的效率。

这也跟团队基因有关，我们三个创始人都是互联网技术和产品出身，所以一开始就是从产品和技术的角度出发去打在线教育市场。这条路比较难，前期也需要更多的积累。

不过，在线教育跟其他互联网领域不太一样，它的先行者优势没有那么强，简单来说，这件事情你是不是第一个做，是不是第一个吃螃蟹的人没有那么关键。因为教育是一个非常重内容、重品质、重服务、重口碑的行业，快不是关键，走的方向对不对、走得稳不稳才是关键。

基于这个认知，我们发现，我们要从一个用户喜欢的产品跨越到一个成功的商业产品，就必须在内容上下功夫，打造自己的系统化课程。之前流利说上的内容都是比较碎片化，也没那么成体系的。

最开始我们想跟出版商合作，但不幸的是，他们的教材都太陈旧了，大部分都没有数字化，即使有些内容是数字化的，也只能在 PC 端上实现，很难满足移动端的用户需求。

我和我的创始人都是产品和技术出身，对教育没有那么了解，因此要下决定投入那么多成本和时间去做课程，一开始还有些挣扎。但最终，我们还是决定这件事情得自己来做，因为只有我们才最了解我们的用户，了解他们在移动端上想要得到什么样的体验。

于是，痛定思痛，我们开始深入了解教育，并投入大量的资源，引入教研相关的人才，然后教研、技术和产品三方一起，花了十八个月的时间，自主研发了一套符合移动端逻辑的英文原创教材，并将其数字化，将原本只存于书本上的内容通过原创插画、动画、语音等形式在移动端重构，也取得了非常好的反响。

另外，教育的好处在于，它的内容的生命周期很长，像现在非常火的短视频，一个短视频的生命周期就非常短，即使是电影或电视剧，它们的生命周期也没有想象中的那么长。

但教育类内容的生命周期非常长，比如我小时候学过新概念英语，到了现在依然有人在学，而这本教材已经诞生几十年了。从这个维度来看，我们投入重金打造系统课是非常值得的。

极客时间：关于技术创业，您有什么经验可以分享给我们的创业者？

胡哲人：很多技术创业者都想打造类似 Facebook、Instagram、WhatsApp 这样的轻资产型的产品，就是几十人的小团队，做出一个用户量庞大的超级产品。

但如果我们把视野收拢在国内，类似这样的机会已经不多了，特别是在垂直行业。我们在垂直行业创业，想用技术、用互联网思维推动行业改变的话，很多时候需要摒弃一些技术人的固有想法，更多的是需要深入去了解所处的行业，了解他们真正需要什么。

最开始的时候，我们也想把产品做得轻一些，能够打造一个轻资产型的公司。毕竟我的两个合伙人都是来自谷歌，而谷歌就是非常标杆的轻资产型的公司。但在垂直行业，这么做越来越困难的，以流利说为例，最终，我们还是选择投入大量资源打造属于自己的原创教材和课程。

技术人创业一定要跨过这个思维的坎，这是我们创业过程中最深的一个感悟。

大咖对话 | 袁店明：如何将打造自组织团队落诸实践

你好！

本周作客大咖对话的是 Dell EMC 敏捷与精益创业咨询师袁店明。曾任职于百度、阿尔卡特朗讯，辅导过多个产品线转型，包括商业产品、无线变现以及多个移动互联网产品的团队转型和组织转型。目前着重于项目管理、团队转型、组织转型、精益创业、欣赏式探询以及专业引导 (Facilitation) 的实践和应用。今天我们共同探讨了自驱动、自组织团队的相关话题。

极客时间：很多公司都希望打造自驱动的团队，那如何落诸实践，打造真正自驱动的团队呢？

袁店明：我认为自驱动的关键在于个人的 Motivation（动机），同时离不开组织管理对个人的影响，包括团队项目管理的透明性、团队的规则、透明的考评机制、团队中权力与职责的分布，等等。

个人的 Motivation 并不单单是指薪资福利，其实，一个人在拿到公司的 offer 时，他的薪资待遇、职业通道就已经确定了。因为每年加薪的范畴是固定的，是你能够想象到的，除此之外，根据公司制定的晋升机制，你的升职路径也是能想象到的。所以，升职加薪不是给个人带来 Motivation 的主要因素，我认为其主要因素有三点。

第一点是尊重与认可，因为人具有社会属性，每个人都希望得到认可，感受到荣誉感与归属感。第二点是个人能力的成长，而个人成长只靠自我驱动是不够的，还需要依靠团队的帮助，比如团队成员间的相互促进和知识的传递分享等。第三点是职业发展通道与个人兴趣的匹配度，也就是个人职业生涯是否符合他的个人兴趣，兴趣可以激发动力，这一点不难理解。

不知道你有没有发现，获得 Motivation 的这三点因素，其前后顺序是有关联的，先是获得认可，其次是个人能力的提升，在获得成长之后，才会更多的考虑个人职业生涯与个人兴趣的匹合度。

其实，相比自驱动，我更建议用自组织来说这个话题，内容可以更丰富。那如何打造自组织的团队呢，我认为有两个关键点：

1. 分散权力

比如 Scrum 中，有三个角色，分别是 PO（产品负责人）、Scrum Master 和 Team（开发团队），我觉得应该再加入一个重要角色，即 People Manager，这四个角色相互制约、相互促进。具体有哪些措施呢？

首先，People Manager 不应该参与团队的日常运作。如果团队要更好地实现自组织，People Manager 所做的事情非常多，比如招聘、培训、考核，一对一面谈等等。如果是一个几十人组织中的 People Manager，这些事情就已经够他 / 她忙的了。

其次，Scrum master 需要提醒团队成员，每个人的职责所在和权力范围，不要越界，同时需要引导团队如何更好的呈现项目进度。

在这方面，Scrum master 需要做两件事，即对外透明和对内透明。先说对外透明，比如 Scrum master 需要提醒产品负责人，不要干涉开发团队的进度，但产品负责人一定是会很关心项目进度的，这时，Scrum master 就需要引导团队及时向外部所有关系人输出信息，比如利用大白板公开工作任务及任务进度、用户故事的进度等，使产品负责人能够直观的看到项目迭代进度。

所以，作为 Scrum master，需要引导团队，准确地对外输出信息，并及时更新，这样一来，外部关系人才不会越权，干涉内部团队的项目进度。

再说对内透明，Scrum master 需要保证项目管理的透明性和真实性。只有项目管理真实、透明，才能在此基础上建立团队内部的信任，打造自组织团队。刚才讲到的对外的信息输出，是透明你的需求，也就是公开用户故事的状态，而对内透明，是为了保证任务的真实性和时效性。这里的真实性是任务要真实，时效性是指业务状态要及时更新。

2. 设定个人与团队的成长目标

一个自组织团队，必须要让团队不断地达成自己的成长目标，同时帮助团队成员成长。在这方面，就需要 Scrum master 去做许多工作，比如对于个人，就需要 Scrum master 在回顾会议上，组织每个人展望自己下个季度的目标，并依此制定自己的学习目标和成长目标。而对于团队，也需要 Scrum master 根据团队所面临挑战的不同，制定不同的项目计划与业务计划。总的来说，设定团队和个人的成长目标是 Scrum master 非常重要的一项职责。

为什么又谈个人成长，又提团队成长呢？因为团队由个人组成，每一个人都应该对团队有所贡献，在自己获得成长的同时，帮助其他人学习与提升。当然，这个团队绝对不是共产主义，只是在小团队中，拥有互相帮助、共同成长的环境，能够促使团队成员的个人能力得到快速提升。而这样才能够激发自组织团队的 Motivation，从而使团队越来越优秀。

极客时间：敏捷原则中提到“最好的构架、需求和设计出自于自组织的团队”，您怎么理解这句话呢？

袁店明：这句话中，架构和设计出自于自组织团队这两点不难理解，那为什么会说最好的需求是来自于团队，而不是来自于客户呢？主要原因在于，客户其实并不知道自己想要什么，是产品经理将客户需求描述出来的。那这么说，最好的需求难道来自于产品经理吗？也不是，产品经理只是把客户的痛点收集起来，至于如何用产品解决用户的问题，应该是实现需求的人最了解，也就是团队。团队需要写代码去实现产品，还要考虑到各种用户情况，因此可以说，最好的需求来自于自组织团队。

正因如此，作为一名最了解需求的技术人，就需要具备一定的产品思维，主要包括两点，一是了解用户细分人群，二是了解用户的行为和交互逻辑。

首先来看为什么要了解用户细分人群呢？极限编程中有个概念叫用户故事（User Story），是从用户的角度来描述用户渴望得到的功能，而我们有很多用户，用户需求也各不相同，因此就需要我们去了解用户的细分人群，清楚我们的用户是什么人，有什么特征等，这样才能写出更好的用户故事。

举个例子，有次我带团队，做的是一款管理工作流的产品，就需要去了解这类产品的用户人群，了解这类人群的特征。团队中有一位产品经理非常聪明，想到从 LinkedIn 上收集信息，他搜索相关岗位就能看到对应的人有什么特点和属性，比如工作职责、教育程度、能力方向等，是一个提取用户信息的好方法。

再来看第二个产品思维，即了解用户的行为和交互逻辑。最熟悉产品的人应该是技术人员，因此技术人需要熟悉所有用户和产品的交互逻辑，比如用户先输入什么，再输入什么，以及每一个数据的边界值、各种测试情况、各种交互路径的细节等等。你作为技术人，需要对此都非常了解。当然技术团队既包括开发，又包括测试，其实测试应该要比开发更了解用户行为。

至于为什么有的技术人没能具备产品思维呢？有多方面的原因，在我看来主要有两点。

第一个原因是产品经理与开发人员之间的矛盾，矛盾冲突加深之后，可能会让开发人员为了完成产品经理的紧急需求，而选择只求交差，放弃思考的做法。甚至于产品后续会出现什么样的问题，技术人员也不会去深入思考了。所以，产品与技术人之间的矛盾是产生问题的首要因素。

第二个原因是技术人没有参与用户故事内容的描述。一个好的用户故事应该遵循 INVEST 原则，这六个字母代表六个特性，其中的第二个字母 N 是 Negotiable，意思是一个用户故事的内容要是可以协商的。

但很多人就忽略了协商因素。我在辅导团队时，通常会用电子工具来管理用户故事，从中能够看到用户故事的版本记录。如果一个用户故事从初稿到终稿都是由产品负责人拍板，中间没有其他任何人做改动，那这个用户故事一定是有问题的。合理的做法应该是在产品负责人写完初稿后，开发和测试再将用户故事细化，最终经过协商后确定终稿。

我认为每个用户故事都应该加入技术人的产品思维。因为，产品经理虽然从用户端了解到了他们的需求，但对于实现需求的产品逻辑与细节，技术团队才是最清楚的，所以，产品负责人应该与开发团队共同协商，形成最终解决方案。

大咖对话 | 袁店明：打造高效研发团队的五个要点

你好！

本周作客大咖对话的是 Dell EMC 敏捷与精益创业咨询师袁店明。曾任职于百度，辅导过多个产品线转型，包括商业产品、无线变现以及多个移动互联网产品的团队转型和组织转型。目前着重于团队转型、组织转型、持续集成、欣赏式探询以及专业引导 (Facilitation) 的实践和应用。今天我们聊了聊打造高效的研发团队。

极客时间：您好，能先简单介绍一下您和您目前主要负责的工作方向吗？

袁店明：目前我的工作基本是三七分，70% 的工作是在做项目管理，负责中国区一个 350 人规模的 BU，剩余 30% 是做我的老本行，敏捷教练。

不过现在在工作中，我基本上已经不再提敏捷二字了，因为我做管理的时候，会用到敏捷方法论中的要点，至于团队是否敏捷、BU 是否敏捷，我几乎不再关心了。我只关心目标是否能实现，用户需求是否能满足，比如三个月后要上线新版，那我们需要交付哪些需求，还有哪些缺陷需要修复，这才是我关心的问题。

当然，在完成目标的过程中，会遇到很多问题，我们在解决问题时，可以运用各种各样的方法，这些方法或实践可以是敏捷范畴内的，也可以是敏捷范畴外的，其实并无所谓，能达成目标才是关键。

极客时间：在您看来，如何打造高效的研发团队？有何关键要点？

袁店明：对于这个话题，我还蛮有感触的，因为我的工作经历比较丰富，我加入过创业公司，在百度等国内知名的互联网公司工作过，也在阿尔卡特朗讯等知名外企工作过，还做过一年的独立咨询，现在来到 EMC，最开始是全职教练，后来做 BU 的管理工作。因此，我可以说是亲历过创业公司、民企、外企等不同阶段、不同类型的公司，见识过诸多不同阶段、不同状态的团队，对于打造高效研发团队，有一点自己的经验和看法。我主要总结了 5 个要点。

第一，团队项目管理的透明性

我从 2009 年全职做敏捷教练以来，每次辅导团队，做的第一件事就是公开团队的所有工作事项，保证项目管理的透明性。

我总结我的辅导经验后发现，效果最好的做法就是通过一块高 1.5 米，宽 2 米的大白板，将团队中所有事务全部罗列出来，包括需求列表、迭代表、问题风险列表等，把所有的信息透明化。

比如在白板左侧列出需求列表，中间写上迭代表，团队这一个迭代内需要完成的任务，之后列出团队目前遇到的问题及风险。另外，还有需求燃起图、迭代燃尽图等，便于查看每一个迭代图完成了多少个需求。还可以加上一份团队日历，标注出在迭代过程中的重要事项和重要时间节点。

因此，在这块白板上，我们能够看到团队中所有人的任务和进度。当然这对于个人来说，将自己完完全全暴露在团队成员面前，是一个很难过的心理关，因此，团队如果想要达到之前提到的完全透明的理想状态，就需要团队慢慢磨合。

这时，我作为教练，就需要能够发现团队成员的心理障碍或内心的担忧，帮助他们解决这些问题。这样不断发现问题，解决问题，才有可能一步一步将所有信息透明化。在此基础之上，我才能够建立团队内部的互相信任。

透明的团队项目管理，能够使团队内部互相信任，这点非常重要，因为，缺乏信任的单兵式作战，不能称为团队，只有建立互相信任的基础，团队才能高效作战。

第二，制定团队自己的规则

我曾经报名学习了 IAF 国际引导者协会关于引导的课程，从中深深感知到了团队规则的重要性。

我们常说流程，但流程其实跟规则有区别。一般来讲，流程针对的是上规模的团队或组织，只有当一个几十上百人的团体在做一件复杂的事情的时候，我们才需要流程。目的是为了在某一个节点、某一个方面提醒人们少犯错误。其中节点是时间纬度，方面是空间纬度。

这是我对流程的定义，但其实很多人对流程的定义出现了偏差，所以对于团队，我更喜欢用规则 rule。

另外，流程一般都是由公司层面制订的，团队不会参与流程的制定过程，只能按照固定流程行事。而在我看来，团队应该根据团队情况制定适合自己的规则，比如开会的规则、代码提交的规则、代码评审的规则，以及相应的奖惩制度等等。

只有团队自己参与了规则制定的过程，并不断检验它，才是让团队达成共识，高效协作的行之有效的办法。

第三，权利与职责清晰

团队内部公开透明，也制定了行之有效的规则，接下来就是明确权利与职责（义务）。权力与职责是对等的，你有多大的权力，就应该承担相应的职责，不能只享受权力，不承担义务，或只有义务，没有权力。

据我观察，互联网行业有一个很普遍的问题是，产品经理既管产品，又管项目，把两个权力都抓在手里，就很容易出现问题。比如产品经理进行项目估算后，由别人执行、落地，而一旦他的估算出现偏差，别人在具体执行过程中，就很难按照估算将项目落地，这就是问题所在。

我比较喜欢 Scrum 中的角色设置，他们分别是 PO（产品负责人）、Scrum Master 和 Team（开发团队），我想应该再加入一个重要角色，即 People Manager，这四个角色相互制约、相互促进。

我们先把 People Manager 抛外，在团队运作中，PO 负责产品方向，包括产品对外的承诺、收集所有需求等，Scrum Master 是 Team 和 PO 之间的“润滑剂”、协调者，负责提升团队协作效率，确保团队持续、高效地输出结果。而另一个角色 Team 的职责范围更广，事实上整个项目管理工作都是在 Team 内部完成，当然，这也离不开团队内部的自主性。

因此，每个角色的权利与职责不同，各自发挥其作用，保证团队的高效输出。

第四，个人的激励

团队运作中最重要的因素是个人，先有个人，再有团队，之后才是公司、社会和国家，而让一个人高效工作的秘诀就是 motivation（动机）。

对于团队 leader，我总结了三点激励团队成员的途径：

1. 动机，给予每个团队成员 Motivation。
2. 个人成长，了解团队成员的职业生涯或成长通道，按照这个方向帮助他提升个人能力。
3. 尊重与认可，关注团队中的个人，给他尊重与认可。当然，这方面也需要团队的透明制度作为支撑。

在激励个人方面，Scrum Master 会起到关键作用，他需要具备良好的引导技巧，（这也是我为什么去学引导技巧的原因），运用引导技巧，能够让团队中的每个人互相尊重，良好协作，高效沟通。

需要注意的是，Scrum Master 虽然担负如此重要的职责，需要解决团队中所有的问题，消除达成目的的障碍，但是，Scrum Master 本身没有权力，也不需要权力。因为有权力的团队无法自驱动与自组织，Scrum Master 应该依靠的是他的能力和影响力。

第五、透明的考评机制

考评机制是一个敏感话题，但对团队非常重要。在阿尔卡特朗讯内部曾经有一套“七二一”法则，其中，“七”代表对公司业绩的贡献，很好理解。

“二”是指团队产出的占比，是团队与团队之间的考评。比如在互联网公司，产品团队、开发团队之间互相考评，如果考评机制透明，他们互相打的分数就应该相对公平、公正。

当然，这是一个考核标准，考核的是产出量，另外，我们还可以考核产品上线后产生的缺陷量，这个数据很好统计，但往往会被忽略。因为有些人认为这样做很伤人，但其实，要想做到不伤人也很简单，就是将考核机制透明化、数据透明化，如果你认为不该是你背锅，你就可以申诉。

最后是“七二一”法则中的“一”，这 10% 是对个人能力成长的考核，我们不谈个人在过去一年对团队的贡献，而是关注他的成长，由团队来考评成长分数。

类似的，国内很多公司在用 360 度环评，考评内容包括工作能力、表现能力、沟通能力、协作能力、执行能力、分析问题的能力、解决问题的能力等等。从 360 度环评表中，我们可以获取所有协作者对某个人的评价与反馈，因为 360 度环评是透明的，每个人收到或发出的分数与评价都必须透明。

所以，拥有一个透明的考核机制非常有必要，能够促使团队自发地愈来愈优秀。

最后小结一下，以上提到的透明、规则、权责、激励、考评这五点，就是我多年实践下来，总结的对于打造高效研发团队最重要的五个要点，希望能给你带来参考。

大咖对话 | 让团队成员持续的enjoy

你好！

又到了“大咖对话”时间，今天的嘉宾是饿了么 CTO 张雪峰。2015 年初，他正式加入饿了么担任 CTO，之后饿了么的业务迅速发展。今天，其订单量仅次于淘宝和滴滴，与美团不相上下。亮眼数字背后，饿了么技术团队背负的压力可想而知。今天我们就请张雪峰谈谈他对于技术团队文化的一些感悟。

Q：作为 CTO 陪伴饿了么一路成长到现在的规模，你最大的收获是什么？

A：最大的收获就是一直支持我、陪伴我，能够坚持走到今天的团队，这听上去是个套话，但是确实不容易，因为我们是个创业公司，一开始也是一穷二白。我加入的时候，技术团队只有 30 多个人，分工也不完善。但是那时候被业务逼得就得迅速招人，而且那时候肯定是顾不上太多，不可能像 BAT 这些大厂去精挑细选，我们直接就先把人招进来干活，通过干活，相当于以赛代练。当然可能会出现一些问题，这个过程中就优胜劣汰了。这个团队到今天还留在这的同学，或者坚持 3 年以上的同学真的是不容易，没有他们我早就下台了。他们能够坚持下来，也是我自己能坚持下来最大的动力。

在此过程中，组织架构变化、研发流程优化更是家常便饭。不过无论如何变化，有一点却是不变的：研发管理，没有所谓 Best Practice（最佳实践），只有适应业务发展且生命周期有限的 Suitable Practice。

这一切有个前提，就是我们的创始团队对于我的信任，让我可以放手大胆的干，这也是在创业公司的好处，大公司你肯定会有很多的限制和约束。这两点缺任何一个，团队都走不到今天，我也走不到今天。当然公司会怎么样也不好说。

这三年多真的是靠毅力熬过来的，创业公司资源相对少，虽然有融资，但说实话，每天 CEO 一起床就多少钱出去了，不光是人员的工资这些，像我们做外卖，一天的营销费用也是蛮惊人的。我可能考虑的不是这个问题，我要把系统做稳定。其实我是 2014 年 9、10 月份开始接触饿了么，因为我跟饿了么联合创始人汪渊关系很好，就担任了他的技术顾问。后来出现了一些“火情”，他就说兄弟要不一起搞吧，我就来了。我加入之后也不可能马上见效，还是会挂掉，靠人肉上去顶，慢慢才稳定下来。你没有一点毅力，没有一点心理承受能力，真的支撑不下来。

Q：我们知道饿了么非常重视技术文化，那么饿了么的技术团队文化到底是什么？

A：饿了么的技术文化经历过两个阶段，新的文化我就不展开讲了，内容比较多，早期蛮简单的，就三个词：极致、激情、创新。到今天为止，我认为我们技术文化也主要是围绕这三点。

我是 70 后，但团队里大部分都是 90 后，包括我们几位创始人也都非常年轻。一般来说，岁数大一点的肯定是求稳，但是年轻人就是希望把一件事做到极致，这个词也是我进饿了么之后体会到的。以前知道这个词，但是没有经历过，进到这个团队我就发现完全不一样。如果认为这件事是对的又是很重要，大家就拼了命的要把这件事做到最好，实际上并不是每次都能做到最好，但是目标就是要做到极致。

激情的意思是，在顺风顺水的时候有激情是正常的，在不顺利，或者有坎坷的时候，你还能保持激情，这才是激情真正的含义。我们其实经历了很多坎坷挫折，尤其在高峰期系统挂掉的时候，外面铺天盖地的吐槽，这时候你的压力会非常大，你会有挫折感。这时候如果没有一些东西支持你，那可能你要么放弃，要么就听之任之。不管怎么样，更多是在逆境的情况下，保持激情非常重要。如果无法让团队始终充满激情，不可能有持续极致成果。

最后是创新，创新也是我们这个团队的一个很重要的基因。外卖行业大部分新鲜的东西，或者现在被验证成功的东西，都是饿了么首创出来的。这跟创始团队的基因很有关系，创始团队对技术很重视，很多时候创新是靠技术来带动。还有商业模式创新。我自己原来其实不是很有创新精神，但是进了这个团队之后，我受这点影响很大，你不能预测对与错，但至少要去试一试。创新有个近似词叫试错，试错就是大部分试下来是错的，只有很小的概率能试对。所以创新需要激情去支撑。

这就是我们说的极致激情创新，我们技术团队没有把这些作为口号，也没有标语，就是大家一直在潜移默化中这样做。

Q：新人加入之后，怎样能够帮助他们融入这种团队文化？

A：我们新人进来之后，可能有岁数比较大的，就像我刚进来，我也有一点吃不准自己能不能适应这种文化，解决办法很简单，就是让他能够 enjoy，而且能够持续的 enjoy。人只有在快乐的前提下，做他有兴趣的事，才能够做好。

enjoy 有两个层面，一个是 enjoy 过程，我们叫 enjoy working，你自己不管写程序也好，做产品设计也好，做架构也好，包括网站宕机去救火，你要 enjoy 这个过程，做你喜欢的事。新同学来了之后，我们会让他们去体验，先选自己喜欢的事，当然也不可能每个人都想去那个岗位就去那个岗位，但我们会尽可能做到。结果方面，允许一定的失败率，就是这个项目不成功，或者你这个项目成功，但你在项目中并没有做的非常好，这方面我们允许一定的试错成本。

还有就是 enjoy result，光讲过程没有结果也不行，因为公司毕竟不是福利院，即使试错 100 次失败了 99 次，你好歹也要有一次靠谱。总的来说就是要让同学们做自己喜欢的事，而喜欢的事又能给公司带来价值，毕竟我们是个商业公司，要让团队持续的 enjoy，如果说今年享受过一个成果之后，明年就一下子掉下去了，这也不行，我们要一直创造一些很有意思的东西让大家去做。

除了公司的收益，还有一件事，这几年公司一直在强调，就是社会价值，或者说社会责任。因为我们毕竟做的是一个食品相关的行业，食品安全还有我们的骑手的安全，还有比如最近我们做的一个寻找走失儿童的行动。你的业务上正好有一个环节可以去延展一下，就能创造社会价值，这也是能够让团队成员 enjoy 的。

作者简介

张雪峰，饿了么 CTO，TGO 鲲鹏会上海分会会员。曾带领携程软件架构团队 & 框架研发团队，后担任携程国际 BU CTO。曾有过一次创业经历（教育行业），深知创业之痛并快乐着的感觉，理解创业之苦、之难、之惨烈。

大咖对话 | 谢孟军：技术人如何建立自己的个人品牌

你好！

本周作客大咖对话的是积梦智能创始人兼 CEO 谢孟军，他也是 TGO 上海分会会长。谢孟军是知名 Go 语言专家，Gopher China 创始人，著名开源框架 beego 开发者，畅销书《 Go Web 编程》作者，曾就职于 Apple 、盛大云。本周，我们跟他聊了聊技术人打造个人影响力那些事儿。

极客时间：从您的经验来看，技术人该如何建立自己的个人品牌和影响力？

谢孟军：对技术人来讲，良好的个人品牌是非常重要的，它体现了你在别人心目中的价值、能力以及作用，是你职业生涯中的第二个自我，它影响着别人对你的看法，也能把别人对你的看法变成机会。

回到如何打造个人品牌，我们可以从三个方面出发，第一是个人核心技能的打造，第二是打造自己的独特性，第三是找平台 + 建立圈子。

1. 个人核心技能的打造

个人核心技能是指你在某一个领域是否足够精专，是否具备足够的核心竞争力。最直接体现在你在这个工作岗位上的不可替代性程度，你的不可替代性越强，就说明你越有核心竞争力，反之亦然。间接则体现在你在公司或是这个领域中的话语权及权威性。具体打造的话，我们可以从聚焦和开阔眼界两个方面着手。

首先是聚焦， 一定要发现并聚焦到自己最擅长的领域，然后专注这个领域，不断精进和优化自己的能力，成为该领域的专家。

以 Go 语言为例，Go 其实是一个很大的技术领域，所以你需要聚焦到更小的技术方向上，比如专攻 Go 中的 API 这一技术点。然后不断的学习、不断的深挖，在这个具体方向上做到最好，同时积极参与社区，逐渐成为这方面有话语权的专家。

其次是开阔眼界， 如果专注在一个领域或平台太久，你会发现自己的思路、格局都会受到限制。这个时候就必须向外探索，看看外面的世界，看看行业的整体情况，看看其他大牛的实践是怎样的，吸收其中的精华，再找到自己的差距。回来后，再快速地聚焦专注到自己的主攻方向，不断地精进，再外化，这样内外兼攻，快速打打磨自己的核心竞争力。

2. 打造自己的独特性

除了技术功底扎实外，如果想打造个人品牌，就一定要找到自己的个人特色，打造自己的独特性。

而独特性，一般由核心技能之外的多样化技能构成，比如你程序员里最会演讲的、最会写文章的、最会做 PPT 的等等，这些都是很好的标签。这样，如果公司有一个去知名技术大会分享的机会，你就可能是领导第一个想到的人。

当然，我常开玩笑说我是 Go 语言界里面最帅的，这其实也是一个很好的标签，能让大家一下子就记住我。

除了多样化的技能之外，还可以多发展一些兴趣爱好，积攒几个真正能拿得出手的，比如你摄影很厉害、踢球很厉害、跑马拉松很厉害等等，这些都能给你带来不一样的标签。被打上的标签越独特，就越能让人记住，就越能加强个人品牌。

3. 找平台 + 建立圈子

很多技术人给人的第一印象就是有点内向，不爱交流，我一直很建议技术人们多出来分享。分享的好处有很多，首先，很多东西你以为已经弄明白了，其实不然，出来分享，有助于你把自己正在做的事情真正理清楚、讲清楚，这是非常重要的。

其次，你分享之后，别人才能给你反馈，有正向有反向，你才可能意识到自己之前走入的一些误区，也能认识到自己和行业真正顶尖水平之间的差距。最后，通过分享，别人才有可能认识你，这是一个锻炼的机会，也是一个树立自己形象的机会。

因此，要想让自己的个人品牌足够大，就一定要出来分享，而且要选择一些优秀的平台，比如极客邦举办的 InfoQ、ArchSummit 等大会就是不错的选择。

我们也可以建立自己的圈子，比如我通过 GoCN 社区的打造、GoCN 每日新闻的更新、Gopher China 大会、各地的 Meetup 等活动的举办等，成功的推动了国内 Go 语言社区的发展。可以毫不客气的说，国内 Go 语言的圈子基本就是我一手搭建起来，选择 Go 语言的技术人，大多都会认识我。

极客时间：以您的经验，程序员该如何提升自我呢？否能给出一些自建议？

谢孟军：这个话题其实很大，但我觉得最重要的还是坚持坚持再坚持。以我做 Go 语言社区为例，到现在我已经坚持了 6、7 年了，而且还在继续坚持下去。

我之前写过一本书《Go Web 编程》，写这本书的时候，我的儿子刚出生，每天回到家跟儿子互动完之后就差不多已经是 9、10 点了，但我会从 10 点开始写文章，一直写到 12 点睡觉，这样的生活我坚持了大概一年多，直到写完这本书。包括我之前写的 beego 框架，也是一直坚持了 6 年多，直到现在。

还有一个例子，之前我每天都会把自己看到的 Go 语言相关的新闻、知识，整理成类似每日新闻形式的内容，然后发到社区中，一直坚持了 3 个多月，最后，这个内容演变成了现在的 GoCN 每日新闻栏目。刚开始还有人觉得这是不是我拿爬虫爬的内容，其实不是，就是我坚持把自己每天看的内容整理之后分享给大家而已。

我一直觉得，一个人要想取得成功，最主要的就是两点，第一是充分利用好自己的时间，包括业余时间；第二就是坚持，坚持做自己喜欢的、感兴趣的事情。

就像我们写公众号，写一篇文章爆红，是眼球不是品牌；写一百篇文章，篇篇有人看，是积累也不是品牌；但是每年写一百篇文章，坚持了七年，提起某个领域，大家首先想到的就是你，这才是品牌。

极客时间：您一直在积极参与开源，那您怎么看待技术人完成业务和参与开源项目之间的平衡？

谢孟军：这是个好问题，我就分享一下我自己是怎么做的吧。我做 beego 这个框架的时候还在盛大，当时我已经在用 Go 语言写很多小系统去完成各种业务功能。但在这个过程中，我遇到了很多共性的问题，我一直在写很多重复的代码。我就想着是不是可以把这些共性的问题抽取、提炼出来，然后我就这么做了，并把它开源了，这就是 beego 最早的一个版本，它是从业务中诞生的。

后来我加入了苹果，虽然负责的业务方向有了调整，但我还是会把 beego 中相关的、有价值的部分应用到业务中去，加快业务的发展速度。可以看到，这个开源项目是对我负责的业务有帮助的。

所以，我基本是把业余时间扑在开源项目上面，然后工作时间的话，把项目中有价值的、能起到作用的部分应用到自己的业务中，两者相辅相成，这样把握两者之间的平衡会更好一些。

大咖对话 | 谭待：架构的本质是折中

你好！

本周作客“大咖对话”的嘉宾是百度搜索首席架构师兼区块链实验室主任谭待。他的主要研究领域在分布式系统、搜索引擎和区块链，是百度 BVC 代理计算和 Matrix 私有云的主要设计者，两获百度最高奖。主持设计了百度新一代搜索架构，在时效性和计算规模上实现了大幅提升；同时也主导了极速搜索、全站 HTTPS 等百度搜索的一系列重大革新。

极客时间：您现在身兼百度搜索首席架构师和区块链实验室主任，这两个不同角色之间的差异大么？您如何调整自己适应不同的要求？

谭待：在百度搜索这边，我作为首席架构师，是一个 IC 的角色，也就是独立贡献者。百度跟很多互联网公司不一样，百度的技术序列是不带人的，即使要推进项目，用的也是非职权管理的方式，更多的会依靠技术人自身的影响力，而不会涉及到具体业务相关的管理。而在区块链实验室这边，我作为主任，就要承担很多业务相关的管理工作。

我需要在这两个角色之间互相切换，而不同角色的要求是不一样的。

作为技术负责人，虽然也会有非职权管理的场景，但更多的是需要把个人的聪明才智发挥出来，找到关键点，把事情给解决掉，体现出你的技术价值。同时在宏观方面，还要着眼整体技术方向的演进，以及技术梯队的培养等工作。

而作为管理身份，简单来说，就是不能像原来那么挑活了。原来作为技术 Leader，我可以只看最关键的事情，剩下的反正有经理帮着兜底，如人员问题、预算问题等，我都可以不去管。但现在作为一个业务的管理者，我变成了那个兜底的人，需要把很多精力分到一些看上去非常琐碎，但对整个部门发展非常关键的事情上，比如上面提到的人员招聘、预算制定等。

除此之外，最大的挑战是思维方式的改变。

在搜索这边，我依旧保持之前的思路和做事方式，保持对技术的判断力，找出技术的最优解，发挥技术的最大价值。

但在区块链实验室这边，我反而需要主动克制自己对技术的感觉，不要过多的参与到一些非常细节的技术讨论和判断中。甚至有时候我有更好的想法，也要忍住，不能直接提出来，而是要慢慢引导团队，或者让他们自己去尝试。

主要原因在于，一方面，我作为业务管理者过多的参与技术方案的制定，对整个技术团队的成长并不是一件好事；另一方面，作为管理者，我需要将更多的时间和精力分配到整体的业务和战略上，以及对内对外、向上向下的各种协同合作中。

总的来说，我现在也不算是从技术转向管理，而是同时保留了这两种角色，有点人格分裂的感觉，但也是非常有意思的挑战。

极客时间：回顾一下您的职业生涯，对您影响最深的事情是什么？

谭待：这么多年下来，感触深刻的事情还蛮多的，我分享一个至今仍对我产生影响的事情吧。

2007 年，我进入百度开始实习，加入了一个主攻云计算方向的团队。当时这个团队聚集了百度最优秀的人，公司也给了非常大的支持。

一方面，一毕业就加入一个可以说是当时全国最优秀的团队，得到了很多牛人的指导，这对个人的成长非常有帮助，最关键的是在这个过程中养成了很好的技术素养和做事方式，对我的职业生涯起到了奠基性的作用。

另一方面，这个项目后来失败了，它有着最优秀的团队，做的也是云计算这样符合技术趋势的事情，但它最后却失败了。可以说，如果它成功了，那它对我的触动还没有这么大。

我时常回顾它的失败原因，其中最大的一个原因是，它没有吻合产品的发展步调。

这是一个技术型项目，但它最终是要服务于某一个业务和产品的。然而，这个项目在设计之初，就和产品的步调脱节了，它的发展计划没有很好的吻合产品的发展计划。所以，虽然它的技术很出色，取得的成果也不错，但产品等不了它出成果、出方案，最终就用了其他方案。对这个项目来说，它就是失败了。

大家都知道，技术要结合业务和产品的发展，但老话说的好，知易行难，知道归知道，要做到知行合一是一件很难的事情。很多技术人，在执行过程中，会不自觉的追求最前沿的技术，会很自然的从自己的角度出发思考问题，而忘了考虑产品的需求与步调，最终导致两者脱节。

这件事情对我的影响很深，一方面，它帮我培养了非常好的技术素养，让我懂得在做技术规划的时候，要往前看，往远看；另一方面，它也提醒我，你可以站的很高，看的很远，但你的每一步落地，都必须要接地气，踩中业务方的节奏。

极客时间：您从事架构相关工作多年，在您看来，架构的本质是什么？

谭待：架构的本质是折中，作为架构师，你拥有的是有限的资源，如人力资源、机器资源等，但你面对的是没有上限的需求，如工期的需求、稳定性的需求等，所以需要在不同的层面做出折中的选择。

你不可能做出一个完美的解决方案，必然要牺牲一些东西来达成另一些需求。所以，从宏观的整体架构设计和安排，到最终每个功能点的实现，都是折中的。

比如，我过去设计方案的时候，会做不同的 Milestone，选择不同的 Feature List，这是一种广泛的折中。再具体点说，你做方案的时候，不管是用空间换时间，还是用时间换空间，都是一种折中。

展开来讲，首先，作为架构师，要明确你设计系统最终还是为了产品和业务，所以，你要了解产品和业务的需求，并做出相应的预判，比如预判这个产品三年以后会是什么样的。这样，你设计的系统，就有足够的预留空间和生命周期。

在百度，我们设计系统的时候，一般会去看业务三年以后的情况，这样做出来的系统，至少在三年内能比较好的支撑业务发展。另外，硬件基础设施一直在迭代，三年后很可能就发展到一个新的阶段。这时就可以根据新的业务情况和硬件条件重构系统，也能借此机会让团队更好的熟悉原来的系统。

其次，作为架构师，在设计系统的时候，一定要找到关键点。折中不是平庸，而是为了更好的在某些关键点上突出，为此，可以在别的地方做出牺牲。

我父亲小时候给我讲了一个故事，至今印象深刻。20 世纪初期，美国福特公司的一台电机出现故障，很多人花了两三个月都修不好。在束手无策的情况下请来了专家斯坦门茨，斯坦门茨在电机旁边仔细观察，又计算了两天后，就用粉笔在电机的外壳上画了一条线，说：“打开电机，在这条线往里的线圈减少 16 圈。”结果证明，问题果真出在这里。

这个故事给我的感触很深，作为架构师，你一定要成为那个划线的人。一个架构会涉及方方面面，不可能全都很好的顾及，所以，你需要找到那条线，找到问题的关键，并将其解决，这才是最能体现架构师价值的地方。

举个例子，我做过的极速搜索项目，这个项目目标是把搜索平均速度提高两倍。我之前一直负责搜索中的底层分布式的系统，分布式系统里的很多折中是怎么把时间和空间进行互换。之后，我接手极速搜索项目。之前，大家做速度优化，普遍的思路是看哪个地方慢就优化那个地方。我没有这样的惯性思维，而是想着，分布式系统里的那种用空间换时间的做法能不能应用到速度优化上来。

最后我的方法是，系统提前预测用户的搜索目标并实时抓取，当用户点击搜索时，就把搜索结果瞬时展现出来。这么做必然会消耗更多的资源，但却能极大提升搜索速度，基本可以把搜索请求时间缩短至原来的 10%。

可以说，“用空间换时间”就是我划的非常漂亮的一条线。

大咖对话 | 陈天石：AI 芯片需要技术和资本的双重密集支撑

你好！

本周大咖对话的嘉宾是寒武纪创始人兼 CEO 陈天石博士，近年来，AI 成为科技领域内最受关注的话题，芯片行业也开始高频率地出现在大众的视野之中。而寒武纪作为国产 AI 芯片创业领域的头部独角兽，如何在巨头涌入芯片赛道后继续保持“独立”？我国芯片产业的前景何在？芯片产业当下的挑战和未来的发展趋势又是什么？在采访中，陈天石博士与我们分享了他的观点。

极客时间：陈博士您好，能先简单介绍一下寒武纪目前的芯片产能和自研情况吗？
陈天石：寒武纪拥有终端智能处理器和云端智能芯片两条产品线。
针对终端应用，我们在 2016 年就推出了世界首款终端人工智能专用处理器——寒武纪 1A 处理器（Cambricon-1A），面向智能手机、智能视觉、可穿戴设备、无人机、机器人和智能驾驶等各类终端设备，早于国外同类型产品两年以上。

2017 年开始，我们先后发布了第二代多核智能处理器寒武纪 1H 及第三代高性能智能处理器寒武纪 1M。1A、1H 分别应用于麒麟 970 与麒麟 980 芯片中，迄今已累计服务了千万台智能手机终端。

2018 年 5 月，我们发布了云端人工智能芯片 MLU100，开始从云到端全面的人工智能计算力生态布局，目前 MLU100 已进入大规模量产阶段，与浪潮、联想、曙光、H3C 等服务器厂商的适配机型已开始陆续出货。

对于 2019 年，除了完成现有产品线的升级迭代外，面对更复杂的云端智能训练应用、轻量级的边缘端场景和消费类电子产品，我们还将推出一系列新的芯片和 IP 产品。另外，在与民生紧密相关的 AIoT 领域，寒武纪也会做重点赋能。

极客时间：芯片行业并不是个新兴产业，市面上已有如 CPU、GPU 等诸多类型的处理器长期存在。和其他类型芯片相比，智能处理器诞生与发展的必要性是什么？
陈天石：深度学习是目前 AI 领域机器学习方法中最为有效的算法，深度学习模型需要大量的数据训练，这就要求处理器有极高的运算速度作为支撑。

传统 CPU 基于低延时的设计，拥有复杂的内部结构，优点是拥有针对各种不同类型数据的计算能力以及逻辑判断能力，适合进行复杂逻辑的问题处理和计算设备内的管理调度。而深度学习模型所需的运算能力极高，传统架构处理器无法做到功耗与速度上的平衡——通常需要成百上千条指令才能完成对一个神经元的处理。

目前人工智能行业内主流做法是采用 GPU 并行计算神经网络。GPU 是专门进行图像运算工作的处理器，因为它在浮点运算、并行计算等方面的性能优势与人工智能的需求不谋而合，于是在人工智能爆发的关键期，GPU 被广泛使用。但是作为图像处理器，GPU 在推理阶段无法充分发挥并行优势，另外由于 GPU 的计算方式不是为深度学习算法专门设计，性能峰值无法被完全利用。

所以，人工智能行业需要经过专属设计优化的处理器，来应对计算密集型应用场合——不需要面面俱到、八面玲珑，但要有强大的执行力，速度一马当先；同时，也不会带来过高的功耗，这是 AI 专有的速度与激情。

而寒武纪芯片是专门针对深度神经网络计算而设计的 AI 处理器。针对传统 ASIC（将单个特定算法硬件化）思路无法解决深度学习处理需求这个问题，我们通过多年研究，采用硬件神经元虚拟化，稀疏神经网络处理器架构等技术以及深度学习指令集打造了寒武纪的 AI 芯片，使得寒武纪芯片在执行 AI 计算任务时能效可以实现最大程度的优化，和同类产品比速度可以实现大幅提升。

极客时间：现阶段芯片发展到了什么阶段？目前面临的最大挑战点和难点在哪？
陈天石：从人工神经网络的雏形在上世纪四、五十年代被提出开始，人工智能发展几经起伏。近年来，得益于算力、算法、大数据等各个要素上的全面突破和创新，在现阶段，AI 技术应用发展如火如荼。

作为 AI 核心的底层硬件——芯片，也同样经历了漫长的发展过程，从 CPU 到 GPU 再到专门的 AI 芯片，我们一直在试图通过硬件架构创新，去追求计算效率、性能和能效比等性能上的进一步攀升。

目前，随着深度神经网络的层数日益增多，规模日益庞大，AI 芯片发展始终在面对严峻挑战，并需要持续完善以下 3 个方面：

1. 算力资源储备 —— 网络规模变大之后，如何用足够的计算能力来支持如此庞大复杂的深度学习模型；
2. 功耗与成本 —— 如何在超大规模并行计算中更好地兼顾性能与功耗，同时成本可接受；
3. 性能与灵活度 —— 如何能在拥有更适合 AI 计算特点的丰富算力的同时，让算力适用于尽量多的行业与应用场景，满足云端计算中的应用多样化需求。

曾有人开玩笑说，现阶段 AI 的最主要矛盾是 PPT 中体系健全 / 理论完备的全行业解决方案与现实中难落地难实现的实际应用之间的矛盾。作为最底层基础，AI 芯片提供的计算力是连接算法和海量数据的桥梁，是 AI 解决方案得以真正在传统应用中顺利落地的钥匙。

极客时间：在您看来，芯片产业未来的发展趋势将会是什么？
陈天石：AI、大数据、云计算等技术的兴起对处理器提出了不加上限的性能需求，而芯片产业经过 50 余年来的发展，面临着通过架构创新来实现突破性进步的瓶颈。

为了解决海量数据的处理效率问题，无论是在大型数据中心的服务器中还是在芯片内部，异构计算已成为目前越来越普遍的架构模式。CPU 担任调度管理角色，其他多种类型协处理器来负责各种类型的数据处理和计算加速，协处理器的性能在某些程度上还会超越 CPU。

对于 AI 芯片来说，如何通过模型压缩以及设计更合理的数据流等技术手段来实现性能和灵活性的进一步提升、功耗与成本的进一步降低，也是我们持续探索的方向。

另外，在未来时代，物联网和 AI 相辅相成，密不可分。打一个比方：物联网让各类的设备和终端有了生命，而 AI 让它们有了智商。如今物联网已经渗透到我们生活的各个领域，它所具备的万物互联和海量数据的特性也推动了云计算、大数据、AI、边缘计算等技术的发展。即将到来的 5G 时代，也会进一步加快物联网和 AI 等技术的爆破式进步。

物联网连接的物理对象多样且应用场景丰富，将来更需要通过云计算、边缘计算、智能终端计算的协同发展、有机部署来实现万物互联的智能世界，而全部场景中的这些智能数据处理，都需要 AI 芯片参与其中。

极客时间：现在大家都在关注芯片动态，有一种观点说中国芯片产业落后国外几十年，很多时候都是自嗨，您如何看待这一观点？
陈天石：AI 芯片这个领域和其他的芯片领域不太一样的是，中国和其他国家相比不存在太多历史积累上的差距，相反中国还在开始设计研发 AI 芯片的时间上还领先一步。大家从同一起跑线出发，AI 芯片市场前景广阔，人工智能产业发展和应用推进也是迅猛的，希望和国内外同行一道共同努力，推进人工智能领域发展进步。

极客时间：当下越来越多的企业，包括巨头互联网公司都在布局 AI，您如何看待这一现象？接下来寒武纪会有什么差异化的打法吗？
陈天石：基于 AI 技术的突飞猛进和对日常生产生活的深入影响，布局 AI 已经成为一种潮流和趋势，包括现在许多巨头通过研发 AI 芯片来实现自身 AI 生态圈的闭环，形成全栈 AI 平台，其实是希望围绕自身的主营业务形成完整或相对完整的行业解决方案，提前部署万物互联时代的战略，以期待减少对芯片供应商的依赖，保护自身核心技术秘密与知识产权。

但客观来说，芯片从设计、制造到封装是一条几乎没有捷径的漫长链条，尤其是芯片的设计，需要技术和资本双重密集支撑。所以，能对计算基础架构进行布局的 AI 公司不多，能真正打造出高性能、可商用的量产 AI 芯片又是一件更不容易的事。

寒武纪的定位一直以来很明确 —— 做独立的芯片设计公司。为下游厂商提供不同尺寸、面向不同应用场景的终端 AI 处理器 IP，提供从前端训练到后端推理的多品类云端 AI 芯片，帮助大家解决“AI 闭环路上最后一公里”的事情。

大咖对话 | 陈斌：如何打造高创造力、高动力的技术团队

你好！

本周作客“大咖对话”的嘉宾是易宝支付 CTO 陈斌，曾任日立美国系统集成总监、Abacus 首席架构师、Nokia 美国首席工程师和 eBay 资深架构师等职位，拥有丰富的海外经历和架构经验。回国后加入易宝支付，领导公司技术团队，负责建设公司技术体系，对管理有自己独特的认知。今天我们主要聊了聊技术领导者如何带团队，以及技术人的职业通道。

极客时间：依您多年的海外工作经验来看，国内外的 IT 公司有哪些方面的差异？

陈斌：我认为主要有两方面的差异。第一个方面是技术应用的差异，美国的 IT 公司更加注重对基础技术的投入和研发。比如 Android 系统，国内几乎所有的手机制造商都在用这个操作系统。再比如大数据领域的 Hadoop、Spark 等，都是源于美国的一些开源项目或者科技公司的自研项目。相比之下，国内的 IT 公司对基础技术的投入比例没那么多，但国内 IT 公司在技术的应用方面比美国做得更灵活。比如微信，它相当于整合了美国的 Facebook、Twitter 等诸多软件的技术，功能更丰富，能解决更多问题。

第二个方面是领导力的差异，美国公司更注重激发员工潜力，使员工在做事的时候主动发挥个人能力、个人影响力，国内公司则更多见于 KPI 的管控。我认为如何让工程师高高兴兴的来上班，自发努力的去工作，这是技术领导者要研究的一个重要课题，在这方面，国外就做得比较靠前。

极客时间：您回国后，管理理念会不会有所改变，谈谈您是如何管理团队的？

陈斌：重新回到易宝集团后，随着团队规模的不断扩大，也遇到了各方面的问题，比如技术团队与非技术团队的配合问题，包括与产品部门、业务部门的配合问题等。

同时，在一些事情的处理方法上也有些不同。举个例子，如果一个系统由于员工操作不当出现了问题，有些公司可能会主张给员工记过、罚款。我非常不赞同这样的做法，为什么呢？因为这种做法是针对人，而不是针对事。正确的做法应该要对事不对人，因为我们的目的是要解决产品技术的不足，优化流程、优化管控系统等。做接近目标的事情远远比处分一个员工重要的多。

另外，公司文化也很重要，作为 CTO，有些方面跟 CEO 是一样的，我们都对公司的企业文化建设有着不可推卸的责任。企业就像一个花园，里面长满了各种奇花异草，有好看的玫瑰，也有无用的烂草。作为领导者，该施肥的就给它施肥，该铲掉的就把它铲掉，这样花园中的植物才能生长的更好。同样，领导者的关怀就像阳光，应该多给员工鼓励，多拍拍肩膀，让小草成长得更快更茁壮。

更具体点讲，不同企业的规模大小不一，管理方式也应该根据企业自身的情况作出调整。团队人数一般以 150 人为临界点，对于 150 人以下的团队，CTO 可以施加个人影响力，通过沟通来解决大部分问题；而超过 150 人的团队，就需要更好的企业文化来推动，此时 CTO 必须具备 Leadership，是一个领导者，而不仅仅是管理者。

极客时间：作为技术领导者，如何保证技术团队的创造力与动力？

陈斌：互联网公司都提倡创新，比如在易宝集团，我们更加鼓励大家要有创新的意识，不要把创新当做一件高不可攀的事情。你可以做一些微创新，也可以做一些流程上的小改动，或者利用新技术做一些事情。

我们每年都会举办两次创新 24 小时活动，一般在周末把大家聚到一个地方，提供食宿。大家可以三五成群、集思广益去讨论、研究一些东西。在活动中，我们成功找到很多不错的创新，甚至有人做出了能够申请专利的产品，这其中关键的是企业给大家提供了一个创新的氛围。同时，我们也有内部创业的政策，如果员工有好的想法，公司可以提供创业条件，与员工一起创建新的公司。

除了创新，要保证技术团队的创造力与动力，我们还要给员工打开上升的职业通道。在易宝，职业通道可以分为技术通道和管理通道两个方向。在技术通道，员工可以从 T1、T2、T3、T4……一直往上走，到 T7 时可能就是架构师。只要在技术方面不断积累经验、提升能力，就一定会得到公司认可，会有新的挑战，能一直做下去。否则每天都重复做同样的事情，员工就感觉不到自己的价值所在。

另一方面，如果员工在长期的实践中不断总结经验，甚至积累管理经验，我们也可以把他从技术通道转为管理通道。管理方面的知识比较通用，比如，前期可能是管理运维，那后面也可以管理监控或者测试等其他方面的工作。

另外，我们也鼓励员工主动思考。比如，自动化运维一直是我们追求的目标，越来越多的重复性手工工作被自动化取代，节省了大量的人力资源。但剩下的人不等于说失去价值了，我会希望他们做更深入的研究和分析工作，比如分析运维设备的使用率，如何把进一步提升其使用率等。这能给公司创造更多的价值。

极客时间：CTO 在各方面已经达到顶尖了，那他未来的职业规划是什么？

陈斌：公司规模有大小之分，大公司的 CTO 和小公司的 CTO 所需的能力也有差别。真正优秀的 CTO 需要有很强的领导力、影响力、技术战略能力以及战略前瞻性。没有人敢跳出来自称是一名很合格的 CTO，大家都是在实践中不断总结经验，不断提高自己。包括我也是，对我们来讲，要学习的东西太多了。

首先是技术方面的挑战，因为不断有新的技术涌现，作为技术领导者，不能只要求团队的兄弟不断学习，自己却止步不前。对于各种新的技术与趋势，你也要不断的更新与学习。

其次是业务方面的挑战，技术领导者需要有很强的敏锐性，需要熟知你的业务，对于所处的行业、自己的产品以及当前业务的发展，都要有敏锐的分析力。所以 CTO 必须清楚，这个业务是赚是亏，在行业中处于怎样的竞争态势，你的产品有哪些特点与不足，等等。这些都需要不断学习，不断更新。

然后是领导能力的挑战，领导力是个人的性格魅力，加上后天培养形成的。领导力的培养并不是报一个班，教一教就能学会的。例如，怎么跟你的下属、上级以及周围的同学沟通，怎么去说服别人等。这些都有一定的技巧性，并不是通过学习理论就能搞定的。这就是领导的艺术。为什么领导力是一种艺术而不是技术呢？因为艺术是多元的、生动的，需要自己体会、自己摸索、自己掌控。所以即使已经成为 CTO，要学习的还有很多，学无止境。

还有一种情况是，很多 CTO，在一段时间之后，选择自己创业，转变为 CEO，这又是一个新的开始。

讲到这里，我再多说一点，就是 CTO 与 CEO 的沟通难题，如果 CEO 有技术背景，那沟通起来还比较容易，但很多情况是，CEO 没有技术背景，他与 CTO 的思考方式不同，那作为 CTO，如何与 CEO 形成伙伴关系，共同推进公司业务，这是所有技术人都要面对的一个问题。

我的建议有两点，第一点是理解与信任，第二点是尊重与默契。

首先要做到相互理解、彼此信任，因为 CTO 与 CEO 各自承受的压力类型不同，要懂彼此其实很难。CEO 担负的是整个公司的存亡问题，包括如何应对激烈的竞争，如何在市场中分一杯羹等，而 CTO 考虑更多的是公司技术体系的搭建，保证系统的平稳运行等。所以，双方要互相理解各自的难处，同时，做到相互信任才能更好地沟通与协作。

其次，双方要互相尊重，有合作默契，比如 CEO 不要把 CTO 当成是“我请来打工的，你只要把活干好就好”，CTO 也不要有这样的想法“反正是给老板干活，公司死活是他的事，跟我没关系”。

在合作中，往往是先有信任，才有尊重。如果你觉得 CEO 信任你，那你就不会觉得他说的话是对你的不尊重，否则 CEO 说话直接点，CTO 就会受不了。相反也是这样的。所以，最关键的还是彼此间的信任与尊重。

其实 CEO 与 CTO 之间的沟通障碍是客观存在的，也是正常的，我们要清醒意识它的存在，更关键的是在这种时候，CTO 要主动向前走一步，跨越这个鸿沟。

大咖对话 | 陶真：技术人要爱上问问题，而不是自己的解决方案

你好！

本周大咖对话嘉宾是上上签电子签约联合创始人、首席技术官及产品官，TGO 鲲鹏会会员陶真。在回国加入上上签之前，陶真曾先后在美国一线 SaaS 服务公司 Intuit 及 Paycor 担任 VP 和 CTO 职务，拥有 20 多年技术开发经验和丰富的管理经验，并在 2008 年获得了宾夕法尼亚大学沃顿商学院的工商管理硕士学位（MBA）。

极客时间：作为技术管理者，您为什么会选择去读 MBA 呢？
陶真：去沃顿念 MBA 对我的视野，看东西的视角有很大的增进。MBA 可以把一个技术管理人员的视野拓宽到技术之外，去了解做技术的目的，或者说做这项技术对改变世界、优化客户的流程、解决他们的痛点到底有什么实质性的作用。当把视野放高了之后，反倒能在技术上更加地如鱼得水，可以避免去做一些技术上感觉很热闹，但并不一定有商业产出能效的事情。

其实，我选择去攻读 MBA，主要是出于“好奇心”。我在美国从事第一份工作的时候，就跟别人“不同”，我会多问一点，别的程序员可能照着需求，直接或者加一点猜测就去埋头做了，但是我会先快速做出一点来，给产品经理看一看，问一问，了解为什么要做这个东西，有时候还会协助他们去做一些优化。

后来产品经理、销售就会带我去见客户，跟客户去沟通，帮他们解决技术产品上的一些限制，这对他们的工作也有很大的促进。有时候他们处理不好客户要求、焦头烂额的时候，就会带上我去跟客户沟通，通过技术、通过功能、通过对客户问问题这些方法，让客户变得非常合作，愿意跟我们一起创新，也愿意去接受一些他们无法向客户解释清楚的时间点或者功能的改进。

当有这样一个开端之后，这些商务人员遇到其他一些产品计划的时候，就会很主动地让我去参与，这对我自己也是非常大的增进。那时候就萌发了一个想法，就是作为一个技术管理人员，要怎么把商务的东西了解好？把公司的价值做好？把客户的价值做好？所以觉得去读一个管理方面的学位会有很大的帮助。

另外，这份“好奇心”也让我养成了喜欢从技术和非技术的角度去看问题，去跟各种不同的人做沟通的工作方式。当时我在 ADP 之所以会做的比较突出，不仅仅是因为技术方面很强，而是我能够跟非技术的管理人员有非常好的沟通，像当时公司的产品销售、高管们非常乐于来跟我沟通一些商务上的事情，觉得我是极少的这些技术高管里面，能够听懂他们讲话，也能把事情讲成他们听得懂的人。

很多矛盾其实跟沟通方式有关。在最开始建立信任的时候，是要非常小心的，不能指手画脚，可以从问问题开始。假设自己的想法是错的，让他们去帮助我了解，我自己是不是想错了？当他们在寻找答案的过程中，突然意识到这个想法其实是对的时候，这个就变成是他的主意，这时候他是会非常开心的，他也不会觉得是我给他贡献了一个主意，因为我只是问了他问题，就让他自己说出了好像他自己想说的话。其实说服别人的最好的方法就是，让他自己想到你的好主意，然后他也不觉得这个主意是你想到的。

极客时间：您为什么会选择回国加入上上签？
陶真：因为这是个非常好的行业，电子签名可以帮助中国企业提高很多的效能，可以帮助他们做到很多以前做不到的事情。从大的方向来看，电子签名也可以帮助中国的整个商业环境提高诚信。增进了诚信之后，所有的商业成本都会有一个很大的降低。当然另外一方面通过电子化的这种方法，把合同电子化、线上化，也保护了环境，少用纸张就是减少树木的砍伐。我觉得无论从大的理想，还是从大的宏观环境都对整个中国商业的发展有促进作用。

极客时间：您加入了上上签之后做了哪些具体的工作，帮助业务上实现了那些突破？
陶真：从公司的技术架构方面，我们做了简化，我们在云计算成本、创新能力、维护成本、高并发能力、帮客户提供价值的速度上，都取得了非常大的突破。我们的区块链存证技术是业界第一个自主研发的电子合同全链路区块链存证应用。我们植入 AI 技术帮助客户更好的管理合同。截止 2019 年 3 月，我们的电子签名系统可以支持 4000/ 秒的高并发签名，最高日签署量突破了 2100 万。我们也在银行、金融、供应链、制造、零售、人力资源、物流、租赁、互联网创新等各个行业和场景的使用中获得了大量代表性客户。

在云计算能力的使用方面，我们把所有的技术做了简化，对我们的团队创新能力做了提升。当我们的技术团队不用去解决别人已经解决好的问题的时候，我们就可以专注在自己的业务上面，可以更多地去倾听我们客户的声音，然后跟客户一起做联合创新。跟合作伙伴的配合上面，我们有一个非常明确的原则，如果我们要做的一件事情不是直接帮助我们的客户得到价值的，或者我们不卖这个零部件的情况下，我们是不自己去研发的。

比如一些在线编辑功能，我们可以选择自己去做，但是已经有人专门卖这样的商业化的技术，提供这样的 API，我们就直接通过合作的方法把这些技术能力做一个引进。这样我们可以在合同管理、电子签名、相关加密以及法律支持这些方面做更多的一些创新。所以我们把一些自己不该做的事情都停掉了，并且通过引进技术很快地得到助力，并把这些价值提供给客户。

我们做的另外一个很大的改变就是让各个部门的协同做了一个增进。没有任何一个部门是可以独立地为客户去创造价值的。产品团队、各个技术团队、客户成功部门、销售部门以及市场团队的日常沟通，都在保证我们有创新的源泉。从这个角度来讲，这样的调整不应该比技术上面的一些重大调整要低一个优先级。

极客时间：您的工作经历中很多都是同时负责产品和技术，那对于技术人员的职业规划，您有什么建议吗？
陶真：技术人的规划应该有两个方面，除了要不断地自我提升，学习最新的、最前沿的技术能力，还要去对问题好奇，去了解自己的技术是被如何使用，可以解决哪些问题。

当我们并不了解自己的技术是怎样解决问题的时候，就把技术和产品分离开甚至对立起来了。好比我们有一把锤子，我们不是一定要去找个钉子，而是要去了解，我们找到的是一个钉子还是一个螺钉，如果是螺钉，我们必须要有螺丝刀的能力。有些工程师太喜欢自己的解决方案、太钟爱自己的技术了，以至于忘掉了要解决的问题是什么，客户的痛点是什么？当他有一个特别强有力的锤子的时候，他把什么东西都当钉子看，其实有时候我们需要的可能不是一个锤子，而是一个扳手。

很多时候我会提醒我们的产品和研发团队，要爱上问题，而不是爱上我们的解决方案。学会从客户痛点的角度出发，而不是从解决方案的角度出发。当了解了问题以后，我们可以用最切合的、最高新，甚至是最简单的技术，给客户做好一个解决方案。所以，我觉得技术人不仅技术上要有不断的突破，了解我们解决的问题是什么也十分重要。只有这样，才能把最切合的技术，用最适合的方法去提供一个解决方案。这是我觉得在成长中最受益的一个自我训导。

大咖对话 | 韩军：CTO转型CEO如何转变思路

你好！

本周作客“大咖对话”的嘉宾是欧电云创始人兼 CEO 韩军。创立欧电云之前，韩军曾担任 1 号店 CTO，从零开始打造了 1 号店技术系统，支持 1 号店业务每年数倍的业绩增长。

极客时间：先简单介绍一下您自己吧？

韩军：大家好，我是欧电云 CEO 韩军。欧电云致力于为企业量身打造专业的新零售、新流通、全渠道数字化解决方案，提供全品类的电商产品、全渠道的流通管理、全终端的用户触点。在后 ERP 时代，以大中台，小前台，轻后台为核心的理念指引下，以强大的技术实力为驱动，为企业产业转型升级提供技术支撑和战略咨询。

技术的价值不完全由技术本身来决定的。因此，我希望做一家商业型的技术公司，把技术作为生产力直接输出，让技术能以一种直接的方式来生产价值。从这个想法出发，我选择了创业这条路。

极客时间：您怎么看待技术与业务之间的关系？

韩军：任何技术最后都要跟业务相结合，在我看来，当今世界上是没有纯技术的概念的。哪怕你研究的是导弹技术，也需要跟导弹的设计成本、最终目标相关联，这其实也是业务的范畴了。所以，CEO 一定要对业务有绝对的把控能力。

我之前提到欧电云想要将技术作为生产力直接输出，输出也是为了解决电商系统产品研发和运营中的各种问题，是有具体业务依托的。

为什么互联网在中国发展比较快？因为中国的需求比美国更旺盛，而旺盛的需求驱动了行业、技术的快速发展。技术则需要解决人们的这些需求，从这个角度来讲，业务是核心，当然技术也是必不可少的，技术是解决业务问题的手段。

具体来说，技术解决的是 How 的问题，而业务解决的是 What 的问题，两者的重要程度其实很难区分，但从哲学的角度来讲，肯定是先有 What 再有 How，次序肯定是先有业务再有技术。

我们常说技术领导力，纯粹的领导力的定义已经有很清楚的定义了，很多 MBA 的课程也在讲，但如果从技术的角度来看领导力，最重要的就是你能够将业务与技术结合，能用技术的手段把问题解决、把事情做好，这是技术领导力的一个重要体现。

极客时间：创业做 CEO 和之前做 CTO 时有什么区别？

韩军：这两者之间的差距还是蛮大的，以我的经验来讲，CEO 是提出目标方向的人，CTO 则负责将 CEO 提出的目标方向分解，然后用技术的手段去实现，也就是 CEO 解决的是 What 的问题，CTO 解决的是 How 的问题。

首先，原来做 CTO 的时候，我只用关注技术本身就好，想的更多的是如何用技术手段去解决商业中的一个个问题。但创业成为 CEO 之后，需要更多的去关注技术和商业之间的关系。另外需要考虑的事情也变得更多、范围更广了，有时候不能简单的只想着把事情做好，而是要考虑平衡各方面的因素，对平衡感的要求会更高一些。

其次，当你是 CTO 的时候，尽管也会遇到各种难题，但你背后永远还有 CEO 在支撑。当你成为 CEO 之后，你就是最后一道线，问题到了你那儿必须得解决，不管这个问题是不是真的有正确答案，你都得给其他人一个解决方案。这两者给人的感觉是非常不一样的。

最后，相对 CTO 来讲，CEO 会花更多的时间在公司外面。原来做 CTO 的时候，可能我 90% 的时间都是在公司内部解决各种问题，但现在创业做 CEO 之后，我花在内部的时间可能只占 40%，剩下的 60% 都是在外面解决各种各样的问题、寻找各种各样的机会。所以，怎么更好的管理自己的时间，内外部怎么更好的协同，也是一个非常大的挑战。

极客时间：技术人创业需要注意哪些问题？

韩军：从技术的角度来看，技术人创业，首先要把握好技术本身的核心，这是你的立足之本。

其次，技术人要转变自己的思维和视角，就像上面提到的，不能再纯粹的从技术的角度看问题，面要更广，更多的要从商业角度或公司运营角度来看问题。

毕竟，原来你可能是解决 How 的问题，但创业之后，你更多的要去解决 What 的问题，也就是公司的方向、目标。原来可能是 CEO 给你一个命题，你去想办法解决这个命题，但创业之后，你要自己去提出对公司发展至关重要的命题，然后让下面的人去解决，这就考验你对行业、趋势、战略的把握程度。这是两个不同的角度，需要注意转换。

以前做 CTO 的时候，很自豪自己能解决各种各样的问题，但现在创业之后，关键能力不再是如何解决问题，而是能让别人解决问题，能让自己的团队围绕自己定出的 What 而努力，竭尽全力的实现这个 What，为目标拿分，这个能力变得更为重要。

最后是薄弱能力的补足，在角色转变的过程中，作为创业者你需要不断去学习以前没有的技能，因为相对来讲，技术人的软技能会欠缺一些，比如沟通能力、对商业的认知能力、获取外界帮助的能力等，当你创业后，这些薄弱面都是需要你去补足的、能力提升的。

极客时间：如何正确应对创业过程中的压力？

韩军：创业的压力肯定是很大的，经常有想创业的人会来问我创业相关的问题，很多时候我都会泼他们冷水，因为创业是一件压力很大的事情，很多人都没有真正准备好。

具体来说，一个是经济上的准备，一个是精神上的准备。尤其是精神准备，很多人以为自己准备好了，其实并没有。创业真的是一件九死一生的事，之前做了再多的准备，过程中还是遇到各种意料不及的困难，承受诸多难以想象的压力。

因此，你创业的初心一定要是做你真正喜欢的、热爱的事情，而不是为了赚钱。赚钱是创业成功之后必然会获得的回报，但它不应该成为你创业的初衷。

因为热爱，你才会全情投入，就不会计较一时的得失，也就不会被压力压块。即使遇到困难也会是痛并快乐着，因为你证明了自己，你解决了很多用户的痛苦，你为社会创造了价值。这样，就算失败了又怎么样呢？你可以选择再来一次或者不，这是你喜欢的事情，你真正经历体验了这个过程，而人生就是在不断的经历。

于我而言，因为现在做的是自己感兴趣的事情，也全身心投入到这件事中，只想着怎么把它做好，就不会太在意压力了。另外，即使遇到难题，我更关注的也是怎么去解决这个问题，而不是沉浸在痛苦和压力中，算得上是乐在其中了。

大咖对话 | 项目成功的秘诀——技术产品双头负责制

你好！

本周作客“大咖对话”的嘉宾是 360 商业化 CTO 胡宁，她也是 360 聚效联合创始人、首席技术官。在此之前，她曾担任谷歌技术总监，先后领导主持了移动搜索、谷歌音乐及 Android 云服务的研发。今天，我们和她聊了聊技术人的产品思维。

极客时间：您负责 360 的商业产品，在技术产品化方面，您有哪些心得？

胡宁： 这跟我之前的经历有关，我原来在谷歌做工程师的时候，做的一直都是用户产品，从移动搜索，到谷歌音乐，再到安卓云服务，都是跟用户打交道。众所周知，谷歌是典型的工程师文化，工程师的话语权会比较大。那些在别的公司只需要产品经理考虑的事情，在谷歌，工程师也要参与，而不是产品经理一个人说了算。

那时，我就形成了一个观念——一个优秀的工程师，不光技术能力要强，还需要有非常优秀的产品感觉。

后来我出来创业之后，也一直是产品、技术两个一起管。在这些年的创业过程中，关于项目管理、产品管理，我也摸索出了一些自己的心得，那就是技术产品双头负责制。

一般做互联网产品，很多时候都是由产品经理或项目经理去负责整个产品，技术相对来说是一个接收需求、开发需求、实现需求的处于后方的位置。但在我看来，一个产品真正要获得成功，并不只是产品设计的问题，怎样以更低的代价、更系统化的路径去实现它，也是很重要的，而这就需要有工程师的积极参与。

所以我们会提倡技术产品双头负责制，由技术负责人和产品负责人一起承担整个项目，包括该开发什么功能、功能要做成什么样子、怎么设计、该用什么样的架构选型、怎么开发、怎么做测试排期、什么时候上线等一系列工作。

只不过他们会各有分工，技术负责人会更偏向内部，会更多的做一些开发排期、技术架构设计等工作；而产品负责人会更偏向外部，比如需求收集、跟各部门的沟通等。经过我们这么多年的实践，这样的一个机制是能比较有效的保障产品、项目成功的。

可能有人会问，两个人一起负责，会不会产生争议和矛盾，毕竟在传统框架中，技术和产品本身就是容易有矛盾的两个角色。这点其实不必担忧，我们在实践的时候，会保证技术负责人和产品负责人的目标是一致的，例如他们的 OKR 就是彼此先沟通商量好的。

有了这些确定的目标，他们两个人就需要一起负责，无论是做成还是没做成，都需要他们两人带领团队去一起承担。而在目标一致的情况下，很多分歧就不存在了，看的就是要做的事情是否对项目有好处。

原来技术和产品容易产生分歧，很大程度上，是因为大家权责不清晰，出问题的时候，老想把锅甩到对方头上，但在技术产品双头负责的制度下，这锅只能双方一起承担，想甩都甩不掉。在我们做出这样的调整之后，技术和产品的关系反而融洽了很多。

极客时间：技术人应该怎样提升产品思维？

胡宁：第一点，积累足够的行业经验。 产品与其所在的行业、领域是紧密相关的。技术人要想提升产品思维，首先就是要积累足够的行业经验与知识，需要真正沉浸到行业里去，踏踏实实做上几年，才能领会其中的关节与窍门，理解核心的商业逻辑。只有这样，才有可能做出优秀的产品，否则就是天方夜谭了。

第二点，要有全局观。 我一直倡导技术人不能局限在自己的岗位上，而是需要站在一个更高的层面上，从全局出发去看事情，去看产品整体到底是什么样的、之后要走什么样的方向，而为了支撑这样的方向，技术架构、技术选型又要怎么做等。这其实也呼应了第一点，有了较为丰富的行业经验作为基础，才有可能站在全局的角度去看问题。

第三点，技术本身不能丢。 这一点回到了技术本身，是因为一个好的、能满足用户需求的产品，最终还是要落到各种技术指标上的，比如页面响应时间多少、互动操作是否流畅、用户点击率是否能提升、能承担多少同时访问的用户数等。而这其中各种优化工作的完成度，最终还是取决于技术水平的高低。所以技术人的产品思维还得有很强的技术积累作为支撑。

极客时间：你认为具备哪些素质才是一个优秀的技术管理者？

胡宁： 一个优秀的技术管理者需要具备以下素质：

第一，技术水平得非常扎实。 在技术领域，做纯粹的人事管理是很难服众的，必须有很强的技术能力，才能服众，才能带动团队。因此，我原来培养一个人的时候，很多时候都是要求对方从基层做起，去展现他的实力，去以技术服人。工程师是相对比较单纯的群体，如果真觉得你实力很强，他们是会佩服你、敬仰你，愿意跟随你的，这是非常重要的一点。

同时，我也不希望一个技术管理者就纯粹的只做管理，当然我也不是强硬地要求他们做了 leader 之后还要写代码，但我希望他们仍然能够亲力亲为地去处理一些问题、尤其是难题，而不是把事情完全推给下属，这样的管理者，不会是优秀的技术管理者。

第二，要有同理心。 我最近看了微软 CEO 纳德拉的《刷新》一书，我很赞同其中的一个观点——管理越往上走，越需要有同理心。之前我把这些归纳为沟通能力、情商等，但更深层次去挖掘后，发现它们本质上就是同理心。

同理心就是你是否能理解别人的立场，是否能站在别人的角度去考虑问题。还是以技术和产品为例，我们很多时候都会听到技术抱怨产品又改需求啦、产品又把锅甩过来啦，但如果站在产品的角度，他们只是想把产品做好，做各种调整是为追求理想的最终结果。如果双方都理解对方的立场，技术把做好产品当成彼此共同的目标，产品能看到并体谅技术的实现难处，那双方的摩擦和埋怨就会少很多。

因此，优秀的技术需要拥有这样一颗强大的同理心，只有真正站在别人的角度看问题，才能找到大家都能接受的解决方案，大家的劲儿才能往一起使。

第三，要具备领导力。 技术管理中是有管理职责的，每个人的管理风格都不一样，我能理解并尊重，但是需要保证你的管理风格是能被团队接受并适应的，能让团队运转工作起来，这个被我称为领导力。

在管理团队时，每个人的性格不一样，管理者不能要求所有人都按照一个模子去做，否则很可能会引起反弹，这又呼应了第二点，看管理者是否具有同理心，是否能站在团队成员的角度去考虑问题。

当然，不是所有的技术人都适合做管理，有些人由于性格、情商等原因，可能更适合做 IC 独立贡献者（Individual Contributor），这也是很好的发展路径，并不是非得走技术管理这条路的。

极客时间：您具体是如何培养团队 leader 的呢？

胡宁： 管理团队，我有我自己摸索出来的一套流程和模式，比如我会用 OKR，会用之前提到的技术产品双头负责制，会做公开透明的绩效考评和互评，还会建立一系列技术开发、产品开发的规范和流程等。

在培养团队 leader 时，我一般会扮演一个教练的角色，会给对方建议，怎样才能成长，需要做哪些事情，哪些方面还需要继续加强。比如我会在某个 leader 成长到某个阶段后，建议他做团队梯队建设，为什么要做，大致要怎么做。

另外，他们在管理过程中遇到各种各样的难题和困惑，会随时来找我、或在 1-on-1 沟通时问我，我也会尽力给对方提供我的经验和建议。例如，团队里两个相对资深的小组 leader 之间有矛盾，团队管理者要怎么处理；或者如何劝退一个不能胜任工作的团队成员。我会跟他分享我以前遇到过的类似情况，以及我的处理经验。但我只会以教练的身份去引导他，跟他讨论，给他建议和提示，而不会指手划脚的告诉对方该这么做那么做。具体该怎么处理，主动权应该握在他手里，这样才能最大限度的让他获得锻炼和成长。

最后，在我看来，技术管理是个经验科学，管理者一定要通过实践去尝试、去体验，最终沉淀出属于自己的管理经验和管理风格。

大咖对话 | 顾旻曼：投资时我们更多地是在找优秀的团队

你好！

本周大咖对话的嘉宾是真格基金董事总经理、华东区负责人顾旻曼。顾旻曼是真格基金早期员工， 在此之前，曾任职盛大创新院，负责战略投资业务。加入真格基金后，主导和参与投资了 60 多个项目，如即刻、青藤云安全、达观数据、燧原芯片、Papi 酱等。

有人说，这是技术创业最好的时代，在互联网下半场的浪潮里，什么样的企业能得到资本的青睐？资本的注入对企业、对技术创业者来说会带来哪些影响呢？对此，顾旻曼坦诚地分享了所在赛道的投资情况、自身的投资逻辑以及对相关投资案例的解读与看法。

极客时间：您的投资理念与投资逻辑是什么样的，能与大家分享一下吗？
顾旻曼：在投资时，真格会比较偏向于选择优质的、专业的团队进行早期投资。

拿 papi 酱来说，在对 papi 酱团队进行投资时，我并没有预想到它会红极一时，当时传统线下艺人的生态已经比较成熟和坚固，而线上尤其是网红群体能够更接近于商业转化；同时，在这个行业里要找到一支高素质的从业者队伍非常难，而 papi 酱团队中的三个人是中戏同学，各自的经历也非常丰富，他们也做过游戏创业、经纪人业务，本身也可以从事内容创作，这样的组合非常罕见，也比较打动我。

其次，我们很少追风口，客观上来讲，风口起来了价格也偏高，当然真格可能无意间提前进入了一些风口。我们更多地是在找优秀的团队。

比如我们 2013 年投了依图科技，当时 AI 这个概念还没有出现在大众的视野中，更不用说所谓的风口，而如今，依图科技已经成长为 AI 独角兽，在智能安防、智慧医疗、智慧金融、智慧城市、智能硬件上都有不俗的表现。

真格当时之所以选择依图，是因为看中了创始人朱珑、林晨曦组建的团队。当时，朱珑在麻省理工学院担任博士研究员后回国，此前一直专注在机器智能研究上；而林晨曦在阿里巴巴搭建了国内最大的拥有自主知识产权的飞天分布式云计算操作系统，擅长的恰好是人工智能算法工程化和产品化最需要的大规模并行计算系统。

这种组合的团队，我们觉得应该要支持，但当时并没有说规划要投 AI 赛道，那会儿也还没有这个赛道，我们只是看重了这个团队。

类似的例子还有很多，比如说投找钢网，当时还没有这样一个专门的风口出现；青藤云安全也是，它是一家做安全的企业，近一两年才获得了很多的关注。

而对于个人偏好来讲，我会对创业者有一些期待，希望他们有充分的积累，不管是过去在学术技术上的积累，还是在产业里面的积累。创业是对过去积累的势能的一次变现，也就是说，创业者要清晰地知道自己为何而来，并且不会因为一时的市场起伏、资本的追捧或是冷落就有任何变化，他们需要知道自己将创造什么。

极客时间：在您看来，一个优秀的投资人需要做到哪些？
顾旻曼：作为一个投资人，首先从心态上就要摆正——不能要求创业者一帆风顺，在他做得很好的时候就高捧，在遇到困难和挣扎时就贬到一文不值。

创业成功与否是由很多因素共同决定的，作为投资人，我们能够把握的是团队的选择和对当时市场方向的预估，而最后结果的好坏主要看两点：一是看自己的判断力是否准确；二是创业讲究的是天时地利人和。尽可能减少因主观的判断力而导致的投资失败，是对创业者、对自己负责的表现。

其次，投资者自身需要成长，我每次复盘都会觉得自己可以做得更好，会觉得自己对于商业本质的判断、对于产品的理解和认知、对于团队的人的理解和认知都不断在上升，但永远还有进步空间。

另外，投资者需要有自己的核心投资理念，拿我来说，不管是投资哪些方向和行业，从前几年投 ToC 互联网产品方向，到内容文娱，到后数据安全、ToB 方向，我一直以来关心的核心都没有发生过变化—— 技术怎么样改变这个世界，我怎么样帮助技术改变世界，让人们的生活更美好。这是我做投资的使命感，投资不同行业，只是在不同阶段的不同形式呈现，我期待的是从泛互联网技术到硬科技对商业世界、对生活的改变。

接下来，我还是会持续关注科技方向的创业公司，包括大数据、AI、产业互联网相关的比较多一些，现在互联网走到了更加硬核的地步，我也会看更加硬核一些的项目。

极客时间：行业女性投资人会比较少，这个对您来说会有什么样的影响吗？
顾旻曼：我觉得用性别给自己打标签，要不就是偷懒，要不就是自我限制，我从来不给自己打性别标签，客观上来讲女性思维或者男性思维因人而异。

而至于女性在职场上会出现劣势，很多时候不是因为能力问题，而是需要女性加倍地去证明自己，这是一个现实。但首先可以先做好自我，女性不管是作为投资人，作为媒体人，作为任何一个职场人，只有你发挥出很大的能量，才会影响一些雇主对女性的“偏见”，后来者才会给更多的女性更多的机会，永远不要让公司觉得雇佣女性有很大的风险。

极客时间：刚才提到您自身的成长，那在成长的过程中，是否有经历过至暗时刻？最后是怎么走出来的？
顾旻曼：我觉得没有一个至暗时刻，但有很多时候会否定和怀疑自己。比如说每年的复盘，或者说回看自己两三年前做的一些决定，不管是从投资方向的选择、从团队的判断、从某个项目的参与度来说，我永远都觉得自己做得不够。

我会很多有很多的反思，很多时候自己会有一叶障目的感觉。我现在处在投资人的身份和位置，业绩表现和努力工作这些是正常的压力，老实讲，很多时候我的压力没有创业者那么大。但我觉得很多时候压力是原生的动力，才能让自己成长得更快。也就是说，你如何在自己的小世界里做得更好，如何让自己获得更大的视野，以此在更大更残酷的市场里成长，是非常关键的，也是自己需要时时反思的。

大咖对话 | 高斌：过分渲染会过度拉高大众对人工智能的期望

你好！

本周大咖对话的嘉宾是高斌，现任微软总部必应搜索广告部门首席机器学习科学家，此前曾担任微软亚洲研究院机器学习研究组主任研究员，主要从事机器学习、信息检索、数据挖掘和计算广告等领域的研究，在国际顶级期刊和会议上发表相关论文 40 余篇，持有 30 余项美国专利，其指导的论文曾获得国际信息检索大会 (SIGIR) 最佳学生论文奖。

在做研究的同时，高斌博士十分重视和产品部门的合作，将十多项技术转化到了必应搜索、必应搜索广告、微软小冰等产品中。也是在这个过程中，高斌博士对应用型研究产生浓厚兴趣，因此申请转到产品部门，成为了微软总部必应搜索广告部门的首席机器学习科学家，将前沿的机器学习技术应用到产品中，同时针对具体应用研发新的算法模型，改进产品性能。

Q：您认为目前影响人工智能落地的因素有哪些？
高斌：我认为目前影响人工智能落地的因素主要有以下三个方面：

第一，明确技术应用的边界和程度。虽然人工智能技术发展日新月异，但是目前能够解决的问题还是有限的。我们要弄清楚在一个应用场景中哪些部分是人工智能技术可以解决的，可以解决到什么程度，哪些部分不能解决。然后针对应用场景的需求期望来决定哪些部分使用人工智能技术以及使用何种人工智能技术。这样才能最大的发挥技术功效，并且避免因为一些不切实际的幻想破灭而造成的负面影响。

第二，提升数据的质量。人工智能技术尤其是深度学习技术需要依托海量数据来进行模型训练。我们需要针对具体的应用问题来对数据进行选择和处理，包括对数据量的积累、对多种类型的数据进行取舍、对数据进行降噪、对数据内在关联进行分析和利用等。在这个基础上，才能更好的建立模型并提升模型学习质量。

第三，提高工程实现能力。虽然近年来高性能计算硬件的发展和普及非常迅猛，高水平的工程实现能力依然是影响人工智能落地的重要因素。一般来说，数据量、模型尺度的增长速度还是大于硬件发展的速度的，高水平的工程实现能力可以最高效地在硬件计算资源、数据量和算法模型之间找到平衡点，实现人工智能技术的落地。

Q：您觉得大众对人工智能的认知偏差大吗？这种偏差会对行业造成哪些影响？
高斌：我觉得大众对人工智能的认知偏差普遍比较大，出现这种偏差有多方面的原因：艺术作品的先入为主、对大众的人工智能知识科普的不足、媒体的过度渲染、部分从业人员的炒作等等。这种偏差的影响也是多方面的。
第一个影响是大众的恐慌。比如人工智能取代人类，人工智能导致失业率升高等等，这有可能会导致社会上对人工智能的一些恐慌，一些人可能并不太了解人工智能在做什么，而是盲目的反对和否定，这当然会影响行业的发展。其实，虽然人工智能技术确实会导致某些职业岗位的需求量大幅下降，但是同时也会创造一些新的职业类型，人力资源会向新兴的岗位流动。
第二个影响是大众的失望。过分的渲染和炒作会过度拉高大众对人工智能的期望值，当项目或者产品投放市场以后，如果产品的实际表现和宣传相差过大，大众就会大失所望而可能抛弃产品并且对人工智能产生质疑，这对人工智能技术和产品的改进和推广都会带来一定的负面影响。

Q：您觉得未来人工智能会成为一种什么样的存在？
高斌：我觉得人工智能在未来会回归它原本的位置，成为人们比较关注的几个前沿技术领域，并会不断地带来改变人们生活的新技术。

Q：在您看来，什么样的企业应该发展人工智能技术？
高斌：我觉得与数据相关的企业都可以发展人工智能技术，只是不同企业的发力点可能不一样。有的企业可能注重人工智能技术与传统行业的结合来进行技术升级和创新，有的企业可能注重对人工智能关键技术的本质突破，有的企业可能注重人工智能在某个非常具体的应用场景的创新。

Q：您在人工智能领域深耕多年，对于刚开始学习人工智能的技术人有什么建议？
高斌：首先是要打好基础，数学基础、计算机基础、编程基础都要扎实；然后就是选择一个方向，人工智能领域里面课题众多，要结合自身条件、个人兴趣和行业发展选择适合自己的方向；再就是要紧跟技术的发展，人工智能领域技术更新迭代速度很快，稍不留神就会被落在后面。

Q：未来人工智能在金融领域的应用场景有哪些？您最期待的是哪个场景？
高斌：在金融领域，人工智能可以应用于收益预测、投资组合构建、风险管理、金融产品推荐等方面。我本人最期待的应用场景是投资组合构建。

Q：在很多年里，普通人对人工智能的印象主要来自一些机器人电影，过去您看那些机器人电影的时候是什么感觉？
高斌：我听说过，有些人看了某部科幻电影之后便立志投身人工智能领域改变人类，一部电影成了他们人生的转折点，从此开启了开挂的人生，我很敬佩他们。我很喜欢电影，不过对于机器人题材的电影倒是没有什么特别的偏好，我更加关注的是电影故事所引发的思考。对于机器人题材的电影里面展现的一些有关人工智能的情节，我有时会想哪些是有希望实现的，是否还可以联想到一些类似的有意思的应用，哪些不过是人们美好的想象，仅此而已。而对于整个故事所引发的思考我倒可能会时不时反复回顾。

Q：发展人工智能技术一定需要人才支持，您通过什么样的方式吸引人才的？
高斌：对于人才的吸引，我们主要通过以下三个方面。一是对外进行宣传，比如我们会在一些学术会议、产业会议等技术交流活动中展现我们的技术实力、宣传我们的产品性能，从而吸引人才的加盟；二是通过实习生项目从在读的硕士研究生和博士研究生中筛选高水平技术人才；三是通过一些前沿的有挑战性的项目，来吸引内部人才的流动。

Q：可以介绍一下微软必应搜索广告部门现在的技术人才团队吗？
高斌：微软必应搜索广告部门的技术团队主要分为三种角色。一是软件开发工程师（software development engineer），主要负责产品系统构建、模块开发、技术维护等；二是数据科学家（data scientist），主要负责各种数据的处理、分析、挖掘、预测、决策等；三是应用科学家（applied scientist），主要负责针对具体问题进行分析，运用、改进或者发明机器学习、数据挖掘、信息检索等领域里的技术来对问题进行建模、实现相应的算法并嵌入到产品系统中。

Q：您和其他部门的负责人在工作中会发生观点不一致的情况吗？一般会怎么处理？
高斌：工作上发生观点不一致的情况是比较常见的，一般来说我们会通过协商解决。这里可能有多种不同情况，如果项目目标不一致，那就要看多个目标是否可以分阶段完成，是否可以双方都做一些妥协做一些取舍；如果是在目标一致的情况下项目执行方案不一样，那就要论证每个方案的可行性并根据一些衡量标准来做出大家都认可的选择。总之，需要具体问题具体分析，在大家本着解决问题的态度下，进行协商和互相之间的妥协。

大咖问答 | 发现下一个小米，不是只能靠运气

你好！

本周与我们对话的嘉宾是迅雷创始人程浩。2018 年 5 月，程浩宣布和田鸿飞、江平这两位硅谷老友共同创立新一代技术型 VC「远望资本」。迅雷是中国互联网企业中典型的强技术创新基因公司，从企业家转型成为投资人，这样的经历让程浩更愿意投资有技术创新背景的公司。

对于技术人如何选择创业赛道，以及如何加入一家前景光明的创业公司，程浩根据自己多年的经验，给出了一些非常中肯的建议。

Q：远望资本强调投资要“聚焦赛道”，那么对于技术型人才来说，创业应该怎么选赛道？

程浩：其实技术人选赛道的逻辑跟其他人群是一样的，首先要建立在一波大势、一波红利之上。我过去的经历告诉我，这样做绝对事半功倍，否则只会事倍功半。举个简单的例子，早期在开放平台上发展起来的公众号、微博大 V 等，都是借助了平台早期红利，现在再做微信公众号，涨粉是非常困难的，因为红利已经过去了。

BAT 为什么能成功？迅雷为什么能发展起来？一个是中国的人口红利，一个是宽带迅速普及带来的红利。小米为什么能崛起？是智能手机的这一波红利。简言之，有红利才能发展的快。如果说现在创业，还做互联网，或者移动 App，你要面临的第一个问题就是怎么获客，去 App Store 买流量吗？根本不现实。

2000 年之后的大势是互联网，2010 年之后的大势是移动 App，在我看来，现在的核心赛道一是人工智能，这也是远望资本关注的重点，我们高度关注人工智能在汽车、机器人、零售、金融等领域的应用。二是微信小程序，这是 to C 的又一波社交流量红利。

对于 VC 来讲，选择赛道是战略层面的问题，投后管理是战术层面的问题。我觉得技术人创业跟一般人创业一样，都应该选择最有红利的赛道，这不是机会主义，而是历史经验的总结。赛道没选对，你再聪明再努力，都不会发展得很快。

Q：根据你的观察，技术创业容易踩哪些坑？

程浩：首先技术人创业，不要执着于技术主导，也就是不要有必须当老大的心态。行业是第一位的，如果这个行业是运营驱动的，那 CEO 必须是擅长运营的，如果这个行业是产品驱动的，那么产品经理应该是 CEO，当然如果这个事是技术驱动，那么懂技术的做 CEO 最合适。简单来说就是，CEO 必须得是这个项目的核心竞争力。你作为一个技术大牛，不要因为必须要做老大，而选择自己不擅长的事情，也不要选一个虽然自己擅长但是发展很慢的行业。 正确的姿势是应该首先选一个高速发展的行业，然后缺什么补什么，如果这个行业运营驱动，你找个懂运营的做 CEO，自己做二把手是最好的。

另外我建议创业之初一定要把利益怎么分配约束好，所有的事情都根据协议走。大家开始创业时都在兴头上，不愿意讨论这些事，结果到最后往往就各有各的解释，容易扯皮。有经验的创业者都会有协议约束。如果是新手，就要考虑把所有的内容都先写清楚，比如万一谁中间离开了，资产怎么处置。

总之提前写清楚，是保护他们的最好方式，但这要求你必须能拉下面子。这里面有心理的问题，也有经验的问题，特别是对于第一次创业的人，他不知道要做这个事情。当然站在 VC 的角度上，我建议大家坚持到革命成功，不要中途退出。

如果一个企业的联合创始人比较多，我们通常会建议 CEO 做一个有限合伙企业，其中 CEO 作为 GP（一般合伙人），然后其他的所有联合创始人和员工股东都作为 LP（有限合伙人），这样资本结构比较简单。

在技术团队的考核上，我觉得如果是 to C 就必须得是用户导向， to B 就必须得是客户导向，记住永远都不能纯技术导向。我举个最简单的例子，我们之前做迅雷看看的时候，就犯了这样的错误。迅雷是个非常技术型的公司，我们当时定的 KPI 就完全是技术导向的，也就是看传输的总数据量上 P2P 所占的比例，这完全是错的。

而若以用户体验为导向，应该是缓冲时长要尽可能的短，中断率要尽可能的少。虽然 P2P 的比例越高，带宽占用率就越低，我们的成本就越少，但这不是用户想要的，用户不 care 你的成本，只关心看视频流不流畅。我们的竞争对手就直接用服务器抗，成本很高，但是比我们流畅。所以技术很重要，但技术不是目的，而是手段，最终的目的是服务用户。大家要注意不要为了秀技术而使用技术，而是要让你的技术为商业服务。

还有一点，技术型创业公司如果不直接面向用户 / 客户提供整体解决方案，则非常容易被上游碾压。如果单做技术提供商，你的技术壁垒不够高，上游很可能直接把你的事做了，这样的例子比比皆是。即使在有一定技术门槛的行业，技术提供商的日子也不好过，高通和 MTK 这几年日子都不好过，因为苹果、华为、三星、小米有了规模效益都在做自己的芯片。做技术提供商最怕上游太集中。还有被 Intel 收购的 Movidius，专注嵌入式的视觉处理芯片。之前大疆无人机是其主要客户之一，但大疆统治了消费级无人机市场，很自然的开始做自己的芯片。这其实是一个产业链通用规律：如果一个产业链有很多环节，在某一个环节有一个垄断者，那么这个垄断者就有向上下游延展的机会，即使不延展也会把整个产业链的大部分利润吃掉。

Q：最近传闻小米上市将造就一批亿万富豪，大家纷纷表示很羡慕。有没有什么方法，能够在早期发现小米或者 BAT 这样的公司？

程浩：技术人员应该跳出技术这个圈子，从用户思维或者从行业思维去考虑会更有价值。像现在的滴滴打车、饿了么，都不是强技术驱动的，而是强运营驱动的。如果你是一个技术人员，在早期选择企业公司的时候，是应该选择滴滴这样的公司呢，还是选择一家技术主导的，但市场不大的公司呢？答案是显而易见的。

技术人员有时会感觉如果技术在这家公司不是最主导的，我就没价值，或者我就不感兴趣，这是个误区。我觉得做任何一件事情，技术应该都是让位给商业需求，这个顺序是很清晰的。首先先是选行业、选赛道，其次才是技术在中间占的比例有多大，如果行业都错了，技术占百分之百也没用。

所以技术人员应该是先找一个高速发展的行业，然后在其中选一个高速发展的企业，其次才是薪资待遇之类的其他东西。不同公司提供的薪水不会差太多，大家未来都靠股票，但是股票就完全取决这家公司做得怎么样。 最好的机会当然是能够进 60 人时的百度，或者 100 人时的小米，但是这个真的只能靠运气。但是如果你坚定的看好一家公司的时候，就可以有目标的去加入。对于 BAT、小米、头条来讲，1000 人规模时加入一点也不晚，这不需要靠运气，更多的靠自己的眼光和实力。

大咖问答 | 打造自己的个人品牌，你也可以

你好！

本周与我们对话的嘉宾是极客邦科技创始人兼 CEO 霍泰稳。霍泰稳在过去的 15 年职业生涯当中，基本都在和技术人打交道，不管是技术媒体 InfoQ 中国还是高端 CTO 圈子 TGO 鲲鹏会，在这中间，他见证了很多技术人的成长之路，深谙影响力对于一个人发展的意义。

本周，我们邀请霍泰稳分享他对于认知升级的独特见解，以及技术人可以通过哪些方法打造自己的个人品牌。

Q：技术人可以通过哪些方法打破边界，提升认知？

A：为了学习而学习，可能会适得其反。我认为最重要的，还是要和公司当下的业务相结合，在促进业务快速发展的过程中，让认知自然地提升。为什么有些大公司出来的同学，就是给人感觉视野很开阔，能力也很好，主要原因并不是说他们在大公司里很努力地学习，而是他们参与解决了很多实际的有挑战的问题，攀登了一座又一座技术的高山，然后回头看，就有一种“不畏浮云遮望眼”的感觉。所以，第一点就是我们脑袋里面要始终想着业务，如何通过技术的努力，让业务得到快速发展，而不是一味地埋头于自己的技术三分地。

刚才说的是如何基于业务发展提升自己，另外对于技术领导者，或者想成为领导者的技术同学，在对内对外的联结上也要多加注意。有意识地进入某一个圈子，找到能听懂你说话的人，大家经常一起切磋交流，共同成长。最近我在看《深度工作》这本书，在书中，作者就特别提到“不要独自工作”，原因是“对于很多类型的工作而言——特别是追寻创新的——协作深度工作可以产出更好的效果”“……恰当的时机可以采用协作的方式，因为这样可以推动你的成果提升到一个新档次。”我们都知道人的认知是存在盲点的，自己看不到，了解自己的人却能看的很清楚，在一个安全的氛围里，大家互相指正，可以帮助彼此定期提升认知。

最后还有一点，所谓打破边界，就是要走出自己的舒适区，要学会“跨界”。尤其是创新型的工作，不同领域的界限已经越来越模糊了，比如科学与艺术，互联网与制造，甚至零售前面要加一个“新”。不囿于当下的工作，多参加一些跨界的活动或者学习，可能会有不同的体验，不同的思考。

Q：怎样从他人的经验分享中提炼出真正对自己有价值的知识点，并在实践中运用？

A：但凡是学习，都比较讲究“次第”，也就是一步一步地上升。现在我们很多的讲座都是请行业里面的顶尖专家来分享，是很好的事情，但是在选择的时候，还是要结合自己的水平，和自己公司当前的业务发展。如果现在公司网络业务的并发量是以万级计算，你听千万级并发量的课程，对自己能有多大的帮助，我是存疑的。这时候可能倒不如听一个不是那么有名气的同学，来分享他们的业务是如何从万级并发到十万百万并发的。也就是说，学了之后能在自己的团队尽快用得上，能够学以致用。

另外就是学习了别人的经验后，一般都是当时热血沸腾，想回去马上在自己团队实施。我的经验是，先让自己冷静一下，一般以一周为宜。在这几天里，挑选团队里的个别小伙伴征询意见，看看如果自己要实施“新政”，大家是否是拥护的，是否能帮助大家真正解决问题。比如可以基于下面几个问题进行讨论：

团队目前需要改进的地方或者痛点是什么？

新的方法是否能帮助我们真正解决问题？

如果要实施新方法，会遇到什么样的挑战？

除了这个方法，我们还有没有更好的方法？

具体实施的目的、目标和步骤是什么？

还有一个办法，也是一些创新团队经常采用的，就是 MVP 法则。学到了好的方法，回到团队，我们可以先挑个小团队去试运行，看看效果。如果效果好，适合自己的团队，则推而广之，否则，就偃旗息鼓。这样就不至于动不动大动干戈，劳民伤财，而且这样的事情多了，还会损害自己作为技术领导者的信誉。

Q：技术人应该如何打造个人品牌？

A：讨论这个问题之前，我们还是要定义什么是“个人品牌”，简单来说，就是一个人带给别人的印象，以及所影响的人的范围。我们说一个人个人品牌很好，通常是说他在某一方面有专长，有权威，另外就是他还影响和帮助了很多人。从这个角度出发，我认为技术人可以从下面几个维度思考，打造自己的个人品牌或者影响力。

通过社交媒体多发表观点，尤其是针对热点事件，让自己在关键时刻不缺位。但是这个方式也有自己的副作用，如果在社交媒体上过于活跃，比如在每个群里都能看到他在说话，好像随时都在响应大家，可能会给人留下没有专注于本职工作的印象。学会“隐藏自己的实力”，多发表有见地和有理有据的内容，可以作为自己使用社交媒体的礼仪之一。

多参与有品质的会议，并发表演讲，或者写“博客 / 公众号”也是不错的办法。因为不论是一个 45 分钟的分享，还是一个 2000 字的文章，都代表着你对一个问题的深入思考，这在现在已经泛滥的浅层信息流中是比较稀有的东西，自然会受到更多人的关注。需要注意的是，不要一个内容到处讲，要克制，就好像武侠小说里面的剑客，不是随意拔剑的，剑一出手，必定置敌人于死地。如果是公司需要自己多露面，那么至少每次讲的内容要有 30% 的更新。

出书，这个我认为可能是当前最有效的建立个人品牌的方法，尤其是和一些有品牌的出版社合作。通常情况下，越是难度高的产出，越容易受人肯定。如果说公众号代表一个人当下的深入思考，出书则代表一个人对过去一段时间的深入总结，而且还要花费数月把它形成文字写出来，是代表着一种严肃的，真实的付出。所以，如果你真的想有自己的品牌，那就沉下心来，有意识地总结经验，找一个靠谱的编辑合作，写书吧。

最后我想提醒我们技术人的是，别害羞，激进一些，多站在台前发表自己的观点和言论，会更能彰显自己的价值。比如很多技术人喜欢的“左耳朵耗子”（真名：陈皓，酷壳博客的维护者，极客时间 App“左耳听风”的专栏作者），在他的文章中，常能看到对某一技术的使用经验，对某一热点的解读，拥趸无数。时间长了，他的个人品牌也出来了，现在他的“左耳听风”专栏已经快突破 7000 人订阅。人的一生，都会有属于自己的光芒闪耀的五分钟，希望你能抓住它，不让机会溜走，形成属于你的品牌。

新春特辑1 | 卓越CTO必备的能力与素质

你好，我是《技术领导力 300 讲》专栏的主编成敏，今天是除夕，先在这里祝你除夕快乐，身体健康，万事如意！

从 2018 年 4 月 16 号，《技术领导力 300 讲》专栏更新第一篇文章开始，我们已经与你一起度过了 9 个多月的时光，更新了 210 篇文章，走过了专栏 3/4 的路程。

在这 9 个多月里，我们邀请到了近百位 CEO、CTO、技术 VP 等技术领导者来分享他们的实践与经验，话题涉及技术领导者的核心能力、高效技术团队的打造、高效研发流程的建设、技术团队的考核与激励、技术团队文化的建设、技术人才的选育用留等多个方向。

这些文章虽有序但却分散在全年的专栏中，恰逢新春假期，我特别整理了 5 个热门的主题的直达专辑，以便您按照主题领域来回顾。你可以点击知识卡，跳转到你最想看的那篇文章，温故而知新。

今天专辑的主题是“卓越 CTO 必备的能力与素质”，希望你看完之后能有所收获，也欢迎留言选出你最喜欢的文章，或是分享你对于 CTO 必备能力与素质的观点。

新春特辑2 | 如何成长为优秀的技术管理者？

你好，我是《技术领导力 300 讲》专栏的主编成敏，今天是大年初一，祝你在新的一年里万象更新，事事顺心！

今天专辑的主题是“如何成长为优秀的技术管理者？”，希望你看完之后能有所收获，也欢迎留言选出你最喜欢的文章，或是分享你关于技术管理者成长的实践与经验。

新春特辑3 | 如何打造高质效的技术团队？

你好，我是《技术领导力 300 讲》专栏的主编成敏，高质效的技术团队是每个技术领导者的追求，今天专辑的主题就是“如何打造高质效的技术团队？”，希望你看完之后能有所收获，也欢迎留言选出你最喜欢的文章，或是分享你对于技术团队打造的实践与经验。

新春特辑4 | 如何打造高效的研发流程与文化？

你好，我是《技术领导力 300 讲》专栏的主编成敏，研发流程与工程师文化两者一硬一软，共同组成了高效技术团队的基石。今天专辑的主题就是“如何打造高效的研发流程与文化？”，希望你看完之后能有所收获，也欢迎留言选出你最喜欢的文章，或是分享你对于技术团队打造的实践与经验。

新春特辑5 | 如何做好人才的选育用留？

你好，我是《技术领导力 300 讲》专栏的主编成敏，招到合适的人才并充分发挥他们的价值，是公司发展最重要的事情之一，也是技术领导者最重要的能力之一。今天专辑的主题就是“如何做好人才的选育用留？”，希望你看完之后能有所收获，也欢迎留言选出你最喜欢的文章，或是分享你对于技术团队打造的实践与经验。

温故而知新 | 一键直达，六大文章主题索引

你好，我是《技术领导力 300 讲》专栏的主编成敏，很高兴与你一起走过一年的时间，

从 2018 年 4 月到 2019 年 4 月，专栏共计发布 260 篇文章，话题涵盖了格局与战略、团队管理、职场软技能、跳槽与创业、技术趋势解读等。为了便于你按照主题领域来回顾，我曾在春节期间整理了 5 个热门主题的直达专辑。在此基础上，我又对整个专栏内容进行了梳理和精选，并整理为六大类，你可以点击知识卡，跳转到你最想看的那篇文章。

新春特辑 1 | 卓越 CTO 必备的能力与素质

新春特辑 2 | 如何成长为优秀的技术管理者？

新春特辑 3 | 如何打造高质效的技术团队？

新春特辑 4 | 如何打造高效的研发流程与文化？

新春特辑 5 | 如何做好人才的选育用留？

CTO 能力、素质与战略类

创业、打造团队类

研发管理、团队管理类

绩效管理、空降管理类

政策、趋势解读类

职场文化、软技能类

第1讲 | 你的能力模型决定你的职位

在投资圈里经常听到这样的话：“CEO 和方案都有了，就差个 CTO 了”。技术人员听了都哈哈一笑，觉得不靠谱。

但是笑过后，反思这句话，其实无论巨头公司还是初创公司，每个公司都有这个情况，有些公司真的就因为找到了合适的 CTO 崛起，有的公司因为找错了 CTO 而走上歧途，也有的 CTO 因为找错了公司而耽误了自己的时间。

究竟什么是 CTO，一个公司真的需要 CTO 么？哪些公司的职位对于技术管理者来讲真的是 CTO 的职位？同样是技术最高负责人，为什么有人叫 CTO、有人叫技术总监、技术 VP，有人叫首席架构师？他们之间的差别是什么？怎样才能成为一个合格的 CTO？

这些问题，我将通过“CTO 核心能力管理”系列文章分享一些自己的思考，也重新定义一下市场上对于上述职位的定义，各位 CEO 和 HR 在发布 JD 的时候重新思考一下，自己需要的是一个 CTO 还是技术 VP、还是技术总监。

跟各位技术管理者也谈一下自己 CTO 成长之路的一些感悟，希望可以对大家有所启发，也希望大家多多提意见，让我自己也能更多的向大家学习。

首先说一个观点，“所有的职位不是别人给你的，而是你自己挣出来的”，一个人在某一个公司一个职位 18 个月以上，基本上是获得了这个公司合伙人和其他管理者的认可，存在必合理，现存的最高技术负责人：CTO、技术 VP、技术总监、首席架构师都是合理的，一个公司最高技术负责人不一定是 CTO。

各职位之间的差异，我从以下技术管理者需要的五个核心能力来区别开：领导力、文化构造能力、人员管理能力、体系搭建能力、技术实力。同样是最高技术负责人，在这五点能力上的强弱决定了最终自己在市场上“挣”出来的职位是什么。

这篇文章会把这 5 个技术管理的核心能力进行阐述，然后根据下面的技术核心管理能力模型来对这些职位进行重新定义。后续几篇文章会分享一下如何提高这五方面能力的一些心得和经验。

领导力：“成事”的能力

领导力的定义有很多，管理大师德鲁克的定义是“领导力能将一个人的愿景提升到更高的目标，将一个人的业绩提高到更高的标准，使一个人能超越自我界限获得更大成就；另一位领导力大师约翰·麦克斯威尔的定义是：领导者是知道方向、指明方向，并沿着这个方向前进的人。

而我的定义很简单：“成事”的能力，领导力最终是用各种各样的方法、人员、影响力、号召力、决策力将一个事情从 0 到 1 的能力，如果把事情做成 0.99，都不是领导力的体现。是否对最终结果负责，这也是所有带”O”的职位和不带”O”的职位最大的差别。

文化构造能力：“影响意识”的能力

文化是人类群体创造并共同享有的物质实体、价值观念、意义体系和行为方式，是人类群体的整个生活状态。对应到技术管理上，就是管理者对于大家意识的影响力，小到对于整个技术团队价值观，公司技术氛围、行为方式和状态的构造和影响能力，大到对于国内技术生态甚至国际技术生态的影响力。

文化对于公司和部门管理非常重要，它是无形之手，决定了你团队的价值观是什么，你的公司能不能招聘到高级的技术人员，在我们日常流程和管理者眼睛看不到的地方，员工是怎样工作的。

是否可以打造一个合适公司发展的技术文化，是否可以构造一个开放、透明的技术氛围，是否有能力建立一个 MTP（Massive Transformation Purpose）能让每个技术人员深入人心，能在技术圈内影响到志同道合的牛人来一起共同奋斗。

“影响意识”的能力是一个 CTO 水平高低的评判标准，也是每个“O”级别管理者能力的体现。同样是 CEO/CTO，除了可以“成事”的领导力，文化构造能力也是决定了哪些企业可以持续壮大，哪些企业会昙花一现的关键要素。

人员管理能力：“人 *100”的能力

人员是一个科技企业和技术团队核心最重要的资产，如何让技术人才这样特别聪明的一群人可以高效的工作，对这些聪明人如何招、识、管、留、开，是一个技术管理者的核心技能。人员管理其中不仅仅是沟通的能力，更要是对人员素质的准确判断、员工心理、团队士气、杀伐决断、上下级管理沟通的综合能力。

从发挥人员能力的角度来看，一个好的技术人才可以做到乘以 1，一个优秀的总监可以做到乘以 10，一个卓越的 O 级别人物就要做到乘以 100。所以，人员管理的能力，简化来讲，就是管理者如何让人乘以 100 的能力。这里的人员管理，不仅仅指的是管理下级，还有管理同级和管理上级的能力，能否和其他合伙人以及 CEO/COO 级别紧密沟通和配合，也是一个高级管理人员是否可以成功的关键。

体系搭建能力：“建巢、管事”的能力

体系搭建能力比较复杂，做成一个事情，不仅仅包括项目管理的能力，而且要包括从 0 开始建立选择项目管理方法、选择人员管理体系，然后再根据体系进行管理的能力。不同的公司，不同的阶段管理方法和体系都会发生一些变化，从项目管理、架构管理、到人员管理、体系管理，什么时间用什么样的管理方法，控制好质量、进度、节奏、人员是一个管理人员能力的体现。从具体管代码、项目，到最高层的建立一套体系取代管理人员日常的工作，体现这个管理人员的职位和公司对他的需要。

技术实力：“技术肌肉”的实力

技术管理人员，技术是必不可少的，在这个维度上经常有些争论，例如“CTO 要不要是极客”，“CTO 应该不应该写代码”。我这么理解，把技术人员对比成运动员，一个人的技术能力就是他的肌肉的实力。有的人上肢力量很发达，可以举重；有的人腿部肌肉很发达，可以短跑，有的人肌肉匀称，善于马拉松。不同的技术人员、不同的职位，需要的肌肉群是不同的，对于不同公司的相同职位，其实需要的肌肉群也不同。没有一个人全身的肌肉都发达，也没有一个公司仅需要一种肌肉群的 CTO，作为技术人员来讲，你的肌肉强度和肌肉群的分布，也会影响职位的不同。

下面根据这五个维度能力模型来重新定义现在的技术管理岗位，公司的管理者也可以根据实际需要来找到公司需要的人才：

技术总监能力模型

对于技术总监来讲，要有比较强的技术基础实力和人员管理能力，主要是要能把事情完成和落地，对于小公司来讲，如果最高职位是技术总监，那么就需要技术肌肉矩阵全面的，对于大公司，技术总监意味着单项技术肌肉比较强。无论公司大小，总监级别一般都会汇报给某个业务线 VP 或者技术线 VP/CTO，因为他不是对最终结果负责的人。同样，领导力和体系搭建能力就没有那么强，对于文化构造能力更要弱一些，因为这个层级并不需要这些能力。

技术 VP 能力模型

技术 VP 和总监最大的差异在于体系搭建能力的增强，每一个 VP 会有一个或者多个总监来支撑，建立一套体系让技术研发高效的运转起来，体系搭建的能力甚至要高于 CTO，因为他是 CTO 的大内总管。而技术实力略强于总监，领导力，文化构造能力也有所提高。VP 和 CTO 的最大差异是是否可以对技术的最终结果负责，不仅仅是技术本身、而是在财务、战略方向上是否具有决策力，这是副手和正手之间的差距。在很多时候拍板很难，因为 CTO 很多时候不管是不是由你直接造成的，你都要承担所有的后果。所以技术 VP 一般不会直接汇报给 CEO，因为 CEO 眼里只有 0 和 1，不会接受任何理由。同时，公司外部文化和内部文化的构造能力也是 VP 和 CTO 的差异之一。

首席架构师能力模型

首席架构师应该是在公司里技术最全面最强的一个人，技术肌肉和公司整个技术最匹配的人员。经常有人会把首席架构师能力模型和 CTO 能力模型搞混，首席架构师可以是 Geek 一样的人物，因为他不对商业的最终结果负责，但是对技术整体架构、前瞻性，技术本身体系负责。因此，首席架构经常会把方案汇报给技术 VP/CTO 供选择，不会最终拍板。首席架构师的技术非常厉害，领导力和文化构造能力就会相对较弱一些。

CTO 能力模型

CTO 是能力矩阵里最均衡的一个，突出的能力是领导力和文化构造能力，而不是技术实力。公司小的时候，CTO 可能是公司中技术最强的那个人，但是 CTO 必须要有能力构建一个文化和体系，迅速能让比自己技术牛的人、体系搭建能力比自己强的人融入到公司，才可以让自己到更高层次上来做决策。CTO 要把控和技术相关的布局节奏、商业结果、公司战略、人才策略，并翻译成其他合伙人可以听懂的语言，来做“成”事。

CTO 的技术肌肉通常要全身匀称的，因为他是公司里的技术肌肉教练，他可以肌肉不强大，但是要知道找什么样的技术肌肉团队来满足公司的需要，在赛场上赢球。同样，如果 CTO 只对技术着迷而对于 CEO 的融资策略、战略决策、业务布局，COO/CFO 的公司运营、财务运作没有有效建议并对结果负责的话，CTO 也很难成为公司 CEO、COO、CTO 三个重要 O 级别人物之一。所以，最终的管理的道理是相通的，如果你选择了 CTO 作为你的职业路径的话，其实你已经放弃了你是公司技术最强的那个人的成长路径。

结语

上面用技术管理核心模型来重新定义了这几个职位，一个初级技术管理人员可以根据自己的职业发展方向有意地培养自己的能力来达到自己的目标方向，一个公司在招聘技术人员的时候也可以对号入座，构建合适的 JD 找到自己合适的人才。这个“郭氏”技术管理核心模型也是第一个版本，也希望各位多给宝贵意见，促进模型本身逐步迭代，更贴近企业技术管理真实现状。后续几篇文章会分享一下如何提高这五方面能力的一些心得和经验，请大家持续关注《技术领导力 300 讲》。

作者简介

郭炜，易观 CTO ，中国软件行业协会智能应用服务分会副主任委员，TGO 鲲鹏会北京分会董事会会长。负责构建易观技术团队、完成易观大数据采集、平台、数据挖掘等技术架构与体系；从无到有完成易观混合云的搭建、以及易观 SDK 的升级，并发布易观秒算实时计算平台。目前易观大数据平台日处理数据量 30T ，272 亿条，月活用户 5.5 亿。

第2讲 | 七位CTO纵论技术领导者核心能力

关于技术领导者的具体职责和能力要求，每个企业会给出自己的定义。同样的职位，由于企业文化的区别，以及具体的业务和发展阶段不同，相应的要求也会有所不同。但总体来说，有一些核心的能力，是衡量一位技术领导者是否优秀的通用标准。

通常来说，CTO 这个岗位对技术领导者的能力要求是最全面的，基本上可以覆盖技术管理核心能力的各个方面。因此，我们邀请了七位现任或曾任 CTO，请他们根据自己工作中的体会，总结 CTO 需要具备的核心能力。对比来看，非常有意思。

AdMaster 联合创始人兼 CTO 、TGO 鲲鹏会上海分会董事会成员洪倍：

“CTO”“首席技术官”这三个英文单词或五个汉字，其实已经揭示了 CTO 所需要的核心能力。我自己总结起来是 5 个 "shi" 字。

第一个是 " 将士 " 的士，也就是要会带兵。“首席”和“官”这两个词天然赋予了你带兵用兵的责任。所以了解每一个团队成员的特征，关心每一个小伙伴的成长，打造一支能战斗的团队，是对 CTO 最重要的要求；

第二个是 " 做事 " 的事，除了带人，CTO 也需要身先士卒、迎难而上，CTO 没有攻坚平事的能力，愧对 " 技术 " 这个词；

第三个是 " 视角 " 的视，CTO 也要有行业洞察、市场思维、成本视角，只有多视角的观察自己所研发的产品、服务的用户、所处的市场环境，才能找到更匹配的技术解决方案，为员工、企业乃至社会创造价值；

第四个是 " 试错 " 的试，CTO 要勇于试错，当然有错了也要勇于承担，勤于总结，CTO 不敢试错，那团队成员就更不敢试错了。创新和成功是来自于无数次的试错；

第五个是 " 顺势 " 的势，CTO 如果不能预判技术发展趋势，团队一定会面临无头苍蝇或者得过且过的窘境。同时 CTO 也需要学会顺势而为，借助各方的资源和力量才能更好地带团队、攻难关、聪明地试错；

CTO 就是这样一个需要会带人、能攻坚、有视野、愿试错、懂得顺势而为的岗位。

杭州福强科技有限公司创始人王福强：

CTO 的能力要求很多，但我觉得有几个能力属于核心能力：

第一个是运营能力， 当然，因为 CTO 主要是 focus 在技术前缀下，所以，他负责的是技术组织的运营， 这包括日常，组织结构以及技术文化和营销等一系列软硬结合的运营方式；

第二个是转承的能力， CTO 和产品技术部门的核心职责是支撑 CEO 和公司业务，所以，要能够很好地理解 CEO 和 Peer 部门的意图和规划，进而推动落地；

第三个就是吸星的能力， 爱才如命，什么时候 CTO 对人的重视略高于对技术的重视的时候，CTO 的格局就更上一层楼了。

这是我的几点粗浅认识，仅供参考。

有赞 CTO 崔玉松：

CTO 首先是一个 O，O 本身代表着一个管理职位，其次还有 Owner 这层意思，他要很了解这家公司的业务，包括人才战略、市场战略、用户战略、增长战略等，甚至必须参与这些战略的制订。

技术说到底是为业务服务的，除非技术就是业务本身。在很多公司里技术真的就成了实现其他部门需求的工具，我觉得这样做 CTO 肯定是不合格的。首先它不能影响战略，需求提出方会经过很多转化，如果不是基于战略去推导，整个过程会失真。

第二个，我认为最最重要的是业务架构的能力，可能管理能力还次之。对于管理能力我认为最重要的是对团队的感知能力，因为一旦到了 CTO 这个级别，他已经脱离一线，很难再把一些细节还原。如果没有很细腻的感知能力，很多的决策会有偏差。

如果他不是一个业务架构师，不是一个能给团队指明更好方向的人，他最终会沦为一个需求翻译器，产品经理说怎么做就怎么做。他更多的只是负责保证产品的质量、开发的速度，最终被肢解成一个很琐碎的人。一旦团队上了一定的规模，团队就会从单纯的需求实现走向团队运营，而运营是需要方向的，业务架构就是一个基于运营和数据的一种综合的能力。

总结一下，我觉得最重要的就是参与战略制订、战略实施和战略分解的能力。其次，就是业务架构的能力和对团队感知的能力，微观事物感知的能力。

丁香园 CTO 范凯：

我觉得 CTO 需要具备如下 5 方面的素质：

一、技术视野良好，架构设计能力出色

CTO 要有良好的技术视野，不需要各种技术都样样精通，但是必须要所有涉猎，有所了解，对各种技术领域的发展趋势，主流非主流技术的应用场景要非常了解。知道在什么场景应用什么技术，公司业务发展到什么规模应该预先做哪些技术储备。产品架构的设计要有足够的弹性，既能够保证当前开发的高效率，又能够对未来产品架构的演进留出扩展的余地。

二、动手能力要强，学习能力出色

CTO 并不需要自己亲自动手写代码，但是如有必要，自己可以随时动手参与第一线的编码工作，CTO 不能长期远离一线工作，自废武功，纸上谈兵。否则长此以往，会对技术的判断产生严重的失误。另外，CTO 也应该是一个学习能力非常出色的人，毕竟 IT 行业的技术更新换代速度非常快，如果没有快速学习能力，是没有资格做好 CTO 的。

三、管理研发团队过硬，能建立团队研发文化

CTO 的责任是负责整个公司的产品实现，所以 CTO 要善于管理研发团队，掌控好研发工作进度，能够在规划好的时间内，步步为营，好整以暇地完成公司产品的研发工作。

此外 CTO 还要擅长培养研发梯队力量，建立研发团队内部具有向心力的，开放性的，交流学习型组织文化。让研发团队具备自我学习能力，自我培养能力，自我建设能力。这样的研发团队工作极度默契，战斗力极强，而且员工归属感很强，流失率很低。

四、具备良好的产品意识，以及跨部门跨背景的沟通能力

CTO 不仅要懂技术，还要对互联网产品有良好的感觉，从产品的逻辑性，可实现角度提出产品改进和完善的总体性设想。因为产品经理或者业务人员设想的产品，很可能是逻辑上不严密，存在实现矛盾的。

此外 CTO 还需要极强的沟通能力，要能够和不同背景的人有良好的沟通能力，能够用对方的思维方式和话语体系来描述他不理解的专业问题。

五、敢于对 CEO 说“不”

只要不是技术出身的 CEO，必然对研发是门外汉，很可能对产品也是门外汉。因此，CEO 不是每个想法都靠谱的，CTO 有责任站在更加专业的角度去帮助 CEO 纠正，推演，完善想法。一个不敢对 CEO 说不的 CTO，这个公司肯定要走很长很长的弯路的。

易宝支付 CTO 陈斌：

在我看来，CTO 可以不写代码，但是这意味着你有更重要的事情要做，比如需要具备技术战略、体系建设、人才培养、企业文化、商业眼光、领导艺术等方面的素质。

首先，CTO 是技术战略的主导者。在 CTO 的这些素质中，最基本是要有技术战略。比如：编程语言选 Java 还是其他的语言，有新技术出现的时候，及时地安排团队的人去学，以备不时之需。当然 CTO 自己也要不断学习新的技术，不断更新自己的知识储备。

其次，企业文化是非常有力的管理工具。企业文化很重要，但在实践当中经常会被忽略。CTO 也要管企业文化，不但要引导企业文化，而且要身体力行。其实企业文化是一个能够帮你把整个企业的研发人员、氛围、管理过程组织起来的有效手段。

最后，要打造良好的技术团队氛围。研发人员需要一位能指导他们、了解他们的大哥，我在易宝经常会跟兄弟们抽抽烟，聊一聊，有的时候也会写写代码，原因在于可以通过写代码去了解大家在想些什么。你作为技术领导者，必须进到那个氛围，了解一线员工在做什么。然后作为他们的代言人，代表技术团队跟公司管理层争取一些利益和福利，大家才会觉得这是我们的带路人。

携程首席科学家叶亚明：

在我看来，合格的 CTO 有六大要素：

要素 1：技术问题的解决能力
技术领导者会面临很多技术问题，尤其业务发展了以后，过去的一些技术瓶颈，都会变成问题。在这种情况下，要具备快速解决问题的能力；另外，你要指明方向，带领团队共同前进。

要素 2：具备强烈“还债”意识
几乎所有的互联网公司都会遇到技术债，当业务发展到某个阶段时，一定会爆发。有技术债怎么办？除了能够“发现”债的存在，还要适时“还债”，作为技术领导要有这种前瞻性。

要素 3：构建与 CEO 的良好伙伴关系
首先，要从业务负责人或 CEO 的角度去思考他提的需求是什么。其次，要会平衡产品需求，判断产品需求的优先级。第三，要提高交付满意度。第四，要有业务洞察力，要对业务有强烈的兴趣，如果你对业务非常有感觉，那么你跟 CEO 的交流就会上升一个层次。

要素 4：清晰的自我认识
你要意识到自己处于什么位置？周围的人跟你的平衡点在哪里？自己的优势和短板在哪里？对自我有一个清晰的认识非常重要。认识自我还不够，还要认识团队。团队整体技术水平是什么样？团队的短板在哪里？有这样的意识，你就知道在哪个方面应该补强。

要素 5：团队人才建设
实践起来主要有四点：第一，招募培养接班人；第二，CTO 自身的影响力；第三，自己的人格要经得起别人的挑剔，做到客观公正；第四，能创造优秀的团队文化。

要素 6：给工作注入新的东西
作为一个技术领导者，如果你经常为整个业务或者团队带来新的东西或思路，与公司授予你的权力相结合，那么推进起来会非常快。虽然自下而上的创新也可以成功，但是根据经验和中国互联网过去的发展，从上到下去推动改变会更快一些。

磁云科技创始人及 CEO、 京东终身荣誉技术顾问李大学：

一个好的 CTO 是能够把商业和技术结合起来，或者说具有商业敏感性的 CTO。我认为有三点：

第一，CTO 应该具备商业洞察能力。我比较喜欢看一些商业书籍，来锻炼自己的商业分析能力、判断力、决策力，因为只有把技术和商业去结合的时候，它的价值才能呈现出来。

第二是战略思维。很多 CTO 都是从技术人员做起来的，技术人员往往会想一个问题怎么做，他解决的是 how 的问题，但是在研究战略问题的时候，我们更多研究的是 What 和 who 的问题，或者说，我们更多的是看趋势、看未来，如果看得远，就可以反过来思考，现在做得是否对。我们有时候太关注技术本身，没有站在战略角度考虑问题。

第三是个人的影响力。这种影响力包括影响同事，影响下属，甚至影响 CEO，当你有一定影响力后你会发现，你能团结凝聚更多的人，那你做事情就比较容易。对于 CTO 来说，领导力的核心就是影响力。

结语

以上就是七位现任或曾任 CTO 总结的“CTO 的核心能力”，我们会发现，其中有很多相通之处，也有一些独特的观点。或许可以这样理解：是否具备 CTO 们都非常看重的能力，决定了你是否能够成为一个技术领导者；而是否具备部分 CTO 非常看重的能力，决定了你将成为一个什么风格的技术领导者。你的看法呢？

第3讲 | CEO实话实说：我需要这样的CTO

昨天我们分享了几位 CTO 对于高级技术管理者需要具备的核心能力的分析，今天我们换个角度，看看公司真正的老大——CEO 关于这个问题的想法，和 CTO 们是否存在差异。我们邀请了四位 CEO 现身说法，阐述他们需要一个什么样的 CTO。这四家公司都拥有为人称道的技术水平，相信他们的看法会对你有所启发。

七牛 CEO 许式伟：

一个 CTO 应该具备什么样的能力？或者说 CTO 应该承担什么职能？我想不同业务类型的公司、不同阶段的公司都不太一样。这里我说说七牛云对 CTO 定位的理解。

七牛早期只有单一的云存储业务的阶段，CEO 最大的职责是产品经理职能，理解和识别用户的核心诉求，并将其转化为产品的能力去满足它，而 CTO 的职责就是确保业务正常落地，用户的需求可以被按时按质地满足。从前瞻性的角度来说，CTO 同样应该深刻理解客户，以确保产品不止适应当前用户的需求，还要能够适应需求未来的演化。适应需求未来的变化，不仅仅是能够预测未来什么事情会发生，更重要的是预测未来什么不会发生。我一直比较强调需求的预见能力，是因为很多技术人员不太能够理解这件事情对其能力提升的重要性。而实际上只有做到这一点，才能从根本上解决研发资源的浪费（把精力放在不该放的地方）和重复投入（同一个组件反复投入反复没有做好）的问题。

2014 年是七牛业务多元化的开始，到今天我们发展出了以存储为核心、覆盖从连接到智能的多元化场景的数据管理平台。今天我们的业务覆盖了存储、网络加速、多媒体处理、机器视觉、AI/ 大数据、容器等多个领域，这对组织结构提出了新的挑战。今天七牛反而相对弱化了 CTO 这样一个单一岗位的职能，更多会倾向于在每个子业务设立一个首席架构师角色，而这些首席架构师会有一个架构师团队，各自负责该业务的系统架构和技术方案决策工作。在这样一个新的组织架构下，CTO 的位置在哪里？我的看法是，CTO 是这些首席架构师中的一员，一方面他也会具体负责某一个子业务落地的工作，另一方面，他牵头把公司所有架构师聚集起来，形成一个技术委员会这样的一个团体，这个团体会定期一起审视整个公司业务的健康状况，并推动全公司范围的基础设施迭代与改进。

有赞 CEO 白鸦：

CTO 要具备的最基础的能力我认为有两点：第一，他站在技术的角度，可以提前规划这家公司的整体技术储备和技术基础能力的沉淀。这件事儿其他的 O 都不懂，甚至大家在讨论的时候，在定战略的时候，都不一定能够从这个角度去思考。

但是，这个是 CTO 的专业，他的专业就是要做好今天在业绩上不能体现出来的知识储备，这是他一定要搞定的事情。

第二，因为技术这件事儿对于业绩的体现不是最直接的，所以 CTO 需要具备一种能力，就是用人话把技术讲清楚，让其他同事以及合作伙伴们能够理解技术。

总结起来，CTO 本质上要做好技术储备和技术沉淀，然后用人话把技术讲明白。

基于以上两点再对 CTO 提要求就变得非常简单：

第一，他要有足够开阔的视野。要做好技术储备就必须具备一定的视野，具备视野他才知道储备。但是，视野也需要经验，没有经验何来视野？我认为，经验是视野的基础，但视野还需要更开阔的想象力。

第二，因为这个时代技术迭代非常快，对技术的创新要求也特别快，所以 CTO 要具备很强的学习能力。这个很强的学习能力是指：他需要具备快速迭代自己的能力，他才能够有前瞻性的理解前端的技术，才能知道技术未来的方向。

沪江 CEO 阿诺：

不同企业由于所处发展阶段不一样，对于 CTO 的要求是不一样的。即使是同一个企业，在不同发展阶段对于 CTO 的要求也是不一样的。

从 0 到 1 创业阶段，对于技术负责人的要求是要能快速解决问题，碰到任何问题可以撸起袖子自己上。在成熟期的企业，CTO 作为公司的首席技术专家，需要具备战略的视野、优秀的管理能力和快速反应的能力，也就是三方面的核心能力：思维力、团队力、敏捷力。

思维力首先是能够制定并推进技术战略。要能站在行业和公司的战略高度来看待技术发展，洞察和分享技术行业发展趋势、最佳实践，对公司的技术和核心竞争力有深刻的理解。提炼年度或更长期的关键技术战略目标，并确保相关者理解。推动创新方面，思维力主要体现为开放性，也就是以好奇和开放的态度面对问题。带动分享组织内外的最佳实践，倾听不同的观点。嘉奖创新表现，对创新想法和行动给予赞赏。

团队力的基础是建立信任，能够聚焦企业文化和价值观的传承，建立学习型组织文化。展现正直、公平、诚实的可信赖品质，用行动兑现承诺，说到做到。最终目标是要建立成功的团队。引导团队设定清晰而吸引人的团队目标，激发团队斗志。为团队目标达成设置有效的分工、协作机制，降低内耗。定期盘点关键岗位上的人才供给及能力状况，培养人才，营造团队氛围。

敏捷力体现在个人的敏锐学习力，能够随着发展不断更新迭代，对新趋势和新技术持续跟踪评估，会亲自尝试各种新技术。有强烈的提升自己的学习愿望，并为此付出切实的努力。敏捷力还体现在推动团队执行目标，追求卓越。以解决工作中的核心问题作为头等大事，持续而快速的推进，刻不容缓解决问题。当结果不理想时，果断承担责任，想办法扭转局面。

乂学教育创始人栗浩洋：

CTO 的需求有三个方面，第一个方面要有非常过硬的背景和经历。对于一个创业公司来说，想要从初级突破十亿美金，比如我们乂学今年将超过十亿美金的估值，那么这个 CTO 过去的背景一定要是在远超十亿美金的公司里面工作过。比如说在 BAT，或者是百亿美金的上市公司里工作过，这是第一。第二，他一定要有过上亿的用户的经验，然后有千万日活的技术的成熟经验，如果没有，只是负责一个小的部分，没有打过大仗，那这个人是不符合我们的要求的。

第二，他要有进化能力。因为这个世界在不断地变化，产品在不断地变化，需求在不断地变化，技术也在不断的变化。如果他没有持续不断的进化和学习能力，那么其实他没有办法迎合企业不断往前发展的需求，就像我们现在，公司是一个 AI 为核心的公司，那么 CTO 就要在人工智能领域里边去进行深度的学习，要有深刻的了解。然后，我们这个产品还远远高于以前产品的复杂程度，因为自适应学习系统还牵扯到学生的认知学、心理学、教育学等等方面的知识，都要求 CTO 有自我进化的能力。

第三是具备黑洞的能力，黑洞的特性。现在的 CTO 已经不仅仅只是一个技术的负责人了，在企业里面要衔接里里外外的各种板块。像我们乂学人工智能教育机构里面，他要衔接 AI 算法，要衔接教学研究的部分，要衔接我们的线上销售和 marketing，他还要衔接商业拓展，还要衔接我们全国的所有合作学校。在这样的一个过程中，对他本身的沟通能力、协调能力和消化吸收能力要求特别高。

他不能把自己定位成一个板块的负责人，首先他要从一个董事长的眼光，从一个宇宙的宏观的眼光去看整个公司和未来的发展。然后，他要把自己放的足够低，在这个过程中，他一定不能是高高在上的，一定是自己放下所有的身段去非常虚心地倾听，像从零开始的小学生一样去和各个部门沟通，然后通过技术将各个板块的需求衔接进来，来推动公司的整个从战略到细节的发展。

结语

以上就是四位 CEO 对 CTO 这一角色的真实需求，有没有让你更加理解老板对你的要求，以及更加明确自己需要加强的能力呢？欢迎留言与我们探讨。

第4讲 | 技术领导者不等于技术管理者

在成为领导者的道路上，很多人会陷入一个误区，就是把“领导”等同于“管理”。事实上，“领导”比“管理”难度更大，因为管理很多时候是在解决重复问题，有章可循，而领导经常要面对新问题、新形势，而且没有现成的规章可以遵循。

怎样成为好的技术领导者？著名软件专家、美国计算机名人堂代表人物杰拉尔德·温伯格在《成为技术领导者》（曾译名《技术领导之路》）一书中给出了一系列答案。

2008 年，还是一线程序员的余晟翻译了这本书，用他自己的话来说，“‘生吞活剥’了一整套关于领导力的学说，基本‘塑造’了我关于领导力的认知，深深影响了我作为技术领导的管理风格和价值取向。”

余晟曾在传媒、电商行业工作，目前在互联网教育行业从事架构和研发管理的工作；业余翻译、审校过一些技术书籍，也撰写过专门讲解正则表达式的书籍；业余时间在个人公众号“余晟以为”（yurii-says）分享技术和管理话题，在技术圈小有影响力。最近，他与我们分享了关于技术领导力的最新思考，一起来听一听吧。

好的领导者可以“赋能”其他人

《成为技术领导者》这本书里，我能记起来的，现在还受用的主要有这么几点：

领导对团队的作用。优秀的领导者加入团队之后，人还是那些人，资源还是那些资源，但是做事的效率和质量都提高了很多。换用流行的说法，好的领导者可以“赋能”其他人，做成这些人之前做不成的事情。

勇于面对自己。如果一件事是“要做的”，但你迟迟没有做，那么坦白承认吧，你根本不想做。周围很多人总是立各种志、发各种誓，最后没行动，基本都是这样。想要改变，尤其是自我改变，是很难的，因为自我改变的任务通常不会像上级布置的任务那样，有明确的压力和期限，所以大多停留在“想”而已。真正要动起来，需要极大的勇气和毅力。

认清真实的自己。我越来越发现，我们并不是自己以为的样子，很可能完全不同。有一次，有个资深的同事把来求助的女同事给吼哭了。我找他严肃谈才发现，他当时正在思考一个问题，只是不希望被打扰，完全没有意识到自己的声调有多么高，语言有多么严厉。这样的现象很多，领导者尤其要注意。

“领导”和“管理”不应割裂

既然技术管理不等于技术领导，那么技术管理者应该如何判断自己需要加管理能力还是领导力呢？

我觉得这个问题没有不变的答案，好的技术管理者一定会根据具体的形势来调配“管理”和“领导”的分配，静态地、割裂地谈“领导”和“管理”都是不对的。

正好前几天看到了一篇形象讲解管理和领导的文章：你可以“管理”机器、“管理”马戏团，但不能“领导”机器和马戏团。

所以在我看来，如果你面对的团队还没有进入稳定的“轨道”（没有形成良好的习惯），甚至其中还有南郭先生和害群之马，那多半得加强管理。如果你面对的团队已经有良好的习惯，可以在目前的轨道上运行得很好了，那可能适合加强领导。

作为反例，如果你的管理能力很强，但去了一个已经稳定运行，很需要领导力的团队，没准只会添乱。

领导力可以换算为管理力

一个管理能力不是很强的人，有可能成为好的领导者吗？基于我上面说的这点，我觉得是可以的。

我见过不少精英型团队，自驱力和凝聚力都很强，它们其实不需要太多的管理手段。坦白说，管理在不少时候都是脏活累活——比如升职的安排、加薪的分配等等。

当然，领导力有时候也可以“换算”为管理能力。假如公司开不起那么高工资，年终奖系数也不高，又需要保持团队稳定性。这确实是管理上的难题，需要管理者动很多脑筋。但是，也有不少人单纯是“愿意”跟着某些人而选择留下的。这就是领导力换算为管理力的例子。

优秀技术领导者的必备特质

我见过不少优秀的技术领导者，总的来说，他们都拥有如下特质。

正直。大多数技术人员的价值观都比较朴素，天生不喜欢太复杂的算计和手腕，哪怕他们自己的利益并没有受损。如果发现领导者善于玩弄权术，多半不会佩服，而是觉得不舒服。

体谅。遇到问题能够放下自我，善于从其他人的角度思考，理解其他人的难处，了解“白痴问题”的来龙去脉，找出合理的地方。技术很强大，但把技术当成自己的护身符，就会很可怕。

谦虚。面子观念不能太强，要善于承认自己的不足，善于鼓励团队伙伴。领导者一定要清楚，衡量领导者业绩的落脚点是团队的产出，而不是个人的表现。

眼光。不是所有人都习惯解决“一大坨问题”的，很多人更习惯解决明确的问题。所以领导者一定要有本事从“一大坨问题”中找到最关键的那一两个，投入资源，同时把其它问题“按住”。

噢，还有宣传意识。约翰·洛克菲勒说过“除了做重要的事，也别忘了让其他人知道你在做最重要的事”。我见过太多这样的情况了：技术团队习惯默默无闻地付出，“耐心等待”上级有一个公正客观的判断，最后事与愿违。良好的宣传意识，对技术团队来说尤其重要。

提升领导力的靠谱途径

要提升技术领导力，我建议多看看技术领导力的书，比如《成为技术领导者》就不错（玩笑）。当然《最后期限》《凤凰项目》《告别失控》也是很好的书，甚至更好，毕竟《成为技术领导者》有点老啦。

但是也别光盯着“技术”领导力，其它行业也有不少领导力可以借鉴。我最近半年看了《中途岛奇迹》和《午夜将至》，尼米兹在二战太平洋战场的指挥，肯尼迪在古巴导弹危机中的决策，都给我不少启发。

另外，遇到问题多思考，多和其他人讨论。我们每天都在解决各种问题，但未必是以最优的方式解决的，甚至很多都是“凑合”对付过去了。“凑合”可以用来应付工作，但和成长绝缘。要成长，还是得像棋手要反复推演一样，多复盘自己的决策，持续讨论反思下去会有不少提升 。

最后，持续关注《技术领导力 300 讲》专栏呗。

以上就是余晟和我们分享的内容。最后，我们一起来回顾一下他在此前的一些文章里，关于技术领导力的几段精彩论述：

1、通常的激励似乎是从行为主义心理学的角度出发的，认为简单机械的“奖励 / 惩罚”就可以对员工起到引导和归束的作用。但这种理论其实是行不通的。

赫兹博格的“激励 - 保健因子”理论指出，员工在不同的阶段所看重的方面是不同的，简单说员工刚开始更看重的是个人生活、工作环境、薪金福利等“基本因子”，满足之后则寻求学习与发展、工作乐趣、成就与肯定等“激励因子”，而简单的“奖励 / 惩罚”在这些方面并不能奏效。

更重要的是，因为技术工作的核心之一便是创新，简单的“奖励 / 惩罚”并不能催生创新。按照我的经验，激励的作用更多是树立正确的价值观。这种价值观既符合公司的利益，又兼顾个人的成长，而且还要能落实到真实的工作中来。

在日常工作中，技术领导应当持续表扬和鼓励能提供高质量程序的行为（哪怕他日常不怎么说话），而不是提交质量一般但努力除错的行为。有这种持续的激励，才有可能塑造正确的价值观，给有潜力但还在摇摆、困惑的成员发出清晰的信号，从而打造高质量、迅速成长的团队。

2、领导力的表现是创造让所有人都能成长，都能发挥更大价值的环境，当然不能把所有人当成可以互相替换的棋子。按照温伯格的意见，好的组织应当是“全面的（Organic，也可以翻译为“有机的”）”，也就是可以互相取长补短，形成一股合力。

组织的全面，还体现在一个方面，即它是自组织的，各级的情况和任务可以在对应的级别自动自发地完成。或者用温伯格的话说：“在全面的组织中每个人都能解决问题，做出决策，执行这些决策。而领导不需要对各种问题亲自出面，亲自做决策，亲自执行”。

要想打造全面的组织，有凝聚力的团队，温伯格列出了几种需要警惕的行为，包括“只抓大目标”、把人当成机器来看待、事必躬亲、奖励低效的组织等等。虽然我们日常工作中无法做到彻底戒除，但只有尽力避免这样的行为，才能真正营造全面的组织，形成有凝聚力的团队。

3、许多技术领导者本身对技术非常有兴趣，所以他们自己在创新方面是没有问题的。但是身为领导，仅仅自己创新是不够的。既然相信人不是机器，既然相信软件开发是需要创造力的工作，那么就应当鼓励每个人的创新，为团队营造勇于创新的气氛。

好的技术领导从来不应该因循守旧。按照温伯格的说法，即便你用某种方式成功过，也不意味着没有更好的办法来解决同样的问题。所以，身为技术领导，应当鼓励所有人的创新，对于不够完善的创新建议，不能简单拒绝，需要代之以鼓励和引导。

甚至在某个问题上，即便自己有过成功经验，心里已经确定了方案，也需要虚心听取其他人的不同建议，更要勇于采纳更好的方案。

要知道，这样做并不意味着贬低自己的技术威信，反而确立了积极创新，并且能采纳合理创新建议的工作方式。只有一个人能创新的团队，永远不会强过一支人人都能创新的团队。

最后，用余晟的一段话与大家共勉：

技术领导确实不好做。但是，考虑到技术已经在我们的生活中扮演了那么重要的因素，考虑到技术人员大多是那么的单纯可爱，对技术领导者们来说，提高自己的技术领导力，既是义不容辞的责任，也是让人迷恋的诱惑。

正如上文所说，“领导”其实不同于“管理”，身为技术领导者，一定要把握好“管理”的份量，留出更多的精力给“领导”，才能更好的激发技术人的激情与创造力！

第5讲 | CTO的三重境界

要谈这个话题有些惶恐，毕竟扶墙老师也不是什么格局的 CTO 都做过，但我觉得 CTO 的格局不是由个人决定的，而是由组织的成长和所处的阶段决定的。

为了简化模型，我们姑且将不同格局的 CTO 划分到三个阶段的组织成长过程中去。

冲锋陷阵型 CTO

在组织刚起步到组织还没有成长到相对稳定的阶段，CTO 更多要承担的职责是身先士卒， 带领团队披荆斩棘，艰苦创业。

这个阶段的 CTO 更多关注的是结合团队自身情况，如何快速使用成熟的技术完成核心产品的原型落地，并根据产品和市场的需求快速迭代，你来不及去想什么架构合理，什么技术更优，你要做的就是想方设法让业务和产品落地，想得太多，对团队和公司都是危险的，现阶段的 CTO，务实比什么都重要。

我有一位朋友在北京的创业公司担当 CTO 和合伙人，他们团队主要为券商提供大数据产品， 曾经跟我讨论 Scala，比如为什么要选择 Scala，有什么优劣等等，他们要转型，因为当初团队是 Python 比较熟悉，能够快速落地业务，但随着支撑的数据量增长，Python 的性能已经要迫近瓶颈了，所以不得不考虑转型。可是如果过早的转型，可能连产品和客户的单子都拿不下来，所以，我认为我这位朋友与这个层面 CTO 的格局观是匹配的。

另外，之所以叫冲锋陷阵型 CTO 还有一层意思，说起来很多人可能会反对，但我还是要说的是，现阶段的组织里面，作为 CTO 的你在技术和见识上一般情况下都要比你团队的任何同学都高，所以，也意味着你在跳进去做事的同时，还有带人和培养人的职责。

总之，我认为相对处于前期阶段的组织，冲锋陷阵型 CTO 是最为匹配的，虽然很多 CTO 的格局可以更大，但与组织匹配才是最好的。 现阶段的 CTO 也可以关注很多，做得更多，格局更大，但我认为核心还是要务实地去抓产品的快速落地，自身要扑进去的同时还能够带人和培养人。

指挥若定型 CTO

随着组织的成长，团队规模越来越大，依然是冲锋陷阵似的做事方式和格局已经不能满足组织成长的需要了，这个时候 CTO 的格局体现在，你要开始抓管理了，你要开始抓规范了，你要开始向外看了。

怎么理解呐？

团队规模扩张，是因为业务规模扩张和增长，这也意味着其实是事情变多了，CTO 即使浑身是铁，又能捻几颗钉？所以，现阶段的 CTO 不能以过去冲锋陷阵型的思路去做事情， 而要学会授权，让专业的人去做专业的事儿，你要做得更多是去挖掘人才，定目标，抓考评，不管你是用 KPI 还是 OKR，这些都是现阶段的常用工具，CTO 自己去权衡和取舍就可以了。

你还要关注团队的结构是否健康，然后通过人才的选用育留来动态调整团队结构到一个相对健康的状态，在此基础上再梳理和沉淀日常工作流程，让团队的工作可以规范化，流程化，因为这些日积月累的东西，是很多人看不到的一个组织的软性价值，虽然很多时候员工会厌恶，领导也看不到明显的价值，但一个好的 CTO 应该理解并认同这些事情的价值之所在。

扶墙老师在做顾问的过程中，其中一家客户企业从几十人的技术团队扩展到上百人，CEO 反映说为什么团队人数多了，反而感觉效率却下降了呢？实际上反映的就是过去那种冲锋陷阵式的组织方式赶不上组织的发展了，所以，CTO 跟 HR 部门开始投入精力构建公司的职级序列，进行人才盘点，跟进制定绩效奖惩制度等，因为没有这些管理工具作为基础， 随着团队规模的增长，组织和团队的能力不但不会增长，反而会下降的厉害。

我很赞赏该 CTO 现阶段开展这些工作的手感，只不过这需要一段时间和发展过程，如果能够提前准备和着手，那么可以一定程度上减少组织发展过程中的试错成本和时间成本。

当然，这个阶段的 CTO 的格局还体现在内外兼修，除了将团队内部通过管理治理清明，还要开始向外看，关注业界的大趋势，大方向，并结合公司业务适当考虑一些方案的尝试和实验，为潜在的业务发展积攒弹药，并通过合适的渠道去发声，比如 InfoQ，比如 QCon， 都是业界公认的很有价值的渠道和平台，通过与这些有价值的渠道和平台合作，进而为公司和个人创造相应的业界影响力。

CTO 要有开放的心态，假如自己对一些新的趋势和方向都不感冒，甚至一枪毙了，那么，整个团队的创新文化和氛围也会受影响。虽然我相信很多 CTO 都是很聪明很理性的人，看问题也往往是直达本质，一针见血，但保持一个开放的心态还是很有必要的。

前阵子看杭州一家互联网金融公司在招聘区块链工程师，顺道就跟他们家 CTO 闲聊了一下，原来是他们有一个技术实验室的机制，会实验性的为一些新的技术和方向开辟试验田，我觉得这是一种很好的鼓励技术创新的方式。

让我们一起总结一下成长期的组织， CTO 应该有什么样的格局：

有一个开放的心态，能够通过营造团队文化环境和建立合理的机制，鼓励团队技术创新，对前沿技术和大趋势保持密切关注；

内外兼修，对内要关注团队的结构是否健康，要关注团队的人员成长，要关注团队的管理机制和手段是否合适和有效，通过一系列的人才和管理机制锻造一支有实力的团队；对外，则要通过相应的渠道去创造个人，团队和组织的影响力，建立符合自身定位的团队技术品牌，将来引入活水也好，同业界其他企业建立业务合作也好，自身和技术团队的影响力都是不可或缺的加分项。

当以上所有这些重点的事情做好之后，作为 CTO 的你就可以像坐在中军帐的元帅那般指挥若定了。

引领方向型 CTO

恭喜你，现在的 CTO 已经站在大平台之上，开始考虑指点江山了。

现阶段的 CTO 我觉得核心抓两个事情，第一个就是要考虑自主知识产权的技术和产品了， 通过结合业界方向以及自身团队和组织的核心定位，发展具有自主知识产权的产品和技术，构建属于自己组织和团队特色的技术体系，这是下面我要说的第二个事情的基础，打铁还需自身硬，只有奠定了相应的技术基础，自己有了很强的技术实力，才能有发声的权利和影响力。

前段时间 Google 和 Oracle 就 Java 平台的一些知识产权问题闹得有些不愉快，88 亿，确实有些肉疼，但这恰好反映的就是发展自主知识产权技术和产品的重要性，尤其是大公司，大平台，在越是接近底层技术栈的层面，越要具有前瞻性的提前布局，我觉得支付宝或者说蚂蚁金服自主研发 OceanBase 就是一个很好的正向案例。

当然，研发 OceanBase 除了有前瞻性这种可能，还有可能是被系统压力逼的，毕竟，在业务发展到一定体量之后， 所有已有的开源或者闭源方案可能都没有办法很好的满足需求，在看到数据监控趋势持续上升的情况下，研发符合自己业务特点和体量的数据库也是很自然的事情，因为扶墙老师不是决策层，所以这里只是随便猜测一下。

在奠定了自身的实力之后，现阶段 CTO 要核心关注的第二个事情就是做业界的方向标，所谓一流公司定规范就是这个意思（当然，这里的规范跟公司内部的规范可不是一回事，而是行业级别的规范）。作为 CTO 的你可以思考发起新的技术目标，引领新的技术风潮，因为你的平台和格局决定了你要思考的高度。

如果说蚂蚁金服 CTO 鲁肃提出 BASIC（注 ：所谓 BASIC 分别对应着 Blockchain 区块链、Aritificial intelligence 人工智能、Security 安全、IoT 物联网和 Cloud computing 云计算五大领域）还只是更多结合业界方向和自身公司业务特点制定的技术战略，那么，阿里搞达摩院则完全是在铸造高端技术品牌了，阿里不但要占据现有业界技术的制高点，更要抢占先机，通过研究院和实验室的形式挖掘和探索新的技术方向，进一步巩固自身高端的技术实力和品牌。

现在互联网有一个趋势，就是大公司大平台的技术已经过剩，在自身业务已经逐渐趋向天花板的情况下，技术部也开始思考作为一个业务单元或者说事业部向外拓展业务的问题了。而面向企业客户输出各种技术服务，帮助传统非互联网企业向 + 互联网转型，显然是一片很大的蓝海，所以，在这个层次化的 2B 企业技术服务市场的顶端，大公司和大平台的 CTO 们应该要提前并重点主攻同样处于行业龙头的大 B 市场，在奠定和稳固了大 B 市场份额之后，再寻求突入中小企业市场。

而在整个 2B 市场的技术服务品类里面，阿里云实际上是属于提前布局并已经开花结果的典范了，也可见多年前王坚博士作为 CTO 的大格局。

总的来说，制定行业规范和引领行业方向，塑造和巩固高端技术品牌，对外输出强大的技术服务能力和产品，扶墙老师认为这三点是现阶段 CTO 应该着重考虑的，也是现阶段 CTO 格局的体现，一旦落地，那就真是华山论剑，舍我其谁啊 ~

后话

总的来说，猛将有猛将的格局和职责，大帅有大帅的格局和职责，领袖有领袖的格局和职责，谁也代替不了谁，谁也都有谁的用武之地，最主要的是是否与组织现阶段的发展阶段相匹配，是否能够结合自身组织的特点选择合适的团队，手段和成本，从而达成组织的业务发展目标。

合适的才是最好的！

最后总结一下扶墙老师的观点：CTO 的格局是由组织成长和所处阶段决定的，作为 CTO 的格局可以超前，但不能滞后，否则就会严重制约组织的发展，进而拖累业务发展并让自己的团队沦落到拖组织后腿的境地。这是任何有追求的 CTO 都不愿意看到的。

祝愿各位 CTO 越成长格局越远大，即使已经可以引领方向了，还可以进一步晋级 CEO，继续人生赢家之路。

作者简介

王福强， 人称“扶墙老师”， 《Spring 揭秘》，《SpringBoot 揭秘》作者， 杭州福强科技有限公司创始人，原挖财首席架构师 / 技术 VP， 原天猫和阿里巴巴资深架构师和高级技术专家，TGO 鲲鹏会杭州分会会员。技术人出身，走过了 15+ 年的技术历程，爱读书，爱武术，爱码字， 爱射击，爱老婆……

第6讲 | 像CEO一样思考

2008 年 5 月，我加盟京东。实话说，刚到京东的时候，京东技术面临非常多的问题，甚至根本跟不上业务的成长。所以我在京东做的第一件事情，就是准备了 5 个人的团队，郊区租了一个别墅，决定开始封闭开发，要把京东的网站进行改版。

我们 5 人团队连续征战了三个月，把整个网站都重新改写了。正是因为这次改版，京东的用户体验上了一个台阶，成为电商用户体验的标杆。那次改版之后，京东的订单从几千单突破了几万单。

在公司小的时候，很多事情 CTO 都必须亲力亲为。但是，当公司逐渐长大，比如 2010 年京东的技术团队超过了 200 人，开始做前后台拆分，公司的快速成长对我的能力提出了更高的要求。一年后，京东的前、后台都超过了 600 人，技术架构必须统一，我以前从来没带过这么大的团队，面临着很大的挑战。

我意识到，作为一个技术专家，我可能是够格的，但是作为一个 CTO，其实我没有准备好。这时我想起这句话，站在 CEO 的角度思考。

经过一段波折，2012 年底，我把京东整个研发体系重新管理起来。2012 年到 2015 年 5 月期间，京东的技术又上了一个台阶。

所以，我想要跟大家分享：CTO 要像 CEO 一样思考。其实有时候做这个决定很难，因为，这意味着你要受委屈，你要放下，你要接受很多挑战，最重要的是，你要坚持。

换位思考，CEO 眼中的 CTO 是啥样？

一个人最大的问题，是不能很好地认识自己。两个人互相审视，一定会发现一个盲点，即你身上的问题我知道，而你不自知。

所以作为 CTO，一定要 360 度审视自己：员工对你有什么样的要求，同事对你有什么样的要求，CEO 对你有什么样的要求，特别是在他们眼中是怎么看待你的。如果你不把这个问题处理好，你就不是一个合格的 CTO。

那么，CTO 怎么才能让别人能理解我们呢？我觉得要反过来换位思考：我们要去理解别人，如果我们很好地理解别人了，就能很好地让别人来理解我们。如果研究我们自己的话，我们是有盲点的，所以我们要把同事、员工、CEO 甚至合作伙伴当做镜子，不断地反思。

通常在 CEO 眼里，CTO 是一个「成本中心」，总是要钱、要人、要资源，还经常出事，这是一个困境。

一般来说，CTO 最大的问题在于沟通。我们习惯用技术思维来沟通，在我们的世界里只有 0 和 1，非黑即白。但是对 CEO 来讲，每天面临的都是不确定问题，不是靠推导逻辑可以推导出来的。

尤其做战略选择的时候，只是判断一种可能性，他面临很大的压力，这种思维模式跟技术思维是不一样的。所以我们用技术思维方式去跟 CEO、业务部门沟通，就会有很多问题。

2015 年 4 月，我从京东出来创办了磁云科技，需要解决的最大问题就是：怎么把互联网人才、技术人才和传统行业相结合、对接？

所以我们技术人要知道，在 CEO 眼里，我们是什么样子，这样我们才可以去改变自己。

CEO 如何思考问题？

CEO 怎么思考问题呢？一般有五个维度：

先说第一个，用户维度。

一个公司其实就是做两件事：第一件事，把用户吸引过来；第二件事，让用户把钱掏出来，把用户留住，持续掏他腰包。

所以 CTO 要研究：我们企业的用户是谁？用户从哪儿来？怎么把用户留住？怎么让用户掏腰包？怎么提升用户的转化率？这里面就有很多学问，如果在用户这个维度，能够给 CEO 提供一个用户的仪表盘，我们做技术就有了一个新的方向。

第二个维度是行业的维度。

我到京东以后，努力学习仓储、配送、供应链、零售等其他业务部门的知识。因为如果你不懂，你是无法跟业务部门沟通的，当然更没法同 CEO 沟通。

所以，CTO 必须要具备行业知识，不能只讲技术，不能只用技术语言，很多时候你要结合商业和技术。你必须要懂行业，了解行业的本质。

第三个维度是竞争。

CTO 要对他所在的行业了如指掌，特别是这个行业里有多少企业，处在什么样的地位。要对整个产业画一个地图，把我们企业和企业未来要演变的路径标在上面，这样才能够按照整个行业趋势去做，才能奠定自己的优势。

我们在京东的大多数时间都在研究对手，研究对手正在干什么，怎么去追求卓越，怎么超越他们。

第四个维度是生态。

也就是要关注我们的合作伙伴，特别是那些上门推销卖硬件、软件的，我们要给予足够的重视。要很好地处理这些合作伙伴的关系，CTO 的圈子不仅仅要有技术圈，还要有行业的圈子，扩大自己的圈子，找到可以帮你的人。

第五个维度是要面向未来去思考。

通常，做技术的为了解决眼前的问题常常疲于奔命。其实，如果 CTO 能看到公司未来三年、五年的前景，可能会更得心应手。CEO 的思维一定是面向未来的。所以怎么把技术的战略跟公司的业务战略结合起来，这也是 CTO 要研究的课题。

沟通的时候，用数据说话

在京东，我学到很好的一招：和 CEO 沟通的时候，尽量用数据说话。包括立项，要说清楚这个项目能给公司带来什么，不是带来技术的先进性，而是跟收入、利润或者用户体验挂钩。如果你这么去做，更能够得到业务部门的支持，也更能够得到 CEO 的支持。

用数据说话也意味着，每个技术团队的成长可能都有三个阶段。

第一个阶段，技术跟随业务。业务跑得很快，技术跟在后面，业务部门可能不满意，但是要通过技术能力的提升去满足业务的要求。

第二个阶段，技术同业务肩并肩。这个阶段需要用数据说话。在京东我们成立了一个大数据部门，对每个业务部门制定 3~5 个指标，每个核心指标包括 100~300 个小指标。每个月都会做月度经营会，各个部门 PK 这些指标，通过指标的 PK，各个部门业务就可以提升。

也就是说，企业发展一定有一个业务验证到规模化的阶段，而规模化的时候就需要精细化，精细化的时候就需要数据说话。

我在京东的时候，曾给强东总做了一个仪表盘，打开手机对公司的经营情况一目了然，非常清楚哪个库房出问题了，哪里打包拥堵了，我们会用三种颜色来标记业务的状态：黄色警告，绿色正常，红色报警。

尽管 2014 年京东要上市，2013 年强东总到哥伦比亚大学学习去了，但是不要紧，虽然有这么远的距离，他通过这个仪表盘，对公司的运营了如指掌。

第三个阶段，通过技术来引领整个公司的发展。在京东一路走来，我认为技术部门一定要换一个思路：要跟业务部门做伙伴，要帮助业务部门成功。公司一般是业务部门立项，立项一定会带上研发部门。如果我们有这样一个心态，去帮助别人成功，顺带成就我们自己，在内部就能获得很多支持。

所以在京东研发部发展的过程中，组织结构一直在变化。以前京东是一个职能化的结构，包括产品部、研发部、测试部、运维部，后来分了很多研发部。比如，采销部门有研发部，物流部门有研发部，财务部门也有研发部。

其实，当研发人员达到几千人的时候、是最需要做业务研发闭环的。研发人员同业务在一起，业务、研发、运维、运营都在一起，这样响应的速度是最快的；业务的目标就是研发的目标，这样会更有成效。

所以公司的组织结构也是 CEO、CTO 们要考虑的一个问题，如何调整以适应公司的发展。甚至每一项技术的引进、每一个项目的设立，都要回到数据上去。看看对公司带来怎样的贡献，和哪个部门有利益关系，和哪个部门去合作。

当家才知柴米油盐贵

最后说说我自己成为一名 CEO 之后的一些感悟。

说实话，变化还是挺大的，比如做 CTO 的时候，当一门新的技术出来的时候，就会深入下去，可以亲自动手，现在就比较难做到了。我能做到的是搭一个平台，让这些牛人团结起来，在那个技术方向上能够深入下去，并且我让他们随时把进展的情况给我分享，我就能够跟上这个技术发展的步伐。

当你从 CTO 到 CEO 位置的时候，你需要有勇气来承认技术上不如 CTO 了，但是要保持对技术的好奇心，要跟踪技术的趋势，同时要尽量花多一点时间跟他们在一起。

另一个方面，技术现在进步非常快，但是技术怎么转化成生产力？怎么去商业变现？这是我考虑更多的问题，怎么从新技术，或者新趋势里面找到商业机会，这方面我往往很敏感。我当 CTO 的时候，我感觉有个框框把我框住了，那可能是企业战略或者 CEO 要求你要这么干，我做 CEO 的时候，我发现没有了框框，有一种天高任鸟飞，海阔凭鱼越的感觉，这种感觉能够让我抓住更多的机会。

在磁云科技助力产业转型升级的过程中，我发现真正制约企业发展的瓶颈是资金和效率，磁云科技因此逐渐明确了科技赋能产业升级的思路，成为一家以区块链为核心的科技金融公司。

2016 年，磁云率先布局区块链的场景应用；2018 年，磁云聚焦区块链＋供应链金融，发布了磁云唐票产品，基于自有区块链核心技术，将行业上下游的账期资产实现了数字化和信用化，从而实现了数字资产的切分、流转和融通。

你当了家之后，你才知道柴米油盐贵，当你成了 CEO，公司的生存发展就是头等大事。而且 CEO 承担的压力是很大的，很多人都在关注你，我当 CEO 之后，抗压能力更高了，对自己的要求也更高了。

作者简介

李大学，磁云科技董事长兼 CEO、京东集团终身荣誉技术顾问。中国互联网 + 实战团发起人，正和岛互联网 + 部落酋长。曾担任天极网 CTO、京东集团高级副总裁，主管技术研发体系。在京东期间，带领京东研发团队从不到 30 人发展到近 5000 人，通过技术驱动，实现了京东业务一万倍的成长。

第7讲 | 要制定技术战略，先看清局面

随着企业创新节奏加快，CTO 作为核心高管之一，在管理战略上起到越来越重要的作用，一方面要理解公司战略，另一方面要给出正确的技术战略和节奏反馈管理层，让所有管理层对技术有一个正确的预期和把控。

什么是技术战略？用通俗的话来讲，就是在现阶段用合适的人、合适的技术架构办合适的事情。

首先要看清“现阶段”

不是每个公司从一开始就是和 BAT 一个阶段的，每个公司实际业务形态也不同，所以技术战略、架构选型、人员招聘等直接选择与 BAT 对标往往会把公司坑得很惨，所以认清楚现阶段很重要。简单说来，要认清以下两点：

公司团队现状：公司现状包括管理团队和执行团队的价值观、认知、潜力、水平等。对于高级技术管理者来说，其他高管对于技术的价值观和认知很重要。这涉及到你对于技术的投入、人员变更一系列的决策是否可以得到其他合伙人发自内心的支持，只有这样你才可以让技术形成有效闭环，技术和业务才可以螺旋式上升。所以，技术高级管理者要花非常多的时间，结合实际业务反复给其他合伙人沟通你的观点和认知，并把事情“做成”，赢得其他合伙人的信任。

认清现状，同样适用于执行团队，没有一个执行团队天然就是全能的，在这个业务快速变化的时代，每个技术团队都需要在不断迭代中适应公司和市场的变化。当前团队的长处和短板是什么，当前情况下业务情况下，对于技术团队是需要招聘、优化、还是培养。这都是一个高级技术管理者需要了解和决策的。

业务增长节奏：了解当前业务的节奏、财务的预期是什么。这是高级技术管理者后面选择人、架构和事情重要的参考，在控制技术节奏的时候非常重要。无论是牛人，还是最棒的架构，都是为了业务预期服务的。

如果公司节奏是在快速上升通道，那么需要孤注一掷的砸资源、请牛人、扩大技术团队以支撑几何级数上涨的业务；如果公司业务处于探索阶段，那么适当控制团队规模、用实用而稳定的技术，控制管理团队预期就很重要。

如果节奏没有了解清楚，技术节奏把控不好，很可能会导致技术无法支持现有的业务增长，或者业务收入无法供给辛辛苦苦招聘来的技术牛人，看着一起成长起来的兄弟却要忍痛优化掉，这是每一个技术管理者都不愿意见到的。所以，深度了解公司业务、洞察业务增长节奏，是每一个高级技术管理者必修课。

技术架构升级就是对人的升级

了解了当前公司的节奏和现状后，就可以对现在的执行团队和架构做一次评估，然后决定做什么样的事情。人、架构要做的事情是一体的，技术架构升级其实也就是对人的升级（可以参看我发表在 TGO 鲲鹏会微信公众号的文章《技术框架升级其实是整个公司的升级》），不同情况下执行团队和架构也是不同的。

公司初期，业务验证阶段：技术品牌与技术资源都不足，为了尝试业务，需要快速实现 MVP 并开始迭代。在这个期间，人才招聘和快速达成 MVP 是最重要的，MVP 用的技术架构可以是丑陋的，因为这个时候业务闭环比技术优美更重要，“快”才是第一位的。

同时，招聘也是最重要的，是否可以组建一个有相同价值观的初创团队，经受住压力快速推出 MVP 是这个阶段的“生死门”。此时人才招聘宁缺毋滥，一个不够优秀的人才你还要花很多精神去管理他，而在初期你同时要做很多事情，已经焦头烂额，不寻找到能自我驱动的人才，其实是给你自己挖坑。

而人才的价值观和技能最重要，此时没有时间去培养，一个人的力量永远是有限的，要一帮能同仇敌忾的兄弟才能成事。当然此时大多数公司人力招聘还跟不上，所以往往要技术合伙人自己去寻找人才。在后面关于人员管理的文章中，我会详细讲到如何能找到第一批技术骨干。

公司高速突进阶段：此时，公司业务模式已经定下来，需要高速发展。人才的抢夺、高可用高可扩充的架构是需要重视的。此时，公司每天业务可能翻几倍的成长，初期留下的技术债急需修正。所以，招聘人才时，一方面需要看人才对价值观的认同、潜力和能力，另一方面需要高出市场平均价格来吸引人才迅速加盟，确保公司业务顺利进行。卓越的人才团队建立是这个时期最重要的，如果人才不到位、高可用高并发的架构必然无法满足，业务出现各种问题就会让整个技术团队进入被动。经常看到一些初期的技术合伙人和技术团队在这个阶段因为无法跟上公司发展的步伐而被优化或者替换。

其实，同作为技术管理者我很理解这些处理，只要公司处理的公正和公平就无可厚非，不能因为技术团队的一个人或者几个人阻碍公司的发展。有的人擅长从 0 到 1，有的人擅长从 1 到 N，作为高级技术管理者，要了解自己的认知边界，要么不停挑战自己不停进化，要么急流勇退，为整个公司提供更好的上升空间。所以，这里的人才抢夺不仅仅是执行团队，也包括管理团队自己。跟上公司高速发展的步伐，是这个阶段整个技术团队最大的挑战。

公司平稳发展阶段：公司在市场的大格局已定，此时技术体系搭建和文化的建立是最重要的。经过高速的发展，各种能人已经召集大半。一方面随着业务进入常态，技术开始进入平缓期，有时间可以对过去的技术债进行偿还，另一方面也要注意避免技术过渡镀金和官僚的滋生。此时，可以挑战最新的架构来适应未来不确定的业务变化，重构升级原有技术体系，将前面各阶段的漏洞补上。

打江山难，坐江山更难，每一个技术管理者不要放松警惕，此时可以好好思考一下，怎么来好好管理了。需要建立合适的文化和体系，让这些牛人有合适的氛围，继续打磨原有的产品和技术框架的同时为未来的业务拓展打好基础。注意不要给过多的资源，一直要保持着技术团队“半饥饿”状态，这样在前期积累的狼性才可以持续保持，而不是把一群狼训练成狗；当然，也不要把在余粮的时候故意把狼饿死。同时，开始配合公司进入新业务领域的研发和突围，继续从业务验证阶段重新开始新的挑战。

公司业务紧缩阶段：尽管大家都不愿意面对，但是某个业务或者某个产品都会遇到瓶颈，或者试错失败的情况。此时，如何紧缩是每一个技术管理者最大的挑战。这个阶段，保持士气和核心成员是最重要的，公司里应该有一种试错的文化，很多时候业务的失败是天时地利人和的问题，不是某一个团队的问题。但是因为公司的发展和生存，可能某个业务方向要紧缩。

人员如果可以转到其他业务最好，如果需要人员裁剪，注意方式方法，如果可能尽量送上大家一程，同时尽全力保留核心骨干。此时，对于士气的保持很重要，毕竟业务紧缩，不是整个公司破产，通过领导力和个人魅力留住核心人员维护最基本的业务运转，以图东山再起。“地失人在，人地皆得；地在人失，人地皆失”。仔细看每一个成长起来的大企业，无一不经过一些巨大的挑战活了下来，浴火重生的团队才是真的战无不克。

管理体系建立的关注点

在不同阶段，都要建立不同程度的流程体系，具体有很多文章介绍，从传统的瀑布模式到 Scrum 到 DevOps，我就不一一介绍了，这里需要说的是除了日常的人、财、物的体系构建之外，管理体系建立还有几个需要注意的点：

不确定性控制与持续改善：技术面临的不确定性很多，如果做得快了，成本难以收回；做得慢了业务无法支持。面对巨大不确定性，立一个巨大的项目，通过庞大的管理体系去管理往往都会失败。我们通常面对要做 100 个 50 分的功能和 50 个 100 分的功能的决策，我们要毫不犹豫的坚持 50 个 100 分的功能。针对每个项目、每个管理步骤，最小的闭环很重要，步子不要太大，每一个小的迭代都是成功的，持续完善才是王道。

持续交付与迭代：这里不想讲 CI 的东西，只想强调 CI 的目标是“快”。最快的集成，最快的给出高质量的产品，最快的训练出来高效的跟的上节奏的团队。这才是持续交付与迭代的目标，把团队的速度和交付节奏拉起来，淘汰跟不上的人员，对优秀的人员持续激励。这样才可以得到优秀的团队，做成事情，获得其他合伙人的认可。

构建使命式管理结构：团队大了就会出现行为不一致的情况。这时候有两种选择，一种是自上而下命令式管理，一种是水平沟通使命式管理。我会选择后者，尽管看上去不像自上而下流程管理那么清晰，但是，在现在这个瞬息万变的市场，你很难有效的获得最真实的信息。此时，你再厉害的经验和决策，往往也会在信息一收一发当中扭曲变形。

因此，使命式管理，通过让整个团队了解明确的目标以及目标背后的原因，把权力下放，让一个产品经理也可以决定某个网页带 bug 上线，而达到整体产品流程完整。这个时候你会发现，形成业务闭环的速度比你想象的要快得多。

结语

战略和体系搭建是很难通过几篇文章或者一个培训就可以学会的，更多的是高级技术管理者的自己的思考和顿悟。此时，除了技术类书籍，建议技术管理者可以通读一下管理者经常看的书籍，例如《毛泽东选集》、《原则》，或者管理大师德鲁克、精益系列的书，从中一定会有所收获。

当然，也可以加入 TGO 鲲鹏会，和更多的高级技术管理者在私密环境下深入切磋。很多时候，高级技术管理者，特别是技术一把手是孤独的，很难有人可以分担一把手的压力，阅读和深入切磋是大家解忧的好办法。

后面，我将针对领导力、人员管理、文化建立做详细的讨论，欢迎大家持续关注。

作者简介

郭炜，易观 CTO ，中国软件行业协会智能应用服务分会副主任委员，TGO 鲲鹏会北京分会董事会会长。负责构建易观技术团队、完成易观大数据采集、平台、数据挖掘等技术架构与体系；从无到有完成易观混合云的搭建、以及易观 SDK 的升级，并发布易观秒算实时计算平台。目前易观大数据平台日处理数据量 30T ，272 亿条，月活用户 5.5 亿。

第8讲 | 技术领导力就是“成事”的能力

人，是一个创新企业最重要的要素，在确定方向上能否在市场上胜出，在于这个企业招聘和管理了什么样的人才。越是高端的人才越难招聘和管理，而如何和各层级人员有效的合作，领导力是一个技术管理者的重要能力。在上一期的技术管理核心能力模型中：领导力、人员管理能力、文化构建能力、体系搭建能力、技术实力，领导力是排在第一位的。

那么什么是技术人员的领导力呢？经常有人这样定义技术管理者的领导力：领导力就是让人服你，所以技术管理者的领导力就是技术要比大家都强；还有人认为领导力就是权力，赋予你权力自然就有领导力。这都不是正确的理解。

领导力，管理大师德鲁克的定义是“领导力能将一个人的愿景提升到更高的目标，将一个人的业绩提高到更高的标准，使一个人能超越自我界限获得更大成就。另一个领导力大师 John Maxwell(约翰·麦克斯威尔) 定义是：领导者是知道方向、指明方向，并沿着这个方向前进的人。

而我对领导力的定义很简单：“成事”的能力，职位不是别人授予你的，而是你自己挣出来的。领导力就是用各种各样的方法、人员、影响力、号召力、决策力将一个事情从 0 到 1 的能力，如果把事情做成 0.99，都不是领导力的体现。

“成事”，对最终结果负责，这是最高级领导力的体现，如何培养自己的领导力，能“成事”呢，在我看来需要以下几种能力和素质的培养：

决策力：迅速拍板并为结果负责的能力

大家所理解的决策，经常是给老板三个方案，老板从三个方案里拍板一个最好的，然后让大家去执行。其实实际情况并不是这样的，作为一个高级管理者，经常能看到下属遇到一些困难的球（问题），大家想尽一切办法去接着这个球，好接的球基层、中层管理者都搞定了，出现在你面前的球都一定是“仙人球”了。

所以，技术管理者看到的情况，经常不是“两好选其优”，而是“两害取其轻”，通俗的话讲，你面前两坨翔，一坨大的，一坨小的，让你必须选一坨吃，如果你不迅速确定，这两坨马上各自增长一倍。

所以，每一个决策者其实都是痛苦的，他要在信息不完全明确的情况下，面对痛苦和更痛苦的事情上，迅速决定用哪个方案，并为结果负责，同时为了激励士气还不能表露出任何痛苦。如何能在这样的情况下迅速决策，结果只是当时最好的（最糟的决策就是不做决策），而所有产生的问题和压力都要独立承担，而不能给下属，这就是一个管理者决策力的表现。果断敏锐地选择当前可行的方案并为之负责，这就是决策力。

沟通力：倾听与准确反馈的能力

沟通是普通管理者最重要的工作，高级管理岗位除了日常的沟通之外，还要倾听中层管理者和员工的声音并准确的反馈，其中难得是“准确”二字。在对直接下属沟通时，根据员工的性格和成熟程度，准确告诉他的管理问题和对事情的目标、方法以及异常的处理情况。初级熟练员工需要手把手完整的指导如何去做，高级员工需要使命式沟通，如果沟通方式相反，反而会让初级员工不知所措，高级员工觉得无法成长，而起到反作用。

在批评员工时更要准确，批评不是发泄自己的压力，对事不对人，有效的批评是帮助员工成长，下次不会再需要你操心同样的问题。如《原则》中提到的“严厉的爱才是最可贵也是最难得的”。

沟通力，就是在合适的时间对合适的人用合适方法说合适的事情。

影响力：号召管理层和员工一致行动的能力

“职位不是别人给的，而是自己挣出来的”，这句话就是影响力的真实表现。影响力包括对外对内两部分。

大部分人提到影响力，会提到一个技术人员在外部被多少技术会议邀请，有多少技术文章和概念被其他人引用和认可。其实对外影响力的目标是作用在对内影响力上，通过对于业界的影响力以及方案判断和决策不断的验证，建立管理层对于技术整体团队的信任。这样在决策和预判过程当中，作为 CTO 和技术管理者的技术基因才可以有话语权，可以让公司以合适的技术节奏和技术路线来发展，避免过少或者过多的技术投入导致影响业务。

对于员工的影响力，是员工发自心底的一呼百应，通过准确的技术判断、正确的管理决策、合适的领导方法让员工信服决策者而不是因为职位的高低而去执行。这样才可以打造一个积极向上、海纳百川的产品技术团队。

识人 & 授权：通过人员管理人员，通过别人完成使命的能力

一个超过百人的高级技术管理者一定不是亲自再做细节的工作，而是通过更多的合适的人员来完成任务。首先，知人善用是高级管理者重要基本素养。所有的创新企业都是由人构成的，人是否合适在一个岗位上是管理者最重要的判断。在企业的不同阶段，是适用不同类型的人才的，而每个人也都是不完美的，尺有所长、寸有所短，如何管理这些人是需要有技巧的，后续文章也会再详细的讲述。

其次，要充分的授权。高层管理者的授权不是说只是布置事情让大家去看，然后自己再去指挥，高级的管理者要和自己的直接下属建立信任，“疑人不用，用人不疑”。

什么是授权，我用个极端的例子，哪怕是下属去犯错，你也要眼睁睁的看别人犯错，而自己来承担所有的后果。除非你判断问题超过你的职权范围或者挽回范围，否则你不能直言相告。“看着下属犯错，自己却不能说” 这点是最难的。因为你说了，这些经验就永远是你自己的，下属不在错误中成长，管理者就是永远的瓶颈。这是中美文化最大的差异，也是创新企业和传统企业管理方法最大的差别。

“允许犯错，但不允许同样的地方持续犯错”这也是在后续文章讲“文化构建能力”时会讲到的。是否做到识人 & 授权，是管理者是否可以管理超过 100 人团队的门槛。

坦诚 & 开放：营造一种氛围，绝对的透明和坦诚，绝对的开放

如前面所说，一个技术管理者不一定是公司技术最强的人，这很好理解，在公司小的时候往往是技术最强的人，随着技术团队的壮大，如果他还是各方面技术能力最强的人，那么他一定是这个公司的技术瓶颈，会被公司淘汰。

但是作为技术一把手，他一定是公司里对技术人员最坦诚、最开放的人。举一个我自己的例子，刚到易观的时候技术团队还不够给力，技术债很多，一次严重事故的时候，整个技术团队 48 小时没有解决一个平均 QPS30 多万 - 峰值快到 100 万的数据接收问题（一天快 200 亿条数据接收 IP 还是写死的，资源还不够 LVS 后面 netty 还是 tomcat 业务都撑不住 @_@），没办法，自己上阵用 72 小时学了 lua 和 openresty 分流了压力，按照我设想的逻辑重构了接收端，临时解决了问题。

等到我招到好的技术人才，把项目交接给他的时候，他公开的非常直接的对我讲：“大侠，你写的这个东西什么破玩意啊，有更好的函数为什么不用，看这里写的简直画蛇添足……”巴拉巴拉地把我训了一通。

一方面，我坦诚承认我的不足，在那个环境下如果他来了，肯定比我解决的更漂亮；另一方面我很高兴，在会上我们可以开诚布公的就事论事，没有谁是权威，只是坦诚、开放的讲对的事情。这样才可以容纳更牛的人，让事实带领全公司的团队走向正确的方向，而不会因为个人的误判导致整体的失败。

如何建立这样的文化和体系，后面的文章会和大家分享，坦诚 & 开放是一个团队走向持续增长的必要条件。

悟性 & 个人魅力：悟性与个人魅力是一个管理者的必备的软技能

没有一个人是天生的管理者，所有的管理经验都是通过不同的管理实践和反馈中积累起来的。对于同样的一个人或事情，管理者从中参悟到什么，理解到什么程度，是一个管理者是否可以持续提高的关键。所以作为高级管理者，至少留给自己 20% 的时间在思考，而不是具体做事情，反思自己的决策、沟通、影响、开放当中的问题，是否可以有更好的方法来提高，这样才可以让自己持续在管理岗位上提高。

而个人魅力是和管理风格息息相关的，尽管每个管理者的管理风格都不太一样，但是你发现做到高层管理者的人，去掉这个管理者的 title，在其他领域的普通沟通当中，他依然有特殊的人格魅力让他闪光，让他身上具有一种“领袖气质”。这点并不是通过专业性辅导可以做到的，而是管理者自己在做人的方面要有更深的理解和见地，反复的参悟自己、提高自己才可以做到。

所以，大家看到很多高层管理者开始大量阅读非专业的书籍，也是源自于此。一个人能做到什么样规模的高级管理者，和他对于自己、对于业务、对于管理甚至对于世界的参悟程度有关系，最终管理的瓶颈是对于自己对于世界的认知瓶颈，而不是技能瓶颈。所以，专心阅读《技术领导力 300 讲》和各种知识含量的书籍、杂志是扩大自己认知边界的好方法。

最后，大家可以看到管理是没有年龄界限的，无论是一个 70 后、还是一个 00 后，一个具有决策力、沟通力、识人 & 授权、坦诚 & 开放、悟性 & 个人魅力的技术领导者是一个有领导力的技术一把手的必要条件，而体系搭建能力、文化构造能力、人员管理超能力、技术实力也是一个技术一把手不可或缺的，这些请大家持续关注我在《技术领导力 300 讲》的“打造技术管理核心能力”系列文章。

作者简介

郭炜，易观 CTO ，中国软件行业协会智能应用服务分会副主任委员，TGO 鲲鹏会北京分会董事会会长。负责构建易观技术团队、完成易观大数据采集、平台、数据挖掘等技术架构与体系；从无到有完成易观混合云的搭建、以及易观 SDK 的升级，并发布易观秒算实时计算平台。目前易观大数据平台日处理数据量 30T ，272 亿条，月活用户 5.5 亿。

第9讲 | CTO是商业思维和技术思维交汇的那个点

CTO 这个岗位，在今天的任何一家互联网企业中显然都是不可缺少的，特别是处于创业阶段的企业。当我在微信群里发出一条“推荐靠谱 CTO”的消息后，会瞬间被无数红包砸到。但当我试图了解他们对 CTO 的需求时，回答却迥异。同时，在 CTO 的圈子里，我又经常听到对这份工作的迷惘甚至抱怨。

我非常不愿意把人群分类，用标签的形式去评价。但我认为，在任何一家对技术需求较大的企业中，确实存在两类差异较大的人群，一类偏商业性思维，另一类偏技术性思维。而 CTO 恰恰就是这两类人群交汇的那个点。

CTO 的“本职“工作

站在 CTO 的角度，我认为以下三类工作应该算是本职工作。

第一，团队建设。包括招新人，培养人，淘汰人。如果团队大了，还包括文化建设，制度建设，层级体系建设。

第二，还技术债。例如 TutorABC/vipJr 是一家有 20 年历史的互联网企业，有大量的老系统，老代码。我的一个重要任务就是解耦和重构。我相信所有 CTO 都面临这个最难最复杂的问题。再难你也要解决。边开飞机边换引擎，早已经是普遍的做法了。

第三，技术升级。互联网技术日新月异，CTO 需要让一些新技术落地，开花，提振士气。2017 年，TutorABC/vipJr 的两项技术成为亮点。基于 WebRTC，后端用 Go 语言实现的新一代音视频技术 TutorMeet+，实现了在丢包率 20% 的不稳定网络环境下，仍然让学生和老师顺畅地进行双向互动。大数据系统不仅让数据处理能力提升了 2 个数量级，还让业务的数据分析速度提升到秒级。自定义报表进一步提升了数据分析效率。除此之外，我的年终总结还包含了可用性数据，人效数据等其它支撑数据。

其他 CTO 的年终总结或许还包括异地多活技术，小程序，AI，甚至区块链技术等等。CTO 们带着各自的技术团队忙活了一年，交出这样的作业后，公司们都满意吗？我认为，做到以上三点是必须的，是及格，但未必得高分。作为交汇点的那个人，CTO 的作业还应该包括公司的商业价值。

CTO 还可以做什么？

除了做好公认的“本职“工作以外，CTO 还可以做什么？这显然是因人而异的。结合 2017 年的工作内容，我在这里分享一些实际工作案例。任何行动都是思维的产物。所以我把它们抽象为四种思维方式：效率思维，用户思维，跨界思维，和商业思维。无论是哪种思维，都必须对应到公司的商业价值，都应该以产生商业价值为最终目标。

效率思维

提升内部效率通常是 CTO 最容易切入的点。大家的方法会有很多相似之处。比如改进工作流程，推进数字化管理，通过自动化代替人工等等。但 CTO 很容易陷入的一个误区是，只用报表证明自己的成绩，而非用公司的成本来衡量效率。

内部效率的提升，通常不是省了钱，就是省了人。但省出来的钱或人去哪里了？公司的总费用或总人数下降了吗？辛辛苦苦省出来的钱或人，有没有被拿去做了效率更低的事情？如果回答不了以上问题，效率提升也许并没有真正发生。

在 TutorABC/vipJr，我们在客服系统上投入了大量研发资源，包括人工智能。对于在这方面的效率提升，我的目标很简单，就是大幅下降客服的人数。当然前提条件是客户体验不能下降，其它部门人数不能因此上升。这就是我今年的主要目标之一。我建议 CTO 们看效率的时候，不仅要看局部效率的提升，还要看全局效率的提升。只有全局效率提升，才能为公司真正节省成本，创造价值。

用户思维

CTO 通常比较善于通过表面现象看本质，也比较喜欢系统性地根治问题。我们可以把解决客户当下问题，解决表面问题定义为短解；把系统性地根治问题定义为长解。当寻求短解和长解平衡时，CTO 比较容易倾斜到长解这一端。但是在今天高度竞争的互联网环境中，如果短解不够，不能立刻解决客户的当下问题，很可能导致客户流失和失去竞争优势。

很多时候，问题经过层层汇报后，已经失去了当时的温度和紧急性，从而衰变成了没有温度的数字。这时候很容易选择长解而忽略短解。例如，在服务中，数据显示有万分之一的用户有某种问题，我们往往觉得问题不大，还有比这个优先级更高的问题。但如果是我们自己或者亲朋好友碰到这种问题时，我们就恨不得要马上解决，立刻解决。后者更紧急的原因是我们对用户有很强的感知，有同理心。而前者已经变成了冷冰冰的数字，激发不起我们的同理心。

CTO 可以解决这个问题。一方面，可以通过系统，尽量让用户的问题原汁原味地传递到后台，让解决问题的人看得到当时的场景以及对问题用户的紧急程度。另一方面，CTO 需要激励和培养团队的用户意识和用户思维能力。只有让更多的员工做好短解和长解的平衡，公司层面的平衡才能做到更好。

跨界思维

有些 CTO 做过多个行业，有些 CTO 了解多个行业。我认为跨界思维是 CTO 特有的技能。而这个技能或许可以给企业带来很大的价值。

TutorABC/vipJr 虽然是一家在线教育的公司，但我们的做法非常跨界。在整个教育行业中，几乎所有公司都采用学生选老师的模式。学生是客户，老师提供服务，客户选择服务，貌似这是天经地义的。但我们在很早以前就颠覆了这个思路。我们决定不让学生选老师，而是通过算法来匹配老师。其实我们做了教育行业的滴滴和 Uber。大家试想一下，如果打车软件让你选司机，会怎么样？很可能的结果就是，要么你选的司机离你很远，空车过来接你很浪费司机资源；要么你选的司机正在接客人，不能服务你。这就是目前很多在线教育企业的问题之一，一边企业拼命增加老师，一边客户抱怨选不到他们想要的老师。

我们的 DCGS（动态课程匹配系统）很好地解决了这个问题。不仅如此，DCGS 还可以做到 1 对多的小班课。大部分在线教育公司还停留在 1 对 1 的水平。1 对 1 上课，类似普通打车。而 1 对多小班课，类似于顺风车 / 拼成模式。DCGS 通过算法，做到了把多个水平相当，兴趣相似，对老师的偏好一致，上课时间相同的学生匹配到一起。

DCGS 的另外一个创新是真正实现了个性化的非线性课程教学。线性课程就是普通课本，上课顺序必须从第一课到最后一课。DCGS 可以做到非顺序，非连续的个性化教学。例如根据计算，某个学生从第 8 课开始，然后跳到第 15 课，然后再跳回到第 3 课。线性课程在传统教育中被认为是再正常不过了。但试想打车如果也是这样，每辆车都必须像公交车一样走固定路线，是不是很滑稽？

CTO 是一群经常接触互联网最先进技术，最先进商业模式的人。如果我们能跳出自己的行业，看看其它行业在怎样解决问题，或许能给我们的企业带来非常大的创新机会。我觉得自己很幸运，能站在前人的肩膀上，把跨界思维发挥到极致，让我们和普通竞争者在不同的赛道赛跑。

商业思维

绝大部分技术和产品研发在公司中属于成本中心，是后台支持部门。但如果技术逐渐强大之后，也许可以利用技术直接产生商业价值，让后台直接变成前台。

我们在 2017 年看到了青少年编程这个市场在逐渐变大。于是我们决定由研发团队内部自己孵化，并且不占用公司任何的额外资源。我们自己设计产品，做市场营销，自己运营“vipJr 青少儿编程”微信公众号，然后通过朋友圈转发来获客。我们的产品经理和程序员兼职做销售，通过微信来转换客户，引导客户去自助购买我们的课程。最后，我们的程序员兼职做老师，和家长约定时间，给小朋友上 Scratch 课和 Python 课。从产品设计，产品定价，市场营销，到销售，到服务，技术部完成了闭环。

这件事不仅为公司创造了新的商业价值，也让技术部从后台走到前台，亲身体验产品，营销，销售和服务这几个核心环节。这对于技术部直接参与到公司的核心业务中，有着非常大的促进作用。一个充分理解公司商业模式的技术团队，一定是公司的核心竞争力之一。

结语

现代的企业对于技术的依赖越来越大。CTO 是企业中商业思维人群和技术思维人群的交汇点。因此，CTO 在商业策略和组织策略中扮演的角色是枢纽。好的枢纽可以让信息沟通顺畅，让商业决策变得快速，让技术能力得以释放，让企业高效并充满竞争力。

作者简介

汤峥嵘，TGO 鲲鹏会上海分会会员。2016 年 10 月 18 日正式出任 iTutorGroup 集团首席技术官（CTO），于 2018 年 1 月 3 日升任为 iTutorGroup 集团首席运营官（COO）。曾在阿里巴巴历任淘宝网、支付宝、B2B 的资深总监及日本阿里巴巴、途牛网的 CTO，并先后负责淘宝网架构迁移、支付宝网站创建、国际网站、途牛整体技术架构、淘日本的技术研发项目。

第10讲 | 创业公司CTO的认知升级

在不同的行业中，以及不同公司在不同阶段，对 CTO 的要求是非常不一样的。同时任何一个时期，对 CTO 的能力要求其实都是综合的。

我所在的公司是一家创业公司，我是公司的联合创始人和 CTO。我想结合我在公司不同阶段的经历，谈谈我对 CTO 这个岗位的认识。

公司初创期

大多数互联网创业公司，一开始都是从几个人开始干起，我们也不例外。这个阶段最重要的是如何快速开发，快速试错，通过试错不断验证自己的 idea 是否靠谱。而对于技术架构是否可扩展、研发流程是否规范、绩效考核等则不会过多考虑。

记得我们在开始第一个产品的时候，直接写 JSP 页面，不需要前后端分离（因为我们也没有专职的前端），数据库则用了 Schema free 的文档数据库 MongoDB，无它，就是追求最快迭代开发速度。

这个阶段的公司，应该建立怎样的认知呢？首先是创业越早期风险越高，其次是低成本试错。那么作为 CTO 或者技术负责人，你的决策也需要匹配公司当前的状态。

比如招人方面，从匹配性上看，如果候选人没有创业心态，过于追求安稳，就可以 pass 掉；从技术画像上看，一个全栈工程师会比一个技术专家更能帮助到团队。

比如技术选型方面，不要犯杀鸡用牛刀的错误。尽量选择轻量级的框架，考虑最大化团队的开发效率为核心。在产品还未被被验证之前，过于超前的为大规模用户使用、超高并发和海量数据访问投入设计，很可能最终只能轮为摆设。因为产品的死亡率极高，方向也随时可能发生变化。

网上流传着腾讯的 QQ 服务端架构从建立初期一直沿用到现在的说法，腾讯的 CTO 张志东在一次内部培训中被问及此事时，很坦诚地说，其实 QQ 的架构一直在不停的改造和优化，到目前为止已经做了 4~5 次的调整。当初创业时候的规划是：第一年同时在线人数到达 1K，第二年 2K，第三年 4K，第四年 8K，第五年就可以上万了，而实际上第五年的时候腾讯已经做到了 500 万的同时在线数，目前 QQ 支持的最大的同时在线人数已经超过上亿。张志东说，如果 1998 年创业初期，就让他做到支持 500 万的同时在线人数，可能就不敢创业了。

高速发展期

一旦你的产品通过了用户和市场验证，公司可能会进入了新的发展阶段，这时候你才有机会接受进一步的考验。随时用户和业务的增长，产品需求可能越来越多，公司对产品的迭代要求更高，老的技术架构已经不能适应新的业务迭代，同时管理层也越来越关注产品的稳定性对客户的影响，你的团队人员在不断的膨胀，而你还没有准备好绩效管理，也还不知道如何去淘汰不合适的员工……

开始接近自己的创业梦，发现梦想并不是想象中那么美。在公司的高速发展期，问题产生的速度远比你想象中快。这个阶段的 CTO 应该建立怎样的认知呢？

我总结有三点方面的思考非常关键：

第一，抓大放小，区分主次。分析清楚当前主要矛盾和次要矛盾，重点解决主要矛盾。把当前的问题、内外部需求、公司的规划进行梳理对比，找出核心问题，重点投入。

在我们公司发展历程中，曾经遇到一些问题。首先是团队效率，在人员膨胀的情况下，如何保证做到小团队作战的人效。亚马逊的 CEO 杰夫·贝索斯有个“两个披萨原则”，如果两个披萨不足以喂饱一个项目团队，那么这个团队可能就显得太大了，沟通协作的效率很容易下降。把团队按业务或职能切分，可能是更好的方案。如果你的团队人员扩充上去了，生产力并没有跟上，那么是时候考虑团队规模是否太大的问题。

如何平衡各种需求？在我们公司的发展历程中，早期产品稳定性是我们的核心问题，当时我们内部同事也会反馈说竞品有这个功能那个功能，而且网站上页面看起来比我们舒服多了，这些需求我们能不能做？记住，资源永远是有限的，次要的功能不做不会影响用户的核心流程，页面长得不好看也不影响用户的使用。但如果产品不稳定，那客户是要跳起来的，所以我们早期研发的重心之一是做稳定性优化。

第二，追根溯源，从源头解决问题。特斯拉的 CEO 埃隆·马斯克倍受推崇的“第一性原理”思维，就是强调在基本事实的基础上探究问题的本源，不被过去的经验知识所干扰。在高速增长期，我们也会遇到各种各样的问题，从根源上解决问题才不至于反复的疲于应付。

比如面对产品的故障，是每次修复完就忙于下一个需求，还是重视复盘总结问题根源？这一点《SRE Google 运维解密》这本书提到的“事后总结制度”做得非常到位，除了追溯问题本质原因外，还建立了良好的总结文化，会收集事后总结内部分享，开放评论，对于良好的事后总结和事故处理还会做公开的奖励，甚至可以得到高层的点赞。

再比如技术债，技术债累积越多，后期的研发效率、问题隐患越多、维护成本越高，适时的解决技术债问题，是从长远考虑非常有价值的投入。

第三，充分放权，有效监督。早期小团队作战，也许还能靠几个尖兵一招鲜，快速占领先机；中后期拉开战场了，必须要依赖团队作战，依靠制度管理。

首先，早期成长起来的 CTO，长期战斗在一线，冲锋陷阵以身作则的品质自然是不用说的。但是作为最高指挥官，最难得的是需要自知和自省，知道自己的短板和优势是什么，知道如何补自己的短板，不管是找到比自己更强的人，还是依赖团队的力量，这要求 CTO 具备有大局观和开阔的心胸。我们看到很多公司设立技术委员会、架构组等技术决策层，也有些公司设立联席 CTO，其实是非常好的尝试，既下放了一些技术决策权，又补充了 CTO 可能的技术短板，同时也可以根据需要，对 CTO 的技术决策权做一定的约束，形成互相监督。

其次，团队作战，也讲究排兵布阵。按业务切分，还是按职能切分？还是更复杂的混合架构？孙子兵法曰：“知己知彼, 百战不殆”。需要结合团队成熟度、业务特点和竞争格局考虑，要求 CTO 除了了解自身团队特点，还要熟悉行业竞争格局，以制定出最强有力的打法。阿里巴巴搞出了“大中台、小前台”组织架构，即作为前台的一线业务会更敏捷、更快速的适应瞬息万变的市场，而中台将集合整个集团的运营数据能力，产品技术能力，对各前台业务形成强有力的支撑。

最后，有不同的团队，就需要更多的将军。在这个阶段，要有意去选拔和培养合适的 leader，建立人才梯队。但人才培养、团队建设都是一个长期的过程，并非一蹴而就。高速增长的阶段，也要适时去补充能独当一面、身经百战的大将，在专业能力、技术视野、管理经验等方面补充团队的不足。不至于出现“蜀中无大将，廖化作先锋”的悲哀。同时对于新上任的将领，作为将军需要知道每个人的局限在哪里，每个人都不是完美的，要知道如何去补位和防范，以制定有效的监督。

稳定发展期

经历了早期的试错和高速的发展，公司可能会进入一个相对稳定的发展阶段。为了公司长远发展，公司需要不断的进行新业务探索、不断进行技术的创新，CTO 对新技术的判断力和商业敏感度会越来越重要，CTO 的视野关系着公司的未来。就像前微软 CTO Nathan Myhrvold 所说：“My job at Microsoft is to worry about technology in the future. If you want to have a great future you have to start thinking about it in the present, because when the future’s here you won’t have the time.（我在微软的主要工作是关心未来的技术。 如果你想拥有一个美好的未来，你现在必须开始思考它，因为当未来来临时，你就没有时间了。”）

我们也看到了很多优秀的公司，在技术上所做出的超前布局。全球公认的最优秀的 CTO 之一，亚马逊的 Vogels 在一次采访里介绍了 亚马逊在机器学习领域的技术布局。他介绍说，在过去的 20 年间，已经有多达数千位软件工程师在亚马逊参与了机器学习项目。他认为亚马逊是一家在业务领域使用人工智能和机器学习技术的前沿公司，也正是因为不断地创新，才会让业务发展不断突破瓶颈。

写在最后

就像电影《后会无期》中所说的：“听过很多道理，却依然过不好这一生”，每个 CTO 的经历和挑战大不相同，只希望以上分享的经历能抛砖引玉，对大家能有一点帮助。

在创业路上共勉！

作者简介

林佳齐，云片网络 CTO，TGO 鲲鹏会杭州分会会籍委员 & 服务委员。2010 年加入淘宝，参与淘宝搜索技术的改造与优化、淘宝去 IOE 等项目。2012 年创业， 负责技术团队搭建和管理、核心产品研发和运维保障。从为淘宝商家提供 CRM 服务的维客软件，到为企业提供短信、语音、流量等服务的云片云通讯平台，对高可用、高并发系统架构设计有丰富的实践经验，对于云通讯技术和稳定性实践有深厚积累和独到见解。

第11讲 | 最合适的技术才是最有价值的技术

很多技术人在最开始工作的时候，都会有一种误解：做技术主要的工作是要和计算机打交道，而不是和人打交道。只要技术足够牛，不用考虑太多其他的事情。但是随着时间的推移，大部分人的看法也有了很大的改变。

好的技术一定是从公司的状况出发，最新的、最先进的技术不一定就是最合适的技术，最合适的技术才是最有价值的技术。作为技术领导者，又该如何去把握呢？我们就这个问题采访了几位技术负责人。

花虾金融 CEO、前宜人贷 CTO 段念：

在我看来，技术本身是为业务支撑服务的，换句话说，技术所有的价值最终都要通过业务结果来呈现的，我不认为技术可以独立于业务之外去体现它的价值。所以从这个意义上来讲，所有对于业务有好处的可能，我们都愿意花时间和精力去尝试。

当然对于技术，我的另一个观点是，所有重复性的事情都应该被具体的程序化的方式所替代。所以我一直试图找到一个平衡，一方面技术是为业务支撑提供服务的，但技术人应该 do smart things，应该用聪明的方法做事情，而不只是作为业务的一个实现手段。

一个好的管理者首先应该面向目标，这意味着他不会关注太多范围、界限，而是奔着把这件事情的结果给搞定。所谓目标，可以用简单的整个公司层面的目标来解决，但同时它也需要落地，每一个团队和个人都需要知道自己的目标是什么。这个目标并不是一定要去改变什么，但需要始终在组织中间做一个清晰的传递，让大家都清楚。

另外，面向目标也就意味着整个组织的绩效管理、晋升体系等方面，都需要与之强烈挂钩。

融云 CTO 、TGO 鲲鹏会北京分会董事会成员杨攀：

我在微软有一段工作的经历，微软给团队的定位就是三个角色：产品、研发和测试。但实际上微软的团队模型中，这三个角色是互相交叉的，要求你每个角色都要懂其他角色的东西。在做任何事情的时候，都应该站在其他角色、其他知识领域上去考虑这个问题，当你能做到这样的时候，你在这个团队中就会是一个非常非常优秀的角色。

我觉得优秀的人，都至少能达到：1、能够清楚地认识到什么东西是对的。2、在知道是对的情况下，愿意去把事情做得更好。我是一个特别有洁癖的人，我会要求我的团队在写中英文混杂的东西的时候，按照一定的标准去写。

要了解什么是正确的，认同正确的理念，愿意按正确的理念去做事情。

极光推送 CTO 兼首席科学家 黄鑫：

无论我们是否承认，公司大了就需要划分部门，划分部门就需要有部门管理者，每个管理者一定会为自己的部门争取最大的利益，这个利益不仅仅是金钱层面的利益，还包括可控性、风险性等等。

举例来说，假设我们需要做一个需要多方配合项目，移动端会说我们负责的就是把数据传到后端，各种逻辑转换应该后端来做。后端会说我们负责的就是维持后端架构的稳定性，具体的业务逻辑你们来搞。数据会说你们能不能把数据清理好再传给我，这样我集群压力小。当然，三方都有自己的理由，大家都讨厌业务复杂度，保证技术架构的纯净。很多技术人员避免和其他部门产生过多的联调。这时，能站在中立角度去评估分工合理性的只有 CTO。

要做到这一点，那么自然牵引出了两个必备的素质：1、全面的技术能力，不求多深，但是可以听懂不同部门的诉求和技术方案，了解不同方案的技术难度。2、 优秀的沟通能力和说服能力，这一点无需多言。

恺英网络的技术支持系统副总裁 伍涛：

除了技术与管理，技术人应该进一步用商业思维武装自己，努力去思考如何帮助公司获取利润、提升市值。新的商业模式几乎都是挖掘出来的，敏锐的商业嗅觉非常重要。

我觉得最厉害的人是有理想的技术人，他们能把技术和商业结合。比如，Microsoft 的 Bill Gates 、Tesla 的 Elon Musk 、Facebook 的 Mark Zuckerberg 、小米的雷军等，那些伟大的公司都是这些有理想的、有技术背景的人创立起来的。

恺英是个小团队作战的公司，所有成功的产品都是靠业绩打出来的，在恺英只要做得好，就可以获得相应的回报。恺英看似低调，其实 2017 年有超过 16 亿元的净利润，能够做到这个业绩的公司并不多。能够取得这样成绩在于团队里有很多有互联网商业头脑的人，他们在思考如何在互联网行业里把握新的机会，机会来了就去做，然后把它迅速变大，成为公司一个新的业务。

苏宁云商 IT 总部执行副总裁、苏宁技术研究院院长 向江旭：

在创业公司，公司的业务需求、生死存亡肯定是首要问题，那技术领导者的思维方式也要把公司的生死存亡放在第一位，不需要考虑太多的系统架构更新。

但在构建系统、提出方案的时候，要跟 CEO 沟通清楚各个方案的优缺点，比如采取短平快的方式，前半年、一年系统可以支撑，但也许一年后要付出的代价更大，如果到时系统架构重构的话，对业务的冲击可能是现在的 10 倍。要把那些利弊、短中长期的厉害关系跟大家沟通清楚。

同时，技术领导者还要向 CEO 展示，技术不仅仅只是业务的支撑，技术还可以引领业务的发展。以电商为例，不是网站不宕机、可以卖货，就是一个好的电商系统，还需要研发大数据等技术，更好的理解用户、精准画像，做精准营销、做技术推送、提高转换率等等，这些都是帮助业务更好发展的。

Coding.net CTO 孙宇聪：

如果一个创业公司做不到统一开发环境和研发体系，那么势必会造成我们研发力量的分散。这就是为什么有些公司事儿特别少但人特别多，因为每个人所作的事情都不通用。

完全禁止创新是不可能的。因为作为一个公司、团队必须要尝试新鲜的东西，不然难以进步。如果一个团队老用旧的东西那他就领会不到外界的好处。举一个例子，这就和像园丁打理花园一样，你可以让花随便长，但到了一定时间一定要把长得不好的砍掉，选出其中一种，或者是有限的几种一定要留住的。最终的决定其实并不重要，重要的是要有这样一个决策的过程，以及强有力的执行。

作为 CTO 来说，我的工作就是抵住 CEO 的压力。每周我们要安排一些产品上的事情，也要留出一段时间来做架构上的整理，改进，统一。我需要给程序员们留出时间，创造条件来做这些长远的事情。 只要把程序员聚到一起，他们自然而然就会产生出很好的想法来，然后再把这些好的想法推广出去。

欧电云创始人 韩军：

作为公司的技术一把手，CTO 一定要把握行业趋势，我觉得在行业内去看技术可能更好一些，因为对行业理解得越深，实际上你解决 How 的问题的能力就越高。你最好在某一个领域达到专家级的水准，这对你往水平方向扩展有很大的帮助，因为很多的方法论都是相似的，你其实可以用在一个领域的深度去做一些思考，这对你有非常大的帮助。

其次是要从客户角度思考。这是非常难的一件事儿，一是因为你的客户有很多种，如高层老板、产品经理、开发人员等；二是你还要满足客户的客户，最终的用户才是产品最终有价值的东西，不是说今天满足客户就 OK 了，我还要满足其他用户的需求，这个难度就非常高，不是简单的说今天了解我的一个客户、一个想法就 OK 了，其实没有那么简单。

还要从业务角度思考。我们发现很多技术人员和业务人员的沟通经常是鸡同鸭讲，完全不在同一个沟通线。技术人员理解之后出来的东西不是业务人员想要的，再做一遍又不是想要的。很多时候因为没有同样的思维逻辑，大家其实是很难沟通的，所以作为公司技术的一把手一定要有业务思维。

结语

以上就是几位技术领导者对于技术部门在整个公司的定位的理解，哪些观点与你不谋而合，又有哪些观点是你之前没有想过的？欢迎留言与我们探讨。

第12讲 | 谈谈CTO在商业战略中的定位

“战略”一词最早是军事方面的概念，战略的特征是发现谋略的纲领。在西方，“strategy”源于希腊语中的“strategos”一词，意为军事将领、地方行政长官，后来演变成军事术语，指军事将领指挥军队作战的谋略。在中国，战略一词历史长远，“战”指战争，“略”指“谋略”、“施诈 "；春秋时期，孙武的《孙子兵法》被认为是中国最早对战略进行全局筹划的著作。

战略是一种从全局考虑谋划实现全局目标的规划，而战术只为现实战略的手段之一。实施过程中，往往又是要牺牲部分利益，去获得战略胜利。战略是一种长远规划，是远大的目标，往往规划战略，制定战略，用于实现战略目标的时间是比较长的。

争一时之长短，用战术就可以达到目标，如果是争一世之雌雄，就要从全局出发，去规划，这就是战略。那么，在互联网企业公司中，一般是由 CEO 制定战略，那么 CTO 在中间应该扮演什么角色呢？这个问题是令很多 CTO 感到疑惑的。

战略必须被认可和接受

首先第一点：作为技术领导者，首先要参与讨论战略，充分认可战略目标，并作为决策者的立场上接受。要站在整个公司的层面上，觉得公司的战略是可以实现的，也是合理的。用一句俗语来说就是：CTO 永远是要为 CEO 的“吹牛”去埋单的，但是，从职业的角度来说，不能玩死了。

大概意思就是，在总体战略下，CTO 作为技术领导者，至少需要从产品设计、技术落地两个层面去支撑战略在产品上的的落地，若不能理解并接受，产品是无法及时有效的落地，并推向市场的，连试错的机会也会失去。

其次，战略宣讲。任何一个团队，CEO、CTO……CXO，再怎么厉害，现代企业中，不可能靠一个人能将所有的事情都完成。同样，这些不同团队的负责人也不能将一家公司的战略在战术上完美落地，必须依靠一个核心团队，依靠能够理解，并接受战略，且各自不同分工的团队。如何让核心产品和技术团队推进落地，对其核心团队进行宣讲，并让核心团队能够接受，作为技术领导者在对战略的分解，在战术上的具体落地，策略的制定，等等，时刻被考验着。

战略宣讲的三个步骤

那么如何进行宣讲呢？就我的经验来说，一般宣讲分为这么几个步骤。

第一步：战略制定者从全公司层面对公司来年的目标、运营模式进行宣讲。这种情况下，一般面向公司全员宣讲来年的目标，讲解制定目标的意义，制定这些目标的依据。这种面向全员的宣讲，最大的问题并不是无法将目标和战略详细的讲解清楚，也不是担心整个公司层面是否能够接受，而是在于如何能够清楚的描述为什么能够完成这些目标，完成这些目标的底气和信心来自哪里。这些都是在宣讲过程中，需要向全公司层面清楚的描述的，同时核心管理层要给大家展示以及表达能够完成这些目标的信心。

第二步：这一步最重要的点就是战略和目标分解。公司层面的目标定义完成，接着就需要每个团队根据目标，认领自己团队的目标，团队负责人对团队目标进行分解。实际上这里是对整个公司来年的目标的进一步分解和目标宣讲。这一阶段实际上最重要的是根据公司的目标，在产品和技术层面的支持。为了达到公司既定的战略目标，产品的设计思路是如何提供对完成目标的支持的。以及在产品思路上，技术的架构设计思路，技术路线设计，以及在技术上的落地策略。

再次，落地策略、资源调配。战略再高大上，最后也要靠战术推行落地。若只是战略上的宣讲，而没有最后的落地策略，往往会被认为是吹牛。作为 CTO，理解并接受战略之后，接着就要做产品策略，设计产品思路，其核心思想一定是在产品上体现战略。围绕着公司的整体运营思路，体现产品的设计思想。产品的设计一定是整体运营思想的体现，在这个中间，CTO 一定要带领整个产品、技术团队，在既定的战略思维指导下，对产品目标、策略进行设计，确定产品的范畴，明确产品诉求、目标客户群体，设计产品具体的运营玩法。

能解决问题才是合格的 CTO

确定产品的设计思路、目标群体、产品范畴等之后，就要调配资源进行落地，此时，作为产品、技术的领导者，对其基本功底的考验就变得非常重要，如何在现有资源上，对资源进行最优化的配置，产品功能如何抉择，合理利用资源，优化资源，最大化利用资源合理设计并执行落地，是需要技术领导者去做的事情。

至于很多公司的技术领导者觉得不知道自己该为战略做什么，其实这个问题一般是因为，CTO 尚未理解公司的目标定位，即便知道也是一知半解，对公司的目标定位并不是完全接受。

有些技术领导者则是能完全理解并接受战略目标定位，但是并不清楚公司在这种目标定位下团队短板在哪里，需要补充的资源是什么，以及这些资源该如何补充。

对于这个问题，个人觉得，CTO 应该在充分理解之后，跟每个团队，尤其是不属于 CTO 负责的团队进行充分的沟通，理解这些团队的痛点，业务上的不足，设身处地的站在对方团队的基础上理解并接受对方的痛点，换位思考，对症下药。

什么样的 CTO 才能在商业战略上做决策？

那么合格的 CTO 应该具备什么素质，才能支持其作为核心决策者之一，参与公司的战略定位和经营决策？个人认为，至少需要具备以下几点素质：

至少在技术上的某一个领域独当一面，无论是架构设计、性能优化、服务端开发等，至少需要具备很强的经验，踩过坑，否则，对于技术上的经历更多的只会停留在纸上谈兵的层面。

CTO 未必要亲自写代码，但一定要懂得系统是如何通过代码实现的，懂得编程的原理，懂得程序员是如何干活的，各种方法的优缺点必须心中明白，说的直接一点就是，不能让下面的任何人把你给忽悠了。

架构设计是 CTO 关注的重点，未必亲自设计，但一定要了解各种架构的优缺点，以及当前选择的理由和依据，结合当前的业务发展，做最优的选择。

相当重要的一点是沟通能力，往往沟通能力体现的是两个方面，其一是表达能力，充分、明白的表达自己的观点，在跟不同的人沟通时，能用不同的语言和方式表达；其二是理解能力，不管跟业务方、产品经理、运营或者 CEO 沟通时，都能 get 到对方的真实意图，透过现象看到本质，获取最真实和原始的需求。

很强的产品意识和商业意识。任何商业模式希望在最后获取最大化的商业价值，技术是无法逾越的鸿沟，而 CTO 作为公司的技术最高指挥官，必须同时具备很强的产品意识和商业意识，将业务和技术有机的结合起来，才能实现商业目标最大化的商业价值。

总之一句话，CTO 是为 CEO 的吹牛而埋单的，但是不要忘记，作为追求利润最大化为唯一目标的经营单位，任何一次的目标定位，都是生死抉择。作为核心决策者之一，理解接受只是最基本的要求，充分参与其中，合理调配资源，并解决问题才是合格的 CTO。

作者简介

吴万港，前中恒云能源 CTO，TGO 鲲鹏会杭州分会服务委员 & 学习委员。10 多年的互联网行业从业经验，带领多个团队完成设计、研发了分布式 K/V，分布式数据库，日处理达到百 T 级别的分布式文件系统。8 年以上互联网行业大型的产品、技术团队的建设、团队发展、团队管理经验。对于从产品需求、技术实现等管理方面有全面的认识和实践经验，深入理解敏捷研发管理办法以及多年的实践经验。

第13讲 | 把脉高效执行的关键要素

曾经有个公司的高管跟我说，“竞争对手家的团队”天天加班到很晚，于是也想让自己团队实施 996 工作制，问我怎么看。

我问他，希望通过 996 来达成什么目的？他一时语塞。

我其实挺理解他的感受，他希望事情能够做得更快，团队更有干劲，产出更有效率，让整个公司跑起来，至少比竞争对手跑的要快。我也理解他为什么会语塞，在创始人眼里，创业公司就是要热火朝天啊，就是要 996 啊，就是要比竞争对手更努力啊，这还用问吗，至于要达成什么目的……没仔细想！

但我还是要问，因为 996 终究只是手段，而手段必定需要为某个特定目的服务，目的还不明确的时候，手段的有效性是无法评判的。我们靠“理所当然”的常识做决策，往往达不到我们想要的效果，甚至事与愿违，唯一的效果就是阶段性的自我安慰。

高效执行，本身也并不是目的，而是达成特定目的的手段。因此，当我们探讨如何打造高效执行团队的时候，就不能只谈论“执行”本身。那么，要谈论哪些内容呢？

什么是高效执行

为了避免我的个人狭隘，我做了一个公开小调研，当提及“高效执行”的时候，大家第一印象是什么？回复我的有一线员工，有经理层，也有创业者，集中在下面这些词句：

“令行禁止、不拖延，军队”

“多做少说、决定干了就干，别讨论了”

“发奖金、扣工资”

“实施 996 997”

“红色性格”（热情、奔放有力量）

“理解沟通”

“时间管理”

“项目管理、过程控制”

“目标明确、收益明确”

……

看到这些反馈，我的内心是崩溃的：即便是背景相对一致的朋友圈，大家对“高效执行”的理解都这么大差异，探讨这个话题是多么有挑战的一件事啊。

好在，人类有一项特异功能是其它动物所不具备的，那就是使用隐喻去提炼问题的核心。于是，我们也借用一个简化了的管理模型：把执行一项任务，看做是把一架马车驾驶到特定目的地，他们都是要带着队伍去达成某个目标。所谓“高效执行”，就变成了如何尽快地到达目的地；而管理者，此时就变成了一名马车夫，他能否快速到底目的地，大体取决于 3 个关键因素：

1) 每匹马用多大力气拉车。

2) 多匹马是否步调一致，且往一个方向走。

3) 马车是否在有效地朝着目的地方向前进。

用一个近似公式来表示是：

路程

—》速度 x 时长

—》马车动力 x 方向有效度 x 时长

—》单马动力 x 步调一致性 x 方向有效性 x 时长

对应到团队管理和任务执行中，就是这样三个问题：

1) 每位成员的个体能力和努力的意愿。即，个体动力。

2) 成员间的组织结构是否合理，协作的节奏是否一致。即，协作水平。

3) 大家是否在朝着一个稳定的目标努力。即，目标清晰度 / 方向有效性。

对应的近似公式是：

绩效

—》效率 x 时长

—》团队合力 x 方向有效度 x 时长

—》个体动力 x 协作水平 x 方向有效性 x 时长

可见，每个公司都希望拥有的高执行力，除了时长这个“简单粗暴”的因素外，个体动力（能力 x 意愿）、协作水平（默契 x 机制）、方向有效性（目标清晰），是三个重要的着眼点，我们分别来探讨下。

个体动力和员工激励

我们先来看个体动力。一匹马能出多大力，取决于它的实力，以及使用实力的意愿，即个体动力 = 实力 x 意愿，对应到员工就是：能力 x 意愿。

个体实力的提升，功夫在平时的积累，其提升的方式也各有神通，我们不展开讨论。而意愿的激发，却可以是立即起效的，所以我们看到大部分的管理者都在意愿的激发上做文章，比如发奖金、扣工资等，这就是我们经常说的员工激励。

员工激励是个很大的话题，值得我们关注的是，目前职场上正在经历从驱动力 2.0 到 3.0 的转变，即从胡萝卜加大棒的外部奖惩驱动，过渡到以提升自驱力为特征的自主投入驱动，能够发挥优势，以及工作的目标感、成长感、意义感成为激励的重要手段，在员工激励的话题中，我们再展开来探讨。

协作水平和团队合力

是不是每匹马都尽力去拉车了，车就一定跑得快呢？

其实未必，如果几匹马用力的方向不一致，车有可能是不会动的；即便车辆设计非常好，马匹不会出现用力方向不一致的情况，几匹马的步调如果不一致，车速也不是最优。因此，所有马匹是否形成有效的合力，这才是决定车速的最终力量。

团队合力亦是如此，组织架构是否让团队成员往同一个方向努力，以及大家工作节奏是否协调一致，也决定着团队的产出是否高效。

当然，在团队中，两个员工出现往相反方向努力的情况并不常见，但是团队每位成员对一项任务的优先级有不同的理解，却非常普遍。在 A 手上是第一重要的工作，在上下游团队中的 B 手上未必是，此时信息同步和整体协调就显得尤为重要，那么，我们是否拥有有效沟通的机制呢？只是靠人的主动性，肯定漏洞百出。

目标清晰度和方向感

驾驶马车的方向感，其实就是一个团队的目标感。大家也许会问，目标设定是规划的范畴，和高效执行有什么关系？我想说的是，脱离目标来谈执行，这恰恰是最普遍存在的问题，这个问题至少会引发了三个不良后果。

第一是激励失效。如果你和一线员工有着顺畅的沟通通道，不难发现引发他们强烈抱怨和失去动力的一个重要原因就是需求变化太快，导致手头上的工作任务频繁切换，带来三个主要的负面影响。

1） 工作反复切换，之前的讨论、评估、设计、开发都变成了沉没成本，员工的挫败感不断累积，而成就感很少。

2） 时间越来越紧，挑战越来越大，员工不得不承担更大的工作压力和强度，引发员工焦虑和负面情绪。

3） 员工认为管理层没有想清楚，甚至是质疑管理层的能力，对公司和团队降低信任，甚至丧失信心。

清晰的目标，本身就是激励，目标缺失的团队和员工，是很难有效激励的。如果大家还有疑惑，你可以盘点下自己过往取得的那些最得意的成绩，回顾一下自己曾经有过的“心流”体验，你不难发现这些好的体验，都有一个共同特点，就是当时的目标非常明确，方向感非常好。

第二是协作失调。明确而认知一致的目标，对于团队所有成员保持统一的工作步调的意义，是非常显而易见的。相反，目标不一致的情况下，让员工保持良好的节奏和状态就变成了奢望。

除了对步调和节奏的影响，对于多任务优先级的判断，也便没有了最核心的依据，此时要想在沟通中达成一致意见，沟通成本非常高，所以才有人反馈高效执行的第一反应就是“多做少说、决定干了就干，别讨论了”、“理解沟通”，换句话说，低效率的沟通也是执行的一大障碍，而目标不清晰必然会导致低效率沟通。

第三是忙乱无效。高效执行，除了速度快，还得有效，所谓有效就是往正确的方向前进，即，离目标要越来越近。

快速执行的现象有两类：一类是看上去很忙；另外一类是真的忙得很有效，其区别，就在于核心目标的达成度。如果目标不清晰，就属于“瞎忙”，这种状态是不健康的。

从以上三个负面影响来看，目标和方向感的不清晰是高效执行的大敌。而这个问题却很普遍地存在很多公司中，却往往不被管理层重视，更常见的情况是——

老板说，我们目标一直都很清晰啊，不就是……，说了多少遍了！

管理者说，这也不是我能左右的……，而且这个时代也没法做长远规划……

员工说，方向总是变来变去……

归结起来就是，要么没目标，要么就是目标不清晰，要么是没有被有效解读和传达。

管理者除了要明确目标，还必须把握该目标的核心衡量指标，即，这个任务最核心的指标是进度（赶时间）、质量（稳定可靠）还是效果（功能完善），只有这个问题明确了，在碰到突发情况的时候，我们才能把握住决策方向，优先满足最核心的期待，让结果更加有效。

结语

总而言之，打造一个高效执行的团队，是一个系统工程，不能只是靠简单堆时间去达到所谓的“高效执行”，因为堆时间可能会让其它要素打折扣，比如员工意愿。当我们去诊断一个团队的执行力问题时，也不能头痛医头脚痛医脚，而要通盘考虑这些要素，从而找到高效执行的最大提升空间。

最后总结一下，高效执行的要素就是：

个体动力 x 协作水平 x 方向有效性 x 时长

（能力 x 意愿）x（默契 x 机制）x（目标 x 沟通）x 时长

作者简介

刘建国，TGO 鲲鹏会北京分会会员。果见管理工作坊创始人，聚焦于技术背景准经理和新经理的培养。埃里克森国际教练学院教练、国家认证职业生涯规划师、清华大学高级工商管理硕士（EMBA）。

12 年互联网从业经验，完整经历从一线员工、一线经理到 150 人独立部门负责人的全过程，培养出 40-50 位一二线经理。其中在百度 9 年，负责过百度知道、百度 passport、百度开放平台、百度 app1.0、百度手机助手 1.0、移动搜索等产品研发和团队管理，百度最佳经理人；创业 3 年，负责过天使轮到 C 轮各阶段互联网公司的 CTO 体系团队。

第15讲 | 定制高效研发流程

当我们的研发团队组织架构搭建完毕后，接下来需要思考的是，如何让这个架构跑起来、跑得快、跑得稳。此时，我们需要定义出一个高效的研发流程，还要尽可能降低研发过程中所遇到的风险，确保在流程的每个环节中都不能出错。

在定义具体的研发流程之前，我们需要从整体入手，先把研发流程体系架构定义清楚，便于让团队从全局上把控整个过程。接下来需要从局部入手，将研发流程中所涉及的操作步骤罗列出来，便于指导团队完成具体的工作。

现在我们就从整体开始，对研发流程的体系架构进行探讨。

研发流程体系架构

高效的研发过程应该具备“多线程”的特性，仿佛多条并行流淌的河流，上游是业务，中游的是产品，下游是技术，流量取决于业务，流速取决于产品和技术。

需要说明的是，这里的“业务”其实包括两类人：一是公司内部使用产品的业务同事，二是公司外部使用产品的最终用户。为了便于描述，下文统一将他们称为“业务需求方”或“业务方”，简称“业务”。

根据我的上篇文章可知，整个研发工作流程体系架构是职能团队与项目团队的有机结合，团队职责清晰且协作高效（如图 1 所示）。

图 1：研发流程框架图

在职能团队中，产品委员会的产品专家们将业务需求统一记录到“需求池”中。需求池中的每一个需求都要描述业务的当前现状，还要包括业务对产品的未来期望。每隔一段时间（一般是 1~2 周），产品委员会将根据需求池中所记录的需求细节加以讨论，并将优先级较高的需求进行立项和排期，项目团队可知晓近期需要实现的业务需求是什么，整个团队的方向感也更加清晰了。

需求池中一个典型的需求可包括以下字段：

需求名称：用一个关键词描述，最多 15 个字。

需求来源：该需求来自于哪里？包括业务、运营、财务、法务、市场、其他。

业务痛点：为何要实现该需求？即业务当前的现状。

需求描述：该需求具体是什么？即业务将来的诉求。

渴望程度：期待何时可以上线？包括：本周、本月、下月、本季度、下季度、未来、或具体截止日期。

需求类型：包括：新功能（从 0 到 1）、优化（从 1 到 100）。

需求规模：包括：大（两周以上）、中（一至两周）、小（一周以内）、未知。

备注：可写下对该需求的补充或疑问，以便深入交流。

附件：可通过相关文档对需求进行补充描述。

创建人：该需求被谁创建？

处理状态：包括：未处理（默认）、处理中、已处理、关闭。

优先级：包括：A（重要 & 紧急）、B（重要 & 不紧急）、C（不重要 & 紧急）、D（不重要 & 不紧急）、X（待定）。

负责人：该需求由谁跟进？

简单情况下，可使用电子表格的方式来维护需求池，比如：Numbers、Excel 等，当然也可通过在线方式来管理，比如：石墨文档、金数据等。

需要注意的是，需求池对公司全员共享，由产品委员会管理并维护，其他人员只能阅读但无法编辑。产品专家们首先需要和业务需求方进行有效沟通，深刻理解他们的业务痛点与未来期望后，才能将这些需求入池。

从需求池中挑出的高优先级需求将分别“流入”对应的项目团队中，在项目的执行过程中难免会遇到技术上的遗留问题，然而团队不希望因为这些问题而导致项目工期受到影响。因此，这些技术遗留问题将被列为“技术债”，技术委员会中的技术专家们将对这些技术债加以管理和跟踪，在后期会有针对性地解决这些技术问题，偿还这些技术债。

了解了研发流程体系架构后，下面我们进入具体的研发流程操作步骤。

研发流程操作步骤

将需求转化为项目，是一个复杂的过程，如果只是一个体系架构，恐怕也只是空中楼阁，因此我们有必要对整个研发流程体系架构进行细化，为其设计具体的操作步骤，以便让整个流程可以顺利落地。

我们可定义了以下 10 个操作步骤，将需求转化为产品，将产品转换为项目，将项目顺利上线（如图 2 所示）。

图 2：研发流程操作图

以上 10 个阶段，涉及到不同角色的人员，每个阶段需要包含当前所需完成的任务，也涉及到相关例行会议。我们可将这份操作步骤打印下来，发给每一位研发人员，并贴在会议室的墙壁上，每日站立会的时候，团队都能看得见它。我们会慢慢发现，每个项目团队都有相同的工作习惯，大家还可不断优化这份操作步骤以及其中的相关细节。

需要注意的是，产品经理在需求调研阶段，必须了解业务的当前现状，搞清楚业务痛点是什么？我们不妨这样做业务调研：如果没有这项功能，业务同事需要花多长时间、多少人力来完成自己的工作？当前的获客成本是多少？订单转化率是多少？产品经理需要将这些信息和数据记录下来，并丰富到需求池中。此外，在每次启动项目之前，需要得知该执行项目的目标是什么？如何来验证这个目标？

我们需定期对已上线项目进行复盘，可通过“复盘四步法”来完成：

审视目标：当初设定的目标是什么？目前达成的现状是什么？差异是什么？

回顾过程：回顾整个过程是如何进行的？大致分为几个阶段？每个阶段发生了什么？

分析得失：哪些方面做得好？哪些方面做得不好？为什么？

总结规律：再次做同类事情应该怎么做？对未来工作有何指导？有何规律、原则、方法论？

使用以上项目流程与复盘方法，可确保以正确的方法将事情做正确。但是，只能解决研发内部的闭环问题，似乎无法解决研发和业务之间的外部闭环问题，也就是说，研发和业务之间的高效协作问题还需进一步探讨。

研发与业务如何协作？

这个问题也许在许多企业中会存在，毕竟业务和研发的工作性质不同，关注点也不同，因此考虑问题的方式也会不同。

业务心中可能会这样认为：为何我们提出的需求，研发总是迟迟不解决？

研发心中可能会这样认为：为何我们上线的功能，业务总是迟迟不反馈？

我们似乎遇到了一个“死锁”问题，彼此都在等待对方。业务提出需求，得不到及时响应；当研发响应后，却得不到反馈。久而久之，业务和研发之间会失去信任，从而严重影响企业的可持续发展。

这里我向大家介绍一种新玩法，它能让业务和研发得到更好的闭环，而且让双方的协作过程变得更加顺畅。我们称这个方案为“特赞之声”（如图 3 所示）。

图 3：特赞之声

在公司内部，我们制作了一种叫做“特赞币”的虚拟货币，其实它只是普通的磁铁，币上贴了一个自制的图案而已。我们给业务部门发放固定数量的特赞币，为了避免“通货膨胀”现象，我们一次性不会发太多币，后期可根据实际情况适当增发。

当业务部门遇到痛点时，可在痛点卡片上手动填写具体痛点，并用特赞币将卡片固定在白板上。此时需要消耗一个或多个特赞币，如果一次性使用多个币，表示优先级更高。项目上线后，当业务部门提供使用反馈后，将得到一个特赞币，提出的反馈包括对已有功能的称赞或吐槽。

也就是说，提需求要“花钱”，提反馈可“赚钱”，这样可确保业务所提需求都是最大痛点，由于币数是固定的，因此需要通过提反馈来获取新币，这样研发和业务自然就建立了有效循环。

除了痛点和反馈以外，公司全员也可以提出脑洞，也就是对产品的奇思妙想，脑洞被产品委员会采纳后，可赠送一定数量的特赞币。痛点会使用特赞币将其吸附在白板上，反馈和脑洞可使用普通磁铁来固定。

使用特赞之声，我们得到了以下收益：

业务人员：业务痛点得到更好的重视，得以更快速地解决。

研发人员：产品价值得到更好的体现，产生更高的成就感。

彼此双方：业务与研发不再孤立，从而形成了完美的闭环。

写在最后

没有人愿意在一个复杂的流程上投入自己更多的时间，流程是帮助我们更规范地做事情，目的是避免犯错误。因此，在流程的定义上，我们可以先简单后精细，简单才便于操作，精细才易于管理。

以上我们提到的研发流程十步骤，对于大家而言只是一个参考模型，大家需要根据自身实际情况，作出合理调整，流程才能发挥出最大的作用。否则，它可能会变成一种负担，反而约束了我们前进的速度。

研发流程是团队的行动规范，是大家共同智慧的沉淀，流程高效，产出才能高效。

作者简介

黄勇，现任特赞科技（tezign.com）CTO，图书《架构探险》作者，Smart 开源项目作者，TGO 鲲鹏会上海分会董事会成员，QCon 讲师。十年以上互联网软件架构与技术管理经验，擅长敏捷开发，推崇“轻量级”架构思想。喜欢阅读，热爱交流，乐于分享。

第16讲 | 培养中层团队的管理认知

技术团队到达一定规模之后，要保持高效，中层管理者会变得非常重要。他们在团队中起到承上启下的作用，既要接受上层的指派，又要领导下层执行。如果中层管理者给力，上层的管理者会轻松很多。所以一定要选对中层，培养中层。

先做目标管理

在说中层团队的选拔和培养之前，先来说说我选择公司或者职位的理念。首先，我要去了解这家公司的目标是什么，我个人非常关注目标的选择。目标选择的好，就比较容易成功。反之，个人和团队都会比较辛苦，结果还不一定好。有了一个合理的目标之后，剩下都是一些执行层面的技巧，我很清楚如何去带领团队达成一个目标。

举个例子，我之前在盛大集团刚开始负责整个测试团队的时候，当时 CEO 觉得测试团队不能满足公司的期望。测试团队一般有两个指标，一个是速度，另一个是质量。其实不只是测试团队，绝大部分团队都是这样，很多时候这两个指标的实现上存在一定的冲突。

我意识到公司对测试团队的期望是速度能更快一点，避免因为测试花掉太多时间，而导致产品上线的延迟。当时的测试团队把过多注意力放在了测试质量上，时间用的比较长。

我做的一个最主要的改变，就是让整个测试团队了解我们真正的目标是什么，把原来以质量为重的目标，变成了质量和效率兼顾的目标。目标修改了之后，整个测试团队对公司业务的支撑就改善了很多。不到一个季度的时间，整个公司都感受到了测试团队的涣然一新。这是通过目标的选择和调整，让团队表现更好的一个例子。

在盛大在线的时候，我曾经带领数据团队做数据算法的研究，大概用了两个季度左右的时间，把我们广告的推荐算法优化，让整个点击率和广告收入提升了大概一倍。利用这个案例，我分享一些管理经验。

很多时候我们团队在做事情时可能会忽略一些东西，从而导致整个进展不够顺利，我要做的是帮助他们把事情理顺。那时候的实际情况是，团队已经在广告算法上探索了很长时间，但是一直没有很好的产出。我接手之后，比较全面地去了解了导致团队进展慢的原因。我发现了几个问题：一个是当时数据的准确性是有问题的，原始数据的准确性不够，导致我们被数据误导，结果自然不会很好。

另外，在广告算法提升场景上，我们也是做了一些判断。很多人在做算法的时候，会有些假设，很多时候我们认为某一个用户的唯一标识代表的是一个用户。其实在实际情况中，你应该想到，有的电脑白天是先生在用，晚上是太太在用，有一些类似这样的情况。后面我们基于这样的假设再去提升整个推荐算法，效果就会比较明显。

我想用这个案例告诉大家，有些目标达成过程中会出现一些困难，要能够全面的思考可能是哪里出了问题，问题解决之后，才会获得比较好的进展。

根据需要选管理者

在中层团队建立起来的时候，我会把这些亲身实战的管理方式传达给我的中层管理者。我现在的团队大概有五、六个中层管理者。每一个细分的团队都有各自的 Manager，包括运维团队、后端开发团队、移动端开发团队、测试团队等。

我是如何选拔中层管理者的呢？首先，我觉得很多时候不要去谈这个人是否是一个管理者。有时候一件事情需要很多人共同完成，也有些简单的项目开发只需要一个开发工程师。只有当你需要有些人把某个团队的整体能力或者整体工作效率提得更高，才应该去考虑选拔一些偏管理型的人才。

一线工程师需要做实际的工作，但是管理者更主要的目标是用各种手段帮助一个团队更好地提高产出，或者说提升整个团队的能力。我属于一个非常关注目标的管理者，围绕这个目标，我们会去了解是不是有合适的人来做管理者。如果内部有些合适的人，就会内部提拔，如果内部没有太合适的人，我会考虑从外部招一些管理人才，让他们来帮助我把团队的产出和整个技术能力提的更高。

很多管理者比较关注选拔中层管理者的通用标准，我认为不存在通用类型的中层管理者，也就没有通用的标准。关键还是要结合团队当时的情况，选拔最需要的管理者类型。

大多数时候，不同的团队需要的管理者都是不一样的。有些团队面临的问题是，由于经验不足导致很多东西做不了，大家都不知道应该怎么做事。在这种情况下，就不能找一个通常的人员管理能力较强的管理人员，而是需要一个过去做过类似事情的人，他只有在做这种类型的事情上有经验，才能帮我解决问题。另一些团队遇到的问题是内部沟通不够顺畅，激励机制不够顺畅，导致大家士气低落，这种情况下，我要找的管理者就偏向于更擅长人员管理和沟通的人。

做好教练

管理者选好之后，接下来才是培训。对任何中层管理者，首先，我一定会跟他们分享我对管理的认知。很多管理者对管理的目标、职责以及常用的管理方法还不太了解，其中包括管理的职责是什么，最主要的目标是什么，常用的管理手段是什么等问题。

一旦有了这样的认知，在一些具体的操作细节上面，他们才会有管理的概念，他们会在日常工作中实践一些东西。如果在实践的过程中遇到了问题，我会进一步跟他们一对一沟通，分享一些精髓。主要是让他们对自己的职责和大的提升方向有一个比较清晰的认识。然后，在日常工作中会根据实际案例、实际情况分享在不同的情况下应该怎么采取管理手段。

中层管理人员的时间分配也是大家比较关注的问题，我认为这个事没办法固定。还是那句话，不同团队情况不一样，有些团队人员比较少，内部沟通也比较顺畅，不需要花太多时间做人员管理，这时候我会要求管理者直接做一些技术方面的事情，提升架构能力，或者做一些产品的方案设计。让他们利用过去的经验，帮助团队少走一些弯路，让整个的团队产出更好一些。

有些团队可能在具体的业务技术经验方面还可以，主要是内部的沟通不够顺畅，这种情况，我就会希望他在人员管理方面投入更多的精力。

结语

最后，我还是要强调一下目标管理的重要性。不管管理什么样的团队，我首先会做的就是帮团队管理一个目标，让所有人都能理解这个目标。对于应该用什么方式为这个目标努力，我也会有比较清晰的设置。在设置完目标之后，我使用的是偏教练式的管理方式，也就是说，极少情况下我才会真正代替他们做事。更多时候是以教练这样的角色，了解他们在完成目标过程当中会遇到的困难，然后通过启发式的提问，让他们意识到他们应该做怎样的改变，才能够更好的完成目标。

作者简介

陆怡，医信金融 CTO，TGO 鲲鹏会上海分会董事会成员。20 年以上的技术团队管理经验。曾在盛大，eBay 中国研发中心任职技术高管，管理过各种类型的技术团队。2013 年作为技术合伙人，和朋友共同创立维金公司，提供互联网金融的解决方案和系统服务。从零开始组建产品技术团队，团队人数最多时接近 200 人。维金先后获得 IDG 和蚂蚁金服的投资。目前出任医信金融 CTO，全面负责产品和技术工作。

第17讲 | 团队成长要靠技巧和体系

谁都希望能够有一个牛逼的团队。但创业公司前期资金少，不可能全员都是牛人，所以也会引入一些在能力上刚刚合适或有一定潜力（比如实习生）且认同公司价值观的人加入，先让业务跑起来，再来优化结构。

从 HR 的角度，所谓优化，就是补短板，或许直接换掉来得更快，但作为早期加入有过苦劳的员工，这样太不公平。所以提升团队成员，让他们与公司一同成长才是团队领导者第一选择。

实战，毫无疑问是最快的提升方式。项目的压力会让一个人的潜力快速显现出来。但是时间过长且过大的压力会让人疲劳，所以除了实战外，我们应该还有一些技巧和体系来帮助团队成员成长。

如何来引导他们的成长方向

一个成熟的公司，会清楚的知道他们需要什么样能力的人才，所以根据公司的实际情况，构建一个清晰的 JobModel（能力模型），规划出不同层级的核心能力、通用能力及标准，可以对团队成长有较为明确的指引。

以二维火为例，一个 JAVA 工程师，他的核心能力为：
操作系统、编码基础，JAVA，网络协议、网络安全、数据库、架构设计、运维能力等。JAVA 这一项再分解成：

Java 语言基础：异常处理，泛型，reflection，annotation;

Java 基本类库：io, util

Java 高级特性和类库：class loader，bytecode，nio, juc 等

Java 多线程编程

Java 网络与服务器编程, TCP/IP 协议

Dubbo

开源产品和技术

JVM 原理和调优

每一项能力需要有三个等级的评定：

第一级是会用，有过三个到五个项目经验，对正常的语法、概念、配置、部署等方面有正常的认识；

第二级是熟练，有过十个项目以上的经验，能够指导他人进行工作并解决问题，同时阅读过源码；

第三级是能多深入源码，能够做较为低层的优化。当遇到无法解决的问题，能够通过修改源码甚至更换技术及框架来解决。

将来在对团队进行评级时，可以通过多个项目的代码来看出他对这项技术的掌握程序。同时这些能力和等级都会引导团队更加深入的对相关进行系统性研究。

文化和学习氛围比培训更重要

2012 年曾经有幸加入过支付宝技术大学，在这半年当中，除了建立了内部的培训和分享机制外，深刻的体会到，培训和技术分享本身带来的效果是非常有限的，在团队内部营造一种人人爱学习，乐于分享的氛围，建立一个持续学习的文化，才能让团队更快成长。

当然，培训本身的设计与实施也是非常重要的，例如阿里内部的三板斧、AMDP、青年禁卫军等体系化的培训，能够批量提升技术和管理意识并学习到一些技巧。

培训的设计应该考虑到不同层级，不同岗位对能力的要求，不可能一项培训提升所有能力。以下介绍二维火的两项内部培训设计：

火种计划：是针对每年实习生和应届毕业生组织的培训，里面会从非常基础的编程技巧、项目流程、各种工具的使用和企业文化等相关内容，最后还会有一个一周的练习，大多是一些内部系统的开发，顺便还能提升一下内部生产力。培训结束后，这一期的小组不会解散，会继续以民间小组的形式维护这个系统。

我 2014 年加入二维火，当时团队只有 20 人左右，急缺高层级的技术人才，但我们还是在当年年底做了一轮校招，招聘了 5 名实习生，并组织了第一次火种计划培训。当时团队也有人认为，业务已经忙不过来了，还要分出精力来带人，是不是划算。但是当这些实习生陆陆续续毕业并加入正式的项目组，解决了我们半年后的人才招聘问题。2015 年我们招聘了一名硕士实习生，实习半年就是项目主力，等到他毕业直接以 P6（高级工程师）入职，今年夏天有望晋升 P7（架构师）。

管理培训（初级、进阶）：针对主管、经理层级的管理人员进行基础的管理技巧培训，从组织结构设计、岗位模型、招聘技巧、授权、激励、绩效管理等多个方面进行深入的培训，后期所有的技巧都会由上级主管记录应用的过程，定期探讨。

很多技术高手没有得到专业的管理培训就直接上岗，往往连最基本的管理技巧也没有，只有粗浅的项目管理知识，这样带出来的团队一定在某些环节上出问题。

举个例子，有一名主管经常会在团队周会或办公区批评团队成员，这样给团队成员的自信心打击非常大。人都是感情动物，都会要面子。而激励讲的就是如何提升团队士气，奖励一个人需要在公开场合，而批评或指出问题需要在一对一的时候，这样效果才好。而奖励和批评都要具体到事例，不能空泛，同时事例经得起团队认可等等。

所以后面我们在挑选出团队管理者的时候，一定要经过各种管理知识的培训，另外需要更高级别的主管进行长期的辅导，才会正式任命，保证公司在团队管理上少出问题。

除了专业培训外，其他的培训例如一些通用能力，包括项目管理、沟通技巧、时间管理、会议管理等，可以多在公司内部挖掘一些讲师，给予他们一些额外的鼓励。

另一个对学习氛围有提升的方式是分享，尤其是内部分享，对一些较新的团队成员来说，是一个可以直接答疑解惑的好机会，而外部分享可以帮助团队成员去了解同行在领域中的技术应用方式。目前我们每个月都会和一些非常优秀的公司进行交流，比如同在杭州的有赞、又拍云、上海的饿厂等，都给团队带来了非常多的益处。

同时公司还鼓励参与外部专业认证培训，例如 PMP、以及一些云厂商提供的培训，报销所有费用。

最后再说一项建立培训和分享机制的好处，就是在招聘方面会有好的口碑，更容易招到有潜力的新人。

从绩效上给予激励和鞭策

如何帮助和鼓励团队成员成长呢，人都是有惰性的，或者很容易陷入具体的工作中。

这个时候作为团队的管理者，要为每一个团队成员做好职业规划和能力提升的规划，定期 review。绩效考核相信一定规模的公司都会用到，在这里建议把员工的个人成长放进绩效，当能力有提升时，给予一些实际的奖励。

提升的表现可以分为两个方面，一是应用在实际工作中，二是给团队做了一次成功的分享，都可以做为加分项，并告诉他这会做为将来晋升时的参考。同时也是在帮助他在公司内部建立自己的影响力。

如果没有做到，也要有相应的惩罚，来提醒他成长已经停滞，当成长速度低于公司和团队的成长速度时，会被淘汰，要做到丑话当先。

随着业务跟技术发展，研发具有技术挑战的系统平台，激发团队成员的潜力与热情，避免一直只做业务开发，技术成长慢，让他们取得技术成就感。

最后，给所有的技术管理者分享一个心态，很多管理者担心自己培养了很长时间的人才一两年后就跳槽走了。实习生成本方面比社招要低很多，你的成本其实已经收回了。也不要因为培养出来的人跳槽，就有了是不是给其他公司当了培训班的心态，其实这反而可以扩展你的团队在行业中的影响力，还有可能带回来一些人，同时也让我们反思给这些子弟兵的待遇是不是符合他们的成长。

作者简介

芦宇峰，花名红烧肉，前支付宝用户技术部 / 技术大学负责人，《旅途求助》创始人 &CEO，现任二维火产品研发中心副总裁， TGO 鲲鹏会杭州分会会长。首席按摩师，美腿控，健身无效达人。

第18讲 | 做到这四点，团队必定飞速成长

如何激发团队的斗志？

如何促进团队成员的成长？

如何帮助团队成员设定工作目标？

我相信这几个问题一定反复困扰着每一个团队的牵头人。方法很多、理论也不少，从 KPI 到 OKR，每个都是很多企业和团队实践的经验，但从我十多年的团队管理经验来看，这些方法和理论其实有一个共同的内核：摸清禀赋、认清目标、扫清障碍、列清奖惩。

摸清禀赋，力求人和事的匹配

摸清禀赋是第一步，我相信孙子兵法的“知己知彼，百战不殆”是众人皆知的古训。西汉晁错的《上书言兵事》也提到“ 卒不可用，以其将予敌也； 将不知兵，以其主予敌也”， 所以作为团队牵头人，摸清每一个团队成员的性格、能力甚至是健康和家庭状况，是帮助团队成员成长的第一步。摸清了成员的禀赋，也更有利于团队的分工，帮助成员找到合适的角色和位置。

一般来说，我们总能将一位同事从几个角度来评价，不管是 MBTI、九型人格还是近年流行的 DISC，其实都在做同样的事情——摸清团队成员的禀赋。

我们也可以加入更多的角度来评估我们的团队成员，思维方式更有广度还是更有深度、主动创新还是按部就班、聪明异常或是勤奋过人 、坚韧专注还是勇于探索，擅长哪些领域，熟悉哪些工具和技能。团队所从事的具体每项工作和事务，同样也可以从几个角度来分类，就像我们不太会赶鸭子上架，让一个设计师去写数据库的代码一样，“专注执行不容错型”和“勇于创新敢于试错型”显然也需要不太一样的成员。

工作的特性匹配了成员的特质，至少可以避免时间、人力和资源错配导致的浪费，也为团队的组建、短板的补强提供了方向。

讲到人的禀赋和事的特性匹配，这里还要提醒一下各位技术团队的牵头人，一定要和 HR 同事密切沟通，是不是要招人、招多少人、招什么样角色的人、补强短板还是建立优势壁垒、是不是需要空降一个牵头人，都需要和 HR 同事有统一的推演和规划；也千万不要轻视职位要求定义、面试筛选、背景调查的流程，哪怕是内部转岗最好也需要经过面试的过程。面试、背调就是一次全面摸清禀赋的过程。一千个人眼中有一千个哈姆雷特，HR 同事的视角和经验，也是很好的禀赋评价或分类的角度。

认清目标，规划合理的成长路径

如果说摸清禀赋更多的指成员的现状，那么认清目标讲的就是筹备未来。
未来当然也包含两层含义：成为什么样的人，做成什么样的事。事是团队乃至企业的目标，要由团队成员来执行；成为什么样的人，就是个人的成长目标，来自于工作、学习乃至生活中的磨练。

大家都大致了解“一万小时理论”，但是往往忽略了这里的“一万小时”指的是刻意实践所累积的时间，而不仅仅是打发消磨的时间。看一万小时电视剧并不能让人变成著名演员、编剧或导演，甚至连成为影评家的概率都很低，因为那不是刻意的实践而仅仅是打发时间。工作显然是一段带有刻意训练特征的时间消耗，虽然很多工作是出于谋生养家，但是花同样的时间、赚同样的钱，人总是希望做一些有助于成长目标、让你自己获得成就感的刻意训练。

和团队成员一起深入沟通，找到一个既能帮团队做成事、也能帮助成员个人获得训练积累成长 1 万小时的目标，显然变成了重中之重。

找出个人的成长目标一般分三步：找寻榜样，自省差距，分解突破。榜样可以是身边更出色的前辈，也可以是业界的大牛，甚至是几个实例的综合体，自省差距往往也可以和摸清禀赋结合在一起，然后从众多的差距中找到一个相对好入手、好训练、有助于成事的点，进行突破。

例如，对于一个软件工程师，写代码并调试就是一个带有刻意训练性质的本职工作，降低代码 bug 严重程度、提高代码和需求匹配度，就是不错的训练目标。突破的了代码质量的成长目标，也许代码中的逻辑严谨性或者代码编写的全局思维就是下一个需要突破的目标。

关于目标设定，我相信大家也都熟知目标设定的 S.M.A.R.T 原则。一个好目标一定具有：S 特定领域、M 衡量方法、A 实现路径、R 所需资源、T 时间范围 这五个要素。

这里我尤其想提醒大家近年来管理学界的一些补充：R 字母更有指导意义的解释是达成目标所需要的资源 Resources ，这一观点在 2013 年 由 John Lawler 和 Andy Bilson 提出 ，显然这个解释优于之前和实现路径 (Achievable) 含义相近的若干单词“Relevant 相关的” 或“Reliability 可靠性”或 “Realistic 现实的” 或“Reasonable 合理性”。

一个团队成员除了自身的能力、经验和人脉这些内部潜力外，最大的外部资源往往来自于团队其他成员的互补、来自于团队牵头人更丰富的阅历、经验和人脉。

扫清障碍，扶上马还得送一程

认清了人和事的大目标、分解逐个突破的小目标后，我们已经能够和团队成员一起设计出一些可行的路径，也许这条路径并不完善，还需要不断修正，但是至少这时，团队成员可算是在成长快速道路上入了门。接下来团队的牵头人，要做的一件事就是帮助成员一起扫清路径上的各种障碍，俗语也叫“扶上马还得送一程”。

送一程干的事情无外乎卸包袱、供粮草、 共填坑、调节奏、把方向之类。

合理的分配任务，尽量排除偏离个人成长目标（但是可能适合其他成员）、又耗费工时的工作事项称为卸包袱；

提供攻坚所需的关键性的数据、硬件甚至是经费称之为供粮草；

遇到困难和棘手问题，作为牵头人自己不能退缩，不能甩锅，甚至要敢于背锅，授权成员去试错，要和成员一起战斗，这才是共填坑；

因为企业的经营环境、团队的工作环境和个人的生活环境会不断变化，所以往往大目标不变的情况下，小目标却需要因应调整，及时调整前进的步点和节奏，才能不为环境所累；

环境的重压之下，节奏不断变换，团队牵头人还需要提醒个人成长目标和做事的初衷，避免为了成事而疲于奔命，一起把握既定的大方向。

在成长之路上提速的整个过程，也和驾驶手动挡汽车起步提速一样，踩离合（也就是卸包袱）、给油（也就是供粮草）都必不可少，坡起时还要借助刹车（也就是共填坑），即使右手不断换挡（也就是调节奏），也要紧握方向盘目视前方（也就是把方向）。

另外不得不提一句，如果团队的牵头人，并不享受带领团队成长“扶上马送一程”的过程 ，也不认为成为一个好的团队牵头人是自己的成长目标，那么请大胆的告诉你的领导，你更适合技术专家、科学家、架构师的角色，请婉拒团队的管理者、牵头人的任命，请不要把你自己的刻意训练时间累计在你不想要、不享受的目标上。

列清奖惩，用惩罚警示，用奖励提速

对于快速成长的团队，奖惩也要列清，尤其要避免功过相抵的糊涂帐。团队成员和团队牵头人一起设定的目标，既是承诺也是对赌；甚至因为团队成员的小目标和团队的大目标往往天然交织在一起，一个人的工作瑕疵就会拖累其他成员乃至整个团队；因此奖惩不仅仅是物质上的得失，更多是一种仪式，奖是仪式上的凯歌，惩是仪式上的警钟。

在对具体的成员进行惩罚之前，请各位团队牵头人先自我检讨三个问题：

我是不是足够了解这位犯错的成员，包括这位成员最近的健康、家庭等外部环境变化？

我有没有错配人和事，让成员从事了既不胜任亦不享受的工作？

我有没有帮助成员找到明确的目标和清晰的路径，并在路径上做好保障？

如果这三个问题中，有任何一个问题的答案是否定的，那么请先检讨你自己的工作缺位。甚至对成员个人的惩罚有时也不需要处罚金钱，也不需要记过存档，而仅仅需要的是集体复盘、自我检讨，然后修订目标，制定改进计划，让成员知耻而后勇、避免再犯。牛奶已经因为错误而泼出，与其纠结如何惩罚既成事实，不如把亡羊补牢、改进未来作为一种惩罚方式。

关于奖励，也请告别庸俗的纯物质奖励，金钱固然好，但是并不一定是团队成员需要的，因此和 HR 一起，设计更有温度的奖品，会让成员更有归属感和求胜欲。

我个人和我们公司非常不推荐长期执行闭关冲刺这种不健康的、错将时长当效率的工时制度，但是在团队成功的完成短期闭关冲刺的交付目标后，集体休个小长假就是团队最需要的奖励；将奖品奖金和团队的谢意，直接寄送给获奖成员的家人，让军功章的另一半一起分享成员的成就，让成员在家庭获得认同，也是一种有温度的奖励；忽略年龄和资历的桎梏，给予充分的授权，允许年轻的杰出成员，独立带领一支年轻的新团队，给予年轻人更重的责任和更深的信任，也是很好的奖励；帮助成员完成梦想，哪怕是资助成员停薪续保去留学深造、去创业，更是一种有温度也有气度的奖励。

人在工作和生活中主动或被动的扮演很多的角色，但是趋利避害、改善境遇是共通的发自人性的需求。如果说“己所不欲，勿施于人”是一种不作为，那么“人己共欲，施之援手”就是一种共赢的主动选择。带领团队快速成长，靠的一定不是鞭子，而是每个成员各自所需、且无法拒绝的果子；找到那颗果子、那棵果树，规划前往果园之路，这条路才会是有助于成员成长的高速公路。

作者简介

洪倍，AdMaster 创始人兼首席技术官，TGO 鲲鹏会上海分会会员。毕业于上海交通大学，于 2006 年与闫曌共同创立 AdMaster。拥有超过 13 年大数据产品构架、挖掘、处理和创新技术研发经验。带领 AdMaster 研发团队，架构了国内领先的涵盖广告监播、社交聆听、电商渠道及移动应用等多种数据源的营销大数据采集和处理集群。

第19讲 | 将企业打造成一所终身大学

我们可能经常会遇到一种情况，团队成员突然有一天跑过来，跟我们说：

“我学不到东西”

“我已经都会了”

“我感觉没啥成长”

“每天都在重复劳动”

……

接着就是，“我想离职，换个环境……”

团队成员的成长是一直困扰管理者的问题，今天我们就一起简单讨论学习一下。

成长的定义

我对成长的理解就是通过自己的学习和工作，在一个环境里，和组织一起互相扶持，发挥自己的价值，同时也创造价值，得到反馈，不断积累的一个过程。过程中会有坎坷，不断克服困难，放空自己的心态，接受一切挑战，并最终朝着一个既定的目标前进。整个过程中充满了乐趣和成就。

团队成员的成长一开始更偏基础实际一点，而随着经验的增加，诉求会更多元，也更偏上层务虚一点。

新人刚加入团队的时候，我们会有一套帮助他着陆的方案。包括公司历史，文化，价值观，公司内部的技术框架，公司业务，最佳实践等。随着员工的成长，会给他更成体系的培训，并有日常的经验分享。对于公司核心人才或高管会有管理咨询培训，并且有创业营计划，在带领团队打仗的过程中不断成长。

在务虚方面，我们每周三会组织一个管理会，将 20 多个技术负责人聚在一起，大家讨论和产品技术无关的话题，讨论关于人的问题。有的时候采用分享的方式，有的时候采用分组讨论的方式，有的时候采用集体共创的方式。互相扶持着成长，经验和想法交流，帮助某位同学解决问题，用集体智慧共同解决公司问题。

企业本身需要打造成一所终身大学，含有各个学科，可以永不毕业，每个人都能一直深造。

管理者可以做什么

管理者需要和员工一起定目标，拆成多个阶段，定落地方案，并阶段性给出反馈结果。过程当中我们采用共创的方式，达成共识，充分尊重团队成员的想法，而管理者在当中教的最重要的是学习和工作方式。

目标

目标要清晰，可度量，限定时间，包括工作和学习。在定目标前，我们会先调查现状，并和团队成员在目前现状上达成共识，接着一起定目标，并充分尊重团队成员的意愿。我们年初时会和各业务团队定好目标，并分解到季度，每个季度会重新 review，并及时调整目标。每个团队技术负责人会和各团队成员定成长目标，每个季度都会有到个人的 oneone review。

落地方案

目标会分阶段实施，每个阶段先大致定个目标，再不停迭代优化。这个时候，会再讨论什么是最重要的，最紧急的，用户到底需要什么，未来会是什么样的，用终局来看当前，寻找最合适的方案。

反馈（Review）

人往往都需要监督，给出反馈，才能不断优化。首先鼓励团队成员自我总结，反馈，其次从专家和教练方向，督促他，给出管理者的反馈意见。

工作 / 学习方法

我们经常会说：“这个人不行，思路不对”，其实是这个人的学习方法，工作方式不对，我们给出指导，给员工机会让他成长，如果实在不行再淘汰。

工作方式要有框架性或整体思维，落地时分阶段落地，得到结果，为下一阶段提供准备。细节决定成败，在落地过程中要关注细节，但如果代价太高，需要权衡。得到的结果要有价值，只有苦劳，没有功劳，是得不到成长的。

学习方法我自己分为快速学习，系统学习，深度学习。快速学习是了解一个新领域，如果想进入就先系统学习，如果自己操刀就需要深度学习，成为专家。

我们看一个实例：我们一个中台开发年度目标移动端推送打开率，推送打开人数 /DAU 提高绝对值 10 个点。

这位同学一开始比较抵触，说推送这个主要看推送的内容用户喜不喜欢，这是运营团队的事，是各业务线的事，我不能背这指标，我只能负责推送的达到人数。当然推送的到达人数多了，打开率就会高。但是这对于他的成长，价值是有限的，我们描绘了这件事给他的未来的成长空间，怎么去赋能业务，怎么去跟踪数据，怎么去做个性化，怎么去倒逼业务，怎么去利用资源等等。如果你都把这些事情做好，数据会不会增长，你自己会不会比你一开始提的目标得到更多的成长。

这位同学回去后立马对目标做了分解，Q1 做达到人数，Q2 做推送数据可视化，Q3 做特征模型训练，Q4 做货币化（和业务结算资源），并对工作做了详细拆解。每个 Q 下来我们会对结果做 Review，并且把所有业务团队对接人一起叫过来，真正从用户角度 review，收集反馈。而我们只是教练角色，从工作方式上给予指导。

成长来自于实践, 不会一帆风顺

成长过程中，会遇到很多的挑战，很多新事物，直观的感觉是排斥它，这样无法成长。有首歌是这么唱的，不经历风雨，怎么见彩虹，没有人能随随便便成功。而作为管理者，给团队成员更多的机会，让他们去锻炼，不要担心他们会失败，但也不要袖手旁观。有些 leader 在管理时就直接放手，只管结果不管过程，导致团队成员一次次失败，更打击了他们的积极性。有人会问在什么时候给出帮助呢？

他向你求助时

阶段性看过程时

不管是工作，还是学习，都要和团队成员进行阶段性 review，在 review 时要给出帮助。

解决紧急问题时

紧急问题需要立刻解决，所以并不能给团队成员太多时间，这时他其实也可能需要你的帮助，互相沟通一下，如果他有思路解决，给他时间，如果没有思路，跟他一起解决。

方向把控时

要和团队成员，确定大家的目标都是一致的，而且没有方向的问题。主要防止走错方向，做无用功，恶劣地影响团队整体产出。

跨团队和跨部门协调时

作为团队的负责人，你比他更有调动资源的能力，要为他协调组织。

成长来自于实践，在实践中我们会有很多收获，我们要及时把他们保存下来。

知识库

建立一套知识库体系，早期的时候会用 confluence 来记录，文档放在 NAS 上。后续会搭建公司内部资料共享的系统，公司技术博客。

复盘

复盘是一种很好的总结，学习的方式，从失败当中获得成长。每个人都做自我总结，大家再一起给出改善建议，将整个复盘的结果保存下来，缺点改正，优点传承。

成长不是个体的

成长的最高境界是成就他人，但首先还是管理者自己的个体成长，自己不要成为团队的天花板。技术管理者是团队的旗帜，大家都在向他看齐，他的言行举止是最重要的。成长首先是看个体成长，团队成员的每个人都是其中的个体，每个人都有自己的想法，而且处的阶段都不同，要让他们每个人都能获得成长。团队需要有出类拔萃的标兵人才。但整个团队都依赖于个别人，说明人才结构就不健康了。

选才培养

从招聘开始，就会去选适合团队文化和人才结构的候选人。我们很重视对年轻人培养，敢于破格提拔年轻人试错，让有作为的年轻人成为团队的核心。

团队目标

上一节提到个人目标，整个团队需要有一个整体目标，协同所有人，一定要沟通到位，上下一致。

营造氛围

营造工作学习氛围，调动大家的积极性，每个人都能独立负责一块。在营造技术氛围这一块，我们鼓励大家分享，建立培训体系，组织 hackthon 活动，喜欢真正对技术感兴趣并乐于分享的同学，给他们荣誉，比如最佳讲师，技术创新奖等。同时创建公司技术博客，在精力允许下，提倡员工出去分享，提高技术影响力。

成长就是为了创造价值，并满足自我需求 ##

成长最终目的还是为了创造价值，成长过程中的成就感也来源于创造的价值。创造的价值最终是服务于我们的用户，得到成就感，但同时基于人性，我们不能忽视财富，权利，虚荣心的需求。

成就感

最好的办法是让做工作的人有成就感，通过工作本身，变得有成长，通过工作不能调动他的动机，就没有持续的动力来调动他的积极性。

荣誉

荣誉可以成为不断鞭策荣誉获得者保持和发扬成绩的力量，还可以对其他人产生感召力。在企业中我们设计了职位，职级，表彰（优秀员工，优秀团队）等，给予员工最大的尊重。对于员工的重大贡献，要公开表扬，同时对犯错的员工不要过分批评、指责和抱怨，对事不对人，给予帮助和指导。

财富

包括工资，奖金，股票期权。工作的结果不会直接跟工资挂钩，工资会和岗位，职级挂钩。奖金往往和工作绩效挂钩，要考虑工作背后的真正价值，防止过度 KPI 化。奖金要和员工期望值挂钩，过度激励和过少激励都是不科学的。长期业务的奖金偏向于阶段性激励，而不是项目制，这样才能给予真正的价值判断。

使命感

企业强调自己的使命愿景价值观，加强员工的使命感，所有人活着都想做点有意义的事情，将所有员工的成长和公司使命愿景放在一起，形成共识，激发团队的向心力，用价值观去规范员工的言行举止。

结语

团队管理者不光是个人获得成长，要让团队成员都能获得成长，和他们一起分享成长和收益，让每个团队成员未来都会比自己更好，成就他人才是最大限度的成就自己。

作者简介

陆栋栋，TGO 鲲鹏会上海分会会员，喜马拉雅 CTO& 技术合伙人，伴随着喜马拉雅的整个成长，微胖界典型码农。关注音频，知识付费，直播，AI 大数据，区块链等领域。

第20讲 | 论团队管理与共同升级

近两周，我们共同探讨了打造优秀的技术团队的一些经验，接下来几周，我们还会继续相关的话题。其实，不管是招聘、培训、考核还是激励等等，归根结底考验的是团队负责人的“人员管理能力”。

此前，易观 CTO 郭炜在“技术管理核心能力”系列文章中，已经分析了”领导力“和“体系搭建能力”，今天我们就来一起听一听，郭炜对于”人员管理能力“的分析。以下为正文内容：

所有企业管理的问题都是“人”的问题，人就是一个企业的竞争优势。在写作本文时，我思考了半天用什么词来讲“人”的问题，用“管理”这个词并不合适，卓越的人才其实是“自我驱动”，而不是仅仅需要被“管理”的，所以加入了“共同升级”一词。

在《原则》当中有这样一张图，有效的说明了一个企业其实就是一个从设定目标到实现最终结果的机器，这个机器是由一些“原则”组成。而执行就是由“文化”和“人”来做到的（详细的内容强烈推荐大家仔细阅读《原则》这本书），人本身也是由文化和制定的原则来影响的，卓越的人才对卓越的文化体系有一个正反馈，对公司本身的原则也是一个正反馈，最后与公司“共同升级”。

公司并不是僵化、一成不变的，而是一个由“原则”构成的生机型组织，这也是现代企业必备的生存和竞争技能。所以，人员是一个科技企业和技术团队最重要的核心资产，如何让这些特别聪明甚至“傲娇”的技术人才可以在一起高效的工作，对这些聪明人如何招、识、管、留、开，是一个技术管理者的核心技能，这也是本文主要讨论的内容。

招：人才招聘

对于科技企业，招贤纳士是每一个技术管理者最头疼的问题，一个 CTO 往往会花 50% 以上的时间用来找人。但是，招聘其实不是一个单点问题，招不到合适人才，并不是招聘体系出了问题，招聘是一个企业的技术品牌、技术文化、技术薪酬体系的综合产物，只靠钱是买不来人才的，我一直坚守着的原则是只有将心比心、诚心求才，才可以换来高质量、忠诚的员工。

技术品牌：技术品牌上技术人员是否认为你所在的企业是一个有技术发展潜力的企业，自己在加盟企业的过程中，除了待遇，是否可以学到东西有成长空间，将来离开企业是否会对自己未来的职业生涯有正向影响。

技术文化：技术文化是技术最高管理者和公司共同营造的核心技术竞争力，看上去非常虚无，但是一个公司重要人才的流失、招聘不利，往往是公司的文化和所需要人才的不匹配造成的。一个公司的文化是目标导向、创新导向、还是 KPI 导向、是否容错，这些其实是要融合公司当前阶段和技术在公司中的作用来做。既不能让技术放任自由，也不能限制过死导致没有发展空间，招不到牛人。

技术薪酬体系：整体上需要构建和市场接轨的薪酬体系以迅速扩张团队，在团队构建初期以期权和现金的模式吸引高级技术人才，中期以高于市场同等价位迅速扩张，迅速淘汰保留优秀的中层人才；长期通过异地研发中心等方式拉平整体研发成本，提高整体技术团队 ROI。对于薪酬定位可以参考 BAT 的薪酬评估体系，这里不再详述。

关于招聘，最后还有一句话，高级人才的招聘要高级技术管理者自己亲自上阵，三顾茅庐，将心比心、诚心求才才可以成功。对于高级技术管理者，招聘，并不是人力的事情，而是自己的事情，有这样的觉悟，才可以求到一起共同奋斗的弟兄姐妹们。

识：识别人才

首先，我们一定只招聘精英人才，这是公司精英文化的基础。怎样算是一个精英的人才，大多数技术管理者往往会在考察人员的技术技能上下很大功夫，而从我看来，这是不对的。我是用如下逻辑来看一个人才的：

价值观 >>> 学习能力 >> 技术技能

先考察一个人的价值观，因为这是一个人最难改变的。一个优秀的技术人才是否认同公司的 MTP（MTP，Massive Transformation Purpose 参见 《How Google Works？》），是否认同公司的使命和顶层设计，通俗化讲，你所招聘的员工信不信这个公司或者部门能把事情做成。这点非常重要，因为你很难改变一个人的观点，即使这个人再卓越，他不认同你所做的事情能做成，那么后期你在用人阶段，你无论怎么激励也不会有任何效果。

这也是我为什么坚持终面所有人都要我亲自面试一次的原因，此时不会再考量这个人的技术技能细节，而是“闻味”，看它是否和我们团队的价值观和公司的价值观一致。

其次是看一个人的学习能力，这可以从人才的简历看出来，也可以从人员的经历以及他问的问题和回答问题的情况看出来。一个优秀的技术人员，现在会什么其实并不是那么的重要，而是他是否有潜力可以学习更多的东西。在技术领域里，没有一成不变的东西，一个新技术，往往 1、2 年就过时了，能不能快速学习迭代自己的技术，快速适应公司业务的变化，往往是一个人才自己最重要的素质。

最后再看技术技能，在价值观和学习能力都 OK 的情况下，技术能力好的人才，可以节约你培养的时间，可以快速上手。而招聘时为了快速上手，招聘大量技术技能不错而价值观、学习能力不行的成员，一定会面临一次大洗牌，重新更新团队。

管：和人才共同成长

首先我的管理理念是精英团队理念，也就是所有的团队成员一定是由精英构成的团队，哪怕团队规模小一些，也不会有鱼目混珠的成员在其中混事。这样的好处是可以迅速打造精英文化，在招聘和识人上下了很大功夫之后，在管理上反而会轻松很多。

这里需要和大家分享的观点是用“使命式”管理，而不是用“命令式”管理。使命式管理含义就是告诉大家要做什么，目标是什么，为什么要这样做，让大家理解我们的使命是什么，而权力和决策下放到具体执行层面，只在关键点上进行协同。而不是“命令式”管理，把一个事情按照传统项目制细分 WBS，把每一个人每一天要做的事情全部细分下去，这样你的团队没有积极性，留下来的也一定只是听话的“庸才”。而面对瞬息万变的市场，这样的团队是无法生存下去的。

使命式管理，是坚定的把“人”放在核心位置上，每一个员工是否愿意承担责任，上级领导是否愿意支持下属的决定，对善意的错误是否可以容忍。这个理论基础不在这里详述，喜欢军事的管理者可以参考一下拿破仑的“机动作战”体系，或者冯 · 毛奇提出的面对不确定性作战的理论，他那句名言“遇到敌人，一切计划都将被打破”，正是现在中国瞬息万变的市场的体现。对于人才，我们要做的不是“管理”，而是使命式管理下的共同成长。

留：评估和挽留人才

挽留人才是在“管”这个阶段管理没有做到位的体现，往往是一线管理者或者团队使命出现问题，才会进入“留”这个环节。一般提出分手的员工，需要从他的需求来做分析。马斯洛的需求理论在这里可以发挥出比较大的作用。最终员工心理需要的是什么，有的员工是待遇问题，这种挽留是最容易做到的，是因为你可以考虑重新招聘一个员工和留住这个员工的代价。

而员工在这个阶段的个人发展诉求没有满足是比较棘手的，因为企业发展阶段和员工自身发展阶段可能会出现不匹配的情况，那么尽力对员工进行岗位的调整，项目组的调整，如果依然无法匹配那么只好友好的说再见，等待下次时机成熟再次合作。

如果是因为一线管理人员不到位的情况，可以通过重新宣贯价值观，调整一线汇报线等方式进行处理。整体上，走到“留”这一步的精英骨干员工，都是因为管理不到位造成的，是技术管理者需要避免的情况，需要从前几个环节找问题，而不是到最后需要挽留再临时抱佛脚。

开：和人才友好分手

开有两个含义，一个是管理者要在每隔一段时间，例如半年，评估一下所有的员工，把他们和市场上的资源相比，重新招聘一次，这个员工是否还值得。一方面，对于表现优秀的员工进行奖励，保持市场价值的均衡，另一方面，对表现不如市场资源的员工，分析我们自己管理哪里没有做到位，导致员工入职后成长速度不如市场预期，对于一直表现有问题的员工要进行优化。所以，从某种含义上来讲，其实每半年你心里把所有员工“开”了一遍，又重新招聘了一遍，只有这样做，才可以分析整个管理团队哪里做的有问题，管理团队自我也要再提升。

另一个含义，开，是针对触犯公司文化、原则红线，或者持续无法跟上公司节奏的员工进行的处理。没有开过员工的管理者不是好的管理者，大多数技术管理者性格比较随和，不喜欢开除员工。但是出现触犯红线的员工或者跟不上节奏的员工，你保留它反而会影响团队整体的士气，因此需要杀伐决断，当机立断采用合适的方法让员工离开。当然，如果只是能力跟不上的员工，你也可以推荐给其他公司适合的岗位，让和自己一起奋战过的兄弟有一个好归宿，也会让在职的员工会感觉温暖。整体上“慈不掌兵”，在开人这件事情上，高级管理者不要过于犹豫，为了一两个人最后影响整体团队的士气反而得不偿失。

结语

人是最复杂的动物，对于人员的管理和共同成长，是一个技术管理者毕生都需要研习的课程。究竟最终所有的生机型企业都是由精英人才构成的系统。人员管理其中不仅仅是沟通的能力，更要是对人员素质的准确判断、员工心理、团队士气、杀伐决断、上下级管理沟通的综合能力，也是技术管理者核心能力中最难的一个能力。

判断一个团队的技术管理者是否做好了人才管理，其实可以用一个很简单的问题来验证，你的精英是否愿意推荐他周围精英加入到你的公司，如果大多数精英愿意这么做，那么你的人才管理是有效的。同时，这也形成了你这家公司的精英文化，让更多的精英汇聚到你这家公司来。

“人在地失，人地皆得；人失地在，人地皆失”。人，才是一个企业的竞争优势。

希望各位管理者都有一支能打硬仗的队伍。在下一篇文章中，我会分享文化的构建能力，欢迎大家持续关注《技术领导力 300 讲》。

作者简介

郭炜，易观 CTO ，中国软件行业协会智能应用服务分会副主任委员，TGO 鲲鹏会北京分会董事会会长。负责构建易观技术团队、完成易观大数据采集、平台、数据挖掘等技术架构与体系；从无到有完成易观混合云的搭建、以及易观 SDK 的升级，并发布易观秒算实时计算平台。目前易观大数据平台日处理数据量 30T ，272 亿条，月活用户 5.5 亿。

第100讲 | 徐裕键：团队文化建设，保持创业公司的战斗力

你好，我是贝贝网合伙人徐裕键，之前的文章中，我分享了业务高速增长中的团队迭代和技术演进，而保证团队持续迭代和技术持续演进的一个关键是团队文化。

团队文化可以成为每个员工的行为准则，影响个人意识，当个人意识与团队文化达成一致时，团队就会逐渐走向成熟，并具备极强的战斗力。所以，今天我想跟你分享我们在团队文化建设上的一些实践。

创业公司发展路径

从文化的角度讲，一个企业基业常青，它的发展路线必然会经历一个 S 型的增长曲线。

以阿里巴巴为例，它最初专注于国内批发贸易市场，做 ToB 业务。当 ToB 业务做到一定的规模后，它预感到了业内天花板的存在，此时，又发现 ToC 领域有非常大的市场，于是创立了淘宝网，直接触达普通用户。然后又发现用户和商家在交易时存在非常大的痛点，于是推出了第三方支付工具“支付宝”，以担保交易的方式使消费者对网上交易产生信任。随后又推出阿里旺旺，方便用户与商家沟通，这样一来，即时通讯工具与网络购物就有了联系。之后又发现了商品品质与用户购物体验的问题，于是推出了天猫商城。而当线上交易的渗透率达到一定深度后，业务的天花板也是显而易见的，于是又从业务转向技术，开始做阿里云。

从阿里巴巴大概的成长历程可见，每一个创业公司都必须经历这样的过程，即不断地寻求新的业务增长点，预见问题、解决问题，并保持持续迭代，不断追求新的制高点。

我们公司也是一样的，我们是一个持续创业公司，最初，我们做的是返利模式，后来发现返利的天花板非常明显，之后转到导购，又发现导购需要依赖于淘宝、天猫等电商平台，受制于人，天花板也非常明显。

之后，我们发现了母婴市场，并迅速切入进去。当时母婴市场还是一片蓝海，其实蓝海和红海是相对的，很多人们以为是蓝海的领域，进去之后发现已经变成了红海。好的商业模式会让蓝海很快变成红海，所以创业者一定要有在红海中竞争的姿态。

所以，在母婴市场，我们也需要不停地进行迭代，在成长过程中，不停地寻求新的业务增长点，寻求新的突破。

另外，每个 S 形迭代的过程中，都有很多不确定因素，这对于团队成员的考验非常大。因为在每个 S 阶段中，都有高速增长期和顶峰停滞期。在高速增长期，业务发展快，大家都会比较亢奋，很多问题都会被掩盖掉，不会被发现。然而，当业务达到顶峰停滞期时，之前被掩盖的问题都会暴露出来，这时就需要团队去做调整，去寻找新的破局点，对于团队成员的考验也就随之加大，会需要他们具备强烈的文化认同感与执行力。

文化价值认同感

我们推崇的文化主要有三点，第一是自我驱动，第二是头狼精神，第三是价值认同。

自我驱动

我们会在团队内部强调创业文化，强调自我驱动。因为我们希望，在确定目标、明确方向之后，大家能够基于问题出发，以结果为导向，带着敢担当的精神做事情。同时也希望每个人都能带队伍冲锋、打胜仗。

因为，创业过程确实存在很多不确定性因素，会遇到各种问题与挑战。无论是来自于公司的流程制度，还是应用系统等工具支撑，都存在许多不完善之处，而这些不完善，都需要员工自己开拓解决方案。那么，员工能否将这些问题当做一次次机会，发挥自身价值，就需要看他们是否具备创业精神与自我驱动的意识。

另外，团队中的 Leader，必须具备识别小白兔与老白兔的能力。所谓的“小白兔”即勤勤恳恳干活，认认真真做事，但不生产业绩的成员。而“老白兔”则是加入团队的时间比较早，以过往的功劳自居，也是勤勤恳恳做事但不产生业绩的人。对于这两类团队成员，管理者应该及时处理，该淘汰就淘汰，否则也会影响到其他团队成员的积极性与成长速度，对公司的发展非常不利。

头狼精神

所谓的头狼精神即开拓、进攻、猎杀，对创业公司来讲，开拓与进攻非常重要。因为无论你做到何种规模，想守住第一都很难，迟早会被别人超越，所以，只有每时每刻具备危机感，保持敏锐，去发现新的机会，转守为攻，才能确保你的核心竞争力。

在创业公司，很多情况并不是考验员工的整体能力，而是考验员工的执行力，包括能否接受各种考验，能否主动突破问题、获取知识，能否做到快速执行，以及执行后能否做到持续迭代优化。创业公司能否保持快速迭代，可以说与团队员工的执行力紧密相关。

如果团队中的每一位成员都能够具备创业精神和头狼精神，遇到问题积极挑战，而不是吐槽抱怨，那么，团队将会快速稳定的走向成熟。

对贝贝网来讲，我们的目标是成为全球领先的母婴公司，那么就必须要保持头狼精神，保持领先的思维方式，积极进取，勇于开拓，构建核心竞争力，以免被他人超越。

价值认同

我们在确定公司的使命、愿景及价值观这条文化建设道路上，花了好几年的时间，我们会去研究、借鉴很多优秀公司的文化价值观。经过几年的积极探索，我们逐渐形成了属于自己的开发者文化。

想知道自己到底有没有文化，其实很简单，就问自己接下来团队要举办的活动中，大家对哪些活动寄予期望，另外，是否有什么东西成为他们工作的准则。

我也会经常在技术团队提及公司文化的 slogan，使大家增强认同感、归属感与使命感。

比如，我们要求团队成员有责任感，持续迭代对用户负责。不论是公司的商业模式、产品，还是技术都需要进行持续迭代。尤其作为研发者，给用户交付产品功能，并不是将功能上线就完成了，而是要持续迭代，交付给用户真正有价值的东西。

而如何将这些喊口号的内容做实、落地、体系化，并转型为生产力，就需要我们作为技术领导者在日常工作中不断的积累和沉淀。

以贝贝网为例，我们把“悟空”设为我们文化的关键词，因为我们的发布系统叫“悟空”，并由此衍生出很多含有“悟空”因素的活动，比如新员工培训叫“大闹天宫”，高精尖的老员工进阶叫“悟空训练营”，一年一度的技术嘉年华叫“悟空说”，等等。

我们第一次举办技术嘉年华的时候，针对五个领域、五大专题进行分享，时间定在每天晚上的七点到九点，每个专题每个晚上都会分享两到三个话题。当时，虽然我们公司的技术人员不多，只有两三百人，但是每天晚上会场都坐满，甚至站满，并且吸引了很多产品组、运营组同学一起分享交流。

最后，我们也对这次技术嘉年华进行了满意度调研，结果发现，满意度、认可度、赞赏度都非常高，并在团队中形成了一种技术文化氛围。而最重要的是，团队成员可以互相借鉴彼此的经验，提升自己，获得成长。

总的来说，团队文化建设不是一蹴而就的事情，需要统一团队成员的文化价值观，使大家目标保持一致。对于企业的使命、愿景有强烈的实现愿望，并将想法有效执行，而在团队文化建设中，也需要做好文化传承，将企业的精神、态度、价值等有效传承下去。

作者简介

徐裕键，贝贝网合伙人兼研发副总裁。负责贝贝技术团队管理，从 0 到 1 搭建贝贝移动电商产品和技术架构，推动集团各个技术领域快速演进，完善技术团队的梯队搭建和文化建设。

第101讲 | 刘俊强：领导力提升指南之培养积极的态度

你好，我是腾讯云资深架构师、TGO 鲲鹏会会员刘俊强，有着 8 年以上的技术管理经验，今天想跟你分享技术管理者如何做好情绪管理、培养积极的态度。

作为技术管理者需要负责的事情繁多，需要培养并带领团队完成工作目标，会面临诸多不如人意或突发的情况，稍加不注意就会让自己陷入到负面情绪中。我们必须及时处理工作中的负面情绪，不论是团队成员的或是自己的，毕竟负面情绪是可以传播的，我们当然不想给团队增加消极性，从而影响士气和团队表现。

一般来讲，我们在工作中常见的负面情绪及典型场景有以下这些：

挫败：当我们感到卡住或陷入困境时，通常会有挫败感。有可能是团队没有按照你的期望完成好项目，抑或是上司或老板未按时出席你主持的会议。

愤怒：失控的愤怒可能是人们在工作场所中经历的最具破坏性的情绪。同时这也是我们大多数人处理得不好的情绪，作为管理者更要学会控制愤怒的情绪。

忧虑：是对尚未到来事情的担忧和焦虑，例如公司业务发展受阻，需要对技术团队进行人员优化，抑或是工作挑战大担心完成不了等。忧虑的情绪不加以控制的话，很容易扩散影响自己的身心健康和工作效率，同时也容易让你在工作中不太愿意承担风险。

失望：当事情未达到我们期望时，一般会产生失望的情绪，例如团队成员认为未取得应得的晋升时。失望的情绪也会让我们趋向避免承担风险，影响到我们的工作效率。

不得不承认的是，工作场所中不出现负面情绪是不可能的，不论是因为管理者糟糕的决策引起的，亦或是由团队成员的个人问题引起的，作为技术管理者，我们不能对负面情绪视而不见，不去处理，任由它们在团队中蔓延，影响团队效率和士气。作为合格的管理者，我们应该学会在团队中培养积极的态度，学习洞察和处理负面情绪。

接下来，我们就聊聊如何来应对负面情绪、培养积极的态度，希望对你实际工作或生活产生些帮助。

应对挫败感

无论是基于什么原因，快速处理挫败感很重要，因为它很容易导致更多的负面情绪，比如愤怒。对于处理挫败感我这里有些建议：

首先是停下来评估，当你感到挫败时，能够做的最好的事情之一就是先停下来，当然这里说的停下来是指精神和思维上，回顾下遇到的情况，问问自己为什么感到沮丧，记录下来并具体来看这些事情，想想所遇到情况的积极方面，例如你的上司开会迟到了，你就会有更多的时间准备会议，或者，利用这段时间放松一下也不错。

如上所说，寻找情况的积极面，考虑你所遇到情况的积极方面会帮助你以不同的方式看待事物，角度微小的改变能够对我们的心情进行改善，因为造成你挫败感的人，他们可能并不是刻意让你沮丧或困扰的。因此让你挫败事情的产生，并不是某个个人的，不要在意，继续前进做你该做的事情。

消除脑里的负面词语，一般产生挫败感时，我们的脑子里会不自主产生些负面词汇或语句，让我们陷入这种负面情绪的影响之中，例如 “糟糕，又被坑了” “怎么总是做不好呢”，我们可以使用语气不那么重的词汇及语句来替换，例如 “事情进展有些不顺利” “完成情况低于预期”等，状况或事情总要解决的，因此不要沉迷于挫败感，如上面所说的继续前进带领团队解决问题。

控制愤怒

没有人会喜欢自己发怒的样子，作为管理者更不应该对团队成员发怒，因为这样会很容易将之前建立的团队信任摧毁掉。愤怒可能是工作中最普遍的负面情绪，从过往经历而言，愤怒在团队管理中还是蛮常见的，甚至于有些管理者会习惯性使用愤怒来达到自己的目的，但是与愤怒的人一起工作是让人辛苦、精疲力尽的。当人愤怒或回应愤怒时，大脑会让我们难以沟通或清晰地思考，那么我们该怎么避免在工作中发怒呢？

注意愤怒的早期迹象，只有你知道愤怒发生时的危险信号，所以我们要学会在它们开始时识别它们。尽早制止你的愤怒是关键，请记住，你的第一反应是生气，但并不意味着这是正确的反应。如果你开始生气，停下正在做的事情，闭上眼睛，进行深呼吸，将注意力集中在呼吸这件事情上，这样反复深呼吸后，能够帮助自己将注意力拉回到事情本身，而不是陷在愤怒的负面情绪中。

当生气时想象自己生气的样子和表现，例如，如果你要对团队大喊大叫，想象一下你自己的样子，是不是面红耳赤、手舞足蹈，你自己是否愿意和这样的人一起工作？我相信答案一定是否定的。

学会聆听，团队管理中经常会遇到的愤怒场景，便是团队成员对未完成好的事情进行解释或辩解，这很容易让管理者情绪达到临界点，进而爆发，因此我们要学会聆听，保持冷静沉着的风度，继续听下去，找出问题所在并引导团队进行纠正，以讨论问题的方式进行处理，如果进行到激烈时候，可以暂停 5 分钟，彼此冷静下再讨论问题。

解除忧虑

我们可能会对工作中发生的一些情况产生忧虑的情绪，例如糟糕的季度工作业绩、上司对于团队的不信任或公司发展受阻需要裁员等。忧虑通常伴随着恐惧，人类的生理本能会让人战斗、逃离或站着不动，而作为管理者，我们面对这些状况时，还需要带领团队继续前进，例如在不尽人意的业绩情况下，继续改进给予完成目标的希望。那么我们该怎么面对和处理？

正面处理员工的恐惧，坦诚地与团队成员沟通现状，并探讨接下来该怎么改善处理，唯有行动才能打破忧虑与恐惧，也就是人类本能里要么跑、要么战斗，站着不动可能被野兽吃掉，而因为我们是管理者，所以我们必须正面面对恐惧与忧虑，例如业绩不好，我们需要坦诚合理地探讨分拆实现的可能性，以及因为业绩不好带来的负面影响。

帮助员工避免夸大风险，当事情失去控制时，人们难免会产生恐惧并可能会放大忧虑。作为管理者，我们应该通过自己的经验和分析，帮助员工正视现状及问题，鼓励他们专注于如何改善现状，例如害怕被解雇，坐在那担心并不能帮助他保住工作，我们需要引导他们如何展示自己对于公司的价值。

记下你的担忧，如果你发现有些事情总是烦恼着自己，那么请将它们记录下来，然后安排时间处理它们，在此之前，你可以忘记这些担忧，因为你知道自己会去处理他们。在时间安排上，我们可以对这些担忧进行适当的风险分析，并看看可以采取哪些措施来减少风险。

宽容失望

我们可能会在工作中失望或悲伤，不论哪种情绪都对干好工作没有帮助，我们可以采取一些主动措施来应对失望和不快乐：

调整自己的心态，花一点时间让自己意识到事情并不总是一帆风顺的，说句鸡汤的话，正是完成事情过程的起起伏伏才让得生活变得如此有趣。

适当调整目标，如果你对团队未达到目标感到失望，并不意味着目标不可到达，可能是需要再多点的时间，那么是否可以调整下截止日期呢？如果团队总是无法在截止日期前达成目标，那么要思考的是目标拆分、进度管理是否合理呢？

帮助员工调整，前面我们有举例，员工可能会因为未取得自己期望的晋升而感到沮丧和迷失方向，他们会觉得自己经历了损失，因此作为管理者，我们在沟通时要有同理心，不要要求他们怎么怎么做，而是引导他们如果要达到自己的期望，应该要解决哪些问题，并认可他们出色的地方以帮助他们建立自信，达成目标。

总结

我们在上面谈到了一些常见的负面情绪，以及如何应对它们。我认为作为管理者应该明白的一点是，不论你自己或团队产生了负面情绪、士气低落，这些都是你要承担责任的，因为你是管理者，需要你来带领大家走出困境解决问题。

做个阳光积极的管理者并不容易，需要我们保持对团队负面情绪的洞察，并采取适当的方法进行处理，而这需要管理者不断训练精进。最后，当然是希望收听的各位都能够成为应对负面情绪的熟手，带领团队元气满满的工作。

思考题

你最近一次发现团队负面情绪是什么呢？你又是如何应对的，欢迎在留言区分享。

感谢你的收听，我们下期再见！

作者介绍

刘俊强（微信公众号：程序员精进）现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+ 年以上互联网开发经验，8 年以上技术管理经验。

第102讲 | 姚从磊：巧用AARRR模型，吸引优秀技术人才（一）

你好，我是百炼智能联合创始人兼 CTO 姚从磊，我于 2008 年从北京大学网络实验室博士毕业，先后经历过大型外企、大型互联网公司和不同规模不同阶段的创业公司，并于 2018 年 5 月创办百炼智能。

这十年间，作为技术线和业务线负责人，先后面试过的技术人员超过两千人，读过的简历更是数以万计。在这个过程中，经常会为吸引到顶尖的技术人才而感到欣喜，更为错过优秀的技术人才而感到惋惜。

欣喜和惋惜之余，逐渐发现吸引优秀技术人才这件事儿，跟研发运营一款成功的产品有着相通之处；并且，产品研发运营过程中的成熟方法论，可以直接拿来提升吸引优秀技术人才的成功率，AARRR 模型就是其中之一。

何为 AARRR 模型？

AARRR 模型（图 1）是一个经典的用户生命周期分析模型，在互联网产品研发运营中被频繁使用。在这个模型中，一个产品的用户生命周期分为五个阶段：

Acquisition：获取用户阶段，通过各种免费和付费的方式获取大量用户；

Activation：产品互动阶段，在用户初次体验产品的时候，最大程度让用户感受产品的核心价值，并尽可能将其吸引回来重复使用；

Retention：用户留存阶段，用户被产品功能吸引，频繁使用产品；

Revenue：获取收入阶段，利用广告、收费等模式，将用户流量转化为商业收入；

Referral：口碑传播阶段，用户认为产品足够好，主动向周围的人介绍。

（图 1 产品研发运营的 AARRR 模型）

AARRR 模型也是一个漏斗转化模型，可以用来验证产品的价值，并指导产品的研发和运营行为。

从产品的角度来看，如果每个阶段的表现都很好，就可以形成理想的产品闭环：

因为有很好的用户获取能力，就会有源源不断的新用户来尝试产品；

因为有很好的产品体验，新用户在尝试过程中更容易被产品核心功能吸引；

因为有很高的留存率，新用户会频繁使用产品核心功能，快速转化为忠实用户；

因为有很强的获取收入能力，就可以在不影响用户体验的前提下获取足够多的收入，进一步投入产品研发、采购更多新用户；

因为有很好的口碑传播，用户一传十十传百，就能免费获得更多的高质量新用户；

因为有能力采购更多新用户、获取更多免费的高质量新用户，用户获取能力就变得更强，最终形成闭环。

AARRR 模型只是一个普适性的分析模型，它可以帮助优化产品体验和运营策略，但无法决定产品成败；一个产品的成败，还取决于一个关键问题：产品解决了哪群人的哪个痛点？这个关键问题不能解决好，AARRR 就全无用武之地。

AARRR 模型 VS. 吸引优秀技术人才

一提到吸引优秀技术人才，大都会第一时间想到「招聘」。但真正的吸引，远不止于把人才招聘进来。在吸引优秀技术人才加盟后，更重要的是让每位人才在公司充分实现价值，高度认同公司，并源源不断地介绍自己的亲朋好友加盟，这样才会形成吸引优秀人才的「闭环」。

这个闭环，同前面提到的产品闭环、用户体验闭环完全相同。借鉴产品研发和运营的 AARRR 模型，我们可以得到吸引优秀技术人才的 AARRR 模型，如图 2 所示。

（图 2 吸引优秀技术人才的 AARRR 模型）

这个模型同样分为五个阶段：

Acquisition：触达人才阶段，通过各种渠道触达尽可能多的优秀技术人才；

Activation：面试入职阶段，打造一流的面试入职体验，促成优秀人才顺利面试入职；

Retention：人才留存阶段，为人才提供足够良好的工作和学习环境，提高人才对公司的认同感；

Revenue：实现价值阶段，人才在公司充分实现自我价值，并为公司发展贡献力量；

Referral：内部推荐阶段，人才对公司高度认同，主动推荐亲朋好友加入，一起奋斗。

同样，这个模型可以奏效的前提是，必须弄清楚两个关键问题：

公司需要什么样的优秀技术人才（目标用户画像）；

这些优秀技术人才需要什么（目标用户痛点）。

接下来，我们会首先解决「目标用户画像」和「目标用户痛点」两个问题，之后集中讨论 AARRR 五阶段中的关键策略，最后是简短的总结和建议。

目标用户画像——何为优秀的技术人才？

宁要一位优秀的技术人才，也不要 100 位平庸的工程师。一位优秀技术人才的贡献，要超过至少 100 位平庸的工程师。

虽然不同阶段的公司对优秀技术人才的定义有所差别，但还是有着诸多共性。

首先，「聪明和好奇心」会是一个基本特征。 聪明意味着学习能力强，成长速度快，可以同公司一起成长，将不可能变为可能。好奇心意味着探索精神强，对未知事物有强烈的求知欲，对新技术有浓厚兴趣。

聪明和好奇心往往是联系在一起的，只有聪明但没有好奇心，则只是在自己熟悉的领域里原地打转，虽然看起来更专注，但由于好奇心的缺失，事实上很难越钻越深；只是有好奇心但不够聪明，则只是对大多数技术领域略懂皮毛，夸夸其谈可以，深入解决问题就不灵了。

第二，「实战能力」会是重中之重。 过去的面试中，我经常遇到聪明且好奇心强的人，开始聊的时候会非常开心。一旦抛出一个实际的问题，不少人会很快提出一个大体方案，但当尝试细化到可执行层面时，往往就不太顺利了。尤其是在自然语言处理领域，如果不是标准化的问题（给定输入输出，给定训练集、测试集和评价标准），而是一个开放性的来源于实际研发中的问题，十有八九会不太顺利。

这些情况，大都是缺乏实战能力造成的，虽然思路不错，但还是浮于表面，离具体落地尚有一段距离。当然，一部分这样的候选人，可以作为较初级的技术人才培养。但是，如果在聊及过往主要参加的项目时，候选人对具体细节和例外情况的处理也是含糊不清的话，那就建议敬而远之了。

第三，「一技之长」会是非常关键的因素。 当然，这一点主要针对有一定工作经验（工作两年以上）的人，但如果经验尚浅也具备一技之长的话，那就更好了。

所谓一技之长，指的是在一个技术领域有一定的技术深度和积累。技术领域无所谓大（比如图数据库）小（比如中文分词），关键是要对领域内的主流技术方案有全面的理解，有独特的分析视角，更有第一线解决实际问题的实战经验和积淀。具备「一技之长」的人，是对自己职业生涯有着详细规划和强执行力的人，是非常优秀的技术人才。

共性的最后一点，我认为是「无边界」的特质。 没有一个人是可以脱离团队而独自达成高难度目标的，攀登珠峰如此，研发运营产品更是如此。在团队合作中，如果成员可以做到「无边界」，乐于承担更多，乐于帮助团队内外的同事，为了共同的目标而不计小节，这样的团队往往无往不利，团队中人才的成长速度也往往超出预期。

「无边界」的技术人才，是大多数公司都异常需要的，但往往可遇不可求，一旦遇见，就一定要拼尽全力去打动、去吸引，因为他们的辐射作用会使得周边的技术人才变得更加优秀。

谈完共性，再聊聊差异。 公司在发展的不同阶段，对优秀技术人才的定义也会有所不同。对于类似百炼智能这样的初创公司来讲，除了以上提到的这些共性的点，还对人才的「野心」和「乐观」非常关注。

有了足够强的「野心」，会相信自己和团队可以一起创造不可能；有了足够强的「乐观」精神，则会更容易克服从 0 到 1 过程中的各种困难，在坎坷时不但不气馁，反倒会觉得坎坷之后就是胜利。

对于从 1 到 10 的快速发展期的公司来讲，就会对人才的「快速学习能力」更为看重，因为公司业务的快速发展会产生大量的空缺，需要每个人及时的补位，需要人才在极短时间内快速大量地学习。

而对于稳定期的公司来讲，则会对人才是否「耐得住寂寞」较为看中，毕竟稳定期的业务，在大量重复性工作的同时，需要能够深入发掘钻研，发现更大的机会，而这个过程会需要极大的耐心和稳定性，所以「耐得住寂寞」会是一个需要的特质。

下篇预告

在讲清楚 AARRR 模型同吸引优秀技术人才的关系，并讨论完「目标用户画像」这个关键问题后，我们会在下一篇详细分析目标用户的痛点，尝试讨论清楚优秀的技术人才需要什么这一关键问题。

最后给你留一个思考题：为什么宁要一位优秀的技术人才，也不要 100 位平庸的工程师？

作者简介

姚从磊，百炼智能联合创始人兼 CTO，致力于利用深度自然语言处理技术，将无结构的公开互联网信息结构化，构建以商业机构和商业人物为核心的知识图谱，服务于各种商业场景。2008 年博士毕业于北京大学计算机系“天网”实验室，师从李晓明教授。毕业后，先后在惠普中国研究院、腾讯负责文本挖掘和搜索引擎相关技术和产品研发。2012 年加入豌豆荚先后负责技术团队和搜索、营收等业务，主导建设的技术团队成为当时国内最有吸引力和竞争力的团队。2016 年加入 Kika 任 CTO，负责 AI 技术团队打造、输入法 AI 引擎、语音识别等业务，大幅提升 Kika 的技术实力。

第103讲 | 姚从磊：巧用AARRR模型，吸引优秀技术人才（二）

你好，我是百炼智能联合创始人兼 CTO 姚从磊，上一篇文章中，我与你分享了 AARRR 模型同吸引优秀技术人才的关系，而这个模型奏效的前提必须弄清楚两个关键问题，一是公司需要什么样的优秀技术人才，即目标用户画像；二是这些优秀技术人才需要什么，即目标用户痛点。

上一篇文章中，我们已经讨论完「目标用户画像」这个关键问题，今天，我将详细分析目标用户痛点，尝试讨论清楚优秀的技术人才需要什么这一关键问题。

虽然不同阶段的公司对优秀技术人才的定义会有所差异，但从「目标用户痛点」的角度来看，优秀技术人才的痛点往往共性更多，差异更少。最基本的痛点有二，一为「成长」，二为「成就感」。

「成长」痛点

每一位立志于长期从事技术工作的人，都渴望能够在技术和相关产品业务领域快速成长。而技术人才的快速成长需要满足三个支撑条件。

1. 牛人环境

首先，成长环境非常重要，需要有「牛人环境」。如果周围的人都比自己要强，耳濡目染下，自己也会有不错的成长。如果周围有行业中一流的牛人，有了牛人作为参照，自己成长为牛人的概率也会大大提高。并且，这里的「牛人」，不仅指自己专业领域的牛人，其他相关领域的牛人，也是多多益善。

从我这些年组建打磨优秀技术团队的经历来看，「打铁首先自身硬」，团队中必须要有一些真正的牛人，这样才会吸引更多优秀人才；久而久之，团队水平越来越高，也会吸引到能力水平远超现有团队的「大牛」，毕竟「大牛」也是喜欢与优秀的技术人才群体一起工作的。

2. 成长路径

「牛人环境」之外，每位技术人才的「成长路径」也非常重要。每个人在职业路径的关键节点上，大都会迷茫，不知道自己应该怎么往下走。这时，清晰可执行的「成长路径」就显得非常重要了。有了清晰的路径，技术人才们就可以时刻对照现状，及时发现问题并改正，然后根据现实情况实时调整。

因此，为了吸引优秀的技术人才，我们必须结合每位人才的成长诉求和现状，为其量身定做成长路径，并提供相应的条件使其快速成长。在每一位技术人才成长的路径中，「牛人」又会起到非常关键的指导和帮助作用，结合「成长路径」的 mentor 制度，为每位技术人才在团队内匹配可以长期指导其工作的 mentor，会起到事半功倍的作用。

在我的成长过程中，在豌豆荚非常幸运地遇到了一位大牛老师——邓草原老师；当时我每周都会有跟邓老师的固定聊天时间，主题不定，聊聊技术，聊聊人生，或者聊聊天下大事，每次聊天都是收获良多，既开阔视野，也使得自己更加自信。

3. 技术氛围

好环境和成长路径之外，另一个关键因素是「技术氛围」。团队有没有好的技术氛围，有没有好的技术导师及时解答每一个人的问题，有没有高水平的技术分享使大家可以有更多沉淀和学习，是非常重要的。无论业务压力多大，技术氛围的打造都不能松懈。打造良好的技术氛围，并适时向行业输出成熟技术方案，提升技术影响力，是每个公司都必不可少的工作。

在打造「技术氛围」的过程中，有两点需要避免。

一为闭门造车，仅停留在团队内部技术分享的阶段，虽然有助于技术沉淀和锻炼口才，但很容易坐井观天。好的技术氛围，应该是开放式的，既有团队内部的技术沉淀式分享，也有同其他公司团队的交流分享，更要经常邀请行业大牛来进行高水平分享和讨论。

二为脱离业务，技术是为业务服务的，最忌「为了技术而技术」，在保持技术敏感性的前提下，除了聚焦于团队目前的技术方向构建技术氛围外，也需要适当扩大技术领域的外延，为将来的业务工作进行准备。

好环境、成长路径、技术氛围都是技术人才获得成长的支撑条件，但更重要的是「实战」，必须有足够高难度的目标来挑战，他们才可以在实战的过程中不断提升自己。在设定技术人才的目标时，一个建议的原则是「一定要蹦起来才可以够到」，人的潜力永远都比自己想象的大，不给自己挑战，又如何能成长呢？

在对实战结果进行考核时，需要考虑好技术和业务的平衡。所有的技术人才，首要的是要完成业务目标，然后在这个前提下考核其技术方案的优劣和技术水平的高低。技术人才的考核是一个较大的话题，在此仅给出两个建议：

分别考核业务目标完成情况，和业务过程中技术水平的提升情况；

技术水平提升的前提是，业务目标必须达成，否则技术水平提升无从谈起。

「成就感」痛点

成就感对于每个人都必不可少，没有成就感的工作，是无法吸引任何人的，优秀的技术人才更是如此。

成就感之一为「业务增长成就感」

技术人才虽然从事的是研发相关的工作，但最终目标是为了服务产品、服务业务。只有他们的贡献真正对业务增长提供了支撑甚至决定性的作用，他们工作的价值才会真正体现，个人的满足感和成就感才会足够强。这一点，即使是在纯技术部门也是如此，如果跟业务没有关系，个人很难收获真正的成就感。

为了达到「业务增长成就感」，每位技术人员都需要是业务人员，从属于具体的业务团队，扛具体可衡量的业务目标。在这个前提下，利用「牛人环境」、「成长路径」和「技术氛围」确保每位技术人才能够在业务发展的同时取得技术上的成长。

有朋友可能会认为，这样容易造成不同业务团队重复造车等各种研发资源浪费问题，这是明显的只见树木不见森林的看法。一方面，重复造车的问题可以利用日常的技术手段（比如技术方案评审、Code Review 等）加以避免和控制；另一方面，很多好的技术方案往往是经过了很多次「重复」/「重构」才真正形成的，适当的「重复造车」会形成技术团队间的良性竞争，反而益处更大。事实上，这种方式可以类比为「市场经济」的方式，通过适当的「调控」，可以最大化个体的积极性，最大化生产力的发展。

成就感之二为「技术提升成就感」

在贡献业务增长的同时，技术人才的技术得到了磨练，技术能力得到了提升，有了更多的积累和沉淀。这时，公司应该及时通过技术职级晋升的方式对他们的提升进行肯定，并提供高质量的技术分享机会，帮助优秀人才打造自己的行业技术影响力。

技术职级晋升是一件非常神圣的事情，最忌讳领导制定等暗箱操作方式，必须确保标准明确、过程透明、结果公正，在合理设计技术职级体系的前提下，通过精心设计职级晋升的评审过程，确保相关信息对所有参与人均保持及时和透明，并利用机制确保最终的投票过程可以消除少数人的偏见，最大程度确保结果的公平和公正。对于处在业务快速发展阶段的公司，技术职级晋升以半年为周期为宜。

在打造行业技术影响力方面，公司应该积极提供各种支持，并对核心技术人才提出特殊要求和支持；在实操过程中，需要摒弃「他 / 她在行业中出名了会被别家挖走」的不自信想法，真心实意地帮助技术人才构建行业影响力，这样公司的技术影响力才会水涨船高，才会吸引更多的技术人才。

成就感之三为「现实收益成就感」

多劳多得，能力越强得到的也应该越多。现实收益，不仅仅局限于现金以及股票等现金等价物，也包括更好的学习机会（比如参加 Google I/O 等世界一流的技术会议等）、更好的发展机会（更重要的职位等）和更高的目标及背后更高的现实收益等。

在现实收益的设计上，一定要明确对技术人才能力水平的期望，并设计相应的现实收益水平。例如，如果期望技术团队平均技术水平超过行业中 75% 的人，那薪酬 / 股票体系的设计需要确保在行业 75 分位以上；对于团队急需且非常合拍的「牛人」，则要不惜代价，以最大的诚意和现实收益来吸引其加入。与现实收益平行，更好的学习和发展机会也会是非常重要的因素，可以同现实收益打包形成有竞争力的人才吸引手段。

下篇预告

在解决了「目标用户画像」和「目标用户痛点」两个关键问题后，我会在接下来的两篇文章中详细分析吸引技术人才的 AARRR 模型每个阶段的主要目标和策略，以及一些对应的实操型建议，敬请期待。

最后给你留一个思考题：在你的公司中，经常出现「不同团队重复造车」的情况吗，这些情况真的都是不好的吗？

作者简介

姚从磊，百炼智能联合创始人兼 CTO，致力于利用深度自然语言处理技术，将无结构的公开互联网信息结构化，构建以商业机构和商业人物为核心的知识图谱，服务于各种商业场景。2008 年博士毕业于北京大学计算机系“天网”实验室，师从李晓明教授。毕业后，先后在惠普中国研究院、腾讯负责文本挖掘和搜索引擎相关技术和产品研发。2012 年加入豌豆荚先后负责技术团队和搜索、营收等业务，主导建设的技术团队成为当时国内最有吸引力和竞争力的团队。2016 年加入 Kika 任 CTO，负责 AI 技术团队打造、输入法 AI 引擎、语音识别等业务，大幅提升 Kika 的技术实力。

第104讲 | 姚从磊：巧用 AARRR 模型，吸引优秀技术人才（三）

你好，我是百炼智能联合创始人兼 CTO 姚从磊，之前的两篇文章中，我与你分享了吸引优秀技术人才的 AARRR 模型，并探讨了执行这一模型的前提，即弄清楚“目标用户画像”和“目标用户痛点”这两个关键问题，也就是“公司需要什么样的优秀技术人才”以及“这些优秀技术人才需要什么”。

在本篇文章中，我会结合吸引优秀技术人才的 AARRR 模型（图 1 所示），来详细分析 Acquisition 和 Activiation 阶段的主要策略，并提出一些实操性建议。

图 1 吸引优秀技术人才的 AARRR 模型

Acquisition - 如何触达更多的技术人才？

对于产品研发来讲，Acquistion 阶段的目标在于尽可能触达尽可能多的目标用户。为了达到目标，首先会对目标用户的特点进行分析和定位，然后制定针对性的策略，来开拓足够多的渠道，将产品送到目标用户面前。对于触达技术人才来讲，方法也基本类似，首先需要做好定位策略，之后就是通过社招和校招等多种渠道触达更多的目标技术人才。

定位

在开始行动触达技术人才之前，需要想清楚两个问题：一是公司的定位，二是职位的定位。

公司的定位，其实就是期望能够占领用户 / 客户心智的唯一标签，这个标签一定要有足够强的区分度，且公司在标签对应的细分领域应该已经成为或正在成为第一。这样的标签比比皆是，比如「社交」之于腾讯，「电商」之于阿里，「搜索」之于百度等等。当然，对于技术人才来讲，这个标签还应该可以引申到技术的优势，比如「社交」意味着高并发、异构网络环境下可靠稳定的通讯，比如「电商」意味着千人千面的商品推荐和实时、精准的记账系统，再比如海量网页数据对于海量查询请求的准确、个性化排序等等。公司定位一定要花大功夫来确定，并且以各种方式使其占领技术人才的心智。

职位的定位，不仅包含传统职位描述（JD）中的职位职责和职位要求，更应该说清楚职位的独特技术挑战和发展机会。这里的「独特」非常关键，必须是同公司的文化特点、发展阶段和技术栈密切相关的独特点，必须是能够完全区隔于同类公司的同类职位的。然而，现在大部分公司在职位定位上的投入还远远不够，只是说清楚了共性（职位职责和职位要求），很少去深入思考和阐述独特性，这是一种典型的「非换位思考」的处理方式。换一个角度想，如果你公司的这个职位定位跟别人家一样，我为什么要选你呢？职位定位这件事，只有站在技术人才的角度来思考，确保他们看一眼就能被吸引，才算是合格。

在公司定位和职位定位清晰确定后，目标技术人才的特点，也就水到渠成了。

渠道

吸引目标技术人才的渠道，无外乎校招和社招两类。

校招

校招绝对不是每年投入两三个月的项目，而是需要在平时多下功夫。合格的校招，要准确定位目标人才在哪里（大学、院系、社团），如果能够定位是谁则会更好。定位的原则必须是少而精，集中精力重点突破。

在目标人才精准定位后，接下来就是通过各种方式触达。

一类方式是通过老师、社团和师兄师姐来触达并持续影响，可以通过定向资助教授研究项目（建议无任何约束的 gift money 形式）、资助社团活动、鼓励公司内的师兄师姐多回校请师弟师妹吃饭聊天等方式来进行；这种方式需要长期投入大量精力和资源，但收效也是最明显的。

另一种方式是通过在学校教授公开课，介绍工业界的技术进展和实战经验，使同学们在收获知识的同时，对公司的定位和技术特点有清晰的认知；这也是一种很好的方式，同样需要投入大量精力精心准备课程，确保同学们所花的时间物超所值。

除此之外，优质的实习生项目也是一类重要的方式。但如何确保足够「优质」，就需要下大功夫了。一要确保挑战足够大，二要确保薪水足够高，更重要的是要确保有牛人带。

社招

社招的渠道，也分为两类。

一是「自己动手，丰衣足食」。内部推荐是最重要的渠道，但做好内推，前提是公司同事对公司的高度认可，而这需要平时多下功夫。熟人推荐也是一个高效的方式，有了熟人的信任背书，同目标人才的信任感会显著增强，转化率也明显偏高。做好熟人推荐，平时要积极参加各种相关的高水平技术论坛和学术会议，融入「圈子」才好办事。

二是「借助外部，广泛撒网」。首先，要经营好自己的官方网站，突出定位，明确需求，官方网站是外部人才了解公司的最重要的渠道。在这个基础上，猎头渠道是需要重点投入的渠道，但不能产生依赖，要本着「好钢用在刀刃上」的原则，选择一流的猎头公司，专攻挑战性高的职位。此外，需要花大力气在各种招聘网站上，主动寻觅目标人才，强烈建议技术 / 业务 leader （而非 HR）直接在招聘网站上找人，这样不仅能大幅节省时间提高效率，而且能对行业人才的流动趋势了然于胸，使得招聘和团队建设更有针对性。

Activiation - 如何促成优秀人才顺利入职？

在产品研发中，Activiation 阶段的目标在于使目标用户充分体验产品闭环，并被产品核心功能的价值打动，产生频繁使用的意愿。为了达到这一目标，首先要实现简洁、准确的新用户引导流程，使得新用户对产品的定位一目了然，并迅速使用到产品的核心功能，进而对产品核心功能的价值做出判断。这个过程，实际上是产品和用户之间的双向选择过程。

类似地，在吸引技术人才的 Activiation 阶段，我们的目标是促成优秀人才顺利入职，在通过精心设计的面试流程来筛选和打动面试者的同时，还要利用诚意满满的 offer 谈判策略及入职等待阶段的精心准备来促成人才顺利入职。

面试阶段

面试是一个双向选择的过程。好的面试，需要在两个方面做好功课。

面试邀约

面试邀约的原则是，一切以目标人才为主。

首先，需要提供足够多且客观的材料，供目标人才判断是否接受面试。建议提供的材料清单包括：专业的公司介绍，公司过往的新闻，原创技术文章，作为 contributor 的一流开源项目列表，以及获得的技术奖项等；

同时，一定要同目标人才有直接的沟通，避免线上纯文字的沟通方式。在直接沟通时，一定要说清楚职位的具体情况，尤其是强调职位同他 / 她的匹配程度，表达公司对他 / 她的欣赏，以及特别期望邀请他 / 她来公司同公司内技术大牛聊一聊的愿望，必要时可以请公司内技术大牛亲自出马。

面试邀约必须准备充分，并迅速沟通，在提供全面客观信息之后，请目标人才在短时间内做出决定，节省彼此的时间。即使被拒绝，也要表示感谢，并保持联系，保留之后沟通的机会。

在面试邀约阶段，需要尽可能降低无效的面试邀请。直接过滤掉有明显问题的简历；在沟通时如果判断候选人目的在于刷面试经验，或者发现其职业阶段和职业诉求不适合，则需要果断终止面试邀请；对于重要岗位的候选人，在面试邀约之前，要做好充分的背景调查。

现场面试

现场面试是 Activiation 阶段最重要的环节，不建议电话或者视频面试后就决定是否 offer，因为现场面试会让目标人才更全面的了解公司和公司的人，并且也可以让公司对目标人才有深入的了解。

现场面试有两个重点，简单高效的面试流程，和科学的评价体系。

在面试流程的设计和执行上，任何环节都同等重要。面试接待、面试中物料的准备、面试中间的休息等环节，均需要表现出公司的专业和对目标人才的尊重；在面试时间的选择和面试过程的安排上，一定要以目标人才的时间为准，且一次面试过程尽可能完成全部面试，让目标人才的时间得到高效利用。

科学的评价体系，首先要坚持目标人才能力高于团队平均水平的原则，通过合理的设计减少面试中的误伤情况；在最终得出评价结果时，要根据业务团队需求来科学评价，不能唯技术论，要综合考虑发展潜力、技术水平、业务能力以及文化契合度等相关因素。

Offer 阶段

Offer 谈判的基本原则是足够自信和真诚，对于看好的目标人才，创造各种条件，不达目的誓不罢休。

首先，在 offer 的设计上要有足够的诚意，不拘小节；对于目标人才的需求，要在不违反原则的前提下尽可能满足，而不要凡事总是留一手。但同时，要杜绝过度承诺，不要忽悠，所有细节必须说清楚，要书面化，坦坦荡荡。

其次，要让目标人才清晰地理解公司设计 offer 的原则，特别是理解 offer 是一个整体的方案，即 offer = 现阶段现实收益 + 职业发展机会 + 个人成长，引导目标人才客观地在不同 offer 间进行比较。同时，要忌讳「漫天要价」的候选人，因为引进这样的人，负面作用往往大于正面贡献。

当然，对于核心岗位的目标人才，在双方诉求相差不悬殊的情况下，要保持足够高的灵活性，必要时可以适当突破现有规则的限制。毕竟，千军易得，一将难求。

入职等待阶段

入职等待阶段，往往是最容易被忽视的阶段，也最容易造成各种遗憾。

入职等待阶段的原则，是让目标人才持续得到来自公司的信息，持续感受到公司对他 / 她的渴求和欣赏。

可用的方法有很多。首先，要保持足够频繁的沟通，不仅仅是 HR 同事，他 / 她入职后的 leader 更需要同其频繁沟通，多聊聊公司的进展，多聊聊目标人才入职后的安排，多创造机会使其熟悉团队，甚至可以邀请其帮忙面试候选人或者参与技术方案的评审等，在入职前提升归属感；同时，可以邀请他 / 她参加公司的特殊活动，比如 TGIF、Hack Day 等，提前感受公司的氛围和文化，也对于降低入职等待阶段的风险有很大帮助。

下篇预告

下篇文章会重点讨论 AARRR 模型中后三个阶段的主要策略和实操性建议，敬请期待。

最后给你留一个思考题：你在技术人才入职等待阶段的工作做的充分吗？

作者简介

姚从磊，百炼智能联合创始人兼 CTO，致力于利用深度自然语言处理技术，将无结构的公开互联网信息结构化，构建以商业机构和商业人物为核心的知识图谱，服务于各种商业场景。2008 年博士毕业于北京大学计算机系“天网”实验室，师从李晓明教授。毕业后，先后在惠普中国研究院、腾讯负责文本挖掘和搜索引擎相关技术和产品研发。2012 年加入豌豆荚先后负责技术团队和搜索、营收等业务，主导建设的技术团队成为当时国内最有吸引力和竞争力的团队。2016 年加入 Kika 任 CTO，负责 AI 技术团队打造、输入法 AI 引擎、语音识别等业务，大幅提升 Kika 的技术实力。

第105讲 | 姚从磊：巧用 AARRR 模型，吸引优秀技术人才（四）

你好，我是百炼智能联合创始人兼 CTO 姚从磊，上一篇文章中，我分享了吸引优秀技术人才的 AARRR 模型中前两个 A 阶段，即 Acquisition 和 Activiation 阶段的主要策略和一些实操性建议。

在本篇文章中，我将详细讨论模型后三个 R 阶段的主要策略和实操性建议，并在最后给出一些补充说明，希望能对你有用。

Retention - 如何提高技术人才对公司的认同感？

在产品研发中，Retention 阶段的目标是通过持续提升产品用户体验，使用户频繁打开产品，使用产品功能，强化产品核心功能在用户心智中的价值定位，使用户快速转化为忠实用户。为了提升产品体验，不仅要持续打磨核心功能细节、研发新核心功能点，还要持续补足非核心功能的短板，从整体上提升产品的用户体验。

同产品研发类似，在技术人才成功入职后，接下来 Retention 阶段的重点就是如何通过持续优化公司和团队中的工作氛围和体验，持续提高人才对于公司的认同感，越来越坚定地同公司一起走下去，同公司一起成长。为了达到这一目标，不仅要兑现 offer 承诺，还需要在四个关键阶段，破冰、融入、成熟、波动中，持续地优化人才的工作和发展体验。

当然，上述方法奏效的关键前提是业务的长期发展。如果业务长期停滞或长期倒退，是很难提升技术人才对公司认同感的。

兑现承诺

Offer 阶段的所有承诺需要清清楚楚地书面确认，并且在入职后需要按照约定按时兑现，不能有半点折扣，这是同人才建立信任的前提，也直接决定了人才是否能够建立对公司的信任感。

在 offer 阶段的过度承诺，在这个阶段就会收到恶果。如果已经出现过度承诺的情况，且人才已经入职，那么公司要不惜代价兑现「过度」的承诺，并通过及时沟通，与做出过度承诺的人在 offer 原则上达成完全一致，避免此类情况再次发生。

可能会有一些公司或个人抱着「反正他 / 她已经入职，对承诺加以灵活变通，相信他 / 她也会理解」的心态，或者故意利用信息不对称在 offer 中模糊部分承诺，又在对方入职后不爽快兑现，这些做法会在信任建立之初就破坏信任存在的基础，绝对得不偿失。

破冰阶段

破冰阶段，即正式入职后的一到两周。该阶段的原则是尽可能创造机会，让人才在公司各团队中认识足够多的人，初步感受公司的文化，并同某些同事建立初步的信任关系。

为达到目标，需要结合公司定位设计独具匠心的游戏化环节，使得破冰项目充满趣味性和惊喜感，并且使人才能够发挥自己的主动性，乐在其中。例如同团队同事一起完成有趣的任务，采访公司中有特长的同事，参与不同团队的团建活动等等。

在破冰阶段，不建议采用被动式的公司历史和文化培训，这种填鸭式的活动，起效并不明显，甚至会起到负面效果。

融入阶段

融入阶段通常为破冰之后，试用期结束前。该阶段人才的目标是熟悉团队的工作习惯和氛围，确定自己接下来主要的工作目标和职业发展路径，并开始投入到业务工作中。

融入阶段中，mentor 需要发挥关键作用。不仅要帮助人才熟悉团队，熟悉公司技术栈和研发过程，还需要结合人才本身特点，同人才一起制定接下来的职业发展路径和主要工作，并在对方工作遇到挑战和困难时，及时提供帮助，在长期工作中加深相互的认同和信任。

几乎所有的人才在融入阶段都会有大大小小的心理波动，所以，在这个阶段我们一定要对其足够关心，建立良好的沟通渠道，一起找到并解决导致心理波动的小问题。

并且，融入阶段中的人才，由于独特的视角，往往更容易发现公司的问题，所以要主动地收集和感谢他们反映的问题和建议，并且在第一时间解决问题，不断优化工作体验。

成熟阶段

到了成熟阶段，最重要的事情就是如何通过日常工作，使得人才收获足够强的「成就感」。正如第二篇文章中「成就感」痛点所讲的，业务增长、技术提升和现实收益这三种「成就感」，缺一不可。

达到这一目标的通用方法基本不存在。唯一的原则就是因时、因地、因人而异，在不同的阶段、不同的岗位，对于不同的人才提供不同的个性化帮助和指导，使其充分发挥自己的能力，收获应得的成就感。

波动阶段

有统计数据表明，员工入职后的一些关键时间节点（例如三个月和两年）是离职高发期；但事实上，波动是随时可能发生的，如果等到这些所谓的关键节点再努力，则会悔之晚矣。

有波动并不可怕，只要时刻关注和发现波动，真诚给予人才帮助，共同面对和解决问题，就可以把问题消灭在萌芽阶段。如果由于某些原因的确不可挽回，则不要强人所难，强扭的瓜不甜。

此外，员工离职是正常现象，不应过度关注和责难相关 leader/mentor，而更应该本着后续如何更好的帮助员工发展和成长的出发点，来进一步优化工作和发展体验。

Revenue - 如何使技术人才更好实现价值？

在产品研发中，创造营收的模式通常有两种。

一种是「羊毛出在猪身上」的被动模式，利用核心功能不断吸引用户增加流量，利用核心功能无关的功能（例如广告）来进行流量变现，并同时尽可能最小化对用户体验的伤害；另一种是「羊毛出在羊身上」的主动模式，在用户使用产品核心功能的同时产生营收（例如电商），并通过营收的增加进一步提升用户体验。

同样，技术人才实现价值也有两种模式。

被动模式的特点是，「干自己的活，拿应得的钱，公司好坏与我无关」，这里的原因通常是人才在公司中没有发挥的空间和清晰的业务目标，也没有因为业务的发展而得到应得的激励，更谈不上收获足够的「成就感」。与之相反，主动模式的特点是，每位技术人才都肩扛具体业务目标，在具体工作中有足够大的权限和自由度，自身乐于承担更多，一切为了团队和公司发展更好；并且，公司有简单清晰的考核方式，每位人才的收益同个人、团队和公司业务目标的完成情况直接绑定，「成就感」爆棚。

显然，通过主动模式实现价值的技术人才，其个人发展会更顺利，对公司的认同感也会更强。为了实现主动模式，一要目标清晰，二要信任放权，三要利益绑定。做到这三点，技术人才才能更好地实现价值，公司也才能实现更大的价值。

Referral - 如何使优秀人才积极推荐朋友入职？

好产品才有好口碑，而好口碑会通过传播的方式吸引更多的用户。只有好口碑的产品，才是有长久生命力的。对于产品来说，在满足好口碑的前提下，如何通过良好的设计，让忠实用户自发传播，吸引更多的用户，是 Referral 阶段的主要目标。以互联网产品为例，好产品通过社交裂变（分享拼团等）来进行传播吸引更多优质用户，已经被证明是行之有效的方法。

相应地，在吸引优秀技术人才方面，Referral 阶段的目标是使人才积极推荐朋友入职，同样可以借鉴社交裂变的方式来实现这一目标。

一方面，可以通过长期运营精心设计的内推（内部推荐）项目，使得优秀人才在推荐优秀朋友加入一起工作的同时，可以有令人惊喜的收益（例如大额红包或者 Google I/O 这样的参会机会）；同时，可以借鉴互联网产品的运营思路，通过内推排行榜和内推大奖的方式，来激励更多的技术人才参与到内推项目中来。

另一方面，可以通过 Hack Day、Family Day 和高水平技术沙龙这样的社交活动，邀请优秀技术人才的家人朋友参与到活动中来，使得他们对于公司的定位和优秀的工作环境有第一手的认知，与其建立长期的联系，并不断吸引适合的人才择机加入，实现真正的「社交裂变」。

写在结尾

虽然我们将吸引优秀技术人才的工作分为五个阶段来看，但这五个阶段应该是一个统一的整体，不同阶段的效果会相互影响，在实际操作过程中需要有全局性思维。

由于个人经历的局限，前面文章中的不少观点不免有些主观，且其中的方法更多适合于互联网行业，还希望你多多批评指正。

不过，作为高速发展的行业，互联网人才竞争的激烈程度在所有行业中都名列前茅，其方法论对于其他行业也具备一定的借鉴意义。

并且，借鉴 AARRR 这样的以用户为核心、以产品体验为中心的模型，来运营技术人才的吸引工作，其本质是充分地换位思考，以技术人才的视角来分析他们的需求，使得日常的工作有的放矢且能够不断优化。这一点，在所有的行业，都是通用的。

作者简介

姚从磊，百炼智能联合创始人兼 CTO，致力于利用深度自然语言处理技术，将无结构的公开互联网信息结构化，构建以商业机构和商业人物为核心的知识图谱，服务于各种商业场景。2008 年博士毕业于北京大学计算机系“天网”实验室，师从李晓明教授。毕业后，先后在惠普中国研究院、腾讯负责文本挖掘和搜索引擎相关技术和产品研发。2012 年加入豌豆荚先后负责技术团队和搜索、营收等业务，主导建设的技术团队成为当时国内最有吸引力和竞争力的团队。2016 年加入 Kika 任 CTO，负责 AI 技术团队打造、输入法 AI 引擎、语音识别等业务，大幅提升 Kika 的技术实力。

第106讲 | 程军：技术人的「知行合一」（一）

我是一个特别喜欢思考的人，凡事都喜欢问为什么，年近 40，经历了一些生命中的大小事情，有喜有悲，自认为悟出一些道（知），写一篇文章践行一次，希望可以帮你打开思考问题的新世界。

一、众生认知的过程和误区

先说我的观点，世界上大部分的人都是好高骛远的，字面意思就是脱离实际地追求目前不可能实现的过高、过远的目标。

至于其原因，本质是认知与践行的差距所造成的。具体可以类比人们用眼睛看远方某个目的地，和实际到达该目的地之间的差距。瞳孔成像的速度是光速即为 3*10^8 米 / 秒，而实际前往该目的地，即使你的工具是火箭，其速度最多也就是第二宇宙速度即为 11.2 *10^3/ 秒，两者之间速度差距高达 20000 倍。

这个速度之差异，就是导致大多数人好高骛远的本质原因，也就是知与行之间无法统一。

先来看认知的一个例子：

假设有一个九层的认知金字塔，我们最开始懵懂的时候，其实是站在认知的第一层，这时让你去仰视这个金字塔，说出金字塔的形状，从视觉上来讲，你肯定会说这一个是三角形。但如果把金字塔同比放大，假设高达 50000 米，直冲云霄，这时你再去仰视它，肯定无法得出这是一个三角形的结论。

接着如果我再用直升机把你从一层以 1m/s 的速度慢慢送到 50000 米高，这时你再去看，会得出这还是一个三角形的结论。同一个东西，认知的不同、站的角度不同，看到的结果却不一样，这让人陷入了沉思。

金字塔亦可类比我们中国的古塔（比如杭州的雷峰塔），我们从第 1 层到第 9 层，是需要一层一层爬上去的，不可能一下子就从第 1 层跨越到第 3 层，即使用直升机把你送上去，你的上升路径依旧是从第 1 层到第 2 层直至到第 9 层。

爬古塔就好比我们提升认知，你爬多快取决于你每一步的跨度有多远，而每一步的步长是有限制的，取决于你之前的认知高度，以及你在具体行动过程中运用的策略。

综上，我们必须做和提升认知相关的事情，才可以快速提升自己，才可以在比较短的时间内到达认知的“塔顶”。当然，提升的路径本身不能跳跃，只是不同方法带来的速度不一样而已，毕竟不同的人选择的方法和策略都可能不一样，更需要根据具体场景因时而变、因势而变。

一个很好的方法，就是看其他先行者的经验，并吃透他们“行”背后的逻辑，再反哺自己的“知”，不断向知行合一靠近。

二、先行者“行”之后的逻辑

咱们《技术领导力 300 讲》更新到现在，已经有 130 多篇文章了，可能你读完每一位老师的分享之后，都会觉得他们说的是对的，都能自圆其说，毕竟同一个问题每个人的处理方式都不一样。但是，很多文章并没有告诉你背后的逻辑，今天，我们不妨来解读一下他们这么做背后的逻辑与原因。也算是抛砖引玉，如果你也对这几篇文章有自己的解读，欢迎在留言区分享。

1）第 5 讲《CTO 的三重境界》

原文这里不再赘述，我的洞察是，作者福强老师用了一个分类法，按自己的之前的经验和推理，把 CTO 分为三类，即冲锋陷阵型、指挥若定型和引领方向型，我认为这三种分类基本可以覆盖我们现实中绝大多数的 CTO，并且，这种分类法也是人们在各个领域屡试不爽的办法，值得借鉴。

2）第 7 讲《要制定技术战略，先看清局势》

我研读文章多遍，发现作者郭老师不但用了我们之前说的分类法，还运用了因时而变、因势而变的思维逻辑，并把管理的核心收敛在人和事，只是不同时期关注的人和事的角度和深度都不一样，但万变不离其宗。

可能有人会说文中老师还讲了文化、CICD 等角度，但我认为，这些都是人和事的分支逻辑，最终都可以收敛到人和事上来。

3）第 18 讲《做到这四点，团队必定飞速成长》

洪倍老师的这篇文章道行极深，我们来细细品味一下，其主要核心为四点：人事匹配、规划到达目标路径、扶上马还要送一层、赏罚分明。

从人事匹配这里，可以看到洪老师所讲的关键点就是识人，无论是通过性格还是让 HR 协助，其核心都在于识人。而在我看来，识人的核心包括知识、经验、能力，还有最重要的是一个人的性格和做事方式。至于具体怎么做，我之前的文章《打造高效技术团队之招人》中有过详细的分享，如果感兴趣的话，可以回顾这篇文章。

规划到达目标的路径，这点其实跟我之前提到的爬雷锋塔的例子一样，具体可以抽象为找到榜样，选择适合自己的最佳路径，并且这个路径一定和目标强相关，莫偏离轨道做无关的事。最后，作者还用了 SMART 原则进行收敛，给读者提供了很好的思考模型，但其本质是，我们做任何事，时间和资源都不可能是无限的，一定是在指定时间内把目标达成，这才是最难的。

赏罚分明这点中，有几个核心逻辑可以看出作者非常了解人性，知道团队成员们最想要其实并不只是物质本身，不妨设计更有温度的奖品，让他们更有归属感和求胜欲，比如把奖励的方式与员工家庭绑定，花的钱不多，但攻了员工的心智。

工作事业被家庭认可一定可以给员工更大的内心激励，更能激发他们内心更大的潜能。

针对惩罚，老师的方法也非常值得我们学习，可能有的人会说，不就是复盘和改进措施么。你可以根据自己的现实情况选择适合自己的方式，但是，我想强调的是，无论你多忙，复盘都是必须的。复盘是一种最佳的场景教学，做的好了必将成为你前进路径纠正和优化的最佳方式。

4）大咖对话《让团队持续的 enjoy》

雪峰老师一直是我学习的榜样和人生导师，他认为团队管理的成功就是让员工持续的 enjoy，但要做这点不是一般的难。从文中我们可以看到，老师一直在事和人（组织架构）的不断升级和持续改进中，不断调整自己、调整团队，以适应内外部的变化。

细心的读者可能已经发现，要让同学 enjoy 并持续做好事，其中非常重要的一个抓手就是文化（更本质的原因是团队到了一定规模，文化就更为重要）。一个让成员愿意去创造和持续付出的文化或者说土壤，必然会更多的和 CEO 强相关，而具体到技术部门，我们作为 leader 不能照搬全抄，必须要先自己认同，再转化为自己的东西，再传递给同学们，这个承上启下的过程必不可少。并且在每个阶段，我们都需要持续去打透一个最关键点。

比如 2015-2016 年，我们的系统经常宕机发生 P0 事故，我们就搞了一个文化叫“作战室文化”，那段时间我们上班就直接去作战办公室，雪峰老师坐阵并指挥，持续一段时间后，问题一一被解决，并沉淀出一些自己的排查恢复的 SOP 和一些后续需要研发的作战工具。大家也感觉很 enjoy，这样的过程才可以认知升级、自我升级、团队升级。

三、认知升级的撬动工具——知行合一

说了这么多，大家可能还是有些疑惑，我在这里补充几个前人或伟人的理论精华，便于大家理解：
1.《易传》中孔子所写的“一阴一阳谓之道”。
2. 王阳明的“知行合一”理论。
3. 曾国藩的“凡成大事，以识为主，以才为辅；人谋居半，天意居半”。
4. 建国初期，周总理在外交上提倡的“求同存异”策略。
5. 习主席提出的“一带一路”方针。

不难发现，这些理论都是由两个层面的内容构成的，如阴阳、知行、识才、存异、带路等。这个世界上，很多东西都是成双成对、都是辩证且统一的，两者之间存在一个协同或撬动的工具，并且这个工具在不同时期、不同场景中都会有所不同。关于如何更好的培养协同的思维、找到协同的方式，这里想推荐一本书叫《第 3 选择》，感兴趣的可以去看看。

再举一个一般大厂推广微服务中间件例子：
1、中间件部门刚成立，看到公司系统非常多且有一些问题，比如调用关系复杂，没人敢改动一些核心模块，排查问题困难且耗时多，还有经常会因为系统之间的耦合严重而导致需求上线时间一拖再拖等等。
2、业务部门则研究 CRUD，系统业务订单量已经达到 10w/ 天，每次发布都小心翼翼，流量大时想降级一些不关键业务的调用都会很麻烦，偶尔一些紧急需求又不能按需发布，一发布调用系统都会受影响，苦不堪言。

这时，如果你是这款的中间件的 owner，你会怎么办？

我们先对结果进行可能性分析：

从概率上说，双赢的概率是 25%，但在我们的认知中，会觉得这事压根就是不可能的。之所以会有这样根深蒂固的认知，是因为我们从小就被灌输了好坏、美丑、正义邪恶、贫穷富有等对立的概念，而这些对立的概念禁锢了我们的思想。

我的破解方法是双方坐下来敞开心扉移情沟通，相互了解中间件部门和业务部门对于这件事赢的标准，运用协同、知行合一等理论，重新定义新的双赢标准并通过协作去执行。

这样，结果是一定业务交付速度更快，排查问题更快，而且中间件团队会感觉自己的工作有价值并认可，这才是协同产生的 1+1>2 的结果，持续践行下去甚至等于 100 的好结果。从根本上说，这是一种新的思维模式，能让我们找到解决所有难题的新思维、新办法。

回顾人这一生，其实就是一场修行，悟道的过程是非常痛苦，但也非常开心的。因为阶段性的胜利是值得开心的，但踏上下一个旅程又会面临新的痛苦。我们要做的就是保持一个好身体，一个乐观、积极的心态，选择好每一个人生十字路口并坚持走好我们选择的路。

另外，强调一下每个人的认知都会有一个提升的过程，不同的阶段，对问题的看法会变、做事的方式也会变。由于认知层级不同和信息不对称等因素，事事无绝对，请用你的左脑理性管理自己的行为，用右脑感性领导你的思维。坚持正确的原则，以终为始坚持自己的个人愿景，用知行合一这个抓手、用螺旋式上升的方式去撬动自己的未来，打开一片属于每个技术人的新世界。

我点上一只黄鹤楼，一直践行在路上。

作者简介

程军，现任贝壳技术总监，曾任饿了么技术总监、1 号店架构师，10 年以上互联网开发经验，8 年以上技术管理经验。

第107讲 | 刘俊强：消除压力的七种方法

你好，我是腾讯云资深架构师、TGO 鲲鹏会会员刘俊强，有着 8 年以上的技术管理经验，今天想跟你分享技术管理者在工作中如何面对压力并进行有效的缓解。

压力在工作和日常生活中是不可避免的，有些人能够在高压情况下保持冷静，并很好地完成事情，但同时有些人的抗压能力要弱些，不能够很好的应对压力所带来的影响，所以学会消除压力便至关重要。

我这里所说的压力，包括两个方面，一个是受环境或项目进度等情况影响，自身对于现状或未来有所恐惧或担忧的心理状态，即技术管理者自身面对的压力；另外一种是技术管理者的管理风格或方法，对于团队成员所造成的压力，即施压型管理者。

首先，我们要避免成为“施压型管理者”。试想一下，你的主管把每件事情都变成一种压力，让人在恐惧和压力中完成任务或做决策，让团队成员的神经总处于紧绷状态，这样的工作氛围是极为不健康的。

那么你自己是不是这样的管理者呢？通过不断的批评或威胁等工具，来刺激团队完成目标，短期内可能会取得一些效果，但是我们看长远些，这种管理方法所造成的工作氛围，会让团队成员仅关注于你所关注的事务上，会追求最为安全和简单的业绩输出方式，不会敢于创新承担更多责任。在这里，我希望大家不要成为这样的管理者，因为这类管理者是在消耗自己的信用，是不可持续的。

那为何有些管理者会成为“施压型管理者”呢？主要原因在于，作为管理者所面对的压力，如项目进度、团队成长等事务都在挑战管理者的舒适区，身处舒适区外，会让人紧张、害怕或不知所措，从而感受到压力。当他们不能够很好地消除处理掉这些压力时，就很容易让自我的行为产生偏颇，变成“施压型管理者”，而要避免这种情况，就一定要简单快速地解决当前让自己感到不舒适的压力状况。

接下来，我将介绍七种消除压力的方法，来帮助技术管理者让自己和团队在压力状况下，还能够舒适地进行工作和生活。这七种方法分别是：

制定计划
反复练习
避免工作中用光能量
不要拖延
不要多任务
学会委派工作
充足的睡眠

方法一：制定计划

面对需要在限定时间内完成的工作，我们让自己无压力完成的方法便是制定计划。当然，对于没有明显规定时间的工作，我也建议采用分阶段、分里程碑的方式来制定计划，以便我们逐步完成事项来达成目标。

为何制定计划对于消除压力这么重要呢？完成一个项目或是一项具体工作时，会给我们带来压力的地方，很多时候来自于对突发状况和日后未知情况的担忧和恐惧，因此，我们通过制定计划，确定每个阶段需要哪些资源和预估时间。

当然，这里我们需要留下些富余时间，因为执行过程中很有可能犯错，因此留下点犯错的余地，能让我们的计划更有灵活性，当状况真的来临时也能够应对自如。如果我们没有在计划中建立灵活性，这样的计划反倒只会增加压力，另外，我们的计划在工作强度上也要保持合理并尽量一致，这样的计划才能够帮助自己和团队舒适地完成目标。

方法二：反复练习

对于技术管理者而言，咱们的压力也可能会来自于产品介绍、技术演讲以及团队动员会等非技术领域的事务。而这些事务带来的压力，往往来自于环境，如地点、时间、竞争对手以及观众等，因为环境的变化会让我们分心，感到不舒适与压力，进而影响我们的表现。

消除这类事务压力的方法便是反复练习，我们准备好内容之后，需要对呈现内容的环境进行了解和熟悉，例如空间大小、观众人数、时间长度等。如果条件允许，我建议可以在最终场地进行排演练习；如果条件不允许，则可以事先思考补充场地的细节，并在自己的计划中预留一点时间进行场地环境的熟悉，让自己更胸有成竹地完成。

方法三：避免工作中用光能量

需要注意的是，一个人的身体和精力是有上限的，不要让自己和团队在工作中用光能量进而产生倦怠。面对压力时不要屈服于压力，这会让我们产生职业倦怠，变得疲惫与情绪化。一直处于高压情况下工作，很容易让人感觉自己对工作没有什么控制权，或者工作输出没有被认可。

当你审视自己或你的团队时，问问自己是否已经看到任何接近倦怠的迹象，如工作量和压力是否过大，团队成员是否看起来很疲惫，抑或是团队中的拖延和抱怨是否在增加。我们需要保持自己和团队的持续战斗力，而不是一次战役便压榨光大家的精力。

如何面对压力并避免倦怠状况的产生呢？

首先，保持跟团队成员的沟通，了解他们的工作状态和感受，需要形成定期沟通的模式来了解团队状态。

接下来，如果压力过大产生了倦怠前兆，可以尝试放慢下速度，重新考虑团队追求的整体目标以及项目目标。

最后，请务必提供团队所需的支持和资源，通过快速会议、消息群组以及电子邮件等方式来分享好消息，并鼓励团队让他们知道自己所做工作很重要，并给予对应的资源支持，同时也可以通过团队聚餐或其他放松活动来提升团队效率。

方法四：不要拖延

我们处理事情的时候，往往会先处理简单或是看起来不那么难的事情。对于那些明显重要但看起来麻烦的事情，我们可能会选择拖啊拖，拖到之后再做，其实我们有部分的压力便来自于这样的情况，因为这些困难或糟心的事情不会因为我们拖延而消失，而是会不断占领我们的心智，不能释怀，反而让人感到焦虑和压力。所以，不要拖延任何事情，把待办事项上的事情拿出来做吧。

方法五：不要多任务

让我们工作舒适的重要的一点便是不要多任务处理事情，不要试图一次做几件事情，我们可以将事情写在待办事项列表中，然后一次完成一个。人类思维并不是为多任务而设计的，不同事情间的切换会让我们的大脑感受到压力，让我们表现得更差。另外，事务中断一会儿后再回过头来接着做时，需要寻找上下文回顾之前的进度，这样效率会变差，进而情绪化毛躁起来。因此不要多任务，弄个清单可好？

方法六：学会委派工作

作为技术管理者，可能会有诱惑让你去做尽可能多的事情，虽然这样会让你工作丰富，并且感觉到有更多的控制权，但工作事务是做不完的，不断涌来的事务会让你倍感压力。更为关键的一点是，这样做对你的团队成员并没有多大帮助，你需要用你的知识、技能和方式去带领团队成功，而并不是要当一个全能的超级英雄。

你需要评估自己的工作内容，有些临时或不紧急的事务，需要考虑交给团队成员，甚至实习生来处理，你要做的是给予他们完成事情的必要帮助。

有时项目进度会有所延迟，这样的压力来临时，并不是要求你完全顶上去亲自将其处理掉，而是要跟团队沟通清楚目前的进度状况，跟团队一起来面对这些压力，有可能需要重新调整计划、也有可能可以很快速地处理掉影响进度的问题，最重要的是，你要学会将事情委派给对应的人员，并帮助他们成功完成任务。

方法七：充足的睡眠

充足的睡眠对于消除压力至关重要，可能有些人心比较重，一旦有压力或者担忧的事情就会一直想着，让自己的睡眠时间和质量都受到影响。事情终究会解决，会被处理掉，如果不能保持充足的睡眠，就不能保持良好的身体状态，反倒更容易感受到压力，无法很好的处理遇到的难事，因此，保证充足的睡眠非常关键。

现在我们有太多的诱惑，视频节目、游戏以及即时聊天等，这些都会影响我们的睡眠，我这里有个非常古典但行之有效的方法可以帮助入睡，那就是看书，可以阅读跟自己工作内容相关书籍，比如管理类书籍，很快就能够让自己入睡，当然小说之类的书籍坚决不要在睡前阅读。

总结

本文我和大家聊了聊技术管理者面对压力的处理方式，我们一定要注意处理好压力，不要让自己成为“施压型管理者”，也希望大家在之后面对压力时能做得越来越好。

思考题

想想自己最近的行为，是不是属于“施压型管理者”呢？

感谢你的收听，我们下期再见！

作者简介

刘俊强（微信公众号：程序员精进）现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+ 年以上互联网开发经验，8 年以上技术管理经验。

第108讲 | 谢呈：技术高手转身创业的坑和坡

你好，我是木仓科技副总裁谢呈，我是技术人转型创业的一个典型例子。我从高一开始写代码，一直写到春雨医生早期，在春雨医生的 6 年时间内，我从技术转型，开始负责产品与业务。目前，我在另一家互联网创业公司木仓科技负责驾培业务线。

今天，我将结合自己创业的亲身体会与经验，和你分享一些创业中的坡和坑。坑，是创业中难以避开的挑战；坡，是创业中迎难而上，实现目标的路径。

前言

我主要从三个方面讲创业，即找方向、找人、找钱。

有了创业想法，第一步应该做什么？很多人脱口而出“找人、找钱、找方向”。其实，正确的顺序应该是先找方向，然后找人才，最后才是找资金。

原因很简单，在互联网以及移动互联网如此成熟的阶段，此时创业，如果你连方向都不能确定，你想获取人才与资金可谓难上加难。

创业方向不同，需要的人才也不同，也许你做 2C 公司或是 2B 公司，也许你投身医疗行业或进军金融行业，专业的事情需要交给专业的人去做，所以，没有明确的方向，团队组建时就会乱了阵脚。

我将找资金放于末位，其实是标准路径，具体还需要分情况而论。有些人刚有创业想法就可以拿到钱，而对于多数创业者，根本没有这样的机遇。所以，在大多数情况下，我们换个角度想，如果你是 VC，你会选择投资一个方向明确、已有团队的创业公司，还是选择一个只有创业想法的技术高手？

答案当然是前者。

这就是方向第一，人才第二，资金末位的排序原因。

考虑到多数人目前只有创业的想法，还没有真正投身实践，所以，接下来我会着重讲讲找方向，以及在创业前期需要注意的事项。

找方向

创业方向非常重要，但放在实际情况中，找方向中的“找”代表验证。即验证方向。

从结果来看，多数知名的创业公司或成功的创业公司，往往不是在有一个创业冲动之后去找方向，而是已经有了明确的方向，再通过各种方法验证方向。

对于初次创业者，要判断是创业想法还是创业冲动的标准就是，创业方向是否足够明确，是否已经进行了验证，对此方向是否足够笃定。如果你没有明确而笃定且可落地的方向，往往代表这不是一个成熟或容易成功的创业模式。

不过，虽然有明确的创业方向是最好的选择，但是，对于技术人，尤其对于目前还未辞职创业的技术人而言，前期当然可以找方向，不断对方向进行调研与验证。

很多想转身创业的技术人，可能都会有这样的困惑，就是在移动互联网已经非常成熟，BAT 三足鼎立的情况下，创业是更容易了还是更难了？

对于这个问题，我的答案是难易程度取决于创业方向的选择。

小方向找机会：make money，看重商业模式

很多人认为创业更难的原因是，BAT 不仅有吸引人才的能力，有充足的资金，有丰富的经验，还熟知互联网战场。相比之下，创业公司好像毫无优势。

其实不然，创业公司至少有两点优势。

第一，正因为 BAT 强大，为我们斩掉了创业路上的许多荆棘，很多基础工作，都不需要我们再去做。比如，对于移动互联网的普及以及让用户习惯移动支付。

在此，以木仓科技的产品——驾考宝典 App 为例，这个产品的模式很清晰，就是两点：
1. 一个优秀的学车考驾照软件。现在考驾照的用户绝大部分都用驾考宝典，用户量可想而知。考驾照的周期即用户使用产品的时间周期，一般几个月到 1 年不等，时间并不短，所以用户流量也很可观 。
2. 通过用户和流量卖广告变现，驾考宝典早已实现盈利。

4 年前，为了进一步拓展商业模式，我们尝试过一些 2C 的收费项目，结果低于预期：日均收入一直在小几千徘徊，难以突破，后来考虑再三就放弃了。

1 年前类似的业务我们再次做了尝试，结果第一天就收入上千元，第二天直接破万了。后来很快形成了日均以万计的规模化收入。

前后 3 年的变化，归根结底是支付方式发生了改变，现在移动支付已经成为一种正常的消费习惯。而这种现象级的改变就归功于 BAT，他们帮我们铺平了许多创业路上会遇到的坑，创造了用户更容易接受的消费环境。

第二，BAT 虽然强大，但不能吞掉所有食物。假设 BAT 是一条大鲨鱼，初创公司是小鲨鱼，哪怕你附着在 BAT 的身上，都能够吃到它吃剩的或者它看不上的小鱼。这里的小鱼代表小生意，但值得注意的是，这个小生意可能不像大家想象的那么小。

比如借助微信平台做公众号的人，有人年收入可以上亿。再比如，去年我的两位朋友，还能分别借助百度和微信做流量倒卖的小生意。先用低价收购流量，将流量汇集后，再抬高价格卖出去，赚取差价，年收入也可以达到上千万。

所以回归主题，在这个时代，创业的难易，取决于你的商业模式。如果你只希望做好盈利，那你第一步就应该考虑赚钱方式，路径越短越好。

另外，如果你找的方向较小，希望做一个年营收亿级别的企业，甚至做上市，这并不是不可能。你只需要找到一个盈利的业务机会，利用自己的优势将它做到极致。不用太担心竞争，更不用担心 BAT，它们与你根本不在同一赛道。对于 BAT，你更需要思考的是如何利用它们帮助你更快的实现创业目标。

大风口拼刺刀：why me？理清竞争优势

如果你的创业方向较大，估值百亿以上，甚至希望像 BAT 一样服务上亿用户，那么成功的难度将会很大。当然，这不代表不可能成功，此时你要问自己的是「为什么是你」，为什么你可以做或者为什么你是最适合做这个事情的人？

大公司在组建人才、调动资金、吸引投资这方面都有非常强的优势，所以，你选择的创业方向与商业模式时即使大也需要具体，需要多做考量与验证，多用竞争的思路看问题。

2B 与 2BAT

对于创业方向，我还想分享两点，即 2B 与 2BAT。

1.2B

技术人在 2B 方向有不少优势。如果你做 2B 企业，你需要特别注重销售与资源。在这里也跟大家分享一个真实的案例：

我有位技术背景出身的朋友，与他的两位技术朋友合伙做了一家 2B 企业，无论产品还是商业模式都非常扎实，在业内小有名气。但他们最初忽略了销售的作用，导致后期产品销售非常困难，现在，他们找了一位销售合伙人。

2.2BAT

如果你选择 2BAT 方向，就需要注重两点，一是抓住需求，二是铺垫关系。

有朋友问我，我的公司融不到资金，想卖给 BAT，你觉得可行吗？
在我看来，这个想法不可行。其实将企业卖给另一个企业，是非常正常的退出渠道，但是，2BAT 的成功离不开需求分析，要抓住 BAT 的需求。

比如几年前的滴滴、快滴，它抓住了 BAT 需要移动支付的需求，而且，只有做到业内领先地位，才能够拿到 BAT 的资金。从目前实现 2BAT 的公司来看，无论是为了融资还是卖掉企业，它们之前都做得非常不错。

其次，内部关系也能在必要时助你一臂之力。许多拿到 BAT 融资的公司，合伙人中往往有人与 BAT 有一定的渊源。所以，作为技术人，你有必要铺垫一些关系，这些关系在关键时刻往往能够帮助到你。

就像一场比赛，谁都想拿到 BAT 的资金，甚至很多人为此降低自己的价格。在激烈的竞争中，你必须产品过硬，同时如果能够接触到 BAT 中的高层，那胜算的几率将大大提升，这点大家都懂，无需我多言。

找人才

对于找人才，我分享一点容易被技术人忽略的东西。

很多人会问，我到底应该找一个跟我像的人还是不像的人？其实，这就像找结婚对象，一定要价值观相近，而最重要的一点是技能互补。

比如我刚才在 2B 的例子中，谈到的那位技术朋友，就是因为他们缺少销售人才，导致再好的产品也遇到了销售困境。所以技能互补对于团队非常重要。

而互补依托于人脉的积累，如果你有创业梦，或者想跳出技术领域，你需要积累来自各方面的人脉，比如产品、销售、运营等，他们都可能成为你未来的合伙人，

虽然，找方向、找人才、找资金的顺序是所谓的标准路径，但还有一种情况是，当你去找你预想的合伙人谈团队时，可能他会说“你什么时候找到钱我才加入你”。这时，你就需要换一个人，一位看好你的方向并愿意跟你一起从零开始做事的人。

找资金

在找方向与找人方面，我提到很多需要注意的点，大多是创业者常见的坑，大家一定要避过，找资金反而没有多少大坑，这是一个坡。

我问过不下十个创业的朋友，当时找资金的情况。回答很有意思，两极分化。

一部分人说，根本不需要找，发个朋友圈，投资人就上门来找我。另一部分人表示找资金难，其中，联系过一百多家 VC 的初创者，也不在少数。

因此，总结找资金的经验，方式不用非常花哨，当方向正确，产品过硬，团队扎实时，找钱自然不是一件难事。

作者简介

谢呈，木仓科技副总裁，前春雨医生副总裁及联合创始人，曾任网易有道移动事业部技术负责人。在多年的创业中，分析垂直行业发展、制定并调整战略方向、思考业务和商业模式，对创业和互联网 + 的模式有丰富经验、教训和独到的见解。

第109讲 | 谢呈：关于垂直互联网创业的一些经验之谈

你好，我是木仓科技副总裁谢呈，在《技术高手转身创业的坑和坡》一文中，我分享了技术人转身创业时，在找方向、找人、找钱上可能会遇到一些坑与坡。

其实，我的创业经历中，先后做的春雨医生和木仓科技都属于移动互联网垂直领域的领先者，因此，接下来将分享一些我在垂直行业创业的经验与几点心得。

找用户 & 找专家

当下，创业很难避开某个领域直接做纯互联网的商业模式，比如，做社交、游戏等，非常之难，实际做的往往是传统行业 + 互联网的模式，避不开的一个话题就是垂直领域。

很多想在垂直领域创业的人会有这样的困扰：我不是业内人，创业的方向应该是找用户还是找专家？

答案是都要找。

以春雨医生为例，它垂直于医疗行业，是一个典型的垂直产品。当年决定做这款线上问诊平台时，我们也有这样的疑问，应该先找患者还是先找医生。而我们采用了笨办法，就是两边都找。

我们与二十多个医生交谈，发现支持率并不高，同时，也找到近百名用户，结果获得超过 50% 的用户支持率。在医生看来问题很多，如线上问诊没有见面能否给出有效建议、资质是否合法、医疗纠纷怎么办等等，而用户只担心医生是否专业，但对于线上问诊的方便都很期待，毕竟去医院排队和挂号的体验实在是太差了。

最终我们听从了大部分用户的建议，果断启动春雨医生项目，第一期的效果出乎意料。总结经验可得：

1. 什么时候该找用户？答案是当你想判断一个需求是否存在时，比如是否有线上问诊的需求。在垂直行业，必须始终以用户需求为出发点。
2. 什么时候应该找专家？答案是当你想寻求一个更合适的解决方案时，比如，线上问诊如何解决误诊的问题，这时就应该找专家。

把产品做出来

当你已经有具体的创业想法，对需求也充分验证之后，就需要将想法落地，搭建团队，做出产品。虽然，做产品是技术人的强项，但我还是想从两个方面给出一点提醒，一是解决问题与发现问题的思路；二是团队配合问题。

1. 解决问题 & 发现问题

如果你决定创业，或期望做 CEO、CTO、COO 等合伙人级别的技术人员，你必须具备发现问题与解决问题的思维。

最初，我从技术岗转到管理岗时，一个非常大的困惑就是时常感到不知所措，不知道问题在哪儿，其原因就在于思路不同。

技术人员是非常优秀的解题高手，但在创业过程中，我们的思路要从代码中跳出来，去发现公司存在的问题，去解决这些开放性的问题。想法不能再局限于如何做好一个产品，而是要思考如何做好一个企业。

我经常与一些技术转身创业的朋友聊天，以前我们总是会讨论彼此的产品，目光聚焦于小问题。后来，我们慢慢学会将思维扩大，讨论大局层面的问题，比如公司现阶段最大的瓶颈是什么？目前公司遇到的最大的风险是什么？甚至会讨论双方公司在人力方面遇到的问题。

其实这样的思考方式就是从解决问题转化为发现问题，只有真正站在公司的角度，才能看到公司的问题所在，才能指引团队向正确的方向前进。

2. 团队配合

一个高效团队必备的素质之一就是，尊重专业人士，寻找优势互补人员，恰好这点非常容易被技术团队忽视。

举个例子，我有一位朋友做 2B 的 OA 系统，他们发现市面上的 OA 系统存在诸多问题，于是自己研发了一套新的 OA 系统，体验确实非常好。

产品做出来后，几个技术人员带着产品展示 PPT 去目标公司谈合作，他们将竞品与自己的产品摆在客户面前，然后开始宣讲自己产品的四大特点、八大优势。结果，直到两周后也没有收到对方回信。

他们百思不得其解，于是我引荐了一位销售朋友，帮助他们推动这个产品的销售。

这位销售朋友非常懂得销售套路，首先他并不是去客户办公室推销产品，而是请对方负责人喝咖啡；其次，喝咖啡期间也没有展示产品 PPT，更未提及产品的四大特点、八大优势，而是询问对方一些问题，比如，最近工作压力如何、目前在用的 OA 系统员工反馈如何等等。

几天后，这位销售朋友将整理过的产品 PPT 拿给对方负责人，一通电话之后，促成了这次合作。

这让几位技术人员很崩溃，百思不得其解。

其实，这单之所以能成功拿下，是因为销售人员懂得为客户解决问题。这其中有两个关键点。

第一点，对方负责人特别怕麻烦，当他第一次看完产品 PPT 后，认为虽然现在用的 OA 系统存在诸多问题，但也能够使用，为什么要换？而换系统后，随着功能增多，会不会面临更多的麻烦？

这一点在技术人宣讲产品时，完全没有想到，更没有告诉对方，其实他们可以做非常简单的云端或者直接部署功能，无需对方过多操心，而对方所担心的问题都能被完美解决。

第二点，对方负责人在喝咖啡时透露，新的 OA 系统确实有许多优势，但这毕竟不是老板指派的任务，他的困扰是如何向老板汇报。

于是这位销售朋友将产品的四大特点、八大优势整合，做成了一页 PPT，并且告诉对方，这套产品几个知名的互联网公司都在用。如此一来，就解决了对方负责人的担忧。既然这套产品有这么多优势，还有知名公司在用，老板一定能认可。

通过这个例子我们能够看到，不论搭建团队还是工作配合，要牢记尊重专业人士，寻找优势互补成员。

迭代之前先验证需求

无论是做软件还是互联网产品，上线之后肯定要进行不断迭代。在此，我想提醒的是，迭代是必须的，但也是有坑的。

迭代最大的坑就是没有需求。

可能你会问，我有明确的方向，有团队，也获得了融资，产品也不是没有人用，怎么会没有需求。

此处的没有需求，其实指的是没有理解用户的深层需求。

我还是举个例子，减肥是女生的需求吗？肯定不是。我从两方面解释原因：

第一，为什么女生天天喊着减肥？因为瘦下来好看，容易搭配衣服。那么问题来了，减肥与好看相比，哪点是女生的需求？答案一定是好看。所以，好看才是减肥的深层次需求，如果你要做一款减肥产品，你对于需求层次的理解，将影响减肥产品的成败。

第二，按照这样的逻辑往下思考，正因为这个时代以瘦为美，所以得出减肥是需求，而方法也很简单，就是少吃多运动，那么，为什么女生总是解决不了这种需求？

春雨医生曾根据专家建议做过 30 天瘦 6 斤的健康减肥计划，但是反响并不理想，因为我们发现，减肥并不是需求，不节食不运动的减肥才是需求。

所以，一定要了解用户的深层需求，才能真正为用户解决问题。另外，在发现用户问题的过程中，一定要验证需求。

对于验证标准，我认为，只要有一个指标让你觉得兴奋，就能称之为标准。

以春雨医生真正满足线上问诊为例，最初，我们对这一需求并没有把握，所以，只找了两位医生做兼职工作，要求每人每天回答一百个问题。结果，上线第一天就涌现出 300 个问题，两位兼职医生根本无法在短时间内答完所有问题。我们当时的方法是限号，比如上午只放出 200 个号，结果到 10 点、11 点就没号了。到了下午，用户就反馈意见甚至打来电话，表示产品体验太差，根本不能咨询问题。

之后我们开始分批限号，依旧在每个时间段的前二十分钟左右就没号了。最后，我们迅速扩量，同时与大量专业医生合作，在两个月内将产品变为平台模式，整个产品就起来了。无论你做多少，有一个兴奋点就够了。

拥抱不确定性

最后想说的是，创业非常辛苦，创业者聚在一起时，彼此都会有种英雄惺惺相惜的感觉。在创业过程中，总会出现各种不确定因素，比如，你的产品非常有潜力，结果 BAT 也开始做了；再比如，你的团队刚稳固，结果合伙人有新的创业想法，想退出团队等等。所以，面对各种不确定性，要做好心理准备，去拥抱它，与不确定性同行。

另外，要多学习，多实践，多跟人交流、早接触尝试。实践并不只有辞职创业一条路，在创业之前，你可以多做一些功课，包括参加技术大会，与已经创业的同事交流经验，与非技术创业者交流经验，利用互联网做开源项目等。通过这样的实践，获取知识、沉淀经验，当你有了知识积累与技能储备再去创业，一定会事半功倍。

作者简介

谢呈，木仓科技副总裁，前春雨医生副总裁及联合创始人，曾任网易有道移动事业部技术负责人。在多年的创业中，分析垂直行业发展、制定并调整战略方向、思考业务和商业模式，对创业和互联网 + 的模式有丰富经验、教训和独到的见解。

第110讲 | 成敏：创业公司为什么会技术文化产品缺失

你好，我是技术领导力 300 讲主编成敏，最近经常参加一些技术创业者的交流活动，听他们聊创业过程中遇到的问题、踩过的坑。

其中一个很有意思的话题是，不少创业公司的产品技术人员会觉得公司没有产品技术文化，或者市场驱动的文化盖过了产品技术文化。

对此，他们其实也很委屈，每个技术创业者在创业之前都是充满理想的，都会想要打造一个技术驱动、产品驱动、模式驱动的公司，但创业的压力实在是太大了。

几乎所有的创业公司从成立的第一天开始就会面临巨大的生存压力，包括基本生存压力、投资者压力和激烈的市场竞争这三重压力。

1. 基本的生存压力
很多创业公司的起始资金都是创始人自己之前积累的血汗钱，我跟很多创业者聊过，只有很少一部分人一有创业想法就能拿到 VC 的钱，大部分还是拿着自己的钱来创业，甚至有卖房创业，把自己全部家底投进去的。

所以，对创业者而言，公司从诞生之初就面临着非常大的压力，每天一睁眼，就是几千、几万甚至几十万的支出，账上的钱一直在减少，但收入却迟迟没有看到曙光。这时，创业之前的那些很优雅的想法，在生存的压力面前，就慢慢开始变形了。

2. 投资者压力
即使创业者拿了融资，不再烧自己的钱了，但是投资者不是雷锋，他给你投钱并不是为了无偿帮助你，而是想获得超出预期的回报。可能他投了一千万，但他会希望这一千万能给他带来一个亿、十个亿甚至百个亿的回报，这才是他们真正的诉求。

因此，融完资之后，可能有的投资人信任创始团队，不会过多参与过问公司经营情况，但这是少数，大部分投资者都会非常关注公司营收，可能会经常问你财务报表怎么样、营收有没有翻倍等，这些都会给创业者带去很大的压力。

3. 激烈的市场竞争
国内互联网行业竞争激烈，一旦出现一个新模式，马上会有几百上千家公司跟上，比如之前的 O2O、P2P、共享单车，现在的区块链等等。但同样的，每个行业到最后可能只会剩下一两家公司成功存活。

互联网时代的商业规则：赢家通吃，数一数二，不三不四。 老大占据大部分市场，剩下的给老二，其他的都无声无息，没有三没有四。

这个规则就决定了，在一个细分领域里，只有成为其中数一数二的公司才有可能存活下去。这给创业者带来了极大的压力，鞭策着他们不停往前跑，无法停歇。

其实，创业者都是非常有理想的人，为了实现他们的创业理想，即使没有外界压力，他们自身也会给自己施加很大的压力，再加上这些激烈的市场压力、生存压力和资本压力，更是如座座大山压在创业者肩上心头，导致公司的实际情况离最初创业时的理想模式越来越远。

经营目标驱动下的研发模型

这三重生存压力带来了公司的经营压力，而有经营压力，就一定会有经营目标。

很多创业公司，在第一年、第二年的时候，因为体量比较小，在经营上会相对比较随性，但到了第三年、第四年之后，就需要开始做公司的年度商业计划，包括产品、市场、财务、人力等各个方面的计划，公司开始向经营目标驱动的模式靠近。这时，导致产品技术文化受伤的情况是，所有的计划最终都会落到一个个数据指标、一个个 KPI 上。

很多创业公司在最初成立的时候，都会说我们是反 KPI 的，但实际上到最后多多少少都会落回到 KPI 上。KPI 本身没有原罪，它只是一个工具，只是 KPI 往往太过强调收入，很容易导致公司整体以经营目标为驱动，忽视了产品技术文化。

这里举个例子，图中是一个手游公司的 KPI 体系，他们会先设计一个目标，比如月流水达到 1000 万，然后整个公司就开始围绕这个目标运转。在设定目标之后，他会先反推目标，例如要达到这样的目标，要达到多少的留存率、多少的用户平均收入、多少的转化率等等。

而这些具体的指标确定之后，马上就会反应到版本特性规划、开发计划上，并细化到每个人的 KPI 上，付诸执行。随后就是定期考核、阶段总结，再之后是根据考核情况和目标完成情况发放奖金、调整团队等。

这就是经营目标驱动下的研发模型，所有都是围绕着经营目标而转。同时，不得不承认，除了创业的最初阶段，公司一旦走入正轨，基本上都要遵循这样的研发模型，大公司无非是整个模型体系中的环节更多、更完善。

这时就会发现，产品技术人员的创意开始让位于 KPI 驱动，也就是业绩经营驱动，这是很多创业公司进入融资阶段以后和规模化运营以后都会面临的情况。

强悍的市场文化、产品技术文化不再

这时，就很有可能出现市场文化强悍，产品技术文化弱势让步的情况。而在这种市场文化之下，产品研发人员最怕的就是需求，然而每天面对也必须面对的还是需求，而且包括来自市场的需求、来自领导的需求、竞争对手带来的需求（比如竞争对手做了一个新特性，公司也得跟上）等等。除此之外，还有为了公司长远发展而做的架构需求、规划需求，还有用户在社区中反馈的需求等等。

对于开发人员来说，在底下实际实现的时候，这些大都是在满足市场和领导的需求，其中可能还有一些很傻的需求，他们也不得不做。但在市场人员眼里，他们完全不会觉得这些需求有问题，因为都有可能给公司带来营收。两者的视角不同，观点就不同。

如此，市场文化就开始和产品技术文化产生冲突，而作为公司、作为管理者，就需要在这两者之间做出一个平衡。

产品技术文化是带有一定理想主义色彩的，每一个技术出身的创业者都希望公司是产品驱动、技术驱动、模式驱动，但实际在执行的时候，往往最先进入状态的是市场驱动。

而在市场驱动的文化下，如果你去跟其中的开发人员聊天，相信提到最多的关键字一定会是“加班、版本、进度、急”这些。很常见的一种情况就是领导发脾气，“你们的进度怎么这么慢，新版本怎么还没做好”，然后施加压力，“新版本赶快出，无论如何这周末必须给我上”。

可能刚开始的时候，这种压力对研发人员比较有效，大家能加班赶进度把新版本做出来，但长久处在市场驱动的文化下，研发人员一定会疲惫，效率就必然会不断降低，这种是一种很典型的现象。

面对这种现象，有些公司可能会从流程改进、绩效考核、员工激励等方面着手提高团队效率，可能能起一时之功，但如果继续任由产品技术文化缺失，研发人员疲于应对各种市场、领导压过来的需求，依然是治标不治本。

总结一下，当前国内的互联网行业，少有纯产品技术文化驱动的创业公司，资本裹挟和市场欲望是大部分创业公司的驱动力，这其实是创新缺失和产品技术文化缺失的主因。

不知道你是否认同这个观点，欢迎在评论区分享你的观点！

第111讲 | 蔡锐涛：从0到1再到100，创业不同阶段的技术管理思考

你好，我是有米科技 CTO 蔡锐涛。有米科技已成立 8 年，从创业期到发展期再到平稳期，这一路走来，作为技术管理者，我有很多思考，今天分享给你，希望对你有用。

了解行业发展趋势

创业前有必要了解行业发展趋势，做好心理预期、人才准备、资金储备等。每个公司都会经历 5 个发展时期，即技术萌芽期、狂热期、幻想破灭期、复苏期与平稳期。

公司在不同时期，技术团队的状态也会不同。首先，在技术萌芽期，所有人都非常兴奋，加班、熬夜、赶工都不是问题。比如人工智能出现时，技术人觉得“这就是未来啊”，所以创业的信心爆棚。之后进入狂热期，可能会接到大量的行业风投与外界给予的资源，这时也是泡沫最大的时候。紧接着会跌入谷底，因为理想与现实差距过大，幻想破灭，此时需要寻求新的增长点。等你扛过这段时期，就会进入复苏期，也是高速发展阶段，这时该考虑如何让团队维持商业化，也是证明自己商业能力的时候。最后进入平稳期，遇到行业天花板，就该考察新机会，寻求新的突破点了。

所以，我会围绕创业启动期、高速发展期与寻求突破期这三个阶段展开分享内容，每个阶段都需要考虑人、财、物这三个问题。对于技术管理来讲，“人”即人才梯队与团队建设；“财”是团队赚钱的能力，理清团队状态和业务需求，这一点很重要；“物”就是对技术栈、技术架构的选择。

创业启动期

一、团队状态与业务需求

创业前期，团队成员目标一致，凝聚力非常高，此时，急需出产品，推向市场，快速迭代。

有米科技刚起步时，我们还在读大三，当时没钱、没办公室，于是想尽办法去忽悠楼管，从她手中拿到了学生宿舍活动室的钥匙，我们在活动室埋头苦干一个月，做出了第一版产品。当时的感觉就像你在做一件可以改变世界的事情，很有激情，所以你为此可以做出任何牺牲。

二、技术栈

在创业启动期，对于技术栈的选择非常重要，我跟很多创业者交流过，技术合伙人想法过于天马行空，喜欢炫技是不少创业者头疼的问题。

我认为，技术创业应该尽量避免使用新潮技术，我们就深受其害，而是要尽可能减少技术成本，使用成熟、稳定的技术，即使那不是自己喜欢的技术。

举个例子，早期的时候，我们在 MongoDB 2.4 时就开始使用它，当时存的数据量不到一亿，使用非常顺畅，但当数据量达到十亿时，数据库平均两天出现一次故障。我们找了一些国外公司的使用经验，但是仍旧没解决，毕竟是一个比较新的数据库。最后迫不得已，改用了 MySQL，虽然它又老又无聊，但稳定、好用。

另外，在创业初期，要专注于自己的核心业务，使用一切外部能够提供的工具。

三、重视技术文化建设

首先要重视知识储备。虽然创业前期人少，但是一定要注重知识储备。这是我们团队受益至今的一件事，我们在创业第一年就建立了自己的 WIKI 系统，将产品设计、架构，以及每一次遇到的故障和解决方案，甚至每个决策，都写进 WIKI 系统中。逐渐累积，它就会变成宝藏，甚至现在在招聘与培养人才时都能用到它。

其次要启动技术文化建设。早期注重技术文化建设也很重要，当时，我们会在每周五学习硅谷的 TGIF（thank God it’s Friday）分享会制度，公司二三十号人聚在一起，随意聊各种各样的话题，包括用到的好用的 APP、吃到的好吃的食物等。不仅加深了彼此间的关系，还能加上对公司的认同。那批最早的核心同事现在都已经变成了公司技术文化的布道者。

高速发展期

一、团队状态与业务需求

当公司进入高速发展期，业务可能一个月翻一倍，团队像打了兴奋剂一样冲劲满满。这时，业务增长非常迅速，人员大规模扩张，沟通、协作效率逐渐降低。

二、技术架构

在高速发展期，关于技术架构有三个关键点：

第一，Design for Growth，也就是为你的 10 倍增长设计。当时，我们也遇到了很多发展问题，我经常去国外交流请教经验。在理念方面，我最大的收获就是：你每个模块的设计、重构都要为 10 倍的增长而准备，按照这个 10 倍指标，去做升级。因为在重构的过程中，业务还在不断增长，等重构完成后，新的架构需要能够满足新的业务需求。

第二，重视人员的知识储备，遇到问题时再学习就晚了，应该未雨绸缪，着眼于下一个业务量级所要面对的问题。

第三，设立基础研发部门，实现基础组件服务化。当时我们设立了一个基础研发部门，把面向机器的人员剥离出来，只留下面向业务的人员，他们不用再担心机器层面的问题，可以专心处理业务问题。

这样的组织调整在大公司里司空见惯，但对创业公司来说，早期并不适合做这件事，也没那么多人手，但在发展期，当你能够预见问题的时候，就应该开始去做这件事。

三、沟通协作

在高速发展期，我们会直面沟通复杂度的线性增长。在这里，提升沟通效率有两个关键点：

第一，在于工具，重视内部流程自动化，不要吝啬对工具化的投入。当时，我们设立了一个新的小组，专门负责优化内部的协作流程工具，保证沟通协作效率。

第二，在于人才梯队建设的改变。从人管人、人带人到文化、制度管人，培养人。当时，我们在技术团队做了一个尝试，让所有的核心技术人员写下他们的最佳实践存入知识库（比如在 Python 中对于数据的最佳处理方式），用文字来沟通、来传递信息，可以达到一对多沟通的效果，从而提高协作效率，降低部门沟通成本。

四、人才梯队建设

在这方面，我们也做了一些改造组织架构、技术体系的事情，来适应大规模招聘带来的问题。

首先是人才管理方面，保持社招，重视校招，引入 OKRS，因为我们在广州的大学城，又重视校招，所以，在公司快速成长期，只有 20 名正式员工的情况下，招入了 30 个应届实习生。因为在 2013 年左右，大公司招人不计成本，我们在社招方面根本抢不到人才，所以就只能自己培养。当时校招的 30 人，最后留下来的将近 10 人。

我们的培养方式就是以老带新，新同事学习老同事的教程和最佳实践方案，然后将理论投入实践。

其次是技术架构方面，从靠人，到靠系统自动化管理，适应高频度的迭代上线。我们只有三个人负责海外的业务，所有的服务器都是自动化。只有机器高频度的迭代上线，才能使人尽快响应这么快的开发节奏，使系统能够响应整个业务发展。

然后是组织架构方面，我们做了分层，拆分，用单独项目组面对高速发展的业务需求，用独立团队把握基础架构的弹性和稳定。

最后在培养方面，我们建立了领域委员会和学习机制，每周有专人组织分享会，我觉得分享的难点在于愿意分享，所以，在创业早期，就应该鼓励分享，什么内容都可以，逐渐形成分享文化。

五、知识系统管理

高速发展期，人员流动大，所以要重视知识沉淀，降低人员流动带来的传承问题。作为技术管理者，要吸纳技术人才，更要将他的能力留下来，对此我总结了三点：
1. 总结公司各领域最佳实践到 WIKI。
2. 梳理公司技术栈，减少重复造轮子，减少重复招人带来的成本。
3. 重视内宣，鼓励技术团队对内宣传自己的优秀组件，鼓励同类团队间的交流。

我认为 CTO 中的 T 是 Talk（讲话），你要多谈话、多分享，多宣讲正能量，多营造交流氛围。比如，我们的程序化交易团队，会跟算法团队一起交流。我们鼓励交叉分享，这样不仅能互相学习，还可以碰撞出更多可能性。

寻求突破期

一、团队状态与业务需求

当我们最初选定方向时，其实就确定了天花板。比如，选择做游戏，游戏在中国的市场不到千亿，腾讯和网易就切割掉 70%，剩下的 30% 既是你的市场，也是你的天花板。当然，在公司寻求突破时，就说明它已经成功了一半，目前我们正处于这个阶段。

在寻求突破期，业务多且稳定，在满足财务指标的同时，需要寻找新的突破点。这时人员流动也较大，因为泡沫挤出后，我们就不需要那么多人了。

另外，因为你要不断尝试突破，而新项目尝试的失败率也非常高，相当于再次创业，所以，成功率在百分之二就已经非常不错了。

二、技术架构需求

既然尝试突破是当下最重要的事，首先我需要不断提高组件化能力，降低试错成本。比如我们的公众号业务，利用爬虫软件每天抓取全国上万个公众号文章内容，供业务人员参考，降低试错成本。

其次要围绕数据，建立在数据之上挖掘需求，给运营团队提供非常好的工具，帮助他们精准分析数据。

三、寻找突破点

我认为，在平稳期寻求突破的最大挑战是，从关注一个点，到关注多个点，对于这个挑战，我有三点建议。
1. 走出去，强化情报和线索搜集能力。
2. 保住人，就是核心人才保留计划。我们会尽量满足核心人才的需求，比如钱、婚姻等，也可以送他读 EDP、MBA、EMBA 等等。
3. 强技术，提供更好的技术研发条件。这也关乎试错率的问题，作为技术管理者，要鼓励技术创新，而创新过程中一定会有失败，也要求技术人员有承受失败的能力。因为有的人在失败一两次之后就受不了了，所以技术管理也要区分哪些人适合试错，哪些人不适合。对于后者，那他只需做好自己的工作就可以了。

四、组织变革

组织架构其实是围绕各种极端性变化的，早期人少，没有关键点，到发展期，随着人员能力的增长，组织架构需要进行优化，从而提升团队效率。但在寻求突破期又有不同，我希望我的组织架构能多变化，在碰撞中寻求最优架构，我们组织变革的关键点是拥抱不确定性。

比如我们弱化部门，强调项目组，提高组织的灵活性，鼓励大家用脚投票，如果你在某个项目组待不下去，可以调换项目组。我们会及时处理状况不好的项目组。

在业务相对稳定期，大家的工作内容相对固定，所以我要利用这段时期让所有人都能多了解其他工作内容，而不是只盯着自己手头的一亩三分地，特别是那些优秀人才。

总结

创业初期比较容易忽略文化建设；高速发展期，重要的是人才梯队建设和知识沉淀，以便传承；而寻求突破期，就要营造氛围，加深人员之间的联动，碰撞出最大能力。

作者简介

蔡锐涛，有米科技 CTO，联合创始人，中国最早的移动营销技术专家，专注于移动广告平台及移动应用商业化变现方向相关产品技术的研究。

第112讲 | 刘俊强：必知绩效管理知识之绩效管理循环

你好，我是腾讯云资深架构师、TGO 鲲鹏会会员刘俊强，有 8 年以上的技术管理经验，今天想跟你分享技术管理者必知的绩效管理知识之绩效管理循环。

可能绝大多数互联网从业人员都会对一件事达成一致意见，那就是绩效评估既严肃又不好玩，因为绩效会影响员工的奖金和晋升。说实话，对于技术管理者而言，学会如何进行绩效管理尤为重要，我们应当让绩效管理变成有效的管理工具，有效地激励团队，帮助团队成员更好地了解自己的工作及未来的挑战。相信到那时，你已经是一位卓越的管理者了。

了解绩效管理循环

其实，我们接触最多的绩效评估（或绩效评定）仅仅是整个绩效管理循环中的一部分，因为绩效评估直接与利益挂钩，所以，我们对这个阶段最为熟悉。但作为技术管理者，要学好、用好绩效管理，不仅需要关注绩效评估阶段，还应该将目光放于全局之上，关注整个绩效管理循环。

我将绩效管理循环简化为三个阶段，具体如下：

阶段一：Planning，绩效目标制定。该阶段主要根据公司战略目标，与团队及团队成员一起制定预期绩效目标，同时也要进行完成目标所需的资源评估等。

阶段二：Check-in，绩效辅导。在该阶段，管理者需要跟进目标完成情况，并给予团队和团队成员必要的支持与帮助，为完成目标扫清障碍。同时，可能需要根据实际情况对之前制定的目标进行调整。

阶段三：Review，绩效考核与反馈。在该阶段，管理者将通过绩效数据对团队及团队成员进行绩效评定，同时，需要就绩效结果跟团队及团队成员进行反馈和沟通，给予团队及团队成员一些发展建议与指导。

为什么将其称之为绩效管理循环呢？因为，通常当我们执行完第三个阶段后，就会进入下一个循环的第一阶段，所以称之为绩效管理循环或绩效管理周期。至于具体的循环周期为多久，可以根据公司的实际情况来设定，底线是不能少于一个季度，原因主要在于，绩效管理循环不光是技术团队内部的事情，还需要人力资源等其他团队的参与。从公司运营的最佳实践来讲，绩效管理循环周期一般为半年或一年，且不能超过一年，否则绩效管理就失去了意义。

为了方便大家了解这个简化后的绩效管理循环，我做了一个示意图，如下：

正如前面所说，绩效评估既严肃又不好玩，在工作中是最令人害怕、受人鄙视的，但实际是几乎所有的公司都在使用它，在我看来，关键问题在于管理者通常没能很好的使用这个工具，因此大多数员工都不喜欢绩效考核。

因此，全局性的了解绩效管理循环，有助于我们了解各阶段的意义，以及各阶段应该做哪些事情，使我们更有效地使用绩效管理。同时，这样做也可以帮助我们变得更好，管理能力更为精进。但需要注意的是，还是不要期望所有员工都喜欢绩效考核，因为有些人就是不喜欢被评估。

在整个绩效管理循环中，最重要的是专注于发展，包括两方面：一是公司业务发展需要制定有效的绩效目标；二是通过绩效管理指引团队及团队成员的发展方向，并帮助他们进行有效提升。从这个角度来看，绩效管理是为业务发展提供达成目标的基础，并未为团队和团队成员的未来发展提供基础。

适应绩效管理循环

正如前文所说，绩效管理是一个周期内持续循环的过程，这个循环周期可以是半年，也可以是一年。那么，在绩效管理循环周期内我们该如何操作呢？

在此，我先明确错误示范，管理者往往会忽略整个循环周期，直接在阶段三，即绩效评定与反馈阶段开始绩效管理工作，这是极为错误的做法。绩效管理的目的是员工管理，是整个周期内持续不断的过程。

其中，阶段三的绩效评估工作可能只会花费我们 1 到 2 周的时间，阶段一的预期绩效目标制定可能会耗费我们 3-6 周时间，而整个周期内的剩余时间便是用于阶段二的绩效辅导工作。不难理解的是，我们使用绩效管理工具，其根本目的在于帮助团队达成目标。

适应绩效管理循环的关键在于，管理者有效地使用跟进检查方法，而跟进检查的主要作用有三点：
1. 提供支持与帮助；
2. 保持可见性；
3. 避免员工在阶段三出现麻烦。

有时我们认为公开询问员工的工作状态很有必要，这确实管用，但有时候也会适得其反，因为有些人不喜欢别人用对待未成年人的方式对待自己。所以，你需要清楚，跟进检查的目的是，为达成他们目标提供必要的支持与帮助，这种情况下再采用正面、积极的询问方式进行检查会更为有效。

跟进检查的第二个作用是保持可见性，这点很关键，因为这样团队能够时常看到你，知道你在乎并正在关注他们所做的工作及所达成的成长。

另外，采用定期检查与不定期检查，能够帮助我们更了解团队及团队成员的工作进展和状态，以防在阶段三进行绩效评定时，出现因关注少或不了解，造成对团队或团队成员评定不客观的情况。因此，我建议大家在阶段一制定绩效目标时，就同时制定出对目标的定期检查与跟进计划。而在跟进检查的过程中，也需要定期与随机相结合，保持对团队和团队成员的关注度。当然，值得注意的是，检查也不要过于密集，否则你会被贴上控制欲极强的标签。

最后，在每次跟进检查后，你需要总结情况并进行记录，备忘录、电子邮件等都可以，但需要斟酌的是，哪些需要私下记录，哪些需要公开记录并同步给团队成员。

总结

本文从全局视角介绍了什么是绩效管理循环，并阐述了作为管理者该如何适应绩效管理循环，从而能够充分、有效地利用绩效管理这个工具。

我会在后面的文章中，详细介绍如何进行绩效目标制定、绩效辅导以及绩效评定与反馈，欢迎持续关注。

最后留一个思考题，在你使用绩效管理工具时，绩效管理循环中的哪个阶段做得不够充分？欢迎在留言区与我分享、交流。

感谢你的收听，我们下期再见！

作者简介

刘俊强（微信公众号：程序员精进），TGO 鲲鹏会会员，现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+ 年以上互联网开发经验，8 年以上技术管理经验。

第113讲 | 程军：技术人的「知行合一」（二）

你好，我是贝壳技术总监程军，这些天抽烟的频率有所提升，一天多了半包。因为需要更深入的思考才可以输出更有价值的文章。关于本篇内容，我想了很久，最后决定写一写国内外领导力的对比，就以亚马逊创始人贝佐斯（Jeff Bezos）和曾国藩为例开始吧。

远见卓识

我们先来领略亚马逊领导力准则之远见卓识。

徐飞总的极客时间专栏《技术和商业案例解读》中的第 89 讲，就讲了亚马逊领导力准则中的“远见卓识”这一条，我摘录了其中的两段，原文如下：

亚马逊领导力准则之远见卓识的官方解释是：局限性思考只能带来局限性的结果。领导者大胆提出并阐明大局策略，由此激发良好的成果。他们从不同角度考虑问题，并广泛寻找服务客户的方式。

这条领导力原则主要关注领导者的思维方式。贝佐斯要求领导者不拘泥于局限性的思考，要保持脑洞大开的状态。领导者可以从不同的角度去思考问题，发现别人不能发现的，想到别人不能想到的。这种远见对于一家公司的成长来说非常重要。

从以上内容中，我对这条领导力准则的核心理解是，领导者一定要从不同的角度去思考，不局限，不武断，并且开放、包容，可以简单概括为“远见”二字。

担当大事之“明”

曾国潘说过，“担当大事，全在‘明’‘强’二字”。今天，我主要分享我对于其中“明”的理解，主要分三个层面：

一、明即光明

明字由日、月两部分组成，而在甲骨文中以日、月发光表示明亮、光明，也可以说是正确的方向。

众所周知，因为每个人看待问题的方向与角度不同，相同的问题，每个人得出的方法与结果也会有所差异。所以，面对问题，首先要认清正确的方向，这是关键，再坚持去执行。

我们公司有一条朴素的价值观是——坚持去做难而正确的事。相信这也是我们老板做事业的核心价值观，并把这条价值观赋予了每一位贝壳人。

举个例子：

一位朋友在今年 8 月跟我倾诉他的困扰，老板要求年底前招聘 120 个左右有经验的 Go 语言开发者。根据他的描述，这个目标已经是确定不能更改的了。而分析现状发现，目前 HR 的支持非常给力，招聘渠道则主要是猎头、内推等渠道。初看这个问题我们能想到的解决方案会有很多，列出最常见的三种：
1. 增加更多的专业猎头渠道；
2. 统计从收到简历到最终入职的转化率，分析各个重要环节提升转化率；
3. 提高内推奖金，比如可以在原本的基础上再加 5000 元。

当时我给出的建议是，首先要考虑整个上海的 Go 语言开发者容量有多大，这需要动用你的资源（HR+ 猎头）进行估算，然后，乘以你的目前转化率，就是最终理想的招聘数量。

如果数量与目标 120 人有较大差距，那么以上所提的所有解决方案都无效，问题此刻陷入了僵局。另外其实也不用太过担心老板规定的 120 这个数，因为老板也是讲道理，你汇报工作时，拿出图和表，绘制这个简单的数学公式给他，他自然会明白的。过了一周他告诉我，按实际估算的结果来看，120 这个目标根本达不成。

不久后，我主动问他招聘结果，他很开心的说，问题已经有了新的解决思路，就是招一些其他语言并愿意转到 GO 的程序员。

我觉得解决一个问题会有很多办法，但是哪个才是有效的、才是最正确的方向，需要我们站在问题之外去考虑，才能更好的找到。愿光明照亮你我的技术领导力之路。

二、高明与精明

曾国藩又有言：明有二端，人见其近，吾见其远，曰高明；人见其粗，吾见其细，曰精明。

这句话的含义是：“明”有两种，一种是高明，看得比别人深远，高瞻远瞩；另一种是精明，看得比别人细致，明察秋毫。

这里举一个最近几天和团队小伙伴沟通的例子：

团队中的一位 P6 的后端研发同学说最近有些疑惑，想找我沟通，于是找了一个我俩都有空闲的时间，准备坐下来好好聊一次。他说自己喜欢研究一些新的框架和技术，但问题是，他发现自己坚持一段时间后就坚持不去了，内心感到有些慌，需要解惑。

我问了他两个问题：
问题 1，学习目标达到了吗？他回答还有一些差距但有所收获。
问题 2，你觉得差距有多少？他没有回答上来。

我认为他是精明的，知道自己想要什么，并且很努力，只是结果不那么如意罢了。

随后我和他一起制定了一个切合实际的目标，并按 SMART（s= 特定细分、m= 可测量评估、a= 可触达、r= 依赖的资源、t= 时间）原则细化其中的一个目标。我跟他讲，我们先制定 1 个月的目标，还需要将其分解到每周为单位周期。这个目标要可以量化、可以评估，同时需要重点考虑可依赖的已有资源（可能是人也可能一个 GitHub 开源项目或其他）。

另外，在我们计划执行过程中，有时会因为一些不可抗力因素而需要调整目标，对此不用太玻璃心或患得患失，这都是正常的。借用二爷在《邱岳的产品手记》中的一句话，“没有任何一个作战计划在作战过程中还行之有效，但是做计划本身还是必要的”。

显然就这个 case 而言，我看的更远，或许是高明，你认同吗？

但是仅有高明还不够，在我的理解中，高明是战略层面，精明是战术层面，高明与精明是个统一体，二者需要高度结合。只有高明则眼高手低，只有精明，则容易缺乏大局观，难成大器。这里用曾国藩的另一句名言收尾，即“古之成大事者，规模远大与综理密微二者缺一不可”。意思是真正成大事的人，战略的大局与大势和细节的考量与处理，缺一不可。

三、当局者迷，旁观者清

曾国藩有一句话叫：天下事当局者迷，旁观者清；事前易暗，事后易明。

这里主要想跟大家聊一下“当局者迷，旁观者清”，下棋的人都知道，旁观者不受胜负输赢的影响，自然脑子清醒，可以从两方棋手的角度看待问题，从而跳出局限看清局势。而当局者因为胜负输赢与自己息息相关，很容易受到影响看不清局势。

继续举个例子：

我还记得当年我在 1 号店负责公司供应链（仓库管理系统简称 WMS，物流运输管理系统简称 TMS）系统研发的时候，公司 CEO 于刚先生邀请了一支咨询团队来了解 1 号店整个 C 端用户购买和退换货体验，以及运营类员工（核心是仓库、物流、客服人员）使用内部支撑系统的体验。

咨询团队提出了非常多的问题和优化建议，随后我们多次开会讨论，从提升 C 端用户体验出发，我们着重解决了用户最头疼的退换货问题，还推出了订单半日达服务；从提升内部效率出发，我们的 WMS 系统从人工波次改成系统自动波次和人工波次相结合，TMS 系统中最后一公里的配送路径，从依赖配送员经验分配路线，优化成系统结合订单商品的核心属性、用户地址等维度给出最优配送路径，配送效率大大提升的同时，用户投诉也减少了不少。

但是当时，我和我们领导其实并不太理解公司的这种行为，认为这是一种太信任的体现，我们觉得之前的 C 端系统和内部支撑系统已经非常好了，并没有那么大的改进空间。但结果证明，这支咨询团队之后优化建议是非常有价值的。

今年 9 月，我在看于刚先生写给创业者的《激情创业：让不可能变为可能》一书时，才明白他当时的做法并不是不相信我们这些系统设计和研发者，而是希望找一个身在局外的团队去找问题、去无情的暴露问题。因为局外人通常会站在公司内部和用户双方的角度思考问题，更容易跳出局限，直击要害，找到问题的关键所在。

这就应了曾国藩另外一句话：任事者，当置身利害之外，建言者，当设身于利害之中。

时间过去 9 年了，我对于公司当时的行为，也从当初的不理解变为此刻的赞成，这也许就是从当局者迷到旁观者清的转变。

总结

本文我们首先领略了亚马逊领导力准则之远见卓识，按徐飞的总结是领导者要有远见，接着我分享了对于曾国藩的担大事者之“明”的三点理解，即光明、高明与精明以及当局者迷，旁观者清。聪明的读者不难发现，这两条领导力原则高度一致，都在于对事物的高度与方向有清晰的把握，对战略和细节有足够的理解。

为此，我还特意咨询过于刚先生（他在亚马逊任高管时直接向贝佐斯汇报工作），贝佐斯是不是曾了解过中国的领导力文化，他的答案是，贝佐斯并没有了解过中国文化，也许这就是所谓的英雄所见略同吧。

如果你对这个话题有其他认知，欢迎留言与我分享，也欢迎来我的知识星球“小卒吾「知行合一」”（星球号 5139329）跟我一起探讨技术人关于认知和如何在领导力这个领域内实践知行合一相关的话题。

作者简介

程军，现任贝壳技术总监，曾任饿了么技术总监、1 号店架构师，10 年以上互联网开发经验，8 年以上技术管理经验。

第114讲 | 成敏：谈谈不同阶段技术公司的特点

你好，我是成敏。技术体系建设是每个 CTO 都需要关注的话题，但技术体系建设很难像技术工程建设那样，得出一个最佳实践。因为每个公司的背景、业务形态、组织结构，甚至 CEO 性格都有所不同，而这些因素都会对技术体系的建设产生影响。

今天就简单的以公司规模大小为划分标准，分析在不同规模下，技术公司的业务特点，以及要做好技术体系建设可能面临的困难。

第一个阶段：十人左右规模

当公司规模比较小的时候，比如还处在初创阶段，这时公司可能只有十几人，机器也只有十几台，规模很小。在这个阶段，公司的需求变化通常会非常快，甚至可能还没有确定业务的主营模式。很有可能公司今天尝试某个方向，结果发现此路不通，第二天就转换方向，试行另一个方向。

其实，不少创业公司就是在这样的快速迭代，不断试错中找到了自己的爆发点。

这样需求变化快且业务模式难以固定的团队，对团队成员技术栈宽度的要求会非常高。比如研发岗位除了做好研发工作外，还需要承担测试、上线等工作，甚至之后的运维也需要他们来负责。再比如，这时的 CTO 不仅要把控技术方向、管理技术团队，还得上手写代码，更有可能还要去机房看机器情况。

因此，在这个阶段，公司会更看重研发人员的单兵作战能力，之前很流行的全栈工程师正是在这样的需求下应运而生。同时，在这个阶段，团队往往有着非常高效的沟通效率和执行速度。可能有个需求提出来，团队几个人周末加个班熬一下，周一就能上线了，非常快。

当然，这个阶段，团队的问题在于，一是团队的技术天花板会受限于单兵的技术水平；二是缺乏人才储备、规范化程度也比较低，一旦有人离开，就会极大的影响研发进度；三是技术成本投入很难实现规模化。

第二个阶段：五十人左右规模

这个阶段，公司稍微有点起色了，团队规模也达到五十人左右，机器也能有一两百台的规模。

这个阶段，公司的业务主体已经比较明确，但需求变化加快，可能比之前初创期来得更快。团队在这个阶段开始有了明确的分工，但未必有分组，比如运维工作会招一两个专职的运维来负责，不再由研发兼任，但还没法形成专门的运维团队。

在流程上，公司开始关注协同及规范，只是整体的流程规范依旧比较简单，自动化程度比较低，协同比较松散。这个时期，内部沟通依旧会比较顺畅，只是需要警惕不要让公司陷入到作坊式作战的陷阱中去。

第三个阶段：百人左右规模

这个阶段，团队规模一般能达到上百人，机器规模也能达到一两千台。一般到了这个阶段，公司的主营业务已经相对稳定，也开始做 1-2 年左右的规划，因为如果没有一个稳定的主营业务，创业公司也很难进入这个梯队。

这个阶段，业务需求仍然大于技术资源，而技术和业务上的分组都已经开始产生，除了基本的分工之外，会有一些明确的分组去负责明确的事情，比如 A 团队就负责 A 这个业务线，B 团队就负责 B 这个业务线。

在这个阶段，公司也会更重视流程规范，会尝试利用开源工具完成最原始的自动化，团队成员的自主性、自我驱动力也会非常强。其实在第一个阶段，初创团队成员的自我驱动力也非常强，但由于单兵作战，这种驱动力产生的成果往往不具备规模效应，一个人又管研发、又管上线、又管运维，即使他基于流程痛点写了个小工具，节省的也只是自己一个人的时间。

但在第三阶段，上百人规模的团队已经初步具备规模化的效应，比如针对流程写出符合团队需求的工具，在技术上做点有意义的事情，产生的影响力很容易就会扩散到整个团队，提高整个团队的效率。

当然，这个阶段也会存在问题，如人员梯队开始明显化、沟通壁垒开始出现等。毕竟整个公司有一两百号人，每个人的能力、认知等各方面都会有比较大的不同，又不像小团队那样可以坐在一起面对面沟通，很容易出现沟通上的问题，导致沟通效率下降。

第四个阶段：五百人左右规模

这是很多中等公司所处的位置。这个阶段，公司业务已经相当稳健，团队规模一般会达到五六百人，机器也能有三五千台，也有能力做 2-3 年左右的中期规划。

这个时候，公司一般已经有了独立的技术服务团队，也就是除了简单的分工、分组之外，公司还会有一些专门的技术团队专门为内部其他团队提供支撑服务，比如内部的工程效率团队等。

在这个阶段，公司需要尤其注重人员培养机制和梯队的建设。一方面，对这个阶段的公司来说，人员流失是一个非常大的问题；另一方面，与大公司相比，这类中型公司的技术影响力与人才吸引力都比较弱。因此，想要公司更上层楼，就一定要打造好人才培养机制和梯队，加大加深公司的人才储备池。

另外，在技术层面，这个阶段的公司还会面临两个问题，第一个是技术债务的归还，在目前业务比较稳健的情况下，要不要调整或重构用了几年的老系统。

第二个是技术路线的争议，团队小的时候，大家可能没想那么多，只要系统能跑就好了，但到了这个阶段，不同的语言、框架、架构各有利弊，团队成员也各有偏好，到底如何做技术选型，就成了这个阶段的一个问题。甚至曾有团队为了确定选择哪个框架，连续开了两次会还没有讨论清楚，耗费了时间与组织技术资源。

当然，还有技术上的重复建设，跨团队的协同沟通等都是这个阶段需要面对的问题。

第五个阶段：两千人左右规模

这个阶段，公司规模一般已经超过两三千人，机器也有几万台。这个阶段的公司，一般已经拥有完备的技术体系和人才体系，也有足够的资源建立前瞻性的技术研究团队，能够应对未来至少三年以上的长期规划。

对于这个阶段的公司，会更注重技术文化的建设和价值观的传递。另外，在这类大型公司里，很容易出现业务分工上的问题，毕竟各个团队之间的职能范围、业务范围有重叠，团队间的竞争在所难免。这种竞争关系，一方面能够调动员工积极性，促进公司业绩，但另一方面，也会带来技术损耗，甚至形成政治壁垒。

最后，对这类大公司来讲，最重要的就是要做好长线规划，否则一旦遇到问题，很难在航行中调转方向。

小结

本文将技术公司按照规模大小简单分成了五个阶段，每个阶段的特点和面临的问题都各不相同，不知道你所在的公司目前处于什么阶段呢？当前面临的最大的问题又是什么呢？欢迎留言与大家分享。

感谢你的收听，我们下期再见！

第115讲 | 成敏：打造优秀团队与文化的三个推手

你好，我是成敏，团队与文化的重要性已经毋庸赘言，每个有追求的公司都会致力于打造优秀的团队与文化。

毕竟在当前高速变化的互联网行业，新的技术和新的模式一直在不断涌现，如果能拥有健壮的团队和优秀的文化，就能有更多的机会克服障碍，抓住新出现的机遇。

同时，发展优秀的文化需要团队本身达成共识，而这种凝聚力会正向地反映到团队所构建的产品上。优秀的文化促成优秀的产品。

那么如何打造优秀的团队与文化呢？一般我们可以从组织与梯队建设、制度建设和文化建设三个方面入手。

一、组织与梯队建设

组织建设

先来看组织建设，通常，组织建设有三个考量点，即沟通效率、执行效率、人力成本。

常见的组织结构有垂直向划分、横向划分、矩阵型划分等几种。有些公司以技术类别垂直划分为 QA 部门、运维部门、前端研发部门等等。有些公司则以业务为导向横向划分，每条业务线中都有各自独立的研发、QA、运维等人员。还有些公司经常在这几种模式间切换，我们很难说那种划分方法是完全正确的。

不过，沟通效率通常与组织结构划分有关，而技术组织是业务体系的一种映射，当技术组织与业务体系匹配时，整体沟通效率会更高，反之就会出现各种各样的问题。

举个例子，某公司创业之初，为了方便管理，组织结构是以技术类别垂直划分。但团队规模大了之后，发现在这样垂直划分的结构下，某个产品或某个业务需要协调后端、前端、移动端、运维等多个部门，沟通难度大大增加，导致沟通效率大大降低。

当发展到五百人左右规模的时候，团队已经承担不起这样的沟通成本，决定按照业务线重新调整组织结构，将其变为横向划分，这样，每个业务线都包含各自所需的技术、产品、运营等人员，沟通效率、资源分配率、成本核算率都大大提高。

而执行效率与沟通效率一样，其所需的成本占比都会随着团队的变大而增加。举个例子，某个业务需要移动团队支持，但在垂直划分的组织架构下，移动团队还需要支撑公司其他业务线，你的需求只能进入他们的需求池，按照排期慢慢做，但对你来讲，整体执行效率就会大打折扣。

至于人力成本，垂直划分的组织结构下，因为人员集中，人力成本会相对节约，而横向划分则相反，它会带来一些人员的重复建设，造成人力成本、技术成本上升，但相应的，它也能带来业务效率的提升，所以就需要你在做组织建设时，好好衡量人力成本与业务成本之间的关系。

梯队建设

再来看梯队建设，一个合理的梯队建设可以帮助团队规避许多风险，主要包括：

1. 降低人员变动风险
如果团队中只有一个能力很牛的人，其余都是刚毕业的或是能力比较初级的人，那么一旦这位牛人离职，他所负责的工作就没人能顺利接手。所以，我们需要搭建合理的梯队，来降低人员变动风险。

2. 使技术人力成本更加合理
即使在同一个技术团队，总有些工作是属于攻坚突破的技术活，还有些则属于增删改查的体力活。如果团队的梯队结构分配不合理，比如让高水平的工程师去做那些相对他的技术能力来讲很初级、很简单的工作，这绝对是技术人力成本的浪费。同时，工程师本身肯定也干得不爽，很容易离开，造成团队的损失。

3. 定制人员成长发挥空间
作为技术 leader，一定要定期 review 团队的梯队结构，至少一年一次，因为在技术团队中，人员的变动和人员能力的变动都是非常快的。当然，review 的时候，除了技术能力外，还要多多考虑其他维度的因素，比如沟通能力、性格，甚至年龄、性别等，以此来定制人员的成长发挥空间。

以沟通能力为例，如果一个团队里都是那种个性固执、不擅沟通的纯技术人员，那么这个团队跟产品团队的沟通就会非常吃力痛苦。所以，技术 leader 在考虑梯队建设时，一定要考虑团队里哪些人擅长沟通，就让他们多负责跟产品、业务等其他团队的外联事务；哪些人更喜欢钻研技术，就给他们更多机会去研究、突破技术难点。

一个强健的团队需要多种能力的人才，而合理的梯队有助于个人发挥其能力，使其快速成长，进而强大团队。

二、制度建设

制度建设又可以分为流程规范和知识库两个方面。

流程规范

先来看流程规范，流程不是为了最好地解决问题，而是为了避免最坏的情况产生。同时，规范也不是为了统一对错，而是为了协同共识，以编码规范为例，我们很难说哪种风格是对的，哪种风格是错的，公司选择某个规范也并不是认为这个规范就是对的，只是为了协调团队达成一个共识，让团队在基准问题上保持一致性，规避争议。

另外，流程规范本身也是有成本代价的，老掉的流程比没有流程更有害，所以，作为技术 leader，也要像 review 团队梯队一样，经常 review 团队的流程规范，检查其是否符合当前业务形态，其中又是否有疏漏。

知识库

再来看知识库，俗话说“见字如见人”，同样，在技术团队中，知识库的水准基本可以衡量这个团队的整体水准。

很多一线的技术人员可能会认为构建知识库是个重复而麻烦的工作，不过是把做过的东西再写一遍，但作为技术 leader，必须清楚知识库对于技术团队的重要性。

互联网行业人员流动快，可能过了三五年，一个团队中的人员就基本都换了一遍。这时，如果没有完整的知识库，很多东西就没法传承，可能上线多年的老系统没人能弄清楚，新人就不敢去动，一些最佳的解决方案也没人再去回顾，导致重复劳动等等。

另外，如果没有知识库体系，公司的业务知识、技术知识难以传承，就很容易出现“业务绑架”的问题。所谓业务绑架，指的是某个员工所在的岗位比较重要，可他能力较弱或态度较差，但他会以某些独特而有价值的知识长期占据该岗位，并且不愿意与人分享，而构建知识库能极为有效的避免出现业务绑架问题。

三、文化建设

优秀文化对团队、对技术人员有着极强的凝聚力，但文化建设是一个很难谈的问题，它与组织形态、业务形态等各个方面息息相关，不过在大的层面，我们需要遵循两个要点。

首先，文化的建设应避免理想主义，必须有明确的目标，比如这种投入产出是为公司服务的软形态。举个例子，很多公司都会花费时间、金钱去组织团建，但团建时，往往还是熟络的同事在一起玩，组成一个个小圈子，很少有活动能够真正将整个团队融合在一起，并将公司想传递的消息传递给每个人，这样的团建其实就只达成了一半的目标。

其次，文化的建设应该基于共识，而不是强推。文化的核心在于融入，而非排斥。君子和而不同，我们应该尽量将不同背景、不同年龄、不同想法的人融合在一起，这样才是良好的团队文化。

小结

团队与文化的重要性毋庸赘言，所有的公司都希望能拥有健壮的团队和优秀的文化，本文从组织与梯队建设、制度建设和文化建设三个方面出发，总结了一些打造优秀的团队与文化的经验，希望能给大家带来一些启发。

感谢你的收听，我们下期再见！

第116讲 | 刘俊强：必知绩效管理知识之绩效目标的制定

你好，我是腾讯云资深架构师、TGO 鲲鹏会会员刘俊强，有着 8 年以上的技术管理经验，今天想跟你分享技术管理者必知的绩效管理知识之绩效目标的制定。

我们在前一篇文章中介绍了绩效管理循环，全局性地了解了绩效管理的三个阶段，在本篇文章中，我将来聊聊绩效管理循环里的阶段一，即绩效目标的制定。

现代企业管理中普遍使用的绩效管理工具有『关键绩效指标』（简称 KPI）和『目标和关键成果』（简称 OKR），不论是 KPI 或 OKR，目标的制定都是十分关键的，因为实际绩效需要通过目标完成情况来进行评定。在探讨具体如何进行目标制定前，需要明确的是，绩效目标一定要在考虑业务发展需要的前提下，与员工来一起制定，需要互相尊重地达成一致。

制定目标的正确姿势

首先需要了解的是绩效目标的制定过程，它并不是由老板到下属设定任意目标的简单过程，而应该是一种平衡多种需求的过程。绩效目标本身应该给员工提供明确可实现的目标，从而激发员工产出优异的绩效。有效的绩效目标需要考虑以下几个方面：

目标需要在员工的能力范围之内，远超出员工能力的目标是不可取的；
目标需要有助于员工的发展和意愿，与员工发展意愿背离的目标可能会造成员工的不稳定；
目标需要帮助公司实现更高层次的目标，不能够帮助公司实现业务发展的目标是无效的；
目标需要帮助团队更好的成长和发展。

这里需要声明的是，没有完美的绩效目标，也就是说不能希望有个绩效目标是完美满足以上几个方面的，如果我们制定的绩效目标并不能满足其中的某一个需要，这种情况是可以接受的。但同时我们要明确的是，制定的绩效目标不要处在以上这些需要的对立面，毕竟咱们制定的绩效目标还是要正向循环的。

通常情况下，对于有多层管理架构的公司或组织，会先根据战略计划以及过往绩效循环的情况来制定年度目标，然后跟下一级的团队或部门进行共享，这些团队或部门的管理者需要根据公司年度目标来制定他们专业领域的绩效目标，一般来说，技术管理者需要根据公司年度目标来制定技术或工程团队的绩效目标，主要考虑技术或工程团队如何帮助实现公司的年度目标。

再往下一层是员工个人进行绩效目标的制定，这时候首先需要考虑员工个人目标与团队目标、公司目标的方向一致性。另外，根据特定员工的绩效趋势，跟员工制定绩效目标时，除了要考虑团队目标与员工个人的发展需要外，还需要考虑员工在技能和知识领域的提升需要。

在跟员工制定绩效目标时，需要考虑员工的特质和意愿，例如在最近的绩效循环中表现优异的员工，可以给予更多的机会。这些机会可以是纵向的，例如增加相同类型的工作或相关工作；也可以是横向的，例如更高级别的职权等。对于这样的员工，我们在制定绩效目标时，需要基于这些成长机会来设定新基准绩效标准。

这里需要注意的是，有些人面对成长机会非常高兴，甚至会主动告诉你他们希望在新的绩效循环里达到什么位置。但是也有些员工是很内向的，不会跟你主动分享自己的意愿，因此你作为技术管理者就需要跟他们有私密的交流沟通，在沟通中了解他们的意愿和期望，并将其记录下来。做好记录的目的是帮助自己之后能全面深入的思考。

最后，制定绩效目标时也要考虑团队的需要，有时候团队中需要有一定的牺牲和取舍，团队中会出现一些工作内容是员工不愿意负责的，这时候就需要有员工做出一定的牺牲来承担。对于这样的员工，你需要对其保持肯定的态度，另外不要让这些做出牺牲的员工偏离他们的意愿太长时间，否则就很有可能会失去他们。

综上所述，制定正确的绩效目标需要你在公司需求、团队需求以及员工需求之间进行有效的平衡和满足，但不期望这些需求全部都能满足，找到需求之间的平衡点才能帮助你制定更有效的绩效目标。

绩效目标的本质是合作

在过往几十年的企业管理中，以非常简单粗暴的自上而下的方式制定绩效目标是很常见的，处于组织架构上层的人给下层的人直接制定目标。这种方式的好处在于权力清晰和执行高效，但随着时间推移，在大多数公司或组织中，特别是互联网类公司中，这种方式已经不再适用，转变为通过合作协作的方式来创建绩效目标，因此我们说绩效目标的本质是合作。

这种转变的产生由几个因素共同推动，首先，脑力劳动的兴起需要公司对普通员工有更多的尊重。其次，为了更大程度的释放团队生产力，如今的组织架构会更多的趋向于扁平化或最小组织化等，而这样会造成领导结构的平等意识，虽然还是有位置差异，但人们会意识到自己或其他成员决定了团队的绩效表现。

最后一个因素是，合作协作模式释放了团队的综合心智，不仅仅是简单的听写效率，在合作模式下，员工或管理者与他们上级间的关系，不再仅仅是接受指示的关系，而是需要他们更多主动地思考来达成更高的目标。这种双向对话的合作模式不仅有助于满足公司需求，也能更好的满足员工的需求。因此，作为技术管理者，我们需要有这样的合作心态来进行绩效目标的制定。

需要注意的是，我们在跟团队或员工制定绩效目标时，需要考虑短期生产力与长期承诺之间的平衡，有时我们会忽略对长期目标的思考，迷失在短期目标之中。一般我们会使用 S.M.A.R.T 原则来帮助团队和员工建立短期目标并实现它，这里我们先简单介绍下：

Specific- 目标必须是具体的；
Measurable- 目标必须是可以衡量的；
Attainable- 目标必须是可以达到的；
Relevant- 目标必须和其他目标具有相关性；
Time-based- 目标必须具有明确的截止期限。

S.M.A.R.T 原则十分重要，因为它可以帮助我们保持团队或员工的短期生产力，但这里需要提醒的是，长期发展承诺是需要我们在 S.M.A.R.T 原则之外来考虑的，比如，长期来看你希望团队如何发展，长期来看员工希望在团队、公司有什么样的发展等？

在我们明确了长期目标之后，可以尝试在绩效目标中的一小部分加上长期发展相关的工作内容，当然这也是在跟团队和员工沟通的前提下进行的，我们需要以合作协作的心态来进行绩效目标的制定。

绩效目标制定的贴士

最后，再分享一些绩效目标制定时的小贴士，大家可以记录下来方便日后查阅：

考虑员工的能力；
考虑员工的意愿；
给予绩效好的员工更多纵向、横向的机会；
留意员工的绩效趋势；
非正式的记录员工表现；
考虑团队的需求。

总结

本文介绍了如何进行正确的绩效目标制定，需要考虑的需求有哪些，并在最后提供了一些绩效目标制定的小贴士，期望能够帮助大家更好的掌握绩效目标制定的技巧。

思考题

在最近一次的绩效目标制定中，你采用了怎样的方法和模式呢？不妨在评论区留言分享给大家~

感谢你的收听，我们下期再见！

作者简介

刘俊强（微信公众号：程序员精进），TGO 鲲鹏会会员，现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+ 年以上互联网开发经验，8 年以上技术管理经验。

第117讲 | 程军：技术人的「知行合一」（三）

你好，我是贝壳技术总监程军。每次抽烟到烟头快熄灭的时候，心里总会抱怨怎么这么快，然而过不了多久，又会点起新的一支烟。众所周知，这个世界是复杂且多变的，我们唯一能做的，就是在大部分时候都保持乐观、积极的态度面对生活赋予我们的一切。

曾国潘曾说过，“担当大事，全在‘明’‘强’二字”，上一篇文章中，我主要分享了我对“明”的理解，今天，我想聊聊我对其中“强”的感悟。

一、天行健，君子以自强不息

“强”就是指刚强、倔强、自强和坚持，所强调的是意志力、毅力、定力和决心的力量。

他曾说过：“势利之天下，强凌弱之天下，此岂自今日始哉？盖从古已然矣。从古帝王将相，无人不由自强自立做出。”

意思是说，从古到今的帝王将相，没有一个不是由自强中走出来的，更何况我们这样的凡夫俗子。

这里想分享一个我的例子：

今年 5 月底，我加入现在的公司，成为本部门的 1 号员工。入职第 2 天，领导就把需求方、HR 负责人等从北京带来了，我们开了大概 2 个小时的新产品讨论会，依稀记得老大的套路就是：
1. 强调这个产品线公司高层很重视，并当场把产品相关的行业分析、竞对分析以及怎么构建新的壁垒说了一遍，还介绍了第一期产品需要做什么内容；
2. 提出期望这个产品能在 1 个月内上线；
3. 表明协助招人的 HR 也在现场，可以给予最大的支持。

接着问题来了，他问我你现在怎么打算？

当时我几乎是窒息的，心里不停盘算目前团队除了我，什么人都没有，但产品上线日期却已经被确定，该怎么办。内心思考再三之后，我选择回答 OK。对于我的回答，感觉当时在坐的各位都很开心，只有我还一直不能释怀，以至于会议结束之后，领导请我吃了上海最有名的红烧肉，我也感觉没滋没味的。

后面的故事按大家想的那样，产品如期上线，数据表现还不错，上线一个月后已经达到每日 3000 单的交易量。

以下是我当时的解决方案，供大家参考：

和产品同学一起商量这一期 MVP 版本的产品功能，先定义目标和细化目标；

深入了解产品需求，整理出业务架构、表结构模型并搭起系统架构，同时识别出其中需要外部依赖的部分，提前沟通让对方排期；

和兄弟部门的老大不要脸的借来 1 位开发，由于我入职之前兄弟部门已经发出了一个 offer，所以这位同学在我入职后第二周就入职了；

前端和测试的两位同学分别在 2 周后入职（别问我怎么做到的，加入一个新团队前也应该提前做一些准备，毕竟兵马未动粮草先行）；

自己也参与代码编写，跟兄弟们一起战斗，（当时还发朋友圈笑说我是一个已经 4 年没有写代码的人）如亮剑电视剧中李云龙所说的那样，战号一旦吹响，炊事班也得拿着菜刀和大锅冲上去。

后来才知道领导用了一个“以终为始”的方法，就是先确定目标，剩下是你要去考虑的，这也许就是网上鸡汤中所说的，领导要做正确的事，而作为下属的我们要把事正确的完成吧。

话说回来，我当时心里也是比较犯嘀咕的，要是刚入职第一个产品就不能按时交付，这后面可如何是好。好在我一直以来是一个不服输的人，性格倔强、行动果断，很多时候还非常有毅力和坚持。当然，在我的理解里，这些都不是最重要的，最重要的是决心，那是一种超乎寻常力量的东西。如今，我做事更多是价值驱动，如果我认可这件事对公司的价值、对公司的重要性，那么我要做的就是坚持去执行直到拿到结果。

用一句清华的校训收尾本段，自强不息，厚德载物，共勉之。

二、打落牙齿和血吞

曾国潘在回顾自己一生时曾说过，我平生有四大堑，第一堑是“学台悬牌，责其文理之浅”，也就是在秀才考试时被主考官公开批评文章文理太浅。第二堑是“画一图甚陋，九卿中无人不冷笑而薄之”，也就是在向皇帝上疏时，画了一幅图辅助说明，但因为曾国藩本身并不擅长画画，这张图比较难看，遭到了满朝大臣的鄙夷嘲笑。

第三堑是“岳州、靖港败后栖于高峰寺，为通省官绅所鄙夷”，也就是在岳州兵败太平军后遭到江西全省官绅的鄙夷和耻笑。第四堑是“九江败后赧颜走入江西，又参抚臬。丙辰被困南昌，官绅人人目笑存之”，也就是在九江兵败后逃到江西，又因为被刁难而弹劾了江西的巡抚、按察使，结果第二年曾国藩被围困南昌时，江西的官绅人人都幸灾乐祸。

而面对这些难关，曾国藩最大的不同就是从不怨天尤人，遇到苦难总是反求诸己，不断总结经验教训，以此完善自己。这就是关键所在，每个人的人生都会经历一些“生死攸关”的大事，一旦坚持了、迈过了，就是最好的成长。

这里再分享一个我的例子：

当时我还在 1 号店负责公司 TMS 系统，也就是物流运输管理系统的研发，我们系统的上游是 WMS 系统，也就是仓库管理系统，这两个系统是电商供应链系统的关键所在。在具体执行中，仓库打好包裹后，数据交接给 WMS 系统运营人员的同时也要传到我们 TMS 系统上。

当时的故障是，订单数据（WMS 调用 WMS 订单接收接口）过来得特别慢，基本上是每秒 1-2 个订单，一看就出了问题。问题出现后，我一个外号叫“包子”的同事（技术高手，目前是阿里高 P）已经在公司排查了大半天，我想着反正闲着也是闲着，就跟领导说去公司一起帮忙排查问题。

包子是我们部门的技术好手，人也有点傲，见我来了，告诉我他已经各种日志分析、数据库慢 SQL 分析都做了，线上也加了调试代码，就差直接 debug 线上代码了，言下之意就是你还有什么更好的办法。

中间不知道抽了多少支烟，故障发生在周六上午 10 点，眼看时间已经到第二天凌晨 2 点左右了，如果到早上还没有修复就可能会影响我们的订单配送情况。情况很紧张，最后没办法了，只能选择再在可能出现问题的地方加入调试代码，主要是加了一些耗时监控代码（包子加的调用方的代码，我加的是我本地实现逻辑的部分），然后立马紧急上线。

最终问题定位在一个核心配送单分配逻辑上，其中有基于内存的分词索引解析和一个用了 Oracle10 函数的复杂 SQL 查询，继续加入调试代码后发现是因为这个 SQL 的运行时间很慢，运行一次大概要 600ms 左右。

但这处代码正好是我写的，并且一直运行良好，只好打电话问 DBA 为什么 SQL 这么慢，他排查一会说组合索引失效了。问题最终被定位了，然后 DBA 稍作处理后，系统就恢复正常了，真的是一行业务代码也没有改。为什么我用了同样的办法却可以找到问题的本质原因？这里其实也蛮值得思考的。

后来我们复盘的时候才知道，Oracle 有一个收集每个表数据的定时任务停了，执行计划从走联合索引变成了全表扫描，悲剧就这样发生了。这个时候已经是周日早上 7 点了，整整 13 个小时，再加上我同事之前花的时间，这个 bug 用了大概 24 个小时才解决。我们会去追问为什么 DBA 没有异常告警，这个锅其实也可以甩给他们，但是想了一下有意义么，我们才是系统的 owner。

可能有的读者会说，你又不是当时发生故障系统的 owner，一开始问题也没定位你的代码上，你操什么心啊。但我觉得我责无旁贷，因为我是部门的一份子，系统有我的参与，我希望它能解决故障顺畅运行，更关键的是，我们为什么要给自己的思维设限呢？不久之后老大还私下问我需要什么奖励，我拒绝了，因为我觉得奖励不是关键，关键是我从中学习到什么，领悟到什么。

在这之后不久，因为我的技术不错，有自己的思考和判断力，更有很强的好奇心，并且做事也负责，就转岗到了公司的核心部门任架构师。不过我依然非常感谢当时领导对我的培养和照顾，至今都不曾忘记，他是我职业生涯中，对我影响非常深的人之一。目前他在京东直接汇报给刘强东。

三、永不放弃

卓越的领导者一定要有一颗无比强大的内心。丘吉尔的最后一次演讲是在剑桥大学的毕业典礼上，整个演讲过程中他只说了一句话，那就是：“永不放弃、绝不、绝不、绝不。”稻盛和夫也曾经说过：“成功和失败的不同点就是坚忍与毅力。”任正非也说过：“经历九死一生还能好好活着，这才是真正的成功。”

既然这么多领袖都如此以身作则，身为平凡的我们还有什么可说的呢？一个字，就是“干”。

总结

本人从“天行健，君子以自强不息”开始，聊了我们经历困难时需要“打落牙齿和血吞”，但关键还是要有坚强的决心和意志力，也就是“永不放弃、绝不、绝不、绝不”。

在我看来，每个人的一生都是苦行僧，不论你承认或不承认，相信或不相信。而作为技术人，不论我们是在做技术管理亦或是架构师亦或是产品负责人亦或是 CTO，我们的前路上都有非常多的拦路虎，并且一只比一只猛、快、狠。而面对这复杂多变的世界和诸多凶猛的拦路虎，我们唯有“男儿”当自强，迎面而上不退缩。

因为紧急家事，写于 G265 北京回黄山老家的高铁上，一路忐忑但永不放弃。

作者简介

程军，现任贝壳技术总监，曾任饿了么技术总监、1 号店架构师，10 年以上互联网开发经验，8 年以上技术管理经验。

第118讲 | 吴铭：成本评估是技术leader的关键素质

在互联网公司中，技术与业务的关系一直是焦点，我们对于技术与业务之间的矛盾也早已司空见惯，相信大家在工作中都看到过类似的场景：
业务问，“对手产品的某功能我们什么时候能上线？”
技术回答，“目前不行，这个版本我们需要做重构。”
业务问，“性能慢一点没关系，明天能不能发版？”
技术回答，“不行，我们要多花两三天时间将性能提高百分之百。”
业务抱怨，“我和别的公司谈妥了合作营销，技术却总是不给力。”
技术也抱怨道，“你们一个月提一百个需求，没几个有用的。”

诸如此类场景屡见不鲜，无论公司处在何种规模，只是争议的内容有所不同罢了。归根到底，业务体系与技术体系的矛盾主要集中这四方面：
1. 对于资源的抢占；
2. 对于成本的评估；
3. 对外部目标的差异；
4. 内部目标设定的合理度；

协调技术与业务的矛盾

资源抢占是表象，也是其他方面问题的体现，技术 leader 最需要关注的是对成本的评估，也需要时刻对此保持清醒的头脑。因为技术人天生对技术有追求，我们很难要求每个一线的技术人员都去了解业务背景、业务收益等情况。同理，我们也很难要求产品、市场、运营等人员去考虑技术方面成本与收益。

因此，当公司达到一定规模后，一名优秀的技术 leader 就必须在技术与业务的平衡和成本评估等方面花费更多的心思

我举两个例子，第一个例子是，曾经我们的技术人员提出一个需求，想用三天时间提升产品性能，使产品主页面的加载耗时缩减一半，同时机器成本也一半降低，这听起来确实不错。但同时，业务人员也提出了一个需求，想在做一个为期两天的红包活动，以此吸引大批用户与流量。

作为管理者，面对技术与业务同期而目标不同的需求，你将如何抉择，又如何做成本评估、价值评估呢？

第二个例子是，我们的技术团队想用机器学习算法重构产品中的酒店业务的排序模型，做到个性化推荐。模拟测试后，新模型的确要比原来的方式效果好一点。但业务团队不支持这个想法，在他们看来，酒店类业务并不是高频使用的场景，而且具有极强的地域性，之前的当地业务人员人工排序的方法效果不错，贸然改用技术排序，结果不一定好。

事实也确实如此，在这种样本量非常小的情况下，技术人员改进之后，短期内效果确有所提升，但是当一些特殊情况发生时，比如节假日、公务员考试等，业务情况就会产生很大的波动，而新的算法模型在早期没办法准确的覆盖这些因素，反而对业务造成了非常不利的影响。

但我们不能以此判别技术团队的改进方案是错误的，只是一线技术人员无法全面考虑到市场中的所有情况，因此，最理想的办法就是技术团队提出产品改进方案后，与业务团队一起进行可执行度评估、价值评估与成本核算。

我想强调一点，作为技术 leader，我们做决策时要多以成本与收益为考量点，而不仅是基于个人的技术理想主义。我们常说“技术驱动世界，技术改变世界”，我当然认可技术的力量，但有时必须承认，公司依赖业务运转。可能在某阶段，公司更多的偏向技术驱动，但到了其他阶段，可能就是以产品驱动或运营驱动为主，但归根到底，公司必然是以业务为最终驱动的。所以，我们一定要清楚在当前的阶段和业务场景下，公司对技术有何要求与期望，避免过度技术驱动。

不同公司所处的阶段不同，对技术的定位不同，技术与业务之间的关系也就不同。有些公司对技术的定位是“救火”，解决紧急问题；有些公司对技术的定位是“搬运”，将线下产品或服务等搬运至线上；还有一些公司对技术的定位是“提升效率”；也有一些站在科技顶端的公司，对技术的定位是创新与突破。

所以，技术 leader 在协调技术与业务的关系时也需要考虑到公司当前所处的阶段 ，以及公司对技术定位，总结一下，可以归纳为以下四点：
1. 清晰服务于公司短期目标，明确技术定位，明确技术驱动与技术创新在当前阶段的价值。
2. 合理调配技术资源分配，包括协调沟通与资源评估。
3. 组织领导成本及收益评估，需要掌握业务知识与成本核算。
4. 预留中长期目标规划空间，做好技术规划与技术储备。

技术实施与规划

回到技术上，技术的实施与规划是技术 leader 工作的核心。先来看技术实施，技术实施的过程有三个关键点，即资源配比、技术选型和业务分析，更有两个绕不开的话题，即旧系统改造与新技术引入。

1. 旧系统改造

每个公司基本上都会遇到旧系统改造问题，包括何时改造、重构还是改进、投入多长时间、投入多少资源以及价值评估等方方面面的问题。我用一句话总结这些问题：非必要的重构是没有业务价值的。

举个例子，我们之前有个由多个运营人员组成的离线分析团队，他们每天下午 5 点会看离线分析报表。由于这个报表需要几个小时才能生成，技术人员就投入两天时间去做改进，将几小时改进为耗时几分钟。

从技术层面讲，这件事非常值得鼓励与赞赏，但对于业务方面没有任何影响，运营人员仍然在每天下午 5 点看报表。如果当时技术团队没有其他高优先级的事情，那么做这件事是很有意义的，但假设当时同时还有个市场活动要做推广，那么技术资源就不该倾斜到这件事情上，因为技术资源永远是不够的，我们做技术改进时一定要结合业务进行成本核算、价值评估。

2. 新技术引入

技术人员总有创新冲动，看到新的热点技术就想着能不能引进。对于新技术引入，我总结出以下 5 个思考点：一，引入的技术是否成熟；二，是否已做好相应储备；三，是否能承担相应人员培养成本；四，能够承担多大的风险；五；是否已经做好引入后的价值评估。

总而言之，对于新技术的引入，即使能够将性能提升一千倍，但这种性能提升对业务没有太大帮助，也就没有必要引进了。

我们要鼓励技术人员做微创新，但不论是微创新还是大改进，我们作为技术 leader 一定要考虑到成本评估与控制的问题

再来看技术规划，对技术 leader 来讲，技术规划时主要有三个思考点，即技术路线规划、技术栈储备与风险评估。

首先，我们一定要多去关注中长期的技术发展与趋势，但也不要太过超前。除了对那些技术依赖性强的公司，技术有引领、指导作用外，对于大部分的中型、中小型，或初创公司来讲，太超前的规划技术路线，做技术储备没有太大意义。

如今，新技术在很短的时间内就能被普及，我们所储备的新技术很有可能很快就会成为平民化、大众化的技术，大家都可以享受到这种技术福利，比如之前的自动化测试、自动化运维等，很快就变成了大部分公司的标配。另外，太超前的技术出本对成本也是一种消耗。

因此，技术储备的前提是对长期目标和长期收益的判断，只有当既定目标非常明确时，才好去做长期的技术储备，否则，就很有可能发现储备的技术对业务场景并没有太大的价值，变成一种资源的浪费。

第119讲 | 汤力嘉：CTO如何进行产品决策（一）

你好，我是一下科技 CTO 汤力嘉，我经常开玩笑说，要做技术里最懂产品，产品里最懂技术的，今天就想跟大家分享一些我在产品决策上的理念和心得。

决策方法论

做一款产品前，首先需要做产品决策，那如何做好产品决策呢？引用乔布斯的一段话，“一个问题看上去很简单，是因为你并没有理解其复杂性；当你把问题搞清楚之后，又会发现其实很复杂，然后拿出了一套复杂的方案来，实际上你只实现了一半，大多数人也都会到此为止；但真正伟大的人会继续前进，找到问题的关键和内在的深层次原因，再拿出优雅的、堪称完美的解决方案”。

正如乔布斯喜欢的另一位伟人达·芬奇曾说过的一句话：“简单，是终极的复杂。”

对于这句话所表达的观点，我非常认同。产品决策最重要的是简单，但简单不意味最少化，简单是具有个性的朴素设计。

举一个耳熟能详的例子，某肥皂生产厂，在肥皂出厂时，会为肥皂装上塑料泡沫盒。但在生产线上，难免出现泡沫盒装空的情况。于是厂商请来高科技团队，入驻肥皂厂，研究如何分拣这些空盒。高科技团队耗费大半年时间，开发出一套高精度摄影设备，可以检测空盒位置，再用灵活的机器手把它们捡出来。同样的问题，另外一位民间科学家，买了一台大功率风扇放在生产线旁边，然后将风力开到最大，把空盒吹走，成功解决了问题。

从这个案例中可以看到，有时最简单的设计，往往效率最高，它不仅能够解决眼下的问题，还相对便宜，不会引起争议，更容易被接受，而复杂是不可持续的。

如何检验简单

检验简单的方法有两点，第一，能用一句话表述功能；第二，思考你的用户希望有什么样的体验。

你可能会问，我们有几十几百万的用户，每个用户的需求都不一样，我们到底该为谁设计产品功能呢？

我们可以先将用户进行分类，一般可以分为三类：

1. 专家型用户，这类用户愿意使用你的产品，并且愿意花费时间探索和研究产品，并不断提出意见，然后会希望产品按照他们的思路改进设计。这类用户的数量最少。
2. 随意型用户，这类用户对一些新功能比较感兴趣，但是，新功能必须足够简单，最好是在原有功能基础上扩展、衍生的。
3. 主流用户，这类用户一点都不想学习新功能，他们使用产品的目的只是为了解决某些固有的问题。他们掌握一些重要功能的使用方法，但永远不会想要去学会所有的功能。大多数人属于这一类用户。

如何理解这三类用户呢？以手机为例：

首先，专家型用户就是会用到手机文件管理器的用户，他会查看这款手机都有什么功能并一一摸索使用；其次，随意型用户，可能会尝试手机中的美颜拍照功能，但前提是必须保证手机其他最基本的功能，比如通讯录导入。最后，对于主流用户而言，只要手机能够保证基本功能的使用就可以了，比如打电话、上网等。

悲哀的是，多数公司都在为专家型用户服务，并在听取专家型用户的意见方面花费了太多时间，因为专家型用户喜欢提意见，反馈问题。但是，这些专家型用户反映的问题究竟是不是产品应该解决的？这是我们在产品决策中应该思考的问题。

我的建议是，如果你想设计一款简单的产品，请记住，一定要为主流用户设计，解决主流用户的问题。以 Excel 为例，专家型用户可能会试试分类汇总、邮件合并等相对高级的功能，但 99% 的用户只希望能解决金额求和这个简单问题，那我们在产品设计的时候只需要满足这个需求就可以了。

简单四策略

确定针对主流用户做简单设计的产品策略后，具体该怎么做呢？我们可以从删除、组织、隐藏和转移这四个方面落地执行。

删除

1. 保留核心功能
删除是最简单的方式，任何你觉得没有必要的功能都可以删除，将开发精力投入到最核心的功能优化中。

我们常常会走入这样的误区，不想浪费已经做完的功能，干脆将它一起上线。这在经济学中被称为沉默成本，功能做出来后，你的成本已经没办法收回了，但如果选择将功能保留，它会产生更多额外成本，比如维护成本，以及可能对用户造成使用障碍等。所以，当我们考虑是否保留某个功能时，要考虑的不是为什么要删除它，而是为什么要留下它。

另外，以防我们想象不够全面，可能会漏掉一些用户的核心需求，所以对于每一个功能，都要谨慎推敲，只把核心的功能保留下来。

2. 功能过多会对用户造成负担
举个例子，我们之前曾做过一款播放软件 Replay，这款软件迭代了两个版本，一个版本有 21 项功能，另一个版本只有 7 项功能。做用户调查时发现，用户在没有使用软件前，有 2/3 的人更倾向于选择功能多的版本，但在使用软件之后，多数用户就变成了实用主义，2/3 的用户更喜欢 7 个功能这一版。

3. 功能过多会对用户造成干扰
Safari 中有一个功能是阅读器视图，它会把网页上的广告、链接、图片都过滤掉，只保留一个干净的文字阅读界面。就是因为它在用户调查后发现，页面中的任何链接、图片，即使用户不点击它们，也会对用户造成干扰。

曾经我们做了一个关于节假日的调查问卷，内容是你认为哪个节假日比较好、你在节假日里会做什么等。当时考虑到用户可能会担心数据被收集之后的用处，就在提交按钮旁增加了“查看详情”链接。我们以为只有部分有疑问的用户才会去点击详情链接，结果所有人都点击了查看详情，却无人提交问卷，这就是一个非常失败的案例。

4. 选择有限，用户反而更喜欢
曾经有个这样的实验，一个街边的果酱铺给客户提供了二十多种果酱口味，但只有 2% 的人愿意购买。大家就觉得奇怪，为什么我们有这么多口味的果酱，却没有人购买呢？

接着，经过尝试后，果酱铺试着只留下六种口味，结果购买率很快提升到了 12%，让人震惊，而且在这 12% 的购买率背后，顾客的愉悦度也大大提升。所以，有时给用户提供有限的选择，用户反而更开心。

组织

除了删除之外，还有组织的策略。在组织策略中，需要提到记忆力的 7 加减 2 原则。通常，一个人的短时记忆容量为 7 个事物，记忆力好的可以达到 9 个，记忆力差的可以记忆 5 个，所以，我们在构想产品时，要确保一个页面只能保留 7 个事物。

如果页面中无法只容纳 7 个事物怎么办？我们可以利用感知分层技术，如图所示，这是某著名电商网站的一个产品页面，从中可见，凡是和钱有关的事项，都标了红色，比如价格、优惠、以旧换新、加入购物车等。这就是组织中的感知分层技术，把相关事物用同样的颜色标记起来。

那如何证明这个组织规划比较理想呢？最简单的方法是，我们可以把眼睛眯起来再看网页，如果发现网页中的几个分块都比较清楚，就代表规划是比较成功的。

隐藏

如果删除和组织还没法解决全部问题，那么可以采用第三个策略隐藏。我们可以把一些不常用，但又必不可少的功能隐藏起来，比如一些选项、偏好等。

我们也可以选择阶段展示，以循序渐进的方法显示功能，比如 Mac 中的文件保存对话框。还有一种做法是适时出现，比如百度搜索框，用户输入关键字后，它就会将关键字相关的信息展现出来。

你可能会担心用户发现不了隐藏功能？我们只需在关键路径中给出提示与线索就可以，但注意提示要小，保证用户在前进的过程中能够遇到提示，但又不会挡住他们的去路。

我将删除、组织、隐藏这三个策略称为渐进三部曲，首先删除不必要的，其次，组织必须提供的，然后隐藏非核心的。如果这三个策略都不行，还有第四个策略，即转移。

转移

转移也有两种方法，第一，设备间转移，比如电商网站的产品，通常会在手机端页面展示较少内容，而在 PC 端页面展现更多内容。

第二，创造开放式体验，让某些功能具有多种用途，比如大众汽车后备厢上的 Logo 就具备多种用途，它既是打开后备厢的拉环，又是隐藏倒车雷达摄像头的地方。

总结

本期内容中，我主要分享了我在产品决策上的理念和心得，其中的关键点是简单，并分享了简单策略在产品决策中的具体运用，包括删除、组织、隐藏、转移这四个要点，希望对你有用。如果你有不同的见解，欢迎在留言区分享。

感谢你的收听，我们下期再见。

作者简介

汤力嘉，一下科技 CTO，负责旗下秒拍、小咖秀、一直播等产品的研发及团队管理工作。历任酷 6、暴风技术总监，在直播、p2p、视频特效等领域拥具有丰富的行业经验。

第120讲 | 刘俊强：必知绩效管理知识之绩效数据收集（上）

你好，我是腾讯云资深架构师、TGO 鲲鹏会会员刘俊强，有着 8 年以上的技术管理经验，今天想跟你分享技术管理者必知的绩效管理知识之绩效数据收集。绩效数据收集是科学绩效考核的前提，那么在实际的执行中，我们需要收集哪些数据，这些数据的来源分别是怎样的呢？

绩效评定不是一次性事件

我在之前同系列的《绩效管理循环》一文中分享过，绩效管理是一个周期内持续循环的过程，包括绩效目标制定、绩效辅导，以及绩效评定与反馈三个阶段。

不少管理者往往会忽视整个循环周期，直接在绩效评定与反馈阶段开始绩效管理工作，并将绩效评定看作是一次性事件，除非是在正式的评定考核阶段，否则他们不会进行绩效评定相关的工作。这是极为错误的做法，也是导致管理者认为绩效评定非常困难的主要原因。

在实际执行中，绩效管理循环中的第二个阶段绩效辅导，是时间最长并且非常重要的阶段。

成功的管理者应该主动地在这个阶段找到自己的方式来检视团队成员的表现。这样，在进行绩效评定、绩效考核阶段时，会减少管理者因认知偏见对绩效结果产生的影响。

有些客观事实是管理者必须了解的：

第一个事实是管理者的记忆力会变差，通常而言人类的记忆并不可靠，我们越忙越成功，大脑接收的数据就越多。随着时间的推移，回忆事情会变得很困难，特别是绩效评定通常需要以月为单位来看团队成员的绩效表现，因此，如果在绩效评定考核阶段仅通过回忆来进行评定，会造成极大的偏差。

第二个事实是系列位置效应，系列位置效应（Serial-position Effect）是一种心理学现象，指人们倾向于对首先见到的事物和最后见到的事物有更好的印象，分为首因效应（Primacy Effect）和近因效应（Recency Effect）。

首因效应也被称为第一印象作用，或先入为主效应，是指在行为过程中，最先接触的事物会给人们留下深刻的感知或认知，进而影响人们对事物的感知和判断。近因效应指在行为过程中，对事物的最近一次接触会给人留下深刻的感知或认知，能对首因效应所形成的心理认知起到巩固、维持、否定、修改或调整等作用。两种效应在记忆过程中的影响如下图所示：

怎么来理解系列位置效应呢？试想你去听一个分享，在分享开始阶段提供的信息会比后来提供的信息更容易被记住，这就是首因效应；另外，分享临近结束时的信息也更容易被记住，这就是近因效应。在绩效评估方面也会有类似的问题，团队成员给你留下的第一印象和他最近的表现更容易让你记忆，因此会产生绩效评定的偏差。

第三个事实是晕轮效应（Halo Effect），是指人们对他人的认知首先依据初步印象，然后再从这个印象推论出认知对象的其他特质。例如你喜欢或不喜欢某位员工，可能对你如何评估该员工的工作表现产生强烈影响。你越喜欢或越不喜欢某位员工，就越难以清楚地看到现实。简而言之，就是以偏概全。

以上介绍了三种认知陷阱，分别是不可靠的记忆力、首因效应和近因效应，以及晕轮效应。介绍这几种认知陷阱是为了让管理者了解它们，不让它们给绩效评定带来不必要的麻烦。

管理者避免以上认知陷阱的最佳实践是，使用“绩效表现记录本”来记录自己对团队和团队成员绩效表现的持续观察，可以是物理上的笔记本，也可以是数字化文件，或者两者皆有也是可以的。

在记录中需要清晰地记录日期、员工姓名和表现情况，每周至少 1-2 次。当然，每次记录也不用太复杂，例如，8 月 9 日，张三提前完成了某项功能的编码实现工作，使得测试同学可以提前介入进行集成测试，一条记录可能仅需要花费管理者 10 秒左右的时间。

作为管理者，我们应该花时间做好“绩效表现记录本”的使用，记录团队和团队成员的当前表现，并观察总结其表现趋势。

这样，一方面在阶段二绩效辅导阶段，管理者能够有效地帮助团队成员进行提升，另一方面，通过多次的数据记录，管理者的评估就可以尽可能地贴近事实真相，可以保证在阶段三绩效评定考核时，不会给管理者和员工带来过大的压力，因为“绩效表现记录本”已经能够尽量客观的反映事实情况了。

员工绩效评估的数据来源

任何绩效评定考核过程的基础，都是收集和评估有关员工的绩效数据。不论使用何种方法或工具来收集数据，都需要确保它们具备有效性、可靠性和相关性这三个特性。

有效性意味着评估该评估的事项，可靠性意味着标准是持续一致的，相关性则意味着必须跟工作表现相关。在我们开始做绩效数据收集前，有这方面的专家来协助是最好不过了，通常这样的专家来自于公司人力资源部门中负责绩效的团队。

在实际执行中，我们对员工进行绩效评定考核时，通常会从三个主要方面进行评估，分别是特质、行为和结果。首先是特质，这里的特质是指一个人的性格或态度，那么问题是，我们是否可以衡量一个人的人格特质，并认为它们是有效且可靠的工作绩效指标呢？答案是，很难。但是在实践中，特质还是会被用来评估，例如，是否表现出热情、有责任心等。

接下来我们来看行为，是指人们说和做的事情，它们是可观察的，因此和特质相比，行为往往更可靠，基于行为做绩效评估会比基于特质进行评估更为公正和公平。最后，我们聊下结果，是指员工已达到或未能达到的结果，例如，销售数据、项目完成情况等。与行为类似，结果通常被认为是可靠且有效的，而且员工往往也认同以结果为衡量标准是公平的。

那么问题来了，管理者到底应该怎么独立评估这几个方面呢？其实都有据可依，在实践中，特征和行为的度量评估一般与胜任力模型相关，而结果的度量评估则与目标制定过程和后续工作内容相关。

此外，在明确了这三个方面的独立评估方式后，管理者要去哪里收集这些数据呢？这些数据的主要来源是公司记录如考勤数据，员工提供的自评以及作为管理者你的评定记录等，当然有些公司还会用上 360 度评估和客户评价，以上这些数据来源都可用于对特质、行为和结果三个方面的数据收集。

在实际的数据收集和分析中，管理者一般会用到李克特量表、行为锚定量表以及行为观察量表这三种常见的工具和方法。这些方法各有利弊，受限于篇幅，我将在下篇文章中具体分享这三种工具和方法的利弊、使用方法和实践案例，欢迎持续关注。

这里要说明的是，管理者需要根据自己公司业务和团队的实际情况来选择合适的数据收集和分析工具，并依此设计一套相匹配的绩效评估系统，这样的系统才能正确地衡量绩效并激励团队成员。

最后给你留一个小问题，目前你在团队管理中使用的绩效评估系统是怎样的，数据来源又跟哪些方面相关呢？欢迎在留言区分享。

感谢你的收听，我们下期再见！

作者简介

刘俊强（微信公众号：程序员精进），TGO 鲲鹏会会员，现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+ 年以上互联网开发经验，8 年以上技术管理经验。

第121讲 | 刘俊强：必知绩效管理知识之绩效数据收集（下）

你好，我是腾讯云资深架构师、TGO 鲲鹏会会员刘俊强，有着 8 年以上的技术管理经验，今天想跟你分享的依旧是技术管理者必知的绩效管理知识中绩效数据收集相关的内容。

在上一篇文章中，我们谈到任何绩效评定考核的基础，都是收集和评估有关员工的绩效数据，而在实际执行中，我们通常会从三个主要方面对员工进行评估，分别是特质、行为和结果。另外还聊了绩效数据的来源，如公司记录、员工自评、管理者评价等，在本文中，我们将聊聊数据收集常见的工具和方法，以及这些工具之间的优劣比较。

数据收集工具和方法

不得不承认的是，在数据收集中没有完美的工具或方法，目前有几种工具或方法被大家普遍采用，我们接下来会简单介绍。

首先介绍的是评定量表，评定量表在绩效评估系统中占主导地位。评定量表会为评估者提供维度列表，每个维度代表员工有效的评估方面，例如特质、行为或结果等，每个维度都有对应的评分，通常是五分制或七分制。评定为正面的时候，可以是“表现优异”、“超出预期”等，评定为负面的时候，可以是“不合格”、“待改进”等，而评定为中性的时候，可以是“符合预期”。通常这类方法被称为李克特量表（Likert Scaling），以下是一个李克特量表示例：

一个常见的李克特量表版绩效考核表会包括工作数量、工作质量、团队合作以及态度等评估维度。李克特量表易于使用且开发成本很低，因此被大量采用，但是李克特量表也存在明显的问题，这些问题也存在于其他类型的评定量表之中。

首先，评定量表没有提供可以操作的反馈，例如，在衡量积极是否态度的条目上，五分制中的三分只是告诉该员工的表现符合预期，但没有告诉他们该做哪些改进。这里的评分仅仅是一般性的反馈，如果能提供具体的改进反馈会对员工更有帮助。再者，李克特量表和其它评定量表都存在着准确性问题，这源于评估者可以轻松地以不同的方式来解释评分，例如，中间值对不同人的意义就是不一样的。

为了克服这些问题，人们后来开发出来了行为锚定量表，简称为 BARS（Behaviorally Anchored Rating Scales）。使用 BARS 时评估者仍然会对员工进行多个维度的评分，但不同之处在于 BARS 会呈现不同级别表现的特定工作行为，而不是简单的使用量表的数字和形容词。以下是一个使用 BARS 的示例表：

这个例子是对员工沟通能力的考核，并将考核拆分成了三个维度，分别是：
展示有效的书面和口头沟通技巧；
沟通清晰，知识渊博；
与他人共享信息。
每个维度又被划分出 5 个不同的评价等级，分别是不合格、待改进、符合预期、超出预期和表现优异，BARS 的不同之处就在于给每个评价等级都规定了特定的行为表现。

以“展示有效的书面和口头沟通技巧”这个考核维度为例：
不合格的行为表现是，报告或文档写得不清楚、过于简单；
待改进的行为表现是，书面和口头技能需要加强，经常混乱；
符合预期的行为表现是，写作和说话清楚，有说服力，简明扼要；
超出预期的行为表现是，书面和口头沟通始终清晰，有说服力，适合受众；
表现优异的行为表现是，书面和口头沟通都是最高水平的，明确，准确，有说服力，并专注于特定个人和团体的需求。

可以看出，相较于李克特量表，行为锚定量表 BARS 有着明显的进步，但它也有一些限制或不足。首先，跟简单的李克特量表相比，构建有效的行为锚定量表要困难得多。其次，虽然行为锚定量表确实向员工提供了更多可操作的反馈，但却不能因此就证明 BARS 是衡量绩效的一种更好的方法。

除了李克特量表和行为锚定量表外，目前还有一种评定量表也在被广泛使用，即行为观察量表（Behavioral Observation Scale），简称 BOS 。

使用行为观察量表时，管理者会先针对各项评估指标给出一系列有关的有效行为，然后将观察到的员工行为同评价标准相比较进行评分，看该行为出现的次数频率。

行为观察量表具体指出了员工需要什么样的行为才能获得高绩效得分，管理者也可以根据行为量表去匹配员工行为，并用具体的行为条件给出反馈，这样员工便能知道哪些事情正确，哪些行为需要矫正。以下是一个使用 BOS 的示例表：

当我们介绍完行为锚定量表 BARS 和行为观察量表 BOS 后，就不难理解为什么人们会喜欢李克特量表这样的简单方法了，因为前两者都需要管理者和专家进行专门研发。

介绍了三种工具和方法后，接下来咱们简单比较一下这三种工具和方法：

我会从评价的客观性、量表开发成本、评定结果的反馈性、评估者的易用性及其他这五个维度来比较。

可以看出，在评价的客观性方面，李克特量表比较主观，而行为锚定量表和行为观察量表都相对更为客观。在量表开发成本方面，李克特量表的开发成本较低，而行为锚定量表和行为观察量表的开发成本都较高。

在评定结果的反馈性方面，李克特量表的反馈不明确，无法帮助员工更好的发展，而行为锚定量表和行为观察量表的反馈都比较明确，员工可以根据反馈有针对性的改进并提升自己。

在评估者的易用性方面，李克特量表比较简单易用，而行为锚定量表和行为观察量表都需要持续记录员工行为，耗时较多，其中行为观察量表除了耗时多外，需要评估的题目也多，更耗精力。

除此之外，李克特量表容易产生过宽、过严的问题，还容易产生晕轮效应偏差，而行为锚定量表则容易出现不同评估者之间一致性较高的问题。

可以看出，各种工具方法各有利弊，正如前面说的没有完美的工具或方法，都需要管理者根据自己公司的实际情况进行选用和开发。

下面附上我们之前结合行为观察量表和李克特量表制作的绩效考核表，供大家参考。由于每家公司的工作内容都不一样，这里仅放出针对员工特质的考核部分示例：

总结

本文我们介绍了三种常见的绩效数据收集的工具和方法，分别是李克特量表、行为锚定量表以及行为观察量表，这三种工具和方法各有利弊，还请大家按需研发选用。

最后想跟大家探讨下，目前你正在使用的绩效数据收集工具是怎样的呢，对比本文提到的工具和方法有何异同？欢迎在留言区分享～

感谢你的收听，我们下期再见！

作者简介

刘俊强（微信公众号：程序员精进），TGO 鲲鹏会会员，现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+ 年以上互联网开发经验，8 年以上技术管理经验。

第122讲 | 黄伟坚：创业中那些永远回避不了的问题

你好，我是 Mobvista 联合创始人黄伟坚，Mobvista 成立于 2013 年，是一家第三方移动价值发现平台，专注于为国内外的品牌广告商和移动开发者提供获客、变现及移动分析服务和解决方案。

在 2013 年到 2017 年这短短四年内，公司经历了裂变式增长，团队从 4 人扩张为 500 人，营收从 5 千万增长到 20 亿，翻了 40 倍，点击量从每天 1 千万增长到每天四个亿。这些数据其实也超乎了我们的意料，我们用四年时间快速经历了一般创业公司需要走 10 年甚至更久的路程，这些经历给予了我们很多思考。今天，我将这些经验与思考分享给你，希望与你共同探讨创业之道。

什么是最重要的事情

对于初创团队来说，总会遇到各种各样的问题，那什么才是最重要的事情？什么问题才值得你花费最多的时间与精力去解决？有没有一个办法，可以解决创业过程中遇到的所有问题呢？

我的答案非常简单，只有两个字——增长。增长可以解决创业公司在发展过程中遇到的所有问题。为什么？因为增长是公司发展的主要矛盾，解决了主要矛盾，其他问题都会迎刃而解。反之，如果公司一直存在这个主要矛盾，那其他问题也将得不到根本解决。

在此以员工离职问题为例，员工离职有两个主要因素，一是对收入或物质回报不满，二是得不到足够的成长空间，或觉得学到的内容有限。而之所以公司快速增长可以解决这个问题，原因有二：一是公司在快速增长，对员工的物质回报一定不成问题；二是公司在快速增长的过程中，业务在推动所有人向前走，迫使个人快速成长。如此，员工在两方面都能得到极大的满足，离职率也就会极大地降低。

讲到这里，你可能会问如何做到增长？对此，我用两个词来概括答案。

第一个词是时机，在合适的时间节点做有潜力的市场。以移动广告行业为例，2013 年，智能手机的普及进入爆发期，移动广告迎来流量红利。同时，国内的移动互联网巨头，或一些中型企业，迫于新一轮的增长需要，纷纷布局海外。我们看准时机，帮助国内的移动互联网公司出海，在海外推广他们的产品。可以说这是移动时代赋予的一个历史机遇，正是在这样的历史背景下，我们才实现了裂变式增长。

第二个词是团队，所谓“独行者速，众行者远”，意思是一个人可以走的很快，但是，要走的远，就需要一个团队，所以在任何时候强调团队的重要性都不为过。这个世界上，在同一时间跟你做同一件事的人有很多，也不只你一个团队，为什么你能脱颖而出？本质上取决于你的团队是否足够强大高效。

如果时机与团队这两个词不够详细，我还可以再用四个词来阐述创业。

需求，创业前你要找到市场需求、用户需求；

产品，你要用产品手段去解决用户的痛点与需求；

技术，通过技术手段优化产品，提升运营效率；

运营，通过数字化运营，优化产品，同时根据产品的数据反馈，优化运营效率。

如果这四个词还不够详细，我可以再送你八个词，分别是战略、战术、融资、产品、研发、管理、营销和财务。如果你觉得还不够详细呢，我可以再送你十六个词，但如果你需要用到十六个词去解释创业，那你就该重新考虑自己是否适合创业了。

总的来说，关于创业，你只需记住增长这个关键词就行了。

创业过程中难以避免的问题

在创业过程中，有些问题，我们永远回避不了，有些坑即使你知道也不得不再去踩一遍，因为你只有交了这笔学费，才能真正成长。今天我会主要分享三个方向的问题，即有关人的问题、部门协作的问题和激励的问题。

一、有关人的问题

与人相关的问题，是最难解决的，因为它不像工程，会得到精确的解。那怎样解决有关人的问题呢？我有两条原则：

第一，不要因为人的问题而调整组织架构。
比如某员工在某部门与同事或上级关系不好，影响了业务，但他的能力又挺不错，这时你可能认为只是把他放错了位置，调到其他部门就好了。其实，这个动作非常危险。因为在公司规模较小的情况下，即使把他调去别的部门，他与原部门的不和谐关系依然存在，并且这种负面因素可能会在整个公司内传播。另外，因为你没有从根本上找到原因解决他原来的问题，这时调换部门，反而可能会将问题带入新的部门，为自己埋坑。

我认为是否调整组织架构，只有一个判断标准，就是业务，你应该根据业务来调整组织架构，而不是因为个人。

第二，尽早解聘不合适的员工。
很多做技术的人都会比较心软，对于那些不符合要求的人，你可能认为可以再给他一些时间，再多给他一次机会，就能解决问题。但我想说的是，只要你作出解聘决定，你会觉得，为什么我不早点做这件事！因为解聘不合适的员工是一件绝对不会让你后悔的事情，它会让你的管理负担变轻，收拾烂摊子的机会也会变少，你会感觉“真好”！

二、部门协作的问题

技术团队通常会面对多个部门的夹击，比如商务、运营、产品等，非常容易产生矛盾。而这种内部摩擦很难避免，也是互联网行业普遍存在的矛盾，所以关键在于如何减少摩擦，做好跨部门协作，提升工作效率，一般可以遵循三个原则

1. 主动汇报
比如主动汇报项目进度，假设客户要求你在一小时内导完数据，但当你做到一半，预估一个小时可能完不成时，你可以主动跟客户沟通，按照目前的进度，一个小时无法完成任务，可能需要一个半小时。当客户能得到及时反馈时，即使你最后超时完成工作，他也会理解你的难处，不会太过生气。

所以要主动汇报项目进度，及时反馈问题，而不是等你做完了再解释缘由，尤其是项目时间较长时，及时汇报特别重要，能有效减少摩擦。

其实，有时对方问你什么时候能做完，真正目的可能并不是要求你必须在某个时间内完成，而是他想知道一个时间点，让自己心里有底，方便他安排项目进度和其他工作。

2. 充分沟通
跨部门之间的沟通很重要，许多问题都是由沟通不足引起的，如果双方能在信息透明的情况下，沟通顺畅，误解就会大大减少。因此，我经常会同商务、运营等部门的负责人直接沟通，了解双方的工作事项及进度，自上而下倡导沟通的氛围。

3. 参加对方部门的会议
我非常鼓励部门 leader 或部门核心人员去参加协作部门的核心会议，比如他们某个项目的 milestone 会议。从会议中你可以了解他们目前的项目进度，以及遇到的困难，方便技术做一些预见性的准备，另外，这也是一个加强沟通的过程。

三、激励的问题

这是一个老生常谈的话题，但又非常重要。激励机制又可以看作是反馈机制，它能让每个人认识到自己做的好与不好，方向是否正确，又有哪些待改进的地方等等。

那如何做好激励呢？除了常见的规则以外，我们还做了以下四方面的事情：

1. 制定阶段性任务，完成每个阶段任务，员工都会得到相应的荣誉奖励。

2. 偶尔超预期鼓励，以年终奖为例，我们通常会在年初制定年度目标，比如收入指标要达到 40 个亿，如果完成目标，每个部门能得到什么样的奖励。而实际到年底奖励的时候，我们给予的会远远超出年初制定的激励目标，超出员工的预期，这样才会起到激励作用。

3. 针对技术部门，我们会经常举办各种各样的活动来激发他们的荣誉感和归属感，如评比技术之星、技术创新奖、最佳新人等等。

4. 反向激励，比如对于每一次线上事故，我们都会评级，从 P0 到 P5，P0 的严重程度最高。一旦出现 P0 事故，从 CTO 一直到责任人，自上而下全部要罚，并且进行公示。当然，罚钱不是最重要的，目的是给大家传递一个态度，即线上问题不是小事，大家必须要重视。

小结

创业中解决问题最好的办法就是实现增长，而创业是一个漫长而艰辛的过程，总会遇到各种各样无法回避的问题，比如人员问题、协作问题、工作效率问题等等，今天，我所分享的内容都是基于我们在创业过程中遇到的具体问题，而提炼出的一些思考，希望能对你产生价值。

作者简介

黄伟坚，Mobvista 联合创始人，TGO 鲲鹏会会员，从 0 到 1，经历公司裂变式增长，从初创公司成长为为亚洲最大的移动广告平台。曾负责公司整体技术架构规划、研发团队和研发体系搭建、运维自动化等工作，在高并发、大数据处理方面有丰富实战经验。

第123讲 | 黄伟坚：用系统性思维看待创业

你好，我是 Mobvista 联合创始人黄伟坚。在上一篇文章中，我谈到了我对创业的看法，在我看来，对于创业团队来讲，最重要的事情就是增长。增长可以解决创业公司在发展过程中遇到的所有问题。

如果展开来讲，我们可以用四个词来概括创业，就是需求、产品、技术和运营，再展开用八个词来概括的话，就是战略、战术、融资、产品、研发、管理、营销和财务。

可以看到，创业是一个系统工程，创业过程中面对的问题成百上千，而且纷繁交错，我们不可能通过控制一个单一的变量或因素来掌控整个创业系统，这是不现实的。所以就要求我们用系统性思维去看待创业。

如何用系统性思维看待创业

自然界中的生态系统是一个非常好的类比。众所周知，生态系统有非常强的自我适应、自我修复、自我进化的能力。那有没有一种可能，公司也可以像生态系统一样，在外部与内部不断变化的条件和环境中，不断适应与进化呢？我们可以向自然界的生态系统学习一些基础而核心的原则，从中得到启发。

进化论中有三个核心原则，一是生物的多样性；二是遗传变异；三是物尽天择，适者生存。在这三者中，生物的多样性为遗传变异提供了来源与物质基础，而遗传变异提供了进化的方向，物尽天择，适者生存。这是竞争，通过竞争，适合的物种就能留下。

那如何将这三个核心原则内化为指导我们创业的具体行动指南呢？

首先，保持多样性，我们非常强调团队的多样性和包容性，因为只有多样性的团队，才有可能产生化学反应，发生变异。所谓多样性团队是来自不同专业，有着不同性格、不同理念、不同文化的一群人在一起。在技术团队中，如果大家理念极度一致，讨论时无人发表意见，一团和气，是非常危险的现象。

我们鼓励冲突，接受不同观念，只有这样，才能碰撞出新的想法，才能产生遗传变异的基础。所以在组建团队方面我们一直强调，包容不同的声音，只要他没有违反公司红线，业绩又能达到要求，我们就可以包容。比如，有些管理者觉得上班刷知乎、刷微博不可容忍，但我们某位高管就经常这样做，可他的表现都是超预期的，所以我们对这种事情特别容忍。

其次，打造开放系统，热力学中有个定律，一个封闭的系统，它的熵是永远在增加的，而且不可逆，最终导致整个系统崩溃。一个系统只有通过能量交换，不断从外部引入能量进行负熵，才能保持系统的活力。

公司也一样，需要源源不断的从外部接入信息，对于一家创业公司来说，持续不断的接收外部信息非常重要。不仅创始团队、核心团队需要走出去，多跟外部交流，多从外部获取信息，我们也鼓励基层到中层的员工走出去，让他们面向市场，了解客户，了解竞争对手，了解行业上游与下游，甚至是更多的跨界信息。

除了上面提到的鼓励员工走出去外，我们还会在机制上做一些事情，比如定期举办中层管理会议，而这样的会议一般都是在公司之外举行，比如在度假村，请内部讲师、外部讲师，甚至同行来做分享，给我们输入信息。同样，我们也有针对初入职员工的星星之火培训，诸如此类，通过各种各样的手段给公司进行信息的输入。

再次，远离平衡态，很多公司发展到比较大的规模后，可能会追求一种状态，就是公司的流程规章制度都在掌握之中，所有人都要按照规章制度办事，不出疏漏，每个人的绩效都可以被精确衡量，一切都在自己的掌控中。

之所以如此，是因为控制可以给人一种安全感，但事实上，越追求控制，越追求稳定，就越会给公司增加各种各样条条框框的约束，反而导致公司活力下降。

因为，当一个系统处于稳定状态时，它的能量是在最低点的，而当系统处于不稳定状态时，它的能量才处在最高点，所以我想讲的是，公司尤其是初创公司，每天都会面对各种各样的问题，这是常态，一旦你感觉进入掌控状态，一切都尽在掌握，才是可能出现危险的时候。

最后讲讲竞争机制，在自然界中，物尽天择，适者生存，商业社会也是一样，竞争是人类进步的动力之一。

对于一家公司来讲，除了面临外部竞争以外，内部竞争也是不可避免的。比如，腾讯就有内部竞争的传统，甚至将其当做是提升产品体验的一个重要方式，微信的诞生就是内部竞争的结果。再比如网易，网易游戏的创新机制中很重要的一个就是滚动研发机制，多个团队同时进行上百款游戏研发，然后密集的进行各类阶段性评估，竞争最终的上线机会。

可以说，危机意识是每个企业员工，尤其是领导人应该保持的基本状态，我们可以刻意在内部引入竞争机制，让不同的团队竞争同一个项目。即便没有因为项目竞争的情况，我们也要刻意在公司内，通过各种管理机制营造竞争氛围，如绩效考核、末位淘汰等。除此之外，我们还可以适度引入外部新鲜血液，刺激团队内部的竞争氛围，起到“鲶鱼效应”的作用。

当然，需要注意的是，我们要把内部的良性冲突控制在一定的范围之内，而不是简单的让内部团队形成对立冲突面，最终反而影响到团队间的工作配合和效率，整体的团队氛围和文化。

写在最后

创业至今，经历公司从 0 到 1 的裂变式增长，遇到了很多问题，也踩过很多坑，最大的感悟就是，创业是一个系统工程，一定要用系统性思维去看待创业。

在实践中，我们可以借鉴自然界生态系统中的一些核心原则，如保持多样性和包容性、打造开放系统、远离平衡态、打造竞争机制等，将公司构建成像自然界中生态系统一样，拥有非常强的自我适应、自我修复、自我进化的能力，来不断适应当今愈发多变的互联网行业。

作者简介

黄伟坚，Mobvista 联合创始人，TGO 鲲鹏会会员，从 0 到 1，经历公司裂变式增长，从初创公司成长为为亚洲最大的移动广告平台。曾负责公司整体技术架构规划、研发团队和研发体系搭建、运维自动化等工作，在高并发、大数据处理方面有丰富实战经验。

第124讲 | 刘俊强：必知绩效管理知识之评定绩效

你好，我是腾讯云资深架构师、TGO 鲲鹏会会员刘俊强，有着 8 年以上的技术管理经验，今天想跟你分享技术管理者必知的绩效管理知识之评定绩效。作为管理者而言，绩效评定这个过程是非常关键、非常重要的，我们先了解下绩效评定的具体流程是怎样的，然后再介绍如何撰写绩效评价。

绩效评定流程

在我们开始绩效评定之前，需要先对整个绩效评定流程作出一个合理的时间安排。可能对于大公司的管理者而言，人力部门会帮你制定时间表，并按时提醒进度。但如果公司规模较小的话，可能就需要管理者自己创建和控制流程。

那怎么制定绩效评定流程呢？下面我们先了解下绩效评定阶段的工作顺序，并对相关工作内容进行梳理，以便我们能够清晰地掌握绩效评定流程的各个方面。

绩效评定阶段的最后一项，是在截止日期前将所有评定结果反馈给人力资源部门，因此，我们首先要确定反馈给人力资源部门的截止日期，进而反推绩效评定流程中各项工作的完成时间。从我过往的经验来看，一般整个绩效评估流程大约需要 6 周的时间。

第一周，在整个流程开始前，需要管理者将时间表及考评流程同步给员工，以便员工对接下来参与考评流程一事做好准备。这里的同步方式可以是正式邮件结合非正式会议的方式，如果某些员工没弄清楚考评流程的话，还需要管理者对其进行单独的沟通辅导。

第二周到第三周，员工进行自我评估。每个公司情况不一样，可以是 Word、Excel 文档也可以通过在线系统进行提交。当然，如果有条件的话，更建议采用在线系统，方便日后追溯和员工培养。有些公司还会采用同事间互评的方式，并将结果作为绩效参考，这里我们对采用的数据来源不做更多的评判，还是以阐述绩效评定阶段的流程为主。

在这个时候，管理者需要根据之前文章中介绍过的绩效数据收集方法，拿出之前收集到的数据，以便对各个员工在绩效管理循环中的第二个阶段——绩效辅导阶段中的表现情况有清晰的认识，尽量避免认知偏差带来的不公平问题。这里我附上一个绩效评定示例表，以供大家参考。

第四周到第五周，管理者需要对自己管辖的团队和员工进行绩效评定，并撰写绩效评估的评语，怎么撰写评语我将在本文的第二部分详细介绍，这里就不再展开了。

在这个阶段，管理者需要根据之前确定的绩效目标以及收集到的数据，包括员工的自我评价、绩效目标的完成情况以及日常的行为表现记录等等，根据这些记录及数据来进行绩效考核表的填写。假设以上表为例，其中的上级评语和改进意见是最为重要的部分。

另外，管理者做完绩效评定后，接下来需要安排自己的时间，在第六周的时候与团队员工进行绩效面谈。确认好时间后，建议使用日程管理工具管理好日程，并且也要确认被评估员工的时间，让员工能准时参加一对一的绩效面谈会议。

至于会议时长，我建议跟每次都安排一个小时的时间，可能实际用不了这么长的时间，但这样预留安排时间的好处有两点，一是不要让员工觉得你很着急结束跟他的绩效面谈，这样正式的沟通机会对员工来说是难得的机会；二是如果能提前完成面谈，你还能够花这些时间去处理其他日常工作和可能出现的紧急事务等，并不会浪费。

另外在与员工进行绩效沟通时，一个实践经验是，先从他们最近的绩效表现开始聊起，然后整体回顾该员工的表现。另外，管理者在与每位员工进行绩效沟通前，需要至少将该员工的整体信息看两遍，不要让员工觉得你不了解他们的实际情况，否则他们会怀疑绩效评定的准确性和公平性。

第六周，将最终结果和绩效面谈后的员工反馈等信息整理后提交给人力资源的同事，至此，整个绩效评定流程正式完结。

撰写绩效评价

前面我们介绍了绩效评定的整个流程和时间周期安排，现在是时候聊聊如何写绩效评语了。之前有介绍过，管理者至少使用一周的时间来进行绩效评语的撰写，建议时间是一周至两周的时间。

为什么需要这么长的时间呢？因为管理者需要对员工在整个绩效周期里的表现进行评分，同时还要撰写相应的绩效评语和改进意见，所以完整回顾员工的整体表现是十分重要的，也就需要多花些时间反复斟酌。因此，我会建议，每个员工，管理者都至少花费一至二个小时的时间来撰写他们的绩效评语。

接下来我们聊聊撰写绩效评价的一些策略，大多数管理者会首先填写量化考核的部分，但是我并不建议这样做，相反我会建议先从叙述性、陈述性的部分开始，例如绩效评语及改进建议等。原因在于这样做能够强迫管理者在没有详细数据支持的情况下，来思考员工在绩效周期内的表现情况，并回想起他们具体的突出行为例子。可以说，从陈述性的部分开始撰写，能够很好地帮助管理者回忆起员工的表现。

在完成陈述部分的草稿之后，是时候填充量化考核部分了，管理者需要根据之前收集到的数据，对每个考核项的完成情况进行分数评定。接着还需要拿出员工自我评价、同事互评等信息，看是否需要对之前的评分作出调整。

这里需要记住的原则是，一般情况下你最初的评定是你最诚实的评定，绩效评定的目标是提供公平的评估，而不仅仅是个人评估或他人对该员工的评估。

在完成量化评定部分后，这时你可以回到叙述性评语这块，看看量化评定跟你之前填写的叙述性评语间的差异。管理者需要关注这样的差距，同时要尽量解决这样的差距。

我会建议管理者将这些差距记录下来，并具体解释为什么会有这样的差距，这将会成为接下来你跟员工绩效沟通时的重点，你需要告诉员工为什么彼此的认知是不一致的，不论是正面还是负面的差距都应如此。

上面我们介绍了如何做好绩效评定，一个良好的绩效评定应该是完整、准确、公平且尽可能有用的。完整意味着管理者需要对绩效考核的各个维度都进行评定和评价，同时在允许的情况下提供足够的绩效评语。准确性要求管理者认真审查收集到的绩效数据，产生差距时需要解释差距产生的原因，以保证评估是准确的。公平性要求管理者使用的评价标准要一致。最后一点是，评语要对员工的改进有帮助。

总结

综上所述，绩效评定是绩效沟通环节的关键前置环节，一个良好的绩效评定能够助力你接下来的工作。

思考题

试着回想下，你最近做绩效评定时是怎么操作的呢？有什么关键点可以分享给大家呢？

感谢你的收听，我们下期再见！

作者简介

刘俊强（微信公众号：程序员精进），TGO 鲲鹏会会员，现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+ 年以上互联网开发经验，8 年以上技术管理经验。

第125讲 | 洪强宁：从程序员到架构师，从架构师到CTO（一）

你好，我是爱因互动 CTO、TGO 会员洪强宁，在我的职业生涯中，经历了三个阶段，最初是一个典型的程序员，后来在豆瓣开始担任架构师，一直做到首席架构师，现在创业做 CTO。对我来说，每次职位的跃升，都是一个提升眼界的过程。今天，我把这些提升的经验和体会分享给你，希望对你有用。

我们知道，技术人最典型的一条职业发展路径，就是由程序员，到架构师，再到 CTO。那是不是技术人的职业通道就只有这一条呢？并不是，因为程序员、架构师和 CTO，这是三个职业，每个职业都可以单独发展，不断深入与精进。而从程序员到架构师，再到 CTO，主要差异在于看问题的层级和着眼点不同。

对于程序员来说，他们最关注的是技术中的细节处理，看到更多的是代码、模块这个层级，当程序员的着眼点从这个层级，提升到关注系统与协作时，他们就变成了架构师的角色。因为架构师会更加关注系统，着眼于组件和组件之间的协作，然后当架构师的着眼点再往上提升，关注更多的就是业务实现与战略发展，这时，角色就变成了 CTO。

因此，我总结自己多年的职业发展经验，得出一个论断：职业发展的过程，就是眼界不断提高的过程。这不仅仅是对于程序员、架构师、CTO 这个职业发展路线，还包括本岗位持续深入与精进的路线，比如程序员，随着能力的提高，眼界也在不断提升，关注点将不再是最初的细枝末节，而是会有大局观的意识，这也是一个优秀的程序员需要具备的思维。

优秀程序员需要具备的特质

其实相对于架构师和 CTO 来讲，做程序员是最简单的，只需要会写代码就可以，但问题是，只要会写代码就能成为一个优秀的程序员吗？答案显然是否定的。因为，成为一个优秀的程序员，需要多重考量，还需要具备一些特质。我根据自己的经验总结了五点，我把它称为“五精”。

1. 精细，在细节之处深思熟虑。比如代码结构、变量命名、作用域、封装、类的关系等细节。举个例子，对一个变量的命名，应该用短命名，还是长命名，用 A 来表示，还是用一个特别长的句子来表示？这些细节，在你写代码时，就应该仔细衡量，因为它将影响代码后续的可读性与可维护性。

2. 精湛，写出漂亮的代码。在豆瓣任职时，我们有一句半开玩笑的话，说豆瓣是工程师文化，意思是工程师要有文化。我觉得除了文化之外，工程师还需要有一定的美感，分辨一个设计是否简洁、优雅、高效。

3. 精通，了解上下游知识。除了关注自己写的代码与模块，一个优秀的程序员还需要对上下游的知识有所了解。比如你是负责前端的，那你也需要了解一下后端是如何迎合你的请求的；如果你负责后端，你还需要考虑你的代码是如何做运维的；当你去访问数据库时，你需要了解，数据库是怎样应对你的产品请求的。只有将上下游的支撑都了解之后，写代码时，才能够更加准确、更加高效。

4. 精深，掌握技术细节。包括语言细节、类库细节、算法细节、运行环境细节，等等。比如你使用一门语言，那你需要知道这门语言的各种语法细节，以及在什么地方最容易出错，怎么做能够有效的规避它等。再比如你使用的类库是怎样实现的，它在什么场景下的表现最好，在哪些场景下会出现问题等。还有运行环境，你不仅需要考虑业务逻辑，你可能还要考虑内存占用问题、缓存问题、磁盘问题等。这些都需要你对技术细节有较深的掌握度。

5. 精明，做到准确交付。一个优秀的程序员不仅需要优雅、高效的实现需求，还需要在准确的时间内，交付符合质量的内容，这就需要我们去理解需求，并通过协商和沟通对不合适的需求作出调整。另外，也需要我们准确的评估工作量，判断优先级事项，做出考量和取舍。

而当你到达考量与取舍阶段时，就说明你已经开始具备一些架构师所需的特质了。

如何成为一名优秀的程序员

那怎么做，才能拥有这些优秀程序员需要具备的特质呢？我认为最重要的事情是互相学习，向更优秀的人学习。

举个例子，在豆瓣时，我们有一个非常好的实践就是做 Code Review。最开始的时候，大家把所有的代码投到屏幕上，并各自讲出写代码的思路，其他人可以自由发表评论。这样做其实效率非常低，但我们一直坚持了下来，直到 GitHub 出现，我们用其中 Pull Request 的方式来做 Code Review，效率才大大提高。

用 GitHub 做 Code Review，收到的评论会非常多。如果一段代码几乎没有人表达反对意见，很大程度就能代表这是一个不错的代码。如果出现一段糟糕的代码，评论内容就会非常犀利的指出问题。也正是在这样不断评判与被评判的过程中，大家逐渐学会提高自己的代码水平，成为一个更加优秀的程序员。

另外，我们可以多参与技术社区，多参加各种技术交流活动和技术大会，多多跟他人交流。我们也可以不断地去参与开源项目，现在是一个最好的时代，GitHub 的存在，让每个程序员能更容易地看到更多优秀的代码。

从程序员到架构师

你可能会问，那是不是一个程序员，只要能写出漂亮的代码，并且能够优雅、高效地实现业务需求，做到准确交付，就一定能成为架构师呢？

答案是否定的，即使一个程序员做到了“五精”，把“五精”做得再好，他的个人能力也是有上限的，他所实现的系统的复杂度也是有上限的，而业务的发展会远远超出个人的能力。

因此，我们需要把业务需求拆分成多个组件，再将每个组件分发给优秀的程序员来完成，通过互相协作，最终完成一个整体的业务需求。

在这里，分发的工作就是架构师的职责，架构师主要在解决 Scalability 的问题。它包括两个方面，一方面是人的 Scale，比如业务需求变复杂后，单人不足以承担，这时就需要多人协作，那如何分解业务，如何将分解后的业务匹配合适的人，如何协作，就需要架构师来进行判断。

另一方面是量的 Scale，比如当 QPS 从几十个增加到成千上万个，甚至几十万个的时候，面对这种情况该怎么办？这就是架构师需要解决的问题。

因此，当你从实现一个具体的功能，到考虑解决 Scale 问题的时候，你就已经开始走上了架构师这条路。即使你的 title 还是程序员，但是，你已经开始向架构师这个角色转变了。

总结

本文，我主要分享了一名优秀程序员所需具备的特质，即精细、精湛、精通、精深、精明这五个特质。另外，从程序员到架构师，不在于 title 如何，而是当你的着眼点更上一个层级，更多的理解业务需求，然后思考如何解决宏观问题、提炼通用组件、设计协作方式等问题的时候，你就是一名架构师了。

下一篇文章中，我将分享优秀架构师所需要具备的特质，以及从架构师到 CTO 转变之路的关注点，欢迎持续关注。

作者简介

洪强宁，爱因互动 CTO ，TGO 鲲鹏会会员，资深 Python 程序员，曾任豆瓣网首席架构师与宜信大数据创新中心首席架构师，编程 30 余年，拥有 11 年互联网从业经验。

第126讲 | 洪强宁：从程序员到架构师，从架构师到CTO（二）

你好，我是爱因互动 CTO，TGO 会员洪强宁，在上一篇文章，我分享了程序员到架构师的发展之路，以及一名优秀的程序员需要具备的特质，今天我将继续跟你分享一名优秀架构师所需要具备的特质，以及从架构师转变为 CTO 的过程中需要注意的地方。

优秀架构师需要具备的能力

我觉得一名优秀的架构师，需要以下这四个关键能力：取舍、前瞻、抽象、容错。

1. 取舍

一个架构总是有优有劣，它不会是完美的、普适的，也不存在一个架构在 A 场景能用，在 B 场景也最适用的情况，所以就需要我们准确判断，作出取舍。

我们可以根据具体的业务需求来调整架构，也就是以当前的业务需求，选出最匹配的架构。另外，架构师还需要根据现状衡量好需求和资源、效率和安全、时延和吞吐等等之间的关系，做出判断。比如对于在线系统，可能更重要的是保证它的高时延，因此就可以牺牲一定的吞吐量，而对于离线系统，吞吐量则更重要一些。

2. 前瞻

架构师需要具备一定的前瞻性，因为架构的调整周期比较长。这也是程序员和架构师之间一个很大的区别所在。

程序员负责一个项目，在当前的互联网协议下，项目的迭代周期非常快，基本以天或周为单位，最多一个月。如果发现不合适的代码，需要重构，程序员基本也能在几天或几周内就能完成重构。

而架构的调整是相对漫长的过程，可能需要数月，甚至要上年。因此，在设计架构时就需要架构师具备前瞻意识，对很多不确定的事情做出预判，比如未来访问量会增长到什么程度，会不会产生新的业务，这些会对系统产生什么样新的要求等等。

3. 抽象

除了懂得取舍和拥有前瞻意识，架构师在设计架构时还要掌握抽象的方法，不能胡子眉毛一把抓，要做好分层和区隔。

因为架构师面对的是一个很庞大的系统，为了避免过早陷入细节，不要去看各个组件的细节，而是把它们的角色定义下来之后，再分块来思考。而在看每个分块时，其他分块都可以视为一个抽象的概念，另外，也需要考虑复用的问题。

举个例子，我们现在正在做的对话机器人，就运用了分层思想，并且高复用，一个对话机器人可以完成各种各样的业务需求。这其实是一个非常复杂的系统，里面有各种各样的对话机器人的模块，有的特别适合去做检索式的查询，还有的适合做任务导向的、产品推荐导向的对话等等。

我们把对话机器人抽象成一个通用的接口，再将它分为一个个小机器人。这样一来，每个小机器人只需要关注自己的业务模块就行了。然后，我们会在前端再引入一个路由机器人，由路由机器人根据当前对话管理的状态，来判断当前的对话应该交给哪个小机器人去完成。这就是典型的分层的思想。

4. 容错

相比程序员，架构师面对的环境要恶劣的多，因为系统复杂了，出错的几率也增加了，每个节点、每个功能都有可能出错，所以这就需要架构师为错误而设计，事先做好解决方案。

除了出错，还有可能产生数据丢失的情况，这个可以通过备份来预防。有句话说“备份不做，日子甭过”，做好备份也是非常关键的。

另外，如果出现故障，该怎样去恢复呢？我们现在普遍的做法是不修只换，因为如果要修复一个异常状态，可能修复后还会出现连带问题，而如果能通过技术手段，删除已出现的故障，换一个全新的系统，就能够保证它迅速恢复到正常状态。

从架构师到 CTO

再来聊聊从架构师到 CTO，我做 CTO 这个角色只有两年，相比资深 CTO，我对 CTO 这个角色的感悟也没那么深刻。我觉得从架构师成为 CTO 之后，我工作中最大的变化是，从一个需求实现方变为了需求提出方。之前是我的老板提出需求后，我需要思考用什么样的技术和架构来实现它，而现在更多考虑的是，用什么技术才能发展业务。

怎样从架构师的角度转变为 CTO 的角度去思考问题呢，我认为关键点还是在于提高眼界，不仅要着眼于实现需求，还应该思考能发掘出什么新的需求。

举个例子，在我准备创业时，有一件事对我的触动非常大，就是 AlphaGo 战胜李世乭，我原本以为人工智能在围棋方面战胜人类还需要 5 到 10 年，没想到会这么快。

我以十年为一个节点，回顾了近三十年技术圈里发生的重要事件，发现大概每 10 年就会发生一件里程碑式的事件。

大约 1986 年年底，互联网正式商用，标志着我们进入了互联互通的时代。到了 1995 年，Web 出现。然后在 2007 年左右，发生了三件大事，一是 Google 发表分布式系统论文，使得分布式计算变得更加廉价、更加可行；二是亚马逊发布 AWS，意味着云计算正式进入可以商用的状态；三是苹果发布 iPhone，标志着我们进入移动互联网时代。又过了十年，就是 2016 年，AlphaGo 战胜李世乭，标志着我们已经进入了人工智能与大数据时代。

纵观这些趋势，站在 CTO 的角度，当前最应该关注的就是人工智能和大数据。而因为当时我们已经在做创业的准备，就需要考虑人工智能和大数据这个趋势会给我们的创业带来什么样的影响。

随后我和豆瓣前首席科学家王守崑就决定从这个方向入手，一起梳理了我们已经具备的技术能力，主要有这六点：自然语言处理的能力、深度学习的能力、个性化推荐的能力、知识图谱能力、大数据的能力和云平台的能力。

同时，对于产品，我们都认为，随着人工智能的发展，下一代的 UI 人机界面将会是对话式的，因为对话式的人机界面更加自然，门槛更低，又具有私密性和个性化的特点。所以，我们判断这样的产品会是未来的产品形态。

于是，我们就选择利用自然语言处理、深度学习、知识图谱等能力做一个对话机器人，利用个性化推荐、大数据处理、云平台等能力做一个 SaaS 平台。最终，我们的创业方向就确定为偏售前领域的对话机器人 SaaS 服务。

如何成为一名优秀的 CTO

当我们成为 CTO 这个角色，往往不是先有需求，再考虑技术实现，而是根据当前的技术潮流和自己所掌握的技术能力，去考虑如何实现业务。

可能有人会说，这是 CEO 该考虑的事情，没错，这确实是 CEO 的职责，但也是 CTO 的职责。之前大家常开玩笑说，CTO 就是要把 CEO 吹的牛含泪也要实现的那个人。我觉得不对，CTO 其实是帮着 CEO 一起去吹靠谱牛的人，他是 CEO 的一部分。

CEO 这个角色涵盖了公司中的方方面面，他把自己的角色拆分后，其中偏技术的角色就是 CTO。同时 CTO 也是技术团队的建立者和技术文化的捍卫者，因为他是技术团队的最高负责人。

那么一名优秀的 CTO 应该具备哪些能力呢？

首先，他需要关注多个方面，第一，关注业务，我们需要知道用户需求，以及我们能够给用户带来什么样的服务质量和价值。第二，关注行业，比如竞争对手和新的技术，我们需要了解新技术对自己而言是不是意味着新机遇。第三，关注机遇，作为 CTO，需要了解有哪些需求还没有被满足，我们能做什么，新技术能够带来哪些可能性等等。第四，关注增长，能预见到业务的增长并提前应对，能发现增长的瓶颈并及时解决，并在增长的过程中保持系统健康。

其次，一名优秀的 CTO 也应该是一名优秀的架构师，一般在初创公司，CTO 就是首席架构师，公司的业务架构、技术架构，基本上都是由 CTO 来确定，再往前推进的。同时，CTO 也是组织的架构师，需要考虑怎样搭建团队、怎样分解业务，才能够更好的完成战略需求。而对于战略，也需要 CTO 做出优先级判断和取舍。当然，CTO 还需要发现并解决组织级的系统瓶颈，这和架构师做的事情是一样的。

同时，CTO 也应该是一名优秀的程序员，但对于 CTO 要不要写代码这个问题，我的回答是“NO”。我觉得 CTO 最好不要写业务代码，因为，如果你没能及时提交，几乎没有人敢催，而这会影响项目的交付，成为瓶颈。如果你想保持对技术的敏感度和创造力，你可以写写效率工具，写写分析型的代码等。

最后，CTO 还需要像程序员一样，持续不断的优化。当然，CTO 要做的不是优化代码，而是优化产出，基于数据去管理团队。

总结

职业发展的过程，就是眼界不断提高的过程。对于程序员而言，从写代码，到关注代码与代码之间的关系，再到关注代码与系统之间的关系，这时，他就开始承担了架构师的职责。

架构师主要是在做系统的事情，他的着眼点会从系统与系统之间的关系，到系统与业务之间的关系，到这时，他开始承担一些 CTO 的职责。而对于 CTO 而言，他关注的是业务，然后逐渐关心业务与业务之间的关系，最后关心业务与战略方向的关系。这个眼界提升的过程就是从程序员、架构师到 CTO 的发展路径。

作者简介

洪强宁，爱因互动 CTO ，TGO 鲲鹏会会员，资深 Python 程序员，曾任豆瓣网首席架构师与宜信大数据创新中心首席架构师，编程 30 余年，拥有 11 年互联网从业经验。

第127讲 | 刘俊强：必知绩效管理知识之绩效沟通（一）

你好，我是腾讯云资深架构师、TGO 鲲鹏会会员刘俊强，有着 8 年以上的技术管理经验，今天想跟你分享技术管理者必知的绩效管理知识之绩效沟通。绩效沟通最为常见的方式是一对一绩效面谈会议，绩效面谈会议是阶段三绩效考核和反馈中的重要工作项，优秀的管理者会好好利用这个机会，跟下属沟通好他们的绩效表现、帮助员工改进并指引发展。本文将介绍怎么准备绩效面谈会议以及如何设定绩效面谈会议的期望，以便管理者可以在绩效面谈会议开始前做好准备，最大化利用好这次跟下属沟通的机会。

准备绩效面谈会议

在绩效面谈会议前应该做哪些准备事项呢？简单来说主要是三个 W（When、Where、Who），分别代表着：When 会议时间安排、Where 会议地点安排以及 Who 参会人员安排。

关于会议时间的安排，正如前面文章所说，一般需要在第四周至第五周的时候，跟员工确定绩效面谈会议的时间。建议管理者可以先根据自己的时间来进行日程排列，然后跟员工确定该时间是否适合，因为很有可能员工正处在项目重要阶段，所以时间上需要跟员工沟通好，可以是电话沟通时间、即时通信工具沟通或是当面沟通，沟通确认好了后建议管理者发出一封带日程的电子邮件，这样方便员工将日程更新到自己的电脑或手机上。

确定好下属们的绩效面谈会议时间后，便要开始预约会议室了。关于会议地点的选择，如果管理者拥有自己的办公室，不要使用自己的办公室做为绩效面谈沟通会议的地点，对于很多员工来说，去老板的办公室会有小学生去班主任办公室的感觉，即使没有什么问题，小孩去班主任办公室的时候还是会感到紧张，许多员工到老板办公室时也是此番感觉，毕竟管理职责带来的心理地位差异还是实际存在的。

因此，我们要将会议地点对员工带来的压力给去除掉，尽量选择对员工而言比较中性舒适的地点，在注意隐私前提下，空间大些会更好，空间小也会带来压抑感。这里有几个简单的会议地点选择建议，中型会议室、培训室和暂未启用办公区都是不错的选择。

一般情况下咱们的绩效面谈沟通会议，都是评估者和被评估者两个人参加，即管理者和下属的一对一会议。但是也有例外，如果管理者有合理理由觉得这次沟通会议会比较艰难，那么有人力资源同事或其它经理的参加可能会有帮助。简单举例，例如跟绩效表现很糟糕且固执的下属沟通，可能人力资源同事一同出席可能会更好，抑或是从员工未来的发展而言，如果对方需要更换业务线可能就需要该业务线经理出席。

不过不论是基于怎样的考虑需要第三个人参加绩效面谈沟通会议，建议都需要提前跟员工确认，最好是在发送正式邮件前就确认好，再发送邮件到参会人员的邮箱。因为在默认一对一的绩效面谈沟通会议中，如果员工在未被告知的情况下发现有第三个人参加，会让员工感觉到很不受尊重。这里建议，这样的会议增加第三人是慎之又慎的事情，需要提前确认并沟通好，不然会有很大的反作用。

上面我们明确了准备会议的三个 W 的主要内容，下面给一些管理者参加会议前的小贴士。首先在着装上，在遵循办公室规范情况下，尽量休闲舒适为主，不要在这时穿得很正式，因为绩效面谈会议不是轻松的会议，我们需要减少不必要的形式感和隐性压力。另外，当天第一个绩效会议开始前，建议管理者提前至少 30 分钟到达，准时是对下属的尊重，同时也为你提供了更多的时间准备，可以再回顾下待面谈员工的具体绩效表现。最后，在与会者座位的选择上，虽说你们是上下级关系，但是不要对面而坐，而是坐在桌子的同一侧保持一定距离即可，这样想传达的意思是，不是互相对抗而是合作。

管理会议期望

管理者如何管理好员工对于这次绩效面谈沟通会议的期望十分重要，一般来说可以从三个主要点来进行管理，分别是：员工对全年绩效评定的看法、会议开始前几周与员工沟通，以及实际会议中的期望管理。

第一个点，主要是帮助员工以全年视角来理解和思考绩效评估流程，作为管理者你越是不和员工介绍绩效评估相关的信息，越是可能会给后面绩效考核阶段造成麻烦。相反我们要引导员工理解绩效评估流程，例如跟他们探讨绩效评估方法、胜任力模型以及绩效评估流程需要员工关注的地方等。绩效评估这个事情，你不和下属员工沟通，他们相互之间也会聊的，那么相对于可能的消息谬误风险，提前告知沟通不是更为明智么？

第二个点，我们在前面文章也有介绍过，通过绩效评估流程的介绍和未来几周员工所做事情的沟通，在绩效面谈沟通会议的日程邮件发出时，管理者也可以附上会议上会沟通讨论的重点事项，例如管理者会反馈绩效评定情况、同事间的评价反馈以及改进建议等，如果公司业务有调整，那么这个时候进行沟通也是很好的机会。

需要着重提醒的是，不要在绩效面谈沟通会议上探讨薪酬调整和晋升的问题，现实中确实有很多公司都会将薪酬和晋升等话题与绩效沟通会议联系起来，那么在这里，我为什么不建议这样操作呢？因为，当员工知道这个会议要探讨薪酬和晋升时，那么他们很大程度上就不会再有效地倾听绩效结果和改进建议，而是只等待薪酬和晋升结果。薪酬调整和晋升建议专门抽时间进行处理和沟通，不要在绩效沟通时探讨，这会分散员工倾听绩效结果反馈和思考绩效提升的注意力。

最后一点，在实际会议上管理员工的期望。具体来说，在会议正式开始前，管理者可以先告诉员工这次会议的议程，议程一般不用太复杂，可以先是绩效完成情况、自我评价与上级评价、解释探讨评价间的重大差距，然后再是员工发展部分，例如，角色表更带来的挑战、培训和发展计划等。管理者不用过多介绍自己为这次绩效面谈沟通会议花了多少时间，但是可以简单介绍下你准备的东西，让员工知道你是认真对待这次会议的，这样在后面沟通绩效时，员工更容易接受和倾听你的反馈和建议，他们会感觉你的评价是合理的。

简而言之，管理员工的绩效面谈沟通会议期望，是帮助管理者和员工以最为开放和积极的心态来面对绩效评估结果的要点。

总结

本文我们介绍了绩效沟通面谈会议的准备和期望管理，能够帮助我们给绩效沟通开个良好的开端。你在最近的绩效沟通面谈会议前都做了哪些准备工作呢？欢迎在留言区分享~

感谢你的收听，我们下期再见！

作者简介

刘俊强（微信公众号：程序员精进），TGO 鲲鹏会会员，现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+ 年以上互联网开发经验，8 年以上技术管理经验。

第128讲 | 王坚：年轻人永远是创新的主体

王坚：2050 志愿者，阿里云创始人，阿里巴巴技术委员会主席。
他被媒体和众人称为“忽悠马云的骗子”和“风口上的先知”，但这些都是外人眼中的王坚，我们很好奇，站在这些标签背后的他，到底是什么样子？他究竟还有多少不为人知的趣事，脑子里装了哪些新奇古怪的想法？对于自己，他还有多少的期待？对于世界、未来和年轻一代，他又是如何看待的？

作为 2050 的志愿者和发起人，首先想和大家聊聊为什么要做这件事，我觉得现在很多人都在讲创新，但实际上创新是需要很多人帮助的，特别是年轻人。2050 就是为年轻人举办的活动，希望大家对年轻人更加关注，把社会资源留给他们，让他们可以做更多的创新。

如今，绝大部分会议都是为成功人士举办的，而 2050 恰恰是为那些还没有获得成功的年轻人举办的，让他们也能有机会表达自己的观点，这是我创办 2050 的初衷之一。除此之外，科技的作用也不能单单以是否有用去定义，年轻人有这样一个使命——让科技可以像音乐和体育一样将人团结在一起，让不同的人因为科技而产生关联，这就是我发起 2050 的两个初衷。

今年 5 月第一届 2050 落幕了，会议本身超出了我的预期，具体体现在哪里呢？就是我们成功地向外界传递出举办 2050 的初衷，让大家知道了什么叫做志愿者举办的大会，而并不是会议中的哪个活动做得特别成功，这是我觉得最骄傲的一点。如果说我们只有一点做得足够好，那就是这一点。我很清楚地知道会议本身还有很多不足，但只要能将这一点传达出去，就是我最大的收获。

对于明年的 2050，我希望可以向大家证明，志愿者可以做到很多人原本觉得不可能的事情。我们需要重新认识志愿的精神，相信明年的这个时候大家都可以感受得到，在中国，甚至在世界范围内，志愿者是如何为年轻人，或者说，如何通过年轻人为整个社会的发展和进步做贡献的，这一点我感到非常骄傲。我刚刚谈到过，大部分人都在做那些看起来很“高大上”的会议，但这不是 2050 所追求的，最“高大上”的就是年轻人，是年轻人本身。

其实，大部分年轻人都不知道自己处于什么状态，因为身在其中，我年轻的时候也不例外。站在我这个年纪回望过去，最大的感触就是自己年轻时得到了太多人的帮助，但当时我还感受不到这一点，是现在才能感受到的，这是让我非常感恩的一件事，所以我觉得应该为年轻人多做一点事情。

我记得我说过一句话：年轻人就是要做一些大家看起来不可能的事情。从这个角度讲，任何一个时代的年轻人都一样，唯一不同的是时代本身，比如蒸汽机时代有蒸汽机的挑战，电气时代有电气的挑战，如今的数据时代有数据的挑战，挑战是不一样的。但我觉得年轻人有一个最大的共同点，就是他们才是帮助整个社会去突破原有框架的群体，他们永远是创新的主体。

从阿里云到 2050 再到城市大脑，这些事情能够做成其实得益于很多自然条件，我觉得自己非常幸运可以有机会接触到它们。我认为大家还是要多多发现问题，而不是简单地去解决别人提出的问题，虽然发现问题和解决问题都很重要，但事实上，总要有一些人去发现新的问题。因为我的兴趣和背景，我永远会去观察有哪些新问题，所以可能在一些人忙于解决问题的时候，我在做前者。

那么，发现问题后谁来解决呢？我的习惯是自己发现的问题，只要我觉得足够重要，那就应该自己解决。而不是说我发现了问题，交给别人去解决。或许有人会觉得这有作弊的嫌疑，但从我自己的角度上讲，这就是我思考问题最基本的逻辑。所以我鼓励大家从身边发现问题，就算是那些看似很小的问题，也有可能变成社会性的大问题。

之前我看到过一个数据，35 岁以下的年轻人占世界总人口的 50%，当时我感到非常吃惊，因为这个数字是持续增长的，而不是呈下降趋势，是人类历史的峰值。这就是我发起 2050 时想到的问题。城市大脑也一样，我们都觉得城市交通堵塞，那么普遍的解决办法就是多修路或者限行，从没有人认真想过我们对交通资源的使用是否合理，我所做的只不过是从交通堵塞问题延伸到社会资源的使用问题，比如红绿灯资源的使用是否合理。发现问题非常重要，年轻人会用他们自己的眼光去发现别人看不到的东西，这可能也是年轻时候的我与其他人不太一样的地方。

谈到阿里云，现在已经叫云计算了，有两件事情让我印象深刻：首先，在加入阿里巴巴之前，我就已经意识到数据和计算的重要性了，这二者是一体的，你不能把它们拆开来。所以，我既然认识到计算对未来社会的重要性，就知道计算的形态是一定会改变的。

事实上，在云计算出现以前，我们已经经历过几次计算形态的改变了，从大型机到工作站，再到个人电脑，我觉得计算的形态将会发生很大的变化，而变化的物质基础就是互联网，这也是我为什么经常谈到，云计算就是通过互联网来获取的计算，其实是来自于我对计算本身的认识。

后来，大家逐渐对这种计算形态的变化有了共识，就把它命名为“云计算”了。尽管最初我并不愿意这样称呼它，我的设想是叫它“通用计算”，就像通用电器一样，就好像以前的电也是专用的电，只供电灯泡使用，后来才逐渐演变成通用的电，于是有了电冰箱等通用电器，所以我当时想叫它“通用计算”，但一般人很难接受这个叫法，所以就叫“云计算”了。

为什么我总是用电来举例子呢？其实是有原因的：就像电刚出来的时候只有电灯泡一样，阿里云的第一批客户都是中小网站，我觉得这些中小网站就是那个电灯泡，他们无法自行发电，但随着客户逐渐增多，你可以想象，电冰箱出现了，洗碗机也出现了……直到现在，云计算已经变成了通用计算。所以我觉得，对问题的思考会影响你做事情的方法，而发现新问题是思考中最重要的一环。

这是一个非常重要的时代，是属于年轻人的时代，尽管这句话放在历史上的任何时刻都是正确的，但我还是觉得我们现在所处的时代非常特别，是历史上少有的几次，对年轻人而言最好的时代。为什么这么讲呢？大家认真思考一下，美国最好的时代就是爱迪生诞生前后的三五十年，那时候涌现了很多新的发明，而我们现在看到的绝大部分科学技术就是最近几百年发明创造的，和美国那段时期非常相似，是所有可能性集中爆发的时代，至于具体会创造出什么，那就是另外一回事了。

我们通常会说任何一个时代都是年轻人最好的时代，但大家为什么还记得爱迪生那个时期呢？就是因为那个时代非常特殊，我觉得当下就等同于那时候，从电刚开始出现到给城市乃至社会带来翻天覆地的转变，而计算给城市带来的改变还没有开始，Kevin 今天带了一个 laptop，可能那就是开始的开始。

我觉得非常幸运的一点就是年轻的时候，身边的人为我创造出足够多的空间，所以我也想为年轻人创造空间，只要有充足的空间，他们就会用自己的方法去成长，这是我坚定相信的。大家现在看到年轻人身上有这样那样的问题，是因为他们的空间不够，行动就会受限和变形，这是我对年轻人的理解。现在的社会环境总体还是比较好的，可以为大部分人创造出足够的空间，要相信他们，不要让他们把事情做变形，这也是我能为他们做的最好的事情了。

(本文整理自 11 月 22 日王坚博士在极客 Live 的直播活动)

第129讲 | 刘俊强：必知绩效管理知识之绩效沟通（二）

你好，我是腾讯云资深架构师、TGO 鲲鹏会会员刘俊强，有着 8 年以上的技术管理经验，今天继续跟你分享技术管理者必知的绩效管理知识之绩效沟通。在前面的文章中我们介绍了如何准备绩效面谈会议并设定会议期望，今天我们将聊聊绩效面谈会议中如何跟员工进行绩效讨论。

讨论绩效

就员工在工作中的表现进行当面讨论可能会很困难，大多数管理者都不喜欢正式地批评员工，而且大多数员工也不喜欢被评估，所以，在绩效面谈沟通会议上正式地讨论绩效可能会让双方都有些紧张，那么实际绩效讨论环节该怎么做才好？怎样让绩效面谈沟通会议更有效率呢？

最为重要的是时间分配，一般情况下我们建议，10% 的时间用于回顾过去，50% 的时间用于介绍当前，剩余 40% 的时间用于讨论未来。

首先，回顾过去的时间不应该超过 10%，这个环节只是帮我们讨论绩效时设定好背景，例如，员工在公司的工作年限、有过多少次晋升、目前在公司的职位、在该职位上的任职时间，以及上次绩效评定表现好或不好的地方等。

在快速回顾过去后，就进入绩效讨论的主要部分，即当前绩效周期内的表现情况。在这个环节，管理者需要跟员工讨论他的目标达成情况和所有相关的评分，例如上级评定、自我评定以及同事评价等。就目标达成情况而言，有一些可能已经达成，有一些可能仍在进行中，也有一些可能是无关紧要的或是需要改变的。众所周知，公司或团队的需求会经常发生变化，最终不论怎样，管理者都需要对时候按时完成工作和达到目标等这些事情进行评分。

接下来我们以假定的绩效讨论对话来观察如何进行绩效讨论。在以下的对话中，张三为管理者，李四为员工。

张三（管理者）：首先祝贺你在公司的第一个年头。
李四（员工）：哦，非常感谢。虽然只来了十个月，但我确实觉得我已经是团队的一员了。
张三：是的，从二月份入职到现在已经十多个月了。这段时间内你的初始目标是了解咱们团队的开发流程并完成相关系统或服务的开发。在最开始的两个月整体完成情况低于预期，当然这对于一个新人来说非常典型，但再后来的八个月里你的目标都达成了，这是非常好的。
李四：很高兴听到这样的评价，我还担心你觉得我上手不够快。
张三：老实说，预期上手时间是两到四个月，而你在两个月内就完成了，这很棒。
李四：谢谢。
张三：那现在我们进入具体细节。

正如你所看到的，张三作为管理者先花时间回顾了过去，给绩效讨论设定了背景。接下来，该是看评分和具体差距的时候了，通常来说，绩效评估模板生成后应该要突显自我评分、同事评分以及上级评分间的差距，简单的方法就是各评分项作为行，各个评分人作为列进行并排比较。接下来，看看管理者张三是怎么处理的。

张三：到目前为止，胜任力模型中主要能力项的不同评分间的差距很小，甚至有些不存在，可以看出你的整体表现很强，但这里有个例外，正如你看到的，在有效沟通这一项，你给自己评了 8 分，同事评价是 6 分，而我给评了 5 分。我觉得这里我们有些理解偏差。
李四：是的，我也认为沟通能力我还可以再加强，但是这里的评分差距之大让我惊讶。
张三：嗯，来自于同事的数据和我的观察似乎表明了同一件事情，你的沟通风格比较匆忙和直率，当然，这会让人感觉很真诚，但同时也容易让人感觉有些冷。我们来看看一些同事评价？
李四：好的。
张三：我这里拿一个看看。李四似乎总是很匆忙，在跟其它同事打交道时，对于其他人表现得不是很感兴趣。你知道这种看法吗？
李四：不，说实话，我并不是这样的。额，我的意思是我看到这样的评价我很惊讶，也许我有时候不应该像那样沟通。
张三：你的表现还不错，工作目标达成情况就可以说明，只是在跟同事打交道时，处理的不够好，我相信这是一个你可以改进的领域。
李四：嗯，好的。

以上谈话举例，我们可以看到李四在沟通能力上可以再改进，并且自己也明确了改进的期望。接下来，管理者张三就可以引导李四了解公司内有什么样的机会和方式可以帮助他改进和提升，例如沟通能力培训、沟通能力需要比较强的任务机会等。整体上建议管理者使用引导思考的方式解决问题，下面会有些小贴士来帮助管理者保持绩效讨论的可控和高效。

首先，评分要尽量客观，不要刻意贬低压分。这意味着管理者必须有自己明确的评分和评价，不要受其它因素的影响。另外，如果员工在绩效讨论过程中表现出惊喜，就说明管理者的工作有做的不到位的地方。因为如果管理者在绩效周期内已经正确有效地跟员工沟通了，那员工就不会对评估过程中发生的事情感到惊讶的，或是感到惊讶的部分会很少。

另外一个技巧是，员工的评估中找到一两个他们遇到的，同时也是你之前遇到过的问题，可以简要地告诉员工你的解决方案和改进方法，让员工感觉到你是在帮助他们解决问题，而不仅仅是上下级关系，这样绩效讨论时他们也会更有效地倾听。

最后，在绩效讨论中，员工很有可能会对你提出的讨论点找借口或抱怨，而管理者在处理员工的借口和抱怨时要格外谨慎，因为他们此时的情绪极有可能比较激动。记住对应情绪化的最好的方法就是不带情绪的回应，只是以非常冷静的方式来回应借口，就是听，但是不要做记录，因为这样会让员工认为你接受了他们的借口。

大多数情况下，管理者可以回复，我听到了你所说的，我在做评估时有考虑过这个情况；或者是，承认没有意识到这一点，但是评价不会修改。这里的关键是要明确，反馈的情况接收到了但是评价不会改变。除非管理者收到重要的意外信息，才可能会有例外情况。除此之外，在管理者开始绩效面谈会议前，评估就已经完成无需再修改。这里我们再看看管理者张三如何处理员工李四的一些问题的。

李四）：我觉得人们注意到我的沟通问题，只是因为我是新人，大家还不怎么熟悉。
张三：嗯，10 个月也不算新人了。我想说清楚些，提供反馈的不仅仅团队。我的观察也非常相似，你的人际风格需要改变。实话说，我希望也能收到类似的反馈，帮助我改进，例如我有时过于自信了。

上面的对话示例中，张三没有接受李四的借口，甚至可以贬低自己一点，希望自己也能有类似的反馈，从而来进行技能改进和提升。

总的来说，坦诚地讨论绩效对于任何成功的团队都至关重要，如果你能够使用我们之前介绍过的建议，相信可以保持对流程的控制，不仅会让绩效讨论没那么大压力，也会让绩效面谈沟通会议更有效率，最后确保员工活动公平有用的评价。

思考题

你在最近的绩效面谈会议中，讨论绩效环节是怎么操作的呢？欢迎在留言区分享~

感谢你的收听，我们下期再见！

作者简介

刘俊强（微信公众号：程序员精进），TGO 鲲鹏会会员，现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+ 年以上互联网开发经验，8 年以上技术管理经验。

第130讲 | 刘俊强：必知绩效管理知识之绩效沟通（三）

你好，我是腾讯云资深架构师、TGO 鲲鹏会会员刘俊强，有着 8 年以上的技术管理经验，今天想跟你分享技术管理者必知的绩效管理知识中，关于绩效沟通的话题。前面的系列文章介绍了如何准备绩效面谈会议以及绩效讨论该怎么执行，今天我们要聊的是在绩效评估阶段最为重要的事情，即怎么通过绩效评估帮助员工成长发展。

专注于员工发展

年度绩效考核或年度绩效评估这样的名字如果可以的话，我倒是建议修改成年度绩效讨论，因为绩效讨论这个词是个中性词，非褒义非贬义只是在陈述一个主题或事实。相比较绩效讨论这个词而言，绩效考核或绩效评估这样的词会带来潜在的压力。需要记住的是我们做绩效考核的最终目标是帮助员工和团队发展成长，这个环节的目的是要产生帮助，应该是积极的，而不是消极的或是专注于批评。

绩效考核阶段专注于员工发展，主要需要考虑两个事情，一是能帮助员工或团队进行工作调整，二是能提供支持员工或团队持续发展的工具和资源。

关于工作调整，首先需要考虑如何确定目标的规模，例如服务端开发工程师原先负责 5 个微服务的开发，并且表现良好，你可能希望再分配几个重要的微服务给他。这里需要考虑的是，如果管理者增加了员工或团队工作目标的规模，就会占用他们用于不同类型的发展机会的时间。因此，在考虑对绩效表现良好员工进行工作调整时，需要考虑是扩大现有职责还是发展新的能力。

现有职责的规模扩大很好理解，大多数管理者都实际操作过，接下来，我们要聊聊发展新的能力。这里介绍一个术语“拓展角色”，如果有机会的话，可以通过分配“拓展角色”的方式给员工以新能力的锻炼机会。“拓展角色”代表了一个临时的全新的责任领域，需要管理者以教练的方式进行辅导。如果管理者有目标员工的话，绩效讨论是不错的时机，但需要注意的是，“拓展角色”是属于员工的，因此，只有员工自己真正想要这个角色，这样的机会才有尝试的价值。

另外，除了“拓展角色”这样临时的全新领域的发展机会，管理者也可以跟员工讨论持久性的工作调整，一般是横向变化，例如在不带管理职级的情况下带领两个类似员工。关于垂直方向的变化，即承担当前位置之上的职位职责，也就是晋升，这个建议在晋升环节独立操作，时间和准备上会更为充分，因为晋升不是绩效考核环节的必要输出，反之绩效考核是晋升的基础支持。

前面有介绍到工作调整，工作调整不论是横向调整、垂直调整还是“拓展角色”，作为管理者都应该提供相应的工具和资源帮助员工发展和成长，例如各类成长计划，不同的成长计划对应不同的职级和能力。成长计划一般包括专门的培训和发展计划，针对公司最优秀的人才进行培养提升，为他们下一阶段的职能做准备。

总而言之，绩效评估这个环节是关于员工绩效的评估，但这只是第一步，最关键的是在此之后，怎么帮助员工发展成长为更好的自己。

讨论拓展机会

前面咱们有介绍到“拓展角色”，它实际上是一个推动员工超越他们目前职责和技能的工作机会。通常情况下是临时性的，可以是数月或一年之久。优秀员工成长需要定期尝试些新事物，同时，“拓展角色”也能够帮助企业找到合适的人选执行合适的项目。

在今天的大多数企业中，“拓展角色”被用于高潜力员工身上，一般是用于 VP 和 C-Level 级别的潜在高级管理者。但是“拓展角色”这个概念并非是专属于高级管理者的，我们也可以使用“拓展角色”的方式，帮助员工激发新能力的发展。通过“拓展角色”，管理者将员工有意识且积极地放在一个他们尚未成功的地方，员工将面临风险和新的学习曲线，这种方式不一定会成功，很有可能会失败。因此，管理者需要做两件事情来降低这种风险。

首先，“拓展角色”的机会仅仅只分配给真正非常需要它的员工。这里指的是，如果管理者与员工讨论拓展角色的机会时，对方似乎不确定或是无动于衷，这时就需要慎重考虑他们是否是合适的人员。其次，强烈建议管理者使用最优秀的人才，实话讲“拓展角色”不适合一般或良好的员工，它只适合优秀且非常愿意尝试新事物的员工，对他们而言这是个十分重要的机会。

假设管理者拥有了合适的人选，并且双方都做好了准备，愿意尝试且有信心做到，那么，良好的“拓展角色”是怎么样的呢？实际上有很多可能性。例如，将一位年轻的架构师任命到技术委员会，让该员工参与到公司技术战略的规划过程中去。另外一种常见的例子是，指派员工到陷入困境需要扭转的项目或部门。上面两个例子都能够推动他们现有技能水平的提高，以及帮助他们建立起全新的技能。另外，除了给员工分配或委派“拓展角色”之外，管理者还需要确保为其主要工作提供尽可能多的支持，管理者这时要更多的充当教练的角色，辅导帮助他们成功。

有效地结束

之前的系列文章中有介绍到，在绩效沟通环节中，建议给每位员工提供一个小时的时间，如果管理者不知道如何有效地结束会议，那么会影响后面等待绩效沟通的员工。在此我们不期望绩效沟通会议方可以在双完全友好和谐的氛围中结束，通常情况下都会有双方明确同意的部分和不太顺利的部分，这是很正常的，在阐述完绩效评价后，简单回顾下进展不顺利的部分，坦诚地看待事实情况。

员工、上级对绩效评定进行签字是绩效沟通后对于人力资源部门的输出。在此，有些员工会毫不犹豫的签署，有些员工会质疑绩效评价的公平性，这里需要跟员工申明的是，最后的签字不代表着认可，而是代表着他们收到了绩效评定以及管理者对绩效评分的解释。如果管理者沟通后，员工还是不能认可绩效评定结果，管理者可以告知员工申诉流程，申诉流程的具体情况需要根据管理者所在公司的规定来看，一般情况来说，申诉流程会有时间有效期、对接人信息、申诉所需材料等。

因此，管理者在绩效管理循环期间内做的准备越充分，员工就越不可能对你的绩效评定结果提出申诉。当管理者在绩效沟通时，准备并提供有用、诚实的评定，员工会知道你不仅仅是在尝试评价他们，实际上更多的是想帮助他们取得更大的成功。

总结

作为管理者需要记住，绩效考核和反馈阶段最为重要的事情是帮助员工和团队发展成长，只要秉承这颗初心，相信你会成为让员工信服的管理者。

思考题

思考下，你最近在绩效沟通会议时，跟员工沟通了哪些能够帮助他们发展成长的内容呢？

感谢你的收听，我们下期再见！

作者简介

刘俊强（微信公众号：程序员精进），TGO 鲲鹏会会员，现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+ 年以上互联网开发经验，8 年以上技术管理经验。

第131讲 | 汤力嘉：CTO如何在产品方面进行决策（二）

你好，我是一下科技 CTO 汤力嘉。对于 CTO 而言，优秀的产品决策能力是必需的，在之前的文章中， 我跟大家分享了我在产品决策上的理念和心得，其中的关键点是简单，并分享了简单策略在产品决策中的具体运用，包括删除、组织、隐藏、转移等四个执行策略。

而产品策略制定后的下一步就是验证需求，并具体落地执行，今天就想跟大家分享一下我在这两方面的实践与经验。

验证需求

先来看验证需求，在这个过程中，有几点因素会影响验证结果。

一、调查的局限性
验证需求的做法之一就是做用户调查，而调查结果本身有很多局限性，所以不可以完全相信，我举 2 个大家可能都知道的例子。

案例 1：可口可乐公司曾经推出一种新口味可乐，调查显示，多半用户喜欢这种新口味，于是，可口可乐公司买入多套设备，建立新的生产线，投入新口味的生产中。结果，忠于旧口味的用户开始上街游行，而喜欢新口味的用户又不嫌事大，也参加了游行。最终，可口可乐公司被迫将新生产线全都撤掉，损失巨大。

案例 2：我国内地的茶饮料（比如水果茶、冷泡茶）搬上市场前也做了用户调查，结果显示，人们一致认为要喝泡好的热茶，所以生产商都不敢轻易生产。后来台湾厂商直接把茶当饮料卖，并推入内地市场，结果，统一、康师傅等品牌下的茶饮料就占据了内地茶饮料市场。

二、决策情感
验证需求时，除了需要关注调查结果，还需要关注用户的情感因素。用户是否购买产品，很大一部分取决于他的心理因素。

举个例子，可口可乐与百事可乐的竞争，在 70 年代，百事可乐做了一次可乐口味大调查活动，将可口可乐与百事可乐的品牌隐藏，让用户对二者口味进行投票。结果百事可乐以大比分领先，取得优势。但是这 30 年来，百事可乐的销量却一直不及可口可乐，这是为什么呢？

原因与人的情感有关。在 2003 年，核磁共振研究发现，人类大脑中有一块强化奖赏情感区域，在这块区域中，百事可乐比可口可乐多 5 倍，所以人们会认为百事可乐比较好喝。但为什么用户依然会选择可口可乐呢？是因为只要将品牌告知实验者，实验者的前额叶皮层就会发生变化，强制要求这个人喜欢可口可乐，这就是品牌影响了实验者的决策情感。

三、眼见不为实
我们经常讲眼见为实，但在验证需求时，眼见不一定为实，应该从多个角度出发思考问题。

以英国脱欧为例，英国脱欧后，谷歌排名前 5 的搜索问题都是关于欧盟以及脱欧有什么后果。乍一看问题，大家可能会觉得，投票脱欧的人真无知。但用户数据显示，搜索这些问题的用户大多来自于英国北部，是支持留欧的人，并且年轻人多于老年人。此时，大家会怎么理解呢？

其实，有各种各样的理解方法。我能想到的就有五点，第一，支持脱欧的人本来就知道脱欧后果，所以他们不会去搜索脱欧后果，而支持留欧的人不知道脱欧后果，所以才会搜索问题答案。第二，可能是英国的年轻人不懂，所以搜索用户中年轻人多于老年人。第三，也可能是年轻人更关注时事，所以才去搜索。第四，也可能是中老年人压根不会使用搜索引擎。第五种情况是中老年人根本就没有年轻人多。

所以，对于同样一件事，我们从不同方向去理解，就能够产生多种结果。

四、先入为主
第四点影响需求验证结果的因素是人们容易先入为主，打个比方，听到下面这四句话：1. 在东莞工作的女朋友；2. 大学老师和女学生在一起了；3. 上海丈母娘；4. 开奔驰的妙龄女郎。相信多数人会先入为主，戴着有色眼镜去看待，结果就会误导事实。

那么，如何判断想法是否靠谱呢？我认为可以从五个方面出发：

产品价值，产品的核心价值是什么？它解决了什么问题？这个问题在此产品没有出现之前是怎么解决的？此产品出现后，是否能更有效的解决问题？

目标市场，比如市场的用户存量、用户群体、用户画像、用户消费能力，等等。

市场规模，包括存量的市场和增量的市场，增量市场即发展前景，比如，我们为什么一直在做短视频？是因为我们在 2011 年就预见了短视频的未来发展趋势，虽然过足足 5 年才火起来，但也是押对了。

市场格局，比如市场中的同款或同类型产品有几种形态，每种产品的布局是怎么样的？大公司有没有进来？产业链是怎样的？

竞争优势，这是最重要的一方面，很多时候我们去做一个产品并不是因为产品本身能带来什么，而是先看我们能做什么，有何竞争优势。

确定想法靠谱之后，就该判断该想法是否可行，我们可以从四方面来判断。

切入时机，包括自身的硬件条件、技术能力是否已具备实现想法的能力，对用户感知、用户习惯的洞察是否已经有所培养等。

运营推广，酒香也怕巷子深，所以，我们可能要先想一想，有什么办法能走出这条“巷子”。以小咖秀为例，小咖秀初期选择了一个比较好的推广手段，就是在综艺节目《康熙来了》中介绍小咖秀，然后将电视画面截图，并在图片中贴上小咖秀的下载链接进行推广，随后产生了第一批种子用户。另外，我们还邀请了一些明星帮助推广，结果明星自己先嗨起来了，小咖秀也就迅速被带火了。

量化指标，包括产品进度、人员成本、运营计划等，每一环、每一步都需要制定明确的指标，不断跟进、落实，以降低风险。

风险应对，风险可能会来自各个方面，比如财务方面、法律方面、商标、政府部门等等，所以，需要尽可能的想到应对各方面风险的措施。

最后，确定了产品策略靠谱，又可执行，但为什么还是无法落地呢？在我看来，主要原因有以下四点。

想不清，想法落地的过程中可能会发生改变，这是最伤筋动骨的。

推不动，包括人员、招聘、推广等等，都有可能推不动。

没价值，行动后发现，全量的客户有限，根本没有增量空间，这就是没有价值。

时机不对，比如我在上篇文章中提到的手机处理视频特效的功能，提出这个想法的时候，当时的手机配置还不足以支撑这个功能。

如何执行

相信大家都遇到过这样的烦恼，想法往往能够快速产出，但开发过程中总是存在各种各样的坑，而程序员也没有未卜先知的能力，在执行中难免会出现各种偏差，导致结果与预期相差甚远，甚至在过程中因为想法改变，整个产品推倒重来的情况也不少见。

在此，我先介绍一下屁股理论，我认为一个公司就像人体，CEO 就是人的大脑，产品人员就是人体的胃，我们吃进食物，胃就开始消化工作。经过设计加工后来到屁股，屁股就是程序员，程序员产出产品，并交给运营。在这过程中，如果屁股不工作，人就会中毒死亡，但一切正常的时候，你又会忽略屁股的存在。同样，程序员不工作，就没有产品，而产品质量也取决于程序员。

所以，我认为首先要理解清楚程序员的思考方式，这样才能更好的激励他们，提高效率。程序员思维还是比较特别的，主要有以下几点：

一切都有标准，都可以量化，都可以实现；

认为管理者应该是理性的机器，公平的处理每件事；

以自我为中心，文人相轻，认为自己最牛；

情绪化，高兴就给你加班做，不高兴，才不管你呢；

高薪误区，管理者认为员工的首要需求是高工资，其次是工作稳定、得到晋升等等。但对于程序员而言，首要是被人欣赏，其次是有参与感以及被认同。

如何保证效率

那如何管理程序员，保证他们的工作效率呢？关键在于同理其情绪，关注其需求。

比如，我们会把所有任务拆解成一个个工单，每个工单会有相应的积分，如果工单延误，会扣掉相应积分，如果出 bug，也会扣掉相应的积分，最后汇总成总分榜，排名靠前的同学就会特别有成就感和荣誉感，就会形成一个正向的鼓励。

除此以外，我们还可以借助工具来提升工作效率，比如小咖秀爆发的时候，每天新增两百多万新用户，前端机、数据库、缓存全面告急。面对这种情况，我们借助各种工具和服务，包括借调机器扩容前端机，增加缓存，利用云服务等等，都非常有效，在当天就把这些问题解决了。

如何保证质量

保证效率的同时我们也要保证质量，从技术角度出发，保证质量的关键在于技术功底，技术水平越高，产品质量就越好。

除此以外，我们还要制定赏罚制度，但是所有的罚款最终都要回馈到团队，用于团建或者其他活动项目。其实，最初我们也担心这样做可能会打击大家的积极性，但后来发现程序员比较较真，只要你有一套完善的系统，能公平的反映赏罚情况，他们是很乐意接受的，并且反而更激发了战斗力。

写在最后

简单的去做一件事情，并将这件事做到极致，是我这两期内容想表达的主要思想，也是我做产品的关键思路。另外，服务是全世界最贵的产品，任何产品都离不开其背后各个团队的付出。作为 CTO，我们要在人、钱，事等方面深思熟虑，你用错一块钱，可能要损失两块钱，如果选错人，可能会影响整个团队。最后，唯一不变的就是变化。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

汤力嘉，一下科技 CTO，负责旗下秒拍、小咖秀、一直播等产品的研发及团队管理工作。历任酷 6、暴风技术总监，在直播、p2p、视频特效等领域拥具有丰富的行业经验。

第132讲 | 徐函秋：转型技术管理者初期的三大挑战（一）

你好，我是小米大数据团队基础数据与用户画像组负责人徐函秋，目前主要负责小米用户画像、行为标签库、ID-Mapping 等项目的建设与研发工作。今天我分享的主题是“转型技术管理者初期的三大挑战”。对于管理这件事情，因为每个人的经历不同，所处的环境也不同，所以是“仁者见仁，智者见智”的，我今天分享的内容可能更适合刚刚成为技术管理者，和有志于将来成为技术管理者的同学。

工程师生涯中必做的决定

我相信大多数程序员在工作几年，成为团队骨干后，都会面临这样的选择，就是要么继续走技术路线，坚持做研发，要么成为团队的技术管理者，承担更多技术管理的责任。

对于个人贡献者和技术管理者这两个角色，不同的场合有着不同的称呼，比如个人贡献者又叫码农、技术开发，而技术管理者又被称为 Manager、小组 Leader 等等。另外在不同的公司，这两类岗位也有着不同的等级序列，你可以选择继续做个人贡献者，走 T 序列或 P 序列，你也可以选择 M 序列，成为技术管理者。

我个人认为，不论是选择继续走技术研发路线，还是选择技术管理路线，包括在什么时间、什么阶段选择，都没有绝对的好坏，只有适合自己的才是最好的。

那么，我们为什么要成为技术管理者呢？每个人的理由可能都不一样，有人说可以管人，有人说可以提薪，有人说自己更擅长与人打交道，而我选择成为技术管理者的原因，主要有两点。

第一，可以突破个人贡献者的天花板。因为我作为一名研发工程师，可能贡献最多的就是优化用户画像中提取引擎的效率，支持业务各种标签的挖掘需求，比如帮助广告商挖掘出小米用户中有多少人是鹿晗的粉丝等等。而当我成为一名技术管理者以后，就可以带领团队，支持全公司精准运营的若干需求，更好地帮助公司内部业务实现增长，这是之前作为个人贡献者时很难做到的事情。

第二，结合自身的职业规划和目标，提升个人能力。因为对我来说，未来如果有机会，可能还想和朋友一起创业，一起做一些有意思的事情。但那个时候可能就不仅要求自己有扎实的技术功底，还需要有良好的项目管理能力、团队管理能力、沟通能力、演讲能力等等。而成为技术管理者，就可以在实践中锻炼这些能力，对个人成长有很大的帮助。

但是，做一名优秀的技术管理者真的很不容易，可能会遇到各种各样的问题。而我就将自己遇到的一些典型的问题总结分类为三方面。

转型初期将面临的三类挑战

一、角色转型引发的矛盾
当我还是个人贡献者的时候，我的核心竞争力可能就是扎实的工程能力、编码能力，以及对机器学习、数据挖掘等算法和使用场景的掌控能力等等。而成为技术管理者以后，我发现白天除了开会，还需要做跨团队交流，比如跟业务对接、了解业务需求等，另外还需要面试新人、与组员沟通等。因此，问题就出现了——每天面对各种事务性工作，自己的核心竞争力下降了怎么办？

我刚成为技术管理者时，几乎每天晚上九点多钟，大家都下班了，我才能回到工位，完成自己的开发工作。即使如此，在一些项目开发的关键节点上，它的开发进度可能还是会卡在我这里。因此，我每天都感觉自己做了很多事情，自身能力却并没有提升。

后来我逐渐把自己的开发工作缩减，交给小组中的其他技术骨干去完成。但同时我又担忧，自己写代码的时间越来越少，技术退化了怎么办？

恰好我在面试别人时也遇到了这个问题，很多 8 年至 10 年工作经验的面试者都非常优秀，各方面能力都很突出，但由于他们已经脱离一线有一段时间了，所以在考核技术能力时没能过关。我认为技术能力是一名技术管理者的基础能力，如果技术能力不过关，我也没办法给他 offer。

这件事情引发了我的反思，如果未来自己要走出去时，会不会碰到类似的困境？

除了事务性工作与技术工作的矛盾外，还有思维上的改变，之前在研发岗位上可能只需要做好自己份内的工作就足够了，但现在带领团队的话就需要不断思考，做哪些事情能够产生价值，如何做才能将价值最大化等等。

举个例子，小米在每个季度初都会制定 OKR，在我刚成为技术管理者的时候，每次制定 OKR 时都会思考，在未来的一个季度内，我们小组要做哪些事情，比如支持多少个业务、挖掘多少个标签等等。但我所思考的这些内容其实与上级主管的关注点并不相符。其实上级主管并不太关心工作内容的细节问题，他们更看重工作成果，比如为公司节约了多少成本，提升了多少收益，或者是使团队工作效率提升了多少倍等等。

所以，在制定 OKR 时我就需要考虑得更全面，不仅要从自身角度与团队角度出发，还需要兼顾公司业务所涉及的各方面问题。

二、在项目管理能力上的挑战
一名优秀的技术领导者，需要具备良好的项目管理能力，但我在实践的过程中发现了两个问题。

第一，之前作为技术骨干，我们可以很好的完成工作任务，甚至超预期完成任务目标。那现在要领导 15 人的团队来完成历时两个月的项目，如何能保证按时且高质量交付呢？

第二，对于安排给其他团队成员的任务，因为责任边界不明确，最终导致项目延期交付，面对这样的问题该怎么办呢？

举个例子，领导交给小王和小张一个任务，让他们一起来完成，但没有将责任具体落到某个人上，最后任务交付结果并不理想，小王和小张都认为是对方的责任，这就是责任边界不明确的问题。

三、在团队领导能力上的挑战
一名优秀的管理者必须具备良好的团队领导能力。在《技术领导之路》这本书中，对领导力的定义是，“所谓领导力，就是创造一个环境，让所有的人都可以发挥出比单干时更大的价值，并不断成长”。但是我们从技术岗转为管理岗之后，并没有人告诉我们该怎么做才能创造出这样的成长环境。我们都是依靠本能并通过不断地学习，在走了很多弯路之后，才探索出了一些方法。

目前在领导力方面，我之前主要遇到了三个问题。第一个问题是，当团队成员遇到困难的时候，如何能及时感知，并有效的帮助其解决问题？

举个例子，去年我们小组加入一位同学，当时，我将一个用户反馈分类的需求交给他解决。就是当小米手机有若干故障的时候，用户会在各种渠道上反馈，我们根据用户的描述，将问题分类为相机问题、主板问题等等，并训练出一个相应的机器学习模型。

因为这个工作不在主线业务内，所以我给了他充分的时间。结果一个月后，他找我沟通，表示想离职。我当时就懵了，具体沟通后才发现，他其实不太想做这件事情，另外，他所做的工作并不是我们团队的主线业务，跟其他团队成员也交流不多，没有融入团队。所以，面对类似这样的问题，技术管理者该怎么办？

第二个问题是，团队成员不断增加，但自己却越来越累，团队例会效率越来越低怎么办？

随着业务越来越多，团队加班就会成为常态，所以我们需要招更多人。但新成员加入后，却感觉自己更累了。因为之前只需要跟五、六个组员讨论工作，打磨工作成果的品质。而团队成员越多，所要花费的心力与沟通时间就越多，这个问题又该怎么解决呢？

第三个问题是，当团队成员之间发生矛盾时，比如 A 会跟我抱怨 B 的问题，而 B 也会吐槽 A 不懂协作。那该如何沟通，才能协调他们之间的矛盾呢？如何解决问题，才能不影响团队的工作效率呢？

小结

在工程师的职业生涯中，一定会面临一个选择，或成为资深技术人，或从技术转型管理。对于后者，我总结了我目前遇到的三类挑战，即角色转型引发的矛盾、在项目管理能力上的挑战、以及在团队领导能力上的挑战。受限于篇幅，本文只谈了问题与挑战，我会在下一篇文章中，根据自己的实践经验，讲讲我对这三类挑战的应对方法，欢迎持续关注。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

徐函秋，现为小米大数据团队基础数据与用户画像组负责人，目前主要负责小米用户画像、行为标签库、ID-Mapping 等相关项目的建设与研发工作，为 MIUI、金融、新零售等小米公司核心业务提供大数据相关技术支持，帮助业务团队快速搭建多维分析平台，实现精准运营。加入小米公司之前曾在中科院自动化研究所担任研发工程师，期间参与了实验室的多个横向、纵向项目，并多次参加相关的国内、国际数据挖掘竞赛。

第133讲 | 徐函秋：转型技术管理者初期的三大挑战（二）

你好，我是小米大数据团队基础数据与用户画像组负责人徐函秋，在上一篇文章中，我分享了转型技术管理者初期遇到的三大挑战，即角色转型引发的矛盾、在项目管理能力上的挑战、以及在团队领导能力上的挑战。那么该如何应对这三方面的挑战呢？今天我会分享自己在过去的两年时间中，针对这三方面挑战的一些实践过程与破解之法。可能不是最好的方法，因为还没有形成完整的一套理论，但它们的确是有效的，也是我一直在践行的。

第一个挑战：角色转型引发的矛盾

其实，这个挑战下遇到的问题大多与个人相关，在与上级和同事交流过后，我认为最直接的办法就是明确技术管理者新的核心竞争力，然后拉伸视野，以全局视野思考问题。

明确新的核心竞争力

之前做码农的时候，我的核心竞争力是较强的编程能力以及算法的掌握程度。但作为技术管理者，我认为核心竞争力应该转变为综合能力，比如高效沟通能力、项目管理能力、团队建设能力，以及对技术方向的把控能力等等。所以，对于技术管理者而言，真正重要的并不是自己又掌握了新的技术，而是能带领整个团队完成更多有挑战、有价值的项目，以项目的产出结果为导向。

另外，在明确了新的核心竞争力之后，我在思想上也发生了转变，因而解决了我在上一篇文章中所提到的问题——技术管理者到底该如何衡量个人的成长。

换一个角度来讲，如果我们做好时间管理，合理分配每天的工作时间，就不会感觉没有成长，而是变成一种积累。我们可以把每一天都当作一种锻炼，思考怎样才能够更高效的与组员沟通，或是向业务团队了解需求。目前，我每天会拿出 20% 的时间与业务团队进行沟通，再花 30% 的时间与组员交流，剩余 30% 时间用来做研发工作，工作效率也较之前有所提高。

全局的视野与思考

技术管理者是否拥有全局的视野和思考方式很重要，用刘建国老师在《技术管理实战 36 讲》中的一段话来说，“当你还是一位工程师时，你是技术的操作者和实现者，所有的技术服务都从你的手中诞生；而在成为一个越来越成熟的管理者的过程中，你越来越少地直接去实操，慢慢变成了技术的应用者，你需要的是把这些技术服务装配成更大的服务和产品。”

举个例子，假如我是一名技术工程师，可能我关心的是一个电子芯片的实现，而如果我是一名技术管理者，我就会关心如何利用这些芯片，组装一部手机或其他设备。

个人贡献者更关注 How，也就是实现过程的细节与具体的解决方案，而技术管理者则需要拥有大局观，更关注 What 和 Why，思考我们要做什么和为什么这样做。总而言之，我们需要在之前的基础上把视野进行拉伸，以全局性的视野把控、解决各种问题。

当我拥有了全局视野，每个季度制订 OKR 时也就相对轻松了，OKR 是 Objectives and Key Results 的缩写，即目标与关键成果。它可以有效地帮助我们明确公司和团队的目标，并明确每个目标在达成过程中的可衡量的“关键结果”。

经过了之前的这些历练，我还学会了“以终为始”。以前我会思考团队要做哪些事情，比如支持多少个需求等等。而现在我的思考方式是，年底我们应该如何汇报这一年的成果。以结果为导向，明确团队的目标，再将团队关键指标进行拆分，具体落实到每一个子任务目标上。

第二个挑战：项目管理能力

项目管理流程

我们以搭建精准运营平台，将营销效果提升 100% 为例。要想达到这个目标，需要做很多事情，比如投放平台的开发、推送数据的接入、闭环打通、CTR 预估等等。而且这个项目还需要公司内部其他团队的协助才能完成。作为这个项目的负责人，如何保证能带领团队及时且高质量地完成项目目标呢？实际上，我们可以从四个步骤入手来梳理项目流程。

第一步，将目标、任务进行拆解。例如，创建 WBS，把项目工作分解成具体的、易于管理的子任务。我们一般会要求每个子任务都遵循 SMART 原则，即明确具体的、可衡量的、可达到的、相关的、有时限的，即每个子任务都是较明确且可衡量的，与目标相关并在时间限制内能够完成的。

第二步，分配任务。当任务拆分到足够详细时，我们就可以把它分配给团队中各个指定的负责人，让各负责人对这些模块做进一步拆分，再分配给团队内相关的其他成员，并对每个子任务和结果作出时间预估。

第三步是项目协调与追踪。我们可以用甘特图将每个小项目以时间轴的形式排列出来，从中可以看到每一个项目的关键节点，如果项目进度出现问题，我们能够及时找到原因，从而去协调、追踪、推进。

第四步，总结、复盘。当项目完成之后，我们需要及时进行总结、复盘。例如，一个子项目延期了，就要找出延期的原因是什么，如何改进。再如，一个子项目完成得很好，那么下次再做类似项目时，我们是否能够复用该项目的成果或经验等等。

另外，对于任务的分配与跟进，我们也需要注意三点。首先，需要清楚的表达这项任务的目标和分工安排，将责任落实到人，最好通过邮件进行沟通，避免出现责任不明确的问题。其次，二次核对，明确下属对该任务的理解是否与你一致，这一点对于新同学来说尤为重要。最后，我们需要定期跟进、沟通，比如组织晨会、周会等例行会议，这样可以及时发现问题并快速做出调整。

项目管理工具

在工作中，我们用到的项目管理工具主要有三个，就是甘特图、Teambition 和 Scrum。

我们用甘特图去体现一个目标以及分解的各个子任务，用 Teambition 可以看到每个团队成员的工作事项与工作进程，而且还有一个好处是，在评职和提薪时，也可以从 Teambition 中看到这个人过去半年或一年的工作内容。

对于 Scrum，我们其实用的比较少，但在我们小米大数据团队内，有多个小组都在使用 Scrum。它的开发粒度可以控制到小时，相比 Teambition 以天为单位的进度，Scrum 所体现的进度非常细致。

举例来说，如果使用 Scrum，假设一个项目有 5 人共同参与，每人一天工作 8 小时，那一周大概有 200 个工时，一般情况下我们会制订一个为期两周时间的冲刺计划，再将计划内的阶段性目标进行拆分，把每个子任务分配给相应的组员，并评估完成时间。

因为 Scrum 能具体到小时单位，所以我们在每天例会上就可以有效地同步每个子任务的进度，子任务负责人也能清晰地看到各自的完成进度，如果子任务负责人某天有事请假，那他在之后的工作中会非常清楚这个任务的剩余可用时间，然后再自觉地追赶进度，直至完成目标。因此，Scrum 可以有效地帮助组员明确目标，更加聚焦于进度冲刺，从而高效地完成阶段性的任务。

第三个挑战：团队领导能力

针对团队领导能力的问题，我主要完成了三方面的努力。

第一，打造团队良好的技术氛围。比如每周五组织一次技术分享，由一位组员分享自己的经验。这样组内轮流，每位组员大概每隔三个月时间会做一次分享，分享的前半段是对自己过去三个月工作的总结，后半段的分享内容则要聚焦在一个关键技术点上。

我们也会成立技术兴趣小组，或定期邀请公司外的技术大咖来访交流。另外，北京有很多线下的技术分享活动，我们也会鼓励组员多参加。总之，在做好工作的同时，我们团队一直秉承着创造分享、共同成长的理念。

第二，关于团队梯队建设的思考和实践。随着团队内人数越来越多，我发现自己越来越累。开例会时，汇报工作的效率也越来越低。针对这个问题，我对团队结构做了相应的调整。

有理论提出，6 人小团队的效率最高，人数再多效率就会下降，因为我们没有办法清晰地了解到每个人的工作内容和进度，当他遇到问题时，其他人也无法很有效地协助解决。根据这个理论，我将团队的定位与方向划分为三个方面：第一是用户画像标签的挖掘，第二是支持各业务团队的报表需求，第三是数据治理与数据仓库建设。然后，从团队中挑选出技术能力强、工作年限长且有意愿担当中坚力量的组员，让其带领五至六人的小团队负责某一方面的具体工作。这样就有效地构建起了团队梯队，之后再进行沟通或推进时就比较高效了。

第三，一对一交流。这一点非常重要，也是我曾经历过的惨痛教训。定期与团队成员一对一交流，可以增进彼此之间的了解，使我们能够及时感知团队与团队成员目前遇到的问题。现在我每个月都会与一位组员进行单独交流，每次半小时左右，除了会聊一些工作方面的困惑外，也会聊一些关于职业规划及软技能学习方面的话题，并给予每位组员一些建议。

写在最后

怎样才算是一位出色的技术管理者呢？我跟自己的主管和下属交流之后，结合自己的思考与沉淀，总结出四点：
1. 能明确团队的定位与目标，可以帮助团队成员更好的成长；
2. 拥有较好的项目管理意识，能带领团队及时产出高质量成果；
3. 沟通能力良好，在团队中能构建良性循环的技术范围和工作环境；
4. 具备深厚的技术功底，关键时刻能带领团队攻坚或克服困难。

除此之外，我认为作为技术管理者，仍然不能完全放弃技术，还是需要投入足够多的时间去了解前沿技术，关注关键技术。这样，团队的成员才会更加信任你，同时也有助于你在团队中培养出某个领域的技术能手，打造一支多元化的技术团队。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

徐函秋，现为小米大数据团队基础数据与用户画像组负责人，目前主要负责小米用户画像、行为标签库、ID-Mapping 等相关项目的建设与研发工作，为 MIUI、金融、新零售等小米公司核心业务提供大数据相关技术支持，帮助业务团队快速搭建多维分析平台，实现精准运营。加入小米公司之前曾在中科院自动化研究所担任研发工程师，期间参与了实验室的多个横向、纵向项目，并多次参加相关的国内、国际数据挖掘竞赛。

第134讲 | 刘建国：我各方面做得都很好，就是做不好向上沟通

前百度最佳经理人，果见管理工作坊创始人刘建国老师在他的《技术管理实战 36 讲》专栏中，深入透彻地讲述了“管理沟通”这个主题，其中“向上沟通”一文中，分享了技术管理者们在与上级沟通时常见的坑与痛点，以及对应的解决思路与方案，非常有参考价值，在这里分享给大家。

我曾对超过 500 位技术管理者进行过调查，统计结果显示，向上沟通是技术管理者们最挑战的管理主题之一。那么具体是哪些事情，让管理者们感到头痛呢？

基于上百个关于向上沟通的问题反馈，我发现有如下四类问题是最为普遍的。

第一类：和上级能不聊就不聊。主要说法有：

“上级太忙了，我的事情好像没有那么重要，等他闲了再说吧。”

“找不到上级，他很少在工位，每次碰到他都急匆匆地走开，没机会聊。”

“把领导交代的工作做好就行了呗，有事没事找领导聊啥，最讨厌有事没事讨好领导！”

“总是觉得和上级有距离感，很难聊到一块儿。”

“每次见了上级说话都不利索，能用邮件沟通就写邮件吧。”

第二类：拿捏不好该不该和上级聊的分寸和尺度。主要说法有：

“最近取得了一个不错的成绩，要不要和上级说一说呢？”

“感觉自己离技术越来越远，有些焦虑，是不是可以把上级当作朋友来聊聊呢？”

“某项目很可能会 delay，上次和领导打过招呼了，他不置可否，随着形势越来越严峻，我要不要再跟他说一次呢？”

“我和合作者有些隔阂，不知道适不适合告诉上级。”

“上级招我们来是解决问题的，而不是来给上级制造问题的！”

第三类：很难领会到上级的意图。主要说法有：

“上级告诉我这个项目要加紧了，可是要加紧到什么程度呢？”

“上级把这个工作交给我负责，却又安排别人参与进来，这是不信任我吗？”

“上级让我去做一个调研，也没有说什么时候要结论，到底急不急呢？”

“老板到底在想什么呢？他最近突然不找我了……”

第四类：如何影响上级的一些观点和决策。主要说法有：

“老板常常有不靠谱的需求和新想法，我就不知道该如何柔和又不失礼貌地拒绝。”

“上级对项目进度的需求总是很高，如何管理上级的预期呢？”

“有个项目需要向领导申请增加人力，如何跟他说呢？”

“上级总是不采纳我的建议，有何良策吗？”

“上级不懂业务，还喜欢拍板做决策，怎么应对？”

怎么样，上面四类问题，有覆盖到你的情况吗？

由于向上沟通永远是你和上级的“私事”，所以我们无法给出一个普遍适用、一劳永逸的标准答案，也无法穷举所有的向上沟通的场景。但是，我们来逐个分析一下这四类最集中的问题，也不失为一个好的探讨方法，不是吗？

第一类，关于“和上级能不聊就不聊”。你不难发现，无论是所谓的“上级太忙了”，还是“找不到上级”，甚至干脆认为就不该和上级沟通，归结起来，都是没有意识、意愿或能力和上级建立良好的“沟通通道”。

那么如何建立良好的沟通通道呢？你可以从以下四个方面来着手和审视。

第一，沟通意愿。这是基本前提。作为一名工程师，你不主动和上级沟通问题也不大，因为上级一般会有意识地主动和你沟通。但是，如果作为一名管理者，你还不主动和上级沟通的话，那就相当于已经上大学了，还要家长和老师逼着做作业一样。又如何指望你能带领别人往前走呢？

实际上，在我和中层管理者聊他们对下属的期待时，他们大多都会明确表示，希望我和初级管理者们澄清一个事情，那就是：“上级默认是需要管理者们主动向上沟通和反馈的，而非默认不需要。”

关于沟通的意愿，你可以首先审视一下你的角色：你是一名工程师还是一名管理者？然后再审视下自己的初衷：你是为了自己而沟通，还是为了团队去沟通？通过问自己这两个问题，让你的角色给你沟通的力量和动力。

第二，事务特点。即，根据事务的特点，比如是否重大、是否紧急、是否敏感、是否正式等，来确定沟通的方式和频次。这很容易理解。

第三，沟通风格。如果说审视事务的特点，是根据“事”来选沟通方式，那么审视沟通对象的风格，就是根据“人”来选择沟通方式。探讨沟通风格和管理风格的工具比较多，比如大家都熟悉的 DISC，以及盖洛普的“四大优势领域”等，如果感兴趣你也可以去了解和学习一下，核心是根据沟通对象的风格特点，来选用你们更高效和易接受的沟通方式。

第四，信任关系。如果说前面提到的沟通意愿、事务特点和沟通风格，都是为了鼓励你主动加强沟通的话。那么对于你和上级信任关系的审视，就是让你看看，是否可以简化沟通。比如你原本需要长篇大论的汇报，对于默契度很高的上级，可能也就是一条消息的事儿；你原本需要多次沟通的问题，对于信任度很高的上级，可能只要简单一句话，甚至都可以免掉沟通。

所以，你需要花多大精力去准备沟通，很大程度上取决于你和上级的沟通通道的品质。也就是前面的文章中我们提到的信任和默契。信任决定着你们沟通关系的稳定性，默契代表着你们沟通关系的效率和性能。

好了，你如果从沟通意愿、事务特点、沟通风格、信任关系盘点下来，还是不需要和上级去沟通，那么这种不沟通就是你有意识的不沟通，它可能带来的破坏性和损失也就可控了，这和消极的不沟通，是两码事。

第二类，关于“拿捏不好该不该和上级聊的分寸和尺度”。我曾经在课堂上做过这个练习，把这些问题作为候选清单，让管理者们选出他们认为需要沟通的选项，结果大家给出的建议五花八门。如果我是个管理者，听到这么多建议，估计会更晕了。

为什么不同的管理者的看法会有这么大差异呢？原因是，每个人在评判“该不该聊”的时候，都是基于自己的管理常识（common sense），而每个人在和不同的上级打交道的过程中，形成的常识是不同的，所以会给出不同的答案。

在我看起来，大多拿捏不好“该不该聊”这个问题的情况，都是由于还没有厘清自己想通过这次沟通拿到什么，即沟通的目的和初衷不清晰。很多管理者甚至不清楚该如何来描述自己的初衷。

我这里给出一个参考：沟通总体上有四个目的，分别是建立通道、同步信息、表达情感和输出影响。而你和上级想要沟通的目的，也跳不出这四个，只是你需要明确“就什么事”达到上述四种目的中的一个或几个。

比如我们来看前面的案例：

“最近取得了一个不错的成绩，要不要和上级说一说呢？”这时你可以问下自己：“我是想就此向上级表达我很有成就感？”

“感觉自己离技术越来越远，有些焦虑，是不是可以把上级当作朋友来聊聊呢？”这时你可以问下自己：“我是想就此寻求上级的支持和帮助，成功地让他给我一些建议？”

“某项目很可能会 delay，上次和领导打过招呼了，他不置可否，随着形势越来越严峻，我要不要再跟他说一次呢？”这时你就可以问下自己：“我是想就这个问题再和他做一次信息同步，如果有可能，我会进一步说服他给我提供一些资源和支持吗？”

……

在这类问题上，我们无法去评判哪个目的更重要，或者更应该和上级聊，因为我们不是当事人，只有当事人自己才最清楚这个目的对他来说意味着什么。所以，我唯一能做的，就是给你这个方法帮你厘清沟通的目的，至于每个目的有多重要，你还可以问自己两个问题：

1. 这次沟通能给你带来什么价值？
2. 这次沟通能给上级带来什么价值？
然后，你根据自己的目的，做出自己的选择和判断吧！

第三类，关于“很难领会到上级的意图”。对于沟通意图的领会，其实就是对于信息的无失真传递和接收。但是你知道，由于每个人都有自己一套独特的认知体系，所以对于同一个概念的理解都会不同。那又怎么可能做到无失真的领会呢。

相信你也听过这样一个说法：看似是两个人之间的沟通，其实至少是“四个人”之间的对话，哪“四个人”呢？也就是：你想表达的、你实际表达的、对方听到的和对方对于听到内容的理解，这其中每一步传递都会造成失真，所以很难领会到对方的真实意图也就情理之中了。

那么如何降低这种失真所带来的沟通误差呢？我的解决方案是：通道品质足够高的话就靠沟通通道；如果沟通通道品质不高，信任和默契程度不够，就需要靠沟通工具来对齐了，沟通层次图及“3F”倾听是个不错的工具。

另外，用一些“回放”的句式来确认，也是个好方法，比如你可以用下面的话来回放和复述你所听无误：

“你是不是这个意思，……”

“你看我理解的是否准确，……”

可别小看它，在沟通重要的事务，以及和不熟悉的人沟通时，这个小技巧能帮你避免大的沟通偏差。

第四类，关于“如何影响上级的一些观点和决策”。这是向上沟通中的一大类需求，无论是“希望上级接受自己的建议”或者“拒绝上级的不合理需求”，还是“调整上级的预期”或者“说服上级给予资源和支持”，归结起来都是让上级听从自己的看法和方案，即把自己的认知和期待输出给上级。所以，这类需求其沟通的目的就在于“输出影响”。

为了达到“输出影响”这一目的，你可能会根据上级的风格去选取合适的沟通方式，根据上级的关切去选取合适的内容和呈现逻辑，并根据上级的状态去选取合适的沟通时机，等等。我想说，这么做都没问题，而且有时会很奏效。可是，既然这个问题能够成为管理者们普遍头疼的事情，说明这些效果是有限的，因为问题还是依然棘手。

那么，如何才能有效地对上级实施影响呢？我给大家用下面的冰山模型做一个提示：

“说服影响”的冰山模型示意图

从上图你不难看出，说服一个人时，沟通技巧是在“术”的层面起作用；而对说服效果影响更大的因素，却是水面下的冰山，即“势”的部分，也就是你对他的影响力如何。

当你对他的影响力很小的时候，你的技术和方案再优秀，影响力也是非常有限的。举个例子，对于一个完全相同的建议，一线工程师提给 CEO，和 CTO 提给 CEO，极有可能是完全不同的结果。究其原因，就是你们两个对于 CEO 的相对影响力差别是很大的。也就是说，如果你要想有效地对上级实施影响和说服，你的影响力是至关重要的。

那么，该如何盘点和提升自己的影响力呢？我们之后的文章中再来继续探讨。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

刘建国，前百度最佳经理人，果见管理工作坊创始人，TGO 鲲鹏会会员，清华大学高级工商管理硕士（EMBA），百度学院优秀培训讲师，埃里克森国际教练学院教练、盖洛普优势教练，国家认证职业生涯规划师。刘建国有着 10 年的技术团队管理经验，一直专注于对技术新经理的辅导和培养，并创办了“果见管理工作坊”，培训过数百位技术管理者。

第135讲 | 钮博彦：软件研发度量体系建设（一）

你好，我是美团高级技术经理钮博彦，主要负责美团点评研发工具栈的建设。我今天想跟大家分享的内容是，我们作为平台团队与业务线团队在软件研发度量中的实践及思考。我将从三个方面展开内容，第一，度量的意义；第二，研发度量体系；第三，度量平台建设。

度量的意义

为什么需要度量呢？因为我们在研发过程中总会遇到各种各样的问题，比如下面这三个典型问题：
1. 为什么我们做的产品与用户的期望总是存在差异呢？
2. 市场需求日新月异，这个功能可能还没开发，需求就已经变化了，对此，我们该如何提高团队的反应速度呢？
3. 现在的产品质量到底怎么样，为什么 bug 永远修不完？

这些问题都是我们在研发过程中经常遇到的，那我们应该如何解决这些问题，使团队更专注、更有效率、更有质量呢？这就是度量的意义所在，我们可以将它总结为三点。
第一，让目标更明确，比如让大家在项目开始时、研发过程中、项目结束后，对目标有共同的认识。
第二，让现状更清晰，度量可以告诉我们现状如何、效率如何、质量如何、流程如何以及问题所在。
第三，让改进更精准，关于如何完善质量流程、体系化研发过程的方法，我们并不缺乏专家学者与著作观点，那怎样找到适合自己团队的观点呢，就需要通过度量来实践。

研发度量体系

整体的研发度量体系可以从三个维度来考量：即价值、效率、质量。

一、价值

这里的价值，指的是我们要做正确的事，而不是有效率的做一些错误的事情。以此为出发点去架设研发度量体系，我们就可以思考三个问题，第一，怎样度量我们的团队正在做正确的事？第二，既然明确了正确的事情，我们怎样以最高效率交付它？第三，我们既做了正确的事，又很有效率，那交付是否符合我们的预期，符合用户的预期呢？

可能每个公司都有自己的价值指标体系，但整体可以分成两大类，就是商业价值和技术价值，每一类又可以细分为可度量价值与不可度量价值。

商业价值的可度量价值包括钱、订单量、DAU、转化率、停留时间等；不可度量价值则包括影响力、美誉度等。

技术价值的可度量价值包括 QPS、可用性、响应时间、故障恢复时间等；不可度量价值则包括技术竞争力等。

总而言之，不论是宏观的项目还是微观的产品，都会根据不同场景制定不同的度量指标，再根据这些指标，开始研发流程，并在过程中不断迭代，使交付结果越来越好。

举个例子，我们要做一个产品，开始立项时，定了一堆项目目标，比如 DAU 增长目标、订单量目标、技术目标等，跟上面提到的价值度量指标相关联。然后进入功能设计阶段，为这个产品设计了 N 个功能，以其中的某个功能 X 为例，接着就进入到功能 X 的研发流程阶段，包括评估与设计、开发与测试、发布上线、反馈与复盘等。

我们在流程实践上的创新之处在于，我们会把项目目标和需求目标相关联，将项目目标作为需求设计的目标之一，从实际结果看这个需求为整个项目目标分担了多少指标，比如做完这个需求，我们可以增长多少的订单量等。

其中，反馈与复盘特别重要，在需求上线之后，可能一周或一个月，我们就需要进行复盘，来判断它到底有没有达到预期。我接触的很多团队都会将复盘放到项目结束后，但我觉得在需求设计过程中进行复盘也很重要，相当于定期追踪。

因此，我们可以把整个项目流程分为三个阶段，即事前计划、定期追踪、事后复盘。这样做能带来什么价值呢？第一，我们所有的需求都是从价值出发，项目的所有参与人都明确目标，能够提升成就感；第二，拆解高价值需求，更早交付，提升 ROI；第三，把控需求质量，减少“三拍”需求，降低部门浪费。

二、效率

当我们确定价值以后，就需要考虑如何有效率的交付这些价值，我们来看下面这张交付周期图，这是一个非常典型的技术研发流程，包括需求评估、需求设计、待开发、开发、联调、待测试、测试、发布等环节。

那我们如何度量效率呢？有两个核心指标，一是吞吐率，二是交付周期。

首先来看吞吐率，吞吐率就是在单位时间内，团队能够交付多少产出。而对于产出的衡量，大家也是各有各的看法，有些团队以需求个数或故事点数来衡量，有些团队以价值来衡量，比如这个团队在一季度内为公司增收的盈利等。

我们可以从多个纬度出发综合衡量产出，因为单个纬度衡量可能会有不准确的情况。举个例子，假设张三一年写了 1000 行代码，李四一年写了 800 行代码，那张三一定比李四的效率高吗？不一定。再假设李四做了 20 个需求，张三做了 10 个需求，李四的效率一定比张三高吗？也不一定。所以，通过综合纬度衡量，可以更加确保对于吞吐率的度量结果的准确性。

再来看交付周期，顾名思义，就是一个需求从提出到上线所用的时长，可能有版本交付周期、需求交付周期、故障修复周期等等，这些都属于交付周期的范畴。

明确了效率的两个核心指标，下面我们来看如何操作能够帮助我们更好地度量效率。

我们在交付周期的衡量中用了两个典型的项目管理工具，一是累计流量图，帮助我们定位瓶颈。如下图：

这张累计流量图的横轴是时间，纵轴是需求个数，我们可以对照某一个切片来看这一天处于各个状态的需求个数，而红色区域和蓝色区域就是我们团队的瓶颈，我们大部分需求都是卡在这样的阶段。

二是价值流程图，它可以告诉我们，需求卡在每个阶段的平均时间。如下图，从这张图中可以看到，我们在待处理阶段与开发阶段停留的时间比较长。

综合累计流量图与价值流程图，我们能够得知几个常见问题：
1. 需求阶段，需求质量差，需求评估设计时间过长等。
2. 测试阶段，测试数据、环境准备成本较高，自动化测试率低等。
3. 开发阶段，手工重复的工作很多，联调时间长，代码质量差等。

除了上述 3 个问题，可能还有一些整体的人员瓶颈，比如开发人员少，待开发排序的时间就长，类似这样的问题我们可能会在人员结构上进行调整，或者是提高大家的技术能力等等。

总而言之，从效率这个维度来看研发度量体系，我们主要可以获益三点：第一，识别团队瓶颈，优化短板，减少资源浪费；第二，缩短交付周期，提高吞吐率，提升市场反应速度；第三，对团队产能预估更准确，提高团队工作幸福度。

最后，由于篇幅受限，今天就主要分享度量的意义和研发度量体系的前两个维度，即价值和效率，关于研发度量体系中的质量指标以及度量平台建设，我会在下一篇文章中继续分享。欢迎持续关注。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友。

作者简介

钮博彦，美团高级技术经理，负责美团点评整体的研发工具栈建设。曾就职于微软中国、雅虎北研、唱吧等公司，从事系统开发、DevOps 和质量保障等相关工作。一直专注于提升研发整体质量与效率，及其流程和平台建设。

第136讲 | 钮博彦：软件研发度量体系建设（二）

你好，我是美团高级技术经理钮博彦，主要负责美团点评研发工具栈的建设。在上一篇文章中，我分享了研发度量体系建设中度量的意义与度量体系中的前两个衡量指标，即价值与效率，今天我们继续聊一聊度量体系中的质量指标以及如何建设度量平台。

度量体系之质量

在我们明确了价值，提高了效率之后，我们就需要判断产品质量是否能够达到预期。质量度量的重点有两个，一是以结果为导向，二是质量问题，越早发现，越易修复。

其实这是两个老生常谈的问题了，但同时它也引发出我们对质量的两个关注点：第一，关注线上质量，包括服务端和客户端等；第二，关注过程质量，包括需求质量、代码质量、测试质量、发布质量和系统质量等。

线上质量

我相信多数团队都有线上质量看板，从中我们能够得知很多信息。首先，对于服务端，我们可以将度量指标分为三类：第一，线上故障，以线上故障数、线上故障恢复时长、线上缺陷数等指标来衡量；第二，稳定性，以服务可用性、错误类型分布、错误率、报警数、错误数量等指标来衡量；第三，性能，以接口响应时间、慢消息、接口慢响应率、慢 SQL、慢缓存等指标来衡量。

其次，对于客户端的线上质量度量指标，多数人会从 Crash 率、页面错误率等维度去衡量客户端的稳定性，而对于它的性能，我们可以关注安装包大小、页面加载时间、启动时间、FPS、卡顿、流量、CPU 等影响因素。

过程质量

之前提到，过程质量，一般可以从需求质量、代码质量、测试质量、发布质量和系统质量等维度进行度量。

1. 需求质量
30%-40% 的效率问题和质量问题来自于需求质量，需求质量问题有很多产生原因，比如没搞清楚需求的目的、不明确需求的目标，或对需求的理解千人千面等等。那我们怎样把控需求质量呢？

我们可以将需求质量指标分为两类，第一，需求整体质量，可以关注需求质量评分、需求 Bug 数、需求千行代码 Bug 数等因素。第二，需求自身质量，可以以需求打回次数、需求变更次数、需求质量 Bug 数等因素来衡量。

2. 代码质量
我们在工作中，经常会遇到代码质量差的问题，但是有多差、差在哪里，又很难说清楚。举个例子，我们有一个团队大约有 30 个开发人员，QA 六个月报了 1500 个 bug。这个数据体现了一个非常严重的问题，就是开发人员在交付代码时，无论是交付上线，还是交付给 QA，其代码质量都很差，结果就是 QA 与开发人员会周旋于 bug 的沟通与修复，导致团队效率极大降低。

因此，实时关注代码质量就显得尤其重要，我们可以将代码质量指标分为基础信息、可靠性指标、可维护性指标这三类。首先，基础信息可以通过代码质量评分、文件数、类的数量、方法数量等进行衡量。其次，可靠性指标可以依据代码重复率、代码圈复杂度、千行代码严重缺陷度和安全缺陷度来衡量。最后，可维护性指标可以关注高复杂度函数数量、迷惑方法名数量、技术债务比等因素。

另外，我们有一个不成文的实践，就是你要么先单测，要么将全复杂度降到一定程度之下，比如，只要你将全复杂度降到 15 以下，就可以不用写单测。我们通过这些手段，能够让大家快速了解到自己的代码质量。我们还会用一些短平快的方法去降低代码的复杂度，屏蔽代码质量引来的风险。

3. 测试质量
测试质量指标可以分为四类，第一，整体质量，可以查看千行代码 bug 率、整体漏测率、测试覆盖率、小流量灰度漏测率、提测打回率等；第二，bug 统计，可以查看缺陷新增趋势、解决趋势、生命周期分布和有效缺陷率等等；第三，单元测试，可以关注单测通过率与单测覆盖率；第四，单元化测试，可以通过自动化测试通过率、覆盖率、稳定性等因素来衡量。

4. 发布质量
不知道你会不会很关注发布质量，但在线上的 bug 中，很多都是由于发布环节的不规范导致的，对于发布质量的度量我们也将它分为三类。

一是发布整体，我们在发布环节有很多数据可以用来观察发布失败率及次数、发布和需求关联覆盖率、高峰期间发布数量及占比、非窗口期间发布数量及占比等指标。二是构建相关，我们可以关注构建成功率、构建次数与频率、构建失败平均恢复时长等指标。三是回滚相关，比如有预发回滚率、小流量回滚率、全量回滚率，等等。通过关注这些因素都可以使我们知道并保证一个平稳的发布过程。

5. 系统质量
我们可以从系统整体看服务数量、最长链路等指标，也可以看性能相关的方面，比如最大 QPS、系统响应时间、CPU 和客户端专项测试数据等，还有安全性指标，比如安全漏洞严重问题数等等。

全流程质量度量

我们在拿到这么多维度的质量数据之后，要做的就是全流程质量度量。全流程质量度量的目标有三点：需求质量评估、代码质量评估和风险预警。就是从多个维度去观察需求开发过程，对需求上线之前的质量进行评分，以及预测上线之后的风险。目的是提高研发过程中的效率，避免上线之后再做一些重复动作。

总而言之，建设质量度量体系能够带来三方面的好处。第一，产品整体质量可以实时评估；第二，可以提早暴露质量风险，使我们能够提早进行修正；第三，可以使质量保障流程有的放矢，加快落地速度，效果也会非常明显。

说了这么多，想必你已经清楚了我们为什么要度量，以及如何度量，接下来再聊一聊度量平台的建设。

度量平台建设

我们先来看一张度量平台建设的云图，也是我们目前的整体架构图。

在我们公司内有各种各样的业务系统，然后有两个数据渠道，一个是实时数据流，主要用于分析代码质量，每一次代码提交都触发持续集成，我们可以在代码提交时了解到它的质量。另外，实时数据还可以支撑我们线上的监控情况。大家可以看到，我们在这块采用了 ES 来做数据存储，主要是因为我们实时分析的数据量较小，如果你的实时数据分析需求较大的话，可以采用 Flink 或 Spark Streaming。

另一个是离线数据流，我们的离线数据量非常大，每天会有几百 G 的数据进入数仓，包括需求的流转数据、代码提交、持续集成、发布数据、各种线上的监控等等，最后都会汇总到数仓。在数据立方体建设方面，我们主要采用 Kylin。另外，我们的实时数据最终也会通过 ETL 的方式，汇总到离线数据库中，为之后的离线数据分析做数据支撑。

最后再讲几个难点，也是我们在建设度量平台中踩到的坑。
第一，技术选型，我们当时有许多考虑，比如用 Flink 或 Spark Streaming 来做实时数据，最后还是决定用非常短平快的 ES 和离线的 Hive。

第二，指标体系建设，这是一个非常大的系统工程，非常耗费人员精力。由于美团点评有非常多的业务，每个业务都有自己的业务形式，包括发版周期、研发流程都不一样，甚至各个业务也处在不同的发展阶段，种种“差异”就造成我们的指标体系非常庞大，因此，我们就需要以多种视图、多种维度来建设指标体系。

第三，数仓建设，它有三个难点，一是数据立方体的建立，因为指标体系庞大，所以需要建设多维度、多字段组合的数据立方体。二是异构数据，因为业务系统很多，我们需要导入大量的数据，与自己的数据格式对齐，非常耗费精力。三是数据快照，简单来说就是将每天的需求的 Change log 快照下来，只有这样，我们才能得知最后一个需求在每一个状态下停留的时间长度，处理量也非常庞大。

以上三点就是我们在度量平台建设方面踩过的一些坑，因为度量平台建设这个话题比较大，有很多未能详尽之处，如果你感兴趣，我们可以继续在留言区讨论。

总结

通过两篇文章我分享了关于研发度量体系的意义、度量体系指标和度量平台建设，在建设研发度量体系中还有三个要点：第一，度量数据的生产者要成为度量数据的消费者；第二，度量是一个系统工程，不同的业务团队有不同的流程，不同的发展阶段有不同的重点，不同的角色有不同的视角，因此建设度量体系应该以系统性思维去思考；第三，度量不是绩效考核的工具，度量是为了及时解决问题，优化结果。

最后，度量体系能够帮助团队，建设关注价值、效率、质量的文化理念，可以使我们的目标更明确，提升团队战斗力与成就感，使现状更清晰，减少资源浪费，也能够帮助我们改进更精确，无论是技术革新，还是流程优化，我们都能够根据度量指标有的放矢。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友。

作者简介

钮博彦，美团高级技术经理，负责美团点评整体的研发工具栈建设。曾就职于微软中国、雅虎北研、唱吧等公司，从事系统开发、DevOps 和质量保障等相关工作。一直专注于提升研发整体质量与效率，及其流程和平台建设。

第137讲 | 成敏：创业者不要成为自己公司产品技术文化的破坏者

你好，我是成敏，跟不少技术创业者沟通，听他们吐槽创业中的坑之后，一个很深的体会是，技术创业者想要在市场驱动文化的冲击下，保持公司的产品技术文化是一件挺不容易的的事情，需要他们在多个方面持续不断的付出精力、承担压力。

不要让自己成为公司产品技术文化的破坏者

首先很重要的一点是，创业者在创业的过程中要克制自己，不要让自己成为自己公司产品文化的破坏者。但往往在现实中，很多时候，创业者不自知的就扮演了这样一个角色。

1. 不要用战略代替用户需求
很多创业者，创业路上走了一段时间之后，往往会偏离最初的出发点。当然这不一定是坏事，之前 IDG 资本曾有过一个统计，众所周知，IDG 资本投了很多互联网领域的创业公司，根据官网的数据，他们投了 750 家企业，成功上市或成功退出的有 170 家，成功率还是蛮高的。而根据这个统计，大部分成功上市或成功退出的企业，最终上市或退出时的业务模式和战略方向，跟他们找融资时提供的商业计划书里所承诺的业务模式和战略方向几乎都是不同的。

互联网行业瞬息万变，创业者在创业过程中调整方向并没有什么不妥的，关键在于是如何调整方向的。我听过的很多情况是，创始人出去参加了个会，或是跟同行交流后，觉得人家这模式特别好，自己回来也要做，就成了所谓的“战略方向调整”，用这种上层的战略调整，替代产品的一线反馈，去驱动产品运营。

很多时候，这种所谓的调整或变更都是一拍脑袋造成的，带来的很多需求也是不靠谱的。而这种需求做完之后，放到市场中一试，基本都不会有很好的效果，但这种方式给公司带来的伤害却是非常大的。所以，创业者一定要非常慎重的规划自己的战略方向和业务需求。

而调整战略方向和业务模式相对靠谱的方式是，通过各种用户数据、市场数据、业务数据去迭代产品，去调整方向。毕竟互联网的行业天条是要顺应用户需求去设计产品，而不能凭空创造用户需求。尽管大部分用户不能清晰的描述他们的需求，但 100% 会用脚投票，各类行为数据就是最好的了解用户需求的途径。

2. 别把自己当成主流用户代表
创业经常犯的另外一个错误是，经常把自己当成主流用户，并把自己的需求当成主流用户的需求。而互联网行业三大理论基础中的长尾理论表示，个人的需求只是长尾中间某一个非常细分的点上的需求，只能代表自己，不能代表主流用户。

所以，有时当创业者自上而下地提出需求，让产品增加某些功能、往某些方向发展的时候，很有可能是不靠谱的。

创业者应该做的是把自己的需求当成所有需求的来源之一，无论是客户的、用户的、领导的、还是内部规划的，任何需求，一律放入需求池，统一管理。然后通过集体决策、分工协作等方式，把各个需求分解到各个版本里去慢慢实现，永远不要想着把所有需求一部到位，这样做对公司的破坏性也是非常大的。

另外，在需求实现的过程中，管理者要尽可能的保持迭代节奏，减少变更，实在不能按期完成需求时，也要尽可能的将保住节奏放在更重要的位置。就像跑马拉松一样，你稍微慢一点没关系，重要的是一定要保持住自己跑步的节奏。

尽早建立与产品技术相适应的管理体系

一般创业公司在早期规模还比较小的时候，可以用“一俊遮百丑”来形容，也就是如果你公司的模式势不可挡，带来了巨大的营收和利润，那就可以一俊遮百丑，掩盖公司运转中的各种问题。正如很多人秉持的管理理念——公司本身的高速发展，就是对团队最好的管理，也是对员工最好的激励。

但从长远来看，公司还是需要尽早在内部建立起一套与产品技术相适应的管理体系，特别是当公司人数到了 200 人以上之后，这一点就尤为重要。

首先要建立起配套的考核、薪酬、激励制度。公司组织架构和各项制度需要在产品技术运用和市场导向中取得合理的平衡，同时，制定的薪酬体系和员工激励制度要结合互联网产品技术的特点，力争最大化的调动员工热情、激发员工积极性。

其次要打造完善的职业通道和人才梯队。在产品技术职业职业通道的建设上，关键在于给员工展示出清晰可行的上升通道和各个职业层级明确的要求，让员工找到努力的方向。而在产品技术人才梯度的建设上，关键在于高中低合理搭配，一个团队中不可能都是杰出的产品技术人才，杰出的人才往往需要一群合格的人才来配合，完成日常的开发工作，实现设计好的系统和产品。

以技术团队为例，之前看到过一种团队成员的分类法，把员工分为独狼、农民和英雄三大类。其中，独狼大多都是优秀的程序员，但是他们遇到问题的时候往往喜欢独自一人去解决问题。因此，虽然他们能解决问题，但也会比较容易引起团队内部问题和纠纷。农民则是指那些脚踏实地、有条不紊的了解周边情况、配合团队工作、推进项目运转的普通程序员。英雄则是那些能承担需要极大努力才能完成的任务，并最终取得成功的人。在承担责任和付出努力等方面，英雄和独狼有些相似，但英雄更能够与他人配合，在团队工作和开发过程中获得成功。

而根据理论，比较合理且合适的团队成员组成是，1-2 名英雄 + 大多数的农民 + 极少量的独狼。除了打造出搭配合理的人才梯队外，创业者也需要提前做好备份人才储备和人才资源池的建设，为业务的爆发式增长做好准备。

最后要打造优秀的技术培训体系。在建设好职业通道后，就要搭建起和产品技术职业发展通道关联的技术培训体系，每一个职业层级都需要有不同的培训学习计划和锻炼计划，帮助产品技术人员不断成长与晋升。同时，也要建立基于内部资源的讲师、课件和技术培训体系，形成学习型组织，为公司提供造血能力，让培养的员工能早日支撑公司的发展。

小结

总的来说，创业者打造并保持公司产品技术文化的时候，首先就是要从战略和模式上重视产品技术，克制自己，不要让自己成为公司产品技术文化的破坏者。其次在管理实践层面，要尽早建立和产品技术相适应的管理体系，从员工考核激励、员工职业成长、人才梯队培养等维度出发，打造优秀的产品技术文化。

第138讲 | 于艺：以生存为核心，B端产品的定位心法

你好，我是贝壳找房店面平台、客户赋能平台事业部总经理于艺，今天想和你分享我在 B 端产品定位方面的一些思路与心得，希望能给你带来些许价值。

我对于 B 端产品的定位是生存，因为在我看来 B 端产品不是用于娱乐或消费，而是给经营者、工作者收获利益，多数使用 B 端产品的人都是为了生存。

B 端产品的定位方法

在分享方法论之前，我想先讲一个招聘系统产品的案例，之后通过这个案例来看一个垂直房产经纪行业的生态服务是如何构建起来的。

当招聘系统这个产品需求提出来时，总部说，“我们做一个管理系统，把招聘经纪人这事好好管一管。”管的就是招聘中简历、面试、offer 这个流程。

之所以会提出这个需求，是因为当时以链家的背景，全国有将近 20 万经纪人，每年的流失率是 100%，而每流失一个人，就会损失一万块钱，流失 20 万人就意味着损失 20 亿元。因此，对于招聘系统的产品需求，我们积极并且快速将它实现了，结果却很失败。

其实，我们最初的目标是系统做完之后，全国 30 多个分公司都能将它上线，实现所有流程的线上化，结果却没有一个分公司愿意用这套系统。原因主要在于每个城市的招聘环境不同，对于小城市的分公司来说，最多两名招聘专员，根本不需要招聘系统，招聘和协同工作只用 QQ 就可以搞定。而一些大城市的分公司表示，不仅要用招聘系统，还要求系统能够支撑抢简历、自动计算业绩、自动发放绩效等功能。最终因为每个城市的差异较大，每个分公司的需求都不同，难以统一招聘系统。

我们总结了失败的原因，归根结底还是因为没有正确的方法论。B 端产品是为了满足生存需求而存在的，企业的目的是盈利，员工跟随企业也是为了赚钱的机会，因此我们做 B 端产品时就需要看准盈利点在哪，是谁在帮助企业盈利以及如何实现盈利。于是，我们总结出三个定位方法，分别是财务结构定位、组织结构定位与实施模式定位。

财务结构定位

我们可以从财务视角找到企业的核心价值点，比如从哪里赚钱，成本在哪里，为什么能活下来等。程序员们有一个通病就是看到财务两个字就想逃，但是，要想知道一个公司的成本与收益构成，就要看企业财报，有些企业可能没有真正意义上的公开财报，那我们可以去做经营者访谈，比如贝壳找房，每个门店都是一个独立的最小单元的经营者，我们可以通过了解这个店的收入与支出来了解财务结构定位。

另外，还可以看企业的核心生产资料是什么？生产资料是一个企业正增长的正相关因素，比如经纪公司的正相关因素就是经纪人的数量，或者叫合格的经纪人数量，那它的核心生产资料就是经纪人。而其他企业的核心生产力可能是产品、是服务，或者是产品背后的创新能力等，每个行业都不一样。

结合以上两点，再回顾招聘系统产品的案例，招聘与企业利润息息相关，招聘不利就意味着没有人去做交易服务，无法获得佣金收入。由此可见，招聘是关联经纪公司生存的核心价值点，至于招聘业务，本身就有一个盈利模型，它容易被量化，容易衡量交付数量，并不是一个公司的纯粹职能。

组织结构定位

以组织为核心去定位服务提供者的角色和资源。我们需要关注两个方面，第一是目标需求所在的组织架构，一般产品经理会定位到使用产品的角色，那资源如何定位呢？资源就是这个产品所在团队的组织架构，如果看不到一个完整的组织架构，我们就需要看他的汇报对象或上级组织，比如老师的上级组织是学校，这是教师群体所在的组织架构。

第二是目标需求的用户及其上级的绩效和收入构成，我们需要观察 B 端用户的收入来源，由此观察他们在乎什么。还是以招聘系统为例，因为招聘对业务的影响过于深远，所以招聘部门在全国的组织架构是各分公司负责自己的业务与收入，管理权主要落在各城市分公司，而非由总部统一管理，这也是招聘部门在组织架构方面的差异。

另外，在绩效构成方面，招聘部门中，每个人都是低底薪 + 高绩效的方式，他们非常在意自己交付的速度与数量，如果我们的产品对他的收入和绩效产生了影响，并且没有给他的上级管理者带来好处，那么这个产品就不可能在各城市分公司中推广成功。

实施模式定位

从实施角度看，我们需要选择最好的精益实验方案，精益实验在 B 端产品中非常难做，因为这个实验不是开流量、开灰度就可以跑出来的，我们需要做大量的业务研究，甚至设计业务实验。在实际执行中，我们可以尝试三步走。

第一，评估耦合强度，耦合即环节之间的紧密程度，比如在招聘时，获取简历和简历邀约是可以分开的两个步骤，我不需要在一秒钟之内把获取简历和简历邀约都做完。

第二，评估角色的丰富程度，比如财务系统的审批可能需要层层审批，涉及的角色非常丰富。而招聘这件事很简单，就是招聘专员，向他们交付一个服务。

第三，优先尝试 Offline 的精益实验，就是不要动用开发资源，先把一个最小的业务实践跑起来，即线下的 Offline 的精益实验。这个方式够灵活、够快，能够快速获得用户的反馈。

上图其实就是之前提到的两个维度在 B 端场景中的分类，在这四个象限中，比较理想的是松耦合、单角色的场景，可以尽可能尝试 Offline 精益先跑业务的方式。其次是左上角第二象限松耦合、多角色的场景，它的不利点在于多角色沟通方面，业务跑出来后需要沟通的方面太多了。这时，我们可以善用 IM、在线文档、网盘等工具，比如在三个人的招聘组中，我们想去监控他们的行为，就可以建一个 IM 群，或者用一些在线共享文档、共享网盘等工具将他们的行为记录下来，验证一些事情。

再来回顾招聘系统的案例，我们可以将招聘业务流程拆解成多个模块，然后用 Excel、在线文档、邮件、IM 组合的方式模拟线上规则，强调最小单元的交付，快速、灵活地获取用户反馈。

当我们做完这些事情之后，我们的招聘系统产品获得了重生，目前，我们对它的定位是，一个正在进行中的贝壳找房经纪平台上的经纪人招聘生态服务。

第一，它是一个可以独立核算的商业化服务，它可以从职能团队中剥离出来。

第二，我们可以用平台 + 城市合伙团队的模式，利用各个城市非职能团队，甚至是当地的一些人才供应商，做一些定制的合作，形成贝壳输出商机及输出人员的需求，由当地的合伙人向我们提供服务，我们跟他做利益的分成。

第三，技术驱动重构经纪人招聘的业务流程，我们具体做了哪些事呢？首先是去重插件，这是一个非常小的产品，也非常符合精益原则，我可以几乎毫无成本的帮助全国的招聘团队或正在招人的店长们节约简历下载的重复量。

其次是精准流量，我们可以把线上获取简历的渠道，更加精准的匹配经纪人岗位的需求，而非让招聘专员自己去下载简历，通过人性去判断简历是否合适。有了精准流量后，可以匹配后续的人才模型，之后还可以做面试机器人、邀约机器人、内推链等等。最后，当这个平台上的人才服务流程已经跑起来的时候，就可以做人才服务交易了。

总结

今天通过招聘系统产品的案例给大家分享一个 B 端产品定位的方法论，其实，说了那么多，归根到底只有一个关键词，就是生存，一切关于 B 端产品的判断与定位，都可以围绕这个关键点来思考。

作者简介

于艺，贝壳找房店面平台及客户赋能平台事业部总经理，致力于用互联网的产品技术帮助贝壳平台上的加盟商更高效的开店，更高效的招人育人。之前在链家负责链家网上海 app 的研发工作，在经营分析系统、楼盘字典、真房源和 O2O 的行为追踪方面有诸多创新。

第139讲 | 成敏：创业者应该具备的认知与思维方式

你好，我是成敏，因为工作的关系，我经常会接触到不少的技术创业者，之前跟大家分享了他们对于技术产品文化的吐槽以及相应的应对策略。今天想跟大家分享一个稍偏虚一点的话题，关于技术创业者的思维与认知。

1. 创业者要去思考自己存在的意义
当你想走出创业这一步的时候，一定要想清楚能支撑你去创业的核心原因是什么。这其实会上升到一些哲学的层面，就是你要先想明白自己存在的意义，活着的意义。

创业其实是你人生一次颠覆式的选择，会对你的人生起到非常大的影响，如果你不能够想明白自己为什么要活着，或者你从来不去思考这些问题，然后就想着要去创业，要去改变命运，那一定会有很大的问题，很容易在半途中迷失方向。当然，也不排除有一些创业者运气比较好，没想明白就去创业也赚钱了，但这毕竟是少数，同时，这样的创业者也很难做出真正对行业对社会有益的企业。

不仅是创业，几乎所有的领域中真正有成就、有杰出贡献的人都会思考这个问题。甚至于我们今天看到的社会的发展、人类的进步，都是来自于思考这些问题的人，是由他们带动的。然而在现实中，大多数的人可能一辈子都没有真正有效地去思考过这个问题，但如果你选择创业，就不能再忽视或逃避这个问题。当你问自己这个问题的时候，你会发现你的整个视野立马宽广了很多，不再局限于很多细节的东西。

这样的思考带来的是你对自己清晰的定位，你知道自己想要什么样的生活，想要做什么样的事情，想要成为什么样的人。这样，当你创业时，你就能找准自己的出发点和想要达成的目标，也能找到自己前进的动力，面对各种抉择时不会感到迷茫，面对各种问题时也有了解决的准绳。

2. 创业者要时时更新自己的认知
创业者还要多多提升自己的认知，方式就是不断接触更多的人和事，接触更多的信息，然后理解它们。

以人们的收入为例，在工业革命前的几千年间，个人的收入几乎没有什么变化，或者说在一个非常小的幅度里波动。而进入工业革命后，尤其进入新世纪之后，人们的收入呈现了一个指数级的成长，这也体现了经济的指数级增长，而这带来的是行业的、社会的剧烈变革。

不少企业家、管理者都在他们的演讲中提到，如今是 VUCA 时代，也就是一个易变的、不确定的、复杂的、模糊的时代。这个概念其实并不是首次出现，德鲁克早在上个世纪 80 年代出版的《动荡年代的管理》一书中，就第一次明确提出了变化对商业社会的冲击，并表示当时的商业环境已经进入高度的动荡紊态。而现在商业社会的动荡程度和当时相比，至少多了一个量级。

这样的商业环境带来的挑战就是，理解变化、拥抱变化成为创业者的必修课，如果我们不时时更新自己的认知，就极有可能落后于这个世界。举个例子，之前一个企业要做十年、二十年才可能成长为一个非常大的独角兽，而如今，很多创业公司短短几年之内就能成长为独角兽。与此同时，一个企业从成长起来再到失败可能也只需要很短的时间，近几年的共享单车行业可以说是很好的样本了。

因此，当你不断更新自己的认知，认识了这个世界的一些粗浅的本质后，再去看待周围的事物，去做一些决策的时候，就会发现自己能思考得更深一层，有更多的想法。

而当你想明白之后，就不会再煎熬和痛苦，在面对创业中的各种事情试也会更加从容，能够阻碍你的东西也会越来越少。

3. 创业最大的收获是对思维的洗礼
并不是每个创业者都会成功，但不论最终结果如何，每一次创业都是对创业者思维方式的巨大洗礼。

之前提到，创业者在创业之前要想清楚、弄明白，但其实，当你真正投入创业之后，之前想得再多还是会遇到各种各样新的情况。比如你会不断地被问各种各样的问题，来自用户的、客户的、合作伙伴的、员工的等等；也会不断的遇到问题，比如这个需求要不要做，要不要招人、要不要裁员等等。很多问题可能是你之前就经历过的，有相应的经验，但也有些是你之前从来没有做过的事情。这个时候，就会逼迫你在不断的决策的过程中，把每件事情都真真正正的想清楚。

因为你一旦偷懒，不去想明白就去决策的时候，世界会立刻还你以颜色，你做出的决定很可能会导致特别糟糕的结果，比如会招致合作伙伴的不满，丢失用户，甚至会影响到业绩等等。

可以说，大多数创业者，创业前和创业后最本质的差别就是他们的思维方式，他们的思考会更精密，他们的逻辑性会越来越强。即使他们最后创业失败了，这样的思维方式也会成为他们最大的财富。

最后，不管面对多大的困境，创业者一定要具备某些信念，其中最重要的一点就是要永远相信未来会更好，这样的信念会支撑你面对创业过程中的任何困难，支撑你走下去。

第140讲 | 袁店明：创业产品必须迈过的鸿沟

你好，我是袁店明，DellEMC 资深敏捷咨询师、培训师，精益创业导师。我曾在 2014 年做了一年的独立咨询，期间辅导了多个创业公司。在这个过程中，我一直在思考并探索产品需求的来源，今天，我总结了一些个人探索和辅导经验并分享给你，希望能给你有所启发。

据福布斯数据统计。创业产品的 20 种死法中，排名第一位的是没有市场需求（No market need），很多创业公司在创业时根本没有明确产品的市场需求，就推出产品，这是失败的主因。

那么如何明确我们的产品有市场需求，并与市场匹配呢？最直接的方法就是提出假设并验证它，用一句玩笑话来说，就是把投资人的钱烧光之前找到可行的商业模式和正确的产品逻辑、产品路径。

价值主张与用户细分

下图是一张商业模式画布，在一款产品开始前，可能你会做商业模式画布，当产品做完后，进行复盘时，你会发现，最初的商业模式画布中的九个格子可能都是你的猜想，没有一个经过你的验证。

那如何把猜想变成现实，就是我们接下来要解决的问题。首先，我们来看商业模式画布中正中间的一个模块，价值主张（Value Propositions），价值主张不是产品，更不是创意，而是产品要提供给用户的价值。换句话说，价值主张是产品的内涵，是你真正所要表现的东西，而产品是你给用户提供价值的媒介。

因此我们不能只将所有精力投入产品中，产品只是外在的表现形式，我们需要清楚产品能够带给用户何种价值主张，能够帮助用户解决什么样的问题或痛点。事实上，当我们清楚了产品的价值主张后，针对不同的用户，产品形式可能会有多种，那么谁是我们的最终用户呢？

接下来就是商业模式画布中的第二步 Customer Segments，即用户细分或者客户细分，在汉语中，用户和客户是两个不同的概念，这里我们主要谈用户。我们需要思考两个问题：

用户是谁，是哪一个细分人群？

他们所处的场景是什么，为什么要买我们的产品？

举个例子，我在 2014 年辅导过一个创业产品是视频服务，我建议创业者将所有的目标用户列出来，再把这些用户的场景列出来，场景包括人物、时间、地点等。当然，人物就是他所列出的用户细分。当他列完之后，我当场就否定了他的创业产品，因为对于他所列出的用户细分人群而言，所需要的数据流量价格太贵了，所以很难做起来。结果他没有听取我的辅导建议，没有坚持多久还是放弃了。

在这个案例中，对于产品的场景，除了时间与地点外，关键还在于网络环境。因此我想说，对于现在的 APP 产品，虽然如今流量价格大大降低了，但我们仍然需要考虑网速问题。比如是处于 WiFi 场景，还是处于非 WiFi 场景，是处于高速的 4G 流量环境，还是属于低速 4G 流量环境，等等。

明确了价值主张与用户细分，我们再来看这张产品 - 市场匹配（Product-Market Fit）模型图，顶层的 UX 是用户体验，在 UX 下层是产品功能集，再下一层是价值主张。而价值主张是我们真正要提供给用户的，根据最深层的用户需求而来。由此可见，我们只要明确价值主张与用户之间是否匹配，就可以确定产品与市场的匹配关系。

我们可以按照一套行之有效的逻辑进行验证，就是提出假设、设计实验、验证和学习。首先假设用户细分人群和场景，接着设计一个实验来验证假设，然后收集反馈结果，最后通过不断的学习和有价值的用户反馈，对产品进行快速迭代优化，以期匹配市场。

四步走策略

根据上述的推理逻辑，我在辅导创业产品时一般有四个步骤。

第一步，提出假设。

假设的前提是建立价值主张，明确产品创意和解决方案以及你想带给用户的价值。这里举个反例，某创业公司中有七八个人，但每个人对对产品的价值理解都不同，对产品的未来方向理解不一，这就是典型的价值主张不明确。当我们确定价值主张之后，就可以提出问题假设，并在办公室画出商业模式画布，

第二步，验证假设。

基于价值主张，我们可以进行逻辑推理。首先是用户人群细分，尽可能发散，因为每个人群的特性不同，需要解决的问题不同，即使问题相同，不同的用户人群所需要的解决方案也不同。其次是针对每个用户细分人群列出场景，即时间和地点，需要注意的是，时间、地点、人物这三要素仅仅是基于价值主张来考虑。此时需要抛弃你最初的创意，因为创意是你强加给用户的解决方案，此时最重要的是研究清楚基于价值主张，你的最终用户人群是哪些，他们有什么痛点。接着考虑问题，每个用户细分人群在各类场景下碰到了什么样的问题，一个问题可能由多个因素组成，我们需要把问题拆解，猜想构成这个问题的所有可能性因素，最后把这些猜想都设计成访谈问题，走出办公室，针对真实用户进行验证。

第三步，提出验证方案。

我们需要开发高保真产品原型，找到最终用户进行真实试用，并验证方案的可行度。比如前面提到的视频服务案例，当时创始人的想法是给医生与患者提供远程视频医疗服务，我问他，“现在的微信或 QQ 视频不能满足这种需求吗？”他说“不行，因为医生要看患者的化验报告单。”我反问他，“真的需要看吗？”于是我们就去访谈医生，医生表示并不会看化验报告单，如果要看，可以让患者拍照。这个结果就验证了远程视频医疗的猜想是不可行的。

第四步，证实或转向，

在我们验证猜想时能够得到真实用户的反馈，明确最终用户是否认为产品能够解决他们的问题，如果是，继续验证下一个问题或下一个用户细分人群，如果多个问题都被否决，我们就要重新考虑价值主张，也就是创业产品的转型。一个方向走不通，我们就要尝试下一个方向，转型时就涉及到产品的重新定位，即价值主张需要重新设定。

总而言之，就是从建立价值主张、列出假设用户与场景到提出问题、验证问题的过程。

案例分享

我分享三个案例，都是我在 2014 年辅导的创业公司，每个案例中所遇到的问题都不同。

案例一：简七理财

这个产品的创始人当时还在大公司做理财顾问，工作之余，通过写公众号文章、博客以及组织线下读书会等各种活动聚集用户，想为这群用户提供所有可能的理财产品或服务，比如基础的理财教育、基础的投资知识、自己的理财平台、导流到银行等机构的理财产品、导流到投资平台等等。

当时，他的想法是为小白用户提供价值投资，我和他将所有创意列出来之后，根据逻辑推理流程，我建议他从理财产品、投资教育和理财教育这三个方向中做出选择。他当时非常犹豫，因为在我辅导他之前，他已经投入了两年时间摸索创业。在他团队中，有人认为他们要卖理财产品，而他作为创始人，认为他要做理财教育，但同时，还想做导流到银行的理财产品，这就是典型的价值主张不明确问题。

他认为通过各种方式将用户汇聚到平台上，就能解决问题，事实却不是这样，不清楚用户的问题，或者不明确能够给用户提供何种价值，即使有再多的用户，也可能一夜之间流失。

结果，经过半年的尝试和思考，他终于确定了方向，决定做理财教育，正好赶上知识付费的风口，有了不错的发展。

案例二：VEO 纽视科技

它最初的价值主张是“VEO 是一家在线云视频服务提供商，为开发者提供主打视频通讯能力的 PAAS 平台服务，提供的 API、SDK 和打包的应用程序，支持视频通话、屏幕共享、注释、示例代码和在线文档等服务。”

它的典型错误就是在未进行每一个细分领域的产品 - 市场匹配的情况下，直接决定做平台服务，认为用户一定会用。而且，在 2014 年的短视频热潮下，他断定风口来了，于是，我按照逻辑推理，将所有创意、问题等列出来，建议他一一验证，以此来明确某个细分领域是否可行。

当时他列出的想法包括公司多点视频会议、视频远程教学（早教、成人学习）、远程视频医疗、视频面试、视频客服等，比如对于公司多点会议这个想法，因为大公司都有自己的视频会议系统，而小公司对视频会议的需求较小，几乎不会用到这样的系统，所以就此否定。其余的想法也几乎全部被否定，于是他最后还是回到代理服务，虽然难以做大，但至少是赚钱的。

案例三：美人工厂

这个创业公司想解决的用户痛点是，电商平台不能试穿衣服，而他的解决方案是从服装厂商拿到产品并设立线下门店，给用户提供试穿。这时，我们需要列出用户细分人群和场景，是一线、二线还是十八线城市？首先因为他的合作品牌都是中小品牌，所以在一线设立门店不占优势，需要去二三线城市，而对于小品牌或者低消费人群来说，也没有太大必要设立线下门店。因此只剩中型品牌在二三线城市设立门店的选择，可是消费人群受限，得不到扩展。这个案例就是用户细分人群的问题。

总结

面对创业产品可能会遇到的各种问题，我们都可以执行这套推理逻辑，就是基于价值主张，寻找用户细分人群，以人物、时间、地点出发，提出假设问题，并猜想构成问题的所有因素，再逐一验证所有的这些假设。针对这些证实的问题和痛点提出解决方案。这个逻辑可以帮助我们更加准确的匹配价值主张与用户之间的关系，提高产品与市场的匹配度。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

袁店明，DellEMC 资深敏捷咨询师、Progam Manager，精益创业导师。曾任职于百度，辅导过多个产品线转型，在阿尔卡特朗讯就职期间，负责上海贝尔多个产品线的敏捷教练和敏捷培训师工作。目前在 Dell EMC 担任产品线的 Program Manager，负责整个产品线的项目集管理与转型。曾经担任 Agile China 2012 的执行副主席，Scrum Gathering Shanghai 2012 年和 2013 年的评审委员会负责人，QCon 上海和北京的专题出品人，《敏捷教练 - 如何打造优秀的敏姐团队》合译者。致力于探索团队发展和组织转型、团队引导、可视化管理、精益创业、持续集成、欣赏式探询、演讲和培训。

第141讲 | 徐毅：五星级软件工程师的高效秘诀（一）

你好，我是华为云 DevCloud 首席技术布道师徐毅，今天分享的话题是五星级软件工程师的高效秘诀。

从去年年底开始，我们发起了一个提升研发效率的项目，积累了很多思考和经验。研发效率包括很多不同的方面，也能从很多不同的角度去观察，我今天分享的内容更偏向于从提升基层个人能力和基层团队能力两个维度去提升研发效率，希望对你有用。

高效的工作策略

首先想请你思考一个问题，你觉得一个五星级员工效率高、价值大的原因是什么？

在多数人看来，有三点原因，第一，智力因素，比如智商、逻辑思维能力、推理能力、创造力等高；第二，性格因素，比如自信，有雄心壮志、冒险精神及自制力等；第三，社交因素，比如有处理人际关系的技巧、有领导力等。

然而，在《五星级员工是这样诞生的！》这本书中，揭示了原因并不是多数人以为的这样。书中说到：“从揭示生产效率的秘密的角度来看，我们的数据显示，精英职员和普通职员在智力因素、性格因素、社会因素和环境因素方面并没有明显的差别……”

这个数据是有依据的，作者罗伯特·凯利（Robert E.Kelley）花了十年时间研究明星员工的个人特征及职业特征，最后总结出了高效员工的工作策略，并将其归纳为九个方面。

积极主动（Taking Initiative）

构建知识网络（Networking）

自我管理（Self-Management）

团队协作（Teamwork Effectiveness）

领导力（Leadership）

追随力（Followership）

大局观（Perspective）

呈现与表达（Show-and-Tell）

组织智慧（Organizational Savvy）

当然，这些员工也并不是一开始就有高效工作的能力，而是在日常工作中，坚持实践这些精英的工作策略，长此以往，他的工作效率就远超他人。

基于这个理论，我们希望在现实工作环境中推行这些工作策略，为此，我们必须找到一些切入点或者抓手，这个抓手就是聚焦效率问题，从不同维度入手改进影响员工生产效率的问题，最终打造高效个人。

聚焦效率问题，打造高效个人

我们先来了解影响效率的原因，常见的影响产出效率的问题主要有四个方面。

第一是软件工程师不能够聚焦编码、团队周边协作与支撑工作占比高、跨团队联动开发等耗时又低效。我们希望降低这样的开销，让员工有更多时间去编码。

第二是打断问题，员工工作常被突发事务打断，据统计，平均每小时被打断 7 次以上，平均编码持续时间不到 10 分钟。

第三是 PL 直接贡献价值少，项目管理和团队建设占比高、特性交付占比不到 20%。我们希望 PL 也要投入较多时间参与开发功能、开发特性，去做交付，而不只是做一个纯粹的管理者。

第四是新员工写代码、老员工解问题。很多团队会让新员工写代码，出现问题后又让老员工主要解决新员工遗留的问题，但多数人都不喜欢解 bug，若是长此以往，老员工也失去了动力。

综合以上四方面的问题，我们将问题与理论结合，得出一套实践方法叫“TVI/PVI”，意思就是基层团队及个人效率提升，针对不同的问题，提出对应的解决思路和实践方法。我们大概将问题分为五类。

第一是活力：活力决定动力，因此，我们需要激发员工的活力，这样他才会自主高效地工作。

第二是贡献：我们提倡贡献透明化，并建立个人荣誉档案，让员工看到自己的贡献，看到自己被认可，获得荣誉和鼓励。

第三是管理：我们推崇自我管理，相对应的实践是静默时间与番茄工作法，使用精益看板与个人看板，以此提升个人效率。

第四是能力：我们提倡员工不断学习，构建自己的知识网络，打造自己的知识沙盘。

第五是协作：相应的实践是组建微战队，推动社区化评审与协同。

做这些事情的最终目标，都是为了倡导高效工程师，再具体一点就是将工程师的效率提升 10 倍。虽然现实情况下，在一个庞大的研发队伍中，很难说人人都是超级精英，但是我们希望，能够让更多的精英浮现出来。因为如今是一个 VUCA 时代，即动荡（volatility）、无常（uncertainty）、复杂（complexity）、模糊（ambiguity），组织形态为了适应这种不确定性，对个体的要求更高了，所以我们需要高效个人。

举个例子，在《赋能》这本书中，作者提到了三种作战组织形态，分别是指令式机械组织、指令式团队组织与团队式团队组织。

首先来说指令式机械组织，典型的就是美军常规部队，强调自上而下的指令系统，成员间的沟通是通过其上层节点来完成的。再来说指令式团队组织，典型例子是美军特种部队，团队间也是采用自上而下的指令系统，组织成员间则完全的横向连接、充分互动。最后是团队式团队组织，团队间和团队内部均采用完全的横向连接，以个人为节点，达到充分互动。

可能只讲这三种组织形态的区别，我们很难感受到高效个人的重要性，不妨再来看看这三种组织形态之间的关联。指令式机械组织为了提高沟通效率与作战效率，会向指令式团队组织发展，而指令式团队组织能够做到充分信任并拥有共同的目标感，但团队之间仍然维持着传统的指令式组织模式。为了在更大范围内增强协作，例如要确保全球大规模的特种部队间的紧密协作，围绕同一目标展开行动，整个团队就必须朝团队式团队演进，需要每个团队都同其他团队之间建立广泛的信任关系，犹如团队内部一般。

这三种组织形态也体现在我们的工作组织中，传统的瀑布型组织，就是指令从上往下传递，但当你需要多个业务部门配合，或者多个职能部门配合作战时，如果还是全都要向上汇报给老板做决策，再传递下来，效率就会特别慢。于是，这种组织形态就演变成了以个人为节点的网状组织，在这个组织中，个人所承担的责任会更大，对个人的要求也随之提高，而当下，多数互联网公司都采用网状的组织形态，因此，就需要我们成为高效个人。

那如何成为高效的个人呢？我们先来看看新时代员工的驱动力构成，主要有三个方面：第一，是自主，员工需要在做什么、什么时候做、和谁做以及如何做上实现自主；第二是目的，员工需要清楚这样做的目的，创造不同，认可自己工作的价值与意义；第三是专精，员工需要能够运用并改进所擅长的技能，把想做的事情做得越来越好。你可以问问自己，你的一技之长是什么？如果你内心有答案，那至少你对自己的定位是清晰的。

根据这三点驱动力因素，我们需要帮助员工了解自己的特长，并帮助他在工作中不断精进。由于篇幅受限，我将在下一篇文章中继续分享我们对于打造高效个人的实践与方法，欢迎持续关注。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友。

作者简介

徐毅，华为云 DevCloud 首席技术布道师，华为 Cloud BU 软件开发云产品部、华为研发能力中心特聘敏捷专家顾问，前 IBM 大中华区敏捷及 DevOps 卓越中心主管，前惠普企业服务资深敏捷顾问，前诺基亚移动设备敏捷及精益教练，前诺基亚网络全球敏捷转型中心精益及敏捷教练，业内知名敏捷教练及顾问，IT 书籍译者。

第142讲 | 徐毅：五星级软件工程师的高效秘诀（二）

你好，我是华为云 DevCloud 首席技术布道师徐毅，在上一篇文章中，我们了解到影响工作效率的原因以及成为高效个人的重要性，今天我们继续探讨如何成为高效个人，我将分享一些我们的经验和方法，希望能给你带来价值。

第一，基于工作目标，定期审视现状，有针对性地提升能力。

我们团队内部有一个能力矩阵，我们会基于工作目标，定期评估员工能力现状，并有针对性地确定近期可以改进方向和目标，以此不断地提升他的能力。

在实践中，首先要根据团队的业务目标和技术目标，明确未来这个任务需要团队具备哪些技能，再根据团队成员的能力现状，有针对性地进行提升，使他们的能力与团队对齐，以便更高效地完成团队目标。在这个过程中，我们一般有四个措施：

定制计划：识别成员能力 GAP，制定能力提升计划；

实践锻炼：任务安排采用必要任务 + 提升能力任务，保证交付质量的同时提供实践机会。

闭环改进：通过对关键案例的技术分析、一类问题的归纳总结、复盘等来提升成员的技术分析能力；

培训分享：开展课程培训、测试经验总结，让该领域能力强的人，帮助成员提升能力。

除此以外，我们还会制定能力仪表盘跟踪现状，并观察提升趋势，帮助我们实时地看到员工能力的变化。

需要注意的是，能力评估也要与知识挂钩，高水平的能力必须要产出相对应的知识，进行积累和消化，比如写 Wiki 和博客等。另外，我们内部有一些工具，会与任务管理系统对接，员工完成某一个特定任务之后，工具系统就会自动累计该员工的能力经验值，这也是一种能力提升的反馈。

第二，工欲善其事，必先利其器。

我们很强调工具，因为我们的业务形态很多，所以会有各种各样不同的工具提供给员工选择。同时，我们还会统计员工使用某个工具的时间，通过这样时间统计，我们可以知道工具在使用过程中出现的情况，并针对性的进行改进，或是把更合适、更好用的工具推荐给他们。

另外，在研发层面，我们也会提供工具链服务，华为的业务场景众多，原本每一个产品都有自己的工具系统，每个业务部门都有自己的工具团队去开发适合业务情况的工具。而现在，由于提倡高效工程师，要减少工具的人员，将所有的相关工具链整合为对内的新的工具链系统云龙以及对外的软件开发云，也就是我目前所在的 DevCloud。

第三，提倡知识管理，从梳理和积累开始做起，坚持就有成果。

除了工具以外，我们还提倡知识管理，不论是基层员工还是管理者都需要积累知识、输出知识。

举个例子，华为的特点是以客户为中心，就强调一线团队要跟客户拉近距离，但这样一来，客户遇到问题时就会直接找研发团队，研发团队就会经常被打扰。于是，我们在团队中又设立了一个特战队，专门对接外部的问题，包括来自客户的干扰和来自产品的干扰。因为有很多问题是重复性的，所以就要求特战队在解决问题的同时将所有问题都记录下来，当有重复问题时，就可以更快“对症下药”。另外，特战队的作用就是在内部做好第一层过滤，凡是一些基础问题或是已有现成答案的问题，都不可以再推送给研发人员。

总之，我们要求所有人都积累知识，更提倡大家输出内容，这样不仅能够证明员工水平高，同时，知识的输出也能进一步促进员工做知识积累，形成良性循环。

第四，辅以贡献可视化和同行认可为反馈、标杆为激励，可以促进专精。

我们希望员工得到更多的贡献可视化和同行的反馈认可，为此，每一个员工都有一个内部档案，这个档案不是简历档案，而是该员工的成绩呈现。其他同学对该同学个人贡献的认可与反馈，可以使他获得荣誉感、归属感与激励。我们还制作了团队贡献仪表盘、团队个人平均生产率图表、个人平均代码行生产率图表与个人综合贡献排行榜等，可视化地呈现他们的贡献产出，这既是员工的成就体现也会成为他们改进的动力。

第五，知识积累配合各种解耦手段，消灭不必要的协作和沟通。

这一点的前提是先判定协作与沟通是否是不必要的，一般来说，我们会把协作分成以下四个方面来衡量。

协作质量：我们可以用对内协作的量除以对内协作和对外协作量的总和，如果是高占比，就意味着是“高内聚低耦合型”的优质协作，反之就代表协作质量较低。简单来说，如果团队成员需要频繁的跟团队外部人员沟通，那就意味着协作质量存在一定问题。

协作类型：关键是围绕什么进行协作，例如代码、任务、需求、服务等。如果是两个服务型团队间协作，那么他们之间的交互就不应该是围绕一个任务或需求来开展，因为服务是可以直接互用的，对于这种不合理的情况，就需要去改进。

协作强度：度量的标准是协作次数与协作时长，而且，跟不同的人协作的强度也应该是不同的。

协作丰富度：充分的协作可能会运用多种媒介，例如 Espace、云龙、DevCloud 等，而不同媒介有不同的作用，因此也可以用协作媒介数量来衡量协作丰富度。

除了根据上述四种协作类型判断协作质量，进而解耦外，我们还会根据业务形态，进行团队架构上的解耦。比如针对云化和 IT 类产品，我们进行服务化解耦，提倡微服务微战队，就是将服务细化拆解并分配到相应的微战队中，微战队完成任务之后再与整体服务进行对接、联调，进行整体的测试。而对于系统类产品，我们会组件化解耦，就是将系统组件化，每个组件分别开发完之后进行最后的集成，再完成上线，因此对应的团队就是组件化微战队。

其实，微战队是一种实践，我们比较高效团队和低效团队后可以发现，在很多团队中，真正干活的可能只有三五个人，或者三五个人之间的合作比较密切。因此我建议 PL 可以观察团队中成员的交互，看哪些人协作比较多，就可以把他们组成微战队。这样做带来的好处，除了高效沟通与协作之外，还可以减轻 PL 的管理工作，甚至可以减少一些管理者角色。

第六，建立成长心态，不怕失败，持续成长。

华为的文化不是特别提倡试错，而是提倡成长的心态与文化，要时刻从工作中、生活中学习。心态不同，看待同一件事情的感受和反应也不同。比如加班这件事，假如一个新的版本需求要尽快实现，有人的第一反应是“天啊，又要加班”，但也有人会说“我们又有事做了”，这其实就是僵化心态与成长心态的区别。

僵化心态主要是说，他们认为人的能力是不变的，就像成人的身高一样，在这种情况下，如果又想要在事情上、任务上有不错的表现，在面对挑战时，他们就会更倾向于避免可能会失败的情况，在他们看来，失败是有损形象的事，努力更是只有没天赋的人才会做的事。

与之相对的，成长心态则认为人的能力是可以增长的，就像肌肉一样，他们更重视学习、成长，因此对于挑战，他们拥有很强的适应力，会尽量去拥抱它，在他们看来，失败可以得到更多信息，而努力是精通的必经之路。

那我们是怎样帮助员工建立成长心态的呢？举个例子，众所周知，华为有很多研究所，不同的业务线可能都建立了它的研究所，它们都有各自的职能。我们可以通过研究所在各个地域推动工程师文化与高效个人的知识分享，举办学习活动，推荐标杆式学习并给予激励奖项等等，从而创造一个知识学习与积累的氛围，推动高效个人。

总结

从我们推行的经验来看，五星级软件工程师的高效秘诀的四个层次，用中国人的话来说就是道、法、术、器，用西方术语来说就是价值观、原则、实践、工具。我们可以这样来理解这四个层次：
第一， 道的层面：就是理念，我们认为高效的团队和个人是提升研发效率的关键；
第二， 法的层面：就是方法、套路，从活力、贡献、管理、能力、协同等维度切入改进，提升个人及团队的能力，优化协作。
第三， 术的层面：就是具体实践，我们倡导微战队、静默时间和首席工程师。静默时间就是在静默时间编程，首席工程师是把团队中的高效个人单独划分出来，组成优秀团队，由部门经理直接管理，这个团队中的同学还有一个特权，可以挑选工作。
第四， 器的层面：工欲善其事，必先利其器，要提高效率，一定要为员工提供先进、易用、贴切的工具和工具链服务。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友。

作者简介

徐毅，华为云 DevCloud 首席技术布道师，华为 Cloud BU 软件开发云产品部、华为研发能力中心特聘敏捷专家顾问，前 IBM 大中华区敏捷及 DevOps 卓越中心主管，前惠普企业服务资深敏捷顾问，前诺基亚移动设备敏捷及精益教练，前诺基亚网络全球敏捷转型中心精益及敏捷教练，业内知名敏捷教练及顾问，IT 书籍译者。

第143讲 | 徐毅：技术Leader应该具备的能力或素质

你好，我是华为云 DevCloud 首席技术布道师徐毅，之前的文章中，我们谈到罗伯特·凯利（Robert E.Kelley）花了十年的时间研究明星员工的个人特征及职业特征，最后总结出了高效员工的工作策略，并将其归纳为九个方面，如积极主动、构建知识网络、自我管理、团队协作等，其中很重要的一点就是领导力。

我们经常说 Leader 要有领导力，但这个话题其实挺难聊的，技术 Leader 看似是一个词，但背后可能每个 Leader 都有不同，他们的产品、业务可能不同，他们所负责的团队或部门规模可能不同，每个人的工作经验可能也不同，很难一概而论。

如果说是一个比较基层的、十人团队这个层级的技术 Leader，技术方面可能更重要的还是技术实现、特性交付的能力，但他 / 她肯定也要带人，所以怎么样管好这十个人和这十个人的工作，也是他 / 她需要具备的能力。那就会涉及到很多项目管理相关的能力和团队管理相关的能力。这里面也会有很多软技能的需要，比如华为常说的“拉通对齐”，就是你要跟周边部门的人员去沟通协调，对内也要关注团队成员的能力、性格等方面的不同，通过任务安排等方法尽可能的发挥每个人的特点。

在这个层面的话，我建议是不要全部靠自己去摸索，如果公司内部有类似于研发能力中心这样的部门，多多跟他们保持联系，把先进的好的实践直接拿过来使用，然后也多跟其他的技术 Leader 交流，不止要学习别人的成功经验，也要从别人失败的教训里汲取经验。

前面说的是方法层面，还有就是在工具方面，十人团队这个层面，建议直接选择成熟的工具体系，如果选择比较多，可以通过使用和比较进行选型，不建议自研或长期探索。主要是如果你是大公司里的团队，你的决策余地未必很大，如果你是小公司的团队，你未必有时间来探索，如果能够用钱换来时间的话，可能反而是超值的。

如果要抽象提炼一下技术 Leader 应该具备的能力或素质，我会说是开放心态、坦诚沟通、持续改进这几个方面。

1. 开放心态

也就是能够接纳别人的意见，或者说即便不认同也能够共存。都说现在是 VUCA 的时代，技术、需求各方面都有很多不确定性，而且我们也需要发挥团队里每个人的积极性和能力，要把大家都动员起来，那必然就会出现不同的意见、看法和做法。这个时候，一个技术 Leader 能否开放坦然地接受这个局面，认可自己的意见、经验可能并不是最好的选择，在我看来，是一个团队能够走多远，一个 Leader 能够升多高的重要因素之一。

2. 坦诚沟通

沟通是我们透过表面去发掘更深层次的信息的一种手段，通过充分的、深入的沟通，我们才更容易发现彼此意见的关键分歧所在、问题的真正原因所在，而只有坦诚的沟通，不藏着掖着，我们才能够针对真实的、尽可能全面的信息去判断、去决策，从而能够更快速、更准确地解决问题。如果 Leader 不能够坦诚，团队成员不用多久就能够感受到，那么这个 Leader 可能就很难再得知到项目和团队的真实情况了。

3. 持续改进

敏捷里面的回顾（Retrospective）是非常重要的实践，也是建立持续改进文化的一个重要手段，但遗憾的是绝大多数团队都没有做好。举个例子，演示产品功能时，PO 或产品经理指出了一个问题，回顾不是说“这个问题是啥原因、谁在什么时间把这个问题修复掉”，而是说“为什么我们没有在更早的时间自己发现这个问题，而是到了演示产品功能的时候才由 PO 发现”。从中发现团队工作方式的改进点，这才是回顾的真正意义。

以上提到的这三个方面都是偏软技能的能力，培养、锻炼都不容易。首先要对这三个方面有意识，我们才能够想到要去观察自己在这些方面做得好不好，而这一点，通常都可以通过放慢速度来辅助。例如，讨论问题时，别人讲完话，强迫自己数 1-2-3，然后再讲话；如果觉得对方讲得不对，在讲话之前，提醒自己采取“我理解你的意思是……，我有些不同的看法，……”这样的句式，等等。

而坦诚沟通，在方法技巧方面，可以学习《非暴力沟通》一书中的方式，通过它建议的讲观察、讲感受、讲自己的需要、讲自己对对方的请求这个表达自己的套路，更好地、非暴力地表达自己的意思。

持续改进的方法技巧方面，推荐可以学习《敏捷回顾》一书中的相关实践并尝试落实，也可以考虑学习美军 AAR、《复盘 +》等相关知识，比如 AAR 的基本流程：我们打算做什么? 实际发生了什么? 成功之处是什么？不足之处是什么？有什么改进或创新的机会？下次我们将怎么做?

当然，知识是一方面，更重要的是一定要练，练的时候，最好找一位也在培养这些技能的你信得过的同道，让他 / 她来观摩你的实践过程，事后你们一起做一个迷你回顾，根据对方的反馈来提升你自己实践这些提升方法的能力。

总的来说，对于刚刚走上技术领导者（Technical Leader）类型岗位的员工来讲，要习惯从以往只要自己做好就一切都好的状态，转到大家好才是真的好的状态。而领导力，简单来讲，除了本身对技术的掌握，还要注意人员管理和沟通相关的内容，取决于不同的组织，未必你需要管理这些人，比如薪水、绩效等，但是你一定会需要负责让这些人能够理解和正确地使用技术完成任务。以前你可能 90% 以上的精力都投入在技术上，而现在，这 90% 中的 20% 甚至更大比例的精力，都要用于提升整个团队的技术能力，毕竟，你的 20%*1 个人，换回来的可能是 20%*9 个人的整体效率提升。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友。

作者简介

徐毅，华为云 DevCloud 首席技术布道师，华为 Cloud BU 软件开发云产品部、华为研发能力中心特聘敏捷专家顾问，前 IBM 大中华区敏捷及 DevOps 卓越中心主管，前惠普企业服务资深敏捷顾问，前诺基亚移动设备敏捷及精益教练，前诺基亚网络全球敏捷转型中心精益及敏捷教练，业内知名敏捷教练及顾问，IT 书籍译者。

第144讲 | 于艺：如何提升自己的能力与动力

你好，我是贝壳找房店面平台及客户赋能平台事业部总经理于艺，在之前的文章中，我分享了 B 端产品定位方面的一些经验与方法论。

在我看来，B 端产品不是用于娱乐或消费，而是让经营者、工作者更好的收获利益的，因此，B 端产品定位的关键是生存，一切相关的判断与决策都可以围绕这个关键点来思考。而在方法论层面，我们可以用财务结构定位、组织结构定位与实施模式定位等方法来做产品定位。然而，对于产品定位，我觉得只有方法论还不够，还需要提升我们自身的能力，才能更准确的对产品进行定位。

B 端产品经理的人才模型

要提升，就要先找到提升的方向和路径，我们先来看 B 端产品经理的人才模型，如下图：

首先，显性的是知识与经验，知识的来源可以是业务可以是互联网，经验则来源于工作及项目等经历中的积累，二者都可以通过不断学习和刻意积累获取到。

比如，我接触经纪人招聘这个系统的时候，对招聘这种业务只是参与过面试，但在专业角度一无所知，所以从招聘的知识角度，我不但调研了专业招聘团队的工作场景，访谈了招聘的上下游用户，还关注了大概 10 多个人力资源公众号，阅读了不少人力资源基础的书籍，甚至还有经纪人行业研究方面的报告和书籍。从经验角度，我开始自己尝试着招募经纪人，研究各种招聘网站，一个月在 boss 直聘上沟通了 2000 多个人，推荐了 100 多次面试，还亲自面试了很多人。从一无所知到一个多月过去之后，和一些城市的 HR 总监聊招聘业务时，对方会很惊讶，你一个做系统的怎么这么懂招聘业务。

其次，隐性的部分，藏在冰山海面下的是能力与动力，这两点是在面试过程中比较难衡量的，也是在自我认知中比较模糊的方面。因此，我们就针对能力与动力这两个点，就知己这件事分析它的方法论。

识别自己的能力适配性

先来看能力这个维度，我们可以记住这个公式：能力 = 实践 + 学习 + 洞察，在这个公式中，实践与学习可以得到知识与经验，因为知识可以通过学习获取，经验可以通过实践积累，就像我从招聘小白到被行家称赞懂业务，获取知识与经验并不难。那洞察又该如何理解呢？

“懂业务”浅层的理解，只是我可以像一个招聘专员一样作业，其实伴随深入的逻辑分析和思考，我发现其实很多招聘专员也说不清楚业务的本质，而这种“发现本质”的行为就是洞察。

当然洞察本身也有深浅之分，如上图所示，我们看待一件事情或者一个业务时，都有一个渐入的层次结构，由感知到角色到资源到能力最后到业务价值。再以前文提到的那个最初失败的招聘系统产品为例，首先我们获得了最表层的感知，也就是接到了要做一个招聘管理系统的需求，其次，我们知道了由谁来实现这个产品需求，以及有哪些角色参与。但我们当时的洞察就到此为止了，并没有更深一层地去判断这些角色能够利用的资源有哪些、在哪里，也没有去探究资源背后的能力是什么，以及最后核心的业务价值，也就是生存的源头在哪里。

这其实就是我们当时理解事情的层次不够，但老实讲，大多数普通产品经理的认知也就是到角色这层为止了，因此，普通产品经理很多时候就等同于功能经理，就是接功能、做功能，然后就没有然后了。

但如果我们利用上一篇文章中提到的方法论，利用组织模型定位方法，我们可以洞察到资源、能力这一层，也就是用户所拥有的资源给他带来的能力是什么，他们能做成什么事；而利用财务模型定位方法，我们可以洞察到最核心的业务价值。

我们回忆一下组织模型定位法，是观察用户所在的组织形态，用户的部门结构，他的上级是谁，上上级是谁，能拍板的人是谁，能决定他们绩效规则的人是谁。而在我们的例子中，招聘团队的上级就是招聘经理，一般向人力资源总监汇报，而人力资源总监是向城市分公司汇报，城市总经理对城市规则绩效有决定权。这就决定了招聘团队的“资源”最终是由城市总经理决定，或者实际上由城市的人事总监决定。那我们做产品的时候，必须搞清楚，招聘团队做什么、怎么做，其实和集团总部人事关系并不大，而是和城市人事总监关系最大，要从他们的需求出发，解决他们的痛点。

再说说财务模型定位法，我们分析招聘项目的时候，会从房产经纪行业的成本结构去看，原来人是房产经纪业务中最大的成本构成，也是最容易流失的生产资料——房产经纪行业的年流失率超过 100%。那么招聘肯定是每一个城市分公司非常关键的事，除非系统能明显的给招聘业务带来提效，否则仅仅从简单的实现线上化管理、规范招聘流程的角度看，城市总经理一定会掂量，规则和生产效率的轻重，决定是否参与和支持系统的建设。但如果我们的产品定位是主打提高招聘效率，那根本不用什么推广，城市总经理都会自己找上门来希望合作。

总之，你的能力越高，能够到达的层次就越深。如果你需要衡量自己的洞察能力，可以参考这个分层结构度量自己能够到达哪一层。如果你想刻意练习提升自己的能力，我特别推荐一本书，是日本作家大前研一的《思考的技术》，书中提供了一种全新可借鉴的思考方式。

大前研一指出，我们能看到的事物大多只是现象，而非原因，原因一定是思考后产生的。而思考是一门技术，是可以刻意练习和提升的。例如当他在乘地铁时，看到地铁拉手上的广告，就会刻意去思考，这个广告一年市场规模和利润率应该如何测算，并且在一周内真的找到了在拉手广告公司的朋友验证自己的猜测。正是一次又一次的刻意思考和验证，锻炼了自己的洞察事物本质的能力。

识别自己的动力适配器

再来看动力这个维度，我认为动力 = 热爱 - 恐惧，因为动力源于发自内心的热爱，但很多时候这种热爱都伴随着恐惧。举个例子，我热爱演讲，可我并没有成为一个演讲家，就是因为虽然我发自内心的热爱公众给我的正向反馈，享受这种成就感，但是我也害怕在公众面前做演讲。所以，当我们内心不再恐惧，就能够有动力去做自己热爱的事情。

其实，从心理学角度讲，动力是最难改变的底层价值观，但是在职业生涯中，当我们在进行行业的选择时，这个底层动力还是比较容易被改变的，它的逻辑就是按照动力公式，缩小恐惧，扩大热爱。

我们首先需要清楚热爱和恐惧二者的来源，再有针对性地解决问题。热爱源于视野，我跟很多朋友聊，发现没有具体爱好的人是大多数。工作中，和同事聊，发现大部分人除了爱好成就感、有挑战之外，很难讲出更具体的细分的行业、职业或者某类行为。例如，到目前为止，接触了十几位招聘岗位上的从业者，很少有听到人说，我把做好招聘当作自己热爱的事业。

那我们到底热爱什么呢？一定会有，只是我们没有体验到而已。小朋友选兴趣班的时候，父母都会说试试看，舞蹈、围棋、美术、击剑、足球、篮球……尝试了很多后，一般都能发现一个喜欢的。而在成人的世界里，我们并没有再抱有这种目的去体验不同的事物，所以也越来越不知道自己热爱的到底是什么。

但归根到底，不论大人还是孩子，眼界越宽，体验的事物越多，就越容易知道自己的兴趣所在。相信只要识别了自己动力的源泉，拥有热情的必要性，刻意的去开拓视野，你也可以发现自己真正热爱的事物或工作。

而恐惧源于能力的不足，为什么我害怕在公众面前演讲呢，表面原因是害怕被笑话，其实根本原因是认知到自己不专业、能力不足，因此恐惧，那我就需要通过提升自己的能力来缩小恐惧。最终，动力等于热爱减去恐惧，不是光看你爱什么，还要看你看你怕什么。

总结

本文分享了 B 端产品经理的人才模型，以及如何在能力和动力两个维度提升的方法论。其实，专业选手和业余选手最大的区别就在于正确的方法论加刻意的实践，这两点可以有效提高我们的能力，若是再扩大视野，就可以让我们不论是选择 B 端产品、C 端产品，还是选择技术方向，都能获得不错的提升与成就。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

于艺，贝壳找房店面平台及客户赋能平台事业部总经理，致力于用互联网的产品技术帮助贝壳平台上的加盟商更高效的开店，更高效的招人育人。之前在链家负责链家网上海 app 的研发工作，在经营分析系统、楼盘字典、真房源和 O2O 的行为追踪方面有诸多创新。

第145讲 | 李列为：技术人员的商业思维

你好，我是华博 CTO 李列为，雨后的下午，坐在办公室，闷得慌，极客时间的编辑小靖正好发来消息，要约稿，聊聊技术领导力这个话题，我想，好啊，我就聊点“非主流”的话题吧，谈谈技术人员的商业思维。

以前，做基层员工，写点代码，小日子就过得挺安逸的，可是，积极工作之后，还会有其他的战利品，老板除了给你加薪，还会给你更多的任务和责任，特别是，到了 CTO 这个岗位，考虑的，就不仅仅是做好技术支撑工作，更多的是需要根据公司的宏观战略，参与讨论后续的业务定位、组织结构、管理方案，到那会突然发现，只懂技术是不行的，还要懂社会科学、懂商业世界，否则，混不下去啊。

那就让我用技术的眼光，来看看商业世界，或许，还是挺有趣的一件事。今天，聊三个方面：
1.IT 行业的发展， 从单机软件到云服务，再到“云 + 端”的模式，用这一技术演进过程来理解商业世界的变化：“从小而全的小店铺模式，到社会共享“商业大脑”，再到全社会的“脑力 + 体力”的分工协同”；
2. 用 IT 产品建模的思想，来解决管理中的问题，用软件的“器”来落实管理哲学中的“道”；
3. 用微服务架构思维来管理公司众多资源。

从共享到分工

2000 年以前，中国几乎没什么电子商务，成千上万的小老板们开着自己的实体小店，走南闯北的找货、卖货，辛苦地管理着店面，他们都很累，因为信息不畅通。直到 2003 年，淘宝网出现了，马云计划把所有的小商家搬到网上，并立志“让天下没有难做的生意”，他没有自己做物流，没有自己做产品，他做的是信息撮合平台，都是软性的工作、“大脑”的工作。我们可以理解成，马云创建了一个“商业大脑”，把海量的商品和海量的客户进行统一管理，如果说，原来线下小商铺是“小而全”的垂直模式，那么，淘宝网，就是将所有商铺做了一次水平切分，上层是共享的商业大脑，下层是商品和客户，软硬件进行了分离。

然而，这种水平切分，不能解决所有问题，那些重体验、重服务的商品，就很难全部搬到网上，于是，分工又出现了。

2014 年开始，微商开始涌现，云集、环球捕手等一批微商型公司你方唱罢我登场，拼多多也上市了，我们发现，电商行业又变了，开始“分”了，这次的“分”，和之前的共享，不是一个逆过程，而是分工。微商们只做销售的服务环节，其他环节都是总部集中处理，这就像软件业的发展一样，从单体应用，到服务“云共享”，再到云 + 端（边缘计算）的模式，都是那么的相似。

从共享到分工的变迁，在服务器架构里，同样出现了。2010 年左右，阿里云出现，把算力进行了共享，形成了全国算力的大脑，推动了中国云计算的步伐。近年来，随着 AI 技术的发展，数据量暴增，若把所有数据全部集中到云端处理，是不现实的。于是，“分工”出现了，边缘计算将一些图像、视频流数据，在终端进行了结构化处理，与云端进行了很好的分工协同。

这种“共享大脑”之后的产业结构大调整，已经在各行各业发生着，阿里云王坚博士说，他们在建设城市大脑，以后还会建设城际大脑、国家大脑，我想，通过这些大脑来调配社会资源、劳力，让社会运行效率最优，是完全可能的。

单体资源的使用，都有负载“峰谷”，而这种情况，也造成了资源的浪费，共享，可以实现“削峰填谷”，资源使用得以平滑。因此，阿里云就像是一个算力工厂，在白天，大量的机器为电商、服务业、制造业服务，夜间，可以把富余算力用于 3D 影片的渲染、DNA 的测序等无时间限制的业务。

共享，在信息调度方面，也能帮助物流企业实现资源的最佳配置，譬如：江苏有人要寄一件快递到新疆，希望以最快的速度送达。在传统方案中，没有一家物流公司能在 2 天内实现这一需求，但是，菜鸟网络可以，它可以调取江苏最好的揽件服务商、全国最合适的干线航空运输商、最快的新疆落地商进行联合服务，全自动的实现资源最优的调配。当然，价格可以比传统价格高 N 倍，真正实现的“分级定价”。反之亦然，如果客户购买的是“计划性商品”（不着急使用的，有采购计划的，如冰箱等），那么，物流大脑可以调配最便宜的运输资源来配送。

社会体系从无数个“小而全”的单体，到计算大脑的共享集中，再到全社会的大分工，或许，就是因为技术的发展，造就了社会的变革。我们可以预见，接下来的几年，垂直行业的各种大脑型公司还会不断产生。陈春花老师最近出版了一本新书：《共生》，其中描绘了命运共同体，描绘了协同管理、协同赋能，技术重构组织形式，这一切，正在我们周围发生着。

我画了一张图，右侧是社会碎片劳动力，左侧是碎片资源，而各大公司都在向上走，争做“大脑”。今年下半年，很多金融公司在改名，譬如：京东金融，更名成京东数科，蚂蚁金融云，更名成蚂蚁金融科技，除了金融管控越来越严格以外，或许，大家都意识到了，要做行业的大脑，所有权不重要，重要的是控制权，拥有行业控制权，商业利益才能得到保障。

猛然间，公元前 300 年，孟子的一句话在我眼前浮现：劳心者治人，劳力者治于人。

用软件的建模方法来落实管理哲学中的“道”

我常和我们的技术团队说，我们处理问题的原则是：发现一个问题，解决一类问题，其实，把这句话做逻辑分解是：发现一个问题，进行归纳建模，抽象成这类问题的普遍特征，然后，设计软件模型，统一解决它。

哲学和 IT 技术是相似的，哲学解决问题的逻辑是：从归纳到理论，再到演绎，IT 技术解决问题的逻辑是：从 梳理抽象逻辑，到建模，再应用到这一类的场景，都是从“特殊”到“一般”再到“特殊”的一个过程。但哲学和 IT 建模也有区别，哲学更偏向于“道”的层面，IT 建模则偏向于“器”的层面。我们常说“道法术器”， 只有道，没有器，没有具体的步骤和工具，是很难落实和执行的。我们需要用 IT 建模的思想，来帮助管理者解决管理思想落地的问题。

前些日子，我们公司老板发火，因为公司组织的一次海外旅游，结果，有几个高管缺席，造成了公司资源的浪费。按传统的做法，行政部就事论事，出个规定，或者，教育一下就结束了，但我们发现，这种做法，几乎是无效的，因为，下次旅游的人不一定记得之前的教训，下次组织活动的行政人员，也不记得这些细小的规定，那怎么办？

我们在 OA 上建立了一套管理流程（建模），把这类管理，纳入福利类，从确认参与某一活动时，就签订一个线上契约，并冻结一定的工资金额，直到正常参与活动结束，有点像我们 TGO 鲲鹏会组织活动时那样，这样，管理模型出来以后，大家养成了习惯，这个问题就能真正的解决。

因此，在具体管理方面，IT 技术，或者说，数字化管理，更具操作性，比总结的哲学理论，更量化，更可控。如今，我们又有一个新的观点，那就是：公司有制度，手中无制度，因为，制度都已经潜移默化进了 OA 中。

如今，在移动互联网的大潮中，我们发现，管理方式也发生了很大的变化，特别是针对年轻的一代，管理需要更加游戏化、扁平化、碎片化，那唯有软件工具才能真正展现这种思想，软件模型相比传统制度，最大的好处是：易操作、有积累、能传承。

譬如，我们的企业文化，提倡创新、学习、互助，传统做法是，张贴条幅或海报，但发现，这种形式只能落灰，几乎无效。我们通过在 OA 上建立了一套投票流程，每人每月发放 10 张点赞卡，一月内必须全部发出，对接受点赞卡的同事，必须做符合公司价值观的点评，对于点赞最多的同事，公司给予不同的奖励，也作为年终评级的标准之一。这种游戏化的相互鼓励形式，效果很好，也强化了公司的核心价值观。这些，都是数字化管理给我们带来的福利。管理思想是软件的灵魂，建模，是把思想通过“器”的形式展现出来，润物细无声地体现出来，没有灵魂的软件，是没价值的，没有“器”的思想是空中楼阁。

用微服务架构思维来治理公司的众多资源

现在微服务架构在软件开发行业里非常流行，微服务讲究的是：高内聚、低耦合、可复用，这样的思路在企业管理里面也同样适用，比如，我们集团公司下面有很多子公司，每个子公司都有自己的业务，都是一个项目的主体，是个“小而全”的业务单位，这有点像 SOA，然而，这样的颗粒度还是有点大。有时，A 公司在赶一个项目，B 公司恰好在闲置期，A 公司通过业务的运营，积累了一定的金融风控能力，具备了对外输出的要求，B 公司也有需求场景，却无人知晓。

基于这样的情况，我作为集团的技术管理者，将各公司的能力量化、降低颗粒度，并制定了调用结算标准。譬如：各公司间，技术人员可以相互借调，按 1500￥/ 天计价，同时，将各种能力做公示，如：短信通道能力、金融风控能力、聚合支付能力、产品供应链能力等，上架到集团的公共资源平台，所有子公司均可方便调用，这是不是和微服务的思想一致？

各种独立的微服务能力，有点像扑克牌，每个公司都有一些牌，每张牌都有它的价值，如果把这些牌进行不同的组合，能产生对子、顺子、葫芦、同花顺等等，通过整合，可以让它们的价值得到充分发挥。其实，小到软件项目管理，大到国家治理，不都是在朝“三提一降”（提高效率、提升体验、提高品质、降低成本）的方向走嘛，技术的思想和企业管理思想是可以相互借鉴和演绎的。企业向平台化发展是必然趋势，每个企业都应该是一个微服务框架，逐渐积累自己的各种能力，然后让新的成员入驻，孵化新的项目，调用平台能力，在过程中，再积累新的平台能力，螺旋上升。

技术人员的商业思维，不仅可以把技术的逻辑思维方式用于对商业环境的剖析，也能更好地解决管理中的各种问题，因为，在“道”的层面，一切道理都是通用和相似的。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

李列为，华博集团 CTO，TGO 鲲鹏会会员，在消费金融分期、B2B 电商、新零售等领域拥有丰富经验。目前负责华博集团，蜂华智联 BG 的业务，分管新零售、智能产品开发等工作，曾任江苏峰云研发总监，曾创建创建南京宁网科技有限公司，成为江苏第一的增值服务提供商。

第146讲 | 刘天胜：打造高效团队，关键在于平衡人、事和时间（一）

你好，我是上海讯联数据 CTO 刘天胜，除了负责公司研发团队外，还负责一个数据营销事业部，为商户提供新零售营销技术和运营服务。前几天恰逢代表讯联营销技术团队到客户海底捞国际控股有限公司领取《2018 年最佳执行力 IT 供应商》奖项时，收到了极客时间编辑的约稿信息，就“如何打造高效团队”的话题与大家聊聊。在分享我的心得之前，我想先对“高效”二字，谈谈我的认识。

上海讯联数据作为一个 toB 企业，致力于激发每一位员工，尽我们所能帮助客户成功。在这样的企业价值观下，我们一般评判团队是不是高效，主要看这个团队是否能投入最少的人，在最短的时间内高质量地完成客户所托付给我们的事情，而不是当我们想要做事时给出这理由那理由迟迟不行动甚至阻碍事情启动，或者没有安排事情的时候就无所事事不主动去寻求优化改进。

如何做到高效呢？我认为团队需要平衡好“人”、“事”、“时间”之间的关系。三方面平衡得好，客户反馈好，续约率高，公司投入产出比小，公司管理团队觉得业务在发展，这才具备成为高效团队的条件。而且，如完成的是原本认为不可能完成的任务，那就有资格评选为卓越高效的团队了。比如，我们本周获得最佳执行力奖项的团队，在我们为海底捞搭建的全渠道营销中心项目中，不仅按时保质保量的完成了项目任务，获得客户领导好评，还利用很短的时间对我们已有的营销产品进行了架构优化升级，使其能承受数倍流量的冲击，当然就有这个资格。

不过，在现实中，特别是 to Big B 的研发团队，想每个项目都做到“投入最少的人”、“用最短的时间”、“高质量地完成任务”三者兼得是非常复杂和困难的事情。只有在打造团队时有意识的用好人、管好事、控制好时间，才有可能使团队向高效团队演进，让更多的项目成为经典。那么，类似团队，我们是如何培养的呢？

概括而言，我们通过以下几个方面入手。

“人”

在“人”方面，需要做到以下几点：
1. 招人不将就，宁缺毋滥
一个团队，绝不是人越多越高效，务必保持精干。像我们获奖的这个小团队，就是一个精干的小组，每位成员都很棒。

而做到这一点，首先要把好招聘关，这一关耗费再多的笔墨都值得。回顾团队的招聘时，有三种方式最有效能找到合适的人。一靠内推，二凭彼此的感觉，程序员有种很特殊的气场，甚至看手型和坐姿都能发现那种特殊的气质，不过，别想歪了哈，不是“屌丝”气质，正相反，我一直觉得优秀的程序员都是艺术家。那种气质，是一种描述起自己喜欢做的事儿两眼放光或者解决起问题来会入定的状态。在第一面感觉不错的前提下，如果聊下来很顺畅，对一些问题产生了共鸣，彼此认可，那人就找对了。这样的同事，工作时有默契，对于自己不懂得方面也可以快速学习，不会推三阻四，团度协作也变得更加简单高效。

除了上述两种方式，还有第三种，因为我们研发团队主要使用 Golang，所以，我们在招聘时还会问应聘者对 Golang 是否了解，愿不愿意学，愿不愿意转。这个问题是非常重要的，我们目前研发中心的四五十位 Go 开发工程师无一例外都是从其他语言转过来的。水平的高低先不说，如果没有主观意愿，不是多语言爱好者，根本无法坚持下来。

同时，应聘者只回答愿意学是不够的，还需要重点考核应聘者最基本的计算机高级语言和数据结构。因为基础厚的应聘者后劲足，不挑活，成长的很快，所以面试基础知识不能绕过，也将就不得。当然，不同的团队招聘要求是不一样的，一般而言，产品研发团队更注重计算机基础和动手能力，项目交付团队更注重对流程规范的了解和遵守，总之，团队负责人需要对自己要招聘的人员要求有清晰的认识，不能人云亦云，适合自己的才是最好的，不能将就。

2. 因材分派任务，制定成长目标
一个高效的团队，离不开团队负责人与团队成员的紧密配合。团队负责人一定要利用面试时和日常团队管理过程中的 1v1 机会，充分了解团队中的每一位成员，包括性格偏好、家庭情况、技术能力、发展规划，然后才能更好的根据个人情况分配任务。人和任务匹配的越合适，任务完成的越高效。但是，如果实在做不到 100% 的人和任务匹配， 也可以通过对每个人的了解以及根据其抗压度来分配任务，这样尽可能地确保团队的执行力，进而实现目标。

例如，我们团队中有一位前端小伙伴，非常希望做小程序开发，但所属小组没有相关的开发任务，而所属小组所分配的任务又是他最不擅长的前端框架 Angular JS，所以，一直不太匹配。后来我知道以后，通过及时的人员对调，既发挥他的所长，又舒缓了所属小组的人员瓶颈，一举两得。

同样地，作为一个团队管理者，还需要和每一位直接下属和部分二级下属一起讨论出他个人的成长目标，并在日常工作中保持一致性，帮助他、引导他、甚至督促他坚定地向团队与自己达成一致的发展目标迈进。具体而言，在制度上，我们是这样做的。首先，我们要求团队管理者需要定期与下属员工有正式的 1v1 面谈和团队会议，有问题及时指出，摆在桌面上。其次，在平时，员工的日报、周报、项目进度报告等邮件必须抄送上两级主管，同时，我们要求每一位主管不论再忙，必须阅读下属两级员工的邮件，并根据对该员工的定位，及时地、有针对性地进行指导和纠偏。

当然，每个人都是有惰性的，在下属的成长方面，千万不要不好意思给压力，也不要指望每一位下属都自觉向着目标前进、成长，很多同事虽然潜力很大但有时也需要引一下，甚至逼一下，所谓“扶上马送一程”就是这个道理。

我们团队中有一位老同事，工作非常努力，自身工作完成的很优秀，也非常愿意挑战新任务，但做新任务时的产出质量却很一般。经过一番提醒、引导，甚至“犀利的批评”让其意识到自己在新任务上的不足后，我发现他通过自学和到处虚心求教，在短时间内工作结果就上了一个档次，现在已经基本驾轻就熟了。在这个过程中，我虽然做了一次“坏老板”，但结果是好的，同事也获得了成长，值得。很多时候就是这样，我不做恶人，谁来做，总比碍于情面不说，让客户吐槽好吧。

总之，对于 toB 企业来说，丢单是最大的恶，帮助客户成功是最大的功。我们公司所有人，包括老板和管理层，都在不断成长，努力让自己服务客户更专业，以获取更多的合作机会。

3. 能力互补，分工明确，多沟通跨越边界
在一个团队中，每个人的分工必须明确，管理流程如需求流程、评审流程、变更流程、请假流程等要清晰，这样每个人才能专注地做好自己的事儿。当然，任何制度安排都有利有弊，有时也会衍生出很多边界，既有谁也不愿意干的三不管地带，也有互相交叉的模糊地带。

比如，我们开发的讯联灵犀平台是一个给商户使用的全渠道营销平台产品。它包含了多个模块，其中有相对成熟独立的模块，也有公共的或新衍生出的模块。每个独立模块都有明确的负责人，但限于人力，有些公共模块未能及时明确归属。而这就成了三不管地带，经常出现一些问题，如代码合并冲突、功能找不到人做甚至互相推诿等，后来通过交叉任命两人并明确主次职责，这种情况得到大大改善。

类似的，对于尚在发展中的团队而言，这种限于人力无法及时明确职责的情况其实有很多，但三不管状态是不允许的，只要发现，就需要想办法解决，甚至立刻召集开会，重新明确边界，否则该地带会长草生锈，代码腐烂，而采用这种交叉任命的方式过渡，虽然交叉的边界依然是模糊的，但执行力会高很多，还可以促进跨团队沟通。多做事的同事会觉得自己越来越受重视，被分配事情较少但性格不错的同事会觉得自己不好意思少干活，也会主动分担一下，于是，这个团队既提高了积极性，又提高了凝聚力。

4. 要求复盘，鼓励分享
复盘和分享对于一个成长中的团队来说，非常重要，只有不断的复盘，才能总结经验和教训，沉淀业务与技术知识。团队成员通过多复盘多分享，将日常项目或产品研发过程中零散的知识点串联起来，才能完善自己的知识体系，真正提升一个层次。同时，其他团队同事也能从中学习经验，吸取教训。

另外，在鼓励分享时，要鼓励员工多分享思考的过程和思维方式，跟大家分享当时遇到了什么问题，是怎么解决的，当时的考虑都有哪些，而不只是讲结果，歌功颂德。只有更接地气更有干货的分享，团队才能学到更多的东西，不断提升战斗力。

举个例子，我们曾经丢了一个跟进近半年的客户，通过复盘，我们发现在整个过程中虽然我们很努力的在准备提案，但一直在被动的应变，没有从专业角度为客户着想，没能从客户的场景入手，主动设法推进这个方案的落地。认识到这个问题后，在后面的提案中，我们开始有意识地将自己的方案根据对客户的了解，有针对性地做出调整，反馈就好了很多，团队也有了更多的成就感和信心。

5. 定期团队建设，关键时刻庆祝
团建的重要性就不用多说了，及时的庆祝，定期的娱乐，才能更好的工作，使团队凝聚力愈来愈强。吃饭唱歌这是必须的，但我特别想提的是日常的一些小庆祝。比如，下面这张图片是拍摄于近期的一次半夜变更，其中一位同事在准备变更方案，另一位同事打印出一个荣誉证书给他，并手写评语，另一人拍照。像这样的半夜变更，夜深人静，人困马乏，还得保持高度清醒，确保变更顺利，很辛苦，很不容易。而通过这个图片分享，即使没那么正式的庆祝，但整个团队也立即活跃了起来，氛围很好。

由于篇幅受限，关于“事”和“时间”方面，我将在下一篇文章中与你分享，欢迎持续关注。感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

刘天胜，TGO 鲲鹏会会员，上海讯联数据合伙人、 CTO 兼数据营销事业部总经理，曾任 Cadence 顾问工程师，拥有十一年软件开发和项目管理经验，在技术领域的高可用高并发、微服务架构、信息安全、智能推荐、性能优化、研发流程改进等方面有丰富经验，共享软件 Compare++ 作者。

第147讲 | 刘天胜：打造高效团队，关键在于平衡人、事和时间（二）

你好，我是上海讯联数据 CTO 刘天胜，我认为打造高效团队需要平衡好“人”、“事”、“时间”之间的关系，在上一篇文章中，我分享了我们团队在“人”这方面的经验和做法，今天我们继续来聊一聊“事”和“时间”这两个方面。

“事”

人对了，事就成了一大半儿，但也需要注意以下几点：
1. 方向明确
任何一个团队，不论是做产品还是做项目，都需要有方向。方向要明确，不能什么都做，而且对于团队目标，每一位团队成员也都需要知道。这方面，我们踩过一些坑。比如今年年中时，我忙于业务，洽谈商户，疏忽了与团队沟通，没有及时就“做什么事”，“为什么做”与团队交流。我自己本认为事情安排得当，团队也知道方向，但直到有两位骨干连续离职时，我才猛然发现这是幻觉。虽然团队成员都很优秀，但当大家不知道方向时，做的越多错的越多，疲于奔命但又没有成就感。大家都想着赶快离开了，因此，我们需要明确团队目标，并达成一致认知。

2. 目标清晰
事情安排需要清晰明确，同时需要具备可行性。自己都感觉模模糊糊的事情最好不要分派给下属，否则对方要么无所适从，要么不当回事，不会引起重视。当然，有些事情本身就是调研性质的，需要调研之后才能搞清楚，但就算如此，安排事情也需要交代清楚，明确下属需要完成的目标，这样才能保证效率和方向正确。

举个例子，我曾经安排给同事一个任务，让他调研一下某渠道的能力是否可以帮助我们的灵犀营销平台，结果是不了了之，让我很生气，怎么能把我的话当耳边风呢。后来经过 1v1 才知道，这位同事一来不知道我想调研这个渠道什么方面的能力，二来不知道什么时候交付，手头又忙，一忙就忘了。经过沟通，我明确调研目标和时间要求后，效果和效率就好了很多，而且也没耽误其他排期的任务。

3. 优先级一致
作为团队负责人，任何时候面前只要超过一件事，心中肯定有优先级之分。这个优先级需要清晰明确的告知团队，并且就此与团队达成一致，避免因信息不一致或者大家的认识不同，引起不必要的扯皮，耽误事儿。

“时间”

在“用好人”、“做好事”之前，特别是对于 toB 服务这样甲方话语权很大的行业，时间安排是否合理非常重要。就像我们安排一位同事写一个 PPT，安排两天写完与安排下午两个小时写完，准备出来的稿子一定是不一样的，甚至千差万别。

为了留给团队更多的时间，我们是这样做的：
1. 统一阶段性目标和排期
每个月的最后一周，我们都会安排一次产品功能讨论会，来讨论并确定下个月计划安排的主要产品和项目任务以及优先级，让团队提前心里有数，提前做些技术预研，尽可能的避免内部产品开发任务“从天而降”，搞突击是需要尽可能避免的。

2. 留出弹性空间和人手给项目
toB 服务的产品以通用功能为基础，但也总免不了一些个性化开发需求，因此，经常会有项目突然要立项。此时，在第一项统一阶段性目标的基础上，对人员和任务的安排要保留弹性，比如，我们的研发团队会提炼一些重要但没那么紧急的内部优化任务填满工作量。当紧急项目来时，将没那么紧急的任务往后排，人手就好腾出来做项目。

3. 靠技术提升生产效率
平时，鼓励团队多开发一些提高效率的小工具，例如自动化测试脚本、部署工具和一些解放人力重复性工作的小程序。

比如，我们为商户提供营销代运营服务时，在举办一次营销活动后都需要提取活动数据。之前，都是运营同事登录渠道的 Web 平台人肉提取，但由于渠道的限制，每次只能提取 1000 条，而每次活动动辄几万甚至几百万条数据，导致提取数据非常耗时。每次活动，我们的运营小伙伴都要崩溃。后来，技术同事开发了一个小浏览器插件，自动化提取，人力一下子解放了，原本两天的工作量一分钟就搞定了。突然感觉世界真美好，这是一件多么让人快乐的事情！

4. 减少事务性时间消耗
尽最大努力减少员工特别是技术同事在一些公司事务上所花的时间，例如打的报销，贴发票等。技术同事出差次数少，报销流程也经常记不住，贴发票经常会贴错，需要返工，经常一次报销大半天功夫就没了。仔细分析原因才发现，大家出错的情况都很类似。

为了改善这种情况，我们鼓励每个小组将报销事项汇总到某一位同事（最好是女生或者团队负责人），由一人来统一报销，这样就好了很多。当然，有人会说，你们欺负女生。“其实～我也可以帮你解 bug 嘛”，所以，实践下来还是不错的。大家可能觉得这个事情很微不足道，不值一提，但做好了其实可以节省不少时间，也可以塑造互帮互助的团队氛围。

总之，打造一个高效团队需要协调好“人”、“事”和“时间”，要有制度，但又不能完全依赖制度。有的地方是科学，有的地方是艺术，有的地方是哲学，但更多的地方需要用心。用心与团队一起成长，协调好三者之间的关系，提高凝聚力，使自己的团队越来越高效地完成客户和公司交给我们的任务。如果你有任何疑问或不同观点，欢迎在留言区和我讨论。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友。

作者简介

刘天胜，TGO 鲲鹏会会员，上海讯联数据合伙人、 CTO 兼数据营销事业部总经理，曾任 Cadence 顾问工程师，拥有十一年软件开发和项目管理经验，在技术领域的高可用高并发、微服务架构、信息安全、智能推荐、性能优化、研发流程改进等方面有丰富经验，共享软件 Compare++ 作者。

第148讲 | 肖德时：创业团队技术领导者必备的十个领导力技能（上）

你好，我是容器技术专家、前数人云 CTO 肖德时，今天想跟你分享创业技术团队的领导力打磨之路。

领导力这个东西，对于我来说也是近些年才注意到的一门技能。它代表着技术人的成熟度能力和对团队的把控能力。就什么是领导力这个问题，每个人心里都有自己的定义，我这里拿纽约时报畅销书作者凯文. 克鲁斯 (Kevin Kruse) 的一篇领导力文章中给出的定义来给大家一个参考：

Leadership is a process of social influence, which maximizes the efforts of others, towards the achievement of a goal.

领导力是一种社交影响力的过程，就是可以让团队成员可以最大化发挥自己的能力，并朝着实现一个共同目标努力。

在参考这个定义之后，我们知道领导力和领导显然是两码事，但是往往新上任的领导在满足个人荣誉的过程中迷失了对这种能力的训练，导致很多有经验的人，包括我在内，都会或多或少的犯一些领导力方面的错误。所以，当你看到这篇文章的时候，我期望通过梳理出来的一些最佳实践和参考建议能给你一些好的思路，帮助你更好的发挥你的领导力。

领导力技能一，善用同理心技能给员工最合适的任务

在国内大概只有在大公司待过，你才有机会接触到专业系统的领导力培训，我有幸在红帽工作的时候上过这类课程，也让我能在懵懵懂懂中开始运用一些领导力的方法来和团队其他成员协作。

后来离职加入创业公司之后，在业务饥渴的阶段，我的团队成员往往都是临时搭班子组建的草台班子，大家都是第一次合作，很难让所有人都能理解这些领导力技能相关的事情。所以，当我变成领导的时候，底下缺乏领导力技能的同事经常无脑执行我安排的任务，我想这大概是创业公司的普遍情况。我记得在阿里创业历史的视频中，马云在一次淘宝团建中说过这么一句：“不要怕犯错，只要坚决执行下去就可以成功。” 想想在缺乏合适的领导力培训的环境下，这其实不失为一种有效的办法。

当然，缺乏领导力技能最大的危害也是显而易见的，有很大概率的可能是员工需要花费大量精力来理解和支持你的决定，并可能私底下还要花很大的力气才能实现制定的目标。作为领导的你，可能才华横溢，那能否用一种领导力方法来缓解甚至解决这种困境呢？这里就需要介绍领导力的第一个技巧，同理心。什么是同理心，就是从别人的角度来想问题，给手下最合适的任务，让他去干擅长的事情。

同理心，不是发慈悲，而是一种策略。它要求你能了解下属的能力，并善于发挥下属的能力。在创业公司，人少活多的状况下，大家一定会遇到这样的场景，所有的事情都是开创性的，时间紧任务重，但手下有些员工可能唯唯诺诺，缺乏自信。如果你的团队中发现这样的人，应该立刻和这位员工交流，梳理他的能力范畴，帮助他规划成长的路线，给他设定一个成长目标，并定期维护这个成长计划。这些工作其实很繁琐，但却是你每天都需要用到的。而正因为枯燥繁琐，在和员工接触的时候，如果没有同理心，你很难完成这些计划的制定和培养，也很难拿到第一手的反馈。所以，同理心技能是一项非常重要的领导力技能。

领导力技能二，设定合理目标的能力

创业公司野蛮生长，业务目标时刻都在变化中。其实本质上创业公司的目标一直没有变，就是业务要增长，公司要赚钱。所以，作为创业公司领导的你，就需要锤炼自己实现目标的能力。另外，由于创业公司大都是小规模团队，所有做的东西都可以快速反馈出你的能力，所以，在制定你个人工作计划的时候，一定要有设定合理目标的能力。

而要锤炼设定合理目标并将其实现的能力，就需要有一把尺子来衡量结果，其实创业公司的衡量标准就是业务成长，能赚钱，其他都是务虚的。创业公司真没有必要去模仿大公司组织没用的团建活动，踏踏实实的解决生存问题是最好的收获。

另外，创业公司往往因为项目管理软件的缺失，沟通基本靠口头交流，所以，很多任务的制定和执行都是没法追踪的。作为解决方案，创业公司可以考虑采用一些 SaaS 团队管理工具来完善自己的工作流链条。

领导力技能三，及时反馈的能力

创业公司在不断发展的过程中，人数开始飞速扩张。人与人之间的关系开始变的复杂。由于工作的繁忙、沟通的缺乏，团队之间、员工和领导之间，都很容易出现无形的墙。此时，作为创业公司的领导者就需要具备能反馈信息的能力。

可能有人会觉得这点很奇怪，不就是回话吗，有什么技能一说。其实想想就能理解，在创业公司，大家都是一个人干好几件事情，其他部门或者同事给你交代的事情，你其实很难完全理解，都是在被动中被推动着前进。这其实并没有错，抓大放小么。但是在信息流的传播中，就不能抓大放小，尤其对领导者来说，更是如此，任何员工对你的反馈都是他个人比较看重的地方。

在具体做法上，你可以公开一个邮箱，让员工可以随时给你发邮件诉苦和吐槽，你也能及时通过这个渠道反馈你的想法。作为一个重要的领导力技能，要做到任何同事给你的反馈，你都能反馈信息给他。很多创业员工都是到实在干不下去要离职了才和领导见上一面，等真到这个时候，你再反馈就已经晚了，可能之前就已经在无形中伤害了你的团队，浪费了人才，导致你不得不时刻要招募人才，体会到人才缺失、人手不够的痛苦。

领导力技能四，持续创新的能力

如果没有持续创新，人很难开阔自己的眼界。固步自封只能让创业公司完蛋，创业不进则退，一旦退步，本质上就是你这个领导不称职，导致底下员工也无法晋升上来。所以，创新能力是一定要自我磨练的。

作为技能来说，这种创新能力并不是指发明一个技术，或者是写了一大堆新算法，而是涉猎广泛一点，在尝试解决公司难题的前提下，能不断的小步尝试一些未能证明的假设。这些假设可能很傻，但是你要自己去尝试。可能 100 个假设中有 20 个假设能成功，那么把成功的假设加以总结和推广，就是一种强有力的创新能力。它可以帮助你更好的实现业务目标的落地。

这里最关键的地方不是追求新东西，而是在你现有能力的基础之上去强化和丰富你的能力。在很多现实例子当中，大家很喜欢学新东西，美其名曰调研，但其实很多都是对业务没什么用的东西，让你的技能更强的能力才是真的创新能力。

领导力技能五，有担当的能力

任何人都会犯错，谁来承担责任呢？肯定是领导来承担责任。但是我想讲的不是职责问题，而是技能层面的东西。从技能的角度出发，担当的技能就是当员工的陪练，带着这个员工一起成长。很多大公司在新员工入职后，都有师傅制度，就是一个资深的员工，带着几个新手一起干活。这样既能让新手员工放开手干，也能让老员工发挥自我实现的价值。

这个时候，如果这个老员工没有担当的能力，很可能就是一个分任务的机器人，把团队成员都给带坏了。这种能力不是天生就来的，需要老员工在接到这个任务的时候了解到有担当的能力是需要培养的，也需要领导先带着这些老员工，把他们担当的能力先锤炼出来。怎么验证这个能力呢？我觉得大家心里都有一杆秤，如果经过 1 到 2 个项目，成员被磨练的可以完整支撑一个业务的时候，就可以算是出师了。如果成员并没有什么起色的话，你的有担当的能力就没有发挥好，就要继续去锤炼了。

结语

领导力是一种需要训练的技能，我在打磨自己领导力的过程中，梳理出了十个需要磨炼的领导力技能，本文分享了其中的五个，分别是同理心技能、设定合理目标的能力、及时反馈的能力、持续创新的能力、有担当的能力。

由于篇幅有限，剩下的五个领导力技能，我将在下一篇文章中与你分享，欢迎持续关注。感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

肖德时，TGO 鲲鹏会会员，容器技术专家，前数人云创始人兼 CTO，曾领导 Redhat 内部工具开发团队，从 2013 年开始研究 Docker 技术，是中国最早一批的 Docker 开发者，在开源领域有相当的影响力。

第149讲 | 肖德时：创业团队技术领导者必备的十个领导力技能（下）

你好，我是容器技术专家，前数人云 CTO 肖德时，今天继续跟你分享创业技术团队的领导力打磨之路。

在我看来，领导力是一种需要训练的能力，而非当了领导者之后就能自动获得，其中包含很多需要磨练的技能。在上一篇文章中，我分享了同理心技能、设定合理目标的能力、及时反馈的能力、持续创新的能力、有担当的能力这五个领导力技能。今天，我将继续分享我总结的其余五个领导力技能。

领导力技能六，能信任员工的能力

信任是需要花时间来培养的。所以这个技能就是在时间紧张的情况下如何信任员工。这个真的很难，但是作为一个技能。聪明的你一定会想到，我可以用一些工具和方法来间接保证我信任的价值，比如运用身边的各种资源来制定一套方法论和工具链，帮助我们能时刻管理好员工的工作情况和信任关系。

这里的关键是，在给下属交代任务的时候，一定要把任务讲清楚，让下属能完全理解你的任务。这些任务的分发，并不是简单的开个动员会就完事的，你需要真正的分析识别任务的难点，相信自己的员工能在这些难点上发挥自己的才能完成它们，并在小任务目标达成后给予即时的表扬和反馈。同时，作为领导者，你要去定义员工行为什么是对的，什么是不对的，要能正直的去应对员工的一切行为。一旦发现决定错误了，也要能真的向大家诚恳道歉。

领导力技能七，让人觉得靠谱的能力

什么是靠谱，就是能把领导交代的任务完成的能力。这个真的很难。尤其是在创业公司，基本上都是不可能完成的任务。大家在硬着头皮做的时候，就需要这个技能了。那什么是靠谱的能力？就是从小事做起，把任务一点一点的给攻克。如果任务特别大，是不是可以运用 WBS 方法把任务分的更细一点。如果任务时间点控制的比较死，是不是能先不要去考虑下班时间，用笨办法加班先把活给干了。对于普通员工来说，我们也就只能想出这样的办法来解决问题了，费心费力苦不堪言。

所以，让别人觉得靠谱的能力，更上一层，就是需要动脑筋，把任务计划规划好，在时刻拥抱变化的同时，能运用一些科学的时间管理方法，把时间充分管理好。要学会拒绝大部分和业务无关的任务，抓住业务核心。要记住，你来创业公司不是来玩的，是来带动公司业务增长的。这个很枯燥，所以没有人和你谈苦劳，谈感情之说。完成任务，让业务赚钱才是王道。能让公司活下来的人，都是牛人。所以，我们不指望人人都是牛人，但是最少在细节上，把小任务都做好，按时按量的交付，日拱一卒的让任务前行，让大家都觉得把任务交给你放心才是正确的解法。

领导力技能八，分配任务的能力

分任务是最不好培养的技能之一，因为锻炼的机会非常少，所以需要珍惜这样的机会。不管是瀑布式工作流，还是敏捷开发，都逃不过分任务的工作。啥叫好任务呢，我觉得就是能让人快速上手的活。这个对于成员在 6 个人左右的团队最合适分解，我记得微软就有一个方法论，一个团队开任务分解会议，如果午餐不是 1 到 2 个披萨能解决的话，就要有意识的分组了。

分配的概念是你知道任务应该给谁，而不是让员工自己去接任务。大家都不傻，脏活累活谁愿意去干呢？你需要有这个能力去打破这种套路。在适当的时候，要指定人去干他不擅长的任务，目的无非是让员工能定期审视自己，了解自己的边界。一个岗位就是一个职责能力模型，如果在这个岗位上，任务都搞不定，那这个人的能力就有问题，必须劝退。

职场无儿戏，所以分配任务的机会很少，要懂得珍惜这种场景，并锻炼自己的分配能力。大部分人都是能分配好的，只是分配的次数太少，无法做到特别完美。你要在这个技能上刻意的训练才有机会发挥这个技能对你工作带来的好处。

领导力技能九，正能量的能力

一个人不可能天天手持宣传大旗，喊口号，那个不是正能量，是忽悠洗脑，虽然确实会有点效果，但是大部分时候都会因为大家无法理解而无法提升。什么是正能量的能力，我觉得包含以下这些方面。

关心员工，能和团队成员时不时调侃两句。
能记得同事的名字，鼓励同事的好行为。
能真正的帮助到你的同事。
正能量技能不是活雷锋，是一种内在的潜能，俗话为一身正气。
不随波逐流的发表一些对行业的看法，并与员工分享交流。
和同事建立深厚的协作友谊，而不是把同事当成朋友，他们不是朋友，是你的战友，不要搞错了角色。
能有出色的社交能力把你公司的文化体现出来。

这个能力非常零碎，我也经常分不清哪些是哪些不是。但是我想大概的衡量标准就是能有很强的社交能力吧，而不是在公司内部建立一个小团体，那个不是正能量能力修炼的最好的办法。要想办法走出去，不管对内部还是对外部都能和人打交道的能力，就是正能量的能力吧。

领导力技能十，推动进展的能力

创业公司的使命目标千奇百怪，但归根到底，无非是为了能业务增长。对你个人来说，看准一件事情并推动起来是很好的提高工作效率的方式。工作不是兴趣，兴趣不是工作。工作是一份事业，是一份职责。能推动事情进展的机会对于创业公司的员工来说，非常多。但是如果稍加不注意，就会丢掉很好的磨练完整事情推进的机会。技能总是要打磨的，如果不去推，你是永远不清楚事情的复杂度的。

创业公司不是大企业，无法提供特别完整的基础设施和福利，那就要给员工提供有挑战性、有生产力的工作氛围。作为领导者，要能直言对公司行为不同的看法，并能提出自己的方案。只有看法没有方案，那就根本无法起到推动的作用，对于创业公司而言就是在做无用功。而有方案，就可以去执行，错了成本也低。创业的本质就是试错，小错误没大事，积累多了就不得了。所以，推动进展的能力是领导力中比较核心的能力，必须要磨练。

结语

以上我列出来的十大技能，仅仅是我个人成长经历的一些总结。我想强调的事情是，领导力显然是一项非常重要的能力，并且是一项需要不断磨练的能力，而不是创业当了领导就可以具备的。

我相信，很大一部分企业的领导者并不具备完善的领导力，就是因为平时业务压的太重，心思都在业务上，很难有心思来锤炼这些软实力。但是看完以上的能力清单后可以清楚的了解到，很多软性的东西是不得不去做的。如果不做，就只能用一些笨办法来强制员工或者自己去实现目标，这本身就是很笨的行为。

庆幸的是，领导力的提高本来就是不断磨练成长的过程，今日的不足不代表你的领导力就一定不能提高。我们稍微加强一下以上十大技能的磨练并整理分享给团队，说不定就可以让整个团队的精神面貌会有很大的改变，也能实践出一个有个性、有棱角、具备实战领导力技能的你。祝你好运。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

肖德时，TGO 鲲鹏会会员，容器技术专家，前数人云创始人兼 CTO，曾领导 Redhat 内部工具开发团队，从 2013 年开始研究 Docker 技术，是中国最早一批的 Docker 开发者，在开源领域有相当的影响力。

第14讲 | 从零开始搭建轻量级研发团队

2015 年，我加入特赞，带领了一支 5 人的研发团队。那时公司还在天使轮，团队最大的目标是能让产品上线，并证明我们的商业模式是可行的。三个月后，我们实现了这个目标，看到公司第一笔订单产生。随后我们拿到了 A 轮融资，开启了公司新的征程。在接下来的两年中，我们不断开发新的产品功能，不断优化现有产品特性，但似乎总是很难感受到研发和业务之间发生的直接影响。

不久前我们拿到了 B 轮融资，今年是公司的重要转折点，也是公司业务和规模同步增长的重要时期。我认为有必要将团队中一些有价值而有意义的工作做一些总结，希望能给业界朋友们一些帮助，或者给大家带来一种新的思考。

我将从组织架构、研发流程、绩效考核、团队文化这几个方面，与大家探讨如何打造一支高效的研发团队。首先从搭建团队组织架构开始，我们现在就一起出发吧。

矩阵式组织架构

如果研发团队规模大于 10 人，并且希望团队以最高效的方式实现项目交付，不妨采用以下“矩阵式”组织架构（如图 1 所示）。该架构能让团队更加专注，而且整个架构的扩展性也非常强。

图 1：矩阵式研发团队组织架构图

我们将横向的“职能团队”比喻为“虚线团队”，将纵向的“项目团队”比喻为“实线团队”。以实线项目团队为主，以虚线职能团队为辅。横纵交错，形成一个优雅的矩阵，横向可扩展，纵向可延伸。

横向的职能团队

根据团队成员专业技能的不同，可划分为多个职能团队，也称为“小分队”，例如：前端小分队、后端小分队、测试小分队、运维小分队等。当然，可根据我们所面临的实际环境，灵活划分出合理的职能团队。

需要注意的是，每个职能团队必须有一名负责人，也就是说，不要让同一人担任多个小分队的队长。因为划分职能团队的目的就是为了将专业技能聚焦，队长的职责之一就是帮助队员们在专业技能上得到成长，为职能团队赋能。

除了前端、后端、测试、运维这类职能团队以外，也可以搭建更有意思的职能团队，比如：技术委员会。

我们需要让团队们都知道的是，能够加入技术委员会的人，都是团队中技术水平最高的人，需要让他们有一种至高无上的荣誉感。技术委员会的成员可能来自于前端、后端、测试、运维，但技术委员会的人数一定是非常精简的。

技术委员会中有一名“技术主席”，也可称为“技术委员长”，他是整个技术委员会的权威，拥有最高的技术决策权，其他成员统称为“技术委员”，他们都是“技术专家”，而技术主席是“首席技术专家”。

随着团队规模的扩展，如果团队中其他队员希望申请加入技术委员会，此时必须得到委员们的一致认可，主席拥有最终决策权。加入的过程可能需要笔试或面试，或者也可以增加一些投票环节，我们可以把这个过程设计得更好玩一些。

除了技术委员会以外，还有产品委员会和设计委员会。产品委员会中的成员往往都是产品经理，当然也可以欢迎具备产品思维能力的工程师们加入，决定权还是交给产品委员会主席来定夺。设计委员会中的成员一般都是设计师，同样也包括对设计感兴趣的伙伴们。

需要强调的是，委员会中的成员，务必确保少而精，而且加入的成员都要有自己的责任。

可见，职能团队包括“小分队”与“委员会”两种形式，不管哪种形式都有一名负责人，即队长或主席，他们是自己所在职能团队的核心，他们的首要职责是帮助成员们在专业性方面得到提升，从而提高整个职能团队的战斗力。

职能团队负责人并非空降或任命，而是由职能团队成员们共同选举。每隔半年，团队全员可通过投票的形式，以匿名选举出自己心中认为最称职的职能团队负责人。也就是说，职能团队负责人是有任职期的，且任职期为半年，他们需要在这半年时间内努力改善自己所负责的职能团队，并努力让团队能得到成长，自己才能得到进步。

现在，我们可绘制一幅职能团队组织架构图（如图 2 所示），我们也可以根据实际情况进行合理设计。

图 2：职能团队组织架构图

横向关注人员成长，纵向关注项目落地，下面我们就一起来搭建纵向的项目团队。

纵向的项目团队

在纵向层面，我们还需要搭建一些项目团队，并确保这些项目团队是可以并行工作的，也就是说，他们的工作一般是彼此隔离，不会相互干扰。

在业务发展过程中，难免存在一些实验性工作，业务团队希望研发团队能够快速给出产品方案，并以最快的速度上线且投入市场，通过试错来验证业务的意义。研发团队也希望快速响应业务的变化，以提高产品和技术的价值。因此，我们需要搭建一个称为“功能团队”的组织，该组织的成员将面向业务中实验性的新功能进行快速开发，并确保这些功能可以尽快上线，但质量上却不能打折扣。

另一方面，已经上线的产品功能还需要在业务上不断磨合，通过不断收集用户反馈来持续迭代，才能打磨出一款优秀的产品。我们需要在已有产品功能上进行调优，以不断适应业务的需求。因此，我们需要搭建一个称为“效率团队”的组织，让他们来跟踪已经上线的产品功能，并通过数据和反馈来驱动产品不断优化。

公司主营业务固然重要，对于创新性业务而言，将会为公司带来更多的商业机会。因此，我们可以需要搭建一个称为“创新团队”的组织，它是我们的“独立团”，我们需要为这个团寻找一名称职的团长。

此时，你将得到一幅项目团队组织架构图（如图 3 所示），每个项目团队都有其负责人，每个项目团队可根据实际情况，划分多个项目小组，确保大家都能并行工作。

图 3：项目团队组织架构图

需要注意的是，由于项目周期是变化且短暂的，因此每个项目的负责人也是动态的，可能由项目团队负责人来担当，也可能是由项目团队负责人授权一名项目成员来担当，但项目团队负责人需要为项目最后的结果负责。

如果说功能团队的职责是实现产品功能的从 0 到 1，那么效率团队的工作就是完成产品从 1 到 100（如图 4 所示）。

图 4：功能团队与效率团队的关系

我们可将实验性的功能交给功能团队来研发，将优化性的工作交给效率团队来跟踪。

队员的选拔也十分重要。功能团队的队员对技术实现能力要求较高，尤其在做新功能的时候，需要考虑对整个系统架构的影响，不仅需要有较高的效率，同时还需确保较高的质量。效率团队的队员对业务理解能力要求较高，当他们对现有功能进行优化时，需要通过业务反馈和数据表现做出正确的判断，指导自己的下一步工作。

当功能团队所负责的项目上线后，他们会将该项目交接给效率团队，随后效率团队将对功能团队的交接情况给出评价，评价结果将影响功能团队的绩效考核成绩。关于绩效考核问题，我将在“绩效考核篇”中进一步与大家探讨。

我们认为员工不应该存在“双线汇报”关系，这样只会让组织架构变得更复杂。因为项目团队才有汇报，职能团队没有汇报，只有培养。项目团队为公司目标负责，职能团队为团队成长负责。换言之，项目团队帮助公司成长，员工可拿到项目奖金；职能团队帮助员工成长，为员工实现升职加薪。

写在最后

对于一支研发团队而言，需要拥有合理的组织架构、高效的研发流程、科学的绩效考核、良好的团队文化。如果缺乏这些方面的建设，研发管理工作将变得痛苦且低效。我们应该做的是，从管理中追求效率，从效率中提升价值。

杰克·韦尔奇曾经说过：Before you are a leader, success is all about yourself. When you become a leader, success is all about growing others.（在你成为领导者之前，成功的全部就是自我成长；当你成为领导者之时，成功的全部就是帮助他人成长。）

现在我想说：当你在赛场上踢球时，你应该考虑做一名优秀的球员；当你成为一名优秀的球员时，你应该考虑做一名优秀的教练。从技术到管理，正是球员转变为教练的过程，我们不能停止前进的脚步。团队的成功，才是我们的成功，我们的职责是给团队赋能。

与君共勉。

作者简介

黄勇，现任特赞科技（tezign.com）CTO，图书《架构探险》作者，Smart 开源项目作者，TGO 鲲鹏会上海分会董事会成员，QCon 讲师。十年以上互联网软件架构与技术管理经验，擅长敏捷开发，推崇“轻量级”系统架构。喜欢阅读，热爱交流，乐于分享。

第150讲 | 暨家愉：技术人如何快乐的自我成长（上）

你好，我是暨家愉，目前在阿里云担任解决方案架构师。自研究生毕业以来，涉足过云计算，大数据，物联网等不同方面的工作，还有过一些创业经历。今天，希望通过这个机会，结合自己之前的经历，跟大家聊聊技术人的成长。

技术人的成长类型可以分两类，即本能型成长和应激型成长，一般来说，本能型成长的效率是较高的，但现实是，我们在多数情况下都面临着应激型成长，那我们该如何不那么痛苦地提升自己，一路升级打怪呢？希望我的经历能给你新的启发。

本能型成长

所谓本能型成长，我们可以理解为源于自己的意识、兴趣和愿望，或是你想要改变现状，渴望得到进步。我们接下来举两个具体的事例。

我的第一份工作是在一个传统的零售企业内部做技术人员，当时我主要负责系统的开发和测试工作。我这人好奇心比较重，喜欢在测试环境对每个功能都了解一下，搞清楚业务到底是怎样进行的。有次我发现某个功能运行起来特别慢，通过查代码发现，这个功能在一个页面中行进了若干次 SQL 查询，其中一条 SQL 相当复杂，耗时足足有 2 秒。我开始分析这个 SQL，为什么要写这么复杂的一个查询，最后这个查询展示出来的是什么结果，对应页面上是哪个位置。在我一一搞清楚之后，发现其实可以有更优的做法，并且将这个查询稳定地控制在 20 毫秒以内，实现了指数级的性能提升。面对如此高的提升，我又继续探索，搞清楚了数据库里面关于 I/O，索引等会影响性能的因素，从理论层面搞清楚问题的根源，这样的经验可以直接复制到以后的工作中去。

另外一个经验是在美国工作的时候，因为工作关系，我开始有很多机会可以接触云计算，对于上面的各种服务充满好奇。由于当时所在的公司是创业公司，文化比较开放，所以在空闲的时候，我向公司申请做一些实验性的项目。其中一个实验是利用云计算的服务去完成服务器的动态伸缩，但是，期间遇到了很多技术方面的挑战，于是我自学了一些开源的 DevOps 工具，还有包括之前不熟悉的编程语言。最终这个实验项目变成了一条生产线上使用的功能，很好地帮助后台服务器应对了流量变化。

你发现了吗？这两个例子，其实有一个共通点，就是我当时的职位或职责跟这些任务没有一点相关性。第一个例子中，关于 SQL 性能调优，正常来说是属于 DBA 的事情。第二个例子中，要做动态伸缩，那肯定是运维同学的事情。而当时的我，只是遵循了我内心对这个事情的热情（Passion），然后一步步把事情做好，我的出发点并不是为了要达成 KPI 或得到技术成长，尽管结果确实是达到了。因此，对于这类型的成长，我归类为本能型成长。

本能型成长是最有效率的，过程也是最快乐的，这里主要有几方面的原因：
1. 你满足了自身的渴望。因为你想做，而且没有障碍，你做到了，所以你快乐。
2. 因为你真的想要做好这件事，所以你会废寝忘食地投入，用尽一切办法，自然成功的可能性也会更高，过程也会更快。
3. 本能型成长可能带来意料之外的好处。譬如在我的第二个例子中，因为我的杰出表现，老板后来给予了我加薪奖励。

应激型成长

我对应激型成长的理解是，我们身处在某个环境中，由于外部因素的变化，导致自身不得不进行成长，以适应这些变化。关于这样的情况，我也举例描述一下。

在我创业早期，我的想法很简单，以为作为一个技术合伙人，自己的技术足够支持产品的实现就可以了，只要自己认真地做好本职工作，创业就可以成功。由于对自己的能力看好，所以并没有觉得创业是一件风险高的事情。事实证明，当时我的认知是完全不到位的，我并没有意识到虽然都是在创业公司，但不同的角色、不同的位置，所需要的技能也是不一样的。

如果我单纯是一个技术专家，在创业公司里面，确实只需要关心如何通过自己的经验把产品和业务实现就足够了。但是作为一个技术合伙人，除了要做好产品实现之外，还对很多其他技能有要求。马云老师说过“一个人走得快，一群人走得远”。技术合伙人很重要的一项能力就是搭建一个走得远的团队。这其中就包含了对识人和用人两方面的要求。团队搭好之后，如何调剂好团队内部的气氛，保证成员的成长又是另外一个重要的问题。这些还都只是对内的技能要求。对外比如公司层面的跨部门协作，或是面向业界和市场进行输出又是另外一些必不可少的要求。这些一切一切，都逼迫我对自己进行升级，通过不同的方式去学习和提升自己所缺失的技能。

于是，我进入了应激型成长的状态，然而这个过程并没有本能型成长来得容易。因为第一，这些要求来得有点突然，甚至让人有点措手不及。但在当时，我并没有可选择的余地，甚至这是一道或成长或灭亡的选择题；第二，应激型成长往往伴随着打破自己的舒适区，如果我要成长，我需要打破自己作为技术专家的舒适区，走出去，做很多之前自己没有做过的事情。这些事情并不是我有经验的，甚至未必是我喜欢的。综上所述，由于不是自愿发生的，应激型成长往往是一个痛苦的过程。

那么，我们该如何快乐的成长呢？可能你会说将应激型成长转变为本能型成长，多增加自己的兴趣，但我们不可能每次都转变成功，不知道你是怎么做的呢？欢迎在留言区和大家分享。我将在下一篇文章中分享我的经验和方法，欢迎持续关注。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

暨家愉，阿里云解决方案架构师，TGO 鲲鹏会会员。研究生毕业于美国伊利洛伊理工大学，曾任 Teradata 资深大数据专家，作为大数据 Team Lead 参与 EMC 内部首个大数据平台的设计与开发。15 年作为技术合伙人从硅谷回国加入红茶移动并担任工程 VP，一年时间带领技术团队完成对国内主流安卓厂商的海外漫游支持。16 年底获得顺为和小米投资，联合创办小米生态链企业树米科技，专注于利用虚拟 SIM 技术和大数据技术，为企业搭建一站式物联网解决方案。

第151讲 | 暨家愉：技术人如何快乐的自我成长（下）

你好，我是暨家愉，目前在阿里云担任解决方案架构师。上篇文章我提到，技术人的成长可以分为本能型成长和应激型成长两大类，并分享了我对这两类成长类型的理解以及一些自我实践，今天我将着重分享我在应激型成长方面的一些经验和做法，希望能给你一些参考。

本能型 vs 应激型

本能型成长由于受本性驱动，往往能够给我们带来更好的体验，而应激型成长则较为痛苦。那么是不是说，我们应更多地依靠本能型成长，促进自己进步达到最大值呢？答案并不是这样。我认为应激型成长反而在个人职业生涯中扮演更重要的角色。你可以先来想想为什么，下面我们再来看几个例子。

我在读《人类简史》的时候了解到，当智人进入澳大利亚和美洲大陆之后，这两片大陆上许多原有的大型哺乳类动物在极短的时间内遭到了灭绝，这些大型动物甚至包括可怕的剑齿虎和重达 8 吨、高达 6 米的巨型地懒。有一种理论认为，这是由于这些原大陆上的霸主们，对于新来到的客人认识不足，对于他们的出没没有足够的危机意识，因此，它们在还没有演化出危机感之前，短短的数千年之间，就已经遭受了灭顶之灾。作为对比，在亚欧大陆上面的生物，由于随着智人的狩猎能力一起进化了数十万年，它们早已懂得了躲避危险。

从这个例子中，我们可以看到，外部世界的变化会要求我们必须作出相应的改变予以回应。我们可以给予回应的时间有时候并不由我们自己决定，假如没有在限定的时间里面完成应激和成长，那么面临的就是无情的失败，甚至是淘汰。

如果说生物进化论这种例子对我们而言太遥远，下面我再举一个技术圈的例子。我研究生毕业的时候，正好赶上大数据热潮，那时候我在一个大数据顾问公司工作，主要是给 EMC 做他们的数据湖项目。在项目第二期的时候，EMC 向项目加进来一位他们自己的架构师，这位大哥当时应该有 50 多了，对于 Hadoop 的生态完全没有概念。在进入项目的早期阶段，他每天拉着我学习 Hadoop 生态相关的知识，希望能够跟上这种新型的计算思想，更重要的是，跟上项目的进度。当时我可以感觉出来，这个过程让他相当痛苦。因为他对于分布式计算没有什么概念，也好久没有写代码了，但生活和工作的压力，让他不得不赶紧学会。不然，随着 Hadoop 着陆，他可能很快就会像那些美洲霸主一样，被快速淘汰。

上述这个例子跟我们很近，可能每天都发生在我们身边。甚至我们大部分人可能都想过，到某个特定的年龄之后，我们写不动代码了，技术更新换代又那么快，比不上年轻人精力旺盛的我们还有生存的空间吗？

我之前在做一次分享的时候，就有一位初入职场一两年的同学，已经在思考这个问题了，她的焦虑是，30 岁之后，还能继续在一线写代码吗？仔细想想，正常大学本科毕业大概是 22 到 23 岁左右，到 30 岁也就是短短的 7 到 8 年的时间。以 60 岁退休来算，这么短的时间还不到职业生涯的四分之一。由此可见，技术人的职业生涯是一条受外部环境影响多么严重的道路。既然我们每个人都知道外部影响的严峻，那么对抗这种影响的能力，也就是我说的应激型成长，它的重要性也就不言而喻。

拒绝意外

既然知道应激型成长的重要和无可避免，我们是不是有办法来减轻这种痛苦，从而让我们更好地面对呢？

仔细分析一下，应激型成长痛苦的地方主要有两个：一个是在我们的预期之外，而且通常特别快；另外一个是要求我们打破自己的舒适区，做我们不擅长的事情。只要能够有效地应对这两点，是不是就可以让痛苦减轻？

还是回到我当时创业的例子，显然，在我进入创业这个环境之前，我对于创业的认知是严重不足的。因为认知的缺失，导致我对情况的判断出现了差错，并且最终走向失败。这就跟生活在美洲大陆的巨型地懒一样，它们当时看到的智人，只是一种身型矮小的类猩猩生物，在它们眼中，这样的生物并不会对他们的生存带来任何威胁。而事实是，它们没有看懂智人背后的协作和使用的工具可能给它们带来的危险，当然，在那个信息流通程度几乎为零的时代，地懒犯这种错误是无可厚非的。今天则完全不一样，在这样一个信息过载的社会里，我们信息缺失的绝大部分原因肯定不会是因为信息的无法获取。换句话说，我们应该尽可能地保持对信息的敏感度，并且通过信息进行判断，通过提早的预判，做好准备，来免除“惊喜”带来的痛苦。

如今获取信息的渠道有很多，我简单地在这里分一下类，也谈一些心得。第一类是知识付费类的平台和 APP，这类型的渠道最大的优势是通过学习前人总结的经验，可以让你快速地学到新技术、新思维、新方法。它的好处在于每节课一般都只有 10 到 15 分钟，适合利用好各种碎片时间进行学习。

第二类是网络公开课，一般是正规大学里面的课程，通过网络的形式让你参与进去。这种大学一般都是 self-paced，可以根据自己的进度和空闲时间进行学习。它的好处是可以让你更系统地学习一门技能或者一个课题。如果你想对某个知识体系进行补强或学习一个全新的领域，这是最好的方法。

第三类是各种聚合型新闻类的 APP，优点是汇聚了不同来源的新闻资讯，还有一些行业分析，市场分析等。很多技术人可能默认只做好技术就足够了，其实你所处的行业发展情况，市场的发展趋势，都会对你所处的公司造成影响，并间接影响到每一个人，因此这部分的信息是不应该缺失的。

第四类是读书，特别是一些经典著作。有句话叫做“太阳底下无新事”，有些事情，可能换个时间、地点和人物，又会重新发生一遍。理解这些事情对于我们日后预判身边或者市场将要发生的形势变化，会有特别的帮助。对于这一块，我自己也在努力学习。

“打破”舒适区

有了预见性之后，我们再来谈如何打破舒适区。要谈这个话题，我们需要先认识舒适区。舒适区本身不是一个物理空间，它更多的是在描述一个我们在熟知范围内行动的一种心理状态。我们乐于在这种既定的模式下面运作，因为这样，我们知道所有事物都是可控的，能够带给我们安全感。长期在舒适区里面生活甚至会给我们一种假象，认为自己已经很厉害了，一切事情尽在掌握。不得不说，跟井底之蛙有点异曲同工的意思，这样的安稳往往也孕育着危机。当外界发生剧变的时候，长期处于舒适区的我们可能来不及反应，就像北美大陆的巨无霸那样，顷刻之间就被淘汰。

知道居安思危的重要性之后，我们该怎么打破舒适区呢？在这里，我故意使用“打破”这个词，而不是“走出”，怎么理解呢？

首先，我觉得人是不需要离开舒适区的，或者说从当今社会分工的现实状况来说，为了整体社会生产更有效率，人在大部分情况下都不应该离开舒适区。举个例子，一个 10 年工作经验的程序员同学，你让 TA 离开自己的舒适区，意思就是让 TA 换个工种，譬如去当一个厨子。这样的结果是 TA 完全没办法继续运用之前的经验，一切从 0 开始。这么做，无论对于 TA 还是整个社会来说，都是一种生产力的浪费。打破舒适区的做法就完全不一样。譬如我本身是一个服务器研发，我可以选择往上下游扩充我的能力，去做中间件开发或者前端开发，我也可以选择向产品或者测试转型，在有延续性的新岗位上利用我的研发经验延伸出不一样的思路。

再拿我自己为例，当年做大数据的时候，Hadoop 的生态发展得很快，我刚刚开始对 Hadoop 1.0 的整个架构有比较深入的掌握，马上 Hadoop 2.0 就开始被广泛讨论，及后 Spark 的出现也开始让大家重新思考 MapReduce 这个计算框架作为底层的效率问题。如果那时候我依然死守在我的舒适区中，可能在短短几年内就会被淘汰。因此，我凭借着在 1.0 打下的基础，快速跟进学习 2.0 的系统，通过对比分析，我理解了 2.0 设计的初衷，解决了 1.0 的哪些问题，也对以后生态发展的方向有了更清楚的认识。对于 Spark，我先在 Coursera 上面完成了 Functional Programming 的课程，对 Scala 的编程方式有了认识，然后对照着 MapReduce，我又研究了 Spark 的框架和设计思路，继而再去理解 Spark 的生态。通过一段时间的学习，我掌握了这两个新的大数据知识点。

从这个例子中可以看到的是，对于新的知识，我是通过跟旧有知识进行对比去学习的。在完成了新知识学习之后，其实是对本身已掌握知识体系的一个补充或完善，这种对于原舒适区的打破，最终会融合原来的舒适区，给我们一个更大的舒适区。而这些舒适区里面的知识，也会慢慢演化成我们军火库里面不同的武器，给我们以后再次打破舒适区提供支持。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

暨家愉，阿里云解决方案架构师，TGO 鲲鹏会会员。研究生毕业于美国伊利洛伊理工大学，曾任 Teradata 资深大数据专家，作为大数据 Team Lead 参与 EMC 内部首个大数据平台的设计与开发。15 年作为技术合伙人从硅谷回国加入红茶移动并担任工程 VP，一年时间带领技术团队完成对国内主流安卓厂商的海外漫游支持。16 年底获得顺为和小米投资，联合创办小米生态链企业树米科技，专注于利用虚拟 SIM 技术和大数据技术，为企业搭建一站式物联网解决方案。

第152讲 | 施翔：如何打造7*24高效交付通道（上）

你好，我是阿里巴巴高级技术专家施翔，今天想跟大家一起探讨如何体系化的看待研发效能，以及我所在的 CBU 技术部在打造 7*24 小时交付通道中的实践。

在开始之前，想先跟大家分享一下我们的数据，毕竟没有数据的分享是没有灵魂的。我们从拉分支到正式发布的平均周期是 5.29 天，目前整个部门的应用数有 1000 多个，开发人员有 350 多人，一年下来集成自动化大概是 29000 多次，发布大概是 15000 多次。平均下来，可以看到，每个人每年的平均发布次数是 42 次，再细化一下，就是每人每周至少有一次发布，这个数据还是非常惊人的。

而这可以归结于研发效率，那我们怎样从交付通道的角度，思考研发效能的提升呢。所谓交付通道，就是从产品需求提出到最后触达用户的通道，其中，我们需要从四个维度出发考虑，即系统、开发、测试、运维。
1. 系统：怎样确保它可以无限扩展，编写代码过程中不受限于环境。
2. 开发：怎样能够不断地提交和验证需求。
3. 测试：怎样快速的验证，快速的反馈。
4. 运维：如何确保灵活的发布手段，更快更好地感知线上问题。

这个通道中的每个环节，都应该自驱动、自运行，而且各环节之间的工件传递也应该能够实时完成。

之所以从这四个维度来考虑研发效能，主要有三点原因：第一，主要是基于业务的长期述求，希望技术能够快速地、高质量地响应业务需求，做好业务交付；第二，在整个研发生命周期中，影响业务交付的因素有很多，因此需要我们从交付通道的各个维度出发来考虑问题。第三，敏捷能力需要有持续性。

而在整个交付通道中，架构、配置、测试、发布等是提升效能的几个关键点，接下来，我会从这几个点出发，分享我们是如何打造 7*24 小时交付通道的。

架构——提升代码的生产力

影响代码生产的因素主要有以下几个方面，第一，代码结构是否合理；第二，代码提交模块是否足够小；第三，开发环境构建是否便捷；第四，代码语言的适用性等等。

而好的架构能有效提升代码的生产力，但也需要结合团队的规模、业务特点等来决定更适用的架构，比如在创业阶段，技术团队只有几个人的情况下，完全可以在主干上进行开发，在主干上进行发布，不会有任何的影响。因为系统之间不存在依赖，一切在非常可控的范围之内。在这个阶段，甚至可以不用考虑架构的问题，不用考虑研发效能的问题，没那个必要，不用为了架构而架构，为了研发效能而研发效能。

当业务复杂、团队已经达到几十上百人规模之后，我们就需要对系统进行分层，比如 MVC 模式，就是把系统按照 Model（模型）、View（视图）、Controller（控制器）来分层，让前端、后端、测试等更加专业的同学去做更加专业的事情。否则，如果所有的人都在一个平台进行开发，那么彼此之间一定会相互等待，而且在解决一些代码冲突时，花费的时间可能比代码开发的时间还要长。

随着业务的不断发展，当系统分层也难以支撑业务发展需求的时候，我们不可能再在单台机器上获取一些性能的提升，而是需要从技术的角度，通过裂变或通过调整架构来提升代码生产力。比如阿里巴巴在 2007 年以后，整个系统 SOA 化，调整为按照服务的方式进行划分，满足了业务去高速增长的需求，同时这种分布式的架构，也很好地解决了效率问题。

之前也提到，当所有技术同学都围绕着一个系统进行开发的时候，一定会出现冲突，而当组件拆分之后，所有的技术同学都面向自己负责的服务进行开发，释放个人生产力，效率就能得到大大的提升。

如今，阿里整个系统的规模一直在不断膨胀，今天，可能我们一个开发同学需要维护对应的两到三个系统。这其实就是从整个系统架构的层面去考虑，怎么提升开发同学的生产力，让他们的活力能够释放出来，这也是研发效能提升的第一步。

配管——全天候的配置能力

以前我们有个岗位叫 SCM，负责版本控制、环境管理、配置管理等，来保证所有配置项的完整性和可跟踪性。但当分布式架构、面向服务的架构蓬勃发展起来之后，系统的数量也在不断扩张。以前的 SCM 是靠人肉来部署，但当系统数大量扩张之后，SCM 就不可能再靠以前这种人肉的方式了。

在配管中，非常关键的一个点是对代码分支的管理。代码分支管理可以说是研发模式变革的一个起点，它的策略不存在好坏之说，需要结合业务的特点、技术团队的规模等因素来决定。

对阿里来说，代码分支管理解决的核心问题是并行开发。在实践中，具体的代码分支管理策略有两种，一种是分支开发、主干发布，一种是分支开发、分支发布。

对于第一种分支开发、主干发布来说，它可以维持一个非常稳定的主干环境，同时又可以随时拉一个新的分支出来进行独立的开发。但这种模式也存在一个问题，就是所有的分支都必须要在一个集合点或者说集成区，才能进行集成。而且，当开发人员在集成的过程中发现代码有 bug，需要回滚的时候，成本是非常高的，因为可能需要所有的分支全部重构才可以。

对于第二种分支开发、分支发布来说，理论上，这种模式拥有非常高的灵活度，可以确保每个项目不会影响任何一个项目，不同的项目组之间也不会相互影响。但它也会带来非常大的挑战，主要在于这种模式需要有非常多的 merge 的过程，而这些 merge 所带来的是测试工作量的急剧增长，需要非常频繁的测试才能解决不断 merge 所带来的问题，确保集成质量。

以阿里为例，大概在 2009 年的时候，我们希望能够把代码开发、代码提及、配置管理等环节通过工具的方式进行集成，取代原先靠人来协同的模式。在这样的背景下，我们打造了一个研发统一协作平台 Aone，对外也叫云效，从平台化的角度来解决研发效率以及研发过程中的协同等问题。在我们做了这件事之后，大家会发现，原来的 SCM 团队消失了，他们之前能做的配置、协同等问题，我们都能通过这个平台化的角度来解决。

而代码分支管理对应的非常重要的一点就是开发和测试环境的协同，那 Aone 的核心就要确保以下几点：第一，环境必须能自动化部署，否则就又回到了之前人肉的时代；第二，环境之间必须要有隔离，当存在多套测试环境的时候，隔离、协同等问题就是平台一定要解决的；第三，要确保测试环境的稳定性，无论是开发同学还是测试同学都需要在测试环境上做一些支撑，怎么确保测试环境的稳定性就成了重中之重。

小结

今天跟大家分享了我们在打造 7*24 小时交付通道中的实践，正如前文提到的，整个交付通道中，架构、配置、测试、发布等是提升效能的几个关键点，尤其是架构与配置，尤为重要。

在升级了系统架构，提升了配管能力之后，开发同学的活力能得到极大的激发，他们可以无拘无束的面对自己的系统、自己的服务来进行开发，活力被大大释放了。同时，我们通过平台化来支持配置管理、测试环境管理等，解放人力，也能够实现 7*24 小时战略支持。

受限于篇幅，剩下的测试、发布等关键环节的提升，我将在下一篇文章中与你分享，欢迎持续关注。感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

施翔，TGO 鲲鹏会会员，现就职于阿里巴巴 CBU 技术部，担任高级专家职务，质量技术、稳定性和 DevOps 团队负责人。曾就职于中兴、支付宝等公司，在系统高可用、测试工具研发、研发效率提升等方面有着丰富的经验。

第153讲 | 施翔：如何打造7*24高效交付通道（下）

你好，我是阿里巴巴高级技术专家施翔，研发效能的提升是技术团队都需要关注的话题，而打造一个 7*24 小时的交付通道就是一个非常有力的着眼点。

在整个交付通道中，架构、配置、测试、发布是提升效能的几个关键点，上一篇文章分享了我们在架构、配置这两个环节的做法，今天将继续分享我们在测试、发布等环节的实践。

测试—高频率低成本

在架构、配管以及打通的基础上，接下去就到了测试环节。其实，当一个技术团队比较小的时候，测试环节并不是那么必要，当业务发展到一定规模、用户对于质量的容忍度越来越低的时候，才需要去引入专业的测试环节。

另外，在过去，传统软件是离线交付的模式，软件的交付程度非常高，所以对于测试来说，它是不惜余力的，哪怕要花费更多的时间、更多的精力，也要把测试做好。但现在在互联网模式下，更多的软件是在线交付的模式，测试团队的角色也发生了一些变化。以前，他可能是一个守门员，守在研发环节的最后一道关口，把控软件的质量，而现在，他需要考虑怎样才能尽快对软件质量进行反馈，这是非常关键的一点。这一点也决定了测试成为了整个研发交付环节中非常重要的一个环节。

测试包括单元测试、功能测试、系统测试、集成测试、回归测试等不同的方法，今天我想重点分享的是集成测试。对测试来说，发布越频繁，对集成测试的要求就越高，越需要可靠低成本的集成测试方案。

上一篇文章中，我们提到，代码分支管理有两种不同的策略，一种是分支开发、主干发布，一种是分支开发、分支发布，它们其实就对应着不同的集成策略。

第一种策略，通过项目过程中不断的 merge，不断减少分支和主干的冲突，来提高项目间的集成效率。在这个过程中，也可以用项目过程中的功能测试来覆盖小集成的需求。

第二种策略，用空间换时间，多个项目一次性集成，提高单次集成效率。在这种策略下，必然会有多个项目在集成区域等待，甚至可能有的项目提前一天就等在集成区了。除了能提高单次集成的效率外，这种模式还适用于比较复杂的系统，例如阿里的一些业务系统，需要从端到端的验证的时候，就需要这种集成方式，来确保它们从端到端的同步。

第三种策略，无人值守集成测试，回归本质，通过测试技术手段来解决多项目集成过程中的频繁验证的问题，这也是更能保证测试灵活性的方式。

同时，作为技术人，我们会希望通过无人值守自动化，来解决合并过程、集成过程中的一些质量效率问题，也只有这个问题解决了，我们才能一步一步往下打通到测试环节，不再让人的效率问题影响到整个交付通道的效率。

发布——更灵活，可感知

在互联网行业，相信不少技术团队都遇到过这样的情况，就是无论你开发上线速度有多快，业务同学总希望你们更快，甚至可能会出现一些变态的业务需求，比如要求一天开发，一天上线，那怎么办呢？其实我们是可以在发布上下功夫的。

举个例子，阿里现在有很多发布模式，比如正式发布、Beta 发布、预发布、分批发布、灰度发布、隔离发布等等。我们也希望，如果有一天，业务真的紧急到了这样的程度，需要第一时间上线的时候，我们可以通过这些灵活的发布方式来解决它的效率问题。

阿里 CBU 技术部的一些实践

说了那么多理论，接下来我将分享我们 CBU 技术部在打造这个 7*24 小时交付通道中的一些实践。

先来看分支管理和发布策略，如下图所示，这是我们整个的发布通道，采用的是分支开发，分支发布的策略。对于整个发布通道，我们定义了四个流程状态。

其中，第一个是正常的从预发到正式发布的流程，中间有开发、构建、预发、正式发布、提交、写基线到结束的整个从预发到发布的过程。而第四个就是相对快速一些的发布通道，从开发、构建到正式发布，相较于第一个流程，它省去了中间一些预发的环节。

再来看无人值守自动化能力的建设。我们讲协同的时候，通常指两方面，一个是人与人之间的交流、协同，另一个是系统与系统之间的协同，而我们做的就是第二种，强调系统之间的协同。

过去常说，我们是面向过程来开发、面向对象来开发、面向服务来开发，未来，我们应该是面向平台来开发。以无人值守自动化系统为例，如图中所示，上面是整个 Aone 研发平台，开发者可以在这个平台上提交代码，进行预发代码集成、代码静态扫描，乃至预发等等操作。

而当系统到了预发的状态后，就可以通过一些操作促发下面一层的自动化体系，并通过这个分层的自动化系统及时进行反馈。我们对自动化的要求是，任何一次集成、任何一次发布，都需要在 30 分钟内跑完所有的用例，并给到 Aone 平台分块，通过彼此系统间的交互解决效率问题。

我这里有一些自动执行的数据，截至目前为止，我们整个部门中 50% 左右的发布是完全由自动化实现的，基本不需要人力参与。另外，去年一年，通过这个自动化系统，我们线上拦截了 30 多个问题数据，预发拦截了 60 多个问题数据，日常拦截了 100 多个问题数据。同时，构建次数达 29000 多次，活跃功能测试件数量达 1100 多个，运行的 case 数达 80000 多个。

之前提到，整个交付通道打通以后，我们从拉分支到正式发布的平均周期缩短到了 5.29 天，目前整个部门的应用数有 1000 多个，开发人员有 350 多人，一年下来集成自动化大概是 29000 多次，发布大概是 15000 多次。

这些是非常优秀的数据，但可能对于老板来说，光有结果不行，还需要有过程，为此，我们专门打造了一个部门提效中心。我们做任何工具、任何平台，都要考虑它们到底能不能产生价值，那怎么衡量和定义这些工具平台的价值呢？

我们想了一个最简单的方法，比如自动化以前，通过人肉去集成的话，可能需要一个小时，现在自动化之后，通过工具或平台去执行集成的话，可能只需要 10 分钟，那么对于这个工具或平台而言，就是执行一次，提效 50 分钟。我们通过这样的方式去衡量整个提效过程的成果。

可以看到，过去一年，我们大概提升了 2177 个人日，基本占了部门总人日的 5%。

结语

回顾一下，我们通过架构的升级，极大的激发了开发同学 Coding 的活力与能力；通过平台化、系统化解决了配置、测试环境等问题；通过无人值守的自动化集成测试解决了集成质量与效率的问题；通过灵活可感知的方式解决了随时随地发布代码的问题。

这样一条路走下来，大家会发现，其实整个交付通道已经打通了，也就意味着，除去开发时间，任何一款代码都可以在 7*24 小时内的任何一个时间点快速上线，解决了之前可能出现的排队发布时间长、集成测试效率低等等一系列问题，这就是我们这么看重交付通道打通的原因。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

施翔，TGO 鲲鹏会会员，现就职于阿里巴巴 CBU 技术部，担任高级专家职务，质量技术、稳定性和 DevOps 团队负责人。曾就职于中兴、支付宝等公司，在系统高可用、测试工具研发、研发效率提升等方面有着丰富的经验。

第154讲 | 谢东升：说说技术管理者从外企到民企的挑战

你好，我是石投金融 CTO 谢东升，在公司负责系统的架构和研发团队的日常管理工作。今天结合自己的一些经历，和大家分享一下从外企到民企工作可能会遇到的挑战。

纵观国内 IT 或者互联网企业的发展史，90 年代的时候，国内的 IT 企业无论是数量还是质量和外企都没法比，所以那时候 IT 类专业的学生毕业都将能进入一流欧美外企作为一个目标来努力。这就造成了最老的大型外企聚集了国内一堆优秀的技术人才，成了中国 IT 的黄埔军校。2005 年以后，以 BAT 为代表的互联网民企开始崛起，民企的竞争力大增， 特别是这些年，在资本力量的推动下，国内各行各业的互联网创业公司如雨后春笋般冒了出来，对外不断地抛出橄榄枝。同时，黄埔军校的学生们这些年通过自身的不懈努力，也已经挂上了 Manager/Director 的抬头，成为外企的中高端技术管理者了，准备”学成毕业”了。对于毕业出发前的技术管理者们，需要了解到以下这些挑战：

第一、调节好心态，放下表面的光鲜

作为一名管理者，你从顶级外企跳槽到创业型民企后，生活可能会有如下变化：
1. 住宿从五星酒店变为锦江之星。
2. 出差从头等舱变为廉价航空、火车、大巴车。
3. 出门随意打专车变为等公交、挤地铁。
4. 从土豪流量无限 + 电话无限打变为每月话费 200 元封顶。
5. 餐饮费用从随意报销变为沙县小吃、黄焖鸡等等。

对于这些生活变化，请以平常心看待。同样的，从事的工作也会有下面两点变化：
1. 在外企时，你可能会觉得天花板过低，对未来的发展也是一眼看到底，而来到民企后，你会感觉明天总是充满刺激和挑战。
2. 工作状态从混吃等死变为总感觉有新机会向你招手。
因此，明确了外企与民企的利弊与区别后，如果你还想跳槽，那请你想清楚为什么要来民企以及自己要追求什么样的生活。

第二、需要学会找活干

外企是按照清晰的组织定位需求找管理者，有明确的岗位描述、职责范围及说明、汇报线路和相对完整的 KPI，有一套规范化和标准化的管理要求和逻辑。民企对技术管理者也有定位，但相对笼统和宽泛，边界不是很清晰，甚至是为了实现企业发展的某些“使命”而不是单纯的职责定位来找管理者。这样对一名技术管理者，工作难度会更大，因为老板和其他管理层可能都不懂技术，这样就容易导致技术高管入职后多少有些无所适从，磨合期的难度也增加了。另外，一个有趣的现象是，民企找 CTO 或者技术总监经常是没有 JD 的，能提供 JD 的，很多要求都直接说参见 BAT。不过换个视角，正因为民企没有框定太多细节，想象空间和发展空间才更有诱惑力。

说到这里，我分享一点自己的实践经验，对于“找活干”可以分为技术团队内部和技术团队外部。在技术团队内部“找活干”的方法比较容易，就不展开说了，这里重点说说我是如何在技术团队外主动干活的。

首先，主动找各个中前台部门的负责人聊天，最好是请对方吃饭（新来的人总归要拿出更诚恳的态度，千万不要认为自己是 CTO/ 技术总监, 就高高在上），这样做可以更快速地了解彼此，为日后的革命友情打下基础。在互相信任的基础上，就可以了解到对方所在业务模块或者流程中的痛点，帮助他解决问题。这里值得注意的是，痛点可能有多个，要确定优先级，同时一般业务负责人都很忙的，为了最终推动问题的解决，一定要让业务负责人给一个对应的对接人。

接下来，就是跟着业务对接人将对应的痛点及其流程完整的过一遍，了解各个问题的具体环节，更重要的是了解实际操作的一线员工的感受，这样才是真的接地气。

当和所有部门都聊过之后，手上就有一个优先级任务列表。在公司管理层会议上，就可以和包含老板在内的管理层最终确认一遍需求。之后，就可以跟着产品与技术的兄弟们将需求一件一件的实现落地，同时每周在管理层会议上和大家同步进度。

第三、学会在流程完善前就完成任务

外企的人在细密的流程和制度中生活久了，对流程、制度等就会产生莫名的习惯和依赖，认为做好项目，需要 Project Manager, 需要按照日程表来发技术会议邀请，对民企而言，很多人以为是缺失流程，其实缺失的是执行流程的必要能力和资源。所以，我要说一个道理：作为一名技术管理者，我们要面对现实，先不要谈建立完美的流程，先找到可以利用的资源，把事情做起来，让管理层和团队看到成绩和效果。

当时，我刚加入新公司的时候，开发流程还不完善，也没有对外的标准接口对接规范，但这个时候我们需要和一家汽车金融公司进行系统对接，时间非常紧，要求 1 个月内必须要开发联调完上线跑业务，因此，不可能有时间先来梳理规范再进行对接。
当时，我的做法就是先把握好几个关键点：

确定接口，我需要提供什么。和对方约定好对方需要提供的内容，我们才可以有效的处理并返回给对方需要的结果。

异常情况如何处理，接口稳定性怎么保证？

钱怎么算？单次收费还是按用户收费？套餐包还是无限量？

抓住几个核心对接人，大家约定好在一起面对面办公开发，减少沟通成本。

后续这个项目也顺利上线，得到业务部门认可的同时，我们技术团队也通过本次对接，及时做了总结，生成了我们的接口开放规范。

第四、需要学会融入公司的业务中

很多外企在国内开设的分支机构都是研发中心，具体的业务是在海外。这就意味着，技术管理者只要保证项目能按时按质交付，就完成个人的大部分工作了。但在国内的民企却不一样，业务就在身边，变化需要即时响应，因此做为技术管理者要保持与销售、市场和运营的交流互动，了解对方的迫切诉求，帮助业务团队提升战斗力。

比如深入去了解每个部门的业务报表，了解每张业务报表的字段。通过字段关联技术部的工作，这样就可以清楚的知道技术部可以为业务部门做点什么，在制定年度或者月度目标的时候，就可以和业务的目标做到高度一致。如果一个月下来，某张报表的指标发生了波动，就可以去回顾一下是否工作没有做到位，我们不要等业务来找技术提要求，而是主动找对应的业务负责人商量后续的行动方案。

第五、养成创业者的思维方式

在外企的时候，作为一名技术管理者，你的直接汇报对象或老板往往也是职业经理人，只要相互之间和睦相处、各负其责便相安无事。但在民企，你的上司变成了老板或者核心创始人，如果还是保持不要犯错，稳字当头的思维，那么接下来的工作很可能“如履薄冰”。你最需要做的，就是放开手脚，和你的老板的思维保持一致。总之，民企老板和外企的职业经理人老板有很大区别，决定了我们的工作方式也需要作出相应的改变。

我们不仅需要重视这些区别，能驾驭这些区别更有实用价值。希望各位到民企大展宏图的技术管理者们，成功被 Offer 只是第一步，后续更要成功活下来，做足准备是大前提，因为这不是一次简单的跳槽。

作者简介

谢东升，石投金融 CTO ，TGO 鲲鹏会会员，历任 eBay 中国研发中心架构师和工程经理，设计了 eBay 第一个移动端自动化测试框架；曾任顺丰海淘技术总监，经历了技术团队从小到大的整个发展历程；积累了超过 10 年以上的互联网从业经验，对微服务、高并发、虚拟化有深刻的理解。

第155讲 | 王可光：如何搭建初创团队之人才关

你好，我是澳觅技术总监 、TGO 南京会员王可光，因为本人经历过几次团队从无到有的搭建过程，所以非常荣幸有机会和大家分享一下团队搭建这个话题。围绕这个话题，我主要从以下两方面展开分享：找人、留人，关于团队的其他话题前面已经有很多文章讨论过，这里就不赘述了。

找人

你应该注意到了，我这里使用的是“找人”，而不是“招人”，“招人”只是一个人事部门流水线的动作，而“找人”最重要的就是这个“找”字，“找”在百度汉语中的解释是“为了要见到或得到所需求的人或事物而努力”，也就是你必须付出努力才会得到想要的人。

找人之前我们先聊聊多数初创公司的创立过程：即首先有好的产品创意，然后快速实现，再推向市场，最后不停迭代。前期就是大家常挂在嘴边的“我有个好点子，就差一个程序员了”，有了程序员之后产品需要快速上线，因为移动互联网时代有“唯快不破”的法则，所以前期找人也需要快，那如何找人呢？

首先，我们需要想清楚找人的核心问题是什么？是要明确到底需要什么样的人！如果团队里面没有一个懂技术的，那你最需要的是一个技术合伙人（找到这个人后，这篇文章剩下的内容就可以交给他看了）；如果没有一个人有产品思维，那你就需要找一个专业产品经理……

比如我们当时只是有一个初步的想法：要做澳门本地的 O2O 平台。但是这个想法要落地，就需要有专业的产品经理去梳理需求，同时还需要有专业的 APP 开发人员，所以当时思路很明确：服务端我自己来，再找一个产品经理、一个视觉设计师、一个 IOS 开发人员（经过调研澳门市场 IOS 和 Android 的比例约为 7:3，所以为了快速试错，前期战略性放弃 Android 用户）。总之一句话：找人之前先想好需要找什么样的人。

其次，就是找人的方法；找核心员工最靠谱的方式是在熟人圈里面找到合适的人，靠谱的朋友推荐的人也可以，只要是能力和口碑俱佳的，碰到这种人，即使不能全职加入，兼职的方式也未尝不可，如果产品顺利，兼职的人后期自然而然就会转成全职了。

这里我大概介绍一下我们的产品澳覓 APP 第一版上线前的状态：当时核心成员都位于不同的城市，技术方面全职的人员只有我一个，我在南京；其他成员都是熟人推荐的非常靠谱的小伙伴：产品经理是微信资深产品经理兼职，位于广州；设计师是联想的设计师兼职，位于广州；IOS 开发是远光的开发兼职，位于珠海；而我们的创始人在澳门。就是这样一个分布在 4 个城市的松散组织，2 个半月完成了第一版 APP 上线；上线后运行效果非常好，随后兼职人员基本全部收编转为全职了。

另外，需要注意的是核心员工只要你认为值，真的可以不用太考虑成本，即使小公司也是一样，小公司前期更需要优秀的人。还是以我司为例：我们公司的架构师，当时我面试的时候就非常满意，再加上有百度大数据的背景，即使当时要求的薪资超出了我们的预算，而且这种情况下他还不是特别愿意加入，但我一点都没有犹豫，当即叫上了老板一起聊，最后用薪资 + 期权的模式敲定了，现在回过头来看，真的是超值，他给团队和公司带来的价值远远超出了我们付出的有限成本。

最后，核心人员搞定之后，其他成员的招聘主要交给各个小组的 leader 负责就可以了，我主要使用如下几个方式：
1. 充分放权，leader 可以有下属薪资定价权，当然超出范围的需要给出合理的理由；
2. 内推机制，从后面的实际情况来看内推的人真的更靠谱；
3. 宁缺毋滥，我们找的每一个人都是认真考量的，一定要认可公司文化和价值观。

留人

毛主席在《沁园春. 雪》中写道，“一代天骄，成吉思汗，只识弯弓射大雕”，说的是成吉思汗只知道骑在马上打天下而不会治天下。我们辛辛苦苦把人招进来，如果留不住，那岂不是前功尽弃了？所以招人只是万里长征第一步，怎么留住人才更重要。

那么，怎么才能留住人呢？从马斯洛的需求层次理论就能窥其一二，人的需求无非是物质和精神两个层面的。

物质层面

先谈谈物质层面，就是一个字：钱。一般初创公司的薪资不会太高，希望用期权的方式留住人，但是经历了这几年互联网公司各种期权问题后，这个方式对于大部分员工已经失效了，因此，我们至少要提供和业内持平的薪资待遇，再辅以期权模式，效果会更佳。我一般会在每个季度考核结束后，组织主管 review 一遍产品和研发部门的人员结构以及薪资水平，适时调整员工的薪资，及时给予优秀员工奖金或期权奖励，每隔一年左右进行一次普调。

比如我们某部门有位主管，有次沟通的时候得知他个人认为以他的能力和目前的薪资是匹配的，薪资方面也不会有太大的提升了；但是我总觉得他最大的问题是责任心不够强，还有很大的提升空间，于是为了激发他的责任心，让他有更大的成长，沟通后的第二个月给他加薪了，并告诉他，“你的能力远比你想象中的要强，下一个版本由你来主负责”，他收到调薪邮件的时候很意外，还单独给我发微信说感谢对他的信任，然后在接下来的几个月，他经过引导，主动把控研发流程各个环节的进度，并积极带领同事解决之前版本的遗留问题，各方面的能力都有质的提升。可见物质层面需要及时奖励，也需要适时激励。

精神层面

精神层面的范围就比较广一些，每个人都有被认可、被信任的需求，我们要尽量发挥每个成员的价值。我在写这篇文章时，先使用锤子便签列了提纲，恰好在便签中看到了自己在 2018 年第一次使用极客时间 APP 时摘录的德鲁克的一句话：“组织的目的，就是让平凡的人做出不平凡的事”。组织最重要的特性就是用人所长，要充分发挥每个个体的价值，而个体价值的发挥又能反向促进个体对组织的认可。

记得公司某部门最初只有 1 个人，后来加入一位新成员，能力比较强，做事也比较踏实，但是因为有老员工在，做事情总是有些畏手畏脚不能施展他的能力，后来经过沟通，直接任命刚过试用期的新员工为部门主管，然后她渐渐开始放开手脚梳理流程、制定规范，目前管理一支近十人的团队游刃有余，她的部门也是目前最让我放心的一个部门。

结语

今天主要分享了初创团队找人与留人方面的经验，这些年，我自己对于技术管理有几点感悟，或者说是对技术领导者的几点建议，也在此分享一下，希望能给你带来新的思考。
1. 服务思维：很多时候领导就是团队的粘合剂，要有为团队服务的意识；
2. 全局观念：要站在更高层次看待问题，不断引进比我们更优秀的人加入公司，学会“像 CEO 一样思考”；
3. 不断学习：随着公司业务拓展，对各种能力的要求也越来越高，技术管理者也需要与时俱进，不断学习充电，比如订阅极客时间专栏、加入 TGO 鲲鹏会，就是非常好的学习方式。

作者简介

王可光，澳门网络传媒发展有限公司技术总监 、TGO 南京会员，有着 10 余年技术研发、团队管理经验，2016 年联合创办珠海市蜜瓜科技有限公司和澳门新鲜生活科技有限公司两家企业，依托国内技术力量，从事澳门市场智慧生活等方面产品的研发和推广业务，目前公司已成为澳门地区移动互联网方面的领军企业。

第156讲 | 成敏：技术人转型管理的两大秘诀

你好，我是技术领导力专栏主编成敏，今天想跟你分享技术人转型管理的两大秘诀。对技术人来说，做几年技术之后，转向管理是非常自然的职业生涯选择，但相比做技术，做管理更需要从心态、认知及思考方法等层面做出一些改变。

要做杠杆率最高的事情

很多人刚刚成为技术管理者的时候，内心大都会比较焦虑，经常会思考的一个问题就是，技术管理到底应该做什么？其实答案很简单，可以用一句话概括为：带领技术团队，完成目标。

这里的第一个关键点是“带领技术团队”，这是技术转型管理的同学需要适应的最大改变。一方面，你不再是一个人，而是带领着一个团队，你需要为团队包括团队成员的产出、成长等负责；另一方面，相信不少同学都会觉得时间变少了，确切地说，是做技术的时间明显变少了。而当需要做的事情变多以后，该如何选择优先级，比如应该先做技术攻坚，还是先协调资源，或者先去招人？这时就很容易迷失方向。

在跟不少技术管理者交流后，发现这个问题并没有一个标准答案，比较不同团队的规模不同，面对的环境不同，所做的业务也不同，但有一个原则是统一的，即作为技术管理者，要先去做杠杆率最高的事情，为你的团队负责。

之前有位朋友跟我分享过他空降的经历，这里也分享给大家。当时他加入了一个新团队，算是一个空降管理者，但团队的管理方式比较粗放，流程比较粗糙，也没有什么自动化的工具，很多事情的推进都是靠人，导致整个团队的效率比较低。他觉得应该将所有的工作流程自动化，引入更多的工具和方法，这样才能从根本上提高效率。

最初，他认为，杠杆率更高的事情是跟团队一遍一遍地沟通，将他的想法传达给团队，推动团队一起改变。但经过几轮沟通之后，他发现效果并不明显，很多人都是听过就算了，并没有真正将这个想法落地。那要怎样才能真正将自己的理念传输给团队，并在完成繁忙工作任务的同时，让大家真正落地执行这个理念呢？

在经过反思之后，他意识到，空谈是无用的，反而会因为给他们带来额外的工作量而被抵触，关键是让大家先看到这样做的好处，从而愿意跟随。于是，他从自己出发，自己上手优化低效率的工具及做事流程，切实简化团队工作流程、降低重复性工作、提高团队工作效率，事实证明这样做的效果非常明显，减少了很多流程上的、事务性的打扰，团队成员可以更专注在业务的推进和技术的提升上。而享受到了这样实实在在的好处后，之后再带着大家一步一步往下推进就比较容易了。

另外，长期来看，技术管理者可能会逐渐演变成两个角色，队长或教练。有的技术管理者可能更像队长，带领团队在一线冲锋；有的技术管理者可能更像教练，关注团队的组成，关注团队的成长。

无论作何选择，大家都应该反问一下自己，这个角色是否与杠杆率最高的事情匹配？从这个角度出发，假设团队输出是一个定值，如果你是队长，可能是在定值上做加法，如果你当教练，更多的是像在定值上做乘法。当然，最终的优化目标会取决于你做加法或乘法的数值。因此，大家需要理性的分析这一点，选择最适合自己的角色。

对于管理者而言，还需要对自身有要求，最好是拥有多面手的能力，不要局限于管理或技术。你能做的事情越多，那你对杠杆率更高的事情就会有更多的选择。

要以结果为导向

从技术转型管理的第二个关键点是“完成目标”，也就是结果导向，这是思维上的重要改变，以前你只需做好自己份内的技术就行了，而现在你还要对结果负责。

很多公司都强调以结果为导向，很多技术管理者在分享自己经验的时候也会强调以终为始，但在实际工作中，很多人其实并没有真正理解结果导向的意义，或者意识到了，但却找各种各样的理由松懈自己。比如有的同学会有这样的心态：虽然结果不好，但我已经尽我所能了，可能是因为人手不够，或者外部团队不配合等客观原因才导致了这样的结果。

当然，出现这样的心态并没有错，可以说是一种人性的本能，但作为技术管理者，你要带领团队完成目标，就要去引导他们更进一步去思考：既然存在这些客观原因，那你为此做了什么事情？是否对此提出了你的解决方案？在我看来，积极地推动所有可能影响到结果的因素，尽力打造最好的结果，这才是结果导向的意义。

在具体的执行过程中，我们其实可以把它抽象成一个过程，即先明确目标，然后诊断问题、确定思路、细化方案、实施执行，最后反馈调整，不断反复循环。虽然这个过程已经为大众所知，但多数人在做事的过程中，还是会经常不自觉的忘记这个过程中的某些环节。

举个关于合作的例子，之前我有个朋友加入了一家互联网教育公司，接手了他们的业务开发，当时，他们的产品正处在一个重要版本的开发过程中，问题是这个版本迟迟无法上线。接着他了解到，这不仅是开发团队的问题，而是参与这个产品的所有团队共同导致的问题。

按照流程，他应该首先明确自己的目标。那他的目标是做好技术工作吗？不止于此，作为技术管理者，应该以结果为导向，推动产品顺利交付。

接下来诊断问题，其实产品无法上线的原因主要来自于多团队合作导致的组织和沟通困难。教育类产品比较复杂，包括了教研、产品、交互、视觉、开发、算法、测试、渠道等等诸多不同的团队，每个团队又有自己的周期，相互协同、同步就存在很大困难。多团队协作，如果不能准确传达信息，错误信息就会不断发酵、放大。另外，每个团队都希望加入更多自己的需求，同时又希望这个过程快一点，就出现了更多矛盾点。

问题诊断清楚之后，就要确定解决思路，当时大家提出了几种思路：

第一，既然多团队协作造成现在的局面，那能不能减少团队呢？这个思路很快就被否定了，正因为有不同的团队，才使得产品更加专业。

第二，能不能找一个个人英雄，由他统领大家完成目标呢？但这么做的难点在于，首先，这样的角色对人的要求很高，需要他对产品的各个环节都了解，包括教研、技术、交互、运营等，很难找到符合要求的人选，其次，即使有这样的人选存在，最后他也很可能成为另一个影响产品推荐的单点。所以，这个思路也被否定了。

第三，能不能将整个过程分解成若干个阶段，并选出一个固定角色来负责每个阶段，其他人辅助呢？这就是最终选取的方案，就好像一个 4×100 米的接力赛，各阶段分别由不同的团队负责领跑，其他团队负责配合，然后大家全力以赴，最终达到目标。

之后就是细化方案、实施执行，而在具体执行中，值得注意的是，因为涉及的团队较多，所以需要提前约定好沟通规范、沟通工具、协商机制等，并用量化的方式来衡量每一次的交接质量，包括需求、提测、交付等。同时，还需要打出富余量，以防意外情况的发生。

最后，为了避免因为合作框架的存在而做事死板，让整个过程保持生命力，还需要有一个复盘会议，大家坐下来一起去分析过程中做的好与不好的地方，好的地方及时沉淀，不好的地方及时改进。另外，这样面对面的复盘会议也可以增强团队相互之间的信任。

总而言之，技术管理不外乎这样一种循环，即明确目标、诊断问题、确定思路、细化方案、实施执行、反馈调整，重要的是做好每一步。对于从技术转型管理的同学来说，需要记住的是，管理不仅仅是一种艺术，在管理中，我们的理性思考无处不在。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

第157讲 | 成敏：技术人才的管理公式

你好，我是技术领导力专栏主编成敏，今天想跟你分享技术管理中的管人这个话题。很多技术转型管理的同学，初期都会觉得管人是管理中最困难的一部分，究其原因，主要在于技术同学习惯面对代码、面对机器，面对人时多少都会有些手足无措。毕竟，相较于人的复杂性来讲，代码和机器会更具逻辑性和确定性。

那我们不妨换个角度思考：如果管人也有公式，是不是又能回到技术人熟悉的思维方式中，是不是就能够降低管人的难度呢？

管人的公式

既然谈公式，就要先确定公式中的各个参数。不妨将员工的表现抽象为五个维度，分别是领导力、项目管理能力、技术能力、业务理解能力和表达沟通能力，并用这五个维度能力的高低构建一个人的能力画像，如图中所示。

根据不同场景，选择考量的维度不同，而且每个维度，细展开来都有不同层次。比如项目管理，最低的层次是个人时间管理，然后逐步上升为工作任务管理，再进阶可能是对整个项目过程的管理。其他四个纬度也是类似。

有了这样的能力画像后，我们就可以尝试把团队成员按照这个模型归类，有了直观的对比后，可以很容易地从中看到某个同学的优势、不足和需要学习与进步的空间。在管理中，我们就可以依照这些信息，跟团队成员进行有针对性的高效沟通，帮助他们更好地成长。

通过这张能力画像图，我们也可以看出团队目前缺少哪类人才。一个优秀的团队中，每位团队成员最好都拥有不一样的技能，这样才能适应各种各样的问题。而借助能力画像，我们可以合理搭配团队间的合作关系，使团队更加稳健。

举个例子，很多团队都有导师制度，会给新加入的员工分配老员工作为导师，便于快速融入团队并获得成长。但导师选择也有诀窍在，要考虑到新老员工之间的相性，如果没有经过思考，随意指定老员工，导致两者之间相性不合，反而会造成反效果。

但如果利用能力画像来量化搭配，就很好的解决这个问题。图中展现出的是两种不同的搭配思路。在搭配 A 中，新员工五个维度的能力普遍弱于老员工，或是跟老员工持平，没有比老员工突出的能力。在搭配 B 中，新员工的综合能力依旧弱于老员工，但他在某个能力维度上却有高于老员工的能力，图中示意的例子中是表达沟通能力这个维度。

你不妨思考一下，搭配 A 与搭配 B，哪种效果更好？

在我看来，搭配 B 的效果会更胜一筹。因为，新老员工双方各有所长，他们可以形成一个良性的合作关系，彼此都可以得到相应的成长，而不是只有老员工在输出。比如，老员工作为导师可以将他在技术能力、业务理解能力等维度上的理解和经验传递给新同学，而新同学有着良好的表达和沟通能力，反过来也会影响导师。这就是搭配 B 效果更佳的原因，有相互促进的作用，因此，在条件允许的情况下，更推荐大家使用 B 类搭配。

当然，这只是一家之言，如果你有不同的看法，欢迎留言探讨。

量化人才成长潜力

对于新同学，我们要关注的不仅仅是他当前的能力，还要关注他未来的成长潜力。如果将一个人的成长潜力比作冰山，那么能力画像中所罗列的个人能力都只是浮在水面的部分，是我们能够直观看到的他现有的能力与经验。

而水面下的部分就是他的潜力，最直接的就是他做事的方法和习惯。但方法和习惯并不是难以习得，所以，起到更深层次影响的是他的基础素质与精神。因此，我们在招贤纳士时，除了关注水面上的部分，还要多多关注水面下的部分，即人才在方法、习惯、基础素质、精神等方面的表现。

那我们怎样培养人才呢？可能有人说，我们直接改善他的方法与习惯不就好了，也有人会说，直接给他打鸡血，提升素质，塑造精神。但从我的实践经验来讲，这样做的效果很差。人才的选育用留，直接只在“育”层面发力去培养人才是不够的，我们要把“用”和“育”结合起来，让他们通过解决问题来提升能力。

在具体实践中，首先需要思考，提供给他们解决的问题是否适合他们需要提升的能力，然后，通过相应的问题，给予相应的磨炼来提升他们的能力与经验。我们还需多做一步，就是跟他们多交流，并让他们刻意训练一些方法与习惯，以此去影响他的基础素质与精神。这是一个比较好的培养人才的逻辑。

从个体到团队

有了人之后，面临的问题就是如何把这些人更好的组织起来，也就是从个体到团队。虽然互联网行业跟体育行业相隔甚远，但运动队的团队组织方式是非常值得大家在组织团队时借鉴的。

比方说一个 NBA 篮球队，或是一个俱乐部足球队，你会发现它非常的形式化，连工资都有上限，比如 NBA 的工资帽。而在这样的环境中，如何组织好团队间的关系，是非常有学问的，也是值得我们借鉴的。

首先，一个先决条件是基本相同的价值观。如果一位同学极度自私或极度不成熟，而你没有办法改变他，不能让他认同并贯彻团队的价值观，那他就不能与这个团队共生，你就需要尽早的将他清出团队。

其次，一个团队需要有相应的规则纪律。我们有很多管理规则，如绩效、奖惩、约定、制度等。但关键在于，作为团队 leader，不能滥用这些规则纪律，而是要利用好它们，让团队运转更加稳健顺畅，同时，通过这些抓手来传达你想传达的东西，比如对团队成员的正面引导。

接着，再上一个层次是文化与归属。我们在做同样的事情，有着同样的“气味”，彼此拥有情谊与信任。很多管理者都会头疼的一个问题是，怎样让新同学快速地融入团队？其实，与其反复跟新同学讲要如何融入团队，都不如设定一些机制，创造条件让他跟团队成员发生互动。团队架构关系是固定的，但我们可以通过互动、沟通，加深彼此的信任，建立新的友好关系，使团队形成一张网，这个团队才可以更加稳健、团结。

最后，最高层次就是彼此拥有共同目标。作为团队的技术 leader，需要经常思考，为什么我们是一个团队？

举个例子，很多创业公司早期，技术团队都是按照技术方向来组织的，但随着规模的扩大和业务的发展，很多公司会选择组织架构调整，按照业务方向来组织团队。对技术人来说，这种调整很可能会让大家感到不知所措，找不准自己的定位。

这时，你作为管理者就需要明确，团队的核心目标是什么。如果是以技术维度来组织团队，核心目标就应该更偏向于技术所产生的效率和质量。而如果以业务维度来组织团队，核心目标就应该更注重于塑造技术对业务产出的贡献，以及团队成员在业务中能够获得的成就感。

正如瑞·达利欧的《原则》一书中强调的，在管理中，理性的思考无处不在。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

第158讲 | 胡峰：人到中年：失业与恐惧

你好，我是京东成都研究院技术专家胡峰，今天想跟你分享的话题是：人到中年：失业与恐惧。

刚入行的时候，听说程序员是吃青春饭的，只能干到 30 岁。过了几年，这个说法变成了 35 岁。如今走在奔四的 “不惑” 之路上，想到如果突然丢了工作，会怎样？还是不免为此有一些惶惑。

人到中年，突然就多了一些恐惧感。

恐惧感：谋生

当你感到害怕丢掉工作时，说明已经不再年轻了，一种为了谋生的恐惧感油然而生。

记得我步出学校后，刚工作满一年，攒下了约一万元的积蓄，然后裸辞了。但只休息了一个月，就开始恐慌起来了。第二个月初，拿着手上的账单计算着，当时在广州，大约每个月的生活成本需要 3000 元。再看着卡上不多的储蓄，不得不从魔幻的虚拟世界回到苟且的现实之中，开始了新一轮的找工作之路。

彼时的恐惧不是失业的恐惧，而是没钱继续生活的恐惧。并不害怕失去工作，是感觉工作随时都可以换一个，要不干嘛要傻乎乎地裸辞呢？所以反倒是想着下次应该多攒点钱才辞职的。而下次是什么时候？当时的我也不知道。

第二次裸辞，已是三年后，这次我不仅想换个工作，还想换个城市，中间休息间隔的时间更长了。辞职好几个月后，我才又在成都开始了找工作。这一次感觉到了，工作没有那么好找，看上去还行也匹配自己的工作并不多，并且工资相对原来的一线城市也整体低了一个档次，但这些也未能让当时的我产生恐惧，仅仅是困惑，看不清前路。

又过了好些年，真的到了中年后，每月都有很多账单要付，贷款要还，再也不会觉得切换工作是一件很随意的事情，裸辞也早已从我的字典里消失。不随意，但未必会恐惧，只是年龄与处境让我此刻更需要认真地面对和思考这个问题。

中年，每个月比年轻那会儿挣得更多了，职位也更高了，生活变得更安适和稳定，这时真正潜伏着的威胁开始出现：技能的上升曲线可能越过了高点，走入平缓区，甚至也许在以缓慢而不易觉察的方式下降，而我们却安之若素。

但中年，悄然而生的恐惧感，并不是阻止我们再进一步的 “鸣枪示警”，而像是中场的哨声，提醒我们人生的上半场快结束了，短暂的休整之后，就该提起精神开始下半场了。

所以恐惧感不应是一种束缚，而是一种警醒。

无惧感：舍生

假如你在一份工作中，对丢掉工作本身产生了恐惧，那你做工作的形式很可能会走向谨小慎微。

这时工作让你产生了恐惧感，你就将会被工作绊住，只想兢兢业业、如履薄冰地做好份内工作，以保护好自己的位置。但为了保护位置所做的所有努力都会是徒劳的，因为恐惧感绊住了你，这样的工作状态，自己也是缺乏信心的，而一个对自己信心不足人，也很难让别人对你产生信心。最终，几乎没有任何办法阻止别人占有你当前的位置。

而偏偏是要对工作的无惧感才能真正释放你的潜力，发挥你的能力，让你能够留在原地甚或更进一步。

作为程序员，我们只有一个位置：专业阵地。这是一个专业性要求比较高的职业，我们被雇佣并要求成为一名专业人士，所以应该像一个专业人士一样行事。普通劳动者和专业人士的区别在于，普通劳动者主要被动接受指令去执行任务，而专业人士则在其领域内自己生成指令，同时在领域外还会向同事或上级提供来自该领域的输出：专业建议。

普通劳动者是一种劳动力资源，他们保证执行，而专业人士则是保证选择的执行方向是有意义的，执行路径是优化的。作为专业人士，我们需要去坚持和持续地打磨专业力，守住这块阵地。

有时我在想，是专业让人拥有无惧感呢，还是无惧了才能走向更专业？也许，“谋生的恐惧”害怕失去的不过是工作岗位，“舍生的无惧”才能塑造专业的职业生涯吧。

安全感：重生

安全感，是渴望稳定、安全的心理需求，是应对事情和环境表现出的确定感与可控感。

本来丢掉工作并不可怕，如果我们很容易找到下一份工作，并能很快适应变化的话。但现实是，如果是因为经济大环境变化导致的失业或技术性淘汰，找下一份工作并不容易，适应这种变化也不轻松。

二十年前，上一辈的中年人，他们从自认为的铁饭碗（国企大厂）中批量下岗了，这是一种社会经济与技术变革引发的批量淘汰。近一点的，如美国 2008 年金融危机，一夜之间失业的也不在少数，而且之后很长一段时间都找不到工作，这并非专业能力过时的技术性淘汰，而是环境剧变导致的萧条。

而离程序员更近的案例，来自 TOMsInsight 的深度调查采访，也就是 2015 年的事。

Tony 37 岁，清华本硕，毕业后加入全球知名的 A 记公司中国研发中心工作 11 年，年薪 80 万。在北京东三环，置业豪宅，老婆全职太太，两个孩子。但 2014 年 5 月，A 记公司中国研发中心裁员，Tony 就成为了其中之一。

Tony 作为专业技术人士的价值依然存在，更以百万年薪身价加入著名的互联网巨头 B 厂。但后来，Tony 却无法适应互联网的节奏，感觉工作上周边环境各种 “浮躁”，管理也不 “专业”，只好再度离职。

辞职后 Tony 很难找到合适的工作：不能很好地适应互联网公司，外企整体不景气招聘冻结，进入体制内早已过了年龄，创业没有机会和资源，当然也没勇气。而维持家庭高品质生活还需要不小的开支。Tony 在 37 岁这年，学会了抽烟、喝酒，仿佛人生的不顺利，来得稍微晚了一些。

最可怕的失业就来自变革引发的技能性淘汰（如：国企下岗），其次是环境引发的萧条（如：金融危机），再次是技能虽然还有普适价值，但自身却适应不了环境变化带来的改变与调整（如：Tony 的危机）。

Tony 面对的危机还是比较少见，属于个人问题。而金融危机也不多见，面对萧条 “血”（储蓄）够厚也可以撑得过去。只有第一种，技能性淘汰，积重难返。四十而不惑，不过四十岁程序员的悲哀在于，他们拥有十五年以上的经历与经验，有时却在和只有五年经验的年轻程序员竞争同样的岗位。

中年人和年轻人本应在不同的战场上。年轻时，拼的是体力、学习力和适应能力，是做解答题的效率与能力；中年了，拼的是脑力、心力和决策能力，是做对选择题的概率。

年轻时，是用体力和时间积累经历，换取成长与机会。就拿我来说，从年轻到中年我的体力状态变化是：20 岁以前可以通宵游戏后再接着上一天课；30 岁以前连续一个月加班通宵颠倒，睡一觉后就又精神满满；35 岁以前，还能上线到凌晨两、三点，睡上几小时后，早上 9 点又正常上班；35 岁以后，就要尽可能保持规律作息，否则可能第二天就精神不振了。

所以，中年了体力下降是自然生理规律，但和脑力有关的学习能力并不会有明显改变。记得以前看过一篇万维钢的文章讲了一本书《成年大脑的秘密生活：令人惊讶的中年大脑天赋》，其中提到：

跟年轻的大脑相比，中年大脑在两个方面的性能是下降的：计算速度和注意力。其他方面，比如模式识别、空间想象能力、逻辑推理能力等等，性能不但没有下降，而且还提高了。

计算速度和注意力下降应该是对学习力有一些影响的，但丰富的经历和经验应该可以缩短学习路径，更有效地学习。回顾过往，年轻时学习的路径试错曲线要长得多，所以这一点在学习效率上得到了弥补。而从其他方面看，模式识别、空间想象和逻辑推理意味着中年人的大脑擅长更多高级的工作技能，所以完全没必要担心 “老了” 会导致学习能力下降。

缺乏安全感，正是源自变化，变化带来的不确定性。

环境和人都处在长期持续的变化中，变化总是不确定的，我们没法消除变化，只能把变化纳入考虑，承认变化是永恒的，不确定是长期的。面对这一点很难，难在反人性，我们真正需要做的是战胜自己人性里的另一面 —— 适应变化，无论世界怎样变化，内心依然波澜不惊，就像大海深处，无论海面如何波浪滔天，深处依然静谧悠然。

简言之，人到中年，转换了战场，重新定位自己的优势，转变核心竞争力，浴火重生，开启人生的下半场。

…

年轻时，我们打的是突击站，左冲右突；中年了，我们打的是阵地战，稳步推进；如今，我们进入了人生的中场战事。这场战事从谋生的恐惧感开始，给予我们警示；到舍生的无惧感，让我们摆脱束缚，整装待发；最后经过重生的安全感，推动我们再次上升。

关于中年之惑，你有哪些看法呢？

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎订阅胡峰老师的专栏《程序员进阶攻略》，获得更多关于持续成长的经验。

作者简介

胡峰，TGO 鲲鹏会会员，京东成都研究院技术专家，目前承担京东咚咚产品线技术架构工作，专注于 Java 后端分布式系统技术架构相关领域。除了技术工作外，近年来也开始领导研究院技术委员会，负责人才识别，晋升选拔，关注人才梯队层次建设和个人进阶发展。

第159讲 | 黄云：技术管理者如何科学的做好向上管理

你好，我是川报观察 CTO 黄云，今天想跟你分享的话题是，技术管理者如何科学的做好向上管理。

近日，嫦娥四号登陆月球背面的消息刷爆了朋友圈，NASA 也发推祝贺。其实早在 60 年代，阿波罗 17 号的宇航员哈里森·施密特就曾尝试去推动 NASA 将阿波罗 17 号的登月舱降落地点选在月球背面，但最终失败，从而遗憾终生。

从施密特的角度出发，这算是一次典型的“向上管理”失败，也由此可见“向上管理”是多么的重要。对于技术管理者特别是非技术型公司的技术管理员而言，向上管理更为重要，有时候甚至关乎到整个团队乃至公司的生存。

为什么要做“向上管理”

陈春花在谈“向上管理”的时候，引用了彼得·德鲁克在《卓有成效的管理者》一书中的一句话来阐述为什么要做向上管理，“工作想要卓有成效，下属发现并发挥上司的长处是关键”。这和我们很多技术领导者的认知恰恰相反，很多技术领导者更偏向于向下管理、向上负责，从《技术领导力 300 讲》这个专栏也可以看得出来，大部分内容都集中于分享如何提升自身管理下属管理团队的能力，这和大部分技术管理者的认知是匹配的，加之技术员大概率的闷骚属性，对于需要涉及复杂关系处理的向上管理，那是能不碰就不碰。

然而，一个合格的技术管理者，理应“向上管理，向下负责”，需要本着对公司负责、对团队负责、对员工负责的态度，做好向上管理，让领导做更正确的决策，为团队争取更好的环境和更公平的待遇。特别是非技术型企业，决策的高管通常都是业务出生，对技术通常是敬而远之，对于需要花钱来做活动这种可以看得见的东西还可以理解，但是诸如需要抽调精英技术力量来做底层基础架构这种事情却较难沟通，这种情况下，技术管理者如何科学的去做好向上管理，就显得尤为重要了。

如何做好向上管理

1. 领导对你的信任是基础
这是一句废话，但也不算一句废话，因为建立信任是一个循序渐进的过程，技术管理者经常抱怨那些做销售的部门更容易让领导信任，“做得好的不如说得好的”、“会哭的娃儿有奶吃”，这其实也好理解，对于销售部门，领导能很直观的评判一件事情的投入产出比，比如做了一个活动，带来了 200 万赞助，利润是 60%，领导一眼便知，加上领导平时最关心的更多也是利润或业绩指标，所以销售说一项措施可以带来多少利润，领导一般还是会选择相信，而技术，在传统企业往往不是最核心的位置，所以更需要领导的深度信任才能更好的实现向上管理。

那么对于技术领导者而言，如何能让领导更为信任呢？我觉得最有效的还是需要结合技术特色，扬长避短，技术人经常挂在嘴边的就是“Talk is cheap，show me the code”，同样，赢得信任最有效的方式依然是用事实说话。多打硬仗，多解决问题，多干实事都是可以让信任值飙升的有效方式。

举个例子，2011 年，我刚进报社的时候，报社给我们技术团队的定位还只是维护 PC 网站，地位边缘化的可能性很大，但在同对手的一款 APP 创新产品的遭遇战中，团队用七天就完成了对手耗时半年多还没有开发完成的功能并抢先上线，然后又火速被报社打造成了纸媒行业的标杆产品，可谓“一战成名”，这让技术团队的地位得到极大提升，并从此逐渐成为主角，摆脱了被边缘化的命运。

当然，凡事都有两面，信任也是会被不断消耗的，技术管理者时刻保持清醒是必须的，对所负责的事情怀有敬畏之心，否则很可能整个团队的信誉会因为一些细节而毁于一旦。

曾经，我们技术团队在公司举办年会的时候，做了些炫技的操作，通过人工控制 2 台 PAD 来做效果的叠加互动，虽然排练期间都非常顺利，但关键时刻却掉了链子，控制 PAD 的同学竟然没有协调好，导致互动效果大打折扣，前期团队的心血付诸一空，后来又有两次技术创新类的现场活动出现意外，导致我们领导对技术团队承担活动的能力大为怀疑，后面但凡是有技术参与的活动，就让我离主席台远点，估计是觉得我磁场太大，离近了连话筒都会失声，甚为悲惨，更不用说说服领导在重要场合做一些技术创新了。好在这只是一些插曲。

2. 信息对称是前提
有了信任的基础，也并不表示领导就会对你言听计从，只是让你有了和领导对话的可能，如何进一步做有效的向上管理，找适当的时机用适当的语言也是极为关键的因素。要做到这点，信息对称是一个很重要的前提，只有上知领导所忧下知员工所想，才可能让你的建议或意见更能为领导所接受。

需要有心理准备的是，信息对称绝对是一个需要日常长期保持的工作，不但需要向上对称领导的信息，还需要对称公司所处的大环境的信息，更需要对称团队和下属的诉求。信息对称的越充分，则意味着你的方案更科学，也更容易被领导接受。

要做好信息对称，如果能和领导和员工经常保持沟通自然是最好的，如果不能，那挖掘部门内的消息灵通人士并和他们保持密切关系是个不错的选择，运维工程师和 HR 是很好的“标的”。技术管理者要做好向上管理，还是需要有一颗“八卦的心”，只有这样，你才能知道领导可能会接受什么，以什么样的方式接受。

有时候，技术领导者们在信息不对称的情况下，常常会出现自我感觉良好或者感叹怀才不遇的情形，觉得自己深处一线，屹立于技术前沿，方案好的不得了，却没有去尝试对称领导的想法和公司的战略，只是想一味的说服领导，被拒绝后还不忘吐槽一番，这是典型的没把向上管理认识清楚的表现。事实上，大部分时候领导都是聪明的，而且掌握的信息量更大，所做的决策需要考虑的方面也更多，总之，不要单纯的认为领导啥都不懂就对了，就如同你真的认为乾隆真的很傻，不知道和珅的种种行为么？

3. 谋定而动
单纯就某项具体的事情而言，必须清楚，向上管理肯定不是一次就能成功的，正确的心态一定是一次没成功，那就换个姿势，再来一次。一定要沉住气，然后根据领导的反馈，重新审视自己的提议或者方案，如果再辅助一些说服手段收效就能更明显，多发一些类似观点的大咖文章或者请外地的业内大拿来神助攻都是很好的曲线救国方法。绝对不要抱着一蹴而就的心态，也不要被拒绝或者没通过就放弃治疗。在没找到第二次汇报的机会期间，不断完善方案、做好一些前期准备或者去做一些小范围的验证是更好的选择。

身边有很多这样的案例，都是前期几个人的虚拟团队，利用空余的时间，做一些尝试性的工作，最后验证成功，领导看到后主动加一把火。所以，领导的一次不同意并不等于向上管理失败，还是那句话“人生没有白走的路，每一步都算数”，与其吐槽引起自己不高兴，不如多多审视并完善方案，寻求下次机会再做汇报。

还是之前我们那个七天就完胜对手的项目，之所以七天可以出来，也是因为在前期我们就基本已经把技术选型、功能规划之类工作的做好了充分的准备，所谓“万事俱备，只欠东风”，领导当时只说了一个字“做”，这边就已经进入到了项目收尾的阶段，加之后面在全面推广的阶段，后续的功能也有所规划，所以迅速拉开和对手的距离，导致对手直接想放弃产品上线。

4. 向上管理不是单纯的直线向上，还需要协助决策领导解决周边障碍

很多时候，技术管理者觉得向上管理就是单纯的针对直线领导，这算是一个误区，甚至很多时候，直线领导是最容易认同你的，因为经常在一起，彼此交流的会多一些，信息对称的也会最到位。但有时候，由于周边环境存在的各种障碍（如关系的平衡、其他领导的认知不统一等），会导致直线领导无法去落实你的想法，这时候，就需要你将向上管理的范畴放大，协助领导去解决好周边的障碍，为最终目标的实现提供干净的外围环境。具体方式可以参考前面的三条建议。

有人说，向上管理是一种心机主义，我不甚认同，有心和有心机是有着本质区别的两个词。作为一个技术管理者，理应站在自己专业的角度，本着对公司负责、对团队负责、对下属负责的态度，用心为团队的发展争取更多的资源，争取更好的团队环境。

最后，还是继续借用陈春花在“向上管理”一文的结束语中的话，“在向上管理上，彼得·德鲁克还认为，有效的管理者了解他的上司也是普通人，肯定有其长处和短处。如果能在上司的长处上下功夫，协助他做好工作，便能在帮助上司的同时也带动下属自己。要使上司发挥所长，不能靠唯命是从，应该从正确的事情着手，并以上司能够接受的方式向其提出建议”。希望我们的技术管理者都能成为向上管理的高手！

关于向上管理，你有哪些看法呢？欢迎留言分享~

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

黄云，TGO 成都分会学习委员，川报观察 CTO，四川日报报业集团媒体融合发展技术委员会委员。

第160讲 | 胡键：创业公司需要高凝聚力高绩效的技术团队

你好，我是上海圭步 CTO 胡键。我们常说“天下武功唯快不破”，很多人对此深信不疑。放在创业公司的背景下，则反映了创业者对于高绩效队伍的向往。然而，在我看来，光有高绩效是不够的，它还有一个前题，那就是：高凝聚力。由于极客时间的受众主要是技术人员，而我的职责也是技术管理和研发，那本文就重点讨论一下创业公司为何需要一支高凝聚力高绩效的技术队伍。

什么样的队伍是高凝聚力的技术队伍？

我认为高凝聚力的技术队伍至少要达到三个方面的一致：价值观、技术观和方法论。

价值观

价值观一词可能有点抽象，几乎每个公司都会提及，但要问每一个人“什么是价值观？”你得到的答案都不一样。本文不会就此展开，而且咬文嚼字也不是我个人的兴趣。就价值观而言，我看中的主要是：

团队拥有一致的对错观

团队对自己有高标准的要求

团队内部对协作保持一种开放心态

大多数人对于前两条应该不会有太多疑问，这里我来说说第三条为何在打造高凝聚力的团队中那么重要。通俗地讲，第三条可以简化成：我为人人，人人为我。由于软件开发是一种团队协作，只有构成产品的每一部分都完成了，整个产品才算完成。单单只是前端完工或者后端调完，从用户的角度看，这并不是一个完整的产品，根本无法使用。

对于协作的态度，这么多年的经历让我观察到两种类型的团队：
第一种类型，大家自扫门前雪，团队协作靠上游拉动。出了问题，首先由最上游的小伙伴排查，逐一往下走。
第二种类型，大家除了干好本职工作，同时也会在力所能及的前题下，去帮助那些需要帮助的小伙伴。出了问题，相关人员会一起帮助排查。

很明显，后者团队的协作要比前者要好得多，并且它还带来了一些额外的好处。

首先，带来了效率的提升，它有助于知识在团队内流动，对于日后解决其他问题会有帮助。因为我们对其他人的工作内容多少都有些了解，当出现类似或相关问题时，这些知识就有助于排查问题。

其次，有利于培养团队认同感，团队相关成员会认为自己是团队的一份子，现在正在开发的产品是“我们的产品”，而不会像第一种团队成员中普遍存在的：“这不是我的工作”。这种团队认同感恰恰是高凝聚力团队不可或缺的一部分。

技术观

除了价值观，技术观一致也很关键。作为技术领导者，你肯定不希望看到组内成天充斥着不同技术之间的嘴炮。一来这种争论纯属浪费时间；二来容易成为团队不和的导火索。为了避免这种情况发生，技术的一致性就显得至关重要了。

就技术观而言，我会要求团队管理者做到三个方面的一致性：平台、架构和工具。在一段时间内，从众多技术选择中认定一种，并坚持下去。并在招人时也有的放矢，不仅仅看重应试者的技能，同时也看重应试者的技术开放程度。尤其是后者，对于那种死抱着自己擅长的技术，坚决抵制改变的开发者，是不会在我的团队中受欢迎的。

拥有一致的技术观，会让团队更关注于解决问题，而不是去对技术挑三拣四、朝秦暮楚，并且也有利于团队的技术积累，进而带来更高的绩效。以 IDE 为例，开发队伍采用同样的 IDE 有以下这些好处：

统一 IDE 设置，如 TAB 键对应 4 个空格还是 8 个或者根本不做变化，这样使得代码格式在不同机器间得以统一。

统一编码习惯，因为同一 IDE 的快捷键往往一致，当开发者之间相互结对编程时，不会因为换了机器而觉得不顺手。

规避了法律风险，比如有人采用盗版的付费 IDE，而作为管理者却完全不知情。

方法论

如果说价值观统一了团队的意识，技术观统一了团队的工具，那么方法论则起到了统一团队做事方式的目的。就时下的软件开发而言，敏捷是主旋律，然而就是在这个主旋律之下，依然演变出不同的流派，比如 SCURM、KANBAN 等等。不论采用何种方法论，有一点是关键的，坚持一种，就是整个公司的技术研发都采用一种。这种方式虽然有点独裁，但放在创业公司的背景下不无道理，原因有二：

创业公司的人手本就不足，人员很有可能会在团队间来回切换，拥有同样的方法论可以让这一过程更平滑一些。

创业公司早期结构相对简单，不论采用哪种方法论，其得到的结果不会有太多差异，因此坚持一种完全可行。

什么样的队伍是高绩效的技术队伍？

高凝聚力的队伍还需具备高绩效的才能称得上有战斗力，毕竟你不能指望一群高凝聚力的肉鸡战胜一只饥饿的狐狸。关于高绩效的队伍，其实已经有很多文章都有过提及，各有各的看法，而且也都很有道理。这里我只谈谈我的个人认识，当然，同样是在创业公司的背景下去探讨。

高绩效的队伍特点有很多，但我个人看重的就三条：高执行力、自我进化能力和做对的事情。

高执行力

高执行力除了通常所说的“指哪打哪、说到做到”之外，还有一个我个人比较看重的特质，即自我驱动力。它是一切高绩效队伍或高效个人的基础。反映在具体事项上就是主动，而非被动等着分配任务。创业公司内部大多制度不健全，也不会有非常明确的绩效考核机制，更多地是靠人治。

在这样的环境里，不主动的人也能很容易地生存下来，而且还会显得很忙，因为有人会推着他往前走。但换个角度，这种方式在某种程度上增加了公司的管理成本，一旦没人推，又开始放羊。因此，即便他能很好地完成本职工作，但若是等着分配任务，那无异于是公司战斗力的浪费。而且，我很难认为一个不主动的员工对于公司都多大的认同感，是否愿意在公司需要他的时候给予公司支持。从团队的角度来看，有这样的人存在也很难建设一支高执行力的团队。

自我进化能力

自我进化能力则反映出一个现实：创业公司早期能吸引到的人和它想要的人并不匹配。原因显而易见：人总是趋利避害，能力强的人总有更好的选择，而创业公司尤其在早期风险较高。在这样的情况下，团队的自我成长能力就显得很关键了。而且，由于创业公司自身发展的速度和外界的变化，也都要求团队有良好的自我成长能力。比如，支撑 1w 并发请求的产品得到了市场好评，面对不断上升的访问量，能不能很快支持到 10w、100w 或者更高呢？如果缺乏良好的自我进化能力，这几乎难以实现。

自我进化能力不仅仅体现在技术上，同时还体现在其他方方面面，比如：技术管理、架构发展、方法论等等。从公司角度来讲，这种跟着公司同甘共苦成长起来的队伍，稳定性和忠诚度不是空降领导可以比拟的，是公司自身的财富。而且，它本身还对公司的其他团队有示范标杆作用，激励其他队伍向其学习。

做对的事情

“做对的事情”虽然是一个人人都明白的道理，但要做好却没有那么容易。什么是“对的事情”？在每个阶段可能含义并不一样，在原型还没有出来就考虑高并发架构显然是一个错误的行为。而在产品已经得到市场考验，但依然只关注功能而不关注架构同样不是一个对的事情。方向对了，事半功倍；反之，则事倍功半。自然谈不上什么高绩效。

啰嗦了这么半天，现在到了总结时间。

总结

大多数人对于创业公司需要拥有一支高绩效的团队毫无疑问，但在我看来，它还有一个前提：高凝聚力。作为创业公司，为了能在残酷的市场上生存下来，它必须高度聚焦、反应迅速，作为其技术支撑的团队如果缺乏凝聚力必然导致三种现象发生。

1. 迟疑，小到不认同公司选择的技术架构，大到甚至不认同公司的目标，进而导致整个队伍缺乏行动力，严重时导致队伍出现逃兵，对整个生产力和士气打击巨大。

2. 浪费，过于多样化的团队在创业公司早期并不可取，它很容易分散团队的精力，在不重要的事情上浪费时间，而在真正重要的工作上却没有取得任何实质性的进展。

3. 抗压能力差，创业是条艰险的道路，很少有一帆风顺，更多地可能是遇到各种意想不到的状况。比如预期大卖的产品无人问津，或是刚刚感觉找对了方向，但很快竞争对手就出现了。如果没有很强的向心力，队伍很容易就会出现负面心态，导致怨天尤人，不能真正面对问题，寻找解决之道，在公司需要大家携手共渡难关之时，队伍反而分崩离析。

况且，只要技术队伍的资质过得去，从高凝聚力的队伍升级到高凝聚力高绩效的队伍并不算太难，因为创业本身也是不断发展的过程，刚开始对于技术技能的要求算不上太高。而反过来，由高绩效升级到高凝聚力可就没有那么容易了。正如电影《天下无贼》中葛优所说“人心散了，队伍不好带了。”

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

胡键，上海圭步 CTO，TGO 鲲鹏会会员，前 InfoQ 中文站 SOA 社区首席编辑。超过 15 年软件研发经验，先后任职于中兴和 SAP，现专注于工业物联网创业，具有丰富的产品研发和项目实施经验，擅长围绕设备资产和生产管理提供物联网端到端解决方案。他同时还是 CSM 和活跃的社区活动组织者，在西安组织过多场 HiBlock 区块链技术社区活动并做分享。

第161讲 | 卢亿雷：企业发展的不同阶段，该如何打造高效的研发流程体系

你好，我是 nEqual（恩亿科）合伙人兼首席技术官卢亿雷，今天想跟你分享的话题是，企业发展的不同阶段，该如何打造高效的研发流程体系？

互联网时代，我们可以把公司分为初创期、成长期和成熟期三种类型，初创期企业讲究的短平快的模式，尽可能缩短研发层级，保证最高效的沟通；成长期企业由于发展很快，人员也越来越多，将会迫使企业通过一些系统工具和管理流程体系来进行管理；而成熟企业则必须采用成熟的工具和严格的流程体系架构来管理，所以企业所处的阶段不同，其研发流程体系也有区别之处。

企业发展不同阶段的研发流程体系

初创期和成长期的公司一般采用独立的产品经理负责制，这样做的优势是可以打破部门间的壁垒，拉近产品研发与市场的距离，建立以客户需求和市场需要为导向的跨部门产品组。执行产品经理负责制，是由产品经理全权负责产品全生命周期的管理，直接对产品的市场成功与否负责，对产品的损益负责，并且需要充分利用到整个公司各部门的知识、经验与技能。值得注意的是，这里所说的产品经理负责制，不仅仅要针对公司已有的成形产品，更要适用于新产品的开发，使开发过程中的产品经理能够真正具有相适应的权利。

产品经理不一定非要隶属研发中心，也可以隶属市场部。如果产品经理隶属市场部，则应该在研发中心设立与其相对应的产品研发经理，产品研发经理对产品经理负责。另外，通过产品经理制度的实施，可以为公司培养懂技术、懂管理、懂市场的中坚力量，并在一定程度上避免公司人才严重流失的情况。

处于成熟期的公司一般采用系统监控负责制，即所有的模块，包括底层系统、应用系统、会议安排、员工管理等在内的相关系统全部需要通过监控系统来实现。比如，如果某个产品的某个系统出现问题，将会由监控系统通过邮件、短信、电话等方式通知负责人，如果负责人一直不处理，就会一直通知。如果是关键系统中的关键指标，将会上升到更高一级的领导，直到有人开始处理为止。成熟期公司的研发管理制度一般包含以下几个方面：

有完整的研发职称体系。比如百度就有 M 系列（管理）、T 系列（技术）等，每个员工可以根据自己的职业发展规划选择适合自己的职称体系；
有完善的系统工具。比如监控系统、预警系统、工单系统、KPI（OKR）考核系统、员工管理系统等；
有全面的员工培训体系。包括新员工入职培训、定期专业知识培训、定期各种马拉松竞赛等；
分部门采取各种不同的开发模式。如敏捷软件开发（SCRUM、XP）、DevOps 等各种开发模式。

初创期和成长期的公司也都会或多或少用到各种系统工具、各种开发模式，不过他们更多的会采取一种模式，也就是使用统一的管理方式，这样效率才会更高。

以人为核心的研发流程体系

为了提高公司的流程效率，管理一般有从人出发和从事出发两种方式。不管是初创期、成长期，还是成熟期的公司，要打造一个高效的研发流程体系，以人为核心的管理办法是最重要的管理方式，因为研发人员是一群高智商的人群，只有把研发人员管理好了，研发效率才会快速得到提高。以人为核心的管理方法主要是通过以人为主体，根据不同人的特点分配不同的项目，同时在项目里根据人的特长配备不同的有梯度的研发人员，保证项目顺利进行，像敏捷等开发模式就是以人为核心的一种管理方法实践。

以 nEqual 为例，nEqual 属于成长期的企业，我们重点采用以人为核心的管理方法，主要的研发流程分为如下几个方面：

1. 采用类似于百度的职称体系架构，分为 M 系列（管理）、P 系列（产品经理）、T 系列（工程师）、R 系列（研究员）四个职称，给技术同学提供了清晰明确的成长路径，保证了技术、产品同学可以根据职业规划来选择自己的发展方向。

2. 构建了一套完整的监控系统，包括系统级监控系统和应用级监控系统。特别是应用级监控系统，由于有邮件、短信、电话预警和通知，将会极大提高研发工程的效率。同时，我们采用的是系统责任制，某个产品线所有的同学以负责系统稳定可靠性为目标，系统出现任何问题，此产品线的所有同学都要承担责任。比如某个负责子系统的工程师，凌晨收到报警后，需要完成打开电脑、连接 VPN、连接服务器、查看应用程序和系统日志、定位问题、重启程序、服务正常、继续睡觉的一系列动作。

而由于我们采取的是系统责任制，如果这位工程师一天不从根本上解决此问题，那么他每天都要重复这样的事情，他自己也会受不了，一定会在接下来的时间通过优化程序，彻底解决此问题来保证自己不天天被打扰。通过这种方法，可以大大提高系统稳定性，同时也可以最大化调动研发人员的积极性，保证研发效率高速运转。

3. 成立了学院，定期给研发人员分享前沿技术、系统培训分布式系统、分布式计算、分布式存储、高并发等相关理论和实践，也会让员工分享项目中遇到的问题，这样会让研发同学有系统的学习技术的机会，在以后的新项目中可以快速上手，研发效率变高，同时也让他们感觉在企业里学到了新知识，保证了他们的学习兴趣，也提高对企业的忠诚度。

4、采用 OKR，即目标与关键成果法，是一套明确和跟踪目标及其完成情况的管理工具和工作方法，并在团队中共享，这样就可以在整个组织中明确目标，帮助协调和集中精力。

5. 采用 SCRUM 的敏捷开发模式，同时内部采用持续集成（CI）、持续发布（CD）的软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

6. 构建了统一的公共平台和数据中台，成立了基础架构部，保证技术、数据等尽可能的复用，提高企业的整体技术能力。由于技术模块、架构等的复用，整个企业的研发效率得以更高效的发展，也让不同的研发同学能选择适合自己的技术路线，比如喜欢做基础服务的就可以去平台底层团队，想做应用层的就可以去不同的产品线服务业务团队。

7. 每个月都有技术评审会，通过技术评审强化多个备选方案、把握新技术应用、体现技术合力和技术继承，保证“正确地做事”，同时让研发同学学习了解到技术选型其实是一个平衡技术与业务的问题，促进更多技术同学的架构能力得到快速发展。

小结

企业打造高效的研发流程体系最重要还是人的问题，一切需要以人为核心来驱动，不管我们是采用敏捷开发模式，还是通过监控预警系统来约束研发人员解决问题，系统和工具只是辅助的手段而已，还需要通过各种流程和方法来激发研发人员的潜力如完整的研发职称体系、完善的培训体系、标准的系统责任制度、自动化的系统监控系统、流程化的技术评审会、OKR 的管理工作方法等。

作者简介

nEqual（恩亿科）合伙人兼 CTO，TGO 鲲鹏会会员，CCF（中国计算机学会）大数据专委委员，北京航空航天大学特聘教授，中国大数据技术大会主席，2017 年大数据行业领军人物。关注数据的采集、清洗、存储、挖掘等整个数据流过程，对分布式存储和分布式计算、超大集群、大数据分析、机器学习、数据安全等有深刻理解及实践经验。有超过 12 年大数据、人工智能、区块链、数据安全等经验。曾在联想、百度、Carbonite 工作，并拥有多篇大数据相关的专利和论文，高教出版社《大数据导论》等书的编写作者。

第162讲 | 王海亮：提升技术团队效率的5个提示（上）

你好，我是王海亮，非常荣幸收到极客时间的邀请，与你分享我对技术团队管理的一点思考与实践。

任何管理方法都有前提，所以，我先聊聊技术团队的一些差异。

技术团队的组建分两个方向，比如刘国梁团队与西游记团队，刘国梁团队是通过层层筛选，都是精兵强将，而西游记团队则是各有亮点，互为补充。

技术团队做的事也分两个方向：项目方向与产品方向，项目方向如甲方委托乙方按要求开发应用；产品方向如给自己公司开发自己运营的产品。

对具体事情的要求也可以分两个方向：追求质量与追求效率，追求质量如硬件驱动、飞机发动机等；追求效率如互联网应用。

这样的分法，相信大家能分出很多，但是请注意，我所说的都是方向，没说具体是什么，因为事情不是非黑即白的，我不建议大家给自己或团队贴一个标签。试想一下，如果我们给自己打上某个标签，我们思考问题或选择方法时就很容易受到标签的影响，将思维局限在某一个区域，但高效最重要的是选择最适合自己的流程与方法来达到比之前更理想的效率，选择时需要穷尽尽可能多的方法，而不要局限在自己的标签里。举个例子，比如你是做电商平台的，属于互联网应用，但是，如果像互联网应用那样就只追求效率，可能就有问题了，因为电商平台中有和钱相关的，和钱相关的部分还是要关注质量，只追求效率，就可能会出现由于系统或流程漏洞而导致巨额亏损。

所以你必须清晰，你当前的团队和所做的事在哪个度上，再根据不同的度选择最适用的方法。

高效的定义

每个人对高效的理解不同，所以，你必须知道你的团队成员、你的上级、你的服务对象等相关人对高效的理解是什么？他们对你团队现在的效率能打多少分？

这些可能每家都不一样，需要你全方位了解你所在的场景，如果大家认为效率低，除了团队自身效率外，还需要考虑你沟通是否充分或反馈是否及时，是否做了大家认为最紧急重要的事情，大家对你工作是否了解，大家对你的预期是否过高等等。

关于沟通的问题，极客时间已经有很好的分享内容，这里，我只是聊聊团队自身效率的提升。

要提升效率，我会先了解影响效率的因素，你可以记录团队每个成员所做的工作与耗时，每周分析一次，如果你对时间与工作内容记录的足够细，相信你一定能分析出哪些是无效或可以不做的工作，哪些是可以节省的时间，效率 = 有效工作量 / 工作时间，注意，是有效工作量，不是总工作量，那么，多做有效工作，减少时间浪费，就一定能提升效率，这个道理非常简单。

下面，我分享几个我的一些思考和实践。

关于组织

我想先通过微软的例子说明下组织对效率的影响，不知道大家是否感受到，Windows7 以前，微软的软件质量相当高，很少出现 Bug，但发布频率很低，到了 Windows10 以后，Bug 明显增多，但发布频率也变高了，那么，微软到底发生了什么？

进入软件行业比较早的人，可能听过微软“三权分立”的组织架构，有开发、测试和程序经理，程序经理负责设计详细的需求规格说明书，开发负责实现需求，测试负责验收需求。这三者是人事层面的三权分立，他们各司其职，互相制衡，带来的好处是能够确保项目质量，因为如果有任何质量问题，测试就不会通过，无法发布，但带来的问题是各自目标不同，互相扯皮，效率低下。

后来微软做了一次意义深远的工程师体系改革，把开发部门和测试部门合并，这样做大大提升了研发效率，加快了发布频率，能很快的响应市场变化，但带来的问题就是大家感受到的 Bug 量明显上升。

基本道理也很简单，就是越集权越高效，但风险越高，反之亦然，没有对错，只有是否适合。比如我们曾经采用过研发和测试一个团队，产品独立团队的组织架构，也采用过产品、研发和测试合并为一个全职能团队的组织架构，并没有好坏对错之分，只看是否适合当时的团队和所做的事。

关于流程

流程和组织架构一样，不同的流程对效率的影响也很大，选择适合的流程非常重要，比如追求质量的和追求效率的需要不同的流程，计划驱动的和拥抱变化的也需要不同的流程。

举个例子，2013 年之前，我用的是 CMMI 模型，它更适合计划驱动、对质量要求高、需求变化少、团队规模大的项目，2013 年后转入敏捷方法中的 Scrum 框架，它更适合对质量要求相对较低、需求变化频繁，团队规模小的项目。如果你认为你的团队介于某两者之间，也可以将多种方法结合，选取适合自己的流程。

道理也很简单，流程越短效率越高，但风险越大，反之亦然。

近几年我做的都是互联网项目，用的都是 Scrum 框架，我就从 Scrum 中选几点分享下我在流程方面的思考与实践。

Scrum 中有三个角色，Product Owner，可以简单理解为产品经理，但比产品经理要求更多的一点是，他需要将产品需求拆解成一个个独立的、可协商的、有价值的、可估算的、很小的、可测试的用户故事，以确保每个迭代都能够上线有价值的产品功能；Scrum Master，可以理解为教练，站在场外，观察并引导每个队员按规则在最佳状态推进工作；Scrum Team 可以理解为球场上的球员，各有分工，但目标一致，实际项目中就是开发、测试、设计等人员，每个 Team 一般为 6 到 8 人。

Scrum 有 5 大会议，在计划会议中，我们会将本次迭代要做的用户故事拆解为具体要执行的任务，团队一起讨论设计方案，再使用扑克牌估算法，估算出每个任务的点数，点数就是这个任务工作量的大小。在对某个任务估算时，所有参会人员使用 Scrum Poker 选择自己认为该任务应该具有的点数，然后将扑克反面放在桌子上，确保不被他人看到自己的点数，当大家都估算完后，由 Scrum Master 发出翻牌指令，大家一起亮牌，由估算点数最小的和最大的人分别说明自己估算的原因，团队再次交流，解决大家的疑问，然后再继续一轮扑克牌估算，直到大家亮牌的点数一致。

这样做有几大好处，首先，大家的参与度很高，能够挖掘出更多的细节；其次，大家对需求与实现的理解基本一致，定下的工作量也是大家认同的。

我们对估算点数的大小也有要求，当估算的点数大于 13 时，任务必须拆分或简化，建议控制在 8 以内。这样做主要有两个目的，一个是要尽可能的确保功能或实现简单，再一个是为了让一个任务尽可能不跨天完成。当然，点数是个相对度量单位，每个团队可能都不同，所以请根据自己团队的实践确定。

我们会将分解的任务用便贴纸按任务状态以列的形式贴在一个物理白板上，便贴纸上包含用户故事编号，优先级编号，任务名和点数。每日例会时，Scrum Team 和 Scrum Master 一起围绕在这个白板前，每个人说下他昨天做了哪些，今天要做哪些，有什么障碍，大家按任务优先级顺序领取任务，承诺预计完成时间，并在领取的任务便签上写上自己的名字，再将便签移动到对应的状态列。

这样的好处是每个人都知道任务当前的状态，是由谁负责的，信息完全透明，同时，任务都是每个人自己领的，时间也是自己承诺的，工作内容与工作量也都是大家认可的，并且有签字仪式，这样承诺意识会更强，。

每个迭代完成后，我们会开回顾会议，回顾会议中，我们会先回顾上一次回顾会议的会议纪要，再让每个人花几分钟写出自己认为本次迭代做得好的和不好的，以及对下次迭代的建议，然后逐个按自己写的内容发言，每个人必须发言，最后再聊聊其他信息，对会议做下总结归纳，形成会议纪要。让每个人先写这点非常重要，不然可能会出现“我和他说的差不多”或发言没有重点等情况。

在回顾会议上，我们不建议上级管理者参加，Scrum Master 不是管理者，他是教练，只是不同的角色，该角色是为 Scrum Team 服务的，所以他要参加。试想一下，如果上级管理者参与，大家可能会无法敞开心扉，因为上级管理者往往和团队成员的利益有关，且上级管理者专注于具体的执行时，也容易忽略掉更重要的场外信息。

那么，管理者要干什么呢？管理者要去建立并不断的优化制度、流程与机制，去创造这个场景，并将团队带入到场景中，然后自己出来，将场景交给团队。

小结

本文分享了我对技术团队管理，尤其是团队效率提升的一些思考与实践。其实道理很简单，通过数据分析，让团队多做有效工作，减少时间浪费，就一定能提升效率。但在实践中，却需要我们从组织、流程、做事方式、专注度、代码质量等诸多可能影响效率的方面入手，通过有针对性的迭代、优化，不断提升团队效率。

受限于篇幅，本文主要分享了我在组织和流程这两个大方向上的实践，下一篇文章中，我将根据以往的实践，分享我在做事方式、专注度、代码质量等方面的经验，欢迎持续关注。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

王海亮，TGO 鲲鹏会北京会员，10 年技术团队管理经验，先后任职于 Newegg.com Team Leader，九州通集团 C 端技术总监，烽泰科技技术总监。

第163讲 | 王海亮：提升技术团队效率的5个提示（下）

你好，我是王海亮，上一篇文章中，我与你分享了我在技术团队效率提升上的一些思考与实践，其实大的原则就是，以数据分析为基础，让团队多做有效工作，减少时间浪费。但在具体实践中，就需要我们从组织、流程、做事方式、专注度、代码质量等诸多可能影响效率的方面入手，不断优化提升团队效率。今天，我就将根据以往的实践，与你分享我们在做事方式、专注度、代码质量等方面的经验。

关于做事

做正确的事与正确的做事也是影响效率非常重要的点，我们知道，事情要从重要程度、紧急程度、成本大小等多方面去考虑，再按优先级顺序处理。优先级最高的应该是紧急重要且成本低的，但这里需要注意的是，这个紧急重要是你认为的，还是需求部门认为的？千万不要陷入到“你以为”的紧急重要中去，即使是技术上真的紧急重要的事，也要和业务连起来，直接或间接的体现出业务价值，否则，业务人员会各种抱怨，甚至可能会出现老板也不知道技术团队一天到晚在忙什么的情况。这点可以通过定期沟通的方式来解决，要做到对上与对外的充分沟通。

需要注意的是，团队要按优先级处理紧急重要事情，但管理者要更关注重要但没被定为紧急的事，因为团队往往会将很重要但不好实现的事情定为重要不紧急，而这些事情又往往会关系到团队或业务未来的发展。

做事情时，我经常会强调以下几点：
1. 强调目标，目标一般为解决业务问题或提升效能等最终目标，而不是完成某个功能或搭建某个技术框架等过程目标。目标要大胆，就像特斯拉创始人埃隆·马斯克那样，事情要做到十倍好，只有大胆的目标，并且相信能做到，为此去找方法，才能激发团队的创新，不止于在原有的思维或经验中徘徊。绝大多数人都是在原有的思维和经验中线性思考，比如项目要早点上线，就想着要么加班，要么增加人员，陷入到自己的心智模式中，只有给他更大胆的目标，很难用原有的思路和方法解决时，才能促使他去改变、去创新。

2. 强调 2/8 原则，强调先用 20% 的精力解决 80% 的用户需求，比如微信，你 80% 的时间在用什么功能？用的这些功能可以理解为 80% 的用户需求，这 80% 的用户需求往往只占微信所有功能中 20% 的工作量，那么，先做这 20% 的工作量来满足 80% 的用户需求，这就是 2/8 原则。

3. 强调适用原则，不要让目标脱离实际，也不需要最好的方案，只要最适合自己的方案，适合的才是最好的。比如，当你在为你产品的吞吐量提升做技术选型或架构设计时，先看看你产品的 QPS、TPS 等现状是什么样的，业务规划的预估是多少，再按实际选择能满足近半年或一年的业务需求即可，而不一定选择吞吐量最大的方案，避免杀鸡用牛刀的情况，浪费资源。

4. 强调 MVP 原则，快速上线最小化可行产品，比如用户需要一个交通工具以提升出行效率，这时你应该先做一个滑板车，快速交付用户，再造自行车，快速迭代，而不要想着一口气造一个跑车，或分阶段先造一个跑车轮子。

5. 强调技术实现也用最小化可行原则，快速迭代，每次实现一个小点，测试可用后再实现下一个小点，要避免技术人员的完美主义或钻牛角尖带来的时间浪费，避免重复造轮子，多借外力，比如使用公有云产品，成熟的开源方案等。

6、 强调技术的简单可控，保持简单非常重要，因为，系统越复杂，依赖越多，越容易出故障，要确保不出故障，就必须加入更多功能，导致系统更加复杂，陷入恶性循环，所以，做任何会让系统变复杂的事情，我们都会特别慎重。

其中技术的简单可控是我强调最多的，也是我发现问题最多的点，因为技术人员经常会为了解决某一问题引入新的技术，甚至会因为某一技术流行或为了学习某一新技术而将其引入到项目中，最终导致项目非常复杂，陷入到各种 Bug 之中。最常见的就是这几年非常火的微服务架构，经常会遇到一个团队不管项目阶段、组织架构、团队规模和人员能力，就将系统设计为微服务架构，并且拆分的非常细，然而，没有做服务治理，没有分布式事务，自动化水平很低，且一个人维护好几个微服务，结果处理各种 Bug 的时间比写业务逻辑的时间还多。

在做事的过程中不断强调这些要点，并不断贯彻落实，到最后，说得多了、做得多了这些就成了你团队的文化，而文化的重要性不言而喻。

关于专注

专注是大家谈的最多的，也是影响效率最严重的原因之一，为了保障技术团队不被打扰，保持专注，我们从组织层面组建了技术支持团队，专门处理业务反馈的技术问题，比如线上问题的排查与解答，数据的提供与处理等。

这个团队独立于技术团队，只有该团队解决不了的技术问题才会提交给技术团队。同时，我们的研发流程采用敏捷方法中的 Scrum 框架，我们给每个冲刺都会预留 2 到 3 名技术人员不参与到 Scrum Team 中，我们将预留的人员叫救火团队，随时处理技术支持团队处理不了的问题或紧急需求。救火团队采用轮值方式，因此，他们熟悉整个团队的业务，也随时可被打断，目的就是为了确保 Scrum Team 的专注。如果仍然需要 Scrum Team 的协助，也是由 Scrum Master 处理，因此，Scrum Team 内是非常专注的。

在沟通协作上面，Scrum Team 成员不建议登录即时通讯工具，禁止各种即时通讯工具的群聊，对外的事情由 Scrum Master 沟通，团队内部和 Scrum Master 一起面对面沟通，Bug 处理通过项目管理工具协作，其他协作均通过项目管理工具或邮箱沟通。我们不建议通过即时通讯工具沟通而转向协作工具或邮件沟通，就是让技术人员尽可能的在自己适当的时刻拉取信息，而避免被随时推送来的信息打断思路，从而确保专注。

很多时候，大家都在谈专注的好处，以及我们怎样才能专注，但需要注意的是，作为管理者，一定要认识到专注的坏处，例如，当你在工位非常专注的写着代码时，你的老板从你身后走过，你会不会发现？如果你真的专注，我想你肯定是看不到老板的。而当你是管理者或 Scrum Master 时，你必须要尽可能多的了解团队的所有信息及外部对团队有价值或有影响的信息，但如果你过多的时间专注在做执行层面的事情时，这些场外信息你就无法获取，而没有全面的信息，你又如何引导团队，如何把握方向呢？因此，我们不建议 Scrum Master 做太多执行层面的事情，因为他需要获取更多的信息。

团队在专注的做完一个迭代后，我们也会让团队停一停，做下回顾、聊聊做得好的、不好的和建议，再聊聊迭代以外的信息，技术对业务产生的价值等等。这个“停”是非常重要的，能够让团队停下来反思，获取更多信息，了解团队及个人的价值，因为大家在专注的做事情时是会忽略这些信息的，长期下来就会导致团队成长缓慢，士气低下。所以，团队也需要和产品一样，不断的迭代升级，每次的停顿就像竹子的节一样，如果节太少，竹子就容易断，但节太多，就长的太慢，我们团队的这个节就是迭代后的回顾会议，频率是每两周一次。

关于代码质量

我相信，改别人的代码是很多程序员最痛苦的事情之一，也会导致效率非常低下，主要有业务和技术两方面原因，如：别人写的业务我不知道，别人的技术实现我不熟悉，别人的代码风格我不习惯等等。

关于这个问题，我们先是通过流程来解决信息透明问题，让团队中每个成员都清楚大家的业务逻辑、解决方案及进展，再通过统一框架与代码规范确保实现统一、风格统一，最后通过代码评审确保执行结果。

关于流程我在上一篇文章中已经有过分享，你可以回顾一下。

关于框架与规范，我们组建了基础框架团队，基础框架团队提供统一的 API 框架，后台管理系统框架及各前端框架，并且提供详细的 Demo，制定每个框架的编码规范及数据库规范。每个业务开发团队必须使用统一框架进行业务系统开发，如果业务开发团队需要引入新技术，必须向框架团队提出申请，新技术引入到框架后才可以线上使用，确保团队内部技术栈统一，实现方式统一，编码风格统一。

关于代码评审，我们是整个 Scrum Team 一起评审，实践上有两种方法，一种是由开发者讲解自己的代码，团队成员提出建议；另一种是互相交换，每个人都讲解别人的代码，其他人提出建议，如果讲的人讲不明白或很吃力，就必须修改。我们评审的主要原则是实现简单，逻辑清晰严谨，遵守编码规范。实践下来第一种方法效率更高，第二种方法质量更好。让大家把代码拿出来讲，大家心理就会有压力，会尽可能的将代码写好，评审时发现有问题的点也需要及时修改，这样，能确保代码质量，也是团队很好的学习与交流的机会。

关于代码注释，我们有个规定，不管是新增还是修改代码，必须有注释，注释必须包含作者、时间及背景，背景主要是需求来源及简短说明，以确保以后看代码的人能方便的找到原需求。

除此之外，我不建议过多的注释，并且写注释一定要慎重，这点可能和很多人的建议不同，因为我认为，代码是程序员自己的语言，这个语言除了和计算机沟通外，还要频繁的和团队其他成员沟通。如果你无法用自己的语言讲清楚你的目的，那就需要尝试换种思路去讲，而不是换种语言去讲，你的语言必须简洁且通俗易懂。但有时，确实有一些非常精妙的设计，需要新人有一定背景或深度思考才能明白，这时才需要注释，注释需要说明背景及设计思路，而不要过多的说实现，因为你的实现必须是简洁且通俗易懂的。

我建议慎用注释，还有一个很重要的原因是，当注释过多时，维护注释与代码逻辑的一致性，也是一个不可忽视的工作量，特别是由于某次疏忽，导致注释与代码逻辑不一致时，你到底是以代码为准还是以注释为准？可能你的第一反应是以代码为准，但仔细想想，你真的能确保代码是正确的吗？在我们的实际工作中，这种不一致的情况不止一次发生，每次都非常痛苦。

其他建议

除了以上提到的组织、流程、做事方式、专注度、代码质量等这五个方面外，影响团队效率的还有很多其他方面的因素，这里再给到几个建议，希望能对你有用。

1. 招最优秀的人才；
2. 花 4 个人的钱招 3 个人做 5 个人的事；
3. 尽可能的工具化、自动化，避免重复工作；
4. 建立愿景、反思与系统化学习机制，打造学习型组织；
5. 建立知识库，确保知识与经验的积累和传承；
6. 建立工作清单，让每个事件或过程都使用清单的方式简洁的列出，就像书的目录一样，确保不会漏掉重要的事情；
7. 淘汰绩效差的人员，招聘更优秀的人员，给团队输入新鲜血液，确保团队良性发展；
8. 采用深度聆听、团队共创法等方式、让团队参与和决策、尊重并认可团队、保持团队的开心与激情等；

总而言之，任何管理方法都有前提，我提到的方法不适合所有情况，但道理越基础越通用。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

王海亮，TGO 鲲鹏会北京会员，10 年技术团队管理经验，先后任职于 Newegg.com Team Leader，九州通集团 C 端技术总监，烽泰科技技术总监。

第164讲 | 陈崇磐：心理成熟度 - 创业公司识人利器

你好，我是德信随寓 CTO 兼 COO 陈崇磐，很不幸，但也很幸运，我的职业生涯中有过几次从头搭建团队的经历，本文我将分享创业公司招人和组队的经验，希望对你有所启发。

招人是公司永恒的旋律，而创业公司的招人更是贝九级别的交响曲，冗长而跌宕起伏，一旦团队顺利成型，带给人的成就感也如交响乐带来的震撼一样，更印象深刻且耐人寻味。

可问题是处于创业阶段的公司招人，是所有公司阶段中最难的，因为出不起高价，却要求更高（而不是更低）。虽然 234 原则（2 个人干 4 个人的活，拿 3 个人的工资）就已经很残酷，但更难的是，如何让搭建出的团队能跟上业务的快速发展，而不是牵绊。因此，回到操作层面，当我们没有资本开着直升飞机为人才等 2 个小时的时候，我们该以什么准则在茫茫人海中找我们想要的人？

招人

我们对人群的划分有很多种：男人或女人、感性或理性、外向或内向、老手或萌新、好人或坏人，甚至有人习惯以星座、血型、相貌、色彩偏好等作为划分因素。但在招人的时候，我更喜欢使用心理年龄，这个和生理年龄（工作年限）有一定关联却又不完全等同的标准把人分为四等：幼儿期、少年期、青年期、成年期。

幼儿，不知道自己不知道

这是心理成熟度的第一层级，在职场中的表现就是，碰到问题只会求助，而且在求助的时候，连自己的问题都无法准确描述。这种员工和幼儿一样，没有描述问题的能力，分不清自己与世界的边界，也分不清人与人之间、岗位与岗位之间的边界，只能通过哭和外界对他困难的理解，帮助他解决问题。

为了识别这种候选人，我通常会选择其简历上的项目问一个问题：你们几个之间是怎么分工协作的？比如几个 Java 开发之间、前后端之间等。如果候选人对分工和彼此的边界都不能准确描述，我会把候选人定位为幼儿层级，直接 pass。

少年，知道自己不知道

这是第二层级，正如少年，知道自己是因为个子不够高才拿不到柜子上的玩具，或者因为力气不够大才拧不开超市新买的果酱。这个层级的员工没有足够的能力解决碰到的所有问题，所以在求助时，会对问题有一个准确的描述，甚至自己已经做过某些尝试但还是没能解决，正如已经尝试搬了板凳但还是够不到柜顶上的玩具。

为了分辨这个层级，我通常会问的问题是：你经历的项目中，有没有遇到让你刻苦铭心的困难，你是怎么解决的？这个问题一方面可以通过遇到问题的难度判断候选人的专业技能，比如是属于语言技巧层面、逻辑思维层面、架构设计层面，还是业务运行层面，另一方面可以得知对方是否有尝试过自己解决问题，了解候选人针对问题的主观能动性和韧性。

少年缺少的是专业技能而不是问题意识，一般也能够解决能力范围内的问题。因此如果遇到少年，我通常会结合他的生理年龄也就是工作年限，来判断对方的学习曲线，再结合团队的缺人程度决定是否合作。

青年，知道自己知道

青年属于知道自己知道的层级，一方面，青年往往是团队中的业务骨干，知道自己碰到的是什么问题，也往往能找到解决问题的办法。另一方面，青年也会倾向于证明自己，让别人意识到他的“知道”，因此在工作上会有不错的主观能动性，有时甚至会为了证明自己而出现一个人偷摸捣毁敌人老巢回来邀功的行为，或者叛逆顶撞的现象。

为了分辨青年，我会倾向于问类似的问题：你过往的工作经历中，最让你有成就感的事情是什么？如果对方的答案是落在个人英雄主义的范围，满足于以个人能力赢得团队的尊敬，进而认为自己在团队中不可替代，我就会将他归到青年的层级，否则就会归到最高层级，也就是成年。

抛开其他因素，由底层个人英雄主义延伸出的职业发展障碍，可能成为青年换工作的深层次原因，因为他觉得自己是英雄无用武之地，没人知道他的“知道”，实际上可能是他无法突破技术思维，造成眼高手低。

这个问题的另一种表现形式是：我们也经常遵循“学而优则仕”的原则去提拔技术骨干，让他去驱动或影响他人，这样，既让他成为榜样，也解决了骨干的发展空间问题。但现实中这样做并不能每次都成功，失败的结果是既陷入了管理混乱，又损失了一名技术骨干（技术人员的自尊往往很难接受自己回到从前）。我对这个问题的个人体会是，事先判断心理层级，如果技术骨干还处于青年的层级，切忌拔苗助长。

成人，不知道自己知道

这里的不知道不是真的不知道，而是自己的知道已经悄然地融入到日常行为中，不需要刻意让自己或者别人了解自己已经知道。成人和青年的区别，在于对问题的认识是否突破了“自己”这个边界，考虑问题的出发点是“自己”，还是“自己 + 相关的人”。

单纯考虑生理年龄，人总会随着时间的流逝慢慢变成成人，但如果以心理年龄衡量，不是人人都能随着工作经验的积累，慢慢成长为成人这个层级。因此，找人的时候，如果能碰到心理上的成人，是非常幸运的一件事。

我经常尝试通过一个开放性的问题了解对方的心理成熟度：你心目中最理想的工作环境是什么？这个问题可以很好地衡量出对方考虑问题的角度，如果他在意的都是与自己利益相关的东西，比如待遇、氛围、能学到东西等，我会将他划分到青年层级而不是成人层级。听起来很苛刻甚至有点作，容我解释一下，我们不是要找不食人间烟火的圣人，或者只付出不求回报的老黄牛，因为也不现实。但我对这个问题的理解是，自己的获得往往是结果而不是理由，是终点而不是起点。如果以结果作为起点，往往是因果倒置。

如果碰到成人且对业务有兴趣，重用吧。

上述的心理层次模型是一个管理工具，某种程度上可以帮助我们判断碰到的人，但这种判断只是基础和前提。我一直认为大多数团队中，从诸多因素出发，业务骨干往往是青年这个层级的员工。但青年层级的业务骨干是最难管理的群体，因为青年的个人英雄主义行为经常会落入好心办坏事的境况，一个有着良好出发点的行为却因为考虑范围不够而给团队带来了不好的影响，这个时候鼓励和约束都不合适。例如我就遇到过弹性工作制下习惯性凌晨 3 点拼命工作，第二天 11 点钟还不见踪影的员工。因此，在团队的组建上，除了判断人的原则，更需要组队的原则。

受限于篇幅，创业公司组队的原则我将在下一篇文章中继续分享，欢迎持续关注。如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

陈崇磐，德信随寓 CTO 兼 COO，TGO 鲲鹏会会员，多次从零开始搭建团队，有丰富的团队打造经验，曾在通信领域扎根 10 多年，先后就职于华为、摩托罗拉、诺西通信等公司。2013 年开始自主创业，并随后加入创业社交平台–微链担任 CTO，目前专注长租公寓领域。

第165讲 | 陈崇磐：管事与管人 - 如何避开创业公司组队陷阱

你好，我是德信随寓 CTO 兼 COO 陈崇磐，在上一篇文章中，我分享了创业团队招人的心理年龄原则，以及基于此原则划分的人才等级：幼儿期、少年期、青年期、成年期，并分析了各个等级的特点和管理对策。在团队的组建中，选人很重要，而如何组队，将人才价值的体现最大化更加重要，今天我们就来聊一聊组队的原则。

组队

当大多数人被问起“一个都是孙悟空的团队是不是好团队”时，往往都会摇头。很显然，大多数团队都需要相互配合才能高效工作。效率来自分工，分工需要协作，配合和协作是一个团队的基石。都是孙悟空，不仅浪费了资源，也不一定有好的配合。

理想团队模型

针对每个团队成员而言，专业技能决定他能解决什么样的问题，而心理年龄决定他能解决多大的问题。汇总成一个团队，专业技能的短板决定了这个团队能不能做起一件事，而心理年龄的长板决定了能把这件事做到多大。孙悟空是专业技能很强，但心理成熟度不一定匹配的员工，如纯订单销售导向的团队可以由孙悟空为基本组成来搭建，但对大部分团队而言，我设想的最理想模型应该如下图所示：

这样的设想有如下几个考虑点：

处于管理位置的必须是成人，否则团队的正常运转无法保证；
业务骨干有 2 个，成人或者青年。2 个有竞争也有备份，防止团队被业务骨干绑架；

每个业务骨干各带一个业务新手，可以是少年或青年，业务新手有学习的对象，团队有后备的力量，业务骨干也有培养新人的成就感；
再配备一名少年业务小白，为团队补充新鲜血液，也作为业务新手的后备力量；

整个团队模型中的每个人都有上升的空间，但成为业务骨干之前都是专业技能的上升，而业务骨干到团队负责人的升迁则属于业务到管理的突变；

团队负责人可以做业务，但不应该是主要职能，重心还是应该放在团队管理、放在带领团队突破业务上。小型团队往往需要负责人做一些业务工作，比如“CTO 要不要写代码”这个永恒的问题就是很好的例子，但不应该本末倒置。

有了预留的成长空间，随着团队规模的扩大，团队成员就会面临两个重要的突变：从做事到管事，再从管事到管人，如下图所示：

其中，做事阶段的重点是做好自己，管事和管人阶段的重点都是管好他人。学而优则仕，是完成“做好自己”到“管好他人”的突变，而这个突变需要以青年到成人的突变作为基础。创业公司经常会出现一个问题，就是让做事还不错，即专业技能不错的员工，直接沿着红色升迁路线到达“管人”的位置，直接从“做事”跃迁到“管人”，跳过了“管事”这个阶段。这有现实条件的无奈，也有提拔升迁时考虑是否全面的因素。

如果业务需要的协作不复杂，则处于青年心理层次的员工在做事的阶段也可以有很好的表现。但一旦团队规模达到每个小组至少三个成员时，则势必要有人慢慢承担小组的管理工作，比如提拔业务开发骨干担任小组长，提拔架构师担任项目经理或者团队负责人等。此时应该考察的是心理成熟度，而不是业务能力。所以，从“做事”直接到“管人”的红色升迁路线要尽量避免，并不是所有人都有能力或者意愿完成突变，如果团队内部没有合适的人，宁愿外招。

管事的原则

从“做事”到“管事”，是“自己做事”到“驱动做事”的区别，也是动手到动嘴的转变。在辅导新人如何“管事”时，我通常会解释如下原则：

受益原则：谁受益谁驱动。在团队协作边界不是很清晰的情况下，往往会导致一个事情落到几不管的灰色地带中，尤其是创业公司更容易出现这种情况。此时如果没有一个清晰的原则，则会使小公司得大公司的病，事情推动效率非常低下。而受益原则比较粗暴，约定谁受益谁驱动，会让问题在边界划分清楚之前快速得到解决，也让新手在犹豫到底该不该插手时有了一个简单的原则。

基准原则：时间节点是协作的基准。正如 NTP 是服务器群正常工作的基础，所有相关方共同认可的时间节点表是团队协作的基准。如果没有一个所有人都认可的时间节点表，不要贸然启动。

推动原则：从目标到范围、从工作量到计划，从跟踪到关闭。这是典型的项目管理方法，也是驱动做事的套路。分解一下：

首先，确定整个事情的目标，以及为了达成目标的路径和手段，进而确定出整个事情涉及的人和事。
其次，基于事确定出工作量，基于做事的人确定难度系数，形成所有相关方都认可的时间节点，进而形成计划
最后，启动计划，过程中不断监控、评估、协调，直至所有节点关闭。

受阻原则：如果推不动，尝试改变协调方式而不是停止。管事新手会经常落入推不动而被迫停止的苦恼境地，这可能有多种原因：协调手段不合适、事情条件不成熟、相关方时间冲突、相关方配合意愿不足（尤其跨部门协作）等。有些新手会在团队追溯分析时把原因归结到别人的不配合或者团队给了尚方宝剑的同时没有约束所有相关方等，但管事者最需要的是在过程中找到原因，改变协调方式，而不是在冲破时间节点时找责任方，想办法推动事情才是关键。

好人原则：当面的妥协并不是真正的好人。对团队而言，把事情推到底落到地，才是一个真正好的管事者。

管人的原则

当团队中有了成熟的管事者，下一个成长目标便是让他“管人”。从“管事”到“管人”，是“成就自己”和“成就他人”的区别。既然管人，就要有通过成就他人来成就自己的格局。而一旦管人，在事情推动上会由管事的直接推动变成管人的间接推动。

管人有几个原则：

基本规则：右手棒子、左手甜枣。管人新手比较容易犯的错误有几个：
1. 觉得间接推动效率太低而直接介入，由管人降级为管事；
2. 太有管理意识，凡事使用棒子解决（强制必须做或不能做等），导致团队失去积极性；
3. 不好意思，凡事使用甜枣哄骗，导致团队没有甜枣的激励就不出活，甚至在某些关键甜枣承诺没有兑现后，失去了对团队的控制力。
正确的做法应该是右手棒子左手甜枣，打一棒子给个甜枣，这样既不会把团队管死，也保持了原则性。

换位原则：了解对方的需求层级，满足对方最在意的。管人者的最高境界是，所有人都觉得老板对自己特别好。企业的资源总是不够用的，这也是需要管理的最底层逻辑。所以在激励成员方面，能在一碗水端平的基础上，照顾好每个人最在意的点，非常不容易，也是值得每个管人者追求的目标。

招人原则：不为事，不引诱。为事招人，是新手比较容易犯的错误。招人的出发点不应该是团队里面有个具体的问题没人解决（否则这个问题解决了，人怎么安排？），而应该是因事设岗，因岗招人。只有岗位梳理清楚后招的人进而形成的团队，才是可以跑得更远的团队。另一个招人的点是不引诱，创业团队一开始都比较困难，如果生怕招不到人而重点利诱而不是强调公司的目标以及意义，那结果只能是，招到的人是冲着利诱来的，很显然这不是团队最希望得到的，能跟着团队一路跑下去的伙伴。

提拔原则：先证明能力再给名分。在意向提拔团队成员时，很多成员会要求先给名分再做事，否则会抹不开面子不好意思主动去承担更多责任。我对这个问题的理解是，组织协作关系只是实际协作关系的追认，而不是先行。如果没有给名分就放不开手脚，或者说一定要借助名分才能约束别人，那我的结论是，被提拔者的影响力还不够，应该给更多机会并协助他建立更强的影响力来进一步考察，而不是贸然提拔。正如上文提到的，不恰当的提拔会让团队和成员处于双输的局面，提拔没有退路。

以上内容纯属个人体会，欢迎留言和我交流 。如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

陈崇磐，德信随寓 CTO 兼 COO，TGO 鲲鹏会会员，多次从零开始搭建团队，有丰富的团队打造经验，曾在通信领域扎根 10 多年，先后就职于华为、摩托罗拉、诺西通信等公司。2013 年开始自主创业，并随后加入创业社交平台–微链担任 CTO，目前专注长租公寓领域。

第166讲 | 俞圆圆：合格CTO应该做好的5件事（上）

你好，我是 VPGAME 的 CTO 俞圆圆，感谢极客时间的约稿，让我聊聊 CTO 的素质与战略这个话题，因为是命题作文，所以在正文开始前还是需要说明一下：CTO 的素质和战略虽然有关联，但其实是两个不同的主题。做一个小小的类比吧：

两匹狼来到一个草原。
第一匹狼感到很沮丧，因为他没有看到肉。这是视力。
第二匹狼感到很兴奋，因为他知道有草就一定会有羊。这是视野。

素质当然会影响你的战略决策能力，就像视力会影响你的视野一样，但一名合格的 CTO 不能局限于必须看见了羊，才能判断出一定有肉吃。
以下想分 5 个点来和大家具体聊一聊：
1. 技术原点：At the end of the day, 你还是一个工程师
2. 技术方向：工程（Engineering）和技术（Technology），何者优先
3. 技术决策：通过“常识”来做判断，做正确的事
4. 技术外沿：项目做好了，但还有其他的事
5. 技术人才：CTO 是技术团队最重要的 HR

技术原点：你的原点应该还是一个工程师

CTO 这个角色容易进入 2 个误区：

认为管理能力的重要性要远重于技术能力。

认为管人 (people management) 的重要性要远重于管事 (project management)

有人总喜欢用军事指挥官的例子来做类比，声称好的将军不需要自己上前线冲锋陷阵。这样的类比中的逻辑漏洞稍微仔细思考一下就不难发现，但这里我想强调的是：诚然，出色的管理能力是 CTO/ 技术 VP/ 技术总监这样的领导岗位上必备的能力，但“学而优则仕”的逻辑不能僵化引申到技术职场上来变成“码而优则管”。不要盲目地鼓励或同意优秀的程序员转到管理岗，不然你可能收获一个三流的管理者而失去一个一流的工程师。

与此同时，我们不能轻视技术能力对于技术领导岗位的绝对必要性。我自己认识和了解的范围内，没有一家成功企业的 CTO 是一个管理学上的大师但却是技术上的弱鸡。我所认识的优秀的技术管理者几乎都是同时在技术专业领域持续不懈地坚持与时俱进的人。

反面的例子我倒是遇见过，几年前曾和某大型跨国电商公司的中国区技术高管一起吃饭，席间这位前辈一直在谈论他的管理艺术，并展示了一些他团队开发的被他称为“之前没见过吧”的厉害系统，我看了以后觉得这样一个企业内部的私有监控告警系统虽然复杂，但也未必就达到“没见过吧”的程度，毕竟那时公有云上类似系统已经是 10x 的规模了。这之后那家大型跨国电商公司在中国的业务节节败退，被很多本土的后起之秀（有阿里、京东也有后来的唯品会、拼多多等）抛离，而这位前辈也淡出了技术圈。

总之，CTO 绝对不能放下技术，而技术能力的养成没有什么捷径，只有不断学习与时俱进，才能不至于“不知有汉，何论魏晋”。

有人说我也想继续学习新技术，但实在没有时间，管理上的事务已经忙不过来了。我比较好奇的是，Jeff Dean 管理 Google Brain 3000 人的团队，每周尚有时间自己写代码，难道你管理的团队超过 3000 人了？

在《技术领导力 300 讲》专栏的文章里，我写的第一条居然不是什么宏大的管理理念，还是在唠叨敲代码，可能感觉有点怪异，但我确实是想说，在技术人员成长的这条道路上，不论我们去往哪里，我们都不应该忘记自己的原点。在我们承担起团队管理职责的同时，我们能否保持这样的自律：

每年学习一种新的编程语言

每年深入关注一个新的技术领域

技术方向：工程（Engineering）和技术（Technology），一体两面

虽然自己是 TGO 的会员，但该吐槽的还是要吐槽的：曾经参加过一个 TGO 的辩论活动，题目好像是“创业公司应该是业务驱动还是技术驱动”。这样的命题其实挺傻的，因为这本来就不是一个矛盾的问题。

对于技术团队来说，实现业务大体上就是指团队工程（Engineering）能力，但追求业务项目的落地实现和追求技术能力（Technology）的迭代演进，不应该成为两个互相矛盾的事。这两者本来就是互相促进螺旋上升的，比如，实现一个随机抽奖的功能是一个业务实现，实现一个最高可供 10w 人同时在线每 1 分钟进行一次随机抽奖的功能就有点挑战了，实现一个可以通过弹性扩容支持 0 到 10w 人同时在线，以“真. 随机数”(TRNG) 的安全级别每 1 分钟进行一次随机抽奖的功能则可能是大多数工程师都不会小觑的技术难题了。

同样的业务场景，在不同的性能要求下，对团队就会不断提出更高的技术要求。而另一方面，没有解决实际问题的技术方案，即使听起来很酷炫，它的价值也十分有限。比如说不久前还火的不行的区块链，2017/2018 年的时候，好多机构和组织都在招聘区块链专家、上马区块链项目、吹捧区块链技术，但时至今日，一地鸡毛，很少有人说得上来当时我们到底是要解决怎样的实际问题。

其实花点时间了解一下区块链底层技术就知道，blockchain 最开始的技术底层并没有发明太多的新内容，其核心还是由一系列经典的基础模块重新组成的算法逻辑，比如说哈希算法、非对称加密、分布式系统中的一些工作原理等等。也许在某一个时间会有适合区块链技术场景的实际问题出现，但显然不是 2017/2018 年那时候无脑狂欢的形式。

类似的问题在人工智能领域也出现过，这几年风头正劲的深度学习框架底层依赖的神经网络理论，在 21 世纪初的时候都还不算是人工智能学术界主要关注的领域，在人工智能的大学课程里，神经网络的内容往往是被匆匆带过。一直到了 21 世纪第一个十年后，随着能够支撑大型神经网络并行“学习 / 训练”（training）的算力基建逐渐成熟并生产化，神经网络理论才真正地被大量认可并采用，其核心原因还是因为这个技术终于能够解决我们的实际问题了。

总结一下：

1. 业务，或者说工程（Engineering），一点也不 low，在不同时空复杂度的要求下，它会不断演变出新的技术（Technology）挑战来。
2. 警惕过度追逐没有实际问题可解决的技术热点，对于团队中类似“一直在做业务，技术没有进步”这样的困惑能胸有成竹地回答。

最后还有一点有必要提一下：作为团队的技术领导者，要有能力识别一类问题，这类问题是需要技术预研先行的，我们不能等着产品需求提出来了才去做技术预研或储备，这样被倒逼往往会十分被动。在此举一个小例子：我们团队在 2017 年的时候了解过 Apache Flink，但当时只是作为流式计算框架的一种去调研的，并且最后也没有采用。但 2017 年下半年的时候，我们了解到有阿里巴巴的团队在致力于将“流处理”和“批处理”两种数据处理模式统一在 Flink 框架下（新产生的框架称为 Blink），当时虽然还没有业务场景需要使用到这样的技术框架，但我们感到在不久的将来很可能会出现这样的业务场景，因此我们一直密切关注相关的技术发展并积累一些实践经验。最近，我们也开始基于一个真实的业务场景落地 Blink 的使用。

有的时候，技术部门主管做出这样决策的时候是会受到很多挑战的，比如业务部门可能希望把研发力量更多地配置到急需实现的当前业务项目中去，比如财务部门可能会对这些前瞻性的投入提出投入产出比的质疑等等。面对这些挑战，技术领导者能否有审慎的判断和足够的自信去推进他所认为正确的工作，这是一个不小的挑战。如果说技术领导者需要具备什么战略眼光的话，这可能是其中一点吧。

感谢你的阅读，我们今天分享了 CTO 在“技术原点”、“技术方向”两个方面应该具备的素质和能力，下一期文章中，我们将继续聊聊 CTO 在“技术决策”，“技术外沿”，以及“技术人才”等几个方面的能力，下期再见。如果你觉得这篇文章对你有帮助的话，也欢迎将它分享给更多的朋友。

作者简介

俞圆圆，VPGame CTO，TGO 鲲鹏会会员，前 UCloud 基础云计算研发中心总监。曾经分别供职于 Microsoft Windows Azure 和 Amazon AWS EC2，历任研发工程师，高级研发主管，首席软件开发经理。经常深入第一线为客户提供技术支持，全面参与日常运维和现网问题排查，并组建和带领过实战能力极强的研发团队。在大规模、企业级分布式系统、面向服务架构、TCP/IP 协议栈、数据中心网络、云计算平台服务的研发和运维等方向积累了大量的实战经验。

第167讲 | 俞圆圆：合格CTO应该做好的5件事（下）

你好，我是 VPGAME 的 CTO 俞圆圆，今天继续和大家聊聊一个合格的 CTO 应该做好的 5 件事。在上一篇文章中，我们聊到了“技术原点”和“技术方向”两方面的内容，这一期，我们继续说说其他的 3 个方面：“技术决策”，“技术外沿”，和“技术人才”。

技术决策：依赖“常识”做判断，做正确的事

即使再勤奋努力，我们也不可能做到对每个技术领域都有足够的学习和了解，所以作为技术领导者，很重要的一个素质就是在没有充分了解一个领域的情况下，如何还能有效地帮助团队做出正确的判断。

这些年的创业热潮催生出很多有趣的现象，其中一种叫潮词金句新概念癖。讨论问题的时候，不提几句认知、降维、赋能、反脆弱，似乎都不好意思说自己是创业者。处于这样的环境中，一个团队以及它的核心成员很容易产生一种“时不我待”的焦虑感。新的概念我们需要去了解，但并不是所有的新兴概念都能真的带来价值的。作为团队的领导者，如何在高不确定性的环境下去有效地甄别和选择哪些是“正确的事”和“正确的方法”，是极其重要的工作。其结果不但会影响团队中短期的决策和方向，更可能会影响团队长期的文化氛围。

好的技术团队文化很难概括，但大多有些共性，比如讲究常识，说人话，重视逻辑，以及互相间尽可能平视的视角等等。同样，在面对知之不深的领域的时候，“常识”，也许是能够帮助我们做出正确判断的最有效的方法。

对于技术领导者来说，有哪些是可能要面对的知之不深的领域呢？
1. 技术面试的时候：你对候选人不了解，你也很可能对他擅长的技术背景不那么精通；
2. 技术选型的时候：流量、负载、容错性、可扩展性等等，都是未知但却必须考虑的因素；
3. 技术攻坚的时候：不同的技术团队遇到的不同领域的技术难题需要你去指导解决。

那有哪些“常识”能够协助我们做出判断呢？

1. 评估候选人的能力（比如责任心，抗压力，创造力），而不是知识

2. 做任何决策，先问问评估成败的核心指标是什么

3. 核心指标宜少不宜多

4. 指标要尽量可量化

5. 先抗住再优化，边重构边生活

6. 持续迭代，而不是过度设计

7. 化繁为简

8. 其他人听不懂的一定不是好的技术方案

9. 让懂的人和不懂的人都能坦然地表达自己的“有知”和“无知”

10. 有违价值观底线的方案坚决不采纳

11. 先统一思想，再约束行动
……

这些“常识”性的原则看起来也许比较抽象，但其实真正在日常工作中应用起来却并非如此，我们举个例子：大部分的技术团队都会有一定的绩效体系，不论是 KPI 也好，或是 OKR 也好。在此我们不讨论 KPI 好还是 OKR 好, 何为道，何为术等等抽象的问题。每个团队的实际情况不同，每个 leader 的个人风格不同，应该都会有自己的判断和选择。在这里我想说的是一点通用的“常识”，就是不论我们用的是何种绩效体系，如果我们评价的核心指标十分繁复的话，那这个体系所产出的结果很可能是不理想的。

如果一个员工将自己一个季度的绩效目标划分为 7-8 个小项来评估，每个小项占 10%-15% 的权重，那这就是一个强烈的信号，说明这个团队的管理或者这个员工的自我管理出现了不小的问题，具体存在以下这些可能性：

当一个员工的目标如此繁多而琐碎的时候，他的工作很可能是没有重点的。什么都想做好，往往是什么都做不好。

这个团队对于当前核心任务的拆分比较混乱，导致员工必须完成很多不同的工作才能达到团队的目标。员工可能疲于奔命，团队也可能顾此失彼。

团队负责人对于员工的帮助或指导可能是浮于表面的，作为一个领导者, 我们真的能同时对员工的 7-8 个不同的工作或能力做出有效的评估和指导么？我们是否真的了解了我们的小伙伴最迫切需要提高的核心能力是什么？

员工或团队对于以结果导向来证明自己的贡献和价值没有信心，而正是因为缺乏这样的信心，才抱着“这么多事，总能做好 3-4 件吧，这样至少有个交代”的心理，以很多细碎的小目标来掩饰心虚。

根据这个常识性原则，我们团队在制定季度和年度绩效目标的时候，一直是强行规定必须只能有小于等于 5 个分目标，有时在一个季度的时间范围内甚至会规定必须只能有小于等于 3 个甚至 2 个分目标。如果做不到，那说明我们对当前最需要解决的问题剖析的还不够深，我们对赖以生存的关键条件分解的还不够细，我们的精力和资源还不够聚焦。

技术外沿：项目之外，还有你需要关心的

作为团队的技术负责人，确保业务及时安全稳定的交付是我们的本分，追求技术有序高效深入的演进是我们的愿望，但除此之外，其实还有很多其他重要的工作需要我们的关注，在此试举一些：

1. 专利申请
2. 外部的技术影响力和技术形象
3. 内部的技术氛围
4. 企业基础 IT 建设
5. 成本管控（人力成本，运维成本等）

这些工作看似和项目交付、创造营收等没有直接的联系，但其实会在潜移默化中影响一个技术团队的长期产能，是我们责无旁贷要去关注的。并非每个企业，特别是初创企业，都配备了完整的职能部门帮助你完成上面的各类事项，所以很多时候需要技术负责人自己去主动补位、主动担当。比如专利申请需要法务或行政部门的配合，技术形象和技术影响力依赖外部技术渠道的运营可能需要市场或商务部门的配合，内部的技术氛围需要 HR 培训部门的配合，企业 IT 建设和成本管控需要采购或财务部门的配合，我们并无法保证所需要的资源和支持一定能够全部到位，但我们也不能坐而论道，等待客观条件都成熟了才去行动。对团队有利并且当前必须要做的事，有条件的就执行的坚决一些，没有条件的就创造条件去执行。

举个例子，VPGAME 是一家创业公司，和很多其他创业公司一样，我们在很多领域并没有完整建制的部门人力资源，比如当我们想将积累下来的一些技术沉淀回馈给技术社区的时候，却发现公司的市场商务部门并没有现存的技术渠道关系，也没有相关的技术市场建设的铺垫，甚至没有相关的市场人员有精力或经验来负责这部分工作的。所以最开始起步的时候，我就直接拉上 HR 招聘部门的同学一起来做技术市场推广和对外技术影响力建设的工作。

我和招聘部门的同学是这样解释的：也许这部分投入在短期内未必会看到回报，但从中长期来说，我坚信这些投入一定会给招聘工作带来反哺。我们想要找到那些优秀的志同道合的研发人才，不能单纯地依赖传统的招聘渠道，在我们寻找技术人才的同时，我们也希望技术人才能注意到我们，能了解到我们是一家以技术为核心驱动力的互联网创业公司，能知道我们对技术的尊重和积累，从而多多少少给他们心中留下一个 VPGAME 的印象，甚至有可能主动地和我们来联系。即使做一整年这样的工作就换来一个优秀研发人员的加入，我觉得都是值的。

事实上，我们也确实通过这样的坚持，收获了不止一个的优秀技术人员来加入我们的团队。

很多“技术外沿”的工作经常是没有短期直接回报的，但作为技术团队的领导者，我们应该有这个战略眼光，在合适的时间为了一些长期的价值坚持去做相应的投入。积一时之跬步，臻千里之遥程。

技术人才：你就是团队最重要的 HR 主官

作为技术领导者，你最重要的工作职责之一就是为团队培养和选拔人才。HR 关于人才体系的各个环节，不论是招聘，培训，还是绩效等等，我们千万不能认为“交给 HR 就好了嘛”。我们自己才是团队最重要的 HR 主管，人才选拔、培养、留存、汰换的各个环节，我们的参与和重视程度，会极大的影响最终的结果。让我们分几个阶段来简单地看一下：

1. 招聘阶段：从待招岗位的 JD 到面试前的准备，你都有充分了解和准备么？你团队里的新员工有多少是你亲自面试过的（不同的发展阶段会有不同的答案）？一场面试，你是不是等候选人到前台了才匆匆拿起 HR 给你的简历扫了几眼，然后就开始临场发挥了？你是不是一直在用同样一组问题在评估所有的候选人？面试后所有的面试官对于候选人有没有进行审慎的讨论合议？

2. 培训阶段：你的团队给员工提供了怎样的内部和外部的培训资源和渠道？是否有定期的培训计划，还是想到了就做做，忙了就再说呢？你自身是否做过什么表率性的工作来告诉团队持续学习的重要性？员工是否将学习提高作为他们工作的必要组成部分？员工之间是否有良好的技术分享和讨论的氛围？有多少员工是能够上台做一个出色的内部技术分享的？外部的技术分享呢？

3. 绩效阶段：在制定绩效目标前，我们是否对团队的职责进行了足够的拆分和明确？我们的团队是否足够精干简练，从而每个人的工作成效都能和结果成直接因果关系？一个团队如果有 5 个人对同一目标负责，是不是意味着如果目标不达成那这 5 个人的考核就全部是不合格的？拆分了职责之后，我们充分授权了么？

4. 汰换阶段：271 的原则要不要遵守？末尾或者后 10% 淘汰是不是必要的？绩效改进计划 (PIP) 的目的是什么，目的是单一的么？

我列出了很多问题但没有给出什么答案，因为这里很多内容展开的话自身就够写一篇文章的了，所以在这里我只是想说，如果这些问题和工作，你作为团队的技术负责人没有想过而是全部交由 HR 部门来处理的话，也许那并不是最好的安排。

感谢大家的阅读，希望这篇文章对你有一点小小的帮助，也欢迎把它分享给更多的朋友。

作者简介

俞圆圆，VPGame CTO，TGO 鲲鹏会会员，前 UCloud 基础云计算研发中心总监。曾经分别供职于 Microsoft Windows Azure 和 Amazon AWS EC2，历任研发工程师，高级研发主管，首席软件开发经理。经常深入第一线为客户提供技术支持，全面参与日常运维和现网问题排查，并组建和带领过实战能力极强的研发团队。在大规模、企业级分布式系统、面向服务架构、TCP/IP 协议栈、数据中心网络、云计算平台服务的研发和运维等方向积累了大量的实战经验。

第168讲 | 余加林：从技术人到创业合伙人必备的三个维度的改变

你好，我是八号空间 CEO 余加林，从事互联网行业 11 年，有 7 年开发经验、8 年管理经验、5 年创业经验，从一名码农到技术管理者再到创业者，相对来说是一个比较常规的发展路径，对我个人来说，节奏算是比较快的，以至于很多时候自己并不能很好的驾驭所在的岗位，因此踩了很多坑，也获得了很多的教训。

从纯粹做一个码农或是一位技术管理者到选择创业，这其中角色的转变是比较大的，今天，我把自己关于创业的一些经验进行粗略的总结，分享给你，不敢说特别有用，但希望可以给大家一些参考。当然不同的场景，不同的人，不同的公司都会有不同的情况，适合自己的，才是好的。

另外，我想声明一点，我不鼓励创业，至少绝大部分人并不适合创业，所以，请谨慎选择。
回到正题，我将从三个方面来分享认知创业这个话题，分别是思维的转变、团队的协同、成就感的获得，内容适合于参与创业的 CTO 或技术 VP、技术高管、产品高管等。

思维的转变

对于创业合伙人来说，思维上的转变是指要让自己的工作立场更彻底地站在公司角度，一切以公司利益为导向，不能只想着管好自己的一亩三分地，更不能以自己的利益为上。因为我们已经是一名创业合伙人了，需要尽力发挥我们作为合伙人的作用，无论在工作、效率还是决策等方面都应该看的更远，这对公司未来的发展至关重要。这可能就是大家所说的提升视野与格局。

1. 对公司的思考
当自己多了一些头衔，如合伙人、联合创始人等这些让人听起来就觉得公司跟自己大有关系的 title 时，我们对于公司的思考就需要转换一下角度了，我们需要考虑公司的战略、方向、财务、组织架构、人员情况等各方面的部分或全部，这些在以往的工作中感觉离我们很远，但当你作为一个创业者时，你不得不去面对这些，也许不需要你在这些方面做太多的决策，但你必须理解各部门的职能、作用以及协作关系等，在此基础上才可以有针对性地优化，提升效率、减少内耗，在我们有限的能力范围内尽量避免扯皮推诿的事情。

2. 对部门的思考
作为技术部门 leader 时，考虑的是人不够就加人，工资给的不够就加钱，还会为自己部门争取各种福利和补贴等，创业后在做决定时就需要特别慎重，需要综合考虑公司现阶段的情况，当部门有需要时，很多事情就该到你这层截止，而不应该再向上汇报，我们既要做好向下管理，也要做好向上管理。部门的开发计划需要围绕公司的战略和方向去适时调整，知道哪些重要哪些不重要，始终站在公司的角度去思考部门的工作。在公司不同的阶段，需要对团队做出适当的调整，以适应公司的前进或是倒退。

比如我们公司在两年前决定聚焦主营业务，将其它不相关业务全部砍掉，这时就涉及到人员裁撤等问题，我们既要考虑到公司的利益，也要考虑到员工的利益，还要顾及在职员工的看法和想法。这是一件吃力不讨好的事情，如果处理不好会背负很多骂名，因此很难办，但不得不做。作为合伙人，我们处理问题时必须果断，有魄力和决心，同时需要平衡好各方利益关系。

3. 对产品的思考
作为员工时，有产品开发任务就直接去做，可能不会去问产品背后的逻辑，或者也没有人告诉你产品背后的初衷和思考，参与创业后就完全不一样了，为什么做这个产品，怎么做这个产品，什么时候真正需要用这个产品，甚至连市场开拓、运营推广都要去了解，我们需要对产品的思考更加全面，更加合理的安排开发计划，产品开发的快与慢，好与丑，这些一定是在权衡之下才能出好结果。

4. 对利益的思考
这里的利益是指个人利益，参与创业，是获得股份 + 薪资还是获得期权 + 薪资，具体应该怎么分配其实并无法界定，我们需要明白自身的价值和在创业过程中担当的角色，以及想要参与的程度，以此衡量自己应该得到的利益。

有一点需要明确的是，该是自己的，一定要坚持争取，千万不要碍于面子最后不了了之，否则在未来的某一天，利益分配问题一定会让你头疼，参与创业，一定要想清楚自己的价值所在，这没有标准答案，也很难去量化，就是一个权衡的过程，如果心里那杆秤非常不平衡，那就争取让它尽可能地达到平衡，这是妥协，也是选择。

以我自己为例，早期我选择的是股份 + 少量生活费的方式参与了创业，当时也没有想太多，就是干，一定要干好，钱多钱少无所谓，只要未来能享受公司增长带来的红利就好，这在前些年全民创业的时代可能没啥问题，但在目前这种资本寒冬下就需要慎重，我们可能要付出比前几年更多的精力，更多的金钱，但这也使得我们更加的理性。我一直觉得创业是需要有一定的资金积累的，一是为了保证家庭未来一段时间的生活所需，二是为了保证公司在早期的一段时间内得到供血，如果做不到这两点，一定不要创业。

团队的协同

1. 对上的协同
技术人和技术创业者在对上协同中的区别是，以往对于领导安排的任务，我们基本上只要执行就可以，不需要有太多的想法，但技术创业者需要对所安排的工作有自己的独立思考。因为每个人看问题的角度不同、高度不同，所以看到的东西永远都是有局限的，我们要从公司角度，综合各部门的利益提出最优解决方案，并考虑方案的可行性，有一点提醒，如果最高级决策者一意孤行，那就直接配合他尽自己的能力做好执行就好，千万不要有“我是合伙人 / 联合创始人，我的意见你必须听”的想法。相信我，所有创业公司的 CEO 都是独裁的，如果不是，过一段时间这家公司可能就不存在了。有时候退亦是进。

2. 对下的协同
作为合伙人或者联合创始人，公司员工对你的看法是不一样的，因为你拥有一定的话语权及影响力，所以你需要有很正的价值观，这可以影响到员工对创始人和公司的认同感。同时，你还需要多了解员工的情况，帮助他们解决问题，提升员工幸福感。比如我经常会给员工一些小惊喜，再比如在一些特定的节日（如程序猿节）给员工送礼物、送祝福，等等，偶尔也会带大家去喝个酒，唱个歌，跟员工促膝长谈等，来加深了解。

每个人都有自己的调性，在自己的调性里做好人，做好事，要善良，要果断，要虚心。我们不要因为公司发展的不错或者融了一大笔钱就过度膨胀，这会让自己变得自大，甚至德不配位。

3. 对部门间的协同
作为创业者，我们不能只管自己的一片小天地了，各部门团队需要有配合，我们需要让部门间的协同效率更高，做到真正意义上的凡事有交代，件件有着落，事事有回音。而不是推责，不是内耗，如果各部门同事都能目标一致、齐头并进，那你公司的战斗力一定会提升百倍、千倍、万倍。在实践中，多参与项目，做到即时协调、沟通、跟进，就是我们要在团队中起到的积极作用。

成就感的获得

创业是件很苦逼的事情，在这过程中可能还没有钱拿，无法获得短期利益，而长期利益也可能遥遥无期，因此我们需要在精神上有所图，通过产品数据、他人认可及公司发展等来获得成就感。

对于产品，我们可以通过深入的思考，数据的分析，对公司的战略方向等提出建设性的意见，也可以用技术的手段去提升产品的数据，如用户数据、订单数据等。同时，我们需要通过技术解决用户的问题，解决各部门的问题，以此来提升公司的整体效率，获得他人的认可。我们要通过自己能力范围内的工作来帮助公司，向公司正向的输出，提升公司效率，这样，在公司发展越来越好的情况下，我们的成就感自然也会越来越多。

比如我们曾做过一个商品的智能推荐，做到了千人千面，经过一段时间的优化，推荐商品的点击率得到了极大的提高，下单的转化率在排除其它影响后也提升了 5%，而这就会让我们特别有成就感。

结语

从技术人到技术创业者，至少我们思考的宽度、深度都会有很大程度的提升，这对我们来说，不单单是一次成长，更是一次蜕变。而且，每家公司都会经历高峰期和低谷期，不要意外，总结经验，重装上阵，一切都会慢慢变好的，如果不好，一定要有自己的主见，去思考公司的方向是否有问题，如果认可则继续跟公司一起走下去，如果不认可也要有决断，不要互相耽误。

这是全民创业的时代给我的机会，让自己获得了更快成长的机会，因此，感谢这个时代。

文中内容仅供大家参考，欢迎留言探讨不同观点。如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

余加林，TGO 会员，八号空间 CEO，原 8 天联合创始人兼 CTO、副总裁，2013 年底加入八天一起创业，2018 年初负责 8 天内部孵化项目八号空间，并担任 CEO。从事互联网行业 11 年，拥有丰富的管理经验。

第169讲 | 高琦：如何给研发打绩效不头疼而又公正？（上）

你好，我是搜狐社交产品中心总经理高琦，今天想跟你分享的话题是，怎么给研发打绩效不头疼又公正？

每次到了绩效考核的那段时间，我都非常纠结，即使最终做完了决定，还是常常感到无法满意，偶尔收到一些新信息后又会对之前的决定感到懊悔，觉得自己没有考虑周全，做到足够公正。后来和很多技术领导者沟通后，发现大家都对此有相同的感受，越希望追求客观公平的人越纠结。

因为自己没有更好的解决方式，这个问题一直搁置着，每隔一段时间就再纠结一次，不断循环往复。后来团队的一个变化，突然使得打绩效的问题变得非常简单，意外的收获让我大为惊喜。这次就基于这个意外的收获谈谈给研发团队打绩效这个话题。

这个变化就是团队引入了敏捷开发流程。当时引入敏捷开发并不是为了解决绩效的问题，而是为了平衡研发速度和质量，解决产品需求变化多且经常插入迭代导致的项目周期不可控问题。但这里我们不谈敏捷，只谈绩效。

给研发打绩效是门艺术

给研发打绩效难，究其原因，研发本质上是一种有创造性的工作，程序员和艺术家有非常多相似的地方，相信很多人都读过《黑客与画家》这本经典之作，既然是创造和创新，那么衡量就是一件很难的事情。

我们团队在这方面进行了不同的尝试，而这次在研发过程中引入敏捷的方式 (我们团队使用的是 Scrum) 就是一个意外之喜。敏捷不是让打绩效突然变得简单且公正，而是让团队从开始就进行改变，最终使打绩效的过程变成一件自然而然、水到渠成的事情。

敏捷实践，敏捷的核心在于透明、透明、透明，重要的事情说三次，当然，敏捷作为一种项目管理方式，其特点还有迭代、拆分子任务、站立会等等，能带来诸多好处，但是这里我们不是讨论敏捷，不再赘述敏捷的优点，而是强调敏捷中的透明对打绩效的影响。

另外，需要强调的是，敏捷是一种项目管理方式，而不是一种工具，例如腾讯在推进的敏捷管理平台 TAPD，腾讯及其投资的很多企业都在使用，但是我和相关使用者深入探讨的时候，发现大部分团队并没有深入理解敏捷的本质，最终使这样的平台只起到了一部分敏捷的效果。其实，使用什么样的敏捷工具并不重要，比如我们团队反而更青睐白板、便签、笔和 excel。

敏捷过程中对后续绩效考核影响的关键点

之前提到，透明是敏捷给打绩效带来的非常正面的影响，而在具体的敏捷过程中，透明主要由两个方面来体现，分别是评选迭代之星和燃尽图。

1. 评选迭代之星

每次迭代小组在完成一个迭代之后，都会开迭代总结会，在这个会议里有一个最终的评选，那就是每人一票，选出自己认可的对这个迭代贡献最大的人作为迭代之星，不能选自己。由于这个过程完全是由参与其中的人，根据本次迭代中每个人选择的需求难度、完成度、质量、代码 review 时代码的漏洞、帮助团队其他人的情况等等综合考虑的结果，而且因为一次迭代之星没有什么跟金钱相关的实际意义，就是团队共同的肯定，这里大家没有什么顾虑，被选为迭代之星的人就较为客观。

依据我们实践的经验，优秀的人很容易在这个过程中浮现出来，并且得到大家的一致认可。而到年终进行绩效考核的时候，荣获迭代之星次数最多的员工得到最高的评价，对于团队里面的每个人来说都是完全可以接受的，而且这个过程是一种良性的竞争。

2. 燃尽图

在小组之间进行对比和评判的时候，燃尽图是非常重要的参考。通常，燃尽图是各个尝试敏捷的团队最容易选择简化掉的部分，因为大家开始并不能理解画一个图能有什么实际意义。

燃尽图 (见下图的示例) 是描述团队随着时间的推移而剩余的工作数量，可用于表示开发速度。不过在这里，我就不具体介绍燃尽图的画法和各种曲线展现出来的问题了。好的迭代小组，由于其拆分任务颗粒度合适，对任务难度评估准确，团队成员相互熟悉代码，燃尽图会趋近于一条直线。从燃尽图中我们可以看出各团队出现的问题。

先鼓起后落下：这是最常见的情况，原因是程序员对自己极度自信或者在做计划时漏掉了一些事情，造成初期进度缓慢，成员到最后通过疯狂加班使整个曲线快速落下，但这会导致最终项目质量低下。

一开始一切正常，然后突然停止燃烧：这是由于任务划分太粗糙，导致团队对工作量估计错误，到最后容易出现任务在余下时间内难以完成的情况。

先缓慢燃烧，然后到快燃尽的时候还剩下一堆没完成的任务，只能被推迟到下个迭代周期。

还有其他很多种情况，都能看出团队的不同问题。当然，绩效主要还是在各团队小组内部进行评比，每个小组通常会按照一定的比例分配 A/B/C，仅有一小部分需要几个团队来挣优质绩效的名额，而燃尽图就可以作为技术管理者评判团队的辅助手段。

为什么敏捷一直都是雷声大雨点小？

很重要的一个原因是，大部分团队在不了解敏捷核心的情况下，总是自以为是的进行简化，把非常关键的步骤精简掉了，导致最终敏捷流于形式，还浪费了时间，最后得出一个敏捷不靠谱的结论。

其次，敏捷教练也带来了一定的负面作用，由于国外的推崇，业界出现了专门的敏捷教练这个职业，比如我在第一次尝试敏捷的时候，公司就专门聘请了这样的教练来帮助我。然而，当时这个教练并不愿意参与到迭代内部，仅仅对流程和形式进行指导，让整个团队觉得这个人除了空有理论，百无一能，不久这个教练就被负面评价包围了，最后还影响了大家对敏捷的印象。

另外，部分团队成员会抵制敏捷，因为敏捷会使得所有工作变得透明，能力不足的成员会瞬间受到很大的压力，这种压力来自于团队整体。

最后，在实施敏捷的初期，相比于过去的管理方式，通常都是更费时间，而不是节省时间的。团队需要花时间适应这个变化，也需要做更多额外的工作，除了 coding，整个流程比之前多了迭代启动会、站立会议、随着任务状态的变化移动任务、最终的迭代总结会等，都需要花费额外的精力。从长期来看，敏捷会让迭代更快速，但在最开始的时候却是最容易被放弃的。

举个例子，我们的第一次实践最终也是以失败告终，上面四个问题都遇到了，但在第二次实践的时候，我们更加严格，并且在一次迭代中总结出的问题，第二次迭代时就能大为改善，极大的提高了团队对敏捷的评价，最终成功，给团队带来了巨大的变化。而作为团队的负责人，我也再没有因为给研发打绩效感到头疼，由于迭代中的表现每个人都有感知，绩效出来之后，大家都会比较信服。

或许实施敏捷对于团队来说是一个过程，但从我们团队的实践中可以看出，对打绩效帮助最大的其实在于团队整体透明度的提升，以及团队成员之间对彼此工作的了解，这使得相互之间的评价变得更客观。也许作为技术管理者你并不希望使用敏捷的方式，甚至不认为敏捷能极大的提升团队战斗力，但仍然可以尝试以下两个关键点：

使团队成员相互了解其他人的工作，而不是仅让一个人负责一个独立模块，每个人能够对其他人的工作提出意见；

在一定的迭代周期内，团队内部民主的选出大家认可的贡献最大的团队成员。

这两点是敏捷实践带给绩效考核最大的变化，这个变化是透明带来的，是团队认可的，是多维度的，也可以让技术领导者更加客观的看待自己团队中的每一位成员。

感谢你的收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

高琦，搜狐社交产品中心总经理，TGO 会员，2014 年加入搜狐，负责搜狐集团移动广告业务，负责搜狐移动端广告系统架构和性能优化，有效提升了业务指标，2017 年起，从零开始构建了搜狐资讯团队，产品在一年内日活突破百万。2018 年负责搜狐社交业务。

第170讲 | 高琦：如何给研发打绩效不头疼而又公正？（下）

你好，我是搜狐社交产品中心总经理高琦，上一篇文章中我跟大家聊了如何给研发打绩效的问题，我们团队在实践敏捷的过程中意外发现，敏捷带来团队整体透明度的提升，使得相互之间的评价变得更为客观，给绩效考核带来了非常正面的影响，让给研发打绩效变得更为简单、公正。

但不同公司对于研发团队的绩效考核都有不同的方式和标准，我们之前也尝试过不少其他方法，因此，本文想再谈谈一些其他绩效方式的实践以及我对这些方式的补充和探索。

1. 用数据说话，把研发的工作量化

有这样一种绩效流派是唯数据论，希望把一切工作量化，用数据来评判一切，这样就可以套用 KPI 的方式来进行考核。那么要想评价研发的绩效，自然会找出一些指标，而研发过程中是不会缺乏指标的，比如代码量、bug 数等等。

举个例子，曾经有个兄弟团队的 Leader 突发奇想，用代码量和 bug 数来进行绩效考核，最后变成了程序员和考核者斗智斗勇，激发出了各种奇思妙想。要代码量就加注释，考核加入了去掉注释的功能，程序员就引入大量废代码，考核又加入自动分析有用代码覆盖率的功能，程序员就把各种一行可以解决的问题，写成多行，很像古龙为了多拿稿费，非得写成“风”换行“冷风”换行“冷风吹”换行。古龙这种写法多少还有其特殊的艺术价值，而程序上一行换多行，没有任何价值。

这种博弈充分体现了互联网的迭代思维，而且迭代速度之快，让人目不暇接，脑洞大开。可笑的是最终这个想法被放弃并不是因为考核者觉得斗不过程序员了，而是由于产品经理崩溃了。

因为另一个指标是 bug 数，而程序员为了 bug 少，那就得保守，少做需求，原来一个需求 3 天可以完成，现在打死 5 天也完成不了了，项目进度突然变得异常缓慢。终于在产品经理的抗议声中，这个计划土崩瓦解。实际上这些程序员都是非常优秀的人，之所以有这样的反应是因为感觉人格受到了侮辱，被人怀疑总是想偷懒。

虽然这种尝试失败了，而且从根本上看这种方式就是错误的，但我认为数据在研发绩效考核中是可以发挥作用的，只是各种数据应该仅作为辅助参考，而不可以作为核心考核指标。一旦数据成为核心指标，必然会导致其中的参与者动作变形，人为做一些事情来干扰指标。而且，由于数据肯定会存在一定的偏差，即使作为参考也只适用于发现极端的情况，比如筛选出表现非常出色的员工和表现非常不理想的员工，如果用数据来衡量一般表现的员工之间的差别，会非常容易出现误差。

我曾经使用代码量、bug 数、bug reopen 数、接需求量、优化性能需求占比和加班时长这六象限雷达图来统计研发数据，如下图 所示 (数据做了归一化处理)。

图中列出的是两个差别较大的程序员，可以看出红色代表的程序员和蓝色代表的程序员相比，在代码量和 bug 数上都没有优势，在加班时长上明显要更少，但他实际完成需求量更多，bug 被 reopen 数也少很多，说明他的代码质量更好，勇于承担优化性能且较难的任务。

这张图其实是我在大家都不知情的情况下，偷偷用系统数据跑出来的，而且我也并没有用这样的数据进行绩效考核，但是这个数据仍然让我较为客观的发现了问题员工。例如这个蓝色的程序员，看起来非常辛苦，每日忙忙碌碌，如果每个人独立开发，不知道他人的工作，那么这样的人也有可能会得到一定的肯定。有句话叫没有功劳也有苦劳，功劳不容易比个高下，而苦劳却容易得多，然而这类研发者属于低效者，是团队战斗力不良的关键因素。

同时，由于不会将数据作为绩效考核的标准，那么即便大家知道我有时会抽数看这些数据，但真实改变这些维度的数值需要花费大量的精力，没有必要为了还不确定能影响结果的事情做太多事情，员工进行人为干预的动力就不足，最终得出的结论也就更能接近实际情况。

2.360 度环评

360 度环评在外企使用得比较多，初衷是想创造出一种相对公开透明的企业文化。优点是可以减小绩效只由直属领导主观评定导致的严重偏差。
360 度考察的信息来源包括：来自上级监督者的自上而下的反馈（上级），来自下属的自下而上的反馈（下属），来自平级同事的反馈（同事），来自企业内部支持部门和供应部门的反馈（支持者），来自公司内部和外部客户的反馈（服务对象），以及来自本人的反馈。

总体而言，这种方式确实可以将主观认知偏差，通过更加民主的方式进行有效抑制，最终的评价也更接近团队均衡的客观。应用于研发，就是自我评价、同组研发人员的评价、其他研发组人员的评价、直接下属评价、相关的产品人员评价、测试团队人员评价等等。

虽然看起来 360 度环评是一种非常好的绩效实践手段，但在执行的过程中，这种绩效考核方式最大的问题还是在于主观因素过多，且上级、下级、同部门、相关部门共同打分之后各自的权重不好界定。取一样的权重显然不合适，最终不同公司的权重选择仍然非常依赖规则的制定者，通常公司会给出一个统一的标准，但部门不同，实际情况也是千差万别，结果是最有发言权的人，未必有足够的权重。

但无论如何这种方式是利大于弊的，更需要反思的是为什么 360 度环评没有被国内的公司大量采用。我个人认为最大的困难在于各 leader 希望可以对自己的小团队有更好的控制，而且也并不愿意把自己置于这样环评的境地中，这需要公司整体自上而下进行推动，所以实施的关键在于顶层决策。

3. 对 OKR 的误解

很多公司都对 OKR 存在误解，他们推进 OKR，希望 OKR 能同时解决很多问题，包括绩效考核。从目标分解的角度看 OKR 和 KPI 是两种不同的方式，但从绩效考核的角度看，KPI 能和 360 度环评等概念并列，而 OKR 并不在其中，它并不解决绩效问题，所以在这里不多讨论 OKR，例如谷歌就是使用 OKR 作为目标管理框架，360 度环评作为绩效考核工具。

4. 靠技术领导者的个人感觉

这种绩效考核方式是大部分团队所采用的，有一定的合理性，在没有更优的办法出来之前，这种办法通常是较为合理的，宁肯用主观评价，也千万不要引入错误的量化指标。

这种方式的优点是，如果技术领导者能深入到各个团队，倾听各种意见和反馈，自己也能尽可能的把自己的好恶抛在一边，最终的结果就会相对公正和公平。但是弊端也非常明显。

首先深入了解每个人是非常耗费时间的，技术领导者还有很多重要的事情，而且团队越大，这种深入就会占用更多的时间，这是不现实的。但我会推荐小的团队负责人，应该尽可能的深入了解团队中每个成员的情况。

另外每个人都有很大的认知偏差，这是人性的弱点，没人能完全克服。很有可能的一种情况是，某个员工工作中的某件事情没有做好，就被领导打了个不靠谱的标签，后续一直受到严重的影响，甚至在一些情况下不得不选择辞职换个环境重新来。大家不妨仔细想想曾经自己的领导，哪些人是让你感觉伴君如伴虎的？那些让你有这种感觉的人，通常会更喜欢给人打标签，所以这样领导的下属通常就会谨小慎微，怕说错话，做错事。

这种类型的领导者也最容易看不到真实情况，因为他团队中的每个人都在尝试包装自己，给自己调整出一个比较好的人设。最后，那些聪明的、会包装自己的人会得到更多的机会，但整个团队实际上是受损的。对技术管理者而言，这样的结果尤为致命。

或许你会觉得自己不会成为这样的人，但这是人性的弱点，作为一个普通人，大家都会存在这样的问题，只是程度不一样而已。克服偏听是一种反人性的操作，就像对抗习惯，大多都无功而返一样。但只要有这样的意识，积极审视自己的决定，就会有更多调整的机会。

总结之前提到过的诸多绩效考核实践和方法，比较好的一种方式是让敏捷团队自己评价成员，技术领导者主要参考这个评价指标，再以各种数据进行辅助，识别出最优成员和表现不佳成员，同时要多深入团队防止自己的主观误判，最终让绩效结果更加公正透明，让人信服。

感谢你的收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

高琦，搜狐社交产品中心总经理，TGO 鲲鹏会会员，2014 年加入搜狐，负责搜狐集团移动广告业务，负责搜狐移动端广告系统架构和性能优化，有效提升了业务指标，2017 年起，从零开始构建了搜狐资讯团队，产品在一年内日活突破百万。2018 年负责搜狐社交业务。

第171讲 | 邱良军：如何有效地找到你心仪的人才

你好，我是极智嘉研发总监邱良军，在互联网行业工作已有 18 年，前 10 年做软件开发，后 8 年做管理工作，包括研发管理、项目管理、运营管理，期间有过几次组建技术团队的经历，今天主要跟大家分享自己在组建团队方面找人的经验与思考，希望你听后有所收获，也欢迎与我共同探讨。

找人是创业起步、公司发展最重要的事情之一，阿里巴巴 CEO 张勇每年问自己两个问题，其中第一个问题就是“今年为企业找了几个人？”可见人才对公司的重要性。在我们准备找人之前，首先得想想我们需要找什么样的人才，以及什么样的人能叫“人才”或者能成为“人才”！一旦找错人或看错人所需付出的代价极高，他直接决定着搭建一个团队的成败。

技术人才定义

在判断人才之前，我们先来定义人的能力，人们在工作中通常需要具备的能力与素质有以下四类：

第一类专业能力，具备专业能力的人通常是某领域的专家，是企业发展中不可或缺的一部分，比如技术领域的软件工程师有系统架构师、Java 工程师、C# 工程师、DBA、前端工程师、全栈工程师等。再比如非技术领域有英语翻译员、仓储业产品经理、信贷需求分析师、健康险需求分析师、法律合规员、专利专员等。

第二类管理能力，帮助协调管理项目，确保项目能够顺利完成。也可以称为指挥团队的能力，一般达到一定规模的项目会配有专人做管理工作，具体职位有项目助理、项目经理、高级项目经理、项目总监等。

第三类是软技能，包括持续学习能力、沟通能力、领导力、洞察力、认知能力以及各种思维能力（结构化思维、逆向思维、深度思考、换位思考…）。

第四类是个人品质，包括个人诚信、工作态度、执行能力、抗压能力等，我认为现在常说的延迟回报心态、同理心、个人信念也属于这块。

最后，作为技术专才，或技术型管理人才，身上应该有一种气质：极客精神，Cool，自信，还有一点点的叛逆……

在创业期和团队组建初期，我们往往只需要专业能力较强的人，先“把事情做对”。随着业务的发展，企业的壮大，再慢慢通过管理能力来让每个人“做对的事情”。随着我们事业的继续扩展，企业向集团化发展，就需要有更强能力的人来把握未来，“为未来做事”。

现在来具体给我们心目中的人才画画像，并结合实际情况想想什么样的人是我们要找的人才。首先，在团队组建初期需要找专业性人才，简称专才。“专业的事情由专业的人做”，找人时我们需要关注以下基本点：

1.学历背景，虽然学历不等同于能力，但是为了降低试错风险和提高选人效率，需要设置必要的门槛，对于技术人才的选择来说，本科是基本的要求之一。
2.逻辑思维，在我参加过的数百次的面试中，几乎有 50% 的人沟通起来比较吃力，原因有思维混乱的、有理解沟通力差的、有表达能力弱的、还有少数人不懂装懂，甚至对完全不懂的概念乱说，等等问题可以总结为“答非所问和沟通效率低"。我在面试中会比较看重候选人的逻辑思维能力，包括逻辑的条理性、逻辑闭环等。
3.学习动力或习惯，技术发展日新月异，特别是软件技术人员需要持续不断地学习，我们需要观察候选人才是否还保持好奇心，会主动学习新技术。
4.良好的世界观，思考问题不偏激，不能想一出是一出，具体表现为不频繁跳槽，具备一定的抗压能力；
5. 之前提到过的基本要求，专业技能需要符合岗位要求，例如专业技术能力、英文能力、行业知识等。

若面试者在以上几个方面都能达到要求，就可以将他定义为人才了，短期能够帮助公司把需要的产品做出来，长期则可以和公司一起成长发展。

如果公司发展快速，团队很快到达了一定的规模，开始出现管理瓶颈，就必须及时补充管理类人才。最好的方法还是内部培养提拔，因为管理类岗位对于人品及忠诚度要求比较高，并且试错成本也很高。

技术管理类人才画像

那么技术管理类人才的基本特征有哪些？我将它分三类来看，第一类我定义为基层管理人才，管人也管事，通常是项目经理类，需要具备的能力有：
1. 前面提到的专才所具备的 5 个方面的要求需要全部满足，其中专业技能可以放低，重点是对技术宽度和发展趋势的理解；
2. 诚实守信非常重要，是人品的必要条件，为人要可靠、做事要靠谱；
3. 沟通协调能力强，总能积极主动地沟通，不轻易放弃；
4. 有带团队和项目管理方面的实际经验，了解或熟悉项目管理的理论知识；
5. 对未来保持乐观，做事富有激情，能够有延迟满足感，而不急于求回报。

如果公司起步就要组建一支较大的团队，规模在 20 人以上，则需要直接找具备以上 5 点能力的负责人。

而当起步就要搭建 50 人以上的大团队时，就需要找具有领导力的人才，他们通常需要具备以下几点特质：
1. 需要满足基层管理人才的 5 个要求，技术细节可以继续忽略，但要有技术感知能力，能更好的理解技术趋势；
2. 具有坚定的信念，做事有很强的原则性，富有使命感、责任感、荣誉感；（瑞·达利欧写了一本书《原则》，讲述了生活做事的原则，说的非常好。最近几年我都是独立带部门和发展业务，感觉很多处事方式都接近《原则》这本书中所写的。）
3. 熟悉公司运作管理的基本规则，对自己的责任范围不设限，使命必达，对团队负责，对公司负责；
4. 不甘于平庸，具有强烈的工作成就感，极强的沟通力；
5. 富有领导力，有激情有感染力，通过内驱来领导团队成长，能凝聚团队的力量。

如果继续往上要求，寻找技术合伙人、技术 VP 或 CTO，则需要这样的人：创业型或高端型人才，他们具备以下几点特质：
1. 需要基本符合领导力人才的 5 个要求。
2. 具有创业精神，必须要有自我牺牲精神，当然这里指是利益上的牺牲。
3. 能给公司带来资源，包括稀缺技术、专利、市场客户、行业内的影响力及人脉资源等。
4. 认同公司及团队价值观，不是一家人不入一家门，对未来有必胜信念。
5. 对公司所处行业未来的趋势有很强的洞察和把握能力。

理想是美好的，但是实际情况是十全十美的人才很难找到，或者说这样的人在市场上原本就很稀奇。如果找不到完美的人才，又或者对人才的能力评估还看不准，也没有关系。可以按照自己团队的特点先用人，而后再重用之。做事的前提是找人，雷军投资不看项目只看人，找准能力强并靠谱的人来做事是企业发展最重要的事情。

感谢收听，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

邱良军，TGO 鲲鹏会会员，极智嘉研发总监，负责组建极智嘉苏州研发团队，以及筹建苏州研发中心， 4 个月将团队发展到 40 人，并承接两个系统开发，数条支持线的工作。曾在新电任职超 10 年，带领团队交付数个项目，团队峰值人员超 70 人。2014 在文思海辉担任总监，从零开始将团队带至 300 人。18 年 IT 老兵，管理经验丰富。

第172讲 | 于人：研发团队人均产能3年提升3.6倍的秘诀（上）

你好，我是随行付 CTO 于人，目前，随行付技术团队约 400 人。随行付的发展速度十分之快，曾经在 2 年时间内实现了支付宝 7 年的规模增长，如此迅猛的发展速度，给技术团队带来了巨大的压力：CPU 动辄飙升至 80% 以上，技术人员 24 小时打地铺加班，需求积压严重，技术高管忍受不住压力离职……

最终，随行付走出了困境，从 2016 年 1 月至 2018 年 12 月，3 年时间内团队人均产能提升至 360%。一方面，随行付进行了技术升级，采用了微服务架构；另一方面，随行付在技术管理上也进行了行之有效的调整，今天我就和大家分享一下管理方面的经验。

随行付的技术管理实践可以用 12 个字概括，就是“定战略、抓战术、搭班子、带队伍”。

如图所示，定战略、抓战术偏理性，搭班子、带队伍偏人文。因为技术管理者作为科技和管理的结合体，是理性和人文的最佳实践者。理性做事，人文育人。

而从做事的角度上讲，定战略表示决策，抓战术表示执行。用一个公式说明：结果 = 决策✖执行。同样从人文的角度上讲，搭班子和带队伍，同样也对应了决策与执行。

遵循上述逻辑，随行付的技术管理框架划分为四象限，分别是定战略、抓战术、搭班子、带队伍。接下来，我就逐一与你分享这几年的实践感悟。

定战略，以定位破局红海竞舟

定战略的“定”，是指定位。做为团队领导者，最重要的是给团队做好定位，那如何确定团队有所为、有所不为呢？我总结了 3 个“定”：定范围、定赛道、定路径。

1. 定范围，用户所需 & 企业所长，缺一不可

如图所示，首先，我们需要圈定团队可选的战略方向。明确用户需求与团队擅长的，然后选取重合部分作为战略方向。

如果只关注用户需要，忽视团队长板，则无法建立竞争壁垒，发展过程中容易被竞争对手摧毁；如果只关注团队长板，忽视用户需求，就是自嗨，无法赢得市场认可。而既符合用户需要，又是企业擅长的，便可以作为备选战略方向。

以随行付技术团队为例：假如将业务部门看作我们的用户，可供我们选择的战略范围涵盖：交付速度、开发效率、业务前瞻性、质量、开发成本、运维成本、扩展性、安全性等等。

2. 定赛道，争做细分领域第一

孙正义说过，无论你所在的行业有多小，只要你能做到第一，你就会被人需要。
如图所示，我们需要选择一个未来空间足够大，同时有信心争夺第一的领域作为战略方向。

市场经济下，往往会形成这样的稳定格局，第 1 名占领超过 70% 的份额，第 2 名占据 20% 的份额，而 3-10 名的份额加起来都小于 10%。就比如 2018 年国内公有云市场份额就是阿里 72%，腾讯 21%，只留下 7% 给华为、百度等其他云厂商争夺。

基于这个现象，我们选择战略的时候，就要以做第一为目标。假如行业里已经有巨头存在，没有机会争第一，怎么办？

答案是进行品类细分。以随行付孵化的创新项目——Iron Cloud 微服务私有云开发平台举例，我们用了 4 个限定词来细分赛道，即微服务、私有、云和开发。顺应发展趋势，首先我们选择云原生，放弃物理机；其次，因为数据安全性，我们选择私有云，放弃公有云；再次，因为更擅长高速交付，我们选择开发环节，放弃运维环节；最后，因为实践经验丰富，我们选择微服务，放弃其他架构。

我们判断，云赛道足够大，微服务未来的市场空间也足够大，所以 Iron Cloud 选择了微服务私有云开发平台作为细分赛道，这 4 个限定词再加上有所为、有所不为，才有机会成为细分领域第一。。

在这里说一句题外话，关于定赛道，特劳特写的《定位》一书，可以帮助技术管理者更好的理解细分赛道。

回归主题，随行付技术团队最终选择的战略目标是“线下收单行业交付速度第一”。

3. 定路径，不可实施皆为妄谈
我们经常说，没有可实施路径的战略，就是耍流氓。

很多技术管理者，特别是高管，容易犯一个毛病：战略蓝图规划的很好很强大，落地失败了就说下面人不给力。更有甚者，当下属不知道如何做，向他请教时，这哥们来一句：“我如果会做要你干什么？”

各位技术管理者，切记，定路径是定战略的一部分，不能推给执行阶段。

为了达成收单行业交付速度第一的战略目标，我们每半年会确定一个阶段性技术目标，采用 OKR 的方式分解到各个团队中，各自努力达成，就这样一步一步达成战略目标。

截止 2018 年底，我们可以做到 85% 的任务一周内上线，附带着人均产能较 2015 年提升到了 3.6 倍，预计到 2019 年底，将提升至 5 倍。

好了，定战略，就分享到这里。

抓战术，以后果严重度区分大事小情

抓战术这个层面，我总结了 3 个词：抓大、放小、管细。

1. 抓大，大事抓过程
同一时间，只有一件事情是最需要关注的，需要占用你 70% 的精力来对待。推荐一本书：《最重要的事只有一件》，对于这件最重要的事，一定要扎到过程里，管理每个里程碑，持续跟进，及早发现问题，避免风险。

2. 放小，小事要放权
放小的“放”，讲的是放权。尽量把事情边界划分清楚，遵循责、权、利统一的原则，交给团队成员，领导者只需要定期获取阶段性成果反馈，尽量少插手过程。

至于如何划分大小事是这个层面的关隘，我的判断依据不是工作量、也不是复杂度，而是基于“对失败后果的承受能力”来衡量。

3. 管细，万事可测量
管细，不是指事无巨细，而是制定合理、贴切、细致的测量标准。对不确定性时代下的非 KPI 型团队来说，测量是很重要的管理手段，当然只统计，不考核。目前，随行付的技术团队已经做到数字化管理，利用大数据手段，统计各项目组日常工作情况，每周进行横向排名。不需要 KPI，因为测量和排名本身就是一个很好的激励手段。在此需要提醒一点，数据统计和排名，建议只针对团队，不要精确到每个人。

受限于篇幅，今天只分享定战略和抓战术两方面的心得体会，搭班子和带队伍将在下一篇文章与你分享，欢迎持续关注！

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

于人，随行付 CTO，黑少微服务商店创始人，Iron Cloud 微服务开发平台创始人，专注于金融科技领域。拥有 9 年分布式金融系统实践经验，5 年支付系统演进经验。对微服务架构有独到见解，对微服务发展趋势有前瞻性理解。管理经验全面，擅长通过分工、聚焦与放权，系统性提升组织效能。

第173讲 | 于人：研发团队人均产能3年提升3.6倍的秘诀（下）

你好，我是随行付 CTO 于人，随行付的技术管理实践可以用 12 个字概括，就是“定战略、抓战术、搭班子、带队伍”。在上一篇文章中，我分享了定战略和抓战术两方面的心得，今天我将继续分享我们团队在搭班子和带队伍方面的实践，希望你听完后能有所收获。

搭班子，正视二八定律、顺应人性

搭班子，我也总结了 3 个词：选人材、选阵型、搭团队。

1. 选人材：正视二八定律，能者重用

如图所示，团队成员可以从业绩强弱、价值观强弱等维度出发，划分成千里马、小白兔、狐狸、野狗、老黄牛等不同的类型。领导者一定想清楚，团队由什么样的成员构成。

领导者要把 80% 的精力用在业绩强、价值观也强的“千里马”身上；把价值观强但业绩弱的“小白兔”放在合适的岗位上，尤其注意不能放在管理位置上；找业绩强但价值观弱的“野狗”深谈一次，争取将其转化为千里马，假如无果，果断放弃；尽早识别业绩和价值观双弱的“狐狸”，并把他干掉；最后，对待价值观和业绩都处于中流水准的“老黄牛”，要利用公平、公正的制度，保证他们多劳多得，引导他们自己成长为“千里马”。

很多领导者容易犯一个错误，喜欢在“小白兔”身上投入大量的管理精力，期待小白兔的业绩发生质变。其实软件开发行业很看重天赋，天赋能保证生产力的量级。价值观强而业绩弱，只能说明能力已经触达其天花板，而能力上限的问题很难靠管理就轻易解决。因此，让“小白兔”承担其无法胜任的工作，领导者可能是好心办了坏事，“小白兔”处理起工作来也可能事倍功半。

所以我的建议是，领导者要把 80% 的精力用在“千里马”身上。如果对客观存在的事实有不切实际的期待，可能会导致管理手段畸形，浪费大量机会。

2. 选阵型：复合结构灵活运用
合理的组织结构，能够更好发挥成员间的配合能力，非常考验领导者组织结构设计的智慧。

举个例子，如下图所示，目前随行付有四种组织结构，分别是：研发组、项目组、专家组和兴趣组。

研发组是由需求、开发、测试人员组成的面向业务线的敏捷团队，目标是高速交付。研发组的协作方式是 KanBan（看板）。顺便说一句，我们随行付使用的是物理看版，大家一致觉得围着白板开站立会，更加有团队的感觉。

项目组是遇到紧急重要的任务时，从各团队抽调人手，集中攻坚的工作方式。因为涉及人员调动，对日常工作有一定影响，所以需要自上而下审批。不过一旦项目成立，就要千方百计达成目标。目前随行付的项目评价，已经可以完全做到系统化，能利用数据数据建模，客观评价项目组业绩。

专家组是由各领域专家组成，针对重要主题，进行专业性讨论的组织。比如技术专家组、设计专家组、风控委员会等，专家组同时肩负研发团队职级评审的责任，共同决策员工职级晋升。

重点提一句，专家组有否决权、建议权，但是没有决策权。我们的管理原则，每一件事都有且仅有唯一主责人，负责决策和承担责任。主责人可以委托专家组决策，但是最终成败，皆由主责人一力承担。

兴趣组是随行付技术团队的一种民间组织，只需要备案即可成立。组员利用业余时间一起研究新技术、学习新知识，例如：自动化测试兴趣组、敏捷开发活动组等。

通过多种组织结构的灵活运用，随行付可以应对日常工作中的各种场景。研发组确保了常规工作的自动运转，项目组攻坚紧急任务，专家组调动集体智慧并且彰显公平，兴趣组赋能团队成长。

3. 搭团队：取长补短发挥“木桶效应”
选出了人材，也选好了阵型，最后要做的就是人材与阵型的匹配。我们需要智慧地搭建团队，“搭”体现在团队能力最大化，如果我们把长板搭在一起，团队成为木桶；把短板搭在一起，团队则变成木盆。因此我们要识人，更要善用人。

搭团队，要注重补短板；而用人，恰恰要取长板，一定不能反着来。有的管理者，错误的把补短板用在了下属个人成长上，这是极其错误的，因为我在这方面就有血的教训。正是因为尝试让下属补短板，我手下两员大将一死一伤，其中一位最终选择离职，另外一位也消沉了很久，花了很长时间才重拾信心。所以我认为搭团队的艺术就体现在取长补短、实现共赢。

你一定知道，木桶的水位取决于最短的那块板，而交付速度，取决于流程中最慢的环节。这里推荐一本管理学小说《目标》，我们技术管理者，天天和性能作斗争，书中的 TOC 瓶颈理论一定能引起你的共鸣。

带队伍，试错文化推动快速成长

带队伍，也有 3 个总结词：带着做，带着说，带着想。

1. 带着做，带着团队在实践中进步
随行付是一个重实践的团队，非常注重给员工提供一种在实践中进步的机会。我们提倡因材施用，为不同能力、不同意愿的员工，设计适合他的任务，并且采用差异化的管理手段辅助他完成任务，实现成长。

如图所示，针对一项任务，如果判断员工意愿够，但能力不够，领导者可以传授具体的工作细节，要求员工执行，主要磨练他的动手能力。这种管理方式，我们称之为指令型管理，通常对新员工可以采用这种手段。

如果某项任务，我们判断员工完全可以胜任，但是员工信心不足，这个时候我们会采用支持型管理，给予员工鼓励与支持，提升他的意愿。

如果不幸，员工进入了能力、意愿都弱的状态，我们会精心设计任务，由易到难，一点点教会员工，并帮助他重拾信心，也就是采用教练型管理。

最后，如果某一项任务，员工轻车熟路，信心爆棚，我们会采用完全授权型管理，留给员工自主试错的成长空间。

说到试错，我和你分享一个亲身经历：2015 年初，我们新系统上线，阴差阳错下，系统报了一个 Native 异常，没有被捕获住，造成了 1500 多万的潜在损失。当时，作为研发团队主负责人的我，以为当天就会背包走人，可是公司并没有第一时间追责，只是叮嘱我尽快组织大家解决问题，争取降低损失。经过不懈努力，我们虽然化解了大部分风险，但是依然造成不小的损失。一天天过去，事情逐渐平息，我天天等着领导找我“秋后算账”，可处罚迟迟没有降临。最后我实在受不了这种煎熬，主动跑去问当时的上级，即公司的联合创始人，我说出了这么大的事，公司打算怎么处理我？我得到了影响我一生的回答。他说：“公司花了这么大成本，让你学到了经验教训。让你离职，公司岂不白损失了？”

这就是随行付的试错文化，这或许就是我们快速增长的动力来源之一。从这件事起，我暗下决心，一定要通过未来贡献，把欠公司的这份损失赚回来。我也把公司的试错文化传承了下来，大胆让兄弟们去试，去闯。

另外，指令型、支持型、教练型和完全授权型四种管理方式，需要与员工的胜任力匹配，一定不可错位。如果员工能力不足，你却拼命打气，用提升意愿的方式支持他，他大概率会被你坑杀。而如果员工能力、意愿都完全胜任，领导者却手伸太长，不给空间，就是在逼下属离职。

人是活的，是可以在实践中成长的；任务也是活的，是可以拆分的。给每位员工设计合适的任务，让员工通过完成一个个任务而成长，就是领导者的艺术。

带着说，注重方法论的沉淀与分享

如图所示，领导者带领员工成长一般会经历 4 个阶段，首先是“我做你看”，领导者给员工示范；其次是“你做我看”，员工实践，领导者从旁指导；再次是“我说你听”，领导者总结理论传授给员工；最后是“你说我听”，员工总结自己的方法论并分享给团队，形成团队沉淀。

员工成长 70% 来自“工作中学习”，20% 来自“向他人学习”，10% 来自“正式培训”。
领导者应该培养团队的分享文化，有句瑞士谚语说得好，“火炬会互相点燃”，我们要让知识之火传遍整个团队。

在这方面，随行付通过内部的“百人讲坛”给大家创造了良好的分享环境，并且为了鼓励分享，我们把技术影响力作为员工职级晋升的重要条件。

3. 带着想，以团队自我进化为目标
带队伍的最高境界，是让团队自管理，实现团队自我进化。关键 Key 是由人治变为法治，领导者要学会限制自己的权利，学会放手。

当制度建立起来，团队就可以“自动化”运转；如果把制度修订权也交给团队，那么管理就实现了“智能化”。再推荐一本书《重新定义管理：合弄制改变世界》，虽然这本书翻译版的质量较差，诸多用词不当，但瑕不掩瑜，掩盖不了其理念的先进，有迷惑之处欢迎找我探讨。

目前随行付正在努力践行“自管理”，流程设定已经完全实现 PDCA 的自管理闭环。

总结

结束前，我们一起回顾一下。

随行付的技术管理实践，分为四象限，分别是定战略、抓战术、搭班子、带队伍。

定战略，包含 3 个步骤：定范围、定赛道、定路径。

抓战术，可以用 3 个词概括：抓大、放小、管细。

搭班子，也是 3 个步骤：选人材、选阵型、搭团队。

带队伍，包含 3 个“带”：带着做、带着说、带着想。

以上就是随行付技术团队这几年的管理实践，这些管理实践结合微服务实践就是随行付人效 3 年提升 3.6 倍的秘诀，希望对你有帮助。

最后，再跟你分享四句话，分别是“先胜而后求战，格物而后致知；上下同欲者胜，己欲达而达人”，这是我从孙子兵法和论语里摘录出来的，常读常新，希望也能给你带来灵感。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

于人，随行付 CTO，黑少微服务商店创始人，Iron Cloud 微服务开发平台创始人，专注于金融科技领域。拥有 9 年分布式金融系统实践经验，5 年支付系统演进经验。对微服务架构有独到见解，对微服务发展趋势有前瞻性理解。管理经验全面，擅长通过分工、聚焦与放权，系统性提升组织效能。

第174讲 | 邱良军：打造高效技术团队，你准备好了吗！

你好，我是极智嘉研发总监邱良军，是个有 18 年工作经验的 IT 老兵，做了近 10 年软件开发，俗称码农；而后从事 IT 管理工作超过 8 年，包括研发管理、项目管理、运营管理。接到极客时间的约稿后，试着介绍分享一下自己在打造技术团队方面的经验。这是一个比较大的话题，详细说起来可以写一本书，在此主要结合我的实际工作及所学理论分享一下。

写在前面

在 18 年的职业生涯中，我从一名专注技术的码农，到研发经理，再到研发总监，中间踩了无数的坑，体验了从技术到管理的各种艰辛历程，也不断学习各种理论慢慢悟出了很多道理。我的成长阶段大体上分为三个阶段：

学习各种技术技能自己做事；

带领团队做事；

找人、组建团队、用好每个成员做事。

如下图所示，我提取了成长过程中的几个数据指标，一类数据是管理的团队人数变化，一类是技术、管理、认知能力的变化（自我打分），绘制成了个人的成长曲线图。

技术团队打造前的准备

在准备打造一支技术团队前，先看看自己当前的现状如何？ 你是从零开始组建一支技术团队，还是改进现有的技术团队。不同场景、不同条件、不同现状、不同阶段所使用的方法都有差别，没有一套放之四海皆准的方法，我们应该根据具体情况作出具体应对。下面我列出六个技术团队的种类，你可以对比一下自己的具体情况。

首先，需要思考一下：要打造什么样的技术团队？
1. 临时性研发型团队：临时承接系统研发任务，项目结束后团队解散；
2. 外包研发型团队：承接软件外包项目，或按工时付费的软件外包项目等；
3. 离岸外包研发型团队：承接国外或者异地转移的部分软件外包系统开发；
4. 业务研发型团队（2B 业务）：给自己公司业务发展做产品系统方案，自研自用，迭代开发完善产品，支持业务的发展，扩大抢占市场 ;
5. 产品研发型团队（2C 或小 B 业务）：做行业产品的系统解决方案，一般有行业 SAAS 平台开发，行业软件系统开发，比如餐饮系统、信贷系统、呼叫中心系统等等；
6. 技术研发型团队：做技术基础软件研发，比如 PAAS 平台，中间件、数据库、报表类等工具产品。

其次，是从零开始还是改造现有的技术团队，改造技术团队需要分析是处在以下哪种情况：
1. 改造自己组建的团队，让它提供更专业的服务，支持业务更好的发展；
2. 由于职位调动，空降并接管一个技术团队，更进一步发展团队；
3. 作为救火队员空降到一个问题团队，需要你稳定团队，并把它打造成有技术范的团队；

在确定了团队目标和当前状态后，根据实际情况去搭建团队，需要思考的关键点有：
1. 团队定位：项目驱动型、业务驱动型、 技术驱动型.
2. 薪资预算：公司所能提供的薪资在行业内的水平分析
3. 公司声誉：公司在业内的排名，是否是新兴行业
4. 行业要求：除了技术以外，人才是否需要特定的行业背景，比如英文能力要求
5. 人才市场特点：当地人才市场的分布，人才聚集的公司及地点
6. 时间要求：团队组建的时间要求和时机情况
7. 团队负责人：个人背景及魅力，行业影响，管理能力，领导力等
8. 核心团队：核心团队如何获得
9. 领导授权：放权是否足够，是否有充分的权力做决策

如上图所示，我们再来看一下不同定位类型的团队分别具有哪些主要特点，搭建相应的团队时要做怎样的规划。

如果是项目驱动型的团队，它的主要特点有：

以软件外包为主，项目具有一次性，做完后会换其他项目做；短的项目几个月，长的项目会有 1 年，甚至几年时间。

对于这样的团队来说，流程、项目管理非常重要，要确保项目按时交付，具有明显的成本、进度、范围的控制。

项目一般来自于“业务型”团队来不及做的系统，或没有自己开发团队的公司需要做项目发包，比如大系统改造、重构、新系统开发等。

项目驱动型团队对技术的要求处在一个相对比较低的等级。

此时团队规划中应该有需求分析员 BA、项目经理、开发组长 / 开发团队、测试团队等，如果是大项目的话，还需要有架构师。

如果是业务驱动型的团队，它的主要特点有：

为业务发展做支撑，开发迭代速度比较快，多数互联网企业属于这个类型。

系统设计要有产品化思路，能支撑业务的增长，当前投入是为了未来获得回报，能讲故事获得融资。

团队对技术的要求会有所提升，技术对业务的支撑要有一定的前瞻性。

这时团队规划中应该有产品经理、开发组长 / 开发团队、测试团队、运维支持、架构师等。

如果是技术驱动型的团队，它的主要特点有：

一般这类团队是指大型软件公司的架构组、基础组件团队，比如阿里、百度等；或者开发工具的软件公司，比如金山、360、TiDB 等。

软件的复用性最高，能解决普遍的技术或者工程效能问题。

团队对技术要求处在最高一个等级。

这样的团队规划中应该有技术专家、架构师和开发团队等。

此外，团队负责人和公司人力资源部门需要清晰理解对人才的定义，关于人才定义可以参考我之前分享的“人才画像”一文。先列出这些基本信息，再使用 SWOT 工具做优劣分析对比，找出当前的优势，扬长避短，就可以开始“撸起袖子加紧干”了。

说了这么多，那我是怎么做的呢？下面我先分享自己五段不同的经历，再说说在组建团队的准备阶段，我们需要做什么。

第一段，当时我临时组建了一个团队来完成一个临时性的项目，团队人员是流动的。 核心人员是从其他团队借调的，另外临时招聘了几个刚刚入行的新人。客户对接、需求分析及任务跟踪都是我自己做的，总体上比较顺利，项目完成后团队就解散了。由于是在外企，同事关系比较简单，项目工期也不紧张，所以没有做准备工作。

第二段，我的职位升级后调任一支 15 人左右的团队负责人，任研发经理负责一个系统的研发交付，当时已经做码农近 10 年，但管理方法欠缺，因此恶补了很多管理方面的知识。

第三段，空降到一个 30 人的团队，准备工作主要是了解团队成员及系统开发的情况。

第四段，从零开始将团队发展到 300 人，开始时完全被忽悠，中间无数次想放弃退出，最后坚持下来，收获非常大，当时没有做任何准备工作，完全是摸爬滚打过来的。

第五段，从零开始快速组建创业团队到 40 人，此时组建团队已经轻车熟路了，基本上是按照本文所写的套路去做的。

通过自己数次组建团队的经验，在准备工作阶段，我们需要做的最重要的事情主要有六点：
1.向上管理，观察你老板的为人是怎样的，是否获得充分授权及信任。
2.干系人分析，如果有条件的话，做一次干系人分析，包括你的老板，公司内部的各种角色，分析支持者与反对者（多从对方角度想想为什么？），还可以想想哪些是会帮助你的朋友，哪些是会落井下石的，联系那些不经常联络的朋友，扩大一下社交圈。
3.设立目标，在前进的路上不断看看是否偏离大目标，同时每个月设立可以完成的小目标。
4. 充分发挥SWOT 分析中的优势项，快速做出成果，给大家信心。
5.确立核心骨干，这是准备阶段最重要的事情之一。
6. 建立随时沟通、积极沟通、勤奋沟通的心态。

以上每个 Topic 都足够写个长篇大论来分析讨论，也是我认为最最重要的事情，需要反复学习、反复体验、反复思考。另外， 学一点项目管理知识绝对是有好处的， 很多事情使用项目管理的方法去做，就成功一半了，这次的约稿写作，我也用了项目管理的方法。

最后，由于打造技术团队的话题较大，我将分为几个篇章来讲，本文主要分享了搭建团队之前要做的准备工作，之后的每篇文章也都会以理论结合我自己的实际情况来分析，并分享一些心得体会。欢迎持续关注，也希望你在听读的过程中能够根据自己的具体情况作具体分析，因为只有完美的理论，没有完美的现实。实际工作中的项目 / 任务 / 团队千差万别，我们自身的情况也千差万别，需要根据实际情景灵活机动的应付各种情况，解决各种问题。

我认为在有限的条件下完成设定的目标才是一个合格的团队负责人，拿到 PMP 认证只是认可了你的管理理论水平，实际能力还需要通过做项目带团队来验证，并且只有通过做项目才能得到提高。理论可以作为指导，实际解决问题不能拘泥理论，需要把“十八般武艺”都用上。当你能利用学到的理论，结合实际工作磨练，把理论和实际结合起来，并不断优化提炼出最好的经验（Best Practice）时，你的能力才能得到真正提升。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

邱良军，极智嘉研发总监，TGO 鲲鹏会会员，负责组建极智嘉苏州研发团队，以及筹建苏州研发中心， 4 个月将团队发展到 40 人，并承接两个系统开发，数条支持线的工作。曾在新电任职超 10 年，带领团队交付数个项目，团队峰值人员超 70 人。2014 在文思海辉担任总监，从零开始将团队带至 300 人。18 年 IT 老兵，管理经验丰富。

第175讲 | 邱良军：打造高效技术团队的人才招聘攻略

你好，我是极智嘉研发总监邱良军，一个 18 年的 IT 老兵，其中有 8 年管理经验，包括研发管理、项目管理、运营管理。在上一篇文章中，我们提到在搭建技术团队前，要先明确所搭团队的类型，一般来说有三种不同类型的技术团队，即项目驱动型、业务驱动型和技术驱动型，不同类型的技术团队在招聘时也有很大的不同，今天我就将分享在招聘方面的一些经验和心得。

在设定好要打造什么样的技术团队目标后，我们就要启动招聘工作了，随着中国人口红利的消失，人员薪资成本的上升，特别是互联网企业的蓬勃发展，软件技术人才的缺口越来越大。要找到技术能力强且与公司文化价值观相符的人才越来越难。找人是团队组建的第一步，而要想招聘到合适的人才，必须想尽各种办法、利用各种渠道去找人。

招聘：找人的步骤

第一步、根据搭建团队的目标，做好招聘计划。

第二步、确定招聘需求（定岗定责）：列出每个岗位的职责、需要具备的技能及其他要求。

第三步、确定人才招聘渠道，可以根据自身的特点灵活选择，具体可参考下列渠道：
1.自身的影响力，人脉关系：这是最有效的方式，也是最稳妥的，不过需要你长期维护好自己的形象，建立良好的人际关系，特别是个人诚信、业界影响力、个人技术水平等方面；
2.内部推荐（特别是靠谱员工的内部推荐）：设立内部推荐奖金，这绝对是物有所值，也是最佳的人才寻找方式，因为人才有集聚的特点，就和鱼群一样；
3.业界大牛朋友推荐：扩大自己的交际频率以及交际范围，认识一些技术牛人，参加一些技术 Club，往往在找人时能出奇兵，很多对技术有追求的人都喜欢跟着牛人走；
4. 画本地人才地图，找目标公司挖人：这个也是非常快速有效的方法，不过通常需要付出高薪才能成功；
5.互联网招聘渠道：比较多的有 Boss 直聘、猎聘、Linkedin 等；
6.通过猎头：猎头也是非常好的一个渠道，特别是高端稀缺人才的招聘；
7.校企合作，包括设立合作实验室： 和当地学校建立关系，入驻到当地的校企联盟能有效的扩大企业影响力，招聘到有潜力的新人，还可以和学校建立长期关系，提供实习机会，也为自己选择优秀人才降低风险；
8.组织公司的开放日（Open Day）：让更多的人才直接与公司内部交流，了解公司文化、技术特点，兼做招聘；
9. 参加政府或者行业协会组织的专场招聘会。

第四步、面试方式及面试流程，一般有笔试及多轮面试来考察候选人的技术能力及软技能，如果条件允许的话还是找一个招聘专员来负责。面试沟通及面试接待是比较繁琐的过程，需要有非常大的耐心，投入非常多的时间做沟通解释，这边就不细说了。

第五步、人才选取及考查，要根据自己团队的目标来选取合适的人才，设定完成的时间期限，将面试的重点放在专业技能、管理能力、价值观（公司认同）等方面，一般要求如下：
1. 和岗位需要的专业技能高度匹配：专业技术技能面试过关，定岗定责；
2. 沟通力强：理解公司的业务，知晓管理层，了解公司的发展方向；
3. 责任心：凡事有交代，件件有着落，事事有回音；
4. 靠谱并自带正能量：不抱怨，主动解决问题，懂得纪律的重要性，一诺千金；
5. 价值观认同：认同公司，有目标有理想、有激情有冲劲；
6. 背景调查：非常有用的一个办法，可以大幅度降低选人风险，不用怕麻烦，这个工作的付出永远都是值得的。

第六步、薪资福利包，需要根据自己公司的特点，综合考虑薪资、奖金、期权、股票激励等。

第七步、入职前准备，从发 Offer 到入职的这段时间非常重要，如果不做好沟通，会大大降低入职率，前面的工作将前功尽弃，并且给公司的声誉带来不好的影响。

建议你在找人的时候，准备好下面几张表：招聘需求表、面试流程表、面试及入职跟踪表、每周需做的 PDCA 循环分析表。

这是一个比较理性的招聘过程，实际过程并不会如此顺利，如果你做过招聘，你必定有遇到各种奇葩事情。

招聘：找人的方法

下面我分享两段比较困难的招聘经历，俗话说实践出真知，正因为有这些宝贵的经历才会有今天的思考。

2015 年底，我作为开发经理负责承接一个系统研发任务，计划 2 个月内组建一支 20 人的项目团队，包括中高级 Java 工程师、测试工程师，对整体技术要求不高。因为项目已经逐步启动，所以当时团队的招聘时间非常紧。

我们在首先准备好招聘计划及需求表后，组织了一次各干系人的动员大会，包括公司高层、人事主管、全体招聘人员、部分其他部门负责人等。确定了三个找人的渠道和方法：一是内部协调借调人员，二是招聘专员通过网络渠道招人，三是通过周围的熟人推荐。经过两周时间，面试通过并入职了几个初级 Java 工程师，但是他们对项目启动根本没帮助，反而需要我花更多的时间来给他们做培训。

当我意识到这个问题后，紧急暂停了当前的状态，并分析问题，重新安排招聘方式：首先，暂停初级 Java 工程师的招聘，重点找团队骨干，并且可以稍微放低要求，将重点放到候选人的技能及责任心方面；其次，利用高层的影响力，要求必须借调 1 人过来；最后，扩大周围朋友的范围，主动联系并不太熟的朋友，那段时间我几乎天天约朋友吃饭。

通过三天的努力，马上收到立竿见影的效果，从兄弟部门借调到一名有经验的工程师，能力不是很强，但可以暂时应付，把前面入职的初级开发先组织起来。同时，和几个久不联络的朋友联系后，马上有了回音，连续给我推荐了好几个靠谱候选人。由于有朋友背书，交谈、沟通、入职过程都比较顺利，初步搭建起了项目的骨干团队，后续招聘逐步容易起来。因此，无论怎样的困难，先迅速找到第一个靠得住的骨干再做团队扩张。

再说说第二段招聘经历，我在 2018 年加入新公司并且负责组建苏州的新研发团队，因为有之前多次组建团队的经验，也做了足够的准备工作，几乎用到了所有的招聘方式。同时利用自己的人脉，大范围和朋友做交流，请朋友帮忙推荐，并组织专场招聘会。所以用了一个月时间，就找到了 20 人，并且其中多数是开发经理、Java 高级工程师、前端工程师、自动化测试工程师等，迅速接手了两个系统的开发，支撑业务的发展。在这过程中获得经验体会有：
1. 广开思路的找人，利用一切可以利用的资源，坚持、坚持、再坚持就会有惊喜；
2. 抓住自己的核心骨干团队，选择基础管理人员非常重要，一定要充分了解他的过往历史；
3. 内部推荐是所有找人的方式中最好的，特别是让你的核心骨干去推荐；
4. 人才和鱼群同样具有扎堆的特点，去到鱼群喜欢的地方找鱼；
5. 珍惜你的信用是最佳的招聘方式，注意维护及宣传公司的形象及声誉；

如果你已经明白了如何找人，还要有能力说服候选人加入公司，真正的人才有很多选择的机会，你自己必须有足够的吸引力才能使人才愿意加入。如果“如何说服技术人才加入公司”也是一门学问，那么，有一个比较简单的方式是：请你换位思考一下，如果你是候选人，对方是面试官，你会加入这家公司吗？你和其他公司的对比优势在哪儿？因此，面试官需要介绍清楚的核心点有：
1. 公司的未来，行业的发展，创始团队的情况；
2. 公司近三年来的发展路线，如果是创业公司，重点讲产品定位和市场潜力；
3. 对候选人的职业规划，技术栈，发展机会；
4. 薪资报酬，福利待遇，包括奖金、员工关怀、培训机会等。
另外，还要注意高职位候选人及普通职位候选人的关注点是不一样的，需要灵活掌握。当然切记不可用欺骗及画大饼的方式来拉人，否则来了也会走，得不偿失。

作者简介

邱良军，极智嘉研发总监，TGO 鲲鹏会会员，负责组建极智嘉苏州研发团队，以及筹建苏州研发中心， 4 个月将团队发展到 40 人，并承接两个系统开发，数条支持线的工作。曾在新电任职超 10 年，带领团队交付数个项目，团队峰值人员超 70 人。2014 在文思海辉担任总监，从零开始将团队带至 300 人。18 年 IT 老兵，管理经验丰富。

第176讲 | 胡键：创业公司如何打造高凝聚力高绩效的技术团队：组织篇

你好，我是上海圭步 CTO 胡键，在我的上一篇文章中，我们聊过了“高凝聚力、高绩效的技术团队对于创业公司的必要性”，今天我们就来谈谈如何打造这样一支队伍。 由于篇幅限制，这部分内容将分成上下两篇，上篇（组织篇）关注于组织和团队的搭建，下篇（工具篇）则更多侧重于团队工作的基础设施，以及若干辅助管理工具。

团队架构

就团队架构而言，我倾向于“小核心大外围”。其中的小核心主要由全职精英人员组成，大外围则可以由兼职或全职非精英人员构成。请注意，这里的精英其实没有那么严格，站在公司立场上来讲，更多是指那些认同公司价值观、打过硬仗的员工。这样的组织结构具有天然的优势，非常适合创业公司，为什么呢：

第一，从管理上来讲，只需要重点管理小型核心团队即可，管理成本低，执行效率高；

第二，从人才建设看，核心成员给外围团队起到了模范带头作用，让外围队员更有目标，激励他们向核心区靠拢。而且，即使部分外围人员没有意愿这样做，对于公司来讲，并没有什么损失；

第三，明确人才战略，严进宽出，有效控制公司的全职员工总人数，同时获得不错的生产力。

对于上面的第三点，主要建立在这两层团队明确的分工基础之上：

核心团队，制定规范和核心业务逻辑，并通过自己研制的基础框架和组件将这些知识和要求固化；

外围团队，使用核心团队开发的框架和组件，快速实施；

用一句话来概括就是：核心团队制定规范，外围队伍负责执行。从公司的角度来看，尽量安排核心团队干附加价值高的事情，低附加值的事情则交由外围队伍完成。

虽然客观上这种结构会造成双方心态的不对等，但作为管理者，需要做到公平对待，比如：
1. 符合要求的外围队员可以进入核心团队；
2. 核心团队犯错，绝不姑息；
3. 在资源允许的情况下，为双方提供一致的机会，比如培训；
4. 刻意促进双方交流，加强相互了解，找机会增进双方感情，比如聚餐或踢球等团体活动；
5. 核心团队对于外围团队的意见和反馈需要重视，同时不定期选派核心成员和外围队员共同完成某项任务，帮助不断打磨基础框架和组件。

团队架构决定之后，接下来就是决定各个团队带头大哥的人选。

带头大哥

俗话说，“兵熊熊一个，将熊熊一窝”。站在团队管理的角度，它有两层意思。首先，它道出了这样的事实：什么样的领导，就决定了什么样的队伍。或者更通俗地说：领导的高度决定了队伍的高度。这里强调的“高度”固然包括了领导的硬技能（如：业务能力或技术水平），但对于带头大哥来讲，软技能的要求会要更高一些。第二层意思则是：建立一支队伍首先要找到合适的带头人。基于前面的事实，这个推论的合理性应该不难理解。

对于这样的一位带头大哥，我的要求很简单：与公司三观一致。这里的三观指的是，价值观、团队观和技术观。

价值观

如果价值观不一致，而你又恰好招到了一位充满领导魅力的大哥，那无疑是危险的。历史上类似这样下克上的事情并不少见，即使最终结果是稍微好一点的带队出走，也会造成整体战斗力的大幅下降。因此，在考虑候选人时，首先需要考虑的就是候选人的价值观是否跟公司保持一致。具体到操作层面，我的建议是，你必须能很明确地将公司的价值观总结成一句话或口号，想尽办法让候选人高度认同它。这句话不必高高在上，但一定要具体。它可以是粗鄙浅陋的“脱贫致富”，也可以是崇高光辉的“社会责任”。但不论哪种，它必须能让候选人理解并把它具象化。而候选人最终是否认可，就看各自的机缘和你的魅力了。

团队观

价值观解决了“不是一家人不进一家门”的问题，团队观则充分考察了候选人本身作为带头大哥的软实力。大多数人都认为“带头大哥必须是技术水平最高的那位”，而我个人并不赞同。其实，这种观点的形成跟我们从小受到的教育有很大的关系，因为从小到大，班干部的首要条件就是“学习优秀”，那作为技术团队的带头人，技术当然也得过关，但我认为他的技术并不需要是团队或者整个公司第一。而且就我观察，“技能第一”对于带领技术团队来讲并不是优势，反而常常会带来某些障碍。这些障碍包括：个人意愿、技能偏见、人身攻击、思维局限等等。限于篇幅和主题，这里就不展开说明了。

就团队观而言，我主要考察候选人的以下几个方面：

1. 团队调动能力，即是否有能力让整个团队拧成一股绳、劲往一块使。有这样的带头大哥，不仅团队战斗力超群，而且还能降低团队的管理成本。

2. 良好的方向感，即有能力判断当前做的事情是否符合公司的战略方向，分清楚事情的先后缓急，根据手头掌握的情况做出最佳部署。典型的比如，闲时提前安排人员着手预研相关技术或工具，当竞争对手始料未及夺取市场份额时，能随时根据上级指示做出部署反击。

3. 外部协调能力，即是否有能力获取外部支援以及在外部团队需要配合时能有效地支援对方，协同完成任务。对于这个能力的重要性，道理大家都懂，但特别考验团队带头大哥的能力。一方面，技术人员大多偏内向和好强，即使有困难，最可能首先想到的就是自己先扛一阵子，把对外请求支援看做是一种弱者行为。另一方面，人天性就希望得到关注，做主角是最自然的心态，配角不是人人都想当的。这就要求团队带头人能很好地区分“小我”和“大我”之间的关系，将所有的事情放在公司层面去考虑。

4. 团队教育能力，即是否有能力让团队出现更多优秀的领导者或工程师。这种能力不仅仅是作为带头大哥的言传身教，更多的是培育一种团队相互教育的环境和土壤，鼓励内部成员之间互通有无，并定期邀请外部成员帮助团队扩充视野。条件允许的话，还可以鼓励队员参与社区活动或行业会议，不仅可以大幅锻炼小伙伴的能力，同时也有助于提升公司和团队品牌，带来意想不到的好处。

5. 团队搭建能力，即是否有能力引贤聚能，为团队和公司招到合适的队员。如何在一定成本之下快速搭建出一支最优队伍，同时还能保证一定的稳定性，这不仅仅考验带头人的个人魅力，同时也考验带头人的成本观和人才观。在充分了解公司现阶段状态的前题之下，引入性价比高的员工，帮助公司尽快实现业务目标。

技术观

在三观之中，技术观之所以会排在最后，是因为这三观暗含了这样的顺序：公司层面、团队层面和个人层面。由于技术团队带头人的技术一般不会太差，因此对其技术观的考察也不会落到具体的技术细节上，而在于：

是否能接受不同的技术偏好？

是否能有效地将技术和业务结合起来思考问题？

是否具备一定的技术视野和前瞻性，能有效地判别出未来若干年内值得投入精力研究的方向？

是否有能力将想法落地实施？

是否具备总结能力，不仅仅是将经验写到纸面上，更重要地是能将其固化到代码中，比如框架或业务组件库？

是否有方法论的指导，对于方法论本身的看法？

总结

听到这里，有过架构设计经验的朋友是不是感到有些眼熟？相信你们都会有这样的感悟：系统成败的关键与系统本身的架构和关键对象有密不可分的关系。类似地，打造一个成功的组织也是如此：

首先，团队架构相当于架构范式。选定合适的团队架构不仅要求管理者思考清楚人员分工协作，同时也要求管理者思考清楚自己的人才战略，明确自己当前最需要的人才，以便在一定的成本之下建立相对优化的人才结构。

其次，带头大哥则相当于系统内的关键对象。他或她的确定除了个人能力之外，还需确保三观测试得以通过，以便能在当前公司的组织架构之下起到其应该发挥的作用。

然而，即使有了好的团队架构和带头大哥仍然还不足以让整个组织变得团结并高效，还需要辅以合适的基础设施和工具才行，这也是本文的下篇“工具篇”里需要探讨的内容，敬请关注吧。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

胡键，上海圭步 CTO，TGO 鲲鹏会会员，前 InfoQ 中文站 SOA 社区首席编辑。超过 15 年软件研发经验，先后任职于中兴和 SAP，现专注于工业物联网创业，具有丰富的产品研发和项目实施经验，擅长围绕设备资产和生产管理提供物联网端到端解决方案。他同时还是 CSM 和活跃的社区活动组织者，在西安组织过多场 HiBlock 区块链技术社区活动并做分享。

第177讲 | 胡键：创业公司如何打造高凝聚力高绩效的技术团队：工具篇

你好，我是上海圭步 CTO 胡键，今天我们继续聊聊创业公司如何打造一支高凝聚力、高绩效技术团队，由于篇幅过长，我将这个话题分成了上下两篇来探讨，因为内容互相关联，感兴趣的话可以点击链接阅读上篇文章。在上篇“组织篇”里，我们拿系统架构设计来做类比，重点探讨了成功组织的关键前提：团队架构和带头大哥，将它们分别类比为系统的架构范式和关键对象。正如一个成功的系统除了有好的架构和关键对象设计外，还需要有清晰明确的协作系统和好用的辅助工具一样，要想打造成功高效的组织也离不开好的基础设施和必要的辅助工具，

基础设施

选好团队带头人是否就万事大吉了呢？当然不是！你还得提供相应的基础，为这些带头大哥的工作提供支持，同时也要保证不同大哥之间能够相互配合，合作无间。前文谈到的三观测试只是解决了主观层面的问题，保证大家性情相投，愿意合作共事。但这还不够，为了给我们的事业提供多一份保障，还需要客观层面的基础设施。

这些基础设施典型包括：版本控制、问题跟踪、持续集成、部署流水线。它们为整个公司的开发过程提供了自动化的基础，同时也通过各个系统将开发实践和要求固化，保证整个开发团队都按照同一标准去做事和协作。以我们公司为例，目前所有的研发都围绕 gitlab + Jenkins 的方式完成：

每一项任务（feature 或 Bug）都会有相对应的 issue，对于每类 issue 有建议但非强制的格式要求。

代码管理则采用“主 / 从库”结构，所有开发将各自代码以 Merge Request 的方式向主库提交。对于每个 MR，会先经过自动化测试流水线，成功之后，经专人 Review 合并，正式版本只从服务器的主库编译产生。

代码要求写自动化单元测试，同时有建议非强制的 git log 格式，但强制要求在提交时关联对应的 issue 号。Gitlab 会自动在当前 commit 和 issue 之间建立关联，在页面浏览 commit 时可以方便查阅对应的 issue。

对于涉及数据库的后端，要求提供 DB Migration 脚本，促进发布和测试的自动化。

分支模型采用“branch-per-feature”模式，但 Merge Request 只向主库的 Master 分支提交，并且只从 Master 分支编译。

集成流水线围绕 jenkins 打造，也有团队直接使用 gitlab 的 pipeline，主要完成：自动化测试（发生在 MR 时和合并进入主库后）和部署（人工触发）。

由于 gitlab 本身也支持 wiki，开发相关的琐碎事项可以直接写入到此，但从可维护性角度来讲，我们倾向于将其直接作为项目文档纳入到版本控制中来，方便版本库的迁移。

有人或许觉得这种稀疏寻常的事情不值得去强调，但我却发现不少创业公司不要说部署整个开发基础设施了，就连最基础的版本控制都不见得能保证。这样的公司或许可以很快拿出可用的原型产品，但是能够走多远，让我很怀疑。

这里我再强调一遍，不要以创业公司人少好协调为借口，将这些本该从公司创立第一天就做的事情一拖再拖。在我看来，这种事情恰恰就应该从人少的时候抓起，从一开始就培养好团队的优良习惯，再将后来者不断同化。如果等到人多的时候再做，反而成本更高，推进更慢，因为“人多嘴杂”。

辅助工具

最后，让我们来说说一些常用的团队管理辅助工具。这里事先声明，下面讲到的这些工具并不是一份完整的辅助工具列表，而且我相信这份列表永远也无法完整。之所以列出它们，只是因为我个人经常使用而已，带有强烈的个人色彩。

1. 经济手段

虽说谈钱很俗，但这是一个绕不过的话题，因为它将兑现你所有的“待人诚意”。就我的做法而言，我喜欢：

结合行业标准和个人能力来评定，工作年限只做作为参考。比如，某人号称在某领域中有 3 年工作经验，但经考察发现其只有 1 年工作经验，后两年只不过是重复前面的经验毫无进步，此时只能等同 1 年工作经验来对待了。

基本工资和绩效工资相结合，多劳多得，但此处的“多劳”并不单指“工作时长”，更侧重“工作结果”。在实际操作过程中，可以让绩效工资远超基本工资，同时跟项目的贡献度挂钩。所谓贡献度可以是类似“利用自动化手段大幅提高效率”或“最佳助人为乐”等等，对团队或项目产生直接可见的效果。这种薪酬机制有点类似销售市场的模式，好处显然易见，就是工资直接与公司的财务状况挂钩，避免团队内部出现“南郭先生”，能撑下来的不论从心态还是从能力来看都可谓强大。当然，不利之处也很突出，容易引起某些研发人员的误解和反感。但是，创业公司招人不就是一个认同和被认同的过程么？相比起所得的好处来讲，一点点误解和反感不算什么，只要能够在后续的工作中持续让大家拿到满意的薪资，建立了信任感和信心，其余的问题都好解决。

另外，我不建议开出超待遇的条件，即使你非常希望候选人加入。一方面是没有必要，因为这个世界总能找到替代品；另一方面，单纯靠金钱吸引过来的人往往是最早离开的。对于只认钱的候选人，我宁可外包，而不是考虑共事。或许有人会感到很疑惑，觉得跟上面说的自相矛盾，但你若放在“创业公司”的背景下就很容易理解了：

首先，创业公司永远都处于资金紧张的状态。如果拿薪资跟其他大公司硬碰硬，是以己之短对他人之长。

其次，我上面所谓的超待遇一词仅限于薪资而言，而对于候选人本身擅长的领域，当许以充分的自由度。而这种自由度往往是大公司体制下无法获得的，恰恰是创业公司之长。

再次，创业公司吸引人才不能不谈待遇，但也不能光谈待遇。只要创始人魅力足够，公司的愿景足够诱人，吸引合适的候选人并非困难。

鉴于以上的原因，创始人更应该去用心琢磨公司的业务和前景，以此为王牌去帮助公司吸引各式各样的人才。摆在眼前的一个耳熟能详的例子就是当年蔡崇信放下上百万年薪跟着马云只拿 500 块钱工资一起创业的故事。而且，我相信在收听极客时间的技术合伙人中也有不少是离开待遇不错的老东家，自降工资跟着现有公司老大把业务做起来的。

2. 复盘

在我不靠谱的印象里，复盘一词的流行跟朋友圈中那些神话某些成功公司管理方式的言论有关系。但我最早接触到类似概念则是敏捷方法论中的“回顾”。就其本质来讲，他们其实都是一码事，都强调客观地按时间线复现关键动作，最终进行总结。在敏捷方法中，则落实到：好的实践（应该发扬）和坏的实践（应该避免）。

我个人比较喜欢这种不那么正式的方式，简单有效，如果能持之以恒，累积效果会很惊人。但假若急于求成，一次想改进的东西太多，则可能造成期望和实际落差太大，适得其反，进而怀疑这种方式的效果。这在实践中需要避免。

3. 团队建设

团队建设的方式依据公司所处的阶段不同而不同。对于刚起步的公司，吃吃喝喝可能就够了。因为此时公司人也不多，酒桌完全可以担当起拉近人与人之间距离和统一大家思想战线的作用。至于上规模的公司，选择面就更多了。但总的原则仍然不变：促进团队合作，提高大家彼此的认同感。

4. 新陈代谢

关于人员管理，外面已经有很多不错的文章和实践，这里我只想强调几点：

第一，尽快淘汰不认可公司价值观的员工，不论职位高低。因为他们的存在对于整个团队士气有不可估量的后果，职位越高，后果越严重。

第二，对于希望挽留的员工，考虑感情留人、事业留人和待遇留人。但说实话，很多时候这已经属于事后补救措施，效果有限。站在公司角度，管理者更需要思考的是为什么会走到这一步？

第三，新挑战是除了经济手段之外最好的激励手段。对于有自驱力的员工，他不会满足于不断自我复制，希望能不断成长迎接挑战。这些新挑战在我看来有两种：一种是在项目中尝试新技术；另一种则是采用老技术将项目升级到新形态，典型的比如，原来的业务逻辑都是硬编码到系统中，是否可能通过重构系统的方式对其进行优化，分拆成基础平台和业务实施平台呢？技术人员往往对第一种重视有加，但对于第二种重视不足。

总结

至此，三篇关于我个人在创业过程中所收获的组织管理经验的文章在《技术领导力 300 讲》就告一段落了，它们记录了创业这几年我最大的感悟，其重要程度远胜于技术经验的增加。在我看来：

1. 打造一个团队，首先应该关注于凝聚力，然后才是团队绩效，而目前的技术团队管理方面的文章对此强调较少。

2. 打造组织的过程跟搭建系统有异曲同工之妙，都是先确定整体结构，再确定相互交互，最后辅以若干工具的过程。只是在组织搭建的过程中关注的对象是活生生的人，而不是冰冷的组件和对象。

3. 和软件架构一样，组织的结构也需要根据组织本身的发展不断进化，妄想一步到位必将自食恶果。在不同的阶段，需要采用不同的结构。

4. 没有最好，只有最适合，各个公司有各个公司的企业文化和发展历史，生搬硬套既是一种懒汉思维，也不会成功，所有其他公司的组织结构和搭建方法都只是参考。

最后，感谢《技术领导力 300 讲》的邀稿，让我有机会跟各位优秀的读者进行交流，谢谢！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

胡键，上海圭步 CTO，TGO 鲲鹏会会员，前 InfoQ 中文站 SOA 社区首席编辑。超过 15 年软件研发经验，先后任职于中兴和 SAP，现专注于工业物联网创业，具有丰富的产品研发和项目实施经验，擅长围绕设备资产和生产管理提供物联网端到端解决方案。他同时还是 CSM 和活跃的社区活动组织者，在西安组织过多场 HiBlock 区块链技术社区活动并做分享。

第178讲 | 马连浩：用人的关键在于用人所长，而非改人之短

你好，我是 iPayLinks CTO 马连浩，极客时间 APP 上线以来，作为 TGO 鲲鹏会会员，能够免费阅读所有专栏，得幸听过很多技术大咖的管理专题类课程，甚至有的管理类文章听了两三遍，文中有很多管理方法论及管理技巧的分享，内容全面且深入，因此就不在这里赘述了。今天我想和你分享一些用人方面的领悟与思考，希望能给你带来一些有营养的东西。

知人才能善任

曾经看到一个观点，“改变自己是神，改变别人是神经病。”意思很明确，不要去奢望改变别人，而是要努力改变自己。这个浅显的道理同样适用于团队管理，对于设定的目标，更重要的是要从自己出发，不仅需要自己身体力行去实现，更要根据情况改变自己的管理方式，做到知人善任，靠改变别人来迁就自己，只能是乌托邦痴人说梦而已。

先前在某公司时，我的两个下属：张和刘（避免误会隐藏真名）年龄相仿，技术能力相当，在各自团队里面的表现都很突出，因此我提名他们做了两个技术团队的主管，负责两条产品线的项目管理和研发交付。这是当时我所负责的整个技术团队中最重要的两个子部门，张和刘自然就成了我的左膀右臂。

没想到的是，三个月之后，却出现了“冰火两重天”的情况。张带领的部门开始出现颓势，项目延期，质量失控，团队成员冲突频频，经常出现争吵的局面；而刘带领的部门则是项目交付很顺利，关联部门评价也很高，团队小伙伴的状态昂扬向上，一片欣欣向荣的态势。

我就很纳闷，因为就我亲眼看到的情况来说，张工作更勤奋，他总是在加班，我常常能在深夜的办公室里看到他的身影。刘则不然，乍一看之下，他并不像张那么勤奋，会议开得也不多，团建庆功倒是不少。

时间一长，我也听到了一些“小道消息”。有人指责张太死板，老是压制手下这个方案不行那个方案也不好，搞得团队死气沉沉，团队成员积极性不高，工作不是很开心，进度自然慢了下来。同时，也有人嘀咕刘太随便，什么东西都敢尝试，手下的人经常整出一些新花样甚至幺蛾子，有哗众取宠作秀的嫌疑。于是，我借着季末绩效考核的机会，分别跟张和刘谈了话，了解了实际情况，看清事实，分析原因，并制定对策。那次谈话，也让我对管理工作有了进一步的了解。

张认为，部门交付效率下降的原因在于团队小伙伴们不给力，张说：“团队成员的缺点太多了，改起来需要时间，三个月显然还不够。”刘则认为，部门业绩增长的原因是手下的人很优秀，刘说：“他们每一个人都很厉害，我只是鼓励他们大胆去做自己认为对的事情，若有问题，我再身体力行给予辅导。”

又过了一个季度，年中考核结果出来之后，依据绩效管理规定对张进行了降职处理，并从管理序列转到技术研发系列。他自己感觉面子上挂不住，最终选择了辞职。而刘则升职为技术总监，并接管了张走后的技术团队。

如果用一句话来总结他们的做法就是，张看到了下属的缺点，一直在改人之短；刘则看到了下属的优点，一直在用人所长。

看一个人的缺点，是比较简单的，通过一两件小事就能得出大概结论。而看一个人的优点，却非常困难。尤其是对于管理者来说，很多时候明知道下属在某些方面的确比自己厉害，可是心里非常别扭，不想承认或不愿承认，硬是把一件好事整成了心病。而这种”不想“或”不愿“的行为，就导致在“知人”方面出了大问题。既然不能知人，自然也就没法做到善任。

从这个意义上来说，一个优秀的管理者，一定要把主要精力放在用人所长上，而不是改人之短。尤其对于社招来的团队成员更要如此，高成本招来的社招生，要的就是招之则来，来之能战。而对于应届生需要设置一个培养周期，帮助他尽快有能力承担一些更为深度的工作。因为，用人所长，才能创造奇迹，是天才的行为；而改人所短，要么自讨没趣，要么事倍功半，是蠢笨的选择。

研发工程师分类

接下来，基于我在工作中的一些实践，针对一线技术管理者最常遇到的如何给研发工程师安排工作的典型场景，介绍一下该如何给研发工程师进行分类，以及不同类型的工程师该采用什么样的用人策略。一般来说，研发工程师可分为优秀工程师、具有自驱力的潜力工程师、具有自驱力的普通工程师、熟练工程师和普通工程师五类：
1.优秀工程师：技术优秀，认同公司价值观和愿景，有很强的主观能动性，喜欢发现问题，解决问题；
2. 具有责任心的潜力工程师：认同公司价值观和愿景，有很强的主观能动性，技术能力尚待提升；
3. 具有责任心的普通工程师：认同公司价值观和愿景，有很强的主观能动性，技术潜力一般；
4.熟练工程师：技术比较扎实，但主观能动性一般；
5.普通工程师：技术一般，主观能动性也一般。

在现实的技术团队中，往往存在上述各种类型的员工，做好技术人才的画像，将合适的人放到合适的位置，是形成高绩效团队的前提。给不同类型的技术工程师安排工作任务，就如同打仗排兵布阵一样。

优秀工程师需要公司提供适合的舞台，并由技术负责人亲自提供有效的辅导，让其尽情发挥，形成团队榜样；潜力工程师就需要让其负责核心项目中的核心模块，在实战中历练，并安排优秀工程师提供辅导帮助其尽快的成长为优秀工程师；具有责任心的普通工程师安排一些技术难度不高同时需要非常细心的工作，如资金渠道接入、核心业务系统维护等，促使其慢慢成长；熟练工程师安排相对独立、较少协同的工作，可以带一些新人或应届生，但要观察其心态和价值观，避免负能量影响；普通工程师往往需要安排优秀工程师对其工作进行复核监督，避免责任心不到位产生故障损失。

结语

不管是哪一个层级的技术管理者在用人方面做到知人善任，都是非常重要的。用人不是要求对方做圣人，方方面面都非常优秀，但求对方有一技之长，用的就是对方的长处。现在团队人员构成越来越年轻化，管理新生代 90 后员工更多的要抱以同理心，相互尊重，在有条件信任的基础上，更容易建立高效的技术交付团队。优秀的管理者都懂得人性，他们都知道“用人所长”，包容人才的短处和缺点。

以上是我用人方面的一些实践，抛砖引玉，大家可以参考一下。也欢迎在留言区和我一起探讨。

作者简介

马连浩 iPayLinks CTO，TGO 鲲鹏会上海分会会员，曾任职于盛大、新浪、平安、利得等互联网和金融科技公司，先后担任过架构师、技术总监、技术副总裁等技术管理职务；在互联网和金融科技的产品研发及技术管理领域具有超过 12+ 年的从业经验，在互联网、金融科技和跨境金融实际等行业产品研发和解决方案有深入研究和一线实战经验。

第179讲 | 张矗：技术管理者必经的几个思维转变

你好，我是马蜂窝技术副总裁张矗，在互联网这一行摸爬滚打了十余年，也参与了两个创业项目。一路从一个普通工程师走向技术团队的管理岗位，经历了多少挫折和错误，可能也只有自己才清楚。我回顾自己在这个过程中的成长，发现每一次蜕变都是思维的转变。今天总结一些经验分享给你，希望对你也有一些帮助。

一、去管理，而不是找人协助你

刚开始带团队时，团队成员大概在 7-8 人左右，通过有效地辅导，任务分解，沟通协调，团队成员的工作也能有条不紊地推进。但问题在后期逐渐都凸显出来了，其中一个问题就是主要的核心代码还必须由我完成，一些长期来看重要，但是短期无法校验结果的事情，我也无法安排给其他同学来完成。

今天回头看这个转型阶段，一方面是长期单兵作战形成的一些"技术洁癖"局限了自己的思维转换，"技术洁癖"并不是缺点，不过"技术洁癖"会让自己更多的关注在代码层面，而我们需要让自己的关注点转移到解决方案、产品交付、质量控制等其他层面。这些领域对于一个新手技术管理者来说，很可能都是需要重新学习的内容，因此出现问题就成为了必然。

另一方面是没有找到对任务完成情况进行跟踪和衡量的办法，导致自己无法和团队建立信任，无法将任务的复杂性有效地封装和管理起来，任务封装可能更多的在于能力问题，但任务管理就是思维问题。比如如何了解任务的执行进度？如何监控可能的风险？如何在任务中进行资源的协调？如何阶段性的衡量任务的执行情况？等等。

只有转化思维，了解这些问题，才能从根本上理解管理的意义。而这个过程中，在单兵作战期间能力非常突出的成员，可能要花费更多的时间来完成思维的转变。在我看来，管理不是找一些人来协助你的工作，而是让你带领一帮人来完成指定的目标。而现实情况是问题多种多样，问题的解决办法也是多种多样，对于这种多样性，我并没有固定的解决办法，只能具体问题具体分析，在这里我不再展开来谈，我想强调的是思维转化是这一切的前提。

二、技术视野从深耕到全局

今天互联网领域用到的技术非常广泛，一个人要对所有主流的技术栈有一个全面且深入的了解，只从时间这个维度来看，已经几乎是不可能的了。

人们总是习惯于用自己擅长的技术来解决问题，这无可厚非。但是随着我们管理的范围越来越宽泛，如何管理其他技术栈领域的团队是一个不可回避的问题。举个例子，不同的技术栈适合解决的问题不同，在协同工作的时候，经常会出现重复造轮子、统计口径不一致等现象。

在移动互联网爆发的这些年，我看到很多客户端团队和服务端团队的互相不理解，WEB 开发团队和大数据团队的互相不理解。这个时候往往是需要工程师能够互相换位思考，可是一般的工程师并不具备这样的能力，这就需要我们技术管理者能够从一个宏观的视野来进行协调和规划。

而要做到这一点，就需要我们具备足够的技术敏感度，同时要保持一个开放的心态，保持对新技术的追踪与学习，不需要了解具体的技术细节，但要能够了解不同技术栈适合用于什么场合，这是非常重要的。

我自己早期更多的偏向 WEB 开发领域，那个时候大数据生态刚开始在国内萌芽，但是需求一直存在，我自己还使用 PHP 实现了一个简单的分布式计算方案，一开始也迅速解决了问题，但是随着时间推移，维护成本越来越高。等到阅读了谷歌关于大数据的三篇论文，回头再看，直接采用 Hadoop 的方案应该会少走很多弯路。

当然，这个过程需要我们不断提升快速学习、总结归纳和英语沟通的能力，同时，对于其他技术的学习，也要关注在它在成熟度、应用领域、人才状况等方面的情况。

三、该不该停止写代码？

写代码应该是一个给技术人员带来成就感的行为，我认为也是一个技术人员要毕生追求的行为。

但是作为技术管理者，随着管理任务越来越重，在写代码上的时间投入一定是在减少的。当出现下面几个迹象的时候，也许就是时候停止了：

项目的推进开始等待你的代码完成，可是你的时间花在会议、招聘等管理事务上，无暇顾及；

你写的 BUG，别人修复起来消耗的成本很高；

你写的代码无人可以维护。

这几点说的都是一个意思，即在这个阶段虽然你的代码质量可能依然优秀，但是它已经成为了整个团队的瓶颈。

当然，我并不建议这个阶段的技术管理者完全停止写代码，少量写一些不重要的代码，持续保持自己的技术敏感度也是很重要的，这个时候，一些胶水语言也许就非常适合了。

四、不要时刻冲在最前线

亲自带领团队完成一个又一个的项目，当然是技术管理者的责任。但是随着团队越来越大，要做的事情越来越复杂，你不得不认识到，时刻冲在第一线，对你和团队来说都不再是一个好的选择了。这会让你无法关注最重要的事情。这时候，需要让团队中更多的优秀人才来带队，辅助你完成项目，而你要用服务的心态做好帮助的角色。

从带领团队到服务团队的转变，具体表现在几个方面：

从简单的辅导培训，走向搭建平台。辅导培训更多的是一个单向输出，而搭建平台是创建规则、环境与生态，让大家能够在更大的空间中自由发挥才能，施展创意。

从统一管理到多元治理。在小团队阶段，统一固然能够保证效率最大化，可是多元化才能让你的团队长期发展。而这需要管理者保持开放的心态，在不同时期做好统一和多元间的平衡。比如在团队初创阶段，统一的开发语言、CI/CD 流程会让整个迭代过程非常高效，但是团队规模变大之后，支持多种开发语言的微服务解决方案就变得非常重要。

更多的要成就他人。团队的成功一定不是一个人的成功，应该是团队整体的成功，并让团队成员与团队获得共同成长。这就需要我们作为技术管理者赋予团队成员更多的责任与权力，并在一个个项目攻坚中，帮助他们完成自己的蜕变。这样相辅相成，相互成就，团队才能持续正向的发展。

还记得电视剧《兄弟连》里面有一个经典的场景：温斯特晋升营长之后，下面的连长带领 E 连冲锋遇到了阻碍，温斯特控制不住要自己上去带领 E 连冲锋，却被他的团长叫住。作为营长必须坚守在指挥阵地，完成更重要的任务，为整个团队负责。

五、技术思维到产品思维的转变

技术的最终目的还是要创造价值，同时技术的价值也必须通过产品来呈现，因此，技术管理者的关注点不能仅仅停留在技术架构与团队建设上，更应该建立你的产品思维。具体该怎么做呢，我有以下四点建议：

第一，关注客户的反馈，不光是内部客户，也应该关注外部客户；
第二，需要对业务有更深地理解和洞察；
第三，关注财务状况，要思考如何让技术团队从一个成本中心转化为利润中心；
第四，让其他岗位能够通过产品充分利用技术，将技术的价值最大化。

这并不是要让技术管理者转型成为产品经理，产品经理也是专业活，也需要时间的积累，而是让技术管理者能够具备同理心，站在产品经理的角度思考产品价值。研发工程师和产品经理常常在各种段子里面被描述成相爱相杀的冤家，其实用技术的手段打造出改变这个世界的产品，应该是每一个互联网技术管理者的梦想终局。

因此，我建议技术管理者们，要时常转变思维，换一个角度来看待技术对产品产生的价值，网络上流传乔布斯 1 秒变小白，马化腾 3 秒，张小龙 5 秒。那么你转换思维需要几秒呢？

作者简介

张矗，马蜂窝技术副总裁。TGO 鲲鹏会会员，曾任新浪网研发经理，开心网联合创始人。2012 年加入马蜂窝，负责技术研发团队管理工作。目前，马蜂窝技术研发团队已发展至 600 人。

第180讲 | 钟忻：成为“温格”—聊聊如何当好CTO

你好，我是联通沃云 CTO 钟忻，今天想跟大家聊一个轻松点的话题：从足球队主教练看怎么当好 CTO。北京时间 2 月 19 日，前阿森纳主帅温格获得劳伦斯终身成就奖，昔日爱徒法布雷加斯为其颁奖并在社交平台上对恩师表示了祝贺。之前不久，温格在阿森纳培养出的最后一位代表性球员拉姆塞宣布下赛季转会尤文图斯，也宣告了后温格时代，在他离开半年以后正式终结。

在长达 34 年的教练生涯中，温格执教阿森纳长达 22 年时间，教授带领枪手共获得了 3 座英超冠军和 7 座足总杯冠军，也曾在欧冠击败过皇马巴萨，闯入决赛。尤其是 0304 赛季，英超 49 场不败的神话，至今无人打破。

作为多年的阿森纳球迷和六年的技术管理者，有时遭遇管理困境的时候，温格这样的足坛大咖的经历，就是活生生的例子，可以学习和借鉴。另外，我也发现了一些有趣的现象，很多球迷讨论的关于球员和主教练的话题换成程序员和 CTO，都同样适用。

比如前段时间，国足惨败，里皮下课。有球迷调侃说主教练是个高危行业，就是背锅侠，这么高的年薪就是主教练的委屈费。而在技术圈，我们也经常讨论 CTO 背锅的话题。

再比如也是前不久，亨利执教摩纳哥三个月就黯然下课，有球迷在讨论，好球员未必是好教练，好教练也不一定是好球员。而在技术圈，我们也经常讨论，好的程序员是不是就能成为好的 CTO。还有很多诸如此类有趣的对比。下面就让我们以温格等主教练为例，来看看如何当好 CTO。

1. 专业能力

作为足坛知名的主教练，通常都有自己擅长的执教风格，比如刚刚从曼联下课的穆里尼奥最擅长防守，用一堆人高马大的后卫在禁区前“摆大巴”，然后伺机反击。虽然场面很难看，但却让对手一筹莫展，也能取得不错的战绩。再比如利物浦的主教练“渣叔”，擅长快速进攻，所以比赛一般都是大开大合，进球很多，让人大呼过瘾。而温格最为人称道的就是他的球队打法，强调地面进攻，层层推进，犹如行云流水，让人眼花缭乱。这样的打法，一般都能有很高的控球率，尤其遇到弱队，对方几乎没有碰球的机会，也就很难制造威胁。加上明星球员的临场发挥，经常打出连续几十脚不间断传球得分的经典之作，也因此，在他执教后期，虽然阿森纳战绩不佳，仍然能拥有全球范围内广泛的球迷基础。

2. 识人用人

对于主教练来说，要支撑自己的执教理念，必须得有得力的核心球员。放眼当今足坛，能在几个不同的球队都达到顶级水平的，非瓜迪奥拉莫属。但他为了打造自己的足球风格，通常会不惜花重金来进行人员的洗牌，即使是公认的实力派球员，不符合他理念的，也会被边缘化。

由于客观与主观的原因，温格的用人风格跟瓜帅有很大不同。他不是靠砸重金来打造心目中的梦幻阵容，而是有着擅长点石成金的用人能力。比如亨利，在尤文图斯看了一年饮水机，被温格带到阿森纳，很快成长为了世界顶级的球员，也是我多年的足球偶像。再比如法布雷加斯，年纪轻轻就被温格委以重任，最后也成长成为世界级的后腰。

3. 管理风格

在世界足坛，既有不少“铁腕”主帅，强调球队纪律，擅长从严治军，也有“打鸡血”型的教练，善于鼓动和激励球员。因此，在执教新球队的时候，面对如何处理与更衣室“意见领袖”间的关系这个难题，有的教练喜欢采用高压政策，而有的教练则会包容大牌球员。君不见穆里尼奥就是因为没有摆平博格巴，导致球队战绩不佳，被逼下课。他前脚一走，换了前曼联球星，非常年轻的索尔斯克亚来执教，博格巴就状态爆棚，曼联也连胜了好几场。而温格显然不是这种执教风格，据他的传记透露，他对球员是比较包容的。这样对球员的成长有一定的好处，但也经常被球迷诟病，有的年轻球员球技迟迟没有起色，比如球迷经常津津乐道的“吉祥三宝”，最后都没有成大器，但温格仍然不忍心弃用。

4. 坚持梦想

得到劳伦斯奖，对于任何一个体育界人士，无疑都是非常值得骄傲的。为什么温格能做到？我想，归根结底在于他多年坚持自己的梦想，坚持践行自己的执教理念。在开始执教生涯之前，温格只是一个非常不知名的球员。甚至在他加盟阿森纳的时候，也只是日本 J 联赛的球队主教练，因此遭到了很多人的质疑。上任之初，甚至有人打出了标语“谁是阿瑟？”来质疑他（温格的全名是阿瑟·温格）。但正是此前多年默默无闻期间也坚持自己的教练梦想，持续不断的积累，形成了自己的执教理念，才使得他能在短时间内，把阿森纳打造成了世界足坛的一支劲旅。

如何成为“温格“？

对于作为 CTO 的我们来说，温格无疑是一个很好的榜样。同时，我们的职业跟主教练也有很多可以借鉴的地方。

首先, 要有独特的“执教风格“。作为 CTO，我们的“执教能力“和”球队打法“体现在我们的技术专长和技术路线上。必须得有自己的技术专长，结合自己的技术积累，来做产品创新，使得公司在产品上具备独到的“风格”，也就是核心竞争力。另外，CTO 的技术视野也很重要，提出的技术理念要符合技术发展的趋势，给团队正确的技术指引，避免选择错误的技术路线。一般能在市场上立足的产品都有自己的独到之处，有的产品可能是以界面风格易用性取胜，有的产品则是以稳定性性能优越取胜，而这些产品优势跟 CTO 的技术背景和此前长期的技术积累肯定都有很大的关系。

其次，要培养“明星球员“。作为 CTO，人员的招聘培养是非常核心的工作。从招聘开始，就要关注团队成员的成长，识别出“明星球员“，把自己的经验倾囊相授，让他能迅速的成长，并委以重任。有一批这样的核心员工，才能保证团队取得佳绩。

再次，要管理好“更衣室“。作为 CTO，一定有着自己独到的管理风格。有的 CTO 亲和力比较强，有的 CTO 比较严厉。不管什么管理风格，都是为了促成团队团结一心，来保证目标的达成。另外，在团队管理上，要想短期出成绩，拥有广泛的人脉，能从外部引入人才是非常重要的。如果加入新公司的时候能够带一些得力干将一起加入，更是一个能平稳落地、快速出成绩的有力的保证。当然，如何管理好老员工以及新老员工之间的关系，也是需要注意的问题。关于这个话题，我之前在专栏里写过相关的文章，感兴趣的话可以点击文中链接阅读（CTO 空降上篇、下篇）。

最后，毋庸置疑，每个 CTO 心目中都应该有一个希望到达的彼岸，不管是上市敲钟，还是财务自由，还是别的，必定是需要我们多年的努力奋斗才能达到的。但也许更大的梦想，是成为温格那样的人，对时代有影响，也改变了很多人的人生。当他从自己昔日的得意弟子手中接过奖杯，想必也是百感交集。

正好前段时间，以前 lab 的 CTO，前 IBM 杰出工程师 Jane Xu，已经 70 岁的老太太，在看到我 LinkedIn 上的工作变动以后给我发消息，寒暄了几句。回想起刚加入 IBM 的时候，看着 lab 在她的领导下从很小成长到几千人的规模。我们也有机会参与 Top500 超级计算机这样的核心项目的开发。那段时间，她每个月都会跟技术梯队的人一起开会，对大家进行成长辅导。有一次我还因为工作不够积极，收到了她单独发的邮件。那些年在 IBM 学到的很多技术和管理的理念，现在还在给团队传递和践行。温格传递给世界的是他对足球的热爱，而对技术的热爱和不懈的追求，也许就是我们作为 CTO 和技术管理者能够传递的最核心的价值。

作者简介

钟忻，联通沃云 CTO，清华大学自动化硕士。曾在 Turbolinux、IBM、Intel 等多家 IT 公司担任资深软件工程师。主导了多个大型行业云平台的产品研发和运营，包括乐视云平台和海航 eKing Cloud 基础云平台等。目前负责联通沃云的整体研发工作。。

第181讲 | 姚威：技术团队管理中关于公平的五个核心准则

你好，我是凌晨 CEO 姚威，你有没有听过这样一句话“技术人员都很单纯的，连这样一群人都管理不好，那一定是管理者的问题”。或者你在管理技术团队时有没有这样的感觉：技术团队管理工作中的那些头疼的问题，大多与公平一词相关。新东方年会那首职场版“沙漠骆驼”依稀还在耳边，整首歌都表达着各种不公平的问题。这些问题往往由很小的点爆发，认真处理时又发现牵涉太广，继续解决甚至开始自我怀疑，是制度问题？还是管理问题？还是某人的个人问题？每到这时都有一种无力感油然而生。

创业这两年，跟很多管理者们聊过，有信奉管理方法论的，有频繁修正优化管理制度的，有打感情牌的，有用三寸不烂之舌左右调停的，我个人也深受其累，也是在不久前做出了新的管理方案调整，今天和大家一起分享一下。

我个人一直在网络安全行业从事技术工作，中间开始管理一家乙方安全公司的核心技术小组，直到开始带团队创业，过程中其实从来没有带过大型技术团队。不过，无论是大型技术团队还是小而美的技术部门，只要你需要一支能“打仗”的队伍，相信下文内容一定多多少少会引发你的共鸣，无论舒适或是不适。

关于公平的几类常见问题：

1. 沟通类
这一类是最常见却最不易发现的问题，技术人员往往会用管理者和个人沟通的频率来判断两人的关系密切程度，沟通少的人往往觉得自己在整个团队中和他人已经拉开了差距，处在了弱势一方，自然会认为自己所有的事情从此都失去了公平待遇。
2. 考核类
这类问题可谓经久不衰，你会发现无论多么完美的考核体系，在出结果的那一天都会被无情挑战；无论如何高喊用制度去管理，矛头都会指向某一个具体的人。而当管理者去复盘制度和执行过程的时候，没有任何人提出异议，在结果出现的时候考核体系却崩塌了。
3. 工作分配类
工作的类别可能会有设计、研发、测试、运维等很多种，但在技术人员看来往往都是“活儿”而已。每个人对“活儿”的评估都是很主观的，于是乎，在工作分配初期就会有人觉得不公平，甚至在进度出现问题的时候也会质疑当初工作分配上就有问题。
4. 制度类
这类问题也是传说中管理者面临的“婆媳关系”，当这类问题出现时，说再多也无非是管理者觉得制度执行上出了问题，而技术人员觉得是制度本身就有问题，各位管理者可以用自己的血泪史自行展开。

为什么会出现上述几类问题呢？

首先，技术团队管理虽是管理的一种，也是与人打交道，但具有很强的特殊性，特殊在这类人群本身就很特殊。我也是一路技术出身，乱讲两句大实话，绝对不是要以偏概全：技术人员往往有着极强的契约精神，在自己的领域非常有主见，自尊心很强，对曾经处理过的问题有着绝对自信。所以对于这样的人群，如果没有意识层面的共识，只是强调管理制度的执行，那本身就让他们觉得是不公平的，冲突的出现就会是必然且频繁的。

其次，我建议不要用目标、过程、结果这样的词汇去管理技术团队，即使拥有很优秀的人才梯队，每个人在理解这些词汇时与管理者也绝不是在同一个维度上的。拿目标一词举个例子，通俗一点说，对于管理这份工作的目标可能是项目成果、效率提升、良好的用户体验、用户量提升多少等等。而技术人员真实的工作目标呢？是完成一个活儿、完成 KPI、完成一个功能、添加一个模块之类的。从目标一词的理解开始就产生了分歧，过程中的冲突就可想而知了，那么最终的结果出现后，就必定会出现例如“不公平”、“我不服”、“制度有问题”等等不和谐的声音，如果我们尝试去解决这样的信息不对称，还试图以教育的手段及姿态去统一他们的想法，那就陷入了另外一种“不公平”的漩涡了。

总结一下核心的悖论：所谓“片言九鼎，一公百服”，公平的管理制度是管理者的必要工具，而制度的公平性又无法让被管理者全都认同，这就和技术人员强契约精神的思维模式产生极大的根源性冲突。

关于公平的五个核心准则

那要怎么样才能做到公平或者说相对公平呢？在实践中，我总结出了五个核心准则，希望能给你提供一些参考：

1. 意识层面的核心准则
意识是技术团队管理中的根基，这一点跟大多数管理思维可能不一样，大多数的管理思维本着“先定好规矩，然后说话算话”的思想，认为制度才是管理的根基。前面我们提到，技术人员有着非常高的独立思维并且越优秀越自信。那么从根本上来说，你就没办法让其信服你制定的制度是正确的。换言之，当技术人员接触制度时根本不知道这些制度制定时的目的和意义是什么。他们挑战的其实不是制度本身，而是制度制定的原则和目的，这恰恰是和公平相关的。

在制定和下发制度前，先做好团队基础意识的统一就显得尤为重要了，我们的团队统一的是“以终为本，能力为尺，人人平等”的意识与理念。也就是告诉所有技术人员，所有的工作制度是为了保障完成最终工作制定的，所有考核制度考核的是技术人员个人能力与协作能力，能用自己的能力完成自己的工作，人人都是平等的。

这些意识的传达绝不是喊一喊口号而已，而是他们可以以此校验未来各种制度的核心意义是否与之相符合，如果出现不符合的，比如要求必须加班或者把加班时间纳入绩效考核等，就可以挑战并废除掉，保证意识层面的公平与统一，这比所谓的“制度学习”更符合技术人员的思维模式，也更具实际操作性。

2. 角色层面的核心准则
首先，需要解释的是，我使用角色一词是为了区别等级和职位。等级和职位是人力资源和组织架构层面的，对于技术人员而言，等级和职位这些词他们并不感冒。而角色一词在技术团队中却无处不在。

我个人对于具体技术工作中的流程持悲观心态，并不认为现实中存在“完美流程”。一个具体项目中，每一个环节该谁做事，该谁做什么事及做到什么程度，这些不是一个工作分配讨论会议就能解决的，即使分配了也没有那么细，即使足够细节了，也不一定能匹配每个人的能力，当然，还不包括协作性任务。如此多的不确定，我倒觉得任务分配不合理、不公平是可以理解的了。

于是我们尝试确定团队中的不同角色，用角色扮演的方式让每个技术人员立即判断自己该做什么。举个例子：我们团队中对于职位平行的研发技术人员也做了更细的角色划分，比如决策人、责任人、操作人和协作人几种角色。

决策人：除了常规本职工作外，当技术工作出现多种方案时做决策的人；

责任人：除了常规本职工作外，还需要收集他人遇到的问题和不同想法；

操作人：只要做好常规的本职工作；

协作人：除了常规本职工作外，配合某一个具体的操作人推进工作；

以上种种虚拟角色是在工作分配会议上分配的，针对不同的项目，虚拟角色都可以进行更换。工作是管理者进行分配的，而虚拟角色是技术人员参考自己的能力选择担任的。我们不能因为不同的项目工作就去改变组织架构，但在不同的项目中，让最合适的人体现自己的能力，却可以用角色扮演的方式去实现。这样角色层面的准则确定，确实减少了我们在工作分配上出现的各种不公平和常说的“强人所难”。

3. 制度层面的核心准则
到了第三层，终于说到了制度层面，基于我们能先确定的意识与角色这两个层面，在制定制度的时候就可以有理可依，即使制度苛刻，也能让人理解其情有可原。

意识层面大家是统一确认的，虚拟角色是灵活可选的，那么我们可以直接说，我们的制度不针对任何人，而是针对各种角色。我们的制度约束了每个角色应该做什么事、拥有什么权利、需要承担什么责任、获得什么利益保障。制度依然是“死”的，但角色是“活”的，每个人可以根据自身能力和对不同项目工作的熟悉程度而自由选择。当然，既然自主地选择了一个角色去扮演，就得执行那个定死的制度。这也是一种公平。（我个人觉得，这比不能干就滚蛋有温度的多，对于管理者而言也更绅士。）

4. 执行层面的核心准则
在执行层面，管理者需要做的就没有那么多了，针对不同角色履行相关的制度就可以了。唯一需要注意的是，针对不同角色去优化制度的细节，也可以将一些特别细的监督和管理任务分配给一些角色。

记得著名的国际战略管理专家林正大曾说过：“权限就像风筝线，部属能力强了就放一放；部属能力弱了就收一收。”一样的道理，如果在团队的不同角色中，有些能在前线辅助我们去管理的人，就该去优化我们的角色制度，给予权限。对于技术人员而言，他们彼此有着认同感，这可能是管理者如何提升也难以企及的。也让团队的每一个人看到，管理者并不是每天拿着制度敲打你的那个人，也可以是为了统一意识去修正自己与制度的那个人。

5. 奖惩层面的核心准则
最后才是奖惩层面的准则，奖惩的公平不一定是人人平等，且预设统一的幅度，有时候奖惩的一视同仁才是最大的不公平，毕竟一个团队中每个人的岗位和承担的责任都有所不同。基于前面说到的角色层面，每个角色承担的责任是不同的，那么奖惩幅度和标准也应该是不同的。比如决策人和责任人，是需要额外解决问题做出决策的，他们做的好，贡献更大，奖励更高；他们出现了问题，那么可能不是一个 bug 的问题，所以惩罚可能更重，也倒逼着这个角色需要具备相对高的决策能力和全局思考能力的人来承担。当然打一份工拿一份工资这样的人也有，而且再正常不过了，那么相应的，每次都只承担基础操作工作的人，奖励相对少，当然能出现的问题也很小，所以惩罚幅度也小。有担当的人自然敢于挑战，想打一份安稳工的人也有他选择的权利。

结语

以上关于公平与制度的核心准则，来源于我的公司和团队，可能与大家的整体环境不同，会有很多的实际差异。毕竟管理这事无外乎两点，一个是对人，一个是对事。人人不相同，事有千千万。作为一个网络安全技术从业者转型的管理者，我也一直在摸索前行，总结出的五个准则不敢说一定都是正确的，但作为我的经验之谈，可以保证为其付诸了实验、时间与实践。

对于管理而言，技术团队的管理确实要单纯的多，但是技术团队的中层管理者或是小型技术公司的管理者更多的是在做搭通天地线的工作，偶尔还会被两边怼，背后背锅胸前还得挂个锅盖。但有时候想想，不管想出来的管理方法是不是有效，这不也是我们该承担的责任和扮演的角色吗？

作者简介

姚威，凌晨网络科技 CEO，TGO 鲲鹏会广州分会会员，腾讯 WiFi 安全实验室联合发起人，RainRaid 雨袭团信息安全团队负责人。曾发布：《中国一线城市公共 wifi 安全与潜在威胁调查研究报告》《社会工程学攻击建模》《针对 IPTV 的 EPG 系统攻击思路分析与实验》《匿名者黑客组织针对我各国政务网站攻击思路分析》。

第182讲 | 谢文杰：区块链的下一个十年

你好，我是智链万源 CTO 谢文杰，今天想跟大家聊聊区块链的下一个十年。但在正文开始前，想先给大部分区块链从业或即将从业的朋友们泼点冷水：

1. 如果过去十年你没有在密码学货币里挣到钱，基本上你已经完美的错过了上半场。

2. 大部分现在说的区块链本质上就是个噱头，给大家的感觉好像是万能的，但又好像没什么人知道具体能干啥。

3. 区块链的雪道很长，也很厚，厚长到你还没滚起来就被大概率被淹没了。

另外，如果你没有错过上半场，那看我这篇文章对你而言可能是一种时间的浪费。但如果你不太想接下来完美的错过下半场，不妨认真的看看我这篇文章。不论你是否认同我的观点，欢迎留言与我探讨。

币圈已死？未必！只是暴富的机会越来越小，输光的机会倒从来不缺

说在最前面，如果你有足够的风险承受能力，最主要是心理的承受能力，买点比特币在过去十年和未来十年里任何时间点都不会是错的。当然，我不对前面这句话负任何责任，本文也不构成任何投资指导。

神图镇楼！

这是 2018 年出现频次很高的一张图，图为 2008 年让 - 保罗·罗德里格博士（Dr. Jean-Paul Rodrigue）绘制的泡沫阶段原型图叠加了比特币近期的价格走势，两张图的契合度很高，从图上可以看到，目前比特币刚走到泡沫破灭期的最早期。这两者叠加的概念最早可能是在 2013 年底福布斯中文网的一篇点评比特币的文章里出现的，去年又热了。其实我很认可这张图，不能同意更多。基本上每次有什么东西暴涨暴跌，比如股市，类似这样的观点就会出来刷屏一次，泡沫的起伏几乎不可能跳出这个模型。

回顾一下 2018，对于区块链行业最大的词大概就是币圈凉了，但是币圈真的就这样死了么？

下面是比特币过去十年经典的三次“被死亡”的时间点，同时，也是三次非常好的暴富机会，我进入区块链领域有点晚，只经历了两次。

这三张图分别是 2018 年，2014 年，2011 年三个时间点比特币的三年价格走势，和泡沫曲线都非常的契合。你说到底哪一次更严重些？我是说不出来。但我能说的是，靠比特币暴富的机会已经已经越来越小了。

下面这张图才是我比较想说的，这张图是把比特币十年来的价格走势用对数坐标显示，可以看到走势已经越来越平缓。从这个角度看，对于普通人来说，靠比特币暴富的机会已经越来越小了，但讲真，输个精光的机会从来不缺，这个不局限于比特币。说句题外话，如果你打算进场但碰巧还不知道这张图是什么含义，研究一下可能会对降低你输光的概率有些帮助。

链圈当下的尴尬，说好的凯迪拉克只来了个卡车拉货

我有个朋友经常说，别拿着锤子找钉子，区块链现在就是个锤子。有用的人用的很好，没用的人还在找钉子。

过去，现在，以及将来，提起区块链，都必然提变革。诚然，它前所未有的指数级地降低了传递信任的成本，这是一项革命性的，标志性的工程创新。

先容我说说为什么这么讲。

引用两个 Ray Dalio 的视频截图，经济的本质一般会被抽象成上面这张图，图里有三要素：买家、卖家、交易。放大一些，就是资源的供给方、消费方和整个交易网络。

在这个模型里，区块链技术没有提升生产力，也没有提升货币供给，但它的出现，为整个交易网络的变革提供了一个巨大的可能。

我们智链万源的 CEO 董宁曾经分享过一本书，叫《中间人经济》，可以更好地帮助理解原因。交易需要信任，所以，有交易的地方就会有中间人，有中间人的地方就有交易。中间人一直存在，交易网络也一直存在，也永远不会消失。

交易网络在过去的历史长河里发生了太多次的变革。每一个时代的变革似乎都预示着中间人的终结，但从来没有成功过。这是书里说的，不是我说的。因为在这个交易网络里对于信任的需求从来没有变过，每一次的变革都是在建立信任的效率和成本上做出了一个质的变化。

不可否认，区块链在建立信任这件事情上提供了一种全新的成本更低的技术，所以我说，未来区块链会极大的变革这个交易网络，就像红极一时的互联网思维一样。并且从我刚开始接触区块链、接触比特币的时候就这么认为。

然而，说好的变革一直没来，过去两年，被玩坏了的是各种 ICO，区块链也还停留在争论什么是区块链能解决但传统技术不能解决的阶段。

如果有人和你说他做了一个区块链的创新，革命性的，你想知道靠不靠谱，怎么办？其实可以很简单，只需要问他一个问题，这个场景里区块链技术究竟改变了哪块的成本构成。绝大部分人是回答不了这个问题的，回答不了的，你把他归类成蹭热点的肯定没错。

究其原因，可能是这个世界还缺一次生产力的突破，突破到现有的交易网络不能承载，突破到我们需要一个更高效的交易网络。

也有可能是这个新的交易网络根本不够高效，或者说区块链和各项基础技术的融合还没到位，甚至连融合都谈不上，一个真正好用的企业级区块链底层都还没到位，就别提什么高效的交易网络了。所以对很多人来说，现在的确是有一个锤子，但是不知道能干什么，怎么用。

中场休息，说说我看见了的

2018 年是区块链崛起的一年，也是密码学货币和区块链的一个标志性分水岭的时间点，很荣幸，我们在这件事上做了不少贡献。

我放了两张图，是过去两年百度指数上的比特币和区块链，和 Google Trends 上的 HyperLedger。

从图中可以看出，企业对区块链的热度从 2016 年以来一直在升温，2018 年受币圈的影响并没有那么大，从我们过去一年的经历来看，企业对区块链的热情在 2018 年反而有一直在上升的趋势。这个趋势 2019 年还将持续，并且我认为会持续很长一段时间。

举个例子说说我为什么这么认为。

2017 年，我们认真的实践了一件事情：用区块链去重塑溯源，为溯源赋上它真正应该有的商业价值。为了这件事，我们和北大荒合作了全球第一个区块链大农场，从 2016 年开始花了一年多的时间认真的调研每一个细节。
起初，没有人认为这件事会成功，很多人都说这里面无法解决的问题太多了。但我们坚持下来，并且把它做完了，我们在用区块链量化并且优化一个具体的细分交易网络里的成本构成。

等我们做完这个项目，大家仿佛第一次看到原来区块链是真的可以落地的，其实只不过是我们在一个略新一点的领域里做了些探索，论证了些许的可行性。

于是，2018 年变成了区块链在溯源领域爆发的一年。京东、天猫、蚂蚁金服等等大厂先后跟进，各种初创的区块链溯源平台也层出不穷，当然，也毫不意外的充斥了大量来蹭热点的。

从我们的实践来看，未来的很长一段时间里，区块链将会在供应链里扮演越来越重要的角色。得益于不可篡改的特性，链条生态中的交易摩擦成本会极大的下降；同时，背靠智能合约，供应链中建立信任的效率会极大的提升。这些都将极大的打开供应链上的枷锁。

在金融领域，区块链必将会重构整个信任体系，当你的一次转账行为不再是因为信任背后的银行，不再是因为信任 BAT 这样的巨头，当你的一笔交易行为不再是因为信任背后的三方存管，不再是因为信任背后的各种担保主体，整个商业运转的成本将空前的降低。

下一个十年，不妨做几个预测

先说一个简单的好理解的，未来，信息除了会附带摘要签名，还将附带一份时间证明。以邮件来举个例子，你想证明是你写的怎么办，这个简单，只要加一个 GPG 签名就可以了，足够证明不会被别人伪造。但怎么证明时间呢？可能需要一个中心的服务器，把邮件发出去，让这个服务器帮你证明。那如果服务器作假呢？如果你 1 月份写的，6 月份才想发出去，怎么证明呢？这在区块链上有个很好的答案，你加一个链上证明，就可以证明这封邮件写在 2019 年 1 月，不会更早，也不是后期捏造，并且，你可以一直保密，直到需要的时候才公开。

由此展开，类似的技术未来将全面融入各种数据体系，AWS 去年发布的 QLDB 就是个很好的例子，证明历史属性这件事情是个强需求，但和时间属性的证明仍然还有一段距离。试想一下，如果上市公司的财务报表背后依托的是一个不可篡改、历史完备并且可以证明时间属性的技术体系，先不说公信力的变化，审计成本将极大的降低，金融系统对应的风控模型也将会出现极大的变化。

再继续展开，去中心化的智能合约将建立一个新时代的合约体系，一个趋势是履约条件的全面数字化，另一个趋势是履约这个行为的去中心化，不仅仅是自动化。也举一个例子，先不说远到金融资产的交割，近到上班打卡领工资这些还远没达到自动化的事情，我们可以认为像买电影票、买火车票这种行为，现在已经是一个非常自动化的履约过程，但非常中心化，平台的信任背书很重要。如果你要创业做一个类似的平台，如何让用户相信在你这买票是没有风险，这个成本现在还非常的高。未来，借助区块链和智能合约，人人都可以很低成本的创建一个交易平台的时候，现在这些平台的日子都将很艰难。好处嘛，电影票便宜了，开心不。

我一直还持有的一个观点是，区块链和当下的应用和技术体系的融合度还很低，都还是相对比较独立的存在，还有很大的提升空间。应用上大家一直都预期着区块链领域能够爆发一个杀手级应用，过去的很多探索都是基于此的非常独立的探索，所以会有很多关于区块链革命的论调。但从这两年的趋势来看，应用层面已经出现了融合的趋势，未来随着业界对区块链理解的加深，这个趋势必然会加速。从表象上来讲，区块链会和今天的云计算、大数据、AI、物联网、5G 等等革命性的技术一样，最终成为人们日常生活的一部分，就像今天移动互联网已经无处不在，不经意间完全改变了我们的生活。

相比应用层面，技术层面这个趋势还相对滞后，区块链相关技术架构仍然是比较独立的存在，被赋予了太多的技术使命，这个再未来也会出现很大的变化。换一个角度讲，区块链会和关系代数、虚拟化、非结构化存储、机器学习等等底层技术一样，成为一项技术标配，某种意义上既为未来的全栈工程师们觉得痛苦，又为他们感到幸福。

下半场，风随时会来

都看到这了，我们现在到底该做点什么。

首先肯定是要坚持创新，改进和优化很重要，能带来数量级提升的才是质变。区块链可以带来质变的领域很多。过去这两年，溯源、供应链金融是两个比较热门的区块链应用领域，涌现了众多的案例，其中不乏主流大厂和大型金融机构的身影。此外，法律存证、跨境清结算等也一直是区块链活跃的领域。目前，业界还普遍看好区块链在物流、版权、众筹、公益慈善、医疗、数字身份等众多链条复杂又极其依赖信任成本的领域的潜力，让我们一起来努力。

其次是要坚持在场景里锤炼技术，市场无法凭空创造，技术也一样，过去这么多年无一例外，伟大的技术都是在伟大的场景里锤炼出来的。

再次是区块链真的不是万能的，十八般武艺都得用上。一方面，区块链涉及的技术栈非常广，比如密码学、结构化存储、P2P 网络、虚拟机等等，每一块都可以深度展开；另一方面，区块链可以融入的技术体系也非常广，像 DAG、分布式一致性、零知识证明、安全计算等等，未来会涌现出越来越多的融合技术，还请拥抱开源并且回馈开源。技术之外，形成质变还需要很多产品思维、商业逻辑的融合，以及趋势的变化，这些都不是靠区块链一个技术能够打通的。

最后，祝大家完美的收割下半场，风，随时会来。

写在文末：
细心的读者可能会发现，文中我一直用的都是密码学货币，不是虚拟货币也不是数字货币，其实没啥，纯属个人洁癖，没有特殊含义。

作者简介

谢文杰，智链万源 CTO，联合创始人。曾就职于百度公有云、金山云、百度移动事业部、搜狐等公司，任产品及研发高管。拥有十余年软件产品技术架构经验，从零构建金山云云计算产品、搜狐 WebIM 亿级 PV 产品技术，对云计算、移动 APP、手游、社交、P2P 网络等多种类型产品的开发运营均有深度研究。从 2014 年开始研究区块链，对众多主流区块链技术平台如 HyperLedger Fabric、Corda、Ethereum、Ripple、Bitcoin 等均有深入研究，专注于区块链技术的产业结合及在海量数据以及高性能、高可用软件体系内的应用实践。

第183讲 | 薛文植：技术管理的本质—要做尊重人性的管理

你好，我叫 Nick ，中文名是薛文植，在电商和零售行业里摸爬滚打了 7、8 年，现在在便利蜂负责整体门店的智能化。这些年踩了很多坑，但同时也对管理有了一些心得，今天就想跟你分享一些自己在管理方面的实践经验，希望能对你有所帮助。

现在这个时代，对管理者的要求非常高。作为一名优秀的技术负责人，一定要给团队指出正确的方向，必须同时要懂业务、懂产品、懂技术，但是更重要的是对于技术团队成员的管理，人才才是整个公司的根本。

对于管理，我们要认识到技术人才首先是普通人，需要遵循一些对人才管理的基本原则，也就是尊重人性的管理。我们需要从人的本质上去理解大家的需求，这样才能更好的保持团队的活力。

1. 满足员工最本质的需求，而不是永远画大饼

首先，我们要了解员工到底想要什么，来公司的诉求是什么。这些年有太多的创业公司给员工画大饼，最常见的比如承诺期权、股票等，激励大家为梦想奋斗。其实如今大家早已看穿这样的“大饼”模式，员工更看重实实在在的价值，如工资、晋升、前途等。很多技术人也非常看重自己能力的成长，比如能不能做更核心的项目，能不能带更大的团队等，这些都是很多人的第一需求。如果员工觉得自己在这里没有成长，他们自然会选择离开。

而关于期权和股票，有当然是锦上添花，但上市和被收购的公司毕竟是少数，大多数公司的股票是无法兑现的。因此作为管理者，不能用未来可能会有的股票来压低员工现有的其他价值，该给的现在就要给，大家都要养家糊口。如果只是画大饼，而不给员工提供实际利益获得与成长机会，这种团队是不会长久的。

2. 知道如何去批评员工才能让人更容易接受

人都是有自尊心的，有些管理者会认为，在发现员工犯错误的时候，作为领导可以毫不留情面的批评指责，甚至辱骂。这是一个非常错误的观念。我们批评员工的目的是让对方认识到自己的错误，然后接受并且改正。如果采用相对粗暴的方式来批评别人，员工可能会觉得无地自容，但这不但无法达到让其改正的目的，反而会让其更加抵触。当然这并不是表示员工有错误你不指出，而是可以采用相对柔和一点的方式，这样效果会更好。

我比较青睐“三明治”式的谈话方式，就是先扬后抑再平和的节奏。举个谈话的例子，我们可以对员工说：“最近 XXX 方面做的还行，但是你在某某某方面还需要改进（然后具体发散需要改进的内容），不过我们还是有很大进步空间的不是吗？”当然这只是我个人喜欢的一个风格，供大家参考。

3. 对员工的预期要事先表达清楚

这是很多管理者容易犯的毛病。比如很多领导会对员工说：“关于 XX 事情，我以为你应该知道。”要知道，揣测老板的意图，是很多员工最不想做的事情。如果你对该员工有期许，请直接告诉他，比如设置好目标节点，并且告知员工达成目标之后的结果或收益。因为员工不是你肚子里的蛔虫，不可能知道你的想法，同时猜测想法本身就是一件非常消耗精力的事情。透明的做事方式能够减少内耗，也能够让员工有一个非常清晰的目标，事半功倍，所以作为管理者，你需要对员工提前表达你的预期。

举个例子，如果你对某位员工的做事方式或结果不是特别满意，一定要在第一时间与对方沟通。原因有二，第一，有可能是其他因素导致了该员工做事没有达到预期，而你不知情；第二，如果你提前沟通了，员工也能够清楚自己该改进的方向，而不是一直持续现状，这种结果不论是对员工个人还是于公司层面而言都是不利的。

4. 对人公平，以结果为主

管理者要对所有员工都一视同仁，尤其是在最终绩效考核的时候，一定要以实际表现为最终衡量标准。这点虽然是普罗大众都有认知的常识，但实际执行起来，却不是每个人都能做到的。技术人才可能都有自己的脾气，如果与管理者性格不和或平时对技术的争论较多，该员工是否还能够被客观的评价，这点是很重要的。

管理者不能因为个人喜好而对与自己趣味相投的员工有特殊优待，同时也不该对与自己相处平平的员工给予不公待遇。互联网行业变化非常快，因此对员工的创新力有更多的要求，而有创新力的顶级人才大多有自己的脾气，毕竟能力强就是资本，但这并不影响他们为公司创造价值，因此，如果我们把员工的实际产出作为衡量其表现的主要标准，那员工才能被公平对待，这样大家也能对管理者有充分的信任。

5. 并不是每个人都想当管理者，提拔干部需要看个人特质

事实上，可能只有 10% 的人愿意成为管理者，90% 的人其实更愿意过简单的生活。管理团队和专研技术，其实需要不同的技能组合，所承受的工作压力也是不同的。带团队或者带项目，有时候需要处理很多琐碎繁杂的事情，同时需要考虑到更多更广的细节，而专研技术可能需要向某个方向，非常深入的往下走。有时候你让一些技术厉害的同学去带团队，如果其本人的特质更适合做点而不是面，可能会适得其反。不但团队的整体成绩不出彩，项目进度也可能跟不上，而且被放在该位置上的同学也会灰心丧气，产生离开的念头。

因此，提拔干部一定要因人而异，领导力有时候和性格有极大的相关。有些人的特质天生就更适合管理，比如说开朗、善于沟通的人，其实比较容易胜任带人的职位，因为带团队就需要和不同的内外部成员进行有效的协调和沟通，反之，如果一位闷声不响的同学被强拉到管理岗，他反而可能会觉得这是一种受罪。再举个例子，管理需要一定的决断力和气场，但很多同学其实是相对的“老好人”，当被拉到某一个管理岗位的时候，相对偏“软”的性格会导致一些管理上的劣势，不一定能镇得住团队其他人。

6. 人都喜欢相对简单的环境，尤其技术人才

我认为作为技术团队的负责人，主要的工作其实是给团队成员创造一个更好的舞台，让他们能够在这个舞台上更好地实现自己的价值。很多技术人都喜欢相对简单的环境，因为技术的世界本身是最纯粹直接的，“不服看代码”就是技术人才最主要的态度。然而有时候公司内部或外部会有很多的压力和噪声，不管是外部业务的压力，部门的斗争，还是团队之间的甩锅和扯皮，都会严重干扰到技术人才的工作。太复杂或者效率太低的氛围，会让他们感到异常的疲惫。因此，把流程制定清楚，合理分工，提高团队之间的配合效率，让工作环境相对融洽，这能极大地提升技术人工作的整体效率。

总的来说，人性其实都是一样的，我们从更根本的去了解人的需求，这样会更容易摸到规律。我非常崇尚最近很火的“第一性原理思维”，解决或者思考问题都需要从本质出发，有时候甚至要回归到物理学的底层逻辑去。那么管理，其实也需要我们静下心来，思考人性的本质和人的根本诉求，这样我们才能更好的管理团队。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

薛文植（Nick），TGO 鲲鹏会会员，便利蜂智慧零售负责人，曾任多点 Dmall 高级总监，酷派集团互联网中心 vp，简 24 联合创始人。深耕电商领域多年，是名副其实的电商精英。

第184讲 | 狼叔：2019年前端和Node的未来—大前端篇（上）

你好，我是阿里巴巴前端技术专家狼叔，今天想跟你分享 2019 年我对前端和 Node 现状及未来发展趋势的理解。

我其实特别反感很多人说“前端娱乐圈”这种话，诚然，爆发式增长必然会带来焦点，但也不必过度解读，2018 年的几件大事儿我都了解，真的不是大家看到的那样的。学会辩证的看问题，用心去体味背后的趋势，我想这比所谓的“正直”更有价值，我更希望大家能够坚持学习，保持思辨和平和。

大前端

2018 年的事儿特别多，从 React v16 普及，到 jQuery 被 GitHub 下掉完成阶段性历史使命，在唏嘘之外，版本帝 Angular 又发布了 v6 和 v7 两个版本。这些其实都不算啥大新闻，反观三大框架，写法越来越像，越来越贴近 WebComponents 标准，而周边应用层面的封装已经开始指数级增长。小程序是今年最火的技术，接连出现，快应用也想分一杯羹。PWA 进入稳定期，尤其是 PWA 桌面版，可以让我们更好的看清楚 PC 桌面版开发的全貌。移动端还是以强运营为主，各大公司都开始不再 all in 移动，开始重视多端并进，到了开始拼细节的阶段了。TypeScript 全面开花，GraphQL 蠢蠢欲动，WebAssembly 更是打开了浏览器上多语言的大门。所有的这一切都在暗示，浏览器即操作系统，你能想象到未来前端的样子么？下面跟着我一一进行解读吧。

三大框架标准化

有朋友吐槽：“Vue 的特点就是上手快，初期相当好用，但如果接手一个别人写的 Vue 项目，再和 React 对比一下，你会感谢 React 的”。但当 Vue 3.0 发布之后，估计他就不会这样说了。因为 Vue 3 的 Class API 和 React 的写法几乎是一模一样的，这个改动不是 Proxy 和 TypeScript，而是支持原生 Class 的写法。你用 Class 来写，那代码和 React 写法几乎是一模一样的！

import Vue from 'vue'

class App extends Vue.Component {

  count = 0

  up() {

    this.count++

  }

  down() {

    this.count--

  }

  render() {

    return (

      <div>

        <h1>{this.count}</h1>

        <button onClick={() => this.up()}>+</button>

        <button onClick={() => this.down()}>-</button>

      </div>

    )

  }

}

Vue.render(<App />, document.body as HTMLElement)

从上面的讨论可以看出，前端三大框架已经趋于平稳化、标准化，在我看来未来是 WebComponents 的。

WebComponents 是规范，最早最知名的一个是 Google 主推的 JavaScript 库 Polymer，它可帮助我们创建自定义的可重用 HTML 元素，并使用它们来构建高性能、可维护的 App。在 I/O 大会上，Google 推出了 Polymer 3.0，Polymer 3.0 致力于将 Web 组件的生态系统从 HUML Imports 转移到 ES Modules，包管理系统将支持 npm，这使你更容易将基于 Polymer 的 Web 组件和你喜欢的工具、框架协同使用。

 <script src="node_modules/@webcomponents/webcomponents-loader.js"></script>

  <script type="module">

    import {PolymerElement, html} from '@polymer/polymer';

    class MyElement extends PolymerElement {

      static get properties() { return { mood: String }}

      static get template() {

        return html`

          <style> .mood { color: green; } </style>

          Web Components are <span class="mood">[[mood]]</span>!

        `;

      }

    }

    customElements.define('my-element', MyElement);

  </script>

  <my-element mood="happy"></my-element>

另外还有 2 个项目具有一定的参考价值：

1.Rax 也提供了一个名为atag的 UI WebComponents 库。
2.LitElement 是一个简单的轻量级的快速创建 WebComponents 的基类，可以理解成是 Polymer 最小的实现版本。

LitElement 主要的特性包括 WebComponent 生命周期模型支持和单向的数据绑定模型。它遵守 WebComponents 标准，使用 lit-html 模块这个快速的 HTML 渲染引擎定义和渲染 HTML 模板。最重要的是它对浏览器兼容性非常好，对主流浏览器都能有非常好的支持。由于 LitHtml 基于 tagged template，结合 ES6 中的 template，使得它无需预编译、预处理，就能获得浏览器原生支持，并且扩展能力更强，性能更好。

import { LitElement, html } from '@polymer/lit-element';

// Create your custom component

class CustomGreeting extends LitElement {

  // Declare properties

  static get properties() {

    return {

      name: { type: String }

    };

  }

  // Initialize properties

  constructor() {

    super();

    this.name = 'World';

  }

  // Define a template

  render() {

    return html`<p>Hello, ${this.name}!</p>`;

  }

}

// Register the element with the browser

customElements.define('custom-greeting', CustomGreeting);

是不是看着更眼熟了？

《三国演义》里有这样一句：“话说天下大势，分久必合，合久必分。周末七国分争，并入于秦。及秦灭之后，楚、汉分争，又并入于汉。汉朝自高祖斩白蛇而起义，一统天下，后来光武中兴，传至献帝，遂分为三国。”

前端从 2014 年到 2017 年是混战期，得益于 Node.js 的辅助加成，外加各种前端优秀的创意和实践，使得 React/Vue/Angular 三足鼎立。无论 React 发布 v16，增加 Fiber 和 Hooks，还是 Vue 3.0 发布，其实最终都是朝着 W3C WebComponents 标准走。一言以蔽之，Follow 标准是趋势，如果能够引领标准，那将是框架的无上荣耀。

我们可以参考一下技术成熟度曲线（Hype Cycle -Wikipedia），这个曲线把技术发展分成五个步骤：【科技诞生的促动期】->【过高期望的峰值】-> 【泡沫化的底谷期】 -> 【稳步爬升的光明期】 -> 【实质生产的高原期】。从前端现在的热度来看，应该是处于从第三阶段【泡沫化的底谷期】到第四阶段【稳步爬升的光明期】的爬坡过程，创新不会那么多，更多的是偏于应用层的内容。

对于当下的前端发展情况，我其实是有隐忧的。当年 Java 世界曾经搞各种 GUI，创造了 MVC 模式，结果没火，没想到到了 Web 开发领域，MVC 成了基本约定。之后 Model 1 和 Model 2 等企业开发模型渐渐成熟，出现了 Struts、Spring、Hibernate 三大框架。在之后很长的一段时间里，Java 程序员都是言必称“SSH”。再之后 Spring 一家独大，一统江湖，恐怕今天还记得 EJB 的人已经不多了。框架一旦稳定，就会有大量培训跟进，导致规模化开发。这是把双刃剑，能满足企业开发和招人的问题，但也给创新探索领域上了枷锁。

应用层封装进入爆发期

框架和工程化基本探索稳定后，大家就开始思考如何更好的用，更简单的用。目前，各家大厂都在前端技术栈思考如何选型和降低成本，统一技术栈。

举个例子 Umi，如下图所示。

Umi 就是一套零配置（约定高于配制），按最佳实践进行开发的，开箱即用的前端框架: React 全家桶 + dva + jest + antd (mobile) + less + eslint。

从上图中可以看出，Umi 已经思考的相对全面，从技术选型、构建到多端输出、性能优化、发布等方面进行了拆分，使得 Umi 的边界更为清晰，是前端最佳实践，目前大多数前端组都是类似的实现方式。说白了，Umi 和 create-react-app（cra）类似，就是现有技术栈的组合，封装细节，让开发者用起来更简单，只写业务代码就可以了。

零配置就是默认选型都给你做好了。

开箱即用就是技术栈都固化了。

约定大于配置，开发模式也固化好了。

Umi 的核心是 af-webpack 模块，它封装了 Webpack 和各种插件，把 webpack-dev-server 等 Node.js 模块直接打包进去，同时对配置做了更好的处理以及插件化。af-webpack 核心是 webpack-chain 模块，通过链式写法来修改 Webpack 配置，使得 af-webpack 极为灵活。其实以 React 全家桶为例，开发者最大的负担就是 Webpack 工程化构建。关于 Webpack 的封装实践有很多，比如知名的还有 YKit、EasyWebpack 等。

YKit 是去哪儿开源的 Webpack，内置 Connect 作为 Web server，结合 dev 和 hot 中间件，对于多项目构建提效明显，对版本文件发布有不错的实践。

EasyWebpack 也是插件化，但对解决方案、boilerplate 等做了非常多的集成，比如 Egg 的 SSR 是有深入思考的，尽管不赞同这种做法。

另外，在 create-react-app（cra）项目里使用的是 react-scripts 作为启动脚本，它和 egg-scripts 类似，也是通过约定，隐藏具体实现细节，让开发者不需要关注构建。在未来，类似的封装还会有更多的封装，并且更偏于应用层面。

PWA 进入稳定期

PWA 和 native app（移动应用）的核心区别在于以下几点：

1. 安装：PWA 是一个不需要下载安装即可使用的应用。
2. 缓存使用：native app 主要是对 sqlite 缓存，以及文件读写操作，而 PWA 对缓存数据库操作支持的非常好，足以应对各种场景。
3. 基本能力补齐，比如推送。

现在 PWA 已经支持的很好了，唯一麻烦的是缓存策略和发版比较麻烦，应用轻量化的趋势已经很明朗了。下面讲一下 PWA 的一些关键点。

1. 通用本地存储的解决方案 Workbox

Workbox 是 GoogleChrome 团队推出的一套 Web App 静态资源和请求结果本地存储的解决方案，该解决方案包含一些 JS 库和构建工具，Workbox 背后则是 Service Worker 和 Cache API 等技术和标准在驱动。在 Workbox 之前，GoogleChrome 团队较早时间推出过 sw-precache 和 sw-toolbox 库，但骂声很多，直到 Workbox 才真正诞生了能方便统一的处理离线能力的更完美的方案。

Workbox 现在已经发布到了 3.0 版本，不管你的站点是用何种方式构建的，它都可以为你的站点提供离线访问能力，几乎不用考虑太多的具体实现，只用做一些配置就可以。就算你不考虑离线能力，它也能让你的站点访问速度更快。

比如星巴克的 PWA 应用，对缓存的应用高达 41.3mb。这是浏览器端非常大的突破，尽管没啥新技术。

2.PWA 桌面版

纵观 PC 桌面端的发展过程，早期 Delphi/VB/VF/VC 等构建起的 c/s 时代，即使到今天依然有很大的量。最近两年，随着 Atom/VSCode 的火爆，带动了 node webkit 相关模块的爆发，比如 NW.js 和 Electron 等。通过 Web 技术来构建 pc client，确实是省时省力，用户体验也非常好，比如钉钉客户端、石墨文档客户端等，最主要的是可以统一技术栈，比如某些算法，用 JS 写一次，之后可以到前端、node、pc client 等多处复用。当然更好的是使用 Web 技术进行开发，不需要加壳打包，PWA 桌面版就是这样的技术。

接下来就具体聊一下桌面端的 3 个发展阶段。

第一阶段：原生开发 Native

早年的 VB/VF/VC/Delphi 等原生开发方式，到后来出现 QT 类的跨平台软件，但依然可以理解成是原生开发。

第二阶段：混搭开发 Hybrid

谷歌于 2008 年 9 月 2 日首次发布了 Chrome 浏览器，Node.js 是 Ryan Dahl 于 2009 年发布的，他把 V8 引擎（Chrome 核心 JavaScript 引擎）搬到了后端，使用 js 编写服务器程序变为现实。随后 npm 发展极为迅猛，跨平台技术也突飞猛进，出现了 NW.js 这样的轻量级跨平台框架，基于 Chromium（Chrome 开源版本） + Node.js，使得 PC 桌面端能够通过 Web 开发技术开发，最终打包编译成各个平台支持的应用格式，给 PC 桌面开发带来了太多的可能性。

而 Atom 是 GitHub 在 2014 年发布的一款基于 Web 技术构建的文本编辑器，其中 atom-shell，也就是后来的 Electron，是和 NW.js 类似的技术。它允许使用 Node.js（作为后端）和 Chromium（作为前端）来完成桌面 GUI 应用程序的开发。Chromium 提供了渲染页面和响应用户交互的能力，而 Node.js 提供了访问本地文件系统和网络的能力，也可以使用 NPM 上的几十万个第三方包。在此基础之上，Electron 还提供了 Mac、Windows、Linux 三个平台上的一些原生 API，例如全局快捷键、文件选择框、托盘图标和通知、剪贴板、菜单栏等。

Erich Gamma 老爷子设计的 Monaco／VS Code，同样基于 Electron，但性能比 Atom 强多了。VS Code 会先启动一个后台进程，也就是 Electron 的主进程，它负责编辑器的生命周期管理、进程间通讯、UI 插件管理、升级和配置管理等。后台进程会启动一个（或多个）渲染进程，用于展示编辑器窗口，它负责编辑器的整个 UI 部分，包括组件、主题、布局管理等等。每个编辑器窗口都会启动一个 Node.JS 子进程作为插件的宿主进程，在独立进程里跑插件逻辑，然后通过事件或者回调的方式通知 Renderer 结果，避免了 Renderer 的渲染被插件中 JS 逻辑阻塞。

演进过程：chrome > Node.js > nw.js > atom(electron) > vs code

在第二阶段里，我们可以看到 PC 桌面端以 Web 开发技术作为核心，以浏览器内核作为跨平台核心，最终将 Web 开发的代码和浏览器内核打包。这样做的好处是前端开发相对简单，相对于 C++ 等语言更为方便，另外从成本上考虑，也是极为划算的。

如今，很多应用都开始基于 Electron 构建，比如微信小程序 ide、微信 pc 版本等，另外非常令人激动的是，2018 年 10 月 18 日，迅雷论坛发文称新版（从迅雷 X 10.1 版本开始）采用 Electron 软件框架完全重写了迅雷主界面。使用新框架的迅雷 X 可以完美支持 2K、4K 等高清显示屏，界面中的文字渲染也更加清晰锐利。从技术层面来说，新框架的界面绘制、事件处理等方面比老框架更加灵活高效，因此界面的流畅度也显著优于老框架的迅雷。

第三阶段：PWA 桌面版

王国维在《人间词话》中提出“隔与不隔”这一文学命题，这个问题在开发领域也是存在的。明明是 Web 开发的，为什么还要打包加壳呢？除了体积非常大以外，使用安装也极为麻烦。

Spotify 的 PWA 桌面版应用体验是非常好的，在 mac 上丝般顺滑。

2018 年 Google IO 大会上，微软宣布 win10 全力拥抱 PWA，通过爬虫爬取 PWA 页面，并将其转换为 Appx，继而在其应用商店里提供应用，体验和原生 Native 应用非常相近，对此我非常看好。

浏览器有着超强的缓存能力，外加 PWA 其他功能，使得浏览器上的 PWA 应用能够取得媲美 Native 应用的性能。在浏览器里可以直接打开，无需加壳，很明显这是极为方便的。

PWA 必然会改变前端与移动端之间的格局，再加之 AOT(ahead-of-time) 与 WebAssembly 为 JS 带来的性能上的突破，JavaScript 将撼动所有领域，从移动端（PWA）到桌面应用、物联网、VR、AR、游戏乃至人工智能等等。

Google 接下来会大力推进 PWA 的桌面版，再加上 win10 和 Chrome 加持，Web 应用无需加壳就能达到近乎原生的体验，前端的领域再一次被拓宽，未来真的可以大胆的想想。

很多人问 PWA 在国内为什么感觉不火，原因很简单，PWA 在弱网环境下表现极好，但中国的网络是全球最好的，所以 PWA 其实没有给我们带来那么大的收益。不过当做一个补位方案也挺好的，毕竟 2G/3G 还有点量，另外在服务器渲染 SSR 上，PWA 也能够起到很好的效果。

小程序火爆

如果说和 PWA 比较像的，大概就是小程序了，小程序也可以说是今年最火的技术。

微信小程序的下一步计划，支持 NPM、小程序云、可视化编程、支持分包等，听起来很美好，但坑依然不少。小程序原生提供的 DSL 不够好用，所以就有了上层开发框架或者脚手架来优化开发效率，目前比较主流的有 3 个：

今年还冒出了微信小程序之外的头条小程序、支付宝小程序、百度智能小程序等，未来还会有很多。同时，手机厂商大概是看到了小程序对其应用商店的威胁，小米、华为、OPPO、vivo 等九大国内手机厂商联手成立了“快应用联盟”，基于 react-native 技术栈，整体也很不错，尤其是天猫调用菜鸟裹裹的快应用，安卓下有非常好的体验。相较而言，微信是基于 Webview 的，而快应用使用的是原生渲染方案，其他家也大抵如此。

其实 5G 时代很快就到了，大家可以畅想一下，在网速、内存和 CPU 更高的情况下，5G 每秒最高下载速度高达 1.4G，秒下 PWA 或小程序应用，到底是离线，还是在线，犹未可知吧。

前端能讲的东西实在太多了，但受限于篇幅，本文只能先简单跟你分享 React/Vue/Angular 三大框架标准化、应用层封装进入爆发期、PWA 进入稳定期、小程序火爆等方面的内容。下一篇文章中，我将继续跟你聊聊移动端局面、多端拉齐的必然性等内容，以及 2019 年不可忽视的 TypeScript 和 WebAssembly 这两大技术，欢迎继续关注，也欢迎留言与我多多交流。

作者简介

狼叔（网名 i5ting），现为阿里巴巴前端技术专家，Node.js 技术布道者，Node 全栈公众号运营者。曾就职于去哪儿、新浪、网秦，做过前端、后端、数据分析，是一名全栈技术的实践者，目前主要关注技术架构和团队梯队建设方向。即将出版《狼书》3 卷。

第185讲 | 狼叔：2019年前端和Node的未来—大前端篇（下）

你好，我是阿里巴巴前端技术专家狼叔，上一篇文章中，我与你分享了 React/Vue/Angular 三大框架标准化、应用层封装进入爆发期、PWA 进入稳定期、小程序火爆等前端趋势，今天，我将继续跟你聊聊移动端局面、多端拉齐的必然性等内容，以及 2019 年不可忽视的 TypeScript 和 WebAssembly 这两大技术。

多端拉齐，并重用户体验

在 AI 时代，没有“端”的支持可以么？明显是不可以的。首先感谢苹果，将用户体验提升到了前无古人的位置。移动互联网兴起后，PC Web 日渐没落。我个人非常欣赏玉伯，在当年无线 ALL IN 战略中，他还是选择留下来继续做 PC Web 的前端。不过，虽然很多公司的重点转向无线，但 PC 业务也一直没停，这是很多公司的现状，也是客观事实。那么，PC 端这样的“老古董”的出路到底在哪里呢？

1. 我们可以利用 PC/H5 快速发版本的优势，快速验证 AI 算法，继而为移动端提供更好的模型和数据上的支撑。

2. 多端对齐，打好组合拳。既然不能在移动端有更大的突破，大家只能在细节上血拼。

大家的战场已经不是点了，已经升级到打组合策略的阶段了。未来一定是多端拉齐，并重用户体验的。

今天的大前端，除了 Web 外，还包括各种端，比如移动端、OTT，甚至是一些新的物联网设备。我们有理由相信 Chrome OS 当年的远见：“给我一个浏览器，我就能给你一个世界。”如果说的苟且一点：“给我一个 Webview，我就能给你一个世界。”

TypeScript

我之前就非常关注 TypeScript，但迟迟未下定决心在团队内落地。今年 1 月份北京 Node Party 上组了个局，和几位嘉宾一起聊了一下，确认提效非常明显，落地难度也不大，大家一致认为 2019 年 TypeScript 将有非常大的增长。本身前端团队变大，规模化编程也必然依赖类型系统和面向对象的，从这点上看，TypeScript 也是完胜的。

这里再简单介绍一下 TypeScript，它是有类型定义的 JavaScript 的超集，包括 ES5、ES5+ 和其他一些诸如反射、泛型、类型定义、命名空间等特征的集合，为了大规模 JavaScript 应用开发而生。复杂软件需要用复杂的设计，面向对象就是一种很好的设计方式，使用 TypeScript 的一大好处就是 TypeScript 提供了业界认可的类（ ES5+ 也支持）、泛型、封装、接口面向对象设计能力，以提升 JavaScript 的面向对象设计能力。市面上的框架也对 TypeScript 提供了非常好的支持。

1.React 对.tsx 支持非常好，比如我在 Midway controller 里支持 tsx 写法，这是非常大胆的，对于后面 react ssr 来说是一个极大便利；
2.Vue 从 v2.5.0 之后对 ts 支持就非常好；
3.Node.js Web 框架，尤其是 Egg.js 对 ts 支持非常好，当然还有更高级更专注的的 Midway 框架，Midway 基于 Egg 生态，同时提供 IoC 等高级玩法；

在使用 Webpack 编译前端应用式，通过 TypeScript-loader 可以很轻松地将 TypeScript 引入到 Webpack 中。有了 TypeScript-loader，就可以一边使用 TypeScript 编写新代码，一边零碎地更新老代码。毕竟 ts 是 js 超集，你有空就改，非强制，特别包容。

WebAssembly

WebAssembly 是一种新的字节码格式，目前主流浏览器都已经支持 WebAssembly。 和 JS 需要解释执行不同的是，WebAssembly 字节码和底层机器码很相似，可以快速装载运行，因此性能相对于 JS 解释执行而言有了极大的提升。 也就是说 WebAssembly 并不是一门编程语言，而是一份字节码标准，需要用高级编程语言编译出字节码放到 WebAssembly 虚拟机中才能运行， 浏览器厂商需要做的就是根据 WebAssembly 规范实现虚拟机。这很像 Java 早年的 Applet，能够让其他语言运行在浏览器里。Applet 是一种 Java 程序，它可以运行在支持 Java 的 Web 浏览器内。因为它有完整的 Java API 支持，所以 Applet 是一个全功能的 Java 应用程序。

有了 WebAssembly，在浏览器上可以跑任何语言。从 Coffee 到 TypeScript，到 Babel，这些都是需要转译为 js 才能被执行的，而 WebAssembly 是在浏览器里嵌入 vm，直接执行，不需要转译，执行效率自然高得多。

举个例子，AutoCAD 软件是由美国欧特克有限公司（Autodesk）出品的一款自动计算机辅助设计软件，可以用于绘制二维制图和基本三维设计。使用它时，无需懂得编程，即可自动制图，因此它在全球被广泛应用于土木建筑、装饰装潢、工业制图、工程制图、电子工业、服装加工等诸多领域。

AutoCAD 是由大量 C++ 代码编写的软件，经历了非常多的技术变革，从桌面到移动端再到 web。之前，InfoQ 上有一个演讲，题目是《AutoCAD & WebAssembly: Moving a 30 Year Code Base to the Web》，即通过 WebAssembly，让很多年代久远的 C++ 代码在 Web 上可以运行，并且保证了执行效率。

本来，我以为 WebAssembly 离我们很远，但在 2018 年 Google I/O 大会亲眼见到 AutoCad Web 应用后，非常震撼，效果如下图所示。

能够让如此庞大的项目跑在 Web 端，真的是非常了不起。通过 WebAssembly 技术，既能复用之前的 C++ 代码，又能完成 Web 化，这也许就是所谓的两全其美吧。

之前，全民直播的前端研发经理赵洋曾分享了 WebAssembly 在全民直播里对直播编解码方面的应用，效果也非常不错。

另外，许式伟在 ECUG Con 2018 上也分享了一个 Topic，主题是《再谈 Go 语言在前端的应用前景》，Go 的发展也遇到了瓶颈，专注后端开发是没办法让 Go 排到第一的，目前的一个方向是借助 GopherJS，将 Go 代码编译为 JS。这种实践是没问题的，和 Kotlin 类似，对于绝大部分 Go 用户也是非常好的。但问题在于，真正的前端不太可能换语言，目前连 Babel、ts 这种都折腾的心累，更何况切换到 Go。“求别更新了，老子学不动了”，这是大部分前端工程师的心声。

从 WebAssembly 的现状来看，对于复杂计算耗时的部分采用其他语言实现，确实是比较好的一种方式。从趋势上看，WebAssembly 让所有语言都能跑在浏览器上，浏览器上有了 vm，浏览器不就是操作系统了吗？

Chrome 的核心 JavaScript 引擎 V8 目前已包含了 Liftoff 这一新款 WebAssembly baseline 编译器。Liftoff 简单快速的代码生成器极大地提升了 WebAssembly 应用的启动速度。不过在桌面系统上，V8 依然会通过让 TurboFan 在后台重新编译代码的方式最终让代码运行性能达到峰值。目前，V8 v6.9 (Chrome 69) 中的 Liftoff 已经设置为默认工作状态，也可以显式地通过 --liftoff/–no-liftoff 或者 chrome://flags/#enable-webassembly-baseline 开关来控制。另外，Node.js v11 采用的 v8 引擎的 v7 版本，对 WebAssembly 支持更好，虽然这没啥意义，但练手还是蛮好的。

移动端

Flutter 是 Google 推出的帮助开发者在 Android 和 iOS 两个平台，同时开发高质量原生应用的全新移动 UI 框架，和 React-native/Weex 一样支持热更新。Flutter 使用 Google 自己家的 Dart 语言编写，刚好今年 Dart 2 也正式发布，不知道二者之间是否有关联。目前 Dart 主攻 Flutter 和 Web 两块，同时提供了 pub 包管理器，俨然是一门全新的语言，学习成本有些高。反观 TypeScript 就非常容易被接受，基于 npm 生态，兼容 ES 语法，因此，2019 年对 Dart 我还是会持观望态度。

除了不喜欢 Dart 外，Flutter 的其他方面都很好，在移动端现在强运营的背景下，支持热更新是必备能力。

关于 Weex，一边骂一边用，很无奈的一种状态。Weex 本身是好东西，捐给了 Apache，目前在孵化中，会有一个不错的未来。但社区维护的非常差，问题 issue 不及时，文档不更新。如果公司没有架构组，还是比较难搞定的。

不过也有很多不错的案例，比如 2018 年优酷双十一活动就是使用 Weex 开发的，效果非常不错。通过自建的可视化活动搭建平台，能够非常高效的完成开发，结合 App 内的缓存，整体效果比 H5 好的多。

我对 Weex 的看法是，以前 Weex 只是解决 H5 渲染效率的问题，但如今强运营的背景，使得 Weex 承载了非常多的内容，比如动画、游戏甚至是图形图像处理等。可以看到，未来 Weex 还会战略性的增加。

总结一下，2018 年大前端的现象：

1. 前端三大框架已趋于平稳，标准化，向 Web Components 看齐。
2. 应用层面开始进入过渡封装周边的阶段，很多细节都会埋在框架里。
3.PWA 平稳发展，兼容 4/5 浏览器，workbox 3 进一步简化开发，另外 PWA 桌面版已经开始兴起，未来会更多。
4. 多端受到重视，不再只是 all in mobile。
5.WebAssembly 让更多语言可以运行在浏览器上，AutoCAD 的 web 版是非常好的例子。
6. 强运营背景下，移动端以前端开发为主，已成定局。Flutter 局势暂不好说，还在观望中（主要是不喜欢 Dart）。
7.TypeScript 落地很好，包容性更好：React 对.tsx 支持非常好，Vue 从 v2.5.0 之后对 ts 支持就非常好，Node.js（尤其是 Egg.js、midway）对 ts 支持也非常好。
8.5G 时代快来了，互联网的长期在线情况有可能会被打破。本地设备即客户端，可以大胆的想想。对前端来说，本地 web 服务，辅助日常开发，类似于 je 这样的模块会越来越多。

终上所述，未来浏览器会越来越重要，Web Os 的概念正在慢慢落地。另外三大框架趋于稳定，写法上也越来越像，学习成本是降低的。但周边应用层面的封装还会是爆发式增长，更多复杂的细节会被包装到应用框架里，可能还有很多不一样的开发方式需要大家熟悉。

对于开发者而言，唯一不变的就是学习能力。掌握了学习能力就能够应对这些趋势变化，无论是在三大框架混战时代，还是后面周边封装时代都能很开心的“折腾”。哪怕有一天 AI 真的能够替人写代码，能应变的人自然也是不怕的。

关于大前端的现状和未来我就分享到这里，希望能对你有所帮助，而提到大前端，就不能忽视 Node.js，它在大前端布局里的意义非常重大，接下来的两篇文章，我将会着重分享一些跟 Node.js 结合比较密切的点，如 API 演进、GraphQL、SSR 等，欢迎继续关注，也欢迎留言与我多多交流。

作者简介

狼叔（网名 i5ting），现为阿里巴巴前端技术专家，Node.js 技术布道者，Node 全栈公众号运营者。曾就职于去哪儿、新浪、网秦，做过前端、后端、数据分析，是一名全栈技术的实践者，目前主要关注技术架构和团队梯队建设方向。即将出版《狼书》3 卷。

第186讲 | 赵晓光：如何培养团队竞争力（上）

你好，我是 Resideo 技术总监赵晓光，今天想跟大家聊聊团队能力培养的话题。“竞争力”常见的表达是能力的竞争，“能力”这个词在我们日常生活中太常见了，张三能力很强，李四能力一般，王五能力不足等等……但何为“能力”？我们也经常听到某人在某岗位上很有竞争力，那什么是“竞争力”呢？

我认为，首先，能力是指一个人或者一个团队保证工作成效，能正确执行工作任务的技能、知识、经验以及行为，并且这些都是可以论证且有因果关系的。我们经常讲知识就是力量，知识就是能力的一部分，而经验也可当作知识，但只有知识加上行动才是能力的体现。这也是我这样理解能力的原因。

其次，竞争力是能力的升级版或者专业版，更加注重于如何完成特定任务的能力。竞争力是指在完成具体任务时所体现的能力，如果抛开具体的任务，是无法谈竞争力的。因此，我对竞争力的理解是：在大部分场合，竞争力和能力是一回事儿，在对内的场景下一般讲能力，在对外的场景下一般讲竞争力；在合作的场景下讲的是能力，在角逐的场景下讲的是竞争力。无论能力还是竞争力，都有如下特点：

1. 需要针对特定任务，对于不同的工作任务，竞争力的要求是不一样的，进一步来讲，执行不同工作任务的能力要求也不一样，就如同 CEO 和 CTO 的能力要求不一样，软件架构师和软件工程师的技能要求不一样，销售和工程师的要求不一样，同理在研发团队内部，对于不同部门的能力要求也会不同；

2. 可重复，竞争力是保证我们所执行的工作能够完成的必要条件，并且要正确，有效率。如果只是勉强可以维持，错误百出，则不能称之为能力。就比如现在大家都在谈人工智能，如果某个公司的人脸识别算法仅仅是偶尔能够识别出一个人来，是不能称之为有人工智能能力的，同样的，如果一个团队不能在同一类任务中保持绩效的可持续及迭代提高是不能被认为有竞争力的；

3. 有显著的因果关系，竞争力是可以被显著的因果关系论证的。以 AI 团队为例，拥有多名算法专家，并且专家的技能被用于算法的设计、调优等，从而保证发布的算法都是业内领先的，那这可以称之为团队的能力和竞争力；相反，虽然团队有很多专家，但仅仅因为某次误打误撞撞到了一个看起来不错的模型，甚至都不知道为什么，我是不赞同称这个团队有竞争力的。这就是为什么竞争力不但要含有知识的部分，还要有行动的部分，能够正确的使用个人能力是团队竞争力的保障。

团队竞争力培养的关键因素

对于任何一个团队，在团队竞争力培养的这件事儿上，首先要有明确的定位，大致可以分为四个层面：

1. 明确团队的愿景、使命、价值观；

2. 明确团队当前的能力；

3. 制定发展战略；

4. 设定周期性目标以及关键结果。

明确团队的愿景、使命以及价值观

愿景、使命和价值观被称为团队核心三要素，是团队竞争力的基础。理想的团队应该有共同的价值观，为了共同目标在一起努力奋斗。

从实践角度来讲，如何确定三要素是需要集体来决定的，比如可以通过心无旁骛的 workshop 来确定，不过在开始之前最好先明确上一层组织架构的三要素，确保不与其冲突。

在团队确定三要素的过程中，团队成员可以通过德尔菲法来逐步明确价值观，也就是征求所有团队成员的意见，进行整理、归纳、统计，再匿名反馈给各个团队成员，再次征求意见，再集中，再反馈，直到最终获得一致。价值观是团队的行为准则，以及如何处理分歧的基础，是团队文化的核心，也是团队成员的考核标准之一。

而确定愿景需要回答三个问题：我们的团队是什么样的？我们将会成为什么样的团队？我们最终会是什么样的？在具体操作上可以逐步引导团队思考这些问题，可以通过公开讨论并投票的方式来确定，直至最终确定清晰明了无歧义的描述。

明确使命就是要在愿景的基础上确定职责所在，也就是要先做什么，是对团队自身以及关联团队甚至社会的承诺。因此，在实践中，一定要确保先明确核心价值观和愿景再明确使命，并且保证三者不相悖，这是团队拥有持续稳定竞争力的基础。

明确团队当前的能力

明确团队能力一般需要周期性的评估，以自我评估为主，对于关键能力的评估可以通过引入外部团队来做客观评价。举个例子，我所在的技术团队主要做两个方面的评估：管理资源回顾 (MRR) 和技术资源回顾 (TRR)。

管理资源回顾主要是评估个人能力，一般需要自上而下来操作：被评估人在当前职位的水平如何？潜在的继任者是谁，能力如何？如何调整被评估人的职位（升迁或准备升迁，还是保持）？对不合格（“能力”不够）的人采取何种措施等。

技术资源回顾主要针对团队的技术能力进行评估，自下而上，先做个人评估，再做小组评估，进而进行部门评估等。在个人评估方面，一般是自评和团队负责人评估相结合，用一个简单的表格就可以搞定，比如 Excel、Power 等。也可以对技能掌握程度定级，我的经验是采用 CDE， C 指的是 Capable, 基础级，也就是可以做这个任务； D 指的是 Developed, 专业级，是经过专门培养的，；E 指的是 Expert，专家级；为了统计上的需要，还引入了 X 表示不具备技能。同时，为了方便对技能水平进行量化，我们可以给每个等级一个分数，如 C=1，D=3，E=5，X=0。

如上图所示，在进行小组技能评估时，先要确定技能列表，这个列表一般由小组长指定的团队核心人员制定，也可以通过讨论的方式来选出相关技术技能。对于一个技术团队来讲，技能可以是核心的编程语言，可以是技术的方向如数据库、网络、算法、操作系统等，可以是重要的技术平台，也可以是核心的行业知识……

另外，针对每个人的技能评估，需要进行一对一的双向沟通，这样做的目的是：

1. 明确技能等级的确定方式，毕竟在不同的组织内部，对技能级别的定义会有偏差，通过双向沟通能够逐渐明晰技能的能力定义；

2. 查漏补缺，发现那些疏漏了的核心技能，在实践中，经常会发现有的团队成员具备一些对团队有益的技能，但没有被评估出来；

3. 给管理者和团队成员提供双向沟通的机会，一方面使团队成员更了解团队未来的人才需求，另一方面，管理者可以更好地了解团队中每个人的能力。因此双向沟通不能马虎。有些小组长会自以为已经很了解团队了，凭个人感觉打分，就很容易走入误区。

在逐级的汇总过程中，需要对技能进行泛化，例如我们可以把 CoAP、MQTT、AMQP 等针对应用领域泛化成 IoT 协议，把 AngularJS, VueJS, ReactJS 等针对应用场合泛化成 web 前端技术，但要对泛化的技能加上明确描述。值得注意的是，不要泛化非常核心的技能，例如，如果团队的核心技能是 Go 语言，那么在泛化的过程中，可以将其他编程语言泛化成一个技能，而 Go 始终作为核心技能，直到团队大到不再关注如此细节为止。在自下而上的过程中，每个层级的团队都要进行分析和总结工作，这个工作需要结合业务需求，并对技能进行两个维度的独立分类。一般我会用四象限的技能坐标图来分类，如下图：

横坐标是技能获得难易度，设定技能难度从 1 到 10 递增，比如技能 A 的难度为 5，然后依次对其他技能难易度打分，从易到难依次排列在横坐标上；纵坐标是技术对业务的影响力，按照同样的步骤打分，并根据影响力的大小依次从将技能排列在纵坐标上，最后根据打分情况，对技能进行总的分类：

第一象限的技能称为皇冠上的明珠 (Crown Jewelries)：这类技能对公司业务发展很重要，属于高精尖的技能，一般需要花费很大财力、物力、人力来培养或者招聘具备该技能的人才，具有此类技能的团队，在竞争者中就会处于相对领先的地位；

第二象限的技能属于畅销技能 (Marketable Skills)：对业务发展很重要，但相比第一象限，具备该技能的技术人才比较充裕，有明确的培养途径，在人才市场上也比较容易招聘到；

第三象限属于基础技能 (Commodity Skills)：技术人才很多或者掌握该象限技能相对容易，对业务也不是特别重要的技能。

第四象限的技能属于领先技能 (也叫利基技能，Niche Skills)：该象限的技术人才或者技能非常难培养，由于业务的调整或者开拓进度，目前只是满足小部分业务需求；

按照这样的方式进行分类后，就会对团队所需的技术技能定位有一个清晰的了解。这时再对之前采用技术资源回顾表收集的技术能力数据进行统计整理（一般应该采用工具生成），由个人数据变成团队数据，针对每个技能都可以得知团队当前的技术实力，同时也能更好地明确团队当前的能力缺口在什么地方。以及未来需要什么样的技术人才等，例如当前 AI 的专家有两人，但因为团队需要，一年内需要扩张到 5 人，这样就能更好的打造团队的竞争力。

受限于篇幅，今天先分享明确团队的愿景、使命、价值观和明确团队当前能力这两个层面的内容，提升团队竞争力的后两个层面，即制定发展战略以及设定周期性目标和关键结果将在本文下篇继续分享，欢迎持续关注，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

赵晓光，TGO 鲲鹏会会员，目前在 Resideo Technologies，Inc. 担任 Fellow 及 IPA 技术总监，负责技术创新、平台以及架构方向，同时负责技术战略以及路线图，团队竞争力培养以及人员培养等工作。此前在霍尼韦尔担任 Fellow 及技术总监工作。在软件开发领域有丰富经验，获得 Leading SAFe, Exin Devops Master, CSSLP 及 PMP 认证。

第187讲 | 赵晓光：如何培养团队竞争力（下）

你好，我是 Resideo 技术总监赵晓光，在上一篇文章中，我列出了四项团队竞争力培养的关键因素，即：明确团队的愿景、使命、价值观；明确团队当前能力；制定发展战略；设定周期性目标以及关键结果。前两项已经在上篇文章详细阐述，今天继续分享后两个关键因素，希望能带给你一些收获。

制定发展战略

在上一篇文章中，我们通过理资源回顾 (MRR) 和技术资源回顾 (TRR)。对团队能力进行了梳理，对团队人才有了比较全面的了解，以此作为支撑再开始做竞争力发展战略就会比较客观和直接。制定竞争力发展战略和计划（CDS(competency development strategy)/CDP(competency development plan)）需要综合考虑以下三点：

第一，愿景和使命，毋庸置疑，如果能力的培养不是为愿景和使命服务，就说明要么愿景和使命不正确，要么是能力培养策略有问题；

第二，产品（业务）路线图，竞争力的培养必须为业务的发展提供良好的后勤支撑和保障，如果没有清晰的产品路线图，谈能力就是无的之失，南辕北辙。而对团队能力有一定了解，也可以帮助产品路线图不断完善；

第三，技术路线图，技术路线图需要和产品路线图互相呼应，团队竞争力的培养，需要以技术路线图为蓝本，这个时候才会细化现状到目标之间的差距，进而制定后续的跟进计划。

一般来讲，综合考虑了这些主要因素，也明确关键技术领域的差距后，就可以制定发展策略了。针对不同分类的技能所做的策略也不一样，基本上可以归结为 Buy or Borrow。

对于高精尖技能，基本上通过组织内培养 / 培训或外部招聘等手段，不过具备这类技能的人才非常紧缺，外部招聘可能需要较大的投入，因此，在内部选择合适的人才进行培养反而是一个比较好的方式。这样做，一方面可以给内部人才提供很好的职业发展路线，另一方面，内部培养的人才对行业的理解比较深刻，更容易快速进入状态，这两种都属于 Buy 的方式。

我们也可以通过 Borrow 的方式来弥补竞争力的不足，例如寻找技术合作伙伴，来快速提升在该技术领域的能力，通过中长期的合作，逐步培养自己团队的实力。我个人的经验是，在这些前沿的技术领域，通过和高校合作是比较好的选择，因为没有业务竞争关系，不会形成利益冲突，同时，把技术转化为应用，对高校和企业来讲都是双赢的选择。

对于畅销类技能，如果需求不紧急，基本可以通过项目实践来逐步培养，把有潜力的人放到项目中通过传、帮、带的方式来迅速扩大人才规模，如果需求紧急，因为此类技能人才比较充足，就可以直接到市场上进行招聘。

针对上述两类技能的人才，需要特别指出的情况是，如果发现单点故障 SPF，也就是说某个技能只有一个人会，那么必须立即采取行动，否则一旦出现 SPF 意外，会对整个组织造成非常大的影响。因为团队竞争力的培养是为了未来持续发展做准备的，但是如果出现多个 SPF，可能就会没有未来。

对于领先技能，需要组织业务人员一起为技术团队掌握的领先技术找到更好的业务，这样做时一定要回答出“如果我们用 XX 技术来解决 XX 问题会怎样？”，一旦找到这个问题的答案，就会对业务拓展产生非常积极的影响。

对于基础技能，可以根据团队的实际情况来考虑，是否通过 Borrow 的方式来提升竞争力，也就是通过外包（也是合作的一种）或者合同工的方式把这些工作转移给第三方，让自己有更多精力着眼于核心能力的培养。另外，这些技能的地位并不是一成不变的，今天的高精尖技能，可能就是明天的基础技能，一定要用前瞻性视角去思考。

在提升竞争力的计划中，打造合适的学习型组织文化是比较重要的，团队中每个人都能够互相学习，会带动整体能力的提高。学习型文化不是靠发几本书可以解决的，要通过配套的行动以及激励来实现，比如定期的技术分享，鼓励团队和外部建立连接，参加论坛以及技术峰会等。需要补充的是，激励政策不仅仅有物质激励一种方式，能够帮助技术人员提升个人影响力也非常重要，例如在团队内部进行宣传，外部进行演讲，通过团队博客或者微信公众号鼓励大家写文章等，都是比较好的激励方式。

当完成了团队技术能力的分析以及确定了相应可采用的策略后，就需要把培养的战略再细化到人，一般通过两种方式：着重培养 FDP（focus development plan），普遍提高 IDP（individual development plan）。着重培养适用于那些被选出来的核心发展人员，需要和他的上级一起制定针对性的培养计划，要因材施教，不能千篇一律，有的人需要通过参加行业论坛峰会来拓展，有的人需要内部导师来指导，有的人需要在项目里面实践，还有的人需要通过培训来快速提高等。而普遍提高适用于整个团队技能的革新，让基础技能逐渐退出，整个团队不断的进行技能革新，普遍提高可以通过一些日常活动来提高，团队负责人需要制定大方向，再由各个小团队执行，例如大方向是将 Web 开发的技能由传统方式革新为 WebApp，这样各个小团队可以针对性地学习新技术，比如前端团队可能会学习 AngularJS，后端可能会优先学习 WebSocket 等等。

设定周期性目标以及关键结果

可能有人会认为设定目标和制定计划总是很容易的，如果你也这样认为，那么可能需要反思自己是否真正考虑了执行。竞争力培养是个长期的过程，不可能一蹴而就。需要定期的回顾并更新，一般的周期是：每隔一个季度进行 TRR 即技术资源回顾评估的更新，每半年进行 FDP 即着重培养战略的更新，每年进行技能图的更新。而在执行方面一般分为 3 个步骤：
1. 长期目标设定为 2 年，对两年后要达到的指标进行量化，就如同做 OKR 一样，设定 SMART 的考量结果；
2. 对两年的目标进行分解，分解为以半年为时间跨度的中期目标，对于中期目标的设定有一个有意思的参考指标：40%，也就是说半年后要完成两年目标的 40%；
3. 继续对半年的目标进行分解，设立关键监测点，来定期进行跟踪。

如何跟踪这些目标，推荐可以采用一个 A3 项目（关于 A3 受限于篇幅，请自行检索）的方式来进行。无论如何，计划没有变化快，之所以设定定期的监测，就是为了便于快速而敏捷的对变化作出反应。这样的变化有很多，例如重点人员的离职，业务的调整，甚至是设定的计划并不是特别有效，有需要随时改进和提高的地方等，技术团队要做的是及时调整计划，使之能够切实的支持业务发展，而不是按照一个原始目标一成不变的前进，最后与实际偏离过远。我们一般会用 PDCA 戴明环来形容这个过程，即制定计划，尝试去做，检查结果，采取行动，进入新的计划。

通过不断地演进，团队竞争力会逐渐提高，如果团队较大，可以在周期性的目标中设置一个关键任务，就是对团队竞争力发展的模型进行成熟度评估，类似于 CMMI，一般竞争力模型可以分为发展级，标准级以及优化级，不同的级别对应了组织对竞争力培养的响应能力。

1. 发展级，这个级别的组织对重点核心工作岗位做出了定义，并且和业务目标进行了对应，但并没有一个自动化的程序来执行（HR，业务，研发，财务等）相应的计划和改变；
2. 标准级，这个级别组织的竞争力模型已经完全对应了业务的需要，整个组织的 OD 进行了细致的思考，并且具有一定的伸缩性，在组织内部对竞争力培养的相关宣传工作已经开展，并且大部分工作都是自动化，至少是半自动化；
3. 优化级，这个级别的组织具有完备的自动化的竞争力模型，所有关键岗位的能力定义都十分清晰，各种人才流程能够自发的被应用并被自动映射到业务的发展上。很重要的一点是，这样的组织由于自身竞争力的提高，能够预测到未来的发展，就可以提前自发的响应并引领行业的发展。

总之，对于做好竞争力培养的团队，个人能力能被很好的培养并应用到实现既定目标上，也会帮团队取得高绩效。

关于这个话题，希望我能抛砖引玉，通过分享我个人的看法，希望和大家多多探讨，共同打造一个不是靠 996 来拼体力的研发团队，做到谋定而后动，未卜先知。

作者简介

赵晓光，TGO 鲲鹏会会员，目前在 Resideo Technologies，Inc. 担任 Fellow 及 IPA 技术总监，负责技术创新、平台以及架构方向，同时负责技术战略以及路线图，团队竞争力培养以及人员培养等工作。此前在霍尼韦尔担任 Fellow 及技术总监工作。在软件开发领域有丰富经验，获得 Leading SAFe, Exin Devops Master, CSSLP 及 PMP 认证。

第188讲 | 张嵩：从心理学角度看待小中型团队的管理

你好，我是张嵩，作为一个架构师出身的管理者，刚被“赶鸭子上架”的时候，我更喜欢别人称呼我为架构师而非总监 /CTO，原因是技术管理，特别中型技术团队的管理方法需要一段时间去摸索与分析，并非能一蹴而就。而当时的我，充其量只能算是在做技术管理的架构师，而非技术管理者。之后，我也将一些在架构领域养成的思维面模式，如习惯于权衡得失，应用到了管理中，慢慢形成了自己的管理风格。

《未来简史》中说过，“我们以为自己懂得很多，原因在于我们把存在于他人大脑中的知识看成自己的了”，因而我希望能尽量地享受群体思维带来的知识，而非无知。我从大学时代开始就接触心理学的基础理论，如今，我会更多地将它运用于生活的方方面面，包括职场，例如技术管理。在本专栏之前的文章中，熟稔于管理之道的技术管理者们已经将各种管理经验及实践案例讲述得很详尽了，我自觉已无能力更上一层楼，因此本文将以另外一个角度，即心理学来切入技术管理，抛砖引玉。

其实，这也是我转型技术管理者之后的常用的一个分析方法，俗话说“当局者迷，旁观者清”，有时候跳出管理的维度，站在一个非本领域的角度，如心理学角度来看待问题，会带来许多思考与领悟。另外，在本文中你可能会发现很多问题在日常中自己都碰到过，甚至解决方式都异曲同工，毕竟虽然思考角度不同，但殊途同归，万变不离其宗嘛。

技术管理的方法论关联性很高，很难做到降维，因此接下来的内容直接以心理学理论来推导，而不以管理方法作为主线来扩展。

一、自我服务归因

根据自我服务归因理论，人都会习惯性地把好的结果归因于自己，把坏的结果归因于其它。例如面试中，你拿到了 offer，可能会认为原因是自己基础扎实、思维快，如果与 offer 失之交臂，你可能觉得是因为面试官问的问题太偏 / 问的东西在实战中用不到等。

与此类似，技术管理人员容易把效能低、进度推进缓慢等归因于团队成员缺乏能力或者不够卖力等；团队成员会把获得奖励 (例如加薪) 看作是公平的，而对进度缓慢的看法会觉得是同事原因、任务目标不可及等。

这些现象在心理学中的术语叫自我服务偏差。团队成员容易高估自己对群体成功的贡献，而低估对失败应该负的责任。因此成功时，大部分成员会认为自己做出了很大的贡献，如果没有得到薪酬提升或奖励，就极有可能会觉得不公平，引发嫉妒与不和；而失败时，则容易责备他人，并且影响团队的氛围。

因此在实际工作中，作为一个技术管理人员，在出现任何问题时，首先要思考：我的行为导致这问题出现的占比有多少？(在此建议大家可以反思下最近一次问题。) 而非直接归因于团队成员或者情境，否则当问题主因并不在团队成员时，很容易造成团队成员的心理落差。

不过，在我看来，团队成员容易产生的自我服务偏差这点，其实既有好处也有坏处，而利弊占比取决于技术管理者的管理方式。原因在于，团队氛围的好坏很大一部分取决于团队成员对自身的评价和公司对他的评价。自我服务偏差会导致成员对自身的评价较高，如果从正常的管理角度而言，大家都更倾向加以赞赏与奖励，甚至为了整个团队的稳定，会让团队成员“吃大锅饭”，让团队的士气尽量稳住。但是这种做法却容易对其他的自认为表现更好的团队成员产生伤害，于是逐步地影响到整个团队的氛围，久而久之轻则带气工作，工作效率降低，重则优汰劣胜，最好的一部分人逐步离职，整个团队分崩离析。那如何才能够避免这情况的发生呢？

我们先从个人角度来分析，之所以出现服务偏差，一种解释是这是我们加工和记忆个人信息的副产品。我们常常会不自觉的将自己与他人做比较，去注意、评价、回忆自身与他人的行为，而这增加了出错的机会 (Chambers & Windschitl)，因为我们更容易回想起自己做了什么而不记得自己没做过什么 (Sicoly)。对于这种知觉错误，部分解释是：我们渴望评定自己的能力 (Dunning)、我们寻求自我证实 (Swann)、希望提升自我形象 (Sedikides)。堵不如疏，知道了偏差的原因，我们就可以有的放矢，我建议做四件事情：

1. 即时反馈 (Lichtenstein & Fischhoff)，通过在事情进展过程中的即时反馈，我们可以降低团队成员的过度自信，因为清晰的反馈信息有助于矫正偏差。

2. 分解任务 (Kruger & Evans)，对大任务的规划总是更容易陷入规划误区，(Zauberman & Lynch)，把大任务拆解成小任务，有助于减少团队成员的服务偏差所导致的问题。

3. 让团队成员养成反向思考的习惯，从你认为错误的观点中寻求能证明它的方面。因为按照验证性偏差的观点，一旦你认为一个观点可能正确，你会找出各种理由来证明它，让它看起来更加正确。

4. 定期一对一沟通，肯定团队成员的能力，同时在保证不伤及自尊心的前提下指出成员的不足之处，要注意对事而非对个人。并针对个人的形象提升，给出对应的成长计划。同时要拒绝大锅饭，在确保判断无误的情况下合理进行分配。

二、错误知觉

上一段内容中，我提到了“确保判断无误”这个词，为什么要强调它？主要原因在于我们的知觉很容易受到误导。

不知道大家是否有过这样的经历，当发现一个员工连续在一些事情上犯错后，我们会不自觉地更多地关注到他后续的错误行为，例如上班时不认真干活而在看不相关的资料等，但与此同时，却觉得其他有同样行为的员工是在做完本职工作后扩展学习。

出现这种现象的主要原因在于，我们的信念和预期在很大的程度上影响我们对事件的建构与看法，例如有消息说美国实施紧急法案后中国股市会回升，这时相信这个消息的人会以美国不行了、美股跌了中股会上涨等理由证明这是正确的，并且对反向的信息越来越封闭 (Jelalian & Miller)，而相信股市会下跌的人，会以全球金融不行了、中国出口受影响等理由证明这才是正确的。

这种现象其实很容易出现在各种评审会议、技术讨论等现实工作中，比如很多时候技术并非只有一条道能达成结果，但是如果多个研发有不同的思路，大部分情况下都会想法设法去证明基于思路的方案才是对的，同时陷入对其它方法的批判中，事实上双方的方案可能只是取舍方式不一，并无绝对对错。我们的先入之见会强烈地影响我们对事情的判断和解释。

另外，大部分人还会陷入“信念固着”的困境中，即使支持这个信念的证据被否定，但信念本身依然会存活下来，并可能会愈发固执。一个陷入信念固着的研发，当他支持的技术方案被否认后，他并不会去考虑其他人方案的可行性，而是努力地在原先的方案中抽取可行的部分，凑成新的方案来争辩，即使新方案依然是有问题的。因此，建议大家在团队内推行以下思考方式：“如果我是一个持相反意见的人，我是否会同那些与我信念不一致的人得出同样的结论呢？”

除此之外，错误知觉还有其他表现形式。心理学的一些研究表明，我们的记忆系统并不是一个储藏过去事实的地方，我们的记忆，实际上是在我们进行回忆时重构的，它会受到当前所持态度的严重影响 (Loftus)。而且有研究数据显示，人们总是将过去错误的判断回忆成基本上是正确的 (Tetlock)，也就是即使一开始判断错了，却依然会当做是几乎对的。打个比方，某个人分析股市，他早期判断可能是腾讯游戏类不行了，股价肯定会下跌，等到某一天腾讯股票涨了，他却会认为“我几乎是对的，腾讯游戏类确实不行了，要不是因为微信起来了，它股价肯定就跌了”，在专业术语上讲这种也被称为过度自信。

这种现象在技术管理者身上，就很容易出现误导信息效应，也就是很多时候态度改变后，就可能会坚持认为自己一直以来都是这样想的。比如在与团队成员相处时，因为某个时间点对方的行为或彼此的关系变差，技术管理者很容易认为这个人从一开始就很糟糕或者彼此的关系一开始就很差，即使一开始的评价是正向的，也就是当前情感状态容易影响到记忆中的情感状态 (Safer & others)。

因此，针对团队成员的判断，最好的方式是进行记录，不要受到自己情感状态变更的影响，相信自己所记录的，而不要以之前可能不是太了解之类的理由让自己处于一个错误的判断中。

三、基本归因错误

上文中提到针对团队成员的判断，相信大家都有自己的一套判断方式，但是这边要提出一个技术领导者很容易犯的错误，包括我自己在内。

通常情况下，我们都会做出很合乎常理的归因，但是我们会习惯把他人的行为更多地归结为内在的特质以及态度，很少去考虑环境的影响限制，即使这个影响非常显著。原因是在于我们观察某个人表现的时候，那个人是我们的焦点，情境相对而言处于不可见的状态。但是我们观察自身的时候，会更多地去关注需要作出反应的情境，因此情境是可见的。

而情境的不可见容易给技术领导者带来误判，例如这个团队成员当前的状态如何，是否陷入对未来的迷茫？他的家庭生活 / 成员近期是否发生了变化？他当前是否对某些事务有意见？各种各样的情境很容易给团队成员带来巨大的改变，作为技术领导者，应该对这块了如指掌，否则将难以做出正确的判断以及补救。

就如同我们所观察到的，近期当父亲的团队成员很容易赶不上迭代，甚至在需求评审中走神，这时如果不清楚近况，就很容易陷入对他们的误解中，而如果能在这种时候给予对应的关怀，减轻短期的工作量，引导赚奶粉钱的思维等，等团队成员熬过新生儿最让人疲惫的前几个月，他们的状态反而会更加良好甚至爆发性增长。

四、自我妨碍

限于篇幅影响，我选择了一个技术管理者的自我陷阱作为最后内容，它很常见，而我们作为技术管理者，需要克服它来得到提升。

所谓的自我妨碍，指的是人们习惯设置障碍来阻挠自己成功，以达到保护自尊的目的，大家先别急着否认，可以试着看完后回忆下。

前面讲过我们习惯把失败归为外因，以达到保护自身形象的目的。例如曾经年少的时候在考前各种玩耍而非学习，一旦考砸了就能把原因推到玩乐耽搁了学习而非能力不行上，一旦考好了则可以提升自己聪明的形象；再比如做一些项目没成功是因为一开始没认真去做，而非能力不足等等。

而研究者们发现，人们为此会做以下事情：

减少对重要的事情的准备 (Rhodewalt & others)；

给对手提供一些有利条件 (Shepperd & Arkin)；

在任务开始时不好好干，以便不对自身产生过高期望 (Baumgardner & Brownlee)；

在关系到自我形象的困难任务并不会尽全力 (Hormuth)，等等。

因此，在我们自己接手一项有难度的事情时，需要尽量去克服这种心理，同时需要使用各种方法来帮助团队成员避开这个陷阱。

结语

本文中谈到的从心理学角度看技术管理，其实主要都是针对人的层面，如果从对事、对团体等角度来分析，还包含说服、多人组成的平均水平降低、群体对决策的影响等非常值得探讨的话题。

作为技术管理者，需要关注的问题点着实很多，但是我相信方法更多。时代在不断地改变，新加入的团队成员的想法也在不断地改变，然而时代并不会主动来满足我们的团队管理方式，而是我们需要根据新时代团队成员的变化去不断地调整策略。

作者简介

张嵩，TGO 鲲鹏会会员，九年互联网工作经验，2014 加入他趣，先后从事微服务体系的构建、搭建技术梯队及构建研发体系等。同时从事多年互联网中小型公司顾问角色，为公司提供针对当前情况的技术 / 效率优化方案及实施，积攒了大量技术与应用结合的实践经验。对基础平台构建、机器学习、架构规划及实施、k8s 等有深入研究，开源爱好者，Go 语言及多个开源项目的 contributor。

第189讲 | 狼叔：2019年前端和Node的未来—Node.js篇（上）

你好，我是阿里巴巴前端技术专家狼叔，前两篇文章，我分享了大前端的现状和未来，接下来的两篇文章，我将会注重分享一些跟 Node.js 结合比较密切的点。

Node.js

Node.js 在大前端布局里意义重大，除了基本构建和 Web 服务外，这里我还想讲 2 点。首先它打破了原有的前端边界，之前应用开发只分前端和 API 开发。但通过引入 Node.js 做 BFF 这样的 API proxy 中间层，使得 API 开发也成了前端的工作范围，让后端同学专注于开发 RPC 服务，很明显这样明确的分工是极好的。其次，在前端开发过程中，有很多问题不依赖服务器端是做不到的，比如场景的性能优化，在使用 React 后，导致 bundle 过大，首屏渲染时间过长，而且存在 SEO 问题，这时候使用 Node.js 做 SSR 就是非常好的。当然，前端开发 Node.js 还是存在一些成本，要了解运维等，会略微复杂一些，不过也有解决方案，比如 Servlerless 就可以降级运维成本，又能完成前端开发。直白点讲，在已有 Node.js 拓展的边界内，降级运维成本，提高开发的灵活性，这一定会是一个大趋势。

2018 年 Node.js 发展的非常好，InfoQ 曾翻译过一篇文章《2018 Node.js 用户调查报告显示社区仍然在快速成长》。2018 年 5 月 31 日，Node.js 基金会发布了 2018 年用户调查报告，涵盖了来自 100 多个国家 1600 多名参与者的意见。报告显示，Node.js 的使用量仍然在快速增长，超过¾的参与者期望在来年扩展他们的使用场景，另外和 2017 年的报告相比，Node 的易学程度有了大幅提升。

该调查远非 Node 快速增长的唯一指征。根据 ModuleCounts.com 的数据，Node 的包注册中心 NPM 每天会增加 507 个包，相比下一名要多 4 倍多。2018 年 Stack Overflow 调查也有类似的结果，JavaScript 是使用最广泛的语言，Node.js 是使用最广泛的框架。

本节我会主要分享一些跟 Node.js 结合比较密切的点：首先介绍一下 API 演进与 GraphQL，然后讲一下 SSR 如何结合 API 落地，构建出具有 Node.js 特色的服务，然后再简要介绍下 Node.js 的新特性、新书等，最后聊聊我对
Deno 的一点看法。

API 演进与看起来较火的 GraphQL

书本上的软件工程在互联网高速发展的今天已经不那么适用了，尤其是移动开发火起来之后，所有企业都崇尚敏捷开发，快鱼吃慢鱼，甚至觉得 2 周发一个迭代版本都慢，后面组件化和热更新就是这样产生的。综上种种，我们对传统的软件工程势必要重新思考，如何提高开发和产品迭代效率成为重中之重。

先反思一下，开发为什么不那么高效？

从传统软件开发过程中，可以看到，需求提出后，先要设计出 ui/ue，然后后端写接口，再然后 APP、H5 和前端这 3 端才能开始开发，所以串行的流程效率极低。

于是就有了 mock api 的概念。通过静态 API 模拟，使得需求和 ue 出来之后，就能确定静态 API，造一些模拟数据，这样 3 端 + 后端就可以同时开发了。这曾经是提效的非常简单直接的方式。

静态 API 实现有很多种方式，比如简单的基于 Express / Koa 这样的成熟框架，也可以采用专门的静态 API 框架，比如著名的 typicode/json-server，想实现 REST API，你只需要编辑 db.json，放入你的数据即可。

{

  "posts": [

    { "id": 1, "title": "json-server", "author": "typicode" }

  ],

  "comments": [

    { "id": 1, "body": "some comment", "postId": 1 }

  ],

  "profile": { "name": "typicode" }

}

启动服务器

$ json-server --watch db.json

此时访问网址 http://localhost:3000/posts/1，即我们刚才仿造的静态 API 接口，返回数据如下：

{ "id": 1, "title": "json-server", "author": "typicode" }

还有更好的解决方案，比如 YApi ，它是一个可本地部署的、打通前后端及 QA 的、可视化的接口管理平台（http://yapi.demo.qunar.com/ ）。

其实，围绕 API 我们可以做非常多的事儿，比如根据 API 生成请求，对服务器进行反向压测，甚至是 check 后端接口是否异常等。很明显，这对前端来说是极其友好的。下面是我几年前画的图，列出了我们能围绕 API 做的事儿，至今也不算过时。

通过社区，我们可以了解到当下主流的 API 演进过程。

1.GitHub v3 的restful api，经典 rest；
2.微博 API，非常传统的 json 约定方式；
3. 在 GitHub 的 v4 版本里，使用 GraphQL 来构建 API，这也是个趋势。

GraphQL 目前看起来比较火，那 GitHub 使用 GraphQL 到底解决的是什么问题呢？

GraphQL 既是一种用于 API 的查询语言也是一个满足你数据查询的运行时

下面看一个最简单的例子：

首先定义一个模型；

然后请求你想要的数据；

最后返回结果。

很明显，这和静态 API 模拟是一样的流程。但 GraphQL 要更强大一些，它可以将这些模型和定义好的 API 和后端很好的集成。于是 GraphQL 就统一了静态 API 模拟和和后端集成。

开发者要做的，只是约定模型和 API 查询方法。前后端开发者都遵守一样的模型开发约定，这样就可以简化沟通过程，让开发更高效。

如上图所示，GraphQL Server 前面部分，就是静态 API 模拟。GraphQL Server 后面部分就是与各种数据源进行集成，无论是 API、数据还是微服务。是不是很强大？

下面我们总结一下 API 的演进过程。

传统方式：Fe 模拟静态 API，后端参照静态 API 去实习 rpc 服务。

时髦的方式：有了 GraphQL 之后，直接在 GraphQL 上编写模型，通过 GraphQL 提供静态 API，省去了之前开发者自己模拟 API 的问题。有了 GraphQL 模型和查询，使用 GraphQL 提供的后端集成方式，后端集成更简单，于是 GraphQL 成了前后端解耦的桥梁。集成使用的就是基于 Apollo 团队的 GraphQL 全栈解决方案，从后端到前端提供了对应的 lib ，使得前后端开发者使用 GraphQL 更加的方便。

GraphQL 本身是好东西，和 Rest 一样，我的担心是落地不一定那么容易，毕竟接受约定和规范是很麻烦的一件事儿。可是不做，又怎么能进步呢？

构建具有 Node.js 特色的服务

2018 年，有一个出乎意料的一个实践，就是在浏览器可以直接调用 grpc 服务。RPC 服务暴漏 HTTP 接口，这事儿 API 网关就可以做到。事实上，gRPC-Web 也是这样做的。

如果只是简单透传，意义不大。大多数情况，我们还是要在 Node.js 端做服务聚合，继而为不同端提供不一样的 API。这是比较典型的 API Proxy 用法，当然也可以叫 BFF(backend for frontend)。

从前端角度看，渲染和 API 是两大部分，API 部分前端自己做有两点好处：1. 前端更了解前端需求，尤其是根据 ui/ue 设计 API；2. 让后端更专注于服务，而非 API。需求变更，能不折腾后端就尽量不要去折腾后端。这也是应变的最好办法。

构建具有 Node.js 特色的微服务，也主要从 API 和渲染两部分着手为主。如果说能算得上创新的，那就是 API 和渲染如何无缝结合，让前端开发有更好的效率和体验。

Server Side Render

尽管 Node.js 中间层可以将 RPC 服务聚合成 API，但前端还是前端，API 还是 API。那么如何能够让它们连接到一起呢？比较好的方式就是通过 SSR 进行同构开发。服务端创新有限，搞来搞去就是不断的升 v8，提升性能，新东西不多。今天我最头疼的是，被 Vue/React/Angular 三大框架绑定，喜忧参半，既想用组件化和双向绑定（或者说不得不用），又希望保留足够的灵活性。大家都知道 SSR 因为事件 /timer 和过长的响应时间而无法有很高的 QPS（够用，优化难），而且对 API 聚合处理也不是很爽。更尴尬的是 SSR 下做前后端分离难受，不做也难受，到底想让人咋样？

对于任何新技术都是一样的，不上是等死，上了是找死。目前是在找死的路上努力的找一种更舒服的死法。

目前，我们主要采用 React 做 SSR 开发，上图中的 5 个步骤都经历过了（留到 QCon 广州场分享），这里简单介绍一下 React SSR。React 16 现在支持直接渲染到节点流。渲染到流可以减少你内容的第一个字节（TTFB）的时间，在文档的下一部分生成之前，将文档的开头至结尾发送到浏览器。当内容从服务器流式传输时，浏览器将开始解析 HTML 文档。渲染到流的另一个好处是能够响应背压。 实际上，这意味着如果网络被备份并且不能接受更多的字节，那么渲染器会获得信号并暂停渲染，直到堵塞清除。这意味着你的服务器会使用更少的内存，并更加适应 I / O 条件，这两者都可以帮助你的服务器拥有具有挑战性的条件。

在 Node.js 里，HTTP 是采用 Stream 实现的，React SSR 可以很好的和 Stream 结合。比如下面这个例子，分 3 步向浏览器进行响应。首先向浏览器写入基本布局 HTML，然后写入 React 组件<MyPage/>，然后写入</div></body></html>。

// 服务器端

// using Express

import { renderToNodeStream } from "react-dom/server"

import MyPage from "./MyPage"

app.get("/", (req, res) => {

  res.write("<!DOCTYPE html><html><head><title>My Page</title></head><body>");

  res.write("<div id='content'>");

  const stream = renderToNodeStream(<MyPage/>);

  stream.pipe(res, { end: false });

  stream.on('end', () => {

    res.write("</div></body></html>");

    res.end();

  });

});

这段代码里需要注意stream.pipe(res, { end: false })，res 本身是 Stream，通过 pipe 和<MyPage/>返回的 stream 进行绑定，继而达到 React 组件嵌入到 HTTP 流的目的。

上面是服务器端的做法，与此同时，你还需要在浏览器端完成组件绑定工作。react-dom 里有 2 个方法，分别是 render 和 hydrate。由于这里采用 renderToNodeStream，和 hydrate 结合使用会更好。当 MyPage 组件的 html 片段写到浏览器里，你需要通过 hydrate 进行绑定，代码如下。

// 浏览器端

import { hydrate } from "react-dom"

import MyPage from "./MyPage"

hydrate(<MyPage/>, document.getElementById("content"))

可是，如果有多个组件，需要写入多次流呢？使用 renderToString 就简单很多，普通模板的方式，流却使得这种玩法变得很麻烦。

伪代码

const stream1 = renderToNodeStream(<MyPage/>);

const stream2 = renderToNodeStream(<MyTab/>);

res.write(stream1)

res.write(stream2)

res.end()

核心设计是先写入布局，然后写入核心模块，然后再写入其他模块。

布局 (大多数情况静态 html 直接吐出，有可能会有请求)；

Main（大多数情况有请求）；

Others。

于是

class MyComponent extends React.Component {

  fetch(){

    // 获取数据

  }

  parse(){

    // 解析，更新 state

  }

  render(){

    ...

  }

}

在调用组件渲染之前，先获得 renderToNodeStream，然后执行 fetch 和 parse 方法，取到结果之后再将 Stream 写入到浏览器。当前端接收到这个组件编译后的 html 片段后，就可以根据 containerID 直接写入，当然如果需要，你也可以根据服务器端传过来的 data 进行定制。

前后端如何通信、服务端代码如何打包、css 如何直接插入、和 eggjs 如何集成，这是目前我主要做的事儿。对于 API 端已经很成熟，对于 SSR 简单的做法也是有的，比如 next.js 通过静态方法 getInitialProps 完成接口请求，但只适用比较简单的应用场景（一键切换 CSR 和 SSR，这点设计的确实是非常巧妙的）。但是如果想更灵活，处理更负责的项目，还是很有挑战的，需要实现上面更为复杂的模块抽象。在 2019 年，应该会补齐这块，为构建具有 Node.js 特色的服务再拿下一块高地。

小结一下，本文主要分享了 API 演进与 GraphQL，SSR 如何结合 API 落地，以及如何构建出具有 Node.js 特色的服务等前端与 Node.js 紧密相关的内容，下一篇文章中，我将主要分享一些 Node.js 的新特性，以及我对大前端、Node.js 未来的一点看法，欢迎继续关注，也欢迎留言与我多多交流。

作者简介

狼叔（网名 i5ting），现为阿里巴巴前端技术专家，Node.js 技术布道者，Node 全栈公众号运营者。曾就职于去哪儿、新浪、网秦，做过前端、后端、数据分析，是一名全栈技术的实践者，目前主要关注技术架构和团队梯队建设方向。即将出版《狼书》3 卷。

第190讲 | 狼叔：2019年前端和Node的未来—Node.js篇（下）

你好，我是阿里巴巴前端技术专家狼叔，今天是咱们大前端趋势系列的最后一篇文章，我将主要分享一些 Node.js 的新特性，以及我对大前端、Node.js 未来的一点看法，但在开始之前，我想先聊一聊 Serverless 这个当下很火，同时未来可期的技术。

Serverless

简单地说，Serverless = FAAS + BaaS ，服务如果被认为是 Serverless 的，它必须无需显式地配置，并能自动调整扩缩容以及根据使用情况进行计费。云 function 是当今无 Serverless 计算中的通用元素，并引领着云的简化和通用编程模型发展的方向。2015 年亚马逊推出了一项名为 AWS Lambda 服务的新选项。Node.js 领域 TJ 大神去创业，开发了http://apex.run。目前，各大厂都在 Serverless 上发力，比如 Google、AWS、微软，阿里云等。

这里不得不提一下 Eventloop，Node.js 成也 Eventloop，败也 Eventloop，本身 Eventloop 是黑盒，开发将什么样的代码放进去你是很难全部覆盖的，偶尔会出现 Eventloop 阻塞的情况，排查起来极为痛苦。

而利用 Serverless，可以有效的防止 Eventloop 阻塞。比如加密，加密是常见场景，但本身的执行效率非常慢。如果加解密和你的其他任务放到一起，很容易导致 Eventloop 阻塞。

如果加解密服务是独立的服务呢？比如在 AWS 的 Lambda 上发布上面的代码，它自身是独立的，按需来动态扩容机器，可以去除 CPU 密集操作对 Node.js 的影响，快速响应流量变化。

这是趋势，对于活动类的尤其划算。你不知道什么时候是峰值，需要快速动态扩容能力，你也不会一直使用，按需付费更好。就算这个服务挂了，对其他业务也不会有什么影响，更不会出现阻塞 Eventloop 导致雪崩的情况。

可靠性：99.999999999%

可用性：99.99%

无限存储空间

按量付费

在前端领域，Serverless 会越来越受欢迎，除了能完成 API Proxy，BFF 这种功能外，还可以减少前端运维成本，还是可以期望一下的。

Node.js 新特性

2018 年有一个大家玩坏的梗：想提升性能，最简单的办法就是升级到最新 LTS 版本。因为 Node.js 依赖 v8 引擎，每次 v8 发版优化，新版 Node.js 集成新版 v8，于是性能就被提升了。其他手段，比如使用 fast-json-stringify 加速 JSON 序列化，通过 Schema 知道每个字段的类型，那么就不需要遍历、识别字段类型，而是可以直接用序列化对应的字段，这就大大减少了计算开销，这就是 fast-json-stringfy 的原理，在某些情况下甚至可以比 JSON.stringify 快接近 10 倍左右。

在 2018 年，Node.js 非常稳定的前进着。下面看一下 Node.js 发版情况，2018-04-24 发布 Node.js v10，在 2018-10-23 发布 Node.js v11，稳步增长。下图是 Node.js 的发布计划。

可以看到，Node.js 非常稳定，API 也非常稳定，变化不大，一直紧跟 V8 升级的脚步，不断的提升性能。在新版本里，能够值得一说的，大概就只有 http2 的支持。

在 HTTP/2 里引入的新特性有：

1.Multiplexing 多路复用
2.Single Connection 每个源一个连接
3.Server Push 服务器端推送
4.Prioritization 请求优先级
5.Header Compression 头部压缩

目前，HTTP/2 已经开始落地，并且越来越稳定，高性能。HTTP/2 在 Node.js v8.4 里加入，在 Node.js v10 变为 Stable 状态，大家可以放心使用。示例代码如下。

const http2 = require('http2');

const fs = require('fs');

const server = http2.createSecureServer({

  key: fs.readFileSync('localhost-privkey.pem'),

  cert: fs.readFileSync('localhost-cert.pem')

});

server.on('error', (err) => console.error(err));

其他比如 trace_events，async_hooks 等改进都比较小。Node.js 10 将 npm 从 5.7 更新到 v6，并且在 node 10 里增强了 ESM Modules 支持，但还是不是很方便（官方正在实现新的模块加载器），不过很多知名模块已经慢慢支持 ESM 特性了，一般在 package.json 里增加如下代码。

{

    "jsnext:main": "index.mjs",

}

另外异常处理，终于可以根据 code 来处理了。

try {

// foo

} catch (err) {

if (err.code === 'ERR_ASSERTION') { . . . }

else { . . . }

}

最后再提 2 个模块：

1.node-clinic 性能调试神器（https://clinicjs.org）

这是一个 Node.js 性能问题的诊断工具，可以生成 CPU、内存使用、事件循环（Event loop) 延时和活跃的句柄的相关数据折线图。

2.Lowjs 使用 Node.js 去开发 IoT（https://www.lowjs.org/）

Node-RED 构建 IoT 很久前就有了，这里介绍一下 Lowjs。Low.js 是 Node.js 的改造版本，可以对低端操作有更好的支持。它是基于内嵌的对内存要求更低的 js 引擎 DukTape。Low.js 仅需使用不到 2MB 的硬盘和 1.5MB 的内存。

Node.js 新书

这里想再分享两本 Node.js 新书。

第一本是赵坤写的《Node.js 调试指南（全彩）》（https://item.jd.com/12356929.html）， 这本书从 CPU、内存、代码、工具、APM、日志、监控、应用这 8 个方面讲解如何调试 Node.js，大部分小节都会以一段经典的问题代码为例进行分析并给出解决方案。虽然内容比较散，但还是蛮有意思的一本书，属于进阶书。

第二本是吉姆·威尔逊（Jim，R.，Wilson）的《Node.js 开发实战》（https://item.jd.com/12460185.html）， 书中主要是 Node.js 新特性汇总，是 2018 年引进版，the pragmatic programmer 的书，还算比较新，我印象比较深的有拿 Elastic Search 作为数据，以及 node-red 这种 IoT 编程。不过需要注意的是，说是基于 Node 8，但没多少感觉，另外 mocha 等模块比较老，微服务和 Rest 写的也都比较浅，属于入门书。

在 2018 年，我也被小伙伴们各种花式催书，《狼书》3 卷，历时 3 年，终于在 2019 年要面世了。

关于 Deno

Ry 把 Deno 用 Rust 重写了之后，就再也没有人说 Deno 是下一代 Node.js 了。其中的原因大家大概能够想明白，别有用心的人吹水还是很可怕的。Deno 基于 ts 运用时环境，底层使用 Rust 编写。性能、安全性上都很好，但舍弃了 npm 生态，需要做的事儿还是非常多的，甚至有人将 Koa 移植过去，也是蛮有意思的事儿。如果 Deno 真的能走另一条路，也是非常好的事儿。

未来已来

不知道还有多少人还记得，Google 的 ChromeOS 的理念是“浏览器即操作系统”。现在看来，未来已经不远了。通过各种研究，我们有理由坚定 Web 信仰，未来大前端的前景会更好，此时此刻，只是刚刚开始。

这里我再分享一些参加 Google IO 时了解到的信息：
1.PWA 证明了浏览器的缓存能力；
2. 投屏、画中画、push 等原生应用有的功能也都支持了；
3.Web Components 标准化；
4. 编解码新方案 av1，效率有极大的提升。

为什么会产生这样的改变？原因在于：

1.Web 开发主流化，无论移动端还是 PC 端，都能够复用前端技能，又能跨平台，这是 ROI 最高的方式。
2.Node 和 Chrome 一起孕育出了 Electron/Nw.js 这样的打包加壳工具，打通了前端和 Native API 的通道，让 WebView 真正的跨平台。
3.PWA 对于缓存的增加，以及推送、安装过程等抽象，使得 Web 应用拥有了可以媲美 native client 的能力。

这里首先要感谢 Chrome+Android 的尝试，使得 PWA 拥有和 Android 应用同等的待遇和权限。谷歌同时拥有 Chrome 和 Android，所以才能够在上面做整合，进一步扩大 Web 开发的边界。通过尝试，开放，最终形成标准，乃至是业界生态。很明显，作为流量入口，掌握底层设施能力是无比重要的。

Chrome 还提供了相应 Web 端的 API，如 web pay、web share、credential management api、media session 等。

Chrome 作为入口是可怕，再结合 Android，使得 Google 轻松完成技术创新，继而形成标准规范，推动其他厂商，一直领先是可怕的。

前端的爆发，说来也就是最近 3、4 年的事情，其最根本的创造力根源在 Node.js 的助力。Node.js 让更多人看到了前端的潜力，从服务器端开发，到各种脚手架、开发工具，前端开始沉浸在造轮子的世界里无法自拔。组件化后，比如 SSR、PWA 等辅助前端开发的快速开发实践你几乎躲不过去，再到 API 中间层、代理层到专业的后端开发都有非常成熟的经验。

我亲历了从 Node 0.10 到 iojs，从 Node v4 到目前的 Node v11，写了很多文章，参加过很多技术大会，也做过很多次演讲，有机会和业内很多高手交流。当然，我也从 Qunar 到阿里，经历了各种 Node 应用场景，对于 Node 的前景我是非常笃定的。善于使用 Node 有无数好处，想快速出成绩，想性能调优，想优化团队结构，想人员招聘，选择 Node 是不会有错的，诸多利好都让我坚定的守护 Node.js，至少 5 年以上。

我想跟很多技术人强调的是，作为前端开发，你不能只会 Web 开发技术，你需要掌握 Node，你需要了解移动端开发方式，你需要对后端有更多了解。而拥有更多的 Node.js 和架构知识，能够让你如鱼得水，开启大前端更多的可能性。

如果前面有二辆车，一辆是保时捷一辆是众泰，如果你必须撞一辆，你选哪个？

理性思维是哪个代价最低撞哪个，前提是你能够判断这两辆车的价值，很明显保时捷要比众泰贵很多。讲这个的目的是希望大家能够理解全栈的好处。全栈是一种信仰，不是拿来吹牛逼的，而是真的可以解决更多问题，同时也能让自己的知识体系不留空白，享受自我实现的极致快乐。另外，如果你需要了解更多的架构知识，全栈也是个不错的选择。

以我为例，我从接触全栈概念到现在，经历了以下四个阶段：

第一阶段各种折腾，写各种代码，成了一个伪全栈，还挺开心的；

第二阶段折腾开源，发现了新大陆，各种新玩法，好东西，很喜欢分享；

第三阶段布道，觉得别人能行自己也能行，硬抗了二年，很累；

第四阶段带人管理，参加超级项目，心脑体都是煎熬，但对心智的打磨很有意思。

不忘初心，坚持每天都能写代码，算是我最舒服自豪的事儿了吧，以前说越大越忙，现在要说越老越忙了，有了孩子，带人，还想做点事儿，能安静的写会代码其实不容易。

说了这么多，回到大前端话题，至少目前看 2019 年都是好事，一切都在趋于稳定和标准化，大家不必要过于焦虑。不过，掌握学习能力始终是最重要的，还是那两句话：“广积粮，高筑墙，缓称王”，“少抱怨，多思考，未来更美好”。

做一个坚定的 Web 信仰者，把握趋势，选择比努力更重要！

最后给自己打一个广告，今年 6 月 20 日北京举办的 GMTC 大会上 (https://gmtc2019.geekbang.org/)，我会担任 Node 专场出品人，主要关注 Serverless，TypeScript 在 Web 开发框架里相关实践，以及性能，SSR，架构相关的 topic，如果你有想法，想分享的话，欢迎联系我。

作者简介

狼叔（网名 i5ting），现为阿里巴巴前端技术专家，Node.js 技术布道者，Node 全栈公众号运营者。曾就职于去哪儿、新浪、网秦，做过前端、后端、数据分析，是一名全栈技术的实践者，目前主要关注技术架构和团队梯队建设方向。即将出版《狼书》3 卷。

第191讲 | 肖冰：如何建立高信任度的团队

你好，我是肖冰，作为技术出身的管理者，我想和你分享这些年我从“独行侠”到懂得团队协作的心路历程，希望能给你带来一些收获。

成功依靠的是团队协助，而不是个人英雄

我早期的成长经历让我形成了颇为个人英雄主义的认知，即成功靠的是提升个人技术能力。当时的同事还送给我一个外号“大侠”，我对这个外号虽然谈不上骄傲，但颇有自信可以解决各种技术问题，而且我当时在工作上基本上是一个独行侠，一个人就可以快速完成各种任务，这也进一步强化了我的个人英雄主义。

可随着年龄的增长、业务的发展、职位的提升, 当年“任何工作上的事情都能自己一个人扛下来”的自信慢慢消失。另外，虽然增加了很多下属，但是压根不懂管理甚至蔑视管理，还是按照“自己来”和“我先学会再教大家”的工作思路做事，基本上工作中遇到困难都是自己一个人尝试解决。但实际上人的精力是有限的，不可能面面俱到，结果导致工作绩效每况日下。经过起初的迷茫、无助、焦虑等阶段后，终于明白当下想要把工作做好，需要的不是继续增强个人的能力，而是要依靠团队的力量。

依靠制度流程不能建设团队

当意识到问题之后，我开始恶补和实践很多软件开发领域的管理方法，经过一段时间的学习和思考，那时得出的结论是，靠细化岗位职责、强化制度流程才能发挥团队的力量。于是，开始按照软件工程的思想，依据 CMMI 的理念进行管理，进一步明确和细分岗位，建立了一系列的制度和流程。但结果是，表面上大家貌似都很认真、忙碌，产出了一堆工程文档和记录，但实际上客户满意度却越来越差，而且能明显感觉到同事的活力越来越低，办公室里越来越安静了。

经过痛苦的反思和总结后，我意识到，不断增加的制度和流程在规范操作、提高效率的同时也在压制个性、扼杀创新，让大家觉得工作没劲，缺乏乐趣。之所以设计这些制度和流程，本质上是不信任员工的能力，也不相信员工的责任心。这种不信任员工，只相信制度的管理方法，并不适合技术这种鼓励创新的、非重复劳动的工作。

信任是团队建设的基石

那到底如何建设团队？如何带领团队一起实现目标呢？每天在一起工作的同事就是团队吗？团队建设就是外出旅游，吃吃喝喝吗？那时的我一直在思考这些问题，后来有幸加入 TGO 鲲鹏会，对我个人而言仿佛推开了一扇大门，着实开阔了眼界，各种知识扑面而来。一个偶然的机会我读到了《团队协作的五大障碍》以及《突破——程序员如何练就领导力》这两本书，给了我极大的启发和触动。我意识到建立和增强信任才是团队建设的基石。

那么具体如何才能建立信任呢？我认为简单来说，平等、真诚这两个原则是取得信任的关键。下面是我从以上两本书以及我们 TGO 鲲鹏会小组活动规范中总结出的，并在工作中验证过的一些具体的思路和实践方法，供大家参考。

###1. 思想的转变，发自内心的相信改变观念能够带来结果的改变
这听起来有点唯心主义，而且作为一个比较坚定的唯物主义者，我花了很大代价才完成了思想的转变，毕竟太颠覆自己之前所相信的思想了。

作为一个团队领导者，首先你要从内心相信，改变你的观念能够带来结果的改变，要放下自己可能由于年龄、资历、职位等各方面优于团队成员而带来的自信，放下感觉团队成员能力不足、没责任心、不够努力的偏见，从内心深处相信只有信任、授权、依赖你的团队成员，才能提高团队绩效。

不要以“因为团队成员能力不足，责任心不强，所以我不能信任”作为理由进行辩解。因果要倒置，要相信“由于团队成员没有被信任，所以不愿意负责，不愿意提升能力”。这点很重要。我曾经有很多次差点忍不住出言指点或者自己动手，但是每次都在心里告诉自己既然选择相信大家，就彻底放手，毕竟只有亲自经历挫折才能成长。

2. 真诚的沟通

以前我意识到自己不会说话，太直接，老讲实话，不擅长沟通，这是一个缺点，需要改正。因此我读了很多如何提高情商或说话技巧类的书籍，也学习了一些方法，比如先表扬，再批评，接着再表扬的三明治批评法。但是在实践中，我发现这样沟通看起来一团和气，但实际上并没有解决问题，甚至可能让问题更加的恶化。

后来感觉这种沟通方式太累了，还是回到我熟悉的有话直说的方式，不过尝试改变了自己之前以问题导向为主的沟通方式，我不仅说出那些可能让人不快的结论，而且把我所得到结论的各种事实、思考及推理的过程和盘托出，没有压抑或者掩盖自己对某些事情的好恶，反而感觉获得了有效的沟通。

试想一下，如果团队成员间不能如实地表达自己的想法，而是按照某种高明的、不伤人的沟通技巧沟通，能形成真正互相可信赖的团队吗？

3. 尽量多的暴露工作以外的信息

做个简单的小调查，你是否能准确的说出你团队成员的家庭情况？父母身体如何？小孩几岁了？如果不能。那说明你们不是一个理想的团队，只是一群熟悉的陌生人。

只有让团队成员之间了解除了工作以外的其他信息，才可能产生信任。试问你会信任一个什么背景信息都不了解的陌生人吗？所以在团队活动中要让团队成员互相介绍自己的背景、人生历程、习惯爱好以及最触动自己的事情等等。正如 TGO 小组的活动中，每个小组成员都要首先进行人生成长历程的生命线分享，之后每次活动都向大家介绍自己这段时间在工作、家庭以及个人方面的喜怒哀乐。

尽量多的、周期性的暴露自己的信息是建立信任的关键。从这点来说，换一个环境，比如在酒桌而不是办公室，聊聊工作以外的事情确实是一种团建行为。

4. 平等的发言机会和时间

我记得 TGO 小组中有一条重要原则就是关于平等，不论在公司中担任什么职务，不论公司规模大小，在小组活动中大家的发言机会都是平等的。同样的，在一个团队中也存在职务上、能力上、年龄上的差异。而会议是最重要的团队活动，要通过刻意的会议议程设计，确保团队成员的发言机会和发言时间的平等性。一个“一言堂”或者缺乏活力的团队，其会议发言机会和时间一定是不平等的。比如我们在小组活动中首先就会学习和讨论如何开会的问题，具体涉及到议题如何产生，主持人如何确定，主持人要如何控制发言机会和时间等等细节。

5. 示弱，减小盲区

我记得有一篇文章里提到，“在战场上，对战友的最大信任就是背靠背，把唯一的弱点交给对方，也是将自身无法满足的安全感托付给对方”。如果你真正信任团队成员，你就不会怕团队成员会利用、嘲笑你的弱点，而是相信他们会包容和帮助你。一个强势的让人感觉各个方面表现都很突出、几乎全能的团队成员，会让其他成员感觉自己不被需要，很难产生信任。按照乔哈里视窗理论，任何人都存在别人知道而自己不知道的盲区。所谓盲区，是指你自己无法感知到的信息，主要指负面信息，例如性格上的弱点、坏习惯、别人对你的处事方式的感受等。

减少自己的盲区是成功的必要条件。如果你的团队成员让你看到了自己的盲点，减小了自己的盲区，那对你来说就是获得了进步和提升，而你真诚的感谢会极大地提升对方的成就感，使对方获得被信任、被依赖的感觉，有利于增强团队信任。具体的实践方法就是团队领导带头进行定期的自我批评。

以上是我在这几年工作中的一些心得和实践，对我来说，转变管理思维模式，真正的做到以人为本，激发团队成员的活力后，确实取得了比之前好很多的绩效。

当你和团队成员真正建立信任以后，你会发现其实不用依靠复杂的流程、繁琐的文档，也不需要人海战术或者技术大咖，打造一个能让大家愉快且发自内心愿意工作的团队氛围，即使是一群普通人都能够取得非凡的成就。现在的我认为小而美的团队是成功的基础。

感谢收听，我们下期再见，如果有不同看法，也欢迎留言探讨~

作者简介

肖冰，环球鑫彩技术总监， TGO 鲲鹏会会员，一个混迹于技术十多年，蓦然发现感性和沟通非常重要，正在不断学习的人。

第192讲 | 崔俊涛：如何做好技术团队的激励（上）

你好，我是崔俊涛，每个团队的激励都是一件费心费力的事情，团队成员千变万化、性格迥异，每个人的追求和出发点也不尽相同。使用统一的框架来进行考核和激励，虽然会比较困难，但是非常重要。在本文中，我将结合自己实际的工作经验以及外部学习到的一些方法来进行总结，期望你能有所收获。

激励的重要性

在明确如何激励之前，我们先简单了解下激励的重要性和误区。

首先，激励是心理学的术语，代表激发动机、鼓励行为及形成动力。激励用于管理，是指激发员工的工作动机，用各种有效的方法来调用员工的积极性和创造性，使其努力完成任务，实现公司目标。一般而言，有效的激励手段能够实现如下目标：
1. 公司及团队目标的实现。
2. 激发开发员工的潜能，使之获得巨大的成就感。

既然激励如此重要，那在实际的团队管理中，我们应该如何进行激励以提高团队的积极性和开发效率呢？在实际的产品或者项目流程中，我们一般分为三个阶段：设定目标、进行考核以及实施激励，做好激励也需要从这三个阶段着手。

目标管理

提到目标管理，我们脑海中最先出现的可能是 KPI 或者近年流行的 OKR。关于技术团队是更适合用 KPI 还是 OKR 的讨论也一直存在。我们先从如何设定目标开始讲起。

设定目标

歌德曾经说过：“每走一步都走向一个终于要达到的目标，这并不够，应该每下就是一个目标，每一步都自有价值。”设定目标之后可以使公司的愿景明确，团队资源集中来完成目标。在实际的工作中，如何设定目标可以用一个通俗易懂的词语来表达：给谁干。

人是一种社会性动物，但同时也是一种自私的动物。我们喜欢拥有自主和主动的权利，不喜欢被人牵着鼻子走。因此，在设定目标的过程中，我们期望团队中的每位成员都能够认为目标是自己的，是在为自己实现目标。因此给谁干的问题可以总结为如何使团队成员设定自己的目标。

目标共享

如果希望团队成员将团队目标当成自己的目标，那就需要做到目标共享，信息透明。只有团队成员清楚了解团队目标，并明确自己能为目标贡献哪些力量，他们才有动力将其细化分解为自己的目标并付诸行动。同时，团队成员间的目标也要充分及时交流，才能更好的互相配合，形成合力与凝聚力。

基于此，目标共享分为自上而下和自下而上两条路径。自上而下保证团队成员的个人目标最终能汇聚成团队目标，而自下而上能够由个人目标来推动团队目标的完成，增加团队成员的集体荣誉感。

在日常工作中，如何做到让团队成员设定自己的目标并且将其共享给其他团队成员呢？在实际的操作过程中，我们可以结合 OKR 来进行。

1. 团队目标
首先我们可以根据 OKR 的原则来设定团队的整体目标及关键成果。比如整体目标可以设置为“提升用户留存率”，关键成果可以由团队成员集体讨论后确定，经过讨论后，相应的设置可以为如下几条：

提升用户次日留存率 3 个百分点；

提升用户 7 日留存率 5 个百分点；

提高推送消息触达率到 99.5%；

提升用户浏览时长 10%。

2. 成员目标
关键成果讨论确定完毕后，每个团队成员都需要根据自己的情况和工作安排来考虑自己的目标和关键成果是什么，能够为整体的目标和关键成果产生什么影响。这一过程中我们强调必须是由团队成员自己来设定目标和关键成果，这样他们才能认为这些目标是自己的目标，并产生责任感和使命感。比如产品负责人为自己设定的目标和关键成果如下：

目标：提升用户留存率
关键成果：

设计积分奖励体系，提高用户的次日及 7 日留存率分别为 3% 和 5%；

提高内容质量，提升用户浏览时长 10%；

设计推荐系统，根据用户的浏览习惯推送内容，提高用户浏览时长 10%。

3. 共享并修正目标
团队成员的目标可能会互相影响和互相促进，因此需要在团队内部进行共享。比如开发负责人可能会根据总体目标及产品负责人的目标来设定自己的目标如下：

目标：提升用户留存率
关键成果：

使用手机厂商的推送通道，并优化推送逻辑，提高推送消息触达率达 99.5%；

使用协同过滤算法实现推荐系统，提高用户浏览时长 10%；

实现积分奖励体系，提高用户次日及 7 日留存率分别为 3% 和 5%。

业务目标与技术目标并重

技术人员渴望自身技术的进步以及公司层面技术的前瞻性与先进性，而团队更关注于业务的目标及完成度。大多数情况下，这两个目标是有冲突的，为了业务的稳定性及目标能够尽快达成，采用原有的稳定性高的技术是首选，但这样做就会限制技术团队尝试使用新的可能不太稳定的技术。因此在团队管理中，需要兼顾短期业务目标及中长期技术目标，将技术的发展作为团队的一个长期发展的主线。

目标量化

清晰且可以实现的目标一定是量化的目标，因此无论是技术目标还是业务目标都应该是量化的目标。如“完成订单功能的微服务重构”就不是一个量化的目标，因为目标中不包含时间、目标范围等基础信息。此目标应该改为“2019.3.31 完成订单功能（包括下单、库存处理、订单支付）的微服务重构，并能无缝接入现有系统”。

不可能实现的目标

目标设定的过程中，大多数目标都是可实现的目标，但团队也需要一些看似不可能实现的远大目标。从心理学的角度来说，人的潜力和主观能动性是无穷的，看起来可以实现的目标会限制人的潜力和欲望，从而不能达成惊人的结果。如果团队设置一些看起来不太容易实现的目标，为了达成这个目标，团队中的成员往往会自发的发挥他的潜力，即使最终的目标没有达成，也可能看到令人欣喜的发展。

总的来说，技术团队的激励虽然是一件费心费力的事情，但却非常重要，能够有效帮助公司及团队目标的实现，并激发开发员工的潜能。在实际的操作中，我们可以从设定目标、进行考核以及实施激励这三个阶段着手来做好激励。

本文主要分享了在目标管理阶段该怎么做，关键在于给团队设定合理的目标，并让团队成员将团队目标当成自己的目标，并为之付诸行动。下一篇文章将着重分享我在考核及实施激励这两个阶段的实践与经验，欢迎持续关注。

感谢你的收听，我们下期再见，如果你有不同的观点，也欢迎在评论区留言讨论~

作者简介

崔俊涛，TGO 鲲鹏会会员，目前担任上海万位数字科技有限公司 CTO，专注于位置服务、大数据及汽车金融风控解决方案领域。

第193讲 | 崔俊涛：如何做好技术团队的激励（下）

你好，我是崔俊涛，今天继续聊聊技术团队的激励这个话题，上文中提到，我们可以从设定目标、进行考核以及实施激励这三个阶段着手来做好激励。今天，我将继续分享一些我在目标考核及实施激励这两个阶段的经验，希望能对你有所帮助。

目标考核

目标设定完毕后，团队就需要定期监控目标的达成进度和完成情况，并及时向团队成员进行反馈，修正目标的偏离和漂移，并且及时根据市场及业务的发展情况对目标进行调整，保持公司的竞争力和活力。目标考核一般分为几个方面：即时反馈、量化考核及目标修正。

即时反馈

积极心理学奠基人米哈里在《心流》一书中着重提到，获得即时反馈能够帮助我们进入心流状态，即全神贯注、投入忘我的状态。回想一下我们玩游戏时的状态，全神贯注、废寝忘食，感觉特别爽。为什么游戏能让我们达到这个状态，因为 Double Kill、升级、装备等即时反馈的机制存在。米哈里认为即时反馈本身是什么并不是很重要，真正重要的是，通过这个反馈信号，能让你觉得达到或者在接近目标。因此在工作中，团队管理者需要对团队取得的成果给予即时的反馈，包括对接近目标的鼓励和表扬，对远离目标的批评和建议。

量化考核

对目标的即时反馈取决于我们如何判断当前工作是接近还是远离目标，所以要有可以量化的考核方式。量化考核一方面依赖于可以量化的目标，另一方面需要依赖于对于过程的量化的监控。量化的目标在目标管理的章节已经讨论过，这里重点说一下如何量化过程。

技术团队的过程量化一直是个比较大的难点，我们聪明的产品狗（读得时候读作产品人）或程序猿总是能够很快定位到过程量化中的漏洞并且绕过。举个例子，之前有一个指标是 BUG 数量 / 代码行数，但程序猿很快就发现可以多写空行或者多换行来降低这个数字。

目前，在实际的量化考核中，我们主要采用如下几种方式：
1. 项目完成度：对于团队来说，项目按时按质完成是首要任务，因此项目完成度是一项比较重要的指标。
2. 任务积分：将产品和项目分解成工作量差不多的任务，交由团队成员来挑选，完成任务可以增加任务积分，每月统计一次任务积分，根据排名进行不同的奖惩。
3. 严重 / 无脑 BUG 排名：对测试过程中或生产环境上产生的严重 / 无脑 BUG 进行统计。
4. 知识分享积分：鼓励团队成员之间的知识分享，可以通过会议、文档、沟通的方式来进行。
5. 工时排名：我们承认每个人的效率会有差异，但不可否认的是团队成员的效率差距一般不会特别明显，在这种情况下，投入的时间和精力能够成为衡量一个人工作情况的重要参考指标。

目标修正

俗话说，唯一不变的就是变化，这是大多数公司面临的现实情况。市场的变化、竞争的变化、政策的变化以及执行的结果都会导致公司目标发生变化和调整，因此需要定期回顾目标及其完成情况，然后根据公司实际情况进行修正，并且将新的目标共享给团队成员。

激励

最激动人心的时刻到了，所有团队成员都在等着这一刻，目标达成，拿到期盼已久的奖励。通俗地说，激励就是怎么分的问题。激励一般有如下几种：精神激励、晋升激励、物质激励等。

1. 精神激励
领导的信任、良好的情感空间和氛围、对自身价值的认同都属于精神激励的范畴。精神激励是一种低成本、高效率的激励方式。这种激励方式能够最大限度的激发团队成员的积极性和创造性，提高忠诚度和自信心，久而久之，团队就形成了家庭般的氛围，气氛融洽、目标清晰、分工明确、互帮互助，这也是很多公司追求的团队氛围。

精神激励可分为持续性和临时性两种方式。持续性的包括定期评比，比如每月的任务之星、最少 bug 奖等，奖励方式可以是光荣榜、流动锦旗等。临时性的适用于完成了某个项目或者任务、帮助了某位同事等非持续性的工作，奖励方式可以是语言激励、团队表扬、聚餐等方式。从这些方式来看，精神激励简单直接，并且能产生较大的效果。

2. 晋升激励
如果说精神激励属于柏拉图式的激励，晋升激励就属于直接激励了。通过职位或者职称的晋升，团队成员的价值获得最直接、最明确、最广泛的认可。在公司层面上一般都会有技术职级的设定，比如阿里的 P 序列，腾讯的 T 序列等。有些公司还会成立技术委员会来参与技术团队的职级晋升评定，结合 KPI 或 OKR 的完成度来对团队成员进行评定以决定是否能参与晋级评定。

3. 物质激励
物质激励也是比较常见的直接激励手段，也是最能体现怎么分的细节。但是在使用物质激励时需要小心，避免掉进物质激励的陷阱。

首先是平均主义。中国有句古语：不患寡而患不均。因此团队管理者在分配奖励时最先考虑的是公平，不巧的是，有时候我们认为公平 = 平均，所以倾向于采用按照工资比例分配的方式来发放物质激励。但往往这种激励不仅达不到激励的效果，还会引起反作用，使团队成员觉得激励不公平。在大多数人眼里，只要分配有规律可循，根据规律计算出自己拿少了或者别人拿的多了，就很容易感到不公平，因此很难找到让所有人都满意的公平方法。所以在实际操作中，可以不按照规律来分配物质激励，或者说团队管理者可以比较随心的分配激励，不需要让团队成员看到其中的规律。

其次，过于依赖物质激励。团队管理者往往有一种概念：只要给足了钱，员工必然会感恩，从而提高忠诚度和积极性。其实未必，试想这种情况，整体业绩好的时候，发了很多奖金，但如果第二年整体业绩不好，奖金少发了，部分团队成员就会产生不满的情绪。由俭入奢易，由奢入俭难，就是这个道理。人的欲望是无止境的，物质的激励只会逐步放大欲望。

对大部分团队成员来说，精神激励的效果要大于金钱激励。在基本物质需求得到满足的基础上，员工更需要的是肯定与褒奖，即精神层面的鼓励。比如每个月给某个团队成员发 1 万块钱奖金，但天天当众骂他废物，另外一个员工每个月只给 1000 块钱奖金，但天天当众夸他做得好，哪个对他的激励效果更大？前者是管理者在用金钱买员工的尊严，员工拿了钱都不会念你的好，闹不好心里反而会记恨你；后者管理者通过充分给予员工尊严为自己省钱，员工也会视你为知己，像打了鸡血一样为你效命。

4. 量身定做
团队成员的情况千差万别，有人追求精神激励，有人追求物质激励，所以激励手段和方法不能一概而论，要单独为团队成员量身定做激励方案。这就要求团队管理者对团队成员的情况有比较清楚的了解，清楚的知道每个团队成员处于马斯洛需求层次的哪个阶段，以便于对症下药。

总结

总结下来，关于团队激励，本文只是讨论了两个问题：给谁干和怎么分。通过目标管理，团队管理者可以将团队目标转化为团队成员自己的目标，从而达到每个人都是在为自己干的目的。通过激励管理，团队管理者可以使团队成员都产生一种拿到了合理甚至丰厚回报的感觉，从而激发团队成员的积极性和潜力，形成良性循环。

感谢你的收听，我们下期再见，如果你有不同的观点，也欢迎在评论区留言讨论~

作者简介

崔俊涛，TGO 鲲鹏会会员，目前担任上海万位数字科技有限公司 CTO，专注于位置服务、大数据及汽车金融风控解决方案领域。

第194讲 | 刘俊强：2019年云计算趋势对技术人员的影响

你好，我是腾讯云资深架构师刘俊强，之前提到 2019 年的云计算趋势主要体现在五大方面，分别是：云服务市场将继续增长强劲；混合云和多云（Poly-Cloud）将逐渐成为主流；自动化将不可或缺；合规性和安全性将受到重视；云服务将依然是新技术的最佳试验地。

那么，这样的趋势会对技术人员产生什么影响呢，技术人员又该如何应对这样的趋势变化呢？

一个普遍的共识是，云计算优先概念将在接下来的几年内被普遍接受，云计算也将被各大企业以及独立开发者所选择采用，而对于 IT 从业人员或技术人员来讲，面临的主要影响是自身云技能栈的建立。

云技能栈的建立

目前，各大企业都加大了在云计算上的投入，那么如何将云计算使用好，追求最大的投入回报便成为关键问题。云计算和传统 IDC 有着诸多区别，如果仅仅将云计算当做传统 IDC 来进行使用便达不到上云的目的。简化来看，企业上云的期望主要在于成本优化和效率提升，而技术人员需要通过技能来帮助企业达到这样的目标，势必会对技术人员的技能栈提出新的挑战和要求。

在开始讨论云技能栈的挑战前，先回顾下云计算的三类服务：IaaS（基础设施即服务）、PaaS（平台即服务）以及 SaaS（软件即服务）。

上图展示了不同类型的云计算服务，云厂商和客户的责任分配是怎样的，我们可以根据自身业务的情况来进行灵活的选用，例如类似 GitHub 的 SaaS 类代码托管服务、消息队列 Kafka 这样的 PaaS 类服务以及云服务器这样的 IaaS 类服务，在此我将不再累述了。接下来主要讲一下云计算给技术人员带来的技能栈方面的挑战，主要在两个方面，分别是对云计算弹性能力的掌握和对云网络与安全架构能力的掌握。

云计算弹性能力的掌握

上云之所以能够有效帮助企业进行成本优化和效率提升，主要是依赖云计算的弹性能力，弹性能力包括资源的快速分配以及资源类型多样性等诸多方面。企业在迁移上云时可能会遇到一些问题，比如业务应用程序架构本身不支持弹性扩展等，这样的情况下将应用迁移上云后，如果业务架构不做出调整，还是无法使用到云计算的弹性能力来帮助优化成本和提升效率。

当然，迁移上云本身会面临新业务应用和遗留业务应用的问题，这里暂不做过多讨论，因此这属于云迁移策略的范畴，还是专注于探讨如何使用好云计算的弹性能力。我将如何使用好云计算弹性能力的要点做了如下简单整理：

业务架构需要采用云优先策略，尽量做云原生（Cloud-Native）架构，使得业务应用本身在基础架构上是对云计算弹性能力有良好支持的，同时，拥抱微服务架构设计风格，使用容器服务来简化运行环境依赖等。

云计算弹性能力的熟悉，例如弹性伸缩（Auto Scaling）、批量计算（Batch Compute）以及无服务函数计算（Serverless Cloud Function）等，简单来说，就是将计算资源的生命周期管理交由云厂商来进行处理，使用者更加关注于业务实现。当然，使用者也可以基于云监控和 API 自行进行资源的弹性扩缩容。不论是何种使用方式，弹性能力是云计算帮助企业优化 IT 成本的基础，能最大程度做到按需使用，减少资源浪费。这里还有个需要注意的地方是关于资源的计算，例如云服务器计费模型的选择问题，不同的计费模式适用于不同业务场景。如间歇、周期性计算作业就适合按量计费这种后付费模式，如长期稳定计算作业就适合包年包月这种预付费模式。

熟悉公有云物理地域和可用区来进行高可用架构设计，充分利用公有云物理地域间内部网络互通的能力。

那么技术人员如何用好云计算的弹性能力呢？目前，主流的云服务商都提供了相关的产品使用介绍资料，如文档、视频以及 workshop 等，通过这些资料可以帮助技术人员快速的熟悉了解云计算的弹性能力。当然，了解熟悉完云服务商提供的弹性计算能力后，我们还需要对自身业务进行梳理分类，来规划好不同业务模块到底应该使用怎样的计算能力。

云网络与安全架构能力

在传统 IDC 模式下，IT 环境更像基于边界的城堡模式，即整座城堡都是由客户自行建立和管理的，而云计算环境更像是一座现代化的酒店，客户在这座酒店可以通过房卡进入特定的楼层和房间。因此不难看出这两种模式下的安全模型是不一样的，如果企业直接将传统 IDC 模式下的安全模型平行迁移到云上，可能会对安全产生不利影响。简单来说，云网络与传统网络模型有相似和不一样的地方，对应技术人员需要掌握的网络相关能力如下：

先掌握私有网络 （Virtual Private Cloud）下的产品，例如子网划分、ACL 设置以及 NAT 网关等产品，最终掌握基于云网络产品的网络隔离方案设计。

了解公网网络计费模型并根据业务特点选用最为适合的计费模型，公有云的公网网络计费有多种模型，适应不同的业务场景，如果不能熟练掌握会造成成本的浪费。例如，公网计费常见的计费模式有按带宽计费、按流量计费等，如果业务类型每日只有很短时间的流量高峰，采用按带宽计费就会有成本的浪费，一般实践而言，当带宽利用率高于 10% 时，建议优先选择按带宽计费。

熟悉公有云特有的网络产品来帮助提高业务效率，例如对等链接、云联网等产品能够帮助提升客户多地域部署时的内部互通性。

正如前面所说云计算更像现代化的酒店，那么云安全架构设计能力就对技术人员提出了如下的基础技能要求：

熟悉云安全责任共担模型，简化而言，就是客户负责使用云的内部安全、云厂商负责云服务本身的安全。使用云的内部安全包括但不限于：数据、身份和访问管理以及操作系统安全配置等。

做好云安全架构指引来帮助企业做好云端安全加固，即云安全架构的能力和产品全景图，以及适合企业业务需要的能力和产品选取方案。

关于云安全架构指引，这里我将分门别类简单整理如下：

基础设施安全：基于私有网络 VPC 设计网络隔离方案、应用防火墙 WAF、安全组（云服务器的网络访问控制）、安全的链路连接（如 VPN 和专线等）等；

身份与访问控制：访问管理系统、多因子认证等；

DDoS 防护：云解析（防 DDoS 域名解析服务）、DDoS 防护、安全 CDN、高防 IP 等；

数据加密：块存储及对象存储加密、密钥管理系统、数据库中间件安全连接等；

日志与监控：网络流日志、云审计服务、日志服务、云监控等。

总的来说，做好云安全架构设计，首先需要明确的是文章之前提到的责任模型，即明确哪些责任是由云服务商负责，哪些是由企业自己负责；然后根据上面提到的指引，熟悉并整理出这些产品或功能对企业自身业务的适配程度与边界，如能解决什么问题、不能解决什么问题、解决问题是否引入额外的代价等。这样就明确了手上有哪些弹药，在设计云安全架构时就可以像搭积木一样来进行组合使用了。整体而言云安全架构设计能力是构建于基础的安全架构设计能力之上的，因此掌握基础架构设计知识是前提条件。

从全文不难看出，云计算的普及会对技术人员的使用习惯产生很大的挑战，基础设施工作模式的不一样会带来工作思路的不一样。再加上目前正处于传统 IDC 和云计算并行的阶段，因此对技术人员来说，掌握和了解相关的知识和信息，养成良好的工作习惯是尤为关键的。云计算更多的是服务模式的变化带来了适配工作的挑战，作为技术人员，学会有条理的梳理工作、对数据安全敏感、持续学习等良好的工作习惯，相信面对云计算带来的挑战也将游刃有余。

作者介绍

刘俊强（微信公众号：程序员精进）腾讯云资深架构师、TGO 鲲鹏会会员，曾任迅雷技术总监、某互联网公司技术副总裁，10+ 年以上互联网开发经验，8 年以上技术管理经验。

第195讲 | 吴晖：企业B2B服务打磨的秘诀—ESI

你好，我是金扳手 CEO 吴晖，从事企业 IT 研发、服务、管理共 20 年。今天想和你分享的话题是：创业公司如何打磨出一个好的 B2B 企业服务。这里的企业 B2B 服务，特指需要线上 / 线下结合的，面向企业客户提供的服务。这个话题是我对创业过程中所碰到的业务挑战的一个总结。当然，摸索的路还远没有结束，我今天分享的一些内容有可能是错的，但是希望能够为其它 2B 的、需要线下交付结合线上可视化的企业服务创业团队，提供一个真实的参考，也期待大家在留言区讨论和反馈。

挑战

金扳手的业务非常传统，是为生物制药、IDC 等行业客户提供基础设施（空调，配电，锅炉等）运营服务。我们提供的是企业服务，需要线下交付。同时，面临着人效低，服务质量方差大，服务 SOP 标准不统一等实际问题。客户对我们服务的感知，和竞争对手区别不大。因此，我和我的创业伙伴想把 IT 技术、物联网技术以及 AI 技术等，应用在这个传统的基础设施运营服务的业务场景中来，提升交付质量，提升人效。但从业务角度看，面临三个挑战：

目前的创业项目为企业提供基础设施运维服务。该服务需要线上、线下相结合，服务交付的链条比较长，而不是像 2C 的创业企业可以攻其一点。B2B 比的是短板，而且还需要考虑线下交付，整个服务需要打磨的周期比较长。

创业环境和外企环境不同，MBA 的很多管理方法不能在创业环境中直接使用，创业的项目是一个摸索的过程，采用什么方法来摸索也是一个挑战。

如何激励一线技术工人？如何激励一线项目经理？人是企业服务中非常重要的一环，线下交付的质量严重依赖于人的技能和积极性。

以上几个问题都是相关联的，无法简单的分割。带着上述业务背景和面临的挑战，我在不断思考，哪些规律是在 0 到 1，1 到 10 的创业过程中必须考虑和摸索的？个人认为最重要的规律（或者说第一性原理）有三个，即迭代的认知过程、康威定律和设计思维。当然，还有很多其它具备参考价值的规律，在此不多叙述。下文对这三个规律进行简单描述。

规律一：通过迭代获取认知的过程

如上图所示，我们都知道，产品研发的迭代过程，其实是一个通过不断重复打磨，在实践中获得正确、完整认知的过程。在早期搭建的 MVP 是一个最小可行产品，其作用是为了验证某个特定客户集合所感知的价值。只有通过不断的 MVP 迭代，每次迭代改进一些功能，提供更多的客户价值，最终才能构建一个客户认可的产品。我们无法省略中间的迭代，一步到位实现对事物正确而全面的认知。创业其实也是这样一个过程。

规律二：康威定律

在 IT 行业，大家都知道大名鼎鼎的 Conway’s Law 康威定律：

产品的结构会拷贝组织的结构。（Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure）。

在打造企业服务的 IT 产品系统的过程中，必须思考企业内部组织的结构。只有在 IT 产品系统结构和企业组织结构相适配的情况下，IT 系统才能够充分发挥作用。如果结构不一致，将导致内部工作的混乱。

举个例子，如果线下工厂设备巡检工作是由调度员分配，对维修团队派单的模式，而 App 却设计一个抢单模式，不需要调度员了，那这就是 App 系统和组织的结构不一致，将导致企业无法使用 App。如果我们觉得客户需要抢单模式来提升效率，而目前线下组织是一个支持派单模式的结构，这就需要对线下组织结构和流程进行重新设计，对相关人员进行培训，并且激励相关人员去抢单。

所以在设计这个 App 的时候，需要充分考虑线下组织结构、线下服务交付及线上 App 的业务流程的同步。在传统企业互联网化转型的过程中，线下组织的结构和流程往往并不是最优的，我们希望通过 App 带来新的工作流程，提升效率和服务体验，而这必将会带来线下组织结构和业务流程的改造。这样的场景很常见，因此，在设计线上 / 线下打磨的时候，需要充分考虑康威定律。

规律三：设计思维

如上图所示，在混沌商学院的一次分享中，IDEO 联合创始人汤姆·凯利（Tom Kelley）分享了设计思维（Design Thinking）的理念，其中提到了三个维度：商业、技术和人。

设计思维强调的是商业、技术和人的结合产生的体验创新。如果只是商业和技术结合，产生的是流程创新。例如：我们把巡检工作的派单模式，改变为抢单模式，这就是在商业、技术上可行的流程创新。但是，如果没有考虑到激励员工去接受抢单模式，改变相应的组织结构，那么就不是体验创新。

如果只是技术和人的结合，将产生功能创新。最近碰到挑战的共享单车行业，就是技术上可行，人也愿意使用的功能创新，但是一直没有摸索到可行的商业模式。这也不是体验创新。

如果只是商业和人的结合，将产生情感创新。例如早期的在线音乐行业，人们是愿意在线下载自己喜欢的音乐，但是技术上解决不了版权保护的问题，导致行业发展缓慢。在苹果解决了支付、下载和播放问题之后，解决了在线下载的问题，同时成就了 iPod 的成功。

显而易见，真正可以成功的，一定是结合了商业、技术和人的体验创新。

解决方案

基于上述三个规律，并结合自己业务管理中的挑战，我提出了如下的企业 B2B 服务线上加线下的迭代打磨解决方案 —— ESI(Enterprise Service Iteration）即企业服务迭代。

首先满足规律一，这是一个通过迭代获取认知的过程。一次迭代过程包括了商业价值、业务流程、IT 产品以及研发。这样可以做到商业和 IT 不脱节，一起获得正确的认知。

其次结合了规律二康威定律，强调线下组织结构和 IT 产品系统架构一致。每次迭代都会根据商业价值，对线下组织结构进行一定的优化。例如，在前面介绍的抢单案例中，可以先拿线下的一个团队的组织结构进行微调，某一项业务支持抢单。这样逐步打磨线下组织结构和 IT 产品系统架构。

最后，遵循了规律三设计思维，在打磨中同时考虑了商业、技术和人。例如，在抢单案例中，考虑了抢单对商业效率的提升，技术上如何支持抢单，以及对参与抢单者进行激励。

通过 ESI，建立了端到端的企业 B2B 服务打磨，包括商业价值的识别、业务 SOP 优化、组织结构的优化、激励（游戏化）、IT 产品定义、IT 产品研发、产品发布、培训和运营等步骤。

下面将以前面提到的线下巡检业务为例，介绍 ESI 的每个步骤，以及迭代的过程。

步骤一：商业价值。对基础设施运营来说，线下巡检是一项基础服务。我们的典型场景是一次巡检需要巡视 50 个点。每个点平均耗时 3 分钟，抄写 3 个设备参数，检查是否漏水，是否异响等。纯线下巡检，对巡检质量及是否按时巡检，是否已巡检全部巡检点等服务要求很难考核。所以我们希望结合 App 做线下巡检，准确记录巡检时间、抄录的设备参数，确保巡检无遗漏，按时完成，并可以持续提升巡检质量和效率，从而降低运营风险。

步骤二：业务 SOP 优化。基于对巡检商业价值的提升，我们制定了新的 SOP（标准操作手册），添加了使用 App 进行巡检的操作要求，并且对 App 的功能从业务层面进行定义。同时添加了一个 App 巡检质量打分步骤，确保每一次巡检都有一个质量评估。在 SOP 中，还定义了结果指标，例如巡检质量，以及过程指标，例如巡检时间方差等。

步骤三：组织结构优化。既然添加了一个 App 巡检质量打分机制，我们也增加了一个巡检质量分析员的角色。这个角色将完成巡检质量分析，并将结果反馈给运行主管。在运行主管的工作职责上，增加了巡检质量报告分析，持续提升巡检质量的岗位职责。这些都是在对组织结构进行优化。

步骤四：激励（游戏化）。为了让员工接收 App 巡检增加的工作量，我们还制定了激励方案。对每位员工每个月的巡检工作进行打分，赋予相应的金币，做排名，金币还可以转化为红包。

下图就是我们最终展示的员工积分情况及排名。

步骤五：IT 产品定义。通过收集 SOP，组织结构以及激励的需求，进行 IT 产品定义，完成产品功能需求以及页面设计等。

步骤六：IT 产品研发。研发工程师根据 IT 产品的定义，完成相应的研发工作。

步骤七：IT 产品发布。研发结束之后，发布对应的 App 及小程序。下图就是我们发布的小程序。通过这个小程序，可以查看每天、每次巡检任务的完成情况等。

步骤八：培训。IT 产品经理在产品发布之后，对相关人员进行培训。以巡检为例，培训的内容不仅仅是如何在巡检过程中如何使用 IT 产品，还包括了新的 SOP，以及如何赚取打赏等。

步骤九：运营。我们会每天、每周从 IT 系统中抽取相关的过程指标和结果指标。

首先是巡检的结果指标：巡检质量。下图是我们试点的几个项目的巡检质量历史曲线。其中可以看到有平稳的，有波动大的，并在持续改进的。

通过对具体波动产生原因的分析，我们可以看到一些更具体的过程指标。例如下图中展示的每个项目的巡检过程指标。通过过程指标，可以找到质量波动的原因。

在通过运营获得了数据之后，通过对这些数据的分析，提出对 SOP 优化的需求，IT 产品优化的需求，激励优化的需求等。例如通过对运行数据的分析，我们优化了巡检过程中输入数据的键盘，减少了每个巡检点录入数据的时间等。

经验总结

在打磨企业服务的过程中，通过采用 ESI 方法，并进行多次迭代，我们明显感觉到线上 / 线下的结合更紧密。我们可以通过线上的数据优化线下的服务质量，同时通过线下的服务过程，优化线上 App 的功能和数据采集方式。在多次迭代之后，我们的企业服务相比原来传统的纯线下服务，大大的提高了巡检质量, 提升了客户满意度，并且通过积分打赏的方式，大幅提升了员工满意度。

下面是 ESI 迭代打磨中的几点经验总结：

每次迭代中，要尽可能明确需要提升的商业价值，并且这个商业价值应该是可以用数字来衡量的。

在第一次迭代中，根据业务的需要可以不实施步骤五到步骤七，也就是说在没有 IT 产品的帮助下，通过线下的手段来打磨企业服务。这种情况通常是通过线下 +Excel 等方式，先打磨出一个企业服务的雏形，这种雏形的企业服务相对比较灵活。在初步探索之后，后续迭代中，再加入步骤五到七的 IT 产品研发。这样可以加快对客户价值的响应，并且积累产品需求。

一线员工的积极性非常重要，必须加入对一线员工的激励。特别是在传统的企业服务中，一线员工有可能会认为使用小程序 /App 是增加了他们的工作量，是公司在监管他们的工作，导致产生抵触心理。通过游戏化元素的加入，可以让他们更容易接受小程序 /App 的使用。

上述是我对 ESI 打磨企业服务的经验分享。有疑问欢迎在留言区进行探讨，提出反馈意见。感谢收听，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

吴晖，TGO 鲲鹏会会员，金扳手 CEO，原 OKCHEM CTO、副总裁，原 SAP 大中华区 OEM 售前团队负责人，HP 企业服务电信 / 云计算研发团队负责人，微软技术支持中心企业运营经理等。复旦 - 奥林商学院 EMBA 毕业，混沌大学首期创新商学院学习，管理经验丰富，对创业有深度思考。

第196讲 | 邱良军：关于做好技术团队管理的几点思考

你好，我是极智嘉研发总监邱良军，一个 18 年的 IT 老兵，其中有 8 年管理经验，包括研发管理、项目管理、运营管理。在打造高效技术团队之准备篇和招聘篇中，我们讲了对技术团队的基本认识和团队的招聘要点，今天我们继续聊聊打造高效技术团队时如何进行团队管理。

选对人是第一要务

如果你是一名技术出身的软件工程师，对照自己就会发现，技术人员的特点还是比较鲜明的，让我们看看技术团队成员有哪些明显的特点：
1. 高智商，低情商
2. 多数不善于沟通及协作
3. 有反叛性格
4. 充满好奇心
5. 性格固执，坚持己见
6. 常常不听从管理（尤其是心情不好的时候）

看到这几条，估计你已经心领神会了， 如何管理这样的一群人确实让人头痛。尤其是作为团队管理者的你也是技术出身，就更麻烦了。在技术团队中，我们遇到最多的问题就是针尖对麦芒，经常会对一些技术问题争论不休，彼此谁也不服谁；如果管理者也是技术高手，就更会加入技术细节的争论中，又或者直接代替下属把事情给做了。在这样的背景下，如何打造一个有战斗力的技术团队，并高效完成设定的项目目标，或者开发出一款好的产品呢？

按照 PMBOK 中所写的团队发展理论，打造技术团队分组建、激荡、规范、执行四个阶段，理论相关的可以参考相关项目管理类书籍。我在前文打造高效技术团队之招聘篇中就已经强调过：选对人是第一要务。在初期组建团队的过程中，我们的主要目标是:

把招聘过程中出现的误差（选错的人）识别出来，对于已经给过多次机会但是发现能力确实不行或者还是不能胜任当前岗位的人，一定要及时处理。培养悟性极低或改变不喜欢这份工作的人是极其困难；

带有负能量的人，必须马上下决心放弃；

通过大小战斗磨合历练团队，从小战役开始打起，没有打过仗的士兵不是好士兵，更当不了将军；

每个团队成员的情况都不一样，用心呵护你的核心骨干，他们是团队的支柱；

对于核心成员，必须给予充分信任和授权，给予试错机会，每月复盘结果，做 PDCA 循环；

打造技术团队的经验与收获

接下来分享我打造技术团队的几次经历过程：

第一个案例：

2014 年底，我加入了一家大型软件外包的内资企业，需要迅速从 0 开始组建一支项目团队，目标规模在 20 人左右。业务逻辑比较复杂，技术要求并不高，最重要的就是快。在做好人力资源规划和预算后，我就开始想各种方法组建团队。

首先，从其他团队借调了 4~5 人作为核心骨干和小组长；组织专场招聘会从社会上招聘（面试尽量放低要求，用人之长）。团队组建非常迅速，然而从内部借调的人员因为出差等各种原因出现了一连串的问题，中间经历各种奇葩的事情：有的以各种理由不服从项目安排，有的家里有事经常请假，有的手上还带有其他项目只是过来打个酱油，还有的是刚刚招聘过来能力根本不行只是强行凑数而已。

面对这个全是坑的局面，我不得不痛下决心让借调人员全部回去。一方面加紧做社会招聘，并对不合格人员及时做淘汰优化（态度不行的马上处理，以及每月一次复牌优化）；另一方面，自己也参与开发，并重点做代码评审，自己每天 7 点开始工作直到晚上 12 点。经过 3 个月时间的磨练，团队基本组建完毕，项目也进入了正轨。

在此之前，我一直在外企带项目，开发计划、流程都很规范。而这段狗血的组建团队的过程让我数次都有想离职放弃的念头，最后还是坚持下来，感觉收获很大，以下是这次管理团队的心得：
1. 大企业部门的墙厚重，不要轻信别人答应的事或是自己听到的事，必须亲自参与；
2. 外企和内企的管理方式、开发流程和文化方面的差异巨大；
3. 沟通、沟通、再沟通，做好项目干系人分析，包括客户、直接领导、兄弟部门以及团队成员；
4. 如果是从 0 开始打造团队，团队负责人几乎需要什么都会，哪里需要就要去哪里填坑；
5. 坚持、坚持、再坚持，度过难关后就会见到彩虹；

在这半年后，又一次需要紧急组建一支呼叫中心的项目团队，团队需要有相关系统开发的经验并且时间非常紧急。不得不再次考虑从公司内部借调专业团队，由于有之前的前车之鉴，这次人员借调比较谨慎，设定了几个要求：

宁缺毋滥，必须仔细面试和做调查背景；

借调时间至少半年。

在面试了这个小团队的组长后，感觉和预想的完全不一样。从技术、管理、理念一路聊下来，有很多共识，感觉非常好。接下来就是团队过来、项目启动、进入正轨，并且通过社招扩大团队到 10 多人。通过这次经历深深体会到：
1. 人和人不一样，选择一个好的负责人，太重要了，选对项目负责人是项目成功最关键的一步；
2. 做好沟通，以及团队服务支持工作，定时激励团队。

第二个案例：

2012 年底，我空降到某外企一个 30 人左右的团队，并经过 2 年左右的时间将其发展为超过 60 人的团队，由于流程规范，整个过程比较顺利，在此过程中有几个关键节点分享一下：

1. 接手团队的开始阶段，要和每个成员交流，并与核心成员深入交流，前面 2 个月主要是听和观察为主。其后逐步梳理团队，重点培养提拔 2 个骨干，并把一半以上的团队交给他们俩来管理，只授权不干预，效果很不错。而自己亲自来带相对不成熟的小团队。

2. 在团队扩展发展过程中，遇到了很大的麻烦，有一个几乎不可能完成的紧急任务。最后通过成立临时突击队、封闭式开发（每天到晚上 12 点，周末至少加 1 天班，核心关键成员取消周末）、借调高级工程师等各种手段勉强按时完成。项目完成后及时奖励了团队，包括申请了一笔奖励金和放假 3 天。比起项目完成的成果，团队能力的提升更为重要，一个 Leader 获得晋升并得到重用，此后我们获得了承接更多项目的机会，扩大了团队规模。

3. 接手团队 2 年后，绩效考核面临非常大的挑战。通过打各种战役，团队成员能力提升快速，团队规模持续扩大。但是外企吃大锅饭、晋升缓慢的特质及其涨薪制度，跟团队成员的期望形成巨大的落差，即使通过各种努力争取到了公司最大支持。最后还是形成了离职潮，当时是非常失落的。现在看起来未必是坏事。很多成员抓住了新的机会，他们在未来的职业生涯中获得了非常好的发展。

这段经历不仅让我认识到规律不可违背，还让我学会了如何做授权来培养 Leader，并且自己经常亲自带新员工和初级开发。正因为对新人培养的投入，这对以后两次的工作变动和组建团队起到了至关重要的作用，他们或自己加入我的新团队，或帮助我推荐了核心骨干。因此，最好的找人方法就是你曾经培养过的团队成员，以及由此积累的口碑，正所谓：种下善果，积累福报。

通过管理技术团队近 10 年的经历，我总结积累了四条经验分享如下：

1. 管理好新员工，不论你做多大的准备或努力，提升新员工的满意度，激发新员工的潜力，是你必须要时刻放在心上的头等大事，你要总是为新员工的第一天入职做好充足准备：高调介绍新员工给所有人，给予明确的试用期目标，指定一名靠谱导师，一起吃顿饭。而后，每周、每个月、直至试用期前的考核都是重要的节点。留与不留一定要在试用期结束前做出决定。
2. 处理好问题员工，要求问题员工限期整改，不要把问题员工留到试用期后。但是试用期后，如果还是发现有问题的员工出现，可以借鉴京东对于问题人员的定义及处理：

无德无能的人（称为废铁），坚决不留，并且反思招聘过程中出现的问题。

无德有能的人（铁锈），不能久留，及时找人替换。

有德少能，对于价值观认同的，给予提升能力或换岗的机会。

3. 服务好优秀员工，优秀员工是公司的最核心资产，通常公司 80% 的价值是他们创造的，并且他们也是整个公司其他员工学习的榜样，必须把他们树为标杆。作为管理者，你的首要任务就是利用一切条件服务好他们，给他们创造好的工作环境，激发他们的潜能。正如 GE 杰克韦尔奇说过的，“失去最优秀的前 20% 人才，是领导者的失败，留住最差的 10% 也是一种过错”。
4. 最后是普通员工，一个团队一定会有能力普通的员工，这个是现实也是规律，作为管理者要时刻需要鼓励大家向标杆学习，依靠流程制度来管理。日常管理中，向团队多问问题，抛出挑战性的问题，不要急于给出结果（偶尔抛出错误问题也没有关系，如果经常出错，就应该自我反思补短板了），让团队自己找答案，技术团队的特点是喜欢接受挑战，作为技术团队的 Leader，发现问题、提出问题要比解决问题更重要。

识别出不同员工，做好以上几点的处理，不论团队规模多大，你就基本掌握了团队管理的秘诀，并且不会随着团队的扩大而手忙脚乱。让优秀的员工，特别是有管理能力的优秀员工再去帮助你带团队，培养能够带团队的管理者，你的团队将会发生裂变，你自己的认知也将随着团队的发展而提升，你将能轻松应对团队的迅速发展。在此过程中不断的学习思考，你一定会成为一名优秀的领导者。

核心骨干的培养

团队的核心骨干是指那些专业技能强、行业知识丰富的员工以及基础管理者，具体包括架构师、核心开发（高级工程师）、产品经理或者需求分析师、团队组长和技术经理等，如何激发团队的潜能是每个技术管理者必须思考的问题。

总体的原则是用人之长、避人之短。对于技术能力强的架构师及高级开发工程师要安排到关键开发岗位（核心模块的开发），多做技术分享等；对于团队组长及技术经理，必须给予足够的授权，同时需要深刻认识到部分优秀工程师不一定适合做技术管理，需要不断提升他们的管理能力。由于个体的差异，每个人的管理方式也要有所不同，我大概分了以下几类：

1. 启发型 - 导师型，适合求知欲比较强，技术或者管理经验比较好的，同时对管理者自己的要求比较高，是最理想的领导者，又是最难做到的。
2. 指导型 - 老师型，适合经验不是太足的，比如刚刚开始做组长或者技术经理的，技术上也是入门时间不长的。
3. 甩锅型 - 授权型，适合经验非常丰富，技术能力或者管理能力强，责任心强的人。
4. 无为型 - 放羊型，适合自律性非常强，团队是做创新项目，短期目标不明确的人或团队。
5. 服务型，和第一种启发型是对应，不过由于领导人本身不可能在所有领域多精通，这个时候就作为服务者做好服务：帮助团队排除外部干扰，做好信息透明沟通顺畅，做好后勤保障及员工关怀。

培养好核心骨干的益处非常多，第一，对于自己的能力成长很有帮助，从他们身上可以学到很多东西，可以让自己保持不断学习的动力。第二，对于公司非常有帮助，工作中 80% 的工作（财富）都是他们来完成的，他们是公司的核心资产。第三，对于核心骨干自己也是非常有益的，他们获得了成长锻炼的机会。最后你也将获得最难能可贵的人脉资源，珍惜并培养这些核心骨干，将是你最值得做的事情。

提升自己，管理自己

作为技术管理者，我们还需要提升自己的视界和领导力：

需要经常了解外面发生了什么，了解前沿的技术发展，通过外部力量来影响团队。

紧跟时代的特点，了解新的资讯、新的变化，80 后、90 后、甚至 00 后都慢慢步入社会，管理方式也在变化，自己也需要做出调整。

及时学习补充管理理论，必须牢记管理也是一门学问（很多技术出身的管理者常常认为技术人员是不需要管理的，特别是自己比较自律的那种），而技术人员往往容易做违反管理原则的事情，比如：事必躬亲，过分自信，通过自己努力虽然能解决部分问题，但是效果通常不好，长期如此团队成员没有发挥锻炼的机会，这样的管理者是培养不出人才，打造不出好的技术团队。最后自己累死了，也没把事情做好，更难把业务做大，最后还想不明白为什么？我们要牢记“专业的事情由专业的人去做”。要学习熟悉管理理论中的一些常识，比如 2/8 原则、PDCA 戴敏环、墨菲定律等等。

作为技术出身的管理者，还要学会从“自己做事”中跳出来改变为“指导团队做事”、以及“引导团队做事”。

多思考问题，多角度想问题，把问题想透彻，方法论比解决单个问题更有价值。

作为领导者，与其说是管理团队，不如说是管理自己。这里有两种能力非常重要：第一是认知能力，对于事情的判断要有自己的原则标准，以此来指导自己的工作，建议可以看一下《原则》这本书。第二是知行合一（就是心学大师王阳明倡导的），领导者是孤独的，不被理解将会是常态，你不得不向自己内心寻求答案，那里将是一个更为广阔的精神世界。

作者简介

邱良军，极智嘉研发总监，TGO 鲲鹏会会员，负责组建极智嘉苏州研发团队，以及筹建苏州研发中心， 4 个月将团队发展到 40 人，并承接两个系统开发，数条支持线的工作。曾在新电任职超 10 年，带领团队交付数个项目，团队峰值人员超 70 人。2014 在文思海辉担任总监，从零开始将团队带至 300 人。18 年 IT 老兵，管理经验丰富。

第197讲 | 邱良军：做好研发管理的3个关键

你好，我是极智嘉研发总监邱良军，一个 18 年的 IT 老兵，其中有 8 年管理经验，包括研发管理、项目管理、运营管理。前三篇我们讲了对技术团队的基本认识、团队的招聘要点、以及团队管理的要诀，今天我们继续聊聊打造高效技术团队时如何做研发管理。

项目管理包括了 5 大过程、10 个领域和 42 道管理过程，这边我们不展开细讲，有兴趣的可以看项目管理的相关介绍。

研发管理简单来说就是如何高效的写代码、做产品及做运维支持等。主要研究方向有软件开发生命周期管理和项目管理，包括项目管理 PMP 认证、瀑布开发主流模式 CMMI 软件成熟度模型、Agile 敏捷开发（前有 XP 极限编程，后是主流 Scrum）、DevOps（开发运维一体化）等。

过去个别大神一个人就可以开发一套系统，不需要分工、不需要团队协作，甚至不需要各种工具，研发管理就会变得非常简单。然而现实生活中，情况往往比较复杂。这里我们分析一个成功的 IT 创业公司在快速发展过程中，研发管理是如何伴随着组织扩大和组织架构演变进化的，我们一般可分为三个阶段或三个层次：

第一阶段是公司的创业初期，创始团队中往往有技术强人和产品牛人，大家齐心协力目标一致，就是把产品尽快做出来，推向市场或者寻找客户。研发管理主要关注技术和产品，其中产品（或业务）又是最主要的，这时候考虑的是客户的痛点需求，而研发效率是最关键的，用最少的钱办最重要的事情。

在这个阶段，团队规模小、目标一致，基本不需要管理，主要是个人技术能力 + 行业洞察能力的叠加。之后团队开始扩大发展，产品功能不断完善，研发管理关注的核心点主要在系统稳定性、产品系统不出现性能问题等方面上，团队的协作主要依赖于协同软件的使用，开发模式通常会选择敏捷开发、快速迭代的方式来做，团队加班加点是常态。

第二阶段是公司初具规模，一般到了 A/B/C 轮融资，研发团队接近或超上百人，甚至几百人。由于业务需求的急剧扩张，客户迅速增加，对于系统功能和性能的要求越来越高，还有安全性、高可用、稳定性等等要求，团队忙的应接不暇，而初期产品牛人和技术强人都做了团队管理者。

在这个阶段，研发团队通常处于混乱期，然后开始寻找解决方案，一般来讲，第一步是梳理流程，各种会议没完没了的开，最后基本是参考 CMMI3/5 模型来提升研发管理能力。再按照分工拆分为产品、开发、测试、运维、架构等团队，开发还要继续拆为前端开发、基础组建、中间件、架构等团队。各团队清晰地划分职责，加上各种关系、成员个体能力差异，各种争论互怼经常发生，慢慢的就形成了部门墙。到此为止，公司步入研发管理标准化阶段，同时伴随着更大的问题是研发效率不断下降，客户满意度和管理层的满意度急剧下降，公司出现危机。

第三阶段是公司达到几百甚至上千人的研发规模，各职能部门都建立起来了，研发效率却越来越低，做什么事情都特别难，客户抱怨员工也抱怨，危机四伏。创始人及核心骨干特别怀念创业之初金戈铁马，气吞万里如虎的潇洒自由。

在这个阶段，为了拆除厚厚的职能部门墙，研发管理的组织架构不得不再次做调整，增加 PMO 项目办公室，临时组建项目团队来打各种战役。开发模式演变为 CMMI 瀑布式 + 敏捷迭代模式相结合的方式来推进，并不断做精细化管理。我之前参加过软件精细化管理的一门课《Lean Six Sigma》，课程内容是参考丰田汽车的制造过程设计的，非常的不错。此外，在软件研发发布过程、测试及运维过程中，这个阶段的研发团队都在推自动化、智能化工具的使用，让有风险和重复性的工作变得快速而简单。

研发管理的成长就是技术积累、业务理解、研发效率和风险控制的平衡发展过程，我们应该从实际出发，根据公司和团队发展的不同阶段而灵活使用不同的方法。总得来说包括了对产品的理解（行业知识累计），还有技术水平（研发能力、含运维）、工程效能和流程管理等诸多方面。

产品和业务

一个段子说：CEO 负责吹牛，销售负责让客户相信 CEO 吹的牛，CTO 负责让 CEO 吹的牛变成真的。这个过程就是把 CEO 吹的天花乱坠的产品做出来，并且是在有限的时间和成本内把好的产品做出来。不过，业务类型的不同会产生很大的差异：对 ToC 业务，产品体验是至关重要的；对 ToB 业务，很多系统在签合同的时候还是个 Demo，快速完成就非常关键。

不管公司是在初创阶段，还是在快速发展阶段，产品的好坏始终是最关键的，它决定着公司是否能赚到钱，决定着公司的生死。公司的一切必须围绕着产品来转，现在流行说人人都是产品经理，说的就是这个理。

研发管理的难点之一就是技术团队对业务的理解、对于产品的理解。在我的职业生涯中，做的都是 ToB 的业务（B 是 Business，指企业客户），并且主要是做的大 B，有金融行业、半导体行业、仓储机器人行业等。对于技术管理者来说，如何做好对产品业务的理解是一个巨大的挑战。以下是我经历以及观察到的如何去理解产品和业务的一些实践：

培养具有程序员思维的产品经理，或具有产品思维的程序员，通常乐于沟通、勤于沟通的程序员经过 1~2 年的锻炼就可以对行业比较熟悉。我曾经花了一年的时间专注学习国际银行监管的巴塞尔协议，并组织团队内部做业务知识的普及讲解。每周通过邮件做一次业务知识的推送，给团队创造一个学习了解业务的氛围。如此，也可以让产品经理和研发团队之间形成一些共同的语言，提升团队之间的沟通效率，甚至于开发也可以给产品一些建设性的建议。

理解业务最好的方式就是从自己的生活出发，曾经我一个新加坡同事为一家银行研发一套银行开户系统。他想要快速地理解业务知识，并能及时了解系统上线后的运行情况。为此，他到此银行开了各种银行户头，并且存入少量的钱，自己掏钱来操作各种业务，包括线上和线下的操作。同时，他也到本地另外一家最大银行也做了相同的事情。通过在不同银行开户，了解了哪些是银行开户中的相同流程，哪些有差异；通过真实的开户及用卡体验，了解了银行开户的业务流程知识，并不断优化正在研发的系统。当这位同事到上海出差的时候，他也不忘这个事情，马上以外国人的身份到上海分行做开户体验，如此他既能了解中国分行的流程，又能进一步了解中国银行的一些监管要求。他把类似经验也分享给研发团队的其他人，整个团队对于产品业务的理解非常快速，开发出来的产品功能自然令客户满意了。

产品设计遵循 MVP 原则，在开始设计产品时不要追求一个完美的产品需求 (实际上这样的完美需求也是不存在的），而是通过提供最小化可行产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到产品到达一个相对稳定的阶段。这样可以快速验证团队的目标，快速试错。

业内很多厉害的产品经理也是出身程序员，最有名的要属微信之父张小龙，其他的还有雷军、马化腾等都是技术达人 + 产品经理，所以技术团队也可以有产品思维，甚至于可以打造一支技术与产品兼顾的复合型团队。

技术和架构

研发管理的核心能力就是技术能力，产品的需求要转换为产品，最终依靠的是系统架构、代码质量。对于研发管理，这里我们需要防止两个极端：

第一种，追求技术上的完美，在系统设计的时候一上来就是高可用、高活、分布式、并发上万、亿级数据等，等系统做出来时，黄花菜都凉了。“好的架构不是设计出来的，而是进化出来的”，这句话被很多人引用，并不是给糟糕的起步寻找借口。就像前面一节说的，技术是为产品服务的，系统设计之初，速度是关键。To C 业务需要快速获得客户，取得收入或者融资；To B 业务的客户通常更着急，恨不得签完合同就要上线，当然公司为了快速获得收入也是希望尽快上线验收。

第二种是完全不管架构技术，只要能做出来就好，系统的稳定性极差，体验也不好。这样的系统即便是交付上线了，用户也会失去耐心，产品也就失去了意义。

因此，在系统不断迭代的过程中，我们需要不断做架构调整演化，代码也需要不断做重构调整，以适应业务发展的需要。在预算许可的条件下，适当的做 6~12 个月的业务前瞻。

在做研发管理的时候，我们还必须做好质量管理，其中代码质量是非常重要又极其容易被忽略的，工期或者资源一紧张，或者团队发生入离职的时候，代码质量就很容易失控。由于人员变化、新的需求功能的增加及变更，废代码、垃圾代码、不规范代码、奇葩代码、天书一般的代码都会出现。这几乎是研发过程管理中绕不开的梗，甚至上升到了软件工程师人品的高度了。对付这个的问题可以加强代码精细化管理：一方面可以使用代码扫描工具（比如 Sonar），另一方面加强代码人工审查。

在代码的重构中，特别是系统到一定的复杂度后，我们需要对代码做一定的减法，包括删除废代码和注释掉不用的代码，还有详细看一下代码逻辑，避免重复代码，重复造轮子。还可以利用一些已有的开源代码来替换写得不理想的代码。利用一些设计模式来简化系统的复杂性，提升代码的复用率。

工程效能 - 研发流程及工具使用

工程效能是研发管理中非常重要的一环，研发团队不断发展，工程效能的重要性就会日益凸显。在团队规模超过 100 人，甚至达到 1000 人时，就需要专门的人或者团队来关注这块了。工程效能的核心是在符合公司流程要求（风险控制要求）的前提下，提升各团队协作的效率。现在比较流行的是敏捷开发和 DevOps 两套方法论的使用，两种方式都是大量地使用自动化工具来提升效率。

敏捷开发是是软件研发团队管理的一种方式，要求团队成员都是自我驱动、自我管理，从而达到敏捷团队的自管理组织，JIRA 支持的 Scrum 是敏捷的方法之一。JIRA 可以做需求管理（User Story）、缺陷跟踪、任务管理等等，JIRA 还提供了专门的 Scrum 视图和 Kanban 视图等，特别适合敏捷开发团队使用。大型互联网公司如 LinkedIn、Facebook、eBay 等内部几乎都在使用 JIRA，我们公司也是使用 JIRA 来管理整个软件生命周期，并且是敏捷的开发模式。

DevOps 涵盖开发、测试、发布、部署以及运营、监控一体化的过程管理，通过自动化工具的使用，把持续集成、持续交付、自动化的部署发布和监控、持续反馈和优化过程勾连形成一体化，又叫开发运维一体化。通过 IDE 集成 Git 和 Sonar，在代码提交时做自动扫描检查，再通过 Jenkins 把 Maven、JIRA、Git、Jmeter 集成起来做到自动化的部署发布，以及 Docker 镜像、zibbix 自动监控等，最后通过短信、邮件、微信、Jira 等系统可以实现报警监控的自动化。

总结一下研发管理所讲的主要几点：
1. 从 10 人以下技术团队演化到几百上千人时，组织架构发生的裂变和团队分工，由此产生的乱弄和低效，再到部门墙的产生是无法避免的，最好要考虑好如何拆除部门墙，所谓分久必合合久必分。
2. 和研发管理相关的项目管理的知识，包括软件过程管理（开发生命周期），以及瀑布开发（CMMI）和敏捷开发（Scrum）等。
3. 研发管理的核心重点是产品、技术、工程效能。

在即将讲完团队管理及研发管理的时候，总结一下我对做事、管事及管人方面的理解和思考：

做事的本质是“高效自驱”，这样的员工谁都喜欢，并且这样的员工也会获得更多晋升和重用的机会。秘诀是勤学勤练，提升专业技能，做事靠谱、高效，有责任心。

管事的本质是“抓执行，勤反馈”，形成闭环，并不断通过总结和反思做提升。秘诀是思考问题的本质，找出根本的解决办法，最后形成流程和方法论。

管人的本质是“知人性，有人性”，每个人的个性都不同，然而人性却是相通的，学会换位思考，己所不欲勿施于人。秘诀是自我修养，知行合一，修炼自己的人品、口碑、心态最为重要。

作者简介

邱良军，极智嘉研发总监，TGO 鲲鹏会会员，负责组建极智嘉苏州研发团队，以及筹建苏州研发中心， 4 个月将团队发展到 40 人，并承接两个系统开发，数条支持线的工作。曾在新电任职超 10 年，带领团队交付数个项目，团队峰值人员超 70 人。2014 在文思海辉担任总监，从零开始将团队带至 300 人。18 年 IT 老兵，管理经验丰富。

第198讲 | 徐林：通过快速反馈建立充满信任的技术团队

你好，我是徐林。在我看来，打造具有战斗力的团队，首先要建立成员之间的相互信任，就像打仗冲锋一样，一声令下，谁也不希望只有自己一个人冲出了战壕。作为公司的技术 leader，应该如何建立技术团队的信任呢？你可能很快会想到沟通和互动，就像敏捷宣言第一条宣扬的那样，“个体和互动”高于“流程和工具”。

没错，人在互动中才能增进了解，相互了解才能建立情感，有了情感才可能加深信任，就像我们常说的“没有什么事情是一顿烧烤解决不了的，如果有就两顿”。但是，建立团队信任只靠“吃饭聊天”是远远不够的。

LinkedIn 首席执行官杰夫·韦纳（Jeff Weiner）认为，“在时间的流逝中保持一致就是信任”，这个“一致”有很多含义，如目标的一致、行动的一致等；微软首席执行官萨提亚·纳德拉（Satya Nadella）认为，“信任 = 同理心 + 共同价值观 + 安全可靠”，他把“同理心”放在了信任等式的第一位，认为无论做什么事情，都需要大家对所做的事情产生共鸣。

虽然两位 CEO 对信任的描述不一样，但是建立信任的方法可以归纳为关键的一点：通过同理心来确保目标和行动的一致，消除信息不对称。站在他人的立场思考问题，对他人的关切进行快速反馈是富含同理心的一种表现。接下来，我想分享下我们团队是如何通过快速反馈加深信任的，希望对你有所启发。

一、员工对领导的关切快速反馈

领导最关心的是交给员工的任务什么时候能完成，完成的怎么样或有什么风险。员工如果能做到“凡事有交代，件件有着落，事事有回音”，在领导的眼里才是靠谱的，是值得信任的。举个例子，我们一个版本交付，少则几十号人，多则两三百号人，会在向上级进行开发状态反馈时使用多种不同方式，比如：

通过晨会向特性责任人反馈开发和测试风险；

通过项目例会向项目经理反馈进展和诉求；

通过项目周报向更高级别领导反馈项目偏差和应对措施。

通过这些方式，可以使每一级领导都获得自己关心的信息，感觉一切都在自己的掌控之中，自然就会对交付团队充满信任。我们常说要做好向上管理，那如何做好向上管理呢？最直接的方式就是站在领导的视角思考他们对员工的期望，管理好这些期望才能不让领导失望，并使他对员工充满信任。

二、员工对其他员工的关切快速反馈

团队合作中，每个成员的工作多多少少都会和其他人有一些上下游交互，如果上游的人总是能够对下游人的诉求快速响应，无疑会让下游的人感觉更加安心。以我们的交付团队为例，我们有专职的集成测试团队，他们要负责软件发布前的最后一轮验收，但是开发团队的交付延迟总是会把集成测试团队搞得手忙脚乱，团队内的相互指责也从来没有停止过。

后来，我们引入了统一研发看板系统，使得每一个员工的任务都在看板上可见，任何下游的同事都可以看到其依赖的上游员工的进展和潜在的风险。通过这套实时反馈系统，下游员工可以提前了解风险，以便及时采取应对措施，那种一无所知的不信任感很容易就消除了。可见，员工之间要及时进行沟通，才能及时获取自己关切的信息，团队人越多，沟通效率越低，越要想办法增加沟通的带宽，而构建可以透明呈现所有人信息的系统是一个不错的实践。

三、领导对员工的关切快速反馈

员工对于团队未来的规划、发展方向以及个人相关的升职加薪机会都比较关心，谁也不希望黑天鹅到处飞，比如今年寒冬中的某些互联网公司，员工上午还愉快地写着代码，下午就被离职了。如果员工每天都在担心下一秒公司倒闭或是自己被炒鱿鱼，那么还谈什么做好本职工作呢？所以，领导有责任也有义务为员工建立一个确定的、稳定的和值得信赖的工作氛围。在我们的团队中，领导会做以下几个事情来建立这种氛围：

1. 年初，领导会就业务经营情况、业务规划与全员进行沟通；
2. 在季度会上，领导会与员工进行项目立项、结项情况沟通；
3. 所有员工的任职情况会在第一时间进行全员公示；
4. 基层主管会定期请员工吃饭解疑答惑。

领导作为团队的一员，也要以同理心来考虑员工的诉求，通过这种分层分级的信息反馈，员工对管理团队的信任会逐步加深，心里有底也就能安心做好本职工作了。

1994 年，心理学家 Freeston 等人提出了“无法容忍不确定的程度（The Intolerance of Uncertainty）”这一概念，简称 IU。一系列研究认为，IU 是担心、焦虑产生和维持的关键影响因素，也是焦虑及焦虑障碍的最重要预测指标。对于不确定的焦虑，会影响我们的知觉控制水平，也就是我们所感知到的“自己能够在多大程度上影响事情的结果”。当我们对不确定的焦虑越高时，我们就会越不相信自己能够影响事情的结果，对自己的贡献就会越不信任。

那么要如何消除不确定性呢？从香农的信息论来看，消除不确定性，就要引入更多的信息。对于团队中的个人来说，一方面，及时从领导或其他同事那里获取信息反馈，消除信息不对称带来的不确定性；另一方面，要快速得到我们所从事工作的结果反馈，消除因果未知的不确定性。

以编码工作为例，我们团队通过构筑个人自动化流水线和同行代码评审活动，很好地实现了结果信息快速反馈：开发人员通过 IDE 写完一个函数后，可以一个菜单按钮启动个人流水线，流水线会自动完成代码规范检查、编译、打包、部署和测试，几分钟后就可以看到结果；当他提交代码时，Committer 会进行代码检视并及时反馈检视结果。有了这种快速反馈工具和机制后，我们可以迅速获取自己从事工作的结果反馈，减少个人对工作结果的不确定性，从而消除焦虑感，减小对自己的不信任。

另外，当面对比较复杂的任务时，测试驱动开发（TDD）是一个能更快获得编码结果反馈的实践，它将复杂问题提前分解成多个测试用例，每次编码的目标都定义为使得某个测试用例通过。这样就将复杂问题分而治之，每次编码只关注一个用例，问题复杂度降低了，编码的结果反馈也就可以更快地拿到，极大减轻了程序员的压力感。

小结：

人在面对众多不确定性时，会充满焦虑，一个充满焦虑的团队中团队成员会彼此失去信任，团队没有信任就没有了基本的战斗力，更别说发挥潜能挑战更卓越的目标了。作为技术 leader，有义务为每个成员建立一个相互信任的氛围。比较有效的方法是：提倡每个人都发挥同理心，站在对方的角度考虑对自己的诉求，运用各种方法和工具提升团队内各种信息的交换带宽和效率，让每个人的诉求都得到快速反馈，最大程度消除不确定性是建立信任的优秀实践。

作者简介

徐林，TGO 鲲鹏会会员，华为某产品软件总工，专注 Cloud Native，微服务架构设计与实现，曾在 200 多人规模的交付项目中承担版本 SE 工作，负责方案设计团队人力管理，设计任务分解，技术方案裁决，技术风险跟踪，上游部件及下游客户技术沟通等技术管理工作。

第199讲 | 宝玉：怎样平衡软件质量与时间成本范围的关系？

你好，我是 Groupon 资深工程师宝玉，也是极客时间《软件工程之美》专栏的作者，我今天与你分享的主题是：怎样平衡软件质量与时间、成本、范围的关系。

你会发现，在实际的软件项目中不乏这样的例子：

一个项目，正常估算，要三个月才能完成，但是老板或客户要压缩到一个月完成，而你不知道如何说服他们；

项目开发一半，产品经理告诉你，有一个非常紧急的功能，要增加到这个版本中，你不知道该不该拒绝，或者如何拒绝；

听说迭代模型很好，你也尝试使用迭代模型，但是每次迭代时间到了还是完不成，只能把迭代时间延长，最后又做回传统的瀑布模型了；

你们组用瀑布模型开发，一到项目后期总免不了加班加点赶进度，为什么他们用敏捷开发的加班要少一些？

其实，这些日常项目中涉及时间、成本和范围的问题，都离不开“软件项目管理金三角”的概念。

掌握好这个知识点，学会平衡软件质量与时间成本范围的关系，可以帮助你更好的驾驭项目中的各种问题，也可以帮助你更好地理解软件工程中各个模型，尤其是瀑布模型和敏捷开发。

什么是软件项目管理金三角？

在现实生活中，我们都知道，做产品想“多快好省”都占着，是不可能的，最多只能选两样。想要便宜和质量好，就要花时间等；想要快还要质量好，那就得多花钱；想要又便宜又快，那就得接受难用质量差。

而在软件项目中，也有一个类似的平衡关系，就是软件质量（产品的质量，客户的满意度）与范围（需要实现多少功能）、时间（多久可以完成）、成本（花多少钱）四个要素之间的平衡。

上面这个图就是著名的项目管理金三角（以下简称“金三角”），三条边分别是时间、成本和范围，中间是质量。

为什么四个要素，是“质量”放在三角形的中间？

因为软件工程的目标就是要构建和维护高质量的软件，所以项目的质量是高于一切的。也就是说，“质量”这个因素一般不会妥协，因此把“质量”放在三角形中间，然后在时间、成本、范围这三条边之间寻求平衡。

质量往往也是其他三个因素平衡后结果的体现，想要做的快、成本低、功能多，最后一定是个质量很差的产品。

如何应用“管理金三角”做决策？

我在专栏中常用“道术器”来比喻软件工程中的各个知识点，“金三角”无疑就是“道”级别的。

项目管理其实就是项目中一系列问题的平衡和妥协，而“金三角”理论则为我们的平衡提供了理论指导，了解这三个因素分别对项目其他方面产生的影响，可以帮助你在做决策时进行权衡取舍。

当你接手一个项目，项目的进度、成本和范围指标很容易可以跟踪到。有了这些信息，你就可以及时发现问题，调整“金三角”的边，及时解决，以防止这些小问题发展成大问题。

我来举两个例子，看看“金三角”是如何应用的。

老板要压缩项目时间怎么办？

当项目经理，常遇到的问题之一就是时间被压缩，比如文章中开头举的例子，老板问我一个项目多久能完成，我按照经验，觉得要三个月，老板觉得三个月太久了，要砍到一个月就上线。

最开始的时候，我就是据理力争，说这不科学，肯定不行呀。老板说时间点很重要，必须要一个月上线。结果就是大家吵得不欢而散，最后还得加班加点做，质量也不好。

后来我学乖了，先用金三角知识分析了一下：老板希望时间是 1 个月，也就是说时间这条边被缩短了，那么结果就是会影响到另两条边：范围和成本，如果另外两条边可以调整，也不是不可以。

于是再遇到这种问题，我就换了一种方式跟老板沟通：“一个月也不是不行，就是我们得需求调整一下，第一个版本只能做一些核心功能，剩下的后面版本再加上。（调整范围）另外还得给我加两人，不然真做不完！（增加成本）”

这样的方案一提出来，就好沟通多了，最后重点就变成了砍多少功能和加多少人的事情了。

产品经理要临时加需求怎么办？

在文章开篇我提到一种情况，项目开发一半，产品经理告诉你，有一个非常紧急的功能，要增加到这个版本中，怎么办？我们拿“金三角”知识先套用一下。增加需求，也就是范围这条边要增加，那就必然对成本和时间这两条边造成影响，要么延期，要么增加成本。

面对这种临时加需求的情况，我们也不需要直接说不能加，而是清楚的让产品经理认识到这样做的后果：进度延期，需要更多的成本。如果这个功能真的太重要，可以接受延期，也不是不可以接受，那就重新制定新的项目计划好了。

所以你看，如果我们能应用好“金三角”的知识，很多软件项目中问题，一下子就多了很多方案可以选择了。

瀑布模型和敏捷开发如何平衡时间成本范围的关系？

除了可以将金三角的知识应用在软件项目中，还可以应用它来理解和应用软件工程中的开发模式，尤其是瀑布模型和敏捷开发这两种典型的开发模式。

瀑布模型有严格的阶段划分，有需求分析、系统设计、开发和测试等阶段，通常在开发过程中不接受需求变更，也就是说，我们可以认为瀑布模型的范围是固定的，其他两条边时间和成本是变量。

所以使用瀑布模型开发，如果中间发现不能如期完成进度，通常选择的方案就是延期（加班），或者往项目中加人。

我们再来看敏捷开发，敏捷开发中，是采用固定时间周期的开发模式，例如每两周一个 Sprint，团队人数也比较少，所以在敏捷开发中，时间和成本两条边是固定，就只有范围这条边是变量。

这就是为什么在敏捷开发中，每个 Sprint 开始前都要开 Sprint 计划会，大家一起选择下个 Sprint 能做完的任务，甚至于在 Sprint 结束时，没能完成的任务会放到下个 Sprint 再做。

这时候再想想文章开头我们提到的问题：

听说迭代模型很好，你也尝试使用迭代模型，但是每次迭代时间到了还是完不成，只能把迭代时间延长，最后又做回传统的瀑布模型了。

你现在是不是就明白了：如果不能固定“时间”这条边，就会导致时间也成了变量，迭代自然无法正常推进。

如何平衡好软件质量与时间成本范围的关系？

那么怎么样才能平衡好软件质量与时间成本范围的关系呢？

前面我们说日常生活中“多、快、好、省”最多只能选两样，其实如何平衡好软件质量与时间成本范围的关系也是一样的道理，我们只能最多选择两样，然后在另一边或者另两条边去寻找平衡。

所以第一件事就是：从时间、成本和范围这三条边中找出来固定的一条或者两条边，再去调整另一条边。

下面，我来分析一些案例，帮助你更好地理解。

淘宝网站第一个版本是怎么做到一个月上线的？

这个故事其实我是从极客时间《从 0 开始学架构》专栏看来的，李运华老师在《架构设计原则案例》一文中举了淘宝网站的例子：

2003 年 4 月 7 日马云提出成立淘宝，2003 年 5 月 10 日淘宝就上线了，中间只用了一个月时间。

好，如果你是当时的淘宝网站负责人，马云要你一个月上线淘宝网站，功能还不能少，你怎么办？

第一件事当然是先应用金三角分析一下：时间这条边被固定了，只能一个月；功能也不能少，范围这条边也限制住了，那就只能在成本上想办法了。要么一下子雇很多牛人，要么直接买一个现成的电子商务网站，然后修改。

显然，直接买一个网站，再雇一堆牛人的方案最好，所以淘宝网站就这样在一个买来的网站基础上，由一堆牛人快速搭建起来了。归功于淘宝网站的快速上线，刚推出后，正好赶上“非典”，网购需求增大，淘宝网一下子就火爆起来了。

从成本角度我们还有可以去做的，比如说有同学在看完《06 | 大厂都在用哪些敏捷方法？（上）》这篇文章后，也想在团队里面推行代码审查和 CI，但是苦于搭建这一套 git+CI 的系统没有经验，不知道该如何下手，怎么办呢？

我的建议就是刚开始就没必要自己去折腾了，买一套 GitHub 的企业版，加上支持 GitHub 的商业 CI 系统，花不了多少钱，而且可以节约大量搭建这种系统的时间。

极限编程是怎么做到“极限”的？

前面在介绍敏捷开发的时候，也提到了极限编程（eXtreme Programming，XP），是目前敏捷开发主流的工程实践方法，极限编程的“极限”（Extreme），意思就是如果某个实践好，就将其做到极限。比如：

如果做测试好，就让每个开发人员都做测试

如果集成测试重要，就每天都做几次测试和集成

如果简单的就是好，那么我们就尽可能的选择简单的方法实现系统功能

……

极限编程的“极限”理念，产生了很多优秀的实践方法，例如持续集成、自动化测试、重构等。

这些实践帮助我们可以在短时间的迭代中，产生高质量的代码。我们用金三角的理论来分析一下极限编程在 Sprint 中的应用。

在一个 Sprint 中，计划好了当前 Sprint 要做的工作内容后，那么极限编程怎么帮助我们提高代码质量呢？

一个 Sprint 要做的内容是确定的，相当于成本和范围这两条边都固定了，时间这条边就成为变量了。要么通过加班延长工作时间，要么通过提升效率、减少浪费帮助我们提升时间利用率。

极限编程，就是通过帮助我们提升效率和减少浪费这方面来做的。比如说：

持续集成，通过自动化的方式帮助我们部署，节约了大量需要人去手动部署的时间；

自动化测试，通过自动化测试，节约测试时间，另外，有了自动化测试，可以避免后面修改代码产生 bug，减少了大量的浪费；

只做刚好的设计，避免设计时考虑了太多不必要的可能，造成浪费。

其实我们在项目中也有很多地方可以借鉴这种思路，比如说写代码的时候，少自己造轮子，多使用成熟的开源或者商业组件，可以提升效率；比如把需求想清楚搞清楚再去开发，可以减少很多返工的时间成本！

MVP 模式是怎么诞生的？

这些年流行的 MVP（minimum viable product，最小化的可行性产品）模式，是一种快速推出产品的模式：一开始只推出最核心的功能，满足用户最核心的需求，然后在用户的使用过程中收集反馈，进一步升级迭代。

这种模式怎么诞生的呢？还是应用金三角理论，要快速推出产品，还想成本不用太高，那就意味着时间和成本这两条边是固定的，剩下范围这个变量。

所以最简单有效的办法就是砍掉一些重要性不那么高的功能需求，只保留最核心的需求。通过缩小范围的方式，达到快速推出高质量产品的效果。

类似的道理，我们程序员，在遇到很多功能忙不过来的时候，可以主动的去和项目经理协商，砍掉一些不那么重要的需求，把精力放在核心需求上，保证项目可以如期上线。

总结

其实，要平衡好软件质量与时间成本范围的关系并不难，你只需要记住，最重要的是根据“金三角”的三条边，找出来固定的一条或两条边，然后去调整剩下的边，达到平衡。

软件项目的“金三角”很多人都知道，主要是不知道如何应用到实际的项目中，希望这篇文章能为你提供一些思路，帮助你在项目中真正应用好这个非常实用的知识。

对于质量和时间成本范围的平衡，你有没有什么应用的案例？你对你当前项目的时间、范围和成本都清晰吗？有没有什么可以做的更好的地方？欢迎在留言区与我分享讨论。

感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

第200讲 | 邱良军：沟通，沟通，还是沟通（上）

你好，我是极智嘉研发总监邱良军，一个 18 年的 IT 老兵，其中有 8 年管理经验，包括研发管理、项目管理、运营管理。在前面四篇文章中，我们聊了打造技术团队的准备工作、人才招聘攻略、团队管理要点、以及高效研发管理的关键等诸多内容，并做了理论结合实际的分享。接下来我会继续分享打造高效技术团队中不可忽视的沟通和团队文化建设这两个话题，本篇文章将重点分享沟通的重要作用。

我会主要从以下这几个方面展开：
1. 沟通为什么这么有难度，理解和正视沟通中存在的问题；
2. 沟通不畅给会给团队带来怎样的后果；
3. 沟通的阶段，及高效沟通的技巧；
4. 技术团队如何进行有效的沟通，包括和团队成员沟通、跨团队沟通、和老板的沟通等。

《PMBOK 指南》将沟通管理划为一个专门的知识领域，建议项目经理花 75% 以上的时间在沟通上。根据美国普林斯顿大学的调查报告，在所有对工作产生影响的因素中，沟通占的比例高达 75%。而我们工作中出现的 80% 问题都是由沟通不当造成的，可见沟通的重要性，因为沟通实在太难了。多数时候，我们只想着表达自己的观点，只关注自己想说什么，我们会尽量使用漂亮的 PPT、华美的语言、一堆的数据、甚至引章据典，而不关心别人听懂没有，没有思考别人是否想听，别人是否听得懂。

总的来说，沟通难主要出于以下四个原因：

第一种是由于立场、利益、背景的原因，当双方缺乏信任，或处于敌对状态时是无法沟通的，这个时候的沟通和所说内容的对错没有必然的关系，对方只想找差错，找到了就会理解为阴谋论，并且非常兴奋，所谓道不同不相为谋。这是最困难的沟通场景，越沟通，矛盾分歧会越大，实际是无效沟通。在公司中，经常会因为组织架构设计的不合理，造成团队利益的冲突，从而产生很多的无效沟通。

第二种是由于语言、专业知识、职位、环境的巨大差异，造成沟通方面的巨大鸿沟，本质上是思维方式、常识、知识储备的不一致造成的认知差异，这样的沟通成本非常巨大，需要恶补相关知识，参加专业培训消除鸿沟才能够创造沟通的条件。

第三种是由于沟通信息衰减造成的，语言文字是我们主要的沟通方式，但是很多时候光靠语言文字会有歧义，比如我们对名词概念的理解可能会有不同，甚至可能会完全相反，对语言中所带情绪的理解也不同，而这些都会造成信息的压缩。有研究表明，对话沟通中语言起到的作用仅占 38%，而肢体语言所占的比例高达 55%。你想表达的意思和你说出来的话语会有差异，对方听到的信息和对方理解的意思又会有差异，这就形成了我们通常说的沟通漏斗：

第一个漏掉 20%：你想表达的是 100%，实际表达的只有 80%，主要原因有语言词汇的限制等；

第二个漏掉 20%：听者只接收了 60%，主要原因有信息衰减、听得不仔细等；

第三个漏掉 20%：听者只理解、听懂了 40%，主要原因有词语理解能力、注意力不集中等；

第四个漏掉 20%：最后听者只记住了 20%，主要原因是没有反馈、容易忘记等；

而随着时间的推移，如果不持续做交流沟通，最后的 20% 也会被忘记。

第四种沟通障碍是沟通交流者的心态，这个又和企业、团队的组织架构及文化有关，以下举例一下可能存在的心态对沟通的影响：

刚刚进入公司的时候，把自己设置在一个保护阶段，不愿意主动沟通，或者沟通一次被拒绝和敷衍后，对沟通产生了消极抵制的心态；

因为性格原因，或最近心情不好、不耐烦，对于别人的沟通敷衍了事，甚至怨气很大，给沟通造成了障碍；

还有自以为是、高高在上、得理不让人等心态，都容易在沟通中把简单问题复杂化，把小事弄成大事，造成巨大的沟通成本。

总之，各种因素给沟通交流造成了巨大的障碍，加大了沟通的成本，作为技术团队的主管必须正视这个问题，不能回避，并且需要想尽一切办法来解决它。

沟通不畅的后果

我们必须要理解和正视沟通中可能出现的这些问题，避免陷入无效沟通的处境。一般技术团队是比较单纯的，并且团队成员多数不善于沟通，通常不会出现这么多复杂的场景。但是由此得出技术团队不需要沟通的结论就大错特错了。恰恰相反，技术团队的沟通更为重要，尤其是当技术团队发展到一定规模（30 人以上）时，沟通交流的瓶颈就会显现：团队的每个成员都很努力，大家的能力在此之前也是被证明过的，但就是感觉沟通困难、做事困难，别人不配合（原本的默契没了），自己不被理解，感觉心累。

这个时候多半是沟通出了问题。如果不及时解决沟通问题，就肯定会演变为不信任问题，若是任由问题发展下去，最后团队就会分崩离析。

在实际的工作中，我们经常会遇到这样的麻烦。在 2013 年的时候我带过一个团队，其中的一个核心骨干提出离职，后来经过多次沟通，发现双方其实并没有实质性的分歧。他在原本的岗位上做的很好，平时的工作沟通中也没有发现任何问题，但是由于这份工作对他来说缺乏挑战，慢慢就感到了枯燥，他也经常和同学交流此事，但由于缺乏沟通，我一直没有注意到这个信息，直到最后他提出离职。而与此同时，我却一直因为另外一个重要岗位招不到人而苦恼，这次沟通之后，我直接把他调入这个有挑战性的岗位，一下子解决了两个大难题。这是一个典型的沟通渠道单一的问题，没有做非正式的沟通，不能走进团队成员的心里。

沟通的阶段及应对的技巧

中国式管理大师曾仕强描述沟通有四个层次：不沟不通，沟而不通，沟而能通，不沟而通。前面两个阶段因为知识差距、价值观不同、缺少信任等原因，是沟通最困难的阶段。我们通常需要采取一些非常规手段做沟通的破冰，根据我组建团队，或者与客户沟通交流的经验，总结出了以下 4 个要点：

在缺乏信任的情况下，努力找到双方共同的朋友，这个是建立信任最有效的方式，当然前提是自己在朋友心中的口碑是好的，否则适得其反。我在实际的工作中，多次使用这个方式，非常好的和客户或者同事建立了信任基础，之后的沟通就非常顺利了。

寻找双方共同的点，比如共同的兴趣爱好——下棋、读书、打球等等，还可以是相似的工作经历、校友、老乡等，在初次见面的时候可以拉近关系，找到聊天的话题，为沟通交流开一个好头。

用信息互换的方式做沟通，通过告知对方想要知道的信息，或者对方已经知道的事实来开始最初的沟通交流。这样可以让对方感知到你的真诚，以及让对方觉得交流是有价值的，不过这样的沟通需要提前做好准备。比如对方正在研究一个 Java 多线程的技术问题，如果你过去遇到过类似的场景或有过解决类似问题的案例，都可以分享出来。

体验式沟通，比如非常流行的拓展活动，这是技术团队初创时期或士气低落时一种有效的沟通方式，可以让团队在短时间内做高频率的碰撞、沟通、协作，是团队破冰的最佳方式。我之前参加及管理的团队中多次使用过类似方式，效果都比较好。

后面两个阶段——沟而能通，不沟而通是高效沟通的开始，此时沟通双方已经有了信任基础，并愿意推进双方的沟通交流。此时的沟通分为几个层次，分别可以使用不同的沟通方式。

第一层是公司或团队的日常沟通，可以通过邮件、留言等方式沟通，是异步的沟通方式，一次沟通可以包含比较多的信息，并且可以深思熟虑、考虑周全，是非接触的沟通方式。紧急情况下使用电话沟通处理，非紧急的小事还可以通过微信、钉钉等即时聊天工具沟通，再辅以见面沟通的方式。比较复杂和需要多方参与沟通的，可以组织相关的专题会议做沟通。

第二层就到了沟通双方彼此有默契的阶段，通常是 1 对 1 的沟通，一般会采用非正式的沟通方式，如吃饭、聊天等，当然还有上下级的日报 / 周报等。

最高层是心有灵犀的境界，这个阶段沟通双方建立了绝对的信任关系，此时要解决的主要是产品需求优化、技术难点攻坚、协同效率提升等问题，双方都会聚焦在具体事情的处理上。

在沟通过程中，沟通技巧的掌握，对于沟通也是至关重要的，“一句话可以把人说的笑起来”，“同样一句话可以把人说的跳起来”，高超的沟通技巧是管理技术团队的法宝之一。我就曾亲眼目睹过一个新提拔的团队负责人因为不注重沟通技巧，团队满意度极低，最后导致离职率很高。间接造成交付的产品质量差、系统交付的数次延期等严重后果，引起客户极大的不满，最后公司管理层不得不更换掉了这位负责人。

由于沟通所涉及的内容过多，受篇幅所限，本文只分享了沟通困难的原因、沟通不畅的后果、沟通的阶段及应对的技巧等几个方面的内容，关于技术团队如何进行有效的沟通的相关内容，我将在下篇文章继续展开分享，欢迎持续关注。

作者简介

邱良军，极智嘉研发总监，TGO 鲲鹏会会员，负责组建极智嘉苏州研发团队，以及筹建苏州研发中心， 4 个月将团队发展到 40 人，并承接两个系统开发，数条支持线的工作。曾在新电任职超 10 年，带领团队交付数个项目，团队峰值人员超 70 人。2014 在文思海辉担任总监，从零开始将团队带至 300 人。18 年 IT 老兵，管理经验丰富。

第201讲 | 邱良军：沟通，沟通，还是沟通（下）

你好，我是极智嘉研发总监邱良军，一个 18 年的 IT 老兵，其中有 8 年管理经验，包括研发管理、项目管理、运营管理。在上篇打造技术团队之沟通篇中，我们探讨了沟通难的原因、沟通不畅的后果及各个沟通阶段的技巧，今天继续来聊聊技术团队如何进行有效地沟通，包括和团队成员沟通、跨团队沟通、和老板的沟通等。

技术团队如何进行有效的沟通

打造技术团队的过程中，我们详细聊了准备阶段的工作、找人的重要性、团队管理及研发管理的要点等内容，而沟通技巧是贯穿整个过程的最重要的能力。在整个沟通中，我们应该抱有“六颗心”，即尊重之心、真诚之心、做事之心、赞赏之心、信任之心和感恩之心。而沟通过程中需要遵守的基本原则有以下几点：

确保信息的公开透明（除了敏感信息以外，比如薪资、财务信息），这样可以极大的降低沟通成本，它也是建立团队信任的基础。

任何团队成员都可以表达自己的观点，确保沟通渠道的畅通。

“对事不对人”，沟通的目的是解决问题，不是制造问题，沟通的对象是人，目标是事情。

沟通不可以“人身攻击”。

技术团队的负责人要学习提升沟通技巧：开放心态，学会聆听，并善于提问引导。

技术团队内沟通（向下沟通）

技术团队成员的沟通首先要遵循沟通的基本原则，带着“六颗心”与团队成员平等的做沟通。由于团队的差异性非常大，在具体的沟通中，技术负责人应该掌握不同的方法，灵活使用。对于自律自驱型的团队成员，应该是以关怀、支持的沟通方式为主，把问题的本质解释清楚，并让员工自己自由的去思考。如果工作中出现小瑕疵，暗示或不经意的提醒就可以了。 对于自律性比较差，总需要监督才能推进工作的人，沟通方式就应该以督促指导为主。如果经常出现某种状态，则可以公开不点名的指出。对于做事敷衍推诿的成员，沟通方式就要带一定的严肃、严厉性。

此外，在沟通之前，技术负责人必须想明白，当前团队正处在什么样的阶段。如果是组建初期，需要破冰；如果是团队磨合期，需要碰撞、熟悉、解决冲突；如果是凝聚整合期，需要梳理规范流程；如果是在成熟期，大家配合默契，保证持续贡献就可以。还要根据管理者自身的特点，利用自己最擅长的方式来沟通。

而在实际工作中，如何与团队成员做沟通，我根据自己的经验总结了以下几个要点：

一，充分信任自己的团队。对于团队中提拔起来的小组长等核心成员必须要充分授权，同时在沟通中需要以鼓励为主，让他们大胆放心的去做。我初次带 20 多人规模团队的时候，团队中有 6～7 个同学能力很不错，是可以独当一面的骨干成员。于是我在工作中充分授权并信任他们，还和团队中的每个人谈心，收集他们的诉求，并做出合理的工作安排。在后面的发展中，大家都取得了不错的成绩，有几个还成长为知名企业的中层领导。

二，沟通中不要试图回避问题和矛盾，问题会积累成为大问题，最终让团队垮掉。我的原则就是正视问题本身，以事实和数据为依据做沟通，技术团队对于技术问题是比较执着的，但是通常不愿意激化矛盾，喜欢回避一些问题，如果经常这么做，团队成员就会比较压抑。作为技术管理者就需要把这些事情说开，不用过于担心大家的承受力。经过充分沟通解决后的矛盾往往是增加了解和感情的催化剂，很好地诠释了“不打不相识”这句老话。

三，重要的事情要沟通到位。所谓沟通到位，就是大家已经充分理解，比如工作任务的委派，重大事故的通报，公司年度战略、价值观的传递等，都必须明确地说明。同时，技术管理者在沟通中要保持开放的心态，让团队成员积极反馈，勇于提出自己的问题，管理层再有针对性的做出解答，最后形成闭环。

四，在和下属沟通中，需要学会聆听，使用启发及引导的方式让团队成员说出真实的想法。这个往往非常困难，很多团队成员对于领导有天生的戒心，于是管理者在沟通中获取的信息，通常是经过员工刻意筛选过的。如果技术管理者能为沟通营造一个轻松的环境，并在聆听过程中等一等再做总结和下结论，最终获得的信息会真实全面得多。

五，组织专项沟通会。对于公司层面的事情，包括 HR、财务等，当发生一些流言蜚语的时候，不要尝试着 1 对 1 的沟通，效果会非常差，对于这样的情况，组织一次专项沟通会，将会是一个非常好的选择。

跨团队沟通（同级沟通）

由于没有上下级关系的制约，同级沟通是最难的，有时候同级之间会有利益冲突，会有部门墙，就更容易产生沟通问题，对此，作为技术管理者必须时刻警惕。同级沟通的核心是“不预设立场，不做主观假设，保持一颗谦虚的心”，杜绝利益牵扯、阴谋论、部门墙等因素干扰。

具体如何做好跨团队沟通，我总结了以下几个要点：

1. 沟通中不做假设，不用道听途说的信息为依据，更不能攻击对方。沟通的目的就是解决问题，如果沟通过程中分歧太大，没有办法继续，可以暂停沟通，而后再继续。我曾经在工作中，因为一些误解，和同级的一个研发经理产生了矛盾，然后仓促组织了一次沟通会，由于没有调查清楚事情缘由，当时气氛比较紧张，沟通没有继续下去，而是约了第二天继续讨论。回去后我们分别对事情的来龙去脉做了比较详细的了解，发现原来是一场误会，最终比较轻易的化解了矛盾。

2. 同级沟通中需要特别注意顾及对方的面子，给予充分的尊重。中国人沟通做事比较讲究情面，即使对方有求与你，需要你提供支持来帮助他解决问题，你也尽量在沟通中顾及对方的面子，做到与人方便，将来一定会获得福报。如果没有办法帮助到他，也要解释清楚。

3. 跨团队沟通需要更积极主动。团队之间的很多问题都是因为相互之间有戒心，或者爱面子，都不愿意先跨出一步做沟通。等遇到问题了，通常也采取等待的姿态，都希望对方先来找自己。这样的心态往往会把小事拖成大事，不紧急的事情拖成紧急事情，最后容易把事情弄砸。如果你能更积极主动地沟通，你会发现有奇效。我在 2014 年底刚刚入职新公司时，因为项目比较多，需要兄弟团队的支持。于是我选择了主动出击，积极和多个团队沟通联系，即使当时的主管给我泼冷水降低我的预期，我也没有退缩放弃，最后取得了非常不错的效果。

4. 寻找共同的利益出发点。有时候看似没有利益关系，甚至利益还有冲突的不同团队，如果你仔细分析，是可以找到共同利益点的，包括远期的、近期的，以及直接的、间接的利益。另外，做为一个技术管理者，要有舍小利顾大局的格局，更多的时候可以换位思考，从对方的角度出发，看看哪些是有利于他们的，如此跨团队沟通会容易推进很多。

总的来说，同级沟通最能体现一个人的做事风格，以及综合沟通的能力。而在这种情况下，他唯一能使用的就是自己的影响力。因此，同级沟通的秘诀就是树立自己的个人口碑，包括个人的诚信、乐于助人的品质、坦诚交流、尊重别人、合作共赢的心态等。最后在语言沟通中，要尽量使用简单明了的语言，同时不要总想着在言语上占据上峰。

与老板（领导）的沟通

这里的老板既可能是 CEO，也可能是部门主管或更高的领导。在实际工作中，很多技术团队的管理者不重视或回避、逃避，甚至害怕和老板打交道，主要有以下几个因素：

担心自己的工作没有做好；

担心自己的缺点（比如偶有松懈）被老板知道；

怕给老板添麻烦；

经常和老板的建议、意见有冲突，没办法解决。

而且通常会给出一个冠冕堂皇的理由：老板太忙了。以此来找借口，结果损失的往往是自己。需要记住的是：你和老板的关系是相互借力，特别是你需要向老板借力，因此你更要好好学习如何向老板借力。

首先，我们看看老板是什么样子的，他们到底在想什么，到底忙不忙。看看坐在老板位置上的人有什么不同：

1. 通常老板也是从底层的位置一步一步走上来的，你的角色定位和工作老板是清楚的，你做事的过程和结果是老板非常关心的。不要试图找借口蒙蔽老板，也不用害怕老板，最重要的是带领团队把工作做到位。
2. 老板考虑问题的角度和你是不一样的，他管理着更多的团队或部门，会从整体角度去分析问题，并做出最优的决策。这里面他知道的信息远比你要多，同时需要考虑的事情也比你多。
3. 老板需要下属反馈信息，虽然他不一定会全部看，但是肯定不会从来不看。如果你不及时反馈，多数老板还会有其他渠道来得知你团队的信息，通常是你越不反馈，老板越是想知道。
4. 老板是很忙，但没有你想象的忙，老板的忙和你理解的忙可能是不一样的，他们用来思考的时间比实际做事情的时间多。他们每天做很多的决策，需要把很多信息串起来思考。你认为重要的事情，老板可能不在意。
5. 老板的思维方式一般是先关注结果，再看过程。看过程中的风险，以及你处理事情的方式。不过如果有好的结果，他们通常就不会太关注过程，除非想做个标杆来推广。如果结果不好，他们就会非常关注过程。
6. 老板也是正常人，在某些方面的能力可能不如你，但是如果希望得到老板的支持，你需要把存在的问题说出来，讲清楚。当面不说问题，而在背后说老板不行或不支持你，这个是大忌。

团队主管比较容易犯的认知错误：认为自己最了解团队，而老板是不了解的，老板是瞎指挥（不排除有这样的老板，但是是少数）。得出这样的结论通常是你的认知和见识太浅，我的建议是：
1. 当你得出以上结论时，就不要想太多，由于信息的不一致（多数是你的信息缺失），你无法理解其中的原委。
2. 如果一定要想，请做反思：你汇报给老板的信息是否全面，是否存在偏差，这个可能影响了老板的决策。如果由此带来不好的后果，始作俑者还是在于你，老板对你的信任会因此而降低。

在和老板的沟通中，我总结了几个要点：

老板反复强调的问题，需要仔细思考并充分理解，你肯定可以从中学到东西，提高自己的认知。不要抱怨，而要以积极的心态来看问题、想问题。老板想要解决的问题总归会有办法的，并且也会坚持不懈地想办法，如果你要对着干，趁早走人为好。

在向老板汇报工作的沟通中，一定要注意方法方式。务必提前做好准备，不要浪费老板的时间：先说工作的结论，是否完成目标任务，超过目标还是低于目标，具体完成了多少。再说具体的过程、遇到的困难，以及经验总结、原因分析。当然，这些信息如果领导没有时间或者不关心可以不说。另外要做好周报月报，条理要清晰、用词要简单，使用结构性思维，把事情做好分类并一条条列好。

和老板的沟通就是对老板的管理，定期和老板做沟通反馈是非常必要的，不用担心自己工作出现的瑕疵或做不到位的地方，主动说出来。不要怕麻烦老板，很多关系是麻烦出来的，不过要分析老板所在岗位的难处，以及权力的边界，麻烦的边界要在他的能力范围内。花上一点时间来说服老板听取你的建议，即使无法完全达成一致意见也是值得的，是相互之间关系熟悉并加深的过程。

在和老板的沟通中，特别是解决实际的困难时，要做到：第一把问题调查描述清楚，最好要有数据支撑，信息收集的渠道不要单一；第二经过自己或团队的思考，给出 2~3 个比较好的方案，并给出利弊分析，由老板来做决策，让老板做选择题而不是问答题。

总结

沟通无处不在，做管理就是做沟通，技术团队的管理也不例外。因为它太重要了，因此我单独列了一篇来细说。我自己是理科生出身，前后写了 8~9 年的代码，原本并不善于也不喜欢沟通。在做管理前没有认识到沟通的重要性，以前写上几行代码，输出的结果总是一致的，就感觉到世界都在我的掌握之中。

然而自从做了管理以后，才认识到沟通多么的难，又多么的重要。很多问题的出现，本质上是沟通不畅造成的。沟通不仅仅是能说会道，还包括了管理者对事情的认知、个人的经历、沟通的方式、沟通的技巧、个人的修养等。 沟通能力是一个人情商的集中反映，懂得沟通会让你的职业走的更远、更稳。

另外，对于正在找工作的技术人员，一个小建议是，请务必让 HR 安排一次和直线领导的沟通，如果存在沟通障碍将会是非常麻烦的事情，需要慎重考虑。

最后，我们一定要认识到——沟通是一种可以被训练，是每个人都可以学习的一种能力，每一个技术管理者都应该努力提升自己的沟通能力。

作者简介

邱良军，极智嘉研发总监，TGO 鲲鹏会会员，负责组建极智嘉苏州研发团队，以及筹建苏州研发中心， 4 个月将团队发展到 40 人，并承接两个系统开发，数条支持线的工作。曾在新电任职超 10 年，带领团队交付数个项目，团队峰值人员超 70 人。2014 在文思海辉担任总监，从零开始将团队带至 300 人。18 年 IT 老兵，管理经验丰富。

第202讲 | 陈嘉佳：奈飞文化宣言（上）

你好，我是陈嘉佳，奈飞是一家颇具传奇色彩的公司，一直致力于对企业文化进行颠覆和创新，可以说，企业文化是奈飞保持强大的创新能力以及高效团队的关键因素。

其实早在 2009 年，奈飞就公开发布了一份介绍企业文化的 PPT 文件，在网上累计下载量超过 1500 万次，被 Facebook 的 CFO 谢丽尔·桑德伯格称为“硅谷重要文件”。风靡全球的《奈飞文化手册》就是奈飞前 CHO 帕蒂·麦考德对这份文件的深度解读。

2017 年 6 月，奈飞又做了一个重大更新：将这份文件从 120 页的演讲稿进化成了仅有 10 页的散文。这个散文版比原有的演讲稿版更简洁、更清晰、更明确，对于了解奈飞成功之道有很强的参考意义。由于国内没有这版文件的完整译文，我试着将其翻译成中文版，希望能对你有所帮助。

以下是正文：

娱乐，类似于友谊，是一项基本的人类需求；它能够改变我们的感受，凝聚共识。奈飞提供了世界上从未有过的更低价格和更大规模的娱乐。我们想要娱乐所有人，让这个世界微笑。

本文档是关于我们不同寻常的员工文化。

类似于所有的伟大公司，我们竭尽全力雇佣最优秀的人。我们珍惜正直、卓越、尊重、包容和合作。然而奈飞最特殊的在于，我们在很大程度上：

鼓励员工独立作出决定；

开放地、完全地、深思熟虑地共享信息；

相互之间极其地坦率；

仅仅保留最高效的员工；

避免规则。

我们的核心哲学就是人重于流程。更明确的说，我们是一群优秀的人一起打造的梦之队。通过这种方法，我们的组织更灵活、更有趣、更刺激、更有创造力、更合作和更成功。

真实的价值观

许多公司都有价值观宣言，但是通常写在纸上的价值观都是很含糊的，容易被忽略。一个公司的真实价值观是要通过谁得到奖励或者谁离职来体现的。下面是我们的真实价值观，我们最重视的特定的行为和技能。这些价值观和你的（以及你想一起工作的人的）价值观越接近，你在奈飞的成长会越好。

1. 决策

在不确定的情况下做出明智的决定；

找到根本原因，而不是头疼医头脚疼医脚；

战略性地思考，能够说清楚你是什么，不是什么，想要做什么；

善于使用数据来佐证你的直觉；

做长期决定，而不是短期决定。

2. 沟通

善于通过口语和写作简明扼要地表达；

善于聆听并在反馈之前力求理解对方；

在压力之下保持冷静从而表达最清晰的思路；

善于调整沟通方式以便于和世界各地不同母语的人一起合作；

向同事提供坦诚的、有帮助的、及时的反馈。

3. 好奇心

快速而热切地学习；

在你的专长之外做出有效贡献；

善于在其他人忽视的地方建立连接；

理解世界各地的奈飞会员，并理解我们是如何娱乐他们的；

寻求不一样的观点。

4. 勇气

只要符合奈飞的最佳利益，即使让人很不舒服，你怎么想就怎么说；

不畏手畏脚，敢于做出艰难的决定；

承受明智的风险，坦然面对失败；

质询不符合奈飞价值观的行为；

在寻求真相的时候，易于接受（真相）。

5. 激情

用你对卓越的渴望激励他人；

非常关心奈飞的会员和奈飞的成功；

顽强而又乐观；

沉稳自信，对人谦虚。

6. 无私

寻求最有利于奈飞的，而不是最有利于自己或者你的小团队的；

在寻求伟大想法的时候心智开放；

花时间帮助同事；

开放而主动的共享信息。

7. 创新

创建被证明有用的新想法；

重定义问题，从而发现困难问题的解决方案；

挑战主流的假设，并提出更好的方案；

通过最大限度地降低复杂性和耗费的时间，让自己更加灵活；

在变化中茁壮成长。

8. 包容

善于和各种文化、各种背景的人有效合作；

培养和拥抱不同的观点，从而做出更好的决定；

对不同背景是如何影响工作感兴趣，而不是假装不同背景不会影响到我们；

理解所有人都有偏见，并努力超越偏见；

如果有人被排斥，行动起来。

9. 正直

以坦率、真实、透明和非政治性而闻名；

当面说的和背后说的一样；

自由而公开的承认错误；

不管他们的地位如何，或者他们的意见如何，你都同样地尊重别人。

10. 碰撞

完成大量重要工作 ；

长时间高效地工作，让同事们依赖你；

让你的同事更优秀；

关注结果更甚于过程。

写下这些美妙的价值观是很容易的，难的是一直去践行它们。在描述勇气的时候，我们说：“质询不符合奈飞价值观的行为”。我们希望每个人都能够帮助其他人和价值观一起生活，让彼此对成为榜样负责。这是一段长期的非常吸引人的路程。

在描述正直的时候，我们说：“当面说的要和背后说的一样”。新人很难相信这种态度，更难学习实践。在大多数情况下，包括社交和工作场合，坦诚说出真实看法的人很快会被孤立和惩罚。我们一直努力让人们不断地给予对方专业的、建设性的反馈，不管是向上的、向下的还是整个组织内的。领导者要证明我们都是会犯错的，对反馈持有开放的态度 。人们需要经常询问其他人，“我怎么才能做的更好？”同时也要经常问自己，“我还哪些反馈没有分享？”

我们相信，如果我们能够更轻松地接受和给予反馈，反馈也会成为工作和生活中更常规的部分，我们将学得更快，变得更好。反馈是与他人沟通和协作中持续性的部分，而不是偶发的正式练习。即使这不是一件容易的事情，我们也要通过无私地给予反馈来构建信任。反馈可以帮助我们避免持续的误解和对规则的需求。如果人和人之间有牢固的底层关系和信任，反馈就很容易进行，也这是为什么我们在职业关系上投入时间的部分原因。我们称颂那些非常坦诚的人，尤其是有很高职位的人。我们理解这种程度的坦诚和反馈对于新雇员来说非常难，因为世界上各个地方都不太有这么直接的反馈。但通过指导和鼓励，我们希望在每个雇员上看到这样的行为，我们主动地帮助人们学习如何在奈飞做到这些。

梦之队

梦之队是一支所有同事都为所做的事情而感到骄傲的团队，也是一群高效的合作者。身处一支梦之队的满足感和价值感都是巨大的。我们对于伟大工作场所的定义，不是寿司午餐、良好的健身房、时尚的办公室、或者频繁的派对。我们对伟大工作场所的定义是：一支梦之队一起追求雄心勃勃的共同目标, 并为此付出了沉重的努力。这是一支你学到最多、完成你最好的工作、拥有最多快乐的队伍。

要想把整个公司（而不是一些小组）打造成梦之队是非常有挑战的。毫无疑问的，我们必须在雇佣上做的很好。我们也必须培养合作，拥抱不同的观点，支持信息共享，并且不鼓励办公室政治。不寻常的部分是，我们会给一个一般的雇员一个慷慨的离职金，这样我们就可以为这个职位找到一个明星。

你试想一支职业球队，教练一定会确保场上的每个球员在他的职位上表现出色，而且还能和其他人合作的非常好。我们把自己定位成一个团队，而不是一个家庭。家庭里可能有无条件的爱，即使你的兄弟姐妹可能有不当行为。梦之队会要求你逼迫自己成为最好的队员，也要极度的关心你的队友，而且知道你不可能会永远在这个团队之中。

我们没有钟形曲线、排名或配额，比如“每年要削减最低的 10% 员工”。这不利于促进合作，我们永远也不支持这种过于简单的基于规则的方法。我们通过一种称之为“留存测试”的方法来关注管理者的判断力：如果团队里面有人想要离开，管理者会不会竭尽全力挽留他？对于没有通过该测试的人，我们会迅速而尊敬地给他一份丰厚的离职金，这样我们可以寻找替代者，让我们成为一个更好的梦之队。从团队中被裁掉是令人失望的，但是这并不羞愧。加入一支梦之队是职业生涯中的亮点。

为了成为梦之队，管理者需要非常频繁的和团队成员沟通他们目前所处的位置，从而避免惊讶。因此，每一个雇员都可以在任意时间问他们的管理者：“如果我考虑离开，你在多大程度上想要挽留我？”在友好和诚实之间，我们倾向于诚实。然而无论多么诚实，我们都要尊敬的对待每个人。

有人可能猜想梦之队的关注点在于不要犯错误。事实恰恰相反。当我们寻求进步的时候，我们会尝试各种可能，犯下大量的错误。“留存测试”是一种对某个人整体贡献的判断。

在梦之队里面，合作和信任会良好运作，因为你的同事十分擅长他们的工作，而且也十分擅长和其他人协作。在描述无私的时候，我们说，“花时间帮助同事，开放而主动的共享信息。”我们希望所有的新员工都能感受他们是非常受欢迎的，能够得到所有必要的帮助。

人们喜欢忠诚，因为忠诚是很好的稳定器。在奈飞有良好业绩历史的员工， 如果他们的表现暂时下降，会有一定的回旋余地。同样的，我们也会要求员工和奈飞一起度过短期的困难期。但是，无条件的效忠于一个停滞不前的公司，或者留下一个业绩不佳的员工，并不是我们的目的。

在一支梦之队里面，没有“出色的混蛋”。这对团队协作的杀伤力太大了。我们坚持我们的观点，那就是出色的人能进行体面的人际互动。当一群出色的人在一个合作的氛围里面，他们相互启发，会变得更有创新力、产出更多成果，最终作为一个团队要比一群个人更成功。

梦之队的成功在于有效工作，而不是努力工作。持续的“B”级绩效，即使一直有着“A”级的努力，也只能得到一份丰厚的离职金。当然，为了变的更伟大，我们中的大多数人都需要可观的时间投入，但是努力和长时间的工作不是用来衡量一个人贡献值的标准。

加入梦之队并不是每一个人的正确选择。许多人非常看重工作保障，更喜欢在一家稳定的、更看重资历的、员工效率差别较大的公司工作。我们的模式更适合那些希望所有同事都很卓越的人。

为了帮助我们吸引和挽留住最好的人，我们向员工支付市场上的最高薪酬。一般来说，我们每年都会根据市场情况校准一下。我们不把这个看做是“加薪”，也没有所谓的可以瓜分的“加薪池”。人才市场是什么就是什么。我们不会采用“普通人加薪 2%，优秀的人加薪 4%”这种模型。有些员工的市场价值将会飞速增长（也许是因为绩效也许是因为市场上人才短缺），同时另外一些员工可能年复一年没什么变化，即使他们也做了卓越的工作。在任何时候，我们的目标都是支付员工在市场上能拿到的最高薪酬。

如果我们公司遇到财务困难，我们不会要求员工接受低薪资。一支有亏损记录的运动队仍然会为有望夺冠的队员支付市场上的最高薪酬。另一方面，如果公司表现良好，我们广泛持有的股票期权就变得很有价值。

最终，你的经济安全依赖于你的技能和信誉，而不是你的资历。在奈飞，你将学会如何和令人惊叹的同事一起解决困难的问题，而你学到的东西将增加你的市场价值。如果你离开奈飞，别的公司将会很快雇用你，这一点会让你感到欣慰。我们认为偶尔去外部面试是正常的，并鼓励员工和他们的管理者谈论他们从中学到的东西。

当我们拥有梦幻般的同事，大家合作起来也非常愉快的时候，我们肯定可以做的更好。我们冷静而有信心，渴望获得提高。与我们想成为的伟大相比，我们还差得很远。

整个《奈飞文化宣言》有 10 页，翻译成中文有 8000 多字，受限于篇幅，本文只分享了奈飞价值观的总纲，以及他们对于梦之队的阐述，下一篇文章将分享《奈飞文化宣言》中对于自由和责任、船长决策、营造环境不去控制、高度一致、松散耦合、追求卓越等价值观的阐述，欢迎持续关注。

译者简介：陈嘉佳，巧房科技创始人 & 技术合伙人，负责技术和管理工作。TGO 鲲鹏会会员。国防科学技术大学硕士学历，拥有十多年年研发实践经验，热爱技术，追求卓越。拥有 10 年以上 SaaS 研发经验，在弹性计算、中间件、高并发分布式和大数据处理等方面积累了丰富的实战经验。一直致力于 C 端技术和 B 端产业互联网的相互融合和提高 。在 QCon 2018 上海大会上担任"微服务实践 2.0"专题出品人，并获得优秀出品人称号。目前对团队文化建设和效率提高很有兴趣，计划持续研究典型硅谷企业的文化和国内技术企业的文化差异和融合。

第203讲 | 陈嘉佳：奈飞文化宣言（下）

你好，我是陈嘉佳，奈飞的企业文化一直被很多企业家和领导者者所推崇，而《奈飞文化宣言》是奈飞对其企业文化的最佳提炼和总结，本文就是宣言中对于自由和责任、船长决策、营造环境不去控制、高度一致、松散耦合、追求卓越等价值观的阐述，希望能对你有所启发。

自由和责任

有的公司，人们在办公室里绕着垃圾走，把垃圾留给别人捡起来；有的公司，人们会俯身去捡他们看到的垃圾，就像在家里一样。我们努力成为后者，一家每一个人都有责任感的公司，人人都会在每一个关键时刻做正确的事情来帮助公司。在这里，捡垃圾是处理各种问题的隐喻，无论大小，从不认为“那不是我的工作”。我们没有制定如何“捡垃圾”的规则。我们想要创造一种主人翁感，让这种行为成为自然。

我们的目标是启发人而不是管理人。我们信任每一个人都能做出他认为对奈飞最好的事情：给他们足够的自由、权利和信息，以支持他们做出决定。反过来，这也会产生责任感和自律意识，促使我们做出有利于公司的伟大工作。

我们相信人们渴望被信任，渴望拥有自由，渴望能够做出不同。因此，我们在任何可能的地方促进自由和赋权。

许多组织不健康的强调流程而不是自由。这些组织并不是一开始就是这样的，但是每次出了问题，流程就像巨蟒一样越缠越紧。特别的，许多组织在他们还小的时候拥有自由和责任。每个人都认识其他人，每个人都捡垃圾。然而当他们长大了，业务变得更复杂，有时候人才的平均水平和激情程度就下降了。

随着这种非正式的、平稳运行的组织开始崩溃，混乱开始出现，普遍的呼声是“增长”，所以要增加传统的管理和流程来减少混乱。随着规则和各种程序的激增，价值体系演变为规则优先。如果这种标准的管理方法运转的很好，那么公司在其商业模式上会变得非常高效。这样的体系是鼓励沉默的，创造性的思考者会被告知不要再质疑现状了。这样的组织是非常专门化的，非常适应于它的商业模式。然而，过了 10 年到 100 年，商业模式毫无疑问的会发生改变，大多数这种公司就无力去适应新的模式了。

为了避免过度专业化导致的僵硬以及不断增长带来的混乱，我们的工作致力于同时满足四个目标：保持自由，业务不断增长，员工卓越水平不断提升、以及业务模型尽可能简单。我们试图建立一家由自律的员工组成的公司，他们可以主动发现并解决问题。

我们致力于不断提升员工的自由，从而和流程巨蟒做斗争。这里有一些我们不寻常的关于自由的例子：

1. 我们在内部广泛而系统的分享文档。对所有人而言，几乎所有文档都是开放的，可以阅读和评论，所有这些都是交叉链接的。任何职位表现的备忘录，每个战略决定的备忘录，任何竞争对手的备忘录，以及每个产品功能的测试备忘录都是开放的，供所有员工阅读。可能会存在一些信息泄密，但是信息完备的员工带来的价值值得我们做这件事。

2. 我们几乎没有支出控制或者合同签署控制。每个员工都应该酌情寻求他人的（多样的）建议和视角。“有良好的判断力”是我们的核心原则。

3. 关于出差、娱乐、礼物和其他支出的政策只有 9 个字：符合奈飞的最佳利益。我们还避免了大多数公司为了执行政策所需的合规部门。

4. 我们的休假政策就是“去休假”。我们没有任何规则规定一年能休几周。坦率的讲，我们相当程度的混淆了工作时间和私人时间，在休息时间收发邮件，在工作日下午休假去看孩子的比赛等等。我们的领导者确保他们在休假上树立良好的榜样，经常带着新想法回来，并鼓励团队的其他人做一样的事情。

5. 我们的产假政策就是“照顾你的小孩和你自己”。新父母一般可以休假 4-8 个月。

6. 每位雇员每一年都可以选择现金还是期权。你可以选择全现金、全期权、或者任何你喜欢的组合。你选择你能承受的风险和能享受的上行空间。这些 10 年期的期权是完全收益的，即使你离开奈飞，你也可以保留他们。

7. 我们不要求你留下来才能拿到你的钱。人们可以随时离开，不会有金钱损失，然而他们绝大多数人会选择留下。我们希望管理者创造条件，让人们喜欢这里，为了伟大的工作和丰厚的薪资而工作。

你也许会认为这么自由会导致混乱。然而，我们没有穿衣政策，也没有人裸体来工作。我们学到的是，并不是所有的事都需要政策。大多数人都知道工作时候穿衣服的好处。

我们的反规则自由哲学也有几个重要的例外。我们对道德问题和安全问题很严格，例如，对骚扰雇员或者买卖内幕消息是零容忍的。信息安全问题，比如对客户的支付信息有严格的访问权限控制。从公司的银行账户转移大量金钱也有严格的控制。但是这些都是边缘案例。

通常来说，自由和快速恢复好于防止出错。我们从事的是创意行业，不是安全至关重要的行业。随着时间的推移，我们面临的最大危险是缺乏创新，所以我们应该相对的容忍出错。如果人们具备良好的判断力，快速恢复是可能的。错误预防听上去是很好的诱惑，然而往往是无效的。我们一直很注意不要让太多的错误预防措施妨碍了创造性工作。

在很少的情况下，自由会被滥用。例如，我们曾有一个资深员工收了 IT 合同的回扣。但是这都是例外，我们会避免过度纠正。少数人滥用自由，并不意味着我们的员工不值得高度信任。

有些流程是为了增加生产力，而不是避免出错，我们喜欢能帮助我们做更多的流程。其中一个能够让我们做的更好的流程是高效地计划会议。我们很多类型的会议都有一个常规节奏：准时开始，准时结束，并有充分准备的议程。我们在这些会议上相互学习，做的更多，而不是防止出错或者批准决定。

消息灵通的船长

对于每一个重要决定，都需要一个负责任的船长在综合和消化了其他意见之后做出判断。我们避免通过委员会来做出决定，因为这会减缓我们的速度，分散责任。我们为不同意见而耕种，不同意见不会自然出现，也不容易出现，因此我们需要努力一致来刺激不同意见。

很多时候，团队会针对某个话题见面并辩论，但在这之后需要有人做出决定，成为那个“船长”。小决定可以仅仅通过邮件分享，大决定需要讨论不同的立场，并得把船长为什么做出这个决定记录为备忘录。决定越大，所基于一致的意见和不一致的意见都应该越广泛，并记录在一个公开共享的文档中。

然而，我们很清楚最终决定不是由多数人或者委员会投票做出的。我们不会等待共识，也不会去推动快速的不为人知的决策过程。对于一个特定决策而言，如果“船长”对“下注”有合理信心的话，他们会做出决定，我们也会“下注”。随后，随着后果越来越明显，我们需要反思这个决策，看看未来能不能做的更好。

公开反对

如果你在一个实质性问题上有分歧，你有责任通过讨论和书面解释为什么你不同意。反复讨论可以澄清不同的观点，核心问题的清晰描述可以帮助人们反思什么是正确的道路，同时也可以更容易的分享你的观点。做出该决定的“船长”有责任欢迎、理解和考虑你的意见，但可能不同意。一旦“船长”做出了一个决定，我们希望所有人都能够让它变得尽可能成功。之后，如果有重要的新信息，可以要求“船长”重新讨论这个话题。无声的分歧是不可接受的，也是没有成效的。

不控制环境

我们希望员工成为一个优秀的独立决策者，仅仅在他们不确定是否是一个好决定的时候，才需要咨询他们的管理者。每个层级上的领导者的工作就是设置一个清晰的上下文，确保其他人有正确的信息来做出正确的决策。

我们不相信有所谓的 CEO 神话：CEO 极度深入细节，因此他们的产品或者服务变得惊人的优秀。斯蒂夫. 乔布斯的传奇故事就是通过他的微管理让 iPhone 成为一个伟大的产品。有些人甚至更极端，自豪得把自己称为“纳米管理者”。主流网站和工作室的负责人有时候会在其内容创作过程中做出很多决定。我们不仿效这些自上而下的模式，因为我们相信，当整个公司的员工能够自己做出决定的时候，我们是最有效和最有创新力的。

我们努力在公司的任何地方都培养良好的决策能力。我们为高管做出的决定如此之少而自豪。不过，我们也不需要“旁观者”式地管理。每个领导人的作用就是教导、设定上下文，并高度了解正在发生的事情。要想知道上下文如何改进，唯一的办法就是研究样本细节。但是与微管理不同，了解这些细节不是为了改变某些小决定，而是为了学会如何调整上下文，这样就能更好地做出更多决定。

对于“不控制上下文”，有一些小的例外，比如紧急情况下来不及思考合适的上下文和原则，或者新的团队成员因为还没有吸收到足够的上下文而不够自信，或者当人们认识到一个错误的人扮演了一个决策者角色时（毫无疑问，暂时的）。

我们告诉员工不要去取悦你们的上级。相反的，服务于你的业务。不同意你的上级，没问题。但隐藏任何事情都是不允许的。可以跟你的上级说：“我知道你不同意，但是我打算去做 X，因为我觉得这是个更好的方案。如果你想推翻我的决定，请告诉我。”我们不希望的是，人们猜测他们的管理者会做什么或者想要什么，然后执行这个猜测。

高度一致，松散耦合

随着公司的成长，它们通常会变得高度集权和不灵活。主要现象包括以下几点：

1. 高层陷入大量的小决策；

2. 有很多跨部门的会议来宣传自己的策略；

3. 取悦其他的内部团队重于取悦客户；

4. 组织高度协调，很少出错，但是速度很慢，令人沮丧。

我们通过高度一致和松散耦合来避免这些问题。我们花大量的时间一起讨论战略，然后相信其他人可以按照战术执行，并不需要提前审批。通常的，两个小组可能致力于同一目标，但他们的行动相互之间并不知晓，也不需要相互认可。如果之后发现这些行动不太对，我们可以进行一次坦诚的讨论。我们也许会发现，该战略过于模糊，或战术和战略不一致等。一般我们会讨论如何在将来做的更好。

“高度一致、松散耦合”的工作环境的成功依赖于高绩效个体的合作以及高效的环境。最后，终极目标是当增加灵活性和敏捷性的同时业务飞速增长。我们追求更大更快更灵活。

追求卓越

新员工在入职的最初几个月经常会评论说，他们很惊讶的发现这个宣言准确的描述了他们所感受到的实际的公司文化。在世界各地，我们共同实践并创造了我们的文化。事实上，我们全球数百名员工都为这个文件做出了贡献。

我们不寻求保护我们的文化——我们寻求改善它。每一个加入我们的人都可以帮助我们进一步塑造和发展文化。我们一起找到获取更多成果的新方法。每隔几年，我们就能感到我们比过去运营的更有效率。我们的学习速度比以前任何时候都要快，因为我们拥有更多观点不同的敬业人士，努力为我们更有才华的团队找到更好的合作方式，让他们更协调、更灵活、更有效的合作。

总结

正如我们写在最前面的，奈飞的特殊之处就在于我们在多大程度上

鼓励员工独立作出决定；

开放的、完全的、深思熟虑的共享信息；

相互之间极其地坦率；

仅仅保留最高效的员工；

避免规则。

最后，正如《小王子》的作者安托万·德·圣艾克修佩利告诉我们的：

如果你想要造一艘船，
不要召集大家去收集木材，不要划分工作并发号施令。
而是要教会他们对浩瀚无际的大海心生憧憬。

译者简介：陈嘉佳，巧房科技创始人 & 技术合伙人，负责技术和管理工作。TGO 鲲鹏会会员。国防科学技术大学硕士学历，拥有十多年年研发实践经验，热爱技术，追求卓越。拥有 10 年以上 SaaS 研发经验，在弹性计算、中间件、高并发分布式和大数据处理等方面积累了丰富的实战经验。一直致力于 C 端技术和 B 端产业互联网的相互融合和提高 。在 QCon 2018 上海大会上担任"微服务实践 2.0"专题出品人，并获得优秀出品人称号。目前对团队文化建设和效率提高很有兴趣，计划持续研究典型硅谷企业的文化和国内技术企业的文化差异和融合。

第204讲 | 邱良军：从小处着眼，修炼文化价值观

你好，我是极智嘉研发总监邱良军，一个 18 年的 IT 老兵，其中有 8 年管理经验，包括研发管理、项目管理、运营管理。在之前的文章中，我们讲了沟通的重要作用，以及如何做好技术团队内部沟通、跨团队沟通，以及和老板的沟通。在本系列的最后一篇中，我们来聊聊团队文化价值观的话题，看似非常大而虚，实际上是公司长久发展的基石。

本文将通过以下三点来讲文化价值观方面的内容：

什么是公司的愿景、使命和文化价值观

文化价值观对技术团队的影响

文化价值观如何落地，又如何体现在技术团队管理中

公司愿景、使命和价值观

所谓“不是一家人，不进一家门”，这体现了文化价值观认同的重要性，以此作为基础来做事会容易的多。而在一个团队中不传递负能量，很关键的表现就是对文化价值观的认同。好的公司和团队需要有一个正确的、激动人心的愿景、使命、价值观，它总能在关键时刻帮助大家做出正确的选择。我一直很欣赏阿里巴巴对于文化价值观的坚持。

马云曾说过，阿里巴巴所有的组织结构，包括七家子公司、阿里学院，都紧紧围绕着我们的使命和价值观，我们的任何政策都不能与它们相违背，凡是违背价值观、使命感的政策，我们一定要拿掉。正因为有这套价值观、使命感和文化，才诞生今天的阿里巴巴，这是阿里巴巴做决策的首要原则。

愿景就是目标，某个学生立志成为天文学家就是一个愿景，还是举阿里的例子，它的愿景就是“成为一家 102 年的企业”。愿景通常是宏大的，而且实现起来会很困难，通常也不会轻易变化，需要通过一段长久时间的持续努力才能够实现的宏伟目标。

使命就是为什么而存在，例如立志要做天文学家的学生会把“发现外星文明”作为他的使命，而阿里的使命是“让天下没有难做的生意”。我们都说肩负着伟大的使命，使命会让我们对从事的工作充满敬意和荣誉感！

价值观就是做事的原则，有所为而有所不为，社会最基本的底线是法律，在此之上是社会道德，企业的价值观应以此为底线，再结合企业自身的特点来确定做事情的准则。在此再分享一个关于马云的故事：“有一次，阿里的销售人员在做培训，他去看了下，发现培训老师在讲怎么样把梳子卖给和尚。他听了 5 分钟后非常生气，就把这个培训老师给开除了。马云认为，这根本不是销售之术，而是赤裸裸的欺骗！”，这就是价值观，以“不忽悠客户为中心”。

愿景、使命、文化价值观构建了一个企业和团队的核心精神，它会帮助企业和团队做出符合自己发展的选择，也会帮助团队渡过难关。

文化价值观对技术团队的影响

文化价值观就是企业的基因，会深深地影响到公司中的每个人，特别在企业面临很多选择的十字路口：

当遇到困难、迷茫时，愿景和使命会指引驱动我们向前，让团队抱着必胜的信念。

当取得成绩面临诱惑时，价值观会让我们不骄不躁、清醒头脑，坚定地做出正确的选择。

随着公司的发展，规模会越来越大，人员会越来越多，各级部门领导各有各的管理风格、各自有擅长的领域，但是他们却有着相同的决策和选择事情的准则，这就是文化价值观。我们熟悉的著名企业的文化价值观有：

华为的“狼性”企业文化，保持高度的危机感!

阿里的创新、武侠文化（每个高管有个花名），有目标和激情！

京东的客户体验文化，体现了强大的执行力！

作为技术团队，我们如何打造自己的团队文化，又如何让团队文化融入到公司的文化中，这是技术团队负责人必须要思考的，也是自己能否被公司认可，以及被自己带领的技术团队成员认可的关键，我列举几个自己比较推崇的技术文化：

一、工程师文化，这几乎是会被每个技术管理者提到的一个文化标签，是技术团队向往的一种终极文化。什么是工程师文化呢？我认为工程师文化的几个核心标签是“专业专注”、“学习自律”、“自由创新”。简单来说，工程师是某个领域的专家，会非常专注、持续自主地学习探索某个领域的知识，需要一个自由的状态和环境来工作， 是创新的主要贡献者。

然而几乎没有一个公司能够打造一个标准的工程师文化环境。企业需要生存，需要为客户和业务服务，技术最后需要为企业创造价值，理想的自由是不存在的。我们作为技术团队的管理者就需要在两者之间找到平衡，努力为团队创造一种自由、宽松的环境，尽量屏蔽掉不必要的干扰，同时引导团队崇尚技术、创新、学习的文化，并以此为荣。

二、团队不能带有负能量，负能量文化是摧毁一切的开始，是我极端厌恶憎恨的。如果有负能量的信息在传递，只要你感知到了，就必须在第一时间找出原因。直面问题，做梳理，通过公开沟通的方式来澄清一些事实。如果是确实存在问题，必须马上做出纠正，而不能回避它。

在我们的工作中，总会有少数几个人不管如何总喜欢抱怨，包括抱怨公司、抱怨老板、抱怨同事。作为团队负责人必须干预这样的抱怨，必要时坚决不用这样的团队成员。我曾经在制度完善的德企待过几年，这样的抱怨者照样存在，他们不会给出任何改进建议，只是为了抱怨而抱怨。

三、极客文化，这是软件研发团队特有的一种文化，由于软件技术的高难度、神秘性，会让技术工程师变的很“酷”。 极客文化是大家把这样的一种认知推向了极致，代表人物有乔布斯，他对产品的功能、性能、外型近乎于完美的要求，是技术人员极其推崇的对象，也是学习的标杆。

最近技术圈内也发生了一件让人瞠目结舌的反面标杆——“拼多多”上线了一个未经充分测试的秒杀优惠券功能，短时间内损失达到亿元。作为技术管理者必须认识到：一行问题代码就可能带来严重的后果，甚至于让系统崩溃，让公司倒闭。

文化价值观如何落地

被誉为“世界第一 CEO”的杰克·韦尔奇提出“价值观要天天讲，月月讲，年年讲，他每到一个分公司都会给全体员工讲企业文化，并要求每一个管理者都宣传企业文化，在他看来，优秀而牢固的企业文化形成强大的竞争力，保持了公司每年的高速发展。

技术团队落实公司及技术团队的价值观，就是要从小事着眼，处处体现公司的文化价值观，比如：

会议室的命名，可以带有技术、自由的元素；

给予团队成员一定的自由度，鼓励并奖励成员的创新，创造思辨的环境氛围；

可以给团队成员起一个“酷”的别称，或昵称；

去掉公司等级、企业的老总文化；

定期组织技术分享、沙龙；

让团队成员，尤其是具有极客精神的成员拥有 20% 的思考时间；

根据当前团队的特点，把“要做什么、不能做什么”清楚的表达出来，列一个 Do List 和一个 Don’t List，并放到每个人的桌子案头；

技术团队负责人要以身作则的做表率，这个非常关键。

文化最终体现在每个人的行为规范上，对于细节的处理就是文化的体现。技术管理者要想打造积极向上的工程师文化，就需要技术管理者首先自己践行，做到知行合一，文化的力量就是榜样的力量，我们要把文化作为一种习惯固化下来。同时，文化的力量是伟大的，也最能体现领导力的力量。最后用杰克. 韦尔奇的话作为本篇的结束语：“世界属于热情而又有动力的领导者，这些人不仅自身具有很多能量，而且能激发那些被领导者的能量！”

作者简介

邱良军，极智嘉研发总监，TGO 鲲鹏会会员，负责组建极智嘉苏州研发团队，以及筹建苏州研发中心， 4 个月将团队发展到 40 人，并承接两个系统开发，数条支持线的工作。曾在新电任职超 10 年，带领团队交付数个项目，团队峰值人员超 70 人。2014 在文思海辉担任总监，从零开始将团队带至 300 人。18 年 IT 老兵，管理经验丰富。

第205讲 | 邵浩：人工智能新技术如何快速发现及落地（上）

你好，我是狗尾草科技合伙人，人工智能研究院院长邵浩。从上世纪 80 年代开始，我们经历了技术飞速发展的四个时代，分别是 PC 时代、互联网时代、移动互联网时代，以及我们正在经历的人工智能时代。现如今，人工智能的新概念、新技术层出不穷，作为技术管理者，一个重要的能力就在于如何快速发现技术，并且落地到实际产品中。在本文中，我将跟你一起讨论人工智能新技术如何快速发现和落地。

人工智能技术现状及成熟度概述

简要来说，人工智能概念自从 1956 年达特茅斯会议上被提出之后，迄今为止经历了 3 个热潮。第一个热潮伴随着神经元模型、深度学习模型以及增强学习的雏形即感知器的提出和发展而兴起，但却由于适用性较窄而进入低谷。第二个热潮出现在上世纪 80 年代初到 90 年代，浅层学习算法如支持向量机、Boosting、最大熵等得到广泛应用，IBM、苹果推出的个人电脑也进入到普通百姓的家庭，但由于第五代计算机的失败和背离工业发展的方向的技术路线，人工智能再一次进入低谷。

2006 年，杰弗里·欣顿（Geoffrey Hinton）和他的学生在《Science》上提出基于深度信念网络（Deep Belief Networks, DBN）可使用非监督学习的训练算法，随后 2012 年，DNN 技术在 ImageNet 评测中取得了突破性进展，人工智能进入到新的热潮，围绕语音、图像、机器人、自动驾驶的技术大量涌现。

2017 年 8 月 20 日，微软语音和对话研究团队负责人黄学东宣布微软语音识别系统取得重大突破，错误率由之前的 5.9% 降低到 5.1%，可与专业速记员比肩¹；谷歌在 2015 年提出的深度学习算法，已经在 ImageNet 2012 分类数据集中将错误率降低到 4.94%，首次超越了人眼识别的错误率（约 5.1%）²；DeepMind 公司在 2017 年 6 月发布了当时世界上最好的文本到语音环节的生成模型——WaveNet 语音合成系统；另外，截至 2019 年 3 月，由斯坦福大学发起的 SQuAD（Stanford Question Answering Dataset）使用 BERT 的系统暂列第一，其 F1 分值达到 89.474。

每一次热潮都会伴随着媒体的大肆报道，在吊起广大民众胃口和期望值的同时，让大家产生一种错觉，认为人工智能马上要统治世界了。因此，在人工智能符号主义、连接主义、行为主义之外，又出现了一个叫“媒体主义”的分支，主要特点是哗众取宠，什么吸引眼球就写什么。至于我们当前正处于的人工智能第三次热潮，会不会由于强人工智能的难以突破，又一次跌入谷底，还有待观望。

如图，从独立咨询公司 Gartner 发布的最新技术成熟度曲线中，我们可以看出，脑机接口、知识图谱，以及通用人工智能技术都有了快速的发展，但强人工智能的极点何时出现，我们还不可知。

人工智能技术落地的种种困难

在简要介绍完人工智能技术的发展现状之后，我们来谈谈人工智能落地的难点。

2012 年之后，随着一波投资热潮，大量人工智能公司如雨后春笋般涌现，同时，政府也在人工智能上投了很多热情，以期推进智能化和产业升级。借此契机，大量传统的软件公司乃至文化公司，为了更快的融资和拿到政府的补贴，想尽办法为自己的产品和解决方案冠上人工智能的头衔。但实际上，人工智能的落地并没有想象的那么美好，媒体上经常看到的一些炫酷的案例，背后也都存在大量人工设计的场景和规则。甚至专门出现了一个叫做 P2V 的场景，全称是 PPT to VC。然而，随着 2018 年后资本热度的冷却，很多人工智能创业公司不得不转型寻求安全的落地业务，甚至有一些公司已经挣扎在倒闭边缘。

我们就拿最近很火又很难的技术为例，聊一下从技术到产品的落地痛点。

首先是自然语言处理（Natural Language Processing，简称 NLP）技术，所对应的产品在 C 端通常是聊天机器人，在 B 端通常是智能问答解决方案。例如狗尾草科技的公子小白智能音箱，以及小 i 公司的智能客服机器人等。

微软亚洲研究院副院长周明博士曾经提到，自然语言处理技术可以看做是人工智能皇冠上的明珠。尝试用技术模拟人类的真实对话，在开放领域就是个伪命题。因为人类的对话过程中，所表达出的信息，不只是文字本身，还包括世界观、情绪、环境、上下文、语音、表情、对话者之间的关系等。一句“今天天气不错”或者“你好么”所表达的意思可能是千差万别的。因此，目前聊天机器人还远远没有达到人类的期望值，给人的感觉也是人工智障。

但在一些特定场景下的聊天机器人和智能问答系统，却能够表现出令人满意的效果。比如 2018 年谷歌开发者大会上，打电话预约理发店的对话系统，就把场景限制在了预约理发店这个业务本身，通过有限状态机，以及大量的规则和数据，把这个特定场景做的看似天衣无缝。同样，在大型电商平台的客服机器人场景下，所涉及到的状态也是有限集合，因此，其效果也能做的比较好。

由于在开放域对话中，现有技术还无法达到人类预期，研发人员和投资机构又把眼光投向了近两年比较火热的知识图谱技术上。知识图谱的概念提出已久，谷歌在 2012 年提出了 Knowledge Graph 的概念，并通过知识图谱实现了“让搜索通往答案”的理念。

知识图谱的火热程度，从国内质量最高、参会人数最多的全国知识图谱与语义计算大会 CCKS（China Conference on Knowledge Graph and Semantic Computing）就能一窥端倪。CCKS 在 2016 成立之初只有 500 名参会者，这个数据到了 2017 年是 600 人，2018 年是 800 人，而 2019 年杭州的会议，预计参会者将突破 1000 人。

作为从感知智能到认知智能跨越的重要基石之一，知识图谱被寄予了厚望，但真正在落地上却鲜见成功案例。尤其是很多公司和地方政府机构在谈需求的时候，一上来就说，“我想用知识图谱技术，你们能不能把现在的知识库变成知识图谱？实现大数据的链接应用？”其实，知识图谱技术能不能应用，要综合考量多方面因素，就拿知识的表示和存储来说，选用不同的数据库，就需要用到不同的知识表示。RDF（数据的一种三元组表示形式）的数据表示可以选用 Jena 数据库，而图表示可以选用 Neo4j 图数据库。对不同来源的数据还需要进行大量的数据清洗和结构化，甚至还牵扯到纸质文档（例如医院病历）的手工录入。结合业务来看，很多时候传统关系型数据库就能解决的问题，完全没必要用到大规模图数据库，否则很容易导致整个项目成本高效率低的问题。

以上就是很典型的人工智能从技术到产品过程中的难点痛点，那作为技术管理者，面对如此现实，我们要如何快速发现新技术并将其落地到实际产品中呢？受限于篇幅，我将在下篇文章中与你分享这个话题，欢迎持续关注。

感谢收听，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

参考文献：

W. Xiong, L. Wu, F. Alleva, J. Droppo, X. Huang, A. Stolcke, The Microsoft 2017 Conversational Speech Recognition System, Microsoft Technical Report MSR-TR-2017-39, arXiv:1708.06073v2, 2017.

K He, X Zhang, S Ren, J Sun. Delving Deep into Rectifiers: Surpassing Human-Level Performance on ImageNet Classification, arXiv:1502.01852v1, 2015.

作者简介

邵浩，TGO 鲲鹏会会员，日本国立九州大学工学博士。现任上海瓦歌智能科技有限公司总经理，深圳狗尾草智能科技有限公司合伙人，人工智能研究院院长，带领团队打造了聊天机器人产品“公子小白”及 AI 虚拟生命产品“琥珀•虚颜”的交互引擎。中国中文信息学会青年工作委员会委员，中国计算机学会 YOCSEF 上海学术委员会委员。研究方向为人工智能，共发表论文 40 余篇，出版了业内第一本聊天机器人著作，主持多项国家级及省部级项目，曾在联合国、WTO、亚利桑那州立大学、香港城市大学等任访问学者。

第206讲 | 邵浩：人工智能新技术如何快速发现及落地（下）

你好，我是狗尾草科技合伙人，人工智能研究院院长邵浩。在上篇文章中我们聊了一些人工智能技术在落地过程中的难点痛点。今天，我们接着这个话题，继续聊聊在新技术层出不穷的情况下，技术管理者如何快速发现可应用的新技术，并将其落地到实际产品中。

新技术层出不穷，如何发现新技术

如果有关注 arxiv 网站的读者会感觉到，算法在近年来的迭代速度非常快速。以语言模型（Language Model）预训练方法为例，代表性方法有 Transformer，ELMo，Open AI GPT，BERT 以及最新的 GPT2。其中，Transformer 于 2017 年 6 月被提出。ELMo 的发表时间是 2018 年 2 月，刷新了当时所有的 SOTA（State Of The Art）结果。不到 4 个月，Open AI 在 2018 年 6 月，基于 Transformer 发布了 GPT¹方法，刷新了 9 个 SOTA 结果。又过了 4 个月，横空出世的 BERT 又刷新了 11 个 SOTA 结果。到 2019 年 2 月，Open AI 最新发布的 GPT2，包含 15 亿参数，刷新了 11 项任务的 SOTA 结果。

因此，可能我们还在尝试验证一个算法的时候，另一个新算法已经刷新了原有算法的指标。那我们如何能够保持对技术的敏感度呢？以下是我的几个建议：

首先，优秀论文（英文为主）是必须要跟进的，尤其是阅读算法的原文，对于复现和修改算法细节非常有必要。其中，axiv（https://arxiv.org/ ）是一个非常重要的平台，虽然没有同行评审，会带来良莠不齐的问题，但鉴于论文更新速度快，很多重要的成果都会在此进行预发布。一般来说，优秀的论文引用量都比较多，英文苦手也不用担心翻译问题，因为网络上会有很多业内高手对好论文进行解读，通过中文解读可以初步了解算法的性能和工程化的可能性。

其次，高质量的微信公众号也是了解新技术的一个快速通道。通用类公众号比如机器之心、将门创投，细分领域比如 paperweekly（就是带你读论文）等，都是快速接触新概念新技术的途径（注：我没有收取广告费 LOL）。

然后，对于工程化项目而言，GitHub（https://github.com）是一个不可或缺的代码源，工程师经常戏称 GitHub 是全球最大的同性交友网站。在这里，可以直接获取大量优秀算法的开源代码，还有经典论文的算法复现，可以在 issue 中提问和解答细节问题，还可以参与完善算法。

最后，要找机会参与圈内的活动。参加国内的一些圈内会议，不仅可以了解目前的技术进展，同时还可以和来自高校和企业界的朋友互通有无。尤其是一些大型会议，对公司的招聘和技术宣传也都是非常好的途径。机器学习、计算机视觉、语音技术、自然语言处理、知识图谱等都有专门的会议，这里就不再一一列出了。有兴趣的读者可以关注中国计算机学会的学术会议排名来进行选择。

新技术如何从理论到落地

在上一篇文章中，我们讨论了人工智能技术落地难的问题，接下来，我希望和你简单讨论下如何将优秀的技术进行落地的话题。

首先，从业务的角度来看，需要审视公司的主要竞争力是什么，不能为了用新技术而偏离了公司的核心价值。因为新技术通常是锦上添花，而不是雪中送炭的。在业务中，需要根据自己的产品做选择，用了人工智能技术，能不能给产品带来显著的提升，公司能否负担起人力成本和数据成本，甚至包括深度学习所需的硬件成本？

举一个简单的例子，机器学习中有一个子领域是分类（Classification），在深度学习还未兴起的时候，针对不同的数据进行分类，需要根据数据的分布特点，选择不同的适用算法，例如 SVM，LR，决策树等。即便是在今天，传统的算法未必就比深度学习方法要差。我有一次面试一名头部大厂的高级算法工程师，他整个过程中只谈 LR 的方方面面，对于其他的算法不关心也不熟悉，好像是 LR 弄好了就能打遍天下的感觉。不可否认，这些传统分类算法在大量问题上都有优秀的表现，但有了效率更高的模型，也有必要去测试并判断它们能否用于实际产品中。

比如 FastText 这个算法，发布之初就得到了广泛支持，在自然语言分类问题上，不仅速度快，性能提升也相当明显。因此，经过一整套测试流程之后，我们将其作为了主分类模型。后来又出现了 BERT，同样经过测试之后，我们发现其性能超越了 FastText 百分之一到百分之二。但这时候，由于其时间消耗远大于 FastText，并不能作为主模型来用，我们仅将其作为并行处理中的一种参考方法，与若干传统机器学习方法一起来做 stacking（Stacking 是一种集成学习方法，感兴趣读者可以阅读其他资料进行了解）。

因此，算法好不好用，能不能落地，需要综合考虑各方面因素。比如说在做文本匹配的时候，有大量深度学习方法可以使用，理论性能也都是 SOTA 水准，但根据产品需求来看，有时候 96% 的准确率和 95% 的准确率，产品体验并没有多大差别，但投入的研发成本却要高出许多，反而用 ES（ElasticSearch）自带的 BM25 算法又快又好，那就完全没有必要使用深度学习方法了。

同样的，对于感知技术，目前技术的成熟度也非常高。比如说人脸识别，如果和产品不是重度耦合，直接使用大厂的 API 或 SDK 就行了。但如果是自己的核心产品需要搭配人脸识别模块，就可以考虑在已有成熟的开源的算法上进行二次开发，甚至搭配自己的芯片，从而打造自己的核心竞争力。（注：别忘了确认算法的商用条件，以免陷入版权纠纷）

其他需要注意的点

1. 技术和产品的权衡
正如前文提到的技术成熟度曲线，有些技术，在现阶段的确没有达到人类的期望值。这个时候，一个可选的解决方案是通过产品设计来补偿。

比如说大量“弱智”的聊天机器人产品，可以利用产品设计，来弥补技术缺陷。那该如何去做呢？关键在于，我们要让用户不要重点关注其技术表现，而是对产品的体验有一种惊艳感，发出类似“天哪，这样都可以“的赞叹。比如我们狗尾草科技提出的聊天机器人的虚拟生命形态，这个概念之前日本的 Gatebox 公司也提出过。基于这个概念诞生的琥珀·虚颜，就是我们推出的一款结合了 AI+AR+IP 以及 GAVE 引擎（Gowild AI Virtual Engine）的虚拟生命产品，它搭载 holoera 硬件平台及 360°全息投影，创造了一个有情感、可养成、可进化的虚拟存在，但这种存在又可以和周边世界进行多模态真实互动，并针对用户行为习惯形成不同的性格体系。同时，人物还可以换成二次元角色和真实的明星，进一步提升用户体验和粘性。

有一句话说的好，技术不够产品来凑，产品不够运营来凑。用户接受才是硬道理，技术可以加分，但过硬的还是产品本身。

2. 小公司和大公司
我接触过一些创业公司，一开始就期望做一个人工智能开放平台，虽然在前两年拿到不少融资，但最近大多数都销声匿迹。做平台型的事情，没有大量的人员和资金支持，是无法实现的。我们可以看一下国内的人工智能研究院，且不说百度腾讯的换帅事件，很多中小型公司的研究院也由于没有办法进行工业级产出，导致了大量资本投入换来的只是 Demo 和论文。

所以，对于中小型公司而言，需要做的事情是借助利好，顺势而为。同时精耕细作一个细分领域，在大公司无暇顾及的垂直行业杀出一条血路。无论是后期被收购还是能够独立壮大，都是比较好的结果。切忌大而全，什么都想做，做自己擅长的才是最重要的。

写在最后

大家现在都在谈人工智能技术，而且很多人都会把人工智能和 AlphaGo 以及深度学习划上等号。其实人工智能涵盖的学科范围是非常广泛的，包括心理学、神经科学、哲学、认知科学等等。我们目前看到的大量成果都只是深度学习和大数据的化学反应。而且，大量的人工智能应用还都是人工 + 智能，离真正的认知智能差距甚远。如何利用技术赋能产品，得到用户和资本的认可，才是最重要的。

参考文献：

Radford, A., Narasimhan, K., Salimans, T. & Sutskever, I. (2018). Improving language understanding by generative pre-training

作者简介

邵浩，TGO 鲲鹏会会员，日本国立九州大学工学博士。现任上海瓦歌智能科技有限公司总经理，深圳狗尾草智能科技有限公司合伙人，人工智能研究院院长，带领团队打造了聊天机器人产品“公子小白”及 AI 虚拟生命产品“琥珀•虚颜”的交互引擎。中国中文信息学会青年工作委员会委员，中国计算机学会 YOCSEF 上海学术委员会委员。研究方向为人工智能，共发表论文 40 余篇，出版了业内第一本聊天机器人著作，主持多项国家级及省部级项目，曾在联合国、WTO、亚利桑那州立大学、香港城市大学等任访问学者。

第207讲 | 许良：科创板来了，我该怎么办？

你好，我是许良，随着科创板首批上市企业名单的公布，科创板频频占领媒体头条，频频曝光下，科创板已经箭在弦上，整装待发！今天我们就来聊一聊科创板的来龙去脉以及科创板上市，对于技术管理者来说能够享受到什么红利。

为什么要有科创板？

有朋友会问，目前已经有主板、中小板、创业板、新三板等二级市场了，为何还要设立科创板？

大家都知道，科技的进步和产业化推广都是需要巨大的资金来支持的。虽然这些年，我国资本市场在加大支持科技创新力度上，已经有了很多探索和努力，但由于一些历史原因，还存在很多问题，使得国内的交易所错失了过去二十年发展势头最好的一批科技企业，尤其阿里巴巴、腾讯、百度等企业的远走海外上市，成为无数国内投资者的心头之痛。

特别是当下资金寒冬大环境下，公司融资难，二级市场本来应该成为企业最有效的融资渠道，但是因为在现有体系内存在诸如上市条件严格（要求连续几年盈利）、审核排队长（当前为核准制，之前每年上市几百家排队，只能上市几十家）、内幕交易频发（对于内幕交易惩罚轻）、企业退市少（对于违规企业极少实行退市制度）等问题，二级市场远远没有发挥它应有的作用。

而设立科创板，就是为了解决这些问题。

我所在的企业可不可以上科创板？

正如科创板的名字所表达的，科创板天生就是为科技创新服务的，所以上市企业定位上，也是有明确要求的，大家好好对号入座。

科创板主要服务于符合国家战略、突破关键核心技术、市场认可度高的科技创新企业。重点支持新一代信息技术、高端装备、新材料、新能源、节能环保以及生物医药等高新技术产业和战略性新兴产业。

对于符合以上定位的企业管理者们，要打起精神来了，敲黑板、划重点，下面是科创板上市需要关注的点。

首先，科创板对于企业的利润要求变低了。商业规律使然，好多创新科技企业的最开始几年都是连续亏损，京东、特斯拉、阿里这些伟大的企业在国内现行体制下连审核都过不了，但是现在不一样了。科创板对于利润不做一刀切的强制要求。

其次，科创板对于股权结构的要求放松了，可以接受红筹企业及 VIE 结构，也有条件的接收同股不同权。曾经港股因为不同意阿里巴巴的同股不同权的要求，导致阿里巴巴被迫赴美上市，悔青了肠子，痛定思痛下进行了改革，才有了后来的小米、美团在港股上市。而本次科创板的股权政策放开，可以让“阿里巴巴”和“小米”、“美团”们也能够在国内上市，让国内的投资者也能享受到科技发展的投资红利。

针对科创板上市的具体要求，共有五套市值标准，见下图。

注：上市企业筛选上，引入专家把关机制，上交所设立了科技创新咨询委员会，对科创板的定位以及发行人是否具备科技创新属性等方面为上交所提供咨询意见。

此外，上市审核的审核制度也进行了放松，科创板试点注册制，发行人向上交所提交申请（过去为证监会），审核通过经由证监会注册便可上市，上交所受理申请到出具审核意见不超过三个月，流程更便捷，审核时间预期更明确，也就是说企业上市的速度将大大提高。

可以说，科创板针对过去交易所的几个问题都做了相应的改进，对于企业确实是大大的好事。

我的企业在科创板上市，我能否得益？

企业上市之后，每个人第一反应就是这个问题，换句话说就是，作为团队的技术管理者，企业上后，我们得到的股权激励，是否匹配？

其实这里面有两个问题：

第一个是股权出让的价格合不合理？

第二个是自己企业人员是否愿意把蛋糕持续做大？

第一个问题决定了管理者手里的股票能够值多少钱。第二个问题关系到，企业能否长期健康发展，进一步关系到科创板能否健康发展。让我们一个个来说。

第一个问题的核心是定价是否有专业性，换句话说，是否由市场来决定。从发行承销规则来看，发行价格、规模、节奏主要通过市场化方式决定，询价、定价、配售等环节由机构投资者主导，市场化的发行定价以及向战略投资者配售也有助于引入长期资金，降低股价的波动，引导市场长期健康发展。

在上市首发中，回拨及网下初始比例安排更偏向网下，网下最终份额最低 60% 或 70%。个人投资者是不能参与网下配售的，这进一步提高了定价的准确性。

发行上市后，谁来定价呢？还是较为专业的投资者，首先我们看到，由于首发机构参与较多，上市企业的股权大部分都在机构投资者手中，创投基金等股东减持可以采取非公开转让方式退出。

科创板对个人投资者的二级市场投资和网上申购也设置了较高门槛，要求拥有 50 万元股票市值和 24 个月证券交易经验。这些都提高了股权价值定价的专业度和准确度，能正确反映企业的经营质量和前景。

好，第一个问题解决了，我们来看第二个问题：企业的管理者是否有意愿持续做大？

首先，科创板在制度设计上就杜绝了个别企业家想上市捞一把走人的想法。企业家持股冻结时间最长，同时考虑到个人资金需求，是逐步解冻的。

此外，核心技术人员，作为公司创新创业的核武器，科创板还针对核心技术人员的激励措施做了明确的规定，来最大化调动他们的工作激情，帮助企业取得重大的核心科技竞争力。

比如，科创板针对细分行业和技术来源，提出了不同的技术划定标准，比如企业内部产生的职务技术成果与非职务技术成果，外部获得的技术委托开发与技术合作开发。明确的技术权利归属规定，确保技术所有人是真正的技术贡献者，也应当获得技术发明发现过程的回报。

为确保核心技术人员能够享受到股权激励，科创板还作出了专门规定：

第二十一条 科创公司以本公司股票为标的实施股权激励的，应当设置合理的公司业绩和个人绩效等考核指标，有利于公司持续发展。
第二十二条 单独或合计持有科创公司 5% 以上股份的股东或实际控制人及其配偶、父母、子女，担任董事、高级管理人员核心技术人员或者核心业务人员的，可以成为激励对象。科创公司应当充分说明上述人员成为激励对象的必要性、合理性。
第二十三条 科创公司授予激励对象的限制性股票，包括符合股权激励计划授予条件的激励对象在满足相应条件后分次获得并登记的本公司股票。
限制性股票的授予和登记，应当遵守交易所和证券登记结算机构的有关规定。
第二十四条 科创公司授予激励对象限制性股票的价格，低于市场参考价 50% 的，应符合交易所有关规定，并应说明定价依据及定价方式。
出现前款规定情形的，科创公司应当聘请独立财务顾问，对股权激励计划的可行性、相关定价依据和定价方法的合理性、是否有利于公司持续发展、是否损害股东利益等发表意见。
第二十五条 科创公司全部在有效期内的股权激励计划所涉及的标的股票总数，累计不得超过公司总股本的 20%。”

和企业管理者一样，科创板对核心技术人员的股份锁定与减持的规定，详情请看下图，参考了主板与创业板对高管人员的锁定与减持限制，并需在公司申报时未盈利情形下承担与科创板董监高同样的锁定期与减持限制的义务。

其次，企业管理的效率化和法制化也得到保证。

企业上市时，中介机构辅导上市过程中，会进一步优化企业章程，理顺管理流程和先进经营理念。同时，由于科创板强化监督管理和法律责任，对违法违规行为的相关责任人员将加大追责力度，上市公司将建立健全以信息披露，并采取规范委托代理机制，防止不同实体的非正当利益输送。

最后，企业家做不好的话，史上最严格的退市制度来了，出现重大违法直接退市。

A 股目前的退市制度是纸老虎，而科创板则对退市制度做出更为严格细致的安排。目前主要分为两类，第一类为重大违法强制退市，与主板规定相一致。第二类为丧失持续经营能力且恢复无望的主业“空心化”公司，主要从交易指标、财务和规范三方面做出规定。

另外，科创板不设置重新上市环节，已退市企业若符合科创板上市条件需重新走 IPO 通道，但针对重大违法强制退市的公司，则实施严格的永久退市制度。

就这样，萝卜和大棒将在科创板双管并下，从而让企业家和投资人都得益，有利于科创板的长久健康发展，

作为个人投资者，如何享受到科创板的红利？

相较于主板，科创板的涨跌停限制也做出了很大的调整，科创板将采取“竞价 + 盘后固定价格 + 大宗”的交易方式，首发上市后以及增发上市后的前 5 个交易日不设价格涨跌幅限制，其他交易日的竞价交易涨跌停限制为 20%（主板当前的涨跌停限制为 10%）。

这意味着，新股上市后股价波动将会非常大、市场认可的会涨的特别凶，市场不认可的也会跌的特别狠，盲目的“打新股”的策略将不可行。

在这样的背景下，考虑到科创板的巨大的投资风险绝非一般的个人投资者所能承受，为了保护风险承受能力比较弱的个人投资者，科创板提高了个人投资者的投资门槛。

首先，个人投资者无缘科创板新股网下申购，科创板网下申购将主要是机构投资者的天下，机构投资者的网下申购市值要求最低 1000 万元。

其次，科创板对个人投资者的二级市场投资和网上申购也设置了较高门槛，要求拥有 50 万元股票市值和 24 个月证券交易经验。

第三，如果不满足上述条件的个人投资者，如股票市值不满 50 万元或者证券交易经验不足 24 个月的个人投资者，也不要以为就这样遗憾的错失下一波投资红利了。个人投资者可以通过购买公募基金等方式参与科创板投资。现有可投资 A 股的公募基金均可投资科创板股票。

总结

天生为科技创新服务的科创板的确是科技创新企业的福音。除了只允许特定类别的企业上市外，科创板还对上市条件进行了放宽，如盈利条件大大放宽，也可以接受红筹企业及 VIE 架构，还有条件的接收同股不同权，此外科创板试点了注册制，审批速度也大大加快。

科创板制定了准确的市场化的股权定价规则，从而让股价更加准确，从而让企业家和管理人员能够得到应有的股权激励，而且也为了能够让企业人员能够持续的做大企业，也做出了相应的规定，出台了严格的信息披露制度和退市制度。

科创板提高了个人投资者的门槛，不过鼓励个人投资者通过公募基金来参与投资科创板，让每个人都能享受到科技创新的投资红利。

作者简介

许良，高级行业分析师。在传统汽车和新能源汽车领域深耕多年，负责新车型的开发和新技术探索，开发的新车型多次蝉联销量冠军，后加入某头部互联网公司的前沿技术部门，负责行业分析和新技术在新场景的探索和落地。

第208讲 | 陈阳：科创板投资，未来哪些行业受益最大？

你好，我是陈阳，上周，特朗普在一次演讲中宣布：“5G 竞赛是一场美国必须赢的竞赛”。去年美国制裁中兴，围堵华为，这足以说明，以 5G 网络为核心的科技之争，已经上升到国运之争的程度了。科创板就是在这样的环境下诞生的，但是很多人对科创板并没有深刻的认识，所以今天特意写下此文，对科创板的前因后果，以及未来的投资机会做一个全面性的总结。

百年大局

周期大王周金涛说过，人生发财靠康波，每个人一生中发财的机会只有三次，而每一次的机会都出现在时代的转折点上面。经济发展十年一个轮回，2019 年显然就是一次财富重新分配的新起点，能把握得住这个机会，就能够在下一个十年中胜出。

新生事物形成的初期，很多人总是在犹豫和怀疑中错过，只有少数人能够展现出超乎常人的智慧，能够提前看到常人看不到的机遇，就能够提前布局未来，成为脱颖而出的少数人。

目前为止，还是有很多人对于国家设立科创板这一举措抱着半信半疑的态度，并没有深刻的认识。

如果站在百年发展大局来看，设立科创板，对中国经济发展其实是具有跨时代的战略意义。

改革开放四十几年来，中国经济经历了劳动密集型到资本密集型两个发展阶段，到现在已经取得了巨大的成就，规模上已经跃居全球第二，但是从发展质量上却依然落后于大部分国家。

今天的中国有两大问题亟需面对：

其一、经济总量庞大，高科技产业发展却跟不上经济发展的步伐。

其二、人口老龄化带来的劳动力不足，人口红利变为人口负担。

过去粗放型的发展方式出现了瓶颈，中国经济想要再上一个台阶，就必须跨过劳动力不足和科技水平薄弱这两座大山，走向转型升级之路，而转型升级之路只有一条，那就是从以数量取胜走向以质量取胜的技术密集型发展道路。

中国现在已经走在了前进道路上的一个十字路口，如果转型成功，就能够成功摘掉发展中国家的帽子，跨入发达国家行列，如果转型不成功，那就会陷入中等收入陷阱，重新走向平庸。所以，科技兴国不是一句空话，也不是一时兴起提出来的口号，而是关乎百年发展大局，关乎民族前途命运的重大转折点。

我们国家不可能会甘于平庸，现在大力发展高科技产业，其中深刻原因就在于此。这里面包含着只许成功不许失败的大决心，因为我们已经没有退路。而设立科创板，就是以金融支持科技最重要的一个环节。

中泰证券首席经济学家李迅雷做过一个统计，2018 年信息技术产业对 GDP 增加值的贡献在 30% 左右，而传统产业如金融，房地产和建筑行业等行业，对 GDP 增加值的贡献只是在 3%-4% 之间。从数据上也能够明确的看出，未来推动经济发展的主力必然是高科技产业，而传统行业已经开始在拖后腿。

这从另一方面也说明了，选择一个正确的行业到底有多重要！过去十年，国内高收入群体也是集中在互联网科技等新兴行业，过去高收入的传统行业现在也开始走下坡路了。

说到这里，大家应该就能理解科创板的重要性了，既然这是百年大计里面最重要的一个环节，这其中蕴含的机会自然也是十分巨大的。

美国的科创板：纳斯达克股票市场

介绍科创板之前，我们先来认识一下美国纳斯达克股票市场，原因就是纳斯达克对科创板有着许多值得借鉴的地方，能帮助我们更好的去思考和理解科创板对中国未来的真正意义所在。

纳斯达克股票市场就相当于是美国的科创板，创立于 1971 年，专门为计算机，电信，生物技术公司等新兴技术行业提供融资的渠道。

当年的美国股市跟 A 股有着诸多相似之处，当时美国很多高科技企业，规模小，利润不稳定，达不到上市的条件，同时又有迫切的融资需求。美国为此专门成立了纳斯达克股票市场来接纳这些中小高科技企业，降低了上市的门槛，为他们提供了非常方便的融资渠道。

纳斯达克股票市场的成立，培育出了无数后来叱咤风云的高科技跨国大企业，例如 70 年代上市的英特尔，80 年代上市的微软、戴尔，苹果，90 年代上市的思科等，他们在上纳斯达克之前也都属于创业阶段的中小企业。还有美国在线，雅虎等也都是在纳斯达克股票市场成长起来的高科技巨头。可以想象得到，如果当时没有纳斯达克股票市场的支持，以上这些科技巨头，恐怕又是另一个样子。

话说回来，把美国高科技产业的发展全部归功于打通融资渠道的支持也是不严谨的，这里面一样离不开美国政府对科技产业的大力支持，和对专利技术的严格保护上面。现在国内对高科技产业的支持力度也是空前的，至于专利技术保护方面，也是在逐步的完善当中。不过今天主要讲的是科创板，这方面内容就不展开了。

回到今天的主题，以上这些在当时受到主流资本歧视的美国中小企业，现在已经成为代表全球最高科技水平，引领全球科技发展方向的主力军。纳斯达克股票市场的成交量，也超过了任何单一证券市场，纳指也成为了全球范围内最具影响力的股票指数之一。

就是这一举措，一举奠定了未来几十年，美国在国际社会上科技水平的领先地位，这也是利用金融培育高科技产业的典范。

国内新兴技术的现状

高科技企业，新兴技术的特性，意味着一开始就需要投入大量资金，产出却十分不稳定，想要他们短期就见到利润是很困难的，所以这个市场非常需要资本的培育，否则要成长起来十分困难。而我国的资本市场在过去却显得十分急功近利，资本一旦进入了某个产业，就巴不得立刻能够赚取暴利，套现走人，没有人有耐心去放长线钓大鱼，这也是国内经济快速发展，高科技却一直发展不起来的重要原因之一。

很多人对腾讯，阿里，新浪，网易等互联网巨头纷纷选择去海外上市就十分不理解，其实当年的阿里腾讯他们并不是不想在 A 股上市，而是达不到上 A 股的条件，国内资本不愿意投资，国内市场也没有类似纳斯达克一样的市场为他们提供方便的融资渠道，迫不得已之下才舍近求远，设计了一套非常复杂的 VIE 股权架构，跑去海外上市，卖身给外国资本。前几年阿里跟雅虎，软银的股权之争，还差点因此丢掉了控制权。

现在国家已经意识到了这个问题的严重性和迫切性，所以着手设立科创板，目的就是为新兴经济提供方便的融资渠道，以市场的方式来培育国内新兴技术产业的发展。

这也是国内从事高科技，互联网，生物技术等领域的科技从业人员的一个极大的机遇。

科创板的规则

科创板的定位就是落实创新驱动和科技强国战略，这个目标十分明确。发行制度上采取注册制，极大的简化了发行的流程，缩短上市的时间，整个流程下来，大概只需要 9 个月左右的时间。

另外，科创板设立了 50 万的投资门槛，目的就是鼓励专业的机构投资者投资科创板，毕竟投资创业型企业，本来就是专业投资者的行为，对于中小投资者也可以选择购买科创板基金来间接投资科创板企业。

从目前已经受理的 72 家企业看来，其中大部分都集中在半导体芯片，集成电路，人工智能，互联网，生物科技等领域，并且都是中小企业为主，这跟纳斯达克股票市场的定位十分类似。

未来哪些行业受益最大？

想要抓住科创板的核心，还要从去年开始的中美贸易战，美国制裁中兴通讯说起，这一次中美贸易战之争，核心就在于科技创新之争，而未来科技创新的风口，就在 5G 网络技术的主导权上面。

为什么 5G 技术网络技术会如此重要？原因就在于网络技术就是科技之母，未来很多新兴技术都依赖于 5G 网络的铺开，才能够迎来飞跃性的发展。

前几年 4G 网络的发展，催生出了抖音快手等短视频 APP，成为了这几年最火爆的互联网产品。那么，5G 网络的发展，必然也会催生出更多的新兴行业，例如虚拟现实，人工智能，无人驾驶，物联网等领域，而这些领域也正是科创板大力支持的领域。这些领域的发展，势必也会成为引领下一轮经济飞跃式发展的主要动力，这也是中国经济转型升级的重大机遇。

下面逐项来分析：

1. 虚拟现实：虚拟现实的应用非常广泛，例如可以应用在医学实验，工业仿真，军工航天，娱乐，游戏体验，购物体验等方面。

例如在医学上的应用，学生可以通过虚拟现实去做各种现实中无法尝试的实验，医生做手术的时候也可以通过虚拟现实事先反复模拟，再制定出最优的方案，可以极大的提高手术的成功率。

在工业仿真和军工航天上面，一些大型施工项目，或者是军事演习，容错率极低，就可以通过虚拟现实事先模拟演练，做到万无一失以后才开始具体实施，这样也可以极大的节约成本，提升工作效率。

在娱乐和游戏，购物方面，也可以极大的提升用户体验，让用户有一种身临其境的感觉，让足不出门就能环游世界不再是一个幻想，这将会极大的颠覆传统的游戏和电商行业。

2. 人工智能：很多人把人工智能简单归结为硬件的提升，这是不对的。人工智能的本质，是机器算法和思维的提升，只有对计算机技术，心理学和哲学等各方面都有深刻理解的科学家，才能做出类似阿尔法狗那样具备深度自我学习能力的机器算法。

人工智能的应用也是非常广阔的，例如可以用在经济统计和经济决策，自动控制系统，语言和图像的识别，甚至人体神经网络和人体基因的研究等方面。

3. 无人驾驶：无人驾驶技术的难点就在于高速行驶时网络的响应速度和精确度，目前的 4G 网络无论从稳定性和速度上都无法满足无人驾驶技术的要求，无人驾驶迟迟没有取得实质性进展主要就是这个原因。5G 网络不管从速度还是稳定性上都要远远好于 4G 网络，随着 5G 网络普及，无人驾驶必然就会逐渐兴起。

4. 物联网：物联网就是物物相连，一个手机终端，就能够随时随地看到你所有东西的状态，例如家里的门锁，冰箱里食物的状态，汽车的位置等物。物联网技术其实已经逐渐在铺开，现在新的设备基本都带有可联网设备，物联网技术的普及也只是一个时间问题。

综上所述，未来技术创新推动经济发展的路径已经非常清晰，而技术创新的核心就在于 5G 网络的普及，在此基础上又会衍生出大量新兴行业，而新兴行业的兴起，也是造富的时代。在未来的互联网 2.0 时代，你做好准备了吗？

作者简介

陈阳，一个具有工科背景和超过十年投资经验的独立投资人。

第21讲 | 绩效管理的目标不仅仅是绩效考核

我们经常讨论绩效考核这个话题，有不少人为如何考核程序员产出这件事烦恼。我旗帜鲜明的提出观点，绩效考核只是绩效管理的一环，如果抛弃绩效管理谈绩效考核，无异于舍本逐末。本文尝试聊几个大家关心的话题：绩效考核有哪些痛与伤、绩效管理与绩效考核的关系、目标与 KPI、OKR 的关系等。

绩效考核有哪些痛与伤

我们先回顾一下绩效考核都有哪些常见问题。

第一类问题，我们姑且称为”工作量考核”。顾名思义，工作量考核的关键点在于工作量评估。工作量评估，又会绕到一些常见的问题：

Java 开发工程师的工作产出如何衡量？

前端工程师的工作产出如何衡量？

产品经理的产出如何衡量？

DBA 的工作产出如何衡量？

有人提到过代码行评估，但代码行评估其实在业界的争议非常大。代码行多是绝对代表产出更好吗？不同语言之间对比代码行也是一个有点滑稽的事情。

第二类是绩效考核，可以称之为”全面指标考核”。全面指标考核可以说在”考核”本身这件事上已经做得足够了，一般会关注多个维度的评估以保障全面性。我曾在一家电信业务的 IT 公司做部门经理，当时公司是采用平衡计分卡来做绩效考核。

平衡计分卡是从财务、客户、内部运营、学习与成长四个角度，将组织的战略落实为可操作的衡量指标和目标值的一种新型绩效管理体系。我后来反思，绩效目标要突出拉动力，而不是面面俱到。否则很容易导致全面指标考核在实操过程中走向失败，绩效考核的维度和实际运营维度不 match。

我们再看一个例子。在项目研发中往往以研发过程数据、业务结果、公司制度（比如考勤）、主管主观评价等构成程序员的绩效考核体系。如下图所示，示例了一个绩效考核的指标体系。

业务结果、研发过程、制度考勤、主观评价 4 个维度有对应的权重，来体现不同的岗位角色和各项指标的关联紧密程度。比如，活跃用户数超出预期，研发人员自然是有贡献，但产品和运营所起到的作用更是重要。我认为，研发过程的指标应该作为观测指标，真正的考核指标是业务在线上运营的故障和缺陷，以及研发人员对于需求响应、客户服务方面的满意度。由外而内，避免自嗨。

绩效考核还有一类问题，出在绩效指标设定上。绩效指标要和组织目标对齐，不要为了设置而设置。我们来看一个例子。某测试同学的绩效指标设定：1：所负责的模块无线上缺陷；2：辅导应届生进行功能测试；3：完成一次性能测试。

到考核季的前一个月，这位同学发现我的第三个指标 (完成一次性能测试) 还没做呢？于是急急忙忙去做了。当主管评估该同学绩效指标的时候，发现所有指标都完成了，包括性能测试的指标。但这个指标是不是当下最重要紧急的，甚至这个个人绩效指标跟项目目标、团队目标没有强关联。目标没有对齐的危害，可能是树木和森林没有很好的对应，甚至可能南辕北辙。

通过这个 case 可以思考一个问题，绩效目标设定和所属团队目标的关系，以及和上级组织目标的关系。

我们跳过绩效考核应该如何做，先回头来看看绩效管理是怎么回事。

绩效管理闭环

有个专家叫戴明，他发明了一个快速反馈的工具叫戴明环，又称为 PDCA 环。PDCA 环实际是美国质量管理专家休哈特博士首先提出的，由戴明采纳、宣传，获得普及。PDCA 循环的含义是将质量管理分为四个阶段，即计划（plan）、执行（do）、检查（check）、行动（Action）。

绩效管理其实质也是一个 PDCA 循环。

第一步是目标设定。目标来自于哪里？技术团队的目标一定是来自于业务。我经常讲不服务业务的技术都是耍流氓。阿里巴巴 CTO 行癫也有句话，所谓的工程师文化就是”让好技术驱动业务腾飞”。比如一个业务负责人把一款 app(如极客时间) 的目标设定为：

活跃用户数达到 10 万

单品专栏成交量超过 20000

按照增长黑客的思路，引新、留存、促活、转化这些套路都会用起来，那么对于技术平台就可能有一些对应的技术指标。比如：

App7*24 小时可用（实际上可以放宽一点，深夜 4 点还在学习的用户极少）

App 稳定性 (安装包大小、启动时间、崩溃率、App 耗电等)

易于分享和传播（比如分享步骤不超过 3 步，过于复杂会让用户失去兴趣，当然还可以通过返利一定程度上平衡）

第二步是设置计划，亦即是 PDCA 环中的 P(Plan)。设置计划来自于目标的分解。比如：

8.31 完成 A 业务线的全部业务接入

9.30 完成 B 业务线的全部业务接入

10.31 完成 C 业务线的全部业务接入

第三步是执行 (Do)，执行过程中进度风险、人员流失、技能不够、需求变更频繁等风险都有可能存在，甚至是不止一个因素同时发生。那么我们要做好的就是缩短反馈环，解决问题。每日立会、缩短迭代发布频度等有助于掌握项目实际的风险和完成状况。参与项目的同学，项目整体目标与个人目标息息相关，可以通过主动反馈主管来做阶段性检查 (check) 对齐。

第四步是检查（Check）。对于个人而言，日常过程中的绩效管理尤其重要，及时发现偏差，及时清晰的沟通，落地有效的改进计划或方式。同时如果涉及绩效目标的变更，也要及时沟通调整。

第五步是给出 Action。根据 check 结果给出 Action 帮助目标进行改进。同时进入到新的 PDCA 循环。

由此可见，绩效管理是一个闭环过程，而绩效考核是其中一个阶段。如果等到考核期才发现问题就晚了，应该保持按周、月、季做 check 有利于早发现、早纠正。

目标与 KPI、OKR 的关系

首先辨识一些基本概念。

什么是目标？目标是要去的方向，并且转换为可衡量的数据指标。目标不是孤立存在的。

KPI(Key Performance Indicator) 是关键绩效指标，来自自上而下的分解。各部门的主管需要依据企业级 KPI 建立部门级 KPI，并对相应部门的 KPI 进行分解，确定相关的要素目标。KPI 的好处就是分解清晰，力出一孔。

OKR（Objectives and Key Results）即目标与关键成果法，是一套明确和跟踪目标及其完成情况的管理工具和方法，主要目标是明确公司和团队的“目标”以及明确每个目标达成的可衡量的“关键结果”。OKR 首先确定 O(Objectives)，然后从 O 分解出 KR(Key Results)，然后用 KPI 或者 Milestone 的形式来表示 KR。

有论者批评唯 KPI 论，一切都是 KPI 惹的祸。我觉得关键的问题不是出在 KPI，而是出在 KPI 的制定者，或者是 KPI 的执行者。KPI 顾名思义，是关键绩效指标，指标不等于目标，所以 KPI 应该在目标的指导下工作。

举例来讲，在 2011 年的时候，我们大团队曾经做了一个产品叫悬赏交易，如果我没记错的话，大概业务指标是做 100 万笔交易。热心的运营同学想了各种办法来完成这 100 万笔，包括给旺旺用户推送消息，然后跳转到对应页面，获得一个赠送的商品，默认点击则完成一笔交易。我认为这样的 KPI 在执行层面是有害的，设定 KPI 背后的 why 是什么？是让这个产品被用户知道，让用户愿意来使用，有用户留存。如果用户在引流过来对产品毫无感知，单纯完成的交易并不能说明什么问题。总结来说，KPI 没有错，在使用 KPI 的时候，要了解背后的 why，要了解我们要去的方向在哪里，目标在哪里。在灯塔的照耀下，KPI 就能被合理的应用于考核。

有时候方向对了，KPI 设定错了，还可以走一段之后去调整它，所谓“不忘初心”，在行进途中别忘了，我们为什么出发？而 OKR 的美丽在于，对于目标提出了可度量的关键结果。所以无论 KPI 还是 OKR 都需要强目标驱动，单纯谈 KPI，可能会丢掉目标和初心。

我们参考一下吴军老师 2017 年初给自己设定的 OKR，下面仅引用目标 1。

目标 1. 完成《数学之美》的英文版和韩文版，《大学之路》第二版

关键结果 1.1 找到英文版的出版商 ；（1.0，已经签了合同）

关键结果 1.2 寻找合适的、母语是英语的合作者，修改英文版的书稿 ；（0.3，试了两个翻译者，都不满意，在联系第三个翻译者，让她试着翻译一章。）

关键结果 1.3 完成英文版的写作；（0.1，因为翻译者还没有找到，因此我自己翻译了一章、前言、目录，以后要由翻译者做）

而我在工作中，习惯了增强 KPI 的设置模式，这个模式里面有关键绩效指标, 但关键绩效指标仅仅是一个评估结果。于是又增加了过程关键指标。过程关键指标如同温度计，它不是用于惩罚和制裁。而是去发现可能的异常，通过高频快速的反馈促进团队和个人改进，以便于满足阶段性 KPI 的达成。下面就提供一个设置增强性 KPI 的示例。

夯实底盘（稳定性、资金风险）：通过 XXX 手段加强事前、事中、事后的风险防控。

【衡量标准】：

最终结果：

无重大故障

无 P1 级故障

线上总故障数 <=5

过程关键指标：

线下缺陷，缺陷密度、紧急发布等作为观察指标 (详细指标此处省略)

应急体系：（衡量指标：变更导致线上的问题的发现时效、主动发现线上问题比例等）

业务分钟级异动感知， 5 分钟内止血消除影响。

加分项：

1：创新解决问题方案，有案例支撑并具备跨子域或者更大范围的推广价值。

2：在问题的解决过程中追求极致，有典型案例支撑。

大家可以思考一下，如果把上面的例子修改为 OKR 应该如何做？我认为 KPI 本身并不 low，关键在使用这个工具的人。在使用 KPI 的时候要紧扣目标，绩效管理闭环有助于产出的改进。OKR 创造性的提出了 Key Results，但也要防止 Key Results 陷阱。随着公司业务发展和规模扩大，越来越多的团队面临的是不确定性问题域，很可能 3 个 Key Results 结果都很好，但关键目标并未达成。

结语

绩效管理的目标不仅仅是绩效考核，绩效考核只是绩效管理 PDCA 的其中一环。考核的目的是为了改进，而不仅仅是做一个评价。技术团队设定目标的方向非常重要，目标应该来自于组织目标分解，同时为了保有创新和自主性，组织目标不宜确定过细、让团队拥有一些创造性解决 key result 的机会。KPI 是关键绩效指标，关键绩效指标要在目标的作用下工作。OKR 在目标的基础上分解出关键结果，有利于目标的过程跟踪。

作者简介

于君泽，蚂蚁金服资金运营技术部负责人，TGO 鲲鹏会成都分会会员。从业超过 16 年，业务领域兴趣在支付、金融风险、监管科技。同时经常就高可用分布式架构、研发管理、内建质量等发表观点。维护公众号：技术琐话。著有《深入分布式缓存》一书。

第22讲 | 验证研发团队价值的绩效考核机制

业务同事的绩效很容易考核，签了多少单？赚了多少钱？清晰可见，容易衡量。对于做产品研发工作的我们来说，成本很好计算，但价值却很难衡量。业务团队能为公司赚钱，研发团队却花公司的钱，研发团队从此就变成了公司的“成本中心”。

我们需要有一套合理的绩效考核机制，衡量并验证自己的价值。这套机制需要简单易懂、操作方便，而且需要通过数据说话。有数据还有要对比，需要与自己比较，还要与别人比较。

本文将结合之前的文章（第 14 讲：从零开始搭建轻量级研发团队）中提到的内容，从绩效考核方面继续探讨下去。首先，我们针对研发团队考核模型，进行深入探讨。

研发团队考核模型

我们的研发团队分为横向“职能团队”与纵向“项目团队”，所有的研发人员都在职能团队中，他们都在所在的项目团队中，体现出自己的工作绩效。因此，绩效考核是基于项目团队进行的，而不是职能团队。针对不同类型的项目团队而言，需要制定不同的团队目标，采用不同的考核方式（如图 1 所示）。

图 1：项目团队考核方式

每种项目团队都有共同的考核部分，那就是“个人 OKR”，它包括两方面：一是个人成长，二是团队贡献。个人成长又包括专业技能和综合技能两方面，前者是“硬技能”，后者是“软技能”。个人是否得到成长，取决于和自己的曾经作比较，而并非与他人作比较。团队贡献包括的方面较广，比如：技能培训、经验分享、偿还技术债、制定并落地规范、组织团队活动等。在本文下一节中将对 OKR 进行深入探讨。

需要注意的是，个人 OKR 需要个人结合团队目标来定义，由个人所在职能团队来评审个人 OKR。 也就是说，OKR 是自底向上的，而 KPI 却是自顶向下的。此外，我们认为 OKR 和 KPI 既不冲突，还能相辅相成。将 OKR 与 KPI 有效结合，不仅可以激励团队成长，还能促进团队完成公司的核心目标。

对于功能团队而言，他们的目标是确保以最快的速度，高质量地让项目上线。然而，速度和质量往往是相互制约的，速度太快，质量一般不会太高。也正因如此，我们才需要对功能团队的速度加以限制，否则项目上线后，一个难以维护的成果即将诞生，可以想象，随后效率团队一定会踩坑无数。因此，我们需要对功能团队定义一些“技术 KPI”，才能确保项目的顺利交接，比如：上线时间、代码质量、产品质量等。

对于效率团队而言，他们的目标是优化现有产品功能并帮助业务实现目标。可见，业务的成功，决定于效率团队的成功。我们无需像要求功能团队那样去要求效率团队，因为他们关心的不再是速度和质量，而是如何不断提升业务效率，帮助业务团队实现业务目标。因此，我们可将业务 KPI 作为考核效率团队的参考标准。

对于创新团队而言，他们的目标是帮助公司创造新的商业机会与盈利方式。往往需要通过收入的方式来考核该团队，我们需要同时设置业务 KPI 与技术 KPI 来验证该团队的价值，即投入与产出。

当然，不论哪种项目团队，都需要考核项目是否延期？上线后是否有 Bug？而且这些标准都应该是事先确定清楚并和团队达成共识的。我们相信：先有共识，才有共赢。只有大家一致认同的原则，才可能有效地去执行。

以功能团队和效率团队为例，在绩效考核的具体操作层面上，我们可采用“打分制”，根据具体情况进行加分或减分（如图 2 所示）。

图 2：绩效考核打分制

需要注意的是，效率团队将对功能团队的交付成果进行考核，不仅是代码，还包括文档。确保功能团队的 1.0 项目这根“接力棒”可以顺利传递下去，未来在效率团队的手中，让它变成 1.1、1.2、1.3 等。若要开发产品功能 2.0，可认为这是新的尝试，同样需要功能团队来开发，2.0 功能上线后再次交给效率团队进行功能迭代。

每个季度可进行一次绩效考核，具体的考核成绩将分为 S、A、B、C 四个级别，S 表示大家心中充满美好期待的那根线，A 表示努力跳起来就能够得着的那根线，B 表示及格线，C 表示不及格。绩效考核的成绩需要公示，考核结束后根据具体成绩进行奖金发放。同时，个人 OKR 也在每个季度结束时进行考核，但考核结果不会体现在季度奖金中，而是体现到每年的加薪幅度上，因为个人 OKR 是个人的能力提升与团队贡献程度的表现，与薪资挂钩会更加合理。

关于 OKR 方面，虽然它无法直接反应在绩效上，但它对团队的成长是至关重要的，团队成长了，绩效才能提高。下面，我们专题讨论一下 OKR 的十大要领。

OKR 十大要领

OKR 最早来自于 Intel 公司，随后在 Google 公司得到了更好的应用，现在全球杰出的互联网公司几乎都在用 OKR。要在企业中更好的应用 OKR，完全取决于我们自己对它的认识。

OKR 包括两大要素：O 和 KR，O 是 Objectives（目标）的缩写，KR 是 Key Results（关键结果）的缩写。O 用于描述我们心中希望通往的美好目标，KR 用于描述衡量实现这个目标的关键结果。

为了让大家更好地理解 OKR 的精髓，我们提出以下 OKR 十大要领：

OKR 不是一款绩效考核工具，而是一款目标管理工具。

OKR 包括自顶向下（制定）与自底向上（评审）的全过程。

O（目标）需要做到简洁且定性，要鼓舞人心。

KR（关键结果）需要做到明确且定量，用数据说话。

一个季度制定一次 OKR，季度结束需对 OKR 进行评审。

每周做一次 OKR 回顾，每月做一次 OKR 调整。

OKR 制定过程需进行多次评审，以确保它与上级目标不冲突。

O 一般不要超过 5 个，O 所包含的 KR 一般为 2-4 个。

OKR 需要做到透明化，向团队完全公开。

OKR 评审结果可作为加薪的重要参考依据，但不是唯一依据。

对于 OKR 而言，很多人容易将它理解为绩效考核工具，认为它和 KPI 是同类，这是一种误解。如果将 OKR 理解为考核工具，我们一定无法用好它，也更无法从中受益。OKR 是一款目标管理工具，它管理的是我们所制定的目标，让我们的目标更加清晰且容易实现。

KPI 是自顶向下的，老板定义了 KPI，各级领导去背 KPI，员工去完成 KPI，大家各扫门前雪，达成自己的 KPI 即可。然而，OKR 却是自顶向下和自底向上的全过程，老板结合企业战略去定义企业 OKR，领导结合企业 OKR 去制定团队 OKR，员工结合团队 OKR 去制定个人 OKR，这是 OKR 制定过程。通过一段时间的努力，随后进入 OKR 评审过程，员工评审个人 OKR，领导评审团队 OKR，老板评审企业 OKR。可见 OKR 即包括了自顶向下的制定，也包括了自底向下的评审。

我们务必做到能用一句话来描述 O，这句话要让团队任何人都能完全理解，即简洁且定性，还要做到鼓舞人心。例如，如果目前我们的团队文化做得不太好，我们希望未来一个季度可以得到改善，O 如果写成“改善团队文化”，这句话虽然做到了简洁且定性，但不够鼓舞人心。我们可以将其改为“打造更好的团队文化，让大家爱上这个团队”，是否瞬间就产生了正能量？

每个 O 都有对应的 KR，它们用来说明为了实现这个 O，应该做到的关键结果是什么。KR 需要做到让团队任何人都能完全衡量，即明确且定量，还要做到用数据说话。例如，如果目前我们的系统架构中微服务的颗粒度较大，代码的可重用性方面比较低，为了解决这个问题，我们希望对微服务边界进行切分，如果将其中一个 KR 写成“切分颗粒度较大的微服务”，这样是不合乎要求的，我们可将其表述为“至少切分 3 个颗粒度较大的微服务”，增加了一个数字来描述，这样的 KR 就更加容易衡量了。数字是最容易衡量的，此外“有”和“没有”也比较容易衡量。

通过实践我们发现，一个季度制定一次 OKR 是非常合理的，季度结束需对我们所制定的 OKR 进行评审。OKR 并非制定后就无法调整了，我们自己每周可做一次 OKR 回顾，自行将有问题的地方记录下来，职能团队每月在一起可做一次 OKR 调整，以及时修正我们的 OKR。对于个人 OKR 而言，并非完全由自己制定后就开始执行，个人 OKR 制定过程需要进行多次评审，以确保它与团队 OKR 不冲突。O 和 KR 的数量也有限制，O 一般不要超过 5 个，O 所包含的 KR 一般为 2~4 个。

最后，需要说明的是，OKR 要做到透明化，可用电子表格或纸质卡片来管理，这些表格需要向团队完全公开。此外，每个季度末的 OKR 考核结果可作为加薪的重要参考依据，但不是唯一依据。

我们作为团队领导者，也需制定自己的 OKR，以下是一位研发团队领导者的 OKR 示例（如图 3 所示）。

图 3：一位研发团队领导者的 OKR 示例

写在最后

一个团队需要有目标，也需要对目标完成情况加以考核，目标与考核往往是相辅相成、缺一不可的。如果只有目标而没有考核，将无法检验团队的价值；如果没有目标而只有考核，团队将离我们越来越远。

OKR 不是绩效考核工具，而是目标管理利器，所有人都能理解 OKR 的定义，但不是每个人都能很好的应用它，这也正是 OKR 的魅力之处，往往好的工具都是理解容易，但应用不易。大家可参考我们给出的 OKR 十大要领，再根据自身实际情况加以调整，就能顺利地实施 OKR，在组织中发挥出它的效果。

我们认为，衡量结果好坏的最简单手段就是数据，只有数据才会让人信服，绩效考核关键就是用数据说话。

作者简介

黄勇，现任特赞科技（tezign.com）CTO，图书《架构探险》作者，Smart 开源项目作者，TGO 鲲鹏会上海分会董事会成员，QCon 讲师。十年以上互联网软件架构与技术管理经验，擅长敏捷开发，推崇“轻量级”系统架构。喜欢阅读，热爱交流，乐于分享。

第23讲 | 产品技术团队OKR使用法则

经常有团队问我，团队或者部门是否可以应用 OKR 工作法。我的回答一般是否定的。像销售、市场、人事、行政这样的职能部门，如果彼此独立设定 OKR，几乎必然是无法和公司的聚焦目标对齐的。而且这些孤立的部门无法形成完整的业务链条，如果不能从公司或者事业单元的角度出发，就无法识别出影响成长的瓶颈问题和可能存在的增长动因，也就无法做有意义的聚焦。

但是，这个问题在产品技术部门可能是个例外。尤其是产品型公司的产品技术团队。一方面是因为产品型公司的聚焦重点经常会放在产品本身；另一方面是因为很多互联网公司在产品技术方面遇到的问题和机会都非常接近，以至于我看到不少科技公司在企业层面的 OKR 设定都非常近似。

先决条件

即便如此，也并非所有的产品技术团队都适合独立引入 OKR 方法。如果要让这个方法在企业中发挥出成效，不产生部门本位主义，那么这个团队要符合以下这些特征：

1）产品技术团队能够对产品的设计、开发和交付整体负责；团队具备主控性，而不是受制于多个部门的配合；

2）非项目服务业务模式，产品技术团队服务的是本企业的产品，而不是客户的产品，否则这个团队的核心管理体制很难超越项目管理本身。而且外包项目的生命周期也不足以来激励 OKR 的实施。

3）公司的业务成效很大程度上取决于产品本身的定位、特性与市场需求的适配度和产品质量；销售和营销职能起的是放大器作用。消费者应用领域的公司大多符合这个条件。如果是 2B 的产品则要视情形来看。

如果以上先决条件不存在，那么这样的团队独立实施 OKR 的成效是不乐观的。实际上，缺乏自治度和管理关注度的产品技术团队，本身也很难有动力来自行发起目标管理。即使做，一般也只是为了响应公司从上至下的管理要求而已。

常见的产品技术部门 OKR 类型

当我辅导了十家科技企业的 OKR 制定沟通会议以后，我发现这类企业的 OKR 选择有非常明显的规律。团队相对容易达成一致的目标意图（Objective）大体会分成这么几类：

1、产品特性交付里程碑

这可能是最常见的目标之一。产品技术团队因为担负交付产品和特性的责任，所以容易有这样习惯性的思维——本季度发布 xxx 特性，交付 2.0 版本产品等。

在这个动因下，产品技术部门设定目标要有更清醒的头脑和更整体的认知。为什么要交付 2.0 版本？2.0 版本主要解决的问题是什么？除了形式上的交付，用什么 KR 能够更好地定义交付成功？一个好的产品交付目标应该揭示背后的商业意图。比如：“通过 2.0 解决客户自助部署问题”就是更加完整的目标描述。

正是因为如此，这类目标所配套的关键结果（Key Results）也要能够反映出意图达成的 KPI（请中性理解这里的 KPI 含义）。发布时间本身不应该成为 KR，发布后能够形成的一个关键数据指标才是。比如上面“通过 2.0 解决客户自助部署问题”的 Objective 可能需要配套一个 KR：自助部署页面的 UV 数量，它反映了这个特性交付带来的客户价值，每有 1000 个 UV，说明可能有 1000 个用户得到了自助部署系统的帮助。

在产品特性交付目标方面，我还经常发现一个常见困难，就是每个季度的 OKR 周期很难保证一个大宗的产品特性交付彻底完成，更加不要说获得使用相关的数据。这时候，我们就需要定义更加细分的里程碑，而不是一个版本的交付，比如“完成单元测试”、“完成数据架构设计”等。

2、提升开发和运维质量

在产品型公司的早期，因为经验和能力的原因，在产品开发和运维过程（devops）中存在大量缺陷。有一些质量问题也可能是因为“MVP”理念导致的。这些可能都是创业公司不可避免的阶段。

但当公司开启了商业化进程，建立了专门的销售团队，低质量的产品会消耗巨大的营销投入，不仅无法转化满意的客户，而且会让整个团队士气低落。

但站在公司的角度看，刚刚建立了销售团队，管理层的注意力通常被牵制在销售团队的形成和管理上，有时候是无暇顾及，有时候是没有意识到产品质量对于提高销售效率的重要性。与其等到部门之间相互指责和推诿，有全局观的 CTO 应该尽快聚焦在提升质量的目标上。在达成这类目标时，产品技术团队的自治能力至关重要。

技术产品的质量提升目标不难设定用于衡量的关键结果（KR），但指标选择的过程最好依然是从下至上的，因为非专业人员很难有相关的知识背景。如果是和软件缺陷有关的质量改进，这个关键结果最好能够落在测试流程内部（用例的数量和覆盖度，测试的自动化程度等），而不是去衡量客户投诉率这样的滞后性 KR；如果是和运维质量相关的目标，KR 则更容易选择一些，因为有足够多的监控工具来直接提供有意义的指标。

3、运营改善相关

产品运营的职能划分在不同公司不一样，但有很多互联网企业很重视产品运营，并且意识到产品设计和研发团队对运营管理的直接驱动力。所以，也有不少产品技术团队会直接提出和运营改善有关的目标，这通常发生在企业的成长阶段。

AARRR（获取，激活，转化，留存和推荐）是建立运营改善目标的最佳模型，它揭示出一个产品的总体成功来自这五个基本运营环节的成功。产品运营绩效目标的达成依靠的是方法、智力的投入，比如通过 User Onboarding Design（用户上手指南设计）提升新用户激活度，而它带来的产出在财务上却非常显要。卓越的产品运营能够大幅降低平均营销成本，提升用户终生价值。从这个角度看，来自产品技术团队的相关目标设定，能够大幅影响公司的最终绩效。

这类目标的描述可以非常直白，面对惨淡的留存，产品团队应该意识到“提升用户留存”是一个显然的目标意图。但是在每个公司的具体业务中，它的描述可以更加明确，比如“通过游戏化设计来加强用户留存“，“通过 Onboarding 模块加强用户留存”等。目标的设定越明确，在 OKR 执行过程中的任务设计就越顺畅，在复盘时头脑也更加清醒，不会被干巴巴的数字所制约。

和开发运维质量提升相关的目标类似，产品运营的 KR 制定也有它的专业性要求，比如有关用户留存的 KR，专业领域内有几十个可以使用的指标，到底哪个指标能够反映当下目标的实现度？次日留存和次月留存可能有完全不同的暗示。这需要专业的产品运营自发来选择指标，而不是等待管理层派发指标。同样，前面提到的目标描述的具体度也会影响我们选择 KR 时的精确度。

4、提升产品市场适配度

产品的功能和特性与客户的实际需求存在断层，这是一个普遍的企业失败原因，不仅在产品早期可能出现，在扩张阶段也可能再次遇到。杰佛瑞·摩尔在经典著作《跨越鸿沟》中阐明了出现这种情况的必然性。尤其是科技产品，早期用户和主流用户在需求和心理上的巨大差异使得一个新产品在进入早期市场和拓展主流市场的不同阶段面临完全不同的市场接受度。

产品市场部门很难独立定义这样的目标。不仅可能缺乏足够的决策信息，也很难有这样的决策权威，因为它很容易挑战到一个公司的品牌和市场定位，细分市场选择。所以，这类目标的设定通常都需要和管理层，销售业务部门充分的沟通。

设定好这一类的目标的前提是企业对“理想客户对象”有更加明确的定义。假设这个步骤能够达成共识，那么产品技术团队就需要和销售业务团队仔细沟通产品应该怎样改进才能更好地满足这类目标客户的需求。在以季度为周期的 OKR 执行中，聚焦解决那些能够有助于提高产品市场适配度的关键特性。这时候，选择对应市场的销售转化率作为 KR，可能是更明智的做法。因为在客户买单之前，我们很难找到可靠的前导性指标。对于 2C 产品，验证要更加容易一些，一般留存率和活跃度指标都能够很好地反映需求匹配度。

5、技术选型变更和偿还技术债

在业务成长到一个阶段时，有一些技术团队会意识到紧迫的架构调整、技术选型升级等偿还技术债问题。这更加是一个需要由下至上设定目标的领域，因为很少有公司的管理层和其他业务部门关注这一点。如果业务发展顺利，用户不断增长，那么该发生的事情一定会发生。警惕性高的 CTO 们会未雨绸缪。

设定这类目标时，要重视的是和管理层达成共识，因为这些技术工作必然会影响功能特性开发，锁死一些常规事务的进展，也可能涉及一些可控风险。如果没有事先的沟通，很可能会发生不必要的冲突。

当然，这些目标是否应该成为产品技术部门某季度必须面对的关键目标，不能是 CTO 的主观臆断。它应该建立在数据的客观分析和预测上。

衡量这类目标的 KR 也不难识别，甚至纯技术层面的压力测试就能够很好地回答这个问题。我们有没有让基础构架更加健壮？我们能否承受每小时 100 万次以上的访问？设定了这类目标和关键结构，就公开给其他部门的同事，这样既能够让团队周知这些事务的重要性，争取支持，也能够激励营销和销售部门，建立更强的业务拓展信心。

执行和评估

我列举了产品技术部门可能独立制定的五类目标类型，它们中的一部分依然有赖于和其他部门的深度协作，KR 的设计也考验团队的策略分析和批判性思维能力。但这些都还只是开始，OKR 目标的有效达成，并不是依赖选择出科学的 KR，而是需要设计出切实有效，尽责执行的任务项，并且连续跟踪这些任务的完成状况，遇到的问题，改进方案。

我为什么要强调“任务设计”，而不是“任务分配”？因为 OKR 目标所对应的问题通常不是一个常规运营问题，更加不是一个逐步改良性的目标，而是一个阻碍企业成长的关键问题，必须集中精力去跃升。如果依靠一般的任务分配所能够达到的成效，是很难有惊喜的。当 OKR 脱离了传统的绩效考核范畴，参与者就可以解放思想，采用创造性的手段来达成目标，这就是为什么要叫“任务设计”。

在产品技术相关的目标达成中，我发现卓越完成的情况往往依赖两个重要的驱动力，一是成员的敬业度，二是成员的学习能力。对于一个产品技术问题的解决，很少存在可不可行的问题，更多的是团队暂时没有取得相关的能力，不知道行业的最佳实践是怎样的。敬业度又和学习能力相辅相成，彼此关联。所以，想要 OKR 目标的达成度提高，CTO 和产品 VP 们应该长期关注的是人才的选拔标准，和团队共同学习进步的具体安排。

我在管理明道的几年中，最大的感悟就是这一点。科技公司的兴起来自于关键技术能力的提前掌握，同样，科技公司的衰败也是因为没有能够跟上产品技术进步的洪流，它和团队成员有没有及时完成一个短期绩效目标没有太多联系。所以，OKR 工作法看似是一个围绕短期，高速迭代的执行落地方法，但它的有效性有赖于使用者对长期绩效和价值创造的绝对关注。

作者简介

任向晖，企业社会化协作平台明道创始人 &CEO。梅花网创始人。

第24讲 | 996、987，程序员加班文化你怎么看？

某日，在 TGO 鲲鹏会全国会员群里，一位会员说了句“刚开始实行 996 一个半月，就有人提出离职了”。这一话题马上引起许多会员的共鸣，由此展开了热烈的讨论，其中不乏许多精彩的观点与实用的经验。加班文化，是很多技术管理者绕不过去的困惑，到底应不应该加班，怎么衡量加班的成果，怎么加班才不会让团队的兄弟们反感？为了解答这些问题，我们邀请了几位当天参与讨论的技术领导者写下了自己的观点，供大家参考。

启赟金融 CTO 马连浩：

启赟金融的技术团队规模近 100 人，当前实施 996 的工作时长。我个人工作时长除了和团队一起 996 之外，还会有非坐班时间的支持工作，比如融资支持，商户谈判支持和战略讨论，实际工作时长远超 996。

支撑员工接受高强度的工作时长无外乎是工作内容的高度认可，有温度的管理氛围，高度协同的工作同事，当然还有合理的物质回报。

长期加班必须在工作产出的有效性上，判断自己的工作内容和研发项目是否符合能够有效提高公司的销售业绩，能够有效降低公司的运营成本，能够符合公司未来战略布局，符合度的高低和工作产出的有效性成正比。重复劳动和返工对一线员工影响很大，这块需要技术负责人来把控，保证技术团队接收到的需求是正确的。

任何工作投入和产出都是成正比的，加班实际上是一种时间投入，内外培训和员工分享同样是投入，是在效率提升上的投入，在身心能够承受的范围内，合理提高时间上的投入，肯定在产出上会有正反馈。当然有个前提是加班要建立在工作需要上，提高工作的有效产出上。

更重要的是，让员工建立主人翁意识，认为是公司命运共同体的一部分，为自己的事业而奋斗，很多抱怨和不解自然也就烟消云散了。同时，公司后勤要跟上，比如下午茶，加班水果等体贴式福利还是要到位，让马跑，还要让马吃草。

今日头条上海研发中心负责人，前 WeWork 亚太地区技术总监陈满砚：

我目前刚刚离开 WeWork 加入今日头条。之前在 WeWork 时的团队分散在亚洲各地包括澳大利亚，规模在 50 人。可以在家完成工作, 生病可以 MC。

我自己没有固定工作时长，也没有特定的休息日，毕竟作为亚洲和美国的枢纽，我是单点链接, 累计时长应该在 50 小时一周，如果加上因为工作需要的应酬和洽谈，应该在 60 小时左右。

工程团队由于没有特别可以量化的指标（KPI），所以我们都是 OKR 驱动的，而 OKR 是自上而下的传输，为了达到公司的短期 / 中期目的而努力，所以这个作息只适用于工程团队，我们的销售等团队的工作时间也会比工程团队多一些。

我觉得加班在目标明确的情况下是必须的，比如 release 出问题了，比如吃鸡要一个月上线等。可是加班不应该上升到一种文化，更不能宣传这种奉献，因为我们都清楚 IC 的权利是没有保障的，而公司的利益是有明确的保障的。

我们都知道，有流水线程序员（code monkey），有程序员（engineer）。我不否认，流水线必然会战胜小手工作坊，可是同时我们也要知道，流水线上的每一个人每一个部件都是可以随时被取代的，当 AI 升起，流水线程序员肯定是会被直接淘汰的，我希望我们能发现和培养出更多的程序员，培养他们独立思考的能力，做一些对我们这个技术产业增值的事情。

爱因互动创始人兼 CTO 洪强宁：

爱因互动目前属于较早期的创业公司，技术团队只有 30 人左右。我们不实行 996 也不实行 987，而是五天工作制，弹性上下班时间，全公司实行，从创业第一天开始就是这样。2017 年全年离职率为零。

但是这并不意味着我们是一家慢悠悠的养老型公司，相反，虽然我们没有实施 996，但无论是夜晚还是周末，大家热情高涨加班冲刺的情况比比皆是。作为一家高速增长的创业企业，事情多，期限紧是常态，碰到事情做不完的时候必然需要依靠加班。但我们不把延长上班时间作为工作进度的保障，而是依赖频繁公开的进度沟通，依赖对交付物的质量要求，使得团队成员无论是否加班，都把产出作为首要目的，避免“为了加班而加班”的情况出现。

软件开发是一个高度创造性的工作，为了提高产出，相比于简单粗暴的延长工作时长，我们更倾向于把精力放在增强技术平台、完善工作流程、打造学习型企业文化上，以及更重要的，精挑细选有足够强的自驱力，能融入到团队文化中的人上。

“我们认为用在办公室出现的时间长短来评价一个工程师的产出是缺乏逻辑的。需要加班的场景，一定是因为有事情需要在限定的时间范围内完成，只要事情完成了，大家应该充分享受闲暇的时光。”

这个是我们的招聘文案，我们也是这么做的。

慧安金科高级产品研发总监马宇翔：

我从 955（偶尔还需要倒时差）的工作（4 年）到创业公司 955、996、987 的工作（10 年）都经历过。

首先我认为，不要用“自己的认知”来看待和定义问题，对于创业公司的初创阶段来说，不管是 955、996、987 都是种工作模式，暗扣在企业文化这个大主题下面，只是种表现形式罢了。

创业公司在初创阶段，创始人的性格和工作模式会很具备代表性，所组建的核心团队和对公司认可的初期成员也是对公司、创始人、工作模式的认同。

不能抛开客观条件谈这类开放式的话题，客观前提条件是：创业公司（初创阶段）、核心小团队、企业文化和创始人风格、高效且高度认可的团队成员，在超出劳动合同规定工作时间范围以外的工作，是否界定为加班或加班文化，这一点因人而异了，毕竟每个人的三观和认知并不相同。

我自己目前 987 半年了，依然不认为很辛苦或过于劳累，这样的生活方式与工作方式早已是习以为常的事情，虽然每天八点看似很晚，但要考虑到北京的交通问题，很多时候七点半晚高峰才退去的时间点，八点以后有选择性的文体活动，比如说我可以保证每周 2 次篮球 2 次健身 1 次纯娱乐放松，并未感觉到时间不够或工作严重挤压生活时间。只要这样的生活模式不会影响到身体健康、家庭、朋友、自己的兴趣爱好，也是种不错的生活方式与工作方式的平衡。

二维火产品研发中心副总裁 芦宇峰：

二维火的技术团队大概在 400 人以上，去年我们实行了大半年 996，因此离职的技术人员大概有 3%。

衡量技术人员绩效，当然不能用工时。时间确实不重要，有质量的进度才是重要的，毕竟竞争对手有时候强大到不拼命不行，比如我们的对手是美团，融个资都比公司估值高十倍，你想想有多让人绝望。也招不起百把个博士或架构师，只能用勤奋弥补了。

行业不一样，客户不一样，战略也就不一样。我所处的行业很大一部份是传统软件，我们的客户这些餐饮老板，在见面第一件事不是看你的产品有多好用，而是给我们一张五六页的纸，上面写着几百条功能列表，如果我们的产品覆盖了 80%，才谈下一步。所以，我们对功能量有很大的要求。

任何所谓好的体验，大数据带来的价值，节约了多少成本带来了多少客流，都要建立在整个产品体系的完善上。所以我们是劳动密集型企业。

996 其实是一个概念，或者是一个动员，其实在具体控制上，大部份员工都是早上 10 点左右才到，晚上 8 点半左右离开，这样就行了。还有一些基础要做好，比如绩效奖励，晚餐宵夜零食打车，再加上项目的各种庆祝，中午休息时间加长。非 996 的时候多一些活动和调休，比如周五周六晚上不加班，。实施方法如果得当，996 也不是万恶的。

公司业务快速增长，才是最好的团建。最终还是要回到结果上。如果结果好，那就都好。

众安在线财产保险股份有限公司技术总监 陈天予：

我们公司目前现状是 99N（N=2~4），每周平均会有两三天的加班。在项目或业务需要的时候才会长期开启 996 模式。特殊制度执行时长一般根据项目周期来。高强度情况下最多有过连续 2 个月的 996 状态。

加班只是一种手段，没有哪种手段是万能而不可替代的。但是为了追求更高的目标和自我价值，但凡能用的手段我们都应该用到极致，这其中自然也包括加班。毕竟世间唯一公平的是时间，要追求更多，加班已经是我们能选择的成功率较高的手段了。

对于提升团队产出，首先是团队的使命感培养，只有团队有一致的目标及使命感，非常清楚“Why？What？How？”这三个经典的问句的答案，这样的团队一定能在相同条件下爆发出更强的战斗力。

其次是建立透明公开的奖惩机制，在日常工作中对典型情况及时快速的进行奖惩及团队宣导，尤其是奖励这块，能极大地发挥榜样作用，激发大家的激情和竞争意识。在肯定其工作成果的同时也要不断的给予其更高的要求和挑战。

最后是做到足够的人文关怀，尽可能去关心员工的心理状态和生活情况，在组织有能力的情况下帮员工去解决些后顾之忧或者帮助员工来更好地履行家庭责任。当员工能平衡好身心、家庭的关系时，必定能爆发出更大的工作热情和工作效率，从而提升团队产出。

写在最后

你所在的团队，工作时长是怎样的？你对加班抱有什么样的态度呢？欢迎留言与我们交流。

第25讲 | 建立有效的员工淘汰机制

作为技术管理者，我们要常常梳理团队结构、梯队建设等事项，通过梳理才能更好的认清当下团队的状况，才能为更美好的未来最好准备。

团队的发展其实与个体一样，只有不断的去突破自己的舒适区，根据实际的变化，放弃那些过时的认知，才能不断进步。

想创建优秀团队，筛选出优秀的员工，淘汰不合适的员工，是一个团队能否健康发展的重要因素。好的员工是企业最大的财富，同理，差劲的员工也能让一个企业陷入万劫不复。

本文就来聊聊，当你遇到不合适的员工时，该如何合情合理的进行淘汰。

那些不同类型的“问题员工”

首先，我把“问题员工”分类概括为“既合格，又合适的员工”、“合格，但不合适的员工”、“既不合格，又不合适的员工”、“合适，但不合格的员工”这四种。

从管理者的角度来看，当然是那些“既合格，又合适的员工”更受青睐，为此往往不惜重金招聘，给以丰厚的福利待遇，委以重任。但是，这种员工毕竟是少数，因此，管理者不应该把太多的精力放在这类员工的身上。

其次就是“合格，但不合适的员工”，这类员工往往具有职业上的硬技能，但是也许在软技能等其他辅助能力上缺乏潜力。对于这些员工，企业的处理方法应该是人尽其用，把他们所有的知识、技能都应用在工作中，尽力让企业的其他员工都分享他的知识和技能。

如果他们主动提出要离开，企业不需要着力进行挽留，因为对于当今互联网时代的企业来说，倡导扶持高潜力员工的发展，才是面向未来的有效论调。

再来说说“既不合格，又不合适的员工”，这类员工既不符合本职工作的技能要求，也不符合企业文化的需要，属于“无法胜任，也无潜力”的两无人员，这样的员工对于企业来说并无价值，基本是需要淘汰的对象。

最后说说“合适，但不合格的员工”，企业管理者需要把主要精力放在那些“基本胜任，但潜力大”的员工身上。这些员工虽然职业技能有所欠缺，但是他们所具有的良好的学习技能和沟通技能，决定了他们能够通过培训很快弥补这些不足。

通过以上分析我们发现，问题员工分布的范围比较广泛，技术管理者需认真鉴别，区别对待，发掘问题员工的长处，适当容忍其短处，对其存在的问题适时加以正面引导，真正做到 “用人之长，容人之短”。

建立有效的员工淘汰机制

一个团队必须建立相应的淘汰机制，人人都有危机感，都有随时被淘汰的可能，才能实现优胜劣汰，保持团队活力的同时，尽可能的保持最大的竞争力。就像是鱼群里的鲶鱼，随时威胁大家的生存，才能保证让大家都动起来。

在具备有效的员工淘汰机制之前，有哪些问题是我们需要探讨的呢？比如“如何把真正的‘末位’员工剔除出来？“，“到底是从员工的工作质量、工作态度、个人品德、交际能力还是其他方面进行衡量？”或者“谁来评价，才能做到公正合理？”

可以说，在企业内部建立淘汰机制是必要的，关键是如何做到“有效”，把不符合企业要求的员工进行淘汰，这才是我们应该真正关心的。

在我看来，要保证“淘汰机制”的有效性，有效的绩效管理体系必须具备对企业的高层管理者（与公司总体绩效挂钩）、中层管理者（偏重本部门绩效的考核）及基层员工（偏重工作本身的考核）等不同的考核体系，最终通过约束与竞争机制促进个人及团队的发展，而考核者和被考核者都应将通过绩效管理手段提高工作绩效作为首要的目标。

在执行过程中，对于一些比较容易考核的职位，可以考虑用试用期间的业绩及上司的意见，综合考虑新员工的去留。如果是一些技术性较强的，可以通过技术理论和操作两方面进行考核，再综合上司的意见后，由人力资源部决定新员工的去留。

另外，也可根据员工的综合素质、能力、工作态度等因素，通过换岗、降职、培训的方式进行处理，或者直接淘汰。

总而言之，建立一套员工淘汰机制是非常必要的，但是，淘汰员工要根据企业自身的特点选择比较适合的方式。

如何让员工淘汰更具说服力

众所周知，淘汰员工这件事，无论是用人部门，还是人力资源部门，常常煞费苦心，采取各种办法，结果却常常引发被淘汰者的极大不满，甚至引起劳资纠纷。

为了让这个过程更具有说服力，我觉得需要从“管理环节重视”与“淘汰工作中的原则”两方面进行考虑。

先来谈谈，我对“管理环节重视”的主要认知。

首先，我们需建立起一套有效的甄选机制，进行有效的人才识别，则可为企业招聘到合适的人才，而无须在日后花费过多的精力进行人员淘汰管理。

随后待员工入职后，为避免在短短的一个小时的面试过程中，难以对一个人作出全面而综合的考评，应重视试用期间对员工的更进一步的考核，通过员工在试用期间的实际工作表现，综合考评其知识、技能及态度，以更好了解此员工是否胜任本职，从而作出淘汰或留任的决定。

紧随其后的是绩效考核，通过有针对性的绩效考核制度，实现有效的优胜劣汰，淘汰绩效不佳的员工。但对于许多企业来说，采取生硬的淘汰方式也许过于激进，也可以选择在其合同期满的时候，与员工终止劳动合同，从而达到淘汰的目的。或通过组织架构或业务流程重组时，进行淘汰处理，原来需要两个人完成的工作，现在只需一个人即可，这样，则会对多余的人员进行淘汰。

所谓“没有原则，不成方圆”，与人力资源同学相比，技术管理者在淘汰员工的过程中应承担主要责任，因为对员工的业绩更有发言权，更具说服力。因此，在淘汰员工的管理工作中，除了管理环节重视之外，还应把握原则。

在准备淘汰时，须事先搜集好员工的业绩考核数据资料，只有在论据充分的前提下实施淘汰管理，才能使员工能够接受将被淘汰的事实，不致引起员工过激的行为。

淘汰面谈时，仅对其工作业绩不佳做出评价，不对员工性格，为人处事加以评论，尽量告知员工本人，并不是他能力不够，或本人有问题，只是不适合公司目前提供的工作而已。

明确其的功过得失，不能全盘否定，任何一个员工都会有所长，有所短，有很多员工业绩低下只是因为他缺乏对自已的职业了解，目前从事的恰恰是自已不擅长的工作，或是因部门内部人际关系没处理好。

沟通时，避免直来直去，注意说话的语气，用词，管理方式，方法，注意自已的身体、面部等，并注意说话的语气，措词。

强调“青山不老，绿水长流”的态度，在员工有需要时要提供帮助，千万不能当仇人，因为他们对公司基本上或者全面了解，如果你能想到要帮助他们，他们一旦有机会也会回报你及帮助公司。

结语

无论对于企业，还是团队，在这个互助互盈的互联网时代中，其本质还是竞争。想要达到一个“你好，我好，大家好”的氛围，只是一个美好的梦想罢了。

有竞争，就会有淘汰，只不过在这个过程中，我们应当更合理、更有效、 更具原则性。

作者简介

王晔倞，TGO 鲲鹏会上海分会会员，好买财富平台架构部技术总监。2013 年加入好买财富，在 4 年内亲身经历了公司面向互联网的业务转型与技术变迁，辗转过不同的业务团队，对技术与业务都有深入的了解。

第26讲 | 让细节的“病毒”感染你的团队

很多大公司的技术高管，既要思考战略和执行，又要管理繁杂的业务，有限的时间都占得满满当当。那么，作为企业的技术决策者，是否还需要关注细节呢？对于这个问题，我的答案是肯定的。

为什么要关注细节？

“细节决定成败”，这个道理自古就有，尤其是在这个全球商业竞争激烈的时代，更是很多成功公司奉行的理念。如果要找一个最能代表这种精神的公司，那就非苹果公司莫属了，其产品如 iPhone、MacBook、MacOSX 等都堪称当今工业界最高水平。最近几十年在中国市场上发展起来的很多本土企业，也日益肯在细节上下功夫，出现了很多极为成功的科技公司。

在知乎上有篇写腾讯 CEO 马化腾领导风格的帖子，提到其经常在深夜还发邮件和团队探讨产品细节问题，最厉害的是这些讨论往往第二天就能被团队落实。这个帖子中还提到，QQ 邮箱在 2008 年的 400 多个创新点中，有近 300 项是由马化腾本人发现和提出。马化腾发现这些问题的方法很简单，就是反复使用。

连大公司 CEO 都在半夜讨论产品细节，作为 CTO 或者技术决策者，还好意思说自己没时间关注技术细节吗？并且，我工作这么多年，有个感受，就是越到高层的老板，越重视细节、越抠细节。

谷歌 CEO 埃里克•施密特在他写的《重新定义公司》书中提到，在偶遇一位许久不见的高管时，一句诚恳的问候之后，埃里克便会开门见山地提问：“你最近的工作进展如何？遇到了哪些问题？应该交付的产品进度如何？”这些问题的效果有两重：不仅让埃里克掌握了对方的业务细节，还让他知道这些主管是否掌握了他们的业务细节。在埃里克看来，没有掌握细节的管理者，是不胜任工作的。

所以说，作为技术负责人，同样需要关注技术的细节。而善于提出问题，就是很好的了解细节的方法。

细节决定成败

前通用电气 CEO 杰克·韦尔奇曾在他的回忆录《赢》中讲述过一个案例。

起初通用电气在核磁共振设备的市场中一路领先，韦尔奇曾发现自己的产品口径太过小，使人受到的压抑感太大，而此时日立公司正在研究大孔径设备。韦尔奇与医疗事业部门讨论发现：孔径加大会导致成像的准确度下降，医院的人不会接受。韦尔奇后来一有机会就会督促医疗部门考虑改进成像技术，但得到的反馈都是敷衍。随后不久，原本处于领先地位的通用电气被日立公司超越，其追赶之路辛苦万分。韦尔奇在自传中写道：我非常后悔，为什么自己没有付出更大的努力，对下属提出更严厉的要求。

孔径之大小，能如此影响一个公司的发展，使我们不得不重视细节。

技术做为一个业务中的重要部分，是保障业务成功的基础。由于互联网的应用，涉及到客户端程序和服务器端程序共同实现，也普遍有多个技术系统的相互依赖。在一个大规模分工合作的团队中，产品体验要做到极致，没有技术决策者的亲自参与，就不能有效调动和协调必要的资源，也没法保证执行的快速精准。也只有技术决策者关注到技术细节中去，才能掌握全面的信息，做出准确的判断。否则就会造成很多工作的处理结果，犹如隔靴搔痒，劳而无功。

最近几年流行的短视频和视频直播应用，各家比拼的体验中，秒开就是一个技术上追求极致的例子，就是在细节上的深入探究和改进。

秒开是指手机视频应用中显示的视频，只要点播放，1 秒内就要完成视频的下载并播放。要做好这个体验，需要把点击播放、下载视频、首次播放等环节的处理时间记录日志，并进行分析，来决定哪些环节需要优化来缩短处理时间，这种分析往往会沉淀为日常的机制，确保秒开比例保持在高水平。

为了提高秒开比例，除了手机客户端应用作优化，我们白山云作为视频分发的 CDN 服务商，也需要让速度变得更快，尤其是快速填满客户端上视频播放缓冲区。

对于这个目标，开始团队做了一些改进但是没有大的突破，后来我们的技术 VP 苗辉作为技术专家亲自参与和组织，通过对 TCP/IP 和网络传输的深入研究，优化 TCP 重传、窗口拥塞、慢启动等机制，整体上加快客户端视频下载速度；通过智能 DNS 的动态 IP 库和四维调度算法优化，更实时的把用户调度到网络质量最优的 CDN 边缘节点。那么结果怎么样呢？根据我们一个 CDN 客户提供的数据，其直播客户端首次播放时间稳定在 450 毫秒左右，远远小于 1 秒。

抓住细节的“七寸”

既然关注细节如此重要，是不是技术管理者就应该深入了解每一个细节？这是一部分管理者尤其是初级管理者经常会遇到的困境，关注细节本身没错，但前提是抓住大的，再聚焦小的，找到影响整体工作的关键细节，以免自己被细节缠身。

2014 年我还在前东家时，曾经参与过微博客户端图片和视频的加载性能优化，当时的问题是运营部门经常抱怨，总是说用户投诉图片点开显示慢，或者打不开。客户端团队和存储、CDN 团队做了一些排查和优化，但还是有用户投诉，大家就很疑惑这到底是不是个严重问题？问题在哪里？怎么改进？

当时也是有一些性能监测数据，但是不能直接反应用户端体验，运营部门不认。当时我负责的微盘云存储应用，通过采集客户端性能数据，做性能持续优化，所以我提出先建立微博用户端性能的量化评估指标，比如加载时长、成功率，确保各个业务方都认可这些指标，这相当于大家有了统一的性能标准。

当时先和业务运营方负责人沟通定义好客户端加载性能的几个一级指标，然后推动建立了客户端性能数据采集机制，建立全面的性能数据分析体系，以及不同环节的性能类和质量类二级指标体系，覆盖客户端到服务器端、和多家 CDN。一级指标主要用于运营方评估用户体验，二级指标用来监测各个技术系统的性能质量情况，二级指标对一级指标有重要的影响。并且在我负责的部门内指定了各指标相关的责任人，具体的工作由他们去负责落实、并且为指标达成负责，这样工作就分解下去了。

通过合理的工作安排，和我在重要细节上的关注和参与，最后的工作成果让大家非常满意，有了清晰的数据体系，还消除了很多工作上的争议。经过半年时间持续优化，图片下载速度加快了 25%；对于用户投诉，也能够提供量化的错误率数据，基于用户帐号可以检索全部的服务端日志，以及客户端上报的错误日志，还能排查出是客户端软件异常、手机网络异常、运营网络异常、还是服务器端异常，这些信息对于解决问题和改进产品的帮助也很大。

让细节的“病毒”感染你的团队

只有技术决策者关注细节是不够的，业务上的很多细节，是需要每一个人去关注去抠的，只有这样才能让整个团队重视每一个环节，尤其把重要环节在细节上做极致，才能给用户超出预期的体验。这种对细节的态度，不是每个人天生就会的，而一个业务的负责人，如果能够具备这样的素养，把这样的态度融入在工作中的每一个环节，影响到团队中的每一个成员，就可能培养出更多具备这种能力的员工。

如何打造一个重视细节的团队，我再分享几点经验。

首先，做好招聘环节，更倾向本身就关注细节的人，面试时多问问候选人工作中细节的问题。关注细节体现在不同的方面，关注代码的质量、风格是细节，关注产品的技术方案是细节，关注产品的上线流程是细节，关注业务的成本构成也是细节，关注业务的运营数据更是细节。

其次，通过自己不断对细节的把控来影响团队、树立榜样，尤其对重要事情的细节上斤斤计较，提出细节上的问题，参与细节上的改进，当然，你更多的是分析、沟通、决策，具体的工作更多的是团队来落实。

然后，带领团队梳理流程和方法，通过流程规范的完善，使团队成员更能关注细节，这点再展开说一下。

工作的发展，也是不断完善和细化的过程，比如业务最开始，最先解决的是核心的功能，仅仅满足能用。而在发展过程中，随着业务要求的提高，之前很多没有做的工作就逐渐提出来了，比如运营、质量、监控、流程等等，这些工作的落实，都需要负责人参与到细节中去。

比如去年初，白山云因为一些重大项目推进中的问题，决定建立项目管理机制。一位同事起草了初步的项目管理方案，通过讨论和完善方案，最后定下来项目管理机制、项目需要的文档、立项结项需要的文档等，这些我也仔细看过并且确认。制度确立后，前期的几个重要项目立项，我也参与，一方面是观察团队的接受程度和执行情况，一方面也需要了解制度是否还有些问题。几个月后，我就只关注重点项目的周报、月报，关注项目本身的细节，而不在于项目管理制度的细节上了。

随着项目管理方法被更多团队接受，很多工作的细节就更有保障了。还有其他如客户需求管理、故障管理、变更管理、变更流程等机制的建立完成，让整个团队的工作能力得到提升，在工作上更加有序、也更可控。对于细节的重视，被融入在各个流程机制中，未来随着业务变的更加复杂、团队规模更大，我相信也能保证各项工作高质量的输出。

结语

关注细节，就体现在日常的管理工作中，你了解的细节越多，对工作的问题看的就越准确，管理工作才能做到有的放矢。

深入细节，既是你观察、培养人才的过程，也是团队磨合、建立信任和默契的过程。对于达到稳定的业务，或者配合很默契的下属，你就充分放权，不必太多关注细节，把你省出的精力投入在其他地方。

如果所有的问题，团队都能帮你搞定，那你自然不用太关注技术的细节。但是实际情况不会这么乐观的，总会有一些团队自己搞不定的事情，所以这才是你作为技术决策者存在的价值。

作者简介

童剑，白山联合创始人兼首席技术官，TGO 鲲鹏会北京分会董事会成员 & 学习委员。前新浪研发中心总经理，2016 年 5 月加盟白山，迅速搭建和完善各产品线技术梯队，构筑云链产品技术体系，带领团队推出云存储、云聚合产品，助力白山抢先布局云后市场。

第27讲 | 如何在不同组织文化下推行技术管理

2016 年初，我从一家互联网视频公司出来，那个时候就感受到移动互联网创业达到了顶点，人口红利已经吃尽，2C 端的流量趋于饱和，新的现象级的 App 难以出现，并且受到 BAT 的严重挤压。这时很多传统企业都在谈数字化转型，希望利用云计算大数据等 IT 技术帮助企业转型。我本人接到了很多公司的邀请去构建行业的云平台，来自汽车、医疗、教育等行业的都有。同时我看到业内甚至周围一些朋友也从互联网公司加盟了传统企业，这里面有做的比较成功的，比如平安科技、链家网等等，但也有很多人遭遇了诸多挑战甚至很快折戟沉沙。

最近两年，我先后在两家传统企业集团担任技术高管，目前在海航的科技子公司易建科技担任技术副总裁，主管上千人研发团队的技术体系以及云服务事业群整体管理。在此分享一下如何适应不同企业文化下的技术管理，有哪些挑战与机会。

传统企业 VS 互联网：面临的挑战

通过这两年多的经历，我发现传统企业在诸多方面跟互联网企业还是存在很多不同，对技术高管推行技术管理会带来很多的挑战。

从组织架构上来说，很多互联网公司都是比较扁平化的管理，尤其几年前小米倡导的三级制管理。一般技术产品团队都归 CTO 统一管理，以业务为导向，底下分为技术、产品、运营及运维几条线。而传统企业大多采用事业部制，事业部有独立的人财物的权利，研发团队以成本为导向。公司层面没有 CTO，或者各事业部的研发团队虚线向 CTO 来汇报。这样就造成各事业部通常都各自为政，技术力量比较分散，没有统一的技术体系，各事业部的研发团队只关注自己的绩效，相互之间很难协同。最后造成整个公司形成了大大小小的技术孤岛，也不容易有核心的技术积累。

从激励机制上，互联网企业更看重技术产品人才的创造性，加上近年来创业资本的助推，工资水平较高，同时也会采取股权期权的形式激励。而传统企业通常更看重资源资本的因素，对技术人才的重视程度相对不够，更多的是采用项目奖金的方式激励，工资平均水平较低。这个时候从外部引入互联网人才，工资低了没有吸引力，工资高了，容易形成倒挂，对内部老员工心理上会造成很大冲击。

开发模式上，传统软件开发团队一般采用瀑布模型，对新需求响应比较缓慢。互联网开发团队通常采用敏捷开发，注重小团队作战以及快速迭代。同时互联网公司由于发展比较迅速，人员新陈代谢比较快，可以迅速组建团队，人员也比较年轻。而传统企业进人流程相对缓慢，对学历要求较高，有严格的背调机制，同时也很少主动做人员淘汰，人员平均年龄比较大。这个时候如果沿用在互联网公司一套管理手段，可能会面临水土不服。

个人的经历与收获

互联网技术高管进入传统企业需要考虑如下问题：如何打通技术体系；如何引入新技术；技术人员如何更好的成长；如何调整管理方式。

我本人经历的某家企业是个传统的集团型企业，该企业是一个传统的从事系统集成的集团公司，涉及的领域包括校园支付、身份认证、智能交通等，集团新的战略希望利用线下的优势，尤其是在高校领域行业第一的占有率，孵化新的线上业务，进行互联网转型。

公司管理层下了很大决心来进行互联网转型，在集团层面一年投入了上亿的预算，成立了专门的 PMO 组织，请了业内顶尖的咨询公司做业务规划，并成立了专门的技术产品团队，构建了整套的私有云平台和微服务架构。并落地实施了首例校园支付 App。

但由于上面提到的组织架构，人员激励，团队配合等诸多问题，新的技术和产品未能得到有效的推行和利用，新团队也很快瓦解。

吸取之前的一些经验教训，在目前公司管理层的支持下，我作为技术副总裁，在一年之内推动了如下的一些工作：

技术体系的构建

我目前所在的公司分为三个大的事业群，每个事业群有自己的技术总监。事业群 A 负责集团的大 IT，事业群 B 负责 IDC 和云平台，事业群 C 负责智慧科技。我们的专家委员会由各个事业群技术总监，及他们提名的各事业部的技术专家组成。有定期的会议和月度的技术分享。

通过一年的运行，各个事业群形成了各自的技术体系，同时在公司层面三套技术体系有了边界和融合。事业群 A 和 B 有了比较明确的边界，A 构建 IT 的大中台，而 B 主要聚焦在 IaaS 和 CaaS 平台。C 事业群则主要对外，利用 AI 技术向各个事业部的行业赋能。同时，我认为在一些局部，适度的重复和冗余是必要的，比如我们两个事业群都有一些大数据方面的团队，但各自的场景还是有很大不同，没必要强行去捏合，但是彼此可以有技术的交流和促进。

同时专家委员会由各个事业群轮流，对各自领域的技术进行分享和推广，一年之内我们陆续介绍了云计算、大数据、AI、分布式数据库等主题，也邀请了很多外部的专家，得到了技术人员的踊跃参加和不错的反馈。

另外公司也有比较好的技术投入的传统，在新的技术体系之下，我们通过研发评审，对重点项目进行了财务补贴，这样事业部能够减轻收入利润的压力，加大技术投入。

新技术的推动

即便有了技术体系和技术分享等常态化的机制，推动新技术也会遭遇很多阻力，比如技术人员的学习成本，比如需要其他业务板块甲方的认同等等。这个时候需要利用一些时间窗口和契机。比如集团去年对信息安全比较重视，投入也比较大，我们迅速组建了安全团队，在人员设备各方面做了相应的投入，得到了各方的认可，同时也顺势把这块的技术体系提升了一个台阶。

安全本身也不是孤立的一块技术，和 IDC 云平台都有很大关联，这块的提升也会暴露出其他方面的一些短板。在问题暴露后，我们迅速调整了变更流程和协同机制，也通过春运两会博鳌等一系列的重大保障的检验，使新的技术进入了稳定期。

管理方式的调整

在公司每个事业部负责的业务和技术的挑战不同，就像 Gartner 所提的双模 IT 理念类似，确实有传统 IT 和敏捷业务并存的情况。所以我认为没有必要强行来推动敏捷 DevOps 等理念，允许不同团队选择适合自己的开发机制。

另外对于不同团队，也应该有不同的激励手段。对于发展比较迅速，人员比较年轻的团队，多运用正向激励。而对于情况相反的团队，可能负向激励会比较奏效，技术高管需要有自己的判断，灵活运用。

开展工作前先考虑这些

总体而言，我觉得互联网出身的技术高管在进入新的组织文化，尤其是传统企业时需要考虑如下方面：

业务机会

比如云计算这个领域，公有云的机会已经不多了，如果帮助传统企业构建行业云，实力雄厚的企业集团相对更有耐心，能够保证长期持续的投入。同时大的企业品牌知名度较高，人才基础比较好，能够提供比较好的人员支撑，也有利于组建新的团队。技术毕竟是为业务服务的，如果没有好的业务机会，技术再厉害，也没有很好的施展空间。

管理层的支持

公司的管理层需要对技术有合理的预期，重视技术的长期价值，不急于短期见效。同时管理层对公司的发展历史比较了解，能够对技术的落地给出比较好的建议。技术高管应该虚心听取其他高管的意见，结合自己的技术背景来采取合理的方式推行新技术。

碎片化到体系化

传统企业在多年的发展历程中，已经形成了成熟的业务和组织架构。期望一个完美的战略和一步到位的落地是不现实的。但我觉得长期的机会还是存在的，也是值得很多技术高管去尝试的。毕竟看到你的技术能够支撑一个千亿甚至万亿的企业集团的数字化业务，这种成就感还是不言而喻的。但我个人认为这个重塑的过程必定是碎片化的，量变引起质变的。这些碎片需要我们一点点去寻找和拼凑，直到引发整体变革的那一天。

写在最后

酝酿本文的过程中，正好看到了中兴被美国制裁，以及陆奇从百度离职等消息，感触良多。我本人非常幸运，成长经历中得到了中科大清华很多老一辈的指引，对技术抱有很大热情，少走了很多弯路，但仍感觉跟老一辈还有很大差距。已近不惑之年，深感我们这一辈还是需要有点家国情怀，相信技术能够改变世界，并贡献一份绵薄之力，共勉。

作者简介

钟忻，易建科技技术副总裁兼云服务事业群总经理，TGO 鲲鹏会北京分会会员。2003 年清华大学自动化硕士毕业。曾在 Turbolinux、IBM、Intel 等多家 IT 公司担任资深软件工程师。13 年底到 16 年初担任乐视云平台高级总监，主导了乐视 IaaS、PaaS 平台从无到有的全过程。目前负责易建科技上千人研发团队的技术体系的搭建，以及整个海航集团的 IDC 和基础云平台的产品研发、运营和市场开拓。

第28讲 | 业务高速增长期的团队管理：“知轻重、重绸缪、调缓急”

作为企业的技术管理者，如技术总监、技术副总裁或是 CTO，必定会期望企业业务快速发展，这样技术团队对业务的价值才能最大程度得到体现。但业务的爆炸式增长将不可避免地带来组织结构的变化和管理上的挑战，那么作为技术管理者，你是否做好了迎接这些挑战的准备？

本文将结合我过往在创业公司以及大公司新业务扩张时期的经历，来讲述如何在企业快速成长时做好技术团队管理，我将通过“再识技术管理”来聊聊对技术管理的理解，再通过“边开飞机边换引擎”来聊聊企业快速成长时技术团队管理面临的挑战，并给出一些管理团队的建议。

再识技术管理

技术管理者大多都是从技术专业人才转变成为管理者的，极少情况下存在着没有技术背景的技术管理者，一般都是在企业发展过程中，需要在专业能力或业务贡献上已经被证明过的技术专业人才来成为技术管理者，期望他们将自身的业务能力进行复制，带给整个团队，以让企业的技术团队正向发展。晋升为技术管理者，这是一个令人振奋的新角色，但同时也需要不少新的技能和能力来面对这个职位带来的挑战。我们先来看技术专家与管理者在日常工作输出上的区别：

技术专家

与产品、QA 团队日常撕

分析业务需求并制定技术方案

编写代码实现功能需求以及修复 bug

解决线上故障或突发问题

经验知识沉淀及技术学习

管理者

设立团队目标、制定工作流程

协调必要资源来支持团队、并与其它团队保持良好沟通

观察团队工作进展、向上输出业务进度报告

招募并培训技术人才

评定团队成员业绩

从上面对比不难发现，这两个角色实际是从不同角度来看相同的业务挑战，因此日常需要完成的⼯作内容是完全不一样的。简而言之，技术人才或技术专家是面向任务来工作，而管理者或经理的角色是面向人来工作，他是要驱动激励团队来完成业务需要，并根据公司远景来提前布局。

边开飞机边换引擎

在业务高速发展的公司，例如创业公司 B 轮融资后开始冲业绩、又或是被媒体报道后的激增，一般业务量会有几倍甚至于几十上百倍的增长，这取决于公司的业务模式，这时企业的技术团队将面临巨大的挑战，比如业务系统能否抗住高并发、业务系统的响应速度以及业务代码是否存在影响严重 bug 等。这里我们要聊的是在这种情况下的技术团队管理该如何做，所以我们不过多关注具体的细节问题，而要以管理者的角度来更加全局性地来审视这样情况下面临的核心冲突或矛盾是什么。

大家会经常听到的一个比喻是“边开飞机边换引擎”，这个比喻十分形象地将这种困境描述了出来，我们简化来看这个困境，实际面临的是两个问题，一个是时间，我们需要驾驶这架飞机在最短的时间内安全到达目的地；另一个便是资源，我们拥有的飞机就只有这一架，并没有其它备用飞机提供给我们来进行替换使用，因此我们只能在这架飞机上进行修修补补继续飞。

不难看出我们在企业高速成长时技术团队管理面临的两个核心矛盾或问题就是时间和资源。时间上的矛盾在于业务系统开发和完善、以及技术储备等都需要时间来进行开发维护以及沉淀，但业务增长的速度和时间窗口并不会给技术团队以太多喘息机会，那么在这个时间矛盾下，怎么做好技术团队管理呢？精简来说就是“知轻重、重绸缪、调缓急”，如何理解呢？这种情况下时间对于企业、团队和个人来说都很紧张，因此技术管理者如何分配时间便很关键，如何分配时间和资源也将决定了技术团队的发展趋势和业绩输出，所以做到“知轻重、重绸缪、调缓急”是很关键的。

管理者需要从公司业务未来发展趋势上来做规划，进而来看自己所负责事情的轻重缓急，例如招募并培训技术人才、 Code Review、设立团队目标、制定工作流程这样的事情，对于企业和团队来说是至关重要的，但是并不会马上有明显产出。但需要持续坚持做，是利于长期的事情，那么我们到底该怎么从众多的事务中来做区分呢，下面我们先看一张图：

To Do 轻重、缓急象限图，以及典型事务分布

从上面象限图来看，作为技术管理者我们应该怎么分配时间和资源呢，以下是我简单的总结。

重要紧急：
得做，但要避免做。例如线上故障解决，这种问题重要又紧急，可能目前只能你来处理，但是应该是有各种故障后备用方案，让团队成员去实施，先保障业务然后团队再进行问题定位。

重要不紧急：
坚持做。例如人员招募培养、组织架构调整、Code Review 以及技术踩坑分享等，这些事务做了不会马上产生收益，坚持做的话日后收益会很大。

不重要紧急：
让团队成员做。将锻炼机会留给团队成员，自己做好支持工作。

不重要不紧急：
不要做。在时间和资源有些许喘息机会时，可以安排成本低的方式来处理。

因此，技术管理者应该未雨绸缪地将未来发展所需事务列举出来，也就是说要有技术管理者的远见，然后再将目前要处理的事务列举出来，放置在上面的象限图中，你需要关注的一个象限是“重要不紧急”，另外需要培养团队成员来处理的两个象限事务是“重要紧急”和“不重要紧急”。象限里的事务并非是固定的，会产生事务移动的情况，有些移动是需要技术管理者自己总结和主动发起的，最后跟大家分享两个小案例，希望对大家有些启发。

案例一：运营活动支撑，“重要紧急”变为“重要不紧急”

之前公司有做过一款社交 App，运营同学定期会进行运营活动策划，例如情人节、春节、七夕等，活动类型比较多且比较频繁，涉及到活动广告位、活动着陆页、活动参与页、活动结算以及 App 内状态标识等诸多 App 内相关的修改变更。 对于社交 App 来说，运营活动能够提升客户活跃以及营收，属于是“重要紧急”的事情，一般来说都是分配 1 到 2 位开发人员进行运营活动的开发工作，开发⼈员一般不太愿意接这样的活，因为技术挑战不大且重复性工作较多，面对这样的矛盾局面，我们是怎么处理的呢？

很明显这样的运营活动一定会持续办下去，那么将“重要紧急”变为“重要不紧急”就尤为重要了，然后我们在研发团队内部立了个小项目——“运营活动定制系统”，对于过往经常使用的运营活动策划手法进行了总结整理，可以将 App 内广告位、着陆页、活动参与页以及状态标识修改等诸多内容可以通过该系统进行定制，通过运营、iOS/Android、前端、服务端同学的一起参与，将该项目开发完成，运营仅通过后台便可以完成常规活动的定制、审核以及发布。

案例⼆：提前部署组织架构调整，典型的“重要不紧急”

企业业务初期时，业务线比较少，一般研发团队组织架构按照岗位职责来划分，例如前端团队、服务端团队、运维团队以及客户端团队等。但随着业务不断的发展，会出来很多的子系统和产品，例如产品 A、产品 B、内部运营系统以及数据可视化系统等，这时按照职能划分团队方式的弊端就很明显，研发团队成员需要身兼多项工作任务，如何在各项工作任务之间弄清楚优先级，会出来很多扯皮的现象，并且团队越大，团队负责人专门的管理成本会升高。

面对上述问题，通过提前部署好组织架构调整，可以进行化解。我们先将运维、 数据、服务端团队划分部分人员到基础服务团队，将前端、服务端、客户端团队按照项目组来进行划分，项目组里加上运营、产品团队成员来形成小团队，降低内部沟通成本，提升组织运作效率，同时研发团队绩效考核上会加上项目组业务的权重评分，这样保证项目组目标一致高效运作。

作者简介

刘俊强（微信公众号：程序员精进），现任腾讯云资深架构师，TGO 鲲鹏会深圳分会会员。曾任迅雷技术总监、某互联网公司技术副总裁。10+ 年以上互联网开发经验，8 年以上技术管理经验。

第29讲 | 被80%的人误解的工程师文化

软件开发是一场需要集体智慧的运动，它的成功不完全属于团队中任何一个人。然而，团队成员们做人做事的风格却不完全一样，因此我们需要一种叫做“团队文化”的东西，通过它让大家的心聚集在一起，齐心协力完成目标。

本文将从团队文化入手，站在软件开发的角度，讲述工程师文化是如何打造出来的。文中会包含一些可立即落地的实践方法，大家可根据自身实际情况，灵活运用。

下面，我们就一起聊聊关于团队文化的那点事儿吧。

什么是团队文化？

我们认为，团队文化主要包含以下三个方面：

团队气氛

做人原则

做事方式

我们先说“团队气氛”。我们每个人都希望团队有个好的气氛，都不希望气氛变得糟糕，因为气氛糟糕会让人的心情变得糟糕。我们的工作性质决定了，我们每天都要与人协作和沟通，如果缺乏好的团队气氛，合作关系将变得冷漠，工作也将失去激情。

然而，营造好的团队文化，起到决定性作用的就是团队领袖。公司就是一个最大的团队，公司文化取决于公司老板。道理很简单，团队成员能否加入这个团队，是由这位团队领袖决定的，他决定了人的构成，人决定了团队的气氛。

团队文化也包括“做人原则”。坦率地说，团队中每个人的性格可能不尽相同，性格必然多元化，性格也必须求同存异，同类型的人只会让团队的短板更加明显。我们相信，没有完美的个人，只有完美的团队。但是，做人原则与人的性格不同，做人原则是态度和行为的根基，如果这个根基就不对，那么也很难做成一件成功的事情。

团队领袖就是团队做人原则的根基，他说的每一句话，做的每一件事，团队都看在眼里，大家都以他为标准。如果团队领袖是一位正直的人，那么邪恶的人也无法留在他的团队中。正所谓，物以类聚，人以群分。

做人原则决定了“做事方式”。如果团队都是性格直爽的人，那么一定是有话直说，对事不对人；如果团队都是溜须拍马的人，那么一定会让领导笑口常开，用表象去掩盖事实。不得不说，在一些互联网公司中很多老板（也包括一些领导），他们很喜欢看数据，很相信数据，认为公司是一家数据驱动型企业。如果没有一个求实的企业文化，员工就会拿数据来欺骗老板，因为老板相信数据，员工就会给老板看到数据。

事情做不做都在那里，做的方式不同，效果也会完全不同。一位求实的员工，一定会用数据说话，但不是单纯地给老板看数据，他会将数据背后的本质原因分析给老板听，帮助老板正确地做出决策。团队的做事方式同样也取决于团队领袖，他是怎样的人，就会带出怎样的团队。

综上所述，团队气氛、做人原则、做事方式这三点构成了团队文化，而且这三点都由团队领袖来决定，如果你就是这位团队领袖，不妨思考这样三个问题：

你想要怎样的团队气氛？

你的做人原则是怎样的？

你的做事方式是怎样的？

把以上三个问题的答案写在纸上，反复思考自己是不是这样的，想明白后就去亲自实践，用写下来的这些准则去要求自己。当自己违反了这些准则时，思考为什么会这样？到底出了什么问题？

我曾经写过以下 5 条行为准则，自己一直都在努力践行，这些也是我们的团队文化。

守信 —— 为自己的承诺负责

进取 —— 勇敢面对新的挑战

高效 —— 追求高效工作方式

学习 —— 不断学习新的技能

分享 —— 乐于分享个人收获

其中，守信是做人的原则，进取是做事的态度，高效是做事的方式，学习是对自己的要求，分享是对团队的贡献。

需要注意的是，团队文化必须体现在平时的日常工作中，通过文化来影响整个每个人，通过文化来指导团队的行为，通过文化来融入更多的新人。团队文化不是喊出来的口号，也不是贴墙上的标语。只有我们心中认可的文化，才是真正的团队文化。

既然我们都是软件工程师，那么我们也需要有自己的文化，我们需要的是“工程师文化”。

什么是工程师文化？

弹性的工作时间、优雅的办公环境、穿着自由且随意、做自己喜欢的工作、工程师们说了算……这些是工程师文化吗？显然不是，这些只是工程师文化的表象，而非本质。学习工程师文化，一定要抓住本质，否则舍本逐末，不伦不类。

有些互联网创业公司，对外号称弹性工作时间，但当员工做完当天工作并按时下班时，老板却认为这些员工不够努力，他们都在打工，而不是在创业，老板因此感到心寒，但束手无策，只能在内心里埋怨。当这样的事情屡次发生后，老板对员工会产生更加强烈的不满，离员工的距离也会越来越远，从而不再信任他们。

我有一位朋友，他在一家公司做技术高管，公司提倡工程师文化。他的老板经常对工程师们说：“大家白天写代码，晚上可以做业务嘛，这么早下班回家干嘛呢？做业务的同事天天加班到深夜，凌晨给他们发微信，他们都是秒回的”，当老板说出这句话时，也就注定了，这家公司不可能拥有真正的工程师文化，他们公司所号称的工程师文化其实都是表象，老板根本就不理解工程师文化，公司也留不住优秀的工程师。

果不其然，这位技术高管无法承受老板的态度和行为，选择了主动离职，他的离开影响了整个技术团队的稳定性，导致优秀工程师大量流失，公司业务也受到了影响。

我们认为，工程师文化是以共同解决实际问题为目标的团队文化。工程师文化并非由工程师们自发创建，更不是工程师们的一种自嗨行为。工程师文化是由企业文化所决定，企业文化由老板所决定，老板必须理解工程师这样的人群，才能把合适的工程师放在合适的位置上，才能真正领悟工程师文化的真谛，才能做成一家真正的互联网产品技术型公司。

可以抽象地认为，工程师文化只是一个代号，一种象征。工程师文化强调的是团队有目标、有分工、有协作，而且团队所解决的是当前面临的实际问题，并非是一些不切实际的目标，更不是加班这种表面上的东西。

工程师文化并非一个人或几个人就能打造起来的，需要公司老板以及高管们的认同，自顶向下的影响并鼓励自己的团队。老板必须懂得工程师这个职业，必须深刻理解工程师文化。

怎样打造工程师文化？

如果你是一位技术负责人，你的老板却并太不懂技术，你很希望打造出工程师文化，这样对外容易招聘，对内也能让团队更加融合，工作更加高效。此时你需要掌握正确的操作方法，才能打造出良好的工程师文化，否则后面迎接你的将是一场噩梦。

你要做的第一件事情是，让老板理解软件开发是一项工程，需要工程师们一起合力完成，还要让老板看清工程师的价值。因为在不懂技术的老板眼中，工程师的成本是相当昂贵的，他们做的东西自己又看不懂，不知道钱花得有没有价值，工程师们每天都在做什么？为何做一个项目不能直接开干，还要先去估时？估时会不会有水分？

我们必须站在老板的角度去理解他，把他心中的这些顾虑全部排除掉，让他觉得软件开发是一项伟大而复杂的过程，需要工程师们用科学的方法来避免风险，从而让项目得以顺利交付。很多技术负责人可能都忽略了这个过程，导致后面做的一系列事情，老板都看不懂，也不认为有价值。

当你让老板理解了软件工程以及工程师价值以后，接下来可以做以下几件事情：

让团队扁平，自己和团队一起工作

没有 Leader，只有 Owner

没有“你们”，只有“我们”

一切都以数据说话，分析数据的本质

可以加班，但拒绝无意义的加班

以上这些观点，首先你需要确保自己能做到，你的团队才会做到，你才有可能打造出真正的工程师文化。

接下来，你需要不断培养队员们的软技能，其中有 3 点非常重要的态度，这些态度决定了团队做事的行为：

1、主动担当任务，并非被动等待

2、具备用户思维，产出有用成果

3、具备服务意识，乐于帮助同事

除此以外，你还可以考虑做到这些事情：

让大家成为朋友

缩短项目迭代周期

为每个项目找到 Owner

选择最合适的技术

技术尽可能自动化

注重代码质量

建立开放与共享

预留学习时间

不追究任何责任

只招最对的人，不招最贵的人

你可以组织一些有意思的活动，比如：茶话会、小黑屋、经验分享、内部演讲、摄影比赛、话题辩论、体育活动、健身、户外运动、技能培训、读书会、黑客马拉松等，只要对团队成长有帮助的活动，你都可以去大胆尝试。

写在最后

打造一支高效的研发团队，我们至少需要关注四个方面：组织架构、研发流程、绩效考核、团队文化，这四点缺一不可。其中，团队文化是至关重要的，它是团队价值观的主要体现，是大家做人做事的行为准则。

我们非常提倡工程师文化，但也要有正确的方法去打造工程师文化，需要让自己的上级产生信任感，也要让自己的下级产生幸福感，我们必须做到这些，才能打造出真正的工程师文化。

我已在《技术领导力 300 讲》发表了 4 篇关于“打造高效研发团队”的系列文章，这几篇文章的内容还比较片面，不一定能完全帮助大家解决现在所面临的问题。深知自己水平有限，但我愿意分享，愿意和大家交流成长的点点滴滴，还请大家不吝赐教。

作者简介

黄勇，现任特赞科技（tezign.com）CTO，图书《架构探险》作者，Smart 开源项目作者，TGO 鲲鹏会上海分会董事会成员，QCon 讲师。十年以上互联网软件架构与技术管理经验，擅长敏捷开发，推崇“轻量级”架构思想。喜欢阅读，热爱交流，乐于分享。

第30讲 | 关于工程师文化的六个问题

说到工程师文化，很多人会马上想到 Netflix、Google、Facebook 等知名的硅谷科技公司。如果一家公司的“工程师文化”备受推崇，大家往往会觉得很羡慕，但是到底什么是工程师文化，我们为什么需要工程师文化，却没有多少人说得清楚。今天我们就通过几位技术高管的视角，来重新审视这些问题。

问题一：工程师文化能够令一家公司获得成功吗？

答题人：风投公司 Andreessen Horowitz 联合创始人及合伙人 Ben Horowitz

如果你去问 10 个创始人，什么是企业文化，你会得到 10 种不同的回答。比如企业文化跟办公室设计和筛选不合适的员工有关，企业文化牵涉到价值、乐趣以及人员配合，企业文化就是寻找志同道合的员工，企业文化就是要像宗教一样的狂热崇拜。

在探讨这个问题之前，我想说，任何技术初创企业都必须要做的一件首当其冲的事情是，开发出这样一款产品，它做某件事情达到的效果至少要比目前市面上的通行的方式好 10 倍。好 2、3 倍还不够，因为那样大家切换到新事物的速度和规模都会不足。

任何技术初创企业必做的第二件事是占领市场。如果说你把某件事做得比原来好上 10 倍是有可能的话，那么能做到这一点的公司不止你一个也是有可能的。因此，你必须在别人也做到了这一点之前先占领市场。能够比竞争对手好上 10 倍的产品少之又少，所以，废黜其他窥伺王位的王子要比让老国王退位困难得多。

上述事情如果有一件你办不到，你的文化就会变得一点重要性都没有。这个世界到处充斥着拥有世界级文化的破产公司。文化并不能造就一家公司。

那么，我们还要谈文化又是何苦呢？三个理由：

文化关系到你实现上述目标的程度。

随着公司的不断壮大，文化能够帮助你坚守自己的核心价值，让你的公司处在一个有利的位置，让它未来的表现更好。

也许最关键的一点是，在你和你的人历尽艰辛，用各种惨无人性的努力换回了公司的成功之后，如果你的文化却让你感觉到连自己都不想呆在那里的话，你的努力无疑将是一场史诗般的悲剧。

问题二：为什么要强调工程师文化？

答题人：团队协作软件公司 Atlassian 技术传播者 Sven Peters

产品时刻都在发展变化。在之后的几年中，一个你倾注过血汗和眼泪的产品可能会不复存在。不过，如果你能同时专注于创造健壮的团队和编码文化，你就能够时刻准备着，抓住出现的机遇。而且，发展强健的文化需要对团队所代表的立场达成共识，而这种凝聚力也会正向地反映到团队所构建的产品上。伟大的文化促成伟大的产品。

人们通常会将文化可见的外部标志——免费食物、免费饮品、瑜伽课程、Aeron 电脑椅、电视游戏、Nerf 玩具枪——错误地等同于文化。的确，许多公司，特别是科技企业都会提供这些很棒的福利，但是这与文化没有半点关系。文化是我们如何交流、工作、组织、荣辱与共。文化无法准确描述，但是它能够让员工更加快乐、更有生产力。如果员工害怕失败，公司等级森严，雇主把利润看得比员工更重要，即使有再多的免费食物和公务津贴也无济于事。

在科技界有一个耳熟能详的故事，小型创新公司随着规模的增长会逐渐失去创新的能力。的确，大型组织与初创企业相比会更加结构化，缺乏灵活性，这会导致难以孕育开创性想法并使之浮出表面。文化如此重要的一个原因就是无论公司规模多大，它都可以帮助公司始终保持创新。

问题三：如何让工程师文化体系化、可传承？

答题人：微软 CTO、前 LinkedIn 高级副总裁 Kevin Scott

在扩展研发团队的时候，最有价值的管理工具是文化宣言（cultural manifesto）。文化宣言是一个文件或一组材料，以帮助整个研发团队处在同一轨道上，让大家清楚如何做事情，以及如何作为一个团队运转。文化宣言是引领公司高速增长的锚。LinkedIn、Google 和 AdMob 的文化宣言是完全不同的。因为不同地方的环境不同，在每一个地方所专注的要素也不同。

如何建立一个文化宣言以引导和激励研发团队？

不要等到灾难出现才开始行动。无视研发文化会不经意间产生巨大危害。起草一份宣言就是迈出积极的第一步。当危机来临时才决定开始写可能会非常困难，应该尽早开始腾出时间起草一份文化宣言。

经常性地讨论和修改宣言。随着时间的推移，宣言可以作为一种优化研发文化的方式。不要指望公司开始存在的那一刻，你的文化就完美地与你的公司契合。由于每家公司的情况都有所不同，其文化宣言也必然不同，但是可以利用一个统一框架来讨论如何组建、操作和运行一个团队。

寻求协调，而非达成共识。让每个人都在同一轨道上并不意味着让每个人都认同。因为文化宣言必定站在了某个立场，可能会不符合研发团队中部分人的利益，所以没必要让每个人都对宣言认同。文化宣言不是一份意见目录，而是一份打印好的承诺。

明确界定研发的角色。市场能够帮助研发团队清楚地认识研发的角色。清醒地观察市场之后，研发的角色会变得清晰，即需要研发团队取得一切可能的先发优势以帮助企业占得先机，这在研发文化中应该得以明确。而且研发必须具有灵活性，即采用的技术平台可以让团队克服大量的风险并迅速采取行动。

问题四：如何让价值观潜移默化地影响每个人？

答题人：开源软件公司 Redhat 总裁兼 CEO Jim Whiteh

当行动和价值观一致时，组织文化就成一种积极的力量，推动组织更快实现更大的创新。当行动和价值观相背离时，就会发生相反的情况，组织就举步维艰。

这里举一个例子。我最近参加了一个公司会议，其核心价值观就是安全。安全高于一切，它形成了公司所有决定的基石。当会议正式开始时，有人进入房间一本正经地向我们告知附近所有紧急出口的位置。这个人说：“在紧急情况下，我们将沿着以下路线疏散，在这个确定的位置重新集合”。

没有人觉得诧异，每个人都觉得这个启动会议的方法完全正常、自然和有价值。事实上，如果会议没有这样开始，我怀疑人们会马上注意到并立即说出来。这家公司希望安全——这一核心文化的价值——无处不在。因此，它建立了安全无处不在的一系列可观察和学习的行为。

对比这个例子，我知道每个人都至少看过一次，领导声称有价值的东西，却没有鼓励或强化它。价值只出现在行为中，行为取决于价值观。当同事加入组织时，他们会立即接受周围人的行动表达出来的的价值观。

问题五：在公司规模持续快速扩张的情况下，怎样保护公司文化？

答题人：在线网页制作工具 Jimdo CTO Arne Roock

文化是一种难以捉摸的东西。我见识过一些公司企图制定和控制本公司文化的失败尝试。在我看来，凭空制定自己向往的公司文化，然后指望据此建立一家公司，这绝无成功可能。在现实中，公司文化的来源正好相反，它已经蕴藏在公司的运转方式里面，重要的是从中鉴别出有效的成分，确认创始人和每位员工认为重要的方面，并找出需要加强或改变的地方。

一旦确定了公司的核心价值观，写成书面的记录可以坚定公司的支持立场。接下来就要采取行动来滋养、强化和扶植我们树立起来的公司文化——首先从创始人自身开始，以身作则来影响其他人。

文化的重要性说起来好像是个很玄的话题，但其实与我们的日常工作息息相关。每当遭遇困境，面对重大变化，或者招聘新员工的时候，我们总是可以停下来，问一问核心价值观可以怎样帮忙解决当前的状况。这个办法总能取得很好的结果，至今帮我们排解了诸多难题和冲突。我们真诚相信健康的公司文化是无价之宝，并且会大胆地投入在这上面。

问题六：硅谷和国内的工程师文化差异在哪里？

答题人：Twitter 高级主任工程师王天

工程师本身的人都没有什么区别，硅谷在之前那么多年的发展过程中积累下来一些很好的实践，普通工程师已经受到这些实践的训练，你觉得天经地义就是应该做的东西，或者搭一个东西要搭成什么样子，对底线的感觉不一样，国内对底线的容忍比较低，工程师文化的发展实际上是慢慢抬高这个工程质量底线。

大家觉得硅谷有很好的工程师文化，实际上是因为大家在整个环境和社区的影响下已经塑造了比较好的底线，有共同的话语。国内这些话语在慢慢形成，硅谷和国内现在的联系也很紧密，当这些实践慢慢实施开的时候，国内的底线也会提高，工程师的环境也会更加活泼健康。

现在国内非常活泼，那么多公司，那么多东西大家都在做，但是经验在传播的过程中有时候没有很好的积累下来，或者需要有人推动一下。科技媒体，还有整个社区的交流，这些都非常重要，在中国以前这些东西影响可能没有那么大。

结语

以上就是我们关于工程师文化的六个问题，和技术领导者们给出的答案。可以肯定的是，上述几位答题人都认为构建合适的工程师文化是必要的，并且应该坚定地贯彻下去。那么，你怎么理解工程师文化？你所在的团队有令你骄傲的价值观吗？欢迎留言与我们探讨。

第31讲 | 五位技术领导者的文化构建实战

昨天，我们一起了解了关于团队文化的一些事情。作为技术领导者，构建良好的工程师团队文化可能是你绕不过去的一个课题。今天我们就请 5 位过来人，讲述他们的文化构建实战经验。当然，由于每个公司对工程师文化的理解不同，这些经验不一定能拿来就用，但至少可以提供一种思路。

中青易游 CTO 张辉清

我 35 岁前主要钻研技术，近几年逐步转向管理，带过几十人至一两百人的研发队伍。在最近的管理工作中，总结并归纳了几个可以贴到墙上的大字，即 “共治分享自视一起拼，简单有效快”。

共治：共治就是部门要共同治理，自我管理和部门管理一起进行，每个人要管好自己，部门的共治我们希望能转化为个人的自治。具体形式有部门共治文件夹、轮值会议等；

分享：因为专业所以自信，因为自信所以开放，因为开放所以分享。具体形式有周五分享日、书斋建设；

自视：自视就是自我察觉，双眼反向注视着自己。对公司和他人的要求转化为对自己的要求，少一些抱怨，多找一些方法，如乐捐；

一起拼：一起拼就是团队要一起拼搏，一起奋斗，一起喝酒、一起爬山，如户外、项目管理；

简单有效快：把复杂的事情变简单，追求事物的本质，这就是简单有效。“快”是指快速地交付，快速响应业务的需求，如站立式会议等。

当我们确定了这个阶段的部门文化后，团队氛围有了较大的改善，从死气沉沉到激情活力，从固步自封到好学分享，从互相推诿到勇于担当。在后期的几个大项目中，项目的成功显得自然得多，特别在新员工的融合上，成本也低得多。

文化的构建并没有想象的那么难，也没有多少高大上。它也需要脚踏实地、土了吧唧，一步一步埋头干。先有管理工具、制度和行为措施，然后予以贯彻，形成一种习惯，最后才是总结提升。

我们不能简单的参考大公司的做法，或者管理书籍上挑选几个词语，然后领导喊两声或挂在墙上。构建团队文化的过程就如同花朵或生物一般，需要播种、栽培，然后才能收获。这样「长」出来的文化，才能管人做事，深入骨髓、改变思想，才能成为公司或团队的核心竞争力。

付钱拉高级架构师 周恒

关于如何建立工程师文化，我们付钱拉团队的经验是，最好的方式就是把业务和技术结合起来，通过技术降低业务的难度，从而提高学习的时间。分享技术，让代码和思想都能得到升华。

我们在团队内部通过工具化，框架化和实时重构，本质上简化了我们的运维成本，同时也提高了大家对技术的钻研兴趣，用学习的技术解决实际的生产问题。另外还有挺重要一点就是平时工作中多鼓励大家钻研技术，鼓励刨根问题，鼓励知识共享。鼓励思维创新，鼓励组建技术小组，攻克技术难点。开展黑客马拉松，强调竞争，合理奖赏。另外在工作之外，会组织一些游戏竞赛，一来放松心情缓解疲劳，二来团队合作增加彼此了解。

其实工程师文化就是一种放松的，自我驱动的技术文化，在这种文化下，通过成员的自我创新，通过技术手段，降低工作强度，优化业务数据，将技术与生产的需要相结合，并做到极致，从而使人在这个环境中得到飞速成长，团队也飞速进步。工具化，框架化强调 DRY 原则，避免重复，提高工作效率。实时重构避免代码质量恶化，重新设计提升代码品质。技术氛围创造来良好的环境，促进工程师文化持久留存，人人受益，团队才会受益。

出门问问 CTO 雷欣

作为一个核心团队来自于谷歌的初创公司，出门问问的公司文化很大程度上受到了谷歌工程师文化的影响。其中我印象最深的是，谷歌对代码质量的要求和追求到了一种近乎狂热的程度。

那我们怎么在一个小的 Start Up 中间达到谷歌的代码质量呢？我有一些建议：

坚持原则

一定要坚持原则，坚持 Unit Test 和 Code Review。

Start Up 的步伐、步调是非常快的，各方面的竞争也很激烈，你不快的话就会落后。在这种情况下的话，很多产品经理面对各方面的压力，可能会说“我只需要这个产品快速出来，我根本不 Care 你是怎么做的，你的代码质量、代码风格，Whatever，我不 Care。”
但实际上，，从公司的长远角度来讲，你把基础框架搭好之后，对以后的发展、稳定都会有很大的帮助。因此，在很大程度上，要坚持 Unit Test、建立 Code Review 的机制，一定要保证你的代码是有一定质量的。

拥抱开源

第二点是要拥抱开源。实际上，谷歌是一个非常大气的公司，它已经把很多很好、很酷的内部的东西都开源出来了，我们要做的话，就只需要把这些东西积攒在一起，然后搭建一套更适合于创业公司的开发环境。

鼓励更新、快速迭代

很多时候，我们会面临一个问题，代码的第一个版本出来之后，我以后是在这个基础上修改呢，还是在一定阶段把它推翻了重来呢？

谷歌内部基本上都认为，没有什么代码是能活过超过 2、3 年的，所以，会对代码进行推陈出新。实际上，在代码的推陈出新之间，会把以前没有考虑到的东西会做得更好，也会锻炼新人，然后学到更多东西。

FreeWheel 高级副总裁 容力

拥有良好工程师基因团队的三点要素：

1、管理人员必须要从技术第一线提拔而来

如何从一线的工程师转成技术管理者，对个人和工程师团队文化来说都是非常重要的一环。我非常看重的的一点是，技术公司的管理人员一定需要从技术第一线提拔而来，这样才能让公司保持工程师团队文化，而且这种文化才具有与生俱来的某种技术特性。

在我的定义和 FreeWheel 的文化中，转变为团队领导的人必须要在他的团队里具有最顶尖的技术水平，要能够服众。

2、培育一种开放的文化：信息和思维双维度

我们的开放主要体现为在信息维度的充分共享和在思维维度的创造激发。整个公司发展中，技术层面和商业模式层面的信息，可以在领导层和员工之间做到充分的沟通和共享，使得全员在任务处理上能更好地把握整体方向、理清事情的优先级，做对公司最重要的事情。另外，大家做事情都是本着平等开放的原则，不会因为说话的人不同，就对他提出的问题或者方案有不同的态度。这样做的目的就是要激发大家的积极性，充分发挥每一位员工的创造力。

3、对 Engineering Excellence 的追求

追求 Engineering Excellence，是近期 FreeWheel 整个工程师团队的最大变化。在公司整体度过了生存期的挑战并进入到加速生长期时，我们要关注的事情，不再是到处救火，而是要追求卓越， 要打造一个可以在未来几年里，支撑业务发展的优秀技术平台。 在这个新的目标下，FreeWheel 工程师团队也发生了不少变化，包括对 Full Life Cycle Engineer 理念的倡导，对 CI/CD(持续集成 / 持续交付) 等高效开发流程的探索和精进等。

花虾金融 CEO、前宜人贷 CTO 段念

作为管理者，我们会忍不住像游戏一样去设计规则，但这是不可能的，我们也不应该这样做。我们应该去强调约束，定义规则的边界，确保规则跟约束没有冲突。

我们倾向于让团队成员自己以民主的方式形成自己团队的规则，我尽量不插手。当然，在团队发展早期，你也可以尝试为它设置一些规则，但你会发现这些规则很快就会被团队内部产生的新规则所替代。

有些公司比较看重员工的一致性，尤其是思想上的一致性，统一的价值观，这点我是不认可的，我觉得统一思想这件事毫无意义。所谓共识，大致有三个层次：

愿景。就是“什么该做什么不该做”。比如往页面上放广告，这事儿该不该做，大家会有自己的看法。

价值观。就是“应该怎样做事”，在愿景之下，通过规则和约束体现出来。我觉得价值观不是贴在墙上的东西——越是贴在墙上反复念叨的，一般都是越没有的东西。

规则与约束。这是在行为层面。规则是一个很容易被复制的东西，比如开发流程，你看到大家都用 pull request 提交，你也很容易跟着这样做。在这个过程中，价值观得到了强化。

对于我来说，我更愿意大家在行为上一致，而不去追求思想上的一致。规则创建的过程应该是民主的，这个过程需要有冲突，有碰撞，有妥协——因为大家的思想并不一致；而规则一旦建立，则人人遵守规则。

结语

以上就是五位技术领导者在实践中总结的“工程师文化”的内涵及实施经验，可以看出来，不同公司的工程师文化确实存在比较明显的差异，相信也是在实践中慢慢演化而来。希望你也可以通过思考与实践，在你的团队中构建起最适合的文化。

第32讲 | 文化是管理的那只无形之手

文化是人类群体创造并共同享有的物质实体、价值观念、意义体系和行为方式，是人类群体的整个生活状态。对应到技术管理上，就是管理者对于大家意识的影响力，小到对于整个技术团队价值观，公司技术氛围、行为方式和状态的构造和影响能力，大到对于国内技术生态甚至国际技术生态的影响力。

文化对于公司和部门管理非常重要，它是无形之手，决定了你团队的价值观是什么，你的公司能不能招聘到高级的技术人员，在我们日常流程和管理者眼睛看不到的地方，员工是怎样工作的。是否可以打造一个合适公司发展的技术文化，是否可以构造一个开放、透明的技术氛围，是否有能力建立一个 MTP（Massive Transformation Purpose）能让每个技术人员深入人心，能在技术圈内影响到志同道合的牛人共同来一起奋斗。

“影响意识”的能力是一个 CTO 水平高低的评判标准，也是每个”O”级别管理者能力的体现。同样是 CEO/CTO，除了可以“成事”的领导力，文化构造能力也是决定了哪些企业可以持续壮大，哪些企业会昙花一现的关键要素。

《原则》当中提到, 公司就是一个从目标到结果的运作的机器，而这个机器构成主要有两个部分文化和人：优秀的机构拥有优秀的人和优秀的文化，优秀的人具备高尚的品格和出色的能力，优秀的文化不掩盖问题和分歧，而是公开妥善的解决，喜欢让想象力驰聘且愿意开创先河。大多数公司在初期技术团队可以形成点状的成功而无法延续成功都是因为没有构建合适的企业技术文化不断升级公司这个“机器”、保持引进卓越优秀的人才。

构造技术文化的关键点

构造一个公司的技术文化，需要结合公司的顶层设计确定以下几个关键点：

愿景

技术团队要成为什么。一般会根据公司的业务和技术团队具体情况定义一个宏大定义，它就像一面旗帜，吸引高级技术人才的同时激励现有员工不断学习，挑战自己的极限，让自己成为卓越团队中的一份子。

例如，在易观，技术团队要成为世界顶尖的用户大数据团队。这里结合公司的愿景，阐述了几个事情，第一是，易观的技术团队是做大数据的，特别是用户大数据，其中涉及到的技术就比较垂直，用户画像、数据存储、数据采集、数据处理、数据引擎等，都是面对用户大数据的，而不是自然语言、爬虫、舆情分析这些。那么，在招聘和技术品牌宣传当中，就可以针对做这些人群进行定向宣传，同时人员培养的路径也比较清晰。

第二，我们要做世界级别的顶尖技术团队，因此，我们要的是卓越的人才，面临的挑战也会世界级别的，这样可以激励加盟易观的小伙伴可以不断挑战极限，遇到 5.5 亿月活的时候也不认为多复杂，遇到复杂的模拟用户行为的算法时候就不会觉得不靠谱，激励员工不断挑战不可能。

只定义愿景还是不够的，作为高级技术管理者，我们不能把它变成空的口号，而要在日常的招聘、培训、工作安排当中，都要体现我们实际的行动。例如，招聘的人员是否都是卓越的人员，给予大家的培训和辅导是否是国际化的，技术的挑战是否是其他公司无法提供的，是否有技术大牛来在面对无法攻克的难关的时候给大家指点迷津。有些是当时无法一步达到的，定义了愿景，整个技术团队就要不断的为之努力。

使命

技术团队要去做什么，一般都是一个宏大的概念，一般是和公司业务一个比较抽象集成，例如为世界贡献 XXX、改变世界的 XXX，连接世界的 XXXX。它和价值观一起，指导员工具体怎样去做事情，大家内心有一个的使命，会在具体做事情、做决策、发生矛盾的时候有一个统一的目标。

例如在易观，技术团队的使命是“让未来数据科技开箱即用”，这里面有几层含义，第一是未来，我们使用的都是最前沿的技术，甚至是我们自主研发的技术，这些技术相对于我们服务的内部客户和外部客户是未来才会普及的技术，放眼未来的科技，才让我们不会停滞在当前临时的困难和辛苦。

第二是数据科技，这既明确我们是针对数据这一细分领域，同时也澄清我们要做的是科技，而不是简单的技术应用，需要大家有科学家的探索和不断迭代试错，挑战极限。而“开箱即用”说清我们技术的目标是什么，不是为了炫技，而是为了让内部、外部的客户通过极致的“开箱即用”的体验认识到卓越技术带来的效果。所以，技术是要有商业闭环的，一味追求技术并不是在技术团队要追求的事情。大家在定义技术团队使命的时候，一定要和公司的实际业务来结合技术团队的使命，这样可以和公司其他的部门耦合更紧密，也会和其他团队更融洽。

价值观

一个团队提倡的团队理念，换句话讲，不符合这个理念的人，是不能招聘到团队当中的。首先，价值观是在公司大价值观之下的，每个公司都有自己的价值观和理念。其次，针对技术团队需要增加一些特殊的价值理念，例如，绝对透明，勇于担当等等，这些价值观定义了你的团队是怎样的一群人走到一起。这和一个管理者的管理风格也密切相关。一个高级管理者的价值观会带入到团队当中，所以，才会有“强将手下无弱兵”，“兵怂怂一个，将怂怂一窝”。价值观没有对错，但是定义了哪些人可以“对味”。在处理事情和决策当中，碰到公司价值观的红线，那么很大可能会被清理出团队。如果价值观不同，也很难在团队中立足。

结语

愿景、使命、价值观看上去虚无缥缈，但其实它定义了你要的是怎样的人，这些人要去做什么，用什么样的理念来处理事情。而正是这些人在这样的文化下，把公司一个又一个的目标变成结果。文化并不是一日就可以建成的，它需要定型后，不断的给员工反复重复，直到这些文化成为你团队的灵魂，在管理者在或不在的时候，让你的团队可以在这样的文化下进行自我驱动自我决策。

此前，我已经给大家分享了领导力、体系搭建能力、人员管理的能力如何构建和提高，这些都是有形之手，都是看得见摸得到的；而文化，就是管理的那只无形之手，融入到你团队每一个人的血液里，在很多前面几种能力鞭长莫及的地方发挥它的力量。

作者简介

郭炜，易观 CTO ，中国软件行业协会智能应用服务分会副主任委员，TGO 鲲鹏会北京分会董事会会长。负责构建易观技术团队、完成易观大数据采集、平台、数据挖掘等技术架构与体系；从无到有完成易观混合云的搭建、以及易观 SDK 的升级，并发布易观秒算实时计算平台。目前易观大数据平台日处理数据量 30T ，272 亿条，月活用户 5.5 亿。

第33讲 | 选对的人，做正确的事情

人才队伍，对一个组织能否打胜仗起到至关重要的作用；人才结构，决定企业能够做多大走多远。人对了，事才能对，选对的人，做正确的事情，企业才能步入发展的快车道。企业经营的过程就是在招兵、练兵和用兵的过程，今天我们就来谈谈招兵买马这件事情。

招聘的岗位要求、流程和方法论，本文不作过多探讨，相信每个公司都有自己的操作章法。本文把重点放在招兵买马认知和实战经验上面：

选用什么样的人才？ —— 甄选人才的六大基本标准；

如何挑选人才？ —— 识别人才六大基本素质的实用方法；

哪类人才要慎用？ —— 管理者要慎重聘用的六类人才。

甄选人才的六大基本标准

“以德为先”作为选用人才的第一个标准。

没有良好的职业道德、人生观和价值观的人才，往往缺乏奉献精神，很难将做好本职工作作为对自己的第一要求，严重时，其不良倾向会波及和影响整个团队，进而给团队带来较大的管理难度和管理风险。如果管理者道行不深，很有可能需要花费大量时间和精力纠正其行为，却效果不大，产出也很低。你的时间和精力是宝贵的，不应该投入在没有产出的人身上。

“务实为本”是选用人才第二个标准。

任何成功都是从点滴开始积累的，务实型人才往往乐于从基础工作做起，一步一个脚印。尤其是搞技术的，如果整天只是夸夸其谈，不干实事，浮于表面，将很难立足，很难给公司创造价值。唯独踏踏实实，认认真真，把心沉下来，用心做好事情，在做事情的过程中，不断磨砺自我，提升自我，方能成为企业的顶梁柱。

“良好的团队精神”是选用人才的第三个标准。

现代企业中几乎不存在个人英雄主义逞能的土壤，成功离不开团队全体成员竭诚协同努力。一个缺乏团队精神的人，表现为自私、利己、很难与别人合作、很难认可别人的贡献，这样的人会与团队格格不入。如果无法融入团队，即使有一技之长，也很难有机会施展，最终无法为团队创造应有的绩效。

“较扎实的基础知识”是选用人才的第四个标准。

较扎实的基础知识是能否进行有效培养继而使其成为“能人”的前提条件。其中最重要的是语文知识和数学知识。一个人如果具备良好的语文基础知识，则理解和表达能力通常不错，有利于与人的沟通；具备良好的数学基础知识，则逻辑思维能力会比较强，处理事情一般会比较严谨和细致。另外，良好的语文和数学知识对于掌握新知识、新技能也非常有利。

“认同企业文化”是选用人才的第五个标准。

认同企业文化与招聘后人才的稳定程度有关。人才不稳定，不但不利于团队工作的开展，而且会增加人才招聘成本，给企业带来不必要的负担。有了共同的团队文化，大家用一种语言沟通，在同一频道上对话，有一致的想法，工作步调又一致，节奏一致，劲往一处使，形成合力产生共振，把组织效能发挥到最大，最后把事情做成，正所谓上下同欲者胜。

“较好的发展潜力”是选用人才的第六个标准。

较好的发展潜力是一个人能否快速成长的先决条件。企业需要的是这种具有较好发展潜力的人才，因为企业为这样的人才付出的成本可能不会很高，但其创造的价值却会不断增长。这也是大家选股票找对象喜欢找潜力股的原因，性价比高，未来增量将会释放大量价值。

识别人才六大基本素质的实用方法

应聘者是否具有良好的道德情操，可以通过了解他以前的工作和学习情况来发现，也可以通过他的言谈举止来观察，因为一个人内心的想法多数时候会“溢于言表”。

应聘者是否具有良好的务实精神，可以通过查看他以前的工作履历来了解。如果由于个人原因而频繁跳槽，这样的应聘者十有八九不属于这一类，聘用时需慎重考虑。

应聘者是否具有良好的团队精神，可以通过讲解项目研发过程，遇到的人和事，是怎么处理和面对的，通过设置好的一系列问题去深挖，去捕捉他处理的小细节和肢体语言来判断。

应聘者是否具有良好的语文基础知识和数学基础知识，可以请他就某一个问题进行书面（或口头）阐述，通过他的表达清晰程度和分析理性程度来判断。

应聘者对企业文化是否有认同感，可以通过向他介绍企业的规章制度、用人政策、薪酬政策等，来观察他所表现出来的认同程度。

应聘者是否具有较好的发展潜力，可以通过他对事物的个人见地去了解，是否具备相应的思维空间和相应的意识。有些时候，通过观察应聘者的精神面貌也可以作为基本的判断，精神面貌积极、阳光的人，一般来说发展潜力都不错。

管理者要慎重聘用的六类人才

个人简历与实际情况不符者

管理者在招聘人才时，一般是先看应聘者的个人简历，然后决定是否面试。在面试的过程中，如果发现应聘者自我介绍的内容或者回答的问题与其个人简历上描述的存在较大的差异，那么这样的人要慎重聘用。一个弄虚作假的人，不要期望他能在以后的工作中干出多少名堂。此外，不诚实守信就很难和上下级建立信任，做的事情和产生的成果就会被质疑，自己痛苦，上下级也痛苦，是个双输的结果。

频繁跳槽者

在把自己的岗位工作做好的前提下，根据自己的职业生涯规划，理性地选择更有利于自我发展和成长的工作环境，应该是一种值得肯定的行为。但有些人才，却往往把跳槽作为“快速”提升自我价值的有效手段。这种类型的人才往往会急功近利，当感觉自己已经达到“自我期望”时，无疑又会选择跳槽。经验表明，大多数频繁跳槽者的工作经验和技能不如同工龄的工作比较稳定者，因为他们在频繁的跳槽过程中，空耗或贻误了一些非常难得的沉淀经验和技能的时机和机会。

眼高手低者

在招聘过程中，我们会发现有些应聘者高估了自己的工作能力，只想做“大”事，不愿做“小”事，这种类型的人才要慎重聘用。因为这类人实际上眼高手低，往往“小”事不想做，“大”事做不了，不愿从基础工作做起。这样的人在工作中很可能会找各种各样的借口推脱他们自认为“小”的事，而最终变得游手好闲，无法为团队作出应有的贡献。

夸夸其谈者

在招聘的过程中，我们会遇到口若悬河、夸夸其谈者，自我介绍时滔滔不绝、天花乱坠，甚至根本不着边际，这种类型的人才要慎重聘用。因为这种类型的人往往不太务实，工作起来比较浮躁，通常只图将事情做完，而不关心事情是否做好。这种类型的人才很难委以重任，对团队的贡献也比较有限。技术工作是靠能力靠本事干出来的，不是靠嘴吃饭的。

过分看重个人利益者

有些人才，过分看重自己的个人利益（如薪酬、福利等），将企业能否满足他的“自我期望”作为是否“加盟”的首要甚至唯一条件，这种类型的人才要慎重聘用。因为这种类型的人才有不断膨胀的个人私欲，他们的“自我期望”是无止境的。即使招聘时满足了他们的要求，工作时他们也会不时提出新的要求，甚至将是否满足他们提出的要求作为是否继续工作的条件。这种类型的人才虽然可能会有贡献，但管理起来会非常辛苦。

过分追求自我表现者

有些人才，一味追求自我表现。他们往往过分自信，一心追求彰显自己聪明才智的机会，这种类型的人才要慎重聘用。因为这种类型的人才只看重自我表现，不善于考虑别人的利益和感受，不愿意与别人协作，其能力发挥将非常有限。现在是一个协作共赢的年代，成就别人，也是帮助自己；成就公司，也就是成就自己，大家都是命运共同体。

结语

李云龙的部队无论走到哪里，都不会忘记两件事，一是招兵买马，二是筹备武器装备（工具），这才由千多人的团队发展到后来将近万人。对于现代企业来说，这两件事同样重要。互联网公司的核心竞争力是人才，人才多寡、人才结构、人才分布和人才搭配决定组织效率，决定公司生死存亡。祝各位管理者都能找到适合的人才。

作者简介

黄玉超，现任拉卡拉金融集团研发经理，有十余年的软件开发、架构和技术管理经验，其中有八年互联网金融行业经验，喜欢阅读，乐于分享，爱好技术管理和领导力的深化，使其工具化的落地。

第34讲 | 打好技术团队搭建的基础

从运营、到产品、再到技术研发落地，都需要一个团队的执行，尤其要仰仗团队的核心骨干来执行落地。对于 CTO 等技术领导者来说，招聘始终是绕不过去的话题，毕竟，任何一个团队，都不是每个岗位都齐整，等着你来领导的。如果技术领导者不能搭建自己的强大团队，是无法胜任其岗位的。

那么，招聘前需要做好哪些准备工作？如何定岗定级？有哪些有效的招聘渠道？本文将就这些问题展开探讨。

明确发展阶段

首先要明确的是公司发展阶段，这点非常重要。产品从 0 到 1，和 1 到 N 的过程中，对团队的人员需求，能力诉求是完全不一样的。在从 0 到 1 的过程里，讲究的是如何高效的利用现有的条件实现产品研发落地，而不过分追求技术的先进性。

这个阶段中，往往从 CEO 开始到一线的产品、研发人员未必清楚产品在市场上的响应，整个团队的核心思想其实是需要将产品放到市场上试错，从而收集第一手的用户数据，这时，时间决定一切。这个时候的 CTO（未必就是一个 CTO，可能是技术总监或者技术专家的角色）更多应该扮演的是技术专家的角色，主要的工作是根据产品的设计，带领大家一起写代码，并在团队资源紧张的情况下，自己撸起袖子写代码。

随着产品在市场的反响越来越好，慢慢的有了一些用户基础和用户数据，数据日益增长，原来的系统架构越来越不能胜任用户增长、数据增长的需求，要求平台从会员、商品、WMS、交易等进行划分，甚至微服务化，此时对团队的技术能力要求也越来越高，需要专人专岗负责，甚至专业的团队来负责。这时，团队规模较公司创立之初有了较大幅度的扩张，CTO 应该将更多的精力转移到团队管理，如绩效、战略等。

明确团队发展阶段对于 CTO 来说，是招聘的前提，比如在创业之初，没有 P9 级别的诉求。做技术的人都有一个通病，总是希望将技术做到极致。殊不知，在 QPS 1000 都到不了的情况下，从技术上将 QPS 做到 100 万级别没有任何价值。

在本人的从业经历中，遇到过这样的例子：当时公司 TPS 大概在 100 左右，本人空降过去成为技术 Learder，团队里有一个技术控，他的技术能力确实不错，一眼就能看穿我们当时的系统技术上的瓶颈。但是当时的系统足够使用，没有从技术上改造的必要。而当时另外的一个业务产品需要新的团队来负责，我希望由他来负责，但是他就是不想负责这个业务产品，就是想对平台的技术进行改造，希望团队能协调资源支持他进行改造。多次沟通无果，最后不欢而散。

我也遇到过另外一个相反的例子，当时我们系统的 TPS 大概在 3000 左右，而实际的用户场景中对 TPS 的需求已经达到了 30000+，直接导致系统每天都要不定时的重启。我认为每天对生产系统不定时的重启是不合理的，而且没有监控系统，不知道什么时候需要重启。在本人未入职之前，整个技术团队为了解决这个问题，将所有的精力都投入到了新产品的研发中，而置生产系统不顾，关键是新的产品不知何时落地何时上线，也不知能否解决这个问题。我上任之后的第一件工作就是希望解决这个问题，其实从技术上来说并不难，但由于团队里没有合适的人，只能是我自己带领技术人员来解决。

以上例子说明，作为技术领导者，在用人和招人时，要非常明确团队所处的阶段，在合适的阶段用合适的人，当然也包括 CTO 在内。

定岗定级

大多数的创业型互联网公司都是靠融资活着，在公司扩张方面，有人任性，有人谨慎。当然也见过有人任性到拿到投资时无限制招人，到最后裁员的结局。任何一家公司都不可能无限制的扩张，基本都是根据业务的需求制定合理的招聘需求，对于技术领导者来说也是一样的。

作为一个技术领导者，需要根据业务和产品的需求，结合现有团队的资源（现有团队的能力分布对于新的业务需求在招聘岗位上的能力需求是很有意义的参考），定义岗位的能力要求。

比如，现在要做一个 WMS，那么首先就要评估团队的现状，明确团队的技术栈（比较忌讳采用全新的技术栈，一般沿用现有的技术栈）。从产品角度来说，如果团队成员对 WMS 都比较熟悉，但就是没有资源能将想法落地，此时需要一个对 WMS 有点概念或者比较资深的产品经理来设计落地即可，至于招聘还是内部提拔，视不同情况而定。

对于研发技术人员的需求，本人比较崇尚根据目前团队某个产品的 duty team 的构成作为参考，而不是盲目地提升团队的需求，导致招人困难，致使项目延期；也不需要为了便于招人，刻意降低团队的需求，从而导致最后产品质量没法保障。

那么如何定级呢？相信大家对现在互联网行业中的 P／M 定义都非常熟悉，但是不能照搬，要结合自己团队的现状定义合理的级别。此时，HRBP 在这个过程中能够起到很大的作用，通常 HRBP 在每个季度都会对团队的效能进行分析，明确每个团队，每个伙伴的绩效分析，和效能分析报告。CTO 可以根据这些分析报告，结合业务需求，制定比较合理的 headcount。

在技术管理者中不乏这样的人，对 headcount 的诉求是拍脑袋决定的，总觉得人越多越能显示权威，说明自己越厉害。这样的技术管理者自身就是不合格的，我们一定要避免陷入这种思维。

招聘渠道

面向不同岗位，不同定级的招聘诉求，对应的招渠道应该尽量多样化。可能很多人都认为招聘渠道的获取应该是 HR 的事情，这种观点本人并不认可。本人 2003 年参加工作，那个时候领导真的是领导，在办公室高高在上，而现在的领导，尤其是互联网行业的 CTO 等，已经早就不是领导，而是保姆。对于招聘渠道的布置和推广，CTO 至少要参与其中，给出思路，让 HRBP 去执行。

目前比较有效的几个招聘渠道，基本上有下面几种：

1、熟人圈子
这种方式是最可靠的，尤其针对核心岗位，骨干级别，高 P／M 级别的岗位，非常推荐这种方式。熟人圈子最大的优势是，对于业主和候选人都知根知底，背景清楚。

2、猎头
通常企业在需要招聘团队负责人时，才会启用猎头，毕竟利用猎头的成本不低。但是，由于猎头准入门槛较低，滥竽充数者大有人在，作为团队负责人，想要提高命中率，恐怕需要向猎头明确候选人背景、候选人经历、能力、岗位诉求、岗位价值回报等。因为对于候选人来说，猎头是其最先接触，并最先了解企业的入口。候选人往往会希望从猎头口中得知更多的关于企业的信息。这就要求企业在向猎头发布招聘需求时，非常清晰的表达企业的要求之外，还要明确说明岗位的工作内容，价值回报等。

本人经历过太多猎头推荐岗位，大多数的猎头没有办法清晰的描述业主的 vision、企业的商业模式、岗位的基本诉求，更多的在谈该岗位的价值回报，要知道，通过猎头推荐的岗位，候选人往往更加在乎的是能否共同成长。

因此，通过猎头实施招聘，建议选择专业的猎头机构，专业的人员合作。

3、内部推荐
内部推荐实际上是对企业文化的一次考验。记得一位朋友曾经说过，如果公司发布的任何一次关于公司 vision，团队文化建设等，员工都将其分享到朋友圈，说明该公司的企业文化建设相当成功。

大多数创业型团队将内部推荐作为常态工作。根据岗位定级的差异，设计内部推荐的激励制度。内部推荐成功的概率往往比较高，毕竟大家都不希望自己推荐的候选人被拒，从而或多或少影响到自己。

4、扫街
负责团队招聘的 HR 在各大招聘信息网站上海选简历，将符合需求的简历放入到人才库，接着再一个一个电话预约面试。

这种获取简历的方式工作量巨大，效率比较低下，也难以获取符合岗位诉求的候选人。
目前，很多公司已经不大会采用这种方式了。

5、发布招聘信息
大多数希望从传统转型到互联网的企业比较喜欢的招聘渠道。由于深受传统思维的限制，这种类型的企业的 HR 大多认为用人单位是强势的一方，就等着人家主动投递简历过来，我来筛选。

现在的招聘方式变了，候选人更加在乎的是自己做事情的感受，是否被认可，是否受到应有的尊重。不是说不能发布招聘信息，而是应该更加主动的出击，直接面对候选人，而非被动的等待投递的简历上门。

对于招聘渠道，往往需要一个双向的，长期的建设过程，除了正常的维护高质量的招聘渠道之外，还要尽量的对外推广。推广的目的之一是企业形象的推广，实际上是促进招聘的便利。

结语

招聘，对于很多团队来说，只是日常工作的一部分，毕竟业务每天都在变化，团队也每天都在变化，铁打的营盘流水的兵，谁都无法保证在一家公司呆一辈子。以上我分享了一些自己在多年工作中总结的招聘流程和渠道，相信大家也都有自己独特的经验。总之，作为技术领导者，需要在日常工作中不断总结经验，从而不断提升招聘成功率，提升团队效能。

作者简介

吴万港，前中恒云能源 CTO，TGO 鲲鹏会杭州分会服务委员 & 学习委员。10 多年的互联网行业从业经验，带领多个团队完成设计、研发了分布式 K/V，分布式数据库，日处理达到百 T 级别的分布式文件系统。8 年以上互联网行业大型的产品、技术团队的建设、团队发展、团队管理经验。对于从产品需求、技术实现等管理方面有全面的认识和实践经验，深入理解敏捷研发管理办法以及多年的实践经验。

第35讲 | 做个合格的技术岗位面试官

昨天的文章中，我分享了如何做好技术团队招聘的基础工作。那么，当有了较合适的简历，应该如何有效的面试，在满足自己岗位需求的同时，将不符合要求的候选人挡在门外？本文将详细讲述，作为一个技术领导者，如何做好面试的工作。

不同岗位关注点不同

由于个性，知识背景，每个 CTO 在招聘过程中，面试的技巧都不一样，有人偏向技术，有人偏向情怀，等等，各人各异。本人认为对于不同的岗位面试技巧，不同的候选人，面试技巧应该因人而异。

在定岗定级时，基本上就确定了，不同岗位在团队中扮演的角色的差别，有些岗位是核心岗位，而有些岗位则是辅助性的，相对来说没有那么重要。

对于核心岗位，根据岗位的需求，针对候选人的简历，在短短的不到 2 个小时的面对面沟通中，主要考察的是候选人对该岗位描述中使用到的技术的掌控能力，以及候选人过去的工作中是否真如其描述的那样的经历和经验。

针对核心岗位候选人的面试，在面试过程中，考察的重点往往是候选人过往的经历是否对该岗位负责的事情起到带头的作用，候选人的经历和经验会成为考察的重心，作为技术领导者，要能一眼看穿候选人是否夸大其自身经历和经验，不至于被忽悠了。

另外，对于核心岗位，公司都是非常希望候选人作为核心骨干能够与公司长期共同发展，共同成长的。这里要表达的意思是，应该要给候选人卖一点情怀，让候选人能够明确的感觉到团队希望其能共同成长，共同发展，而不是仅仅为其提供一个工作的岗位。

而对于一般的岗位，最重要的是考察其能力，是否能够胜任岗位所描述的需求，若能够满足，实际上可以录用的，否则就算了。针对这些岗位的候选人，本人觉得比较忌讳的是大谈特谈所谓的忠诚度，谈贡献，而忽略了个人利益。很有可能对于候选人来说，他们所需要的可能仅仅只是一份工作而已。

当然，任何岗位的面试，针对候选人的基本技能、感知认识等的面试和了解，是任何一级的面试官都必须要去面对的问题，这里不做深入的探讨。

如何考察技术能力

针对技术岗位的候选人的面试，随着面试慢慢的深入，往往候选人会放下戒心，有些 CTO 会抓住这种机会，在自己认为重要的技术点上，采用压力面试，实际上考察的是候选人在面对危机时的临场处理能力，面试官也未必比候选人就这些知识点了解的更加透彻。本人就非常喜欢根据面试气氛的变化，采用这种方法。

面试过程实际上是双方相互之间第一次了解和试探的过程，候选人向面试官详细描述了自身的背景、经历之后，出于互相尊重的需要，尤其是对于核心岗位的候选人，面试官需要将公司的商业模式，公司的 vision，团队的现状告知候选人，向候选人描述团队对该岗位的定义和诉求，以期达到双方对该岗位预期诉求的基本认同。

对于技术岗位的面试，很多公司往往会进行临场的编码考察。这种面试方法本人也比较喜欢，尤其是定位在 p7/p6 以及以下级别的岗位，这个定级的岗位在日后的工作中往往是方案设计、编码的主力，对于性能、可靠性等关键的质量要素的敏感性往往很高。因为大多数候选人是很不喜欢考察临场的代码能力，在面试过程中考察其临场代码能力，实际上并不是要求候选人完全按照既定的思路和设想去完成，并达到完全正确，而是为了考察候选人在面对临时的全新的命题时，解决问题的思路方面的能力。

面试中的忌讳

往往，针对比较核心的岗位的面试可能要持续好几次，不同的面试官（包括 HR）从不同的角度了解候选人的背景、经历等。最后不同的面试官会得出不同的面试评估，最终是否录用可能会根据团队情况的变化和面试评估报告，最后给出一个综合的结论。

但是，非常忌讳的一点是惹恼了候选人。这里讲一件本人经历的事情，记得在 2013 年前后，我在面试一个视频云 SaaS 平台的解决方案工程师时，候选人有在一家国内大型的专业提供视频服务的企业的背景，由于本人一时不慎，要求候选人在视频 SaaS 的基础上，详细描述广电集团在景区的应用场景中就视频历史数据本地化和云化如何结合的解决方案。候选人觉得其背景受到了质疑，面试持续了 5 分钟就不欢而散，最后 HR 团队认为我作为面试官，不够尊重候选人，给企业带来了负面影响。

这个例子想要说明的是，切忌一时口快，而让候选人觉得受到了质疑。面试官在控场的同时，要把握好面谈氛围，尽量让候选人觉得愉快，从而能够让其放下戒心，清楚的表达其真实想法。同时，面试官也能在候选人比较放松的状态下，更加直观的了解其真实的背景和经历。

同样忌讳的是，在面试过程中和候选人海阔天空，夸夸其谈，偏离了面试的本质，最后什么面试结果都没有。记得有一次本人的一个 HRBP 反映，下面的一些主管在面试过程中毫无时间观念，和候选人就一些热点事件聊的不亦悦乎。这种面试过程，其结果多数是候选人反映面试官不专业，不切实际，面试官针对候选人没有有价值的面试评估报告。浪费大家的时间，浪费公司资源，最后拖延的往往是项目时间。

结语

CTO 等技术领导者是核心团队的核心领导者，对于运营、产品到最后研发落地等岗位，招聘中对于候选人的考核，尤其对于核心人员，请将综合素质摆在第一位，宁缺毋滥是第一原则。同时，在关注候选人素质的同时，也要不断提升自身面试技巧，并充分尊重候选人。只有这样，才能赢得合适的候选人的认可，从而提高入职率。

作者简介

吴万港，前中恒云能源 CTO，TGO 鲲鹏会杭州分会服务委员 & 学习委员。10 多年的互联网行业从业经验，带领多个团队完成设计、研发了分布式 K/V，分布式数据库，日处理达到百 T 级别的分布式文件系统。8 年以上互联网行业大型的产品、技术团队的建设、团队发展、团队管理经验。对于从产品需求、技术实现等管理方面有全面的认识和实践经验，深入理解敏捷研发管理办法以及多年的实践经验。

第36讲 | “高潜力人才”的内部培养

三年前，我加入饿了么担任 CTO，这三年饿了么技术团队从 30 多人发展到数千人。经常有人问我，饿了么技术团队怎么做招聘。其实关于招聘，我个人倾向于：高级岗位尽量内部培养，其次校招，最后迫不得已才会空降。

空降不如内部培养

这里的高级岗位是指 P7 或以上级别，或者管理类的，我们称为经理的这样一些角色，一般一线工程师的招聘可能问题不是很大，也谈不上空降。高级岗位合适的人是比较难找的，因为你是要管团队，或者要去带一个业务的架构，或者作为很有深度的专家。管理型人才、架构师我们通常都是内部培养，基本是这样一个思路。校招有些挑战，有些校招的同学非常不错，比如有些海归的硕士，他可能进来就是一个高 P。

我刚进饿了么是救火的，我虽然自己是空降进来的，但我还是倾向于内部培养。因为空降的员工要跟公司的业务，或者老员工去磨合，确实有一些麻烦，这也是我那时候的一个感受。

内部培养是有周期的，空降可以很快来一个看上去很不错的人，马上可以上手干活。但是空降的人，他不一定熟悉内部的情况，人员的情况。还有业务，比如原来我认为外卖是个很简单的业务，进来之后，远远复杂度超过我的想象。

不过我的观点主要是针对创业公司，其他企业不好判断。业务比较稳定的公司，比如说外企，或者大型企业，我感觉可能空降的情况可能会多一点，因为外企相对来说，对试错的容忍度差一些。因为已经有很好的业绩，你轻易再去试错，万一把主营业务拖累了怎么办？不像我们创业公司，本来就是在不断试错。还有上市公司，要关注财报，你花了这么多钱，结果没有业务产出，跟投资人也不好交代。这些公司更趋向于求稳。

“高潜力”人才的标准

内部培养管理者，我们通常有两个选拔标准。首先技术一定要 OK，他至少有一些，我们叫“技术的信用”，大家都认为这个人技术不错，不一定需要很牛。在饿了么刚开始人不多，都是技术可以的，你如果技术不过关，只是说管人很厉害，下面的团队是不服的。我们现在的管理岗，技术是一个必选项，你要曾经做过厉害的项目，而且在饿了么证明过你做过这样的项目。

第二就是经历过火坑，因为有些同学不愿意去做跳火坑的项目，或者救火的项目。满足这两个条件，就是我们愿意去培养，也是我们内部叫“高潜力”的人才。他可能现在工作时间不长，很难说有多少经验，但是他潜力比较好，我们就愿意花精力去培养。

在管理方面，我们有时候会拔苗助长，可能很多公司也经历过，这个工程师他可能自己不喜欢做管理，但是现在没有管理者，这个位置你先扛着，扛着扛着有些同学发现管理很有意思，有些同学越做越郁闷，他说我要么离职，要么重新做很纯粹的技术。这两类同学，我们都有。

对于后一种没办法，只能让他回去做技术岗，因为强扭的瓜不甜，不是每个人都想做管理的。我们这边，尤其公共团队，很多同学讨厌做管理，更喜欢做比较成熟的技术，就让我安安静静戴个耳机写 Code，或者做调优。因为他们是要成为一个深度的专家。

但是在产品研发，就是垂直团队，可能有些同学就走两条路线。一种是管理岗，因为他要跟产品经理去聊，跟业务去聊，跟运营去聊，他必须有沟通能力。很多同学不愿意做管理，更多的还是不适应做沟通这个活，不光是跟自己的团队沟通，还要跟合作的团队做沟通。还有一种呢，他也不带团队，但他会去主导一个项目，我们叫架构师，架构师也需要很强的沟通能力。整体而言，我们的管理岗并不多。

没有“最适合的人”

当必须外部招聘时，怎样找到最合适的人？我觉得这个很难，因为空降之后首先要磨合，这是个长期过程，我个人这三年来的经验，包括以前在一些稍微大一点的公司的经验是，能找到合适的人纯属运气好。没有最合适的人，磨合融合是必然的，再厉害的人，情商再高智商再高都是要磨合的，因为家家有本难念的经。

即使你人脉比较广，或者资金雄厚，比如刚刚融到一笔资金，可能在外面给的 Offer 很诱人，也很难找到特别合适的人。你开的出价格，找到的可能是牛人，但牛人不一定是合适的人。比如一个创业公司，只有三个人，它现在最缺的不是 CTO，你找一个很牛的 CTO 来没有意义，找个程序员来干活就可以了，先把系统搭出来。有可能你找了一个 CTO 三个月后，代码没搞定，公司倒闭了，你找了个程序员三个月后做了个 APP，或者做了一个什么系统出来，后面慢慢再去找厉害的人。

公司内部挑战自我

我们垂直团队的绩效，其中最主要的一个指标就是业务指标，因为他们是跟业务是紧绑定的，我们叫业务单元。当然有的团队说，我这个业务单元今年业绩做得不好，我是不是也受累？没错，就是要受累，除非你不愿意做这个业务，做这个业务，技术团队，还有产品团队，运营团队，首先就是要对齐业务指标。

我们的垂直团队一般是按领域来拆的，不是按角色来拆。对单个成员来说，他的成长首先与他的业务指标相关。我们内部对于垂直的产品研发 PE 或者 RD 来说就八个字，一荣俱荣，一损俱损。我们开玩笑说，业务今年做得很好，你技术老是宕机，但没有一起大问题，你也有收获；但业务做得一塌糊涂，你一个 Bug 也没有，你今年也是 Nothing。当然说的略微有点夸张，但就是这个意思，这些工程师不仅仅只是程序员，他要懂业务，懂产品，他甚至可以去挑战业务，挑战产品，说你这个功能是不是合理，应该如何调整。

也许有人会觉得这样绑定是不是合理？我们认为是合理的，这就是自己的一个选择。我们招人的时候，你做过订单，我倾向于你来做定单；你做过用户会员，我倾向于你来做会员；你做过结算支付的，我让你来做支付。但也有些同学可能喜新厌旧，他做腻了想换一个。你换一个也要考虑风险的，没有旱涝保收的，旱涝保收谁都想去，这种不存在的。

一开始，公司既然决定做这个业务，肯定是有一定前景。当然成熟业务每年的指标相对是可预计的，试错的业务就考验同学们的判断力了。我们内部是鼓励去创新试错的，风险和收益成正比，稳定的业务很难有那种非常大的那种突破，它可能每年会有增长率，但这个增长率基本上是可以看得到的。就像有些在硅谷的程序员说的，他可以看到他 20 年后的样子。所以为什么很多硅谷的程序员都回中国？中国可能空气质量不好，中国的创业公司可能倒闭的比例比硅谷高，但是他至少不是那么容易看到 20 年后的自己，有机会脱颖而出。

结语

内部人才培养好处多多，不仅能够为企业节省成本，降低团队成员间沟通、磨合的成本，也能为员工提供更多机会，增加团队成员的归属感。但是做好内部的人才培养，也要求企业的技术领导者建立起有助于人才成长的机制，前期会辛苦一点，但是后面就会有很大的收获。

作者简介

张雪峰，饿了么 CTO，TGO 鲲鹏会上海分会会员。曾带领携程软件架构团队 & 框架研发团队，后担任携程国际 BU CTO。曾有过一次创业经历（教育行业），深知创业之痛并快乐着的感觉，理解创业之苦、之难、之惨烈。

第37讲 | 技术创业该如何选择赛道

你好，我是熊飞，经纬创投董事总经理。今天我想跟你分享的话题是“技术方向创业该如何选择赛道”。

这两年，技术创业，特别是 Infra 创业有一些新趋势出现。

第一，资本市场开始认可，国内 3~5 亿美金估值规模的公司大量增加，如七牛、GrowingIO 等。毋庸置疑，在 2-3 年内，我们会看到很多 Infra 领域的独角兽出现。

第二，商业开始认可，这些公司已经形成商业化的收入，好几家公司收入规模已经达到亿元量级，并且保持高速增长。

第三，创业机会极大增加，可以看到美国 Infra 公司创业持续繁荣，随着大数据、云计算在各个领域的使用越来越深入，大家对于底层架构的要求越来越高，使得创业机会极大的增加。

同时，整体生态愈发繁荣，任何行业都是需求驱动的，否则技术人再牛、再有愿景也没什么意义。这 3 年，我们能够明显看到底层架构在云计算、存储、网络等领域的客观需求在暴涨，我们正生活在一个非常好的时代。

趋势背后的原因

为什么这些趋势会在这 3 年如此显著的发生呢？

第一个原因是人的问题。 人越来越贵，劳动力成本越来越高，所以大家都在思考怎么去自动化。以运维为例，原来运维没那么复杂，运维人员比较好招，工资也不是很高，所以公司不太在乎要不要把运维自动化。但是，这两年情况发生了变化，运维越来越复杂化，运维人员也越来越贵、越来越不好招，所以大家拼命想把运维自动化，或者能不能买到相应的产品来提升效率。

第二个原因是各行各业的业务互联网化已经成为核心趋势。 以银行等传统行业为例，面对蚂蚁金服、腾讯金融等互联网金融公司的冲击，对他们来说，IT 问题已经从一个锦上添花的问题变成一个生死存亡的问题，这是一个非常强的驱动力。

另外，以电商为例，现在他们会花费几百万买安全产品，但在大促时，这笔支出会帮助他们拦截羊毛党，挽回一两个亿的损失。因此，对他们来说，IT Infrastructure 已经从锦上添花变成必然的基础设施。

这些都反应了各行各业的互联网化，也让 Infra 创业领域充满机会。

第三个原因是各行各业都认清了数据的价值，都在尽可能收集数据、分析数据和使用数据。可以看到，不管处在哪个领域，大家都有一个非常清晰的概念，那就是不管用不用得上，先把数据收集上来再说。

正因如此，现在数据量在暴涨，行业对数据处理的实时性、分布式等都提出了更高的要求，这也使得大家对底层架构的要求变得非常高，由此需要更先进的供应商来解决问题。

如何选择赛道

既然如今的趋势这么好，那技术人创业该怎么选择赛道？我觉得可以主要看三个方向，一是数据，二是新技术架构变迁，三是机器学习应用。围绕这三个主题，未来三五年内将持续出现很多新兴的创业机会。

首先来看数据，数据的大方向下又包含几个小方向。 第一是数据量的暴涨带来的存储、整合等领域的巨大机会。

第二是数据对实时性的要求越来越高，如果你在实时性数据处理上有相关积累的话，这里就有很多机会。

第三是新型的数据格式，比如图数据、IoT 等。过去一年，图数据库的创业非常红火，行业至少有 3 到 5 家非常不错的公司开始尝试这个方向。背后也是同样的道理，随着风控、社交等领域产生越来越多的多维数据，对数据处理也要求越来越有效率，图数据库因此有非常多的机会，IoT 数据也是如此。

第四是在线数据分析，很多数据是在云上的，通过 Realtime、通过业务数据做分析也有很多机会。

因此，如果你想做 Infra 领域、做底层架构方向的创业，可以先围绕数据做思考。

其次来看新技术架构的变迁。 过去 2-3 年，最火的词就是容器，而这会衍生出安全、运维等多方面的问题。因此，如果你们在容器生态下有自己很好的解决方案，可以试着通过开源等渠道先推广出去，有很大机会在里面。

另外像是近年来火的 Lambda、Serverless，包括更细分的软件定义的存储、软件定义的网络等，其中都有很多机会。

最后来看机器学习的应用，可以衍生出自适应的安全、自适应的运维、自适应的很多方向，而在安全和运维两个领域，已经出现了很不错的创业公司，是真的能够大大节省人力和提高效率的。

这些就是我对赛道的理解，把握数据在暴涨，把据新技术结构一直在变迁，把握机器学习会应用在 Infra 各个相关的领域，其实就会找到很好的赛道。

怎样赢得资本青睐

找到赛道之后，如何赢得资本青睐呢？这是大家都感兴趣的话题，毕竟一个好汉三个帮，有几个 VC 帮帮忙，创业这件事儿就会变得容易很多。我会讲一下我们的标准。

一是先人一步，在 Infra、在基础架构领域创业，没有一两年基本上是磨不出来好产品的，所以，你创业的话一定要做 1% 看到那个趋势的人。千万不能等到 20%、30% 的人都觉得这是个好方向了你再去做，这样等你把产品做出来的时候，可能 80% 的人都知道了，而且市面上也早就有不错的产品了。

Infra 创业不像 2C，2C 因为有流量优势、错位竞争等各方面因素，是有可能后发先至的。但在 Infra 领域创业是没有捷径的，所以建立优势，最笨最有效的办法就是先人半步。

另外，先人一步才能找到敢吃螃蟹的标杆客户。做 2B 这个生意，产品都是磨出来的，得找一流的、有痛点的客户才能去慢慢打磨出来。那么，只有你是这个行业最先行的人，你才能跟观念和理念最先行的客户碰撞在一起。

七牛的例子就是这样，他们 2012 年左右的开始做云存储，当时大家都觉得这个东西太早了，但后来像美图这些公司在云端存储、图片存储上遇到巨大问题，在市面上看了一圈之后，发现只有七牛能满足他们的需求。借助这样一批早期的一流客户，公司自然就跑起来了。

二是在大市场中去系统性解决问题。技术类创业偶尔会步入一个误区，就是切入的点太小，虽然当前的增速很快，但公司的天花板太低。相信大家创业肯定是想做一个十年二十年、收入几十亿甚至上百亿的大公司，那么天花板这事儿就要比当前的增速重要无数倍。

另外，资本其实是很实际的，他们会看你的技术，投你的科技公司，但本质上，他们投的是一个商业科技公司。科技是一个手段，他们希望看到的是你用非常好的技术手段最终实现了非常不错的商业目标。

所以，如果你考虑在 Infra 或底层架构这方面创业的话，就需要多花一些时间想想天花板的事情，想想你想涉足的行业，在 5 年、10 年之后，能不能诞生一个年收入至少几十亿人民币的公司。

三是一流的相互信任和互补的团队。这边我想举的例子是 GrowingIO，当时我们投他们的时候，团队只有 4 个人，大部分来自 LinkedIn。那首先，LinkedIn 的数据分析团队绝对是世界一流的团队；其次，团队成员之前就共事了大概 4-5 年，彼此非常信任；最后，团队成员间非常互补，有人产品做得很好 ，其人技术做得好、有人在用户体验甚至商业分析方面有非常多的经验，4 个人非常互补，极大的帮助团队获得了资本的青睐。

四是要尽可能深入思考发展路径，举个例子，我们投了一家公司叫才云，应该是国内 Kubernetes 生态里最好的一家创业公司，但在谷歌掌控的开源社区下发展，是很容易碰到限制和天花板的。

因此，后来他们和谷歌一起开源了 Kubeflow，简单来说就是 TensorFlow On Kubernetes。这个产品就是才云能够自己掌控的，而且跟 TensorFlow 和 Kubernetes 两大未来最核心的趋势结合，一下子就把公司的天花板拉高了 10 倍。所以，要尽量多思考发展路径。

Tips

最后，我总结了 5 个 Infra 创业的 Tips 共大家参考。

1. 选择早期标杆用户，而且一定要非常反逻辑地选那些事多钱少麻烦的客户，因为只有这样的客户，才是真正能够帮助你把产品打磨成行业一流的客户。

2. 要抵制项目制诱惑，在早期，项目制就是毒药，你所有的人力开发都会陷进去，而时间窗比收入重要一千倍。一个 Infrastructure 的时间窗也就 2-3 年，如果你在那几年里忙着做项目挣钱，那等你项目完成，创业这事儿也就结束了。所以，要明确只有产品制才有未来。

不过，也并非所有项目都不能做，如果项目里有很多代码、功能是能被公司其他项目、产品复用的，是能标准化的，那它就是积累的资产，是没问题的。

3. 要耐得住寂寞 ，我们最好的 Infra 产品、底层架构产品无不都是憋了 1-2 年， 这是 Infrastructure 的客观规律。

4.Leverage 开源并利用口碑效应，开源是行业内的必然趋势，据我估计，未来 3-5 年，国内每一两年至少会有 2-3 家很不错的开源公司出现。

5. 要想着从科技公司到商业科技公司，这才是公司走的更为长远的必然基础。

本文整理自经纬创投董事总经理熊飞在 GTLC 全球技术领导力峰会上的精彩分享。熊飞于 2011 年加入经纬中国，负责考察、筛选及评估互联网领域的投资机会。加入风险投资行业之前，他曾先后在阿里巴巴、腾讯担任产品经理。

第38讲 | CTO要掌握的产品哲学：理性与人性的权衡

大家好，我是梁宁。今天主要想跟大家分享一组概念词，就是理性和人性，这也是 CTO 想做好产品必须厘清的概念。

合理的部分是理性，不合理的部分是人性

我是在部队家庭长大的，大学又学了计算机，可以说我是在一个高度理性的环境中成长出来的。所以当我走出这个环境，走到江湖里的时候，就觉得到处都是不合理的事情，比方说我提出一个要求，按理说人们应该这样给我反馈，为什么我得到的反馈从来不符合我的预设，包括团队沟通也好、用户反馈也好，都是这样子。

开始的时候，我很被这件事情困扰，后来就慢慢理解了，其实合理的部分是理性，不合理的部分是人性。

在生活中，理性其实只占了很小的部分。那人们为什么会按照理性做事呢？因为外界的巨大压力，只有在压力下，他才会按照理性做事。如果你没有足够的能力给他足够大的压力，其实他是会按照自己的人性做事的。

所以我想明白这点之后，也就不再像以前那样苦恼了。当我的伙伴、我的用户在我面前展现我认为不合理的事情时，他们其实是把人性和天性展现在我面前，从另一个角度来想，其实是给了我一个真正认识和理解这个人的机会。

好产品 =10% 生理体验 +90% 心理体验

那么 CTO 为什么要理清理性和人性的概念呢？因为当我们做产品的时候，我们要洞察用户需求，重视用户体验。但你会发现，我们的体验中可能只有 10% 是生理体验，是人的身体可以真实感受并给出反应的，剩下的 90% 都是心理体验。

如果 CTO 在追求用户体验的时候，无法理解人的心理体验是怎么构成的，那就无法真正的了解用户体验，做出优秀的产品。

以衣服为例，可能两件不同价位的衣服带给人的保暖、舒适等生理体验是差不多的，但它们的差异来自于优越感、文化认同感、自卑感等心理体验的差异，而这些差异的根源是社会氛围、是人们的共识观念。

技术出身的人做产品的时候，特别容易去追求理性，觉得功能达到了，做到了服务器的完美负载匹配，就已经很好啦，但其实只满足了 10% 的生理体验。

那么心理体验中，人最核心的情绪是什么呢？很重要的词是满足，还有一个很关键的词是存在感。对人类来说，除了生物性的生存，其实还有一个社会性的存在感。而存在感包括两个方面，一个是世界观，就是你对你所生存的场域的真实认知和感受；另一个就是从关系中感受自己的存在，看到自己存在的证明，所以有一种慈悲就是给别人存在感。

因此，我们谈管理的时候，为什么非常强调管理者在说话的时候要看着别人的眼睛，因为这意味着你看到了对方的存在，你在关注他，这对他来讲是非常重要的。

围绕着生存和存在感，以满足为中心，会分成两组不同的情绪，一旦不满足，就会产生不爽、担心、着急、紧张、恼火、生气、心神不宁、忧伤、沮丧、难过、烦燥等状态。而一旦被满足，就会出现愉悦、兴奋、喜悦、欣喜、甜蜜、精力充沛、兴高采烈、感激、感动、乐观、自信等状态。

此外，围绕生存和存在感，还有两个词是愤怒和恐惧，这是一体两面的情绪，其中的差异主要来自你对对手的感知。猫划定地盘之后，如果来的是另外一只猫，它就会感到愤怒，而如果来的是只老虎，它就会感到恐惧。再比如说英雄人物和普通人的区别，就在于大多数人感到恐惧的时候，他们感受到的是愤怒。

但因为每个人的所在意的生存场域不一样，所以他需要的满足点和在意的最不能被侵犯的点也是不一样的。

“应该”是角色化的产物

这时候，我们会更愿意用抽象、用“应该怎么怎么样”去推测一些问题，技术出身、偏向理性的 CTO 就更偏好抽象了。但这很容易出现一个问题就是，抽象往往会忽视现实的复杂性，也就是所谓的人性。

我们经常会用应该怎样怎样来预期一件事情，但实际上“应该”是角色化的产物，是压力的产物，你只有在给对方足够大的压力的情况下，他才会在你设定的“应该”里去工作。

举个例子，我原来在联想工作，大家都在以某种方式说话做事配合，如果谁面对压力却退缩，这是一件羞耻的事情，这是由于联想企业文化的系统压力形成的人的行为特性。但当我离开这样的环境，自己走到江湖开一个小公司后，我再给人原来的压力，对方就辞职了。他不会认为退一步是羞耻，因为我根本就没有形成这样的组织势能。

这也是为什么大公司高管出来创业，一开始都很不适应的原因之一，因为人们和他以前的配合方式不一样。

在大公司，公司有足够的组织势能和系统压力，压着每个人都在他设定的角色脚本里去工作，他们呈现的不是他们本身人性的样子。但当你出来创业后，你就是江湖风浪中的一叶小舟，每个人都用他本来的人性面对你。这时候如果你还想着“应该”，那就只是在给自己找挫折而已，不妨 open 地去看人们真实的样子，不要再将他们套到角色化的模子里面。

不满足的状态 + 处境 + 场景 = 需求切入点

因此，CTO 们做产品时首先就要去弄懂人在什么状态下不被满足。我之前在创业马拉松的时候，有个小组说他们的产品解决的是老年人孤独的问题，他们觉得孤独是一个需求。但我不这么认为，我认为孤独只是一种状态，而不是一种需求。从状态到需求之间，还有处境，还有在这个处境里解决这个状态的场景，接着才变成产品对接的点。

以饥饿为例，饥饿也是一种状态而非需求，同时，菜场、超市、便利店、餐馆、盒饭、外卖等诸多产品和服务都是在对接这个状态，所以在状态和产品之间还需要加上用户的处境。

比如说我饿了，但我在减肥，同时经济上还算宽裕，那么基于这样的处境和场景，我可能选择代餐或是低卡饮食，或者在另一个健身房场景下，我的选择可能是冲一杯蛋白粉。所以，从我们洞察到的用户没有被满足的状态，到能提供的产品和服务之间，还存在这对用户处境、所在场景的洞察。

而不满足的状态 + 处境 + 场景就构成了我们常说的需求切入点，也就是痛点、痒点和爽点。

痛点是什么？ 痛点其实是恐惧，恐惧自己的生存资源被侵犯、生命安全无法保障等，举例来说，当今中国，教育是你对生存机会的恐惧，医疗是你对生命安全的恐惧。

痒点是什么？ 痒点其实是对理想化自我的追求。一个女孩为什么买 200 只口红，这就是上面提到的，人的体验 10% 是功能性体验，90% 是心理体验。从功能性上来讲，3、5 只口红已经够用了，但内心的空洞是没有尽头的，也就是心理体验是没有尽头的。这是为什么如今物质已经极大丰富了，但我们依然有机会不断做新产品的原因。

爽点是什么？ 爽点就是一个长期被压抑、不被满足的需求，突然被满足了，就像古话中的人生四大喜：久旱逢甘霖、他乡遇故知、洞房花烛夜、金榜题名时，满足的都是人们的长期期盼。

不过，这些都是 2C 产品的定义，如果是 2B 产品，那么痒点和爽点就没那么重要了，重要的只有一条，那就是抓住老板的恐惧。因为 2B 产品需要系统灌输及系统学习的成本，如果不能抓住老板的恐惧，他们是不可能让组织付出代价、付出时间去贯彻 2B 产品的。

另外，2C 和 2B 产品细分还可以分成 3 类，一种是 C 端产品直接卖给 C，一种是 C 端产品 B 买单，还有一种就是给组织用的。这 3 中产品在用户体验上是有差别的。

以钉钉为例，它就是很典型的 C 端产品 B 买单。对普通用户来说，钉钉其实是很反人性的，用它很不爽，但在钉钉团队看来，他们这个产品是给集体设计的，而集体人格就是反人性的。但在老板看来，钉钉能为他提供确定性，能让他觉得爽，也愿意依赖这个产品，所以他就愿意为此想办法克服 C 端的抱怨，让这个产品得以持续下去。

最后，我想说，我们都是技术出身，从小学的、崇尚的都是理性思维，但今天我们要搭团队、要跟人协作、要为人们提供产品，所以我们需要看到人和人是不同的，我们要接纳他人与我们的不同。他们对一件事情的感受和反应、他们的满足和不满足、他们的愤怒和恐惧和我们不一样，所以需要我们能够真正地完整地看到别人，然后和别人真正地连接。

本文整理自著名产品人梁宁在 GTLC 全球技术领导力峰会上的精彩分享。梁宁是湖畔大学产品模块学术主任，曾任联想、腾讯高管，工作经历横跨 BAT，与京东、美团、小米等企业有长期深度交流。

第39讲 | 从客户价值谈技术创新

你好，我是百姓网 CTO 姜杰，今天想跟你分享的话题是“从客户价值的角度谈技术创新”。

图灵在他的论文中提出了“图灵机”的描述，即“以布尔代数为基础，将逻辑中的任意命题用一种通用的机器来表示和完成，并能按照一定的规则推导出结论”，奠定了现代计算机发展理论的基础。

而在大多数的互联网企业中，技术很多时候承担的角色类似“图灵机”的定位，主要在解决和实现产品和运营提出的相对确定性的需求。那么作为一个技术负责人，除了响应和满足这些“本职工作”外，是否需要思考技术创新呢？ 答案显然是肯定的，那又该如何从技术的角度去规划创新呢？

技术创新要跳出技术本身思考

首先分享一个不成功的例子，前段时间聊了一个候选人，他做了 10 年的中间件，有着非常好的中间件实践经验。在上一家公司，他作为一个架构团队的负责人，发挥了积累多年的功力，做出来的中间件，无论是设计、架构还是性能都有着非常优秀的水平和可取之处，然而他离开公司的原因却是老板并没有对中间件的价值有足够的认可。

表面上可能是他的向上沟通出了问题，没有跟老板沟通好这件事情的真正价值。但深入剖析之后却发现，当时公司的整体技术中，中间件并不是当时公司最需要的技术，公司更需要的是解决像客户端连通率等更迫切的用户侧工程问题。因此，如果制定最初的目标时，仅从自己的优势经验角度出发去思考，往往就会产生比较大的 Gap。

所以，大家在思考技术中长期目标和创新的时候，一定要跳出技术本身的一些惯性思考，把组织业务的发展需要纳入到自己的思考维度中，而且要放在非常重要的地位。在此之上再去思考如何用最合适的技术方案解决可能遇到的问题。

技术创新要围绕客户价值

当技术发展到一定阶段，团队已经能很好地支持当前阶段业务发展的时候，有一天你会突然发现好象有你没你业务都能够顺利地开展，也就是俗称的“业务上没啥技术挑战”时，很多人会觉得技术到了天花板，会开始考虑选择换一个环境，寻找更高速发展的业务和挑战。

但此时往往还有一个更具挑战的选择，就是在当前的环境中去探寻技术本身的突破，思考更长远的技术规划和技术创新，让技术未来成为业务发展的重要引擎。

创新并不意味着一定要做新产品，在产品研发、售前、售后等过程中的效率提升和成本降低也有很多的技术创新可能。

技术创新可以应用在很多方面，往往也意味着非常大的开放性和不确定性，很容易出现为杀鸡而研发一个牛刀的过度目标设计，所以就更加需要找到相对稳固的锚点来进行重要性和优先级评判，那就是从客户中找答案，很明显对养鸡场来讲，牛刀远不是他们最需要的产品，能增强禽类免疫力的鸡饲料才是。

企业的核心是围绕客户价值实现的，而在当今信息和数据智能的时代，企业长期的发展和利润取决于技术在客户价值上做得有多深，技术创新要是能多从客户角度思考，就能让创新决策跟企业的中长远发展保持一致，并且能够保证持续地得到技术发展所需要的资源，构建长期竞争力。

技术团队如何更好地关注客户价值

那么作为技术团队，如何更好的关注客户价值并思考技术规划呢？我们可以从组织文化、研发流程、产品功能这个三个维度着手。

首先，从组织文化的角度来看，在追求技术卓越的同时要将技术对业务和战略产生 Impact 作为重要衡量指标，避免过度设计和炫技。对业务型团队可以推行技术合伙人制，鼓励每个同学都以技术合伙人或业务合伙人为目标，每个团队都能基于业务和客户价值，去思考并制定团队使命，并让团队中的每个人都清楚这个使命，能够自主地为这个目标去思考、去优化。

其次，从研发流程的角度来看，构建可快速交付客户价值的能力也是技术负责人需要思考的重要课题，关键模块服务化、敏捷流程、持续集成、快速部署、自动化测试及线上回归等一切能够提升工程师效率的手段都值得持续地投入；灰度发布和线上自动化的 fail over 处理等高 SLA 保障可以尽可能地降低对线上客户的影响；全链路的数据分析和用户模型则可以提升对客户的理解，为更好的用户体验和客户价值提供必要的决策依据。

最后，从产品功能的角度来看，要鼓励技术能够经常接触用户。如果工程师只坐在办公室里，接收的往往都是来自产品和运营的“二手”需求，而让他们真正有机会去接触客户，直接参与客户需求反馈，往往会发挥出更多的效率创意和技术价值。通过一些机制的设计，比如客户轮岗日等，保证工程师们能够有这样的环境获得客户的一手信息和反馈。基于这些信息再加上对技术本身的理解及技术趋势的思考，往往就能保证技术创新的目标能足够接地气并且足够 Sharp。

技术创新不能憋大招

制定创新目标后，在推进技术规划时很重要的一点就是不要想着憋大招。我看过到不少的项目就是因为一直在“推进”而迟迟没有价值产出而被砍掉。技术价值的释放曲线是一个 S 型，一开始呈现出的价值会比较低，所以大家在做技术规划的时候，千万不要想着去做一个特别完美的技术方案，然后再把它推到实际业务中去。这时，你做出来的所谓“完美方案”，很有可能和实际的场景、需求之间存在比较大的 Gap，实践才是检验设计的唯一标准。

所以，一定要先把技术的最小 MVP 快速地做出来，并且找一些应用场景，快速地根据反馈进行迭代。公司内部的很多技术项目包括一些中后台技术项目，我也都鼓励大家走出去，走到客户及业务技术中去，真正倾听他们的反馈，解决他们的痛点，才能保证技术价值的有效性和持续发展。

小结

之前谈了很多客户价值，但这里的客户并非单单指市场上的客户，很多时候，内部很多团队其实也是彼此的客户。比如说架构团队，他们的目标客户就是各个业务技术团队，所以，技术管理者也需要培养不同的团队产生这样的意识。

有时候，技术同学会觉得跟产品、运营等业务方在合作中有着所谓“不可调和”的冲突与矛盾，而从客户价值出发，更多的是希望技术同学能够跳出技术领域换一种思维方式，它不仅可以帮助你思考技术创新，组织管理也可以从客户价值的角度来进行思考和创新。

另外，管理者本身也可以尝试从客户价值的角度去思考问题，把自己的技术团队和团队成员当成客户，去创造一个自由且有效率的环境，让大家能够更加自主、自驱地去打造优秀的技术引擎。同时让这些优秀的技术人才也能够以客户价值作为技术创新的重要思考维度，避免技术与业务之间可能出现的冲突视角，将这些优秀的技术引擎最大可能地落到技术价值和客户价值上。

本文整理自百姓网 CTO 姜杰在 GTLC 全球技术领导力峰会上的精彩分享。

作者简介

姜杰，现任百姓网 CTO，负责百姓网整体的技术研发管理工作。在加入百姓网之前，他曾先后在腾讯、盛大、百度等公司，带领过数个亿级规模产品的技术团队，在技术架构与研发管理方面有超过十年的丰富经验。

第40讲 | 技术人投身创业公司之前，应当考虑些什么？

你好，我是余晟，一个积攒了许多创业惨痛教训的老程序员。今天想跟你分享的话题是“技术人投身创业公司之前，应当考虑什么？”

创业火热，回想过去十来年的热点，移动互联网、海淘、云计算、微信生态、大数据、人工智能、区块链…… 虽然技术和商业的大潮起起伏伏，但创业的吸引力、关注度却始终保持在高位，而且，这些热潮也大多和技术有密切关系。 “万事俱备，只缺程序员” 虽然更像是一个玩笑话，但这毕竟说明，创业对技术的依赖越来越严重，技术人员的价值也水涨船高。

因此，也有许多技术人员义无反顾地投入了创业的大潮。其中有些人赚得盆满钵满，有些人碰得头破血流，还有些人起起伏伏，似乎也没有比在大公司打工更好。

为什么会这样？除去运气，技术人员在创业之前的考量和准备也非常重要。运气不好，充其量是不成功，认命就好。而准备不充分，即便有好运气也可能错过甚至被坑，这就非常悲剧了。

那么技术人在创业之前要考虑些什么呢？我觉得，技术本身是没有太多值得赘述的，反倒是下面这些“非技术因素”值得认真考虑。

第一，放下技术的骄傲

有许多投身创业的技术人，之前已经做的相当不错了。他们已经在之前的工作中取得了足够多的成绩，所以，也非常有信心能够在创业中继续贡献力量、创造价值、证明自己。但是，许多人往往低估了“惯性”，忘了考虑自己之前的成绩都是在技术而且是在某个专门的领域做出的。如果去做其它领域的事情，他们往往会觉得不适应，觉得没有“物尽其用”，对资源是浪费，对自己是贬低。

但是投身创业，你会发现“技术”的范围其实相当广泛。在你的合作伙伴的理解里，所有和电脑、网络有关的事情，都归“技术”管。而且，创业公司往往不会有那么充分的资源，那么严格的分工，因此，所有和所谓“技术”有关的问题，都只能靠少数技术人员来搞定。如果这时仍然恪守之前的专业分工那一套，很可能会不适应。

我曾经加入一家电商创业公司，通过重整代码和团队，在业务高速发展期解决了业务瓶颈，也得到了创业元老们的认可。但是后来吃饭我才知道，元老们根本不懂具体的技术细节，重整代码、重整团队这样的事情到底有多重要，该什么时候做，他们完全没法判断。但是他们通过一件我完全没想到的小事判断，我是值得信任的。

什么小事？当时仓库的网络总是出问题，每次一出问题就影响发货。因为当时的网管不给力，又没有招聘到合适的人，所以这个问题爆发时，我只能亲自上场。“看到你身为技术的头，不是在上面高调指挥，而是抱着个交换机在仓库里钻来钻去拉网线，我们觉得这人一定能把事情干成”——你看，这就是创业公司的判断依据。

后来我才知道，这并非特例。有位好友的经历成了反例：他技术也做的很好，也加入某个创业公司负责技术，但干了不长时间就退出了，问他为什么，答曰“公司太不正规了，难以适应，连办公室 Wi-Fi 不稳定也总是找我，我是负责组建技术团队的……”。这位朋友技术当然很好，但他离开之后，公司发展得也相当好。

不是每个技术人加入创业公司都要去拉网线、调 Wi-Fi，但是，你要做好足够的心理准备。

第二，加深对人性的认识

创业是九死一生的博弈，能成功的人寥寥无几。所以，成功的企业，都是上天眷顾的幸运儿。不过，别以为你加入的创业公司成功了，你就“一荣俱荣”了。我见过不少成功的创业公司，公司的成功与员工的回报，没有一毛钱关系。

为什么会这样？多半是因为技术人员对人性的认识不够深，没有足够的防范意识。

许多人之所以选择做技术，正是因为“不喜欢、不擅长与人打交道”。他们的思维往往带有计算机的惯性：这个事情就“应当”是这样，那个事情就“应当”是那样。

在计算机的世界里，这样的规则或许存在。但是在商业世界的利益格局里，人性的复杂体现得淋漓尽致，尤其是在“创业成功，价值增长成百上千倍”的考验下，人心会如何变化，实在是没有保障也很难琢磨的事情。最终的利益格局，多半会与简单朴素认定的那些“应当”大相径庭，完全是博弈、较量和妥协的结果。

我有位朋友，在师兄弟的拉拢下加入某创业公司，拼死拼活干了四五年，终于盼来公司大好形势，却发现承诺给自己的股票早已在暗地里大打折扣。更悲催的是，他还不能发作，如果发作，剩下的那部分也拿不到手，只能出去从头再来。

他始终没有想明白的是：当年创始人求自己加入，“拉着我的小手看月亮”的时候，怎么没看出来他其实有那么多花花肠子呢？其实，未必是“当时就有那么多花花肠子”，只是世事难料，人心无常，这位朋友的困惑，未免有“刻舟求剑”的性质。

也不要以为签了白纸黑字的合同就可以高枕无忧，不管公司有没有做成，大家撕破脸皮的例子不胜枚举。所以加入创业公司，一定要加深对人性的理解，虽然你未必能够因此多获得多少利益，但至少可以增加自己利益的保障。

第三，与业务的人打成一片

你在创业之前，经常与公司里哪些人一起吃饭？

据我观察，很多技术人在创业之前，最经常一起吃饭的公司同事，就是技术人员。大家本来工作交集就比较多，相同的工作性质也导致大家的趣味、价值观比较一致，共同语言自然也很多，所以大家也比较愿意交流。

创业公司不一样，创业公司的一大特点是“麻雀虽小，五脏俱全”。加入创业公司，你能直接打交道的同事的数量可能减少了，不太可能有“远在天边”的团队来找你，但接触的业务却可能更多了，也许以前客户的声音要经过重重过滤，变成规范文档才传达到你这，但现在不得不每天都面对枪林弹雨。

打交道的人数变少了，技术人员大多是欢迎这种变化的，毕竟大家都喜欢简单。但接触的业务更多了，顺带的，接触的人也更复杂了，这种变化则让相当多的技术人员不适应，认为合作伙伴“心思不单纯”，抱怨“业务烦耽误自己专心做技术”，“没有流程导致浪费严重”等。

但是我敢说，如果你考察一百家创业公司，起码有九十九家是这种情况。所以，问题不是出在公司身上，这个阶段的公司“就是”这个状态。如果一定要分个对错，那么不对的一定是你，是你没有弄清楚形势，或者说，缺乏足够的业务感知。

所以，与其抱怨合作伙伴心思不单纯，不如去观察他们是怎么搞定各种事情的，慢慢你就会发现，某些事情确实不是心思单纯能搞定的；与其抱怨业务繁杂，不如去了解为何业务这么繁杂，时刻记住“公司要生存”，这些业务到底是自找麻烦，还是不得已而为之；与其抱怨公司没有规范流程，不如去看看大家都在着急处理什么事情，没有制作规范流程，到底是没有意愿，还是没有时间，或是没有资源……

找到这些问题的答案很重要。但身为技术人员，大概很难冲到业务第一线，直接面对客户、面对竞争对手，所以和业务伙伴打成一片就非常重要。只有和大家充分交流，你才能从完整的角度理解公司的这盘生意，从价值链的角度看待自己的工作。最终，你的价值才能够充分体现。

技术人员加入创业公司，遇到的问题通常不是技术问题，难倒他们的也通常不是技术问题。正因为如此，重视非技术问题，在加入之前就考虑清楚，这些再怎么强调也不为过。

第41讲 | 技术人创业前要问自己的六个问题

你好，我是张新波，同盾科技联合创始人兼技术副总裁，今天想跟你分享的话题是“技术人创业前要问自己的六个问题”。

从 2002 年大学毕业到现在这十几年职业生涯，虽然只经历过四家公司，但是有一半时间是在创业过程中，经历过第一次创业惨痛的失败，也体验过目前创业的快速发展小有所成。创业的过程无比精彩，也无比痛苦，它有可能让你功成名就，更有可能让你一败涂地，因此创业前做好深入的思考和充分的准备是十分有必要的。

我的第一段创业经历是在 2005 年，一个朋友拉我到杭州做一个短信移动搜索的创业项目，通过短信来搜索生活类信息，有点像短信版的 58 同城，并且已经和国内非常知名的一家 VC 谈好了第一笔融资。

当时我正好在第一家公司呆满三年准备出去闯一闯，当时虽然智能手机还没有普及，但功能机几乎已经人手一部了。但是，当你离开家或办公室后，如果想要查询出行、美食等相关信息，是非常不方便的，再加上当时准备用自然语言处理的方式来实现对话交互，是一个非常新颖的方式，所以当时觉得这个方向还是有戏的。然而，这次看起来美好的创业，最后却是一败涂地，自己也深陷泥潭浪费了至少两年的时间。

第二段创业经历是在 2013 年底。经历了第一段失败的创业后，我去大公司锻炼了整整 4 年，一直专注在风控领域。当我们 CEO 邀请我一起创业做一家专业的第三方风控公司时，我觉得事靠谱人靠谱值得冒险，但是基于上次的教训，我还是没有当场就答应，慎重地考虑了一周后，才正式答应加入，如今公司已经迈入独角兽行列。

回头再看这两段创业经历，比较相似，创始人都是我非常熟悉的人，都有海外经历有着宽广的视野，对事业有着执着的追求；都是技术出身，公司做的事情也是技术驱动的事情，并且在当时都是非常创新的业务模式；一开始都拿了非常知名的投资机构的钱，有了资本的支持，但同样四年左右的时间，结果却完全不同。

是什么原因导致了这两段创业结果有如此巨大的差距？总结下来，我觉得除了运气之外，在创业前的六个关键问题上的答案差异导致了完全的不同的结果。

第一，做的事情在今后 5 到 10 年，是否是一个大的趋势。 第一次创业时，当时虽然以功能机为主，人们对短信的需求非常强劲，但是智能手机已经开始流行，我自己就买了 MOTO 的一个翻盖智能机，经常用 UC 浏览器看新闻资讯。

然而我自己从来没有想过，或者即使想过也没有深入思考过，短信搜索以后是不是可以做的长久，当时只是想快点开始一段新的工作和生活。可惜当时吴军老师的《浪潮之巅》一书还没有出版，还不知道顺势而为这个道理。

第二次创业做同盾时，当时互联网正处在高速发展中，越来越多地渗透到人们日常生活的方方面面，然而个人信息的保护却并不完善，网络上的各种欺诈非常猖獗，并且可以预见，这种状况会长期存在。但是，国内还没有一家专业的公司以一种全新的模式来服务众多的中小公司，而国外不少可以参考的对象已经做得非常不错，以数据驱动的模式做第三方风控，是个不错的方向。

第二，有没有跟对老板。 我毕业后在第一家公司呆了 3 年，做基于位置服务的车辆监控和报警系统，一开始就是用云服务的模式给众多公司提供服务，并且和河南全省的 110 指挥中心专线连接。当时还创新性地实现了市场上多家 GPS 终端设备的兼容，做成了一个基于位置服务的监控报警服务平台。

即使现在回过头来看，我们老总在这些方面也是有着非凡的前瞻性和很强的资源整合能力，是非常有希望把这个事情做大的，但后来因为他自己的一些格局和性格上的缺陷，导致留不住人才，公司始终原地踏步，后来无奈离开。

之后跟朋友创办第一家公司，我又犯了同样的错误。我这位朋友年龄比我大很多，在美国学习工作 20 年，经历很丰富，人也非常勤奋。他有着非常强的事业心，但是做事比较固执，认准一个方向就会一头扎进去，对外界的变化不是很敏感，以至于在智能手机来临后，依然坚信短信搜索这个方向。再加上在资本运作和商业经营方面的欠缺，导致这段创业非常艰辛，一年就把 VC 投的钱烧光了，我们俩自己借钱维持公司运营，甚至找我们的投资方借过过桥贷款等，然而大势已去又不能卸下包袱轻装上阵，最后基本上只能勉强苟活。

经历这两段惨痛的教训后，再次选择时我首先考虑人的因素。当时杭州的阿里发展势头最猛，我想这家公司能快速发展，老板一定有不凡之处，我应该去这样的企业学习。事实证明，确实如此，我在阿里的几年亲身见证了这家公司的快速成长，马云的胸怀、眼光、魄力等都很少有人比的上，自己也取得了长足的进步。

所以，后来我们 CEO 邀请我一起创业时，之所以我在心底瞬间就做了决定，就是因为我对他非常了解。在一起共事的四年中，我发现了他身上很多其他技术人员不具备的特质，比如对风控的热爱，出色的学习能力，有领袖气质，能吸引和说服人才加入团队，以及从体系外从零打造一个风控体系并推销到各个事业部的销售能力等。再加上他之前也有过成功的创业经历，所有这些因素加起来，让我看到了一个未来企业家的样子，愿意和他一起赌一把。

当然，如果你出来创业准备自己当老大而不甘心当一个合伙人，你也得做好创业伙伴的选择，这几乎是所有成败的关键。

第三，是否有足够多的行业积累。 第一次创业时，我只有三年纯开发的经验，并且是只有十几个人的小公司，去了没多久，公司唯一的开发也离职了，所以所有的东西都是靠自己摸索，没有经过正规的训练，也没有学会如何在一个大的团队中进行协作，以致创业过程中走了很多弯路，也不知道找谁来帮助。当时做短信搜索，既没有搜索经验，也没有自然语言处理的经历，完全凭一股初生牛犊不怕虎的精神在支撑。

第二次创业时，经过阿里四年的锻炼，经验、见识、人脉都有了很大的提升，并且我们做的事情还是风控这个老本行，都有非常丰富的经验，这也是我们能快速推出产品，并且在经历快速增长时，能够不断改进和优化系统，遇到困难也能找到帮忙的老同事或朋友，这是我们能支撑上万家客户每天上亿请求量的主要原因。

第四，是否有足够开放的心态。 技术出身的人，往往会陷入我技术好就是比其他竞争对手牛的虚幻中，实际上，技术上的先进不代表产品上的先进，技术上的成功也不代表商业上的成功，创立和运营一家公司是一个非常复杂的系统工程，技术只是其中一小部分。

第一次创业时，我们老总坚持觉得我们在这个领域的技术是最牛的，没法接受移动互联网带来的变化。第二次创业时，我们 CEO 则迅速把自己变成了一个销售、一个全能战士，自己跑客户谈合作找融资，哪个地方缺人他就补位，包括我自己，虽然还是搞技术，但也接触了很多以前没经历过的东西，不断学习快速成长。这在公司成长的过程中，尤其是早期阶段，帮助我们构建了别人不具备的竞争优势。

第五，是否尊重商业规则。 一起创业的伙伴大多是同学、朋友或同事等比较亲密的关系，既然大家为了一个共同的理想走到一起，想做一件了不起的事情，那就要尊重商业规则，尤其是利益分配上的规则。

可以看到很多公司开始发展的很好，但到后面，创业伙伴却因为利益分配不均而不欢而散甚至反目成仇。所以，一开始，大家就要把这些事情谈清楚，不管事后看来是否合理，只要是双方当时都认可的，就应该遵守，不能因为觉得自己贡献大为啥分的少就不爽闹事，或者看别人现在不值这个价，就想方设法去挤兑甚至坑别人的股份，把团队搞得分崩离析。

第六，是否取得家人的支持。 创业要想取得阶段性的成功，是一个非常漫长的过程，早期一定是拿非常低的薪资，没有太多精力和时间照顾家人，心情也会起起伏伏不太稳定。这时家人是否能够理解和支持，是至关重要的，后院不稳的话，很难有足够的精力和良好的心态迎接创业路上的各种挑战。

以我为例，我第一次创业时还年轻，一无所有，机会成本不大。第二次创业时，虽然有家有口有房贷压力，但是幸运的是家人非常支持，家里的事情几乎不需要我操心，使我可以全身心地投入到工作上。

结语

创业是一件极其有挑战也极其有成就感的一件事情，如果人生当中没有经历过，肯定是一个遗憾。如果你想清楚了，就撸起袖子加油干吧，尽自己最大的努力，准备迎接最坏的打击，永远期待最好的结果。

作者简介

张新波，同盾科技联合创始人 & 技术 VP，TGO 鲲鹏会杭州分会会长。2009 年加入阿里巴巴，成为国际交易风控与反欺诈团队的早期成员。2009 年至 2011 年，全程参与了国际站风控与反欺诈系统的建设，因为绩效突出被晋升为技术专家。后期负责整个 B2B 风控与反欺诈系统并参与集团统一风控平台的建设，对风控与反欺诈领域有深入的研究。

第42讲 | 团队激励之分配好你的奖金

大家好，我是刘译璟，百分点技术副总裁兼首席架构师。今天，我想跟大家分享的是团队激励中关于奖金分配的话题。

团队激励有许多种手段，物质方面我们可以考虑股权、绩效工资、项目奖、年终奖、加薪、提成等等，职业方面可以考虑晋升、表彰、授权、培训、宣传等等，还有其他诸如批评、竞争、对赌等等都可以作为激励手段。

众多激励手段中，奖金无疑是最简单最直接最容易见效的。但想把奖金分配好、发到位乃至收获效果，却是一件很有挑战的事。在这里，我想通过案例剖析的方式，同大家分享如何充分利用好奖金激励。

在正式剖析案例之前，有一些背景信息需要先介绍一下：我从 2016 下半年开始带一条新的业务线，负责政府行业的大数据解决方案和项目落地。团队规模最初大约 10 人，随着业务快速发展，到 2017 年底的时候团队已经发展到了 180 多人，再加上公司其他部门的支持人员，前前后后有近 300 多人参与过这条业务线。

团队构成方面，有 2 位业务总经理，4 位核心总监，30 多个 Leader，其余都是普通员工。那么如何在 2017 年底给大家发年终奖呢？（当然，首先得有奖金可发才行，这个问题需要大家自行解决，不在本次分享的讨论范围之内。）

摆在我面前的第一个问题是，为什么要发奖金，我想通过奖金激励获得什么？我很快有了结论：发奖金是期望团队知道公司乐于分享，业务的成长会给大家带来的收益，并且对业务贡献越大的人获得的收益越多。由此我得出了三个奖金分配的原则：

原则一：根据业务发展情况设置奖金池大小。 业务发展的好则奖金多，发展的不好则有可能完全没有奖金。这个原则比较容易让大家接受，毕竟不会天下掉馅饼，大家只有努力把蛋糕做大才有可能得到更多。也有个别来自基层员工质疑的声音，他们会争辩说“我自己这一块做得好就应该有奖励啊，业务做的好不好我也负不了责。”如何看待和应对这种质疑呢，这里先不展开讨论，大家不妨一起来思考，也欢迎留言讨论。

原则二：根据每个成员在业务中的贡献度统筹分配奖金。 对业务做出越大贡献的人得到的奖金越多，而且我希望贡献度前 30% 的成员可以分配总奖金的 70%！请大家注意，这里的贡献度不是指个人绩效，而是一种对业务的综合影响程度。显然的，团队 Leader 和关键岗位更容易做出大的贡献，在这种机制下他们天然就会分配到更多奖金，再加上 30% 的人获得 70% 的收益，那么这种分配原则公平吗？这也留给大家一起思考。在实际操作中，这是最核心的原则，但也确实是解释成本最高的原则。

原则三：根据每个成员的月薪计算奖金。 每个人的薪酬不一样，这就造成大家对“奖金多少”的理解是不一致的，同样是一万块钱，甲可能觉得匹配自己的努力，但乙就会觉得太少了。为了消除这种不一致，每个人的奖金都会是他月薪的一个倍数。这个原则的解释成本特别低，但在具体操作中会给分配人带来许多工作量。

大家仔细思考可以看出，上述三个原则实际上把个人和团队的利益绑定在了一起，让每个人都切身感受到自己参与到了业务中，业务成长个人才能受益。而这正是我实施奖金激励的初衷。

这些原则是在 2017 年 6 月份定出来的。毫不夸张的说，原则一敲定，就等于成功了一半，剩下就是具体如何操作了。

一项政策要落地，不是领导拍脑袋就说了算的，必须得到团队的理解和认可。所以我要做的第二项工作就是细则制定和宣传。在这个环节中，我首先跟 2 位业务总经理讨论激励目标和原则，进一步明确了以下事项：

第一，业务发展状况由公司来评定，主要考虑收入、客户满意度和项目质量；

第二，成员贡献度的评估精心设计，至少要参考岗位重要度、个人绩效、参与业务的时长这些重要指标；

第三，成员贡献度被分为 S、A+、A、B+、B、C 和 D 七档，对应的奖金是月薪的 6、5、4、3、2、1 和 0 倍。很明显奖金的幅度会拉得比较大，这个系数在最后落实时候被调整成了 6、5、4.5、3.5、2.5、1.5 和 0，稍微平缓了一些；

第四，岗位重要度被分为 ABCD 四档，分别代表某个功能小组，如咨询、产品、技术等小组中的核心、副手、骨干和成员。我的基本策略是，奖金分配时要优先 AB 两档，满足 C 档，照顾 D 档。因为任何一个小组，只要核心和副手在就能运转起来，只要骨干在业务就能发展，普通成员的参与影响的只是业务发展的速度；

第五，个人绩效被划分为 SABCD 五档，分别代表超预期、优秀、良好、合格和不合格。由 30 位 Leader 按照小组成员的日常工作情况来评价，并且进行面谈后确定；

第六，参与业务的时长由 HR 给出，基本上是按照入职到本业务线的时间来计算的；

第七，只要参与过业务的人员，不论他是否归属到本部门都会一视同仁，都会计算他的贡献度，都会有奖金。

在与 2 位业务总经理讨论明晰之后，我进一步征求 4 位核心总监意见，而后在部门聚餐中向 30 位 Leader 介绍这些原则和细则并与大家讨论。最后，在一系列的团建活动和培训中向所有团队成员简介 2017 年度的奖金激励规划。

整个讨论、意见征询和宣传活动贯穿了 2017 年下半年，团队成员大致都明白了我的奖金激励计划和背后理念。某种程度上讲，我认为 2017 年下半年的这一系列活动要远比发奖金本身更重要，因为它是团队形成共识的过程，也是塑造团队文化的过程，更是夯实团队班底的过程。

在这过程中，每个人都有机会表达自己的见解，从而有机会识别出每个人对团队、对工作和对利益的不同理解和诉求，团队就是在这些理解和诉求的激烈碰撞中逐步成熟的。

实际的奖金分配工作是 2018 年 1 月才开始启动的，此时的关键问题是如何合理的评估大家在 2017 年的贡献度？在操作层面，我做了如下工作：

其一，我和 2 位业务总经理为每个成员确定了岗位重要度。这一步是很容易达成共识的，AB 两档主要是 30 位 Leader，C 档是 Leader 们委以重任的架构师、高级咨询顾问、高级工程师和设计师等角色，大多数成员都是 D 档。唯一特殊的情况是，有许多人只是短期支持过本部门工作，贡献度不明显，为此我单独划了一个 E 档出来，给他们一笔固定的感谢金，不参与贡献度的计算；

其二，由 30 位 Leader 给出了每个成员的年度个人绩效。由于 Leader 的业务职能差异和手松收紧程度不一致，不同团队之间个人绩效的差别还是很大的。同样的研发人员，他在小组甲的绩效可能是 A，跑到小组乙可能就是 B，这也说明完全按照绩效发放奖金并不是个好主意；

其三，我从 HR 处获得了每个人参与到本业务线的天数。

收集到以上数据后，我着手设计一个相对公平的贡献度评价模型，这个模型必须站在整个团队的角度评估每一个成员的工作。我的做法大概是这样的：

第一，我和 2 位业务总经理挑选了一些典型员工出来，商定了他们的贡献度档位，作为基准和样本；

第二，基于上面的样本训练了一个 SVM 模型，输入是每个人的岗位重要度、个人绩效和参与业务时长，输出是贡献度档位，训练的过程中会发现样本中也存在基准不一致的问题，那就进行适当的调整，最终经过参数和基准调整使得模型的准确率达到 95% 以上；

第三，将训练出来的模型用到全体成员上，得到每个人的贡献度；

第四，一旦有了每个人的贡献度，就可以估算需要的奖金额度，不过还要跟实际的奖金池去匹配，对每级贡献度的奖金系数进行适当的调整，以免发不出那么多的钱……

这个过程描述起来很简单，但实际上我前前后后用了两周多时间才计算好，中间涉及到许多沟通、数据校正和系数调整的工作，都是很细的活儿。老实说，由于业务线比较新，2017 年在制度建设和数据积累方面条件不足，这部分的工作不算非常细致，例如评价要素不够丰富、个人绩效过于粗糙等等。今年我已经针对这些问题做了制度上的改进，相信 2018 年的年终奖分配会更加合理和精细。

经过上面的工作，我有了一个初步的奖金分配方案，但这还不够，因为还有一些特殊情况需要考虑，例如有些员工得到了客户的高度认可、有些员工即将承担重要岗位需要特别鼓励、有些员工月薪偏高 / 偏低等等等等，以及每个 Leader 对团队成员都会有一些微调。因此，我又做了两件事：

第一，与 2 位业务总经理讨论，对极个别特殊员工进行了贡献度上调整；

第二，对每个小组，利用上面得到的分配方案核算出一个奖金包，给到小组 Leader，由他进行微调，再反馈给我；

第三，汇总上面得到的数据，形成最后的分配方案。

这一阶段的工作又持续了两周。在这一个月时间内，分配方案更新了 12 个版本才算敲定。任何涉及到利益的事都不能大意啊！

分配方案敲定以后，从 2018 年 2 月开始，团队开始逐层沟通每个人的年终奖，总的来说非常顺利，没有出现负面的声音。大家也拿着年终奖开开心心过了大年。

以上就是我进行 2017 年奖金分配的整个过程，期间其实还有许多小插曲，以及公司和业务线的特殊情况，这里就不展开了。通过这个案例剖析，我想大家可以感受到奖金激励不只是最后发钱那么简单，而是一项需要考虑公司文化、业务体系、制度和利益的细致工作。如果做不到位，甚至会带来反效果，还不如不发。

小结一下，奖金激励是团队激励中最直接和有效的手段，但为了更好地发挥奖金激励的效果，管理者需要做到以下几点：

必须想清楚发奖金的目的是什么，按照什么原则发；

要通过一系列的宣传工作让每个人知晓管理者的目的和原则，团队齐心激励才有意义；

需要设计合理的机制，保证奖金的分配是合理的，是可以被团队认可的；

发放奖金时各层管理者一定要进行面对面的沟通，讲清楚规则，让员工理解我为什么拿了这些奖金，以后怎么办才能得到更多。

最后，希望所有的团队管理者都能运用好奖金激励这个手段！

作者简介

刘译璟，百分点信息技术副总裁，TGO 鲲鹏会北京分会会员。负责产品研发工作以及研发团队管理和培训工作。工作后主要关注高并发 Web 应用、分布式存储和计算、机器学习、商业建模和用户画像等技术领域，以及个性化推荐、互联网广告、精准营销和客户管理等应用领域。

第43讲 | 通过积分考核提升技术团队的绩效

你好，我是一维科技 CTO 杨立东，今天我想跟大家分享的话题是“如何通过积分制，更合理有效的考核技术团队。”

技术团队考核一向是个大难题，合理的考核机制加上奖励制度，能极大激发团队成员的热情，提升团队效率，而不合理的考核机制，却往往会造成团队缺乏热情，高手离职、庸人留下的严重后果。今天，我就想跟大家分享一个综合了不同考核方法优点的方法——积分制。

在聊积分制之前，我想先说一下，为什么我认为“任职资格标准”和“OKR”这两种人力资源方法并不适合作为技术团队的考核方法。

1. 任职资格标准——技术人员的晋升通道

很多公司已经实施了任职资格标准，通过任职资格标准给技术员工进行评级，让技术人员在公司内有明确的晋升通道，解决的是员工持续发展的问题。而技术管理者可以根据不同的级别设置不同的薪资范围，一旦员工通过评估达到了相应的级别，就应该主动给这个员工加薪到这个级别的薪酬范围。这样员工才能有动力持续不断的努力达到更高的级别。

但是，任职资格标准更像一个门派武功或者修真秘籍，用于长时间的筛选这个门派的核心骨干，在更高层面上，通过不断招募新人和让每一个人在这个标准下不断的晋级两种方式来保持技术团队的搭配合理性。

因此，虽然这种方法对员工有一定的激励作用，但却不足以用来刺激员工或团队提升效率。因为每人起点不一样，有的员工想半年晋一级，有的员工觉得两年晋一级就不错呢。

2.OKR——聚焦员工和团队的工具

技术团队的工作大多是多目标的，特别是如果你服务的对象是企业客户或产品经理，他们会毫无节操的给你们团队设定目标。这些无聊的需求和目标足以让技术团队抓狂，但如果实施了 OKR，将会缓解掉这些矛盾。

我们可以给团队设定相对单一的目标（O），可以是进度，也可以是这期迭代要完成的功能和产品特性。而在这个目标下最多分解不超过 3 个关键结果（KR）。对于团队中的个人也是一样，设定与团队相一致的目标和关键结果，这样才能让团队聚焦到最重要的工作中去。

那为什么 OKR 不适合做考核呢？因为在实际操作中，有人喜欢挑战，KR 设得高却可能得不到高分，有人保守，KR 设的很低，不需要努力都能达到。如果把 OKR 作为考核工具，必然结果是每个人都去设定没有挑战的目标，这非常不利于团队的激励，也偏离了 OKR 管理的初衷。

既然任职资格和 OKR 都不适合做考核工具，什么才是适合团队的考核方法呢。我们都耳熟能详的绩效考核方法包括：360 度考核法，BSC 平衡记分卡，KPI 法等等。我们不去评价哪种方法的好坏，因为不同的组织和公司文化适用不同的方法。下面我想跟大家介绍的这种方法是综合了不同考核方法的结果，积分制。

首先来看项目积分的设定

积分制适合于项目型组织，在这个组织里，一切都可以转化为不同类型的项目。管理层首先要对项目进行重要性排序或者打分。根据项目的规模，这个活动可以每个季度执行一次，也可以每个月执行一次。与此同时管理层还需要给每个项目设定 1-3 个量化的目标，为目标设定卓越线和及格线。

如果一个项目目标都达到卓越，那么最终每个成员的项目得分都是满分。例如，参与“盘古”项目的成员，项目上线后 1 个月内统计数据显示产品 7 日留存率提升到了 39.7%，崩溃率降到了 0.19%，那么所有参与该项目的成员都能拿到项目分的满分 5 分。

接着来看个人积分的评定

项目得分如果参考量化标准，是比较容易打分的，但个人打分是一件十分困难的事情。作为技术管理者，这个时候就到了体现你智慧的时刻，你可以把打分的权利完全授权给团队，让他们根据对目标的贡献度互相进行打分。你可以给定一个总分数和两条打分原则：1. 不能均分；2. 按照每人对目标的贡献度进行打分。

总分的范围为团队人数×项目系数，而项目系数从 1-5，越早上线的项目系数越大，从而激励团队尽早完成项目和上线使用。如果项目周期 3 个月，系数可以如下表。其他项目的系数根据项目周期可以类比。

还是以“盘古”项目为例，项目提前 2 周上线，那么项目系数为 4，同时项目人数 10 人，那么我们可以设定团队的总分为 10×4=40 分，这 40 分分给团队让团队进行自己打分，个人最多 5 分，最少 1 分。这个打分过程由于不能平均，每个人又都按对目标的贡献进行打分，所以会相对公平一些。如果你在这个项目中得到了 5 分，那么你在这个项目的期间段个人积分就是项目分×个人分，也就是 5×5=25 分；如果你的得分只有 3，那么你该项目的个人积分就只有 3×5=15 分。这个方法将会大大拉开不同成员之间的差距，起到更好的激励效果。

积分季度排名和年底排名

不同的公司可以按照以上的规则进行季度排名和年底最终排名，根据自身的经营情况可以按季度发放奖金，也可以年底统一发放。出于诸多因素的考虑，我还是建议全年排名和计算发放。那么问题来了，不同的积分该发多少奖金呢？

首先，年初管理层应该根据预测的业绩设置一个奖金包，这个奖金包就是发放的基础。奖金包是否独立于年底双薪取决于你们的招聘制度，如果公司不愁招人，完全可以忽略双薪，直接定奖金包。如果招聘环节招人就困难，那么奖金包应该区分于年底双薪而独立设定。既然是奖金包，最少也要有技术团队 2 倍工资作为起点才有意义，如果太少，什么考核方法也起不到激励作用。

其次，奖金倍数的计算是根据员工积分进行的，积分的导向就是尽量拉开差距，不搞平均主义。可以设定积分排名前 20% 的人按 4-8 倍系数发放奖金，后 20% 的人不发奖金，中间 60% 的人能拿到 1-2 倍系数奖金。在这种体制下，如果你月薪 20000，排名第一，就可以拿到 20000×8=160000 年终奖金。

需要注意的是，中层经理不参与积分，如果要考核中层，可以参考 360 度考核法。

最后，需要在试用第 1 年后汇总员工的建议，并根据反馈将以上的考核方案形成制度，然后通过人力资源部和 CTO 两个渠道下发给员工。我们不难发现，积分考核综合了 KPI 和 OKR，鼓励做有价值的项目，鼓励在项目中有卓越的和目标相关的表现，同时还导向项目及早上线。

最后来说一下实施积分制的阻碍

技术团队考核是行业难题，所以不管实施什么考核方案都是困难重重，阻碍多多。项目的分数评定是需要所有相关的高管共同参与的，即使出来一些没有规划的临时项目，也需要高管们及时给一个项目分数。

同时员工也不愿意去做那些低分项目，比如：运维，行政，市场等，因为这些项目很难出成绩。对此，需要直接主管配合员工设定合理的量化目标，确保即使项目不容易拿高分，也能让个人在项目表现中拿到高分。

另外，互联网公司项目的量化目标相对好设定和检验，可以通过第三方数据公司获取相对客观的数据。而对于面向行业进行项目交付的公司，项目的分值大同小异，因为你不太容易界定那个客户重要，哪个客户不重要。

因此，在这种类型的公司里，个人积分排名不容易拉开，就失去了实施积分制的意义。所以追本溯源，还是要通过项目毛利、项目回款等因素对项目进行不同分值的划分，通过项目预算节约、进度和上线后售后投入等因素对项目给予不同的项目系数。

小结

作为技术管理者或者 CTO，团队效率的提升是首要考虑的事情，当你还是一个小团队时，可以撸起袖子加油干，而随着团队的扩大，就需要建立适当的规则再用公司情怀来激励。团队再大一些，再讲情怀已经没用了，务实一些就需要建立合适的考核制度。

积分制在项目层面综合了 OKR 的目标管理的精髓，让团队关注对公司最有价值的项目，同时在个人考核上又遵循了 KPI 的方式，只不过把 KPI 的权利下放给团队进行互评，这样更能激励那些自身努力而又关注目标的员工。

第44讲 | 空降技术高管的“择业七计”

你好，我是黄勇，今天想跟大家分享的话题是“空降技术高管的‘择业七计’”。

2015 年，我离开阿里，空降到一家创业公司做 CTO，原本以为自己可以轻松驾驭这个岗位，没想到刚加入公司，我就面临了职场中最大的三个挑战。

挑战一：我的空降打破团队平衡，受到团队的质疑和排挤

我第一天来到公司，有位同事就找我私聊，突然问我：“你会把我们现有技术团队都开掉吗？”这句话如同晴天霹雳，让我猝不及防，我根本没有想到他会问我这样的问题。还好我脑筋转得快，镇定地反问他一句：“你为什么会这么问？”，此时我的大脑在飞速地运转，思考接下来应该如何回答这个尖锐的问题。

他很直接的说：“你是搞 Java 的，我们是搞 PHP 的，你以后肯定会招 Java 的人来取代我们”。我对他说：“我只会开掉长时间都做不出成绩的人”。这句话言简意赅，他瞬间找到了答案，认识了我的态度，我也顺利地化解了这次挑战。

但挑战并不总能迎刃而解，面对一个新的地盘，我很需要有自己的人，这样我才能更快地做出成绩。

我邀请了几位以前合作过的同事加入公司，我不再是一名空降兵，我们形成了空降部队。我的初衷是想用自己熟悉的人来提高工作效率，没想到却带来了“抱团”现象，技术团队变成了新老两个团队，我是“新人队”队长。老人队不约我们新人队吃饭，甚至也不主动找我们讲话，我约老人队一起吃饭，吃饭时大家各玩各的手机，一句话也不说，场面十分尴尬。我毕竟是 CTO，我深知自己不能搞团队分离，但我当时面临这样的挑战，却显得束手无策。

除了缺乏同事的信任以外，我还面临着第二个挑战。

挑战二：产品系统架构非常脆弱，现在是否应该推倒重来

当时公司产品虽然已经上线，产品质量却出现了非常严重的问题，其他部门领导吐槽声不断，每次管理层周会上，我都是他们“批斗”的对象。原来最近半年里，公司已经换掉了两批技术团队，前面已经走了两位 CTO，我是第三任。原本以为是蝙蝠侠，没想到却是背锅侠。

当我看到用户注册都有 Bug 时，我才感受到自己这次接手了一个“烂摊子”。反之，我看到了这也是一个绝好的机会，如果我能将产品质量提升，那么这个 CTO 的位置我才能坐得长久。

当时整个系统是一个单体架构，不管是上线一个新功能，还是修补一个 Bug，都要手工部署，效率极低，而且每次上线时间都要放在深夜里，上线前还需要发布一条网站升级公告。我之前在阿里研究过微服务架构，也实践过 Docker 容器化技术，站在技术人员的视角上，我很想在团队中实践微服务架构，但又担心研发成本太高，如果失败了，我的结局也会和两位前任一样，更严重的是，这家创业公司会断送在我的手里。

我最终放弃了这个美好的想法，开始脚踏实地修改每个 Bug。我将关注点转移到了研发流程上，开始亲自带领团队，采用敏捷方法进行产品研发，短期内让团队的节奏有了改善。

当我花了一个月的时间，熟悉了现在的团队后，紧接着就遇到了第三个挑战。

挑战三：公司只能发四个月工资，产品出不来公司就关门

记得有一天，我和老板一起吃饭，他告诉我：“天使轮的钱不多了，只够发四个月工资，商业模式还没得到验证，产品功能还没开发完毕，很可能公司就要走不下去了……”。没等老板把话说完，我就告诉他：“用不了四个月，给我三个月就够了，我让产品闭环，你可以拿着产品去跟投资人讲故事了”。

背水一战，没有任何退路。我带领团队，疯狂地工作，每天早出晚归。那时我女儿才两岁，活泼可爱，但我几乎没有亲眼看到女儿醒着的时候。我下班到家时，她已经睡着了，我去上班时，她还没醒来。在深夜里，我只能摸摸她柔软的小手，看看她睡着时的可爱模样。

我们的努力是值得的，只用了两个半月的时间，团队完成了所有的产品新功能，修复了所有的 Bug，新产品重新上线，老板给产品取了一个代号，叫做 Raffael（拉斐尔）。这是一个人名，拉斐尔是意大利著名画家，也是“文艺复兴三杰”中最年轻的一位，代表了文艺复兴时期艺术家从事理想美的事业所能达到的巅峰。也许这正是老板内心对产品的寄托，或许也是他对自己的勉励。

在 2015 年春节前，公司顺利地拿到了红杉资本的 A 轮融资，我们用这笔钱度过了之后的两年。公司的业务有了明显增长，产品也添加了更多的功能，团队规模也逐渐壮大起来，我也逐渐找到了做一名 CTO 的感觉。

谈谈技术人员的择业问题

作为一名技术人员，不管是程序员还是 CTO，在面临跳槽时，我们该如何选择呢？是否存在科学的判断方法，避免我们跳槽不慎变“跳坑”呢？

其实早在两千多年前的春秋时期，孙武就提出过这样的观点：

故校之以计，而索其情。曰：主孰有道？将孰有能？天地孰得？法令孰行？兵众孰强？士卒孰练？赏罚孰明？吾以此知胜负矣。（节选自《孙子兵法》始计篇“七计”）

我尝试将孙武的文言文翻译为以下白话文：

所以，可以通过比较双方的具体条件来探究战争的最终胜负，即哪一方君主更得民心？哪一方将帅更有才能？哪一方更得天时地利？哪一方军纪更为严明？哪一方兵力更加强大？哪一方士卒更加训练有素？哪一方赏罚更加公正严明？我通过这些就能够料知谁胜谁负了。

尤其对于 CTO 这类技术高管而言，看似在公司级别很高，但跳槽风险也巨大。空降之前，不妨用孙武这“七计”加以判断，我将其诠释为“择业七计”。当我们在对比未来要去的公司，不知道该去哪一家时，不妨一试。

主孰有道？→ 哪家老板更有战略？

将孰有能？→ 哪家领导更有才能？

天地孰得？→ 哪家项目更合时机？

法令孰行？→ 哪家制度更加合理？

兵众孰强？→ 哪家规模更加强大？

士卒孰练？→ 哪家员工更加精炼？

赏罚孰明？→ 哪家薪资更吸引人？

第一步，比较老板，他的方向是否明确？眼光是否长远？性格是否喜欢？这些问题其实都能在面试的时候找到答案，我们更多的是抛出一些问题，看他的回答是否让自己满意。他在了解你，你也在了解他，两人就像谈恋爱一样，他将是你比面对自己老婆的时间还要多的人，合作前花再多时间聊都不嫌多。

第二步，比较公司各个职能部门的领导，尤其是将来和自己密切共事的几位领导，如果有可能的话，最好在面试的时候要求和他们当面聊聊，通过交谈可初步判断出他们的才能。能够胜任 CTO 这个岗位，我们必须培养自己与非技术同事交流与合作的能力。

第三步，判断公司做的项目是否赢得市场？是否适应当前时机？第四步，比较公司的管理制度与企业文化，判断一下自己是否能接受。第五步，比较公司的市场份额与人员规模。第六步，比较员工的基本素质。第七步，比较薪资待遇。

如果你打算做空降 CTO，以上七个步骤，千万不要搞颠倒。

写在最后

我对担任空降技术高管的经验，归纳为以下 4 点：

空降兵要为人亲和；

谨慎引入空降部队；

快速培养左膀右臂；

全力以赴完成目标。

我对空降技术高管的团队管理思路，归纳为以下 6 个步骤：

学习公司业务；

理解企业文化；

调整研发流程；

优化技术架构；

建设团队文化；

让管理自动化。

我的团队管理秘诀是：

开心 → 交心 → 关心 → 同心

先让团队玩在一起，开心工作，时常和大家交心，问问大家工作上需要哪些帮助，关心身边每一位同事，团队才会与自己同心。

如果说“钱、事、人”三者，我们需要根据优先级排一个顺序的话，我认为一定是：人、事、钱。人对了，才能把事做好，才能赚更多的钱。

作者简介

黄勇，TGO 鲲鹏会上海分会会员，畅销书《架构探险》作者，开源软件作者，拥有十年以上互联网软件从业经验，擅长系统架构与技术管理。喜欢阅读，热爱交流，乐于分享。

第45讲 | 选好人生下一站——CTO空降上篇

你好，我是易建科技技术副总裁钟忻，今天我想跟大家分享的是关于 CTO 空降的话题，本篇文章是上篇，探讨如何做好空降前的准备。

对于 CTO（技术总监）来说，他们已经成为公司或部门技术的最高负责人，实现了人生一个小目标，成为众多技术人崇拜的对象。那么 CTO 的下一站又在哪里？当自身发展遇到瓶颈，决定再次起飞时，选择合适的着陆地点也许就决定了是否能够抢滩成功。

与自己对话——下一站在哪里？

关于这个问题，我跟圈子内许多 CTO 朋友聊过，也看过一些行业专家的文章，其实这本质上是一个个人成长的问题，我想无非分为如下几类：

1. 寻求更广阔的空间

当 CTO 所在的公司业务增长放缓，团队趋于稳定，没有太多技术上的挑战出现时，因为技术出身的高管通常对自己都有着更高的要求，有颗不安分的心，所以，如果这时候有个成长型的公司抛出橄榄枝，提供更大的想象空间和可以另起炉灶、大展拳脚的机会，这对他们来说有着致命的诱惑力。

新的公司或者有新的技术方向可以去追逐，或者是一个新兴的行业有着广阔的商业前景，能够带来更大的成就感，这些都是成熟型公司的 CTO 看中的。

2. 转型不同的角色

另外我也看到周围有一些综合能力比较强的 CTO，作为高管或者合伙人，本身在公司就承担了技术以外更多的业务的职责，希望慢慢转型成为 CEO 或者一个子业务的 GM，这个时候，这种类型的工作机会对他们而言也是很有吸引力的。

正所谓“不想当 CEO 的 CTO 不是好厨子”，未来科技对于行业的影响会越来越大，会有越来越多技术出身的 CEO 出现，这样的综合性人才是市场上非常欢迎的。如果能兼具技术背景和业务能力于一身，也是 CTO 未来可以考虑的一条不错的发展路径。

空降前的“功课”——如何选好下家？

当技术高管做出决定迈出下一步，或者有人抛出橄榄枝时，如何选下家就变成一个非常重要的问题。因为高管更换工作的风险远远大于普通的工程师，这一步必须慎之又慎。由于没有提前做好功课，我周围有些 CTO 从稳定的大平台出来之后，一年换一次工作，甚至更高的频率都是有的。

因此，在想要施展一番抱负的冲动之下，理性的权衡还是非常必要的。我总结有以下几个重要的因素需要在空降前考虑：

首先是企业诉求，需要考虑对方对 CTO 的诉求，按照个人理解的风险由小到大排列，无非是以下几种：

1. 拉升逼格

该公司业务和团队都已经比较稳定了，但是需要更加体系化的管理和创新，想要吸引更多人才，提升技术实力等等。比如 C 轮以后的公司需要上市，原有的技术合伙人执行力可能足够，但是视野格局、宏观把控、人脉名气等诸多方面欠缺且无法迅速提高，因此需要一个能力全面经验丰富的 CTO 坐镇。这种在对企业进行比较仔细的考量后，我认为是风险比较低的一种很好的选择。

2. 救火队员

该公司的业务模式已经确定，也有一个基本的团队框架，但是原有团队的技术能力已经不足以应付业务的需求，疲于奔命。甚至产品的稳定性等各方面都存在很大问题，有诸多技术挑战亟待解决。这个时候，他们需要的是一个技术能力过硬，同时能够很好的进行团队沟通协调，迅速灭火，稳定局面，把业务带入正轨的 CTO。跟上一种情况属于锦上添花相比，这种情况就属于雪中送炭了。但同样，因为企业的诉求比较明确，只要是方向对口，自身实力过硬，我觉得也是比较好的选择。

3. 互联网“焦虑”

该公司有着成熟的业务和稳定的营收，但在互联网催生的一波波技术大潮冲击之下，公司高层要么是想未雨绸缪，要么是看到互联网巨头正在逐步渗透到自己的领地，产生了危机感，加上公司本身对人才的吸引力也不够，技术团队老化严重，于是产生了从外部招聘技术高管，吸纳新鲜血液，尝试业务创新的念头。这种情况，由于公司原有的结构比较固化，新业务一般也不清晰，对于 CTO 来说，有着比较大的风险，需要慎重对待。

其次是企业文化，在搞清楚企业诉求之后，如果觉得宏观层面风险不大，那就要考虑微观层面的适应性问题了，主要可以从以下几个方面着手：

1. 业务状况

公司所处的行业，是否具有一定的行业壁垒，还是很容易被复制。目前的收入、利润、现金流是否稳定，资金是否充足，这决定了公司能够给 CTO 多大的时间窗口来施展才华。

2. 管理模式

公司是什么样的组织架构和文化，公司的工作氛围如何。CTO 在公司组织架构中处于什么样的地位，能够掌握多大的资源和话语权，这决定了 CTO 到岗以后能够发挥多大作用。

3. 人员状况

现有技术团队的状况，是否短期通过简单的调整就可以胜任，还是需要大幅度引入外部人才。如果是后面的情况，那 CTO 在加入之前就要做好相应的准备，通过迅速招人来扭转局面。

最后是渠道问题，是通过猎头还是熟人推荐。

对于求职来说，猎头是绕不开的话题，但我想说，对于技术高管，选择猎头的风险是非常大的。如果 CTO 本身有足够大的名气和人脉，能够获得非常理想的工作机会，这是最佳的选择。因为通过人脉去了解到的企业的信息是比较准确的，另外跟对方的高层有一定的熟悉程度，也大大降低了加入以后磨合的风险。

那么猎头推荐的机会到底看不看呢？其实，我觉得通过猎头是一个比较好的了解外部市场的机会，不必太排斥。比如我在上一家公司的时候，很多大企业需要云或者大数据背景的机会都会找到我这边，接触一下，多了解一下外部的信息我觉得没什么不好。

但是反过来说，单纯听猎头的一面之词，以及通过几次面试跟企业的简单接触，就决定加入，对 CTO 来说是不可取的。因为面试的时候，大家展现的都是最好的一面，也许入职不久就会发现很多之前完全预想不到的情况。

所以，最好的做法就是在了解到机会之后，通过自己的人脉找到内部员工了解真实的情况。如果没有特别靠谱的信息渠道，那么不妨等等再做决定。

临渊羡鱼，还是退而结网

作为 CTO，大家都知道，行业是有周期的，所以看机会的时机也是很重要的。从 2016 年开始，我明显感觉互联网创业的机会越来越少了，而 AI 的机会多起来了。毕竟对于 CTO 来说，更换工作的风险和成本都是很高的，因此，我个人觉得在行业高峰期，可以适当激进一些，因为这个时候机会比较多，即使失败，找个下家也是容易的。但如果在低潮到来的时候选择冒险，那么一旦失败，可选择的余地就会小很多。这个时候不妨慎重一些，在稳定的平台里面再多修炼一下也未尝不好。

最后，小诗一首，送给大家。明天的 CTO 空降下篇更精彩，请多点赞：

烽火照西京，心中自不平。牙璋辞凤阙，铁骑绕龙城。雪暗凋旗画，风多杂鼓声。宁为百夫长，胜作一书生。

作者简介

钟忻，易建科技技术副总裁兼云服务事业群总经理，TGO 鲲鹏会北京分会会员。2003 年清华大学自动化硕士毕业。曾在 Turbolinux、IBM、Intel 等多家 IT 公司担任资深软件工程师。13 年底到 16 年初担任乐视云平台高级总监，主导了乐视 IaaS、PaaS 平台从无到有的全过程。目前负责易建科技上千人研发团队的技术体系的搭建，以及整个海航集团的 IDC 和基础云平台的产品研发、运营和市场开拓。

第46讲 | 走出“至暗时刻”——CTO空降下篇

你好，我是易建科技技术副总裁钟忻，昨天跟大家分享了 CTO 空降前该如何做好准备，今天接着上一篇，探讨当 CTO 迈出了职业生涯关键的一步，空降到新的平台之后，该如何一步步开展工作，迅速发挥作用，得到公司上下的认可呢？我想无非是从做事和做人两方面来看。

做事

首先说说做事，CTO 可能需要经历如下三个阶段，才能到达比较理想的状态。

1. 蜜月期——提理念，找突破

一般 CTO 愿意接受新的工作机会，双方肯定都是比较认可的，而且无论是公司管理层还是 CTO 本人都是见过大风大浪、比较理性的，所以我认为蜜月期一般来说都不会有太大问题。

蜜月期，公司管理层一般都会要求 CTO 对产品团队等做系统的梳理和规划，提出新的想法和见解。而对于经验丰富的 CTO 来说，通过迅速深入一线沟通了解情况，并凭借之前的经验和良好的技术视野，在短期内拿出一份系统性和实操性都比较强的方案，并得到管理层的认可，一般都不是太大问题。加上双方刚刚接触，展现的更多的还是好的一面，对对方也都会比较宽容，因此，蜜月期通常都能很好的渡过。

另外，CTO 入职本身就是一个比较高调的事情，新来的技术高管无疑会吸引很多的目光，所以保持低调，少说多做，反倒是比较理想的选择。在面上取得系统性的突破肯定不是一日之功，但是在一些点上迅速发现问题做出亮点还是很有可能的。比如迅速引入或者落地一些工具和方法，改进一些流程和制度，提升团队士气；或者聚焦在一些系统的稳定性问题上，迅速攻克技术难点，扭转技术团队的被动局面。对于技术功底扎实、经验老道的 CTO 来说，这些都不是太大的问题。

2. 考验期——苦干实干，牢底坐穿

我有几位师兄弟，之前都担任过行业领头羊或是上市公司的 CTO 或者技术 VP，大家在讨论空降这个话题的时候，都比较认同第二个阶段对 CTO 是比较严峻的考验。我相信大部分技术高管，无论是客观还是主观的原因，没能顺利空降，问题也都是爆发在这个阶段。

其中一位有一句名言：“我所见过的技术高管，蜜月期以后还能活下来的，都是搞过封闭开发的”。无论这句话有多少主观成分，还是充分体现了 CTO 这个职位面临的压力和挑战。有的是在工作深入开展以后，发现跟公司管理层在管理理念、做事风格等多方面存在很大差异。有的是在取得一些工作进展后，让老板的期望值越来越高，承担的工作也越来越多，到达一个瓶颈以后，很容易出现顾此失彼、捉襟见肘的局面。

我本人从技术总监到技术高管，一个很深的体会就是，虽然都是独当一面的技术负责人，但总监跟 CTO 有一个本质的不同。总监的上司往往还是技术口的，而 CTO 的上司显然是业务口，很有可能完全不懂技术，所以沟通的成本和获得认可的难度无疑是几何级数的差别。

那么对于 CTO 来说，在这种局面下，出色的抗压能力无疑是必须的。在跟公司管理层无法很好的达成一致的情况下，我认为还是尽量求同存异，不要有太多其他想法，毕竟老板在业务方面的理解和行业经验的积累上，一般来说还是远强于 CTO 本人的，先按照他的想法来执行，再通过实践来检验成果。

另外在被动的局面下，超出预期无疑是非常困难的，但我认为这也是不容逃避的。一方面要顶住压力，另一方面要在老板不重视的方向和事情上，迅速做出成绩，超出预期，这无疑是走出困境的最佳选择。

当然每个人的能力和精力都是有限的，事情太多铁打的金刚也扛不住。在适当的情况下，也可以学着 say no。把精力聚焦在重要的事情上，抓大放小。这样虽然在一定时期会遭到一些质疑，但在长期看无疑是明智的，最终理性的老板还是会认可和接纳的。

总的来说，所谓“封闭开发”这样的做法不一定是必须的，但是拿出态度来，打破自己之前的认知局限，真心实意的苦干实干，熬过“黑暗时刻”，光明总会到来。最终或多或少都会有一些突破和成果，公司的管理层也肯定能够看到 CTO 和团队的努力付出的。

3. 稳定期——全情投入，放眼未来

熬过考验期，进入第三个阶段，无疑是值得高兴的。这说明 CTO 跟公司管理层有了充分的了解，适应了公司的文化，能力也得到了认可，可以更多的按照自己的想法来大展拳脚。往往这个时候，团队也比较成型了，沟通也更顺畅了，所以有时候会有些放松和麻痹大意。

这个时候，作为 CTO，应该有居安思危的想法。自己原有的思维格局和体系，可能很难突破了，因此，一方面要多关注团队成员能力的提升，给他们更多的指导；另外一方面则可以把眼光投向外部，多借鉴同行的先进经验，在框架性体系化上面打打基础，为迎接新的挑战做好准备。

做人

说完做事，再来说说做人，CTO 本身就是一个重要的管理岗，跟方方面面都要打交道，因此，能得到各方的接纳对开展工作也是非常关键的。主要分为对上、对中和对下三方面：

1. 老板——如何做好向上管理

取得老板的认可接纳，得到充分的授权，这是 CTO 做好工作的先决条件，这个道理大家应该都是非常明白的。在初来乍到的情况下，一定要密切的跟老板沟通，加快磨合的速度，搞清楚老板的真实想法。在上面的段落里也提到了，尽量求同存异，按照老板的想法执行，并且力求超出预期。

2. 同事——团结一切可以团结的力量

跟平级的同事打交道，获得他们的支持也是很重要的，比如市场营销团队、财务人力等职能部门。CTO 在这个时候更需要的是领导力、沟通能力，而不是管理能力。

在具体操作中，我认为掌握两个要素比较关键。一个是取得共识，只要大家利益一致，对公司全局有好处，大家就能够达成一致，这样就好合作。另外一个是互惠互利，相互帮助。多换位思考，看看对方的难处是什么，在边界比较模糊的时候，尽量多做一点，毕竟你的最终的目标还是为了结果的达成，这个才是最重要的。

3. 下属——如何让下属信服

空降还有一个蛮有意思的地方，就是怎么获得下属的支持。让大家忘记“前任”，迅速的接纳你，这样你的想法才能落地执行，这也是 CTO 工作的根本所在。作为 CTO，在技术能力、经验和视野上肯定是远强于自己下属的，让他们在技术上信服一般不是难事。但怎么让原本不认识你的一大群人一下子能很好的执行你的想法，还是需要下功夫的。

我自己总结下属有三种类型。一种是听话型，这类下属本身人就比较 nice，跟谁都能很好的配合，在工作中也能够很快感觉到他对工作的热情和执行力，那么迅速委以重任就可以了。

第二种是合作型，他们不会像第一类那么自来熟，但他们会比较有想法，也有能力。这类下属从管理者的角度，跟他充分的沟通，给他施展的空间，让他感受到你对他的支持和认可，那么也是比较好合作的。

第三种就有点让人头疼了，权且叫反动型吧。由于种种原因，不配合你的工作，甚至原来在团队就是刺头。这种一般来说还是先尝试按第二种情况来处理，如果确实有能力也能够合作，那不妨多包容。但在某些情况下，为了维护权威性，在得到管理层的充分授权后，也可以考虑采取极端措施。

在这里我分享一个有意思的事情，我之前有一名下属，脾气比较火爆，个性也有点封闭，做事风格跟我平常倡导的也完全不同，但是执行力非常强，因为一些历史原因和观念的差异，空降之后双方合作一直磕磕绊绊，好在工作也能往前开展。

直到我离开公司后，有一次特别意外，他突然给我发微信对我表示感谢，我还挺感动的。因为我在管理上，一直提倡要成就别人来成就自己，也给过他不少帮助，他在时过境迁之后自己也意识到了这一点。CTO 作为管理者，应该坚持做对的事情，时间会证明一切。

到此为止，CTO 空降的上下篇就要划上句号了，文章结尾把电影“至暗时刻”中丘吉尔的名言送给诸位：Success is not final, failure is not fatal, it is the courage to continue that counts。恰逢技术盛世，唯自信与勇气不可辜负，加油吧，少年们。

作者简介

钟忻，易建科技技术副总裁兼云服务事业群总经理，TGO 鲲鹏会北京分会会员。2003 年清华大学自动化硕士毕业。曾在 Turbolinux、IBM、Intel 等多家 IT 公司担任资深软件工程师。13 年底到 16 年初担任乐视云平台高级总监，主导了乐视 IaaS、PaaS 平台从无到有的全过程。目前负责易建科技上千人研发团队的技术体系的搭建，以及整个海航集团的 IDC 和基础云平台的产品研发、运营和市场开拓。

第47讲 | 空降领导者平稳落地要做的四道题（上）

你好，我是饿了么技术创新部高级总监史海峰，今天想跟大家分享的话题是“空降领导者平稳落地要做的四道题”。

2016 年 11 月底，我从当当离职，入职饿了么，担任当时饿了么北京研发中心的总经理。这种“天上掉下个领导来”的操作方式，职场上俗称“空降”。

在我入职一年半之后，已经更名为技术创新部的北研团队规模超过 90 人，负责项目超过 20 个，并且在 2017 年 9 月，从 0 到 1 做了新零售行业风口项目“无人便利货架”。目前，团队核心成员稳定，我这次“空降”算是实现了“软着陆”。

身在职场，难免跳槽。做管理到了一定职级，更难免以领导者角色进入新的组织，当然不一定是跳槽，也可能是在内部转调。我自己空降过，见过、经历过的空降也不少，听说过的行业新闻更多，其中有成功也有失败，比如郭士纳和陆奇，一个让大象跳舞，一个却黯然离场，结果大相径庭。

那空降到底如何才能顺利着陆呢？带着这个问号，可以展开一系列问题。比如：

众所周知空降操作难度大，为什么还要空降？

空降有风险，从公司、团队、自身的角度看，空降的价值在哪里？

墨菲定律当头，降落过程可能遭遇哪些问题，最糟糕的情况会有多惨？

工欲善其事必先利其器，需要提前做哪些准备？

怎样判断自己是否适合空降？

衡量成败标准是什么？有哪些前提条件？

落地后要做哪些动作，遇到各种情况如何应对？

作为空降的团队领导者，该让谁满意？

我将这些问题总结成四条，接下来将寻根溯源抽丝剥茧，一条条进行分析，并分享自己的一点经验。

第一道题：空降的目标是什么？

如果不是非常必要，无论是公司还是个人，通常不会选择空降。评判空降成败的维度可以有很多方面，但空降目的一定很明确，那就是达成公司对这个职位的预期目标，在此基础之上，才能考虑个人的目标。因此，在空降之前弄清楚该公司为什么需要空降技术领导者是非常重要的。

空降是自上而下的管理动作，决策者安排空降一定是有某些特定原因的。在某些组织里，为了避免结党营私形成地盘，会存在空降轮岗的普遍机制，但技术团队更关注技术本身，相对涉及利益较少，团队文化也简单，一般不会有太多这方面的顾虑。

不过，技术团队通常会按照职能或者业务分成很多领域，专业性强，要做好必须精专，一样有隔行如隔山的情况。因此搭建健康的梯队，打造良性的内部晋升机制是技术团队最常态的补缺方式，这种机制也能够激励团队成员，使团队得以有序可持续发展。

公司需要空降的技术团队领导者，一般出于以下几个原因，而且很可能是多方面综合的结果。

1. 团队内部没有可胜任的人才，或者提拔有比较大的风险

如果团队相对稳定，合格的领导者会安排好自身职位的后备人员，就像美国副总统一样，避免领导者本人成为系统的单点风险。一旦有变动，最稳妥的做法就是内部提拔。然而技术团队中技术好手很多，有领导者潜质可以做好团队管理的人才难求，有时后备力量还不足以能够全面接盘团队当前工作，如果晋升之后掌控不好甚至可能给团队带来二次动荡，因此需要空降。从这点出发，对空降者的能力要求会大大高于后备者，否则也可能引发矛盾。

2. 公司内部没有合适的可调配资源

如果是公司内部其他技术团队有适合的人才，他们对于公司及当前团队的情况都会比较熟悉，因此，内部调配也是一种会优先考虑的操作。但内部调配要看是否可行，如果该领导者自身没有好的后备者，或者对于团队非常重要，调不开，则不如从外部招聘人才，把这种资源空缺的问题，转嫁到行业其他公司，甚至是竞争对手，此消彼长，一举两得。

3. 组织结构调整或者他人兼任不是最佳选择

有些公司会通过组织结构调整的方式，把团队拆分到其他团队，或者合并到另一个大团队中，“从根本上”消灭团队领导空缺的问题。但这种方式也需要避免引入新的问题。如康威定律所述，技术团队的组织结构是由业务形态决定的，自有其领域划分，强行拆分合并，反而会带来结构性的内部问题。还有一种方式是组织结构不变，由他人兼任，这个方式会更可行，但无论如何都要有能 Hold 住更大规模团队的人选才 OK。

4. 团队问题需要外力解决，外来的和尚好念经

每个团队、组织都有自身的问题，有时候内部进行变革，会有更多的阻力，以及局限。此时，引入外力，用新鲜血液带来更多不一样的思考和操作是一个不错的选择。毕竟外来的人员没有包袱，更有活力和魄力，也就是俗话说的，外来的和尚好念经。

5. 团队需要更强的领导者

这是最常见的，也几乎是最主要的原因。技术团队对公司来说是非常宝贵的资产，用好了能创造远超预期的价值，用不好则是巨大浪费。因此团队领导者非常关键，要尽可能胜任，能够快速的融入团队，并带领团队有所产出。

技术团队领导者时时刻刻都要挂在头顶的就是目标，到新的团队，这一点最最重要了。一定要搞清楚公司对自己的要求是什么，要解决什么问题还是搞定什么项目，有什么是必须拿下的，多长时间内要达成，团队对自己有什么期望等关键信息，越详细越清晰越好，如此才能心中有数。

技术领导者选择空降，也一定是各方面综合考量之后做出的慎重选择。可能是职业发展天花板，也可能不满足于现状，想跳出舒适区，迎接新挑战，追求更高的成就，也可能是喜欢新公司的味道，跟上级、老板确认过了眼神，大家都找到了对的人。但无论如何都得要达成目标做出成绩，甚至超出预期。

目标就在前方，有没有信心，有没有底气？迎接挑战的勇气通常来源于对自身能力和目标匹配度的准确认知。这其中有常量，但变量更多，比如各种问题和风险。

第二道题：空降会面临什么问题和风险？

空降有风险，跳槽需谨慎。既然要空降，就必须清楚空降的难点有哪些。简单来看，包括但不限于熟悉度、人员、公司、团队、目标、产出等诸多方面，可谓问题多多，困难重重。如果只看见表面的光鲜，风险意识不足，疏忽大意很可能开局不利马失前蹄。

1. 团队陌生，有距离，易产生隔阂

不同于自己从 0 组建或者内部晋升所负责的团队，空降到一个团队，团队成员彼此之间都很熟、很有默契，带头大哥反而是个陌生人，太尴尬了！团队成立的时间越长，老成员越多，这种情况越明显。也就是说，团队的内部凝聚力越强，越有认同感，越难融入其中。

2. 可能遭遇抵触，发生排异反应

新的领导者作为焦点人物，一举一动都会被关注，作为陌生人进入团队，所有人都会“听其言，观其行”审视你评判你，一旦表现不佳引起团队集体反感，后果很严重。每个人对新任领导的感受都是不同的，可能是上升空间被封闭，也可能跟前任感情太好，或者背景不同、认为你技术水平不够、管理不到位，甚至是单纯看你不顺眼，都会形成负面情绪。

3. 组织文化不熟悉

不怕干不了，就怕不知道。每个组织的文化、运行机制都有各自的特点和合理性，而且多数的协调机制都不是白纸黑字明面上的，不知道可能就会闹出大笑话。跨不同行业、不同规模、不同领域的空降，更容易遇到此类问题，比如互联网和传统 IT、创业公司和行业巨头、国企和外企。

4. 团队状态不佳

有的团队正处在比较糟糕的状态，人心浮动，情绪敏感，士气低迷，甚至陷入了恶性循环，比如骨干流失，新人没人带感觉难以成长，工作效率非常低，系统经常故障，在公司内部的口碑很差。集体的惯性是很大的，破坏力也强，扭转颓势不易，但必须尽快发现问题根源，越快解决越好，至少不能持续恶化。

5. 时间窗口窄

无论有怎样的问题，只要团队还在，就要有所产出。留给空降领导者的时间不会太多，短则三个月，长则半年，基本就是试用期的长度。另外，技术团队多数面向业务，工作状态、产出成果都要由业务方来评判，业务不满意，头一个要顶雷的就是团队领导。

今天，我跟大家分享了空降可能会遇到的各种挑战与风险，可能会有泼冷水之嫌，但凡事未虑胜先虑败，提早考虑可能的风险，并采取相应的措施规避，总比空降之后以脸着地要好得多。

明天，我将跟大家分享空降前的准备以及落地后的具体操作，欢迎继续关注。

作者简介

史海峰，贝壳金服 2B2C CTO，TGO 鲲鹏会北京分会会员。负责总体架构规划、技术规范制定和技术预研推广，善于把握复杂业务需求，提出创新性解决方案，在项目中对系统架构进行持续改造优化。负责技术委员会组织管理工作，发掘最佳实践、推动技术革新，组织内外部技术交流。

第48讲 | 空降领导者平稳落地要做的四道题（下）

你好，我是饿了么技术创新部高级总监史海峰。昨天，我跟大家分享了技术领导者空降会遇到的风险和挑战。今天，我将继续空降这个话题，跟大家聊聊空降技术领导者需要提前做的准备，以及如何平稳落地这两道题。

空降能否成功，无论提前做了多少准备，实际跳下去的那一瞬间，仍然要面对巨大的不确定性。至于如何着陆，这是一个不断调整变化的过程，而且难以谋定后动，必须保持高度紧张，快速响应，确保不以脸着陆，给大家呈现空难现场，累及无辜。

第三道题：要提前做哪些准备？

凡事预则立不预则废。很多战争的结局，虽然看似是因为一些偶然因素，但其实真正起决定作用的都是必然因素。例如美国参战，二战的大局就定了，原子弹只是起到了催化的作用，促使日本投降。因此，既然要空降，就要做好充足准备，以便遇到问题时能从容应对，避免忙中出错。

1. 做好情报工作

尽一切可能搜集团队情况，掌握团队职责、团队由来、核心成员、当前问题、leader 为何空缺等信息。信息渠道包括且不限于面试考官、猎头、同行朋友、技术媒体、知乎、脉脉、内部员工。

如果方便，不妨与原来的领导者直接沟通，他是最了解这个团队、这个职位的人。也可以要求与团队核心成员、同级的关键人物见面沟通，聊历史、现状、问题和未来，以便获得更多的感性认识，并对主要干系人的脾性有所掌握。

另外，对于整个公司的发展史、创始人、CTO、技术优势、当前业务等方面的信息，也要尽可能了解，多多益善。

2. 定位优势，获得资源和支持

结合目标，盘点自己的优势在哪方面，以及怎样才能获得支持，具体能够在哪些方面有帮助。优势可以体现在技术能力、行业视野、影响力、所拥有的资源等，比如要招聘补充团队骨干，行业资源丰富的话，可以提前进行盘点和沟通。

另外，上级为了确保空降成功，一般会提供一定的支持，“扶上马送一程”，比如内部培训、招聘名额、预算费用、临时抽调人力等资源，甚至包括直接参与的推动和协调。

3. 做预案

未虑胜先虑败，明确了目标，对于可能面对的风险和问题，要做好充分的心理准备以及行动计划，也可以与有相关经验的同行多多交流经验。

另外，如果软着陆失败，就得硬着陆，永远要有 Plan B。墨菲定律，怕什么来什么，躲是躲不过的，比如团队短时间离职超过 1/3，就得知道得怎么才能快速招到人，甚至拉一个团队过来都可以；比如有人带头对抗，就得狠下心快速剥离不能称职工作的刺头；比如关键技术问题解决不了，就得知道如何快速找到合适的外援。

第四道题：落地时要做哪些动作？

做好了准备，调整好了心态，接下来就到了实施空降行动的时刻。开弓没有回头箭，从跳出舱门这一刻起，前面的所有铺垫都得化为一连串高难度动作，在有限的时间内不断调整姿态，以期平稳落地。

1. 开场

新官上任怎么办？一般会由上级、HR 或者原领导负责引荐给团队，先是核心成员见面，然后是全体会，登台亮相发表“就职演说”，这时一般要介绍自己的背景和成长经历，阐述自己对团队的定位、设立未来目标，并强调自己的工作风格，比如肯定团队成绩、会关注哪些项目、争取哪些资源、多长时间内认识每一个团队成员、欢迎随时沟通等等。

开场第一印象非常重要，衣着、谈吐要得体、有亲和力，最后要有互动，这个环节非常考验应对能力。

2. 观察

走马上任之后不必着急三把火，先多观察，参加各种会，多看各种文档，摸清楚公司的技术体系、系统架构、项目和团队管理流程，以及公司整体的组织结构和运转机制等。另外，对于业务型技术团队，新任领导者务必在第一时间拜访业务伙伴，建立联系，了解他们的痛点和期望。

在观察期内发起团建活动更有利于熟悉团队文化、融入团队，要多做正式和非正式的沟通，补充核实之前的情报，也增加团队成员对你的感性认识，找到认同你的支持者。比如我很少喝咖啡，但换了新工作后，为了方便沟通，一年喝的咖啡超过了前半辈子的总和，和团队的骨干、平级的团队负责人都进行过沟通。

观察是为了确认团队情况是否与预期相符，深入其中，之前的所有信息才会变成真切的现实场景，而且不同来源的信息可能大相径庭，不同人的思维和看法也可能各有千秋，需要分析判断，不断完善自己的认知。

3. 上手

掌握了具体情况之后，要结合实际情况调整预案，然后逐步落地，制定技术路线、优化流程、立规矩、做奖惩、建立领导权威。

需要注意的是，初期发起任何调整前都要做好充分沟通，保证信息公开透明，尽可能传达到所有的团队成员而不失真，以便获得他们的理解和支持，调动起他们积极性，确保方案得到切实执行。

这其中，明确关注点和量化底线很重要，比如出现线上故障、紧急部署、项目延期必须第一时间上报，比如周报务必准时提交，比如重要会议迟到罚款等。通过这些方法，在预定周期内拿出成果，才算走稳了第一步，才能获得公司的初步信任。

一般而言，空降领导者要首先确保团队稳定，一旦出现动荡，就会大伤元气。当然，如果为了达成目标，需要大刀阔斧，也不能犹豫，畏手畏脚。如果团队缺乏骨干，就拉知根知底信得过的得力帮手进场，能快速撑起大局。如果人员与分工不匹配，就调整组织结构，不必顾忌因人设岗，合理配置能减少错位和内耗。过程重要，结果更重要。

4. 原则

有一个原则是空降领导者一定要遵守的，那就是空降之后你就是团队的一员，要为公司、为团队负责，一切行动都应该把公司和团队放在前面，而不是考虑自身利益。坚决不能把自己当外人，你把自己当外人，就会真的成为局外人。另外，空降领导者自己表现得再好，团队不行，就是失败，反之，团队取得成果也就是你取得成果，这点也是要注意的。

在一个已经形成文化的公司，要做的是适应既有文化，抓住重点，掌握团队话语体系并融入自身工作。作为团队领导者，应该更专业，更有大局观，更有管理套路，更符合公司对领导者的要求。

每个人都是空降兵

刘猛在小说《最后一颗子弹留给我》中，对空降兵有句概括度极高的名言——“空降兵天生就是被包围的”，后来这句话随着小说改编的电视剧《我是特种兵》热映而成为经典台词。

没错，空降兵要定点空投、深入敌后，在险境中站稳脚跟、打开局面、完成任务。生活之中，谁又不是空降兵呢？从呱呱坠地降落人世，到离家求学，到毕业后进入职场步入社会，到组建家庭，职业调整，甚至是退休养老，都在不停地适应新环境。

适者生存，是人生常态，每个人都是空降兵，要一次次的投入陌生的环境，能做的就是成为战场主宰，掌控自身命运，决定战局成败。

作者简介

史海峰，贝壳金服 2B2C CTO，TGO 鲲鹏会北京分会会员。负责总体架构规划、技术规范制定和技术预研推广，善于把握复杂业务需求，提出创新性解决方案，在项目中对系统架构进行持续改造优化。负责技术委员会组织管理工作，发掘最佳实践、推动技术革新，组织内外部技术交流。

第49讲 | 打造高效的研发组织架构：高效研发流程那些事（一）

你好，我是箴亚管理顾问公司负责人，同时也是 TGO 鲲鹏会台北分会学习委员游舒帆，今天想跟大家分享的话题是“高效研发流程的第一步，打造高效的研发组织架构”。

要谈高效研发流程这回事，首先我想先跟大家聊聊高效这词，我对高效的定义是：更快的将事情做对、做好。也就是说产出要快，内容要对，而且质量要好，又快、又好、又有价值才符合我对高效的期待。

“快”，在互联网时代，通常强调的是应变得快、调整得快，这与组织架构、分工，以及决策过程有关。“好”，就是交付的质量，说得出做得到，总是能交付出可预期的成果，这与软件工程的成熟度有关。“有价值”，则是源自于方向与优先级正确，这与企业战略与目标设定有关。

因此，谈高效研发流程，我们便不能只谈研发流程本身，必须将视野拉到外部环境、企业战略与组织架构等层面来思考。

两种最高效的场景

在我过去接触过的千千百百种流程里，其中有两类场景是最高效的：

第一类，制造业的生产线。 每个关卡、每个环节都被精密计算，关卡与关卡间毋须沟通，也甚少出现停顿等待前一个关卡的状况。各关卡只需要负责完成它所负责的那项任务，内容的变化性极少，突发状况也几乎都被控制，成果的可预测性极高，可以大规模、重复的产出相同的成品。

第二类，全栈型员工。 毋须分工，毋须沟通，可以自己一个人从厘清需求、设计架构，到编写前后端代码，同时搞定测试与布署等所有事情。少了沟通这个环节，他不用分心向其他人说明自己的想法，不会有冲突，也不用相依于其他人的工作，这种状况下，工作能不高效吗？

然而，这两种场景都有很大的局限性，第一类场景无法很有效的应对高变化性的环境与需求，即便在如今智能制造的环境下，多样少量的按需生产仍有极高的局限性，想当然也很难适用于现今多变的软件与互联网环境。

第二类场景的局限性则在以下两点：第一，生产力有限，面对较大规模的工作量时，团队分工显然会更高效；第二，专业性问题，全栈型员工并不意味着所有的技能点都点满。

从上述两种极端的案例中，我们可以先了解到一个最基本的观念，那就是“流程高效的前提是对应了适当的场景，而场景，则源自于我们所面对的挑战以及所发展出来的战略与组织架构”，这与我们开头提到的又好又快相互呼应。

四种企业组织架构

前面一段我们提到了两类高效的场景，第一类是高度确定性场景，第二类则是高度不确定性场景。这个部分我将跟大家简单分享一下我经历过的几种主要的场景，以及对应的战略与组织架构。

大家可以先透过以下这张汇整表对这几类组织结构有个基本认识：

1. 功能型

讲究专业分工，基本上制造业或传统产业，大多仍沿用这种组织架构，因其所面对的环境变化性小，流程与技术的变化性也相对较小，在稳定状况下，明确的分工有助于效率的提升。

2. 产品型

又称 BU(Business Unit) 型，通常是为了快速抢占市场而组成的团队。功能型组织分工明确，但容易形成谷仓效应，彼此各自为政，不利于战略的快速推进。如果企业资金充裕，且追求快速推进，一般会让各产品线或 BU 自建销售、营销、服务等相关功能部门，并且各自进行管理，所有功能的主管权集于一人身上，决策相对高效。当然了，对应的或许是资源的重复投入问题。

3. 混合型

一家经营 5 年以上的企业，一般会具有多个产品或事业。某个产品 A 已经相对成熟，对变化的可预期性提高，此时可能会从产品型组织转换成功能型组织；而另外有个产品 B 则尚在起步阶段，仍须快速推进，产品型组织就相对适合。这种状况下便会出现功能型与产品型组织并存在企业内的状况，就我过去的经验，大多数的大型企业最终都会走向这种型态。

4. 战斗小组

当你面对极端不确定的环境，例如全新市场、新科技早期的技术探索等，组织过大的产品型团队一来成本高，二来效率也会受到限制。此时，最佳的解法通常是派出 2-3 人组成战斗小组，在这个团队中所有人都是多能工，每个人都能同时处理多个职能的工作，如同初创团队一般，小而全的高效运作。

以创业团队来说，刚起步时大多都是创始团队组成战斗小组，随着市场需求的厘清与扩张，会逐渐转为产品型，然后随着分工愈来愈清晰，制度愈来愈完善，会步入功能型，等开始切入第二个产品或事业时，就会变成混合型组织。

企业组织架构与研发组织架构如何高效匹配

前一段我们谈到了企业组织架构，这个段落我将分享研发组织架构如何与企业组织架构高效匹配。

企业在草创初期，走的大多是战斗小组模式，研发在此时还没有形成一个独立编制。但随着企业日渐成长，公司规模成长到百人规模，业务、营销、服务都成立了独立部门，研发团队也来到 20-30 人的规模，为了有效的管理与确保研发资源的最有效运用，研发通常也会被独立成一个部门，而企业内，也会自然的走向单一产品型或功能型组织。

1. 集中式的研发团队

习惯上我会称这个阶段为集中式的研发团队，这一时期基本的运作模式如下图，各部门对研发部门提出需求，研发部门则依循一套机制来排序所有部门的需求，并且按照谈定的顺序进行开发工作。

然而，企业在此时仍在追求快速成长，因此销售与营销的需求往往会优先被考虑，而服务与后勤的需求，以及研发团队针对产品或技术架构优化的需求，则往往被滞后。需求顺序会偏重支持短期的营收增长，而客户服务与产品优化等长期项目则严重被忽略。

2. 分布式的研发团队

有鉴于集中式研发团队的问题，许多企业会在此时选择扩张或重整研发团队，将一部分的研发资源放在处理各功能部门的短期性需求上，我习惯称这样的团队为功能部门研发团队；另一部分研发资源则专注于产品与技术的持续进步上，这个团队我则习惯维持研发团队这个称呼。

经过调整后，各功能部门都将拥有一个属于自己的小规模研发团队，所有的需求都可以先提交给这个团队。若需求本身较紧急，且规模较小、复杂度较低，那就由这个团队直接处理，若判断后认定为长期需求，则将需求 pass 给研发团队来评估与开发。

这样的组织架构，虽然可以同时兼顾长期与短期的需求，但那些被分配在功能部门的研发成员们则难免会有所怨言，会认为自己所做的事没有太高的技术含量，更多的是例行庶务与简单的编程工作，时间久了便会失去工作热情。我们曾经尝试过轮岗，让成员能在各团队间轮替，但在几次实践之后，发现这样的做法成效并不好。

因为所有人都倾向于做那些看起来价值更高的事，如果技术领导者在做组织分工时，已经先排出团队价值的高低，那被分派到低价值团队的成员，自然会觉得自己的工作价值不高，会觉得自己不被重视，团队的向心力、热情与使命感都会大幅降低。

为了有效的解决这个问题，我们又尝试了第三种组织架构——矩阵式研发团队。

3. 矩阵式研发团队

矩阵式组织架构最主要的特色在于，重新定义了之前提到的功能部门研发团队的角色。过去，我们指派给这个团队的任务是支持功能部门排除问题与开发短期需求，现在，我们则把各个功能部门定义成一个个独立的产品，每个产品都有单独的产品经理负责，而这个产品经理的核心任务就与各功能部门的产出直接挂钩。

例如，销售系统被定义成一个独立的产品，它拥有自己的销售 PM，目标就是让销售部门达成所有 KPI，可能是业绩、退货率、客单价提升等。

当角色从消极的支持转为积极的负责后，团队的定位就更加清晰且重要了。

此外，推动矩阵式组织的另一个观点是，产品经理可以通过改善产品，或通过运营的手法来促使业绩达成比如 30% 的增长，然而产品经理始终是产品专长，对于销售、营销、服务的理解并不见得非常深入，因此，如果能在销售、营销、服务等岗位上也设立产品经理的职务，肯定能对增长带来重大效益。

举例来说，如果销售 PM 能通过技术带来 30% 的销售效率提升，就能一次性让多个产品同时受惠；如果服务 PM 能通过技术更个性化的服务顾客，有效的降低了比如 15% 的退换货，也有机会让数个产品都得到提升。过去经验里，这些 PM 本身都熟稔技术与业务知识，能同时从两方思考系统问题，所提出的解决方案往往会比纯技术 PM 或纯业务 PM 来得更加到位。

从这个角度来思考，功能部门研发团队的重要性便明显提高了，他们能直接为公司的效益带来贡献，团队成员们有了相对清晰的目标，使命感与热情便有了非常明显的提升。

本文跟大家讨论了较多关于场景与组织架构的内容，往下几篇，我将分别与各位聊聊关于研发流程管理的选型、研发管理过程中的那些坑，以及如何打造追求更快、更好、更有价值的组织文化与人才梯队。

很高兴能与大家交流关于高效研发流程这个话题，咱们明天见。

第50讲 | 你的研发流程符合你的组织架构吗？谈高效研发流程那些事（二）

你好，我是箴亚管理顾问公司负责人，同时也是 TGO 鲲鹏会台北分会学习委员游舒帆，今天想跟大家分享的话题是“高效研发流程的第二步，研发管理流程的选型”。在上一篇文章中我与大家分享了组织架构与打造高效研发流程间的关联，本文将着重于研发过程的探讨。

刚出社会时，我在一家 ERP 软件公司从事研发工作，我在那里接触到了非常正规的软件工程，也见识到当研发流程与业务特性匹配时的高效，以及不匹配时产生的诸多问题。在 2000 年初期，软件开发大多仍遵循瀑布式 (Waterfall) 方法，必然得先进行需求收集、分析、设计，然后进入开发与测试，经过一道道程序后将成品完整的交付。

在 ERP 软件公司的那些年，我也参与了软件成熟度模型 CMMI Lv4 的导入与认证，过程中，我见识到了 CMMI 的严谨之处，同时也体会到严谨背后带来的低效与冗余。由于当时我所负责的产品处于需求不明确、市场性待验证的状态，如果要依照 CMMI 的规则产出完整的需求列表与完整的分析文件，估计是不可能的。

因此在过程中我试着提出用假设性需求，以及用雏型替代成品的方法来进行市场验证。出乎意料的是，这个提议获得了 CMMI 顾问团队的认同，而这也是我对 CMMI 有所改观的转折点。公司内推动小组的负责人告诉我：“CMMI 本来就是一个模型，每家公司得依照自己最适合的方式建构流程，但最终须能达到 CMMI 要求的水平。”

2011 年，我开始负责 SaaS 相关业务，也首次接触了敏捷观念以及 Scrum，与此同时，互联网开始进入火爆增长期，所有的企业都在求新求快，技术团队也被要求要具备更灵活、更弹性、更迅速的特性，只是一两年时光，国内所有公司都在讨论敏捷开发，而不再有人讨论 PMP 和 CMMI 所主张的瀑布式项目管理与研发流程管理方法。

2013 年，我开始在团队中大量引用敏捷观念，通过频繁的交付来验证用户与市场需求，也在技术社区中与许多朋友交流项目管理与软件开发方法，我看见越来越多的人想拥抱敏捷，但同时我也发现，许多人对敏捷其实一知半解，并且对 PMP 及 CMMI 有着错误的偏见。

2015 年，我进入互联网公司后，人人口中所谈的都是敏捷，万一在讨论过程中有人提到 CMMI 或 PMP，就会有人露出鄙视的眼神，他们误以为过去项目做不好，是 PMP 与 CMMI 所造成的，却未曾思考过，或许项目失败的真正原因不在流程与工具，而是运用的那些人。

关于瀑布式或敏捷开发方法的选择

在前一篇文章中，我提到当企业内外部状况稳定，需求的变化性较少，可预测性高时，功能型组织是相对适合的组织架构，而相同的概念，其实也适用于传统的 PMP 管理方法。PMP 强调程序、输入 (input)、输出 (output) 与权责，这与功能型组织不谋而合；相较之下，敏捷强调的快速响应、迭代，则与产品型组织或战斗小组更加匹配。

当一家公司内可能存在多种组织架构时，是否也意味着应该存在多种开发流程呢？我的答案是”肯定的”，当我们过度坚持公司内只能有少数一两套程序，硬要逼所有人配合时，其实已经与敏捷所追求的“专注于更快的创造价值，持续精进”的理念背道而驰了。

最近几年，我一直在同时并行管理多种组织与开发流程，接下来将跟大家分享在不同的场景下我是如何选择的：

1. 需求具备高度不确定性，重要性高，但时程紧迫度一般

例如新商业模式的探索、从 2B 跨入 2C 的新产品等，这样的任务我一般会以战斗小组的形式组成团队，团队成员会根据当下需求随时做调整，可能是 1 位产品经理配 2 位研发工程师，也可能是 3 位具备分析能力的资深工程师。

这样的团队基本上不会有太明确的分工与流程来局限他们，团队可以选择自己熟练的工具，协议合适的分工，唯一的目标就是把问题给解决掉。

2. 需求有一定不确定性，且时程紧迫

例如要赶及在某一天推出新产品或新 feature，藉此创造市场话题。这样的任务一般我会交由产品型组织来完成，而为了持续降低不确定性，他们需要频繁的交付成果以验证市场反应，以期在 deadline 之前把产品交付出来。在我过去几年实施敏捷的经验里，这一类的项目约占总项目的 7 成左右。

在这类项目中，为了同时兼顾效率与质量，团队基本上会依循一定的程序进行项目目标定义、需求厘清、开发、测试与布署，而在分工上，一个人可能会同时兼任多种角色，例如资深工程师除了要写代码外，也要负责架构设计与需求厘清，而产品经理可能同时兼任项目经理与原型设计。

复杂度较高的项目，可能设有独立的项目经理，否则多数状况下产品经理必须兼任项目经理角色，他们必须对项目负责；而架构师与用户体验设计师则不见得会参与每个项目，除非项目涉及较大的架构变迁或选型，以及明显的用户体验缺陷或改进。

分工的方式会根据不同的项目而有所不同，唯一的原则就是，分工必须是必要的，如果只是在工作流程上卡一关，但没有对项目带来实质效益，那分工便非必要。

3. 需求具有高度确定性

例如与战略伙伴合作的项目，彼此已经先把所有需求厘清，并且敲定了验收时间。这样的项目一般我会另外组织项目团队，按瀑布式开发流程推进，并切出几个重要的里程碑进行阶段性验收。

如果敏捷是藉由更快且更频繁的交付，以期降低不确定性并更快的创造价值，那么在目前的项目中，需求基本上已经非常明确，时程也按着彼此协议好的时间进行，中间其实不存在太多需要通过迭代来验证的内容。唯一需要的是按表操课、如期如质的将成果交付出来。

独立的团队，明确的计划、分工与权责，加上里程碑查核，这类案子的稳定度是最高的。所以时至今日，多数的外包项目，都还是依循着这种程序，否则将在报价、管理与验收上产生诸多困难。

上述内容汇整后，可以用下面这张图做个概括性的理解，根据目标与需求的不确定性的高低，所采取的项目管理方法、团队组织与分工方式也不同。

追求敏捷，但更要重视项目管理基本功

在领导团队时，我特别强调项目管理的基本功，因为我认为多数的问题都是出在基本功不够扎实。在项目开始前与进行中，一般我会对产品经理提出很多问题，以确保项目能如原先预期推进。

在项目启动阶段，一般会由团队就已知信息先拟定 draft plan，其内容主要是陈述项目要做哪些事？打算如何进行？由谁来做？预计花费多少时间？以及将得到什么样的结果？

而当团队将计划产出后，我会问产品经理：“这个项目中有哪些不确定性，可能会导致你无法准时交付？”项目管理早期的主要问题大多是“需求不够清晰”、“不确定人力资源能否配合”、“对工作的估时过长或过短”、“技术可行性待验证”、“老板可能还会改动需求”等等，而这些，就是导致项目进行阶段会频繁发生变更 (change) 的原因。

相对的，如果你在规划时期，就已经先把这些问题排除了，那运行时会面临的变更就相对减少了，案子的进行也会相对轻松许多。

这些对我来说都是项目管理的基本功，敏捷虽然强调拥抱不确定性，并欢迎随时的更动，但不意味着我们要对那些不确定性置之不理，而是要尽快的让不确定成为确定。 敏捷强调不断进步与反馈，我们必须通过一个又一个项目的磨练，让自己能把需求看得更清楚，对时程估算得更准确，能更有效的对齐老板的期待，而要做到这些，团队就需要逼着自己不断进步。

若你对 Scrum 架构有所研究，你便会发现 best practice 里头强调的架构，其实正是针对上述几个最常见的项目不确定性而来的。例如，针对时程，Scrum 强调固定的交付周期，以 1-4 周为佳，而且强调是固定团队，在过程中也尽可能避免团队成员同时参与多个项目，在这个基础上，再来讨论这样的团队，在一个迭代时间内可以完成多少工作。

Scrum 给出了一些框架与规范，确实有助于提升团队的项目管理水平，如果团队原本的项目管理能力只有 60 分，或许导入 Scrum 后能提升到 80 分，但如果要做到 90 分，团队还是要根据所遭遇到的问题进行持续不断的改善。

进步，是永远不变的追求

曾有一个 team leader 在一次会议后问我：“老大，不断打破与调整流程，让大家忙得要命，背后追求的到底是什么？”

我说：“进步。忙是一时的，但你想想一年前我们做一样的事情花多少时间，现在又花多少时间？针对一个异常，过去我们是发生后才知道，现在我们已经可以弭平于未发之时。从前我们没日没夜的工作，换来的却是很多谩骂，但现在我们花更少的时间，却换回更多的掌声，因为我们持续在进步。”

如果需求管理不当、时程估算误差过大、未以正确的态度面对不确定性、项目过程控管差劲，却总是靠着团队加班来填补落差，团队可以靠着热情撑过一小段时间，但随着时间延长，团队总是会乏力，身为技术领袖应该要以持续进步为己任，而不该沾沾自喜于团队的超时工作。

记得，永远都要追求更快、更好、更有价值，别用战术上的勤奋，来掩饰战略上的怠惰。

第51讲 | 聊聊研发流程管理中的那些坑：高效研发流程那些事（三）

你好，我是箴亚管理顾问公司负责人，同时也是 TGO 鲲鹏会台北分会学习委员游舒帆，今天想跟大家分享的话题是“高效研发流程的第三步，研发流程管理中最困难的那些事”。

前两篇文章中我与大家分享了组织架构与研发流程的选型，这两者都是高效流程的基础，可以让团队做好事 (Do thing right)，但却不见得能做对事 (Do right thing)。

我曾在台湾敏捷峰会上分享过一句话，在这里也分享给大家：“如果敏捷走不出技术团队，就不可能真正敏捷”，一样的观念“研发流程如果只着眼于研发工作本身，就不可能真正高效”。因为研发团队不是独立存在的，其本身的工作与外部具有一定的相依性，例如需求、营销、运营、服务等，如果我们不能有效的管理这些事，只会事倍功半。

本文我将会着重就研发管理过程中最困难的几件事：需求管理、优先级、迭代与交付方式、跨部门沟通与数据驱动等主题与各位分享我的经验与看法。

1. 需求管理

所谓的需求管理，并不是单指整理出需求列表，而是需要对这些需求做有效的管理，让团队能满足老板与客户的期待，所以我也常说需求管理本质上其实是期待管理。

在谈期待管理时，我常常用这张图来跟团队沟通：

我总是问团队：“你们清楚老板想解决什么问题吗？”因为很多时候，项目团队往往只看到有件事得做，而时程已经被压上去了，所以匆匆忙忙的开始项目工作，但却很少花时间去理解这个项目背后的为什么。一年下来，做的项目也不少，但却没有几个项目真正解决问题。

如此，老板的需求没有真正被满足，对团队的信任感自然也不会太高，而这样的企业，一般效率也不会太高。

如果公司的组织架构是属于多阶层式的科层组织，那这个问题会放的更大，老板可能只是想解决一个很简单的问题，但经过层层解读与转达后，最后收到的需求是要做一整套系统。导致原先只要一两周时间就能解决的问题，却往往得拖上半年一年之久。

要真正做好期待管理，团队必须在承接每个项目时，都往上层去了解源头的问题，这就是所谓的上游信息。当团队能真正理解老板与客户的真实期待，并逐一解决时，需求管理这件事才可能真正做好。

2. 排定优先级

排优先级，一直都是件难事，我们如果想在相同的时间内创造出更多的价值，那决定先做什么，不做什么就成了关键点，所以优先级的规则至关重要。过去我们曾经采取过几种排定优先级的方式：

第一种，权力决，通俗一点来说，就是由权力大的人来决定，排第一的通常是老板或业务部门最高主管。权力决有另一种变形，那就是让承担该业务的主要负责人来做决定，例如产品经理决定产品优先级，业务主管决定业务需求优先级。权力决的好处是决策者明确，然而缺点是官大不一定学问大，有权力的人，对现场的把握度可能反而是最差的。

第二种，共识决，由大家共同决定项目的优先级，严谨一点的甚至会成立一个委员会来定期处理此事，然而就过去经验，如果没有适当的机制来维持客观性，共识决与认可决的背后其实仍是权力决。

第三种，数据决，由大家共同协议一个项目价值的运算公式，例如能带来多少业绩、改善多少服务满意度、提升多少用户增长或留存率、降低多少人事成本等。每个项目都会被算出一个权重，然后依此权重值进行所有项目的排序。这个做法的好处是客观，所有参数都是经过讨论后得到的共识，缺点则是对项目价值的计算不会一开始就很精准，必须经过一次又一次的修正后才会越来越准。

过去这些年来，一般种况下我是倾向使用数据决，如果过程遭遇争议，便辅以权力决或共识决。

3. 迭代与交付方式

如本文开头所述，如果研发团队能将视线从团队内移往团队外，并面对真正的问题，那我们应该会把重点放在快速迭代，创造价值，而不该单单着眼于开发迭代，这句话的意思是“解决问题，不必总是仰赖技术”。

专业人士因为拥有一身绝活，所以思考问题时总想着运用专业来解决问题，技术人在面对问题时也时常会想用技术来解决，然而有许多事情其实可以靠流程解、人工解、沟通解，不见得总是得仰赖技术。过去在带领团队时，我给了团队绕路解、临时解、根本解几个规则，让他们在规划与思考时能有依归。

问题发生的当下，依循处理问题的三段式方法，一定要先能提供一个绕路解，也就是 workaround，但身为研发人员，我们都很清楚 workaround 不代表问题被解决，如果不根本解决问题就会累积技术债。所以我们还是要从根本来解决此问题，但如果根本解的时间太长，用户无法忍受，你就要提供一个临时解来缓和用户的痛苦，不能根除也要先能止痛。

这样的做法，基本上能同时考虑到技术与运营两方，在内部讨论时很容易取得共识。

而面对需求，我们也强调三段式方法，如果有个需求可以每月创造 2 亿的营收，但完整做完需要花 4 个月的时间，我们会将这个需求细拆，找出其中相对有价值的部分先做，可能只花 1 周的时间，就能达到 20% 效益；紧接着在 4 周内再推出第二个版本，这个版本已经能创造 60% 效益；最后再推出根本解，实现完整的需求。

当我们着眼于更快的创造价值时，迭代的方式与周期便可能有多种方法，而三段式方法是我们过去用过的，效率非常好的一种方法。

“解决问题，不必总是仰赖技术”这个观念我们也在持续推广到研发部门外，让大家了解不是凡事都得靠系统，如果时间真的急迫，但研发部门暂时排不出资源，我们也会从专业角度提出其他建议方案。

过去产品团队曾提出一个很棒的产品点子，在早期规划时产品经理与设计团队对于功能产生诸多歧异，并且技术团队做了初步评估，认为要完成这个功能最少需要四个月的时间，我们就这样僵持在会议室内。

此时有位同仁提出了一个很好的建议。他说可以找客服部门合作，请他们找 40 位客户，并告诉客户我们将提供一项新服务，邀请他们抢先体验。而初期，便由客服部门同仁通过人工来服务客户。

我当下觉得这个建议可行，便去找客服主管讨论此事，她听完后觉得很不错，虽然会增加一部份工作量，但能协助产品部门更快的把好的产品功能产出，这些投入非常值得。

人工处理的好处是调整效率高，早上客户反映有状况的地方，下午就可以修正，这种效率是技术做不到的。这个人工服务的时间大概维持了一个半月左右，过程中流程调整了多次，服务内容也修正了好几次。我们可以思考，如果是交由系统来迭代，我们需要花多少时间才能迭代出这个结果呢？

不过，虽然人工迭代的效率高，但人工毕竟无法处理大批量的工作，这部分还是要交由系统去处理，然而有效结合人工与系统，将可能创造最高的迭代效率。

4. 跨部门沟通

在我过去经验中，技术主管最常求助于我的问题有二：第一个是向上管理问题，不知道如何有效的跟老板沟通；第二个则是横向的跨部门沟通问题，彼此之间 KPI 不同，目标不同，讨论时常谈不到一个点上。

其实上述两个问题的解决方法是一样的，都是要掌握上游信息，解决上游问题，我说服团队成员学习向上管理，运用的是本文前头提到的，不断去追问 “为什么” ，只有掌握了为什么，才能知道自己做的事情到底对不对。

而我用来说服团队做好横向沟通则会辅以一个故事：“如果今天你住在河川下游，河川的上游住了另外一群人，上游这群人每天都会在河里倾倒垃圾，所以位居下游的你，要不没有干净的水好用，要不就要喝脏水，此时你会怎么做？”

“我会搬到他的上游去。”“那他也会继续搬到你上游，互相伤害。”
“我到上游去将河道分成两条路线。”“好方法，但工程浩大。”
“我会去劝导他们不要这样。”“一开始有用，两天后可能又故态萌发了。”

通常经过一轮讨论后，大多会得出这个答案：“我去帮他们建立垃圾处理机制”。不管我提问的对象是什么背景，这个简单的答案通常都不会在一开始就出现，原因很简单——我们都认为那是对方的责任。所以我们会直觉的绕开对方的责任圈，我们只在圈外打转，顶多作柔性劝导，而不愿直接有效的帮对方解决问题。

我常灌输大家一个观念，如果我们的上游出问题，不论他是没能力、没资源或是不愿意解决，问题就是在那，如果不帮他解决，我自己就得蒙受其害。这种情况下，那件事不再是别人的事，而是我们的事。当所有部门都理解了这个观念，都能协助上游解决问题，并给下游干净的水源，那跨部门沟通便不再是问题了。

当决策、运营与开发都在正确的组织架构、流程上，而上下、横向之间的沟通都没有阻碍时，研发流程才真正实现了高效。

第52讲 | 数据如何驱动研发高效运转？谈高效研发流程那些事（四）

你好，我是箴亚管理顾问公司负责人，同时也是 TGO 鲲鹏会台北分会学习委员游舒帆，今天想跟大家分享的话题是“高效研发流程的第四步，数据如何驱动研发高效运转”。

在前一篇文章时，我曾提到数据决，因为我认为数据是支撑决策的关键要素之一。当我们作决定时，通常会希望有些数据来协助判断，例如用户增长衰退，我们通常会想了解是哪些渠道没有达到原先预定的目标；找出渠道后，我们会想进一步了解原因是转化率下降，还是流量下降了，并一步步找出源头问题。这一决策过程中数据的重要性不言而喻。

我记得在一次业务会议中，当月业绩落后了 20%，业务部门主管汇报业绩落后原因时直接挑明了说“业绩落后的原因是因为产品出了问题”，我连忙追问：“请问影响了多少个百分比？”对方回答我：“总之很多，好几位业务主管都跟我抱怨这件事。”我又问：“请问是哪几位业务主管？”对方一时答不上来，只含糊地说了句：“总之是产品的问题。”

幸好一直以来我都有收集跟解读数据的习惯，我当下回复：“我可以告诉大家影响的比例有多少，大概是 2%，共有 8 位客户受到影响，而剩下的 18% 我也可以给大家解释问题的地方大概在哪里。”

这个状况在一定规模的公司里很常见，技术或产品部门背黑锅事小，决策错误所衍生的问题事大，因此，如果我们要持续做对事情，就要有能力掌握更充足的信息与数据来支撑我们作决策。

为了让数据更高效的助力经营决策，我曾提出企业应该具备数据策略，所谓的数据策略，顾名思义就是企业如何采集、储存、管理、使用数据，并对企业整体带来帮助。而在这个前提下，我们可以说数据策略是衍生自企业策略，而且数据策略与企业策略间的关系越来越紧密，企业不该只盯着落后指针看，而是要从数据中挖掘出洞见，并采取行动。

而为了让数据能真正发挥效用与价值，我也根据过去经验，整理出了数据策略落地的五个步骤，下面详细跟大家分享。

首先，所有的数据策略，都需要从企业整体策略出发，举例来说，如果今天营销部门的年度策略中有一项是“落实精准营销”，目标是藉此“提高客户年消费金额 (从 5,000 元–>5,500 元) 与成交率 (从 3%–>4.5%)”，而在这样的策略之下，营销部门认为进行交叉销售、做个性化商品推荐有助于达成这个目标，所以他们对研发与数据团队提出了相应需求。

Step1. 依据策略提出数据需求

当我们厘清了营销部门的需求后，我们通常会提出一个问题：“你要数据帮上忙的地方是什么？你要数据回答你什么问题？”

这个问题你必然得回答，基本上数据能协助你解答你有疑问但还不知道答案的问题，但如果你连自己的疑问是什么都讲不清楚，那数据通常就无法帮上忙。

过去我在 BI 年代，总有人期待 BI 的 dashboard 可以直接告诉他经营上所有的问题，然而现实是“BI 只能让你更清楚全貌”。到了大数据与 AI 的年代，仍有不少人抱有这样的想象，我总会告诉大家“如果有了大数据技术就能搞定经营的大小事，那你还犹豫什么？花钱买解决方案就对了”，然而事实并非如此。

如果你要开始做数据化管理，首先要思考的问题就是，你要数据回答你什么问题？

在之前提到的这个营销案例中，我们能得到以下答案：

我想知道 A/B 商品、A/C 商品或 A/B/C 商品同时在一张订单的状况，这有助于我进行交叉销售。

针对 25-45 岁白领女性，找出其中买 A 品牌的口红比例显著高于买 B、C 品牌的群体，我想要知道特定族群对品牌的偏好性，这有助于我推荐合适的商品给客人。

Step2. 确认数据处理目标

有了清晰的数据需求，数据团队就能从这样的需求去讨论他们要对数据做什么样的处理，才能得到所需的信息，可能是分析、汇总、统计等等，而处理完后的预计产出物我称之为数据目标。

因此，在之前的案例中，“想知道 A/B 商品、A/C 商品或 A/B/C 商品同时在一张订单的状况”这一需求的数据目标是：

找出所有的畅销品清单，根据过去公司对畅销品的定义，就是销售数量 >50,000 件的那些商品；

找出所有购买畅销品的订单与顾客；

分别以订单与顾客为源头去找与那些商品同时出现的其他品项。

而“针对 25-45 岁白领女性，找出买 A 品牌的口红比例显著高于买 B、C 品牌的群体，想要知道特定族群对品牌的偏好性”这一需求的数据目标是：

找出 25-45 岁的白领女性顾客清单；

找出上述顾客购买的订单；

分析这群顾客对畅销品购买的显著性。

Step3. 盘点与汇整既有数据

有了预计产出物，接下来就是要实际去看看手边的数据是否足够了，在盘点数据时除了内部数据外，也要同时思考外部数据。而当你盘点完内外部数据后，应该先做一次基本的汇总动作，确认这些数据是否充足。

以上述案例来说，或许在处理第二项需求时，发现会员数据中，有填写年龄的只占总数的 10% 不到，这可能导致最终成效不如预期，因此盘点后，判定缺了年龄的数据。

Step4. 盘点新数据采集需求

如果数据盘点完后发现有所不足，那就要提出数据采集需求，并提列为数据行动方案。以这个案例来说，就是要想办法去采集会员的年龄数据。

Step5. 拟订数据行动方案

在执行完上述程序后，我们要将所有提到的工作事项列为行动方案，然后有计划、有分工的逐步落实，如此才有可能让数据落地，真正开始助力运营工作。

研发工作是一个科学与艺术活，我们掌握着技术与数据，只要能让团队多一些商业与策略敏锐度，培养从数据角度去解读各种症状的意识，研发部门是完全可以助力业务快速推进的。

第53讲 | 如何打造高效且敏捷的组织文化？谈高效研发流程那些亊（五）

你好，我是箴亚管理顾问公司负责人，同时也是 TGO 鲲鹏会台北分会学习委员游舒帆，今天想跟大家分享的话题是“高效研发流程的第五步，打造追求‘更快、更好、更有价值’的组织文化”。

前面四篇，我们把一个组织的骨架 (组织)、血肉 (研发流程管理) 跟循环系统 (需求、跨部门、数据驱动) 都装上了，最后这篇，我们要来为组织注入灵魂，也就是团队的文化与价值观。

价值观是如何形成文化的？

几乎每一个大公司，都会谈使命、愿景与价值观。其中，我特别想跟大家聊聊价值观，价值观其实就是我们看待事情的原则，它会左右我们面对问题时的决定。

而文化，其实是价值观实践出来的结果。当我们强调客户第一，强调诚信，而且公司通过一个又一个案例来告诉大家，什么叫客户第一，什么叫诚信，当大家都按着这些规则来决策与做事，做久了，就会形成文化。所以，文化其实是做出来的，而不是说出来的，大家对文化的感受，是我们怎么做，怎么思考，而不是我们说了什么。

当价值观根深蒂固后，所有员工都会明白，当面临抉择时，只要按着价值观去做决定、去思考就不会错，因为他们知道，这问题即使去问老板，老板也一定会做相同的决定。当员工都知道该怎么做决定时，就不用事事请示领导，决策权分散出去，组织运作才会高效。

所以我才说，文化与价值观是高效研发团队的灵魂，因为当大家都清楚我们追求什么，重视什么，该怎么做才符合我们的价值观时，再辅以专业知识搭建起来的组织架构与流程，团队便会自然的让一切更好。

打造高效且敏捷的组织文化

更快、更好、更有价值，这是团队不变的追求，那么该如何落实在日常，让团队清楚我们追求什么，以及我们重视什么呢？以下我拿几个常见的案例来跟大家分享。

1. 解决问题，别只是提出问题

在团队内，我一直要求大家不要只会提出问题，而是要解决问题。当跨部门合作有灰色地带的工作时，产品经理或项目经理就应该先吞下，待问题解决后再来讨论由谁处理比较好。原先公司内没有人是从业务前线一路衔接到后勤运营与服务的，导致产品上市过程有许多的信息丢失，导致各部门认知有落差，进而影响了客户，当时我就要产品经理负担起这个责任，从前到后将所有问题都连接好。

跟老板之间沟通有问题，我就要大家去掌握上游信息，与横向部门之间沟通有问题，我就要大家学习上下游思维。关于上游信息与上下游思维，我之前也有提到过，大家可以回顾前两篇的内容。

经过一次又一次的案例，大家便清楚，当发生问题时，永远都要去思考怎么解决问题，而不是把问题丢给别人解决。

2. 具备主人翁精神

在整个团队中，我对 leader、项目经理、产品经理、资深员工的要求是显著严格的，因为我认为这些人是榜样，也是传递团队价值观跟文化的载体。所以让他们认清他们该承担的责任是非常关键的一件事。

有一次我在与一个项目经理沟通项目状况，他告诉我他经过几番折冲，终于让业务部门与营销部门愿意配合项目进行，我仔细听他陈述结论，过程中我越听越觉得不对劲，后来我直接打断他。

我说：“因为业务部门无法配合，所以你做了部分妥协，有些事情暂缓不做，而因为营销部门有资源调度的困难，所以你决定另一部分也不做，所以本来要做 100 分的东西，妥协后只剩下了 60 分，对吗？”

他回答我说：“对啊，案子能推进比较重要不是吗？”

我说：“这个思维有问题，只有 60 分的东西还要做吗？你让团队 10 多人跟着你忙了大半个月，结果弄一个 60 分的东西出来，这像话吗？”

所谓的负责，不是只把工作做完，而是要做好且做完，100 分的结果是我们这个项目的目标，沟通过程中如果碰到问题，你应该是在不折损目标的状况下去思考解决方案，而不是牺牲目标让事情得以进行。

对成果负责，对团队的价值负责，对自己的成长负责，这就是我所强调的主人翁心态。

3. 追求又快、又好

曾有一次，有个 QA leader 告诉我某个项目的测试时间需要三周，我一听觉得有点玄，因为开发时间一周，但测试却要花三周，不太合理。我问他为何需要这么久，他摊开了测试案例告诉我，因为需要测试的案例高达 2、300 个，这些时间无法节省。

我接受了他的说法，也接受了三周这个时间，但我紧接着跟他说：“下一次同样的案例，我希望在 2 周，甚至更短的时间内解决。”

他马上回我：“怎么可能？要快，就会降低质量，两者很难兼顾。”

我说：“我并没有限制你的方法，你可以尝试自动化测试，团队自己学，或者对外招聘有经验的人进来；如果你觉得是系统架构造成测试复杂度提高，那你可以跟工程师团队讨论如何调整架构；如果你觉得是产品设计有问题，那你可以去找产品团队讨论。我甚至没有说你不能跟项目经理沟通，可不可以先针对 80% 的用户上线，有这么多方法，为什么都不去尝试呢？”

经过这样的启发后，这名 QA leader 很快组织了自动化测试团队，也让原先的测试人员开始学习自动化程序的撰写，测试效率在半年间便有了很大的提升。

对于运维团队，一开始大夜值班同仁一个晚上会接到 2-3 通 on-call 电话，我说我们要在一个月内把频率降低到一个晚上最多 1 通，后来我们用两周的时间做到了。紧接着我说要把大夜的异常问题减少 80%，后来我们用 2 个月左右的时间做到了。过去我们找到一个异常问题，平均需要 15 分钟，我提出要在 3 个月内缩短到 3 分钟，后来我们也在三个月内做到了。

当我们不断的提出追求又快、又好的要求，并跟着团队一起实现它，过程中团队便会意识到这些事情原来是可能的，而且本来就应该是这样做的，这个价值就会深植于大家内心。

4. 追求更有价值

然而价值才是我们最终追求的东西，如果我们做的事情没有价值，那快与好的意义便失去了。所以在带领团队时，让每位成员清楚自己工作的价值是很关键的一件事，因为如果一个人不清楚自己做的事能为自己、为团队、为公司，甚至为世界带来些什么，他就不会对这件事具有热忱。

如果你无法清楚说明你手边每件事对公司的价值，那你其实就不应该做这件事。很多人之所以每天都有忙不完的事，就是因为例行事务，因为被别人交办事项，但他们却未曾思考，为何要做这些事？或者，除了这些事，难道没有其他更值得做的事了吗？

所以我们要培养团队的意识，在接收到每个任务时，一定都要提问或思考：

“这件事是源自于公司哪个策略？”

“是解决哪个问题？”

“能改善哪个数字指针？”

“能改善多少呢？”

“很棒的事，别人不做，我们要不要自己来做？”

这些问题看似尖锐，但却是关键中的关键，如果我们无法回答这些问题，又依据什么来判断工作的优先级呢？而为了让团队专注于更有价值的那些事，我们就要持续搬开那些阻碍我们前进的绊脚石。

当大家都明白，判断价值，价值排序的重要性，也理解应该持续追求又快、又好，并勇于面对各种问题与挑战，以主人翁心态，对结果、对团队、对自己负责，高效的团队文化便自然形成了。

过去几年，团队能产生大规模的组织、流程、制度的进步，背后都是因为团队文化已经被建立，否则要说服大家，并驱动数百人前进，难度是非常非常高的。

如果你正面临团队文化建立的问题，我建议你可以按这个步骤来落地：

思考企业的价值观是什么？而哪些行为符合这些价值观？

在这样的价值观下，你希望你所带领的团队有什么样的思维与行为？

与你的下一线主管进行价值观讨论，确保大家对价值观的认知是一致的。

不断在各种场合中，藉由案例来告诉大家你是如何解读这些价值观的。

持续的落实与检讨。

关于高效研发流程的那些事，这系列文章到此告一段落了，希望很快有机会能跟大家分享其他的主题，谢谢各位的耐心学习，若大家有任何问题想要讨论，也欢迎大家留言与我联系。

第54讲 | 打造高速运转的迭代机器：现代研发流程体系打造（一）

你好，我是爱范儿 CTO 兼知晓云负责人何世友，今天想跟大家分享的话题是“打造高速运转的迭代机器”。

现代移动互联网对研发流程提出的新问题

移动互联网时代的产品研发，基本上是两个特征，分别对应老板和用户的要求：

迭代速度再快一点，一分钟上线一个特性；

交付质量更高一点，半个 bug 也不能有。

而且没有上限。

而速度和质量，是一个肉眼可见的相悖的存在——速度快了自然要牺牲质量，质量高了自然要牺牲速度。但在移动互联网公司的意识形态里，再相悖，那也是把大象塞进冰箱的问题，因此也就对研发流程提出了新的挑战。本文试图就该问题分享我的经验所得。

正式解决前，我们伪随机地“采访”几位围观群众。

问：如何搞定更快迭代？

开发工程师：给我精确可实现的需求，我一人能干三人的活。

运维工程师：给我更多一点机器干活，我让机器随时随地跑构建、测试、部署。

其他各种师：大家高效沟通快速复盘，地毯式推进。

问：如何产出更高质量？

项目经理：迭代中各工序完整，涵盖各职责。

其他各种师：沟通全面无疏漏。

运维工程师：更多一点机器背锅。（滚……

所有人：产品、研发、测试、构建、部署各环节紧密关联，随时可回溯，随时可加入新人。

项目规模或大或小，周期或长或短，都是由一个又一个版本迭代构筑起来的。当我们在谈研发流程时，实际上在谈的，就是这不断重复的迭代过程。因此，打造研发流程，就是要打造一台高速运转的迭代机器。

打造迭代机器

工业时代的崛起，运转在工厂车间永不停歇的传送带是成功的基石。这条传送带贯穿了各个环节，配合精确的时间控制，最终形成产出效率最大化的流水线。纵观整个产品迭代周期，我们需要立即着手做的，恰恰就是找到这一条传送带。

那什么是研发流程里边的传送带呢？

迭代过程总览

一个标准的互联网产品的一次迭代大概长这个样子：

这个过程中，参与角色有：

PO（项目负责人）

PM（产品经理 / 项目经理）

Designer（设计师）

Developer（泛指各种研发岗位，开发者、架构师、运维等）

Tester（测试工程师）

各环节的交付物有：

Story（一段需求描述）

Product Document（产品文档、原型）

Task（任务，由各岗位在项目管理平台创建并维护）

Design（设计稿、交互稿、切图素材）

Test Case（测试用例，由测试工程师编写并发起评审）

Tech Design Document（技术设计文档，由开发者在开始编码前编写）

Code Commit（一次代码提交）

CI Build（持续集成系统自动化构建）

Test Run（一次测试）

Deployment （一次部署）

各环节与环节之间的转场动作有：

Review（审核、讨论、修改）

Acceptance（验收）

需要注意的是，这里的角色、交付物并非限定因素，各团队可以根据自身因素和项目规模应用不同的角色设定和交付物设定，大可不必纠结。

可以看到，一次可短至一天内完成的迭代，涉及到 5 种角色、10 种交付物，同时，每个角色之间、交付物之间，都会由各种审批和验收的动作填充。一眼看上去复杂到爆炸。

而我们作为技术管理者，需要将这些角色和交付物和动作管理起来，这是打造研发流程的基础。

现代化的项目管理工具

要做管理，必然离不开管理工具。项目管理工具在近 10 年里得到了很多厂商的青睐，纷纷投入研发力量，于是我们如今可以用上 Redmine、Jira、Trello、Tower、Teambition、Worktile、禅道等各种工具。

其中，受 Trello 的影响，近些年的项目管理工具多实现的是简洁的“看板”管理方法，成品往往具有简单好用的特征。老牌的 Jira 则同时支持 Scrum、看板（Kanban）管理方法。Scrum、看板均是敏捷开发流程的实现，并不存在特别大的区别，各团队可以根据自身的喜好选择，这并不是重点。

但如果项目管理工具还只是让项目中的各角色在上边手工创建、更新任务卡片，那一定会成为项目推进中的阻碍。现代项目管理工具一定要将交付物管理、串联起来。管理工具的目的是为了维护任务状态，而任务状态事实上是实际任务完成与否的反映。也就是说，管理工具需要具备从交付物所在平台获取动作事件，将其转换成任务的流转，并完成任务状态更新的功能。

比如说，工程师的任务是写代码，当他做了一次代码提交，就意味着这个任务完成了，如果还需要他手动去任务管理平台更新任务状态，就比较多余。因此，任务管理平台需要具备从代码仓库获取代码提交事件的能力，并自动更新对应的任务状态。

可以说，项目管理工具就是上文提到的研发流程里的传送带。

这条传送带承载了任务的流转，更需要承载一个任务所有交付物的关联。一个任务，包含产品原型文档、设计稿、技术设计文档、代码、测试用例、测试结果、CI 构建、部署等诸多交付物，把这一切串起来，可以解决什么问题？

回溯。

可回溯的迭代

“得益于”不断提速的迭代流程，互联网项目的代码腐化速度，早就从年提升到月。一个“正常”迭代的互联网产品，即便立项时的架构设计文档写得再细致出色，每次迭代时的代码写得再易读注释清晰，3 个月后，来一个新人，一定搞不懂为什么代码会写成这个鬼样子。

为什么？

因为无法追溯。

代码的每一次更改，都是在响应当次迭代的产品变更。虽然每一次产品变更都可以通过产品原型的更迭得到留存，但因此导致的代码更改乃至架构微调，却无法产生对应关系。

那通过任务管理平台来关联产品变更和代码变更呢？这样每一个产品变化导致的代码变化以及当次的测试、构建、部署结果都是串起来的，当需要回顾事故现场时可以将这些关键交付物拿起来看。应该可以解决所有问题了吧？

还不够。

不断迭代的技术架构设计

虽然可以通过这些元素的串联还原当时的迭代详情，但依然可能出现搞不懂代码为什么写成这个鬼样子的困惑。因为已有元素的提供，可以搞清楚代码变更的罪魁祸首，但无法还原现场。在此，需要的是完善的、不断迭代的技术架构设计文档。

举个例子：电商业务产品想增加送礼功能，用户 A 下了一个订单付完款，用户 B 填写收货地址。产品变更简单，增加一个用户 B 更新地址的流程就可以。但对应的代码变更则大了去了，这一个礼品功能的增加，可能直接导致订单架构的变化。这时候如果没有技术架构设计文档的补充，对当时的需求进行分析和架构变更设计进行记录，产出的代码一定是不好理解的。

现代的软件工程构建，再也不是一座桥梁的构建模式——蓝图画好了就打死不改。代码可以不断迭代，同样的，蓝图，也就是技术架构设计也应该不断迭代。而设计文档，就是技术架构设计的迭代交付物，在整个迭代过程中，至关重要。

至此，迭代过程可以做到完全可追溯，这对保证项目质量起到非常大的作用。一个新人刚加入项目，不管是从代码提交记录，还是从设计文档的修改记录，还是从每一次构建部署的记录，都可以追溯到关键节点。如此一来，项目的生长轨迹，再也不用依靠老同事的口耳相传得以维系，其腐化速度也能得以缓解。

一个快速迭代成长的项目，就需要这样的基础。在这个基础之上，如何快速推进？须知，参与项目的不仅有人类角色，还有各种交付物所在的系统——在线文档协作平台、代码仓库、测试用例管理平台、CI 构建平台、自动化部署平台等。这些角色 / 机器之间，也需要沟通。

沟通，不仅是人和人

迭代中的沟通，一般有这么几种需求：

角色之间的沟通，讨论、约定、解决冲突；

群组内的沟通，头脑风暴、计划宣布等；

就某一话题进行多人沟通。

沟通工具要满足的条件之一，就是所有沟通结果可留底用于未来追溯。因此重要的信息，邮件依然是最佳选择。通常在项目启动、验收等关键时刻，邮件确认是最合适不过的。

平日的沟通交流，则以效率优先，大多数是发生在即时聊天工具上的。微信提供了非常便捷的讨论组功能，外部联络时非常高效，可以瞬间圈起公司内外相关人士进行畅聊。但日常工作中，很多时候会有临时的话题需要进行多人沟通，沟通完就散。

举个例子，#codereview 群组里，CI 构建系统发了一条最新的测试失败消息，相关的开发者需要就这一个失败进行讨论。直接在 #codereview 群里讨论吧，消息一多就冲垮了，有噪音；拉一个新的群组吧，又太费劲了。这种情况下，Slack 提供的 Thread 功能就能派上用场。

此外，研发流程里参与的角色一半以上都是机器 / 系统，因此，沟通工具优先要满足的，其实是如何让机器和人对上话——这就是现代沟通工具的特征。在同一个沟通工具里，人类角色可以像和其他人类角色沟通一样和机器沟通，如接收机器的通知（如上图所示，有代码提交的通知、告警通知等）、向机器发送指令等。

用机器打造迭代机器

项目管理平台这条传送带，让一次迭代里的各个角色、任务可以快速进行流转，并从流程上充分利用时间、减少损耗。一个需求，粒度划分越细，就越可以做到精确可控。然而，一次需求从代码到上线，这中间的过程是漫长的——

编码⟹静态检查⟹单元测试⟹测试⟹代码审查⟹构建⟹部署⟹运维……

我们要做的，就是尽可能的自动化，让机器包揽所有能干的活。这样一来，迭代过程，不仅可以无误差运转，甚至连运维的工作都可以更加高效——

编码【人类才智】⟹静态检查【机器】⟹单元测试【机器】⟹测试【机器】⟹代码审查【人类才智】⟹构建【机器】⟹部署【机器】⟹监控【机器】⟹自动扩（缩）容【机器】。

除了两个必须要人类参与的步骤，其他环节机器均可以胜任。

可能有人会问：研发团队写这一套自动化流程，得花多大成本（时间、金钱）？是不是和研发产品缘木求鱼了？答案是磨刀不误砍柴工。

至于成本嘛，感谢开源社区和相关服务提供商，几乎都是现成的、可以花合理价钱买到的。篇幅有限，这里我就不展开了，下一篇文章我将跟大家简单说说各环节的现有解决方案及选型，敬请期待。

研发流程是一个团队打造产品的过程，这里边一个最基本的性质就是生长、不断的生长。而产品快速度、高质量的生长离不开高速运转的迭代机器，本文就迭代机器的打造给出了我自己的经验与答案，存在疏漏在所难免，欢迎大家在评论区提问讨论。

作者简介

何世友，爱范儿 CTO TGO 鲲鹏会广州分会董事会成员，学习委员。从校园创业到跨国团队技术顾问再到如今，专注于高并发网络、机器学习、移动 APP（部分硬件）、团队管理。

第55讲 | 用机器打造迭代机器：现代研发流程体系打造（二）

你好，我是爱范儿 CTO 兼知晓云负责人何世友，今天想跟大家继续聊聊“打造现代研发流程体系”这个话题，并将着重跟大家分享其中“用机器打造迭代机器”这一部分内容。

在上一篇文章里，我们分析了研发流程中的关键环节，并给出了对应的解法。它们分别是——

1. 高速运转的传送带

现代化的项目管理（任务流转）工具。

2. 可追溯的迭代

通过传送带，将每一次迭代的产物，如代码提交、架构设计变更、测试构建部署等串联并存储起来。

3. 重要角色的沟通

用一个通用平台，如 Slack，在解决人与人之间通讯的基础上，重点解决系统工具与人之间的沟通问题。

4. 用机器打造迭代机器

受限于文章的篇幅，上篇文章中只是简单说到了因为迭代的步骤很多，所以要让机器包揽大部分环节，估计很多读者并不能十分感同身受。本文将对此做详细解释：为什么要用机器打造迭代机器？

迭代频率越高，对迭代里的自动化程度的要求就越高。打个简单的比方，如果项目要求一天迭代两次，测试工程师就要一天走完两次主流程回归测试。此时，人工就是最大的瓶颈。一个项目分分钟有成千上万个用例，依靠有限的测试人员分拣完成，那就是纯体力活了。而对质量的要求越高，主流程的覆盖范围就越广。单就这一个环节，如果没有机器的参与做自动化，就会成为一个不可调和的瓶颈了。

之前提到，构成自动化流程的大部分工具都是现成的、可以花合理价钱买到的，本文就将重点介绍研发流程里的各种工具们，以及不同场景下的具体选型。由于这些工具被正确配置完成之后，拥有脱离人工干预在不断电的情况下自我运转的能力，我们亲切地称之为迭代机器里的机器们。

迭代机器里的流水线

编码【人类才智】⟹代码审查【人类才智】⟹静态检查【机器】⟹单元测试【机器】⟹测试【机器】⟹构建【机器】⟹部署【机器】⟹监控【机器】⟹自动扩（缩）容【机器】。

这是一个环环相扣的流水线，每一个步骤都由一个机器角色完成并推送到下一个步骤，最终完成全程；一旦其中一环无法完成，则本次迭代就宣告失败，需要返工。

通常这样的流水线跑在 CI 系统上。CI 系统，Continuous Integration，持续集成系统。常见的 CI 有 Jenkins、Bamboo、Solano CI 等。这些系统各有千秋美丑，本文不赘述对比，各位可根据团队背景和成员喜好进行选择，只需要看这个系统是否具有真正意义上的可定制拓展性，以及规模可观的第三方服务的接入支持。

下边将围绕流水线中的几个重要环节进行描述。

静态检查、单元测试、构建

静态检查、单元测试和构建环节发生在每一次代码提交之后，由代码版本库的代码提交事件触发执行，如 Github、Bitbucket、Gitlab 的 Webhook 等。

1. 静态检查

静态检查由各语言的语法 Lint 工具和 bug 检查工具组成，前者包括 JS 的 eslint、Python 的 pylint 等，后者包括 Java 的 findbugs 等。

2. 单元测试

基本上每种语言、每种框架都有支持单元测试，如 JS 的 Mocha、Python 的 unittest、Java 的 JUnit、Go 的 testing 等。工具本身都是比较类似的，各语言开发者都应该很熟悉。难在代码编写时的测试用例覆盖，这是一个需要仔细权衡覆盖度和时间的过程。

在实践中，比较推荐的是，让测试工程师参与到单元测试编写中来，每一次项目的测试用例评审，一部分用例一定要转化为开发工程师的单元测试。或者说，测试工程师需要参与到开发工程师的单元测试审查和覆盖率评估中，对应的，开发工程师也要参与到测试用例评审中。这二者相结合，黑白盒、单元集成测试才能真正有机的为项目质量负责。

3. 构建

构建（Build）是需要开发工程师根据项目的部署策略编写对应的构建打包脚本。例如前端的 webpack、后端的 maven、客户端的打包等。不过基本上要做的事情就是将原本由工程师在本机上跑的脚本移植到 CI 系统上，这个过程本身不带来多少成本。

自动化测试

自动化测试由测试工程师维护，由两块工作构成：测试用例管理、自动化测试脚本编写。

1. 测试用例管理

测试用例管理流行的工具有 Excel、Qmetry、TestLink 等。没错，Excel 在众多公司中依然是管理测试用例的好工具。当然在我们讨论的场景里，Excel 已经不堪其用。管理测试用例，是为了让测试用例和对应的需求描述，也就是 User Story 关联上。从而让每一轮测试执行，也就是 Test Run 的结果，不论是成功或失败，都自动回传到关联的任务状态里。

同时，平台级的用例管理，可以让用例迭代起来，和项目一起生长，这和前文提到的架构设计文档的迭代一脉相承。甚至，用例要作为项目推进中的自动化测试的组织枢纽，串联起自动化测试和实际任务的状态流转。

2. 自动化测试

这里的自动化测试，主要指的是黑盒测试和集成测试，和开发工程师维护的单元测试做一个区分。常用的框架有 LoadRunner、Selenium、Appium 等。这是一个十分耗时耗力的过程，常见的做法是梳理经过每一次迭代的测试用例，最终形成一个主流程用例集。

主流程的特征是产品特性基本稳定，不会在短期内有较大改动。测试工程师需要对主流程的测试用例进行测试覆盖，例如通过 Selenium 进行 UIUE 的用户交互过程录制等。而有了主流程的覆盖，每次迭代的发布，才能够真正的做到 push on green。否则，每次发版还得测试人员手工回归确认，那基本就是一个跨不过去的时间鸿沟了。

部署、监控、自动扩（缩）容

1. 部署

Devops 的兴起让运维得到解放，Docker 的流行也让社区疯狂，似乎非 Docker 不可，不上容器不是好技术团队。其实不见得。重要的是达到目的，而非工具，一定要根据项目实际情况进行技术选型，不要因为一种便利引入额外的麻烦。

目的是什么？目的是让机器自己完成自动化部署。

而通过前面介绍的工作，CI 流水线上已经有了经过完整测试的构建产物，于是部署阶段只剩下：

开启并初始化机器，并完成系统环境配置，通常可以用预先准备好的镜像文件完成该步骤；

上传构建产物到机器上，启动服务；

将流量或任务分发到新的机器上；

下线旧的机器。

这里边有机器的运维、服务的部署、负载均衡器配置等，每一项业内都有非常不错的工具可以用。比如我们在爱范儿目前用的是——

使用 Ansible 完成环境的自动配置，结合 AWS 的 ami 镜像完成机器运维部分；

使用 Fabric 结合 AWS 的 CodeDeploy 完成的部署流程，并在此基础上完成了 Auto Scale。

AWS 的 CodeDeploy 非常好地利用了 AWS 的基础设施，可以一键完成上面提到的 1、2、3、4 这几个环节。而在使用 CodeDeploy 之前，团队写了一系列脚本去做这块的工作。

Auto Scale 常见的做法是在监控系统里定义一系列的 Metrics，设定阈值，比如，“过去 2 分钟内机器 CPU 达到 60% 以上”就是一个完整的阈值条件定义。然后为这个阈值配置一个动作，比如“过去 2 分钟内机器 CPU 达到 60% 以上，部署并上线 4 台新的应用服务器”。而怎么部署并上线新机器就是上文的 CodeDeploy 的活儿了。

2. 监控

监控分异常监控和性能监控。

异常监控配合日志收集器工作，如前端的 Sentry，后端的 Cloud Watch（AWS）、loggly 等。基本的工作原理是从日志中获取错误信息，并进行统计，达到设定的阈值就开始报警。异常监控系统经常对接的是电话告警系统，为 OnCall 的工程师提供错误叫醒服务。

性能监控分微观和宏观两个维度：

APM 探针实时收集应用服务器代码层面的性能信息；

机器状态（cpu、mem、load）、应用服务响应时间等。

这两者结合可以无死角反映服务状态，对接到 Auto Scale 系统后可以在大多数情况下完成自动化运维。

APM 探针服务，常用的有 NewRelic、AppDynamics 等，国内也有听云、OneAPM 等一众厂商。区别基本上就是价格和第三方支持完备度，近些年各大云服务商也在做这些周边支持，选择上并不是难事。也有一些团队将机器状态等信息归到异常监控里，而我们归到性能监控，主要是站在能否让机器自己治理的角度。毕竟，放到异常监控，OnCall 的工程师更容易醒，但醒了不也是要做 Scale 的事情嘛。

说到这里，大家在迭代流水线中的各个环节上都用了哪些工具呢？欢迎在留言中告诉我们，供大家参考。

一些待完成的和待思考的

然而，一台高速运转的迭代机器中，人类角色才是真正的瓶颈。或者说，高速迭代对人员的要求会更高。因此，团队的成长便更为重要，也更值得探讨。坊间有一句话，互联网公司都是轻资产，值钱的就是人、流程、代码。

那如何打造一个高速成长的团队呢？希望有机会可以和大家探讨。

作者简介

何世友，爱范儿 CTO TGO 鲲鹏会广州分会董事会成员，学习委员。从校园创业到跨国团队技术顾问再到如今，专注于高并发网络、机器学习、移动 APP（部分硬件）、团队管理。

第56讲 | 有了敏捷开发，那交付期限去哪儿了？

你好，我是明道创始人任向晖，今天想跟大家分享的主题是敏捷开发中交付期限控制的问题，以及其他行业带来的启发。

今天，软件行业已经无人不知敏捷开发，实践者也不局限于互联网产品公司，即使是传统软件开发团队，也十分愿意采纳敏捷开发。温和的看板之于严苛的期限，当然前者要友善得多。SCRUM 能够得到普及，和它宽慰人心的作用是分不开的。

敏捷开发宣言

敏捷开发思想的确在改变软件行业面貌。它让小型团队可以摆脱过于笨重的项目计划，让产品设计和开发避免闭门造车，不至于让程序员的青春年华浪费在那些因为失败而没有投入使用的软件项目上。

它同时也推动了需求方和开发者之间的持续透明沟通，让团队开始意识到，高频度的沟通是提高软件交付质量的原动力。敏捷开发还将工作的起点转换到客户的具体问题解决上（User Story），而不是从一个看似完善的产品需求文档出发。

2001 年，17 名软件工程师发表了著名的敏捷宣言，全文只有聊聊数十个字：

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动   高于 流程和工具
工作的软件   高于 详尽的文档
客户合作   高于 合同谈判
响应变化   高于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

在应用敏捷开发的数年中，我们自己从中得到了很多的收益。作为 SaaS 软件产品，采纳敏捷开发模式几乎是从本能出发的。至少，我们没有和客户的合同谈判，也并非为特定客户交付一个软件项目，而是自始至终地改良属于自己的产品。

在相对稳定的冲刺周期内（2-4 周），交付短期可估量的特性通常不是很大的挑战，即便有 1-2 天的延期和缺陷修复，看起来也没有严重的商业后果。

期限之殇

但软件开发行业的大部分从业者其实并不是产品开发者，而是服务于提供 IT 服务的外包开发商。他们按照合约的要求，需要在固定的期限之内给客户交付可用的软件。敏捷开发宣言似乎并不能完全打动他们的客户，因为期限不仅是开发合同的要件，还会直接影响客户的业务运营。在一桩典型的外包开发项目上，的确很难应用敏捷开发模式。

即使是像明道这样的产品型公司，也不能完全通过敏捷开发模式来覆盖所有的开发活动。对于全新的重构、大型版本的迭代、技术债的偿还、复杂的特性交付等情况，就几乎不可能在 2-4 周的时间范围内达成。我们经历过的最漫长迭代周期超过四个月。虽然这当中肯定有决策失误的原因，但没有产品能够完全幸免这样的遭遇。即使像 Salesforce, Asana, Atlassian 这样的高水平 SaaS 产品企业，都有过那些结果糟糕，却又不得已为之的长跑型迭代。

这张图是敏捷开发模式下典型的任务板模型。乍一看是非常直观且有效的开发管理模式。但它只能支持日常特性迭代，在固定周期内完成合适数量的 User Story。而且，在 In Process 这个狭窄的看板中，其实掩盖了过程控制问题。如果这个 In Process 不能在 1-2 周内完成编码和单元测试，整个冲刺就高概率地会失败。

SCRUM 方法要求在这种情况下进行复盘，找出项目延期的原因，在下一次迭代中针对性改善。但从很多产品团队的反馈来看，这个原因通常总是被归结为 User Story 放得太多了，或者定义得太模糊了，而很少有去复盘设计开发过程中的进度控制问题。

所以，SCRUM 在带来价值的同时，并不能天然地保证团队准时的交付。而如果要做到准时交付，团队也不能通过牺牲特性交付量来实现，因为企业永远受团队协作、销售业务需要、竞争等要素的压迫。

无论是传统的开发项目，还是敏捷开发项目，我们到底应该怎样来实现高成功率的进度控制呢？

其他行业的启示

要为软件行业找到按期交付的办法，我们可以从其他对工作交付期限有更高要求的行业中寻找灵感。在众多行业中，建筑工程管理和按单制造业是符合要求的两个行业。

建筑工程受制于客户合约、租赁器材的高成本、人员计划的约束等因素，对于项目执行的节点要求非常高，项目或者项目内的大节点延期会带来大额的损失和违约风险。完整的建筑工程项目计划大多用甘特图绘制完整，其中包含任务的前置关系、资源的约束，并且项目计划被允许保存为基线，用来和实际进度定期比较。

同时，通过专业的项目管理软件（例如 Project），项目经理还要识别出众多任务中的关键路径（Critical Path），在关键路径上的任何任务延期，都会导致整个项目的延期。相反，如果一个任务不在关键路径上，那么它可能有一定的缓冲空间。

按单制造业根据客户性质的不同，按时交付的刚性有所区别。但整体上都面临客户合同的约束，即使延期也必须在合理范围内。如果是在工业上游的制造业，他们面临的交付压力就会非常大，因为一旦延期交付，影响的是后续供应链的生产计划。想象一下苹果公司对富士康等装配企业的要求，再想象一下富士康因此给上游材料、工具、模具等制造企业的交付要求。

因为这两个行业面对的现实挑战，他们自然会因为内在的压力形成一些有效的做法，来实现更可靠的按期交付率，这些方法和原则可能对软件业有所启发。

1. 专业的 WBS 分解

如果打开一个建筑工程项目管理文件或者一家模具制造厂的工单分解和排程表，外行肯定像看天书一样，因为你没有受过工程专业训练，不了解各门类产品具体的生产工艺和制造程序。反过来说，如果这两个行业的任务和里程碑分解结果你都看得懂，那就说明它无法起到真正的过程管理作用。

对于外行来说，也许最多能够猜测出来的建筑工程里程碑就是打地基、结构封顶、内装修和外装修了。但这些所谓的里程碑每一个都可能需要数个月的周期才能达成。而实际上，一个普通民用建筑的里程碑就需要数十个分部分项专业才能列举完整。

分解的 WBS 任务有大有小，建筑业的最小工作包从一两天到一两个月不等。无论长短，它都有一个专业衡量，即便它来自的是经验判断。一座小型建筑的施工准备是 2 天，土方开挖和基底清理要 20 天，楼层主体每层要 20 天，这些预计工期在行业内已经成为显性的知识。

专业的任务分解、工期预估、流程次序和里程碑定义是进度管理的基础，有了这些信息，我们才能够实现第二步——持续跟踪。

2. 持续的进度跟踪和关键里程碑

这两个行业都有高密度跟踪进度的实践，而且大多有专人负责。建筑业一般在项目部有施工日志要求，并依据日志通过专人来负责更新进度表，制造业则有每日站会（一般就在车间里）和生产经理来管理排程。

进度跟踪的基本逻辑在两个行业有所不同。建筑业通过原有的基线对比，来准确协调各分部施工方、分包商、材料供应商和施工人力资源的准备、入场和验收。准备完成、入场和验收完成是建筑业各个分部分项工作的核心里程碑。

制造业则紧紧围绕工件，依据工件在制造程序上的流转来确定进度，如果进度滞后，则要及时修改剩余的制造程序排期，所以大体可以认为工件在单个制造工序上的完成是制造业的关键里程碑。

3. 遇到问题后的快速会商

软件行业中的从业者，经常被一件事情困扰，那就是需求的不明确和经常的变更，尤其是自有软件产品开发项目。很多软件开发的延期会将责任归咎在需求的含糊和变更上。

我以前总以为像建筑工程这样的项目不太会有经常的变更。设计图纸和施工工艺一般不存在含糊的情况。事实看起来的确是这样，一座机场可容不得在开工了一半的情况下突然决定增加一个候机楼。但是，这并不意味着其他行业不存在变更和其他意外的问题。

实际上，局部的施工修改和变更随时都可能发生，施工中遇到的实际环境和设计条件存在差异，因为环境、设备、材料、人员能力和工艺有效性带来的突发问题层出不穷。制造业甚至总结出了“人、机、料、法、环”（分别指人员、机器、材料、方法和环境）这几个生产影响要素。

那么遇到问题该怎么办呢？从这两个行业观察到的方法和我的本能直觉一致——集体会商！

制造业的现场管理和站会不是没有道理的。在生产过程中发现和产生的问题，最好的解决办法就是在制造现场，站在车间里解决。建筑业也是一样，除了工程师可能要带上安全帽进入施工现场以外，工程项目部也永远都设在施工现场一两百米的距离之内。

我在采访一些工程项目部的时候，发现所有的项目部经理办公室都有一个大大的沙发区，项目经理很难离开这个现场，因为他们随时要召集不同职能的人会商问题。

总结一下，专业的 WBS 分解、持续的进度跟踪和关键里程碑，以及遇到问题后的快速会商，从建筑工程业和按单制造业这两个行业总结出的这三个要点看起来非常简单，也不难理解。但反观我们的软件业，在全行业拥抱 SCRUM 的同时，似乎丢失和忽略了一些原则。这也许就是我们管理交付期限更为困难的原因。

受限于篇幅，本期主要跟大家分享了敏捷开发中项目期限控制的问题，以及其他行业带给我们的启发，下期，我将跟大家分享软件业具体该采取的做法。感谢您的收听，我们下期再见。

第57讲 | 敏捷中的期限之殇，软件业该怎么做？

你好，我是明道创始人任向晖，上期内容跟大家分享了敏捷开发中项目期限控制的问题，以及其他行业带来的启发。今天，想跟大家聊聊想要更好地控制项目进度和周期，软件业该怎么做？

1. 将进度要素纳入敏捷开发

其实敏捷开发宣言中也并没有完全抛弃进度，它只是说响应变化要优先于遵循计划。而因为迭代更新的周期相对稳定（2-4 周），所以看起来敏捷开发模式没有延期的问题。再不济也是割舍了一些完不成的特性，作为一个不算成功的迭代来复盘。

预测在 2-4 周内能够完成的特性开发量相对容易，稍有经验的 ScrumMaster 都能够基本估准确。但并非所有的软件开发迭代都是这么短的周期。在新版本开发、复杂的企业 SaaS 特性开发中，一个迭代经常需要超过一个月，再加上必要的测试和灰度发布，可能轻易超过两个月。我统计了一些常用 APP 的版本更新历史，发现 80% 以上的 APP 更新频度在两个月以上。

所以，我们必须要把进度要素重新纳入敏捷开发的管理范畴内。

这意味着，看似简洁的 SCRUM 开发看板，在 In Process（开发中）这一栏中的任务内容，需要建立另外一套计划和跟踪系统才能实现更可靠的进度控制。

而在敏捷开发之外，传统的软件开发计划和建筑工程项目管理相比，大多也欠缺详尽的进度计划，而只是笼统的定义了几个粗放节点。如果是业务部门人员和外包客户达成协议，软件工程人员往往在交付时间要求上缺少发言权。很多软件外包项目的所谓开发交付计划都是根据客户要求的时点往前倒推而已。很多时候，别说客户了，就连自己人也很容易拿交付的时点来倒逼开发团队。

是不是应该倒算排期是一个很难回答的问题，企业总是面临客户的需求压力和竞争压力。问题的关键不在于交付期限的来源，而是有了交付期限以后，我们应该怎样细分软件研发工作的关键里程碑。

2. 软件研发的关键里程碑

软件研发的里程碑到底应该怎样定义？我相信这个问题很多研发团队都做过探索。按照设计交付、编码完成、测试发布和验证发布这样的粗线条节点划分虽然容易，但对进度管理并没有实质性的帮助。而且，对于敏捷开发项目来说，设计交付甚至都不是一个一刀切的工作，有一部分细化设计工作完全可能在编码工作开始以后再进行。

当我们从建筑工程行业寻找灵感的时候，发现他们的关键里程碑是各个分部分项工程的准备、入场和验收，而且每个分支工程所需要的工时在计划时能够比较准确地衡量。虽然软件开发远远没有建筑工程的分工项目那么多，但是要做到可靠进度管理的基本前提是一样的。

制造业的规律也同样提供了线索。工件在工序上的转移是一个明确的物理过程，进入 B 工序的前提是完成 A 工序，每个工序所需要的工件加工时间只要能够被精确衡量，整个制造过程所需要的时间和资源就能够被事先计划清楚。而这个计划过程是在工件进入加工之前用专门的排程工作事先完成的。

那软件业如何采用类似的思想来提高自己的进度管理水平呢？

首先，软件开发要根据前端开发、后端开发和测试的主要专业分部建立细化的专业里程碑。一般前端开发工作依据设计阶段产生的页面来清点前端组件开发工作量。在模块化开发的过程中，还要注意对通用组件的合并归纳。一般而言，页面数量越多的应用，前端开发的工作量越大，模块化程度越低的项目，工作量越大。后端开发则根据数据对象和功能特性的设计来细化出接口列表和数量。如果不涉及特殊计算，大部分企业应用的开发工作量和接口数量成正比。而黑盒测试所需要的时间则和以上前后端开发量的总计成正比。

理解了这个规律，再复杂的软件开发项目也可以像建筑工程那样列出整个开发测试工作的关键里程碑。

在分割这些里程碑的时候，达成里程碑所需要的工作时间一般要细化到一周工作量以内的颗粒度，否则开发过程中的按周检查就失去了意义。

那谁能够有这个专业能力来定义这些关键里程碑呢？其实和建筑工程一样，团队并不需要一个全能的高手，而是应该由负责前后端和测试工作的专业工程师一起评估给出。制定计划和执行计划的人如果是一致的，计划达成的概率就会更高。当然，因为前后端开发工作不可避免地需要相互协调，以确定科学的次序，所以这个制定过程总是依赖产品和研发人员的集体会议。但这样的会议因为目标清晰，就是为了产出里程碑列表，所以效率可以得到保证。

下图就是一个根据以上原则和方法创建的复杂开发项目关键里程碑列表。为了便于每周的检查和跟踪，特意没有做成甘特图模式，而是将里程碑项目根据期限进行分组，每组就是一周内应该达成的里程碑。开发小组在周末进行的检查完全基于这个开发进度计划。

按照这个方法，能不能根据迭代的总期限（比如四周）进行倒推呢？当然可以！而且，这样的倒推，才让敏捷开发中重要的响应变化原则得到体现。在没有可靠进度计划之前，产品研发团队对于一个迭代所需要装进去的开发内容总是容易产生争议，大部分争议集中在用户价值上。但是，用户价值是需要使用数据加以佐证的，在新产品、新特性的开发过程中，往往还没有足够的用户数据来帮助决策，这时候，特性功能对交付时间的影响就成了另外一个关键决策要素。

当我们不得不尊重一个大版本的交付总期限时，团队就能在细分到每周的开发里程碑表中找到均衡，更容易达成一致。有时候，团队会毫不犹豫地在开发计划中将某个特性划去，因为它极有可能带来整个项目延期的风险。

以上介绍的是在敏捷开发模式下的进度计划要素。这个基本方法当然也可以用于一个全新产品和项目的研发过程，只不过，这时除了具体的模块定义、接口定义和页面组件定义带来的开发工作时间计划外，还需要留下足够的项目整体架构时间。这些初始化的架构工作包括项目成员参与技术方案调研和论证、数据结构的初始化设计、通用类库的定义，以及在这个过程中和产品需求方的沟通工作等。根据需求来源的性质和清晰度差异，它们通常要占据团队 2-4 周的时间。

3. 跟踪、响应和及时沟通

制定和落实了进度计划，是不是就不会有意外呢？当然不一定。无论是自己的产品，还是客户的委托开发项目，变更有的时候是难以杜绝的。为了保证最终交付的质量，我们宁可冒险去接受某些变更，也不会对已知的失误无动于衷。

但接纳变更，响应变化的前提是持续对里程碑计划进行维护。让最新版本的里程碑计划能够体现出变更后的情况。和其他行业不同，软件行业一般不需要做完整的基线对比，所有的变化都应该反映在从今天往后的新计划中。从这一点看，对进度的控制并不破坏敏捷项目管理的基本原则。

此外，当周不能完成里程碑的原因不仅仅是需求的变更，还可能是开发过程中遇到的技术实现问题。我们永远无法保证研发人员事先已经掌握了所有的技能和知识，开发过程中随时可能会遇到成员的能力瓶颈和信息断层。解决这个问题的办法和建筑业、制造业一样——及时的会商。

开发人员有时会怯于提出问题，担心自己遇到的阻力会影响团队的进度，所以一个人闷头花了过长的时间，而事实上可能有更好的解决方案或者完全可以接受的变更。为了保证能做到这样的及时会商，团队可以约定在周中（比如周三下午）安排一次期中检查，由产品、研发和必要的管理层一起参加，主动去发现这样的执行瓶颈，以避免到周末的时候面对不得不被动接受延期的现实。当然，为了做到更高密度的跟踪，研发团队内部也应该坚持 SCRUM 开发要求中的每日站会。

所以，在研发过程中，跟踪进度、响应问题和及时主动沟通是保证进度的基本手段。

4. 按期交付的激励

最后，我们要谈一谈按期交付的激励问题。很多开发团队为了解决按期交付的问题，都设计过各种各样的激励计划，其中最常见的就是项目按期交付的额外物质激励或者假期奖励，名曰项目冲刺奖。甚至还把提前交付的时间长度作为奖励的一个变量。

从我们长期的研发管理实践看，这样的做法有百害无一利。因为，它会让管理的重心盯向结果，而不是必要的过程，从而忽略投入在那些让项目如期完成的原因上。

过度强调如期交付的奖励，会让团队成员忽略质量，不愿意花费时间在计划和沟通上，而且一定会制造研发人员和产品设计人员之间的矛盾。如果前者对交付时间负责，后者对用户满意度负责，这之间的冲突和撕裂是可以想象得到的。

最好的按期交付激励应该落到平时。如果能够细化到按周评估的里程碑，就给了我们庆祝 small win 的机会，按周的如期交付也是如期交付，同样值得奖励，甚至如果周四就完成了当周的开发里程碑，周五就可以是一个自由工作时间。

对于软件研发人才，更宝贵的激励是能力的迅速提升。如果研发成员都参与过进度计划工作，尝试过科学拆解研发里程碑，他们将来的能力将不仅仅是更出色的程序员，而是能够管理更复杂项目的主管人才。

这种体验，只要是做过相关工作，尝到过胜利果实的研发人员都能够迅速体会到。这就像在足球赛场上，赢得最终比赛是激励，但除此之外，如果球员能够组织一次有效的进攻，赢得一个进球，或者成功化解和阻挡一次险恶的进攻，这些都是非常有效的激励。

最后，你们是如何控制项目进度和交付期限的呢？欢迎在留言中告诉我们。感谢您的收听，我们下期再见。

第58讲 | 如何打造个人技术品牌？

你好，我是余晟，一个老程序员，一路坎坷走来，积累了些技术品牌和演讲的经验，今天，想跟大家分享该如何打造个人技术品牌。

技术品牌，它到底是公司的资产，还是个人的财富？

我们都知道，公司有了技术品牌，在招聘方面会获益良多。那么个人的技术品牌呢？它能给个人带来什么？起码就我的经验，个人技术品牌有几点收益是相当明显的。

1. 个人技术品牌降低了你找工作的难度

我至今仍然庆幸，自己刚工作不久就发现了一个秘密：有些人找工作不靠投简历，全靠朋友介绍。后来更是发现，好工作往往也不公开招聘，全靠有熟人引荐。那么，上哪里去找那么多的熟人呢？一个人的精力和交往范围有限，这时候技术品牌就显示出强大的辐射力了，如果你之前研究过相关的领域，网络上可以检索到你的研究成果，而且这些成果是靠谱的，那么即便没有熟人背书，其他人也会认为你是靠谱的，好的职位也愿意为你开放。

2. 个人技术品牌拓展了你的交往范围

如今每个人的时间都很宝贵，有时候明明两个人很聊得来，深入聊下去会碰撞出许多火花，但因为素不相识，很难在初次见面就找到沟通频道，所以擦肩而过。如果有个人技术品牌，你的每一篇文章、每一次演讲，都是你的副本，都可能被人认识、记住。所以初次见面，寒暄上一两句，人家可能就会说：我看过你关于某某的文章，我是这么想的…… 这样，打交道自然容易很多，也容易建立起信任。

3. 个人技术品牌可以提供额外的职场保护

大家都知道职场凶险，翻脸比翻书还快，卸磨杀驴、兔死狗烹的事情并不罕见。如果很不幸你遭遇了这样的事情，当然可以求助媒体和劳动仲裁，只是结果不一定乐观。但如果你有个人技术品牌作为后盾，对方多半心存忌惮，动手之前总要仔细掂量掂量，不敢把事情做绝。或者即便下了黑手，你也不会吃闷头亏，总能讨来几分公道。看看近年的几个例子，你就会知道我所言不虚。

既然个人的技术品牌有这么多好处，怎么做才能建立它呢？其实无非靠两样本事：写作、演讲。偏生大多数技术人都很内向腼腆，无论写作还是演讲，都不是天生就有优势的。所以在这里，我提供一些可行的经验来供大家参考。

1. 写作从翻译开始

对我们大多数人来说，写作一直是让人头疼的。经常有人问我：写作有什么秘诀吗？其实没什么秘诀，就是要多写。但他们会说：我就是写不出来…… 既然如此，那就从翻译开始吧。大家起码能阅读技术文档，能就技术文档和同事交流，所以翻译的难度不会太大。 在翻译中要注意以下几点：

第一，翻译和阅读不一样，翻译对原文的理解要求更高，否则可能发生错漏而毫无觉察，所以最好从自己熟悉领域的资料开始翻译，这样更有把握；

第二，翻译完成之后不必立刻发出来，可以过几天再以“没读过原文”的心态仔细看看，确保读者能看懂，发出来之后当然还可以再修改，但原始版本可能已经四处流传了；

第三，翻译时可以加上一些自己的观点和评论，如果能把技术和自己的实际经验结合起来就更好，纯粹的翻译不容易凸显自己的特点，对中文读者的参考作用也有限；

第四，记得在每次发表翻译稿时注明自己的身份，可以借助其他的平台，但尽量不要做这些平台上无私贡献流量的无名氏；

第五也是最后一点，一旦开始做就要持之以恒，如果能就同一主题翻译十篇以上有份量的文章，无论是对自己理解的加深，还是对技术品牌的塑造，都是非常好的。

2. 技术写作要真诚严肃

如果已经熟练翻译，就可以开始尝试自己原创技术文章了。这时候要注意的是，态度必须真诚严肃。

有许多人希望建立自己的技术品牌，做法却非常虚浮潦草：或者是无责任转载，或者是浮光掠影走马观花，即便想认真做点介绍也是囫囵吞枣。其结果就是，当大家在网上搜索某方面的技术文档时，看起来资料很丰富，点开一看却发现每篇文章都大同小异，一些错误以讹传讹，感受非常差劲。

这正是目前中文技术文档的现状，所以久而久之，大家都养成了差不多的习惯：不但要看文档的标题，还要看文档的出处，是不是来自靠谱的作者、靠谱的团队。如果是，才点开。但这也意味着，如果你建立了良好的技术品牌，是很容易被广泛认可的。

所以在技术写作时，务必保持真诚严肃的态度。所谓真诚，是指不浮夸、不吹嘘，做了八分绝不说成九分，懂了五分绝不说成六分，不懂的可以承认自己不懂，或者给出解释并标明是猜想。

所谓严肃，指的是讲逻辑、讲证据，我自己在写技术文章时，常常发现自己之前解决问题的思路竟然是有问题的，或者有一些资料理解错了，或者拿到的证据已经过时，于是需要重新查证、理顺思路。在这个过程中自己的认识深化了，最终的结果也得到读者的广泛认可：原来这类问题，看这篇文章就足够清楚了。

3. 写作过程中务必多交流

技术品牌虽然好，但很多时候它属于“自找麻烦”，因为它并不是技术人的必须选项。于是，建立自己技术品牌的道路必然是孤独的，半途而废的例子我实在见过太多了。所以，有志于建立自己技术品牌的人，当然应当加强交流、互相协作。

具体来说，看到其他人高质量的劳动成果，应当表示赞美，即便其他人“抢先”发表了翻译稿或者意见也不要愤恨；在论述相同主题时，如果借鉴了人家的成果应当大方说明，即便没有借鉴甚至观点都不同，也可以以“延伸阅读”或者“参考阅读”的形式链接过去；如果发现其他人的论述比自己的更高明，甚至指出了自己的错误，也应当大方承认不足，以学习心态虚心对待。

如果能做到上面这些点，自己的技术品牌就不是茕茕孑立，就不是单纯凭快、新、奇、孤傲赢得观众了，还有来自其它技术品牌的延绵活水。同时，你自己也会被更多的技术品牌创造者所接纳，进入他们的圈子。圈子的温暖，圈子的力量，圈子所能提供的视野，都远远大于埋头苦干的个人。

4. 技术演讲要循序渐进

与写作相比，技术演讲是更高的挑战，也会带来更多的好处：鲜活、形象、有现场的互动，后续还可能有媒体报道。

但是演讲的难度也更高：写作可以反复加工，直至拿出成品为止，演讲却没有反复上台的机会。写作可以不必直面观众，以文字作为中介，演讲却必须与观众做直接沟通。 不过这些都不会是太大的困难，通常来说，要成为演讲者，应当注意下面几点。

第一，舍得削删。写作是比演讲更为自由的，空间也更大，所以写作时往往可以对某个主题做大而全的论述。但是演讲的时间有限，观众的注意力和耐心也更有限。所以设计演讲稿时务必对写作的内容做大的削删，去掉细枝末节，只留下最重要的点。

通常来说，三十分钟的演讲，能讲清楚三到四个点就很不错了。所以不必舍不得自己辛苦准备的材料，因为堆积材料反而会喧宾夺主，模糊观众的印象；也不必担心听众接收的不够全面，只要准备好完整的学习材料在演讲完后下发就可以。

第二，反复练习。或许你对某个问题已经滚瓜烂熟了，但这并不意味着你一定能讲好它。如何保证能讲好？除了多练习，没有其他诀窍。你可以从“讲给身边人”开始练习，对身边人讲两三遍，确保他们能听懂，你也能讲得流畅。然后，尝试给更远一点，更大一点的团队来讲，同样确保他们能听懂，你也能讲得流畅。然后再尝试给更远一点的、更大一点的团队去讲……

注意，这里说的“讲”不是简单的重复。每次讲都要全神贯注，讲完都要认真反思，对暴露出的问题，要有针对性地解决。按照我的经验，即便没有任何演讲经验的人，练三次基本可以给三五个人的观众讲清楚，练十次基本可以给一百以内的观众讲清楚。前提是，一定要有足够的耐心来练习——无论练三次还是练十次，针对的都是同一个主题。

第三，也是最后一点，仔细观摩优秀的技术演讲，用心推敲，也是提升自己演讲水平的有效途径。我们去观看技术演讲时，往往只关心“讲了什么”，而不关心是“怎么讲的”。只有自己要去演讲的时候，才会深刻体会到“原来把懂的事情讲明白”，并不是太容易的事情，不是一味堆积“干货”就可以的。

既然要做好技术架构应当多学习先进经验，那么做好演讲也需要多学习先进经验：是一路平铺直叙，还是用悬念引导？是文字数据优先，还是图形表格为主？这些问题，坐在家里空想是没有用的，多去看看优秀的演讲，会让你在技术品牌的塑造上少走很多弯路。

第59讲 | 技术演讲，有章可循

你好，我是余晟，一个老程序员，一路坎坷走来，积累了些技术品牌和演讲的经验，今天，想跟大家分享如何做好技术演讲。

技术演讲，是树立个人和公司技术品牌的重要手段。相比撰写技术文章，它的效果也更生动、更直接，加上现场的互动，以及后续媒体的报道，往往能给人留下更深刻的印象。

但是做技术演讲也比写技术文章更难，因为做技术演讲时，你没有反复修改的机会，你必须直面观众、实时答疑，你的错误会被放大甚至广为传播…… 技术好的人未必能写得好技术文章，技术文章写得好的人也未必能做好技术演讲。不过，技术演讲也不是像天书一样无法琢磨，只靠天赋灵感，还是有一定章法可循的。下面，我就提供几条做好技术演讲的个人经验。

1. 严肃对待

许多技术不错的人之所以做不好技术演讲，甚至讲自己熟悉领域的东西也讲不好，问题不在于技术，而在于态度。技术演讲不是把已有技术内容做点包装就可以拿出去的，通常它在两方面都有着更高的要求：1. 你必须更深入思考已有的技术内容；2. 你必须以空杯心态对待演讲过程。

更深入思考已有技术内容，也就是“知其然也知其所以然”。或许你解决了某些问题，但误打误撞也是可以解决问题的。所以在技术演讲之前，必须反复问自己：分析思路是对的吗，查证的资料是可信的吗，掌握的数据是最准确的吗，看的书是最权威的吗……如果不是，一定要仔细查证，并且保证各环节之间的逻辑是自洽的。

也许你以前花十来分钟，看了篇文章就恰好解决了某个问题，但对外讲的时候，你务必查阅各种资料，把思维的来龙去脉、概念的内涵外延都弄清楚，所花的时间可能几倍甚至几十倍于十分钟，但它是必须的。否则，如果台下观众更有经验，你可能会出丑；如果台下观众没有经验，你的演讲稿可能导致谬种流传，危害更大。

以空杯心态对待演讲，也就是认清“我懂了”和“我能让你懂”是两个完全不同的问题。自己弄懂，可能和自己经年累月的思考有关，也可能需要以自己之前的知识积累做背景。但是让观众懂，而且是在演讲的几十分钟之内让观众懂，就必须把自己从“假想观众”中区分开来，哪些是自己特有的思维习惯，哪些是自己特有的背景知识，哪些是自己特有的学习方式…… 这些思维习惯、背景知识、学习方式，和典型观众有多少重合？以及，观众有没有办法在这几十分钟内倾注注意力来听取你的表达？要知道，如果你在上面演讲，观众在下面玩手机，你是一点办法也没有的。

2. 了解观众

就像开发系统要了解问题背景一样，做好技术演讲也需要了解你的观众。通常，你需要问自己一系列的问题，比如：他们来自哪些领域、哪些公司？主要做的是什么工作？一般都有多少年的工作经验？喜欢听什么样的内容？……

如果你不清楚，可以询问主办方，负责任的主办方应当会向你说明。如果主办方也不清楚，对于系列活动，你可以搜索之前活动的报道，看看相关的微博微信，了解观众的评价和反馈。如果不是系列活动，你不妨问问身边哪些人有兴趣，听听他们的看法，做个大致的判断。如果实在不清楚观众是什么样，你可能要重新考虑自己的选择。

千万不要以为这步很多余。如今各公司都在强调用户画像，了解用户才能保证产品成功，演讲也是这样。如果来的都是 90 后，举《我爱我家》的段子来搞活气氛，估计只能导致尴尬；如果来的都是国内的初阶技术人员，过多的英文缩写、文献出处，也可能影响演讲效果。

3. 制作大纲

不知道你有没有听说过“纲举目张”，提起渔网的粗绳一抛，网眼就自动张开了。对演讲来说，大纲就是那根粗绳，具体内容则是一个个网眼。演讲的素材固然重要，但也必须按照一定的结构和脉络组合起来。我听过的一些技术演讲，演讲者本身有比较好的技术积累，但讲得杂乱散漫，原因就在于没有大纲。

好的大纲一定是重点突出的。演讲和写文章不一样，写文章有充分的时间和空间堆积材料，做到完整全面，演讲的时间却相当有限，观众的注意力更是难以把握，所以大纲一定要保证重点突出。无论你之前多么辛苦，知识多么丰富，大纲的要点只能根据演讲时间来。通常的经验是，按“每八到十分钟一个要点”的节奏来安排，三十分钟的演讲只能包含三个重点，四十分钟的演讲只能包含四到五个重点。

好的大纲一定是有悬念和起伏的。我们解决问题往往是按时间顺序来进行的：识别问题、了解背景、验证方案、开发测试、部署验证。但是在演讲时，即便你敞开胸怀毫无保留，按照这个顺序来讲也未必能让观众满意，因为实在是太普通、太千篇一律了。相反，如果你先把最终结果摆出来，吊起读者的胃口，然后逐步展开，并且在其中穿插各种生动的故事，让观众先以为“如此这般”，继而恍然大悟发现并非如此。内容还是那些内容，但效果一定会好得多。

4. 现场互动

在电视剧可以插播广告的时代，大概每 10 分钟左右就会播一次广告，这是有心理依据的，因为人在无外界约束状态下能集中注意力的时间大概就是 10 分钟。所谓“无约束”，指的是没有老师盯着，没有监视器对着，人可以随时撤出“注意”的状态。很可惜，技术演讲的观众也处在这种状态下。

怎么解决这类问题？安排与观众的互动是一个相当巧妙的手段。纯粹的演讲更像是单方面的输出，一切都在按部就班、顺理成章地发生。但是互动会引入意外的因素，让听众感觉新奇，把大家已经有些溃散的注意力重新聚集起来。所以一个好的做法是，写完大纲之后，每 10 分钟左右留出一个空档，设计合适的互动插入进去，这样往往可以起到很好的作用。

更重要的是，现场互动可以让演讲内容更接地气。有时候，演讲者讲的很好，但观众无法把演讲的内容和自己之前的经验结合起来。这时候如果有人提出有代表性的问题，就容易很好地化解众多观众的普遍困惑，让演讲的效果再上层楼。

有些人喜欢安排“托儿”来互动，因为担心互动出现意想不到的局面。在我看来，除非演讲者自己不够自信，而“托儿”的水平又很高，能做到不留痕迹，否则这样搞反而会弄巧成拙。只要演讲者的准备足够充分，对待观众完全是可以以逸待劳的，很难会出现意想不到的尴尬。

5. 反复排练

我经常讲，技术演讲其实完全不需要什么天赋，完全是个熟练工。所谓“熟练工”，就是反复练习多遍之后，动作顺理成章，不会有任何走样。

你有没有在技术演讲中忘过词或者讲话磕巴？有没有在讲的过程中忽然脑子一片空白？有没有讲到后面才发现前面漏掉了一些东西？…… 这一切现象，虽然会影响技术演讲的效果，但都是正常的。它们都是在不熟悉技术演讲时的正常现象，都是可以通过反复训练加以解决的。

排练要排练到什么程度？我可以提供一个大致的参考公式：如果观众在 10 人以下，排量一遍就可以；如果观众在 30 人以下，排练两三遍就可以；如果观众在 100 人以下，排练三到五遍。前面的每一遍排练，都要计时，都可以随时中断，把想到的可以改进的点记录下来，每一遍完成之后认真复盘，再开始下一遍排练。最后那遍排练应当忘掉计时，不许中断，相当于“上线之前的最后验证”。注意，这里说的排练，是在全部素材已经准备好，PPT 已经成型的情况下进行的，不包含之前的准备时间。

如果观众超过 100 人…… 这时候你大概不需要看这篇文章了，去看看报道，雷军、罗永浩、乔布斯在发布会之前花了多少时间排练，你会有大致的答案。你也会更深刻的意识到，做好技术演讲真不是件容易的事情，怎么重视都不为过。

以上就是我总结的关于技术演讲的经验。希望对你有用，也希望你不要嫌烦。毕竟，认真对待演讲，既是对观众负责，也是对提升自己的机会负责。

第60讲 | 正确对待技术演讲中的失误

作为技术 leader，不论是为了布道公司技术产品，还是为了打造个人技术影响力，在公众场合演讲是不可避免的。优秀的演讲能力几乎已经成为职场升级中的一门基础技能。

然而，演讲并不是一件简单的事情，对于上台表达自己，人们普遍都会感到害羞、恐惧、焦虑。对本来就苦手于沟通和语言表达能力的程序员来说，演讲更是难上加难了。

不少研究都表明，在人们最恐惧的事情中，当众演讲当之无愧的名列榜首，甚至超过了死亡。即使是最伟大的演说家丘吉尔，也把当众讲话列为人生三大难事之一。

许多人对演讲恐惧，是因为害怕犯错误，这种恐惧心理导致人们还没有开始演讲，就已经打了退堂鼓，心理暗示一旦发挥作用，演讲的效果就可想而知了。对此，《演讲之禅》的作者斯科特•博克顿指出，演讲中很难避免一切错误，而是要正确看待它。

斯科特在书中写道：“我很清楚自己会犯一些低级错误，但在演讲中，不犯错几乎是不可能的，而且，完美的表演也会显得有些枯燥无味。因此，我不在乎完美，只在乎我的演讲实用、适宜，并能表达我的心声，而追求完美很有可能会成为它们的拦路虎。”

在演讲中犯点小错误，有时并不是一件坏事，特别是对初次演讲的人来说，它能让我们对演讲产生敬畏，懂得站在台上绝非易事。好的演讲者，几乎都是跨过一个个坑而来的，比如没弄清听众需求、演讲主题老旧、啰嗦的开场白、内容重点失衡、幻灯片出错、语速过快、语调平淡、演讲超时、没有交流等等。

可以说，在演讲中，错误肯定会发生，重要的是如何定位错误以及如何应对错误。

1. 接受不完美的演讲

完美的演讲几乎是不存在的，即使你对内容做好了充足的准备，私底下也排练了很多遍，但当你站上演讲台，面对台下黑压压的一大片人群的时候，你还是极有可能会因为紧张而忘词、磕巴、漏掉准备好的内容。更不用说，如果没有做足准备，那上台之后脑袋一片空白、磕磕巴巴、词不达意也不是什么稀奇的事情。

另外，演讲是一个存在交互的场景，现场的听众、环境、设备都会对最终的演讲效果造成影响。因此，要接受不完美的演讲存在，不要试图避免一切错误的发生，否则，当一些小错误发生时，你反而会猝不及防，甚至可能把小错误变成大失误。

同时，也不用对自己太过苛刻，演讲中的一些小错误可能只有自己知道，听众很多时候是注意不到的。

要知道你怎么对待错误，听众就会怎样对待错误。如果不小心说错一句话，你反应得像是世界末日，在台上磕磕巴巴支支吾吾，那么听众就会看得清清楚楚，视之为惨剧。反之，如果你泰然处之，视之为趣事，听众也自然会照样学样，轻轻跳过这一节。

斯科特在经历一场自认为失败的演讲后，去询问观众的反馈，却发现不仅没有人在乎，而且根本就没有人发现他的失误，记住这一切的只有他自己而已。

正如戴尔•卡耐基在《成功演讲指南（Public Speaking for Success）》中所说的：“演讲结束后，演讲大师常常会发现自己的演讲有 4 个版本：一个是他们准备要讲的，一个是他们所发表的，一个是报纸报道的，一个是讲完后反思的。”

所以，接受不完美，在台上放松自己，对演讲而言反而是更好的状态，越轻松表现得越好。

2. 演讲前的准备必须慎重

演讲不会完美，并不是你放弃准备，试图到台上自由发挥的理由。不论你是因为什么原因站上演讲台的，一旦你站了上去，你现场的表现以及所表达的观点，就会对你的个人品牌造成影响。

讲得好了，听众自然会觉得这个老师特别有料，会愿意跟你做更多的私下交流，也愿意传播你的观点，这对个人甚至公司技术品牌都是很大的提升，反之则会造成对技术品牌的伤害。

而要想做好演讲，前期的准备和练习熟悉是不必可少的，这个过程会耗费大量的时间和精力，那这些时间应该花在哪些方面？斯科特提出了四项建议：

要有一个鲜明的立场。所有演讲都要有中心观点，你需要知道你的中心观点是什么。如果你还不够了解你将要讲的话题，那你一定要在演讲前解决这个问题。即使是一句“这五样东西是我所喜欢的”也表明了你的观点，因为还有无数的事物不在你的选择范围之内。每当我听到一个糟糕的演讲，我都想问演讲者：“你的演讲到底想表达什么意思？”或者“你到底想说什么？”

认真了解你的听众。你要弄明白他们来听你演讲的原因、他们的需求、背景知识、兴趣爱好，以及他们渴望从你这里学到什么东西。若果没有足够时间来将演讲主题研究透彻，那你至少要了解听众。结果可能是你发现自己对某个课题的理解并不是很透彻，但是你至少比你的听众要了解得多。

让观点简洁明了。如果你用 10 分钟才能讲清楚自己的论点，这可不是什么好事。你的论点就是一种声明，而论据则是用来论证观点的。论点必须是精炼、简明的，而论据则可能稍长，但是绝不能让听众听得云里雾里、不知所云。一个不算失败的演讲至少是立意鲜明的，而不会令观众听得稀里糊涂、毫无趣味，而一个糟糕的演讲总是让你找不到重点。

为与自己意见相左的观点做好准备。如果你的听众专业知识过硬，他们就很有可能会与你观点相左，并在现场提出反驳意见。如果你不知道这些与你意见相左的观点，那你就无法提出好的论点，无法与对方更深度的沟通。

最后，演讲者还需要大量的练习，那些前期不多加练习，却期待一上台就能够即兴发挥、侃侃而谈的想法是根本不现实的，必然会得到来自演讲台的深刻教育。

3. 演讲后的复盘必不可少

接受不完美并不代表接受错误，我们要做的是在演讲之后及时复盘、查漏补缺。一般演讲都会有视频记录，我们可以回看自己的演讲录像，不要感到尴尬和害羞，这可以帮助我们客观的了解自己讲得到底如何，演讲中出了什么差错，哪些地方没有达到自己的预期，然后找出到底是什么原因导致你犯了这个错误，是否有方法可以改进，保证下次不会出现一样的失误。

比如开场白太啰嗦，那就为自己设计一个开场白，并不断练习到产生肌肉记忆，下次演讲的时候可以不假思索的说出口。

比如内容重点失衡，那就在准备的时候，对内容做更详尽的规划，设计出每个部分需要花费的时间，并加以练习。对技术演讲而言，可以采用“坑 - 解决方案 - 总结”这种 3 段式的经典结构，并将内容重点放在第二部分优化解决方案上。

比如幻灯片出错，这种是完全可以避免的错误，除了自己检查之外，还可以请同事朋友帮忙检查幻灯片。

比如语速过快，那就有意识的调整、训练自己，也可以在演讲中时时提醒自己要放慢语速。

诸如此类，问题并不可怕，即使职业演讲家，也会经历失误、出丑，重要的是不断练习、不断改进，这样，每一次失误都会是一次人生财富。

你呢？你在演讲中是否犯过错误呢？是如何应对的呢？欢迎留言告诉我们。感谢您的收听，我们下期再见。

第61讲 | 刘俊强：技术最高决策者应该关注技术细节吗?

作为公司的技术最高决策者，身上肩负了很多的职责，不光有公司的技术路线图、投资标的公司的技术尽职调查以及关键技术趋势研究等战略级事务；还有工程团队文化建设、技术布道等帮助公司健康发展的关键事务；还有跨部门沟通、为其它部门提供服务能力帮助他们一起成就公司愿景等。

在目前典型公司架构中，工程团队或技术团队的总负责人便是该公司的技术最高决策者，那么本文要讨论的技术最高决策者就是 CTO（首席技术官）或 VP of Engineering（技术副总裁或工程副总裁），这个一般根据公司的实际职位设置情况来，本文默认 CTO 为技术最高决策者。

技术或工程团队日常工作中会有很多的技术细节类工作，例如技术框架选择、高可用架构设计以及持续集成等，那么一般困扰我们的是，作为技术最高决策者跟这些技术细节的边界是什么？是否应该关注这些技术细节？

我接下来将先简单梳理下 CTO 的工作职责内容，然后我们再看是否应该关注技术细节，在本文阅读完毕后，希望你自己也能够根据现状进行思考。

CTO 的使命与职责

CTO 的使命我们可以从三个维度来进行说明：长期的技术战略、技术布道者以及工程团队文化建设，里面仅第三项是完全的对内事务，前面两项都是内外结合型事务。接下来我们将分别来看看这三个维度的使命是怎样的？

CTO 的使命——长期的技术战略

CTO 必须不断推进、阐述并坚持公司的技术战略方向；

CTO 需确保公司在激烈变化的竞争下持续提供最佳技术；

CTO 需要通过信息获取提取来指引支持公司下一步发展的关键趋势，从而将外部世界与公司内部联系起来，实现业务和技术战略之间的适当平衡，使得公司的技术战略与其业务战略保持一致。

CTO 的使命——技术布道者

CTO 必须围绕公司的长期愿景来激励内部人员，并向外部表达并使他们相信世界或行业未来发展方向，而自己的公司是带领大家抵达未来的最佳选择；

CTO 必须对市场需求具有权威性，必须对客户可信，并且能够向各类的受众阐明公司商业价值和投资回报率。

CTO 的使命——工程团队文化建设

CTO 负责一个公司的技术或工程团队，那么如何建成健康的工程团队文化便尤为重要。

CTO 必须团结起来工程团队，来实现公司的长期技术目标；

CTO 必须能够激励新员工加入工程团队，并且帮助找到渠道并识别合适员工；

CTO 必须帮助建立和维护工程文化，以确保公司能够持续留住和吸引顶尖技术人才。

上面我们提到了 CTO 的使命，从三个维度共 8 个要点进行了说明，希望大家能够对 CTO 的使命有些了解。如果我们要看作为公司技术最高决策者是否应该关注技术细节这个问题，我们还需要看下 CTO 对公司内部各组织的具体职责是怎样的。

一般分为以下 5 个主要组织或团队：CEO 或战略、工程 / 产品、销售、商务拓展以及市场营销。下面将针对这 CEO 或战略、工程 / 产品两个团队阐述下 CTO 的一些主要职责：

CTO 对内主要职责——CEO 或战略

预测可能对公司产生重大影响的任何技术拐点，并且保持领先；

根据公司长期技术战略，向 CEO（以及 CFO/COO）就公司的大规模技术投资时机和机会点提供建议；

为 CEO 提供有关公司技术方向的不同”选项“，并提供足够的决策依据信息，以确保在任何给定时间都是最佳技术选择；

CTO 对内主要职责——工程 / 产品

虽然 CTO 不需要为产品日常交付情况负责，但也应该与产品或工程副总裁密切合作，以确保整体发展方向与公司的战略技术保持一致；

CTO 应该确认在既定技术战略下，公司技术资源投放的优先级，并交给工程团队予以执行；

需要帮助技术或工程副总裁集思广义，了解工程团队面临的各种挑战，在很多方面，CTO 和工程副总裁需要保持联系；

持续优化整个组织，以达到技术资源最合适的收益比；

确保工程团队在壮大的同时，保持技术的一致性，并在必要时进行技术仲裁；

建立合适的创新机制，例如黑客马拉松或内部孵化计划；

帮助招募和员工留存工作。

是否应该关注技术细节？

本文前面说了很多关于 CTO 的使命与职责，那么作为技术最高决策者是否应该关注技术细节呢？在此先说结论，符合其使命和职责方向的技术细节需要关注，此外的技术细节不必要关注。接下来本文将阐述此结论的由来以及会举证一些事例便于理解。

CTO 全称为 Chief Technology Officer（首席技术官），重点要注意的是 Officer，也就是高级管理者的角色，首先需要对公司的长期技术战略进行负责，保证公司在技术拐点产生时能够作出正确的判断并制定应对策略。这样就需要 CTO 对外部世界的技术动向和趋势能够收集到足够的信息并进行分析整理，从而得出结论。

例如 2007 年 6 月苹果公司发布了跨时代产品——第一代 iPhone，成为了移动互联网发展元年，之前 Symbian 系统的智能手机更多的还是基于 WAP 网络，iPhone 全触屏体验、高速好用的内置浏览器、全新的智能手机操作系统 iPhone OS 以及应用商店体系给行业带来了翻天覆地的变化。

CTO 需要了解 iPhone 的详细产品功能以及技术规格等技术细节，并对 iPhone 相关移动网络技术进行调研，从而来分析判断 iPhone 及移动互联网发展趋势，来看公司的技术战略是否需要进行相应调整。

我们现在回顾移动互联网过去 10 年，是几家欢喜几家愁，有些公司借着移动互联网技术东风发展迅猛，有些公司没有及时调整战略进而发展受限甚至慢慢衰退，比如之前超级依赖短信 SP 的公司。

移动互联网的技术拐点来临的时候，我亲身经历过技术趋势分析和公司技术方向调整，当时公司在 2007 年开始做移动互联网方向的尝试，因为我分析认为未来的趋势是基于手机的移动互联网，只是当时是基于 WAP 和 Symbian 系统来做的，体验和能力都不好，因此决定先做互联网 Web 2.0 方向项目。

在同年 iPhone 发布后，研究后觉得 iPhone 走的方向是智能手机未来（当时国内 3G 牌照尚未发放），决定投入少量人力研究和保持关注 iPhone OS，次年苹果公司发布了 iPhone OS SDK 1.0，我们就立马组建了 iPhone 客户端团队进行移动互联网应用开发。由于国内 3G 牌照未发放，当时相应的一些 3G、GPS 测试就到香港和深圳进行，由于我们在移动互联网方面的提前布局，也帮助公司顺利拿下下一轮投资。

前面有提到 CTO 需要在外部激烈竞争下保证公司使用的是最佳技术，这里的“最佳技术”并非是指最为花哨或最为前沿的技术，每个公司有着自己的业务背景和历史债务问题，选用对于公司技术资源投入产出比最高，且为符合日后技术发展趋势的技术方案才是“最佳技术”。

那么这里我们以火热的技术架构设计风格——微服务——为例说明下。众所周知微服务架构设计风格并非只是技术上的，如果要在公司中选用的话，需要具备持续集成 / 持续发布的实践基础，同时要对企业组织架构进行相应调整，那么作为 CTO 需要针对微服务架构设计风格对于公司选用的收益及风险进行评估，以及需要来看跟公司业务发展方向是否一致，这样的微服务相关的技术细节是需要 CTO 进行了解和关注的，这样才能够尽量作出正确的判断。

前面用行业新产品带来的大趋势或技术拐点以及新技术架构趋势的例子，来说明哪些技术细节是技术最高决策者应该关注的，那么反例有哪些，也就是哪些技术细节不应该被关注？

作为 CTO 不应该将时间投入到产品日常迭代和编码这样的技术细节中，例如具体技术框架选取、架构方案设计以及代码评审等，其中亲自上阵写代码是最应该被禁止的。为何呢？因为每个人的时间都是有限的，CTO 需要将时间更多的花在跟公司未来、技术趋势以及商业拓展相关的事情上。

上述具体技术事务应该有技术副总裁和技术总监来进行完成，CTO 需要提前做好指引工作，跟工程副总裁制定好技术方向原则，以指引工程团队具体工作。

有的 CTO 会参与到具体执行工作中去，一般的理由有“团队小”、“该领域我是专家”、“这项工作团队其他人的交付速度与质量不如我”，其实这些理由后面恰恰对应的待解决的问题，例如：

“团队小”：需要反思这个阶段是否需要 CTO 这样的职位，或者给予技术联想创始人更为合适，或是招募优秀团队成员加入；

“该领域我是专家”：需要将知识经验分享给团队成员，或是招募该领域其它专家，因为你自己很容易成为单点，这样是很危险且不负责任的，如果你持续这样想，另一种可能是你并非适合 CTO 职位，或更为适合首席架构师；

“这项工作团队其他人的交付速度与质量不如我”：意味着没有招募到合适的团队成员，这个问题应该被纠正。

写在后面

作为公司技术最高决策者首先需要明确自己在公司承担什么职责，这样才能够清楚怎样的技术细节是应该关注的，哪些技术细节是不需要关注的。正如前面所说的结论 “符合其使命和职责方向的技术细节需要关注，此外的技术细节不必要关注” ，使命和职责是需要先明确的。

本文是以 CTO 的角色来进行的说明，那么实际工作中的情况可能会不一样，例如公司没有 CTO 仅有工程 / 技术副总裁，这样的时候就需要重新来明确使命和职责，再确认技术细节的边界。

总而言之，技术最高决策者需要明白的是，这个岗位的职责是要为公司业务发展及未来负责的，因此技术细节边界的确立有助于更好地分配时间来帮助实现公司愿景。

作者介绍

刘俊强（微信公众号：程序员精进）现任腾讯云资深架构师，TGO 鲲鹏会深圳分会董事会成员，小组委员，曾任迅雷技术总监、某互联网公司技术副总裁，10+ 年以上互联网开发经验，8 年以上技术管理经验。

第62讲 | 张溪梦：技术领袖需要具备的商业价值思维

你好，我是 GrowingIO 创始人兼 CEO 张溪梦，今天想跟大家分享的话题是“在高速成长、竞争的市场里，技术领袖如何帮助企业产生最大规模的价值”。

先来看什么是 Growth？Growth is connecting more people to the existing value of a product。这句话里有两个非常重要的部分：第一，产品必须有核心的价值（existing value），我们必须要有一个核心的产品价值能够传递给我们的用户，这是所有增长的核心。第二，连接，让更多的用户和既有产品的价值进行关联和挂钩。

Gartner 在 2017 年发布的调研表明，在全球顶尖的公司里，至少有 25% 的业绩是由企业内的 CTO 或者 CIO 通过创新或技术优势，直接转化为财务结果、客户优势和市场份额，实现增长。

Gartner 调研的一般都是大规模企业，在这种大型企业里，技术或者说 IT 往往被定位成一个更偏支持的部门。三年前，Gartner 的调研显示 CEO 对技术最高的期待是数据化。近两年，对于 CEO 来说，最高优先级的工作是增长，而第二位就是如何用技术来变革企业内部，产生更大规模的增长。

在这样的背景下，对技术领袖也提出了更高的要求。

1. 思维的进化：以支持各部门为中心（Focus inside the wall）—以客户为中心（Focus outside the wall）

很多时候，我们的思维还停留在墙内，以支持各部门为中心，做的更多的是满足各个不同部门的需求。但在当今阶段，真正有技术领导力的领袖必须要到墙外去关注客户，去以客户为中心做事。

回国创业这几年，我发现即使是为客户服务，我们的产品、技术也是从造榔头开始，而不是去思考用户身边还有哪些钉子需要解决。

技术领导者必须要以客户未被满足的需求为主导，去思考技术创新和解决方案。否则，我们所创造的产品的价值影响力就会很低，它对这个世界的影响及带来的转变也会很低。

未来，技术领袖的关注焦点一定是从公司内部转向公司外部，从以支持各部门为中心到以客户为中心的思维进行转化。

那以客户为中心需要考虑哪些要点呢？

客户是谁？

客户未被满足的需求是什么？

如何用我们的技术、产品，来大规模的满足这种的需求，解决客户的问题，同时拉动自己的业务增长。

这是第一个趋势，要求技术领袖从纯技术导向的思维转变为客户导向的思维。

2. 技术领导力的进化：研发的能力（I can build everything）—整合的能力（I will leverage others）

过去的十年里，特别是我早年在湾区工作的时候，大部分软件都是企业内部自研的。以领英为例，分布式消息系统 Kafka 就是领英自己研发的。因为领英是一家数据驱动的公司，需要工具来处理大量的数据，但当时市场上并没有这样的解决方案，所以工程师们只能自己动手，花了大量的时间开发了 Kafka 等一系列的工具产品。

但在今天，如果我们想提高效率，真正把技术投入在最能满足客户需求的聚焦点上，我们就不能再保持过去这种 Build Everything 的思维，而是要具备一种整合能力，即 Leverage 不同的工具和技术，迅速组合成新的产品和服务来支持业务增长的能力。这种能力对不少 CTO、CIO、技术领导者而言是一种新的挑战。

还是以领英为例，八年前我刚加入领英的时候，领英使用的外部工具非常少，基本都是内部自研的，但到我离开的时候，公司里已经集成了近两百种不同的 SaaS 服务。这些 SaaS 服务，在某种程度上解决了公司内部的运营、营销、财务、客户管理、数据管理等诸多问题，公司能够把所有精力都放在增长核心业务上。

我在领英待了五年，这五年里它的业务增长了接近 40 倍，其核心原因之一，就是能够善用这些产品和工具来提高内部的效率，做到高速的增长。

这是第二个趋势，要求技术领袖从 Build Everything 的构建思维转变为整合的思维。

3. 视野的进化：仅聚焦某部门或职能 （Biz function focused）—连接企业各部门（Cross enterprise）

以前，技术更关注的可能是如何支持公司内部某个部门的需求，在大部分的公司里，技术也被定位为更偏向于支持业务的部门。但本质上，我认为技术是企业内部连接所有部门的第三种力量。

那其他两种力量是什么呢？第一种力量是财务，第二种力量是人力，这两种力量是能够打通企业内部所有部门的。而未来十年、甚至五十年真正能够引领变革、穿接所有部门的第三种力量是科技。技术能使企业内部体系的运营效率得到大幅度的提高，对外能更好的服务客户。

想要提高内部效率或产出，我个人认为是无法靠招聘大量的人力来解决的，而是要有效的打通内部企业的各种系统、流程，这一过程就需要我们在技术上有很大的创造力、很高的执行力及整合力。

这是第三个趋势，要求技术领袖进化视野，让技术具有连接企业所有部门的能力。

4. 角色的进化：关注交付、实施和执行（Keep the lights on）—商业战略导向（Strategic partnership）

即使在很多技术占主导的公司中，技术还是要跟着产品、业务往前走，它会更关注执行，保证系统不会宕掉、提高开发效率、交付更好的业绩等。

但我个人认为，过去的十年里世界经济的高速发展，其中一大部分都是技术创造出来的新增 GDP，而不是因为全球人口的增加。

因此，一个好的技术领袖，要变成一个战略思考者，而不只是一个战术执行者。战略思考者就要求我们的创新必须具备产品化的思维，做的东西要能够吸引很多用户。无论这种用户是行业里的客户，还是企业内部的各种部门。

这是第四个趋势，技术领袖必须转变成商业战略导向的思维，通过解决业务的问题，拉动增长，完成创新 - 战略 - 执行 - 结果的过程，更要从单纯的战术执行者转变为 Strategic Partnership，和公司的 CXO 们一起为，企业的增长做出各种准备和努力。

最后想跟大家分享一下可口可乐的例子，2017 年初，可口可乐取消了首席营销官 CMO 职位，取而代之设立了首席增长官 CGO 这一职位。

大家知道，可口可乐市值约 700 亿美元，其中品牌价值约为 620 亿 -640 亿美元，几乎占到了这家公司整体价值的 90%。可口可乐在过去近一百年的时间里，都在引领全世界营销的变革和趋势，而 CMO 这个职位正是它在 25 年前引领型地创造的。如今，也是它走在前列，用 CGO 代替了 CMO。

以前 CMO 主要管营销，如今 CGO 会管所有的业务线，除了营销之外，还会管理新品研发、创新、数据等。这意味着所有的技术领袖都有巨大的机会成为一个企业的首席增长官。

去年，Forrester 研究表明，全球 100 强企业中大约 5 家公司设有 CGO，今年，它预测世界 100 强企业中至少会有 8 家新的公司设立 CGO。这意味着在未来，很多技术引领者将有很高的可能性变成公司的二把手或者一把手。

因为，如果未来增长是通过技术和产品来驱动的，那么公司的第一把手就应该是技术领袖和产品领袖，而不只是一个做营销的人。

本文整理自 GrowingIO 创始人兼 CEO 张溪梦在 GTLC 全球技术领导力峰会上的精彩分享。在创立 GrowingIO 之前，张溪梦曾任 LinkedIn 美国商业分析部高级总监，创建了 LinkedIn 近百人的商业数据分析和数据科学团队，也被美国 DataScienceCentral 评选为“世界前十位前沿数据科学家”。

第63讲 | 未来组织形态带来的领导力挑战

当我们谈论领导力的时候，一定要考虑到当前所处的时代，相比之前，如今的互联网更加垂直、个性和人性化。市面上有很多 Web1.0、工业 4.0 时代出版的管理书籍，里面涉及到术的层面的内容很多，有着各种各样的管理方法，但那些方法拿到现在已经不太好用了。大家有做管理的话，可能会发现用原来的方法管理员工，好像没那么灵了。

VUCA 时代

有社会心理学家认为，新技术的发展速度远远超过了社会人文的发展速度，导致人们的人文观念、价值观和行为方式在新技术的革命浪潮中无所适从，很多被证明行之有效的范式和秩序正在被颠覆。

有个概念正是描述这一情况，即 VUCA。何为 VUCA？V 是 Volatility，代表易变性；U 是 Uncertainty，代表不确定性；C 是 Complexity，代表复杂性；A 是 Ambiguity，代表模糊性。

也就是说，如今，世界已经进入 VUCA 时代，我们正面临一个易变的、不确定的、复杂的、模糊的世界。在这样的 VUCA 时代，不知道接下来会发生什么、也不知道如何来做应对的准备，每个组织与个人都有一种对未来不确定的恐慌感，长远规划越来越成为不可靠的事。

以 3D 打印为例，不知道大家对 3D 打印当年的热潮是否还有印象？2013 年的时候，3D 打印是一个大风口，除了媒体炒作、资本追逐之外，国家也大力扶持，甚至认为 3D 打印除了民用领域之外，还可以用在航天领域。当时全球有两家 3D 打印相关的公司，市值加起来超过了 100 亿，但仅到 2013 年底，两家公司的市值就跌了 80%，这个巨大的变化是很多投资者包括群众都没有想到的。这就是易变性的一个表现。

在 VUCA 中，对领导者来说，最难的就是模糊性。如今，大家可以在一定程度上在自己的认知范围内，有一个短周期的预判，但对于大的经济环境和形势缺乏预判能力，没有办法很清楚地去做战略规划。因为社会变化太快，机会到处都有。

这种不确定的时代，企业需要适应时代要求，不断自我变革与创新，其中最难的、最深层次的变革就是组织与人的变革。而对领导者的要求就是要敏锐感知影响组织与人变革的因素，洞见组织变革的趋势，使组织有前途，工作有效率，人才有活力。

人性与需求

关于人的变革，面对时代的差别，我们主要看什么呢？是思维。而思维又可以从人性和需求两个层面出发去改变。

第一，讲思维时看人性。传统认为人性是非黑即白的，但现在没那么容易区分了，而且善恶是动态发展的。

同一个员工，可能在 A 公司工作表现、工作态度等诸多方面都不好，但跳到 B 公司后可能就截然不同。我们就流失过这样的员工，在公司时我们恨不得马上把他开掉，他也觉得不受待见，就跳槽去了旁边的公司，结果在那家公司表现非常好。

我私下约他出来聊天，他说在那儿 Leader 信任他，同时给他空间，而在我们这儿不被重视，每天被卡得死死的，这儿不行那儿不行，很多项目很努力地做完后连一句表扬的话都没有。

第二，讲思维时看需求。大家都知道马斯洛的金字塔，常规来看，我们在公司里面讲需求，会先看是不是满足员工最基本的生存、舒服、安全等需求，然后再一级一级往上看。但是现在是混序的需求，作为 Leader，就需要能够鉴别员工的需求在什么地方？哪个需求对他而言是最重要的？经济有时候不再是他们的主流需求，其他情感、归属、自我实现等方面的需求反而可能会浮现出来。

因此，我们要从人性和需求的角度出发，用动态的或生态的思维去看待人才。

未来的组织

除了人的因素之外，组织是领导者在这个复杂多变的时代需要去敏锐感知的另一个因素。那未来的组织变革有哪些特征呢？

如今的组织，不管是 IBM 还是谷歌，它们都有一个边界。在公司里，我们做一个项目，会去找技术、产品、销售等各个方面的人组成团队，这些人都是同属一个公司的员工。

但在未来的组织中，工作形态及组织形式可能有一些变化，会大幅度减少人跟人之间的关系绑定，部门之间的边界也变得越来越模糊，人才共享成为新常态，大量随需而动的“云团队”不断涌现，增加了组织的敏捷性。比如很多企业开始尝试的项目制，就是这种组织形态的一种体现。

而这需要人才能够拥抱变化，随时能够换部门、换老板、换任务、换同伴、换 KPI，对人的环境适应性提出了很高的要求，也对领导者提出了更高的要求。

此外，公司外部的人才共享也将成为可能。举例来说，在座的 400 位中，只有第一排的同学是全职员工，剩下的都是市场流动人才。当我决定做一种智能翻页器时，第一排的全职员工负责供应链、材料、软件等方向，然后由他们去市场上找到合适的顶尖的人才，于是产生了人才投标。通过这种方式会产生一些真正可以中标留下来的人才。而这些不断通过人才投标，总能留下来的人才，或者总能拿到项目的人才就叫做头部人才，他们会拿到市场上几乎 80% 的机会。剩下的人就变成要抢剩下的机会。

这对于企业的好处在于，企业将永远能够拿到市场上更好的资源，而且不用花费大量的人力成本。

在这样的组织形式下，首先，未来组织最重要的职能将变成赋能，而不再是管理或者激励，当然现阶段还是激励对团队来说更重要。

其次，未来的团队将偏向小而美，取得的成果跟团队规模没有任何关系，而是跟人才质量和人均效能有关。例如，现在公司有一百人，这一百人的产出能不能实现真正的最大化？几乎没有公司这么算过，只是感觉员工很努力了就可以了，但是如果算一算，就会知道其实很多员工相当于是在浪费公司的时间或者金钱。

最后，未来将有全新人才的配置方式，当人才共享成为常态之后，自然会对领导者的能力提出更高的要求。举例来说，第一，如果未来是有少部分人是全职员工，我们自然希望留下的是最好的人才，那么对于 Leader 来说，如何留住这些顶尖人才就成为一大挑战。第二，如果以之前提到的项目制的方式工作，除了少部分全职员工之外的大多数人都是市场流动人才，之前跟 Leader 并没有关系，那他们去了公司以后，作为 Leader 该去如何影响、领导他们并与他们沟通，这些对于 Leader 来说也是非常大的挑战。

本文整理自 TalentX 咨询公司创始人兼 CEO Tina Jiang 在 GTLC 全球技术领导力峰会上的精彩分享。

第64讲 | 如何判断业务价值的高低

众所周知，决策是在一定约束条件下，为实现个人、团队或企业目标而按照一定程序和方法，从备选方案中择优选择一个最合适方案的过程。

因此，任何决策都要作出某种选择，而选择是否正确，取决于对决策对象的认知和价值判断是否正确。决策离不开价值判断。

软件开发行业也是如此，特别是在敏捷开发中，很多时候都是根据业务价值来决定特性或故事的优先级排序，可以说，业务价值是敏捷观念的核心。

为什么关心业务价值

那么，人们为什么要关心业务价值呢？Joe Little 梳理了四个原因。

原因一，这个世界上有无数有趣的事情值得去做，所以，问题就不在于是否能找到有趣的事情去做，而在于决定哪些是最重要的需要去做的事情。这正是我们关心业务价值的原因之一，人生苦短，总要去做一些“真正有意义”的事情。

原因二，业务价值有利于保证团队成员共享一个一致的目标，来判断他们的行为是否正确。可以说，业务价值调动了团队成员的自然动机，并给了他们一个基点，可以将与团队工作相关的任务按照自然的顺序进行排列（比如谁做什么，系统架构怎么做等）。

原因三，在软件这个充满了变数的混沌世界中，把握业务价值可以给人一种处变不惊的魄力。变化是永恒的，这包括人们的遗忘、客户群体的变化、客户需求的变化、之前的评估渐渐失效等等。但只要我们对业务价值有适当的理解， 它就可以在这变化的漩涡中充当一个恒定的标杆。

判断业务价值的高低

那如何判断业务价值的高低呢？Pascal Van Cauwenberghe 认为，如果是先编写用户故事，然后再估计它们的业务价值，这一做法会存在严重的缺陷，因为我们很有可能在前期浪费大量时间在低价值甚至是零价值的用户故事上。

好的做法是首先回答这个问题：“我们如何才能找到传递了业务价值的用户故事？”这显示了一个不同的过程，即我们需要首先定义我们打算实现的业务价值，然后生成那些有助于业务价值实现的用户故事。

落地到具体执行过程中，可以按以下步骤来进行：

在开始一个项目或者产品之前，我们首先要决定想要实现什么样的价值（或者利益）；

要找到并改善传递价值的业务流程；

要找到并改善使得传递价值的过程有效的辅助业务流程；

当团队需要用户故事的时候，采用上述步骤中积累的价值最高的流程，然后针对团队的需要以正确的粒度将其分解为用户故事。

而实现这些业务流程的用户故事显然有助于业务价值。

然而，尽管大家都知道业务价值、以及依据业务价值做决策的重要性，但在实际的项目过程中，我们依旧会遭遇各方面的挑战，比如：需求来自多个方面，每个业务人员都将解决自己的问题视为首要优先级事项；领导拍脑袋提出的不合理要求极有可能会打乱原有计划。这样被动的需求接收模式让研发团队很难坚持进行业务价值判断。

对此，姚安峰认为，我们在执行中应该换一个方式。首先，包括技术、PO、业务人员在内的项目团队以及其它相关利益者需要共同理清产品的愿景。也就是要弄清楚为什么开发这个产品？对它的期望是什么？什么是这个产品主要的卖点？相比旧的版本或其他竞争对手，这个产品能带来的改进或差异化竞争力在哪儿？是不是项目相关的各方人士都理解并认可该愿景？该产品的愿景是不是与组织战略方向一致？

明确了愿景后，我们就要对如何达成这个愿景进行规划，产生演进路线图。任何产品都有一个从探索到消亡的过程，都将遵循产品生命周期法则。比如一个在线教育应用，当前的目标是在 6 个月内发展一定用户基础并获得反馈。那在这个阶段，一个吸引人的用户推荐系统是不是更有助于实现目标？一个健壮的会员管理功能呢？一个完善的收费会员体系呢？显然有不同的答案。

产品生命周期决定了在不同的阶段产品应该有不同的策略，从探索期，发展期，成熟期，直到衰退期，“业务价值”的内涵是一直在改变的。而产品规划是预测性地对这些阶段进行设计，并制定每个阶段应该采取的策略，这其中就包括每个阶段的价值取向。更进一步，大的阶段还可以分为一系列连续的小阶段、小目标，比如每个季度或每个月都应该有一个产品要达成的关键目标。

有了团队一致认可的阶段性目标后，当团队分析一个特性或故事时，基本只要看它们与目标的相关性就可以了。只有与该目标强相关的特性或故事才能被优先纳入版本计划或迭代计划中，而与目标不强相关的优先级就往后放。如果这样做出来的计划大家认为不合理，那就要回去重新审视之前设定的目标是否不恰当了。产品的特性或故事是否符合产品规划、是否符合当前的阶段性目标是进行“业务价值”判断的最重要方法。

在基于阶段性目标进行“价值”判断时，建议从“是否不可替代”的角度进行思考，即对每一个特性或故事都问问自己：如果暂时不实现它，我们想要进行的探索能否达到目的？想要改造的业务流程能否实现？用户的期望能否得到满足？是否可以暂时采用其它替代的手段达到同样目的？

如果我们每一次都把目标设定得足够小，这样的思考就可以帮助我们排除很多暂时价值还不够高的工作，从一堆看似都和当前目标相符的特性或故事中找出真正价值最高的部分，从而更快将一个版本交付出去。

总结

上面分别谈了谈进行业务价值判断时需要认真思考的几个角度。可以看出，进行价值判断需要考虑很多因素，但如果为了避免判断错误却花过多时间进行讨论，而迟迟不去实践，反而会错过实现价值的机会。在互联网和传统企业都努力追求创新的的今天，需要的是快速迭代与反馈验证，以及基于反馈的快速调整；而所谓准确的预测、判断并不能有效避免失败，只有基于快速反馈验证的迭代式演进才能降低可能失败的风险。

最后，需要注意的是，所有这些分析和判断都是在特性或故事被实现之前进行的，是一种预测。而预测是导致绝大多数失败的恶魔，只有实践才是检验真理的唯一标准。

第65讲 | 如何打造高效的分布式团队？

在如今全球化趋势下，因为业务需要或人才竞争，许多互联网公司都建立了远程团队或者说分布式团队。但分布式团队在日常工作中确实会面临许多问题，需要付出更多的努力来克服距离带来的内在挑战。

挑战一：如何增加分布式团队之间的熟悉度和亲密感？

Doximity 工程部门副总裁 Bruno Miranda 表示，和队友尽快建立个人联系非常重要。我们会要求新员工至少第一周要来办公室，和总部的团队见面，一起吃午餐，最重要的是和他们的导师建立个人联系。我们也鼓励远程员工不时地来办公室，这样的线下碰面对各自的团队都是有益的。

另外，我们每个季度都会抽出几天时间把团队成员聚在一起，回顾之前的工作，分享经验教训，提前规划下季度的工作等。这样每季度一次的聚会也让我们有时间进行面对面的团队建设，如滑雪、骑马等，高质量的休闲时光，也强化了同事之间的个人联系。

除了面对面的团建外，我们也鼓励各地的员工在线上围绕感兴趣的话题进行即时交流。话题可以非常宽泛，从滑雪到游戏再到音乐都可以。这类对话通常是和业务不相干的，只是提供一个非正式的讨论媒介，让人们有个地方可以增进个人关系。其作用有点类似于公司里的茶水间，为人们增进关系提供了一个舒适的地方。

Passive Management 公司创始人 Janis Janovskis 表示，关键是要强调沟通的重要性，鼓励人们将他们当前的状态分享给他人，例如他们是感觉受挫、焦虑或是快乐等等；也要鼓励团队成员将他们的状态变化告知其他人，例如他们是打算去吃午餐或是去倒杯咖啡。在办公室中，彼此能看到的一切状态都是透明的，但对于远程团队来说，就必须通过一些沟通协作工具分享自己的状态，来保证成员间的亲密感。

另外可以增加虚拟的线上聚会，比如视频会议，但尽量不要为了某些平淡的话题而进行视频会议，而是要仔细挑选主题，比如让团队中的某人为某个有趣的话题准备 10-20 分钟的演讲。甚至可以选择一些主题让成员轮流演讲，给团队中的每个人都有发挥的机会。

挑战二：如何做好分布式团队的项目管理？

Bridge Global 创始人 Hugo Messer 表示，前提是要让分布式团队的成员都清楚他们正在执行的项目。然而在现实中，我们会发现很多远程团队对他们正在搭建的产品完全不了解。对此，我们可以问自己和团队成员以下几个问题：

是否位于所有地方的团队成员都了解业务层面的产品愿景和项目情况？

是否每个人对产品的定义都相同？

是否所有团队成员都参与到了制定产品愿景、创造项目路线图和 backlog 细化研讨会中？

产品愿景和项目路线图是否对身处各地的所有团队成员都可见？

是否所有团队成员都直接与业务相关者和用户紧密合作？

作为管理者，我们可以通过各种项目管理工具、协作工具将产品内容和项目进度与分布式团队成员共享，更要有意识的让他们了解更多有关项目和产品的信息。

敏捷专家 Tanya Kumari 则表示，要制定一个连接各团队的项目路线图。分布式团队意味着成员所处的空间甚至是时间不同，这让计划变成了一项挑战，因为你无法像了解身边的团队那样了解一个远程团队。

因此，我们需要制定一个项目路线图来传达行动计划，不管团队成员身处何方，都可以通过这个路线图来了解项目或产品是如何随着时间推进、演化的。在这种情况下，类似滚动计划这样的方法就可能更有效，对于时间上比较近的事情就详细地计划，而时间上比较远的事情就做大概的规划。

这样一份在多个团队之间共享的计划将为团队的日常工作提供一个关键的上下文，并对竞争环境的变化作出响应。我们所要做的是把它分解到月、周、天，定义每天的可交付物，对于最终目标的实现负责。

Kumari 还表示要打造有意义的自动化。当项目时间比较长，或者需要管理远程团队时，创建一套自动化流程就特别有价值。自动化可以从多个方面节省时间：它可以快速跟踪整个交付过程并报告这个过程，让过程尽可能地高效、简洁，并赋予参与者责任感等。

如今，不少厂商都提供了构建自动化流程的工具，不过投资一种综合性工具，可以减少不同过程中需要的工具，确保过程不会重复。例如，Jira 就是团队规划并构建优秀产品的一个跟踪器选项。许多团队选用 Jira 捕获并组织问题、分配工作及跟踪团队活动。

以奥迪为例，奥迪在全世界雇用了数以千计的工程师、设计师、软件开发人员和 QA 团队，办公室遍布全球，但它的研发中心（R&D）都在德国。2007 年，他们开始用 Jira 跟踪问题，并用 Confluence 管理知识，如今，这两个工具被用来支持所有的团队和项目。例如，在路试场所，测试人员在试车过程中会把软件缺陷记录进 Jira 中。而除了跟踪外，团队会使用 Confluence 存储文档、部门协议、会议记录、政策法规等，帮助企业保持高效、透明。

除此之外，还可以使用 Google Drive 作为文档库，进行文件共享；使用 Bamboo、BitBucket 等作为版本控制工具监控和推送代码；使用 Slack 进行实时、有感染力的谈话，以便快速进行评审、修改、决策等。

挑战三：如何解决沟通协作问题？

如今，技术不断发展，视频会议、屏幕共享以及异步通信的广泛应用帮助我们实现了这种便利的工作环境。Bruno Miranda 表示，他们在测试了六种解决方案后，最终选择了一套自己觉得效果最好的技术。

视频会议：我们的会议室中都配备了 ChromeBox、会议系统和一个大型的壁挂电视。ChromeBox 直接集成了谷歌日历，让参与会议变得轻而易举。我们以前试过其他的系统，如 Skype 和 HighFive 等，但对于我们来说，它们未能提供与谷歌日历的稳定集成。

异步聊天：市面上有不少聊天工具，我们选择的是 Slack，因为它提供了我们需要的集成，可以把工作统一到一个平台上，包括来自 DevOps 栈的警示讯号、日历提醒、自动回复等。

屏幕共享：在促成分布式沟通方面，屏幕共享无疑是其中一项比较显著的技术改进。不管我们是在帮助同事解决一个配置问题，还是结对编写一段比较难的代码，亦或是仅仅共享一个幻灯片，可以快速共享屏幕的能力会让整个过程变得更愉快。Slack 内置了语音电话和屏幕共享，它甚至允许任意一方控制另一方的屏幕。

语音呼叫：异步的文本聊天很有效，但对于沟通来说，文字并非最有效、最直接的方式。我们测试了几款在线语音呼叫工具，最终还是选择了 Slack，因为它已经是这个工作流中不可或缺的组成部分。Slack 让我们有能力从文本聊天快速、无缝地转到语音呼叫，再到屏幕共享，再到视频。

除了以上提到的这些，市面上有很多不同的沟通协作工具和技术，包括国内的 Tower、Teambition、明道、钉钉等，大家可以在尝试后，根据自己公司或团队的业务特性选择最适合自己的沟通协作方式。

结语：打造一个高效的分布式团队存在一定的成本和学习曲线，但业务需要和人才竞争让分布式团队变得越来越普遍，因此，对于技术管理者来说，如何不断改进流程，建立高效的分布式环境，让信任、协作和创造性流行起来，已经成为管理中的必修课。

那么你是否在管理分布式团队呢？你是如何让团队高效协作的呢？欢迎留言与我们探讨。感谢你的收听，我们下期再见。

第66讲 | 如何打造有活力、持续创新的研发团队？

你好，我是运满满 CTO 王东。今天想跟跟大家分享的主题是如何打造有活力、持续创新的研发团队。

运满满是一个车货匹配的货运调度平台，也提供很多增值服务，整个行业非常大，发展非常快，因此对技术和团队也提出了很高的要求。

在具体的执行中，我们花了大量的心血，从业务支撑、技术驱动、文化塑造和团队建设这四个方面出发，打造一个有活力的、持续创新的研发团队，以支持业务的快速发展。

一、业务支撑

快速发展已经成为互联网公司的一种共识，那么在快的情况下，怎么面对业务支撑？尤其是当业务多，团队人手不够，大家又想做技术驱动、平台升级的时候。

我们的做法是跟大家做了一个共创，把业务分成日常项目和重点项目。在互联网领域，所谓重点项目就是能影响市场抢占度，甚至影响公司成败的项目。因此，对于重点项目，我们有一个明确的要求，即 0 排期，让重点项目能够随时启动、快速上线，以雷霆之势赢得战略优势。

以运满满为例，我们是一家强运营公司，前线销售人员面对的情况多变，因此他们的 KPI、运营方式、所需的数据支撑也一直在变，这就需要 CRM 系统也能跟上这种变化速度，给他们最大的支撑。

面对这种情况，我们就把 CRM 建设作为重点项目，高速迭代，在 3 个月内完成了 58 次发布，支持 14 个业务扩展了 109 个需求。

这是我们最根本的态度，重点业务一定要好好支撑掉，然后才会去做技术驱动。

如何保证业务支撑

那在具体执行层面，如何保证业务支撑呢？毫无疑问，架构和技术是基础，但你会发现架构永远跟不上新业务的发展。这时，在平台化还没有实现、工具化还没有完善的情况下，我们就需要先靠项目管理和人员素质来解决这个问题。

首先，要理顺整个项目管理流程和节奏，我们有几个原则，包括早进入、并行化、反向推动、Deadline、公告等。

以并行化为例，在开始聊想法、MRD、运营计划的时候，核心产品经理、核心架构师、核心设计师要同步参与；在出商业计划的时候，基本的整体架构设计就应该已经完成了；在出产品 PRD 的时候，基本的概念设计就应该已经完成了；真正到开发的时候，测试用例和自动化测试脚本等就应该已经同步的完成了。尽量分解并行，以此来提高效率。

其次，要打造项目机动组织。举个例子，大家排期的时候经常会提到人员不够，我们的做法是对整个团队做一次大的封闭培训，要求大多数成员特别是高 T 的同学要非常熟悉每个系统，尤其是核心系统。这样，当某个系统模块比较紧急需要人手的时候，我就可以随时把其他系统的人调过去，尤其是高 T 的同学，他再带上两个研发的话，可以快速的把这个模块做起来。

对于一家较大规模的公司来说，人员肯定是不缺的，关键在于组织是否足够机动，能否做到员工兵力的机动调配，去支撑重点项目，尤其是脉冲型重点项目。

除了这两点，还需要其他项目管理原则、项目公约、项目同步机制等，通过共享的方式，让大家都能看到项目进度，都能参与进来，真正做好项目管理。

业务支撑遇到的问题

在保证业务支撑的过程中，我们会遇到各种问题，最典型的有以下 3 种：

过来的所有需求都说非常重要、非常紧急，但是拼完上线了，业务那边却不做数据反馈或者根本不用，团队这边也不知道效果到底怎么样。

因为都是机动支撑，做完这个版本，也不知道下个版本做啥。

团队也想给业务打枪造炮，但看不到业务蓝图、路线图和运营思路，感觉就像高级外包一样，完全没法和业务一起思考，一起做系统架构，导致没有成就感。

为了解决这些问题，我们和团队又完成一次共创，提出了一个概念，即由单纯只关心“技术指标”的“需求翻译机器”、“架构优化机器”，转变为从技术视角去推动平台业务发展的业务架构师。不断锻炼“寻找技术和业务完美结合点的敏锐嗅觉”，保持“跨界”的核心竞争力。这个概念最初是天猫架构负责人大少提出来的，当我们再次用在满满团队，发现也非常适用。

具体到执行层面，可以从以下几个方面出发。

了解你的用户，我们会让研发团队到前线去跟真正的用户接触，做前线业务同学、运营同学做的事情，听他们的声音。同时要重视用户的反馈，我们的做法是每两周会把所有在线用户的问题拿出来分享给整个团队，让他们去了解用户的需求。

体验你的产品，我们会强行要求每个同学都得用自己的产品，频率可以不高，比方说一两周一次，但一定要亲自去使用，同时要注意在使用的过程中提出问题。

关注线上数据，同样也是要求每个同学都关注线上数据，还会不定期抽查，比方说上线了一个新模块，那这个模块最近数据怎么样了？涨和跌的原因是什么？数据的变动又跟哪个项目有关系等。

懂你的行业，这方面我们也做了很多举措，比如汇集行业资讯，开展行业分享，引入行业专家等。通过这些方式，让大家了解这个行业究竟是怎么运转的，也真正了解业内司机的痛点。当我们足够了解对方的时候，大家才会带有情感和思考的做事。

心中有一张大图，即做每一个功能都要思考整个架构，思考业务的运营，而不是只做单点思考。同时，还要思考要实现这个功能，底层需要有哪些支撑等。

当每个研发人员脑袋里都有一张完整的大图，同时又很懂行业、懂用户，他的参与感就会很高，这些是我们经历过共创、碰撞后提出的硬性要求和做法，目前执行下来效果非常不错。

二、技术驱动

前面提到，我们通过种种措施很好的支撑了业务，但技术同学不仅仅想要得到业务上的成就感，还希望得到技术上的成长。那怎么帮他们寻求成长，并且与真正的商业结合，让公司认可呢？

1. 架构升级，包括服务化、中心化、中间件、平台化等

架构升级对于整个研发的拉动作用是非常明显的，以大家都在做的服务化为例，拆分完之后，模块直接松耦合，可以独立发展和演变，团队也能快速扩张。像运满满一开始也是一个 All In One 的 App，后来服务化拆分之后，团队就可以迅速打起来。

服务化做起来之后，一定要跟上中心化、平台化，底层一定要有一个很强大的中台做支撑，这样才能支持新业务的快速扩张，也能支持已有业务的快速变化。之后还可以去思考怎么在平台里去做业务监控、做数据分析等，慢慢会沉淀出很多中间件。

所以，整个架构是在不断演进、不断升级的，这对于技术同学来说就是一个很好的 Topic，激发大家的激情，让他们自驱动的去思考还可以做什么，来让效率更高、稳定性更强。

2. 工程效率，包括动态化、配置化、工具化、自动化等

工程效率对业务会有比较直接的支撑，而我们做技术驱动的整体思路，就是把工程效率中的每条线、每个子模块，都去做动态化、配置化、工具化、自动化。

从发布到运维，从测试到自动化，我们大概做了六七十个系统来打造我们的工具体系。这样一个工具体系的打造，首先大家会有成就感，自己做出的工具有效的帮助自己提高了工作效率；其次这些事情都有一定的技术挑战和技术深度，让整体团队的技术氛围得以增强。

3、稳定性，通过系统保障系统

稳定性是研发不变的一个主题，当公司体量越来越大的时候，稳定性就越来越重要，可能一个功能宕机 5 分钟，就有几万通电话打进来。在稳定性上，除了形成很多固定的流程机制外，我们还通过系统来保证系统，包括测试 / 灰度、降级 / 容灾 / 回滚、监控告警等。

4、用户体验，包括性能／交互、可用性、新 IO、安全特性等

稳定性和工程效率是研发中两个基础的部分，能够在早期和中期很好的带动研发技术氛围，但最性感的还是用户体验。

用户体验是非常大的一个课题，需要长期的去监控、去治理。除了已有性能的不断优化外，我们还可以采用一些新技术来提升用户体验，比如当前很火的自然语言处理、人脸识别等。

以自然语言处理为例，它的知识图谱跟所处的行业有着密切的关系，比如我们就用它来做智能助手、智能客服，帮助司机解决使用问题，甚至帮助他们语音发货等。

这就是新技术跟行业、跟产品的结合点，而对技术团队来说，每一个结合点都是一个很好的技术驱动的方向。

5、运营效率，包括系统化、智能化等

每家公司不一样，运满满的运营基因很强大，大概有 3000 多名运营人员，所以怎么提高运营效率，怎么让他们更高效的获取用户、服务用户、拓展业务，也是我们的工作重点。

从这个维度出发，也能衍生出很多 Topic，比如各个系统怎么去做自己的优化，通过系统化、智能化的手段大幅度提升运营效率。

值得注意的是，我提的这几个方向并不一定适用于每个公司，只是提供了一个思路，沿着这些方向去思考，总能找到适合自己的做技术驱动的方式。

最后，我们期待的团队必然是充满活力创新，每个人都在贡献 idea，尝试优化产品和系统，参与到业务创造以及技术改变商业的过程中来。今天主要聊了如何从业务支撑和技术驱动这两个方面出发打造这样的理想团队，希望我们的一些做法能给大家带去参考。

作者简介

王东，运满满 CTO，资深技术专家与管理者，曾先后负责过 10 多条亿级用户的产品研发管理工作，历任天猫高级技术专家、360 高级总监、百度主任架构师，有过两次创业经验。

第67讲 | 如何打造独属自己的工程师文化？

你好，我是运满满 CTO 王东，今天想跟大家分享一下如何打造并落地适合自己的文化。

之前的文章中谈到了业务支撑和技术驱动，这两点是打造有活力的、持续创新的研发团队的基础。除了这些自上而下的推动外，很重要的一点是通过打造优秀的工程师文化，激发研发团队成员的自我驱动力，让他们由内而外的真正去思考公司业务的发展和创新。

文化是什么

谷歌、Facebook、亚马逊等都有很强的工程师文化，以亚马逊为例，它的工程师文化包括：通过解决问题来改造世界、基于事实与科学规律、实践务实、逻辑的、专业的、创造性、不断的更新知识、好奇心驱动、对质量的重视、注重效能与效率、交流与传播等。

我们经常跟国内外的公司交流，学习他们的文化和做法。交流是一个非常重要的打开团队思路的方法，给团队制定目标之后，除了让大家自己思考之外，也要让大家多多出去交流，看看其他公司是怎么做的，开开眼界。

谷歌、亚马逊等公司的工程师文化的确非常好，但这不代表我们能全盘学习、拿来就用。每个公司都有自己的独特之处，因此，每个公司都应该有自己的文化，要结合自己当时的状态、行业的状态，以及未来发展后的状态，来定义自己的文化。

如何制定文化

那运满满的文化应该是什么样的呢？我们一方面学习和借鉴了很多优秀的文化，一方面也在思考属于自己的文化应该是什么样的。在具体的操作上，我们管理层进行一次共创，确定了以下几个方向。

一、有担当

我们是一个运营基因很强的公司，需要把业务支撑的特别好，又是一个典型的分布式系统，系统大了之后，有上层、有底层、有中间件，每个人都要 Owner 一个事情或系统，那这之间的权责怎么划分，沟通怎么解决都是问题，所以第一点就是有担当。具体来说：

对于自己 Own 的事情和系统负责，不是简单的别人给你派活，你来做，而是要有强烈的责任感，出了问题要第一时间跳出来想解决方案，而且要一竿子跟到底去真正解决问题。

要去总结和思考自己 Own 的事情和系统，看怎么才能把它们做的更好，是沿着业务支撑的方向走，还是沿着技术驱动的方向往前走。

要推动自己 Own 的事情和系统去跟外部合作，并拿到结果。

要站在客户的角度去思考问题。

二、执行力、速度感

国内的互联网迭代速度快，竞争激烈，格局此起彼伏，以运满满为例，我们有车货匹配这个 Idea 的时候，市场上大概有 100 多家公司在做类似的事情，而且很多事情先做和后做可能就是一个颠覆性的变化。那我们怎么才能制胜？因此我们提出的第二点就是有执行力和速度感。

但要注意的是，执行力和速度感并不是加班，而是要擅总结、有方法。就是你要不停的熟悉项目和系统，主动总结和思考，去发现问题和改进问题，然后主动去沉淀出相关的技术和工具。

这才是真正执行力和速度感，是来自你清晰的思路和深厚的功底，是一个厚积薄发的过程。

三、有挑战、做精彩

之前提到的两点，是我们为了应对公司当时的状态，对大家提出的要求。同时，我们觉得谷歌、Facebook 等公司让工程师们向往，是因为它们是真正有技术创新和活力。而运满满的技术驱动也变得比重越来越大，很多技术会直接产生用户价值。因此，我们提出的第三点就是有挑战、做精彩。

具体来看，一是要弄清楚重点是什么，必须要在重点事情上拿结果；二是要提出和做到有挑战的事情。

现在很多公司都在用 OKR，但我们考核的可能不是你 OKR 的达成率，而是你 OKR 的挑战性或者精彩性。我们可以从你的 OKR 中看出你想创造的价值是什么？实现的思路是什么？思路中有几个核心问题需要解决？具体打算怎么解决？

如果能把这些都想清楚，做出来的 OKR 自然会比较好。对于那些先定一个不太难的 OKR 的做法，哪怕把它完成了 120%，我们也并不赞同。

四、大声说话、开放皮实

很多国外的互联网公司，包括国内的阿里等，有个特别好的文化是员工之间开放交流，思想碰撞。大家对如何做好一件事情有不同的看法，在交流、碰撞的过程中，就能把自己的方案逐渐完善。

所以，我们提出的第四点就是大声说话、开放皮实，鼓励大家乐于和勇于把自己的观点表达出来。包括我们在员工晋升、表彰的时候也会考虑这一点，看他是不是愿意表达自己的观点。因为表达观点一般代表他进行了思考，有自己的想法，尤其对工程师而言，当他们有思考、有想法的时候，一般都会愿意表达。

同时，越有想法、越爱表达的人，我们越会考虑对其重点培养，会基于他的思考跟他有针对性的沟通，告诉他怎么样能思考的更深入，让想法更具可行性等。

以上这些就是我们当时定义文化是的思路和做法，其实是兼容了国内互联网公司要拼、要快的风格和一些国外互联网公司要创新的思维。

当然每家企业都不一样，我只是分享了我们的做法，提供了一些参考思路，最主要的还是结合自身公司业务的重点、团队发展的重点、对未来的期望等，创造和融合出属于自己的文化。

文化如何落地

文化定义出来后，该如何落地呢？毕竟改变一群人，让大家认同团队文化并将其当作自己的观点是一件很难的事情。

我们的做法是又进行了一次共创，当然不是直接把结果告诉大家，而是带领团队去思考。没有这个自己思考的过程，团队不会认同你，或者即使表面认同了，内心也会有疑问。当时，我们提了一堆问题供大家思考，包括：

什么样的研发就算一个好研发?

什么样的测试就算一个好测试?

什么样的运维就算一个好运维?

我们认同什么样的人？

我们 Hire 什么样的人？

我们做什么样的 Leader？

捋完这些问题之后发现，大家对于“好”的定义和认知是一致的，然后，我们又把它提炼精炼了一下，首先在管理层上达成了共识，定下对于“好”的定义。管理团队达成共识之后，接下来就是推广到全体员工。

首先，管理者是关键，要律人律己。

具体的做法上，一是要根据之前的共识确定选拔标准，不再是之前简单的能把活干了就 OK，而是要看他是不是够快，是不是有创新能力，这些将成为提拔人才的标准。

二是各个管理层隔几个月要做一次群 Review，反思自己哪做的好，哪做的不好，先保证 Leader 层面的味道。这样就形成了一个机制，管理层能对文化有比较清晰的认知，如果有员工不符合团队文化，他们也会比较敏锐的感知到。

其次，落地到员工。这不是简单的弄个文化墙就能搞定的，而是要落到具体的关键事情上。

1. 树榜样、荣誉体系

我们每三个月有一个开放日，会跟大家讲一下公司的目标、规划和发展情况，以及下一个季度技术和产品的规划等，同时会对优秀员工进行表彰，设立的奖项则完全匹配之前提到的文化。

比方说有担当奖、最快执行力奖，这个一般是给打了攻坚仗的项目，同时会让这个项目总结他们是如何有速度感、快起来的，在管理、执行上沉淀了哪些工具和措施。

还有创新奖，主要看大家有没有自己的 Idea，能不能想出对用户有帮助的功能，或者行业里边哪些技术可以和我们结合。这些都是荣誉上的，我们会大力打造荣誉体系，并树立榜样来进行鼓励。

2. 员工 One One、项目管理

我们会跟员工做 One One 的深度沟通，对于我们追求的快、速度感、执行力、Ownership 等特质，他们究竟做的怎么样，有哪些地方值得表扬，有哪些地方需要加强等。另外在项目复盘的时候也会复盘这个东西。

当你鼓励什么的时候，什么就会生长起来，当你反对什么的时候，什么就会消失掉，如果你一直鼓励这些文化，它们就会慢慢深入到每个人心中。

3.Hire、Fire

作为管理者，有时候还是需要比较坚决的，因为文化这个事情并不是每个人都能认同和融入的，但不认同并不代表他不好，也许只是不适合。

所以，在这件事情上要坚决一点，对于认同我们、在这儿做出贡献的人，我们就一定要对得起他；如果大家真的观点不一样，那还是尽早分开，避免更多的沉没成本。

这样也是避免被底下的同学影响，因为我们要的是影响而不是被影响，是感染而不是被感染。

最后，我们通过一年多的运营，成功把这些文化贯彻了下去，希望我们打造文化并将其落地的过程能带给你一些启发。

作者简介
王东，运满满 CTO，资深技术专家与管理者，曾先后负责过 10 多条亿级用户的产品研发管理工作，历任天猫高级技术专家、360 高级总监、百度主任架构师，有过两次创业经验。

第68讲 | 如何打造一个自组织团队？

敏捷宣言的原则中提到，“最好的架构、需求和设计都出自自组织团队。”这带来几个问题：什么是自组织团队？我们为什么需要它？又该如何领导一个自组织团队呢？

什么是自组织团队

技术人是典型的知识工作者，他们需要解决全新的问题，需要具备较强的学习知识和创新知识的能力，他们的劳动兼具知识性、创造性、灵活性等多种特性。

因此，对技术人来说，通常只能管理目标，而不好以严格的操作规范来管理过程，同时，他们必须要自我管理，必须要有自主权。正如 Scrum 指南中说的，“自组织团队要自我决择如何最好地完成他们的工作，而不是由其他外部团队来决定。”

具体来说：

给予自组织团队令人信服的使命，并为他们指定清晰的边界，与其他组织单位、资源达成一致。

在一定的边界范围内设立团队自己的规则，并且确保所有人遵守。

在这些边界内给予自组织团队自管理的权利，不需要定向控制和监督，由他们自己监控和管理自己的进度。

可以给自组织团队安排一个目标，并查看他们的进展如何，不过你只需要在他们需要的时候提供帮助。

自组织团队想要知道，并且知道项目和产品的所有内容，理解需求，不会害怕提问题或提出建议。

自组织团队有主人翁意识和承诺意识，他们对自己的工作感到自豪，并承担相应的责任。
7. 自组织团队利用成员所有领域的专业知识，演化、调整并且能够解决广泛的任务。

为什么需要自组织团队

当今社会正经历着巨大的变迁，而这些变迁带来了新的挑战，可以说，我们正面临一个易变的、不确定的、复杂的、模糊的世界。

而一个组织要想成功，就必须充分利用这些变化带来的机遇，同时对危机有足够的准备。如此，管理者就不可避免地要去应对无穷无尽的不确定性、不可预测性和各种风险。

面对这样的情况，“业务敏捷性”成为必须，作为技术领导者，要充分利用手上的机会，要充分挖掘新的可能性，以逐步建立竞争优势。

而自组织团队是敏捷的一种体现，它比微观管理的团队更加高效地协同工作，团队成员接受新事物、学习新知识的能力更快，他们在工作中的动力和得到的乐趣也更大，因此，在人才极度宝贵的软件行业，自组织团队会带来更高的回报，传递更多的商业价值。

此外，自组织不仅是一种团队形式，更是一种管理手段。在此前已经固化的业务流程中，管理者必须自己一手设计出一个高绩效的团队。他必须有能力设定明确的目标，建立正确的决策模式，有效调配资源等。不少团队依旧遵循着这种管理模式和价值观。而在自组织的管理模式中：

提倡自我控制的现代文化取代了旧式的命令和控制手段。

专注于自我控制，是为了表达对知识型工作者的尊重，并充分利用他们能力的唯一途径。

新型的面向关系网的领导方式，与面向层级的管理方式并存，目的是为了充分利用专家资源，并能够对环境变化作出快速响应。

鼓励分散式的决策，同时，运用可视化管理了解全局、建立快速反馈通道、精心选择团队绩效指标，以使各个团队更加齐心，并激发他们内在的驱动力。

如何领导一个自组织团队

如果我们同意自组织团队就是我们需要的和想要的，那么接下来的挑战就是如何建立并领导一个自组织团队。

1. 授权给团队

内外部各种因素都表明我们必须要改变我们组织的运营方式。为了变得更敏捷，我们必须把权力和权威交给更贴近客户的人，并充分授予他们信息，给他们时间思考、学习并改进。

要达到这些目的，唯一的办法就是授权给我们的团队，让他们竭尽所能，不仅仅是完成指派工作任务，而是要激发他们的创造力和自我驱动性，让他们自我决定、自我执行、自我监督、自我控制。这是一种自然而然的尊重，技术人，也就是知识型工作者，必须要有自主权。

另外，自组织团队不是一夜之间就能崛起的。自组织对赖以生存的土壤本身就有各种苛刻的要求，更不用说还时常被微观管理所妨碍，也受累于缺乏工作流程设计，所以想利用自组织流程，必须进行彻底的变革。

同时，团队的自组织过程是永远不会结束的。他们必须持续地、用感知和响应的方式调整需求和上下文来重组自己。换句话说，自组织团队是一个进行中的过程：每一次的设置更改，组织和团队就需要重复整个过程。

2. 允许自治

我们用足球队来打个比方，一旦比赛开始，一支足球队就是一个按着特有方式变化着的自组织单位。要成为一支成功的队伍，即赢得比赛，队员需要有互相帮助的意愿和能力。这需要多方面的技能：

能够专业地理解和把握自己在团队中的具体角色（门将、后卫、中场、前锋），以及为了成为一个真正的团队，这一角色应该如何与其他角色进行配合。

动作和控球技巧，比如跑、冲刺、拦截、弹跳，以及传接球、盘带、过人、射门等。

战术，对整场比赛以及每次配合流程的理解，比如在不同情况下，每个球员必须决定是参与进攻还是留在后场进行防守，在正确的时候出现在正确的位置上。

战略，能够具备对当前球场形式的大局观。能够阅读比赛的局势并采取相应的措施。无论球场上的形式变化是由队友还是对方球员触发的，都能够立即做出响应。

那教练的角色是什么呢？他是否控制着比赛？他是否操纵着他的团队？他是否监控着每个队员的活动？他是否真正参与其中？实际上，他的影响力是有限的。

无论教练是否足够大牌，哪怕他在教练区急得上串下跳，冲着关键球员发号指令，但他没有任何机会去控制球场上正在发生的一切。球队的成功只能靠场上队员的努力才能达成。

这是否意味着教练是多余的呢？当然不是，从一个系统的观点上看，教练对球队的组成、战术、训练计划、踢球风格等等产生着深远的影响。在比赛中，他能够换下一些队员，也能够利用中场休息时间对上半场进行反思并布置战术。

有趣的是，教练最主要的任务是观察，他们观察每一个球员自身的表现与球队的配合，以及和对手对抗的情况。此外，教练会根据观察结果提供专业的反馈。从某种程度上说，教练的主要作用是通过搭建提供积极反馈的回环，创建正确的意识。正如自组织团队中的领导者一样。

结语：我们观察到，这个世界唯一不变的就是变化本身，所以我们需要“业务敏捷性”。而我们过去运作组织的方法已经过时了，那些由教练式领导者指引的自组织团队才是新运转体系的核心。而在这一组织形态下，权力下放和允许自治是让知识型员工重拾和保持工作热情的必要措施。

第69讲 | 茹炳晟：QE团队向工程效能团队转型的实践之路

你好，我是茹炳晟，目前担任 eBay 中国研发中心测试基础架构技术主管，今天想跟大家分享的话题是 QE 团队向工程效能团队转型的实践之路。

在软件开发和项目执行中，工程效能问题一直是技术管理者考量的关键。加快研发效能和提升工程师团队效率及质量，需要在软件智能化上迈出创新步伐。

目前，包括 Google、eBay 等跨国互联网公司的研发团队都在经历“去除 QE（Quality Engineer 质量工程师）”的组织架构转变，为此 Google 也暂停了 2017 GTAC 并寻求向 Engineering Productivity 即工程效能的转型。相应地，QE 团队也正在逐渐向工程效能团队转型。

工程效能团队的好处在于，假如你的研发团队规模为 100 人，那么工程效能团队可能需要 15 个人，但当你的开发团队翻了 10 倍，达到 1000 人规模的时候，工程效能团队的人数可能仍旧是 15 个到 20 个之间。

所以，随着开发团队人员的增多、规模的增大，工程效能团队的输出和价值会越来越大，这也是为什么很多大型互联网公司、尤其是全球性的互联网公司都热衷于采用这种模式。

如今，谷歌等国外大的互联网公司已经基本实现了向工程效能的转型，国内虽然具体的实践还不多，但很多公司都在做类似的尝试。

在这种模式下，整个测试策略发生一个变化。传统的测试由 3 个部分组成，底层是单元测试，中间是 API 测试，最上面是 GUI 测试，是一个类似金字塔的三角形。其中，单元测试由开发人员来负责，API 测试和 GUI 测试都由专职的 QE 或 QA 来做。

但到了工程效能模式下，除了单元测试，API 测试和 GUI 测试也将由开发人员来做。这意味着，开发人员需要兼任测试的角色，克服从开发到测试的思维局限性。同时，还需要一个很高效的测试平台基础架构，提供一个便捷的测试执行环境，以支持开发人员方便的获得测试数据、执行测试。

原本的功能测试团队则蜕化成现在比较热门的探索式测试，测试开发人员则转变成工程效能开发的角色，去做测试平台相关的开发。

在这个转型过程中，如何运用原本 QE 团队积累的技术优势来设计和构建高效的测试基础架构就变得尤其重要，本文将着重分享如何通过架构演进来改善测试执行环境，以达到工程效能的提升。

测试执行环境之疼

为了提升工程效能，一般会对测试执行环境提出以下要求：

第一点，对使用者而言, 测试执行环境的“透明性”。所谓透明是指，假如我今天要用测试环境跑一个 Mobile 的 Native 测试，需要某个版本、某个分辨率甚至某个品牌的手机，但这些设备不需要自己准备，只要提供相关的参数，后台就会帮我把其他事情准备好，并且把相应的测试分发过去。对使用测试环境的人来说，他希望整个测试执行环境是透明的。

第二点，对维护者而言，测试执行环境的“易维护性”。所谓易维护是指，不希望有上千甚至上万台机器的测试执行环境需要人工维护。因此，我们引入了容器化技术，用 Docker 来准备整个测试执行环境。

第三点，对于大量测试用例的执行而言，执行能力的“可扩展性”。引入容器化技术之后，可扩展性自然而然就解决了。我们会根据单位时间内测试用例的排队数量，通过算法来决定这个集群里需要多少台机器才能在规定的时间内执行完全部测试用例。这样整个集群的伸缩也全部由自动化工具来完成，能做到对使用者完全透明。

第四点，Mobile 移动终端的多样性与碎片化，这使得搭建一个包含各种 iOS 和 Android 设备的集群成为挑战。

这些都是测试执行环境会面临的问题，我会分享一些我们的实践，以及我们是如何通过架构演进来不断完善测试执行环境的。

第一版：基于 Jenkins 触发测试执行

这是最早也是最典型的测试执行环境，即基于 Jenkins 触发测试执行。我们把测试用例放在 Github 中，Jenkins 会去获取这些用例，再在远程固定的测试执行环境中去跑这些用例。

第二版：基于 Test Runner／Test Execution System

因为 Jenkins 中跑测试的脚本会越来越多，因此，基于第一个版本，我们在 Jenkins 脚本的基础上，封装了一个 Test Execution Service，这个服务会对 Jenkins 中的 Job 进行版本管理、用例管理等，以方便发起所有测试，同时这个服务不仅提供 UI 界面以方便开发的使用和对用例的管理，还提供 Restful API 接口用于与 CI/CD 的无缝集成。

第三版：基于 Selenium Grid 提高测试并行执行能力

原本在整个架构中，远程测试执行环境这一部分是一个固定的测试环境，都是 VM，而在这个版本中，我们用 Selenium Grid 搭建了一个 Hub，可以容纳上百台机器，下面挂了很多包含不同 OS 和浏览器版本的 Node。

Selenium Grid 其实是一个小的集群，这个集群通过一个中央节点来接收所有的测试请求。拿到请求后，它会先去查看该测试请求是要跑在什么操作系统上的什么浏览器上面，再去查看自己的节点里面有没有相应的机器。如果有，它就会把这个测试发到机器上去执行。

第四版：基于 Jenkins Cluster 提高测试并行执行能力

随着测试用例变多，原本远程测试执行这块是瓶颈，但有了 Selenium Grid 之后，这里的瓶颈问题已经被解决，现在当有大量测试请求集中到来的时候，所有的测试用例都开始在 Jenkins 上面排队，Jenkins 的单节点就成为了瓶颈。基于这个问题，在第四个版本中，我们把 Jenkins 打造成了一个集群，解决掉了系统的瓶颈点。

第五版：基于测试负载，用 Docker 实现 Selenium Grid 的动态扩展与收缩

经过前面四个版本的演进，看似整个测试执行环境的基础架构已经比较完善了，但是在 eBay 内部有个很现实的问题，相信不少有全球性业务的公司也会遇到，即我们一套测试用例可以在全球各个站点上执行测试，同一个测试用例如果乘上支持的国家数量之后，用例数据就会爆增。在这种情况下，Selenium Grid 里放多少台 Node 合适就成为了问题。多了的话平时会浪费，少了的话等用例来了又需要排队。

我们的做法是，用 Docker 实现 Selenium Grid 的动态扩展与收缩，做了一个 Auto Scaling 的服务，根据前面的用例排队情况来决定需要多少 Node，动态的去扩张整个 Node 的数量级。

这样做还带来另外一个好处，Docker 化之后自然而然就解决掉了测试执行环境的维护难题，可以通过 Docker 主要维护 Image 镜像，后面的东西全部是自动化的，不需要做太多管理。

除了以上提到的架构演进，我们还通过 Appium 和 Selenium Grid 搭建了一个移动终端的测试执行集群，集群里面放了各种各样的手机设备，开发人员指定要哪个品牌哪个型号的机器，测试系统就会自动到这个集群中搜索，如果有符合要求的机器，系统就会自动把测试发上去，执行完成之后再自动结束。开发人员都不需要知道这个集群搭建在哪里，他只要调用服务就可以使用。

这样一来，对于开发人员来说，他们做测试时就完全不需要考虑测试执行环境的问题，他们只要弄清楚自己的需求就可以了，整个测试执行环境对他们而言是非常透明的。同时，这样一个基础架构的维护成本也非常低，只需要工程效能团队定期维护就可以了。

结语：为了进一步提高软件开发效率，测试环节也是需要技术管理者们重点关注的方向。如今，测试正在经历去除 QE，向工程效能转型的过程 ，在这一过程中，开发人员将更多的介入测试环节，因此如何提供给开发团队简单、易用、高效的测试基础架构就变得尤为重要。本文分享了测试执行环境架构的演进过程，希望能给有意向转型的团队提供参考。

不知道你的团队目前在采用怎样的测试策略呢？测试执行环境又是如何搭建的呢？欢迎留言分享。

感谢你的收听，我们下期再见。

作者简介

茹炳晟，eBay 中国研发中心测试基础架构技术主管，具有超过 12 年的软件测试经验和 3 年开发经验，和丰富的测试框架设计与自动化测试经验。另外，他还在【极客时间】开设了专栏“软件测试 52 讲”，系统梳理软件测试的知识体系。

第70讲 | 王昊：技术、产品、管理的不同视角

你好，我是 bilibili 主站技术中心总经理王昊，今天想跟大家分享的话题是技术、产品和管理的不同视角。

我们在工作中难免会跟技术、产品、管理等角色打交道，那么不同角色的世界观有什么不同呢？怎么平衡多个角色之间的关系，怎么协调多角色团队的工作呢？

技术、产品、管理眼中不同的世界

技术眼中的世界有 4 个关键词，分别是工作、设计、选型、优雅。他会关注自己的设计方案是否优秀；该选用什么样的技术选型才合适，比如是选用 SQL 还是 MySQL；自己的代码是否足够优雅等。

产品眼中的世界也有 4 个关键词，分别是用户、需求、方案、细化。他会要求自己理解用户，了解他们的需求，并满足他们的需求；针对用户的需求提出相应的解决方案，并将方案细化到可执行程度。

管理眼中世界的 4 个关键词则分别是目标、指标、拆解、梯队。他关注的是自己是否能达到目标和相应的指标，如何对任务进行合理拆解并制定阶段性目标，如何建立完善的人才梯队，做好人才储备等。

这三个角色眼中的世界都是不一样的，这导致他们看待同一件事情的视角也是不一样的。

技术人首先看到的是工作，一个确定性的工作，而且技术人特别喜欢解决确定性问题，有输入有输出。一个任务的要求是什么、边界在哪里，确定这些问题之后，他就非常容易把它分解开，并把它完成。

技术人的追求在于，他希望自己在做这些事情的时候，够优雅、够简洁、够高效。而产品解决的往往是非确定的问题，比如好，不好；好用，不好用；流程，不流畅；酷，不酷等，这些都是没办法做具体的、确定性的界定的。

举例来说，工程师面临的问题，可能是把宽带节省 30%，把 QPS 从 1700 提高到 2000 等，都是非常数字化、确定化的。而产品经理不是这样的，他们面临的问题，往往是让用户更满意、让用户觉得产品更厉害等，都是非确定性的问题。

而管理跟技术和产品都不一样，管理面向的是目标，他关注的是指标，比如这个产品月活提高 30%，成本减少 50%，梯队规模控制在 1000 人以内等，都是数字性的具体指标。

由于大家的视野和视角不同，彼此之间会产生很多隔阂和误解，网上很多段子就是由此而来。而避免这些情况发生最好的方法就是加强沟通，具体可以从以下 3 个方面着手。

以团队实现为目标，把自己的视角从程序员拔到更高的高度，从团队价值的角度出发，思考和对话。

换位思考，多去想想如果你处在对方的位置，你会怎么想怎么做，这样的换位思考能有效避免形成误解和误区。

用对方能听懂的语言做表达，很多时候，技术人员习惯用技术语言来表达，比如异地多活很重要，一个典型的技术语言，但产品经理或管理者可能不清楚这个词具体是什么意思。因此，技术人员在跟对方沟通的时候，需要把技术语言翻译成产品语言或指标性语言，比如“在任何异常情况下保持服务稳定很重要”，这样，他们也更能理解你所做的事情的价值。

技术如何转型产品

对于技术人来说，一般有 4 个职业发展路径，第一个是从工程师到研究员到高级研究员，最后成长为科学家，是偏专业研究的一条路径；第二个是从工程师到高级工程师到架构师再到主任架构师，这是偏工程实现的一条路径；第三个是从工程师到项目经理到经理再到部门总监，这是偏管理的一条路径；第四个是从工程师到产品经理到高级产品经理再到产品架构师，这是偏产品的一条路径。

对于程序员来讲，如果最后以 CEO 或 COO 作为自己职业发展的目标，那么可以换一个方向，尝试选择后两条发展路径，试着培养自己的产品思维和管理思维。

先来看产品思维。其实不同产品经理的侧重点各有不同，可能在技术人员眼里，他们都叫 PM，但其实 PM 各有不同，有的偏交互的，做用户产品；有的偏策略的，做商业产品；有的偏运营活动的，还有的偏活动策划型等，每种产品经理的世界也各不相同。不过，所有的 PM 都有相同的特点：

他们都有改变世界的理想，这一点很重要。程序员的理想是什么？是这个事儿做得得酷，未必是我一定要改变这个世界。但好的产品经理不是，他们一般都有一个改变世界的理想，这样才能推动他们前进。

相对理性的技术人员来说，产品经理一般会更偏感性思维，特别是偏交互型的产品经理，他们的 Sensitive 更强，能敏锐的捕捉用户的需求。

在产品经理的思维中，他们会先考虑一切都是可能的，比如飞机不用轨道就能起飞，在他们眼中应该也能实现，因为这样才能放飞自己的想象力，这点跟技术人员有很大的不同。

产品经理常说就差一个程序员了，他们一般不会考虑实现的问题，在他们看来，具体怎么实现，都是可以扔给工程师去解决的。

技术转产品的优势和劣势

以上这些都是我观察到的产品经理思维上的特别之处，跟技术人员有很大的不同，如果技术人员选择走产品这条路，具体该怎么走呢？有哪些需要注意的地方呢？

先来看，技术转产品的话，有什么优势？

技术人员有较强的逻辑思维能力较强；

技术人员知道什么可能实现。

具体来说，技术人员有更强的逻辑思维的能力，就会有较强的全局视野，做事情就会更有计划性，知道怎么把任务做好拆解，在具体执行中分成几步去做更合适，这一点很重要。

同时，因为技术人员知道什么可能实现，他就不会被技术团队忽悠，反之，一个不了解怎么实现的产品经理很有可能会被他的技术团队忽悠。做到以上两点之后，技术人员就能从源头开始强有力的把控整个项目的进展，这是非常重要的优势。

接着来看，技术转产品的话，劣势在什么地方？

太过注重可实现性。这在技术人员做工程的时候，是一个很好的优势，但当他进入另外一个角色的时候，就可能变成劣势。因为太注重可实现性的话，就会限制自己的想象空间，会被制约想象力。因为很多东西在一开始的时候都是不可实现的，而正因为它们当初的不可实现，才给了我们更多的机会。

缺乏同理心。在技术人员眼中，世界一般都是客观的、数字化的、Coding 化的，但是真实的世界都是由人组织构成的，所以需要我们用心去感受别人是怎么想的，这个功能为什么用户喜欢或不喜欢，这样的同理心，技术人员会相对欠缺一些。

思维太过理性。然而产品有时候需要的是感性，当理性的思维碰上感性的需求，就会产生冲突。举个例子，一个产品有 10 个功能需求，一般技术人员会思考怎样用最少的代价把这 10 个功能都实现了，最后可能每个功能都只做到 60 分或 80 分。但其实，重要的不是把功能全部实现，而是选择其中的一个作为突破点，做到 120 分，这就足够了，其他的都可以不做。所以，性价比不是决定性因素，有突破点才是决定性因素。这一点，很多从工程师转到产品经理的人都不容易参透。

结语： 今天跟大家分享了技术、产品、管理的不同视角，每个角色都有各自不同的世界观，为了避免产生隔阂，技术人员需要从以团队实现为目标、换位思考、用对方能听懂的语言做表达三个方向出发，锻炼自己的沟通技巧。

同时，技术人员有着不同的职业发展路径，转向产品，以产品架构师为目标是不错的选择。而当技术人员选择转向产品时，需要克服自己太过注重可实现性、缺乏同理心、思维太过理性的短处，发扬自己逻辑思维能力强、了解可实现性的长处。

你觉得技术、产品和管理的不同视角主要体现在什么地方呢？技术转型产品时需要转变哪些思维呢？欢迎你在留言区分享。

感谢你的收听，我们下期再见。

作者简介

王昊，bilibili 主站技术中心总经理，曾历任百度基础架构部架构师、高级技术经理，网页搜索部副总监，移动应用部总监，是百度分布式存储领域的早期开创者，推动了百度分布式存储技术的自研、应用。

（本文整理自 bilibili 主站技术中心总经理王昊在 ArchSummit 大会上的分享，有删减。）

第71讲 | 王昊：什么样的人适合考虑管理角色

你好，我是 bilibili 主站技术中心总经理王昊，今天想跟大家分享的话题是技术人转管理过程中的考量。

之前的文章中提到，技术人一般有 4 个职业发展路径，第一个是从工程师到研究员到高级研究员，最后成长为科学家；第二个是工程师到高级工程师到架构师再到主任架构师；第三个是从工程师到项目经理到经理再到部门总监；第四个是从工程师到产品经理到高级产品经理再到产品架构师。

除了第一条专业研究的路径之外，其他几条路走到后面或多或少都会需要管理技能。即使是架构师，也需要带领一个技术团队，在技术上达成目标，更不用说总监、产品经理这样的角色了。

那什么样的人适合考虑管理角色呢？转型为管理者需要具备哪些素质？在回答之前，想先问大家两个问题。

问题一：提到曼哈顿工程你会想起谁？

曼哈顿工程是美国在二战期间实施的利用核裂变反应来研制原子弹的计划，最后成功按计划制造出两颗实用的原子弹，整个工程取得圆满成功。

那么，当提到曼哈顿工程的时候，你会首先想起谁？一般人们的答案都是爱因斯坦、费米、奥本海默等技术英雄。

爱因斯坦虽然没有真正参与曼哈顿工程，但他写给总统罗斯福的信，是曼哈顿工程启动的原因之一。费米领导的小组建成了世界上第一座铀—石墨原子反应堆，从实践上证明了链式反应理论的正确性，为原子弹的制造奠定了坚实的基础。奥本海默则是原子弹计划的负责人，被称为"原子弹之父"。

但很少有人知道这个工程的管理者是当时的美军上校格罗夫斯，他管理了 10 万多人，历时 3 年，耗资 20 亿美元实现了曼哈顿工程这个项目。

可以看到，当提到曼哈顿项目的时候，人们首先想到的是其中技术英雄，很少有人知道它的管理者是谁。管理者的光芒会被掩藏在技术英雄之后，这是技术人转管理时需要考虑的问题。

问题二：对于团队，哪一件事情更重要，是使命还是人？

这个问题我在不同的场合都分享过，也做过一些现场调查，发现了一个很有趣的现象。如果当时的听众大部分是工程师，那么调查结果是选人；如果听众大部分是管理者，那么调查结果就变成选使命，而且管理者的级别越高，选使命的人会越多。

这不是一个有正确答案的问题，它的答案没有多错，没有好坏。只是从中能看到，不同的人的视角是不一样的，他们的价值观也不相同。

因此，当技术人思考自己是否适合做管理时，不妨先问自己这两个问题。

什么叫管理者

回到管理者本身，我给管理者做了 3 个简单的定义：

以实现为目标，不以技术先进为目标。技术先进不先进不重要，能做出来最重要。

以团队实现为目标，不以自己实现为目标。自己的团队能做出来最重要，是不是我做的不重要。

以帮助团队实现为目标，不以自己提升为目标。我级别升不升不重要，我们团队能做更多的事最重要。

这就是管理者视角和技术人员视角的不同。所以，当我们提到曼哈顿工程的时候，所有人第一时间都会想到其中的技术英雄，它的管理者是默默无闻的，但其实他才是这个工程的灵魂。没有他，只靠工程师和技术专家的话，很难把这么多人组织起来，在这么短的时间内，完成原子弹的研发及制造。

所以，对管理者来说，团队的使命更重要，团队的人和人的发展相对来说要欠缺一些。

这是我问了自己这些问题之后得出的答案，是我的观点，但每个人首先得有自己的世界观，你认为什么样的人适合做团队管理，可以有你自己的答案，这并没有一个标准或对错。

另外，管理者要以成功为目的，不以成名为目的；要关注目标达成重于实现路径；要有站在台下的精神准备；还有一点非常重要，受得了委屈。

举例来说，很多公司都会奖励表现突出的员工，会组织在大会上颁奖，这是一个很大的荣耀。这时候，你是愿意作为那个在台上领奖的人，还是在台下看着自己团队成员领奖的人。

如果是前者，你可能在管理道路上走不了太远，反之，如果你愿意站在台下，看着自己团队的成员领奖，享受荣光，你的管理道理才可能走得更远，这就是最大的区别。

但是，能克服这一点的工程师并不是太多，因为骨子里，工程师都有追求卓越的思想，看到别人领奖，他会想我也能做到这样，下次就该是我上台了，能放下的、愿意隐藏在团队光芒背后的技术人员毕竟是少数。

另外，很多工程师都受不了委屈，当一个功能没有实现，经理问他的时候，即使他嘴上没有反驳，他心里也极有可能反驳说，你又不给钱，又不给机器，我怎么能做到呢？

但管理者不能这样想，他需要背目标，一旦不能实现，即使问题出在其他地方，那也是他的失职，得受得了这个委屈，这也是工程师和管理者很大的不同。

结语：今天跟大家分享了管理者具备的特质，以及技术人员转管理过程中需要思考的问题。总结下来，管理者是以实现为目标，不以技术先进为目标；以团队实现为目标，不以自己实现为目标；以帮助团队实现为目标，不以自己提升为目标。而要成为一个合格的管理者，需要以成功为目的，不以成名为目的；要关注目标达成重于实现路径；要有站在台下的精神准备；还要受得了委屈。

因此，当技术人思考自己是否适合做管理时，不妨先反观自己是否具备这些特质，又是否有了接受这些特质的心理准备。

你觉得管理者最重要的素质是什么？技术转管理的过程中最需要关注的点又是什么呢？欢迎在留言区分享。

感谢你的收听，我们下期再见。

作者简介

王昊，bilibili 主站技术中心总经理，曾历任百度基础架构部架构师、高级技术经理，网页搜索部副总监，移动应用部总监，是百度分布式存储领域的早期开创者，推动了百度分布式存储技术的自研、应用。

（本文整理自 bilibili 主站技术中心总经理王昊在 ArchSummit 大会上的分享，有删减。）

第72讲 | 创业公司如何招到合适的人才

对于科技公司来说，技术人可以说是最核心的宝贵资产了，然而招聘几乎是所有科技公司都头疼的事情，尤其是对创业公司来说，如何招到一个优秀又合适的人才更是前期会面临的极大的挑战。那么，如何招到合适的人才呢？

1. 花更多的时间去做招聘

创业初期必然非常繁忙，四面八方涌来的事千头万绪，但是，再忙，招聘依然是所有事情里最重要的。你需要花更多的时间去看人，获得那些有潜力的候选人对你的公司的垂青，并且和所有来面试的人面对面交流。

雷军就曾说过，“如果你招不到人才，只是因为你投入的精力不够多。我每天都要花费一半以上的时间用来招募人才，前 100 名员工每名员工入职我都亲自见面并沟通。”他曾经在一周内有 5 天、每天超 10 小时说服一位跨国公司高管加入小米，但到最后对方还是选择了放弃。

他还有一个切身体会，“不少创业者抱怨找不到人。其实，无论什么样的企业，找优秀的人都很困难。解决这个问题只有两种办法：一，花足够的时间去找人，至少花 70% 的时间；二，把现有的产品和业务做好，展示未来的发展空间和机会，筑巢引凤！”

雷军都如此，我们作为创业者，为了打造优秀的团队，需要花费足量的时间和精力在招聘上。

2. 自己强，才能吸引到相对强的候选人

我们要招人，但更多的时候，我把它称之为吸引人。在阿里、腾讯、百度等大公司，不需要管理者自己去吸引人，每天光是 HR 送来的简历都挑不完，但是到了创业公司，体量没有阿里、腾讯、百度那么大，就需要靠我们管理者自己去吸引人。

那怎么吸引人，简单来讲就是对方想听什么、需要什么，我们就给他什么。一般来说，技术人需要的就六个字——跟对人、做对事。每个人都认为自己是千里马，希望遇到自己的伯乐，我们作为伯乐，该怎么对待我们的千里马呢？

我的一些经验，首先，要跟对方表明自己也是技术出身，比方说秀秀自己的 GitHub 项目，让对方知道自己不是不懂代码的纯管理者，大家都是同一个圈子的人，会理解你们的想法与需求。人最怕的就是别人不理解自己，技术人也不例外。

这是基础，在这个基础上取得信任之后，才好跟对方沟通公司是做什么的，具体业务是什么方向，有哪些挑战等。但我们作为技术管理者，很少拿业务去吸引人，一般都是拿技术上的挑战去吸引人，比方说加入我们可以做 Docker、做虚拟化、自己搭框架等，可以在拓展业务的同时，很好的兼顾技术上的锻炼和发展。

总的来说，一定要让他们感觉到你这个老板是靠谱的、是懂他们的，后面才是业务上的、技术上的挑战，最后才是具体的薪资水平。

3. 扩大团队与 leader 的影响力

有技术大 V 曾分享过，他通过影响力得到的最大的收获就是便于“勾引”各种人才。有了影响力，就有了关注度和话语权，一个有点知名度的公司，与一个毫无知名度的公司，对人才的吸引力，天差地别。那么如何提升影响力呢？

第一，多参加业界交流会——如果你之前不是技术圈大 V，那么可以主动参加一些活动，行业相关的也好，技术相关的也好，多多分享自己及团队的技术和创业心得，建立良好的公司形象和技术团队形象，通过媒体扩大影响力，这是团队扩展人脉和影响力的有力途径。尤其是一些圈内认可度较高的大会，说不定你想要的大牛就在那里。

第二，选定一个技术方向着力打造技术品牌——对于技术人来说，技术团队的实力水平是非常重要的考量因素，因此，可以有意识的选择某个具有核心竞争力的技术方向，来打造技术品牌，比如在相关的技术大会上分享，撰写或翻译该技术的优质文章，如果是开源技术，还可以积极贡献开源社区等。

第三，看到优秀内容主动在对方博客圈里留下痕迹——越是牛人，与他心灵相通的圈子越窄。要想搞定他们，最好的办法就是寻找牛人的博客，看到优秀的内容就主动勾搭，跟对方聊一聊技术、行业相关的话题。你要相信，在你够强的时候，通过跟别人的沟通交流，自然而然会得到他们的认可。

第四，在职员工推荐——这其实是最好的一种口碑传播的模式，在职员工了解你公司的业务状况，他会根据你的请求和需要推荐员工。但是，也容易出现小集体和抱团的情况，不过创业公司规模较小，大家朝夕相对，不容易出现这种情况。

4. 不要完美，合适就行，有潜力最重要

很多时候，大家在招人的时候都想着一定要打造一个梦之队，不管什么方面都要最牛的人。但这很显然是不现实的，就算有人一时冲动被你忽悠过来了，能不能留住也是个大问题。

90 分容易，100 分难，100 分的人你肯定要付出 200 分的代价。这代价不只是公司钱财上的代价，还包括管理的成本，你需要花费更多的精力让他融入现有的团队，然而就算成功融入了，之后团队如何平衡也是个大问题。当前互联网行业早就已经脱离早年一个程序员搞定一个系统的时代了，一个软件动不动就是几十万行代码，一个人根本搞不定，都得靠团队通力协作完成。所以，很多时候不用特意去追求明星程序员，合适的才是最好的。

另外，潜力仍然是衡量一个人是否有发展前景的最重要标准。如今，IT 行业发展快速、复杂多变，对公司来说，胜任的人才固然重要，但潜力人才更是可贵。

那什么才是有潜力的人才呢？一般可以从以下三个方面出发进行判断。

是否具备正确的动机，以强烈责任感和极高投入度去追寻一个的目标。

是否具备极强的好奇心，渴望获得新体验、新知识以及别人反馈，以开放心态学习和改进。

是否有面对挑战的决心，在面临挑战或在逆境中受挫时，依旧能为目标不懈努力。

5. 从招人变为找人

对于优秀或稀缺人才，千万不能端着，要主动出击，放下身段，以真诚打动和吸引他们。毕竟，优秀的人才是从来不缺机会，一定是我们去求才。在求才的过程中，往往还要拿出锲而不舍的精神，正如之前提到的雷军，为了找到一个非常资深和出色的硬件工程师，连续打了 90 多个电话，而为了说服他加入小米，他和几个合伙人轮流和他交流，整整 12 个小时。

尽管穷追不舍、软磨硬泡之后，人才也不见得跟你回家，但你不这么做，优质人才几乎是不可能会主动跟你走的。

结语： 创业团队想要招到优秀又合适的技术人才，从来不只是 HR 的事，而是 CEO、CTO 以及整个公司的事情，在具体操作上，我们可以从花更多的时间在招聘上；增强自己作为技术 leader 的实力，用实力来说服候选人；扩大团队与 leader 的影响力，吸引人才主动来投；制定合适的人才标准，选择最合适的人才而不是最完美的；从招人变成找人，求才若渴，主动出击等几个方面出发，来应对招聘挑战。

你们呢？是否也为招人感到困扰呢？你们又是怎么应对招聘难题的呢？欢迎留言分享。

感谢你的收听，我们下期再见。

第73讲 | 用数据来分析管理员工

上周，我们聊了创业公司招人的话题，今天，我们接着聊聊把人招进来之后该怎么育人和用人。

所有的公司都有新员工培训这个环节，只是重视程度不同，之后进入正式工作后，还会有团队 leader 不断的培养。每个人的特质都不同，很多时候我们很难招到跟团队完全 Match 的人，但如果育人和用人跟得上的话，在把员工变得更好的同时，也能让团队更高效。

一般来说，我会把团队成员定义为三类，一个是核心骨干，一个是骨干，一个是普通同学，不同的人有不同的带法，也就是不同的育人法和用人法。

实际操作中，育人是要花费大量时间和精力的，而我们每天放在工作上的时间是有上限的，很难做到雨露均沾。假如你的团队现在有 10 个人，采用平均主义，在每个人身上花的时间都一样，那你将会累死而且很可能效果不好，因为有些人是无底洞，并不值得投入很大的时间和精力。

就跟买股票一样，如果要选十只股票，那你肯定会分析考虑，做出取舍。如果平均每只股票都买的话，那还不如直接买大盘指数。

所以一定要将人才分档，把我们的大部分精力放在骨干、核心骨干上，下面分享一些我的具体做法。

1. 以事育人，因材施教

王阳明说过，人须在事上磨，如果我们只用嘴说，就太肤浅了。为什么我们听完课之后要做笔记、做功课，还要考试，同样的道理，很多时候，我们在培养下属、管理干部的时候，必须用一些事情让他们得到锻炼、让他们证明自己。比如说我希望他们在项目管理上做得更精细化一点，那就对他们提出要求，通过具体的工作来磨炼他们。

很多时候，我们还需要将我们的同学扶上马，送一程，比方说他技术很厉害，那我们就可以给他设计一个阶梯型任务，让他逐步适应这个新工作，发挥自己的能力。

同时，我们要因材施教，因为不同的人的性格都不一样。有些同学是外放型的，他就适合往业务方向发展，有些同学是内敛型的，他就适合沉下来做基础建设、做工具系统。

2. 言传身教，多做政委

我带过很多新人，新人又分两类，一类是能力强的新人，他们有很丰富的经验，不需要怎么教，给他们定任务、做计划就好了；一类是能力不强的新人，但人很聪明又好学，比方说校招来的新人，值得培养、忠诚度高，但是缺乏经验，这时就是 16 字经验，“我说你听，你说我听，我做你看，你做我看”。

举个例子，小明刚毕业进来，很聪明、很积极，但是没经验，那我就直接派任务给他，比如帮我做个监控的日志分析，那么“我说你听”“我做你看”就是先先口把口、手把手的教他用哪些工具、怎么用怎么分析等，带他做一两次，“你说我听”“你做我看”就是我带着他做了几次之后就放手让他自己去做，看他是否真正掌握方法，同时还要定期考校他，让他总结分析这里面的要点与诀窍。

同时，我们还要多做政委，留人即留心，功夫在平时，平时要多跟员工沟通，多做知心大哥大姐。有机会多带着团队出去吃吃饭、撸撸串，利用这些机会或者每次团队建设的时机，大家一起聊聊工作、谈谈人生、关心关心他们的现状。

除此之外，我们还要结合团队和个人发展目标，和下属共同制定他们的长线规划，这很重要，要让他们感觉到 leader 是在很用心的帮助自己成长。让他们感到被关怀、被重视，而这样的情绪必然会积极的影响到他们的工作效率。

3. 容人之短，用人之长

在用人这方面，我经常把团队成员分为四种：有心有力、无心无力、有心无力、 有力无心。

第一种有心有力，这类同学态度认真、能力胜任，即使有时活给少了，他们也会主动提出来。这类同学是最不需要操心的，给他们定一个明确的目标，他们就能向着目标自驱动的前进。

第二种无心无力，这类同学你给他三次机会，两次考核，不行就让对方走人，没必要对其倾斜资源，要时刻记住把自己的大部分精力放在骨干和核心骨干身上。

第三种有心无力，这类同学很努力，经常发现在加班，很辛苦，但就是出不了成果。这个看情况，第一他是老员工，他已经形成了不太好的工作习惯，你需要花很大的精力去改变他的做事方法；第二他是刚来的新员工，刚适应环境，那就需要快速的给他换个岗位试一试。

我们公司有个规定是，当员工子当前岗位做满一年，只要他在当前岗位达标，那么想去公司任意岗位都可以申请，只要对方愿意收，当前团队就不可以拦着，必须放他走。这也是让人才流动起来，让公司整体的人才氛围更活跃、更好。很多时候硬留着对方，你痛苦他也痛苦，还不如换一换，他可以多个机会发挥自己的能力，你也可以多个空缺招来更合适的人才。

第四种有力无心，这类同学最麻烦的，能看出他技术实力不错，看他写的技术博客、发表的技术文章、写的技术报告都有模有样的，但就是天天干活心不在焉。有贡献，但是心不在，这里面很大的一个可能就是他已经对当前岗位非常熟悉，做这些事情驾轻就熟，但却没有了挑战性，不用花太多心思就能达成考核需要。

这种老员工一定要好好留下来，不能浪费了，家有一老，如有一宝，既然他还没有走，说明他还是认可团队的，所以需要给他更多的挑战和发挥空间，实在不行，也可以主动帮他找出路，比方说从业务支撑团队转到基础设施团队，进行一些工作方向上的调整。

这里面很重要的就是“用人不疑，疑人不用；容人之短，用人之长”，但是知易行难，我也还在不断修炼中，有时也会有抱怨，但是你既然用了他，作为管理者就要尽量帮他发挥长处、规避短处。比如我用了小明，他不擅长对外沟通，那帮他组建团队的时候，就可以选择善于沟通的搭档，发挥各自的长处。

结语：在我看来，每一个管理场景，总有一个最佳实践，所以我非常喜欢给我的员工做画像，因此才有之前提到的核心骨干、骨干、普通同学之分，才有有心有力、无心无力、有心无力、有力无心的区别。我们用大数据来分析我们的客户，为什么不能用数据来分析我们自己的兄弟，让他们在公司呆的更开心呢。

即使真的留不住对方，我也会珍惜每一个同学离职的机会，跟他开诚布公地聊一聊，让他给我开个药方，告诉我是哪里没有做到位，怎样可以做得更好。每一次的员工离职，都是我的一次反思、学习的机会。

关于育人和用人，你是否有独家实践呢？欢迎留言跟我们分享。

感谢你的收听，我们下期再见。

第74讲 | 为什么给了高工资，依然留不住核心员工？

在如今这样一个科技时代，人才几乎是每家公司的重要资产，各大公司都希望能够留住宝贵的人才，很多老板不惜“一掷千金”。

但碰到的问题是，奖金酬劳投入得越来越多，却依旧没有摆脱人才流失的烦恼，特别是没有留住那些具备关键技能或表现杰出的核心员工。

最近参加一个技术管理相关的闭门会议，正好聊到员工招聘、留存的的话题，有个创业的朋友 A 抱怨道：“给了那么高的工资，还有期权，好员工还是留不住。”

前不久，他团队里负责 iOS 开发的一个核心员工离职了，创业公司本来人就少，没有合适的人接手，导致产品的迭代节奏完全乱掉。最后没办法，他作为 CTO 只能自己顶上了，真心很累。

在大公司，人才体系和储备都比较完备，某个核心员工离职产生的影响可能没那么大，能比较容易的找到其他人顶上，而在创业公司，更多的时候都是一个萝卜一个坑，负责某个核心业务的可能也就那么一两个人，人一走整个步调就全乱了，超级麻烦。

对于这个问题，当时参加会议的不少朋友都遭遇过，也都分享了自己的经验，我觉得很有代表性，就记了下来跟大家一起分享，欢迎一起探讨。

1. 高工资真的高么？

据一项调查显示，在所有跳槽者中，有 52.5% 的人都是由于原单位的工资低而跳槽的。

在上面提到的这个例子中，离职的员工是 A 公司最早的一批员工，之前的底子并不是很好，初始薪资并不是很高，但由于创业期需要多面手，而此人学习能力又比较强，因此慢慢成长成为研发团队的核心人物。于是，加薪、期权都有了。

然而，人的能量会随着他能力的提升、地位的升高而逐渐增加。受限于公司的薪酬体系，尽管给他加了薪，但可能在他看来，加薪的程度其实并没有跟上他的成长速度和他在团队里的重要程度。同时，对高层领导来说，他又没有不可或缺到为他破例，打破薪酬体系的程度。

久而久之，他就对现状产生了不满，从而逃离。个人能力越强的人，越容易对现状，比如薪资，产生不满。

至于期权，很多创业在招核心人才，或是留核心人才的时候，往往更愿意提供看不到摸不着的期权，这样一方面可以节省成本，一方面也可以将员工绑上战车。

但是，对于员工而言，这更像是一种投资，而且这种投资的回报时间比较长、风险比较高，相较之下，他们可能更愿意去能够提供高薪水的企业。毕竟并不是所有人都能认同创业项目的价值所在，也并不是所有人都愿意承担创业的风险。

所以，不妨先问问自己，高工资真的高么？真的符合员工的价值，达到员工的预期了么？

2. 激励到位了么？

另一个参会的朋友 B 提出了他的看法，对于这些核心员工来说，高工资真的是他们心中最重要的考虑条件么？

在管理中，高工资和奖金都是很有效的金钱激励手段，然而，还有很多非金钱激励手段，包括目标、成长、认可、授权、尊重、沟通、信任、文化等。心理学界相信非金钱激励至少与金钱激励效果相当。

对此，剑桥大学两位教授做了一次实验，以美国快餐连锁店员工为对象，比较了金钱激励和非金钱激励对他们的相对影响。研究结果表明，两种激励手段都显著提高了该店的利润和客户服务质量，同时降低了员工离职率等。

具体来说，金钱激励使免下车取餐的服务响应时间加快了 19%，而非金钱激励使得免下车取餐的服务响应时间加快了 25%；金钱激励使员工离职率减少了 13%，非金钱激励使员工离职率减少了 10%，可以看出非金钱激励的效果非常强大。

总的来说，金钱激励是很有必要的，然而，金钱并不总是最有效的激励方式，当员工已经具备足够高的薪资水平时，他们反而会更看中非金钱激励中包括的工作本身的意义、被认可程度、自主性、成长机会、进步空间等内容。

所以，不妨问问自己，除了高工资外，你的非金钱激励到位了么？

3.Leader 沟通到位了么？

业界一直都有个说法，80% 的人离开公司都是因为上司，而缺乏沟通又是其中最主要的原因之一。朋友 C 分享了他的经历，他也是创业公司 CTO，只是公司规模更大一些，正处于业务高速发展、团队快速扩张的阶段。

业务的快速增长带来了各种技术挑战，核心岗位的人手又不充足，我作为技术最高负责人，不得不投入到各种具体事务中，有意无意减少了和团队的沟通，很多同学可能 3 个月都没有单独沟通过。

缺乏沟通带来了各种误解，尤其是几个早期员工，他们其实对公司有很多想法和意见，但因为没有向上反馈的渠道，慢慢地就变成了抱怨和愤怒，他们被猎头挖角我也全然不知。等到他们集体提出离职时，我才猛然惊醒，再去跟他们沟通却已经没办法挽回了。

因此，以我的经验，如果不能及时了解团队中的思想状况，不清楚他们的诉求点，很容易遇到你并不想要的“意外惊喜”。

之后，我采取了几个措施来加强沟通，一是请求 HR 部门配备了一个 HRBP 来协助我；二是要求每个团队的 Leader 每两周都要跟他们团队的成员做一次一对一沟通。而我则在每周五的时候，跟我下属的 Leader 们开一次一对一的工作例会，并在每个月月底的时候召开一次全员例会，内容包括欢迎新入职同学、总结本月重要项目的进展以及存在的问题、介绍下个月重点要做的事情，让大家对当前的工作有一个整体的认识，并清楚知道自己在全局中的作用。

另外我还制作了一个表格，根据员工的入职日期、级别和岗位的重要性列了一个沟通计划表。我把每个月分成四周，黄色的表示计划要沟通的，绿色的表示已完成的一对一沟通，蓝色的表示一对多的沟通。每一次沟通都做好沟通纪要，通过这个方式，我能比较好地保持和团队紧密沟通，了解他们遇到的问题，将问题提前解决掉，即使不能全部解决，真到问题出现的时候也不至于毫无准备。

总的来说，技术管理者要想搞清楚团队成员的诉求和不满、留住核心员工、打造一个有战斗力的团队，沟通无疑是最重要的。

所以，不妨问问自己，你跟这些核心员工的沟通到位了，真的理解他们的不满和诉求了么？

4. 未来有希望么？

最后，还有非常现实的一点，就是你的公司是否给员工看到了希望。我们聊管理的时候，经常有这么一种说法：公司本身的高速发展，是对团队最好的管理，也是对员工最好的激励，自然也能吸引更多的核心人才留下。

比方说小米，从传统的管理来讲，小米内部的扁平化结构带来了很大的管理挑战和压力。但在实际中，由于小米的快速发展和扩张，很多员工都像打了鸡血一样，将热情和激情投入到了工作之中。

可以说，这是非常关键的一点，如果公司特别有活力和前途，每个人都很有干劲和激情的话，其实不用在管理上做太多的事情。但如果一个公司本身在走下坡路，或者是创业看不到方向和未来，那不管管理多么精细、工作安排多么合理、对员工激励多么到位，真正想做事的员工是没有什么成就感的，很容易就会选择离开。

所以，不妨问问自己，公司真的给了这些员工未来的希望了么？

结语：对于员工为什么会离职，其实马云已经总结很全面了，一是钱没给到位，二是心委屈了，上面提到的不管是高工资、非金钱激励、有效沟通还是未来发展前景，其实都能包含在这两点之内。不过知易行难，但有了方向之后，可以试着朝这些方向不断努力，找到留住核心员工的方法。

你是否遭遇过核心员工离职呢？你认为最主要的原因是什么呢？欢迎留言讨论。

感谢你的收听，我们下期再见。

第75讲 | 刘俊强：一本正经教你如何毁掉一场技术演讲

你好，我是腾讯云资深架构师、TGO 会员刘俊强，有着 10+ 年以上的互联网开发经验，8 年以上的技术管理经验。今天想从反面出发，跟大家分享如何做好一场技术演讲。

演讲（Presentation）是一种常见的经验分享交流以及个人品牌提升方式，回顾这些年，我做过 QCon 讲师、在线课程讲师，在企业内外做过各种技术及管理的演讲分享，因此，最近思考总结了如何做好一场技术演讲的关键要素，以帮助更多的同学做好自己的技术演讲。

本文不会直接告诉你如何做好一场技术演讲，而是要开个脑洞，假设你自己要毁掉平行宇宙中另一个自我的技术演讲，那么你到底要怎么做才能达到目的呢？不急，下面我们慢慢来捣乱。

通常我们将一个技术演讲划分为三个阶段，即内容准备阶段、演讲前准备阶段以及正式演讲阶段，那么秉着不捣乱不甘心的态度，接下来就教你怎么在这三个阶段毁掉自己的技术演讲，想到要做坏事内心还有点小激动呢。

内容准备阶段：含糊定位、结构混乱

在我们决定做一场技术演讲时，我们对于该演讲的目的应该是明确的，一般来说，一场技术演讲的目的分为以下几类：

告知（To Inform）：产品技术新特性或版本发布的告知等，例如《Spring Boot 2.0 特性介绍及未来路线图》、《Istio 1.0 正式版发布》；

教育（To Educate）：阐明一门新技术或框架的使用方法等，例如教会工程师《基于 Spring Boot 2.0 来构建 Web 应用程序》、《基于无服务函数计算来构建数据流分析系统》、《基于 Kotlin 协程实现异步编程》；

说服（To Convince）：说服决策者来批准或使用自己的技术提案，抑或是研究预算等，例如《基于 Spark 的数据分析系统的投入产出分析》、《基于 Service Mesh 的海量容器管理平台实践》、《腾讯织云智能监控实践》；

行动引导（To Lead to Action）：针对已有解决方案引导人员进行行动实践等，例如《微服务改造实施规划》、《XX 项目性能优化专项》；

不难看出，做一个技术演讲成功的前提是目的明确，知道这场技术演讲主要要解决什么问题，那么，毁掉演讲的根基便是不去弄清楚这场演讲的主要目的，让另一个自我仅知道要完成一个技术演讲，但不知道做这个演讲的目的何在，或是引导另一个自我弄错这场技术演讲的目的，本来是"说服"类的咱给他引导成"告知"类的，想想台下听众一脸懵的表情，是不是心里已经开始暗爽了？

捣乱完了技术演讲目的，下面该在内容准备这块继续使坏了，关于内容准备的要点，我将其总结成“演讲的 4W2H”：

What：演讲要讲什么内容，内容的主题主旨是什么样的；

Why：为什么需要这场技术演讲，能够解决什么样的困惑或问题；

Who：演讲的受众是什么样的人群，是资深工程师还是技术管理者；

Where：演讲的地点在哪里，是公司内部分享还是付费大会，对应的受众人数有多少；

How：准备如何完成这场演讲，例如采用什么演讲风格、演讲辅助工具以及演讲结构；

How Long：演讲的时长是多久，15 分钟还是 30 分钟、40 分钟？

在“演讲的 4W2H”中，Why 是核心冲突或需求，通常来源于工程实践或行业中具体遇到的问题，抑或是大家期望了解的行业趋势，简单来说这个 Why 便是这场演讲能够带来的核心价值。

而 Who、Where 及 How Long 是演讲的限制因素或条件，每场演讲都有客观存在的限制性因素，演讲者必须在这些限制条件下进行内容准备和演讲呈现。

最后的 What 和 How 便是演讲者主要发挥才华的地方，如何有效地梳理内容结构并用合适的技巧来进行呈现便是演讲者的功力体现。

作为带脑子、有技巧的演讲捣乱者，咱们就不期望在核心价值和客观限制条件，也就是 Why、Who、Where、How Long 这些方向上误导另一个自己了，相信另一个自己的智商也没那么容易被误导。那要捣乱的突破点就是 What 和 How 了，在这里我整理了一些有效的捣乱手段，一般情况下，几条就可以成功毁掉一场技术演讲，要是能够全部命中，那这场技术演讲也就万劫不复了：

演讲要呈现的内容过多，不进行收敛导致主题不止一个；

不明所以的幻灯片排版，如满屏代码、多种字体颜色混用、不使用图片、使用与内容无关的图片、整张幻灯片全部是文字以及花哨的幻灯片设计等；

混乱的幻灯片结构，如迷之跳跃的幻灯片、内容不做分区或内容分区后不具有联系等；

直奔主题讲内容，不准备开场和结尾，开场可以帮助观众明确演讲主题，结尾可以帮助观众回顾演讲主题。

另外，咱们更不能让另一个自己知道一些成功演讲的通用技巧或是公式，来帮助他进行结构组织，例如“演讲结构组织的 OIBCC”：

Opening：获取观众的注意力；

Introduction：为何会有这场演讲；

Body：演讲的主要内容及观点，通过统计分析、图表、示例及故事等手法来支持演讲的主要观点；

Conclusion：回顾主要内容及观点；

Close：与开场呼应的一句话，让观众有强烈记忆点。

总结一下，从内容准备的各个方面来看，要毁掉一个演讲的要点就是：随意的演讲结构、不明所以的幻灯片结构与排版。比如我们可以在一场演讲中放飞自我地进行表达，不管是否与主题相关，也不管是否符合表达逻辑；视觉和排版上也拿来主义，这一页是苹果风格，下一页就跳到 word 艺术字风格……这样，内容准备阶段就可以毁得彻彻底底了。

演讲前准备阶段：不充分的排练

前面花了不少篇幅来介绍怎么在内容准备阶段进行捣乱，确实，充分的内容准备是一场技术演讲成功的主要因素，基本可以占到 60% 的比重，那么毁掉了前面的 60% 是否足够呢？

不达目的不罢休、捣乱就要彻底的心态告诉咱们，只毁掉内容准备阶段是不够的，一定要继续祸害这场演讲。而在演讲前准备阶段毁掉一场演讲的方式就是不充分的排练，最好是完全不排练。

在演讲中，演讲者需要通过各种技巧进行阐述来让观众接受他想传达的内容。知名的传播理论家 Albert Mehrabian 教授研究出了“7/38/55 法则”，他总结，你传递的信息或旁人对你的观感主要取决于三个要素：实际言语（内容）占 7%，语气（说话的语调、声音的抑扬顿挫等）占 38%，肢体语言（手势、表情、仪态等）占 55%。

根据这个法则，咱们要让另一个自己忽略 38/55 这两项，即肢体语言和语气，而是将注意力全部放在只占 7% 的内容本身上，这样他就会认为内容准备好了就万事大吉了，咱们干坏事也是尊重科学的。

演讲者排练的主要目的就是让自己在语气和肢体语言上完成肌肉记忆，这样实际演讲时，就不会因为焦虑和紧张造成走形。

排练的另外一个重要作用在于让自己在时间的把握上更游刃有余，有经验的演讲者一般都会提前将演讲讲义打印出来，进行真实的计时演讲排练，帮助自己修正演讲中不合适的内容结构及表述节奏，并且充分的排练能够帮助演讲者准备更多的素材以便应对不同的演讲状况。

正式演讲阶段：照本宣科、忽略反馈

终于到了正式演讲阶段了，这个时候怎么来捣乱、毁掉这场演讲呢？演讲时毁掉演讲很简单，就是照本宣科、不根据现场反馈做灵活调整。

一定要让另一个自我认识到，为了跟你们这些观众做演讲，哥们已经花了 n 多时间和心血、脑细胞不知道死了多少来准备内容，接下来我来说，你们好好听就行了，让我来 carry 全场，什么弄清楚观众群体、吸引观众注意力，不存在的。

通常来说，一场技术演讲要给观众带去新观点、新知识或是新思考方式等，让观众打破原有认知来接受演讲者的内容是有难度的，所以，在正式演讲时，成功的演讲者会根据现场观众的反馈等来调整自己的语速及内容等。

演讲者需要时刻将注意力放在观众身上，观察观众的反馈，反馈可能是表情、眼神或是动作。根据反馈来判断内容对观众的吸引力以及他们的接受程度，对于他们不感兴趣的地方，演讲者可以灵活跳过以节省时间，而那些他们听不懂的地方，演讲者可以再着重介绍讲解。

另外，观众的注意力每隔一段时间就会不集中，因此，成功的演讲者一般会在演讲中埋一些耍宝或是有冲击力的观点，来保持观众的注意力始终在自己身上。

写在最后

前面我们说了很多关于毁掉一场技术演讲的方式，简单总结下就是这些要点：

毁掉演讲的根基便是让自己不清楚这场演讲的主要目的。

内容准备上毁掉演讲的要点就是随意的演讲结构、不明所以的幻灯片结构与排版。

在演讲前准备阶段毁掉演讲的方式就是不充分的排练，最好是不排练。

演讲时毁掉演讲很简单，就是照本宣科、不根据现场反馈做灵活调整。

本文介绍了如何捣乱毁掉平行宇宙中另一个自己的技术演讲，当然这里是卖个脑洞开个小玩笑，通过反向操作的方式来帮助大家了解如何做好一场技术演讲，哪些问题是要避免的。最后，期望大家都能够在技术演讲上做得越来越棒。

作者介绍

刘俊强（微信公众号：程序员精进）现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+ 年以上互联网开发经验，8 年以上技术管理经验。

第76讲 | 内部技术会议的价值

现如今，技术在公司中的重要性越来越高，几乎所有业务的发展都离不开技术的支撑，但很多时候，技术的价值会被低估。

究其原因，往往是因为公司其他部门乃至 CEO 不了解技术在背后到底做了些什么，是如何保证系统平稳运行、快速响应的，也就没法很准确的了解技术的价值和意义。

内部技术会议

一个很好的解决方法就是推动公司内部技术会议的举办，邀请技术／工程团队之外的其他团队参与这项活动，向公司展示技术团队的成就，也让他们更了解技术团队的具体工作。我一般将其命名为“技术开放日”。

同时，内部技术会议还可以帮助技术团队与其他部门，如产品或运营等建立联系，在一种更友好的环境中彼此交流，探讨大家正在从事的项目、感兴趣的技术、正在进行的工作等，对彼此有更深入的了解，也减轻跨团队沟通中的障碍。

在经过尝试，并收集参会者的反馈后，我们决定每六个月举办一次为期半天的技术开放日活动，具体形式包括内容分享、小组讨论、Open Space 等，当然也少不了零食饮料和八卦闲聊。

除了这种纯粹面向内部的技术会议之外，我们也可以邀请外部的发言人和参会者参与，这样的话会更有益于技术品牌的打造和传播。

我有个朋友是一家旅游网站微服务团队的技术 leader，之前他们公司技术团队举办了一次技术开放日，对外招募了 300 多位参会者，分了他们在架构演进、微服务、Docker、混合开发等热门技术话题上的应用经验。

当时活动在技术圈中大获好评，除了对外展示了自己的技术水平，树立了公司的技术品牌之外，还有一个好处是让 CEO 等领导层看到了技术团队的能量，大大提升了技术团队在公司内的话语权。

如何举办一场内部技术会议

内部技术会议的举办没有什么“标准方法”，主要取决于你的团队、部门或组织的需求，但受众的选择一定要尽早确定：到底该邀请谁参加？谁能从会议中获得最大收益？

这些问题的答案可以帮助你确定会议活动的规划框架，因为随着参会者类型的增加，会议讨论的关注点也要随之改变，以尽可能满足受众的需求。

无论打算如何开展自己的内部技术会议，都要为与会者提供足够的时间和空间，并帮助他们做好安排，让他们能全身心投入到活动中，让活动收益最大化。

1. 选择合适的分享者

基于技术会议的一大目标是向公司展示技术团队的形象和成果，所以分享者的选择必须具有代表性。比如尽量选择某个技术成果的一线负责人，这样他能更详细的阐述项目推进过程中遇到的难题、踩过的坑、解决的思路、具体的解决方案等，会更形象更落地；尽量涵盖不同部门、不同背景的分享者，如开发、运维、安全等不同方向的工程师，这样对外技术团队展示的形象会更饱满，对内也能给平时比较“默默无闻”的技术团队展示自己的机会，提升他们的积极性和荣誉感。

2. 为缺乏经验的分享者提供指导

很多技术人其实都缺乏分享演讲的经验，他们往往无法很好的完成一场技术演讲，将自己想传达的内容完整、有效的传递出去。比如准备的演讲素材太过技术、太过深奥，导致其他部门的听众无法理解演讲内容；或是无法准确预估自己的演讲时间，事先准备太多的幻灯片，导致最后演讲潦草结束或超时过多等。

因此，我们可以给他们提供指导，保障他们的演讲内容是合适的，深入浅出，简单易懂的；同时，可以在活动开始前几天跟他一起对演讲进行排练，以此更好地掌控时间。

3. 参加活动的过程中，本职工作也不能停摆

技术人员平时工作繁忙、研发任务重，所以，最大的困难在于要让大量的技术人员在半天甚至更长的时间里暂停自己的本职工作。尤其如果是分享者的话，还需要抽出更多的时间来准备演讲内容。

为了缓解这一问题，我们可以在前期活动规划的时候就安排一个“战情中心”，提前为他们做好相应的安排，确保重要的支持工作不被中断。

内部技术会议的好处

内部技术会议往往可以带来立竿见影的显著收益，此外还会带来一些隐性的长期收益。

第一，会议可以为技术团队的员工创造一个机会，借此在不同团队之间建立联系，加强员工之间的交流，通过共同学习促进交流和创新，并极有可能在交流中碰撞出全新的灵感和创意。

第二，参与者将有机会加入自己最关心的对话中，在一个友好的空间里分享自己的观点，让以前被埋没的看法和观点影响更多的人，并有机会找到跟自己志同道合的伙伴。

第三，内部技术会议是发现和鼓励“默默无闻的”人员、团队和成就的好机会，借此可以展示可能被埋没的团队项目，或者那些虽然不被广为人知但同样很重要的工作，比如运维团队、底层支持团队等。借此让大家更好地意识到自己的价值。

第四，在内部活动中演讲可以让员工挑战自我。即使他们分享的是他们经常向周围人传达的想法，但如果想要登台演讲，他们必须考虑到很多实际情况，重新梳理自己的实践，进行更深入的研究，真正吃透自己想要讲的东西。很多会议的分享者会告诉你，在活动中分享可以获得的最大收获是在整理和完善自己所要讲述的内容的过程中学到的新知识。

第五，团队很容易会变成一种小型的回音室，因此更好的做法是让大家时不时抬头听听别人在说什么。随后他们可能会感觉，原来不光是我，其他人也在谈论这些问题。

最后，内部技术会议最主要的收益最终都将归结为社交：促进人员和团队之间的互动、信任和理解。

结语： 在这种技术会议中，所有的分享和讨论话题都可以由公司内部人员负责，而受众也都是公司同事，让大家自行选择能引发热切讨论的话题，这样可以提高大家的积极性。

你可以将这种活动变为真正的展示与交流活动过，邀请公司其他人见见你的工程师和团队，听听他们在工作中遇到的挑战、取得的成果，并在技术部门和其他人员之间建立有效的对话途径，也让大家更清晰的了解技术的价值与意义。

你是否在公司内部推动过技术会议的举办？收获了哪些好处？欢迎留言分享。

感谢你的收听，我们下期再见。

第77讲 | 陈晨：谈谈Instagram文化和文化背后的故事

你好，我是陈晨，现在是 Reddit 的 Senior Director of Engineering。在加入 Reddit 之前，我在 Instagram 工作，是 Instagram 的第 17 号员工，也是它最早的华人工程师，经历了 Instagram 从 20 人不到的小团队和 5000 万注册用户规模，到 400 人团队和 4 亿月活用户规模的巨大转变。所以，今天想跟大家分享以下 Instagram 成长过程中形成的工程师文化，以及文化背后的东西。

Instagram 是全世界最大的图片分享社区，目前全球有 5 亿多的日活跃用户和 8 亿多的月活跃用户。2012 年 9 月份，它被 Facebook 以 10 亿美金的价格收购，这在当时是一个天文数字。不过事实证明这是一次很成功的收购，2017 年，Instagram 估值约为 350 亿美金，翻了 35 倍。

30 人 * 月 =Instagram Video

Instagram 被收购后不久，我们要出被收购后的第一个版本，当时的目标是要做一些新的增长点。

从 Facebook 内部的数据来看，移动设备上的视频已经开始呈现出爆发式的增长，在这种增长趋势下我们看到了新的机会，再加上当时美国有一个非常火的 6 秒钟短视频应用 Vine，月活跃用户达 2 亿，还被推特花 6 亿美金收购，对 Instagram 造成了很大的威胁。

所以，我们决定做一个 15 秒的短视频产品 Instagram Video，并希望在 30 天里把这个产品做出来。

当时我们团队只有 30 人，其中 15 人是工程师，也就是我们要从 0 到 1 做一款全新的产品，从产品形态到设计，从安卓到 iOS，从后台到测试再到发布，所有的都要 30 个人在 30 天里面完成。

这可能在国内并不是多么稀奇的事，不少创业团队都是这么做的，但在美国，这是非常恐怖的一件事情。

最后我们成功了，我现在还记得很清楚，2013 年 6 月 21 日早上 9 点发布 Instagram Video 之后，短短 3 个小时里就已经有 100 万个视频上传。当然，也得益于当时正好是 NBA 总决赛，依靠 Facebook，Instagram 获得了全世界 30% 的互联网流量，这对于一个产品是否成功的影响力是非常大的。

回想一下，当时团队之所以能成功，主要是因为具备以下特质：第一，创始人亲力亲为，精心打造，快速出产品。当时我们有一个会议室就是老大专门做产品审核的地方。

第二，每个领域都有独当一面的专家，从前端到后端，都是非常优秀的人在做技术和产品。同时，团队里的技术人员，不论是对人的沟通能力还是对产品的理解力都非常卓越，是全面的技术人才。即使没有专家也没有关系，团队还可以花钱去买，比如我们就用七天时间收购了一家全世界最牛的防抖公司。

人们拿手机拍摄视频的时候难免手抖，而手抖会影响视频最终呈现的效果，我们就希望把视频防抖功能做的更好一点。但我们研究了两个星期之后，发现没法做出满意的效果，最后花了一笔巨额资金用 7 天时间收购了一家 YC 的专业防抖视频公司，三天时间谈收购，第四天他们的工程师坐到我们旁边熟悉情况，第七天把代码融合到 Instagram 里面去。

第三，一群年轻人为了改变世界而努力工作。短视频应用在当时是非常新的领域和产品，一切几乎都是从零开始，充满挑战，一群年轻人为了改变世界而努力工作，这件事情走的快也是顺理成章的。

Instagram 的文化

接着来聊一下 Instagram 的文化。关于团队文化，我的看法是：首先，先有人，才有文化，有了文化才能够聚拢人；其次，创始人的特质决定了早期团队的文化，也会限制后期团队的发展；最后，文化无所谓好坏，只有适合当前发展的文化才是有效的文化。而有效的文化，不一定是最好的文化，这两者之间是有区别的。

回到 Instagram，我们在发展过程中形成了 3 个文化：

1. 化繁为简，Simple Things First

对创业公司来说，在一个高度复杂的产品里，可以使用化繁为简的思路，找到一个可以快速迭代出的最小化可行性产品，即 MVP，然后在这个最小化可行产品上持续快速迭代，直到做出一个高质量的产品。

2. 社区至上，Communities Are Important

Instagram 的起源是图片社区，可以说没有社区生产图片就没有 Instagram 的今天。当时 Instagram 的产品使命也是让用户通过图片连接社区以至连接整个世界。只单纯的认为 Instagram 是国外的美图秀秀，或是只看到 Instagram 的滤镜很漂亮，都是不正确的。

3. 细节决定成败，Details Matter

从最早的 2013 年到现在，Instagram 的用户体验都是超越时代的，不论是从产品设计来看，还是从代码的质量来看，都是非常优秀的。比如收购了视频防抖公司之后，经过优化，我们的视频防抖功能就做到了世界第一，这些细节让产品变得无懈可击。

Instagram 的文化背后

但这只能说明，这些文化是适合 Instagram 的，而不能说这些文化是最好的，这些文化背后其实都有让人很头疼的事情。

1. 最小化可行产品还是最小化不可行产品？

把复杂的事情简单化，是一件非常困难的事情。如果团队没有经验，很难掌握好简化的度，过于简化的话，最小化可行产品很可能会变成最小化不可行产品。

这点在国内可能会比较容易解决，国内有着大量的人力资源，可以快速迭代出很多产品和功能，来弥补短板、找到成功的方向，然后把产品继续往前推进。但在美国招不到那么多人，所以要非常小心的把产品做好。

2. 产品经历了几次重新定位，社区的地位在变化

第二个让人很头疼的地方在于，社区不断扩大之后，社区反而就不那么重要了。发展到一定阶段之后，Instagram 有一半的用户都是匿名，如果不关注他，就很难找到他，也很难接收到他发布的内容。这时，图片关系已经被朋友圈关系所取代了，再说社区很重要就有点不切实际了。

3. 追求细节，还是快速开发

追求完美的好处非常显而易见，但它也会带来两个问题。第一，创始人过于专注于产品本身，会忽略整个社交产品的生态大局，比如 Instagram 就错失了把 Snapchat 干掉的机会；第二，追求完美也让产品的开发速度变慢，有些要试错的东西也试不了错。

所以，没有最好的文化，只有最适合当时环境的最有效的文化。国内很多公司都会学国外的工程师文化，但看到硅谷那些成功公司之后，需要先问自己一个问题，这些文化真的适合自己的公司吗?

以 Instagram 为例，Instagram 是一家很幸运的公司，在被收购前，它每个月的服务器流量是 400 万美金，如果不被 Facebook 收购，可能自己就撑不住庞大的服务器压力先挂掉了。

而 Facebook 的收购，不光给 Instagram 提供了无穷的现金资源，还帮它解决了图片审核的难题。大家都知道，色情图片的审核是一件很麻烦、很让人头疼的事情，但 Facebook 在这方面有着 10 多年的经验，一下子帮 Instagram 解决了这个后顾之忧。

被收购之后，当时创始人就多次表示可以只关注产品，反正背后有老大 Facebook，还有着 10 个亿的流量可以随便用。当时，Facebook 中 50% 的图片流量来自 Instagram，而从 Facebook 的图片里引回去的下载流量也有好几百万，再加上本身优秀的产品带来的较高用户留存率，Instagram 整个产品就起飞了。

因此，Instagram 文化形成的背后，是有一个老大在撑腰的。在 Instagram，我们可以有“追求细节”的文化，但在很多创业公司，可能产品快速开发上线，然后快速迭代才是他们要追求的，至于细节有没有解决好可能不是他们首要关注的。

所以，我们看硅谷这些明星文化的时候，一定要看到他们的优势和文化背后的代价。很多文化都是用钱、用资源烧出来的，不见得适合你。而如果没有那么多资源的话，不如老老实实分析当前团队的基础，然后在这个基础上，选择一个合适的文化，找合适的人。

作者简介

陈晨，Reddit Senior Director of Engineering。Instagram 最早的华人工程师，经历了 Instagram 从 5000 万注册用户规模到 4 亿月活用户的巨大转变。2015 年年底加入 Reddit，用 90 天时间从 0 到 1 推出了 Reddit 官方移动应用，建立了移动团队，重构了公司的技术和业务平台。

（本文整理自 Senior Director of Engineering@Reddit 陈晨在 ArchSummit 大会上的分享，有删减。）

第78讲 | 陈晨：团队重组过程中踩过的坑

你好，我是陈晨，现在在 Reddit 担任 Senior Director of Engineering。刚加入的时候，Reddit 只有 30 多人，如今已经扩张到近 300 人的规模了。在 Reddit，我经历了一家公司从小到大的成长过程，也经历了团队大了之后重组的过程，所以今天想跟大家分享一些关于团队重组的话题。

团队重组基本上是每一个发展壮大的团队都无法避免的选择。团队大了之后会遇到很多问题，比如流程混乱、产品规划不明确、团队之间内耗严重等，而一个比较好的解决方案就是团队重组。

团队重组

我刚到 Reddit 的时候，因为整个公司也就三四十号人，规模比较小，所以当时的技术团队是按照技术领域水平分割的，做 Web 的一个组、做 iOS 的一个组、做安卓的一个组等，这也是创业公司比较常见的团队划分方法。

这样的划分会存在一些问题，首先，当产品出问题的时候，你很难去找到一个负责人，负责把这个问题解决掉。其次，产品经理会很郁闷，他至少要跟三个团队打交道，一个简单事情的推进都要开一堆会。最后，多个项目同时进行的时候，工程主管也会变成流程的瓶颈，他需要在无数的项目之间切换，同时要协调好工程师之间的资源，这是一件很深奥的事情。

除了这些流程上的问题，更严重的问题是团队之间的信任关系会被破坏。一个好的管理者必须要把团队之间的依赖关系弱化，否则团队一旦过载，一个团队进度就会依赖于另一个团队的进度，比如说后台 API 开发延期，前端工程师的进度就会受到影响，继而产品进度就会受到影响。

而产品进度一旦出现问题，没法按时交付，整个技术团队就会受到高层的问责。面对这种情况，技术团队之间就极有可能互相推诿，把责任推给对方，久而久之，团队之间的摩擦变多，信任关系也就越来越差，而这对于公司的文化是致命的。

为了解决这些问题，我们的做法是将团队进行重组，按照业务方向做了垂直分割，如视频、搜索、社交、增长等，每个业务都有自己的团队，从设计、产品到开发人员，各个角色都有，组成一个极其完整的团队。

如图中所示，在整个技术组织架构中，中间是各个业务线团队，上面是一个共享的团队，负责整个公司的产品发布，下面是中间层和基础层的东西，这些东西没办法分开，我们就划分出专门的团队来负责他们，包括 API Services、Native Core、Web Core 等。

团队重组的难处

这样重组团队的好处是，首先，项目需求决定人员需求，减少人员浪费；其次，彼此分工明确，团队间的交流损耗降低；最后，能消除团队之间的差距，加强凝聚力。但要做好团队重组也并非易事，会面临两个主要的难题，分别是人心和时机。

1. 人心

人是管理中最困难的环节，不管怎么管，总会出现一些让你措手不及的事情。我还在 Instagram 的时候，也遇到过类似的难题。当时 Instagram 到了 400 人的规模，也需要进行团队重组，只是在执行过程中没有很好的考虑到团队成员的心理因素，直接造成的后果就是，每两个星期就有一个 iOS 工程师辞职。到最后，当年跟我一起打下 iOS 江山的那些老员工，在半年时间里全都走光了。

很大程度上是因为他们感到不开心了。举个例子，他之前为 Instagram APP 付出极大心血，也全情投入，结果团队重组之后，被分到广告组去做广告了，这并不是他感兴趣的领域，而接手他工作的新人，在他看来又没有好好珍惜他之前写的代码，导致代码质量直线下降，可想而知他心里是个什么感受，必然不会好。

工程师做产品的时候，他们追求完美的性格会让他们为了一个产品而呕心沥血，也会对自己所做的东西感到自豪。而当你重组团队，把他做的事情交给别人，又让他去负责并不感兴趣的工作，他一定是感到不开心的。这时，如果管理层不跟他好好沟通，必然会导致他们失望直至最后选择离开。

所以，团队重组的时候，一定要考虑到人心，多多跟团队成员做深度沟通，在可能的情况下，尽量照顾到他们的需求。

2. 时机

团队重组这件事是迟早要做的，只是早做和晚做、早痛和晚痛的区别。晚做会会影响员工的快乐程度，造成团队成员流失，就像上面提的 Instagram 的例子，它到团队 400 人规模的时候再做团队重组其实已经有点晚了。

而早做的问题在于会降低效率。团队早期的时候，很多代码是共享的，工程师之间的协同是很重要的。这时，你把他们拆分到不同的业务小组里，那么他们之间协同的成本就会直线上升。这么做可能降低了产品团队之间的内耗，但却增加了工程师之间的沟通成本，降低了效率。

因此，对于领导者来说，要找到一个恰当的团队重组的时间点，过早或过晚都不好。我的经验是，在工程师团队达到 200 人规模左右的时候开始分割重组是比较合适的，千万不要等到 400 人规模，这算是我的血泪教训了。

这里大家常常会面临的一个问题是，比如原来 iOS 团队就是 iOS 团队，大家聚在一起，遇到问题可以一起讨论，也可以一起研究新技术，但重组之后，他们被分散到不同的业务团队里面，少了原来共同成长的氛围，比较孤单，可能话语权也会变弱，心里就会有些抵抗。

这时，短期的解决方法是依靠文化，比如我的做法是，每周组织一次亲友会，把原来 iOS 团队的同学都叫回来，大家聚在一起交流，分享最近做了些什么、遇到什么难题，大家可以出谋划策，另外，还可以组织一些技术分享，一起学习进步。总之，要让大家感到，虽然团队散了，但心没有散，大家还是一家人，而这就需要你作为 leader 多花费一些心思和精力了。

长期的解决方法是用老人带新人，给每个拆分后的业务团队都配备一个至 5 年工作经验以上的人，把他培养好之后再让他去培养、带领下面的成员，这样每个团队会有一个领头羊，团队其他成员的成长也会有方向。所以，垂直分割对于人员的要求非常高，这也要求你跟公司在招人环节协调好，找到合适的人才加入。

技术转型的困境

最后想跟大家分享一下技术转型过程中的注意点。团队扩大到一定规模之后，很多技术大牛都会或主动或被动的选择转型做管理，而在这个过程中，他们往往会面临 3 个难题：

凡事依旧亲力亲为，大量参与具体的代码编写工作，最后发现自己更像是一个技术领袖，而不是经理。

按技术直觉做事而忽视了流程，导致团队为了按期交付而大量加班。

缺乏规划和项目交付的经验，容易对项目产生乐观情绪，最后极有可能导致项目延期，或者在 deadline 之前加班赶工。

那么该怎么提高管理效率呢？以我培养 Engineering Manager 的经验来看：首先，要熟练使用工具，利用大量的工具，尽量把流程自动化，用工具管人而不是用人管人，这样管理压力会小很多。

其次，要分清主次，把重要的事情先解决掉，而那些不那么重要的事情就可以往后排。然后，让团队每人明确自己的职责和所有权，如果有人不清楚，你作为管理者就有责任跟他们讲清楚，一遍不行就讲十遍。

最后，让工程师驱使部分管理任务，激发他们的主观能动性，不要把很多事情都揽在自己身上亲力亲为，要学会放权。这样，也能更好的培养他们的能力。

对很多团队 leader，尤其是新手 leader 来说，准确预估项目开发时间是一件非常困难的事情，因为项目执行过程中的各种可变因素太多了。

跟大家分享一个 30% 法则，即一个新项目启动的时候，你可以先让团队中有经验的老员工预估需要多长时间，然后将他预估的时间除以 30%，也就是 0.3，得到的时长就是项目完成开发大概需要的时间。比如他预估需要 4 个星期，除以 0.3 后大概是 13 个星期，也就是这个项目我大概需要一个季度的时间才能做完。在我的实践中，这个方法预估出的时间是非常准的。

一般新手管理者的系数都在 30% 左右，真正有经验的管理者能达到 70%，但我至今还没有遇到过超过 70% 的人，究其原因可能在于项目开发中的不确定性太多了。如果感兴趣，不妨尝试一下。

结语： 团队重组基本上是每一个发展壮大的团队都无法避免的选择，将团队从原本的按技术方向水平划分，重组为按业务方向垂直划分是一个不错的选择。另外，在重组的时候，一定要注意把握好人心和时机，否则极有可能会事倍功半。

作者简介

陈晨，Reddit Senior Director of Engineering。Instagram 最早的华人工程师，经历了 Instagram 从 5000 万注册用户规模到 4 亿月活用户的巨大转变。2015 年年底加入 Reddit，用 90 天时间从 0 到 1 推出了 Reddit 官方移动应用，建立了移动团队，重构了公司的技术和业务平台。

（本文整理自陈晨在 ArchSummit 全球架构师峰会上的分享，有删减。）

第79讲 | 程军：从0到1打造高效技术团队的方法论

你好，我是贝壳研发总监、TGO 会员程军，今天想跟大家分享一些我关于打造高效技团队的认知，希望对你有用。

我的分享主要分成三篇，第一篇讲我对高效技术团队的看法以及我的方法论；第二篇讲我过去成功的实践，以及为什么这么做才能成功；第三篇讲我踩过的坑，以及从中得到的教训，自我复盘和螺旋上升。

曾国藩有言：“凡成大事，以识为主，以才为辅；人谋居半，天意居半。”以前不曾体会这句话中的奥秘，经过最近几年的实践，才发现这里深藏着人生的成功哲学。

“识”我认为就是一个人的大智慧、格局，有远见。“才”是一个人的小聪明，注意这里的小，意在小角度细枝末节的把握。

如果将这一观点套用到搭建高效技术团队这件事上，“识”和“才”分别是什么呢？

“识”是了解公司战略，并弄清当前所做的产品线对公司战略的达成有什么帮助等。“才”是先找 leader 还是干活的、选 Java 还是 Go 等人员招聘、技术选型等方向的具体事宜。不难得出结论，“识”是最重要的。

因此，要打造高效技术团队，先站在你可以认知到的全局高度去思考，比如我会去了解我的团队在公司组织架构中所处的位置，去了解公司的整体战略以及我所负责的产品对公司战略的影响。接着，作为 leader，当务之急就是思考怎么做才能支撑这个产品战略。这就是指导我从 0 到 1 搭建高效技术团队的方法论。

在这个方法论的指导下，为了满足产品需求，并和领导沟通团队当前的短期目标，作为 leader，我目前最重要的事就是快速组建核心团队。这又该如何破局呢？

按照我的方法论，可以分解成三点：

我们的雇主品牌怎么样，我们需要什么样的人才？

符合这些要求的人才在哪里？

我们用什么方法和渠道去接触这些人才并且吸引到这些人才？

通过执行上面的步骤，我们初步打造了一支团队，然而，团队组建起来就一切 OK 了么？事实上一切才刚刚开始，往后还有无数的挑战需要克服。那到底是什么支持我们做到更多更好呢？

其实在回答这个问题之前，我们要扪心自问一个问题，你选择软件行业的初心是什么？ 我摘录了一些同学的精彩回答：

高级工程师甲：看到师兄工资很高经常带着学妹下馆子，还时常在朋友圈晒他们在世界各地玩，也就跟风选择了。

架构师乙：能有一个自己的 Github Star 超过 100 的开源系统就知足了。

技术总监丙：希望若干年后，我可以指挥几十号人马奋勇打敌，打造一个一个公司明星级别产品。

CTO 丁：希望有一天，可以打造一款全国人民在用的真正解决用户需求的产品，并希望有机会以杰出校友的身份回到大学，给学妹学弟讲一讲这些年所经历的痛苦和快乐。

接着问题又来了，你的初心是什么呢？ 请默默的问自己。

于我而言，我个人的初心是可以有一支团队一起打造一款真正解决人类自身 bug 的产品（比如之前我在饿了么，就是解决人类懒这个 bug，但是负责的面还比较窄，只是一条比较独立的产品线）。

然后继续问自己，你的初心可以支持你走多远呢？

李嘉诚曾经说过一句话，你想过普通的生活，就会遇到普通的挫折。你想过最好的生活就会遇到最强的伤害。这个世界很公平，你想要最好，就一定会给你最痛。

而你的初心就是支撑你往前走的动力，如果你不能痛定思痛，不能深刻意识到自己最终想要的，那么一切困难挑战对你来说都是外界强加的，会非常痛苦。

那具体到执行中，我们在打造高效技术团队时，要怎么把“识”做好呢？我们可以从人、工程师文化、工程师绩效评价三个方面出发。

“识”的第一点是关注人。

从图中可以看出，我们做事的方法论是有先有目标，然后通过阶段反馈看结果，另外需要有一个抓手，而这个抓手核心就是人，或者说关键人物。

大家都知道一家公司的成功公式是：成功 = 战略 * 组织能力。然而，战略是由团队领袖思考和决定的，组织能力也是由这帮人来打造的，因此，这个公式核心还可以写成：成功 = 人 * 人。当然，这里的人并不是普通的人，而是指关键人物。

举一个例子，饿了么从大学宿舍开始创业到最终被阿里以 95 亿美金收购，创始人有一句话我很认同，“The way to do really big things is to do really small things and grow them bigger”。这就是目标，也是我前公司 CEO 认知外卖这件事可以做成的价值观，并且最后成为所有的饿了么同仁都认同的价值观。

对，他就是关键人物，他输出的价值观指导我们做什么事、我们做事的目标以及我们最终形成的价值观。

上面从整个公司的维度出发，那具体到一个技术团队，成功的两个要素战略和组织能力中，战略就是我们团队的目标，能高效完成一个个的产品就是我们的组织能力，土壤就是这两者从孵化到发展到成熟到衰败的沃土，也就是团队的价值观。

“识”的第二点是工程师文化。

工程师文化的核心体现是团队气氛、做人原则和做事方式。

团队气氛包括分享、开放和打破边界；做人原则包括敢承诺、自驱动和自省；做事方式包括讲逻辑、追求效率、自我闭环。

其中，我想重点分享一下打破边界这件事。以前，我们的管理经验都是把产品、前端、后端、QA 等团队割裂的，即使这些团队每天都在一起开早会、过技术方案设计，一起加班，一起推动产品上线，但其实，他们之间的沟通依旧存在或多或少的障碍，总感觉缺那么一点，意犹未尽。

比如开发和 QA 说我这个功能是异步实现的，QA 妹子一脸懵逼。

比如前端同学问后端同学你们数据库怎么设计的，后端同学会心一笑。

比如由于核心流程有漏洞，产品突然有一个紧急需求，开发和 QA 同学就不能理解，你产品之前设计的时候为什么没有想清楚。

我们的做法是，组织一些头脑风暴，把干系方拉在一起相互交流，大家会相互问一些平时不会问也没有场景问的问题，彼此知无不言。小的知识点当场就能回答，复杂一点需要体系来讲的则可以加入分享池。但这都是术而已，还更多打破边界的形式，你们有什么好的做法么，欢迎在留言区分享给大家。

通过这样的工程师文化驱动并持续一段时间，就会发现我们其实已经是一支快乐的学习型的团队了。

“识”的第三点是做好工程师绩效评价。

从图中可以看出，工程师绩效评价的核心是，怎么评判我们达成的结果符合预期，其关键是结果是否超过预期，以及个人在其中是否有成长并实现个人价值。大公司则有能力模型来直接定义每个技术级别在每一个考核项中需要达到的能力水平。

我们总是要求工程师按我们的文化做事，但是符合团队文化对工程师本身有什么好处呢？有，那就是极高的工程师绩效评价。有了这些好的评价，物质和精神的认可都会随之来到。

那作为 leader，怎么判断团队成员到底做的好不好呢？以下几点你可以参考：

可以把他负责的事在指定的时间截点做成。

做完之后他会思考有什么改进的办法，能让下次做的更好，并分享给其他的人或团队。

他会想着帮团队其他人员甚至团队本身解决问题，而不是只干好自己的。

他会去思考自己的工作结果是不是切中客户的需求，会去尝试帮自己的客户找到最合适他的需求，同时在多个关联方中平衡。

他会突破自己所在的认知高度去思考自己的工作，并站在他的下一个职级能力的角度，去看到问题的本质并给出最优的解决方案，学会取舍。

综上所述，其实工程师绩效评价的核心就是否超出预期，而有了这些好的评价，大家可以升职、加薪、迎娶白富美，反之就要继续回去写 bug、继续打怪升级。

结语

我从曾国潘的名言开头，接着给你介绍了我们要快速组建团队的原因，以及组建团队从哪几个方面入手。接着我们找到了到底是什么支持我个人和团队往前走，抓手是初心和达到目标后我们可以得到的回报，不管物质还是精神上的。

留一个思考题给你：按照我的方法论，目前你们团队最重要的事情是什么？欢迎给我留言，我们一起探讨和学习，共同进步。

感谢你的收听，我们下期再见。

作者简介

程军，现任贝壳技术总监，曾任饿了么技术总监、1 号店架构师，10 年以上互联网开发经验，8 年以上技术管理经验。

第80讲 | 马晋：技术Leader的持续成长

你好，我是百度网页搜索部主任研发架构师马晋。今天想结合自身成长经历跟大家分享技术 leader 的持续成长这一话题。

技术人走上管理岗位，度过初期阶段后，很有可能发现产品和技术架构已经趋于稳定，团队初具规模，业务流量也在稳步增长，整体慢慢进入一个稳定阶段。

这时，如何驱动自己保持动力，在技术和管理上进一步成长，并带动整个技术团队成长，是技术 leader 们面临的新挑战。

技术 leader 的持续成长

大部分情况下，技术 leader 就是团队的天花板，你的成长才能够带动身后整个团队的成长，如果你止步不前，后面同学的成长空间也会受限。

因此，作为技术 leader，首先要保持动力，追求卓越；其次要培养产品的洞察力，通过横向产品的拓展，带给团队成员更多的锻炼机会；最后要打造自己的技术影响力。

1. 保持动力，追求卓越

在保持动力，追求卓越这一点上，首先要保持对技术的深远追求，打造极致的用户体验。比如我所在的网页搜索团队之前做的千亿网页精细排序和索引更新实时化两个项目。

以千亿网页精细排序为例，最初的排序系统中，下层是一个召回模型，上层对召回结果做精细化排序，然而由于响应时间的问题，我们不可能在最顶层模块做更多的结果计算，而这会对最终的排序结果产生一定的影响。

当然，这种影响是非常小的，在整个搜索中可能只占长尾的 5%，在 82 原则中，我们甚至可以不去在意。但出于技术上的追求卓越，我们应当把它做到更好，让其他竞争对手难以望其项背，甚至直接放弃追逐，这样的理念是非常重要的。

因此，我们设计了新的架构，把所有精细化计算打散到最底层的召回模块中。这么做会使架构的复杂性变高，会使底层排序模块变重，会带来很多架构上的调整等等，会有种种困难拦路。尽管如此，我们还是下定决心去做，最终，这个项目获得了 2016 年百度的最高奖。

在技术成长的过程中，一定要保持这种追求卓越的精神和态度，这是非常重要的，而且要把这种精神传递给下面的梯队，让他们每个人都把这种追求卓越的理念根植在内心深处。

如此，团队中的每个人都有追求卓越的想法，就会主动对系统和产品提出改进思路，从反向推动我们前进和成长，也就形成了团队的动力。

最后是生活的动力，这是非常现实但却无法忽视的方面。现代人都面临着生活上的各种压力，但这些压力也是我们努力的动力，毕竟人类天然的会追求更好的生活。

2. 产品洞察力

产品洞察力是工程师团队比较欠缺的一块，但这又是工程师想要更进一步必须具备的能力。比较好的提升方式是多跟产品团队交流，不要抱有偏见和抵触。另外想更进一步的话，可以走出办公室，走进站长圈，多跟站长们接触交流，听听他们的想法。

3. 技术影响力

工程师应该更多的表达自己，不论是在公司内部还是公司外部，要主动走进公司讲堂、走进行业讲堂、拥抱开源社区。多跟团队内外的朋友分享自己的观点，以此来提升自己的技术影响力。

当你在讲台上的照片出现在媒体上、出现在内部员工群里的时候，对你自身技术品牌的打造会有极大的好处，对于提高团队凝聚力也有一定的好处，甚至招聘也会受益，毕竟程序员是很愿意崇拜和追随技术大牛的。

推动工程师团队的成长

工程师团队的成长要素，我将其总结为以下几点：

以团队带动个人

技术氛围建设

团队活动组织

工程师文化传承

团队合作障碍

我重点分享技术氛围的建设和打破团队合作障碍这两点。

技术氛围建设

技术氛围建设可以从学习小组、技术交流、挑战比赛这三个方向着手打造。

1. 学习小组

大家在学校里、实验室里应该都有过学习小组的经历，导师把大家组织在一起，分成几组一起看论文，然后互相分享自己的学习心得。

这个场景在公司里同样适用，而且是一种非常好的模式，能够强制性的启发一些同学的思想和认知。这样，能帮助团队同学在做具体业务的同时，还能了解跟进业界在学术、技术上的最新进展，是非常有价值的。

百度比较成功的一次小组是机器学习小组，当时网页搜索团队有 20 人报名参加，最后坚持到底的同学都成为了机器学习方向的骨干力量，分布在网页搜索的各个团队，也有人去了其他团队、其他公司成为了技术骨干，可以说是一个成长的快车道了。

2. 技术交流

现在业界的技术交流是比较频繁的，有或大或小各种领域的诸多技术会议。除了派团队工程师出门参加活动之外，我们也可以自己组织，邀请感兴趣领域的技术大牛来团队做交流。这时，就需要注意提前收集团队的问题，了解团队的需求，有针对性的邀请讲师，并提前跟讲师做好沟通，让讲师分享的内容能对于团队更有价值。

3. 挑战比赛

竞争机制是非常重要的，有竞争才有趣味，才能产生结果，否则事情很有可能就不了了之了。所以，组织一些挑战比赛就很有必要，百度就有 Hackathon 文化，每个月末都会抽出一个周末 24 小时或更长的时间，把工程师，甚至产品、设计等人员聚在一起，大家组队参赛，在规定时间内完成计划的项目，将自己的想法落地。

同时还会将大家分组 PK，看最后哪一组能获胜。当然输赢其实并不是很重要，最重要的是让大家在实践中得到学习和成长。

就我的实践而言，小团队的组织建设，应该采取强制性的手段，每个同学必须发言、必须思考；大团队则可以以兴趣驱动，筛选出真正对于某些方向和领域感兴趣的人，因为只有兴趣才能驱动他们坚持往下走。

团队沟通障碍

沟通其实有各种各样的技巧，但打破团队沟通障碍最重要的还是共赢和竞争。所谓共赢，即目标导向，大家在共同目标下通力协作，彼此形成合力，更快更好的实现未来目标。

当然，有些事情是很难沟通和协调好的，这时候就要在内部引入一些竞争机制，多团队竞争同一个目标也是一个选择，并非坏事。而且竞争并非你死我活，最终目标还是把事情做成功。具体是选择共赢还是竞争，大家可以根据实际情况来做决定。

结语

今天跟大家主要分享了技术 leader 该如何驱动自己保持动力，在技术和管理上进一步成长，并带动整个技术团队成长。关键是要保持对技术的卓越追求，同时不断培养自己的产品洞察力和技术影响力，让自己持续成长，并做好榜样，带动团队成员的成长。同时，作为技术 leader，可以尝试从技术氛围建设、工程师文化传承、打破团队合作障碍等方向着手，推动工程师团队的成长。

你是如何驱动自己保持动力持续成长的呢？欢迎在留言区跟大家分享你的经验。

感谢你的收听，我们下期再见！

作者简介

马晋，百度网页搜索部主任研发架构师，致力于搜索引擎索引性价比、检索架构等相关方面工作，推动百度索引规模的不断成长，主导百度索引规模从数亿成长为数千亿的一系列架构升级。

（本文整理自马晋在 ArchSummit 全球架构师峰会上的分享，有删减。）

第81讲 | 游舒帆：一流团队必备的商业思维能力

你好，我是箴亚管理顾问公司负责人、TGO 鲲鹏会台北分会学习委员游舒帆，今天想跟大家分享的话题是“一流团队必备的商业思维能力”。

还记得在今年在北京的 GTLC 全球技术领导力峰会上，大家讨论到一个议题，“CTO 愈来愈被要求要 COO 或 CEO 化”，众 CTO 不约而同的提到“CTO 再也无法只站在技术角度思考事情，必须要更深入企业经营，理解客户与市场，才能带领企业快速增长”。

其实，我认为 CTO 被要求 COO 化是一个伪命题，核心问题是企业沟通与创新的低效。

首先，传统 CTO 专注于技术领域，对公司业务理解少，对市场与客户的掌握度也不足，因此总是被动等待 CEO 或业务部门提出需求或下决定，研发部门则负责承接需求往下开发。其次，研发部门手上握有技术与数据，但对商业的理解不足，很难提出具有洞见的策略，并运用技术来驱动企业创新与增长。

所以，CTO COO 化的消极原因是能有效提升业务与研发对接的效率，而积极原因则是期待研发团队能成为企业的战略角色，带领企业走出另一条增长路线。

过去几年，我在团队内实施了一项大工程，我称之为“商业思维建构”。

商业思维建构的目的是让经营的思维与知识普及到研发主管与团队身上，我所谈论的不仅仅是让研发参与到业务活动中，而是包含了弭平研发与业务部门间的横向沟通落差，以及工程师与高阶领导间的上下沟通落差。

做业务的，不会理解研发，做研发的，也不会理解业务，彼此之间总有许多误解与纠葛；基层员工不理解主管，主管不理解老板，老板更不明白为何员工总是与他对立，彼此间的壁垒愈来愈大，在解决问题与确认需求时，往往需要经过多次修改、讨价还价，才能产生一个双方可以接受的版本，最后心不甘情不愿地妥协。

其实双方的角度（老板 vs. 员工、业务 vs. 研发）、知识领域（销售、技术）、承受的压力（业绩达成、项目进度）本来就不同，考虑点很难完全一致。而这就是组织沟通中最常发生问题的地方。

我推动的“商业思维建构”工程的基本构想，是要让团队成员更熟悉公司运作，掌握企业经营的本质，理解公司策略，藉此弭平基层与经营层之间因为组织位阶造成的差距；同时也让团队同仁跨越研发的边界，更深入接触功能部门，包含流程、制度、日常工作等，甚至开始要求他们学习业务、营销与服务相关的知识，藉此缩短彼此在专业知识上的差距。

我在公司运作了这个工程一两年，成效颇丰，不仅沟通变的更高效了，许多制度的推动也愈来愈顺畅。最棒的一点是，当许多工程师理解了商业知识后，能反过来运用技术，以业务部门想象外的方法达成公司目标。

为了方便大家记忆，我试着将我实践的内容汇整成商业思维四力，这四力分别是数据力、运营力、策略力与敏捷力，以下是这四力的概述，往后几篇我则将针对此四力做深入剖析。

数据力

首先谈数据力，我从公司的财务面开始谈起，告诉大家收入、成本与现金流的观念，内容涵盖了固定成本、变动成本、毛利、净利等基本观念，并进一步拆解收入结构，让大家清楚公司靠什么赚钱，哪种商业模式的获利最佳；再拆解成本结构，让各位明白钱都花在哪些地方，哪些地方在浪费钱；再接着拆解客户结构，让大家更清楚哪些族群的客户最忠诚，贡献了最多的业绩。

接着，我进一步提到提升业绩的方法。我简单说明客户分群、分级，精准营销、交叉销售、客情维系、渠道管理、转换率优化等概念与公司内的做法，并运用案例来告诉大家怎么从数据中找出经营的问题，例如业绩未达成的原因，名单转换率下降的原因等。

我告诉大家，这些都能从数据反映，也是研发部门能产生巨大价值的地方，过去我们空有数据，但却在等待 CEO 或业务部门的指令，现在我们知道这些数据背后的价值了，你还会得物而无所用吗？

说完这些，大家顿时清楚了公司的运作机制，也了解高管们常常挂在嘴上讲的那些数字背后的意思。更重要的，大家都搞清楚了一件事，那就是「如果你不知道手上的工作能为哪个数字产生贡献，那你根本不应该做这件事」。
我后来发现，其实不仅研发与后勤人员对数字观念陌生，连业务、营销人员也是一知半解，我有必要去普及这些知识。

运营力

第二部分是运营力，过往我们熟知的运营，大多是套用增长黑客的 AARRR 模型，从用户获取、激活、成交、留存到推荐，有节奏与计划的去转化用户。而运营力强调的不仅仅是让研发部门熟悉运营的知识，更要能善用数据与算法等技术性手法，更大规模且更精准的做好运营工作。

我所追求的是不用人工介入，系统与算法便能持续做好运营工作，相较电商过重的人工运营，我更乐意研究 Netflix 与今日头条这种仰赖推荐算法的运营方式；相较于运用黑客手法来创造短期爆量，我更崇尚运用正规手法来实现长期稳健的增长。

我认为运营不能只靠出奇制胜，总想着靠创意来运营，而是该守正出奇，先将该做且能做的先做好，剩下的才来考验创意。在这个前提下，运营力本质上更强调用户的健康程度，也同时考虑了规模化过程，运营如何日益高效。

策略力

第三部分谈策略力，过去在工作中我最常问 team member：「你知道这项目是怎么来的？为什么而做吗？」，我发现能正确回答这个问题的人少之又少。

其实这问题背后，我问的就是策略与目标。企业在做策略规划时，往往都是一群高管聚在一起，根据目标讨论出策略，接着就定行动方案，而这些行动方案就化为一个个项目，分派到各个部门。

但如我前面所说，高管们熟悉策略与经营，但已经脱离一线工作太久了，他们订出来的行动方案真的能解决问题吗？

坦白说，出错的机率非常高。

高管们当然不是故意的，而是因为专业领域与组织位阶差距造成的误判。如果策略本身没错，但行动方向有错，承接需求的人又没搞清楚具体要解决什么问题，就贸然投入去做，最后的结果就是多做多错。

实务上，多数的员工并不清楚手边的任务是为何而做，更不清楚它是连结到公司的哪个策略目标。从商业思维的角度，我们希望每个员工都要能清楚陈述他所做的每件事情的价值为何？具体能为哪个目标或指标起到贡献。

习惯上我会运用 OKR 与策略地图方法来有效连接企业、团队与个人目标，通过过解构目标策略行动间的连结性，每个团队成员对自己的价值会有更清楚的认识，对企业的认同感与向上的沟通能力也会因此大幅增强，战略能力也会在这过程中不断培养起来。

敏捷力

最后是敏捷力，敏捷是互联网的基础观念，本质上就是用来应对外部环境的不确定性。敏捷所谈的快速交付、试错、迭代等观念，都是为了让企业在面临不确定性时，能套用的一些基本规则与做法。

在推动团队敏捷化过程，我并没有引入任何的敏捷框架，唯一的指导原则就是“持续追求更快、更好、更有价值”。

“快”，通常强调的是应变的快，调整的快，这与组织架构、分工，以及决策过程有关；

“好”，就是交付的质量，说得出做的到，总是能交付出可预期的成果；

“有价值”，则是源自于方向与优先级正确，这与企业战略与目标设定有关。

在过去，敏捷的推动大致只限于技术团队内部，但我一直认为跨不出技术部门的敏捷都无法真正敏捷，因此我也将上述观念推到营销、销售与服务上，让所有人都理解敏捷的真正价值与必要性。

总结

商业经营不仅仅是经营层或业务部门的责任，而是人人都该为经营尽一份心力，商业思维萃取了企业经营最核心的几个关键点，有助于提升团队对商业的认知。

数据力与策略力能有效弭平组织位阶与专业领域落差的关键知识；运营力则让所有人能聚焦于用户身上，运用技术与非技术的方法来做好运营工作；而敏捷力则让我们从开发团队敏捷，走入全组织敏捷，让企业高效运作。

思考题

你所在的企业与团队内部存在哪些沟通上的落差？除了建立商业思维外是否还有其他做法？欢迎在留言区跟大家分享你的经验。

感谢你的收听，我们下期再见！

作者简介

游舒帆，昵称 gipi，箴亚管理顾问公司负责人、TGO 鲲鹏会台北分会学习委员。技术起家，后走入管理、产品、营运相关领域，历任鼎捷软件技术总监、TutorABC 研发总监，熟悉 B2B 软件与在线教育。长年耕耘技术、管理与商业领域，现从事顾问、培训与教练工作，期许自己为社会输送更多的卓越领导者。

第82讲 | 游舒帆：数据力，透过数据掌握公司经营大小事

你好，我是箴亚管理顾问公司负责人、TGO 鲲鹏会台北分会学习委员游舒帆，今天想继续跟大家分享“一流团队必备的商业思维能力”这一主题。

上一篇文章中，我们谈了商业思维的概论，本篇将与大家分享商业思维中的数据力——如何透过数据来掌握公司的大小事？谈数据力时，我基本不谈资产配置或资金操作这种高度专业性的财务内容，而是聚焦于经营上的关键数据，即销售与销售创造的财务结果，藉此建立正确的数字观念。

数字观念之利润率观念

谈到数字观念，一般我们还是会谈到利润率，利润又可分为毛利率与净利率，而提到利润率，就必须得先谈谈收入与成本的观念。从毛利与净利的角度来看，成本可以分成两大类，即变动成本与固定成本，变动成本指的是会随销货量多寡而变化的成本，例如运费、广告费等，固定成本则是不随销货量而变化的成本，例如办公室租金、人事费等。

毛利指的是收入扣除变动成本后获得的数值，这个数值除以收入即得毛利率，净利则是毛利扣除固定成本后获得的数值，这个数值除以收入即得净利率。

有了对利润的基本观念后，我们就要进一步探讨，如何有效的提高经营利润？这个问题的答案很简单，其实就是提高收入与降低成本，听到这，你可能会觉得很像在讲废话，但如果我进一步追问：“你知道公司收入怎么来吗？”、“透过那些产品或哪些服务？个别的占比是多少？”、“透过那些渠道获客？个别的流量与营收占比又是多少？”这三个问题，营销团队应该要能立马答得出来。

然而从产品或渠道来展开收入状况，这只是单一维度的数据，很容易取得，但若我把产品对应渠道做一个二维的展开，让我们进一步了解“什么产品在哪些渠道上卖的好”，这将有助于我们在正确的渠道上铺货。

若我们在产品与渠道的维度上再加一个客户维度成为三维数据，那我们就能看出“哪些客人通常在什么样的渠道上购买什么样的商品”，这就是新零售中所谈论的人货场的典型场景。毋需大数据，也毋需 CRM，只要具备基础的数据观念，程序员就能轻松做到这件事。运用一个很简单有效的案例，就能展现数据的威力了。

数字观念之成本观念

接着谈成本，我觉得多人在收入上的观念还可以，但成本观念往往很差，我不只一次听到销售人员跟我说“这产品 2 万元，打个五折我们都还稳赚，售价不用订这么贵比较好卖”。我当下问他：“你知道我们的成本多少钱吗？然后运营这个客户，服务这个客户都不用花钱吗？”，他顿时答不上来，其实这个产品的利润并不高，折扣打到 55 折以下就要亏本了。

其实，多数员工是缺乏成本观念的，所以我还是会不厌其烦的要大家搞清楚每个产品的成本结构，这样才清楚促销的最低门坎应该抓在哪。将上述的收入与成本合并检视后，你看到的不再是整体的利润状况，而是能进一步看到单一产品、单一渠道以及特定产品加特定渠道的利润状况。

如果你是做产品的，掌握这些信息，会有助于你更好的做产品订价与成本的控制；如果你是做运营的，这将有助于你精算在获客、留存等运营工作所能投入的资源；如果你是写程序的，你能运用数据将这些信息呈现出来，并有理有据的跟产品经理沟通方案的正确性。

找出最佳获利商业模式

到这边，帮大家再一次把利润率的观念重新复习了一次，接着要跟大家探讨另一个重要的话题。

“我如何知道做一单生意是否赚钱？”

会计师或财会人员会跟你说看毛利或净利，然而毛利只看变动成本，服务这位客户的人事成本并不会被计算在里头，因为在传统的会计科目上，人事成本一般被归到固定成本里头。若我们改看净利，里头又涉及了太多非直接与客户相关的费用，例如厂房租金、折旧费用等。

若真的要知道做一单生意是否赚钱，成本应该是这么算的，将客户获取成本加上运营与服务成本。而所谓的客户获取成本指的是从触及客户开始，到客户下订单付钱为止所花的成本。纯互联网或纯电商，一般算的就是广告与生产成本，但若你是透过电销或面销来完成订单，那你必须将业务开发的时间成本也算进去，这才是真实的客户获取成本。

而这一单生意到底赚不赚钱，就要看这张订单的客单价是否超过客户获取成本了。

在此我拿 Netflix 这家在线视频公司为例，Netflix 在美洲区，标准的会员服务一个月约收费 7.99 美元，但 Netflix 在美洲区的客户获取成本约 100 美元，这意味着客户最少要持续订阅超过 13 个月，Netflix 才能回本。而 Netflix 的流失率约 5%，意思是每个客人的平均订阅达 20 个月，换算成客户终身价值约为 160 美元，这是一种能稳健获利的商业模式。

实务上，若我们能把上述的观念厘清，产品经理大多能更深刻的理解产品的商业模式，以及问题在哪；而运营团队也会更清楚自己的目标应该设定在哪，以上述案例来说，就是低于 5% 的流失率；而开发团队，则会妥善运用数据，来做精准的服务推送，藉此提高用户体验，进而降低流失率。

指标管理

把最核心的利润观念谈完，紧接着我想跟大家再聊聊指标管理。程序员都很讨厌被指标给限制，讲白一点，我们都不喜欢为了达成指标而做事，但成为领导后，我们却又不得不面对指标，因此我们有必要对指标有个新的认识。
指针跟目标有很大的关联，指针是用来衡量目标是否被达成，若我们所做的事情无法对某个重要指标产生影响，这意味着我们不该做这件事。在指标管理上，有三个很重要的观念：

第一，指针必然要连动到目标，否则指针达成也不意味着目标实现了，详细内容我们在第四篇讲策略力时会谈的更深入。

第二，永远要关注领先指标，而非将重点放在落后标上。所谓的落后指标指的是业绩、利润率，这是结果指标，是落后的，若我们要有效改善落后指标，我们就必须要掌握领先指标，以电商来说就是曝光数、浏览数、订单数以及对应的转化率，以 B2B 来说，就是名单数、拜访数与成交数以及对应的转化率。

当周、当月的业绩是否能达到，不用等到业绩出现，只要我们盘点手上掌握的曝光数、浏览数、名单数、拜访状况大概就能推估出结果，而且准确率可达 80% 上下，而提早知道状况，营销与销售部门便能更快提出应急方案，不用等到营收数字未达标时才处理。

第三，守正而出奇，降低外部依赖性，不能把希望全寄托在难以控制的因素上，例如付费广告、黑客手法或期待一夕爆红，广告可能被垄断，黑客手法可能被封锁，活动爆红有时可遇不可求。反之，把握度高的旧客户、原生流量我们一定要拿下来，先守住应得的，不足的部分才思考如何出奇致胜，是谓先守正，后出奇。

每个业绩周期开始前，我一定会先盘点一下可能的业绩数字，如何盘点呢？基本就按下方顺序进行：

该周期内会有多少旧客符合回购资格？乘以平均回购率与客单价，可以大概算出一个因回购而创造的业绩数字。

有多少客户可能会帮我推荐新客户？进一步算出因推荐而创造的业绩数字。

有把握的原生流量又有多少？进一步算出原生流量创造的业绩数字。

有多少旧名单能运用？这可以算出持续转化旧名单所能带来的业绩数字。

上述四项做完，已经能达成当月业绩的 60%，剩下的 40% 就是我们真正要努力的地方，可能是广告、营销活动，也可能是增长手法，带来瞬间流量或提高转化率。然而不论是哪一种，掌握正确的数据，提高可预期性，是数据化管理最核心的原则。这部分的细节，我将会在第三篇运营力中跟大家深谈。

数据模型与用户画像

最后，跟大家聊聊数据模型与用户画像，这两者都高度仰赖数据支持，过去我常用的数据模型有三个：流失模型、续订模型与推荐模型，能让我们知道什么样的客户会流失、续订与推荐。

举例来说，我将流失客户的个人属性数据与行为数据拿出来做统计分析，找出高相关性的因子，后来发现，只要客户符合下述三个条件时，流失率高达 90%：

上次消费日期距今超过 6 个月

近一年消费次数低于 2 次

近一年消费金额低于 2,000 元

这就是流失客户模型，也是流失客户的基本画像，接着拿所有的客户名单去跑这个模型，把符合上述条件的客户清单找出来，这份清单就是潜在流失客户清单，若知道这群人将会流失，我们就必须要有对应的行动来防止他们真的流失。同样的手法也适用于回购、推荐，甚至其他事情上。

结语

数据，能让我们掌握现况，找出规律。很多时候，企业并非在战略上输掉，而是在日复一日的工作中没有确切的掌握现况与抓住规律，因此在执行上盲目乱窜，却认为是战略错误，岂不可惜。

回到本文的开头，三大模型有效的降低了流失率，提高了推荐率与回购率达 5-10%，以利润率来看，我们提升了 10% 以上，团队检视自己工作产出时看到这样的成果，每个人都开心的不得了。

过去我们将业务、数据、研发团队分开，后来发现光是反复沟通彼此的需求就耗费掉 80-90% 的时间，后来我直接让工程师去学习数据科学，并亲自指导商业知识，团队的推进效率因此提升了 4-6 倍，原先花了一年都没搞定的三大模型，新团队在短短 2 个月内就一一产出了，而这正是商业思维最关键的魅力所在。

思考题

你所在公司的经营数据是否能完全揭露给员工？哪些可以揭露，哪些不能揭露？不能揭露的原因为何？如何让对的人握有数据，让数据真正发挥效用呢？欢迎在留言区跟大家分享你的经验。

感谢你的收听，我们下期再见！

作者简介

游舒帆，昵称 gipi，箴亚管理顾问公司负责人、TGO 鲲鹏会台北分会学习委员。技术起家，后走入管理、产品、营运相关领域，历任鼎捷软件技术总监、TutorABC 研发总监，熟悉 B2B 软件与在线教育。长年耕耘技术、管理与商业领域，现从事顾问、培训与教练工作，期许自己为社会输送更多的卓越领导者。

第83讲 | 游舒帆：运营力，让用户出现你期待的行为

你好，我是箴亚管理顾问公司负责人、TGO 鲲鹏会台北分会学习委员游舒帆，今天继续跟大家分享“一流团队必备的商业思维能力”这一主题。

这是本系列第三篇文章，今天要来跟大家聊聊运营力。关于运营，我想大家都不陌生，不论你听过的是互联网运营的拉新、留存、促活，或是增长黑客所谈的 AARRR，抑或是营销 4.0 所谈论的 5A 都不打紧，我今天想跟大家聊的是“为何所有人都该理解运营，以及研发人员掌握运营知识后，又有什显着效益”？

依托数据与运算技术的精准运营

若要用一句话谈运营，我是这么说的“运用在线或线下手法，让用户产生你期待的那些行为”，诸如点击、购买、使用、播放等。成功的运营会增强用户的黏性，也会间接提升公司经营绩效。

运营是围绕着用户而生，不论是产品、内容、活动、渠道等运营工作，本质上都是为了服务用户。

产品运营，让用户更多的去使用某些产品功能；

内容运营，提供用户更多有用、有趣的内容，让用户心有所感，甚至愿意分享；

活动运营，跟用户做更多的在线、线下互动，提高彼此的熟悉度与信任感；

渠道运营，保障跟用户接触的每个环节都能提供良好的用户体验。

流量红利消失的年代，营销领域的专家们纷纷提出企业不该再把过多的重点放在增量市场，而该更多的关注存量市场，观念上也该从经营流量，转往经营流量池。其实相同的概念我在前一篇的数据力中已经提到，企业必须先守正，而后出奇，而守正谈的就是做好相对可控的存量与流量池。

要做好流量池管理，关键是给用户提供更棒的服务体验。如今，标准化的服务模式已经愈来愈难取悦客户了，要让用户开心、买单，就非得提供差异化甚至个性化服务不可。精准运营，这个观念与精准营销是一致的，精准的背后仰赖的是对数据的分析与洞察。

以用户喜欢的方式，在正确的时间点，提供用户感兴趣的信息，这就是精准运营的关键所在。当你知道用户不接电话、不看短信、不点击邮件，只偏好微信讯息时，那你就要尽可能用微信来与他互动，并在他闲暇的时间，给他推送他会想看的内容或活动，这样才能实现精准运营。

你喜欢今日头条，因为它内容推的够精准，让你一篇又一篇的读下去；你续订了 Netflix，因为它推荐给你的影片你很喜欢，让你看完一部又一部。

这些，都仰赖足够的数据与运算技术，今年在北京的全球技术领导力峰会上，GrowingIO 创始人张溪梦在演说时援引了 Gartner 的一段话：

“全球 25% 的业绩将被具有企业家精神的 CTO透过创新以及技术优势直接转化为财务结果与市场份额。”

我认为这段话背后所谈的，就是靠数据与运算技术支撑起的精准运营。

运营中常被忽略的议题

前面花了一些篇幅说明运营与数据、技术间的关系，往下我想跟大家聊聊运营中时常被忽略的几个议题。

首先跟大家分享一个真实案例，我有个朋友经营了一间以提供保健食品为主的品牌电商。有次他跟我闲聊时提到客户回购率一直停留在 15% 上下的问题，努力了一整年才提升了一个百分点，不知道该怎么办才好，他甚至觉得是产品出了问题，所以客人才不回购。

听完他的描述，我问他：“客人们买回家后有没有开封吃，或者持续吃，这个你清楚吗？”

他说：“这不确定，但应该都会吃才对。”

我接着问：“那你觉得花了一大笔钱买在线课程的那些人，都会乖乖上课听课吗？”

对方露出了疑惑的表情说：“不见得，但在线课程跟保健食品不能直接对比吧？”

我跟他说我们不用瞎猜了，请你从那些应该回购却没有回购的客人名单中挑选 100 位，打电话逐一跟他们确认两件事，第一，确认他们是否有开封，第二，确认他们是否有吃完，然后下个礼拜我们再来讨论你收集回来的数据。

不到一周，我接到他的电话，他说：“真的被你猜到，客人有 85% 左右是还没吃完的，而这些客人里面有 20% 甚至连开封都没开，只有 15% 是吃完但没有继续回购的。”

从这个案例中，我们可以得到以下启示：

运营的数据若出现断链，决策就容易失准，我们必须尽可能掌握客户在线与线下的数据。

获取客户后，必须要非常关注客户的首次使用体验，这环节我称为用户的 onboarding，其他常用的词汇还有 AHA moment 与 first success，总之，我们要尽可能确保用户的首次体验。

客户首次使用后，必须养成他持续使用的习惯，让他获得原先期待的结果，以保健食品来说就是身体变健康了，以在线课程来说就是他真的学会了，进步了。

在此，我再举一个先前我负责的在线学习平台的例子，其实学习类产品与保健食品之间有两个显着的相似性，第一，都是属于重要而不紧急的商品，短期内不学、不吃也不会造成重大伤害；第二，都不是用一次两次就会产生效果，而是必须使用一段时间才会渐渐看到成效。

前一篇的数据力文章中，我提到常用的数据模型有三个：流失模型、续订模型与推荐模型，能让我们知道什么样的客户会流失、续订与推荐。

在这个例子中，流失模型告诉我们，一堂课都没上的用户，对比有上一堂课的用户，退费率高达 7 倍之多；而续订与推荐模型则告诉我们，用户上课频率的稳定度高度关联于续订率与推荐率。

在这些前提下，我请产品经理与运营经理去思考，在用户生命周期中，我们存在哪些断链？我们又该如何解决？请试着提出可能的方案。

第一次提案时，他们认为改善用户引导功能会有助于用户完成首次上课，但如何让用户持续上课这个问题暂时没有方向。听完后，我问了他们几个问题：

假设用户连上网后都没有打开我们产品，优化了引导功能有什么作用呢？

用户上完一堂课，我们如何确保他会上下一堂呢？

经过约一个小时的讨论后，运营经理针对首次使用提出了一个很不错的做法，他说：“可以让电销业务在成交后直接帮用户订好首次上课的时间，并让服务人员在上课前两天与当天联系客户，确保用户能完成第一堂课。”

这个建议很好，跳脱了产品的边界限制，将其他资源也拉了进来。

产品经理针对让用户持续上课这件事也提出了他的看法，他说：“我们必须要建立订课闭环，过去我们的流程是订课、上课、课后练习，但用户何时会订下一堂课呢？这我们一点把握也没有，若是我们将流程调整为订课、上课、课后练习、再订下一堂课，这样就形成了闭环，用户就能一堂一堂接着上了。”

这个建议也很棒，直接从使用流程上改变了用户行为。

上述两个做法，在经过两次迭代后全面采用，而为了降低运营成本，数据与技术团队们另外编写了信息推送服务，将引导、提醒与推荐系统化，有效的降低了人力需求。其中涉及了产品、技术、运营、业务与服务过程，若我们仍按过去的习惯，纯粹以技术解或产品解，而未从用户角度思考，并将各种可能的资源考虑进来，那根本无法有效的解决这个问题。

同时，在讨论现场我们重新绘制了用户生命周期，特别强调用户留存，将首次使用、闭环设计、沉睡客户唤醒、触动回购与推荐设计作为重点，有效的留住用户，并进一步扩大每位用户的终身价值。

从上述两个案例，我们可以了解到，每个产品的用户行为与生命周期虽然不尽相同，但都需要仰赖运营才能有效留存用户。当不同职能的人都能接触到公司的运营知识与流程时，你会发现大家都能从各自的专业领域提出有效的解决方案。

数据可以帮我们找出用户行为的规律性，而运营则能让我们进一步对症下药，规划适当的运营活动让用户产生预期行为。

结语

用户导向，用户思维，这是在运营力中我想强调的核心观念，运营不仅仅是运营或产品团队的责任，而是所有人的责任，每个人都该了解运营，并学习运营相关的知识，才能围绕着用户不断提高用户体验。

思考题

你的研发团队内是否有人非常熟悉用户与用户生命周期？公司运营的关键点在哪？如何有效提高研发人员的用户与运营思维呢？欢迎在留言区跟大家分享你的经验。

感谢你的收听，我们下期再见！

作者简介

游舒帆，昵称 gipi，箴亚管理顾问公司负责人、TGO 鲲鹏会台北分会学习委员。技术起家，后走入管理、产品、营运相关领域，历任鼎捷软件技术总监、TutorABC 研发总监，熟悉 B2B 软件与在线教育。长年耕耘技术、管理与商业领域，现从事顾问、培训与教练工作，期许自己为社会输送更多的卓越领导者。

第84讲 | 游舒帆：策略力，让目标与行动具备高度一致性

你好，我是箴亚管理顾问公司负责人、TGO 鲲鹏会台北分会学习委员游舒帆，今天继续跟大家分享“一流团队必备的商业思维能力”这一主题。

前几篇文章我们谈了数据力与运营力，让我们对公司与客户的状况有了进一步的剖析，本文将与大家探讨商业思维中的策略力。

策略力的原始目的是希望让所有人都清楚公司的目标，以及为了实现这些目标，我们订下了什么样的策略，紧接着，策略又是如何落地为一个又一个日常的项目与营运工作的。

以传统的组织分工来说，研发团队通常位于后勤角色，多数都是以支持各业务部门的战略为主，然而战略经过层层传达后，实际执行项目的一线员工们往往无法获知自己每天的开发工作，究竟是为何而做，更不明白项目完成后，究竟会对哪个 KPI 或目标有具体帮助。

有些人认为一线员工，尤其是研发同仁，并不需要了解公司战略与目标，只要专注的处理手上的项目就好。但我认为所有员工都必须要对战略与目标有清晰的理解，原因有四：

第一，让员工明白为何而战，唯有知道自己这么努力是为什么，员工才会倾注百分之百的热情。

第二，避免战略与现实脱钩，上层拍脑袋想出来的战略，很多时候并没有参酌一线员工的建议，不让听得见炮火的士兵参与战略的讨论与沟通，是许多企业最终战略失准的重要原因。

第三，培养员工的战略意识，具有战略意识的员工，在做每一件事情时都会仔细评估与思考，确保能对公司战略与目标产生真正帮助，而不会像只无头苍蝇般四处乱窜。

第四，让员工的绩效明确化，当员工所做的每件事都能连结到重要的 KPI 与目标时，员工的每分每秒就都能投入在有价值的事情上，回顾工作绩效时，一来，管理者易于评估，二来，员工也会很清楚自己的贡献与成长。

在培养员工战略思维能力时，我的做法并不是单纯的告知他们公司的战略目标是什么，而是进一步引导他们去思考战略的成因。一般来说，我会以下面 5 个步骤来引导大家将战略推导出来。

第一个步骤，检视现况，并标定机会。

检视现况时我会先抛几个问题让大家有切入点，这些问题分别是：

有哪些新的趋势议题与我们所属产业相关？我们是否能乘上风口？

我们产业的关键价值活动是什么？是否能延伸在产业链的位置？

我们的经营关键点与商业模式是什么？能看到什么突破口？

平常我们仰赖哪些数据在做管理？哪些数据有改善或精进的空间？

之所以要让大家思考这几个问题，而非直接从过去的经营内容中找出可改善的点并持续去调整的原因，是为了避免大家只着眼于短期，却忽略了长期的可能性。

这几个问题思考完后，接着要标定出“可能的机会”，我们要在众多机会中指出“属于我们的”机会，也就是必须要在评估自身资源与可行性后，挑出那些确切可行的项目。

谈到这时，你可能会有个疑问：“老板已经设定好自己的方向与目标了，我们还需要花时间做这些事吗？落实老板的战略不就行了？”

我的答案是：“需要的”，因为企业的战略的形成有两种，一种是自上而下，由领导阶层定义好，并逐层往下展开，落实到第一线人员的日常工作中；另一种则是自下而上，由对现场掌握度最高的一线人员提出，并纳入公司的战略中。就算是研发部门也应该要有自己部门的战略，并有效的连结到公司整体战略上。

企业的战略，其实人人都该关注，也该从你专业的角度提出你的看法与观点。若战略制定时，自上而下与自下而上能同时进行，双管齐下，走偏与白费工的机率就会大幅降低。因此，我认为“战略的制定与执行是全体员工共同的责任”。

第二个步骤，设定目标。

我们必须在第一个步骤中标定出的这些可能的机会中，找到最应该实践的几件事，设定目标。如果你是一个在线学习平台的 CTO，你设定的目标可能是发展人工智能以提升学习体验，或者是提高用户使用平台体验，进而提高留存与完课率。如果你是运营总监，你的目标可能是用户规模的三倍增长，或者有效降低用户流失率。

在此，我希望大家更审慎的设定目标，因为一个清晰的目标具有很高的引领效果，模糊的目标则会导致大家各自解读。那什么样的目标才算清晰呢？我认为必须要符合 SMART 原则：

S 是 Specific，具体明确的，要完成的项目包含哪些事？不包含哪些事？

M 是 Measurable，可衡量的，必须要有可量化的结果来确认事情已完成，否则很难去分辨「做好」与「做完」。

A 是 Attainable，可达成的，这个目标不应该是遥不可及的，虽然我们常说要设定高目标才有高达成，但如果这个目标怎么看都不可能，那反而会让大家无所适从，而且资源的使用也容易失准。

R 是 Relevant，具相关性的，承担这个目标的部门或人，他的工作项目必须要能高度关联于这个目标，否则便不该由他来负责。

T 是 Time-bound，具时效性的，三个月达成 100% 用户增长跟一年达成 100% 增长，做法肯定会有很大的差异。

第三个步骤，定义关键结果。

当我们设定好目标，接着要怎么去衡量目标是否达成呢？我们必须要能看到几个关键的产出物或结果，也就是所谓的关键结果 (Key Results)，往下我依循谷歌等知名国际公司运用的目标管理工具 OKR(Objective and Key Results) 来跟大家说明。

举上述学习平台运用人工智能以提升学习体验这个目标为例，我们若要有效衡量这个目标是否已经完成，我们可能会想看到以下三个关键结果：

第一，人工智能技术应用于的课件编辑，有效降低课件出错率自 8% 到 4%；

第二，人工智能技术应用于学生学习过程，提高学习满意度从 8.9 分到 9.2 分；

第三，人工智能技术应用于课程的精准推荐，提高学生的周订课数从 2.2 堂到 3 堂。

定义好关键结果，团队的努力方向就更明确了。谈到这我也必须要再次强调一个观念，那就是“别将手段当目的”、“技术也不是唯一解”，如果你在执行过程发现，不使用人工智能技术也能有效达成上述三个关键结果，而且做法更好更容易，那你就可以考虑放弃人工智能，因为人工智能是达成关键结果的手段，而非目的，降低课件出错率、提高学习满意度、提高订课数相对更接近目的。

再往上推一层，我们的根本目标是提升学习体验，若执行过程发现这三个关键结果与学习体验的关联性并非最强，那你就该调整这个目标的关键结果，不要被定义好的东西给绑死了。而这也是 OKR 跟传统 KPI 间一个比较显着的差异，OKR 接受来自执行层的反馈，随时可以依照现况去调整关键结果。

第四个步骤，设定行动方案。

有了具体的关键结果，那我们要做哪些事来达成这些关键结果呢？此时就落入到项目层级了，你必须为每个关键结果设定 1-2 个行动方案。

举例来说，提高学习满意度从 8.9 分到 9.2 分，在讨论过程我们认为影响学习满意度因素的有老师、课件、学生参与度、师生互动、网络通讯质量等，而我们认为学生参与度与与师生互动影响最大，但也不排除有其他影响因素，因此我们制订了以下两个行动方案。

第一个行动方案，采集学生上课期间的面部表情、对话与课后评价数据，并运用人工智能技术判断学生在课堂中的反应与参与度，如果学生表情显示有疑问，或者课堂的参与度不好，总是分心，那可直接提醒老师要多关怀该位学生。

第二个行动方案，调整学生课后的评价功能，从只能评分的选单式改成选单加标签式，让学生在评分之余，还可以透过标签来反馈感受好与不好的部分，这能让我们尽可能掌握学生真实的感受。

最后一个步骤，复盘。

行动方案开始执行后，我们必须定期检视执行进度与成效，根据现况不断修正行动方案、关键结果，有必要时甚至连目标都要修正。

总结

识别机会、标定目标、定义关键结果、设定行动方案到复盘，合理来说，识别机会阶段，领导阶层的参与度较高，标订目标、定义关键结果阶段，则是领导阶层与基层共同参与，而设定行动方案则以基层为主来进行，最后的复盘则由基层根据现况汇整结果，提出观察与建议后与领导阶层共同决定修正方案。

让员工具备策略力，让公司与团队上下都参与战略制订与执行过程，让所有人清楚自己是为何而战，员工的参与度会大幅提升，所有人都能紧扣着最重要的目标前进，我们才能真的让高层与基层间的沟通如臂使指般的顺畅运行。

思考题

如何清晰的描述公司的目标与策略？如何明确告知每个同仁，他在做的项目与哪个目标或关键结果有关？盘点你日常工作中，又有哪些其实是无法有效链接到任何目标或关键结果的？这几个思考会有助于你厘清现况，把时间花在真正重要的事情上。

感谢你的收听，我们下期再见！

作者简介

游舒帆，昵称 gipi，箴亚管理顾问公司负责人、TGO 鲲鹏会台北分会学习委员。技术起家，后走入管理、产品、营运相关领域，历任鼎捷软件技术总监、TutorABC 研发总监，熟悉 B2B 软件与在线教育。长年耕耘技术、管理与商业领域，现从事顾问、培训与教练工作，期许自己为社会输送更多的卓越领导者。

第85讲 | 游舒帆：敏捷力，拥抱不确定性，与VUCA共舞

你好，我是箴亚管理顾问公司负责人、TGO 鲲鹏会台北分会学习委员游舒帆，今天继续跟大家分享“一流团队必备的商业思维能力”这一系列文章。

这是本系列最后一篇文章，今天要来跟大家聊聊敏捷力。敏捷这个词在互联网爆发成长的这些年，早就已经被谈到过火，但这么多年观察下来，我发现敏捷这词被过度的曲解与滥用了，怎么说呢？

有些人以为每天早上开个站立会议、用白板来管理开发
工作，这就是 Scrum，就是敏捷实践；

有另一群人，把需求变来变去，朝令夕改，让技术团队不断变更优先级，搞得大家疲于奔命，然后丢下一句“你们要更敏捷才行”；

最糟糕的是那些，明明能花点时间就把问题厘清，少走许多冤枉路的事，却要急就章去做，然后碰个满鼻子灰才回过头来修正，说“我们要加快迭代速度，才能应付这些不确定性”，其实，很多不确定性都是自找的。

对敏捷错误的认知，很容易导致错误的结果，在长鞭效应的影响下，流程最末端的研发团队与程序员们，却必须以超时工作来填补因为项目的不断变更而衍生的额外工作。身为技术领导者，千万不能以这种错误的敏节观念做事，否则最终将累死自己，也累死团队。

若你想了解敏捷真正的精神，我建议你看看 agilemanifesto.org 上所述的敏捷 12 原则。

拉回主题，为何我将敏捷力放在商业思维系列文章的最后一篇？

首先让我们回顾一下前面几篇谈到的内容：

数据力，让你掌握公司现况，而且有数据的支撑，我们跨部门沟通与做决策时，会更有依据，更准更高效是一个可以期待的结果；

运营力，所有的任务都围绕着为客户提供价值，任何无法为用户产生价值的事，也无法为公司带来长期利润，这样的思路，有助于提高决策时的一致性；

策略力，让公司的目标从上到下认知一致，所有人都知道为何而战，所有人都能站在战略角度思考，决策不容易失准，而且战略的调整速度也会快上许多。

总结一下，数据力，让信息一致且透通；运营力与策略力则有效的凝聚了共同的方向与目标，三者对于企业的敏捷性都有极大的帮助。

我曾在台湾敏捷峰会上与大家分享一句话，在这也分享给大家：“如果敏捷走不出技术团队，就不可能真正敏捷”。若我只在研发团队内推动敏捷，成效其实非常有限，因为外部的其他人，总是会成为我们走向敏捷的阻碍。

因此，为了强化团队的敏捷性，我做了以下几件事：

首先，我以矩阵式组织重组了研发团队。

我将团队分成两种类型，一种归属于产品团队，另一种则划分到功能部门，每个部门由一到两个产品经理负责，让产品经理们可以深入的参与到公司的各个业务过程。

当研发团队与业务团队能更紧密的参与彼此的工作，绩效也互相挂勾时，默契与信任感就会渐渐产生，信息更透通，行动也更敏捷了。

第二步骤，建立彼此对优先级的认知。

我在技术领导力第 51 讲中曾提到三种决策方式：权力决、共识决与数据决，这三种决策方法我更倾向于数据决，但前提是这个数据是大家能信任，而且认可的。

为此，产品经理必须要跟业务部门一同敲定排优先序的规则。在排序之前，首先要将会影响优先级排序的要素陈列出来，例如提升业绩、提高用户体验、提高系统稳定性与性能等，给每个要素一定的权重值，并试算出每个项目的价值，价值愈高的优先级愈靠前。

权重值与排序规则通常会经过几次的修正，最终才能为大家所认可，做这件事的目的除了更高效的去排序工作外，更重要的是提升了彼此对事情的认知，我们都清楚对方在意些什么，也容易凝聚共识与目标。

此外，在面临难以抉择的选项时，业务部门也要给与产品经理足够的信任，尊重产品经理的专业决策。

第三步骤，加快迭代脚步，将项目切小，并优先执行最有价值的部分。

这个步骤看似简单，但若没有前面两个步骤来提升信任感与建立共识，落实的难度其实挺高的。过去项目较大，时程估期可能都在 3-6 个月，做价值排序时也是就整个大项目来计算。现在为了加快迭代速度，往往将项目切成 2-4 周交付一次，项目的顺序将有很大的变化。

举例来说，原先有个项目 A 要依序完成 1.2.3 到 10，共 10 项工作，为期 4 个月，项目的价值是带来 4,000 万业绩。现在我们若要将项目切为 A1、A2、A3、A4 四个迭代项目，我们必须针对原先的 10 项工作做重新的排序，可能 A1 先做 1.3 两个需求，完成后可以带来 2,000 万业绩，A2 则完成 2.4.5 三个需求，完成后可以带来 1,000 万业绩，也就是说我们仅完成了 50% 的需求，却已获得 75% 的价值。

剩余的 A3、A4 的价值只剩 1,000 万，拿来跟 B1、C1 等比较，重新排序后或许我们该优先进行 B1 而非 A3。而这就是将项目切小后的好处之一，让我们总是能优先进行价值最高的工作。

然而项目切小，对研发团队来说也是一个挑战，过去走 waterfall 的开发流程时，大家都很习惯将需求访谈期拉长，测试到布署的时间也往往估的较长，当项目最前与最后的工作都需要花费 1 周时，一个只有 4 周的项目开发时间便剩余 2 周了，这样的产出效率很难让人接受。因此，研发团队必须持续改善工作方法与流程，缩短项目的前后置时间，进一步提升生产效率。

第四步骤，凝聚共识，持续追求更快、更好、更有价值。

如我在前一篇策略力时所说，若你发现不利用人工智能技术就能创造出关键结果，那你可以选择不用。“解决问题，不必总是仰赖技术”这个观念我们也持续推广到研发部门外，让大家了解不是凡事都得靠系统，若时间真的急迫，但研发部门暂时排不出资源，我们还是会从专业角度提出其他建议方案。

我在技术领导力第 51 讲中曾举了个例子，是请客服部门先以人工服务的方式来提供产品预计要开发的功能。这个项目之所以能顺利推行，很大一部分仰赖于我们始终追求“更快交付价值”这个原则，否则程序员不会提出这样的建议，我也不会采纳这种非技术解决的方案，而客服主管更不会同意这种高度依赖人力的服务方式。

看到这，或许你会有个疑问，我们这样做难道不会只顾了短期需求而忽略长期吗？不会的，因为我们通过更短的交付周期，倒逼团队将每个项目的价值讲得更清楚，也因为更深入的参与了彼此的日常工作，沟通的落差减少了许多，并且因为具有足够的信任感，部门之间往往都能互相帮忙。

第五步骤，针对面临较高不确定性的部门，持续协助导入敏捷流程。

比如营销部门，过往他们最难回答的问题就是，一个活动举办后大概能创造多大的成效，导致大多数的营销项目最后都是超支预算才能达成原先的业绩目标。在营销项目上，我们以多个小项目同时推进的小步快跑的迭代方式，通过市场反馈与数据分析提高对现况的把握程度，更精准的达成了项目原始的目标。

若要拿实质成效来说，过去需求多数都来自于业务部门与高层，在我们持续推动商业思维与导入敏捷约莫一年后，研发团队的工作中，仅有 50% 来自业务部门与高层，而剩余的 50% 则来自研发团队自提的需求。我们清楚如何呈现技术型项目的价值，也知道我们应该优先做哪些事才能帮助公司达标。

总结

当所有部门都正确理解了敏捷，而非把敏捷视为研发团队的责任，企业才可能真正敏捷，面对多变且不确定的环境时，才能同舟共济，以达成目标为首要。

商业思维围绕着商业目标、用户与价值导向交付，将商业最核心的几个要素都含括在内，过去两年我不断在团队内传递这些重要的观念与知识，团队的凝聚力更强，组织运作也更高效了，创造的价值也提高了许多。

本系列文章到此告一段落，大家可以回顾一下这几天我们谈到的内容。再次思考数据、运营、策略与敏捷在工作中扮演的角色，并适度的将这些知识与观念普及于团队内。若你在看完这几篇内容后有任何问题，欢迎提出讨论。

作者简介：

游舒帆，昵称 gipi，箴亚管理顾问公司负责人、TGO 鲲鹏会台北分会学习委员。技术起家，后走入管理、产品、营运相关领域，历任鼎捷软件技术总监、TutorABC 研发总监，熟悉 B2B 软件与在线教育。长年耕耘技术、管理与商业领域，现从事顾问、培训与教练工作，期许自己为社会输送更多的卓越领导者。

第86讲 | 刘俊强：管理者必备的高效会议指南（上）

你好，我是腾讯云资深架构师、TGO 鲲鹏会会员刘俊强，有着 8 年以上的技术管理经验，今天想跟你分享一份“管理者必备的高效会议指南”。

在技术管理者的工作职责中，与团队保持良好沟通是必须的技能，而会议是沟通和完成实际工作的高效途径之一。

你有没有过这样的经历，参加某次会议时感觉自己的时间被浪费了，恨不得立马逃离现场去别的地方？作为管理者，我们希望自己所带领的团队举行会议时，不会让与会人员也有如此感受，本文就将探讨如何让会议高效化，并从会议中获得最大收益。

我将介绍一些举办高效有用会议的原则，会议之前的准备清单，确定最佳会议时间和创建会议议程的策略、贴士和技巧，以及在会议结束后该做的跟进工作等。

需要提醒的是，本指南主要面向的是小组会议，也就是至少三人参加的会议，不包括大型技术会议。而对于一对一的私人会议，之后将有另一篇文章来探讨——《做好一对一沟通的关键要素》。

成功会议的六个原则

举行高效会议会有许多原则，这里整理出来六个必不可少的原则，整个指南中，我们将遵循这六个原则来组织构建我们的会议：

明确目的：每次会议都应该有明确的目的，但事实是很多人都会随便开会，可能他们认为开会是个解决问题的方法。每次会议都应该有一个目标，这是我们举行或参加会议的原因，因此在安排会议并邀请其他人参加会议之前，首先要问自己这个问题，我想从这次会议中得到什么结果？

确认时间：简而言之，会议应该开多长时间？虽然会议长度没有严格的标准，但是我们的经验表明，会议越短越好。另外，会议可能会经常超时，简短而安排有效的会议，能迫使参会者在有限的会议时间内做出明智的决定。

必备议程：会议议程是参会者在会议中遵循的步骤大纲。议程可以帮助我们让会议更加专注，不让会议随意发散开来，本文稍后就将探讨如何创建议程，以及如何使用议程让每位参会者能够在会议中发表意见。

做好准备：在参加会议之前，每个参会者都应该花一些时间准备他们的问题，以及如何让他人明晰这些问题。本文将分享一些简单的方法，让准备工作变得简单，也对提高会议效率很有帮助。

专注重点：专注并坚持会议的目的，使会议参与者保持在正确的轨道上，让他们倾听、保持专注、避免多任务处理。重点缺失会使会议参与者容易分心，不能够专注地解决问题。

会议负责人：会议由谁负责？会议负责人可以是行政人员、经理或指定的会议主持人。无论这个人是谁或他们位居什么职位，每次会议都应该有会议负责人，会议负责人确保会议遵循以上五个有效的会议原则。他们使会议专注于目标并实现目标、确保会议按时开始和结束，并帮助其他人为会议做好准备且保持专注。

管理者越多使用上述六个高效会议原则：明确目的、确认时间、必备议程、做好准备、专注重点以及会议负责人，会让会议变得更成功而高效。

会议类型

没有一种会议类型可以满足所有需求，因此，面对不同的需求使用不同类型的会议是个好主意，可以实现最好的会议效果。有几种方法来对会议进行分类，这里我们使用时间维度，一般分为每日会议、每周会议和每月会议这三个主要类型。

每日会议可以有很多种，例如 Scrum 会议或每日站会、碰头会等。通常每日会议的目的是让每个团队成员签到并报告当天正在进行的工作，然后迅速投入工作，因此，这种会议的关键是要保持会议的简短。虽然本文分享的原则也适用于每日会议，但这种会议一般不会有特别正式的会议议程，并且也不需要花太多时间来培训团队成员。

下一种会议类型是每周一次，这也是最常见的会议类型。每周一次的会议一般来说更为正式，它的目的不仅仅是快速检查工作，还包括更多的合作和协调工作。因为这是最多的会议类型，所以本文的大部分内容会面向这种类型的会议展开。

最后一种类型的会议是每月、每季度或每年会议，一般来说用于培训、评审以及工作回顾等。通常，这类会议的目的是宣布一个新的重要项目，或者是帮助团队达到更高层次能力的培训，抑或是对于一段时间内的工作总结和回顾等。因此，本文中的大多数原则也仍然适用。

当你在看本会议指南时，不要试图一下子改善你所有的会议表现，而是选择这三个类型中的一个并集中思考怎么改善。在此我先提出一个问题，该如何使用在本文学到的原则来提高会议质量呢？

会议中的具体工具准备

随着技术的进步，我们开会的工具也在变化，例如投影、电视或在线会议等，相信不少人都有过因为工具的技术问题而造成会议停滞或拖延的经验，不过技术的进步也让各种会议工具的体验越来越流畅了。

为了使你和其它参会者的会议更加有效，我这里提供了一个非常简单的清单，会议负责人可以在每次会议开始之前使用。这个清单一共覆盖三种会议方式，一个是电话会议，另一个是需要演示的会议，最后一个是视频或网络会议。在每次会议开始前大约一小时用这个清单是个很好的做法，可以确保工具技术的每个方面都被检查且正常运行。

使用这个示例清单时要记住几件事，首先，它专为通常在公司或其他组织内部进行的小型会议而设计，并不适用于大型活动。此外，该清单的设计非常通用，适用于各种情况，因此，你可以根据自己的独特需求进行定制。

在任何会议中，确保每个人都有机会被听到和看到是会议负责人的工作，会议中的具体工具，需要你根据自己实际需求进行评估，例如网络摄像头、投影仪以及在线会议系统等，并询问 “如果我购买使用” 这些工具，它会极大地 “提高会议质量” 吗？

选取会议负责人

前面有说到，根据我的经验当会议有指定的负责人时，会议效果最好。会议负责人的责任是使会议保持专注和富有成效，他们提醒参会者基本规则，并且负责会议计时。

如何选择会议负责人可以根据你的方法来，一种简单的方法是基于职位，即让会议中最高职位者来做会议负责人，如技术经理、技术总监、项目负责人或首席技术官等，都可以担当会议负责人。这种方式的好处是已经包含了汇报架构和问责制，这种方法的缺点则是其他参会者可能就不会有机会来负责会议，另外，将职位最高者指定为会议负责人有时会让其他人觉得会议始终是由一个人控制或主导的。

选择会议负责人的另一种方法是轮换，让每个会议参与者都有机会来担当，任何方式的轮换都可以。这种方式的优势在于，它为通常不具备管理或领导职位的参会者提供了发展和实践领导力的机会，并且可以增加团队成员的工作满意度。同时，如果该小组的每个成员都有机会让其他人对基本规则负责，那么通常会增加他们对这些规则的遵循程度。

这种方法的缺点可能是，不同会议负责人带来的基本规则执行和重点不一致，小组内也有可能存在不想管理或领导的成员，强迫他们负责会议可能会带来反效果。另外，临时负责人可能不会像有经验的持续负责人那样做好准备，需要进行必要的辅导和指引才能很好胜任。

不论选取哪种方式，只要你选择一种方式并始终如一地使用，并不断修正该方法的弊端，都会取得不错的会议效果。因此，无论是现在，还是在下次会议开始时，确保你的每次会议都有一位会议负责人。

总结

受限于篇幅，本文中，我和你分享了一些举办高效有用会议的原则，包括明确目的、确认时间、必备议程、做好准备、专注重点以及会议负责人，合理运用这六大原则，可以让你的会议变得更成功而高效。

此外，我还和你分享了每次会议都要确保其有会议负责人，会议负责人可以是固定的，也可以是轮换的，各有其优缺点，但不论选取哪种方式，都要不断运用，并不断修正该方法的弊端。

下一篇文章中，我将跟你分享创建会议议程的具体策略、贴士和技巧，以及在会议结束后该做的跟进工作等，欢迎继续关注。

思考题

你平时组织会议时有遵循这六大原则吗？如果没有，之后准备如何改善呢？

感谢你的收听，我们下期再见！

作者介绍

刘俊强（微信公众号：程序员精进）现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+ 年以上互联网开发经验，8 年以上技术管理经验。

第87讲 | 刘俊强：管理者必备的高效会议指南（下）

你好，我是腾讯云资深架构师、TGO 鲲鹏会会员刘俊强，有着 8 年以上的技术管理经验。会议是技术管理者保持沟通、推动工作的必要手段，因此，如何确保会议高效且有效，是技术管理者必备的技能之一。

昨天的文章中，我跟你分享了举办高效会议的六大原则，包括明确目的、确认时间、必备议程、做好准备、专注重点以及会议负责人。还和你分享了会议负责人的重要性，他能确保会议遵循其余五个原则，能使会议专注于目标并实现目标、确保会议按时开始和结束，因此，每个会议都要确保有一位会议负责人。

今天，我将继续“管理者必备的高效会议指南”的下篇，与你分享创建会议议程的具体策略、贴士和技巧，以及在会议结束后该做的跟进工作等。

创建会议议程

这里我有一个会议议程的模板，根据你选择会议的类型，模板的某些部分不一定完整匹配你的需求，你可以随意调整这个议程模板并创建属于自己的议程模板。接下来，我将简单介绍该模板的使用指南，也就是怎么利用会议议程模板来举行高效会议。

我们先看看这个模板的左侧，这些是你在开会时要记住的重要指南，是我们举行会议时的重要参考，因为往往容易被忽略，所以我们再拿出来回顾下，从上至下分别是：

最终结果是什么？例如，在每次会议结束时，所有与会者都应该感受到被尊重，重视并且明确未来的行动步骤等。

为什么要举行此次会议？例如工作协作或协调类会议，帮助减少合作时的摩擦等。

与会人员，谁应该参加这次会议？何时举行会议，我们应该多久见面一次？

如何衡量会议是否成功？比如与会者请求帮助，会上成功给予其完成工作的必要帮助。

工具或资源需求有哪些？例如必要的资料（开发、产品），承诺完成的相关资料，会议记录和代办事项的系统等。

再次强调，模版不一定完全匹配你的需求，你可以根据自己的实际需求来调整这些原则。

接下来我们再来看看这个模版右侧的“会议执行步骤”，也就是会议该如何进行？

首先是准时开始，然后，会议负责人欢迎大家，此时负责人应该帮助与会者感到宾至如归。第三步，会议负责人向与会者简短的演示或培训有关会议内容、工具资源等相关内容，这个过程应该控制在大约三到五分钟内。

小组会议议程的第四步是让每个人快速报告他们在上次会议上所做的承诺，逐个询问每个人是否做到了，与会者回答是或否。接下来，将会议剩余时间减去五分钟留作总结时间，其余时间在成员之间平均分配，确保每个与会者都有发言权。举个例子，如果剩下 30 分钟并且有五个参与者，那么每个人将有五分钟的发言时间。

在最后五分钟内，会议负责人或会议记录员需要回顾并总结每个人在会议期间所做的承诺，然后再次确认下次会议的日期和时间。如果是轮换会议负责人的方式，还要确认下次会议的会议负责人。最后，尽量尽早结束会议，最好不要超时，通常会议时间越短效果越好。

跟进承诺任务

与会者在上次会议中确定的工作任务或承诺，需要在本次会议时进行汇报。这个过程实际上非常简单，会议负责人利用上一次会议的会议记录，朗读每个人的承诺，并简单地问道：“你这样做了吗？”，如果答案是肯定的，那么会议负责人可以提供简短的回答，如 “干得好” 或 “谢谢”。

但如果答案是否定的，会议负责人需要问对方“是什么妨碍你完成？” 或者 “遇到了什么障碍？”等类似的问题， 这比询问诸如 “你为什么不这样做？” 之类的问题要有效得多，因为后者非常强硬，并且经常会让人感觉是责备。这里我们不想责备或羞辱他人，相反，我们是要试图找到帮助他们完成工作的解决方案。

会议负责人应避免参与有关此人未完成承诺工作的延伸讨论，我们需要的只是简要解释发生的事情。如果此说明生成了一个主题，小组或会议负责人希望与所有与会者进一步讨论，那么可以将其添加到任务列表中，以便稍后讨论。

如果他们未能完成任务，则需要让他们对完成任务的日期和时间作出新的承诺，并在新的期限之前完成它。

在收到关于上次会议的待办事项或任务列表完成情况的简要报告后，你需要在其之上记录任何新的承诺，然后保持会议继续进行。通过采用这种方法，你可以提高承诺的完成率，并使会议更有意义。

如果你发现某人一直未能完成承诺的工作，那就需要进行一对一会议沟通了，而不要在小组会议中直接进行批评或指责。一对一会议是管理者协助员工履行承诺，以及探索导致员工缺乏后续行动力的深层原因的好方法。

另外，在会议上，你可以寻找每个参与者都做得好的事情并对其进行评论，给予对方简短、真诚的赞美，表明你已经看到他们的努力和付出。

结束会议

会议议程的最后一步是审查每个人的待办事项或工作任务，在整个会议期间，与会者可能都已经承诺将在某个时间内完成某些事情，通常在这一点上，会议负责人会将其转交给记录员，并要求他们总结承诺。

会议记录员会使用“谁、什么和何时”这三个要素总结每个人的承诺。换句话说，谁做出了承诺，他们要做什么，他们将在何时实现它，就这么简单。

在会议记录员通读列表时，每个与会者都应该密切关注并确保他们同意正在审核的承诺。

在审核了每个人的待办事项后，会议负责人就可以结束会议了，可以通过简单地确认下次会议的时间、会议地点以及确认任何其他会议来做到这一点。

如果需要在常规会议日程之外更详细地讨论有争议的话题，会议负责人将提醒每个人特别会议，并确保会议排上了他们的日程。

总结

本文中，我们已经探讨了一个可以在任何公司使用的高效会议框架，以提高会议效率并专注于结果为目的。如果你遵循本指南的建议，会议的有效性及效率应该得到改善，我希望确保你的会议每次都变得更好，最好的方法是制定一个计划，不断重新评估会议的有效性，也许可以每季度一次，使用会议的一部分时间向每位与会者询问 “这些会议是否有效？”，并根据反馈不断改进。

思考题

在介绍完高效会议指南后，咱们不妨在此思考下，接下来你要进行每周工作回顾会议，使用本文的操作方法或技巧，该怎么来准备、执行会议并保证会议执行的有效且高效呢？

感谢你的收听，我们下期再见！

作者介绍

刘俊强（微信公众号：程序员精进）现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+ 年以上互联网开发经验，8 年以上技术管理经验。

第88讲 | 刘俊强：做好一对一沟通的关键要素（上）

你好！我是腾讯云架构师、TGO 鲲鹏会会员刘俊强。在《管理者必备高效会议指南》一文中，我们探讨了如何高效地进行一对多的会议，使小组会议成为有效的沟通渠道。

今天，我想跟大家分享的是跟团队成员沟通的另一种有效方式，即一对一会议。一对一会议一般用于绩效面谈、员工问题指出以及职业发展规划等场景。定期的一对一会议为管理人员提供了解决问题的机会，并有效地回答了工作周期内出现的许多小而快速的问题。一对一会议还可以帮助员工提升技能，并能够有效改善团队的沟通情况。

在本文中，我将跟大家分享举行高效一对一会议的原则，以及如何建立一对一的会议议程，如何分配待办事项并回顾待办事项，如何评估会议结果并跟进完成情况等。

一对一会议的重要性

一对一会议是管理人员和团队成员相互沟通、互相跟进，并了解彼此工作关系的重要渠道。定期举行的一对一会议是最强大的管理工具之一，可以使管理工作事半功倍。

一对一会议是一个管理者和团队成员双方都应该感受到尊重和重视的场合，在这里，双方可以开诚布公地问对方问题。因此，一对一会议可以增强团队和你之间的信任感，并有效改善团队的沟通情况。

需要注意的是，一对一会议不适合头脑风暴和项目创建类场景，这些通常更适合在项目会议或定期小组会议中被处理。一对一会议也不是批评和强烈纠正问题的地方，虽然偶尔会有反馈和小的修正，但如果出现有待讨论的严重问题，应该在一对一会议之外进行讨论。一般而言，一对一会议更适用于你每天或每周定期与团队成员沟通。

谁需要进行一对一沟通

当我们说到一对一会议时，有些人不太确定他们应该与谁举行这样的会议。为了帮助你确定一对一会议的最佳人员，我提供了一个简单的工作表，可以引导你完成决策的制定过程。

现在我们来看看这个表格，第一列是“姓名”列，需要你在此写下经常一起工作的团队成员的姓名。第二列到第六列是评估列，我们将通过这几列的分数来评估你与每个团队成员的工作关系。

其中，第二列是“管理关系”列，它的可选值是 0 或 3，当答案肯定时填入 3、否定时填入 0，也就是，如果你管理着这位成员或者他在管理着你，就填入 3，反之则填入 0。

第三列是“问题”列，即多久问对方一次问题；第四列是“委派”列，即多久委派任务给该成员，或多久被该成员委派任务；第五列是“协调”列，即是否经常与该成员协调日常安排；第六列是“跟进”列，即多久跟进一次该成员。

这些列的分值都在 0-3 之间，0 代表从来不、1 代表很少、2 代表偶尔、3 代表经常。当然，填写时不需要特别精确，因为它只是一个主观的尺度，只是想借此找出需要一对一沟通的团队成员。

填写完毕后，将第二列到第六列的分数相加得出总分，然后根据总分高低进行排序。我的建议是，经常与表格中排名前三、前四名的成员进行一对一会议。

建立时间表

在你决定跟哪些团队成员进行一对一会议后，下一步就是建立时间表。

具体的会面频率以及会议时长，并没有一个标准答案，不过，以我的经验来看，最常见的一对一会议时间表是每月两次，每次会议时长为 25 分钟。因此，如果你不太确定该怎么处理，可以参考这个经验。

如果你认为每月两次会议不够的话，频率可以安排更高一些，但次数越频繁，会议时间就应该越短。总而言之，会议安排上可以比较灵活，但要确保留有足够的时间讨论我们可能遇到的各种问题。

确定了会议频率及时长之后，接下来就要将一对一会议排入你的日程，并让它形成定期模式，成为一种习惯。如果你不遵守时间表，一直错过会议时间，那会议的效果就会大打折扣。因此，坚持会议计划很重要，能让参会双方都感受到大家对于这个会议的重视和尊重。

确定议程

现在你已经建立了一对一的会议日程，接下来你可能想知道，议程是什么？应该涵盖哪些内容？下面我将提供一个简单的会议议程模板，你可以根据自己的特定需求调整此大纲。

首先，准时开始会议，这确立了互相尊重彼此时间和会议本身的价值。

其次，跟进上次会议中承诺的待办事项。如果对方达到预期，就可以赞美他，并问问对方从中收获了什么；如果对方没有达到预期，就可以问问对方遇到了什么阻碍，并对他进行指导修正。这很重要，因为我们在这些会议中所采取的行动与我们贯彻执行的能力一样宝贵，所以一定要检查参会者是否履行了承诺。

然后，进行简单的成长辅导或培训，大约三到五分钟。无论与谁见面，这都是一个很好的学习机会，可以帮助彼此逐渐成长。接下来到了议程的第四步，让对方有机会向你倾诉他的需求，你要耐心地听，让对方有机会询问他想问的问题。议程的第五步，你将扭转角色，现在，你有机会向对方提问并提出要求，包括将任务委托给对方。

之后，请回顾你们在会议期间彼此所做的承诺，这是你在下次一对一会议开始时需要检查的事情。最后，按时或早点结束会议，同样，这表明了对彼此时间的尊重。

帮助个人提升

当你是一名管理者时，一对一会议为你提供了一个帮助他人提升的机会，使你有机会为另一个人提供一些有针对性的培训。但由于一对一会议本身时长就相当短暂，所以，你需要保证培训内容简短、明晰，时长最好控制在五分钟内或者更短。那么，每次培训内容如何选择，用何种方法教授，你都需要仔细考量。基于时长考虑，我的建议是每次培训内容仅涵盖一个方面，尽量做到专注。这里有三种选择供你参考：

第一种选择是涵盖另一个人已经请求帮助的事宜；第二种选择是覆盖对方最需要的事宜，你的选择取决于你与对方的互动及其在公司的表现；第三种选择是提供有关新系统的培训，如果你的公司更改了规则或实施了新系统，那么一对一会议可能是回顾这些改变的最佳时机。

一旦你决定要培训对方，你就需要决定如何教他，同样有三种方式供你参考。第一种方式，你可以使用一个故事，如果是一个真实的故事就最好了。例如，你可以讲一个上周发生在你身上的事情，通过一个简短的故事来表达你的观点，要比直接告诉某人该做什么，所达到的效果更好。

第二种方式，使用简单的视觉辅助，比如照片或其他道具。通过视觉辅助来对关键信息建立记忆点。第三种方式，使用视频。短视频非常适合一对一训练场景，彼此可以一起观看后进行讨论。选择适合你和你的团队成员需求的方式，通过在一对一会议中提供简短的培训，为另一个人服务并帮助他改进。

总结

定期举行的一对一会议是最强大的管理工具之一，可以帮助管理者解决团队管理过程中遇到的问题，可以帮助员工提升技能，还可以有效改善团队之间的沟通状况，使管理工作事半功倍。本文分享了举行高效一对一会议的原则，以及如何确定一对一沟通的对象，如何建立一对一的会议议程，如何选择一对一沟通的方式等内容，希望能对你有用。

思考题

你跟你的团队成员多久进行一次一对一沟通呢？这样的频率对你的管理工作有帮助吗？欢迎留言分享。感谢你的收听，我们下期再见！

作者简介

刘俊强（微信公众号：程序员精进）现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+ 年以上互联网开发经验，8 年以上技术管理经验。

第89讲 | 刘俊强：做好一对一沟通的关键要素（下）

你好！我是腾讯云架构师、TGO 鲲鹏会会员刘俊强。定期举行的一对一会议是最强大的管理工具之一，他是管理人员和团队成员相互沟通、互相跟进，并了解彼此工作关系的重要渠道。用好一对一会议，可以使管理工作事半功倍。

昨天的文章中，我跟你分享了一对一会议的重要性，如何确定一对一沟通的对象，以及如何建立一对一的会议议程等内容。

我们来回顾一下一对一会议的流程。第一步是会议开始后，跟进上次会议中承诺的待办事项。第二步，进行简单的成长辅导或培训。第三步，倾听对方的需求。第四步，你转换角色，向对方分享。第五步，回顾会议并结束会议。

今天，我将跟大家分享更多实践，包括如何在一对一会议中倾听对方需求并分享你的需求，如何评估会议结果并跟进完成情况等内容。

跟进委派的任务

开始一对一会议后，首先需要跟进上次会议中委派的所有任务。这就需要你保留每次会议中达成共识的待办事项列表。无论你使用项目管理工具还是在自己喜欢的工具中创建任务列表，都需要将这份列表保存好，将它用于每次的一对一会议中，以便询问每个任务的进展。然后，根据对方完成的结果，酌情给予简短的赞扬或纠正。注意要以简短评论的方式操作，举个例子，如果对方完成了委派的任务，那么只需一句“做得好”就足够了。

你也可以询问对方在完成任务时收获了什么？这将让对方有时间停下来思考他所做的工作，并且创造了一个迷你教学时刻，让他跟你分享他获得的经验与见解，这些经验可能使未来的工作或委派任务变得更容易。

还有一种情况是，他没有完成委托任务怎么办？你可以问他，是什么阻碍了你完成这个任务？这比单纯询问未完成任务的原因更加有效。

举个例子，假如你问对方 “为什么不这样做？” 这可不利于你们增加彼此之间的信任。“为什么” 是一个非常强硬的词语，带有假设的责备态度。它会暗示对方，为什么你不能做到这一点？为什么你会失败？反之，通过询问具体的阻碍原因，可以了解到他未完成任务的具体原因，并帮助对方完成任务。在对方回答之后，你将更深入地了解如何帮助他完成任务，以及纠正未来可能出现的失误。

如果你确实需要纠正某人没有完成委派任务的问题，那么，请以真诚的赞美来进行更正。通过遵这种简单的模式，你将成为对方一个值得信赖的资源，而不是一个要求严格的主管。这样的结果是，大家会欢迎你的观点，并在发生错误时更加关注错误，因为大家会觉得你认识到了他们的优势，而不仅仅是他们的缺点。这种跟踪委派任务的简单方法将使你与他人的关系保持平稳，并能确保对分配的任务负责。

倾听对方的需求

在上一篇文章分享的一对一会议的议程中，在简单开场和跟进委派任务之后，就是简单辅导和培训。而一旦你在一对一会议中为对方提供了重点培训，议程的下一步就是讨论需求和问题。

如果你是会议负责人，请让对方先说，即管理者应该首先问对方“你有什么问题想问我？”你需要成为一个良好的倾听者，为对方创建一个安全的空间，让他在浏览任务列表时花些时间，确保他有机会询问他写下的任何问题，甚至在谈话期间想到的任何问题。

接下来，你需要从了解如何帮助对方的角度，认真倾听他对你提出的所有要求，并尽最大的努力以任何可能的方式帮助他们。

此外，清楚了解对方对你的期望后，当他们要求你做某件事时，一定要明确这件事相关的人、事宜及时间，这可以帮助你更好地准备以贯彻执行。最后，在听取意见和讨论之后，你应该酌情做出口头承诺，遵循并按照你所说的去做。

在一对一会议中，你最重要的角色是为另一个人服务。当你们都有服务态度时，一对一会议就会变得更有意义。

分享你的需求

现在轮到你在一对一会议期间分享你的需求了，你必须直截了当的说出自己的想法。如果你想让其他人帮助你取得成功，首先要让他们了解你的需求。

在会议中，如果另一个人需要花费很长时间来找你的需求，那对方就很难为你服务。因此，建议你在会议开始之前先了解自己的需求，这样，在一对一会议中，轮到你提出问题时，你就可以对照你之前准备好的任务列表，向对方提问。

提问时，我建议你采用开放式问题，而不是封闭式问题或是否型问题，这会鼓励参会者深入挖掘他的答案。例如，问他是否喜欢这个想法，要比问他喜欢或不喜欢这个想法的什么地方更为糟糕些。

如果你需要其他人的帮助，请具体说明你希望获得什么帮助，并描述当你获得他的帮助后，最终希望得到的结果是什么样的。

接着，在你对他应该实现的结果进行具体描述后，让他清楚地告诉你，他执行每个项目所需的人员、内容和时间。如果你提出请求时，对方直接或通过肢体语言间接地表达出犹豫的态度，这时你应该先停下来，询问对方在想什么，避免让对方做自己不想做的事情。这样的话，一对一会议就成了真正的伙伴关系，让你们步调一致并相互尊重地完成任务。

回顾并结束会议

在一对一会议期间有机会互相提问时，应该专注于执行相关的问题，特别是你们会后要采取的行动。轮流简要介绍你们对彼此做出的所有承诺，确保重复每个事项的人员、事宜内容和时间。

重复是有价值的，因为它可以帮助我们避免混淆和错误。另外，当重复人员、事宜内容和时间时，确保你允许对方自由地确定他的日程安排，以及完成任务的方式。而不是直接问他能在几天内完成这项任务，或能否在下周二完成这项任务。如果你需要协调时间表，那也没关系，可以跟对方协商，这样会比直接下达截止日期更为友好。

如果你已经将任务委派给其他人，并且你认为有必要跟进他们，那么请为自己创建提醒，以便跟进该执行人。也可以让执行人在规定时间用电子邮件的方式向你汇报结果。你需要关注任务完成的结果，而不是关注完成任务时具体采取的步骤，这样更能使对方感受到尊重，并避免不必要的微观管理。

最后，请务必按时或早点结束每次会议。如果你提前完成了会议的内容，这样很好，请保持并结束会议，没有人会抱怨会议提前结束。如果你尊重他人的时间，他们也会尊重你的时间，你越及时地结束会议并明确承诺，你就越能将一对一会议视为生产力的宝贵资源。

总结

在这两期的文章中，我们探讨了一个可以在任何公司使用的高效一对一会议框架，能使你的一对一会议更有效率并专注于结果。如果你遵循本文的建议，会议的有效性及效率都会有所改善。

我希望你的一对一会议能够变得越来越好，最好的方法是随着时间的推移而不断改进。你可以与你的会议合作伙伴一起设置定期计划，不断重新评估会议的有效性和效率。如果你把对方的需求放在首位，并履行你对他们的承诺，那么，你的一对一会议将变得富有成效，并面向结果。

思考题

在介绍完如何进行一对一会议后，咱们不妨在此思考下，接下来你要如何使用本文的操作方法或技巧，来对自己管理的团队进行定期一对一会议，然后观察这一做法对自己工作的提升以及团队管理顺畅度的改善情况。欢迎在留言区分享你的实践情况。

感谢你的收听，我们下期再见！

作者介绍

刘俊强（微信公众号：程序员精进）现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+ 年以上互联网开发经验，8 年以上技术管理经验。

第90讲 | 程军：打造高效技术团队之招人

你好，我是贝壳研发总监、TGO 会员程军，之前跟你分享过从 0 到 1 打造高效技团队的方法论，今天想跟你分享一些我的实践及背后的成功原因。

每一个人心中都有偶像，我的偶像是乔峰和李小龙。

从乔峰那里我学到了铁汉柔情、处事侠义、国家问题大于一切，回忆其中的情节，依然会被那种义薄云天的气概、那种大碗喝酒的豪爽触动，感到痛快不已。

李小龙，我之所以崇拜他，并不只是因为他武功高强，还在于他对武术的不断追求，他学习各类武术，汲取各家之长，从中国武术到世界武术，最终融合形成自己的“截拳道”。

很显然我的偶像都是集大成者，是杰出并且成功的。从他们身上，我找到了成功的因素，即对已选择目标的坚持称之行和达成目标后的认知升级，我将其称为知行合一。

然而现实生活中，每个能力不一样，能解决的问题大小也不一样，界定成功的标准也不一样，你又是如何定义自己的成功呢？

回到今天的话题，如何从 0 到 1 打造高效技术团队？在我的实践中，最关键的就是要做好两件事：招人和做事。虽然老生常谈，但却至关重要。今天我主要跟你聊聊招人这件事。

这是一个经久不衰的话题，从三国中的“刘关张”团队到西游记中的“西天取经”团队，不难发现，招人并选择合适的人是一个团队成功的关键因素之一。而具体到互联网行业怎么去招人，我认为两个最核心的因素是招聘渠道和识人。

1. 招聘渠道

我们常见的招聘渠道有以下几种：

我们的人脉；

Boss 直聘、脉脉、拉勾等招聘网站；

猎头渠道；

GitHub 等技术网站及论坛；

各种线下大会、线下沙龙，还有各种群等。

有人会说，这个有过几年管理经验的都知道，但是具体到实操层面，你如何快速招到合适的人呢？你会选择哪些办法呢？

我的做法是先把需求分类，一般分为核心骨干、高潜骨干、一线员工这三类，然后根据招聘规划列出总人数和分批的需求时间节点。

其中，一线员工可以去 boss 直聘等招聘网站，效果比较好，注意多平等沟通、多研究这类网站的攻略，就可以花更少的钱达到更好的效果。

通常，找到心仪的人才后，我会先简单问候，再添加微信，从他的朋友圈观察他是怎么样的人，然后找到彼此可聊的话题，并发掘他想要的东西，而这些恰好你能给的，具体策略可以详见后面的动力适配图。

而核心骨干和高潜骨干，建议还是通过我们的的人脉或朋友推荐比较靠谱。因为这类人才都不缺工作机会，缺的是一个相对适合的自己的机会。

对于高潜骨干，我们还可以通过猎头渠道从对手公司寻找，有时候会有非常不错的收获。对于这个渠道，我有三点建议想分享给你：

第一，一定要找 2 家或 3 家适合自己的猎头公司，向猎头顾问讲清楚你的需求，并且定期 review 结果、反思过程，并落实改进方案。

第二，猎头公司并不是越大越好，有时候公司小一点，但对方的专业度和资源投入度都足够的话，也是非常不错的选择，这些就需要你根据实际情况去判断和分析了。

第三，建议扩大选择范围，不要把目光只放在竞对公司，思路开阔一些，办法就会更多一些，也有助于你更快的找到你想要的人才。

2. 识人

谈到识人，各位都有都有自己的见解和做法，我也来先跟你分享一个识人的模型，如下图：

这个模型主要分为知识、经验、能力、动力四个模块。

识人的第一步，看知识和经验。

这两个模块都可以很容易的从候选人的简历和自我介绍中判断出来，并不难。比如你想找一个高级软件工程师，具体的数据库索引怎么设计，简单的算法和数据结构理论就是知识，做了两个实际的软件项目并且有一定的业务量就叫经验。

识人的第二步，看能力，以及他未来能做什么？

这个一般都需要多轮现场面试来判断，墨子曾经说过，听其言，迹其行，察其所能，即通过判断对方的过去行为，来推测他的能力。

那具体该怎么做呢？这里推荐一个模型——STAR 法则：

S 是 Situation，即情况；T 是 Task，即任务；A 是 Action，即行动；R 是 Result，即结果。

这几点是我们在面谈中需要重点考察的，即“在什么情况下 / 什么任务中 –> 候选人做了什么 -> 带来什么结果”。

举个例子，候选人说“我做了什么项目”，那就建议你再问问他“在这个项目里面具体都做了什么事情”？

候选人说“一般是这么干的”，你就要追问“你当时是怎么做的”？这里候选人用了含糊的概念。

还有一些候选人会做假设，比如“如果我是什么什么，我就能做到怎样怎样”，这些没有任何用，是无效的 STAR。当我们遇到这种情况时，就要让他具体化、典型化并可量化，从而避免一些模糊、主观、假设或者不具体的 STAR。

通常，候选人说一个观点或者结果的时候，你不但要让他举一个具体的例子，还要让他说出来当时这么做的优点，以及带来的问题。

因为这个世界是辩证的，每一种技术方案或者管理方法都有其优缺点，如果一个人说不出原委，或者你们聊的不透彻不痛快，那只能说明他从来没有认真思考过，或者即使思考了也深度有限，那就显而易见，对方并不是一个非常有能力的人。

识人的第三步，看动力。

那如何判断候选人是否有动力呢？这个动力本身就是如何自我说服换工作的内因，你应该见到过候选人换工作是因为女朋友异地恋的事吧。我一般会从三个框架去判断，你也可以参考：

职位是否适配，也就是岗位的工作领域和职责，与候选人的个人爱好是否吻合，以及工作本身是否令人满意甚至愉悦。

组织适配，也就是组织的运作模式和价值观所营造的工作环境和氛围与候选人的个人喜好的适配度。

地点适配，也就是工作或者组织的工作地点，与候选人的个人喜好是否匹配。

要进一步展开的话，下面这个动力适配图可以清晰的说明我的观点，图中，横轴描述的是候选人对工作的喜好程度，从不喜欢到喜欢，纵轴描述的是候选人期待的东西工作中有没有，从工作中没有到工作中有。

比如，第二象限的工作中有候选人期盼的东西，但他不喜欢这份工作，和第四象限的候选人喜欢这份工作，但工作中没有他期盼的东西，这两种情况都会导致候选人不开心，也就是他的痛点。我们就按照这张图找出这些痛点并且视情况满足他，直到他感觉到爽点。

这个理论还可以推广到日常的团队管理中，你是不是已经迫不及待想去尝试了：)，记得后面留言反馈我哦。

总结

这篇文章我和你分享了从 0 到 1 打造高效技术团队的两个核心因素，即招人和做事，并分享了如何将招人这件事落地，其中最关键的就是招聘渠道和识人两个方向。

在识人方面，我分享了一个模型，可以从知识、经验、能力、动力四个模块来判断候选人合适与否。其中看能力部分我分享了 STAR 法则，看动力部分我分享了动力适配图，都是可供具体实践的理论方法，希望能对你有用。

写到这里，我不禁想再点一支烟，眺望窗外漆黑的夜晚，我微微一笑。希望这篇文章可以启迪你的认知、进化你的认知。

文章中部分灵感来自 TGO 鲲鹏会会员王福强老师，谢谢老师给与的指导和批评。

留一个思考题给你：你在招人过程中有什么具体问题吗？欢迎留言分享，我非常愿意和你一起探讨和学习，共同进步。

感谢你的收听，我们下期再见。

作者简介

程军，现任贝壳技术总监，曾任饿了么技术总监、1 号店架构师，10 年以上互联网开发经验，8 年以上技术管理

第91讲 | 程军：打造高效技术团队之做事

你好，我是贝壳研发总监、TGO 会员程军。从我多年的实践来看，打造高效技术团队的关键就是招人和做事。

上一篇，我跟你分享了招人的那些事，包括招聘渠道和识人两个大方向。

其中，招聘渠道的关键是把人才需求分类，并根据不同的分类使用不同的招聘渠道，这样会获得更好的效果。而识人可以从知识、经验、能力、动力这四个模块出发，使用 STAR 法则、动力适配图等理论结合实践，快速提高自己的识人能力，找到合心意的人才。

众所周知，招人的核心原因是为了做事，所以，我今天就继续跟大家聊聊做事这个话题。

一、和业务心在一起

在我看来，团队必须要有一个共同的目标、可迭代的协作流程，以及统一的评价机制。

我之前在饿了么负责产品和研发落地，在实际执行中，我会先和业务负责人沟通好彼此做事的方法和节奏，最主要的是先确定下一个月的业务目标，然后产品和研发团队这边好确定产品的目标。

我们每个月都会集中过一次下个月计划落地的产品功能，如果业务方 OK，产品经理就会提前准备 PRD，这样至少可以让团队提前了解下个月的规划，研发和测试团队也能提前准备，有一个缓冲，应了那句古话“兵马未动粮草先行”。

如果碰到紧急需求，我们做法是紧急需求不需要排期，可以按约定砍掉一些 P0 需求。如果出现 P0 需求也砍不掉的情况，只能从灵活的组织能力出发，刚开始我们会从其他部门临时抽调人，后来的做法升级为在自己的团队中成立机动团队，这些人就是我们团队的特种兵，指哪打哪。

再来聊聊评价机制，人一般很难找到自己的问题，或者说很多人其实知道问题所在但是就是改不了，不知道你是否有相同感触。所以，定期和业务负责人乃至上级领导 one one 沟通，让他们指出自己做的不好的地方、欠考虑的地方，是真的可以帮助自己和团队改进和提升。

举个例子，曾经有业务负责人对我说，你们团队执行力很强，但是产品负责人没有自己独立思考的能力，比如在他没有接触过的产品领域，他给不出有建设性的意见，这个时候我才发现是做事上出了问题，本质是一个管理问题。

还有一次，业务负责人毫不掩饰指出我性格中存在的一些问题，我会去深刻的反思，尽管改正很难，但是我知道这是一个大问题，我必须要去改正，或者如果改不掉，也要在做重大的决策时回避这个性格弱点。

这也许就是成长烦恼，也是实践带给自己的重重一记耳光。引用前公司老领导说过的一句话，“未长夜痛哭者，不足以语人生”。

二、技术力和产品力

这一点这个专栏中很多人都已经写过，但在这里，我想分享几个我的认知。还是以前东家饿了么为例子，我将我在其中的三年分成三个时间段。

第一个时间段是 2015 年~2016 年，技术团队从几十人发展到 500 人左右。

这期间，我可以毫不客气的说，我们根本没有什么产品力，先把业务的需求干完就可以，这个阶段要做的就是招人，干活，团队速度扩张快，但是工程效率低下，P0 事故频繁发生，痛苦不堪。

第二个时间段是 2016 年~2017 年，技术团队从 500 扩张到 1000 人左右。

这个时候慢慢出现一个大的问题，招进来的人是多了，可是响应新产品的效率依然很低。因此，这时需要沉淀我们的中台、中间件、工程效率工具及技术影响力。

以技术影响力为例，饿了么第一个有影响力的项目是“多活”，严格意义上来说国内真正做到多活的不超过 10 家公司。在公司内部，为了沉淀技术力量，提升技术影响力，饿了么持续多次推动内部 Hackathon 比赛的举行，到 2017 年底，内部孵化的工具或者中间件就有 200 多个，还开源了更多的比如 Element 组件等等，这些都是非常生动证明。具体的细节，你可以搜索饿了么框架工具和 GitHub 上的开源项目。

其实光做到上面那些还不够，我依稀还记得，当时公司组织架构在过完年后做了一个大的调整，还招来了 2 位国际大牛，一位是 LinkedIn 背景，一位是 Facebook 背景，就是为了补上我们技术和产品视野的短板。

第三个时间段是 2017 年~2018 年，技术团队规模突破 1200+。

这个阶段产品还能做什么，什么才是这个阶段的产品力？广义来上来说，互联网产品一定是流量为王，留存为后，但是最终你的模式要成功，要么可以赚钱自己造血，要么可以成为别人的护城河或防御工具。

按上面的思路我们开始了双剑合并，选择加入阿里的怀抱，抽象一下，这其实是一个连接融合、过滤和筛选的过程，当然也是一个新的开始。

三、如何打造产品力

如何打造，其实想用文字表达很难。我思考万千，提炼一下就是内因和外因。

内因的核心就是按公司、按产品当时的场景和需求，判断出所处的阶段和面临的挑战，找出未来的方向，并以此为基准制定策略、落实执行方案。

举例来说，第二阶段的关键场景是，当时我们的业务订单量迅猛增长，从日 330w 单提升到日 500w+ 单，这种强大的外部压力迫使我们必须要在内部去寻求突破，我们制定了两条方案，一是沉淀饿了么的技术，打造出更稳定、更高效的系统；二是找到更牛的同伴加入我们，弥补我们的短板。

当然，这一切的根本是 CTO 给我们营造的技术环境。好的环境是能促使技术力、产品力发展壮大的土壤。

而到了第三阶段，这时候从内因方面考虑，我们的首要需求是要盈利，为了满足这个需求，就到了必须要通过一些外界的条件来改变现状的阶段。显而易见，利用其它流量大于饿了么本身流量的产品是一个出路，但这还不够，想达成更长久的持续就要进行品牌之间的合作、连接、融合。

总结

这篇文章，我和你分享了打造高效技术团队的另一个核心要素，做事。而要做好事，首先我们要要和业务的心在一起，团队必须要有一个共同的目标、可迭代的协作流程，以及统一的评价机制。其次，要打造技术团队的产品力，而这就要从从内因和外因两方面做分析，但其中真正能产生正向改变的是内因，想清楚自己想要的，剩下的就是寻找突破的方法或手段。

写到此刻，我抬头望向窗外，已经是凌晨 5 点 43 分的江城，点一只烟，猛吸一口，新的一天已经开始。

留一个思考题给你：你是如何打造技术团队产品力的呢？欢迎留言分享，我们一起探讨和学习，共同进步。

感谢你的收听，我们下期再见。

作者简介

程军，现任贝壳技术总监，曾任饿了么技术总监、1 号店架构师，10 年以上互联网开发经验，8 年以上技术管理经验。

第92讲 | 成敏：技术负责人如何做优先级决策

你好，我是技术领导力 300 讲的主编成敏，最近跟一些 CTO 交流，聊到技术负责人做决策的话题，颇有价值，想在这里分享给你。

在整个技术团队中，技术负责人经常要做的无非是两类决策，一类是优先级决策，一类是扩展性决策。

优先级决策

一个公司有业务团队、有产品团队、有运营团队，还有客服团队等等，这些团队都有自己的目标，站在他们的角度，他们会提出许多需求给到技术团队。到技术负责人手上，可能各种各样的需求、项目排期已经排到六个月甚至更久之后了，而其他团队还在不断的提需求过来。

在这种情况下，哪些事先做，哪些事后做，或者哪些事干脆是不用做的，就是技术负责人需要做的优先级决策。

那根据什么来做决策？肯定不是看谁的嗓门大，也不是看这个需求是来自谁，比方说 CEO。最终决定优先级的，是这件事情跟组织的目标到底有多大的关系，也就是优先级决策与组织目标直接关联。

其中，最核心的一个原则就是不做不该做的事情，这是提升效率最有效的方式。

交流中，有一个 CTO 当初是空降到现在的公司的，关于这个话题，他分享了一个他的例子：

我作为 CTO 刚加入公司的时候，公司每周都有一个项目排期会，产品经理和技术负责人会参加，确定接下来要做的事情。会上基本上就是产品经理之间互相争论，最后他们确定下做哪些事，然后技术负责人把这些事排到 to do list 里去，做出排期。

我参加两次之后就觉得这事不行，不能这么做，因为我发现，首先，这个排期表非常的长，长到每次都要滚好几页才能看完整个需求列表。其次，最老的一个 to do list，已经是一年以前的了。我就特别不能理解，既然这个功能这么久没做好像也没影响什么，那当初为什么还要做。

到第三个星期开会的时候，我就动手了，我对参会的产品经理说：“你们提需求可以，提什么都可以，我们作为技术团队，支持你们是天经地义的。但是，你们能不能不光提要求，也给我一个做这件事情的理由，或者这件事情做成能达成的结果。”

所以，我就提了个要求，所有的产品经理在提需求之前要先回答我三个问题：第一个问题，为什么要做？第二个问题，做了之后会带来什么好处？第三个问题，这个好处在最终的数据上怎么体现出来。

如果这三个问题你都回答了，那我们技术团队二话不说赶紧做，加班加点的帮你做。结果，整整一个月都没有人提新需求。

回到今天的主题，怎么判断什么是不该做的事情呢？ 其实可以归纳为三点。

第一，要求马上开始，却没有明确可度量的目标与交付时间的事情，先不要做。 比如 CEO 突然找到你说，有件事情我们必须得马上开始干。那什么时候要结果呢？说是越快越好。那要做到什么程度呢？说是越完善越好。那这件事你就可以拒绝掉，先不做了，等具体的目标、预期出来之后再做。

第二，丝丝入扣、设计完美的大系统，先不要做，特别是如果还要花费很长时间才能出结果的话，那就直接拒绝掉，这种事情一定不值得做。技术人都有想造轮子的冲动，不管是自己去直接造轮子也好，还是推翻别人的东西，全都重构也好，技术人都会有这种冲动，这并不奇怪。

之前跟一个读者聊天，他现在的工作是在一个大公司里面维护老代码，就跟我抱怨说，每次维护老代码都是一边改一边骂，最想做的就是把它推翻掉，全部重写一遍。

但从另一个角度看，所有的代码在最开始的时候，其实都没有那么糟糕，它们是在演进的过程中逐渐变糟糕的。就算你新造了个轮子，解决的也不过是现在或未来一段时间内的问题而已，随着业务的发展、系统的演进，一样会变得糟糕。

第三，要克制精益求精的冲动。 这也是技术团队普遍都有的一种冲动，总想把事情做到最好、最完美。但任何东西，只要有时间、有资源，就总有优化的空间。所以技术团队或多或少都会有这样的想法，你再给我点时间、再给我点资源，我能把它做得更好。

但是这种“更好”是不是当前技术团队乃至公司需要的，资源是不是要放在这件事情上，是技术负责人需要衡量，并做出决策的。

扩展性决策

作为技术负责人，除了要做优先级决策之外，还要做扩展性决策。很多公司在发展过程中都会遇到这样的问题，目前的团队在现阶段是合适的，所选择的技术架构在现阶段是合适的，但一段时间之后，他就不再合适了，怎么办？

所以，技术负责人很重要的能力就是管理扩展性，换句话说，你要对你业务未来的发展有一个大概的预计，然后在组织架构、人员构成、技术架构等方向为业务保留足够的扩展性。

1. 组织的扩展性，比如要不要独立出一个公共的技术部门，负责公司基础设施的搭建；比如要不要搭建一个研究型的团队，专门负责创新相关的研究；比如要不要把组织架构从功能型的重组为矩阵式的等等。

2. 人员的扩展性，这个其实可以归结为到底要招些什么样的人进来。需要考虑的是，现在的人才储备是不是最合适的，未来一段时间内，团队技术上会不会有大的调整，公司业务上会不会有新的发展。比如，如果公司想要拓展人工智能相关的业务，那技术团队就要先招一些人工智能、大数据领域的人才，做好储备，这些都会涉及到扩展性。

3. 技术的扩展性，现有的技术架构能不能支撑公司业务未来的发展，如果不能，应该做哪些事情来补充，比如是引入新技术，是升级架构，还是干脆重构系统等，都需要技术负责人提前做好决策。

而做扩展性的决策的关键，依旧是看这件事情与组织目标之间的关联性，与优先级决策一样。因此，技术负责人一定要对业务、对业务未来的发展有足够的理解和认知。其实，这不仅是对技术负责人的要求，任何一个有想法的工程师，都应该这样要求自己。

小结

本文探讨了技术负责人经常要做的两类决策，优先级决策和扩展性决策。而这两类决策的关键都与组织目标有直接的关联，因此，技术负责人一定要了解公司的业务，清楚公司的目标，并将其拆解为技术团队的目标。

最后，当你面临决策难题的时候，不妨先问自己几个问题：我要解决的问题到底是什么？我的团队在组织里的作用和价值到底是什么？这些价值需要用哪些方式来更好的达成？

你在工作中是怎么管理优先级的呢？欢迎在留言区分享给大家。

感谢你的收听，我们下期再见！

第93讲 | 兰军：团队研发效率低下的要因分析

你好，我是梅沙科技创始人兰军（Blues），今天想跟大家分享提升互联网产品团队研发效率的一些实践。

研发效率未达预期是很多团队都会遇到的问题，项目延期的情况也并不少见。其原因也是多种多样，可能是因为遇到某个技术难题解决不了，可能是因为需求发生了变更，可能是因为设计提出了修改方案等等，表面上总有各种各样的突发情况导致延期。

那延期之后要不要追责呢？一个问题留给大家。然而不论是否追责，这并不能从根本上解决研发效率太慢的问题，我们需要找出更深层原因，总结经验与教训，避免再踩入同样的坑。

这里分享一个我从腾讯学到的分析方法：冰山模型的要因分析法。

如图中所示，研发效率未达预期只是冰山露出水面的部分，只是表象，在水面之下，存在着各种各样的问题，是真正的诱因。

我们可以粗略的将其分成三类：一是近因，即表面原因；二是过渡因，即深度迷惑我们的原因；三是远因，即改善后能从根本解决问题的原因。

1. 头脑风暴找原因

所有这些原因都是从实践过程中不断发现、总结而来的，所以我会组织产品、技术、设计等所有相关人员进行头脑风暴，来找出研发效率低下的各种原因。做产品需求的时候头脑风暴，查找原因的时候，自然也可以用头脑风暴。

问题头脑风暴的关键是尽可能多的列举，不要反驳，把所有能想到的问题都列下来。最后，我们列出了各种各样的原因，包括需求评审不到位、执行态度问题、执行能力问题、主动性不足、考核制度不完善、沟通不到位、不理解整体规划、招聘问题等等，涉及到方方面面。

2. 因果分析与评分

仅仅找出原因还不够，为了解决研发效率过低的问题，我们还需要对这些问题进行分析与评分，找出其中的关键点。

如图中所示，我将总结出的所有原因列成表格，分别在横向与纵向一一列举，再两两比较，进行打分，是“因”记 -1 分，是果记 +1 分。举个例子，A 和 B 相比较，如果 B 是 A 的因，那么 B 得 -1 分，A 得 +1 分，反之亦然。如果两者互不为因果关系就记 0 分。

然后在表格最右一列对每一行的分数进行求和，得出每个原因所得的分数，并进行排序。按照之前的设定，是“因”记 -1 分，是果记 +1 分，所以可以看出分数越高，越代表这个原因是近因，只是表象；分数越低，越代表它是远因，更深层的原因，一旦改善能从根本解决问题。

举个例子，我的表格中，得分最高的原因是“需求更改过多”，有 8 分，得分最低的是“导师指导不到位”，有 -11 分，显然前者只是一个表面原因，而后者是更深层的根本原因。

那怎么判断其他原因到底处在哪个水平呢？我们可以把最高分和最低分分别除以 2，得到的数字就是近因和过渡因，以及过渡因和远因之间的分界线。还是以我的团队为例，最高分 8 除以 2 等于 4，最低分 -11 除以 2 等于 -5.5，那么得分大于 4 的原因就是近因，得分小于 -5.5 的就是远因，而处于两者之间的就是过渡因。

在用这种方法进行分析归纳之后，我们团队研发效率未达预期的近因包括：需求更改过多、产品架构能力不足、项目管理能力不足、项目推进意识不足、不清楚整体规划、交互能力不足、执行力不足、版本发布拖延等。

过渡原因包括：版本计划周期过长、需求分析能力不足、合作分工不明确、目标路径不清晰、全局意识、没有方法、负面情绪、主动性不足、对项目理解不足等。

而远因包括：招聘问题、专业培训不足、导师指导不到位等。可以看到，远因基本上都和领导者相关，很多时候，老板就是公司的天花板。

另外，因为问题特别多，很多都没有逻辑性，所以需要找到它们共性的地方，并对其进行分类，大体上可以分为组织与制度问题、能力问题、沟通问题、招聘与解聘问题这四大类。然后在实际操作中，我们可以针对这四大类问题采取相应的解决措施。

3. 研发流程梳理

以组织与制度问题中的研发流程为例，各个公司研发流程的整体步骤其实并没有太大区别，无非是先提需求，然后需求评审，评审通过后出设计方案和技术方案，接着是开发，开发之后是验收，包括产品验收和设计验收，待验收完，再开发提测。如果一切顺利，就可以进入发布环节，而在正式发布之前还有灰度发布，最终才正式发布，大体如此。

我们也是按照这套流程做事，但细究之下，发现在实际执行中会遇到很多问题。目前，我们在使用的是腾讯的研发管理平台 TAPD，它的默认流程没有问题，只是还不够细致。于是，我们对它进行了梳理，梳理之后发现中间的很多环节都可以进一步细化，以符合自己的研发流程需要。

举个例子，光是需求一项，我们就梳理出了 21 种状态，包括：新需求状态、挂起状态、规划中状态、已规划状态、需求评审状态、已拒绝状态、设计资源分配状态、开发资源分配状态、需求讲解状态、技术方案评审状态、UI 设计状态、UI 稿评审状态、开发中状态、需求变更状态、UI 验收状态、产品功能验收状态、开发提测状态、测试状态、产品发布状态、外网验证状态、已实现状态等。TAPD 里面没有那么全，很多步骤都是我们自己定义的。

定义完详细流程之后，需要进行流程的跳转，而流程跳转也是在这 21 个状态之间进行，非常复杂，所以我们需要确定每一个流程能跳到哪几个流程，每个流程的负责人是谁，下一步它能够进行怎样的跳转等等，把所有的环节都梳理清楚并明确负责人。

这样梳理下来之后，整个流程图会很长、很繁杂，但对提升团队研发效率的效果非常明显。最初，没有细化流程图，也没有按照流程图做事的时候，遇到问题后，团队成员就会比较迷茫，不知道问题出在哪儿，也不确定该如何解决，甚至搞不清楚下一步的做法。

当然，在总结、细化出这个流程图之后，我在团队中进行了很多探讨和培训，让他们能真正清楚这个流程，并约定好每一步的评审人员和把关人员，确保遇到问题时能够及时处理。

小结

研发效率未达预期是很多管理者都会头疼的问题，本文分析了这一问题背后的诸多原因，包括需求评审不到位、执行态度问题、执行能力问题、主动性不足、沟通不到位等，并通过冰山模型的要因分析法，将这些原因分为近因、过度因和远因三大类。

同时，通过提炼共性，将这些原因分成了组织与制度问题、能力问题、沟通问题、招聘与解聘问题这四大类。在实际操作中，可以有针对性的从这四个方面采取相应的解决措施。

本文还分享了改善组织与制度问题中，梅沙科技在研发流程梳理方面的实践，包括细化需求状态、定义详细的流程和流程跳转图，确定每个环节的把关人等，将细节掌控做到位。这样，即使出现问题，也能及时定位，快速解决。

接下来，我还将分享为提升研发效率，我们在能力问题、沟通问题、招聘与解聘问题等方面的实践，欢迎继续关注。

作者简介

兰军（BLUES）：梅沙科技创始人，致力于教育 + 互联网行业产品打造，原迅雷产品总监，腾讯、YY 语音高级产品经理，公众号 ID：bluemidou，已经写了 600 多篇原创文章，欢迎交流。

（本文整理自兰军在 ArchSummit 全球架构师峰会上的分享，有删减。）

第94讲 | 兰军：提升产品团队研发效率的实践（上）

你好，我是梅沙科技创始人兰军（Blues），上一篇文章中，我们分析了研发效率未达预期这一问题背后的诸多原因，并将这些原因分成了组织与制度问题、能力问题、沟通问题、招聘与解聘问题这四大类。

今天，我想结合梅沙科技的实践，跟大家分享改善能力问题和沟通问题的一些解决方案。

1. 沟通公开透明

我们有着非常透明的内部沟通机制，每个人都能看到其他人的工作目标、工作进度周报等。

跟大部分团队一样，我们每天进行晨会沟通，定期有周会和月会。一般晨会是早上九点半，如果遇到周二，晨会就变成周会，如果是每个月第一周的周二，就变成月会。相当于晨会周会月会都固定在早上九点半，只是不同的时间点开不同的会议。

晨会中，我们主要看迭代表。如图中所示，迭代表中包含需求、迭代、任务、缺陷等内容。如果某个项目的迭代一切正常，就可以跳过它。如果出现问题，我们就会把这个迭代公开投影在会议室墙上，团队一起分析问题、解决问题。

周会主要看周报，周报有四个模块，分别是本周工作小结、下周工作计划、每周关键数据，以及问题反思和经验沉淀。其中最关键的是每周关键数据这一项，团队中的每个成员都需要提炼出他所负责项目的数据，并在周报中公开分享给大家。周报的提交频率是每周一次，这是一个连续性的过程，有利于形成团队成员的自主管理。

我们的周报是完全公开的，每个人都可以看到公司其他人的周报，所以每个人的工作都是透明的，遇到问题会有团队中的成员给出解决建议，同时，周报中所沉淀的经验也可以被其他人借鉴和吸收。

2. 内部数据透明

其实，我现在已经不太管具体的产品和开发方面的工作了，但是我会关注两张表，一张是产品前端表，一张是产品后端表，从中可以看出产品的流畅程度与稳定系数。

通常，在前端数据中，我会看页面的访问量，以及页面加载速度这两个关键数据，它们可以反馈出前端开发的质量，甚至技术实力。

在后端数据中，我一般看后端接口的调用速度，比如，每天调用接口的次数、接口调用的反馈时长，接口调用的平均耗时、访问次数等等。如果访问次数很高，但调用速度慢，其中必然存在问题。如果接口特别多，但很多接口都没人访问，也会有问题，具体还需要根据产品设计来判别。

所有的这些数据在内部也是透明的，不止是我，其他团队成员都能查看。

3. 能力提升培训

上一篇文章中提到，专业培训不足是导致研发效率未达预期的远因之一，既然如此，我们就要在平时加强员工各方面的培训。

在梅沙科技，我们非常注重员工的能力提升，在我看来，提升人员能力也是提升团队效率的一种方法，它能有效改善部门之间的沟通问题，减少矛盾。

举个例子，产品经理经常会问开发人员“某功能能不能做”这类问题。长期以往，开发人员也会感到烦躁，所以我的解决方式就是让他们互相培训，互相学习。也就是开发同学有责任去培训产品经理，帮助他提升技术水平和素养，让他自己去判断某个功能能不能做，以此提升工作中的沟通效率。

我们公司的培训方式有两种，一种是内部培训，一种是外部培训，内部培训又分为互相培训和学习分享。

首先，互相培训是各小组之间的经验教授与课程分享，比如，产品经理可以给设计同学和开发同学讲产品课，分享产品思维，讲产品设计。设计同学给产品经理和开发同学讲交互、讲 UI。开发或测试同学就给产品经理和设计同学讲技术。彼此互相教授方法，互相学习，以此提高部门间的沟通效率，进而提升工作效率。

举个例子，很多产品经理可能并不了解什么是状态机，这时，他与开发人员沟通时就会存在障碍，如果开发人员能培训他，让他了解这个概念，之后的沟通中再遇到此类技术术语时就不会出现问题了。

再举个例子，在沟通产品的设计时，我们经常看产品经理对设计师说，“这个图标再放大一点，这里的字号再大一点，整体感觉要高大上”。其实，这些都是非常个人的观点，并不专业。所以设计师需要培训产品经理，让他们从专业一些的角度来评判一个设计作品，比如从颜色这个维度，设计师要让产品经理了解什么是对比色、什么是临近色等，并给出设计规范。这个规范就像品控手册一样，能够得到团队成员的赞同，并且不断完善。

另一种互相提升的方式是阅读分享。我会要求团队成员，每个人每年至少读完三本书。读完之后还要将读后感制作成 PPT，在晨会结束时进行分享。按照团队成员为 60 人来计算，团队每年的阅读书目就至少有 180 本，能够产生 180 次读书分享。如果在读书分享结束后，团队其他成员对这本书感兴趣，他们可以自己继续深入阅读。

可以说，团队中的内部学习与分享对于员工提升自我是非常便捷、有效的，对于提升团队能力也是非常行之有效的办法。

除了内部学习、外部学习外，项目的复盘也特别的关键。我讲一个曾经的案例，最开始，我们公司当时的产品经理做了一个注册登录流程的流程图，结果开发拿到手之后，觉得画的并不好，其中存在诸多问题，甚至有些地方并不符合流程图的规范。

所以，开发人员联合产品经理，对流程图进行了一系列的更改、试验，再进行沉淀、复盘，最终产出规范的登录注册流程图。

后来，这张登录注册流程图还成为了我们公司面试产品经理的参考标准，我会让面试的产品经理动手画一张流程图，从起始框开始，一直到判断框、结束框，以及流程线路等。毕竟对于产品经理来讲，掌握登录注册流程是最基本的能力。

我也遇到过很多产品经理表示自己是野路子，不了解规范的的流程。但是，这并不能成为一个很好的规避理由，因为很多人都是野路子，没有系统学习过，大学里也没有产品经理专业。很多产品经理都是计算机专业出身，经验与知识都是从实践中不断获取，并逐渐积累而来的。

一个人只有不断提升自我才能越来越优秀，同样，一名员工只有不断进步与成长才能不被淘汰。在此，我分享一段《权力的游戏》中经典台词：“混乱不是深渊，混乱是阶梯。很多人想往上爬，却失败了，且永无机会再试。他们坠落而亡，有人本有机会攀爬，但他们拒绝了。他们守着王国不放，守着诸神，守着爱情，尽皆幻想。唯有阶梯真实存在，攀爬才是生活的全部。”

且不论翻译效果如何，我想表达的是，在现实生活中，“攀爬”一词可能过于功利，我认为成长才是全部。所以，我们需要不断成长，并帮助团队中的伙伴一起成长，当自身能力提升之后，做事情的效率自然会提升。

小结

本文分享了改善团队沟通问题，提高团队成员能力的一些解决方案。在沟通问题上，最关键的就是公开透明和信息共享，这样能让团队成员了解彼此的进度，共享彼此的经验，同时也能有效减少沟通时的隔阂。

另外，我们可以从不同团队间的互相培训和学习分享出发，再加上阅读、复盘等一系列手段来不断提升团队成员的能力，以此提升整个团队的能力，并提高部门间的沟通效率。

如果你对团队能力提升培训有自己的见解，欢迎在留言区分享。

作者简介

兰军（BLUES）：梅沙科技创始人，致力于教育 + 互联网行业产品打造，原迅雷产品总监，腾讯、YY 语音高级产品经理，公众号 ID：bluemidou，已经写了 600 多篇原创文章，欢迎交流。

（本文整理自兰军在 ArchSummit 全球架构师峰会上的分享，有删减。）

第95讲 | 兰军：提升产品团队研发效率的实践（下）

你好，我是梅沙科技创始人兰军（Blues），前两期的文章中，我们分析了研发效率未达预期这一问题背后的诸多原因，将这些原因归纳总结后，可以分为组织与制度问题、能力问题、沟通问题、招聘与解聘问题这四大类。

其中，优化组织与制度问题、提升能力与沟通问题等方面，我在之前的文章中已经分享了梅沙科技的实践。今天，我想分享的是如何通过招聘与解聘来提升团队的研发效率。

招聘

我招聘团队人才时有三个原则，一是招聘标准，二是跨岗位面试，三是如果犹豫，就不录用。

1. 招聘标准

首先我会制定一个招聘标准和招聘流程，招聘流程共有五步，分别是专业初试、专业复试、跨岗位复试、合伙人面试以及 HR 谈薪酬的终试。招聘标准的话，我一般会从专业知识、专业技能、激情、开放、用户意识、好学、正直、实干、愿意适配这九个方面来评估候选人。

首先是候选人的专业知识与专业技能，这是硬性条件，没什么好说的。

其次，考虑面试者是否有激情，是否开放。我认为拥有开放心态特别重要，举个例子，即使招进来新员工的能力不是很强，但如果他的心态相对开放的话，他可以接纳别人给他的建议和意见，能够通过学习快速提升自己。如果新员工没有开放心态，就算他能力还 OK，但是他无法听取、接纳别人提出的建议，就很难成长，很难融入一个团队。所以，我对开放特别看重。

再者，我也非常重视新员工的用户意识与好学、正直、实干、愿意适配等几种素养。我会在面试过程中抛出几个问题，让面试者给出答案或解决方案，通过面试者的表现来考察他各方面的素养。

比如在面试产品经理时，我通常会问他最常用、最熟悉的 APP 或产品是什么？能否讲一讲该产品特性、功能或者一些设计方面的亮点。通常面试者都能说出一到两款产品，如果他连这个都答不上来，那就基本不用再聊下去了。

如果他回答了，那么接下来给他几分钟时间，画出他所讲产品的草图。比方说他喜欢音乐，最常用的一款产品是网易云音乐，那么，让他画出网易云音乐的草图，包括顶部设计、中间菜单、列表、底菜单等等。

这并不是什么难事，如果网易云音乐的界面过于复杂，那么至少微信是我们最常用的一款产品，可以给面试者两分钟时间，让他回忆微信的某个页面，并将这个页面画成草图。

事实证明，有些产品经理确实不记得微信页面下方四个底菜单的名称和外观。所以，这就考验了产品经理是否会对常用的产品有所关注，如果他连最常用的一款产品的功能都张口结舌，那面试结果必然是否定的。

2. 跨岗位面试

在面试中，我认为跨岗位面试也非常重要。在我们公司，招聘产品经理时，会有开发人员去面试，特别在初期团队人少时，进来一个产品经理，前端、后端的技术人员都要去面试他，如果面试结果大家都满意，就录用。

结果，入职了很多女性产品经理。事实证明，女性产品经理确实与开发人员的沟通比较顺畅，项目推动的结果也非常理想。当然，也有优秀的男性产品经理，只是各自擅长的方面不同。

同样，我们招聘开发经理时，也需要产品经理去面试。后面如果产品经理对这个开发人员有意见了，我就能开个玩笑怼回去说，这是你面的、你招进来的，现在怎么对他有意见了。

这样双方跨岗位面试，有利于提升团队成员之间的沟通效率，从而提升团队整体的工作效率。

另外，在面试过程中，一旦我对这个面试者产生犹豫，我就就立刻说 NO，直接否定，要相信自己的直觉。

3. 新员工三个月规划

新员工入职后，我们会为他制定一个为期三个月的培训计划，让他能够快速融入团队，快速适应新工作。

每个新员工都有一名指定导师，导师的期限也是三个月。导师会先为新人制定一个目标，然后在三个月之内帮助新人快速成长，努力达成目标。导师还会带领新员工熟练 SMART 原则，帮助他提升达成目标的效率以及质量。

新人进来，我们会要求他每天都发日报，这样我们能清楚地了解他每天的工作与进步，另外，导师需要实时关注，告诉他每天该做的事情，这样，他也能对自己在做的事情心中有数。

如果是产品经理入职，我们会要求他在三个月之内上线一个产品功能，或者是某个页面改版，并提交一份具体的数据分析。不管多小的功能，一定要上线，这样才能走通内部整个流程。

在三个月期限到达后，我们会根据目标的完成度来评估新员工是否适合团队。

在三个月期限中，除了考察新员工的专业技能素养，还需要观察新员工的自身素养。比如，是否有责任心，遇到难题会不会主动承担；是否有嫉妒心理；是否自我感觉良好；是否情绪起伏过大；是否拒绝改变；是否总会迟到等等。如果发现新员工与团队不太适合，我会果断解除试用，这样的结果更加有利于双方的成长。

解聘

在我看来，解聘要果断，这对于团队的战斗力有益无害。通常，团队中某个岗位的员工不达标，但由于缺人或短时间内招不到合适的人才，很多管理者不会解聘该员工，会留着他继续干活。但我的做法恰恰相反，我会果断解聘该员工，留下的工作会临时交付给它的上级，或者直接由我承担。

因为留着一个不合适的员工，既影响团队氛围，又影响团队战斗力，对于该员工也是一种不负责任。

如图中所示，在团队中，假设每个人的能力均等，那么，平均战斗力就是 1，如果有人能力提升，团队战斗力也会随之快速提升，一旦有人能力不足，团队战斗力也会相应降低。

从图中团队 D 和团队 E 的战斗力数据来看，其他 7 位成员的战斗力数据都一样，只有一位成员的数据从 1 变成了 0.6，结果，E 团队的战斗力直接降低了近一半，由此可见能力不达标员工的负面影响之大。

所以，遇到不合适的成员，要果断解聘。这也是有些团队设置末位淘汰制度的原因，这样留下的成员战斗力会更强。

另外，解聘也是对员工的一种培养，有助于他更好地成长。如果他有问题，你可以给他一次机会来提升自己，一次机会足矣，做不到，就果断解聘。千万不要给两次机会，因为一次机会改不了，给两次机会也是白搭。

被解聘之后，他反而可能会获得更好的成长。尤其是对现在的年轻人而言，可能他们的生活压力比较小，自我独立意识比较强，比较崇尚自由，用负面一点的词的话就是比较自由散漫，不太注重团队意识。所以，经历一些挫折与痛苦，能够让他获得更多的成长与经验积累。在我看来，痛苦加反思，才能够进步。

值得注意的是，我所分享的内容都只是一种方法，而非标准答案，具体方法还需要根据你团队的实际情况来分析调整。

小结

本文主要分享了如何从招聘与解聘两个方面出发，来提升团队的研发效率。在招聘层面，我分享了三个原则，一是制定符合团队情况的招聘标准，二是不同部门跨岗位面试，三是如果犹豫，就不录用。而在解聘层面，一旦发现员工不合格或不合适，就要果断解聘，这样即有利于团队战斗力的提升，也有利与对方的成长。

最后，我特别推荐一本书，书名为《非暴力沟通》，我在公司内部也做过这本书的分享，书中所讲的沟通方法对于提升整个团队的效率与战斗力非常有用。

如果你读过这本书，或是对招聘与解聘有自己的实践，欢迎留言分享。

作者简介

兰军（BLUES）：梅沙科技创始人，致力于教育 + 互联网行业产品打造，原迅雷产品总监，腾讯、YY 语音高级产品经理，公众号 ID：bluemidou，已经写了 600 多篇原创文章，欢迎交流。

（本文整理自兰军在 ArchSummit 全球架构师峰会上的分享，有删减。）

第96讲 | 阿禅：工程师转型产品经理可能踩到的“坑”

你好，我是轻芒合伙人阿禅，“可能吧”创始人，也是一名连续创业者，之前做过科技媒体、做过智能音箱，做过很多事，踩过许多坑。今天想跟你分享的话题是“工程师转型产品经理可能会遇到的几个坑”。

之所以称之为“坑”，而不是“问题”，是因为我自己并没有真正做过工程师，而是接触过很多工程师，也有很多工程师转型产品经理的朋友，我将所有的问题与经验总结起来，并分享给你，希望对你有用。

工程思维与产品思维

首先以手机摄像头为例，来说说工程思维与产品思维的差异。假设我们要做一款手机摄像头，从工程思维的角度，我们可能会考虑，如何提高摄像头的分辨率；如何提高弱光下的快门速度；如何进行 ISO 调整；如何优化人像识别功能；如何使闪光灯更智能等等。

从产品思维的角度，我们可能会更多的考虑拍照场景、美颜效果等等，比如如何拍出来就显五官立体、肤色嫩白；如何做到自动美颜并可以立即分享朋友圈；如何从众多照片中自动选取最美的一张等等。

我与很多工程师朋友的理解是，工程思维更关注效率、如何实现，也就是“How”；而产品思维更关注“场景”，以及用户的内心需求，也就是“Why”。

在具体的产品开发中，产品思维和工程思维都很重要，需要将两者结合起来。产品思维需要工程的配合与支撑，将“场景”落实到产品开发。比如，产品经理想做一款夜间拍摄效果更好的手机摄像头，那么就要做到既保证人像清晰，又保证背景明亮，这时就需要工程师们在技术上做相应的提升、优化，比如前景快门锁定、快门拉长等。

工程师转型产品经理可能遇到哪些坑

在这次分享前，我跟几位从工程师转型做产品经理的朋友聊了聊，从中摘取了四条较为典型的吐槽。

视角变了，原先追求完美和逻辑性，现在是怎么快速实现目标怎么来。

很多时候，用户视角的简单性与工程思维的完美性有冲突。

转型这一年，踩过的坑无数，包括产品战略层面、沟通层面、团队管理层面、执行层面，满眼都是坑。

以前不用做这些，现在要做很多公司内部的东西，比如对上沟通，然而老板永远不懂我；对下沟通，光打鸡血远远不够；还有跟兄弟团队和部门之间因为资源不足产生的博弈等。

对此，我稍稍总结了一下，总结出了工程师转型产品经理时，可能会踩进去的 7 个坑。

1. 认为用户傻

我明明设计了一个很聪明的按钮，用户就是不用，非要用那个复杂的方法来使用我的产品。

举个例子，假设产品经理设计了一个开关，用户只需向上一推就可以把灯打开，比原来向下按的方式更为省时省力。结果发现用户并不买账，可能 99% 的用户还是用向下按的方式去开灯。尽管这样会稍微费力一点，但用户已经习惯了这样的行为方式。

对于这类情况，很多产品经理容易陷入一个误区：既然有更加方便的产品使用方式，用户就该放弃原有的方式，去使用新方式。但是，他们忽略了用户习惯较难改变的事实。

2. 觉得同事傻

那帮运营和市场老给我提不靠谱的需求，一点都不懂技术和产品，瞎指挥。

这是我曾经陷入的误区之一，以前我在一家公司做客户端，很多时候，市场和销售的人在与客户聊天之后，就会找我提需求，比如在某个位置加个广告位。在当时的我看来，这完全是他们在瞎指挥。

后来，我反思当时的做法，认为应该从两方面思考这件事。第一个方面，当同事提需求时，这个需求可能已经变质，不再是客户的原始需求了。作为产品经理，应该去了解客户最原始的需求。

第二个方面，应该考虑同事提出这个需求想达成的目的，比如他的目的可能并不是为了加一个广告位，而是为了借此达成盈利目标，那我们其实可以通过其他方式帮助他实现目标。

因此，当同事提需求时，我们应该把他和普通用户放在同一层面，尽管提的是一些所谓的“傻”需求，我们也要花费时间与精力去认真分析这些“傻”需求背后的动因，以及如何才能帮助他们解决问题、实现需求。

3. 觉得同事还是傻

明明那么简单的道理和逻辑，这帮同事怎么就不理解呢?

这个问题其实出在沟通层面，然而，产品经理很重要的职责是沟通, 很多时候, 沟通是做成一件事的关键。

之前有个产品经理跟我分享，他做工程师时不擅长沟通，也不想沟通。在他看来，这些事情都很简单，为什么还要花时间给别人解释。这是他后来转型做产品经理时很难跨过的一道鸿沟。

在公司中，不同职位与不同资历的人，彼此的认知都不同，而作为产品经理，需要团结团队里的每一个人，让大家朝着同一个目标努力。那么，你就必须跟所有人解释，某件事的重要性，某个功能为什么存在，某件事为什么要那么做等等。而且，因为认知的差别，你与每个人的沟通方式也要有差别，找到合适的沟通方式才能获得对方支持。

可以说，提升沟通能力是工程师转型产品经理的必经之路。

4. 容易在前端呈现过多技术

我给用户做了一个特别炫酷的功能，用户可以自定义各种参数，但似乎他们并不怎么用。

其实，许多做产品的书籍、课程都会写到，不给用户选择，反而是最好的选择。举个例子，前段时间小程序黑咔相机特别火，日活量最高时可达千万。它的功能特别简单，就是给照片中天空提供各种动态效果，比如用户选择梵高星空，它就能将图片中的天空变幻为动态的梵高星空效果，然后一键保存、分享，操作非常简单，过程中没有任何需要技术的地方存在。

这个产品的用户平均年龄大概 50 岁，最早在某个摄影群中爆发，由于操作简单，效果有趣，迅速被群成员分享，一天时间内由日活 30 多万，迅速上涨至几百万，第二天再增长至一千万，是一个特别经典的例子。

5. 过于追求完美，害怕返工

用这个方法来实现产品方案太笨了，对服务器的开销太大，我们应该重写代码，用另一种方案。
为了应对未来可能存在的需求改动，我要把能在后端定制的功能都写了 API，并且把功能拆成各种层级。

许多创业公司在开发产品前会将计划思考周到，以防未来可能出现的需求改动，比如将各种 API 补全、把框架都搭好等等。但在实际开发过程中，我们还需考虑阶段性问题，如产品当前处在什么阶段，是否应该在当前寻求最完美的实现方案；如果处在 MVP 阶段，是否应该允许回炉重做等等。

我们应该允许一些不影响主功能的 Bug 存在，先让功能运行，再补全不完美的地方。有许多工程师害怕返工，觉得按照产品经理的需求去做时，会不断出现新的需求，就需要不断地返工进行完善。然而对产品经理来讲，他需要根据每个阶段的数据变动，去观察市场反馈，从而迅速做出调整。所以，我们应该放下害怕返工的心态，接受随时推翻重做的可能性。

6. 认为功能大于场景

我们有 A 功能、有 B 功能、有 C 功能……我们有非常多的功能，都是我们自己的技术实现的。

产品经理经常犯一个错，就是总觉得应该再多开发一些功能给用户使用，让他们的体验更丰富。然而，我研究了许多小程序的方法论，发现小程序之所以火爆，除了自身裂变属性较强外，非常重要的一点是，它只满足用户一个功能的需求。你可以看到，很多拥有多合一功能的小程序，很难火起来，因为功能增多之后，会模糊用户对这个小程序的认知。

7. 忽视运营

酒香不怕巷子深，好的产品，用户自然回来，首先要做好的是产品，运营和营销并不重要。

其实不然，产品与运营始终不可分割，产品经理一定要与运营人员密切沟通，甚至做到产品经理即运营本身。

最近几年，很多成功的产品，其成功的原因中运营占得比重甚至大过了产品本身。以小程序为例，很多小程序的功能比较容易实现，技术门槛并不高，别人也可以快速复制，关键点反而在于如何做用户增长。

对此，我们的做法是采用 AB 测试，反复测试，总结结果，在这个过程中，产品经理需要跟运营不断沟通，共同摸索出最优结果。

并且很多时候，产品经理还需要身兼多重角色，我有一位朋友是做电商产品经理，他每天除了做 AB 测试，测试各种按纽，优化各种流程之外，还会涉及对文案细节的改动，某次他改动了一句广告语，结果下单率提高了 9%。

可以看出，产品经理做测试、运营、文案等细节工作，看似与技术没有太大关系，却是产品获得成功必不可少的一部分。

小结

本文总结出工程师转型产品经理时可能会踩到的 7 个坑，包括认为用户傻、觉得同事傻、在前端呈现过多技术、过于追求完美、害怕返工、认为功能大于场景、忽视运营等，值得大家借鉴。你曾经踩过其中的哪个坑呢？欢迎在留言区分享你的踩坑经历！

作者简介

阿禅，连续创业者，资深微信产品与运营研究者。创办中文原创博客可能吧，轻单创始人、有可能学院 CEO、极客公园前 CEO、出门问问产品总监，目前担任轻芒合伙人。

（本文整理自阿禅在 ArchSummit 全球架构师峰会上的分享，有删减。）

第97讲 | 阿禅：工程师转型产品经理的必备思维

你好，我是轻芒合伙人阿禅，在上期《工程师转型产品经理可能会遇到的“坑”》一文中，我根据自己与朋友转型做产品经理的经历，总结出七个最容易踩的坑。今天，想继续跟大家分享工程师转型产品经理必须要掌握的八个思维与能力。

实际上，即使不是工程师转型，这些思维也需要学习。还记得我第一次学做产品经理的时候，因为是野路子出身，没有经验，不知道文档怎么写，就找了一个网易的朋友请教，他给我发了一个 300 页的文档参考。当时我震惊了，产品经理要做这么多东西么？后来，我自己去做产品时才发现，写文档并不是一个产品经理最核心的技能，他需要具备的能力有以下几点。

1. 好奇心

关注一切你喜欢和不喜欢的产品，思考场景与为什么。在招聘产品经理的时候，我经常问对方一个问题：在不看手机的情况下，分别说出微信做的好与不好的三个功能，说明理由，并反推此功能为什么要这样设计。

我并不关心面试者的观点是对是错，我的关注点是他有没有细心观察这个他每天使用最频繁的产品；有没有去思考其中的功能为什么要这么做，为什么不按照他所认为的更好的方案去做。

产品经理需要有好奇心，要经常花时间与精力去研究常用产品或对手产品，只要一款产品出现在眼前，不管喜欢还是不喜欢，都应该用职业敏锐性去研究、分析它，凡事多问问为什么。

比如看抖音，并不是看完一个点赞量上百万的小视频，认为不错，感到开心，就接着刷下一条。这不是一名合格的产品经理该有的生活状态，而是要研究上百万的点赞量背后的原因，去看看主播是谁，他以往的视频点击量是高是低，视频属于哪一种类型，再试试总结哪个类型的抖音视频比较火等等。

2. 同理心

将自己当成核心用户，并从的他们需求角度思考产品需要解决的问题。当你认为用户“傻”的时候，不要急着否定他们，而是要以同理心去思考他们的需求。

我之前做过一个的练习，当时，我特别不理解拼多多，为什么一个二十几块钱的伟哥能卖四百多万份，成了当时拼多多销量最好的单品，这让我非常震惊。然后我去分析拼多多的用户群体，也混进了很多中老年群。结果发现，中老年人真的很闲，每天都会在群里聊天，而且群是他们很有安全感的一个舒适区，他们乐意在舒适区中表达观点，也非常乐意将自己认为优惠的产品分享到这样熟悉的圈子中。而且他们不止是分享产品，而是会把产品链接直接发到群里，还会直接 @几个人，让他们帮忙拼团，氛围特别热闹。

当时我还观察了一个叫“点开就看”的小程序，它里面包含养生类、新闻类、花草山水类等内容，字号特别大，是中老年人喜欢的风格。我做了个测试，托朋友将这个小程序分享给他们的长辈，结果，长辈们都表示非常喜欢，已经收藏。这在当时非常颠覆我认知，因为不论是 UI 设计还是内容都不能达到我的审美标准，这样的产品竟然能在一个群体中如此火爆，这个群体还非常愿意传播。

后来我开始去尝试了解这个中老年群体，混了好多群，聊了很多人，也慢慢理解了这个群体的内心需求。其实，中老年人，是今年下半年小程序应该着重去打的用户群体。

3. 逻辑力

能够将不同部门、内外声音等所有碎片梳理成树状关联的关系。产品经理需要开很多会，所以信息的整理能力非常重要。同时，逻辑能力还包括对优先级的判断，以及高优先级条目与其它条目的关联性。有逻辑的观点会具有更强的说服力。

4. 化繁为简

找到用户最真实的场景，用用户最容易使用的路径去实现。在这方面，我们需要做到这 4 步：

研究用户在不同场景下的不同需求，并梳理成流程图和故事；

抽象出用户的需求，并列出实现方案 A、B、C；

像用户一样思考，寻找最简单的实现路径；

谨防炫技。

其实，在做用户调研的时候，用户往往很难将内心真正的需求表达清楚。比如，你问用户哪类内容会引发他的阅读兴趣，他可能回答是比较狗血的社会新闻，但如果你因此去做标题党，你的文章并不一定火爆。因为用户真正喜欢的可能并不是狗血的社会新闻，而是其中刺激到他内心的某个点，狗血的社会新闻只是一个外在表象。所以，我们要挖掘用户的核心需求，制定最简单最直观到达用户内心的产品。

5. 不完美思维

因为没有完美的解决方案，只有当下最合理的解决方案。我们要知道哪些是最重要的，哪些是暂时不重要的，要允许不完美，懂得舍弃，懂得屏蔽各种声音带来的非核心需求，毕竟优先解决当前用户的核心需求永远是最重要的。

举个例子，我第一次创业的时候，公司只有 7 人，资金只有一百多万元，产品做了五个月后，遇到了很多技术瓶颈，是我们无法解决的。当时，资金所剩不多，也招不到技术大牛来解决问题。所以，在一次例会中，我们决定砍掉一些不重要的功能，先想办法让公司存活下去。

虽然，公司最后还是没能存活，但是回头去看，对于那个阶段来讲，我们的做法并没有错。当时我们有两个产品，如果不做取舍，可能连一个产品都做不出来。所以很多时候，我们要允许存在不完美，先实现再改进，这会更适合当下中国互联网的竞争态势。

6. 战略思维

像 CEO 那样去思考战略，像 OKR 拆解那样去执行战略。之前看到过一个观点：谁未来最有可能成为 CEO，是产品经理，因为他必须关注面，而非点，要把很多点连成面，这就要求他们充分了解竞争格局，不仅仅是功能，还包括团队优势、融资状况等。

我们做产品的时候，并不是设计完成某个功能就好的，而是需要知道我们做的每一个产品、每一次版本的迭代，对整个公司的好处，对未来盈利的好处。产品经理应该把自己的思维拔到一个相对比较高的角度，思考产品对于公司的价值。

另外，战略思维也包括不完美思维，意味着要放弃一部分不重要的的东西。

7. 运营思维

好的产品是技术、运营、营销配合出来的，在产品中注入运营思维，产品会活的更持久。运营思维主要需要注意 4 点：

产品不光要实现，还要考虑如何吸引用户，如何留住用户；

洞悉用户心理，寻找用户在使用产品中的心理需求；

懂得如何让用户自发传播，如何节省营销成本；

产品中的运营功能应该是方案化并可重复使用的。

8. 利他心理

通俗讲，知道应该找谁推动什么事，并知道应该给他什么，让他来帮助你。举个例子，我有个朋友之前在百度负责广告部门，他想在搜索界面的某个地方再加一些广告位。做的过程中遇到很大的阻力，因为他需要跟好几个部门沟通协调。

第一，技术部门得去沟通，因为需要他们实现广告位的技术开发。第二，广告销售部门得去沟通，因为广告位增加之后，需要他们卖出去。还有其他诸如网站、广告平台等所有相关部门。

然而沟通的结果是，除了广告销售部门，并没有部门答应做这件事，因为对他们其实没有明显的好处。

最后，他决定找广告销售部的负责人一起合作来推动这项计划的实施，因为这项计划能给销售部带来利益。结果是，所有阻力都被顺利攻克，成功增加了新的广告位。

可以看出，产品经理是一个需要调动所有资源、推动产品开发的角色。那么，要调动资源，就需要平衡人与人、人与资源之间的关系，需要具备利他心理，找到关键人，了解这些关键人最关心的是什么，并满足他们的需求，以此减小阻力，让他们帮助你推动这件事。

最后总结一下，本文分享了工程师转型产品经理必须要掌握的八个思维与能力，包括好奇心、同理心、逻辑力、化繁为简、不完美思维、战略思维、运营思维和利他心理。即使不是工程师转型，所有做产品的人都应该具备这些素质。希望我的分享能为你带来思考与价值，感谢你的收听。

作者简介

阿禅，连续创业者，资深微信产品与运营研究者。创办中文原创博客可能吧，轻单创始人、有可能学院 CEO、极客公园前 CEO、出门问问产品总监，目前担任轻芒合伙人。

（本文整理自阿禅在 ArchSummit 全球架构师峰会上的分享，有删减。）

第98讲 | 徐裕键：业务高速增长过程中的团队迭代

你好，我是贝贝网合伙人兼研发副总裁徐裕键，今天跟你分享的话题是，业务高速增长过程中面临的挑战，以及该如何应对。

先简单介绍一下贝贝网，贝贝网在 2014 年上线，不到一年时间，就拿到 C 轮一亿美金的融资，成为估值 10 亿美金的独角兽公司，用两年时间开始实现规模化盈利。我们公司也从最初的 3 个人，成长为上千人规模的大团队。

业务高速增长过程中面临的挑战

一个高速增长的公司会面临各种各样的挑战，这些挑战来自方方面面，但大部分可以归结于业务和团队两大方面。

公司的高速增长必然伴随着业务的指数级增长，而且随着业务的增长，团队会越来越壮大，团队中的角色也会越来越多，此时就会出现两个问题。

第一个问题是流程混乱。从最初运营提出需求到产品设计，再到开发上线，这个产品可能就与最初预想的效果完全不一样了。可能我们最初的产品需求是卖家秀的效果，产品上线后就变成了买家秀。

第二个问题是团队内部的挑战。创业初期，公司影响力比较小，要招到合适的人非常困难。所以当时我们的团队成员基本都是一二线电商公司、互联网公司筛选过的员工，或者是实习生和校招生。而随着业务快速增长，需要不停增加人员来满足业务增长的需求。这时你会发现，即使团队的管理层很牛、很专业，但是管理想法就是落实不下去，因为中层是缺失的。

另外，管理者自身也存在一些问题，因为我们不少管理者都是从技术转型而来的，他们看到团队成员事情做的不好，比如说代码写的慢、规范写不好、架构设计不好等，就恨不得自己上手去做，自己去写代码。

但这样做终归是解决不了问题的。那具体该如何解决呢？我分享两个个我们的做法，即规范流程制度、完善团队人才梯队，希望能给你提供一些参考。

规范流程制度

首先要规范流程制度，将它变得标准化、工具化、可度量，让团队成员有流程可依。

从业务角度来讲，公司业绩增长会带来业务复杂度的提升，比如，业务不停增长，系统就会不停地堆代码，那么系统就会越来越复杂，当它复杂到一定程度时，我们就很难继续快速的跟进与执行了。

同时，业绩增长常会稀释人才密度，当业务复杂度往上快速增长时，公司高绩效人才的占比是下降的，两者会出现一个交叉点。当交叉点出现时，你会发现以前的那套流程已经不适用了，混乱和错误开始出现，产品迭代速度会受到严重制约。在这个人才密度上，业务已经变得太过复杂，而系统不可能再以往常的形态运行。

此时，最简单有效的解决方案就是梳理一套流程制度规范，因为当下你很难招到合适的、能即插即用的专业人才，当然，这并不是说现有团队成员的能力不行，只是他们需要一定的时间去成长，而你提供给他们一整套的流程，授予他们合用的工具与方法，能够帮助他们快速成长起来。

其实，业界有不少成型的流程制度规范，我们可以去借鉴参考，但不能照搬照用，如何将其优化的适合自己公司的情况，真正落地执行，是其中的关键的。

我们的一个尝试是增加了项目经理的角色，在我看来，一个项目要完整执行下来，会有三个关键角色，分别是产品经理、技术经理和项目经理，他们组成金三角，一起去推动这个项目。

项目推进过程中，需要信息快速传递，并且要避免信息失真、不对称的问题，所以我们会建立专门的站会制度，定期沟通、同步进展。另外，项目上线后并不代表结束，我们还需要重视结果，不论这个项目成功还是失败，我们都会组织相关同学进行复盘，并对该项目的流程进行持续的迭代优化。

另外，项目的流程规范也要跟技术的演进紧密相连，比如当我们能做到 APP 组件化的时候，项目方式就得作出相应的变革，否则，就不能与生产力的增长相匹配。

以我们公司为例，规范项目流程能够确保上百号研发、数十条业务线做到并行迭代，同时能够做到快速发布，新版本的迭代速度从一个月一个版本缩短到了三周一个版本。 总而言之，要持续优化改进流程制度规范，以此终止混乱，提升效率和质量。

完善人才梯队

其次是完善人才梯队，刚才也讲到，随着业务复杂度提升，团队高绩效人才的密度会下降，所以，我们需要完善团队人才梯队，使人才密度的提升超过业务复杂度增长。同时，我们也要通过工具化、产品化、智能 AI 等技术手段，将业务增长带来的系统复杂度增长降低到最小。

另外，砍掉一些次要的边缘性业务，或是让人分散精力的鸡肋业务，关注最核心、最具价值的事情，也能降低系统复杂性。

在搭建团队人才梯队时，我们探讨过一个话题，即管理者到底要不要背招聘 KPI？我们的结论是要背。因为招聘不仅是 HR 的事情，也是管理者的事情。一名优秀的管理者也应该是一名优秀的 HR，反之，如果不具备 HR 的能力，他也做不好管理者的角色。所以，在创业早期，我几乎每年年底都会亲自飞去北京，跟各个领域的专家、资深架构师面对面沟通，将他们吸引到自己的团队中。

我们也探讨过另一个话题，即我们是否应该通过高薪引入一些专业人才，他会不会打破团队中的薪酬平衡？因为之前创业初期，招进团队的成员薪资比较低，如果招聘一位技术专家进来，他的薪资可能会比别人多出一倍，甚至好几倍。

最终，我们的答案是，团队需要这样的技术专家，而且，当公司还处在快速发展阶段时，最初跟随团队的那些员工也需要继续成长。那么，通过引进专业人才，可以倒逼大家去不断突破自己的天花板，使团队整体的能力再上一个台阶。结果告诉我们，这确实非常有效。

在完善团队梯队时，你必须选择符合团队发展的组织架构。一般来说，团队组织架构分为两种，一种是职能驱动型，另一种是业务驱动型，而这两种组织架构我们都经历过。

职能矩阵型团队是特点是团队小，业务简单且产品单一，能够更好地进行资源统筹及人员备份，此时，团队应该专注于深耕所在领域，以寻求更大的突破。

而当公司发展，团队变大，业务也越来越多、越来越复杂之后，为了保证产品及业务能够并行快速迭代，这时就需要将团队重组为业务矩阵型团队，以业务线为主，进行团队分工，将全职能目标打通，建立利益共同体。

我们公司即使发展到两三百人的规模，也依然保持扁平化的管理方式，团队中的管理者只有 20 人左右，总占比不到 10%。这样做是希望我们的研发同学能够在专业技能方面发挥更大的价值，我们希望以业务为导向，激发团队自驱动性，将团队价值发挥到最大。

组织架构的能力非常关键，从过去几年的创业过程中，我发现一个公司能否持续成功，有两个决定因素，一个是战略能力、决策能力，一个组织能力。在公司发展过程中，每个阶段都有非常多的机会，至于能否选择对机会，就取决于战略能力和决策能力。即使选对机会，但这个机会最终不一定会属于你，这时就看你的团队组织能力与团队执行力。在如今竞争残酷的市场中，半年就可以决定一个创业公司成或者败，一年时间就可以决定一个公司的存亡。

希望今天的分享能对你有所帮助，感谢你的收听，我们下期再见！

作者简介

徐裕键，贝贝网合伙人兼研发副总裁。负责贝贝技术团队管理，从 0 到 1 搭建贝贝移动电商产品和技术架构，推动集团各个技术领域快速演进，完善技术团队的梯队搭建和文化建设。

（本文整理自徐裕键在 ArchSummit 全球架构师峰会上的分享，有删减。）

第99讲 | 徐裕键：业务高速增长过程中的技术演进

你好，我是贝贝网合伙人兼研发副总裁徐裕键。上一期文章中，我跟你分享了业务高速增长带来的业务和团队两方面的挑战，以及如何通过规范流程制度、搭建人才梯队、完善组织架构等方法来应对这些挑战。

然而，在业务高速增长的过程中，来自技术的挑战也不可忽视。贝贝网从一个电商新秀到行业独角兽，只用了短短两三年的时间，看似顺利，但其中的酸甜苦辣只有我们自己知道。所以今天就想扒扒皮，和你分享一下我们业务扩张过程中在技术上踩过的那些坑，以及我们是如何应对的。

业务规模和复杂度快速增长带来的挑战

其实，创业最初，我们曾怀疑过贝贝网这个平台的可能性，因为在早期的电商淡季时期，我们连三个九的业绩都达不到。后来，在双十一流量压力的作用下，我们把业绩做到了四个九以上，才打消了我们的疑虑。

另外，最开始我们是移动电商，APP 版本的迭代速度非常慢，早期可能一个月更新一个版本都非常困难。后来，经过技术的不断演进、团队的不断迭代，我们能够做到每周更新一个版本，而且新版本的缺陷率从原先的 50% 降低到 5% 以上。50% 意味着，在早期，我们上线的 100 个需求里面，有 50 个需求是有缺陷的，需要返工的。

版本更新速度的提升与相应错误率的下降，这背后起支撑的是一个团队的持续迭代。一个人可以走得很快，但唯有一个团队，才能走得更远。

再来看来自于技术的挑战。公司在快速发展过程中，相应的业务量也是快速增长的，最初可能只有一个单一的产品、一个简单的业务，到后面，随着业务、产品的成熟，逐渐将它铺开后，可能会出现多个产品，甚至数十条业务线，都需要并行迭代的情况。此时便会衍生出更多的问题，具体可以分为三点：

第一个问题是，原先我们习惯于在一个工程或一个系统应用上进行开发，长期以往，代码会越堆越多，导致这个系统越来越腐化，架构越来越不稳定，出现越来越多的耦合。

这时就会发现，团队的新成员进来后不敢写代码，团队中的老人也不敢对这个存在复杂耦合性的系统轻举妄动。因为，极有可能你动了某个地方，就会导致整个系统出现更大的问题。一旦这种可能性发生，那之前的什么代码冲突，相较而言就是非常小意思的事情了。

第二个问题是，当大家都在一个工程、一个应用上进行开发，并且有多条业务线并行迭代的时候，你会发现，每个团队直接的步伐并不一致，互相之间可能会有诸多争论。这样就会导致版本更新的效率大大降低，也加大了需求上线的难度，比如大家可能需要花费半天的时间才能够完成上线验证，效率极其低下。

第三个问题是，由于系统太过耦合，可能某个新功能上线后对于全站业绩增长的影响非常有限，但因为系统扛不住新功能带来的流量，结果导致核心链路交易服务都不可用了。

业务系统解耦合及平台化推进

说了这么多问题，我们当时是如何应对这些技术难题的呢？

首先，我们要明确一个观点：保证生存是首要目的，永远没有非常完美的产品方案，我们必须要不停地进行开发和迭代。所以，我们必须具备一种快速试错、低成本试错的能力，使产品和业务完成快速迭代。并且，当这个模式成熟后，能够帮助产品和业务快速进行规模化，再通过这种规模化的能力，实现公司商业价值最大化。

回到具体的技术挑战，公司规模上来后，我们在每个技术领域都有非常大的技术演进，是基于全栈的技术演进，从 APP 端组件化动态化，到业务层组件化，到服务化，一直到底层数据库拆分、运维自动化、持续集成能力的提升等，我们都做了很多布局，而且很多都被证明是非常有效的。同时，整个系统的基础架构设施也在不断完善和配套。最有力的表现就是，后台研发同学的交付能力，直接是翻倍的提升。

其实，归纳起来就是通过服务框架对应用进行拆分解耦、采用异步消息来对系统进行解耦、使用分布式数据访问实现数据层的无限扩容。

在 APM 应用性能管理方面，我们自研了一套从客户端到后端的全链路应用市场监控，便于我们对性能进行优化。其监控管理对象也从最初的单应用演进为多应用。

在应用拆分、服务化之后，我们还自研了一套私有云系统，改进了系统的部署方式，从原来的集中式部署，到分布式部署，再演进到单元化部署。这样一来，原本交付一个资源至少需要一天以上，现在只需要几分钟就能进行扩容，效果立竿见影。

在监控告警方面，我们从原来的单机房部署，一路演进到异地多机房部署，基于这样的监控告警体系，当我们的业务指标发生变化时，能够做到一分钟之内告警，特别是核心业务指标发生变化时，我们可以及时进行处理。

在持续集成方面，我们也从最初的单系统优化做到后面的结构型优化，能够提供非常灵活的灰度发布机制、非常快捷的回滚机制，确保即使出现问题，它的影响也能控制到最小。

在大数据方面，我们很早就开始布局，并组建大数据团队，目前已经演进到机器学习阶段。比方说在客服上，机器客服能够帮助节省一半的客服人员，减少人力资源消耗。另外，对运营也有非常大的帮助，比如通过自动化排期，基本能做到减少 1/3 运营人员的投入。

当然，在技术之外，流程是保证保证快速迭代的关键，对此，我们定了两点原则：一是每个阶段都实行准入制度，明确需求；二是每个环节都检查输出，包括质量和时间两个维度。在具体执行中，我们推行短项目迭代制，正如之前提到的，没有完美的产品方案，我们要先求有，再求优，小步快跑、快速迭代，而所有的技术与系统都要能支撑我们能够迅速验证产品。

总结一下，技术上的挑战，来自于业务高速增长形成规模化之后，带来的系统复杂度的上涨，而解决的重点在于，通过服务框架对应用进行拆分解耦、采用异步消息来对系统进行解耦、使用分布式数据访问实现数据层的无限扩容。

然而需要注意的是，对创业团队来说，如果想要把握住机会，就必须做到快，因此，在技术演进的时候，也要学会克制自己的技术洁癖，不要追求完美，适合的才是最好的。

作者简介

徐裕键，贝贝网合伙人兼研发副总裁。负责贝贝技术团队管理，从 0 到 1 搭建贝贝移动电商产品和技术架构，推动集团各个技术领域快速演进，完善技术团队的梯队搭建和文化建设。

（本文整理自徐裕键在 ArchSummit 全球架构师峰会上的分享，有删减。）

结束篇 | 即使远隔千山万水，也要乘风与你同往

你好，我是《技术领导力 300 讲》的主编成敏，2018 年 4 月 16 日，我们发布了专栏第一篇文章，《你的能力模型决定你的职位》，分享了不同技术管理岗位的能力模型，不知道你是否还记得？

到今天，我们已经一起度过了一年多的时间，再不舍，300 讲专栏也要和你说再见了。在这一年里，我们共同学习了 260 篇文章，阅读了 80 多万字，这个数字统计出来后我也吓了一跳，差不多是 2 本书的厚度了。

在内容上，我们也从 CTO 能力模型到优秀技术管理者必备素质，从高质效团队的管理要点到高效研发流程的打造关键，从优质技术人才的选育用留到优秀团队文化的培养打造，从技术创业的那些坑到需要了解的那些行业趋势，尽力涵盖了技术领导力的方方面面。

如果其中有哪些内容让你产生，“啊，原来是这样”、“原来还可以这样”，或者“咦，这个方法我可以试试看”这样的想法，那就是这个专栏的成功了。

回想最初，我们为什么要做这个专栏，根本原因在于，对于技术管理者来说，领导力太重要了，是他们是否能够影响别人，让他们朝着特定方向前进的关键能力。与此同时，任何一个卓越的组织，都必然有一个卓越的领导者。领导者是一个组织的灵魂，在很大程度上决定了组织所能达到的高度，技术团队也不例外。

因为工作关系，我们有机会经常与技术管理者交流，在这个过程中，我们发现，技术人们在提升领导力的过程中，往往会遇到很多挑战。虽然这些问题的表象不同，但在本质上其实是相通的，包括对内的技术选型、产品功能实现、团队成员培养、技术人员考核等等；对外的扩大公司技术影响力、为公司招募更多优秀研发人员，发展潜在客户等职责等。

这些问题，我们是否能通过一个专栏，来给技术管理者们提供一些参考做法、解题思路呢？答案是可以的。我们可能无法提供一个标准答案，毕竟不同管理者的领导力风格不同，不同场景下也需要不同的领导力。但我们可以提供其他优秀技术领导力的实践经验、反思复盘，分享他们踩过哪些坑，以及他们是如何跳出这些坑的。这样的思想碰撞，是最为高效的学习方式。

基于这个想法，300 讲总共邀请了 125 位技术领导者，来与你分享他们的管理与成长经验，希望这些内容能真正对你有所启发和帮助。在结束的这一刻，专栏的作者们也给你送上了他们的寄语，山高水长，终身学习的路上，我们一起乘风前行！

各位技术人，大家好。很高兴和大家在极客时间相遇。管理大师德鲁克说：“有效管理者的自我发展，是组织发展的关键所在。”极客时间为我们技术管理者创造了一个共同进化的环境，祝极客时间越办越好。

学到知识后大家记得抓紧实践，德鲁克大师的另一句话与大家共勉：管理是一种实践，其本质不在于“知”，而在于“行”，其验证不在于逻辑，而在于成果，其唯一权威就是成就。让我们带着团队一起成长！
——随行付 CTO 于人

非常有幸参与了极客时间《技术领导力 300 讲》的栏目，这里汇集了上百位 CTO 的真知灼见，可以说是一个思想的汇集地。对于学习者来说，只有将这些他人的理论付诸自己的实践才能真正从内心构建起适合自己的方法。最后用唐代书法理论家孙过庭《书谱》中的名句与大家共勉：初学分布，但求平正；既知平正，务追险绝；既能险绝，复归平正。
——马蜂窝技术副总裁张矗

计算机行业可能是各个行业中信息量最大，更新速度最快的一个领域。在如此快节奏的环境下，我们必须对经验做更多沉淀总结，对新知识做更广泛的吸收。只有这样才能持续提升我们的认知，达到发展的要求。面对这样一个信息过载的时代，选取一个合适的学习平台显得尤为重要。极客时间给我们提供了一个很好的平台来满足上面两方面的要求。

这里既有各位前辈大咖总结自己的经验拿出来分享，也有技术大拿对于前沿技术的分析洞见。我作为作者，同时也是读者，很感谢极客时间提供这样一个平台，也希望可以继续在这里跟大家共同成长。
——阿里云解决方案架构师暨家愉

每一次新技术的出现都会引领社会的重大变革，进而在社会要素重组后出现新技术的推广，移动互联网也不例外，这种规律最终呈现为业务和技术的相互促进和交替发展。当下，互联网进入下半场的结论，已经从大佬富有前瞻的趋势判断，变成身边可以切身体会的行业氛围。回到互联网技术领域，在前辈们摘下低垂的果实之后，技术的知识大厦也因为前辈们的探索日趋庞大而复杂。

就个人而言，互联网带来的新学习手段降低了学习门槛的同时，也带来了信息爆炸和辨识成本的剧增，使得学习效率不高甚至迷失方向很容易成为现实的问题。此时，有一个能帮助个人更有条理修建知识大厦的平台显得更加应景和重要，而极客时间正是这样的技术学习平台。在这里，不论是有志于寻找前沿新技术突破的技术大牛，还是利用上半场的技术积累做应用和落地的业务大咖，都会发现要找的前辈就在这等着你。共同学习愉快！
——德信随寓 CTO 兼 COO 陈崇磐

打绩效一直是技术领导者难以处理的问题，问题的核心一方面是程序员的工作属于创造性的劳动，另一方面由于人性的弱点容易以偏概全，通过引入敏捷的方式，在解决了提高研发效率的同时，还意外的解决了打绩效的问题，原因还是在于敏捷的过程，引入了团队自身对自己的客观认识，同时又将这样的认识透明的呈现给了整个团队，最终的绩效变成了大家能认同且不因为领导者的个人喜好而变化的结果。希望这次分享能给大家一点启示。
——搜狐社交产品中心总经理高琦

如果你已经读到这里。恭喜你，快要结束了。其实，说得再多，听得再多都没有用，关键是去做，勇敢的去做。有时候知道太多困难，就会畏首畏脚而裹足不前。当你真正经历打造技术团队过程时，才是真正体验如何去打造一个技术团队，体验其过程的酸甜苦辣。只有感觉到痛苦、寝食难安的时候，才是你真正成长蜕变的时候。

在这个过程中，你需要时刻回想学习过的各种理论知识，并再重温一下我之前写的打造技术团队系列文章，你将会有不一样的收获，让自己保持一颗谦虚学习、积极乐观、不断挑战自我的心态，灵活使用各种管理工具和思维方式，并勤于沟通、富有同理心、保持自律，你就一定能成功。最后送给大家一句话作为结束语： 要懂人性，要有人性！
——极智嘉研发总监邱良军

在即将说“再见”的今天， 我期待看到你学习这个专栏的感受与收获。

最后的最后，希望你已经成为了更好的自己。