跃迁：从技术到管理的硅谷路径【笔记】

技术管理

1.技术管理包含两层含义：

* 一层是管理自己和团队的技术，进行技术选型，在正确的场景使用最适合的技术，保证程序简捷、强壮、可维护，最终完成产品的上线

* 另一层是管理技术团队，帮助团队成员成长，把事情做成

2.“你不能每次都给答案，你应该试着用引导的方式让对方学会自己找答案”

3.从给答案到做引导：

* 1）什么时候适合直接给答案，什么时候适合给线索让对方自己找答案

* 新人进入全新领域，或者所问问题的答案就是某些知识点时，直接给出答案或知识点

* 对方已经有一定的积累和经验后，可以让他自己去探求解决方案了，需要给出一些提示

* 2）如何引导

* 问对方正确的问题，通过问题去引导对方进行深入思考，找到解决方案

* 3）引导的好处是什么

* 解决类似问题的能力会提升

4.技术经理必须停止只思考自己的状态，把更多精力放到其他人和团队上面

5.一名优秀技术管理者应该做哪些工作呢？

* 帮助团队成员迅速成长

* 明确地分解与布置任务

* 建立有效的合作关系

6.大公司如何帮助成员成长：

* 对每个级别在各个方面设定一些标准

* 一个人是不是可以被提升，标准就是，是不是已经在过去的半年到一年里，按照下一个级别的标准在工作。换句话说，不是觉得你可以达到下一个级别的标准就提升你，而是你已经达到下一个级别的标准，并在这个标准上稳定地保持了一段时间，你才会被提升

7.做到下面4点，有很大机率成为一个优秀的管理者：

* 和自己对话，想想自己哪些时候、在哪些方面会用静态的眼光去看待别人的能力

* 把自己有这种心态的时的表现或内心的想法写出来

* 再遇到类似的情况，停下来，想一想自己是不是可以有所改变

* 诚恳地告诉组员希望帮助他成长，多交流并听取对方的想法

8.一名技术管理者的成功并不在于自己写的代码多好、能力多强，其成功一定建立在团队成功的基础之上

9.尽最大可能避免延期问题的发生：

* 建立一定的流程

* 在整个项目计划中，要有明确的优先级。知道哪些任务是非做不可的，哪些任务是需要提前完成的

* 制作一个共享的项目状态表，让团队成员可以一眼就看清楚项目进展，并保持该图表的更新

* 不要漏掉任何一个人。不要觉得暂时还没有他的活，可以先不用与他沟通

* 提供一个有效的反馈渠道

10.期望值差异很多时候都是一种很自然的存在。原因也很简单，因为每个人都或多或少高估自己

11.90%以上的创业公司都会失败，但这些创业都在初期无一不认为：“我有优秀的团队、广大的市场、敏锐的产品意识和绝妙的创意，怎么可能不成功呢？”

12.尽可能地校准管理者和被管理者对彼此的期望值：

* 最重要的一点是增加对彼此的了解

* 每半年或一年进行一次关于期望值的深度对话

* 有了这样的约定，还需要持续跟进

13.一般情况下，管理者会倾向于把重要、困难的工作交给自己信任的人。这种信任，包含了对对方的了解程度，对其工作态度和能力水平的肯定

14.在没有建立起充分信任的情况下，我们该如何分配工作：

* 1）建立参考基线

* 2）问对问题比给出正确答案更重要：告诉他任务的详细情形，看他会问出什么样的问题，提出哪些想法

* 3）工期估算

* 让接受任务的员工试着去估算：需要多久完成，大概什么时候完成，需要什么样的资源等

* 开发工作量有多大，会不会依赖其他人的工作，有多少沟通成本，技术难点是什么，有没有现成的方案，系统框架是什么，后期集成和测试的时间成本有多少

* 如果一个人不能花费足够的时间去了解自己未知的部分，我们也很难放心地把任务交给他独立完成

* 4）执行力

* 5）后期维护：需要观察，一个人是不是可以自觉地维护产品，有没有责任感，会不会推卸责任，出了问题能不能第一时间冲到一线解决

* 6）注意一些细节问题：

* 学会如何对待职场新人：不要轻易地否定他们。他们可以快速地学习并且进步

