工程管理陷入困境时，该怎么办？

成为工程经理之后，你迟早会遇到各种管理困境：重要文档缺失、研发工具不完善、产品经理或项目经理缺位、项目无法按时交付，甚至发现公司和工作正在走向失控。

工程管理真正困难的地方，不是避免所有问题，而是在问题发生后，迅速判断自己究竟陷入了多大的困境，并采取正确的行动。

在我第一次登上某场海外开发者大会的舞台演讲前不久，一位来自海外软件公司的朋友送给我一件 T 恤。

为了照顾那些仍在使用纯文本浏览器的人，我直接告诉你上面写了什么：

“嗨，我是做 Macintosh 软件的。”

开发者大会的校园派对上，一支摇滚乐队正在台上卖力演出。我穿着那件 T 恤，得意扬扬地在园区里四处晃悠。

同事们很快提醒我：

“可你现在已经不亲自写软件了……你只是告诉别人该怎么写软件。”

没错。

我认。

那么，我们开始吧。

你现在是一名经理了。恭喜。

也许是因为你的代码写得太烂，决定换一种方式发挥作用；也许是因为你受够了过去遇到的那些经理，决定亲自上场，让所有人看看管理究竟应该怎么做。

我来帮你。

成为经理后的前五年，你会学到数不清的教训。

第一课通常发生在这样的时刻：有人跑来问你一个问题，而你突然意识到，他们之所以问你，并不是因为你真的知道答案，只是因为你的职位名称里有“经理”两个字。

只要你的回答听起来像那么回事，他们就可能相信。

有些人把这叫作权力。

我把它叫作责任。

接下来还有很多课程。

比如管理者绕不开的三件大事：招聘、解雇和裁员。每一件都可能给你迎头一击，让你彻夜难眠。

也有一些细小的变化。

你会发现自己越来越频繁地说“我们”；你还会发现，自己正在一遍又一遍地重复同样的话——对十二个不同的人，完整地重复十二遍。

有些事情很有趣，有些事情枯燥得要命。

但这些都比不上那种感觉：

你把事情彻底搞砸了。

工程经理陷入困境是什么感觉？

深陷困境是一种非常特殊的工作状态。

一切顺利时，你可以早上来到公司，悠闲地喝杯热饮，直到上午 11 点才开始当天的第一个会议。

陷入困境时则完全相反。

你刚走出电梯，就被一群人团团围住。你甚至来不及查看邮件，而这种状态仿佛会一直持续到冬天。

那是一种精神上的麻痹。

也是一场职业生涯中的恐慌。

但陷入困境，同样是一次证明自己的机会。

从困境中走出来，会给你带来自信、经验和尊重。但在解决问题之前，你首先要弄清楚：自己究竟陷得有多深。

如果你根本不想摆脱困境，那么这篇文章并不适合你。

我假设你对自己的职业生涯仍然充满热情。你想承担更多责任，获得更高的收入；如果一切顺利，你甚至还想改变世界。

也许是因为我经历的挫折还不够多，但我始终无法理解那些浑浑噩噩过日子的人。他们只完成最基本的工作，勉强维持生活，而且似乎还挺享受。

你到底在享受什么？

当然，也许你的日常工作并不是你真正的理想。

但我喜欢自己的工作。

所以，让我们开始。

1. 重要文档缺失，所有人都在催你

混乱程度：低

在产品开发的早期阶段，所有人都喜欢强调一件事：

把一切都写下来。

市场需求文档、工程规格说明、产品规格、技术方案……

文档，文档，还是文档。

项目里程碑通常也围绕这些材料设定。但现实往往是，一个又一个里程碑过去了，却没有多少人真正关心这些文档是否缺失，或者是否已经完整。

这是个好消息。

因为缺少某一份文件，通常并不是你真正的麻烦。

真正的问题是：

谁在向你索要这份文件？他们为什么需要它？

如果对方确实有充分理由需要这些信息，那么你可能真的遇到麻烦了。

这意味着有人因为缺少必要信息而无法完成自己的工作，进而可能导致整个任务失败。

这当然很糟糕。

因为他们会非常生气，然后把责任推到你身上。

这里送你一条友情提示：

不要把“对方需要一些信息”，误解成“对方要求你立刻提交一份完整、完美、无懈可击的答案”。

完美主义者尤其容易犯这个错误：

“既然我要回答这个问题，就必须彻底、完整地回答。既然要完整回答，就得先找一个合适的模板，再设计结构，然后……”

两周过去了。

提出问题的人早已转向下一件事。

你不仅错过了展示专业能力的最佳时机，还可能被贴上“难以合作”或者“不可靠”的标签。

真是太棒了。

大型组织确实需要更多文档，而且这种需要通常是合理的。

