許曉斌-負責任的技術規劃 —— 不僅僅是技術.pdf

《許曉斌-負責任的技術規劃 —— 不僅僅是技術.pdf》由會員分享，可在線閱讀，更多相關《許曉斌-負責任的技術規劃 —— 不僅僅是技術.pdf（28頁珍藏版）》請在三個皮匠報告上搜索。

1、演講人：許曉斌目 錄01背景、技術規劃源頭02業務、產品、技術目標03規劃的承載-OKR04上下文環境分析業務背景服務的部門淘天（淘寶、天貓）阿里云國際部門（AliExpress，Lazada 等）菜鳥本地生活、高德大文娛（優酷等）整體覆蓋數萬的工程師崗位和技術棧 后端工程師-Java（70%+）前端工程師 JavaScript，TypeScript 后端工程師 Go，C，C+算法和數據工程師 Python（增長）測試、運維/SRE為什么要做規劃為了半年/一年的績效考核組織習慣：財年開始做規劃老板的要求聚焦團隊的資源，實現關鍵的業務目標直接業務目標：通常是和經營、財務直接相關的。例如指標：產品

2、年度的收入，利潤，運營成本（包括硬件資源成本，人力成本）間接業務目標：和用戶規模和市場占有率相關的，例如月付費用戶數，市場滲透率，用戶的留存率等等。（前提：開放競爭市場）從組織的生存邏輯上看，組織內部很多時候也不完全是一個市場邏輯，這個時候一些關鍵干系人的需求就往往會直接變成業務目標慮業務、產品、技術目標通過產品目標支撐業務目標的實現其他方法：銷售、運營、資源優化等關注用戶行為的變化，而不是交付什么產品特性產品假設實際上是規劃的核心組成部分技術決定了產品交付的可行性技術理解決定產品的 insight領域模型是產品和技術的 shared understanding技術目標本來就是產品目標最后：技

3、術的效率，決定交付效率，決定了產品可以更快速驗證假設規劃的承載：OKROKR 的產出依賴大量的分析活動大型組織的研發活動需要聚焦&一致組織 OKR 對齊討論會，對齊理解，有不一致的地方討論組織上下文環境唯技術論團隊知識背景的缺失，團隊內缺乏足夠的業務和產品專業知識，這在技術主導的團隊中比較常見，他們非常容易陷入到唯技術論的狀況中而忽略了用戶價值，網上有一段著名的喬布斯被質疑不懂技術后的回答視頻，非常好的體現了這一現象。激勵方式錯誤例如：在 OKR 設定后基于 KR 的具體數字進行僵化的考核，給團隊帶來巨大的壓力，決策者會在壓力下作出明知不正確但不得不做的判斷，例如，如果團隊的管理氛圍不允許成員

4、犯錯，那么團隊成員就不會把假設放在臺面上討論，更不會去主動驗證假設了。不做量化和數據分析證假設需要成本，無論是去做量化，做數據分析，還是做用戶訪談，都需要投入非常多的資源。有時候技術系統錯綜復雜，光測量一個指標就需要很大的工程工作，有時候拜訪用戶還需要出差，還需要記錄和分析。河馬現象HiPPO，Highest Paid Persons Opinion 的縮寫，或者可以稱之為老板一言堂當團隊的最高管理者因為個人喜好、臨時感受、對下屬的偏見、或者過度自信產生的傲慢等各類因素給出決策，不用數據和邏輯支撐決策卻強勢要求執行的時候，科學的方法自然就失效了。建立豐富的團隊背景，綜合技術、產品和業務能力。鼓勵相互溝通增強理解。更科學的考核方式，不要把 OKR 等同于 KPI從長期主義看，重視量化和量化積累，并積極投入Leader 以身作則THANKS大模型正在重新定義軟件Large Language Model Is Redefining The Software