本文主要從管理產品研發的理念開始談起，著重說明了雲效指揮部的六大步驟，最後對使用產品的效果進行了簡要分析。一起來欣賞吧。理念
確定方向、老闆踩剎車
每個公司的技術資源永遠是有限的，業務五花八門，怎樣才能將技術資源花在刀刃上呢？如果方向錯了，跑得再快也沒有用。
ceo下面有一些業務團隊，對應的cto是並級的，是支撐業務團隊的方向的，也即cto下面的技術部門。當資源不夠用時，老闆就要踩剎車，通過業務的調整來制止過激的做法。
依據上面的組織結構，我們進行了業務分層。從公司的戰略局面來看，我們將公司業務分成前、中、後台，每個業務分為戰役型業務、核心業務和其他業務，當資源出現瓶頸時，我們可以適當的砍掉不重要的業務，明確方向。
賦能團隊、員工踩油門
當業務方向確立好後，我們就按照分好的乙個個業務域去分小團隊，讓小團隊的人自己確定業務的目標和方向，以及實現步驟。
沉澱資料、衡量
roi通過平台來沉澱整個過程的資料，當使用者在整個平台上做操作活動時，進行研發管理整個過程時，包含所有相關角色，我們將所有資料都記錄下來，放在後台裡。這樣做使我們可以隨時看資料，無限化的版本，並且，這樣協同可以讓所有人知道所有的目標，我們每個人都了解我們要實現的目標是什麼，要採取哪些步驟去實現目標，所有事情都非常清晰，達到向心力一致，大家都按照這個方向一起推動。而且，我們對資料會有乙個投入產出比的roi分析。
結合產品的實踐
我們使用的是雲效平台上面的綜合管理效能產品雲效指揮部來實踐的，它主要分為以下六個步驟來實現理念的：
戰略規劃
戰略規劃是讓業務和技術人員一起確定業務的劃分、技術規劃以及作戰規劃，業務技術高度對焦，系統資料自動彙總，系統是一級一級的彙總，得到要實現規劃的人力投入資料，老闆們從整個公司的層級來看，要實現每一級的任務目標要投入的人力資料，以及怎樣去實施，全部看得一清二楚。
兵力部署
制定好規劃後，第二步就是兵力部署。技術部門的人員就要靈活調配人力資源，如何去分布以支撐結果，快速適應業務需求。橙色部分是業務方實現規劃需要的技術資源，兵力部署完成後，就會出現藍色部分，可以看出我們的人力是不夠的，相差多少一目了然，老闆可以一級一級檢視，到底哪個地方資源不夠，並作出判斷決定是否砍掉某些投入產出不明顯的業務。目前一千人左右的團隊，3天時間就可以把這個事情完成。
作戰內容
員工踩了油門，老闆踩了剎車，接下來要關注的就是需求問題，業務池中既包含了通過老闆審批的一些新專案，又包含了應用上線後使用者的反饋情況，全部錄入到我們的需求管理中，通過審批、通知保證所有相關方都知道這個需求，並且我們還提供了讓專案相關職員在前期就可以判斷需求是否靠譜的功能，同時我們還有需求統計功能，讓所有人看到需求的進度。
作戰協同
第四步我們就要進行立項審批，pm填寫專案基本資訊進行立項，並且向團隊的研發主管申請資源做事，一旦申請後，系統就會自動通知各個的主管人，讓他去給這個專案分配資源，主管在後台就可以看到團隊所有人實時待幹的事情，很多公司客戶也比較看重這個功能，同時，我們還提供pmo工作台，讓專案經理通過平台和整個專案組成員一起共同管理專案，專案週報一鍵傳送，所有內容實現共創。
作戰覆盤
專案完成後，實際投入已經出來，可以從兩個角度看當時的投入，一是業務域視角，可以看到每個業務方當時規劃的資料以及實際使用的兵力，也可以看到當時投入多少戰役級的業務、多少核心業務和多少其他業務；一是技術部門視角，可以看到技術部門當時計畫了多少事情和實際做了多少事情，並且這個部門有多少是為業務做事情和技術做事情的。
指揮官檢視
指揮官檢視提供了整體的檢視，包括前、中、後台業務以及研發實時的資料，老闆可以隨時掌控並排程。
一路走來，我們也不是一帆風順的，我們也遇到了一些挑戰。最大的挑戰是工作習慣的引導，在沒有這個平台時，大家都是線下溝通，突然轉到線上大家還是不適應的。對此，我們從三個方面入手客服困難：
第一，宣導。我們不僅讓一線工程師執行任務，我們會告訴他們做這個事情的目的是什麼；
第二，由易到難。研發管理我們都只能從最簡單的開始做起，從立項到立需求，再做規劃、兵力部署，從易到難去推，並且推廣的人員也不同，首先從研發團隊開始做起，慢慢的推廣到業務團隊，所以，推廣的步驟也很重要；
第三，專人負責。客戶中有很多都有pmo組織，pmo專門負責從平台上撈資料，看需求完成了多少，我們規劃到哪一步了，專案中存在什麼問題，都可以及時的反饋出來。
閱讀全文：
業務驅動技術
當一名程式設計師技術達到一定水平後，這時限制他成長的，往往已經不再是技術了，而是業務思想！在當今這個網路發達的時代，網上的技術資源可以說是取之不盡用之不竭，應有盡有，現在的框架封裝的也是越來越徹底 越來越全面 也越來越傻瓜，程式設計師的門檻也因此越來越低。隨著it的發展，漸漸的考查一名程式設計師水平...
業務 技術和架構
這兩天準備要接手天津商行的專案。但是在接手的過程中，對整個專案的理解卻是非常的困難。最大的問題，就是對業務的不理解。天津商行的這個專案不大，核心的業務就是日結，及其圍繞在日結之周圍的一些相關業務。其實也並不是特別的複雜，但是轉來轉去，開賬閉賬，憑證科目什麼的，的確對乙個財務的門外漢是異常的頭痛。雖然...
作技術？作業務？
做行業的軟體公司相比較技術，更注重業務。業務需求是根本，是軟體價值體現，重視是必然。相信絕大多數公司是這樣。技術不是不重要，只能說相對次要，真正的強人是兩條腿走路的。乙個公司不需要太多的技術專家，養 差不多夠用就行。業務的東西比較具有核心價值，知識相對穩定，適合長期積累，越積累越值錢 而技術的可積累...