不懂這三要素,專案怎麼可能低風險?(下)


    [承上篇]

    該從哪裡開始找風險?誰來找?

    實務上,我們通常都會選一個舊專案,來當作新專案的參考基準,然後再以這個基準來新增或是修改部分的功能,以產出一個新的產品。例如,iPhone7會以iPhone6為基準,然後加上更高畫素的鏡頭、雙鏡頭、新CPU等。要找出這個新專案的風險,首先該從哪裡著手呢?

    最直接簡單的方式,就是把新手機和基準手機的硬體規格和軟體功能都拿來做個比較表,接著請各領域的專家(這是關鍵),從差異處一一地評估分析可能的風險點。這個比較表,我們通常把他叫做「Diff(英文difference的暱稱)table」。

    硬體差異的部分,一般我們會用BOM(物料清單 Bill of Material)來做比較,看看有哪些零組件是不一樣的。然後請相關的軟、硬體研發團隊,一起協同合作,分析這些差異點。經驗淺的團隊成員,大約只能做到這種程度。而經驗豐富的老手,還能夠從這些差異點,進一步深入看到它們之間,甚至是它們和沒被更動的元件之間的隱性相關性,而這個部分的潛在風險是否能夠被及早地挖掘出來,並加以處理,往往是日後專案順利與否的關鍵所在。

    另外一個做Diff分析的關鍵重點則是「軟硬體研發團隊的協同合作」。因為這樣才能夠以用戶從操作軟體介面的角度,來把整個全貌都考慮到,而不是僅僅以硬體的觀點來評估風險。例如,「使用者介面的反應靈敏度」就非常不容易從硬體元件分析的角度察覺出來。

    如果從這些差異點發現到有任何的不確定、沒把握,就必須將這些地方全部列管,同時設定驗證完成的檢核時間點來限時追蹤。說的好像很簡單,其實這裡有個關鍵就是,怎麼描述這些風險才會讓溝通和管理有效率。這就得用到上篇文章所提到的三要素了。

    風險描述怎麼寫?

    以iPhone7來舉例,因為要提供更多的照片畫素,以及提供新的景深應用效果,它的相機晶片理應跟它的參考基準iPhone6的晶片會有所不同。那麼,負責相機晶片驅動程式的軟體設計工程師,就會和邏輯電路設計工程師、以及光學設計工程師們一起做風險評估,看看相關的硬體規格配置可不可行,在使用者操作的體驗層面會不會有什麼問題。

    同樣是拍一張照片,i7每張照片的資料量可能會是i6的好幾倍。那麼,即使是不做任何的預處理,光是把照片的資料從相機晶片取得,然後直接儲存到記憶卡,就「可能」會有「瓶頸」產生了!因為,原本i6的記憶卡的儲存速度可能根本就跟不上i7新相機晶片吐出資料的速度!

    這就好像,原本的馬路設計只有二線道(i6記憶卡的存取速度),能處理的車流量(照片資料量)較少,但是因為車流量不大(i6照片資料量較小),所以也就沒有必要花錢(多花專案成本)拓寬馬路為四線道。現在車流量變大了(i7照片資料量變大),而且還是個常態,如果還是維持二線道,那當然就會開始堵車了(在拍照時,手機介面操作可能就會變得卡頓)。

    「資料來不及存入記憶卡」就是這個「馬路可能塞車」的不確定事件(Event),它發生的機率有多高(Probability)則可以根據過去的專案記錄來做查詢和判斷。萬一這個事件成真(風險確定發生,成為一個問題),對專案的影響顯然是「無法出貨」(Impact/Effect),因為這些新的照相功能是i7的主要賣點之一!因此可以說,整個專案的所有專案目標(Objectives)都會被此風險影響到,是個非常嚴重的後果。所以,這個「資料來不及存入記憶卡…」的這個風險不但機率高,影響又大,一定就得用高優先序來處理它。

    「更換相機晶片為新元件」這個原始原因(cause),是一個事實(fact),它不必然會造成「資料來不及存入記憶卡」這個事件(event)。而這個事件,也不必然會造成專案目標的變異影響。然而,「更換相機晶片為新元件」卻是個幾乎無法改變的事實,除非是這個風險無法被處理乾淨(可以出貨),否則,幾乎就不可能去考慮改變這個事實。

    講到這裡,這條風險就可以這樣來描述:
    • 因為「更換相機晶片為A公司的XXX新元件」的原因(Cause),
    • 過去記錄有80%的可能(Probability),會產生「資料來不及存入記憶卡」的事件(Event),
    • 一旦這個事件確認成真,新照相功能將無法實現可用(Effect1:範疇目標影響),專案將無法準時出貨(Effect2:時程目標影響),專案成本也將超支(Effect3:成本目標影響)。

    清晰、具體的風險描述才能讓團隊聚焦

    看到這樣的風險描述,我相信不論是誰都會同意,專案需要立即安排最強大和充足的人力和相關資源去處理這條風險了。這些額外的工作,也就是所謂的風險回應措施(計畫),也才會適時(用得及時)、適所(用在對的地方)。

    一個清晰、具體,套用簡單Cause、Event、Effect三要素的風險描述,才能讓團隊聚焦,有效率地消滅或減輕專案的風險!(全文畢)


    [承上篇]

    圖片來源:twoicefloes.com