17 程序员也可以“砍”需求吗？

我们前面讲的任务分解，主要是在讲开发任务的分解。今天我们换个角度，看看需求的分解。是的，需求也要分解。

有一次，我和一个做开发的同事聊天，他给我讲了他近期的烦恼。

同事：我们现在就是需求太多，开发的人太少，再这么干下去，哪天觉得自己抗不住了，我就拍拍屁股走人。

  • 我：你没尝试着砍砍需求？

  • 同事：怎么没尝试？产品的人都不同意。这批功能他们都说是关键功能。

  • 我：你有没有尝试把需求拆开了再砍呢？

  • 同事：还可以这样？

同事很惊讶，我一点都不意外。我们都是在说需求，但彼此对需求的理解却是大不相同。

我先来问个问题，提到需求这个词，你会想到什么呢？

以我们用了好多次的登录为例，如果我问你这个需求是什么，大多数人的第一直觉还是用户名密码登录。

基本上，闯入你脑海的需求描述是主题（epic），在敏捷开发中，有人称之为主用户故事（master story）。

如果你对需求的管理粒度就是主题，那好多事情就没法谈了。

比如，时间紧迫的时候，我想砍需求，你问产品经理，我不做登录行不行，你就等着被拒绝吧。

但是，如果你说时间比较紧，我能不能把登录验证码放到后面做，或是邮件地址验证的功能放到后面，这种建议产品经理是可以和你谈的。

这其中的差别就在于，后者将需求分解了。

大多数人可以理解需求是要分解的，但是，分解的程度不同，就是导致执行效果差异极大的根源。

以我的经验而言，绝大多数问题都是由于分解的粒度太大造成的，少有因为粒度太小而出问题的。

所以，需求分解的一个原则是，粒度越小越好。

需求要分解

“主题”只是帮你记住大方向，真正用来进行需求管理，还是要靠进一步分解出来的需求。

这里的讨论，我们会继续沿用前面专栏文章中已经介绍过的需求描述方式：用户故事，它将是我们这里讨论需求管理的基本单位。

如果你的团队用的是其他方式描述需求，你也可以找找是否有对应的管理方式。

上一个模块介绍“以终为始”，我们对用户故事的关注点主要在：

用户故事一定要有验收标准，以确保一个需求的完整性。

而在“任务分解”这个模块，我们看用户故事，则主要关注它作为需求分解的结果，也就是分拆出来要解决的一个个需求点。

在前面的讨论中，我们已经知道了用户故事的“长相”，但更重要的问题是，划分需求的方式有无数种，就像一块蛋糕，你可以横着切，也可以竖着切。

如果你一刀不切，那就是拿着主题当用户故事。你也可以快刀飞起，把主题切碎。

每个人都会有自己喜欢的拆分方式，我相信知道拆分的重要性之后，你总会有办法的。这里，我主要想和你聊聊怎样评判拆分结果，毕竟我们要把它当作需求管理的基本单位。

只有细分的需求才能方便进行管理。什么样的需求才是一个好的细分需求呢？我们先来看看用户故事的衡量标准。

INVEST 原则

评价用户故事有一个“ INVEST 原则”，这是六个单词的缩写，分别是：

Independent，独立的。一个用户故事应该完成一个独立的功能，尽可能不依赖于其它用户故事，因为彼此依赖的用户故事会让管理优先级、预估工作量都变得更加困难。如果真的有依赖，一种好的做法是，将依赖部分拆出来，重新调整。

Negotiable，可协商的。有事大家商量是一起工作的前提，我们无法保证所有的细节都能100%落实到用户故事里，这个时候最好的办法是大家商量。它也是满足其它评判标准的前提，就像前面提到的，一个用户故事不独立，需要分解，这也需要大家一起商量的。

Valuable，有价值的。一个用户故事都应该有其自身价值，这一项应该最容易理解，没有价值的事不做。但正如我们一直在说的那样，做任何一个事情之前，先问问价值所在。

Estimatable，可估算的。我们会利用用户故事估算的结果安排后续的工作计划。不能估算的用户故事，要么是因为有很多不确定的因素，要么是因为需求还是太大，这样的故事还没有到一个能开发的状态，还需要产品经理进一步分析。

