前端进击笔记第二十七节 如何通过前期准备和后期复盘让项目稳定上线

课程快接近尾声了，前面我也跟大家介绍了很多技术选型、从 0 开始建设前端项目的经验。今天，我想再跟大家聊一聊关于项目管理和项目复盘这件事情。

日常工作中，我们常常会以项目的形式参与到具体的开发中，可能会负责项目的主导，或是作为核心开发负责某个模块、某个技术方案的落地。

很多人会觉得做一个普通的前端项目，从开发到上线都没什么难度。一个字：“干”就完了。

实际上，项目的管理、推动和落地是工作中不可或缺的能力，这不同于技术方案设计、代码编写，这属于工作中的软技能。但正是这样的软技能会对我们的工作成果产生很大影响，也会影响自身的成长速度，更是升职加薪的必备技能。

在项目进行的每个阶段，我们都可以通过同样的方式去提升自己：预期→结果→复盘。我们来分别看下。

事前

就像在开发前进行架构设计一样重要，我们在项目开始前，需要对项目的整个过程进行初步的预估，包括：

1. 预期功能是否能实现？存在哪些不确定的功能？

2. 预计的工作量和分工排期是怎样的？

3. 每个阶段（开发、联调、产品体验、提测、发布）的时间点大概是怎样的？

4. 哪些工作涉及外部资源的依赖和对接（交互/设计/接口协议等），是否存在延期风险？

5. 如果存在风险，有没有什么方法可以避免？

这么做有什么好处呢？我们来看个小故事。

小明接到个新活，老板说现在的项目代码量很多，各个模块之间耦合相当严重，需要重构。

这是个大活，小明接到之后就开始进行调研和设计。但是这么大规模的项目，又进行大规模重构的案例实在太少了，基本找不到可以直接借鉴的解决方案。于是，小明跟老板要了一周的时间，打算拉个分支边写 DEMO 边调整方案。

这样的大重构，需要对各个模块做好充分调研，也需要对方案进行全面完整的风险评估，但小明觉得这根本就没法做到，太麻烦了，于是就想到哪写到哪。一周过去了，小明改好了一个模块，感觉这样改比较可行，于是跟老板要了三个月的完整改造期。

一个月过去了，小明发现代码写到一半写不下去了，有几个模块不支持预期的改法，需要对方案进行大调整。接下来，项目从预期的三个月变成了四个月，四个月又拖到了半年，迟迟上线不了。老板对小明表示很失望，小明的绩效也跟着失望。

或许在大家看来，小明做事太不靠谱了。实际上在我们的工作中，这样的情况常常会遇到，很多人甚至对需求延期都已经习以为常了，认为需求能准时上线才是稀奇的事情。正因为大家都是这样的想法，我们更应该把这些事情做好，这样才可以弯道超车。

首先，在项目开始的时候，需要进行工作量评估和分工排期。

如何进行合理的分工排期

进行工作量评估的过程可以分为三步：

1. 确认技术方案，以及分工合作方式；

2. 拆分具体功能模块，分别进行工作量评估，输出具体的排期时间表；

3. 标注资源依赖情况和协作存在的风险，进行延期风险评估。

当我们确认好技术方案之后，需要针对实现细节拆分具体的功能模块，分别进行工作量的预估和分工排期。否则可能面临分工不明确、接口协议未对齐就匆忙开工、最终因为各种问题而返工等情况。

我们在进行工作量评估的时候，可以精确到半天的工作量预期。对独自开发的项目来说，同样可以通过拆解功能模块这个过程，来思考具体的实现方式，也能提前发现一些可能存在的问题，并相应地进行规避。

提供完整的工作量评估和排期计划表（精确到具体的日期），可以帮助我们有计划地推进项目。在开发过程中，我们可以及时更新计划的执行情况，团队的其他人也可以了解我们的工作情况。

工作量评估和排期计划表的另外一个重要作用，是通过时间线去严格约束我们的工作效率、及时发现问题，并在项目结束后可针对时间维度进行项目复盘。

为了确保项目能按照预期进行，我们还要对可能存在的风险进行分析，提前做好对应的准备措施。

对项目风险进行把控

我们在项目开发过程中，经常会遇到这样的情况：

• 因为方案设计考虑不周，部分工作需要返工，导致项目延期；

