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

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

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

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

# 事前做预期

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

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

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

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

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

# 如何进行合理的分工排期

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

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

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

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

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

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

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

# 对项目风险进行把控

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

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

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

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

# 事后做复盘

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

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

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

# 用数据说话

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

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

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

其中,时间维度可以包括:

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

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

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

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

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

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

所以,为什么项目复盘很重要呢?

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

# 输出结果

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

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

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

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

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

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

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

# 结束语

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

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

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

部分文章中使用了一些网站的截图,如果涉及侵权,请告诉我删一下谢谢~
温馨提示喵