你最开始想得很好。雇佣开发人员来构建出你的创业想法。但是几乎每一周，都感觉似乎项目需要做做调整，于是各种功能开始混进来，范围逐渐蔓延。
仿佛这项目拥有了自己的生命，而且还试图毁掉你的生活。
怎么会这样呢？你雇佣的开发人员很差劲吗？你对项目管理也只是摸着石头过河吗？还是这个想法从头到尾就是糟糕的？
有可能。但一个核心误区通常会在一开始注定项目的失败。
我们的假设是，给产品定义一系列的功能并记在纸上后，虽然偶然有时候要新增功能，有时候要去除功能，但是你一眼就能看出项目的范围大小。
这个假设是错误的。
你的项目不像一张纸一样是二维的，它还有深度。
软件的每个功能都可以被一层一层剥开。事实上，如果我想当标题党的话，我会说你的app就是个洋葱。我来讲一下我的意思，来告诉你为什么当你把自己的app一层层剥开时，它会让你泪流满面。
终结所有图书馆的图书馆。咱们通过具体的实例来看吧，给你推荐一个我的想法。
人们经常会想要附近图书馆没有的书，而在这附件其它的人可能会有。因此，这款app可以让人们发送用书请求，然后有这本书的人会响应。我们从每一次这样的交易中获利。
太有才了。
这我知道，好吧？软件的功能直截了当：
现在该把规格说明书交给开发人员，并且给软件想个精彩的名字了。叫kaBooki？lib.rari.ly？rddit？
好吧，稍等一下，我们仔细来看看。而且已经有软件叫rddit了。
我们带着问题探究一下你的想法，看看会发现什么。
用户彼此之间如何付款呢？见面的时候付现金还是在app上付款呢？
哦，他们应该在app上用信用卡支付，这样我们能够获得提成。
他们实际上怎么发送用书请求呢？我的意思是，他们到底在app上要怎么操作呢？要填写一个包含了书名和作者的开放式表格吗？
噢，嗯。他们应该对书进行检索并且选择一本想要的。
好，所以我们需要建个书的数据库。
我猜是要这样。
实际上，什么是用书请求呢？拿着书并且准备把书卖出去的人能看到请求的书单吗？还是说我们要向这些要卖书的人发送通知，像Ubr或Thumbtack那样？
是那样，我们将用书请求发给持有书的人。
所以，卖书者需要往app中填充所有在售书籍的信息吗？
呃，是的。
怎么进行书的交接呢？用户自己送书，还是我们处理配送问题？
我们处理配送问题。
所以你需要一个系统来告诉你要拿什么书，以及书应送往的地方。我猜你的司机想知道最短的送书路线，对吧？
好吧，这样不可行。那让用户彼此之间寄书怎么样呢？
所以我们要将收书人的地址给发书的人？怎么处理运费问题呢？
实际上，你知道的，这些用户需要挨得比较近，这样他们就可以直接过去拿书了，还能交个新朋友，对吧？
所以我们需要把挨得近的用户匹配起来。他们怎么找对方呢？App有没有实时地图好让他们安排见面呢？
好，行，就这样吧。
我们要给书定价吗？还是他们自己商量价格？
他们自己谈个明白，给书定好一个价格。
他们怎么做决定？我们是不是需要在app里建个交流平台呢？
他们彼此只需要用电话谈就行了。
好吧，所以我们是不是要用SMS（ShortMssagingSrvic短信服务）短信来确认号码呢？还是……你懂我的意思了，我们真的可以永远无休无止地进行下去。
请别这样。
我们来看一下现在功能清单是什么样的：
每一条项目的功能都可以进行多次扩展，我们只把洋葱拨开了一层，就已经成这样了。
现在啊，现在可别哭。
发生了什么呢？我们要清楚哪些东西不是导致功能激增的原因。
这不是我们通常所知的功能蔓延。功能蔓延是指产品中不断增添新的功能，而如果你看一眼我们最终列的功能清单，里面每一条都支持最初的功能设定。
这无关乎科技因素。比如说，聊天系统最适宜的结构是怎样的呢？什么支付平台是最容易整合的呢？
我们在这儿不讨论那些。一个好的开发人员可以通过各式各样的技术手段与你沟通，但是不能替你决定软件需要具备什么功能。
这也无关乎技术考量。人们想使用这样的产品吗？当其他用户还很少时，有什么因素会诱使早期的用户来登陆软件呢？用户愿意为这项服务付费吗？
这些问题与想法的落实、产品市场匹配度的确认、定价的策略等息息相关。再重申一次，这些项都是非常重要的，但却不是软件功能清单中内容多到炸的原因。
当然这也与全球变暖或者牙仙没有丝毫关系，你要告诉我变成项目变成洋葱的原因吗？或者说看完觉得每个其实都并没什么理由？
噢，你这样很无聊，事实是这样：
我们基本上对复杂性是怎么凸显的存在误解。
我们以为每个功能的复杂程度就像我们开始描述的那样。嘿，也许程序员写代码要花费时间，或者随便程序员做什么，但是商业用语区区几个词就可以完全描述软件的功能，像“用户通过y使用x”，对吧？
这种观点是错的。
软件功能更像是分形。你离得越近去看，细节就会展现得越明显。
洋葱是分形？
不是，我已经换了比喻。咱们继续。
我们从全局视角来开始描述软件的功能。但是，当构建好app，或是使用app时，是处在一个较小规模下的。它的完成一步一步进行的，每一个步骤都有可能遇到问题。为了解决问题，你可能需要重新设计这一步、添加新步骤、或是增添全新功能。
这就像是规划一条从你家到单位的行程。看地图的话，行程好像是直的。
当你开始从更小的视角来看，你会发现直的路线并不会城市道路网相契合。你会遇到交通站、高坡和道路阻塞。根据步行、骑行或者开车的不同，你的行程路线也会不同。
建立软件很大程度上是一样的，你离得越近去看，对解决方案就能有越细致的认识。
这下好了，一路到处都充斥着细节，还都是我需要考虑的。这是否意味着我的产品永远也不可能做完呢？
这么想也对也不对，之所以复杂性凸显，是因为我们一开始就宏观描述了软件功能，也通常就是要实现的目标。然后我们将细节放大，为实现这一目标而一步步建立解决方案。细节放得越大，就会发现越多复杂的问题。
但复杂性并不是问题所在，问题是我们如何来发现复杂性的。我们把软件功能规格书叫个开发人员，几周过后，我们拿到了第一版的app并开始测试。这是我们第一次一步一步操作软件，会从中发现大量漏洞。然后我们做好修订说明，把它交给开发者，让他们再开发第二版app。
在整个流程的最后一步，我们在多次进行之后，得到了很好的解决方案。
问题是开发周期真的太长了，每一环节都要耗费好几周或好几个月。
但是发现app的潜在复杂性又是必要之举。
通过来回反复和开发人员交涉来发现这种复杂性，既耗时又烧钱。
我们想这样做：
我们想在开始写代码之前就尽可能多得发现它的复杂性，将软件层层剥开来，看到一个更加健壮的功能清单，而且想做得又快又省钱。
我们想在软件规格书上来回修改，而不是在app上反复折腾。
我们想从这个过程：
走到这个过程：
我们需要两个东西来行之有效地实现这个过程：第一，我们需要一种方式来展示功能清单，以便反复修改；第二，我们需要一种方式来高效地就功能清单进行审核协商。
我们来看看怎么做。
规划功能我们不想以商业用语来谈，而是像用户一样的身份来考虑软件功能。在这个层面就需要处理软件的复杂性问题了。
首先，列一张用户目标表。你想让用户通过你的app获得什么呢？
接下来，你需要规划用户流程，以用户的身份走每一步，来实现用户目标，并记录这些步骤。
我们建立一张用户使用app的流程图。
有很多种做的方式，你仅需为每一步勾勒一个简单的略图即可。你可以为用户走过的每一个界面绘制模型，也可以在纸上或软件上画流程图。
无论你选择哪种方式，确保优先考虑速度问题。除非你是Photoshop专家，否则把软件收起来，拿纸和笔画吧。
确保每个界面在你的软件略图中都能够得以体现。比如说，如果一个特定的步骤会经过app的好几个界面，那么把该步骤切分开。我们想要梳理出更多的细节，而不是更少的。
这个单独的过程应该将app中一些复杂的问题平面化。现在，我们要往更深处挖。
对一切保持疑问我们要是像之前那样提问的话，范围太宽泛了，无从下手。
首先我们将适用于大部分软件的一些常见问题列到一起，这些问题可以归为四个大类，你可以把它当做框架来组织软件略图。
看着软件略图的每一步，问你自己清单上写的每一个问题。如果答案会展现出一个新的步骤，那就把它添加进软件略图。
清单在这儿：
用户输入这些问题与用户提交到产品的信息有关
用户会输入什么信息？
输入的是信息是开放式的还是交互式的？
开放式信息范例：输入自由格式文本，上传图片，录制视频。
交互举例：往搜索框输入文本来显示可选结果、在地图上选取地址、选择那些预定义选项。
是否有些输入应该被当做无效呢？App又该如何处理呢？
是否有无源输入呢？最常见的例子：通过GPS进行用户定位。
产品需要获取新用户(治疗皮肤病医院哪家最好吉林白癜风医院