[转]称职的技术leader相当于100名工程师

【编者按】抛开这个夸张的骗点击量的标题，我希望告诉你：称职的技术主管确实是拥有普通工程师10倍功力的麒麟之才。不过，这位技术主管在技术之外还需要将强有力的开发能力传授给队伍中的每个成员。在技术主管的指导下，幸运的工程师会感觉自己拥有了10倍的能力，并可以享受前所未有的强大支持。

而且，我希望告诉你，技术主管用头上的白发换来的这种神奇的10倍魔力的光环，并不一定会牺牲任何人的幸福。技术主管扛下了所有工作中的“杂项”，大大加快了重要工作的生产力，从而确保团队成员可以尽情享受工作和生活的乐趣。对于那些拥有一个称职的技术主管的团队成员来说，这是莫大的幸福。

在称职的技术主管的指导下，幸运的工程师会感觉自己拥有了10倍的能力。

我是Webflow的一名技术经理。我们相信团队之幸即用户之幸，所以我们在团队上付出得越多，用户的受益就越多。我们坚持做有意义的工作。我们追求长期快乐的工作，我们将此视为长远的目标。我们深信，工作应该与生活快乐并存，我们认为工作与生活相辅相成。

技术主管可以帮助我们实现这些信念。因此，我撰写了一份技术主管指导手册，用以支持这一具有挑战性的领导角色，并在这里一字不差地复述。我们希望即便身处一个惯于标榜傲慢与荒诞的世界里，你也可以尽情地追求激情与成功。

下面请尽情享受我们的技术主管指南（点击此处查看全文目录）：https://github.com/webflow/leadership/blob/master/tech_lead.md

▌Webflow技术主管指南

欢迎

你好！欢迎你阅读此文。很荣幸你能阅读此文。

如果你接受了技术主管之职，那么首先恭喜你，这证明你拥有卓越的技术力和领导才能，实属罕见的人才！也许，你对技术主管一职感到好奇，想弄清楚这个职位是否适合自己，那么你来对地方了。

不瞒你说，技术主管所承担的责任与普通工程师的日常工作相比有着惊人的跨度。这本指南可以帮助你迅速掌握如下内容：

1.  什么是成功的技术主管
2. 如何从纯粹的技术角色转而兼顾管理与技术，以及如何达成这一职位的期望
3. 应对常见挑战的战略
4. Webflow的“管理职位”所呈现的立场（提示：这里说的是如何更好地服务团队，而非专权）

▌那么究竟什么是技术主管？

技术主管最基本的定义是，“全权负责项目的成功，30%的时间写代码，其他70%的时间管理项目。”主管的称号并非浪得虚名，因为你需要在波涛汹涌的职场上为你优秀的工程师团队指明方向，指导他们，引导他们远离危险，并为他们排除困难，让他们充分享受有意义的工作。

说起来容易做起来难。

技术主管必须拥有和培养各种的技能，但是最重要的是待人真诚，清晰的沟通，以及卓越的技术力。这些品质缺一不可。身为技术主管，你必须一手掌握管理，一手掌握技术，充当项目预期目标与开发任务之间的联络人。一个项目的成败很大程度上取决于技术主管，而Webflow公司的责任是确保他们能够获得成功所需的一切支持。

Webflow的管理有何不同。

在大多数公司内，管理层并不受员工的待见。在员工心目中，管理层不过是把员工当成“劳力成本”，是可以只手遮天的专权者。但Webflow并不是这样的。我们尊重每个团队成员，而才华是其次的。人与人之间可以建立理解和协作的关系。技术主管需要为培养这样的环境而负责，且技术主管只有本着为人民服务的态度才能建立这样的环境。

技术主管的工作不仅是微观管控，更需要为大家服务，他们需要站出来支持团队，为团队成员服务，而团队成员则为技术主管工作（而不是相反的方式）。技术主管可能要对项目的成败负责，但技术主管与团队的协作才能成就项目。

下面是关于如何为团队提供最佳服务的两点提示：

1.  直面项目需求。不要害怕挑战你的团队，只要你是发自真心的关心他们。
2. 如果项目成功，要大胆地赞赏团队，给予他们一切的荣誉，因为没有他们就没有成功。

▌为什么想成为技术主管？

也许你并不想成为技术主管，这也无可厚非。Webflow旨在为工程师提供许多不同的机会来发展他们的职业生涯，包括个人贡献奖，他们与高级管理职位一样对公司做出了卓越的贡献。技术主管要比普通工程师承担更多压力，尤其对新手技术主管来说，在管理团队和贡献代码之间寻求平衡本身也是一项挑战，这也完全正常。

