工作型管理者的產品雜記
英文原文：A Product Journal: As A Working Manager
從工程師到管理者所經歷的最大變化之一，是重新認識我平常看待的問題：我們打算怎樣搞定？做為工程師，我把問題分解為：我們需要開發的軟件是什么，為了完成目標、我們需要解決的技術壁壘是什么。做為管理者，我把問題分解為：我們完成目標的過程是什么。
當我擔任管理者角色、去問“我們打算怎樣搞定？”、得到的答案是“我不知道”時，我有些沮喪。但這是不公平的——總有一些我們不知道答案的問 題。讓我感到沮喪的是當答案來得太快、當某人說“我不知道”時，因為他們正錯過了一些東西，那就是他們覺得需要找到答案。我不知道，因為在我們知道想法是 否可行之前，我們不得不寫一些代碼。我不知道，因為決定在其他人手里，等等。
你知道！如果決定在其他人手里，那么問題的答案就演變為：我們打算問問其他人，他們想要什么以及他們打算如何做決定，然后再去做這件事。如果我 們不知道想法是否可行，那么問題的答案就演變為：我們打算探索技術可行性，一旦我們掌握更多情況、我們將進行下一次迭代計劃。“我不知道因為……”是沒有 錯誤的，因為它就是某種答案，它讓團隊以過程的形式作出了決定。“我不知道。”——以句號結尾——還算好些，如果你把它理解為“我不知道，所以我們打算通 過學習來完成”。這是我不喜歡的“我不知道，讓我們繼續吧”。
但我正有些不公平。做為管理者，在過程這一層回答問題是我的職責。然而我非常努力地把人們劃分開，或許我還應當努力地接受人們在什么時候建立了 他們角色的綁定。當你在盡量創作時，保持專注、抵御分心是有必要的。當你在團隊工作時，你應該依賴團隊成員的各種技能、以放手項目的某些部分。保持低調是 不錯的。（有時候；有時候團隊里的每個人必須抬頭并對環境作出響應。）
說來話長，我體會到在工程師和管理者的角度之間有著太多的不同。很難同時站在兩個角度，從兩個角度行動就更難了。
在我的新項目，我重回到開發，進入工作型管理者的角色，我正在執行我還在管理的相同任務，這是一種古怪的方式。當我開始管理時，我把自己從編程上剔除出來，使自己不會因新角色和不得不要做的大量學習而分心。回到編程，我可以辨別出我做的是正確的。
在這兩種心態、這兩種非常不同的工作模式之間切換，是有挑戰的。無論哪種角色，我想具有前瞻性，只不過一個是面向人的管理者，一個是面向代碼的 工程師。我投入了小塊時間，盡量保持最佳頻率的溝通，留意出現的問題，因此回報是非直接的、有滯后的。直接的和立即出現的回報就是：工作代碼。只要我知道 哪種方式是正確的，這種受限制的專注就能夠更加穩步地向前推進。
但我是一名工作型管理者。現在是調查這種奇怪日志信息的時間嗎，或考慮我應該和誰討論產品機會嗎？沒有標準來比較目前分開的兩種任務的優先級。
如果我打算找些時間做開發，那么我對面臨的兩個選擇有點兒擔心：
- 數小時后堅持編程。
- 做為管理者，開始提出一些問題。
我一直都在做這兩種選擇。為了減輕拋出問題的影響，我盡量使之透明。這或許是有效果的：我不能在 X 上做到最好，因為我正在盡量做 Y。但是我將不會真正知道這在后來是否起到了作用，關系反饋的回轉會花些時間。
順便一提：我一直在學習目標和關鍵結果（OKR）方面的東東，它是一種季度績效分析結構，對于它是如何要求人們傾向于完成既定目標的 70% 而不是 100% 深有體會。如果你完成了 100%，那么你將兌現了自己在季度開始所制定的機會。你已經移除了重點發展的方式。【注1】
無論如何，不斷向前、向上，希望我能夠一切好運。
- 注1：OKR 分數的理想值介于 0.6~0.7。如果某人持續得了 1.0，那么他們的 OKR 還不夠有抱負。分數低的不應該被懲罰，應該把它看成是幫助優化下個季度 OKR 的數據。OKR 不等同于員工考核。http://www.gv.com/lib/how-google-sets-goals-objectives-and-key-results-okrs
— END —
譯文： 《工作型管理者的產品雜記 》 臘八粥