公司的年度計畫

hmmmm...對任何一個夠大夠久的組織來說，砍工作跟規劃新工作是一樣重要的啊。

這是個降低熵的動作：
一間夠大夠久的公司的年度計畫中，加功能與砍功能佔的時程應該要維持一個適當的比例，才是健康的，老是很單純興奮地加新功能，系統的熵只會越來越高，導致未來想加新功能代價越來越大、每個開發行為產生的副作用越來越多。

對開發人員來說，長期而言砍東西是會增加滿意度的：因為任何服務、框架一旦不夠好，那在這樣的公司文化裡就總有下線的一天，於是開發者比較可以期待一個不被過去的錯誤綁住的未來、或是開發者可以更加勇敢的嘗試新東西(類似社會安全網的概念：盡量做，別擔心，有人會來收拾殘局)。這對人員流動率、工作滿意度是有很高的正面影響的。

New framework提出來、Old Framework 下線的排程就要列。
每年普查所有的existing service，搞清楚每一個service 的loading有多大、用的人有多少、趨勢是什麼，要砍、要轉成OSS還是要繼續維護保持。

從產品的高度去看，一旦新產品上線一兩年，過了賞味期，若是流量revenue 上去了，那其實表示公司的方向有微幅的調整，任何跟新產品高度重疊的舊產品，或是與新的市場方向無關的產品，就應該要面對下線的檢討。

那若是流量、revenue 沒上去，市場不滿意呢？當然就是把這個嘗試砍掉，把人丟去發想其他新的專案或產品啊，流連於失敗的計畫對任何人都不是好事。

目前看過去這點做最好的大概是Google吧？
他們的產品墓地陣容好壯觀。