即便如此，升任管理职位的好处还是很多的。首先可以有机会参与公司更高层的决策。对Webflow用户群的影响力也会提高。在业绩考核中拥有更多话语权，并在今后拥有更多职业发展的机会。这个职位经常被视为“高级”工程师头衔的垫脚石，也是荣升工程经理的先决条件。技术主管需要指导并帮助其他工程师成长。对于有些人来说，这将带来更加令人兴奋的挑战，并促使他们挑战更高的极限。

▌怎样才能成为技术主管？

只要你开口！其实很简单。找个单独的机会，跟你的经理表明你有兴趣成为技术主管。你的经理有责任将下属推上新的职位，根据你目前的经验，他们可能提升你为下个项目的技术主管，或者提供机会让你发展技术力，将你培养成技术主管。

▌管理团队的时候，需要做些什么？

技术主管主要负责以下几方面的工作（没有特定顺序）：

1. 与产品经理密切合作，在最后期限前设置合理的预期目标，并确保项目不会出意外。
2. 将项目内容分解成可以消化的任务，将这些任务关联到迭代周期的交付产物中，并时刻关注交付产物。
3. 为团队提供充沛且不间断的工作时间，确保他们的工作状态持续流畅，并为团队保驾护航，不受任何阻碍与分心。
4. 确保团队成员在任何时候都有充足的工作，确保没有人“无所事事”。
5. 勤勉地审查代码，力保一次性通过QA测试，并尽可能的贡献代码。
6. 根据团队任务的需要，随时提供支持与帮助。（既要拿出尽可能多的时间来埋头苦干，还要在团队需要的时候给予支持和帮助。）
7. 不定期地与其他们部门合作。

与其他们部门合作

产品经理负责将用户的期望落实到产品功能中。市场营销部分负责宣传这些功能。售后团队确保Webflow的产品在承诺的功能上有出色的表现。每个部门对Webflow的持续成功和发展都至关重要。工程部门则是重中之重，而技术主管担负着与这些部门之间的联络。

技术主管负责以下列两种主要的形式将项目的状态传达给其他部门：

1.  每周与其他们部分召开一次例行会议，其中产品经理或售后联络员[1]也可以参加。无论产品经理或客服联络员参加与否，这个会议都是必须的。
2. 每周一次向全公司汇报“所有进程”。

有些项目可能没有产品经理或售后联络员，在这种情况下，需要由技术主管向工程经理汇报团队的状况和需求。有时候，市场营销部门也可能就何时可以开始宣传某项功能，征求技术主管的意见。

跟进任务的进展状况

优秀的技术主管知道如何将项目分解成有意义且易消化的任务（易消化指的是大约3天左右可以完成的任务）。这可以让团队成员全面了解项目以及最后期限，也确保技术主管可以每周为团队成员分配任务。将项目分解成小任务是一个很耗时的过程，且是一项持续性的工作，但却对培养团队成员的成就感十分重要。还有助于技术主管在通往未知结果的道路上创建路标，并将这些未知的结果控制在小范围内。

ISSUE

在项目刚启动或着手一个持续性的里程碑时，技术主管必须彻底审查项目规格，并尽力将规格分解为便于跟进的任务，每个任务为期大约1-5天（审查代码和QA工时不包含在内），最佳时间安排为3天。然后，将这些任务划分到里程碑中。每个里程碑都是带有截止日期的交付产物。

专家建议：可以让团队帮忙将里程碑分解成任务。如果团队中有人比你更加了解某个专业领域的知识的时候，这是唯一的选择。这种情况下，委派团队成员处理这项工作更加合理，但是务必审查所有的任务，并验证任务的范围或做出的假设。

Webflow目前的做法是在GitHub中为每个任务创建issue，然后在issue中跟进这些问题。

这个issue在GitHub上提供了集中且清晰的问题概览图，其中列出了里程碑、预期的交付日期，以及相关任务。这些任务：

1.  可以很容易地将任务分配给团队成员，由他们负责提交解决该问题的PR。
2. 显示任务的GitHub问题编号，解决该问题的PR，以及问题的标题。最好以表格的形式呈现这些内容。
3. 提供每个里程碑的预计完成日期，以及里程碑中每个问题的状态。

任务

