背景
入职阿里从双十一会场前端PM到平台项目等PM大大小小的担任了不少，自认为是老司机，不想还是踩了坑，这段时间好好地回想了下这次项目中的一些问题，根据个人经验整理了这篇文章，方便后续的回顾以及能帮助有同样问题的人。
定义
先简单定义什么是跨团队协作项目：跨团队协作是指在给指定时间约束规范内，不同部门与部门之间、个人与个人之间的协调与配合完成一项明确目标的独立的工作任务。
大体上来说一次项目的的流程分五个阶段“项目启动”-“需求评审”-“开发”-“测试（验收）”-“发布上线”，中间涉及的角色有“PD(and业务)”、“PM”、“设计”、“开发”、“测试”，具体的流程可以看下图
项目流程图
在项目的运转中，从最开始来自业务或产品的规划，到需求对焦和分工明确，以及推进到最终上线整个环节中PM的角色都扮演者非常重要的一环，技术PM不仅仅需要了解项目管理的大致流程，也需要了解业务和技术方案，在中间才能推进项目的顺利落地。
后续的章节会重点围绕聚合后的“项目初期”、“项目中期”以及收尾来展开，重点描述下在这个3个大阶段都要做哪些工作和重点注意的事。
NO.1
项目初期
1.1KO立项
一个项目的发起，最终过滤层层环节到达你身上时，至少从战略上是的得到大家的认可(当然还是需要保留自己的主观意识做好判断)，在项目启动前做为PM需要先了解这个项目，为什么做？目标是什么？可能要涉及哪些角色？作为项目PM，如何自己都搞不清楚前面三个问题，那大概率这个项目做不好，理好些问题后才能更好的去协同资源同时明确目标和项目组的同学一起拿到结果。
在明确了解清楚这3个问题后，第一项要做的就是KO立项
可能有同学眼里KO看到的和上图一样，一次项目KO非常重要，通过KO可以把关联的同学聚集到一起，分享项目背景和目标形成共识，另外还可以明确人员边界分工和里程碑方便后续的项目驱动通过这个仪式感让参与的同学感谢存在和认可更强，那一次KO需要准备哪些东西：
梳理项目涉及的角色和关联域负责人线下达成一致，明确子域接口人KOPPT准备（“背景描述”、“目标价值”、“项目介绍”、“产品架构”、“技术架构”、“里程碑”、“人员分工”等）正式会议邀约，讲价值打鸡血
1.2需求评审
KO目的是让大家对这个项目有第一印象和共识，通过需求评审能让大家深入的了解项目，一次项目需求评审可能有2次以上，第一次初稿的评审会有产品思考不全的地方，作为PM最重要的除了了解需求本身外需要定制需求截止时间，让需求能快速的评审确定，便于后续的流程正常运行，需求评审需要多了解细节多问为什么，跳开技术的身份去思考业务，带着技术的身份去思考可实施性。
评审完成后最重要的环节除了任务和优先级拆解，以及资源、成本估算和风险评估外，最最重要的就是按照KO大的里程碑将时间节奏计划产出，后续的项目推进将重点围绕这份时间节奏执行。
1.3任务拆解
在需求评审完成后，就需要开始做子域的划分和任务拆解，避免如上图一团乱麻发力的问题，任务拆解在项目管理中也有类似术语叫做“工作分解结构”（WBS），即把一个项目，按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人，直到分解不下去为止，在做项目分解时可以顺便做好需求优先级的拆解，业务或产品的需求总是一块比较大而全的东西，在实际实现时没法做到一次性完美落地，因为做好优先级的拆解才可以分期按版本完成，优先级的拆解可以按功能的关联度和是否是主流程以及项目目标和业务价值作为判断依据，另外任务拆解的力度尽量要细避免因为过粗导致评估不足和忽略影响整个项目进度的问题，任务拆解中我们可以按照子域和项目中的功能模块来拆解，这样有对比参照，任务拆解完毕后可以通过甘特图等工具来管理。
另外在实际的项目中，由于涉及的人员比较多，绝大部分任务是由子域负责人在拆解下去，所以在这里明确好角色和分工职责非常重要，角色界定不清晰也是时常影响到我们项目落地的一大因素。
1.4技术评审任何一个项目技术评审均是必不可少的一环，在需求和任务拆解完毕后，分域做技术评审拉通上下游依赖做正式的review，可以发现在任务拆分或需求评审中所没考虑到的细节，在前期将风险扼杀在摇篮中，另外在做技术成本预估时一定要加上buffer时间，这个buffer时间可以按照以往的经验作为一个系数乘上去如0.3，因为方案评审并不能做到所有的细节一次性考虑周全，不要将自己的加班时间算进去，这本身已经是项目风险。
技术评审需要哪些内容：
业务流程图（基于业务视角你所在域的环节和用户操作流程）技术框架图（架构或分层，可以了解到你所在域和周边依赖）方案设计任务拆解时间轴上下游依赖风险
项目中期
2.1交流沟通
项目管理中沟通是最重要的一个环节，启动后最大的障碍就在交流沟通上，一个完整的项目会拆分为很多子域，每个子域间会有依赖，在信息传达和处理中可能因为沟通不及时或者理解偏差导致方案设计的问题，如何把这些人聚集在一起项目室是个比较有效的解决方式，可以通过项目室在对项目执行过程时，保持项目成员的沟通的有效性确保方案设计和理解一致。
建立周会和日会机制，按项目的不同阶段运行，在开发开始运行时可以通过周会的方式，一周同步下当前进度和风险以及下周重点计划，确保项目按期执行，运行至中后期时需要开始日会机制，加强沟通交流，方便风险和问题及时同步，会议的主要内容可以按以下方式：
今日主要做的事整体进度是否有风险和依赖明日计划昨天风险是否接触
2.2风险控制
风险的主要来源很多，比如前期需求理解不一致、项目计划不合理或需求变更等等，风险是无法完全避免的，但我们可以通过历史经验或项目管理来提前发现、最小化风险，整个项目最核心的也就是这部分，风险的大小和暴露的早晚会直接影响到这些项目是否顺利，因此对于项目中暴露的问题需要保持足够的敏锐度，遵循墨菲定律，另外加强沟通、管理和交流保持信息获取的有效性。
NO.3
项目收尾
3.1测试问题推进
在项目进行到后期收尾阶段，最大问题就是issue的fix和测试覆盖是否齐全的问题，每个问题的修复可能都会暴露出新的问题，问题修复的越早，留个测试和项目的时间也会越足，因此在开发联通提测前需要开始测试用例的梳理和评审，确保测试流程覆盖度，在测试开始后需要