加拿大如何在社保數字領域內實施產品管理和團隊拓撲？

banq發表於2022-02-25

這篇部落格探討在聯邦政府內部實施產品管理，尤其是在數字領域。
加拿大就業和社會發展部 (ESDC) 是一個服務部門，大多數加拿大政府部門也是如此。ESDC 透過50 個計劃提供服務，以提高所有加拿大人的生活水平和生活質量。其中之一是“就業銀行Job Bank”計劃。
 

就業銀行定位
就業銀行Job Bank計劃實際上是加拿大《就業保險法》的一部分，為僱主和求職者提供免費的雙語服務，以此來減輕就業保險計劃的壓力。
服務消費者並不關心運營服務的成本和風險，但服務使用的是產品，這些產品的交付是有成本的。
管理內部的複雜性以維持這些產品，以及它們如何影響服務水平是產品管理的重點。
轉向數字化意味著這些產品中的一些將被暴露給服務消費者（例如，一個網站，一個移動應用程式）。
“就業銀行 "這幾個字可以理解為三個不同的含義。

  • 一個計劃。
  • 對求職者和僱主的服務，最終使用該計劃的績效資訊檔案（PIP）來衡量；以及
  • 一個產品系列--最引人注目的是構成其網站的10個產品，作為就業銀行服務提供的一部分，它被客戶所接觸和消費。

與網站的互動對服務績效有直接影響（例如，瀏覽和尋找資訊的能力，與相關工作的正確匹配等），並且由於與軟體的互動產生了大量的資料，為改進提供了快速洞察力。這就是數字化帶來的新機會：利用基於證據的決策，對這些洞察力迅速採取行動的能力。所有的目標都是為了改善結果。

在傳統的專案與企業的關係中，IT部門幾乎沒有得到足夠的資金來 "keep the lights on"，當專案想讓IT人員參與到軟體修改中時，就會使用專案。這可能會對急需的小改進造成不必要的滯後。
在數字世界中，一個部門的產品 "團隊"，如Job Bank，應該同時嵌入業務和IT人員。然而，由於財政委員會（TB）規範程式和企業的政策2將IT和程式功能的負責人不同，這兩個獨立的人自然希望在各自的組織結構圖中負責其功能的工作人員。
 

養老金制度
我們的養老金系統在這裡是一個很好的例子。它被各種專案（無論是業務增強、技術債務補救、軟體修補、立法授權、轉型舉措）所轟炸。這些變化來自於多位高管，因為養老金專案並不與監督其交付的單一官員聯絡在一起。由IT部門單獨管理和協調這種規模的承諾是不現實的。特別是在處理專案可能表現出來的領土行為（例如，"我是最優先的，這是我的預算，這些是我的資源"）。
為了管理所有這些需求，使用了產品經理。這是一個戰略角色。他們的眼光超越了6個月的時間範圍：

  • 產品經理使用產品的路線圖，既是一種溝通工具，也是一種談判工具。與不同的專案經理合作，討論在一個時間範圍內做什麼是合理的。產品經理還確保產品團隊有足夠的能力來處理各種需求，如進行財務、人力資源和架構規劃等。這裡特別強調：確保資金。

產品所有者是一個更具戰術性的角色。他們在6個月的時間範圍內進行研究：
  • 產品負責人與產品經理和產品路線圖緊密合作，確定釋出範圍，並擁有對產品做出決定的最終權力。他們與產品團隊一起工作，從路線圖的高層次需求中闡述更詳細的需求，並在必要時與其他IT專業人士合作（例如，IT安全）。

我們認為，產品經理和產品所有者都需要坐在就業銀行計劃的一邊，因為他們的業務決策方面。儘管他們必須與IT經理緊密合作，以充分了解風險的影響，如不斷攀升的技術債務和網路安全，並確保符合IM/IT政策（例如，IT安全的軟體補丁要求）。
 產品團隊是由跨職能的熟練成員組成的，來自多個部門。這就是敏捷和DevSecOps適合的空間。為避免交付堵塞而必須加快釋出速度，這促進了它們的採用。產品團隊必須接受良好的敏捷培訓，否則，混亂會悄然而至，對他們的表現產生負面影響，或者更糟的是，向高階管理層傳達 "敏捷不起作用"。專案管理紀律在這裡仍然被積極使用，尤其是產品經理，不一定要把所有的工作都正式交給一個部門委員會。
 

團隊拓撲
對於 Job Bank，它是加拿大就業保險委員會。在定期向國庫委員會提交的更新中，Job Bank 需要確定充足的資金，不僅適用於其專案人員，也適用於 IT 工作。
團隊拓撲有四種型別的團隊進行互動：
流對齊的團隊是專案官員所資助的。它的雲端計算積分和勞動力成本可以直接歸屬於該專案。

其他三種型別的團隊不能直接歸屬於一個專案，他們的成本基本上是共享的，構成了 "IT企業服務 "的空間。他們的成員很可能都在IT組織之下，但也有可能有來自不止一個分支的成員的情況。他們的資金和可持續性需要將資金集中到CIO預算中。除非他們能提供按需服務，比如透過API，否則他們的工作可能需要專案化，因為流線型的團隊基本上都在爭奪他們的時間承諾。

專業化團隊在某些領域提供重要的專業知識。例如，關聯式資料庫效能、高階資料建模、數學和計算。這些團隊通常首先作為專案的一部分參與進來，然後繼續提供服務（例如，為業務流對齊的團隊建立一個商業智慧（BI）COTS產品，然後讓他們管理BI的報告）。

賦能團隊幫助其他團隊克服障礙。他們輔導和指導他們，直到他們獲得足夠的專業知識，在這一點上，他們會離開。扶持型團隊的性質是臨時性的。上面的例子是無障礙辦公室。

平臺團隊提供令人信服的內部產品和服務，以加速流向一致的團隊的交付。就業銀行的一個例子是，它使用了DocUpload服務，允許客戶上傳檔案，然後進行防病毒掃描並安全地儲存。重新使用這種服務使組織能夠節省時間和金錢。

然後，我們可以看到鬆散耦合架構（即API驅動）是如何增加巨大價值的，因為它賦予團隊更多的自主權，透過提供按需服務來減少專案化的需求。

相關文章