每个问题（或1-5天的任务）必须明确指出问题所需要实现的规格部分，以及所涉及的Webflow代码库（如果有代码的话）。我们发现每个问题最好包含以下内容：

1. 清楚地指出问题所需要实现的原始规格，以及一些图形化内容帮助工程师完成任务，包括来自规格或Webflow本身的截图或视频。
2. 列出最有可能的待办事项，帮助工程师构划他们必须解决的问题。

以下是一个任务模板。你可以将其保存在GitHub的问题中，并把它的名字加入到issue中。

好难啊

创建issue会花费太多时间，让人不免怀疑是否在做最有效的工作。请相信我们，这一步至为关键，issue越清晰，项目成功的可能性就越大。根据项目的规模不同，这项工作可能需要花费一周或更长的时间。没关系。制定严密的计划，并严格地执行。你的团队会为此心存感激。帮助团队建立成就感至关重要。

专家建议：在开始创建主问题之前，针对具体的规格建立一个文档记录下任务列表会很有帮助。当你写出了所有任务之后，创建一个问题，写下基本的描述并重点强调规格要求，然后进入代码库找到问题所涉及的代码。

在issue中显示进度

可以将issue看作仪表盘，上面显示了与项目相关的每个问题的进度状况。这反过来也凸显出了整个项目的状态，以及整个交付产物。例如，下面的例子展示了一个issue的进展状况：

产品经理（或其他相关人员）可以根据上图，快速评估项目的进展状况。例如，当人们看到BETA里程碑大约完成了75%，并且由于任务分解成了大约1-5天的量，因此很容易判断项目是否可以按照计划完成。

技术主管理应负责维护上述issue的状态，尽管可能他们更希望让每个团队成员分别更新各自负责的问题的状态。每个任务应当显示下列重要信息：

• 项目及截止日期
• 其下所有的任务
• 其下所有的PR
• 简短的描述
• 进展状况

专家建议：如果某个主问题列表过长且不易操作，那么可以将其分解成多个主问题。

项目（即交付产物）

技术主管必须向产品经理（如果没有产品经理的话，就向工程经理）汇报各个项目的进展状况，以及每周提交完整的报告。项目和各自的任务由技术主管决定，并经过了产品经理、工程经理及其他人的确认。

所谓“项目”是：

• 一个主要的交付产物，通常拥有六周的时间跨度。
• 负责推动一系列的任务和问题，且当所有任务和问题在正式产品环境中落实完成时，里程碑完成。
• 根据交付产物类型命名，例如根据阶段、上线次数或版本等命名。
• 指定了截止日期。

大型项目的计划结构应该只包含两层：项目>任务。项目本身应属于某个功能的范围，例如富文本编辑器、交互2.0等，这些功能可能需要数月（或数年）才能完成。里程碑是可以持续交付工作的“块”，通常按照一定顺序完成。除非里程碑之间有很高的相关性，否则一般情况下，团队不会并行开展多个里程碑的工作，但是从一个里程碑转到另一个时，可能会有一段时间需要同时兼顾两个。

专家建议：请时刻警惕范围的扩张。范围的蔓延在所难免。一旦范围发生变化，一定要重新审核里程碑的截止日期，并清晰地传达新范围的影响。

项目类型

项目是主要的可交付产物，尽管从语义上可以将它们按照阶段、上线次数或版本划分，但是它们的功能都是相同的。无需过多地关注这些差异，但对产品经理和市场营销来说，相应的命名会很有帮助。

针对未知的方向划分任务

尽管很难估计里程碑的截止日期，但Webflow要求技术主管尽可能地指定比较现实的日期。这个限制起初看起来似乎很有限，但是我们只是希望大家多多关注截止日期，而并不是说截止日期不可动摇。

与其依赖项目模糊的截止日期，还不如“针对未知的方向划分任务”。我们的功能需要缔造全新的产业领域，一个JavaScript世界里前所未有的领域，因此通常不可能清楚地预知即将面临的工作。虽然其中有一些很明确，但是即便是最好的技术主管也会对一部分规格束手无策，他们可能会说，“呃，我不知道这需要多长时间才能完成。”要想打破这种局面，只有将这些未知的结果分解成小任务，尽快揭开这些未知之谜。

要坚定地对任务进行优先级排序。等到掌握了更多信息的时候再进行调整。通知产品经理团队当前正在做的任务。当未知的任务完成到一定程度时，里程碑的截止日期会浮上水面。

