敏捷方法的成功密技(三):Scrum 如何擺脫「產品客戶不愛,團隊熱情不再」的窘境?


    在上一篇文章《敏捷方法的成功密技(二):專案管理的「溝通斷層」》中,我們談到了為什麼客戶/用戶的需求總是這麼難捉摸,為何我們要先談這個問題呢?

    理由其實很簡單,在這個溝通的鴻溝沒有被妥善處理、弭平之前,所有後續的努力與投入都會事倍功半,形成「產品客戶不愛,團隊熱情不再」這個賠了夫人又折兵的窘境。那該怎麼做才能「盡可能」地弭平這個溝通鴻溝呢?(注意,我沒說能完全弭平!)

    從猜測開始

    除了標案之外,很多時候,我們其實並不知道我們的客戶/用戶是誰。我們之所以會「知道」客戶/用戶是誰,其實那是因為我們在「猜測」而已。那我們為什麼要猜測呢?因為,不猜測的話,後面的產品規劃、開發,就無法繼續進行下去!

    好,既然是一種猜測,那它就是一種「假設」(Assumptions),而「假設」是需要被「驗證」的(Validated),而且「驗證」是會被期待要「快速」、「有效」、「省錢」的!

    相信你我都曾經在學校裏頭做過實驗吧?做實驗,不都是先有個「假設」,然後去想辦法證明這個假設為「真」嗎?可是,實驗結果不都往往反而證明了原先的假設是錯的嗎?所以,我們才會被「失敗為成功之母」的諺語不斷地洗腦嗎?

    可是,各位發現了沒?當我們進入職場之後,這句洗腦諺語早已被我們拋諸於九霄雲外去了。不論是已經當主管的自己,或是我們自己的長官,竟然總是期望團隊能一次就猜對目標客戶/用戶(Target Audience)、一次就做出啵棒的功能,讓客戶/用戶滿意到,不但會馬上掏腰包購買,還會幫你做口碑行銷?

    這就是多數傳統式產品開發和專案管理的現況,期望一次就做對!

    發明大王愛迪生,光是找適合做燈泡的燈絲材料,就實驗失敗超過五千次以上,然後才「賓果」,發明了可實際商轉的電燈泡!愈是突破性、革命性的產品或功能,所會遭遇到的失敗也往往愈多、愈頻繁。要做出能讓客戶/用戶真正熱愛的軟體功能或產品,也不比這個簡單,因為人心的確很難測,尤其是在客戶/用戶不明的情況之下,更是如此!

    如果要我用一句話來說明Scrum是什麼的話,我會這樣來下定義:「一種可以讓團隊有重複實驗、不斷地從小失敗中學習、修正,最後達至大成功,的一種方法和架構」!

    重複實驗

    所謂的「實驗」,對軟體開發團隊來說,就是要釋出(release)一個成果(可能是一版軟體更新,或是一些操作流程畫面示意圖),給我們猜測的客戶/用戶去實際體驗看看。如果客戶/用戶認為這個成果並沒有辦法解決他們所面臨的問題(TA假設正確,但功能假設錯誤),或是這個成果他們根本就沒興趣要(TA假設錯誤),那麼,這個成果即驗證了實驗的失敗。

    然而,團隊可以從這個失敗當中學習到一些東西,可能是TA假設錯誤(例如,男生),必須回頭重新做TA的假設,可能是另外的一個用戶族群(例如,女生),也可能是功能假設錯誤,必須從客戶/用戶的實際操作體驗之中觀察、訪談,引導挖掘客戶/用戶內心的真實感受,以作為下次實驗的修正依據。

    就是這樣,讓團隊能周而復始地重複實驗,以逐漸逼近最合適的TA,逐漸完善產品或功能的問題解決方向和完整度。

    同時,為了能夠讓團隊保有節奏感,每個釋出release)的週期會被固定下來,而且在整個專案的過程當中,都不會更改,這個週期就叫做衝刺Sprint)。衝刺的持續時間,通常會被定義為2-4週不等,視專案的複雜度、客戶/用戶的急迫性,以及產業的變化速度而定,並無一個標準答案。

    小失敗

    為什麼衝刺的時間要訂得這麼短呢?

    因為,如果能愈快釋出成果去驗證假設,專案的成本就會愈低!如同上方我們談的,實驗是個有十賭九輸特性的玩意,因此,用儘可能低的代價(時間、金錢),去驗證假設為「否」,讓藏匿的「真」趕快浮現出來,其實才是最划算的做法!

    既然衝刺的持續時間為2-4週不等,那麼,每個衝刺結束後所產生的成果,也就不可能是太大的規模。保持衝刺輸出的成果小規模有什麼好處呢?

    好處就是,當我們遇到小挫折和小失敗的時候,我們通常可以平心靜氣地理智對待它,從中吸取教訓,繼續前進,而當我們遇到大挫折之時,我們往往會遭受驚嚇,不知失措,士氣一蹶不振,甚至是無法從這個大挫折中走出來,重新振作。

    因此,Scrum衝刺週期安排,就是讓團隊在很短的時間之內就能完成一個小實驗,驗證這個小實驗的假設到底正不正確,又該如何修正,以進行下個小實驗。

    大成功

    每個衝刺都有一個事先規劃好的「目的」,這個「目的」就是這個實驗的「假設」,例如,這個衝刺的輸出成果,是要驗證它能否真的解決客戶/用戶的某些問題。

    當我們透過一個個連續的衝刺,輸出了一個個的成果,給客戶/用戶一個個驗證過之後,有些「賓果」(做對了),有些做錯了再修正,這些「賓果」的小成果,就會一直累積成為一個大成果,而這個大成果就是能為客戶/用戶真正解決問題的完整解決方案了!

    如果當初團隊為每個衝刺所做的假設,是有依據重要性來排序過的,那麼最重要的假設,可能是個技術可行性風險評估,會被最早驗證完畢,整個專案的成功率也就很快地大幅提升了。

    即便是放在最末端最後驗證的假設,因為專案時程限制的關係,需要被丟棄不做,整個專案之前所累積的各個小成果,其實也都可以完整出貨,為客戶/用戶解決問題,創造價值了。而組織本身,當然也就受益於這個專案所創造的價值了。

    說到這裡,其實專案已經獲致大成功了!

    待續...

    圖片來源:http://kingofwallpapers.com

    相關文章: