工作法：以终为始

最新推荐文章于 2022-06-25 08:11:44 发布

<花开花落>

最新推荐文章于 2022-06-25 08:11:44 发布

阅读量1.5k

点赞数

分类专栏：转载文章标签：工作

本文链接：https://blog.csdn.net/qq_31362767/article/details/121730960

版权

转载专栏收录该内容

7 篇文章 0 订阅

订阅专栏

文章目录

阅读整理自《10x程序员工作法》- 郑晔，详细内容请登录极客时间官网购买专栏。

如何思考的

软件行业的名著 《人月神话》，他给出了一个统计结果，优秀程序员的开发效率是普通程序员的 10 倍。40 多年过去了，这个数字得到了行业的普遍认同。

如何更高效地工作，怎样才能把时间和精力尽可能地放在处理本质复杂度的事情上，减少在偶然复杂度上的消耗。

思考三个问题：

我现在是个什么水平？—— 现状
我想达到一个什么水平？—— 目标
我将怎样到达那个目标？—— 实现路径

具体问题要怎么问，就可以遵循下面这四项原则：

以终为始
任务分解
沟通反馈
自动化

以终为始 就是在工作的一开始就确定好自己的目标。我们需要看到的是真正的目标，而不是把别人交代给我们的工作当作目标。你可以看出这个原则是在帮助我们回答思考框架中，Where are we going?（我们要到哪儿去？）这个问题。

任务分解 是将大目标拆分成一个一个可行的执行任务，工作分解得越细致，我们便越能更好地掌控工作，它是帮助我们回答思维框架中，How can we get there?（我们如何到达那里？）的问题。

沟通反馈 是为了疏通与其他人交互的渠道。一方面，我们保证信息能够传达出去，减少因为理解偏差造成的工作疏漏；另一方面，也要保证我们能够准确接收外部信息，以免因为自我感觉良好，阻碍了进步。

自动化 就是将繁琐的工作通过自动化的方式交给机器执行，这是我们程序员本职工作的一部分，我们擅长的是为其他人打造自动化的服务，但自己的工作却应用得不够，这也是我们工作中最值得优化的部分。

我们不是一个人孤独地在工作，而是与其他人在协作，想要做到高效工作，我们就要“抬起头”来，跳出写代码这件事本身。

大多数人工作低效是由于工作中偶然复杂度太多造成的，只要能够更多地将注意力放到本质复杂度上，减少偶然复杂度造成的消耗，我们“真实”的工作效率自然会得到大幅度提升。

面对问题时，用思考框架问问自己，现状、目标和路径。

如何让努力有效

在做任何事之前，先定义完成的标准（统一共识）。

做事之前，先考虑结果，根据结果来确定要做的事情。

事物经过两次创造：一次是在头脑中的创造，也就是智力上的或者第一次创造，然后才是付诸实践，也就是实际的或第二次创造。我们应该在第一次创造上多下功夫，统一集体想象，让目标更明确。

定义清楚一个任务完成的标准，期间需要做哪些事情，流程是怎么样的。

DoD（Definition of Done）的价值

DoD 是一个清单，清单是由一个个的检查项组成的，用来检查我们的工作完成情况。
DoD 的检查项，就是我们开发产品所需的一系列有价值的活动。比如：编写代码、编写测试代码、通过测试人员验收等。什么样的活动是有价值的，也许每个团队的认识是不同的。但如果你的团队认为除了功能代码，其他都没价值，也许这是个信号，说明你的团队整体上是缺乏职业素养的，在这样的团队工作，前景并不乐观。
DoD 的检查项应该是实际可检查的。
你说代码写好了，代码在哪里；你说测试覆盖率达标了，怎么看到；你说你功能做好了，演示一下。
DoD 是团队成员间彼此汇报的一种机制。
别把“汇报”想复杂了，最简单的汇报就是说一句“这个功能做完了”。当我们有了 DoD，做事只有两种状态，即“做完”和“没做完”。在团队协作中，我们经常会听到有人说“这个事做完了 80%”，对不起，那叫没做完，根本没有 80% 做完的说法。

