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

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

從這個概念開始，很多管理技巧衍生出來，例如我們熟悉的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，在日常工作中都會更有成就感，也會更熱愛你的工作。