|
|
|
|
移动端

“洋葱”式App开发:为什么你的软件项目越来越冗杂?

开发项目的初衷很美好,功能需求你都理得特别清晰。可为什么在实际开发过程中,你的软件项目总是需要更改和调整?最终,添加的功能越来越多......要知道,看上去很理所当然的功能列表,实际做下去之后你就会发现事情没那么简单。

作者:Vivian Wang编译来源:36氪|2018-04-24 10:38

技术沙龙 | 邀您于8月25日与国美/AWS/转转三位专家共同探讨小程序电商实战

编者按:开发项目的初衷很美好,功能需求你都理得特别清晰。可为什么在实际开发过程中,你的软件项目总是需要更改和调整?最终,添加的功能越来越多......要知道,看上去很理所当然的功能列表,实际做下去之后你就会发现事情没那么简单。本文编译自Medium上原题为《Your app is an onion: Why software projects spiral out of control》的文章。

“洋葱”式App开发:为什么你的软件项目越来越冗杂?

最开始,你的想法很美好。你会雇佣一个开发者来实现自己的创业点子。但几乎每一周,项目似乎都需要进行调整。各种功能开始涌入,范围越铺越大。

就好像项目被赋予了生命,而它正在试图毁掉你的生活。

“洋葱”式App开发:为什么你的软件项目越来越冗杂?

这一切究竟是怎么发生的?你雇佣的开发者不靠谱吗?还是你没能做好项目管理?抑或是创意自始至终就很糟糕吗?

这都有可能。但是有一个核心误区通常在一开始就注定了项目最终会失败。

我们假设自己的项目是由功能组合定义而成的,我们会将这些功能记在纸上。偶尔再添加一些功能,偶尔又会减掉一些。但你仍然能一眼看到项目的范围。

但是,这种假设是错误的。

你的项目并非存在于二维空间里,它不是一张纸。它有自己的深度。

软件的每一个功能都可以被一层一层得剥开。事实上,如果我倾向于做标题党的话,那我会直截了当得表示你的应用就是个洋葱。让我来解释下这到底是什么意思吧。我会告诉你,为什么你在将自己的应用一层一层剥下时,它会让你流泪不止。

终结所有图书馆的图书馆

我们来聊点具体的例子吧。给我推荐一个想法吧。

人们通常想看的书,附近的图书馆都没有。但其他地区的人可能会有。因此,这款应用可以让人们发送图书需求,而有这本书的人则会作出响应。每一笔交易,我们都会进行抽成。

这个想法,很有才吧!

我知道,难道不是吗?功能列表非常简洁明了:

“洋葱”式App开发:为什么你的软件项目越来越冗杂?

现在是时候把产品说明书发给开发者,然后开始给公司考虑一个炫酷的名字了。kaBooki?lib.rari.ly?还是reddit?

欸?别急阿。让我们再稍微深思一下吧。更何况,已经有一个软件叫reddit了。

让我们带着下述这些问题来细究一下你的想法,看看想法最后究竟会发展成什么样子吧。

用户如何交易呢?他们是见面的时候一手交钱、一手交货还是说通过应用来付款呢?

恩,他们应该在应用上利用信用卡进行付款,这样我们才能抽成啊。

他们该如何发送图书需求呢?我的意思是,他们在应用上究竟要做些什么呢?是填写一个包含书名和作者信息的开放式表格吗?

哦......他们应该在应用上搜索图书,然后挑选自己感兴趣的。

好的,那么我们就需要建立一个图书数据库了。

我想应该是这样。

那实际上,究竟什么是图书需求呢?卖书的人能够看到所有的书籍需求列表吗?还是说我们需要像Uber或是Thumbtack那样发送通知告知这些卖书的人吗?

是的,我们需要给那些有书的人发送需求通知。

那么,卖书的人需要在软件里填写自己要卖的书目信息吗?

恩,是的。

那么书该如何完成交接呢?是用户自行交接,还是我们帮忙处理配送问题呢?

