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

06 | 精益创业:产品经理不靠谱,你该怎么办?

郑晔 2019-01-07
前面谈到验收标准时,我们说的实际上是确定性需求,也就是说,我们已经知道了这个需求要怎么做,就差把它做出来了。而有时候,我们面对的需求却是不确定的,比如,产品经理有了一个新想法,那我们该如何应对呢?
今天,我们从 IT 行业一个极为经典的话题开始:程序员如何面对产品经理。我先给你讲一件发生在我身边的事。
有一次,我们一大群人在一个大会议室里做一个产品设计评审,来自产品团队和技术团队的很多人都参与到这个评审中。一个产品经理正对着自己的设计稿,给大家讲解一个新的产品特性。
这个公司准备将自己的服务变成了一个云服务,允许第三方厂商申请,这个产品经理给大家讲解的就是第三方厂商自行申报开通服务的流程。听完前面基本情况的介绍,我举手问了几个问题。
我:这个服务会有多少人用?
产品经理:这是给第三方厂商的人用的。
我:我问的是,这个服务会有多少人用。
产品经理:每个第三方厂商的申请人都会用。
我:好,那你有预期会有多少第三方厂商申请呢?
产品经理:呃,这个……我们没仔细想过。
我:那现在给第三方厂商开通服务的具体流程是什么。
产品经理:第三方厂商申请,然后,我们这边开通。
我:好,这个过程中,现在的难点在哪里?这个审批过程能让我们的工作简化下来吗?
产品经理:……
我:那我来告诉你,现在开通第三方厂商服务,最困难的部分是后续开通的部分,有需要配置服务信息的,有需要配置网络信息的。目前,这个部分还没有很好的自动化,前面审批的部分能够自动化,对整个环节优化的影响微乎其微。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《10x程序员工作法》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(33)

  • 西西弗与卡夫卡
    有的产品经理会使出必杀技——这是老板的需求😃

    作者回复: 好啊,我们一起到老板那里去,看看老板的需求是不是你给我解释得那么不明就里。这只是与产品经理交互的第一集,后面还有。

    2019-01-07
    2
    22
  • 乘风
    我觉得说得都没错,但是我觉得开发得是总监级别的,不然普通开发根本没有这样发言权,在我们公司开发真的就是需求实现机器,特别弱势,就算是总监也没办法影响需求,项目经理更是屁都不敢放一句

    作者回复: 你不管理他,你就很难受

    2019-01-07
    14
  • Xunqf
    当你很产品理论的时候,他往往会拿出来一个现有的产品给你看:“人家怎么就能做到,人家能做到说明技术上是可行的,做吧。”时间久了你会发现他的需求全是抄的的别的APP,然后就觉得别人能做到的我们也一定能做。

    作者回复: 你需要分清楚两件事,技术与需求。要做什么是需求,能不能做是技术。与产品经理要确认的是需求是否合理,技术上能不能实现是技术团队要考虑的问题。

    如果需求合理,技术上难以实现,或成本太高,就把决策上升一级,由上一层领导帮忙确认,此时此刻,在现有资源约束的情况下,是不是要做这么做,同时,最好提供一个可替换的简单方案,让领导有选择。

    2019-01-08
    13
  • 虢国技匠
    打卡:
    以前我总是:不问为什么就接受来自产品经理的需求,然后暗自憋气
    这个样子,我始终不敢拒绝产品的需求,我担心领导会觉得我怠工,我担心产品会用客户来压我;
    后来我有一点点经验了,不敢拒绝 不敢怒怼,是自己没有对某个需求有深入的思考,没有足够的反驳理由和一针见血的问题。
    产品提出的需求,我们程序员一定要好好看需求,仔细想每个需求的正真解决目标问题,紧急度、优先级、验收标准等等,
    这句心里话:
    默认所有需求都不做,直到弄清楚为什么要做这件事
    得有足够底气
    2019-01-07
    9
  • 阿信
    前6讲,内容自我总结

    作者视角:程序员为主、产品经理为辅
    专栏目的:了解高效程序员如何思考的,让我们借用他们的思维方式,以提升自身的工作效率。
    前6讲,主要是对以终为始原则的介绍
    ***
    # 现状
    * 偶然复杂度太高。如选择了不合适的工具,或者框架等
    * 目标问题
        * 目标错误。拿登录为例,在需求不明确的情况下就动手了,成果不满足需求,没有价值。
        * 目标含糊 (边界不清晰)

    # 目标选择
    ## 目标的定义
    输出可执行的程序给用户使用,让客户能达到预期的目标,为他们带来价值

    ## 目标的确认
    以需求来举例,如何识别需求是不是ok的

    1. 多问几个为什么。产生这个需求的背景是什么,解决了什么问题,谁在什么场景下会来使用他。没有这个功能时,用户是怎样完成这个事情的,有没有其他方式可以达到目的。 忌讳在需求不明确的情况下动手开发
    2. 反过来做事情,或者借鉴精益创业的思想,快速试错。 得到用户的反馈,让需求渐进明细
    3. 确认边界。

    # 如何缩短到达目标的路径
    ## 减少非必要支出上的时间消耗
    以持续集成举例,能让工具做的事情不要让人做

    作者回复: 非常棒的总结!

    2019-02-26
    5
  • 雷小鸿
    对我触动最大的一句话:不管什么需求先做出来看看。殊不知,把完整的需求做出来才是最大的浪费。最后真是看看而已。
    2019-01-07
    5
  • 何处似樽前
    郑老师,经过这段时间的学习感觉收获颇丰,非常庆幸能看到这么好的分享。我是神州数码的,跟您应该是在同一个大厦,如果有机会希望能当面多请教。

    编辑回复: 赞😋

    2019-01-07
    4
  • 书生
    产品经理——别人有的我们都要有😂

    作者回复: 让产品经理先弄清别人有的到底是什么,他们为什么要有呢。

    2019-01-07
    4
  • pyhhou
    想问下老师,在寻找其他检验方案替代当前的解决方案那块,是不是得需要团队里面有些个经验较为丰富的程序员?有些情况是知道当前方案很难,但是想不到更好的其他替代方案,还有就是团队里面又没啥人可以给自己建议。。。

    作者回复: 搭配一个团队,一般是经验丰富和经验浅的人都要有,如果一个团队的经验都不足,那就和学生做项目一样,基本上是过家家的水平,掉到坑里就在所难免了。

    如果团队内部不能有足够的思考,那就去外部寻求帮助。现在有很多结交高手的机会,参加大会,参加社区活动,只要自己主动,机会总是有的。

    2019-01-07
    4
  • clairec
    郑晔老师,我想问一下,你那个认知反馈循环模型图是什么画出来的?
    想法-->产品-->数据-->想法-->产品-->数据

    编辑回复: 编辑手绘出品😅

    2019-01-07
    3
  • Jerry.hu
    产品在北京……我的小伙伴们都在上海,每一次需求移交之前 都会提前让小伙伴们reciew一遍 将所以疑惑的地方记下来,并在移交之前先做一次评审,直到pm完全能够解惑我们后 才开始移交

    作者回复: 这是一个不错的做法,事前多思考,事后少后悔。

    2019-01-25
    2
  • MarksGui
    让我最头疼的不是技术问题,而是产品经理自己都搞不清楚要怎么做。还要技术去提醒他! 不过没办法,只能按照老师说的,开发前同他一起协作完成具体需求!

    作者回复: 早头疼还是晚头疼的差别

    2019-01-08
    2
  • SA
    郑老师,精益创业用到软件开发过程中本质上是否就是原型开发模式呀?我们项目组在实现一些较大的系统架构优化时,比如引入新技术时也经常用这个思路去实现,就是先以最小的成本(最省时省力)做出一个最小化的可行产品,其实就是原型,然后快速用起来,在用的过程中持续观察,持续完善,直到最终满足客户需求,最小化可行产品是下限,刚刚满足客户需求(刚刚好)是上限。

    作者回复: 原型和MVP最大的区别在于,原型是要丢弃的,而MVP真的就是一个完整的产品,能提供完整的用户服务,后面还会进一步讨论MVP,敬请期待。

    2019-01-07
    2
  • 高立琦
    在讨论业务时,我们用精益画布,可以在《精益创业实践》中找到。

    作者回复: 很好的做法!

    2019-03-15
    1
  • helloworld
    要经过严格的分析论证后才提新需求,可悲的是,目前新需求大多数就是屁股决定脑袋

    作者回复: 先要意识到这种做法是不对的,然后再想办法改变。

    2019-02-17
    1
  • big黑钦
    这一点非常重要!好些各位前辈的经验分享!
    2019-01-21
    1
  • davidce
    在文章举的例子中,作者问产品经理的两方面问题作为产品经理不好回答,在没有先验经验的前提下连量级都很难给出,产品经理对服务开通的自动化问题的技术细节也未必了解和关心。
    作者问这些问题的目的不是要得到一个答案,而是在评估这个需求能给项目带来什么,我觉得作者的思路是这个需求对外没有大量客户被提供服务,对内不能优化流程,提高效率,推动业务运行的自动化,同时也有能用的替代方案,所以这是一个优先级不高的需求,不必马上就要做。

    作者回复: 只要多问一些问题,你会发现,很多需求都是可做可不做的,让团队聚焦到一个重要问题上,就是节省时间。

    2019-01-09
    1
  • Pray
    没有产品经理,直接面向老板。别人有的我都要,没有的容我再想想。

    作者回复: 不靠谱的经典姿态

    2019-01-07
    1
  • liu
    沟通-反馈-沟通-反馈…-确认-开发产品-运行-进入下一轮需求确认与实现
    2019-01-07
    1
  • 丁丁历险记
    读书笔记 如何干趴产品经理(玩笑)
    1 洞悉全局,利用逻辑能力优势碾压产品。
    2 让产品出数据(放心,测不准原理这里也适用,产品一预测就进坑了) 我举个例子,王煜全老师,著名风投,强大技术背景,大家以现在视角看看他几年的预测,一读完,相信大家会说,这哥们太鬼扯了。 而我想说的是,当时读的时候,我满眼看到的都是洞见。
    3 多消耗产品经理,当他能讲清时,给点甜头,做一些,讲不太清的,拖着让他讲清细节。why 有何意义,预期是啥,战略意图。 (再说点黑暗的,他说得清不清和开发的引导有很大关系。 专栏作者,用的就是常见的刁难手法。这类手法很多,换着用。一个大方向,往细节,往宏观,往预期结论上去丢(挖坑产品背锅)

    思考部分 招术是双刃剑,我在工作之时,偶尔会用刻意挖坑产品,甚至boss,来把一些不那么重要的需求优先级调低。
    但我可以负责任的讲我的初衷是希望多一些时间,把重要的事做好。太多的技术债要还了(尤其是前人的坑),而这个时间的投入很难得和他们详细的说明白。

    别做无意义的努力,(例如改变别人的世界观价值观),也是一条非常重要的效率之道。

    最后我想说的是。实力才是王道,占据技术制高点,你是可以用技术来做寻租的,你不管是想用来做好的或不好的。这个猪确实可以给你带来很大的方便。(租 这个概念有一点点复杂,建议去听薛兆丰的经济学课。)
    2019-10-31
收起评论
33
返回
顶部