軟工以及軟體公司的管理真的是很有趣的東西，PC畢竟出現時間還不長，還沒有經過時間磨練的大規模商業及管理研究，因此要從別人研究或是經驗裡學到大型軟體開發及管理實在不易。約耳這本書道出許多軟體開發及管理上的許多「事實」，真的是一本每位軟體從業人員必讀的好書。
繼續節錄裡面一些「中肯」到不行的段落。
1. 客戶不知道他們要什麼。別再期望客戶知道他們要什麼。
2. 重要推論一：把使用介面的畫面展示給非程式人員看時，如果這個介面很不好，對方會認為你整個程式也是很不好的。
3. 重要推論二：把使用介面的畫面展示給非程式人員看時，如果這個介面非常漂亮，對方會認為這個程式幾乎已經完工。
4. 重要推論四：因為政治因素要求由各技術經理或客戶「啟動」專案時，可以提供數種美術設計讓他們選擇。
改變某些元件的擺設方式，改變外觀和字型，移動標誌位置，標誌也可以變大或變小。拿些無關緊要的家家酒內容給他們玩，讓他們覺得自己很重要。這些他們就不會嚴重影響你的時程了。
5. 至少要有一個對所用的語言、類別、API以及平台有數年以上經驗的設計者，否則還是不要啟動專案吧。如果你可以選擇平台，就用你的團體最熟悉的吧，即使這個平台並不是最符合趨勢或看起來最有生產力也沒關係。另外在設計抽象機制或程式設計工具時，多做些努力讓它不會漏吧。
6. 經理人喜歡施行測量系統，而且喜歡把它和獎懲方案綁在一起。不過只要沒有百分之百的監督，工作人員就有誘因來個「下有對策」，心裡只想著那個測量系統，完全不顧工作的實際價值或品質。
7. 軟體組織通常會獎勵(a)寫大量程式以及(b)修正大量問題的程式師。想在這種組織中出頭，最好的方法就是寫一大堆錯誤百出的程式之後再全部修好，而不是多花些時間在一開始就把東西做好。
8. 除非有個程式師掌舵，否則沒有軟體公司會成功的
9. 我並不是說這是我離開Juno的原因，不過它的確解釋了我離開Juno(約耳的前公司)的理由：不管你多麼努力工作又有多聰明，也不管你是否在「負責」，你對再微小不過的事都沒有權力。把你該死的點子訓練以及聰明睿智放一邊，把那些讓我們付錢請你的一切東西通通都丟到一邊吧。而且Juno的經理很多，大概佔總員工四分之一，所以他們有的是時間可以到處亂伸手指，確定他們能掌控。在微軟卻是副總自己從九號大樓出來找你，確定你有權力能把事做完。這對比還真是強烈啊。
10.
A. 有些事需要天份才做得好。
B. 天份很難複製。
C. 有人嘗試複製天份，要有天份的人建立規則讓普通人照著做。
D. 結果所得到的產品品質很低。
「訓練」並不真的能產生一致的結果。
小心方法論。方法論可以讓每個人的表現都提升到不佳但可接受的程度，不過同時也會產生很多約束而激怒更多的聰明人。
11. 事實上如果你曾經把很關鍵的業務拿去外包，就會瞭解外包其實是個地獄。不能直接控制客戶服務，客服就會爛到不像話，爛到像某人在網誌上寫的，想在電話公司找個人(任何人都好)去做些最最簡單的事都辦不到。
12. 如果是核心的事業功能，不管是什麼都要自己來做。
13. 在開始行銷你的「精簡」產品時，你會告訴大家：「嘿，這東西很小，只佔1MB。」大家通常都會很高興，然後就會問你有沒有他們要的重要功能，如果沒有的話還是不會買你的產品。
14. 聰明的公司試圖讓產品的互補物普及化(commoditize)。(例如，PC硬體與軟體是互補物，PC如果賣得好，隨之軟體也會賣得好，virus與防毒軟體或許也稱的上是互補物XD)
15. 無法獲得開發者尊重的產品經理沒有作用，因為他們只會一事無成。當我還在Excel團隊時，開發者會把沒有技術底子的產品經理當作早餐吃掉。
16. 產品經理最重要的技能，就是把自己的想法塞進軟體開發人員腦子裡，讓開發人員以為是自己的點子，然後乖乖照著做。
沒有留言:
張貼留言