越做越复杂的软件工程项目

你的APP就像个洋葱:为什么软件开发项目一路失控

你最开始想得很好。雇佣开发人员来构建出你的创业想法。但是几乎每一周,都感觉似乎项目需要做做调整,于是各种功能开始混进来,范围逐渐蔓延。

仿佛这项目拥有了自己的生命,而且还试图毁掉你的生活。

怎么会这样呢?你雇佣的开发人员很差劲吗?你对项目管理也只是摸着石头过河吗?还是这个想法从头到尾就是糟糕的?

有可能。但一个核心误区通常会在一开始注定项目的失败。

我们的假设是,给产品定义一系列的功能并记在纸上后,虽然偶然有时候要新增功能,有时候要去除功能,但是你一眼就能看出项目的范围大小。

这个假设是错误的。

你的项目不像一张纸一样是二维的,它还有深度。

软件的每个功能都可以被一层一层剥开。事实上,如果我想当标题党的话,我会说你的app就是个洋葱。我来讲一下我的意思,来告诉你为什么当你把自己的 app 一层层剥开时,它会让你泪流满面。

终结所有图书馆的图书馆。

咱们通过具体的实例来看吧,给你推荐一个我的想法。

人们经常会想要附近图书馆没有的书,而在这附件其它的人可能会有。因此,这款 app 可以让人们发送用书请求,然后有这本书的人会响应。我们从每一次这样的交易中获利。

太有才了。

这我知道,好吧?软件的功能直截了当 :

现在该把规格说明书交给开发人员,并且给软件想个精彩的名字了。叫 kaBooki?lib.rari.ly?reddit?

好吧,稍等一下,我们仔细来看看。而且已经有软件叫reddit了。

我们带着问题探究一下你的想法,看看会发现什么。

用户彼此之间如何付款呢?见面的时候付现金还是在 app 上付款呢?

哦,他们应该在app上用信用卡支付,这样我们能够获得提成。

他们实际上怎么发送用书请求呢?我的意思是,他们到底在 app 上要怎么操作呢?要填写一个包含了书名和作者的开放式表格吗?

噢,嗯。他们应该对书进行检索并且选择一本想要的。

好,所以我们需要建个书的数据库。

我猜是要这样。

实际上,什么是用书请求呢?拿着书并且准备把书卖出去的人能看到请求的书单吗?还是说我们要向这些要卖书的人发送通知,像 Uber 或 Thumbtack 那样?

是那样,我们将用书请求发给持有书的人。

所以,卖书者需要往 app 中填充所有在售书籍的信息吗?

呃,是的。

怎么进行书的交接呢?用户自己送书,还是我们处理配送问题?

我们处理配送问题。

所以你需要一个系统来告诉你要拿什么书,以及书应送往的地方。我猜你的司机想知道最短的送书路线,对吧?

好吧,这样不可行。那让用户彼此之间寄书怎么样呢?

所以我们要将收书人的地址给发书的人?怎么处理运费问题呢?

实际上,你知道的,这些用户需要挨得比较近,这样他们就可以直接过去拿书了,还能交个新朋友,对吧?

所以我们需要把挨得近的用户匹配起来。他们怎么找对方呢?App 有没有实时地图好让他们安排见面呢?

好,行,就这样吧。

我们要给书定价吗?还是他们自己商量价格?

他们自己谈个明白,给书定好一个价格。

他们怎么做决定?我们是不是需要在 app 里建个交流平台呢?

他们彼此只需要用电话谈就行了。

好吧,所以我们是不是要用 SMS (Short Messaging Service 短信服务)短信来确认号码呢?还是……你懂我的意思了,我们真的可以永远无休无止地进行下去。

请别这样。

我们来看一下现在功能清单是什么样的:

每一条项目的功能都可以进行多次扩展,我们只把洋葱拨开了一层,就已经成这样了。

现在啊,现在可别哭。

发生了什么呢?

我们要清楚哪些东西不是导致功能激增的原因。

这不是我们通常所知的功能蔓延。

