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

04 | 接到需求任务,你要先做哪件事?

郑晔 2019-01-02
我们书接上文,继续讲程序员小李的故事。这次小李接到一个新的需求,让他开发一个单点登录的服务,经过几天的奋战,他顺利地写完了所有的代码。正好产品经理小王路过他身边,顺便问了他一下。
小王:单点登录做得咋样了?
小李:做完了,我给你演示一下。
小李演示了一遍自己做的功能,小王看上去很满意。
小王:不错。不过,怎么没有支持验证码?
小李:为什么要做这个?
小王:这不就是登录的一部分吗?
小李:哪里规定要做验证码了?
小王:现在做登录哪有不用验证码的?
我想你已经嗅到了双方谈话的火药味,这个时候如果双方都不能很好地控制自己的情绪,那接下来一场体力的较量可能就一触即发了。
为什么双方会有这么大的分歧呢?其中一个重要的原因是,开始实现这个需求之前,任务双方都没有清晰地定义好边界,没能把需求描述清楚。

需求描述的问题

在软件开发中,程序员做什么一般都由需求来定义。我们都知道,需求是软件开发的一个重要组成部分,但你可能并没有仔细想过,不同的需求描述方式,可能会影响我们程序员对需求的理解。
因为信息的传递是会衰减的,你不可能把你理解的信息 100% 传递给另外一个人,而这中间,如何传递,也就是如何描述将直接决定衰减的比例。
很多公司的软件开发模式是基于功能列表的,这个列表“规定”了程序员要做的功能,各个组从产品经理那里领来开发列表,然后“照单抓药”开始写代码。但是,通常这种功能列表只是一些简单的描述,你并不能看到全局。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《10x程序员工作法》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(38)

  • liu
    程序员的核心职责是如何实现产品功能,怎么实现功能;前提是理解产品功能,需要实现哪些功能。有些项目经理,产品经理与程序员角色混淆。你同他谈功能,他同你谈技术实现,你同他谈技术,他同你谈产品(需要实现哪些功能)

    作者回复: 你能分辨出你们讨论的不是一回事,这是很强的能力。其实,与任何角色沟通都一样,能够识别出双方讨论的不是一回事,及时制止,会大幅度提高沟通的效率。

    2019-01-02
    20
  • 彩色的沙漠
    老师您好
    一个产品经理没有想清楚需求的前提给我们开产品需求讲解会,每次就会造成开发和测试的轮番轰炸产品细节,产品经理的回答就是我下去再想想,第二次再开产品需求会的时候还会遇到新的产品细节,产品经理还会回答我下去再想想。看来这个产品经理就是没有定义好验收标准,只是想好了市场部提给他的需求。
    那么问题了
    1、“验收标准给出了这个需求最基本的测试用例,它保证了开发人员完成需求最基本的质量”
    这个验收标准给的太基本还是会在后期开发中浪费时间,尽量的详尽很考验产品经理的职业素养以及时间成本,如何去衡量这个最基本的验收标准?
    2、团队开发中需求变更在所难免的,产品变更需求如何同步给大家最有效,以及需求更变的痕迹如何可追踪。请问老师在团队开发对于这种问题有什么最佳实践,谢谢!

    作者回复: 这种现象可能有两种原因,一是产品经理没想清楚,二是问题复杂到产品经理想不清楚。实际上,这是一个问题,产品经理缺乏好的工作方式,他需要将产品特性做分解,分解一个个的小需求去实现。另外,变更不可怕,大变更才可怕。这其实是任务分解模块要讨论的内容,敬请期待。

    2019-01-03
    8
  • 小可
    我说两点感受
    1.有不少开发,纯粹为了完成任务而完成任务,从来不考虑自己开发的功能到时候怎么用,开发完随便点点就提交测试了,我要是测试已经崩溃了😂
    2.另外一个,遇到不专业的专职产品经理,给出的全是需求矩阵,两句话描述一个功能,开发的时候思考这些细节真是浪费时间
    2019-01-02
    8
  • davidce
    请作者如果能顺便介绍一下每节课内容相关的国内当前行业现状,就像回复评论中的那样就好了。

    作者回复: 好建议,后面的内容我适当调整一下。

    2019-01-03
    6
  • Xunqf
    就像老师文中提到的,产品只考虑正常逻辑,异常是不做考虑的,然后交付设计,设计也不会出异常页面的UI,开发补充的异常提示信息和异常界面又往往不是产品想要的,往往容易在验收的时候反复修改。而且有些细节问题往往是在做的过程中才发现的,这个时候做一点就去和产品确认一下又非常影响开发效率,老师有什么比较高效的方法吗?

    作者回复: 开发效率是什么?我反反复复强调地一个观点就是,开发效率不是写代码的效率。细节不确认就动手,后期还会反复,更浪费时间。

    有些细节确实是只能在开发中发现的,所以,最好的办法是,让产品经理与开发团队坐在一起,随时确认。退而求其次,每天确认一次。

    2019-01-07
    1
    4
  • 喜悦
    今日概念:
    1. 开发功能列表:对开发标准做简易描述的列表,容易丢失信息;
    2. 用户故事:用户故事是一种分析需求的方法,能将各个功能串联起来以便做场景化的思考。最重要的是它能确定验收标准,这将作为后续开发的准绳;
    3. 验收标准:规定以终为始开发的结果,可以使用 DoD 来制定;

    今日总结:
    开发中的许多问题都是由于思考不够深入,沟通不够细致造成的,用户故事能将沟通中丢失的关键环节暴露出来,(切换角色至项目经理)走通用户故事之后再制定验收标准,这时我们的开发流程就变得可控了;
    2019-01-04
    3
  • Geek_fe0336
    听老师的案例有种感觉案例中产品经理不具备基本的需求方面的知识和技能。听到第四课,得出初步结论,10倍速程序员,最直接的方式是找一个有合格产品经理的团队,从业这么多年有个感觉就是,软件行业的工程师是最不像工程师的工程师。因为好多人不具备基本的工程知识和工程化的技能。甚至不具备软件工程的通识,门槛太低是个最大问题。一方面程序员们自认为是专业人士,另一方面确连基础知识都不愿去学。很难想象一个不懂乐理,不持续练习的乐手上台演奏,一个没上过医学院,没练过大量实习的医生去开刀,但程序员呢。说到底,老师讲的都该是一个自认为专业人士具备的基础知识,基本工作技能,基本沟通能力。

    作者回复: 好的产品经理可遇不可求。所以,我们只能倒逼产品经理交出靠谱的答案。

    IT 行业入门门槛还是低,时间还是短,专业的人太少了。

    2019-03-21
    1
    2
  • 大帅哥
    产品经理太强势,需求总是列出几个功能点,用户故事和验收标准完全说不清楚,每次需求评审耗费大量时间讨论,结果功能做出来了,又说不是产品经理需要的,由此可见推动制定验收标准是何等重要

    作者回复: 每个人都需要考虑一下,令自己信服的到底是态度,还是道理。做出的东西不是需要的,需要怎么让它变成需要的呢?不去面对这个问题,问题永远解决不了。

    2019-01-04
    2
  • Monday
    项目都快到截止日期了,心里总是没底。因为开发,项目负责人,产品经理,测试工程师。。。都是自己。看完此篇才知道验收标准如此重要。现在的情况是没有明确的验收标准,,,怎么做才是最好?

    作者回复: 先有验收标准,按照自己的理解,怎么有助于提高怎么来。

    2019-01-03
    1
    2
  • 大彬
    在华为,我们部门是没有产品岗位的,需求是se传递给开发人员的,se大多也是从开发升级上去的,所以需求看起来还算“顺畅”,拿到需求,就要先看,然后拉上se和测试,让se再给我们介绍一遍,解决开发和测试的疑问,这个环境是公司要求不能少的,所以都搞清楚再开始各自的工作,最后才能无缝连接起来
    2019-01-02
    2
  • 虢国技匠
    打卡
    开始之前就定义好验收标准

    编辑回复: 打卡的方式挺好的,加油💪

    2019-01-02
    2
  • L
    突然觉得,这个东西很适合产品看啊。。。

    作者回复: 欢迎把文章转发给你们的产品同事!

    2019-01-02
    2
  • 产品经理没有完整的产品思路,只有一个大概的功能点,项目经理只谈开发功能的必要性 给不了技术支持,烦躁。。

    作者回复: 把事情做细,让他们把需求分解好,别替其他人填坑。

    2019-04-16
    1
  • 猿工匠
    在做任何任务和需求之前,先定好验收标准
    验收标准包括:正常流程、异常流程
    在确定验收标准中,最好用“用户故事”来定义,且站在项目模块的角度来看待需求。
    这样在分析需求和“用户故事“中,可以更完整地看问题。
    2019-03-19
    1
  • 孤独的二向箔
    郑老师有个疑问,我厂没有这种流程,大家都是以交互稿为验收标准,虽然有时候交互会漏一些异常情况,但是这不是这种形式本身的问题,补上就行了。
    交互稿还有个好处就是更直观,前后端都可以使用。
    最后验收的时候一般不会出现大的偏差,小的偏差通过产品交互视觉运营走查就能解决。

    这两种形式有什么优劣吗?还有您的公司前端程序员也是用用户故事来做参考吗?

    作者回复: 交互稿只是需求交付的一部分,不是全部,中间的的缺失是靠你们团队的通力协作解决的,你们的方法在你们特定的上下文可以起作用,但很难作为通用的实践推广。

    用户故事与前端还是后端没有关系,关注的是业务价值。

    2019-01-23
    1
  • MarksGui
    产品经理往往考虑不到很多异常情况,因为很多产品没有技术背景。作为项目经理,后续我应该承担起这部分工作的责任。第一划清需求边界,避免天马行空的讨论。第二着重考虑异常流程。第三定义验收标准,然后转交给测试。 最后真心希望作者能给出国内大公司的一个开发流程和一些工具(比如腾讯的tapd就不错),这样能让很多小公司的人员也能学习大公司的先进管理模式。不胜感激。

    作者回复: 其实,国内很多公司在软件开发过程上做得并不是特别优秀,甚至有一些添麻烦的做法,而且,往往是在一个特定场景下适用的。倒是一些产品开发的过程,确实有做得不错的。在软件开发这件事上,行业里的最佳实践几乎都是公开信息,学习这些最佳实践比学习所谓大公司的做法要来得容易,因为这些实践是在很多地方验证过的。

    2019-01-03
    1
  • 光明
    【需求不清晰】带给我最大的问题就是 经常返工!不光是需求上面,在领导分配的任务(也算是需求吧)上面理解出现偏差,最终做出来的东西不符合领导要求,这和上一篇的 DoD 有共同的地方,什么是完成?什么是验收标准?经历过,踩过坑 才知道【以终为始】的重要性!
    2019-01-02
    1
  • Xu
    请问郑老师,在以往的项目经验中,对测试驱动开发TDD怎么看?从逻辑上,根据已有的DoD或验收list, 是可以先写测试用例的。BDD的定义也可以比较容易的转化为测试用例。这样的流程更贴近于以终为始的概念,只是有些反常规,毕竟程序员的意识里最直接就是写功能。请问在ThoughtWorks 或国内大厂TDD和BDD的使用如何,有没有好的项目实例或一些坑可以避免?

    作者回复: 后面会专门讲到TDD和BDD。国内的团队大多停留在能写测试就不错了的阶段,好一点的公司,对测试覆盖率有要求。很多人对于测试的理解有误,这是后面会讲到的。

    2019-01-02
    1
  • 丁丁历险记
    笔记
    1 故事描述。快速以窥全貌,理解用户关键需求。
    2 检查清单,非常的重要。

    小公司场景下,程序员自己写检查清单。

    有趣的话,没有代码的代码最好维护。
    一些想法
    还是那句话,事物有两面,容易变成相互推诿,所以找对合作伙伴很重要。
    2019-10-30
  • 陈斯佳
    老师,想问一个具体的问题,您在工作中有用到RTC这个软件吗?我感觉现在市面上的公司都在用Jira,很少听到用RTC的。我现在的新公司是在用RTC,我感觉网上很难找到学习材料啊…

    作者回复: 这个真不了解。

    2019-07-10
收起评论
38
返回
顶部