每天加班,爲何團隊研發效能仍是那麼低?

前段時間一個 Github 項目把互聯網公司的加班文化推上了風口浪尖，不能否認，最近這十年，國內互聯網的發展速度遇上甚至超過了硅谷，爲了加速發展，國內不少公司採用了「拼工時」的作法，每天加班，卻忽略了最最應該關注的研發效能。

能夠回想一下，你的團隊是否是也面臨着下面的問題？

研發團隊人很多，你們也很辛苦，但產品發佈經常延期，上線後產品問題頻發。

開發提測質量很差，大量壓力彙集到測試，致使代碼返工率極高。

開發人員疲於應付業務，沒有精力或者興趣去精進技術，工做效率低。

這其實就是團隊的研發效能出現了問題。

你所處在的研發團隊

這裏我列舉三種能夠看見的研發團隊

第一種：

項目從0到1，系統或產品都沒有搭建完成，團隊的開發資源都在這個項目週期中。開發到一半可能由於業務或領導的決定改變方向，最終花了幾個月時間可能整個項目沒有任何結果或只有半成品。

這樣的研發方式：傳統研發模式

第二種：

團隊項目進入到1.0後的版本，項目團隊以產品線爲中心，將產品經理所匹配的前端、後臺、安卓、IOS等爲一小組。項目2週一版本，碰着大需求的時候就3週一版本。但必定要保證版本迭代的方式落地項目，而不是一次性幾個月才上線一個完整的項目。

這樣的研發方式：敏捷開發scrum

第三種：

團隊項目有1.0以後的版本，也有從0到1的版本。所以團隊以產品經理爲中心，開發匹配在一塊兒後，以1-4周的時間範圍內爲版本時間。另外0到1的項目呢，開發人員all in在這個這裏，致使沒辦法繼續作迭代的工做。

這個第三種有點像第一和第二種的結合

這樣的研發方式：四不像

你是哪種？

如何提高團隊研發效能

互聯網產品由於產品的需求面臨用戶，或則是線下的業務。需求自己會不停地變換或調整到最好的方式，按傳統的方式從需求調研、原型設計、評審、文檔、設計、研發，這樣的流程須要大量的文檔、以及項目審覈時間，當審覈結束後咱們才能進入開發。而且開發的時間週期也是很是長的。致使互聯網研發中，其實不少需求均可能已通過時了，但咱們仍然在研發中的尷尬局面。

瀑布型工做流程也會致使團隊產生容易敵對的關係，好比產品說：「研發他們作不了」，研發說：「產品他們總是變」，互相的責任推卸影響團的士氣。

雖然瀑布流的邏輯很是嚴謹，但開發、產品人員都能瞭解到它的缺陷。團隊內部都會反問本身：「是否應該更應該合理的遵照流程，輸出更詳細的文檔？」

可是卻越嚴格，致使結果團的溝通問題愈來愈大

因此，在當研發有2-3個以上的時候，突破傳統開發瀑布流的方式。能夠將有效的增長團隊人員的參與感，從需求調研到項目結束每一個人都可以完整的感覺到項目的成就與失敗感。

以人爲溝通的「敏捷開發」

敏捷開發的意義是將人的溝通爲切入，將團隊的概念引入。以產品經理爲主導將開發、設計人員關聯在一塊兒。固定的每日站會、每週評審、每個月覆盤，產品經理爲切入點帶動起來整個項目。

固然敏捷開發的好處是必需要規定1-4周爲一個版本。每一個週期叫作spring，一旦定下來了就不能更改，簡單稱呼爲：小步快跑、快速迭代。

真正的「敏捷開發」流程究竟是什麼樣的

敏捷開發後咱們的研發流程大體以下，下面以CORNERSTONE敏捷開發工具爲例:

一. 項目啓動

1.1 需求收集

CORNERSTONE爲需求生命週期搭建流程，能夠自定義更改按收集、評審、排期、設計、開發、發佈設立多個階段，在不一樣階段把任務分發給產品、設計或者開發人員，讓需求完成無縫銜接。這個階段實際上是產品經理最擅長的領域，即爲何要作這個項目？

在這個階段，對於負責項目的產品經理來講，須要輸出的是需求文檔及原型，這是你用來打動老闆的基礎，也是須要與涉及項目團隊成員溝通需求的基礎。