因为大型组织中的沟通极其困难。每个人都有自己的观点，你永远不知道谁会突然提出一个绝妙的想法。

另一方面，大型公司之所以不断强化文档制度，也是因为各级管理者很难准确了解和衡量庞大团队中真正发生了什么。

因此，团队平时最好就把任务、项目进展和关键文档放在统一的协作环境中持续沉淀。例如，使用 Worktile 管理任务、项目和文档，可以减少信息分散在聊天记录、个人电脑和不同表格中的情况。这样做的目的不是增加记录负担，而是避免真正出现问题时，所有人才开始四处寻找信息。

但是，如果你此刻正因为缺少某份重要文件而焦头烂额，不妨先看看，究竟是谁让你产生了这种感觉。

然后问自己：

对方是在真诚地询问事实，还是管理层又在进行毫无意义的折腾？

如果他们确实需要事实，而时间又非常紧张，那么面对面沟通几乎永远是最好的解决方式。

读到这里，你可能觉得我在反对写文档。

这当然很荒唐。

拜托，我自己就是写博客的人。

别忘了，这篇文章讨论的是“当你陷入困境时该怎么办”。

我说的是那种天仿佛马上就要塌下来、你必须迅速采取行动的时刻。

当然，我完全可以从另一个角度论证：认真、持续地记录信息，本身就是避免这种危机的有效方式。

因为把事情写下来，是让信息大规模传播的绝佳手段。

毕竟，你不可能亲自向每个人解释一遍。

2. 研发团队缺少关键开发工具

麻烦程度：取决于缺少什么工具

工程师喜欢在开发过程中使用各种各样的工具，但真正不可缺少的，通常只有四类：

• 编辑器
• 编译器
• 版本控制系统
• 缺陷跟踪系统

我几乎没有见过完全没有编辑器或编译器的工程组织。

但令人震惊的是，我确实走进过一些团队，发现他们既没有版本控制，也没有缺陷跟踪系统。

如果你不幸遇到这种情况，那么你的第一要务——甚至应该在你坐到办公桌前之前——就是让这些工具立即投入使用。

否则，你和团队将永远处在混乱之中。

任何超过两个人的工程团队，一旦产品开发真正运转起来，却仍然缺少版本控制和缺陷跟踪系统，都很快会陷入崩溃。

这些工具能够帮助研发团队做到几件事。

第一，在协作时彼此尊重，互不干扰。

你负责这一部分，我负责另一部分。

第二，明确每个人对工作的责任。

是谁提交了这段代码？

这个缺陷到底由谁负责？

第三，衡量研发工作的状态。

我这里还有多少个缺陷？

你那里又有多少？

第四，保留团队的工作记忆。

等等，这堆乱七八糟的代码到底是谁批准合入的？

在规模稍大的研发团队中，仅仅分别部署这些工具还不够。需求、任务、代码、缺陷、测试和发布信息如果彼此割裂，管理者仍然很难看到完整事实。像 PingCode 这样的研发管理工具，可以把需求规划、项目开发、缺陷跟踪、测试发布和知识沉淀连接起来，并接入团队原有的研发工具，让不同环节的数据能够连续流转。

在管理生涯的早期，你很快就会发现，人们走进你办公室，很多时候都是因为他们需要你解决冲突。

等冲突双方终于停止争吵后，你需要引导他们重新关注事实。

因为事实能让人回到现实。

回到现实，就意味着更少的争吵。

上面提到的这些研发管理工具，正是帮助你获得确凿事实的最好方式之一。

这非常有用。

3. 产品经理或项目经理缺位怎么办？

混乱程度：中等

作为工程经理，你通常需要两位重要的合作伙伴。

第一位是产品经理。

产品经理代表团队与客户和市场沟通，理解客户真正需要什么。

第二位是项目经理。

项目经理负责流程、协调和信息传递。

项目经理的角色常常很难定义，因为很多工程经理会把项目经理的职责与自己的职责混在一起。

简单来说，项目经理负责产品交付的整个过程。

你可以这样理解：

作为工程经理，你负责把最终产品交付出来；项目经理则要确保产品按照正确的方式完成包装、发布和上市。

不要以为这只是一些无关紧要的杂事。

这是一项工作量极其庞大的任务。

产品经理和项目经理，本质上都是信息传递者。

产品经理负责传递客户和市场的信息。他们告诉你客户想要什么，你负责把它开发出来。产品发布后，他们还会告诉你市场反馈如何。

项目经理传递的则是组织信息。

无论你遇到什么问题，他们要么知道答案，要么知道应该向谁询问。

优秀的项目经理还是流程专家。他们会确保各种事情按照正确顺序发生，让整个项目保持秩序。

关于项目经理的一段题外话

我之所以如此坚定地相信项目经理的价值，是因为自己曾经付出过惨痛代价。

