10x程序员工作法
郑晔
火币网首席架构师,前ThoughtWorks首席咨询师 ,TGO鲲鹏会会员
立即订阅
7975 人已学习
课程目录
已完结 56 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 程序员解决的问题,大多不是程序问题
免费
思考框架 (1讲)
01 | 10x程序员是如何思考的?
以终为始 (11讲)
02 | 以终为始:如何让你的努力不白费?
03 | DoD的价值:你完成了工作,为什么他们还不满意?
04 | 接到需求任务,你要先做哪件事?
05 | 持续集成:集成本身就是写代码的一个环节
06 | 精益创业:产品经理不靠谱,你该怎么办?
07 | 解决了很多技术问题,为什么你依然在“坑”里?
08 | 为什么说做事之前要先进行推演?
09 | 你的工作可以用数字衡量吗?
10 | 迭代0: 启动开发之前,你应该准备什么?
答疑解惑 | 如何管理你的上级?
划重点 | 关于“以终为始”,你要记住的9句话
任务分解 (11讲)
11 | 向埃隆·马斯克学习任务分解
12 | 测试也是程序员的事吗?
13 | 先写测试,就是测试驱动开发吗?
14 | 大师级程序员的工作秘笈
15 | 一起练习:手把手带你分解任务
16 | 为什么你的测试不够好?
17 | 程序员也可以“砍”需求吗?
18 | 需求管理:太多人给你安排任务,怎么办?
19 | 如何用最小的代价做产品?
答疑解惑 | 如何分解一个你不了解的技术任务?
划重点 | 关于“任务分解”,你要重点掌握哪些事?
沟通反馈 (12讲)
20 | 为什么世界和你的理解不一样
21 | 你的代码为谁而写?
22 | 轻量级沟通:你总是在开会吗?
23 | 可视化:一种更为直观的沟通方式
24 | 快速反馈:为什么你们公司总是做不好持续集成?
25 | 开发中的问题一再出现,应该怎么办?
26 | 作为程序员,你也应该聆听用户声音
用户故事 | 站在前人的肩膀上,领取属于你的高效工作秘籍
27 | 尽早暴露问题: 为什么被指责的总是你?
28 | 结构化:写文档也是一种学习方式
答疑解惑 | 持续集成,一条贯穿诸多实践的主线
划重点 | 一次关于“沟通反馈”主题内容的复盘
自动化 (12讲)
加餐 | 你真的了解重构吗?
29 | “懒惰”应该是所有程序员的骄傲
30 | 一个好的项目自动化应该是什么样子的?
31 | 程序员怎么学习运维知识?
32 | 持续交付:有持续集成就够了吗?
33 | 如何做好验收测试?
34 | 你的代码是怎么变混乱的?
35 | 总是在说MVC分层架构,但你真的理解分层吗?
36 | 为什么总有人觉得5万块钱可以做一个淘宝?
37 | 先做好DDD再谈微服务吧,那只是一种部署形式
答疑解惑 | 持续集成、持续交付,然后呢?
划重点 | “自动化”主题的重点内容回顾汇总
综合运用 (7讲)
38 | 新入职一家公司,怎么快速进入工作状态?
39 | 面对遗留系统,你应该这样做
40 | 我们应该如何保持竞争力?
答疑解惑 | 如何在实际工作中推行新观念?
划重点 | “综合运用”主题内容的全盘回顾
总复习 | 重新审视“最佳实践”
总复习 | 重新来“看书”
结束语 (1讲)
结束语 | 少做事,才能更有效地工作
10x程序员工作法
登录|注册

02 | 以终为始:如何让你的努力不白费?

