背景
入职阿里从双十一会场前端PM到平台项目等PM大大小小的担任了不少，自认为是老司机，不想还是踩了坑，这段时间好好地回想了下这次项目中的一些问题，根据个人经验整理了这篇文章，方便后续的回顾以及能帮助有同样问题的人。
定义
先简单定义什么是跨团队协作项目：跨团队协作是指在给指定时间约束规范内，不同部门与部门之间、个人与个人之间的协调与配合完成一项明确目标的独立的工作任务。
大体上来说一次项目的的流程分五个阶段“项目启动”->“需求评审”->“开发”->“测试（验收）”->“发布上线”，中间涉及的角色有“PD(and 业务)”、“PM”、“设计”、“开发”、“测试”，具体的流程可以看下图
项目流程图
在项目的运转中，从最开始来自业务或产品的规划，到需求对焦和分工明确，以及推进到最终上线整个环节中PM的角色都扮演者非常重要的一环，技术PM不仅仅需要了解项目管理的大致流程，也需要了解业务和技术方案，在中间才能推进项目的顺利落地。
后续的章节会重点围绕聚合后的“项目初期”、“项目中期”以及收尾来展开，重点描述下在这个3个大阶段都要做哪些工作和重点注意的事。
NO.1
项目初期
1.1 KO立项
一个项目的发起，最终过滤层层环节到达你身上时，至少从战略上是的得到大家的认可(当然还是需要保留自己的主观意识做好判断)，在项目启动前做为PM需要先了解这个项目，为什么做？目标是什么？可能要涉及哪些角色？作为项目PM，如何自己都搞不清楚前面三个问题，那大概率这个项目做不好，理好些问题后才能更好的去协同资源同时明确目标和项目组的同学一起拿到结果。
在明确了解清楚这3个问题后，第一项要做的就是KO立项
可能有同学眼里KO看到的和上图一样，一次项目KO非常重要，通过KO可以把关联的同学聚集到一起，分享项目背景和目标形成共识，另外还可以明确人员边界分工和里程碑方便后续的项目驱动通过这个仪式感让参与的同学感谢存在和认可更强，那一次KO需要准备哪些东西：
- 梳理项目涉及的角色和关联域负责人线下达成一致，明确子域接口人
- KO PPT 准备（“背景描述”、“目标价值”、“项目介绍”、“产品架构”、“技术架构”、“里程碑”、“人员分工”等）
- 正式会议邀约，讲价值打鸡血
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和测试覆盖是否齐全的问题，每个问题的修复可能都会暴露出新的问题，问题修复的越早，留个测试和项目的时间也会越足，因此在开发联通提测前需要开始测试用例的梳理和评审，确保测试流程覆盖度，在测试开始后需要关注问题的推进和修复，尽量确保问题日清。
3.2 项目验收
项目的最后一个环节就是验收，验收方式分2种，一种为组织会议预演，另外一种为推进产品（业务）和视觉验收（走查），第一种比较容易理解，即申请正式的会议拉上关联项目组成员和业务同学做产品功能的预演，确保产品和业务理解一直以及功能完善，第二种则由产品和业务以及设计同学，分别以各自的域走查，确保视觉还原、产品逻辑、产品文案的一致性。
另外最重要的一点是项目方案如果涉及到新老版本交替时，一定要考虑到二者的兼容和对用户的影响以及预案，避免影响用户，如果是个block change那需要确保足够的稳定，用户为第一优先级
NO.4
常见误区
- 过分悲观 or 乐观：这两者均建立在对项目掌控度不够的情况下，会导致对于项目的判断失误，过分悲观会影响到项目组同学的积极性，反之会导致风险暴露在后期。
- 忽略细节：即墨菲定律，凡是觉得可能出错或小概率出错的事一定会出错，当review发现问题时需要深入到细节中了解和推进，避免问题最终暴露在线上。
- 信息断层：跨团队项目中涉及的人较多，信息传递中因为不同的同学判断和思考方式不一样，导致最终你得到的信息可能是有误或缺失的信息，需要多问多了解。
- 考虑不全：每个人抛开项目PM都有自己原本的角色，比如前端、某某平台开发，导致自己站位思考会下意识从当前域去看，丢失了其他面，作为项目PM需要抛开自己的身份，站更广的域思考。
- 不敢取舍：项目启动后因为外部各种因素感染导致项目的需求上变化，针对明确的项目目标和计划需要做好取舍，了解需求的本质，敢于说不。
- 前松后紧：不合理的规划会导致项目陷入这种状态，导致提测时问题过多，开发未自测质量差等情况
NO.5
常见问题
下面的问题主要是个人见解不一定是最佳实践，有好的其他答案欢迎回复。
5.1 上下游不配合如何推进？
换位：每个人每个Team都有自己规划好的事，当我们换位思考了解当前依赖的团队目前的规划和方向是怎样，是否有周边其他方向一致的合作伙伴，才能更和的切入推进和合作
利他&共赢：这2个词可以合成一个，做好一件事的前提条件一定是大家方向目标一致，这样才能长期正常的运作下去，只有利他才能形成良好的运作模式，抛开屁股意识尤为重要，避免短期利益，另外在找上下游寻求帮助前一定要提前想清楚他要什么？我能给什么？想不清楚建议在重新review是否找对人和做对事。
借势：分2种情况，第一和当前大团队或者集团大的方向目标捆绑，跟着大的背景驱动下前行；第二向上寻求帮助，个人的力量和可以调动的资源总归有限，要学会向上管理寻求帮助
5.2 如何做好项目风险把控？
项目开始前：风险往往发生在你所未关注的视角或者依赖的上下游部分，一个复杂的项目涉及的人和方案会较多，不同域方案不一样一个人的精力总归有限，这种情况下拆域化简明确分工职责和接口人尤其重要，细分好域明确子域同学职责
项目中：”沟通“项目协同管理最核心的事，和子域负责人保持信息沟通交流，定期(日、周会等方式)对焦进度和风险，才能提早发现问题，另外避免只把自己局限在自己这块域上，更深入的了解细节和技术方案才能比较好推进，方案评估时对于时间节奏buffer才能掌控自如，以及提前发现风险和推进解决
项目上线时：作为项目最后一环较多问题主要为之前忽视偶现难排查问题以及未考虑应急预案，遵循墨菲定律，你所未在意的问题可能成为压倒这个项目的最后那根稻草，上线前多预演和准备好check list以及预案手册
NO.6
总结
任何一件事或项目光靠一份文档是无法保障稳定的，还是需要更多自己沉淀、积累以及跟进，做的多了跟的紧了才能确保没问题和沉淀自己的方法论，事在人为。