比起設計和開發流程的選擇,還有幾個事情更重要 - 優設網 - UISDC

比起設計和開發流程的選擇,還有幾個事情更重要

2018/09/04 10127評論區

在 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,我們的大客戶要求這個今天上線,能不能把你的項目放一邊,幫我們把這個產品弄上線?」這也是一個反面案例。拒絕。

非特殊說明,本文版權歸原作者所有,轉載請注明出處
本文地址:http://www.dbw33.com/product-design-agile-waterfall

發表評論 加載中....

評論加載中....

uisdc

評論區都快餓癟了,看看我期盼的小眼神...

設計圈干貨 界面設計 排版布局 版式設計 職場 優設專訪 優設大課堂 設計師干貨 設計達人 配色 web前端開發 視覺設計 素材下載 AI教程 設計理論 設計流程 神器下載 字體下載 設計師專訪 psd下載 海報設計 設計規范 設計趨勢 用戶體驗設計 動效設計 logo設計 平面設計 圖標設計 ICON 產品設計 神器推薦 App設計 字體設計 職場規劃 酷站推薦 交互設計 ui設計 優秀網頁設計 設計師職場 ps技巧 酷站 用戶體驗 PS教程 網頁設計 經驗分享

您還沒有登錄

優設啟用更安全省心的 微信掃碼登錄

微信掃碼

300萬設計師聚集地!優設網是極具人氣的設計師平臺
2012年成立至今,一直專注于設計師的學習成長交流

把好文章收藏到微信

打開微信,掃碼分享
學設計 優設網 在這里

久播电影网伦理片