構建從目標到研發過程的全生命週期管理體驗

做者/PingCode研發PV孫敬雲

最近有客戶提出這樣一個問題：如今的工具功能都大同小異，PingCode有什麼特別之處？

那麼要回答這個問題，我可能要從」根「上提及。

 

1、首先，在產品的構建理念上PingCode有一套完整的理論基礎

 

假如企業有一個目標，爲了實現這個目標，員工們以一種資源的形式出如今那裏，承擔着機器作不了的工做。這種管理方式的理念是：全部管理者的工做，就是在員工身上汲取他們所須要的。這是從工業時代就已經成熟的管理方式，它把員工當成一種資源，而員工本身的定位就是」爲老闆打工「。

 

對於勞動密集行業來講，這種方式經久不衰。由於這類員工的工做內容重複性高、易標準化，管理者能夠制定具體的行爲規範，經過細緻的考覈標準和明確的賞罰條款簡單直接的給予激勵。

 

可是對於知識密集行業來講，這種方式很難完成偉大的工做。 由於這類員工的工做一般是定製化的、具備必定創造性的，他們須要在一個小範圍內保持公開透明、充分溝通。若是這時員工的腦子裏都是」爲老闆打工「，那麼他有一百種方式玩忽職守。這毫不是危言聳聽，根據蓋普勒的統計，每10名員工中有7名是」不敬業的「，他們要麼自由散漫，要麼主動出手破壞組織的努力成果。

 

那麼這是員工的錯嗎？其實歸根究竟是員工們沒有」爲本身作事「，他們缺乏參與感，缺乏在工做中的那一份」樂趣「。

 

若是細化到IT行業-研發領域，我認爲應該弱化管理的」管「字，而更看重管理的」理「字。好比這樣的一個管理模型：

 

一、研發的基礎離不開工具的支撐，經過工具能夠最大化的釋放員工的雙手，這對於效能的提高是很是明顯的，好比經過DevOps工具鏈搭建CI/CD，它不只加速了部署過程，更是提供了另外一種研發場景的可能性。固然工具毫不是一成不變的，它們會根據企業的實際發展不斷的向前演進，帶來新一代的效能革命。

 

二、基於相同的工具集，咱們能更容易的統一技術規範，好比編程規範、工程化方案、CI/CD、基礎架構和文檔標準等等。統一技術規範是爲了標準化研發過程，由於標準化的行爲更容易進行復制，從而產生規模化的經濟效應。

 

三、有了統一的技術規範，企業就能夠從新構建本身的研發工做流。工做流就像水流入管道同樣，順着定義好的規則從左到右的流動，咱們要儘早的發現管道中的瓶頸並予以解決，經過不斷的改進讓這條工做流愈來愈高效，可以提供更大的交付能力。

 

四、在必定的流程制度約束下，咱們能夠成立不少跨職能團隊，向他們賦能，容許他們自我管理，經過激活腦力工做者的創造力和內在動力，讓他們」爲本身作事「，享受工做中的」樂趣「，從而創造更大的價值。

 

五、組建高效能的敏捷團隊不是目的，實現企業目標纔是。所以在自組織團隊之上要有一套目標引導機制，目標管理主要就兩點：一是咱們的目標是什麼；二是如何知道咱們向着目標前進。

經過上述的管理模型示例咱們能夠發現，研發領域管理者的主要工做並非」鞭笞「着員工的幹活，而是營造一個」雙贏「的工做環境，將員工引導到正確的軌道上，讓他們在必定的自由空間下發揮最大的價值。

 

那麼PingCode的產品矩陣如何體現「研發領域的管理方式」？

• 很簡單，PingCode自己就是工具集中重要的一個，同時PingCode還具備打通其餘工具的能力（經過REST API和應用市場）。
• 經過PingCode Wiki能夠沉澱企業內的技術規範和流程制度；
• 經過PingCode Plan、PingCode Agile和PingCode Testhub能夠很是容易的搭建出一套標準化的研發工做流，打開即用；
• 經過PingCode Agile可讓敏捷團隊（Scrum和Kanban）規劃本身的工做、顯現真實進度、回顧和不斷的改進本身；
• 經過PingCode Goals可讓全部的項目有共同的目標，在更高的視野上及時瞭解企業目標的進展。

PingCode官網

 

 

 

2、其次，與其看單獨的功能點，不如連起來看PingCode的工做流

 

 

PingCode是根據場景來組織功能的，我先放一張場景圖：

（規模化敏捷）

 

在一個健康的IT企業中，一個明智的決策一般要通過充分的調研和評估，而後才能成爲各個研發部門的目標。在這個過程當中，企業中的各個關鍵角色要進行目標對齊，全部人的步調要保持一致。關於如何使用PingCode Goals進行目標管理？請參考：「國內首款OKR SaaS廠商，是如何落地研發目標管理的」

 

目標肯定後，一些關鍵工做項要有明確的落地計劃 ，這就須要經過PingCode Plan來進行規劃。在PingCode Plan中經過路線圖能夠清晰看到全部工做的時間節點，這個階段對應着」規模化敏捷「圖中的」特性「節點。

 

 

 

緊接着，在PingCode Plan中，將這些工做項安排到不一樣的敏捷團隊的」待辦工做事項「中，讓這些自組織團隊在必定的時間區間內安排開發工做：

 

 

 

 

進入每個敏捷團隊的」待辦工做事項「（PingCode Agile的需求列表）中，自組織團隊就能夠看到按優先級排序的各種需求。

 

 

 

 

敏捷團隊會根據綜合因素（一般包含：優先級、工做量、依賴關係、非功能性需求的比例等等）安排每一個開發週期的工做，他們在每一個開發週期結束時都會產出一個能夠交付的程序增量。

 

隨後咱們將全部的Scrum團隊完成的服務進行集成，造成一個全局版本，部署到生產環境中，這個階段對應着」規模化敏捷「圖中的」PROD「節點。

 

 

 

最後，各部門、業務負責人在企業的目標同步會議上，經過PingCode Goals對目標的完成進度進行復盤，一個理想的覆盤會議應該要基於必定的行爲記錄、數據分析進行後續決策。

最後，PingCode的功能比較全面，體驗也更天然

 

由於PingCode的功能點很是多，我在這裏只舉幾個例子：

 

1.用戶故事的360°的關聯

 

在PingCode中，一個用戶故事既承載着一個業務價值點，也是一個溝通的平臺。在一個用戶故事上能夠看到很是多的信息，好比一些基本信息，包括：狀態、負責人、關注人、開始結束時間、優先級、風險、故事點、需求來源、需求類型、發佈版本、標籤、描述、自定義字段等等；還有一些關聯信息，包括：子任務、缺陷、關聯工做項、關聯測試用例、關聯文檔、關聯附件等等；還有一些開發數據，包括：代碼提交記錄、評審記錄、構建記錄、部署記錄等等；還有一些交互數據，包括：評論、卡片的活動記錄、狀態流轉記錄等等。可謂是一張卡片，全緯度的數據。

 

2.規劃迭代（適用於Scrum團隊開計劃會議的時候，投大屏幕）

 

 

 

3.迭代回顧（適用於Scrum團隊開回顧會議的時候，投大屏幕）

 

 

 

更多的功能點，我仍是建議各位讀者們本身體驗，我就不自賣自詡了。但願經過這篇文章能夠說明PingCode的特別之處，也但願可以幫助您尋找到更合適的研發管理工具。

 

 

 

PingCode官網——點擊當即領取25人免費版​