创业团队具体分工,创新创业团队分工

　　#背景　　

　　阿里从双十一场馆前的PM到平台项目，承担了很多工作。他以为自己是老司机了，但他不想踩坑。在此期间，他仔细思考了这个项目中的一些问题，并根据自己的亲身经历编写了这篇文章，以便于后续的回顾，帮助有同样问题的人。　　

　　#定义　　

　　让我们简单地定义一下跨团队协作项目是什么。　　

　　跨团队协作是指不同部门和个人在给定的时间限制内，以明确的目标完成独立的工作任务的协调与合作。　　

　　一般来说，一个项目的过程分为五个阶段：项目启动、需求评审、开发、测试(验收)以及发布和启动，其中涉及的角色是PD(和　　

　　业务)、项目管理、设计、开发和测试。具体流程见下图。　　

　　项目流程图 　　

　　在项目的运营中，PM的角色在从业务或产品规划开始，到需求聚焦和分工明确，再到最终上线的整个过程中扮演着非常重要的角色。技术PM不仅需要知道项目管理的一般流程，还需要知道业务和技术解决方案，这样才能促进项目在中间顺利落地。　　

　　接下来的章节将围绕“项目初期”、“项目中期”以及聚合后的结局展开，重点描述这三大阶段该做什么、该注意什么。　　

　　#第一名　　

　　项目初期 　　

　　1.1 KO立项 　　

　　一个项目的启动，当最终层层过滤的链接到达你的时候，至少在战略上得到大家的认可(当然，你还是需要保持主观意识，做好判断)。作为项目开始前的PM，你需要先了解这个项目。　　

　　为什么做？目标是什么？可能要涉及哪些角色？ 　　

　　作为项目PM，前三个问题我自己都想不出来。这个项目很有可能做不好。只有解决了一些问题之后，才能更好的协调资源，和项目组的同学一起明确目标，共同取得成果。　　

　　明确了这三个问题之后，首先要做的就是KO项目。　　

　　有些同学可能在KO眼里看到的和上图一样。KO对于一个项目来说非常重要。通过KO，相关同学可以聚在一起分享项目的背景和目标，形成共识。此外，还可以明确人员边界的分工和里程碑，便于后续的项目推进。通过这种仪式感，参与的学生可以更好地欣赏存在和认可。KO当时应该准备什么：　　

　　1.梳理项目涉及的角色，线下与相关领域负责人达成一致，明确子领域接口人。　　

　　2.KO PPT准备(背景描述、目标值、项目介绍、产品结构、技术结构、里程碑、人员划分等。) 　　

　　3.正式会议邀请，谈鸡血的价值　　

　　1.2 需求评审 　　

　　KO的目的是给大家对这个项目的第一印象和共识。通过需求评审，我们可以对项目有一个深刻的了解。一个项目可能有两个以上的需求评审，初稿评审会有不完整的产品思维，这对于PM来说是最重要的，除了　　

　　了解需求本身 　　

　　需要定制需求的截止时间，以便快速审核确定需求，便于后续流程的正常运行。需求评审需要了解更多细节，问更多为什么，跳出技术身份去思考业务，用技术身份去思考可实现性。　　

　　评审完成后，除了拆解任务和优先级，以及资源、成本估算和风险评估外，最重要的环节就是按照KO的里程碑来制作时间节奏计划产出。　　

　　后续项目推广将围绕这个时间节奏展开。　　

　　1.3 任务拆解 　　

　　需求评审完成后，需要开始划分子域，分解任务，避免出现上图所示的工作混乱。任务反汇编在项目管理中也有一个类似的术语叫“WBS”，就是把一个项目按照一定的原则分解成任务，然后把任务分解成任务，再把每个任务分配给每个人，直到不能分解为止。分解项目时，可以做好需求优先级的拆解工作。业务或产品的需求永远是一件大而全的事情，在实践中不可能一次完美实现，因为拆解优先级可以分阶段分版本完成。分解优先级可以根据功能关联程度和是否是主流程，以及项目目标和业务价值来判断。此外，任务拆除的努力应尽可能小心，以避免因过大而导致评估不足和忽视影响整个项目进度的问题。在任务拆解中，我们可以遵循项目中的子领域和功能模块。　　

来拆解，这样有对比参照，任务拆解完毕后可以通过甘特图等工具来管理。

另外在实际的项目中，由于涉及的人员比较多，绝大部分任务是由子域负责人在拆解下去，所以在这里明确好角色和分工职责非常重要，角色界定不清晰也是时常影响到我们项目落地的一大因素。

