在研发管理和工程团队协作中一个常见误区是管理者太早给出解决方案却没有充分说明问题本身。《星际迷航深空九号》第四季第七集《星舰坠落》中有一个场景很好地说明了管理工程师的一条重要原则给工程师问题而不是直接给方案。在这个场景里沃夫用典型的克林贡式强硬语气向工程团队下达命令“你去做这个你去做那个”工程师们听后明显畏缩士气也迅速低落。沃夫对此感到很困惑。首席工程师奥布莱恩把沃夫拉到一旁试图告诉他还有更好的方式。“他们不是舰桥军官”奥布莱恩解释说“他们没有上过星际舰队学院。他们是工程师。他们习惯的是先理解问题然后自己想办法解决。”沃夫仍然很不解为什么人们就不能直接服从命令呢后来当船员们准备迎击杰姆哈达人的进攻时沃夫想起了奥布莱恩的建议。这一次他没有继续大声下达命令而是召集工程师们说“我需要你们的帮助。我需要一件武器。”接着他解释了当前形势有多紧迫以及他们需要达成什么目标。工程师们脸上的恐惧很快消失了取而代之的是兴奋。一名工程师提出了一个方案沃夫批准后团队立刻行动起来迫不及待地投入到解决问题的工作中。沃夫几乎不敢相信奥布莱恩的建议竟然这么有效。奥布莱恩只是心照不宣地笑了笑。为什么工程师更需要问题而不是方案每当我讲起这个场景时通常会听到两类反应。第一类反应是“你是不是想说《星际迷航下一代》沃夫并没有出现在《星际迷航深空九号》里。”是的亲爱的读者莫格之子沃夫确实在第四季加入了《深空九号》。他从《星际迷航下一代》转入这部剧部分原因是为了提升收视表现。如果你当时已经弃剧可能就错过了这一点。后来他一直留在《深空九号》直到全剧完结。可见某些海外收视率统计机构的数据也未必总能说明问题。另一类更相关的反应则集中在这种管理方法对现实中的工程师是否真的有效。答案是有效。因为很多工程师本质上都喜欢解谜。这个职业吸引的往往正是那些喜欢分析问题、寻找答案、不断试错的人。他们从找到解决方案的过程中获得满足感即使这个过程需要反复尝试。当他们看到自己的方案被采纳并真正落地时也会感到自己发挥了价值。把问题交给工程师而不是直接把方案交给工程师可以激发他们的创造力也能促进团队协作。工程师通常渴望有机会探索、发明、启发彼此并与他人并肩解决问题。这个过程能让他们充分发挥自己的专业能力。相比被动接受任务主动解决问题更容易带来主人翁意识和使命感。反过来如果你直接告诉他们要采用什么方案而不是告诉他们你遇到了什么问题你实际上就剥夺了他们发挥作用、释放创造力和协作解决问题的机会。你也剥夺了他们与同伴一起攻克难题的社交体验。如果你的工程团队士气低落这很可能就是原因之一。从问题出发不仅能提升士气也更容易带来更好的方案。如果工程师不了解问题的关键细节就无法全面理解问题也无法判断某个方案是否真正有效。这样往往会导致错误方案、无效绕路和注意力分散。只有把问题讲完整团队才能看到问题的全貌。此外虽然这可能让人有些难以接受但你提出的方案未必就是最佳方案。你花了多年时间组建了一支聪明、能干、技能各异又彼此互补的团队那就应该让他们真正发挥作用。研究表明多元化团队通常能够提出更多潜在方案并从中筛选出更好的答案。直接指定方案会让团队失去这个机会。更重要的是当老板直接给出方案时很容易压制团队的创造力。没错团队成员也许仍然可以提出其他想法但他们已经接收到一个隐含信号最好别多说。因为老板已经说明了“正确答案”是什么这会让他们停止继续思考。即使在确实只有一个可行方案的情况下这种方法依然能激励团队。当人们相信自己是在为自己的想法而努力时他们通常会更有动力。而且有些看似唯一的方案往往并不是唯一方案。你可能会惊讶地发现自己并不了解所有可能性。我们之所以组建团队正是为了获得多元经验和互补技能。不要用“我不需要你们思考”的信号扼杀他们的创造力。大型项目管理中需要设置护栏当然当错误决策的代价很高、转换成本很高或者后续修改非常困难时确实需要设置更多护栏。不过对于规模庞大或极其复杂的问题如果一开始就给出过多限制条件也可能适得其反。团队可能会因此感到压力过大创造力也会受到抑制。在这种情况下一份初步方案可以帮助降低问题难度为团队提供一个可以讨论和迭代的起点。同时你也可以要求团队把大问题拆解成更小的组成部分。这个过程会促使他们深入分析问题从而加深理解、降低畏难情绪。在实际研发管理中这类拆解最好不要停留在口头讨论里而应沉淀为清晰的问题描述、目标、约束、任务分工和评审记录。例如团队可以借助PingCode这类研发管理工具把从目标制定、需求拆解、评审排期到开发、测试、发布的过程串联起来并将关键背景和决策沉淀到 Wiki 中避免“问题还没讲清楚团队就已经开始执行”。创建多个原型也是一种降低风险的好方法。如果有几个显而易见的解决方案不妨要求团队做出更多原型。这样可以鼓励他们跳出最直观的答案探索一些不那么明显、但可能更有价值的思路。这种问题驱动方法也适用于生活和关系这种方法并不只适用于办公室。我的一位朋友曾试图推动自己的亲密关系朝着新的方向发展。几个月来她不断提出一些具体要求但始终没有效果。后来她改变了策略。她不再只提出具体做法而是坦诚告诉伴侣自己有哪些需求一直没有被满足。结果她的伴侣不仅做出了她原本希望看到的改变还做出了一些她从未想过的改变。因为他参与了问题解决的过程所以更愿意持续投入这些改变。而这在过去从未发生过。我自己也用过这个方法效果同样不错。我觉得家门前院的树篱太高了想至少修剪掉一半。此前我几次试图说服妻子都没有成功。于是我改变了策略。我先等了几个星期让这件事冷却下来。后来有一天我提到行人经过我们家门口时都不得不低头避开伸出来的树枝。她走到外面亲眼看到了这个问题。很快修剪树篱就变成了她自己的想法。总结优秀的工程团队管理要先讲清楚问题这项技巧的核心是讲清楚“为什么”而不是直接规定“怎么做”。与其直接指定解决方案不如清楚描述问题、约束条件和预期结果让团队自己探索解决路径。这样做可以激发创造力培养共同责任感推动协作式问题解决也能激励团队寻找真正更好的方案。无论你是在解决技术问题、开发新产品、改善人际关系还是处理园艺决策这种方法都同样有效。最重要的是它能让每个人都对自己的贡献产生真实的价值感。如果你的团队、部门或组织士气低落不妨想一想人们是不是只被告知了“怎么做”却没有被告知“为什么”。在工程团队管理中真正值得优先解决的往往不是方案本身而是如何让团队理解问题并参与到解决问题的过程中。
