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程序员工作法
登录|注册

11 | 向埃隆·马斯克学习任务分解

郑晔 2019-01-23
这次我们从一个宏大的话题开始:银河系中存在多少与我们相近的文明。我想,即便这个专栏的读者主力是程序员这个平均智商极高的群体,在面对这样一个问题时,大多数人也不知道从何入手。
我来做一个科普,给大家介绍一下德雷克公式,这是美国天文学家法兰克·德雷克(Frank Drake)于 1960 年代提出的一个公式,用来推测“可能与我们接触的银河系内外星球高等文明的数量”。
下面,我要放出德雷克公式了,看不懂一点都不重要,反正我也不打算讲解其中的细节,我们一起来感受一下。
不知道你看了德雷克公式做何感想,但对于科学家们来说,德雷克公式最大的作用在于:它将一个原本毫无头绪的问题分解了,分成若干个可以尝试回答的问题。
随着观测手段的进步,我们对宇宙的了解越来越多,公式中大多数数值,都可以得到一个可以估算的答案。有了这些因子,人们就可以估算出银河系内可以与我们通信的文明数量。
虽然不同的估算结果会造成很大的差异,而且我们迄今为止也没能找到一个可以联系的外星文明,但这个公式给了我们一个方向,一个尝试解决问题的手段。
好吧,我并不打算将这个专栏变成一个科普专栏,之所以在这讲解德雷克公式,因为它体现了一个重要的思想:任务分解。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《10x程序员工作法》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(16)

  • pyhhou
    实际工作中来看,如果对一个任务,或者说是一项技术不是特别了解的话,确实很难做细致的任务分解,往往就是列一个粗糙的大概计划,然后去执行,在执行的过程中就发现很多计划都存在问题,一个计划里面还涵盖了之前没有考虑到的细节,导致任务项目充满了不确定性。很想听听老师的意见,就是在一个自己不熟悉的,充满未知的项目中该怎么更好地进行任务分解,还有这种分解的思想在平时是否可以通过一些练习和思考来加强,并应用到广泛的工作学习中去,期待~

    作者回复: 好问题,我就在答疑里谈谈这个问题吧!

    2019-01-23
    18
  • 大彬
    我会的任务分解,不仅可执行,粒度还很细。比如说,我要修复一个rpc接口的bug。我会列出每个代码的修改点,要修改的测试,要增加的测试,合并到哪个分支,修改rpc文档,文档中有哪些点要修改。

    每一步都非常容易执行,看起来每多少必要,但在我当前的工作环境特别有用:1)事前思考,不会造成遗漏,2)任务实施过程中经常被打断,比如,测试有疑问和你讨论,主管找你谈事,紧急会议来了,这种“硬中断”完全打破了节奏,而任务列表,让我知道清楚当前做了多少,该从哪一步继续。

    作者回复: 很清楚的做法!

    2019-01-25
    13
  • 🌲树根🌲
    如果清楚知道接下来怎么做,任务分解就告一段落。其实清楚就是知道是否可执行,如何执行,越是知道每步细节越能把控全局。

    但往往就是以为自己“清楚”,才导致任务评估不准。特别对自己没做过的领域,做沙盘推演,以结果导向推导任务推进过程,做好排坑。

    另外一点受益的,就是分解任务不单单是任务内容的分解。特别是文中提到的特斯拉通过建立公司引入专业人才,或者图数据库需要学习的知识。真正分解是如何达成任务目标,分解所需的步骤、资源、风险。

    我现在缺的是系统分解目标,清楚知道自己下一步要做什么,需要哪些资源。

    作者回复: 多练习,做事之前先分解。

    2019-01-23
    3
  • 西西弗与卡夫卡
    最近在做战略拆解,都是一样的道理。战略飘在空中遥不可及,要落地就必须拆解。比如说达成目标有哪几个方面可以努力,各方面都需要做哪些事,这是路径。这些路径里哪些优先级最高,需要配置哪些组织资源。心里有数之后就是制订计划时间表。

    作者回复: 你做的非常棒!

    2019-01-23
    3
  • Geek_kevin
    任务分解和敏捷开发的用user story应该是相似的,首先我们会定义大的feature,这个是大的产品经理关注的,然后我们基于feature分解成不同的user story,最后每个story,再分解成一个个具体的task,我们程序员就主要解决task。

    作者回复: 喂,110吗?有人知道的太多了。:)

    2019-01-24
    2
  • liu
    任务分解至自己能够解决的程度,即达到分解任务的粒度。然后以此估算工作时间与工作量。面对个陌生的事务,逐渐将不可控转化为可控,直至最后全面掌握
    2019-01-23
    2
  • 北天魔狼
    网站积分清算都是系统定时任务,老是担心时间超时任务失败。后来把任务按照时间拍好顺序,保证每个任务都不超过一分钟,运行时间间隔大于5分钟。再也没有出现过运行失败

    作者回复: 不错的分享!

    2019-01-23
    2
  • 春之绿野
    前两天分解一个任务,第一步是写一个template,我想着写一个template算是可执行了吧,但写template主要是为了做成自动化,自动化的话还要考虑怎么自动更新,生成,问题多着呢,最后做着做着就变成来不及了也不自动化了,先做一个出来再说吧
    2019-06-01
    1
    1
  • 木子輕颺
    任务分解是一个很好的策略,其实日常做事情也在做任务分解。比如在家里做饭,需要开始准备做什么菜、整理材料、蒸饭、炒菜。根据每个人的理解不同,会有不同的步骤,而且每次都不太一样。这里默认的就已经有任务分解在里面了。

    日常生活的自动化,或者称为习惯,大脑会在后台做任务分解反而降低了感知度。想要精细化的控制任务,就需要做可感知的任务分解。明确每一个步骤,做到可执行化。

    对于一个大的任务,或者未遇见的任务大脑的默认方式就不起作用了。这时会体现出懵懵的感觉。这种情况应该会有策略在之后的课程中讲解吗?

    作者回复: 大任务分解的方式就是一点点分解,但对于不确定的任务,我准备在答疑中,专门讨论一次。

    2019-01-25
    1
  • 公号-代码荣耀
    云计算,大数据等底层实现思想都体现了分而治之的分解逻辑。
    2019-01-23
    1
  • 潘pan
    做一个需求是,往往需要预估完成时间。但遇到的问题是:无法正确的分解任务,以及不知道任务难易程度和自己的解决工时,就会有无法预估的情况。请问这个情况怎么进行处理
    2019-10-16
  • 陈斯佳
    任务分解其实也像是老师所说的,事前忙,而不是事后忙。做事之前,先在脑袋里过一遍,把任务拆解成一个个可执行的微操作,之后就可以相对无脑的执行了。
    2019-07-23
  • 之前做过要把好几个小项目换框架,它们之间又有相互的调用,感觉要动一个就得动整体,无从下手,最后下定狠心做的时候,就是分解开,第一步先搭建一个空的能跑起来的项目,第二步将其中一个项目中的某个功能进行实现,比如登录,然后一步一步挪功能,等都挪完了,项目也就换完了,其中还有在具体功能的时候分解,比如登录的时候 ,第一步先导入包,第二步 进行配置 ,第三步实现简单的数据通信,第四步修改参数获取项目需要的用户数据,感觉真正做起来的时候,反而没有想象中那么难

    作者回复: 你做得很棒!

    2019-04-18
  • (^_^)
    让我想起一类面试题 ,譬如煎饼摊大妈的收入估算、估算北京一年出租出去的房子数量等等,将一个原本毫无头绪的问题分解,分成若干个可以尝试回答的问题

    作者回复: 嗯,是这个意思。

    2019-02-12
  • 虢国技匠
    打卡
    2019-01-23
  • 王维
    个人认为,要做到精确的任务分解任务,在实际工作中比较困难。如果不能对细节了如指掌,如果不能对全局高屋建瓴,要精确的分解是不可能的。我的指导思想是,在一项任务开始之前,做粗略的任务分解,然后随着任务的进行,边做边完善。说的通俗点就是边走边看。其实不管是做技术,还是给自己定发展目标,都是一样,一开始给自己定长期目标,然后具体到当下,我们就分解目标,边走边计划,边走边看!

    作者回复: 分解到什么程度取决于自己的把控能力,不清楚的部分不分解是一种风险。

    2019-01-23
收起评论
16
返回
顶部