纠缠这词，以前我听着就觉得玄乎，不是物理学里头量子那点事儿吗？跟我这敲代码的，做点小生意的，有啥关系？直到我前几年自己真正碰上，才发现，这玩意儿根本不只在实验室里头。它就在你我身边，说不清道不明，但是劲儿大着。
那会儿我不是刚从老家回城，折腾着想自己搞点啥吗？瞧着市面上做电商挺火的，就想着搭个小团队，弄个卖当地特产的平台。我寻思着，就一个小小的平台，能有多难？买个服务器，装个系统，前端后端数据库，不就那么回事儿吗？
结果？我从一开始就犯了个大错，就是把事情想得太简单了。我找了几个老哥们儿，有的懂点前端，有的会搞服务器，还有个是做销售的。大家都挺有劲儿的，说干就干。
开始动手，结果一团乱麻
我先是拉起了一个工作群，每天在群里吆喝大家进度。然后自己撸起袖子就去研究产品原型，把大致的页面框架、功能流程画出来。心里想着，这不就是把脑袋里的想法具象化嘛有啥难的？结果刚画了两天，老王就跟我说，你这登录页怎么设计得跟咱们那个后台管理系统一个样？我说，？不是通用的吗？他说，那不行，客户看着不专业。我一听，也是，就又回去改设计稿。
改完设计稿，发给前端小李，让他开始切图写页面。小李，他平时还接点私活，忙得跟啥似的。我催了几回，他总说快了快了。结果，等他把第一版页面给我看的时候，我发现那登录按钮，点击之后没啥反应，就是个图片。我说，这咋回事？小李说，我只负责切图，功能得后端实现。我心想这不对劲，前端不是应该连着后端接口一起调吗？
这时候，后端的老张也开始抱怨数据结构有问题。我说，我画的产品原型，上面都标注了哪些字段？老张说，你标注的太简单了，实际业务可复杂得多。比如一个商品，它不光有价格，还有库存，还有多种规格，比如颜色、尺寸啥的，你的原型里没体现。我一听，妈呀，头又大了。
那段时间，我每天就是个传话筒。小李跟老张说，老张你接口还没我调不了。老张跟小李说，小李你页面做得不规范，我不好对接。然后小王负责的服务器，老是时不时地抽风，一会儿内存不够，一会儿带宽又满了。每次一出问题，大家就互相指责，说不是自己的问题。我听着他们扯皮，感觉就像一团线，越缠越紧，谁也理不清。
硬着头皮，开始“解缠”
后来我实在受不了了，这样下去别说赚钱，连项目都得黄。我决定不能再稀里糊涂地往前冲了。我告诉大家，先暂停手上的活儿，开个会。我当时就想，这不就是“纠缠”吗？大家伙儿都缠在一起，谁也动不了。
我找了块白板，把我们现在做的所有模块，都画成一个个小方块。然后，把每个模块之间的数据流动、功能依赖，都用线连起来。比如，用户注册需要前端页面，页面把数据传给后端接口，接口去数据库里存起来，存完还要给用户发个短信验证码，短信服务又依赖另一个短信平台。我尽量把每一步都细化，可视化。
- 第一步：梳理依赖。 我们把所有功能，从用户注册到购买支付，都列出来。然后一个功能一个功能地问：这个功能需要谁提供数据？提供什么数据？输出什么数据？给谁用？
- 第二步：明确责任。 每一条线，每一个方块，都指明了具体负责人。谁的模块出问题，谁负责到底，不能再推诿了。
- 第三步：约定规范。 前端和后端之间的数据接口怎么定义？用什么格式？状态码怎么表示？这些都写成文档，白纸黑字，谁也不能耍赖。
- 第四步：小步迭代。 我强制大家，每次只做最小的功能闭环。比如，我们先实现一个最简单的用户注册，不求花里胡哨，但求能跑通。跑通了，再加功能。
那段时间，我每天就是盯着白板上的图，感觉自己像个侦探，一点点地剥开那些乱七八糟的连接。我把一些看起来很复杂，但是可以拆分的功能，都给拆成了更小的单元。然后，把那些非核心的功能，暂时就放一边，先搞定主流程。
终于搞明白这回事儿
这么折腾了大概有一个月，虽然时间拖长了，但我们整个团队的状态完全不一样了。大家不再互相指责，而是有了明确的目标。小李知道，他页面做好了，要按照约定好的接口格式，把数据传给老张。老张也知道，他接口写完了，小李可以马上拿去调。小王，也把服务器的资源使用情况，每天汇报给我，哪里要升级，哪里要优化，都清清楚楚。
整个项目，就像我把那团乱麻的毛线，一根一根地捋顺了。我发现，所谓的“纠缠”，就是当很多个独立的“事儿”或者“人”，它们之间有了藕断丝连、剪不断理还乱的关系，而且这些关系还不明朗的时候，就会出现。你动它一下，它牵扯出一大堆意想不到的问题。
我后来再做项目，或者处理一些复杂的事情，第一时间就是把“纠缠”给“拆”出来。先看清楚到底是谁在跟谁互动，产生了什么样的结果，每个环节到底承担了什么责任。把这些都掰扯清楚了，那些看起来玄乎的“纠缠”，不就变成了一个个清晰明了的小问题了吗？就像我给你们讲的，一点不难，就是得亲手去把那团线给解开。
