DMA01
什麼是風險管理?

什麼是風險管理?

What is Risk Management?

寓意科技

談數位管理的風險,是人人皆不想提的議題,但在這個時代,只要是想要運行或開發任何內部外部的資訊平台,就一定會有風險的發生,這邊將風險的影響力分成低中高,讓大家可以針對風險做一個初步了解。

談數位管理的風險,是人人皆不想提的議題,但在這個時代,只要是想要運行或開發任何內部外部的資訊平台,就一定會有風險的發生,這邊將風險的影響力分成低中高,讓大家可以針對風險做一個初步了解。

數位管理有哪些風險?

低:上線時程Delay、預算爆表、局部功能失效、工程人力更換頻繁、架構雜亂導致功能互相牽連出錯

中:關鍵流程資料結構出錯、結構設計錯誤、採用錯誤的技術元件

高:資安漏洞或管理失誤造成資料毀損或被竊取、委外開發但全案程式碼皆無法收回、被工程團隊勒索

 

低程度的風險 - 最表面的問題

上述列舉的風險,相信作為數位管理者一定都會遇過,低程度的風險肯定是遇過的,上線時程Delay往往是第一個會遇到的,畢竟很多預計的時間跟實際發生的時間總是會有落差,不想Delay,成本控管絕對是第二個容易遇到的問題,畢竟現在大多的平台開發,過程需求變更是十分頻繁,因為大量運用外部API的過程,也是常有可能遇到外部環境改變,比如說API更新等等,造成需要多花時間或人事成本去處理,這兩個問題應該是專案管理上最常遇到的。

 

要防止以上兩點,基本上不太可能,除非可以阻止一切外在的需求變更狀況,不過基本上以現在數位網路的更迭速度,恐怕是有些難度。很多人認為,透過敏捷開發的方式,便能根治這些問題,這種觀點絕對是不正確的想法;透過敏捷開發,小步快跑的方法,可以讓我們提早知道問題之所在,然後早期發現早期調整,但每一次的調整一定都會伴隨成本的變更,就算時程能趕上,成本也是有可能上升。

 

所以面對這兩個低程度的風險,最好的方法其實就是一開始在規劃專案時,就先保留部分空間讓自己可以運用,根據經驗去抓出一些可彈性調整的預算跟時間,這反而是比較讓自己能趕上進度以及成本的方法,也當然大多數老闆一定會要求你做的又快有便宜,所以如何向上溝通恐怕才是這裡的關鍵。

 

而至於其他的幾個問題,像是局部功能失效、找不到原因,或是工程師換人以及原本架構沒規劃好造成的問題,建議可加強文件化的管理,讓所有資訊統整可以盡量開放,並且文件一定要能做到大家都能讀得懂,這樣才能在資訊傳遞時比較不會出錯,交接上也會比較安全。

 

基本上低程度的風險,給予大家最好的建議是,防不慎防,不如選擇直接面對問題,這些問題比較不那麼嚴重,直接跟工程師或是團隊成員坦白問題,大家一起解決,我相信都會是有答案的。

 

中程度的風險 - 潛在的燒腦問題

中程度的問題,往往就不是數位管理者能解決的,大多數這些屬於架構師的層級會比較容易解決,偏偏台灣大多數中小型企業並沒有架構師的角色,所以很多是讓後端工程師來充當這個角色,也因此在工程師不懂業務流程的狀況下,很容易設計出有問題的系統結構,但就技術面來說可能沒有問題,但如果要配合業務流程,可能就會有誤。

 

舉兩個簡單的例子,一個是早期我們在開發的時候,有些要運算的行為,一開始為了求方便,就在網頁前端去執行,後來當這個服務開始要做App的時候,發覺如果要在App端同時寫這樣的程序,因為操作流程有些不同,所以可能寫起來會很麻煩,但是如果要做在後端,卻又可能要改寫前面的前後端程式邏輯,也因此這就造成部分程式需要重寫,不然就是要花大量的時間去繼續做這個錯誤的架構,這就是一開始架構設計不良造成的延伸問題。

 

