管理工程师：给问题，而不是方案

在研发管理和工程团队协作中，一个常见误区是：管理者太早给出解决方案，却没有充分说明问题本身。《星际迷航：深空九号》第四季第七集《星舰坠落》中，有一个场景很好地说明了管理工程师的一条重要原则：给工程师问题，而不是直接给方案。

在这个场景里，沃夫用典型的克林贡式强硬语气向工程团队下达命令：“你，去做这个！你，去做那个！”工程师们听后明显畏缩，士气也迅速低落。沃夫对此感到很困惑。

首席工程师奥布莱恩把沃夫拉到一旁，试图告诉他还有更好的方式。“他们不是舰桥军官，”奥布莱恩解释说，“他们没有上过星际舰队学院。他们是工程师。他们习惯的是先理解问题，然后自己想办法解决。”

沃夫仍然很不解：为什么人们就不能直接服从命令呢？

后来，当船员们准备迎击杰姆哈达人的进攻时，沃夫想起了奥布莱恩的建议。这一次，他没有继续大声下达命令，而是召集工程师们说：“我需要你们的帮助。我需要一件武器。”接着，他解释了当前形势有多紧迫，以及他们需要达成什么目标。

工程师们脸上的恐惧很快消失了，取而代之的是兴奋。一名工程师提出了一个方案，沃夫批准后，团队立刻行动起来，迫不及待地投入到解决问题的工作中。

沃夫几乎不敢相信，奥布莱恩的建议竟然这么有效。奥布莱恩只是心照不宣地笑了笑。

为什么工程师更需要问题，而不是方案

每当我讲起这个场景时，通常会听到两类反应。

第一类反应是：“你是不是想说《星际迷航：下一代》？沃夫并没有出现在《星际迷航：深空九号》里。”

是的，亲爱的读者，莫格之子沃夫确实在第四季加入了《深空九号》。他从《星际迷航：下一代》转入这部剧，部分原因是为了提升收视表现。如果你当时已经弃剧，可能就错过了这一点。后来，他一直留在《深空九号》，直到全剧完结。可见，某些海外收视率统计机构的数据也未必总能说明问题。

另一类更相关的反应，则集中在这种管理方法对现实中的工程师是否真的有效。

答案是：有效。因为很多工程师本质上都喜欢解谜。这个职业吸引的，往往正是那些喜欢分析问题、寻找答案、不断试错的人。他们从找到解决方案的过程中获得满足感，即使这个过程需要反复尝试。当他们看到自己的方案被采纳并真正落地时，也会感到自己发挥了价值。

把问题交给工程师，而不是直接把方案交给工程师，可以激发他们的创造力，也能促进团队协作。工程师通常渴望有机会探索、发明、启发彼此，并与他人并肩解决问题。这个过程能让他们充分发挥自己的专业能力。相比被动接受任务，主动解决问题更容易带来主人翁意识和使命感。

反过来，如果你直接告诉他们要采用什么方案，而不是告诉他们你遇到了什么问题，你实际上就剥夺了他们发挥作用、释放创造力和协作解决问题的机会。你也剥夺了他们与同伴一起攻克难题的社交体验。如果你的工程团队士气低落，这很可能就是原因之一。

从问题出发，不仅能提升士气，也更容易带来更好的方案。如果工程师不了解问题的关键细节，就无法全面理解问题，也无法判断某个方案是否真正有效。这样往往会导致错误方案、无效绕路和注意力分散。只有把问题讲完整，团队才能看到问题的全貌。

此外，虽然这可能让人有些难以接受，但你提出的方案未必就是最佳方案。你花了多年时间组建了一支聪明、能干、技能各异又彼此互补的团队，那就应该让他们真正发挥作用。研究表明，多元化团队通常能够提出更多潜在方案，并从中筛选出更好的答案。直接指定方案，会让团队失去这个机会。

更重要的是，当老板直接给出方案时，很容易压制团队的创造力。没错，团队成员也许仍然可以提出其他想法，但他们已经接收到一个隐含信号：最好别多说。因为老板已经说明了“正确答案”是什么，这会让他们停止继续思考。

即使在确实只有一个可行方案的情况下，这种方法依然能激励团队。当人们相信自己是在为自己的想法而努力时，他们通常会更有动力。而且，有些看似唯一的方案，往往并不是唯一方案。你可能会惊讶地发现，自己并不了解所有可能性。

我们之所以组建团队，正是为了获得多元经验和互补技能。不要用“我不需要你们思考”的信号，扼杀他们的创造力。

大型项目管理中需要设置护栏

当然，当错误决策的代价很高、转换成本很高，或者后续修改非常困难时，确实需要设置更多护栏。

不过，对于规模庞大或极其复杂的问题，如果一开始就给出过多限制条件，也可能适得其反。团队可能会因此感到压力过大，创造力也会受到抑制。在这种情况下，一份初步方案可以帮助降低问题难度，为团队提供一个可以讨论和迭代的起点。

同时，你也可以要求团队把大问题拆解成更小的组成部分。这个过程会促使他们深入分析问题，从而加深理解、降低畏难情绪。在实际研发管理中，这类拆解最好不要停留在口头讨论里，而应沉淀为清晰的问题描述、目标、约束、任务分工和评审记录。例如，团队可以借助 PingCode 这类研发管理工具，把从目标制定、需求拆解、评审排期到开发、测试、发布的过程串联起来，并将关键背景和决策沉淀到 Wiki 中，避免“问题还没讲清楚，团队就已经开始执行”。

创建多个原型也是一种降低风险的好方法。如果有几个显而易见的解决方案，不妨要求团队做出更多原型。这样可以鼓励他们跳出最直观的答案，探索一些不那么明显、但可能更有价值的思路。

这种问题驱动方法也适用于生活和关系

这种方法并不只适用于办公室。

我的一位朋友曾试图推动自己的亲密关系朝着新的方向发展。几个月来，她不断提出一些具体要求，但始终没有效果。后来，她改变了策略。她不再只提出具体做法，而是坦诚告诉伴侣：自己有哪些需求一直没有被满足。

结果，她的伴侣不仅做出了她原本希望看到的改变，还做出了一些她从未想过的改变。因为他参与了问题解决的过程，所以更愿意持续投入这些改变。而这在过去从未发生过。

我自己也用过这个方法，效果同样不错。

我觉得家门前院的树篱太高了，想至少修剪掉一半。此前我几次试图说服妻子，都没有成功。于是我改变了策略。我先等了几个星期，让这件事冷却下来。后来有一天，我提到行人经过我们家门口时，都不得不低头避开伸出来的树枝。她走到外面，亲眼看到了这个问题。很快，修剪树篱就变成了她自己的想法。

总结：优秀的工程团队管理，要先讲清楚问题

这项技巧的核心，是讲清楚“为什么”，而不是直接规定“怎么做”。

与其直接指定解决方案，不如清楚描述问题、约束条件和预期结果，让团队自己探索解决路径。这样做可以激发创造力，培养共同责任感，推动协作式问题解决，也能激励团队寻找真正更好的方案。

无论你是在解决技术问题、开发新产品、改善人际关系，还是处理园艺决策，这种方法都同样有效。最重要的是，它能让每个人都对自己的贡献产生真实的价值感。

如果你的团队、部门或组织士气低落，不妨想一想：人们是不是只被告知了“怎么做”，却没有被告知“为什么”。在工程团队管理中，真正值得优先解决的，往往不是方案本身，而是如何让团队理解问题，并参与到解决问题的过程中。