• 在项目进行过程中，常常会遇到依赖资源无法及时给到、依赖方因为种种原因无法按时支援等问题，导致项目无法按计划进行；

• 团队协作方式未对齐，开发过程中出现矛盾，反复的争执和调整协作方式导致项目延期。

一个项目能按照预期计划进行，技术方案设计、分工和协作方式、依赖资源是否确定等，任何一个环节出现问题，都可能导致延误。因此，我们需要主动把控各个环节的情况，及时推动和解决一些多方协作的问题。

下面我们来看一个详细的例子。

小明接到一个需要带外包同学进行小程序开发的项目，张三听说了，就跟小明吐槽说之前也做过类似的项目，外包同学写的代码可乱了，最后交付的时候甚至都还有报错。

换作是其他人，听了张三的话可能都开始泄气了，内心想着：这么麻烦的活，估计最后还得自己擦屁股。可小明不一样，他找到张三详细咨询了之前项目的一些情况，整理出来以下问题。

小明分析了下，问题的确很多，但都是可预估的风险。为了避免同样的问题出现，小明特地做了一些前期的准备工作，并且最后达到了不错的使用效果。

通过前期准备的这些方案和工具控制了很多可预见的风险，一期整个开发过程比较顺利，外包同学表示合作过程很愉悦，最终的交付质量也比预期好很多，连张三也拍手称好。

在这个项目中，小明对可能存在的问题做了充分的调查，并提供了一系列的技术方案避免了问题的出现。但小明觉得这还不够，项目虽然成功上线了，但其实也出现了一些延期的情况。项目还要进行二期开发，于是小明决定要进行项目复盘，找到问题在哪。

事后

很多开发习惯了当代码开发完成、发布上线之后就结束了这个项目，其实他们遗漏了一个很重要的环节：复盘。

对于大多数开发来说，很多时候都不屑于主动邀功，觉得自己做了些什么老板肯定都看在眼里，写什么总结和复盘都是刷存在感的表现。实际上老板们每天的事情很多，根本没法关注到每一个人，我以前也曾经跟老板们问过这样一个问题：做和说到底哪个重要？

答案是两个都重要。把一件事做好是必须的，但将这件事分享出来，同样可以给团队带来更多的成长。

通过对项目进行复盘，除了可以让团队其他人和老板知道我们做了些什么，更重要的是，我们可以及时发现自身的一些问题并改进。

及时反馈与复盘

小明在一期的项目结束后，整理了这次开发过程中存在的问题。

• 外包同学开发效率上问题不大，项目延期主要原因整理如下。

  • 等待后台接口可联调时间比预期要长

  • 产品对接问题：提供资源、体验产品不够及时，需求描述不够详细

  • 过程中存在需求变更，主要体现在设计和交互调整

• 沟通上，外包同学态度比较积极，反馈及时，但还可以改进的地方如下。

  • 每日、每周工作进度及时做总结和汇总。

  • 对产品设计和体验的合理性可具备有一定的思考，主动发现问题、提出问题、解决问题。

  • 开发风格不一致，导致部分问题如下：过度抽象、逻辑管理较乱、变量类型混乱、重复代码过多。

既然发现问题了，就需要进行解决。为此，小明及时与外包同学进行交流后，对方已调整和优化大部分代码，也更加主动积极地进行反馈。

项目结束后，小明还收集了外包同学的一些建议和反馈。

• 该项目过程的一些优点。

  • 初始化时提供的代码大大减少了搭建环境的时间，部分功能模块也得到了复用，对开发速度有很大帮助

  • 项目相关文档很细，降低了不少沟通成本

  • 项目开发过程中，外包同学成长很多，也知道了之前存在的一些问题

• 对该项目的一些建议。

  • 代码规范：外包同学希望负责人（小明）能提供一份前端代码规范

  • 分工：外包同学负责业务相关页面开发，负责人（小明）负责提供基础框架和工具库

  • 视觉还原：外包同学大部分都是编程方向的，对 UI 理解不深，如果希望高度还原或者想做细致的交互，需要在开发前特别提醒

小明梳理了这些内容，打算通过邮件的方式发送给团队以及合作方，同时还可以作为自身的经验沉淀，在后续更多项目中可以进行参考。但是只有这些纯文字内容的输出，似乎除了作为后续项目的参考之外，比较难作为这次项目的复盘结果。所以小明决定，要用数据说话。

