敏捷方法的成功密技(二):專案管理的「溝通斷層」


    在上一篇文章《敏捷方法的成功密技:Scrum 為何對你很重要?》中,我們談到了Scrum這個在敏捷開發方法中頗受歡迎的一派,也談到了敏捷式與瀑布式,在產品開發和專案執行成功率上的巨大差異。可是,既然這個東西這麼讚,又簡單易懂,那為什麼還是有很多公司和組織在導入這個方法的時候,不盡人意,東卡西卡的,無法體驗到敏捷法的巨大好處呢?

    在談Scrum方法的架構和元素之前,我想為非軟體產業的朋友們打個基礎,先快速簡要談一下,軟體到底是個啥東西(雖然每天都在使用它,可是卻不一定真懂它),你就會理解到為什麼Scrum會先在軟體產業被廣泛應用起來。

    軟體的本質到底是什麼?

    這世界上的任何一個「系統」,目的都是要產出「成果」,而要有「成果」這個輸出(例如,一個產品),就必定會有輸入(例如,實的原物料、虛的邏輯智慧等),輸入和輸出之間就必然有一些流程和工具,來轉化輸入成為輸出。

    對一個軟體產品而言,「輸出」是什麼(這裡我們不談光碟片、包裝盒等實體物,只談那種可以被到處複製、貼上的軟體檔案)?「輸出」不過是一大堆的01的資料組合,平常就是用「檔案」這種東西打包在一起,儲存在你的電腦內(別懷疑,雲端軟體也是有一大堆的檔案,只是你看不見罷了)。

    等到需要的時候,這些檔案內01的資料,就會丟給電腦的硬體電子零組件(就是數十、數百億計的電晶體,分布在不同的IC晶片內)。每個電晶體就是一個小開關,而我們只需用01去控制它們,讓它們以光電的速度解讀這些01的資料,決定要開還是關,然後電腦就會做出一大堆神奇的動作。像你現在在看這篇文章的時候,其實背後早已經不知道有幾十幾百個億,甚至上兆的01的資料被處理完了呢!

    如果你是一位即將花錢請人開發軟體的客戶(Customer),或是一位會實際使用這個軟體的用戶(User),或是兩者同時兼具,你該如何向負責開發這個軟體產品給你的團隊,精確描述你想要電腦呈現出來的畫面和互動,開發團隊才能夠「抓得住你」,不誤解做錯,或者誤會做偏掉呢?

    試想,連日夜相處多年的夫妻之間,溝通都常常會有誤會了,那你怎麼能期待,一個跟你素昧平生的開發團隊,能夠完全了解你的心意,滿足你的需求,而且還常常只是些虛無飄渺的需求呢?

    不像其他非軟體類產品,有實體可見、可觸之產出,這其實就是軟體產品開發最難、最痛的地方!輸入(需求)和輸出(產品)之間,總是有一些大大小小的鴻溝。而且,通常這個鴻溝都還蠻大蠻深的!

    溝通斷層

    傳統的軟體開發方法,通常都是你口述,或寫些很模糊的需求文字(因為,其實你自己也常搞不太清楚你自己想要些什麼),了不起再多畫一些草圖,軟體產品開發團隊則會有位代表,把這些東西「消化」之後,紀錄成為所謂的「需求文件」。


    接著,這位代表以為他/她真的「完全懂你、完全代表你」,就回去把這需求文件交給軟體的實做團隊,而實作的開發團隊也真心以為他們懂你,因為需求文件寫得很清楚、很具體,於是就搞個幾個月、大半年的,最後交出一個你看了馬上會傻眼的東西。

    上面的情境中,那位跟客戶談的代表,可能是一兩位組織中的商業分析師(Business analyst)、系統分析師(System analyst)、產品經理(Product manager)、或是UX設計師(使用者經驗設計師)這一類客戶窗口的組合。在小型組織當中,也可能是由專案經理(Project Manager)來兼任前述的部分職務,而真正產品的實作團隊(架構設計師、軟體工程師、測試工程師等),其實是不太有機會直接面對客戶談需求、了解需求的。不僅如此,實作團隊還往往只能(或者是「只願意」)透過需求文件,來和這些客戶窗口們做溝通,理由是「要分工」、「權責要清楚」等等。

    問題的核心其實就是在這裡!怎麼說呢?

    在商業行為不複雜的古代,人和人之間的溝通其實很簡單,因為產品通常並不複雜。然而,現代社會的各種產品需求,早已複雜到無法以個人或小團隊來因應。也因此,組織愈形巨大,分工愈形細緻,早已成為一個新常態。

    然而,客戶(或用戶)的需求透過層層組織(或人員)之間的轉化、口述變文字的轉換,再加上時間對記憶的侵蝕淡化,當初客戶(或用戶)口中栩栩如生的諸多重要細節,到實做開發團隊手上之時,早已灰飛煙滅,無影無蹤。我們就來把這個現象命名為「溝通斷層」好了

    你可能會問,那為何不把所有跟客戶的對談細節全都寫下來呢?相信我,沒有一個人可以「單獨」做得到,時間的限制也不會允許你這樣做!你可能又會說,那為何不把所有跟客戶對談的過程都錄影下來呢?相信我,不會有人想要看這種沒有萃取過的原始資訊,因為那將會耗費太多的時間和心力!

    那到底該怎麼辦,才能在有限的時間和精力之下,有效解決這種「溝通斷層」的問題,讓需求能在最後被「忠實呈現」在產品之中呢?而且只有真正能對客戶、用戶,和開發組織產生價值(就是可以賺錢或省錢啦)的需求,被納入在產品之中呢?敏捷方法中的Scrum於是就應運而生了。

    待續

    更多相關文章:《敏捷方法的成功密技》系列文章總覽