Small，小。步子大了，不行。不能在一定时间内完成的用户故事只应该有一个结果，拆分。小的用户故事才方便调度，才好安排工作。

Testable，可测试的。不能测试谁知道你做得对不对。这个是我们在前面已经强调过的内容，也就是验收标准，你得知道怎样才算是工作完成。

“INVEST 原则”的说法是为了方便记忆，我们这里着重讨论两个点。

第一个关注点是可协商。作为实现者，我们要问问题。只是被动接受的程序员，价值就少了一半，只要你开始发问，你就会发现很多写需求的人没有想清楚的地方。

在我的职业生涯中，我无数次将需求挡了回去，不是我不合作，而是我不想做一些糊涂的需求。

我之所以能问出问题，一方面是出于常识，另一方面就是这里说的用户故事是否有价值。

用户故事，之所以是故事，就是要讲，要沟通。

还有一个更重要的关注点，也是这个模块的核心：小。无论是独立性也好，还是可估算的也罢，其前提都是小。

只有当用户故事够小了，我们后续的腾挪空间才会大。

那接下来就是一个重要的问题，怎么才算小？这就牵扯到用户故事另一个重要方面：估算。

需求的估算

估算用户故事，首先要选择一个度量标准。

度量用户故事大小的方式有很多种，有人用 T 恤大小的方式，也就是S、M、L、XL、XXL。也有人用费波纳契数列，也就是1、2、3、5、8等等。有了度量标准之后，就可以开始估算了。

我们从分解出来的用户故事挑出一个最简单的，比如，某个信息的查询。这个最简单的用户故事，其作用就是当作基准。

比如，我们采用费波纳契数列，那这个最简单的用户故事就是基准点1。其他的用户故事要与它一一比较，如果一个用户故事比它复杂，那可以按照复杂程度给个估计。

你或许会问，我怎么知道复杂程度是什么样的呢？

这时候，我们前面讲过的任务分解就派上用场了，你得在大脑中快速地做一个任务分解，想想有哪些步骤要完成，然后才好做对比。

所以，你会发现，任务分解是基础中的基础，不学会分解，工作就只能依赖于感觉，很难成为一个靠谱的程序员。

估算的结果是相对的，不是绝对精确的，我们不必像做科研一样，只要给出一个相对估算就好。

同一个用户故事，不同的人估算出的结果可能会有差别。怎么样尽可能在团队中达成一致呢？这就需要团队中的很多人参与进来，如果团队规模不大，全员参与也可以。

如果多人进行估算，你就会发现一个有趣的现象，针对同一个用户故事，不同的人估算的结果差异很大。

如果差别不大，比如，你觉得3个点，我觉得2个点，我们协调一下就好。但如果差异很大，比如，你认为2个点，我认为8个点，那绝对是双方对任务的理解出现了巨大的差异，这个时候，我们就可以把刚才在脑中进行的任务分解“摆”到桌面上，看看差异在哪。

通常情况下，是双方对需求的理解出现了偏差，这时候负责用户故事编写的同事就要站出来，帮助大家澄清需求。

所以，一般来说，估算的过程也是大家加深对需求理解的过程。

估算还有另外一个重要的作用：发现特别大的用户故事。

一般而言，一个用户故事应该在一个迭代内完成。

比如，你预计大小为1点的用户故事要用1天完成，而你团队的迭代周期是两周，也就是10个工作日，那13点的任务是无论如何都完不成的。

那该怎么办呢？很简单，把它拆分成多个小任务，这样一来，每个小任务都可以在一个迭代中完成了。

所以，一般来说，用户故事有可能经过两次拆分。一次是由负责业务需求的同事，比如，产品经理，根据业务做一次拆分。另外一次就是在估算阶段发现过大的用户故事，就再拆分一次。

当我们有了一个合适的用户故事列表，接下来，我们就可以安排我们的开发计划了。只要厘清用户故事之间的依赖关系，安排工作是每一个团队都擅长的事情。

我在这里想回到我们开头讨论的话题。我们常说，需求来自产品经理，但需求到底是什么，这是一个很宽泛的话题。到这里，我们已经有了一个更清晰更可管理的需求，用户故事。这时候我们再说需求调整，调整的就不再是一个大主题，而是一个个具体的用户故事了。

