读书笔记 - 朱赟的技术管理课

读书给我力量，有些书籍给你第一眼的感受就是：爱了；第二眼的感受就是：买了；第三眼的感受就是：读完了、舒服了。

本文为 《朱赟的技术管理课》 读书笔记。

jsliang 没当过管理者，因此文中相关心得，皆为我的粗鄙看法，不构成价值参考，也不构成购买建议。

一 目录

不折腾的前端，和咸鱼有什么区别

目录
一 目录
二 前言
三 精彩语录摘抄
四 新人成长
4.1 新人成长：个人成长
4.2 新人成长：管理技巧
4.3 新人成长：个人思考
五 项目开发
5.1 项目开发：工做分配
5.2 项目开发：受权
5.3 项目开发：A/B 测试
5.4 项目开发：Code Review
5.5 项目开发：项目延期
5.6 项目开发：项目 Bug
六 团队管理
6.1 团队管理：团队成员
6.2 团队管理：晋升
6.3 团队管理：建议和意见
6.4 团队管理：一对一沟通
6.5 团队管理：指望与被指望
6.6 团队管理：职场规划
七 其余
7.1 其余：说 “不” 的技巧
7.2 其余：后续日子的思考
八 总结

二 前言

人总要成长，总要走出本身的温馨区，变幻无穷的前端行业尤为适合这句话，除非你肯定将来日子能当一枚千篇一概的复制粘贴工程师，不然你就要面临各式各样的挑战。

摘抄下 jsliang 的工做笔记目录：

• Node 经常使用工具库（时间处理、Markdown 转 Word、正则表达式）
• 自动化测试（Jest、Puppeteer）
• Git
• Charles
• ……

固然技术是折腾不完的。

世事总在变化，你总要挑战本身极限，这篇文章就是讲挑战自个人其中一条道路：技术管理。

这仅仅是零散的观点汇总，贴近 jsliang “私有化”，不构成参考建议，但愿对你有所帮助

三 精彩语录摘抄

在观看书籍的过程当中，jsliang 摘抄了一些以为很是不错的语录：

• 《04 | 如何帮助团队成员成长》一个技术管理者的成功并不在于本身代码多好、能力多强，他的成功必定创建在团队成功的基础之上。只有团队成员不断成长，这个团队才能够作成更大的事情，而你才能够在团队的基础上，站得更高、看得更远。
• 《05 | 当咱们给别人提意见时，要注意些什么？》因此在工做中适当放低姿态，每每更容易得到尊重。不要老是试图居高临下地提意见，尤为是你在对方内心尚未创建任何信任和威信的时候，不要贸然给别人提负面意见。

四 新人成长

在读书的时候，若是做业不会作，你能够问同窗，直接 Copy 做业；你也能够问老师，获得答案或者启发和引导。

工做了以后也同样，你能够 Copy 代码，也能够获取引导和启发，可是总归仍是得到引导和启发比较好的。

4.1 新人成长：个人成长

在入职金山后，做为一枚萌新，身边的小伙伴和组长的确给了我不少启发：

• 带着方案咨询上级，不作无谓的探讨

人急起来每每会将本身的但愿寄托到某我的能快速帮忙解决问题上，jsliang 也同样，在刚入职的时候就常常将一些问题抛出来咨询组长或者身边小伙伴。

虽然新人成长下直接咨询问题无可厚非，可是有些内容仍是须要自身先行探讨，再进一步咨询的。

这点我一开始就作得不好。

因此后面碰到问题，我会先经过本身思考和资料查询，选出 A、B、C 几种方案，而后带着问题和方案去咨询领导和小伙伴，从而获取到有用的引导和启发，进而修改本身的方案。

这点我也尝试在给身边小伙伴们解答时使用，固然可能有些小伙伴会以为我不够直爽，没有给最直白的答案

这点更让我印象深入的是一句话：雇佣你过来是作事的，安排你作一个需求是想让你接触这类问题的处理（这不是一个紧急的问题），咱们毕竟是一个对外服务的小组，若是有问题你都问领导，那就是领导作事了，那招你过来有何用？