* 了解如何针对不同类型的员工分配工作：分配任务的时候，你需要扬长避短，根据每个人的特点安排不同类型的任务，并提供相应的支持和帮助，以发挥人员的最大效力

* 还要注意大项目的工作分配：如果你希望承担更重要的任务，成为有担当的人，一方面需要提高自身的能力，发挥自己的特长，另一方面就是要成为一个有态度的人

15.一个技术方案如果自己不参与就会担心执行效果，两个误区：

* 事情能不能做好和完全按照你自己的方式做好，是两码事

* 介入和不介入并不是非黑即白的，用什么方式介入，在哪些地方介入才是关键

16.在授权和分配任务的时候应该注意以下方面：

* 1）让对方明确目标，知道最终要得到的结果是什么，对这个任务完成的期望值是什么样的

* 如果有取舍，哪些是重要的，哪些是次要的，哪些是可以妥协的

* 2）制订一个计划，并保持跟进

* 跟进不是指导，而是需要你在对方对某个环节有疑问的时候，能够随时提供帮助

* 3）给出反馈，尤其是下面的反馈

17.管理者不用亲力亲为，关键就在于学会授权和任务分配，两个重点：

* 第一，我们要有效地把任务分配出去

* 第二，我们要保证分配出去的任务能够被圆满地完成

18.项目管理中三个技巧：

* 1）我们在制订项目计划的时候，要对多个项目进行细分重组

* a）需要考虑的因素：

* 先评估能力，再分配任务

* 每个人完成任务所需的时间要尽量平等

* 有挑战性的工作和“脏活累活”的比例要大致相等

* 任务要有足够的挑战

* 不同人的任务之间如果有依赖性，在分配任务时要安排合理的顺序，确保不会有人被其他人或事阻塞（Block）

* 每个人的任务都应该有一个主题，就好像故事有一条主线

* b）细分重组两个阶段：

* 第一个阶段，需要把所有要做的事细分为一个个的小任务，每个任务的大小，完成需要的时间都大致相同

* 第二个阶段，把这些大小均匀的任务块，按照上面提到的因素，分装到几个虚构的“箱子”里，然后分配给团队成员

* 2）工期估算

* 很多工程师在做时间预算的时候，会过于乐观

* 往往需要技术领导者给出参考性的意见和建议，最好留出一些缓冲时间

* 3）实时跟踪，并准备好B计划

* 设立各种里程碑，有一些长期的大里程碑，也有一些为期一周到两周的小里程碑

* 一旦出现延迟，管理者要和任务的负责人一起分析原因，询问对方能否追上进度，会不会对整个项目的进程有重大影响

19.管理者需要把握几个方面的度：

* 1）因人而异

* 最大程度调动并发挥每个人的长处，并且帮助他在欠缺的方面获得更快的成长

* 2）因事而异

* 在介入之前 ，你需要让对方理解为什么需要频繁沟通

* 如果单个任务是在整个项目中有一定试错空间，或者不在时间线的关键路径上，这时，你不妨试着放手让组员尝试独立完成

* 3）跟进的粒度

* a）两种极端的做法：

* 只设计目标，然后完全放手

* 每个细节都按照你的想法去推进，这就无法让员工发挥自己的能力

* b）应该做到以下几点：

* 确立目标，确保传达：非常清楚地说明你想要的最终结果是什么样子，并明确地告诉员工

* 多给指导，少亲手做

* 设定频率，保持跟进：定期跟进，尽可能给对方足够的决定权

* 交流难点，给出建议：可以给出一些建设性的建议和意见，但不要直接上手帮忙完成任务

* 4）交流的重要性

20.为什么要保持员工组成的多样化：

* 互联网时代的市场组成是多样化的

* 产品的用户也是多种多样的

21.如何才能保持员工的多样化：

* 多样化可以体现在员工的国籍、人种和性别这样的外部特性上

* 员工的多样化也可以体现在团队的内部差异上

* 员工的多样化也体现在团队的创新思维上

22.《包容性领导的六个特征》：

* 坚定的承诺

* 谦卑的勇气

* 正确的认知

* 开放的心态

* 高情商

* 合作的意愿

23.责任心是一种抽象的概念，很难去培养，即使可以培养，也是个漫长的过程

