前段時間一個 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 項目啟動會
在立項會上順利從老闆那裡獲得資源後，項目可以真正開始啟動了，這時就需要召開一個項目啟動會，将項目涉及的各個團隊召集到一起，給大家講一個充滿想象力的美好故事，讓大家為了這個目标而努力。
那麼，具體需要做哪些呢：
- 明确項目要做什麼，其實在這個環節，就是給各團隊的同學講為什麼要做這個項目，這個項目能解決什麼問題，帶來什麼樣的收益，用項目價值去打動各團隊一起努力比老闆說必須做這個理由更有說服力和感染力，也會讓所有人全心全意去為項目努力付出
- 明确各團隊的職責，即為了這個項目需要做哪些功能的新增或對現有功能的優化。
- 明确時間節點，即針對于上面提到的功能或優化，各團隊開發、測試以及聯調的時間節點，明确時間節點可以保證項目可以在計劃的時間内完成。
- 明确項目幹系人：項目負責人、技術負責人、測試負責人，在遇到問題時可以找到對應負責人溝通。
在CORNERSTONE裡，可以同時并行管理多個項目。每個項目清晰明确可見責任⼈、任務狀态、優先級、類别、時間等多元度資訊，幫助企業快速⾼效的對項⽬進⾏全周期管理。
1.3 需求讨論及需求分析
作為産品經理，你可能是某一個項目的負責人，也可能是項目相關團隊的産品經理。
無論哪一個，你都需要針對自己團隊負責的任務進行需求整理，與自己團隊的開發、互動視覺設計、測試确認需求、評估需求。
讨論功能可供團隊成員互相交流,共享資訊,解決自己在工作中遇到的各種問題。
二. 項目執行與監控
2.1 項目執行
需求确認、工時評估完成後，正式進入項目執行階段，由相關成員進行開發、設計及測試。
的甘特圖功能可友善管理者弄清項目的剩餘時間，評估工作進度，調整工作任務，更好地把握項目的整體。
2.2 站立會、周會
每日站立會以及周會是保證項目正常進行的手段之一，通過每天的站立會溝通，确認團隊成員是否遇到了問題，針對問題進行及時溝通與解決，保證項目可以正常進行。
如果項目時間較長，通過周會可以統計周期内好的現象以及遇到的問題，通過會議總結，讓各團隊了解目前項目進度以及遇到的阻礙。
2.3 聯調
聯調往往是跨團隊項目需要考慮的問題，隻要項目涉及的團隊大于兩個，就需要進行項目聯調，保證各自團隊負責的功能子產品不會因為新的需求出現問題。
針對這一需求，提供了全局報表（項目進度）。友善管理者了解項目分布、進度計劃、品質風險等，并從中擷取客觀的實時資料，幫助管理人員分析、評估項目，全面了解組合内項目狀況，以便作出及時決策。
2.4 項目監控
項目監控，是保證項目進度，保證項目可以在規定時間内保質按時上線。
中管理者可根據項目建立情況，可實時更新項目狀态，預警項目風險。簡單來說就是：對項目風險的管理——遇到項目風險如何處理，如何解決。
項目風險的可能性有很多，比如開發的delay、測試出現嚴重bug、業務需求方在項目進展過程中頻繁變更需求導緻工時無限延長等等。
在可視化的平台活動圖上，任意自定義不同緯度統計卡⽚，可⼤⼤⽅便項⽬經理全⾯掌握項⽬進度和團隊表現，了解每位成員⼯作産出與⼯時，提前化解潛在⻛險；同時⽀持⼀鍵分享卡⽚内容。
三. 項目收尾
結束是新的開始，項目也好、産品也好，隻要沒有死，就一定還會有新的開始。
在産品的生命周期中，包含着無數個項目，這其中有好的項目也有不好的項目。
每一次的項目上線或收尾，都需要對項目進行一次複盤和回顧，發現項目過程中的優點與不足，優點繼續保持，不足找到解決方案，在下一次項目中盡可能的避免。