天天加班,為什麼團隊研發效能還是那麼低?

前段時間一個 Github 專案把網際網路公司的加班文化推上了風口浪尖，不可否認，最近這十年，國內網際網路的發展速度趕上甚至超過了矽谷，為了加速發展，國內很多公司採用了“拼工時”的做法，天天加班，卻忽略了最最應該關注的研發效能。

可以回想一下，你的團隊是不是也面臨著下面的問題？

1. 研發團隊人不少，大家也很辛苦，但產品釋出常常延期，上線後產品問題頻發。

2. 開發提測質量不好，大量壓力聚集到測試，導致程式碼返工率極高。

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

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

你所處在的研發團隊

這裡我列舉三種可以看見的研發團隊

第一種：

專案從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. 明確專案要做什麼，其實在這個環節，就是給各團隊的同學講為什麼要做這個專案，這個專案能解決什麼問題，帶來什麼樣的收益，用專案價值去打動各團隊一起努力比老闆說必須做這個理由更有說服力和感染力，也會讓所有人全心全意去為專案努力付出

2. 明確各團隊的職責，即為了這個專案需要做哪些功能的新增或對現有功能的優化。

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

4. 明確專案干係人：專案負責人、技術負責人、測試負責人，在遇到問題時可以找到對應負責人溝通。

在CORNERSTONE裡，可以同時並行管理多個專案。每個專案清晰明確可見責任⼈、任務狀態、優先順序、類別、時間等多維度資訊，幫助企業快速⾼效的對項⽬進⾏全週期管理。

1.3 需求討論及需求分析

作為產品經理，你可能是某一個專案的負責人，也可能是專案相關團隊的產品經理。

無論哪一個，你都需要針對自己團隊負責的任務進行需求整理，與自己團隊的開發、互動視覺設計、測試確認需求、評估需求。CORNERSTONE討論功能可供團隊成員互相交流,共享資訊,解決自己在工作中遇到的各種問題。

二. 專案執行與監控

2.1 專案執行

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

2.2 站立會、週會

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

如果專案時間較長，通過週會可以統計週期內好的現象以及遇到的問題，通過會議總結，讓各團隊瞭解當前專案進度以及遇到的阻礙。

2.3 聯調

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

2.4 專案監控

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

專案風險的可能性有很多，比如開發的delay、測試出現嚴重bug、業務需求方在專案進展過程中頻繁變更需求導致工時無限延長等等。

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

三. 專案收尾

結束是新的開始，專案也好、產品也好，只要沒有死，就一定還會有新的開始。

在產品的生命週期中，包含著無數個專案，這其中有好的專案也有不好的專案。

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