公司的一项主要业务是内容创作平台，平台上有很多内容创作者，还有很多内容的消费者。
为了鼓励内容创作者提供更多更好的内容，产品研发团队设计了一个等级体系，或者说是一个成长体系。从内容创作新手开始，每个等级都有任务，完成后可以获得信用分，信用分累积到一定程度后就可以升级做更高等级的任务。因为是UGC的模式，为了防止不良内容或者版权问题，需要对内容进行审核。审核通过的，可以被内容消费者进一步消费，如果审核不通过或者上线后发现有问题，则会退回给内容创作者，该内容创作者还会受到扣除信用分的处罚。如果内容创作者对处罚不满意，可以提起申诉，审核人员则需要对申诉进行处理。
第一期项目的目的，就是要完成信用系统和审核系统的对接。这是项目背景。此外，由于公司的战略规划，产品研发团队有A、B两个，分布在不同城市，恰好这次项目就涉及到两地团队的协作。A团队主要负责内容创作者的成长信用系统。B团队则负责审核系统的开发。
进入项目组时，项目已经开始了一段时间。之所以进项目组，其实就是因为项目推进遇到了问题。项目开始时，B团队的产品经理正好在进行交接，而A团队为了快速推进项目，则把原本B团队负责的审核做了初步产品设计。产品方案文档也发给涉及到的审核、客服团队了，但没有深入聊，这就为后来的诸多问题留下了隐患。因为产品经理在交接，所以A团队的产品经理就直接把产品方案给到了B团队的开发，B团队的开发比较年轻，没多想就开始了开发。
项目进行到一半时，发现两个系统各自的流程可以跑通，但是对接部门的流程有很多问题。技术一直要修流程带来的各种bug。还有麻烦的是，交付使用时，审核团队这才发现产品不好理解不好用，流程不顺、界面文案也有不少歧义，以至于过段时间就有人问产品技术，某某是什么意思。更有甚者，设计时没有想到客服，所以每次内容创作者不理解要问客服时，客服也是一脸蒙圈。
看起来问题比较严重，因为各个团队都有自己的目标，所以导致A团队产品设计时，主要考虑了自己的需求，审核和客服的需求只是点到为止，审核和客服在听方案时，也没有很及时反馈问题。
加入之后，我先是带大家明确了项目的整体目标和范围、最终指标等，就是立个项。因为手中并没有更高的权力，所以主要是拉着各方做到一起，不是听产品讲需求，不是不作声不摇头，而是确立一个场景流程，让各个角色自己来讲该做什么，串起整个流程，如果发现自己理解的不一致就赶紧调整，如果发现对方的方案有问题，也即刻告知对方。
结果在大家更紧密的沟通之下，方案做了很大调整，虽然花了更多时间，但项目涉及到几个主要角色的场景变得更清晰。团队也渐渐不像之前那么焦虑，也减少了不同团队之间之前所造成的不信任感。项目排期变得更明确，敲定了几个里程碑，以及每个里程碑要交付的内容及其标准。
最大启发是，在项目涉及的团队较多时，需要有人统一协调大家的目标，组织大家梳理完整的流程。需求不仅仅让产品讲，更要让各团队参与进来进行沙盘推演，以期在项目前期就确定好范围和需求，并确保各团队理解一致。
创新之处在于，在团队各自为政的情况下，项目经理站了出来。作为跨团队的关键协调人，突破了原团队项目的边界，让大家为目标真正协作了起来。
值得改进的是，今后稍大规模的跨团队协作，除了不是为某个团队负责而是为最终交付负责的项目经理外，项目需要明确立项，以便各团队迅速就授权、规则等达成一致。