专家建议：有时在做未知的任务的时候，原本主问题的列表中没有的一些新任务会涌现上来。没关系，如果这些任务是实现里程碑必须的，那么尽管加进来就好。如果因此影响了里程碑的截止日期的话，请务必通知经理。

会议

技术主管应当每周组织一次最长30分钟的项目会议，最好选在周一早上，议程大致如下：

1. 简单的回顾：

1.1 上周哪些任务进展顺利？

1.2 上周哪些任务进展不顺利？

1.3 如果进展不顺利，我们应当如何改善？

2. 每个成员汇报：

2.1 当前任务的状态？

2.2 遇到了什么困难？

2.3 如何帮助你解决困难？（技术主管）

3. 向每个团队成员分配新任务

4. 向产品经理汇报项目的状况

5. 回答大家的问题，开个小玩笑带动气氛

除了上述每周的例会外，不应再开展任何别的全员会议。Slack上的对话或结对编程不能算作“会议”，团队成员根据需要自由组织。

每周的状况

可以要求每位工程师每天向#status-front-end和#status-backend频道，汇报自己是处于“按计划进行”还是“落后于计划”，而技术主管可以相应地确认每天的状况（简单地在Slack上为大家点赞）。这可以迫使每位工程师为自己每周的任务负责，如果出现任务大幅落后或落后超过5天的情况，技术主管可以及时介入。

专家建议：帮助团队成员一次专注于一到三个并行任务。如果超过三个任务则不利于跟进，所以请帮助他们减少或合并任务，并找出任务过多的原因。

敏捷开发？项目经理？

你可能在想，“这种管理项目的方法属于哪种？”它可能类似于敏捷开发，它拥有两周的迭代周期和类似于“Scrum”的每周例行会议，但是它没有Scrum主管。虽然我们喜欢敏捷方法论，我们的目标是尽快交付，根据需要随时调整，但是Webflow并没有采用具体的方法论。目前我们一切进展顺利，而且随着项目的发展，我们随时可以重新评估。

▌技术主管可以管理哪种类型的团队？

Webflow将其有才华的工程师安排到仅有一位技术主管负责的Action和Permanent团队。

团队	描述
Action	此团队围绕一个功能（或原型）而集合，并在功能完结时解散。
Permanent	此团队围绕一个领域的问题而集结并长期工作，不会被解散。例如：性能和稳定性团队。技术主管和团队成员可以在各个团队之间轮换。

加入什么规模的团队？

团队的规模不尽相同（甚至可以只有一个人），但一般来说，团队包含3名成员，其中包括技术主管。管理共同参与解决同一个问题的两个人相对容易，但是一旦开始管理第3个、第4个或第5个人，所产生的交流成本就会急剧增加。这种情况不仅发生在技术主管与成员之间，团队成员之间的两两交流也是同样的。虽然较大的团队也可以良好地工作，但是3个成员是一个好的开始。

并不是说每个团队都必须而且只能包含3个成员。一个Action团队可以包含7个成员，包括技术主管，他可以将团队划分成两个或三个小组，每个小组集中完成功能内的任务。然后技术主管可以为每个小组指定组长，为本组的工作负责。请记住各个小组都应该有效地关注功能，并互相协作解决问题，才能减少并行使用单个资源时所引发的阻塞延迟。

上述的团队结构可以由后台和前端开发工程师组成。Webflow不希望明确区分这些工程上的分工，以及非工程之间的分工，比如设计师。组建全能的团队是有效实现功能的终极阶段；请根据个人意愿和项目需求决定是否要这么做。

团队的效能与组织

组织团队基本上有两种方式。第一种是根据“功能”划分团队，这种方式有利于团队合作解决密切相关的问题，另一种是根据“资源”划分团队，这种方式有利于个人并行从事完全不相关的任务。这两者都有自己的优势，但我们要求技术主管尽可能采用功能方式划分。

专家建议：并行工作需要定义明确的范围。如果领导的项目中，设计规格的迭代推进的同时，开发迭代也在并列进行的时候，最好只根据功能划分团队。

▌救命！项目进度落后了！

没关系，真的。去喝点咖啡，或者晒会儿太阳，等到内心的波澜恢复平静的时候再回到办公桌前。

几乎每个项目都会遇到一些未知的因素影响到交付日期。并不需要拼命避免这种情况，可以试着做好心理准备。你需要在做预估的时候考虑到这一点。这再正常不过了，而且所有的技术主管都有这样的经历，是不是觉得很安慰？这不过是好与出色的区别。

