19 | 如何用最小的代价做产品？
郑晔
该思维导图由 AI 生成，仅供参考
你好，我是郑晔。
前面我们讲了开发任务的分解和需求管理的分解，这些都是针对“已经确定好要做的事情”的分解策略，今天我们再上一个台阶，聊聊面对那些不确定的产品功能该如何分解。
产品经理的想法层出不穷，但是，如果我们一味闷着头实现产品经理的想法，无论你有多大的开发团队都是不够用的。我们要学会用最小的代价做产品。
我们的直觉当然是把所有的东西都实现了再去检验，但是世界不会停下来等着我们。事实也一次又一次教育我们，“憋大招”的瀑布式软件开发已经成为不合时宜的“老古董”。那我们的理想怎么实现呢？唯有分解。
我们前面提到，精益创业就是通过不断地尝试在真实世界中验证产品想法，其中一个重要的实践是最小可行产品（Minimum Viable Product，MVP），我们这次就把这个实践展开讨论一下。
什么叫最小可行产品？就是“刚刚好”满足客户需求的产品。客户需求好理解，怎么算“刚刚好”呢？其中的关键在于理解“最小”和“可行”。
最小的代价
先说“最小”。这里的“最小”，指的是最小的代价。怎么叫最小的代价，就是能不做的事情就不做，能简化的事情就简化。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了如何用最小的代价做产品，强调了精益创业的理念，通过最小可行产品（MVP）的实践来验证产品想法的可行性。作者分享了在产品开发过程中，要注重用最小的代价来验证产品想法的可行性，而不是一味地追求完美的解决方案。他强调了“最小”的含义是指最小的代价，即能不做的事情就不做，能简化的事情就简化。通过一个物联网项目的经历，阐述了如何在产品开发之前，先验证想法的可行性，而不是一味地开发软件。作者提出了通过验证基本想法和产品设计，不断调整产品设计并进行用户测试的方法，来逐步完善产品。最后，他指出即便不是在做新产品，也可以运用“最小代价”的理念在日常工作中做事。文章强调了在产品开发过程中，要注重用最小的代价来验证产品想法的可行性，而不是一味地追求完美的解决方案。这种精益的方法可以帮助团队在产品开发过程中更加高效地进行验证和完善，从而降低成本，提高效率。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《10x 程序员工作法》，新⼈⾸单¥68
《10x 程序员工作法》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(26)
- 最新
- 精选
西西弗与卡夫卡补充一个和MVP有关的话题。前阵子有个关于产品技术的段子，讲的是技术问产品，开发某个功能预计会有多少人用；而产品说，不上线不知道会有多少人用。其实产品要有一种意识，即开发程序是代价高昂的解决方案，特别是开发某个不确定的特性。所以他需要花许多力气琢磨，找出方案的关键点，构建MVP去验证，而不是先做一个完整的产品方案让开发去完成。虽然这会导致产品经理多做很多工作，但对于团队来说整体代价反而是小的。更进一步说，产品经理的职责本来就是找到最经济有效的解决方案，而不是画一个原型让开发去完成作者回复: 糊涂的产品经理到处都是，程序员不反抗，他们就意识不到自己的糊涂。
2019-02-11433
行与修这篇可以说是精益创业的姊妹篇，现在在做的项目也基本是按照MVP的思路来做的，只是任务分解方面还不够细，有点贪全～～ 总的来说，小步快跑。先弄清客户想要什么，整理后再用自己的语言复述一遍，后面拿着原型+业务交互给客户确认，同时把自己的设计理念植入进去和客户探讨，有些点对方之前也没有想清楚，尤其是实现方面需要专业的软件意见去参考，而我们再从探讨中更新自己的认知，如此往复几次，大方向上就不会有偏差，后面在实施过程中再局部调整。个人认为尤其是对于不确定性很高或者从零开始的工作，这是个可操作的方式，也希望能从大家的分享中获得灵感！作者回复: 你理解了！
2019-02-11431
Ryoma之前做了一个类似TodoList的项目，有个功能是“历史任务”。 当时由于时间紧急，与产品经理商量，在第一版上线时，其实并没有上线“历史任务”这个功能——因为历史任务的定义是一个月之前的任务。 在接下来的版本中再实现“历史任务”这个功能，与老师处理问题的思路如出一辙。作者回复: 多谢分享！
2019-02-1721
丁丁历险记如果全篇就记住一句话。那么就是开发的成本很高很高，不要烂用。作者回复: 你的一句话 :)
2019-11-12314
王维以前做过一个政府部门的绩效考核项目，客户交来一叠厚厚的需求，然后我们就埋头“研究”需求，既没有分解需求，也没有识别出核心需求，项目一开始，开发人员天天打酱油，只有两位项目经理忙得不亦乐乎，结果他们做出了两个不同版本的开发需求。过了一两个月，公司要做需求评审，结果我们匆匆做出了一个所谓的原型才敷衍过去。接下来就开始做开发，好不容易项目做完了，在后期客户又提出要加上工作流审批的需求，结果我们又是一顿好忙。 所以学习了这篇文章，觉得需求一定一定要分解，要识别出核心需求，一定要在MVP的基础上不断重构，直到满足客户需求。作者回复: 唉，多做了多少不需要的需求啊。
2020-03-186
Crypto营长文章说，得益于原型工具的快速发展，我们用一个原型工具做出了相对完整的... 这样的原形工具是指什么啊？有推荐的吗作者回复: 举个例子，墨刀。
2019-10-1425- geoxs公司比较老，并且是to b的那种，目前对于新项目主要还是瀑布式的开发一个基线，后续再迭代。看了本文受益匪浅。不过有一个问题：像文中举的p2p的例子，这样开发会不会风险太大?利益与风险的权衡是由老板做决定吗？谢谢
作者回复: 好问题，当时老板给的要求是尽快上线，这是我们找到的一条通往目标的路径，而且我们给出了一个合理的推理，老板并不反对。 所谓风险是不确定的，当你看到一个几乎是确定的路径，你就不会那么担心了。很多团队是用胆子大来做事，这才是风险很大的。
2019-02-125 - Stephen当时做敏捷开发去开发产品就是前期做一个最小可交付版本，后面的逐步增加功能。
作者回复: 这种做法没问题
2020-12-264 
一个帅哥最小指的是能不加的功能就坚决不加。可行指的是刚好可以用作者回复: 很好的总结！
2020-06-163
Jerry Wu看完“任务分解”模块，发现我们公司还在“憋大招”的时代，太容易出问题了。 有一次，我改进一个项目，分几次提交代码，每次都和他说，XX功能做好了，正式环境先上线。这样即使出事，也是小问题，对客户的影响不大。老板每次都回复了个：1。 到了周末，我微信狂弹消息，说系统不行啦，客户很生气，后果很严重之类的。最后，我发现，他大招没放好，一次性上线了好几个版本的代码，但忘记执行一个SQL文件~~ 我心中一万只羊驼奔腾而过。。。作者回复: 大招伤敌一千，但更可能是自损八百，甚至一千二。
2020-04-2222
收起评论
