关于一场甲乙双方争议的思考

这两天技术团队和服务的客户团队在互相间邮件往来，言语间颇有情绪，如果从大公司的视角来看，颇有部门间办公室政治的味道。

双方领导都还没有发表意见。而我的想法，也是让子弹先飞一会。

如果双方磨合好了，合作会更上一层楼；如果没有磨合好，对自己的团队而言也是好事情，更能清楚自己的团队更应该聚焦精力做好产品，对客户方而言也能够明白需要什么样的团队更好协作。

我旁观了这场看似业务讨论、产品设计与技术工作量认可的辨析，本质上是对各自专业度和权威性的维护。

这个问题最糟糕的情况是甲方持着甲方的权利操着非专业的指挥权，颇有瞎指挥的味道。一般的技术团队或者一次性项目，很简单听甲方的就可以了，毕竟人家是买单方，验收过后，欠货两清就好了。但如果是长期合作的运营项目，后期还是得由现在的团队做维护，而这个坑，技术团队也不愿意背。

对技术团队而言，仅仅是纯外包派单过来做定制的开发，而这个需求可能是由甲方的运维整理后通过来的，也就不愿意参与了，也没有多大价值。因为服务的过程中可能会包含咨询和业务设计的内容，不然能不能满足需求都不知道，也没有办法保障质量和效果。

在这一点上，为什么业务管理类系统争议少，而运营类的互联网产品设计争议多？这就像武无第二文无第一一样，业务是有明确细节和需求的，有一个标准，最简单的方式就是听话照做就是了。而运营类的一千个人有一千个哈姆雷特，等得到数据验证，那又是另一个版本迭代的任务了，工作量消耗了，团队元气消耗了，时间窗口也过了。

这中间扣到某一个细节的工作量统计是否合理上，或者做多了一些工作是否应该统计工时，或者 1-2 个工作日是否合适上，一方面也是考验甲方的度量，也考验甲方的眼光。专业度足够，会有正常的价值判断。对技术团队而言，有不用纠结，项目是产品打磨的练兵场，复用是项目给予的最大价值，对走产品化的技术团队来说亏不了。

扣到某一个细节的工作量统计是否合理上另外一个层面的副作用是，会把双方团队逼到一个不在协议合同内的，就不做了。导致双方团队需要花大量额外的时间精力去核定需求上，都不愿意往前做做一步，总差那么一口气，而运营类的项目一方面要求响应速度快，另一方面刚开始都很难想得清楚，需要快速迭代来拟补，事后复盘是一种常态，也最具有价值。

最后如果双方团队磨合不到一起，除了双方领导出面解决外，对于非定制类的项目其实双方都有很大的选择权，对甲方而言有一大堆 IT 供应商可以选择，对乙方而言也有一大堆项目等着接盘。现在充分竞争的市场的魔力也在于此。

做定制服务的话，有一些坎或者该有的基本功是绕不过去的，除非不做这个生意了。

反观技术团队自身，还是要建立自己明确的标准和要求，让甲方同学知道在专业领域的规则和要求，同时自己要有一套明确的流程和交付物，一步一个脚印把工作做扎实了，直面实际工作的过程和成果，这里面就会排查情绪的成分，这点也正是团队需要进一步努力的方向。