如果因为不能如期交付项目而感觉伤心内疚，那么就会极大地抹杀士气。士气是团队最宝贵的资源。最好把这种“延误”想成是“延期”，并作相应的处理。Webflow认为软件开发是一项艰难的工作，所以我们有一些技巧可以帮助你将延误的截止日期转变为进展。

关于项目管理的一句话

在深入讨论这个最终期限模型——我们称之为“变更/推迟/放弃”的模型——之前，我们先介绍项目管理中两个关键的概念，帮助你掌握我们采用这种模型的原因。

首先，我们必须强调为交付产物指定固定期限的必要性。如果没有一个明显的目标，我们很难衡量进展状况。我们必须依照一个目标衡量进展状况，即使这个目标只是一种猜测。而进展是工作积极性的最主要的因素。

其次，我们可以通过以下四项指标评价项目进程：

指标	描述
时间	交付产物的发布时间
质量	交付产物的质量水平
资源	参与交付工作的人员数目
范围	交付产物所涉及的宽度与功能

随着项目的发展，这四项指标可能会发生变化。项目经理可以通过四项指标调整项目。话虽如此，但是Webflow旨在创建最高品质的产品，所以断不会因为时间、资源或范围牺牲质量，所以只剩下其他三根杠杆可供使用，我们将在下节中详细介绍。

专家建议：因业务需要团队不得不追赶截止日期的时候，技术主管通常会在第一时间成为众矢之的。技术主管的决定必须符合一个问题：“这个决策如何能保证公司健康发展？”如果你没有商业头脑，可以参考Josh Kaufman的《The Personal MBA》一书。这是本很棒的关于现代商业实践的书，可以帮助你在考虑Webflow和团队需求时更好地做出决策。

变更/推迟/舍弃（进度延迟的缓解策略）

遇到无法严守截止期限的时候，有三个方式可以与产品经理商讨。这三种方式的考虑顺序应当为：

• 变更交付产物
• 推迟最后期限
• 放弃这个项目

变更

变更包含以下两个问题：

1.  是否可以向项目追加资源追赶最后期限？
2. 是否可以变更交付产物以达成最后期限？

在评估如何挽回最后期限的时候，首当其冲应该考虑资源和范围。首先考虑追加资源是否有助于解决目前的情况，但通常情况下这个方法行不通，除非项目最初就有人手不足的问题。在后期追加资源只会让项目更加落后！所以，下一个应当考虑的是缩小范围。

专家建议：只要严守最后期限还能提供商业价值，缩小范围通常就是首选。一般来讲，只有10%的项目会选择加派人手挽回最后期限，90%的情况下会选择缩小范围。

缩小范围通常是可行的。作为充满激情的软件开发人员，我们情不自禁会接下能力范围之内的工作。我们可以利用这个机会，将交付产物分成更切合实际期望目标的小块，并将这些期望目标传达给其他利益关系人。

推迟

如果不可以削减范围，且追加资源不可行的时候，那么我们只能考虑延迟截止日期了。没错，你没看错。我们需要推迟截止日期。你可能会问，“如果我们可以强制更改截止日期，那么当初指定截止日期还有什么意义？”别急，我们理应尽可能避免更改截止日期，但是有时候也是迫不得已而为之，其实这也没关系。如果我们试图努力达成不切实际的截止日期，那么风险更大，其中包括团队过度疲劳、产品质量低下、士气低落，等等。

最重要的是我们不能忽视交付日期。这才是关键所在。如果放任无法严守的截止日期不管，那么项目将会陷入僵局，而项目的发展方向也未可知，这岂不是更糟？所以还是重新指定一个期限吧！

放弃

最后一个，也是最不可能发生的情况是放弃项目。如果你认为此次交付会给公司带来负面影响的话，可以考虑放弃项目。扔了它吧！注重高效的工作，而非盲目的工作。

第四种战略：密切关注

还有第四种选择，如果错过期限所带来的后果无关痛痒，那么只需密切关注。如果直觉上觉得有什么不对的地方的时候，就要多加注意。抢先解决问题非常重要，必要时刻应当先发制人。让你的项目经理意识到这一点。

专家建议：为了让自己和其他人的生活更加轻松，掌握管理期望的艺术很关键。少承诺多交付是明智的做法，当然前提是保持坦诚和诚实。坦白一切。担心无法严守截止期限或丢失关键资源的时候，就要大声说出来。会哭的孩子有奶吃，大声说出来有助于尽早完成工作。对未知事物持有怀疑的时候一定要诚实。

