2024年如何做好一个跨团队协作项目，行业寒冬如何面对

最新推荐文章于 2024-09-27 15:52:57 发布

2401_84435885

最新推荐文章于 2024-09-27 15:52:57 发布

阅读量787

点赞数 27

分类专栏：程序员文章标签：前端面试学习

本文链接：https://blog.csdn.net/2401_84435885/article/details/138831845

版权

程序员专栏收录该内容

165 篇文章 0 订阅

订阅专栏

学习笔记

主要内容包括html，css，html5，css3，JavaScript，正则表达式，函数，BOM，DOM，jQuery，AJAX，vue等等

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

HTML/CSS

**HTML：**HTML基本结构，标签属性，事件属性，文本标签，多媒体标签，列表 / 表格 / 表单标签，其他语义化标签，网页结构，模块划分

**CSS：**CSS代码语法，CSS 放置位置，CSS的继承，选择器的种类/优先级，背景样式，字体样式，文本属性，基本样式，样式重置，盒模型样式，浮动float，定位position，浏览器默认样式

HTML5 /CSS3

**HTML5：**HTML5 的优势，HTML5 废弃元素，HTML5 新增元素，HTML5 表单相关元素和属性

**CSS3：**CSS3 新增选择器，CSS3 新增属性，新增变形动画属性，3D变形属性，CSS3 的过渡属性，CSS3 的动画属性，CSS3 新增多列属性，CSS3新增单位，弹性盒模型

JavaScript

**JavaScript：**JavaScript基础，JavaScript数据类型，算术运算，强制转换，赋值运算，关系运算，逻辑运算，三元运算，分支循环，switch，while，do-while，for，break，continue，数组，数组方法，二维数组，字符串

在需求评审完成后，就需要开始做子域的划分和任务拆解，避免如上图一团乱麻发力的问题，任务拆解在项目管理中也有类似术语叫做“工作分解结构”（WBS），即把一个项目，按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人，直到分解不下去为止，在做项目分解时可以顺便做好需求优先级的拆解，业务或产品的需求总是一块比较大而全的东西，在实际实现时没法做到一次性完美落地，因为做好优先级的拆解才可以分期按版本完成，优先级的拆解可以按功能的关联度和是否是主流程以及项目目标和业务价值作为判断依据，另外任务拆解的力度尽量要细避免因为过粗导致评估不足和忽略影响整个项目进度的问题，任务拆解中我们可以按照子域和项目中的功能模块来拆解，这样有对比参照，任务拆解完毕后可以通过甘特图等工具来管理。

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

1.4 技术评审

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

技术评审需要哪些内容：

业务流程图（基于业务视角你所在域的环节和用户操作流程）
技术框架图（架构或分层，可以了解到你所在域和周边依赖）
方案设计
任务拆解&时间轴
上下游依赖&风险

NO.2

项目中期

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 如何做好项目风险把控？

打开全栈工匠技能包-1小时轻松掌握SSR