第二個例子恐怕有不少人也有受害過,在2016年,facebook關閉了parse的服務,那時候很多人的API是用parse寫的,當服務停止維運的時候,很多人便要去改寫整個API層的程式碼,用parse的目的當然就是為了利用套件加速開發,但是這次的停止維運,造成了很多團隊開發不但沒有加速,還必須要在換架構上做出很多規劃跟討論,執行起來也很不容易,這就是選錯套件造成的副作用,而且這種錯誤甚至還是無預警的。

 

中程度的風險,建議除了內部團隊的專業度要有之外,最好能有些外部顧問隨時可以提供諮詢的,因為很多問題,就算是有經驗的工程師都會有自己的盲點,用第三人稱的視角來看,往往會是比較好的解法,為了規避這些問題,其實顧問費用還是有價值的。

 

高程度的風險 - 嚴重的可能造成公司的公關議題

 

很多人可能很訝異,哪有可能工程師誤刪資料庫,或是資安被攻破造成資料毀損,甚或是工程師團隊整個不幹把整個系統把持住,回頭跟公司要求費用。

 

2017年GitLab工程師誤刪大量資料,導致線上服務崩潰,2019年Honda雲端資料庫洩露全球員工電腦安全資料,2020年twitter被駭入造成許多名人帳號發出詐騙貼文,這些是這幾年有名的事件,基本上如果以中小型公司發生問題的頻繁度,恐怕比這些巨型企業更誇張,甚至我們也曾經遇過客戶被印度團隊要求要加付大量費用才將伺服器權限歸還的。高程度的風險,遇到了,恐怕問題都是直上公司老闆,因為中間所有的管理者恐怕都不見得有權限去處理。

 

如何能不遇到這些高程度風險,其實仰賴的是平常公司對於一些基本習慣的要求,比如說文件化、伺服器管理SOP、或是權限設置的管理跟資料記錄,這些議題的重要性,對公司來說,絕對不亞於財務管理,所以找到一些專家顧問,持續協助內部教育訓練,或是針對內部流程進行健檢,這些都是必要的,這些問題發生的頻率也許兩三年可能只發生一次,甚至運氣好一點,三五年都沒碰過,但只要碰上一次,就跟今年COVID19的疫情一發生一樣,災情一定十分慘重。

 

數位管理的風險管理之難,在於環境之多變

 

數位時代的風險,隨著每年時代的改變,風險也會詭譎多變,光一個資安議題就防不慎防,更別說這些數位的開發,全部都跟人有關,技術問題也許還能管控,但人心的管理往往就是十分難以防範,也因此佈建內外部資源的平衡,較能嚇阻權力的不平衡,這些都是值得思考與投資的策略,希望各位管理者都能化險為夷,買包乖乖平安渡過每一個危機。

寓意科技
寓意科技

寓意科技提供專業的及系統資訊科技管理顧問服務,協助企業規劃並完成軟體建置

fable寓意科技官方網站:https://www.fable.com.tw/

fable寓意科技 Medium:https://medium.com/@fableltd

[筆記] Facebook 資深產品經理聊聊產品與創新
今天下午在 Clubhouse 上聽了一場收穫良多的演講,講者和主持人 Ian,Albert,和 Han-Shen 都是在設計和產品管理上經驗豐富又願意分享的前輩,之前有機會在灣區和紐約向他們請益的時候就覺得收穫滿滿,這場 Clubhouse session 仍舊相當 insightful。此篇文章便是這場演講的筆記。
Web1.0~3.0的發展歷程
在我們探尋Digital時代的多元之前,先讓我們理解一下網路成長的歷史故事,讓我們可以鑑古知今。
團隊的 GIT 分支管理策略 (1) : 基本概念
此文分兩個重點部分: 『整合』:工程師們如何把自己的產出整合成一個統一版本。『準備發佈』:從整合好的 codebase 到實際上線的分支處理。