del

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 万玉权：如何招到并培养核心人才.md

@@ -0,0 +1,65 @@
+<audio id="audio" title="大咖对话 | 万玉权：如何招到并培养核心人才" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1c/57/1c694edc26638b8944f0b4dd5dcace57.mp3"></audio>
+
+你好！
+
+本周“大咖对话”的嘉宾依然是连尚网络副总裁、WiFi万能钥匙事业群CEO万玉权，拥有10多年互联网研发和管理经验，目前负责WiFi万能钥匙核心产品和技术研发管理及热点画像业务，在连尚网络期间，完成了核心系统架构从 1.0 到 2.0 的改进。
+
+上周，我们和他聊了CTO到CEO的转变之路，以及高效团队打造等话题，其中谈到人才管理时，万玉权认为“兵不在多，而在于精”，本周，我们就跟他深入聊了聊他对于人才战略的认知。
+
+**极客时间：在您看来，人才成长过程中，最重要的特质是什么？**
+
+**万玉权：** 总结一下，可以归纳为“**明确目标，享受过程**”。
+
+首先，在职业发展路径中，无论是初入职场的新人，还是企业的领导者，都需要明确自己的目标，这就像航船需要知道灯塔的位置一样重要。只有明确目标，才能够知道自己前行的方向。
+
+同时，在这过程中，你的目标不要随着时间、职位、薪资等外界因素的变化而变化。这里我举个反例，有些人在职业发展过程中，往往会因为追求高薪资、年终奖、特斯拉等附加物质，而改变自己的目标，最终导致迷失方向。在我看来，这些都是不可取的行为，当你的事业目标达成之后，这些附加物质自然会随之而来。所以，确定你的目标，坚定并坚持去实现它。
+
+以我自己为例，2013年，我加入WiFi万能钥匙，从最初的程序员到技术经理再到现在的事业群CEO，我的目标一直很笃定，就是希望能够在这个平台上实践属于自己的架构思维和技术理想，研发出服务千万级甚至上亿级用户的产品。最初，确立这个目标的时候，作为程序员的我认为，能够做出这样的产品很牛，而尽管之后的职位一直在变，我的这个想法也没变过。
+
+其次，在实现目标的过程中，要学会享受。打个比方，我将自己比作一名舞者，练了十几年基本功，现在，我想在WiFi万能钥匙这个舞台上跳一段舞，并尽情享受这跳舞的整个过程。我一直都以这样的状态面对工作，面向目标，乃至于到现在，尽管我已经不写程序，已经转向管理了，我依然享受每天所经历的事情，无论过程开心与否，对我来讲，都非常有价值，因为每一天，都是向着目标前进的一天。
+
+对于我的团队，我也是按照这两点来要求大家，要求每个人都明确自己的目标，并学会享受实现目标的过程。事实证明，这对于提升团队效率非常有效。
+
+WiFi万能钥匙里有很多13年、14年就加入跟随团队的老员工，他们像我一样，在这里历经了不同的岗位，接受过许多新挑战，他们都一步一步实现了自己的目标，比如从最初的程序员，到现在成为技术总监、技术VP。他们很清楚自己在这个地方要做什么，也时常跟我聊天，一起沟通自己在这个团队的目标与发展路径。
+
+**极客时间：以您的经验来看，如何招到合适的人才呢？**
+
+**万玉权：** 公司长远发展的核心推动者是人才，我个人认为，兵不在多，而在于精。所以，我们非常注重人才的挑选与培养。挑选人才时，我们主要看重两点，第一点是价值观，第二点是能力。
+
+首先，最重要的考核因素就是人才的品质，即价值观。如果员工的价值观与公司不符，即使能力再强，他也很难真正为公司创造多少价值。
+
+具体在面试中，可以考察候选人对之前公司的企业文化的看法及认同程度，还可以考察他对之前公司制度的遵守程度，或对企业文化的践行程度。可以让他举一些实际的例子来说明。
+
+其次，要考核的是人才自身的能力，是否能够胜任本职工作。其实，简历经过筛选之后，挑选出的多数人都是合格的胜任者。如果在实际工作中，他难以胜任，基本都脱离不了两个原因：一是价值观偏差，工作态度问题；二是之前的工作经历和方向与新工作不太匹配。
+
+但是，在招人时，你很难保证，你招进来的人或被你拒绝的人就一定合适或一定不合适，所以出现了试用期。对于人才管理，必须依靠制度，依靠流程，依靠规范。
+
+在试用期阶段，我们会定期与新人沟通，比如入职一周后沟通一次，入职一个月的时候沟通一次，入职三个月的时候再聊一次。尽管现在团队已经很大了，但对于新招进来的中层干部或专家类人才，我依旧会亲自与他们定期沟通，而其他岗位的员工，就由相应部门的负责人进行沟通辅导。除了直属领导的沟通， HRBP也会定期与新人沟通，帮助他们解决疑惑与工作中遇到的困难。
+
+另外，新人会有一名专属导师，帮助他熟悉公司流程，熟悉业务情况，制订阶段性目标、绩效和计划等，并根据完成情况去做综合评判。如果发现价值观明显不符，我们会先帮助他进一步了解公司的文化与价值观；如果是工作岗位不匹配，我们会先对他进行调岗，帮助他再一次尝试。
+
+如果在诸多尝试之后，新人依然不能胜任工作，我们也会主动解聘。还有一种情况是员工踩到公司的红线，比如贪污受贿、数据泄密、威胁公司信息安全等，那么，无论是谁，价值观匹配度多高，能力多强，都必须马上终止劳动合同。
+
+**极客时间：在人才招进来之后，您会如何对他们进行培养？**
+
+**万玉权：** 在人才培养方面，我的观点是**先成就员工，再成就团队，最后成就企业**。我们要给每个员工足够多的成长机会，让他对公司有归属感，找到自己的目标与追求，认为在这里无论是输入还是输出，都有价值。
+
+每个人都有长板和短板，在用人时，要看到大家的长板。当我需要达成某个目标的时候，就要找出拥有这方面能力的员工，再依据每个人的特长进行目标拆解，使结果达到极致。
+
+待目标达成之后，就要抽出时间与精力找到每个人的短板，再通过内部经验分享、读书交流、业务培训或参加类似TGO这样的技术交流平台，帮助员工提升。
+
+在我看来，作为一名管理者，需要同时注重员工的长板效应与短板效应，并主动沟通，了解他们的诉求与困难点，对症下药，帮助他们提升自己，以此提升团队战斗力。
+
+目前，对于短板较明显的同学，我们更多的是以一种辅导的方式，帮助他成长。同时，我们也会跟他积极沟通，看他是不是愿意调岗，毕竟很可能另一个岗位就是他的长板所在。
+
+不同公司对调岗的的做法不太一样，比方在腾讯，员工入职两年后，会强制要求轮岗。不轮岗说明两个问题，要么是他能力不行，只能在这个岗位；要么是学习态度不行，或学习能力不行，综合来看就是不符合公司的人才要求。
+
+而WiFi万能钥匙对于员工的发展不会设限，不强制固定岗位，也不强制轮岗。只是我们过往的实践中，发现很多人在岗位的转变过程中，获得了很多成长。
+
+举个例子，我们团队中有一名部门负责人，最初是测试人员，只负责产品测试，但他做事认真细心，且责任心强，有强烈的责任感，除了做好本职工作，他还会去考虑整个产品相关的工作，比如从产品研发到运营，再到用户数据分析等，都愿意去思考。另外，他还经常主动与团队沟通，各方面表现都非常好，初步具备了团队Leader的条件。
+
+在这种情况下，你需要给他足够的机会，让他去尝试。可能刚开始尝试其他岗位时，他会有些迷茫，有些不知所措，与之前的表现也相差较大，但这时，你应该主动帮助他，给予他指导，经过几个轮回的试炼，他就会迅速成长，真正做好Leader这个角色。
+
+可以说，任何人的成长路径都是之字形，所谓之字形成长，就是从一个点盘桓旋曲而上至另一个点，在这过程中，需要经历许多磨砺。因此，对于内部的人才培养，也应该本着这样的态度与方式。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 万玉权：高效团队的关键，以目标为导向，用数据来说话.md

@@ -0,0 +1,81 @@
+<audio id="audio" title="大咖对话 | 万玉权：高效团队的关键，以目标为导向，用数据来说话" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/92/02/92cf4ab3b7604f1e4420a70a419d6502.mp3"></audio>
+
+你好！
+
+本周作客“大咖对话”的嘉宾是连尚网络副总裁、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论的出现，防止团队为了实现业务指标而为所欲为。这就需要更好的践行公司的价值观，剔除不符合价值观的行为，同时，我作为领导者也要做好把关工作。
+
+实行团队重组后，我能明细感觉到团队成员的自驱动性明显增强，团队效率也显著提高，我也要比去年轻松很多，能抽出更多时间来思考更多战略、行业相关的问题。最终，我们要达成的目标是，变管理为服务，变管控为赋能，将想象力与创造力归还给员工，使员工发挥自驱能力去完成目标。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 不可替代的Java：生态与程序员是两道护城河.md

@@ -0,0 +1,61 @@
+<audio id="audio" title="大咖对话 | 不可替代的Java：生态与程序员是两道护城河" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/44/e8/440f225e5ba0c66aecbb664802269ce8.mp3"></audio>
+
+你好！
+
+本周作客“大咖对话”的嘉宾是杨晓峰，他目前是Java核心类库北京团队leader，首席工程师。2011年加入Oracle Java团队，经历了从 JDK 7 到 JDK&nbsp;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。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 从几个工程师到2000+个工程师的技术团队成长秘诀.md

@@ -0,0 +1,69 @@
+<audio id="audio" title="大咖对话 | 从几个工程师到2000+个工程师的技术团队成长秘诀" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b1/ec/b12a0ad5a49b2ce74952cc903db043ec.mp3"></audio>
+
+你好！
+
+每周五是《技术领导力300讲》的“大咖对话”时间，本周与我们对话的嘉宾是斑马资本合伙人、原去哪儿网CTO、TGO鲲鹏会北京分会会员吴永强。
+
+在去哪儿期间，他建立了世界上访问量最高的旅游搜索引擎。在公司发展过程中，又成功地带领技术团队支持公司转型为以移动为核心的在线旅游平台。在团队建设上，他成功将去哪儿的技术团队从几个工程师扩展到2000+个工程师的规模。
+
+本周，我们邀请他来分享自己伴随公司成长过程中的收获，以及转型投资人的心得体会。<br />
+<img src="https://static001.geekbang.org/resource/image/f3/14/f3b5be76ae90fb65b413e82e2107aa14.jpg" alt="" />
+
+****Q：作为CTO伴随着创业公司（去哪儿网）一步步成长，到最终上市，你最大的收获是什么？****
+
+A：伴随一家公司从小成长到大，是一段奇妙的旅程，途中有欣喜，痛苦，焦虑，兴奋，什么样的场景、困难都会遇到，就如同我们伴随着孩子成长一样，孩子成长的过程，同时也是父母跟随成长的过程。我在去哪儿的工作历程，收获良多，我就挑几个对我影响比较大的说一下：
+
+首先，人是企业最重要的财富和资源，一个公司的成长伴随的是人的成长和团队的成长，一个公司就是所有员工的集合，公司所有人的集合的高度决定了公司发展的高度。所以要能够吸引好的人才，并且让这些人才在企业的平台上不断经历磨练，不断学习，不断进步。作为企业就应该从一开始就重视建立并改进自己的企业文化、激励机制、组织结构，为人才在内部的发展提供动力、平台。
+
+去哪儿技术团队，从几个人开始，发展到两千多人，基本经历几个阶段。第一阶段，是以熟人为主，这时候团队很小，更多是依靠核心人员过去积累的人脉，快速地建立起团队，这时候大家之间都很熟悉、信任，而且都战斗在业务的第一线，通常这个阶段的问题是很小的。
+
+第二阶段是社招为主，这一阶段业务快速扩张，业务的复杂度也快速上升，急需更多的人才加入进来，同时公司有了一定的知名度，也能招到非常多优秀的人才。
+
+这个阶段的问题主要是，人员来自四面八方，各自有各自的文化底色和做事的方法，同时技术分工变得复杂，很多人会离业务越来越远，这个阶段，如何能够保持原来建立的以业务为核心的技术文化不被稀释，同时能够将大家融合在一起，形成合力，是一个技术管理者需要解决的大问题。
+
+第三个阶段，是自己培养人才的阶段，这个阶段主要的人才来自于各大高校的校招。经验告诉我们，这是目前唯一能够大批量招到优秀人才的途径，所幸去哪儿在技术团队只有六十个人的时候就开始尝试校招，这对后面几年公司业务大发展的时候，解决人才的储备和发展起到了决定性的作用。
+
+校招进来的同学的选、用、育、留，又是一个非常不同的课题，我们在这些同学身上花了大量的时间和资源，做了很多不同的尝试，去培养他们技术、管理、业务等多方面的能力，很高兴看到的是，目前去哪儿网的大部分中坚力量都来自于我们当年的校招。
+
+其次，技术部门的定位问题，我向来认为业务是一个企业的核心。业务的发展壮大是保证技术部门得到足够投入并得到发展的关键。那么如何扎根于业务，同时对业务有自己的深刻的洞察，就是一个技术管理者日常最重要的工作。
+
+技术的积累和发展有自己独特的规律和步调，必须对业务目前和未来面临的技术挑战有一个清晰的认识，技术部门就有了当前运行的重心，也能对未来的挑战做技术和人才上的储备。在业务的挑战到来的时候，才不至于临时抱佛脚。
+
+另外，一个企业的发展历程如同一首交响乐，各个部门在不同的发展阶段，所处的位置和扮演的角色是不同的，如何能够在企业不同发展阶段，对技术部门进行准确的定位是非常重要的。
+
+在轮到技术部门作为主角的时候，就要勇于承担责任，发挥技术部门的优势，促进公司业务的发展；在轮到做配角的时候，也能安心、全力支持其他部门的工作，踏踏实实做好技术的积累和对未来的准备工作。只有这样，企业才能快速、和谐地向前发展。
+
+****Q：对于技术人拓展个人能力，你有哪些建议？****
+
+A：我想讲讲我自己认为的一些比较有意思的建议：
+
+懂业务，我经常开玩笑说，懂业务的技术，就像流氓会武术，多懂些公司的业务，会对我们日常跟产品、业务部门的沟通有很大的好处，也能看得懂各种业务上的变化。对自己在技术上的判断有特别大的帮助，特别是在优先级、重要性的判断准确性上，是那些不懂业务的技术人所不能比拟的。
+
+通常一个懂业务的技术人，在公司的发展速度都是比别人快很多的，而且也比较容易晋升到关键岗位。即使是换工作，选择加入哪家公司，又或者去创业，一个懂业务的技术人，大家可以想象会有多少优势吧。
+
+深度/广度并重，我认为人的知识要形成T字形的结构，有一个专长的方向，这是一竖，同时要掌握相关的知识，这是一横，这两个方向是相互促进的。
+
+没有一定的宽度，其实你的专长深度是有限的，没有一定的深度，横跨的知识就会很松散，而且很难形成结构，大家应该都有这个经验，你在一个方向感到进步很慢，去涉猎一下相关的知识，很多时候就能帮你打开原来方向的困局。
+
+现在的技术工作分工很细，我觉得这是计算机技术发展到成熟阶段的标志，但是技术人自己不能被分工所束缚，简单举例说，你做前端工作，光会前端技术会极大限制你的发展，跟前端相关的操作系统、网络、硬件、产品的基础知识都是需要涉猎和掌握的，而且能把这些知识形成有机的结构。
+
+我遇到过的大牛，都是有这样的知识结构，甚至都对人文，历史有一定的研究，他们把知识当成一个体系。
+
+人的技术，一个技术人的发展，不可避免会遇到人方面的问题，尤其对高端技术人的发展非常重要。高端技术人的日常工作大概是40%跟人相关，30%跟业务相关，剩下30%才跟技术相关。我认为掌握人的技术，有两点非常重要：一是懂表达，二是懂尊重。
+
+懂表达就是如何能将自己的理解用大家容易接受和理解的方式表达出来，这个对于建立和扩大自己的影响力非常关键。
+
+懂尊重，就是要帮助他人成长，好的技术人都容易有英雄情结，视比自己水平低的人如草芥，沟通基本以鄙视为主，所以必须从内心深处尊重其他人，才能建立和发展好一个技术团队。
+
+****Q：离开去哪儿之后，你成了一名投资人，转型过程中你遇到过哪些障碍？****
+
+A：确切说我目前还没有做大的转型，如果让我选择，技术和投资之间，我一定毫不犹豫选择技术。因此目前在投资方面我依然侧重于技术，以及帮助我们投资的公司的技术团队如何能运作得更好。
+
+和在企业做事不同的是，投资有他独特的知识结构以及运作流程，这部分我之前基本是空白，所以现阶段，能做和正在做的就是努力向有经验的同事学习，希望自己能够早日“毕业”。
+
+另外，作为一个技术人员，我跟很多工程师一样，思考问题相对保守，同时习惯于在过程中不断收集信息，学习知识，积累自己对这件事情的信心，这个和投资非常不一样，投资相对来说更加宏观、更加趋势性，时间点也更加急迫，就需要你作出抉择。当然成熟的优秀投资者都有一套自己的方法论来处理这些问题，但这个的确是我目前正在努力去适应、学习和解决的最重要的障碍。
+
+**作者简介**<br />
+吴永强，斑马资本合伙人兼董事总经理、原去哪儿网CTO、[TGO鲲鹏会](http://tgo.geekbang.org)北京分会会员。专注技术管理、大数据、云计算等领域，并具有非常丰富的实战经验。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 以产生价值判断工程师贡献——读者留言精选.md

@@ -0,0 +1,78 @@
+<audio id="audio" title="大咖对话 | 以产生价值判断工程师贡献——读者留言精选" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/fc/ac/fc6f9d8121dd7d442301a725423e7dac.mp3"></audio>
+
+你好！
+
+欢迎来到本周的“大咖对话”环节。不知不觉，“技术领导力300讲”专栏已经更新了4个月，走过了三分之一的路程。
+
+在这四个月里，我们邀请到了近40位CTO、技术VP、有技术背景的CEO等技术领导者来分享他们的实践与经验，话题涉及技术领导者的核心能力、高效技术团队的打造、高效研发流程的建设、技术团队的考核与激励、技术团队文化的建设、空降管理者该如何平稳落地、技术领导者的产品思维等多个方向。
+
+不少读者踊跃留言，分享了他们的观点，也留下了他们的疑问。本周的“大咖对话”环节就筛选出了往期留言中具有代表性的问题，并邀请了相应的大咖来回答。你可以点击文中链接，回顾之前的文章。
+
+在[《如何高效管理8000+规模的技术团队》](http://time.geekbang.org/column/article/9308)一文中，有读者留言问道：“文中提到要打造一个数据化管理体系，把IT管理的对象数据化，想请教一下，数据收集的具体维度是什么呢？如何衡量一个工程师的贡献度到底有多大呢？是看代码量，修复bug数量，还是攻克关键问题的数量等，能分享你们的具体做法么？”
+
+**苏宁易购IT总部执行副总裁乔新亮**：我们数据收集的维度分两个方向，第一个是数字化资产，第二个是工程师对数字化资产的贡献。
+
+首先，数字化资产会包括产品、系统、服务等资产，以服务中的用户体验为例，它的数据化考量维度就是响应速度快不快、异常情况多不多、服务可用性高不高、响应时间的SOA满足率怎么样等。
+
+其次，每一个数字化资产都会对应到某个工程师或工程师团队，他们会负责这个数字化资产的开发、测试、维护等，因此，衡量工程师的贡献度，是从结果出发的。读者提的问题可能更多的是站在开发者的角度，衡量他做了什么，而我们是从整体的、偏宏观一点的角度出发，不管他写了多少代码、解决多少问题，只看他最后产生了什么价值，比如他参与开发的系统响应速度控制在了多少以内等。
+
+另外，我们的衡量细度也不是具体到人，而是看具体贡献情况，看是以小团队为单位还是以人为单位，如果是以团队为单位，那就是公司将评价数据分配给团队后，再由团队分配到个人，得根据具体的情况调整。
+
+在[《让细节的“病毒”感染你的团队》](http://time.geekbang.org/column/article/8273)一文中，有读者留言问道：“关注细节的确有益于把控系统，但如何保证当技术领导者介入细节后不让团队成员对你形成依赖呢？另外，越级介入一些系统，是否会导致基层员工的不创新、不思考呢？”
+
+**白山CTO童剑**：第一个问题，如何防止团队成员形成依赖，我们可以从以下几个方面出发：
+
+1. 培养关注细节的文化;
+1. 建立制度，使细节变成一种流程;
+1. 多提出问题，让团队成员来思考解决办法，给他们空间让他们按自己方法去解决;
+1. 启发式引导，不要一上来就告诉他问题和办法，而是要引导他们发现问题，启发出解决办法；
+1. 管理者是逐步退出的。
+
+第二个问题，如何避免形成基层员工的不创新、不思考，我们可以从以下几个方面出发：
+
+1. 管理者并非越级介入，关注细节的文化形成后，团队中每个人都重视细节， 高层与中层确认细节即可，不影响底层开发。
+1. 管理者对细节的关注和参与，就像教练一样，是传授给员工更好的做事方法。
+1. 管理者对细节的关注和参与，也是以身作则，给员工做出示范，既给员工压力，也让员工有榜样学习。
+1. 对于基层员工，鼓励创新与思考，管理者对其开发细节的关注，是为了帮助基层员工更好的完成开发。
+1. 基层员工更多是从开发的角度思考，而中层和高层的领导者需要从使用者的角度设计产品功能，领导者的参与过程中会给基层员工带来更多的视野，对基层员工本身也是一种提升与培养
+1. 文化是一种彼此交流的基础，我们有招聘的“洁癖”，大家有共同愿景，不会因为上层的过多介入而失去主观能动性，乔布斯说“A级人才的自尊心不需要呵护”，同样“对于A级人才也不必担心上层介入会对其产生负面影响”。
+
+在[《建立有效的员工淘汰机制》](http://time.geekbang.org/column/article/8240)一文中，有读者问道：“对于“合格但不合适”的员工，要怎么处理呢？又该如何确定赔偿方案呢？”
+
+**好买财富平台架构部技术总监王晔倞**：在我的经验中，这种情况一般分为两种，“试用期”与“正式期”：
+
+1.试用期阶段，这时不需要客气，直接说明不合适的原因即可，也不需要任何赔偿 。这种情况的发生很大程度上是由于公司和员工对岗位职责的界定不清晰而引发的。
+
+为了预防这种情况，如果试用期为6个月，可以采取2个月考核一次的方式，前2个月可以安排对方做一些验证其技能的工作，甚至可以设定一些无中生有的任务，后2个月可以安排对方做一些验证其价值观的工作，如项目经理等推动与沟通偏多的工作，最后留出1个月，如果对方不合适的话，留出让其重新找工作的时间，这样做基本可以达到好聚好散的目的。
+
+2.正式期阶段，这时有两种做法，硬开和不硬开。硬开的话，按照劳动法，肯定是按照N+1的方式来赔偿的，如果对方非常较真，一般情况下是无法拿出量化的具体依据来证明其表现不好的。 不硬开的话，可以通过谈话、调岗等手段进行，至少让他觉得你们的企业还挺Nice的，不至于产生负面印象。
+
+所以我觉得，关键在于试用期的把关，如果无法守住这一关，光想在正式期采取“有利于公司”的方式开除员工，既不合理，也不可取。
+
+在[《定制高效研发流程》](http://time.geekbang.org/column/article/6976)一文中，有读者留言问道：“特赞币的做法确实挺好，不过这个虚拟货币的价值是什么呢？各角色为什么要去获取它呢？”
+
+**黄勇**：特赞币只是一种工具，它用于解决研发和业务之间的高效协作问题，业务提需求需要“花币”，业务提反馈可以“赚币”，币的总数是恒定的（在一定条件下会考虑增发），币在业务与研发之间进行流通。
+
+这样，业务提需求是一件需要付出成本的事情，确保所提的需求都是真正的痛点，同时，研发也能尽可能快地收集业务反馈，进一步验证产品的价值。对于优先级较高的需求，业务也可以花费更多的币在这项需求上，研发也会更加重视该需求。
+
+在[《&nbsp;验证研发团队价值的绩效考核机制》](http://time.geekbang.org/column/article/7916)一文中，有读者问道：“关于个人OKR部分想请教一下，个人OKR分为个人成长和团队贡献，那制定的个人成长和贡献怎么来评估是合理的，可执行的呢？”
+
+**黄勇**：我在“组织架构篇”中提到过“职能团队”，该团队主管的职责就是帮助队员制定合理的&nbsp;OKR，目的就是帮助他们得到成长，只有队员成长了，主管才会成长。
+
+另外，每个人将自己的&nbsp;OKR&nbsp;制定完毕后，需要在对应的职能团队中分享，其他队员或主管可提出一些要求，修正或丰富这份&nbsp;OKR，可以将其看做是&nbsp;OKR&nbsp;评审，而这样的评审可以是正式会议，也可以随机探讨，可以一次也可以多次。
+
+OKR&nbsp;均由自己制定，并由职能团队评审，当大家觉得没问题了才算合理，其实这里包括两方面，一是个人的追求，二是团队对自己的期望。
+
+在[《CEO实话实说：我需要这样的CTO》](http://time.geekbang.org/column/article/5975)一文中，有读者问道：“您提到CTO需要有进化的能力，我理解就是学习能力，大家平时也都会学习，但多数是学了、理解了、用了，就完了，是否需要以学位、证书等方式加持呢？”
+
+乂学教育创始人栗浩洋：我说的进化能力，绝不仅仅只是学习能力。它其实更多的意味着一种自我摧毁和自我扭曲的能力，就好像老鹰要把自己身上的羽毛全部啄光一样；就好像一个打乒乓球的奥运冠军，要学打网球的時候，完全不能用自己过去的套路，不能用手腕，而要用整個腰身的力量一样。进化是要改变自己过去的思维习惯，完全变成另外一种物种。
+
+这个时候其实会遇到很多不习惯、不舒适甚至是痛苦的地方，当然也能从中发掘很多有趣的地方。所以我觉得学位、证书的加持只是一小部分，并不是必须的，重要的是他是否真的学会了知识、开拓了思维。甚至可能他只是完全的自学，或者是跟身边的人去学习，也能够完成进化。关键是他自己了解了新的知识，在进化到新领域时转变了一些旧有的思维、行为习惯，以及能夠驾驭新的环境。
+
+**结语：** 本期筛选了管理细度、研发流程、绩效考核、员工淘汰等多个方向的问题，希望作者们的回答也能解答你的疑问。
+
+感谢你陪伴“技术领导力300讲”专栏走过这四个月的时光，如果你对专栏有任何意见或建议，欢迎后台留言，留言被选中的同学将获得极客时间10元代金券。
+
+感谢你的收听，我们下期再见。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 余沛：打造以最佳交付实践为目标的技术导向.md

@@ -0,0 +1,95 @@
+<audio id="audio" title="大咖对话 | 余沛：打造以最佳交付实践为目标的技术导向" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/00/4d/001bd045bd541e3a0a0f8380e683164d.mp3"></audio>
+
+你好！
+
+本周作客大咖对话的依然是同程艺龙副总裁、研发中心负责人余沛，其在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代码时，会非常认真，会去思考还有没有优化的空间，如果有，团队就开会讨论能够优化的部分，再给出较为全面的优化建议。而不是大家一看反正代码也能运行，就很容易的给你通过。
+
+同样，对于交付也是如此，我们每一次内部评奖时，都会问候选人一个最终问题，即你的代码或架构的受益人是谁？他们获得了怎样的好处？
+
+这样造成的结果是，以前评奖时，很多人都会列举自己做了哪些特别厉害的技术，而现在，他们会自发思考，我做的事情最终会交付怎样的成果，能对谁产生怎样的价值，这就是文化潜移默化的魅力所在。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 余沛：进阶CTO必备的素质与能力.md

@@ -0,0 +1,91 @@
+<audio id="audio" title="大咖对话 | 余沛：进阶CTO必备的素质与能力" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/96/de/96066b430c7736d5e1062d3003af72de.mp3"></audio>
+
+你好！
+
+本周作客大咖对话的是同程艺龙副总裁、研发中心负责人余沛，其在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。还得让外面的优秀人才源源不断地跳入。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 刘俊强：云计算时代技术管理者的应对之道.md

@@ -0,0 +1,84 @@
+<audio id="audio" title="大咖对话 | 刘俊强：云计算时代技术管理者的应对之道" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d8/ae/d89aa6cfdb25d542ef5c2f6d53bfaeae.mp3"></audio>
+
+你好！
+
+本周大咖对话的嘉宾是腾讯云资深架构师刘俊强，曾任迅雷技术总监、某互联网公司技术副总裁，有着10年以上互联网开发经验和8年以上技术管理经验。之前，他与大家分享了2019年云计算的相关趋势，今天，我们将继续探讨这样的趋势对技术管理者有何影响。
+
+**极客时间：在您看来，面对这样的云计算趋势，技术管理者要如何应对呢？**<br>
+**刘俊强**：之前提到，2019年云计算的趋势主要体现在五大方面，分别是：云服务市场将继续增长强劲；混合云和多云（Poly-Cloud）将逐渐成为主流；自动化将不可或缺；合规性和安全性将受到重视；云服务将依然是新技术的最佳试验地。
+
+作为技术管理者，一般会负责技术团队组建与培养、技术规划与选型、成本优化以及前瞻技术调研等，那么根据职责来看云计算趋势对技术管理者的影响就比较显而易见了，简化而言主要会有以下影响：
+
+1.如何制定公司的云战略；<br>
+2.云服务的深入使用对团队的影响。
+
+在我们开始谈影响之前，作为技术管理者、技术决策者，首先需要明确业务上云的原因和需要，这里我整理了云计算报告里一些企业选择上公有云的原因，可以对比着来看看哪些是你同样在关注的：
+
+- 1.减少基础设施投资；
+- 2.资源扩展速度快；
+- 3.降低 TCO（总体拥有成本）；
+- 4.提高IT服务交付速度；
+- 5.更灵活地应对不断变化的市场；
+- 6.同业内已有典型应用案例；
+- 7.提升客户服务品质；
+- 8.政府或主管机构要求。
+
+**极客时间：您能具体分享一下如何制定公司的云战略吗？**<br>
+**刘俊强**：我们首先要明确的是，使用云是一种手段而不是目的，我们的目的是实现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 操作规范；云计算可以减少基础设施成本是主要优势之一，但是使用云计算需要更为精细地管理资源使用，才能够将成本优化最大化；深入使用云会对现有技术团队工作方式和文化形成挑战，具体内容在文章后面内容会介绍到。
+- 步骤四：构建云战略成功的能力，如果要成功执行制定的云战略，需要开发培养出一些跟云计算相关的能力。例如，云端安全加固、云计算资源选型及计费模型、云原生架构能力以及云端数据隔离等是保障云战略成功的必要能力。
+- 步骤五：做好团队变革准备，云的深入使用会带来组织上新角色的出现，流程的改变，甚至于组织架构的改变。
+
+云战略制定好后的具体实施需要进行规划和部署，这里有个简单的云战略路线图的示例图供参考：
+
+<img src="https://static001.geekbang.org/resource/image/8a/ed/8ace23d7e60b61000b4b11bc5fd50fed.png" alt="">
+
+一般情况下我们将云战略实施分为三个角色：
+
+1. 筹备组：负责整体云战略的规划与实施节奏把控，一般由各关联职能与业务线负责人组成；
+1. 技术实施组：负责整体云战略的具体实施，包括但不限于上云资源评估、应用系统架构改造、资源管理系统适配以及应用迁移上云等，一般由运维与开发人员组成；
+<li>支持组：负责云战略规划和实施中的支持性工作，包括但不限于 IT<br>
+资源采买模式变更、云安全审计等，一般由采购、财务以及安全专家等人员组成。</li>
+
+整体云战略实施过程一般分为以下几个阶段：
+
+1. 筹划与 PoC 验证阶段：该阶段需要明确云战略的目标以及计划，然后再进行概念验证，如云端实验工作室，让团队对云的使用更为熟悉和了解，该阶段的最后输出为云战略实施计划，并做好团队内部沟通与云战略公示；
+1. 云服务商评估阶段：该阶段根据自身业务特点对云服务商提供的产品进行测试与选型试验；
+1. 云战略实施阶段：该阶段需要根据云战略来评估安全风险、架构调整风险点等，并开始对系统架构进行调整、对运维管理系统进行修改、落实数据迁移方案等以适配迁移上云的目标，本阶段是整个过程中最重要的，也是持续时间最长的阶段；
+1. 总结阶段：该阶段主要对云战略实施的最终结果进行总结复盘，并根据企业业务需要和发展阶段，制定下一阶段的云战略。
+
+**极客时间：云服务的深入使用对团队有何影响呢？技术管理者要如何应对呢？**<br>
+**刘俊强**：云服务的普遍使用会给团队带来一些影响，正如我们之前提到的云管理控制、成本以及 IT 团队文化等常见的云挑战，当然这些挑战和影响跟企业使用云的程度也是有相关的，一般情况下将团队使用云的程度分为以下几个阶段：
+
+1. 观察者阶段：企业正在开发云战略和实施计划，但目前尚未将应用部署到云上，希望评估适合的云模型和云产品，并评估哪些应用和服务可以部署到云上。
+1. 初级用户阶段：企业正处于 PoC （概念验证）阶段，或是初始上云阶段，希望获取云计算使用经验以确定未来项目部署模式。
+1. 中级用户阶段：企业已在云上部署了多个项目或应用，希望扩大和改进云计算资源的使用。
+1. 高级用户阶段：企业已大量使用云基础设施，并正在寻求优化云运营和云成本。
+
+不同企业对云的熟悉和使用程度是不一样的，因此不同阶段企业的技术管理者面临的挑战和团队影响也将是不一样的，这里我简单用表格示意下：
+
+<img src="https://static001.geekbang.org/resource/image/4b/31/4b39954eefa49198ec2eba1c3ccaf431.jpg" alt=""><br>
+不难看出，随着云熟悉程度的加深，技术管理者们所面对的挑战和影响是不一样的，在观察者阶段和初级用户阶段，更多需要的是明确上云的策略和云产品的使用，这里需要技术管理者帮助团队学习对应的新技能，并带领团队沉淀下云的使用经验，以帮助后续项目或应用上云。
+
+到了中级用户和高级用户阶段，技术管理者们所面临的问题又不一样，在这两个阶段，会有更多的团队和角色参与到云的管理控制中，例如安全团队、财务团队等，而云端安全、云端架构与传统架构、安全会有差异，因此需要专门进行设计和评估。另外由于云端资源采买的便利性，如何界定是否适合采买、已有资源是否浪费以及项目独立核算等问题都需要财务团队介入。
+
+在变为高级用户阶段时，组织架构上甚至会产生类似技术委员会这样的组织，一般是云战略委员会，负责企业云使用的整体规划和设计，以及组织架构和流程改进等事务。
+
+另外在团队成员构成上，原先的架构师、安全专家及运维工程师等角色都需要对其进行云端技能补全，使其转变为云架构师、云安全专家和DevOps工程师，以使技术团队能更好地适应大量使用云后的改变。
+
+综上所述，我们不难发现云计算的大量采用对于技术管理者的挑战，不光体现在业务应用迁移上云的难点和风险，在团队云计算相关技能培养、组织架构等方面也面临不小的挑战，技术管理者需要保持清醒的头脑，对于自身企业的云战略有着良好的规划，以此为指引来应对这些挑战。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 刘俊强：谈谈我对2019年云计算趋势的看法.md

@@ -0,0 +1,76 @@
+<audio id="audio" title="大咖对话 | 刘俊强：谈谈我对2019年云计算趋势的看法" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/17/dc/172f0f236c9a3ea73d966f91e15d0cdc.mp3"></audio>
+
+你好！
+
+本周大咖对话的嘉宾是腾讯云资深架构师刘俊强，云计算经过最近五年产品能力的不断完善、云产品的持续新增和稳定性的逐步增强，使得大家已经能够广泛接受云计算的理念，并积极思考如何在自身业务中使用云计算。今天，我们主要聊了聊他关于2019年云计算趋势的看法。
+
+**极客时间：您能先简单分享一下您对2019年云计算趋势的理解吗？**<br>
+**刘俊强**：首先需要说明的是，在未特殊说明的情况下，我之后提到的所有云市场都指公有云市场，也就是我们一般所熟知的三类服务：laas(基础设施即服务)、Paas(平台即服务)以及SaaS(软件即服务)，另外还有一类是Gartner提出的BPaaS(业务流程即服务)。这三类服务的关系我就不在此赘述了，简单以下图做个解释。
+
+<img src="https://static001.geekbang.org/resource/image/7f/a3/7f51abc362f7e2880734ffeaa9a078a3.png" alt="">
+
+根据最近几年的技术发展和云计算行业的成⻓，我对于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%。
+
+<img src="https://static001.geekbang.org/resource/image/f9/8c/f9d853addebc0546946c89cec6f0df8c.png" alt="">
+
+<img src="https://static001.geekbang.org/resource/image/32/91/326ccb304e8759469b6b175ffd869f91.jpg" alt="">
+
+下面的图表则是中国信通院对中国公有云市场规模做出的预测，据预测，2019年中国公有云收入将增⻓36.2%，总额达到 521.1 亿人⺠币。
+
+<img src="https://static001.geekbang.org/resource/image/26/99/26effaec92d082dda7cf1924d5916b99.png" alt=""><br>
+过去几年，公有云市场的快速增⻓离不开企业对云的接受及使用程度的提升，根据 IDG 和中国信通院的数据(IDG 数据针对非中国地区，信通院数据针对中国)，目前非中国地区企业对云的接受程度如下:
+
+- 73% 的企业已使用云服务，另有 17% 的企业将在1年内使用；
+- 到2019年预计 90% 的企业会将应用放在云上，这一数据到2021年预计将为 100%。
+
+下图是由 IDG 调研的非中国地区企业对云服务的接受情况：
+
+<img src="https://static001.geekbang.org/resource/image/58/d8/58cac1468e2dee324a06b894833026d8.png" alt="">
+
+而据中国信通院的调研，54.7%中国企业已使用云服务，并成逐年增⻓的趋势。由此可以看出，不论是中国企业还是境外企业对云服务的接受程度都是在逐步提升的，而除了接受使用程度在提升外，企业的云计算预算也在增⻓，预算增⻓率可能保持到 30% 以上。
+
+随着云计算市场产品和解决方案的不断增⻓和完善，显而易⻅的是，2019年云计算服务市场依旧会强劲增⻓，并且云服务将对企业的协作和工作模式产生更深远的影响。
+
+**极客时间：您提到混合云和多云(Poly-Cloud)将逐渐成为主流 ，能详细分享一下您对此的看法吗？**<br>
+**刘俊强**：公有云并不是银弹，不是一种适用于所有类型需求的解决方案，不是全部企业都能够像 Netflix 那样将全部基础设施放在公有云上。对于具有特定需求的企业来说，全部基础设施迁移上云是一项极为艰巨的任务，而混合云模式提供了一种过渡的解决方案。
+
+混合云将现有的本地基础设施与公有云服务混合在一起，通过混合云模式，企业能够以自己的节奏来过渡到公有云，同时还能够保持灵活性与实施效率。目前还是有不少企业有自己的 IDC，通过混合云模式可以帮助企业在 享受公有云的弹性和产品能力的同时，还能够减少全量迁移的压力、降低过渡⻛险和总体成本，同时还能够进行灵活的私有云、公有云资源分配，2019年企业对公有云接受程度的提升，也势必带来混合云模式选用的增⻓。
+
+多云(Poly-Cloud 或 Multi-Cloud)则是近几年兴起的另一个概念，意指企业不将全部业务放置在一个云服务提供商身上，他们会根据自己的策略，将不同种类的业务分配给不同的云服务提供商， 例如根据云服务商的产品服务能力专⻓进行选择。有的企业则是根据云服务商与企业业务间的关系进行选择，还有的企业根据 “云不可知论” 追求跨供应商的可移植性。不论如何，多云的选用策略也将成为越来越多企业的部署模型，因为对于企业而言明显能够感受到的好处就有以下两点:
+
+1. 能避免单一供应商绑定，拥有更高的灵活性和成本优化优势；
+1. 供应商故障和灾难发生后，能最大程度保证业务可用性。
+
+但多云部署策略的选用并非全是好处，有些前置条件和问题也是需要注意的，比如需要企业技术决策者根据企业的长短期目标来进行云产品组合的规划。
+
+**极客时间：您之前提到了自动化、安全性等方面的趋势，能详细分享一下您对此的看法吗？**<br>
+**刘俊强**：首先要强调的是，自动化将是不可或缺的。随着最近几年微服务、Service Mesh 等架构设计⻛格被普遍接受和选用，容器服务也逐步成为主流，Docker 及 K8S 已经成为了容器和编排的实际标准而被众多企业选用。在我看来，公有云的容器服务将成为主流，因为容器技术可以帮助企业以一种快速、可靠、一致化的方式部署应用，容器和编排服务本身作为软件工具，也会有缺陷和安全⻛险的问题，而公有云供应商的云容器服务能够很好地帮助企业进行这些问题的解决和规避，因为他们拥有更庞大的集群规模和研发人员投入。
+
+不可否认的是，容器化改造不光是在部署环节的改进，实际上是软件或应用全生命周期的改造， 因此在架构设计、开发、测试及部署环节上都会有相应的改变。容器化改造、微服务架构设计⻛格选用等，都势必会造成应用系统的增多，增加开发、测试及部署的复杂程度，会带来应用系统的管理成本上升，所以如何在软件生命周期实现自动化、部署自动化以及云计算资源管理自动化是各个企业需要调研的问题。
+
+另外，企业将越来越重视合规性和安全性。举个例子，此前欧盟推出了 GDPR (一般数据保护条例)，旨在对欧盟公⺠的数据保护法律进行大规模改革， 所有向公⺠出售和存储个人信息的公司都不能对数据有太多控制。比如根据 GDPR 规定，数据收集者不能用隐藏默认的方式获取用户许可，必须提前进行明确的提示与询问，获得允许后才可使用用户数据；收集之后，需要为用户提供查看收集数据概览及用途，还需要具备用户删除功能等。
+
+不遵守规定的企业可能会面临欧盟严厉的惩罚。如果企业要在欧洲发展业务，必然需要考虑遵守 GDPR，除了公有云提供商本身遵守外，企业自身应用也需要遵守。而随着互联网近十年的快速发展，法律法规上将会出现更多的保护条例限制，因此合规性也将越发受到重视。
+
+在安全性方面，近几年 MongoDB、ElasticSearch 等勒索事件的爆发，安可以看出全漏洞每年是呈增加趋势的，而在选用公有云解决方案后，并不代表着就不会有云安全漏洞了，企业业务在上云之前做好云安全规划是非常重要的事情。云安全解决方案需要 IT 和安全团队采用新的操作模型，来减少上云后安全漏洞的产生以及漏洞产生后的范围控制等。
+
+**极客时间：在您看来，云计算理念的广泛普及，对新技术有何推动作用呢？**<br>
+**刘俊强**：简单来说，云服务将依然是新技术的最佳试验地。近几年有很多技术名词新产生或变得再次火热起来，如人工智能、5G、物联网、边缘计算以及无服务函数计算等。公有云不光是这些技术的试验地，也是这些新兴技术的关键推动因素，会与新技术形成很好的⻜轮效应，使得新技术能够快速地使用到应用中去，同时也将帮助新技术快速收集问题以帮其改进。
+
+比如，5G技术的到来，可以给物联网提供更多的应用场景，同时，5G技术提供了更快和更大带宽的移动网络服务，最终使得物联网设备或无人驾驶汽⻋产生更大容量的数据回传到云服务进行处理；而边缘计算，也就是在网络边缘进行数据处理以优化云计算，能够很好适应5G技术普及后的大容量数据回传和计算需求，通过边缘计算运行实时服务，简化来自物联网设备的数据流量，并提供实时本地数据分析，将核心数据和分析结果回传至云计算中心节点。不难看出，5G和物联网的发展，势必会带来云计算和云存储的使用增加。
+
+另外，通过无服务函数计算服务，可以不用虚拟机或容器就能够进行计算任务，当数据存储或数据连接在云端时，无服务函数计算允许开发人员在没有任何基础设施的情况下构建和运行应用程序服 务，帮助企业提高效率、减少工作量和成本，结合物联网、大数据等场景能够很好地简化开发与部署。
+
+总的来说，云计算会继续快速发展并最终像水电一样的便捷和基础，新的技术和解决方案也必将在云计算最先普及和使用，企业如何根据自身业务特点使用云计算来提升组织效能和竞争力，是接下来从业人员需要重点考虑的问题。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 创业就是把自己过去的经验快速的产品化.md

@@ -0,0 +1,53 @@
+<audio id="audio" title="大咖对话 | 创业就是把自己过去的经验快速的产品化" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/72/24/72c2a61018b57a441607f9c6a62f8b24.mp3"></audio>
+
+你好！
+
+本周作客“大咖对话”的嘉宾是经纬创投董事总经理熊飞。熊飞曾先后在腾讯和阿里巴巴担任产品经理，负责过腾讯网社区产品的设计及策划、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这些东西。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 如何打造自我驱动型的技术团队？.md

@@ -0,0 +1,65 @@
+<audio id="audio" title="大咖对话 | 如何打造自我驱动型的技术团队？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/45/b8/45061005e7f211a89cf3e8717954cab8.mp3"></audio>
+
+你好！
+
+本周作客“大咖对话”的嘉宾是青云QingCloud CTO甘泉。他拥有18年软件开发相关工作经验，曾先后在华为、IBM&nbsp;软件实验室、百度等公司任职，对Linux操作系统、网络、存储以及分布式系统架构、软件工程等方面有比较深入的理解。今天，我们和他聊了聊如何打造自我驱动型的技术团队。
+
+## 极客时间：以您的经验来看，如何做好技术团队管理，提升技术团队效率？
+
+甘泉：软件开发是一个创新密集型的领域，同时它的创新越来越多的来自工程师，而不是管理者。因此，作为技术团队的管理者，就需要顺应这个变化，转变自己的管理模式。
+
+**第一，要鼓励自我驱动。** 以前，通常是公司高层或领导者直接驱动，下面的程序员戏称自己是码农，领导让做什么就做什么。但现在，我们要鼓励他们的自我驱动，让工程师自己身体内部的马达转动起来，让他们自己考虑下一步该往哪里走，怎么才能做到最好？作为管理者，你要做的是设定一个目标，然后想办法让他们自我驱动的往前走，这是一个比较大的转变。
+
+**第二，要大胆放权。** 既然要鼓励自我驱动，就不能把程序员锁得死死的，所以大胆放权。坦白讲，不少管理者都非常在乎自己手中的权利，不舍得放权。但其实大可放宽心，因为你放出去的权利还是你的，你能放出去就还能收回来，所以大胆放权，这个并不会对你造成什么伤害，管理者要有这个心胸。
+
+**第三，要避免纯管理者模式。** 我见很多纯管理者，他们制定了公司的管理制度，他们会觉得之所以管不好，就是因为制度做的还不够好。我也认同，管理制度是有用的，但作为技术管理者，一定要想明白，如果你的公司都是能人、每个人都能非常高效的工作，那么你就不需要管理制度。
+
+你之所以需要管理制度，是因为里面有一些庸人，这些庸人总是犯错或偷懒，所以需要制度来避免他们犯错。但你制定越多的管理制度，减少庸人犯错机会的同时，你也是在惩罚那些能人，给他们树立了太多的条条框框，让他们动弹不得。所以，作为一个管理者，你在制定这些管理制度的时候，一定需要克制自己内心的冲动，不要去做扼杀创新的事情。
+
+举例来说，我们之前推出了分布式数据库RadonDB和分布式块存储NeonSAN，这两个产品就是比较典型的例子，都是我完全放权给了它们的负责人，由负责人自我驱动，最后打造出了非常优秀的产品。
+
+这里有两个关键因素，一个是幸运因素，这点无需避讳，能找到这样两个人是我的幸运。对我而言，他们比千军万马都要有用，这也是我常说的，有创造力的人要远比那些普通工程师有价值得多。
+
+另一个因素是，管理者有没有给他们创造一个能自我发挥的空间。其实，相关的事情他们之前在别的公司也做过，那为什么之前没有做成，在青云就做成了呢？总的来说，就是我们给予了他们合适的阳光、雨露、土壤，给了他们能发芽、成长、结果的环境，激发了他们的潜能，把他们从看上去很普通的技术人，变成了青云的Super Star，这是我作为公司的管理者需要去做到的。
+
+我一直很反对管理者驱动太多，因为在那种情况下，你实际上是在为你个人去管理，是在维系你的权利，并没有为公司的核心竞争力增长这个目标去管理，这两者之间有很大的区别。
+
+## 极客时间：您提到大胆放权，那如何确定放权对象呢？如何控制试错成本？
+
+甘泉：这个其实不是问题，首先，放权的前提是他已经获得了你的信任，而你信任他的前提，必然是他以往的表现足够好。其次，放权并不是说把事情丢给对方之后，就完全不管了，如果真这么做，那就是管理者的失职了。
+
+放权其实也是分阶段的，刚开始的时候，其实只是表示我准备好信任你了，但在你还没有真正做出成果之前，我们彼此之间的信任是有保留的。
+
+这个阶段，作为管理者，需要去了解他的项目进度、Review他的项目质量，Check他有没有On Schedule、有没有Off Track，这些在项目初期都是需要密切关注的。当然，如果出现情况，大家应该就事论事，公平的去讨论，取得共识。
+
+因此，说是放权，其实中间有很多实操的环节，实际上是付出了更大的精力的。
+
+之后等他们做出成果，证明他们值得信任后，那我当然就敢完全放权给他们了，就像我上面举的例子，比如NeonSAN这个产品，下一代该往那个方向走、下一个规划应该是什么样的，作为CTO我都听对方的，因为他已经值得我信任了。但是达到这个level的人不多，每一个都是公司最重要的资产。
+
+另外，我们并不会把资源完全往这些人身上倾斜，对于普通程序员，我们也会提供平等的机会。如果你有想法，我也会按照他们的标准给你创造一个自由的空间，看看你能不能抓住机会。
+
+如果你抓不住，那没办法，说明你能力还不够，可以待在这个层级继续练级，但有的人就抓住了机会，往上进入另一个层级。这样，青云的员工就慢慢沉淀出不同的层次，但这样大家是心悦诚服的，因为这个划出来的层级，并不是我指定的，而是大家自己争取来的，由大家的能力来决定的。
+
+所以，真正的平等并不是说在待遇上每个人均贫富，而是要给每个人相同的机会，机会的平等才是真正的平等。
+
+## 极客时间：据您的介绍，青云的环境能极大的激励技术人成长，那么培养出Super Star之后如何留住他们呢？
+
+甘泉：技术管理之所以难是因为你面对的是人，人是善变的，比机器要难管，但是这也有好处，因为人是有感情的。如果你给了他们机会，把他们培养成今天这样的人，他们会感谢你的。说他们会转身就走，我是不信的。
+
+就算他们被挖走了，就算拿到了比青云更高的薪水，但是成长空间呢？大公司一个萝卜一个坑，挖他过去，需要的就是他之前在青云练就的能力与积累的知识。一旦这些知识贡献给了他们，又没有青云这样自我成长的环境，很可能最后耗光自己的积累与价值。
+
+因此，我并不会像别的公司那样，把研发跟外界隔绝，生怕别人来挖。我反而会努力把他们培养成Super Star，同时努力把他们推出去，支持他们多去参加大会、去做宣讲，建立自己的影响力。做管理者还是要有胸怀。
+
+话说回来，那些纯粹为了钱的人也到不了Super Star这个level，之前就会离开了。所以我也不会在这些人身上花费气力，走就走，没关系，留下来的、沉淀下来的才是公司最重要的一批人，是公司整个文化传播的种子。
+
+## 极客时间：在您看来，技术管理者最重要的品质是什么？
+
+甘泉：管理者最重要的一个品质是要有确定性。何谓确定性？就是指，你作为管理者，不管你在还是不在，团队都会按照一个共识去做事情。就算你不在，大家也都敢放心大胆的这么去做，因为你给了他们确定性，让他们知道这么做是对的，大家能知道对错、知道好坏。
+
+最怕的就是管理者自身的不确定，因为大家会不由自主的去研究领导、去试探领导的边界，如果管理者不确定，那团队成员的精力可能就都放在琢磨领导身上，而不是琢磨事情上了。
+
+尤其是对于自我驱动的团队而言，领导的确定性对于下属有着决定性的意义，你不可能让员工自我驱动的同时，又要不断的琢磨你的喜好，这样他会很迷茫，不知道该往哪个方向驱动了。
+
+最后，如果你能确定性延续下去，就可能达到“无为而治”这样极高的管理境界，可能看着管理者什么都没做，但其实整个公司都在他的Control之下，按照统一的价值观做事。这样的团队，战斗力怎么会不高呢？
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 如何高效管理8000+规模的技术团队.md

@@ -0,0 +1,75 @@
+<audio id="audio" title="大咖对话 | 如何高效管理8000+规模的技术团队" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/61/56/613697700f8bf5c09f0eebda7d03f956.mp3"></audio>
+
+你好！
+
+本周作客“大咖对话”的嘉宾是苏宁易购IT总部执行副总裁乔新亮。乔新亮拥有16年企业架构规划设计和系统集成的工作经历，曾任IBM全球咨询服务部副合伙人，现担任苏宁易购集团IT总部执行副总裁，全面负责苏宁易购技术管理和项目管理工作，在苏宁转型的历程中，亲历了苏宁技术团队从上百人到8000人的急速扩张及发展。
+
+## 极客时间：苏宁现在的技术团队有8000多人，您如何管理如此大规模的技术团队呢？
+
+乔新亮：这几年苏宁一直在快速扩张，技术团队从四年前的1000多人，发展到现在的8000多人，到今年年底肯定会超过一万人。在这个快速扩张的过程中，涌进来了很多不同背景、不同水平的人，给管理带来很大的挑战。
+
+我们的做法是打造一个数据化管理体系，力争做到不管进来的人是什么背景、什么水平，都能顺利的融入到这个体系里面，能有发展的空间、能发挥自己的能力，否则就会很麻烦，会冲垮苏宁原本的团队、流程、文化等所有东西。
+
+而体系的基础是数据，整个业务、交易都要去做数据化。举例来说，今天，我们对每一个上到生产的服务都有管理，服务之间的关系也有管理，包括这些服务之间的契约是否清晰、每个服务的响应时间是多少等，全都被数据化，并纳入体系管理。
+
+我们会根据这些数据做宏观的把控，规划苏宁的前进方向，同时，我们也会把这些数据提供给各个团队，赋能给他们，让他们依据这些数据自我管理。
+
+总的来说，我们这些年一直在努力做的，就是把IT管理的对象数据化，并以此为基础建立体系化的技术管理机制，并把数据赋能给各个管理团队，让小到一个经理，大到上面的总监、总经理都能看到他们团队各方面的数据，然后以此为依据进行管理。
+
+到这时候，当体系真正搭建起来之后，团队是1000人和8000人就没有太大的关系了，我能管1000人，就能管8000人，甚至再扩张到上万人也没有问题。未来，我们还可能会把这套体系作为对外输出的苏宁云的一部分，甚至是其中的核心价值部分。
+
+## 极客时间：有了体系和数据之后，您具体是如何执行管理的呢？
+
+乔新亮：简单的说，就是产品化，一切以产品的维度来管理。当这些数据被汇集起来之后，会先汇总到产品，而不是人，因为产品才是更贴近业务、对用户或客户更有价值的东西。汇总到产品之后，再将评价数据具体分配到团队、个人，而这中间都依赖于此前的数据化基础。
+
+此外，苏宁的管理也从原来的偏向架构技术的管理，到今天所有的都围绕着产品和核心能力。具体来说，就是所有的内容，包括架构、稳定性、安全性、项目等都会汇总到一个产品维度去看，以架构管理为例，最终我要看的就是这个架构对产品有什么价值、能产生多少价值。
+
+我们在实践中也发现，这套数据化管理体系再加上相应的绩效管理，对整个团队的倾向性影响是非常大的，基本能做到指哪打哪。这样就可以做到在一定时间内聚焦在某些方面，把这些方向做到一定成熟度后，就可以相对弱化它，再去强化其他方面，这样公司整体就能一块一块地补上薄弱部分，最后形成一个优秀的整体。
+
+比如我们经常组织的稳定性月、安全月、用户体验月等活动，就是聚焦大家，让大家一起去着重提升某个方向。
+
+这点也是我觉得在管理中很重要的，就是一定要在一定时间内聚焦，不能铺得太开，否则一方面是研发团队忙不过来，也做不到极致优秀，就可能失去动力；另一方面，站在用户的角度，他们也没法看到产品特别明显的进步。
+
+所以，管理既要有完美主义，又要有不完美主义。从大处着眼，你得想得完美一点，规划得完美一点；从小处着手，你就得接受你在聚焦的点之外，系统还存在的不完美之处。而在这个过程中，管理者需要不停地用数据去衡量，看看当前的方向与进度是否需要修正。
+
+另外还有一个更大的好处在于，原来绩效考核可能是一个月甚至是一个季度的，现在变成了实时反馈，大家就知道自己该往哪个方向努力。这就像打仗一样，现在已经能指挥到单兵了，而且是实时指挥，这在过去没有数据化的时候是很难做到的。
+
+## 极客时间：在如此体系化的管理之下，如何激发技术人员的积极性呢？
+
+乔新亮：我之前谈到，所有的管理都得有数据，然后都得有评判，但评判不代表批判，一般的管理都比较倾向于惩罚，但我们希望用激励代替管理，尽量减少“管”的部分。
+
+比方说一个产品，原本是60分，极致的目标是100分，现在团队做到了80分，可以说它还差20分，但我更希望是鼓励他们提高了20分，如果他们真的做到了100分，那更是要大大地鼓励与奖励。
+
+我们希望在苏宁的技术管理体系里面打造一个激励机制，鼓励员工们不断向上，鼓励大家不断解决问题，不断提高自己水平。
+
+除了传统的激励措施之外，苏宁也在打造一个内部创业机制，每一个团队都可以申请以创业公司的方式去推进，也就是驱动型的创业生态。
+
+而什么叫创业公司，说的俗一点，他创业成功了，他就财务自由了。我们也是用一样的方式，比如说，顶层的，你的产品能够去占领市场，或者底层的，你的产品能为公司占领市场做出贡献，你就能不断拿到融资，不断拿到苏宁云的天使、VC、PE。
+
+以后可能大家的薪资构成就是月薪、奖金、股权和期权，也有完整的体系，相当于是拿着薪资在创业。这样做，除了能激发主观能动性以外，也会给团队以压力。简单来说，团队就是一个创业公司，而创业公司是有压力的，如果你把钱花完了还没有达到目标，那么你就是失败了，没什么可说的。而如果你成功了，你就能获得更多的资源，拿完天使拿VC，拿完VC拿PE，一直拿上去，相对来说会更公平。
+
+同时，这样的机制也能把更多的优秀人才吸引进来，毕竟我们可以给对方提供平台、基础设施、客户关系等各种资源，还可以提供资本支持，降低对方的创业风险，让他们可以在一个没那么紧迫的环境里好好打磨产品、实现想法。
+
+目前，这个内部创业机制我们还在完善，最终，我们希望能用投资代替管理，以此来解决整个激励问题。想想看，如果真的能把八千到一万个人的主观能动性激励出来，让他们觉得是在为自己拼搏，那一定会带来很多不一样的变化。
+
+不过也不能急，当这边的体系还没建立起来的时候，传统的管理肯定是要继续的，要慢慢的、有序的切到这边来。
+
+## 极客时间：在打造苏宁的数字化管理体系的过程中，您遇到的最大的挑战是什么？
+
+乔新亮：最大的一个挑战还是利益和信任问题。我们必须要承认，一个管理者他有好的地方，肯定也有不好的地方，这是很正常的事情，如果所有都很好的话，也就不需要管理了。
+
+所以，一开始说要数据化，把所有数据都呈现出来的时候，大家会觉得我的所有问题都暴露在了阳光底下，会被所有人都看到，会觉得不高兴，甚至会抵制。
+
+这个时候，作为最高管理者，你要打消大家的这种想法，不要让对方觉得你搞这个数据化是为了找他问题，而是要让他觉得，你的本质是想帮他成功、帮他把管理做好。
+
+所以，要想消解对方的抵触，改变他们的想法，首先就是要沟通，一定要跟对方说清楚讲明白这件事情对他们的好处。毕竟他们也是团队管理者，下面可能也带着几十、几百号人的团队，他们对管理也有痛点，而这个数据出来之后，对他们管理自己的团队也是有好处的。
+
+简单来说，就是要让自己跟他们站在一边，不要跟他们站在对立面，而是要表现出我给你提供数据、提供工具、提供手段，是来帮助你做管理的。
+
+其次就是一定不要先上绩效，要先出数据，让大家看到这么做的好处。一旦先跟绩效挂上钩，那么大家的反弹一定是非常厉害的，甚至会出现隐藏作假的现象。像之前提到的数据，一定要留有几个月的缓冲时间，让他们看到数据的好处，当基于这些数据，大家都有了实质的提升之后，再慢慢把它跟绩效考核结合起来。
+
+所以，管理者一定不要跟那些被管理的对象站在对立面，也不要高高地站在神坛上，而是要变成他们的盟友，要打心底里相信，我现在做的事情是对对方有好处的，是在帮助对方提升。
+
+至于之后真正收集数据、搭建系统的过程，我反而觉得只是项目推进的问题，真正难的还在于人心，在于如何建立这种信任机制，这一点，甚至比管理本身更重要。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 季昕华：以不变的目的应对多变的技术浪潮.md

@@ -0,0 +1,53 @@
+<audio id="audio" title="大咖对话 | 季昕华：以不变的目的应对多变的技术浪潮" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/49/c4/49e29f88aa469ea69a6f76cc4ed614c4.mp3"></audio>
+
+你好！
+
+本周作客大咖对话的是UCloud联合创始人兼CEO季昕华，他有着超过15年IT及互联网行业管理经验，曾就职于华为、腾讯、盛大，历任经理、副总经理、首席安全官、CEO等职位，曾全面负责腾讯安全体系建设、盛大云计算平台的研发及管理，对云计算、安全行业具有丰富的经验和深刻的见解。今天，我们和他聊了聊创业、技术管理等相关话题。
+
+**极客时间：您为什么会选择云计算作为您的创业方向呢？**
+
+**季昕华**：看过我的经历都知道，我原本是做安全的，但是创业的话，一方面觉得安全的市场不够大，未来发展空间比较有限。另一方面，我之前的工作中接触了很多黑客，他们技术不错，却只能通过写木马、写病毒谋生，所以想试试能不能给这些人提供一个好的环境，让他们能够通过技术合法的挣钱。而云计算正是这样一个方向，能够让每一个有能力写代码的人，都可以利用云平台的资源发展起来、挣到钱。
+
+我们公司的使命就是“用云计算帮助梦想者推动人类进步”。有很多技术人有很好的想法，也有很好的技术，只是缺少资源，我们希望能通过我们的服务帮助这类梦想者实现梦想。过去几年，我们支持的公司中，接近80%的都是这样的创业公司，其中很大一部分都已经成功了，而且现在规模越来越大。
+
+**极客时间：您觉得云计算行业当前的发展趋势是怎样的？**
+
+**季昕华**：云计算经过十年左右的发展，整体行业已经趋于成熟，但整个市场其实才刚刚开始。目前国内云计算市场规模已经突破千亿大关，但市场渗透率只有5%-7%，非常低，仍然处于相对早期的阶段。
+
+不过，当前市场正处于飞速增长的阶段，像我们公司基本上每年都能达到百分之百以上的增长。整体的客户规模也在不断扩大，以UCloud为例，从最初的游戏客户，到电商客户、O2O、互联网金融，再到现在的传统行业，如银行、医疗、政府等都开始尝试云计算，整体规模越来越大。
+
+至于云计算创业，云计算的概念一直非常火，我们2012年刚开始创业的时候，云计算领域的创业公司非常多，竞争非常激烈，但之后随着我们的快速增长，回过头去看，发现跟上的、留下的公司越来越少了。不管在哪个行业，公司是否能活下来，最关键的一点就是你能否为客户创造价值，其次是能否用好的、新的技术持续为客户创造价值。这两点是最关键的，一是能创造价值，二是能持续的创造价值。
+
+举个例子，我们有个客户是典型的电商公司，平时有很多电商流量，在618、双11等时候又有很多突发流量需要响应。它本身也有一些服务器，如果全面转向云服务的话，自己的服务器就浪费闲置了，对此，我们以他们的需求为驱动，提出了混合云方案，在接管对方服务器的同时，提供部分云服务，实现了业务的弹性，也提高了公司的整体价值。
+
+另外，我们还成立了UEP组织，帮助客户融资、找流量、做广告等等。我们是第一家帮客户在地铁里做广告的云计算公司，后来这个方式也被阿里和腾讯借鉴了。其实归根到底，我们做这一切的核心目的都是为了帮助客户，毕竟只有客户业务做得好了、赚钱了，他们才会愿意把钱花给我们。
+
+**极客时间：作为先行的技术创业者，您会给想创业的技术人哪些建议？**
+
+**季昕华**：我是技术出身的，在创业的过程中遇到了很多困难，踩过很多坑。现在回过头来总结一下，技术人创业首先要做好准备，我们都知道创业很辛苦，但实际上，创业只会比你想象的更辛苦，一定要做好心理准备。
+
+其次，技术人在创业过程中一定要发挥自己的技术优势。当然，创业不同阶段需要做的事情不同，当公司规模达到一定阶段后，你反而要放弃自己所有的技术优势，去做那些你可能不擅长，但又必须得做的事情，比如销售、市场、财务、投融资等。
+
+其实，以我作为创业公司CEO的角度来看，技术创业可以分为四个阶段。第一个阶段，做自己想做的事情；第二个阶段，去做那些不想做，但又必须得做得事情；第三个阶段：找到一群合适的人，去帮你做那些你不想做，也不擅长的事情；最后一个阶段，有机会去做那些自己内心真正想做的事情。
+
+目前，我还处在第三阶段，还在努力找一些合适的人，来做那些我不想做但是又必须做的事情。
+
+**极客时间：新技术、新模式层出不穷，在您看来，该怎样应对这不断变化的技术浪潮？**
+
+**季昕华**：技术一直在不断变化，每年都有各种各样的技术趋势出现，而应对技术浪潮，最核心的要点就是，变化的是技术，不变的是目的，这一点非常关键。
+
+在我看来，任何技术都是为商业服务的，所以我们要围绕我们的商业目的、商业手段去选择所需的技术。
+
+在互联网行业，一般产品研发有三种模式：第一种是技术驱动型，技术特别好，舍我其谁，只有我能干、谁也干不了；第二种是竞争对手跟随型，绝不捣乱，老大干什么、我就干什么；第三种是用户需求满足型，用户要什么、我就干什么。
+
+UCloud就属于第三种，公司存在的价值是为用户创造价值，当你为用户创造价值的时候，用户才会真正给你收益，你才能给员工回报、给股东回报，这才是一个完整的公司生态链。
+
+**极客时间：关于技术团队管理，能否分享一些您的经验呢？**
+
+**季昕华**：要做好技术团队管理，我觉得以下这几点比较关键：第一，要有一个比较大的梦想，这是非常重要的；第二，要让技术人员感知到，他们做的事情在直接对客户产生价值，让他们有成就感；第三，要坚持技术导向，让技术人员觉得他们能在这里学到东西，比如如何处理大规模的海量并发任务等，这些是技术人员比较感兴趣的。
+
+而技术人在转向管理的时候，面临的最大的问题就是思维上的转变。举个例子，某个问题自己几分钟就能搞定，但交给下属可能需要好几天才行，这时作为技术leader就一定要克制自己，不要亲自去解决问题，否则虽然对解决问题有帮助，但对团队管理却并无好处。
+
+这就是挑战所在，其实就是看你能不能放弃自己的技术优势，给团队机会，让年轻的团队按照你的方向和思路往前走，给他们带去成长，这样你自己才能有更好的成长。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 对人才的长期投资是人才体系打造的根本.md

@@ -0,0 +1,64 @@
+<audio id="audio" title="大咖对话 | 对人才的长期投资是人才体系打造的根本" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/6a/ed/6acb5774a5a41f56de11dca2eb64bbed.mp3"></audio>
+
+你好！
+
+本周作客“大咖对话”的嘉宾是Comcast全球副总裁、FreeWheel高级副总裁容力博士，在加入FreeWheel之前，他曾就职于雅虎和微软，具备多年技术管理经验，并在搜索广告、展示广告和视频广告领域拥有深厚的知识储备和业务理解。今天，我们和他聊了聊如何打造自己的人才体系。
+
+**极客时间：以您的经验来看，如何打造高效的研发团队？**
+
+容力：作为一家以技术创新为主要发展手段的新兴企业，我们在市场上面对的是全球顶级的竞争对手，因此，一支高效的有持续活力的研发团队是我们的竞争基础。我们会从以下几点出发：
+
+1. 优秀人才是打造高效研发团队的基础，因此，在招贤纳士时我们始终秉承“Hire the Best”的基准和原则。但Hire the Best 的难点在于，不能只看他现在会什么，而是要预测他将来是否能更快地学到更多。技术人的学习能力，其个人长期的潜质和潜力应该在面试环节得到更多的加分。
+1. 技术引领的创新是我们公司从创立伊始就一直秉承的公司文化，也就是工程师文化。我们认为这样的工程师文化，为我们营造了一种浓厚的技术氛围，能促使研发团队持续高效运转。
+1. 优秀的管理层是必要条件，我们鼓励从研发一线选拔出积累了丰富的实操经验、具备国际视野和深厚技术背景的管理人，从管理层面empower潜心研究前沿技术领域的技术大牛。
+1. 持续不断地优化流程，使其适应变化，结合project和squad模式对资源进行有效管理，并根据优先级合理分配资源。
+1. 管理层非常重视跟员工之间充分、开放地沟通。比如技术层面和商业模式层面的信息，都可以在领导层和员工之间做到充分的沟通和共享，使得员工能更好地把握整体方向、理清事情的优先级，做对公司最重要的事情。另外，大家做事都是本着平等开放的原则，不会因为说话的人不同，就对他提出的问题或者方案持有不同的态度，不因人废言，更不因言废人。这样做更能激发大家的积极性，充分发挥每一位员工的创造力。
+
+**极客时间：FreeWheel非常注重人才培养，那您能否分享一下FreeWheel的人才培养体系？**
+
+容力：对人才的长期投资是我们搭建人才培养体系的根本出发点，我将从人才招聘、人才培养、人才留存三个方面分享一下FreeWheel的做法。
+
+首先是人才招聘方面：
+
+1. FreeWheel有着自己的“文化基因”，我们始终鼓励技术引领创新，加上多年对行业的深厚理解和积淀，造就了今天的市场地位。我们所做的事情时刻反映着我们的理念，我们认为，理念和价值观的契合是十分重要的，在这个前提下，我们能为他带来什么、他能为公司带来什么、双方能否达到长期的互相认同——这三点是我们在甄选人才时始终在强调的。
+1. 我们认为人才培养是一个长期的投资，所以我们非常看重候选人的发展潜力，强调对市场和业务的理解。
+1. 我们看中人才的国际视野，我们的定位和立意是全球化，即我们研发的产品，是为全球客户服务的，而不是为某一个或几个特定的国家服务，因此，我们的技术团队、我们的员工必须具备国际视野。
+
+其次是人才培养方面：
+
+1. 我们为技术人提供技术路线和管理路线两条上升路径，两者并不互斥，他们可以根据自己的兴趣与特长选择适合自己的道路。
+1. FreeWheel建立了非常完备的培训系统，设有专门的培训团队，并划拨专门的培训预算。我们会为员工提供不同维度的培训机会，包括技术培训（技术分享、技术大会、专业培训、技术书籍等）、软技能培训（英文、演讲、领导力、沟通等）和业务培训（高端视频市场及广告业务方面）。
+
+最后是人才留存方面：
+
+1. 打造归属感和个人影响力。我们团队所研发的产品的每一个功能，都是客户迫切需要，并且能为他们带来明显收益的，因此每一个人的工作重要性和回报都显而易见，每一个人都在时刻对公司发挥着个人影响力。这样的高要求，加上十分紧密的团队合作、带FreeWheel“文化基因”的做事方式，最终会带给个人强烈的归属感。
+1. 轮岗制。加强全球各部门之间的沟通，加深工程师对不同区域市场的理解，是轮岗制设立的初衷。前面我提到我们很看重员工的国际视野，轮岗制正是建立和提升我们员工国际视野的有效机制。尤其是我们的轮岗不仅仅是在纽约和北京两地，也包括了美国西海岸以及欧洲，并且是多向而不是单向的。
+
+**极客时间：在您看来，好的技术团队组织架构是怎样的？不同阶段该如何做好规划？**
+
+容力：当一家创新公司从初创走向在市场引领者地位时，如何“不忘初心”，坚持以技术创新作为导向，保持企业的活力，是摆在管理者面前的一个难题。
+
+在我看来，一个高效的技术团队应该以任务导向为主，人际导向为辅，并需要具备以下特征：
+
+1. 目标和任务是明确的；
+1. 共同的行为准则是明确的；
+1. 如何衡量绩效是明确的；
+1. 决策是高效迅速的。
+
+此外，不同阶段，技术团队的侧重点也不同。
+
+首先是初创阶段，与所有初创公司一样，大家有明确的共同目标，组织架构和人际关系作为辅助手段的作用尚不显著。
+
+其次是百人规模阶段，100人是通常可保持稳定相互关系的一个阈值。此时，团队正式从“部落”进入到“村落”阶段，必须要建立两级管理制度，并明确分工。在这个阶段，团队之间如何协调会成为管理层必须关心留意的一个问题。
+
+接着千人规模又是一个新的阶段，FreeWheel现在就处于这个阶段，我们全球有约800位工程师，北京占300余人。此时的团队从“村落”进化到“城镇”，在管理中尤其需要注意以下几点：
+
+1. 需要不定期审视组织架构并对其进行优化；
+1. 为确保团队的高效，需保证团队上下对企业愿景和使命的理解高度一致；
+1. 保持竞争力（狼性），有些公司鼓励内部项目竞争，我们则希望通过别的方式，尤其是希望以技术竞争替代项目竞争达到同样目的，Hackathon是一个例子。
+
+**极客时间：在您看来，一个优秀的技术人最应该具备的能力或素养是什么？该如何更好的培养、锻炼这一能力呢？**
+
+容力：正如我之前提到的，优秀的技术人他应该要具备强技术硬实力、国际化视野、对业务逻辑和市场需求的理解力，以及扩散自身影响力的个人软实力。不过，对技术人才的要求是随着大环境的变化在不断变化着的，这一点是技术管理者在建立人才体系时需要注意的。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 张建锋：创业可以快而大，也可以小而美.md

@@ -0,0 +1,51 @@
+<audio id="audio" title="大咖对话 | 张建锋：创业可以快而大，也可以小而美" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/6e/48/6eef99884aab5b1872c7840229e6e148.mp3"></audio>
+
+你好！
+
+本周作客大咖对话的嘉宾是永源中间件共同创始人张建锋，原红帽公司JBoss应用服务器核心开发组成员，曾供职于金山软件、IONA科技公司，在分布式计算、企业应用设计、移动行业应用、DevOps等技术领域有丰富的实战经验和自己的见解。今天我们聊了聊技术创业的相关话题。
+
+**Q：您能先简单介绍下自己，以及您目前主要负责的工作方向吗？**
+
+**张建锋**：我的工作一直在技术领域，曾供职于金山软件、IONA科技公司、红帽软件等，2015年出来创业，负责公司的经营管理和技术方向的把控。目前，我们的主要业务是国内中间件技术相关的内容，包括产品、二次开发、咨询、培训，等等，下一步的方向可能是云计算相关产品。
+
+**Q：您为什么会选择中间件作为创业方向，当前的市场情况如何呢？**
+
+**张建锋**：我先回答第一个问题，选择中间件作为创业方向，有三个原因，第一，很简单，以往的工作经验都与中间件技术相关，对这个领域比较熟悉。
+
+第二，我们认为中间件在国内市场还未达到它应有的规模，国外做中间件软件的大公司较多，比如甲骨文、IBM等等，虽然这两大公司从操作系统、中间件、数据库到应用系统都有提供，但是中间件依然拥有非常重要的地位，甚至在21世纪初，中间件带来的收入占据了整体营收的大比重。我个人觉得，国内也应该有这样量级的软件企业，作为一个有技术追求的人，我们应该做这件事。
+
+第三个原因是，在很多企业项目中，中间件都占据重要的位置，但是国内的采购行业几乎都在用国外中间件产品，这其实是一个机会，国内也可以有这样的厂商能够提供优秀的产品和服务。
+
+第二个问题，对于中间件目前的市场情况，从微观角度审视，发展态势不是很好，但从宏观角度来看，仍然有较大的探索空间。
+
+在云计算兴起以前，国内的技术软件市场分三大部分，即操作系统、中间件和数据库，操作系统大家都很熟悉，比如Windows、Mac OS等，数据库有甲骨文、IBM等公司，而中间件是介于操作系统与应用程序之间的软件，我们在使用中间件的时候，一般是由一组中间件集合在一起，构成一个平台，而其中必须包含通信中间件，相当于中间件是平台和通信的集合。
+
+云出现以后，中间件的角色发生了一些变化，国内规模较大的互联网公司都有专门的中间件团队，而且目前很多云服务商提供的解决方案中就包含了许多中间件相关的内容，等于将中间件囊括进云的解决方案中了，亚马逊、阿里云等解决方案中都包含有消息系统相关的产品和服务，这原本都是中间件的范畴。
+
+尽管如此，中间件软件的价值依旧值得我们将其作为创业方向，只是面对云的冲击，我们不能固步自封，需要适应市场变化、调整方向，向着与云计算融合的方向发展，从这个方向中探索出更广阔的市场空间。
+
+**Q：在这样更偏技术软件的方向创业，您觉得需要注意哪些问题？**
+
+**张建锋**：我觉得很重要的一点就是要保证健康的现金流，现在大多数面向C端的互联网创业公司，都是选择先用融资的方式做大公司规模，再找到某个市场点切入并快速发展的模式。这样的模式风险会比较大，投资、融资是一种重要的资金流转方式，但当资本环境发生变化时，融资这条路就会受到很大的影响。
+
+坦白讲，互联网行业、软件行业、电子行业的成本都比较高，如果融资方面的供血不足，公司可能就会出现各种各样的运营危机。从公司运营的角度来讲，能够获得外部融资是一件好事，可互联网行业把融资看得太重了，好像没有融资就不会成功一样。我个人认为，我们创业时，可以把融资当作锦上添花，它能够帮助我们更快速的发展，但也需要考虑到没有融资的情况下，公司如何能够存活并健康发展。
+
+再者，一家创业公司最终能否成功，很大程度取决于它的商业模式是否成熟。能够将商业模式理顺，提供具有竞争力的产品和服务，同时保证健康的现金流量，这样，无论处于什么样的经济环境，创业公司都可以存活，甚至稳步向前发展。
+
+不过当前创业圈的现状是，很多创业公司都没有没有成熟的盈利模式，或者它的盈利点难以支撑它的成本，所以就会依赖于融资，希望资本的钱进来之后能够推动它先更快速的发展，等规模上来之后再找到盈利模式。但是，资本最终都要找到一个退出机制，如果在市场不景气的情况下，难以找到令人满意的退出机制，就没有人愿意冒险投资，创业公司赖以生存的资金来源自然也就断掉了。特别是在这两年，受市场大环境影响，整个投资环境都呈现出收缩态势，不少创业公司都受到了很大的冲击。
+
+另外，我们作为B端的技术创业公司，还需要注意的一点是，一定要耐着性子打磨技术，先打磨出一些领先性或具有独特竞争力的产品和服务。这可能跟C端的、面向用户的创业不太一样。
+
+以我们为例，我们在中间件这个领域有着多年的积累和领悟，能在此基础上打造出行业领先的产品。同时，相对国外的软件公司，我们对国内市场有更深的理解，能够按照国内市场的技术产品需求，做出针对性的改进。软件本身没有国界，但对于客户来说，不同国家、不同地区，都有着不同的需求，所以，即使是国外的大公司在国内做生意，多少还是会有一些水土不服，而我们作为本地人，更了解本地市场与客户的需求，提供的产品与服务也会更适用。
+
+**Q:作为技术出身的创业者，您对技术人创业有何建议？**
+
+**张建锋**：技术人创业并不是件容易事，但如果你选择创业，要么将注意力主要集中于技术，找一位非常合适的合伙人来承担技术之外的事情；要么自己走出舒适圈，既把控技术方向，又学着去管理团队、运营公司，接触各种各样的人，学习各种各样的技能等。这两条路其实各有各的困难与挑战，就看你怎么选择了。
+
+以我自己为例，我目前是既负责公司经营又把控技术方向，这样能够全面地了解创建和运营一家公司的各个方面。在我看来，技术很重要，但不是最重要，商业部分也很重要，这就需要我们向团队内外的各个角色学习，包括销售、市场、财务等，了解各方面的相关知识，同时也需要学会和人打交道，无论是对内部的团队成员，还是对外部的客户，我们都需要做好沟通。
+
+另外，目前很多媒体或投资者的口径是，好像创业只有一条路，就是一定要瞄准上市目标，追求公司快速发展，争做行业第一，争做独角兽。但其实创业并非只有这一条路，快而大不错，小而美也很好，你其实可以选择一个自己喜欢的技术方向切入，做到能在行业立足的规模，很多B端的或者跟地域关联比较密切的行业，都能提供这样的选择。这样压力没有那么大，也能在创业路上见识更多的风景，不断丰富自己，不断获得成长。
+
+目前我就处在这样的状态，能够在熟悉的领域比较自由的做一些自己喜欢的事，已经非常开心了。总之，如果你有想法，希望能做出一家行业数一数二的独角兽公司，那是非常值得敬佩的选择，但如果你只是想做一些自己喜欢的事，那找准方向，做一家小而美的公司也未尝不可。毕竟人生有着许多不同的选择，我们不能武断的说哪种选择就是对的，哪种选择就是错的。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 彭跃辉：保持高效迭代的团队是如何炼成的.md

@@ -0,0 +1,50 @@
+<audio id="audio" title="大咖对话 | 彭跃辉：保持高效迭代的团队是如何炼成的" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d1/05/d1655b88d1795e721dd4391d10d33305.mp3"></audio>
+
+你好！
+
+本周作客大咖对话的嘉宾是Keep CTO彭跃辉，曾于2010 年加入豌豆荚，从零开始搭建豌豆荚的应用搜索，打造最全、最准、最快的内容库。2016 年加入 Keep，搭建近 200 人的技术团队，带领团队快速迭代，通过内容、数据和智能打造运动的闭环，Keep 长期稳居健康健美的榜首。今天我们主要与他聊了聊搭建高效团队相关的话题。
+
+**极客时间：您能先简单介绍下自己，以及您目前主要负责的工作方向吗？**<br>
+**彭跃辉**：我毕业后加入豌豆荚，主要做应用搜索、内容库相关的工作，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。
+
+以上三点是我们对技术管理者的要求，如果技术人想走上管理路线的话，可以参考一下，有针对性的做一些学习和锻炼。

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 彭跃辉：解决用户痛点就是立足于市场的秘诀.md

@@ -0,0 +1,55 @@
+<audio id="audio" title="大咖对话 | 彭跃辉：解决用户痛点就是立足于市场的秘诀" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/66/e6/66f50941afc37180d9f464441fcd11e6.mp3"></audio>
+
+你好！
+
+本周作客大咖对话的嘉宾是Keep CTO彭跃辉，曾于豌豆荚从零搭建了豌豆荚的应用搜索，打造最全、最准、最快的内容库。2016 年加入 Keep，搭建近 200 人的技术团队，带领团队快速迭代，通过内容、数据和算法打造运动的闭环，Keep 长期稳居健康健美的榜首。今天，我们跟他聊了聊创业打造产品的秘诀，以及在AI方面的实践与探索。
+
+**极客时间：Keep在短短几年内成长为如今的明星产品，同时拥有极高的用户粘性，有什么秘诀吗？**<br>
+**彭跃辉**：相较于其他互联网 App，Keep一亿多的用户几乎都来自于自然流量，只有不到10%的用户是买过来的。其实，我们之前也复盘过，为什么能做到现在这个规模，主要有三个因素。
+
+第一点是定位，健身行业比较垂直，而运动与健康正是处于上升期的领域，Keep能稳定发展的原因很大一部分是源于健身行业的发展，越来越多的人对自己的身材与健康更加在意。
+
+第二点是解决用户痛点，我们做Keep的初心，就是为了解决用户的一些痛点。从这个角度来看，Keep解决用户痛点相较于其他产品更加深入。最初，我们定位于为初级的用户服务，这样能让更多人参与进来，从而沉淀更多用户数据，随着用户规模逐渐扩大之后，我们将整个内容体系做了一次升级，使它越来越专业，越来越体系化，并且持续不断的生产内容。
+
+我们希望能够真正帮到用户，举个例子，与传统健身房相比，说直白点，很多传统健身房是在挣那些不去运动的用户的钱，但我们的线下体验店是按次收费。从用户角度出发，体验会好很多。体验店现在还只有一种模式，就是小团课，但满课率及用户复购率都比较高。目前Keep这两个指标在整个行业中也是遥遥领先的。
+
+其实，Keep刚推出时还有很多竞品，但目前来看，在健身品类上，第二名、第三名与Keep的差距已经非常大了，这也证明我们在解决用户痛点这条路上越走越远，越来越好了。
+
+第三点原因是，Keep的团队比较爱学习、爱探索，一家创业公司遇到的问题会很多，在解决问题的过程中，我们的团队会主动学习，寻求突破边界。比如2017年第三季度，老板将之前APP的定位扩展为APP+硬件+线下体验场景的定位，用数据将三者串联起来，打造运动闭环。
+
+**极客时间：创业有苦有乐，您能跟大家分享一下自己印象最深的踩坑经验吗？**<br>
+**彭跃辉**：不同阶段的坑不一样，在早期，我们面临最大的问题是如何将产品做起来，那时资源并不充足，需要做很多取舍，最后只能比较粗放的将产品上线，导致后来花费了很长时间来还这些技术债，甚至是整个架构的重构。同时，在这个过程中，业务还得继续高速往前跑，我们形容这段过程是“在高速上开着车，还要给车换轮胎”。这个阶段最痛苦的就是平衡技术重构与业务进度，但想要将两件事情都做好，让二者并驾齐驱其实很难，这中间的纠结反复，现在想起来还是深有感触。
+
+然后在成长阶段，从外部数据看，Keep在健身领域已经有一定的领先优势了，这时，面临的问题是如何突破自己，但现实情况是，团队中大部分人都还没有达到突破的能力或者还未找到突破的方向。因此我们不管是品类扩张，还是探索不同领域都走了很多弯路。
+
+第三阶段的挑战是未来做什么，你必须找到下一个突破点和增长点。因此，我们开始搭建运动闭环，将之前APP的定位扩展为APP+硬件+线下体验场景的定位，用数据将三者串联起来，更好地为用户服务。
+
+硬件最大的作用是它和用户能有更多的触点，能够采集更多用户数据，比如用户戴着手表，交互的次数会更多，采集的数据也会更准确，帮助我们为用户提供更多更具针对性的指导。
+
+综上三点，第一阶段的挑战是从0到1将产品做出来，以及如何平衡业务与技术；到了第二阶段，已经在某个小领域成为了Top1选手后，面临的问题就变成了如何更好的扩张品类；第三阶段的问题是未来的发展方向。目前，我们处在第二阶段与第三阶段之间，既需要继续扩张品类，又需要探索新的突破点，因此当下最大的挑战可能就是接受更多不确定性。
+
+**极客时间：Keep与AI结合较为成功，能分享下你们在AI方面的实践与探索吗？**<br>
+**彭跃辉**：我先回答第一个问题，Keep的定位一直比较清楚，一方面要让更多人运动，另一方面是让更多人有效地运动。与AI结合的目的也是想让更多人动起来，但其实这件事有点反人性，为什么呢？
+
+因为很多AI的应用场景都是利用人性的弱点，使人更加沉迷，我们则相反，是想着怎么用科技手段，让用户在冬天也能运动，以及在运动时，产品如何跟用户互动等。
+
+我们将场景、内容、数据和算法这四个环节与健身领域结合。首先，场景方面，Keep走的比较靠前，无论是大型器械、运动设备等硬件，还是线下体验场景，都利用人工智能手段采集数据。而有了场景及更多的用户数据之后，就更加便于我们建设内容库和知识图谱。
+
+举个例子，我们会对场景数据进行收集，包括位置、室内和室外的温度、湿度、PM2.5以及天气情况等，然后可以根据位置推荐附近适合跑步的路线，或是根据天气给用户提供运动建议等等。将内容与场景结合，更好地服务用户。
+
+目前，我们的内容有两类，一类是我们的健身课程，是整个行业中较全、较准的一个内容库，另一类是用户产生的内容，比如用户的社区交互、运动后反馈提交的内容等。我们也从中收集用户数据，挖掘数据价值。
+
+基于这些数据，我们会先描绘出用户的行为画像，然后再与算法结合后做出精准推荐，比如APP上的智能训练计划，就是数据的落地，它会根据用户的用户画像，以及当前的运动情况，给用户推荐适合的运动课程。举个例子，很多女生会跳过俯卧撑这个动作，那系统就会针对当前用户的情况降低难度，将动作改为跪式俯卧撑，甚至扶墙俯卧撑。我们会根据用户的交互与反馈对这个课程的做相应的调整。
+
+除此以外，还有硬件与AI结合帮助算法落地，比如即将上线的智能运动手环，用户游泳时佩戴它，它会自动帮用户记录游泳距离、游姿等，未来也能够记录网球、羽毛球等球类运动的用户数据。
+
+**极客时间：另外，人工智能跟运动领域结合的话，未来的趋势是什么？**<br>
+**彭跃辉**：运动健身与AI结合的趋势有两方面，一方面是运动智能硬件，因为可穿戴设备能进一步拉近与人的距离，并且就目前来看，大部分穿戴设备都逐渐走向了运动健康领域。Keep在智能硬件方面也在持续探索，比如我们最近在做体感传感的尝试，用户在运动时，他们的动作会被投放出来，与虚拟教练做对比，从中可以看到自己的动作哪里不标准等等。
+
+另一方面在视觉方向，比如在Keep APP上有些入口，能通过用户身体的正面和侧面照片来识别用户的体态、体脂情况。测试结果显示的数据比大部分体脂秤都要准。因为体脂秤的原理比较简单，不同的人差别也比较大，而AI识别相当于先构建一个用户3D的身体情况，再计算腹部、腰部、臀部等数据。
+
+除此以外，AI可以从运动视频、人体图片中抽出用户动作的关键点，比如膝关节、肩关节等，从而了解用户在运动过程中的关节运动情况，判断用户动作是否标准。这一个方向我们已经有了探索，目前已经能在线下的场景提供给用户尝试使用了，不过因为对数据计算的要求较高，这个功能目前还未在APP上线。
+
+正如之前提到的，公司发展第三个阶段的挑战是要探索未来做什么，而人工智能正是当前非常显著也非常有前景的方向，因此，运动健康和人工智能的很多方向我们都在尝试探索。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 徐毅:如何提升员工的活力与动力.md

@@ -0,0 +1,47 @@
+<audio id="audio" title="大咖对话 | 徐毅:如何提升员工的活力与动力" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/07/b9/07949aae747ed0b0b446cf81496d11b9.mp3"></audio>
+
+你好！
+
+本周作客大咖对话的嘉宾是华为云DevCloud首席技术布道师徐毅，也是华为Cloud BU软件开发云产品部、华为研发能力中心特聘敏捷专家顾问，前IBM大中华区敏捷及DevOps卓越中心主管，前惠普企业服务资深敏捷顾问，前诺基亚移动设备敏捷及精益教练，前诺基亚网络全球敏捷转型中心精益及敏捷教练，拥有10+年行业经验。今天，我们跟他聊了聊如何提升员工的活力，以及他对敏捷的认知。
+
+**极客时间：您之前的采访中提到活⼒是让效率之轮滚动起来的动力之源，那在具体的实践中，该如何提升员工的活力呢？**
+
+**徐毅**：活力方面，首先要理解新时代我们员工的动力在哪里，我比较推荐咱们的技术Leader们可以学习一下丹·平克的《驱动力》这本书，作者认为适合现代知识工作者的驱动力3.0包括三个要素，自主（Autonomy）、目的（Purpose）和专精（Mastery）。
+
+先来看自主，我一般会举例说，如果一个人要做什么、怎么做都无法做主，那这个人就被管死了。作为中国人，我们可以回想一下自己的成长经历，尤其是中学时代，学什么、怎么学都没有什么可选择的余地，所以逃课的人很多。当然，怎么释放自主，也不是说马上把这些选择权给到员工就行了，就好比前面这些学生突然进入寄宿制大学就跟放羊一样，也是不行的，必须有个过程，这方面呢，我推荐参考下图中理查德·哈克曼（Richard Hackman）的职权模型，要逐步地培养自主能力。
+
+<img src="https://static001.geekbang.org/resource/image/93/7d/934d627a9b16f8043d5ed0d20831a97d.jpg" alt="">
+
+再来看目的，一个非常具体的小例子，就是我们平时大家交流需求，越大的组织越容易出这种问题。当基层员工拿到一个需求的时候，其实已经不是需求，而是一个开发任务了，他们可能都不理解这个任务为什么是这样的，但是当架构师或者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一员，我的个人感受是我们其实是为华为公司的愿景“把数字世界带入每个人、每个家庭、每个组织，构建万物互联的智能世界”服务的。而我们的切入点，就是云上开发。要构建这样的智能世界，软件开发会变得越来越重要，软件开发的企业和开发者是其中非常重要的一环。从某个角度来讲，我们是在致敬开发者，跟大家一起携手共建未来万物互联的智能世界。
+
+最后，在此感谢能够有这个机会跟大家交流。网络的交流，表达观点难以全面，如有问题或建议，欢迎给我留言交流，谢谢大家！
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 徐毅：打造高效研发团队的五个维度及相关实践.md

@@ -0,0 +1,68 @@
+<audio id="audio" title="大咖对话 | 徐毅：打造高效研发团队的五个维度及相关实践" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/3c/70/3cdff24c9ea467d37ac4fc0d311baa70.mp3"></audio>
+
+你好！
+
+本周作客大咖对话的嘉宾是华为云DevCloud首席技术布道师徐毅，也是华为Cloud BU软件开发云产品部、华为研发能力中心特聘敏捷专家顾问，前IBM大中华区敏捷及DevOps卓越中心主管，前惠普企业服务资深敏捷顾问，前诺基亚移动设备敏捷及精益教练，前诺基亚网络全球敏捷转型中心精益及敏捷教练，拥有10+年行业经验。今天，我们跟他聊了聊高效研发团队打造相关的话题，以及华为在这方面的相关实践。
+
+**极客时间：您好，能先简单介绍⼀下您和您⽬前主要负责的⼯作⽅向吗？**
+
+**徐毅**：感谢极客时间的邀请，很高兴能够跟大家分享我们在技术领导力方面的经验。
+
+目前，我在华为公司担任华为云DevCloud的首席技术布道师，以及负责我们的专家服务相关的工作，之前是在公司的研发能力中心负责团队及个体效率提升的研发能力工作。
+
+布道师这个头衔在国内可能还属于比较新鲜的事物，所以我先稍微介绍一下。DevCloud是我们将华为30年研发能力积累对外开放的一个出口，我们也称之为是软件开发云，从名字就可以看出来，它跟云有很大的关系。云计算近些年发展得很快，在云上进行软件开发相比以前在PC机上进行软件开发，研发的环境和人员的技能等各方面都发生了变化，当然，更大的变化是业务形态。
+
+由于有这么多的变化，对我们的主要受众，也即软件研发人员和企业来讲，DevCloud背后所承载的理念可能是一种颠覆性的理念，而这种理念的转变，对于更好地理解和使用软件开发云是至关重要的。布道师的工作，顾名思义，也就是去传播这种理念、思想，让更多人接触、了解和理解这种新颖的研发方式，学会和掌握使用我们的软件开发云产品。而专家服务，则是通过为企业提供更全方位的从规划到落地的完整的培训、咨询等各种服务，配合产品的使用，更顺畅地实现研发的转型升级，提升研发效率。
+
+**极客时间：关于打造⾼效的研发团队，可否分享⼀下您的实践与经验？应该从哪⼏个维度出发呢？**
+
+**徐毅**：先简单铺垫一下，我的经验来看，做任何事情，道法术器各个层面都不可缺。
+
+首先，在道的层面，我认为高效的团队和个人是提升研发效率的关键。这么说不是否认整体研发方法论的重要性，只是想强调，任何的方法论都依赖于基层执行人员的能力和纪律，所以说打造好基层的团队和个人是方法论生效的基础。比如前些年敏捷热门的时候，大家就很纠结说敏捷到底对人的能力素质有没有要求。其实我觉得这个事情很简单，如果把方法论比喻成算法，比如说加法、乘法、幂，那么1+1+1=3、2+2+2=6，1**1**1=1、2**2**2=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）教授的研究成果，选择从如下五个维度去提升研发团队和个人的效率：<br>
+1.活力：也就是人的动力动机，如果一个人没有主观能动性，我们给他们再好的方法、工具，恐怕都没有用，如果下面四个维度构成了效率之轮，那么活动这个维度就是让轮子滚动起来的动力之源；
+
+2.贡献：包括硬产出和软影响力多方面，主要思路是希望通过更好地汇集和展示团队与员工的贡献情况，一方面是提升员工的成就感，增强周边的认同，另一方面也是帮助员工观察自己情况、持续改进；
+
+3.能力：识别出我们需要具备的技能和能力项，持续地度量以及采取针对性的措施去提升技能能力水平，这会涉及到知识管理和应用方面的内容；
+
+4.管理：团队和个人的时间管理、工作任务管理等方面的管理水平，通过推广优秀实践、优秀工具等方法，来提升改进；
+
+5.协同：协同协作很难简单地说越多越好或者越少越好，都是要看具体的情况，但一定要减少不必要的协作浪费和投入。
+
+**极客时间：您提到从这几个维度去提升研发团队和个人的效率，那在具体实践中，你们是怎么做的呢？**
+
+**徐毅**：这些维度，我们在具体操作中，也有各不相同的方式。其中一种，是从时间记录和分析开始，也是前面提到过的，我们会在一些团队进行时间统计分析。然后就从最希望优化的时间入手，比如说，我们发现团队被打扰、被打断的情况很严重，严重到有的工程师戏称说自己是“白天抽空编码”，于是先在一些团队试点静默时间，固定上午或下午一个时间段是静默时间，IM工具下线，专心干活。
+
+当然，在开始静默之前，也都要告知周边团队和一些相关人员，让大家知道我们在这个时间段会静默。而且也建议团队选择一位联系人，在静默期间，处理紧急问题，可以隔一段时间再轮换。尝试之后，试点团队的反馈很好，所以后来这个实践也被大范围的推广，甚至有整个研究所、整个产品部集体静默的。静默时间能够给我们的工程师尽量的挤出一整块一整块的时间可以专心使用，但也一定要想好如何利用这块时间，以及如何做好紧急事件的处理计划。
+
+有些比较积极的团队，参与了我们的试点，安装了时间统计工具，运行在后台，统计不同应用程序消耗的时间，然后我们再把这个时间统计进行汇总分析，从中寻找改进的机会点。其实我们前面提到的很多问题，也都是通过这些时间统计工具得到的时间数据来说话的。
+
+改进方面，方法上，主要还是推荐时间管理的方法、技巧、经验，以及提供时间数据给（参与试点安装了工具的）员工帮助他们了解自身的情况。从影响范围更大的角度来看，更有效的，还是给大家推荐好用的工具。
+
+工欲善其事必先利其器，我们目前并不缺少好的工具，但可能很多人并不知道有更好的工具可以使用，那我们就可以根据得到的信息，定点推给具体某位员工，建议他/她可以使用某款工具。比如，某产品线在分析试点团队的时间数据时候发现，有的员工有10%的时间都花费在了“explorer.exe”（我们工作环境以windows为主）上。那员工使用文件资源管理器干嘛呢？极大可能是要在电脑里寻找某个文件，但是我们为什么一定要找呢，可以搜嘛，所以就通过邮件推送信息给这些员工，建议他们使用Everything软件。
+
+除了这类小工具，更重要的还是员工每天工作需要使用的作业工具。大家可能因为种种原因并没有使用最新、最好的工具，还有可能因为彼此的配置、环境等各方面的差异，而导致研发过程中浪费很多时间在集成、联调等环节。
+
+在这方面的问题上，我们发现云化研发这个场景还是有不少的优势，如果把大部分的研发工作都放在云上，而不是每个人的本地环境，那么一致性以及工具最新版本的升级等各方面的问题都会更容易解决。华为内部就有专门的工具团队，开发基于云化场景的研发工具链，从项目管理、需求管理到编译构建、流水线到部署、发布全流程打通，同一个研发团队或开发部的人员都在同一套云化工具链上进行开发。同时，在工具链的背后，是我们云化研发的方法论和能力在支撑。
+
+当我们把整个作业过程全部都放到云上之后，我们会发现能够更容易去度量一个需求的周期时间以及各个环节的问题，以此来牵引团队的改进。相比刚才讲的小工具，这个就是大工具方面的改进。我目前所在的DevCloud，可以简单理解为就是这套工具链和能力方法体系的对外输出版，感兴趣的话，华为云官网上就有入口，可以尝试使用。
+
+另外一方面，目前公司整体都非常重视优秀工程师的作用，强调搞技术也可以到很高的职级，在职业发展上铺平道路，还通过内部刊物等各种手段宣传介绍优秀工程师的事迹和经验，营造氛围，也鼓舞更多的工程师积极向上，磨炼自身的能力，加入优秀工程师的行列。也有部分研究所，在研究所范围内组织高效工程师的专属俱乐部，把当地的优秀工程师聚集起来，定期交流彼此的经验，也会邀请公司内部和业界大牛给他们开小灶，也在尝试是否可以在研究所地域层面给这些高效工程师提供一定的优待，比如专属的停车位等。还有一些产品部，对大家公认的高效工程师，会奖励机械键盘、大屏显示器、人体工程座椅、专用鼠标垫等各种优厚待遇，鼓励大家向榜样学习。
+
+在具体工作任务层面，有的产品部针对前面提到的老员工问题，在部门层面，把部分优秀员工，从PL团队拎出来，组成“首席工程师”团队，不在PL团队承接任务，而是在部门层面自行挑选工作任务，给予他们相当的自主性，可以自己选择去解决难题或者挑选自己比较感兴趣的工作任务，很好地激活了老员工的工作动力。
+
+公司各团队在这方面的积极性非常高，产生了很多的实践，我们内部还总结成册，出了这么一本“打造高效研发团队”的内部实践册，以供有需要的团队参考使用。也建立了内部的实践社区，供大家交流，补充最新的实践。也会有定期的内部大会，各研究所各产品部的优秀团队，大家会聚集在一起，分享各自的经验、交流学习。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 技术人创业前衡量自我的3P3C模型.md

@@ -0,0 +1,69 @@
+<audio id="audio" title="大咖对话 | 技术人创业前衡量自我的3P3C模型" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1e/d6/1e7ba964693cb82b8d69244655d0e2d6.mp3"></audio>
+
+你好！
+
+本周作客“大咖对话”的嘉宾是线性资本创始合伙人王淮。他是原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，坚持。** 创业是一件长期的、艰难的事情，可能你刚开始有创业想法的时候，会觉得阳光普照，每天都充满激情干劲，但等到真正创业之后，你会面对很多狂风暴雨，经历各种磨难考验。
+
+因此，在和创业者沟通时，我们会考量他在面对困难时的坚持能力，会通过各种假设，跟他们探讨未来可能遇到的挑战与风险，比如腾讯跟你做同样的事情你会怎么做等。
+
+这并不是我们对他或他在做的事情有多大的负面看法，而是我们很看重创始人、创始团队在面对这些困难的时候，体现出来的处事态度，比如是否能冷静的思考、是否拥有解决一切难题的自信、是否能做出相应的战略分析等。<br>
+&nbsp;<br>
+接下来再谈谈3个C。
+
+**第一个C是Crucial，决断。** 原来你当工程师的时候，你可能只需要把问题解决、管好自己的一亩三分地就行了。但创业不是这样，创业的时候，你必须把自己有限的资源，投入到最有机会让你成功的那个切入点中去。因此，你就必须要做全盘打算、必须要有取舍、必须要有决断。
+
+以员工为例，虽然对创业公司来说，一方面招人是个大难题，另一方面对方可能是从最初就跟随你的老员工，但当你发现对方已经不合适的时候，一定要有决断，要Fire Fast。
+
+**第二个C是Consistent，一致。** 这其实是人品方面的问题，老实讲，我们对创业者其实没有特别强的道德要求，只是希望他们能遵循一个最起码的底线就是言行一致，不能想一套、说一套、做的时候又是另一套。
+
+是，创业是一个战场，你可以采取一些策略去迷惑麻痹别人，但对内，跟你应该信任的对象，比如投资人、合伙人、员工等沟通时，就应该至少做到思言行一致。这是我们的要求，别小看了这一点，做起来还真的不是很容易，尤其是在面对那些利益相关的事情的时候。
+
+**第三个C是Credible，可信的。** 信用是需要很长时间积累的，也是一个很难的过程。但一个有信用的、靠得住的人，即使这次创业不成功，但从长远来看，也是迟早能成事的，毕竟不管是合作伙伴还是投资人都会更愿意跟这样的人合作。比如说合伙人，可能就因为他信得过你，他就愿意在你什么都还没有的时候，放弃其他很好的机会，跟你一起打拼。
+
+总的来说，这3P3C六个点是我们关注的最核心的东西，而前面5点最后都会体现在Credible上。我们跟创业者的所有沟通、交流，最后都是为了能在这六个点上对对方有一个深度的可量化的认知。
+
+## 极客时间：技术人创业时，找到合适的合伙人是非常关键的一点，那在合伙人的选择上，你认为有哪些权衡和考虑点？
+
+王淮：**第一，是知根知底。** 合伙人是一个非常长期的选择，一旦出问题就会很致命。你会天天跟你的合伙人聊很多各种各样的东西，可能你跟他待在一起的时间要比家人还多。这个人一旦选错，你就会郁闷很长时间，而且万一不成了要分开，造成的影响不比离婚来得小。因此，知根知底、互相信任是非常重要的。
+
+**第二，是互补性。** 对技术型的创业者来说，如果能找到彼此信任的、非技术偏商业的合伙人当然很棒，但如果没有，大家都是做技术的，那一个偏产品、一个偏技术，也是可以接受的，毕竟那种理想的互补型团队太难得了。另外，商业型的人才也可以等到之后A轮的时候再去补充，因此，第二点就没有第一点知根知底来得关键。
+
+而这两个权衡点就衍生出一个对技术人的要求，那就是技术人在平时工作生活中，应该尽量多做一些人脉的积累，要在平时的合作中，尽量去交几个知心的、能够互相认可的朋友。这里的认可不仅仅体现在具体做事上，还包括在平时的为人处世上。
+
+另外，技术人也要更Open自己，不仅仅要去接触技术、产品等比较容易接触的伙伴，还要多去接触些销售、BD、人事等方方面面的人。即使他不会成为你创业时的合伙人，但至少你碰到相关问题的时候，可以找到人商量。
+
+以投资人为例，其实平时投资人跟创业者的接触是很有限的，初期往往很难很快就达成深度的认可。但如果你们之前就有过接触，彼此已经认识了解对方了，那投资人产生信任的速度就会更快，确定投资的概率也就更高。
+
+虽然这对技术人来说不是一件容易的事情，但如果你有创业的想法，就一定要Open自己，一定要把门打开、广泛纳贤，汇集吸取多方的思考，毕竟创业这件事一定是不能把自己关在屋子里闭门造车的。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 技术人真正需要的是升维思考.md

@@ -0,0 +1,48 @@
+<audio id="audio" title="大咖对话 | 技术人真正需要的是升维思考" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/df/bb/dff45571a8c92ee94213943183b4b9bb.mp3"></audio>
+
+你好！
+
+今天与我们对话的嘉宾是七牛云创始人兼CEO许式伟。
+
+许式伟曾在金山、盛大等知名互联网公司担任重要技术岗位，从事核心产品研发。2011年，他与吕桂华一起创立七牛云，专注以数据为中心的公有云服务市场。此外，他也是国内Go语言实践圈子公认的Go语言专家，著有国内第一本Go语言图书《Go语言编程》。今天我们请他来聊一聊技术人怎样提升产品思维，以及如何把握商业趋势。<br />
+<img src="https://static001.geekbang.org/resource/image/7f/4e/7f09d1e43f712db482b98a608f10484e.jpg" alt="" />
+
+## 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 语言仍然会继续深耕服务端开发的生态，同时积极探索其他潜在的应用市场。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 技术管理者应该向优秀的体育教练学习.md

@@ -0,0 +1,41 @@
+<audio id="audio" title="大咖对话 | 技术管理者应该向优秀的体育教练学习" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/29/58/295778c465ed4ef02e8135c124ae5d58.mp3"></audio>
+
+你好！
+
+今天做客“大咖问答”的是Rancher Labs联合创始人及CEO梁胜博士。梁胜是耶鲁大学计算机博士，Java语言和JVM的领导设计与开发者。[2008年他创建了Cloud.com](http://xn--2008Cloud-8b7np1a800ab05bxsb.com)，因此被誉为“CloudStack之父”。2011年Cloud.com被Citrix收购，梁胜成为Citrix首位华人CTO。2014年，他创立了如今全球领先的容器管理公司Rancher Labs。关于如何衡量技术团队的效率和产出，梁胜表达了他的观点。
+
+<img src="https://static001.geekbang.org/resource/image/16/23/16261b702233d48c8f6d612fbb0fe023.jpg" alt="" />
+
+## 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年代就预见到将来家家户户都会拥有个人电脑，所以他去做了操作系统，这就是“做对的事情”。但是具体做事情的时候，他也非常关心细节。大家知道乔布斯也非常关心细节。所以能够把技术产品做到最好的人，都是对产品、技术、体验、质量这些事情非常在乎的，真的像一个教练一样，调教出了一批优秀的人，这些人现在也成了各大公司的领导者。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 未来技术负责人与首席增长官将如何协作？.md

@@ -0,0 +1,44 @@
+<audio id="audio" title="大咖对话 | 未来技术负责人与首席增长官将如何协作？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/27/ca/27e01d1a01c362c401a8a8071af370ca.mp3"></audio>
+
+你好！
+
+本周与我们对话的嘉宾是GrowingIO 创始人&amp;CEO、国家千人计划专家、畅销图书《首席增长官》作者张溪梦。
+
+作为前LinkedIn首位做变现盈利的数据科学家，张溪梦对于如何用数据分析来增加销售，促进产品的研发效率、做更好的风险控制等很有见解。本周，我们邀请他来和大家聊聊技术人创业，以及技术人如何利用自身优势帮助企业驱动增长。<br />
+<img src="https://static001.geekbang.org/resource/image/b8/66/b86cefb647fcf3b84012b7aa82c27d66.png" alt="" />
+
+## 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，然后到了机器学习、模型深度分析，在这一过程中，技术领导者帮助我更高效实现数据分析，从而产生更多商业价值。可见，技术领导者一方面把自己的产品服务赋能给用户， 另一方面就是帮助未来的首席增长官更高效的进行增长，而非单纯的产品研发。
+
+最后，对于技术领导者，只有具备更高的战略思维，善用技术与工具帮助企业驱动增长，做更多的创新与尝试，并将之产品化，要把价值交给更多人。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 李昊：创业公司如何做好技术团队绩效考核？.md

@@ -0,0 +1,62 @@
+<audio id="audio" title="大咖对话 | 李昊：创业公司如何做好技术团队绩效考核？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a3/74/a30aa55d932a89e261239d86f6f85c74.mp3"></audio>
+
+你好！
+
+本周作客大咖对话的嘉宾是满帮集团高级技术总监兼联席委员会主席李昊，拥有超过10年的技术管理经验，目前在满帮管理超过500人的团队。对于高速发展的创业公司而言，如何保证项目的按时保质交付看起来是对研发管理者的一个基本要求，但这背后其实需要织架构、流程规范、绩效考核和团队文化等各方面技术管理，今天我们就和李昊聊了聊其中如何做好组织架构和绩效考核这两个方向的话题。
+
+**极客时间：您能简单介绍一下您和您目前负责的工作内容吗？**<br>
+**李昊**：我工作后一直在外企从事研发和技术管理工作，在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搞不垮的团队和公司”，在实践中，主要有以下几个要点，供大家参考：
+
+<li>
+任何面向不信任员工设计的指标最好都不要有，比如前面提到的把工作时长和绩效挂钩。大部分人到创业公司是想做事的，不要把大家逼成上班的心态。
+</li>
+<li>
+先考察团队，再考察个人。我们会通过一些指标来衡量整个技术团队的能力，比如效率方面的上线次数，lead time，质量方面的MTTR，回滚次数等等，都有考察。个人绩效方面，我们是OKR结合KPI来做。OKR⾃底向上，体现个人成长的需求，主要影响职级，不直接影响绩效，是⽬标管理工具；KPI⾃顶向下，根据团队的性质不同，侧重点不同，决定了绩效考核结果，同时也直接影响职级和年终奖。
+</li>
+<li>
+这些指标要尽量的标准化，可视化，公开化。比如我们的团队指标是有专门的Dashboard的，因为只有可度量的才是可优化的。再比如我们个人的OKR也是放Confluence上互相可见，一方面这样可以让员工了解其他同事的工作和目标，另一方面这样还增加了团队的横向一致性。
+</li>
+
+这里讲了很多，主要是希望能够为其他的技术管理者提供一些在创业公司里进行组织架构和绩效管理的经验，作为大家进行这部分工作时的一个参考。毕竟，在一个公司里面销售等团队的绩效是相对比较容易衡量的，而产品技术团队的成本很好计算，价值却很难衡量，所以常常被划成所谓的“成本中心”。越是这样，就越需要有一套合理的组织架构，再通过科学的考核机制，用简单易懂，对日常工作侵入和干扰少的方式，通过数据来衡量和验证自己的价值。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 李智慧：技术人如何应对“互联网寒冬”.md

@@ -0,0 +1,57 @@
+<audio id="audio" title="大咖对话 | 李智慧：技术人如何应对“互联网寒冬”" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/99/60/99a177a01e2ff42c8c914b8ea8515460.mp3"></audio>
+
+你好！
+
+本周大咖对话的嘉宾是同程艺龙交通首席架构师、极客时间《从 0 开始学大数据》专栏作者李智慧，曾担任阿里巴巴技术专家、Intel 亚太研发中心架构师、宅米和 WiFi 万能钥匙 CTO，长期从事大数据、大型网站架构的研发工作。今天，他主要与大家分享了技术人如何成长，以及“互联网寒冬”下技术人发展与转型的选择等话题。
+
+**极客时间：在您的成长过程中，印象最深刻的一件事是什么？**<br>
+**李智慧**：在我的职业生涯里面，比较重要的一次机会是在 2006 年获得的，也就是十几年前。那时我在方正参与当时一个最热的项目，算是当时中国最大的软件外包项目，方正特别成立了一个部门去做这个项目。
+
+因为项目比较大并且比较新，部门也刚刚成立，最开始大概只有三五个人在做，但我们在中关村这边包了一层楼，规划是要把人坐满的。由于这是对日的项目，公司里面技术不错的都会派到日本去跟客户对接事情，其余的留在国内。在项目启动后，日本客户找了一家咨询公司给出了前端、中间服务器、后端的技术方案，大概三层的布局。有了架构，客户的需求也过来了，之后就是要考虑怎么把这个架构方案落地。那时我们每天在查资料、学习，但怎么去做、怎么把项目落地，一直没人去说。
+
+有一天我可能是比较着急，就去跟项目经理说：“这些技术方案，它最终还要落实成代码的。这个代码谁来写？框架间通讯谁来做？这件事情应该怎么推？”没想到过了几天项目经理找到我说“要不你来做吧”。当时我研究生刚刚毕业，经验也不是很多，但我很快就答应了下来。
+
+项目经理是周五找到我的，到周日晚上的时候，我就做出了一个基本的设计，把整个流程和开发视图画了出来。经过评审后，大家都说看起来似乎还不错，然后就开始按照这个架构进行设计开发。之后部门里面其他同事也参与到了整个框架和架构设计的开发中来，后来测试跑通以后，整个框架就算是出来了。之后项目按照原计划运转起来，上百个工程师都逐步招入进来，很快就把一整层楼坐满了。
+
+因为开发业务代码的时候必须要遵照开发流程和框架去做，而这个流程设计和框架是我带人做的，所以后面不管是测试还是异常处理，都要过来找我。把这个项目做完以后，我的心态也不再是刚毕业那样了。上百号人做技术决策的时候，都过来找你，这个时候你会有一种责任感，或者是有一种新的视角，这种视角跟以前在别人的框架约束下做开发是完全不一样的。
+
+这段经历，一方面让我从做开发到做架构，获得了新技能，做开发是在别人画的框里面去做你的业务，而架构是你站在全局的视角去思考问题。另一方面，是让我从另一个视角去观察和思考问题，很多关注的点和思考的点都是不一样的，比如看待一个新技术，我会考虑背后的设计和优缺点，以及为我所用时我要关注什么等等。这种视野给我带来的帮助非常大。
+
+当时这件事对我来说是一个机会，迈过这个坎，也就把握住了这个机会。成长的过程中，一定会有一些机会出现在你面前，有的看起来比较随机，就像我刚才讲的机会突然就出现在面前，如果当时我犹豫一点或者对自己不自信，放过这个机会，人生可能就不一样了。所以当机会出现在你面前的时候，要有勇气把握这个机会。
+
+**极客时间：在您看来，技术人怎样才能更好的成长？**<br>
+**李智慧**：技术人大都很忙碌，每天都在忙忙碌碌地上班下班或者加班，然后我就在想自己每天的工作到底在干什么。后来我总结了一下，做事情的时候可以分成两种角色：生产者和消费者。
+
+学习本身其实是一种消费，每天忙着去读书，看起来是在学习，但是学完以后你的生活和工作因此改变了吗？或者说有产出和输出吗？如果没有，每天的日子还是老样子，工作和生活也没有改变，这样的学习和玩一会手机、看一会抖音在本质上并没有太大的区别。所以一定要输出一些东西，比如你在公司里面做一个项目或者做一个产品，当然也可以写一本书，或者是在极客时间开一个专栏，总之就是你一定要有产出，让自己成为生产者而不仅仅是单纯的消费者。
+
+你要能够输出让别人消费的东西，这样你就会有成长，会变得不一样。我做事情的时候，总会想我到底是在做什么，是生产还是消费，是输出还是接收。如果我是在生产，大家是不是愿意去消费我生产的东西。比如在公司，我不仅仅是研究新的架构、框架和技术，我还希望自己能从头把它做出来。我希望其他人能够用我做出来的东西，希望自己在工作中是有产出的，这样我会更踏实一点，并且有产出，就会很有收获，也能很快的进步。
+
+**极客时间：很多人觉得90后员工比较自我，很难管，您是怎么看待的呢？**<br>
+**李智慧**：网上关于 90 后会有些言辞，觉得 90 后太自我，考虑别人太少，但我自己是很欣赏 90 后的。我的态度是，一个人如果不知道自己想要什么，那么也不会给别人想要的东西，这在公司里来说是不负责任的。你只有知道自己想要什么，对自己负责，才可能为公司创造真正有价值的东西。
+
+我想说的是，你要做自己的主人，要对自己负责。举个反例，我小的时候一直都是比较乖宝宝类型的，小时候听父母的，上学听老师的，工作听领导的。突然有一天，就是一瞬间惊醒：我这么听你们的，你们会对我负责吗，父母会养我一辈子吗，老师能保证我的将来吗，领导会让我在公司干一辈子吗？你如果不能对我负责，我都听你的有什么用。谁能对我负责？只有自己对自己负责。
+
+你要知道自己想要的是什么，你去付出你该付出的，然后得到你该得到的。比如去学习、去努力、去提高自己。如果你付出了以后，依然得不到，那就去寻找新的机会。
+
+你对自己负责，就是对公司负责，我一直以来都是这个观点。如果天天老板让做什么就做什么，等到最后事情没做好，就会觉得反正是老板让做的、反正是领导让做的，最后大家互相抱怨，根本没有意义。如果你觉得这件事情不该做、没有意义，那就跟他说不要做，这件事情没有意义的，我们有更好的办法。如果你真的有这样的想法，有这样的能力和实力，那就说出来，肯定会得到别人的认可的。这样对自己负责任，在公司也有主人翁的意识。
+
+**极客时间：很多人都认为现在是互联网寒冬，比较有危机感，您是怎么看的？**<br>
+**李智慧**：我加入阿里巴巴的那一年也赶上金融危机，我面试的时候问了一下，大家都在裁人，为什么阿里巴巴还在招人。当时的 HR 跟我说这是马总的判断，马总认为越是到了寒冬的时候，越要吸引优秀的人才进来，为了冬天过去以后，可以做好储备和积淀。我对马云还是比较佩服的，而且这个道理也很浅显，冬天一定会过去的，日子一定会好的。如果你在冬天的时候冻得瑟瑟发抖，那等冬天过去以后，你肯定还是那个老样子。
+
+在我看来，如果你觉得自己是努力的、优秀的、聪明的、愿意奋斗的那种人，那么寒冬对你来讲就是一次机会，因为未来一定会变好的。而如果你觉得寒冬淘汰的是你的话，那你肯定是会被淘汰的，寒冬就是淘汰掉那些投机的、不努力的、没有什么真本领却虚张声势的人。这其实是你的机会啊，把那些人淘汰掉，这个世界是留给你的，等到冬天过去，当一切变好的时候，这些最好的东西都是留给你的。
+
+另外想聊一下转型这件事，寒冬是你的机会，但寒冬不是你转型的理由，转型是一件时刻都在发生的事情，最主要的还是要去思考，哪些领域和技术是未来的潮流。
+
+我在 Intel 做大数据的时候，我们组里面有几个从 Intel 其他部门转岗过来的同学，之前是做 Linux 内核开发的，当时我觉得这个世界上写代码、做开发，最顶尖的可能就是开发操作系统了，而操作系统的内核开发，更是顶尖中的顶尖。我问他你之前做的是所有程序员梦想的工作，为什么要跑过来做大数据开发呢？
+
+他的回答是，Linux 已经非常成熟和稳定了，变化已经非常小了，他做了 3 年的进程调度和内核算法，向 Linux 社区提交了一行代码，还被拒绝了。这对他来讲是非常痛苦的，也不是一个好的兆头。那么未来在哪里呢？当时最火爆的是大数据，他们就转岗做大数据了。后来其中一个同学去一家专门做大数据的创业公司当 VP，另一位同学在一家快要上市的公司做大数据平台总监。
+
+我在极客时间上的专栏是关于大数据的，大家也可以关注一下大数据方面的潮流。如果你觉得这是潮流，这是未来发展的方向，是机会，你就去做。不用把它看得有多大有多艰难，别人能做到的，你要相信自己也能做得到。
+
+关于转型，我的另一个建议是不要被动转型。我还有一个做开发的同学，因为在意老板比自己年轻这件事，跳了几次槽，结果都不是很好。他以前也是非常资深的工程师，跳了几次槽之后，从开发转做咨询，也算是转型。他也抱怨说，这次转型真的是太失败了，实际上他转型的目标和理由，是要离开比他年轻的老板，这种转型是被动的，也不是很好的理由。
+
+但是人总是有出路的，后来这个同学不做 IT 了，出去开了一家鸭脖店，现在是整个上海地区周黑鸭最大的代理商，名下有将近 30 家的店铺，很让人吃惊。他这个转型转得更大，但肯定是痛定思痛想明白了，来了一次大的转型，反而很成功。
+
+所以，这个世界变化很快，转型真的是无处不在的。人们都在顺应这个时代在发展，你要主动做好这种转型的准备，而不是说因为寒冬，或者其他什么理由去转型。你要去看时代的潮流，从正向去转型，把握住方向，而不是走投无路才去转型。当然走投无路再去转，也是一种转，但是肯定是提前做好准备，并且自己思考清楚会更好。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 杨育斌：技术领导者要打造技术团队的最大化价值.md

@@ -0,0 +1,72 @@
+<audio id="audio" title="大咖对话 | 杨育斌：技术领导者要打造技术团队的最大化价值" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/24/cb/248c86a5e39bf576a74e4335554031cb.mp3"></audio>
+
+你好！
+
+本周作客大咖对话的是蓝盾CTO、信息安全专家杨育斌，目前主要从事信息安全、云计算、网络应急体系等领域的技术创新、开发管理与战略规划工作。先后承担国家级、省部级、市级科研课题40余项，获得国际发明专利1项，国家发明专利20余项。今天，我们主要和他聊了聊高效技术团队的管理理念。
+
+**极客时间：能分享一下您近期关注的领域么在信息安全领域，您比较关注哪方面，有什么新的想法？**
+
+杨育斌：目前，我比较关注智慧安全这个方向，如何用人工智能技术改变传统信息安全被动的局面，从而实现进一步发展。
+
+利用人工智能技术，帮助业务系统上云的同时，又能更好的抵御数据安全、网络安全、虚拟主机安全等主要安全威胁。
+
+人工智能强大的学习能力，在越来越多的数据面前显得游刃有余，而且越来越多的数据也对人工智能的自我学习和提升有很多帮助。利用人工智能技术，我们能更好的进行病毒样本学习，攻击特征学习，以提供智能的基础设施平台，更智能的进行攻击防护。
+
+另外，我也一直在关注构建大安全生态这件事。我们要做安全，但是不要局限在信息安全，而是要做大安全。在我看来，安全是一种能力，它会渗透并有机融合到云计算、移动互联网、物联网中，形成必须的技术能力与服务体系，最终嫁接到更大的IT生态体系上，发挥更大的作用，这也是大安全生态的力量所在。
+
+而且，对比国内外信息安全的发展比例、产品构成比例与盈利构成比例，差异非常明显。国内以硬件和软件产品为主，大部分的销售收入主要来自于硬件和软件，比如防火墙、入侵检测等产品，而安全服务的占比非常低。
+
+但在国外正好相反，比如在美国，安全服务的市场要比安全硬件和软件市场大得多。其主要原因在于，如今许多客户的资产包括数据、系统、网络，都在云端及各种智能硬件上运行了，他不再需要防火墙这样形态的安全守门人，不再需要有个软件跑在实际系统上了，他更需要的是安全服务，是专家型的安全服务，这也是目前蓝盾及国内许多安全同行发力的一个方向。
+
+**极客时间：可以分享一下您的技术团队与您的管理理念吗？**
+
+杨育斌：我们研发技术团队有六百人左右，虽然，团队规模在国内同行中不是最大的，但团队效率可以说是最高的。举个例子，去年(2017年)，我们在国内市场的利润达到了四亿人民币，平摊到技术团队，每个人的人均利润可以超过国内很多技术团队。
+
+我总结了团队高效率的原因，主要有三点：
+
+1. 发挥团队成员的个体潜力；
+1. 定时与业务单元高效沟通；
+1. 团队协同与组织优化。
+
+首先是第一点，发挥团队成员潜力。在我看来，一名技术领导者最大的使命就是激发团队成员的潜力，并且最大程度地将它发挥出来。包括在招聘人才时，我们也要想着如何发掘应聘者的潜力，我并不以招聘岗位的工作内容评判应聘者是否合适，而是发掘他的优点，判断他是否值得引进。
+
+举个例子，应聘者来面试技术岗位，可能他没有达到岗位要求，但我发现他口才很好，沟通能力很强。这时我会尝试将他培养成一名销售工程师，他只需了解一些技术基础、产品知识以及竞争性解决方案，并向市场和潜在客户进行有效传导灌输，也能够给公司创造价值。
+
+另外，我非常鼓励大家说出自己的新想法，只要对产品、营销有推动作用，都会获得相应的奖励，以此强调和推动公司内部创新合作的氛围。
+
+第二点是团队之间需要及时沟通，发现问题，解决问题。我们每两周会有一次沟通会议，保证业务与技术的定期对接。会议中，我们会根据市场的一线情报与反馈对研发等方向进行及时调整。这种小步快跑的模式是很多公司欠缺的，而我希望让我们的技术团队非常关注业务发展，注重客户的实际需求，所以我会保持这种每两周一次的沟通节奏。
+
+第三点是注重团队合作，当团队人数达到一定数量，都会遇到内部合作问题，因为大团队之下，每个小团队可能都会对自己产出的东西存在一种保护意识，而这会导致内部之间的合作出现隔阂。
+
+我们的方法是打破藩篱，共同协作，灵活利用资源。比如共建组件库，我们有一个专门负责技术资源整合的团队，整合所有研发团队能够公用的组件，提高效率。如果一个小团队需要爬虫组件，他们可以直接在共享组件库中寻找，只需对组件做一些修正、优化工作，就可以实现运用，省去了他们重新开发的时间与精力。并且，他们还需要将优化后的组件重新上传至共享组件库中，方便别人再次取用。这也是我们在人员成本降低后，效率还可以继续提高的原因之一。
+
+**极客时间：您对技术领导力有怎样的认知？**
+
+杨育斌：首先，技术必须与业务配合，才能够为公司创造高价值，片面强调技术领先，脱离业务实际，并不是技术领导者应该去提倡的做法。直白的说，技术领导者不能光想着怎么烧钱，烧出一个技术领先来，也要想着怎样为公司创造价值，在最少成本的情况下为公司创造最大价值。
+
+其次，我认为，领导力可以理解为教练，或是团队的鼓动者，作为技术领导者，必须不断地鼓动团队战斗力，推动公司业务发展。比如公司已经上市，进入平稳发展期，可能会遇到团队中一些核心成员开始懈怠的问题，此时，作为技术领导者，就需要调动他们积极性，同时，要去思考如何在外部寻求更多的资源来为公司增添新的动力。
+
+因为企业在经营过程中，一定是追求成本最小化和效益最大化的，团队氛围松散，业务停滞，一定不利于企业营收。而科技公司的人员成本又高，所以，如何充分运用团队能力，生产更大的效益，就是每个技术领导者需要思考的问题。
+
+**在我看来，作为一名技术领导者，必须具备两个基础能力：**
+
+1. 勤于思考，保持敏感。比如，当公司已经解决温饱问题，进入下一个阶段时，可能会出现两种情况，一种情况是，安于现状，满足于过往的成就，认为沿着目前的步伐继续前进就行了。此时，技术领导者需要保持对技术变革的敏感，做好准备，思考下一步的方向。
+1. 面对未来，拥有危机意识，每个企业，都会在平稳、顺利的时候，放松警惕，此时一旦松懈就可能被对手，或市场的新兴力量超越。对于这点，过往的案例不在少数。
+
+所以，技术领导者必须在不同的阶段有不同的思考，思考如何保持目前的积极状态，或如何能够继续前进，应对未来的各种不确定因素。
+
+在此，对于一些有志成为CTO的年轻技术人，我也想说说我的建议。
+
+首先，必须一步一个脚印，稳固自己的基础。其次，不断学习，拓宽自己的知识面，你要从专才变成全才，除了学习技术，还要学习业务、运营、管理、投资、融资等诸多方向的知识。
+
+然后，想法要多，更要胆大，为什么有些公司最终没能再向前一步，就是因为局限于自己的思维、局限于自己的技术架构、局限于市场保有率中，没能进行突破。作为一个技术领导者，你一定要思考如何突破，如何再进一步。最后，要快速将自己的想法落地，再根据结果反馈，快速迭代。
+
+**极客时间：您认为技术类的公司在面向公众传播时，应该怎样打造企业的技术影响力？**
+
+杨育斌：我认为最重要的一点是需要承担一定的社会责任，具体做法包括两点：
+
+第一，正确表达技术所能带来的变革和进步，技术的变革是必然趋势，传统企业也会在技术变革过程中打磨自己，适应新的时代。
+
+第二，不要将技术神化，给公众制造焦虑与恐惧，以我所在安全行业为例，遇到信息安全事件，有些公司为了显示自己的技术高深，会将事件夸大，而这样的行为就违背了技术推动社会进步的意义。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 池建强：做产品不要执着于打造爆款.md

@@ -0,0 +1,106 @@
+<audio id="audio" title="大咖对话 | 池建强：做产品不要执着于打造爆款" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/22/56/22ad3ae9398aa6194416944551304c56.mp3"></audio>
+
+你好！
+
+本周作客“大咖对话”的嘉宾是池建强，现任极客邦科技总裁，从零开始打造了IT类知识服务产品极客时间。加入极客邦前，曾服务于洪恩软件、用友集团和锤子科技等公司。
+
+**极客时间：根据您的观察，技术人创业容易踩哪些坑？**
+
+**池建强**：技术人创业其实就是跳出技术的圈子，从另一个维度，比如产品、商业模式上去寻找更多的可能性，这个过程同样充满挑战和乐趣，创业的时候要专注在这个过程上，而不是技术领域。在不同的阶段使用合适的技术解决相关场景的业务需求，创业者需要的不是炫技，而是提供能够为业务服务的技术。
+
+人们常说，一件商品最重要的是质量，但是提高产品质量最关键的是精准的把握用户需求的本质。否则，无论产品质量多好，功能多么丰富，如果不是用户需要的，那么这个产品就是不成功的，是某种程度的自嗨。技术也是同样的道理。
+
+另外，在领域的选择上，技术人容易根据自己之前的经验选一些看起来是降维打击的创业方向，也容易掉进自己的思维陷阱。
+
+很多朋友做烦了 toC（面向普通消费者）的产品，认为 toB （面向企业）是个大市场，一头扎进去也会发现很难，不仅仅是客户难伺候，个性化和通用软件也会不停的打架。规模化还是 Case by Case ，都是艰难的选择。
+
+有些人则烦透了企业客户，开始做 toC 的创业，也难，因为 toC 的产品做出来容易，用户认可和规模化则是个大难题。数据增长和日活是很多 toC 产品迈不过去的坎，转化和收入也更是让人焦虑不已。
+
+有些人适合做 toC 的产品，有些人适合 toB，这个需要每个创业者自己去探索和选择。我自己喜欢做个人消费者的产品，更有意思，更挑战，也更平民化。
+
+有朋友问我，哪个更容易哪个更难呢？天下没有容易的事，都难。重要的是你的选择和坚持。
+
+另外，创业和在大公司打工不同。大公司资源丰富，你做到总监级别，很多琐事是不需要关注的，公司作为平台会提供你想要的各种资源，你只需要专注于某个领域进行突破就好了。有时候这种平台之上的成功容易造成一种错觉：原来我真的很牛！
+
+其实并不是这样，平台隐形的力量不可忽视。一旦开始创业，财务、行政、市场、运营方方面面的事情都需要创业者去操心，可谓事无巨细，也许员工的座椅都需要你决定用哪个牌子。这时候就需要找到能和你互补的合伙人，把自己不擅长的事情交给别人去做，自己去做最擅长的业务和产品。
+
+发挥自己的长板，让别人补足你的短板，这就是现代的木桶理论。
+
+**极客时间：您创业至今，从零开始打造了极客时间这一产品，在这个过程中，您最大的挑战和收获分别是什么？能以具体事例来辅助阐述么？**
+
+**池建强**：从零开始做一个产品是非常独特和有价值的事情，事实上很少有人能从头开始参与一个产品的构建过程。有的人是中途加入，有的人是整个平台已经成形之后添砖加瓦。我个人能够主导极客时间这个产品，实在是一件幸运的事。
+
+在打造产品的过程中会遇到各种各样的问题，如何组建团队，如何选择技术体系，如何进行产品定义，如何首次发布产品，如何迭代，如何触达你的用户等等，限于篇幅，我简单介绍几个感触比较深的点。
+
+## 1.不要想打造爆款产品
+
+首先，每个产品的出现都有原因和相关的背景。公司愿意投入人力物力去研发一款产品，自然希望产品一发布即大获成功，比如：在发布产品的那一刻，你会觉得，如果你的手指向苍穹，就能看到电闪雷鸣；你登上山峰，千年的冰雪就会融化成水；你走上舞台，就会有千百双手在挥舞……但事实是并不会这样。
+
+大部分情况下什么都没有发生。爆款产品是因为真的“爆”了，才被叫做爆款，很少有人开始的时候就说要打造爆款，因为说了也没什么用。大部分产品都是一点一点长起来了，微信也不例外，只不过由于腾讯的用户体量，微信的起点更高罢了。事实上很多爆款都是黑天鹅事件，而黑天鹅事件是可遇不可求的。
+
+## 2.一个成功产品有其增长曲线图
+
+那么一个成功产品的增长曲线是什么呢？大概是这样的：
+
+发布，获得初始用户，拉起一条增长曲线，然后失去新鲜感，数据下降，保持在一个低水平线上，反复迭代，挣扎，试错，找到真正的用户需求点，很多产品在这个阶段就死掉了，活下来的继续前行，直到找到那个数据上扬的拐点……
+
+<img src="https://static001.geekbang.org/resource/image/7a/e5/7a6764841d552d4fb2ffba6ae8f1ede5.png" alt="">
+
+知道了这一点，我们就不用苛求自己的产品上线后马上一飞冲天。从心理上接受这个事情，我们就能更加从容自由地去迭代和尝试。正如 Airbnb 创始人 Brian Chesky 所说的那样：“如果你的产品发布后没人买账的话，那么不妨再发布一次。”反正你是小公司，没人关心你的产品到底发布了几次。
+
+产品发布之后，一般会有一个数据拉升的曲线，之后就是不断的迭代了。迭代就涉及到功能和版本规划，极客时间初期版本基本上是没有规划的，1.0.0发布之后，需求和用户反馈即扑面而来，我们只能且战且行，临时计划，随时发布。两周之后，差不多有了比较细致的计划，一月一个大版本，一个小版本，迭代着往前跑。
+
+有计划就行了吗，并不是这样，因为计划赶不上变化，甚至很多变化是不可控的。
+
+## 3.计划赶不上变化
+
+在做产品的过程中我们会遇到各种意想不到的问题，比如产品延期，人员变动，产品特性用户不买账，甚至你计划好上线的运营活动会因为苹果不给过审，白白等待两个星期错过最佳时期……
+
+遇到变化怎么办？分析问题，解决问题，根据用户的反馈做出更好的解决方案，复盘，打样，然后再次制定计划和执行。
+
+有人会觉得如果总是变那干脆不要计划了，这也是不可取的。邱岳老师在他的产品专栏里说过，没有任何作战计划在与敌人遭遇之后依然有效，但做计划的过程依然是必要的。缺乏计划会让产品失掉节奏感，员工失去方向，并且很难专注。计划制定的过程，本身是一个制定战略，统一思想，上下齐心的过程。也就是说，大家要登船渡海，扬帆起航了，得弄个罗盘，定好灯塔，然后再出发，这样在行进的过程中，无论怎么折腾，总的方向不会有大的偏差。
+
+## 4.遇到挫折怎么办？不要有侥幸心理
+
+我们在做系统开发的时候经常会遇到这样的问题，生产系统好好的谁也没动，也没有大的流量进来，一切都有条不紊，然后系统突然就挂了。这时候我们会下意识的以为是偶然事件并祭出杀手锏「重启试试」。重启能够撑一阵子，但是很快又挂了，往返几次，工程师们才会意识到是真的出了问题，开始从代码和日志中寻找蛛丝马迹。这种情况常有发生，一般是因为数据或流量突破了某个边界，或者设计的时候没有考虑某种状态的变化。你只有找到了真正的原因，才能彻底解决问题。
+
+记住墨菲定律，当你认为要出问题的时候，就一定会出问题，决不能有侥幸心理。
+
+## 5.寻找外援
+
+程序员解决研发中碰到的问题喜欢钻牛角尖，看起来不达目的誓不休，但你可能解决的是个陈旧的问题，别人早就解决了一千遍，你搞不定只是因为你不知道而已。所以，当我们被某个问题卡了很久的时候，就该去寻求帮助了。这种帮助可以是公司内部的，也可以是公司外部的。
+
+我们在开发这款产品的过程中得到了很多朋友的帮助，得到、知识星球、微信、微信读书的朋友，他们都给了非常好的意见或建议。这时候有人就会问了，你这是有资源，我们没有资源怎么去找外援呢？
+
+要知道创业者的资源也不是从天下掉下来的，而是付出自己的时间和资源置换的。如何获取资源呢？
+
+- 一，打铁还需自身硬，你自己得有真本事。
+- 二，把自己知道的东西分享给别人。我经常会获得一些陌生人的帮助，问起原因，说是 MacTalk 的某一篇文章对其有极大的帮助。说实话我已经记不起是什么文章了。
+- 三，构建健康的社交圈子。有些人能够成为生死之交，有些可以成为朋友，有的人能在关键时候能够互相帮助。不要太计较得失，在有可能的情况下尽最大努力帮助别人。
+
+资源是相互吸引的，你想要资源，首先自己也得有资源，否则你有什么资格免费获得别人的帮助呢？
+
+**极客时间：现在有不少观点是技术人要具备产品思维，您能分享一下您的观点么？具体落地的话，该怎样提升产品思维呢？**
+
+**池建强**：技术人学习一些产品知识，对自己有百利无一害。
+
+工程师如果对产品很有感觉，和产品经理沟通起来会更加顺畅，而不是你说什么我就做什么。在很多互联网公司工程师都具备很强的产品思维，甚至一些技术产品本身就是工程师主导研发的。
+
+还有一些技术人会直接转成产品经理，腾讯的马化腾就非常推崇技术出身的产品经理，他说：
+
+> 
+产品和服务是需要大量技术背景的，我们希望的产品经理是非常资深的，做过前端、后端开发的技术研发人员晋升而来。好的产品最好交到一个有技术能力、有经验的人员手上，这样会让大家更加放心。
+很多产品经理对核心能力的关注不够，不是说完全没有关注，而是没有关注到位。核心能力不仅仅是功能，也包括性能。对于技术出身的产品经理，特别是做后台出来的，如果自己有能力、有信心做到对核心能力的关注，肯定会渴望将速度、后台做到极限。
+
+
+事实上，现在很多顶尖的产品经理，当年都是喜欢编程的少年人。
+
+还有一些技术人出来创业，这时候就需要关注产品的整个生命周期，而不是局限在技术领域，产品思维就越发重要了。
+
+要不要学习产品构建的知识呢？无论从哪个方面讲 —— 理解、协作、沟通、转行、创业 —— 这个答案一定是肯定的。技术人了解产品知识，不仅能够加速自己的成长，降低沟通成本，形成更好的协作关系，甚至未来，你去主导一款自己的产品也是非常可能的。
+
+如何提高产品思维呢？这是个非常大的话题，很难在一篇文章里讲清楚。我们特地在极客时间开设了三个产品专栏，让资深的产品专家，从实际的场景出发为大家剖析产品的诞生、增长、数据能力和商业意识等，有兴趣的话大家可以了解一下。当然，专栏只是地图和指引，所有的知识，都需要你在实战中演练和打磨。
+
+祝好运。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 焦烈焱：从四个维度更好的激发团队创造力.md

@@ -0,0 +1,63 @@
+<audio id="audio" title="大咖对话 | 焦烈焱：从四个维度更好的激发团队创造力" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a8/32/a88b17bf6acd4f6ab769eac4928afd32.mp3"></audio>
+
+你好！
+
+本周作客“大咖对话”的是普元信息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年就太远了，对公司当前的发展并没有太大的好处。
+
+**第四，要有匠人精神**。这个词现在被说的有点多了，但一家企业必须找到自己最擅长的领域，然后专注的打磨，将其做到极致，变成自身的核心竞争力。现在很多领域都有赚钱的机会，但如果不是跟自己核心相关的话，就要懂得取舍。
+
+我们的创新可能都是时间熬出来的，我们掉过无数的坑，经历过无数次的错误，但是我们想办法从坑里爬出来，一步一个脚印把事情做好。一个产品做了废，废了再做，可能要磨四遍、五遍才有突破。而在这个过程中，我们也能不断去思考怎么把技术跟业务做更好的结合。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 玉攻：四个维度看小程序与App的区别.md

@@ -0,0 +1,44 @@
+<audio id="audio" title="大咖对话 | 玉攻：四个维度看小程序与App的区别" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/6a/3d/6a9e88867e175b88683a6ac90f2a223d.mp3"></audio>
+
+你好！
+
+本周大咖对话的嘉宾是蚂蚁金服资深技术专家，蚂蚁金融科技产品研发团队主管玉攻，目前主要负责金融级云产品的架构和研发工作。2015 年加入蚂蚁金服，并作为金融科技核心创始团队成员，领导和创立了蚂蚁金服的第一代 PaaS 云平台产品蚂蚁金融云。
+
+小程序从一开始的无人看好，到后来的风生水起，再到急转直下，现在又要重回巅峰，诸多互联网巨头纷纷发力小程序，那小程序与App之间的区别是什么，如何才能更好的发掘小程序的价值，玉攻与我们分享了他的观点。
+
+**极客时间：在您看来，小程序和App之间最主要的区别是什么？小程序会取代App吗？**<br>
+**玉攻：**不会，小程序不会取代App，从用户的角度来看，在一些高频的使用场景，App 的地位从不曾被动摇。一般情况下，用户每天打开使用频率最高的 App 不会超过 10 个。只有一些低频使用的 App 非常适合小程序实现。
+
+从大型企业的角度来看，大型互联网公司往往会采用“App+ 小程序”的模式，小程序会极大地提升 App 用户的活跃度，甚至会成为整个业务产品矩阵中的一部分，但不会替代 App。
+
+从个人开发者和中小型企业的角度来看，小程序的研发和推广成本远远低于 App，在研发初期和新业务试错环节，小程序会优于 App。但随着企业发展成熟，需求增加，功能要求更丰富时，App 的优势就凸显出来了。
+
+从业务的角度，如果某项业务需要短时间依附于大平台生态，借助平台的力量发展，那么小程序要明显优于 App。但当业务逐渐成熟并且被市场认可之后，平台的局限性也会逐渐显现出来，由小程序转向 App 就成了必然。
+
+说到底，小程序和 App 并不矛盾，但是小程序绝对不可能取代 App 的价值。大厂会并行走两条路，App 负责高频场景，小程序负责拉新试错。对于一些快速成长的创业公司，我建议从小程序做起，因为一开始就做 App 的成本非常高，但是先开发小程序，就可以用最低的成本去验证业务的创新性和市场接受度。如果业务上能成功，再去扩展业务模式，继续用小程序或者做成一款 App都可以，所以在一开始用小程序相对来说性价比更高。
+
+小程序近两年确实出现了一些爆款，但在这些爆款背后，其实大多数小程序都死掉了，探究其背后的原因，是因为很多人并没有搞懂小程序的持续迭代，不清楚小程序需要与场景深度结合。由于小程序开发成本低，所以市场上大量小程序都存在很快上线却缺乏维护的问题，没有精心运营，小程序的迭代就成了“死棋”；另外，很多开发者还没有意识到小程序与 App 的区别，只是简单地将 App 现有功能移植到小程序上，在产品形态上只注重功能而忽视了小程序最看重的场景问题，这就解释了为什么有的人开发的 App 活跃度还不错，但转战到小程序却满盘皆输的原因。
+
+对于小程序的未来，我希望小程序的发展不再局限于某一个平台，而是某个操作系统的小程序，甚至成为一种“新型 App”。不过目前阶段，还是要分清小程序和 App 有不同的用处，要根据客群、使用频率来决定最后选择小程序还是 App。
+
+**极客时间：支付宝为什么要做小程序，而支付宝小程序又有哪些独特的地方？**<br>
+**玉攻：**支付宝小程序其实是一个极简的服务工具，这与支付宝的定位不谋而合。支付宝小程序可以帮助用户在生活/商业的场景下开发出一些创新型的业务。其实大多数人很多时候并没有意识到自己正在使用的就是支付宝小程序，比如很多人每天去蚂蚁森林浇水，其实蚂蚁森林就是一款支付宝小程序。
+
+支付宝小程序集成了支付宝最核心的一些能力，比如支付、交易、信用、风控、AR 等等，所以在支付宝小程序里我们可以实现很多有创意的想法。举个例子，充电宝其实是基于 [街电] 这样的一个小程序，充分利用支付宝用户的信用和支付能力，产生的一种新型的商业模式。在我看来，支付宝小程序的初衷就是让大众的生活变得更方便，帮助企业更快地触达客户，让创新无处不在。
+
+支付宝小程序是一个前端技术，整个浏览器内核采用 UC 浏览器的内核，WebView 的稳定性和兼容性非常不错，Crash 率只有一般系统 WebView 的 1/5。另外，UC 内核针对内存做了大量的优化，包括图片的内存、渲染内存、JS 内存、峰值内存管理。支付宝小程序的内核启动逻辑是 v8 引擎 CodeCache 深度优化，这使得JS代码解析和编译时间减少 40% 左右。首页的加载和渲染对于冷启动非常关键，为了减少用户在首页显示前的等待时间，支付宝小程序采用离线缓存的方式优化加载流程。
+
+整个阿里经济体在做小程序的时候，强调统一的技术架构和多端投放，我并不希望小程序变成巨头进行技术垄断的手段，或者说技术封闭的一个边界。小程序最大的价值在于真正服务客户，让客户受益，给客户提供更多的渠道，获取更大的流量。
+
+目前在阿里体系里，我们想做统一的小程序，也就是支付宝小程序不仅在支付宝里可以使用到，在其他平台如天猫、淘宝、高德等也可以使用。比如打车，用户既可以从高德平台进入，也可以从支付宝的平台进入；比如某个特卖的小程序，用户有可能是从淘宝的渠道进入，也有可能是从支付宝的渠道进入。所以支付宝小程序不是单一的，它的背后是有强大的“矩阵”在支撑。开发支付宝小程序，表面上获得的是支付宝的渠道优势，其实它背后是整个阿里经济体系的支持。这是其他平台所没有的优势。
+
+**极客时间：普通开发者如何才能更好的发掘小程序的价值呢？**<br>
+**玉攻：**其实支付宝小程序云是一个非常好的选择，它能让开发者不需要关心证书、运维、扩容，不需要关心被黑客攻击，只需要专注写好自己的代码和业务逻辑即可。
+
+平台技术一直是我非常感兴趣的方向。我在 IBM 参与过 WebSphere 这样的应用服务器，我也做过 Java 开发。技术的发展在这十几年的时间里，基本实现了基础设施的“云化”。整个业界在最开始做云的时候，真的是“云里雾里”。随着认知的成熟，我们发现云其实是一层一层的，最下面一层叫做 IaaS，相当于把计算存储网络的资源“云化”，所谓的云化就是能够让更多的人以共享的方式使用到这些资源，而不需要自己去做比如购买机器、物理机、买机房设置网络等等这些事情。这个阶段我们称为 Cloud-Based。对于金融行业来说，要想实现云化，其实是需要心理斗争的。但当我们心里迈过这个门槛的时候，我们就进入到 PaaS 层面。
+
+PaaS 层面要解决的问题就是让应用变得更舒服一点。比如原来要开发一个应用，需要考虑如何设计中间件、网关、流控、分布式架构等，当中间件云化之后，需要做的就是保证上层业务的实现，让业务衍生成为一个能够支持一定规模的互联网的产品，这个阶段就是 Cloud-Ready。我在做中间件的时候，发现中间件的未来其实已经往 PaaS 层面发展，中间件的云化可以帮助上层业务更容易地享受到基础设施的便利性。
+
+而我们现在要走的一个方向，其实跟支付宝小程序云服务未来的发展方向是一致的，也就是 Cloud-Native。现在技术圈比较火的就是 Serverless，就是你已经不关心服务器这件事情了，所有的基础设施，包括运维，都已经由云厂商帮助你去解决，而你真正需要关注的只是你的应用和你的业务逻辑。这其实就是支付宝小程序云服务的发展的轨迹。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 王坚：我从不吃后悔药.md

@@ -0,0 +1,78 @@
+<audio id="audio" title="大咖对话 | 王坚：我从不吃后悔药" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/65/8e/657f23bca8c9d9b424e6b76bd9ffde8e.mp3"></audio>
+
+你好！
+
+本周大咖对话的嘉宾是王坚，他是2050 志愿者，阿里云创始人，阿里巴巴技术委员会主席。日前，极客邦科技创始人兼CEO霍太稳Kevin与王坚在极客 Live进行了一次精彩的直播，聊了他对于自己、对于技术人、对于世界的诸多想法与思考，带来了不一样的王坚。本文特意筛选了直播中关于技术人成长、管理等相关的话题分享给大家，希望你能有所收获。
+
+**Kevin：在您看来，一个优秀的技术人应该具备哪些特质？**
+
+**王坚**：写好代码当然是最重要的，代码都写不好，再说别的都不靠谱，这是技术使用层面的问题，是最基本的。但一个好的技术人不仅该知道如何使用技术，还要有能力创造新技术，这可能是我们国内技术人面临的最大挑战。
+
+使用技术和创造技术是两个不同的概念，并不是说谁比谁更高级。我们的历史责任应该是为全世界创造技术，比如从语言这个角度讲，我们能否为世界贡献一门语言，这并不是说要“为国争光”，而是说要对世界有贡献，要想一想我们能为这个世界做点什么。
+
+除此之外，还要保持年轻的心态。而保持年轻心态的关键就是要享受现在所做的事情，只要你真正热爱一件事，做起来就会觉得是种享受。如果将享受理解成远离你现在的工作，这是件很悲剧的事情。有些人希望一辈子都生活在海边，这本身没有错，但如果觉得只有去海边度假才是享受生活，这就是个问题了。对我而言，我每天都坐在海边，享受自己所做的事，做对做错都不重要，做好做坏也不重要，不要以结果的好坏作为判断你是否享受的标准。
+
+**Kevin：您对于管理有何心得体会？**
+
+**王坚**：说真的，做管理还是挺难的，如果允许我自夸一下的话，我觉得所谓的创新工作或治理工作，这方面的直觉会相当重要，至少对我来讲是这样。任何优秀的管理方法，管理者都要对流程非常清楚，但这里面也有一个诀窍，就是你要精准地知道，哪些是你要做的事情，哪些事情一定不做。
+
+很多时候，我们最艰难的环节都卡在“纠结”这件事情上，于是以花时间做了一些本来可做可不做的事情，浪费了一些原本可以花在必做事情上的时间。这个判断的过程对我来说是依靠直觉完成的，作为管理者，对于流程的严格管理是必要的，但相信直觉一样也很重要。直觉是支配你的巨大资源，有了它你才会进入流程的管理，这方面我的体会蛮深的。
+
+大部分时候，要平衡商业、技术和管理这三者的关系，确实会遇到一些困难，对我自己而言，这时候最重要的就是要接受别人的帮助。我经常会讲，一个人有长处其实是很危险的一件事，因为他的短处是需要别人帮忙填补的，但很多人看不到这一点。
+
+我觉得我最大的长处，并不是我自己有多优秀，而是我可以心安理得地接受别人的帮助，比如2050，就是我接受别人的帮助，而不是我帮助别人。如果你管理上比较弱，在这方面就要多接受别人的帮助，如果不能接受，那就会是个灾难，不要试图去做你明知道做不好的事情。适时接受他人援手，也是一个人成长最后的挑战。
+
+**Kevin：和马云在一起工作是一种什么样的体验？**
+
+**王坚**：我知道，很多人想了解和马云一起工作是一种什么体验，对此我觉得非常幸运，我还是更喜欢叫他马总，这是对他的尊称，能够有机会跟他在一起工作，对我的帮助非常大，和他相处也没什么压力。
+
+大家都知道他在公众面前做了很多次演讲，我可能是少数真正理解他为什么会那样讲的人之一。很多时候，我可以明白他的所思所想，他说出的话和他的思想保持着高度的一致性，这让我非常佩服。他是真正从解决社会问题的角度来看待所有事情的人，你可以从他身上学到很多东西，包括对企业家的尊重和对中小企业的尊重。
+
+同时，马总也是一位非常谦虚的人，他经常说自己不懂技术，我会跟他讲，懂不懂技术并不是核心问题。他真心地尊重技术，有时我甚至觉得，他比一些懂技术的人还要尊重技术。
+
+我经常讲，阿里是一个平台，很多人在阿里工作的时候，他（她）的能量被放大了，边界随之扩张，学到的东西自然也变多了。人和人之间原本没有那么大的差别，但你身处潮流的中心，边界又足够大，自然就可以做很多事情，学很多别人学不到的东西，对你的成长就会有更多帮助。
+
+其实，我们做技术也是在拓展业务的边界，业务会反过来推动技术的发展。我定义业务和技术的关系，是铁轨跟火车头的关系，这里并不是说铁轨一定是业务或技术，这二者都没问题。
+
+你很难讲，是火车头还是铁轨将你带到一个地方的，因为铁路不修到那里，火车就到不了那儿；铁轨修到了那里，没有火车也无法抵达，这二者是统一的，这就是他们之间的关系。我认为，业务在推进技术，技术也在创造崭新的业务，在今天这个时代，这二者是一体的，这也是我说这是最好的时代的理由之一。
+
+**Kevin：咱们最后快问快答几个问题。**<br>
+**Q1**：您认为自己做过最牛逼的事情是什么？<br>
+**王坚**：今年做的最牛逼的事情就是让志愿者来办一个大会（2050）。
+
+**Q2**：有最后悔的事情吗？是什么？<br>
+**王坚**：真没有最后悔的事情，我这人从来不吃后悔药，真没有什么感到后悔的事情。
+
+**Q3**：过去对您触动最大的一件事是什么？<br>
+**王坚**：阿里云做到后面，我发现自己接触到了整个社会，这是我第一次发现有那么多人要用云计算，世界变得如此开阔。这件事对我触动很大，让我改变了很多想法，阿里云折射出社会的一面，打开了一扇崭新的大门。
+
+**Q4**：做过最尴尬的事情是什么？<br>
+**王坚**：我从学校到研究院，又到阿里，最尴尬的事情就是整天都有人问我，这跟你学心理学有没有关系？我说有关系是不对的，说没关系也是不对的，这就是最尴尬的地方。怎么说都得说点理由出来，但其实一点理由都没有，这就是最尴尬的事情。
+
+**Q5**：作为阿里巴巴的首席技术官，您会写代码吗？<br>
+王坚：我真的会写代码，只不过我今天写的代码对公司的贡献已经微乎其微了，还是不说的为好。
+
+**Q6**：最近有哪些新的感悟？<br>
+**王坚**：谈不上新的感悟，如果一定要说，那就是做了2050和城市大脑之后就会觉得，我之前讲的那句话是对的，这真的是人类历史上少数几次最好的时代，而不是笼统的好时代。
+
+**Q7**：最近看的一本书，或者是电影是什么？<br>
+**王坚**：最近我看了很多书，不止一本，电影倒是没怎么看。我今天看了一本书，内容讲纸是从哪里来的，我觉得蛮有意思的。那些非常日常的东西，很多人会忘记他们的出处。我们经常会去追求一些看起来很深奥的东西，但那些东西却并不能告诉你有价值的道理，倒是那些看似非常普通的事情，可以告诉你一些非常朴素的道理。
+
+**Q8**：您的口头禅是什么？我很幸运吗？<br>
+**王坚**：大家都觉得我的口头禅是“不知道我说清楚了没有”，但“我很幸运”这个确实是我最近经常讲的，真的不是客气话，是我的心里话。
+
+**Q9**：您最害怕的三件事是什么？<br>
+**王坚**：别说三件事，连一件害怕的事我都讲不出。这个世界还是很宽容的，你就是要面对那些应该面对的问题。站在我的角度，我自己没有什么特别害怕的事情，我只是在想如何能让这个世界变得人人都可以享受其中，不仅仅是物质层面的，还有精神层面的，这可能是我想得比较多的。
+
+**Q10**：您最敬佩的人是谁？<br>
+**王坚**：这个问题很难回答，我最早看维纳写的书，那时候年纪比较轻，就觉得特别敬佩他，但年纪大了一些以后可能就没有那种感觉了，我只能说我年纪轻的时候曾经敬佩过的就是这些人。因为他们在很多人尚没有能力描述清楚的时候，他们就可以做一些比较清晰而有逻辑地表达了。
+
+另外，很多时候我觉得最好不要用“最”字，比如说刚才讲到的马云，再比如比尔·盖茨，还有一些书籍的作者我都很敬佩。再比如最早阿里云的一些客户，我也是真的很敬佩他们，没有他们就没有我，这是我自己的真实感受。
+
+**Q11**：最不满意自己的事情，或者最不满意自己的地方是什么？<br>
+**王坚**：跟Kevin认识那么久还是第一次做直播，这个话是什么意思呢？其实世界真的很大，你只能遇到很小的一部分，跟Kevin那么熟也只不过接触了这么一点，这是我最不满意的地方，我应该更多地接触一下这个世界。
+
+**Q12**：博士给我们这些热爱科技的年轻人能不能说几句话？<br>
+**王坚**：第一句，这是年轻人可以创造未来的时代，你真的要打起精神来。第二句，要相信天是蓝蓝的天，乐观是解决问题的必要因素，世界上有很多的问题和挑战，依靠乐观是可以解决一部分的，也是我们年轻人给这个世界带来的很棒的东西。我曾经和人讲，年轻人是最后去解决这个世界问题的人，你不乐观，这个世界就没有未来。我们真的应该努力让这个世界变得更好，让大家都能享受在这个星球上的生活。
+
+感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 王平：从人、事、价值观、文化等维度看技术团队转型.md

@@ -0,0 +1,68 @@
+<audio id="audio" title="大咖对话 | 王平：从人、事、价值观、文化等维度看技术团队转型" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/4b/f5/4b233e00efb5cfbb5c18d5fed1b1b4f5.mp3"></audio>
+
+你好！
+
+今天作客大咖对话的嘉宾是前Mobvista CTO 王平，在Mobvista负责公司整体商业变现技术体系的构建和管理。此前先后在百度、高德就职。在百度，作为凤巢核心成员，负责凤巢流量变现商业产品的技术管理。随后加入高德担任商业变现总监，负责产品和技术管理。多年职业生涯一直活跃于互联网商业变现领域的风口，对行业技术体系构建有深刻理解。
+
+今天，我们跟他聊了聊出海创业的趋势 ，以及公司技术转型中的挑战与实践。
+
+**极客时间：您之前在Mobvista接触过很多移动出海的案例，以您对海外市场的了解和观察，能分享一下当前移动出海的趋势吗？对于创业者，有何建议呢？**<br>
+**王平**：自2010年中国移动互联网出海的浪潮兴起，近9年的时间里，中国移动出海的产品历经工具类应用的百花齐放，到安全、桌面类应用和轻型游戏的爆发式增长和洗牌，再到娱乐内容类产品的迭代与崛起，目前已经进入稳定发展阶段。
+
+前几年，移动出海成为热点的主要原因有两方面，一是当时国内的移动互联网市场经过将近十年的发展后已经慢慢趋于饱和，移动互联网的人口红利也已经被慢慢消耗完了，很多行业都从蓝海市场变成了红海市场。而与此同时，海外的市场就相当广阔了，比如像南美洲、印度、东南亚这些国家和地区，他们当时移动互联网发展的程度与规模远落后于国内，人口红利和蓝海市场优势依然存在，对于中国的创业者而言，还具备相对的竞争优势。
+
+二是国内的创业者走得比较领先，他们经历了移动互联网的爆发式发展，等于是以一种高维的状态去向低维的市场进攻，有非常大的优势。从这些角度来看，相较国内的激烈竞争，海外的市场机会非常多，这也是当时越来越多的中国创业者选择出海的原因。
+
+现在临近2019年，再去审视出海，局势和环境又有了较大的变化。首先，5年前所谓的国内海外的信息差几乎已经不存在，现在每个人都知道出海有机会，都知道出海怎么买量、知道怎么判断流量质量；其次，流量的聚合效应在加强，头部玩家在不断进行行业整合，比如阿里布局东南亚电商、今日头条做海外版今日头条；最后，出海产品在往内容类、社交类、购物类产品等转型的过程中，往往面临着规模化瓶颈，至少在东南亚、两印等国家和地区是很明显的，因为从文化语言的角度来看，那不是一个国家。
+
+因此，以我对海外市场的了解和观察，创业者出海依然有机会，但是在市场选择、产品方向选择上需要谨慎。现在海外已经不再是蓝海市场，竞争已经充分，没有了信息差和经验差的绝对优势，接下去拼得还是创业者的战略、产品、市场等真正的内功修为。
+
+另外，虽然早年间，大家是认为国内创业越来越难，才去寻求外部市场，也尝到了甜头。但是，近几年，国内的创业局面，发生了一些根本性的改变。首先，市场依旧很大，依旧有很多机会，比如典型的拼多多，通过三四线城市下沉，以及去中心化的营销模式创新，挖掘了一个极大的市场蛋糕。所以不是不存在市场，而是我们没有发现市场。
+
+其次，随着中国自身的发展，已经进入了产业升级的轨道，越来越多的出现了传统行业和互联网的碰撞机会，这将会诞生一大批各个领域的互联网+公司，而且各个领域都有机会，像VIPKID、钉钉等就是典型代表。所以大家不妨可以思考下国内市场的空间。
+
+最后，我认为目前的互联网发展到了一个十字路口，不久的将来一定会引来生产力级别跃迁和变革的机会，比如物联网、AI领域。若有人能掌握生产力级别的核心竞争力，必然将引领未来的发展趋势。所以，对于有技术追求的创业者，不妨多关注和死磕技术竞争力。这条路很难，只有心怀梦想不畏艰难的人，才有机会。
+
+**极客时间：您之前在Mobvista主导了公司的技术转型，能否分享一下您的这段经历吗？**<br>
+**王平**：Mobvista早期是一家商务运营驱动的公司，团队让我加入的初心是希望进行技术转型，原因在于广告行业本质是数据业务，是解决广告和流量匹配效果的业务。
+
+回顾Mobvista的技术转型路线，经历了人、事、价值观、文化四个关键阶段，前三者几乎同时进行，并稳定持续近2年，文化是在2016年底开始思考和推进的，很遗憾，离开前并没有完成真正的落地。
+
+人才战略是我最早推进的事情，没有人才储备，就没有所谓的技术驱动。在早期半年内，我们搭建了一支核心团队，未来团队几乎以此为基础展开。
+
+事的角度，我们梳理了业务和技术体系，确定了一系列的重点业务和技术专项，全力解决重点核心工作以求突破，又通过“事”来以战养兵，很多未来的核心方向都是这个过程中发展起来的。
+
+伴随着人和事的推进，我们在这个过程中确定了团队当时的价值观，主要有：以终为始、有分工无边界、有功必奖有过必究等。
+
+然而，上述举措在团队规模150人以内是能work的，但超过150人以后，就会发现团队的管理遇到了很大的效率和执行问题。这是发生在2016年底。随后，经过思考后认识到，需要通过文化去凝聚团队，之前的价值观还只是一种做事方式，并没有形成一种文化。2017年，我做的重要的事情之一就是技术团队文化的构建。
+
+**极客时间：能否分享一下，在具体的执行层面，您是如何打造技术团队文化的呢？**<br>
+**王平**：首先，我想再强调一下文化的重要性。文化跟团队人数是绝对相关的，之前提到，当团队规模超过150人之后，管理者能明显感觉到团队管理难度的差异，很多事情的执行与落地会比之前困难很多，很多管理层想法在传递过程中会有非常严重的损耗，你会发现一切好像都变成了一个相对不可控的状态。
+
+为了解决这些问题，我花费了很多时间去处理并思考，发现一个比较有意思的事情是，出了问题，大家复盘之后会发现是某个操作流程或规范上有缺陷，处理方法自然是去完善这些地方。
+
+但这么做其实存在极大的问题，原因在于，如果真的企图通过流程机制或规范的不断完善细化，来解决整个管理中遇到的问题，几乎是一个不可能完成的任务，因为规则是不可能穷尽的。同时，必须要认知到一点，规则制定得越细，团队成员可发挥的空间就越少。
+
+而之所以会出现上面提到的诸多问题，归根到底是因为人多了，而不同的人的想法、追求、价值观都是有差别的。因此，解决问题的关键点就落到了，如何让大家在公司或技术团队范畴内，拥有统一的价值观或文化上。
+
+打个比方，社会有其自身的道德价值观，也有其法律，但法律只能规定整个社会的道德底线，而没法定义上限。整个社会的道德体现最终取决于其价值观，比如尊老爱幼，这句话就是价值观或文化的体现，它有很多延展和体现，我们能用四个字概括，却不可能在法律法规里一一规定到底什么样的行为是尊老爱幼的行为，相信大家都能体会。这其实跟公司的流程规范有些类似，都只能定义底线。
+
+这种价值观或文化的另一个好处是，能在很多灰度地带，引导大家自动选择一个相对正确的行动方向，也能避免去制定极其详细繁杂的流程规范和机制。这是我对文化的一个思考。
+
+确定思路之后，就要去打造属于技术中心的统一的价值观和文化。在具体的执行层面，首先，我需要一个能够在文化建设方面帮助到我的人，我的做法是招聘了一位HRBP，来帮助我一起把文化这件事做好。毕竟文化构建对于我来讲是一个相对陌生的课题，而这在一定范畴内又是属于HR体系的事情，专业的事情交给专业的人来做，这是非常重要的。
+
+接下来就是一些围绕文化的实践，比如要先确定整个技术团队的文化是什么，以及我们怎么解读这个文化，哪些案例是最能体现文化内涵的，等等。
+
+当时我定下的技术团队的文化是敬畏技术、追求卓越，再把之前一些执行层面的价值观（以终为始、有分工无边界、有功必奖有过必究等），以及很多现实中的案例完善进去，形成对文化的解读。
+
+确定文化是什么之后，就需要在整个公司层面、各个场合去不断强化这个文化，不断强调哪些价值观、哪些行为会被公司认可，比如通过平时的一些奖励机制，引导团队成员的行为逐渐靠近我们文化所推崇的行为。
+
+坦白说，这个文化落地的过程中存在很多挑战，举个最典型的例子，团队之所以会出现这样那样的问题，很大概率上是因为中层管理团队已经在文化和价值观上出现了偏差。那你推动文化落地的时候，必然会在中层管理团队这儿就感受到一些阻力，比如推脱说现在业务很紧，如果在质量保障工作上投入更多精力的话，就可能会影响到业务的进度，给你出一个选择难题。
+
+但这中间的逻辑是存在问题的，乍一看，业务很忙，那自然要把更多的精力聚焦在业务上，把业务做得漂亮，但长远来看，减少了放在质量保障上的时间精力，质量保障没有做好的话，接下来反而会出更多的问题，影响到业务。
+
+因此，我也做好了准备，先对整个中层管理团队做一个整体的Check，看他们的文化和价值观取向是否一致，如果出现差异极大的同学，就必须要重新调整。这是一个比较艰难的事情，但为了文化的顺利落地，这件事情是一定要去做的。毕竟，当团队扩张到更大规模的时候，文化与价值观能否统一，会决定整个团队的精神面貌以及未来的战斗力。
+
+感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 王平：如何快速搭建核心技术团队.md

@@ -0,0 +1,58 @@
+<audio id="audio" title="大咖对话 | 王平：如何快速搭建核心技术团队" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/4d/09/4d8ce0e13fac3c3dc84663258ac94309.mp3"></audio>
+
+你好！
+
+今天大咖对话的嘉宾是前Mobvista CTO 王平，在Mobvista负责公司整体商业变现技术体系的构建和管理。此前先后在百度、高德就职。在百度，作为凤巢核心成员，负责凤巢流量变现商业产品的技术管理。随后加入高德担任商业变现总监，负责产品和技术管理。多年职业生涯一直活跃于互联网商业变现领域的风口，对行业技术体系构建有深刻理解。
+
+今天，我们跟他聊了聊如何搭建核心团队，以及如何做好跨地域沟通等话题。
+
+**极客时间：据了解，您主导了公司的技术转型，并在早期半年内，搭建了一支核心团队，能否分享一下您当时的做法，以及是如何吸引核心人才加入的呢？**<br>
+**王平**：首先肯定是要先做一个人才盘点，我们当时盘点下来，大概需要6个核心成员，包括运维、测试、算法、工程、业务等领域的相关负责人，后来这个核心班子扩展到了8个人。
+
+那这些核心成员如何来呢？就需要开源和节流两方面结合，所谓开源，就是外部招聘，所谓节流，就是内部培养。而在当时的情况下，内部培养出的人才是远远赶不上需求的，开源，即外部招聘就成了重点。
+
+首先，要确定人才在哪儿。当时我们团队在向技术方向转型，一个很现实的问题是，公司在广州，但广州这边的技术人才储备是不够的，同时，整个广告行业的人才分布也大多集中在北京。基于这个角度，我们人才战略的第一个决策就是在北京成立一个研发中心，解决了人才在哪里的问题，这是招聘中非常关键的环节。
+
+其次，要确定所需人才类型。当时，广州的技术团队主要是PHP后台研发相关的人才，人才盘点后，发现还缺乏两类人才，一类是算法人才，一类是能够支撑流量高并发、低延时、高稳定性的工程架构相关人才。确定去哪儿、招什么人这两点之后，团队组建的基调就定下来了，接下来就是具体的搭班子环节了。
+
+其实，早期组建团队，技术leader的个人影响力是非常重要的，比如当时6个核心成员中，就有3个人是通过我自己的关系挖来的，剩下的再通过招聘和内部提拔来补充。
+
+至于如何吸引这些核心人才的加入，有几个关键点。
+
+首先，你做的事情要能引起他们的兴趣，这是非常重要的一点，也是能不能把大家聚在一起的先决条件。技术在广告领域有很多可做的事情，包括当时我们有一个比较成功的变现产品，日活接近2个亿。如此大流量的产品，背后的算法、工程都有很大的挑战，也能带给大家很大的成就感。
+
+其次，对于公司未来发展，要给出一个相对公正客观的分析。我自己加入，本身就代表我是非常看好这件事的，因此，在招聘时，我会跟候选者分享我对未来的看法。至于对方是否认可，就要看双方的互相选择了，也取决于对方认不认可我们在做的事情。但对于创业公司来说，这种冒险精神是非常必要的，如果没有冒险精神，大家很难走到一起创业。
+
+最后，作为创业公司一定要在待遇上给到位，特别是金钱上不能给特别多的话，期权就得到位。对于核心人才，我们当时在期权上做了比较多的倾斜，越早期加入，倾斜的比重就越大，毕竟这些人才过来也是需要冒风险的。
+
+**极客时间：您提到Mobvista的技术团队分布在广州、北京两地，能分享一些您在跨地域沟通和管理上的经验吗？**<br>
+**王平**：目前，整个Mobvista有180位左右的技术人员，涵盖研发、QA和运维，基本是以1：1的比例分布在北京和广州两地。另外，还有我们在海外收购的公司中也有研发团队，所以还涉及到跨国团队的沟通问题，都非常具有挑战性。
+
+对于每家公司来说，沟通都是非常重要的一件事情，即使是面对面沟通，都有可能出现误差，更不用说跨地域沟通，出现问题的可能性就更大了。在实际管理中，我们一般会从以下几个方面出发去尽量解决。
+
+首先，在业务划分阶段就做好准备，尽量让不同地区团队负责的业务都相对独立，减少跨地域沟通的频次，从根本上解决这个问题。目前我们在这方面做得还不错。
+
+其次，即使各地区的业务相对独立，依旧无法避免跨地域沟通，这时就需要我们有一个定期的沟通机制，从管理团队和一线执行团队两个层面做好沟通。
+
+管理团队层面，我们规定每周必须有一次当面的沟通会议，同步之前的工作进展，明确之后的工作规划。同时，对于遇到的问题，比如哪些问题需要在短时间内就解决，哪些是中长期的问题需要持续关注，都要在管理团队内达成共识。
+
+一线执行团队层面，我们会通过视频会议的方式，尽可能减少信息沟通中产生的偏差。同时对于一些重要项目，我们会安排相关人员出差，通过这些方式尽量去环节跨团队沟通的问题。但如果说完全解决这个问题，这几乎是不现实的，跨团队沟通中的问题或多或少都会存在，我们作为技术leader，要做的就是尽量把这些问题控制在一个相对能够忍受的范围内。
+
+其实，不论是本地沟通，还是跨地域沟通，对于一个团队来讲，最重要的事情就是成员是否能知道团队的目标在哪里，以及是以什么样的路线去达成目标。另外，在想着目标前进的过程中，已经走到哪里，未来还将走向哪里，这些对于整个团队来讲都是非常重要的信息，也许不是所有的同学都关注，但我相信，优秀的同学一定会主动关心这些信息。
+
+因此，作为管理者，我们就需要在团队层面做一些事情，安排一些场合，比如季度沟通会，来对整个团队做阶段性的复盘，并对阶段性目标进行重新锚定。如果跟之前设定的目标有差异，就要说明为什么会产生偏差，以及在这样的偏差下，我们要做哪些调整，下个季度还要做什么事，等等。
+
+这些信息，我们都会在全体范围内做集体性的沟通，确保在大的战略和战术执行层面，大家获得的信息都在一个基本面上。但坦白的说，这件事是其实是做给优秀的人、愿意主动关心团队动向的人看的。
+
+**极客时间：最后，对于有志于成为CTO的技术人，您有哪些建议？**<br>
+**王平**：如果想往CTO这个方向发展，首先不要把自己定义成一个单纯的技术型人员，因为当你往更大的事业和格局去走时，你要把自己技术人员的身份先放一放，要更多的考虑业务，考虑自己如何把技术和业务结合起来，推动公司业务往前走。
+
+公司之所以是公司，它有它的商业模式和生存之道，这时，如果你的目标不能和公司目标很好的结合起来，就很难成为公司发展中的关键人物。所以，首先要做的就是把自己技术人的身份先放一放，稍微淡化一下。
+
+第二点是管理，很多技术人的单兵作战能力很强，有时难免会觉得别人的技术都不如自己，跟其他人组成小团队做项目，效率还不如自己一个人上来得快。但如果你的职业目标CTO，那就一定要从单兵作战的思路演变成团队作战的思路。在这种情况下，管理就是一件非常重要的事情，你需要想办法走出舒适区，想办法做好管理相关的工作，比如如何制定整个团队的目标，如何拆解目标，如何带领团队一步一步实现目标等等。同时，管理并不像技术有定式，需要你在这个过程中不断实践、反思、复盘，直至找到最适合自己的管理实践。
+
+最后，也是最重要的一点是，就是要选择一个适合自己的、能长久去做的事业方向，具体来说，可以考虑以下几个因素：一，选择的方向是否具备社会价值，是否能对人们的生活产生深远的影响；二，选择的方向是否具备战略纵深，不是3~5年就到头的，而是可以做5~10年，甚至更长远的做下去的；三，选择自己喜欢的事情，这里的喜欢不是单纯的爱好，而是你相信这件事，哪怕到最后失败你都坚信这事是对的，你依旧有热情沉浸其中去享受。
+
+感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 王鹏云：技术人创业该如何选择合伙人？.md

@@ -0,0 +1,48 @@
+<audio id="audio" title="大咖对话 | 王鹏云：技术人创业该如何选择合伙人？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/98/7d/98fa18e9df6e3c687d28f69ae7580a7d.mp3"></audio>
+
+你好！<br>
+本周作客大咖对话的嘉宾是蓝创中心总经理，蓝标产品技术委员会主席王鹏云，他也是前多盟联合创始人，前蓝标移动广告集团CTO，曾任百度高级工程师、魔时网CTO、139移动互联研发总监，在营销领域深耕十多年，目前专注于技术创业孵化，今天我们的话题是技术人创业过程中容易踩到的坑，希望能给你带来一些借鉴意义。
+
+**极客时间：根据您的观察，技术人创业容易踩哪些坑，需要注意哪些问题？**<br>
+**王鹏云**：这些年，我自己有过几次创业经历，也见过很多的技术创业者，包括联合创始人、CTO以及技术人自己做CEO等，总结技术人创业陷入的主要误区有三个。
+
+一是考虑问题以技术为先，因为他最熟悉的是技术，而且很多技术创业者有极强的技术自信，他在很多相对成功的大公司待过，自己的那套技术已经在应用中取得了较大成功，所以出来创业就会有极强的技术自信，容易以技术为先考虑问题。
+
+不能说技术优先是绝对错误的，如果企业是纯粹的技术领先驱动型公司，技术优先就没有问题，你拓展的是技术边界，比如AI，在这个领域中，如果你公司的技术一马当先，这时以技术为先考虑问题是OK的。我之所以称技术优先为误区，是因为如今绝大部分创业公司都不是真正以技术为核心驱动，多数情况下你的核心技术门槛没有那么高，你能做，很多公司也能做。你公司的核心竞争力不是来自于技术独到性或技术领先性，这时再用技术为先的思路主导，往往会将更核心的目标忘掉。
+
+二是过度技术化，所谓“过度技术化”是在推进业务的过程中，可能很多工作是可以由人工完成的，比如用Excel来统计分析，而技术人往往看不过去，会说“这玩意怎么还那么落后呢”，想将这种工作方式技术化。我认为，技术化应该有一个节点选择，即在合适的时间、合适的环境和条件下做技术化，而不是将所有问题都用技术方式解决，这是很大的误区。
+
+这个误区容易导致的问题是什么呢？首先是过度的技术投入，其次，浪费了很多业务抢占市场机会的时间。我们知道，要用技术化的方式来实现某个功能，并且相对成型，需要大量的技术投入、时间投入和精力投入。一方面技术投入成本增加，另一方面，时间、精力也是一种耗损。可能人工方式看起来比较土，但相对来说却能够较快的完成目标。因此，对于技术化的选择还需要考虑时机，过早使用太技术化的方式不是一个明智的选择。
+
+三是过度理性，在创业过程中，理性是很重要的，但技术人往往容易过度理性，做任何判断与决策，都希望有数据支撑，这不可能，因为创业本来就是九死一生，甚至99%失败，只有1%是成功的。其中有非常多难以用理性方式去把握的东西，甚至有很多运气的成分、感性的成分。很多时候，创业需要狂热、突围、狂奔。另外，创业很多时候都需要我们对商业、对行业有洞察和直觉，而这需要有嗅觉和敏锐性，不能所有决定都依赖于数据，有些数据可能是脏数据、假数据，这时难道我们不做决策了？不往前走了吗？你拍着脑袋也得往前走。过度理性会让自己变得裹足不前，甚至被一些错误数据引导到错误的结论中。
+
+那我们应该怎么尽量避免这些误区呢，我认为主要有两点，首先，从主观上讲，一定要压制自己的技术人思维，意识到问题的存在，即使你的技术确实很强，也一定要压制自己的技术冲动，理解其他方式的合理性，理性地看待问题。
+
+其次，开阔眼界，了解技术之外的东西，比如产品、销售、行业现状与未来以及企业之间的协同模式，等等。虽然我们了解的这些知识不见得能在工作中“学以致用”，但这有利于我们能以更全面的视角思考问题。另外，当你了解了社会与行业，再来反推公司的商业价值，以及如何让商业价值变现，就相当于了解全局，再跳回来审视局部，这样能避免踩更多的坑。
+
+其实，上面提到的几个误区，我自己以前多多少少都经历过，因此有一些切身体会。除了技术方面的坑，还可能有合伙人的坑，商业合作的坑，视角的坑，业务拓展的坑，变现的坑，投资的坑，等等，坑非常多。
+
+我想说的是，选择创业，就不是在别人搭好的平台和既定的规则、清晰的约束下去做事情，你只要做好自己边界范围内的事，看准边界在哪里，完成既定目标就好，或有所突破更好。创业真的是一件无边无际的事情，最底层的约束其实就是法律，除法律外，在没有约束的情况下做事，就非常容易迷失方向，跌跌撞撞踩很多坑。虽然踩坑无法避免，但我们可以尽量少踩，因此就需要我们开阔眼界，至少可以用一些常识让自己少踩坑。虽没有经历过，但大体上有直觉，知道某件事的运行规律，这样，当你做一些具体的决策和判断时，就可以尽量遵循规律，不符合规律的就绕着它走，不是所有事情都要不撞南墙不回头，脑袋没那么硬，撞几下可能就不行了。
+
+**极客时间：技术人创业，在合伙人的选择上，您认为有哪些权衡和考虑点？一个优秀的创业团队又应该具备哪些特质呢？**<br>
+**王鹏云**：我一直认为合伙创业是这个世界上特别难的一件事，比结婚还难，因为这个团队所经历的事情要比家庭复杂得多，正如阿里巴巴的做大做强之路，中间经历了多少时间和磨难，这绝不是一个家庭能够比拟的。合伙的问题也非常复杂，合伙人内斗其实是很多公司死亡的主要原因，内斗有各种各样的原因，各种各样的情形，我甚至见过最严重的情况已经到了团队斗的唯一目的是把对方送到局子里去。
+
+至于创业合伙要注意什么？我当然可以列出很多要点，但在实操过程中，你会发现依旧有很多问题是这些要点覆盖的，不过总的来说，选择合伙人可以衡量五个方面。
+
+首先，最重要的是要有契约精神，承诺就要尽最大努力兑现，并对达成一致的决定不反悔。吃亏也认。只有这样，大家才能形成一个比较良好的协作模式，否则个人具有再强的能力、再高远的洞察、再丰厚的资源、再宽广的人脉都难以预料你的合伙人哪天与你反目相视。有契约精神之后，多方可依赖，再多延伸一点就是志同道合，有句话说“志不同不相为谋”，目标的差异可能导致很多问题的出现，只有目标一致，才能同心同力。
+
+第二，有主有从，创业团队共同商量决策没问题，但不能因为哥们义气齐头并进，一定要有一把手，因为大多“商量着办事”的企业发展到最后，瓶颈都非常明显。因此，不管决策人身上有这样那样的缺点，但他是你们最初共同选定、认可的人，那就遵照契约精神，在遇到各种分歧时，该妥协妥协，该配合配合，最后达成一致继续往前走。
+
+第三，能力互补，这点也很关键，有的初创团队几个人都是技术，或几个人都是商务，这样的团队短板非常明显，并且弥补短板时不得不用一些你完全没有把握的人来做，风险很大，因此，团队合伙人最好能力不同，分布于技术、产品、商务、市场等几个方向，能够有所互补，比如，在视角方面，大家的关注点就不同，有些人比较有远见，有些人可能更关注落地。
+
+第四，合伙人数最好是奇数，三个是相对比较好的数字，人太多，达成一致的困难更大，人太少又容易缺乏足够的视角。如果只有一个人，那你的短板就是公司最大的短版，没有核心的伙伴来帮你补齐你所欠缺的能力，因此三个人可能是最好的一种合伙团队模式。
+
+第五，合伙人人选最好是前同事，从各种合伙人的选择来看，有亲人、朋友、前同事、陌生人等，在我看来，前同事可能是一个较好的选择。前同事好在哪呢？一是对目标的理解更容易达成一致，彼此对事情的理解相对有认同感，因为曾经共同做过一些事，三观和认知可能更贴近；二是与前同事之间有更好的协同基础，也了解对方的能力、短板、做事风格等，这点也是陌生人合伙的不足；三是能够撕破脸皮，这点很重要也容易被忽略，朋友、兄弟创业最大的问题就是容易在出现问题时撕不下脸，觉得争吵会伤害彼此的感情与关心，结果导致负面情绪积少成多，一旦爆发就可能是不共戴天的仇人。而同事之间互相争辩讨论问题已经是一种协作方式，大家成天吵来吵去的，没有关系，万一争不成，彼此以前也不是兄弟，即使以后不合伙了，也不会夹杂那么多感情去处理问题。当然这不能一概而论，但以我看了那么多以及结合自己的经验来讲，选择与前同事共同创业会更加稳定。
+
+至于创业团队，在我见过的创业团队中，其实不睦的情况多于和睦的，但能走下来的团队有三个共同点，首先是具有契约精神，之前也提到过这一点，也许有个别和睦的情况是依赖于兄弟之间的信任，但不论如何，承诺过就努力兑现，基于契约精神才能有更多理解与支持。我看到很多初创团队，之所以一路走来，不离不弃，就是因为困难时共赴难关，才坚守住这个合伙团队。
+
+其次是能够互相理解，即使你不同意他的做法，但你理解他做事的合理性。比如你是技术，从技术视角看可能不认同销售的决定或方法，这只是因为你没有真正做过销售，不理解其中的难处，但是你理解他做这样决定的合理性。因为你相信，他有契约精神，做那件事情一定不是为了把其余几个人都坑了，谋他一己私利，而是为了大家的共同目标，为了集体利益而为。
+
+除了契约精神和互相理解外，还有一点是良好的默契，默契与契约精神有差别，默契更多是私下彼此信任，产生了工作中达成一致的更多可能，如果合伙人私交较浅，则更多趋向于遵守契约精神，无论是哪一类，这样的团队都会走的比较稳。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 王鹏云：管理方式的差异是为了更好地实现企业商业价值.md

@@ -0,0 +1,34 @@
+<audio id="audio" title="大咖对话 | 王鹏云：管理方式的差异是为了更好地实现企业商业价值" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ea/ae/eaa55fdb63d267c5c35c8d0ca0543aae.mp3"></audio>
+
+你好！<br>
+本周作客大咖对话的嘉宾是蓝创中心总经理，蓝标产品技术委员会主席王鹏云，他也是前多盟联合创始人，前蓝标移动广告集团CTO，曾任百度高级工程师、魔时网CTO、139移动互联研发总监，在营销领域深耕十多年，同时拥有多年技术管理经验。今天我们和他聊了聊技术管理方法与技术人创业如何把握商业方向这两个话题，若你有不同观点，欢迎在留言区进行讨论。
+
+**极客时间：您能简单介绍一下您自己和您目前所负责的工作方向吗？**<br>
+**王鹏云**：我是产品和技术出身，2004年硕士毕业后就加入百度，算是百度比较早期的成员，2007年离开百度开始创业，陆续有过几次不同领域的创业经历，包括社交网络、移动相关的社群、工具等。2010年创立多盟，后来发展成国内比较大的几个移动广告平台之一，我们在2015年被蓝色光标收购，此后我一直在蓝色光标工作。2017年年底我把多盟的工作陆续交给原来的团队，投入全部精力创立了现在的蓝色光标技术创新孵化中心，重点关注大营销领域的创新创业，如广告、社会化传播、公关等等。
+
+**极客时间：您觉得在技术管理方法上，互联网公司与蓝色光标这样偏传统的企业有何不同，能否分享下您的感悟？**<br>
+**王鹏云**：蓝色光标代表具有两个特质的传统公司，一是规模较大，蓝标目前有五六千员工，二是工作比较个性化，它不是基于一个固有的平台，比如我们认为淘宝是一个平台，上面商家数量虽然很多，但他们是基于一种共同的工作模式，而蓝标是以大客户的营销服务为主，主要根据客户需求和客户差异去安排工作，因此每个项目组或每个产品线的工作都差异很大，管理工作内容的个性化程度也非常高，灵活性非常高。
+
+其实，所谓的传统企业与互联网企业的技术管理方式差异，我认为主要是依赖不同，互联网公司更多依赖于平台、技术等，而蓝标这样的传统公司更依赖个人及团队的能力和智慧，其中个人素质非常关键，因此对人才的依赖性会比较强。
+
+另外，蓝标没有CTO。它的业务当然也会涉及产品与技术，但它不是基于产品与技术来构建团队，而是基于服务价值，这就是很大的区别。可能很多公司的模式是，我有一款产品，然后基于这款产品，进行研发、运营、推广、商务合作等各方面工作，而蓝标是基于客户，给客户营销服务，其中可能需要产品支持，但并不是以产品为核心。
+
+来蓝标之前，我一直在互联网公司工作，工作模式都还比较相近，来蓝标之后，切身感到很多不同的工作方式，以及组织管理架构的不同，我还没有去过更传统的公司，比如传统制造企业，肯定又会有很多的不一样。从这个角度来讲，其实最终所谓的这些差异，都是为了服务于你所要实现的商业价值，为了推进商业价值的实现，每个公司会采取不同的组织架构与形态。比如蓝标会以业务和客户价值为先导，反推我需要什么样的技术工具，需要什么样的数据来支撑业务运行。因此，蓝标的成员构成多数是业务与客户服务相关人员，技术和产品是相对较小的群体，主要以支撑业务和客户服务为工作重心。而互联网公司就会以产品和技术为主。
+
+**极客时间：您拥有多年的CTO经历，并且在负责技术创新孵化中心的过程中，接触过很多CTO，您觉得一个优秀的CTO应该是怎样的？**<br>
+**王鹏云**：这个问题应该很多人都回答过，也提到了CTO应该具备的几大特质，但从我自己多年的经历以及实操经验来看，没有一个CTO能够完备的做到这些点，我觉得没有最标准的CTO所应该具备的特质要求，只有合适的CTO。所谓的“合适”，就是如何用产品、技术、平台、工具等作为支撑，帮助企业的商业价值在最好的时间和场景下落地。
+
+企业有各种形态，包括互联网（产品、工具、游戏、平台）、传统广告业、传统制造业、传统生产企业，等等，每个企业对CTO的要求都不太一样，甚至有些企业根本没有CTO。之前有个蛮火的讨论是“CTO该不该写代码”，在我看来不能单看这个问题的是与否，我们需要考虑CTO的工作中需不需要他写代码。比如CTO负责的是公司最核心的技术驱动，那他写代码是必须的，他必须带领技术团队完成这项使命，但如果在相对成熟、比较传统的业务中，CTO需要做的就是优化工具，支撑业务，并审时度势这个业务现阶段需要什么样的产品和技术，然后设计最合适的支撑体系，而不是写代码、做系统架构等，这些交给技术总监来做就足够了。
+
+因此，我认为CTO不要给自己套太多的框，比如“我好久没写代码了，技术是不是退步了，心里好慌，是不是应该多分配点精力在写代码上”等等，如果你所在的公司、所处的位置不需要你写代码，而你却将精力纠结于这件事上，反而可能会落下更重要的事情。
+
+**极客时间：技术人创业，该如何准确地把握商业发展趋势？**<br>
+**王鹏云**：创业的核心一定是实现商业价值，并达成双向收益，你给用户贡献你的价值，同时你也能把钱收回来，这两项缺一不可。原因很简单，只收钱，不提供价值就是骗子公司，只贡献价值收不回钱，这样的公司难以维持。一个可持续发展的公司是一定是双向收益的，在此过程中，最主要的是关注大势、理解大势，然后顺势而为。
+
+有些大势是显性的，有些是隐性的，比如乔布斯发明苹果是不是大势？我认为是，不过很多人觉得是乔布斯创造了一个大势，但在我看来，智能手机在当时是隐性的大势，因为当时的市场满足不了用户对于智能手机的需求，但需求已经是真实存在的。在苹果之前，已经有一些手机可供用户处理文档、存储音乐等，用户知道智能手机可以做这么多事情，他们的需求已经被唤醒，呼之欲出了，这时乔布斯做了苹果，满足了这个需求，所以大势一下爆发。
+
+顺势而为很重要，而如何理解大势并不是一个可以快速入门的知识，它需要我们持续的关注与思考理解，并融合与洞察这个行业的运行与变化，以及了解社会中各阶层、各领域的人是如何思考，如何行事的，你了解的信息越多，对宏观大势的理解就越准确、越深刻，之后再做创业方向的选择，就会更完备。
+
+另外，我建议在当前环境下，创业不要想太多，不要再去想太多颠覆平台的事，而是多想想怎么利用平台，在平台上做好事。都说现在是互联网下半场，但下半场不代表没有机会了，而是意味着在一些成熟的领域，大平台已经形成，此时创业颠覆大平台的可能性越来越小，但基于大平台延伸到别的领域做事情的机会并不少，比如产业互联网，基于原来的平台去改造产业和升级产业。这个市场盘子并不小，动辄都是千亿万亿级别，善于利用资源能帮助我们走的更远。至于具体的创业方向的选择，每个领域都不同，要结合我们自身的特点与能力、结合行业机会与自己拥有的资源去做选择。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 王龙：利用 C 端连接 B 端实现产业互联网是下半场的重中之重.md

@@ -0,0 +1,53 @@
+<audio id="audio" title="大咖对话 | 王龙：利用 C 端连接 B 端实现产业互联网是下半场的重中之重" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/86/26/8683017210dd741474c9d7ded22b8c26.mp3"></audio>
+
+你好！
+
+本周大咖对话的嘉宾是腾讯云副总裁王龙，具有多年中、德、美三国工作经验，曾就职于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（风险投资）的企业。现在这种情况会促使大家更谨慎地审视产品的价值，更小心的验证自己的商业模式。而最早云的诞生原因就是为了帮助开发者和合作伙伴降本增效、快速创新，这些能力都是开发者在当前环境中最需要的。
+
+我觉得每经历一轮这样的低谷，云和开发者的能力都会得到更好地锻炼，也都会为下一轮的增长打下更好的基础。
+
+**极客时间：在这种环境下，作为一名技术管理者应当如何帮助内部团队渡过这段时期？**
+
+**王龙**：我在中国、德国和美国做管理有十几年的时间，经历过几个经济周期。不管大环境如何，我认为总的管理方法论是不变的。首先，要目标清晰。要给团队制定短、中、长期的战略目标和规划，这个规划一定要明确和可衡量。其次，要帮助团队里的各层级负责人，驱动他们把目标分解给下一级团队能理解的小目标来执行。最后，要非常关注团队成长，要帮助成员获得更多的知识，获得更宽广的视野。只有成员不断成长，团队才能不断成长。
+
+在跨部门的协调方面，我个人有一些总结。其实不管是跨部门还是和合作伙伴、客户的协调，最重要的一点是要具备同理心。通过同理心来寻找共同共目标、共同利益点。具体来说，就是要多站在对方的立场上考虑问题，只有这样，双方的合作才能变得更加顺畅。当然，最好在具体执行层面就把两边团队乃至个人的小目标对齐。
+
+感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 童剑：用合伙人管理结构打造完美团队.md

@@ -0,0 +1,73 @@
+<audio id="audio" title="大咖对话 | 童剑：用合伙人管理结构打造完美团队" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ef/69/efca881c79ebd1a7c88cedb63cacd469.mp3"></audio>
+
+你好！
+
+本周作客“大咖对话”的嘉宾是童剑，国内云计算领域知名专家和早期实践者。现担任白山云科技联合创始人兼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 鲲鹏会](http://tgo.geekbang.org)北京分会董事会成员&amp;学习委员。前新浪研发中心总经理，2016 年 5 月加盟白山，迅速搭建和完善各产品线技术梯队，构筑云链产品技术体系，带领团队推出云存储、云聚合产品，助力白山抢先布局云后市场。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 管理者是首席铲屎官？.md

@@ -0,0 +1,63 @@
+<audio id="audio" title="大咖对话 | 管理者是首席铲屎官？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/99/c5/99dbaaecfb7d3a12036c3dbdc97c74c5.mp3"></audio>
+
+你好！
+
+本周作客“大咖对话”的嘉宾是陈皓。网名左耳朵耗子，独立运营技术博客酷壳 CoolShell，也是极客时间《左耳听风》专栏的作者。他拥有 20 年软件开发及相关工作经验，在团队管理、项目管理，以及程序员个人成长等方面拥有自己独特的见解和方法。今天，我们和他探讨了该如何修炼成优秀的技术管理者。
+
+## 极客时间：在您看来，如何才能打造高效的研发团队呢？
+
+陈皓：管理基本上是三个事，管人、管事和自我管理。
+
+**管人的意思就是管团队**，除了要招聘到很好很强的人才，组建一个很强的团队，并不断提高团队的实力之外，还需要做的是激发团队的热情，培养他们的主人翁精神，这样才能够更高效地开发日益复杂的软件产品、解决日益困难的技术问题。因此，管理者需要在各个方面都坚持比较高的标准，并不断得提高团队的能力标准。
+
+**管事的意思是要找准方向**，如果你的方向是错的，即使你有一个好的团队，也是没法高效起来的。另外，找到正确的方向之后，还要落地执行，而在执行过程中，会有各种各样的问题需要你去解决，包括对第三方的依赖、条件受限（时间不够、人力不足）、以及各种没有考虑到的项目风险。有时，一个小问题就可能会影响到整个项目的进度。所以，如何把复杂的逻辑简化掉（简化而不是简陋），如何把复杂的问题拆解成小问题并各个击破，如何在受限的条件下抓重点，如何说服别人统一大家的目标……这些都是管理者需要负责的。
+
+**自我管理的意思是说管理者自身的素质和自我的成长**，通常来说，管理者就是这个团队的天花板，如果管理者自己不成长，那么团队就会受限，所以，管理者要修炼自己硬技能和软技能等各方面的能力，包括个人魅力、沟通能力等，从而提高自己的影响力。所谓影响力并不在于职位高低，而是当别人有困难的时候，是否会想到向你寻求建议或支持。一个leader的关键素养就是要能服众，能获得团队和客户的信任，之后，自然会赢得老板的信任。
+
+如果这三个方向能做好，那一定能打造出一个非常好的研发团队。
+
+## 极客时间：一位优秀的技术管理者必备的能力和素质有哪些？
+
+陈皓：好的管理者一定要具备两个素质，一是明白自己的定位，二是能激励团队。
+
+**先来说第一个素质，自我定位。** 要明白作为管理者，是来帮助团队，而不是阻碍他们前进、阻碍他们创新的。因此，如果你懂，你就一起来干，如果你不懂，那就相信团队，放手让团队去做，千万别外行领导内行，这是非常不好的做法。
+
+我一直戏称leader是首席铲屎官，团队在前进的过程中，一定会遇到很多阻碍，这时候就需要leader在前面把这些不好的东西都解决掉。
+
+比如跨团队合作时，跟其他团队的沟通与协调；比如团队遇到不合理的流程时，leader需要将其不断优化；比如遇到团队内影响士气的不和谐声音时，leader就需要狠得下心去解决；比如面对客户、老板等压力时，leader需要一肩承担等等。
+
+当然，这里不是说就不能给团队压力了，而是说不能把没有经过过滤的负面的外部压力直接传递给团队。你给团队的压力，一定是你已经消化过的、跟团队整体成长相关的正面压力。
+
+因此，管理者肯定是孤独的，哭得自己哭、压力得自己扛，但取得的成绩、获得的好处一定得交给整个团队。最糟糕的做法就是成绩是自己的，问题是团队的，这样一定会导致众叛亲离。
+
+**再来说第二个素质，能激励团队**，也就是能驱动团队成员有主人翁精神、有ownership。技术研发是知识密集型项目，不能沿用传统的“命令与控制”Command &amp; Control的管理方法。这种管理模式之下，大家多会觉得所做的事情与我无关，是你老板的事情。
+
+激发主人翁精神的一个关键就是让团队成员有参与感，而要让他们获得参与感就需要赋予他们建议权甚至是决定权。同时，领导者需要往后退一步，把命令变成协作和引导。
+
+所谓协作，就是我们彼此帮助，团队的事务和进度不是来自于老板的鞭打，而是来自团队成员间的相互协作，同时管理者还要兼顾到员工的兴趣点，你为他们实现理想，他们才会为你实现理想。
+
+所谓引导，就是我不再以指令和控制的形式告诉你要做什么，而是通过给出一些问题、提供一些工具或方法让团队成员自己找到答案，管理者这时要做的不是一个奴隶主，而是一个教练或是一个老师，传道授业解惑。
+
+这里的关键其实就是看管理者的心胸够不够大，能不能容忍员工犯错，错误是成长的关键，只有痛过，才会真正努力。另外，管理者还要多问问自己，你是更多地关注事情的结果，还是员工的价值与成长；你是更多地关注眼下的事情，还是长远的目标。
+
+在协作和引导这两种方式的共同效益下，员工会有非常高的参与感和归属感。当然，当你需要去攻坚、去打硬仗的时候，还是需要Command &amp; Control，但这不应该成为常态，而是只在特殊情况下采取的特殊手段。
+
+在具体执行中，一个比较好的方法就是变问答题为选择题。问答题就是员工会问这事怎么做，这个问题怎么解，而你告诉他该这么做，这样的模式下，员工永远成长不起来，团队也不会变强。
+
+选择题就是引导员工，下次再说什么事，先拿出一二三个方案，列出每个方案的优缺点，并给出他们看好的方案，你再在其中做选择，这样就会逼着他们去想各种解决方案。同时，如果每次他们的选择跟你的相似，那么就表明他们已经锻炼出来了，可以自己做决定了，你也就可以放权给他们了。
+
+**给员工放权的多少是一个团队是否强大的表现。最差的管理是家长式的保姆式的管理。**
+
+## 极客时间：如何才能找到适合自己的管理风格呢？
+
+陈皓：我之前讲了那么多，其实都只是我的管理经验，我的管理更偏人性化风格一点，但每个人的管理风格是不一样的，也没有哪一种定式的风格是最好的。
+
+在管理的象限图中，第一象限是团队，第二象限是质量，第三象限是流程，第四象限是成本。
+
+不同的管理风格会偏重不同的象限，而且一个管理者最多只能偏重其中的两项，而且还不能是处在对角线上的。因为对角线都是有冲突的，比如太注重流程，团队就会没有活力，或者关注质量，成本就难免会变高等。另外，相邻的两个象限是互补的，比如好的质量必须要好的团队和高效的流程来保证。
+
+每个人的管理风格都是不一样的，而我的风格更偏重团队和质量这两点。大家也可以做一些测试来测自己的管理风格，比如当系统出现故障的时候，你会怎么办？是先惩罚人，还是先弥补流程，还是先总结错误。其中并没有哪个答案是标准答案，就看你选择什么，而你的选择会展示你的偏好。
+
+最后，没有定式的管理方法，找到自己的管理风格是最重要的。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 胡哲人：技术人创业要跨过的思维坎.md

@@ -0,0 +1,69 @@
+<audio id="audio" title="大咖对话 | 胡哲人：技术人创业要跨过的思维坎" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a8/b3/a8122c2cbdc76fa8013fe6bb8c1313b3.mp3"></audio>
+
+你好！
+
+本周作客大咖对话的嘉宾是流利说联合创始人兼CTO胡哲人，在创立流利说前，他曾任美国著名互联网大数据AdTech公司Quantcast资深软件工程师，负责多个核心产品功能的前后端开发，拥有丰富的大型软件和大数据分析系统的架构经验。今年9月，流利说在纽约证券交易所挂牌上市，被誉为“AI+教育”第一股。今天，我们和他聊了聊创业、管理相关的话题。
+
+**极客时间：能分享一下您当时为什么选择回国创业？**
+
+**胡哲人**：创业之前，我一直在湾区工作做程序员。选择做工程师，包括我最初选择计算机行业的初衷，都是希望能把一个产品从无做到有。正好在那个时间点遇到了志同道合的朋友，国内创业也正蓬勃兴起，就决定一起回国创业。
+
+从我下决定到回到国内，前后不到一个月时间，真的是很快的一个决定，完完全全的“从心”，follow my heart。
+
+现在回过头去看，还是蛮佩服那个时候的自己的，因为真正创业之后，才意识到这是一件多么困难的事情，一路走来处处都是挑战，需要全身心的投入。但可能正是因为我对创业的困难没有那么了解，当时才会那么快的做下决定。
+
+当然，现在来看，这个决定是非常正确的，我非常享受这个把事情从0做到1，再从1扩张到100的过程。在这个过程中，我克服了很多挑战，接触了很多之前没有接触过的人和事，看到了很多不一样的风景，对很多事也有了不一样的思考和感悟，这让我收获了非常大的成长。
+
+**极客时间：您提到有很多挑战，那您创业以来遇到的最大的挑战是什么？**
+
+**胡哲人**：一个比较大的挑战是，创业后，我逐渐地从工程师的角色转到更偏管理者的角色。老实讲，我之前并没有管理过这么大的团队，在这样一个角色转变的过程中，遇到了很多挑战。
+
+其中之一就是思维上的转变，最最开始的时候，我其实对做管理有一点排斥或者说胆怯。因为之前一直在做技术，面对的是机器和代码，所有东西都由0和1构成，比较简单明了，而做管理的话，面对的是人，远比0和1要复杂，也担心自己是否能把管理做好。
+
+当然在之后的实践过程中，我慢慢发现了自己在管理方面的一些特长和优势，也找到了技术团队管理的要点，形成了自己的管理风格。
+
+**极客时间：您能分享一下您的管理风格吗？**
+
+**胡哲人**：因为我之前在湾区的经历，我会希望我的风格能更接近湾区的管理方式。
+
+作为管理者本身，我觉得非常重要的一点是，自己要做好榜样。在很多事情上，我对团队有怎样的要求，那我自己也要达到这样的要求，甚至做到更好，起到榜样作用。古语有言，知之非难，行之不易，你怎么做要比你怎么说重要得多。
+
+而在具体的管理上，我不提倡micromanagement，也就是微观管理，把管理做得特别细。我会在把公司目标和当前要做的事情跟团队传达清楚的情况下，授权给团队，给团队更多的自由度，让他们能自主的去思考、去执行。
+
+另外，毕竟我管理的是技术团队，所以我相信代码可以解决很多问题。我们应该尽可能的去用代码治理，而不是靠人治。
+
+比如，当我们遇到问题，或内部需要做一些事情的时候，我的第一反应就是，这件事是否能够用工具或机器等手段自动化的去解决，之后又是否能够自动化的发现类似问题并解决。现在，这也已经成为我们团队很多leader的第一反应。
+
+我比较幸运的是，我的管理风格恰好跟公司当前在做的事情比较吻合——用技术手段解决英语学习问题，能在这样的环境里去推行实践这样的管理风格。
+
+**极客时间：在线教育行业的竞争十分激烈，流利说的竞争力是什么呢？**
+
+**胡哲人**：我们的做法跟很多在线教育产品不太一样，我们是真正用技术、用AI等手段解决教育环节中的问题。用人工智能技术为用户提供AI英语老师，然后基于机器学习、深度学习等技术，为用户提供个性化的学习课程，提高英语学习的效率。
+
+这也跟团队基因有关，我们三个创始人都是互联网技术和产品出身，所以一开始就是从产品和技术的角度出发去打在线教育市场。这条路比较难，前期也需要更多的积累。
+
+不过，在线教育跟其他互联网领域不太一样，它的先行者优势没有那么强，简单来说，这件事情你是不是第一个做，是不是第一个吃螃蟹的人没有那么关键。因为教育是一个非常重内容、重品质、重服务、重口碑的行业，快不是关键，走的方向对不对、走得稳不稳才是关键。
+
+基于这个认知，我们发现，我们要从一个用户喜欢的产品跨越到一个成功的商业产品，就必须在内容上下功夫，打造自己的系统化课程。之前流利说上的内容都是比较碎片化，也没那么成体系的。
+
+最开始我们想跟出版商合作，但不幸的是，他们的教材都太陈旧了，大部分都没有数字化，即使有些内容是数字化的，也只能在 PC 端上实现，很难满足移动端的用户需求。
+
+我和我的创始人都是产品和技术出身，对教育没有那么了解，因此要下决定投入那么多成本和时间去做课程，一开始还有些挣扎。但最终，我们还是决定这件事情得自己来做，因为只有我们才最了解我们的用户，了解他们在移动端上想要得到什么样的体验。
+
+于是，痛定思痛，我们开始深入了解教育，并投入大量的资源，引入教研相关的人才，然后教研、技术和产品三方一起，花了十八个月的时间，自主研发了一套符合移动端逻辑的英文原创教材，并将其数字化，将原本只存于书本上的内容通过原创插画、动画、语音等形式在移动端重构，也取得了非常好的反响。
+
+另外，教育的好处在于，它的内容的生命周期很长，像现在非常火的短视频，一个短视频的生命周期就非常短，即使是电影或电视剧，它们的生命周期也没有想象中的那么长。
+
+但教育类内容的生命周期非常长，比如我小时候学过新概念英语，到了现在依然有人在学，而这本教材已经诞生几十年了。从这个维度来看，我们投入重金打造系统课是非常值得的。
+
+**极客时间：关于技术创业，您有什么经验可以分享给我们的创业者？**
+
+**胡哲人**：很多技术创业者都想打造类似Facebook、Instagram、WhatsApp这样的轻资产型的产品，就是几十人的小团队，做出一个用户量庞大的超级产品。
+
+但如果我们把视野收拢在国内，类似这样的机会已经不多了，特别是在垂直行业。我们在垂直行业创业，想用技术、用互联网思维推动行业改变的话，很多时候需要摒弃一些技术人的固有想法，更多的是需要深入去了解所处的行业，了解他们真正需要什么。
+
+最开始的时候，我们也想把产品做得轻一些，能够打造一个轻资产型的公司。毕竟我的两个合伙人都是来自谷歌，而谷歌就是非常标杆的轻资产型的公司。但在垂直行业，这么做越来越困难的，以流利说为例，最终，我们还是选择投入大量资源打造属于自己的原创教材和课程。
+
+技术人创业一定要跨过这个思维的坎，这是我们创业过程中最深的一个感悟。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 袁店明：如何将打造自组织团队落诸实践.md

@@ -0,0 +1,61 @@
+<audio id="audio" title="大咖对话 | 袁店明：如何将打造自组织团队落诸实践" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/29/9b/29ff2590c7e223d573151f7e196fdd9b.mp3"></audio>
+
+你好！
+
+本周作客大咖对话的是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，意思是一个用户故事的内容要是可以协商的。
+
+但很多人就忽略了协商因素。我在辅导团队时，通常会用电子工具来管理用户故事，从中能够看到用户故事的版本记录。如果一个用户故事从初稿到终稿都是由产品负责人拍板，中间没有其他任何人做改动，那这个用户故事一定是有问题的。合理的做法应该是在产品负责人写完初稿后，开发和测试再将用户故事细化，最终经过协商后确定终稿。
+
+我认为每个用户故事都应该加入技术人的产品思维。因为，产品经理虽然从用户端了解到了他们的需求，但对于实现需求的产品逻辑与细节，技术团队才是最清楚的，所以，产品负责人应该与开发团队共同协商，形成最终解决方案。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 袁店明：打造高效研发团队的五个要点.md

@@ -0,0 +1,87 @@
+<audio id="audio" title="大咖对话 | 袁店明：打造高效研发团队的五个要点" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/66/af/66f2f72994b2fda52b9e035b6177ebaf.mp3"></audio>
+
+你好！
+
+本周作客大咖对话的是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。<br>
+2.个人成长，了解团队成员的职业生涯或成长通道，按照这个方向帮助他提升个人能力。<br>
+3.尊重与认可，关注团队中的个人，给他尊重与认可。当然，这方面也需要团队的透明制度作为支撑。
+
+在激励个人方面，Scrum Master会起到关键作用，他需要具备良好的引导技巧，（这也是我为什么去学引导技巧的原因），运用引导技巧，能够让团队中的每个人互相尊重，良好协作，高效沟通。
+
+需要注意的是，Scrum Master虽然担负如此重要的职责，需要解决团队中所有的问题，消除达成目的的障碍，但是，Scrum Master本身没有权力，也不需要权力。因为有权力的团队无法自驱动与自组织，Scrum  Master应该依靠的是他的能力和影响力。
+
+## 第五、透明的考评机制
+
+考评机制是一个敏感话题，但对团队非常重要。在阿尔卡特朗讯内部曾经有一套“七二一”法则，其中，“七”代表对公司业绩的贡献，很好理解。
+
+“二”是指团队产出的占比，是团队与团队之间的考评。比如在互联网公司，产品团队、开发团队之间互相考评，如果考评机制透明，他们互相打的分数就应该相对公平、公正。
+
+当然，这是一个考核标准，考核的是产出量，另外，我们还可以考核产品上线后产生的缺陷量，这个数据很好统计，但往往会被忽略。因为有些人认为这样做很伤人，但其实，要想做到不伤人也很简单，就是将考核机制透明化、数据透明化，如果你认为不该是你背锅，你就可以申诉。
+
+最后是“七二一”法则中的“一”，这10%是对个人能力成长的考核，我们不谈个人在过去一年对团队的贡献，而是关注他的成长，由团队来考评成长分数。
+
+类似的，国内很多公司在用360度环评，考评内容包括工作能力、表现能力、沟通能力、协作能力、执行能力、分析问题的能力、解决问题的能力等等。从360度环评表中，我们可以获取所有协作者对某个人的评价与反馈，因为360度环评是透明的，每个人收到或发出的分数与评价都必须透明。
+
+所以，拥有一个透明的考核机制非常有必要，能够促使团队自发地愈来愈优秀。
+
+最后小结一下，以上提到的透明、规则、权责、激励、考评这五点，就是我多年实践下来，总结的对于打造高效研发团队最重要的五个要点，希望能给你带来参考。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 让团队成员持续的enjoy.md

@@ -0,0 +1,43 @@
+<audio id="audio" title="大咖对话 | 让团队成员持续的enjoy" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/49/ba/49019a7dd693c00c6e9652dee50607ba.mp3"></audio>
+
+你好！
+
+又到了“大咖对话”时间，今天的嘉宾是饿了么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鲲鹏会](https://tgo.geekbang.org)上海分会会员。曾带领携程软件架构团队 &amp; 框架研发团队，后担任携程国际 BU CTO。曾有过一次创业经历（教育行业），深知创业之痛并快乐着的感觉，理解创业之苦、之难、之惨烈。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 谢孟军：技术人如何建立自己的个人品牌.md

@@ -0,0 +1,63 @@
+<audio id="audio" title="大咖对话 | 谢孟军：技术人如何建立自己的个人品牌" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/f8/88/f8a85e17ebae8579ff58cec6392a8188.mp3"></audio>
+
+你好！
+
+本周作客大咖对话的是积梦智能创始人兼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中相关的、有价值的部分应用到业务中去，加快业务的发展速度。可以看到，这个开源项目是对我负责的业务有帮助的。
+
+所以，我基本是把业余时间扑在开源项目上面，然后工作时间的话，把项目中有价值的、能起到作用的部分应用到自己的业务中，两者相辅相成，这样把握两者之间的平衡会更好一些。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 谭待：架构的本质是折中.md

@@ -0,0 +1,69 @@
+<audio id="audio" title="大咖对话 | 谭待：架构的本质是折中" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/8c/3b/8cab50198069270f3c89c6e918cc743b.mp3"></audio>
+
+你好！
+
+本周作客“大咖对话”的嘉宾是百度搜索首席架构师兼区块链实验室主任谭待。他的主要研究领域在分布式系统、搜索引擎和区块链，是百度BVC代理计算和Matrix私有云的主要设计者，两获百度最高奖。主持设计了百度新一代搜索架构，在时效性和计算规模上实现了大幅提升；同时也主导了极速搜索、全站HTTPS等百度搜索的一系列重大革新。
+
+**极客时间：您现在身兼百度搜索首席架构师和区块链实验室主任，这两个不同角色之间的差异大么？您如何调整自己适应不同的要求？**
+
+**谭待**：在百度搜索这边，我作为首席架构师，是一个IC的角色，也就是独立贡献者。百度跟很多互联网公司不一样，百度的技术序列是不带人的，即使要推进项目，用的也是非职权管理的方式，更多的会依靠技术人自身的影响力，而不会涉及到具体业务相关的管理。而在区块链实验室这边，我作为主任，就要承担很多业务相关的管理工作。
+
+我需要在这两个角色之间互相切换，而不同角色的要求是不一样的。
+
+作为技术负责人，虽然也会有非职权管理的场景，但更多的是需要把个人的聪明才智发挥出来，找到关键点，把事情给解决掉，体现出你的技术价值。同时在宏观方面，还要着眼整体技术方向的演进，以及技术梯队的培养等工作。
+
+而作为管理身份，简单来说，就是不能像原来那么挑活了。原来作为技术Leader，我可以只看最关键的事情，剩下的反正有经理帮着兜底，如人员问题、预算问题等，我都可以不去管。但现在作为一个业务的管理者，我变成了那个兜底的人，需要把很多精力分到一些看上去非常琐碎，但对整个部门发展非常关键的事情上，比如上面提到的人员招聘、预算制定等。
+
+除此之外，最大的挑战是思维方式的改变。
+
+在搜索这边，我依旧保持之前的思路和做事方式，保持对技术的判断力，找出技术的最优解，发挥技术的最大价值。
+
+但在区块链实验室这边，我反而需要主动克制自己对技术的感觉，不要过多的参与到一些非常细节的技术讨论和判断中。甚至有时候我有更好的想法，也要忍住，不能直接提出来，而是要慢慢引导团队，或者让他们自己去尝试。
+
+主要原因在于，一方面，我作为业务管理者过多的参与技术方案的制定，对整个技术团队的成长并不是一件好事；另一方面，作为管理者，我需要将更多的时间和精力分配到整体的业务和战略上，以及对内对外、向上向下的各种协同合作中。
+
+总的来说，我现在也不算是从技术转向管理，而是同时保留了这两种角色，有点人格分裂的感觉，但也是非常有意思的挑战。
+
+**极客时间：回顾一下您的职业生涯，对您影响最深的事情是什么？**
+
+**谭待**：这么多年下来，感触深刻的事情还蛮多的，我分享一个至今仍对我产生影响的事情吧。
+
+2007年，我进入百度开始实习，加入了一个主攻云计算方向的团队。当时这个团队聚集了百度最优秀的人，公司也给了非常大的支持。
+
+一方面，一毕业就加入一个可以说是当时全国最优秀的团队，得到了很多牛人的指导，这对个人的成长非常有帮助，最关键的是在这个过程中养成了很好的技术素养和做事方式，对我的职业生涯起到了奠基性的作用。
+
+另一方面，这个项目后来失败了，它有着最优秀的团队，做的也是云计算这样符合技术趋势的事情，但它最后却失败了。可以说，如果它成功了，那它对我的触动还没有这么大。
+
+我时常回顾它的失败原因，其中最大的一个原因是，它没有吻合产品的发展步调。
+
+这是一个技术型项目，但它最终是要服务于某一个业务和产品的。然而，这个项目在设计之初，就和产品的步调脱节了，它的发展计划没有很好的吻合产品的发展计划。所以，虽然它的技术很出色，取得的成果也不错，但产品等不了它出成果、出方案，最终就用了其他方案。对这个项目来说，它就是失败了。
+
+大家都知道，技术要结合业务和产品的发展，但老话说的好，知易行难，知道归知道，要做到知行合一是一件很难的事情。很多技术人，在执行过程中，会不自觉的追求最前沿的技术，会很自然的从自己的角度出发思考问题，而忘了考虑产品的需求与步调，最终导致两者脱节。
+
+这件事情对我的影响很深，一方面，它帮我培养了非常好的技术素养，让我懂得在做技术规划的时候，要往前看，往远看；另一方面，它也提醒我，你可以站的很高，看的很远，但你的每一步落地，都必须要接地气，踩中业务方的节奏。
+
+**极客时间：您从事架构相关工作多年，在您看来，架构的本质是什么？**
+
+**谭待**：架构的本质是折中，作为架构师，你拥有的是有限的资源，如人力资源、机器资源等，但你面对的是没有上限的需求，如工期的需求、稳定性的需求等，所以需要在不同的层面做出折中的选择。
+
+你不可能做出一个完美的解决方案，必然要牺牲一些东西来达成另一些需求。所以，从宏观的整体架构设计和安排，到最终每个功能点的实现，都是折中的。
+
+比如，我过去设计方案的时候，会做不同的Milestone，选择不同的Feature List，这是一种广泛的折中。再具体点说，你做方案的时候，不管是用空间换时间，还是用时间换空间，都是一种折中。
+
+展开来讲，首先，作为架构师，要明确你设计系统最终还是为了产品和业务，所以，你要了解产品和业务的需求，并做出相应的预判，比如预判这个产品三年以后会是什么样的。这样，你设计的系统，就有足够的预留空间和生命周期。
+
+在百度，我们设计系统的时候，一般会去看业务三年以后的情况，这样做出来的系统，至少在三年内能比较好的支撑业务发展。另外，硬件基础设施一直在迭代，三年后很可能就发展到一个新的阶段。这时就可以根据新的业务情况和硬件条件重构系统，也能借此机会让团队更好的熟悉原来的系统。
+
+其次，作为架构师，在设计系统的时候，一定要找到关键点。折中不是平庸，而是为了更好的在某些关键点上突出，为此，可以在别的地方做出牺牲。
+
+我父亲小时候给我讲了一个故事，至今印象深刻。20世纪初期，美国福特公司的一台电机出现故障，很多人花了两三个月都修不好。在束手无策的情况下请来了专家斯坦门茨，斯坦门茨在电机旁边仔细观察，又计算了两天后，就用粉笔在电机的外壳上画了一条线，说：“打开电机，在这条线往里的线圈减少16圈。”结果证明，问题果真出在这里。
+
+这个故事给我的感触很深，作为架构师，你一定要成为那个划线的人。一个架构会涉及方方面面，不可能全都很好的顾及，所以，你需要找到那条线，找到问题的关键，并将其解决，这才是最能体现架构师价值的地方。
+
+举个例子，我做过的极速搜索项目，这个项目目标是把搜索平均速度提高两倍。我之前一直负责搜索中的底层分布式的系统，分布式系统里的很多折中是怎么把时间和空间进行互换。之后，我接手极速搜索项目。之前，大家做速度优化，普遍的思路是看哪个地方慢就优化那个地方。我没有这样的惯性思维，而是想着，分布式系统里的那种用空间换时间的做法能不能应用到速度优化上来。
+
+最后我的方法是，系统提前预测用户的搜索目标并实时抓取，当用户点击搜索时，就把搜索结果瞬时展现出来。这么做必然会消耗更多的资源，但却能极大提升搜索速度，基本可以把搜索请求时间缩短至原来的10%。
+
+可以说，“用空间换时间”就是我划的非常漂亮的一条线。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 陈天石：AI 芯片需要技术和资本的双重密集支撑.md

@@ -0,0 +1,62 @@
+<audio id="audio" title="大咖对话 | 陈天石：AI 芯片需要技术和资本的双重密集支撑" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d6/b6/d6af51392fdb1e63ac730b147e048fb6.mp3"></audio>
+
+你好！
+
+本周大咖对话的嘉宾是寒武纪创始人兼 CEO 陈天石博士，近年来，AI 成为科技领域内最受关注的话题，芯片行业也开始高频率地出现在大众的视野之中。而寒武纪作为国产 AI 芯片创业领域的头部独角兽，如何在巨头涌入芯片赛道后继续保持“独立”？我国芯片产业的前景何在？芯片产业当下的挑战和未来的发展趋势又是什么？在采访中，陈天石博士与我们分享了他的观点。
+
+**极客时间：陈博士您好，能先简单介绍一下寒武纪目前的芯片产能和自研情况吗？**<br>
+**陈天石**：寒武纪拥有终端智能处理器和云端智能芯片两条产品线。<br>
+针对终端应用，我们在 2016 年就推出了世界首款终端人工智能专用处理器——寒武纪 1A 处理器（Cambricon-1A），面向智能手机、智能视觉、可穿戴设备、无人机、机器人和智能驾驶等各类终端设备，早于国外同类型产品两年以上。
+
+2017 年开始，我们先后发布了第二代多核智能处理器寒武纪 1H 及第三代高性能智能处理器寒武纪 1M。1A、1H 分别应用于麒麟 970 与麒麟 980 芯片中，迄今已累计服务了千万台智能手机终端。
+
+2018年 5 月，我们发布了云端人工智能芯片 MLU100，开始从云到端全面的人工智能计算力生态布局，目前 MLU100 已进入大规模量产阶段，与浪潮、联想、曙光、H3C 等服务器厂商的适配机型已开始陆续出货。
+
+对于2019 年，除了完成现有产品线的升级迭代外，面对更复杂的云端智能训练应用、轻量级的边缘端场景和消费类电子产品，我们还将推出一系列新的芯片和 IP 产品。另外，在与民生紧密相关的 AIoT 领域，寒武纪也会做重点赋能。
+
+**极客时间：芯片行业并不是个新兴产业，市面上已有如 CPU、GPU 等诸多类型的处理器长期存在。和其他类型芯片相比，智能处理器诞生与发展的必要性是什么？**<br>
+**陈天石**：深度学习是目前 AI 领域机器学习方法中最为有效的算法，深度学习模型需要大量的数据训练，这就要求处理器有极高的运算速度作为支撑。
+
+传统 CPU 基于低延时的设计，拥有复杂的内部结构，优点是拥有针对各种不同类型数据的计算能力以及逻辑判断能力，适合进行复杂逻辑的问题处理和计算设备内的管理调度。而深度学习模型所需的运算能力极高，传统架构处理器无法做到功耗与速度上的平衡——通常需要成百上千条指令才能完成对一个神经元的处理。
+
+目前人工智能行业内主流做法是采用 GPU 并行计算神经网络。GPU 是专门进行图像运算工作的处理器，因为它在浮点运算、并行计算等方面的性能优势与人工智能的需求不谋而合，于是在人工智能爆发的关键期，GPU 被广泛使用。但是作为图像处理器，GPU 在推理阶段无法充分发挥并行优势，另外由于 GPU 的计算方式不是为深度学习算法专门设计，性能峰值无法被完全利用。
+
+所以，人工智能行业需要经过专属设计优化的处理器，来应对计算密集型应用场合——不需要面面俱到、八面玲珑，但要有强大的执行力，速度一马当先；同时，也不会带来过高的功耗，这是 AI 专有的速度与激情。
+
+而寒武纪芯片是专门针对深度神经网络计算而设计的 AI 处理器。针对传统 ASIC（将单个特定算法硬件化）思路无法解决深度学习处理需求这个问题，我们通过多年研究，采用硬件神经元虚拟化，稀疏神经网络处理器架构等技术以及深度学习指令集打造了寒武纪的 AI 芯片，使得寒武纪芯片在执行 AI 计算任务时能效可以实现最大程度的优化，和同类产品比速度可以实现大幅提升。
+
+**极客时间：现阶段芯片发展到了什么阶段？目前面临的最大挑战点和难点在哪？**<br>
+**陈天石**：从人工神经网络的雏形在上世纪四、五十年代被提出开始，人工智能发展几经起伏。近年来，得益于算力、算法、大数据等各个要素上的全面突破和创新，在现阶段，AI 技术应用发展如火如荼。
+
+作为 AI 核心的底层硬件——芯片，也同样经历了漫长的发展过程，从 CPU 到 GPU 再到专门的 AI 芯片，我们一直在试图通过硬件架构创新，去追求计算效率、性能和能效比等性能上的进一步攀升。
+
+目前，随着深度神经网络的层数日益增多，规模日益庞大，AI 芯片发展始终在面对严峻挑战，并需要持续完善以下3个方面：
+
+1.算力资源储备 —— 网络规模变大之后，如何用足够的计算能力来支持如此庞大复杂的深度学习模型；<br>
+2.功耗与成本 —— 如何在超大规模并行计算中更好地兼顾性能与功耗，同时成本可接受；<br>
+3.性能与灵活度 —— 如何能在拥有更适合 AI 计算特点的丰富算力的同时，让算力适用于尽量多的行业与应用场景，满足云端计算中的应用多样化需求。
+
+曾有人开玩笑说，现阶段 AI 的最主要矛盾是 PPT 中体系健全 / 理论完备的全行业解决方案与现实中难落地难实现的实际应用之间的矛盾。作为最底层基础，AI 芯片提供的计算力是连接算法和海量数据的桥梁，是 AI 解决方案得以真正在传统应用中顺利落地的钥匙。
+
+**极客时间：在您看来，芯片产业未来的发展趋势将会是什么？**<br>
+**陈天石**：AI、大数据、云计算等技术的兴起对处理器提出了不加上限的性能需求，而芯片产业经过 50 余年来的发展，面临着通过架构创新来实现突破性进步的瓶颈。
+
+为了解决海量数据的处理效率问题，无论是在大型数据中心的服务器中还是在芯片内部，异构计算已成为目前越来越普遍的架构模式。CPU 担任调度管理角色，其他多种类型协处理器来负责各种类型的数据处理和计算加速，协处理器的性能在某些程度上还会超越 CPU。
+
+对于 AI 芯片来说，如何通过模型压缩以及设计更合理的数据流等技术手段来实现性能和灵活性的进一步提升、功耗与成本的进一步降低，也是我们持续探索的方向。
+
+另外，在未来时代，物联网和 AI 相辅相成，密不可分。打一个比方：物联网让各类的设备和终端有了生命，而 AI 让它们有了智商。如今物联网已经渗透到我们生活的各个领域，它所具备的万物互联和海量数据的特性也推动了云计算、大数据、AI、边缘计算等技术的发展。即将到来的 5G 时代，也会进一步加快物联网和 AI 等技术的爆破式进步。
+
+物联网连接的物理对象多样且应用场景丰富，将来更需要通过云计算、边缘计算、智能终端计算的协同发展、有机部署来实现万物互联的智能世界，而全部场景中的这些智能数据处理，都需要 AI 芯片参与其中。
+
+**极客时间：现在大家都在关注芯片动态，有一种观点说中国芯片产业落后国外几十年，很多时候都是自嗨，您如何看待这一观点？**<br>
+**陈天石**：AI 芯片这个领域和其他的芯片领域不太一样的是，中国和其他国家相比不存在太多历史积累上的差距，相反中国还在开始设计研发 AI 芯片的时间上还领先一步。大家从同一起跑线出发，AI 芯片市场前景广阔，人工智能产业发展和应用推进也是迅猛的，希望和国内外同行一道共同努力，推进人工智能领域发展进步。
+
+**极客时间：当下越来越多的企业，包括巨头互联网公司都在布局 AI，您如何看待这一现象？接下来寒武纪会有什么差异化的打法吗？**<br>
+**陈天石**：基于 AI 技术的突飞猛进和对日常生产生活的深入影响，布局 AI 已经成为一种潮流和趋势，包括现在许多巨头通过研发 AI 芯片来实现自身 AI 生态圈的闭环，形成全栈 AI 平台，其实是希望围绕自身的主营业务形成完整或相对完整的行业解决方案，提前部署万物互联时代的战略，以期待减少对芯片供应商的依赖，保护自身核心技术秘密与知识产权。
+
+但客观来说，芯片从设计、制造到封装是一条几乎没有捷径的漫长链条，尤其是芯片的设计，需要技术和资本双重密集支撑。所以，能对计算基础架构进行布局的 AI 公司不多，能真正打造出高性能、可商用的量产 AI 芯片又是一件更不容易的事。
+
+寒武纪的定位一直以来很明确 —— 做独立的芯片设计公司。为下游厂商提供不同尺寸、面向不同应用场景的终端 AI 处理器 IP，提供从前端训练到后端推理的多品类云端 AI 芯片，帮助大家解决“AI 闭环路上最后一公里”的事情。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 陈斌：如何打造高创造力、高动力的技术团队.md

@@ -0,0 +1,59 @@
+<audio id="audio" title="大咖对话 | 陈斌：如何打造高创造力、高动力的技术团队" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/82/3d/82a2f2e144c767a4e2875cbc13adea3d.mp3"></audio>
+
+你好！
+
+本周作客“大咖对话”的嘉宾是易宝支付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要主动向前走一步，跨越这个鸿沟。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 陶真：技术人要爱上问问题，而不是自己的解决方案.md

@@ -0,0 +1,39 @@
+<audio id="audio" title="大咖对话 | 陶真：技术人要爱上问问题，而不是自己的解决方案" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ba/cd/ba067e65a04b8d0d5bb09fc544bf50cd.mp3"></audio>
+
+你好！
+
+本周大咖对话嘉宾是上上签电子签约联合创始人、首席技术官及产品官，TGO 鲲鹏会会员陶真。在回国加入上上签之前，陶真曾先后在美国一线 SaaS 服务公司Intuit及Paycor担任VP和CTO职务，拥有20多年技术开发经验和丰富的管理经验，并在2008 年获得了宾夕法尼亚大学沃顿商学院的工商管理硕士学位（MBA）。
+
+**极客时间：作为技术管理者，您为什么会选择去读MBA呢？**<br>
+**陶真：**去沃顿念 MBA 对我的视野，看东西的视角有很大的增进。MBA 可以把一个技术管理人员的视野拓宽到技术之外，去了解做技术的目的，或者说做这项技术对改变世界、优化客户的流程、解决他们的痛点到底有什么实质性的作用。当把视野放高了之后，反倒能在技术上更加地如鱼得水，可以避免去做一些技术上感觉很热闹，但并不一定有商业产出能效的事情。
+
+其实，我选择去攻读 MBA，主要是出于“好奇心”。我在美国从事第一份工作的时候，就跟别人“不同”，我会多问一点，别的程序员可能照着需求，直接或者加一点猜测就去埋头做了，但是我会先快速做出一点来，给产品经理看一看，问一问，了解为什么要做这个东西，有时候还会协助他们去做一些优化。
+
+后来产品经理、销售就会带我去见客户，跟客户去沟通，帮他们解决技术产品上的一些限制，这对他们的工作也有很大的促进。有时候他们处理不好客户要求、焦头烂额的时候，就会带上我去跟客户沟通，通过技术、通过功能、通过对客户问问题这些方法，让客户变得非常合作，愿意跟我们一起创新，也愿意去接受一些他们无法向客户解释清楚的时间点或者功能的改进。
+
+当有这样一个开端之后，这些商务人员遇到其他一些产品计划的时候，就会很主动地让我去参与，这对我自己也是非常大的增进。那时候就萌发了一个想法，就是作为一个技术管理人员，要怎么把商务的东西了解好？把公司的价值做好？把客户的价值做好？所以觉得去读一个管理方面的学位会有很大的帮助。
+
+另外，这份“好奇心”也让我养成了喜欢从技术和非技术的角度去看问题，去跟各种不同的人做沟通的工作方式。当时我在 ADP 之所以会做的比较突出，不仅仅是因为技术方面很强，而是我能够跟非技术的管理人员有非常好的沟通，像当时公司的产品销售、高管们非常乐于来跟我沟通一些商务上的事情，觉得我是极少的这些技术高管里面，能够听懂他们讲话，也能把事情讲成他们听得懂的人。
+
+很多矛盾其实跟沟通方式有关。在最开始建立信任的时候，是要非常小心的，不能指手画脚，可以从问问题开始。假设自己的想法是错的，让他们去帮助我了解，我自己是不是想错了？当他们在寻找答案的过程中，突然意识到这个想法其实是对的时候，这个就变成是他的主意，这时候他是会非常开心的，他也不会觉得是我给他贡献了一个主意，因为我只是问了他问题，就让他自己说出了好像他自己想说的话。其实说服别人的最好的方法就是，让他自己想到你的好主意，然后他也不觉得这个主意是你想到的。
+
+**极客时间：您为什么会选择回国加入上上签？**<br>
+**陶真：**因为这是个非常好的行业，电子签名可以帮助中国企业提高很多的效能，可以帮助他们做到很多以前做不到的事情。从大的方向来看，电子签名也可以帮助中国的整个商业环境提高诚信。增进了诚信之后，所有的商业成本都会有一个很大的降低。当然另外一方面通过电子化的这种方法，把合同电子化、线上化，也保护了环境，少用纸张就是减少树木的砍伐。我觉得无论从大的理想，还是从大的宏观环境都对整个中国商业的发展有促进作用。
+
+**极客时间：您加入了上上签之后做了哪些具体的工作，帮助业务上实现了那些突破？**<br>
+**陶真：**从公司的技术架构方面，我们做了简化，我们在云计算成本、创新能力、维护成本、高并发能力、帮客户提供价值的速度上，都取得了非常大的突破。我们的区块链存证技术是业界第一个自主研发的电子合同全链路区块链存证应用。我们植入 AI 技术帮助客户更好的管理合同。截止 2019 年 3 月，我们的电子签名系统可以支持 4000/ 秒的高并发签名，最高日签署量突破了 2100 万。我们也在银行、金融、供应链、制造、零售、人力资源、物流、租赁、互联网创新等各个行业和场景的使用中获得了大量代表性客户。
+
+在云计算能力的使用方面，我们把所有的技术做了简化，对我们的团队创新能力做了提升。当我们的技术团队不用去解决别人已经解决好的问题的时候，我们就可以专注在自己的业务上面，可以更多地去倾听我们客户的声音，然后跟客户一起做联合创新。跟合作伙伴的配合上面，我们有一个非常明确的原则，如果我们要做的一件事情不是直接帮助我们的客户得到价值的，或者我们不卖这个零部件的情况下，我们是不自己去研发的。
+
+比如一些在线编辑功能，我们可以选择自己去做，但是已经有人专门卖这样的商业化的技术，提供这样的 API，我们就直接通过合作的方法把这些技术能力做一个引进。这样我们可以在合同管理、电子签名、相关加密以及法律支持这些方面做更多的一些创新。所以我们把一些自己不该做的事情都停掉了，并且通过引进技术很快地得到助力，并把这些价值提供给客户。
+
+我们做的另外一个很大的改变就是让各个部门的协同做了一个增进。没有任何一个部门是可以独立地为客户去创造价值的。产品团队、各个技术团队、客户成功部门、销售部门以及市场团队的日常沟通，都在保证我们有创新的源泉。从这个角度来讲，这样的调整不应该比技术上面的一些重大调整要低一个优先级。
+
+**极客时间：您的工作经历中很多都是同时负责产品和技术，那对于技术人员的职业规划，您有什么建议吗？**<br>
+**陶真：**技术人的规划应该有两个方面，除了要不断地自我提升，学习最新的、最前沿的技术能力，还要去对问题好奇，去了解自己的技术是被如何使用，可以解决哪些问题。
+
+当我们并不了解自己的技术是怎样解决问题的时候，就把技术和产品分离开甚至对立起来了。好比我们有一把锤子，我们不是一定要去找个钉子，而是要去了解，我们找到的是一个钉子还是一个螺钉，如果是螺钉，我们必须要有螺丝刀的能力。有些工程师太喜欢自己的解决方案、太钟爱自己的技术了，以至于忘掉了要解决的问题是什么，客户的痛点是什么？当他有一个特别强有力的锤子的时候，他把什么东西都当钉子看，其实有时候我们需要的可能不是一个锤子，而是一个扳手。
+
+很多时候我会提醒我们的产品和研发团队，要爱上问题，而不是爱上我们的解决方案。学会从客户痛点的角度出发，而不是从解决方案的角度出发。当了解了问题以后，我们可以用最切合的、最高新，甚至是最简单的技术，给客户做好一个解决方案。所以，我觉得技术人不仅技术上要有不断的突破，了解我们解决的问题是什么也十分重要。只有这样，才能把最切合的技术，用最适合的方法去提供一个解决方案。这是我觉得在成长中最受益的一个自我训导。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 韩军：CTO转型CEO如何转变思路.md

@@ -0,0 +1,59 @@
+<audio id="audio" title="大咖对话 | 韩军：CTO转型CEO如何转变思路" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/7d/97/7d5cbb28fb0137ef201c11dceb23db97.mp3"></audio>
+
+你好！
+
+本周作客“大咖对话”的嘉宾是欧电云创始人兼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，为目标拿分，这个能力变得更为重要。
+
+最后是薄弱能力的补足，在角色转变的过程中，作为创业者你需要不断去学习以前没有的技能，因为相对来讲，技术人的软技能会欠缺一些，比如沟通能力、对商业的认知能力、获取外界帮助的能力等，当你创业后，这些薄弱面都是需要你去补足的、能力提升的。
+
+**极客时间：如何正确应对创业过程中的压力？**
+
+韩军：创业的压力肯定是很大的，经常有想创业的人会来问我创业相关的问题，很多时候我都会泼他们冷水，因为创业是一件压力很大的事情，很多人都没有真正准备好。
+
+具体来说，一个是经济上的准备，一个是精神上的准备。尤其是精神准备，很多人以为自己准备好了，其实并没有。创业真的是一件九死一生的事，之前做了再多的准备，过程中还是遇到各种意料不及的困难，承受诸多难以想象的压力。
+
+因此，你创业的初心一定要是做你真正喜欢的、热爱的事情，而不是为了赚钱。赚钱是创业成功之后必然会获得的回报，但它不应该成为你创业的初衷。
+
+因为热爱，你才会全情投入，就不会计较一时的得失，也就不会被压力压块。即使遇到困难也会是痛并快乐着，因为你证明了自己，你解决了很多用户的痛苦，你为社会创造了价值。这样，就算失败了又怎么样呢？你可以选择再来一次或者不，这是你喜欢的事情，你真正经历体验了这个过程，而人生就是在不断的经历。
+
+于我而言，因为现在做的是自己感兴趣的事情，也全身心投入到这件事中，只想着怎么把它做好，就不会太在意压力了。另外，即使遇到难题，我更关注的也是怎么去解决这个问题，而不是沉浸在痛苦和压力中，算得上是乐在其中了。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 项目成功的秘诀——技术产品双头负责制.md

@@ -0,0 +1,65 @@
+<audio id="audio" title="大咖对话 | 项目成功的秘诀——技术产品双头负责制" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/5d/ed/5dabdefe30078a3e5af2e59f528b58ed.mp3"></audio>
+
+你好！
+
+本周作客“大咖对话”的嘉宾是360商业化CTO胡宁，她也是360聚效联合创始人、首席技术官。在此之前，她曾担任谷歌技术总监，先后领导主持了移动搜索、谷歌音乐及 Android 云服务的研发。今天，我们和她聊了聊技术人的产品思维。
+
+**极客时间：您负责360的商业产品，在技术产品化方面，您有哪些心得？**
+
+**胡宁：** 这跟我之前的经历有关，我原来在谷歌做工程师的时候，做的一直都是用户产品，从移动搜索，到谷歌音乐，再到安卓云服务，都是跟用户打交道。众所周知，谷歌是典型的工程师文化，工程师的话语权会比较大。那些在别的公司只需要产品经理考虑的事情，在谷歌，工程师也要参与，而不是产品经理一个人说了算。
+
+那时，我就形成了一个观念——一个优秀的工程师，不光技术能力要强，还需要有非常优秀的产品感觉。
+
+后来我出来创业之后，也一直是产品、技术两个一起管。在这些年的创业过程中，关于项目管理、产品管理，我也摸索出了一些自己的心得，那就是**技术产品双头负责制**。
+
+一般做互联网产品，很多时候都是由产品经理或项目经理去负责整个产品，技术相对来说是一个接收需求、开发需求、实现需求的处于后方的位置。但在我看来，一个产品真正要获得成功，并不只是产品设计的问题，怎样以更低的代价、更系统化的路径去实现它，也是很重要的，而这就需要有工程师的积极参与。
+
+所以我们会提倡技术产品双头负责制，由技术负责人和产品负责人一起承担整个项目，包括该开发什么功能、功能要做成什么样子、怎么设计、该用什么样的架构选型、怎么开发、怎么做测试排期、什么时候上线等一系列工作。
+
+只不过他们会各有分工，技术负责人会更偏向内部，会更多的做一些开发排期、技术架构设计等工作；而产品负责人会更偏向外部，比如需求收集、跟各部门的沟通等。经过我们这么多年的实践，这样的一个机制是能比较有效的保障产品、项目成功的。
+
+可能有人会问，两个人一起负责，会不会产生争议和矛盾，毕竟在传统框架中，技术和产品本身就是容易有矛盾的两个角色。这点其实不必担忧，我们在实践的时候，会保证技术负责人和产品负责人的目标是一致的，例如他们的OKR就是彼此先沟通商量好的。
+
+有了这些确定的目标，他们两个人就需要一起负责，无论是做成还是没做成，都需要他们两人带领团队去一起承担。而在目标一致的情况下，很多分歧就不存在了，看的就是要做的事情是否对项目有好处。
+
+原来技术和产品容易产生分歧，很大程度上，是因为大家权责不清晰，出问题的时候，老想把锅甩到对方头上，但在技术产品双头负责的制度下，这锅只能双方一起承担，想甩都甩不掉。在我们做出这样的调整之后，技术和产品的关系反而融洽了很多。
+
+**极客时间：技术人应该怎样提升产品思维？**
+
+**胡宁：第一点，积累足够的行业经验。** 产品与其所在的行业、领域是紧密相关的。技术人要想提升产品思维，首先就是要积累足够的行业经验与知识，需要真正沉浸到行业里去，踏踏实实做上几年，才能领会其中的关节与窍门，理解核心的商业逻辑。只有这样，才有可能做出优秀的产品，否则就是天方夜谭了。
+
+**第二点，要有全局观。** 我一直倡导技术人不能局限在自己的岗位上，而是需要站在一个更高的层面上，从全局出发去看事情，去看产品整体到底是什么样的、之后要走什么样的方向，而为了支撑这样的方向，技术架构、技术选型又要怎么做等。这其实也呼应了第一点，有了较为丰富的行业经验作为基础，才有可能站在全局的角度去看问题。
+
+**第三点，技术本身不能丢。** 这一点回到了技术本身，是因为一个好的、能满足用户需求的产品，最终还是要落到各种技术指标上的，比如页面响应时间多少、互动操作是否流畅、用户点击率是否能提升、能承担多少同时访问的用户数等。而这其中各种优化工作的完成度，最终还是取决于技术水平的高低。所以技术人的产品思维还得有很强的技术积累作为支撑。
+
+**极客时间：你认为具备哪些素质才是一个优秀的技术管理者？**
+
+**胡宁：** 一个优秀的技术管理者需要具备以下素质：
+
+**第一，技术水平得非常扎实。** 在技术领域，做纯粹的人事管理是很难服众的，必须有很强的技术能力，才能服众，才能带动团队。因此，我原来培养一个人的时候，很多时候都是要求对方从基层做起，去展现他的实力，去以技术服人。工程师是相对比较单纯的群体，如果真觉得你实力很强，他们是会佩服你、敬仰你，愿意跟随你的，这是非常重要的一点。
+
+同时，我也不希望一个技术管理者就纯粹的只做管理，当然我也不是强硬地要求他们做了leader之后还要写代码，但我希望他们仍然能够亲力亲为地去处理一些问题、尤其是难题，而不是把事情完全推给下属，这样的管理者，不会是优秀的技术管理者。
+
+**第二，要有同理心。** 我最近看了微软CEO纳德拉的《刷新》一书，我很赞同其中的一个观点——管理越往上走，越需要有同理心。之前我把这些归纳为沟通能力、情商等，但更深层次去挖掘后，发现它们本质上就是同理心。
+
+同理心就是你是否能理解别人的立场，是否能站在别人的角度去考虑问题。还是以技术和产品为例，我们很多时候都会听到技术抱怨产品又改需求啦、产品又把锅甩过来啦，但如果站在产品的角度，他们只是想把产品做好，做各种调整是为追求理想的最终结果。如果双方都理解对方的立场，技术把做好产品当成彼此共同的目标，产品能看到并体谅技术的实现难处，那双方的摩擦和埋怨就会少很多。
+
+因此，优秀的技术需要拥有这样一颗强大的同理心，只有真正站在别人的角度看问题，才能找到大家都能接受的解决方案，大家的劲儿才能往一起使。
+
+**第三，要具备领导力。** 技术管理中是有管理职责的，每个人的管理风格都不一样，我能理解并尊重，但是需要保证你的管理风格是能被团队接受并适应的，能让团队运转工作起来，这个被我称为领导力。
+
+在管理团队时，每个人的性格不一样，管理者不能要求所有人都按照一个模子去做，否则很可能会引起反弹，这又呼应了第二点，看管理者是否具有同理心，是否能站在团队成员的角度去考虑问题。
+
+当然，不是所有的技术人都适合做管理，有些人由于性格、情商等原因，可能更适合做IC独立贡献者（Individual Contributor），这也是很好的发展路径，并不是非得走技术管理这条路的。
+
+**极客时间：您具体是如何培养团队leader的呢？**
+
+**胡宁：** 管理团队，我有我自己摸索出来的一套流程和模式，比如我会用OKR，会用之前提到的技术产品双头负责制，会做公开透明的绩效考评和互评，还会建立一系列技术开发、产品开发的规范和流程等。
+
+在培养团队leader时，我一般会扮演一个教练的角色，会给对方建议，怎样才能成长，需要做哪些事情，哪些方面还需要继续加强。比如我会在某个leader成长到某个阶段后，建议他做团队梯队建设，为什么要做，大致要怎么做。
+
+另外，他们在管理过程中遇到各种各样的难题和困惑，会随时来找我、或在1-on-1沟通时问我，我也会尽力给对方提供我的经验和建议。例如，团队里两个相对资深的小组leader之间有矛盾，团队管理者要怎么处理；或者如何劝退一个不能胜任工作的团队成员。我会跟他分享我以前遇到过的类似情况，以及我的处理经验。但我只会以教练的身份去引导他，跟他讨论，给他建议和提示，而不会指手划脚的告诉对方该这么做那么做。具体该怎么处理，主动权应该握在他手里，这样才能最大限度的让他获得锻炼和成长。
+
+最后，在我看来，技术管理是个经验科学，管理者一定要通过实践去尝试、去体验，最终沉淀出属于自己的管理经验和管理风格。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 顾旻曼：投资时我们更多地是在找优秀的团队.md

@@ -0,0 +1,47 @@
+<audio id="audio" title="大咖对话 | 顾旻曼：投资时我们更多地是在找优秀的团队" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e8/fd/e8bd22806da18e8ad1090e4c6cac23fd.mp3"></audio>
+
+你好！
+
+本周大咖对话的嘉宾是真格基金董事总经理、华东区负责人顾旻曼。顾旻曼是真格基金早期员工， 在此之前，曾任职盛大创新院，负责战略投资业务。加入真格基金后，主导和参与投资了 60 多个项目，如即刻、青藤云安全、达观数据、燧原芯片、Papi 酱等。
+
+有人说，这是技术创业最好的时代，在互联网下半场的浪潮里，什么样的企业能得到资本的青睐？资本的注入对企业、对技术创业者来说会带来哪些影响呢？对此，顾旻曼坦诚地分享了所在赛道的投资情况、自身的投资逻辑以及对相关投资案例的解读与看法。
+
+**极客时间：您的投资理念与投资逻辑是什么样的，能与大家分享一下吗？**<br>
+**顾旻曼**：在投资时，真格会比较偏向于选择优质的、专业的团队进行早期投资。
+
+拿 papi 酱来说，在对 papi 酱团队进行投资时，我并没有预想到它会红极一时，当时传统线下艺人的生态已经比较成熟和坚固，而线上尤其是网红群体能够更接近于商业转化；同时，在这个行业里要找到一支高素质的从业者队伍非常难，而 papi 酱团队中的三个人是中戏同学，各自的经历也非常丰富，他们也做过游戏创业、经纪人业务，本身也可以从事内容创作，这样的组合非常罕见，也比较打动我。
+
+其次，我们很少追风口，客观上来讲，风口起来了价格也偏高，当然真格可能无意间提前进入了一些风口。我们更多地是在找优秀的团队。
+
+比如我们2013 年投了依图科技，当时 AI 这个概念还没有出现在大众的视野中，更不用说所谓的风口，而如今，依图科技已经成长为 AI 独角兽，在智能安防、智慧医疗、智慧金融、智慧城市、智能硬件上都有不俗的表现。
+
+真格当时之所以选择依图，是因为看中了创始人朱珑、林晨曦组建的团队。当时，朱珑在麻省理工学院担任博士研究员后回国，此前一直专注在机器智能研究上；而林晨曦在阿里巴巴搭建了国内最大的拥有自主知识产权的飞天分布式云计算操作系统，擅长的恰好是人工智能算法工程化和产品化最需要的大规模并行计算系统。
+
+这种组合的团队，我们觉得应该要支持，但当时并没有说规划要投 AI 赛道，那会儿也还没有这个赛道，我们只是看重了这个团队。
+
+类似的例子还有很多，比如说投找钢网，当时还没有这样一个专门的风口出现；青藤云安全也是，它是一家做安全的企业，近一两年才获得了很多的关注。
+
+而对于个人偏好来讲，我会对创业者有一些期待，希望他们有充分的积累，不管是过去在学术技术上的积累，还是在产业里面的积累。创业是对过去积累的势能的一次变现，也就是说，创业者要清晰地知道自己为何而来，并且不会因为一时的市场起伏、资本的追捧或是冷落就有任何变化，他们需要知道自己将创造什么。
+
+**极客时间：在您看来，一个优秀的投资人需要做到哪些？**<br>
+**顾旻曼**：作为一个投资人，首先从心态上就要摆正——不能要求创业者一帆风顺，在他做得很好的时候就高捧，在遇到困难和挣扎时就贬到一文不值。
+
+创业成功与否是由很多因素共同决定的，作为投资人，我们能够把握的是团队的选择和对当时市场方向的预估，而最后结果的好坏主要看两点：一是看自己的判断力是否准确；二是创业讲究的是天时地利人和。尽可能减少因主观的判断力而导致的投资失败，是对创业者、对自己负责的表现。
+
+其次，投资者自身需要成长，我每次复盘都会觉得自己可以做得更好，会觉得自己对于商业本质的判断、对于产品的理解和认知、对于团队的人的理解和认知都不断在上升，但永远还有进步空间。
+
+另外，投资者需要有自己的核心投资理念，拿我来说，不管是投资哪些方向和行业，从前几年投 ToC 互联网产品方向，到内容文娱，到后数据安全、ToB 方向，我一直以来关心的核心都没有发生过变化—— 技术怎么样改变这个世界，我怎么样帮助技术改变世界，让人们的生活更美好。这是我做投资的使命感，投资不同行业，只是在不同阶段的不同形式呈现，我期待的是从泛互联网技术到硬科技对商业世界、对生活的改变。
+
+接下来，我还是会持续关注科技方向的创业公司，包括大数据、AI、产业互联网相关的比较多一些，现在互联网走到了更加硬核的地步，我也会看更加硬核一些的项目。
+
+**极客时间：行业女性投资人会比较少，这个对您来说会有什么样的影响吗？**<br>
+**顾旻曼**：我觉得用性别给自己打标签，要不就是偷懒，要不就是自我限制，我从来不给自己打性别标签，客观上来讲女性思维或者男性思维因人而异。
+
+而至于女性在职场上会出现劣势，很多时候不是因为能力问题，而是需要女性加倍地去证明自己，这是一个现实。但首先可以先做好自我，女性不管是作为投资人，作为媒体人，作为任何一个职场人，只有你发挥出很大的能量，才会影响一些雇主对女性的“偏见”，后来者才会给更多的女性更多的机会，永远不要让公司觉得雇佣女性有很大的风险。
+
+**极客时间：刚才提到您自身的成长，那在成长的过程中，是否有经历过至暗时刻？最后是怎么走出来的？**<br>
+**顾旻曼**：我觉得没有一个至暗时刻，但有很多时候会否定和怀疑自己。比如说每年的复盘，或者说回看自己两三年前做的一些决定，不管是从投资方向的选择、从团队的判断、从某个项目的参与度来说，我永远都觉得自己做得不够。
+
+我会很多有很多的反思，很多时候自己会有一叶障目的感觉。我现在处在投资人的身份和位置，业绩表现和努力工作这些是正常的压力，老实讲，很多时候我的压力没有创业者那么大。但我觉得很多时候压力是原生的动力，才能让自己成长得更快。也就是说，你如何在自己的小世界里做得更好，如何让自己获得更大的视野，以此在更大更残酷的市场里成长，是非常关键的，也是自己需要时时反思的。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖对话 | 高斌：过分渲染会过度拉高大众对人工智能的期望.md

@@ -0,0 +1,47 @@
+<audio id="audio" title="大咖对话 | 高斌：过分渲染会过度拉高大众对人工智能的期望" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/4a/da/4a43cc042a6a0bb82f2c3cc71ef256da.mp3"></audio>
+
+你好！
+
+本周大咖对话的嘉宾是高斌，现任微软总部必应搜索广告部门首席机器学习科学家，此前曾担任微软亚洲研究院机器学习研究组主任研究员，主要从事机器学习、信息检索、数据挖掘和计算广告等领域的研究，在国际顶级期刊和会议上发表相关论文 40 余篇，持有 30 余项美国专利，其指导的论文曾获得国际信息检索大会 (SIGIR) 最佳学生论文奖。
+
+在做研究的同时，高斌博士十分重视和产品部门的合作，将十多项技术转化到了必应搜索、必应搜索广告、微软小冰等产品中。也是在这个过程中，高斌博士对应用型研究产生浓厚兴趣，因此申请转到产品部门，成为了微软总部必应搜索广告部门的首席机器学习科学家，将前沿的机器学习技术应用到产品中，同时针对具体应用研发新的算法模型，改进产品性能。
+
+**Q：您认为目前影响人工智能落地的因素有哪些？**<br>
+**高斌**：我认为目前影响人工智能落地的因素主要有以下三个方面：
+
+第一，明确技术应用的边界和程度。虽然人工智能技术发展日新月异，但是目前能够解决的问题还是有限的。我们要弄清楚在一个应用场景中哪些部分是人工智能技术可以解决的，可以解决到什么程度，哪些部分不能解决。然后针对应用场景的需求期望来决定哪些部分使用人工智能技术以及使用何种人工智能技术。这样才能最大的发挥技术功效，并且避免因为一些不切实际的幻想破灭而造成的负面影响。
+
+第二，提升数据的质量。人工智能技术尤其是深度学习技术需要依托海量数据来进行模型训练。我们需要针对具体的应用问题来对数据进行选择和处理，包括对数据量的积累、对多种类型的数据进行取舍、对数据进行降噪、对数据内在关联进行分析和利用等。在这个基础上，才能更好的建立模型并提升模型学习质量。
+
+第三，提高工程实现能力。虽然近年来高性能计算硬件的发展和普及非常迅猛，高水平的工程实现能力依然是影响人工智能落地的重要因素。一般来说，数据量、模型尺度的增长速度还是大于硬件发展的速度的，高水平的工程实现能力可以最高效地在硬件计算资源、数据量和算法模型之间找到平衡点，实现人工智能技术的落地。
+
+**Q：您觉得大众对人工智能的认知偏差大吗？这种偏差会对行业造成哪些影响？**<br>
+**高斌**：我觉得大众对人工智能的认知偏差普遍比较大，出现这种偏差有多方面的原因：艺术作品的先入为主、对大众的人工智能知识科普的不足、媒体的过度渲染、部分从业人员的炒作等等。这种偏差的影响也是多方面的。<br>
+第一个影响是大众的恐慌。比如人工智能取代人类，人工智能导致失业率升高等等，这有可能会导致社会上对人工智能的一些恐慌，一些人可能并不太了解人工智能在做什么，而是盲目的反对和否定，这当然会影响行业的发展。其实，虽然人工智能技术确实会导致某些职业岗位的需求量大幅下降，但是同时也会创造一些新的职业类型，人力资源会向新兴的岗位流动。<br>
+第二个影响是大众的失望。过分的渲染和炒作会过度拉高大众对人工智能的期望值，当项目或者产品投放市场以后，如果产品的实际表现和宣传相差过大，大众就会大失所望而可能抛弃产品并且对人工智能产生质疑，这对人工智能技术和产品的改进和推广都会带来一定的负面影响。
+
+**Q：您觉得未来人工智能会成为一种什么样的存在？**<br>
+**高斌**：我觉得人工智能在未来会回归它原本的位置，成为人们比较关注的几个前沿技术领域，并会不断地带来改变人们生活的新技术。
+
+**Q：在您看来，什么样的企业应该发展人工智能技术？**<br>
+**高斌**：我觉得与数据相关的企业都可以发展人工智能技术，只是不同企业的发力点可能不一样。有的企业可能注重人工智能技术与传统行业的结合来进行技术升级和创新，有的企业可能注重对人工智能关键技术的本质突破，有的企业可能注重人工智能在某个非常具体的应用场景的创新。
+
+**Q：您在人工智能领域深耕多年，对于刚开始学习人工智能的技术人有什么建议？**<br>
+**高斌**：首先是要打好基础，数学基础、计算机基础、编程基础都要扎实；然后就是选择一个方向，人工智能领域里面课题众多，要结合自身条件、个人兴趣和行业发展选择适合自己的方向；再就是要紧跟技术的发展，人工智能领域技术更新迭代速度很快，稍不留神就会被落在后面。
+
+**Q：未来人工智能在金融领域的应用场景有哪些？您最期待的是哪个场景？**<br>
+**高斌**：在金融领域，人工智能可以应用于收益预测、投资组合构建、风险管理、金融产品推荐等方面。我本人最期待的应用场景是投资组合构建。
+
+**Q：在很多年里，普通人对人工智能的印象主要来自一些机器人电影，过去您看那些机器人电影的时候是什么感觉？**<br>
+**高斌**：我听说过，有些人看了某部科幻电影之后便立志投身人工智能领域改变人类，一部电影成了他们人生的转折点，从此开启了开挂的人生，我很敬佩他们。我很喜欢电影，不过对于机器人题材的电影倒是没有什么特别的偏好，我更加关注的是电影故事所引发的思考。对于机器人题材的电影里面展现的一些有关人工智能的情节，我有时会想哪些是有希望实现的，是否还可以联想到一些类似的有意思的应用，哪些不过是人们美好的想象，仅此而已。而对于整个故事所引发的思考我倒可能会时不时反复回顾。
+
+**Q：发展人工智能技术一定需要人才支持，您通过什么样的方式吸引人才的？**<br>
+**高斌**：对于人才的吸引，我们主要通过以下三个方面。一是对外进行宣传，比如我们会在一些学术会议、产业会议等技术交流活动中展现我们的技术实力、宣传我们的产品性能，从而吸引人才的加盟；二是通过实习生项目从在读的硕士研究生和博士研究生中筛选高水平技术人才；三是通过一些前沿的有挑战性的项目，来吸引内部人才的流动。
+
+**Q：可以介绍一下微软必应搜索广告部门现在的技术人才团队吗？**<br>
+**高斌**：微软必应搜索广告部门的技术团队主要分为三种角色。一是软件开发工程师（software development engineer），主要负责产品系统构建、模块开发、技术维护等；二是数据科学家（data scientist），主要负责各种数据的处理、分析、挖掘、预测、决策等；三是应用科学家（applied scientist），主要负责针对具体问题进行分析，运用、改进或者发明机器学习、数据挖掘、信息检索等领域里的技术来对问题进行建模、实现相应的算法并嵌入到产品系统中。
+
+**Q：您和其他部门的负责人在工作中会发生观点不一致的情况吗？一般会怎么处理？**<br>
+**高斌**：工作上发生观点不一致的情况是比较常见的，一般来说我们会通过协商解决。这里可能有多种不同情况，如果项目目标不一致，那就要看多个目标是否可以分阶段完成，是否可以双方都做一些妥协做一些取舍；如果是在目标一致的情况下项目执行方案不一样，那就要论证每个方案的可行性并根据一些衡量标准来做出大家都认可的选择。总之，需要具体问题具体分析，在大家本着解决问题的态度下，进行协商和互相之间的妥协。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖问答 | 发现下一个小米，不是只能靠运气.md

@@ -0,0 +1,43 @@
+<audio id="audio" title="大咖问答 | 发现下一个小米，不是只能靠运气" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/93/56/93d2af32f1b85e5e698245a6d0344e56.mp3"></audio>
+
+你好！
+
+本周与我们对话的嘉宾是迅雷创始人程浩。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人规模时加入一点也不晚，这不需要靠运气，更多的靠自己的眼光和实力。
+
+

极客时间专栏/geek/技术领导力实战笔记/大咖问答 | 打造自己的个人品牌，你也可以.md

@@ -0,0 +1,45 @@
+<audio id="audio" title="大咖问答 | 打造自己的个人品牌，你也可以" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/0e/34/0ef2c5a23a09f8a20db6d55783b1f934.mp3"></audio>
+
+你好！
+
+本周与我们对话的嘉宾是极客邦科技创始人兼 CEO霍太稳。霍太稳在过去的15年职业生涯当中，基本都在和技术人打交道，不管是技术媒体InfoQ中国还是高端CTO圈子TGO鲲鹏会，在这中间，他见证了很多技术人的成长之路，深谙影响力对于一个人发展的意义。
+
+本周，我们邀请霍太稳分享他对于认知升级的独特见解，以及技术人可以通过哪些方法打造自己的个人品牌。
+
+## Q：技术人可以通过哪些方法打破边界，提升认知？
+
+A：为了学习而学习，可能会适得其反。我认为最重要的，还是要和公司当下的业务相结合，在促进业务快速发展的过程中，让认知自然地提升。为什么有些大公司出来的同学，就是给人感觉视野很开阔，能力也很好，主要原因并不是说他们在大公司里很努力地学习，而是他们参与解决了很多实际的有挑战的问题，攀登了一座又一座技术的高山，然后回头看，就有一种“不畏浮云遮望眼”的感觉。所以，第一点就是我们脑袋里面要始终想着业务，如何通过技术的努力，让业务得到快速发展，而不是一味地埋头于自己的技术三分地。
+
+刚才说的是如何基于业务发展提升自己，另外对于技术领导者，或者想成为领导者的技术同学，在对内对外的联结上也要多加注意。有意识地进入某一个圈子，找到能听懂你说话的人，大家经常一起切磋交流，共同成长。最近我在看《深度工作》这本书，在书中，作者就特别提到“不要独自工作”，原因是“对于很多类型的工作而言——特别是追寻创新的——协作深度工作可以产出更好的效果”“……恰当的时机可以采用协作的方式，因为这样可以推动你的成果提升到一个新档次。”我们都知道人的认知是存在盲点的，自己看不到，了解自己的人却能看的很清楚，在一个安全的氛围里，大家互相指正，可以帮助彼此定期提升认知。
+
+最后还有一点，所谓打破边界，就是要走出自己的舒适区，要学会“跨界”。尤其是创新型的工作，不同领域的界限已经越来越模糊了，比如科学与艺术，互联网与制造，甚至零售前面要加一个“新”。不囿于当下的工作，多参加一些跨界的活动或者学习，可能会有不同的体验，不同的思考。
+
+## Q：怎样从他人的经验分享中提炼出真正对自己有价值的知识点，并在实践中运用？
+
+A：但凡是学习，都比较讲究“次第”，也就是一步一步地上升。现在我们很多的讲座都是请行业里面的顶尖专家来分享，是很好的事情，但是在选择的时候，还是要结合自己的水平，和自己公司当前的业务发展。如果现在公司网络业务的并发量是以万级计算，你听千万级并发量的课程，对自己能有多大的帮助，我是存疑的。这时候可能倒不如听一个不是那么有名气的同学，来分享他们的业务是如何从万级并发到十万百万并发的。也就是说，学了之后能在自己的团队尽快用得上，能够学以致用。
+
+另外就是学习了别人的经验后，一般都是当时热血沸腾，想回去马上在自己团队实施。我的经验是，先让自己冷静一下，一般以一周为宜。在这几天里，挑选团队里的个别小伙伴征询意见，看看如果自己要实施“新政”，大家是否是拥护的，是否能帮助大家真正解决问题。比如可以基于下面几个问题进行讨论：
+
+团队目前需要改进的地方或者痛点是什么？
+
+新的方法是否能帮助我们真正解决问题？
+
+如果要实施新方法，会遇到什么样的挑战？
+
+除了这个方法，我们还有没有更好的方法？
+
+具体实施的目的、目标和步骤是什么？
+
+还有一个办法，也是一些创新团队经常采用的，就是MVP法则。学到了好的方法，回到团队，我们可以先挑个小团队去试运行，看看效果。如果效果好，适合自己的团队，则推而广之，否则，就偃旗息鼓。这样就不至于动不动大动干戈，劳民伤财，而且这样的事情多了，还会损害自己作为技术领导者的信誉。
+
+## Q：技术人应该如何打造个人品牌？
+
+A：讨论这个问题之前，我们还是要定义什么是“个人品牌”，简单来说，就是一个人带给别人的印象，以及所影响的人的范围。我们说一个人个人品牌很好，通常是说他在某一方面有专长，有权威，另外就是他还影响和帮助了很多人。从这个角度出发，我认为技术人可以从下面几个维度思考，打造自己的个人品牌或者影响力。
+
+通过社交媒体多发表观点，尤其是针对热点事件，让自己在关键时刻不缺位。但是这个方式也有自己的副作用，如果在社交媒体上过于活跃，比如在每个群里都能看到他在说话，好像随时都在响应大家，可能会给人留下没有专注于本职工作的印象。学会“隐藏自己的实力”，多发表有见地和有理有据的内容，可以作为自己使用社交媒体的礼仪之一。
+
+多参与有品质的会议，并发表演讲，或者写“博客 / 公众号”也是不错的办法。因为不论是一个45分钟的分享，还是一个2000字的文章，都代表着你对一个问题的深入思考，这在现在已经泛滥的浅层信息流中是比较稀有的东西，自然会受到更多人的关注。需要注意的是，不要一个内容到处讲，要克制，就好像武侠小说里面的剑客，不是随意拔剑的，剑一出手，必定置敌人于死地。如果是公司需要自己多露面，那么至少每次讲的内容要有30%的更新。
+
+出书，这个我认为可能是当前最有效的建立个人品牌的方法，尤其是和一些有品牌的出版社合作。通常情况下，越是难度高的产出，越容易受人肯定。如果说公众号代表一个人当下的深入思考，出书则代表一个人对过去一段时间的深入总结，而且还要花费数月把它形成文字写出来，是代表着一种严肃的，真实的付出。所以，如果你真的想有自己的品牌，那就沉下心来，有意识地总结经验，找一个靠谱的编辑合作，写书吧。
+
+最后我想提醒我们技术人的是，别害羞，激进一些，多站在台前发表自己的观点和言论，会更能彰显自己的价值。比如很多技术人喜欢的“左耳朵耗子”（真名：陈皓，酷壳博客的维护者，极客时间App“左耳听风”的专栏作者），在他的文章中，常能看到对某一技术的使用经验，对某一热点的解读，拥趸无数。时间长了，他的个人品牌也出来了，现在他的“左耳听风”专栏已经快突破7000人订阅。人的一生，都会有属于自己的光芒闪耀的五分钟，希望你能抓住它，不让机会溜走，形成属于你的品牌。

极客时间专栏/geek/技术领导力实战笔记/开篇词 | 卓越的团队，必然有一个卓越的领导者.md

@@ -0,0 +1,43 @@
+<audio id="audio" title="开篇词 | 卓越的团队，必然有一个卓越的领导者" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/2b/00/2b01e407fa5dfa9fd8b636499c2f9900.mp3"></audio>
+
+管理大师彼得·德鲁克说：“组织的目的，就是让平凡的人做出不平凡的事。”然而，不是任何一群平凡的人聚集到一起，都能做出不平凡的事。甚至一群优秀的人聚集到一起，也可能只是一个平庸的组织。
+
+因为，大到一个国家，小到一个团队，任何一个卓越的组织，都必须有一个卓越的领导者。领导者是一个组织的灵魂，在很大程度上决定了组织所能达到的高度。
+
+技术团队同样如此，管理者的战略眼光、管理方法、人格魅力等，都会给团队的工作结果带来决定性的影响。
+
+但技术管理者面临的具体问题又有其独特之处。虽然CTO、技术VP、技术总监等职位的职责各有偏重，但总的来说，技术管理者对内要负责技术选型、产品功能实现、团队成员培养、技术人员考核等等；对外则要承担扩大公司技术影响力、为公司招募更多优秀研发人员，发展潜在客户等职责。
+
+因为工作关系，我们有机会经常与技术管理者交流。在这一过程中我们发现，技术管理者面临的问题往往是相通的，每一个技术人在通向技术高管的路上都要趟过无数个坑。比如“如何与其他部门的负责人高效沟通？”“如何制定科学的绩效考核方法？”“面对新的技术趋势应该如何布局？”“怎样做好技术人员招聘？”等等。
+
+关于这些问题，通过其他优秀的技术领导者在实践中总结的方法论来学习和提升，是最为高效的方式。因为人类之所以能够取得今天的成就，就是因为我们可以通过阅读等方式，不断地在前行者的基础上再进一步。
+
+而即便你已经一路升级打怪，成为了一名优秀的CTO，你仍然会面临许多挑战：行业格局瞬息万变、技术浪潮风起云涌、资本市场残酷善变，更不要说公司新加入的高管很可能与你气场不合，你与公司商定的股权分配方案可能存在隐患……
+
+在这一背景之下，极客时间推出了“技术领导力实战笔记”专栏。这是一个针对技术高管的付费专栏，由阿里、腾讯、AWS等上百家知名互联网公司的优秀技术领导者和CEO共同贡献和维护，专栏内容涵盖前沿技术、趋势分析、团队管理、软性技能等技术管理者关注的重点问题。该专栏希望通过体系化、有洞见的课程来帮助技术管理者提升认知，升华自我。
+
+“技术领导力实战笔记”专栏中的每篇文章，都是这些身经百战的管理者们基于实践经验的总结和提炼。专栏作者中，有些曾经获得“最具价值CTO”的荣誉，对于团队管理有自己的独到方法；有些从CTO进阶为CEO，对于CTO和CEO应该如何相处有着深刻理解；有些带领技术团队从无到有完成核心系统架构，助力公司业务实现百倍增长……
+
+每周五，我们还将邀请一位技术大神或互联网大佬，回答你感兴趣的问题。他们将以更高的高度，带来不一样的资讯和思辩。一些以往只能在新闻里看到的名字，你也将有机会与他们直接对话。
+
+我们将陪伴你一整年的时间，用六大模块为你详解技术领导力：
+
+一、**格局与战略**。这部分内容将帮助你打开视野，理解卓越技术领导者的核心能力的概念和价值，像 CEO 一样思考商业，让技术与商业战略协同，确立管理者能力模型。
+
+二、**团队管理**。这部分涵盖人员招聘、绩效考核、团队文化建设、研发管理等内容，将通过大量实战经验，帮你清楚认识领导力提升的有效途径，掌握领导力提升的工具与方法。
+
+三、**职场软技能**。通过这部分内容，你将了解如何更好地沟通、如何向上管理、如何打造个人品牌、如何管理情绪等等。令你在工作中游刃有余，从此踏上领导力提升的新旅程。
+
+四、**跳槽与创业**。有时候，选择比努力更重要，所以我们建议你先做好充分的准备。我们将和你一起探讨期权、套现、合伙人、商业模式等话题，让的你人生进阶之路更加平稳。
+
+五、**技术趋势解读**。让你快速了解最新的技术与趋势，比如区块链、人工智能、运维技术发展到了哪个阶段，你的企业是否还在用老旧的技术解决别人早已经轻车熟路的问题。
+
+六、**国家政策解读**。一个卓越的领导者，一定是顺势而为的。我们会邀请行业专家深入分析解读国家机构最新发布的产业政策，助力你洞察先机。
+
+希望一年之后，你已经成为了更好的自己。
+
+“技术领导力实战笔记”是一个全年专栏，在专栏的详情页中我们列出了全年六大模块中的具体话题，供你参考。下面是近四周将会具体更新的课程，后续还有更多精彩内容，欢迎订阅。
+
+<img src="https://static001.geekbang.org/resource/image/91/26/912705ac4deae37bf0e2497430a85726.png" alt="" />
+
+<img src="https://static001.geekbang.org/resource/image/99/26/992ffbead26bc883d896b81a04c39426.jpg" alt="" />

极客时间专栏/geek/技术领导力实战笔记/新春特辑1 | 卓越CTO必备的能力与素质.md

@@ -0,0 +1,26 @@
+
+你好，我是《技术领导力实战笔记》专栏的主编成敏，今天是除夕，先在这里祝你除夕快乐，身体健康，万事如意！
+
+从2018年4月16号，《技术领导力实战笔记》专栏更新第一篇文章开始，我们已经与你一起度过了9个多月的时光，更新了210篇文章，走过了专栏3/4的路程。
+
+在这9个多月里，我们邀请到了近百位CEO、CTO、技术VP等技术领导者来分享他们的实践与经验，话题涉及技术领导者的核心能力、高效技术团队的打造、高效研发流程的建设、技术团队的考核与激励、技术团队文化的建设、技术人才的选育用留等多个方向。
+
+这些文章虽有序但却分散在全年的专栏中，恰逢新春假期，我特别整理了5个热门的主题的直达专辑，以便您按照主题领域来回顾。你可以点击知识卡，跳转到你最想看的那篇文章，温故而知新。
+
+今天专辑的主题是“卓越CTO必备的能力与素质”，希望你看完之后能有所收获，也欢迎留言选出你最喜欢的文章，或是分享你对于CTO必备能力与素质的观点。
+
+[<img src="https://static001.geekbang.org/resource/image/75/88/75fadc34ed0fe3ad712b118d36890a88.jpg" alt="">](https://time.geekbang.org/column/article/6257)<br>
+[<img src="https://static001.geekbang.org/resource/image/7b/42/7b3800353526c0b11ee12984bd913e42.jpg" alt="">](https://time.geekbang.org/column/article/6374)<br>
+[<img src="https://static001.geekbang.org/resource/image/91/f3/91e8a7c392886eed5818e57d839fe4f3.jpg" alt="">](https://time.geekbang.org/column/article/6399)<br>
+[<img src="https://static001.geekbang.org/resource/image/fd/fd/fd2c65875e853d80592a45ab5f30d7fd.jpg" alt="">](https://time.geekbang.org/column/article/6581)<br>
+[<img src="https://static001.geekbang.org/resource/image/65/fb/6573a0c475e2dcbe9e4cac0afdd5a8fb.jpg" alt="">](https://time.geekbang.org/column/article/6585)<br>
+[<img src="https://static001.geekbang.org/resource/image/cb/04/cbbb2f888d5901ded73f3140d669e904.jpg" alt="">](https://time.geekbang.org/column/article/6656)<br>
+[<img src="https://static001.geekbang.org/resource/image/a4/67/a4674df83038f293aaa29e69ce476467.jpg" alt="">](https://time.geekbang.org/column/article/9426)<br>
+[<img src="https://static001.geekbang.org/resource/image/36/ef/36e080389c6bdd98c4471382f86008ef.jpg" alt="">](https://time.geekbang.org/column/article/10154)<br>
+[<img src="https://static001.geekbang.org/resource/image/86/03/86916db73d10f80ca26147aa06963903.jpg" alt="">](https://time.geekbang.org/column/article/12246)<br>
+[<img src="https://static001.geekbang.org/resource/image/3f/bc/3f0a4e2e6ab86ae2d9ba042f32d4efbc.jpg" alt="">](https://time.geekbang.org/column/article/12378)<br>
+[<img src="https://static001.geekbang.org/resource/image/9c/87/9c19f06035aac28dd1f8b57468f62487.jpg" alt="">](https://time.geekbang.org/column/article/74338)<br>
+[<img src="https://static001.geekbang.org/resource/image/4c/be/4ccb6db91735b0184e2122ca0a2e8bbe.jpg" alt="">](https://time.geekbang.org/column/article/75341)<br>
+[<img src="https://static001.geekbang.org/resource/image/bd/21/bd33e29204f5197b4ea8c952e3774621.jpg" alt="">](https://time.geekbang.org/column/article/79774)<br>
+[<img src="https://static001.geekbang.org/resource/image/3a/1c/3a2a5f71b8b7090991544156f447ed1c.jpg" alt="">](https://time.geekbang.org/column/article/6297)<br>
+[<img src="https://static001.geekbang.org/resource/image/23/79/23ce1ca0b690f0e142f7aed0029bb979.jpg" alt="">](https://time.geekbang.org/column/article/42080)

极客时间专栏/geek/技术领导力实战笔记/新春特辑2 | 如何成长为优秀的技术管理者？.md

@@ -0,0 +1,20 @@
+
+你好，我是《技术领导力实战笔记》专栏的主编成敏，今天是大年初一，祝你在新的一年里万象更新，事事顺心！
+
+今天专辑的主题是“如何成长为优秀的技术管理者？”，希望你看完之后能有所收获，也欢迎留言选出你最喜欢的文章，或是分享你关于技术管理者成长的实践与经验。
+
+[<img src="https://static001.geekbang.org/resource/image/72/9b/72cce3506deaa43d8bfd38a7517a839b.jpg" alt="">](https://time.geekbang.org/column/article/5765)<br>
+[<img src="https://static001.geekbang.org/resource/image/a1/2f/a115736e6e51b29ad43551adfd07e92f.jpg" alt="">](https://time.geekbang.org/column/article/11829)<br>
+[<img src="https://static001.geekbang.org/resource/image/3b/ef/3b76065b66e0c070795d4de55e700def.jpg" alt="">](https://time.geekbang.org/column/article/41315)<br>
+[<img src="https://static001.geekbang.org/resource/image/1f/9d/1f828d4896c7494d12c8a9f57e3ed19d.jpg" alt="">](https://time.geekbang.org/column/article/41898)<br>
+[<img src="https://static001.geekbang.org/resource/image/d0/16/d0e69b90e1e5707891da7c0841290116.jpg" alt="">](https://time.geekbang.org/column/article/65311)<br>
+[<img src="https://static001.geekbang.org/resource/image/11/bd/11622638116cbce02e79c7d396629abd.jpg" alt="">](https://time.geekbang.org/column/article/69096)<br>
+[<img src="https://static001.geekbang.org/resource/image/08/dc/08e0e9d1f9da309e283170232db10cdc.jpg" alt="">](https://time.geekbang.org/column/article/70873)<br>
+[<img src="https://static001.geekbang.org/resource/image/2c/8e/2ccf7d156e96fbfb946110502c2e2d8e.jpg" alt="">](https://time.geekbang.org/column/article/71156)<br>
+[<img src="https://static001.geekbang.org/resource/image/eb/14/eba8f6fe6d144962ab874402da8b0f14.jpg" alt="">](https://time.geekbang.org/column/article/73335)<br>
+[<img src="https://static001.geekbang.org/resource/image/b0/38/b010892be243589f51fe34ba32369e38.jpg" alt="">](https://time.geekbang.org/column/article/73596)<br>
+[<img src="https://static001.geekbang.org/resource/image/6e/26/6e431d38cff47cf16998e4a1c3866626.jpg" alt="">](https://time.geekbang.org/column/article/75727)<br>
+[<img src="https://static001.geekbang.org/resource/image/05/b0/050ae62a12f1720b13870e34ee0f65b0.jpg" alt="">](https://time.geekbang.org/column/article/77303)<br>
+[<img src="https://static001.geekbang.org/resource/image/bd/5d/bdb3a89e18e6affa67d1e611ad81d75d.jpg" alt="">](https://time.geekbang.org/column/article/77888)<br>
+[<img src="https://static001.geekbang.org/resource/image/41/b6/41b90fb26c042c4c80e3f81e1f5e8db6.jpg" alt="">](https://time.geekbang.org/column/article/7674)<br>
+[<img src="https://static001.geekbang.org/resource/image/ed/72/eddc1975a2d22a14fccac992fb8b0572.jpg" alt="">](https://time.geekbang.org/column/article/41650)

极客时间专栏/geek/技术领导力实战笔记/新春特辑3 | 如何打造高质效的技术团队？.md

@@ -0,0 +1,18 @@
+
+你好，我是《技术领导力实战笔记》专栏的主编成敏，高质效的技术团队是每个技术领导者的追求，今天专辑的主题就是“如何打造高质效的技术团队？”，希望你看完之后能有所收获，也欢迎留言选出你最喜欢的文章，或是分享你对于技术团队打造的实践与经验。
+
+[<img src="https://static001.geekbang.org/resource/image/d6/c3/d600e093a67eea0b0bf896829ac0aec3.jpg" alt="">](https://time.geekbang.org/column/article/6870)<br>
+[<img src="https://static001.geekbang.org/resource/image/9e/6e/9e01d9df7ee2124efdd4929444ebc46e.jpg" alt="">](https://time.geekbang.org/column/article/6915)<br>
+[<img src="https://static001.geekbang.org/resource/image/f1/1d/f100ba7d24c352310a4484e12036581d.jpg" alt="">](https://time.geekbang.org/column/article/7032)<br>
+[<img src="https://static001.geekbang.org/resource/image/a6/f1/a6a7ff57d8fbf5b974259802dfe82df1.jpg" alt="">](https://time.geekbang.org/column/article/7401)<br>
+[<img src="https://static001.geekbang.org/resource/image/b5/52/b59c78ebfbedc4222386ea0453b13b52.jpg" alt="">](https://time.geekbang.org/column/article/8273)<br>
+[<img src="https://static001.geekbang.org/resource/image/aa/2e/aa5bf6eea7f94da2c419dabf7c2b102e.jpg" alt="">](https://time.geekbang.org/column/article/8462)<br>
+[<img src="https://static001.geekbang.org/resource/image/dd/61/dd13e7b691fe9bf5ded172670c433561.jpg" alt="">](https://time.geekbang.org/column/article/12810)<br>
+[<img src="https://static001.geekbang.org/resource/image/92/23/92ee582f1797e2d8b4a782ae93d4e123.jpg" alt="">](https://time.geekbang.org/column/article/14399)<br>
+[<img src="https://static001.geekbang.org/resource/image/91/cf/91a648d898c4b46d78b18c4aa935e5cf.jpg" alt="">](https://time.geekbang.org/column/article/15992)<br>
+[<img src="https://static001.geekbang.org/resource/image/b6/70/b65addb2d49a379402e880bd9b7d5070.jpg" alt="">](https://time.geekbang.org/column/article/40487)<br>
+[<img src="https://static001.geekbang.org/resource/image/5f/c8/5ffd363444ccc97aa2d7ba4fe6cf48c8.jpg" alt="">](https://time.geekbang.org/column/article/74493)<br>
+[<img src="https://static001.geekbang.org/resource/image/c0/28/c0adee5c24de2874e14836efcf2a5728.jpg" alt="">](https://time.geekbang.org/column/article/78668)<br>
+[<img src="https://static001.geekbang.org/resource/image/5c/c7/5cf348342facb5098e8af28116dc96c7.jpg" alt="">](https://time.geekbang.org/column/article/79202)<br>
+[<img src="https://static001.geekbang.org/resource/image/2c/e1/2c6a84d5c741f2f5e0ebdabaa60627e1.jpg" alt="">](https://time.geekbang.org/column/article/6210)<br>
+[<img src="https://static001.geekbang.org/resource/image/29/53/29e1ea7fd91223fe7fa42f89470b4553.jpg" alt="">](https://time.geekbang.org/column/article/10074)

极客时间专栏/geek/技术领导力实战笔记/新春特辑4 | 如何打造高效的研发流程与文化？.md

@@ -0,0 +1,18 @@
+
+你好，我是《技术领导力实战笔记》专栏的主编成敏，研发流程与工程师文化两者一硬一软，共同组成了高效技术团队的基石。今天专辑的主题就是“如何打造高效的研发流程与文化？”，希望你看完之后能有所收获，也欢迎留言选出你最喜欢的文章，或是分享你对于技术团队打造的实践与经验。
+
+[<img src="https://static001.geekbang.org/resource/image/1c/ab/1cbf12d8a9e07e23ab09a286fcb3a1ab.jpg" alt="">](https://time.geekbang.org/column/article/6976)<br>
+[<img src="https://static001.geekbang.org/resource/image/79/ae/79a03c4c50af17320c2e11f8bc60f6ae.jpg" alt="">](https://time.geekbang.org/column/article/7338)<br>
+[<img src="https://static001.geekbang.org/resource/image/68/86/68210bea470c276e7ffbc837430ed286.jpg" alt="">](https://time.geekbang.org/column/article/7557)<br>
+[<img src="https://static001.geekbang.org/resource/image/1d/aa/1d06308592b6caa661d6959b0ab3a1aa.jpg" alt="">](https://time.geekbang.org/column/article/7916)<br>
+[<img src="https://static001.geekbang.org/resource/image/49/d8/49a5d1ba13caf64377ea04e8baf6fcd8.jpg" alt="">](https://time.geekbang.org/column/article/7991)<br>
+[<img src="https://static001.geekbang.org/resource/image/0f/44/0f8d4da91dfe2f72aced54b3e3bbd544.jpg" alt="">](https://time.geekbang.org/column/article/8395)<br>
+[<img src="https://static001.geekbang.org/resource/image/35/20/358085a01f28cccac37a6043cb469d20.jpg" alt="">](https://time.geekbang.org/column/article/8894)<br>
+[<img src="https://static001.geekbang.org/resource/image/10/16/100a00f67267681dfc94c2c278868f16.jpg" alt="">](https://time.geekbang.org/column/article/10612)<br>
+[<img src="https://static001.geekbang.org/resource/image/d5/07/d5c1e0087a4799d25c7d693877745207.jpg" alt="">](https://time.geekbang.org/column/article/11242)<br>
+[<img src="https://static001.geekbang.org/resource/image/c4/40/c40df8bc747e1ca22b5172b0bd32c540.jpg" alt="">](https://time.geekbang.org/column/article/11399)<br>
+[<img src="https://static001.geekbang.org/resource/image/e0/f0/e05f76bc831e6c82cdcefbcd7e6f45f0.jpg" alt="">](https://time.geekbang.org/column/article/12904)<br>
+[<img src="https://static001.geekbang.org/resource/image/62/cd/624a6d2330889c21e0fbe0c84010d3cd.jpg" alt="">](https://time.geekbang.org/column/article/71350)<br>
+[<img src="https://static001.geekbang.org/resource/image/eb/52/ebe2c2d729e9c3611a626ba1fbad1c52.jpg" alt="">](https://time.geekbang.org/column/article/78489)<br>
+[<img src="https://static001.geekbang.org/resource/image/09/99/099da711d671f205b529553076f11299.jpg" alt="">](https://time.geekbang.org/column/article/11594)<br>
+[<img src="https://static001.geekbang.org/resource/image/eb/c3/eb1ae980b60efb851e28484910a6e5c3.jpg" alt="">](https://time.geekbang.org/column/article/9308)

极客时间专栏/geek/技术领导力实战笔记/新春特辑5 | 如何做好人才的选育用留？.md

@@ -0,0 +1,18 @@
+
+你好，我是《技术领导力实战笔记》专栏的主编成敏，招到合适的人才并充分发挥他们的价值，是公司发展最重要的事情之一，也是技术领导者最重要的能力之一。今天专辑的主题就是“如何做好人才的选育用留？”，希望你看完之后能有所收获，也欢迎留言选出你最喜欢的文章，或是分享你对于技术团队打造的实践与经验。
+
+[<img src="https://static001.geekbang.org/resource/image/f8/c2/f830093a4a1629392d9dd87de78cb2c2.jpg" alt="">](http://time.geekbang.org/column/article/7778)<br>
+[<img src="https://static001.geekbang.org/resource/image/4a/b7/4acfb92457d5d15bcd2225b8919b26b7.jpg" alt="">](http://time.geekbang.org/column/article/8240)<br>
+[<img src="https://static001.geekbang.org/resource/image/a5/45/a5239a4aa9e55dd9b0d95f2e20d20b45.jpg" alt="">](http://time.geekbang.org/column/article/9052)<br>
+[<img src="https://static001.geekbang.org/resource/image/16/5b/16c14fb791308561d9c8d607d3a98b5b.jpg" alt="">](http://time.geekbang.org/column/article/9089)<br>
+[<img src="https://static001.geekbang.org/resource/image/01/7a/01ccd79a09c8e5db8b52b625f738d67a.jpg" alt="">](http://time.geekbang.org/column/article/9147)<br>
+[<img src="https://static001.geekbang.org/resource/image/68/42/6820bc84cbf9faa641e0b84e2377b042.jpg" alt="">](http://time.geekbang.org/column/article/9241)<br>
+[<img src="https://static001.geekbang.org/resource/image/f3/d6/f39a8fafa1e425cb698a65befeaf26d6.jpg" alt="">](http://time.geekbang.org/column/article/9854)<br>
+[<img src="https://static001.geekbang.org/resource/image/f3/51/f367d379d21b56f21f5904c7b4e9d651.jpg" alt="">](http://time.geekbang.org/column/article/9916)<br>
+[<img src="https://static001.geekbang.org/resource/image/86/ce/866872a4d977a54569cedc2ebd68d5ce.jpg" alt="">](http://time.geekbang.org/column/article/13719)<br>
+[<img src="https://static001.geekbang.org/resource/image/7d/2d/7d1cbb0d71d34d8dc6c1687a3408fa2d.jpg" alt="">](http://time.geekbang.org/column/article/40072)<br>
+[<img src="https://static001.geekbang.org/resource/image/ec/67/ec7e3a94668a1dc73cbe4ac12f20fe67.jpg" alt="">](http://time.geekbang.org/column/article/41439)<br>
+[<img src="https://static001.geekbang.org/resource/image/6f/ae/6ff488e87bccd62b7ce99465bdb49bae.jpg" alt="">](http://time.geekbang.org/column/article/69563)<br>
+[<img src="https://static001.geekbang.org/resource/image/5d/c2/5db345aa4c8c89bf88e73aaba98001c2.jpg" alt="">](http://time.geekbang.org/column/article/79196)<br>
+[<img src="https://static001.geekbang.org/resource/image/f6/8d/f617b6d4d9fd848be1aad661e0f6548d.jpg" alt="">](http://time.geekbang.org/column/article/10967)<br>
+[<img src="https://static001.geekbang.org/resource/image/73/55/73c225c2cc035f261841670457601555.jpg" alt="">](http://time.geekbang.org/column/article/40754)

极客时间专栏/geek/技术领导力实战笔记/温故而知新 | 一键直达，六大文章主题索引.md

@@ -0,0 +1,264 @@
+
+你好，我是《技术领导力实战笔记》专栏的主编成敏，很高兴与你一起走过一年的时间，
+
+从2018年4月到2019年4月，专栏共计发布260篇文章，话题涵盖了格局与战略、团队管理、职场软技能、跳槽与创业、技术趋势解读等。为了便于你按照主题领域来回顾，我曾在春节期间整理了5个热门主题的直达专辑。在此基础上，我又对整个专栏内容进行了梳理和精选，并整理为六大类，你可以点击知识卡，跳转到你最想看的那篇文章。
+
+[新春特辑1 | 卓越CTO必备的能力与素质](https://time.geekbang.org/column/article/80646)
+
+[新春特辑2 | 如何成长为优秀的技术管理者？](https://time.geekbang.org/column/article/80665)
+
+[新春特辑3 | 如何打造高质效的技术团队？](https://time.geekbang.org/column/article/80682)
+
+[新春特辑4 | 如何打造高效的研发流程与文化？](https://time.geekbang.org/column/article/80710)
+
+[新春特辑5 | 如何做好人才的选育用留？](https://time.geekbang.org/column/article/80730)
+
+## CTO能力、素质与战略类
+
+[<img src="https://static001.geekbang.org/resource/image/2d/de/2db7053163da7c6de0aaac39873e83de.jpg" alt="">](https://time.geekbang.org/column/article/5964)
+
+[<img src="https://static001.geekbang.org/resource/image/ff/65/fff31714ec088f127cd7f75caca99365.jpg" alt="">](https://time.geekbang.org/column/article/6259)
+
+[<img src="https://static001.geekbang.org/resource/image/71/9b/71472c526d7d1b0e4c6ee1d4a82ec09b.jpg" alt="">](https://time.geekbang.org/column/article/9521)
+
+[<img src="https://static001.geekbang.org/resource/image/bb/23/bbc4becdd0898ef31c138e0b171bfe23.jpg" alt="">](https://time.geekbang.org/column/article/12413)
+
+[<img src="https://static001.geekbang.org/resource/image/1f/85/1f9a9598e3401c2755751f6879a68485.jpg" alt="">](https://time.geekbang.org/column/article/13315)
+
+[<img src="https://static001.geekbang.org/resource/image/73/e3/7340a8ef501f24122778769ebfe14ee3.jpg" alt="">](https://time.geekbang.org/column/article/14477)
+
+<img src="https://time.geekbang.org/column/article/29398" alt="">
+
+[<img src="https://static001.geekbang.org/resource/image/25/ea/2573f3eb9395bbc7fb233fcaade80cea.jpg" alt="">](https://time.geekbang.org/column/article/40422)
+
+[<img src="https://static001.geekbang.org/resource/image/f6/01/f67bc7652aa38728bf4ceaab6ea61c01.jpg" alt="">](https://time.geekbang.org/column/article/70286)
+
+[<img src="https://static001.geekbang.org/resource/image/d2/23/d202c53829d6be9486aa860cf4bd9823.jpg" alt="">](https://time.geekbang.org/column/article/76599)
+
+[<img src="https://static001.geekbang.org/resource/image/5b/4a/5b313a9233250211a70c3c48fa266c4a.jpg" alt="">](https://time.geekbang.org/column/article/79685)
+
+[<img src="https://static001.geekbang.org/resource/image/ec/80/ecd183a3d2b102f90cfb0efd304bda80.jpg" alt="">](https://time.geekbang.org/column/article/83464)
+
+[<img src="https://static001.geekbang.org/resource/image/7d/6b/7d9a2d9c2cc49accde77870e343bcc6b.jpg" alt="">](https://time.geekbang.org/column/article/83994)
+
+[<img src="https://static001.geekbang.org/resource/image/d0/73/d0b3ffc6f0535a4889251dc7c7bc8673.jpg" alt="">](https://time.geekbang.org/column/article/14043)
+
+[<img src="https://static001.geekbang.org/resource/image/8b/a8/8bad4f9d6c09ff845391b027b9b822a8.jpg" alt="">](https://time.geekbang.org/column/article/41287)
+
+[<img src="https://static001.geekbang.org/resource/image/bf/5a/bf307942ac6dbbf5e9eefe89cfae095a.jpg" alt="">](https://time.geekbang.org/column/article/8131)
+
+[<img src="https://static001.geekbang.org/resource/image/ae/71/aee246c10ae38d6a0e623f9f20a27771.jpg" alt="">](https://time.geekbang.org/column/article/10492)
+
+## 创业、打造团队类
+
+[<img src="https://static001.geekbang.org/resource/image/49/77/490b8da1de78c59a4e665c8da1b80c77.jpg" alt="">](https://time.geekbang.org/column/article/7469)
+
+[<img src="https://static001.geekbang.org/resource/image/fd/b6/fde0bc1ef2766055dbc78d3a1cc878b6.jpg" alt="">](https://time.geekbang.org/column/article/9412)
+
+[<img src="https://static001.geekbang.org/resource/image/09/6c/09543c3f56f3f43c193d0a2c17d6676c.jpg" alt="">](https://time.geekbang.org/column/article/9605)
+
+[<img src="https://static001.geekbang.org/resource/image/53/85/53694ff452fbed38c115e84067932485.jpg" alt="">](https://time.geekbang.org/column/article/9756)
+
+[<img src="https://static001.geekbang.org/resource/image/ec/cb/ecae9526e0ee7bb43a5b352c225816cb.jpg" alt="">](https://time.geekbang.org/column/article/12658)
+
+[<img src="https://static001.geekbang.org/resource/image/d4/1a/d4b313b7608ea154628bda680024ce1a.jpg" alt="">](https://time.geekbang.org/column/article/12974)
+
+[<img src="https://static001.geekbang.org/resource/image/70/c4/701fad7382fb389021860971517892c4.jpg" alt="">](https://time.geekbang.org/column/article/40149)
+
+[<img src="https://static001.geekbang.org/resource/image/e7/16/e71f4a4bb4659bd20ce62bae378ce816.jpg" alt="">](https://time.geekbang.org/column/article/42365)
+
+[<img src="https://static001.geekbang.org/resource/image/9b/ba/9b7c6cefc245e8444027de5d0ec8a4ba.jpg" alt="">](https://time.geekbang.org/column/article/42369)
+
+[<img src="https://static001.geekbang.org/resource/image/71/93/711bee9cd7984b74bb565dee5a787a93.jpg" alt="">](https://time.geekbang.org/column/article/42544)
+
+[<img src="https://static001.geekbang.org/resource/image/03/fd/03dc20816903575980be6dd573f442fd.jpg" alt="">](https://time.geekbang.org/column/article/42614)
+
+[<img src="https://static001.geekbang.org/resource/image/f8/a7/f8106c24bd9cbeb85694150a09aa51a7.jpg" alt="">](https://time.geekbang.org/column/article/68269)
+
+[<img src="https://static001.geekbang.org/resource/image/52/68/52751cadb84a1cbc2e403ceb6a9fc868.jpg" alt="">](https://time.geekbang.org/column/article/68526)
+
+[<img src="https://static001.geekbang.org/resource/image/2e/a8/2e2f87c4ee8d47fbab27d9c31fd1dba8.jpg" alt="">](https://time.geekbang.org/column/article/72660)
+
+[<img src="https://static001.geekbang.org/resource/image/3b/3f/3bdc6a6c7dc828f5ee27d6ecf941303f.jpg" alt="">](https://time.geekbang.org/column/article/73176)
+
+[<img src="https://static001.geekbang.org/resource/image/45/fa/45384d8da115569dcea1cb52a6b101fa.jpg" alt="">](https://time.geekbang.org/column/article/76759)
+
+[<img src="https://static001.geekbang.org/resource/image/1e/f6/1e91e3bfe0e949180eb789db96000af6.jpg" alt="">](https://time.geekbang.org/column/article/82650)
+
+[<img src="https://static001.geekbang.org/resource/image/7a/e7/7a8b728466ec946e97cdf306f9eca4e7.jpg" alt="">](https://time.geekbang.org/column/article/82656)
+
+[<img src="https://static001.geekbang.org/resource/image/86/f5/86eeed3ac5eac8eaf4196a7f4fe124f5.jpg" alt="">](https://time.geekbang.org/column/article/7208)
+
+[<img src="https://static001.geekbang.org/resource/image/bf/ae/bfd7ad83a15c58d94ff1f6e7f68618ae.jpg" alt="">](https://time.geekbang.org/column/article/39741)
+
+[<img src="https://static001.geekbang.org/resource/image/28/9f/28d210baf5ca80efc252425544f3a59f.jpg" alt="">](https://time.geekbang.org/column/article/68628)
+
+[<img src="https://static001.geekbang.org/resource/image/53/84/53bd8af4b6d8fc204da4704aa4dcb184.jpg" alt="">](https://time.geekbang.org/column/article/69659)
+
+[<img src="https://static001.geekbang.org/resource/image/86/cc/863817430d9c06470701c2a9701fd9cc.jpg" alt="">](https://time.geekbang.org/column/article/73725)
+
+[<img src="https://static001.geekbang.org/resource/image/3e/e9/3eb08db1983f80e4bf75d13b2f4e7ce9.jpg" alt="">](https://time.geekbang.org/column/article/13063)
+
+[<img src="https://static001.geekbang.org/resource/image/5e/d7/5e6ab0e556a864a2d4127925093ea4d7.jpg" alt="">](https://time.geekbang.org/column/article/8936)
+
+[<img src="https://static001.geekbang.org/resource/image/db/50/db9bc41323bb70a6e9419f6f5e114250.jpg" alt="">](https://time.geekbang.org/column/article/9701)
+
+[<img src="https://static001.geekbang.org/resource/image/b6/05/b63a256eb2f527187007da197462bc05.jpg" alt="">](https://time.geekbang.org/column/article/67387)
+
+[<img src="https://static001.geekbang.org/resource/image/25/4d/25b18ad16c42c64dbb50b4b65310844d.jpg" alt="">](https://time.geekbang.org/column/article/72838)
+
+## 研发管理、团队管理类
+
+[<img src="https://static001.geekbang.org/resource/image/88/25/889a5cccbc6b0483a954649662552625.jpg" alt="">](https://time.geekbang.org/column/article/11680)
+
+[<img src="https://static001.geekbang.org/resource/image/f3/4e/f30499adeec5462e1bd53a6781157e4e.jpg" alt="">](https://time.geekbang.org/column/article/13670)
+
+[<img src="https://static001.geekbang.org/resource/image/2f/99/2feb74aa4ec96c483d4c2e05d5064899.jpg" alt="">](https://time.geekbang.org/column/article/14327)
+
+[<img src="https://static001.geekbang.org/resource/image/8e/8c/8e1cb0cb96e74d35f76ae2a70b3e478c.jpg" alt="">](https://time.geekbang.org/column/article/17304)
+
+[<img src="https://static001.geekbang.org/resource/image/d8/68/d8a0cc70e527c0654d2539d0bbf00b68.jpg" alt="">](https://time.geekbang.org/column/article/17858)
+
+[<img src="https://static001.geekbang.org/resource/image/71/13/71d00a3d2217bf88cd08fbc75aab0413.jpg" alt="">](https://time.geekbang.org/column/article/18130)
+
+[<img src="https://static001.geekbang.org/resource/image/df/67/dfe5863d22061017f131e00ebbb8a267.jpg" alt="">](https://time.geekbang.org/column/article/19175)
+
+[<img src="https://static001.geekbang.org/resource/image/5e/b4/5edbc81f9f297cef45c0c4a064bb59b4.jpg" alt="">](https://time.geekbang.org/column/article/40579)
+
+[<img src="https://static001.geekbang.org/resource/image/7d/7a/7de4ca1c7ccba0ff8da936d261263d7a.jpg" alt="">](https://time.geekbang.org/column/article/41127)
+
+[<img src="https://static001.geekbang.org/resource/image/ae/71/ae5db0e0c74a2a87ecd576811bdce171.jpg" alt="">](https://time.geekbang.org/column/article/41194)
+
+[<img src="https://static001.geekbang.org/resource/image/a3/df/a3b264d54a9919d421d8403e85c3addf.jpg" alt="">](https://time.geekbang.org/column/article/76387)
+
+[<img src="https://static001.geekbang.org/resource/image/1e/30/1ef7de405cb216efc08b47593c545d30.jpg" alt="">](https://time.geekbang.org/column/article/81412)
+
+[<img src="https://static001.geekbang.org/resource/image/12/42/12157926d252dc369f384feb54324042.jpg" alt="">](https://time.geekbang.org/column/article/82093)
+
+[<img src="https://static001.geekbang.org/resource/image/2b/a5/2b96f37d753f707c5cd3d46771472ea5.jpg" alt="">](https://time.geekbang.org/column/article/83458)
+
+[<img src="https://static001.geekbang.org/resource/image/fd/3c/fd09b3a41b41321752d49b868c59713c.jpg" alt="">](https://time.geekbang.org/column/article/84425)
+
+[<img src="https://static001.geekbang.org/resource/image/4d/6e/4dbce0aa044c3a967c92ac50c9ba656e.jpg" alt="">](https://time.geekbang.org/column/article/84686)
+
+[<img src="https://static001.geekbang.org/resource/image/c9/02/c98fcf5ec7bfb006b1711c671460e702.jpg" alt="">](https://time.geekbang.org/column/article/85674)
+
+[<img src="https://static001.geekbang.org/resource/image/71/16/7193e67376d68c9df530a7d9ca2b3016.jpg" alt="">](https://time.geekbang.org/column/article/86077)
+
+[<img src="https://static001.geekbang.org/resource/image/70/47/70ea855001574a9472af5220034f8947.jpg" alt="">](https://time.geekbang.org/column/article/86791)
+
+[<img src="https://static001.geekbang.org/resource/image/fe/38/fe8f5083d0baab2665aa3cdfa10f2238.jpg" alt="">](https://time.geekbang.org/column/article/87318)
+
+[<img src="https://static001.geekbang.org/resource/image/56/2a/56b217110a0e55d692ff98622b8f0e2a.jpg" alt="">](https://time.geekbang.org/column/article/87736)
+
+[<img src="https://static001.geekbang.org/resource/image/22/35/22661184fb74c894dfeb9454b14cb235.jpg" alt="">](https://time.geekbang.org/column/article/88405)
+
+[<img src="https://static001.geekbang.org/resource/image/6e/1a/6ee1d826639f2b684ded38fdfb44ef1a.jpg" alt="">](https://time.geekbang.org/column/article/88532)
+
+[<img src="https://static001.geekbang.org/resource/image/ed/09/ed98f5988712d7df430e4069f3569b09.jpg" alt="">](https://time.geekbang.org/column/article/88722)
+
+[<img src="https://static001.geekbang.org/resource/image/d1/96/d17f219ae0668972519da46f3f23fe96.jpg" alt="">](https://time.geekbang.org/column/article/88702)
+
+[<img src="https://static001.geekbang.org/resource/image/ab/9a/abefa0aae3a5b9d6d285a837124d629a.jpg" alt="">](https://time.geekbang.org/column/article/14594)
+
+[<img src="https://static001.geekbang.org/resource/image/4d/42/4d05507b86ee33607bb5f44b67665942.jpg" alt="">](https://time.geekbang.org/column/article/40228)
+
+[<img src="https://static001.geekbang.org/resource/image/03/42/033b9badd811813fff435c4a0a453f42.jpg" alt="">](https://time.geekbang.org/column/article/77047)
+
+[<img src="https://static001.geekbang.org/resource/image/cb/3b/cbbe34b982ee7d7a3c3dde4929f5f03b.jpg" alt="">](https://time.geekbang.org/column/article/77890)
+
+[<img src="https://static001.geekbang.org/resource/image/9e/03/9ee787f7efafd7ea815e703df95a3c03.jpg" alt="">](https://time.geekbang.org/column/article/42756)
+
+[<img src="https://static001.geekbang.org/resource/image/a5/80/a53d6e6b213a7b8f53236f9a17f76080.jpg" alt="">](https://time.geekbang.org/column/article/74970)
+
+[<img src="https://static001.geekbang.org/resource/image/4a/50/4a30ecddd90099d67a09e1560a4f3550.jpg" alt="">](https://time.geekbang.org/column/article/81840)
+
+[<img src="https://static001.geekbang.org/resource/image/3f/34/3fda0db40e8fb9584d15891389a07434.jpg" alt="">](https://time.geekbang.org/column/article/90064)
+
+## 绩效管理、空降管理类
+
+[<img src="https://static001.geekbang.org/resource/image/0b/7d/0b5d4e5ebeace4b5b2ed27dc14c6f67d.jpg" alt="">](https://time.geekbang.org/column/article/9985)
+
+[<img src="https://static001.geekbang.org/resource/image/a1/12/a126686d7b7107375bef521024173012.jpg" alt="">](https://time.geekbang.org/column/article/10154)
+
+[<img src="https://static001.geekbang.org/resource/image/40/8f/403d544089017454048b5a3d463cb08f.jpg" alt="">](https://time.geekbang.org/column/article/10310)
+
+[<img src="https://static001.geekbang.org/resource/image/ab/a2/ab0412d1d8b47b5de5edfd5a975e49a2.jpg" alt="">](https://time.geekbang.org/column/article/42873)
+
+[<img src="https://static001.geekbang.org/resource/image/0c/9c/0c240088843156117748c2a00543349c.jpg" alt="">](https://time.geekbang.org/column/article/64962)
+
+[<img src="https://static001.geekbang.org/resource/image/c7/63/c7b0e07c56b4581362ab5cc044b5ef63.jpg" alt="">](https://time.geekbang.org/column/article/67817)
+
+[<img src="https://static001.geekbang.org/resource/image/df/38/dfde48ab991ee638ab8c3075699db038.jpg" alt="">](https://time.geekbang.org/column/article/68973)
+
+[<img src="https://static001.geekbang.org/resource/image/09/00/09aa57d4bc31d19502096f627ac99c00.jpg" alt="">](https://time.geekbang.org/column/article/80267)
+
+[<img src="https://static001.geekbang.org/resource/image/06/10/06f5802c4d22cadaf76fcbfdc3f0c910.jpg" alt="">](https://time.geekbang.org/column/article/83163)
+
+[<img src="https://static001.geekbang.org/resource/image/35/1d/35d104d142c377779d30ddcae3f62e1d.jpg" alt="">](https://time.geekbang.org/column/article/83166)
+
+[<img src="https://static001.geekbang.org/resource/image/55/4e/55cbda4ede51400fc3ac6b39e5320f4e.jpg" alt="">](https://time.geekbang.org/column/article/83873)
+
+## 政策、趋势解读类
+
+[<img src="https://static001.geekbang.org/resource/image/f7/e1/f794f45cc797801c8081c3b40db84fe1.jpg" alt="">](https://time.geekbang.org/column/article/84455)
+
+[<img src="https://static001.geekbang.org/resource/image/a3/fe/a3880f4f51436195425cf9326e79aafe.jpg" alt="">](https://time.geekbang.org/column/article/85203)
+
+[<img src="https://static001.geekbang.org/resource/image/6c/94/6c4e8af42da3989b70a096dddc004e94.jpg" alt="">](https://time.geekbang.org/column/article/85391)
+
+[<img src="https://static001.geekbang.org/resource/image/79/f7/7942d9168f119c14efe25645a7af7ef7.jpg" alt="">](https://time.geekbang.org/column/article/87669)
+
+[<img src="https://static001.geekbang.org/resource/image/0d/a1/0d28a8778dbbe23c1eb64b66af4d1ba1.jpg" alt="">](https://time.geekbang.org/column/article/90534)
+
+[<img src="https://static001.geekbang.org/resource/image/2f/c1/2f4a823a2f8c05e593d910f9818b46c1.jpg" alt="">](https://time.geekbang.org/column/article/90875)
+
+[<img src="https://static001.geekbang.org/resource/image/d0/cd/d0479239149f987ca7d925424f0067cd.jpg" alt="">](https://time.geekbang.org/column/article/91179)
+
+[<img src="https://static001.geekbang.org/resource/image/53/33/531f3f964bae821907deedf26b2a3033.jpg" alt="">](https://time.geekbang.org/column/article/84756)
+
+[<img src="https://static001.geekbang.org/resource/image/9f/87/9fa4a67a6afc1caf0cd58320f2d66587.jpg" alt="">](https://time.geekbang.org/column/article/87011)
+
+[<img src="https://static001.geekbang.org/resource/image/86/f8/862e211f943ce756a48c6e48f28690f8.jpg" alt="">](https://time.geekbang.org/column/article/88016)
+
+## 职场文化、软技能类
+
+[<img src="https://static001.geekbang.org/resource/image/1f/b8/1f408838906c7e1513edcf59031059b8.jpg" alt="">](https://time.geekbang.org/column/article/8061)
+
+[<img src="https://static001.geekbang.org/resource/image/c1/ac/c1bb7c9d1eedde9037a9a3945215c3ac.jpg" alt="">](https://time.geekbang.org/column/article/8605)
+
+[<img src="https://static001.geekbang.org/resource/image/21/30/215e3b65a208112d91acad50c2562330.jpg" alt="">](https://time.geekbang.org/column/article/8686)
+
+[<img src="https://static001.geekbang.org/resource/image/9d/79/9d81ed7cc6e9962bcf819330f50aad79.jpg" alt="">](https://time.geekbang.org/column/article/8788)
+
+[<img src="https://static001.geekbang.org/resource/image/71/77/717440aa4137d5ffb083efada9d34077.jpg" alt="">](https://time.geekbang.org/column/article/11926)
+
+[<img src="https://static001.geekbang.org/resource/image/72/48/725c09888fd54635e256fec3d05c4848.jpg" alt="">](https://time.geekbang.org/column/article/12002)
+
+[<img src="https://static001.geekbang.org/resource/image/07/2a/0711ca73a91ece32d3e5c3b7a75f0a2a.jpg" alt="">](https://time.geekbang.org/column/article/13938)
+
+[<img src="https://static001.geekbang.org/resource/image/95/f3/954cb012cf70747415794fa3c94a45f3.jpg" alt="">](https://time.geekbang.org/column/article/13955)
+
+[<img src="https://static001.geekbang.org/resource/image/80/c1/8083cab7df1f0cc683f1770006f0adc1.jpg" alt="">](https://time.geekbang.org/column/article/14215)
+
+[<img src="https://static001.geekbang.org/resource/image/aa/25/aa4c247e0f01b93b6a5f745a1f69fd25.jpg" alt="">](https://time.geekbang.org/column/article/39936)
+
+[<img src="https://static001.geekbang.org/resource/image/0b/9c/0b60b114feb8dac03706bf6671657f9c.jpg" alt="">](https://time.geekbang.org/column/article/41311)
+
+[<img src="https://static001.geekbang.org/resource/image/ac/03/acfff6ebeb64f5cd5d7b2add63996003.jpg" alt="">](https://time.geekbang.org/column/article/64365)
+
+[<img src="https://static001.geekbang.org/resource/image/66/b8/66a51a9c94c1e1975c902261619027b8.jpg" alt="">](https://time.geekbang.org/column/article/72109)
+
+[<img src="https://static001.geekbang.org/resource/image/12/7d/122bb206c94fa640efec78c25f961c7d.jpg" alt="">](https://time.geekbang.org/column/article/89141)
+
+[<img src="https://static001.geekbang.org/resource/image/d2/92/d2959874c76c6be15718172e4b27ab92.jpg" alt="">](https://time.geekbang.org/column/article/89629)
+
+[<img src="https://static001.geekbang.org/resource/image/24/cc/246c2f00350ca046d121e9cd2f8da5cc.jpg" alt="">](https://time.geekbang.org/column/article/90238)
+
+[<img src="https://static001.geekbang.org/resource/image/37/28/37baeb146f3b007005700a46700f4028.jpg" alt="">](https://time.geekbang.org/column/article/6607)
+
+[<img src="https://static001.geekbang.org/resource/image/ea/da/ead71e23b6326d4e5e69d0f461c125da.jpg" alt="">](https://time.geekbang.org/column/article/8484)
+
+[<img src="https://static001.geekbang.org/resource/image/7a/83/7a9612005c4f8707ab8e253810042c83.jpg" alt="">](https://time.geekbang.org/column/article/89016)
+
+[<img src="https://static001.geekbang.org/resource/image/64/da/64387459ca36ff9cd6f7309aa2b149da.png" alt="">](https://gtlc2019.geekbang.org/?utm_source=geektime&amp;utm_medium=content)

极客时间专栏/geek/技术领导力实战笔记/第100讲 | 徐裕键：团队文化建设，保持创业公司的战斗力.md

@@ -0,0 +1,69 @@
+<audio id="audio" title="第100讲 | 徐裕键：团队文化建设，保持创业公司的战斗力" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/7f/af/7fb46d183e6ff0846a51a62e2fce66af.mp3"></audio>
+
+你好，我是贝贝网合伙人徐裕键，之前的文章中，我分享了业务高速增长中的团队迭代和技术演进，而保证团队持续迭代和技术持续演进的一个关键是团队文化。
+
+团队文化可以成为每个员工的行为准则，影响个人意识，当个人意识与团队文化达成一致时，团队就会逐渐走向成熟，并具备极强的战斗力。所以，今天我想跟你分享我们在团队文化建设上的一些实践。
+
+## 创业公司发展路径
+
+从文化的角度讲，一个企业基业常青，它的发展路线必然会经历一个S型的增长曲线。
+
+以阿里巴巴为例，它最初专注于国内批发贸易市场，做ToB业务。当ToB业务做到一定的规模后，它预感到了业内天花板的存在，此时，又发现ToC领域有非常大的市场，于是创立了淘宝网，直接触达普通用户。然后又发现用户和商家在交易时存在非常大的痛点，于是推出了第三方支付工具“支付宝”，以担保交易的方式使消费者对网上交易产生信任。随后又推出阿里旺旺，方便用户与商家沟通，这样一来，即时通讯工具与网络购物就有了联系。之后又发现了商品品质与用户购物体验的问题，于是推出了天猫商城。而当线上交易的渗透率达到一定深度后，业务的天花板也是显而易见的，于是又从业务转向技术，开始做阿里云。
+
+从阿里巴巴大概的成长历程可见，每一个创业公司都必须经历这样的过程，即不断地寻求新的业务增长点，预见问题、解决问题，并保持持续迭代，不断追求新的制高点。
+
+我们公司也是一样的，我们是一个持续创业公司，最初，我们做的是返利模式，后来发现返利的天花板非常明显，之后转到导购，又发现导购需要依赖于淘宝、天猫等电商平台，受制于人，天花板也非常明显。
+
+之后，我们发现了母婴市场，并迅速切入进去。当时母婴市场还是一片蓝海，其实蓝海和红海是相对的，很多人们以为是蓝海的领域，进去之后发现已经变成了红海。好的商业模式会让蓝海很快变成红海，所以创业者一定要有在红海中竞争的姿态。
+
+所以，在母婴市场，我们也需要不停地进行迭代，在成长过程中，不停地寻求新的业务增长点，寻求新的突破。
+
+另外，每个S形迭代的过程中，都有很多不确定因素，这对于团队成员的考验非常大。因为在每个S阶段中，都有高速增长期和顶峰停滞期。在高速增长期，业务发展快，大家都会比较亢奋，很多问题都会被掩盖掉，不会被发现。然而，当业务达到顶峰停滞期时，之前被掩盖的问题都会暴露出来，这时就需要团队去做调整，去寻找新的破局点，对于团队成员的考验也就随之加大，会需要他们具备强烈的文化认同感与执行力。
+
+## 文化价值认同感
+
+我们推崇的文化主要有三点，第一是自我驱动，第二是头狼精神，第三是价值认同。
+
+### 自我驱动
+
+我们会在团队内部强调创业文化，强调自我驱动。因为我们希望，在确定目标、明确方向之后，大家能够基于问题出发，以结果为导向，带着敢担当的精神做事情。同时也希望每个人都能带队伍冲锋、打胜仗。
+
+因为，创业过程确实存在很多不确定性因素，会遇到各种问题与挑战。无论是来自于公司的流程制度，还是应用系统等工具支撑，都存在许多不完善之处，而这些不完善，都需要员工自己开拓解决方案。那么，员工能否将这些问题当做一次次机会，发挥自身价值，就需要看他们是否具备创业精神与自我驱动的意识。
+
+另外，团队中的Leader，必须具备识别小白兔与老白兔的能力。所谓的“小白兔”即勤勤恳恳干活，认认真真做事，但不生产业绩的成员。而“老白兔”则是加入团队的时间比较早，以过往的功劳自居，也是勤勤恳恳做事但不产生业绩的人。对于这两类团队成员，管理者应该及时处理，该淘汰就淘汰，否则也会影响到其他团队成员的积极性与成长速度，对公司的发展非常不利。
+
+### 头狼精神
+
+所谓的头狼精神即开拓、进攻、猎杀，对创业公司来讲，开拓与进攻非常重要。因为无论你做到何种规模，想守住第一都很难，迟早会被别人超越，所以，只有每时每刻具备危机感，保持敏锐，去发现新的机会，转守为攻，才能确保你的核心竞争力。
+
+在创业公司，很多情况并不是考验员工的整体能力，而是考验员工的执行力，包括能否接受各种考验，能否主动突破问题、获取知识，能否做到快速执行，以及执行后能否做到持续迭代优化。创业公司能否保持快速迭代，可以说与团队员工的执行力紧密相关。
+
+如果团队中的每一位成员都能够具备创业精神和头狼精神，遇到问题积极挑战，而不是吐槽抱怨，那么，团队将会快速稳定的走向成熟。
+
+对贝贝网来讲，我们的目标是成为全球领先的母婴公司，那么就必须要保持头狼精神，保持领先的思维方式，积极进取，勇于开拓，构建核心竞争力，以免被他人超越。
+
+### 价值认同
+
+我们在确定公司的使命、愿景及价值观这条文化建设道路上，花了好几年的时间，我们会去研究、借鉴很多优秀公司的文化价值观。经过几年的积极探索，我们逐渐形成了属于自己的开发者文化。
+
+想知道自己到底有没有文化，其实很简单，就问自己接下来团队要举办的活动中，大家对哪些活动寄予期望，另外，是否有什么东西成为他们工作的准则。
+
+我也会经常在技术团队提及公司文化的slogan，使大家增强认同感、归属感与使命感。
+
+比如，我们要求团队成员有责任感，持续迭代对用户负责。不论是公司的商业模式、产品，还是技术都需要进行持续迭代。尤其作为研发者，给用户交付产品功能，并不是将功能上线就完成了，而是要持续迭代，交付给用户真正有价值的东西。
+
+而如何将这些喊口号的内容做实、落地、体系化，并转型为生产力，就需要我们作为技术领导者在日常工作中不断的积累和沉淀。
+
+以贝贝网为例，我们把“悟空”设为我们文化的关键词，因为我们的发布系统叫“悟空”，并由此衍生出很多含有“悟空”因素的活动，比如新员工培训叫“大闹天宫”，高精尖的老员工进阶叫“悟空训练营”，一年一度的技术嘉年华叫“悟空说”，等等。
+
+我们第一次举办技术嘉年华的时候，针对五个领域、五大专题进行分享，时间定在每天晚上的七点到九点，每个专题每个晚上都会分享两到三个话题。当时，虽然我们公司的技术人员不多，只有两三百人，但是每天晚上会场都坐满，甚至站满，并且吸引了很多产品组、运营组同学一起分享交流。
+
+最后，我们也对这次技术嘉年华进行了满意度调研，结果发现，满意度、认可度、赞赏度都非常高，并在团队中形成了一种技术文化氛围。而最重要的是，团队成员可以互相借鉴彼此的经验，提升自己，获得成长。
+
+总的来说，团队文化建设不是一蹴而就的事情，需要统一团队成员的文化价值观，使大家目标保持一致。对于企业的使命、愿景有强烈的实现愿望，并将想法有效执行，而在团队文化建设中，也需要做好文化传承，将企业的精神、态度、价值等有效传承下去。
+
+## 作者简介
+
+徐裕键，贝贝网合伙人兼研发副总裁。负责贝贝技术团队管理，从0到1搭建贝贝移动电商产品和技术架构，推动集团各个技术领域快速演进，完善技术团队的梯队搭建和文化建设。
+
+

极客时间专栏/geek/技术领导力实战笔记/第101讲 | 刘俊强：领导力提升指南之培养积极的态度.md

@@ -0,0 +1,66 @@
+<audio id="audio" title="第101讲 | 刘俊强：领导力提升指南之培养积极的态度" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/90/4f/90703fe9368715b0279a31396adfc54f.mp3"></audio>
+
+你好，我是腾讯云资深架构师、TGO鲲鹏会会员刘俊强，有着8年以上的技术管理经验，今天想跟你分享技术管理者如何做好情绪管理、培养积极的态度。
+
+作为技术管理者需要负责的事情繁多，需要培养并带领团队完成工作目标，会面临诸多不如人意或突发的情况，稍加不注意就会让自己陷入到负面情绪中。我们必须及时处理工作中的负面情绪，不论是团队成员的或是自己的，毕竟负面情绪是可以传播的，我们当然不想给团队增加消极性，从而影响士气和团队表现。
+
+一般来讲，我们在工作中常见的负面情绪及典型场景有以下这些：
+
+1. 挫败：当我们感到卡住或陷入困境时，通常会有挫败感。有可能是团队没有按照你的期望完成好项目，抑或是上司或老板未按时出席你主持的会议。
+1. 愤怒：失控的愤怒可能是人们在工作场所中经历的最具破坏性的情绪。同时这也是我们大多数人处理得不好的情绪，作为管理者更要学会控制愤怒的情绪。
+1. 忧虑：是对尚未到来事情的担忧和焦虑，例如公司业务发展受阻，需要对技术团队进行人员优化，抑或是工作挑战大担心完成不了等。忧虑的情绪不加以控制的话，很容易扩散影响自己的身心健康和工作效率，同时也容易让你在工作中不太愿意承担风险。
+1. 失望：当事情未达到我们期望时，一般会产生失望的情绪，例如团队成员认为未取得应得的晋升时。失望的情绪也会让我们趋向避免承担风险，影响到我们的工作效率。
+
+不得不承认的是，工作场所中不出现负面情绪是不可能的，不论是因为管理者糟糕的决策引起的，亦或是由团队成员的个人问题引起的，作为技术管理者，我们不能对负面情绪视而不见，不去处理，任由它们在团队中蔓延，影响团队效率和士气。作为合格的管理者，我们应该学会在团队中培养积极的态度，学习洞察和处理负面情绪。
+
+接下来，我们就聊聊如何来应对负面情绪、培养积极的态度，希望对你实际工作或生活产生些帮助。
+
+## 应对挫败感
+
+无论是基于什么原因，快速处理挫败感很重要，因为它很容易导致更多的负面情绪，比如愤怒。对于处理挫败感我这里有些建议：
+
+1. 首先是停下来评估，当你感到挫败时，能够做的最好的事情之一就是先停下来，当然这里说的停下来是指精神和思维上，回顾下遇到的情况，问问自己为什么感到沮丧，记录下来并具体来看这些事情，想想所遇到情况的积极方面，例如你的上司开会迟到了，你就会有更多的时间准备会议，或者，利用这段时间放松一下也不错。
+1. 如上所说，寻找情况的积极面，考虑你所遇到情况的积极方面会帮助你以不同的方式看待事物，角度微小的改变能够对我们的心情进行改善，因为造成你挫败感的人，他们可能并不是刻意让你沮丧或困扰的。因此让你挫败事情的产生，并不是某个个人的，不要在意，继续前进做你该做的事情。
+1. 消除脑里的负面词语，一般产生挫败感时，我们的脑子里会不自主产生些负面词汇或语句，让我们陷入这种负面情绪的影响之中，例如 “糟糕，又被坑了” “怎么总是做不好呢”，我们可以使用语气不那么重的词汇及语句来替换，例如 “事情进展有些不顺利” “完成情况低于预期”等，状况或事情总要解决的，因此不要沉迷于挫败感，如上面所说的继续前进带领团队解决问题。
+
+## 控制愤怒
+
+没有人会喜欢自己发怒的样子，作为管理者更不应该对团队成员发怒，因为这样会很容易将之前建立的团队信任摧毁掉。愤怒可能是工作中最普遍的负面情绪，从过往经历而言，愤怒在团队管理中还是蛮常见的，甚至于有些管理者会习惯性使用愤怒来达到自己的目的，但是与愤怒的人一起工作是让人辛苦、精疲力尽的。当人愤怒或回应愤怒时，大脑会让我们难以沟通或清晰地思考，那么我们该怎么避免在工作中发怒呢？
+
+1. 注意愤怒的早期迹象，只有你知道愤怒发生时的危险信号，所以我们要学会在它们开始时识别它们。尽早制止你的愤怒是关键，请记住，你的第一反应是生气，但并不意味着这是正确的反应。如果你开始生气，停下正在做的事情，闭上眼睛，进行深呼吸，将注意力集中在呼吸这件事情上，这样反复深呼吸后，能够帮助自己将注意力拉回到事情本身，而不是陷在愤怒的负面情绪中。
+1. 当生气时想象自己生气的样子和表现，例如，如果你要对团队大喊大叫，想象一下你自己的样子，是不是面红耳赤、手舞足蹈，你自己是否愿意和这样的人一起工作？我相信答案一定是否定的。
+1. 学会聆听，团队管理中经常会遇到的愤怒场景，便是团队成员对未完成好的事情进行解释或辩解，这很容易让管理者情绪达到临界点，进而爆发，因此我们要学会聆听，保持冷静沉着的风度，继续听下去，找出问题所在并引导团队进行纠正，以讨论问题的方式进行处理，如果进行到激烈时候，可以暂停5分钟，彼此冷静下再讨论问题。
+
+## 解除忧虑
+
+我们可能会对工作中发生的一些情况产生忧虑的情绪，例如糟糕的季度工作业绩、上司对于团队的不信任或公司发展受阻需要裁员等。忧虑通常伴随着恐惧，人类的生理本能会让人战斗、逃离或站着不动，而作为管理者，我们面对这些状况时，还需要带领团队继续前进，例如在不尽人意的业绩情况下，继续改进给予完成目标的希望。那么我们该怎么面对和处理？
+
+1. 正面处理员工的恐惧，坦诚地与团队成员沟通现状，并探讨接下来该怎么改善处理，唯有行动才能打破忧虑与恐惧，也就是人类本能里要么跑、要么战斗，站着不动可能被野兽吃掉，而因为我们是管理者，所以我们必须正面面对恐惧与忧虑，例如业绩不好，我们需要坦诚合理地探讨分拆实现的可能性，以及因为业绩不好带来的负面影响。
+1. 帮助员工避免夸大风险，当事情失去控制时，人们难免会产生恐惧并可能会放大忧虑。作为管理者，我们应该通过自己的经验和分析，帮助员工正视现状及问题，鼓励他们专注于如何改善现状，例如害怕被解雇，坐在那担心并不能帮助他保住工作，我们需要引导他们如何展示自己对于公司的价值。
+1. 记下你的担忧，如果你发现有些事情总是烦恼着自己，那么请将它们记录下来，然后安排时间处理它们，在此之前，你可以忘记这些担忧，因为你知道自己会去处理他们。在时间安排上，我们可以对这些担忧进行适当的风险分析，并看看可以采取哪些措施来减少风险。
+
+## 宽容失望
+
+我们可能会在工作中失望或悲伤，不论哪种情绪都对干好工作没有帮助，我们可以采取一些主动措施来应对失望和不快乐：
+
+1. 调整自己的心态，花一点时间让自己意识到事情并不总是一帆风顺的，说句鸡汤的话，正是完成事情过程的起起伏伏才让得生活变得如此有趣。
+1. 适当调整目标，如果你对团队未达到目标感到失望，并不意味着目标不可到达，可能是需要再多点的时间，那么是否可以调整下截止日期呢？如果团队总是无法在截止日期前达成目标，那么要思考的是目标拆分、进度管理是否合理呢？
+1. 帮助员工调整，前面我们有举例，员工可能会因为未取得自己期望的晋升而感到沮丧和迷失方向，他们会觉得自己经历了损失，因此作为管理者，我们在沟通时要有同理心，不要要求他们怎么怎么做，而是引导他们如果要达到自己的期望，应该要解决哪些问题，并认可他们出色的地方以帮助他们建立自信，达成目标。
+
+## 总结
+
+我们在上面谈到了一些常见的负面情绪，以及如何应对它们。我认为作为管理者应该明白的一点是，不论你自己或团队产生了负面情绪、士气低落，这些都是你要承担责任的，因为你是管理者，需要你来带领大家走出困境解决问题。
+
+做个阳光积极的管理者并不容易，需要我们保持对团队负面情绪的洞察，并采取适当的方法进行处理，而这需要管理者不断训练精进。最后，当然是希望收听的各位都能够成为应对负面情绪的熟手，带领团队元气满满的工作。
+
+## 思考题
+
+你最近一次发现团队负面情绪是什么呢？你又是如何应对的，欢迎在留言区分享。
+
+感谢你的收听，我们下期再见！
+
+## 作者介绍
+
+刘俊强（微信公众号：程序员精进）现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+年以上互联网开发经验，8年以上技术管理经验。
+
+

极客时间专栏/geek/技术领导力实战笔记/第102讲 | 姚从磊：巧用AARRR模型，吸引优秀技术人才（一）.md

@@ -0,0 +1,99 @@
+<audio id="audio" title="第102讲 | 姚从磊：巧用AARRR模型，吸引优秀技术人才（一）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/89/8d/895324ea1f542b03960d5b8e7d2abc8d.mp3"></audio>
+
+你好，我是百炼智能联合创始人兼CTO姚从磊，我于2008年从北京大学网络实验室博士毕业，先后经历过大型外企、大型互联网公司和不同规模不同阶段的创业公司，并于2018年5月创办百炼智能。
+
+这十年间，作为技术线和业务线负责人，先后面试过的技术人员超过两千人，读过的简历更是数以万计。在这个过程中，经常会为吸引到顶尖的技术人才而感到欣喜，更为错过优秀的技术人才而感到惋惜。
+
+欣喜和惋惜之余，逐渐发现吸引优秀技术人才这件事儿，跟研发运营一款成功的产品有着相通之处；并且，产品研发运营过程中的成熟方法论，可以直接拿来提升吸引优秀技术人才的成功率，AARRR 模型就是其中之一。
+
+## 何为 AARRR 模型？
+
+AARRR 模型（图1）是一个经典的用户生命周期分析模型，在互联网产品研发运营中被频繁使用。在这个模型中，一个产品的用户生命周期分为五个阶段：
+
+1. Acquisition：获取用户阶段，通过各种免费和付费的方式获取大量用户；
+1. Activation：产品互动阶段，在用户初次体验产品的时候，最大程度让用户感受产品的核心价值，并尽可能将其吸引回来重复使用；
+1. Retention：用户留存阶段，用户被产品功能吸引，频繁使用产品；
+1. Revenue：获取收入阶段，利用广告、收费等模式，将用户流量转化为商业收入；
+1. Referral：口碑传播阶段，用户认为产品足够好，主动向周围的人介绍。
+
+<img src="https://static001.geekbang.org/resource/image/43/a3/430da36f3669a30edffd8c2bd4b049a3.png" alt=""><br>
+（图1 产品研发运营的 AARRR 模型）
+
+AARRR 模型也是一个漏斗转化模型，可以用来验证产品的价值，并指导产品的研发和运营行为。
+
+从产品的角度来看，如果每个阶段的表现都很好，就可以形成理想的产品闭环：
+
+- 因为有很好的用户获取能力，就会有源源不断的新用户来尝试产品；
+- 因为有很好的产品体验，新用户在尝试过程中更容易被产品核心功能吸引；
+- 因为有很高的留存率，新用户会频繁使用产品核心功能，快速转化为忠实用户；
+- 因为有很强的获取收入能力，就可以在不影响用户体验的前提下获取足够多的收入，进一步投入产品研发、采购更多新用户；
+- 因为有很好的口碑传播，用户一传十十传百，就能免费获得更多的高质量新用户；
+- 因为有能力采购更多新用户、获取更多免费的高质量新用户，用户获取能力就变得更强，最终形成闭环。
+
+AARRR 模型只是一个普适性的分析模型，它可以帮助优化产品体验和运营策略，但无法决定产品成败；一个产品的成败，还取决于一个关键问题：产品解决了哪群人的哪个痛点？这个关键问题不能解决好，AARRR 就全无用武之地。
+
+## AARRR 模型 VS. 吸引优秀技术人才
+
+一提到吸引优秀技术人才，大都会第一时间想到「招聘」。但真正的吸引，远不止于把人才招聘进来。在吸引优秀技术人才加盟后，更重要的是让每位人才在公司充分实现价值，高度认同公司，并源源不断地介绍自己的亲朋好友加盟，这样才会形成吸引优秀人才的「闭环」。
+
+这个闭环，同前面提到的产品闭环、用户体验闭环完全相同。借鉴产品研发和运营的 AARRR 模型，我们可以得到吸引优秀技术人才的 AARRR 模型，如图2所示。
+
+<img src="https://static001.geekbang.org/resource/image/0c/46/0cd9e61c6dbd6cce96bedafc7f212546.png" alt=""><br>
+（图2 吸引优秀技术人才的 AARRR 模型）
+
+这个模型同样分为五个阶段：
+
+1. Acquisition：触达人才阶段，通过各种渠道触达尽可能多的优秀技术人才；
+1. Activation：面试入职阶段，打造一流的面试入职体验，促成优秀人才顺利面试入职；
+1. Retention：人才留存阶段，为人才提供足够良好的工作和学习环境，提高人才对公司的认同感；
+1. Revenue：实现价值阶段，人才在公司充分实现自我价值，并为公司发展贡献力量；
+1. Referral：内部推荐阶段，人才对公司高度认同，主动推荐亲朋好友加入，一起奋斗。
+
+同样，这个模型可以奏效的前提是，必须弄清楚两个关键问题：
+
+1. 公司需要什么样的优秀技术人才（目标用户画像）；
+1. 这些优秀技术人才需要什么（目标用户痛点）。
+
+接下来，我们会首先解决「目标用户画像」和「目标用户痛点」两个问题，之后集中讨论 AARRR 五阶段中的关键策略，最后是简短的总结和建议。
+
+## 目标用户画像——何为优秀的技术人才？
+
+宁要一位优秀的技术人才，也不要100位平庸的工程师。一位优秀技术人才的贡献，要超过至少100位平庸的工程师。
+
+虽然不同阶段的公司对优秀技术人才的定义有所差别，但还是有着诸多共性。
+
+**首先，「聪明和好奇心」会是一个基本特征。** 聪明意味着学习能力强，成长速度快，可以同公司一起成长，将不可能变为可能。好奇心意味着探索精神强，对未知事物有强烈的求知欲，对新技术有浓厚兴趣。
+
+聪明和好奇心往往是联系在一起的，只有聪明但没有好奇心，则只是在自己熟悉的领域里原地打转，虽然看起来更专注，但由于好奇心的缺失，事实上很难越钻越深；只是有好奇心但不够聪明，则只是对大多数技术领域略懂皮毛，夸夸其谈可以，深入解决问题就不灵了。
+
+**第二，「实战能力」会是重中之重。** 过去的面试中，我经常遇到聪明且好奇心强的人，开始聊的时候会非常开心。一旦抛出一个实际的问题，不少人会很快提出一个大体方案，但当尝试细化到可执行层面时，往往就不太顺利了。尤其是在自然语言处理领域，如果不是标准化的问题（给定输入输出，给定训练集、测试集和评价标准），而是一个开放性的来源于实际研发中的问题，十有八九会不太顺利。
+
+这些情况，大都是缺乏实战能力造成的，虽然思路不错，但还是浮于表面，离具体落地尚有一段距离。当然，一部分这样的候选人，可以作为较初级的技术人才培养。但是，如果在聊及过往主要参加的项目时，候选人对具体细节和例外情况的处理也是含糊不清的话，那就建议敬而远之了。
+
+**第三，「一技之长」会是非常关键的因素。** 当然，这一点主要针对有一定工作经验（工作两年以上）的人，但如果经验尚浅也具备一技之长的话，那就更好了。
+
+所谓一技之长，指的是在一个技术领域有一定的技术深度和积累。技术领域无所谓大（比如图数据库）小（比如中文分词），关键是要对领域内的主流技术方案有全面的理解，有独特的分析视角，更有第一线解决实际问题的实战经验和积淀。具备「一技之长」的人，是对自己职业生涯有着详细规划和强执行力的人，是非常优秀的技术人才。
+
+**共性的最后一点，我认为是「无边界」的特质。** 没有一个人是可以脱离团队而独自达成高难度目标的，攀登珠峰如此，研发运营产品更是如此。在团队合作中，如果成员可以做到「无边界」，乐于承担更多，乐于帮助团队内外的同事，为了共同的目标而不计小节，这样的团队往往无往不利，团队中人才的成长速度也往往超出预期。
+
+「无边界」的技术人才，是大多数公司都异常需要的，但往往可遇不可求，一旦遇见，就一定要拼尽全力去打动、去吸引，因为他们的辐射作用会使得周边的技术人才变得更加优秀。
+
+**谈完共性，再聊聊差异。** 公司在发展的不同阶段，对优秀技术人才的定义也会有所不同。对于类似百炼智能这样的初创公司来讲，除了以上提到的这些共性的点，还对人才的「野心」和「乐观」非常关注。
+
+有了足够强的「野心」，会相信自己和团队可以一起创造不可能；有了足够强的「乐观」精神，则会更容易克服从0到1过程中的各种困难，在坎坷时不但不气馁，反倒会觉得坎坷之后就是胜利。
+
+对于从1到10的快速发展期的公司来讲，就会对人才的「快速学习能力」更为看重，因为公司业务的快速发展会产生大量的空缺，需要每个人及时的补位，需要人才在极短时间内快速大量地学习。
+
+而对于稳定期的公司来讲，则会对人才是否「耐得住寂寞」较为看中，毕竟稳定期的业务，在大量重复性工作的同时，需要能够深入发掘钻研，发现更大的机会，而这个过程会需要极大的耐心和稳定性，所以「耐得住寂寞」会是一个需要的特质。
+
+## 下篇预告
+
+在讲清楚 AARRR 模型同吸引优秀技术人才的关系，并讨论完「目标用户画像」这个关键问题后，我们会在下一篇详细分析目标用户的痛点，尝试讨论清楚优秀的技术人才需要什么这一关键问题。
+
+最后给你留一个思考题：为什么宁要一位优秀的技术人才，也不要100位平庸的工程师？
+
+## 作者简介
+
+姚从磊，百炼智能联合创始人兼CTO，致力于利用深度自然语言处理技术，将无结构的公开互联网信息结构化，构建以商业机构和商业人物为核心的知识图谱，服务于各种商业场景。2008年博士毕业于北京大学计算机系“天网”实验室，师从李晓明教授。毕业后，先后在惠普中国研究院、腾讯负责文本挖掘和搜索引擎相关技术和产品研发。2012年加入豌豆荚先后负责技术团队和搜索、营收等业务，主导建设的技术团队成为当时国内最有吸引力和竞争力的团队。2016年加入Kika任CTO，负责AI技术团队打造、输入法AI引擎、语音识别等业务，大幅提升 Kika 的技术实力。
+
+

极客时间专栏/geek/技术领导力实战笔记/第103讲 | 姚从磊：巧用AARRR模型，吸引优秀技术人才（二）.md

@@ -0,0 +1,79 @@
+<audio id="audio" title="第103讲 | 姚从磊：巧用AARRR模型，吸引优秀技术人才（二）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/72/e7/724aed385cf80fe707235c98432a94e7.mp3"></audio>
+
+你好，我是百炼智能联合创始人兼CTO姚从磊，上一篇文章中，我与你分享了AARRR 模型同吸引优秀技术人才的关系，而这个模型奏效的前提必须弄清楚两个关键问题，一是公司需要什么样的优秀技术人才，即目标用户画像；二是这些优秀技术人才需要什么，即目标用户痛点。
+
+上一篇文章中，我们已经讨论完「目标用户画像」这个关键问题，今天，我将详细分析目标用户痛点，尝试讨论清楚优秀的技术人才需要什么这一关键问题。
+
+虽然不同阶段的公司对优秀技术人才的定义会有所差异，但从「目标用户痛点」的角度来看，优秀技术人才的痛点往往共性更多，差异更少。最基本的痛点有二，一为「成长」，二为「成就感」。
+
+## 「成长」痛点
+
+每一位立志于长期从事技术工作的人，都渴望能够在技术和相关产品业务领域快速成长。而技术人才的快速成长需要满足三个支撑条件。
+
+### 1.牛人环境
+
+首先，成长环境非常重要，需要有「牛人环境」。如果周围的人都比自己要强，耳濡目染下，自己也会有不错的成长。如果周围有行业中一流的牛人，有了牛人作为参照，自己成长为牛人的概率也会大大提高。并且，这里的「牛人」，不仅指自己专业领域的牛人，其他相关领域的牛人，也是多多益善。
+
+从我这些年组建打磨优秀技术团队的经历来看，「打铁首先自身硬」，团队中必须要有一些真正的牛人，这样才会吸引更多优秀人才；久而久之，团队水平越来越高，也会吸引到能力水平远超现有团队的「大牛」，毕竟「大牛」也是喜欢与优秀的技术人才群体一起工作的。
+
+### 2.成长路径
+
+「牛人环境」之外，每位技术人才的「成长路径」也非常重要。每个人在职业路径的关键节点上，大都会迷茫，不知道自己应该怎么往下走。这时，清晰可执行的「成长路径」就显得非常重要了。有了清晰的路径，技术人才们就可以时刻对照现状，及时发现问题并改正，然后根据现实情况实时调整。
+
+因此，为了吸引优秀的技术人才，我们必须结合每位人才的成长诉求和现状，为其量身定做成长路径，并提供相应的条件使其快速成长。在每一位技术人才成长的路径中，「牛人」又会起到非常关键的指导和帮助作用，结合「成长路径」的 mentor 制度，为每位技术人才在团队内匹配可以长期指导其工作的 mentor，会起到事半功倍的作用。
+
+在我的成长过程中，在豌豆荚非常幸运地遇到了一位大牛老师——邓草原老师；当时我每周都会有跟邓老师的固定聊天时间，主题不定，聊聊技术，聊聊人生，或者聊聊天下大事，每次聊天都是收获良多，既开阔视野，也使得自己更加自信。
+
+### 3.技术氛围
+
+好环境和成长路径之外，另一个关键因素是「技术氛围」。团队有没有好的技术氛围，有没有好的技术导师及时解答每一个人的问题，有没有高水平的技术分享使大家可以有更多沉淀和学习，是非常重要的。无论业务压力多大，技术氛围的打造都不能松懈。打造良好的技术氛围，并适时向行业输出成熟技术方案，提升技术影响力，是每个公司都必不可少的工作。
+
+在打造「技术氛围」的过程中，有两点需要避免。
+
+- 一为闭门造车，仅停留在团队内部技术分享的阶段，虽然有助于技术沉淀和锻炼口才，但很容易坐井观天。好的技术氛围，应该是开放式的，既有团队内部的技术沉淀式分享，也有同其他公司团队的交流分享，更要经常邀请行业大牛来进行高水平分享和讨论。
+- 二为脱离业务，技术是为业务服务的，最忌「为了技术而技术」，在保持技术敏感性的前提下，除了聚焦于团队目前的技术方向构建技术氛围外，也需要适当扩大技术领域的外延，为将来的业务工作进行准备。
+
+好环境、成长路径、技术氛围都是技术人才获得成长的支撑条件，但更重要的是「实战」，必须有足够高难度的目标来挑战，他们才可以在实战的过程中不断提升自己。在设定技术人才的目标时，一个建议的原则是「一定要蹦起来才可以够到」，人的潜力永远都比自己想象的大，不给自己挑战，又如何能成长呢？
+
+在对实战结果进行考核时，需要考虑好技术和业务的平衡。所有的技术人才，首要的是要完成业务目标，然后在这个前提下考核其技术方案的优劣和技术水平的高低。技术人才的考核是一个较大的话题，在此仅给出两个建议：
+
+1. 分别考核业务目标完成情况，和业务过程中技术水平的提升情况；
+1. 技术水平提升的前提是，业务目标必须达成，否则技术水平提升无从谈起。
+
+## 「成就感」痛点
+
+成就感对于每个人都必不可少，没有成就感的工作，是无法吸引任何人的，优秀的技术人才更是如此。
+
+### 成就感之一为「业务增长成就感」
+
+技术人才虽然从事的是研发相关的工作，但最终目标是为了服务产品、服务业务。只有他们的贡献真正对业务增长提供了支撑甚至决定性的作用，他们工作的价值才会真正体现，个人的满足感和成就感才会足够强。这一点，即使是在纯技术部门也是如此，如果跟业务没有关系，个人很难收获真正的成就感。
+
+为了达到「业务增长成就感」，每位技术人员都需要是业务人员，从属于具体的业务团队，扛具体可衡量的业务目标。在这个前提下，利用「牛人环境」、「成长路径」和「技术氛围」确保每位技术人才能够在业务发展的同时取得技术上的成长。
+
+有朋友可能会认为，这样容易造成不同业务团队重复造车等各种研发资源浪费问题，这是明显的只见树木不见森林的看法。一方面，重复造车的问题可以利用日常的技术手段（比如技术方案评审、Code Review等）加以避免和控制；另一方面，很多好的技术方案往往是经过了很多次「重复」/「重构」才真正形成的，适当的「重复造车」会形成技术团队间的良性竞争，反而益处更大。事实上，这种方式可以类比为「市场经济」的方式，通过适当的「调控」，可以最大化个体的积极性，最大化生产力的发展。
+
+### 成就感之二为「技术提升成就感」
+
+在贡献业务增长的同时，技术人才的技术得到了磨练，技术能力得到了提升，有了更多的积累和沉淀。这时，公司应该及时通过技术职级晋升的方式对他们的提升进行肯定，并提供高质量的技术分享机会，帮助优秀人才打造自己的行业技术影响力。
+
+技术职级晋升是一件非常神圣的事情，最忌讳领导制定等暗箱操作方式，必须确保标准明确、过程透明、结果公正，在合理设计技术职级体系的前提下，通过精心设计职级晋升的评审过程，确保相关信息对所有参与人均保持及时和透明，并利用机制确保最终的投票过程可以消除少数人的偏见，最大程度确保结果的公平和公正。对于处在业务快速发展阶段的公司，技术职级晋升以半年为周期为宜。
+
+在打造行业技术影响力方面，公司应该积极提供各种支持，并对核心技术人才提出特殊要求和支持；在实操过程中，需要摒弃「他/她在行业中出名了会被别家挖走」的不自信想法，真心实意地帮助技术人才构建行业影响力，这样公司的技术影响力才会水涨船高，才会吸引更多的技术人才。
+
+### 成就感之三为「现实收益成就感」
+
+多劳多得，能力越强得到的也应该越多。现实收益，不仅仅局限于现金以及股票等现金等价物，也包括更好的学习机会（比如参加Google I/O等世界一流的技术会议等）、更好的发展机会（更重要的职位等）和更高的目标及背后更高的现实收益等。
+
+在现实收益的设计上，一定要明确对技术人才能力水平的期望，并设计相应的现实收益水平。例如，如果期望技术团队平均技术水平超过行业中75%的人，那薪酬/股票体系的设计需要确保在行业75分位以上；对于团队急需且非常合拍的「牛人」，则要不惜代价，以最大的诚意和现实收益来吸引其加入。与现实收益平行，更好的学习和发展机会也会是非常重要的因素，可以同现实收益打包形成有竞争力的人才吸引手段。
+
+## 下篇预告
+
+在解决了「目标用户画像」和「目标用户痛点」两个关键问题后，我会在接下来的两篇文章中详细分析吸引技术人才的 AARRR 模型每个阶段的主要目标和策略，以及一些对应的实操型建议，敬请期待。
+
+最后给你留一个思考题：在你的公司中，经常出现「不同团队重复造车」的情况吗，这些情况真的都是不好的吗？
+
+## 作者简介
+
+姚从磊，百炼智能联合创始人兼CTO，致力于利用深度自然语言处理技术，将无结构的公开互联网信息结构化，构建以商业机构和商业人物为核心的知识图谱，服务于各种商业场景。2008年博士毕业于北京大学计算机系“天网”实验室，师从李晓明教授。毕业后，先后在惠普中国研究院、腾讯负责文本挖掘和搜索引擎相关技术和产品研发。2012年加入豌豆荚先后负责技术团队和搜索、营收等业务，主导建设的技术团队成为当时国内最有吸引力和竞争力的团队。2016年加入Kika任CTO，负责AI技术团队打造、输入法AI引擎、语音识别等业务，大幅提升 Kika 的技术实力。
+
+

极客时间专栏/geek/技术领导力实战笔记/第104讲 | 姚从磊：巧用 AARRR 模型，吸引优秀技术人才（三）.md

@@ -0,0 +1,107 @@
+<audio id="audio" title="第104讲 | 姚从磊：巧用 AARRR 模型，吸引优秀技术人才（三）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/39/24/39b137b318a321dbc3f24dd9518e3424.mp3"></audio>
+
+你好，我是百炼智能联合创始人兼CTO姚从磊，之前的两篇文章中，我与你分享了吸引优秀技术人才的 AARRR 模型，并探讨了执行这一模型的前提，即弄清楚“目标用户画像”和“目标用户痛点”这两个关键问题，也就是“公司需要什么样的优秀技术人才”以及“这些优秀技术人才需要什么”。
+
+在本篇文章中，我会结合吸引优秀技术人才的 AARRR 模型（图1所示），来详细分析 Acquisition 和 Activiation 阶段的主要策略，并提出一些实操性建议。<br>
+<img src="https://static001.geekbang.org/resource/image/0c/46/0cd9e61c6dbd6cce96bedafc7f212546.png" alt=""><br>
+图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 的技术实力。
+
+

极客时间专栏/geek/技术领导力实战笔记/第105讲 | 姚从磊：巧用 AARRR 模型，吸引优秀技术人才（四）.md

@@ -0,0 +1,91 @@
+<audio id="audio" title="第105讲 | 姚从磊：巧用 AARRR 模型，吸引优秀技术人才（四）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/49/ff/49525f72f4392ad37653767127dc4fff.mp3"></audio>
+
+你好，我是百炼智能联合创始人兼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 的技术实力。
+
+

极客时间专栏/geek/技术领导力实战笔记/第106讲 | 程军：技术人的「知行合一」（一）.md

@@ -0,0 +1,101 @@
+<audio id="audio" title="第106讲 | 程军：技术人的「知行合一」（一）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/79/4b/79153a154723f5239e11f5cdfb7b204b.mp3"></audio>
+
+我是一个特别喜欢思考的人，凡事都喜欢问为什么，年近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，这样的过程才可以认知升级、自我升级、团队升级。
+
+## 三、认知升级的撬动工具——知行合一
+
+说了这么多，大家可能还是有些疑惑，我在这里补充几个前人或伟人的理论精华，便于大家理解：<br>
+1.《易传》中孔子所写的“一阴一阳谓之道”。<br>
+2.王阳明的“知行合一”理论。<br>
+3.曾国藩的“凡成大事，以识为主，以才为辅；人谋居半，天意居半”。<br>
+4. 建国初期，周总理在外交上提倡的“求同存异”策略。<br>
+5.习主席提出的“一带一路”方针。
+
+不难发现，这些理论都是由两个层面的内容构成的，如阴阳、知行、识才、存异、带路等。这个世界上，很多东西都是成双成对、都是辩证且统一的，两者之间存在一个协同或撬动的工具，并且这个工具在不同时期、不同场景中都会有所不同。关于如何更好的培养协同的思维、找到协同的方式，这里想推荐一本书叫《第3选择》，感兴趣的可以去看看。
+
+再举一个一般大厂推广微服务中间件例子：<br>
+1、中间件部门刚成立，看到公司系统非常多且有一些问题，比如调用关系复杂，没人敢改动一些核心模块，排查问题困难且耗时多，还有经常会因为系统之间的耦合严重而导致需求上线时间一拖再拖等等。<br>
+2、业务部门则研究CRUD，系统业务订单量已经达到10w/天，每次发布都小心翼翼，流量大时想降级一些不关键业务的调用都会很麻烦，偶尔一些紧急需求又不能按需发布，一发布调用系统都会受影响，苦不堪言。
+
+这时，如果你是这款的中间件的owner，你会怎么办？
+
+我们先对结果进行可能性分析：
+
+<img src="https://static001.geekbang.org/resource/image/ee/ad/ee448f5db11c546d2ff56277eff0cead.jpg" alt=""><br>
+从概率上说，双赢的概率是25%，但在我们的认知中，会觉得这事压根就是不可能的。之所以会有这样根深蒂固的认知，是因为我们从小就被灌输了好坏、美丑、正义邪恶、贫穷富有等对立的概念，而这些对立的概念禁锢了我们的思想。
+
+我的破解方法是双方坐下来敞开心扉移情沟通，相互了解中间件部门和业务部门对于这件事赢的标准，运用协同、知行合一等理论，重新定义新的双赢标准并通过协作去执行。
+
+这样，结果是一定业务交付速度更快，排查问题更快，而且中间件团队会感觉自己的工作有价值并认可，这才是协同产生的1+1&gt;2的结果，持续践行下去甚至等于100的好结果。从根本上说，这是一种新的思维模式，能让我们找到解决所有难题的新思维、新办法。
+
+回顾人这一生，其实就是一场修行，悟道的过程是非常痛苦，但也非常开心的。因为阶段性的胜利是值得开心的，但踏上下一个旅程又会面临新的痛苦。我们要做的就是保持一个好身体，一个乐观、积极的心态，选择好每一个人生十字路口并坚持走好我们选择的路。
+
+另外，强调一下每个人的认知都会有一个提升的过程，不同的阶段，对问题的看法会变、做事的方式也会变。由于认知层级不同和信息不对称等因素，事事无绝对，请用你的左脑理性管理自己的行为，用右脑感性领导你的思维。坚持正确的原则，以终为始坚持自己的个人愿景，用知行合一这个抓手、用螺旋式上升的方式去撬动自己的未来，打开一片属于每个技术人的新世界。
+
+<img src="https://static001.geekbang.org/resource/image/64/32/641205a5fee24fa9b297006354a77932.jpg" alt="">
+
+我点上一只黄鹤楼，一直践行在路上。
+
+## 作者简介
+
+程军，现任贝壳技术总监，曾任饿了么技术总监、1号店架构师，10年以上互联网开发经验，8年以上技术管理经验。
+
+

极客时间专栏/geek/技术领导力实战笔记/第107讲 | 刘俊强：消除压力的七种方法.md

@@ -0,0 +1,89 @@
+<audio id="audio" title="第107讲 | 刘俊强：消除压力的七种方法" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/7d/f0/7df4824a1c3846599869be4652847cf0.mp3"></audio>
+
+你好，我是腾讯云资深架构师、TGO鲲鹏会会员刘俊强，有着8年以上的技术管理经验，今天想跟你分享技术管理者在工作中如何面对压力并进行有效的缓解。
+
+压力在工作和日常生活中是不可避免的，有些人能够在高压情况下保持冷静，并很好地完成事情，但同时有些人的抗压能力要弱些，不能够很好的应对压力所带来的影响，所以学会消除压力便至关重要。
+
+我这里所说的压力，包括两个方面，一个是受环境或项目进度等情况影响，自身对于现状或未来有所恐惧或担忧的心理状态，即技术管理者自身面对的压力；另外一种是技术管理者的管理风格或方法，对于团队成员所造成的压力，即施压型管理者。
+
+首先，我们要避免成为“施压型管理者”。试想一下，你的主管把每件事情都变成一种压力，让人在恐惧和压力中完成任务或做决策，让团队成员的神经总处于紧绷状态，这样的工作氛围是极为不健康的。
+
+那么你自己是不是这样的管理者呢？通过不断的批评或威胁等工具，来刺激团队完成目标，短期内可能会取得一些效果，但是我们看长远些，这种管理方法所造成的工作氛围，会让团队成员仅关注于你所关注的事务上，会追求最为安全和简单的业绩输出方式，不会敢于创新承担更多责任。在这里，我希望大家不要成为这样的管理者，因为这类管理者是在消耗自己的信用，是不可持续的。
+
+那为何有些管理者会成为“施压型管理者”呢？主要原因在于，作为管理者所面对的压力，如项目进度、团队成长等事务都在挑战管理者的舒适区，身处舒适区外，会让人紧张、害怕或不知所措，从而感受到压力。当他们不能够很好地消除处理掉这些压力时，就很容易让自我的行为产生偏颇，变成“施压型管理者”，而要避免这种情况，就一定要简单快速地解决当前让自己感到不舒适的压力状况。
+
+接下来，我将介绍七种消除压力的方法，来帮助技术管理者让自己和团队在压力状况下，还能够舒适地进行工作和生活。这七种方法分别是：
+
+制定计划<br>
+反复练习<br>
+避免工作中用光能量<br>
+不要拖延<br>
+不要多任务<br>
+学会委派工作<br>
+充足的睡眠
+
+## 方法一：制定计划
+
+面对需要在限定时间内完成的工作，我们让自己无压力完成的方法便是制定计划。当然，对于没有明显规定时间的工作，我也建议采用分阶段、分里程碑的方式来制定计划，以便我们逐步完成事项来达成目标。
+
+为何制定计划对于消除压力这么重要呢？完成一个项目或是一项具体工作时，会给我们带来压力的地方，很多时候来自于对突发状况和日后未知情况的担忧和恐惧，因此，我们通过制定计划，确定每个阶段需要哪些资源和预估时间。
+
+当然，这里我们需要留下些富余时间，因为执行过程中很有可能犯错，因此留下点犯错的余地，能让我们的计划更有灵活性，当状况真的来临时也能够应对自如。如果我们没有在计划中建立灵活性，这样的计划反倒只会增加压力，另外，我们的计划在工作强度上也要保持合理并尽量一致，这样的计划才能够帮助自己和团队舒适地完成目标。
+
+## 方法二：反复练习
+
+对于技术管理者而言，咱们的压力也可能会来自于产品介绍、技术演讲以及团队动员会等非技术领域的事务。而这些事务带来的压力，往往来自于环境，如地点、时间、竞争对手以及观众等，因为环境的变化会让我们分心，感到不舒适与压力，进而影响我们的表现。
+
+消除这类事务压力的方法便是反复练习，我们准备好内容之后，需要对呈现内容的环境进行了解和熟悉，例如空间大小、观众人数、时间长度等。如果条件允许，我建议可以在最终场地进行排演练习；如果条件不允许，则可以事先思考补充场地的细节，并在自己的计划中预留一点时间进行场地环境的熟悉，让自己更胸有成竹地完成。
+
+## 方法三：避免工作中用光能量
+
+需要注意的是，一个人的身体和精力是有上限的，不要让自己和团队在工作中用光能量进而产生倦怠。面对压力时不要屈服于压力，这会让我们产生职业倦怠，变得疲惫与情绪化。一直处于高压情况下工作，很容易让人感觉自己对工作没有什么控制权，或者工作输出没有被认可。
+
+当你审视自己或你的团队时，问问自己是否已经看到任何接近倦怠的迹象，如工作量和压力是否过大，团队成员是否看起来很疲惫，抑或是团队中的拖延和抱怨是否在增加。我们需要保持自己和团队的持续战斗力，而不是一次战役便压榨光大家的精力。
+
+如何面对压力并避免倦怠状况的产生呢？
+
+首先，保持跟团队成员的沟通，了解他们的工作状态和感受，需要形成定期沟通的模式来了解团队状态。
+
+接下来，如果压力过大产生了倦怠前兆，可以尝试放慢下速度，重新考虑团队追求的整体目标以及项目目标。
+
+最后，请务必提供团队所需的支持和资源，通过快速会议、消息群组以及电子邮件等方式来分享好消息，并鼓励团队让他们知道自己所做工作很重要，并给予对应的资源支持，同时也可以通过团队聚餐或其他放松活动来提升团队效率。
+
+## 方法四：不要拖延
+
+我们处理事情的时候，往往会先处理简单或是看起来不那么难的事情。对于那些明显重要但看起来麻烦的事情，我们可能会选择拖啊拖，拖到之后再做，其实我们有部分的压力便来自于这样的情况，因为这些困难或糟心的事情不会因为我们拖延而消失，而是会不断占领我们的心智，不能释怀，反而让人感到焦虑和压力。所以，不要拖延任何事情，把待办事项上的事情拿出来做吧。
+
+## 方法五：不要多任务
+
+让我们工作舒适的重要的一点便是不要多任务处理事情，不要试图一次做几件事情，我们可以将事情写在待办事项列表中，然后一次完成一个。人类思维并不是为多任务而设计的，不同事情间的切换会让我们的大脑感受到压力，让我们表现得更差。另外，事务中断一会儿后再回过头来接着做时，需要寻找上下文回顾之前的进度，这样效率会变差，进而情绪化毛躁起来。因此不要多任务，弄个清单可好？
+
+## 方法六：学会委派工作
+
+作为技术管理者，可能会有诱惑让你去做尽可能多的事情，虽然这样会让你工作丰富，并且感觉到有更多的控制权，但工作事务是做不完的，不断涌来的事务会让你倍感压力。更为关键的一点是，这样做对你的团队成员并没有多大帮助，你需要用你的知识、技能和方式去带领团队成功，而并不是要当一个全能的超级英雄。
+
+你需要评估自己的工作内容，有些临时或不紧急的事务，需要考虑交给团队成员，甚至实习生来处理，你要做的是给予他们完成事情的必要帮助。
+
+有时项目进度会有所延迟，这样的压力来临时，并不是要求你完全顶上去亲自将其处理掉，而是要跟团队沟通清楚目前的进度状况，跟团队一起来面对这些压力，有可能需要重新调整计划、也有可能可以很快速地处理掉影响进度的问题，最重要的是，你要学会将事情委派给对应的人员，并帮助他们成功完成任务。
+
+## 方法七：充足的睡眠
+
+充足的睡眠对于消除压力至关重要，可能有些人心比较重，一旦有压力或者担忧的事情就会一直想着，让自己的睡眠时间和质量都受到影响。事情终究会解决，会被处理掉，如果不能保持充足的睡眠，就不能保持良好的身体状态，反倒更容易感受到压力，无法很好的处理遇到的难事，因此，保证充足的睡眠非常关键。
+
+现在我们有太多的诱惑，视频节目、游戏以及即时聊天等，这些都会影响我们的睡眠，我这里有个非常古典但行之有效的方法可以帮助入睡，那就是看书，可以阅读跟自己工作内容相关书籍，比如管理类书籍，很快就能够让自己入睡，当然小说之类的书籍坚决不要在睡前阅读。
+
+## 总结
+
+本文我和大家聊了聊技术管理者面对压力的处理方式，我们一定要注意处理好压力，不要让自己成为“施压型管理者”，也希望大家在之后面对压力时能做得越来越好。
+
+## 思考题
+
+想想自己最近的行为，是不是属于“施压型管理者”呢？
+
+感谢你的收听，我们下期再见！
+
+## 作者简介
+
+刘俊强（微信公众号：程序员精进）现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+年以上互联网开发经验，8年以上技术管理经验。
+
+

极客时间专栏/geek/技术领导力实战笔记/第108讲 | 谢呈：技术高手转身创业的坑和坡.md

@@ -0,0 +1,120 @@
+<audio id="audio" title="第108讲 | 谢呈：技术高手转身创业的坑和坡" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/78/1a/786a7f6afe192334cb1491703e5e871a.mp3"></audio>
+
+你好，我是木仓科技副总裁谢呈，我是技术人转型创业的一个典型例子。我从高一开始写代码，一直写到春雨医生早期，在春雨医生的6年时间内，我从技术转型，开始负责产品与业务。目前，我在另一家互联网创业公司木仓科技负责驾培业务线。
+
+今天，我将结合自己创业的亲身体会与经验，和你分享一些创业中的坡和坑。坑，是创业中难以避开的挑战；坡，是创业中迎难而上，实现目标的路径。
+
+## 前言
+
+我主要从三个方面讲创业，即找方向、找人、找钱。
+
+有了创业想法，第一步应该做什么？很多人脱口而出“找人、找钱、找方向”。其实，正确的顺序应该是先找方向，然后找人才，最后才是找资金。
+
+原因很简单，在互联网以及移动互联网如此成熟的阶段，此时创业，如果你连方向都不能确定，你想获取人才与资金可谓难上加难。
+
+创业方向不同，需要的人才也不同，也许你做2C公司或是2B公司，也许你投身医疗行业或进军金融行业，专业的事情需要交给专业的人去做，所以，没有明确的方向，团队组建时就会乱了阵脚。
+
+我将找资金放于末位，其实是标准路径，具体还需要分情况而论。有些人刚有创业想法就可以拿到钱，而对于多数创业者，根本没有这样的机遇。所以，在大多数情况下，我们换个角度想，如果你是VC，你会选择投资一个方向明确、已有团队的创业公司，还是选择一个只有创业想法的技术高手？
+
+答案当然是前者。
+
+这就是方向第一，人才第二，资金末位的排序原因。
+
+考虑到多数人目前只有创业的想法，还没有真正投身实践，所以，接下来我会着重讲讲找方向，以及在创业前期需要注意的事项。
+
+## 找方向
+
+创业方向非常重要，但放在实际情况中，找方向中的“找”代表验证。即验证方向。
+
+从结果来看，多数知名的创业公司或成功的创业公司，往往不是在有一个创业冲动之后去找方向，而是已经有了明确的方向，再通过各种方法验证方向。
+
+对于初次创业者，要判断是创业想法还是创业冲动的标准就是，创业方向是否足够明确，是否已经进行了验证，对此方向是否足够笃定。如果你没有明确而笃定且可落地的方向，往往代表这不是一个成熟或容易成功的创业模式。
+
+不过，虽然有明确的创业方向是最好的选择，但是，对于技术人，尤其对于目前还未辞职创业的技术人而言，前期当然可以找方向，不断对方向进行调研与验证。
+
+很多想转身创业的技术人，可能都会有这样的困惑，就是在移动互联网已经非常成熟，BAT三足鼎立的情况下，创业是更容易了还是更难了？
+
+对于这个问题，我的答案是难易程度取决于创业方向的选择。
+
+### 小方向找机会：make money，看重商业模式
+
+很多人认为创业更难的原因是，BAT不仅有吸引人才的能力，有充足的资金，有丰富的经验，还熟知互联网战场。相比之下，创业公司好像毫无优势。
+
+其实不然，创业公司至少有两点优势。
+
+第一，正因为BAT强大，为我们斩掉了创业路上的许多荆棘，很多基础工作，都不需要我们再去做。比如，对于移动互联网的普及以及让用户习惯移动支付。
+
+在此，以木仓科技的产品——驾考宝典App为例，这个产品的模式很清晰，就是两点：<br>
+1.一个优秀的学车考驾照软件。现在考驾照的用户绝大部分都用驾考宝典，用户量可想而知。考驾照的周期即用户使用产品的时间周期，一般几个月到1年不等，时间并不短，所以用户流量也很可观 。<br>
+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，你觉得可行吗？<br>
+在我看来，这个想法不可行。其实将企业卖给另一个企业，是非常正常的退出渠道，但是，2BAT的成功离不开需求分析，要抓住BAT的需求。
+
+比如几年前的滴滴、快滴，它抓住了BAT需要移动支付的需求，而且，只有做到业内领先地位，才能够拿到BAT的资金。从目前实现2BAT的公司来看，无论是为了融资还是卖掉企业，它们之前都做得非常不错。
+
+其次，内部关系也能在必要时助你一臂之力。许多拿到BAT融资的公司，合伙人中往往有人与BAT有一定的渊源。所以，作为技术人，你有必要铺垫一些关系，这些关系在关键时刻往往能够帮助到你。
+
+就像一场比赛，谁都想拿到BAT的资金，甚至很多人为此降低自己的价格。在激烈的竞争中，你必须产品过硬，同时如果能够接触到BAT中的高层，那胜算的几率将大大提升，这点大家都懂，无需我多言。
+
+## 找人才
+
+对于找人才，我分享一点容易被技术人忽略的东西。
+
+很多人会问，我到底应该找一个跟我像的人还是不像的人？其实，这就像找结婚对象，一定要价值观相近，而最重要的一点是技能互补。
+
+比如我刚才在2B的例子中，谈到的那位技术朋友，就是因为他们缺少销售人才，导致再好的产品也遇到了销售困境。所以技能互补对于团队非常重要。
+
+而互补依托于人脉的积累，如果你有创业梦，或者想跳出技术领域，你需要积累来自各方面的人脉，比如产品、销售、运营等，他们都可能成为你未来的合伙人，
+
+虽然，找方向、找人才、找资金的顺序是所谓的标准路径，但还有一种情况是，当你去找你预想的合伙人谈团队时，可能他会说“你什么时候找到钱我才加入你”。这时，你就需要换一个人，一位看好你的方向并愿意跟你一起从零开始做事的人。
+
+## 找资金
+
+在找方向与找人方面，我提到很多需要注意的点，大多是创业者常见的坑，大家一定要避过，找资金反而没有多少大坑，这是一个坡。
+
+我问过不下十个创业的朋友，当时找资金的情况。回答很有意思，两极分化。
+
+一部分人说，根本不需要找，发个朋友圈，投资人就上门来找我。另一部分人表示找资金难，其中，联系过一百多家VC的初创者，也不在少数。
+
+因此，总结找资金的经验，方式不用非常花哨，当方向正确，产品过硬，团队扎实时，找钱自然不是一件难事。
+
+## 作者简介
+
+谢呈，木仓科技副总裁，前春雨医生副总裁及联合创始人，曾任网易有道移动事业部技术负责人。在多年的创业中，分析垂直行业发展、制定并调整战略方向、思考业务和商业模式，对创业和互联网+的模式有丰富经验、教训和独到的见解。
+
+

极客时间专栏/geek/技术领导力实战笔记/第109讲 | 谢呈：关于垂直互联网创业的一些经验之谈.md

@@ -0,0 +1,104 @@
+<audio id="audio" title="第109讲 | 谢呈：关于垂直互联网创业的一些经验之谈" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/fe/c2/febbbb68e80f7b061c7abe24869e54c2.mp3"></audio>
+
+你好，我是木仓科技副总裁谢呈，在《技术高手转身创业的坑和坡》一文中，我分享了技术人转身创业时，在找方向、找人、找钱上可能会遇到一些坑与坡。
+
+其实，我的创业经历中，先后做的春雨医生和木仓科技都属于移动互联网垂直领域的领先者，因此，接下来将分享一些我在垂直行业创业的经验与几点心得。
+
+## 找用户&amp;找专家
+
+当下，创业很难避开某个领域直接做纯互联网的商业模式，比如，做社交、游戏等，非常之难，实际做的往往是传统行业+互联网的模式，避不开的一个话题就是垂直领域。
+
+很多想在垂直领域创业的人会有这样的困扰：我不是业内人，创业的方向应该是找用户还是找专家？
+
+答案是都要找。
+
+以春雨医生为例，它垂直于医疗行业，是一个典型的垂直产品。当年决定做这款线上问诊平台时，我们也有这样的疑问，应该先找患者还是先找医生。而我们采用了笨办法，就是两边都找。
+
+我们与二十多个医生交谈，发现支持率并不高，同时，也找到近百名用户，结果获得超过50%的用户支持率。在医生看来问题很多，如线上问诊没有见面能否给出有效建议、资质是否合法、医疗纠纷怎么办等等，而用户只担心医生是否专业，但对于线上问诊的方便都很期待，毕竟去医院排队和挂号的体验实在是太差了。
+
+最终我们听从了大部分用户的建议，果断启动春雨医生项目，第一期的效果出乎意料。总结经验可得：
+
+1.什么时候该找用户？答案是当你想判断一个需求是否存在时，比如是否有线上问诊的需求。在垂直行业，必须始终以用户需求为出发点。<br>
+2.什么时候应该找专家？答案是当你想寻求一个更合适的解决方案时，比如，线上问诊如何解决误诊的问题，这时就应该找专家。
+
+## 把产品做出来
+
+当你已经有具体的创业想法，对需求也充分验证之后，就需要将想法落地，搭建团队，做出产品。虽然，做产品是技术人的强项，但我还是想从两个方面给出一点提醒，一是解决问题与发现问题的思路；二是团队配合问题。
+
+1.解决问题&amp;发现问题
+
+如果你决定创业，或期望做CEO、CTO、COO等合伙人级别的技术人员，你必须具备发现问题与解决问题的思维。
+
+最初，我从技术岗转到管理岗时，一个非常大的困惑就是时常感到不知所措，不知道问题在哪儿，其原因就在于思路不同。
+
+技术人员是非常优秀的解题高手，但在创业过程中，我们的思路要从代码中跳出来，去发现公司存在的问题，去解决这些开放性的问题。想法不能再局限于如何做好一个产品，而是要思考如何做好一个企业。
+
+我经常与一些技术转身创业的朋友聊天，以前我们总是会讨论彼此的产品，目光聚焦于小问题。后来，我们慢慢学会将思维扩大，讨论大局层面的问题，比如公司现阶段最大的瓶颈是什么？目前公司遇到的最大的风险是什么？甚至会讨论双方公司在人力方面遇到的问题。
+
+其实这样的思考方式就是从解决问题转化为发现问题，只有真正站在公司的角度，才能看到公司的问题所在，才能指引团队向正确的方向前进。
+
+2.团队配合
+
+一个高效团队必备的素质之一就是，尊重专业人士，寻找优势互补人员，恰好这点非常容易被技术团队忽视。
+
+举个例子，我有一位朋友做2B的OA系统，他们发现市面上的OA系统存在诸多问题，于是自己研发了一套新的OA系统，体验确实非常好。
+
+产品做出来后，几个技术人员带着产品展示PPT去目标公司谈合作，他们将竞品与自己的产品摆在客户面前，然后开始宣讲自己产品的四大特点、八大优势。结果，直到两周后也没有收到对方回信。
+
+他们百思不得其解，于是我引荐了一位销售朋友，帮助他们推动这个产品的销售。
+
+这位销售朋友非常懂得销售套路，首先他并不是去客户办公室推销产品，而是请对方负责人喝咖啡；其次，喝咖啡期间也没有展示产品PPT，更未提及产品的四大特点、八大优势，而是询问对方一些问题，比如，最近工作压力如何、目前在用的OA系统员工反馈如何等等。
+
+几天后，这位销售朋友将整理过的产品PPT拿给对方负责人，一通电话之后，促成了这次合作。
+
+这让几位技术人员很崩溃，百思不得其解。
+
+其实，这单之所以能成功拿下，是因为销售人员懂得为客户解决问题。这其中有两个关键点。
+
+第一点，对方负责人特别怕麻烦，当他第一次看完产品PPT后，认为虽然现在用的OA系统存在诸多问题，但也能够使用，为什么要换？而换系统后，随着功能增多，会不会面临更多的麻烦？
+
+这一点在技术人宣讲产品时，完全没有想到，更没有告诉对方，其实他们可以做非常简单的云端或者直接部署功能，无需对方过多操心，而对方所担心的问题都能被完美解决。
+
+第二点，对方负责人在喝咖啡时透露，新的OA系统确实有许多优势，但这毕竟不是老板指派的任务，他的困扰是如何向老板汇报。
+
+于是这位销售朋友将产品的四大特点、八大优势整合，做成了一页PPT，并且告诉对方，这套产品几个知名的互联网公司都在用。如此一来，就解决了对方负责人的担忧。既然这套产品有这么多优势，还有知名公司在用，老板一定能认可。
+
+通过这个例子我们能够看到，不论搭建团队还是工作配合，要牢记尊重专业人士，寻找优势互补成员。
+
+## 迭代之前先验证需求
+
+无论是做软件还是互联网产品，上线之后肯定要进行不断迭代。在此，我想提醒的是，迭代是必须的，但也是有坑的。
+
+迭代最大的坑就是没有需求。
+
+可能你会问，我有明确的方向，有团队，也获得了融资，产品也不是没有人用，怎么会没有需求。
+
+此处的没有需求，其实指的是没有理解用户的深层需求。
+
+我还是举个例子，减肥是女生的需求吗？肯定不是。我从两方面解释原因：
+
+第一，为什么女生天天喊着减肥？因为瘦下来好看，容易搭配衣服。那么问题来了，减肥与好看相比，哪点是女生的需求？答案一定是好看。所以，好看才是减肥的深层次需求，如果你要做一款减肥产品，你对于需求层次的理解，将影响减肥产品的成败。
+
+第二，按照这样的逻辑往下思考，正因为这个时代以瘦为美，所以得出减肥是需求，而方法也很简单，就是少吃多运动，那么，为什么女生总是解决不了这种需求？
+
+春雨医生曾根据专家建议做过30天瘦6斤的健康减肥计划，但是反响并不理想，因为我们发现，减肥并不是需求，不节食不运动的减肥才是需求。
+
+所以，一定要了解用户的深层需求，才能真正为用户解决问题。另外，在发现用户问题的过程中，一定要验证需求。
+
+对于验证标准，我认为，只要有一个指标让你觉得兴奋，就能称之为标准。
+
+以春雨医生真正满足线上问诊为例，最初，我们对这一需求并没有把握，所以，只找了两位医生做兼职工作，要求每人每天回答一百个问题。结果，上线第一天就涌现出300个问题，两位兼职医生根本无法在短时间内答完所有问题。我们当时的方法是限号，比如上午只放出200个号，结果到10点、11点就没号了。到了下午，用户就反馈意见甚至打来电话，表示产品体验太差，根本不能咨询问题。
+
+之后我们开始分批限号，依旧在每个时间段的前二十分钟左右就没号了。最后，我们迅速扩量，同时与大量专业医生合作，在两个月内将产品变为平台模式，整个产品就起来了。无论你做多少，有一个兴奋点就够了。
+
+## 拥抱不确定性
+
+最后想说的是，创业非常辛苦，创业者聚在一起时，彼此都会有种英雄惺惺相惜的感觉。在创业过程中，总会出现各种不确定因素，比如，你的产品非常有潜力，结果BAT也开始做了；再比如，你的团队刚稳固，结果合伙人有新的创业想法，想退出团队等等。所以，面对各种不确定性，要做好心理准备，去拥抱它，与不确定性同行。
+
+另外，要多学习，多实践，多跟人交流、早接触尝试。实践并不只有辞职创业一条路，在创业之前，你可以多做一些功课，包括参加技术大会，与已经创业的同事交流经验，与非技术创业者交流经验，利用互联网做开源项目等。通过这样的实践，获取知识、沉淀经验，当你有了知识积累与技能储备再去创业，一定会事半功倍。
+
+## 作者简介
+
+谢呈，木仓科技副总裁，前春雨医生副总裁及联合创始人，曾任网易有道移动事业部技术负责人。在多年的创业中，分析垂直行业发展、制定并调整战略方向、思考业务和商业模式，对创业和互联网+的模式有丰富经验、教训和独到的见解。<br>
+&nbsp;<br>
+

极客时间专栏/geek/技术领导力实战笔记/第10讲 | 创业公司CTO的认知升级.md

@@ -0,0 +1,63 @@
+<audio id="audio" title="第10讲 | 创业公司CTO的认知升级" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b3/3c/b3bcd2d30a7ca1759bcd6ea0b02aad3c.mp3"></audio>
+
+在不同的行业中，以及不同公司在不同阶段，对CTO的要求是非常不一样的。同时任何一个时期，对CTO的能力要求其实都是综合的。
+
+我所在的公司是一家创业公司，我是公司的联合创始人和CTO。我想结合我在公司不同阶段的经历，谈谈我对CTO这个岗位的认识。
+
+## 公司初创期
+
+大多数互联网创业公司，一开始都是从几个人开始干起，我们也不例外。这个阶段最重要的是如何快速开发，快速试错，通过试错不断验证自己的idea是否靠谱。而对于技术架构是否可扩展、研发流程是否规范、绩效考核等则不会过多考虑。
+
+记得我们在开始第一个产品的时候，直接写JSP页面，不需要前后端分离（因为我们也没有专职的前端），数据库则用了Schema free的文档数据库MongoDB，无它，就是追求最快迭代开发速度。
+
+这个阶段的公司，应该建立怎样的认知呢？首先是创业越早期风险越高，其次是低成本试错。那么作为CTO或者技术负责人，你的决策也需要匹配公司当前的状态。<br />
+  <br />
+比如招人方面，从匹配性上看，如果候选人没有创业心态，过于追求安稳，就可以pass掉；从技术画像上看，一个全栈工程师会比一个技术专家更能帮助到团队。<br />
+  <br />
+比如技术选型方面，不要犯杀鸡用牛刀的错误。尽量选择轻量级的框架，考虑最大化团队的开发效率为核心。在产品还未被被验证之前，过于超前的为大规模用户使用、超高并发和海量数据访问投入设计，很可能最终只能沦为摆设。因为产品的死亡率极高，方向也随时可能发生变化。
+
+网上流传着腾讯的QQ服务端架构从建立初期一直沿用到现在的说法，腾讯的CTO 张志东在一次内部培训中被问及此事时，很坦诚地说，其实QQ的架构一直在不停的改造和优化，到目前为止已经做了4~5次的调整。当初创业时候的规划是：第一年同时在线人数到达1K，第二年2K，第三年4K，第四年8K，第五年就可以上万了，而实际上第五年的时候腾讯已经做到了500万的同时在线数，目前QQ支持的最大的同时在线人数已经超过上亿。张志东说，如果1998年创业初期，就让他做到支持500万的同时在线人数，可能就不敢创业了。
+
+## 高速发展期
+
+一旦你的产品通过了用户和市场验证，公司可能会进入了新的发展阶段，这时候你才有机会接受进一步的考验。随时用户和业务的增长，产品需求可能越来越多，公司对产品的迭代要求更高，老的技术架构已经不能适应新的业务迭代，同时管理层也越来越关注产品的稳定性对客户的影响，你的团队人员在不断的膨胀，而你还没有准备好绩效管理，也还不知道如何去淘汰不合适的员工……
+
+开始接近自己的创业梦，发现梦想并不是想象中那么美。在公司的高速发展期，问题产生的速度远比你想象中快。这个阶段的CTO应该建立怎样的认知呢？
+
+我总结有三点方面的思考非常关键：<br />
+  <br />
+第一，抓大放小，区分主次。分析清楚当前主要矛盾和次要矛盾，重点解决主要矛盾。把当前的问题、内外部需求、公司的规划进行梳理对比，找出核心问题，重点投入。<br />
+  <br />
+在我们公司发展历程中，曾经遇到一些问题。首先是团队效率，在人员膨胀的情况下，如何保证做到小团队作战的人效。亚马逊的CEO杰夫·贝索斯有个“两个披萨原则”，如果两个披萨不足以喂饱一个项目团队，那么这个团队可能就显得太大了，沟通协作的效率很容易下降。把团队按业务或职能切分，可能是更好的方案。如果你的团队人员扩充上去了，生产力并没有跟上，那么是时候考虑团队规模是否太大的问题。
+
+如何平衡各种需求？在我们公司的发展历程中，早期产品稳定性是我们的核心问题，当时我们内部同事也会反馈说竞品有这个功能那个功能，而且网站上页面看起来比我们舒服多了，这些需求我们能不能做？记住，资源永远是有限的，次要的功能不做不会影响用户的核心流程，页面长得不好看也不影响用户的使用。但如果产品不稳定，那客户是要跳起来的，所以我们早期研发的重心之一是做稳定性优化。<br />
+   <br />
+第二，追根溯源，从源头解决问题。特斯拉的CEO埃隆·马斯克倍受推崇的“第一性原理”思维，就是强调在基本事实的基础上探究问题的本源，不被过去的经验知识所干扰。在高速增长期，我们也会遇到各种各样的问题，从根源上解决问题才不至于反复的疲于应付。
+
+比如面对产品的故障，是每次修复完就忙于下一个需求，还是重视复盘总结问题根源？这一点《SRE Google 运维解密》这本书提到的“事后总结制度”做得非常到位，除了追溯问题本质原因外，还建立了良好的总结文化，会收集事后总结内部分享，开放评论，对于良好的事后总结和事故处理还会做公开的奖励，甚至可以得到高层的点赞。<br />
+  <br />
+再比如技术债，技术债累积越多，后期的研发效率、问题隐患越多、维护成本越高，适时的解决技术债问题，是从长远考虑非常有价值的投入。<br />
+  <br />
+第三，充分放权，有效监督。早期小团队作战，也许还能靠几个尖兵一招鲜，快速占领先机；中后期拉开战场了，必须要依赖团队作战，依靠制度管理。<br />
+  <br />
+首先，早期成长起来的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鲲鹏会杭州分会会籍委员&amp;服务委员。2010 年加入淘宝，参与淘宝搜索技术的改造与优化、淘宝去 IOE 等项目。2012 年创业， 负责技术团队搭建和管理、核心产品研发和运维保障。从为淘宝商家提供 CRM 服务的维客软件，到为企业提供短信、语音、流量等服务的云片云通讯平台，对高可用、高并发系统架构设计有丰富的实践经验，对于云通讯技术和稳定性实践有深厚积累和独到见解。

极客时间专栏/geek/技术领导力实战笔记/第110讲 | 成敏：创业公司为什么会技术文化产品缺失.md

@@ -0,0 +1,68 @@
+<audio id="audio" title="第110讲 | 成敏：创业公司为什么会技术文化产品缺失" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/9e/6d/9e99fb2adfb5565e7102c1281cde5b6d.mp3"></audio>
+
+你好，我是技术领导力300讲主编成敏，最近经常参加一些技术创业者的交流活动，听他们聊创业过程中遇到的问题、踩过的坑。
+
+其中一个很有意思的话题是，不少创业公司的产品技术人员会觉得公司没有产品技术文化，或者市场驱动的文化盖过了产品技术文化。
+
+对此，他们其实也很委屈，每个技术创业者在创业之前都是充满理想的，都会想要打造一个技术驱动、产品驱动、模式驱动的公司，但创业的压力实在是太大了。
+
+几乎所有的创业公司从成立的第一天开始就会面临巨大的生存压力，包括基本生存压力、投资者压力和激烈的市场竞争这三重压力。
+
+**1.基本的生存压力**<br>
+很多创业公司的起始资金都是创始人自己之前积累的血汗钱，我跟很多创业者聊过，只有很少一部分人一有创业想法就能拿到VC的钱，大部分还是拿着自己的钱来创业，甚至有卖房创业，把自己全部家底投进去的。
+
+所以，对创业者而言，公司从诞生之初就面临着非常大的压力，每天一睁眼，就是几千、几万甚至几十万的支出，账上的钱一直在减少，但收入却迟迟没有看到曙光。这时，创业之前的那些很优雅的想法，在生存的压力面前，就慢慢开始变形了。
+
+**2.投资者压力**<br>
+即使创业者拿了融资，不再烧自己的钱了，但是投资者不是雷锋，他给你投钱并不是为了无偿帮助你，而是想获得超出预期的回报。可能他投了一千万，但他会希望这一千万能给他带来一个亿、十个亿甚至百个亿的回报，这才是他们真正的诉求。
+
+因此，融完资之后，可能有的投资人信任创始团队，不会过多参与过问公司经营情况，但这是少数，大部分投资者都会非常关注公司营收，可能会经常问你财务报表怎么样、营收有没有翻倍等，这些都会给创业者带去很大的压力。
+
+**3.激烈的市场竞争**<br>
+国内互联网行业竞争激烈，一旦出现一个新模式，马上会有几百上千家公司跟上，比如之前的O2O、P2P、共享单车，现在的区块链等等。但同样的，每个行业到最后可能只会剩下一两家公司成功存活。
+
+互联网时代的商业规则：赢家通吃，数一数二，不三不四。 老大占据大部分市场，剩下的给老二，其他的都无声无息，没有三没有四。
+
+这个规则就决定了，在一个细分领域里，只有成为其中数一数二的公司才有可能存活下去。这给创业者带来了极大的压力，鞭策着他们不停往前跑，无法停歇。
+
+其实，创业者都是非常有理想的人，为了实现他们的创业理想，即使没有外界压力，他们自身也会给自己施加很大的压力，再加上这些激烈的市场压力、生存压力和资本压力，更是如座座大山压在创业者肩上心头，导致公司的实际情况离最初创业时的理想模式越来越远。
+
+### 经营目标驱动下的研发模型
+
+这三重生存压力带来了公司的经营压力，而有经营压力，就一定会有经营目标。
+
+很多创业公司，在第一年、第二年的时候，因为体量比较小，在经营上会相对比较随性，但到了第三年、第四年之后，就需要开始做公司的年度商业计划，包括产品、市场、财务、人力等各个方面的计划，公司开始向经营目标驱动的模式靠近。这时，导致产品技术文化受伤的情况是，所有的计划最终都会落到一个个数据指标、一个个KPI上。
+
+很多创业公司在最初成立的时候，都会说我们是反KPI的，但实际上到最后多多少少都会落回到KPI上。KPI本身没有原罪，它只是一个工具，只是KPI往往太过强调收入，很容易导致公司整体以经营目标为驱动，忽视了产品技术文化。
+
+这里举个例子，图中是一个手游公司的KPI体系，他们会先设计一个目标，比如月流水达到1000万，然后整个公司就开始围绕这个目标运转。在设定目标之后，他会先反推目标，例如要达到这样的目标，要达到多少的留存率、多少的用户平均收入、多少的转化率等等。
+
+<img src="https://static001.geekbang.org/resource/image/d6/54/d668e87b0459d882d1467b91ac134754.png" alt="">
+
+而这些具体的指标确定之后，马上就会反应到版本特性规划、开发计划上，并细化到每个人的KPI上，付诸执行。随后就是定期考核、阶段总结，再之后是根据考核情况和目标完成情况发放奖金、调整团队等。
+
+这就是经营目标驱动下的研发模型，所有都是围绕着经营目标而转。同时，不得不承认，除了创业的最初阶段，公司一旦走入正轨，基本上都要遵循这样的研发模型，大公司无非是整个模型体系中的环节更多、更完善。
+
+这时就会发现，产品技术人员的创意开始让位于KPI驱动，也就是业绩经营驱动，这是很多创业公司进入融资阶段以后和规模化运营以后都会面临的情况。
+
+### 强悍的市场文化、产品技术文化不再
+
+这时，就很有可能出现市场文化强悍，产品技术文化弱势让步的情况。而在这种市场文化之下，产品研发人员最怕的就是需求，然而每天面对也必须面对的还是需求，而且包括来自市场的需求、来自领导的需求、竞争对手带来的需求（比如竞争对手做了一个新特性，公司也得跟上）等等。除此之外，还有为了公司长远发展而做的架构需求、规划需求，还有用户在社区中反馈的需求等等。
+
+对于开发人员来说，在底下实际实现的时候，这些大都是在满足市场和领导的需求，其中可能还有一些很傻的需求，他们也不得不做。但在市场人员眼里，他们完全不会觉得这些需求有问题，因为都有可能给公司带来营收。两者的视角不同，观点就不同。
+
+如此，市场文化就开始和产品技术文化产生冲突，而作为公司、作为管理者，就需要在这两者之间做出一个平衡。
+
+产品技术文化是带有一定理想主义色彩的，每一个技术出身的创业者都希望公司是产品驱动、技术驱动、模式驱动，但实际在执行的时候，往往最先进入状态的是市场驱动。
+
+而在市场驱动的文化下，如果你去跟其中的开发人员聊天，相信提到最多的关键字一定会是“加班、版本、进度、急”这些。很常见的一种情况就是领导发脾气，“你们的进度怎么这么慢，新版本怎么还没做好”，然后施加压力，“新版本赶快出，无论如何这周末必须给我上”。
+
+可能刚开始的时候，这种压力对研发人员比较有效，大家能加班赶进度把新版本做出来，但长久处在市场驱动的文化下，研发人员一定会疲惫，效率就必然会不断降低，这种是一种很典型的现象。
+
+面对这种现象，有些公司可能会从流程改进、绩效考核、员工激励等方面着手提高团队效率，可能能起一时之功，但如果继续任由产品技术文化缺失，研发人员疲于应对各种市场、领导压过来的需求，依然是治标不治本。
+
+总结一下，当前国内的互联网行业，少有纯产品技术文化驱动的创业公司，资本裹挟和市场欲望是大部分创业公司的驱动力，这其实是创新缺失和产品技术文化缺失的主因。
+
+不知道你是否认同这个观点，欢迎在评论区分享你的观点！
+
+

极客时间专栏/geek/技术领导力实战笔记/第111讲 | 蔡锐涛：从0到1再到100，创业不同阶段的技术管理思考.md

@@ -0,0 +1,128 @@
+<audio id="audio" title="第111讲 | 蔡锐涛：从0到1再到100，创业不同阶段的技术管理思考" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d1/28/d125de5c734f1eb2045f6b9503ec5828.mp3"></audio>
+
+你好，我是有米科技CTO蔡锐涛。有米科技已成立8年，从创业期到发展期再到平稳期，这一路走来，作为技术管理者，我有很多思考，今天分享给你，希望对你有用。
+
+## 了解行业发展趋势
+
+创业前有必要了解行业发展趋势，做好心理预期、人才准备、资金储备等。每个公司都会经历5个发展时期，即技术萌芽期、狂热期、幻想破灭期、复苏期与平稳期。
+
+<img src="https://static001.geekbang.org/resource/image/88/a0/8842022f6b2782a70ebc492fcb2e63a0.jpg" alt="">
+
+公司在不同时期，技术团队的状态也会不同。首先，在技术萌芽期，所有人都非常兴奋，加班、熬夜、赶工都不是问题。比如人工智能出现时，技术人觉得“这就是未来啊”，所以创业的信心爆棚。之后进入狂热期，可能会接到大量的行业风投与外界给予的资源，这时也是泡沫最大的时候。紧接着会跌入谷底，因为理想与现实差距过大，幻想破灭，此时需要寻求新的增长点。等你扛过这段时期，就会进入复苏期，也是高速发展阶段，这时该考虑如何让团队维持商业化，也是证明自己商业能力的时候。最后进入平稳期，遇到行业天花板，就该考察新机会，寻求新的突破点了。
+
+<img src="https://static001.geekbang.org/resource/image/09/22/098cec68a84695d7f64c10a76b77ec22.jpg" alt=""><br>
+所以，我会围绕创业启动期、高速发展期与寻求突破期这三个阶段展开分享内容，每个阶段都需要考虑人、财、物这三个问题。对于技术管理来讲，“人”即人才梯队与团队建设；“财”是团队赚钱的能力，理清团队状态和业务需求，这一点很重要；“物”就是对技术栈、技术架构的选择。
+
+## 创业启动期
+
+### 一、团队状态与业务需求
+
+创业前期，团队成员目标一致，凝聚力非常高，此时，急需出产品，推向市场，快速迭代。
+
+有米科技刚起步时，我们还在读大三，当时没钱、没办公室，于是想尽办法去忽悠楼管，从她手中拿到了学生宿舍活动室的钥匙，我们在活动室埋头苦干一个月，做出了第一版产品。当时的感觉就像你在做一件可以改变世界的事情，很有激情，所以你为此可以做出任何牺牲。
+
+### 二、技术栈
+
+在创业启动期，对于技术栈的选择非常重要，我跟很多创业者交流过，技术合伙人想法过于天马行空，喜欢炫技是不少创业者头疼的问题。
+
+我认为，技术创业应该尽量避免使用新潮技术，我们就深受其害，而是要尽可能减少技术成本，使用成熟、稳定的技术，即使那不是自己喜欢的技术。
+
+举个例子，早期的时候，我们在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人。
+
+我们的培养方式就是以老带新，新同事学习老同事的教程和最佳实践方案，然后将理论投入实践。
+
+其次是技术架构方面，从靠人，到靠系统自动化管理，适应高频度的迭代上线。我们只有三个人负责海外的业务，所有的服务器都是自动化。只有机器高频度的迭代上线，才能使人尽快响应这么快的开发节奏，使系统能够响应整个业务发展。
+
+然后是组织架构方面，我们做了分层，拆分，用单独项目组面对高速发展的业务需求，用独立团队把握基础架构的弹性和稳定。
+
+最后在培养方面，我们建立了领域委员会和学习机制，每周有专人组织分享会，我觉得分享的难点在于愿意分享，所以，在创业早期，就应该鼓励分享，什么内容都可以，逐渐形成分享文化。
+
+### 五、知识系统管理
+
+高速发展期，人员流动大，所以要重视知识沉淀，降低人员流动带来的传承问题。作为技术管理者，要吸纳技术人才，更要将他的能力留下来，对此我总结了三点：<br>
+1.总结公司各领域最佳实践到WIKI。<br>
+2.梳理公司技术栈，减少重复造轮子，减少重复招人带来的成本。<br>
+3.重视内宣，鼓励技术团队对内宣传自己的优秀组件，鼓励同类团队间的交流。
+
+我认为CTO中的T是Talk（讲话），你要多谈话、多分享，多宣讲正能量，多营造交流氛围。比如，我们的程序化交易团队，会跟算法团队一起交流。我们鼓励交叉分享，这样不仅能互相学习，还可以碰撞出更多可能性。
+
+## 寻求突破期
+
+### 一、团队状态与业务需求
+
+当我们最初选定方向时，其实就确定了天花板。比如，选择做游戏，游戏在中国的市场不到千亿，腾讯和网易就切割掉70%，剩下的30%既是你的市场，也是你的天花板。当然，在公司寻求突破时，就说明它已经成功了一半，目前我们正处于这个阶段。
+
+在寻求突破期，业务多且稳定，在满足财务指标的同时，需要寻找新的突破点。这时人员流动也较大，因为泡沫挤出后，我们就不需要那么多人了。
+
+另外，因为你要不断尝试突破，而新项目尝试的失败率也非常高，相当于再次创业，所以，成功率在百分之二就已经非常不错了。
+
+### 二、技术架构需求
+
+既然尝试突破是当下最重要的事，首先我需要不断提高组件化能力，降低试错成本。比如我们的公众号业务，利用爬虫软件每天抓取全国上万个公众号文章内容，供业务人员参考，降低试错成本。
+
+其次要围绕数据，建立在数据之上挖掘需求，给运营团队提供非常好的工具，帮助他们精准分析数据。
+
+### 三、寻找突破点
+
+我认为，在平稳期寻求突破的最大挑战是，从关注一个点，到关注多个点，对于这个挑战，我有三点建议。<br>
+1.走出去，强化情报和线索搜集能力。<br>
+2.保住人，就是核心人才保留计划。我们会尽量满足核心人才的需求，比如钱、婚姻等，也可以送他读EDP、MBA、EMBA等等。<br>
+3.强技术，提供更好的技术研发条件。这也关乎试错率的问题，作为技术管理者，要鼓励技术创新，而创新过程中一定会有失败，也要求技术人员有承受失败的能力。因为有的人在失败一两次之后就受不了了，所以技术管理也要区分哪些人适合试错，哪些人不适合。对于后者，那他只需做好自己的工作就可以了。
+
+### 四、组织变革
+
+组织架构其实是围绕各种极端性变化的，早期人少，没有关键点，到发展期，随着人员能力的增长，组织架构需要进行优化，从而提升团队效率。但在寻求突破期又有不同，我希望我的组织架构能多变化，在碰撞中寻求最优架构，我们组织变革的关键点是拥抱不确定性。
+
+比如我们弱化部门，强调项目组，提高组织的灵活性，鼓励大家用脚投票，如果你在某个项目组待不下去，可以调换项目组。我们会及时处理状况不好的项目组。
+
+在业务相对稳定期，大家的工作内容相对固定，所以我要利用这段时期让所有人都能多了解其他工作内容，而不是只盯着自己手头的一亩三分地，特别是那些优秀人才。
+
+## 总结
+
+创业初期比较容易忽略文化建设；高速发展期，重要的是人才梯队建设和知识沉淀，以便传承；而寻求突破期，就要营造氛围，加深人员之间的联动，碰撞出最大能力。
+
+## 作者简介
+
+蔡锐涛，有米科技CTO，联合创始人，中国最早的移动营销技术专家，专注于移动广告平台及移动应用商业化变现方向相关产品技术的研究。
+
+

极客时间专栏/geek/技术领导力实战笔记/第112讲 | 刘俊强：必知绩效管理知识之绩效管理循环.md

@@ -0,0 +1,66 @@
+<audio id="audio" title="第112讲 | 刘俊强：必知绩效管理知识之绩效管理循环" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/de/7a/de9ead54e27854a7f6a042987986c47a.mp3"></audio>
+
+你好，我是腾讯云资深架构师、TGO鲲鹏会会员刘俊强，有8年以上的技术管理经验，今天想跟你分享技术管理者必知的绩效管理知识之绩效管理循环。
+
+可能绝大多数互联网从业人员都会对一件事达成一致意见，那就是绩效评估既严肃又不好玩，因为绩效会影响员工的奖金和晋升。说实话，对于技术管理者而言，学会如何进行绩效管理尤为重要，我们应当让绩效管理变成有效的管理工具，有效地激励团队，帮助团队成员更好地了解自己的工作及未来的挑战。相信到那时，你已经是一位卓越的管理者了。
+
+## 了解绩效管理循环
+
+其实，我们接触最多的绩效评估（或绩效评定）仅仅是整个绩效管理循环中的一部分，因为绩效评估直接与利益挂钩，所以，我们对这个阶段最为熟悉。但作为技术管理者，要学好、用好绩效管理，不仅需要关注绩效评估阶段，还应该将目光放于全局之上，关注整个绩效管理循环。
+
+我将绩效管理循环简化为三个阶段，具体如下：
+
+阶段一：Planning，绩效目标制定。该阶段主要根据公司战略目标，与团队及团队成员一起制定预期绩效目标，同时也要进行完成目标所需的资源评估等。
+
+阶段二：Check-in，绩效辅导。在该阶段，管理者需要跟进目标完成情况，并给予团队和团队成员必要的支持与帮助，为完成目标扫清障碍。同时，可能需要根据实际情况对之前制定的目标进行调整。
+
+阶段三：Review，绩效考核与反馈。在该阶段，管理者将通过绩效数据对团队及团队成员进行绩效评定，同时，需要就绩效结果跟团队及团队成员进行反馈和沟通，给予团队及团队成员一些发展建议与指导。
+
+为什么将其称之为绩效管理循环呢？因为，通常当我们执行完第三个阶段后，就会进入下一个循环的第一阶段，所以称之为绩效管理循环或绩效管理周期。至于具体的循环周期为多久，可以根据公司的实际情况来设定，底线是不能少于一个季度，原因主要在于，绩效管理循环不光是技术团队内部的事情，还需要人力资源等其他团队的参与。从公司运营的最佳实践来讲，绩效管理循环周期一般为半年或一年，且不能超过一年，否则绩效管理就失去了意义。
+
+为了方便大家了解这个简化后的绩效管理循环，我做了一个示意图，如下：
+
+<img src="https://static001.geekbang.org/resource/image/a9/88/a965a737d702bc6bd370c88165ae7088.png" alt="">
+
+正如前面所说，绩效评估既严肃又不好玩，在工作中是最令人害怕、受人鄙视的，但实际是几乎所有的公司都在使用它，在我看来，关键问题在于管理者通常没能很好的使用这个工具，因此大多数员工都不喜欢绩效考核。
+
+因此，全局性的了解绩效管理循环，有助于我们了解各阶段的意义，以及各阶段应该做哪些事情，使我们更有效地使用绩效管理。同时，这样做也可以帮助我们变得更好，管理能力更为精进。但需要注意的是，还是不要期望所有员工都喜欢绩效考核，因为有些人就是不喜欢被评估。
+
+在整个绩效管理循环中，最重要的是专注于发展，包括两方面：一是公司业务发展需要制定有效的绩效目标；二是通过绩效管理指引团队及团队成员的发展方向，并帮助他们进行有效提升。从这个角度来看，绩效管理是为业务发展提供达成目标的基础，并未为团队和团队成员的未来发展提供基础。
+
+## 适应绩效管理循环
+
+正如前文所说，绩效管理是一个周期内持续循环的过程，这个循环周期可以是半年，也可以是一年。那么，在绩效管理循环周期内我们该如何操作呢？
+
+在此，我先明确错误示范，管理者往往会忽略整个循环周期，直接在阶段三，即绩效评定与反馈阶段开始绩效管理工作，这是极为错误的做法。绩效管理的目的是员工管理，是整个周期内持续不断的过程。
+
+其中，阶段三的绩效评估工作可能只会花费我们1到2周的时间，阶段一的预期绩效目标制定可能会耗费我们3-6周时间，而整个周期内的剩余时间便是用于阶段二的绩效辅导工作。不难理解的是，我们使用绩效管理工具，其根本目的在于帮助团队达成目标。
+
+适应绩效管理循环的关键在于，管理者有效地使用跟进检查方法，而跟进检查的主要作用有三点：<br>
+1.提供支持与帮助；<br>
+2.保持可见性；<br>
+3.避免员工在阶段三出现麻烦。
+
+有时我们认为公开询问员工的工作状态很有必要，这确实管用，但有时候也会适得其反，因为有些人不喜欢别人用对待未成年人的方式对待自己。所以，你需要清楚，跟进检查的目的是，为达成他们目标提供必要的支持与帮助，这种情况下再采用正面、积极的询问方式进行检查会更为有效。
+
+跟进检查的第二个作用是保持可见性，这点很关键，因为这样团队能够时常看到你，知道你在乎并正在关注他们所做的工作及所达成的成长。
+
+另外，采用定期检查与不定期检查，能够帮助我们更了解团队及团队成员的工作进展和状态，以防在阶段三进行绩效评定时，出现因关注少或不了解，造成对团队或团队成员评定不客观的情况。因此，我建议大家在阶段一制定绩效目标时，就同时制定出对目标的定期检查与跟进计划。而在跟进检查的过程中，也需要定期与随机相结合，保持对团队和团队成员的关注度。当然，值得注意的是，检查也不要过于密集，否则你会被贴上控制欲极强的标签。
+
+最后，在每次跟进检查后，你需要总结情况并进行记录，备忘录、电子邮件等都可以，但需要斟酌的是，哪些需要私下记录，哪些需要公开记录并同步给团队成员。
+
+## 总结
+
+本文从全局视角介绍了什么是绩效管理循环，并阐述了作为管理者该如何适应绩效管理循环，从而能够充分、有效地利用绩效管理这个工具。
+
+我会在后面的文章中，详细介绍如何进行绩效目标制定、绩效辅导以及绩效评定与反馈，欢迎持续关注。
+
+最后留一个思考题，在你使用绩效管理工具时，绩效管理循环中的哪个阶段做得不够充分？欢迎在留言区与我分享、交流。
+
+感谢你的收听，我们下期再见！
+
+## 作者简介
+
+刘俊强（微信公众号：程序员精进），TGO鲲鹏会会员，现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+年以上互联网开发经验，8年以上技术管理经验。
+
+

极客时间专栏/geek/技术领导力实战笔记/第113讲 | 程军：技术人的「知行合一」（二）.md

@@ -0,0 +1,100 @@
+<audio id="audio" title="第113讲 | 程军：技术人的「知行合一」（二）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/96/28/96141b64c0dfb65f72be81221352b928.mp3"></audio>
+
+你好，我是贝壳技术总监程军，这些天抽烟的频率有所提升，一天多了半包。因为需要更深入的思考才可以输出更有价值的文章。关于本篇内容，我想了很久，最后决定写一写国内外领导力的对比，就以亚马逊创始人贝佐斯（Jeff Bezos）和曾国藩为例开始吧。
+
+## 远见卓识
+
+我们先来领略亚马逊领导力准则之远见卓识。<br>
+&nbsp;<br>
+徐飞总的极客时间专栏《技术和商业案例解读》中的第89讲，就讲了亚马逊领导力准则中的“远见卓识”这一条，我摘录了其中的两段，原文如下：
+
+亚马逊领导力准则之远见卓识的官方解释是：局限性思考只能带来局限性的结果。领导者大胆提出并阐明大局策略，由此激发良好的成果。他们从不同角度考虑问题，并广泛寻找服务客户的方式。
+
+这条领导力原则主要关注领导者的思维方式。贝佐斯要求领导者不拘泥于局限性的思考，要保持脑洞大开的状态。领导者可以从不同的角度去思考问题，发现别人不能发现的，想到别人不能想到的。这种远见对于一家公司的成长来说非常重要。
+
+从以上内容中，我对这条领导力准则的核心理解是，领导者一定要从不同的角度去思考，不局限，不武断，并且开放、包容，可以简单概括为“远见”二字。
+
+## 担当大事之“明”
+
+曾国潘说过，“担当大事，全在‘明’‘强’二字”。今天，我主要分享我对于其中“明”的理解，主要分三个层面：
+
+### 一、明即光明
+
+明字由日、月两部分组成，而在甲骨文中以日、月发光表示明亮、光明，也可以说是正确的方向。
+
+众所周知，因为每个人看待问题的方向与角度不同，相同的问题，每个人得出的方法与结果也会有所差异。所以，面对问题，首先要认清正确的方向，这是关键，再坚持去执行。
+
+我们公司有一条朴素的价值观是——坚持去做难而正确的事。相信这也是我们老板做事业的核心价值观，并把这条价值观赋予了每一位贝壳人。
+
+举个例子：
+
+一位朋友在今年8月跟我倾诉他的困扰，老板要求年底前招聘120个左右有经验的Go语言开发者。根据他的描述，这个目标已经是确定不能更改的了。而分析现状发现，目前HR的支持非常给力，招聘渠道则主要是猎头、内推等渠道。初看这个问题我们能想到的解决方案会有很多，列出最常见的三种：<br>
+1.增加更多的专业猎头渠道；<br>
+2.统计从收到简历到最终入职的转化率，分析各个重要环节提升转化率；<br>
+3.提高内推奖金，比如可以在原本的基础上再加5000元。
+
+当时我给出的建议是，首先要考虑整个上海的Go语言开发者容量有多大，这需要动用你的资源（HR+猎头）进行估算，然后，乘以你的目前转化率，就是最终理想的招聘数量。
+
+如果数量与目标120人有较大差距，那么以上所提的所有解决方案都无效，问题此刻陷入了僵局。另外其实也不用太过担心老板规定的120这个数，因为老板也是讲道理，你汇报工作时，拿出图和表，绘制这个简单的数学公式给他，他自然会明白的。过了一周他告诉我，按实际估算的结果来看，120这个目标根本达不成。
+
+不久后，我主动问他招聘结果，他很开心的说，问题已经有了新的解决思路，就是招一些其他语言并愿意转到GO的程序员。
+
+我觉得解决一个问题会有很多办法，但是哪个才是有效的、才是最正确的方向，需要我们站在问题之外去考虑，才能更好的找到。愿光明照亮你我的技术领导力之路。
+
+### 二、高明与精明
+
+曾国藩又有言：明有二端，人见其近，吾见其远，曰高明；人见其粗，吾见其细，曰精明。
+
+这句话的含义是：“明”有两种，一种是高明，看得比别人深远，高瞻远瞩；另一种是精明，看得比别人细致，明察秋毫。
+
+这里举一个最近几天和团队小伙伴沟通的例子：
+
+团队中的一位P6的后端研发同学说最近有些疑惑，想找我沟通，于是找了一个我俩都有空闲的时间，准备坐下来好好聊一次。他说自己喜欢研究一些新的框架和技术，但问题是，他发现自己坚持一段时间后就坚持不去了，内心感到有些慌，需要解惑。
+
+我问了他两个问题：<br>
+问题1，学习目标达到了吗？他回答还有一些差距但有所收获。<br>
+问题2，你觉得差距有多少？他没有回答上来。
+
+我认为他是精明的，知道自己想要什么，并且很努力，只是结果不那么如意罢了。
+
+随后我和他一起制定了一个切合实际的目标，并按SMART（s=特定细分、m=可测量评估、a=可触达、r=依赖的资源、t=时间）原则细化其中的一个目标。我跟他讲，我们先制定1个月的目标，还需要将其分解到每周为单位周期。这个目标要可以量化、可以评估，同时需要重点考虑可依赖的已有资源（可能是人也可能一个GitHub开源项目或其他）。
+
+另外，在我们计划执行过程中，有时会因为一些不可抗力因素而需要调整目标，对此不用太玻璃心或患得患失，这都是正常的。借用二爷在《邱岳的产品手记》中的一句话，“没有任何一个作战计划在作战过程中还行之有效，但是做计划本身还是必要的”。<br>
+&nbsp;<br>
+显然就这个case而言，我看的更远，或许是高明，你认同吗？
+
+但是仅有高明还不够，在我的理解中，高明是战略层面，精明是战术层面，高明与精明是个统一体，二者需要高度结合。只有高明则眼高手低，只有精明，则容易缺乏大局观，难成大器。这里用曾国藩的另一句名言收尾，即“古之成大事者，规模远大与综理密微二者缺一不可”。意思是真正成大事的人，战略的大局与大势和细节的考量与处理，缺一不可。
+
+### 三、当局者迷，旁观者清
+
+曾国藩有一句话叫：天下事当局者迷，旁观者清；事前易暗，事后易明。
+
+这里主要想跟大家聊一下“当局者迷，旁观者清”，下棋的人都知道，旁观者不受胜负输赢的影响，自然脑子清醒，可以从两方棋手的角度看待问题，从而跳出局限看清局势。而当局者因为胜负输赢与自己息息相关，很容易受到影响看不清局势。
+
+继续举个例子：
+
+我还记得当年我在1号店负责公司供应链（仓库管理系统简称WMS，物流运输管理系统简称TMS）系统研发的时候，公司CEO于刚先生邀请了一支咨询团队来了解1号店整个C端用户购买和退换货体验，以及运营类员工（核心是仓库、物流、客服人员）使用内部支撑系统的体验。
+
+咨询团队提出了非常多的问题和优化建议，随后我们多次开会讨论，从提升C端用户体验出发，我们着重解决了用户最头疼的退换货问题，还推出了订单半日达服务；从提升内部效率出发，我们的WMS系统从人工波次改成系统自动波次和人工波次相结合，TMS系统中最后一公里的配送路径，从依赖配送员经验分配路线，优化成系统结合订单商品的核心属性、用户地址等维度给出最优配送路径，配送效率大大提升的同时，用户投诉也减少了不少。
+
+但是当时，我和我们领导其实并不太理解公司的这种行为，认为这是一种太信任的体现，我们觉得之前的C端系统和内部支撑系统已经非常好了，并没有那么大的改进空间。但结果证明，这支咨询团队之后优化建议是非常有价值的。
+
+今年9月，我在看于刚先生写给创业者的《激情创业：让不可能变为可能》一书时，才明白他当时的做法并不是不相信我们这些系统设计和研发者，而是希望找一个身在局外的团队去找问题、去无情的暴露问题。因为局外人通常会站在公司内部和用户双方的角度思考问题，更容易跳出局限，直击要害，找到问题的关键所在。
+
+这就应了曾国藩另外一句话：任事者，当置身利害之外，建言者，当设身于利害之中。
+
+时间过去9年了，我对于公司当时的行为，也从当初的不理解变为此刻的赞成，这也许就是从当局者迷到旁观者清的转变。
+
+## 总结
+
+本文我们首先领略了亚马逊领导力准则之远见卓识，按徐飞的总结是领导者要有远见，接着我分享了对于曾国藩的担大事者之“明”的三点理解，即光明、高明与精明以及当局者迷，旁观者清。聪明的读者不难发现，这两条领导力原则高度一致，都在于对事物的高度与方向有清晰的把握，对战略和细节有足够的理解。
+
+为此，我还特意咨询过于刚先生（他在亚马逊任高管时直接向贝佐斯汇报工作），贝佐斯是不是曾了解过中国的领导力文化，他的答案是，贝佐斯并没有了解过中国文化，也许这就是所谓的英雄所见略同吧。
+
+如果你对这个话题有其他认知，欢迎留言与我分享，也欢迎来我的知识星球“小卒吾「知行合一」”（星球号5139329）跟我一起探讨技术人关于认知和如何在领导力这个领域内实践知行合一相关的话题。
+
+## 作者简介
+
+程军，现任贝壳技术总监，曾任饿了么技术总监、1 号店架构师，10 年以上互联网开发经验，8 年以上技术管理经验。<br>
+&nbsp;<br>
+

极客时间专栏/geek/技术领导力实战笔记/第114讲 | 成敏：谈谈不同阶段技术公司的特点.md

@@ -0,0 +1,67 @@
+<audio id="audio" title="第114讲 | 成敏：谈谈不同阶段技术公司的特点" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/2a/ca/2ab8917079f0670656a1dac86ff6bbca.mp3"></audio>
+
+你好，我是成敏。技术体系建设是每个CTO都需要关注的话题，但技术体系建设很难像技术工程建设那样，得出一个最佳实践。因为每个公司的背景、业务形态、组织结构，甚至CEO性格都有所不同，而这些因素都会对技术体系的建设产生影响。
+
+今天就简单的以公司规模大小为划分标准，分析在不同规模下，技术公司的业务特点，以及要做好技术体系建设可能面临的困难。
+
+## 第一个阶段：十人左右规模
+
+当公司规模比较小的时候，比如还处在初创阶段，这时公司可能只有十几人，机器也只有十几台，规模很小。在这个阶段，公司的需求变化通常会非常快，甚至可能还没有确定业务的主营模式。很有可能公司今天尝试某个方向，结果发现此路不通，第二天就转换方向，试行另一个方向。
+
+其实，不少创业公司就是在这样的快速迭代，不断试错中找到了自己的爆发点。
+
+这样需求变化快且业务模式难以固定的团队，对团队成员技术栈宽度的要求会非常高。比如研发岗位除了做好研发工作外，还需要承担测试、上线等工作，甚至之后的运维也需要他们来负责。再比如，这时的CTO不仅要把控技术方向、管理技术团队，还得上手写代码，更有可能还要去机房看机器情况。
+
+因此，在这个阶段，公司会更看重研发人员的单兵作战能力，之前很流行的全栈工程师正是在这样的需求下应运而生。同时，在这个阶段，团队往往有着非常高效的沟通效率和执行速度。可能有个需求提出来，团队几个人周末加个班熬一下，周一就能上线了，非常快。
+
+当然，这个阶段，团队的问题在于，一是团队的技术天花板会受限于单兵的技术水平；二是缺乏人才储备、规范化程度也比较低，一旦有人离开，就会极大的影响研发进度；三是技术成本投入很难实现规模化。
+
+## 第二个阶段：五十人左右规模
+
+这个阶段，公司稍微有点起色了，团队规模也达到五十人左右，机器也能有一两百台的规模。
+
+这个阶段，公司的业务主体已经比较明确，但需求变化加快，可能比之前初创期来得更快。团队在这个阶段开始有了明确的分工，但未必有分组，比如运维工作会招一两个专职的运维来负责，不再由研发兼任，但还没法形成专门的运维团队。
+
+在流程上，公司开始关注协同及规范，只是整体的流程规范依旧比较简单，自动化程度比较低，协同比较松散。这个时期，内部沟通依旧会比较顺畅，只是需要警惕不要让公司陷入到作坊式作战的陷阱中去。
+
+## 第三个阶段：百人左右规模
+
+这个阶段，团队规模一般能达到上百人，机器规模也能达到一两千台。一般到了这个阶段，公司的主营业务已经相对稳定，也开始做1-2年左右的规划，因为如果没有一个稳定的主营业务，创业公司也很难进入这个梯队。
+
+这个阶段，业务需求仍然大于技术资源，而技术和业务上的分组都已经开始产生，除了基本的分工之外，会有一些明确的分组去负责明确的事情，比如A团队就负责A这个业务线，B团队就负责B这个业务线。
+
+在这个阶段，公司也会更重视流程规范，会尝试利用开源工具完成最原始的自动化，团队成员的自主性、自我驱动力也会非常强。其实在第一个阶段，初创团队成员的自我驱动力也非常强，但由于单兵作战，这种驱动力产生的成果往往不具备规模效应，一个人又管研发、又管上线、又管运维，即使他基于流程痛点写了个小工具，节省的也只是自己一个人的时间。
+
+但在第三阶段，上百人规模的团队已经初步具备规模化的效应，比如针对流程写出符合团队需求的工具，在技术上做点有意义的事情，产生的影响力很容易就会扩散到整个团队，提高整个团队的效率。
+
+当然，这个阶段也会存在问题，如人员梯队开始明显化、沟通壁垒开始出现等。毕竟整个公司有一两百号人，每个人的能力、认知等各方面都会有比较大的不同，又不像小团队那样可以坐在一起面对面沟通，很容易出现沟通上的问题，导致沟通效率下降。
+
+## 第四个阶段：五百人左右规模
+
+这是很多中等公司所处的位置。这个阶段，公司业务已经相当稳健，团队规模一般会达到五六百人，机器也能有三五千台，也有能力做2-3年左右的中期规划。
+
+这个时候，公司一般已经有了独立的技术服务团队，也就是除了简单的分工、分组之外，公司还会有一些专门的技术团队专门为内部其他团队提供支撑服务，比如内部的工程效率团队等。
+
+在这个阶段，公司需要尤其注重人员培养机制和梯队的建设。一方面，对这个阶段的公司来说，人员流失是一个非常大的问题；另一方面，与大公司相比，这类中型公司的技术影响力与人才吸引力都比较弱。因此，想要公司更上层楼，就一定要打造好人才培养机制和梯队，加大加深公司的人才储备池。
+
+另外，在技术层面，这个阶段的公司还会面临两个问题，第一个是技术债务的归还，在目前业务比较稳健的情况下，要不要调整或重构用了几年的老系统。
+
+第二个是技术路线的争议，团队小的时候，大家可能没想那么多，只要系统能跑就好了，但到了这个阶段，不同的语言、框架、架构各有利弊，团队成员也各有偏好，到底如何做技术选型，就成了这个阶段的一个问题。甚至曾有团队为了确定选择哪个框架，连续开了两次会还没有讨论清楚，耗费了时间与组织技术资源。
+
+当然，还有技术上的重复建设，跨团队的协同沟通等都是这个阶段需要面对的问题。
+
+## 第五个阶段：两千人左右规模
+
+这个阶段，公司规模一般已经超过两三千人，机器也有几万台。这个阶段的公司，一般已经拥有完备的技术体系和人才体系，也有足够的资源建立前瞻性的技术研究团队，能够应对未来至少三年以上的长期规划。
+
+对于这个阶段的公司，会更注重技术文化的建设和价值观的传递。另外，在这类大型公司里，很容易出现业务分工上的问题，毕竟各个团队之间的职能范围、业务范围有重叠，团队间的竞争在所难免。这种竞争关系，一方面能够调动员工积极性，促进公司业绩，但另一方面，也会带来技术损耗，甚至形成政治壁垒。
+
+最后，对这类大公司来讲，最重要的就是要做好长线规划，否则一旦遇到问题，很难在航行中调转方向。
+
+## 小结
+
+本文将技术公司按照规模大小简单分成了五个阶段，每个阶段的特点和面临的问题都各不相同，不知道你所在的公司目前处于什么阶段呢？当前面临的最大的问题又是什么呢？欢迎留言与大家分享。
+
+感谢你的收听，我们下期再见！
+
+

极客时间专栏/geek/技术领导力实战笔记/第115讲 | 成敏：打造优秀团队与文化的三个推手.md

@@ -0,0 +1,80 @@
+<audio id="audio" title="第115讲 | 成敏：打造优秀团队与文化的三个推手" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/0c/9f/0c8c65c2f19e29db3832da155fc0bf9f.mp3"></audio>
+
+你好，我是成敏，团队与文化的重要性已经毋庸赘言，每个有追求的公司都会致力于打造优秀的团队与文化。
+
+毕竟在当前高速变化的互联网行业，新的技术和新的模式一直在不断涌现，如果能拥有健壮的团队和优秀的文化，就能有更多的机会克服障碍，抓住新出现的机遇。
+
+同时，发展优秀的文化需要团队本身达成共识，而这种凝聚力会正向地反映到团队所构建的产品上。优秀的文化促成优秀的产品。
+
+那么如何打造优秀的团队与文化呢？一般我们可以从组织与梯队建设、制度建设和文化建设三个方面入手。
+
+## 一、组织与梯队建设
+
+### 组织建设
+
+先来看组织建设，通常，组织建设有三个考量点，即沟通效率、执行效率、人力成本。
+
+常见的组织结构有垂直向划分、横向划分、矩阵型划分等几种。有些公司以技术类别垂直划分为QA部门、运维部门、前端研发部门等等。有些公司则以业务为导向横向划分，每条业务线中都有各自独立的研发、QA、运维等人员。还有些公司经常在这几种模式间切换，我们很难说那种划分方法是完全正确的。
+
+不过，沟通效率通常与组织结构划分有关，而技术组织是业务体系的一种映射，当技术组织与业务体系匹配时，整体沟通效率会更高，反之就会出现各种各样的问题。
+
+举个例子，某公司创业之初，为了方便管理，组织结构是以技术类别垂直划分。但团队规模大了之后，发现在这样垂直划分的结构下，某个产品或某个业务需要协调后端、前端、移动端、运维等多个部门，沟通难度大大增加，导致沟通效率大大降低。
+
+当发展到五百人左右规模的时候，团队已经承担不起这样的沟通成本，决定按照业务线重新调整组织结构，将其变为横向划分，这样，每个业务线都包含各自所需的技术、产品、运营等人员，沟通效率、资源分配率、成本核算率都大大提高。
+
+而执行效率与沟通效率一样，其所需的成本占比都会随着团队的变大而增加。举个例子，某个业务需要移动团队支持，但在垂直划分的组织架构下，移动团队还需要支撑公司其他业务线，你的需求只能进入他们的需求池，按照排期慢慢做，但对你来讲，整体执行效率就会大打折扣。
+
+至于人力成本，垂直划分的组织结构下，因为人员集中，人力成本会相对节约，而横向划分则相反，它会带来一些人员的重复建设，造成人力成本、技术成本上升，但相应的，它也能带来业务效率的提升，所以就需要你在做组织建设时，好好衡量人力成本与业务成本之间的关系。
+
+### 梯队建设
+
+再来看梯队建设，一个合理的梯队建设可以帮助团队规避许多风险，主要包括：
+
+1.降低人员变动风险<br>
+如果团队中只有一个能力很牛的人，其余都是刚毕业的或是能力比较初级的人，那么一旦这位牛人离职，他所负责的工作就没人能顺利接手。所以，我们需要搭建合理的梯队，来降低人员变动风险。
+
+2.使技术人力成本更加合理<br>
+即使在同一个技术团队，总有些工作是属于攻坚突破的技术活，还有些则属于增删改查的体力活。如果团队的梯队结构分配不合理，比如让高水平的工程师去做那些相对他的技术能力来讲很初级、很简单的工作，这绝对是技术人力成本的浪费。同时，工程师本身肯定也干得不爽，很容易离开，造成团队的损失。
+
+3.定制人员成长发挥空间<br>
+作为技术leader，一定要定期review团队的梯队结构，至少一年一次，因为在技术团队中，人员的变动和人员能力的变动都是非常快的。当然，review的时候，除了技术能力外，还要多多考虑其他维度的因素，比如沟通能力、性格，甚至年龄、性别等，以此来定制人员的成长发挥空间。
+
+以沟通能力为例，如果一个团队里都是那种个性固执、不擅沟通的纯技术人员，那么这个团队跟产品团队的沟通就会非常吃力痛苦。所以，技术leader在考虑梯队建设时，一定要考虑团队里哪些人擅长沟通，就让他们多负责跟产品、业务等其他团队的外联事务；哪些人更喜欢钻研技术，就给他们更多机会去研究、突破技术难点。
+
+一个强健的团队需要多种能力的人才，而合理的梯队有助于个人发挥其能力，使其快速成长，进而强大团队。
+
+## 二、制度建设
+
+制度建设又可以分为流程规范和知识库两个方面。
+
+### 流程规范
+
+先来看流程规范，流程不是为了最好地解决问题，而是为了避免最坏的情况产生。同时，规范也不是为了统一对错，而是为了协同共识，以编码规范为例，我们很难说哪种风格是对的，哪种风格是错的，公司选择某个规范也并不是认为这个规范就是对的，只是为了协调团队达成一个共识，让团队在基准问题上保持一致性，规避争议。
+
+另外，流程规范本身也是有成本代价的，老掉的流程比没有流程更有害，所以，作为技术leader，也要像review团队梯队一样，经常review团队的流程规范，检查其是否符合当前业务形态，其中又是否有疏漏。
+
+### 知识库
+
+再来看知识库，俗话说“见字如见人”，同样，在技术团队中，知识库的水准基本可以衡量这个团队的整体水准。
+
+很多一线的技术人员可能会认为构建知识库是个重复而麻烦的工作，不过是把做过的东西再写一遍，但作为技术leader，必须清楚知识库对于技术团队的重要性。
+
+互联网行业人员流动快，可能过了三五年，一个团队中的人员就基本都换了一遍。这时，如果没有完整的知识库，很多东西就没法传承，可能上线多年的老系统没人能弄清楚，新人就不敢去动，一些最佳的解决方案也没人再去回顾，导致重复劳动等等。
+
+另外，如果没有知识库体系，公司的业务知识、技术知识难以传承，就很容易出现“业务绑架”的问题。所谓业务绑架，指的是某个员工所在的岗位比较重要，可他能力较弱或态度较差，但他会以某些独特而有价值的知识长期占据该岗位，并且不愿意与人分享，而构建知识库能极为有效的避免出现业务绑架问题。
+
+## 三、文化建设
+
+优秀文化对团队、对技术人员有着极强的凝聚力，但文化建设是一个很难谈的问题，它与组织形态、业务形态等各个方面息息相关，不过在大的层面，我们需要遵循两个要点。
+
+首先，文化的建设应避免理想主义，必须有明确的目标，比如这种投入产出是为公司服务的软形态。举个例子，很多公司都会花费时间、金钱去组织团建，但团建时，往往还是熟络的同事在一起玩，组成一个个小圈子，很少有活动能够真正将整个团队融合在一起，并将公司想传递的消息传递给每个人，这样的团建其实就只达成了一半的目标。
+
+其次，文化的建设应该基于共识，而不是强推。文化的核心在于融入，而非排斥。君子和而不同，我们应该尽量将不同背景、不同年龄、不同想法的人融合在一起，这样才是良好的团队文化。
+
+## 小结
+
+团队与文化的重要性毋庸赘言，所有的公司都希望能拥有健壮的团队和优秀的文化，本文从组织与梯队建设、制度建设和文化建设三个方面出发，总结了一些打造优秀的团队与文化的经验，希望能给大家带来一些启发。
+
+感谢你的收听，我们下期再见！
+
+

极客时间专栏/geek/技术领导力实战笔记/第116讲 | 刘俊强：必知绩效管理知识之绩效目标的制定.md

@@ -0,0 +1,77 @@
+<audio id="audio" title="第116讲 | 刘俊强：必知绩效管理知识之绩效目标的制定" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a7/fd/a77ad7c2481313f5a0839caeda22edfd.mp3"></audio>
+
+你好，我是腾讯云资深架构师、TGO鲲鹏会会员刘俊强，有着8年以上的技术管理经验，今天想跟你分享技术管理者必知的绩效管理知识之绩效目标的制定。
+
+我们在前一篇文章中介绍了绩效管理循环，全局性地了解了绩效管理的三个阶段，在本篇文章中，我将来聊聊绩效管理循环里的阶段一，即绩效目标的制定。
+
+现代企业管理中普遍使用的绩效管理工具有『关键绩效指标』（简称 KPI）和『目标和关键成果』（简称 OKR），不论是 KPI 或 OKR，目标的制定都是十分关键的，因为实际绩效需要通过目标完成情况来进行评定。在探讨具体如何进行目标制定前，需要明确的是，绩效目标一定要在考虑业务发展需要的前提下，与员工来一起制定，需要互相尊重地达成一致。
+
+## 制定目标的正确姿势
+
+首先需要了解的是绩效目标的制定过程，它并不是由老板到下属设定任意目标的简单过程，而应该是一种平衡多种需求的过程。绩效目标本身应该给员工提供明确可实现的目标，从而激发员工产出优异的绩效。有效的绩效目标需要考虑以下几个方面：
+
+目标需要在员工的能力范围之内，远超出员工能力的目标是不可取的；<br>
+目标需要有助于员工的发展和意愿，与员工发展意愿背离的目标可能会造成员工的不稳定；<br>
+目标需要帮助公司实现更高层次的目标，不能够帮助公司实现业务发展的目标是无效的；<br>
+目标需要帮助团队更好的成长和发展。
+
+这里需要声明的是，没有完美的绩效目标，也就是说不能希望有个绩效目标是完美满足以上几个方面的，如果我们制定的绩效目标并不能满足其中的某一个需要，这种情况是可以接受的。但同时我们要明确的是，制定的绩效目标不要处在以上这些需要的对立面，毕竟咱们制定的绩效目标还是要正向循环的。
+
+通常情况下，对于有多层管理架构的公司或组织，会先根据战略计划以及过往绩效循环的情况来制定年度目标，然后跟下一级的团队或部门进行共享，这些团队或部门的管理者需要根据公司年度目标来制定他们专业领域的绩效目标，一般来说，技术管理者需要根据公司年度目标来制定技术或工程团队的绩效目标，主要考虑技术或工程团队如何帮助实现公司的年度目标。
+
+再往下一层是员工个人进行绩效目标的制定，这时候首先需要考虑员工个人目标与团队目标、公司目标的方向一致性。另外，根据特定员工的绩效趋势，跟员工制定绩效目标时，除了要考虑团队目标与员工个人的发展需要外，还需要考虑员工在技能和知识领域的提升需要。
+
+在跟员工制定绩效目标时，需要考虑员工的特质和意愿，例如在最近的绩效循环中表现优异的员工，可以给予更多的机会。这些机会可以是纵向的，例如增加相同类型的工作或相关工作；也可以是横向的，例如更高级别的职权等。对于这样的员工，我们在制定绩效目标时，需要基于这些成长机会来设定新基准绩效标准。
+
+这里需要注意的是，有些人面对成长机会非常高兴，甚至会主动告诉你他们希望在新的绩效循环里达到什么位置。但是也有些员工是很内向的，不会跟你主动分享自己的意愿，因此你作为技术管理者就需要跟他们有私密的交流沟通，在沟通中了解他们的意愿和期望，并将其记录下来。做好记录的目的是帮助自己之后能全面深入的思考。
+
+最后，制定绩效目标时也要考虑团队的需要，有时候团队中需要有一定的牺牲和取舍，团队中会出现一些工作内容是员工不愿意负责的，这时候就需要有员工做出一定的牺牲来承担。对于这样的员工，你需要对其保持肯定的态度，另外不要让这些做出牺牲的员工偏离他们的意愿太长时间，否则就很有可能会失去他们。
+
+综上所述，制定正确的绩效目标需要你在公司需求、团队需求以及员工需求之间进行有效的平衡和满足，但不期望这些需求全部都能满足，找到需求之间的平衡点才能帮助你制定更有效的绩效目标。
+
+## 绩效目标的本质是合作
+
+在过往几十年的企业管理中，以非常简单粗暴的自上而下的方式制定绩效目标是很常见的，处于组织架构上层的人给下层的人直接制定目标。这种方式的好处在于权力清晰和执行高效，但随着时间推移，在大多数公司或组织中，特别是互联网类公司中，这种方式已经不再适用，转变为通过合作协作的方式来创建绩效目标，因此我们说绩效目标的本质是合作。
+
+这种转变的产生由几个因素共同推动，首先，脑力劳动的兴起需要公司对普通员工有更多的尊重。其次，为了更大程度的释放团队生产力，如今的组织架构会更多的趋向于扁平化或最小组织化等，而这样会造成领导结构的平等意识，虽然还是有位置差异，但人们会意识到自己或其他成员决定了团队的绩效表现。
+
+最后一个因素是，合作协作模式释放了团队的综合心智，不仅仅是简单的听写效率，在合作模式下，员工或管理者与他们上级间的关系，不再仅仅是接受指示的关系，而是需要他们更多主动地思考来达成更高的目标。这种双向对话的合作模式不仅有助于满足公司需求，也能更好的满足员工的需求。因此，作为技术管理者，我们需要有这样的合作心态来进行绩效目标的制定。
+
+需要注意的是，我们在跟团队或员工制定绩效目标时，需要考虑短期生产力与长期承诺之间的平衡，有时我们会忽略对长期目标的思考，迷失在短期目标之中。一般我们会使用 S.M.A.R.T 原则来帮助团队和员工建立短期目标并实现它，这里我们先简单介绍下：
+
+Specific-目标必须是具体的；<br>
+Measurable-目标必须是可以衡量的；<br>
+Attainable-目标必须是可以达到的；<br>
+Relevant-目标必须和其他目标具有相关性；<br>
+Time-based-目标必须具有明确的截止期限。
+
+S.M.A.R.T 原则十分重要，因为它可以帮助我们保持团队或员工的短期生产力，但这里需要提醒的是，长期发展承诺是需要我们在 S.M.A.R.T 原则之外来考虑的，比如，长期来看你希望团队如何发展，长期来看员工希望在团队、公司有什么样的发展等？
+
+在我们明确了长期目标之后，可以尝试在绩效目标中的一小部分加上长期发展相关的工作内容，当然这也是在跟团队和员工沟通的前提下进行的，我们需要以合作协作的心态来进行绩效目标的制定。
+
+## 绩效目标制定的贴士
+
+最后，再分享一些绩效目标制定时的小贴士，大家可以记录下来方便日后查阅：
+
+考虑员工的能力；<br>
+考虑员工的意愿；<br>
+给予绩效好的员工更多纵向、横向的机会；<br>
+留意员工的绩效趋势；<br>
+非正式的记录员工表现；<br>
+考虑团队的需求。
+
+## 总结
+
+本文介绍了如何进行正确的绩效目标制定，需要考虑的需求有哪些，并在最后提供了一些绩效目标制定的小贴士，期望能够帮助大家更好的掌握绩效目标制定的技巧。
+
+## 思考题
+
+在最近一次的绩效目标制定中，你采用了怎样的方法和模式呢？不妨在评论区留言分享给大家~
+
+感谢你的收听，我们下期再见！
+
+## 作者简介
+
+刘俊强（微信公众号：程序员精进），TGO鲲鹏会会员，现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+年以上互联网开发经验，8年以上技术管理经验。
+
+

极客时间专栏/geek/技术领导力实战笔记/第117讲 | 程军：技术人的「知行合一」（三）.md

@@ -0,0 +1,88 @@
+<audio id="audio" title="第117讲 | 程军：技术人的「知行合一」（三）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/89/84/8905f2280fe05d4562382e414d0a5584.mp3"></audio>
+
+你好，我是贝壳技术总监程军。每次抽烟到烟头快熄灭的时候，心里总会抱怨怎么这么快，然而过不了多久，又会点起新的一支烟。众所周知，这个世界是复杂且多变的，我们唯一能做的，就是在大部分时候都保持乐观、积极的态度面对生活赋予我们的一切。
+
+曾国潘曾说过，“担当大事，全在‘明’‘强’二字”，上一篇文章中，我主要分享了我对“明”的理解，今天，我想聊聊我对其中“强”的感悟。
+
+## 一、天行健，君子以自强不息
+
+“强”就是指刚强、倔强、自强和坚持，所强调的是意志力、毅力、定力和决心的力量。
+
+他曾说过：“势利之天下，强凌弱之天下，此岂自今日始哉？盖从古已然矣。从古帝王将相，无人不由自强自立做出。”
+
+意思是说，从古到今的帝王将相，没有一个不是由自强中走出来的，更何况我们这样的凡夫俗子。
+
+这里想分享一个我的例子：
+
+今年5月底，我加入现在的公司，成为本部门的1号员工。入职第2天，领导就把需求方、HR负责人等从北京带来了，我们开了大概2个小时的新产品讨论会，依稀记得老大的套路就是：<br>
+1.强调这个产品线公司高层很重视，并当场把产品相关的行业分析、竞对分析以及怎么构建新的壁垒说了一遍，还介绍了第一期产品需要做什么内容；<br>
+2.提出期望这个产品能在1个月内上线；<br>
+3.表明协助招人的HR也在现场，可以给予最大的支持。
+
+接着问题来了，他问我你现在怎么打算？
+
+当时我几乎是窒息的，心里不停盘算目前团队除了我，什么人都没有，但产品上线日期却已经被确定，该怎么办。内心思考再三之后，我选择回答OK。对于我的回答，感觉当时在坐的各位都很开心，只有我还一直不能释怀，以至于会议结束之后，领导请我吃了上海最有名的红烧肉，我也感觉没滋没味的。
+
+后面的故事按大家想的那样，产品如期上线，数据表现还不错，上线一个月后已经达到每日3000单的交易量。
+
+以下是我当时的解决方案，供大家参考：
+
+1. 和产品同学一起商量这一期MVP版本的产品功能，先定义目标和细化目标；
+1. 深入了解产品需求，整理出业务架构、表结构模型并搭起系统架构，同时识别出其中需要外部依赖的部分，提前沟通让对方排期；
+1. 和兄弟部门的老大不要脸的借来1位开发，由于我入职之前兄弟部门已经发出了一个offer，所以这位同学在我入职后第二周就入职了；
+1. 前端和测试的两位同学分别在2周后入职（别问我怎么做到的，加入一个新团队前也应该提前做一些准备，毕竟兵马未动粮草先行）；
+1. 自己也参与代码编写，跟兄弟们一起战斗，（当时还发朋友圈笑说我是一个已经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 年以上技术管理经验。
+
+

极客时间专栏/geek/技术领导力实战笔记/第118讲 | 吴铭：成本评估是技术leader的关键素质.md

@@ -0,0 +1,71 @@
+<audio id="audio" title="第118讲 | 吴铭：成本评估是技术leader的关键素质" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/27/7e/2701ab4ed8ca664043a9e74bdf11c77e.mp3"></audio>
+
+在互联网公司中，技术与业务的关系一直是焦点，我们对于技术与业务之间的矛盾也早已司空见惯，相信大家在工作中都看到过类似的场景：<br>
+业务问，“对手产品的某功能我们什么时候能上线？”<br>
+技术回答，“目前不行，这个版本我们需要做重构。”<br>
+业务问，“性能慢一点没关系，明天能不能发版？”<br>
+技术回答，“不行，我们要多花两三天时间将性能提高百分之百。”<br>
+业务抱怨，“我和别的公司谈妥了合作营销，技术却总是不给力。”<br>
+技术也抱怨道，“你们一个月提一百个需求，没几个有用的。”<br>
+&nbsp;<br>
+诸如此类场景屡见不鲜，无论公司处在何种规模，只是争议的内容有所不同罢了。归根到底，业务体系与技术体系的矛盾主要集中这四方面：<br>
+1.对于资源的抢占；<br>
+2.对于成本的评估；<br>
+3.对外部目标的差异；<br>
+4.内部目标设定的合理度；
+
+## 协调技术与业务的矛盾
+
+资源抢占是表象，也是其他方面问题的体现，技术leader最需要关注的是对成本的评估，也需要时刻对此保持清醒的头脑。因为技术人天生对技术有追求，我们很难要求每个一线的技术人员都去了解业务背景、业务收益等情况。同理，我们也很难要求产品、市场、运营等人员去考虑技术方面成本与收益。
+
+因此，当公司达到一定规模后，一名优秀的技术leader就必须在技术与业务的平衡和成本评估等方面花费更多的心思
+
+我举两个例子，第一个例子是，曾经我们的技术人员提出一个需求，想用三天时间提升产品性能，使产品主页面的加载耗时缩减一半，同时机器成本也一半降低，这听起来确实不错。但同时，业务人员也提出了一个需求，想在做一个为期两天的红包活动，以此吸引大批用户与流量。
+
+作为管理者，面对技术与业务同期而目标不同的需求，你将如何抉择，又如何做成本评估、价值评估呢？
+
+第二个例子是，我们的技术团队想用机器学习算法重构产品中的酒店业务的排序模型，做到个性化推荐。模拟测试后，新模型的确要比原来的方式效果好一点。但业务团队不支持这个想法，在他们看来，酒店类业务并不是高频使用的场景，而且具有极强的地域性，之前的当地业务人员人工排序的方法效果不错，贸然改用技术排序，结果不一定好。
+
+事实也确实如此，在这种样本量非常小的情况下，技术人员改进之后，短期内效果确有所提升，但是当一些特殊情况发生时，比如节假日、公务员考试等，业务情况就会产生很大的波动，而新的算法模型在早期没办法准确的覆盖这些因素，反而对业务造成了非常不利的影响。
+
+但我们不能以此判别技术团队的改进方案是错误的，只是一线技术人员无法全面考虑到市场中的所有情况，因此，最理想的办法就是技术团队提出产品改进方案后，与业务团队一起进行可执行度评估、价值评估与成本核算。
+
+我想强调一点，作为技术leader，我们做决策时要多以成本与收益为考量点，而不仅是基于个人的技术理想主义。我们常说“技术驱动世界，技术改变世界”，我当然认可技术的力量，但有时必须承认，公司依赖业务运转。可能在某阶段，公司更多的偏向技术驱动，但到了其他阶段，可能就是以产品驱动或运营驱动为主，但归根到底，公司必然是以业务为最终驱动的。所以，我们一定要清楚在当前的阶段和业务场景下，公司对技术有何要求与期望，避免过度技术驱动。
+
+不同公司所处的阶段不同，对技术的定位不同，技术与业务之间的关系也就不同。有些公司对技术的定位是“救火”，解决紧急问题；有些公司对技术的定位是“搬运”，将线下产品或服务等搬运至线上；还有一些公司对技术的定位是“提升效率”；也有一些站在科技顶端的公司，对技术的定位是创新与突破。
+
+所以，技术leader在协调技术与业务的关系时也需要考虑到公司当前所处的阶段 ，以及公司对技术定位，总结一下，可以归纳为以下四点：<br>
+1.清晰服务于公司短期目标，明确技术定位，明确技术驱动与技术创新在当前阶段的价值。<br>
+2.合理调配技术资源分配，包括协调沟通与资源评估。<br>
+3.组织领导成本及收益评估，需要掌握业务知识与成本核算。<br>
+4.预留中长期目标规划空间，做好技术规划与技术储备。
+
+## 技术实施与规划
+
+回到技术上，技术的实施与规划是技术leader工作的核心。先来看技术实施，技术实施的过程有三个关键点，即资源配比、技术选型和业务分析，更有两个绕不开的话题，即旧系统改造与新技术引入。
+
+### 1.旧系统改造
+
+每个公司基本上都会遇到旧系统改造问题，包括何时改造、重构还是改进、投入多长时间、投入多少资源以及价值评估等方方面面的问题。我用一句话总结这些问题：非必要的重构是没有业务价值的。
+
+举个例子，我们之前有个由多个运营人员组成的离线分析团队，他们每天下午5点会看离线分析报表。由于这个报表需要几个小时才能生成，技术人员就投入两天时间去做改进，将几小时改进为耗时几分钟。
+
+从技术层面讲，这件事非常值得鼓励与赞赏，但对于业务方面没有任何影响，运营人员仍然在每天下午5点看报表。如果当时技术团队没有其他高优先级的事情，那么做这件事是很有意义的，但假设当时同时还有个市场活动要做推广，那么技术资源就不该倾斜到这件事情上，因为技术资源永远是不够的，我们做技术改进时一定要结合业务进行成本核算、价值评估。
+
+### 2.新技术引入
+
+技术人员总有创新冲动，看到新的热点技术就想着能不能引进。对于新技术引入，我总结出以下5个思考点：一，引入的技术是否成熟；二，是否已做好相应储备；三，是否能承担相应人员培养成本；四，能够承担多大的风险；五；是否已经做好引入后的价值评估。
+
+总而言之，对于新技术的引入，即使能够将性能提升一千倍，但这种性能提升对业务没有太大帮助，也就没有必要引进了。
+
+我们要鼓励技术人员做微创新，但不论是微创新还是大改进，我们作为技术leader一定要考虑到成本评估与控制的问题
+
+再来看技术规划，对技术leader来讲，技术规划时主要有三个思考点，即技术路线规划、技术栈储备与风险评估。
+
+首先，我们一定要多去关注中长期的技术发展与趋势，但也不要太过超前。除了对那些技术依赖性强的公司，技术有引领、指导作用外，对于大部分的中型、中小型，或初创公司来讲，太超前的规划技术路线，做技术储备没有太大意义。
+
+如今，新技术在很短的时间内就能被普及，我们所储备的新技术很有可能很快就会成为平民化、大众化的技术，大家都可以享受到这种技术福利，比如之前的自动化测试、自动化运维等，很快就变成了大部分公司的标配。另外，太超前的技术出本对成本也是一种消耗。
+
+因此，技术储备的前提是对长期目标和长期收益的判断，只有当既定目标非常明确时，才好去做长期的技术储备，否则，就很有可能发现储备的技术对业务场景并没有太大的价值，变成一种资源的浪费。
+
+

极客时间专栏/geek/技术领导力实战笔记/第119讲 | 汤力嘉：CTO如何进行产品决策（一）.md

@@ -0,0 +1,98 @@
+<audio id="audio" title="第119讲 | 汤力嘉：CTO如何进行产品决策（一）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b6/a8/b6d2db1ac4e9f002b807d9df60b4d2a8.mp3"></audio>
+
+你好，我是一下科技CTO汤力嘉，我经常开玩笑说，要做技术里最懂产品，产品里最懂技术的，今天就想跟大家分享一些我在产品决策上的理念和心得。
+
+## 决策方法论
+
+做一款产品前，首先需要做产品决策，那如何做好产品决策呢？引用乔布斯的一段话，“一个问题看上去很简单，是因为你并没有理解其复杂性；当你把问题搞清楚之后，又会发现其实很复杂，然后拿出了一套复杂的方案来，实际上你只实现了一半，大多数人也都会到此为止；但真正伟大的人会继续前进，找到问题的关键和内在的深层次原因，再拿出优雅的、堪称完美的解决方案”。
+
+正如乔布斯喜欢的另一位伟人达·芬奇曾说过的一句话：“简单，是终极的复杂。”
+
+对于这句话所表达的观点，我非常认同。产品决策最重要的是简单，但简单不意味最少化，简单是具有个性的朴素设计。
+
+举一个耳熟能详的例子，某肥皂生产厂，在肥皂出厂时，会为肥皂装上塑料泡沫盒。但在生产线上，难免出现泡沫盒装空的情况。于是厂商请来高科技团队，入驻肥皂厂，研究如何分拣这些空盒。高科技团队耗费大半年时间，开发出一套高精度摄影设备，可以检测空盒位置，再用灵活的机器手把它们捡出来。同样的问题，另外一位民间科学家，买了一台大功率风扇放在生产线旁边，然后将风力开到最大，把空盒吹走，成功解决了问题。
+
+从这个案例中可以看到，有时最简单的设计，往往效率最高，它不仅能够解决眼下的问题，还相对便宜，不会引起争议，更容易被接受，而复杂是不可持续的。
+
+## 如何检验简单
+
+检验简单的方法有两点，第一，能用一句话表述功能；第二，思考你的用户希望有什么样的体验。
+
+你可能会问，我们有几十几百万的用户，每个用户的需求都不一样，我们到底该为谁设计产品功能呢？
+
+我们可以先将用户进行分类，一般可以分为三类：
+
+1.专家型用户，这类用户愿意使用你的产品，并且愿意花费时间探索和研究产品，并不断提出意见，然后会希望产品按照他们的思路改进设计。这类用户的数量最少。<br>
+2.随意型用户，这类用户对一些新功能比较感兴趣，但是，新功能必须足够简单，最好是在原有功能基础上扩展、衍生的。<br>
+3.主流用户，这类用户一点都不想学习新功能，他们使用产品的目的只是为了解决某些固有的问题。他们掌握一些重要功能的使用方法，但永远不会想要去学会所有的功能。大多数人属于这一类用户。
+
+如何理解这三类用户呢？以手机为例：
+
+首先，专家型用户就是会用到手机文件管理器的用户，他会查看这款手机都有什么功能并一一摸索使用；其次，随意型用户，可能会尝试手机中的美颜拍照功能，但前提是必须保证手机其他最基本的功能，比如通讯录导入。最后，对于主流用户而言，只要手机能够保证基本功能的使用就可以了，比如打电话、上网等。
+
+悲哀的是，多数公司都在为专家型用户服务，并在听取专家型用户的意见方面花费了太多时间，因为专家型用户喜欢提意见，反馈问题。但是，这些专家型用户反映的问题究竟是不是产品应该解决的？这是我们在产品决策中应该思考的问题。
+
+我的建议是，如果你想设计一款简单的产品，请记住，一定要为主流用户设计，解决主流用户的问题。以Excel为例，专家型用户可能会试试分类汇总、邮件合并等相对高级的功能，但99%的用户只希望能解决金额求和这个简单问题，那我们在产品设计的时候只需要满足这个需求就可以了。
+
+## 简单四策略
+
+确定针对主流用户做简单设计的产品策略后，具体该怎么做呢？我们可以从删除、组织、隐藏和转移这四个方面落地执行。
+
+### 删除
+
+1.保留核心功能<br>
+删除是最简单的方式，任何你觉得没有必要的功能都可以删除，将开发精力投入到最核心的功能优化中。
+
+我们常常会走入这样的误区，不想浪费已经做完的功能，干脆将它一起上线。这在经济学中被称为沉默成本，功能做出来后，你的成本已经没办法收回了，但如果选择将功能保留，它会产生更多额外成本，比如维护成本，以及可能对用户造成使用障碍等。所以，当我们考虑是否保留某个功能时，要考虑的不是为什么要删除它，而是为什么要留下它。
+
+另外，以防我们想象不够全面，可能会漏掉一些用户的核心需求，所以对于每一个功能，都要谨慎推敲，只把核心的功能保留下来。
+
+2.功能过多会对用户造成负担<br>
+举个例子，我们之前曾做过一款播放软件Replay，这款软件迭代了两个版本，一个版本有21项功能，另一个版本只有7项功能。做用户调查时发现，用户在没有使用软件前，有2/3的人更倾向于选择功能多的版本，但在使用软件之后，多数用户就变成了实用主义，2/3的用户更喜欢7个功能这一版。<br>
+&nbsp;<br>
+3.功能过多会对用户造成干扰<br>
+Safari中有一个功能是阅读器视图，它会把网页上的广告、链接、图片都过滤掉，只保留一个干净的文字阅读界面。就是因为它在用户调查后发现，页面中的任何链接、图片，即使用户不点击它们，也会对用户造成干扰。
+
+曾经我们做了一个关于节假日的调查问卷，内容是你认为哪个节假日比较好、你在节假日里会做什么等。当时考虑到用户可能会担心数据被收集之后的用处，就在提交按钮旁增加了“查看详情”链接。我们以为只有部分有疑问的用户才会去点击详情链接，结果所有人都点击了查看详情，却无人提交问卷，这就是一个非常失败的案例。
+
+4.选择有限，用户反而更喜欢<br>
+曾经有个这样的实验，一个街边的果酱铺给客户提供了二十多种果酱口味，但只有2%的人愿意购买。大家就觉得奇怪，为什么我们有这么多口味的果酱，却没有人购买呢？
+
+接着，经过尝试后，果酱铺试着只留下六种口味，结果购买率很快提升到了12%，让人震惊，而且在这12%的购买率背后，顾客的愉悦度也大大提升。所以，有时给用户提供有限的选择，用户反而更开心。
+
+### 组织
+
+除了删除之外，还有组织的策略。在组织策略中，需要提到记忆力的7加减2原则。通常，一个人的短时记忆容量为7个事物，记忆力好的可以达到9个，记忆力差的可以记忆5个，所以，我们在构想产品时，要确保一个页面只能保留7个事物。
+
+如果页面中无法只容纳7个事物怎么办？我们可以利用感知分层技术，如图所示，这是某著名电商网站的一个产品页面，从中可见，凡是和钱有关的事项，都标了红色，比如价格、优惠、以旧换新、加入购物车等。这就是组织中的感知分层技术，把相关事物用同样的颜色标记起来。<br>
+<img src="https://static001.geekbang.org/resource/image/95/57/9588721d6278d425a455439537c51857.png" alt="">
+
+那如何证明这个组织规划比较理想呢？最简单的方法是，我们可以把眼睛眯起来再看网页，如果发现网页中的几个分块都比较清楚，就代表规划是比较成功的。
+
+### 隐藏
+
+如果删除和组织还没法解决全部问题，那么可以采用第三个策略隐藏。我们可以把一些不常用，但又必不可少的功能隐藏起来，比如一些选项、偏好等。
+
+我们也可以选择阶段展示，以循序渐进的方法显示功能，比如Mac中的文件保存对话框。还有一种做法是适时出现，比如百度搜索框，用户输入关键字后，它就会将关键字相关的信息展现出来。
+
+你可能会担心用户发现不了隐藏功能？我们只需在关键路径中给出提示与线索就可以，但注意提示要小，保证用户在前进的过程中能够遇到提示，但又不会挡住他们的去路。
+
+我将删除、组织、隐藏这三个策略称为渐进三部曲，首先删除不必要的，其次，组织必须提供的，然后隐藏非核心的。如果这三个策略都不行，还有第四个策略，即转移。
+
+### 转移
+
+转移也有两种方法，第一，设备间转移，比如电商网站的产品，通常会在手机端页面展示较少内容，而在PC端页面展现更多内容。
+
+第二，创造开放式体验，让某些功能具有多种用途，比如大众汽车后备厢上的Logo就具备多种用途，它既是打开后备厢的拉环，又是隐藏倒车雷达摄像头的地方。
+
+## 总结
+
+本期内容中，我主要分享了我在产品决策上的理念和心得，其中的关键点是简单，并分享了简单策略在产品决策中的具体运用，包括删除、组织、隐藏、转移这四个要点，希望对你有用。如果你有不同的见解，欢迎在留言区分享。
+
+感谢你的收听，我们下期再见。
+
+## 作者简介
+
+汤力嘉，一下科技CTO，负责旗下秒拍、小咖秀、一直播等产品的研发及团队管理工作。历任酷6、暴风技术总监，在直播、p2p、视频特效等领域拥具有丰富的行业经验。
+
+

极客时间专栏/geek/技术领导力实战笔记/第11讲 | 最合适的技术才是最有价值的技术.md

@@ -0,0 +1,69 @@
+<audio id="audio" title="第11讲 | 最合适的技术才是最有价值的技术" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/41/99/41e84d7e87f2e479673fb00a164a5e99.mp3"></audio>
+
+很多技术人在最开始工作的时候，都会有一种误解：做技术主要的工作是要和计算机打交道，而不是和人打交道。只要技术足够牛，不用考虑太多其他的事情。但是随着时间的推移，大部分人的看法也有了很大的改变。
+
+好的技术一定是从公司的状况出发，最新的、最先进的技术不一定就是最合适的技术，最合适的技术才是最有价值的技术。作为技术领导者，又该如何去把握呢？我们就这个问题采访了几位技术负责人。
+
+## 花虾金融CEO、前宜人贷CTO 段念：
+
+在我看来，技术本身是为业务支撑服务的，换句话说，技术所有的价值最终都要通过业务结果来呈现的，我不认为技术可以独立于业务之外去体现它的价值。所以从这个意义上来讲，所有对于业务有好处的可能，我们都愿意花时间和精力去尝试。
+
+当然对于技术，我的另一个观点是，所有重复性的事情都应该被具体的程序化的方式所替代。所以我一直试图找到一个平衡，一方面技术是为业务支撑提供服务的，但技术人应该do smart things，应该用聪明的方法做事情，而不只是作为业务的一个实现手段。
+
+一个好的管理者首先应该面向目标，这意味着他不会关注太多范围、界限，而是奔着把这件事情的结果给搞定。所谓目标，可以用简单的整个公司层面的目标来解决，但同时它也需要落地，每一个团队和个人都需要知道自己的目标是什么。这个目标并不是一定要去改变什么，但需要始终在组织中间做一个清晰的传递，让大家都清楚。
+
+另外，面向目标也就意味着整个组织的绩效管理、晋升体系等方面，都需要与之强烈挂钩。
+
+## 融云CTO 、[TGO鲲鹏会](http://tgo.geekbang.org)北京分会董事会成员杨攀：
+
+我在微软有一段工作的经历，微软给团队的定位就是三个角色：产品、研发和测试。但实际上微软的团队模型中，这三个角色是互相交叉的，要求你每个角色都要懂其他角色的东西。在做任何事情的时候，都应该站在其他角色、其他知识领域上去考虑这个问题，当你能做到这样的时候，你在这个团队中就会是一个非常非常优秀的角色。
+
+我觉得优秀的人，都至少能达到：1、能够清楚地认识到什么东西是对的。2、在知道是对的情况下，愿意去把事情做得更好。我是一个特别有洁癖的人，我会要求我的团队在写中英文混杂的东西的时候，按照一定的标准去写。
+
+要了解什么是正确的，认同正确的理念，愿意按正确的理念去做事情。
+
+## 极光推送CTO兼首席科学家 黄鑫：
+
+无论我们是否承认，公司大了就需要划分部门，划分部门就需要有部门管理者，每个管理者一定会为自己的部门争取最大的利益，这个利益不仅仅是金钱层面的利益，还包括可控性、风险性等等。
+
+举例来说，假设我们需要做一个需要多方配合项目，移动端会说我们负责的就是把数据传到后端，各种逻辑转换应该后端来做。后端会说我们负责的就是维持后端架构的稳定性，具体的业务逻辑你们来搞。数据会说你们能不能把数据清理好再传给我，这样我集群压力小。当然，三方都有自己的理由，大家都讨厌业务复杂度，保证技术架构的纯净。很多技术人员避免和其他部门产生过多的联调。这时，能站在中立角度去评估分工合理性的只有CTO。
+
+要做到这一点，那么自然牵引出了两个必备的素质：1、全面的技术能力，不求多深，但是可以听懂不同部门的诉求和技术方案，了解不同方案的技术难度。2、 优秀的沟通能力和说服能力，这一点无需多言。
+
+## 恺英网络的技术支持系统副总裁 伍涛：
+
+除了技术与管理，技术人应该进一步用商业思维武装自己，努力去思考如何帮助公司获取利润、提升市值。新的商业模式几乎都是挖掘出来的，敏锐的商业嗅觉非常重要。
+
+我觉得最厉害的人是有理想的技术人，他们能把技术和商业结合。比如，Microsoft 的 Bill Gates 、Tesla 的 Elon Musk 、Facebook 的 Mark Zuckerberg 、小米的雷军等，那些伟大的公司都是这些有理想的、有技术背景的人创立起来的。
+
+恺英是个小团队作战的公司，所有成功的产品都是靠业绩打出来的，在恺英只要做得好，就可以获得相应的回报。恺英看似低调，其实 2017 年有超过 16 亿元的净利润，能够做到这个业绩的公司并不多。能够取得这样成绩在于团队里有很多有互联网商业头脑的人，他们在思考如何在互联网行业里把握新的机会，机会来了就去做，然后把它迅速变大，成为公司一个新的业务。
+
+## 苏宁云商IT总部执行副总裁、苏宁技术研究院院长 向江旭：
+
+在创业公司，公司的业务需求、生死存亡肯定是首要问题，那技术领导者的思维方式也要把公司的生死存亡放在第一位，不需要考虑太多的系统架构更新。
+
+但在构建系统、提出方案的时候，要跟CEO沟通清楚各个方案的优缺点，比如采取短平快的方式，前半年、一年系统可以支撑，但也许一年后要付出的代价更大，如果到时系统架构重构的话，对业务的冲击可能是现在的10倍。要把那些利弊、短中长期的厉害关系跟大家沟通清楚。
+
+同时，技术领导者还要向CEO展示，技术不仅仅只是业务的支撑，技术还可以引领业务的发展。以电商为例，不是网站不宕机、可以卖货，就是一个好的电商系统，还需要研发大数据等技术，更好的理解用户、精准画像，做精准营销、做技术推送、提高转换率等等，这些都是帮助业务更好发展的。
+
+## [Coding.net](http://Coding.net) CTO 孙宇聪：
+
+如果一个创业公司做不到统一开发环境和研发体系，那么势必会造成我们研发力量的分散。这就是为什么有些公司事儿特别少但人特别多，因为每个人所作的事情都不通用。
+
+完全禁止创新是不可能的。因为作为一个公司、团队必须要尝试新鲜的东西，不然难以进步。如果一个团队老用旧的东西那他就领会不到外界的好处。举一个例子，这就和像园丁打理花园一样，你可以让花随便长，但到了一定时间一定要把长得不好的砍掉，选出其中一种，或者是有限的几种一定要留住的。最终的决定其实并不重要，重要的是要有这样一个决策的过程，以及强有力的执行。
+
+作为 CTO 来说，我的工作就是抵住 CEO 的压力。每周我们要安排一些产品上的事情，也要留出一段时间来做架构上的整理，改进，统一。我需要给程序员们留出时间，创造条件来做这些长远的事情。 只要把程序员聚到一起，他们自然而然就会产生出很好的想法来，然后再把这些好的想法推广出去。
+
+## 欧电云创始人 韩军：
+
+作为公司的技术一把手，CTO一定要把握行业趋势，我觉得在行业内去看技术可能更好一些，因为对行业理解得越深，实际上你解决How的问题的能力就越高。你最好在某一个领域达到专家级的水准，这对你往水平方向扩展有很大的帮助，因为很多的方法论都是相似的，你其实可以用在一个领域的深度去做一些思考，这对你有非常大的帮助。
+
+其次是要从客户角度思考。这是非常难的一件事儿，一是因为你的客户有很多种，如高层老板、产品经理、开发人员等；二是你还要满足客户的客户，最终的用户才是产品最终有价值的东西，不是说今天满足客户就OK了，我还要满足其他用户的需求，这个难度就非常高，不是简单的说今天了解我的一个客户、一个想法就OK了，其实没有那么简单。
+
+还要从业务角度思考。我们发现很多技术人员和业务人员的沟通经常是鸡同鸭讲，完全不在同一个沟通线。技术人员理解之后出来的东西不是业务人员想要的，再做一遍又不是想要的。很多时候因为没有同样的思维逻辑，大家其实是很难沟通的，所以作为公司技术的一把手一定要有业务思维。
+
+## 结语
+
+以上就是几位技术领导者对于技术部门在整个公司的定位的理解，哪些观点与你不谋而合，又有哪些观点是你之前没有想过的？欢迎留言与我们探讨。
+
+

极客时间专栏/geek/技术领导力实战笔记/第120讲 | 刘俊强：必知绩效管理知识之绩效数据收集（上）.md

@@ -0,0 +1,65 @@
+<audio id="audio" title="第120讲 | 刘俊强：必知绩效管理知识之绩效数据收集（上）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/12/43/12e145785c268f94b56a3c2d1a376443.mp3"></audio>
+
+你好，我是腾讯云资深架构师、TGO鲲鹏会会员刘俊强，有着8年以上的技术管理经验，今天想跟你分享技术管理者必知的绩效管理知识之绩效数据收集。绩效数据收集是科学绩效考核的前提，那么在实际的执行中，我们需要收集哪些数据，这些数据的来源分别是怎样的呢？
+
+## 绩效评定不是一次性事件
+
+我在之前同系列的《绩效管理循环》一文中分享过，绩效管理是一个周期内持续循环的过程，包括绩效目标制定、绩效辅导，以及绩效评定与反馈三个阶段。
+
+不少管理者往往会忽视整个循环周期，直接在绩效评定与反馈阶段开始绩效管理工作，并将绩效评定看作是一次性事件，除非是在正式的评定考核阶段，否则他们不会进行绩效评定相关的工作。这是极为错误的做法，也是导致管理者认为绩效评定非常困难的主要原因。
+
+在实际执行中，绩效管理循环中的第二个阶段绩效辅导，是时间最长并且非常重要的阶段。
+
+成功的管理者应该主动地在这个阶段找到自己的方式来检视团队成员的表现。这样，在进行绩效评定、绩效考核阶段时，会减少管理者因认知偏见对绩效结果产生的影响。
+
+有些客观事实是管理者必须了解的：
+
+第一个事实是管理者的记忆力会变差，通常而言人类的记忆并不可靠，我们越忙越成功，大脑接收的数据就越多。随着时间的推移，回忆事情会变得很困难，特别是绩效评定通常需要以月为单位来看团队成员的绩效表现，因此，如果在绩效评定考核阶段仅通过回忆来进行评定，会造成极大的偏差。
+
+第二个事实是系列位置效应，系列位置效应（Serial-position Effect）是一种心理学现象，指人们倾向于对首先见到的事物和最后见到的事物有更好的印象，分为首因效应（Primacy Effect）和近因效应（Recency Effect）。
+
+首因效应也被称为第一印象作用，或先入为主效应，是指在行为过程中，最先接触的事物会给人们留下深刻的感知或认知，进而影响人们对事物的感知和判断。近因效应指在行为过程中，对事物的最近一次接触会给人留下深刻的感知或认知，能对首因效应所形成的心理认知起到巩固、维持、否定、修改或调整等作用。两种效应在记忆过程中的影响如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/dc/f3/dc3d520ce208f09c53ceab6eebef81f3.jpg" alt="">
+
+怎么来理解系列位置效应呢？试想你去听一个分享，在分享开始阶段提供的信息会比后来提供的信息更容易被记住，这就是首因效应；另外，分享临近结束时的信息也更容易被记住，这就是近因效应。在绩效评估方面也会有类似的问题，团队成员给你留下的第一印象和他最近的表现更容易让你记忆，因此会产生绩效评定的偏差。
+
+第三个事实是晕轮效应（Halo Effect），是指人们对他人的认知首先依据初步印象，然后再从这个印象推论出认知对象的其他特质。例如你喜欢或不喜欢某位员工，可能对你如何评估该员工的工作表现产生强烈影响。你越喜欢或越不喜欢某位员工，就越难以清楚地看到现实。简而言之，就是以偏概全。
+
+以上介绍了三种认知陷阱，分别是不可靠的记忆力、首因效应和近因效应，以及晕轮效应。介绍这几种认知陷阱是为了让管理者了解它们，不让它们给绩效评定带来不必要的麻烦。
+
+管理者避免以上认知陷阱的最佳实践是，使用“绩效表现记录本”来记录自己对团队和团队成员绩效表现的持续观察，可以是物理上的笔记本，也可以是数字化文件，或者两者皆有也是可以的。
+
+在记录中需要清晰地记录日期、员工姓名和表现情况，每周至少1-2次。当然，每次记录也不用太复杂，例如，8月9日，张三提前完成了某项功能的编码实现工作，使得测试同学可以提前介入进行集成测试，一条记录可能仅需要花费管理者10秒左右的时间。
+
+作为管理者，我们应该花时间做好“绩效表现记录本”的使用，记录团队和团队成员的当前表现，并观察总结其表现趋势。
+
+这样，一方面在阶段二绩效辅导阶段，管理者能够有效地帮助团队成员进行提升，另一方面，通过多次的数据记录，管理者的评估就可以尽可能地贴近事实真相，可以保证在阶段三绩效评定考核时，不会给管理者和员工带来过大的压力，因为“绩效表现记录本”已经能够尽量客观的反映事实情况了。
+
+## 员工绩效评估的数据来源
+
+任何绩效评定考核过程的基础，都是收集和评估有关员工的绩效数据。不论使用何种方法或工具来收集数据，都需要确保它们具备有效性、可靠性和相关性这三个特性。
+
+有效性意味着评估该评估的事项，可靠性意味着标准是持续一致的，相关性则意味着必须跟工作表现相关。在我们开始做绩效数据收集前，有这方面的专家来协助是最好不过了，通常这样的专家来自于公司人力资源部门中负责绩效的团队。
+
+在实际执行中，我们对员工进行绩效评定考核时，通常会从三个主要方面进行评估，分别是特质、行为和结果。首先是特质，这里的特质是指一个人的性格或态度，那么问题是，我们是否可以衡量一个人的人格特质，并认为它们是有效且可靠的工作绩效指标呢？答案是，很难。但是在实践中，特质还是会被用来评估，例如，是否表现出热情、有责任心等。
+
+接下来我们来看行为，是指人们说和做的事情，它们是可观察的，因此和特质相比，行为往往更可靠，基于行为做绩效评估会比基于特质进行评估更为公正和公平。最后，我们聊下结果，是指员工已达到或未能达到的结果，例如，销售数据、项目完成情况等。与行为类似，结果通常被认为是可靠且有效的，而且员工往往也认同以结果为衡量标准是公平的。
+
+那么问题来了，管理者到底应该怎么独立评估这几个方面呢？其实都有据可依，在实践中，特征和行为的度量评估一般与胜任力模型相关，而结果的度量评估则与目标制定过程和后续工作内容相关。
+
+此外，在明确了这三个方面的独立评估方式后，管理者要去哪里收集这些数据呢？这些数据的主要来源是公司记录如考勤数据，员工提供的自评以及作为管理者你的评定记录等，当然有些公司还会用上360度评估和客户评价，以上这些数据来源都可用于对特质、行为和结果三个方面的数据收集。
+
+在实际的数据收集和分析中，管理者一般会用到李克特量表、行为锚定量表以及行为观察量表这三种常见的工具和方法。这些方法各有利弊，受限于篇幅，我将在下篇文章中具体分享这三种工具和方法的利弊、使用方法和实践案例，欢迎持续关注。
+
+这里要说明的是，管理者需要根据自己公司业务和团队的实际情况来选择合适的数据收集和分析工具，并依此设计一套相匹配的绩效评估系统，这样的系统才能正确地衡量绩效并激励团队成员。
+
+最后给你留一个小问题，目前你在团队管理中使用的绩效评估系统是怎样的，数据来源又跟哪些方面相关呢？欢迎在留言区分享。
+
+感谢你的收听，我们下期再见！
+
+## 作者简介
+
+刘俊强（微信公众号：程序员精进），TGO鲲鹏会会员，现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+年以上互联网开发经验，8年以上技术管理经验。
+
+

极客时间专栏/geek/技术领导力实战笔记/第121讲 | 刘俊强：必知绩效管理知识之绩效数据收集（下）.md

@@ -0,0 +1,80 @@
+<audio id="audio" title="第121讲 | 刘俊强：必知绩效管理知识之绩效数据收集（下）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d7/9d/d7632cb96dc42f6c0850cbc83929e69d.mp3"></audio>
+
+你好，我是腾讯云资深架构师、TGO鲲鹏会会员刘俊强，有着8年以上的技术管理经验，今天想跟你分享的依旧是技术管理者必知的绩效管理知识中绩效数据收集相关的内容。
+
+在上一篇文章中，我们谈到任何绩效评定考核的基础，都是收集和评估有关员工的绩效数据，而在实际执行中，我们通常会从三个主要方面对员工进行评估，分别是特质、行为和结果。另外还聊了绩效数据的来源，如公司记录、员工自评、管理者评价等，在本文中，我们将聊聊数据收集常见的工具和方法，以及这些工具之间的优劣比较。
+
+## 数据收集工具和方法
+
+不得不承认的是，在数据收集中没有完美的工具或方法，目前有几种工具或方法被大家普遍采用，我们接下来会简单介绍。
+
+首先介绍的是评定量表，评定量表在绩效评估系统中占主导地位。评定量表会为评估者提供维度列表，每个维度代表员工有效的评估方面，例如特质、行为或结果等，每个维度都有对应的评分，通常是五分制或七分制。评定为正面的时候，可以是“表现优异”、“超出预期”等，评定为负面的时候，可以是“不合格”、“待改进”等，而评定为中性的时候，可以是“符合预期”。通常这类方法被称为李克特量表（Likert Scaling），以下是一个李克特量表示例：
+
+<img src="https://static001.geekbang.org/resource/image/ce/6a/cefe44a8d94862ea9f38a0cfcd0dfe6a.png" alt="">
+
+一个常见的李克特量表版绩效考核表会包括工作数量、工作质量、团队合作以及态度等评估维度。李克特量表易于使用且开发成本很低，因此被大量采用，但是李克特量表也存在明显的问题，这些问题也存在于其他类型的评定量表之中。
+
+首先，评定量表没有提供可以操作的反馈，例如，在衡量积极是否态度的条目上，五分制中的三分只是告诉该员工的表现符合预期，但没有告诉他们该做哪些改进。这里的评分仅仅是一般性的反馈，如果能提供具体的改进反馈会对员工更有帮助。再者，李克特量表和其它评定量表都存在着准确性问题，这源于评估者可以轻松地以不同的方式来解释评分，例如，中间值对不同人的意义就是不一样的。
+
+为了克服这些问题，人们后来开发出来了行为锚定量表，简称为 BARS（Behaviorally Anchored Rating Scales）。使用 BARS 时评估者仍然会对员工进行多个维度的评分，但不同之处在于 BARS 会呈现不同级别表现的特定工作行为，而不是简单的使用量表的数字和形容词。以下是一个使用 BARS 的示例表：
+
+<img src="https://static001.geekbang.org/resource/image/4d/16/4dba1d9987d4ff543548b8b7e8b64c16.png" alt="">
+
+这个例子是对员工沟通能力的考核，并将考核拆分成了三个维度，分别是：<br>
+展示有效的书面和口头沟通技巧；<br>
+沟通清晰，知识渊博；<br>
+与他人共享信息。<br>
+每个维度又被划分出5个不同的评价等级，分别是不合格、待改进、符合预期、超出预期和表现优异，BARS的不同之处就在于给每个评价等级都规定了特定的行为表现。
+
+以“展示有效的书面和口头沟通技巧”这个考核维度为例：<br>
+不合格的行为表现是，报告或文档写得不清楚、过于简单；<br>
+待改进的行为表现是，书面和口头技能需要加强，经常混乱；<br>
+符合预期的行为表现是，写作和说话清楚，有说服力，简明扼要；<br>
+超出预期的行为表现是，书面和口头沟通始终清晰，有说服力，适合受众；<br>
+表现优异的行为表现是，书面和口头沟通都是最高水平的，明确，准确，有说服力，并专注于特定个人和团体的需求。
+
+可以看出，相较于李克特量表，行为锚定量表BARS有着明显的进步，但它也有一些限制或不足。首先，跟简单的李克特量表相比，构建有效的行为锚定量表要困难得多。其次，虽然行为锚定量表确实向员工提供了更多可操作的反馈，但却不能因此就证明 BARS 是衡量绩效的一种更好的方法。
+
+除了李克特量表和行为锚定量表外，目前还有一种评定量表也在被广泛使用，即行为观察量表（Behavioral Observation Scale），简称 BOS 。
+
+使用行为观察量表时，管理者会先针对各项评估指标给出一系列有关的有效行为，然后将观察到的员工行为同评价标准相比较进行评分，看该行为出现的次数频率。
+
+行为观察量表具体指出了员工需要什么样的行为才能获得高绩效得分，管理者也可以根据行为量表去匹配员工行为，并用具体的行为条件给出反馈，这样员工便能知道哪些事情正确，哪些行为需要矫正。以下是一个使用 BOS 的示例表：
+
+<img src="https://static001.geekbang.org/resource/image/8e/73/8e24294e3fa3d377cf10d71daada1c73.png" alt="">
+
+当我们介绍完行为锚定量表 BARS 和行为观察量表 BOS 后，就不难理解为什么人们会喜欢李克特量表这样的简单方法了，因为前两者都需要管理者和专家进行专门研发。
+
+介绍了三种工具和方法后，接下来咱们简单比较一下这三种工具和方法：
+
+<img src="https://static001.geekbang.org/resource/image/34/d8/34adb7571b7b286f7bc0939b387c6ed8.png" alt="">
+
+我会从评价的客观性、量表开发成本、评定结果的反馈性、评估者的易用性及其他这五个维度来比较。
+
+可以看出，在评价的客观性方面，李克特量表比较主观，而行为锚定量表和行为观察量表都相对更为客观。在量表开发成本方面，李克特量表的开发成本较低，而行为锚定量表和行为观察量表的开发成本都较高。
+
+在评定结果的反馈性方面，李克特量表的反馈不明确，无法帮助员工更好的发展，而行为锚定量表和行为观察量表的反馈都比较明确，员工可以根据反馈有针对性的改进并提升自己。
+
+在评估者的易用性方面，李克特量表比较简单易用，而行为锚定量表和行为观察量表都需要持续记录员工行为，耗时较多，其中行为观察量表除了耗时多外，需要评估的题目也多，更耗精力。
+
+除此之外，李克特量表容易产生过宽、过严的问题，还容易产生晕轮效应偏差，而行为锚定量表则容易出现不同评估者之间一致性较高的问题。
+
+可以看出，各种工具方法各有利弊，正如前面说的没有完美的工具或方法，都需要管理者根据自己公司的实际情况进行选用和开发。
+
+下面附上我们之前结合行为观察量表和李克特量表制作的绩效考核表，供大家参考。由于每家公司的工作内容都不一样，这里仅放出针对员工特质的考核部分示例：
+
+<img src="https://static001.geekbang.org/resource/image/c6/47/c6424220e0201e9b1b53dcd85fe83747.png" alt="">
+
+## 总结
+
+本文我们介绍了三种常见的绩效数据收集的工具和方法，分别是李克特量表、行为锚定量表以及行为观察量表，这三种工具和方法各有利弊，还请大家按需研发选用。
+
+最后想跟大家探讨下，目前你正在使用的绩效数据收集工具是怎样的呢，对比本文提到的工具和方法有何异同？欢迎在留言区分享～
+
+感谢你的收听，我们下期再见！
+
+## 作者简介
+
+刘俊强（微信公众号：程序员精进），TGO鲲鹏会会员，现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+年以上互联网开发经验，8年以上技术管理经验。
+
+

极客时间专栏/geek/技术领导力实战笔记/第122讲 | 黄伟坚：创业中那些永远回避不了的问题.md

@@ -0,0 +1,87 @@
+<audio id="audio" title="第122讲 | 黄伟坚：创业中那些永远回避不了的问题" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/72/81/726ea05df716bfe7ebf97fadd4818681.mp3"></audio>
+
+你好，我是Mobvista联合创始人黄伟坚，Mobvista成立于2013年，是一家第三方移动价值发现平台，专注于为国内外的品牌广告商和移动开发者提供获客、变现及移动分析服务和解决方案。
+
+在2013年到2017年这短短四年内，公司经历了裂变式增长，团队从4人扩张为500人，营收从5千万增长到20亿，翻了40倍，点击量从每天1千万增长到每天四个亿。这些数据其实也超乎了我们的意料，我们用四年时间快速经历了一般创业公司需要走10年甚至更久的路程，这些经历给予了我们很多思考。今天，我将这些经验与思考分享给你，希望与你共同探讨创业之道。
+
+## 什么是最重要的事情
+
+对于初创团队来说，总会遇到各种各样的问题，那什么才是最重要的事情？什么问题才值得你花费最多的时间与精力去解决？有没有一个办法，可以解决创业过程中遇到的所有问题呢？
+
+我的答案非常简单，只有两个字——增长。增长可以解决创业公司在发展过程中遇到的所有问题。为什么？因为增长是公司发展的主要矛盾，解决了主要矛盾，其他问题都会迎刃而解。反之，如果公司一直存在这个主要矛盾，那其他问题也将得不到根本解决。
+
+在此以员工离职问题为例，员工离职有两个主要因素，一是对收入或物质回报不满，二是得不到足够的成长空间，或觉得学到的内容有限。而之所以公司快速增长可以解决这个问题，原因有二：一是公司在快速增长，对员工的物质回报一定不成问题；二是公司在快速增长的过程中，业务在推动所有人向前走，迫使个人快速成长。如此，员工在两方面都能得到极大的满足，离职率也就会极大地降低。
+
+讲到这里，你可能会问如何做到增长？对此，我用两个词来概括答案。
+
+第一个词是时机，在合适的时间节点做有潜力的市场。以移动广告行业为例，2013年，智能手机的普及进入爆发期，移动广告迎来流量红利。同时，国内的移动互联网巨头，或一些中型企业，迫于新一轮的增长需要，纷纷布局海外。我们看准时机，帮助国内的移动互联网公司出海，在海外推广他们的产品。可以说这是移动时代赋予的一个历史机遇，正是在这样的历史背景下，我们才实现了裂变式增长。
+
+第二个词是团队，所谓“独行者速，众行者远”，意思是一个人可以走的很快，但是，要走的远，就需要一个团队，所以在任何时候强调团队的重要性都不为过。这个世界上，在同一时间跟你做同一件事的人有很多，也不只你一个团队，为什么你能脱颖而出？本质上取决于你的团队是否足够强大高效。
+
+如果时机与团队这两个词不够详细，我还可以再用四个词来阐述创业。
+
+1. 需求，创业前你要找到市场需求、用户需求；
+1. 产品，你要用产品手段去解决用户的痛点与需求；
+1. 技术，通过技术手段优化产品，提升运营效率；
+1. 运营，通过数字化运营，优化产品，同时根据产品的数据反馈，优化运营效率。
+
+如果这四个词还不够详细，我可以再送你八个词，分别是战略、战术、融资、产品、研发、管理、营销和财务。如果你觉得还不够详细呢，我可以再送你十六个词，但如果你需要用到十六个词去解释创业，那你就该重新考虑自己是否适合创业了。
+
+总的来说，关于创业，你只需记住增长这个关键词就行了。
+
+## 创业过程中难以避免的问题
+
+在创业过程中，有些问题，我们永远回避不了，有些坑即使你知道也不得不再去踩一遍，因为你只有交了这笔学费，才能真正成长。今天我会主要分享三个方向的问题，即有关人的问题、部门协作的问题和激励的问题。
+
+### 一、有关人的问题
+
+与人相关的问题，是最难解决的，因为它不像工程，会得到精确的解。那怎样解决有关人的问题呢？我有两条原则：
+
+第一，不要因为人的问题而调整组织架构。<br>
+比如某员工在某部门与同事或上级关系不好，影响了业务，但他的能力又挺不错，这时你可能认为只是把他放错了位置，调到其他部门就好了。其实，这个动作非常危险。因为在公司规模较小的情况下，即使把他调去别的部门，他与原部门的不和谐关系依然存在，并且这种负面因素可能会在整个公司内传播。另外，因为你没有从根本上找到原因解决他原来的问题，这时调换部门，反而可能会将问题带入新的部门，为自己埋坑。
+
+我认为是否调整组织架构，只有一个判断标准，就是业务，你应该根据业务来调整组织架构，而不是因为个人。
+
+第二，尽早解聘不合适的员工。<br>
+很多做技术的人都会比较心软，对于那些不符合要求的人，你可能认为可以再给他一些时间，再多给他一次机会，就能解决问题。但我想说的是，只要你作出解聘决定，你会觉得，为什么我不早点做这件事！因为解聘不合适的员工是一件绝对不会让你后悔的事情，它会让你的管理负担变轻，收拾烂摊子的机会也会变少，你会感觉“真好”！
+
+### 二、部门协作的问题
+
+技术团队通常会面对多个部门的夹击，比如商务、运营、产品等，非常容易产生矛盾。而这种内部摩擦很难避免，也是互联网行业普遍存在的矛盾，所以关键在于如何减少摩擦，做好跨部门协作，提升工作效率，一般可以遵循三个原则
+
+1.主动汇报<br>
+比如主动汇报项目进度，假设客户要求你在一小时内导完数据，但当你做到一半，预估一个小时可能完不成时，你可以主动跟客户沟通，按照目前的进度，一个小时无法完成任务，可能需要一个半小时。当客户能得到及时反馈时，即使你最后超时完成工作，他也会理解你的难处，不会太过生气。
+
+所以要主动汇报项目进度，及时反馈问题，而不是等你做完了再解释缘由，尤其是项目时间较长时，及时汇报特别重要，能有效减少摩擦。
+
+其实，有时对方问你什么时候能做完，真正目的可能并不是要求你必须在某个时间内完成，而是他想知道一个时间点，让自己心里有底，方便他安排项目进度和其他工作。
+
+2.充分沟通<br>
+跨部门之间的沟通很重要，许多问题都是由沟通不足引起的，如果双方能在信息透明的情况下，沟通顺畅，误解就会大大减少。因此，我经常会同商务、运营等部门的负责人直接沟通，了解双方的工作事项及进度，自上而下倡导沟通的氛围。
+
+3.参加对方部门的会议<br>
+我非常鼓励部门leader或部门核心人员去参加协作部门的核心会议，比如他们某个项目的milestone会议。从会议中你可以了解他们目前的项目进度，以及遇到的困难，方便技术做一些预见性的准备，另外，这也是一个加强沟通的过程。
+
+### 三、激励的问题
+
+这是一个老生常谈的话题，但又非常重要。激励机制又可以看作是反馈机制，它能让每个人认识到自己做的好与不好，方向是否正确，又有哪些待改进的地方等等。
+
+那如何做好激励呢？除了常见的规则以外，我们还做了以下四方面的事情：
+
+1.制定阶段性任务，完成每个阶段任务，员工都会得到相应的荣誉奖励。
+
+2.偶尔超预期鼓励，以年终奖为例，我们通常会在年初制定年度目标，比如收入指标要达到40个亿，如果完成目标，每个部门能得到什么样的奖励。而实际到年底奖励的时候，我们给予的会远远超出年初制定的激励目标，超出员工的预期，这样才会起到激励作用。
+
+3.针对技术部门，我们会经常举办各种各样的活动来激发他们的荣誉感和归属感，如评比技术之星、技术创新奖、最佳新人等等。
+
+4.反向激励，比如对于每一次线上事故，我们都会评级，从P0到P5，P0的严重程度最高。一旦出现P0事故，从CTO一直到责任人，自上而下全部要罚，并且进行公示。当然，罚钱不是最重要的，目的是给大家传递一个态度，即线上问题不是小事，大家必须要重视。
+
+## 小结
+
+创业中解决问题最好的办法就是实现增长，而创业是一个漫长而艰辛的过程，总会遇到各种各样无法回避的问题，比如人员问题、协作问题、工作效率问题等等，今天，我所分享的内容都是基于我们在创业过程中遇到的具体问题，而提炼出的一些思考，希望能对你产生价值。
+
+## 作者简介
+
+黄伟坚，Mobvista联合创始人，TGO鲲鹏会会员，从0到1，经历公司裂变式增长，从初创公司成长为为亚洲最大的移动广告平台。曾负责公司整体技术架构规划、研发团队和研发体系搭建、运维自动化等工作，在高并发、大数据处理方面有丰富实战经验。
+
+

极客时间专栏/geek/技术领导力实战笔记/第123讲 | 黄伟坚：用系统性思维看待创业.md

@@ -0,0 +1,51 @@
+<audio id="audio" title="第123讲 | 黄伟坚：用系统性思维看待创业" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/24/69/244623f2f64f58dfe57096c0fcc8d969.mp3"></audio>
+
+你好，我是Mobvista联合创始人黄伟坚。在上一篇文章中，我谈到了我对创业的看法，在我看来，对于创业团队来讲，最重要的事情就是增长。增长可以解决创业公司在发展过程中遇到的所有问题。
+
+如果展开来讲，我们可以用四个词来概括创业，就是需求、产品、技术和运营，再展开用八个词来概括的话，就是战略、战术、融资、产品、研发、管理、营销和财务。
+
+可以看到，创业是一个系统工程，创业过程中面对的问题成百上千，而且纷繁交错，我们不可能通过控制一个单一的变量或因素来掌控整个创业系统，这是不现实的。所以就要求我们用系统性思维去看待创业。
+
+## 如何用系统性思维看待创业
+
+自然界中的生态系统是一个非常好的类比。众所周知，生态系统有非常强的自我适应、自我修复、自我进化的能力。那有没有一种可能，公司也可以像生态系统一样，在外部与内部不断变化的条件和环境中，不断适应与进化呢？我们可以向自然界的生态系统学习一些基础而核心的原则，从中得到启发。
+
+进化论中有三个核心原则，一是生物的多样性；二是遗传变异；三是物尽天择，适者生存。在这三者中，生物的多样性为遗传变异提供了来源与物质基础，而遗传变异提供了进化的方向，物尽天择，适者生存。这是竞争，通过竞争，适合的物种就能留下。
+
+那如何将这三个核心原则内化为指导我们创业的具体行动指南呢？
+
+首先，保持多样性，我们非常强调团队的多样性和包容性，因为只有多样性的团队，才有可能产生化学反应，发生变异。所谓多样性团队是来自不同专业，有着不同性格、不同理念、不同文化的一群人在一起。在技术团队中，如果大家理念极度一致，讨论时无人发表意见，一团和气，是非常危险的现象。
+
+我们鼓励冲突，接受不同观念，只有这样，才能碰撞出新的想法，才能产生遗传变异的基础。所以在组建团队方面我们一直强调，包容不同的声音，只要他没有违反公司红线，业绩又能达到要求，我们就可以包容。比如，有些管理者觉得上班刷知乎、刷微博不可容忍，但我们某位高管就经常这样做，可他的表现都是超预期的，所以我们对这种事情特别容忍。
+
+其次，打造开放系统，热力学中有个定律，一个封闭的系统，它的熵是永远在增加的，而且不可逆，最终导致整个系统崩溃。一个系统只有通过能量交换，不断从外部引入能量进行负熵，才能保持系统的活力。
+
+公司也一样，需要源源不断的从外部接入信息，对于一家创业公司来说，持续不断的接收外部信息非常重要。不仅创始团队、核心团队需要走出去，多跟外部交流，多从外部获取信息，我们也鼓励基层到中层的员工走出去，让他们面向市场，了解客户，了解竞争对手，了解行业上游与下游，甚至是更多的跨界信息。
+
+除了上面提到的鼓励员工走出去外，我们还会在机制上做一些事情，比如定期举办中层管理会议，而这样的会议一般都是在公司之外举行，比如在度假村，请内部讲师、外部讲师，甚至同行来做分享，给我们输入信息。同样，我们也有针对初入职员工的星星之火培训，诸如此类，通过各种各样的手段给公司进行信息的输入。
+
+再次，远离平衡态，很多公司发展到比较大的规模后，可能会追求一种状态，就是公司的流程规章制度都在掌握之中，所有人都要按照规章制度办事，不出疏漏，每个人的绩效都可以被精确衡量，一切都在自己的掌控中。
+
+之所以如此，是因为控制可以给人一种安全感，但事实上，越追求控制，越追求稳定，就越会给公司增加各种各样条条框框的约束，反而导致公司活力下降。
+
+因为，当一个系统处于稳定状态时，它的能量是在最低点的，而当系统处于不稳定状态时，它的能量才处在最高点，所以我想讲的是，公司尤其是初创公司，每天都会面对各种各样的问题，这是常态，一旦你感觉进入掌控状态，一切都尽在掌握，才是可能出现危险的时候。
+
+最后讲讲竞争机制，在自然界中，物尽天择，适者生存，商业社会也是一样，竞争是人类进步的动力之一。
+
+对于一家公司来讲，除了面临外部竞争以外，内部竞争也是不可避免的。比如，腾讯就有内部竞争的传统，甚至将其当做是提升产品体验的一个重要方式，微信的诞生就是内部竞争的结果。再比如网易，网易游戏的创新机制中很重要的一个就是滚动研发机制，多个团队同时进行上百款游戏研发，然后密集的进行各类阶段性评估，竞争最终的上线机会。
+
+可以说，危机意识是每个企业员工，尤其是领导人应该保持的基本状态，我们可以刻意在内部引入竞争机制，让不同的团队竞争同一个项目。即便没有因为项目竞争的情况，我们也要刻意在公司内，通过各种管理机制营造竞争氛围，如绩效考核、末位淘汰等。除此之外，我们还可以适度引入外部新鲜血液，刺激团队内部的竞争氛围，起到“鲶鱼效应”的作用。
+
+当然，需要注意的是，我们要把内部的良性冲突控制在一定的范围之内，而不是简单的让内部团队形成对立冲突面，最终反而影响到团队间的工作配合和效率，整体的团队氛围和文化。
+
+## 写在最后
+
+创业至今，经历公司从0到1的裂变式增长，遇到了很多问题，也踩过很多坑，最大的感悟就是，创业是一个系统工程，一定要用系统性思维去看待创业。
+
+在实践中，我们可以借鉴自然界生态系统中的一些核心原则，如保持多样性和包容性、打造开放系统、远离平衡态、打造竞争机制等，将公司构建成像自然界中生态系统一样，拥有非常强的自我适应、自我修复、自我进化的能力，来不断适应当今愈发多变的互联网行业。
+
+## 作者简介
+
+黄伟坚，Mobvista联合创始人，TGO鲲鹏会会员，从0到1，经历公司裂变式增长，从初创公司成长为为亚洲最大的移动广告平台。曾负责公司整体技术架构规划、研发团队和研发体系搭建、运维自动化等工作，在高并发、大数据处理方面有丰富实战经验。<br>
+&nbsp;<br>
+&nbsp;

极客时间专栏/geek/技术领导力实战笔记/第124讲 | 刘俊强：必知绩效管理知识之评定绩效.md

@@ -0,0 +1,65 @@
+<audio id="audio" title="第124讲 | 刘俊强：必知绩效管理知识之评定绩效" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e1/d1/e11488c561d9864159fa584bba843fd1.mp3"></audio>
+
+你好，我是腾讯云资深架构师、TGO鲲鹏会会员刘俊强，有着8年以上的技术管理经验，今天想跟你分享技术管理者必知的绩效管理知识之评定绩效。作为管理者而言，绩效评定这个过程是非常关键、非常重要的，我们先了解下绩效评定的具体流程是怎样的，然后再介绍如何撰写绩效评价。
+
+## 绩效评定流程
+
+在我们开始绩效评定之前，需要先对整个绩效评定流程作出一个合理的时间安排。可能对于大公司的管理者而言，人力部门会帮你制定时间表，并按时提醒进度。但如果公司规模较小的话，可能就需要管理者自己创建和控制流程。
+
+那怎么制定绩效评定流程呢？下面我们先了解下绩效评定阶段的工作顺序，并对相关工作内容进行梳理，以便我们能够清晰地掌握绩效评定流程的各个方面。
+
+绩效评定阶段的最后一项，是在截止日期前将所有评定结果反馈给人力资源部门，因此，我们首先要确定反馈给人力资源部门的截止日期，进而反推绩效评定流程中各项工作的完成时间。从我过往的经验来看，一般整个绩效评估流程大约需要6周的时间。
+
+第一周，在整个流程开始前，需要管理者将时间表及考评流程同步给员工，以便员工对接下来参与考评流程一事做好准备。这里的同步方式可以是正式邮件结合非正式会议的方式，如果某些员工没弄清楚考评流程的话，还需要管理者对其进行单独的沟通辅导。
+
+第二周到第三周，员工进行自我评估。每个公司情况不一样，可以是Word、Excel文档也可以通过在线系统进行提交。当然，如果有条件的话，更建议采用在线系统，方便日后追溯和员工培养。有些公司还会采用同事间互评的方式，并将结果作为绩效参考，这里我们对采用的数据来源不做更多的评判，还是以阐述绩效评定阶段的流程为主。
+
+在这个时候，管理者需要根据之前文章中介绍过的绩效数据收集方法，拿出之前收集到的数据，以便对各个员工在绩效管理循环中的第二个阶段——绩效辅导阶段中的表现情况有清晰的认识，尽量避免认知偏差带来的不公平问题。这里我附上一个绩效评定示例表，以供大家参考。
+
+<img src="https://static001.geekbang.org/resource/image/1a/17/1a72d24916e726194a76908bf8842417.jpg" alt="">
+
+第四周到第五周，管理者需要对自己管辖的团队和员工进行绩效评定，并撰写绩效评估的评语，怎么撰写评语我将在本文的第二部分详细介绍，这里就不再展开了。
+
+在这个阶段，管理者需要根据之前确定的绩效目标以及收集到的数据，包括员工的自我评价、绩效目标的完成情况以及日常的行为表现记录等等，根据这些记录及数据来进行绩效考核表的填写。假设以上表为例，其中的上级评语和改进意见是最为重要的部分。
+
+另外，管理者做完绩效评定后，接下来需要安排自己的时间，在第六周的时候与团队员工进行绩效面谈。确认好时间后，建议使用日程管理工具管理好日程，并且也要确认被评估员工的时间，让员工能准时参加一对一的绩效面谈会议。
+
+至于会议时长，我建议跟每次都安排一个小时的时间，可能实际用不了这么长的时间，但这样预留安排时间的好处有两点，一是不要让员工觉得你很着急结束跟他的绩效面谈，这样正式的沟通机会对员工来说是难得的机会；二是如果能提前完成面谈，你还能够花这些时间去处理其他日常工作和可能出现的紧急事务等，并不会浪费。
+
+另外在与员工进行绩效沟通时，一个实践经验是，先从他们最近的绩效表现开始聊起，然后整体回顾该员工的表现。另外，管理者在与每位员工进行绩效沟通前，需要至少将该员工的整体信息看两遍，不要让员工觉得你不了解他们的实际情况，否则他们会怀疑绩效评定的准确性和公平性。
+
+第六周，将最终结果和绩效面谈后的员工反馈等信息整理后提交给人力资源的同事，至此，整个绩效评定流程正式完结。
+
+## 撰写绩效评价
+
+前面我们介绍了绩效评定的整个流程和时间周期安排，现在是时候聊聊如何写绩效评语了。之前有介绍过，管理者至少使用一周的时间来进行绩效评语的撰写，建议时间是一周至两周的时间。
+
+为什么需要这么长的时间呢？因为管理者需要对员工在整个绩效周期里的表现进行评分，同时还要撰写相应的绩效评语和改进意见，所以完整回顾员工的整体表现是十分重要的，也就需要多花些时间反复斟酌。因此，我会建议，每个员工，管理者都至少花费一至二个小时的时间来撰写他们的绩效评语。
+
+接下来我们聊聊撰写绩效评价的一些策略，大多数管理者会首先填写量化考核的部分，但是我并不建议这样做，相反我会建议先从叙述性、陈述性的部分开始，例如绩效评语及改进建议等。原因在于这样做能够强迫管理者在没有详细数据支持的情况下，来思考员工在绩效周期内的表现情况，并回想起他们具体的突出行为例子。可以说，从陈述性的部分开始撰写，能够很好地帮助管理者回忆起员工的表现。
+
+在完成陈述部分的草稿之后，是时候填充量化考核部分了，管理者需要根据之前收集到的数据，对每个考核项的完成情况进行分数评定。接着还需要拿出员工自我评价、同事互评等信息，看是否需要对之前的评分作出调整。
+
+这里需要记住的原则是，一般情况下你最初的评定是你最诚实的评定，绩效评定的目标是提供公平的评估，而不仅仅是个人评估或他人对该员工的评估。
+
+在完成量化评定部分后，这时你可以回到叙述性评语这块，看看量化评定跟你之前填写的叙述性评语间的差异。管理者需要关注这样的差距，同时要尽量解决这样的差距。
+
+我会建议管理者将这些差距记录下来，并具体解释为什么会有这样的差距，这将会成为接下来你跟员工绩效沟通时的重点，你需要告诉员工为什么彼此的认知是不一致的，不论是正面还是负面的差距都应如此。
+
+上面我们介绍了如何做好绩效评定，一个良好的绩效评定应该是完整、准确、公平且尽可能有用的。完整意味着管理者需要对绩效考核的各个维度都进行评定和评价，同时在允许的情况下提供足够的绩效评语。准确性要求管理者认真审查收集到的绩效数据，产生差距时需要解释差距产生的原因，以保证评估是准确的。公平性要求管理者使用的评价标准要一致。最后一点是，评语要对员工的改进有帮助。
+
+## 总结
+
+综上所述，绩效评定是绩效沟通环节的关键前置环节，一个良好的绩效评定能够助力你接下来的工作。
+
+## 思考题
+
+试着回想下，你最近做绩效评定时是怎么操作的呢？有什么关键点可以分享给大家呢？
+
+感谢你的收听，我们下期再见！
+
+## 作者简介
+
+刘俊强（微信公众号：程序员精进），TGO鲲鹏会会员，现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+年以上互联网开发经验，8年以上技术管理经验。
+
+

极客时间专栏/geek/技术领导力实战笔记/第125讲 | 洪强宁：从程序员到架构师，从架构师到CTO（一）.md

@@ -0,0 +1,61 @@
+<audio id="audio" title="第125讲 | 洪强宁：从程序员到架构师，从架构师到CTO（一）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/25/73/25890ed36824ae178b5c674f59f62273.mp3"></audio>
+
+你好，我是爱因互动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 年互联网从业经验。
+
+

极客时间专栏/geek/技术领导力实战笔记/第126讲 | 洪强宁：从程序员到架构师，从架构师到CTO（二）.md

@@ -0,0 +1,89 @@
+<audio id="audio" title="第126讲 | 洪强宁：从程序员到架构师，从架构师到CTO（二）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/61/e2/61278f3eaab91f47d17e89197863a5e2.mp3"></audio>
+
+你好，我是爱因互动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 年互联网从业经验。
+
+

极客时间专栏/geek/技术领导力实战笔记/第127讲 | 刘俊强：必知绩效管理知识之绩效沟通（一）.md

@@ -0,0 +1,45 @@
+<audio id="audio" title="第127讲 | 刘俊强：必知绩效管理知识之绩效沟通（一）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/8c/1c/8cf170a49f85bc13f0265a461df1701c.mp3"></audio>
+
+你好，我是腾讯云资深架构师、TGO鲲鹏会会员刘俊强，有着8年以上的技术管理经验，今天想跟你分享技术管理者必知的绩效管理知识之绩效沟通。绩效沟通最为常见的方式是一对一绩效面谈会议，绩效面谈会议是阶段三绩效考核和反馈中的重要工作项，优秀的管理者会好好利用这个机会，跟下属沟通好他们的绩效表现、帮助员工改进并指引发展。本文将介绍怎么准备绩效面谈会议以及如何设定绩效面谈会议的期望，以便管理者可以在绩效面谈会议开始前做好准备，最大化利用好这次跟下属沟通的机会。
+
+## 准备绩效面谈会议
+
+在绩效面谈会议前应该做哪些准备事项呢？简单来说主要是三个W（When、Where、Who），分别代表着：When 会议时间安排、Where 会议地点安排以及 Who 参会人员安排。
+
+关于会议时间的安排，正如前面文章所说，一般需要在第四周至第五周的时候，跟员工确定绩效面谈会议的时间。建议管理者可以先根据自己的时间来进行日程排列，然后跟员工确定该时间是否适合，因为很有可能员工正处在项目重要阶段，所以时间上需要跟员工沟通好，可以是电话沟通时间、即时通信工具沟通或是当面沟通，沟通确认好了后建议管理者发出一封带日程的电子邮件，这样方便员工将日程更新到自己的电脑或手机上。
+
+确定好下属们的绩效面谈会议时间后，便要开始预约会议室了。关于会议地点的选择，如果管理者拥有自己的办公室，不要使用自己的办公室做为绩效面谈沟通会议的地点，对于很多员工来说，去老板的办公室会有小学生去班主任办公室的感觉，即使没有什么问题，小孩去班主任办公室的时候还是会感到紧张，许多员工到老板办公室时也是此番感觉，毕竟管理职责带来的心理地位差异还是实际存在的。
+
+因此，我们要将会议地点对员工带来的压力给去除掉，尽量选择对员工而言比较中性舒适的地点，在注意隐私前提下，空间大些会更好，空间小也会带来压抑感。这里有几个简单的会议地点选择建议，中型会议室、培训室和暂未启用办公区都是不错的选择。
+
+一般情况下咱们的绩效面谈沟通会议，都是评估者和被评估者两个人参加，即管理者和下属的一对一会议。但是也有例外，如果管理者有合理理由觉得这次沟通会议会比较艰难，那么有人力资源同事或其它经理的参加可能会有帮助。简单举例，例如跟绩效表现很糟糕且固执的下属沟通，可能人力资源同事一同出席可能会更好，抑或是从员工未来的发展而言，如果对方需要更换业务线可能就需要该业务线经理出席。
+
+不过不论是基于怎样的考虑需要第三个人参加绩效面谈沟通会议，建议都需要提前跟员工确认，最好是在发送正式邮件前就确认好，再发送邮件到参会人员的邮箱。因为在默认一对一的绩效面谈沟通会议中，如果员工在未被告知的情况下发现有第三个人参加，会让员工感觉到很不受尊重。这里建议，这样的会议增加第三人是慎之又慎的事情，需要提前确认并沟通好，不然会有很大的反作用。
+
+上面我们明确了准备会议的三个 W 的主要内容，下面给一些管理者参加会议前的小贴士。首先在着装上，在遵循办公室规范情况下，尽量休闲舒适为主，不要在这时穿得很正式，因为绩效面谈会议不是轻松的会议，我们需要减少不必要的形式感和隐性压力。另外，当天第一个绩效会议开始前，建议管理者提前至少30分钟到达，准时是对下属的尊重，同时也为你提供了更多的时间准备，可以再回顾下待面谈员工的具体绩效表现。最后，在与会者座位的选择上，虽说你们是上下级关系，但是不要对面而坐，而是坐在桌子的同一侧保持一定距离即可，这样想传达的意思是，不是互相对抗而是合作。
+
+## 管理会议期望
+
+管理者如何管理好员工对于这次绩效面谈沟通会议的期望十分重要，一般来说可以从三个主要点来进行管理，分别是：员工对全年绩效评定的看法、会议开始前几周与员工沟通，以及实际会议中的期望管理。
+
+第一个点，主要是帮助员工以全年视角来理解和思考绩效评估流程，作为管理者你越是不和员工介绍绩效评估相关的信息，越是可能会给后面绩效考核阶段造成麻烦。相反我们要引导员工理解绩效评估流程，例如跟他们探讨绩效评估方法、胜任力模型以及绩效评估流程需要员工关注的地方等。绩效评估这个事情，你不和下属员工沟通，他们相互之间也会聊的，那么相对于可能的消息谬误风险，提前告知沟通不是更为明智么？
+
+第二个点，我们在前面文章也有介绍过，通过绩效评估流程的介绍和未来几周员工所做事情的沟通，在绩效面谈沟通会议的日程邮件发出时，管理者也可以附上会议上会沟通讨论的重点事项，例如管理者会反馈绩效评定情况、同事间的评价反馈以及改进建议等，如果公司业务有调整，那么这个时候进行沟通也是很好的机会。
+
+需要着重提醒的是，不要在绩效面谈沟通会议上探讨薪酬调整和晋升的问题，现实中确实有很多公司都会将薪酬和晋升等话题与绩效沟通会议联系起来，那么在这里，我为什么不建议这样操作呢？因为，当员工知道这个会议要探讨薪酬和晋升时，那么他们很大程度上就不会再有效地倾听绩效结果和改进建议，而是只等待薪酬和晋升结果。薪酬调整和晋升建议专门抽时间进行处理和沟通，不要在绩效沟通时探讨，这会分散员工倾听绩效结果反馈和思考绩效提升的注意力。
+
+最后一点，在实际会议上管理员工的期望。具体来说，在会议正式开始前，管理者可以先告诉员工这次会议的议程，议程一般不用太复杂，可以先是绩效完成情况、自我评价与上级评价、解释探讨评价间的重大差距，然后再是员工发展部分，例如，角色表更带来的挑战、培训和发展计划等。管理者不用过多介绍自己为这次绩效面谈沟通会议花了多少时间，但是可以简单介绍下你准备的东西，让员工知道你是认真对待这次会议的，这样在后面沟通绩效时，员工更容易接受和倾听你的反馈和建议，他们会感觉你的评价是合理的。
+
+简而言之，管理员工的绩效面谈沟通会议期望，是帮助管理者和员工以最为开放和积极的心态来面对绩效评估结果的要点。
+
+## 总结
+
+本文我们介绍了绩效沟通面谈会议的准备和期望管理，能够帮助我们给绩效沟通开个良好的开端。你在最近的绩效沟通面谈会议前都做了哪些准备工作呢？欢迎在留言区分享~
+
+感谢你的收听，我们下期再见！
+
+## 作者简介
+
+刘俊强（微信公众号：程序员精进），TGO鲲鹏会会员，现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+年以上互联网开发经验，8年以上技术管理经验。
+
+

极客时间专栏/geek/技术领导力实战笔记/第128讲 | 王坚：年轻人永远是创新的主体.md

@@ -0,0 +1,42 @@
+<audio id="audio" title="第128讲 | 王坚：年轻人永远是创新的主体" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/6a/30/6a6c65cbe8e698ff53fd0860670e5730.mp3"></audio>
+
+> 
+<p>王坚：2050志愿者，阿里云创始人，阿里巴巴技术委员会主席。<br>
+他被媒体和众人称为“忽悠马云的骗子”和“风口上的先知”，但这些都是外人眼中的王坚，我们很好奇，站在这些标签背后的他，到底是什么样子？他究竟还有多少不为人知的趣事，脑子里装了哪些新奇古怪的想法？对于自己，他还有多少的期待？对于世界、未来和年轻一代，他又是如何看待的？</p>
+
+
+作为2050的志愿者和发起人，首先想和大家聊聊为什么要做这件事，我觉得现在很多人都在讲创新，但实际上创新是需要很多人帮助的，特别是年轻人。2050就是为年轻人举办的活动，希望大家对年轻人更加关注，把社会资源留给他们，让他们可以做更多的创新。
+
+如今，绝大部分会议都是为成功人士举办的，而2050恰恰是为那些还没有获得成功的年轻人举办的，让他们也能有机会表达自己的观点，这是我创办2050的初衷之一。除此之外，科技的作用也不能单单以是否有用去定义，年轻人有这样一个使命——让科技可以像音乐和体育一样将人团结在一起，让不同的人因为科技而产生关联，这就是我发起2050的两个初衷。
+
+今年5月第一届2050落幕了，会议本身超出了我的预期，具体体现在哪里呢？就是我们成功地向外界传递出举办2050的初衷，让大家知道了什么叫做志愿者举办的大会，而并不是会议中的哪个活动做得特别成功，这是我觉得最骄傲的一点。如果说我们只有一点做得足够好，那就是这一点。我很清楚地知道会议本身还有很多不足，但只要能将这一点传达出去，就是我最大的收获。
+
+对于明年的2050，我希望可以向大家证明，志愿者可以做到很多人原本觉得不可能的事情。我们需要重新认识志愿的精神，相信明年的这个时候大家都可以感受得到，在中国，甚至在世界范围内，志愿者是如何为年轻人，或者说，如何通过年轻人为整个社会的发展和进步做贡献的，这一点我感到非常骄傲。我刚刚谈到过，大部分人都在做那些看起来很“高大上”的会议，但这不是2050所追求的，最“高大上”的就是年轻人，是年轻人本身。
+
+其实，大部分年轻人都不知道自己处于什么状态，因为身在其中，我年轻的时候也不例外。站在我这个年纪回望过去，最大的感触就是自己年轻时得到了太多人的帮助，但当时我还感受不到这一点，是现在才能感受到的，这是让我非常感恩的一件事，所以我觉得应该为年轻人多做一点事情。
+
+我记得我说过一句话：年轻人就是要做一些大家看起来不可能的事情。从这个角度讲，任何一个时代的年轻人都一样，唯一不同的是时代本身，比如蒸汽机时代有蒸汽机的挑战，电气时代有电气的挑战，如今的数据时代有数据的挑战，挑战是不一样的。但我觉得年轻人有一个最大的共同点，就是他们才是帮助整个社会去突破原有框架的群体，他们永远是创新的主体。
+
+从阿里云到2050再到城市大脑，这些事情能够做成其实得益于很多自然条件，我觉得自己非常幸运可以有机会接触到它们。我认为大家还是要多多发现问题，而不是简单地去解决别人提出的问题，虽然发现问题和解决问题都很重要，但事实上，总要有一些人去发现新的问题。因为我的兴趣和背景，我永远会去观察有哪些新问题，所以可能在一些人忙于解决问题的时候，我在做前者。
+
+那么，发现问题后谁来解决呢？我的习惯是自己发现的问题，只要我觉得足够重要，那就应该自己解决。而不是说我发现了问题，交给别人去解决。或许有人会觉得这有作弊的嫌疑，但从我自己的角度上讲，这就是我思考问题最基本的逻辑。所以我鼓励大家从身边发现问题，就算是那些看似很小的问题，也有可能变成社会性的大问题。
+
+之前我看到过一个数据，35岁以下的年轻人占世界总人口的50%，当时我感到非常吃惊，因为这个数字是持续增长的，而不是呈下降趋势，是人类历史的峰值。这就是我发起2050时想到的问题。城市大脑也一样，我们都觉得城市交通堵塞，那么普遍的解决办法就是多修路或者限行，从没有人认真想过我们对交通资源的使用是否合理，我所做的只不过是从交通堵塞问题延伸到社会资源的使用问题，比如红绿灯资源的使用是否合理。发现问题非常重要，年轻人会用他们自己的眼光去发现别人看不到的东西，这可能也是年轻时候的我与其他人不太一样的地方。
+
+谈到阿里云，现在已经叫云计算了，有两件事情让我印象深刻：首先，在加入阿里巴巴之前，我就已经意识到数据和计算的重要性了，这二者是一体的，你不能把它们拆开来。所以，我既然认识到计算对未来社会的重要性，就知道计算的形态是一定会改变的。
+
+事实上，在云计算出现以前，我们已经经历过几次计算形态的改变了，从大型机到工作站，再到个人电脑，我觉得计算的形态将会发生很大的变化，而变化的物质基础就是互联网，这也是我为什么经常谈到，云计算就是通过互联网来获取的计算，其实是来自于我对计算本身的认识。
+
+后来，大家逐渐对这种计算形态的变化有了共识，就把它命名为“云计算”了。尽管最初我并不愿意这样称呼它，我的设想是叫它“通用计算”，就像通用电器一样，就好像以前的电也是专用的电，只供电灯泡使用，后来才逐渐演变成通用的电，于是有了电冰箱等通用电器，所以我当时想叫它“通用计算”，但一般人很难接受这个叫法，所以就叫“云计算”了。
+
+为什么我总是用电来举例子呢？其实是有原因的：就像电刚出来的时候只有电灯泡一样，阿里云的第一批客户都是中小网站，我觉得这些中小网站就是那个电灯泡，他们无法自行发电，但随着客户逐渐增多，你可以想象，电冰箱出现了，洗碗机也出现了……直到现在，云计算已经变成了通用计算。所以我觉得，对问题的思考会影响你做事情的方法，而发现新问题是思考中最重要的一环。
+
+这是一个非常重要的时代，是属于年轻人的时代，尽管这句话放在历史上的任何时刻都是正确的，但我还是觉得我们现在所处的时代非常特别，是历史上少有的几次，对年轻人而言最好的时代。为什么这么讲呢？大家认真思考一下，美国最好的时代就是爱迪生诞生前后的三五十年，那时候涌现了很多新的发明，而我们现在看到的绝大部分科学技术就是最近几百年发明创造的，和美国那段时期非常相似，是所有可能性集中爆发的时代，至于具体会创造出什么，那就是另外一回事了。
+
+我们通常会说任何一个时代都是年轻人最好的时代，但大家为什么还记得爱迪生那个时期呢？就是因为那个时代非常特殊，我觉得当下就等同于那时候，从电刚开始出现到给城市乃至社会带来翻天覆地的转变，而计算给城市带来的改变还没有开始，Kevin今天带了一个laptop，可能那就是开始的开始。
+
+我觉得非常幸运的一点就是年轻的时候，身边的人为我创造出足够多的空间，所以我也想为年轻人创造空间，只要有充足的空间，他们就会用自己的方法去成长，这是我坚定相信的。大家现在看到年轻人身上有这样那样的问题，是因为他们的空间不够，行动就会受限和变形，这是我对年轻人的理解。现在的社会环境总体还是比较好的，可以为大部分人创造出足够的空间，要相信他们，不要让他们把事情做变形，这也是我能为他们做的最好的事情了。
+
+(本文整理自11月22日王坚博士在极客Live的直播活动)
+
+

极客时间专栏/geek/技术领导力实战笔记/第129讲 | 刘俊强：必知绩效管理知识之绩效沟通（二）.md

@@ -0,0 +1,69 @@
+<audio id="audio" title="第129讲 | 刘俊强：必知绩效管理知识之绩效沟通（二）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/f7/09/f7965c3f1cdeba047553fc1baddc7309.mp3"></audio>
+
+你好，我是腾讯云资深架构师、TGO鲲鹏会会员刘俊强，有着8年以上的技术管理经验，今天继续跟你分享技术管理者必知的绩效管理知识之绩效沟通。在前面的文章中我们介绍了如何准备绩效面谈会议并设定会议期望，今天我们将聊聊绩效面谈会议中如何跟员工进行绩效讨论。
+
+## 讨论绩效
+
+就员工在工作中的表现进行当面讨论可能会很困难，大多数管理者都不喜欢正式地批评员工，而且大多数员工也不喜欢被评估，所以，在绩效面谈沟通会议上正式地讨论绩效可能会让双方都有些紧张，那么实际绩效讨论环节该怎么做才好？怎样让绩效面谈沟通会议更有效率呢？
+
+最为重要的是时间分配，一般情况下我们建议，10% 的时间用于回顾过去，50% 的时间用于介绍当前，剩余40% 的时间用于讨论未来。
+
+首先，回顾过去的时间不应该超过 10%，这个环节只是帮我们讨论绩效时设定好背景，例如，员工在公司的工作年限、有过多少次晋升、目前在公司的职位、在该职位上的任职时间，以及上次绩效评定表现好或不好的地方等。
+
+在快速回顾过去后，就进入绩效讨论的主要部分，即当前绩效周期内的表现情况。在这个环节，管理者需要跟员工讨论他的目标达成情况和所有相关的评分，例如上级评定、自我评定以及同事评价等。就目标达成情况而言，有一些可能已经达成，有一些可能仍在进行中，也有一些可能是无关紧要的或是需要改变的。众所周知，公司或团队的需求会经常发生变化，最终不论怎样，管理者都需要对时候按时完成工作和达到目标等这些事情进行评分。
+
+接下来我们以假定的绩效讨论对话来观察如何进行绩效讨论。在以下的对话中，张三为管理者，李四为员工。
+
+> 
+<p>张三（管理者）：首先祝贺你在公司的第一个年头。<br>
+李四（员工）：哦，非常感谢。虽然只来了十个月，但我确实觉得我已经是团队的一员了。<br>
+张三：是的，从二月份入职到现在已经十多个月了。这段时间内你的初始目标是了解咱们团队的开发流程并完成相关系统或服务的开发。在最开始的两个月整体完成情况低于预期，当然这对于一个新人来说非常典型，但再后来的八个月里你的目标都达成了，这是非常好的。<br>
+李四：很高兴听到这样的评价，我还担心你觉得我上手不够快。<br>
+张三：老实说，预期上手时间是两到四个月，而你在两个月内就完成了，这很棒。<br>
+李四：谢谢。<br>
+张三：那现在我们进入具体细节。</p>
+
+
+正如你所看到的，张三作为管理者先花时间回顾了过去，给绩效讨论设定了背景。接下来，该是看评分和具体差距的时候了，通常来说，绩效评估模板生成后应该要突显自我评分、同事评分以及上级评分间的差距，简单的方法就是各评分项作为行，各个评分人作为列进行并排比较。接下来，看看管理者张三是怎么处理的。
+
+> 
+<p>张三：到目前为止，胜任力模型中主要能力项的不同评分间的差距很小，甚至有些不存在，可以看出你的整体表现很强，但这里有个例外，正如你看到的，在有效沟通这一项，你给自己评了8分，同事评价是6分，而我给评了5分。我觉得这里我们有些理解偏差。<br>
+李四：是的，我也认为沟通能力我还可以再加强，但是这里的评分差距之大让我惊讶。<br>
+张三：嗯，来自于同事的数据和我的观察似乎表明了同一件事情，你的沟通风格比较匆忙和直率，当然，这会让人感觉很真诚，但同时也容易让人感觉有些冷。我们来看看一些同事评价？<br>
+李四：好的。<br>
+张三：我这里拿一个看看。李四似乎总是很匆忙，在跟其它同事打交道时，对于其他人表现得不是很感兴趣。你知道这种看法吗？<br>
+李四：不，说实话，我并不是这样的。额，我的意思是我看到这样的评价我很惊讶，也许我有时候不应该像那样沟通。<br>
+张三：你的表现还不错，工作目标达成情况就可以说明，只是在跟同事打交道时，处理的不够好，我相信这是一个你可以改进的领域。<br>
+李四：嗯，好的。</p>
+
+
+以上谈话举例，我们可以看到李四在沟通能力上可以再改进，并且自己也明确了改进的期望。接下来，管理者张三就可以引导李四了解公司内有什么样的机会和方式可以帮助他改进和提升，例如沟通能力培训、沟通能力需要比较强的任务机会等。整体上建议管理者使用引导思考的方式解决问题，下面会有些小贴士来帮助管理者保持绩效讨论的可控和高效。
+
+首先，评分要尽量客观，不要刻意贬低压分。这意味着管理者必须有自己明确的评分和评价，不要受其它因素的影响。另外，如果员工在绩效讨论过程中表现出惊喜，就说明管理者的工作有做的不到位的地方。因为如果管理者在绩效周期内已经正确有效地跟员工沟通了，那员工就不会对评估过程中发生的事情感到惊讶的，或是感到惊讶的部分会很少。
+
+另外一个技巧是，员工的评估中找到一两个他们遇到的，同时也是你之前遇到过的问题，可以简要地告诉员工你的解决方案和改进方法，让员工感觉到你是在帮助他们解决问题，而不仅仅是上下级关系，这样绩效讨论时他们也会更有效地倾听。
+
+最后，在绩效讨论中，员工很有可能会对你提出的讨论点找借口或抱怨，而管理者在处理员工的借口和抱怨时要格外谨慎，因为他们此时的情绪极有可能比较激动。记住对应情绪化的最好的方法就是不带情绪的回应，只是以非常冷静的方式来回应借口，就是听，但是不要做记录，因为这样会让员工认为你接受了他们的借口。
+
+大多数情况下，管理者可以回复，我听到了你所说的，我在做评估时有考虑过这个情况；或者是，承认没有意识到这一点，但是评价不会修改。这里的关键是要明确，反馈的情况接收到了但是评价不会改变。除非管理者收到重要的意外信息，才可能会有例外情况。除此之外，在管理者开始绩效面谈会议前，评估就已经完成无需再修改。这里我们再看看管理者张三如何处理员工李四的一些问题的。
+
+> 
+<p>李四）：我觉得人们注意到我的沟通问题，只是因为我是新人，大家还不怎么熟悉。<br>
+张三：嗯，10个月也不算新人了。我想说清楚些，提供反馈的不仅仅团队。我的观察也非常相似，你的人际风格需要改变。实话说，我希望也能收到类似的反馈，帮助我改进，例如我有时过于自信了。</p>
+
+
+上面的对话示例中，张三没有接受李四的借口，甚至可以贬低自己一点，希望自己也能有类似的反馈，从而来进行技能改进和提升。
+
+总的来说，坦诚地讨论绩效对于任何成功的团队都至关重要，如果你能够使用我们之前介绍过的建议，相信可以保持对流程的控制，不仅会让绩效讨论没那么大压力，也会让绩效面谈沟通会议更有效率，最后确保员工活动公平有用的评价。
+
+## 思考题
+
+你在最近的绩效面谈会议中，讨论绩效环节是怎么操作的呢？欢迎在留言区分享~
+
+感谢你的收听，我们下期再见！
+
+## 作者简介
+
+刘俊强（微信公众号：程序员精进），TGO鲲鹏会会员，现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+年以上互联网开发经验，8年以上技术管理经验。
+
+

极客时间专栏/geek/技术领导力实战笔记/第12讲 | 谈谈CTO在商业战略中的定位.md

@@ -0,0 +1,57 @@
+<audio id="audio" title="第12讲 | 谈谈CTO在商业战略中的定位" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ac/56/ac706040707c6f4d02b3b5a1c9a52f56.mp3"></audio>
+
+“战略”一词最早是军事方面的概念，战略的特征是发现谋略的纲领。在西方，“strategy”源于希腊语中的“strategos”一词，意为军事将领、地方行政长官，后来演变成军事术语，指军事将领指挥军队作战的谋略。在中国，战略一词历史长远，“战”指战争，“略”指“谋略”、“施诈&quot;；春秋时期，孙武的《孙子兵法》被认为是中国最早对战略进行全局筹划的著作。
+
+战略是一种从全局考虑谋划实现全局目标的规划，而战术只为现实战略的手段之一。实施过程中，往往又是要牺牲部分利益，去获得战略胜利。战略是一种长远规划，是远大的目标，往往规划战略，制定战略，用于实现战略目标的时间是比较长的。
+
+争一时之长短，用战术就可以达到目标，如果是争一世之雌雄，就要从全局出发，去规划，这就是战略。那么，在互联网企业公司中，一般是由CEO制定战略，那么CTO在中间应该扮演什么角色呢？这个问题是令很多CTO感到疑惑的。
+
+## 战略必须被认可和接受
+
+首先第一点：作为技术领导者，首先要参与讨论战略，充分认可战略目标，并作为决策者的立场上接受。要站在整个公司的层面上，觉得公司的战略是可以实现的，也是合理的。用一句俗语来说就是：CTO永远是要为CEO的“吹牛”去埋单的，但是，从职业的角度来说，不能玩死了。
+
+大概意思就是，在总体战略下，CTO作为技术领导者，至少需要从产品设计、技术落地两个层面去支撑战略在产品上的的落地，若不能理解并接受，产品是无法及时有效的落地，并推向市场的，连试错的机会也会失去。<br />
+ <br />
+其次，战略宣讲。任何一个团队，CEO、CTO……CXO，再怎么厉害，现代企业中，不可能靠一个人能将所有的事情都完成。同样，这些不同团队的负责人也不能将一家公司的战略在战术上完美落地，必须依靠一个核心团队，依靠能够理解，并接受战略，且各自不同分工的团队。如何让核心产品和技术团队推进落地，对其核心团队进行宣讲，并让核心团队能够接受，作为技术领导者在对战略的分解，在战术上的具体落地，策略的制定，等等，时刻被考验着。
+
+## 战略宣讲的三个步骤
+
+那么如何进行宣讲呢？就我的经验来说，一般宣讲分为这么几个步骤。
+
+第一步：战略制定者从全公司层面对公司来年的目标、运营模式进行宣讲。这种情况下，一般面向公司全员宣讲来年的目标，讲解制定目标的意义，制定这些目标的依据。这种面向全员的宣讲，最大的问题并不是无法将目标和战略详细的讲解清楚，也不是担心整个公司层面是否能够接受，而是在于如何能够清楚的描述为什么能够完成这些目标，完成这些目标的底气和信心来自哪里。这些都是在宣讲过程中，需要向全公司层面清楚的描述的，同时核心管理层要给大家展示以及表达能够完成这些目标的信心。<br />
+ <br />
+第二步：这一步最重要的点就是战略和目标分解。公司层面的目标定义完成，接着就需要每个团队根据目标，认领自己团队的目标，团队负责人对团队目标进行分解。实际上这里是对整个公司来年的目标的进一步分解和目标宣讲。这一阶段实际上最重要的是根据公司的目标，在产品和技术层面的支持。为了达到公司既定的战略目标，产品的设计思路是如何提供对完成目标的支持的。以及在产品思路上，技术的架构设计思路，技术路线设计，以及在技术上的落地策略。<br />
+ <br />
+再次，落地策略、资源调配。战略再高大上，最后也要靠战术推行落地。若只是战略上的宣讲，而没有最后的落地策略，往往会被认为是吹牛。作为CTO，理解并接受战略之后，接着就要做产品策略，设计产品思路，其核心思想一定是在产品上体现战略。围绕着公司的整体运营思路，体现产品的设计思想。产品的设计一定是整体运营思想的体现，在这个中间，CTO一定要带领整个产品、技术团队，在既定的战略思维指导下，对产品目标、策略进行设计，确定产品的范畴，明确产品诉求、目标客户群体，设计产品具体的运营玩法。
+
+## 能解决问题才是合格的CTO
+
+确定产品的设计思路、目标群体、产品范畴等之后，就要调配资源进行落地，此时，作为产品、技术的领导者，对其基本功底的考验就变得非常重要，如何在现有资源上，对资源进行最优化的配置，产品功能如何抉择，合理利用资源，优化资源，最大化利用资源合理设计并执行落地，是需要技术领导者去做的事情。<br />
+ <br />
+至于很多公司的技术领导者觉得不知道自己该为战略做什么，其实这个问题一般是因为，CTO尚未理解公司的目标定位，即便知道也是一知半解，对公司的目标定位并不是完全接受。
+
+有些技术领导者则是能完全理解并接受战略目标定位，但是并不清楚公司在这种目标定位下团队短板在哪里，需要补充的资源是什么，以及这些资源该如何补充。
+
+对于这个问题，个人觉得，CTO应该在充分理解之后，跟每个团队，尤其是不属于CTO负责的团队进行充分的沟通，理解这些团队的痛点，业务上的不足，设身处地的站在对方团队的基础上理解并接受对方的痛点，换位思考，对症下药。
+
+## 什么样的CTO才能在商业战略上做决策？
+
+那么合格的CTO应该具备什么素质，才能支持其作为核心决策者之一，参与公司的战略定位和经营决策？个人认为，至少需要具备以下几点素质：
+
+至少在技术上的某一个领域独当一面，无论是架构设计、性能优化、服务端开发等，至少需要具备很强的经验，踩过坑，否则，对于技术上的经历更多的只会停留在纸上谈兵的层面。
+
+CTO未必要亲自写代码，但一定要懂得系统是如何通过代码实现的，懂得编程的原理，懂得程序员是如何干活的，各种方法的优缺点必须心中明白，说的直接一点就是，不能让下面的任何人把你给忽悠了。
+
+架构设计是CTO关注的重点，未必亲自设计，但一定要了解各种架构的优缺点，以及当前选择的理由和依据，结合当前的业务发展，做最优的选择。
+
+相当重要的一点是沟通能力，往往沟通能力体现的是两个方面，其一是表达能力，充分、明白的表达自己的观点，在跟不同的人沟通时，能用不同的语言和方式表达；其二是理解能力，不管跟业务方、产品经理、运营或者CEO沟通时，都能get到对方的真实意图，透过现象看到本质，获取最真实和原始的需求。
+
+很强的产品意识和商业意识。任何商业模式希望在最后获取最大化的商业价值，技术是无法逾越的鸿沟，而CTO作为公司的技术最高指挥官，必须同时具备很强的产品意识和商业意识，将业务和技术有机的结合起来，才能实现商业目标最大化的商业价值。
+
+总之一句话，CTO是为CEO的吹牛而埋单的，但是不要忘记，作为追求利润最大化为唯一目标的经营单位，任何一次的目标定位，都是生死抉择。作为核心决策者之一，理解接受只是最基本的要求，充分参与其中，合理调配资源，并解决问题才是合格的CTO。
+
+****作者简介****
+
+吴万港，前中恒云能源CTO，[TGO鲲鹏会](http://tgo.geekbang.org)杭州分会服务委员&amp;学习委员。10多年的互联网行业从业经验，带领多个团队完成设计、研发了分布式K/V，分布式数据库，日处理达到百T级别的分布式文件系统。8年以上互联网行业大型的产品、技术团队的建设、团队发展、团队管理经验。对于从产品需求、技术实现等管理方面有全面的认识和实践经验，深入理解敏捷研发管理办法以及多年的实践经验。
+
+

极客时间专栏/geek/技术领导力实战笔记/第130讲 | 刘俊强：必知绩效管理知识之绩效沟通（三）.md

@@ -0,0 +1,53 @@
+<audio id="audio" title="第130讲 | 刘俊强：必知绩效管理知识之绩效沟通（三）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/47/06/47fd48ea50c7b07528df46fed295fc06.mp3"></audio>
+
+你好，我是腾讯云资深架构师、TGO鲲鹏会会员刘俊强，有着8年以上的技术管理经验，今天想跟你分享技术管理者必知的绩效管理知识中，关于绩效沟通的话题。前面的系列文章介绍了如何准备绩效面谈会议以及绩效讨论该怎么执行，今天我们要聊的是在绩效评估阶段最为重要的事情，即怎么通过绩效评估帮助员工成长发展。
+
+## 专注于员工发展
+
+年度绩效考核或年度绩效评估这样的名字如果可以的话，我倒是建议修改成年度绩效讨论，因为绩效讨论这个词是个中性词，非褒义非贬义只是在陈述一个主题或事实。相比较绩效讨论这个词而言，绩效考核或绩效评估这样的词会带来潜在的压力。需要记住的是我们做绩效考核的最终目标是帮助员工和团队发展成长，这个环节的目的是要产生帮助，应该是积极的，而不是消极的或是专注于批评。
+
+绩效考核阶段专注于员工发展，主要需要考虑两个事情，一是能帮助员工或团队进行工作调整，二是能提供支持员工或团队持续发展的工具和资源。
+
+关于工作调整，首先需要考虑如何确定目标的规模，例如服务端开发工程师原先负责5个微服务的开发，并且表现良好，你可能希望再分配几个重要的微服务给他。这里需要考虑的是，如果管理者增加了员工或团队工作目标的规模，就会占用他们用于不同类型的发展机会的时间。因此，在考虑对绩效表现良好员工进行工作调整时，需要考虑是扩大现有职责还是发展新的能力。
+
+现有职责的规模扩大很好理解，大多数管理者都实际操作过，接下来，我们要聊聊发展新的能力。这里介绍一个术语“拓展角色”，如果有机会的话，可以通过分配“拓展角色”的方式给员工以新能力的锻炼机会。“拓展角色”代表了一个临时的全新的责任领域，需要管理者以教练的方式进行辅导。如果管理者有目标员工的话，绩效讨论是不错的时机，但需要注意的是，“拓展角色”是属于员工的，因此，只有员工自己真正想要这个角色，这样的机会才有尝试的价值。
+
+另外，除了“拓展角色”这样临时的全新领域的发展机会，管理者也可以跟员工讨论持久性的工作调整，一般是横向变化，例如在不带管理职级的情况下带领两个类似员工。关于垂直方向的变化，即承担当前位置之上的职位职责，也就是晋升，这个建议在晋升环节独立操作，时间和准备上会更为充分，因为晋升不是绩效考核环节的必要输出，反之绩效考核是晋升的基础支持。
+
+前面有介绍到工作调整，工作调整不论是横向调整、垂直调整还是“拓展角色”，作为管理者都应该提供相应的工具和资源帮助员工发展和成长，例如各类成长计划，不同的成长计划对应不同的职级和能力。成长计划一般包括专门的培训和发展计划，针对公司最优秀的人才进行培养提升，为他们下一阶段的职能做准备。
+
+总而言之，绩效评估这个环节是关于员工绩效的评估，但这只是第一步，最关键的是在此之后，怎么帮助员工发展成长为更好的自己。
+
+## 讨论拓展机会
+
+前面咱们有介绍到“拓展角色”，它实际上是一个推动员工超越他们目前职责和技能的工作机会。通常情况下是临时性的，可以是数月或一年之久。优秀员工成长需要定期尝试些新事物，同时，“拓展角色”也能够帮助企业找到合适的人选执行合适的项目。
+
+在今天的大多数企业中，“拓展角色”被用于高潜力员工身上，一般是用于 VP 和 C-Level 级别的潜在高级管理者。但是“拓展角色”这个概念并非是专属于高级管理者的，我们也可以使用“拓展角色”的方式，帮助员工激发新能力的发展。通过“拓展角色”，管理者将员工有意识且积极地放在一个他们尚未成功的地方，员工将面临风险和新的学习曲线，这种方式不一定会成功，很有可能会失败。因此，管理者需要做两件事情来降低这种风险。
+
+首先，“拓展角色”的机会仅仅只分配给真正非常需要它的员工。这里指的是，如果管理者与员工讨论拓展角色的机会时，对方似乎不确定或是无动于衷，这时就需要慎重考虑他们是否是合适的人员。其次，强烈建议管理者使用最优秀的人才，实话讲“拓展角色”不适合一般或良好的员工，它只适合优秀且非常愿意尝试新事物的员工，对他们而言这是个十分重要的机会。
+
+假设管理者拥有了合适的人选，并且双方都做好了准备，愿意尝试且有信心做到，那么，良好的“拓展角色”是怎么样的呢？实际上有很多可能性。例如，将一位年轻的架构师任命到技术委员会，让该员工参与到公司技术战略的规划过程中去。另外一种常见的例子是，指派员工到陷入困境需要扭转的项目或部门。上面两个例子都能够推动他们现有技能水平的提高，以及帮助他们建立起全新的技能。另外，除了给员工分配或委派“拓展角色”之外，管理者还需要确保为其主要工作提供尽可能多的支持，管理者这时要更多的充当教练的角色，辅导帮助他们成功。
+
+## 有效地结束
+
+之前的系列文章中有介绍到，在绩效沟通环节中，建议给每位员工提供一个小时的时间，如果管理者不知道如何有效地结束会议，那么会影响后面等待绩效沟通的员工。在此我们不期望绩效沟通会议方可以在双完全友好和谐的氛围中结束，通常情况下都会有双方明确同意的部分和不太顺利的部分，这是很正常的，在阐述完绩效评价后，简单回顾下进展不顺利的部分，坦诚地看待事实情况。
+
+员工、上级对绩效评定进行签字是绩效沟通后对于人力资源部门的输出。在此，有些员工会毫不犹豫的签署，有些员工会质疑绩效评价的公平性，这里需要跟员工申明的是，最后的签字不代表着认可，而是代表着他们收到了绩效评定以及管理者对绩效评分的解释。如果管理者沟通后，员工还是不能认可绩效评定结果，管理者可以告知员工申诉流程，申诉流程的具体情况需要根据管理者所在公司的规定来看，一般情况来说，申诉流程会有时间有效期、对接人信息、申诉所需材料等。
+
+因此，管理者在绩效管理循环期间内做的准备越充分，员工就越不可能对你的绩效评定结果提出申诉。当管理者在绩效沟通时，准备并提供有用、诚实的评定，员工会知道你不仅仅是在尝试评价他们，实际上更多的是想帮助他们取得更大的成功。
+
+## 总结
+
+作为管理者需要记住，绩效考核和反馈阶段最为重要的事情是帮助员工和团队发展成长，只要秉承这颗初心，相信你会成为让员工信服的管理者。
+
+## 思考题
+
+思考下，你最近在绩效沟通会议时，跟员工沟通了哪些能够帮助他们发展成长的内容呢？
+
+感谢你的收听，我们下期再见！
+
+## 作者简介
+
+刘俊强（微信公众号：程序员精进），TGO鲲鹏会会员，现任腾讯云资深架构师，曾任迅雷技术总监、某互联网公司技术副总裁，10+年以上互联网开发经验，8年以上技术管理经验。
+
+

极客时间专栏/geek/技术领导力实战笔记/第131讲 | 汤力嘉：CTO如何在产品方面进行决策（二）.md

@@ -0,0 +1,103 @@
+<audio id="audio" title="第131讲 | 汤力嘉：CTO如何在产品方面进行决策（二）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ce/7e/ce2bbdc8915de60817b5eb85ea830d7e.mp3"></audio>
+
+你好，我是一下科技CTO汤力嘉。对于CTO而言，优秀的产品决策能力是必需的，在之前的[文章](https://time.geekbang.org/column/article/66422)中， 我跟大家分享了我在产品决策上的理念和心得，其中的关键点是简单，并分享了简单策略在产品决策中的具体运用，包括删除、组织、隐藏、转移等四个执行策略。
+
+而产品策略制定后的下一步就是验证需求，并具体落地执行，今天就想跟大家分享一下我在这两方面的实践与经验。
+
+## 验证需求
+
+先来看验证需求，在这个过程中，有几点因素会影响验证结果。
+
+一、调查的局限性<br>
+验证需求的做法之一就是做用户调查，而调查结果本身有很多局限性，所以不可以完全相信，我举2个大家可能都知道的例子。
+
+案例1：可口可乐公司曾经推出一种新口味可乐，调查显示，多半用户喜欢这种新口味，于是，可口可乐公司买入多套设备，建立新的生产线，投入新口味的生产中。结果，忠于旧口味的用户开始上街游行，而喜欢新口味的用户又不嫌事大，也参加了游行。最终，可口可乐公司被迫将新生产线全都撤掉，损失巨大。
+
+案例2：我国内地的茶饮料（比如水果茶、冷泡茶）搬上市场前也做了用户调查，结果显示，人们一致认为要喝泡好的热茶，所以生产商都不敢轻易生产。后来台湾厂商直接把茶当饮料卖，并推入内地市场，结果，统一、康师傅等品牌下的茶饮料就占据了内地茶饮料市场。
+
+二、决策情感<br>
+验证需求时，除了需要关注调查结果，还需要关注用户的情感因素。用户是否购买产品，很大一部分取决于他的心理因素。
+
+举个例子，可口可乐与百事可乐的竞争，在70年代，百事可乐做了一次可乐口味大调查活动，将可口可乐与百事可乐的品牌隐藏，让用户对二者口味进行投票。结果百事可乐以大比分领先，取得优势。但是这30年来，百事可乐的销量却一直不及可口可乐，这是为什么呢？
+
+原因与人的情感有关。在2003年，核磁共振研究发现，人类大脑中有一块强化奖赏情感区域，在这块区域中，百事可乐比可口可乐多5倍，所以人们会认为百事可乐比较好喝。但为什么用户依然会选择可口可乐呢？是因为只要将品牌告知实验者，实验者的前额叶皮层就会发生变化，强制要求这个人喜欢可口可乐，这就是品牌影响了实验者的决策情感。
+
+三、眼见不为实<br>
+我们经常讲眼见为实，但在验证需求时，眼见不一定为实，应该从多个角度出发思考问题。
+
+以英国脱欧为例，英国脱欧后，谷歌排名前5的搜索问题都是关于欧盟以及脱欧有什么后果。乍一看问题，大家可能会觉得，投票脱欧的人真无知。但用户数据显示，搜索这些问题的用户大多来自于英国北部，是支持留欧的人，并且年轻人多于老年人。此时，大家会怎么理解呢？
+
+其实，有各种各样的理解方法。我能想到的就有五点，第一，支持脱欧的人本来就知道脱欧后果，所以他们不会去搜索脱欧后果，而支持留欧的人不知道脱欧后果，所以才会搜索问题答案。第二，可能是英国的年轻人不懂，所以搜索用户中年轻人多于老年人。第三，也可能是年轻人更关注时事，所以才去搜索。第四，也可能是中老年人压根不会使用搜索引擎。第五种情况是中老年人根本就没有年轻人多。
+
+所以，对于同样一件事，我们从不同方向去理解，就能够产生多种结果。
+
+四、先入为主<br>
+第四点影响需求验证结果的因素是人们容易先入为主，打个比方，听到下面这四句话：1.在东莞工作的女朋友；2.大学老师和女学生在一起了；3.上海丈母娘；4.开奔驰的妙龄女郎。相信多数人会先入为主，戴着有色眼镜去看待，结果就会误导事实。
+
+那么，如何判断想法是否靠谱呢？我认为可以从五个方面出发：
+
+产品价值，产品的核心价值是什么？它解决了什么问题？这个问题在此产品没有出现之前是怎么解决的？此产品出现后，是否能更有效的解决问题？
+
+目标市场，比如市场的用户存量、用户群体、用户画像、用户消费能力，等等。
+
+市场规模，包括存量的市场和增量的市场，增量市场即发展前景，比如，我们为什么一直在做短视频？是因为我们在2011年就预见了短视频的未来发展趋势，虽然过足足5年才火起来，但也是押对了。
+
+市场格局，比如市场中的同款或同类型产品有几种形态，每种产品的布局是怎么样的？大公司有没有进来？产业链是怎样的？
+
+竞争优势，这是最重要的一方面，很多时候我们去做一个产品并不是因为产品本身能带来什么，而是先看我们能做什么，有何竞争优势。
+
+确定想法靠谱之后，就该判断该想法是否可行，我们可以从四方面来判断。
+
+切入时机，包括自身的硬件条件、技术能力是否已具备实现想法的能力，对用户感知、用户习惯的洞察是否已经有所培养等。
+
+运营推广，酒香也怕巷子深，所以，我们可能要先想一想，有什么办法能走出这条“巷子”。以小咖秀为例，小咖秀初期选择了一个比较好的推广手段，就是在综艺节目《康熙来了》中介绍小咖秀，然后将电视画面截图，并在图片中贴上小咖秀的下载链接进行推广，随后产生了第一批种子用户。另外，我们还邀请了一些明星帮助推广，结果明星自己先嗨起来了，小咖秀也就迅速被带火了。
+
+量化指标，包括产品进度、人员成本、运营计划等，每一环、每一步都需要制定明确的指标，不断跟进、落实，以降低风险。
+
+风险应对，风险可能会来自各个方面，比如财务方面、法律方面、商标、政府部门等等，所以，需要尽可能的想到应对各方面风险的措施。
+
+最后，确定了产品策略靠谱，又可执行，但为什么还是无法落地呢？在我看来，主要原因有以下四点。
+
+- 想不清，想法落地的过程中可能会发生改变，这是最伤筋动骨的。
+- 推不动，包括人员、招聘、推广等等，都有可能推不动。
+- 没价值，行动后发现，全量的客户有限，根本没有增量空间，这就是没有价值。
+- 时机不对，比如我在上篇文章中提到的手机处理视频特效的功能，提出这个想法的时候，当时的手机配置还不足以支撑这个功能。
+
+## 如何执行
+
+相信大家都遇到过这样的烦恼，想法往往能够快速产出，但开发过程中总是存在各种各样的坑，而程序员也没有未卜先知的能力，在执行中难免会出现各种偏差，导致结果与预期相差甚远，甚至在过程中因为想法改变，整个产品推倒重来的情况也不少见。
+
+在此，我先介绍一下屁股理论，我认为一个公司就像人体，CEO就是人的大脑，产品人员就是人体的胃，我们吃进食物，胃就开始消化工作。经过设计加工后来到屁股，屁股就是程序员，程序员产出产品，并交给运营。在这过程中，如果屁股不工作，人就会中毒死亡，但一切正常的时候，你又会忽略屁股的存在。同样，程序员不工作，就没有产品，而产品质量也取决于程序员。
+
+所以，我认为首先要理解清楚程序员的思考方式，这样才能更好的激励他们，提高效率。程序员思维还是比较特别的，主要有以下几点：
+
+- 一切都有标准，都可以量化，都可以实现；
+- 认为管理者应该是理性的机器，公平的处理每件事；
+- 以自我为中心，文人相轻，认为自己最牛；
+- 情绪化，高兴就给你加班做，不高兴，才不管你呢；
+- 高薪误区，管理者认为员工的首要需求是高工资，其次是工作稳定、得到晋升等等。但对于程序员而言，首要是被人欣赏，其次是有参与感以及被认同。
+
+### 如何保证效率
+
+那如何管理程序员，保证他们的工作效率呢？关键在于同理其情绪，关注其需求。
+
+比如，我们会把所有任务拆解成一个个工单，每个工单会有相应的积分，如果工单延误，会扣掉相应积分，如果出bug，也会扣掉相应的积分，最后汇总成总分榜，排名靠前的同学就会特别有成就感和荣誉感，就会形成一个正向的鼓励。
+
+除此以外，我们还可以借助工具来提升工作效率，比如小咖秀爆发的时候，每天新增两百多万新用户，前端机、数据库、缓存全面告急。面对这种情况，我们借助各种工具和服务，包括借调机器扩容前端机，增加缓存，利用云服务等等，都非常有效，在当天就把这些问题解决了。
+
+### 如何保证质量
+
+保证效率的同时我们也要保证质量，从技术角度出发，保证质量的关键在于技术功底，技术水平越高，产品质量就越好。
+
+除此以外，我们还要制定赏罚制度，但是所有的罚款最终都要回馈到团队，用于团建或者其他活动项目。其实，最初我们也担心这样做可能会打击大家的积极性，但后来发现程序员比较较真，只要你有一套完善的系统，能公平的反映赏罚情况，他们是很乐意接受的，并且反而更激发了战斗力。
+
+## 写在最后
+
+简单的去做一件事情，并将这件事做到极致，是我这两期内容想表达的主要思想，也是我做产品的关键思路。另外，服务是全世界最贵的产品，任何产品都离不开其背后各个团队的付出。作为CTO，我们要在人、钱，事等方面深思熟虑，你用错一块钱，可能要损失两块钱，如果选错人，可能会影响整个团队。最后，唯一不变的就是变化。
+
+感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~
+
+## 作者简介
+
+汤力嘉，一下科技CTO，负责旗下秒拍、小咖秀、一直播等产品的研发及团队管理工作。历任酷6、暴风技术总监，在直播、p2p、视频特效等领域拥具有丰富的行业经验。<br>
+

极客时间专栏/geek/技术领导力实战笔记/第132讲 | 徐函秋：转型技术管理者初期的三大挑战（一）.md

@@ -0,0 +1,73 @@
+<audio id="audio" title="第132讲 | 徐函秋：转型技术管理者初期的三大挑战（一）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c3/bf/c31aafb9b488ae1f75b53c853531c3bf.mp3"></audio>
+
+你好，我是小米大数据团队基础数据与用户画像组负责人徐函秋，目前主要负责小米用户画像、行为标签库、ID-Mapping等项目的建设与研发工作。今天我分享的主题是“转型技术管理者初期的三大挑战”。对于管理这件事情，因为每个人的经历不同，所处的环境也不同，所以是“仁者见仁，智者见智”的，我今天分享的内容可能更适合刚刚成为技术管理者，和有志于将来成为技术管理者的同学。
+
+## 工程师生涯中必做的决定
+
+我相信大多数程序员在工作几年，成为团队骨干后，都会面临这样的选择，就是要么继续走技术路线，坚持做研发，要么成为团队的技术管理者，承担更多技术管理的责任。
+
+对于个人贡献者和技术管理者这两个角色，不同的场合有着不同的称呼，比如个人贡献者又叫码农、技术开发，而技术管理者又被称为Manager、小组Leader等等。另外在不同的公司，这两类岗位也有着不同的等级序列，你可以选择继续做个人贡献者，走T序列或P序列，你也可以选择M序列，成为技术管理者。
+
+我个人认为，不论是选择继续走技术研发路线，还是选择技术管理路线，包括在什么时间、什么阶段选择，都没有绝对的好坏，只有适合自己的才是最好的。
+
+那么，我们为什么要成为技术管理者呢？每个人的理由可能都不一样，有人说可以管人，有人说可以提薪，有人说自己更擅长与人打交道，而我选择成为技术管理者的原因，主要有两点。
+
+第一，可以突破个人贡献者的天花板。因为我作为一名研发工程师，可能贡献最多的就是优化用户画像中提取引擎的效率，支持业务各种标签的挖掘需求，比如帮助广告商挖掘出小米用户中有多少人是鹿晗的粉丝等等。而当我成为一名技术管理者以后，就可以带领团队，支持全公司精准运营的若干需求，更好地帮助公司内部业务实现增长，这是之前作为个人贡献者时很难做到的事情。
+
+第二，结合自身的职业规划和目标，提升个人能力。因为对我来说，未来如果有机会，可能还想和朋友一起创业，一起做一些有意思的事情。但那个时候可能就不仅要求自己有扎实的技术功底，还需要有良好的项目管理能力、团队管理能力、沟通能力、演讲能力等等。而成为技术管理者，就可以在实践中锻炼这些能力，对个人成长有很大的帮助。
+
+但是，做一名优秀的技术管理者真的很不容易，可能会遇到各种各样的问题。而我就将自己遇到的一些典型的问题总结分类为三方面。
+
+## 转型初期将面临的三类挑战
+
+一、角色转型引发的矛盾<br>
+当我还是个人贡献者的时候，我的核心竞争力可能就是扎实的工程能力、编码能力，以及对机器学习、数据挖掘等算法和使用场景的掌控能力等等。而成为技术管理者以后，我发现白天除了开会，还需要做跨团队交流，比如跟业务对接、了解业务需求等，另外还需要面试新人、与组员沟通等。因此，问题就出现了——每天面对各种事务性工作，自己的核心竞争力下降了怎么办？
+
+我刚成为技术管理者时，几乎每天晚上九点多钟，大家都下班了，我才能回到工位，完成自己的开发工作。即使如此，在一些项目开发的关键节点上，它的开发进度可能还是会卡在我这里。因此，我每天都感觉自己做了很多事情，自身能力却并没有提升。
+
+后来我逐渐把自己的开发工作缩减，交给小组中的其他技术骨干去完成。但同时我又担忧，自己写代码的时间越来越少，技术退化了怎么办？
+
+恰好我在面试别人时也遇到了这个问题，很多8年至10年工作经验的面试者都非常优秀，各方面能力都很突出，但由于他们已经脱离一线有一段时间了，所以在考核技术能力时没能过关。我认为技术能力是一名技术管理者的基础能力，如果技术能力不过关，我也没办法给他offer。
+
+这件事情引发了我的反思，如果未来自己要走出去时，会不会碰到类似的困境？
+
+除了事务性工作与技术工作的矛盾外，还有思维上的改变，之前在研发岗位上可能只需要做好自己份内的工作就足够了，但现在带领团队的话就需要不断思考，做哪些事情能够产生价值，如何做才能将价值最大化等等。
+
+举个例子，小米在每个季度初都会制定OKR，在我刚成为技术管理者的时候，每次制定OKR时都会思考，在未来的一个季度内，我们小组要做哪些事情，比如支持多少个业务、挖掘多少个标签等等。但我所思考的这些内容其实与上级主管的关注点并不相符。其实上级主管并不太关心工作内容的细节问题，他们更看重工作成果，比如为公司节约了多少成本，提升了多少收益，或者是使团队工作效率提升了多少倍等等。
+
+所以，在制定OKR时我就需要考虑得更全面，不仅要从自身角度与团队角度出发，还需要兼顾公司业务所涉及的各方面问题。
+
+二、在项目管理能力上的挑战<br>
+一名优秀的技术领导者，需要具备良好的项目管理能力，但我在实践的过程中发现了两个问题。
+
+第一，之前作为技术骨干，我们可以很好的完成工作任务，甚至超预期完成任务目标。那现在要领导15人的团队来完成历时两个月的项目，如何能保证按时且高质量交付呢？
+
+第二，对于安排给其他团队成员的任务，因为责任边界不明确，最终导致项目延期交付，面对这样的问题该怎么办呢？
+
+举个例子，领导交给小王和小张一个任务，让他们一起来完成，但没有将责任具体落到某个人上，最后任务交付结果并不理想，小王和小张都认为是对方的责任，这就是责任边界不明确的问题。
+
+三、在团队领导能力上的挑战<br>
+一名优秀的管理者必须具备良好的团队领导能力。在《技术领导之路》这本书中，对领导力的定义是，“所谓领导力，就是创造一个环境，让所有的人都可以发挥出比单干时更大的价值，并不断成长”。但是我们从技术岗转为管理岗之后，并没有人告诉我们该怎么做才能创造出这样的成长环境。我们都是依靠本能并通过不断地学习，在走了很多弯路之后，才探索出了一些方法。
+
+目前在领导力方面，我之前主要遇到了三个问题。第一个问题是，当团队成员遇到困难的时候，如何能及时感知，并有效的帮助其解决问题？
+
+举个例子，去年我们小组加入一位同学，当时，我将一个用户反馈分类的需求交给他解决。就是当小米手机有若干故障的时候，用户会在各种渠道上反馈，我们根据用户的描述，将问题分类为相机问题、主板问题等等，并训练出一个相应的机器学习模型。
+
+因为这个工作不在主线业务内，所以我给了他充分的时间。结果一个月后，他找我沟通，表示想离职。我当时就懵了，具体沟通后才发现，他其实不太想做这件事情，另外，他所做的工作并不是我们团队的主线业务，跟其他团队成员也交流不多，没有融入团队。所以，面对类似这样的问题，技术管理者该怎么办？
+
+第二个问题是，团队成员不断增加，但自己却越来越累，团队例会效率越来越低怎么办？
+
+随着业务越来越多，团队加班就会成为常态，所以我们需要招更多人。但新成员加入后，却感觉自己更累了。因为之前只需要跟五、六个组员讨论工作，打磨工作成果的品质。而团队成员越多，所要花费的心力与沟通时间就越多，这个问题又该怎么解决呢？
+
+第三个问题是，当团队成员之间发生矛盾时，比如A会跟我抱怨B的问题，而B也会吐槽A不懂协作。那该如何沟通，才能协调他们之间的矛盾呢？如何解决问题，才能不影响团队的工作效率呢？
+
+## 小结
+
+在工程师的职业生涯中，一定会面临一个选择，或成为资深技术人，或从技术转型管理。对于后者，我总结了我目前遇到的三类挑战，即角色转型引发的矛盾、在项目管理能力上的挑战、以及在团队领导能力上的挑战。受限于篇幅，本文只谈了问题与挑战，我会在下一篇文章中，根据自己的实践经验，讲讲我对这三类挑战的应对方法，欢迎持续关注。
+
+感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~
+
+## 作者简介
+
+徐函秋，现为小米大数据团队基础数据与用户画像组负责人，目前主要负责小米用户画像、行为标签库、ID-Mapping等相关项目的建设与研发工作，为MIUI、金融、新零售等小米公司核心业务提供大数据相关技术支持，帮助业务团队快速搭建多维分析平台，实现精准运营。加入小米公司之前曾在中科院自动化研究所担任研发工程师，期间参与了实验室的多个横向、纵向项目，并多次参加相关的国内、国际数据挖掘竞赛。<br>
+

极客时间专栏/geek/技术领导力实战笔记/第133讲 | 徐函秋：转型技术管理者初期的三大挑战（二）.md

@@ -0,0 +1,87 @@
+<audio id="audio" title="第133讲 | 徐函秋：转型技术管理者初期的三大挑战（二）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/4b/91/4b6d71e98ee918309179b7fa6704a491.mp3"></audio>
+
+你好，我是小米大数据团队基础数据与用户画像组负责人徐函秋，在上一篇文章中，我分享了转型技术管理者初期遇到的三大挑战，即角色转型引发的矛盾、在项目管理能力上的挑战、以及在团队领导能力上的挑战。那么该如何应对这三方面的挑战呢？今天我会分享自己在过去的两年时间中，针对这三方面挑战的一些实践过程与破解之法。可能不是最好的方法，因为还没有形成完整的一套理论，但它们的确是有效的，也是我一直在践行的。
+
+## 第一个挑战：角色转型引发的矛盾
+
+其实，这个挑战下遇到的问题大多与个人相关，在与上级和同事交流过后，我认为最直接的办法就是明确技术管理者新的核心竞争力，然后拉伸视野，以全局视野思考问题。
+
+### 明确新的核心竞争力
+
+之前做码农的时候，我的核心竞争力是较强的编程能力以及算法的掌握程度。但作为技术管理者，我认为核心竞争力应该转变为综合能力，比如高效沟通能力、项目管理能力、团队建设能力，以及对技术方向的把控能力等等。所以，对于技术管理者而言，真正重要的并不是自己又掌握了新的技术，而是能带领整个团队完成更多有挑战、有价值的项目，以项目的产出结果为导向。
+
+另外，在明确了新的核心竞争力之后，我在思想上也发生了转变，因而解决了我在上一篇文章中所提到的问题——技术管理者到底该如何衡量个人的成长。
+
+换一个角度来讲，如果我们做好时间管理，合理分配每天的工作时间，就不会感觉没有成长，而是变成一种积累。我们可以把每一天都当作一种锻炼，思考怎样才能够更高效的与组员沟通，或是向业务团队了解需求。目前，我每天会拿出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人小团队的效率最高，人数再多效率就会下降，因为我们没有办法清晰地了解到每个人的工作内容和进度，当他遇到问题时，其他人也无法很有效地协助解决。根据这个理论，我将团队的定位与方向划分为三个方面：第一是用户画像标签的挖掘，第二是支持各业务团队的报表需求，第三是数据治理与数据仓库建设。然后，从团队中挑选出技术能力强、工作年限长且有意愿担当中坚力量的组员，让其带领五至六人的小团队负责某一方面的具体工作。这样就有效地构建起了团队梯队，之后再进行沟通或推进时就比较高效了。
+
+第三，一对一交流。这一点非常重要，也是我曾经历过的惨痛教训。定期与团队成员一对一交流，可以增进彼此之间的了解，使我们能够及时感知团队与团队成员目前遇到的问题。现在我每个月都会与一位组员进行单独交流，每次半小时左右，除了会聊一些工作方面的困惑外，也会聊一些关于职业规划及软技能学习方面的话题，并给予每位组员一些建议。
+
+## 写在最后
+
+怎样才算是一位出色的技术管理者呢？我跟自己的主管和下属交流之后，结合自己的思考与沉淀，总结出四点：<br>
+1.能明确团队的定位与目标，可以帮助团队成员更好的成长；<br>
+2.拥有较好的项目管理意识，能带领团队及时产出高质量成果；<br>
+3.沟通能力良好，在团队中能构建良性循环的技术范围和工作环境；<br>
+4.具备深厚的技术功底，关键时刻能带领团队攻坚或克服困难。
+
+除此之外，我认为作为技术管理者，仍然不能完全放弃技术，还是需要投入足够多的时间去了解前沿技术，关注关键技术。这样，团队的成员才会更加信任你，同时也有助于你在团队中培养出某个领域的技术能手，打造一支多元化的技术团队。
+
+感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~
+
+## 作者简介
+
+徐函秋，现为小米大数据团队基础数据与用户画像组负责人，目前主要负责小米用户画像、行为标签库、ID-Mapping等相关项目的建设与研发工作，为MIUI、金融、新零售等小米公司核心业务提供大数据相关技术支持，帮助业务团队快速搭建多维分析平台，实现精准运营。加入小米公司之前曾在中科院自动化研究所担任研发工程师，期间参与了实验室的多个横向、纵向项目，并多次参加相关的国内、国际数据挖掘竞赛。
+
+

极客时间专栏/geek/技术领导力实战笔记/第134讲 | 刘建国：我各方面做得都很好，就是做不好向上沟通.md

@@ -0,0 +1,120 @@
+<audio id="audio" title="第134讲 | 刘建国：我各方面做得都很好，就是做不好向上沟通" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/97/11/97158138174402ffac98b369150ef811.mp3"></audio>
+
+> 
+前百度最佳经理人，果见管理工作坊创始人刘建国老师在他的《技术管理实战 36 讲》专栏中，深入透彻地讲述了“管理沟通”这个主题，其中“向上沟通”一文中，分享了技术管理者们在与上级沟通时常见的坑与痛点，以及对应的解决思路与方案，非常有参考价值，在这里分享给大家。
+
+
+我曾对超过500位技术管理者进行过调查，统计结果显示，向上沟通是技术管理者们最挑战的管理主题之一。那么具体是哪些事情，让管理者们感到头痛呢？
+
+基于上百个关于向上沟通的问题反馈，我发现有如下四类问题是最为普遍的。
+
+**第一类：和上级能不聊就不聊**。主要说法有：
+
+- “上级太忙了，我的事情好像没有那么重要，等他闲了再说吧。”
+- “找不到上级，他很少在工位，每次碰到他都急匆匆地走开，没机会聊。”
+- “把领导交代的工作做好就行了呗，有事没事找领导聊啥，最讨厌有事没事讨好领导！”
+- “总是觉得和上级有距离感，很难聊到一块儿。”
+- “每次见了上级说话都不利索，能用邮件沟通就写邮件吧。”
+
+**第二类：拿捏不好该不该和上级聊的分寸和尺度**。主要说法有：
+
+- “最近取得了一个不错的成绩，要不要和上级说一说呢？”
+- “感觉自己离技术越来越远，有些焦虑，是不是可以把上级当作朋友来聊聊呢？”
+- “某项目很可能会delay，上次和领导打过招呼了，他不置可否，随着形势越来越严峻，我要不要再跟他说一次呢？”
+- “我和合作者有些隔阂，不知道适不适合告诉上级。”
+- “上级招我们来是解决问题的，而不是来给上级制造问题的！”
+
+**第三类：很难领会到上级的意图**。主要说法有：
+
+- “上级告诉我这个项目要加紧了，可是要加紧到什么程度呢？”
+- “上级把这个工作交给我负责，却又安排别人参与进来，这是不信任我吗？”
+- “上级让我去做一个调研，也没有说什么时候要结论，到底急不急呢？”
+- “老板到底在想什么呢？他最近突然不找我了……”
+
+**第四类：如何影响上级的一些观点和决策**。主要说法有：
+
+- “老板常常有不靠谱的需求和新想法，我就不知道该如何柔和又不失礼貌地拒绝。”
+- “上级对项目进度的需求总是很高，如何管理上级的预期呢？”
+- “有个项目需要向领导申请增加人力，如何跟他说呢？”
+- “上级总是不采纳我的建议，有何良策吗？”
+- “上级不懂业务，还喜欢拍板做决策，怎么应对？”
+
+怎么样，上面四类问题，有覆盖到你的情况吗？
+
+由于向上沟通永远是你和上级的“私事”，所以我们无法给出一个普遍适用、一劳永逸的标准答案，也无法穷举所有的向上沟通的场景。但是，我们来逐个分析一下这四类最集中的问题，也不失为一个好的探讨方法，不是吗？
+
+**第一类，关于“和上级能不聊就不聊”**。你不难发现，无论是所谓的“上级太忙了”，还是“找不到上级”，甚至干脆认为就不该和上级沟通，归结起来，都是没有意识、意愿或能力和上级建立良好的“沟通通道”。
+
+那么如何建立良好的沟通通道呢？你可以从以下四个方面来着手和审视。
+
+**第一，沟通意愿**。这是基本前提。作为一名工程师，你不主动和上级沟通问题也不大，因为上级一般会有意识地主动和你沟通。但是，如果作为一名管理者，你还不主动和上级沟通的话，那就相当于已经上大学了，还要家长和老师逼着做作业一样。又如何指望你能带领别人往前走呢？
+
+实际上，在我和中层管理者聊他们对下属的期待时，他们大多都会明确表示，希望我和初级管理者们澄清一个事情，那就是：“上级默认是需要管理者们主动向上沟通和反馈的，而非默认不需要。”
+
+关于沟通的意愿，你可以首先审视一下你的角色：你是一名工程师还是一名管理者？然后再审视下自己的初衷：你是为了自己而沟通，还是为了团队去沟通？通过问自己这两个问题，让你的角色给你沟通的力量和动力。
+
+**第二，事务特点**。即，根据事务的特点，比如是否重大、是否紧急、是否敏感、是否正式等，来确定沟通的方式和频次。这很容易理解。
+
+**第三，沟通风格**。如果说审视事务的特点，是根据“事”来选沟通方式，那么审视沟通对象的风格，就是根据“人”来选择沟通方式。探讨沟通风格和管理风格的工具比较多，比如大家都熟悉的DISC，以及盖洛普的“四大优势领域”等，如果感兴趣你也可以去了解和学习一下，核心是根据沟通对象的风格特点，来选用你们更高效和易接受的沟通方式。
+
+**第四，信任关系**。如果说前面提到的沟通意愿、事务特点和沟通风格，都是为了鼓励你主动加强沟通的话。那么对于你和上级信任关系的审视，就是让你看看，是否可以简化沟通。比如你原本需要长篇大论的汇报，对于默契度很高的上级，可能也就是一条消息的事儿；你原本需要多次沟通的问题，对于信任度很高的上级，可能只要简单一句话，甚至都可以免掉沟通。
+
+所以，你需要花多大精力去准备沟通，很大程度上取决于你和上级的沟通通道的品质。也就是前面的文章中我们提到的信任和默契。信任决定着你们沟通关系的稳定性，默契代表着你们沟通关系的效率和性能。
+
+好了，你如果从**沟通意愿、事务特点、沟通风格、信任关系**盘点下来，还是不需要和上级去沟通，那么这种不沟通就是你有意识的不沟通，它可能带来的破坏性和损失也就可控了，这和消极的不沟通，是两码事。
+
+**第二类，关于“拿捏不好该不该和上级聊的分寸和尺度”**。我曾经在课堂上做过这个练习，把这些问题作为候选清单，让管理者们选出他们认为需要沟通的选项，结果大家给出的建议五花八门。如果我是个管理者，听到这么多建议，估计会更晕了。
+
+为什么不同的管理者的看法会有这么大差异呢？原因是，每个人在评判“该不该聊”的时候，都是基于自己的管理常识（common sense），而每个人在和不同的上级打交道的过程中，形成的常识是不同的，所以会给出不同的答案。
+
+在我看起来，大多拿捏不好“该不该聊”这个问题的情况，都是由于还没有厘清自己想通过这次沟通拿到什么，即沟通的目的和初衷不清晰。很多管理者甚至不清楚该如何来描述自己的初衷。
+
+我这里给出一个参考：沟通总体上有四个目的，分别是**建立通道、同步信息、表达情感和输出影响**。而你和上级想要沟通的目的，也跳不出这四个，只是你需要明确“就什么事”达到上述四种目的中的一个或几个。
+
+比如我们来看前面的案例：
+
+- “最近取得了一个不错的成绩，要不要和上级说一说呢？”这时你可以问下自己：“我是想就此向上级表达我很有成就感？”
+- “感觉自己离技术越来越远，有些焦虑，是不是可以把上级当作朋友来聊聊呢？”这时你可以问下自己：“我是想就此寻求上级的支持和帮助，成功地让他给我一些建议？”
+- “某项目很可能会delay，上次和领导打过招呼了，他不置可否，随着形势越来越严峻，我要不要再跟他说一次呢？”这时你就可以问下自己：“我是想就这个问题再和他做一次信息同步，如果有可能，我会进一步说服他给我提供一些资源和支持吗？”
+- ……
+
+在这类问题上，我们无法去评判哪个目的更重要，或者更应该和上级聊，因为我们不是当事人，只有当事人自己才最清楚这个目的对他来说意味着什么。所以，我唯一能做的，就是给你这个方法帮你厘清沟通的目的，至于每个目的有多重要，你还可以问自己两个问题：
+
+1.这次沟通能给你带来什么价值？<br>
+2.这次沟通能给上级带来什么价值？<br>
+然后，你根据自己的目的，做出自己的选择和判断吧！
+
+**第三类，关于“很难领会到上级的意图”**。对于沟通意图的领会，其实就是对于信息的无失真传递和接收。但是你知道，由于每个人都有自己一套独特的认知体系，所以对于同一个概念的理解都会不同。那又怎么可能做到无失真的领会呢。
+
+相信你也听过这样一个说法：看似是两个人之间的沟通，其实至少是“四个人”之间的对话，哪“四个人”呢？也就是：你想表达的、你实际表达的、对方听到的和对方对于听到内容的理解，这其中每一步传递都会造成失真，所以很难领会到对方的真实意图也就情理之中了。
+
+那么如何降低这种失真所带来的沟通误差呢？我的解决方案是：**通道品质足够高的话就靠沟通通道；如果沟通通道品质不高，信任和默契程度不够，就需要靠沟通工具来对齐了，沟通层次图及“3F”倾听是个不错的工具。**
+
+另外，用一些“回放”的句式来确认，也是个好方法，比如你可以用下面的话来回放和复述你所听无误：
+
+- “你是不是这个意思，……”
+- “你看我理解的是否准确，……”
+
+可别小看它，在沟通重要的事务，以及和不熟悉的人沟通时，这个小技巧能帮你避免大的沟通偏差。
+
+**第四类，关于“如何影响上级的一些观点和决策”**。这是向上沟通中的一大类需求，无论是“希望上级接受自己的建议”或者“拒绝上级的不合理需求”，还是“调整上级的预期”或者“说服上级给予资源和支持”，归结起来都是让上级听从自己的看法和方案，即把自己的认知和期待输出给上级。所以，这类需求其沟通的目的就在于“输出影响”。
+
+为了达到“输出影响”这一目的，你可能会根据上级的风格去选取合适的沟通方式，根据上级的关切去选取合适的内容和呈现逻辑，并根据上级的状态去选取合适的沟通时机，等等。我想说，这么做都没问题，而且有时会很奏效。可是，既然这个问题能够成为管理者们普遍头疼的事情，说明这些效果是有限的，因为问题还是依然棘手。
+
+那么，如何才能有效地对上级实施影响呢？我给大家用下面的冰山模型做一个提示：
+
+<img src="https://static001.geekbang.org/resource/image/74/09/74ed586a629cf2bc998ebfe4475f8909.jpg" alt="">
+
+从上图你不难看出，说服一个人时，沟通技巧是在“术”的层面起作用；而对说服效果影响更大的因素，却是水面下的冰山，即“势”的部分，也就是你对他的影响力如何。
+
+当你对他的影响力很小的时候，你的技术和方案再优秀，影响力也是非常有限的。举个例子，对于一个完全相同的建议，一线工程师提给CEO，和CTO提给CEO，极有可能是完全不同的结果。究其原因，就是你们两个对于CEO的相对影响力差别是很大的。也就是说，如果你要想有效地对上级实施影响和说服，你的影响力是至关重要的。
+
+那么，该如何盘点和提升自己的影响力呢？我们之后的文章中再来继续探讨。
+
+感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~
+
+## 作者简介
+
+刘建国，前百度最佳经理人，果见管理工作坊创始人，TGO鲲鹏会会员，清华大学高级工商管理硕士（EMBA），百度学院优秀培训讲师，埃里克森国际教练学院教练、盖洛普优势教练，国家认证职业生涯规划师。刘建国有着10年的技术团队管理经验，一直专注于对技术新经理的辅导和培养，并创办了“果见管理工作坊”，培训过数百位技术管理者。
+
+

极客时间专栏/geek/技术领导力实战笔记/第135讲 | 钮博彦：软件研发度量体系建设（一）.md

@@ -0,0 +1,78 @@
+<audio id="audio" title="第135讲 | 钮博彦：软件研发度量体系建设（一）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/8d/8f/8d10d57080c59dc7ffa9d809ebecc98f.mp3"></audio>
+
+你好，我是美团高级技术经理钮博彦，主要负责美团点评研发工具栈的建设。我今天想跟大家分享的内容是，我们作为平台团队与业务线团队在软件研发度量中的实践及思考。我将从三个方面展开内容，第一，度量的意义；第二，研发度量体系；第三，度量平台建设。
+
+## 度量的意义
+
+为什么需要度量呢？因为我们在研发过程中总会遇到各种各样的问题，比如下面这三个典型问题：<br>
+1.为什么我们做的产品与用户的期望总是存在差异呢？<br>
+2.市场需求日新月异，这个功能可能还没开发，需求就已经变化了，对此，我们该如何提高团队的反应速度呢？<br>
+3.现在的产品质量到底怎么样，为什么bug永远修不完？
+
+这些问题都是我们在研发过程中经常遇到的，那我们应该如何解决这些问题，使团队更专注、更有效率、更有质量呢？这就是度量的意义所在，我们可以将它总结为三点。<br>
+第一，让目标更明确，比如让大家在项目开始时、研发过程中、项目结束后，对目标有共同的认识。<br>
+第二，让现状更清晰，度量可以告诉我们现状如何、效率如何、质量如何、流程如何以及问题所在。<br>
+第三，让改进更精准，关于如何完善质量流程、体系化研发过程的方法，我们并不缺乏专家学者与著作观点，那怎样找到适合自己团队的观点呢，就需要通过度量来实践。
+
+## 研发度量体系
+
+整体的研发度量体系可以从三个维度来考量：即价值、效率、质量。
+
+### 一、价值
+
+这里的价值，指的是我们要做正确的事，而不是有效率的做一些错误的事情。以此为出发点去架设研发度量体系，我们就可以思考三个问题，第一，怎样度量我们的团队正在做正确的事？第二，既然明确了正确的事情，我们怎样以最高效率交付它？第三，我们既做了正确的事，又很有效率，那交付是否符合我们的预期，符合用户的预期呢？
+
+可能每个公司都有自己的价值指标体系，但整体可以分成两大类，就是商业价值和技术价值，每一类又可以细分为可度量价值与不可度量价值。
+
+- 商业价值的可度量价值包括钱、订单量、DAU、转化率、停留时间等；不可度量价值则包括影响力、美誉度等。
+- 技术价值的可度量价值包括QPS、可用性、响应时间、故障恢复时间等；不可度量价值则包括技术竞争力等。
+
+总而言之，不论是宏观的项目还是微观的产品，都会根据不同场景制定不同的度量指标，再根据这些指标，开始研发流程，并在过程中不断迭代，使交付结果越来越好。
+
+举个例子，我们要做一个产品，开始立项时，定了一堆项目目标，比如DAU增长目标、订单量目标、技术目标等，跟上面提到的价值度量指标相关联。然后进入功能设计阶段，为这个产品设计了N个功能，以其中的某个功能X为例，接着就进入到功能X的研发流程阶段，包括评估与设计、开发与测试、发布上线、反馈与复盘等。
+
+我们在流程实践上的创新之处在于，我们会把项目目标和需求目标相关联，将项目目标作为需求设计的目标之一，从实际结果看这个需求为整个项目目标分担了多少指标，比如做完这个需求，我们可以增长多少的订单量等。
+
+其中，反馈与复盘特别重要，在需求上线之后，可能一周或一个月，我们就需要进行复盘，来判断它到底有没有达到预期。我接触的很多团队都会将复盘放到项目结束后，但我觉得在需求设计过程中进行复盘也很重要，相当于定期追踪。
+
+因此，我们可以把整个项目流程分为三个阶段，即事前计划、定期追踪、事后复盘。这样做能带来什么价值呢？第一，我们所有的需求都是从价值出发，项目的所有参与人都明确目标，能够提升成就感；第二，拆解高价值需求，更早交付，提升ROI；第三，把控需求质量，减少“三拍”需求，降低部门浪费。
+
+### 二、效率
+
+当我们确定价值以后，就需要考虑如何有效率的交付这些价值，我们来看下面这张交付周期图，这是一个非常典型的技术研发流程，包括需求评估、需求设计、待开发、开发、联调、待测试、测试、发布等环节。<br>
+<img src="https://static001.geekbang.org/resource/image/de/e1/deaae8693ed6b2b870df93ad4dd7d7e1.jpg" alt="">
+
+那我们如何度量效率呢？有两个核心指标，一是吞吐率，二是交付周期。
+
+首先来看吞吐率，吞吐率就是在单位时间内，团队能够交付多少产出。而对于产出的衡量，大家也是各有各的看法，有些团队以需求个数或故事点数来衡量，有些团队以价值来衡量，比如这个团队在一季度内为公司增收的盈利等。
+
+我们可以从多个纬度出发综合衡量产出，因为单个纬度衡量可能会有不准确的情况。举个例子，假设张三一年写了1000行代码，李四一年写了800行代码，那张三一定比李四的效率高吗？不一定。再假设李四做了20个需求，张三做了10个需求，李四的效率一定比张三高吗？也不一定。所以，通过综合纬度衡量，可以更加确保对于吞吐率的度量结果的准确性。
+
+再来看交付周期，顾名思义，就是一个需求从提出到上线所用的时长，可能有版本交付周期、需求交付周期、故障修复周期等等，这些都属于交付周期的范畴。
+
+明确了效率的两个核心指标，下面我们来看如何操作能够帮助我们更好地度量效率。
+
+我们在交付周期的衡量中用了两个典型的项目管理工具，一是累计流量图，帮助我们定位瓶颈。如下图：<br>
+<img src="https://static001.geekbang.org/resource/image/d1/4b/d1dbe5f52d80b1f962dc3ceccc76884b.jpg" alt=""><br>
+这张累计流量图的横轴是时间，纵轴是需求个数，我们可以对照某一个切片来看这一天处于各个状态的需求个数，而红色区域和蓝色区域就是我们团队的瓶颈，我们大部分需求都是卡在这样的阶段。
+
+二是价值流程图，它可以告诉我们，需求卡在每个阶段的平均时间。如下图，从这张图中可以看到，我们在待处理阶段与开发阶段停留的时间比较长。<br>
+<img src="https://static001.geekbang.org/resource/image/fc/53/fcd30c03819eea743840d2858382f053.jpg" alt=""><br>
+综合累计流量图与价值流程图，我们能够得知几个常见问题：<br>
+1.需求阶段，需求质量差，需求评估设计时间过长等。<br>
+2.测试阶段，测试数据、环境准备成本较高，自动化测试率低等。<br>
+3.开发阶段，手工重复的工作很多，联调时间长，代码质量差等。
+
+除了上述3个问题，可能还有一些整体的人员瓶颈，比如开发人员少，待开发排序的时间就长，类似这样的问题我们可能会在人员结构上进行调整，或者是提高大家的技术能力等等。
+
+总而言之，从效率这个维度来看研发度量体系，我们主要可以获益三点：第一，识别团队瓶颈，优化短板，减少资源浪费；第二，缩短交付周期，提高吞吐率，提升市场反应速度；第三，对团队产能预估更准确，提高团队工作幸福度。
+
+最后，由于篇幅受限，今天就主要分享度量的意义和研发度量体系的前两个维度，即价值和效率，关于研发度量体系中的质量指标以及度量平台建设，我会在下一篇文章中继续分享。欢迎持续关注。
+
+感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友。
+
+## 作者简介
+
+钮博彦，美团高级技术经理，负责美团点评整体的研发工具栈建设。曾就职于微软中国、雅虎北研、唱吧等公司，从事系统开发、DevOps和质量保障等相关工作。一直专注于提升研发整体质量与效率，及其流程和平台建设。
+
+

极客时间专栏/geek/技术领导力实战笔记/第136讲 | 钮博彦：软件研发度量体系建设（二）.md

@@ -0,0 +1,81 @@
+<audio id="audio" title="第136讲 | 钮博彦：软件研发度量体系建设（二）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/2c/57/2cc5d19e893c232f56e16982c62e9157.mp3"></audio>
+
+你好，我是美团高级技术经理钮博彦，主要负责美团点评研发工具栈的建设。在上一篇文章中，我分享了研发度量体系建设中度量的意义与度量体系中的前两个衡量指标，即价值与效率，今天我们继续聊一聊度量体系中的质量指标以及如何建设度量平台。
+
+## 度量体系之质量
+
+在我们明确了价值，提高了效率之后，我们就需要判断产品质量是否能够达到预期。质量度量的重点有两个，一是以结果为导向，二是质量问题，越早发现，越易修复。
+
+其实这是两个老生常谈的问题了，但同时它也引发出我们对质量的两个关注点：第一，关注线上质量，包括服务端和客户端等；第二，关注过程质量，包括需求质量、代码质量、测试质量、发布质量和系统质量等。
+
+### 线上质量
+
+我相信多数团队都有线上质量看板，从中我们能够得知很多信息。首先，对于服务端，我们可以将度量指标分为三类：第一，线上故障，以线上故障数、线上故障恢复时长、线上缺陷数等指标来衡量；第二，稳定性，以服务可用性、错误类型分布、错误率、报警数、错误数量等指标来衡量；第三，性能，以接口响应时间、慢消息、接口慢响应率、慢SQL、慢缓存等指标来衡量。
+
+其次，对于客户端的线上质量度量指标，多数人会从Crash率、页面错误率等维度去衡量客户端的稳定性，而对于它的性能，我们可以关注安装包大小、页面加载时间、启动时间、FPS、卡顿、流量、CPU等影响因素。
+
+### 过程质量
+
+之前提到，过程质量，一般可以从需求质量、代码质量、测试质量、发布质量和系统质量等维度进行度量。
+
+1.需求质量<br>
+30%-40%的效率问题和质量问题来自于需求质量，需求质量问题有很多产生原因，比如没搞清楚需求的目的、不明确需求的目标，或对需求的理解千人千面等等。那我们怎样把控需求质量呢？
+
+我们可以将需求质量指标分为两类，第一，需求整体质量，可以关注需求质量评分、需求Bug数、需求千行代码Bug数等因素。第二，需求自身质量，可以以需求打回次数、需求变更次数、需求质量Bug数等因素来衡量。
+
+2.代码质量<br>
+我们在工作中，经常会遇到代码质量差的问题，但是有多差、差在哪里，又很难说清楚。举个例子，我们有一个团队大约有30个开发人员，QA六个月报了1500个bug。这个数据体现了一个非常严重的问题，就是开发人员在交付代码时，无论是交付上线，还是交付给QA，其代码质量都很差，结果就是QA与开发人员会周旋于bug的沟通与修复，导致团队效率极大降低。
+
+因此，实时关注代码质量就显得尤其重要，我们可以将代码质量指标分为基础信息、可靠性指标、可维护性指标这三类。首先，基础信息可以通过代码质量评分、文件数、类的数量、方法数量等进行衡量。其次，可靠性指标可以依据代码重复率、代码圈复杂度、千行代码严重缺陷度和安全缺陷度来衡量。最后，可维护性指标可以关注高复杂度函数数量、迷惑方法名数量、技术债务比等因素。
+
+另外，我们有一个不成文的实践，就是你要么先单测，要么将全复杂度降到一定程度之下，比如，只要你将全复杂度降到15以下，就可以不用写单测。我们通过这些手段，能够让大家快速了解到自己的代码质量。我们还会用一些短平快的方法去降低代码的复杂度，屏蔽代码质量引来的风险。
+
+3.测试质量<br>
+测试质量指标可以分为四类，第一，整体质量，可以查看千行代码bug率、整体漏测率、测试覆盖率、小流量灰度漏测率、提测打回率等；第二，bug统计，可以查看缺陷新增趋势、解决趋势、生命周期分布和有效缺陷率等等；第三，单元测试，可以关注单测通过率与单测覆盖率；第四，单元化测试，可以通过自动化测试通过率、覆盖率、稳定性等因素来衡量。
+
+4.发布质量<br>
+不知道你会不会很关注发布质量，但在线上的bug中，很多都是由于发布环节的不规范导致的，对于发布质量的度量我们也将它分为三类。
+
+一是发布整体，我们在发布环节有很多数据可以用来观察发布失败率及次数、发布和需求关联覆盖率、高峰期间发布数量及占比、非窗口期间发布数量及占比等指标。二是构建相关，我们可以关注构建成功率、构建次数与频率、构建失败平均恢复时长等指标。三是回滚相关，比如有预发回滚率、小流量回滚率、全量回滚率，等等。通过关注这些因素都可以使我们知道并保证一个平稳的发布过程。
+
+5.系统质量<br>
+我们可以从系统整体看服务数量、最长链路等指标，也可以看性能相关的方面，比如最大QPS、系统响应时间、CPU和客户端专项测试数据等，还有安全性指标，比如安全漏洞严重问题数等等。
+
+### 全流程质量度量
+
+我们在拿到这么多维度的质量数据之后，要做的就是全流程质量度量。全流程质量度量的目标有三点：需求质量评估、代码质量评估和风险预警。就是从多个维度去观察需求开发过程，对需求上线之前的质量进行评分，以及预测上线之后的风险。目的是提高研发过程中的效率，避免上线之后再做一些重复动作。
+
+总而言之，建设质量度量体系能够带来三方面的好处。第一，产品整体质量可以实时评估；第二，可以提早暴露质量风险，使我们能够提早进行修正；第三，可以使质量保障流程有的放矢，加快落地速度，效果也会非常明显。
+
+说了这么多，想必你已经清楚了我们为什么要度量，以及如何度量，接下来再聊一聊度量平台的建设。
+
+## 度量平台建设
+
+我们先来看一张度量平台建设的云图，也是我们目前的整体架构图。<br>
+<img src="https://static001.geekbang.org/resource/image/b9/69/b96ff396da62b05b22642f3a2b6b9e69.jpg" alt=""><br>
+在我们公司内有各种各样的业务系统，然后有两个数据渠道，一个是实时数据流，主要用于分析代码质量，每一次代码提交都触发持续集成，我们可以在代码提交时了解到它的质量。另外，实时数据还可以支撑我们线上的监控情况。大家可以看到，我们在这块采用了ES来做数据存储，主要是因为我们实时分析的数据量较小，如果你的实时数据分析需求较大的话，可以采用Flink或Spark Streaming。
+
+另一个是离线数据流，我们的离线数据量非常大，每天会有几百G的数据进入数仓，包括需求的流转数据、代码提交、持续集成、发布数据、各种线上的监控等等，最后都会汇总到数仓。在数据立方体建设方面，我们主要采用Kylin。另外，我们的实时数据最终也会通过ETL的方式，汇总到离线数据库中，为之后的离线数据分析做数据支撑。
+
+最后再讲几个难点，也是我们在建设度量平台中踩到的坑。<br>
+第一，技术选型，我们当时有许多考虑，比如用Flink或Spark Streaming来做实时数据，最后还是决定用非常短平快的ES和离线的Hive。
+
+第二，指标体系建设，这是一个非常大的系统工程，非常耗费人员精力。由于美团点评有非常多的业务，每个业务都有自己的业务形式，包括发版周期、研发流程都不一样，甚至各个业务也处在不同的发展阶段，种种“差异”就造成我们的指标体系非常庞大，因此，我们就需要以多种视图、多种维度来建设指标体系。
+
+第三，数仓建设，它有三个难点，一是数据立方体的建立，因为指标体系庞大，所以需要建设多维度、多字段组合的数据立方体。二是异构数据，因为业务系统很多，我们需要导入大量的数据，与自己的数据格式对齐，非常耗费精力。三是数据快照，简单来说就是将每天的需求的Change log快照下来，只有这样，我们才能得知最后一个需求在每一个状态下停留的时间长度，处理量也非常庞大。
+
+以上三点就是我们在度量平台建设方面踩过的一些坑，因为度量平台建设这个话题比较大，有很多未能详尽之处，如果你感兴趣，我们可以继续在留言区讨论。
+
+## 总结
+
+通过两篇文章我分享了关于研发度量体系的意义、度量体系指标和度量平台建设，在建设研发度量体系中还有三个要点：第一，度量数据的生产者要成为度量数据的消费者；第二，度量是一个系统工程，不同的业务团队有不同的流程，不同的发展阶段有不同的重点，不同的角色有不同的视角，因此建设度量体系应该以系统性思维去思考；第三，度量不是绩效考核的工具，度量是为了及时解决问题，优化结果。
+
+最后，度量体系能够帮助团队，建设关注价值、效率、质量的文化理念，可以使我们的目标更明确，提升团队战斗力与成就感，使现状更清晰，减少资源浪费，也能够帮助我们改进更精确，无论是技术革新，还是流程优化，我们都能够根据度量指标有的放矢。
+
+感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友。
+
+## 作者简介
+
+钮博彦，美团高级技术经理，负责美团点评整体的研发工具栈建设。曾就职于微软中国、雅虎北研、唱吧等公司，从事系统开发、DevOps和质量保障等相关工作。一直专注于提升研发整体质量与效率，及其流程和平台建设。
+
+

极客时间专栏/geek/技术领导力实战笔记/第137讲 | 成敏：创业者不要成为自己公司产品技术文化的破坏者.md

@@ -0,0 +1,47 @@
+<audio id="audio" title="第137讲 | 成敏：创业者不要成为自己公司产品技术文化的破坏者" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/6f/b5/6f6af2f7a3462ab761f4100e1f76a6b5.mp3"></audio>
+
+你好，我是成敏，跟不少技术创业者沟通，听他们吐槽创业中的坑之后，一个很深的体会是，技术创业者想要在市场驱动文化的冲击下，保持公司的产品技术文化是一件挺不容易的的事情，需要他们在多个方面持续不断的付出精力、承担压力。
+
+## 不要让自己成为公司产品技术文化的破坏者
+
+首先很重要的一点是，创业者在创业的过程中要克制自己，不要让自己成为自己公司产品文化的破坏者。但往往在现实中，很多时候，创业者不自知的就扮演了这样一个角色。
+
+**1.不要用战略代替用户需求**<br>
+很多创业者，创业路上走了一段时间之后，往往会偏离最初的出发点。当然这不一定是坏事，之前IDG资本曾有过一个统计，众所周知，IDG资本投了很多互联网领域的创业公司，根据官网的数据，他们投了750家企业，成功上市或成功退出的有170家，成功率还是蛮高的。而根据这个统计，大部分成功上市或成功退出的企业，最终上市或退出时的业务模式和战略方向，跟他们找融资时提供的商业计划书里所承诺的业务模式和战略方向几乎都是不同的。
+
+互联网行业瞬息万变，创业者在创业过程中调整方向并没有什么不妥的，关键在于是如何调整方向的。我听过的很多情况是，创始人出去参加了个会，或是跟同行交流后，觉得人家这模式特别好，自己回来也要做，就成了所谓的“战略方向调整”，用这种上层的战略调整，替代产品的一线反馈，去驱动产品运营。
+
+很多时候，这种所谓的调整或变更都是一拍脑袋造成的，带来的很多需求也是不靠谱的。而这种需求做完之后，放到市场中一试，基本都不会有很好的效果，但这种方式给公司带来的伤害却是非常大的。所以，创业者一定要非常慎重的规划自己的战略方向和业务需求。
+
+而调整战略方向和业务模式相对靠谱的方式是，通过各种用户数据、市场数据、业务数据去迭代产品，去调整方向。毕竟互联网的行业天条是要顺应用户需求去设计产品，而不能凭空创造用户需求。尽管大部分用户不能清晰的描述他们的需求，但100%会用脚投票，各类行为数据就是最好的了解用户需求的途径。
+
+**2.别把自己当成主流用户代表**<br>
+创业经常犯的另外一个错误是，经常把自己当成主流用户，并把自己的需求当成主流用户的需求。而互联网行业三大理论基础中的长尾理论表示，个人的需求只是长尾中间某一个非常细分的点上的需求，只能代表自己，不能代表主流用户。
+
+所以，有时当创业者自上而下地提出需求，让产品增加某些功能、往某些方向发展的时候，很有可能是不靠谱的。
+
+创业者应该做的是把自己的需求当成所有需求的来源之一，无论是客户的、用户的、领导的、还是内部规划的，任何需求，一律放入需求池，统一管理。然后通过集体决策、分工协作等方式，把各个需求分解到各个版本里去慢慢实现，永远不要想着把所有需求一部到位，这样做对公司的破坏性也是非常大的。
+
+另外，在需求实现的过程中，管理者要尽可能的保持迭代节奏，减少变更，实在不能按期完成需求时，也要尽可能的将保住节奏放在更重要的位置。就像跑马拉松一样，你稍微慢一点没关系，重要的是一定要保持住自己跑步的节奏。
+
+## 尽早建立与产品技术相适应的管理体系
+
+一般创业公司在早期规模还比较小的时候，可以用“一俊遮百丑”来形容，也就是如果你公司的模式势不可挡，带来了巨大的营收和利润，那就可以一俊遮百丑，掩盖公司运转中的各种问题。正如很多人秉持的管理理念——公司本身的高速发展，就是对团队最好的管理，也是对员工最好的激励。
+
+但从长远来看，公司还是需要尽早在内部建立起一套与产品技术相适应的管理体系，特别是当公司人数到了200人以上之后，这一点就尤为重要。
+
+**首先要建立起配套的考核、薪酬、激励制度**。公司组织架构和各项制度需要在产品技术运用和市场导向中取得合理的平衡，同时，制定的薪酬体系和员工激励制度要结合互联网产品技术的特点，力争最大化的调动员工热情、激发员工积极性。
+
+**其次要打造完善的职业通道和人才梯队**。在产品技术职业职业通道的建设上，关键在于给员工展示出清晰可行的上升通道和各个职业层级明确的要求，让员工找到努力的方向。而在产品技术人才梯度的建设上，关键在于高中低合理搭配，一个团队中不可能都是杰出的产品技术人才，杰出的人才往往需要一群合格的人才来配合，完成日常的开发工作，实现设计好的系统和产品。
+
+以技术团队为例，之前看到过一种团队成员的分类法，把员工分为独狼、农民和英雄三大类。其中，独狼大多都是优秀的程序员，但是他们遇到问题的时候往往喜欢独自一人去解决问题。因此，虽然他们能解决问题，但也会比较容易引起团队内部问题和纠纷。农民则是指那些脚踏实地、有条不紊的了解周边情况、配合团队工作、推进项目运转的普通程序员。英雄则是那些能承担需要极大努力才能完成的任务，并最终取得成功的人。在承担责任和付出努力等方面，英雄和独狼有些相似，但英雄更能够与他人配合，在团队工作和开发过程中获得成功。
+
+而根据理论，比较合理且合适的团队成员组成是，1-2名英雄+大多数的农民+极少量的独狼。除了打造出搭配合理的人才梯队外，创业者也需要提前做好备份人才储备和人才资源池的建设，为业务的爆发式增长做好准备。
+
+**最后要打造优秀的技术培训体系**。在建设好职业通道后，就要搭建起和产品技术职业发展通道关联的技术培训体系，每一个职业层级都需要有不同的培训学习计划和锻炼计划，帮助产品技术人员不断成长与晋升。同时，也要建立基于内部资源的讲师、课件和技术培训体系，形成学习型组织，为公司提供造血能力，让培养的员工能早日支撑公司的发展。
+
+## 小结
+
+总的来说，创业者打造并保持公司产品技术文化的时候，首先就是要从战略和模式上重视产品技术，克制自己，不要让自己成为公司产品技术文化的破坏者。其次在管理实践层面，要尽早建立和产品技术相适应的管理体系，从员工考核激励、员工职业成长、人才梯队培养等维度出发，打造优秀的产品技术文化。
+
+