工作型管理者的产品杂记

cg2y 10年前

英文原文：A Product Journal: As A Working Manager

从工程师到管理者所经历的最大变化之一，是重新认识我平常看待的问题：我们打算怎样搞定？做为工程师，我把问题分解为：我们需要开发的软件是什么，为了完成目标、我们需要解决的技术壁垒是什么。做为管理者，我把问题分解为：我们完成目标的过程是什么。

当我担任管理者角色、去问“我们打算怎样搞定？”、得到的答案是“我不知道”时，我有些沮丧。但这是不公平的——总有一些我们不知道答案的问 题。让我感到沮丧的是当答案来得太快、当某人说“我不知道”时，因为他们正错过了一些东西，那就是他们觉得需要找到答案。我不知道，因为在我们知道想法是 否可行之前，我们不得不写一些代码。我不知道，因为决定在其他人手里，等等。

你知道！如果决定在其他人手里，那么问题的答案就演变为：我们打算问问其他人，他们想要什么以及他们打算如何做决定，然后再去做这件事。如果我 们不知道想法是否可行，那么问题的答案就演变为：我们打算探索技术可行性，一旦我们掌握更多情况、我们将进行下一次迭代计划。“我不知道因为……”是没有 错误的，因为它就是某种答案，它让团队以过程的形式作出了决定。“我不知道。”——以句号结尾——还算好些，如果你把它理解为“我不知道，所以我们打算通 过学习来完成”。这是我不喜欢的“我不知道，让我们继续吧”。

但我正有些不公平。做为管理者，在过程这一层回答问题是我的职责。然而我非常努力地把人们划分开，或许我还应当努力地接受人们在什么时候建立了 他们角色的绑定。当你在尽量创作时，保持专注、抵御分心是有必要的。当你在团队工作时，你应该依赖团队成员的各种技能、以放手项目的某些部分。保持低调是 不错的。（有时候；有时候团队里的每个人必须抬头并对环境作出响应。）

说来话长，我体会到在工程师和管理者的角度之间有着太多的不同。很难同时站在两个角度，从两个角度行动就更难了。

在我的新项目，我重回到开发，进入工作型管理者的角色，我正在执行我还在管理的相同任务，这是一种古怪的方式。当我开始管理时，我把自己从编程上剔除出来，使自己不会因新角色和不得不要做的大量学习而分心。回到编程，我可以辨别出我做的是正确的。

在这两种心态、这两种非常不同的工作模式之间切换，是有挑战的。无论哪种角色，我想具有前瞻性，只不过一个是面向人的管理者，一个是面向代码的 工程师。我投入了小块时间，尽量保持最佳频率的沟通，留意出现的问题，因此回报是非直接的、有滞后的。直接的和立即出现的回报就是：工作代码。只要我知道 哪种方式是正确的，这种受限制的专注就能够更加稳步地向前推进。

但我是一名工作型管理者。现在是调查这种奇怪日志信息的时间吗，或考虑我应该和谁讨论产品机会吗？没有标准来比较目前分开的两种任务的优先级。

如果我打算找些时间做开发，那么我对面临的两个选择有点儿担心：

  1. 数小时后坚持编程。
  2. 做为管理者，开始提出一些问题。

我一直都在做这两种选择。为了减轻抛出问题的影响，我尽量使之透明。这或许是有效果的：我不能在 X 上做到最好，因为我正在尽量做 Y。但是我将不会真正知道这在后来是否起到了作用，关系反馈的回转会花些时间。

顺便一提：我一直在学习目标和关键结果（OKR）方面的东东，它是一种季度绩效分析结构，对于它是如何要求人们倾向于完成既定目标的 70% 而不是 100% 深有体会。如果你完成了 100%，那么你将兑现了自己在季度开始所制定的机会。你已经移除了重点发展的方式。【注1】

无论如何，不断向前、向上，希望我能够一切好运。

— END —

译文： 《工作型管理者的产品杂记 》 腊八粥