24.如何去激发团队人员的责任心：

* 1）我们要明确责任制，适当地放权，让他们去主导一些事情，适当的奖励机制

* 2）要让责任制变得有效而不是形同虚设

* 让责任人意识到承诺了就要努力做到，承诺的事没做到是需要承担后果的，不是没人在意

* 有效的责任制，需要在开始的时候就让所有人明确责任与权利，而不是事后追究责任

* 多花时间，让对方自己认识到问题所在，而不要把你的主观感觉强加于人，用引导的方式才能更好地激发团队成员的责任心

* 3）尽可能让团队成员充满归属感

* 在有利公司发展的基础上建立独特的企业文化

* 管理者还应该以身作则，让员工看到自己的努力，对公司目标的追求，对企业文化的践行

25.看别人的设计文档，或是自己凭空想象，都没有应对实际系统中的问题更能让自己长经验

26.绩效评估都解决了哪些问题：

* 绩效评估的出发点，就是建立一个奖罚机制

* 保证公平

* 这样一个明文列出规则的系统又可以在一定程度上让所有人的期望值趋于一致

27.绩效评估可能存在的问题：

* 每次绩效评估后，必定是换组甚至离职的高峰期

* 必定每个人都可能会有一些偏见，每个人主观判断的标准也可能有偏差，甚至难免会由于个人情绪和私心影响结果

* 公司把哪些内容列入评估，其实就是引导员工更多地在这些方面花时间精力

* 当一些项目或者工作的周期长于评估周期时，评估机制就很难准确反映每个人就得的奖惩

28.对于工程师来说，尤其是职场生涯偏早期的工程师，能够加入一家快速增长的公司其实是最好的选择和机会

29.Jeff Bezos提出过一个Pizza原则：“如果两张Pizza不能喂饱一整个组，那就说明这个组已经太大了”，而一个组太大，在决策和所有权方面就很容易生产比较大的资源或时间开销

30.每个小组都有自己很明确的职责范围，这是所有跨组协作的基础

31.跨组项目时间线，如何保证项目按期完成：

* 在项目期限规划上，组里的资深工程师还是很有话语权的

* 每次的讨论和会议，尽量保证小而精，切实解决一个问题

* 后期执行中，如果产品有需求上的改动，会影响之前的计划，那么或者适量延期，或者把部分需求置后，或者增加有效工程师资源

* 跨组项目的时间线很大程度上取决于每个小组是否能够按期完成各自的任务定额，因此合理设定每个小组的时间线，对保证跨组项目的期限和里程碑有着很重要的作用

32.“高层”技术领导者很重要，但是“一线”技术领导者更直接影响工程师的生产力

33.一线技术管理者，指的是可以带5-20人甚至更多的人的技术团队，直接管理工程师，或者每天都需要和工程师交流和沟通的那些技术领导者

34.一线技术管理者两个十分关键的能力：

* 利用自己能了解到的有限情况做出最正确的决定

* 利用组里有限的工程师资源高质量完成最关键的项目

35.一个优秀的领导者，在并不亲自写代码的情况下，应该了解到所有方案的优缺点，考虑到所有技术和非技术因素，迅速在给定限制条件下做出最正确的决定。这是很重要的技能

36.如何利用组里有限的工程师资源，高质量完成最关键的项目：

* 1）挖坑，也就是定义项目，决定要做什么，具备长期的战略眼光

* 2）充分调动每个工程师的潜力，给他们成长的机会和空间，在任何一个团队中，如果每个工程师的效力都得到最大化，这个团队的执行力便能超出每个个体简单相加的总和

* 3）帮组员摸清路障，最关键的贡献，应该是全局掌控，提前清楚项目可能遇到的障碍

技术实践

1.A/B测试是一种数据分析手段，它可以对产品特性、设计、市场、营销等方面进行受控实验

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

* 永远不要过分相信你的直觉

* 实验样本的数量和分配很重要：分配算法不会对两个组的数据产生额外的干扰

* 分析的维度要尽可能全面

* 其他组的改动对A/B测试产生的影响

* 比较值的趋势必须收敛的，而不是发散的

* 数据埋点：前端埋点一般可以采集实时数据，后端埋点可以采集实时事件，也可能是一些聚合数据

