2022扯皮心得-01

名词解释：扯皮-多方在一起就达成一致或妥协的行为中涉及责任推诿和拉扯的现象。每个人的感知可能有差异，我的同事将这种现象称为battle、撕逼或者谈判，就个人素质和认知偏好来说，倾向于称为扯皮。

背景概述：本人现在实习所在的部门是比较靠后的一个中台，承接了全公司所有业务的对外服务，目前对接过的业务线有20多条，底层能力也需要其他事业部或者中台提供一部分，除去与自己研发的扯皮，还有与多个业务方及事业部产研的扯皮。

虽然扯皮在生活中总是难以避免，但近期的密度着实有一点高，刚开始面对这些事会比较内耗，后来渐渐在扯皮中也有了一丝丝心得。网上有各种面经、产品方法论还有各种技术心得，很少有人说扯皮方法论的，个人觉得扯皮成功比平台上线、项目结项得到的快乐会更加纯粹，故浅浅输出一波。

本文又臭又长，总结大概这几点：

1）扯皮除了为达成目标，也是维护关系的手段（不要扯破脸）

2）扯皮完了就让他过去吧，只要是比底线高，都是扯的好

3）扯皮注意事项：

明确自己的底线，评估对方的底线；

创造扯皮的议价空间；

坚定扯皮目标，避免被带偏；

扯皮思路：方案+理由+利弊；

把握扯皮中的新信息，创造新价值；

多方扯皮时，通过拉齐改变话语权关系。

比较常见的是与自己研发的扯皮，但很多情况下自家研发为了获取更好用户体验，会主动要求选择开发量较大的方案。所以不是很理解各种面经里存在的研发拒绝产品需求的场景。通常来说自家研发只要方案合理，扯皮无非只是关于排期和做多少的问题。

排期的问题我没有碰到过太多，交付时间delay倒是很常见，总体来说脸皮够厚，顶得住业务催；提前告知风险和原因，挨几天就好了。低优需求更多的会面临做多少的挑战，这类需求多具有这些特点：由产品发起（这意味着没有业务等外部力量来推动）、收益务虚（看不到降本增效的价值，或者是一些部门的指标性建设需求）。研发们面对这类需求可能会提议分批做，先做一期需求给个较晚的排期，后面就迟迟没有下文了。

想要讨价还价，就得先创造议价空间。明确我的底线是实现需求的多少，PRD里可以扩大需求的内容，这一部分用做主动让步或者被动地由研发来砍掉。在扯皮的过程中，不仅仅是为了达成目标，也是对于双方关系的一种加强，所以在讨价还价的扯皮中，一定不会只有单方面的让步，这种情况下终会有一个比较满意的结果。

自家研发扯皮的仅仅是上述低优需求，面向事业部产研则是处处扯，扯皮关系到彼此的工作量。我们中台的性质注定了当上新一个功能和业务线时，必须同步更新，才能提供对外服务能力。这里会有一个底层的逻辑：我们要求事业部做某项功能，但我们并不是业务方，我们的平台是为他们的用户提供服务，没有这个能力影响到的对应事业部用户的体验。通常阐述清楚这个逻辑之后，一般来说会比较顺畅，也有个别情况，像是事业部拒不配合或者人力不够，这种时候就由我们收口进行开发。刚开始面对这种情况，会比较有挫败感，后面也渐渐意识到扯皮结果也需要一个合理的满意度管理方法，扯皮时聚焦于最佳方案，扯皮后聚焦于我的底线，极高程度上减少内耗。

与业务的扯皮上，核心问题是需求为什么不能做，为什么不能这样做。业务提过来的需求，本质上是对于某种问题的一种解法，需求能不能做，要看需求是不是针对于核心问题的最优解；需求不能这样做，则会基于技术难度和现有资源的扯皮。

A业务线需要做一个全业务线的未支付订单的查询工具，目前的现状是部分SKU有这个查询能力，我们从支付中台获取了一个坏账接口，坏账接口支持的业务线没有A（坏账接口中的各SKU存在未支付的互斥逻辑，即某一业务线下存在未支付订单，在其他业务线发单时，存在拦截逻辑）。故提出三种方案：

1）推动业务线A加入坏账接口（优势：开发量小；劣势：业务角度-加入坏账接口后，会影响业务线A及其他业务线的订单量；时间成本-需要大量的评估及沟通时间；可行性-发单拦截计划中不含有A业务线，可行性低）。

基于方案1的不可行性，我们获取了业务线A的未支付订单接口，并做出了两种方案：

2）由自家后端将坏账接口和业务线A的接口包一层（优势：与方案1一致的效果；劣势：开发量极大，且以后还会面临坏账接口以外的其他业务线的诉求，破例之后无法拒绝，且返工开发量较大）