▌怎样才能做出更好的估算？

在撰写本文的时候，还没有人发明类似于魔法8号球（一种占卜类的小玩具）的预估方法，用于预测软件开发的时间表。有些人可能会跟你说一堆空话，而有些人会说根本不可能。你最好接受现实：软件开发中的估算基本不准。迭代与发现，然后交付再改善，这不正是敏捷开发理论的核心吗？这是一种发现的艺术，而不是交付的艺术。Webflow遵循的迭代过程我们在其他章节有所交代，尽管估算很重要，但是没有探索未知重要。虽说如此，我们还是想在这里介绍一些帮助估算任务的策略：

为意外情况留出余量

开发的过程很少按照计划进行。我们不建议给出精确的估计，而应针对给定的任务尽可能地猜测，并将结果乘以4，特别是如果该任务涉及未知信息。听起来有点疯狂，有时候也确实是有点过。技术主管的经验有助于改善最后的预估，但是以防万一起见初步估算还是应该为未知的信息保留一定余地。

探索未知信息的任务

在创建了主任务之后，你就可以大致了解项目可能需要多长时间。一定要确认哪些任务涉及探索未知信息，而哪些任务已经有了具体的定义。在完成所有任务之后，就可以更加准确地掌握截止期限。

八二原则

我们往往很容易忽略实际耗时的细微差别，从而导致项目最后20%的进度落后。在全面审查项目的时候，请使用80/20的原则分解项目，我们可以认为项目最后20%的工作可能会占据整个时间表80%的时间。造成这种情况的原因有很多，但是最后的20%往往牵扯到交付成果最后的完善，而综合性的功能需要完善每项功能，并涵盖各种极端情况，而这种综合性的功能需要在项目最后才能组织起来。

这对你意味着什么？ 当项目完成80%的时候，我们只能将其视为只完成了一半。这样才能正视额外的工作量所带来的细微差别，准确地掌握项目的整体进度。

永远别忘了QA

在估算截止日期的时候，设置一个代码完成日期，如此QA才有时间找bug或用户体验的问题。估算的时候必须将QA的工作当成额外的阶段，并考虑当前QA的工作量。

放松：交付后改bug

交付完前一个功能，在开始下个里程碑之前，我们需要留出一些时间来修改紧急的bug。这部分工作的时间因交付功能的复杂程度而异，通常留出一周的时间比较合适。可以利用这个机会，让团队在进入下一组任务前放松一下，并让技术主管有时间抓紧做下个项目的主任务列表。

▌项目需要多长时间？

虽然功能的范围可能需要数月的工作，但是下一个项目应该以6周的时间为基准，其中包括QA的工作，所以每个里程碑写代码的时间大约是4周左右。如此，市场营销人员可以评价一套的功能并收入囊中，根据市场的动态随时准备发布。起初，将一个大功能分解成6周的时间表可能会很有挑战性，但是我们这么做的几个重要原因是：

1. 较小的范围和时间表易于管理
2. 如果功能所带的业务价值微薄，那么随时可以调整项目
3. 6周的时间表更利于三人团队的快速作业

为期6个月的项目的主要里程碑可能大致如下：

1.  Alpha版发行（6周）
2.  Beta版发行（6周）
3. 功能发行v1.0（6周）
4. 功能发行v1.0.1（6周）

▌是否应该建立功能分支？

不要。好吧，可能有其他分支提交到长期分支的情况。也有可能，1%的可能我们需要重构基础设施中重要且应用广泛的部分。除此之外，基本上不需要建分支。如果需要建分支，那么请告知整个团队，产品经理，以及工程经理。你可能有点惊讶如何将工作组织成小规模，且不断合并分支。

请不要在feature-branches建立分支。技术主管应该要求团队成员将各自的feature-branches直接提交到dev分支上，而非其他feature-branch上，从而保证dev分支上拥有最新的代码。长期的feature-branches分支往往会引起代码间的依赖性，而且其他编程模式可能需要选择性的提交代码，并引发很难与其他分支保持同步的问题。所以，技术主管应该将整个项目归类到一个功能标记下，并持续将代码合并到dev分支中。

总体来说，Webflow有两个主分支：

1.  dev
2.  master

而每个feature-branch：

1.  可以从dev分支上创建
2. 必须合并回dev分支

功能标记

