比起设计和开发流程的选择,还有几个事情更重要 - 优设网 - UISDC

比起设计和开发流程的选择,还有几个事情更重要

2018/09/04 10167评论区

在 Sarah 给 Jimmy 讲完了她在设计上的一些原则之后,Jimmy 就准备开始重新设计那个客户等着要的新的仪表盘界面了。与此同时,他所在的公司 Shmuckle 准备设置一个新的产品经理的职位,并且将会在公司内部选择合适的人员来任职。Jimmy 对此非常有兴趣,实际上,在当前的架构下, Jimmy 是一个非常合适的候选人。但是要担任这个职位,他必须证明自己能够胜任这个职位,证明自己知道如何管理项目和团队。

对于他正在做的这个控制面板的设计项目,他也正在挑选合适的产出流程。用敏捷(Agile)开发流程更好,还是应该用瀑布模型(Waterfall Model)?又或者是循环式开发流程?他觉得跟开发部的同事聊一聊会是更好的选择。

当他找到工程部的 Boris 的时候,他正在楼道里刷推特摸鱼。「用什么流程?那还用问,当然是敏捷啦。这个最好,过程清晰简单,现在没有什么办法比敏捷更好处理各种数字产品的设计和开发啦。」接着,Boris 去隔壁会议室拖出一个白板,并且说道:「给我一个小时,我告诉你关于敏捷开发的一切。接着还能捎带计划一下每周的工作内容,这样你就能完全明白要干啥了。哦,差点忘了,还有几个播客和视频可以帮你更加深入地了解敏捷。」

敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

絮絮叨叨的 Boris 终于找到一个倾诉的对象,Jimmy 一时之间感到颇为尴尬,不知道如何回应。好在这个时候,开发部另外一个部门的 Floris 从门口路过,Jimmy 赶紧喊住他「Floris 我到处在找你,你怎么在这儿啊」说着就拉住 Floris 的手,窜进了另外一个办公室,远离了热情的 Boris。

「干啥?你俩在聊啥?」

「Boris在跟我说敏捷开发……」

「啥玩意儿?他跟你讲敏捷开发?快拉倒吧,他们部门里面唯一敏捷的就手头上的 Macbook。我们这边都用瀑布模型来作为产品开发的流程,因为它是线性的,有着更简单的结构,操作起来也简单,很少会发生混乱。」说着,Floris 从办公室的书架上摸出一堆文档压到 Jimmy 手上。「你要的东西都在里面,祝你好运。如果你需要任何帮助,请在公共的平台上跟我约时间,我们可以开个小会解决一下问题~」说着 Floris 回到自己的桌子边,开始继续干活儿。

瀑布模型(Waterfall Model) 是一个项目开发架构,开发过程是通过设计一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题,那么最好「返回」上一个阶段并进行适当的修改,项目开发进程从一个阶段「流动」到下一个阶段,这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。

拿着一堆资料,回到自己的工位前,整个人都要陷入到怠惰的情绪里面,瘫坐在电脑椅上纠结了起来。信息太多了,不知道从何做起。在网上一搜也是成堆的内容,根本不知道从何入手。懵逼了。

Jimmy 决定采用最终的备用方案——万事不决问 Sarah。在 Jimmy 的工作经验当中,老领导 Sarah 总能给他靠谱的建议和可行的方案。

出问题的时候,先后退一步

Sarah 办公室的门从来都是敞开的。当 Jimmy 来找她的时候,Sarah 正在阅读一些有意思的东西。她的办公室里面有很多的书和绿植,漂亮的色彩让 Sarah 的整个工作区域仿佛能够唤起人的创造力和想象力,桌上打开的书页散发着油墨的味道,闻起来让人很有安全感,像家里的书房。「Hey,Sarah,我又有问题来麻烦你啦,你有空么?」

「我的门永远敞开着。这次有啥问题,看看我能怎么帮到你。」Sarah 听到声音就知道是谁,一边放下手头的文档,一边抬头笑着看到略显局促的 Jimmy 。说话间,Jimmy 非常熟悉地跑到办公桌另外一边的椅子上瘫坐下来,Sarah 笑着摇头,拿起咖啡壶给 Jimmy 倒上一杯咖啡。