用数据说话

性能优化的工作可以用具体的耗时和 CPU 资源占用这些数据来做总结，工具的开发可以用接入使用的用户数量来说明效果，这种普普通通的项目上线，又该怎么表达呢？

前面说过，这次带外包同学进行开发的项目一共分成了两期，第一期开发的时候依然存在一些问题导致延期。小明整理的具体的延期数据如下。

复盘的作用在于可以避免下一次出现同样的问题。于是在二期开发的时候，小明通过一些对策来避免这些问题，例如：

• 开发评估项目预留多一些 buffer；

• 对涉及多方合作的项目，开发负责人（小明）需多预留些 buffer；

• 如果希望高度还原或者想做细致的交互，提前告知外包同学；

• 体验过程中，对开发、体验问题及时反馈；

• 把控需求文档质量，完善交互细节，才给到外包同学进行开发；

• 开发者需预留足够的自测时间，对正常路径、异常路径都完成充分自测。

通过这些对策，二期开发的时候成功地避免了同样的问题。小明以时间线的方式对比了两期的开发时间结果。

除了时间维度，小明还通过质量的维度来对比两期的开发情况。

通过这些数据，再加上前面的问题整理和反馈结果收集，结合前期的准备工作和解决方案，小明将项目的复盘结果输出给团队，大家纷纷表示赞赏。

所以，为什么项目复盘很重要呢？小明来给大家总结下：

1. 及时发现自己的问题并改进，避免掉进同一个坑；

2. 让团队成员和管理者知道自己在做什么；

3. 整理沉淀和分享项目经验，让整个团队都得到成长。

小结

对于大部分前端开发来说，接触工具和框架开发、参与开源项目的机会比较少，很多时候我们写的都是“枯燥无聊”的业务代码。我们总认为只有做工具才会比较有意思、有技术挑战，很多时候会先入为主，认为业务代码写得再好也没用，也渐渐放弃思考要怎么把事情做好。

大家可以尝试对最近做的项目或是事情进行复盘，在这个过程中如果遇到了什么问题，欢迎在留言区进行交流。

---

在最后，我想跟你分享一些前端职业规划相关的内容。

想必每个人都知道要对自己未来的职业发展进行规划，但工作中我们常常忙碌于各种事情，而将它抛之脑后。当想起来要考虑自己未来的方向的时候，经常是因为遇到了瓶颈或是困境。

但其实做工作规划最好的时候，就是在问题出现以前。

今天，我将自己一些职业规划的经验分享给大家，包括：

• 找准自身定位；

• 提升自己的竞争力。

首先，我们需要找准自己的定位。

1. 找准自身定位

对于前端开发来说，技术专业领域同样有不同的方向：纯前端、大前端、全栈。

纯前端，主要工作内容围绕着 Web 开发。可深挖的方向很多，包括关注性能的性能优化领域、关注效能的脚手架/CI/CD等构建领域、关注可维护的项目与代码设计等架构领域、关注浏览器渲染的游戏引擎/WebGL等特殊领域。

大前端和全栈，则分别是以纯前端往终端、往后台等方向拓展而来，同样也有很多可以深挖的方向，这里就不过多延伸。

一个人想要做什么事情，会同时受到很多因素的影响，除了自己对技术的热情和能力，还可能包括遇到的一些人和事，这些都可能会成为我们想要立志做某件事的契机。

那么，要怎么找准自身定位呢？两个建议：扬长避短；将目标放长远。

一、扬长避短

怎么理解扬长避短呢？

我们每个人都有各自擅长的部分，做自己擅长的事情可以更容易发挥自身优势。我们常常会听到其他人说，“你没做过这些、要去挑战自己”。

多尝试一些事情的确是对的，但如果我们需要在这场竞争中生存下来，必须拥有自己的不可替代性，也称之为技术壁垒。而做自己擅长的事情，更容易形成自己的技术壁垒。工作中更有效的方式是扬长避短，而不是花很多时间去补齐短板。因此，尝试找一个可以发挥你自身优势的地方，去做自己擅长的事情。

二、将目标放长远

做职业规划和马拉松很相似，我们需要确定一个较远的目标，拆分成各个小目标，然后控制好节奏、切忌着急和用力过猛。