* 形成一个流程，或者设计一个工具

* 试图给每个结果一个合理的解释

* 必要的时候重新设计实验

* 不同客户端分开进行实验

3.幂等：一个操作如果多次任意执行所产生的影响，均与一次执行的影响相同，我们就称为幂等

4.幂等两个关键因素：幂等令牌（Idempotency Key）和确保唯一性（Uniqueness Guarantee）

5.幂等系统的常见问题：

* 幂等令牌什么时候产生，怎样产生

* 令牌有没有被误删的可能

* 各种竞争条件

* 对请求重试的处理，大部分是服务器端要做的工作

* 系统中需要多层幂等

6.学习算法的用处：

* 1）算法是面试的敲门砖

* 2）编程时用到更多的是算法思想，而不是写具体的算法

* 如果工作中需要读的一段代码中包含一些基本算法思想，你会比不懂算法的人更快理解代码含义

* 3）不精通算法的工程师永远不是好工程师

7.在建表时需要考虑所有可能的高频查询，切忌过度地“为未来设计”，不要增加许多可能根本不常用的索引，这样反而会增加写数据时的成本和负担

8.NULL在数据库里常常被解释为“不确定”而不是空

9.过度使用事务的问题：

* 事务中封装的代码逻辑太长太复杂，甚至调用了别的函数

* 事务中封装了与数据库改动无关的逻辑

* 事务中有不可逆的操作，例如发送电子邮件给用户、发布到一个Job队列等

* 事务中包含了不同数据库中的事务，也就是分布式事务，这种情况需要单独处理

* 事务中嵌套了事务，不同情况下可能会有不同的结果，如果没搞清楚，就可能出现意外

10.业务拆分时的注意事项：

* 测试会变得异常复杂

* 与接口相关的改动需要大量协调

* 报错的处理

* 日志的完整性

* 超时设置

* 代码自由

11.业务拆分综合考虑：

* 1）你的业务是否足够大，逻辑是否足够复杂，以至于必须进行系统拆分？水平扩展是不是已经不起作用了？代码的相互影响、部署时间过长真的是系统的切肤之痛吗？如果答案都是肯定的，那么你就应该进行系统拆分了

* 2）对于服务化的架构，你的开发人员有多少经验，能否正确驾驭

* 3）系统拆分是一个“从一到多容易，从多到一困难”的过程，这个过程几乎是不可逆的。所以在做拆分的时候一定要慎之又慎

12.一家公司早期的代码会因为各种历史原因而不是那么完美，但是在特定的时间点，那就是当时最优的方案

13.在设计API的时候，就应该做到用最简单直观的格式支持所有的需求

14.API设计原则：

* 保证API RESTful和程度是100%

* 在请求和响应中，应该尽可能地保持参数的结构化

* 有关鉴权和安全的考虑，始终应该放在首位

* API本身应该是与客户端无关的

* 尽可能让API是幂等的

15.API设计中的平衡：

* 1）自由总是相对的

* 2）为当前设计，还是为未来设计

* 要考虑未来的场景，在设计时留有余地，但永远只实现当前产品真正要用的功能

* 3）可维护性和效率

* 4）是否采用面向切面编程

* AOP的理念是从主关注点中分享出横切关注点

* 分享关注点使解决特定领域问题的代码从业务逻辑中独立出来，业务逻辑的代码中不再含有对特定领域问题代码的调用，业务逻辑同特定领域问题的关系通过侧面来封装、维护，这样原本分散在整个应用程序中的变动就可以很好地管理起来

16.支付系统在处理各种交易时，不仅仅是处理交易，也需要对其他功能的支持，其中包括了确定规范和程序、处理异常，还有收费的标准、一笔交易应该保证多久完成等

17.每位工程师都应该在他已有的水平上尽全力追求完美。我们应该具有工匠精神——为我们的工作而骄傲，不断打磨工具、流程和技术，打造出具有最高品质的作品

18.说得理想主义一点，软件质量最基本的保证应该来自于程序员的素养

19.很多写代码的技巧、风格或习惯都得益于以前工作中在代码审核环节同事给出的建议。这比看书或者读别人的代码学习来的要有效得多

