程式開發是一種難以管理的創意工作?

5396691102_dd3d157676_b

從工業革命開始,工作被分成了幾種類型,為了量化生產,以供給滿足客戶大量的需求,所以生產實體產品這樣的工作,被拿到生產線上進行最佳化,目標是在最短的時間,最低的資源投入與成本耗費之下,做出一樣品質的產品。

從這個概念開始,很多管理技巧衍生出來,例如我們熟悉的SOP,我們過去常用的甘特圖,計算績效的KPI…凡此種種,都是從這種基礎概念產生的理論。

但,有一種類型的工作很難被SOP規範、很難用KPI管理、也幾乎無法被甘特圖預測,那就是創意工作,諸如,藝術品、歌曲、文章…的生產。而我得說,程式設計,其實也是其中之一,但往往被忽略的很徹底。

為何這類的創意工作不能被傳統管理工具有效管理,本質原因很簡單,因為能透過標準作業程序管理的生產行為,大多是追求著產出"完全一樣"的"實體成果",小到一顆螺絲釘,大到一台BMW汽車、在生產規劃的那一刻,其目標就是希望生產出一模一樣的東西,沒有人希望這類產品的產線在生產的時候,出來的每一個成品都有自己獨一無二的特色,如果是,哪怕只是多了一兩克重量,都會讓人難以接受。

但創意工作不是,沒有一首曲子100%完全一樣,如果有,就變成了抄襲,藝術品、創意工作所產出的成果,之所以有其價值,就是在那95%類似的元素之外,那5%的一點差異。

藝術品和創意工作,容或製作生產的流程相同、投入的資源類似,但一旦落入模仿或臨摹,其價值就一落千丈,和這市場上其他的商品不同,其差異就在於對價值的認定。

很不幸的是,電腦軟體也是如此。天下沒有兩套完全一樣的軟體,因為不需要,如果完全一樣,你copy一分就可以了。電腦"可程式化"的目的就在於面對變化,面對差異,然而麻煩的地方就在那5%的差異。這5%的差異,讓程式設計從工業工作變成了創意工作,而”人”在其中就變成了一個很大的變數。(如果完全一樣,就不會有問題,也不需要額外寫程式,就是因為不完全一樣,才需要再次撰寫程式碼)

過去20年,軟體工業一直企圖把程式設計(軟體開發)變成一個標準化的動作,我們夢想著用OOP,就可以讓一切變的組件化、好讓程式的組成變得容易。我們從工業管理生產線上學來SOP、KPI、Gantt Chart,想要用一樣的方式管理程式設計師的產出,用同樣的方式提高產量,但努力了20年,卻發現離理想越來越遠(早期軟體生命周期很長,半年才一個release,那時好像還可以應付,時至今日,過去的waterfall早已經被證明了,面對這個時代的需求完全力有未逮)。

我們從產線效法了看板方法,有效的管理工作,確保產出,但還是不能忘記,軟體開發最核心的部分其實是創意,我們確實可以依照SOP、利用各種技巧管理工作分配,但別忘了最源頭的需求,才是讓一切不同的主要因素。產線上的需求是固定的,那怕是最小量的客製化接單生產,需求在生產期間都是不變的,但軟體不是。

在這個時代,現實就是需求時刻改變,即便我們能夠在一個週期(迭代)之中固定需求,但面對真正天翻地覆的變更時,本質上我們依舊可能得拋棄某一個迭代的產出,面對變化作出反饋。

這世界上沒有一套軟體是完全一樣的,即便功能相同,但背後的目的也可能天差地遠,然而真正的災難是,企業企圖僅僅使用設計用來提高產能、確保一致性產出的管理概念,來管理一個目標是產出具有唯一性、期待不同結果、具有創意性質的軟體開發流程。
(閒話幾句,我看過無數的程式碼,method以外光鮮亮麗,往下細看method以內慘不忍睹,即便都通過unit test,即便程式運作都正確,但同樣結果的程式碼,還是有品質高低不同的差異,這些,與實體商品的生產流程根本完全不同。軟體產品絕對不能視為實體產品,他本質就是虛擬的,和一首歌、一幅畫一樣,做完,絕對不100%等於做好,做好,也不見得是完成…)

縱然,軟體開發的圭臬從早期的OOP,一路演進到現在的CI, CD, DevOps,我們依舊企圖自動化生產流程,依舊期待可以透過組合的方式產生我們要的軟件,而專案經理們採用的這些管理技巧(SOP、甘特圖、KPI),在其餘各個領域也都被驗證過且有效的被推行,但為何唯獨軟體開發領域不行? 為何唯獨軟體開發工作,在實施了這些管理工具之後,專案經理依舊必須和bug搏鬥? 依舊無法提升品質? 依舊需要面對客戶抱怨,依舊躲不開永無止盡的專案延期,依舊…依舊無法管理好每一個變更? 真的是因為PM的管理知識不足,管理工具沒用到位? 還是根本是管理方法出了問題?

相信我,每一個軟體產品都是唯一的,同樣,每一位程式設計師也是,你可以"管理"一群員工,但你只能"領導"一個團隊,傳統的管理工具僅僅可以讓你確保最低品質的產出(但如果你要的本來就是最低品質的產出,那我也無話可說),但唯有真實面對軟體開發工作與其他生產工作不同的創意特性,才能夠創造出具有價值的軟體,也才能真正發揮團隊的創意與生產力。

軟體專案管理並非真是一個難以管理的生產過程,但是用錯了方法,往往會變成一場災難。

後記:
很多專案經理和業務人員,並非軟體開發背景出身,但在軟體公司或專案工作中卻掌握了管理大權,很遺憾的,即便開發人員依稀覺得當前的管理方法有些問題,卻說不太出來(或是不想說?),導致管理人員和專案團隊中一直存在著一種很難言喻的隔閡。

另一種衍生出的問題則是,在這種環境之下,開發人員久而久之,感嘆於市場狀況(或工作環境)無法改變,時不我予之下,乾脆領錢閉嘴少做錯事,慢慢消耗著僅存的開發熱情度日,不管是哪一種狀況,都很令人遺憾。

在你的團隊中,找出一個合理且有效的管理方式,讓軟體專案變成一種樂趣,讓團隊真的幫上客戶(或End-user)不論是團隊成員或PM,在日常工作中都會更有成就感,也會更熱愛你的工作。

留言

91寫道…
科技一直進步、工具一直進步,工時卻沒有因此而減少...XD
Unknown寫道…
因為老闆一直都想種出又大又美的木瓜...XD
老師,有關鍵字 BMW 耶 XDDDD
David寫道…
Gelis果然看得很認真...
匿名表示…
我也一直認為程式開發是個創意的工作.
卻被使用者當作業員對待.
程式開發背景的主任心理清楚但卻用作業員的方法對待... 哎
匿名表示…
因為付錢的人,並不清楚你在做什麼
最後只好用作業員的方式,處理所有的管理

這個網誌中的熱門文章

使用 Airtable 在小型需求上取代傳統資料庫

使用Semantic Kernel 建立自然語言請假系統

精彩(且驚人)的Semantic Kernel入門範例

在 LINE Bot 開發中使用Semantic Kernel建立自然語言請假系統

專業的價值...