SeraSay

最近一直在观察自己，以及团队中大家的协作方式。

越来越觉得，团队协作就像在谈一场一群人的恋爱。两个人的相处难题都已经折磨了太多人，爱一辈子，吵一辈子。一群人谈恋爱要相亲相爱不吵架，简直异想天开。就算实现了，也未必真的是好现象。因为据说“爱”的对立面不是‘恨’，而是“冷漠”——各人自扫门前雪，吵架是少了，可是这是因为协作少了，自己做自己的，也就没了团队1+1大于2的效果。

拿生活中的现象做比喻会比空谈道理容易理解得多。所以干脆试着把团队协作和恋爱的过程做个对应试试看。

1.热恋

热恋的时候总是充满激情，充满对未来的期待。

就像，每当有新人进入团队时，总是期待着能做出点不一样的事来。这个时候总是最愿意为爱付出的，踩坑撞南墙也不回头。一切都是甜蜜蜜的状态。

2.吵架

可是，慢慢的…

“他怎么约会又迟到了？害我在寒风中多等了10分钟。每次都这样！点儿都把我放在心上”。“她怎么又…..”

——“怎么又改需求了？变来变去有意思么？一点儿都不尊重我们的劳动成果。下次想清楚了再来提好么？”

—— “怎么又要加需求啊，这不是在变相要求我们加班么？什么时候才是个头啊？”

3.冷漠

“每次都会就这样的问题反复吵架，吵得精疲力尽，再也不想吵了。可是情绪还在，无处释放，就只能冷眼相对了”。

——“不想再说什么了，你们先内部评审敲定好方案再跟我们提需求吧。需求说好是什么就是什么，想变更？先发变更邮件，我们多评估些时间，免得你们再坑我们，让我们最后不得不加班加点给你们擦屁股”。

——“你们每次都说要在更早的时候就参与进来，要话语权，要影响力，可是每次叫你们来讨论方案都是一副不乐意的样子。也不知道是真有那么忙，还是就是觉得不是自己的事不care”

往往，“冷漠”就变成了一个团队的常态。

其实，我们并非一开始就对对方恨之入骨，只是在一次又一次解决不了的矛盾中，慢慢学会了用“冷漠”这个武器来对抗爱人，从而保护自己。

“争吵和伤害是我们用来试探爱的手段”

4.相爱

有时候，相处久了，摩擦多了，就忘了最初的最初，我们为何会相爱，怀疑当初我们为什么会走到一起。如果说，相处意味着无尽的争吵和伤害。爱就是包容、忍耐，去尽力解决这一切的原动力了吧。

“我怀念的，是争吵以后，还是想要爱你的冲动”

——如果问题一直得不到解决，慢慢就会变成“习得性无助”，冷漠冻成冰，变成“最亲密的陌生人”

——解决问题，需要动力，需要双方首先有解决问题的意愿。然后各退一步，在各自的能力范围内，付出努力。

【说个具体点的事吧】

做塔绣活动第一次交互评审方案被毙的时候，不得不说我是有情绪在的。上游方案没确认好，导致的推翻重建，浪费的时间精力是一方面，更重要的是士气受挫。

到第二次被毙，第三次被毙。除了慢慢习惯适应以外，自己也一直在思考这个问题。被毙的根本原因是什么？有什么办法能在损失扩大前就尽量避免么？

到最后自己提出来，交互设计师的职责，是向产品经理提出“对的问题”。

如果说界面中的用户体验和行为设计是“器”，那么团队中存在交互设计师的价值，就是他比团队中其他角色都更加熟悉和了解这个“器”。

视觉设计更了解的是更具体的界面元素和视觉/美学原则这个“器”；而开发更了解的是代码这个“器”。

本质上，所有角色是在用各自最擅长的技能来合力挑战一个boss。为什么团战里往往既少不了远攻，又少不了近战？因为每个角色都有弱点，被boss抓到就是一招毙命。各个角色必须贡献出自己最擅长的部分，才可能合力通关。

“合力”的意思，不是你负责打钱，我负责练装备，他负责PK。而是，你打钱的时候遇到打不过的小怪，我来帮忙；他PK挡不住的时候，你能顶上，甚至，只是能给我们其他人通个风报个信，让大家赶来帮忙。遇到血厚的对手，我不逞强自己硬上，让团队里攻击输出最高的伙伴来协助。

哈，最近一定是《微微一笑》看多了，想想为什么游戏里玩得好的队友往往现实中也能成为朋友，这种默契和认知，不管在游戏里还是现实中，都是一样难能可贵的啊。

