《01 | 效能模型：如何系統地理解研發效能？》筆記2

任務驅動 VS 強調工做時長

其實，在硅谷，不多有公司要求 996。不過，在初創公司，由於業務緊張、同事間的競爭，加班也很常見。可是，硅谷和國內的公司有一個很大的區別，就是硅谷的公司通常是任務驅動，只要完成任務就行，無論你花了多少時間。而國內不少實行 996 的公司不只僅是要求完成任務，更強調工做時長。但其實，專一時長的這種操做在軟件開發行業是不合理的，由於長期加班不能保證持續的高效產出。

從我以及身邊許多開發者的經驗來看，天天可以高效地產出代碼五六個小時，已經至關不錯了。短時間突擊加班會有效果，但若是長期加班，一般效率、質量會降低，產生了 Bug 就要花費更多的精力去修復。若是這些 Bug 發佈到了用戶手上，損失就會更大，得不償失。

長期加班還會出現無效加班的結果。好比，有個朋友在一家國內一流的互聯網公司工做，據他反饋，公司實行 996，不少人加班實際上是磨洋工，低效加班很是明顯。可想而知，其餘推行 996 工做制的公司，大機率也會存在這種問題。

軟件開發是一個創造性很高的過程，開發者之間的效率相差很大。就好比，10x 程序員的生產效率能夠達到普通開發者的 10 倍。其實，不只是我的，團隊間的效率相差也很大。因此，相比工做時長而言，公司更應該關注的是研發效能。

1. 關鍵詞：任務驅動，創造性工做。
2. 爲何這麼多公司不約而同選擇讓員工長期加班996呢？
   • 我以爲是公司慌不擇路地下意識選擇。
   • 「慌了，慌了，項目還沒盈利，公司入不敷出，我要自救，我要求生。那就讓員工加班，多幹點活，業務進度快點推動，在市場上快人一步，這樣公司就能活下來了。」
   • 慌亂的團隊能作好事情嗎？
3. 其中的對錯利弊很難講得清楚。
4. 也許國外的月亮特別圓：任務驅動，幹完手上的事就好了？
5. 程序開發確實是創造性的工做，起碼大部分是。創造意味着燒腦？沒法長時間保持輸出。咱們用的這麼多便利的工具都是創造出的。

加班致使效率低？

從我以及身邊許多開發者的經驗來看，天天可以高效地產出代碼五六個小時，已經至關不錯了。短時間突擊加班會有效果，但若是長期加班，一般效率、質量會降低，產生了 Bug 就要花費更多的精力去修復。若是這些 Bug 發佈到了用戶手上，損失就會更大，得不償失。

長期加班還會出現無效加班的結果。好比，有個朋友在一家國內一流的互聯網公司工做，據他反饋，公司實行 996，不少人加班實際上是磨洋工，低效加班很是明顯。可想而知，其餘推行 996 工做制的公司，大機率也會存在這種問題。

行業競爭激烈，你追我趕，長期加班是下意識的自救，但效果並很差，由於員工的創造性受到了限制。

創造性的工做

軟件開發是一個創造性很高的過程，開發者之間的效率相差很大。就好比，10x 程序員的生產效率能夠達到普通開發者的 10 倍。其實，不只是我的，團隊間的效率相差也很大。因此，相比工做時長而言，公司更應該關注的是研發效能

在研發效能上着手，而不是單靠加人，加班等治標不治本的方法。

注重研發效能的巨大好處：開發者聚焦產出價值，團隊創建起好的氣氛，促進生效效率，造成良性循環，支撐起持續的高效開發。

雖然知道要注重效能，但如何提升研發效能也是個難題。

軟件研發的靈活性 與創造性

本質：讓開發流程流暢，最大程度地釋放出開發者的創造性和積極性。

研發效能模型

軟件開發本質上是一條超級靈活的流水線

體現靈活性的4個方面：

引出的研發效能模型：

理論指導實踐，大方向是這4個方面，但每一個團隊都有不一樣的實踐，因地制宜，必需要適合本身團隊的，照搬照抄不必定有卵用。

最後，開發自己是一件頗有趣的事情，軟件開發者，跟畫家，做家，音樂創造者同樣，都特別須要靈感的迸發，但不少時候咱們卻要被業務牽着走，創造性被受限，淪爲搬代碼的碼農，很是痛惜。