功能蔓延是指产品中不断增添新的功能,而如果你看一眼我们最终列的功能清单,里面每一条都支持最初的功能设定。

这无关乎科技因素。

比如说,聊天系统最适宜的结构是怎样的呢?什么支付平台是最容易整合的呢?

我们在这儿不讨论那些。一个好的开发人员可以通过各式各样的技术手段与你沟通,但是不能替你决定软件需要具备什么功能。

这也无关乎技术考量。

人们想使用这样的产品吗?当其他用户还很少时,有什么因素会诱使早期的用户来登陆软件呢?用户愿意为这项服务付费吗?

这些问题与想法的落实、产品市场匹配度的确认、定价的策略等息息相关。再重申一次,这些项都是非常重要的,但却不是软件功能清单中内容多到炸的原因。

当然这也与全球变暖或者牙仙没有丝毫关系,你要告诉我变成项目变成洋葱的原因吗?或者说看完觉得每个其实都并没什么理由?

噢,你这样很无聊,事实是这样:

我们基本上对复杂性是怎么凸显的存在误解。

我们以为每个功能的复杂程度就像我们开始描述的那样。嘿,也许程序员写代码要花费时间,或者随便程序员做什么,但是商业用语区区几个词就可以完全描述软件的功能,像“用户通过 y 使用 x”,对吧?

这种观点是错的。

软件功能更像是分形。

你离得越近去看,细节就会展现得越明显。

洋葱是分形?

不是,我已经换了比喻。咱们继续。

我们从全局视角来开始描述软件的功能。但是,当构建好 app,或是使用 app 时,是处在一个较小规模下的。它的完成一步一步进行的,每一个步骤都有可能遇到问题。为了解决问题,你可能需要重新设计这一步、添加新步骤、或是增添全新功能。

这就像是规划一条从你家到单位的行程。看地图的话,行程好像是直的。

当你开始从更小的视角来看,你会发现直的路线并不会城市道路网相契合。你会遇到交通站、高坡和道路阻塞。根据步行、骑行或者开车的不同,你的行程路线也会不同。

建立软件很大程度上是一样的,你离得越近去看,对解决方案就能有越细致的认识。

这下好了,一路到处都充斥着细节,还都是我需要考虑的。这是否意味着我的产品永远也不可能做完呢?

这么想也对也不对,之所以复杂性凸显,是因为我们一开始就宏观描述了软件功能,也通常就是要实现的目标。然后我们将细节放大,为实现这一目标而一步步建立解决方案。细节放得越大,就会发现越多复杂的问题。

但复杂性并不是问题所在,问题是我们如何来发现复杂性的。我们把软件功能规格书叫个开发人员,几周过后,我们拿到了第一版的 app 并开始测试。这是我们第一次一步一步操作软件,会从中发现大量漏洞。然后我们做好修订说明,把它交给开发者,让他们再开发第二版 app。

在整个流程的最后一步,我们在多次进行之后,得到了很好的解决方案。

问题是开发周期真的太长了,每一环节都要耗费好几周或好几个月。

但是发现 app 的潜在复杂性又是必要之举。

通过来回反复和开发人员交涉来发现这种复杂性,既耗时又烧钱。

我们想这样做:

我们想在开始写代码之前就尽可能多得发现它的复杂性,将软件层层剥开来,看到一个更加健壮的功能清单,而且想做得又快又省钱。

我们想在软件规格书上来回修改,而不是在app上反复折腾。

我们想从这个过程:

 

走到这个过程:

我们需要两个东西来行之有效地实现这个过程:第一,我们需要一种方式来展示功能清单,以便反复修改;第二,我们需要一种方式来高效地就功能清单进行审核协商。

我们来看看怎么做。

规划功能

我们不想以商业用语来谈,而是像用户一样的身份来考虑软件功能。在这个层面就需要处理软件的复杂性问题了。

首先,列一张用户目标表。你想让用户通过你的 app 获得什么呢?

接下来,你需要规划用户流程,以用户的身份走每一步,来实现用户目标,并记录这些步骤。

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

