|0x00 正确看待合作
现如今，大家在大厂里做事情，都会比较有目的性，比如拿项目、拿结果、促晋升，等等。但由于系统组织的复杂性，做好一件事情，往往是需要“合作”的。这种合作并不仅仅是多个职能在一起协同，做一下敏捷项目，就可以拿到结果，而是代表更高的“Owner”意识要求，即我主动发起、我主动推动、我主动拿到结果的“主动”行为。可以说，越往上走，偏执性的内容就越少，“主动”的占比就越大，在这里面，“合作”就显得非常重要了。
除了我们一般所熟知的“技术专业”等内容外，合作还需要有一些“利益”上的绑定。《亮剑》里楚云飞的一个引用，会让大家更感同身受一些：“没有永恒的朋友，没有永恒的敌人，只有永恒的利益。”
这里的“利益”并非是贬义性质的，因为在海洋文明的思维认知里，“与邻为壑”是生存的本能。日本的终身雇佣制在中国行不通，大多数人都更赞同美式资本主义做事方法的基础上，强调“利益”也就是职场上必备的一项技能。
用《国富论》的一段话阐述，就是“我们的晚餐并非来自屠夫、酿酒商或面包师的恩惠，而是出自他们自利的打算。我们不说唤起他们利他心的话，而说唤起他们利己心的话。我们不说自己有需要，而说对他们有利。”
从职场生存的角度出发，人所做的事情，无非三件事：“追求更高收益，降低成本和风险，简化日常操作”，因此，从这三点的任何一个角度出发，“合作”都是有根基的。例如团队经常因为数仓组织的混乱，拖累了自己研发效率，因此就有比较强烈的动机，来追求自动化的治理工具，而且这个工具最好能够简单上手、效果显著。但这件事情本身是一件专业性质很高的事情，需要人力投入是非常大的，短期也不一定见得到效果。因此如果有其他团队来推广使用，或者是市面上的某款开源的或者商业化的产品，能够解决问题而效果不错的话，“合作”就很容易达成了。
接下来，我们就要分析下，主动来“合作”这个事情，应该怎么搞。
|0x01 寻找合作对象
如果我们把思想拔高一下，从社会协作的逻辑来看，“合作”的底层逻辑，大概是有三个：
其一，社会遵循弱肉强食的自然法则，强调适者生存；
其二，社会有它固定的族群法则，出于生存的本能，会形成集体的概念；
其三，现代社会有“协议”的存在，它是超越国家和地区的，所有人认同的概念。
所以，从合作对象的角度来看，我们的目标就很明确，即“有共同利益、有共同团体、有协作协议”的人，来一起做事，或者称之为“有共同OKR”的人，来一起推动KR的完成。
同样以自动化工具为例，我们来分析可以合作的对象。
首先，我所在的部门，不能是太前台的部门，最好是中后台，因为前台部门的技术要为结果兜底，轮子能用就行，对于做好这个事情，不见得有多么大的兴趣。
其次，我所在的团队，与目标用户团队，最好在一个大的集体下，这样在开发环境、权限申请、业务调整等方面，不至于受到太大的羁绊，至少我们是有一定团队集体观念的。
最后，我们做的事情，要“名正言顺”，即目标团队有诉求，我们有资源和经验，大家共同的OKR都是为了做好底层治理。
如此，我们的合作对象，基本就能够圈定下来了。当然，因为一些私人关系、部门战略的影响，合作不会那么顺利，那么学会尝试用一些“沟通技巧”来消弭这些“差异”，而不是像个“二楞子”一样直接冲上去，毕竟人心也是肉长的，多一点好听的话，有时候更胜过行动。
|0x02 学会主动运营
对于合作项目而言，最宝贵的是什么？“时间”！
所以，很难想象我们会按照传统项目管理的方式，设计PRD、评审、开发、测试的一路走下来，更多的情况，是敏捷着就要上线了，因此短时间内合作项目的优先级是可以拔高的，但时间稍微一久，必然会面临下降的情况。
所以，刚开始能用就行，但质量通常就比较难以控制好，需要很多非工作时间来做修正，这个就是“运营”。这其实是比较辛苦的事情，也是不容易见到成果的阶段，但也是最必要的阶段。
即便是在项目上线后，也面临比较长期的“运营”问题。现在大多数研发所理解的“项目”或者“产品”，是按照PRD设计完成后，基本工作就可以完成的。但对于要拿价值的“合作”事情来说，往往开发完成后，下一个阶段，也就是推广和运营阶段，才是决定成败的关键。
这里还是要推广一下PMP的理念，很多时候我个人还是比较推荐学一下，因为确实有用。比如对于项目和运营的定义：“项目是为创造独特的产品、服务或成果而进行的临时性工作”。项目之后是什么？就是交接给运营的同学。
那么运营应该怎么搞？还是借鉴一下《敏捷项目管理》的一些内容。
首先是敏捷宣言，这个与我们所理解的敏捷项目管理，其实是相同的，但很少有人会思考敏捷宣言的内容。我这里写出四个最核心的价值：
- 个体和互动高于流程和工具
- 工作的软件高于详尽的文档
- 客户合作高于合同谈判
- 响应变化高于遵循计划
仔细品一下还挺有味道的。
其次是干系人，这是研发通常会忽略的因素，但往往比较关键。因为做运营，与多团队打交道是必要的事情，那么哪些团队的要重点合作，哪些要及时通知，哪些要令其满意呢？看一下如何管理干系人、面对冲突如何处理，虽然看起来挺无聊的，但是做做题会有另一种不同的感受。
接下来是用户故事和产品路线图，我们需要用一个动听的故事来打通用户，并且有明确的可实现路径，别人才可能相信你这个不是画大饼。
最后是敏捷项目自身的内容，燃尽图、累计流量图等工具的应用，及时的把消息传递给需要知道的人。
本文并不会深入去分析和讲解，只是起到一个“引子”的作用，因为敏捷项目管理，对于研发的意义，并不仅仅是Sprint、Scrum、每日站立会，也有如何把事情做好的指导理论。
|0xFF 共享合作成果
如果拿到结果，请记得一定要有“正反馈”，为下一次，或者是潜在的机会，做好铺垫。
云栖大会上，数据中台专场，有一句话讲的挺好：“被企业需要，是行业混战中唯一生存法则。”
引申到职场上，是“被核心业务需要，是确立竞争力的唯一生存法则。”
中台之所以在大多数公司，成为不伦不类的东西，也是因为这是个“逻辑上正确，实际上不解决核心业务问题”的东西，面对自己的尴尬，也就很难有所突破。
因而，合作的结果，不论是技术的创新，还是业务的自动化，在核心业务需要你之前，先做到匹配它的诉求，那你就领先一步。
做擅长的事情，在时间的赛道上，跑出最好的长跑成绩，能够笑到最后的，也应该是你。