我们负责配送。

那你需要一个系统告诉你哪些书需要取货,然后要送往哪里。我想你的司机应该会想知道最短路线怎么走吧,对吗?

好吧,这样可不行。那不如这样吧?让用户相互之间邮寄图书。

那么,我们就这样将收货人的地址信息告知发货人?那我们如何解决运费问题呢?

实际上,你知道的。这些用户都需要靠得近一些。他们可以上门取货,顺便还能认识个新朋友,这样不好吗?

所以,我们需要匹配距离相隔较近的用户。那他们如何找到对方呢?应用是否还需要内嵌一个实时地图,这样才能安排见面呢?

好吧,这样也行。就这么做吧。

我们需要设定图书的价格吗?还是说买卖双方自行商定?

他们自己商定吧,然后确定一个价格。

他们如何确定呢?我们是否要在应用里嵌入一个聊天功能?

他们可以直接打电话进行联系啊。

好吧,那我们是否要发送短信来确认号码的有效性呢?如果......好了,说到这儿你就应该懂我的意思了。我们还可以这样无休止得谈下去。

别,别再就此问题继续聊下去了。

那不妨现在再来看看功能列表长什么样吧。

“洋葱”式App开发:为什么你的软件项目越来越冗杂?

每一行列出来的内容都可以多次进行延伸。我们只不过刚刚把洋葱剥开了一层皮,结果就已经变成这样了。

现在,你可不要哭啊。

到底发生了什么呢?

我们要弄清楚哪些原因不会导致功能爆炸。

这也并非是我们常说的功能蔓延。

功能蔓延指的是产品不断添加新的功能。如果你看一下我们最终的功能列表,你会发现每一条功能的存在都符合最初的想法设定。

而这也无关乎任何技术考量。

举个例子,什么是最适合的聊天系统架构呢?最容易整合的支付平台是什么呢?

我们在这儿不会就这个问题多加赘述。一个优秀的开发人员会把各式各样的技术方案都告知给你。但是他无法帮你决定软件需要什么功能。

这也无关什么市场考量。

人们需要这样一个产品吗?在用户数量很少的情况下,你该如何诱使早期用户报名呢?用户愿意为此项服务付费吗?

这类问题必须要和想法的验证、产品市场组合的确定以及定价策略息息相关。再重申一下,这些问题都非常重要。不过,这也并非是功能列表爆炸的原因。

这与全球变暖或是牙仙也没有任何联系。你是打算告诉我项目变成洋葱的原因吗?还是说你打算告诉我每一条非原因项吗?

你可真无趣。事情其实是这样的。

我们从根本意义上就曲解了复杂性的运作原理。

我们原本以为每一项功能的复杂程度就和我们一开始描述得一样。嘿,也许程序员是要花些功夫去写代码的,但是用商业术语中的几个词,你就可以轻松描述出产品的功能。比如说“用户用Y来做X这件事”。不是吗?

可这种观点是错误的。

软件功能更像是分形

你离得越近去看,它们就能呈现出更多的细节。

洋葱是分形吗?

不,我只是换了个隐喻而已。继续说吧。

关于功能,我们一开始是基于一个大的蓝图去进行描述的。但是,当开发人员在开发这款应用时候,抑或是用户或你本人使用这款应用时,其实它是在一个较小的规模下进行的。它是一步一步在软件内完成的。每一个步骤,你都会遇到一些问题。为了解决这些问题,你需要重新规划这一步骤、添加新的步骤或是添加全新的功能。

这就像是规划一条从你家到办公室的路线。看着地图,这段行程似乎就是两点连起来的一条直线。

“洋葱”式App开发:为什么你的软件项目越来越冗杂?

但当你以更小的比例去看这条路线时,你会发现自己原先规划的那条直线并不符合城市道路网。你会遇到交通站、高地或者道路阻塞。基于你是步行、骑车还是驾车,你可能需要规划一条不同的路线。