许多团队真正的困境在于，在开发过程中缺少需求分解的环节。在这种情况下，需求的管理基本单位就是一个主题，既然是基本单位，那就是一个不可分割的整体。团队就被生生绑死在一个巨大的需求上，没有回旋的余地。

如果团队可以将需求分解，需求的基本单位就会缩小，每个人看到的就不再是“铁板”一块，才能更方便地进行调整，才会有比较大的腾挪空间。

总结时刻

软件开发中，需求管理是非常重要的一环。在需求管理上常见的错误是，需求管理的粒度太大，很多团队几乎是在用一个大主题在管理需求，这就让需求调整的空间变得很小。

结合用户故事，我给你讲了一个好的需求管理基本单位是什么样子的，它要符合“INVEST原则”。

其中的一个关键点是“小”，只有小的需求才方便管理和调整。

什么样的需求才算小呢？

我给你介绍了一种需求估算的方式，每个团队都可以根据自己的特点决定在自己的团队里，多大的需求算大。大需求怎么办？只要再进行分解就好了。

如果你对用户故事这个话题感兴趣，推荐阅读 Mike Cohn 的两本书《User Stories Applied》和《Agile Estimating and Planning》。

如果今天的内容你只能记住一件事，那请记住：想要管理好需求，先把需求拆小。

18 需求管理：太多人给你安排任务，怎么办？

上一讲我们讲了需求的分解，我以用户故事为例，给你讲了我们应该把大的需求拆分成小的需求，但是不是只要把需求拆开了就万事大吉了呢？

显然不是。今天我们再来探讨另一个与需求强相关的话题：需求管理。

需求管理？

许多程序员的第一直觉通常是，这要么是产品经理的事，要么是项目经理的事，跟我有什么关系？

我知道很多人会这么想，可我想说的是，如果你不了解需求是怎么管理的，即便是进行了需求分解，最终的结果很有可能依然是你深陷泥潭苦苦挣扎而不自知。

为什么这么说呢？我给你讲一个发生在我身边的故事。

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

有一次，我们组织了一次各团队负责人的吐槽大会，让大家把遇到的问题在台面上“摆”一下。

一个开发团队的负责人说：“我这边倒排期太严重了，每个产品经理到我这里都说上线日期已经定好了，我这边资源有限，实在是抗不住了。”

出于好奇，有人问：“这些任务都一样重要吗？”

这个负责人无奈地摇摇头，“他们都说自己的任务重要。”

“他们凭什么说自己的任务重要呢？”我也问了一个问题。

这个负责人说：“他们告诉我，是老板说的。”

这是不是一个很熟悉的场景？

一堆任务压过来，只是因为这是老板的一句话。我们的老板都是这么不近人情吗？其实，大概率来看，并不是。

就凭一句“老板说的”，我们就可以判断出，产品经理缺乏对需求管理应有的理解。而研发团队也因为无脑地接受了需求，几乎将自己压垮。

这时候，CTO 发话了：“口头的东西不算数，如果他们说是老板说的，那就让老板发邮件确认。”

我很认可CTO的说法，但我并不放心那个开发团队的负责人，于是我问他：“你会让产品经理这么去做吗？”果然，他犹豫了。

“产品经理可能不会和老板这么说。那你去说好了。”我们又给他提了个建议。显然，他更犹豫了，毕竟要面对大老板。

针对这种情况，我们又给出了一个解决办法，“如果你担心产品经理不这么做，你可以直接发邮件给老板，同时抄送 CTO。”

“对，可以这么做”，CTO 把责任扛了过去。这个负责人心里一下子有底了。

是不是有种似曾相识的感觉？其实，这个故事只要再往下延伸一点，就到了我们程序员身边。

作为程序员，我们面临的场景往往是，一个需求不明就里地来了，你的周末假期全部泡汤，因为你的负责人会和你说，这是老板说的。

软件行业有个段子：做软件，最理想的交付日期是什么时候？答案是昨天，其次是尽快。所有提出业务需求的人都恨不得需求早就做好了。但事实总是那么不如人意，所以，他们只能寄希望于需求被尽快实现。

