当开发的个人能力成长到一定程度时，日常工作不再是缝缝补补、修修 bug、打打下手。

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

在项目进行的每个阶段，我们都可以通过同样的方式去提升自己：

1. 事前做预期。
2. 事后做复盘。

事前做预期

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

1. 预期功能是否能实现？存在哪些不确定的功能？
2. 预计的工作量和分工排期是怎样的？
3. 每个阶段（开发、联调、产品体验、提测、发布）的时间点大概是怎样的？
4. 哪些工作涉及外部资源的依赖和对接（交互/设计/接口协议等），是否存在延期风险？
5. 如果存在风险，有没有什么方式可以避免？

这么做有什么好处呢？如果不做方案调研和项目预期管理，那么对于项目过程中的风险则很难预测。这会导致项目的延期，甚至做到一般发现做不下去了。

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

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

如何进行合理的分工排期

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

1. 确认技术方案，以及分工合作方式。
2. 拆分具体功能模块，分别进行工作量评估，输出具体的排期时间表。
3. 标注资源依赖情况和协作存在的风险，进行延期风险评估。

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

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

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

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

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

对项目风险进行把控

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

• 因为方案设计考虑不周，部分工作需要返工，导致项目延期
• 在项目进行过程中，常常会遇到依赖资源无法及时给到、依赖方因为种种原因无法按时支援等问题，导致项目无法按计划进行
• 团队协作方式未对齐，开发过程中出现矛盾，反复的争执和调整协作方式导致项目延期

一个项目能按照预期计划进行，技术方案设计、分工和协作方式、依赖资源是否确定等，任何一各环节出现问题都可能导致整体的计划出现延误，这是我们不想出现的结果。

因此，我们需要主动把控各个环节的情况，及时推动和解决出现的一些多方协作的问题。

事后做复盘

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

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

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

用数据说话

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

我们可以用两个维度复盘：

1. 时间维度。
2. 质量维度。

其中，时间维度可以包括：

• 项目的预期启动、转体验、提测、灰度、全量时间
• 项目的最终启动、转体验、提测、灰度、全量时间

通过预期和最终结果的对比，我们可以直观看到是否存在延期等情况，分析原因分别是什么（比如方案设计问题、人员变动、协作方延期等）

如下图，假设项目分为一期、二期，我们可以在一期结束后，进行复盘分析并改进。同时还可以以时间线的方式对比开发时间结果：

除了时间维度以外，我们还可以通过衡量项目质量的方式来复盘，比如：

• 代码是否有单测、自动化测试保证质量
• 产品体验阶段的问题、提测后 BUG 分别有多少
• 灰度和全量后的用户反馈有多少

我们需要分析各个阶段存在的质量问题，并寻找原因（比如技术方案变更时考虑不全、设计稿还原度较低、自测时间不足等）。质量的维度同样可以用对比的方式来展示：

所以，为什么项目复盘很重要呢？

1. 及时发现自己的问题并改进，避免掉进同一个坑。
2. 让团队成员和管理者知道自己在做什么。
3. 整理沉淀和分享项目经验，让整个团队都得到成长。

输出结果

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

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

职场之所以让人不适，很多时候是由于它无法做到完美的公平。对于程序员来说，同样如此。

因此，为了能让自己付出的努力事半功倍，阶段性的输出是必不可少的。对于项目复盘来说，我们可以通过团队内外分享、邮件复盘总结等方式进行输出。

一般来说，可以通过几个方面来总结整理：

1. 项目背景，比如为什么启动项目、目标是什么之类。
2. 技术方案，是否做了技术选型、架构设计等。
3. 项目结果，时间维度和质量维度，最好有数据佐证。
4. 未来规划/优化方向。

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

结束语

本文介绍了在项目开发过程中，要如何做好前期的准备，又该如何在项目结束后进行完整的复盘。

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

其实不只是工作中，我们生活里也可以常常进行反思和总结，这样我们的步伐才可以越跑越快。成长的过程中总会遇到各式各样的问题，有些问题被我们视而不见，有些问题我们选择了躲开，但其实我们还可以通过迎面应战、解决并反思的方式，在这样一次次战斗中快速地成长。

查看Github有更多内容噢：https://github.com/godbasin
更欢迎来被删的前端游乐场边撸猫边学前端噢

如果你想要关注日常生活中的我，欢迎关注“牧羊的猪”公众号噢