我加入一家海外初创公司时，公司只有二十个人，而我是第一位工程经理。

接下来的两年里，公司扩张到了 250 人，我也开始同时负责三条产品线。

就在那个阶段，高管团队成立了项目管理办公室。

我的第一反应是：

“这些人到底是来干什么的？负责开会和记会议纪要吗？天啊，简直是在浪费时间。”

我错得离谱。

优秀的项目经理是细节管理者。

他们会接手产品发布过程中堆积如山的琐碎事务。你很难想象，一个优秀的项目经理能够为普通工程经理节省多少时间。

如果你无法与产品经理或项目经理合作，或者公司里根本没有这些角色，你面临的后果其实差不多：

你必须替他们完成工作。

这意味着，你真正能够投入工程管理的时间会越来越少。

你甚至可能感觉不到情况有多糟，因为你每天都忙得不可开交。

但现实是，你正在为了确保产品发布中的每一个细节都完美无缺，一点一点浪费自己的时间，并同时伤害团队和产品。

在这两类角色中，产品经理缺席或能力不足，通常更加危险。

因为产品经理提供的信息，会直接影响整个团队应该做什么。

如果时间紧迫，而你突然脱口而出：

“我知道客户真正需要什么。”

事情只会变得更糟。

让我再说一遍：

你不知道。

除非你的产品专门卖给软件工程经理，否则你的个人意见很可能并不重要。

抱歉。

4. 项目无法按时交付怎么办？

糟糕程度：希望没有你想象中那么严重

首先，你必须记住：

任何重要产品在开发周期的最后一个月，团队成员都会逐渐失去理智。

真的。

他们会变得非常疯狂。

因为他们已经盯着这个该死的产品看了太久，对其中的每一个组件都产生了强烈的情感依赖。

而这种情感依赖，会促使他们做出一些不理智、甚至完全不合逻辑的事情。

这里说的也包括你，疯狂的工程经理先生。

距离发布日期只剩两周，你已经坚信产品绝对无法完成。

你的判断是：

“这东西就是一堆垃圾。”

此时存在两种可能，而且两种情况发生的概率差不多。

第一种情况：你已经离产品太近了

你可能过于熟悉这个产品，以至于已经失去了判断质量的能力。

这种亲密感蒙蔽了你。

你心目中的“成熟产品”，与客户眼中“足够好用的产品”，很可能根本不是一回事。

如果你在某个短暂清醒的时刻意识到自己可能处于这种状态，最好的办法是找一个你信任的人，帮助你进行评估。

你可能会本能地想到质量保证团队。

但他们很可能和你一样，已经深深卷入这个产品；而且他们通常对质量问题更加敏感。

也许可以找你的老板。

也许是另一位工程经理。

具体找谁并不重要。

重要的是，这个人不能是过去三个月一直埋头研究这个“永远无法发布”的产品的人。

当你找到一个仍然保持理智的人时，他应该问你一些这样的问题：

• 计划中的功能都完成了吗？完成到了什么程度？
• 这些功能能够被有效测试吗？
• 目前还剩多少个缺陷？
• 团队每天能够修复多少个缺陷？
• 你愿意带着多少个已知缺陷发布产品？
• 哪些缺陷可以延期处理？判断标准是什么？
• 产品发布后的更新和修复策略是什么？

这个理智之人的职责，不是替你作决定。

他的职责是保持中立，并通过提出高质量的问题，帮助你建立一个更可靠的项目决策框架。

作为一名新经理，你可能不愿意寻求外部意见。

因为你觉得求助是软弱的表现。

你错了。

向团队成员求助，可以让他们把各自独特的经验带入问题，帮助你作出更好的决策，也会让整个团队变得更强。

寻求帮助非常重要。

一定要这样做。

而且要经常这样做。

第二种情况：你是对的，产品真的没有准备好

第一种情况是，你需要第二意见。

第二种情况则是：你说得完全正确。

产品距离能够交付给客户还差得很远，而距离原定发布日期只剩十四个工作日。

你和团队正在全力冲刺，试图赶上进度。

但几乎每个人都在缓缓摇头，低声嘀咕：

“它根本没准备好。”

这一次，你不需要寻求第二意见。

因为事实已经非常清楚。

团队仍在继续开发新功能。

质量保证团队已经愤怒到了极点。

项目经理正在自己的办公室里哭。

是的。

产品真的还没准备好。

作为普通员工，你的工作可能只是抱怨。

而且从某种角度看，抱怨并不是坏事。

抱怨也是一种信息传递。如果你的经理认真倾听，他们应该能够理解你想表达什么。

但现在的问题是：

你就是经理。

你的职责不再是抱怨，而是主动纠正错误。

因为晚一点交付，通常也比交付一个糟糕的产品更好。

如果你是第一次遇到这种情况，你可能会觉得自己比实际处境更加危险。