• 有些流程适合解谜，有些流程适合解答

有些问题并非直接给你代码就好的，例如新人进来每每不会分配比较复杂的任务，都是让你适应新流程的需求（除非是招你过来要立立刻手，解决重大问题的）。

可能这个问题在熟悉流程的老人身上，花几分钟时间就能搞定，而新人须要琢磨好久。

可是，若是这个问题新人不去了解全流程，不去熟悉它，那么后面碰到这块内容，他仍是会抵触。

4.2 新人成长：管理技巧

• 不要将时间耗费在新人上

不能由于本身对系统各类设计和业务逻辑熟悉，因此直接给答案，或者帮忙找答案。

由于这样子会致使：

1. 在你这里容易获得答案，因而问你问题的愈来愈多，杂事也多
2. 你给的答案，下次有问题还来找你
3. 忽然你不回答了，那么新人会怎么想

你须要作的应该是将这个技术点经过任务形式或者其余方法发布下去，让新人自行调查，而后给予提示和启发。

• 给答案 V.S. 给线索找答案

何时适合直接给答案？何时适合给线索，让对方找答案？

1. 若是是对项目的流程熟悉，项目的搭建，那么就适合给答案
2. 若是是对项目需求的处理，问题的分析，那么就适合给线索

• 如何引导

1. 若是有方案，帮忙分析
2. 若是没方案，诱导分析

不要太具象，也不要太抽象。

例如一个需求，应该代表本身想要的内容，UI 大概长啥样，而不是让对方任意发挥，而后审查后又以为不足。亦或者让对方先给出本身的方案，审对后再开发。

• 工做弹性

工做弹性是根据具体业务需求，让本身可以有足够的处理能力

1. 让新人正确面对本身的压力

   1. 已发生的，思考和复盘
   2. 未发生的，琢磨将来计划和规划，思考不足之处
   3. 前 2 点不要一根筋

2. 当有压力的时候，要学会走出思惟的误区，打造本身的弹性能力

   1. 按期 Review，看下本身的改进是否有效果
   2. 不要由于不可控因素责怪本身，例如公司忽然加班，也不要让这个因素让本身放弃，松持有道
3. 与积极向上的人作朋友，保持良好的心态

4.3 新人成长：个人思考

• 【解答】搭建开发环境
• 【解谜】带处理方案咨询问题

五 项目开发

在项目开发的过程当中，咱们可能须要关注一些点：

• A/B 测试
• Code Review
• 项目延期
• 线上问题

5.1 项目开发：工做分配

团队负责人的工做职责之一就是工做的分解和受权。

在没有创建充分信任的状况下，该如何分配工做？

1. 创建参考基线。在和一我的没有任何接触的状况下，经过第三方评价、我的履历以及员工作过的项目|产品来衡量能力
2. 问对问题比正确答案更重要。将任务交接到员工手中前，尽可能告诉他当前任务的详细情景，看他有什么问题和想法
3. 工期估算。须要多久完成，大概何时，须要怎么样的资源
4. 执行力。有些成员可能沟通、计划能力都很强，可是执行力比较差，会滞后、遇难而退、有始无终，这些成员不适合托付大事
5. 后期维护。项目的完结并非项目的结束，还应包括项目后期的 Bug 维护，跟进用户的反馈，完成产品的迭代升级等

须要注意的一些细节：

1. 职场新人。有些新人可能颇有潜力，可是经验不足。因此初期不要轻易否认他们的工做，而是更耐心地指导让他们快速进步
2. 针对不一样类型的员工分配工做。不一样类型的员工会给团队带来不同的内容，有些人可能逻辑性强，有些人可能技术性强，都会带来不同的反馈

5.2 项目开发：受权

研发组长可能会参与全部的设计和讨论，甚至不少核心的代码都是本身写；组里其余人的代码也会亲自过目；不管多么忙都会参与全部的代码评审，作到对每个改动都心中有数。