如果一定要求“完美无缺”的策划案出来，我才肯动工继续交互；要“完美无缺”的交互稿出来，视觉才肯动工blahblah。如果一定要提前声明的规则才作数，其它都算新增需求，都要重新计算项目时间，都要走一遍变更流程——虽然流程在一定程度上确实在试图解决“变更”的问题，可这真的是最好的解决办法么？——那跟组了个队，但是依然各自打各自的怪，有什么区别呢？

之前我的努力方向，一直是要做一个很懂产品、很懂视觉、很懂开发的交互设计师。包括在出方案的时候，也尽量能从实现方式上就考虑到下游的需求。包括在方案递交出去时，希望尽自己所能把所有可能的坑填掉，尽量避免方案更改。可后来慢慢发现，对于那些我不擅长的工作，我再怎么学，也只能学到皮毛，与其花时间在尽量覆盖更多工作范围上，倒真是不如花心思激发出上下游各端的参与积极性，发挥1+1大于2的力量。

我比策划更熟悉交互上的坑，所以如果能在策划案早期提出关键问题，可以在更早的时候帮他一起修正策划案；视觉和开发，在已有的交互方案基础上做后续工作时，也会时不时遇到各自领域的坑，这些坑在前期很难预料到，所以需要下游回过头来帮忙一起调整交互方案。本质上这两个过程是一样的，都是需要通力协作的，而不是两颗独立的螺丝钉，各自只需承担自己专业领域的内容。

回想起两件来自开发GG的故事。

一个来自之前学习OC的技术GG，强调自己在面试开发的时候，会关注面试者把功能逻辑和业务逻辑进行分离的能力，因为一旦在早期把二者进行了过多耦合，后续功能变动的成本，就会变得非常高。回想自己在做交互稿的时候，到底要把什么内容分离出来做交互稿的母板，也是一样的道理。

另一个来自老大原来公司，因为产品老大是技术，所以对开发的要求就是，对策划案留个心眼，要考虑以后他可能的需求变动，不要坑了自己。

这两件事有一个很关键的共同点，就是都有来自开发角色的努力，动脑筋，想办法，从一开始代码的架构逻辑上，就尽量把功能逻辑和业务逻辑进行分离，增强代码的可扩展性。而不是在需求方提出变更后，理所当然地用“开发成本太高”来堵需求方的嘴。

后者本质上就是一种不负责任的协作姿态。说到底，只有开发本身更了解“代码”这个工具，只有他们能在开发早期就根据自己的架构需求向上游提出建议和要求，贡献自己角色的力量去优化和纠正上游的方案，用一句比较俗的话说就是有“ownership”，为团队和结果负责，而不只是自己手上的一亩三分地。

开发对交互是这样，交互对策划也是一样。一旦产生了“你是你，我是我”的心态，协作这种模式本身是否一定会比一个全栈产品设计师能产生更大价值，就变成了一件很值得被质疑的事。

但是，如果这种“协作”的意识和姿态这么重要，为什么现有大部分团队的情况都不尽如人意呢？

一方面我觉得就是“恋爱早期的吵架问题”没解决好，导致每个角色出于自我保护采取冷漠态度应对。这个“恋爱早期”，主要是指不同角色早期融合后的磨合情况。

另一方面，更关键的是，团队的价值观到底是怎样的。价值观包含了招聘时的考核指标，比如是否只局限于类似“码代码的专业技能”，还是同时包含了“代码的架构思想”的考察。还有团队管理层面上，对每个角色职能范围、合理工作量的制定，激励机制和惩罚机制的建立。

在没有解决好“价值观”问题之前，用某些方式去督促团队成员做一些事，往往会起反作用，比如强制加班这件事。

先抛开其它因素不说，如果“加班”本身的目的是为了让我们在有限的时间内产出更多价值，其实哪怕只是从优化项目协作流程、项目经理协同每个职能老大教会每个员工提升自身工作效率的角度，都已经有很多可以做的事了。简单地靠拉长工作时间的方式来提高产出，不得不说，都是在用“战术上的勤奋”，来掩盖“战略上的懒惰”。

简单粗暴的处理方式，短期看是有效的，但是长期看必然是饮鸩止渴。人都不是傻子，当他心里认为自己得到的薪水和成就感只值每天7小时的工作量时，强制加班就是直接在天平的另一端加码，他也一定会用低效、放水等方式让这座天平回归平衡。这种方式引发的员工对工作的本能抵触，本质上还是在伤害团队本身。

我们说预测一对恋人是否能长久地在一起，“价值观”是否一致往往起了决定性作用。一个团队是否能一起面对困难，一起克服，一起前行，用“价值观是否相符”这一条进行预测，也基本八九不离十。

爱情是一段长跑，团队协作，也是一样。