如果我们等着所有需求都开发好了再上线呢？这就是当年所谓瀑布模型做的事，放在二十年前，这种做法还有生存空间，但今天这种做法显然已经不合时宜了。

关于如何做软件，我们已经讨论了很多，关键点就在于这个世界有太多的不确定，我们只好把产品的“一部分”开发好，送上线。

这就引出了一个问题，到底是选择“哪部分”优先上线呢？我们必须在宏大的理想和骨感的现实中作出取舍。

这也就牵扯出需求管理的本质，实际上是个优先级的问题。

需求的优先级

“来自老板”，这是判断优先级最简单的答案，也是推卸责任的一个答案。其潜台词是，压力大不怪我，要怪就怪老板去。“来自老板”不应该成为优先做事的指标。

首先，我们要明确一点，优先级这种事大家也是可以谈的，大多数能当老板的人都是可以讲道理的。但要和老板谈，我们得知道怎么讲道理。

准备一些基础知识，才能与各级老板探讨怎么安排工作的优先级。

为什么要区分优先级？因为时间是有限的，有限的时间内你能完成工作的上限是一定的。

怎么充分利用好有限的时间，这其实是一个时间管理的问题。所以，我们完全可以借鉴时间管理领域的一些优秀实践，帮助我们更有效地明辨优先级。

谈到时间管理，一个有效的时间管理策略是艾森豪威尔矩阵（Eisenhower Matrix），这是由美国前总统艾森豪威尔开发出的一个工具。

这个工具到了史蒂芬·柯维（Stephen Richards Covey）手里得到了发扬光大，他那本著名的《高效能人士的七个习惯》书籍将其推广至世界各地。也许这个名字你不太熟悉，看一下下面这个图你就知道了。

优先级

  • 它将事情按照重要和紧急两个维度进行划分，也就形成了四个部分：重要且紧急，重要不紧急，不重要且紧急，不重要不紧急。

用几个程序员生活中的例子帮你理解一下。

让系统不能正常运行的线上故障，就属于重要且紧急事情，不赶紧解决，就影响公司的正常运营。 团队对系统升级改造就属于重要不紧急：改造好，性能也好，可维护性也得到提升；不改造，一时半会也能用。 一些临时任务都属于紧急不重要，而刷朋友圈则属于既不紧急也不重要。

按照时间管理的理念，重要且紧急的事情要立即做。重要但不紧急的事情应该是我们重点投入精力的地方。紧急但不重要的事情，可以委托别人做。不重要不紧急的事情，尽量少做。

这个矩阵带给我们思维上最大的改变是，让人意识到事情和事情不是等价的。

如果不把精力放在重要的事情上，到最后可能都变成紧急的事情。

比如，我们放任系统不做升级改造，过多的技术债会让系统的问题越来越多，新需求实现的速度越来越慢，最后几个看起来不大的需求就足以让团队加班加点，天怒人怨。

把这个思路带回到我们现实的需求管理中，你会发现，其实团队面临的各种需求所采用的优先级排序方式，基本上都是按照紧急程度排列的，但它们是否真的重要呢？

如果你把这个问题抛给需求的提出者，我几乎可以肯定，他们给你的答案是，他们提出的需求就是重要的。一种可能是，他们也分不清重要和紧急的差别，正如有时候我们也糊涂一样。

对于这样的场景，我们要做的就是多问一些问题。

我在“精益创业：产品经理不靠谱，你该怎么办？”文章中说过，默认所有需求都不做，直到弄清楚为什么要做这件事。

同样，需求也没那么重要，直到产品经理能说明白它为什么重要，尤其是为什么比其他需求重要。如果一个产品经理不能把几个需求排出优先级，你就可以把上面学到的内容给他讲一遍。

还有另一种可能，他给你的需求在他工作的上下文中，确实是最重要的内容了。

但当有多个需求来源时，我们该如何确认哪个需求是最重要的呢？

这时，才到了真正需要老板出场的时刻。

站在老板面前

在“解决了很多问题，为什么你依然在‘坑’里？”文章中，我曾经讲过，大家不要局限于程序员这个角色，不同角色真正的差异是工作上下文的不同。