20.参与审核的人要多存质疑的态度，不明白的或者觉得有问题的地方都直接说出来，这样对双方都有益

21.Monitoring和Alerting

* Syslog或Kibana Log

* 基于BD Trigger的Auditing Trail

22.一个项目的推进，通常有4种情况：

* 1）负责的程序员 vs 紧张的进度

* 2）不负责的程序员 vs 紧张的进度

* 3）负责的程序员 vs 不紧张的进度

* 4）不负责的程序员 vs 不紧张的进度

* 第一种和第三种都是比较理想的结果

* 如果上层的态度不明确，那么做不到第三种，就不妨做第四种。而最吃力不讨好的，就是第一种

* 如果根本没有人在乎代码质量，只在乎进度，那么就做到第二种

硅谷文化

1.硅谷互联网公司的开发流程

* 1）OKR的设立

* a）硅谷公司的OKR（Objectives and Key Results，目标和关键成果）一般都是自顶向下的，也就是说，先有整个公司的OKR，然后有每个部门的OKR，继而是大组的OKR，再到小组的OKR，确保整个公司有一致的目标

* b）技术驱动反映在哪些方面？

* 确定演进线路图的过程中，我们会采用调查模式，确保工程师的声音可以准确地触达管理层

* 项目怎么做，怎么规划，一般是由工程师来决定的

* 估算OKR里的目标工期时，我们会除去一些用于技术创新和技术支持的时间

* 2）主项目及其子项目的确立

* a）主项目是主要的技术或商业产品，一般由产品经理、技术经理和一些技术骨干经过对产品需求的讨论之后，确定要做什么（Scope），不做什么（Non Scope）以及大的里程碑（Milestone）

* b）一般团队协作有两种方式：一种是每个人负责一个子项目，从始至终；另一种是大家先一起完成基本框架，然后逐个需求、逐个模块去推进，最终一起完成整个项目

* 3）确立每个子项目的生命周期

* a）开发初期的设计文档

* 组内工程师和产品经理审核，然后进入大组评审（包括Legal、Compliance、Finance等），涉及公司的整体架构，还需要发给全公司审核

* 文档中不仅包括怎么实现，还有选型的理由、考虑的因素、支持和不支持的属性、时间线等

* b）设计测试实验，这是可选的，也就是A/B测试

* c）设计文档锁定，就可以开始实施了。每次代码提交要写清除代码改动外的摘要和测试，并通知不同的工程师审核

* d）所有的实现都要加入监控、日志、预警代码

* e）所有的实现都隐藏在一个开头（Trebuchet）后，当代码就位后，就开始进行灰度发布

* 推送的过程中会结合A/B测试，只有测试结果显示对用户体验、公司主要指标没有明显的负面影响，才会正式发布给所有用户使用

* f）对一些需要重构的关键产品链路，有时候也会使用双重写入的方法，就是将新特性和旧特性都写入数据库，并通过不同方式比较两个实现的结果

* g）最后是一些扫尾工作，移除用来做A/B测试和灰度发布的代码开头等，有时候还包括一些次要需求的实现

* 4）确立主项目的生命周期

* a）项目开始都有一个整体设计文档

* b）在所有子项目进行的过程中，共同需要的架构或者服务，可以将其单独提取为公共服务或库

* c）给相关人员做进度报告，包括主项目的里程碑

* d）由于众多子项目的完成时间可能不一样，因此需要进行人员的重新配置

* e）在开发过程中不断更新文档

* f）因为不确定的需求变动，有时会取消或者生成新的子项目

* g）有时候也会因为公司的方向变化或战略调整，对主项目进行比较大的变更，同时对应调整相关的子项目

* h）在项目开始和结束的时候，需要做好对外的交流和沟通

* 5）收尾、维护、复盘

* a）进行代码清理和文档更新，有时还需要写新的用户手册或Wiki等

* b）一些基本的错误和异常处理要写到运维手册里，便于以后负责运维的人知道如何处理一些已知的问题

* c）每个项目结束时都会进行复盘，总结整个项目的经验和教训

2.Code Review要清楚的两个概念：

* Commit：Github上的一次“Commit”行为，这是可以单独保存的源代码的最小改动单位

* PR：也就是Pull Request，是指一次代码提交请求。一次PR可以包含一次Commit，也可以是多次

