作者/PingCode研發PV孫敬雲
最近有客戶提出這樣一個問題：現在的工具功能都大同小異，PingCode有什麼特別之處？
那麼要回答這個問題，我可能要從”根“上說起。
一、首先，在產品的構建理念上PingCode有一套完整的理論基礎
假如企業有一個目標，為了實現這個目標，員工們以一種資源的形式出現在那裡，承擔著機器做不了的工作。
這種管理方式的理念是：所有管理者的工作，就是在員工身上汲取他們所需要的。這是從工業時代就已經成熟的管理方式，它把員工當成一種資源，而員工自己的定位就是”為老闆打工“。
對於勞動密集行業來說，這種方式經久不衰。
因為這類員工的工作內容重複性高、易標準化，管理者可以制定具體的行為規範，透過細緻的考核標準和明確的賞罰條款簡單直接的給予激勵。
但是對於知識密集行業來說，這種方式很難完成偉大的工作。
因為這類員工的工作通常是定製化的、具有一定創造性的，他們需要在一個小範圍內保持公開透明、充分溝通。如果這時員工的腦子裡都是”為老闆打工“，那麼他有一百種方式翫忽職守。
這絕不是危言聳聽，根據蓋普勒的統計，每10名員工中有7名是”不敬業的“，他們要麼自由散漫，要麼主動出手破壞組織的努力成果。
那麼這是員工的錯嗎？其實歸根到底是員工們沒有”為自己做事“，他們缺少參與感，缺少在工作中的那一份”樂趣“。
如果細化到IT行業-研發領域，我認為應該弱化管理的”管“字，而更看重管理的”理“字。比如這樣的一個管理模型：
1、
研發的基礎離不開工具的支撐，透過工具可以最大化的釋放員工的雙手
，這對於效能的提升是非常明顯的，
比如透過DevOps工具鏈搭建CI/CD，它不僅加速了部署過程，更是提供了另一種研發場景的可能性。當然工具絕不是一成不變的，它們會根據企業的實際發展不斷的向前演進，帶來新一代的效能革命。
2、
基於相同的工具集，我們能更容易的統一技術規範，比如程式設計規範、工程化方案、CI/CD、基礎架構和文件標準等等。
統一技術規範是為了標準化研發過程，因為標準化的行為更容易進行復制，從而產生規模化的經濟效應。
3、
有了統一的技術規範，企業就可以重新構建自己的研發工作流。
工作流就像水流入管道一樣，順著定義好的規則從左到右的流動，我們要儘早的發現管道中的瓶頸並予以解決，透過不斷的改進讓這條工作流越來越高效，能夠提供更大的交付能力。
4、
在一定的流程制度約束下，我們可以成立很多跨職能團隊，向他們賦能，允許他們自我管理，透過啟用腦力工作者的創造力和內在動力，讓他們”為自己做事“，享受工作中的”樂趣“，從而創造更大的價值。
5、組建高效能的敏捷團隊不是目的，實現企業目標才是。因此在自組織團隊之上要有一套目標引導機制，
目標管理主要就兩點：一是我們的目標是什麼；二是如何知道我們向著目標前進。
透過上述的管理模型示例我們可以發現，研發領域管理者的主要工作並不是”鞭笞“著員工的幹活，而是營造一個”共贏“的工作環境，將員工引導到正確的軌道上，讓他們在一定的自由空間下發揮最大的價值。
那麼PingCode的產品矩陣如何體現「研發領域的管理方式」？
很簡單，
PingCode本身就是工具集中重要的一個，同時PingCode還具有打通其他工具的能力（透過REST API和應用市場）。
透過PingCode Wiki
可以沉澱企業內的技術規範和流程制度；
透過PingCode Plan、PingCode Agile和PingCode Testhub
可以非常容易的搭建出一套標準化的研發工作流，開啟即用；
透過PingCode Agile
可以讓敏捷團隊（Scrum和Kanban）規劃自己的工作、顯現真實進度、回顧和不斷的改進自己；
透過
PingCode Goals可以讓所有的專案有共同的目標，在更高的視野上及時瞭解企業目標的進展。
二、其次，與其看單獨的功能點，不如連起來看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的特別之處，也希望能夠幫助您尋找到更合適的研發管理工具。