每个人都在自己的上下文里工作，上下文也就局限了很多人的视野。

试想，两个产品经理出现在你面前，一个告诉你，公司要拓展新方向，这个功能要做；另一个却说，公司要进一步盈利，那个功能必须做。

在你看来，他们两个说得都对，听上去都挺重要的。但骨感的现实是，你把两件事都接下来，等着你的是累死都完不成的任务。

这个时候，我们能做的是什么呢？跳出这个上下文，到更大的上下文中。你判断不了哪个需求更重要，就请更高一级的老板来判断。

有了基础知识的储备，我们终于可以站在了老板面前。

你可以告诉老板：我资源有限，需要将这两个需求排个序，看哪个更重要。我的上下文有限，需要你帮我判断一下。

老板会和你说这两个需求的起源，扩展盈利的需求是竞争对手都已经有了，客户也问这边要，再不做会影响客户关系，尤其是新财年快到了，下个阶段的合同会受到影响。而另外的新业务是某天一个高端聚会上得到的新启发，想尝试一下，他也不确定这个想法能带来多少收益，就让产品部门试一下。

听了老板的信息，你顿时明白这两件事的重要性，你也知道该如何面对两个产品经理了。

老板比你们的上下文大，因为他有看待这个问题更多的维度。所以，在你们眼里无比纠结的事情，老板几句话就云开雾散了，在他眼里，那根本不叫事。

如果你看过刘慈欣的《三体》，就会知道，这其实是“降维攻击”。另一个你可能熟悉的说法叫大局观。我经常和人说，当员工想不明白的事，换成老板的视角就全明白了。

我鼓励每个程序员在更大的上下文中工作，也就是想让人获得更多的思考维度。而今天的内容主要告诉你，如果自己的上下文不足时，我们可以引入新的元素，比如征求老板意见，扩大自己的上下文。

再发散讲几句，为人做事同样要不断扩展自己的上下文，这也就是我们常说的涨见识。

很多所谓的人生难题不过是因为见识有限造成的。

比如，如果你觉得公司内总有人跟你比技术，莫不如把眼光放得长远一些，把自己放在全行业的水平上去比较。因为你是为自己的职业生涯在工作，而不是一个公司。

总结时刻

需求分解之后，最重要的是，排列需求的优先级。

优先级的排列方式有很多，我们可以借鉴时间管理的方法，把事情按照重要和紧急的维度进行划分，得到了四个象限。我们要尽可能把精力放在重要的事情上，而不是把紧急的事情当成优先级排序的方式。

需求分解成一个个小块，其实也分解了原本合一的上下文。如果想要有效地管理需求，尤其是确定事情的重要程度，一种方式是找回丢失的上下文。如果我们自己无法判断上下文，一种好的办法是，引入外部更大的上下文。

如果今天的内容你只能记住一件事，那请记住：尽量做最重要的事。

最后，我想请你分享一下，你的团队在日常的需求管理中，还遇到哪些问题呢？欢迎在留言区写下你的想法。

19 如何用最小的代价做产品？

前面我们讲了开发任务的分解和需求管理的分解，这些都是针对“已经确定好要做的事情”的分解策略，今天我们再上一个台阶，聊聊面对那些不确定的产品功能该如何分解。

产品经理的想法层出不穷，但是，如果我们一味闷着头实现产品经理的想法，无论你有多大的开发团队都是不够用的。我们要学会用最小的代价做产品。

谈到产品这个话题，在“精益创业：产品经理不靠谱，你该怎么办？”这篇文章中，我给你分享了精益创业的理念，任何的想法都要放到真实世界中检验。

我们的直觉当然是把所有的东西都实现了再去检验，但是世界不会停下来等着我们。事实也一次又一次教育我们，“憋大招”的瀑布式软件开发已经成为不合时宜的“老古董”。那我们的理想怎么实现呢？唯有分解。

我们前面提到，精益创业就是通过不断地尝试在真实世界中验证产品想法，其中一个重要的实践是最小可行产品（Minimum Viable Product，MVP），我们这次就把这个实践展开讨论一下。

什么叫最小可行产品？

就是“刚刚好”满足客户需求的产品。客户需求好理解，怎么算“刚刚好”呢？其中的关键在于理解“最小”和“可行”。

