平时大伙儿说起合作，总觉得就是分工明确，各干各的呗。产品经理出需求，设计师画图，我们码农负责实现。大家都在自己的那一亩三分地里忙活，把活儿拼到一块儿，就算完事儿。但干了这么多年，我慢慢才咂摸出味儿来，这“比肩而事”，可不是简简单单的站一块儿干活那么回事儿。
记得有一次，我们要做一个新功能，挺急的。产品那边小张，设计那边老王，我这边负责开发。刚开始那会儿，照旧是开会、丢文档、然后就各自开工了。我拿着需求文档就开始琢磨怎么实现，老王拿着需求就开始捣鼓他的设计稿。可没两天，问题就来了。
我这边看着设计图，总觉得有些地方实现起来特别麻烦，甚至有点儿不符合用户习惯。有些地方感觉逻辑上也有点别扭，如果真按这图做出来，用户肯定会骂娘。我跑去问老王，他解释了一通，说这是小张那边的需求，说是用户调研出来的。他又把锅推给了小张。我又去找小张，小张说这是用户调研的结果，动不了，还把好几份报告翻出来给我看，意思就是别给我找麻烦。来来回回几趟，我这心里就堵得慌。老这么传话筒似的，效率低不说，结果肯定也出不来好东西，到时候出了问题，谁也别想跑，都得背锅。
那会儿我就想，不行，得换个法子。我直接站起来，走过去，先敲了敲老王的办公桌，问他现在忙不忙。他抬起头，一脸疲惫。我说，"老王，这功能咱俩再捋捋，行不？总觉得这块儿有点别扭。" 老王估计也被弄烦了，说行，反正也快被这个方案搞得没脾气了。然后我就把小张也叫了过来，说咱仨找个地方好好掰扯掰扯。小张一脸疑惑，但也跟着我们到了会议室，直接围着老王的电脑坐下了。
我们没有像之前那样，小张讲一通，老王画一通，我听一通。这回我们从头开始，把那个需求文档又看了一遍。这一次，我不再是单纯地挑毛病，而是主动提出我的技术视角，比如我说："如果这里这样设计，实现起来会简单很多，省下不少调试时间，而且用户体验可能更因为可以避免多余的点击。" 老王，他也不只是防守，而是积极地解释他的设计思路，同时认真听我的反馈，甚至还打开了好多参考图，跟我解释他想达到的那种感觉。小张，则不断地补充用户场景和业务目标，甚至还打开了用户访谈的录音，让我俩直接听那些真实用户的抱怨和期待。
那一下午，我们仨就这么你一言我一语地聊着，争着，也互相启发着。老王把设计稿直接在屏幕上改，我俩就在旁边看，不停地给建议。小张也不时地提出疑问，"这个改动会不会影响我们之前定义的某个核心指标？我们的推广活动会不会受到影响？" 我们就一起想办法，怎么既能解决技术实现问题，又能满足设计和业务的需求。我们甚至一起画了几个流程图，模拟用户使用路径，看看哪里还能优化，哪里能让用户用起来更顺手、更开心。那个过程，真的特别像三个人在同一个战壕里往前冲，互相打配合，没有谁是高人一等，也没有谁是只管埋头干活的。大家都是为了把这个功能做就一股脑地把自己的想法、担忧、建议都倒出来，然后揉搓到一起，找出一条最好的路。
到我们不仅把那个棘手的功能方案定下来了，而且定出来的方案比最初的任何一个版本都要好。实现起来，我也觉得特别顺手，因为我参与了整个决策过程，知道每个改动的来龙去脉，很多技术细节在前期就被讨论和解决了。设计稿最终定稿的时候，老王拍了拍我的肩膀说："多亏你那天直接过来找我们，不然真就钻牛角尖了，差点走了弯路。" 小张也说："这种一起捣鼓出来的东西，感觉就是不一样，大家都知道怎么回事，执行起来也快。"
那时候我才真正明白，原来"比肩而事"说的就是这个意思。它不是说职位高低，也不是说谁听谁的。它说的是咱们每个人都把自己擅长的那一块，毫无保留地拿出来，主动地去跟其他人融合，一起去解决问题。大家的目标一致，力气往一块儿使，心也往一块儿想。不再是等着别人发号施令，也不是自己闷头苦干，把自己的活儿干完就完事儿，而是主动地走到别人身边，肩并肩地去面对挑战，共同托起一个目标。这中间，有碰撞，有妥协，但更多的是一种互相支撑、互相成就的感觉。做出来的东西，才真正有了精气神，才真正能解决问题。
别再傻傻地觉得"合作"就是分工了。真正的合作，是"比肩而事"，是把心放在一起，把力气使到一块儿，一起往前拱。这样，事儿才能办成，办得漂亮，办得有滋味！
