※ 本文為 dinos.bbs. 轉寄自 ptt.cc 更新時間: 2013-04-05 01:51:08
看板 Soft_Job
作者 標題 Re: [轉錄] 這幾句話，輕鬆惹火程式設計師
時間 Thu Apr 4 22:32:00 2013
※ 引述《TonyQ (自立而後立人)》之銘言：
: ----------------節錄-------------------
: 在軟體行業接近10年了，有很多話是不能對程式設計師講的，而這些你可能從來沒有留意
: 過，以下是我跟朋友們討論後歸結出來的幾個經典台詞：
我相信這篇文章講到很多軟體工程師的內心深處。但我很願意從另一個角度來看這篇文
章。也就是開發一個軟體專案的成本，尤其是要做好，做到賣，其實超過很多人（包含老
闆／出資者）的想像。即便是技術背景的主管，都很容易忘記經驗帶來的教訓。
寫規格
我們都說別人不寫規格，好那我就自己寫，連我自己一個人開發獨立專案我都自己寫給自
己看。( https://github.com/NDark/KobayashiMaruCommanderOS/wiki )
但我認為我規格書寫的很差，我從沒有寫過一個文件是到實行時是完全不用
改的，也就是說，在還未開始實作的時空點，是難以想像實行時會遇到的困難。因此，不
管在寫規格（設計）及實作時有經驗的工程師就非常重要，前者會盡量顧及彈性，而後者
可以在規格不明的時候寫出容易修改乾淨清楚的架構，修改時出問題時也容易找。有經驗
的工程師不便宜，這就是成本。
管在寫規格（設計）及實作時有經驗的工程師就非常重要，前者會盡量顧及彈性，而後者
可以在規格不明的時候寫出容易修改乾淨清楚的架構，修改時出問題時也容易找。有經驗
的工程師不便宜，這就是成本。
我前面說了，我是一個很願意寫文件的人，我覺得我自己文件寫的不好。然而，事實是，
在我生涯中，我從沒看過一個寫文件寫的比我更好的工程師。這說明了幾個可能現象：
a. 其實不需要寫文件，透過優秀的工程師事情也可以做的很好（敏捷式）；
b. 當工程師換了位置，就會換了腦袋。當我們是工程師時我們怪別人沒好好把規格講清
楚，當我們變為管理者，我們就認定工程師不需要文件就應該要把事情做好（學長學
弟制）；
楚，當我們變為管理者，我們就認定工程師不需要文件就應該要把事情做好（學長學
弟制）；
c. 不管是從主管評核或是同儕互相競爭的角度，寫文件被當為是浪費時間，不被當作是
實際產出的工時，所以大家乾脆直接實作（其實我們根本沒這麼在意文件）；
d. 偉大的作品不需要寫文件，一個好的架構應該讓菜鳥一看就瞭解他的奇淫精巧。
（天方夜譚）
我們如何拔擢人才變為專案推動者
科技業通常叫不帶兵的管理者為專案經理；有些公司就是部門小主管帶專案；實行矩陣式
的公司兩者都有；實行專案制的公司會有從其他專案空降過來的專案經理，這些人從基層
的工程師看起來竟然距離實務這麼遙遠。同樣是有好幾種可能的：
的公司兩者都有；實行專案制的公司會有從其他專案空降過來的專案經理，這些人從基層
的工程師看起來竟然距離實務這麼遙遠。同樣是有好幾種可能的：
a. 其實老闆真的只是需要個抗壓性強又聽話的，這個職位就是只被期待這樣而已；
b. 老闆真的應該多看書，多看看國外怎麼管理，該找哪種人來當主管；
c. 其實根本沒有這種人才供給，也就是說沒有一種共通的優秀管理風格，導致不同團隊
都各玩各的，每個專案推動者都是各憑三兩三而已；
d. 沒有辦法訓練沒有管理才能的資深技術人變為－能跟客戶溝通談規格，能將規格變為
企劃書，軟體架構，或規格書的員工。這就回到人才訓練的問題了，不管是新人訓練，進
入專案的訓練，還是儲備幹部的訓練，通通都在這淺碟市場中被成本外部化了（我只想用
便宜的價錢買那種現成不用再切的水果）。
企劃書，軟體架構，或規格書的員工。這就回到人才訓練的問題了，不管是新人訓練，進
入專案的訓練，還是儲備幹部的訓練，通通都在這淺碟市場中被成本外部化了（我只想用
便宜的價錢買那種現成不用再切的水果）。
專案推動者的工作到底是什麼？任務規劃，成本評估。
從老闆的立場，絕對不會允許工程師閑著的。因此專案推動者絕不會故意安排空檔給執行
者。若有空檔都是任務規劃的失誤導致工作太快完成（估計太長）。因此理想來講在排滿
的工作上，若可以插進新的工作（而不影響時程），那其實表示原先估計有問題。專案推
動者應該要被換掉。
者。若有空檔都是任務規劃的失誤導致工作太快完成（估計太長）。因此理想來講在排滿
的工作上，若可以插進新的工作（而不影響時程），那其實表示原先估計有問題。專案推
動者應該要被換掉。
一個好的任務規劃，應該反而沒有機會插進臨時的工作，只能做交換，也就是原先的工作
被推遲。這時成本就應該要反應出來。若沒有，那肯定有人做假。這才是老闆該注意的警
鐘。
被推遲。這時成本就應該要反應出來。若沒有，那肯定有人做假。這才是老闆該注意的警
鐘。
新的任務，臨時的規格修改，隨著工作展開才撥雲見霧的工作細節，就連開會討論都是不
停的墊高成本。做工程師的就是把實行的成本反應出來，做專案推動者的就是去理解這樣
的成本是基於什麼樣的評估及計算方式，其實最有可能的就是對規格與標準的誤解。
停的墊高成本。做工程師的就是把實行的成本反應出來，做專案推動者的就是去理解這樣
的成本是基於什麼樣的評估及計算方式，其實最有可能的就是對規格與標準的誤解。
測試通常是被忽略的成本
尤其在小公司，測試通常被忽略的很徹底。不願意請一個時薪一百出頭的工讀生，寧願讓
三倍薪水的工程師慢慢磨。
絕沒有故意寫臭蟲的工程師，臭蟲的發生多半是規格不清楚（這種情形甚至連什麼叫做錯
，什麼叫做不好，不漂亮都無法定義清楚，我甚至還有聽過沒品味這種評價），若規格清
楚，那測試品管就容易得許多。
，什麼叫做不好，不漂亮都無法定義清楚，我甚至還有聽過沒品味這種評價），若規格清
楚，那測試品管就容易得許多。
錢若不花在教育，就會花在監獄。而沒有測試計劃而省下測試成本的團隊，都會在未來付
出更多的代價來還債。
溝通者，語氣很重要。
卡莉在演講中說過，業務（推銷者）不是天花亂墜，而是用對方能懂得的語言讓對方能了
解，在專案推動者也是亦然，就我所體會，沒有不做事的工程師。只有這兩種
“為什麼是我做，不是你做？”，以及
“為什麼是我加班作？”
將前述的成本觀念匯整，再突破這兩個點，我相信”工程師”這個族群其實並不是很難對
付。
--
"May the Balance be with U"(願平衡與你同在)
視窗介面遊戲設計教學，討論，分享。歡迎來信。
視窗程式設計（Windows CLR Form）遊戲架構設計（Game Application Framework）
遊戲工具設計（Game App. Tool Design ）
電腦圖學架構及研究（Computer Graphics）
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 219.68.22.188
※ 編輯: NDark 來自: 219.68.22.188 (04/04 22:32)
※ 編輯: NDark 來自: 219.68.22.188 (04/04 22:33)
--
※ 看板: dinos 文章推薦值: 0 目前人氣: 0 累積人氣: 197
回列表(←)
分享