精华内容
下载资源
问答
  • 几年前,我画了这张照片并开始在关于敏捷...许多人告诉我,绘图确实抓住了迭代和增量开发,精益创业,MVP(最小可行产品)以及不是什么的本质。然而,有些人误解了它,当你从它的原始背景中拍出照片时这是很自然的。...

    几年前,我画了这张照片并开始在关于敏捷和精益开发的各种演示中使用它:

    从那时起,绘画已经病毒化!在文章和演示文稿中,甚至在一本书中都可以显示出来(Jeff Patton的“ 用户故事映射 ” - 顺便说一句,这是一本非常好的读物)。许多人告诉我,绘图确实抓住了迭代和增量开发,精益创业,MVP(最小可行产品)以及不是什么的本质。然而,有些人误解了它,当你从它的原始背景中拍出照片时这是很自然的。有人批评它过于简单化,这是事实。图片是一个比喻。它不是关于实际的汽车开发,而是关于产品开发,使用汽车作为隐喻。

    无论如何,有了这些嗡嗡声,我认为是时候解释它背后的想法了。

     

    第一个例子 - 不喜欢这个

    第一行说明了关于迭代,增量产品开发(又称敏捷)的常见误解。

    许多项目都失败了,因为他们做Big Bang交付(直到100%完成并最终交付)。由于这个原因,我已经失去了我见过的失败项目的数量(向下滚动一些例子)。然而,当敏捷被作为替代品出现时,人们有时会不愿意提供未完成的产品 - 谁想要一半  的汽车?想象一下:

    “先生,这是我们的第一次迭代,前轮胎。你怎么看?”

    顾客就像“你为什么要给我送轮胎?我点了一辆车!我该怎么办呢?“

    (顺便说一句,我在这里使用术语“客户”作为通用术语来表示产品经理,产品所有者和早期采用者用户)。

    随着每次交付,产品接近完成,但客户仍然生气,因为他实际上无法使用该产品。它仍然只是一部分汽车。

    最后,当产品完成后,客户就像“谢谢!最后!你为什么不首先提供这个,并跳过所有其他无用的交付?“

    在这个例子中,他对最终产品感到满意,因为这是他订购的产品。实际上,这通常不是真的。在没有任何实际用户测试的情况下,很多时间已经过去,因此基于对人们需要的错误假设,产品很可能充满设计缺陷。因此,最后的笑脸非常理想化。

    无论如何,第一行代表“卑鄙的敏捷”。从技术上讲,它可能是增量和迭代交付,但缺乏实际的反馈循环使其风险很大 - 而且绝对不敏捷。

    因此,“不喜欢这个”标题。

    第二个例子 - 像这样!

    现在是第二排。

    这里我们采取一种非常不同的方法。我们从相同的背景开始 - 客户订购了一辆汽车。但这次我们不只是制造一辆汽车。相反,我们专注于客户想要实现的基本需求。事实证明,他的潜在需求是“我需要更快地从A到B”,而Car只是一种可能的解决方案。记住,汽车只是一个比喻,想想任何一种定制的产品开发情况。

    因此,团队提供他们能想到的最小的东西,让客户测试事物并给我们反馈。有些人可能称之为MVP(最小可行产品),但我更喜欢将其称为最早的可测试产品(更多关于此问题)。

    称之为你喜欢的东西(有些人甚至称他们的第一个版本是产品的“滑板版”,基于这个比喻.......)。

    客户不太可能对此感到满意。这远不及他订购的汽车。但那没关系!这是踢球者 - 我们现在并没有试图让客户满意。我们可能会让一些早期采用者感到高兴(或者是痛苦的实用主义者),但我们在这一点上的主要目标只是学习。理想情况下,团队会提前向客户清楚地解释这一点,所以他不会太失望。

    然而,与第一种情况下的前轮相反,滑板实际上是一种可用的产品,可以帮助客户从A到B.但不是很好,但比没有任何东西好一点。所以我们告诉客户“不要担心,项目没有完成,这只是许多迭代中的第一个。我们仍然打算建造一辆汽车,但在此期间请尝试这个并给我们反馈 “。想想大,但以功能上可行的增量递送。

    我们可能会学到一些令人惊讶的事情。假设顾客说他讨厌滑板,我们问为什么,他说“我讨厌这种颜色”。我们就像“呃...... 颜色?就这样?”。客户说:“是的,把它弄成蓝色!除此之外,没关系!“ 你刚刚节省了*很多没有建造汽车的钱!不太可能,但谁知道呢?

    关键问题是“ 我们可以开始学习的最便宜和最快的方式什么?“我们能提供比滑板更早的东西吗?公交车票怎么样?

    这有助于解决客户的问题吗?也许,也许不是,但我们肯定会通过把它交到真实用户手中来学到一些东西。精益创业提供了一个很好的模型,基于列出您对用户的实际假设,然后系统地工作以验证或使它们无效。

    您不需要在所有用户上测试产品,也不需要构建产品来测试某些东西。甚至在单个用户上测试原型也会教会你什么。

    但好的,回到滑板的例子。

    在办公室里玩弄它后,客户说:“好,很有趣,它确实让我更快地进入咖啡机。但它不稳定。我太容易掉下来“。

    因此,下一次迭代我们会尝试解决这个问题,或者至少了解一下这个问题。

    客户现在可以绕过办公室而不会掉下来!

    快乐?不是真的,他仍然想要那辆车。但与此同时他实际上正在使用这个产品,并给我们反馈。他最大的抱怨是,由于车轮小而且没有休息,很难长途跋涉,比如建筑物之间。因此,下一次发布时,产品会像自行车一样变形。

    现在,客户可以放大校园。Yiihaaa!

    我们沿途学到了一些东西:顾客喜欢脸上清新的空气。客户在校园内,交通主要是在建筑物之间绕行。

    自行车可能比最初设想的汽车要好得多。事实上,在测试这款产品的过程中,我们可能会发现道路对于汽车来说太窄了。我们只是节省了大量的时间和金钱,并在更短的时间内给了他更好的产品!

    现在你可能在想“但我们不应该已经知道了。” 通过对客户背景和需求的前期分析?“好点。但是在我见过的大多数现实生活中的产品开发场景中,无论您做了多少前期分析,当您将第一个真正版本交给真实用户并且您的许多假设时,您仍会感到惊讶结果是离开了。

    所以,是的,做一些前期分析,在开始开发之前尽可能多地发现。但是不要花太多时间在它上面并且不要过多地信任分析 - 开始原型设计和发布,而是真正的学习发生的时候。

    无论如何,回到故事。也许客户想要更多。有时他需要前往另一个城市,骑自行车太慢而且出汗。所以下一次迭代我们添加一个引擎。

     

    这种模型特别适用于软件,因为软件很好。您可以随意“变形”产品,而不是每次都必须重建的硬件。但是,即使在硬件项目中,提供原型以观察和了解客户如何使用您的产品也会带来巨大的好处。只是迭代往往会更长(几个月而不是几周)。即使像丰田和特斯拉这样的实际汽车公司在开发新车型之前也做了大量的原型设计(草图,3D模型,全尺寸粘土模型等)。

    那么现在怎么办?也许,客户对摩托车很满意。我们可以比计划更早结束项目。大多数产品都充斥着无人使用的复杂性和功能。迭代方法实际上是一种减少交付的方法,或者找到解决客户问题的最简单,最便宜的方法。尽量减少与Awesome的距离。很禅。

    或者,客户可以选择继续,无论是否修改要求。事实上,我们最终可能会得到与最初设想的完全相同的汽车。然而,我们更有可能在此过程中获得重要的见解,并最终得到一些略有不同的东西。像这样:

    客户喜出望外!为什么?因为我们沿途了解到他欣赏脸上的新鲜空气,所以我们最终得到了一辆敞篷车。毕竟他确实得到了一辆车 - 但是比原计划的车更好!

    让我们退一步吧。

    你的滑板是什么?

    最重要的情况(提供前轮胎)很糟糕,因为我们不断提供客户根本无法使用的东西。如果你知道自己在做什么 - 你的产品很少有复杂性和风险,也许你之前已经建造了数百次这样的东西 - 然后继续前进,只做大爆炸。构建完成并在完成后交付它。

    然而,我所看到的大多数产品开发工作都过于复杂且风险太大,而大爆炸方法往往导致巨大的昂贵故障。所以关键问题是你的滑板是  什么?

    在产品开发中,您应该做的第一件事(在描述您要为谁解决的问题之后)就是识别您的滑板等效物。把滑板想象成你可以放在真实用户手中的最小东西的隐喻,并获得真实的反馈。如果这个比喻效果更好,可以使用“公交车票”。

    这将为您提供急需的反馈循环,并为您和客户提供对项目的控制 - 您可以学习和进行更改,而不是仅仅遵循计划并希望获得最佳。

    让我们来看一些现实生活中的例子。

    示例1:Spotify音乐播放器

    “拥有超过7500万用户,很难记住没有Spotify的时间。但是有。我们都在为新CD考虑Target的过道。在我们生活中的一段时间里,我们都成了Napster的小偷。iTunes强迫我们以2美元/片的价格购买歌曲。然后是Spotify。“ - Tech Crunch

    Spotify现在是一款非常精美的产品。但它没有那样开始。我很幸运能够在这个惊人的旅程中很早就参与进来(现在还是)。

    作为2006年的创业公司,Spotify建立在一些关键假设的基础上 - 人们乐于流式传输(而不是拥有)音乐,标签和艺术家愿意让人们合法地这样做,而且快速稳定的流媒体在技术上是可行的。请记住,这是2006年音乐流媒体(如Real Player)非常可怕的体验,而海盗复制的音乐几乎是常态。挑战的技术部分是:“当你点击播放按钮时,甚至可以让客户端立即播放音乐?是否有可能摆脱那个讨厌的'缓冲'进度条?“

    从小开始并不意味着你不能想大。这是他们想到的早期草图之一:

    但是,与其花费数年时间构建整个产品,然后查明假设是否成立,开发人员基本上坐下来,破解技术原型,放入他们在笔记本电脑上的任何翻录音乐,并开始疯狂地尝试寻找方法使播放快速稳定。驱动指标是“从播放Play到听到音乐时需要多少毫秒?”。它应该立即发挥,并继续顺利播放,没有任何口吃!

    “当没有人关心时,我们花了很多时间专注于延迟,因为我们一心想让你觉得你的硬盘驱动器上有全世界的音乐。对小细节的迷恋有时会产生重大影响。这就是我认为对最小可行产品概念的最大误解。这就是MVP中的V.“ -Daniel Ek,联合创始人兼首席执行官

    一旦他们有了一些体面的东西,他们就开始测试自己,他们的家人和朋友。

    初始版本无法向更广泛的受众发布,它完全没有被删除,除了能够找到和播放一些硬编码的歌曲之外基本上没有任何功能,并且没有法律协议或经济模式。这是他们的滑板。

    但他们无耻地将滑板交给了真正的用户 - 朋友和家人 - 他们很快得到了他们需要的答案。是的,这在技术上是可行的。是的,人们非常喜欢这种产品(或更像是产品可以成为什么样的产品)!该假说进行了验证!这个运行原型帮助说服音乐品牌和投资者,其余的是历史。

    例2:我的世界

    Minecraft是游戏开发史上最成功的游戏之一,特别是考虑到开发成本。“我的世界”也是发布的最极端的例子之一 - 早期和经常的心态。第一次公开发布是在经过6天的编码后,由一个人制作的!你在第一个版本中做不了多少 - 它基本上是一个丑陋的块状三维景观,你可以挖掘块并将它们放置在其他地方以构建原始结构。

    那是滑板。

    虽然用户超级参与(大多数开发者 - 用户通过Twitter发生,非常有趣)。早期用户中有我和我的四个孩子。  第一年就发布一百多个版本。游戏开发就是为了找到乐趣(我曾经使用的一些游戏公司使用“乐趣的定义”而不是“完成的定义”),最好的方法是让真实的人真正玩这个游戏 - 在这种情况下,成千上万真正付钱尝试早期访问版本的人,因此有个人激励来帮助改进游戏。

    渐渐地,围绕游戏形成了一个小型开发团队(实际上大多是2个人),这个游戏在全世界都成了热门话题。我不认为我在任何不玩Minecraft的地方遇到过任何孩子。去年,游戏(以及围绕游戏形成的公司)以25亿美元的价格卖给了微软。太棒了。

    例3:大政府项目

    2010年左右,瑞典警方启动了一项重大举措,使警方能够在现场花费更多时间,减少在车站的时间--PUST(PolisensUtredningsSTöd)。这是一个引人入胜的项目,我作为教练参与其中,写了一本关于我们做了什么以及我们学到了什么的书(来自战壕的精益)。

     

    其想法是将笔记本电脑放入汽车,并通过定制软件让警察实时访问他们所需的系统,例如在询问嫌疑人时(这是片剂前期)。

    他们过去曾试图建立类似的系统并且惨遭失败,这主要是因为大爆炸的想法。他们告诉我,他们之前的一次尝试从开始到首次发布需要7年时间。7年!到那时,一切都发生了变化,项目完全失败了。所以这次他们想要以不同的方式做到这一点。

    这个60人的项目(后来被称为“PUST Java”)取得了令人惊讶的成功,尤其是作为一个大型政府项目(它甚至在CIO奖项“ 年度最佳项目 ”中排名第二)。其中一个主要的成功因素是他们没有尝试同时建造整个东西 - 他们将大象分成两个方面:

    • 按地区划分。我们不需要立即向瑞典所有国家发布,我们可以从发布到一个地区开始。
    • 按犯罪类型。我们最初不需要支持所有犯罪类型,我们可以从支持1-2种犯罪类型开始。

     

    第一个版本1.0是他们的滑板。

    这是一个小型系统,只支持几种犯罪类型,并且在Östergötland(瑞典一个地区)的少数警察进行了实地测试。其他犯罪类型必须以旧方式处理 - 开车到车站并做文书工作。他们知道他们是豚鼠,并且产品远未完成。但他们很乐意测试它,因为他们知道替代方案。他们已经看到了什么样的糟糕系统来自缺乏早期用户反馈的流程,现在他们  终于有机会在系统构建时影响系统

    他们的反馈是严厉和诚实的。我们的许多假设都飞离窗外,其中一个困境就是如何处理所有精心设计的用例规范,这些规范随着真实的用户反馈而变得越来越不相关(这是一个拥有瀑布历史的组织)和做大前期分析的习惯)。

    无论如何,长话短说,早期的反馈被引导到产品改进中,逐渐地,随着Östergötland的那些警察开始喜欢产品,我们可以添加更多的犯罪类型并将其传播到更多地区。当我们进入大发布(1.4)时,在全国范围内推出并培训了12000名警察,我们并不那么担心。我们做了这么多的发布,如此多的用户测试,我们在全国发布之夜睡得很好。

    不幸的是,胜利是短暂的。后续项目(PUST Siebel)对它进行了拙劣的研究并回到了瀑布式的思考,这可能是由于旧习惯造成的。在没有任何发布或用户测试的情况下进行了2年的分析和测试,随后向所有12,000名警察同时发布了“下一代”产品。这是一场绝对的灾难,经过半年的出血,他们把整个事情关闭了。开发成本约为2000万欧元,但内部研究估计瑞典社会的成本(因为警察被可怕的系统所困扰)大约10亿欧元

    相当昂贵的学习方式!

    例4:乐高

    我目前正在Lego工作,我很惊讶他们年复一年地提供新的粉碎技能的能力。我听到很多关于他们如何做到这一点的有趣故事,共同的主题是原型设计和早期用户测试!我经常在办公室看到一群孩子,设计师与当地的幼儿园,学校和家庭合作,对最新的产品创意进行现场测试。

    这是最近的一个例子 - Nexo Knights(2016年1月发布):

    当他们第一次开始探索这个概念时,他们做了纸质原型并带给了小孩子。孩子们的第一反应是“嘿,谁是坏人?我看不出谁是好人,谁不好!“ 哎呀。因此,设计师不断进行迭代和测试,直到找到适合孩子的设计。我敢打赌,即使你可以看到上图中谁是好人,谁是邪恶者......

    不确定滑板在这个故事的确切位置,但你明白了 - 来自真实用户的早期反馈!不要只是设计产品并构建整个产品。想象一下,如果他们根据他们最初的设计假设构建了产品,并 在向世界各地的商店提供数千个盒子之后了解了这个问题!

    乐高也有一些来之不易的失败。一个例子是  乐高宇宙,一个大型多人在线乐高世界。听起来很有趣吧?问题是,他们过于雄心勃勃,最终试图在向世界释放之前将整个事物构建完美。

    大约250人工作了4 - 5年(由于完美主义导致范围不断变化),当发布终于到来时,接待是......不冷不热。完成的游戏很漂亮,但没有预期的那么有趣,因此产品在2年后关闭。

    没有滑板!

    为什么不?因为滑板不是很棒(至少不是你想要一辆车),乐高的文化就是提供令人敬畏的体验!如果你在丹麦比隆的乐高总部工作,你每天都会走过这幅巨大的壁画:

    大致翻译为“只有最好的就足够了”。自公司成立80多年以来,它一直是乐高的指导原则,并帮助他们成为世界上最成功的公司之一。但在这种情况下,原则被误用了。 完美狩猎延迟重要的反馈意见,这意味着什么等,并且用户不喜欢错误的假设。与Minecraft完全相反。

    有趣的是,Lego Universe团队实际上正在使用Scrum并进行大量迭代 - 就像Minecraft的人一样。但这些版本只是内部版本。所以很可能是滑板,自行车等,但这些产品从未达到过真正的用户。这不是Scrum的用途。

    这是一个昂贵的失败,但乐高从中吸取了教训,他们在早期测试和用户反馈方面不断变得更好。

    改善“MVP”

    而那(深呼吸......)让我想到了MVP的主题 - 最小可行产品。

    潜在的想法是伟大的,但这个术语本身会引起很多混乱和焦虑。我遇到过许多客户,他们就像“我不想要MVP交付 - 这是我最后一次交付!”团队经常会提供所谓的最小可行产品,然后很快就会被送到下一个项目,让客户留下一辆未完成的未完成产品。对于一些客户,MVP = MRC(最小可释放垃圾)。

    我知道,我知道,这归结于管理不善而不是MVP这个词,但仍然......这个词会引起误解。“最小”和“可行”对不同的人意味着不同的东西,这会导致问题。

    所以这是另一种选择。

    首先,将“Minimum”替换为“Early”。发布MVP背后的整个想法是获得早期反馈 - 通过提供最低限度的产品而不是完整的产品,我们可以更早地获得反馈。

    很少有客户想要“最低限度”,但大多数客户都想要“早”!这是我们的第一个改变:

    最小=>最早

    接下来,删除“Viable”这个词,因为它太模糊了。你的“可行”是我的“可怕”。有些人认为Viable意味着“我可以测试并获得反馈的东西”,其他人认为它意味着“客户可以实际使用的东西”。所以让我们更明确一点,把它分成三个不同的东西:

     

     

    最早的可测试产品  是滑板或公交车票 - 客户可以实际使用第一个版本。可能无法解决他们的问题,但它至少会产生某种反馈。我们非常清楚地表明,学习是本次发布的主要目的,任何实际的客户价值都将是奖励。

     

    最早的可用产品  也许就是自行车。早期采用者实际使用第一个版本,心甘情愿。它还远没有完成,它可能不太可爱。但它确实让您的客户处于比以前更好的位置。

     

    最早的可爱产品  也许就是摩托车。客户喜欢第一个版本,告诉他们的朋友,并愿意付钱。还有很多需要改进的地方,我们最终可能会使用敞篷车,飞机或其他东西。但是我们已经达到了一个真正有市场的产品。

    我考虑过添加一个更早的步骤“ 最早的可反馈产品 ”,它基本上是用于从客户那里获得第一反馈的纸质原型或等效产品。但是四个步骤看起来太多了,反馈这个词......呃。但尽管如此,这也是重要的一步。有些人会将纸质原型称为最早的可测试产品,但我想这取决于您如何定义Testable。查看Martin的MVP指南以了解更多信息 - 他有很多超级具体的例子,说明如何以最少的投资获得早期反馈。

    当然,人们仍然会误解最早的可测试/可用/可爱,但它至少比模糊的最小可行产品更明确一步。

    外卖点

    好的时候把它包起来。从来没有想过会这么久,感谢你坚持下去!关键要点:

    • 避免Big Bang  交付复杂,创新的产品开发。迭代地和递增地做它。你已经知道了。但你真的在做吗?
    • 首先要确定你的滑板  - 最早的可测试产品。瞄准云,但吞下你的骄傲,开始提供滑板。
    • 避免使用术语MVP。更明确你实际谈论的内容。最早的可测试/可用/可爱只是一个例子,使用对您的利益相关者来说最不容易的任何条款。

    请记住 - 滑板/汽车绘图只是一个比喻。不要太字面意思:o)

    PS - 这是一个有趣的故事,关于我的孩子和我如何使用这些原则来赢得机器人相扑比赛  :o)

     

    原文链接:https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp

    展开全文
  • MVP是最小可行产品,MMF是最小可市场化特性,这是精益与敏捷中的两个术语,很多人不能准确理解这2个概念的差别,我试图用一个表格对这2个概念进行概括总结:   MVP(Minimum Viable Product),最小可行产品 ...

            MVP是最小可行产品,MMF是最小可市场化特性,这是精益与敏捷中的两个术语,很多人不能准确理解这2个概念的差别,我试图用一个表格对这2个概念进行概括总结:

     MVP(Minimum Viable Product),最小可行产品MMF(minimum marketable feature),最小可市场化特性
    含义最小:抓住用户核心诉求提供最优解,控制需求范围和项目预算,降低产品创新试错成本。
    可行:提供足够的价值,客户愿意花钱(或其他货币,如个人信息)
    产品:实际可以使用的东西,不是不可使用的原型。
    最小:最小可能的特性集合,对用户提供显著的价值
    可市场化:为客户提供重要价值,客户愿意购买。
    特性:用户可以观察到的东西
    用途获取客户对产品价值的反馈:客户认为什么有价值,避免开发了客户不需要的产品。
    用最快的方式、最少的精力进行获得客户对产品是否有价值的反馈,以便完善产品。
    交付价值:可以给客户交付价值的最小特性。
    已经经过确认是有价值的产品特性,可以开发出来进行销售。作为产品发布功能范围的基本单元。
    举例滑板车-->自行车-->摩托车-->汽车简单产品,只有一个MMF:一把螺丝刀
    复杂产品,具有多个MMF:微信,具有聊天、发文件、发图片、群聊、支付等MMF。
    时机产品创意策划、产品定义验证产品发布策划、迭代发布策划
    适用场景创新环境,迭代开发。稳定环境,增量开发。
    完备性最小的产品,可以满足客户目标。是产品的0.X版本。产品的部分功能,并非一定是独立的产品。
    参考图书2011年,Eric Ries, The.lean startup2003年,Mark Denne, Jane Cleland-Huang, Software by Numbers
    其他叫法最小的可测试产品,最早可测试的产品,最早可用的产品,最早可爱的产品,最小可售功能
    展开全文
  • 什么是最小可行产品 MVP?

    万次阅读 2014-12-19 15:35:38
    最小可行产品(Minimum Viable Product,简称MVP)是一种避免开发出客户并不真正需要的产品的开发策略。该策略的基本想法是,快速地构建出符合产品预期功能的最小功能集合,这个最小集合所包含的功能足以满足产品...

    最小可行产品Minimum Viable Product,简称MVP是一种避免开发出客户并不真正需要的产品的开发策略。该策略的基本想法是,快速地构建出符合产品预期功能的最小功能集合,这个最小集合所包含的功能足以满足产品部署的要求并能够检验有关客户与产品交互的关键假设[1]。该概念由Eric Ries在其著作精益创业实战》中提出,用最快、最简明的方式建立一个可用的产品原型,这个原型要表达出你产品最终想要的效果,然后通过迭代来完善细节。


    举个形象的例子,就如下图所示的那样,MVP不是每个迭代做出产品功能的一部分,而是每次迭代都要交付一个可用的最小功能集合,这个集合的功能可以满足用户的基本需求,虽不完善但至少可用。然后逐次迭代做出满足客户预期的产品,直至最后完全满足客户需求。


    MVP是最符合敏捷思想的产品迭代开发方法。MVP首先着眼于基本的客户需求,快速构建一个可满足客户需要的初步产品原型。部署之后,通过客户反馈,逐步修正产品设计和实现,最终达到完全满足客户需要。而最关键的是,在各个迭代过程中,做出来的产品始终是可为客户所用的产品,而不是只有一部分功能却不能让客户使用。


    MVP也适用于初创企业在市场不确定的情况下,通过设计实验来快速检验你的产品或方向是否可行[2]。如果你的假设得到了验证,再投入资源大规模进入市场;如果没有通过,那这就是一次快速试错,尽快调整方向。创业企业可以通过做出最小可用产品,精简到不能再精简,发布之后收集市场反应,逐步调整产品战略,调整里程碑,尽快达成短期目标。MVP产品仅包含必要的功能,从而能从早期的用户得到初始的资金和用户反馈。而仅包含必要的功能点意味着最小成本,最能展现核心概念;MVP不一定是成品,也可以仅仅是理念;通常,构建MVP仅需要数天或数周时间。


    MVP也是简约设计思想的生动体现。我们经常见到一个软件中包含了千千万万的功能,比如Windows操作系统。可是对很多用户来说,能用到的功能也就只有寥寥几个,绝大部分功能都在睡大觉,无法真正体现这些功能的价值。软件厂商与其花费大量人力、时间、金钱来做这些绝大多数用户不使用的功能,不如集中精力于用户真正需要的功能,首先从MVP做起,可定制、可选功能集合,不同的用户只需要安装或配置需要的最小功能集合即可。一个软件中有的,都是用户真正需要的。


    当然,MVP也并不适用于任何时候。有人就曾提出[3],MVP模式的问题在于,它并不总是开发颠覆性技术的最好办法。如果乔布斯发布的是最小可用的 iPhone,我们是不是会得出结论说大家更喜欢键盘?如果 Tesla(电动车)制造的是最小可用汽车,还有没有人去开它?因为与 web 服务不同,就好像不可能有人会花几万块买一辆最小可用的车一样,硬件不是免费的,而且不能快速方便更新。当然,这不是"最小可用"理念本身的问题,只是有些市场不合适。产品到底可以做到多好或者做到什么程度最好?答案或许永远也找不到。这种模式也不一定就是做大事情的最好方式。有些产品是小调,有的则是交响曲,而有时候你还是要先让音乐演奏起来。


    参考文献:

    [1] What is a Minimum Viable Product? http://www.quora.com/What-is-a-Minimum-Viable-Product

    [2] 创业需要MVP(Minimum Viable Product,即“最小化可行产品”) http://column.iresearch.cn/u/zdiwbf/677071.shtml

    [3] 做最小可用产品还是做最漂亮的产品?http://www.36kr.com/p/200474.html


    展开全文
  • 最小可交付的特性(MMF)

    千次阅读 2008-11-13 09:12:00
    具有不同技能的人不得不在一起工作,来交付产品的特性。别做那些没人要的特性;别写那些你编程时不需要的规范;别写你测试不了的代码;别测试那些你不能部署的代码;…… 我认为看板比其它已知的工具更有效地解决了...

        对于软件开发来说,源于丰田生产管理系统中的“看板系统”是一种用于安排工作的非迭代方法。它并不使用固定时长的迭代和计划会议的工作方式,而是完成先前的工作后才从backlog中取得新的故事来做的工作方式。

    Dave Nicolette (Valtech公司的一个敏捷教练)说道:“在敏捷社区中,有一些人似乎变成了干零活的人。他们仅掌握一种敏捷工作的方法,却把它来遇到的解决所有问题.当你只会接管道时,那么所有的事情在你眼里就都都成了管道。”全面学习并扩展敏捷技能而不仅仅是那些SCRUM或XP的基础是非常重要的,比如熟悉像看板等其它工具。

    在软件开发团队中有各种各样的方法来实现看板系统。James Shore(《敏捷开发的艺术》一书的作者)就写过一种:“团队从backlog中拿到一个故事后,实现它,一旦完成就交付它。然后再拿下一个故事,实现并交付它。他们的工作就是完成并尽快地交付它,团队一次只做一个故事。”依James所说,让看板真正发挥作用有几个关键因素:

    • 最小化可交付的特性(MMF):一个MMF是最小粒度且有商业价值的特性。MMF被放在一个队列中维护,(很像Scrum中的产品Backlog),但对队列的大小有严格的限制(James认为应该是两到三个,最多七个)。
    • 在线生产:团队总是在做最重要的事,直到完成它,而且在一个时段内只做这件事,并把它分成很多小且离散的任务。
    • 估算:放弃正式的计划与评估,而假设所有的MMF都有相似的大小。通过记录完成每个特性的平均时间,来估计队列中剩余的特性还需要多长时间。
    • 紧急任务:偶尔也会有紧急任务。要为紧急任务留有一个通道,这个通道会绕过了队列,一旦紧急任务走上这个通道,那就要求团队尽快地完成它.所以额外的紧急任务不受正常的backlog的限制。
    • 缺陷:一旦出现缺陷,如果任务还没有完成的话,就要立刻修复它,否则就被放入backlog中。

    David Anderson(《敏捷管理》作者,而且是看板系统的力荐者)说道,他的成功密诀就是:“关注质量,减少在线产品,根据需求及优先级来平衡能力”。

    Corey Ladas回答关于“为什么使用‘拉’的方式?为什么使用看板?”这样的问题时,说道:

    具有不同技能的人不得不在一起工作,来交付产品的特性。别做那些没人要的特性;别写那些你编程时不需要的规范;别写你测试不了的代码;别测试那些你不能部署的代码;……我认为看板比其它已知的工具更有效地解决了这一问题。

    David Laribee为其前任雇主Xclaim引入了看板,因为在使用XP的两年后,他还是面临很多障碍和麻烦。另外,他感到,在计划、回顾和演示上浪费了很多时间。而且最终每一个的敏捷团队都会有自己的工作流程,"当然,我们不可能在第一天就找到这样的流程.我们首先要根据已知且广泛应用的实践建立一个好的基线,这些实践包括TDD,滚动式计划等等。然而,好的敏捷团队会持续调整他们的过程以适合他们的产品及客户的需要。"

    加入看板的邮件列表,查看更多的关于看板的讨论。

    InfoQ中有关看板的文章:敏捷的未来方向, 使用看板让敏捷项目可视化Scrum-ban Paper Adds Kanban to Scrum

    查看英文原文:Kanban as Alternative Agile Implementation

    展开全文
  • 敏捷交付Assurance and Agile — two words not commonly seen together, and for good reason. The early and iterative delivery of product increments using Agile, constantly reviewed and inspected, ...
  • 带有移动接收器的无线传感器网络中的交付延迟最小
  • Dellat:带移动接收器的无线传感器网络中的交付延迟最小
  • 软件测试面试题(面试前准备篇)

    万次阅读 多人点赞 2019-09-27 10:42:37
    UDP尽最大努力交付,即不保证可靠交付 3、TCP面向字节流,实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的 UDP没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如IP...
  • 计算机网络谢希仁第七版 课后答案

    万次阅读 多人点赞 2019-09-03 23:13:25
    答:电视,计算机视窗操作系统、工农业产品 1-26 试解释以下名词:协议栈、实体、对等层、协议数据单元、服务访问点、客户、服务器、客户-服务器方式。 答:实体(entity) 表示任何发送或接收信息的硬件或软件进程...
  • 测试开发需要学习的知识结构

    万次阅读 多人点赞 2018-04-12 10:40:58
    努力成为一个优秀的测试开发从业者,加油!... - 假装在测试的回答 - 知乎白盒与黑盒测试什么区分1、黑盒测试 黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检...
  • 软件测试面试题汇总

    万次阅读 多人点赞 2018-09-27 12:31:09
    转载自: ... 软件测试面试题汇总 测试技术面试题 ...........................................................................................................
  • 如何提高项目交付效率

    千次阅读 2020-03-18 11:06:06
    道法术出自老子《道德经》,道,是规则、自然法则,上乘。...日常工作中新知识学习、新技能扩充、未知问题解决、项目实施交付,都可以从道、法、术、器这几个层面入手,找对解决方案,选对解决措施,将问题逐一击破...
  • 计算机网络谢希仁第七版课后习题答案

    万次阅读 多人点赞 2019-10-12 21:43:44
    若打算使总的时延为最小,问分组的数据部分长度p应取为多大?(提示:参考图1-12的分组交换部分,观察总的时延是由哪几部分组成。)答:总时延D表达式,分组交换时延为:D= kd+(x/p)((p+h)/b)+ (k-1)(p+h)/b D对p...
  • 无人机交付-源码

    2021-02-16 10:49:21
    无人机交付 项目设置 npm install 编译和热重装以进行开发 npm run serve 编译并最小化生产 npm run build 运行单元测试 npm run test:unit 整理和修复文件 npm run lint 自定义配置 请参阅。
  • 深信服AD应用交付介绍

    千次阅读 2019-07-03 15:21:54
    先进的应用交付产品(ADC)能帮助用户缓解来自于当今复杂应用环境部署和交付的挑战。过去的十年,伴随着企业级应用以业务流程和用户生产力为目标,向基于浏览器模式的大量迁移,同时也见证了面向服务架构(SOA) 、...
  • 持续交付 容器化 云原生的发展历程 云原生技术生态现状 云原生基金会 —— CNCF 云原生技术社区 云原生技术产业 我们正处于时代的关键节点 2019 年,云原生技术普及元年 云原生代表技术 “12要素” 基准...
  • 软件测试入门知识了解

    万次阅读 多人点赞 2018-09-05 14:59:58
    需求评审和设计评审是验证软件产品的需求定义和设计实现,验证所定义的产品特性是否符合客户的期望、系统的设计是否合理、是否具有测试性以及满足非功能质量特性的要求。这个阶段主要通过对需求文档、设计文档等...
  • 本视频讲述了如何用架构图表达软件工程的构成和内容,用架构图对软件工程的内容进行了阶段划分,并说明了不同阶段需要的交付物、交付内容、交付标准等。通过图形,可以非常直观地理解软件工程的构成,对于学习和应用...
  • 交付管理——怎样构建项目团队

    千次阅读 2020-08-27 18:18:24
    怎样做才能把项目交付好,确保公司的持续经营,是每一个创业者在创业初期就要想清楚的问题。 在这里,我想先从组织架构讲起,跟大家聊一聊怎样构建项目团队。 对一个公司的经营来说,如何把管理效能最大化,是每一...
  • MQTT协议

    千次阅读 2016-04-26 21:48:31
    轻量传输,开销很小(固定头部的长度只有2字节),协议交换最小化,以降低网络流量。 提供一种机制,当客户端异常中断时,利用 Last Will 和 Testament 特性来通知有关各方。 1. 简介 该协议规范主要...
  • 通过改进的图书馆管理,简化的自适应视图,更灵活和可重复使用的母版以及动态面板的内联编辑,更有效地工作,迅速完成从头脑风暴到完善的可交付成果。 Axure RP 9 Mac破解版小编点评 Axure RP 9 for Mac一...
  • 最小化构建,文件名包含哈希。 您的应用已准备好进行部署! 有关更多信息,请参见有关的部分。 npm run eject 注意:这是单向操作。 eject ,您将无法返回! 如果您对构建工具和配置选择不满意,则可以随时eject...
  • 产品思维的修炼–技术的必修课

    千次阅读 2018-07-25 08:15:38
    作为写了十多年代码的技术表示:产品思维比程序员们想象中重要得多!掌握了产品思维的程序员能力可以double!我把产品思维的养成要点,从我的认知上提炼了下,供大家参考。 理解产品思维前,首先需要了解产品经理是...
  • 敏捷就是快速交付吗?

    千次阅读 2019-09-08 14:18:41
    首次发布我们要用最小的可用产品(MVP)的模式,而后续的发布我们采用的是增量的模式。 怎样理解敏捷的快? 好了,我们小结一下,应该怎样理解敏捷的快呢? 在清晰和精准的市场定位,以及可行的盈利模式下,以MVP的...
  • 在物料主数据中,是设置于MRP1的最小批量(Minimum Lot Size)舍入值,信息记录中的是在采购组织数据中的最小数量(Minimum Qty).最小包装量(MPQ)在物料主数据的舍入值或舍入参数文件(rounding value、rounding profile...
  • 心理辅导平台设计

    千次阅读 2017-12-04 10:22:57
    c利用的资源和信息:参考已有的社交软件系统。 (8)开发基本计划: 工作集 内容 时间 准备工作 社会调查,进行学生,社会人士,心理机构中心和企业有关这款app的建议调查,收集数据...
  • 第1章 持续交付2.0

    2019-03-25 11:27:18
    精益思想是指导企业根据用户需求,定义企业生产价值,按照价值流来组织全部生产活动,使价值在生产活动之间流动起开,由需求拉动产品的生产,从而识别整个生产过程中不经意间产生的浪费,并消除之。 持续交付2.0“8...
  • 软件工程作为一项复杂的工程,具有四个特点:volatility(易变性)、uncertainty(不确定性)、conplexity(复杂性)、ambiguity(模糊性),正是由于这些软件特性,我们为了达成持续交付目标时,经常会遇到业务压力...
  • 应用交付

    千次阅读 2015-05-21 14:47:58
    1.什么是应用交付? “应用交付”,实际上就是指应用交付网络(Application Delivery Networking,简称ADN),它利用相应的网络优化/加速设备,确保用户的业务应用能够快速、安全、可靠地交付给内部员工和外部服务...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 35,079
精华内容 14,031
关键字:

最小可交付产品