關於尊重使用AI的指南

將傳統的軟體基礎設施組織融入產品管理，並轉向平臺工程，已成為當今的熱門趨勢。作為親身經歷過這兩種轉型的人，我毫不驚訝地看到許多人在此過程中掙扎。這些轉變要求從孤立的、流程驅動的技術思維轉向以組合、可用性和客戶為中心的思維。這是一場艱難的變革，對於那些整個職業生涯都在構建基礎設施的人來說，很容易誤解產品和平臺的含義。因此，我想分享成功的秘訣：整個工程文化必須改變。

基礎設施組織在許多方面表現出色：成本管理、供應商談判、大規模系統執行。他們擁有精通資料庫、網路和核心除錯的專家，甚至可能擅長處理來自數十個團隊的故障請求、規劃大規模故障測試和協調大規模遷移。然而，他們通常不擅長思考使用者的需求、考慮使用者的偏好，也不把使用者視為需要留住的客戶。為什麼他們會這樣？因為使用者是被迫使用他們的系統的！正如我在關於內部平臺產品的文章中所提到的，這是平臺和基礎設施團隊必須克服的重大挑戰。

這種以成本、規模和流程為中心，忽視人和可用性的文化很難根除，而且你不想在這個過程中失去那些寶貴的技能。那麼該怎麼辦？你不能簡單地僱傭產品經理就了事。首先，要清楚一點：即使能找到足夠多願意從事這類工作的優秀產品經理（實際上很難），產品經理只有與願意配合的工程團隊合作才能發揮作用。如果工程團隊沒有為客戶交付優秀產品的責任感，產品經理很可能淪為高階的待辦事項整理者，而不是真正的產品領導者。

你需要改變支援產品的方式。工單系統黑洞是讓客戶感到自己更像負擔而非關注物件的典型方式。我理解管理大量請求很困難，但密切關注支援方式、響應時間和問題分類對於轉型至關重要。工程師應該花時間支援自己的產品。如果他們不經常回答問題，就會錯過理解客戶痛苦的機會。注意不要將此視為可選任務或只交給初級工程師。高階工程師如果不善於禮貌且有效地與使用者互動，就無法構建人性化的產品。如果你擔心某人在支援場景中的表現，那麼這個人可能正在構建難以使用的產品。隨著時間的推移，你可能會發現需要重做很多工作，因為那些程式碼難以支援且引發大量投訴。

你需要更新面試流程。我建議在所有面試中加入“客戶同理心”的篩選。這不一定要深入，可以簡單地問他們如何考慮編寫程式碼以便其他開發者理解，或者他們如何回答關於構建的系統的問題。但你要設定基調：期望開發者不僅要考慮如何構建系統，還要考慮使用或協作的人。

你需要更新認可和獎勵體系。如果你只提拔解決重大技術問題的人，那麼很難留住那些致力於改善可用性、積極傾聽客戶團隊並調整工作優先順序以解決最痛苦問題的員工。因此，要仔細審視你在慶祝、獎勵和晉升什麼，確保包括使產品變得更好的工作，即使它不是最難的技術部分。請記住，這是文化變革，而文化變革如果不涉及認可和獎勵方面的價值觀變化，註定會失敗。

你的專案經理是否過多？在基礎設施組織中，過度依賴專案經理可能導致缺乏關於遷移等技術任務的前期規劃。如果你的遷移如此痛苦，以至於團隊和客戶團隊都需要專案經理來了解依賴關係和跟蹤進度，那麼你並沒有承擔起軟體使用者體驗的責任。是的，遷移是使用者體驗的一部分！令我驚訝的是，基礎設施團隊經常提供與現有系統不相容的新系統，並期望客戶自行完成所有遷移工作，而且通常按照發起方規定的時間表。如果轉向平臺模式，你需要承擔比現在更多的遷移工作。平臺的價值主張必須包括降低客戶的遷移痛苦，這意味著提高自行完成遷移的能力。透過限制專案經理的數量，迫使工程師面對他們不想做的專案管理工作，優秀者會意識到，如果他們建立自動化支援遷移（例如依賴檢測、相容性橋樑庫或允許更改內部而不改變客戶端庫的抽象），就不必做那麼多繁瑣的專案管理工作。節省自己的時間也節省了客戶的時間。因此，限制專案經理是一個很好的推動力。只需確保給團隊時間完成這些工作，而不是讓他們痛苦或把專案管理工作轉嫁給新產品經理。

你的團隊將花更多時間與客戶溝通，而非純粹編寫程式碼。工程團隊的產品思維轉型沒有捷徑。你不能只新增一個產品經理或每季度召開一次客戶諮詢委員會會議就了事。團隊需要花更多時間與客戶在一起，並戰略性地規劃如何解決整體問題，而不是僅僅處理最新的客戶投訴。改變工作方式會有前期成本：他們可能完成更少的工單或其他流程導向的生產力指標，工作速度可能看起來比之前處理無盡工單時慢。但隨著時間的推移，產出的工作質量會提高，體現在客戶調查、採用率、遷移時間線以及最終的工程生產力上。

保持樂趣！當公司經歷這種轉型時，基礎設施組織與其他業務/產品工程團隊之間往往存在嚴重的對立狀態。這種情況對基礎設施組織來說從來都不好受。無論他們如何聲稱使用者無可救藥或忘恩負義，與使用者保持對抗性關係以及與同事陷入“我們對抗他們”的動態中都不是有趣的事。因此，雖然轉型會棘手，但如果你允許，它也可以變得有趣。收集使用者對產品喜愛之處的反饋，分享收到的讚譽，並花時間慶祝客戶滿意度指標的改善。確保團隊在因他們的工作使應用團隊能夠做到以前無法做到的事情時參與慶祝。這是一次激動人心的機會，是學習、現代化工作方法和創造更積極文化的契機。以積極的態度領導將使每個人更加享受這個過程。

總而言之，這種文化轉變在很多方面與“devops/SRE”變革相似。SRE組織的工程師不會故意構建程式碼然後扔給運維團隊。同樣，產品導向組織的工程師不會不考慮使用者就構建軟體。這些轉型對工程團隊提出了更高要求，但帶來了更高質量的成果。這需要時間和成本，但我保證，這是值得的。

喜歡這篇文章嗎？你可能也會喜歡我的書《經理的路徑》（The Manager's Path），可在亞馬遜和Safari Online購買。