有些人會想說反正產品可以軟體更新，那就先出貨，然後再給客戶更新。這個動作的前提是公司內部的測試團隊健全、具有阻擋有瑕疵的版本的能力。如果沒有這種團隊，發行瑕疵版本，遲早會把公司搞爛。

讓沒有進過工地的人當總工程師，這個建案一定完蛋。但軟體確不一樣，唉....資訊工程讀的東西不比建築工程少阿...只能感嘆建築至少是百年歷史的專業，資訊只有幾十年。

公司應該要為不同部門、職位，明定權責並公開於每個員工。否則會造成事情一層交代一層，當事情到達某一層的主管，為了保住飯碗而將所有事情接下來做，這對公司與其下的員工都是傷害。

部門開會完以後的問題與結論應該要PO到公司上的討論區，讓有遇過類似問題的人能夠幫忙解答。主動解答的人，會有答題加分。

什麼樣的總經理有什麼樣子的風格，懂財金的自然會把公司的錢控制得很好。懂技術的自然會把研發部門管得很好。懂政治的自然就會把政商關係搞好，就看你想要去哪種類型的公司。

分研發部門應該以專業領域來分，軟體與硬體就是很明顯的領域區別。但現在的產品功能越來越複雜，軟體領域需要切得更細，但不能與硬體並駕齊驅，因為不管怎麼分還是軟體的一部份。就算是codec、dsp、linux、8051，也應該在軟體部門下。因此研發部門若分到3個以上就是過於龐大。

專案開發就像是你想到一個地方卻無法使用導航軟體與看地圖，只能邊走邊問到處碰壁。最慘的是老闆想要從台灣開車到大陸，卻只會在旁邊叫你加班快點開....

去高雄美術館看房子，餘屋一坪才10萬...，加裝潢車位後打折，一坪8萬...

寫出某功能或某模組的人，應該要負責到底，直到離職為止。不然就是要讓他帶人一段時間後才能夠算交接。不能夠天真的以為給個光碟片，或是留下硬碟就算交接。

我最近發現畫UML能夠讓別人覺得很專業。