随着业务规模的扩大，人员的增多，事事亲为会变得愈来愈吃力，加班变成常态，这时候就须要带人和受权，将事情分配出去让别人作。

误区：

1. 事情能不能作好和彻底按照你的方式作好，是两码事，别人有别人的工做方式，也能把事情作好。
2. 介入和非介入并非非黑即白，用什么方式介入，在哪些地方介入，才是关键

受权和分配任务须要注意：

1. 明确目标。让对方知道最终想要达成的结果和对任务完成的指望值。
2. 制定计划。保持跟进很重要
3. 给出反馈。给予对方正面的反馈很重要，给予确定。

5.3 项目开发：A/B 测试

若是产品须要修改 UI 上某个模块的交互设计，引导用户点击 “下一步” 按钮，而后不知道哪种效果更佳，这时候就须要 A/B 测试。

经过 A/B 测试，让一部分用户体验新的 UI，另外一部分用户继续使用旧的 UI，再对采集回来的数据进行分析：

• 哪一种 UI 下，用户更愿意继续往下走

A/B 测试须要注意的问题：

1. 不要过度相信你的直觉。将你的想法和别的工程师、设计师、产品经理深刻交流，经过沟通获取更好的选择
2. 实验样本的数量和分配很重要。实验数量小、随机分配不平均，都不能很好地作 A/B 测试
3. 分析维度要全面。A 与 B 对照组，发现 A > B，可是 A 下网络延迟更差，或者出错率更高，那就不是好的设计
4. 数据埋点很重要。经过前端埋点采集实时数据，后端埋点采集实时事件或者聚合数据。

5.4 项目开发：Code Review

开发应当对本身的代码自测，而后提交上去进行审核。

• commit：代码改动

commit 应当注明本次改动的类型：

1. feat，需求功能
2. fix，功能修复
3. ……

每次 commit 的功能应该是单一的，例如本次 commit 修改了对应文档上的内容，下次的 commit 添加了功能代码，这些在 GitLab 等能根据具体的 commit 去查看改动，而不会乱七八糟丢在一块儿。

• pull request：代码提交请求

pull request 简称 PR，是指将你的代码合并到 GitLab 测试|线上分支的时候，须要进行的操做。

1. 正常提交：至少一我的承认
2. 重要提交：负责人承认
3. 多项改动：不一样组进行各自代码审核

在 jsliang 平常工做中，若是是多语言等无关功能的提交，只须要身边小伙伴的审核；若是是新增功能，则须要组长审核；若是涉及到其余部门，那么须要各自提交到组长审核。

5.5 项目开发：项目延期

影响到项目延期的因素：

• 产品加了特性，需求变动
• 人员减小，开发时间增多
• 项目组成员被调去紧急增援

项目开发过程注意事项；

• 先提问：何时感受到项目可能会延期，在此以后你作了什么
• 创建必定的流程。计划制定流程和计划跟进流程，每周或者天天同步会议
• 明确优先级。分好轻重缓急，将重要的事情先开展起来
• 制定项目共享状态表。让团队成员一眼就能够看清项目进展，并保持图表更新
• 不要漏掉任何一我的。不能由于某成员暂时没有任务，就先搁置，而是事先通知他并让他参与到任务事实跟进中
• 提供有效的反馈渠道。任何人有问题或者质疑，均可以提出并解决他的担忧

5.6 项目开发：项目 Bug

当项目出现线上 Bug 的时候，如何处理？

1. 用户第一，解决问题。对外的事情永远放在首位，作修复和补救，下降损失。
2. 避免重犯，追究责任。错了就是错了，该承担的责任仍是须要承担的。
3. 环境监察，流程优化。人不必定都能具有到位的，因此须要自动化测试或者多种测试，创建预警机制，防止高危操做（灾备演练）

同时，对于线上问题的公关：

• 补偿：包括但不限于发优惠券、送套餐和营销召回等

六 团队管理

6.1 团队管理：团队成员

如何帮助团队成员：

