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

2018-9-5 泥人张 设计管理与成长



如果您想订阅本博客内容,每天自动发到您的邮箱中, 请点这里


在 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,我们的大客户要求这个今天上线,能不能把你的项目放一边,帮我们把这个产品弄上线?」这也是一个反面案例。拒绝。


蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计  cs界面设计  ipad界面设计  包装设计  图标定制  用户体验 、交互设计、 网站建设 平面设计服务

 




Powered by emlog 京ICP备12006971号-1 sitemap