├── .adr.json ├── .editorconfig ├── .gitignore ├── LICENSE ├── README.md ├── _config.yml ├── articles ├── 10-tip-good-tl.md ├── 11-responsibilities-10-mistakes.md ├── 12-tips-be-tl.md ├── 4-things-when-becoming-tech-lead.md ├── 5-signs-be-tech-lead.md ├── README.md ├── being-tech-lead-lesson.md ├── decisions.md ├── dont-need-tech-lead.md ├── effective-tech-lead-in-agile.md ├── five-advice-for-new-tech-leads.md ├── good-tech-lead-bad-tech-lead.md ├── great-culture.md ├── howto-build-thrived-culture.md ├── images │ ├── kanban.png │ ├── ptop.png │ ├── qa_gates.jpg │ ├── ttl-core.png │ └── weekly-vitals-example-report.png ├── keep-culture-while-scaling.md ├── lead-programmer-reponsiblities.md ├── make-great-tech-lead.md ├── path-to-production.md ├── project-lifecycle-tl.md ├── software-architecture.md ├── tech-lead-4-challenges.md ├── tech-lead-8-qualities.md ├── tech-lead-analyzing-requirements.md ├── tech-lead-architecture-triangle.md ├── tech-lead-balancing-coaching-with-coding.md ├── tech-lead-do.md ├── tech-lead-good-for.md ├── tech-lead-main-skills.md ├── tech-lead-new-project-checklists.md ├── tech-lead-or-tech-lead.md ├── tech-lead-role-responsibilities.md ├── tech-lead-survival-guide.md ├── to-be-great-tl.md ├── what-make-a-good-tech-lead.md └── what-tech-lead-do.md ├── assets ├── adr.png ├── architecture-process.jpg ├── c4-model.jpg ├── c4model-layer.png ├── cone-of-uncertainty-for-powerpoint.jpg ├── flow.png ├── influence.gif ├── influencing-approaches.png ├── leader-vs-boss.jpg ├── limit-of-authority.png ├── motivators.jpg ├── new-project-checklist.jpg ├── path-to-production.png ├── situational-leadership-model.png ├── skill_wheels.png ├── skilltree.png ├── stakeholder-mapping.jpg ├── states-of-group.png ├── sweet-spot.png ├── tech-action-project.png ├── tech-action-project.sketch ├── tech-action-project.svg ├── tech-debt-wall.png ├── tech-lead-butterfly.png ├── tech-lead-circles.png ├── techstack.jpg ├── tki-stratery.jpg ├── tki.jpg ├── tla.png └── tw-radar-platforms.png ├── defined.md ├── desktop └── src │ └── index.ts ├── docs ├── README.md ├── adr │ ├── 0001-desktop-工具.md │ ├── 0002-模块功能插件化.md │ └── README.md ├── architecture │ └── README.md ├── bmc │ ├── canvas.html │ ├── canvas_template.html │ ├── css │ │ ├── bootstrap-responsive.css │ │ ├── bootstrap-responsive.min.css │ │ ├── bootstrap.css │ │ ├── bootstrap.min.css │ │ └── canvas.css │ ├── img │ │ ├── glyphicons-halflings-white.png │ │ └── glyphicons-halflings.png │ ├── js │ │ ├── bootstrap.js │ │ ├── bootstrap.min.js │ │ ├── canvas.js │ │ └── jquery.min.js │ └── startup.html └── mvp │ ├── README.md │ └── model.md ├── evaluate └── README.md ├── faq └── README.md ├── model ├── README.md ├── agile-practise.md ├── personal-effectiveness.md ├── tl-model.md ├── tw-model.md └── value.md └── package.json /.adr.json: -------------------------------------------------------------------------------- 1 | {"language":"zh-cn","path":"docs/adr/","prefix":"","digits":4} -------------------------------------------------------------------------------- /.editorconfig: -------------------------------------------------------------------------------- 1 | # Editor configuration, see https://editorconfig.org 2 | root = true 3 | 4 | [*] 5 | charset = utf-8 6 | indent_style = space 7 | indent_size = 2 8 | insert_final_newline = true 9 | trim_trailing_whitespace = true 10 | 11 | [*.md] 12 | max_line_length = off 13 | trim_trailing_whitespace = false 14 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Logs 2 | .DS_Store 3 | logs 4 | *.log 5 | npm-debug.log* 6 | yarn-debug.log* 7 | yarn-error.log* 8 | 9 | # Runtime data 10 | pids 11 | *.pid 12 | *.seed 13 | *.pid.lock 14 | 15 | # Directory for instrumented libs generated by jscoverage/JSCover 16 | lib-cov 17 | 18 | # Coverage directory used by tools like istanbul 19 | coverage 20 | 21 | # nyc test coverage 22 | .nyc_output 23 | 24 | # Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files) 25 | .grunt 26 | 27 | # Bower dependency directory (https://bower.io/) 28 | bower_components 29 | 30 | # node-waf configuration 31 | .lock-wscript 32 | 33 | # Compiled binary addons (https://nodejs.org/api/addons.html) 34 | build/Release 35 | 36 | # Dependency directories 37 | node_modules/ 38 | jspm_packages/ 39 | 40 | # TypeScript v1 declaration files 41 | typings/ 42 | 43 | # Optional npm cache directory 44 | .npm 45 | 46 | # Optional eslint cache 47 | .eslintcache 48 | 49 | # Optional REPL history 50 | .node_repl_history 51 | 52 | # Output of 'npm pack' 53 | *.tgz 54 | 55 | # Yarn Integrity file 56 | .yarn-integrity 57 | 58 | # dotenv environment variables file 59 | .env 60 | 61 | # next.js build output 62 | .next 63 | .idea 64 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2019 Phodal Huang 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Tech Lead Toolbox 2 | 3 | **The origin Tech Lead articles is need to delete. And now I working on build the tools for Tech Lead, welcome to join us.** 4 | 5 | > A toolbox for better tech lead of Phodal 6 | 7 | ![Tech Lead Actions](assets/tech-action-project.svg) 8 | 9 | Todos: 10 | 11 | **Soft Skills** 12 | 13 | - Team Development Model 14 | - Scenario Leadership Model 15 | 16 | **Team** 17 | 18 | - Flow 19 | - Sweet Spot 20 | - Culture Checklists 21 | 22 | **Dev Skills** 23 | 24 | - Dev Skills Checklists 25 | 26 | **Leadership** 27 | 28 | - Thomas-Kilmann Conflict Theory 29 | - CHAMPFROGS Model 30 | - Cone of uncertainty 31 | - Stakeholder Mapping 32 | - Six principles of influence 33 | - Join New Team 34 | 35 | ## DEFINE 36 | 37 | ### WHAT IS TECH LEAD? 38 | 39 | Tech Lead can be a purely technical job, while others act as project managers. If you only look at the role of Lead with Tech, then it is: 40 | 41 | * **Architect**, **Technologist**. Compared with the project manager and the technical manager, he/she not only focuses on the technical practice and progress of the project, but also has to solve the most complicated technical problems. 42 | * **Technical role model**. Tech Lead is more like a spiritual “leader” who needs to let other people in the project see the way forward. 43 | * **Developer**. He/she takes time to write code in the project, which, as defined in the training, takes at least 30% of the time to write. First, master a series of technologies related to the project; second, continue to improve technical capabilities, rather than become managers. 44 | 45 | In addition to technical work, he/she also needs to understand the business in order to develop software that meets business needs. There is also a need to manage risk (mainly technology-related risks) in order to respond to changes. 46 | 47 | ### 什么是 Tech Lead？ 48 | 49 | Tech Lead 可以是一个纯粹的技术岗位，有的则还要充当项目经理的职责。如果只以 Tech 来看待 Lead 这个角色，那么它是： 50 | 51 | * **架构师**、**技术专家**。与项目经理，技术管理者相比，他/她不仅仅关注于项目的技术实践和进度，还得去解决那些最复杂的技术问题。 52 | * **技术榜样**。Tech Lead 更像是一个精神 “领袖”，他/她需要让项目中的其他/她人看到前进的方向。 53 | * **开发人员**。他/她在项目中抽取时间来编写代码，如 在培训上所定义的那样，至少需要 30% 的时间来编写。一来，掌握项目相关的一系列技术；二来，不断提升技术能力，而不是成为管理者。 54 | 55 | 除了技术上的工作，他/她还需要懂业务，以此才能开发出符合业务需求的软件。还需要能管理风险（主要是技术相关的风险），才能对应变化。 56 | 57 | ## Tech Toolbox 58 | 59 | ### [ADR](https://github.com/phodal/adr) - Architecture Decision Records in Node.js with Reporter, supported Windows, GNU/Linux, macOS. 60 | 61 | ![Screenshot](https://phodal.github.io/adr/docs/list-example.png) 62 | 63 | ### [TLA](https://github.com/phodal/tla) - Tech Lead Assessments Radar 64 | 65 | ![Screenshot](https://phodal.github.io/tla/docs/tla.png) 66 | 67 | ### [Path](https://github.com/phodal/path) - Path To Production 68 | 69 | ![Screenshot](https://phodal.github.io/path/docs/path-to-production.png) 70 | 71 | ### [SkillTree](https://github.com/phodal/sherlock) - A SkillTree of Junior Developers 72 | 73 | ![Screenshot](assets/skilltree.png) 74 | 75 | ### [TechStack](https://github.com/phodal/techstack) - A Radar for Projects' Toolbox 76 | 77 | ![Screenshot](http://phodal.github.io/techstack/screenshot.jpg) 78 | 79 | ### [New Project Checklist](https://github.com/phodal/new-project-checklist) - https://github.com/phodal/new-project-checklist 80 | 81 | ![Screenshot](assets/new-project-checklist.jpg) 82 | 83 | Checklist: TBD 84 | 85 | ### [SkillWheel](https://github.com/phodal/skillwheel) - A SkillWheel of Organzation's usage 86 | 87 | ![Screenshot](assets/skill_wheels.png) 88 | 89 | ### 后端体系规划指南 - [https://github.com/phodal/bde](https://github.com/phodal/bde) 90 | 91 | Architecture of backend development efficiency 92 | 93 | > Screenshot TBD 94 | 95 | ### 前端体系规划指南 - [https://github.com/phodal/fde](https://github.com/phodal/fde) 96 | 97 | Architecture of Frontend Development Efficiency 98 | 99 | > Screenshot TBD 100 | 101 | ## Leadership Theory 102 | 103 | ### Motivation: CHAMPFROGS Model 104 | 105 | ![Motivation](assets/motivators.jpg) 106 | 107 | ### Risk Management: Cone of Uncertainty 108 | 109 | ![Cone of Uncertainty](assets/cone-of-uncertainty-for-powerpoint.jpg) 110 | 111 | ### Scenario Leadership Model 112 | 113 | ![Scenario Leadership Model](assets/situational-leadership-model.png) 114 | 115 | ### Team Development Model 116 | 117 | ![Team Development Model](assets/states-of-group.png) 118 | 119 | ### Conflict Management: Thomas-Kilmann Conflict Theory 120 | 121 | ![TKI](assets/tki.jpg) 122 | 123 | ### Six principles of influence 124 | 125 | ![Six principles of influence](assets/influence.gif) 126 | 127 | ### Stakeholder Mapping 128 | 129 | ![Stakeholder Analyse](assets/stakeholder-mapping.jpg) 130 | 131 | ### Flow 132 | 133 | ![Flow](assets/flow.png) 134 | 135 | ## Related 136 | 137 | English: 138 | 139 | - [Awesome Leadership and Management](https://github.com/LappleApple/awesome-leading-and-managing) 140 | - [Tech Leading](https://github.com/PeterCookDev/TechLeading) 141 | - [Reading Lists](https://github.com/techleadworkshops/coaching/blob/master/reading-list.md) 142 | - [Tech Leadership](https://github.com/icaroseara/tech-leadership) 143 | 144 | 中文（Chinese）见：[Tech Lead 相关文章](articles/README.md) 145 | 146 | License 147 | --- 148 | 149 | [![Phodal's Idea](http://brand.phodal.com/shields/idea-small.svg)](http://ideas.phodal.com/) 150 | 151 | © 2019 A [Phodal Huang](https://www.phodal.com)'s [Idea](http://github.com/phodal/ideas). This code is distributed under the MIT license. See `LICENSE` in this directory. 152 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | remote_theme: phodal/mifa-jekyll 2 | 3 | -------------------------------------------------------------------------------- /articles/10-tip-good-tl.md: -------------------------------------------------------------------------------- 1 | # 成为 Tech Lead 的 10 个技巧 2 | 3 | 原文链接：[10 Tips for Being a Good Tech Lead](https://habr.com/en/post/439492/) 4 | 5 | 领导力不是服务，而是技能。作为软件开发人员——工作几年的专业人员，都有机会成为 Tech Lead。但是，请记住，“**以强大的力量来承担巨大的责任。**” 6 | 7 | 作为技术领导者，您需要注意几件事情。显然，作为软件开发人员，您不需要像编辑那样需要编写代码。但是，还有其他几个非编码相关的东西，现在你有责任处理。 8 | 9 | **成为 Tech Lead 的 10 个技巧** 10 | 11 | 在没有得到团队任何批评的情况下，维持 Tech Lead 地位是不可能的。这不是因为你的无能力，尽管是由于人性。但是，可以努力使其最小化，并最终使您的工作变得更好。毕竟，你现在是领导者。 12 | 13 | 除了领导开发团队之外，访谈通常也是 Tech Lead 工作的一部分。因此，您可能会了解在为开发团队招募新成员时，要询问的最相关的面试问题。 14 | 15 | 成为技术领导者不仅仅是指挥，而是要让每个人聚集在一起取得成功。Tech Lead 越好，负责的开发团队就越好。 16 | 17 | 以下是 10 个技巧，可以帮助任何新的或经验丰富的 Tech Lead，更好地发挥他们的作用： 18 | 19 | ## 接受不完美是不可避免的 20 | 21 | 作为软件开发人员可能具有挑战性。然而，成为技术领先者可能更具挑战性。当团队工作得很好并且享受他们的工作时，作为技术领导者可以获得极大的回报。然而，实现和维持这样的条件并不容易。 22 | 23 | 当一个截止日期即将到来，资源即将消失，并且团队成员存在不可避免的问题时，Tech Lead 的价值和耐心会在整个工作时间内得到测试。 24 | 25 | 由于团队是由于人性而容易出错的人组成的团队，因此团队也容易受到混乱和不完美的影响。技术领导者不需要从中获得动力，而是将其作为持续增强的动力。 26 | 27 | 有几种解决方案可以最大限度地减少团队中的混乱，其中一种是**定期反馈**。技术领导者需要在团队成员中促进诚实和坦诚。此外，Tech Lead 必须不断进行自我评估，以便不断变得越来越好。 28 | 29 | ## 委托很重要 30 | 31 | 学习授权对于正确承担 Tech Lead 的角色非常重要。在正式领导团队时，委派任务非常重要。它不能被跳过，因为 Tech Lead 已经做了很多工作。 32 | 33 | 没有将结果委托给广泛的问题，从不堪重负到成为团队的障碍。委派不是指挥团队成员，而是在思考分担责任。 34 | 35 | 为了建立新的技能并在资历排名上升，重要的是承担新的责任。因此，如果做得对，将任务委派给团队成员，可以成为赋予他们权力的一种方式。 36 | 37 | 委派时，允许团队成员自愿参加，但不是每次都是。虽然有些人已经准备好迎接挑战，但其他一些人可能缺乏信心。作为 Tech Lead ，您有责任激励并准备好这些成员接受挑战。 38 | 39 | 委托时需要注意的另一件事是，每个人都应该得到公平的机会。不应该给同一个团队成员一遍又一遍地授予相同的委托任务。 40 | 41 | 对于没人喜欢的任务，您需要创建一个轮换列表，允许团队中的每个成员以相同的方式分担负担。 42 | 43 | ## 不要一直成为技术主管 44 | 45 | 作为 Tech Lead 显然是一个很重要的责任。但是，您无需始终像所有 Tech Lead 那样行事。一些 Tech Lead 成为了一名守门人，并试图对其团队运作的每个方面进行微观管理。 46 | 47 | 软件开发需要整个开发团队，原因很复杂。因此，它不能由一个人开发。团队中的每个人对于使项目成功非常重要。 48 | 49 | 不要占有指定。像世界上每一件物质一样，它最迟会被传递给其他人。但是，当你有机会时，尽量充分利用它。 50 | 51 | ## 给每个团队成员注意和时间 52 | 53 | 成为领导者最重要的事情可能是，能够与所有成员建立个人关系。您需要进行一对一的会话，以便与团队的每个成员进行联系。 54 | 55 | 您无需遵循一对一会话的典型制度，包括在会议室或您的小屋中彼此相对的座位。相反，尝试尝试。带人散步，一起玩游戏，一起喝茶或咖啡，等等。 56 | 57 | 永远记住，学习是一个双向的过程。不仅是你的下属向你学习，而且你也可能从他们身上学到一些东西。 58 | 59 | ## 看到事情的重点 60 | 61 | 软件开发人员主要关注手头的任务。当升级到 Tech Lead 的位置时，仅关注分配的任务不是主要关注点。 62 | 63 | 相反，有几件事情需要你立即关注，甚至有些事情需要同时关注。因此， Tech Lead 需要经常在焦点之间切换。 64 | 65 | Tech Lead 必须比任何团队成员更广泛地了解整个系统。简而言之， Tech Lead 必须能够理解团队中每个成员的努力，如何适应更大的范围。 66 | 67 | 认为自己是属于舰队的许多船只之一的船长。您的团队成员是您船上的水手。他们专注于保持帆，牵引绳索，以及完成其他任务，以确保船保持完整并继续航行。 68 | 69 | 但是，您需要时不时地跳到乌鸦的巢穴，然后向前看以发现潜在的危险，然后采取必要的措施以确保船只保持安全和正确的航线。 70 | 71 | ## 从错误中学习并分享 72 | 73 | 生活就是做，失败，站起来，意识到出了什么问题，纠正错误，再做一遍，直到你成功为止。这个口头禅适用于各行各业，可能是你的个人生活或作为技术领导的职业生涯。 74 | 75 | 你需要大胆地犯错误，谦虚地向他们学习。在分享时，从自己的经验中学到的东西的重要性会增加。因此，您需要与下属分享您从错误中学到的知识。 76 | 77 | 犯错误不要感到羞耻。我们都是人类，因此每个人都容易犯错误。你需要有勇气接受你的错误，纠正错误，并让那些会发现你的经验有用的人知道。这是一种启蒙的方式。 78 | 79 | ## 管理大部分内容，而不是一切 80 | 81 | Tech Lead 是项目大多数部分的主要决策者，而不是每个部分。Tech Lead 必须对所有决策都有最终决定权，但是，她必须至少听到团队成员的意见。 82 | 83 | 没有人喜欢能够完全控制会员或团队的领导者。感觉更像是独裁而不是领导。任何真正的 Tech Lead 都会鼓励、并授权团队成员自己做出重要决策。 84 | 85 | ## 准备团队成员以更好地整合业务 86 | 87 | 通常，能够以高级技术语言进行通信，并以非技术术语解释相同的软件开发人员，被提升为承担成为 Tech Lead 的责任。 88 | 89 | 软件开发人员和非技术业务代表之间的对话最终会让人感到不安。虽然商界人士最终会感到困惑，但技术人员却因为没有得到他们的观点，而感到焦躁不安。 90 | 91 | 能够以非技术人员可以理解的方式，与技术项目进行沟通的软件开发人员有机会成为技术主管。 92 | 93 | 但是，在某些情况下，Tech Lead 成为技术团队与其他非技术业务人员之间唯一的沟通渠道。 94 | 95 | 虽然技术团队认为 Tech Lead 是唯一能够用他们的语言交谈的人，但业务部门认为 Tech Lead 是唯一能够以简单，非技术术语向他们解释产品的人。 96 | 97 | 这种方法在某些情况下可能会有所帮助，例如团队在截止日期前工作但不是长期工作。在这样的 Tech Lead 度假或生病的情况下，没有办法建立适当的技术 - 非技术交流。 98 | 99 | 伟大的技术人员了解这种情况，因此总是尝试将技术团队的成员与业务集成，以避免上述情况。这可以通过将其中一些用于商务会议，并邀请加入对话来轻松完成。 100 | 101 | 通过这种方式，向非技术人员学习解释技术事物的机制的人，将能力转移给团队中其他有能力的成员。优秀的 Tech Lead 也确保开发团队，拥有成功完成项目的所有资源。 102 | 103 | ## 对所有人都有同样的待遇 104 | 105 | 承担 Tech Lead 角色时要避免的最大错误是，优先考虑一个成员而不是其他成员。这会在您和其他团队成员之间造成差距。真正的 Tech Lead 可以为团队中的每一位成员提供公平的待遇。 106 | 107 | 对一个团队成员给予特殊待遇并对另一个团队成员负责是不公平的。领导者不仅让每个人都团结在一起，而且保持平等。对于团队而言，每个成员都很重要。这就是为什么它首先是一个团队。 108 | 109 | ## 编码中的中间路径 110 | 111 | 当一个人晋升为 Tech Lead 时，编码责任就会降低。但是，有些人继续编码的程度与之前相同。如果您一直在编码，那么您只完成了多方面工作的一部分。 112 | 113 | 相反，一些新任命的技术主管完全放弃了编码。这两种情况都同样有害。通常，能够快速编写高质量代码的软件开发人员，需要负责技术主管。 114 | 115 | 因此，保持和发展他们的编码能力是非常重要的。Tech Lead 希望花费总编码时间的大约 30％ 到 60％。 116 | 117 | ## 结论 118 | 119 | 这些是我们支持 Tech Lead 角色的 10 个技巧。除了具有编程能力之外，技术主管必须能够同情成员并从内到外理解他们。充分了解整体业务也很重要。 120 | 121 | -------------------------------------------------------------------------------- /articles/11-responsibilities-10-mistakes.md: -------------------------------------------------------------------------------- 1 | # Tech Lead 最重要的 11 项责任和 10 个常见错误 2 | 3 | 原文链接：[11 Top Responsibilities and 10 Common Mistakes of a Technical Leader](https://www.coderhood.com/11-top-responsibilities-and-10-common-mistakes-of-a-technical-leader/) 4 | 5 | ## 论领导力 6 | 7 | 领导是一门艺术；这不仅是我真正相信是真实的陈述，而且也是 Max Depree 撰写的优秀书籍的标题。在他的书中，Depree 为我们提供了以下对领导者责任的描述： 8 | 9 | > 领导者的首要责任是定义现实。最后是说谢谢。在这两者之间，领导者是仆人。 10 | 11 | 这些话经常在白天回荡。当我不确定如何增加价值时，他们一次又一次地引导我。他们还有一个很容易被忽略的深刻信息：现实不只是 “存在”，而是需要定义的东西。 12 | 13 | 需要定义现实，因为它很少只有一个版本。您经常需要选择一个观点，并且您必须使用不完善的信息进行选择。定义现实就是赌博，下注，引导他人对你做同样的事情。您永远不会拥有您希望拥有的所有信息，但您必须做出决定。作为领导者，您还必须对他们负责。 14 | 15 | ## 缺乏领导力是痛苦的 16 | 17 | 你可能有不幸的经历，参与需要做出决定的讨论，但没有人担任或担任过领导角色。那些谈话很痛苦。总是有很多话题 —— 太多了 —— 但该小组很少得出有力的结论。最后，无论讨论发生了多少，都没有具体的决定或充分的理由来制定明确的计划。 18 | 19 | 在这些情况下，所涉及的每个人都倾向于挥手或忽略问题中最棘手的方面。该小组经常让对话感到不确定该怎么做。那些情况下的 “现实” 仍未定义。结果，时间过去没有进展；人们回到他们的活动而不与现实是一致的；混乱占主导地位。 20 | 21 | 如果没有 Tech Lead，一群软件工程师也会猜测什么是技术卓越的好例子。高级工程师可能已形成他们的意见，但初级工程师需要看到它的实际效果。如果没有人带头，那么就会做出猜测，猜测往往是错误的。 22 | 23 | ## 领导者的角色 24 | 25 | 领导者是推动对话的人，并且可以在选项之间做出选择，看到过去不确定的迷雾。要被信任，领导者需要在大多数时间被称为正确的 —— 或者至少没有错的。此外，他或她必须做出选择，而不会让人感到被迫进入他们不相信的方向。事实上，领导者很少会强迫任何人做出决定。 26 | 27 | 领导者指导对话，并确保在讨论结束之前定义明确的现实版本。或者，至少，他或她必须确定达到这一点需要做些什么。 28 | 29 | Tech Lead 还有责任去通过向团队展示：如何在项目环境中脱颖，而出来定义现实。设定一个模仿的黄金标准对于团队的成功非常重要。如果没有这个标准，一群工程师往往会走向不同的方向并发生冲突。 30 | 31 | ## 小组的角色 32 | 33 | 当 Max Depree 说领导者最后的责任是说 “谢谢你” 时，他正在解释追随者必须感受到控制权。领导人说，“谢谢”，因为他们没有对他们的人施加选择；相反，他们引导他们走上一条道路，然后感谢他们被允许成为他们的向导的特权。 34 | 35 | 指导团队意味着领导者需要牢记计划，然后引导团队朝着总体方向发展。随着讨论的展开，领导者需要随时准备根据需要改变行动方案，即时调整和完善。调整和提炼的过程是领导者调用集体智慧，在此基础上构建现实的一种形式。 36 | 37 | ## 建设乐高塔 38 |   39 | 我认为引导对话的过程类似于与一群朋友建立乐高塔的过程。作为领导者，你开始制作一个已经在你脑海中勾画出来的计划。您与朋友分享您的愿景，他们与您一起实现它。在对概念进行更改或需要做出必要决定之前，他们会与您核实。在您按照团队的建议，您拥有的部分以及如何进行工作的指导下，您的原始愿景会发生变化。 40 | 41 | 在整个过程中，您可以让每个人了解愿景，以便团队可以根据变更计划定制建议。您可以帮助您的员工以最有效的方式组织工作。施工是一项团队合作，但作为领导者，您可以根据自己的专业知识和经验采取最有益的行动方案。 42 | 43 | 你融入了好的想法，并轻轻地重定向任何看起来像坏的想法。最终，当你看到每个人都朝着正确的方向前进并且愿景和目标明确时，你就会走出小组的道路。此时，您可以选择继续工作或仅仅关注事物。最终结果与原计划有所不同；最有可能是一个更好的版本，由集团的集体智慧打造。 44 | 45 | 在整个过程中，您不会告诉人们该做什么。您提出建议并提醒他们整体愿景。您还为他们定义了现实，尽可能地避开他们的方式，帮助解决问题并回答他们的问题。当团队完成塔楼的建设时，你赞美并感谢他们的工作。他们做到了。你，大多数，为他们服务。 46 | 47 | ## 技术领导力 48 | 49 | 与构建乐高塔相似，构建软件需要从头到尾做出决策。技术领导者的首要任务是确定工程现实：需要构建什么，一般技术方向，生产力和技术卓越的黄金标准的例子，业务和技术背景以及时间和资源限制。 50 | 51 | 对现实的最初定义是一个起点，它受到进化的影响。开发团队是塑造它的过程中的积极参与者。在此过程中，领导者必须能够回答问题，解决问题并协调和同步活动。领导者是一名仆人，他们的目标是确保每个人都在研究相同版本的转变愿景，并且项目以自我一致的方式发展。 52 | 53 | 强有力的领导者，必须了解整个项目的技术细节。他们不必做出所有决定，但他们必须足够详细地熟悉它们以捕捉不一致性。技术领导者必须牢记很多细节，并且必须能够看到工作的当前状态，以及它与愿景如何一致。 54 | 55 | Tech Lead 还必须具备了解团队工作细节的技能，并且不能落伍。 56 | 57 | ## Tech Lead 最重要的 11 项责任 58 | 59 | 1. **定义现实**。这包括为团队其他成员提供技术卓越和生产力的明确示例。团队应该将技术领导者看作是模仿和关注的人。以身作则，在软件工程中至关重要。 60 | 61 | 2. **从头到尾保持项目技术愿景对每个人都清晰**。当团队对特定项目或技术方向有疑问时，领导者需要有答案或方法来获得答案。没有答案的领导者是瓶颈。 62 | 63 | 3. **牢记项目或系统的大多数工程细节**。构建项目部分的开发人员必须关注他们正在做的事情。Tech Lead 应该牢记大局和大部分高级工程细节。如果没有这种观点，团队就有可能做出不一致甚至不兼容的选择。 64 | 65 | 4. **回答团队或利益相关者的技术问题**。Tech Lead 需要帮助团队保持专注。一种方法是回答来自团队成员或外部利益相关者的大多数技术问题。回答问题不仅可以提供正确的信息流，还可以告知领导者在他人眼中的重要性。 66 | 67 | 5. **帮助团队解决棘手的工程问题**。当工程师处于一个棘手的问题中时，他们经常需要一个用于技术头脑风暴的发声板。Tech Lead 应该被自然地视为这种讨论的理想候选人，并且应该能够提供有关如何解决工程挑战的建议。 68 | 69 | 6. **审查团队制定的决策，以确保与愿景的一致性和一致性**。作为项目或系统的整体高级技术知识的守护者，技术领导者处于确保方向一致性的最佳位置。审查决策并使用建议和方向进行调整是技术领导者的关键责任。 70 | 71 | 7. **将工程现实转化为非技术利益相关者的简单术语**。工程师对代码的细节非常关注，如果不能自然地将细节翻译成非技术语言，则不应该担心。技术领导者需要能够提供此类翻译，根据受众调整细节级别。 72 | 73 | 8. **允许团队通过阻塞，并保护他们免受干扰来取得进步**。技术领导者需要履行自己的职责，同时避开团队。他或她必须通过限制不必要的分心来让其他工程师尽可能高效。这是一个棘手的平衡，需要时间来掌握，并且无论在哪个方向都可以摆得太远。 74 | 75 | 9. **了解团队成员的优势和劣势**。了解他或她的成员，并了解他们的技术优势和劣势，是技术领导者的责任。有了这些知识，领导者就能够将工作适当地分配给合适的人。 76 | 77 | 10. **指导团队成员**。技术领导者需要被视为团队成员的导师；有人可以帮助其他工程师改进并在技术之旅中前进。 78 | 79 | 11 **对团队说“谢谢”**。领导者引导人们走上正轨，然后让他或她的人去做。工作完成后，领导者必须感谢他们的努力和取得的成果。一个不表示对团队表示感谢的领导者不会在长期内受到团队的尊重。 80 | 81 | 82 | ## Tech Lead 常见 10 个错误 83 | 84 | 我看到 Tech Lead 陷入了一些共同的陷阱。这是一个简短的清单： 85 | 86 | 1. **强迫团队做出决定**。工程领导者不应该像暴君一样行事。我已经看到它与初级领导人多次发生过，而且很痛苦。想要做出所有决定的咄咄逼人的领导者往往会疏远开发团队。人们厌倦了它，放弃了项目，甚至放弃了公司。相反，团队必须有权在知识渊博且值得信赖的技术领导者的指导下做出独立决策。 87 | 88 | 2. **不听团队**。成为无效领导者的最快方法是不要注意小组的声音。请记住，作为领导者，您是团队的仆人，您必须倾听那些允许您领导的人。领导力不是赋予你权力超过他人的头衔。这是您必须拥有的一个角色，它使您在计划的设计和执行中处于中心位置。倾听完成大部分工作的人员对成功至关重要。如果你不听团队的话，你很快就会成为问题，团队会停止听你的。 89 | 90 | 3. **落在后面**。技术领导者必须至少在大多数时间都有答案。如果他们不知道事情是如何运作的，那么他们的角色就会受到损害。长期从项目中分心是技术领导者的死刑判决。它导致与细节相距太远，无法保持指导决策和技术愿景的能力。 91 | 92 | 4. **失去了团队的信任**。工程领导者需要获得并保持团队的信任。当团队失去信心时，成为一名领导者变得非常困难并失去其意义。必须通过在大多数时间保持正确，并始终为团队提供信任来获得信任。这意味着领导者必须有机会在团队面前证明自己。这是我不是雇佣技术领导者的粉丝的原因之一，而是为什么我相信在战壕中培养他们。 93 | 94 | 5. **在做出任何决定之前等待获得所有数据**。这被称为 “分析瘫痪”，这是另一个死刑判决。领导者必须能够在大多数情况下，使用可用信息做出决策。始终需要更多信息来做出决策，这是弱点和糟糕领导力的表现。总是等待 “更多数据” 是一个滑坡，阻止 Tech Lead 履行其职能。能够面对不确定性进行操作是经验对技术领导者如此重要的原因。“之前完成” 使得领导者能够根据不完美，不完整甚至矛盾的信息做出决策。经验和模式匹配可以轻松胜过数据的所有权。 95 | 96 | 6. **团队无法使用**。技术领导者必须与团队密切合作。一个独立的领导者有可能落后并失去对项目细节的追踪。留下的领导者很快失去了团队的信任。如果小组成员无法从技术领导者那里得到答案，他们就会冒着错误的方向做出自己的决定。 97 | 98 | 7. **与执行管理层不一致**。采取与执行管理层不一致的道路的技术领导者是无效的。技术领导必须在公司提供的限制下，在执行小组制定的路线上运作。技术方向与业务方向的错位将领导者转变为问题而不是解决方案。再一次，我已多次看到它，它总是很糟糕。 99 | 100 | 8. **让骄傲，自我和自恋指导决策**。当骄傲，自我或自恋倾向开始推动决策时，领导者走在危险的道路上。人们可以在一英里外看到它，并最终厌倦了处理它。为自己的工作感到骄傲并没有错，但你不能让这种自豪感引导你的决定。作为领导者，您是团队和您工作的公司的仆人;因此，你需要把你的自我放在一边。决策必须考虑到业务 - 即您的客户 - 而不是因为您的自我。当你错了，承认它。当你的团队不同意你的观点时，要珍惜它并仔细聆听。 101 | 102 | 9. **不认识你的团队成员**。作为技术领导者，您需要了解您的团队成员。如果你没有看到你的人的优点和缺点，你就无法正确领导他们。要非常注意每个人的技术技能，他们做出的决策类型，他们的协作风格，他们相处的人，他们的冲突，他们的习惯和行为。了解你的球员。 103 | 104 | 10. **给出一个坏榜样**。 技术领导者必须为团队提供遵循的黄金标准。 他或她不应该陷入坏习惯或破坏性模式。 一些要避免的事情的例子： 105 | - 划水并编写糟糕的代码 106 | - 不遵守商定的标准 107 | - 来得晚，早退 108 | - 没有完成承诺的工作 109 | - 挑战或忽视流程 110 | - 挑战组织标准 111 | - 作为一个贫穷的合作者 112 | - 从事非仁慈的摩擦 113 | - 等等… 114 | 115 | -------------------------------------------------------------------------------- /articles/12-tips-be-tl.md: -------------------------------------------------------------------------------- 1 | # 成为优秀 Tech Lead 的 12 个提示 2 | 3 | 原文链接：[Twelve tips to become an awesome Technical Lead](https://ordina-jworks.github.io/architecture/2017/12/22/Tech-Lead.html) 4 | 5 | ## 什么是 Technical Leadership？ 6 | 7 | 一个 Technical Lead 有责任来帮助团队前进。作为该角色的人员，他/她应该具有非常不错的**技术方面的经验**以及**强大的沟通技巧**。他或她将对项目或产品的技术方向负责，并作为跨团队沟通的首选人。 8 | 9 | 对于大中型团队而言，有一位全职的 Tech Lead 在场，负责重要的领导方面的活动，诸如： 10 | 11 | **指导项目的技术愿景** 12 | 13 | 例如。我们将使用什么技术，我们将如何交付项目，我们将使用哪些模式等。 14 | 15 | **分析风险和跨功能要求** 16 | 17 | 分析风险意味着降低风险：我们可以选择某种方法，还是说有太多未知数。 18 | 19 | 在承担一定风险时，对项目的影响是什么？例如。介绍您在会议上看到的新技术。 20 | 21 | 22 | **教练（Coaching）经验不足的人** 23 | 24 | 你很可能会在你的团队中有不同的经验的人。一旦谈到项目成本，混合和匹配技能和经验时，它就变得很有意义。也因此，需要培养经验不足的人。 25 | 26 | **利益相关者和团队之间的沟通** 27 | 28 | 业务利益相关者通常在技术上不如开发人员。他/她们将使用不同的语言，Tech Lead 将需要关注于这一点。 29 | 30 | ## 我们需要一个 Technical Lead 吗？ 31 | 32 | 有人反对这个角色，并声称一个运作良好的开发人员团队可以自己做出决策，并优先考虑重要的工作。即使存在这些完美的条件，在此期间团队成员公开谈论彼此，在达成一致同意的解决方案之前讨论利弊，也不需要花费太多时间来破坏这种微妙的平衡。 33 | 34 | Technical Lead 就是这样的一个角色。而不是关注于角色是否应该存在，最好将重点放在确保满足所有 Technical Lead 的职责上。与每个领导职位一样，糟糕的领导者会使事情变得更糟。有了如下的这些提示，我想帮助您确保不会发生这些。 35 | 36 | ## 两个故事 37 | 38 | 正如职位所暗示的那样，Tech Lead 是一份混合责任的工作：技术和领导。我将分享双方的提示，尽管区别并不总是很清楚。这些方面不太可能平分秋色。关于这一点内容，可以看提示 4。 39 | 40 | ## Techn Lead 提示 1： 倡导变革 41 | 42 | 倡导变革，意味着安装竖立起积极进化的思维模式。当一个流程缓慢或者繁琐时……，要尝试改变它，并使其变得更好。这样做的一种方法是使用 OODA 循环： 43 | 44 | - 观察（Observe） 45 | - 定位（Orient） 46 | - 决定（Decide） 47 | - 行动（Act）。 48 | 49 | PS：有关OODA的更多信息，请参见此[早期博客文章](https://ordina-jworks.github.io/architecture/2017/06/21/pragmatic-architecture-today.html)。 50 | 51 | 为了正确观察缓慢或繁琐的流程，重要的是成为团队的一员，并体验与团队中其他人一样的痛苦。你应该采取一种不断改善某种状况的心态。日本称之为“Kaizen”（改善法，其是起源于丰田公司在生产、机械和商务管理中持续改进的管理法）。在我们的案例中，您希望改进的情况是团队的效率和快乐感，以及软件项目的交付。 52 | 53 | 去寻找妨碍良好团队合作的问题。 54 | 55 | ## Techn Lead 提示 2： 经历失败和成功 56 | 57 | ### 事情会失败 58 | 59 | 事情会失败。不要过分担心失败。构建将失败。部署将失败。时间表将被遗漏。崩溃将会发生。如果你为失败做好准备，那么应该更容易应对。 60 | 61 | 当事情失败时，不要寻找责怪的人。你是 Tech Lead。承担责任，用你的精力来解决手头的问题并从中吸取教训。当然，不要两次修复同一个 bug。如果您需要两次修复相同的错误，那么你应该是做出了错误的决定。 62 | 63 | 从失败中汲取教训，将塑造您的方向，并在未来做出更好的决策。 64 | 65 | ### 庆祝成功 66 | 67 | 当团队有成就感时，他们会感到快乐和积极，尽可能做到最好。庆祝较小的成就非常重要，例如成功的冲刺或完成的功能。我做过一次项目，在那里我们交付了一个系统，客户对它非常满意……不幸的是，客户的愿景发生了变化，项目从未投入生产。如果那是你等待的那一刻…… 68 | 69 | 当有人想出一个新想法时，也许是他们在会议上看到的一种方法或框架，如果这个想法得以实现，重要的是任何带有新想法的人都应该被认可。这是非常有益的，将带来更多的合作，创造力和开箱即用的思维。 70 | 71 | 星期五晚上喝一杯，一顿小午餐，也许是一个团队建设都是一个很好的想法，可以让一个快乐和积极的团队。哦，这很有趣。 72 | 73 | ## Techn Lead 提示 3： 保持技术 74 | 75 | 技术主管有很多非编码职责，但不要忽视实践技术活动是非常重要的： 76 | 77 | - 编写代码，进行概念验证，定义接口……根据团队的成熟程度，您的参与会有所不同。 78 | - 进行代码审查，并审核您的代码。当新人到达项目时，我倾向于进行大部分代码审查，而且我会非常严格：我会编写导致 NullPointerExceptions 的测试，我会要求他们遵守惯例，使用单一责任原则，小心包装和命名等。我还将详细说明这些评论的推理和所做出的选择。这可能会挑战现有的工作方式并提高代码库的成熟度。他们必须做的更改（审核后）将很快变得更少。 79 | - 确保技术愿景存在，并由团队共享。这一愿景需要符合客户的需求。客户需求将导致重要的限制，例如。关于重用（一个一次性的营销项目与多年的企业努力……但要注意这种类型的约束也可能会改变）。分享您与团队实现这一愿景的方式，将会对其采用产生巨大影响。尝试让团队参与到技术愿景中。并确保他们知道他们如何为实现这一愿景做出贡献。 80 | - 密切关注代码的演变：一段时间后，您所做的实际编码量可能会更低，但您需要及时了解代码的演变。您需要了解系统及其技术限制。 81 | 82 | 大多数（如果不是全部）开发人员将乐于定义框架，提倡某些方法等。但是，一些非功能性需求（也称为质量属性）（如网络，安全性，部署和一致性）经常被忽视。 83 | 84 | ## Techn Lead 提示 4： 始终可用 （时间管理） 85 | 86 | 作为 Tech Lead，您应始终为您的团队服务；提问、支持、指导或做出决定。我开始写这篇博文时所说，Tech Lead 角色有两个重要方面，将这些结合起来绝非易事。对我来说很有意义的东西是写下你期望投入某些任务的努力量，例如： 87 | 88 | - **技术设计** 为团队（包括您）准备工作。确保清楚需要实施什么以及如何实施。这通常会考虑很多质量属性，如网络，安全性等。 89 | - **业务**：与客户交谈，查看他们的需求和目标，并将这些与项目的技术愿景相匹配。 90 | - **项目管理**：定义用户故事，估算，跟进。 91 | - **代码**：编写代码，进行代码审查等。 92 | 93 | 对于每个人和每个项目，分配的百分比显然会有所不同。查看实际情况也很重要，因为这些可以帮助您了解所花费的时间。 94 | 95 | ## Techn Lead 提示 5： 成为团队的导师 96 | 97 | - **调解员**：技术主管应该是调解员，便于讨论。当人们有不同的意见时，你应该接受这一点。因为这意味着他们足够关心某些事情来讨论它。最后，我们朝着同一个目标努力。每个人都可以从别人的意见中学习。获得团队的意见并尝试达成共识。如果达成共识真的不可能并且需要做出决定，那就做出决定。不决定总是会引发更多的讨论。 98 | - **导师**：技术主管应该是开发人员的导师，当老师。当您查看代码或解释某些约定时，请务必清楚地解释您为何以特定方式执行某些操作的原因。 99 | - **有效的授权**：一段时间后，您的团队将采用某些最佳实践，并且需要较少（严格）的审核或更多人将进行审核。在这一点上，您还可以向更多开发人员提供用户故事的所有权。通过将所有权转让给开发人员，他们将非常积极地做好工作。技术主管不应该试图承担所有责任。技术主管需要确保某人承担责任。 100 | - **匹配目标**：将开发人员的个人目标与项目和组织的更大目标相匹配。这是专门针对性的动态指导。动态，因为目标可以改变。在匹配目标时，沟通非常重要：它会让人感到受到重视。 101 | - **针对小组进行优化**：团队中的个人非常重要，但是当难以找到共识时，您应该关注的是团队。合作良好的团队将表现得更好，表现良好的团队成员是快乐的成员。 102 | 103 | 一个好的 Tech Lead： 104 | 105 | - 知道什么时候给予输入 106 | - 知道何时做出决定 107 | - 知道什么时候退后一步，让团队获得更多的所有权。 108 | 109 | 分担责任，给予所有权……但要保持负责。 110 | 111 | ## Techn Lead 提示 6： 与其他/她 Tech Lead 相联系 112 | 113 | 有很多理由将自己与其他/她 Tech Lead 联系在一起。在个人层面上，它提供了向同行学习的机会：他/她们如何为团队提供意见，以及他/她们如何在角色的不同职责之间分配时间。在组织层面，您应该验证是否有明确理解的总体目标。如果是这种情况，您可能需要调查是否需要跨组织协调才能实现目标。跟踪架构指南非常重要，以确保您的产品能够很好地与其他组件一起使用，并确保更大的系统保持一致。有可能依赖于其他团队的产品或其他团队的成员。确保在编写冲刺时考虑这些因素。 114 | 115 | 这种协调在许多（较大的）组织或客户中是一个真正的问题。投入网络时间是必要的，以避免超出您的控制范围的意外。 116 | 117 | ## Techn Lead 提示 7： 大处着眼，偏袒行动 118 | 119 | 大处着眼（Think Big）和偏袒行动（Bias for Action）是[亚马逊十二项领导原则中](https://www.amazon.jobs/principles)的两项。 120 | 121 | 大处着眼，意味着为项目或产品创建和传达大胆的方向。它将激发结果，因为人们正在努力做大事。有所作为的东西。关注未来可能出现的机会。 做出不受限制的决定。Dave Gray的 [Liminal Thinking](http://liminalthinking.com/) 是一本很好的书。 122 | 123 | 偏袒行动，意味着承认许多行动和决定是可逆的，不需要进行广泛的研究。完成任务……很重要。当飞轮运动时，它会继续旋转。专注于简单的事情，让飞轮移动。它将鼓励人们在最初的障碍下进行交付。 124 | 125 | ## Techn Lead 提示 8： 面试潜在的新团队成员 126 | 127 | 知道你面试的是什么。你是在寻找一个长期的人，还是在寻找一个短期任务的人？当你查看简历时，寻找模式：例如。任务的持续时间。这符合您的需求吗？如果没有，请确保您询问候选人是否有某些偏好。有些人喜欢长期项目，有些人则不喜欢。这不一定是阻塞问题。但这是值得讨论的问题。除此，请查看使用过的语言，库和框架。这些与您当前的选择匹配吗？当您在寻找长期的团队成员时，使用某些工具的经验不如意志、能力和学习的热情重要。我总是试图关注开发人员的心态：从逻辑上思考，确定解决某个问题的多种方法。就个人而言，我强烈反对使用 StackOverflow 查找问题。提出与您的项目相关的问题更为重要。我个人面试的模式如下： 128 | 129 | - 安慰（Comfort） 130 | - 提供选项 131 | - 建立在回应上 132 | - 展示兴趣 133 | - 奖金问题 134 | 135 | 当然，总是保持礼貌。如果候选人与您的具体目标不符，请不要让他/她带着糟糕的感觉回家。 136 | 137 | 注意：即使我们没有时间，资源或影响来修复团队组成，我们仍然需要完成任务。 138 | 139 | ## Techn Lead 提示 9： 拥抱文化差异 140 | 141 | 多样性非常宝贵。 所有人都不同，过着不同的生活。它非常有价值，因为您的用户也会有所不同。 用充满激情的人围绕自己。 142 | 143 | 如今大多数（如果不是全部）团队都使用某种即时消息。与不同时区的团队合作时，这变得更有价值，因为它可以实现异步通信并扩大潜在的答案。我之前提到过：每个人都是团队的一员，应该重视每个人的意见。 144 | 145 | ## Techn Lead 提示 10： 评估很难 146 | 147 | > 霍夫施塔特定律：即使考虑到霍夫施塔特定律，它也总是比你预期的要长。 ——Douglas Hofstadter 148 | 149 | 评估很难。如果你经常这样做，你会变得更好……但你仍然会不时地弄错。 150 | 151 | 在敏捷项目中，整个团队可以参加计划扑克会议（估点会议）。规划扑克可以在估计用户故事时暴露未知数。通常，有两种方法可以应对这些未知因素：在开始用户故事之前进行技术设计（例如，通过定义峰值）或接受风险，以及您的业务利益相关者。 152 | 153 | 作为 Tech Lead ，您可能还需要在团队实际构建某些内容或响应 RFP（请求提案）之前进行估算。这可以让业务利益相关者了解潜在成本，决定优先级或评估员工。 154 | 155 | 为了达到这个目的，我建议使用三点估计，你做一个乐观的，一个最好的猜测和一个悲观的估计，并使用这个公式：**（O + 4BG + P）÷ 6** 得到加权平均值。根据估算的性质，未知未知数的数量可能很大：项目可能与其他项目非常相似或完全不同。将这些考虑在内。对将要实施的团队进行估算：您可能正在估算一个真实的项目。在最好的条件下，这不是您可以做的事情的最快时间。估计代表了团队执行的能力；不是你自己实施的能力。还要确保，你知道你的可交付成果。这可能比代码和部署工具更多，例如。代码质量保证报告，使用手册，...... 156 | 157 | 记录假设。 158 | 159 | 掌握评估是一生的旅程。它会让你与众不同。您的同事会将您与专业，稳定和高质量的工作联系起来。 160 | 161 | ## Techn Lead 提示 11： 与外部世界的接口 162 | 163 | 非技术利益相关者使用的语言可能与开发团队的语言非常不同。Tech Lead 必须找到一种以非技术人员可以理解的方式交流思想的方法。例如，通过使用类比和使用其他人可以轻易涉及的术语。 164 | 165 | 在 DDD （领域驱动设计）世界中，这意味着建立一种通用语言。 166 | 167 | 与客户密切合作，尝试从他们那里检测需求，并不断地将他们的需求与正在进行的实施相关联。 168 | 169 | 作为 Tech Lead，我认为您不应该是单点联系人。 因为那时你在项目中引入了潜在的责任：对你的强烈依赖。在某些讨论中包括您的团队，但请确保您防止团队成员持续中断……所以不要成为单点联系人，而应尽量成为第一联系人。 170 | 171 | ## Techn Lead 提示 12： 促进（敏捷）团队工作 172 | 173 | 我会敦促所有 Tech Lead，促进敏捷团队的工作。当然，当涉及到业务时，这也会更好。但即使他们没有参与，也要指定代理产品所有者。这机会将是你。 174 | 175 | 无论你使用 Scrum，Kanban 或其他东西都重要，重要的是缩短开发周期，反馈循环等。 176 | 177 | ## 结论 178 | 179 | 你的团队的力量不是个人成员的才能。它是他们的合作，坚韧和相互尊重的功能。 180 | 181 | 如果您想了解有关 Tech Lead 的更多信息，可以在 [Devoxx](https://devoxx.be/) 上查看我在 [SlideDeck](https://www.slideshare.net/BartBlommaerts/javaday-2017-10-tips-to-become-an-awesome-technical-lead-v4) 上的幻灯片或 [YouTube](https://www.youtube.com/watch?v=yhtK1jQC_4s) 上的视频。 182 | -------------------------------------------------------------------------------- /articles/4-things-when-becoming-tech-lead.md: -------------------------------------------------------------------------------- 1 | # 当我成为 Tech Lead 时，我希望知道的四件事 2 | 3 | 原文链接：[Four Things I Wish I Knew When I Became a Tech Lead](https://product.hubspot.com/blog/four-things-i-wish-i-knew-when-i-became-a-tech-lead) 4 | 5 | 多年前，我的一位导师向我讲述了领导力（应对变革）与管理（应对复杂性）之间的区别。技术主管需要同时兼顾两者：我们必须提出发展技术系统的愿景，为客户解决问题，并将解决方案从概念转向生产。虽然所有这些都在发生，但我们需要引导，管理和支持我们团队中的人员，以便他们始终能够成长。对于第一次当 Tech Lead 的人来说，这可能是一种令人生畏的广泛责任。我知道这是给我的。 6 | 7 | 现在，作为一名高级的 Tech Lead，我在 HubSpot 上取得了一些成功。没有规则或指南可以帮助我在一夜之间掌握这个角色。但是当我的头衔第一次变成 Tech Lead 时，很多错误和'啊哈！'的时刻，让我意识到了许多我希望我知道的事情。这里有四个我认为成为领导者的关键。 8 | 9 | ## 你无法在工作中学到一切 10 | 11 | 不幸的是，就像教育只能以最基本的方式，为你做一个有效的个人贡献者一样，成为一个有效的个人贡献者，只能为你提供成为有效领导者所需技能的一小部分。这就是为什么我认为积极主动地学习，如何在成为 Tech Lead 之前、期间和之后领导团队。 12 | 13 | 我很幸运，当我开始我的职业生涯时，有一位经理与我公司以外的人联系，帮助我了解我的职业道路。他与我分享了很多关于 Tech Lead 的期望，认识到团队中人员的不同优势，同时平衡人员和产品需求。无论他们是您的经理，还是在另一家公司都有类似职业发展轨迹的人，找一位导师是成为领导者的重要资产。但你必须故意这样做；没有人会敲你的门乞求你让他们指导你。留意可能建立良好联系的活动或领导者可以联系的[社区](http://randsinrepose.com/links/2015/05/17/semi-informal-serendipitous-bitching/)。 14 | 15 | 根据公司的不同，您可能不必走得太远，无法找到培养领导风格的方法。加入 HubSpot 后，我学到的最激动人心的事情之一是：这里有一个内部团队，为管理人员提供明确的培训。他们开设了一门 12 门课程，内容包括从 1 对 1的有效运行到提供辅导，以及讨论职业目标。这些课程作为一名经理非常宝贵，并且充满了我仍在努力掌握的实用见解。幸运的是，如果办公室没有这些类型的流程，像 Intelligent.ly 这样的组织（在波士顿）也会举办领导力研讨会和管理培训。 16 | 17 | 多年来，我收集了一些书籍，我已经收集了领导力的洞察力。在他的书 [“Turn This Ship Around”](http://www.amazon.com/Turn-Ship-Around-Turning-Followers-ebook/dp/B00AFPVP0Y) 中，前潜艇队长 L. David Marquet 将领导者的成功描述为，创造更多的领导者而不是追随者：如果你是一个好的领导者，当你离开你的组织时，它将继续运作良好。为了做到这一点，您必须在团队的所有成员中建立技术能力，并为他们提供组织清晰度，以了解该做什么。这对我来说非常有助于我们，去培养小型自治团队的文化。更个人化的是，我最近阅读了 Eric Greitens 撰写的 [The Heart and the Fist](http://www.amazon.com/The-Heart-Fist-Education-Humanitarian/dp/0547750382)，它描述了面对挑战性情况时弹性和意志力的重要性，每个 Tech Lead 经常做的事情。 18 | 19 | 有一百万资源可以改变你的想法，为你的团队运作做好准备。但是你必须积极主动地寻找它们，并使学习成为工作的一部分。 20 | 21 | ## 领导风格应该反映团队，而不是领导者 22 | 23 | 当我第一次成为以前公司的领导者时，我知道自己不喜欢什么。我曾经参加过 “敏捷” 的团队，因为 “敏捷”（又称scrum）就是这样做的。我们曾经站在那里，刚刚一起工作的人会站起来说出，他们刚才在做什么。我们举行了每日站会，那些不参与相同事情（但是在同一个“团队”中）的人们粗略地总结了，他们为没有任何背景的人所做的工作。我去了回顾会议，没有人想说什么。 24 | 25 | 我梦想成为一个自组织敏捷团队的一员，你在 Scrum Master 培训中听到的那种，但从不参与，个人接受必要的工作，并在他们自己之间实现。我希望会议具有互动性和包容性。所以，我只是尝试以这种方式运行我的团队和会议。 26 | 27 | 我的部分策略工作正常。例如，让人们在会议开始时，在一个安静的头脑风暴时期，写下便利贴上的想法而不是亲自召唤他们（我从 Dave Gray 的 Gamestorming 书中偷走了一个技巧），帮助了我团队中的一些更安静的人在计划和回顾会议期间，而不是被一些有力的人格所压倒。第一次做这件事可能会感觉很奇怪，但我团队中的一些女士告诉我，这对他们来说有很大的不同。 28 | 29 | 其他部分则持平。我的团队还没有做好自我组织的准备，因为他们之前从未有过这种自主性。我们未能按时交付项目。任务没有完成；就像看着排球撞到地上一样，因为没有人打电话给它。我让团队侧身奔跑，而不是领导和管理。 30 | 31 | 不要认为适合自己的东西适合你的团队。我意识到，当你将自己的领导风格与个人（和团队）的准备情况相匹配时，你会对自己的输出感到更自信，并且他们感觉更舒服。一旦你建立了节奏，你就可以努力提高他们的技能，并赋予他们更多的独立性。 32 | 33 | ## （通过）沟通是关键 34 | 35 | 我和我们的首席执行官布莱恩·哈利根（Brian Halligan）共进晚餐时，他问桌上的每个 HubSpotter，如果我们是首席执行官，我们会怎么做。我说我会优先考虑扩展沟通和透明度。我之前曾经在公司工作过，其核心价值观和使命，在他们从管理层流向个人贡献者的时候被稀释了。每个季度，我们业务部门的首席执行官或副总裁都会坚持这一愿景。但是，有太多的中层管理层和如此多​​的 PowerPoint 标志，很难将我们日常的个人贡献与更大的图景联系起来。 36 | 37 | 当公司成长时，特别是当他们快速成长时，对于每一个移动的部件都要变得更加积极主动和有意识。但良好的内部沟通永远不会在洗牌中丢失。高层管理人员必须考虑，让整个公司与他们如何推动业务保持一致，作为一个 Tech Lead，你必须为你的团队做同样的事情。 38 | 39 | 我的团队渴望知道他们如何做出贡献，找到自己的东西，并产生影响。我只需要确保我在能力和技能方面，指导正确的业务方向。有时，我意识到我没有传达项目或技术决策的背景。但是当我以一种对我们的团队可操作和个性化的方式提炼大局时，他们的世界变得更加清晰，他们独立工作的能力提高了，他们可以将他们的努力与我们更大的使命联系起来。 40 | 41 | 在团队之外进行沟通，以帮助大型组织了解您所做的事情也很重要。特别是当事情进展不顺利时，我发现在共享文档中记录所有内容（我们使用 Google 文档）非常有帮助，该文档具有最新信息。这使团队能够协作并为解决问题做出贡献，同时也成为一种资源，可以让其他各方（例如，法律，运营，其他开发团队）快速上手，而无需人们阅读数小时的聊天记录或电子邮件线程。 42 | 43 | 你知道什么时候你不能沟通。您可以在团队开展项目的方向上看到它，并在需要重新考虑解决方案时感到困惑。您将听到管理层提出的难题。这就是为什么最好通过沟通。 44 | 45 | ## 精益求精的人比你聪明 46 | 47 | Tech Lead 几乎总是关于我们组织中产品的技术决策的最终仲裁者。我们喜欢给予人们责任，我们可以负担得起，因为我们确保他们拥有做出正确决定所需的所有工具和知识。作为一个 Tech Lead ，我有多个 “观察者”，他们会关注我并帮助我重回正轨，如果事情发生了变化。 48 | 49 | 我的第一个观察员是我的经理，他和我一起经常 1 对 1 聊天。我的经理提出了我忘记考虑的替代方案，并指出了我没有提供足够的领导力，以及我的团队迷路的时候。我们还使用 15five 作为工具来鼓励每个人反思他们的一周；我的 15 个报告给了我的经理一个不同的看法，让他提出问题并提出建议。拥有更有经验和更独立的眼睛，可以看到情况并提供反馈，这是非常宝贵的。 50 | 51 | 作为 SaaS 公司，我们还需要我们的操作系统高度可靠。我们的可靠性总监通过帮助 Tech Lead 管理运营危机，成功进行验尸并实施补救措施，充当监察员。对我而言，与我们的可靠性团队合作教会了我如何思考问题的严重性，并将 HubSpot 其余部分的最佳实践，应用到我们的 Sidekick 组织。 52 | 53 | Tech Lead 也有明确的机会相互学习。除了跨越团队的日常工作（给予从同行学习的隐含机会），我们还有每周一次的轮流午餐计划。这为我们提供了一个平台，可以与我们每天都无法解决的问题分享问题和解决方案。除了利用其他 Tech Lead 之外，我们还有另一项计划，让我们有机会不时地依靠我们的高级管理人员（有时候吃饭，喝酒或打保龄球。）。我意识到寻求帮助或寻找外面指导并没有错导。事实上，这是成长为高效 Tech Lead 的唯一途径。 54 | 55 | 成为一个伟大的 Tech Lead 是一项长期投资。我一直在遇到新的问题和艰难的对话。这就是为什么我希望几年前我所知道的最后一件事就是 Tech Lead ，特别是那些刚刚开始的 Tech Lead ，需要感到不舒服。积极主动地接触导师，并尽可能早地学习是在我的掌控之中，但我从那些没有的东西中学到了同样多的东西，如果不是更多的话。不要让错误把一切都抛在脑后，重要的是把它当作一个教训，让领导更自然地走下坡路。 56 | -------------------------------------------------------------------------------- /articles/5-signs-be-tech-lead.md: -------------------------------------------------------------------------------- 1 | # 5 个标志表明你是 Tech Lead 了 2 | 3 | 最近在工作中，我被任命为 Tech Lead。事实上，在一些项目里，我已经被称为 Tech Lead 一段时间了，但这恰好是一个小的结构变化。所以它让我思考，什么是 Tech Lead？ 4 | 5 | ## 什么是 Tech Lead？ 6 | 7 | 在 Google 上搜索 “What is Tech Lead？”，会找到一些结果，以及一个维基百科链接——它给了首席程序员（Lead Programmer）。 8 | 9 | > 首席程序员是负责一个或多个软件项目的软件工程师。相近的替代标题包括开发主管（Development Lead），技术主管（Tech Lead），首席软件工程师（lead software engineer），软件设计工程师负责人（ software design engineer lead ，SDE主管），软件开发经理（software development manager），软件经理（software manager）或主要应用程序开发人员。当要为高级企业软件设计角色做贡献时，经常使用的标题是软件架构师（或者类似）。 10 | 11 | 我真的不喜欢这个定义。这意味着 Tech Lead 要负责，但我认为这不是 Tech Lead。我认为这种负责更适合产品负责人甚至项目经理的描述。 12 | 13 | ## 什么不是 Tech Lead？ 14 | 15 | 事情有点模糊，有时候开始消除虚假的东西会更容易。 16 | 17 | - 并非总是正确 - 技术主管有时（而且应该）有时会出错。 18 | - 不负责所有 Pull Request - 通常，Tech Lead 被委派为 PR 的守门人。 我认为：（1）它不是一个理想的 Tech Lead 使用时间和（2）它不是一个伟大的团队结构。 19 | - 不是团队中最好或最有经验的程序员 - 但有时可以，但是没有要求任何方向 20 | 21 | ## 所以，什么是一个好的 Tech Lead？ 22 | 23 | 我在这个主题上做的研究越多，我就意识到技术主导有很多不同的定义。因此，更好的问题是什么是好的 Tech Lead。这里有 5 个标志，可以让你成为一个很好的 Tech Lead： 24 | 25 | 1. 你是可用的，且平易近人 - Tech Lead 需要做一些领导相关的工作。很多时候，这被认为是**领导力**，而不是直接的指挥链领导（职级领导）。其他软件工程师应该感到非常舒服，与您交谈并可能寻求帮助。 26 | 2. 您是一名软件工程师 - 您必须保持强大的技术支持。您应该对代码库有一个很好的理解，并能够解决它周围的问题。这意味着您还在编码。其他软件工程师应该重视您的技术反馈。 27 | 3. 您了解业务 - 您应该对如何确定对业务重要的事项进行优先级评估，以便将此信息传达给团队中的其他人。 28 | 4. 你接受你并不总是正确的，但可以证明你为什么这样做 - 你有想法并有技术方面的解释，但你接受团队中的其他软件工程师可能会提出更好的方法。这（1）表明您愿意并且能够学习，（2）有助于为您的团队提供增长机会。 29 | 5. 当团队中的其他软件工程师成功时，您会很高兴 - 这是关键！如果您的团队中的其他软件工程师成功并获得信誉，那么您就不会成为一名优秀的 Tech Lead。这通常意味着你没有获得那么多的荣耀，但作为 Tech Lead，你应该对此感到满意。 30 | 31 | ## 这不适合每个人 32 | 33 | 你是怎么做的？你有这 5 个标志吗？如果是的话，恭喜！ 如果没有，不要担心！ 34 | 35 | 我不相信成为 Tech Lead 是每个软件工程师的自然或理想的一步。我个人认为，我与其他领导的经历，使我处于一个我自然倾向于并且能够擅长的地位。 36 | 37 | 但是，我认识到作为 Tech Lead 需要时间来编写代码。而由于这种副作用，我们很多人倾向于避免会议，因为出于同样的原因，我们中的一些人是否会避免担任 Tech Lead 的角色和责任？ 38 | -------------------------------------------------------------------------------- /articles/README.md: -------------------------------------------------------------------------------- 1 | Tech Lead 相关文章 2 | === 3 | 4 | Category: 5 | 6 | - Programming 7 | - People 8 | - Process 9 | - Soft-Skills 10 | 11 | Related：[Lead Programmer](https://en.wikipedia.org/wiki/Lead_programmer) 12 | 13 | 14 | ## Tech Lead Summary 15 | 16 | | English | 中文翻译 | Category | 17 | |--------|------------|---------| 18 | | [Twelve tips to become an awesome Technical Lead](https://ordina-jworks.github.io/architecture/2017/12/22/Tech-Lead.html) | [成为优秀 Tech Lead 的 12 个提示](./12-tips-be-tl.md) | Main | 19 | | [What Does a Software Tech Lead Do?](http://allyouneedisbackend.com/blog/2018/08/03/what-does-a-tech-lead-do/) | [好的 Tech Lead 在做些什么？](./what-tech-lead-do.md) | 20 | | [Agile Practices of Effective Tech Leads](https://medium.com/the-andela-way/agile-practices-of-effective-tech-leads-888c46eb1710) | [敏捷项目中的高效 Tech Lead](./effective-tech-lead-in-agile.md) | Main | 21 | | [What Makes a Good Tech Lead?](https://jasonroell.com/2015/10/13/what-makes-a-good-tech-lead/) | [怎样才是好的 Tech Lead（技术负责人）？](./what-make-a-good-tech-lead.md)| Main | 22 | | [Tech Leads: What Are They Good For?](https://medium.com/myplanet-musings/tech-leads-what-are-they-good-for-165108411be) | [Tech Lead：他们有什么好处？](./tech-lead-good-for.md) | Options | 23 | | [We don't need a Tech Lead](http://vvgomes.com/we-dont-need-tech-leads/) | [我们并不需要一个 Tech Lead](./dont-need-tech-lead.md) | Options | 24 | | [5 Signs You’re A Tech Lead — Congrats!](https://abc.danch.me/5-signs-youre-a-tech-lead-congrats-4b89b6b9c071) | [5 个标志表明你是 Tech Lead 了](./5-signs-be-tech-lead.md) | Options | 25 | | [Responsibilities of a Lead Developer](http://blog.robbowley.net/responsibilities-of-a-lead-developer/) | [首席开发人员的责任](./lead-programmer-reponsiblities.md) | Defined | 26 | | [Technical leader – Roles and Responsibilities](https://www.weetechsolution.com/blog/technical-leader-roles-and-responsibilities) | [Tech Lead 的角色和责任](./tech-lead-role-responsibilities.md) | Responsibilities | 27 | | [The Tech Lead’s New Project Checklist](https://insimpleterms.blog/the-tech-leads-new-project-checklist) | [Tech Lead 的新项目检查清单](./tech-lead-new-project-checklists.md) | Checklists | 28 | | [8 qualities of a great Technical Leader](https://www.monterail.com/blog/2015/8-qualities-of-a-great-technical-leader) | [好的 Tech Lead 应具有的 8 个品质](./tech-lead-8-qualities.md) | Checklists | 29 | | [Becoming a Tech Lead: How I've Balanced Coding with Coaching](https://product.hubspot.com/blog/tech-lead-balancing-coaching-with-coding) | [成为 Tech Lead 时：我是如何平衡编码与教练](./tech-lead-balancing-coaching-with-coding.md) | Balance | 30 | | [Five pieces of advice for new technical leads](https://engineering.rallyhealth.com/technical-lead/leadership/new-leader/advice/new-role/tech-lead/2018/07/05/five-pieces-of-advice-for-new-technical-leads.html) | [给新 Tech Lead 的五个建议](./five-advice-for-new-tech-leads.md) | Tips | 31 | | [Four Challenges Every Software Tech Lead Faces](https://www.forbes.com/sites/forbestechcouncil/2018/09/28/four-challenges-every-software-tech-lead-faces/) | [每个 Tech Lead 面临的四个挑战](./tech-lead-4-challenges.md) | Tips | 32 | | [My lessons learned while becoming a Tech Lead](https://medium.com/quintoandar-tech-blog/my-lessons-learned-while-becoming-a-tech-lead-cacb1fc4e69f) | [成为 Tech Lead 过程中吸取的教训](./being-tech-lead-lesson.md) | Tips | 33 | | [https://www.nikosraptis.com/single-post/2017/01/21/Tech-Lead-or-no-Tech-Lead](https://www.nikosraptis.com/single-post/2017/01/21/Tech-Lead-or-no-Tech-Lead) | [要 Tech Lead 还是不要 Tech Lead ](./tech-lead-or-tech-lead.md) | Options | 34 | | [Good Tech Lead, Bad Tech Lead](https://medium.com/swlh/good-tech-lead-bad-tech-lead-948b2b806d86) | [好的 Tech Lead，糟糕的 Tech Lead](./good-tech-lead-bad-tech-lead.md) | Compare | 35 | | [Four Things I Wish I Knew When I Became a Tech Lead](https://product.hubspot.com/blog/four-things-i-wish-i-knew-when-i-became-a-tech-lead) | [当我成为 Tech Lead 时，我希望知道的四件事](./4-things-when-becoming-tech-lead.md) | Exp | 36 | | [Main Skills a Tech Leader Should Have](https://blog.makingsense.com/2017/02/main-skills-a-tech-leader-should-have/) | [Tech Lead 应具备的主要技能](tech-lead-main-skills.md) | Skills | 37 | | [What I believe is a triangle of success for Software Architects and Technical Leads](https://dev.to/ggonchar/what-i-believe-is-a-triangle-of-success-for-software-architects-and-technical-leads-2gek) | [我所相信软件架构师和技术领导者的成功三角](tech-lead-architecture-triangle.md) | Options | 38 | | [Software architects & autonomous teams](https://ebaytech.berlin/software-architects-and-autonomous-teams-328138202df1) | [软件架构和自组织团队](software-architecture.md) | Compare | 39 | | [Analyzing Requirements as a Tech Lead](http://www.zsoltnagy.eu/analyzing-requirements-as-a-tech-lead/) | [Tech Lead 需求分析](tech-lead-analyzing-requirements.md) | Model | 40 | | [How to Build a Software Engineering Culture Where Everyone Can Thrive](https://medium.com/@ann_lewis/how-to-build-a-software-engineering-culture-where-everyone-can-thrive-e927bc52ea97) | [如何建立一个每个人都能茁壮成长的软件工程文化](howto-build-thrived-culture.md) | Culture | 41 | | [What makes a great Tech Lead?](https://www.madetech.com/blog/what-makes-a-great-tech-lead) | [如何成为一个伟大的 Tech Lead？](make-great-tech-lead.md) | Options | 42 | | [https://stormpath.com/blog/how-to-build-engineering-culture](https://stormpath.com/blog/how-to-build-engineering-culture) | [建设优秀工程文化的 9 种方法](great-culture.md) | Culture | 43 | | [How to keep your engineering culture while scaling your business](https://m.oursky.com/how-to-keep-your-engineering-culture-while-scaling-your-business-481820333392) | [如何在高速发展的同时，保持工程师文化](keep-culture-while-scaling.md) | Culture | 44 | | [Tech Lead Survival Guide](https://medium.com/@ann_lewis/tech-lead-survival-guide-aeee065fe0f5) | [Tech Lead 生存指南](tech-lead-survival-guide.md) | Guide | 45 | | [10 Tips for Being a Good Tech Lead](https://habr.com/en/post/439492/) | [成为优秀技术主管的 10 个技巧](10-tip-good-tl.md) | TIP| 46 | | [What does a tech lead do?](https://www.bitlog.com/2017/10/12/what-does-a-tech-lead-do/) | [Tech Lead 做些什么事？](tech-lead-do.md) | DO | 47 | | [What It Takes To Be A Great Technical Leader](https://www.businessinsider.com/how-to-be-a-great-technical-leader-2013-6) | [怎样成为优秀的 Tech Lead？](to-be-great-tl.md) | Tip | 48 | | [11 Top Responsibilities and 10 Common Mistakes of a Technical Leader](https://www.coderhood.com/11-top-responsibilities-and-10-common-mistakes-of-a-technical-leader/) | [Tech Lead 最重要的 11 项责任和 10 个常见错误](11-responsibilities-10-mistakes.md) | Tip | 49 | 50 | 51 | ## Articles List 52 | 53 | - [x] https://medium.com/myplanet-musings/tech-leads-what-are-they-good-for-165108411be 54 | - [x] https://medium.com/the-andela-way/agile-practices-of-effective-tech-leads-888c46eb1710 55 | - [x] https://jasonroell.com/2015/10/13/what-makes-a-good-tech-lead/ 56 | - [x] [5 Signs You’re A Tech Lead — Congrats!](https://abc.danch.me/5-signs-youre-a-tech-lead-congrats-4b89b6b9c071) 57 | - [x] [The Tech Lead’s New Project Checklist](https://insimpleterms.blog/the-tech-leads-new-project-checklist) 58 | - [ ] https://medium.com/the-andela-way/the-briceicle-test-12-steps-to-better-technical-leadership-57e27356c4bb 59 | - [x] [Analyzing Requirements as a Tech Lead](http://www.zsoltnagy.eu/analyzing-requirements-as-a-tech-lead/) 60 | - [ ] [Contrasting the Waterfall Model, Agile, Lean and DevOps](https://medium.com/@freddyyumba/contrasting-the-waterfall-model-agile-lean-and-devops-a95cd9acf58) 61 | - [x] [11 Top Responsibilities and 10 Common Mistakes of a Technical Leader](https://www.coderhood.com/11-top-responsibilities-and-10-common-mistakes-of-a-technical-leader/) 62 | - [x] [Technical leader – Roles and Responsibilities](https://www.weetechsolution.com/blog/technical-leader-roles-and-responsibilities) 63 | - [x] [Responsibilities of a Lead Developer](http://blog.robbowley.net/responsibilities-of-a-lead-developer/) 64 | - [x] [We don't need a Tech Lead](http://vvgomes.com/we-dont-need-tech-leads/) 65 | - [ ] [Talking Feature Leads](https://www.thekua.com/atwork/2012/07/talking-feature-leads/) 66 | - [ ] [You're a Champion](http://ryanogles.by/youre-a-champion/) 67 | - [x] [Four Things I Wish I Knew When I Became a Tech Lead](https://product.hubspot.com/blog/four-things-i-wish-i-knew-when-i-became-a-tech-lead) 68 | - [ ] [WHAT I WISH I KNEW AS A FIRST TIME TECH LEAD](https://2017.theleaddeveloper.com/blog/2017-03-01-what-i-wish-i-knew-as-a-first-time-tech-lead) 69 | - [x] [8 qualities of a great Technical Leader](https://www.monterail.com/blog/2015/8-qualities-of-a-great-technical-leader) 70 | - [x] [Becoming a Tech Lead: How I've Balanced Coding with Coaching](https://product.hubspot.com/blog/tech-lead-balancing-coaching-with-coding) 71 | - [x] [My lessons learned while becoming a Tech Lead](https://medium.com/quintoandar-tech-blog/my-lessons-learned-while-becoming-a-tech-lead-cacb1fc4e69f) 72 | - [x] [Four Challenges Every Software Tech Lead Faces](https://www.forbes.com/sites/forbestechcouncil/2018/09/28/four-challenges-every-software-tech-lead-faces/) 73 | - [x] [10 Tips for Being a Good Tech Lead](https://habr.com/en/post/439492/) 74 | - [x] [Five pieces of advice for new technical leads](https://engineering.rallyhealth.com/technical-lead/leadership/new-leader/advice/new-role/tech-lead/2018/07/05/five-pieces-of-advice-for-new-technical-leads.html) 75 | - [ ] [Project Team Roles at Atomic – The Tech Lead](https://spin.atomicobject.com/2018/08/22/tech-lead-role/) 76 | - [x] [Tech Lead Survival Guide](https://medium.com/@ann_lewis/tech-lead-survival-guide-aeee065fe0f5) (TLDR) 77 | - [ ] [No Tech Lead](https://adamralph.com/2014/03/15/no-tech-lead/) 78 | - [x] [Good Tech Lead, Bad Tech Lead](https://medium.com/swlh/good-tech-lead-bad-tech-lead-948b2b806d86) 79 | - [x] [What Does a Software Tech Lead Do?](http://allyouneedisbackend.com/blog/2018/08/03/what-does-a-tech-lead-do/) 80 | - [x] [Tech Lead or no Tech Lead](https://www.nikosraptis.com/single-post/2017/01/21/Tech-Lead-or-no-Tech-Lead) 81 | - [x] [What does a tech lead do?](https://www.bitlog.com/2017/10/12/what-does-a-tech-lead-do/) 82 | - [x] [What I believe is a triangle of success for Software Architects and Technical Leads](https://dev.to/ggonchar/what-i-believe-is-a-triangle-of-success-for-software-architects-and-technical-leads-2gek) 83 | - [x] [What makes a great Tech Lead?](https://www.madetech.com/blog/what-makes-a-great-tech-lead) 84 | - [ ] [What's awful about being a {software engineer, tech lead, manager}?](https://www.onebigfluke.com/2016/04/whats-awful-building-software.html) 85 | - [x] [Main Skills a Tech Leader Should Have](https://blog.makingsense.com/2017/02/main-skills-a-tech-leader-should-have/) 86 | - [ ] [Tech lead roles: What makes a technical leader?](http://martinb3.io/tech-lead-role/) 87 | - [x] [Software architects & autonomous teams](https://ebaytech.berlin/software-architects-and-autonomous-teams-328138202df1) 88 | - [ ] [https://gist.github.com/ygrenzinger/14812a56b9221c9feca0b3621518635b](https://gist.github.com/ygrenzinger/14812a56b9221c9feca0b3621518635b) 89 | - [x] [How to keep your engineering culture while scaling your business](https://m.oursky.com/how-to-keep-your-engineering-culture-while-scaling-your-business-481820333392) 90 | - [x] [How to Build a Software Engineering Culture Where Everyone Can Thrive](https://medium.com/@ann_lewis/how-to-build-a-software-engineering-culture-where-everyone-can-thrive-e927bc52ea97) 91 | - [x] [9 Ways to Build a Great Engineering Culture](https://stormpath.com/blog/how-to-build-engineering-culture) 92 | - [x] [What It Takes To Be A Great Technical Leader](https://www.businessinsider.com/how-to-be-a-great-technical-leader-2013-6) 93 | 94 | ## Hacker News && Quora 95 | 96 | - [ ] [Ask HN: How to Be a Good Technical Lead?](https://news.ycombinator.com/item?id=10395046) 97 | - [ ] [How do I become a great tech lead?](https://www.quora.com/How-do-I-become-a-great-tech-lead) 98 | 99 | ## Technical, Skills, Architect 100 | 101 | - [Who is Solution Architect: Processes, Role Description, Responsibilities, and Outcomes](https://www.altexsoft.com/blog/engineering/solution-architect-role/) 102 | 103 | ## Tech Lead JDs 104 | 105 | - [Amazon Web Services: Technical Team Lead](https://www.amazon.jobs/zh/jobs/584828/technical-team-lead-amazon-web-services) 106 | -------------------------------------------------------------------------------- /articles/being-tech-lead-lesson.md: -------------------------------------------------------------------------------- 1 | # 成为 Tech Lead 过程中吸取的教训 2 | 3 | 原文链接：[My lessons learned while becoming a Tech Lead](https://medium.com/quintoandar-tech-blog/my-lessons-learned-while-becoming-a-tech-lead-cacb1fc4e69f) 4 | 5 | *本文记录了我的经历、经验教训，以及我希望之前有人告诉我的一些事情。在这篇文章中，我将分享我从我之前的工作，以及在 QuintoAndar.com 上的当前工作中学到的东西。* 6 | 7 | 扮演技术角色的角色，因公司不同而有所不同，但我试图将我所学的内容简化为技术参考，或者是拥有 Tech Lead 的官方头衔。 8 | 9 | 我认为在科技行业中，这个角色是非正式地由高级开发人员扮演，而这正是我在之前的 3 年工作中所做的。 10 | 11 | 在 QuintoAndar，我于 2016 年 11 月正式成为 Tech Lead，所以它已经有 2 年了，这里是我在过去 5 年中学到的一些东西。我远没有掌握它们，但我每天都尽力记住它们。 12 | 13 | ## 学会放手解决您的技术问题 14 | 15 | 我想这是我希望的事情——有人可以在几年前告诉我的第一课。实际上，我觉得有人在几年前就告诉了我，但是我花了一段时间才真正吸收它，但是，我有时还会挣扎。 16 | 17 | 通常，好的 Tech Lead 的技能之一，也是优秀的软件工程师和开发人员。这不是唯一需要的技能，但它通常是管理者在考虑促使某人成为 Tech Lead 时，开始关注的首要技能之一。 18 | 19 | 在这些年作为 Tech Lead 的过程中，我了解到，如何教导团队做出正确的决定，而不是告诉他们该做什么，这一点更为重要。 20 | 21 | 不是教他们如何编码，尝试展示你如何做出决定，你的想法，你考虑什么，你如何平衡事物，有时所有这些都与你的编码方式有关，但不一定。 22 | 23 | 你不雇用优秀的开发人员告诉他们该做什么，你雇用他们来创建好的解决方案，不仅要编写代码，还要解决问题。相信他们。 24 | 25 | 我还了解到，团队将更加致力于提供他们提出的解决方案，而不是技术主管可能创建的解决方案。即使团队提出的可行解决方案，并不是我认为最好的解决方案，我也倾向于将此决定委托给团队。我只是试着引导他们，找到一个可行的解决方案。 26 | 27 | 如果你想成为一名优秀的 Tech Lead ，我认为没有骄傲或嫉妒的空间。团队比你更重要，一旦你意识到这一点，你将更快地变成一个更好的领导者。 28 | 29 | 30 | ## 团队的工作方式比团队中的人更重要 31 | 32 | 您需要了解您的团队，他们的期望，他们的动机以及他们职业生涯的时间。有时候，你需要适应自己。 33 | 34 | 您与一个团队的动态，并不一定适用于您之后将要使用的每个团队。人与众不同，对事物的看法不同。 35 | 36 | 显然，根据团队的成熟程度，您需要引导他们，并展示他们没有看到的其他选项和路径。有时你需要引导它们，让它们自己找到更好的路径，而不仅仅是指向它们。 37 | 38 | 您可能需要学习，如何为他们一起工作创建一个安全的空间。只招聘 A 级的程序员，并不能保证你将拥有一支高绩效和可交付的团队——如果他们不知道如何一起工作。有时，您的任务是帮助他们实现这一目标。 39 | 40 | ## 建立信任关系 41 | 42 | 你之前可能已经听过这个说法，但我真的相信它。 43 | 44 | > 领导力不是给的，而是赚到的。 45 | 46 | 许多人认为，如果你有领导头衔，人们会尊重并关注你。他们可能会跟随，因为他们害怕你，因为你可以解雇他们，但对我而言，这不是领导。 47 | 48 | 对我而言，领导力是在你的团队信任你的时候。即使有时候他们不理解百分之百的决定，如果他们信任你，他们也会帮助你并成为目标。 49 | 50 | 如果你被聘请领导已经组装的团队，我的建议是：在任何事情之前，尝试了解他们是如何工作的，不要试图过分强调你的方法。 它可能会反击你。 51 | 52 | 可以帮助您建立这种信任的一个方面是提供真实的反馈。 53 | 54 | ## 练习并提供真实的反馈 55 | 56 | 了解如何提供结构化反馈。 57 | 58 | 有时他们需要严厉，但如果他们有条理、真诚，你表明你所说的是因为你真的关心这个人及其职业，它会对他们产生巨大的影响。 59 | 60 | 这里有关于 Radical Candor 的好视频：[https://www.youtube.com/watch?v=yj9GLeNCgm4](https://www.youtube.com/watch?v=yj9GLeNCgm4) 61 | 62 | 还有其他框架可以帮助您提供反馈，只记得诚实并在执行时带来示例。 63 | 64 | 请记住，你需要练习和谈论他们的职业生涯。如果你和你的六个月的开发人员做了 1：1 的聊天，并且你从未进行过至少一次，你认为“这次谈话并不容易”的对话，你可能不会谈论需要谈论什么。 65 | 66 | ## 你无法取悦所有人 67 | 68 | 你想要取悦并让团队中的每个人都高兴，我知道你真的这么做，有时候你的决定会让别人不高兴。 69 | 70 | 这很难，你可能会感觉很糟糕，并认为你可能不公平。但要相信自己的直觉并与自己保持和平，以便用当时的信息做出最好的决定。 71 | 72 | 你无法预测未来。尝试根据您所处的环境做出最佳决策，这是您目前可以做的最好的决定。 73 | 74 | 我做了一些我今天可能不会做出的决定，但过去我必须让它们从中学习。 75 | 76 | ## 从您之前的决定中学习，让自己成为更好的版本 77 | 78 | 正如我之前所说，从你以前的决定中学习。 79 | 80 | 花一点时间回顾一下，想一想今天可以做些什么。不是因为它过去一定是错的而你后悔了，但因为我们经常变化，你不是六个月前的那个人，现在你可以针对同样的问题做出不同的决定。 81 | 82 | 关键是，如果我们不实践这一点，如果我们不看自己并对自己诚实，我们可能冒险根本不进化。 83 | 84 | ## 拥抱旅程 85 | 86 | 因为这是一段旅程。你将永远学习和发现你可以提高自己。 87 | 88 | 我认为有时候成为一名 Tech Lead（技术领导者）很难，因为你要为很多事情负责，有时，你可能没有得到所有的答案。 89 | 90 | 但它也真的很棒。 91 | 92 | 您不仅可以对您提供软件的人的生活产生巨大影响，而且还可以对与您一起构建软件的人的生活产生巨大影响。这可能会改变你和他们的生活。在教别人的同时，你可以学到很多东西。 93 | 94 | 如果你正在成为 Tech Lead（技术领导者），我最大的建议是：**它不再是关于你了**。 95 | 96 | 我认为这是关于如何帮助周围的人，比在遇到你之前做得更好。有时，是为了帮助他们变得比以往任何时候都更好。 97 | 98 | 不要因为嫉妒或恐惧而限制人们的成长。 99 | 100 | 帮助他们释放出更好的版本。 为他们加油。 为他们感到骄傲。 101 | 102 | 这就是我所学到的，我每天都在努力。 103 | -------------------------------------------------------------------------------- /articles/decisions.md: -------------------------------------------------------------------------------- 1 | 2 | Role Model 3 | 4 | - Team Focus. Make Team Stronger 5 | - Member Focus. Make one member happy 6 | - Self Focus （Tech Excellent) . Make self Happy 7 | - Business Focus. Make money 8 | 9 | **Inception** 10 | 11 | - GitFlows 12 | - Editor/IDE 13 | - CI/CD Tools 14 | - Build Tools 15 | - 16 | 17 | **Soft Skilsl** 18 | 19 | - Lead by example 以身作则 20 | 21 | 22 | ## How to Be Tech Lead 23 | 24 | - Ownership. 25 | - Vision (Big Picture) 26 | - Chance 27 | -------------------------------------------------------------------------------- /articles/dont-need-tech-lead.md: -------------------------------------------------------------------------------- 1 | # 我们并不需要一个 Tech Lead 2 | 3 | 原文链接：[We don't need a Tech Lead](http://vvgomes.com/we-dont-need-tech-leads/) 4 | 5 | 对于大中型团队而言，全职 Tech Lead（技术负责人）负责重要的领导活动是非常普遍的。这些活动诸如： 6 | 7 | - 指导项目技术愿景 8 | - 分析风险和跨功能需求 9 | - 教练经验不足的人 10 | - 利益相关者和团队之间的沟通 11 | 12 | 一般而言，被指定为 Tech Lead 的人都具有良好的技术经验和良好的沟通技巧。他/她将对项目的技术方向负责，并担任跨团队互动的首选人。 13 | 14 | ## 我们是否需要一个 Tech Lead？ 15 | 16 | Pat Kua 在两年前写了一篇文章（[Do we need a Tech Lead](https://www.thekua.com/atwork/2014/10/do-we-need-a-tech-lead/)），他支持这样的观点，即大多数软件团队**都需要** Tech Lead 的存在。 用他的话说： 17 | 18 | > 人们反对这个角色，并声称一个运作良好的开发人员团队，可以做出决策并优先考虑重要的工作。我完全同意这个理想世界的立场。可悲的是，理想的世界很少存在。 19 | 20 | 根据我的观察和个人经验，我倾向于以两种方式不同意这种观点： 21 | 22 | - 运作良好的团队，人们分担责任并**不罕见**。 23 | - 当团队运作不良时，分配 Tech Lead 可能会使情况**变得更糟**。 24 | 25 | ## Tech Lead是一个解决方法吗？ 26 | 27 | 要说 Tech Lead 是必要的，因为理想条件很少是说 Tech Lead 是一种解决方法 - 而不是根本原因的解决方案。这意味着角色就在那里，因为情况不是最理想的。当一个团队运作不良时，可能会有一些破窗需要解决。Tech Lead 只能减轻后果。 28 | 29 | 然而，在他的文章中，Pat Kua 给出了一个示例场景，其中需要技术主管： 30 | 31 | > 技术辩论在开发团队中经常发生。没有什么比团队达成冷冻状态时更糟糕的了。 32 | 33 | > Tech Lead 有责任帮助团队向前发展......促进和谈判技巧对于 Tech Lead 来说是非常宝贵的资产。 34 | 35 | 那么，在这种情况下，我们可能需要的是**调解员**。任何具有协助和谈判技巧的人都可以根据需要发挥这一作用。将多种技能期望推向一个人是不可扩展的;它压倒了负责人，破坏了整个团队。 36 | 37 | ## Tech Lead 会让情况变得更糟吗？ 38 | 39 | 大约四年前，我写了一篇文章 [More Testing, Less Testers](http://vvgomes.com/more-testing-less-testers/)，它是关于人们锻炼不同技能，并在团队中扮演多重角色的重要性。 40 | 41 | > 我见过的最成功的团队分享了这样一个事实：人们是多功能和自我管理的，从某种意义上说，每个成员都会积极参与 a）帮助企业找出并定义需求，b）直接工作 关于功能的开发，c）直接研究相关活动的测试。 42 | 43 | 我坚信也可以扩展到 Tech Lead 活动中。角色轮换背后的主要思想是降低风险。无论 Tech Lead 的经验水平如何，角色的存在都存在各种风险。而随着团队变得更大，这些风险的严重程度会增加。 44 | 45 | ## 对于 Tech Lead 风险 46 | 47 | - 活动超载 - 对单个人的期望过高。 48 | - 由于持续的上下文切换，缺乏对细节的关注。 49 | - 单点故障 - 当信息集中在 Tech Lead 上时。 50 | - 责备文化 - Tech Lead 通常是对失败负责的人。 51 | - 距离 - 当 Tech Lead 远离团队时。 52 | - 缺乏同伴感 - 当 Tech Lead 不再被视为团队成员时。 53 | 54 | ## 对团队的风险 55 | 56 | - 缺乏集体所有权 - 当关键决策不是集体决策时。 57 | - 瓶颈 - 当所有决定必须通过 Tech Lead。 58 | - 公交因素 - 当团队无法在没有 Tech Lead 的情况下运营。 59 | - 对动机的影响 - 当团队成员感到无能为力和无声时。 60 | 61 | 除此之外还存在另一种心理风险：在两人或两人以上具有足够 Tech Lead 技能的团体中，如何选择其中一人作为 Tech Lead，而不让其他人感到贬值？ 62 | 63 | 总之，这些问题是全职 Tech Lead 存在的直接后果。Tech Lead 带来的最终好处，通常不会减轻必须应对风险的负担。 64 | 65 | ## Leadership 66 | 67 | 我们还需要软件团队的领导力吗？ - 我们肯定会这样做。但领导力是一种技能,而非个人角色。 68 | 69 | 在最近的一次[采访](http://www.se-radio.net/2016/03/se-radio-episode-253-fred-george-on-developer-anarchy/)中，Fred George 提出了一种季节性和分散的领导模式，在这种模式中，领导者自然会在特定时间根据项目需求出现。 70 | 71 | - 当有新人时，我们需要一位强大的教练。 72 | - 当存在架构挑战时，我们需要经验丰富的架构师。 73 | - 当存在内部冲突时，我们需要一名调解员。 74 | - 当有外部阻滞或缺乏资源时，我们需要看门人。 75 | - 当我们需要与其他团队进行谈判和整合时，我们需要一位大使。 76 | 77 | 这只是一些例子。对一个人（Tech Lead）设定所有这些能力的期望显然不是一个好主意。另一方面，建立一支能够有效发挥作用的互补能力的团队似乎更合理。 78 | 79 | 关于分散领导的另一个观点是 Features Lead（最初由 Pat Kua 提出，并且我的同事 Ryan Oglesby 也讨论过：[You're a Champion](http://ryanogles.by/youre-a-champion/)）。在该方法中，Tech Lead 被分解为开发中的系统的相关功能和或正交方面的片段。它有助于通过将领导活动，分散到多个人来最小化风险。 80 | 81 | ## 结论 82 | 83 | 那么，我们真的需要技术领先吗？ - 当条件不理想时，也许是的。但 Tech Lead 几乎肯定无法将条件变为理想状态。在次优情况下，运营的团队通常会破坏窗户和拦截器。很多时候，您会在 [极限编程](http://www.extremeprogramming.org/values.html) 中找到您的团队正在寻找的确切答案。除此之外，如果你找不到合适的人与你合作，就没有灵丹妙药，所以招聘在这里发挥了重要作用。 84 | 85 | 总的来说，在团队中分配一名全职 Tech Lead 是有风险的，可能会使事情变得更糟。健康和高效的软件团队很可能不需要 Tech Lead 。 86 | 87 | 88 | -------------------------------------------------------------------------------- /articles/effective-tech-lead-in-agile.md: -------------------------------------------------------------------------------- 1 | # 敏捷项目中的高效 Tech Lead 2 | 3 | 原文链接：[Agile Practices of Effective Tech Leads](https://medium.com/the-andela-way/agile-practices-of-effective-tech-leads-888c46eb1710) 4 | 5 | Tech Lead（技术负责人）或技术团队负责人或工程负责人是软件开发学科中的共同角色。该人员负责复杂软件解决方案的整体规划、执行和成功，以满足客户的需求。在过去一年半的时间里，我花了很多时间在 Andela 的工程部门指导 Tech Lead。在这篇文章中，我将分享我迄今为止所学到的，关于我认为为敏捷团队中的高效的 Tech Lead（技术负责人）所做的关键实践。 6 | 7 | ## 1.协作 8 | 9 | 身为一个 Tech Lead，您花费了大量时间来识别和清除团队的障碍。它需要有效的协作技能。您需要与不同的业务功能协作，以获取团队需要前进的方向。通过与产品经理合作，确保下一个开发迭代里 backlog 有足够的卡，从设计人员获取特定功能的高保真设计，以确保团队中的开发人员拥有合适的硬件来完成工作。一个伟大的 Tech Lead 要提前考虑、预测风险，并在他们成为团队的瓶颈之前解决它们。 10 | 11 | 高效的 Tech Lead 也是一个很好的沟通者。他们为非技术人员找到理解技术概念的方法。他们通过将业务术语引入开发团队并鼓励他们使用，以促进对业务利益相关者的理解和同情，从而最大限度地减少翻译层。 12 | 13 | ## 2.团队调试 14 | 15 | 随着开发人员在职业生涯中，从单个贡献者发展为领导一个团队，他们通常会从调试他们正在构建的软件，转向调试，他们领导的团队。各种阻止程序可能阻碍开发团队满足其可交付成果（例如，糟糕的任务管理、不明确的需求、复杂的开发过程等）。为了指导团队调试工作，Andela 工程部门的 Tech Lead 使用我们所谓的 “Team Vitals” 来监控团队的健康状况。 16 | 17 | 与医生如何监测一个人的白细胞计数以确定是否存在感染相似，我们已经制定了每周监测团队健康状况的指标： 18 | 19 | - 任务的周期时间 20 | - 每个贡献者接受的点数 21 | - 已接受的故事卡数量 22 | - 突出的 bug 数量 23 | - 引入的错误数量 24 | - 交付日期发生变化 25 | - 平均每日生产部署次数 26 | 27 | 我们为每个指标设定目标，并在团队回顾期间每周检查一次，以找出指标特定转变（正面或负面）的根本原因。 28 | 29 | 我们使用 PivotalTracker，这是一个功能强大的任务管理工具，提供深入的分析，可以轻松自动捕获大多数生命体征的测量值。生命体征不是一成不变的，而是按季度进行审查并相应调整。 30 | 31 | ![Weekly Vitals Example Report](images/weekly-vitals-example-report.png) 32 | 33 | ## 3. 技术债务管理 34 | 35 | 技术债务是每个开发团队（无论大小）必须处理的事情。在构建软件时，技术债务会以各种方式累积下来。有时候它会通过明确的妥协来实现：你故意选择以不可持续的方式做某事，以便更快地将产品推向市场，并告诉自己以后要清理一下。其他时候，技术债务会产生，因为建筑技术很难，人们会犯错误，你无法预测未来，这意味着有时你会制造错误的东西。 36 | 37 | 一个伟大的 Tech Lead 以有效的方式管理技术债务，以确保它不会累积到那种程度——团队正在做的唯一事情是偿还债务，而不是迭代产品。在处理技术债务时没有银弹，但这里有两种我认为合作良好的做法： 38 | 39 | > 度量技术债务 40 | 41 | 如果你不度量它，你不知道它有多大以及它的增长速度。任何时候你遇到技术债务走过代码库，创建一个任务并将其标记为 “技术债务”。 42 | 43 | > 持续偿还技术债务 44 | 45 | 我们有一个 80/20 规则。便是在给定的迭代中，花费 80％ 的时间迭代产品，20％ 的时间来修复债务。Tech lead 们需要确保在每次迭代中，优先考虑一些与债务相关的任务。 46 | 47 | ## 4. 任务管理 48 | 49 | 也许一个优秀的软件开发团队最关键的要求之一就是**一致的速度**，以及**实现其估算的能力**。若想实现这一壮举，便需要掌握任务管理方法，而不仅仅是将任务分配给团队中的开发人员。以下是 Andela 的 Tech Lead 实践中的一些任务管理行为： 50 | 51 | - 在跟踪器（tracker）中追踪一切（例如 TODO、技术债务、研究琐事、想法），即：#NoTicketNoWork 52 | - 确保所有的团队成员，都能够将任务添加到 icebox 中。 53 | - 确保 backlog 总是有足够的工作量，至少可以进行 1 到 2 个迭代 54 | - 每天更新 backlog。寻找如何将较大的任务分解为较小的任务。查找一个任务依赖于另一个任务的依赖项。 55 | - 只当任务已经被分解到尽可能低的复杂性，才开始开发（例如，我们团队中的开发人员只处理估计为 1 点的任务，Pivotal Tracker 在其复杂点系统中的最低排名） 56 | - 根据团队中开发人员感受的复杂程度细分任务，而不是作为技术主管感受的复杂程度。如果团队中缺乏经验丰富的开发人员，那么这一点尤为重要 57 | - 每当任务感觉 “陈旧” 时检查任务的状态（例如，它已启动超过一天） 58 | 59 | 实践上述行为，有助于 Tech Lead 在团队速度减慢时发展出第六感，并提高他们迅速采取行动，以使团队重回正轨的能力。 60 | 61 | ## 5.导师 62 | 63 | 最后，但同样重要的是，伟大的 Tech Lead 是伟大的导师。他们的目标是培养和指导团队中的开发人员，经常提供他们的工作反馈，并鼓励和促进最佳工程实践。他们通过委派日益复杂的问题来扩大团队的技术能力，并定期与开发人员进行编程以提供技术指导。伟大的 Tech Lead 知道，他们的成功取决于他们团队成员的成功。 64 | 65 | Tech Lead 是任何软件开发团队成功的关键角色。他们是开发人员的发声板，工程师对其他业务职能的支持，以及制定或破坏项目的关键技术决策。提供满足用户需求的出色软件解决方案，需要出色的 Tech Lead。我相信掌握上述五种做法，可以产生更多的实践。 66 | 67 | 68 | -------------------------------------------------------------------------------- /articles/five-advice-for-new-tech-leads.md: -------------------------------------------------------------------------------- 1 | # 给新 Tech Lead 的五个建议 2 | 3 | 原文链接：[Five pieces of advice for new technical leads](https://engineering.rallyhealth.com/technical-lead/leadership/new-leader/advice/new-role/tech-lead/2018/07/05/five-pieces-of-advice-for-new-technical-leads.html) 4 | 5 | 在您的上一个项目中，成功交付了一些令人惊叹的代码后，您的经理为您提供了一个新角色，一个 Tech Lead！但是，这是什么意思？如果您不编码，您可以做些什么来帮助团队？ 6 | 7 | 如果这听起来像你，首先，祝贺你！在 Rally 中，我们将 “Tech Lead” 的角色与 “团队经理” 分开，虽然他们可能经常由同一个人担任，但今天我们只关注谈论前者。在 Rally Health 任职期间，我有机会参与各种各样的项目，从团队中的唯一工程师，到令人惊叹的工程师团队的技术负责人，到几个项目的主管。每个人都有自己的能干。在这些转型中，需要最大的心理转变的转型是从开发人员（又称为 “个人贡献者”）转变为 Tech Lead。 8 | 9 | 不出所料，我经常从同事那里得到问题，询问我是否对想要制作或正在进行类似过渡的人有任何建议，并发现自己会遇到类似的主题。 10 | 11 | 如果有什么我尝试向我合作的团队宣传（如果你问他们可能有点太频繁），那就是正确的文档和知识共享是成功项目的关键。本着这种精神，我记录了我在 Rally 中与新 Tech Lead 讨论的五个共同主题，希望它能帮助其他人寻求类似的跳跃。另外，我在每个部分的底部添加了一个 “TLDR”（太长不读），专门对于那些只有 140 个字符或更少共享情感的注意力范围的人。）。 12 | 13 | ## 1. 你的工作不再是“你”了。 14 | 15 | 我不能强调这一点。通常在关于这个主题的博客文章中，您会看到类似的建议，围绕自我训练，不再使用 “我” 这样的代词，并在所有的沟通中有意识地用 “我们” 来替换它们。这是一个很好的建议，但它只是暗示你应该关注的是什么。 16 | 17 | 您现在负责一个项目和（可能）一个工程师团队。您不再单独负责编写代码，而应该努力使那些代码成为可能。您每天的主要关注点应该是弄清楚如何让您的团队免于分心、积极主动和高效。如果您为您的团队提供他们所需的方向和跑道，您就可以让他们自信地设计和交付成功的解决方案。 18 | 19 | 幸运的是，如果您正在阅读本文，您将获得一些个人贡献者/工程师的经验，并且您知道如何提供帮助！想想你直接参与的最后一个项目。是什么让你无法有效地完成工作？是什么导致你浪费时间走错了实施路径或兔子洞？你觉得这个项目失去了什么？ 20 | 21 | 回答这些问题是成为优秀 Tech Lead 的关键。注意您的团队停滞在锁定需求，上下文切换以使会议无效，或由于办公室政治，或项目模糊而变得失去动力的时候。这些都是您介入并帮助团队关注的机会。优秀的领导者应该始终在项目的边缘工作，使他们的团队更加成功。 22 | 23 | TLDR：专注于解锁和支持您的团队。在路径畅通时，赋予他们权力并信任他们去交付。 24 | 25 | ## 2. 保持积极态度并发展关系 26 | 27 | 您的团队以及公司内的其他领导者，都希望您能够确定项目的基调和进度。没有人愿意在一个每个人都生气、失败或沮丧的团队中工作，如果你的团队对其他人好斗，也不会做任何事情。保持积极和协作的态度不仅是团队生产力的关键，更重要的是不在其中。每个项目都会充满挫折和潜在的陷阱。您的态度和方法可以将这些问题从士气低落的问题，转变为团队建设挑战。 28 | 29 | 花时间与整个公司的其他团队和人员建立关系。在 Rally 中，我们喜欢在个人和他们的经理之间，以及同事和同事之间定期举行 “一对一” 会议，以帮助促进这些关系和对话。作为领导者，您始终专注于团队的目标。但是，您还应该注意这些目标如何影响公司内部的其他人，他人如何看待项目，以及其他项目或工作如何影响或使您的团队受益。 30 | 31 | 如果另一个团队听到你的团队做的一些事情，并希望在他们的团队中使用，同时建立在两个团队的利益之上，那么如果你的团队被视为不合作或好斗，他们是否可能会这样做？ 32 | 33 | 如果来自其他团队的人，建立了与您的团队正在进行的工作，而不知道或合作的类似服务或库，会发生什么？最终这两个项目将发生冲突，工作将被丢弃或重复，导致浪费时间和精力。请注意（尽管我不愿意这么说），你的团队目标与其他致力于解决类似问题的团队之间的“协同作用”。尽早合作或定义边界，将在以后节省重复和麻烦。 34 | 35 | TLDR：不仅在您的团队中，而且在其他领导和团队中培养积极的态度和协作关系。它将在未来的合作中获得回报。 36 | 37 | 38 | ## 3. 自信地讲道为什么;好奇地问 39 | 40 | 让我们谈谈领导一个新项目，以及如何尽早和经常让您的团队参与进来。 41 | 42 | 作为 Tech Lead，您有责任了解团队正在开展工作的“大局”。事先进行研究，并尝试深入研究，同时获得您知道团队将要问的一些难题的答案。现在，当团队开始工作时，解释（有信心！）目标是什么，最重要的是，为什么它重要以及它将对业务产生什么影响。 43 | 44 | 如果您的团队了解工作的重要性和工作内容，则可以让他们对工作负责，对工作感到自豪，并在实施过程中做出更相关的决策。您应该基本上将项目及其目标出售给团队。如果您对项目及其影响不感兴趣，您的团队为什么会这样做？ 45 | 46 | 一旦你给团队提供了关于原因的背景信息，现在你需要团队对 “如何” 进行调整。我发现，最好的方法是使用建议的实现，或团队可以讨论的高级流程图（我喜欢流程图）开始对话。请记住，您有依赖关系的上下文，以及是否需要涉及其他团队或服务（您事先调查过，对吧？）。为技术实施提出一个起点，或 “方向” 以获得解决方案。它不必详细或解决所有问题，但让团队中的每个人都与方向保持一致是关键。 47 | 48 | 然后，您的团队应该感到很舒服，提出不同的解决方案，或制定更详细的计划来实施。不要防守你提出的方向。目标是让团队提出一个他们可以轻松执行的计划，并为这个对话提供一个起点。随着这些讨论的继续（或解决方案到位后），请确保与团队一起验证——它如何满足您所列出的目标，并确保您了解您感到舒适的详细程度。 49 | 50 | 在此之后，您应该提出足够的问题并充分了解实施计划，以便您可以自信地与其他团队讨论（他们应该向您寻求任何依赖性问题）。相信您的团队可以提供详细信息，但要驱动它们并了解方向。 51 | 52 | TLDR：在启动项目时，将项目“出售”给团队，提出技术指导以开始讨论，并了解最终方法，以便能够轻松地向其他人解释。 53 | 54 | ## 4. 定义团队流程并推动标准 55 | 56 | 任何运作良好的工程团队的目标之一应该是，他们高效并且彼此负责。要做到这一点，作为 Tech Lead，您应该尽早帮助定义流程和团队标准，以便为团队提供有关期望的指导。 57 | 58 | 您可能会考虑尽早定义的事物类型的示例： 59 | 60 | - 团队中代码约定的标准是什么？ 61 | - 是否有可以遵循常规开发任务的标准流程？ 62 | - 如何发布、通讯和处理？ 63 | - 对单元测试、发布测试和负载测试有什么期望？ 64 | - 如何处理代码审查以及在合并代码之前，必须经过什么步骤？ 65 | - 最重要的是：所有这些都记录在某个地方吗？ 66 | 67 | 您的团队将专注于执行功能并解决代码中的问题。如果您和团队已经同意并定义了开发标准，那么它将使团队保持同样的节拍，并允许每个人彼此保持相同的期望。 68 | 69 | 例如，如果您看到团队正在讨论 REST API 路径的结构，请抓住机会提出他们同意的团队标准，并将其记录下来！现在每个人都对应该为手头的工作做些什么一致，文档可以帮助新团队成员预先确定团队的期望。（奖励：这将有助于减少未来工程师的适应时间！） 70 | 71 | 除了开发标准之外，不要害怕定义有用的过程。记录完成任务（例如，发布，产品支持或API升级）的可重复的一组步骤，将有助于事情顺利进行，并允许一致的容量规划。如果团队成员预先制定了标准或流程，他们可以更准确地确定工作所需的时间。 72 | 73 | 当然，这并不意味着永远不可能从这些标准中进行创新或推导，但是当它存在时应该是由团队讨论和商定的有意识的决定，因为这个过程正在发生变化，而不是无意中膨胀超出范围的事情。 74 | 75 | TLDR：预先定义质量和流程标准，以便团队可以相互保持责任并进行相同的节拍。详细的文档和一致性是王道。 76 | 77 | ## 尽早沟通状态，避免意外 78 | 79 | 既然您已经定义了项目，并且您的团队正在运行，那么下一步是什么？Tech Lead 最重要的角色之一就是要注意并引导团队，走向迫在眉睫的最后期限。在 Rally 中，项目的 Tech Lead 预期将与产品和项目管理方面的同行合作，以正确领导团队。预计三者将共同决定团队的下一个优先事项，确定技术计划，确定工作规模，最后汇总并传达交付时间表。 80 | 81 | 一旦启动，团队的领导者正在进行沟通并让利益相关者根据承诺的计划向项目进展情况进行更新，这一点至关重要。项目经理将成为此项目的主要联系人，但作为技术领导者，您需要与状态保持同步，并确保项目计划能够反映工作的实际情况。 82 | 83 | 在 Rally 中，我们将项目状态与表示项目相对健康的颜色进行通信。绿色表示一切按计划进行，如果项目出现意外转弯或可能偏离轨道，则为黄色，如果项目有可能无法完成其当前轨迹，则为红色。与所有指标一样，我们鼓励所有潜在客户发出消息，并记录事实，而不是人们想要听到的内容（参见：Sam Freund 的博客文章）。为项目传达黄色或红色，并不一定是坏事。 84 | 85 | 当一个项目明确没有时，向绿色发出信息是一件坏事。 86 | 87 | 如果您的项目朝远问题前进，那么必须实现它，跟踪问题并提出计划。我鼓励与我一起工作的 Tech Lead——出现问题就尽早发出消息，但总是计划如何让它重回正轨。传递红色状态以及回到绿色的具体计划，远比 “自己解决” 来说是一种更有用的沟通。它允许其他利益相关者，了解他们可以为您和您的团队提供帮助的领域。如果您以这种方式主动发送消息，那么基于您团队工作的依赖关系或业务可交付成果的人应该不会感到惊讶。即使存在问题，每个人都会意识到并应该帮助项目取得成功。 88 | 89 | 如果你发现你的团队，处在一个他们不可能成功的地方，那么尽早升起指示这个问题的标志，并定义一个计划或路径来解决它。在这种情况下，您的团队永远不应该等到截止日期前，再提出时间线或范围问题。Tech Lead 应与产品和项目管理方面的领导同行合作，使利益相关者了解进展情况，在项目偏离轨道的情况下，通过（例如）重新调整项目期望，要求更多的团队成员提高项目速度，帮助解决潜在的交付失误。或者在他们成为截止期的拦阻者之前解除阻塞。基本上，与你的同事一起跟踪你的团队的进展，并清楚地传达状态。如果项目偏离了正轨，那么就要传达这个状态以及您正在采取（或计划采取）什么行动使它回到正轨上。即使你还没有一个完整的解决方案，让利益相关者了解你的计划是什么，也会让他们尽可能地提供帮助。保持所有相关人员之间的一致性将得到回报。 90 | 91 | TLDR：一旦项目进展，请密切关注范围和进展，并在沟通中保持诚实和清晰。尽早提出问题但始终有解决问题的途径。避免给利益相关者带来意外。 92 | 93 | --- 94 | 95 | 就是这些！虽然所有这些提示，可能与每个组织或团队无关，但我发现他们应该对任何希望跳到 “Tech Lead” 的工程师具有建设性。当你承担这个新角色和责任时，请记住首要的是提出问题并获得所需的支持。单独行动可能很有吸引力，但是您的组织正在帮助您成长和学习。找一个导师或组织中的某个人，你觉得他们很自在地提出问题和 “橡皮避免” 解决方案。定期与他们安排时间。您会惊讶地发现，您所面临的问题或困难经常被其他愿意提供建议的人分享和解决。 96 | 97 | -------------------------------------------------------------------------------- /articles/good-tech-lead-bad-tech-lead.md: -------------------------------------------------------------------------------- 1 | # 好的 Tech Lead，糟糕的 Tech Lead 2 | 3 | 原文链接：[Good Tech Lead, Bad Tech Lead](https://medium.com/swlh/good-tech-lead-bad-tech-lead-948b2b806d86) 4 | 5 | Foursquare 技术领导的简要指南，灵感来自于 Ben Horowitz 的 [Good Product Manager，Bad Product Manager](http://benhorowitz.files.wordpress.com/2010/05/good-product-manager.pdf)。 6 | 7 | ## 团队合作 8 | 9 | 好的 Tech Lead（技术领导者）充当团队成员，并在团队成功时认为自己是成功的。他们分担了不合时宜的蹩脚工作和明确的障碍，因此他们的团队可以 100％ 运营。他们致力于拓宽团队的技术能力，确保关键系统的知识不会集中在一两个人的头脑中。 10 | 11 | 糟糕的 Tech Lead （技术领导者）会为自己承担高调的任务，并且能够因为工作而获得荣誉。他们在本地进行优化，使团队成员继续从事有利于团队的项目，而不必牺牲整个工程组织。 12 | 13 | ## 技术愿景 14 | 15 | 好的 Tech Lead（技术领导者）对产品的技术方向有一个全面的愿景，并确保团队了解它。他们将功能区域委派给其他团队成员，让他们自己决定。他们认识到他们的团队成员很聪明，信任他们，并依靠他们来处理项目的重要部分。 16 | 17 | 糟糕的 Tech Lead （技术领导者）拒绝解释或澄清技术方向，取而代之的是决定决策。他们将关键的机构知识保留在他们的头脑中，未能通过创建和传播有用的文档来增加其有效性。 18 | 19 | ## 讨论和辩论 20 | 21 | 好的 Tech Lead（技术领导者）倾听并鼓励辩论。 当团队无法解决辩论时，他们会描述一个有助于他们解决问题的过程或思维框架。他们不会与已成定的结论进行讨论，并且总是允许自己被伟大的想法说服。 22 | 23 | 糟糕的 Tech Lead （技术领导者）会让辩论持续太长时间而不解决，妨碍了团队的生产力。其他人过早地中断了辩论，驳回了新的讨论，称这个问题 “已经解决了”。糟糕的 Tech Lead 认为，他们赢得争论比团队做出正确决定更重要。 24 | 25 | ## 项目管理 26 | 27 | 好的 Tech Lead（技术领导者）是积极主动的。他们确保技术进入正轨。他们与团队成员合作，提出估算并建立中间里程碑。他们期待关注的领域，并确保在成为问题之前解决它们。他们确定技术障碍，并帮助团队绕过他们。他们确定了可以共享工作的重叠区域，相反，找到没有得到足够关注，并将资源用于其中的区域。 28 | 29 | 糟糕的 Tech Lead （技术领导者）是被动的。他们可以委派，但不会跟进以确保取得进展。他们没有设定中间目标，并希望最终所有事情都汇集在一起。他们等到发布之前，才进行复杂系统的端到端测试。它们允许团队成员在有趣但不重要的工作上浪费时间。 30 | 31 | ## 实用主义 32 | 33 | 好的 Tech Lead（技术领导者）是务实的，并在正确完成和完成之间找到平衡点。他们在权宜之计时偷工减料，但绝不会出于懒惰。他们鼓励他们的团队找到阻碍整体进度的问题的临时快捷方式或解决方法，并为发布构建最小的可行基础架构。对于优秀的技术主管，细节很重要。代码质量、代码审查和测试与按时交付一样重要。 34 | 35 | 糟糕的 Tech Lead （技术领导者）带来捷径，短期内可节省时间，但长期成本更高，让技术债务积累。他们无法区分需要权宜之计的情况和需要完美的情况。 36 | 37 | ## 沟通 38 | 39 | 好的 Tech Lead（技术领导者）知道他们的角色不仅仅是编写代码，有效的沟通是他们工作的重要组成部分，花费时间和精力使他们的团队更有效率。他们承认，在团队工作时需要一些沟通开销，并且他们牺牲了一些个人生产力，以提高整体团队的工作效率。 40 | 41 | 糟糕的 Tech Lead （技术领导者）相信他们在编写代码时效率最高，并且认为沟通是一种分心。它们不会优化整体团队生产力，而是针对最适合自己的因素。当他们需要花时间领导时，他们会感到沮丧。 42 | 43 | ## 与产品的关系 44 | 45 | 好的 Tech Lead（技术领导者）与产品经理和设计师，就产品应如何运作进行对话。他们并不害怕拒绝他们不同意的决定，而是牢记产品目标并知道何时容纳他们。他们通过提出技术要求较低的替代产品配方，找到了技术限制的创造性解决方案，并帮助 PM 和设计人员理解技术挑战，以便他们自己做出明智的权衡。 46 | 47 | 糟糕的 Tech Lead （技术领导者）导致产品决策 “无所谓”，并且不会取得产品的所有权。他们因技术限制而退缩，但不提供替代或解释。 48 | 49 | ## 弹性 50 | 51 | 好的 Tech Lead（技术领导者）能够适应产品规格的变化，并能够从容应对惊喜做出反应。 他们预测可能发生的变化，并设计他们的代码来处理它们。 52 | 53 | 糟糕的 Tech Lead （技术领导者），在当规范发生变化时会感到不安，或者在不太可能发生变化的领域，过早地推广他们的设计。 54 | 55 | ## 个性 56 | 57 | 好的 Tech Lead（技术领导者）是随和而自信的。糟糕的 Tech Lead （技术领导者）具有对抗性和侵略性。 好的 Tech Lead（技术领导者）自然而然地通过技术能力和经验赢得尊重。糟糕的 Tech Lead （技术领导者）认为他们的头衔被赋予尊重和权威。 好的 Tech Lead（技术领导者）总是在寻找改进的方法。 58 | 59 | 糟糕的 Tech Lead （技术领导者），在给出反馈时容易变得防守。好的 Tech Lead（技术领导者）领先是谦虚的，并增强团队中其他人的信心。 糟糕的 Tech Lead （技术领导者）是傲慢的，并乐于让他们的队友感到自卑。 60 | 61 | -------------------------------------------------------------------------------- /articles/great-culture.md: -------------------------------------------------------------------------------- 1 | ## 建设优秀工程师文化的 9 种方法 2 | 3 | 原文链接：[https://stormpath.com/blog/how-to-build-engineering-culture](https://stormpath.com/blog/how-to-build-engineering-culture) 4 | 5 | 如果你想拥有一个成功的技术创业公司，你需要的不仅仅是一个伟大的公司文化，你需要一个伟大的工程师文化。优秀的文化为您提供了巨大的优势，可以招募优秀人才，留住这些人，并巧妙地指导他们的行为来推动业务发展。 6 | 7 | 与炒作相反，文化不是乒乓球桌、垒球联赛和免费午餐。相反，文化是一群人自我指导的隐含规则，指导方针和价值观。正是同伴压力以强有力的方式塑造行为。简单地将一堆核心价值放在墙上的某个地方是不够的。文化是一种需要持续照顾和喂养的生物。 8 | 9 | 虽然根据团队的战略，每种文化都应该有所不同，但对于工程而言，最好的团队中有一些共同的元素。 10 | 11 | 12 | ## 1.鼓励公开辩论 13 | 14 | “对我来说很重要的是，我鼓励去发表意见，并且我正在倾听” ——Jose@Stormpath 15 | 16 | 科技创业公司很难。大多数时候，你正在构建一些没有人建立或开创新方法或新市场的东西。路径永远不会清晰，没有人能够得到所有答案。然而，您的工程团队是一群非常聪明的人，他们致力于加入公司并坚持过山车的愿景。 17 | 18 | 它们的价值超出了调用代码的能力；他们可以为技术设计、流程、架构、功能等做出巨大贡献。在某些情况下，他们甚至可能对销售和营销有很好的想法。通过鼓励人们说出来，你不仅可以从他们的洞察力中获益，而且还可以让他们感受到有影响力和有价值的感受。那很厉害。它推动了更好的技术决策。它有助于识别隐藏的风险。它有助于知识共享。它推动了忠诚度。 19 | 20 | 但是，并非团队中的每个人都会在激烈的辩论中自然而然地说话，或者自己与高级经理发生矛盾。你的团队领导有责任为更多的人保留 “空间”。注意表明他们对某个主题有意见的肢体语言。或者可以暂停辩论，并询问那些没有声音的人，他们是否有任何需要补充的内容。也许，您要求在会议之前或之后提供意见，以便每个人都有时间停下来，并将他们的想法汇总到一封电子邮件中。尝试一下，因为一个有效的辩论文化包括每个人，而不仅仅是大声的外向者。 21 | 22 | ## 2.建立对管理决策的承诺 23 | 24 | “一旦做出决定，我们就会一起搬家。不回头。” —— Mario@Stormpath 25 | 26 | 辩论文化有一个单一的目的 —— 做出更好的决定。然而，通过共识做出正确的决定非常困难。拥有强大工程文化的强大团队，对此持有一点点独裁。一个人在辩论后获得最终决定权。首席执行官、首席技术官、架构师、经理、大师，无论如何 —— 团队中的这位领导者，不仅需要信心和技巧来打开和管理真正的辩论，而且他们还需要权威和信心来在正确的点上停止辩论，并做出坚定的决定。即使这是一个不受欢迎的决定。在做出任何决定之后，更难的仍然是对所做出的决定的承诺感，因为对于一个团队来说，没有比在决定之后 “我告诉过你” 更糟糕的事情。 27 | 28 | 实现这种承诺水平很难。它首先源于对领导层的信任。为了建立这种信任，请确保您正在倾听，并明确了解所提供的所有信息和意见。一个简单的测试是你是否可以令人信服地重播争论。在做出决定之后，不要只宣布决定，解释你为何采取这条道路。你可能是对的，你可能错了，但如果团队能理解 “为什么”，那么他们就可以做出承诺。 29 | 30 | ## 3.谦卑 31 | 32 | “这里的每个人都非常好。团队氛围很好，人们对新想法持开放态度” —— Jeff@Stormpath 33 | 34 | 为了使公开辩论真正在团队中发挥作用，你需要谦虚的人。谦虚的人更专注于找到正确的答案，而不是赢得争论。谦虚的人有想法和意见，但知道他们并不总是正确的。谦虚的人为他人腾出空间，不同意他们，仍然恭敬地参与其中。只要他们觉得他们的声音被听到，谦卑的人就会承诺反对他们的意见。谦虚的人很容易教。谦虚的人很容易合作 - 他们是包容性的，分享信用，并倾向于接受新的想法。 35 | 36 | 雇佣谦卑更多的是艺术形式而非科学。留意他们如何谈论他们以前的团队，他们如何描述自己的优势和劣势，以及他们在面试过程中如何对待您和您的团队。他们分享信用吗？怪？他们在谈话中为其他人腾出空间吗？他们如何回应一个愚蠢的问题？被反驳？ 37 | 38 | ## 4.聘请聪明的人完成任务 39 | 40 | “我们不是在这里鬼混。这是一支由专业人士组成的团队” —— Tom@Stormpath 41 | 42 | 如果你是一家科技创业公司，你不仅仅是在预算上，而且你的时间非常有限。所以，你需要那些值得每一分钱，并且会快速行动的人 —— 聪明的人完成任务。引用乔尔·斯波尔斯基的话说，“聪明但不做事的人经常拥有博士学位，并且在没有人听他们的大公司工作，因为他们完全不切实际。” 而 “那些把事情做好但不聪明的人会愚蠢的事情，似乎没有考虑过它们，其他人将不得不在以后清理他们的烂摊子。这使他们成为公司的净负债，因为他们不仅没有做出贡献，而且还吸收了好人的时间。” 43 | 44 | 如果你认为招聘谦卑很难，那就更难了。您的工具包括面试问题、编程测试和参考检查。 45 | 46 | 正确的面试问题是评估智慧的好方法。用正确或错误的答案避开问题。即使是最聪明的候选人，也可能在面试的热度中忘记一些模糊的定理。相反，提出问题将揭示人们如何处理复杂问题而没有明确答案。您可以采取务实的技术方法（如我们），“您将如何构建照片共享应用程序” 或更加奇特的方法（如微软） “中国有多少茶？” 请他们大声思考。他们可以围绕这个问题包围吗？找一个接近的角度？问你正确的问题？他们的解决方案是否切实可行？他们的答案是否清晰且内部一致？ 47 | 48 | 要确定他们是否可以完成任务，请给他们一个带回家的编程练习。一个有点挑战性的，有十几个要求，并模仿你的一般环境。他们能够完成吗？他们满足了所有要求吗？他们认真对待了吗？这些都很容易检查。更重要的是，他们是如何组织他们的项目的？他们是否记录并测试了他们的代码？你能按照他们的做法去做吗？他们是否采用了适当的设计模式？设计有什么好处吗？ 49 | 50 | ## 5.推动客户同理心进入团队 51 | 52 | “我知道谁将使用我们的产品，以及他们试图通过它实现的目标。知道有人会使用我的代码，我感到压力让它变得很棒。” —— Robert@Stormpath 53 | 54 | 如果您的工程师了解您的客户以及他们想要实现的目标，他们就会成为一个产品开发人员团队。当用户体验（UX）成为一个更深层次的辩论而不仅仅是按钮颜色时，它变成了文化，并通过更少的会议和管理带来更好的产品开发。 55 | 56 | 那你怎么去那里？这是一笔很大的投资，而且这种方法取决于您的业务。在 Stormpath，我们让工程师进行支持轮班，以便他们与客户进行一对一的互动，了解人们如何使用产品，他们正在尝试做什么，以及他们遇到问题的地方。我们鼓励他们作为最终用户连接到 API。它耗费了他们的开发时间，但这是我们认为自己付出的投资。什么对你有意义？ 57 | 58 | 59 | ## 6.鼓励探索新技术 60 | 61 | “只有十六种颜色才能看世界的艺术家，才能创造十六种颜色的艺术” —— Les@Stormpath 62 | 63 | 工程师解决问题。要做到这一点，最优秀的工程师总是在寻找新的技能和技术来添加到他们的工具箱中，拥抱它并促进它。通过让新的技术和方法进入您的组织，您不仅可以激发新的挑战，还可以强迫他们以新的方式思考。考虑 NoSQL，这是一种完全不同且强大的数据结构思维方式。您的特定项目可能不会最终使用它，但只需接触它，您的团队的技能就会增长，并可能为您的下一个问题提出一种新颖的解决方案。 64 | 65 | 在鼓励探索和为新技术采用新技术之间存在一条界线 - 这可能会导致很多问题。保持在该方面的右侧的方法是鼓励您的团队在他们认为可以对您的工作产生有意义的影响时将新技术带到谈判桌上。让会员在午餐时分享新技术并学习。如果它看起来有潜在的价值，那么就让时间让团队弄脏并测试技术 - 也许是通过尖峰，概念证明，甚至内部黑客马拉松。 66 | 67 | ## 7.改善！推动持续流程改进 68 | 69 | “我喜欢在我们需要时随时改进技术，工艺和技术的自由” —— Elder@Stormpath 70 | 71 | 有一个过程，任何过程。让它变得强大和清晰。重或轻，重复它，以适应您的战略和您的团队。它将确保您的团队明确指示如何做以及如何做。这只是良好的工程管理，但要建立一个伟大的工程文化，这个过程应该由工程团队本身而不是管理团队拥有和管理。 72 | 73 | 工程师是日复一日地处理这个过程的人。他们知道，比任何人都更好，它在哪里工作，哪里不工作。如果您的文化已经促进了公开辩论并且有明确的目标，那么这种所有权可以创造奇迹。 74 | 75 | 每两周左右，每个人都会遇到关于如何改进流程的想法。不知道是个坏主意。无论多么疯狂，都要试一下两周并重新评估。您的流程将会起伏不定，但始终与您公司最重要的事情保持一致。这种管理方式最终成为丰田制造业的支柱，并且在 Stormpath 也为我们提供了良好的服务。如果您想了解更多信息，可以查看我们关于 [Agile Kanban 流程的帖子](https://stormpath.com/blog/so-long-scrum-hello-kanban)。 76 | 77 | ## 8.尊重他们的时间 78 | 79 | “我觉得你尊重我作为专业人士的时间” —— Pablo@Stormpath 80 | 81 | 人们希望受到尊重。如果你给予他们尊重，你将获得尊重，以及办公室中的忠诚度和低摩擦力。尊重您的工程师很容易：尊重他们的专业知识，更重要的是尊重他们的时间。 82 | 83 | 您可以通过两种方式快速制度化尊重。从这两个开始，你会看到尊重迅速蔓延。 84 | 85 | 强制您的每日站立会议每次都准时开始。预定上午 10 点？从上午 10 点开始，不是一分钟后，无论谁迟到，都表示尊重准时出现的其他人。即使经理或总建筑师迟到，也要迫使他们按时开始，明确表示没有人可以免税。 86 | 87 | 在下一个大工程截止日期，每个人都需要工作疯狂的时间，问他们，不要告诉他们，要迟到并解释为什么这对公司很重要。对您需要的内容设定一个清晰而现实的期望，以便他们可以在推动期间规划他们的个人生活。确保它们尽可能舒适。一旦完成，尽你所能，尽量减少这些推动的频率，这样你就不会失去信任。 88 | 89 | ## 9.提供和接收定期反馈 90 | 91 | “反馈，冠军的早餐” - Alex @ Stormpath 92 | 93 | 最好的工程师，希望通过提高他们的技能和他们努力的领域来发展。要做到这一点，他们需要明确，诚实和建设性的反馈。您提供反馈的频率越高，他们将拥有的数据点越多，他们可以更快地进行更改。反过来，收集他们的反馈，以便您可以提高自己，管理技能和公司。通过建立强大的双向反馈渠道，您将获得更好，更强大的工程师以及他们的信任和忠诚度。 94 | 95 | 建立定期反馈需要时间和纪律。一个季度对我们来说效果很好 - 通常足够可行，但不重复。对于每位工程师，至少花费一小时的准备时间，来思考您认为有价值且可操作的反馈。并要求他们花费尽可能多的时间准备给你反馈，并反思他们自己的表现。然后安排一小时的会议给予和接收。对于那些从未做过这种时间的团队而言，证明这种时间投资是合理的，特别是当所有工程师在短期限内感到资源不足时。但这是一项投资，为您和您的团队带来巨额长期支出。准备是关键，如果这对你来说是新的（如果不是！）。 96 | 97 | ## 结论 98 | 99 | 这九个步骤是建立伟大工程文化的有力方式，但它们只是基线。要建立一个真正卓越的文化，评估您的组织的核心战略，并找到使您的文化与该战略保持一致的方式，使您的工程团队真实可行。如果您投入时间和精力，您的文化将会开花，最终帮助您吸引，留住并指导管理最佳人才。 100 | 101 | -------------------------------------------------------------------------------- /articles/howto-build-thrived-culture.md: -------------------------------------------------------------------------------- 1 | # 如何建立一个每个人都能茁壮成长的软件工程文化 2 | 3 | 原文链接：[How to Build a Software Engineering Culture Where Everyone Can Thrive](https://medium.com/@ann_lewis/how-to-build-a-software-engineering-culture-where-everyone-can-thrive-e927bc52ea97) 4 | 5 | 媒体喜欢在技术世界中讲述有关性别歧视，种族主义和其他形式偏见的战争故事。虽然对系统性问题有所了解，但对于那些对科技事业感兴趣的人来说，阅读有关科技文化问题的故事，最好像熟悉的刻板印象威胁一样，最糟糕的是像一个威胁性的职业责任。但好消息是，科技行业文化本质上并不是坏事 - 其中一些是伟大的，创造一个人人都可以茁壮成长的软件工程文化既可行又直接。 6 | 7 | 糟糕的软件工程文化效率低下 - 除了推出 75％ 无法适应技术创新的人类，从而使人工行业竞争力下降 - 恶劣的软件工程文化，也常常是一种只有少数主导工程师的文化实际上是著有成效的，而其他人感到困惑或最小化，以及大型团队可能花费数年和数百万美元，意外地解决错误问题或构建错误产品的文化。敌对工作场所更明显的问题，很容易衡量不良组织文化和组织效率低下的共病问题的证据。 8 | 9 | 幸运的是，职场文化具有很强的可塑性，您可以通过大大小小的方式对其进行影响。如果您在工作场所找到改善软件工程文化的方法，那么您可能不仅仅是为自己改善环境，而是为每个人改进环境。结果，每个人不仅会更快乐，而且会更富有成效。 10 | 11 | MoveOn 的技术按规模组织。我们所做的工作很重要，我们如何开展这项工作同样重要。我的技术团队不仅建立了动员数百万美国人的工具，增强了人们的权力，并使我们的政府负起责任，但我们正在通过公平的招聘流程招聘团队这样做，我们不断审计和改进我们的软件工程实践和流程，以确保团队中的每个人都有发言权，每个人都有成功的基础。这是一项绝对值得的艰苦工作，当我们的团队流程正确时，我们将获得丰厚的回报，因为我们能够在合适的时间高效灵活地构建正确的技术，扩展我们的系统和流程，并与其他该组织作为技术思想伙伴。我们拒绝接受当前的技术刻板印象和文化期望是不可避免的想法，因此我们是一个更好的团队。 12 | 13 | 那么你如何建立一个良好的软件工程文化呢？ 14 | 15 | ## 优秀文化的关键成分 16 | 17 | 公平有效的软件团队文化考虑到团队的组成，操作流程并使规范明确，使所有团队成员都能获得成功，并使团队对其既定目标负责。 18 | 19 | 以下是实现此目标的五个关键值： 20 | 21 | - 承认团队的多样化经验 22 | - 明确说明沟通和协作规范 23 | - 为学习和提问提供安全的空间 24 | - 明确将所有团队成员加入新项目 25 | - 建立问责文化 26 | 27 | 实现这些价值观的任何流程组合，都可能适用于您的团队，但并非所有策略都适合每个团队，每个项目和每个组织环境，因此，尝试不同的策略并定期与您的团队进行汇报非常重要。什么工作，不工作。让团队成员协商流程变更，并保持灵活性。 28 | 29 | 接下来我们将分解每个值的真正含义，并且我将分享我用于实现每个值的策略示例。 30 | 31 | ## 承认团队的多样化经验 32 | 33 | 大多数软件工程环境将包括具有不同经验水平的人员，并且经验将在许多方面变化：编码所花费的实际时间，特定语言或框架的多年经验，特定公司规模，类型和行业的经验。每种语言，框架，平台，行业都有一系列期望，关于项目的操作顺序应该是什么，哪些问题应该容易与难，哪些架构模式被认为是标准的，哪些规范存在于文档，调试，和部署。这里的每一个区别都很重要，在设定沟通和协作规范时应予以考虑。解开每个团队成员的经验和假设将使决策更加清晰，并将平滑潜在的误解。 34 | 35 | **承认团队多样化经验的策略：** 36 | 37 | - **团队撤退（Retreats）**：当你的团队的构成发生变化时，为每个人开辟一两天，让每个人相互见面，分享经验和重置规范是有帮助的 38 | - **团队宪法（Constitution）**：将您批准的一系列价值观和规范制定为团队的章程。保持语言直接，保持清单简短，并专注于价值与特定项目是有帮助的。提示每个团队成员根据他们的经验分享有关每个价值为何重要的故事。 39 | - **促进分享经验的机会**：您可以将此作为团队撤退或定期团队建设会议的一部分。提示与促进无关紧要。促进是关键，所以每个人（内向和外向，包括初级和高级工程师）都有机会发言和倾听。一些示例提示我发现它是生成性的：“你曾经参与的最艰难的项目是什么？”“你曾经拥有过的最好和最差的管理经验是什么？”主持人应该呼吁所有人会面并给予他们相同的会议记录数，并回答有关他们经历的问题。 40 | - **解包软件估算推理**：您的团队将不约而同地讨论任务需要多长时间，并且有时会不同意。当发生这种情况时，明确解开关于任务或问题的哪些部分被认为是复杂的，为什么以及基于此的过去经验的假设是有帮助的。 41 | - **软件工程学习计划**：为希望以支持和结构化的方式扩展其软件工程技能的软件工程师创建学习计划。 42 | 43 | ## 明确说明沟通和协作规范 44 | 45 | 写下并正式同意团队成员如何在项目上合作，如何管理任务，以及如何批准和合并完成的工作。如果您没有明确地声明这些规范，您的团队和项目无论如何都会制定规范，但是这些隐式规范可能对某些工程师而不是其他工程师有效，并且这些规范可能对那些认为您组织的主导文化的人更清晰和易用，而对那些不这样做的人更容易混淆。最好是明确。 46 | 47 | **制定沟通和协作规范的策略**： 48 | 49 | - **项目启动会议**：团队章程帮助团队决定如何在一般情况下一起工作，但是在团队决定如何在这个特定项目上合作的情况下召开项目启动会议也很有帮助。这应该包括如何管理任务、如何安排任务、谁挑选哪些类型的任务、如何和何时请求帮助、何时一起工作、如何批准变更和完成的工作。 50 | - **每日站会**：这是大多数敏捷软件管理策略的基本原则。提示每个团队成员报告他们昨天做了什么，今天要做什么，以及他们是否需要任何帮助。尽量缩短会议时间，如有可能，不超过 15 分钟。当面或在视频会议（与电话）中这样做很重要，这样团队成员就可以了解视觉反馈和相关的社会动态，这些都是团队成员中的一部分，彼此都要对团队目标负责。我发现，每天都有一个站立议程文档是非常宝贵的，在这个文档中，每个人在每天的会议之前都按照相反的时间顺序编写更新，这个文档会随着时间的推移累积所有更新。这有助于内向者在实际会议之前收集他们的想法，并创建一个可扫描的已完成工作的书面记录，在准备逃避或赶上错过会议的团队成员时，这些记录非常有用。 51 | - **定期检查流程的机会**：有时工程师会被落在后面，或者对其他工程师、流程或项目的进展感到沮丧。最好直接用包括整个团队在内的清晰沟通来避免这些挫折，并为分享反馈创造低压力的机会。有时，我发现将“过程检查”包括到每个团队成员在每日站立会议上报告的项目列表中是很有帮助的。其他时候，我发现每隔几周在 Sprint 计划会议中执行这个 “过程检查” 步骤很有帮助。每当 “过程检查” 发生时，不仅要谈一下，而且要写下提议的过程更改是很有帮助的，因此如果将来出现混乱，就有一个共享的协议可以参考。 52 | - **适用于15分钟以上会议的 POPs**：当团队需要做出重大决策或在混乱的情况下导航时，会议很容易陷入死亡陷阱。避免过度会议的一种方法是允许任何人提议一次团队会议，但要确保会议有一个弹出窗口：目的、结果、进程以及在提议会议前至少一天制定的议程。这有助于保持会议的重点和可操作性，提前共享议程可以让有兴趣参加会议的人，以及不想退出会议的人参加会议。 53 | 54 | 55 | 56 | ## 为学习和提问提供安全的空间。 57 | 58 | 在做出正确的事情之前，每个人都会犯错误并错误地学习一千次。你可以称之为“修修补补。”编码的美妙之处在于，你可能会出错，然后最终以你能想到的速度，很少或没有实际成本。但是当你探索一个新的问题空间时，不同的人（基于经验和个人偏好）可能会更广泛或更深入地搜索可能解决方案的树，并且可能已经开发了心理模型，使他们拥有比其他特定问题空间。当工程师感到舒适地分享他们的问题解决过程和步骤时，他们开始变得更聪明，更快捷。这自然会让很多人感到愚蠢并且提出“愚蠢的问题”（其中没有一个实际上是愚蠢的），因此能够做到这一点需要大量的信任。在高风险的工作中很难获得信任，因为自负或声誉受到威胁，每个人都试图辜负某种“天才工程师”的原型。管理者应该通过宣称没有愚蠢的问题，来明确地创建安全空间，通过询问“哑”问题来建模，为协作制定结构化空间，并奖励那些主动协作的人。如果你没有明确地这样做，你团队中的一些工程师可能会创建这些安全空间，但并不是每个人都会被自动包含在内。 59 | 60 | 61 | ### 创造安全空间的策略： 62 | 63 | - **常规 1-1 见面**：经理应该定期与员工1-1，最好每周半小时。经理应该鼓励员工推动这些会议的议程。维护此会议的共享 1-1 议程文档很有帮助，员工可以在问题出现时提前添加项目。在撰写论文或反思过去的挑战和机遇时，这个议程文件也可以作为一个有用的文章。 64 | - **定期 2x2 反馈**：经理和工作人员分别写下并分享工作人员做得好的两件事，工作人员可以做得更好的两件事，经理做得好的两件事，以及两件可能更好的事情。这可以成为员工绩效的有用登记点，也是员工为经理提供反馈的安全空间。无论你作为一名经理多么友好或平易近人，大多数工作人员都会毫不犹豫地给你负面的反馈，除非你邀请他们。 65 | - **打开术语**：当工程师抛出一个不为团队其他成员共享的不熟悉的术语或首字母缩略词时，将行话标记的行为规范化，并提示他们解释该术语对整个团队的意义。 66 | - **计划结对编程**：结对编程是一个很好的生产力助推器，也是工程师相互学习的好方法。而不是等待结对编程在已经相互熟悉的工程师之间有机地发生，促使团队成员在他们的日历上明确地计划这一点，并确保所有工程师都能够访问他们想要的配对时间。同时促使工程师为他们协商正确的焦点时间单位（有些时间为 60 分钟，其他时间为 90 分钟，其他时间为 120 分钟），以及配对时最有效的时间。 67 | - **明确的辅导机会**：让团队中的每位初级工程师都有机会聘请高级工程师，并明确包括有效指导高级工程师的绩效目标。鼓励导师与他们的学员建立每周会议，并为高级盟友提出安全的空间，以便提出“愚蠢”的问题或澄清流程或规范。 68 | - **练习定期回复**：当一名工程师教他人一个新的框架，让所有人通过建议的架构，或者让团队成员加入新系统时，有时候听众很容易关闭或分心。为了使讨论保持活跃，在每5分钟的谈话之后，定期提示听众口头重复刚刚解释的内容。口头重复的表演性质迫使听众向自己证明他们理解概念，或者阐明他们需要理解的其他信息。在入职或进行项目启动会议时将其标准化，并随机呼叫人员进行重复回复以让每个人都关注。 69 | - **鼓励和模仿提出“愚蠢”的问题**：作为管理者，人们会仔细观察你的行为和语气，并根据这一点模拟他们的行为和社会规范。因此，重要的是要根据您与团队其他成员的互动方式对上述值进行建模，尤其要模拟在您不完全理解某些内容时，提出直接问题的能力。这表明有效解决问题，总是比自我更重要或总是正确的感知。 70 | 71 | ## 明确将所有团队成员加入新项目 72 | 73 | 开始一个新项目时，重要的是不仅要解开将要完成的工作，还要解释为什么这项工作很重要，以及这项工作对谁来说非常重要。确保工程团队了解“为什么”以及“什么”可以在出现意外选择点时指导决策，并最大限度地降低花时间解决错误问题的风险。在开始一个新项目之后，重要的是要确保每个人都拥有他们需要的东西来完成任务并立即提高工作效率。如果您没有明确地这样做，您团队中的一些工程师将会开始运行，而其他工程师则会在设置本地开发环境等自举步骤时遇到困难。将这些步骤作为启动项目的先决条件可确保每个人都能够立即投入使用。 74 | 75 | ### 明确入职的策略: 76 | 77 | - **开发环境**：在调用项目准备启动之前，确保团队中的每个人都有一个功能开发环境。年轻和年老的工程师都不时地努力使本地开发环境正常运行，这成为软件项目时间表中隐藏的成本。当发生这种情况时，工程师会感到尴尬，并且经常避免承认他们需要帮助，通过保持编码外围的角色，或者只与具有工作开发环境的工程师进行结对编程。最好只是消除潜在的挣扎和耻辱，并将其称之为工作，然后通过明确和支持开发环境设置来计划前端加载这项工作 - 每个人都在一起做的事情，没有被标记为“完成“直到项目中的每个人都有一个有效的当地环境。 78 | - **代码库的导览**：在启动或重新启动项目时，最了解代码库的工程师应该对代码库进行导览，暂停不熟悉的团队成员定期“重复”，在成员之间轮换以便每个人都在负责学习代码库结构，以便能够解释它。 79 | - **调试器**：一旦每个人都有一个开发环境和对系统如何工作的概念性理解，每个人都应该安装一个调试器，并能够通过系统跟踪执行以获取样本请求或输入。能够在本地工作和调试将确保当工程师开始接收任务时，他们至少能够自己开始这些任务。这减少了挫败感，提高了生产力和所有权。 80 | 81 | ## 建立问责文化 82 | 83 | 软件工程管理的关键工作是确保您的团队在正确的时间以正确的顺序完成正确的工作，并且关注正确工作的关键部分是以正确的方式与利益相关者建立联系。软件团队有几个利益相关者：彼此，更大的组织，以及他们正在构建的软件的用户。软件团队管理流程应该与所有这些利益相关者建立责任。 84 | 85 | ### 建立问责文化的策略: 86 | 87 | - **项目汇报会议**：项目完成并启动后，为举行汇报会议留出空间非常重要，并为此提供便利，以便团队中的每个人都有机会分享他们的反馈意见。我使用的一个有用的提示是 “SaMoLo：下次你会做什么/更多更少？”鼓励团队成员分享技术和流程领域的反馈。这可以让团队成员互相追究是否遵循了作为项目启动会议一部分进行协商的流程。 88 | - **软件过程责任**：在项目启动会议中确定的代码审查和发布流程，也在团队内部建立问责制，每日立场会议也是如此。 89 | - **定期演示会议**：定期演示项目进度，为大型组织创建问责制。我们希望为所有感兴趣的员工提供每周演示的空间。这是团队的动力，因为他们可以展示他们的工作，它创建了一个用于捕获早期利益相关者反馈的论坛，并在可能的情况下将项目工作集中在迭代可演示的可交付成果上。 90 | - **以用户为中心的指标**：通过进行用户测试，根据用户参与度定义和跟踪成功指标，为您的软件用户创建问责制。 91 | 92 | ## 为什么这很重要 93 | 94 | 尽管利润丰厚，软件工程界目前效率相当低。90%的软件初创公司都失败了，我认为这在很大程度上是由于可避免的软件项目执行问题。50% 的大公司软件项目未能按时、按预算或完全启动。对于任何曾在大型软件公司工作过的人来说，迟到一年或超出预算一百万美元都不是新闻。软件工程文化通常将管理者标记为开销或低于软件工程师的地位，这会导致软件工程师成为有效的管理者，以避免这种晋升路径，而当前的软件经理难以与自己的团队进行谈判并在其团队中统治。有时，即使是公开关心软件工程过程，在牛仔编码员受人钦佩的环境中，也会受到侮辱。 95 | 96 | 在一个大型软件项目上工作只看到最后期限被推迟或项目被取消，这让人士气低落。在营利的世界里，这是一种低效的时间和金钱浪费。在非营利的世界里，我认为这是不道德的使用会员捐款。对于软件工程师来说，这是浪费我们宝贵的时间、精力和注意力。 97 | 98 | 出于智力和经济方面的原因，审计工作环境的文化并寻找优化和改进的方法是很重要的。如果你从使你的工作文化更公平、更负责任、更公平开始，在一个人人都能成功的地方开始，你不仅会使软件工程师更快乐，软件工程更高效，你还会通过降低软件开发成本和消除歧视性障碍，使世界更公平。 99 | 100 | 建立一个人人都能兴旺发达的软件工程文化并不难，但现在在充满傲慢、贪婪、自我和道德困惑的技术文化中，这是一个激进的想法。我认为有意建立一个有效和支持性的团队文化是一种行动主义。让我们让公平有效的软件团队文化成为规范！ 101 | 102 | -------------------------------------------------------------------------------- /articles/images/kanban.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/articles/images/kanban.png -------------------------------------------------------------------------------- /articles/images/ptop.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/articles/images/ptop.png -------------------------------------------------------------------------------- /articles/images/qa_gates.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/articles/images/qa_gates.jpg -------------------------------------------------------------------------------- /articles/images/ttl-core.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/articles/images/ttl-core.png -------------------------------------------------------------------------------- /articles/images/weekly-vitals-example-report.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/articles/images/weekly-vitals-example-report.png -------------------------------------------------------------------------------- /articles/keep-culture-while-scaling.md: -------------------------------------------------------------------------------- 1 | # 如何在高速发展的同时，保持工程师文化 2 | 3 | 原文链接：[How to keep your engineering culture while scaling your business](https://m.oursky.com/how-to-keep-your-engineering-culture-while-scaling-your-business-481820333392) 4 | 5 | 一个成功的科技创业公司始于强大的公司文化。如果有一群人你特别想保持激励，那就是建立你的产品的人。 6 | 7 | 强大的工程师文化不是创业界的乒乓球桌、免费午餐和休闲星期五的形象。建立产品的好处并不在于流程。对我们而言，工程师文化意味着积极的团队成员始终如一地创建和维护高质量。 8 | 9 | 强大的工程文化需要建立一定的系统，使开发人员对他们交出的代码负责，同时利用团队成员的独特技能和个性。有哪些框架可以开始？以下是我们的一些方法。 10 | 11 | 12 | ## 大小很重要，只是不符合你的想法。 13 | 14 | 作为一家拥有40多名开发人员和设计人员处理多个客户项目的公司，我们拥有自主团队，其中包括项目经理（PM），技术主管，拥有 1-3 人的开发团队以及指定设计师来跟踪项目。使用基线标准的开发人员，您应该能够计算客户想要构建的产品所需的天数 - 如果他们想要更快，那么您可以让更多人使用它。在较小的范围内，允许我们的开发人员对他们正在构建的内容拥有所有权，而不是来回处理（即使使用 Github）。 Pull Request 由技术主管合并，因此其他人将始终检查代码。合并完成后，我们的项目经理将测试并批准该功能。 15 |   16 | 当我们说大小时，我们指的是制作出色产品的最低可行团队成员。 17 |   18 | 小团队结构有助于改善： 19 | 20 | - **重点**：小型团队有一个固定的目标和截止日期，高级团队成员可以花更多的时间来支持每个人 21 | - **凝聚力**：拥有 3-5 人团队，每个人都可以随时了解所有工作部分 22 | - **互动**：小型团队可以更好地协调面对面会议，并分享临时信息 23 | - **可见性**：小型团队可以更轻松地捕捉路障，冲突和潜在问题 24 | - **管理**：小型团队允许一个人成为联络点，减少文档、文书工作和官僚作风 25 | - **清晰度**：团队能够跟踪所有成功、期望、失败和状态变化（即通过每日站立） 26 | 27 | ## 无论谁想到它，一个好主意都是个好主意。 28 | 29 | 正如 Intuit 的联合创始人 Scott Cook 所解释的那样，“传统管理优先考虑项目，并将人员分配给他们。但是，越来越多的人认为，管理者并不是这个想法的源泉。“ 30 |   31 | 在辩论想法和解决方案时，资历应该无关紧要。开发中的许多任务非常简单，但您如何决定使用一个框架而不是另一个框架呢？我们应该使用更新的库来更好地满足项目要求还是更好的文档库？虽然技术负责人经常根据经验提出这些问题的解决方案，但应该积极鼓励整个团队做出贡献。 32 |   33 | 我们的项目经理将在当天浏览每个开发人员的项目，开发人员会概述他们将要做的事情。团队的其他成员可以提供其他想法或资源，例如有用的库。这种基于任务的报告使每个人都有机会每天做出贡献，无论他们是新的初级开发人员还是技术主管。结论并记录在 Waffle.io 上，它跟踪 GitHub 上的问题。 34 | 35 | ## 不要找借口不分享。 36 | 37 | 公开辩论对于汇集想法至关重要，无论它们是否会变得激烈。 38 |   39 | 在 Oursky，错误传达通常是一种破坏的来源，而不是争论性的行为。这种做法的形式是人们没有说出由于感知到的资历，人们没有要求澄清，和、或开发人员没有在他们知道没有意义的请求上挑战 PM。 40 |   41 | 透明度有助于在上述情况下做出贡献。每日站立会议中的面对面交流减少了个人冲突的可能性。明确记录 GitHub 上的辩论，问题和解决方案可以帮助团队成员专注于问题，而不是人。当整个团队都可以贡献并获取信息时，每个人都有更好的机会被听到，从而得出结论。该文档对于分布式团队尤为重要，因此远程同事可以了解全局。 42 |   43 | 通过满足您的团队成员的独特需求，并为他们提供多种渠道，在公共渠道中表达他们的贡献，您可以显着降低个人冲突的可能性。而不是人们需要彼此相处，你创造了一种热衷于向同龄人学习的人的文化。 44 | 45 | ## 告别代码所有权。 46 | 47 | 虽然代码所有权肯定有它的特权（控制和信用到期），但成功的小团队文化并不适合它。放弃代码所有权可以让开发人员考虑可读性和长期可维护性。以下是 Oursky 的典型开发流程，以确保代码质量： 48 | 49 | - 1）PM 分配任务，开发人员总结他们在站立会议上会做些什么。 50 | - 2）开发人员在 2 天内完成任务（更长的任务进一步细分）。 51 | - 3）开发人员在需要时咨询团队成员（特别是 Tech Lead）。 52 | - 4）开发人员在问题结束时发送拉取请求。 53 | - 5）技术主管检查并合并拉取请求。 54 | - 6）PM 检查功能是否实际有效，然后更新客户端。 55 | 56 | 作为一个团队的思考鼓励开发人员在他们去的时候互相咨询，即使他们认为这会产生长期影响的细节也是如此。我们的一位开发人员询问 “设置” 或 “设置” 是否应该是正确的术语，并决定重构他的代码，因为他希望确保其他人在将来能够理解。开发人员从 6 个月前完全忘记了她 /他的代码的逻辑和上下文，这是很常见的，因此，作为一个团队的思考，可以执行命名等最佳实践。 57 | 58 | ## 优化迭代速度。 59 | 60 | 快速迭代有两种形式。第一个是官僚主义，或者在整个公司内部执行快速有效的流程，第二个是实际的产品开发。缓慢的官僚程序，例如让每个级别的管理层批准新的代码或功能都是一个瓶颈，可能会严重降低启动速度。它还使远离产品的人（即高级管理人员）掌握决策权，这意味着如果存在分歧，需要召开更多会议以加快速度。 61 |   62 | 此外，具有长周期和大修的产品，意味着工程师无法看到他们的进展结果（即用户正在使用他们的产品）。如果项目落后，两者都是时间投资风险和心理消耗。 63 |   64 | 我们建议使用与 GitHub 集成的 Waffle 来帮助团队每天查看需要解决的问题。PM 负责帮助团队确定优先级并委派（包括外包）任务，以便开发团队保持专注。PM 接收新的功能请求，并通过以下过程完成： 65 | 66 | 流程： 67 | 68 | - 1-2 周 Sprint：由客户端引入的一系列功能和/或错误定义 69 | - 如果是请求的功能，请确保有足够的详细信息可供使用。如果没有，请首先引入设计团队以提供其他 UX 和 UI 支持。 70 | - 如果是肤浅的功能，比如复制内容，则委托给作家。 71 | - 如果问题是 bug，请在将其分配给开发人员进行修复之前，确保它是可重现的。 72 | - 如果问题变得太大，请将其分解为不到 2 天。 73 | 74 | 虽然我们是一家数字产品代理商，但是这个流程的准系统可以被提升并放置在任何工程环境中。 快乐的建筑！ 75 | 76 | -------------------------------------------------------------------------------- /articles/lead-programmer-reponsiblities.md: -------------------------------------------------------------------------------- 1 | # 首席开发人员的责任 2 | 3 | 最终我的责任是，**让我团队中的所有开发人员都遵守我们（我的团队和更广泛的开发团队）所同意的软件质量标准**，以便尽可能高质量地完成工作。 4 | 5 | **理解并能够向我的团队，讨论和解释良好软件设计和开发原则的重要性**，以便我们能够在最快的时间内生产出质量最高的软件，并且能够在将来继续这样做。 6 | 7 | **要理解并能够一致地讨论，我们正在实施的任何实践（例如重构，TDD和结对编程）及其好处**，以便我们共同努力，并理解它们为何如此有价值。 8 | 9 | **为了确保我的团队开发的功能在最快的时间内以尽可能高的质量生产**，所以将来我们能够继续这样做。 10 | 11 | **向我的团队中的开发人员展示更好的做事方式，并帮助他们提高技能**，以便我们在工作中变得更好。 12 | 13 | **为了确保我的团队负责的软件是健康的，我的团队和更广泛的开发团队可以看到它的健康状况**，这样我们就可以专注于改进它，并知道技术债务和遗留代码的位置。 14 | 15 | **作为最贴心遵循我们所承诺的原则和实践的人，以我的团队中的所有开发人员为榜样**，以便团队中的开发人员对他们也能够有信心。 16 | 17 | **作为我团队中所有开发人员的榜样，通过提倡学习和花时间自己这样做**，让他们感到舒适，他们也可以。 18 | -------------------------------------------------------------------------------- /articles/make-great-tech-lead.md: -------------------------------------------------------------------------------- 1 | # 如何成为一个伟大的 Tech Lead？ 2 | 3 | 原文链接：[What makes a great Tech Lead?](https://www.madetech.com/blog/what-makes-a-great-tech-lead) 4 | 5 | 如果您是一名开发人员，试图了解可能需要采取哪些步骤，那么您来对地方了。在本文中，我们将讨论在招聘或晋升为技术领导角色时我们寻找的一些特征： 6 | 7 | ## 全栈高于专家 8 | 9 | 新式的（modern） Tech Lead 应该知道全部的信息。对于我们来说，这意味着前后开发：前端（coffeescript、sass、html）到服务器端开发（ruby、python等）到devops（chef、docker、terraform等）。有一些领域你觉得更有信心是可以的，但是作为一个 Tech Lead，你应该在整个技术栈中塑造一个应用程序。 10 | 11 | ## 承担责任高于等待任务 12 | 13 | 新式的 Tech Lead 不等待义务。他们确定了一项需要完成的工作，并采取行动。责任是承担的，而不是给予的，这是一个很好的口头禅，这是不可能比当采取一个Tech Lead 类型的角色的步骤更真实。如果你在等待某人提升你或者给你更多的责任，那么你会等很长时间。 14 | 15 | ## 开辟新天地高于坚持尝试和测试 16 | 17 | 软件行业的发展速度惊人。每天都会出现新的框架、技术和工具。新式的 Tech Lead 需要处于前沿，抓住适当的机会，将新技术和工具引入交付。继续对每个项目使用相同的“尝试和测试”方法是没有好处的。如果你这样做，你就会被甩在后面。 18 | 19 | ## 作者高于译者 20 | 21 | 在过去的几年里，一个大的规范文档会放在你的办公桌上，你会把它翻译成一些工作软件。现在，作为技术负责人，你的工作是成为一个作家，而不是翻译。你提供了叙述，并决定了项目应该走哪条路。这需要创造性和想象力，以及对过程的严格理解。 22 | 23 | 24 | ## 主动传播者高于墙头花 25 | 26 | 新式的 Tech Lead 需要成为积极的沟通者。躲在角落里，等待别人开始重要对话的日子已经一去不复返了。您应该是鼓励团队内部持续积极沟通的人，因为沟通是制作优质软件的关键。 27 | 28 | ## 可靠性高于不可靠 29 | 30 | 新式的 Tech Lead 是可靠的。他们的团队总是可以指望他们在那里并且可用。他们生病，迟到或错过最后期限是不寻常的。正是这种可靠性意味着他们可以承担运行项目的责任。我们已经看到责任水平提高与可靠性提高之间存在密切关联。 31 | 32 | ## 导师高于聆听教导者 33 | 34 | 新式的 Tech Lead 提供指导，并期望培养和支持他们的同事。他们从主要寻求帮助，转向向其他人提供帮助。他们认识到同事面临的挑战，并提出改进方法。他们认识到，他们为改善个人所做的任何事情都将有助于整个团队。 35 | 36 | ## 拥抱客户高于避免客户 37 | 38 | 新式的 Tech Lead 与客户交流舒适。他们不再让别人与客户打交道，而是有信心并能够就影响交付的任何事情进行对话。 39 | 40 | ## 解决问题高于标志出问题 41 | 42 | 新式的 Tech Lead 是一个解决问题的人。他们不会坐在那里等待某人移除阻挡者。他们捅，他们刺激，他们找到了新的方法来转发东西，所以他们可以继续运输代码。他们发现了一种坏味道并且修复了它，而不是让坏味道妨碍进展。 43 | 44 | ## 永远在学习 45 | 46 | 随着软件业务的日益复杂化，所需的技能将不断发展。 要跟上，你需要成为一个优秀的学习者，你需要留出时间学习新事物。 47 | 48 | 如果你能做到这一点，其余部分应该都能落实到位。 49 | 50 | -------------------------------------------------------------------------------- /articles/path-to-production.md: -------------------------------------------------------------------------------- 1 | # 如何优化上线流程——Path to Production 2 | 3 | > 可视化 Debug ：Path to Production 4 | 5 | 在你们公司里，当你们想上线一个新的功能时，需要怎么做才能上线到生产环境？若是没有 Path to Production 的相关知识，那么，我的答案就是这样的： 6 | 7 | - Local。在本地完成 A 功能的开发，提交代码到 Git 服务器上 8 | - Dev。CI 检测 Git 服务器的变化，运行构建。构建成功后，自动部署。 9 | - QA。在 Dev 环境完成联调后，部署到 QA 环境进行详尽测试。 10 | - ST/UAT。在完成这次上线的功能后，在 ST/UAT 环境上，进行上线前的验收测试。 11 | - Production。审批，上线。 12 | 13 | 看上去没有问题，这是一份相关合适的“标准” 答案，然而它可能一点儿用处也没有——因为大家都是这么做的。可是同样一个功能，从开发到上线，有的项目只需要几个小时，有的项目却需要几周。隔壁的小公司，和我们的流程完全一样啊，为什么它们的上线如此的快。为什么呢？无非就是流程。 14 | 15 | 于是乎，若以这种方式来定义我们的上线流程，怕就不再是那么合理了。我们的流程中，省略了相当多的东西。 16 | 17 | ## 为什么上线如此的长？ 18 | 19 | 不同的公司，不同的组织，不同的团队，对于 to Production 都有自己所需要的流程以及规范。在各自的公司和组织里，它们拥有各自对于软件的生命周期的定义。它们起源于一些基本的定义，诸如： 20 | 21 | | 活动 | 描述 | 22 | |----------|-----------------------| 23 | | 命名生命周期的阶段 | 环境映射到阶段 | 24 | | 定义状态 | 状态是用户定义的值，例如“已通过”或“已存档” | 25 | | 添加门 | 门（gate）是一种机制，可确保项目无法部署到阶段/环境中，除非它们具有门指定状态 | 26 | 27 | 我们所熟知的 ``local -> dev -> qa -> st/uat -> prod`` 便是这样的几个不同的关卡，每个关卡都由不同的人来守卫。这个守卫的人，便是对这次行为负责的人。在向 QA 环境部署时，需要 Dev 对质量负责；在向 ST 环境部署时，需要 QA 对之前的内容负责；在部署到生产环境时，需要所有的人对它负责。 28 | 29 | 正是由于不同的公司，对于这些关卡规范的不同，导致了“同样的代码” 在不同的公司里会有不同的上线周期。如同样是一个部署到 UAT 环境，在 A 项目里，可以由开发人员直接触发，而在 B 项目里，则需要先拥有测试用例等，才能部署到 UAT 环境。若是情况紧急（紧急修复一个 bug），还需要相关的项目的负责人，开上个会议，才能部署到 UAT 环境。这样的情形，也适用于上线过程，需要一级一级的审批，才能进入最后的上线流程。 30 | 31 | 除去软件质量的相关原因，我们会发现相关的上线流程也特别的长。可为什么流程会这么长呢，到底是什么因素导致了每次上线的周期特别长呢？所以，我们就需要去 Debug 为什么需要这么长的时间。在那之前，让我们先看看一张图： 32 | 33 | ![Path to Production](images/ptop.png) 34 | 35 | 它便是上线流程的一种可视化形式： Path to Production ，其用途在于： 36 | 37 | - 找到项目上线的痛点和瓶颈，如某个审批人经常不在，审批的时间太长 38 | - 拥有一份完整上线文档，帮助团队成员了解项目。 39 | - 有针对性地优化上线过程中的问题。 40 | - …… 41 | 42 | 那么，问题来了： 43 | 44 | ## 什么是 Path to Production ？ 45 | 46 | Path to Production，来源于精益，旨在通过可视化的方式来展示项目的上线流程，并优化过程中的瓶颈问题。它类似于我们使用 CI（持续集成）时的 Pipeline。传统的 Pipeline 的 gate 可以通过代码定义一些标准，由测试不能挂，测试覆盖率不能低于多少，打包不能失败等等。而这些 Pipeline 则是分别由开发人员、测试人员、运维人员、项目负责人等等来负责把控的。 47 | 48 | 对应的，在这个过程中：流程（Process）、人（People）、工具（Tooling）、产物（Artifacts） 都是我们的关注点： 49 | 50 | - Process，即上线需要多少流程。从提交代码开始，运行持续集成，部署到 Dev 环境等等。 51 | - People，即过程中需要哪些人来参与。如需要开发人员提交代码，需要测试人员进行 QA 环境部署，需要项目经理等高级领导进行上线审批等。 52 | - Tooling，即需要使用哪些工具来完成上线。如托管代码的 Git 服务器，运行构建的持续集成工具，提交上线申请的相关工具等等。 53 | - Artifacts，即过程中产出的产物。如生成的应用包，QA 生成的测试报告等等。 54 | 55 | 随后，我们从相关的流程中，梳理出每个部分（流程）的持续时间、痛点，来查找优化空间。 56 | 57 | ## 如何做 Path to Production？ 58 | 59 | 方法论说了这么多，要做起来倒也不难——其实，我们所需要的是：知道有这么一个东西的存在。然后： 60 | 61 | 1. 绘制出基本的四个部分，即 Process、People、Tooling、Artifacts 62 | 2. 使用便利贴，将相应的流程整理出来 63 | 3. 重复第二步，直到真正完成 64 | 65 | 如下是一个相应的示例： 66 | 67 | | 活动 | stage 1 |stage 1 |stage 1 |stage 1 |stage 1 |stage 1 |stage 1 |stage 1 |stage 1 | 68 | |--------|--------|--------|--------|--------|--------|--------|--------|--------|--------| 69 | | Process | 提交代码 | 运行 CI | 部署到 Dev 环境 | 运行 E2E 测试 | 手动测试 | 部署到 ST/UAT | 手动测试 | 上线申请 | 上线 | 70 | | People | Dev | Dev | Dev | Dev | Dev | 项目 QA | 业务 QA | 业务 QA | PM | Dev | 71 | | Tooling | Git & GitHub | Jenkins | Jenkins | Jenkins | - | Jenkins | - | 邮件 | - | 72 | | Artifacts | 代码 | 持续集成结果 | - | 测试报告 | 测试报告 | - | 邮件结果 | -| | 73 | 74 | 4.列出每个流程的时间长度和痛点，并看是否有办法解决 75 | 76 | ### 维护 Path to Production 77 | 78 | Path to Production 是一份需要不断更新的文档，为些我们需要： 79 | 80 | - 变更时，及时更新它 81 | - 使用可视化出 Path to Production，如白板 82 | - 上线时，可视化当前行走的步骤 83 | 84 | 对于复杂的项目来说，如一个项目可能有多个版本，那么它需要使用类似于看板的方式来维护。 85 | 86 | ![Kanban](images/kanban.png) 87 | 88 | 在每个阶段，都由相应的人来跟踪和维护。当发生状态更新的时候，及时更新状态到看板上。 89 | 90 | ## 结论 91 | 92 | 可视化的文档是最好的文档。 93 | 94 | 95 | -------------------------------------------------------------------------------- /articles/project-lifecycle-tl.md: -------------------------------------------------------------------------------- 1 | # 项目生命周期中的 Tech Lead 2 | 3 | 在大部分的组织里，一个 Tech Lead 做的事情，每个人在日常中，到底还是看得一清二楚。可是呢，项目上的每一个人，并非都是从一开始就在这个项目中的。有一些是一开始加入的，一些是早期加入的，还有的则是中途加入的。 4 | 5 | 也因此呢，我便根据 Tech Lead 要做的一些事情，再按照之前定义的[项目三步曲](https://www.phodal.com/blog/short-time-project-best-practise/)，绘制了一个在项目不同时间的 TODO Lists。 6 | 7 | ![Tech Lead in Project](../assets/tech-action-project.png) 8 | 9 | 需要注意的是：这里仅列出笔者**觉得重要的部分**（PS：由于是第一个版本，所以也可能缺少一些要点）。对于某些并非那么重要的职责，可以在上述的 Tech Lead 模型中查看到。 10 | 11 | ### 技术准备期（磨合期） 12 | 13 | 在 ThoughtWorks 开启一个项目的时候，会有这么两个时期：Inception、迭代 0。它们全程都需要一个资深的程序员、架构师参与。他/她的主要职责是**设计出符合项目需要的架构**。所谓的项目需要，并不一定是最合适于这个项目的技术方案。它可能受到利益相关者、组织架构等各种因素的影响，而导致最适合的方案无法采用。如最大的领导，喜欢的是 A 方案，而不是最佳的 B 方案。 14 | 15 | **Inception**，主要用于验证技术、业务、运营、设计、产品的可行性。过程中需要一个 Tech Lead 作为一个架构师，设计出符合项目需要的软件架构。按照我的理解，相关的过程大概如下所示： 16 | 17 | ![架构设计的流程](../assets/architecture-process.jpg) 18 | 19 | 过程中，要与项目相关的利益相关者进行沟通，与开发人员一起探讨……，最后妥协出一个能勉勉强强满足各方需求的架构。我们还会从相关的讨论中，梳理出项目相关的技术风险。 20 | 21 | **Interation 0**。迭代 0，便是在正式开始开发人员，我们所要做的技术工作。它包含的内容有： 22 | 23 | - PoC 架构验证。验证系统的架构是否真正可靠，并做一些细微的调整。 24 | - 搭建 CI/CD 25 | - 编写模式示范代码。以符合系统架构风格和模式的方式，结合业务功能编写示例代码，作为其它人的参考。 26 | 27 | 除此，在技术准备期，我们还需要： 28 | 29 | - 对项目成员进行技术培训 30 | - 设计、实施测试策略 31 | - 部署设计及实践 32 | 33 | 这是一个相当漫长的时期。 34 | 35 | 除此，在这个时间我们还要做的一件非常重要的是：**隔离其他/她技术人员与业务人员的直接需求对话**。 36 | 37 | 对于团队的其他/她成员来说，任何的功能和需求的来源，只应该是来自于业务人员（源自业务需求），又或者是团队中的技术负责人（技术需求）。而不应该由业务人员直接与其他/她开发人员沟通。哪怕是 Tech Lead 和业务人员不在的时候，也需要减少此类事情的发生。 38 | 39 | ### 业务回补期 40 | 41 | 无论是上一个时期，还是这一个时期，我们不得不妥协于业务开发的进度，而忽视一些技术上的追求。这也就导致了，我们在技术实践上缺乏一些更好的实施。 42 | 43 | 也因此，作为一个 Tech Lead，我们需要建立一系列的规范： 44 | 45 | - 着手建立技术债的白板。开始一步步偿还一些技术债，诸如测试覆盖率不足的问题。 46 | - 创建团队的技术文化。知识分享、知识传递等。 47 | - 关注于团队成员的成长。 48 | 49 | 过程中，不断发布新版本的应用，也因此稳定了系统的部署架构。 50 | 51 | ### 成长优化期 52 | 53 | 到了这个阶段，作为一个 Tech Lead，我们所要关注的内容，主要有两部分： 54 | 55 | - 架构演进。系统已经偏向于稳定，只是我们可以探索新的方式，来帮助我们解决当前的问题。 56 | - 人员的培养和成长。团队的大部分成员在这个时期，已经处于 “无聊” 阶段，需要一些新的元素来帮助他/她成长。 57 | 58 | 这并不代表其他/她的几个方面是稳定的。仍然会出现一些变化，只是这些变化的影响范围并没有那么大。比如，一些关键的利益相关者更换了，那么还需要重新的摩擦一断时间。 59 | 60 | ### 其它 61 | 62 | 最后不得不提及的一点是：**受多种因素的影响**，项目的开发速率会先从落后于标准速率开始，而后追平，最后随着平均水平的提高，便超过平均速率。 63 | 64 | 所以在这个过程中，需要 Tech Lead 在合适的时期，采用合适的策略。 65 | -------------------------------------------------------------------------------- /articles/software-architecture.md: -------------------------------------------------------------------------------- 1 | # 软件架构和自组织团队 2 | 3 | 原文链接：[Software architects & autonomous teams](https://ebaytech.berlin/software-architects-and-autonomous-teams-328138202df1) 4 | 5 | 近年来，我一直在多个组织担任软件架构师，包括技术公司和高增长初创公司，既是个人贡献者，也是架构团队的经理。我所学到的是，软件架构师角色是最多样化的角色之一，也是最不了解的角色之一。让我们看看业界对软件架构师的看法。 6 | 7 | > 软件架构师是一名软件专家，负责制定高级设计并指定技术标准，包括软件编码标准，工具和平台 - Wikipedia 8 | 9 | 最常见的理解是，架构师是一个接受并决定决策的人。在许多人的理解中，这不符合软件工程的许多其他现代原则，例如自主的跨职能团队，独立的微服务或团队的软件所有权（您构建它，运行它）。此外，还有平台小组的概念，它关注共同点和一套合理的共同标准。那么，为什么在现代工程组织中有人会做出决定而不是团队呢？这是一个很棒的问题。 10 | 11 | > 软件架构师，永远不应该做出团队可以自己做出决定的决定 12 | 13 | 当团队无法自己做出最佳决策时，需要软件架构师。这不是技术专长。架构师不是房间里最聪明的工程师。虽然，软件架构师确实应该是一位资深且知识渊博的人，但非凡的技术专业知识，并不是拥有软件架构师的原因。主要原因是对大局和广泛关注的了解。以下是我在软件架构角色中看到的主要优点。 14 | 15 | ## 复制成功案例 16 | 17 | 如今，不同的团队通常不共享代码库。此外，微服务可以帮助团队更灵活，更独立，更快地行动。因此，团队对其他人的工作知之甚少。特别是在人们甚至在地理上分布的大公司。一个团队可能正在努力解决另一个团队是专家的问题。通过与多个团队合作，软件架构师可以帮助找到，并复制成功的决策。两个团队可能正在解决类似的问题，而不承认这一点。但与他们两个合作的人肯定会。我已经多次看到，团队计划开发另一个团队已经实现的一些功能：弹性解决方案，平台升级甚至是微服务。 18 | 19 | ## 确定战略改进 20 | 21 | 该系统与其最薄弱的环节一样强大。在每个组织中，都有一个不如其他组织强大的功能。通过识别和改善最薄弱的环节，我们大大改善了整个系统。它可能是系统弹性、域隔离、DevOps 成熟度或性能。每个团队都应该致力于技术卓越。但是，如果他们在不同的方向上工作，那么结果可能比整个组织优先考虑一个方向的影响要小。架构师可以识别并突出显示系统中最薄弱的环节，并帮助其他团队定义最显着的改进。 22 | 23 | ## 保持决策务实 24 | 25 | 好工程师喜欢他们的工作。此外，他们喜欢学习新东西。当你手上拿着一把锤子时，每个问题都可能看起来像一个钉子。架构师肯定应该为代码库做出贡献，但是他们不像开发人员那样花费太多时间编写代码。因此，架构师在技术决策上的情感依赖程度较低。此外，架构师对组织了如指掌，并且更关注预算影响，因为他们通常了解全球基础设施成本和全局。这有助于保持务实，而不是过度工程。切勿与切角混淆实用。务实主要是关于不做某事，而不是以不可维护的方式做某事。同时，应始终保持合理的实验和学习感。 26 | 27 | ## 专注于技术卓越 28 | 29 | 工程团队通常以领域和功能为导向。这意味着他们专注于提供客户价值。架构师通常不是功能团队的一部分。相反，他们可以专注于并促进技术卓越，并成为产品团队和交付压力的反制力量。这有助于在组织中找到技术卓越，交付和可扩展性之间的正确平衡。虽然遵循既定的敏捷流程是每个人的责任，但可能会有一个 Scrum Master 来管理这一切。同样，虽然确保长期系统可维护性是每个人的责任，但软件架构师可以帮助实现这一目标。 30 | 31 | ## 吸引，促进和发展人才 32 | 33 | 软件架构师角色吸引了强大的工程师，他们喜欢全系统关注并与其他人合作。软件架构师是一个允许应用软技能，而不是软件工程师角色的角色，但没有人们不喜欢的人员管理职责。许多软件架构师，不会以软件工程师或工程经理的身份交换此角色，因为他们非常擅长软件架构师的工作。这个角色将高级技术人才，吸引到可能没有申请的公司。此外，这是一个很好的选择，让您的经验丰富的工程师更加投入。扮演架构师的角色，确实是一个伟大的职业发展步骤。 34 | 35 | 如您所见，没有精确定义软件架构师职责使这个角色无法替代。软件架构师的职责可能由其他人承担。 36 | 37 | > 没有架构师，公司很可能能够生存下去。但我相信，熟练的架构师可以为任何工程组织带来显着的价值。 38 | 39 | 软件架构师的关键价值在于，通过帮助其他工程师做出更好的决策，来节省时间和金钱。熟练的架构师可以成为神秘的10倍工程师，比他或她实际花费的开发天数节省 10 倍。当人们想知道为什么架构师决定决策时，软件架构师角色的主要缺点可能是：权威造成的挫败感。要成为一名技术娴熟且有价值的软件架构师，仅仅是一名技术强大的技术人员是不够的。还应该掌握沟通，演讲和领导技能，并实践以业务为导向的思维。 40 | -------------------------------------------------------------------------------- /articles/tech-lead-4-challenges.md: -------------------------------------------------------------------------------- 1 | # 每个 Tech Lead 面临的四个挑战 2 | 3 | 原文链接：[Four Challenges Every Software Tech Lead Faces](https://www.forbes.com/sites/forbestechcouncil/2018/09/28/four-challenges-every-software-tech-lead-faces/) 4 | 5 | 成为 Tech Lead 很复杂。你承受着很大的压力，对你和你的工作都有很大的期望。您是该项目的关键部分，其成败在很大程度上取决于您。 6 | 7 | 虽然没有经验的真正替代品，但在我担任 Tech Lead 的 10 多年里时间里，我发现了技术领导者（Tech Lead）经常面临的一些问题，这些问题往往引起一次又一次的头痛。下次遇到以下挑战时，请考虑以下解决方案： 8 | 9 | ## 1. 选择要使用的技术、框架或编程语言 10 | 11 | 这是所有技术问题的起源（mother）。说实话，这不仅仅是技术领导者（Tech Lead）所要面临的事情，而是一般的开发人员也要面对。但是，对于技术主管来说，这一步骤尤为重要。如果做出错误的选择，那么整个项目可能会从错误的地方开始，之后纠正错误需要会非常昂贵和复杂的代价。 12 | 13 | 这个问题有很多不同的答案，选择正确的答案取决于很多因素。首先要记住的是，我们倾向于忘记的事情：**为正确的工作选择合适的工具**。您可能会发现，某个框架或编程语言非常有趣和有趣，但如果它并非针对此当前场景设计的，因此请不要尝试将其弯曲到您的意愿。相反，尽量客观并寻找专为此任务设计的工具。您还可以学习类似的项目，以了解他们选择的工具以及原因。 14 | 15 | 考虑一下你**所拥有的人才也很重要**。如果团队中的每个人都使用技术 A，即使它不是最合适的，切换到技术 B 可能不是最好的解决方案。您还应该考虑人才库如何发展，并考虑在未来为您所选择的技术雇用人才是多么容易。 16 | 17 | **您可能还喜欢** 18 | 19 | 请记住每个解决方案的直接和间接成本。一些成本最初可能不那么明显，例如维护和运行解决方案的成本。 20 | 21 | 最后，考虑项目未来的样子，并寻找随项目发展的工具。 22 | 23 | ## 2.权衡开发人员的意见 24 | 25 | 想象一下，开发人员会为您提供一个让您有点不舒服的解决方案。在这种情况下，您可以做的最好的事情是信任您的开发人员，但也相信您的直觉。如果您对某些事情不满意，请先请您的开发人员解释，然后分享您的观点。 26 | 27 | 如果您仍然认为该方法存在问题，请尝试寻找第二意见，但不要公开，因为您的开发人员可能认为：您不信任或不尊重他们。相反，私下与他人协商（如果可能的话，在团队之外）。 28 | 29 | 最后，如果没有更好的结果，请尝试开发人员建议的内容。你每天都可以学到新东西。 30 | 31 | ## 3. 平衡截止日期及问题 32 | 33 | 不要屈服于试图取悦每个人的诱惑，或者觉得有义务撒谎或 “调整” 事实。如果您认为存在影响项目交付的问题，请将其清楚地传达给利益相关方。作为一个好领导者的一部分是，接受有些事情你无法改变，并相应地面对他们。 34 | 35 | ## 4. 聘请 “摇滚明星” 开发人员 36 | 37 | 我发现团队经常试图培养一种 “摇滚明星” 文化。一些发布r 职位，甚至明确搜索 “摇滚明星开发者”。让我说清楚：摇滚明星们演奏音乐会；他们不写代码。我不是说你不应该聘请才华横溢的开发人员——实际上，你应该努力雇用最好的开发人员 - 但你也必须注意你正在创造的文化。 38 | 39 | 将自己描述为摇滚明星的人的问题在于，他们往往难以合作。他们可能相信他们知道最终的真理，并且几乎没有能力接受不同的意见。这可能适用于非常小的团队，但随着团队的发展，问题将开始出现。最终，你最终可能会失去你的团队成员（无论是摇滚明星，还是厌倦摇滚明星的人）。 40 | 41 | 我的建议是寻找有才华和热情的开发者，而不是那些认为自己是摇滚明星的人。有很多非常有才华的开发人员，只是喜欢他们所做的事情，并不关心做对 - 他们只是想要最好的项目。不要浪费时间雇佣他们。 42 | 43 | 成为技术领导者（Tech Lead）的一个非常重要的部分是，**能够应对不确定性**。您必须学会接受有些事情是无法控制的。最后，按照你的直觉。我们经常没有所有的答案，我们的部分工作是做出有根据的猜测。不要害怕尝试。 44 | 45 | -------------------------------------------------------------------------------- /articles/tech-lead-8-qualities.md: -------------------------------------------------------------------------------- 1 | # 好的 Tech Lead 应具有的 8 个品质 2 | 3 | 随着致力于特定项目的开发团队的发展，需要在所有团队成员之间划分职责和责任。经过几年的不同选择测试，我们采用了 Tech Lead 的方法，我们对角色定义非常有信心。 4 | 5 | 与高级、常规、初级（ Senior/Regular/Junior ）分类相比，高级和中级开发人员可以担任 Tech Lead的角色。 6 | 7 | 以下是每位 Tech Lead 应具备的 8 项品质。这就是我们想出来并坚持在 Monterail 的榜样。 8 | 9 | ## 代码质量 10 | 11 | Tech Lead 对项目的代码库质量负责。通常，这意味着对其他开发人员进行代码审查，审查 Pull Request 请求等。这并不意味着 Tech Lead 是唯一应该执行代码审查和合并的人。 在更大的团队中，这应该是每个人的工作，但是 Tech Lead 有责任实现这一目标。 12 | 13 | ## 软件架构 14 | 15 | 虽然整个开发团队应该参与有关技术解决方案、工具集选择和项目软件架构的讨论，但最终还是 Tech Lead 由做出最终的决定。 16 | 17 | ## 研究、原型、概念证明 18 | 19 | 在有不寻常要求的情况下，Tech Lead 负责研究和准备原型或概念证明。 这些任务可以委派给其他团队成员。 20 | 21 | ## 与客户联系 22 | 23 | 当需要与客户方面的人讨论技术问题时，Tech Lead 是 PM 接近的第一个人。Tech Lead 可以将对话委托给她团队中的其他开发人员，也可以自己完成。 24 | 25 | ## 知识库 26 | 27 | Tech Lead 应该对他/她的项目有最好的了解。他/她应该能够回答有关该项目的所有技术问题。Tech Lead 还应确保项目的文档是最新的。 28 | 29 | ## 安全 30 | 31 | Tech Lead 对项目的安全性负责。它包括使所有库保持最新，对任何 CVE（应用程序和服务器端）做出反应，并确保对代码库的任何更改都不会引入任何漏洞。Tech Lead 的职责是为这些更新分配时间，并解释在必要时 PM 和客户解释它的必要性（和风险）。 32 | 33 | ## 帮助他人 34 | 35 | Tech Lead 应该是其他团队成员的导师 - 帮助他们解决技术问题，推动他们的学习之路。 36 | 37 | ## 委托 38 | 39 | 正如本文前几次所提到的那样，Tech Lead 可以将各种技术任务委托给其他团队成员。但是这并不意味着，他/她必须这样做。而即便如此，Tech Lead 仍然对结果负有直接责任。 40 | 41 | 42 | -------------------------------------------------------------------------------- /articles/tech-lead-analyzing-requirements.md: -------------------------------------------------------------------------------- 1 | # Tech Lead 的需求分析 2 | 3 | 原文链接：[Analyzing Requirements as a Tech Lead](http://www.zsoltnagy.eu/analyzing-requirements-as-a-tech-lead/) 4 | 5 | 在过去的几个月里，我一直作为 Tech Lead 协调一个软件项目。从公共关系的角度来看，我们称这个职位为 Tech Lead，但实际上，我承担着架构师的角色。 6 | 7 | 从头开始创建一些东西很有趣。有时它并不好玩，因为黑暗中的决定有时看起来很可怕，但作为 Scrum 团队的一部分，我们总是在那里纠正路线。我周围也有很多伟大的人，每当我忽视某件事时，他们就会抓住我。 8 | 9 | 随着我在企业界积累了大量的经验，我开始了解企业是如何运作的，有董事和副总裁的九层企业结构是什么样的，我也开始领悟到达到顶峰需要哪些技能的本质。本文将重点讨论在需求分析和软件设计环境中 Tech Lead 的角色。 10 | 11 | ## Tech Lead 角色 12 | 13 | 一个项目的技术主管可以做很多事情来帮助项目向前发展。这包括 14 | 15 | - 做出架构决策， 16 | - 解决技术争议， 17 | - 监督功能和非功能需求， 18 | - 设置代码库、项目结构， 19 | - 驱动架构和详细的软件设计， 20 | - 帮助团队将应用程序部署到云上， 21 | - 建立持续的集成管道， 22 | - 还有惊喜，甚至是编码。 23 | 24 | Tech Lead 是一个角色，而不是一个职位。你可能是一个项目的Tech Lead ，在另一个项目中可能扮演完全不同的角色。 25 | 26 | Tech Lead 是有原因的主管。在团队成员高度自治的环境中，团队成员向技术主管寻求建议。高度自治意味着，任何负责某项任务的人都有权做出决定。Tech Lead 只是在那里提供指导，稳定团队。 27 | 28 | 有一些象牙塔的 Tech Lead 和架构师在那里从来没有编码。同样，您可以在大多数组织中遇到一些了解一些非常高级概念的经理，但他们不知道如何用信息帮助另一个团队，因为他们与自己的领域没有那么深的联系。他们委派并保持很高的水平。一些经理和董事承认这些漏洞，并指出了正确的人选。其他人玩游戏，如果他们不知道什么，他们害怕承认。与后一种类型的经理和主管类似，象牙塔架构师通常是团队的负担，因为这种类型的人将自己与现实世界隔离开来。太多了，以至于他会耽误团队而不是帮助他们。 29 | 30 | 最糟糕的象牙塔建筑师可能会做一些所谓的生产性拖延。它们通过专注于错误的事情，用别人不关心的请求分散整个团队的注意力，看起来很有成效。 31 | 另一方面，Tech Lead 能够解决任何挑战，甚至可能比大多数团队成员都要好一点。由于在其他地方增加了更多的价值，实际的 Tech Lead 代码量低于平均值。 32 | 33 | 领导是责任。在所有层面上，领导意味着服务。那些想在聚光灯下崭露头角的人，应该立即转向演艺事业。在今天的世界里，你甚至不需要守门人，因为你只需要学习一些表演技巧，就可以建立一个 YouTube 频道。然后你可能会说服那些不太懂技术的观众，他们在你的课程中投入几个月的努力后，每小时可以赚 100 美元。这样每小时能赚 100 美元吗？对。有可能吗？不，尤其是当你的听众对基础数学有困难时。 34 | 35 | 36 | ## 技术主管在需求工程中做了什么？ 37 | 38 | 在整个软件开发生命周期中，技术主管是有帮助的。 在需求分析期间，技术主管帮助阐明需求的以下方面： 39 | 40 | - 功能要求， 41 | - 非功能性要求。 42 | 43 | 功能需求描述了我们正在构建的软件。 44 | 45 | 非功能性需求描述了我们构建的系统的质量。 这包括最大容许停机时间（可用性），数据保护问题，可扩展性等的规范。 46 | 47 | > 功能要求可能意味着非功能性要求。功能和非功能需求都会推动架构决策。 48 | 49 | 因此，技术主管应该通过提出正确的问题来参与探索需求。 50 | 51 | ### 发现功能需求 52 | 53 | 功能需求描述了我们正在构建的软件。 这包括： 54 | 55 | - 了解用户是谁， 56 | - 了解用户想要解决的问题， 57 | - 了解用户想要解决问题的原因。 58 | 59 | 指定软件验收标准的一个好方法是 Gherkin。在结构中看到谁，什么，为什么的作用： 60 | 61 | ``` 62 | S AN Advertiser 63 | I WANT TO set up Advertising Campaigns 64 | SO THAT I market my product 65 | ``` 66 | 67 | 有不同的工具来捕获需求。如果不了解用户（也称为参与者），与每个角色分解的用户相关联的工作流程，以及我们系统运行的上下文，我们开发的软件将不太可能解决客户端的痛点。 68 | 69 | 在瀑布项目中，整个项目的范围是预先确定的，这意味着到这个阶段结束时，要求或多或少都是一成不变的。例如，如果您订购房屋，您必须提前澄清您想要的房屋类型。当建筑师开始为您订购的建筑物制定建筑计划时，您很少会改变主意，表示您希望在建筑物顶部添加第二层。 70 | 71 | 在敏捷项目中，需求通常会发生变化。我们倾向于接受变更。我们仍尽最大努力尽早收集所有要求，但我们希望改变发生。 72 | 73 | > 敏捷不应该成为不尽力满足要求的借口。无论如何都要求需求会改变，所以为什么创造需求，被称为无知，而不是敏捷。 74 | 75 | 要进行校正，我们需要明确的方向。该方向由功能要求提供。 76 | 77 | 例如，想象一下软件系统，技术主管选择用 PHP、MySQL 和 JavaScript 编写单片应用程序，忽略了他们的客户将存储 5TB 数据的事实，并且 MySQL 很难处理这个数量的几个百分点。尽管扩展是非功能性要求，但可以通过检查功能要求来检测所涉及的数据量。 78 | 79 | 同样，实时，每小时和每日更新的数据之间存在很大差异。在那些日子里，我是日常数据库存交易应用程序的技术主管和架构师。我们每天从澳大利亚数据提供商处导入一次数据。我们的客户想要实时更新，所以我们必须彻底改变我们获取数据的方法。 80 | 81 | > 一个 Tech Lead 应该监控需求，因为在他们收到正确的问题之前，客户通常不会完全知道他们想要什么。 82 | 83 | 我看到了包含逻辑矛盾的需求文档。 人类通常很难通过使用连接和分离来描述它们的含义。 许多非技术人员混淆了 ``and`` 或 ``or`` 。当他们写 ``or``，他们通常意味着 ``xor``。 84 | 85 | 我看到用户故事没有给客户带来任何价值，同时他们大大增加了解决方案的复杂性。一个好的 Tech Lead 应该通过识别它们，或者通过委托和监督对专家的技术要求分析来指出这些问题。 86 | 87 | 在发现功能需求时，可能需要对数据进行高级分析以了解系统正在执行的操作。 这可能包括： 88 | 89 | - 一个上下文详细说明了系统及其数据流边界 90 | - 确定系统内部进程如何转换数据的数据流 91 | - 实体关系模型，它充当建架构的基础，因为数据库模式和业务逻辑都依赖于它。 92 | 93 | ### 我们需要注意哪些非功能性要求？ 94 | 95 | 再一次，非功能性需求描述了我们构建的系统的质量。质量是通过一些需要明确定义的指标来衡量的，以推动架构决策。 96 | 97 | 如果您正在设计一个人类生命或数万亿美元的关键任务应用程序，我假设您不需要本文，因此，我将重点关注我们在项目中关注的典型非功能性需求： 98 | 99 | - 可用性指标 100 | - 性能指标 101 | - 可扩展性 102 | - 合规 103 | - 安全 104 | - 可维护性 105 | 106 | 让我们逐一探讨这些非功能性需求的作用。 107 | 108 | **可用性**描述系统根据规范运行的百分比。想想你的网上银行软件。如果它在凌晨 1 点到凌晨 3 点之间发生了什么？不多。无论如何银行转账都不是直播，如遇紧急情况，有电话接线员可以处理您的请求。在其他情况下，只需一分钟的停机时间就会威胁到人们的生命，或造成数十亿美元的经济损失。可用性通常用 9 来衡量。 109 | 110 | 在电信行业，99.999％ 是通常的可用性指标。这究竟是什么意思？每天 0.864 秒，或一年只需 5 分钟。设计具有如此高可用性的系统需要比具有 99％ 可用性的系统更多的资源和容错能力，我们的系统每年可以停机 3.65 天。 111 | 112 | **性能**指标通常与响应请求的时间量相关联。在企业应用程序中，执行团队成员的报告可能需要几分钟才能编译。将此与日间交易者进行比较，他们相互竞争，减少从办公室到证券交易所中心的延迟时间。它们还可以通过算法交易软件最大限度地缩短响应时间，该软件会在必要条件得到识别后立即执行。与此同时，有些人仍然认为即使你手工操作，日间交易也很容易。 113 | 114 | 性能指标可能使得无法使用某些技术，因为存在大量数据，MySQL 数据库永远不会响应。在其他情况下，您可以选择阻塞 I/O（PHP）和非阻塞 I/O （node.js服务器）。您可能还必须考虑客户端的计算机以采取适当的客户端决策。 115 | 116 | **可伸缩性**是一种度量标准，可随着用户群的增长确定软件的未来性能需求。该指标与我的文章 “微服务简介” 松散相关。您可以创建一个单一的应用程序来验证您的想法作为MVP（最小可行产品）。然后，您可以通过从中提取微服务来扩展性能瓶颈。 117 | 118 | **合规性**是一项重要指标，因为您的应用程序可能受到法律环境的限制。数据保护的法律标准，或在线游戏公司的许可是两个可能对公司构成存在风险的强制性要素。另一个例子是政府招标，其中所有形式要素必须与所需要素相匹配。 119 | 120 | **安全性**是一个重要的指标，通常与合规性相关联。例如，数据被盗是由系统中的安全漏洞引起的。虽然小型创业公司除了宣布赏金计划并奖励，具有某些加密货币的道德黑客之外不会做太多事情，但公司通常有义务审核他们的系统，并维护一个负责所有软件解决方案的安全团队。该团队执行渗透测试，以确保软件解决方案不包含严重的安全漏洞。需求分析应根据相关风险处理这些安全问题，这意味着某些非功能需求由安全需求决定。例如，认证和授权系统可能受到安全要求的约束。 121 | 122 | **可维护性**意味着软件的生命周期。我们是否正在建立一个 MVP 来验证一些想法？开发速度比可维护性更重要吗？可维护性就像一个金融账户。当牺牲软件的质量时，就像借钱一样。这笔钱必须在晚些时候以利息偿还。如果借了太多钱，我们可能永远无法偿还单身而且我们会破产。在软件方面，我们不借钱。我们创造技术债务。除非申请被破产，否则必须偿还这笔债务以避免破坏申请。例如，MVP 可能被完全抛弃，因为其主要目的是验证商业理念。MVP 应该快速开发，通常不考虑可维护性。另一方面，自动化组织的所有业务流程的复杂系统必须是可维护的，否则有一天我们意识到功能开发比以前花费更多的时间。 123 | 124 | **可扩展性**是可维护性的一个方面。它通常由功能需求所暗示。例如，您的任务可能是为一个特殊的客户机构建一个 MVP，但是您应该以最小的定制为行业中的任何客户机准备系统。 125 | 126 | 始终考虑开箱即用，因为没有清单可以提取涵盖所有情况的所有非功能性要求。 127 | 128 | 非功能性要求也可能来自您组织批准的黄金路径。较大的组织倾向于标准化工具，编程语言、框架、库、云提供商以及与软件开发相关的几乎所有内容。在您的架构中进行过多创新之前，请考虑这一点。 129 | 130 | 许多其他考虑可能会导致非功能性需求，包括开发团队的能力和内部政治。 131 | 132 | ### 软技能作为非功能性要求 133 | 134 | 您必须了解项目的利益相关者。 135 | 136 | 例如，由于自动化，系统的用户不再利用漏洞来获得经济收益。这意味着他们不会与您合作，因为他们的兴趣是继续利用系统，而不是帮助您改进流程。 137 | 138 | 例如，如果疾病诊断系统自动为症状开出最好的药物，那么医生将无法被营利者贿赂一种有利但非次优的药物，这样他们就能得到更多的处方药。 139 | 140 | ## 摘要 141 | 142 | Tech Lead 在整个软件开发生命周期中协调架构和工程决策，并领导他或她的团队。 143 | 144 | 在本文中，我们通过分析需求发现了 Tech Lead 的作用。 要求可以是功能性的或非功能性的。 所有要求都为建筑选择奠定了基础。 145 | -------------------------------------------------------------------------------- /articles/tech-lead-architecture-triangle.md: -------------------------------------------------------------------------------- 1 | # 我所相信软件架构师和技术领导者的成功三角 2 | 3 | 原文链接：[What I believe is a triangle of success for Software Architects and Technical Leads](https://dev.to/ggonchar/what-i-believe-is-a-triangle-of-success-for-software-architects-and-technical-leads-2gek) 4 | 5 | 近年来，我一直在多家组织担任软件架构师，包括技术公司和高速增长的初创公司。既是个人贡献者又是架构团队的经理。我意识到有三个原则可以帮助我完成日常工作。我总是试图做出所有决定，尝试了解业务和成本影响，并花时间编码。还有一些令我惊讶的原则。它们是我个人成功的三角形（感谢 HBO 的名字灵感）。 6 | 7 | 如果您不相信需要架构师或技术主管，您可能需要先查看我的其他故事：[软件架构师和自治团队](https://ebaytech.berlin/software-architects-and-autonomous-teams-328138202df1)。 8 | 9 | ## 让您的船员分享使命 10 | 11 | 我们很容易陷入这样一个陷阱：仅仅说服管理层做决定，或者作为架构师建立一个规则就足够了。现在，我们有独立的微服务团队，团队必须平衡相互冲突的优先级。抄近路很容易。如果你不能说服人们为什么某个决定是重要的，他们可能只是找不到足够的时间来遵循它。确保每个人都理解任务，并具有高度的动力。之后，通过实际贡献成为任务的一部分。 12 | 13 | 14 | ### 让贡献者参与决策 15 | 16 | 在将任何想法称为决定之前，将其呈现给直接在其上工作的人。首先，您会获得良好的反馈，然后您可以分享和理解该决策。在 @ebaytechberlin，我们发现架构决策记录作为一个 Pull Request 很好。您还应该采取其他措施。 17 | 18 | ### 首先在白板上讨论技术思路 19 | 20 | 我发现写得很好的提案很难改变。一旦任何人对某件事投入了巨大的努力，情感依恋就会起作用。在这种情况下，您可能会偏向于最初的建议。最好先把你的想法作为草稿，然后在白板上讨论其他人的想法。这样，就可以进行更多的讨论，并通过朝着正确的方向共同采取建议。仪器可能不需要白板，但需要拉请求。其想法是，最初的提议应该支持变更的灵活性。 21 | 22 | ### 确保记录缺点 23 | 24 | 我们都知道没有银弹。几乎任何技术决策都是一种权衡。通常，合乎逻辑的人不同意这些决定，因为他们不以同样的方式看待权衡。确保你解释了为什么某些优势超过了你当前项目的劣势。最好将权衡、结果和缺点包括到架构决策记录中，并记录为什么它们不如解决方案的优势重要。 25 | 26 | ### 向所有受影响的利益相关者展示决策 27 | 28 | 一旦做出决定，工作就不会结束。这只是旅程的开始。通过向其他利益相关者透彻地说明为什么团队会采取特定的技术方向，您就增加了以正确的方式平衡优先级以实现决策的机会。您还应该确保不仅工程师，产品经理和工程经理都了解技术远景。确保您的技术目标对非技术人员也具有有意义的名称和价值。“重构事件收集器” 是一个乏味的名称，任何产品经理都无法理解其中的价值。“删除不合理的事件跟踪代理以更快地添加对新事件的处理” 是一个冗长但已经有意义的名称。 29 | 30 | ## 理解现金流 31 | 32 | 每一个成功的工程组织都需要在财务上取得成功，才能继续其使命。这应该是技术负责人最关心的问题之一。 33 | 34 | ### 不同解决方案的成本是多少美元？ 35 | 36 | 了解某些云或硬件服务的成本，以及您的组织平均工程小时成本。你自己学习这项技术的费用，将其与聘请一位经验丰富的顾问的费用相比有多大。良好的体系结构也是长期以最佳成本实现业务目标的体系结构。如果不把粗略的数字放在你的决定上，很难做出正确的决定。 37 | 38 | ### 参与产品要求的梳理 39 | 40 | 产品改进，是我作为架构师经常参加的唯一一次团队会议。作为一个技术远见者，你需要非常清楚地知道你未来的系统需要如何工作。当一个产品经理呈现出新的特性，并且捕捉到某些产品决策的细微差别时，我发现这非常有用。但请记住，如果你是一个架构师或其他类型的领导者，而不是团队的一部分，那么你应该更愿意在团队会议中倾听。这种出席的主要目的是学习业务需求。只有在必须做出重大决定，而且不朝着你认为最佳的方向发展时，才积极参与。 41 | 42 | ### 花点时间坐在客户席上 43 | 44 | 与运营部门或客户支持团队共度一周可能是个好主意。我不是说你应该停止工作一个星期，坐在电话旁接客户电话。但是，如果您不直接处理 UX 或前端，那么很容易对产品的使用和操作方式建立错误的假设。 45 | 46 | ### 了解指标 47 | 48 | 了解产品的另一个补充方法是从数据度量中学习。你的客户是谁，你有多少。人们在您的平台上使用最多的功能是什么？某个特性应该处理多少流量应该是数据驱动的决定。您可以从产品管理中获得许多想法，以了解这方面的最佳实践。 49 | 50 | ### 了解战略目标 51 | 52 | 了解企业的战略优先事项。没有人能预测未来，你不应该建造不需要的东西。但这有助于了解船的航行方向。你在市场上的竞争优势是什么？你需要保持哪些关键优势？这将让你知道在哪里投入更多的时间，以及什么对企业更重要。 53 | 54 | ## 从内部了解你的车 55 | 56 | 5 年前是 JavaScript 专家的人，今天不会自动成为专家。“我有几十年的经验” 不是当今技术领域的论据。事情确实改变了，你需要保持最新。此外，在实践中展示产品和代码库知识的人，在提出决策时会赢得更多的信任。 57 | 58 | ### 用编码保持平衡 59 | 60 | 关于你应该花多少实际操作这一点，没有一个理想的时间。这在很大程度上取决于你对项目的时间、你对产品的了解程度以及你对技术的了解程度。主要的想法是编码不再是技术负责人的主要职责。如果你编码太多，你就没有时间做你最重要的工作。 61 | 62 | 作为一名技术领导者，你可以通过正确的技术决策而不是通过你自己提供的代码来对组织产生更高的影响。 63 | 64 | 同时，您需要自己深入了解您的代码库和产品。您需要尽可能多地编写代码，以保持这些冲突的优先级之间的平衡。 65 | 66 | ### 找时间编码 67 | 68 | 作为一个技术领导者，你会发现你在会议上花费了太多时间，工作时间变得支离破碎，你不再能够集中足够的精力，代码贡献成为一个挑战。 69 | 70 | 小贴士 1：**安排你的工作**。根据经验，当我的时间窗口少于一小时时，我甚至不会尝试编码。尽管我试图将一个无需开会的日子完全用于实际工作，但在会议较少的日子里，我会查看请求、创建文档或与人交谈。 71 | 72 | 小贴士 2：**在 “低” 架构季节做出更大贡献**。每个项目开始时都有更多的设计决策。你将高度参与其中，并将有较少的实际操作机会。只要接受这一点，只要项目进展顺利，你就会有更多的时间做出更大和重要的贡献。 73 | 74 | ### 仔细选择编码任务 75 | 76 | 如果您不属于一个工程团队，那么如何准确地为生产代码作出贡献可能并不明显。 77 | 78 | 小贴士 1：作为一个有贡献的想法，在最具挑战性或最不愉快的工作中迈出第一步。你不应该只吃糖果。你得把你的手弄脏，以身作则。如果您正在努力进行痛苦的重构，那么您也应该是进行重构的人。 79 | 80 | 小贴士 2：您应该为生产代码做出贡献，而不仅仅是在原型上工作。只要来到团队说 “嗨，我能和你一起冲刺吗？” 就行了，但这不是一个最佳的主意。对于团队来说，可能会看到老大哥在看着他们。相反，最好找一个真正需要帮助的团队。这可能是一个有多个成员休假的团队，也可能只是一个新团队，他们还不知道当前的情况。 81 | 82 | ### 保持深度 83 | 84 | 恭喜你，现在你是技术负责人。你不会再整天编代码了，因为你有不同的职责。你至少应该在一些学科上保持深入。因为我不是一个软件工程师，而且不花一整天的时间编写代码，这已经快 5 年了。但我仍然可以向一些最有经验的同事暗示一些棘手的 Java 错误的解决方案。重要的是不要成为 “各行各业的杰克”，谁只有广泛的知识。我很难想象自己是一个优秀的架构师，如果不保持深入的技术性，他会提出最佳的解决方案。 85 | 86 | 作为技术负责人或架构师，有很多方法可以产生影响。不要害怕花时间学习你的产品、代码库和解释你的技术愿景。你需要做的最重要的工作是制定正确的决策并使它们具体化。实际上，99% 的工作只是通过学习和贡献来准备技术愿景。 87 | 88 | -------------------------------------------------------------------------------- /articles/tech-lead-balancing-coaching-with-coding.md: -------------------------------------------------------------------------------- 1 | # 成为 Tech Lead 时：我是如何平衡编码与教练 2 | 3 | 原文链接：[Becoming a Tech Lead: How I've Balanced Coding with Coaching](https://product.hubspot.com/blog/tech-lead-balancing-coaching-with-coding) 4 | 5 | 在拥有许多小型团队的工程组织中，培养能够成为成功的工程师，以及有效导师的 Tech Lead 非常重要。根据公司、 团队或个人的不同，在实践中看起来有很多变化。在HubSpot，我们对 Tech Lead（TL）的定义明确指出：他们应该将大部分时间花在产品上，而不是人。 6 | 7 | Tech Lead 负责新工程师的入职，并帮助他们在自己的角色中脱颖而出。但仅此一点不应该是 Tech Lead 的全职责任。那么，为什么新 Tech Lead 的普遍抱怨的是，他们没有足够的时间来编码呢？ 8 | 9 | 在服务型领导与保持富有成效的个人贡献者之间取得平衡可能很难。我花了很多时间来适应它。在我担任 Tech Lead 的第一年里，我从经理那里学到的指导性口头禅是：努力成为其他人的力量倍增器。这意味着要找到一种方法，用于大幅提高同行的效率，以便随着时间的推移获得红利。当你赋予你的团队权力时，你不仅可以收回你作为个人贡献者的时间，而且你的队友也会自己做出惊人的事情。 10 | 11 | 任何团队的情况都没有灵丹妙药。这些是一些对我有用的学习，可以帮助你重新成为成功的个人贡献者，以及有效的领导者。 12 | 13 | ## 教你的团队钓鱼 14 | 15 | 成为 Tech Lead 之后不久，我意识到我正在接近我的团队的每一个问题，好像我有责任为他们找到答案。我已经接受了仆人式领导的想法。正如您可能想象的那样，这涉及到每个非平凡的问题都会花费大量时间。 16 | 17 | 为什么你会默认会花时间，来调查一些事情——而它们可以教你聪明的队友为你做？ 18 | 19 | 如今，我试图成为街道地图，而不是司机。我很快就会承认，当我不知道某些事情时 - 通常是 - 但我会描述我接下来要做什么，或者组织中的其他人能够做什么救命。我可能会在这两个人之间进行介绍，或者在一个新工具中提供即兴速成课程，以帮助他们解决问题。 20 | 21 | 我是这种策略的粉丝，因为它与提出问题的人保持问题和解决方案的所有权。随着时间的推移，您的团队成员也具有指数优势： 22 | 23 | - 他们学习如何使用工具，来回答他们自己的问题（指标、监控、调试、内部工具等） 24 | - 他们学习如何咨询新资源，其中有许多其他未来问题的答案（代码搜索、内部维基、知识库、外部文档等） 25 | - 他们在公司里结识新朋友，并建立新的关系 26 | 27 | 在这一点上，我的队友拥有我没有的各种技能和知识。考虑到我需要花时间自己学习所有这些东西，团队和我们的产品要好得多，因为我没有坚持在他们做之前吸收相同的知识。教导团队捕鱼，并授权他们使用他们可以使用的工具来解决问题。这对于帮助团队扩展，并取得更好的成果至关重要。 28 | 29 | ## 忘记 Atlas 的作用 30 | 31 | 在希腊神话中，阿特拉斯（Atlas）是被谴责将地球与天空分开的上帝。在规模小得多的情况下，我看到 Atlas 和 Tech Lead 在像我这样的团队中的角色有一些相似之处。 32 | 33 | 作为一名 Tech Lead，我很高兴看到我的团队投入到令人兴奋的新功能，有趣的技术挑战和他们表达的职业兴趣。当我们演示新功能或获得大的性能提升，并且我的队友负责 100％ 的代码时，它对我来说是一种刺激。（这些是我希望我团队的天堂。） 34 | 35 | 实际上，我工作的产品领域每周都有相当多的中断任务。它们是无计划的，可能是时间敏感的，并且通常没有明确的解决方案。这些可能是客户报告的支持问题，可靠性问题或公司其他团队的内部请求。（那是我觉得，有必要保护我的团队的地球。） 36 | 37 | 我团队的一位工程师最近告诉我，她有机会在学习使用新框架，并将其应用于重大的重新设计工作时，她享受到了多少。对于那些听说过生产力规则的人来说，它应该是相当熟悉的，开发人员需要长时间不间断的时间，才能发挥最大效果。 38 | 39 | 听说，谁会想要用 bug 打断这个人？这种方法的最终缺点是，自己承担所有笨拙的工作，可以迅速转变为无休止的追赶游戏。你可以为你的团队提供他们需要专注于更大问题的沉默，但你如何能够抽出时间来解决你自己的项目，从战略角度思考，并帮助你的队友成长？ 40 | 41 | 这是我一直在想的事情，但我发现将每个传入的问题，与每个团队成员的技能和专业知识相匹配是有帮助的。如果他们已经熟悉相关代码，那么它们应该是一个更容易的上下文切换，以便他们在方便的时候留出他们的主项目。如果时间和带宽允许，我甚至会将问题传递给不熟悉问题的工程师，作为他们分支的机会。 42 | 43 | 如果我有疑问，在点击 Jira 中的“分配”之前，我会明确地问，“嘿，你有时间在接下来的 1-2 天内，看看这个支持问题吗？” 这里的目标是开始一个关于优先级、紧迫性，以及对下一步应该做什么的期望的透明和协作的讨论。 44 | 45 | 我的主要目标是保持维护的痛苦，使每个团队成员有责任提供高质量的工作。该团队将期望他们能够做出改变。他们也会在以前与他们合作的事情上寻求帮助，所以花时间真正理解代码，而不是发送 bug 驱动的修复，以符合每个人的利益。 46 | 47 | 最后，我还认为，偶尔感受到这些类型的压力，符合团队的最佳利益。当存在大量漏洞或积压的技术债务时，让团队中的每个人拥有这些东西，也会让他们感到满意，并感受到清理旧的混乱所带来的所有权。 48 | 49 | 团队需要时间来积累技能和信心，共同处理可能出现的任何中断。然而，如果他们的团队中的工程师，从未被要求拥有他们的工作、切换环境或解决他们的舒适区之外的事情，那么这对 Tech Llead 来说将是一个难以吸取的教训。从长远来看，试图扮演 Atlas 的角色是一种不值得承担的负担。与团队分享会更好。 50 | 51 | ## 分享你的宠物石 52 | 53 | 作为工程师，我们喜欢解决难题。在一个新问题上拿出霰弹枪，并花时间秘密思考如何解决它，可能是非常诱人的。虽然在理智上令人满意，但这并不是让事情做得好或很快的方法。以下示例显示了一个有趣的谜题如何激励他人。 54 | 55 | 在过去几个月中，我们注意到我们的 Java 项目需要更长时间才能构建。即使我们将项目的构建从 Jenkins 迁移到 Blazar，这应该给我们一个很好的推动，但我们的项目仍然存在问题。然而，在长时间等待最重要的情况下，手头的问题优先于搭建构建时间，因此具有讽刺意味的是：没有得到它所需要的关注。 56 | 57 | 目前没有时间，但希望构建速度更快，我将所有细节都删除，并将它们放入我们团队的 GitHub 存储库中的 issues 中。我回到我正在做的事情，并认为我会在下雨天回到这个问题上。 58 | 59 | 那一天在未来出现了，因为我团队的工程师悄然注意到了。两周后，他花时间调试问题，而没有被提示这样做，并且在我们的构建时间内完成了整整 10 分钟。这让他赢得了团队的感激之情，速度的提升使我们更有成效。 60 | 61 | 如果我囤积了我对这个问题的了解，那自然可能不会发生这种情况。在这种情况下，被动地详细说明一个高影响力的问题，就是激励这个人解决问题所需要的。最重要的是，问题比我决定保留给自己的问题早得多。 62 | 63 | 我确保在团队可以看到它们的地方，提交类似问题的详细信息，例如 GitHub 或者我们的 Trello 板。在我最近与团队沟通的努力中，我已经开始向团队发送简短的季度回顾，以及预览我们最大的项目，还有我们关心他们的原因。每当有时间向我的团队中的某个人提供新任务时，我通常会发现它已经很熟悉了，他们可能已经有了如何处理它的想法。 64 | 65 | 自由和公开地分享有关团队挑战的知识，将有助于团队的整体准备，并以更及时的方式完成工作。而且，你知道吗？我不会错过那些宠物岩石。 66 | 67 | ## 编码更多，更少担心 68 | 69 | 一开始，平衡责任与有效的个人贡献可能会让人无法理解。最重要的是，考虑一下你可以做些什么来投入时间，从而导致力量倍增。通过将您的工作重点放在团队的自主权，所有权和沟通上，我希望您会发现，随着时间的推移，您需要花费更多的时间进行编码，而更少的日常团队开销。 70 | -------------------------------------------------------------------------------- /articles/tech-lead-do.md: -------------------------------------------------------------------------------- 1 | # Tech Lead 做些什么事？ 2 | 3 | 原文链接：[What does a tech lead do?](https://www.bitlog.com/2017/10/12/what-does-a-tech-lead-do/) 4 | 5 | 这是在 Etsy 内部编写的。我被鼓励在我自己的个人博客上发帖，以便人们可以分享。 这些是我的意见，而不是 “Etsy 官方的”。 6 | 7 | ## 写这个的动机 8 | 9 | 在过去的 5 个月里，我一直是 Etsy 搜索体验团队的技术主管。我们的工程经理有一个很好的理念，即在经理和 Tech Lead 之间分配工作。工程经理负责将项目提升到工程师开始工作的程度。Tech Lead 确保一切都在此之后发生。因此，这旨在记录有助于推动 “之后的一切” 的思维方式。 10 | 11 | 拥有一个 Tech Lead 可以帮助我们的团队顺利开展工作。我们已经产生了相当大的总商品销售（Gross Merchandise Sales，GMS）。我们以可预测的时间表发布我们的项目，几乎没有戏剧性。我已经看到这个结构在过去成功了，无论是在 Etsy 还是以前的公司。 12 | 13 | 您可以学习如何成为 Tech Lead。你可以擅长它。有人应该这样做。它也可能是你。这个建议听起来有点奇怪，因为： 14 | 15 | - 这是许多公司的角色，但并不总是官方头衔 16 | - 不是每个团队都有 17 | - 工作很难，而且可能无法识别 18 | - 您不需要被视为 Tech Lead，就可以执行本文档建议的任何操作 19 | 20 | 但是当有一个人设定团队的技术方向时，团队会更有效地运行并更快地传播知识。 21 | 22 | ## Tech Lead 意味着谁？ 23 | 24 | 一位正式或非正式领导 2-7 人项目的工程师。这不适用于大型团队，也不适合领导团队。根据我的经验，8-10 人是通信开销爆炸的拐点。此时，需要花费更多时间在流程和组织上。 25 | 26 | ## Tech Lead 的心态是什么？ 27 | 28 | 这是一系列原则，可以为搜索体验带来良好的结果，或者是完成工作所必需的。 我正在记录我的经验中哪些方面有效。 29 | 30 | ## 更多责任→减少编写代码的时间 31 | 32 | 当我刚从大学毕业时，我在一个计算机视觉研究实验室工作。我认为最重要的是编写大量代码。这很好用。我的老板很高兴，我慢慢得到了更多的责任。但随后经济衰退袭击了军事分包商，该公司陷入了困境。生命快到你了！ 33 | 34 | 所以我加入了 BigCo，再次开始在图腾柱的底部。我专注于编写大量代码，并学会在大型团队中进行编写。这很好用。我慢慢地获得了责任，最终被赋予了运行一个小项目的任务。在此之前，我一直专注于编写大量代码。所以我打算写很多代码，对吧？ 35 | 36 | 错误。两周后，我的经理把我拉到一边说：“你的团队中没有人有任何事可做，因为你没有在三天内组织积压的任务。你为什么整个上午编码？在做其他任何事情之前，你需要确保你的团队顺利运行。“ 37 | 38 | 好的，知道了。 39 | 40 | 所以我每天都会制作日历提醒，专注于为团队做额外的准备工作。当我做这项工作时，我们作为一个三人单位更快地移动。但我可以在我的代码统计数据中看到我开始更多地关注团队。有明显下降。即使我预料到这一点，我也感到内疚！提交和代码行是衡量生产力的非常简单的方法，但当您是 Tech Lead 时，您的首要任务是团队的整体生产力。而你只需要对抗内疚。你还会经历它。你只需要认识到这种感觉并通过它来完成。 41 | 42 | ## 先帮助别人 43 | 44 | 在你向前迈进之前说，你应该解锁你的团队听起来不错，但这在实践中意味着什么呢？ 45 | 46 | 首先，如果你有工作，但有人需要你的帮助，那么你应该先帮助他们。作为一名高级工程师，你的时间是杠杆化 - 花费 30 分钟的时间可以节省别人的时间。这些数字听起来有些偏差，但这也是一个原则背后的原则，即错误会在发现它们之后变得更加昂贵。做事比做重做更便宜。你有机会让你的队友不必重新发现已知的东西，或者让他们不必编写已经写好的东西。一些探索是好的。但总有一个门槛，你应该鼓励队友根据任务设定截止日期。当他们通过时，寻求帮助是最好的举措。这也有助于捕获在编写之前会成为推送问题或生产问题的错误。 47 | 48 | 代码审查也是如此。如果您有技术工作要做，但等待代码审查，则应首先进行代码审查。等待某人审查你的代码是残酷的，特别是如果审查往返很长。如果您坐在上面，工程师将上下文切换到新任务。当他们对代码的记忆很新时，最好做评论。他们将对您的问题提供更快更好的答案，并且能够快速调整他们的拉取请求以准备提交。 49 | 50 | 鼓励将大型更改拆分为多个拉取请求也很重要。在预先讨论项目时，请务必建议如何拆分它。例如，“第一个将添加 API，第二个将数据发送到客户端，第三个将使用数据呈现新组件。” 这使您可以详细检查每个更改，而无需花费数小时审查并重新审查巨大的拉取请求。如果您认为变更风险太大而无法立即提交，因为它太大而您无法理解其所有后果，那么可以请求将其拆分。您应该确信更改不会删除网站。 51 | 52 | 即使采取这种态度，您也不会快速审查所有拉取请求。不可能。例如，我的大多数团队都不在我的时区。我在工作时间之外得到了评论，直到我在 10 分钟的工作中开始工作之前，我不会在电脑上查看它们。 53 | 54 | 我个人认为代码审查和问题是可以中断的。如果我从我们的团队进行代码审查，我将停止我正在做的事情并进行审核。这不适合所有人，因为它是另一种中断类型，老实说，整天打断都很累。随着时间的推移，处理中断对我来说变得更加容易，但是我从几个人那里获得了反馈，但这些反馈并不适合他们。你永远不会擅长它。我不是。不可能。你将变得更好地管理你的纯粹必需品的时间。 55 | 56 | ## 你的大部分时间都花在帮助初级工程师身上 57 | 58 | 一个典型的高级工程师是自我导向的。你可以抛出一个无限制的问题，他们会组织起来。他们有时间需要建立共识。他们将技术工作分解成块，并找出需要回答的问题。他们很少会以负面的方式给你带来惊喜。 59 | 60 | 但是，并非所有人都是高级工程师。您的团队将由初级和高级工程师组成。非常好！初级工程师是一项投资，每个高级工程师都处于这个位置，因为人们投资于他们。没有神奇的算法决定如何在团队中的工程师之间分配时间。但是我注意到一个人越是年轻，我和他们一起度过的时间就越多。 61 | 62 | 这里有一个推论。确保新工程师知道他们有此选项。明确表示与您联系是正常的，并且这样做不会受到惩罚。我记得在我担任初级工程师时害怕向高级工程师询问问题，所以当他们提出前几个问题时，我总是尽力保持友好。如果他们在办公室就亲自过去，并确保他们的问题得到了充分的回答。如果他们消失了一两天，请检查他们。画出你正在谈论的内容，并在谈完后给他们提供论文。 63 | 64 | ## 降压停在这里 65 | 66 | 我的经理曾告诉我，领导者对没有明确所有者的问题负责。根据我的经验，这意味着你应该为许多不合时宜的工作负责，而且往往是不费力的工作，以推动团队前进。 67 | 68 | 问题是 “什么东西应该容易，但很难？”，这是一个很好的启发式方法，可以在哪里花时间。例如，当搜索体验是一个新团队时，推出新功能是痛苦的。我们从来没有以同样的方式踢过功能，我们不知道我们应该测试哪些组，我们（令人不快）让我们的数据科学家感到惊讶，有时我们忘记在测试时为员工启用内容。所以我写了一个文档，逐步解释了我们应该如何引导从概念到A / B测试的功能，再到启动它们或禁用它们的决定。然后，我们的数据科学家在此过程中添加了大量关于何时让她参与的信息。现在推出功能要容易得多，因为我们有一个手册可以做什么。 69 | 70 | 这可能会使图片中的工程经理和/或产品经理感到困惑，因为他们也应该默认负责确保工作完成。但这并不像听起来那么严重。想象一下棒球的流行音乐，一个球落在三个人之间。如果每个人都站着不动并看着它落地，那就不好了。如果你们所有人都试图抓住它们会更好（因为抓住它的几率比没有人尝试的要好）。如果你们三个人有一个处理意外问题的系统，那就最好了。常规 1：1 见面和状态更新是解决此问题的好方法，尤其是在开始时。 71 | 72 | ## 利用传播知识的作用 73 | 74 | 当团队拥有 Tech Lead 时，他们最终成为活动的中心枢纽。他们将讨论团队中每个项目的设计和审核代码。 75 | 76 | 如果您阅读了团队在拉取请求中发出的所有代码，您将以加速的速度学习。您将很快深入了解团队的代码库。你会看到有效的技术。您可以询问有关不清楚的事情的问题。如果您还在团队之外进行代码审查，您将了解其他开发人员的新技术，库和技术。这使您能够更有效地为您的团队提供从整个公司学到的知识。 77 | 78 | 由于您处于这个位置，因此您可以通过团队快速定义和传播最佳实践。一个很好的资源，提供一些代码审查的建议是前 Etsy 员工 Amy Ciavolino 的演示。这是一个很好的团队导向的风格。随意根据自己的风格调整零件。如果你和我一起工作，你会发现这有时与我的不同。例如，如果我有 “您的想法？” 反馈，我更喜欢面对面/ Slack / Vidyo对话。这通常以头脑风暴结束，并创造出比我们任何一个人想象的更好的第三种方法。但这个演讲是一个很好的开始，也是一个强有力的指导方针。 79 | 80 | ## 日常工作 81 | 82 | 正如我上面提到的，Tech lEAD 的大部分工作都是中断驱动的。这对团队有利，但它增加了安排自己时间的挑战。在一个轻松的日子里，我将花费一个小时做科技领导工作。但是在一个沉重的日子里，我会得到大约一个小时的时间，而不会因为中断而被吃掉。 83 | 84 | 因此，很难估计你什么时候会完成一些事情。我和我们的工程经理一起制定了一个运作良好的系统。我只接受了小型，非阻塞或没有截止日期的项目。这对于试图获得最少量流程的团队来说效果很好。这将是对估计超组织的团队的重大调整。 85 | 86 | 你需要对付随之而来的内疚。你的工作不是要编写最多的代码。你的工作是让团队中的人看起来很好。如果需要做一些重要的事情，而你没有时间去做，你应该委托它。这将有助于整个团队向前发展。 87 | 88 | 当我决定做什么时，我会大致优先做事： 89 | 90 | **内环**： 91 | 92 | - 回答任何 Slack ping 93 | - 在我的团队频道中帮助任何需要它的人 94 | - 做任何待定的代码审查 95 | - 确保团队中的每个人都有足够的工作在一周的其余时间 96 | - 做任何流程/组织工作 97 | - 项目工作 98 | 99 | **一天一次**： 100 | 101 | - 检查性能图表。调查（或委托）主要回归到我们可能已经影响的事情。 102 | - 检查所有 A/B实验。对于新实验，请查找存储错误，性能问题（或意外收益，更可能是错误）等。 103 | 104 | **每周一次**： 105 | 106 | - 查看 bug 积压，确保一个主要错误没有滑过裂缝。 107 | 108 | ## 这对工程师经理意味着什么 109 | 110 | 许多团队没有 Tech Lead，但每个团队都需要技术领导才能有效运作。这是工程管理人员的行动呼吁，以检查他们团队的动态。你团队中谁在执行这项工作？他们是否因此获得奖励？特别是，寻找代表性不足的群体的成员，由于无意识的偏见，他们可能因编写较少的代码而受到惩罚。 111 | 112 | 想象一下工程师团队。上面列出的职责可能属于以下类别之一： 113 | 114 | **指定的技术负责人处理工作**。如果您的团队属于这一类，那就太好了！确保履行这些职责的工程师或工程师得到认可。 115 | 116 | **除了他们现有的工作之外，有人对此负责**。根据工程经理对领导工作的看法，这对工程师来说可能是一种祝福或诅咒。他们的工作可能会受到赞赏。但也有可能人们只是目睹他们的编码输出下降，而没有认识到推动团队前进的工作。如果你的团队中＃#2 大部分都是正确的（技术主管没有正式化，而且有些工程师负责推动团队前进，而牺牲自己的 IC 工作），那就问问自己：他们是否正在接受评判只是为了他们的工作？或者他们是否因为他们启用的所有传递性工作而获得奖励？ 117 | 118 | **有些人会这样做，但他们经常被忽视**。这个类别的工作仍然有效，但有系统的阻截者。如果没有人拥有代码审核，则需要很长时间才能审核代码。如果没有人拥有代码质量，你的代码库将成为瑞士未发布的破碎标志。 119 | 120 | **没有人对他们负责**。在这个类别中，有些事情根本无法完成。例如，如果没有人默认负责成为代表性不足群体的盟友，那么很可能只会将其丢弃在场内。这种情况是分形的：如果我们将球放在小组级别上，我们就会在个人和公司范围内放弃球。 121 | 122 | ## 结论 123 | 124 | 为您的团队指定 Tech Lead 是有价值的。他们将创建和推广最佳实践，成为团队中的重点人物，并消除工程障碍。此外，这项工作可能已经由某人完成，因此正式承认承担此责任的人员非常重要。 125 | 126 | 正式承担这一角色也有很多价值。它允许您利用您的时间推动组织向前发展，并使您能够影响整个团队的工程。 127 | 128 | 如果您正在接受这项工作，并且您不是正式的 Tech Lead，那么您应该与您的经理讨论此事。如果您想成为 Tech Lead，请与您的经理（或 Tech Lead，如果您有一位！）谈谈您可以承担的任何责任。 129 | -------------------------------------------------------------------------------- /articles/tech-lead-good-for.md: -------------------------------------------------------------------------------- 1 | # Tech Lead：他们有什么好处？ 2 | 3 | 原文链接：[Tech Leads: What Are They Good For?](https://medium.com/myplanet-musings/tech-leads-what-are-they-good-for-165108411be) 4 | 5 | 在上周，我们的一位高级开发人员在办公室里分享了这篇文章：[We don't need a Tech Lead](http://vvgomes.com/we-dont-need-tech-leads/)。 6 | 7 | 文章中，Vinicius Gomes 认为 “Tech Lead” 的想法是有问题的。他说，我们的目标应该是建立一个，能够让所有团队成员以更加基于共识和平等的方式，来填补必要角色的结构，而不是一个人执行 Tech Lead 的诸多工作。 8 | 9 | 分享这篇文章的 Myplanet 开发人员 Shanly Suepaul，将其作为 “检查这个” （check this out）类型的阅读而提供的。这也是我们的团队一直在做的事情。 10 | 11 | 通常当某人以这种方式分享内容时，会发生一些聊天，可能是 “读起来很棒！” 或者 “谢谢！” 这样的话语。 12 | 13 | 这不是这次发生的事情。 14 | 15 | 一篇文章引发的谈话数量跨越了几天，并在我们的团队聊天频道中进行了多次多段回复。（如果你认识一个开发人员，那么写一段写作就可以说明它是一个**大**的话题）。 16 | 17 | 所有这一切都在说，我们本周要写的这篇文章被废弃了，因为这个话题占据了我们的脑海。所以让我们深入它吧。 18 | 19 | ## 什么是 Tech Lead？ 20 | 21 | > “有些人会告诉你 Tech Lead，是从不编写代码的软件架构师。但是，其他/她人会坚持认为 Tech Lead 可能曾经是软件开发人员的中层管理人员。 还有一些人会说 Tech Lead 只是公司最好或最资深的程序员，他们只是纯粹的产出质量的领导者。“ ——Jeff Carouth 22 | 23 | 在我们讨论拥有 Tech Lead 的价值之前，需要确定一下 Tech Lead 的职能。 24 | 25 | 传统上，Tech Lead（或者Tech Manager，首席平台工程师，开发主管或您喜欢的任何 title）负责监督和交付。他们是开发链中的最终决定权，并且在遇到麻烦时负责解决。 26 | 27 | 或者，至少，这主要是他/她们所做的。 28 | 29 | 人们倾向于不同意这个角色的是在后续职能，责任和职责上。 30 | 31 | 为 InfoQ 撰稿的 Amr Noaman 表示，Tech Lead —— 无论他们在组织中实际获得的头衔，都有一个首要责任。“这个人在所有组织中的主要和共同责任是**产品交付**。” 32 | 33 | 但 Noaman 也承认并不是所有 Tech Lead 都能做到。 34 | 35 | “产品交付责任的范围有所不同，” Noaman 说。 “我的职责可能包括设计和开发，以及与客户合作、团队运营、向高级管理层报告和战略产品管理！” 36 | 37 | 试图确定技术主管角色的确切范围，是需要一些认真的努力，并且像角色本身的标题一样，因组织而异。 38 | 39 | 许多新的 Tech Lead 发现自己处于管理角色，而其他人则成为技术严谨的支持者。与客户联络、评估代码结构、促进团队沟通 - 这些都属于 Tech Lead 的工作内容（原文是：操舵室（wheelhouse））。 40 | 41 | 找到技术主管的一刀切定义可能是不可能的。但是，由于我们今天需要一个有效的起点，因此 Jeff Carouth 的描述是我们所遵行的： 42 | 43 | > “Tech Lead 是指具有扎实开发背景的人，并且已经证明了有效沟通的能力。” 44 | 45 | 这个定义有两个原因： 46 | 47 | 首先，在 Tech Lead 的所有可能定义中，强大且不断发展的技术背景是关键。而毫无疑问，Tech Lead 应该有严格的技术作为支持。 48 | 49 | 其次，它突出了沟通技巧。无论您在 Tech Lead 的工作中添加什么功能，沟通技巧都是核心。 50 | 51 | 沟通，也是我们关于 Tech Lead 主题的内部辩论真正起飞的关键所在。 52 | 53 | ## 技术主管给予...... 54 | 55 | 也许支持 Tech Lead 的最一致的论点是，拥有一个**稳定的、指导性的沟通者**。 56 | 57 | 对于任何团队运作良好，沟通是关键。技术团队的沟通包括几个方面，所有这些都可以由一个强大的，沟通的领导者帮助。 58 | 59 | 让我们来看看：Tech Lead 如何通过清晰的沟通来影响团队的运作。 60 | 61 | ### 1-提供上下文 62 | 63 | Tech Lead 的一部分职责是向团队传达项目的目标和方法。Tech Lead 确保每个人都知道该做什么，如何做，并且有能够做到这一点的工具，以确保满足期望。 64 | 65 | 提供明确的指导和成功之路，可能是技术主管最重要的工作。并分享有关为何选择此路径的洞察力，并提供有关如何遵循此路径的建议和指导，这需要强大的沟通技巧。 66 | 67 | Myplanet 的 Drupal Practice Lead 的 Erin Marchak 比较了 Tech Lead 与在工作现场的总承包商角色。“水管工和电工在开始工作时不应该担心浴室的布局 - 这是 GC 的工作，它也已经与建筑师/制造商确认了。” 68 | 69 | 对她来说，Tech Lead 更像是一个 “在职” 的角色，而不是 “最终决定” 的角色。“我有责任确保在团队开始工作之前，确保我们完成所有技术要求，并明确定义任何技术不确定性，” 她说。 70 | 71 | ### 2-促进讨论 72 | 73 | Tech Lead 的责任还在于促进团队成员之间的沟通。包括可能被淹没的声音，使那些倾向于占主导地位的声音安静下来，并为未在讨论中代表的团体发声，都属于技术主管的职责范围。 74 | 75 | Myplanet 开发人员 Erick Cardenas Mendez 指出，经常引用的 “集体决策” 理想通常无法实现。“集体决策要求团队中的每个人都善于沟通（分享和倾听）。但是通常情况下，并非如此。“ 76 | 77 | 强大的 Tech Lead 可以简化技术团队成员之间的沟通。它使他们能够分享想法，提出问题，并改善整个团队的知识基础。 78 | 79 | “一位优秀的领导者将确保人们真正参与进来，” Erick 说。 80 | 81 | ### 3-取得所有权 82 | 83 | 一个强大的 Tech Lead 也将承担一定的责任。单边决策是不可取的。但如果每个人都试图取得所有权，那么项目就会停滞不前，没有人对结果负责。 84 | 85 | Tech Lead 可以 - 在必要时 - 采取决策制定并与之一起运行。能够在没有羽毛的情况下，要做到这一点需要一个稳定的，引导性的沟通者和团队的信任。 86 | 87 | 另一位 Myplanet 开发人员 Jerry Low 倡导旨在达成共识的团队讨论框架。但他也认识到，当讨论达成陈旧情结时，需要就问题达成最终决定。 88 | 89 | “当然，我们没有完美的团队，”他说，“我发现每个 Tech Lead 的角色都会随着团队之间以及项目之间的变化而变化。但是当事情仍然含糊不清时，我喜欢打破平局的想法（在团队讨论之后）。“ 90 | 91 | 所有这一切都在说 Tech Leads，当他们是强大的沟通者时，可以缓解技术团队中许多常见问题。 92 | 93 | 他们可以减轻团队内部的沟通。他们可以解决技术决策中的僵局。他们可以提供指导并为工作创建清晰的技术路线图。他们甚至可以与客户进行联络，从而使团队从耗时的非技术工作中解脱出来。 94 | 95 | 所有这些都是必不可少的功能。所有这些都可以得到技术主管的帮助。但这些都不需要技术主管。 96 | 97 | 这些论点中没有一个概述，为什么所有这些不同的和重要的责任必须落到一个人身上。 98 | 99 | ## ......而 Tech Lead 带走了 100 | 101 | 这些也是 Shanly分享这篇文章的最初原由 - 以及他不愿意支持 Tech Lead 的概念。 102 | 103 | “鼓励沟通是团队成员的重要角色。但是，如果你让一个人担任这些角色的超负荷，那么我的经验就是团队承担了领导者的优点和缺点。“ 104 | 105 | 他所倡导的是更均衡的责任分担。 106 | 107 | 是的，需要一位能够帮助促进健康，平衡的讨论的主持人或调解员。是的，需要一位强大的技术专家来帮助指导计划，并在出现问题时回答技术架构问题。是的，当无法达成共识时，需要做出决定。 108 | 109 | 然而，让一个人负责所有这些事情（以及更多）不仅会冒着耗尽和压倒个人的风险，而且还会阻碍合作和面对敏捷实践的飞行。 110 | 111 | “为什么我们依靠层次结构（隐式或显式）在团队中做出决策？敏捷团队实施咨询决策。作为练习的一部分，我们培养同理心、情商和倾听技巧，使人们能够被听到，” Shanly说。 112 | 113 | 他认为，通过为一个人分配 Tech Lead 的头衔，我们正在采取可能阻碍我们成功的结论的捷径。 114 | 115 | 这就是我们内部辩论的所在：职责是必要的，但至于谁完全履行这些职责......嗯，这是一个更强硬的呼吁。 116 | 117 | ## To Tech Lead or Not To Tech Lead? 118 | 119 | 理想情况下，团队划分和征服。人们根据需要承担不同的角色，并分担责任。但是，即使是在功能强大，长期运作良好的团队中，理想世界也很难获得。 120 | 121 | Pat Kua 很好地总结了这场冲突：“即使存在完美的条件......也不需要花费太多时间来破坏这种微妙的平衡。有时候只需要一个新人加入团队，一个人离开或者一些压力很大的危急情况，这会使团队进入一个争论仍在继续的状态。“ 122 | 123 | 可以肯定，这不是一个理想的场景。那么答案是什么？ 124 | 125 | 您是否分配了 title 及其随附的所有内容，为一个人提供了一定程度的权限和一系列责任，这与基于群体的决策制定的理想情景背道而驰？或者你是否总是让一个团体进行自我调节，并希望他们找到一个平衡和平衡，以实现高水平的运作，同时为许多成员提供分享负荷的渠道？ 126 | 127 | 在我们自己的组织中，我们有 Tech Lead 类型职位的人员。但我们倾向于不让一个上尉（captain）指导船只 - 我们赞成建立共识和积极、敏捷、团队授权的领导。 128 | 129 | 最后，通过我们自己的技术负责人，技术副总监 Everett Zufelt 找到我们的解决方案： 130 | 131 | “我真的不认为这是一个适合所有问题或解决方案。在不同的环境中，Tech Lead 可以是不同的东西。有些团队需要断路器，有些则不需要；有些团队对彼此更有信任，有些团队仍在建立信任；一些团队拥有丰富的应用程序架构经验，有些还在构建经验。它可以使生活更难以推理，但我认为 Tech Lead 的技能是阅读团队，并以团队需要的方式服务，基于技术主管发现他或她自己的背景“。 132 | 133 | 也许这意味着成为清晰，强大的指导性声音。也许这意味着退后一步，让每个声音在不同时间都能发挥领导作用。 134 | 135 | Tech Lead 作为一个单一的，具体的功能有其潜在的缺陷，但当一个清晰的沟通者可以阅读团队并提供正确的支持时，我们只有一个回应： 136 | 137 | Lead on. 138 | -------------------------------------------------------------------------------- /articles/tech-lead-main-skills.md: -------------------------------------------------------------------------------- 1 | # Tech Lead 应具备的主要技能 2 | 3 | 原文链接：[Main Skills a Tech Leader Should Have](https://blog.makingsense.com/2017/02/main-skills-a-tech-leader-should-have/) 4 | 5 | 6 | 我已经在科技行业工作了大约 10 年，所以我亲眼目睹、并亲身体验了：当开发人员成为 Tech Lead 时所发生的变化。没有什么能让你为这个新角色做好准备。突然之间，您将负责一个将提供技术和非技术技能的专家团队。您需要管理这两种类型的技能，以促进您领导的项目的最佳执行。 7 | 8 | 在软件开发中，通常会找到多学科团队，其中每个成员都有能力实现共同目标。至少，这就是我们在 Making Sense 中的工作方式。我们这样做，因此我们可以为您的项目提供 360º 视野。为了取得成功，团队需要有人来协调他们，这就是技术领导者的角色所在。Tech Lead 也不仅仅是领导团队。他或她也将编码，与团队中的其他人一起。 9 | 10 | ## 什么是 Leader？ 11 | 12 | 为了能够有效领导团队，领导者必须致力于他们的工作。这涉及理解并与公司的愿景和使命，以及项目的目标保持一致。这是与团队和客户建立良好信任关系的基础。 13 | 14 | 此外，一位优秀的领导者还必须注意以下概念： 15 | 16 | ### 沟通是一个关键因素 17 | 18 | 我们需要能够与团队进行有效沟通，避免可能出现的任何混淆，并可能导致我们应该提供的延迟。 19 | 20 | 我们的合作伙伴也是如此。我们必须始终传达团队决定采取的行动或路径，强调团队作为一个整体。如果必须做出新的决定，我们必须在内部与团队进行分析，然后才能为客户提供可能的解决方案。 21 | 22 | ### 领导者必须是一个好的观察者 23 | 24 | 领导者必须认识到自己的优点和缺点。他还必须了解团队成员中的这些主要因素。重要的是检测美德，以便你可以加强它们，就像在你有弱点的地方改善一样重要。 25 | 26 | 这将为您的团队提供所需的附加价值。团队成员可以增加一致性，并改善其缺陷，相互合作以完成成功的产品。这是让他们成长为专业人士的一步。 27 | 28 | 观察中的另一个观点与团队精神密切相关。通常在项目中，背景在全局层面上发生变化。当这些变化成为习惯或意外时，它们通常会影响团队。对于那些消极的（例如：设备减少，工作环境的重大转变等）尤其如此。 29 | 30 | 出于这个原因，我们必须谨慎并观察团队如何响应这些变化，并尝试找到正确的沟通方式。对团队诚实。总是解释发生了什么，并试图证明你可以从变化中学习。一个团队，即使他们处于 “敏捷” 框架，也必须具备适应能力。 31 | 32 | ### 了解如何应对压力非常重要 33 | 34 | 这很重要，需要绝对关注项目，因为当我们领导一个团队时，压力就会成倍增加。我们必须防止压力阻碍团队，我们必须学会如何处理顾客焦虑，这样才不会影响团队绩效。 35 | 36 | ### 领导者必须创造激励 37 | 38 | 在谈论长期项目时，重复性工作的单调会导致成员的动摇，我们必须确保团队保持灵感。我们应该能够以新的挑战鼓励他们。我们必须利用我们所观察到的，根据个人需求寻求挑战。 39 | 40 | > 我们必须确保团队保持灵感。我们应该能够以新的挑战鼓励他们。 41 | 42 | ### 领导者必须鼓励团队合作 43 | 44 | 领导者必须完成团队提出的最佳决策，因此学习如何倾听他们是一个好习惯。我们必须依靠成员之间存在的知识和委派工作，以产生信心并承担更大的责任。证明领导者的角色也可以由另一位成员承担；这是鼓励每个人的另一种方式，并证明如果你作为一个团队工作，目标会更快地实现。 45 | 46 | ## 作为里程碑的经验 47 | 48 | 在我担任技术主管期间，我了解到领导力的基本关键是你带来的专业和个人经验。为了协调团队的有效性，我们必须具备技术知识，因为我们必须成为团队成员的参考，指导他们的专业发展。这是我们的责任。 49 | 50 | 这是我学到的其他内容： 51 | 52 | - 我们不是老板。成为领导者，并不意味着拥有更多权力或超越其他人。 53 | - 我们必须指导开发人员找到解决方案的正确和最佳途径。 54 | - 我们并不总能得到答案。是的，我们可能是错的，我们是人类。 55 | 56 | 成为领导者是一个进化过程，而不是一系列个人课程。这是一个没有开始，没有结束，但是经常性需求的过程：教育，对所学知识的反思，承担风险和犯错，以及完全掌握任务。对于所有未来和现在的技术领导者，我希望这已经阐明了成为开发行业技术领导者意味着什么。谢谢阅读！ 57 | -------------------------------------------------------------------------------- /articles/tech-lead-new-project-checklists.md: -------------------------------------------------------------------------------- 1 | # Tech Lead 的新项目检查清单 2 | 3 | 4 | 这些是关于 Tech Lead 需要做什么，以及何时到达新项目的会议的笔记。智慧来自于 Thoughtworks 的 @JimBarritt - 我只是个搬运工。 5 | 6 | 请注意，此列表既适用于 Tech Lead 来到已有的项目，也适用于整个团队/产品是新项目的项目。 7 | 8 | 前两个显然是 “两个最可能的死亡或受伤原因”： 9 | 10 | 1). 基础设施 11 | 12 | - 生产环境在哪里？这是最重要的一个！它是什么样子的？什么时候准备好了？（开发环境是产品后的事后补充） 13 | - 我们怎么样才能上线？ 计划是什么？ 14 | - 负载均衡 15 | - 防火墙 16 | - 证书 17 | 18 | 2). 第三方 19 | 20 | - 集成 21 | - 如果您无法控制的环境是混乱的，那么确保您自己的环境超级有序，规范、流畅、自动化，具有良好的范围规划等等更为重要。 22 | 23 | 3). 找到有权势的人 24 | 25 | - 找到所有可以拒绝的人，持有钱包的人/可以签署预算，以及可以说 “是的，你做得很好” 并且了解他们的人。例如： 26 | - 架构师 27 | - 掌控数据保护的人（当心 “组织性疤痕组织（organisational scar tissue，即过度反应）”） 28 | - 在公共部门，SIRO（高级信息风险官） 29 | 30 | 4). 查找团队工作的所有顶级文档，阅读并理解 31 | 32 | 5). 预算和价值主张是什么？ 33 | 34 | - 它的定义有多好？ 你为什么要做这项工作？ 愿景是什么？ 人们明白吗？ 35 | - 一旦你找到这个信息，就要真的重复一遍 36 | - 如果有一些假设对整个成功至关重要，请在每个 showcase 开始时不断重复 37 | 38 | 6). 尝试与团队中的每个人一对一沟通 39 | 40 | - 尝试了解他们的目标是什么，特别是在项目上 - 并且对自己的目标保持透明。例如，如果您想要远离某些区域，请找到热衷于移动到这些区域的人 41 | - 他们的主要痛点和阻滞点是什么？ 42 | 43 | 7). 与项目经理交朋友，了解他们如何管理预算。 44 | 45 | - 这有助于建立信任关系 46 | - 阅读 Chris Matts 的 [Real Options](https://theitriskmanager.wordpress.com/the-real-option-resource/)（实物期权） 47 | - 阅读 Bjarte Bogsnes 的 [超出预算](https://bbrt.org/bjarte-bogsnes/?gclid=CJvs4LiAyNUCFUK7GwodNNgFDQ) 48 | - 布雷特·安斯利在 [2016 年的敏捷大会上](https://www.youtube.com/watch?v=M72kFSilPCE)，做了一次关于金钱和团队以及如何进行核算的伟大演讲。 49 | - 阅读 Gregor Hohpe 的 [一个架构师对 IT 转型需要了解的 37 件事](https://leanpub.com/37things) 50 | - 不要试图成为金融领域神秘细节的专家，但要了解基本要素：资金是如何流动的，不同类型的工作是什么，运营支出和资本支出之间的区别是什么？ 51 | 52 | 8). 如果有多个团队，找到并了解其他/她 Tech Lead 53 | 54 | 9). 了解交付三位一体的重要性：交付经理、产品负责人、技术主管 55 | 56 | - 这三个领域之间往往存在紧张关系 57 | - 与这些人建立关系 58 | - 所有三个都应该出现在所有决策中，否则它可能会出现偏差 59 | - Tech Lead 有时会在这些关系中略微侧重 60 | 61 | 62 | 10). Backlog：确保范围结构清晰 63 | 64 | - 使用故事树和 backlog 层次结构 65 | - 人们可以在更高水平的分组/规模上抗争 66 | - 你得到直升机上，俯视你正在建造的东西 67 | 68 | 11). 代码： 69 | 70 | - 确保您可以访问它 71 | - 保持与它的连接 72 | - 让几个开发者为您提供导游 73 | - 如果让更新的团队成员做这一个，可能会特别有启发性 74 | - 您需要能够可视化整个代码库（整体架构） 75 | - 第一次从头开始运行它有多难？ 76 | 77 | 12). 疼点和阻塞者有哪些？ 78 | 79 | - 项目经理是谈论这个问题的最好人选 80 | 81 | 13). 跨功能需求 82 | 83 | - 弹性和可扩展性 84 | - 是否会因负载而坍塌 85 | - 安全 86 | - 有人会闯入吗？ 87 | - 自动化 88 | - 尽管自动化很棒，但不要因为认为：必须在一开始就设置好所有内容，因此而陷入困境。 89 | - 不一定优先考虑自动化 - 但要确定实际交付内容的优先级 90 | - 一旦你有了一些东西，并运行和迭代，这一切都很好 - 但你怎么打破那张初始的空白纸？ 91 | - 你想要 pipeline 等，但作为一个原则，也许在项目开始时就有不同的物理定律 92 | - 不要花费六个星期，来构建一个没有实际可交付成果的 pipeline - 确保你有一些迭代的东西 93 | - 想象一下你正在构建的这个产品......想象一下你没有使用任何软件。然后把电脑带进去，问为什么 - 它会给你带来什么？哪里可以给你最大的价值？不要添加你不需要的东西 94 | - 想象一下，从业务角度来说，这是一个行走的骨架 - 例如，通过物理的方式来发布威士忌（delivering whisky）。您的部署步行骨架可以在顶部 - 只在您需要时自动执行某些操作 95 | - 这虽然是一种微妙的艺术 - 你不想最终得到大量的技术债 96 | - 您可以花费大量时间，来制定概念而无需使用该功能。 97 | - 可以同时使用技术 alpha - 查看跨功能需求等 98 | - 尝试架构的行走骨架 - “可伸缩模型” 99 | 100 | 14). 作为 Tech Lead ，这个项目最让你害怕的是什么？ 101 | 102 | - 做一个x轴上的时间图和不确定性的云。如果云真的很近，并且有大量的闪电......请注意它！ 103 | - 这部分是关于风险管理 104 | 105 | -------------------------------------------------------------------------------- /articles/tech-lead-or-tech-lead.md: -------------------------------------------------------------------------------- 1 | # 要 Tech Lead 还是不要 Tech Lead 2 | 3 | 原文链接：[https://www.nikosraptis.com/single-post/2017/01/21/Tech-Lead-or-no-Tech-Lead](https://www.nikosraptis.com/single-post/2017/01/21/Tech-Lead-or-no-Tech-Lead) 4 | 5 | ## 什么是 Tech Lead？ 6 | 7 | “领导一个开发团队并非易事。一个高效的 Tech Lead 与开发团队建立技术愿景，并与开发人员合作将其变为现实。在这一路上，技术主管承担其他角色可能具有的特征，例如 团队负责人，架构师或软件工程经理，但他们仍然亲自动手编写代码。“ 8 | 9 | 资料来源：https://www.thekua.com/atwork/2014/11/the-definition-of-a-tech-lead/ 10 | 11 | 我相信上面的文章很好地解释了 Tech Lead 是什么。我可以提到一些更多的细节，比如代码审查员或者负责合并到生产等。所有这些以及更多其他的工作内容，使得 Tech Lead 角色成为团队内外人员的参考。 12 | 13 | ## 编码怎么样？ 14 | 15 | 技术领导通常至少编码30％的时间，因为 16 | 17 | - a）通常他们擅长 18 | - b）他们的代码风格（应该）是其他人遵循的一个例子。 19 | 20 | 他们不能 100％ 编码的原因是：他们必须在设计、思考和分析解决方案的更大领域方面迈出一步，并为其他领域做好准备。 21 |   22 | 有时代码而不是代码，它们会生成文档和图表，这些文档和图表将成为其他开发人员的一种要求，并且它们还提供有关技术问题，以及如何解决这些问题的有用信息。 23 | 24 | 25 | ## Scrum 团队怎么样？ 26 | 27 | 让我们记住 Scrum 指南所说的内容。 28 | 29 | “开发团队具有以下特点： 30 | 31 | - 他们是自组织的。没有人（甚至不是Scrum Master）告诉开发团队：如何将产品的 Backlog 转换为潜在可释放功能的功能; 32 | - 开发团队是跨职能的，具有创建产品增量所需的所有技能； 33 | - 除了开发人员之外，Scrum 不会识别开发团队成员的任何称号（title)，无论该人员正在执行哪些工作；这条规定没有例外； 34 | - Scrum 不会识别开发团队中的任何子团队，无论需要解决哪些特定领域，如测试或业务分析；这条规定没有例外；和， 35 | - 个人的开发成员可能拥有专业技能和重点领域，但问责制属于整个开发团队“ 36 | 37 | 资料来源：http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf 38 | 39 | 我有意强调了这两个要点，因为它们似乎提出了这些问题： 40 | 41 | - **a). Tech Lead 是 Scrum 无法识别的称号，如果是这样的话会是什么？** 42 | - **b). 这个角色可以由具有一些广泛技术知识的高级开发人员中取代吗？** 43 | 44 | 显然它是一个称号，而 Scrum 不承认它。但是，让我们看看在每种情况下哪些是优点和缺点。 45 | 46 | ## 创建具有官方 Tech Lead 角色的团队的优点和风险。 47 | 48 | 有时当 Scrum 团队形成时，成员技能就不一样了。这导致一个简单的管理决策，给高级开发人员提供 Tech Lead 头衔。这有一些优点和风险的。 49 | 50 | 优点： 51 | 52 | - 大多数技术决策都来自这个人，没有太多争议。这将导致更快的结果。 53 | - 人们会感到更加宽慰，他们不必采取艰难的技术决策 54 | - 团队之外的人使用这个人作为参考点，沟通渠道较小，因此对他们来说更好（至少他们是什么东西） 55 | - 通常，如果这个人“真的”是一个拥有广泛技术知识的优秀开发人员，那么将会产生良好的技术解决方案 56 | 57 | 风险： 58 | 59 | - 其他开发者可能不同意 Tech Lead 的建议，但由于他拥有头衔，他们犹豫不决地说出自己的想法 60 | - 人们可以保持被动模式，等待他们如何实施某些事情的指示 61 | - 如果缺席，团队无法轻松前进 62 | - 结果的责任可被视为只有 Tech Lead 才有的东西 63 | - 可以减少 “团队” 精神，并导致经理-开发人员架构 64 | - 如果你愿意，以后很难改变心态 65 | 66 | ## 在没有官方 Tech Lead 角色的情况下，创建团队的优点和风险。 67 | 68 | 另一方面，Scrum 没有发现任何角色。这意味着团队可以在没有 Tech Lead 角色的情况下开始。让我们看看哪些是优点和风险。 69 | 70 | 优点： 71 | 72 | - 团队成员可能会更自在地谈论技术问题和决策。 73 | - 引导有凝聚力的决策，因此团队成员共同承担责任。 74 | - 可能会导致更积极的人采取主动并建议替代方案。 75 | - 可以增加 “团队” 精神 76 | 77 | 风险： 78 | 79 | - 人们可能会对他们做出的决定感到不安全，所以他们开始隐藏在“后台” 80 | - 由于分歧导致决策缓慢 81 | - 如果他们缺少高级软件开发人员，可能会产生技术债务的决策 82 | 83 | ## 团队中出现了一位 Tech Lead 呢？ 84 | 85 | 这就是大多数时候，当你创建一个没有任何成员的官方 Tech Lead 角色的团队时，会发生这种情况。你只需要有一两个高级人员，可能在一段时间后，其他开发人员，将开始更容易地听取他们关于技术决策的建议。 86 | 87 | 88 | 这也很好，因为标题大部分时间都是团队中提到风险的原因，这个风险始于官方角色。可能一个人从团队内部出现，从未获得正式的头衔，但他的行为非常接近这个角色所承担的责任。不同之处在于她不会承担所有这些责任，这将是好事，因为它可能“迫使”其他团队成员采取主动。 89 |   90 | 91 | ## 如果事情没有按计划进行怎么办？ 92 | 93 | 这是你需要敏捷教练（或scrum master）的另一个原因。因为大多数时候事情往往不顺利，敏捷教练必须在那里提高敏捷世界中最佳实践的意识。 94 | 95 | 敏捷教练必须保持警惕，注意团队中的行为，使他们远离敏捷价值观。她必须立即采取行动指导人们，并试图明确希望的心态。 96 | -------------------------------------------------------------------------------- /articles/tech-lead-role-responsibilities.md: -------------------------------------------------------------------------------- 1 | # Tech Lead 的角色和责任 2 | 3 | 软件开发是一个漫长的过程，涉及到诸多的人，他们完全成功地完成了整个过程。软件开发过程由初高级开发人员、团队架构师、团队负责人、Tech Lead和工程经理。这些只是团队成员中的一小部分; 实际的清单很长。而据说 Tech Lead 发挥了重要作用。 4 | 5 | Tech Lead 的名称是全权负责带领开发团队。Tech Lead 的任务并不容易。他们必须领导一个团队。Tech Lead 是实际创建技术愿景的人，在团队的帮助下将其变为现实。Tech Lead 有时也必须担任架构师软件、团队负责人或软件工程师经理。除此之外，所有 Tech Lead 还必须与船上的每个人保持联系。 6 | 7 | 技术主管有很大的责任，基本上分为两类，如下所述： 8 | 9 | ## 项目责任 10 | 11 | - 承担整个项目的责任。 12 | - 仔细分析项目，并纠正过程中发现的错误。 13 | - 持续分析过程，以满足系统范围的要求。 14 | - 在了解了要求和设计之后，开发详细的设计架构。 15 | - 实施项目的最佳实践和编码标准。 16 | - 持续询问同伴的评论和反馈。 17 | - 以准确和详细的报告形式，报告所有每周任务。 18 | - 要检查整个系统，请对整个系统进行测试和集成测试。 19 | - 致力于在项目层面，与 PM 确定项目风险和规划缓解措施。 20 | - Tech Lead 应该积极主动，同时对惊喜做出反应，并且应该有相同的书面解释。 21 | - Tech Lead 还必须协助和指导项目负责人/PM/BA 进行项目协调。 22 | - 为了确保团队按照列出的程序工作，Tech Lead 应该进行 FIR-流程检查。 23 | - Tech Lead 还应该不断提高团队的生产力，以减少另一端的浪费。 24 | - Tech Lead 应该激励所有其他团队成员，所有成员都看到的领导者。 25 | 26 | ## 通用责任 27 | 28 | - Tech Lead 应该足够灵活，能够适应不断变化的工作环境。 29 | - 应仔细分析所有工作的细节。 30 | - Tech Lead 将是团队与管理层之间的接口。 31 | - 重要的是要可靠，但是也要公平。承认你的错误也同样重要。 32 | - 为了成功领导团队，为团队设定目标和期望非常重要。 33 | - 对设计团队也要有足够的设计知识。 34 | - 遵守所有项目和公司指导方针和标准，并确保团队成员也要这样做。 35 | - 通过及时交付可交付成果，来履行所有承诺。 36 | - 维护客户下（account，公司层级）的时间，并定期报告自己的工作。 37 | - 确保公平的任务分配，根据员工的技能和个人喜好为人员分配任务。 38 | - 不断激励和鼓励团队发挥最大作用，特别是在高目标压力的时候。 39 | - 让自己完全了解所有技术，尤其是与正在构建的软件或应用程序相关的技术。 40 | - 与团队分享成功与失败。 41 | -------------------------------------------------------------------------------- /articles/tech-lead-survival-guide.md: -------------------------------------------------------------------------------- 1 | # Tech Lead 生存指南 2 | 3 | 原文链接：[Tech Lead Survival Guide](https://medium.com/@ann_lewis/tech-lead-survival-guide-aeee065fe0f5) 4 | 5 | 3 年前，当我第一次在 Moveon 担任首席技术官时，我立刻被淹没了：在我第一天登录的几个小时内，我收到了 100 封未读的电子邮件，一种全新的、完全远程的组织文化，以便找出并导航，我陷入了一个高风险平台和数据迁移的过程中，而我还没有任何背景或历史，我继承了一个无文件记录的预算和遗留代码库，我的任务是雇佣一个团队，建立一个数据仓库，并弄清楚 “我们应该如何处理这个网站”。 6 | 7 | 或多或少，我坐在我的座位上，融入了英特尔的收集模式-与每个人交谈，制定组织结构，制定系统和结构，以及我继承的期望。我参与了一些项目，包括运行招聘流程、构建数据仓库、共同领导正在进行的平台和数据迁移，同时做出巨大的、高风险的决策，并且很难只用部分信息来逆转决策。在我最初的 5 个月之后，我有了一个团队，一个数据仓库，一个成功启动的迁移平台。我对工具和内容管理生态系统有一个清晰的概念，我想保留哪些工具，哪些工具我想日落，以及我的团队接下来应该构建什么。这段时间充满了兴奋、激动和肾上腺素，最后我为我的团队和我所取得的成就感到骄傲。然后，我想知道，从这里变得容易吗？ 8 | 9 | 答案可能是否定的。领导一个团队，直接为许多其他团队服务，在一个有着十多年历史、流程和传统代码的知名组织中，这个组织在全国范围内开展宣传工作，这意味着总有新的、巨大的挑战，而且总是比任何一个人在任何给定时间都能处理的更多的工作。我很快意识到，我需要非常谨慎地对待我的时间和团队的时间，并且非常清楚地沟通我们正在做什么和没有做什么，以便我们能够以可持续的速度工作，确保我们在正确的时间进行正确的工作。 10 | 11 | 这段时期令人兴奋，势不可挡，正是我准备迎接的挑战，但同时也很有压力，因为对于如何从混乱中摆脱清晰，如何处理压倒性的沟通和无数的竞争优先事项，没有剧本。这篇文章是 3 年前写给我自己的一封信-我希望存在的指南。我希望这对其他进入新技术领导职位的人有帮助。 12 | 13 | ## 一种不同的问题解决方法 14 | 15 | 当我是一名软件工程师时，当我还是一名软件工程经理时，我通常有过这样的经历，即我在代码库，项目或领域工作的时间越长，我就越了解它，我能够更有效地工作。编码经验复合，升级我可以编写更多代码，编写更复杂的代码，或承担风险重构项目，或学习如何扩展系统。我工作的知识空间是清晰的，自我记录的：如果我不知道代码的哪一部分，我可以运行它并进行调试和检查。如果我想了解代码库中过去决策的完整背景，我可以查看已签入更改的历史记录。一般来说，如果我深入研究细节，我可以询问的关于软件系统的大多数问题我可以自己回答。 16 | 17 | 作为一名 CTO 则恰恰相反：每个月都有一些全新的高风险挑战来自左场，这与之前的重大挑战毫无关系，有时在作出决定之前无法获得完整或甚至足够的信息。挑战的知识空间几乎从未被清晰地记录下来。如果我想了解过去决策的完整背景，我必须找到做决定时的人，有时我不能。我做出的每一个决定都有难以估计的权衡，不仅影响我，而且影响整个团队，有时影响整个组织。 18 | 19 | 虽然我已经准备好应对这一新的挑战，但我已经成熟了典型的技术行业文化，这种文化崇拜 “牛仔编码员”，并且通常不尊重管理层，所以我没有语言可以解释我的角色是什么或应该是什么。我最好的猜测是，我会成为一个解决组织技术问题的人，并为软件工程师带来麻烦。最初我曾假设我会像招聘我的团队那样做一些前期管理引导工作，然后我们将大部分时间花在一起编码。很快我意识到作为 CTO 的生产单位不是编写的代码行，而是做出了决策。做出决定很难。 20 | 21 | ## 规划组织并评估期望 22 | 23 | 在新组织中担任技术领导角色的第一步与在新组织中担任任何类型领导角色的第一步相同：您需要规划组织的工作方式，特别是规划对您自己和您的角色的期望。当前流程是什么？谁担任哪些角色？您将继承、使用或创建的流程和项目的决策者和利益相关者是谁？ 24 | 25 | 我的第一直觉是尝试将对这个角色的期望从与关键组织利益相关者的谈话中逆转出来。我向一组最初的利益相关者提出了一系列开放式问题，跟踪下一组问题的答案，跟踪团队和项目对下一组要交谈的人的引用，并重复直到我回答了所有开放式问题。我也很幸运能有几个小时的时间，接触到以前的首席技术官进行知识转让。由于我加入了一个有着悠久历史的成熟组织，过去曾做出过许多决策，其中许多决策都具有财务影响，因此我发现，从向前首席技术官提出有关继承预算和账户的问题开始，这一点很有帮助： 26 | 27 | - 对于每个预算行项目，为什么要购买此服务以及它的用途是什么？是谁做的决定？它服务于哪些团队或流程？ 28 | - 对于您以前管理的每个帐户，为什么存在此帐户？谁决定采用它，它服务于哪些团队或流程？ 29 | - 对于预算和账户问题确定的每一个流程，其实施时间有多长？一年中什么时候？涉及哪些团队和利益相关者？ 30 | - 您个人负责管理哪些流程？ 31 | - 你必须签署哪些程序？ 32 | - 你被要求参加哪些会议或工作组？你对什么说是？为什么？你拒绝了什么？为什么？ 33 | - 你还记得把时间花在我应该知道的事情上吗？ 34 | 35 | 在收集了以前 CTO 的团队和流程信息之后，我会见了 CTO 答案中确定的每个利益相关者，并讨论了他们参与的流程、他们过去与技术的互动、他们的经验和他们的期望。 36 | 37 | 我写下了所有的东西，并特别注意了关于技术和组织其他部分如何交互的隐含规范。总的来说，这些早期的会议，对于理解组织是如何工作的，以及技术团队在组织中是如何工作的非常有帮助。 38 | 39 | 我还发现，我不需要为这些利益相关者会议做太多的准备，我只需要展示议程项目“你认为我应该知道什么？”“准备好倾听。 40 | 41 | ## 考虑组织的阶段 42 | 43 | 对于任何新的领导者来说，《[The First 90 Days](https://www.amazon.com/First-90-Days-Strategies-Expanded/dp/1422188612)》值得一读。这是一个指导，在新的领导职位的前90天内要问什么问题和做什么。我发现以下提示特别有用： 44 | 45 | 1. **该组织处于什么阶段？** 本书使用 STARs 模型：启动、周转、重新调整和持续成功。组织的阶段很重要，因为它将决定可用的组织资源，组织的最高优先级，可能遇到的问题类型以及团队的组成和人员配置。 46 | 2. **我怎样才能将策略与情况相匹配？** 有很多领导力策略，特别是如果你过去一直担任领导角色，要避免的一个常见陷阱是推出过去有效的流程，而不仔细考虑这个组织所处的阶段，这个特殊的团队和情况。 47 | 3. **我可以获得什么“早期胜利”？** 将新领导者带入组织始终是一种风险：新领导者具有重要的地位权力，而且最初没有足够的背景来理解组织面临的当前和过去的挑战。新领导者必须迅速建立信任并获得组织成功的信心。一个直截了当的方法就是确定并推出 “早期胜利” - 显示您的优先事项的变化，并且是对长期运行会产生什么样的影响的早期一瞥。 48 | 49 | 在我与潜在客户和利益相关者的早期对话之后，我确定 MoveOn 的技术根据 STARs 模型处于重新调整状态。使用 The First 90 Days 剧本，这意味着我需要重新定义技术在这个组织中的作用，重组和重新聚焦技术资源，处理不再有用的根深蒂固的文化规范，并以一种尊重的方式谨慎地改变牧羊人的变化。当前流程和组织历史。 50 | 51 | 我也承认，虽然我曾在创业，周转和持续成功阶段的组织工作，但我以前从未参与过一次调整，因此需要注意不要重复使用有效的策略。在以前不合适的情况下。我决定专注于规划一些“早期胜利”，这些胜利证明了技术流程的变化是一件积极的事情，它使组织的其他成员受益并参与进来。 52 | 53 | ## 创建个人路线图 54 | 55 | 在确定了我认为 MoveOn 所处的组织阶段，制定组织项目、流程、角色、责任，并确定过去拥有什么技术以及为什么，我现在已经配备了足够的信息，来创建我自己的建议。我应该拥有什么，以及我的团队将拥有什么。 56 | 57 | 我将这个提案发布给了我的老板，领导团队以及我之前遇到过的主要利益相关者，得到了反馈，并将其作为我的个人路线图批准了。我特别注意自己和之前的首席技术官以及新聘用的技术团队之间的角色和责任是如何不同的。以下是本路线图的一些摘录。 58 | 59 | 前任 CTO 管理的事情我也将管理： 60 | 61 | - 年度预算计划 62 | - 核心系统和服务的管理员级帐户管理 63 | - 法规数据政策管理：FEC 报告，PCI 合规性，GDPR 64 | - 为核心技术系统构建或购买选择 65 | 66 | 我确定我将创建和管理的流程需求： 67 | 68 | - 技术团队招聘 69 | - 技术团队管理 70 | - 围绕员工和组织网络安全的政策和标准 71 | - 新的技术支持/快速响应技术问题解决系统 72 | - 如何与技术团队互动的新论坛和规范 73 | 74 | 我会落日的过程： 75 | 76 | - 通过直接编辑和检查 HTML 使员工更新基于 perl 的 Intranet - 替换为自助服务内部 wiki 77 | - 通过直接编辑和检查 HTML，让员工更新基于 perl 的面向公众的网站 - 替换为 Wordpress 并培训如何使用 Wordpress 的管理界面 78 | - 技术领域：我们将集中管理所有开发，项目管理和产品管理，而不是每个项目 1 名工程师，我们将集中项目和产品管理，所有开发人员都将在所有系统上工作 79 | 80 | 现在我清楚地意识到我的工作涉及的领域，我将拥有和不拥有的领域，以及我需要做出决策的地方。作为 CTO 的生产力单位不是编写的代码行，而是做出的决策。但即使有明确定义的领域，制定决策仍然很难。 81 | 82 | ## 征服时间管理 83 | 84 | 为了能够做出正确的决定，首先你需要控制你的时间。你需要弄清楚什么是可能性，并得到必要的上下文来定义和衡量权衡。 85 | 86 | 在一个著名的组织中担任权力职位的一个伟大而可怕的事情是，突然间每个人都想和你交谈！在成为 MoveOn 的首席技术官的一个月内，我发现我的日历一周又一周地填满了会议，这些会议对另一方有着模糊的价值，但对我来说却没有明确的价值。我不知道该对哪些会议说是或否。我发现，花大量的时间花在与渐进式组织空间相关的大量沟通和相关新闻上是很容易的，但是在处理紧急的团队问题上却没有时间。或者反过来说：我很容易把所有的时间都花在团队上，然后感觉与更大的组织或运动的工作脱节。如何平衡？ 87 | 88 | 我很快意识到，我的时间是我拥有的最宝贵和最稀缺的资源，我需要策略来有意和公平地利用它。我负责一个新的、不断变化的责任格局。 89 | 90 | ## 建立跟踪时间的习惯 91 | 92 | 在 [ Laura Vanderkam](https://lauravanderkam.com/) 的时间追踪体验启发下，我开始详细跟踪我的时间。有各种各样的工具，如谷歌电子表格和 toggl。工具本身并不重要，只是追踪时间的习惯。每周，我都会跟踪我从头到尾选择完成的每项任务，以及任务所属的工作类别。我跟踪了我早上的电子邮件时间，与员工的 1 对 1 会议、技术团队会议、花费时间进行审查代码和结对编程，研究不同的框架选项，以便即将进行的设计决策。在每一天结束时，我都记录了我的时间。 93 | 94 | 我开始跟踪任务和任务类别。当我跟踪我的任务时，我发现我工作的大部分任务都属于以下类别：软件管理、跨团队沟通、跨组织工作组、技术战略和架构研究、动手技术工作，如结对编程和技术思想的领导，比如在会议上发言和写这篇文章。 95 | 96 | 在每周结束时，我查看了我的时间日志并寻找模式。我是否把时间花在了回想起来并不重要的任务上？我没有得到什么是重要的？上周我能说什么不对？我是否为重要的事情腾出空间，还是让我的日子充满了不太重要的任务？ 97 | 98 | 然后我分析了我按类别花费时间的地方：我花了多少时间用于沟通？管理？我是否有足够的时间进行实际技术工作？我的重点是多么明确或分裂？ 99 | 100 | ## 分析时间并寻找见解 101 | 102 | 回顾我的每周时间日志，我很快就发现了一些模式，这些模式让我可以深入了解默认情况下的时间，我真正想要的时间。这有助于我围绕自己所做的事情制定更多有意识的目标，并且在任何特定时间都没有能力承担，委派什么，以及说什么不对。 103 | 104 | 例如，我很快意识到，在我的电子邮件收件箱中保持100％是不值得的，但很难让自己远离恐惧错过重要的事情。渐进式组织空间完全是关于书面文字 - 许多组织者通过电子邮件进行规划和协作，大部分员工的工作产品最终都是通过电子邮件或博客发布的 - 因此我在一周的漫长工作中每周收到大约 800 封电子邮件。我需要浏览这些电子邮件中的至少一半，以便掌握新的广告系列，这些广告系列会影响我的技术团队所做的工作或受其影响。跟踪我的时间，我意识到默认情况下我每周会花 8 到 12 个小时的电子邮件 - 超过一整天的时间！与其他团队不同，电子邮件通信与我的实际工作产品相关，即技术问题解决，软件系统构建和扩展。我无法在电子邮件中花这么多时间。所以我想出了一个时间管理干预：我不再按顺序阅读电子邮件，而是开发了一个个人电子邮件过滤算法，该算法使用gmail过滤器将电子邮件按项目和主题放入优先级。如果我只有 5 分钟，我只会阅读优先级最高的电子邮件。如果我有更多的时间，我会按照优先级排序。在调整过滤器几周之后，我最终得到了一个足够好的系统，并设法保持最佳工作的电子邮件通信，每 1-2 周一次浏览其他所有内容，让我减少到 3 个小时花在电子邮件上的一周 - 每周节省一整天！ 105 | 106 | 每周跟踪时间也有助于我了解需要花多少时间来承担不同类型的项目和责任。我发现作为参与者，参加任何跨组织工作组的成本是每周 2 小时，如果我领导该组，则为 4 小时。结果，我决定我一次只能承载这些类型的项目之一，这有助于我提高我的专注力，并拒绝额外的工作组职责。 107 | 108 | 我发现员工绩效评估每季度花费 20 个小时来编写和交付，每年预算编制过程花费 10 个小时，招聘流程需要 6 个星期 25 个小时，团队管理人员每周花费 10 个小时非可协商的团队会议和1-1时间。有了这种更清晰的经常性义务和所需时间的意识，我开始明白我的时间有多少，然后能够更有意识地开始消费。 109 | 110 | ## 时间管理策略 111 | 112 | 我发现 Cal Newport 的 《[Deep Work](https://www.amazon.com/Deep-Work-Focused-Success-Distracted/dp/1455586692)》 和 David Allen 的 《[Getting Things Done](https://www.amazon.com/Getting-Things-Done-Stress-Free-Productivity/dp/0142000280)》 对于制定时间管理策略非常有帮助。 113 | 114 | 《Getting Things Done》鼓励您将正在进行的工作和项目跟踪为 “开环” （open loops）。当人们要求你做事或回答问题时，如果不到两分钟，那就去做吧。如果需要更长时间，找出最终目标是什么，什么是可操作的并将其捕获为 “开环”。在将注意力从开环转移之前，请记下下一个可操作的步骤，这样当您返回任务时，它立即可以操作，您不必浪费时间将自己拉回到项目的完整环境中。当 “工作” 不仅涉及代码而且涉及通过电子邮件跟踪通信时，这很有用，并且您有大约 10-20 个定期需要跟进的活动项目。 115 | 116 | 《Deep Work》鼓励您将认知要求严格的 “深度工作” （Deep Work）与不认知要求的 “浅层工作” （Shallow Work）分开，首先优先考虑 “深度工作”，创建成功完成深度工作所需的适当焦点时间，并极力保护这一时间。对我来说，路线图，制定或购买决策，危机干预研究，预算编制以及编写单词和代码都是深度工作。代码审查，电子邮件，咨询其他团队，行政管理，如费​​用报告，利益相关者跟进和社交媒体都是浅薄的工作。很容易让你的一天充满 Shallow Work，所以反而积极地为 Deep Work 焦点会议留出时间（对我而言，这需要一次 90 分钟），并让 Shallow Work 填写这些焦点会议。这类似于许多管理哲学中的“大岩石第一”概念。 117 | 118 | ## 专注于极其重要的事物 119 | 120 | 一旦你有适合你的时间管理系统，并在你的个人路线图的指导下，接下来要弄清楚的是如何度过你日常的宝贵时间。 121 | 122 | 默认情况下，作为领导者，您可以轻松地将大部分时间用于捕获需求和需求，从而增加您的待办事项列表。大多数电子邮件都在寻求一些东西：建议，时间，决定，许可，资源。大多数会议都是讨论但未完成工作的地方。您可以在一整天内轻松完成将项目添加到待办事项列表中的活动，或者阻止您处理待办事项列表。结果是一种压倒性的感觉，并且不断变得越来越落后。该怎么办？ 123 | 124 | 每天的每个小时，您都会决定花时间做什么是最重要的 - 每次执行此操作时，您都会将自己的个人决策算法应用到您的时间。无论您的决策制定算法是什么（或者您认为自己的算法是否合适），您都需要知道它的表现如何，并随着时间的推移将其调整为更好。您需要设定明确的目标，专注于这些目标，并参与反馈循环，告诉您在实现目标方面的表现如何。 125 | 126 | **设定明确目标**： 127 | 128 | 1. 在每周开始时设定目标：本周你必须完成的2或3件事情是什么？您的日历上是否有空间来完成这项工作？如果没有，取消或推迟会议，直到有。 129 | 2. 在阅读电子邮件之前每天设定目标：今天你必须完成的一件事是什么？在检查电子邮件或走进办公室之前写下来，并在开始互动时继续关注它，并开始接收新的工作请求。 130 | 131 | **为与目标相关的工作留出时间**： 132 | 133 | 1. 在日历上获取工作区：其他人通过安排与您的会议来消磨时间。您可以通过安排日历上的工作块来节省自己的时间，以便为重要工作留出时间，并确保您有足够的时间开始并完成认知要求高的工作。 134 | 2. 做或委派？虽然大多数工作要求都会流经您，但您不仅要对自己的工作计划负责，还要对团队的工作计划负责。它可能很容易意外地囤积或瓶颈工作，然后不堪重负。尽可能默认为委派。一个好的经验法则是只做你能做的事情。委派你只会做得更好的事情。为您的团队提供真正的所有权和责任 135 | 136 | **专注于您的目标**： 137 | 138 | 1. 如果不知所措或不确定，请保持现在最重要的事情的清晰度。有什么选择可以推动您实现每日或每周目标？当您完全休息并以合理的速度工作时，您具有评估整个选项范围并做出谨慎决策的认知能力。但如果你在忙碌的消防日的第 12 小时，你可能会遇到决定疲劳。当你处于这种状态时，不要试图做出更多或新的决定，只关注那个最重要的事情，然后在休息时重新调整并重新评估情况。 139 | 2. 相信你的判断：当精疲力竭或不堪重负时，很容易开始怀疑或猜测你的判断。这可能会导致您无法在任务之间来回切换，或导致您以非生产性或混乱的方式重定向您的团队。明智地制定战略重定向，因为团队环境转换导致生产力成本高昂。请记住，在新工作几个月或新项目几周后，您确实拥有做出正确决策所需的背景。 140 | 141 | **反馈回路**： 142 | 143 | 1. 在一天结束时，检查您是否遇到了今天的一个目标。写下来，不要花费超过 5 分钟来考虑它。如果是这样，你做了什么使得这成为可能？如果没有，你怎么能重新安排你的一天来实现这个目标呢？ 144 | 2. 在本周末，检查您是否达到了本周 2-3 个目标。如果是这样，你做了什么使得这成为可能？如果没有，你怎么能重新安排你的一周来实现这个目标？有会议你可以推迟到另一周吗？你应该委派的问题？不要花费超过 15 分钟。 145 | 3. 特别是，我发现继续运行 “绝对值得花时间的东西” 和 “绝对不值得花时间的东西” 的列表是有帮助的 - 当我遇到它们时，我会记下新项目，如果我是面对什么感觉像是一个新的困境，或者我已经厌倦了，只是简单地决定疲劳，我在做出决定时遇到了困难，略读这些列表有助于我寻找新任务可以适应的模式，以指导我的决定。 146 | 147 | 调整个人决策算法最重要的部分不是你设定的目标，而是花时间进行反馈循环。有了反馈，随着时间的推移，你会变得越来越好。 148 | 149 | 150 | ## 调整个人路线图 151 | 152 | 在研究，定义和批准我的个人路线图之后，现在我有了一大堆我将拥有的东西以及我的团队将拥有的东西，我有一个明确的领域，我将成为关键的决策者。有了时间管理策略和个人反馈流程，每天我都觉得我更有意识地花时间。审核我的时间在特定类别中的位置，我意识到特别是对于技术领导职位，我需要非常仔细地，有意识地弄清楚我的时间如何在**软件工程**、**软件管理**和**组织领导**的关键领域之间分配。 153 | 154 | **软件工程**的世界总是在变化和发展，但是或多或少有一个关于软件工程工作所需要的标准手册 - 架构、构建、测试、扩展、修复，在一些编程语言和框架中启动代码。大多数工程师都有类似的典型日常工作，而且大多数管理人员都会让工程师明确期望他们应该做什么工作，以什么方式，在什么时间表上。 155 | 156 | **软件管理**更加模糊，但通常涉及人员管理，技术决策，[Building a Software Engineering Culture Where Everyone Can Thrive](https://medium.com/@ann_lewis/how-to-build-a-software-engineering-culture-where-everyone-can-thrive-e927bc52ea97)，每个人都可以茁壮成长，并且取决于组织的规模，一些项目，程序和产品管理。 157 | 158 | **组织领导**涉及定义团队与其他团队的交互方​​式，定义团队在大型组织中的角色，并涉及一定数量的“驾驭船舶”，参与讨论组织应关注的内容，应该解决的问题解决，它应该如何成长。 159 | 160 | 这里没有一个正确的答案 - 在不同的时间，技术领导者可能不得不在一个领域花费更多的时间，然后随着项目启动和组织环境的改变，焦点可能会发生变化。与时间管理策略一样，这里的重要部分是有意识地花时间在哪里。特别值得注意的是，要了解哪些区域适合您。您自然会倾向于舒适区域，特别是在疲劳或压力时。编码是否比决定如何实施即将发生的法规变更更准确？您可能会通过一个非常有趣的编码挑战来拖延监管决策，这个挑战突然出现在您的板块上。重要的是要知道哪些区域是舒适区域，哪些区域是增长区域，并确保您在正确的时间有意识地将时间花在正确的区域，特别是您在增长区域花费了足够的时间。 161 | 162 | 可能是大多数新技术领导者在组织领导方面缺乏经验的领域。提高组织领导力的最佳方法就是做更多的组织领导。 163 | 164 | 但这可能是非常耗费精力的，因为总有更多需要监督的项目，需要干预的问题，以及希望吸引您提供帮助的团队。我经常面临的一个关键挑战是弄清楚如何在保持技术的同时做出重要的组织领导。 165 | 166 | ## 保持技术 167 | 168 | 技术领导力不仅要充分利用您的时间，还要掌握快速发展的工具，系统和标准。每隔几年就会改变生态系统标准，以确定哪些问题容易或困难，昂贵或便宜，可扩展或瓶颈。对我来说，这是从事科技工作最激动人心的部分，但它也带来了独特的领导力挑战。作为技术领导者，不可能实际阅读所有代码，监控所有变更，管理所有系统，试验所有新工具和框架，阅读所有文章。即使你设法克隆了几次并尝试做所有事情，你也可能会让你的团队疯狂地进行微观管理。 169 | 170 | 面临的挑战是弄清楚与委托相关的技术工作，以及在没有瓶颈工作或微观管理的情况下保持参与技术细节的水平。以下是我发现有用的一些策略。 171 | 172 | **寻找复杂性并预先加载它**：您的团队在未来 6 个月内将面临哪些最大的技术挑战？这可能是称重生产系统的遗留代码的定时炸弹，需要扩大 10 倍的系统，将影响团队工作方式的新监管变更，是否投资新系统或生产线。你可能无法自己解决这个领域的所有问题 - 你需要整个团队来解决它，但是你需要精通足够的可能解决方案，以便能够指出它们正确的方向，构建关键问题，并在与空间相关的权衡中充分流利，以便能够引导利益相关者。您通常可以将这些区域标识为您的待办事项列表中看起来最无限或可怕的内容。在您的日历上获取深度工作重点块，并开始深入挖掘。通过安排与利益相关方的会议，向他们介绍他们以后必须做出决策的挑战和权衡，为这些挑战创建最后期限和问责制。 173 | 174 | **如果你进行实际的技术工作，优先考虑解除大多数人阻碍的工作**：虽然当你是个人贡献者或技术工作时，你可能很喜欢倾向于最有趣的技术工作，但你最有信心你知道该怎么做，如果你接受其他团队成员也可以做的技术任务，你很容易就会最终囤积或者瓶颈工作，最糟糕的是让你的团队失去权力，他们也想要从事有趣的工作。保存为您的团队带来最多技术荣耀的任务，而是集中精力完成解锁大多数人日的任务 - 每个人都在回避的怪物 Pull Request，令人烦恼的数据库迁移需要几个小时来照看孩子，构成或购买决策带来的风险最大。您在技术领导岗位上所能提供的最大价值不是您团队中软件工程师的编码速度快2倍，而是找到解锁或简化整个团队的方法，这将对网络团队生产力产生更大的乘数效应，而不是您更快或更有经验的实践技术工作的增量值。通过巨大的乘数效应来挑选烦人的任务，也为团队提供了关于领导角色的良好榜样。 175 | 176 | **找到插入有双重用途的技术环境的方法**。您永远不会有时间阅读所有代码库，浏览所有变更集，并保持所有架构决策的流畅性，而且您将永远没有足够的时间将所有质量时间花在您想要的每个团队成员上，因为时间是你最稀缺的资源。抵制向你不断增长的待办事项清单添加 “学习框架X” ，或者 “弄清楚 Y 功能如何工作” 等 “追赶” 任务的冲动 - 通常情况下你不能完成这个 “追赶” 任务。在技​​术系统中越来越多地感受到这种情况可能会令人生畏，特别是如果您患有**冒名顶替综合症**，并且您习惯于比其他人更努力地工作以建立和维持基线技术可信度。因此，找到方法逐步赶上有双重目的的技术背景。为此，我喜欢预定的结对编程和重复代码审查。 177 | 178 | **预定结对编程**：只需将其安排为与您的一名工程师会面并显示即可。忘了知道一切，感到愚蠢，为不知道所有事情而道歉。你不可能像工作人员那样在杂草中（因为在他们深入的时候，你的工作是广泛的），但你可以出现，提出问题，一起工作。故意模特正在问'愚蠢'的问题。配对可以让您的工程师对他们的工作给予关注和欣赏，并且他们可以成为专家。随着你的共同努力，定期回复以确定你明白。这将帮助您更快地赶上代码库，而不是自行完成代码阅读代码，这反过来又为您的工程师建立了有效的学习模型。 179 | 180 | **复述代码和架构检视**：当你试图成为一项优秀的运动时，该怎么做，并拿起其他人都在避免的怪物代码审查，但后来你意识到你缺乏能够判断设计决策或风格选择的背景？安排与提交代码审查的工程师进行“谈话代码审查”会议 - 这不必超过 20 分钟 - 并逐节讨论他们的变更集。让他们引导解释，每隔 5 分钟左右停下来 “重复” 他们用你自己的话所描述的内容。解释的性能方面确保您将成为一个积极的倾听者，并将迫使您自己澄清您是否理解他们做了什么以及为什么做。它也总是比阅读代码库或修补系统以获得所需的上下文更快。阅读代码并修补它总是很有趣，但有时你只需要 20 分钟就可以选择 2 小时，并且必须使用你所拥有的东西。与预定结对编程一样，这不仅可以节省您的时间并为您提供所需的背景，还可以让您的工程师对他们的工作给予关注和欣赏，并且他们可以成为专家。 181 | 182 | ## 管理信心并为自己创造安全的空间 183 | 184 | 为您的团队创建安全的空间，是 [Building Software Engineering Environments Where Everyone Can Thrive](https://medium.com/@ann_lewis/how-to-build-a-software-engineering-culture-where-everyone-can-thrive-e927bc52ea97) 的重要组成部分，每个人都可以茁壮成长，但除了确保您的团队有安全的空间，来提出 “愚蠢” 的问题并获得反馈之外，您也需要这样做。您的技术领导力越大，团队规模越大，您做出决策的次数就越多，但您对决策的反馈越少，您解决问题的权利就越多，或者无法做出权衡。明确的先例或正确或错误的答案。这最终会让人感到孤独和畏惧。您可以尝试从您的团队获得反馈，但由于持有位置权力的动态，您不可能获得直接，直接的反馈 - 您的直接报告不会拥有相同的上下文，并且每个人总是有点害怕批评他们的老板。 185 | 186 | 因此，走出去寻找一些 Tech Lead 的同行，建立关系，并为自己建立安全的空间，在那里你可以交换故事并得到你需要感到自信和负责任的真实反馈。我喜欢与其他进步组织的同行定期举行签到会议。 187 | 188 | 跟踪和监控自己的信心也很重要 - 了解您何时感到自信，什么时候不信任以及这有什么迹象，并为自己创建一个工具箱，让您自信地建立干预措施，您可以部署干预措施来支持自己你需要它。 189 | 190 | 如果我感到疲倦或恐惧，当人们向我提问或向我提出问题时，我会开始变得更加反应，特别是当我累了时，我倾向于怀疑问题比实际上更复杂。因此，当我意识到我立刻说是或者试图立即解决所提出的问题而不进行范围界定和理智检查时，我会理智地检查自己。 191 | 192 | 当我需要干预并加强我的信心时，我会尝试以下一些策略： 193 | 194 | - 我喜欢教人们编写代码 - 没有什么比向某人展示自动化的魔力更有趣，并帮助他们意识到他们也可以利用代码的力量，特别是如果他们以前被吓倒了。因此，我尝试定期为组织提供志愿服务，以便教人们编写代码，例如我在本地的 GirlDevelopIt 章节。教学帮助我记住我最喜欢的软件工程，帮助我巩固自己对核心概念的理解，并让我进入一个我已经是专家的论坛 - 所有这些都带来了信心。 195 | - 我会做一个心态干预（来自 Kelly McGonigal 的优秀书籍：[The Upside of Stress: Why Stress Is Good for You, and How to Get Good at It](https://www.amazon.com/gp/product/1583335617/)）就像花 15 分钟写下我的价值观，重新构思我的思维方式什么对我很重要，为什么，以及我的价值观如何与我的技术领导相关。 196 | - 庆祝成功：给自己一个金星，写下你最近为自己感到骄傲的胜利，并将其放在冰箱上，打电话给家人或朋友告诉他们。无论以何种方式对您有意义，明确表示您已经完成的工作。我剪辑了引用 MoveOn 活动或项目的新文章，我特别自豪，把它们挂在我身后的墙上，然后每当我进行视频会议时，我都会看到它们。 197 | - 帮助他人：在任何时候，我都会指导 1-2 名初级开发人员，或者有兴趣开始科技事业的人。这不是服务，而是增长的互利机会。当我们谈论目标，斗争，焦虑，前进的道路，而不是想知道我是否足够好时，我突然想起了我的心态，让我的学员放心，事实上他们已经足够好了，我记得成功是不是为了好或是完美，而是关于勇气和努力实现明确的目标。突然之间，我记得自己的自信，因为我需要建立信心，以帮助他人找到并增强他们的信心。 198 | 199 | ## 你有这个 200 | 201 | 开始一个新的技术领导角色将是艰难和压力，但也非常有益。 202 | 203 | 随着您在软件工程领域的进步，您将学习编码，然后学习更好，更快的代码，然后您将学习如何解决要解决的编码挑战，以及问题中简单和优雅的价值取景。在美好的日子里，有时候你的个人速度可能比预期快 10 倍，你会感觉自己像个巫师。 204 | 205 | 随着您在软件管理职业生涯中的进步，您将了解到，按正确的顺序，在正确的时间，对正确的工作进行排序，使整个团队能够有效地解决问题。您将了解构建每个人都可以茁壮成长的软件工程环境的重要性。您将了解到，确保团队中的人员能够倾听并感受到尊重，从而提升员工的能力，使他们更加自信和富有成效。您将学习如何支持您的团队的专业发展。当您的团队满意时，您的团队流程正在运作，您的团队目标明确，您将解锁并提高整个团队的工作效率。这种倍增效应比你个人在真正好日子里工作的速度快 10 倍。 206 | 207 | 随着您在技术领导职位上的进步，您可以指导整个组织使用技术来扩大他们的工作，使以前不可能解决的问题成为可能，并扩展系统以产生国家或甚至全球影响。组织领导能够影响，扩大和支持 100 或 1000 人的工作。在正确的时间用技术放大的正确想法可能会影响数百万人。即使是效率最高的开发人员或开发人员团队可以做的工作，这种乘数效应也要高出几个数量级。 208 | 209 | 这是很大的力量。您可以使用它，并且可以使用它来创建和扩展使世界变得更美好的项目！ 210 | -------------------------------------------------------------------------------- /articles/to-be-great-tl.md: -------------------------------------------------------------------------------- 1 | # 怎样成为优秀的 Tech Lead？ 2 | 3 | 原文链接：[What It Takes To Be A Great Technical Leader](https://www.businessinsider.com/how-to-be-a-great-technical-leader-2013-6) 4 | 5 | 大多数成功的项目都有一名工程师负责推动项目的进展，同时确保自信地做出强有力的技术决策。通常，该人被称为 Tech Lead。 6 | 他们通常不会管理人员，而是指导他们做最好的工作。 7 | 8 | 每家公司都不同，但我与之合作的最佳技术领先者中有一些共同点。脱帽致意 9 | (Hat Tip) Brian Stoler、Nathan Hunt、Evan Gilbert 和 Rich Burdon 以身作则。 10 | 11 | 在本文中，我列出了什么是不好的 Tech Lead，分解为 3A：属性（attributes），活动（activities）和动作（actions）。 其中许多概念适用于生活中的坏蛋。你的里程可能会改变。 12 | 13 | ## 属性 14 | 15 | 随着时间的推移，您应该始终增加三个属性：知识，速度和意识。 16 | 17 | ### 1.知识 18 | 19 | 技术知识为您提供了良好，可靠的决策的洞察力和可信度。强大的技术领导者的知识是广泛而深刻的。如果团队成员询问特定组件或系统的工作方式，您应该能够以有用的详细程度解释它或指向可以的人。 20 | 21 | 为了保持知识，我按以下顺序做了三件事： 22 | 23 | 1. 查看代码 24 | 2. 阅读设计文件 25 | 3. 编写代码（参见[ABC：始终编码](https://medium.com/always-be-coding/abc-always-be-coding-d5f8051afce2)） 26 | 27 | 顺序很重要，特别是前两个事项。如果工作已经完成，但等待审核，那么您几乎应该放弃自己的工作并帮助推进工作。如果不协助他人，编写代码可以让您在代码库中保持新鲜感。 28 | 29 | Tech Lead 应该是几种技术的掌握者。例如：Java，JavaScript，C++，分布式存储系统和客户端 Web 开发，可以让 Tech Lead 的拥有丰富 Web 应用程序知识。 30 | 31 | ### 2. 速度 32 | 33 | 你应该努力做到超级敏感，能够做出即时决定，总是把球向前踢。工程师应该带着期待迅速回应的问题来找你。 34 | 35 | 我个人为能够快速回应而感到自豪。我的目标似乎无处不在。我的秘密武器是我的收件箱，所以我更喜欢使用紧密的电子邮件集成工具。 36 | 37 | 例如，您使用哪个问题跟踪，代码审查或生产警报软件无关紧要，但团队成员应该收到电子邮件通知，并能够通过电子邮件对问题发表评论。允许团队中的任何人快速响应新的或更新的问题，并始终掌握所有状态更改，即使是从移动设备。 38 | 39 | ### 3. 意识 40 | 41 | 您应该能够始终保持整个项目的当前状态。否则，您无法意识到潜在迫在眉睫的阻滞者。如果内部或外部的力量威胁到减缓项目的速度，那么你应该知道它。 42 | 43 | 电子邮件集成再次成为关键。理想情况下，所有状态更改或更新都应以某种形式通过电子邮件传递，即使是离线会议也是如此例如，有人应该始终向整个团队发送会议记录，尤其是在做出重要决策时。 44 | 45 | 你应该始终改进上面的三个属性，因为你总是可以更快，更有知识，更有意识。 46 | 47 | ## 活动 48 | 49 | 作为一名 Tech Lead ，我发现自己在任何特定时间都在进行五项核心活动。几乎每一个动作都归结为其中一个。 50 | 这些年来我学到的是，一个 Tech Lead 所能做的两件最重要的事情，恰好是完全相反的两件事：阻塞和解除阻塞。 51 | 52 | ### 1。阻塞 53 | 54 | 阻塞需要高度的意识和规模，从战略决策到战术工程任务。技术负责人需要对项目中发生的事情保持警惕和意识，随时准备在做出错误的决定之前介入并阻止它们，通常会有更好的解决方案。 55 | 56 | 例如，如果一个工程师将一些代码发送给项目中的另一个工程师进行审查，这对审查人员来说似乎无害，但实际上引入了新的错误，并且您能够在提交或发布到生产环境之前介入并警告作者，这对作者、审查人员和整个项目都非常有用。 57 | 58 | 阻塞不应该停止进程，它会纠正，这样事情就可以继续前进。想想安全带，而不是安全网。 59 | 60 | ### 2. 解除阻塞 61 | 62 | 与阻塞相反，阻塞同样重要。通往地狱的路是由懒散的工程师铺成的。如果有人有问题，你应该能够给出一个答案或者让合适的人回答。 63 | 64 | 帮助我发展这种技能的是接待实习生。最好的实习生有很多问题。如果他们得不到答案，他们往往会陷入困境，或者更糟，沮丧。我必须学会如何提供正确的答案，或者将他们与能够引导他们前进的人联系起来。 65 | 66 | ### 3. 重定向 67 | 68 | 不管你有多好，你都不知道。你不能回答每一个问题。即使从技术上讲你可以，实际上你所有的时间都会花在回答他们上。为了填补这些空白（并帮助你完成自己的工作），你应该在精神上建立一个专家索引，这样你就总能知道在哪里找到答案。一个非常有用的策略是尽早使用，通常是重定向。技术领导者通常是 “人类302”（或人类重定向），将个人联系在一起。如果团队中的工程师不确定某件事情或有一个你不知道确切答案的问题，那么知道将他们发送给谁是非常有价值的，并且可以节省很多时间。 69 | 70 | 除了重定向问题之外，主动地将合适的人员添加到任何线程或代码审查中也有助于提高工作的整体质量。例如，如果一个工程师正在向一个关键组件添加代码，而这个关键组件不是他们最初编写的，那么向代码评审中添加一个专家将有助于确保正确地实现该特性。 71 | 72 | ### 4. 决定 73 | 74 | 你的部分职责是做决定，你的团队将依赖你。你越快地做出决定，别人就越快地做出决定。通常情况下，没有明确的前进道路，仅仅凭直觉走就是正确的选择。 75 | 76 | 当你倾听自己的直觉时，一定要做出一个能经得起时间考验的强有力的决定。您的项目可能会在您继续之后继续进行，您不希望继承者在继承您的项目时诅咒您的名称。这通常发生在积累了大量技术债务的项目上。 77 | 78 | 当面对对一系列选择做出决定时，我自然会经历以下过程： 79 | 80 | - 将选项数减少到 2。任何问题的复杂度都会随着每个选项呈指数级增加。 81 | - 根据经验或数据快速确定是否有最佳选择。 82 | - 如果此时正确的答案不明显，是否可以将其重定向到更适合作出决定的人？ 83 | - 如果仍然没有最好的选择，那么可能没有足够的数据，或者提出了错误的问题。要么阻止做出决定，要么用你的直觉去阻止。 84 | 85 | 上面的步骤应该在你的脑海中一瞬间完成。 86 | 87 | 决策的质量就像猎鹰适时的猛扑，它能攻击并摧毁受害者。- Sun Tzu 88 | 89 | ### 5. 表演 90 | 91 | Tech Lead 最重要的一个方面是他们能够通过例子来证明这一点。我们都听过“以身作则”这句话，但我更喜欢，展示，不说。从设计上讲，技术领导者往往不是管理者，因为他们把精力集中在代码上，而不是人上。所以，拥有团队的尊重和信任是很重要的，这最好通过证明你了解自己的东西来完成。 92 | 93 | 大多数领导者可能会发现很难抽出时间来编写代码，但要想找到时间是非常重要的。我称之为创造时间。即使我可以花一点时间做一些“垃圾工作”，修复恼人的 bug，或者根据需要在这里或那里添加一些有用的代码，我也会这样做；它对您来说比代码本身更有价值。 94 | 95 | ## 行动 96 | 97 | 以下列出了 Tech Lead 经常为推动项目前进所做的事情。它远非详尽无遗。 98 | 99 | - 创建并维护启动，测试和发布计划。 100 | - 举办有效的工程团队会议。 101 | - 确保会议在必要时有用且简洁。 102 | - 帮助创建和堆叠排名项目优先级。 103 | - 经常对新的或不必要的功能说“不”。 104 | - 定义问题跟踪的最佳做法。 105 | - 安装团队修复它，黑客马拉松或错误擦洗。 106 | - 保持跨职能关系。 107 | - 创建目标里程碑日期。 108 | - 随时了解有用的工具。 109 | - 指导其他工程师。 110 | - 招募其他团队的工程师。 111 | - 主持实习生，使他们成功。 112 | - 详细查看代码并提供有用的反馈。 113 | - 阅读，编写并提供有关设计文档的反馈。 114 | - 在正确的时间写出正确的代码。 115 | - 根据需要为管理人员提供保护。 116 | - 与其他工程团队合作，尤其是依赖项。 117 | - 确定技术债务。 118 | - 解释为什么做出决定。 119 | - 争取正确的设计决策。 120 | - 花时间解决技术债务问题。 121 | - 团队之间的负载平衡工作。 122 | - 板载新工程师并帮助识别其他工程师作为教练。 123 | - 根据需要，课程更正并完善目标日期。 124 | - 保持项目 MVP 的定义。 125 | - 评估架构决策及其含义。 126 | - 确保正在为核心功能编写测试。 127 | - 维持待命和值班流程。 128 | - 必要时升级阻止问题。 129 | - 了解产品的隐私和安全问题。 130 | - 经常产生新的想法和优雅的解决方案。 131 | - 调试困难的生产问题。 132 | - … 等等。 133 | 134 | 成功的技术领导没有处方。最好的是拥有大量实际运输产品经验的多产程序员。但回想一下你曾经使用的最佳线索，以及你上面阅读的内容有多少适用于它们。 135 | 136 | 要自信，继续前进，并始终提高。 137 | 138 | 139 | -------------------------------------------------------------------------------- /articles/what-make-a-good-tech-lead.md: -------------------------------------------------------------------------------- 1 | # 怎样才是好的 Tech Lead（技术负责人） ？ 2 | 3 | 原文地址：[What Makes a Good Tech Lead?](https://jasonroell.com/2015/10/13/what-makes-a-good-tech-lead/) 4 | 5 | 每个团队都需要一位优秀的领导，软件团队更是如此。在面对漏洞，开发出令人敬畏的新功能以及赶上最后期限之间，团队成员需要有可以信赖的人。但他/她是谁呢？技术的团队领导职位拥有哪些技能和责任？ 6 | 7 | 在我的职业生涯中，我有一些非常棒的团队领导者，也有一些不那么好。当我试图确定是什么让 “优秀” 如此惊人的工作时，这篇文章的灵感来到我身边？这些开发人员有哪些技能和责任，使他/她们与其他/她非常优秀的技术团队领导者不同？ 8 | 9 | 我已经制定了一份技能和责任清单，我认为这对于技术领导者来说是必不可少的，如果他/她们要取得成功的话。他/她们应该拥有几乎所有这些技能，并且能够舒适，乐于并且能够处理所列出的责任。 10 | 11 | ## Tech Lead 核心职责地图 12 | 13 | 事实上，Tech Lead （技术负责人）平衡了几个关键职责，如下面的思维导图所示： 14 | 15 | ![Tech Lead 核心职责地图](images/ttl-core.png) 16 | 17 | ### 团队支持 18 | 19 | 当然，第一个也是最重要的责任是团队支持。Tech Lead （技术负责人）可以激励团队，具有促进团队活动的能力和艺术，并且可以将团队工作组织成以流程为导向的方式。人们应该想和这个人一起工作。这是让你（团队的其他成员）生活更轻松的家伙。每个人在做正确的事情时偶尔都需要得到认可，但是团队也需要得到帮助，以保持对可能变得非常困难，政治或持续时间过长的事情的激励。谢谢 Tech Lead（技术负责人）！ 20 | 21 | ### 技术卓越 22 | 23 | 其次，Tech Lead （技术负责人）负责培育/执行和监控产品技术卓越性和高质量。更具体地说，Tech Lead 负责确保整个团队实现这一目标。换句话说，如果 Tech Lead 在团队无所作为的情况下自己开发了一款出色的产品，那么他在这方面仍然失败。 24 | 25 | ### 革新 26 | 27 | 第三，Tech Lead（技术负责人） 应该赞助团队工作的创新。这与卓越技术不同。它与团队精神和尝试和尝试新事物和非常规解决方案的愿望有关。这对于解决问题也是不同的，因为你可以用愚蠢的方式解决问题！ 28 | 29 | ## Tech Lead 核心技能组列表 30 | 31 | - 能够指导各个级别资历的工作人员，从刚毕业 3 个月的人到已经编程 30 年的人 32 | - 如何处理与团队成员的人员问题 33 | - 熟悉您的开发领域。它包括：语言，框架，实用程序，开发环境 34 | - 对问题管理系统、项目管理技能和版本控制有充分的了解 35 | - 成为首选的 bug 杀手 36 | - 知道如何及时进行代码审查、需要做什么，以及如何最大限度地减少他们持有的时间，并进行相应的代码更改 37 | - 如何编写单元测试和 mock（译者注：test-double），并让开发人员也编写测试 38 | - 了解什么是设计模式以及何时使用它们 39 | - 了解代码坏味道的含义，以及如何减少代码的坏味道 40 | - 持续集成 41 | - 对项目做计划及发布的能力 42 | - 能够将项目组件化，并将其分解为功能部件 43 | - 全面了解安全性，包括正确处理密码、分离系统、保护数据等的方法。 44 | - 管理业务指令/目标，并将相关信息转换为开发人员的信息 45 | - 能够估计不同技能的程序员的花费时间 46 | - 能够根据技能和能力将任务分配给正确的开发人员 47 | 48 | 最后，您需要意识到您的队友不是您的开发人员。 我经常听到技术主管说 “是啊，我的开发人员......” 或 “我的家伙......”。不，无论你在团队中扮演什么角色，他们都是你的队友。担任领导角色并不意味着你是队友的老板，也不是说你可以在他们身边老板。如果有的话，它会摧毁士气，你的团队的成果将受到极大的影响。 49 | 50 | -------------------------------------------------------------------------------- /articles/what-tech-lead-do.md: -------------------------------------------------------------------------------- 1 | # 好的 Tech Lead 在做些什么？ 2 | 3 | 原文链接：[What Does a Software Tech Lead Do?](http://allyouneedisbackend.com/blog/2018/08/03/what-does-a-tech-lead-do/) 4 | 5 | 在软件开发组织层次结构中，Tech Lead 是一个相对较新的角色。当我第一次听到这个角色时，我的第一个想法是 6 | 7 | > 它是软件架构师 + 团队的领导者吗？ 8 | 9 | 我并不认为这个定义是正确的，但这是一个很好的思考方式。在这篇文章中，我将回顾我在该职位上的 3.5 年经验，其中包括： 10 | 11 | - 领导 Atlassian Stride 的团队之一 —— 它是一个完整的团队沟通解决方案。在近两年的时间里，该团队拥有 5 到 10 名工程师。 12 | - 领导 KPIdata —— 一个非盈利组织，开发用于获取基辅理工学院高等教育质量的软件。该团队扩展到 10 个核心成员（仅包括我自己的 3 个软件工程师），最终，180 多个个人贡献者帮助我们完成了项目。 13 | - 领导由 4 名工程师（包括我自己）组成的团队在 Video Internet Technologies Ltd 进行视频管理系统集成（CCTV）。 14 | 15 | ``请注意``，相同职位在不同公司中可能有不同的职责。 16 | 17 | 查看博客文章的内容，了解我作为软件系统全职所有者的现实。我将详细说明了在技术主管职位上的利弊。 18 | 19 | 从实际的角度来看 - 该职位最关键的技能列表在博客的最后提供。 20 | 21 | ## 成为一名全职业主 22 | 23 | 我在这个职位上发现的第一件事是，现在我需要**100％ 负责**工程组织的一个篇章。关于这一点的好处 —— 新的篇章尚未生产任何东西。所以，任何来自先前维护者的遗留代码来支持和扩展。这一点相当的棒 24 | 25 | 然而，这不是通用的规则，每家公司都不同。我认为通常你有机会增强现有的软件系统，而不是从头开始创建。因此，请准备好对您的团队未启动和设计的项目负责。 26 | 27 | 成为全职业主意味着什么？ 28 | 29 | - **您收到的任务与特定的业务目标相关联**。实际上，任务是项目。而且，可以部分地定义要求。您需要继续并找出所有要求和约束。您希望尽可能多地指定项目的预期结果，以防止范围蔓延。理解和定义最终目标是第一步。 30 | - **您可以在时间/预算范围内为您做任何合理的事情来实现目标**。这一点，我们将在下一节中详细介绍。 31 | - **为实现目标而创建的软件的所有成功（和失败）都将与您相关联**。如果您的系统中的某些内容被破坏或者无法正常工作 —— 它是您的责任和错误。在目标超出预期的情况下 - 干得好！不要忘记为你们的成功归功于团队。团队应得的。 32 | 33 | ## 工程中的创意空间 34 | 35 | 是的，您可以做任何事情来实现工程目标。以下是我能够改变或实施的事项列表。请注意，您应该从团队中获得支持，以使更改持续存在。人们制作软件。快乐的人制作可以工作的软件。 36 | 37 | - **软件开发方法**。很大程度上取决于项目的目标和截止日期。回答以下的问题，以进行相关的定义： 38 | - 迭代中有多少天？ 39 | - 什么是规划过程？应该估算哪些任务？如何估算任务？ 40 | - 我们是否应该接受迭代之内的需求变化？ 41 | - 不同类型/优先级的任务有哪些规则？示例：无论严重性如何，必须尽快修复付费组件的所有错误。 42 | - 如何向组织的其他人演示？ 43 | - **项目的技术堆栈**。它可以包括但不限于编程语言，框架，数据存储，库，监控解决方案。有时您会有一些来自公司政策，规定的预定义预设。对于我们的章节，堆栈如下： 44 | - Python 3，异步编程，asyncio 45 | - MySQL，Elasticsearch，Redis 46 | - AWS（EC2，RDS，ElastiCache，S3，SQS，CloudFormation，CloudWatch） 47 | - DataDog，Elasticsearch/Logstash/Kibana，ElastAlert，Splunk 48 | - **软件架构**。您可以定义软件系统的结构部分。你可以建立新的东西。您可以重复使用现有的公司内部或第三方服务。如果您是技术主管，那么设计不同组件之间的接口也是您的责任。玩得开心！ 49 | - **非功能性要求**。它是关于定义足够好和完美软件之间的边界。我从未被鼓励做出理想的商业解决方案。通常，人们只需要一个稳定的解决方案来解决他们的业务问题。解决方案应该足够灵活，以便我们快速应用新的更改。对我而言，这意味着为工程师设定合理的期望，使企业满意。例如： 50 | - 该组件应该能够恢复数据库重启... 51 | - ...但如果在60秒内无法建立连接 - 请提醒 52 | - **内部里程碑**。您可以为项目的不同阶段设置团队的重点，并为此定义可交付成果。 53 | - 例如，可以优化项目路线图，以便尽快在生产中使用系统版本来建立 CI/CD 管道，并确保您的想法主要起作用。 54 | - 另一个例子 - 你可以瞄准让你的队友尽可能自主（当你们在地理上分布时都是个好主意） - 然后你需要花更多的时间来计划定义独立的工作流。 55 | - **服务水平指标**。作为技术主管，您负责定义软件何时提供所需的服务质量。选择反映业务实际情况的正确指标至关重要，因为它为您的团队设定了目标以及工程改进的方向。以我的经验来看，相关的例子有： 56 | - **可用性**。可以使用该服务吗？ 57 | - **已处理的作业数**。我们还需要这项服务吗？我们做了多少有用的工作？ 58 | - **主要组成部分的成功率**。——帮助我们看到中间层面的问题。 59 | - **推出计划**。它包括将软件部署到不同环境的频率。 60 | - 一旦拉出请求（Pull Request）合并 61 | - 或者每 4 个月发布一次。 62 | - **通讯**。团队如何就日常进展进行沟通？ 63 | - 每天 30 分钟的视频通话两次 64 | - 文字站会每周一次（也许） 65 | - **工作切分**。如何分配 Jira 中的任务？ 66 | - 您将每项任务分配给每位工程师，如果没有您的书面许可，他们没有任何机会进行更改（不是很好的策略） 67 | - 无论优先级和依赖性如何，每个人都可以执行任何任务 68 | - **代码审查政策**。应该由谁批准 Pull Request，以让创作者将其合并到 master ？选项： 69 | - 共识 —— 所有问题都得到了解答，所有默认审核人都批准了这些更改 70 | - 收到高级工程师至少 2 份批准才能继续 71 | - 我可以批准我的 PR，并在最后一次提交后 2 小时后部署 72 | - **回顾会议**（Retrospectives）。多久做一次？我的推荐是每 4 周一次，但我知道有些团队每 2 周做一次。顺便问一下，你经常这样做吗？ 73 | 74 | 我省略了一些东西，所以随意添加你的想法作为评论。 75 | 76 | ## Tech Lead 需要多技术？ 77 | 78 | 我的任务是使团队能够为问题实施正确的解决方案。 79 | 80 | > 你不会每天写很多代码 81 | 82 | 在我成为最近团队的 Tech Lead 之前，我所在小组的成员，大多数是超过 1.5 年的中级/高级软件工程师。对于我来说，获得异步编程、关系数据库和非关系数据库、即时消息传递和高负载系统所需的实践经验至关重要。 83 | 84 | 首先要让你的项目成功，为此你应该阅读更多的相关资料： 85 | 86 | - 代码 87 | - 来自团队提出的 Pull Request。 88 | - 您的系统重用的解决方案。 89 | - 您需要使用的其他团队维护的第三方服务代码。 90 | - 技术文档 91 | - 您可以重复使用的服务的说明（内部和第三方服务）。 92 | - 解决方案的实施细节。 93 | - 他们已知的问题（没有什么是完美的） - 了解风险并为他们制定缓解计划。 94 | 95 | 经过大量阅读后，你写一下： 96 | 97 | - 工程建议 - [DACI](https://www.atlassian.com/team-playbook/plays/daci) 是一个有用的框架。 我喜欢它。 98 | - 提案确定后 - 设计页面。 99 | - 最后的最后 - 工作内容的 tickets（我们团队使用的是 Jira）。 100 | 101 | 在写完之后 - 你讨论： 102 | 103 | - 与您的成员达成有关非平凡任务的协议。 104 | - 如果您有不完整的规范或没有提供所有数据源，请教育您的团队成员。 105 | - 与其他团队谈判。 106 | - 演示您的工作成果，并在公司内推广您的解决方案。 107 | 108 | 在一天结束时，您可能需要花费几个小时来做​​出个人贡献。对我来说，它类似于以下内容： 109 | 110 | - 修补程序（Hotfixes）。当世界即将爆炸时，需要修复一些东西。 111 | - 在不编写测试的情况下为 pull request 提供概念证明。之后，请团队成员将其转变为生产级软件。 112 | - 提交数据库或配置更改。 113 | - 调查在开发环境中，难以复制的奇怪错误。 114 | - 从度量/日志记录解决方案中，提取一些数据以验证实现的想法。 115 | 116 | 我认为 Tech Lead 应具备扎实的实践软件工程经验，以便能够制定和支持合理的决策。 117 | 118 | > 在小型团队（最多 3 个直接报告者）上，我认为仍然可以做出一些好的个人贡献。 119 | 120 | 在撰写本文时，我还没有发展出足够的工程领导能力，能够为更大的团队做出可持续的个人贡献。 121 | 122 | ## 成为 Tech Lead 的优缺点 123 | 124 | **优点**： 125 | 126 | - 您将成为项目领域的主题专家（subject matter expert）。 127 | - 您完全了解软件系统的工作原理，以及如何以最小的风险将更改应用于该系统。您现在可以将其复制到其他系统。 128 | - 您成为一名优秀的沟通者，因为您有责任了解需求并解释技术解决方案。 129 | - 在软件开发的各个领域，你达到了某种程度的能力（但并不总是很高）： 130 | - **系统设计** - 构建您的软件，并在早期阶段验证所有风险。 131 | - **操作** - 保持系统正常运行。 132 | - **工程质量** - 防止损失贵公司的声誉。 133 | - **工程管理** - 将实施委派给您的团队甚至其他团队。 134 | 135 | **缺点**： 136 | 137 | - 在工作日结束时，你往往没有成就感。 你已经为你的团队创造了一些新的工作，解决了一些阻碍者，但它并不像真正的工作。 138 | - 大型团队编码不够。 139 | - 你是团队的入口。 您应该能够接受来自多个来源的任务： 140 | - 你的队友 141 | - 你的管理层 142 | - 合作团队 143 | - 客户支持团队 144 | - 其他人听说过你的团队 145 | - 有时它很紧张，因为它有很多责任 最终，你应该学会如何处理所有这些。 146 | 147 | 我认为这个位置值得尝试，我很高兴我有机会担任该职位多年。 我会再做一次。 148 | 149 | ## Tech Lead 入门包 150 | 151 | 152 | 如果您对 Tech Lead 职位感兴趣并希望为此做好准备，那么以下便是我在路径的最开始时发现的有价值的技能列表： 153 | 154 | - 从技术栈中，**熟练掌握编程语言** —— 能够做出良好的技术选择，并进行代码审查。使项目正确启动至关重要，因此您的编码技能可以极大地帮助定义结构和基本组件。 155 | - **与数据存储相关的良好技能水平** —— 我认为在大多数项目中，您处理从某个地方读取或存储的信息。此外，知识是系统设计能力的完美基础。 156 | - **项目管理** - 用于在新的多任务环境中组织您的工作以及其他人的工作。 157 | - **沟通技巧** - 这个职位是让其他人做技术工作。 158 | 159 | 我相信这 4 项技能已足够，其余的技能可以在项目期间建立。我希望这篇博文有助于提高软件团队的技术领导能力。 160 | 161 | 162 | 附： 在博客中，当我说“你做某事”意味着“你对某事负责。”作为 Tech Lead ，你可以将一些复杂的工程委托给团队中的专家，但能够验证、批准或纠正解决方案。此外，作为决策者并不等于成为独裁者而忽略了其他人的声音。 163 | 164 | 附附： 从我的角度来看，Team Lead 和 Tech Lead 之间的区别在于： 165 | 166 | - Team Lead 负责人，而不是项目。 167 | - Team Lead 负责人事管理。 168 | - Team Lead 不应该做出个人贡献。 169 | 170 | 附附附： 另外，在我看来，架构师和 Tech Lead 之间的区别： 171 | 172 | - 架构师有更实际和多样化的经验。 173 | - 更广泛和更复杂的系统需要架构师。 174 | - 架构师的立场更多的是做最费力的工作，而不是让团队的其他成员完成所有的工作。 175 | 176 | -------------------------------------------------------------------------------- /assets/adr.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/adr.png -------------------------------------------------------------------------------- /assets/architecture-process.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/architecture-process.jpg -------------------------------------------------------------------------------- /assets/c4-model.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/c4-model.jpg -------------------------------------------------------------------------------- /assets/c4model-layer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/c4model-layer.png -------------------------------------------------------------------------------- /assets/cone-of-uncertainty-for-powerpoint.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/cone-of-uncertainty-for-powerpoint.jpg -------------------------------------------------------------------------------- /assets/flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/flow.png -------------------------------------------------------------------------------- /assets/influence.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/influence.gif -------------------------------------------------------------------------------- /assets/influencing-approaches.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/influencing-approaches.png -------------------------------------------------------------------------------- /assets/leader-vs-boss.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/leader-vs-boss.jpg -------------------------------------------------------------------------------- /assets/limit-of-authority.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/limit-of-authority.png -------------------------------------------------------------------------------- /assets/motivators.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/motivators.jpg -------------------------------------------------------------------------------- /assets/new-project-checklist.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/new-project-checklist.jpg -------------------------------------------------------------------------------- /assets/path-to-production.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/path-to-production.png -------------------------------------------------------------------------------- /assets/situational-leadership-model.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/situational-leadership-model.png -------------------------------------------------------------------------------- /assets/skill_wheels.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/skill_wheels.png -------------------------------------------------------------------------------- /assets/skilltree.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/skilltree.png -------------------------------------------------------------------------------- /assets/stakeholder-mapping.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/stakeholder-mapping.jpg -------------------------------------------------------------------------------- /assets/states-of-group.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/states-of-group.png -------------------------------------------------------------------------------- /assets/sweet-spot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/sweet-spot.png -------------------------------------------------------------------------------- /assets/tech-action-project.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/tech-action-project.png -------------------------------------------------------------------------------- /assets/tech-action-project.sketch: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/tech-action-project.sketch -------------------------------------------------------------------------------- /assets/tech-debt-wall.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/tech-debt-wall.png -------------------------------------------------------------------------------- /assets/tech-lead-butterfly.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/tech-lead-butterfly.png -------------------------------------------------------------------------------- /assets/tech-lead-circles.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/tech-lead-circles.png -------------------------------------------------------------------------------- /assets/techstack.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/techstack.jpg -------------------------------------------------------------------------------- /assets/tki-stratery.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/tki-stratery.jpg -------------------------------------------------------------------------------- /assets/tki.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/tki.jpg -------------------------------------------------------------------------------- /assets/tla.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/tla.png -------------------------------------------------------------------------------- /assets/tw-radar-platforms.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/assets/tw-radar-platforms.png -------------------------------------------------------------------------------- /defined.md: -------------------------------------------------------------------------------- 1 | Tech Lead is a 'Hybird' role 2 | 3 | - technical lead 4 | - project manager 5 | - people manager 6 | 7 | individual developers -> individual contributor -> Technical Contributor 8 | 9 | Focus on 10 | 11 | - Productivity（Autonomy） 12 | - Growth 13 | 14 | 15 | Tools 16 | 17 | [DACI](https://www.atlassian.com/team-playbook/plays/daci) 18 | 19 | 20 | ## 是否需要 Tech Lead 21 | 22 | ### Tech Lead Overload 问题 23 | -------------------------------------------------------------------------------- /desktop/src/index.ts: -------------------------------------------------------------------------------- 1 | console.log('hello, IDE'); 2 | -------------------------------------------------------------------------------- /docs/README.md: -------------------------------------------------------------------------------- 1 | # Tech Lead Toolbox Documents 2 | 3 | [Architecture Decision Record](adr/) 4 | 5 | [Business Model Canvas](bmc/canvas.html) 6 | 7 | -------------------------------------------------------------------------------- /docs/adr/0001-desktop-工具.md: -------------------------------------------------------------------------------- 1 | # 1. Desktop 工具 2 | 3 | 日期: 2019-01-31 4 | 5 | ## 状态 6 | 7 | 2019-01-31 提议 8 | 9 | ## 背景 10 | 11 | 在这里补充上下文... 12 | 13 | ## 决策 14 | 15 | 在这里补充上决策信息... 16 | 17 | ## 后果 18 | 19 | 在这里记录结果... 20 | -------------------------------------------------------------------------------- /docs/adr/0002-模块功能插件化.md: -------------------------------------------------------------------------------- 1 | # 2. 模块功能插件化 2 | 3 | 日期: 2019-02-15 4 | 5 | ## 状态 6 | 7 | 2019-02-15 提议 8 | 9 | ## 背景 10 | 11 | 模块功能比较多，可以远程加载时速度比较慢，且不利于系统维护 12 | 13 | ## 决策 14 | 15 | 采用 Web Components 作为插件化的载体，来进行插件化设计 16 | 17 | Plugin API spike: 18 | 19 | ```typescript 20 | interface PluginModel { 21 | name: string; 22 | uuid: string; 23 | url: string; 24 | version: string; 25 | } 26 | ``` 27 | 28 | ## 后果 29 | 30 | 在这里记录结果... 31 | -------------------------------------------------------------------------------- /docs/adr/README.md: -------------------------------------------------------------------------------- 1 | # 架构决策记录 2 | 3 | * [1. desktop-工具](0001-desktop-工具.md) 4 | * [2. 模块功能插件化](0002-模块功能插件化.md) -------------------------------------------------------------------------------- /docs/architecture/README.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/docs/architecture/README.md -------------------------------------------------------------------------------- /docs/bmc/canvas.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | The Business Model Canvas 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 |

The Business Model Canvas

15 | 16 | 17 | 18 | 19 | 23 | 28 | 34 | 39 | 45 | 46 | 47 | 48 | 49 | 54 | 60 | 61 | 62 | 66 | 70 | 71 |
20 |

Key Partners

21 |

Open Source Contributor

22 | 		24 |

Key Activities

25 |

Tech Lead Resources

26 |

Tech Lead Toolbox

27 | 		29 |

Value Proposition

30 |

Self Growth

31 |

Team Release

32 |

Work Better

33 | 		35 |

Customer Relationship

36 |

Communities

37 |

Co-creation

38 | 		40 |

Customer Segments

41 |

Tech Lead/pre Tech Lead

42 |

Tech Manager/pre Tech Manager

43 |

Senior Engineer/Pre Senior Engineer

44 |
50 |

Key Resources

51 |

Related Resources

52 |

Brand

53 | 		55 |

Channels

56 |

SEO

57 |

Social Media

58 |

Article Marketing

59 |
63 |

Cost Structure

64 |

Server

65 | 		67 |

Revenue Streams

68 |

Donate

69 |
72 | 73 |
74 | 75 | 76 | 77 | 78 | 79 | 80 | -------------------------------------------------------------------------------- /docs/bmc/canvas_template.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | The Business Model Canvas 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 |

The Business Model Canvas

15 | 16 | 17 | 18 | 19 | 23 | 27 | 31 | 35 | 39 | 40 | 41 | 42 | 43 | 47 | 51 | 52 | 53 | 57 | 61 | 62 |
20 |

Key Partners

21 |

22 | 		24 |

Key Activities

25 |

...

26 | 		28 |

Value Proposition

29 |

...

30 | 		32 |

Customer Relationship

33 |

...

34 | 		36 |

Customer Segments

37 |

...

38 |
44 |

Key Resources

45 |

...

46 | 		48 |

Channels

49 |

...

50 |
54 |

Cost Structure

55 |

...

56 | 		58 |

Revenue Streams

59 |

...

60 |
63 | 64 |
65 | 66 | 67 | 68 | 69 | 70 | 71 | -------------------------------------------------------------------------------- /docs/bmc/css/bootstrap-responsive.min.css: -------------------------------------------------------------------------------- 1 | /*! 2 | * Bootstrap Responsive v2.1.0 3 | * 4 | * Copyright 2012 Twitter, Inc 5 | * Licensed under the Apache License v2.0 6 | * http://www.apache.org/licenses/LICENSE-2.0 7 | * 8 | * Designed and built with all the love in the world @twitter by @mdo and @fat. 9 | */.clearfix{*zoom:1}.clearfix:before,.clearfix:after{display:table;line-height:0;content:""}.clearfix:after{clear:both}.hide-text{font:0/0 a;color:transparent;text-shadow:none;background-color:transparent;border:0}.input-block-level{display:block;width:100%;min-height:30px;-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box}.hidden{display:none;visibility:hidden}.visible-phone{display:none!important}.visible-tablet{display:none!important}.hidden-desktop{display:none!important}.visible-desktop{display:inherit!important}@media(min-width:768px) and (max-width:979px){.hidden-desktop{display:inherit!important}.visible-desktop{display:none!important}.visible-tablet{display:inherit!important}.hidden-tablet{display:none!important}}@media(max-width:767px){.hidden-desktop{display:inherit!important}.visible-desktop{display:none!important}.visible-phone{display:inherit!important}.hidden-phone{display:none!important}}@media(min-width:1200px){.row{margin-left:-30px;*zoom:1}.row:before,.row:after{display:table;line-height:0;content:""}.row:after{clear:both}[class*="span"]{float:left;margin-left:30px}.container,.navbar-static-top .container,.navbar-fixed-top .container,.navbar-fixed-bottom .container{width:1170px}.span12{width:1170px}.span11{width:1070px}.span10{width:970px}.span9{width:870px}.span8{width:770px}.span7{width:670px}.span6{width:570px}.span5{width:470px}.span4{width:370px}.span3{width:270px}.span2{width:170px}.span1{width:70px}.offset12{margin-left:1230px}.offset11{margin-left:1130px}.offset10{margin-left:1030px}.offset9{margin-left:930px}.offset8{margin-left:830px}.offset7{margin-left:730px}.offset6{margin-left:630px}.offset5{margin-left:530px}.offset4{margin-left:430px}.offset3{margin-left:330px}.offset2{margin-left:230px}.offset1{margin-left:130px}.row-fluid{width:100%;*zoom:1}.row-fluid:before,.row-fluid:after{display:table;line-height:0;content:""}.row-fluid:after{clear:both}.row-fluid [class*="span"]{display:block;float:left;width:100%;min-height:30px;margin-left:2.564102564102564%;*margin-left:2.5109110747408616%;-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box}.row-fluid [class*="span"]:first-child{margin-left:0}.row-fluid .span12{width:100%;*width:99.94680851063829%}.row-fluid .span11{width:91.45299145299145%;*width:91.39979996362975%}.row-fluid .span10{width:82.90598290598291%;*width:82.8527914166212%}.row-fluid .span9{width:74.35897435897436%;*width:74.30578286961266%}.row-fluid .span8{width:65.81196581196582%;*width:65.75877432260411%}.row-fluid .span7{width:57.26495726495726%;*width:57.21176577559556%}.row-fluid .span6{width:48.717948717948715%;*width:48.664757228587014%}.row-fluid .span5{width:40.17094017094017%;*width:40.11774868157847%}.row-fluid .span4{width:31.623931623931625%;*width:31.570740134569924%}.row-fluid .span3{width:23.076923076923077%;*width:23.023731587561375%}.row-fluid .span2{width:14.52991452991453%;*width:14.476723040552828%}.row-fluid .span1{width:5.982905982905983%;*width:5.929714493544281%}.row-fluid .offset12{margin-left:105.12820512820512%;*margin-left:105.02182214948171%}.row-fluid .offset12:first-child{margin-left:102.56410256410257%;*margin-left:102.45771958537915%}.row-fluid .offset11{margin-left:96.58119658119658%;*margin-left:96.47481360247316%}.row-fluid .offset11:first-child{margin-left:94.01709401709402%;*margin-left:93.91071103837061%}.row-fluid .offset10{margin-left:88.03418803418803%;*margin-left:87.92780505546462%}.row-fluid .offset10:first-child{margin-left:85.47008547008548%;*margin-left:85.36370249136206%}.row-fluid .offset9{margin-left:79.48717948717949%;*margin-left:79.38079650845607%}.row-fluid .offset9:first-child{margin-left:76.92307692307693%;*margin-left:76.81669394435352%}.row-fluid .offset8{margin-left:70.94017094017094%;*margin-left:70.83378796144753%}.row-fluid .offset8:first-child{margin-left:68.37606837606839%;*margin-left:68.26968539734497%}.row-fluid .offset7{margin-left:62.393162393162385%;*margin-left:62.28677941443899%}.row-fluid .offset7:first-child{margin-left:59.82905982905982%;*margin-left:59.72267685033642%}.row-fluid .offset6{margin-left:53.84615384615384%;*margin-left:53.739770867430444%}.row-fluid .offset6:first-child{margin-left:51.28205128205128%;*margin-left:51.175668303327875%}.row-fluid .offset5{margin-left:45.299145299145295%;*margin-left:45.1927623204219%}.row-fluid .offset5:first-child{margin-left:42.73504273504273%;*margin-left:42.62865975631933%}.row-fluid .offset4{margin-left:36.75213675213675%;*margin-left:36.645753773413354%}.row-fluid .offset4:first-child{margin-left:34.18803418803419%;*margin-left:34.081651209310785%}.row-fluid .offset3{margin-left:28.205128205128204%;*margin-left:28.0987452264048%}.row-fluid .offset3:first-child{margin-left:25.641025641025642%;*margin-left:25.53464266230224%}.row-fluid .offset2{margin-left:19.65811965811966%;*margin-left:19.551736679396257%}.row-fluid .offset2:first-child{margin-left:17.094017094017094%;*margin-left:16.98763411529369%}.row-fluid .offset1{margin-left:11.11111111111111%;*margin-left:11.004728132387708%}.row-fluid .offset1:first-child{margin-left:8.547008547008547%;*margin-left:8.440625568285142%}input,textarea,.uneditable-input{margin-left:0}.controls-row [class*="span"]+[class*="span"]{margin-left:30px}input.span12,textarea.span12,.uneditable-input.span12{width:1156px}input.span11,textarea.span11,.uneditable-input.span11{width:1056px}input.span10,textarea.span10,.uneditable-input.span10{width:956px}input.span9,textarea.span9,.uneditable-input.span9{width:856px}input.span8,textarea.span8,.uneditable-input.span8{width:756px}input.span7,textarea.span7,.uneditable-input.span7{width:656px}input.span6,textarea.span6,.uneditable-input.span6{width:556px}input.span5,textarea.span5,.uneditable-input.span5{width:456px}input.span4,textarea.span4,.uneditable-input.span4{width:356px}input.span3,textarea.span3,.uneditable-input.span3{width:256px}input.span2,textarea.span2,.uneditable-input.span2{width:156px}input.span1,textarea.span1,.uneditable-input.span1{width:56px}.thumbnails{margin-left:-30px}.thumbnails>li{margin-left:30px}.row-fluid .thumbnails{margin-left:0}}@media(min-width:768px) and (max-width:979px){.row{margin-left:-20px;*zoom:1}.row:before,.row:after{display:table;line-height:0;content:""}.row:after{clear:both}[class*="span"]{float:left;margin-left:20px}.container,.navbar-static-top .container,.navbar-fixed-top .container,.navbar-fixed-bottom .container{width:724px}.span12{width:724px}.span11{width:662px}.span10{width:600px}.span9{width:538px}.span8{width:476px}.span7{width:414px}.span6{width:352px}.span5{width:290px}.span4{width:228px}.span3{width:166px}.span2{width:104px}.span1{width:42px}.offset12{margin-left:764px}.offset11{margin-left:702px}.offset10{margin-left:640px}.offset9{margin-left:578px}.offset8{margin-left:516px}.offset7{margin-left:454px}.offset6{margin-left:392px}.offset5{margin-left:330px}.offset4{margin-left:268px}.offset3{margin-left:206px}.offset2{margin-left:144px}.offset1{margin-left:82px}.row-fluid{width:100%;*zoom:1}.row-fluid:before,.row-fluid:after{display:table;line-height:0;content:""}.row-fluid:after{clear:both}.row-fluid [class*="span"]{display:block;float:left;width:100%;min-height:30px;margin-left:2.7624309392265194%;*margin-left:2.709239449864817%;-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box}.row-fluid [class*="span"]:first-child{margin-left:0}.row-fluid .span12{width:100%;*width:99.94680851063829%}.row-fluid .span11{width:91.43646408839778%;*width:91.38327259903608%}.row-fluid .span10{width:82.87292817679558%;*width:82.81973668743387%}.row-fluid .span9{width:74.30939226519337%;*width:74.25620077583166%}.row-fluid .span8{width:65.74585635359117%;*width:65.69266486422946%}.row-fluid .span7{width:57.18232044198895%;*width:57.12912895262725%}.row-fluid .span6{width:48.61878453038674%;*width:48.56559304102504%}.row-fluid .span5{width:40.05524861878453%;*width:40.00205712942283%}.row-fluid .span4{width:31.491712707182323%;*width:31.43852121782062%}.row-fluid .span3{width:22.92817679558011%;*width:22.87498530621841%}.row-fluid .span2{width:14.3646408839779%;*width:14.311449394616199%}.row-fluid .span1{width:5.801104972375691%;*width:5.747913483013988%}.row-fluid .offset12{margin-left:105.52486187845304%;*margin-left:105.41847889972962%}.row-fluid .offset12:first-child{margin-left:102.76243093922652%;*margin-left:102.6560479605031%}.row-fluid .offset11{margin-left:96.96132596685082%;*margin-left:96.8549429881274%}.row-fluid .offset11:first-child{margin-left:94.1988950276243%;*margin-left:94.09251204890089%}.row-fluid .offset10{margin-left:88.39779005524862%;*margin-left:88.2914070765252%}.row-fluid .offset10:first-child{margin-left:85.6353591160221%;*margin-left:85.52897613729868%}.row-fluid .offset9{margin-left:79.8342541436464%;*margin-left:79.72787116492299%}.row-fluid .offset9:first-child{margin-left:77.07182320441989%;*margin-left:76.96544022569647%}.row-fluid .offset8{margin-left:71.2707182320442%;*margin-left:71.16433525332079%}.row-fluid .offset8:first-child{margin-left:68.50828729281768%;*margin-left:68.40190431409427%}.row-fluid .offset7{margin-left:62.70718232044199%;*margin-left:62.600799341718584%}.row-fluid .offset7:first-child{margin-left:59.94475138121547%;*margin-left:59.838368402492065%}.row-fluid .offset6{margin-left:54.14364640883978%;*margin-left:54.037263430116376%}.row-fluid .offset6:first-child{margin-left:51.38121546961326%;*margin-left:51.27483249088986%}.row-fluid .offset5{margin-left:45.58011049723757%;*margin-left:45.47372751851417%}.row-fluid .offset5:first-child{margin-left:42.81767955801105%;*margin-left:42.71129657928765%}.row-fluid .offset4{margin-left:37.01657458563536%;*margin-left:36.91019160691196%}.row-fluid .offset4:first-child{margin-left:34.25414364640884%;*margin-left:34.14776066768544%}.row-fluid .offset3{margin-left:28.45303867403315%;*margin-left:28.346655695309746%}.row-fluid .offset3:first-child{margin-left:25.69060773480663%;*margin-left:25.584224756083227%}.row-fluid .offset2{margin-left:19.88950276243094%;*margin-left:19.783119783707537%}.row-fluid .offset2:first-child{margin-left:17.12707182320442%;*margin-left:17.02068884448102%}.row-fluid .offset1{margin-left:11.32596685082873%;*margin-left:11.219583872105325%}.row-fluid .offset1:first-child{margin-left:8.56353591160221%;*margin-left:8.457152932878806%}input,textarea,.uneditable-input{margin-left:0}.controls-row [class*="span"]+[class*="span"]{margin-left:20px}input.span12,textarea.span12,.uneditable-input.span12{width:710px}input.span11,textarea.span11,.uneditable-input.span11{width:648px}input.span10,textarea.span10,.uneditable-input.span10{width:586px}input.span9,textarea.span9,.uneditable-input.span9{width:524px}input.span8,textarea.span8,.uneditable-input.span8{width:462px}input.span7,textarea.span7,.uneditable-input.span7{width:400px}input.span6,textarea.span6,.uneditable-input.span6{width:338px}input.span5,textarea.span5,.uneditable-input.span5{width:276px}input.span4,textarea.span4,.uneditable-input.span4{width:214px}input.span3,textarea.span3,.uneditable-input.span3{width:152px}input.span2,textarea.span2,.uneditable-input.span2{width:90px}input.span1,textarea.span1,.uneditable-input.span1{width:28px}}@media(max-width:767px){body{padding-right:20px;padding-left:20px}.navbar-fixed-top,.navbar-fixed-bottom{margin-right:-20px;margin-left:-20px}.container-fluid{padding:0}.dl-horizontal dt{float:none;width:auto;clear:none;text-align:left}.dl-horizontal dd{margin-left:0}.container{width:auto}.row-fluid{width:100%}.row,.thumbnails{margin-left:0}.thumbnails>li{float:none;margin-left:0}[class*="span"],.row-fluid [class*="span"]{display:block;float:none;width:auto;margin-left:0}.span12,.row-fluid .span12{width:100%;-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box}.input-large,.input-xlarge,.input-xxlarge,input[class*="span"],select[class*="span"],textarea[class*="span"],.uneditable-input{display:block;width:100%;min-height:30px;-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box}.input-prepend input,.input-append input,.input-prepend input[class*="span"],.input-append input[class*="span"]{display:inline-block;width:auto}.modal{position:fixed;top:20px;right:20px;left:20px;width:auto;margin:0}.modal.fade.in{top:auto}}@media(max-width:480px){.nav-collapse{-webkit-transform:translate3d(0,0,0)}.page-header h1 small{display:block;line-height:20px}input[type="checkbox"],input[type="radio"]{border:1px solid #ccc}.form-horizontal .control-group>label{float:none;width:auto;padding-top:0;text-align:left}.form-horizontal .controls{margin-left:0}.form-horizontal .control-list{padding-top:0}.form-horizontal .form-actions{padding-right:10px;padding-left:10px}.modal{top:10px;right:10px;left:10px}.modal-header .close{padding:10px;margin:-10px}.carousel-caption{position:static}}@media(max-width:979px){body{padding-top:0}.navbar-fixed-top,.navbar-fixed-bottom{position:static}.navbar-fixed-top{margin-bottom:20px}.navbar-fixed-bottom{margin-top:20px}.navbar-fixed-top .navbar-inner,.navbar-fixed-bottom .navbar-inner{padding:5px}.navbar .container{width:auto;padding:0}.navbar .brand{padding-right:10px;padding-left:10px;margin:0 0 0 -5px}.nav-collapse{clear:both}.nav-collapse .nav{float:none;margin:0 0 10px}.nav-collapse .nav>li{float:none}.nav-collapse .nav>li>a{margin-bottom:2px}.nav-collapse .nav>.divider-vertical{display:none}.nav-collapse .nav .nav-header{color:#555;text-shadow:none}.nav-collapse .nav>li>a,.nav-collapse .dropdown-menu a{padding:9px 15px;font-weight:bold;color:#555;-webkit-border-radius:3px;-moz-border-radius:3px;border-radius:3px}.nav-collapse .btn{padding:4px 10px 4px;font-weight:normal;-webkit-border-radius:4px;-moz-border-radius:4px;border-radius:4px}.nav-collapse .dropdown-menu li+li a{margin-bottom:2px}.nav-collapse .nav>li>a:hover,.nav-collapse .dropdown-menu a:hover{background-color:#f2f2f2}.navbar-inverse .nav-collapse .nav>li>a:hover,.navbar-inverse .nav-collapse .dropdown-menu a:hover{background-color:#111}.nav-collapse.in .btn-group{padding:0;margin-top:5px}.nav-collapse .dropdown-menu{position:static;top:auto;left:auto;display:block;float:none;max-width:none;padding:0;margin:0 15px;background-color:transparent;border:0;-webkit-border-radius:0;-moz-border-radius:0;border-radius:0;-webkit-box-shadow:none;-moz-box-shadow:none;box-shadow:none}.nav-collapse .dropdown-menu:before,.nav-collapse .dropdown-menu:after{display:none}.nav-collapse .dropdown-menu .divider{display:none}.nav-collapse .navbar-form,.nav-collapse .navbar-search{float:none;padding:10px 15px;margin:10px 0;border-top:1px solid #f2f2f2;border-bottom:1px solid #f2f2f2;-webkit-box-shadow:inset 0 1px 0 rgba(255,255,255,0.1),0 1px 0 rgba(255,255,255,0.1);-moz-box-shadow:inset 0 1px 0 rgba(255,255,255,0.1),0 1px 0 rgba(255,255,255,0.1);box-shadow:inset 0 1px 0 rgba(255,255,255,0.1),0 1px 0 rgba(255,255,255,0.1)}.navbar .nav-collapse .nav.pull-right{float:none;margin-left:0}.nav-collapse,.nav-collapse.collapse{height:0;overflow:hidden}.navbar .btn-navbar{display:block}.navbar-static .navbar-inner{padding-right:10px;padding-left:10px}}@media(min-width:980px){.nav-collapse.collapse{height:auto!important;overflow:visible!important}} 10 | -------------------------------------------------------------------------------- /docs/bmc/css/canvas.css: -------------------------------------------------------------------------------- 1 | BODY {font-family: 'Headland One', serif;} 2 | 3 | H1 {font-weight: 900;} 4 | 5 | #bizcanvas { 6 | border: 3px solid black; 7 | width: 100%; 8 | } 9 | 10 | #bizcanvas td { 11 | vertical-align: top; 12 | height: 200px; 13 | width: 200px; 14 | padding: 6px; 15 | } 16 | 17 | 18 | #bizcanvas H4 { 19 | font-weight: 700; 20 | font-size: 1em; 21 | } 22 | 23 | #bizcanvas H5 { 24 | font-weight: 700; 25 | font-size: 0.7em; 26 | } 27 | 28 | #bizcanvas p { 29 | font-weight: 300; 30 | font-size: 0.8em; 31 | } 32 | -------------------------------------------------------------------------------- /docs/bmc/img/glyphicons-halflings-white.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/docs/bmc/img/glyphicons-halflings-white.png -------------------------------------------------------------------------------- /docs/bmc/img/glyphicons-halflings.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/techlead/6ac48201022b417c697bdd4e618d014bc18a0357/docs/bmc/img/glyphicons-halflings.png -------------------------------------------------------------------------------- /docs/bmc/js/bootstrap.min.js: -------------------------------------------------------------------------------- 1 | /*! 2 | * Bootstrap.js by @fat & @mdo 3 | * Copyright 2012 Twitter, Inc. 4 | * http://www.apache.org/licenses/LICENSE-2.0.txt 5 | */ 6 | !function(e){e(function(){"use strict";e.support.transition=function(){var e=function(){var e=document.createElement("bootstrap"),t={WebkitTransition:"webkitTransitionEnd",MozTransition:"transitionend",OTransition:"oTransitionEnd otransitionend",transition:"transitionend"},n;for(n in t)if(e.style[n]!==undefined)return t[n]}();return e&&{end:e}}()})}(window.jQuery),!function(e){"use strict";var t='[data-dismiss="alert"]',n=function(n){e(n).on("click",t,this.close)};n.prototype.close=function(t){function s(){i.trigger("closed").remove()}var n=e(this),r=n.attr("data-target"),i;r||(r=n.attr("href"),r=r&&r.replace(/.*(?=#[^\s]*$)/,"")),i=e(r),t&&t.preventDefault(),i.length||(i=n.hasClass("alert")?n:n.parent()),i.trigger(t=e.Event("close"));if(t.isDefaultPrevented())return;i.removeClass("in"),e.support.transition&&i.hasClass("fade")?i.on(e.support.transition.end,s):s()},e.fn.alert=function(t){return this.each(function(){var r=e(this),i=r.data("alert");i||r.data("alert",i=new n(this)),typeof t=="string"&&i[t].call(r)})},e.fn.alert.Constructor=n,e(function(){e("body").on("click.alert.data-api",t,n.prototype.close)})}(window.jQuery),!function(e){"use strict";var t=function(t,n){this.$element=e(t),this.options=e.extend({},e.fn.button.defaults,n)};t.prototype.setState=function(e){var t="disabled",n=this.$element,r=n.data(),i=n.is("input")?"val":"html";e+="Text",r.resetText||n.data("resetText",n[i]()),n[i](r[e]||this.options[e]),setTimeout(function(){e=="loadingText"?n.addClass(t).attr(t,t):n.removeClass(t).removeAttr(t)},0)},t.prototype.toggle=function(){var e=this.$element.parent('[data-toggle="buttons-radio"]');e&&e.find(".active").removeClass("active"),this.$element.toggleClass("active")},e.fn.button=function(n){return this.each(function(){var r=e(this),i=r.data("button"),s=typeof n=="object"&&n;i||r.data("button",i=new t(this,s)),n=="toggle"?i.toggle():n&&i.setState(n)})},e.fn.button.defaults={loadingText:"loading..."},e.fn.button.Constructor=t,e(function(){e("body").on("click.button.data-api","[data-toggle^=button]",function(t){var n=e(t.target);n.hasClass("btn")||(n=n.closest(".btn")),n.button("toggle")})})}(window.jQuery),!function(e){"use strict";var t=function(t,n){this.$element=e(t),this.options=n,this.options.slide&&this.slide(this.options.slide),this.options.pause=="hover"&&this.$element.on("mouseenter",e.proxy(this.pause,this)).on("mouseleave",e.proxy(this.cycle,this))};t.prototype={cycle:function(t){return t||(this.paused=!1),this.options.interval&&!this.paused&&(this.interval=setInterval(e.proxy(this.next,this),this.options.interval)),this},to:function(t){var n=this.$element.find(".item.active"),r=n.parent().children(),i=r.index(n),s=this;if(t>r.length-1||t<0)return;return this.sliding?this.$element.one("slid",function(){s.to(t)}):i==t?this.pause().cycle():this.slide(t>i?"next":"prev",e(r[t]))},pause:function(t){return t||(this.paused=!0),this.$element.find(".next, .prev").length&&e.support.transition.end&&(this.$element.trigger(e.support.transition.end),this.cycle()),clearInterval(this.interval),this.interval=null,this},next:function(){if(this.sliding)return;return this.slide("next")},prev:function(){if(this.sliding)return;return this.slide("prev")},slide:function(t,n){var r=this.$element.find(".item.active"),i=n||r[t](),s=this.interval,o=t=="next"?"left":"right",u=t=="next"?"first":"last",a=this,f=e.Event("slide",{relatedTarget:i[0]});this.sliding=!0,s&&this.pause(),i=i.length?i:this.$element.find(".item")[u]();if(i.hasClass("active"))return;if(e.support.transition&&this.$element.hasClass("slide")){this.$element.trigger(f);if(f.isDefaultPrevented())return;i.addClass(t),i[0].offsetWidth,r.addClass(o),i.addClass(o),this.$element.one(e.support.transition.end,function(){i.removeClass([t,o].join(" ")).addClass("active"),r.removeClass(["active",o].join(" ")),a.sliding=!1,setTimeout(function(){a.$element.trigger("slid")},0)})}else{this.$element.trigger(f);if(f.isDefaultPrevented())return;r.removeClass("active"),i.addClass("active"),this.sliding=!1,this.$element.trigger("slid")}return s&&this.cycle(),this}},e.fn.carousel=function(n){return this.each(function(){var r=e(this),i=r.data("carousel"),s=e.extend({},e.fn.carousel.defaults,typeof n=="object"&&n),o=typeof n=="string"?n:s.slide;i||r.data("carousel",i=new t(this,s)),typeof n=="number"?i.to(n):o?i[o]():s.interval&&i.cycle()})},e.fn.carousel.defaults={interval:5e3,pause:"hover"},e.fn.carousel.Constructor=t,e(function(){e("body").on("click.carousel.data-api","[data-slide]",function(t){var n=e(this),r,i=e(n.attr("data-target")||(r=n.attr("href"))&&r.replace(/.*(?=#[^\s]+$)/,"")),s=!i.data("modal")&&e.extend({},i.data(),n.data());i.carousel(s),t.preventDefault()})})}(window.jQuery),!function(e){"use strict";var t=function(t,n){this.$element=e(t),this.options=e.extend({},e.fn.collapse.defaults,n),this.options.parent&&(this.$parent=e(this.options.parent)),this.options.toggle&&this.toggle()};t.prototype={constructor:t,dimension:function(){var e=this.$element.hasClass("width");return e?"width":"height"},show:function(){var t,n,r,i;if(this.transitioning)return;t=this.dimension(),n=e.camelCase(["scroll",t].join("-")),r=this.$parent&&this.$parent.find("> .accordion-group > .in");if(r&&r.length){i=r.data("collapse");if(i&&i.transitioning)return;r.collapse("hide"),i||r.data("collapse",null)}this.$element[t](0),this.transition("addClass",e.Event("show"),"shown"),e.support.transition&&this.$element[t](this.$element[0][n])},hide:function(){var t;if(this.transitioning)return;t=this.dimension(),this.reset(this.$element[t]()),this.transition("removeClass",e.Event("hide"),"hidden"),this.$element[t](0)},reset:function(e){var t=this.dimension();return this.$element.removeClass("collapse")[t](e||"auto")[0].offsetWidth,this.$element[e!==null?"addClass":"removeClass"]("collapse"),this},transition:function(t,n,r){var i=this,s=function(){n.type=="show"&&i.reset(),i.transitioning=0,i.$element.trigger(r)};this.$element.trigger(n);if(n.isDefaultPrevented())return;this.transitioning=1,this.$element[t]("in"),e.support.transition&&this.$element.hasClass("collapse")?this.$element.one(e.support.transition.end,s):s()},toggle:function(){this[this.$element.hasClass("in")?"hide":"show"]()}},e.fn.collapse=function(n){return this.each(function(){var r=e(this),i=r.data("collapse"),s=typeof n=="object"&&n;i||r.data("collapse",i=new t(this,s)),typeof n=="string"&&i[n]()})},e.fn.collapse.defaults={toggle:!0},e.fn.collapse.Constructor=t,e(function(){e("body").on("click.collapse.data-api","[data-toggle=collapse]",function(t){var n=e(this),r,i=n.attr("data-target")||t.preventDefault()||(r=n.attr("href"))&&r.replace(/.*(?=#[^\s]+$)/,""),s=e(i).data("collapse")?"toggle":n.data();n[e(i).hasClass("in")?"addClass":"removeClass"]("collapsed"),e(i).collapse(s)})})}(window.jQuery),!function(e){"use strict";function r(){i(e(t)).removeClass("open")}function i(t){var n=t.attr("data-target"),r;return n||(n=t.attr("href"),n=n&&n.replace(/.*(?=#[^\s]*$)/,"")),r=e(n),r.length||(r=t.parent()),r}var t="[data-toggle=dropdown]",n=function(t){var n=e(t).on("click.dropdown.data-api",this.toggle);e("html").on("click.dropdown.data-api",function(){n.parent().removeClass("open")})};n.prototype={constructor:n,toggle:function(t){var n=e(this),s,o;if(n.is(".disabled, :disabled"))return;return s=i(n),o=s.hasClass("open"),r(),o||(s.toggleClass("open"),n.focus()),!1},keydown:function(t){var n,r,s,o,u,a;if(!/(38|40|27)/.test(t.keyCode))return;n=e(this),t.preventDefault(),t.stopPropagation();if(n.is(".disabled, :disabled"))return;o=i(n),u=o.hasClass("open");if(!u||u&&t.keyCode==27)return n.click();r=e("[role=menu] li:not(.divider) a",o);if(!r.length)return;a=r.index(r.filter(":focus")),t.keyCode==38&&a>0&&a--,t.keyCode==40&&a').appendTo(document.body),this.options.backdrop!="static"&&this.$backdrop.click(e.proxy(this.hide,this)),i&&this.$backdrop[0].offsetWidth,this.$backdrop.addClass("in"),i?this.$backdrop.one(e.support.transition.end,t):t()}else!this.isShown&&this.$backdrop?(this.$backdrop.removeClass("in"),e.support.transition&&this.$element.hasClass("fade")?this.$backdrop.one(e.support.transition.end,e.proxy(this.removeBackdrop,this)):this.removeBackdrop()):t&&t()}},e.fn.modal=function(n){return this.each(function(){var r=e(this),i=r.data("modal"),s=e.extend({},e.fn.modal.defaults,r.data(),typeof n=="object"&&n);i||r.data("modal",i=new t(this,s)),typeof n=="string"?i[n]():s.show&&i.show()})},e.fn.modal.defaults={backdrop:!0,keyboard:!0,show:!0},e.fn.modal.Constructor=t,e(function(){e("body").on("click.modal.data-api",'[data-toggle="modal"]',function(t){var n=e(this),r=n.attr("href"),i=e(n.attr("data-target")||r&&r.replace(/.*(?=#[^\s]+$)/,"")),s=i.data("modal")?"toggle":e.extend({remote:!/#/.test(r)&&r},i.data(),n.data());t.preventDefault(),i.modal(s).one("hide",function(){n.focus()})})})}(window.jQuery),!function(e){"use strict";var t=function(e,t){this.init("tooltip",e,t)};t.prototype={constructor:t,init:function(t,n,r){var i,s;this.type=t,this.$element=e(n),this.options=this.getOptions(r),this.enabled=!0,this.options.trigger=="click"?this.$element.on("click."+this.type,this.options.selector,e.proxy(this.toggle,this)):this.options.trigger!="manual"&&(i=this.options.trigger=="hover"?"mouseenter":"focus",s=this.options.trigger=="hover"?"mouseleave":"blur",this.$element.on(i+"."+this.type,this.options.selector,e.proxy(this.enter,this)),this.$element.on(s+"."+this.type,this.options.selector,e.proxy(this.leave,this))),this.options.selector?this._options=e.extend({},this.options,{trigger:"manual",selector:""}):this.fixTitle()},getOptions:function(t){return t=e.extend({},e.fn[this.type].defaults,t,this.$element.data()),t.delay&&typeof t.delay=="number"&&(t.delay={show:t.delay,hide:t.delay}),t},enter:function(t){var n=e(t.currentTarget)[this.type](this._options).data(this.type);if(!n.options.delay||!n.options.delay.show)return n.show();clearTimeout(this.timeout),n.hoverState="in",this.timeout=setTimeout(function(){n.hoverState=="in"&&n.show()},n.options.delay.show)},leave:function(t){var n=e(t.currentTarget)[this.type](this._options).data(this.type);this.timeout&&clearTimeout(this.timeout);if(!n.options.delay||!n.options.delay.hide)return n.hide();n.hoverState="out",this.timeout=setTimeout(function(){n.hoverState=="out"&&n.hide()},n.options.delay.hide)},show:function(){var e,t,n,r,i,s,o;if(this.hasContent()&&this.enabled){e=this.tip(),this.setContent(),this.options.animation&&e.addClass("fade"),s=typeof this.options.placement=="function"?this.options.placement.call(this,e[0],this.$element[0]):this.options.placement,t=/in/.test(s),e.remove().css({top:0,left:0,display:"block"}).appendTo(t?this.$element:document.body),n=this.getPosition(t),r=e[0].offsetWidth,i=e[0].offsetHeight;switch(t?s.split(" ")[1]:s){case"bottom":o={top:n.top+n.height,left:n.left+n.width/2-r/2};break;case"top":o={top:n.top-i,left:n.left+n.width/2-r/2};break;case"left":o={top:n.top+n.height/2-i/2,left:n.left-r};break;case"right":o={top:n.top+n.height/2-i/2,left:n.left+n.width}}e.css(o).addClass(s).addClass("in")}},setContent:function(){var e=this.tip(),t=this.getTitle();e.find(".tooltip-inner")[this.options.html?"html":"text"](t),e.removeClass("fade in top bottom left right")},hide:function(){function r(){var t=setTimeout(function(){n.off(e.support.transition.end).remove()},500);n.one(e.support.transition.end,function(){clearTimeout(t),n.remove()})}var t=this,n=this.tip();return n.removeClass("in"),e.support.transition&&this.$tip.hasClass("fade")?r():n.remove(),this},fixTitle:function(){var e=this.$element;(e.attr("title")||typeof e.attr("data-original-title")!="string")&&e.attr("data-original-title",e.attr("title")||"").removeAttr("title")},hasContent:function(){return this.getTitle()},getPosition:function(t){return e.extend({},t?{top:0,left:0}:this.$element.offset(),{width:this.$element[0].offsetWidth,height:this.$element[0].offsetHeight})},getTitle:function(){var e,t=this.$element,n=this.options;return e=t.attr("data-original-title")||(typeof n.title=="function"?n.title.call(t[0]):n.title),e},tip:function(){return this.$tip=this.$tip||e(this.options.template)},validate:function(){this.$element[0].parentNode||(this.hide(),this.$element=null,this.options=null)},enable:function(){this.enabled=!0},disable:function(){this.enabled=!1},toggleEnabled:function(){this.enabled=!this.enabled},toggle:function(){this[this.tip().hasClass("in")?"hide":"show"]()},destroy:function(){this.hide().$element.off("."+this.type).removeData(this.type)}},e.fn.tooltip=function(n){return this.each(function(){var r=e(this),i=r.data("tooltip"),s=typeof n=="object"&&n;i||r.data("tooltip",i=new t(this,s)),typeof n=="string"&&i[n]()})},e.fn.tooltip.Constructor=t,e.fn.tooltip.defaults={animation:!0,placement:"top",selector:!1,template:'
',trigger:"hover",title:"",delay:0,html:!0}}(window.jQuery),!function(e){"use strict";var t=function(e,t){this.init("popover",e,t)};t.prototype=e.extend({},e.fn.tooltip.Constructor.prototype,{constructor:t,setContent:function(){var e=this.tip(),t=this.getTitle(),n=this.getContent();e.find(".popover-title")[this.options.html?"html":"text"](t),e.find(".popover-content > *")[this.options.html?"html":"text"](n),e.removeClass("fade top bottom left right in")},hasContent:function(){return this.getTitle()||this.getContent()},getContent:function(){var e,t=this.$element,n=this.options;return e=t.attr("data-content")||(typeof n.content=="function"?n.content.call(t[0]):n.content),e},tip:function(){return this.$tip||(this.$tip=e(this.options.template)),this.$tip},destroy:function(){this.hide().$element.off("."+this.type).removeData(this.type)}}),e.fn.popover=function(n){return this.each(function(){var r=e(this),i=r.data("popover"),s=typeof n=="object"&&n;i||r.data("popover",i=new t(this,s)),typeof n=="string"&&i[n]()})},e.fn.popover.Constructor=t,e.fn.popover.defaults=e.extend({},e.fn.tooltip.defaults,{placement:"right",trigger:"click",content:"",template:'

'})}(window.jQuery),!function(e){"use strict";function t(t,n){var r=e.proxy(this.process,this),i=e(t).is("body")?e(window):e(t),s;this.options=e.extend({},e.fn.scrollspy.defaults,n),this.$scrollElement=i.on("scroll.scroll-spy.data-api",r),this.selector=(this.options.target||(s=e(t).attr("href"))&&s.replace(/.*(?=#[^\s]+$)/,"")||"")+" .nav li > a",this.$body=e("body"),this.refresh(),this.process()}t.prototype={constructor:t,refresh:function(){var t=this,n;this.offsets=e([]),this.targets=e([]),n=this.$body.find(this.selector).map(function(){var t=e(this),n=t.data("target")||t.attr("href"),r=/^#\w/.test(n)&&e(n);return r&&r.length&&[[r.position().top,n]]||null}).sort(function(e,t){return e[0]-t[0]}).each(function(){t.offsets.push(this[0]),t.targets.push(this[1])})},process:function(){var e=this.$scrollElement.scrollTop()+this.options.offset,t=this.$scrollElement[0].scrollHeight||this.$body[0].scrollHeight,n=t-this.$scrollElement.height(),r=this.offsets,i=this.targets,s=this.activeTarget,o;if(e>=n)return s!=(o=i.last()[0])&&this.activate(o);for(o=r.length;o--;)s!=i[o]&&e>=r[o]&&(!r[o+1]||e<=r[o+1])&&this.activate(i[o])},activate:function(t){var n,r;this.activeTarget=t,e(this.selector).parent(".active").removeClass("active"),r=this.selector+'[data-target="'+t+'"],'+this.selector+'[href="'+t+'"]',n=e(r).parent("li").addClass("active"),n.parent(".dropdown-menu").length&&(n=n.closest("li.dropdown").addClass("active")),n.trigger("activate")}},e.fn.scrollspy=function(n){return this.each(function(){var r=e(this),i=r.data("scrollspy"),s=typeof n=="object"&&n;i||r.data("scrollspy",i=new t(this,s)),typeof n=="string"&&i[n]()})},e.fn.scrollspy.Constructor=t,e.fn.scrollspy.defaults={offset:10},e(window).on("load",function(){e('[data-spy="scroll"]').each(function(){var t=e(this);t.scrollspy(t.data())})})}(window.jQuery),!function(e){"use strict";var t=function(t){this.element=e(t)};t.prototype={constructor:t,show:function(){var t=this.element,n=t.closest("ul:not(.dropdown-menu)"),r=t.attr("data-target"),i,s,o;r||(r=t.attr("href"),r=r&&r.replace(/.*(?=#[^\s]*$)/,""));if(t.parent("li").hasClass("active"))return;i=n.find(".active a").last()[0],o=e.Event("show",{relatedTarget:i}),t.trigger(o);if(o.isDefaultPrevented())return;s=e(r),this.activate(t.parent("li"),n),this.activate(s,s.parent(),function(){t.trigger({type:"shown",relatedTarget:i})})},activate:function(t,n,r){function o(){i.removeClass("active").find("> .dropdown-menu > .active").removeClass("active"),t.addClass("active"),s?(t[0].offsetWidth,t.addClass("in")):t.removeClass("fade"),t.parent(".dropdown-menu")&&t.closest("li.dropdown").addClass("active"),r&&r()}var i=n.find("> .active"),s=r&&e.support.transition&&i.hasClass("fade");s?i.one(e.support.transition.end,o):o(),i.removeClass("in")}},e.fn.tab=function(n){return this.each(function(){var r=e(this),i=r.data("tab");i||r.data("tab",i=new t(this)),typeof n=="string"&&i[n]()})},e.fn.tab.Constructor=t,e(function(){e("body").on("click.tab.data-api",'[data-toggle="tab"], [data-toggle="pill"]',function(t){t.preventDefault(),e(this).tab("show")})})}(window.jQuery),!function(e){"use strict";var t=function(t,n){this.$element=e(t),this.options=e.extend({},e.fn.typeahead.defaults,n),this.matcher=this.options.matcher||this.matcher,this.sorter=this.options.sorter||this.sorter,this.highlighter=this.options.highlighter||this.highlighter,this.updater=this.options.updater||this.updater,this.$menu=e(this.options.menu).appendTo("body"),this.source=this.options.source,this.shown=!1,this.listen()};t.prototype={constructor:t,select:function(){var e=this.$menu.find(".active").attr("data-value");return this.$element.val(this.updater(e)).change(),this.hide()},updater:function(e){return e},show:function(){var t=e.extend({},this.$element.offset(),{height:this.$element[0].offsetHeight});return this.$menu.css({top:t.top+t.height,left:t.left}),this.$menu.show(),this.shown=!0,this},hide:function(){return this.$menu.hide(),this.shown=!1,this},lookup:function(t){var n;return this.query=this.$element.val(),!this.query||this.query.length"+t+""})},render:function(t){var n=this;return t=e(t).map(function(t,r){return t=e(n.options.item).attr("data-value",r),t.find("a").html(n.highlighter(r)),t[0]}),t.first().addClass("active"),this.$menu.html(t),this},next:function(t){var n=this.$menu.find(".active").removeClass("active"),r=n.next();r.length||(r=e(this.$menu.find("li")[0])),r.addClass("active")},prev:function(e){var t=this.$menu.find(".active").removeClass("active"),n=t.prev();n.length||(n=this.$menu.find("li").last()),n.addClass("active")},listen:function(){this.$element.on("blur",e.proxy(this.blur,this)).on("keypress",e.proxy(this.keypress,this)).on("keyup",e.proxy(this.keyup,this)),(e.browser.webkit||e.browser.msie)&&this.$element.on("keydown",e.proxy(this.keydown,this)),this.$menu.on("click",e.proxy(this.click,this)).on("mouseenter","li",e.proxy(this.mouseenter,this))},move:function(e){if(!this.shown)return;switch(e.keyCode){case 9:case 13:case 27:e.preventDefault();break;case 38:e.preventDefault(),this.prev();break;case 40:e.preventDefault(),this.next()}e.stopPropagation()},keydown:function(t){this.suppressKeyPressRepeat=!~e.inArray(t.keyCode,[40,38,9,13,27]),this.move(t)},keypress:function(e){if(this.suppressKeyPressRepeat)return;this.move(e)},keyup:function(e){switch(e.keyCode){case 40:case 38:break;case 9:case 13:if(!this.shown)return;this.select();break;case 27:if(!this.shown)return;this.hide();break;default:this.lookup()}e.stopPropagation(),e.preventDefault()},blur:function(e){var t=this;setTimeout(function(){t.hide()},150)},click:function(e){e.stopPropagation(),e.preventDefault(),this.select()},mouseenter:function(t){this.$menu.find(".active").removeClass("active"),e(t.currentTarget).addClass("active")}},e.fn.typeahead=function(n){return this.each(function(){var r=e(this),i=r.data("typeahead"),s=typeof n=="object"&&n;i||r.data("typeahead",i=new t(this,s)),typeof n=="string"&&i[n]()})},e.fn.typeahead.defaults={source:[],items:8,menu:'',item:'
    • ',minLength:1},e.fn.typeahead.Constructor=t,e(function(){e("body").on("focus.typeahead.data-api",'[data-provide="typeahead"]',function(t){var n=e(this);if(n.data("typeahead"))return;t.preventDefault(),n.typeahead(n.data())})})}(window.jQuery),!function(e){"use strict";var t=function(t,n){this.options=e.extend({},e.fn.affix.defaults,n),this.$window=e(window).on("scroll.affix.data-api",e.proxy(this.checkPosition,this)),this.$element=e(t),this.checkPosition()};t.prototype.checkPosition=function(){if(!this.$element.is(":visible"))return;var t=e(document).height(),n=this.$window.scrollTop(),r=this.$element.offset(),i=this.options.offset,s=i.bottom,o=i.top,u="affix affix-top affix-bottom",a;typeof i!="object"&&(s=o=i),typeof o=="function"&&(o=i.top()),typeof s=="function"&&(s=i.bottom()),a=this.unpin!=null&&n+this.unpin<=r.top?!1:s!=null&&r.top+this.$element.height()>=t-s?"bottom":o!=null&&n<=o?"top":!1;if(this.affixed===a)return;this.affixed=a,this.unpin=a=="bottom"?r.top-n:null,this.$element.removeClass(u).addClass("affix"+(a?"-"+a:""))},e.fn.affix=function(n){return this.each(function(){var r=e(this),i=r.data("affix"),s=typeof n=="object"&&n;i||r.data("affix",i=new t(this,s)),typeof n=="string"&&i[n]()})},e.fn.affix.Constructor=t,e.fn.affix.defaults={offset:0},e(window).on("load",function(){e('[data-spy="affix"]').each(function(){var t=e(this),n=t.data();n.offset=n.offset||{},n.offsetBottom&&(n.offset.bottom=n.offsetBottom),n.offsetTop&&(n.offset.top=n.offsetTop),t.affix(n)})})}(window.jQuery); -------------------------------------------------------------------------------- /docs/bmc/js/canvas.js: -------------------------------------------------------------------------------- 1 | $(document).ready(function() { 2 | $('a[rel=popover]').click(function() { 3 | $(this).popover('toggle'); 4 | }); 5 | $('a[rel=popover]').hover(function() { 6 | $(this).popover('show'); 7 | }, function() { 8 | $(this).popover('hide'); 9 | }); 10 | }); 11 | 12 | -------------------------------------------------------------------------------- /docs/bmc/startup.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | The Business Model Canvas 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 |
    14 |

    The Business Model Canvas

    15 | 16 | 17 | 18 | 23 | 27 | 32 | 36 | 41 | 42 | 43 | 47 | 51 | 52 | 53 | 57 | 61 | 62 |
    19 |

    Problem

    20 |

    Need to present business models for partner to discuss with

    21 |

    22 |     		24 |

    Solution

    25 |

    ...

    26 |     		28 |

    Value Proposition

    29 |

    ...

    30 |
    High-level concept
    31 |     		33 |

    Unfair Advantage

    34 |

    ...

    35 |     		37 |

    Customer Segments

    38 |

    ...

    39 |
    Early adopters
    40 |
    44 |

    Key Metrics

    45 |

    ...

    46 |     		48 |

    Channels

    49 |

    ...

    50 |
    54 |

    Cost Structure

    55 |

    ...

    56 |     		58 |

    Revenue Streams

    59 |

    ...

    60 |
    63 | 64 |
    65 | 66 | 67 | 68 | 69 | 70 | 71 | -------------------------------------------------------------------------------- /docs/mvp/README.md: -------------------------------------------------------------------------------- 1 | # MVP Prototype 2 | 3 | 1. Market Search (Done) 4 | 5 | with [Path to Tech Lead] (ps：迈向 Tech Lead 之路) 的传播 6 | 7 | 2. Express your idea 8 | 9 | 10 | 3. Design Process 11 | 12 | 13 | 4. User Flow 14 | 15 | 16 | 5. Project features 17 | 18 | 19 | 20 | 6. Build MVP 21 | 22 | 23 | 7. Build, Measure, and Learn 24 | 25 | 26 | 27 | 8. Measuring 28 | -------------------------------------------------------------------------------- /docs/mvp/model.md: -------------------------------------------------------------------------------- 1 | # MVP 2 | 3 | ## Functionality 4 | 5 | 6 | ## Reliability 7 | 8 | 9 | ## Usability 10 | 11 | 12 | ## Brilliant Design 13 | -------------------------------------------------------------------------------- /evaluate/README.md: -------------------------------------------------------------------------------- 1 | # Evaluate Tools 2 | 3 | ## Current Process Tools 4 | 5 | ## Team Development Model 6 | 7 | 8 | ## 你需要一个 Tech Lead 吗？ 9 | 10 | -------------------------------------------------------------------------------- /faq/README.md: -------------------------------------------------------------------------------- 1 | # Tech Lead 常见问题 2 | 3 | # 1. Tech Lead 需要编码吗？ 20% 的时间 4 | -------------------------------------------------------------------------------- /model/README.md: -------------------------------------------------------------------------------- 1 | ## Level Defined 2 | 3 | - Novice 4 | - Advanced Beginner 5 | - Practitioner 6 | - Proficient 7 | - Expert 8 | 9 | 10 | 相关模型： 11 | 12 | - [Agile Practise](agile-practise.md) 13 | - [Tech Lead Value](value.md) 14 | - [Tech Lead Model](tl-model.md) 15 | - [Personal effectiveness](personal-effectiveness.md) 16 | -------------------------------------------------------------------------------- /model/agile-practise.md: -------------------------------------------------------------------------------- 1 | | STAGE | Requirement Management | Team Collaboration | Visualisation | Build-in Quality | DevOps | 2 | |------|------|-----|------|-----|----| 3 | 4 | 5 | 6 | **Requirement Management** 7 | 8 | - Single Backlog 9 | - Spring Planning 10 | - Spring Review 11 | - User Story 12 | - User Story Map 13 | - Prototyping Validation 14 | - Business Model Canvas 15 | 16 | **Team Collaboration** 17 | 18 | - Daily Standup 19 | - Cross Functional Team 20 | - User Stroy Estimation 21 | 22 | **Process** 23 | 24 | - Story Kick-off 25 | - Story Desk Check 26 | 27 | **Visualisation** 28 | 29 | - Scrum Boards (like Jira) 30 | - Agile Tools (Jira) Reports 31 | - Physical Story Wall 32 | - CI Monitor 33 | - Team Level Tech Radar 34 | - Path to Production 35 | 36 | **Quality** 37 | 38 | - Code quality analysis 39 | - Continuous integration 40 | - Exploratory testing 41 | - Infrastructure testing 42 | - Mobile automated testing 43 | - Performance and load testing 44 | - Quality strategy 45 | - Security testing 46 | - Test Automation 47 | - Test data management 48 | 49 | Exmples 50 | 51 | - Code Review 52 | - Unit Test/API Test/Layered Auto Testing 53 | - Tech Debt 54 | - Code Static Analysis 55 | 56 | **DevOps Culture** 57 | 58 | - Auto Database Management 59 | - CI Pipeline 60 | - Auto Deployment 61 | - Feture Toggle 62 | - Containerisation 63 | - Continuous Monitoring 64 | 65 | 66 | 67 | https://www.scaledagileframework.com/safe-program-consultant/ 68 | 69 | [SAFe](https://www.scaledagileframework.com/) 70 | 71 | -------------------------------------------------------------------------------- /model/personal-effectiveness.md: -------------------------------------------------------------------------------- 1 | # Personal effectiveness 2 | 3 | 4 | 5 | -------------------------------------------------------------------------------- /model/tl-model.md: -------------------------------------------------------------------------------- 1 | # Tech Lead Model 2 | 3 | Tech Lead can be a Team Lead, also Project Manager 4 | 5 | ## Skills Scope 6 | 7 | ### Architecture, thinking in future 8 | 9 | ### Programmer, code for follow 10 | 11 | ### Lead, lead by example 12 | 13 | ## Daily 14 | 15 | ### Bridging the Business 16 | 17 | ### Release People 18 | 19 | - Meetting 20 | - Delegate 21 | 22 | ### Better Process 23 | 24 | - Split Work 25 | 26 | ### Make Self 27 | 28 | - Time Management 29 | - Focus Ability 30 | -------------------------------------------------------------------------------- /model/tw-model.md: -------------------------------------------------------------------------------- 1 | Define: 2 | 3 | - 1. 需要经常指导，不能独立完成 4 | - 2. 基本独立工作，需要经常检查 5 | - 3. 值得信任，可以指导别人 6 | - 4. 该领域专家，可以解决复杂问题 7 | 8 | level 1：接受培训 9 | level 2：能用（不能独立，还需要指导） 10 | level 3：讲 Session（独立完成） 11 | level 4：组织培训（Drive） 12 | 13 | ## 微服务架构 14 | 15 | 书单：《微服务设计》、《微服务架构设计模式》、《领域驱动设计》、《领域驱动设计模式、原理与实践》、《领域特定语言》 16 | 17 | ### Level 1 18 | 19 | - 参加 EventStorming 培训 20 | - 参加 DDD 战略培训 21 | - 了解 DDD 相关的架构 22 | - 学习典型的微服务架构案例 23 | 24 | ### Level 2 25 | 26 | - 参与微服务项目 Inception 27 | - 完成单一部分 EventStorming 工作 28 | 29 | ### Level 3 30 | 31 | - 能主导中小型微服务项目 Inception 32 | - 将成果写成案例讲讲 Session 33 | 34 | ### Level 4 35 | 36 | - 参与大中型客户的微服务项目售前，并能独立完成 Inception 37 | - 进行微服务相关的 workshop 38 | 39 | ## 常规软件架构 40 | 41 | 书单：《架构整洁之道》、《程序员必读之软件架构》、《演进式架构》、《前端架构：从入门到微前端》 42 | 43 | ### Level 1 44 | 45 | - 参加 TL 培训，掌握 C4 架构设计方法 46 | - 学习典型案例 47 | - 能够绘制系统架构图和部署架构图 48 | 49 | ### Level 2 50 | 51 | - 参与常规项目的 Inception，并完成部分架构设计工作 52 | - **总结现有经历过项目的架构** 53 | - Spike 具体技术解决方案 54 | - 尝试利用项目做练习，然后评估能否实施 55 | 56 | ### Level 3 57 | 58 | - 主导一个常规项目 Inception，并把成果写成案例讲 Session 59 | - **搭建项目脚手架** 60 | - **能区分出每种架构优劣势、适用场景** 61 | - 对同事提出的架构方案，会提出意见、问题 62 | - 可以承担架构的技术决策 63 | 64 | ### Level 4 65 | 66 | - 参与大中型客户的常规项目售前，并独立完成 Inception 67 | - 对软件架构守护自动化 68 | - 了解特定领域最新发展和最佳实践，并能合理地引入项目中。 69 | 70 | ## DevOps 71 | 72 | 书单：《持续交付》、《DevOps实践指南》、《SRE：Google运维解密》 73 | 74 | ### Level 1 75 | 76 | - 有 DevOps 基础，能做 CI/CD 的维护工作 77 | - 了解 Docker、K8S 等容器化技术 78 | 79 | ### Level 2 80 | 81 | - 在普通项目中项目能承担 DevOps 工作 82 | - 了解云原生架构 83 | 84 | ### Level 3 85 | 86 | - 能完成项目所有的 DevOps 工作：如搭建 ELK、编写 DockerFile 等 87 | 88 | ### Level 4 89 | 90 | - 能进入 DevOps 项目承担主力 91 | 92 | ## 编码 93 | 94 | 书单：《代码整洁之道》、《重构》、《设计模式》、《从重构到模式》 95 | 96 | ### Level 1 97 | 98 | - 合理的 TDD 99 | - 了解重构手法 100 | - 了解和实践过常见设计模式 101 | 102 | ### Level 2 103 | 104 | - 在 Code Review 能发现问题 105 | - 在合适的时候，使用设计模式 106 | - 熟悉 SOLID 原则 107 | 108 | ### Level 3 109 | 110 | - 具有良好的 TDD、重构习惯和技巧，可以指导团队其他人 111 | - 编码能力能够承担项目所有难度的卡片 112 | - 在 Code review 上可以给出建设性意见 113 | 114 | ### Level 4 115 | 116 | - 组织 OO BootCamp 117 | 118 | ## 软件质量 119 | 120 | 书单：《测试驱动开发 》、《修改代码的艺术》、《探索式软件测试》 121 | 122 | ### Level 1 123 | 124 | - 能够跟 BA 和 QA 良好协作，正确理解业务需求，代码返工率较低，生产问题较少 125 | - 了解不同类型的测试（测试金字塔） 126 | - 学习如何进行质量诊断，常见的改进方案 127 | 128 | ### Level 2 129 | 130 | - 对于代码质量有较高的要求，是前/后端测试覆盖率的贡献者 131 | - 对于复杂功能的设计，在质量和稳定性的考虑上略有欠缺 132 | - 注重代码质量，自己花时间搭建起测试框架 133 | 134 | ### Level 3 135 | 136 | - 设计并实施项目的测试策略 137 | - 在交付过程中设计，并实施质量改进计划 138 | - 进行单元测试相关的 Session 139 | 140 | ### Level 4 141 | 142 | - 完成多个项目的质量诊断、设计改进方案、测量改进效果 143 | - 发现潜在的软件质量问题，并**驱动**解决。 144 | 145 | ## 敏捷开发流程 146 | 147 | 书单：《敏捷软件开发》、《学习敏捷》、《用户故事与敏捷方法》、《精益思想》 148 | 149 | ### Level 1 150 | 151 | - 了解敏捷软件开发 152 | - 熟悉敏捷软件开发命命周期 153 | 154 | ### Level 2 155 | 156 | - 对敏捷实践有一定的了解，能够给出一些意见 157 | - 对看板项目敏捷方法产出文字总结，包含看板敏捷方法的优缺点 158 | - 分享看板可能适用的敏捷方法 159 | - 理解和掌握敏捷实践，不断深入扩展自己的技术边界，扩大技术深度及广度。 160 | 161 | ### Level 3 162 | 163 | - 在交付过程中设计并实施流程改进计划 164 | - 能根据项目需求，因地制宜在项目中进行敏捷实践设计、裁剪及推动。 165 | 166 | ### Level 4 167 | 168 | - 能够完成多个项目的健康诊断、设计改进方案、测量改进效果 169 | - 能在各个领域综合运用并高效解决问题。 170 | -------------------------------------------------------------------------------- /model/value.md: -------------------------------------------------------------------------------- 1 | # Tech Lead 价值观 2 | 3 | 4 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "tltools", 3 | "version": "0.0.1", 4 | "description": "A Toolbox for Tech Lead", 5 | "main": "index.js", 6 | "scripts": { 7 | "test": "echo \"Error: no test specified\" && exit 1" 8 | }, 9 | "repository": { 10 | "type": "git", 11 | "url": "git+https://github.com/phodal/tltools.git" 12 | }, 13 | "keywords": [ 14 | "toolbox", 15 | "tech", 16 | "lead" 17 | ], 18 | "author": "Phodal HUANG", 19 | "license": "MIT", 20 | "bugs": { 21 | "url": "https://github.com/phodal/tltools/issues" 22 | }, 23 | "homepage": "https://github.com/phodal/tltools#readme" 24 | } 25 | --------------------------------------------------------------------------------