1. 融合协做。经过指导、反馈、监督、交流、协调资源等方式帮助下属提高能力
2. 布置任务。分解和布置任务，包括界定需求边界、制定计划、选拔人员和工做受权等
3. 创建合做。与上级、下属和相关部门创建良好的合做

好的上级应该给予下属机会、空间和支持。

下面不可取的有：

1. 固定的眼光看一我的，成员的提高看不到，也不去挖掘
2. 太重看天赋而非努力
3. 关注错误而非让你在错误中成长
4. 认为团队比每一个人成长更重要

可取的是：

1. 一次失败能够容忍，可是屡次失败应该警戒
2. 问题很棘手，可是容许你尝试
3. 任务要求对系统比较了解，可是让你作也能提高你的了解

值得帮助成员提高的地方：

1. 技术如何提高到更高层次
2. 潜力在哪，优势在哪，如何培养和挖掘
3. 如何让他改进和同事的关系
4. 错误哪些，缺点在哪，如何修正和改进
5. 创建不擅长领域的信心
6. 处理各类压力和矛盾

自身反馈：

1. 和本身对话，反思上面可取和不可取的点
2. 将一些场景的心里 OS 写出来，方便回顾
3. 跟组员和上级沟通，交流和听取建议
4. 哪些事情能够交给组员的，可是本身却承担下来了

6.2 团队管理：晋升

关于团队成员的晋升，能够考虑到如下几点：

• 技术提高标准：这我的是否在过去的半年或者一年里，按照下一个级别的标准在工做（我须要的提高点在哪，我本身的思考、组长的评论、好友的建议）
• Code Review：是否对本身的需求开发、任务完成有对应的记录，并将这些内容统计分析出来

6.3 团队管理：建议和意见

同事展现或者汇报工做成果，说完会表示 “有意见尽管提”，可是这是一个大坑！

若是你特别老实直接说了一堆负面建议/意见，很大可能会不欢而散。

因此，沟通是门艺术。

• 大多数人对于负面的反馈和意见，心理上或多或少都有些排斥感

提意见的方式：

1. 考虑由你提出这个意见是否合适。是否是换成领导比较好，或者技术问题由技术比较厉害的人提出比较好
2. 提出这个意见的时机是否把握好。别人忙得焦头烂额，或者失恋了等场景，提这个建议/意见和加一把刀有什么区别
3. 提出这个意见的地点是否把控好。是否在人员密集场所提出这个问题，是否在会议场所提出问题
4. 提出的建议或者已经对事不对人。避免让别人感受你这是针对他，而是针对这个事情

多正面反馈，80% 的正面反馈 + 20% 的改进建议，会让一我的有更好的动力。

听取意见的方式：

1. 了解本身心里，是否在认真听取意见。看重提意见的人？意见我的化？心情因素？对方态度因素？
2. 克服自身障碍，避免情绪影响到听取。不要试图从恶的角度揣测对方，先假设是善意的，并标明本身的感谢
3. 了解建议细节，将关注点放到改进处。
4. 过滤建议信息，将改进处落实到具体。

6.4 团队管理：一对一沟通

创建一对一的沟通机制，能让团队更加和谐：

1. 每一周或者每两周和团队成员进行一对一沟通
2. 谈话的内容没有定式，一般如下级为核心，对项目进展、工做中的挑战、技术、业务和人事关系等进行详细探索和沟通
3. 经过信息分享，会提高团队成员的工做品质，你也能够学习了解到更多的知识
4. 不要为了沟通而沟通，这样会毫无心义
5. 能够先为沟通设定一下话题：产品提高、工做哪些方面能够改进、技术方面如何提高

6.5 团队管理：指望与被指望

管理者和被管理者之间，最须要避免的状况之一，就是指望值。

• 团队成员 A 平时很努力，但愿能拿到优秀的绩效，结果拿到合格
• 团队成员 B 完成了一个很重要的项目，以为能够升职加薪，却落到其余成员头上
• 管理者 C 以为本身和团队成员合做很愉快，结果成员但愿换组甚至跳槽
• ……

这些状况都会给以为意外的一方带来委屈。