1.2 項目啓動會

在立項會上順利從老闆那裏得到資源後，項目能夠真正開始啓動了，這時就須要召開一個項目啓動會，將項目涉及的各個團隊召集到一塊兒，給你們講一個充滿想象力的美好故事，讓你們爲了這個目標而努力。

那麼，具體須要作哪些呢：

1. 明確項目要作什麼，其實在這個環節，就是給各團隊的同窗講爲何要作這個項目，這個項目能解決什麼問題，帶來什麼樣的收益，用項目價值去打動各團隊一塊兒努力比老闆說必須作這個理由更有說服力和感染力，也會讓全部人全心全意去爲項目努力付出

1. 明確各團隊的職責，即爲了這個項目須要作哪些功能的新增或對現有功能的優化。

1. 明確時間節點，即針對於上面提到的功能或優化，各團隊開發、測試以及聯調的時間節點，明確時間節點能夠保證項目能夠在計劃的時間內完成。

1. 明確項目干係人：項目負責人、技術負責人、測試負責人，在遇到問題時能夠找到對應負責人溝通。

在CORNERSTONE裏，能夠同時並行管理多個項目。每一個項目清晰明確可見責任⼈、任務狀態、優先級、類別、時間等多維度信息，幫助企業快速⾼效的對項⽬進⾏全週期管理。

1.3 需求討論及需求分析

做爲產品經理，你多是某一個項目的負責人，也多是項目相關團隊的產品經理。

不管哪個，你都須要針對本身團隊負責的任務進行需求整理，與本身團隊的開發、交互視覺設計、測試確認需求、評估需求。CORNERSTONE討論功能可供團隊成員互相交流,共享信息,解決本身在工做中遇到的各類問題。

二. 項目執行與監控

2.1 項目執行

需求確認、工時評估完成後，正式進入項目執行階段，由相關成員進行開發、設計及測試。CORNERSTONE的甘特圖功能可方便管理者弄清項目的剩餘時間，評估工做進度，調整工做任務，更好地把握項目的總體。

2.2 站立會、週會

每日站立會以及週會是保證項目正常進行的手段之一，經過天天的站立會溝通，確認團隊成員是否遇到了問題，針對問題進行及時溝通與解決，保證項目能夠正常進行。

若是項目時間較長，經過週會能夠統計週期內好的現象以及遇到的問題，經過會議總結，讓各團隊瞭解當前項目進度以及遇到的阻礙。

2.3 聯調

聯調每每是跨團隊項目須要考慮的問題，只要項目涉及的團隊大於兩個，就須要進行項目聯調，保證各自團隊負責的功能模塊不會由於新的需求出現問題。CORNERSTONE針對這一需求，提供了全局報表（項目進度）。方便管理者瞭解項目分佈、進度計劃、質量風險等，並從中獲取客觀的實時數據，幫助管理人員分析、評估項目，全面瞭解組合內項目情況，以便做出及時決策。

2.4 項目監控

項目監控，是保證項目進度，保證項目能夠在規定時間內保質按時上線。CORNERSTONE中管理者可根據項目建立狀況，可實時更新項目狀態，預警項目風險。簡單來講就是：對項目風險的管理——遇到項目風險如何處理，如何解決。

項目風險的可能性有不少，好比開發的delay、測試出現嚴重bug、業務需求方在項目進展過程當中頻繁變動需求致使工時無限延長等等。

CORNERSTONE在可視化的平臺活動圖上，任意自定義不一樣緯度統計卡⽚，可⼤⼤⽅便項⽬經理全⾯掌握項⽬進度和團隊表現，瞭解每位成員⼯做產出與⼯時，提早化解潛在⻛險；同時⽀持⼀鍵分享卡⽚內容。

三. 項目收尾

結束是新的開始，項目也好、產品也好，只要沒有死，就必定還會有新的開始。

在產品的生命週期中，包含着無數個項目，這其中有好的項目也有很差的項目。

每一次的項目上線或收尾，都須要對項目進行一次覆盤和回顧，發現項目過程當中的優勢與不足，優勢繼續保持，不足找到解決方案，在下一次項目中儘量的避免。