3.一般情况下，所有的PR都必须有至少一个人认可（stamp），才能进行合并（merge）。如果改动的内容涉及多个项目，则需要每个项目都有相关人员认可才能合并

4.帮助他人成长，而不是帮他写代码：

* 从对方的角度来说，代码写不好，可能是对业务不熟悉，对编程语言不熟悉，也可以是对公司代码的整体架构不熟悉

* 帮别人写代码的方式可扩展性很差。你不能什么都自己写，尤其是开始带项目、带新人时。每天审核五个人的代码和帮五个人写代码，长期而言哪个更划算呢？答案显然是前者

* 写代码是一个学习过程，怎么成为一个好的代码审核人更是一个学习和成长的过程

5.一般将提交的代码分成4类：

* Bug修复。独立的Bug追踪和管理系统，每个Bug都有一个票据（ticket），代码提交的PR一般和票据是关联的

* 代码优化。文件的移动和拆分，部分函数的重构等

* 系统迁移。包括代码库拆分，用另一种语言重写等

* 实现新系统和新功能。新功能在实现之前都需要进行设计审核，最终版本的设计文档会包括数据库的Schema、API的签名、代码的流程和模块等内容，相关代码的提交，也就是PR，一般是和设计文档相关的

6.Code Review的注意事项：

* 为什么要进行PR？原因一定要在提交的时候写得非常清楚，才能帮助审核者判断这个改动是不是合理

* 除非是极其明显的单词拼写问题，否则尽量不要引入不是这个PR目前的改动。PR要尽可能保持目标的单一性

* 一定要确保所有的改动都是测试过的，无一例外

7.Code Review从代码审核者的角度要注意：

* 如果时间足够，自然是看得越细越好。如果特别忙的时候，则可以做一些筛选

* 如果是新人写的代码，尽可能地在代码风格、性能等各方面都加以审查。如果是老员工，这些方面则可以给予更多信任

8.Code Review具体哪些地方需要审核：

* 代码格式方面

* 代码可读性方面

* 业务边界和逻辑死角问题

* 错误处理

* 确保测试用例覆盖到了所有的功能路径。严格来说，每段代码都应该有测试用例

* 代码质量和规范

* 代码架构

9.公司层面对Code Review的支持：

* 统一代码提交和审核的流程与工具，并确保大家使用同样的工具，遵循相同的流程

* 鼓励员工帮助别人审核代码，甚至可以列入绩效评估中

* 制定统一的编程规范和代码风格，尤其是在有争议的地方，这样可以解决由于程序员的偏好而带来的矛盾

10.对于Bug导致的错误，应该采取什么态度和措施：

* 追究责任，但不是惩罚

* 对事不对人

* 反复问“为什么”，从根本上发现问题

* 员工关系的建立也很关键

11.硅谷的沟通

* 1）每两周会有一次到两次的一对一面谈，经理人会和每位团队成员进行一次大约二三十分钟的跟进谈话，这个行为差不多成了硅谷所有公司的传统

* 2）谈话的内容其实没有定式，一般会谈到最近的项目进展如何，有没有什么阻力，最近的生活和家庭状况如何，有没有出游或其他特别的计划等

* 3）如果想让一对一沟通真的有益、有效，管理者应该学会聆听

* 4）好的沟通：

* 找一个适合谈话的场所

* 彼此百分百专注

* 要有一定程度的眼神交流

* 不会收到批判性的反馈，哪怕是表情或者肢体语言的暗示

* 有一定程度上的交流

* 所有的对话，如果自己有保密要求，可以保证对话内容不会被传播出去

12.关于On Call

* 1）监控和报警

* a）监控：

* 将系统和使用的监控工具集成

* 在代码中加入各种instrumentation向监控发送数据

* 在监控系统中设置阈值，当某项指标出现异常时，通过特定的方式通知预设的组或者工程师

* b）监控工具：PagerDuty、Slack

* c）报警工具：Nagios、Graphite、New Relic

* d）很多公司都不会只用一种监控工具，通常是两到三种并用，因为工具都有出问题的时候

* 2）系统检查

* a）检查到底哪里出了问题

* b）日志系统：Kibana