有很多种做的方式,你仅需为每一步勾勒一个简单的略图即可。你可以为用户走过的每一个界面绘制模型,也可以在纸上或软件上画流程图。

无论你选择哪种方式,确保优先考虑速度问题。除非你是 Photoshop 专家,否则把软件收起来,拿纸和笔画吧。

确保每个界面在你的软件略图中都能够得以体现。比如说,如果一个特定的步骤会经过 app 的好几个界面,那么把该步骤切分开。我们想要梳理出更多的细节,而不是更少的。

这个单独的过程应该将 app 中一些复杂的问题平面化。现在,我们要往更深处挖。

对一切保持疑问

我们要是像之前那样提问的话,范围太宽泛了,无从下手。

首先我们将适用于大部分软件的一些常见问题列到一起,这些问题可以归为四个大类,你可以把它当做框架来组织软件略图。

看着软件略图的每一步,问你自己清单上写的每一个问题。如果答案会展现出一个新的步骤,那就把它添加进软件略图。

清单在这儿:

用户输入

这些问题与用户提交到产品的信息有关

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

如果之前的部分是输入,你可以把这个当成输出。

  • 屏幕上哪些信息是呈现给用户的?
  • 这些信息是以怎样的形式呈现的?比如:文本、图片、地图、清单、图表。
  • 这些信息需要以某种方式进行分类吗?比如:最近使用频率、距上次使用时间、关联性。
  • 产品是不是可以主动对外通信?比如:邮件、推送通知、SMS 消息。
各部分之间的交互

这些问题有关软件体验的不同部分(用户、产品、其他服务)之前是如何交互的。

  • 用户彼此之间有交互吗?比如:收发邮件、加好友、 “喜欢”、或者给其它用户的内容打标签
  • 用户与外部服务有交互吗?比如:付费服务、物流跟踪、社交登陆。
  • 产品与外部服务有交互吗?比如:位置查询服务、天气 API、社交网络(“你的朋友X刚加入了!看看他们的简介!”)
企业家功能

有关你——企业家,需要从产品中获得什么。

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

简直有……数不清的问题。

这就对了!这也真的就是人们在早期开发过程常常忘记的东西。你的产品还有很多特定的问题,随着时间你就会慢慢发现。

把它整合到一起

建立软件略图和进行软件审核的过程可以让你知道少了什么东西,这个过程重复几次之后,你就能更自信得拿出一个 非常可靠的功能表 了。

你知道,我真的很希望通过这种好像挺奇怪的诀窍,可以使项目得到修缮。听上去工作量还蛮大的。

的确。但这是你在过程中的某些点上,无论如何都必须要做的工作。

记住我们为什么要这样做。你无论如何都要找到软件功能所潜藏的复杂性因素,你要做的就是选择何时来将洋葱层层剥开。

基本上来说,有两种选择:

  1. 根据用户找准开发目标,对此建立模型或者流程图,对自己的假想保持疑问态度,并且像我们上面所做的那样将软件层层剥开。或者,
  2. 让开发人员直接开始开发软件,然后根据每一版暴露的问题一次次改版,每改版一次就要花一周时间。几个月后,你通过改版会发现很多问题,而这些问题和你本在一周内用纸笔就可以搞定的问题一模一样。

所以这让软件项目变得复杂到爆,恨不得能一下子将你生吞活剥。

所以,去发掘功能吧,建立软件略图,对自己的假想保持疑问态度,以既迅速又省钱的方式发现软件存在的主要问题。

让自己从压力和痛苦中解脱出来,放手让产品走向外面的世界,让它恣意绽放。

难道洋葱也会开花绽放吗?你的隐喻太蠢了。

噢说得好。

如果你觉得这篇文章挺有用,可以帮我分享它!也可以订阅我的邮件,确保不错过我的下一篇文章。

2 4 收藏 3 评论

关于作者:dimple11

简介还没来得及写 :) 个人主页 · 我的文章 · 15

相关文章

可能感兴趣的话题



直接登录
最新评论
跳到底部
返回顶部