我们鼓励所有的工程师养成每天推送代码的习惯（如果可能的话），并且为了防止新功能流入最终用户，我们建议技术主管将这些新功能归类到一个功能标记之下，并由ShortcutHelper控制。

▌怎样才能保持注意力集中？

保持“注意力集中”意味着首先要照顾好自己，而且最重要的是找到一种解决问题的“快乐”方式。生活就是要做有意义的工作，同时也要有意义的生活。这意味着你需要从忙碌的工作中抽出时间来放松一下，参加一些业余活动，让自己保持精力充沛与专注。可以读本书，也可以观看一些电视节目，锻炼身体，或者去户外呼吸新鲜空气。找到一种方式可以让你高效的工作与生活，不要害怕向经理表达这方面的需求，也不要害怕抽出些时间来放松自己，即便感觉这会降低你的工作效率。

如果你不能保持注意力集中，那么你的团队也做不到。记住以身作则。

▌如何良好地组织时间？

新晋技术主管往往感到不知所措，如果不是这样，那么可能说明他们没有好好工作。（好吧，有些人可能可以泰然处之，但是大多人会觉得不适应）。对付压力过大的关键是学习管理时间的艺术。管理时间的方式多种多样，你可以根据自己的喜好选择。如果你从未接触过关于时间管理的书籍的话，我们建议你可以读一读David Allen的著作《尽管去做》（Getting Things Done）。这是学会如何清除心中杂念的第一步。如果他的方法不适合你，那么你可以找别的方法，并与大家分享。

▌我应该在编程上花多少时间？

虽然根据项目不同而异，但是我们可以大概地将技术主管的工作时间划分成：30%的时间写代码（或者更少），30%的时间审核代码（或者更多），剩下的时间服务你的团队。

审核代码

既然最终要对交付成果的质量负责，那么你需要审核代码并首肯每个PR。对于大型团队来说，这项工作耗时巨大，所以最好鼓励团队成员互相审核代码。也就是说，你需要进行大量的代码审核，并趁机指导初级团队成员，然后多向高级团队成员讨教，磨练自己的技术能力。

▌怎样向全员用Lattice汇报进度？

每周四早上11点，Webflow都会举办“全员”会议，管理团队将在会上传达所有进行项目的状况，以及公司的大型目标和倡议。技术主管负责在会前将各自的项目进展状况提交到Webflow的项目跟进Google文档中。本文档共享到了Slack的＃全员频道中。该Google文档的最后给出了汇报模板。请按照模板进行汇报。模板的内容包括：

1.  项目概要：项目状况的简短介绍。
2.  按计划进行/偏离计划的里程碑：汇报每个有效里程碑的状况，它们的进展百分比，上周以来的进展百分比（这些是猜测）。还需列出团队接下来两周的工作内容以及预计的交付日期。
3. 关键决策：交代所有可能涉及时间表变更、范围变更、以及其他关系到客服/市场、或资源变更的关键决策。
4. 风险、未知因素、以及困难：交代上周以来出现的风险、未知因素或困难。

Lattice

Webflow使用Lattice来跟进更高的公司目标。除了每周的全员汇报外，公司还要求在Lattice中更新与你相关的目标。如果你没有帐号，请找工程经理帮忙。

▌如何保持团队的积极性？

营造成就感，保留足够的空间，不要提示解决方法，让团队成员创造性地解决问题，激励人类的不仅仅是金钱，或胡萝卜加大棒。简单地启发就可以激励内在的动力：你只需将现实的目标摆在面前，并提供工具，以及解释清楚其中的缘由，我们就可以创造奇迹。

科学向我们揭示了激励人类的关键因素。本文中的很多概念都建立在这些科学见解之上，所以不知不觉中你已经开始使用战术来保持团队的积极性了！虽说如此，我们还是想在这里介绍一些流程中的基本机制。

自主、专精与目的

Daniel Pink在他的著作《驱动力》中否定了人类外部动力的秘密，或者说金钱、更好的办公室、职位等外部因素激发的动力。相反，他揭示了人类内在动力的因素，例如归属感、提高技能的机会、以及按照个人的方式做事。这三方面的内在因素可以归纳为自主、专精与目的，解剖动力的基本知识是个良好的起点。

Webflow公司负责提供这些关键的激励因素，但是聪明的技术主管也可以使用它们来产生很大的影响。所以，每个星期都问问自己以下几个问题：

