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 回到自己的桌子邊，開始繼續干活兒。
拿著一堆資料，回到自己的工位前，整個人都要陷入到怠惰的情緒里面，癱坐在電腦椅上糾結了起來。信息太多了，不知道從何做起。在網上一搜也是成堆的內容，根本不知道從何入手。懵逼了。
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.gerard.com.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務。