產品經理如何幫助減少技術債務 ?

陳琦聊測試發表於2021-03-03

產品經理擁有廣泛的知識,能夠接觸到公司的不同部門和利益相關者。這使得他們處於一個理想的位置,可以圍繞預防和應對技術債務創造一種工作文化。我們提供了一些有用的策略。

根據Gartner的2019年產品經理調查,只有55%的產品釋出如期進行。這對於按時釋出產品的產品經理來說意義重大,因為他們更有可能在釋出一年內達到內部目標。在45%的延遲釋出的產品中,平均有20%無法達到內部目標。

未能在計劃的時間範圍內釋出產品可歸因於許多因素,包括缺乏正規的釋出流程、產品開發的延遲(錯誤、故障、功能蔓延)、未能滿足客戶的要求、產品質量,甚至供應問題。另一個原因是技術債務。技術債務不僅讓開發人員感到沮喪,還會導致一系列相關問題:未修補的錯誤意味著客戶不滿意。客戶留下負面的產品評論,給營銷團隊帶來挑戰。不穩定的架構延遲了新特性的釋出。銷售週期受到影響。高階管理層和投資者對此會提出質疑。

產品經理在促進產品成功方面扮演著關鍵角色:願景、特性、戰略、產品釋出、市場定位、競爭對手以及路線圖。產品經理位於工程、銷售、支援和營銷互相交叉的十字路口,這意味著他們處於解決技術債務問題的獨特位置。這裡有一些會起到幫助的可行策略。

在這裡插入圖片描述

建立同盟關係

產品經理的職責應該包括與技術主管、技術長和其他部門主管建立牢固的關係。Gartner的調查發現,78%的產品經理將改善內部協作視為他們的三大任務之一,他們的產品失敗率較低。花點時間定期與技術負責人交談,共同瞭解公司內部技術債務的程度,並承諾予以解決。開發團隊(不一定是管理層)中是否有任何擁護者願意處理技術債務?避免讓人們覺得技術債務是罪魁禍首。相反,把注意力集中在解決債務對你的產品、公司和客戶的積極意義上。鼓勵管理層為減少技術債務提供激勵措施,例如休息一天或外出娛樂活動。

讓技術債務公開透明

技術債務無處不在,應該成為每一次產品會議的一部分。讓它成為一個可操作的專案,並尋求定期更新。為了避免看起來僅僅像一個把關者,要努力讓開發人員參與解決問題,併為解決技術債務這項工作設定優先順序。要清楚以下問題:開發人員更喜歡在衝刺中還是專門的時間來解決技術債務?哪個人負責哪塊工作?每個人目前工作量是多少?是否需要更多員工?

進行必要的提問

產品經理的工作是一場在任務和時間線之間不斷轉換語境的戰鬥。產品經理可能是整個組織中對此最為擅長的人,他們對一個專案的方方面面都有過人的眼光。解決技術債務意味著戰略和承諾,但首先需要確定問題的現實性。以程式碼錯誤為例,它會延遲產品釋出。理想情況是,組織正在跟蹤和監控技術債務,並提供一個漸進的行動專案列表。如果情況並非如此,提出開放性問題可以讓你對問題的嚴重程度、潛在後果有一個現實而清晰的理解,並就前景展開對話。玩個遊戲吧,任何回答“視情況而定”的人都需要往罐子裡放一美元。詢問內容示例如下:

●是否有戰略上的理由推遲解決方案(例如等待所使用的特定軟體的技術升級)?

●是否存在不需要修復的技術債務(如過時的產品供應)?

●修復這段程式碼需要多少工作?

●我們能承諾以後會修復這個程式碼嗎?

●誰將負責任何修復,時間表是怎樣的?

●此時間表是否與其他釋出計劃、功能更新等相沖突?

●不修復此程式碼對當前客戶和未來版本有何影響?

●在我們致力於未來的返工或重構之前需要做些什麼?

將技術債務的補救列入路線圖中

將技術債務嵌入到路線圖時間表中。分配任務和時間來進行Bug修復、程式碼審查、維護,以及全面減少現有債務,以構建更強大、更具彈性的產品。 讓路線圖儘可能地開放和可見,這樣開發團隊和其他同事就會覺得他們是產品迴圈的一部分。路線圖應該是靈活多變的,但也應該包括一些應對技術債務的硬性截止日期。 記住,不是所有的東西都需要重構,你的目標是確定你在這個Sprint、一個月或一個季度所要做的事情的交集,以及你的程式碼庫中有技術債務的部分。要在這些交集點解決技術債務,而不是在交集之外解決。

參考技術債務制定KPI

將消除技術債務作為跟蹤組織內成功的方式。圍繞具體參考技術債務的產品效能和開發速度建立KPI。如果您的公司使用淨推薦值(NPS,可反映口碑)來衡量客戶忠誠度,這可能包括有關產品修復延遲、漏洞等的反饋。有時直接從終端使用者那裡獲得反饋確實會看出問題。

考慮如何預防技術債務

與技術負責人探討什麼樣的戰略可以納入專案過程,以減少技術債務。這可能包括指導、團隊培訓和結對程式設計,瞭解這些是否可以包含進產品預算。找出將修復程式碼的責任全部放在一個人肩上的技能差距。

細心對待文件

一些開發團隊努力建立一種機會主義重構的文化,在這種文化中,無論何時何地,只要程式碼需要清理,就會進行程式碼修復——不管是誰。雖然這聽起來很理想,但在工作量大的高峰時期不太現實。確保你的公司記錄債務和清理債務的責任。這應該是一份經常提及並付諸行動的“活”的檔案。在團隊成員發生變化的組織中,這一點尤為重要。

相關文章