產品經理擁有普遍的知識,可以接觸到公司的不一樣部門和利益相關者。這使得他們處於一個理想的位置,能夠圍繞預防和應對技術債務創造一種工做文化。咱們提供了一些有用的策略。
根據Gartner的2019年產品經理調查,只有55%的產品發佈如期進行。這對於按時發佈產品的產品經理來講意義重大,由於他們更有可能在發佈一年內達到內部目標。在45%的延遲發佈的產品中,平均有20%沒法達到內部目標。
未能在計劃的時間範圍內發佈產品可歸因於許多因素,包括缺少正規的發佈流程、產品開發的延遲(錯誤、故障、功能蔓延)、未能知足客戶的要求、產品質量,甚至供應問題。另外一個緣由是技術債務。技術債務不只讓開發人員感到沮喪,還會致使一系列相關問題:未修補的錯誤意味着客戶不滿意。客戶留下負面的產品評論,給營銷團隊帶來挑戰。不穩定的架構延遲了新特性的發佈。銷售週期受到影響。高級管理層和投資者對此會提出質疑。編程
產品經理在促進產品成功方面扮演着關鍵角色:願景、特性、戰略、產品發佈、市場定位、競爭對手以及路線圖。產品經理位於工程、銷售、支持和營銷互相交叉的十字路口,這意味着他們處於解決技術債務問題的獨特位置。這裏有一些會起到幫助的可行策略。架構
產品經理的職責應該包括與技術主管、首席技術官和其餘部門主管創建牢固的關係。Gartner的調查發現,78%的產品經理將改善內部協做視爲他們的三大任務之一,他們的產品失敗率較低。花點時間按期與技術負責人交談,共同瞭解公司內部技術債務的程度,並承諾予以解決。開發團隊(不必定是管理層)中是否有任何擁護者願意處理技術債務?避免讓人們以爲技術債務是罪魁禍首。相反,把注意力集中在解決債務對你的產品、公司和客戶的積極意義上。鼓勵管理層爲減小技術債務提供激勵措施,例如休息一天或外出娛樂活動。性能
技術債務無處不在,應該成爲每一次產品會議的一部分。讓它成爲一個可操做的項目,並尋求按期更新。爲了不看起來僅僅像一個把關者,要努力讓開發人員參與解決問題,併爲解決技術債務這項工做設定優先級。要清楚如下問題:開發人員更喜歡在衝刺中仍是專門的時間來解決技術債務?哪一個人負責哪塊工做?每一個人目前工做量是多少?是否須要更多員工?spa
產品經理的工做是一場在任務和時間線之間不斷轉換語境的戰鬥。產品經理多是整個組織中對此最爲擅長的人,他們對一個項目的方方面面都有過人的眼光。解決技術債務意味着戰略和承諾,但首先須要肯定問題的現實性。以代碼錯誤爲例,它會延遲產品發佈。理想狀況是,組織正在跟蹤和監控技術債務,並提供一個漸進的行動項目列表。若是狀況並不是如此,提出開放性問題可讓你對問題的嚴重程度、潛在後果有一個現實而清晰的理解,並就前景展開對話。玩個遊戲吧,任何回答「視狀況而定」的人都須要往罐子裏放一美圓。詢問內容示例以下:遊戲
●是否有戰略上的理由推遲解決方案(例如等待所使用的特定軟件的技術升級)?
●是否存在不須要修復的技術債務(如過期的產品供應)?
●修復這段代碼須要多少工做?
●咱們能承諾之後會修復這個代碼嗎?
●誰將負責任何修復,時間表是怎樣的?
●此時間表是否與其餘發佈計劃、功能更新等相沖突?
●不修復此代碼對當前客戶和將來版本有何影響?
●在咱們致力於將來的返工或重構以前須要作些什麼?開發
將技術債務嵌入到路線圖時間表中。分配任務和時間來進行Bug修復、代碼審查、維護,以及全面減小現有債務,以構建更強大、更具彈性的產品。
讓路線圖儘量地開放和可見,這樣開發團隊和其餘同事就會以爲他們是產品循環的一部分。路線圖應該是靈活多變的,但也應該包括一些應對技術債務的硬性截止日期。
記住,不是全部的東西都須要重構,你的目標是肯定你在這個Sprint、一個月或一個季度所要作的事情的交集,以及你的代碼庫中有技術債務的部分。要在這些交集點解決技術債務,而不是在交集以外解決。rem
將消除技術債務做爲跟蹤組織內成功的方式。圍繞具體參考技術債務的產品性能和開發速度建立KPI。若是您的公司使用淨推薦值(NPS,可反映口碑)來衡量客戶忠誠度,這可能包括有關產品修復延遲、漏洞等的反饋。有時直接從終端用戶那裏得到反饋確實會看出問題。文檔
與技術負責人探討什麼樣的戰略能夠歸入項目過程,以減小技術債務。這可能包括指導、團隊培訓和結對編程,瞭解這些是否能夠包含進產品預算。找出將修復代碼的責任所有放在一我的肩上的技能差距。產品
一些開發團隊努力建立一種機會主義重構的文化,在這種文化中,不管什麼時候何地,只要代碼須要清理,就會進行代碼修復——不論是誰。雖然這聽起來很理想,但在工做量大的高峯時期不太現實。確保你的公司記錄債務和清理債務的責任。這應該是一份常常說起並付諸行動的「活」的文件。在團隊成員發生變化的組織中,這一點尤其重要。it