以我自己为例，一开始我想要往前端深度的领域发展，但我的起跑线是非科班+外包。

显然，我无法一下子到达自己想去的地方，而此时自身的实力也无法和想要的岗位相匹配，因此我整体的职业路线是：外包公司前端→ 中规模公司前端→ 大公司重后台的业务部门前端 → 大公司重前端业务部门前端。

这是一个经历了好几年的过程，每当我觉得在所在的团队中没法获得更多成长的时候，就会选择进入下一个阶段。

如果我们想找到自己想要的工作，首先需要提升自己的竞争力。

2. 提升自己的竞争力

只有让自己有足够的竞争力，才可以有更多选择的机会。那么，要怎么提升自己的竞争力呢？

一、打破“忙于工作”的假象，努力提升自己，保持成长。

常常有人跟我说，说好羡慕我有时间研究技术、写文章。其实我开始写博客的时候，正是我最忙的时候，那会几乎每隔几天就一个通宵发版。

很多情况下，我们之所以会陷入“忙得没有喘息的时间”的困境，常常是因为懒得思考。每天被工作淹没，我们很容易就会因为疲惫而给了自己不去思考的借口。

我换了好多份工作了，感受是工作永远不会给你提供成长的机会的，你要去从工作里挖掘到这样的机会。

越是忙的时候，反而越要去思考怎么改变现状，越要去想想怎么提升自己。

二、养成沉淀的习惯，积极分享。

工作这么多年，有一个习惯让我收获匪浅，那就是坚持将工作和生活中的一些知识、思考和理解沉淀下来。这是一个特别漫长的过程，但大概是这些年来最有价值的投资了。

沉淀的积累，对提升个人自我意识有帮助。获得成就感，可以改善我们的工作和生活，这是一个正反馈的过程。

三、提升个人影响力。

为什么我们需要影响力呢？因为个人影响力会很大程度上影响我们自身的工作体验。例如可能会包括以下问题：

• 在需要依赖他人协作的时候，对方是否愿意积极配合你；

• 其他人是否足够信任你，不会质疑你的能力、挑战你的决策；

• 上级是否能关注到你，可能会影响你的绩效考核甚至升职加薪。

我们的工作中，并不是全部都可以独自一人完成。事实上，大部分的工作内容都涉及与他人进行沟通交流合作。个人影响力会直接影响到他人是否愿意相信和配合你，是否愿意与你积极共事。

那要如何提升自己的个人影响力呢？我认为有两点：

1. 真正地把工作做好。

2. 给予他人帮助。

所谓的影响力，其实来自我们做过怎样的事情。

这些事情可以是自身的，例如拥有比较出名的技术博客、出版过技术书籍、参与过比较大型或是著名的项目等。也可以是团队中的，例如参与了某个项目，在项目过程中积极主动沟通和推动、与他人交流顺畅、能及时发现并解决问题等。

在把工作做好之外，我们还可以多给予他人帮助。比如在他人遇到困难的时候主动提供帮助、在他人遇到问题的时候提供实用的建议。我们还可以将自身一些思考和经验，主动分享给其他人，也同样能给到他们一些帮助。

以上这些，是我一路走来的尝试和经验。工作是双向选择的过程，我们不用觉得自己是弱势的一方，也不必要觉得委曲求全。努力地提升自己，靠自己才是硬道理。

最后，祝各位工作和生活都能披荆斩棘，所向无敌~

同时我邀请你为本专栏课程进行结课评价，因为你的每一个观点都是我和拉勾教育最关注的点。

---

精选评论

**骅：

我在前端领域混了6年了，或者说是一两年经验用了6年，深感自己实力差距。找不到定位，也不知道自己的长处，一度想转行。看完本篇课程后还是打算再努力学一把，希望能有所改观吧。

*月：

大家好，我是被删。声音沉静，温柔，讲课很有条理，逻辑。从宏观层面讲前端，给人耳目一新，豁然开朗的感觉。很喜欢听你讲课，贴近真实开发现状，实在，有用

**7651：

老师广东人吧，课程很有感触

EnochGao：

完结撒花，课程不错，接地气🙌

**溪：

经历的起点类似，但是路径不一样。希望每一个在路上的技术人，都可以越来越好，技术、生活都是。

*宇：

祝大家披荆斩棘，所向无敌