日常工作中，我们常常会以项目的形式参与到具体的开发中，可能会负责项目的主导，或是作为核心开发负责某个模块、某个技术方案的落地。
很多人会觉得做一个普通的前端项目，从开发到上线都没什么难度。一个字：“干”就完了。
实际上，项目的管理、推动和落地是工作中不可或缺的能力，这不同于技术方案设计、代码编写，这属于工作中的软技能。但正是这样的软技能会对我们的工作成果产生很大影响，也会影响自身的成长速度，更是升职加薪的必备技能。
在项目进行的每个阶段，我们都可以通过同样的方式去提升自己：预期→结果→复盘。我们来分别看下。
就像在开发前进行架构设计一样重要，我们在项目开始前，需要对项目的整个过程进行初步的预估，包括：
这么做有什么好处呢？我们来看个小故事。
小明接到个新活，老板说现在的项目代码量很多，各个模块之间耦合相当严重，需要重构。
这是个大活，小明接到之后就开始进行调研和设计。但是这么大规模的项目，又进行大规模重构的案例实在太少了，基本找不到可以直接借鉴的解决方案。于是，小明跟老板要了一周的时间，打算拉个分支边写 DEMO 边调整方案。
这样的大重构，需要对各个模块做好充分调研，也需要对方案进行全面完整的风险评估，但小明觉得这根本就没法做到，太麻烦了，于是就想到哪写到哪。一周过去了，小明改好了一个模块，感觉这样改比较可行，于是跟老板要了三个月的完整改造期。
一个月过去了，小明发现代码写到一半写不下去了，有几个模块不支持预期的改法，需要对方案进行大调整。接下来，项目从预期的三个月变成了四个月，四个月又拖到了半年，迟迟上线不了。老板对小明表示很失望，小明的绩效也跟着失望。
或许在大家看来，小明做事太不靠谱了。实际上在我们的工作中，这样的情况常常会遇到，很多人甚至对需求延期都已经习以为常了，认为需求能准时上线才是稀奇的事情。正因为大家都是这样的想法，我们更应该把这些事情做好，这样才可以弯道超车。
首先，在项目开始的时候，需要进行工作量评估和分工排期。
进行工作量评估的过程可以分为三步：
当我们确认好技术方案之后，需要针对实现细节拆分具体的功能模块，分别进行工作量的预估和分工排期。否则可能面临分工不明确、接口协议未对齐就匆忙开工、最终因为各种问题而返工等情况。
我们在进行工作量评估的时候，可以精确到半天的工作量预期。对独自开发的项目来说，同样可以通过拆解功能模块这个过程，来思考具体的实现方式，也能提前发现一些可能存在的问题，并相应地进行规避。
提供完整的工作量评估和排期计划表（精确到具体的日期），可以帮助我们有计划地推进项目。在开发过程中，我们可以及时更新计划的执行情况，团队的其他人也可以了解我们的工作情况。
工作量评估和排期计划表的另外一个重要作用，是通过时间线去严格约束我们的工作效率、及时发现问题，并在项目结束后可针对时间维度进行项目复盘。
为了确保项目能按照预期进行，我们还要对可能存在的风险进行分析，提前做好对应的准备措施。
我们在项目开发过程中，经常会遇到这样的情况：
一个项目能按照预期计划进行，技术方案设计、分工和协作方式、依赖资源是否确定等，任何一个环节出现问题，都可能导致延误。因此，我们需要主动把控各个环节的情况，及时推动和解决一些多方协作的问题。
下面我们来看一个详细的例子。
小明接到一个需要带外包同学进行小程序开发的项目，张三听说了，就跟小明吐槽说之前也做过类似的项目，外包同学写的代码可乱了，最后交付的时候甚至都还有报错。
换作是其他人，听了张三的话可能都开始泄气了，内心想着：这么麻烦的活，估计最后还得自己擦屁股。可小明不一样，他找到张三详细咨询了之前项目的一些情况，整理出来一系列问题（如需求反复、外包沟通成本高、验收标准模糊、排期不合理等）。
小明分析了下，问题的确很多，但都是可预估的风险。为了避免同样的问题出现，小明特地做了一些前期的准备工作（如明确验收标准、制定排期、建立沟通机制），并且最后达到了不错的使用效果。
通过前期准备的这些方案和工具控制了很多可预见的风险，一期整个开发过程比较顺利，外包同学表示合作过程很愉悦，最终的交付质量也比预期好很多，连张三也拍手称好。
在这个项目中，小明对可能存在的问题做了充分的调查，并提供了一系列的技术方案避免了问题的出现。但小明觉得这还不够，项目虽然成功上线了，但其实也出现了一些延期的情况。项目还要进行二期开发，于是小明决定要进行项目复盘，找到问题在哪。
很多开发习惯了当代码开发完成、发布上线之后就结束了这个项目，其实他们遗漏了一个很重要的环节：复盘。
对于大多数开发来说，很多时候都不屑于主动邀功，觉得自己做了些什么老板肯定都看在眼里，写什么总结和复盘都是刷存在感的表现。实际上老板们每天的事情很多，根本没法关注到每一个人，我以前也曾经跟老板们问过这样一个问题：做和说到底哪个重要？
答案是两个都重要。把一件事做好是必须的，但将这件事分享出来，同样可以给团队带来更多的成长。
通过对项目进行复盘，除了可以让团队其他人和老板知道我们做了些什么，更重要的是，我们可以及时发现自身的一些问题并改进。
小明在一期的项目结束后，整理了这次开发过程中存在的问题。
项目结束后，小明还收集了外包同学的一些建议和反馈。
性能优化的工作可以用具体的耗时和 CPU 资源占用这些数据来做总结，工具的开发可以用接入使用的用户数量来说明效果，这种普普通通的项目上线，又该怎么表达呢？
前面说过，这次带外包同学进行开发的项目一共分成了两期，第一期开发的时候依然存在一些问题导致延期。小明整理出了具体的延期数据（如接口联调超时、需求变更未纳入排期等）。
复盘的作用在于可以避免下一次出现同样的问题。于是在二期开发的时候，小明通过一些对策来避免这些问题，例如：
通过这些对策，二期开发的时候成功地避免了同样的问题。小明以时间线的方式对比了两期的开发时间结果，二期明显更高效。
除了时间维度，小明还通过质量的维度（如 Bug 数量、需求返工率）来对比两期的开发情况，二期质量也更稳定。
通过这些数据，再加上前面的问题整理和反馈结果收集，结合前期的准备工作和解决方案，小明将项目的复盘结果输出给团队，大家纷纷表示赞赏。
所以，为什么项目复盘很重要呢？小明来给大家总结下：