1.  我是否给予了我的团队足够的空间，让他们用自己的方式解决问题？在我应该提供方向和目标时，我是否下达了命令？自主
2.  我是否给成员们分配了合适的任务，帮助他们成长？专精
3. 我们是否在为什么要建立这个功能，以及Webflow希望怎样帮助这个世界上达成了一致？目的

提供反馈

在Google和苹果担任过执行官的哈佛毕业生Kim Scott，曾在她的著作《Radical Candor》中总结了如何以最好的方式管理与团队每个人的关系与期望。事实证明，我们不应该淡化我们的感受以及彼此间的对话，相反，我们应该以个人和关心的方式讨论难题。这项原则的基本前提是“关心个人，直接挑战”，这意味着你必须体谅团队成员，并向他们表达你关心他们，但是仍然可以提供重要的反馈（甚至是直接的反馈，可能会伤害到对方）。

尽早并经常提供重要的反馈，并表达你十分关心团队成员，可以帮助你在今后的道路上回避悲惨的挑战。不仅可以提供负面的反馈，更要提供积极的反馈。两方面都很重要。如果你想了解更多信息，请参阅她的书籍。

专家建议：表达反馈的方式可能直接影响到对方是否肯接纳。我们要做到对事不对人。可以使用情况-行为-影响的模式来表达反馈。首先提出事情发生时的情况，然后强调行为，最后指出造成的影响，例如，“在今天的会议中，你多次打断Brian，让Brian感觉直到会议快结束时他才能发言。这拉长了整个会议。”如果你想了解更多这方面的信息，可以参阅这篇文章：https://www.mindtools.com/pages/article/situation-behavior-impact-feedback.htm

圈子

强调每个团队成员都有足够的机会加入圈子很重要。这本身足以让大多数人快乐地工作与生活。这是激励和有效工作的关键因素，因此我们在此列出来提醒大家。

▌如果有人表现欠佳，我该怎么办？

有一句老话说，“没有差劲的员工，只有差劲的经理？”这句话大部分属实。Webflow拥有才华横溢的工程师，所以在你得出有人表现欠佳的错误结论之前，请先确定你是否为团队提供了100%的服务。

请确保每个团队成员都有足够的动力，有充分的机会自主地做有意义的工作，拥有足够的成长空间，并掌握了足够的目标。另外，持续提供反馈也是很重要的部分。

你还必须考虑团队成员的内在工作生活。大胆地问他们，“最近怎么样？工作之外一切都好吗？”经常问这些问题，但是记住不要八卦。允许团队成员讨论个人问题，但是要记得这是他们的私事。

如果你已经尽了最大努力，为团队成员营造了最佳工作环境，但他们的表现依然不尽人意，那么请跟你的经理谈谈下一步该怎么办。

▌如何避免团队承担过多工作？

如果一个团队无法严守截止日期，那么这是管理上的问题，而不是团队的问题。这意味着，在项目的进行过程中，某些环节没有按照计划进行，且没有得到及时调整。因此，避免承担过多工作的第一个原则是“良好地管理项目和预期结果”。

第二个原则：永远不要将自己都无法完成的工作分配给团队成员（而且不能算你加班的时间）。有些公司或组织会在遇到难关时要求员工加班。对于高效团队来说，这将导致人员流失和长期的效率降低。Webflow非常关心我们的团队，不仅在工作中，还有个人方面，所以我们必须尽最大努力管理好自己的时间。

时间紧迫

哦，时间紧迫，你已经拥有了最好的团队，但是还是不可避免紧急情况的发生。

作为技术主管，你将不可避免地遇到一个即将来临的截止日期，可能需要稍微付出一点额外的努力才能在最后阶段完成所有工作。稍微的意思是说，团队可能要在每周40个小时的工作时间之外再加会儿班。没错，我们所说的“时间紧迫”并不是疯狂地加班到深夜或周末。就几个小时而已。最多的时候，有人每天加班2-4个小时，若非万不得已他们不能再有更多的加班。他们已经尽了全力工作了，如果要求更多势必造成效率低下，也会对他们个人和Webflow公司造成不利影响。

时间紧迫是真的。但是时间紧迫可能是管理不善的一个表象。我们必须尽最大努力将这些过度活跃的时期控制在每年一到两次。

注释：[1] 稳定的团队应当与客服联络员密切合作，专注于修复对用户影响巨大的bug。

 

[source]称职的技术leader相当于100名工程师

https://hackernoon.com/the-effective-tech-lead-is-a-100x-engineer-fe49c0372a63