校准管理者和被管理者对彼此的指望值：

• 增长彼此的了解。内向外向、自信自负、跟本身较劲仍是和他人攀比
• 半年或者一年进行一次关于指望值的深度对话。兴趣是什么；加入团队但愿作什么；将来两三年职场计划怎样；作了哪些努力而且正在努力哪方面；目前作哪些工做，还想作哪些工做，还能作哪些工做；想承担什么样的责任；你对他的指望置，并表示本身会尽大可能提供机会和支持；明确表示若是对方之前的承诺目标没有达到，那就暂时不回给予更有挑战的机会
• 持续跟进。设置一些检查点，一周或者两周进行一次检查，根据双方的判断进行调整

6.6 团队管理：职场规划

对于团队成员，须要注意成员的我的规划：

1. 我的价值观是什么，最在乎什么？在乎独立解决能力，在乎挑战别人作不到的事情，在乎同事间的沟通氛围良好关系
2. 长期意愿是什么，五年甚至十年后，你但愿成为何样的人？
3. 为了达到目标，你还须要哪些技能或者经验？技术广度、深度，产品系统了解
4. 优点和长处是什么？合做性、独立思考、行动迅捷、良好的产品思惟

成员但愿领导提供怎样的支持：

1. 须要能证实本身的项目
2. 须要能带本身的老员工
3. 但愿有更多练手的机会
4. 须要专一培养本身的技能
5. 须要让本身接触更多的业务或者架构
6. 须要参加系统的培训

固然，在提供这些支持以前，须要先证实本身。

例如但愿参与能证实本身的项目，那么在这以前你有没有参与各个项目的开发，脏活累活有没参与，从而才能得到须要的机会。

例如但愿能带本身的老员工，那么你是否作同等反馈，例如帮忙作一些力所能及的杂活，让老员工能更轻松地帮助你。

不该该脱离实际去请求支持。

完成职场规划须要：

1. 知道本身想要什么，知道现实的你和理想中的你差距在哪里
2. 和领导者沟通，获得一些反馈和帮助
3. 设定目标，指定你和你的领导者都赞成的计划和期限，确保计划会让你和目标更接近
4. 让计划变得可执行和可追踪，循序渐进完成和跟进，持续改进

七 其余

7.1 其余：说 “不” 的技巧

若是什么事情你都说 yes，你多是万能的，可是你总会有栽跟头的一天。

1. 分清事情的轻重缓急，有些紧急的事情和优先级高的事情很难拒绝
2. 正确评估本身的能力和时间资源

7.2 其余：后续日子的思考

1. 下一步路怎么走？

   1. 本身陌生领域开辟新天地
   2. 擅长领域继续精进
   3. 转岗

2. 思想是一种沉淀，时过境迁之后你可能再也写不出来了

   1. 忙到后续再补笔记不是借口
   2. 不会作笔记也不是借口

八 总结

也许有的小伙伴看完会以为一脸懵逼，这写的都是什么和什么。

可是在读原文和此时回顾以前写的读书笔记（2021-04-13），我仍是以为有些点是很是值得关注的，例如：团队成员的晋升。

虽然咱们不少人都但愿本身能晋升到下一个职级，可是有时候想一想本身是否知足下一个职级的技术栈，并按照这个技术栈严格要求本身了？

固然有时候会以为本身是否是被洗脑了，可是若是晋升不是按照一套流程走的，那么开了口子后团队管理是否是乱了。

除此以外，里面还有内容值得拉出来深思，这里不一一例举。

我是 jsliang，咱们下本书读书笔记见。

---

不折腾的前端，和咸鱼有什么区别！

jsliang 的文档库由 梁峻荣 采用 知识共享 署名-非商业性使用-相同方式共享 4.0 国际 许可协议 进行许可。<br/>基于 https://github.com/LiangJunrong/document-library 上的做品创做。<br/>本许可协议受权以外的使用权限能够从 https://creativecommons.org/licenses/by-nc-sa/2.5/cn/ 处得到。