回到自己椅子上的 Sarah 没有看自己的电脑,而是像心理咨询师一样,盯着 JImmy ,进入了等他倾诉的状态。而 Jimmy 此刻也惊讶于 Sarah 如此洒脱迅速地放下手头的工作,并专注地帮助自己,于是也不再放飞地瘫坐着,直起腰身,开始认真地陈述自己的问题:

「实际上,你之前跟我说的设计原则,让我获益匪浅。我按照你告诉我的方法,找到了症结,解决了问题。但是我现在不仅仅是要设计这个仪表盘界面,我需要开发和实现。有人说敏捷开发比较好,有人说瀑布模型很给力,这些开发方式到底有啥差别,优势具体在哪我并没有搞清楚。有人说我需要的是敏捷开发里面 Scrum,还有人说,它实际上是 shmum,也有人称之为 Bshmum,结果还有朋友告诉我说 Google 的 Design Sprint 才能帮我解决问题。我感觉脑子快要炸了。所以……Sarah 你明白么,我需要帮助了。 」

听到 Jimmy 说到后面,Sarah 就明白了他碰到什么问题了。「Jimmy,没事儿,我们总会在某些时候碰到问题,别人的指导总会派上用场。」

「我可以理解,如果在网上搜索这些相关的信息,会有太多杂乱的内容让你感到信息过载。幸运的是,如果你理解这些东西背后的基本原理,就可以相对轻松地梳理清楚所有的内容了。」

「早知道我应该一开始就来找 Sarah 问问。」Jimmy 不由得对自己抱怨了一句。说着,他在摸起咖啡杯旁边的纸和笔,准备做笔记,就像上次那样。Sarah 看穿了他的小心思,笑道:「不用记。」说着,喝了一口咖啡,然后继续道:「先想想看,我们为什么会有敏捷、瀑布模型、冲刺模型,为什么要用循环工作法呢?」

「为了高效?」Jimmy 下意识挠头。

「是的,但也不完全是这样。总的来说,我们需要一个过程来呈现产品,因为人类的思维是没有办法直接掌控混乱的事物。此外,一个清晰的、可遵循可记录的流程,能够确保你在完成后,确保产品的整个开发过程是可交付的,细节也是可回溯的。这就是为什么,我们需要这些流程。」

「最首要的问题,不是选择哪个流程,而是要了解这些流程为什么而存在,以及我们可能会碰到什么样的问题。无论你选择哪一个。」Sarah 看了一眼窗外,继续说道:「你有问过公司的其他的同事,他们都遵循什么样的流程么?」Sarah 问道。

「问过了,绝大多数都采用的敏捷和瀑布模型。」Jimmy 说到。

承诺是关键

「首先要告诉你的是,两种方法都很棒。但是绝大多数的公司只会在两种方法当中选择一种。因此,当人们采用敏捷或者瀑布的时候,我们更多看到的是他们所做的设计或者开发的小冲刺。以往,我们会看到团队会在3个月或者半年这样的时间尺度当中,一直保持着高强度冲刺的状态的。在旁观者眼中,会看到一个清晰的故事,或者说整个产品逐渐设计或者开发出来的景象。如今流行的做法是将冲刺划分为很多不同的阶段,这也是为什么如今被称为小冲刺。不过本质上,做的事情和内容并没有改变。」

「另外,很多人会使用敏捷的方法来做项目,过程中会不断的迭代修改。他们希望通过这样的方法来获得更好的结果。实际上,很多团队会持续不断地、长期地坚持这么做,几个月甚至一年半载都没有发布任何东西。如果你在这种情况下,会问自己,到底出了什么问题?我会告诉你,原因在于没有清晰的承诺,以及太多的事情让人分心。大家都不会承诺在一段时间内交付一些东西,使用各种借口不按时、按预算来完成项目。」

「如果这个时间只是一两周,一个月,好吧,或者说一年,这个周期并不重要。重要的是,你不需要拥有一个清晰的过程,并且承诺提供一些东西。当然,这是很有挑战性的。这意味着,在这个情况下,你必须作出一些选择,来完成任务。」Sarah 总结道。

阻碍前进的东西

