我们做项目这么多年，遇到的坑那真是一脚深一脚浅。有些坑是技术问题，改改代码就能过去；有些坑是流程问题，调整下步骤也能解决。可有那么一种坑，你看着它，摸着它，就是不知道从何下手。那感觉就跟面对一块儿硬邦邦的石头，但你清楚知道这石头内部全是错综复杂的矛盾线，密密麻麻，缠绕到一起，就成了一块儿“矛盾的结晶体”。
我记得有一次，接了个公司内部的大项目。听起来是小改动，但牵扯了三个部门，每个部门都有自己的历史包袱和“金科玉律”。产品部要用户体验做到极致，交互必须流畅，巴不得一个页面能搞定所有事；业务部要数据报表全面，每一个字段都不能少，还得支持各种导出和复杂筛选；而技术部，希望系统架构简洁，模块复用高，最好动一发而牵全身，减少后期维护成本。这三拨人，出发点都没错，都是为了公司
可问题就出在这儿了。产品那边设计出来的原型，业务部一看就跳脚，说数据呈现不完整，没法用；技术部看到那些眼花缭乱的交互，又直摇头，说实现起来太复杂，后期维护是灾难。我这夹在中间，两边都是我的兄弟姐妹，谁的话都得听。开会的时候，大家你一言我一语，从一开始的探讨，慢慢就变成了各执己见，谁也不让步，项目进度就那么硬生生卡在那儿，一个月都动弹不得。
我当时真是抓耳挠腮，每天晚上躺床上都在琢磨，这到底是个啥情况？想把谁的需求砍掉一部分，那边肯定不答应，甚至会影响到他们的核心工作。想把所有需求都塞进去，那玩意儿出来肯定是个四不像，谁也用不我就感觉这项目就像被凝固住了一样，一个死结，掰都掰不开，真是矛盾的结晶体，越想解决越觉得它硬得石头一样。
后来我跟一个老前辈喝茶，跟他抱怨这事儿。他听完就笑了，说：“小伙子，你这是想把所有的矛盾都揉成一个球，当然揉不动了。你得换个思路，结晶体怎么解决？你得学会怎么‘融化’它，或者干脆‘掰开’它，而不是硬碰硬。”
他这话一下子点醒了我。我之前总想着找到一个完美的方案，能一次性满足所有人的全部需求，这根本就是痴心妄想。我回去后，立马调整了策略，开始我的“融化与掰开”实践：
- 第一步：把“结晶”分解成“原液”。我不再想着宏观地解决所有矛盾，而是把每个部门的核心需求单独拉出来，一条一条地列清楚，甚至细化到哪个功能对应哪个痛点。我挨个找产品、业务和技术部的负责人，让他们把“最重要”的，离开了就没法活的需求，给我讲清楚。我不是去评判对错，就是去听，去记，去理解。就像把固态的糖块重新溶解成糖水一样，让它们恢复到最初的、灵活的状态。
- 第二步：找到彼此的“交集地带”，但也尊重“独立空间”。我把所有需求整理完，发现有些需求确实是大家都要的，比如基本的增删改查。这些就是我们的交集，可以先确定下来。但更多的需求是彼此冲突的。这时候我做了一个大胆的决定：不强求这些冲突的需求必须在一个模块里实现。比如，产品部看重的体验，我们独立出一套前端交互逻辑；业务部看重的报表和数据，我们就单独设计一个后台管理模块，甚至可以考虑分两个入口，一个给普通用户，一个给业务管理人员。技术部关心的架构，我们就在底层把接口和数据模型做让上层不管怎么变，底层都能稳定支撑。这就像给他们各自划定地盘，不是让他们打架，而是让他们在各自的地盘上把自己的活儿干到最但在某些公共环节，大家要一起发力。
- 第三步：先做“骨架”，再添“血肉”。我跟三个部门反复沟通，终于达成一致：我们先出一个核心骨架版本，把那些交叉且必要的功能先做出来，保证系统能跑起来。这个版本可能不好看，数据不全，但它能动。就像造房子，先把主体框架搭起来，再一点点装修。这样大家都能看到进展，信心也就上来了。每迭代一个小版本，我都会拉着大家过一遍，让大家看到自己部门的需求是怎么被落实的，哪怕只是实现了其中一部分。
- 第四步：建立“定期沟通，冲突前置”机制。项目跑起来后，矛盾还是会有，但不再是死结了。我拉了个定期的周会，不是来解决问题的，而是来“预警”问题的。大家在会上把可能出现的需求冲突、技术难点提前抛出来，而不是等到问题发生把项目卡死。这就像给矛盾找了个“宣泄口”，让它们没法结晶，而是通过持续的小流量沟通把它排出去。
这么一通折腾下来，项目虽然走得慢了点，但总算是动起来了。系统上线的时候，虽然不是百分百完美，但三个部门都觉得基本满足了需求，而且最重要的是，他们不再是互相指责，而是开始能理解对方的难处了。我才明白，所谓矛盾的结晶体，很多时候并不是矛盾本身有多难解，而是我们解决矛盾的方法，太想一次性彻底消灭它，反而让它越抱越紧，越变越硬。
所以说，遇到这种硬邦邦的“矛盾结晶体”，我的经验就是：别急着一锤子砸碎它，也别想着把它全都揉到一起。先把它掰开，看清楚每一块的成分，然后给它们各自找到一个舒服的位置，或者创造一个能让它们共存的机制。有时候，不强求统一，反而能找到真正的出路。