郑晔 2018-12-28
今天内容的开始,我希望你可以先来思考一个问题:如果让你设计一个登录功能,你会怎么做?
我曾在公司内部做过这样一个练习,我扮演客户,让大家帮我设计一个登录功能。同事们一听就高兴了,登录不就是用户名加密码嘛,我熟啊,我还可以设计出验证码、找回密码、第三方登录等等功能。
更有个别动作快的同事,甚至已经开始设计数据库表,考虑用 Redis 做缓存了。整个过程下来,大家彼此讨论得热火朝天,唯一没人理会的就是我这个“客户”。
讨论结束,扮演客户的我告诉大家,作为一个“土豪”,我打算做一个打车软件,用户可以通过手机号接收验证码的方式进行登录。你可以想见,同事们一副“被套路了”的表情。是的,他们设计那套用户名密码登录完全是文不对题。
虽然这是一个简单的练习,但反映的却是我们日常面对的真实工作场景:许多人都是刚刚听到别人要求做的一个功能,就开始脑补接下来的一切。导致的结果,就是付出的努力毫无意义。
那么问题出在哪呢?因为我们欠缺了“以终为始”的思维习惯。

一种反直觉的思维方式

以终为始,就是在做事之前,先想想结果是什么样子的。
说起来很简单,但做到并不容易。因为我们习以为常的思维模式是线性而顺序的,第一步做完,做第二步;第二步做完,做第三步。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《10x程序员工作法》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(57)

  • 每天晒白牙
    我们在生活中经常遇到这样的场景:许多人听到别人要做的一个功能,然后自己开始脑补后面的东西。导致的结果,付出的努力没有意义。同样在面试的过程中也会发生类似的事,面试官谈到一个点,还没等面试官说完,就开始吧啦吧啦说一堆,然而并不是面试官想要问的。
    这里面的问题是缺少”以终为始”思维习惯。
    任何事物都要经过两次创造:一次在头脑中的创造也就是智力上的或者第一次创造,然后才是付诸实践即第二次创造。
    第二次创造的成本往往相对较高,所以需要在动手之前,要在第一次创造上多下一些功夫。对于做产品来说,就是我们想给用户看原型或做各种问卷调查,充分理解用户喜欢的,只有符合用户的使用习惯,这样的产品做出来才有卖点。
    拿开发举例子,我们一般会经过需求评审-技术方案评审-写代码-测试-上线-测试。
    在需求评审阶段,pm给我们呈现的是最后的结果,这次需求想要达到的效果。
    技术方案评审就是rd根据需求给出设计方案,怎么用代码来实现这个需求,最开始我接触出技术方案就是在58同城,之前的公司没有这个过程。我们在出技术方案的时候,要考虑好需求的实现过程可能出现的各种情况,这点往往是最考验rd的,我还需要努力呀,团队内其他小伙伴做的还是很棒的。然后叫上小组内的同学,一起对这个方案的可行性进行评估,或者给出优化方案,总之技术方案评审这个过程是个思维碰撞的过程,也是一个架构的过程,不是说非得架构师才可以玩架构,不知道这样说会不会被架构师揍。
    写代码就是实践嗯过程即第二次创造的过程。这个过程需要在前面的基础上进行,如果需求理解有偏差,或技术方案设计的不好,在这个过程中往往是比较痛苦的。
    测试阶段很重要,我们听说过测试驱动开发(TDD),qa会根据这次需求想要的结果进行测试,这个过程很重要,就是再检验是否践行3了以终为始这个原则。其实我们的流程还有点欠缺,更好的流程是在开发前加上测试用例评审,之前待的一家公司有遇到过,把测试用例放到开发前面,会更好践行TDD,也更符合以终为始。

    说了这么多废话,总之就是践行以终为始,就是在做事情前,先考虑后果,以结果为导向来确定要做的事情。
    2018-12-28
    26
  • Edward
    开头的“套路”确实很生动。做技术的人会有这么样的倾向,听到要做一个功能,第一反应就不是去梳理功能的细节,而是把熟悉的技术(也有是自己业余时间研究的,想在项目里用上)拿出来,粗略地构想解决方案。也是那句话:“手里拿着锤子,看什么都像钉子。”

    2018-12-29
    18
  • jueyoq
    当前处于什么水平?
    优势:年轻(今年刚毕业),没对象(充足学习时间),善于钻研底层原理,对编程有热情,善于总结方法论,技术表达力强(会吹牛逼)
    劣势:完美主义,英语差,算法一般,计算机原理不成体系(非科班),稳定性差,数学功底一般,缺乏工作经验,工作效率低。

    有什么目标?
    想在技术上快速积累,达到主力开发程度。

    如何实现?
    吃透项目代码。
    看开源项目源码。
    写开源项目。
    输出博客,打造职业品牌。
    每天练习算法。
    总结方法论,提高工作效率。
    2018-12-28
    11
  • pyhhou
    感觉“以终为始”这样的思考模式其实在生活中经常出现,例如说要做菜给别人吃,得先考虑别人爱吃什么?南方人还是北方人?是否有饮食顾虑?自己会的菜当中哪道菜做出来更吸引人眼球?先是考虑好要做什么,再去买菜,然后做菜;还有就是买一个东西会先想买回去预期有一个怎样的效果,然后再决定买不买;

    “能够为别人带来价值,自己的价值才能体现出来”,感觉这才是做软件的初衷,也是一个程序员的目标,受教了;

    另外就是还请老师在后期的课程中指明程序员职业发展的最佳路径,或者授人以渔,道明如何去思考出属于自己的一个最佳路径,期待。
    2018-12-29
    9
  • Alexdown
    前段时间遇到一个事,领导派给我一个任务——做一个XXXX功能,没太细说就告诉我:你自己去想,自己去看别人怎么是实现的,把他弄出来

    我经过一番调研,这个大功能可以拆分为8个小功能。于是我将4个必备小功能(编号1~4)实现并提交;
    领导看了说:还少……功能呢。我一看哦还要加上6号小功能,实现并提交;
    领导看了又说:我们的业务我是这样……所以需要……。我理解后发现要加的不是8号小功能的变种嘛,实现并提交;
    领导看了没说什么算过了。几天后接到领导QQ弹窗:怎么没有……功能呢(我一看是7号小功能,还不等我说什么)你是怎么回事,总是少这少那的,非得我说的那么细吗一步一步告诉你怎么做?……

    真是日了🐶了,他不详细告诉我他头脑中的想象,但却要实现他要求的功能,问多了觉得你能力不行需要嚼碎了喂你,按我自己的想象实现后要经常返工,次数多了最终还是落在能力不行、做的太少啊等等负面评价

    现在接任务我都是战战兢兢,不知道该怎么办了,想听听老师和小伙伴们的意见和建议

    看来今天的文章,我觉得可以尝试原型,但考虑到地位的不对等以及我的“人设”已经定型了,实施起来有点难度

    作者回复: 这个问题很有趣,决定产品特性的究竟是谁,这是需要先明确下来的。如果这是你要做的事,你就在扮演产品经理的角色。你需要做的就是分析产品特性,找用户了解使用场景,而不是闷在办公室里空想。

    即便你只是为领导在做产品,你需要把你们会谈的结果详细地写出来,然后,发邮件让领导确认。一旦确认,你领导就不好拿这事说事了,因为你有证据。

    如果一个领导连自己的话都不认,你需要考虑一下与他合作的前景了。

    2018-12-28
    1
    9
  • 极客不落🐒
    “以终为始”,最常见的一个实践就是计划倒排了。先定时间,然后看功能是不是做不过来得砍掉一些,人力是不是不够需要补充一些,提前预知规避风险。

    作者回复: 你说得对,倒排时间表不是错,倒排时间表却不调整需求范围和资源配置就是问题了。

    2018-12-28
    8
  • yu
    延伸出来的思考。
    拿到一个需求先写接口文档,评审过了再开发代码。争取做到接口文档就是最终的实现方案,不需要做着做着再去沟通方案。而不是拿了需求文档,直接就写代码。
    好处:
    1. 写接口文档,可以更好的规划工作量和时间。
    2. 梳理的过程中,可能会发现一些考虑不周的技术问题,提前排雷。
    3. 评审的过程也是自我提高的过程,说不定沟通中有比自己认为的有更好的技术解决方案。

    作者回复: 很好的延伸思考。

    2019-02-14
    3
  • 王宇泽
    程序员版的高效能人士
    2019-01-13
    3
  • David Mao
    1.开发采用“以终为始”的原则有利于认清目标,提高开发效率。
    2. 根据自己的经历,在产品的整个生命周期,业务的部分如销售在前期需求评审及开发阶段介入,会更好的支撑后续的销售工作。实际遇到的情形,产品开发完成后,由于产品没有市场竞争力,导致销售人员销售时遇到很大的压力,站在全局的角度,销售也应提早介入,销售也可以提产品的需求。目前提的持续交付业务(销售)也应是里面的一个环节。总结起来就是业务驱动开发,业务驱动技术。
    2018-12-28
    3
  • helloworld
    这就是倒逼思维吧!在事情开始前先在脑海中模拟下整个过程,等到真的做起来时就游刃有余了!
    2019-02-15
    2
  • 喜悦
    今日概念:
    1. 想象共同体:集体对同一个目标达成的共同想象;
    2. 任何事物都需要经过两次创造:一次在头脑中,一次是付出实践;
    3. 遇到问题倒着想,再用工具模拟“想象共同体”发现潜在问题;

    今日总结:
    以终为始就是终局思维,这种思维方式会强迫我们的大脑去做计划。借用工具将想法表达出来更是有利于发现潜在问题,创造出“想象共同体”;
    2019-01-01
    2
  • 长满鱼的树
    我个人觉得以终为始的意思就是从结果开始倒排开发,先确认明确清晰不含任何二义性的需求和结果,然后再倒推软件的设计架构,再动手编码,在开发过程中不停调整和反馈,最终达成目标
    2018-12-29
    2
  • 感谢老师的回答,我之前描述的背景可能不完整,我们不是软件企业,不是我们自己做。而是我们老板想做为平台方中间方,找几家软件供应商合作卖软件。我觉得这种利润空间太小,本身软件行业价格竞争比较激烈了,还要赚中间利润,利润空间太小。其次,对于平台方来说,这个没有一点意义,又不能积累数据,也不能沉淀什么信息。老板太自以为中心了,提建议不符合他思维,直接就骂,根本不给你讲道理的机会。就像您说的,可能这种合作没有意义了。继续跟随老师的脚步,升级自己的思维,相信总有一天,能有更好的舞台,先准备着。
    2018-12-28
    2
  • 大力
    最近在复习10x程序员,并且在将每一课都做成思维导图,不知道郑老师有没有兴趣读读呢?实在不知该如何上传至极客时间。
    2019-05-12
    1
  • 王维
    这确实是一种思维方式,从结果反推前导,这条原则不仅适用于工作,而且还适用于生活。在具体的开发工作中,我也使用过这个原则,例如在做一个功能之前,我会画一个原型图,先让要使用的人确认,如果ok我们就动手开发。
    其实我们在生活或者工作中有意或者无意都用到了这个方法。

    作者回复: 赞!

    2019-01-08
    1
  • 小马
    嗯,这个方法不错,我从明天就开始实施!
    2019-12-11
  • arronK
    以终为始,我刚毕业准备找工作写简历的时候就是这么干的。
    1. 先确定我想要找到的工作是什么样的,
    2. 然后收集很多招聘网站上给出的对应需求,整理划分成一份简历的技能树
    3. 写好最终的简历
    4. 按照简历上的要求去学习和提升

    这个方法我自己用起来百试不爽,也推荐给了身边的朋友。哪怕不是要去面试,想提升自己的技能和价值,也可以假设写一份想要达成的简历,然后以终为始去执行。
    2019-11-16
  • 蓝懒懒
    emmm 用户故事……
    2019-09-05
  • hgf
    有时候在工作进行快结束了,就会回头考虑一个问题,做这个事情有什么特点?如果和现有的一样,那还有必要做吗?如果能以始为终的考虑问题,就不会一直走在别人已经走了很多次的老路上了。毕竟做重复的事情价值就没那么高了
    2019-08-28
  • javaadu
    上周在做一个大项目的方案评估,我就是用的这种思维方式—不断想我们的方案如何上线,如何真正在线上起作用,从这里出发,确实发现了原有方案的一个大问题,在按照这个思路过了两遍方案后,我的心里就很有底了
    2019-08-26
收起评论
57
返回
顶部