Re: [轉錄] 這幾句話，輕鬆惹火程式設計師

[NDark (溺於黑暗)]

※ 引述《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/05 01:54)
→ NDark:感謝 elvispoetic 提供排版嘍
推 hegemon:現在很多主管都反過來了...只重文件不重實做....
推 x90050:測試真的很容易被忽略，我這邊就是屬於先實作做完才補規格
→ x90050:每次把東西搞出來，上頭就只會說你啥沒做啥做錯
→ x90050:但是做之前都沒開規格，永遠要等樣品出來後才要決定
→ x90050:今天如果事前有明定規格，那沒做跟做錯是我的錯
→ x90050:偏偏上頭就是當工程師都是先知，只要講個專案名稱
→ x90050:工程師就會知道規格是啥，跟他說是你沒開規格
→ x90050:他還會回你說要舉一反三，而不是別人說一做一
→ NDark:我認為文件在實作後出算是折衷的做法.
→ NDark:但是不能不出,作完確定有個大家同意的版本後還是要寫清楚.
→ NDark:後出的做法下.第一版的實作其實就是原型.
→ NDark:只是公司把原型就拿去賣了.
推 lovdkkkk:推~
推 damody:有經驗值 推~
推 MonyemLi:非常認同,但我認為在台灣插入會轉換為加班,所以成本不變
→ NDark:加班要付加班費,"理論上"是增加成本的.
→ NDark:責任制的代價是高獎金,其實也是成本.
→ i386:很多責任制的公司也不一定有獎金..這種小公司不少...
→ NDark:責任制 沒高薪 沒大餅 還待大概是跟被詐騙集團騙差不多了.