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

18 | 需求管理:太多人给你安排任务,怎么办?

郑晔 2019-02-08
上一讲我们讲了需求的分解,我以用户故事为例,给你讲了我们应该把大的需求拆分成小的需求,但是不是只要把需求拆开了就万事大吉了呢?显然不是。今天我们再来探讨另一个与需求强相关的话题:需求管理。
需求管理?许多程序员的第一直觉通常是,这要么是产品经理的事,要么是项目经理的事,跟我有什么关系?我知道很多人会这么想,可我想说的是,如果你不了解需求是怎么管理的,即便是进行了需求分解,最终的结果很有可能依然是你深陷泥潭苦苦挣扎而不自知。
为什么这么说呢?我给你讲一个发生在我身边的故事。

最无脑的需求管理法:老板说的

有一次,我们组织了一次各团队负责人的吐槽大会,让大家把遇到的问题在台面上“摆”一下。一个开发团队的负责人说:“我这边倒排期太严重了,每个产品经理到我这里都说上线日期已经定好了,我这边资源有限,实在是抗不住了。”
出于好奇,有人问:“这些任务都一样重要吗?”
这个负责人无奈地摇摇头,“他们都说自己的任务重要。”
“他们凭什么说自己的任务重要呢?”我也问了一个问题。
这个负责人说:“他们告诉我,是老板说的。”
这是不是一个很熟悉的场景?一堆任务压过来,只是因为这是老板的一句话。我们的老板都是这么不近人情吗?其实,大概率来看,并不是。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《10x程序员工作法》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(8)

  • 西西弗与卡夫卡
    为了适当减少每次argue需求优先级带来的沟通成本,还可以把当前团队正在面对的四象限公示出来,让大家都能看到团队路线图,让提需求的人(产品经理更需要)看看自己的需求在哪个象限,什么优先级,有时候他们自己就明白了

    作者回复: 可视化是个好办法

    2019-02-08
    2
    10
  • WL
    程序员也应该更积极主动一些, 最好能推动事情发展, 当这件事情由你推动时主动权就在你的手里了

    作者回复: 谁积极谁主动

    2019-02-12
    4
  • 开发团队无力反驳产品经理的需求,工作方式被动,话语权受限也是原因之一。虽说公司内各有分工,但大部分公司还是具备宽松氛围的,一直从事某产品开发的员工,只要不局限于自己的一亩三分地,即便不具备老板的视角,产品经理那点小九九还是能有对策的。其实不管是谁,什么角色,掌握工作的主动权最重要,重大事项商量着办,彼此协作才能越发默契。

    作者回复: 别人限制不了你,自己限制自己了。

    2019-02-09
    2
  • 风翱
    团队中的需求来源就是简单文字描述,而且还是上一层需求收集人员理解以后补充上去,再给到产品经理那里。和文章说的,很多时候,就是某位领导说要做的。而团队中负责人听到是某领导提出时,并没有给出相应的方案,结果是都要做。提出的所有需求,都是紧急且重要的。因信息不对称,底下人很难判断其紧急和重要的程度。结果就是不停的加班,通宵赶进度,留下很多的技术债务。

    作者回复: 你不主动,你就被动。

    2019-02-08
    2
  • 丁丁历险记
    1 套路包收集,留证据,把面对不确定性的决策风险(锅)甩给产品,把自己定位搬砖的。

    关于尽量做重要的事,个人理解如下。
    做好重要不紧急的事。 这项能力决定了人生的高度,是我开发生涯的信条。
    例如重构,轮子优化,(极端情况下直接造),这些努力的背后哲学是,让体力活向智力活迁移,有时候少做是高纬度的多。

    例如 在开发中不断和产品沟通已期待更好的为用户服务,更合适的开发资源投入。

    文中谈到了站在老板面前。
    我回忆了一下,好像更多是直接推开老板们,看他不忙就直接沟通的,关键问题直接硬怼,沟通能三句话说明白不扯第四句,有开脑洞场景的再放开聊,庆幸老板懂技术。 真的别怕,也没必要怕,我是信奉技术王道的,而我的目标是专注做优质产品的,我有问题你直接说,我思考后改(还有可能不改) ,大家目标一致,严重忙不过来,哪有空怕老板。 只管向死而生的活着。注意下身边的小人即可,这类人多了,直接走,也别犹豫。
    2019-11-09
  • Sudouble
    二刷的收获:管理好任务的优先级,并尽量想清楚关键任务的价值。积极主动,让自己收获更多!
    2019-04-16
  • like_jun
    做有价值的事。
    2019-03-07
  • 极客不落🐒
    敏捷 4+1 会,迭代列表 + 产品列表,可以解决大部分问题了……
    2019-02-13
收起评论
8
返回
顶部