1.4 技术评审

任何一个项目技术评审均是必不可少的一环，在需求和任务拆解完毕后，分域做技术评审拉通上下游依赖做正式的review，可以发现在任务拆分或需求评审中所没考虑到的细节，在前期将风险扼杀在摇篮中，另外在做技术成本预估时一定要加上buffer时间，这个buffer时间可以按照以往的经验作为一个系数乘上去如0.3，因为方案评审并不能做到所有的细节一次性考虑周全，不要将自己的加班时间算进去，这本身已经是项目风险。

技术评审需要哪些内容：

1. 业务流程图（基于业务视角你所在域的环节和用户操作流程）

2. 技术框架图（架构或分层，可以了解到你所在域和周边依赖）

3. 方案设计

4. 任务拆解&时间轴

5. 上下游依赖&风险

项目中期

2.1 交流沟通

项目管理中沟通是最重要的一个环节，启动后最大的障碍就在交流沟通上，一个完整的项目会拆分为很多子域，每个子域间会有依赖，在信息传达和处理中可能因为沟通不及时或者理解偏差导致方案设计的问题，如何把这些人聚集在一起项目室是个比较有效的解决方式，可以通过项目室在对项目执行过程时，保持项目成员的沟通的有效性确保方案设计和理解一致。

建立周会和日会机制，按项目的不同阶段运行，在开发开始运行时可以通过周会的方式，一周同步下当前进度和风险以及下周重点计划，确保项目按期执行，运行至中后期时需要开始日会机制，加强沟通交流，方便风险和问题及时同步，会议的主要内容可以按以下方式：

1. 今日主要做的事&整体进度

2. 是否有风险和依赖

3. 明日计划

4. 昨天风险是否接触

2.2 风险控制

风险的主要来源很多，比如前期需求理解不一致、项目计划不合理或需求变更等等，风险是无法完全避免的，但我们可以通过历史经验或项目管理来提前发现、最小化风险，整个项目最核心的也就是这部分，风险的大小和暴露的早晚会直接影响到这些项目是否顺利，因此对于项目中暴露的问题需要保持足够的敏锐度，遵循墨菲定律，另外加强沟通、管理和交流保持信息获取的有效性。

# NO.3

项目收尾

3.1 测试问题推进

在项目进行到后期收尾阶段，最大问题就是issue的fix和测试覆盖是否齐全的问题，每个问题的修复可能都会暴露出新的问题，问题修复的越早，留个测试和项目的时间也会越足，因此在开发联通提测前需要开始测试用例的梳理和评审，确保测试流程覆盖度，在测试开始后需要关注问题的推进和修复，尽量确保问题日清。

3.2 项目验收

项目的最后一个环节就是验收，验收方式分2种，一种为组织会议预演，另外一种为推进产品（业务）和视觉验收（走查），第一种比较容易理解，即申请正式的会议拉上关联项目组成员和业务同学做产品功能的预演，确保产品和业务理解一直以及功能完善，第二种则由产品和业务以及设计同学，分别以各自的域走查，确保视觉还原、产品逻辑、产品文案的一致性。

另外最重要的一点是项目方案如果涉及到新老版本交替时，一定要考虑到二者的兼容和对用户的影响以及预案，避免影响用户，如果是个block

change那需要确保足够的稳定，用户为第一优先级

# NO.4

常见误区

1. 过分悲观 or 乐观：这两者均建立在对项目掌控度不够的情况下，会导致对于项目的判断失误，过分悲观会影响到项目组同学的积极性，反之会导致风险暴露在后期。

2. 忽略细节：即墨菲定律，凡是觉得可能出错或小概率出错的事一定会出错，当review发现问题时需要深入到细节中了解和推进，避免问题最终暴露在线上。

3. 信息断层：跨团队项目中涉及的人较多，信息传递中因为不同的同学判断和思考方式不一样，导致最终你得到的信息可能是有误或缺失的信息，需要多问多了解。

4. 考虑不全：每个人抛开项目PM都有自己原本的角色，比如前端、某某平台开发，导致自己站位思考会下意识从当前域去看，丢失了其他面，作为项目PM需要抛开自己的身份，站更广的域思考。

5. 不敢取舍：项目启动后因为外部各种因素感染导致项目的需求上变化，针对明确的项目目标和计划需要做好取舍，了解需求的本质，敢于说不。

6. 前松后紧：不合理的规划会导致项目陷入这种状态，导致提测时问题过多，开发未自测质量差等情况

# NO.5

常见问题