1樓：科創人
你好，我是方云數位化研發管理諮詢師。
我們幫助一家研發團隊有500人左右的中型公司，用三年的時間完成了數位化轉型。
下面是我們的研發數位化管理成熟度模型：
方云數位化研發管理成熟度模型是由方云開發的評價企業研發團隊管理成熟度水平的一套標準，反映了企業在各個過程域的數位化研發管理成熟度。
成熟度的定義是研發過程的管理水平，基於自組織理論和控制論原理，從忽視、口頭宣傳到提供持續和標準化的輸出，再到能夠自主、自動地改進，體現了現代企業管理的發展方向。
成熟度0級，初始級：無管理行為。
成熟度1級，制度級：有制度，無工具保障制度的執行效果。分為三個小級別：
低階代表制度停留在管理者口頭，並無成文制度；中級代表有成文制度，但是覆蓋不完全；高階代表制度覆蓋完整全面。
成熟度2級，工具級：有工具來保障制度落地，缺少完整畫像。分為三個小級別：
低階代表有工具支援制度，但是覆蓋不完全；中級代表工具全面支援制度，但是缺少相互整合；高階代表工具完整覆蓋，相互整合。
成熟度3級，資料畫像：通過管理視角建立完整畫像。分為三個小級別：
低階代表有了畫像，但是資料質量較差，無法反映團隊真實績效；中級代表部分資料質量較高；高階代表資料種類完善，質量較高。
成熟度4級，資料驅動：通過資料畫像來指導組織改進，需要專家參與。分為三個小級別：
低階代表資料主要應用於驅動制度完善和制度落地；中級代表資料能夠驅動績效提公升；高階代表資料有效性取得廣泛共識，形成資料說話的文化，組織形成數位化經營的管理實踐，固化為獨特的基於資料畫像的績效體系。
成熟度5級，資料智慧型：專家不參與或少參與，由人工智慧來優化組織過程，指導人才發展。本級別屬於技術展望，未有明確細分。
經過三年的轉型，這家公司研發體系的生產相關領域已經基本數位化，現在我們正在進行的，是將研發體系的人力資源管理領域也完成數位化轉型。
從經驗來看，最初隨著公司的發展，我們要做加法，不斷的往上堆疊。但是隨著公司的發展，複雜度達到一定水平之後，我們需要做減法，將公共部分抽取出來變成元件，將重複勞動自動化。
2樓：
這個問題太大，就像已有答案，這個答案意味著乙個高階技術團隊的多年經驗。但要注意，也許不能低估架構師和軟體的總設計師的能力。這裡需要掌握軟體系統的兩個規律：
一、分層
二、抽象
每個層面的人，只需要理解該層應該理解的，穿透理解細節不是不能，而是不必要。乙個人眼裡的乙個複雜系統，只是上層檢視中的幾個服務或介面。
3樓：
因為問題問的太泛泛，具體細節沒法講。只想提個醒，不同型別的專案之間差異性過大，不是什麼devops和TDD什麼的一堆詞能解決的，更別上來就拿pmp那一套糊弄人。
問的太虛，答得也只能虛點。要學會未雨綢繆，也要學會問題求解、危機攻關。要解決的核心問題是：
1，資金。
2，研發負責人的人事權。
3，分工，合適的人做合適的事。
以上問題解決了，具體細節問自己團隊裡面專家去。
4樓：程墨Morgan
我不想正面回答這個問題，因為這個回答可能足夠寫一本書，不，可以寫很多本書。
但是，我可以給幾個直接的思路：
不要指望乙個人兩個人能夠很清楚地梳理大型專案的全貌，當軟體專案龐大複雜到一定程度，就像是一頭不斷進化的怪獸，你只能盡量「馴服」它，但不要指望對它完全掌控，因為這頭怪獸有自己的生命，你想要控制它會被它反噬的。
花大價錢僱傭專業的人來做事，不要指望花很少的價錢撿乙個大便宜，原因很簡單，有能力的人能夠找到更識貨的雇主。
沒有第3條，請參考第1條和第2條。
產品研發管理和研發專案管理的區別是什麼？
才聚PMP考試中心 需求方面 產品需求定義，要從市場調研開始，分析使用者樣本，定義詳細的SPEC，在SPEC定義完整前，不要進入設計 編碼階段。而專案的需求可能很模糊，所以就需要不斷用原型來啟發使用者的需求產生，所以XP很適合專案開發。PMP專案管理師報考條件免費評估 學習資料 題庫免費領取 專案管...
遊戲研發團隊的工作氛圍如何？
個人覺得在國內有志同道合一起用心做遊戲的團隊很難很難找到，確實如其他朋友說的那樣，很多都是為了混個工作。乙個團隊有幾個是能夠長期專注的投入的，很多能完成當前任務的都不錯了，還有就是團隊意識就更別提了。至於有創造性的團隊協作，很難遇到，遊戲專案一旦時間長了，超過半年以上，大部分人就疲了。這個和專案研發...
產品研發專案進度管理軟體（工具）有哪些推薦？
場量科技 X Developer專案進度管理自動化工具，值得擁有。場量科技 新特性 X Developer自動化看板，讓遠端團隊管理更高效 曾經用過project，Excel，後來發現easytrack，之後一發不可收拾，一用就是幾年，納悶早些時候幹嘛不用easytrack呢，為什麼這麼好的專案管理...