协作 | 1. 工程师之间的市场化协作

梵高

 View of the Church of Saint-Paul-de-Mausole

工程师已经和工厂里的工人没有多大区别。工程师就是产品设计流水线上的一名工人。我们接受上游的输入数据，我们设计的方案要交给下游专业使用。大家眼里的优秀工程师，就是按时交出符合要求的方案，不耽误设计流水线正常运行。

这种在明确要求下的协作，如果设计一种简单重复的产品，这么协作也没有问题。

今天，已经很少有简单重复的设计，大多数产品都是创新设计。这么流水线式的协作，效率很低，还可能永远无法完成。

为什么会这样呢？因为无法对创新设计提出准确的要求。有句话特别真实，“只有做完了，才知道当初应当提什么要求。”

领导作为要求的制定者，只能根据老经验，给工程师提要求，这位负责重量减小十公斤，那位负责阻力减小10%。或者开会协调对大家的要求，这种会议立即成为哭穷大会，每个人都强调，自己的专业太难，实现不了技术指标，必须由别的工程师去实现。

不难理解，为什么创新设计往往更需要“哭”和“苦”，需要加班加点的长明灯，带病坚持工作的眼泪。

因为没有人知道每位工程师的工作到底有多难。有些人只好借助这些手法，提高自己的“难度”，在制定要求的时候，给自己留下余量。

这种统一制定要求的协作，看起来特别可靠，好像只要搞明白要求，就能保证正常运行。内部往往演化成对“要求”的明争暗斗。

大家的聪明用到了争取对自己有利的要求，要求越具体，大家的斗争越激烈，越没时间解决问题。这个场景，正在以各种形式天天上演。

能不能像市场一样决策，让大家公平交易技术指标，通过反复博弈平衡出合理的集体决策。

每位工程师都是一位商人，产品的技术指标是流通货币。

比如，我的专业原来的要求是减小阻力，但是发现减小阻力的代价很高，减小10%的阻力，会降低10%的稳定性。但是意外的发现，我的专业减小重量的代价比较低，减小10公斤重量，会缩小1%的空间。

通过核算，我的专业只负责减小重量，把减小阻力的重任交给代价小的专业解决。

每个人认真核算，总会发现自己可以帮同事解决一点困难。虽然这个责任不在领导的要求之列。如果以市场交易的角度，你可以换取同事解决你的困难。

这种交易，要以产品技术指标，作为标准货币。我们需要把付出的代价和提升的性能，换算为最终的产品技术指标。多个专业把多个指标、互相换算，会形成一个代价较低的总方案。

也许你会说，如果有人不说真话，非要夸大他的专业特别难，非要说他的技术指标无法实现，怎么办？

市场的长处就是，当他过度夸大他的代价，就无人需要。大家会绕过他，找到其他办法，解决这个难题。

比如，有人夸大他的部件很难设计，要让他多占用空间，占用重量。也许大家会取消这个部件，把他占用的空间和重量，让给其他部件，可以获取更高的技术指标。

当然，实现市场化协作也有困难。让大家在博弈中自然形成大方向，看起来好吓人，会有人担心是不是会乱套。很多时候，我们宁可选择低效率的固化，也不要高效率的自由。

这种自由协作，也要求工程师有很强的主动性，而且有能力知道自己专业的代价与收益。有些人永远只会打回车运行固定过程，从来不知道自己的设计会付出什么代价，更不知道这个代价对于产品有多大伤害。

然而，在一线的工程师都不知道代价和收益，又有谁能够知道呢？只有每天浸泡在产品设计中的工程师，才知道最新的变化，才知道如何调整策略。

市场式协作是工程师之间反复衡量后的交易结果，伴随对产品认识加深，不断修正的结果。让我们工程师不再把聪明用在演苦情戏，而是把聪明用到寻找最低代价的方案。 

下周的文章将讨论：

<如何知道设计的代价和收益>