DoD 是一个思维模式，是一种尽可能消除不确定性，达成共识的方式。

人与人协作中，经常会出现各种问题，根本原因就是，有太多因为理解差异造成的误解，进而浪费了大量的时间，而 DoD 就是一种将容易产生歧义的理念落到实处的方法。

简单的应用场景：

上级分配任务时，应该把完成的指标和工作的边界讲清楚，下级根据要求去做。
下级应不断提高技能，能自己定义DoD，请上级check，毕竟上级不希望每次沟通都占用较多时间。

接到需求任务

验收标准非常重要的一环是异常流程的描述。

采用用户故事之后，在写完主要流程后，再去看一下验收标准，为自己的开发查缺补漏。因为那是标准，达不成就不算任务完成。（用户故事就是一种固定的格式，让需求提出方把应该想清楚的问题想清楚。）

验收标准给出了这个需求最基本的测试用例，它保证了开发人员完成需求最基本的质量。

如果团队采用用户故事的格式进行需求描述固然好，如果不能，在功能列表中，补充验收标准也会极大程度地改善双方协作的效率。

当拿到一个需求的时候，要做的事不是立即动手写代码，而是扮演产品经理的角色，分析需求，圈定任务范围。

扮演不同角色的时候，我们的思考模式是不同的。

小结：

需求，是软件开发中的一个关键环节，一旦需求理解出现问题，势必会造成大量的浪费。传统的功能列表只是简单罗列了要实现的功能，丢失了大量的上下文，会导致团队成员对于需求“只见树木不见森林”。
而在比较大的团队中，更是会将一个功能分拆到多个小团队中，每个人看到的只是功能碎片。于是，后来产生了其他的需求描述方式，比如用例和用户故事。
验收标准不仅仅描述出了正常流程，也会关注到异常流程的处理，它也是验收测试用例的起点。一旦事先定义好验收标准，大量的扯皮工作就没了。

持续集成

在软件开发中，编写代码是很重要的一环，但程序员的交付物并不应该是代码，而是一个可工作的软件。当我们在一个团队中工作的时候，把不同人的代码放在一起，使之成为一个可工作软件的过程就是集成。

1996 年，Steve McConnel 出版了一本著作《Rapid Development》，国内译作《快速软件开发》。在这本书中，作者首次提出了解决集成问题的优秀实践：Daily Build，每日构建。通过这个名字，我们便不难看出它的集成策略，即每天集成一次。

在 2000 年时，“软件行业最会总结的人” Martin Fowler 发布了一篇重量级文章“Continuous Integration”。后面，以持续集成为基础，进一步拓展出持续交付的概念

虽然我们在同一个时代写代码做开发，但在技术实践层面，不同的团队却仿佛生活在不同的年代。这也是我们要学习的原因。

尽早提交代码去集成。

一个好的做法是尽早把代码和已有代码集成到一起，而不应该等着所有代码都开发完了，再去做提交。
不能再说代码写完了，就差集成了，因为这不叫开发的完成。

关于产品经理

我们必须要有自己的独立思考，多问几个为什么，尽可能减少掉到“坑”里之后再求救的次数。

要做产品，那就需要倒着思考，这个产品会给谁用，在什么场景下怎么用呢？

IT 行业是这样一个有趣的行业，一旦一个问题变成通用问题，就有人尝试总结各种最佳实践，一旦最佳实践积累多了，就会形成一套新的方法论。

从前的 IT 行业更多的是面向确定性的问题，所以，需要更多的是分析。只有当面向不确定性工作时，产品经理才成为一个行业普遍存在的职业。

当产品经理让我们做一个新的产品特性时，我们可以从精益创业这个实践上得到启发，向产品经理们问一些问题，帮助我们确定产品经理提出的需求确实是经过严格思考的。

