案例分析:敏捷轉型的3大阻礙及解決方案
對于希望時刻緊跟用戶需求和行業趨勢的公司來說,敏捷開發非常關鍵。采用敏捷開發后,軟件研發團隊能夠快速創造新的產品和服務,轉變開發流程,甚至更加合理地改造組織架構。不過僅有敏捷遠遠不夠,只有解決敏捷開發常伴隨的三大阻礙,企業才能充分發揮敏捷的力量。
對于希望時刻緊跟用戶需求和行業趨勢的公司來說,敏捷開發非常關鍵。采用敏捷開發后,軟件研發團隊能夠快速創造新的產品和服務,轉變開發流程,甚至更加合理地改造組織架構。不過敏捷團隊也會遭遇困難,由于他們需要與其他團隊相互協作,提前預期并妥善處理可能出現的問題非常重要。
假設一家信用卡公司希望升級他們的移動端應用,以使客戶能夠更加便捷地查詢并兌換積分,那么就需要創建一支敏捷開發團隊,包括開發人員、設計師和項目負責人,負責人要能夠深入理解用戶行為,在開發過程中決定重點和優先順序。開發團隊花費了數周時間對應用進行升級,而另一個團隊又要花費數月時間提供積分系統的數據源,此后其他團隊還需要花費更長的時間將這些改進嵌入到應用之中,新功能的推出被嚴重推遲。
客戶喜歡這個新推出的功能,但他們還希望在登陸的時候就能查看到最近的積分活動。原來的敏捷團隊很可能已經解散了,現在各自都有新的任務,想要再組建一支敏捷團隊又要花費數月的時間。如果新團隊做出了功能的調整,但又因疏忽了一個缺陷,導致新版本未能通過安全漏洞測試,即便是后來修復了這個問題,運營團隊也可能拒絕推出這個版本,除非再經過更徹底的全面測試。那么這時開發團隊和運營團隊之間的矛盾又會導致新版本的延后推出。
這樣的狀況對很多公司來說都很常見,即便是那些技術過硬的企業,上面提到的這個案例,其實就來源于幾年前塔吉特公司所經歷的。經過了數年的發展,塔吉特公司累積了巨大的技術債務,公司的核心業務是由整體架構組成的,嚴重限制了創新和變革的便捷程度。經營規模的擴張還意味著公司對技術資源的需求也在上升,尤其是第三方承包商對技術支持的需求。
塔吉特和其他公司在技術變革上遇到的問題告訴我們:敏捷開發非常強大,但那遠遠不夠。想要擁有高度有效的數字化組織,公司需要給敏捷開發之路裝上“減速帶”,軟件開發不能一味求快。敏捷開發常伴隨以下三個阻礙:剛性架構、人才管理落后、缺乏產品思維。在這篇文章中,我們將逐一介紹這些阻礙,并給出實用的解決方法。
阻礙一:剛性技術架構
在IT行業,多年來一直在膨脹的數據庫和升級補丁已經讓許多公司的技術架構失去了靈活性。在大多數公司,提供給用戶的應用軟件都是在更科學的設計架構出現前開發完成的,飽受剛性架構之苦,太多的功能都被耦合在一起,如果你想要對其中某一段代碼進行變更,產生的影響可能如同雪崩。
在大多數情況下,要用應用程序編程接口(API)及微服務架構(microservices)對系統進行重新架構不現實,事實上,絕大多數公司采用的都是下面四種更常用的對策:
- 無為而治。一些應用可能太過渺小或更新頻率不高,不值得進行改進。
- 包裝美化。更多地向用戶展示經過良好設計的功能,在開發新功能時再采用更加現代的架構體系。
- 體系重構。重新設計應用,包括拆散原有數據庫,將其設立為相互獨立的部分,移除其中的硬編碼值。
- 重新開始。用現代架構模式如微服務架構搭建新的應用,取代原來的舊應用。
對于架構中不同的部分,可以采取不同的方法,高管需要在決定選用哪種方法時,權衡各自的潛在價值。需要考慮的方面有對新功能的需求度、與系統的交互頻率、現有應用帶來的成本、對數據拆分的難度、業務中斷的風險。
塔吉特針對這些問題做出了決策,他們將打造現代化系統置于優先地位,公開常用的關鍵數據,例如物品價格和供應量等,對于運行良好的遺留事物系統則沒有改動。這使得團隊能夠集中精力優化用戶體驗,讓用戶能夠更便捷地搜索、兌換物品,而不是把時間浪費在從幾個定價系統中選擇哪個最準確。
阻礙二:人才管理落后
人才是數字化運營模式中的核心,高管也應該清楚他們需要招募的是能夠負擔得起的最優秀的人才。然而,過去幾年的經驗告訴我們,想要招到對的人來提升IT企業的敏捷性太難了。
例如,許多公司領導發現他們的IT經理并不能從商業視角來看問題,于是就開始招募更有商業頭腦的人來替代。這些新招來的人都尤其善于交談,能夠理解業務與技術的優先度,和公司內部人員也能和睦相處,但問題就在于這些人很多都不是深度的技術專家,因為公司領導在招人的時候更愿意選擇與自己談得來的,許多公司在技術、技能方面仍然比較吃虧。
技術外包形式的出現,一定程度上也加劇了技術人才缺失的問題。從外部借調人才在某種程度上對企業有幫助,能夠迅速幫企業解決遇到的困難,獲取新的技能,或彌補企業人員不足的缺陷。可是有些企業過于依賴這種方式,公司內部的人才大多數時間都在將任務接洽給承包商,他們自己的技能不斷退化。這導致技術承包商壟斷了大量的人才資源與創新能力,形成了強大的市場競爭力。在這樣的情況下,倘若公司里一半的人都不是你的員工,你又怎么指望科技企業進行變革呢?
第三個問題在于公司內部權責模式的創建,例如產品的構建和維護的過程中,如果出現問題該由誰負責。許多公司將產品的開發和運維區分開來,因為這樣便于將產品后續的運維支持外包給第三方。如果大半夜的軟件出現了問題,到底應該找誰解決問題呢?是寫代碼的人還是負責運維的人?在敏捷團隊中整合開發、運營和維護,能夠解決不必要的職責糾紛,建立明確的端對端問責機制,這也是DevOps原則的核心要義。
要解決這些問題,科技公司需要作出重大調整,加強技術人員的技術水平,減少對外包商的依賴,明確劃分責權利。如今,絕大多數科技公司都有三種人員分工:監督的人、干活的人和思考的人,但未來的IT行業勢必會有變化,這些人員分工也必須進行調整。尤其是監督者,在公司中主要是指項目經理、業務分析師和資源渠道經理,他們需要在未來承擔更多的職責。新工作方式在敏捷開發中得到廣泛運用,意味著更合理的安排、更重的義務和更透明的過程,也意味著對業務和技術缺口間的外包商更少的依賴。
一些公司已經意識到了變革的必要性,已經開始重新設計公司的人才模式,他們主要依據以下幾點原則:
- 重點發展技術型人才。IT企業應當尋找技術過硬的人才擔任項目經理,既有能力核對程序員編寫的代碼,也具備適當的商業頭腦,能夠與產品經理和業務主管緊密合作。項目經理主要負責系統架構的技術可行性,同時匯聚各方英才。
- 重新定位監督者。甄選出最有能力的人才,拓展其職能以增加其對公司的價值。例如,有創新思維的項目經理可以通過培訓成為組織的敏捷教練,一些優秀的分析師可以發展為項目負責人。然而,現實是監督崗的人數遠超過新運營模式下的新崗位,新模式是否有效且高效,主要取決于你賦予團隊多大的權力與義務,以及去官僚化的程度。
- 民主問責制。新的人才模式中,干活的人也要承擔更多的責任,扮演更豐富的角色,例如,產品計劃中要兼具開發和運維。曾經有一位客戶的研發經理問到:“我們最優秀的開發人員要在半夜接聽多少個有關產品問題的電話才能下班?”首席技術官回答道:“我也不知道。那我們又要給他們打多少次電話,才能叫醒他們寫出更好的代碼呢?”開發人員始終承受著開發很多功能的壓力,難免會有疏忽之處。產品經理考慮到這個問題,也會讓開發人員堅持在崗位上,畢竟他們對產品的質量負有最大的責任。在新的模式之下,這些開發人員要與運營團隊協同合作,他們主要負責簡化代碼的集成和部署,就不必在解決市場反饋方面花太多的功夫。
- 減少對外部承包商的依賴。公司內部的軟件創新應當主要來自于員工的努力,這意味著需要將任務進行分類,組建敏捷開發團隊,按照合理的比例結合內部和外部的人才。也就是說,不應該矯枉過正,切忌人為地盲目砍掉對外部人才的需求。企業需要對自己的目標足夠清楚,依據客觀的需要進行人員的配比,合理地將資源分配在技術管理和人員招聘上面。
塔吉特發現他們采用的傳統招聘模式并沒有招到適合的技術人才,把公司引領到目標的位置。企業對于技術人才外包的依賴,限制了它對于打造軟件工程師社區的遠見。說回塔吉特,他們在經歷失敗之后,選擇轉向開源技術,對外宣布了公司進行轉型并發展數字科技的雄心。塔吉特此前堅持使用自己的專有代碼,導致難以聚集足夠多優秀的開發人才,因為許多優秀的開發人才都更偏愛在開源數據上工作。塔吉特的這一舉措有助于吸引并留住優秀的稀缺技術人才,減少對第三方的依賴性。
阻礙三:缺乏產品思維
在敏捷開發日益盛行的世界,傳統的項目導向、瀑布開發等模式逐漸被淘汰。相比于敏捷開發,后兩種傳統開發模式不夠靈活,對于市場和客戶的響應不足。
向敏捷開發的轉變會帶來一些問題,但相較于轉變后數字化開發的產品和服務,這些問題并不是無法解決的。將以下的產品管理實踐與原則充分應用,就能幫助產品經理盡快跨越轉變的鴻溝。
- 以產品而非項目為中心進行組織。以產品為中心組織開發工作,能夠更好地結合產品的開發與市場的需要,因為產品的誕生主要是為了解決某個行業痛點或是迎合市場機遇,通常表現為新的功能或用戶體驗的改善。技術研發團隊和管理團隊要共同決定開發的目標和優先級,每一個產品都要設置一個負責人,制定產品路線圖,選擇衡量進度的指標,在關鍵階段作出正確的決策。
- 建立穩定的工作團隊。在項目制導向下,開發團隊會不停的組成又解散,而產品導向的隊伍在整個產品的生命周期中都將延續,在需要進行改進的時候繼續合作。團隊的穩定性能讓隊伍更加高效,快速反應。
- 進行長期融資。由于產品有較長的生命周期,團隊需要每年為產品融資,以支持長期產品路線圖的實現。一些首席財務官和公司的控制者可能會對這個變動持謹慎態度,但產品導向型的開發模式實際上能帶來更加穩定的結果,因為對產品產出的測度是可以持續進行的。每個季度重新評估融資狀況,適時地調整開發的優先級,或是改變投資方向,以更高的回報率超越其他產品。
許多數字化企業早已采用了產品導向型開發模式,因為他們主要的產品和服務就是軟件等,現在更多的傳統企業也開始接受這樣的理念。例如,塔吉特將其技術研發與其商業能力和顧客體驗緊緊地結合在一起,他們250多位產品經理都像是獨立的企業家一樣,各自追求著可測度的商業投資回報,那些能夠獲取高額回報的產品經理,能夠獲得更多的資源和職責。
敏捷開發是創造價值的有效方法,但就其本身來說,光有敏捷是不夠的,不過許多企業都在努力地獲取敏捷開發帶來的技術、人才和產品管理上的優勢。一些敏捷開發的批評者認為,這種方法只適用于數字化的企業,這些企業才具有較大的潛力。解決架構剛性、人才緊缺的問題,采取產品導向型的開發模式,這些都需要企業領導及技術領袖承擔足夠的責任,并持續付出努力。如今看來,這些方法本質上就是決定商業目標與技術目標之間的優先級,只有真正愿意且努力讓企業更好地走向敏捷開發的公司,才能夠享受到不斷積累起來的收益。
相關閱讀
原作者:Will Poindexter and Steve Berez
原文鏈接:https://sloanreview.mit.edu/article/agile-is-not-enough/
翻譯:「即能」小程序,公眾號:「即能學習」,做互聯網和創業者者喜歡的內容
本文由 @即能 翻譯發布于人人都是產品經理,未經許可,禁止轉載
題圖來自Unplsh,基于CC0協議
- 目前還沒評論,等你發揮!