 |
| 圖片來源：Microsoft Bing Copilot (GPT-4 enabled) |
最近到一家合作多年的客戶那邊授課（EZ專案力兩日班），課程結束後，一位學員（研發單位副處長）來問我問題。
「老師，您的課程真的很有用，從出社會到現在這麼多年，從來就沒有人用這麼系統化的方式教我們管理專案。您剛剛講的 Issue management 和 debugging 的實務經驗（專案品質控管），它們和人資管理、時程管理等面向環環相扣的關係，真的是很有感。可是，現在人真的很不好找，您也知道，我們公司的薪資福利根本就拚不過台積電和 IC Design House，老師您有沒有什麼好的建議啊？」
「你們的薪資福利拚不拚得過台積電和豬屎屋（IC Design House），我是不知道啦！不過，『人不好找』是所有企業都很普遍的問題，你不要以為台積電和那些豬屎屋就比較好找人，其實他們也和你們一樣在哇哇叫，你只能降低用人的標準啦！」
「是喔。可是，這樣退而求其次用次級人才的結果，程式碼的品質就很難控管得好啊！這真的是很兩難耶！」
「『少子化』是所有先進國家都陸續遇到的問題，而且現在的就業環境也已經變很多了，各種像 YouTube、TikTok 這樣的網路平台，提供年輕人輕鬆當網紅的機會，自己創業時間自由又不用被管，市場上的新鮮人本來就一定會愈來愈少，你也只能接受這個現實，想其他的方法去解決『人不好找』的問題。」
這位學員似乎還是不願醒來接受事實，繼續 argue，「可是老師，網紅也沒這麼好當吧？」
「我非常同意啊！但你想過沒，年輕人別的沒有，就是時間特別多，也沒什麼包袱，失敗了也沒關係，這就是年輕人的本錢，反正先試試看，就算踢到鐵板，養不活自己，再丟履歷出來應徵，也不缺工作機會，是吧？」
「也是啦！」
「再說，自己為自己工作，多拚就能多賺，還能全拿，不像幫別人打工，還要看主管臉色才能加那一點點有限的薪水，自己創業的誘因大多了，是吧？」
「您說的也是有道理啦！就像老師您現在自己創業一樣 ...」
「我是沒有現在這些年輕人勇敢啦！我可是在科技業工作過二十幾年，有點老本、有點經歷才敢出來創業的，好嗎？」
「哈哈哈！對啦！老師，剛剛你課堂上有講，沒有需要改的 code 就不是專案的『必要工作』，不該亂改，以免出包，這我真的是很認同。可是總經理要我們不要一直把程式碼複製一份出來再去加功能，免得以後解 bug 的時候常常漏掉原本舊程式碼裡的 bug 沒修到。這道理我知道，可是照總經理講的去做，程式就常常改出問題，這該怎麼辦啊？」
「你們有沒有在做 CI（Continuously Integration）？要每天，甚至是每小時，都在持續整合所有工程師寫出來的程式碼，確保程式碼都可以整在一起沒問題，而且還要做到自動化喔？」
「CI 我知道，不過我們沒有在做，人力不夠啊！」
「那你們寫程式有沒有連帶做單元測試（Unit Test），確保每個人寫的每個單元程式碼功能都正常無誤？」
「ㄟ，也沒有耶。」
「那你們有沒有對整合出來後的軟體，做一些基本的、 自動化的整合測試（Acceptance Test）？」
「沒有內。」
「你們什麼都沒做，是要怎麼管控好程式的品質？每天這麼多人改了這麼多程式碼，你們怎麼知道有沒有人把原本好好的功能給改爛掉？」
這位學員頓時愣住，完全無法回答我的問題。
我接著說，「你知道微軟在二、三十年前的 DOS 時代就已經用 batch file 在做這些事情了嗎？Office 軟體裡內建的 VBA 也是為了測試 Office 龐大的功能集而打造出來的自動化測試架構，你知道這些工作 effort 有多大嗎？人家就是能認清事實，做對的事，做該做的事，才能成為世界級的企業的啊！」
「是喔，我確實可以想像到那些 effort 有多大。」
「再說了，Microsoft Visual Studio 這類整合式開發工具，老早就已經內建 Unit Test 的架構和工具了，自動化測試的工作不知道已經簡化了幾百、幾千倍了，為什麼你們不想利用呢？」
「老師，這些我知道，可是就真的沒人力做這些東西啦，功能都做不完，Bug 都解不完了...」
「ㄟ，別倒果為因喔！就是因為沒好好做這些自動化的 CI、Unit Test、Integration Test，所以你們才不敢放手去改現有的程式碼來增加新功能，只敢 copy 一份 code 出來改，最後搞得軟體愈來愈肥，愈跑愈慢。而且，就算你們這樣幹，軟體的 bug 也還是一堆，解 bug 也還是一樣曠日廢時，是不是這樣？」
「老師，我們的狀況的確是這個樣子...」
「這就對了。這些自動化 CI、Unit Test、Integration Test 的作法，都是老早就已經被廣為驗證過有效的方法，是確保軟體品質的基礎建設，也是很重要的軟體品質防護網，就是因為你們一直都沒有好好做這一塊，所以你們才會沒辦法『迅速確認』自己改的 code 有沒有問題，當然就會讓整個團隊一直 suffer 大量又難解的 issue，然後為了 debug，就不得不一直加班、一直 delay schedule 啊！」
「老師，你說的很有道理...」旁聽的另一位學員插嘴說道。
「所以，『人不好找』不該是你的首要議題，你該優先思考和解決的應該是『提升現有人力工作效率』的問題，也就是打造好我剛剛講的那些基礎建設，搞好這部分之後，專案的 bug 絕對會大幅減少，也會很快就被發現，這樣就會好解很多，這樣就等同於整個專案團隊的效率大提升。我覺得，這件工作才是現在你這位主管應該看的大局，不知道你同不同意呢？」
「嗯，老師，我同意。」
「OK，如果你同意，那我接著問你，就算是召募到次級人才，他們還會製造出嚴重的軟體品質問題嗎？」
「有這些防護網，應該就比較不會才對。」
「沒錯，你應該抓到專案管理的重點了，這些工作都應該被列入專案的 WBS 和甘特圖裡面。下個階段，你也許就可以再考慮導入 GitHub 和 OpenAI 合作開發的人工智慧工具 GitHub Copilot，讓程式設計師用自然語言就可以快速產出有一定品質水準的程式碼，進一步提高團隊的生產力。我想如果你可以顧好『防護網基礎建設』和『利用 AI』這兩件事，以後在管理專案或部門時，應該都會輕鬆很多。」
經過這番犀利的提問之後，這位學員頻頻點頭認同，表示會開始這樣做。可是，who knows？這些建議我已經在這家客戶多年來的課堂上說過很多遍了，結果到現在還是沒看到真正的改革。畢竟「知道」是一回事，「做到」又是另外一回事了。
打從我和這位主管學員開始對話，旁邊就陸續湊過來好幾位學員旁聽，其中有位在總經理室任職的同仁，最後終於忍不住吐槽了那位主管學員，為這段對話畫下了句點。
「我早就跟你說，你真的不要再寫 code 了，要像老師講的那樣，看大局，幫部門和團隊紮好馬步，做好基本功，團隊的工作效率才出得來，你就不聽。」