10x程序员工作法
郑晔
火币网首席架构师,前ThoughtWorks首席咨询师 ,TGO鲲鹏会会员
立即订阅
7938 人已学习
课程目录
已完结 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程序员工作法
登录|注册

09 | 你的工作可以用数字衡量吗?

郑晔 2019-01-14
今天的分享从日常工作开始。请你回想一下,你每天到岗之后做的第一件事是什么呢?然后你来猜猜我的答案是什么?你可能猜不到,我每天到公司之后,第一件正事是看数字
我现在服务于一家做数字资产的公司,我们提供的是一个 24 小时运行的服务。从加入这家公司的第一天开始,公司的人就给我不断灌输一个重要理念——看数字。在我座位的正前方,摆着一个巨大的显示器,上面展示着各种不断变换的曲线、柱状图和数字,这些数字反映的是各种系统运行的指标。
我们就是每天看着这些指标,来发掘一些线上系统问题的,一旦某些指标出现自己不能理解的异常,就要着手调查。
你或许会纳闷,我们不是在探讨“以终为始”吗?怎么变成了一个关于监控的讨论呢?别急,我们确实还在讨论“以终为始”,因为数字是诠释“终”的最好方式。
我们前面讨论了各种“终”,但通常靠语言定义的“终”,或多或少都会存在一些模糊的地方,也就是容易产生误解的地方。而数字却是一个明明白白的“终”。比如,测试覆盖率要求 100%,即便你做到了 99.9%,不达标就是不达标,没什么好说的,说破天也是不达标。
再比如,之前内容我们讲到精益创业时,提到了一个重要的反馈循环:开发(build)- 测量(measure)- 认知(learn)。你会发现,在这个循环中,开发(build)是可控的,认知(learn)必须是得到反馈之后才能有的。所以,这里面最需要我们回答的问题是测量(measure)。而这里的测量,最好的检验标准当然就是数字。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《10x程序员工作法》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(16)

  • geoxs
    我们的产品之前没有什么监控数据,有一次系统莫名其妙所有的api都变慢了,分析不出原因。最后还是写了个小程序读取系统日志,统计一段时间内每个api的调用情况(调用时间、调用时长、调用次数等等),导出成统计数据以后,一下子就清晰了。

    作者回复: 做得不错!

    2019-01-15
    5
  • 彩色的沙漠
    数据对技术方案选定,运营方案的改进,验证产品特性是否合理,面试,提供强有力的支撑作用。"数字也是沟通的一把利器,用数字说话,避免空谈",可以提高沟通效率。
    每个公司都有绩效衡量一个员工,但是我遇到的公司对于绩效这件事,衡量指标都都比较主观,唯一比较客官的指标是代码量和BUG数,不知道老师经历的公司是怎么衡量绩效这件事的,谢谢!

    作者回复: 你会发现,我在建议用数字来发现问题和解决问题,但我不倾向用数字做为绩效,因为太具有误导性了,至少现在还没有哪个指标是令人信服的。我知道很多公司用代码量和BUG数,但我认为,这些指标应该用来发现问题,而不是当作绩效标准。

    2019-01-15
    3
  • 大帅哥
    线上接口日志统计少,很多业务日志虽然也加上了,但很少去关注。更多的情况是不知道打印哪些日志,更别说相关指标的数字了,上线新功能时只能人工的访问下接口,一个接口异常时,每天都需要花费不少时间去定位。现在有了日志和采集统计,一有问题立马可以看出来,随时做好回滚的准备。

    作者回复: 日志也是一个很有趣的话题,少了不行,多了也不好。

    2019-01-15
    2
  • helloworld
    想法很好,但是我所遇到的公司没有一个按照数字说话的

    作者回复: 你可以推动变化,可以的。

    2019-02-21
    1
  • 喜悦
    今日概念:
    1. 算法、算力和数据:现在企业不缺算法(行业共有)、算力(云计算),但数据依然是必争的稀缺资源;
    2. 数字:数字能量化问题,避免空对空谈话;

    今日总结:
    使用数字衡量工作能更顺利的团队和非IT人员沟通,并且也可以及时监控自己的工作状态。使用数字量化,可以先从沟通开始,少用甚至不用“可能”、”应该“、“大概”等字眼,在监控系统状态的时候,也都尽量将指标量化而不是凭感觉。这样做了之后可以减少内部甚至外部沟通成本,更好的规划自己的工作,也能快速确定系统出现问题的原因。
    2019-01-24
    1
  • AlanP
    感觉公司要做到CMM第4级还是有难度的,需要有人持续推进,也需要每个人都有量化的意识

    作者回复: 个人并不推荐CMM这种重量级的软件过程,但持续改进和量化的意识是要有的。

    2019-01-15
    1
  • 246小言
    看得出老师的用心
    2019-01-14
    1
  • 大彬
    特别认同。上周我把一个方案进行推迟了,让同事去搜集某项指标的数据,没数据,一切方案都是空谈。

    AB测试,留言量,阅读量,转发量一切数据都是下一步决策和改进的基础

    作者回复: 你的做法值得推广!

    2019-01-14
    1
  • 西西弗与卡夫卡
    比如开发常常关注的是产品经理提的功能有没有实现,实际上也应该了解做出来的有多少人使用,每个页面有多少人使用。

    此外,看开发是否努力勤奋,不要光听他说,而是要看看他提交git有多频繁、提交的时间段、代码量有多少。代码质量可以用bug数/代码量来衡量。当然,这些量化未必科学,甚至会被误用,但总胜过凭印象拍脑袋的判断。

    作者回复: 特别认同你的这个说法,量化好过于空口白牙,但什么工具都抵不过滥用。

    2019-01-14
    1
  • 丁丁历险记
    我的工作,是用堆(优先队列)来描述的。
    确实一直没思考用一个数字来量化。始终在模糊这个概念。
    2019-11-01
  • 丁丁历险记
    从数字来看,好的系统应该是死水一潭。👍
    2019-11-01
  • @syj@
    产品设计时过多的考虑可行性,很少拿数据说话。
    2019-03-11
  • 新博
    明确数字所代表的意义,在沟通的时候,特别是和非技术人员,能让自己的观点更有说服性。也让自己的工作有衡量依据。

    作者回复: 空对空的讨论,特别容易发散,有依据的讨论更能聚焦。

    2019-02-25
  • 111
    现在微服务中服务监控,服务治理都主要以数字作为指标
    2019-02-24
  • 蛀牙
    对于一线的系统操作员,我们无法得知常用的查询条件,通过记录统计查询条件的数字,可以针对复杂查询进行优化。这是我能想到的我们公司以始为终用数字测量的应用场景。
    2019-01-14
  • 虢国技匠
    打卡
    2019-01-14
收起评论
16
返回
顶部