最小的代价

先说“最小”。这里的“最小”，指的是最小的代价。

怎么叫最小的代价，就是能不做的事情就不做，能简化的事情就简化。

首先，我们必须清楚一件事，我们要做的是验证一个想法的可行性，甚至不是为了开发一个软件，开发软件只是一种验证手段。

很多程序员都会有一个认识上的误区，容易把解决方案当成问题。我们开发软件的目的是为了解决问题，如果不写软件就把问题解决了，岂不是更好。

我先讲一个自己的经历，帮你理解一下什么叫“最小”。

有一次，有一个朋友找我帮忙，他手头有一些制造业的客户，想做一个物联网相关的项目，帮助这些客户改造设备，实现物联网功能。

该怎么着手呢？把软件写好，给客户试用吗？这样时间太长，成本太高。那么，我们是怎么做的呢？

第一步，我们要验证这样一个想法是否可行。我们做了一个产品文档，就好像我们已经有了这个产品一样，让负责销售的同事拿着这个文档给客户讲讲，看看客户对这个想法的反映。

在这个过程中，我们验证了基本的想法，已有设备进行物联网化改造的需求存在，客户看到了这样的一个东西，各种各样的想法和要求就会冒出来。

此外，我们还获得了一个额外的收获，我们知道了客户对于这样一个产品能够接受的价格区间，这可以帮助团队给产品进行适当的定价。

验证了方向上的想法，我们开始进入到具体的产品设计阶段。这个阶段我们想验证的是，我们给出的产品设计用户是否可以接受。于是，我们决定把这个产品的交互做出来。

得益于原型工具的快速发展，我们用一个原型工具做出了相对完整的用户界面，而且把各种交互流都做出来了。

在用户看来，这几乎就是完整的软件了。

他们甚至可以在自己的设备上体验一下这个产品用起来是什么感觉的。一旦上手用起来，他们就会抛出各种细节的问题：如果这样就好了，如果能做到这个就太棒了。当然，他们也会说，这个东西我不需要。

这个时候，我们就可以知道，我们在产品上的假设哪些是好的，哪些是不流畅的。团队拿到这些反馈，就可以再调整产品设计，然后，再给到用户去测试，如此反复进行。有的时候，产品会在一天之内改好几个版本。

PS: 墨刀？？？draw.io

经过多轮测试下来，团队有了一大堆的用户反馈，而且是来自真实用户的反馈。

接下来，就是整理这些用户反馈，决定哪些可以真正的开发出来，这时候，团队才真正进入到开发阶段。

不知道你注意到了没有，迄今为止，这个团队验证了一大堆的想法，而代码却是一行都没有写，所有花费的工作量都是有针对性的验证。

我们经常听到一个段子，叫“就差一个程序员了”。这说的是，一个创业者把前期的准备都做好，就差程序员把产品开发出来了。

按照 MVP 的思想，这个创业者做的就是对的，前提是他真的把前期准备都做好了。

开发软件是一件成本很高的事情。

如果只是验证想法，无论是创业方向，还是产品设计，我们可以找到各种各样的手段，不用写代码。

即便我们不是在做一个新产品，我们依然可以运用这个“最小代价”的理念在日常工作中做事。

比如，怎么来衡量产品经理的产品设计是不是好的。我会问，这个功能不做，用户会怎么样？

有没有什么替代方案等等。以此来帮助产品经理想清楚自己的产品设计是否真的有价值。

可行的路径

说完了”最小”，我们再来看”可行”。

可行是要找到一条路径，给用户一个完整的体验。

做程序员出身的人，对软件系统的认识总是一个模块一个模块的，相对比较弱的方面是缺少一个完整的图景。

但从产品可行的角度，我们需要转换一下思路，不是一个模块做得有多完整，而一条用户路径是否通畅。

我再给你分享一个我当年做 P2P 项目经历，这里的 P2P 指的是个人对个人的互联网借贷平台。

这是一个从头开始的项目，项目方和所有的项目方一样，希望昨天这个项目就上线了，如果不能，那就尽快上线一个版本。他们给我们一个时间线，第一个上线的版本是一个月之后。

