小弟也是鍵盤分析師，針對為什麼大家要把公司產品搞糟，
先來玩個情境模擬一下。
從公司制度面出發，大部分公司一定都有個績效考核制度，鼓勵大家認真打拼。
如果大家都顧好自己的績效，是不是也同時表示公司績效會好呢?
才不一定哩...
先假設一個簡化後的KPI計算方式為ΣC(i)P(i)
C是案子的重要性，越大的案子越高
P是案子結束後的完成度，以100%為最高分
i從1到n，表示經手n個案子
再假設三種角色：
一個案子略分為三層分工管理，上層、中層、下層，
這個分工是依照流程而不是職位高低。
1.上層代表產品規劃設計，與市場推出時程等等負責整個案子的最後表現。
依照各公司不同的體制，可能是PM或是與中層為同組人馬等等，
只要任務屬於這個範圍都是定義中的上層。
2.中層負責管理研發開發時間，依照上層訂定的schedule完成開發。
project leader就是這裡定義的中層，視情況協助開發。
3.下層毫無反應就只是個工程師。
今天在這種KPI計算法則下，每個人如果要提升自己的績效，
都是朝著能夠完成越多重要案子，且每個案子完成度越高越好去努力。
如果每個案子都能如期完成，大家都可以得到相應的報酬。
問題就在於每個人時間有限，衝高案件數(n)的同時，也許會犧牲完成品質(Pi)
這時不同職位就會表現出明顯差異了。
下層工程師的一次經手的案件數較少，所以一旦手中的案件失敗對考績影響很大。
反之中層project leader一次管理多個工程師經手案件較多，
一兩個失敗的案子無所謂，其他案子有好表現照樣拉高KPI。
所以對project leader來說，幾個工程師被操到精神不濟狀況百出也不是大問題，
只要還有人能繼續幫忙產出就好。
所以只要是上層丟下的任務幾乎可以來者不拒，有人幫忙消化掉就有加分。
就算負責到的案子真的出包了，先想辦法推給其他部門，只要最後不被黑掉就好。
由上層PM來看，既然project leader都能夠消化的了這些任務(其實時程早已被壓縮了)
能夠多幾個產品線就盡量多，一來可以排滿自己的schedule，
二來反正開發時間可以壓到這麼短，不如多做幾種產品來測試市場反應，
等哪個產品熱賣了再來加開產量。
所以每個階層按照各自的角色，追求最大利益的結果就是加縮開發時程，增加案件
卻不用確保產品品質。
趕得上上市時間，結果品質做到全民公測的OneX也許就像這樣。
要能改善這種狀況當然是從project leader做起最快，
對上盡量以確保品質滿分來接案，吃不完不要硬撐。
免得PM以為開發周期本來就很短，拼命亂試產品浪費公司資源。
對下當然是讓工程師有充足的時間把事情做好，起碼有正常的生活作息。
不要一下子沒日沒夜的拼個三四天，然後就睡眠不足變阿呆。
講得簡單做的難，要擺脫這種文化就要有人先肯犧牲自己的利益，
於是周永明就寫信道德勸說啦...
用說得就有效才有鬼哩，大家都會算啦，不把制度改一改哪有機會啦
阿對了，好像漏了講工程師要怎樣才會對自己最有利...
阿沒差啦，除了不爽不要做以外也沒幾招啦，準備國考和英文比較實在