3）由业务线A所在的事业部自行开发一个查询本业务线未支付订单的工具，我们将事业部开发的工具和自己开发的坏账工具均接入到业务线A的工作台中（优势：开发量小，且效果一致；劣势：若其他业务线需要查询业务线A的未支付订单，则方案不可行；对于坐席的交互体验较差）

结合当时的资源整体来看，方案三是最优解。方案三是否可行，需要先调研其他业务线有无查询业务线A的未支付订单的场景及需求。我的问题是这样的“咱们业务线这边有没有查询业务线A的未支付订单的场景啊？比如说用户进线查询，然后转接给对应业务线的坐席这种场景，有的话大概量级是多少。”问题看似没有问题，有场景有数据，但却没有把握好度：我希望得到的答案是不存在这样的场景，通过各业务线反馈不需要，来推动事业部自行开发。且这部分业务线目前在工具使用过程中未提出新的需求，后面举的例子却会引导业务同学往极端场景靠拢，为了他们各项指标的达成，他们极大可能会反馈需要这种场景，毕竟这是送上门的资源，他们无需任何投入。好在及时调整了提问的方式，顺利明确了方案三的可行性。

这个case在后续的与业务沟通中，由于掌握信息足够齐全，陈述清楚方案及对应的利弊，业务线A最终存在了两个未支付订单工具。

当然，在与业务扯皮的过程中，稍不注意就会被带偏了，特别是当业务的理由和信息足够充分时。还是未支付订单工具，做这个工具的初衷是原有的平台不符合集团安全合规的要求，需要我们提供替代能力。照旧是需要了解各业务线的需求，这个工具的面向对象应该为付款方，在跟B业务线的同学沟通完现有能力的不足后，他们提出了一个场景，因为他们业务线不存在平台给商家垫付的现象，存在大量商家进线查询未支付订单的情况，由于场景量级和提效的收益即为显著，也非常心动，从proxy到收银做了多种方案。后面才意识到被带偏了，本次项目的核心目的是提供提供替代能力，推动原有平台的下线，业务所要求的部分本质上不是未支付订单的工具，因为商家没有未支付这个行为。所以当时反应过来之后拒绝了这个需求；扯皮中也一定要实时注意对方的锚与本人的目标是否有偏离。但最后还是找时间把工具给做了，在扯皮中每一句有新信息的话，都有可能为双方创造价值（可能需要抛开当前的时间与资源维度来看）。

上述均是双方之间的扯皮，更多的情况下牵扯的部门会更多。一次在做一个涉及用户安全相关的功能时，公司安全部门要求我们平台在发生点击功能按钮的行为后透传工单id，来留存记录这个功能发生的行为。涉及工单id的记录和透传首先需要保证有工单生成，跟业务反复确认后，该工具上线后仅有二线坐席使用，评审顺利通过。通过后第二天，业务变卦了，说会有一线坐席未创建工单使用的场景，此时心里一万只草泥马游走，出了以下方案：

1）点击按钮后是假动作，前端先给后端传递未生成工单id时的唯一标记符markid，待坐席创建工单后再正式发送请求并通过映射关系实现透传工单id（优势：满足了安全平台的要求；劣势：并没有及时满足进线用户的需求，易引发舆情等客诉风险，且开发量大）。

2）考虑到记录工单id的根本目的是为了溯源，由于入参中还有操作人的必填项，故在未创建工单id时，统一给透传我们平台的callerid+一线操作（优势：交互好，体验佳；劣势：安全部门具有一棒子打死的权利）。

3）推动事业部产研修改接口，接口改为两部分，先发送请求，生成工单后再异步透传工单id（优势：满足所有需求；劣势：其他平台正在使用这个接口，推动事业部重新开发难度较大）。

4）推动业务修改sop，通过sop规范坐席使用工具时先创建工单，并通过质检等手段进行约束（优势：和评审时一样的效果；劣势：存在业务拒绝的风险）。

明确方案后，分别找自家研发、事业部产研、安全同学和业务同学进行了四轮扯皮，自家研发表示假动作无意义（他说的对）、事业部产研表示没有人力，要不工具就自己开发了，业务和安全均拒绝妥协让步。

需求迟迟无解，最后通过拉了一个大会，安全方明确要求、事业部和自己研发表明难度，硬生生地推动业务修改sop。

在这个case里，单方面沟通时，弱势永远是我们，四方拉齐时的强势程度大概这样：安全>事业部产研>=自己产研>业务（因为私下沟通业务始终相信不逼产研一把，他肯定是在摆烂）。通过群聊或者集体会议，改变彼此之间的关系，加强自己的话语权，也不失扯皮的一种好办法。

其实从入职到现在每天都在扯，目前扯得比较有记忆点的只有这些。以及最近能明显感受出提出方案的维度越多，扯皮的几率会越大。扯皮成功虽然成就感蛮高的，但是目前还是有点折磨人的。