开发软件也与之类似。当你离得越近去看,你就可以更为详细地意识到你的解决方案是什么样子的。

那可真是太棒了,一路上都是各种细节,这还都是我需要去考虑的。这是不是意味着我的产品永远都完不成了?

是也不是。之所以会显得复杂,原因在于我们在一开始对功能进行了描述,这通常是要实现的目标。之后,我们就会将其放大处理,一步步设计解决方案来实现目标。当我们将细节放大,我们就会发现事情变得愈加复杂了。

复杂本身不是问题。问题是我们选择发现复杂性的方式。我们将功能的规格说明书递交给开发人员。几周之后,我们会拿到应用的初始版本并且进行测试。这是我们第一次一步一步操作整个软件,然后我们就发现很多的漏洞。我们会将修改意见记录下来,然后将其发送给开发人员,让他开发第二版应用。

“洋葱”式App开发:为什么你的软件项目越来越冗杂?

在整个过程的最后,经过反复几次的修改调整,我们得到了一个较好的解决方案。问题在于,开发周期实在是太长了。每一个环节都需要数周或数月时间来完成,

但是,要发现应用存在的内部复杂性,这又是必要之举。

反反复复和开发人员进行沟通来发现这种复杂性,耗时还烧钱。

我们希望这样做:

“洋葱”式App开发:为什么你的软件项目越来越冗杂?

我们想要在写代码之前就能尽可能多得发现这种复杂性。我们想要剥下“洋葱”的皮来发现一个更可靠的功能清单,最好能以一种快速且便宜的方式。

我们并不想来回修改应用,而是想要反复修改软件规格书。

我们想要从这个流程:

“洋葱”式App开发:为什么你的软件项目越来越冗杂?

变为这个流程:

“洋葱”式App开发:为什么你的软件项目越来越冗杂?

为了高效做到这一点,我们需要两个东西。首先,我们需要一种方式来呈现功能列表,以便之后反复修改调整。第二,我们需要一种高效的方式来审视这份功能列表。

我们来聊聊该如何实现这两点吧。

规划功能

我们不必再用商业术语来考虑这一点,而是要把自己当做是一个用户去思考功能需求。在这个层面上,我们就需要应对软件复杂性问题了。

首先,列出用户目标。用户使用你的app要做什么呢?

接下来,你需要规划用户流程。以用户的角色确认实现目标所需要的每一个步骤,记录下这些内容。

我们要建立一张用户使用应用的流程图。

有很多种方式可以实现这一点。你可以简单做一个所需步骤的略图。你可以针对用户看到的每一个界面进行版面设计。你还可以在纸上或是用软件画出流程图。

“洋葱”式App开发:为什么你的软件项目越来越冗杂?

图中是一种版面设计。

不管你选择哪种方式,确保优先考虑速度问题。除非你是Photoshop领域的专家,否则还是放弃使用软件,拿起纸笔来干活吧。

确保略图中能呈现出每一个界面。举个例子,如果一个特定的步骤需要在屏幕上以多个界面呈现出来,那你就需要将该步骤分开。我们希望能梳理出更多的细节。

此过程应该能揭示出应用中存在的一些复杂性问题了。

现在,我们要开始从更深层面来挖掘了。

对一切事情保持疑问

像我们之前问的那些问题未免太过宽泛了。这很难找到切入点。

首先,我列出了一些适用于大多数软件的常见问题。这些问题会被分为四大类,你可以将其当做是模板来提问自己的软件略图。

仔细观察略图中的每一个步骤,拿列表上的每一个问题问问自己。如果答案呈现出了新的步骤,就将其添加在你的软件略图里。

用户输入:

这些问题是用户在输入信息到产品中时候会碰到的。

  • 用户会输入什么样的信息?
  • 输入的是信息是开放式的还是交互式的?
  • 开放式信息举例:输入自由格式文本内容、选择图片进行上传或录制视频。
  • 交互举例:往搜索框输入文本来显示可选结果、在地图上选择地址、从预定义选项组合中进行选择。
  • 是否有些输入的信息应该被当做是无效的呢?应用又将如何处理呢?
  • 是否有无源输入呢?最常见的例子:通过GPS 进行用户定位。
  • 产品需要获取新用户 (https://www.useronboard.com/)的什么信息呢?用户后续可以对信息进行修改吗?

向用户呈现的信息

如果之前那部分算作是信息输入,那么这部分应当是信息输出。

  • 屏幕上哪些信息会被呈现给用户?
  • 信息是以何种方式呈现的?比如说:文本、图片、地图、列表或图表。
  • 这些信息需要以某种形式进行筛选吗?比如说:距上次使用时间、用户距离、相关性等。
  • 产品是否可以主动和外界进行交流?比如说:邮件、推送通知、短信。

各部分之间的交互

这部分问题是关于软件体验中各个部分之间的交互。

  • 用户会彼此之间进行交互吗?比如说:短信、添加好友、点赞或是给其他用户内容加标签。
  • 用户是否会和外界服务发生交互呢?比如说:付费服务、物流追踪、社交媒体账户登录。
  • 产品是否会和外界服务发生交互呢?比如说:位置查找服务、天气应用程序接口、社交网络(“你的朋友XXX刚刚加入了!查看他们的信息!”)

企业家功能

这部分问题是关于企业家对于产品的需求。

  • 你需要通过邮件或其他媒介发送提醒或介绍吗?
  • 你需要为自己或员工提供专门的系统吗?比如:为配送人员提供导航软件,为厨房员工提供实时点餐管理接口。
  • 你需要手动批准用户/内容的接口吗?
  • 你需要一个内容管理系统吗?它可以让管理员轻松撤除内容或让用户账户失效。

还有很多很多的问题。

这就对了!这其实也是人们通常在开发应用早期会遗忘的一些问题。针对你的产品,还会衍生出更多的问题,你需要慢慢发现。

总结

建立软件略图和审核软件的过程会告诉你——你漏掉了哪些内容。重复几次这一流程,之后你就可以更加自信地提供一份可靠的功能清单了。

你知道,我真的希望你有什么妙招能够修缮我的项目。可这听上去工作量好像很大的样子。

事实也确实如此。但是这是你在软件开发过程中必须要做的事情,不论在什么阶段。

记住我们之所以要这样做的原因。无论如何,你都需要发现软件功能中隐藏的复杂性问题。你所要做的仅仅是选择何时剥洋葱。

从本质上来说,你有两个选择:

  1. 你可以发现用户目标、构建版图设计或流程图、质疑自己的假设,然后像我们说得那样将软件一层一层剥开。或者说,
  2. 你可以让开发人员直接开始开发应用,然后根据开发的每一个版本暴露的问题进行修改,一周一次。在几个月之后,你就会发现这些问题,你本可以在一周之内就用纸笔想明白的。

这也是为什么软件项目常常会变得非常复杂,恨不得将你生吞活剥掉一般。

那么,赶快去发现自己所需要的功能吧。构建版图设计然后质疑自己的假设,用一种快速且省钱的方式发现大量的问题。

此举可以将你从压力和痛苦中拯救出来,帮助你将产品推向全世界,让它如繁花一般恣意盛开。

洋葱会盛开吗?你这比喻可真糟糕。

【编辑推荐】

  1. 如何将iOS项目的编译速度提高5倍
  2. 我业余时间如何学习多门技术以及开发业余项目的一些心得
  3. 说说项目从0-1过程中的那点事儿
  4. 接手一个负分的iOS项目后我做了什么
  5. 腾讯关于微信和移动开发的10大开源项目
【责任编辑:未丽燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

Struts 2权威指南:基于WebWork核心的MVC开发

本书所介绍的Struts 2已经完全超出了Struts 1框架原有的高度,Struts 2建立在Struts 1和WebWork两个框架整合的基础之上,因此提供了更多优...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