「到底使用哪种敏捷的方法,采取多少个步骤,或者使用经典的瀑布模型,借助谷歌的设计冲刺,都可以,都没有问题。大家总会认为,采用哪种过程是关键,但是现实是,这个过程始终都只是达成目的一个手段而已。」

「真正的问题在于,人的天性是懒惰的,没有按照承诺交付东西。总是忍不住的拖延,膨胀的自我,办公室政治,爱来事儿的甲方,喜欢变卦的客户,它们还都会像拦路虎一样进入产品和设计的流程。无休止的辩论,不断改变的策略,不断膨胀来回拉锯的会议,最后你只能呆滞地坐在办公室当中,想想自己的生活到底出了什么问题。最后,我想说一下多年前,我自己所经历的一个项目。」Sarah 觉得她应该从具体案例上来说说这个事儿了。

「所以,首先你应该清楚,在一个特定的时间段内,交付一些东西出来。你要保证你的团队不会跳票和拖延,也不会让预算超出计划。你将要在约束中工作。约束其实是一种隐藏的优点,也许并不是每个人都明白。你需要完全保持专注,除了你的和参评之外,不会被其他的任何东西分心。就你的情况而言,你需要专注于这个仪表盘界面的设计和实现。」Sarah 说道。

「团队的规模很重要。不过那是后话,后面咱们再仔细聊。」

「假设,你有一个三个人组成的团队,他们共同负责开发并发布你的产品的下一个功能。具体到你的头上,就是为你开发并实现这个重设计的仪表盘。你需要确保公司的其他人不会前来干涉他们的工作,不会来和他们讨论这个项目以外的任何事情。」

「这一点极为重要。他们必须保持专注。减少被打扰的机率——或者说不被打扰是最好的事情,他们能够专注而清晰的思考问题。除了手头的任务之外,他们不会需要去做其他的任何事情,不会被其他的工作内容所分心。对于如何做手头的工作,什么时候做,具体做什么,他们应当有足够的控制权和自主权。最后,请记住这一点:

团队必须足够小。如果太大,沟通问题一定会成为主要的障碍。每增加一个人,想让大家信息和想法保持一致的成本,就会成倍增加。如果你拥有太多的自由,太多的资源以及大量的人员,你不仅会得到过度的设计,超出常规的工作,需要超出计划的预算,以及一个没有重点,不够出彩的产品。」

问题总是会出现的

「如果你像我说的一样,后退一步来看问题,就会意识到,流程背后所存在的问题,并不是流程本身的优劣,也不关乎公司、人员、国家、文化或者其他。这是关于纪律和约束。不仅是团队本身需要纪律,负责人要有纪律感,业务也需要有纪律约束。如同我们所知道的,团队也好,产品也好,公司也好,它都是自上而下的,顶部的纪律、约束和眼界,决定了底部的纪律、调性和产出。」

「现在,你可能会问自己,如果你的项目出现了问题,会怎么办?那么首先,对于你想要达成的目标,需要一个清晰的愿景或者想法。除非你的愿景和目标足够清晰,否则你是没有办法来提供承诺的。在项目开始之前,这个愿景/目标必须有足够清晰的定义,是否能够达成,难度高低,是否具备可执行性,否则在过程中一定会有所偏离。在这里,给你几个小贴士,务必要记住:

不要自欺欺人,你需要提前计划好整个项目,避免出错。很多事情都会出错,所以你需要有目标有愿景,你需要向着目标前进,并且随时做好解决问题、纠偏的准备。一旦你被其他的因素影响,就很容易增加开发时间、增加预算、招募更多的人手。不要相信所谓的规划和蓝图,那什么都不是。问题是一定会出现的,出错了,就专注于最终目标,抓紧手头的项目,别无其他。」

Sarah 说道这里,Jimmy 已经开始有所思考了。「所以,在我告诉你这些事情以后,对于你你手头的这个仪表盘的项目,你打算下一步要怎么做?」

需要始终牢记的事情

Jimmy 的脑中仍然在反思 Sarah 刚刚说过的话,下意识回复道:「要有远见,目标清晰,为即将出现的错误与问题做好准备,组建一个足够独立的小团队,和公司其他的团队和部门隔离开来,这样可以在不被打断的情况下聚焦于当前的任务,最重要的是,要在承诺的日期前交付承诺的产品。但是我不知道团队要有多小,我应该带多少人?」Jimmy 问道。