摆在我们面前的问题是，无论如何，在一个“一穷二白”的基础上，要在一个月内完成一个完整的借贷平台是不太可能的。

时间有限，我们只能做最基本的东西，许多运营上的想法，比如，发红包代金券之类的，第一期一律不做。即便如此，我们仍然认为完成完整的借贷循环是不现实的。

于是，我们就开始从需求完整性的角度动脑筋。

这是一个借贷系统，其最基本的模型是：贷款方贷款之后，一次性拿到所有的钱，然后用等额本息的方式每个月还款，最后一个月剩多少钱一次性全还了。

我们在这个模型中找到了一个关键点，每个月还款。

换句话说，第一笔贷款发生之后，最早的一笔还款是发生在一个月之后的。

于是，我们做了一个决定，第一个版本只包含贷款能力。

是的，这个版本只能贷款，不能还款。

因为用户一个月之内不会用到这个功能，你从页面上，完全看不出这样的能力缺失，因为一个月内，根本没有任何用户有可还的款项。

因为缩减了项目规模，我们在预期的一个月内完成所有开发，成功地把项目送上了线。第一批早期用户就开始了使用。从用户的视角看，这是一个功能完整的项目，虽然简单了点，但它是完整的。

当然，我们把还款排到了下一期。按照我们两周一迭代的节奏，在第一期上线两周之后，我们就会上线还款功能，届时贷款方将拥有一个真正的还款功能。

不过，这个还款功能只是每期的等额本息还款，最后的一次性还剩余所有贷款的功能，我们依然是不支持的。因为根据需求设计，最后一次还款最早发生在一年之后。

在我们把基本的功能全部送上线之后，这个系统就是一个真正的、完整的借贷平台了。但是，相对于其他提供相同能力的平台而言，这个系统依然还是很简单。比如，常见的运营功能、短期借贷计划，这个平台都没有。

但我们有了基础，接下来，就是在基础上叠加，而且随着项目方自己团队的构建，我们拥有了够大的团队，可以同时做几个大需求了。

就这样，几个月之后，我们就逐步上线了一个功能相对完整的P2P平台。在这个过程中，我们每个阶段都会上线新功能，从用户可见的角度，他看到的始终是一个完整的平台，其中的变化只有站在内部实现者的角度才能看得清楚。

和大家分享这个例子，主要是想破除大家对于一个“完整”系统概念的认识。

当时间有限时，我们需要学会找到一条可行的路径，在完整用户体验和完整系统之间，找到一个平衡。

站在开发团队的角度，我们怎样把 MVP 理念运用在自己的工作中呢？

当产品经理有一大堆要实现的功能时，我们就可以根据 MVP 理念，从这些产品功能中找出一条最小的可行路径，重新安排一个合理的开发计划。

总结时刻

产品同样需要分解，目前在探索产品的不确定性上的最佳实践是精益创业，而精益创业就包含了将庞大的产品分而治之的方式：最小可行产品（Minimum Viable Product，MVP）。

最小可行产品就是“刚刚好”满足客户需求的产品。

想要在实践中运用好最小可行产品的理念，就是要用最小的代价找到一条可行的路径。

最小的代价就是能不做的事就不做，能简化的事情就简化。

程序员通常愿意用自己的代码解决问题，而写代码通常是代价非常高的解决方案，它应该成为最后的产品解决方案。

可行的路径，是一条完整的用户体验路径，至少在用户眼中是这样的。我们常常会想给客户一个完整的系统，但在时间有限的情况下，我们必须学会分解。

如果今天的内容你只能记住一件事，那请记住：做好产品开发，最可行的方式是采用 MVP。

最后，我想请你分享一下，你遇到或听说过采用 MVP 或类似方法解决问题的案例吗？欢迎在留言区写下你的想法。

参考资料

http://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/10x%e7%a8%8b%e5%ba%8f%e5%91%98%e5%b7%a5%e4%bd%9c%e6%b3%95/17%20%e7%a8%8b%e5%ba%8f%e5%91%98%e4%b9%9f%e5%8f%af%e4%bb%a5%e2%80%9c%e7%a0%8d%e2%80%9d%e9%9c%80%e6%b1%82%e5%90%97%ef%bc%9f.md