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

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