「如果我说我知道你要带几个,那么我一定是在骗你。不过,通常而言,你这种规模不算太大的产品,我建议控制在3人以内。你是这个项目的主管设计师,也是产品经理,在设计上已经没有大的问题,你还需要两个开发人员,一个负责前端,一个负责后端,这样足矣。」Sarah 回答道。

「那么我应该花费多少人在这个上面呢?」Jimmy 又问道。

「这个是你的项目,时间应该由你来衡量。不过,你需要一开始就清楚你手头有多少资源,你有多少时间来投入这个项目,有多少可供调用的预算,以及管理团队的耐心达到了什么程度。而且,这个事情最关键的并不是时间,而是你的承诺,以及到达约定时间之后要交付的东西。这不仅是对上层的责任,对于你和你的项目而言,也是一个可供奋斗的目标和清晰的边界。你的项目看起来并不算小,这个人员工作量之下,可能需要花费一个月的时间来进行开发。但是请记住,在一个月的时间内,你必须提交出一个可用的产品出来。从我的角度上来看,我是不允许增加预算和时间的。约束对双方其实都是有利的。」Sarah 说道。

「那么我还是想问最开始的那个问题,到底应该使用敏捷还是瀑布模型?」Jimmy 还是忍不住问道。

「我不知道。」Sarah 坦言道:「你的项目应该由你来决定。对我而言,选择哪个流程其实并不算最重要的问题,相反我刚刚说道的,流程之前的种种问题才是最重要的,关于承诺,团队的构建和管理,这些因素产生的影响更为深远。如果你清楚的知道最终要产出的产品,流程就仅仅只是手段了。」Sarah 笑着总结道。说话间,她伸手去拿之前没看完的文档。「谢谢,Sarah,」Jimmy 笑道:「你好像又救了我一次。」说着 Jimmy 走出了Sarah 的办公室。

「我的门一直都敞开着。」Sarah 低声说道,走远了 Jimmy 大概并没有听到这句低语。

结语

在设计和开发数字产品的时候,每个团队的负责人可以选择自己习惯的或者自己青睐的流程和方法。使用什么样的方法无关紧要,在未来10年,我们可能还会碰到更多的新方法,新的策略。而唯一不变的,始终还是最基本的问题,团队,承诺和交付。

我注意到,有人把产品所使用的敏捷和瀑布模型这类流程称为「项目的上帝」。但是实际上,不管哪种流程,依然会陷入无休止的扯皮会议和无意义的辩论,出现了问题之后,开始修改时间表。「我们无法按时完成功能A,因此我们无法开发模块B,开发人员又需要参与下一个项目,因此我们资源是不够用的,所以呢,这个项目不得不停一个月。」这情况很常见,也是典型的反面案例。

我相信,产品团队应该高度专注于当前的产品,和其他产品的需求、各种无关的事务隔离开来。「Hey,Angela,我们的大客户要求这个今天上线,能不能把你的项目放一边,帮我们把这个产品弄上线?」这也是一个反面案例。拒绝。

非特殊说明,本文版权归原作者所有,转载请注明出处
本文地址:https://www.uisdc.com/product-design-agile-waterfall

发表评论 加载中....

评论加载中....

uisdc

评论区都快饿瘪了,看看我期盼的小眼神...

界面设计 设计圈干货 排版布局 版式设计 职场 优设专访 优设大课堂 设计达人 设计师干货 web前端开发 配色 视觉设计 素材下载 AI教程 设计理论 设计流程 神器下载 字体下载 设计师专访 psd下载 设计规范 海报设计 设计趋势 用户体验设计 动效设计 logo设计 平面设计 图标设计 ICON 产品设计 神器推荐 App设计 字体设计 职场规划 酷站推荐 交互设计 ui设计 优秀网页设计 设计师职场 ps技巧 酷站 用户体验 PS教程 网页设计 经验分享

您还没有登录

优设启用更安全省心的 微信扫码登录

微信扫码

300万设计师聚集地!优设网是极具人气的设计师平台
2012年成立至今,一直专注于设计师的学习成长交流

把好文章收藏到微信

打开微信,扫码分享
学设计 优设网 在这里