但现实是，大多数人本来就不会完全相信工程团队给出的项目时间表。

这几乎已经成了某种行业常识。

如果工程团队说一个功能需要一个月，最后可能会花三个月。

好吧，说工程师在撒谎，也许有点过分。

我们没有撒谎。

我们真的已经尽力了，我发誓。

只是说实话，在完成一半之前，我们自己通常也不知道一个功能到底需要多久。

不同组织会用不同方式，应对软件开发天然存在的不确定性。

有些产品团队会在计划中预留缓冲时间。

还有一些团队会设置一个神秘的“发布后”里程碑——而所有人其实都知道，那个日期才是真正的发布日期。

关键在于：

如果这是该产品第一次提出延期，当产品团队问你“你到底还需要多少时间”时，事情很可能没有你想象得那么糟。

你之前不知道自己参加的是一场扑克游戏吗？

现在你知道了。

不要在最后一刻宣布项目延期

如果你还想在组织中建立信誉，就不要等到项目最后阶段才突然宣布产品无法按期发布。

这种做法只会破坏你的公信力。

优秀的工程经理和项目经理，会在功能规划和项目进度安排中设置多个检查点，并在项目推进过程中不断调整。

这些检查点能够逐步增强所有人对最终发布日期的信心。

在最后一刻突然修改计划，违反了我的第三条管理禁忌：

不要让别人感到意外。

5. 公司和工作正在变得越来越糟

混乱程度：高

这是一件真实发生过的事。

20 世纪 90 年代初，一家海外老牌软件公司在与行业巨头的竞争中节节败退。

它试图将旗下办公软件全面迁移到新的操作系统平台，但整个计划推进得一塌糊涂。

竞争对手已经建立了难以撼动的市场地位。他们把办公套件中的多个产品捆绑销售，并以极具攻击性的价格抢占市场。

于是，这家老牌软件公司曾经颇具影响力的数据库和电子表格产品，逐渐从市场中消失。

此前，公司已经扩张了很多年，还搬进了一座直到今天看起来仍然十分气派的新园区。

但它正在走向崩溃。

而我非常清楚这一点。

在这种情况下，摆脱职业困境的第一步是：

察觉。

你必须意识到，这艘船正在下沉。

即使高管们仍然在全体员工大会上表现得无比乐观。

当然，他们必须乐观。

如果所有员工都普遍相信天马上就要塌了，那么这些全员会议很快就会变成空无一人的房间。

我当时做了什么？

我离职了。

我带着工程师的头衔，去了另一家海外数据库公司。

那家公司现在也已经倒闭了。

问题在于，新公司的实际状况，比我离开的公司还要糟糕。

它可能在我加入之前一年，就已经开始走向死亡。

但直到入职一个月后，我才意识到这一点。

当初那位热情洋溢、极具远见的招聘经理突然离职，我才发现，自己已经被留在了一群长期情绪低落的数据库开发人员中间。

我们每天调试构建系统，喝着难以下咽的咖啡。

糟糕。

显然，当你的公司烂透了，摆脱困境通常需要经历两个阶段。

第一阶段仍然是：

察觉。

直到今天，原来的公司里或许还有人在抱怨和十几年前完全相同的问题。

我们姑且把他们称为“伪抱怨者”。

他们会不停抱怨，却永远不会采取任何行动。

因为对他们来说，抱怨本身就已经足够了。

但你不是伪抱怨者。

否则，你不会一直读到这里。

你想改变自己现在的处境。

你想继续向前。

你想进入一个能够让你：

• 获得加薪
• 得到晋升
• 从事真正感兴趣的工作
• 不必为一家糟糕的公司卖命

的环境。

离开上一家公司后，我在加薪和晋升两方面都取得了成功。

但在“去一家不糟糕的公司”这件事上，我彻底失败了。

后来我还发现，自己同样没能做上真正感兴趣的事情。

那是我职业生涯中最糟糕的一次转型。

我花了整整一年，才重新找回那种感觉：

我正在继续前进。

优秀的管理者，应该让团队、产品和自己的职业生涯，都保持前进的速度。

管理者需要保持前进的速度

“速度”这个词，比“向上流动”更准确。

它代表的是一种持续前进的势头。

至于怎样建立属于你自己的职业发展速度，最终完全取决于你。

我那些似乎无穷无尽的管理建议，终究也只是建议。

你真正需要的，其实是我的经验。

但我没有办法把经验直接交给你。

因为获得经验只有一种方式：

你必须亲自陷入困境。

当你深陷其中、恐惧不已时，也许你会突然想起某条有用的建议。

也许你会找到一个比我更巧妙的解决方案。

无论如何，你最终都会走出来。

到那时，你前进的速度可能会更快。

也可能会更慢。

但那会是属于你自己的速度。