默认所有需求都不做，直到弄清楚为什么要做这件事。

如何更好解决问题

我们一直在强调“以终为始”。所谓“终”，其实就是我们的做事目标。虽然大家工作在一起，朝着一个共同的大目标前进，但真的到了一个具体的问题上，每个人看到的目标却不尽相同。

有时有的人看到的是需求，而他看到的是一个要解决的技术问题。所以，不同人在对目标的理解上是有根本差异的。

不同角色工作上真正的差异是上下文的不同。

比如在项目里打杂，你只能关注到一个具体的任务，而项目主力心目中是整个系统。虽然写的代码都一样，但你看到的是树木，人家看到的是森林，他更能从全局思考。
同样，项目负责人的工作，虽然包括在项目组内的协调，但还有一部分工作是跨项目组的，他需要考虑你们项目组与其他组的互动。所以，他工作的上下文是在各组之间，包括技术和产品等方面。
部门负责人要协调内部各个组，同时要考虑部门之间的协调。而公司负责人考虑的上下文甚至要跳脱公司内部，进入到行业层面。

程序员总喜欢用技术去解决一切问题，但很多令人寝食难安的问题其实根本不是问题。之所以找不出更简单的解决方案，很多时候原因在于程序员被自己的思考局限住了。

多问几个为什么，交流一下是不是可以换个做法，许多困惑可能就烟消云散了。而能想到问这样的问题，前提就是要跳出程序员角色思维，扩大自己工作的上下文。

虽然我不是项目主力，但不妨碍我去更深入地了解系统全貌；
虽然我不是项目负责人，但不妨碍我去了解系统与其他组的接口；
虽然我不是项目经理，但我可以去了解一下项目经理是怎样管理项目的；
虽然我不是产品经理，但了解一个产品的设计方法对我来说也是有帮助的。

当对软件开发的全生命周期都有了认识之后，看到的就不再是一个点了，而是一条线。

当扩大了自己工作的上下文时，我们的目标就不再局限于一个单点，而是会站在更高的维度去思考，解决问题还有没有更简单的方案。许多在低一级难以解决的问题，放到更大的上下文里，根本就不是问题。

想把工作做好，就需要不断扩大自己工作的上下文，多了解一下别人的工作逻辑是什么样的，认识软件开发的全生命周期。

突破了自己只愿意思考技术的限制，世界一下子宽阔了许多。所以，有机会走到客户现场，看到更多公司的项目运作、公司是如何工作的。

机会总是垂青那些有准备的人，尤其在公司规模不大的时候，总有一些跳跃式的发展机会。

做事前先推演

对比我们的工作，多数情况下，即便目标清晰，路径却是模糊的。所以，不同的人有不同的处理方式。有些人是走到哪算哪，然后再看；有些人则是先推演一下路径，看看能走到什么程度。

即便已经确定了自己的工作目标，我们依然要在具体动手之前，把实施步骤推演一番，完成一次头脑中的创造，也就是第一次创造或智力上的创造。这种思想在军事上称之为沙盘推演，在很多领域都有广泛地应用。

在软件开发过程中，我们就假设软件已经就绪，看就绪之后，要做哪些事情，比如，如何上线、如何推广等等，这样的推演过程会帮我们发现前期准备的不足之处，进一步丰富我们的工作计划。为了不让我们总在“最后一公里”摔跟头，前期的推演是不可或缺的，也是想让团队进入有条不紊状态的前提。

想清楚了才能写清楚，它可以说是区分合格与不合格开发工程师的重要区别。软件开发过程中，最常见的例子就是拿到需求后不管三七二十一，上来就开始撸代码，但最后往往返工不断，质量问题层出不穷，而且加班没完没了，这里面一个根本原因就是没有系统地想清楚，但很多人都觉得前期澄清需求、分析设计是浪费时间，只有编码才是真正的创造价值，这就是差距。