* 3）系统控制：包括关闭部分系统或者系统的部分功能，重启系统，以及启动某项特定的服务等

13.本地化：是指在移植产品时为其加上与特定区域设置有关的信息和语言习惯、用户习惯等，使得产品在该地区有很强的可用性和粘滞性

14.Coupon（优惠券）设计：

* 无论最开始设计Coupon系统的人，以及后来在上面加新需求的人，是产品经理还是技术领导，他得真的知道或者了解所有Coupon可能出问题的地方，应该怎么统一设计

* 一定要有统一的文档，并保持更新

* 为所有用法编写测试用例，包括上面所有场景的各种组合

个人成长

1.四类错误

* 1）伸展错误（The stretch mistakes）

* 当你尝试去进行能力之外的挑战时，因为自身能力或其他条件的束缚做得不够好而犯的错

* 获得学习的机会成本很高，一旦经历过一次，就可能有长足的进步

* 2）无知错误（The aha-moment mistakes）

* 当你发现自己为什么犯错的时候，你会发出“噢，原来是这样的”的感慨

* 一般是因为你不知道或忘记考虑某些特殊情况而导致的，也可能是因为你做了错误的假设

* 3）粗心错误（The sloppy mistakes）

* 你明明知道怎么回事，但是因为不小心或者忘记了而导致的

* 4）高风险错误（The high-stakes mistakes）

* 主动去做事情 ，但风险很高，是否会犯错不受自己的控制

2.避免错误：

* 为了避免伸展错误，尽可能提供一些培训机会

* 为了避免无知错误，要做好信息的透明共享

* 为了避免粗心错误，要设置一定的复盘机制

* 为了避免高风险错误，为所有的决定尽可能准备一个备用方案

3.要对更多的工作说“不”，需要搞清楚两件事：

* 分清事情的轻重缓急，有些紧急的事情和优先级高的事情很难拒绝

* 正确评估自己的能力和时间资源

4.什么时候可以说“不”：

* 正确评估需求后，如果事情没有那么紧急，或者这件事别人也能完成，并且你手头正好有更重要的事情在做，告诉对方，这个需求现在做不了，需要完成当前任务后才能考虑

* 如果某件事的处理已经远远超出了你的能力，甚至职责范畴，不要只是为了让别人高兴而充当滥好人，揽下来又做不了，或者达不到对方的预期，不仅会耽误别人的事，还会丢失自己的信用分。这时候要学会说“不”

* 如果某件事你可以做，但是因为各种原因，觉得有些难处又不愿意解释，就勉强答应下来，最后的结果可能是事情做了，却做得心不甘情不愿，完成度也不够。这时候也可以考虑说“不”

5.听取意见时有几点很重要：

* 尽量排除情绪以及偏见对我们的干扰，这一点，需要我们有意识地去克服

* 假定对方是善意的

* 了解意见的具体细节 ，把关注点放在对方的出发点，以及对方希望我们改进的地方

* 对意见里的信息进行分类和过滤，思考一下：哪些是误解，哪些是自己的不足，哪些是自己可以通过沟通去改变的，哪些是自己需要尝试改进的

6.关于学习的焦虑感：

* 1）快速甄别，决定哪些事情值得花费时间

* 锻炼自己不要在无用的事情上花费时间

* 2）对于需要学的，考虑自己的时间，衡量时间成本的性价比

* 评估掌握一项技能在短期和长期内对你有多重要

* 时间成本本身的评估

* 信息获取是不是可以利用时间碎片来完成或者处理呢，还是需要用连续的时间去持续学习？

* 3）对需求和时间成本评估，决定要不要学，确定学习目标

* 4）计划学习前要想清楚，一旦开始执行，就不要想太多

7.“一个团队应该有一些稍微激进但又可行的里程碑，而且大里程碑又应该分成小的，尽可能让每两个里程碑之间的间隔时间不要过久。这样，每隔一段时间，大家就会完成一个目标，就会有成就感。最糟糕的就是定一些不切实际的目标，或是不断放弃预定的目标。这样的话，每个人都会开始疲惫和迷惘，很难看清楚自己到底做成了什么”

8.管理自己精力的法则，就是找到对自己来说重要的和困难的那些任务，不仅要为期预留时间，而且要预留自己精力最充沛的时间