不聊代码：这些年我最想安利的五个工作方法
分享一些我真正参与过落地的项目、做过产品才会总结出来的亲身经验。不谈框架不谈语法，都是些没做过项目可能压根不知道的东西。文中没有任何真实公司、项目和人名。
先说一句：这些只是我自己总结的，最好别听个热闹，你自己要多独立思考，思考后去实践，才能变成你自己的。
一、如何给工作预留 buffer（缓冲）
给你说一个场景，我稍微夸张了一点，用来说明什么是 buffer。
假设一个重要客户提了新需求，要求三个月内必须上线。
- 产品经理和项目经理设计了一个新 feature（功能），告诉技术负责人：两个月内必须上 stage（内部预发布环境），两个半月必须上 prod（生产环境）；
- 负责人经过深思熟虑，告诉团队：我们有个新功能，一个半月必须做完；
- 团队经过 grooming（讨论分析），决定一个月完成所有任务。
本来三个月的工作，因为各个环节都留了 buffer，被压缩到了一个月。做过项目的人都知道，唯一不变的就是变化，意外和明天不知道哪个先来。这样最大限度地屏蔽了风险，给变更和意外留下了时间——可能这也是 996 的一部分原因吧。只有不满足的客户，没有累死的程序员。
再说另一个场景，一个很小的变更，可能只需要改几行代码，几分钟的事。
一个有经验的程序员一定会留 buffer：
- 汇报的时候基本说 1~2 天；
- 技术负责人向上汇报，说变更至少需要 3~4 天；
- 产品经理会跟客户说，这个功能我们会开发至少一周。
一个几分钟的事，因为各个环节都留了 buffer，就变成了至少一周。
即使你只改了一行代码，你要考虑的东西也是很多的。我说几个比较有代表性的：
- 修改的影响范围，是否有自动化测试覆盖；
- 新旧版本的兼容性，比如 App 的用户不一定会升级版本；
- 对其他团队、微服务的影响，是否依赖各自的上线时间；
- 版本回退或者 feature 回滚是否有影响；
- 是否要追加单元测试覆盖你所有的 case，是否要追加自动化测试脚本。
所以，大胆地给自己的工作留好 buffer。评估好工作量之后，推荐增加 20% 左右的时间作为 buffer。只要你的理由是充分的、做的事情是对项目有利的，那就是合理的！时间是自己争取的。
有人说我不会留 buffer，预估的也不准。我想说的是，你不试着预估，你永远也不会。这次留得不准，多来几次，经验积累起来你就会了。如果进度就是特别紧，那就主动、及时地报联商（报告、联络、商谈），放心，是有 buffer 的。
一个不留 buffer 的管理者不是好的管理者，一个不留 buffer 的程序员也不是一个优秀的程序员。作为程序员，尽人事听天命就可以了。用 100 次深思熟虑去避免一次线上事故，都是值得的。
再送你一个程序员留 buffer 的经典例子：其实程序员是从 0 开始数数的，留下的那个 0，才是最要紧的那个。
插一句：很多人不喜欢中文里夹英文单词的说话方式。我英语、尤其是口语其实也不好，真不是在装。就是做项目时间长了，这些英语就是日常在说的行业标准词汇，突然说成中文有时候反而觉得别扭。我尽量都加上中文的含义。当然不是那种"today 我 eat 了 breakfast"的招人烦版本哈。
二、要认真且主动地做 checklist
checklist 就是一个工具，是在各阶段落地质量管理的一个非常简单实用的方法，有点像一份清单，一般以"是否"开头。
大部分 checklist 都是团队整理的，比如上传代码的 checklist、code review（代码检查）的 checklist：
- 是否考虑了代码的影响范围？
- 是否追加了相应的单元测试？
- 是否正确 merge（合并）了 master（主分支代码），且编译没有 error（错误）？
- ……
当你要上传代码的时候，checklist 每一条都满足了，才能真正地提 PR。
我想告诉你的是：首先，如果团队有 checklist，你一定要每一条都认真执行。切记！！！务必要认真对待，不要觉得是负担、是走形式。checklist 不是约束你，而是帮助你、服务你的。人都会粗心大意，都有不在状态的时候。你认真做了之后，会发现它真的对你有帮助，对团队也有好处。
另外，你也可以主动做自己的 checklist。首先，不做项目你可能都不知道这个工具；主动维护它，等于变相增加项目经验，也能体现责任感和工作能力。生活中你也可以有自己的 checklist。
三、定期主动进行横向展开
横向展开，就是项目管理者对项目中经常出问题的地方进行整理分析，罗列出一份问题列表，然后让团队各自进行检查和修改。
它有点像 checklist，但时机不同：
- checklist 是行动之前要检查，避免发生问题；
- 横向展开是问题出现之后——一个典型问题，其他成员可能也会出现，于是让成员检查自己是否也有类似的问题并改正。
还是要主动做。而且不仅是问题，优点也可以横展：避免犯别人犯过的错，同时把别人的优点学过来。犯错不可怕，不及时找到类似的问题才可怕。
顺手教你一句：复盘或汇报的时候可以说——"针对这个问题我们进行了横向展开调查，还发现存在两处类似的问题，我们也一并修改完成了。"感受一下那股迎面扑来的责任感和使命感。
四、根本问题分析法 RCA（Root Cause Analysis）
RCA 就是透过调查和分析，看问题哪里出错、为什么出错，寻求防止事故再次发生的必要措施，从而提高产品的安全和品质。它做三件事：
- 分析并找出问题 / 事件的根本原因；
- 了解如何修正、补偿或者吸取经验；
- 预防未来同类问题的发生。
我们基本上如果生产上出事故，或者生产频繁告警，是一定要开 RCA 会议的。这种会议一般时间会很长，每个组员都要发言参与讨论，直到找到出问题的根本原因才会结束。产品、前端、后端、测试，看到的问题和原因也许都不同，因为有不一样的视角。大家综合到一起，就能更容易看到事情的全貌，也能更好地制定 plan（计划），指向未来的 action（行动）。
RCA 最大的作用，其实是引起足够的重视——团队里任何一个人都不希望因为自己的失误去开 RCA。
总结一下：做项目不怕犯错，就怕一直犯类似的错误。这点一定要注意。你要说"我不犯类似的错误，专犯不同的错误"，那就更可怕了。
五、输入、处理、输出
我认为这是最重要的一点！！！！！虽然只有六个字，但可以适用于任何场景。我的经验是，无论什么事情都逃不过这六个字、三个步骤。
很多新人往往就是上来就干。但你应该先明确输出和输入，再进行对应的处理。
我举个例子：领导让你把屋子收拾干净，你什么也不问，上来就风风火火地干活了。热情、干劲都是好的，但可能不是最优解。
一个有经验的人，不是马上"处理"，而是要先确定输出！！！
你需要我把屋子收拾成什么样？大面上说得过去就行，还是要一尘不染？有没有时间要求？
明确了输出之后，也不是马上处理，而是确定输入：
是我自己干，还是可以找几个人帮忙？我是否可以借保洁阿姨的工具？甚至领导预算充足的话，我们可以花点钱外包给保洁阿姨。
写代码的方法、函数也是输入、处理、输出吧。你算法写得再好、性能再高，结果不对也没用；或者你结果对了，处理写得也非常完美，可有个输入你压根得不到，处理写得再好又有什么用？为什么要面向接口编程？因为输入输出定了之后，处理大概率就没有问题了。
做产品、软件工程会经历这么几个阶段（先不提敏捷开发，以后专门讲）。这其实也是一个标准的输入、处理、输出，而且是把一个大的输入处理输出，拆分成很多个小的：
需求分析 → 概要设计 → 详细设计 → 编码 → 测试（单体测试、结合测试、性能测试、回归测试）→ 发布产品
现在基本所有的项目都更看重输出，这个叫结果导向；如果更偏重处理，叫过程导向。站在公司的角度，一定是结果导向，因为项目是为了盈利。但对于你，我建议要过程导向：结果当然重要，但在这个过程中你学到的技术和业务、积累的工作经验、提高的学习能力和解决问题的能力，其实更重要。
最后
今天想分享的就这五点。希望能有哪怕三两句话帮到你。还是那句话：最好不要听个热闹，你自己要多独立思考，我的经验只是我自己总结的，思考后实践以后，才能变成你自己的。
本文整理自我早年分享给团队的一份工作方法口头稿，署名、公司、项目以及所有引流、跑题内容均已删除。