前端在研发过程中都做些什么

一个项目从需求产出到研发上线,都经历了哪些阶段?本文面向前端同学,从角色维度讲述了各阶段的职责、注意事项,供参考

一般流程

一个健康的项目流程大致为:

  • 需求阶段
    • 产品设计
    • 上下游沟通
    • 业务宣讲
    • 需求评审
  • 系统设计
    • 交互评审
    • 后端系分评审
    • 前端系分评审
    • 测试系分评审
    • 各域工作量评估
  • 研发实现
    • 编码、自测
    • 联调
    • 发布分析
      • 兼容性、风险、发布顺序、回滚方案
    • 交付测试
      • 开发环境
      • 集成环境
        • 验收阶段
        • 视觉还原
      • 预发环境
    • 发布

职责划分

PM

PM(Project Manager)是项目导演,把 PD / 前端 / 后端 / 设计 / 测试链接在一起,一是推动项目进度(如主导上述各阶段),保持各域信息对称,规避(提出)风险,保障顺利交付;二是统筹资源,合理安排人员分工和需求迭代。

如果 PM 没有尽到职责,很容易让项目节奏陷入混乱,如各阶段无人牵头,导致合作陷入乱序;未做好信息同步,导致研发低效,项目产生风险。这时候,作为项目一份子,前端可以主动站出来提出问题,并在适当的情况下引导阶段步入正轨。

在工作量评估上,需要提前统筹手里的工作,保障能应对各业务的支撑。一般项目没到集成阶段,不能视为已经释放投入,所以不要将新需求插到集成阶段前。如果 PM 提出的工期无法满足,先咨询师兄或老板的建议,不要给出无法付诸的承诺,否则很容易让自己陷入被动,加班到昏天暗地。正常情况下不接受倒排。

如何评估工作量?以下公式可供参考:

  1. 需求明确,有过实现经验:评估时间 * 1.5
  2. 需求方比较生疏(可能变动):评估时间 * 2
  3. 技术方案需要调研:评估时间系数 + 1

合理安排 buffer 时间,要留有余地,因为中途可能因为各种事情被打断,如评审会议、团队事项等,项目顺利迭代需要大家一起保障,工作延期会对项目形成较大负面影响;同时本着对自己负责的态度,超出正常 buffer 的时间会引来团队和合作方的质疑。

PD

PD(Product Dog Director)直接对接业务方,产品实施的设计者,因此需要对需求进行理解与明确,合格的 PD 不应该提出不明确的需求,更不能随意变动。

需求上,前端需要合理把控:当需求不明确(不靠谱,易变动),先让需求方给出明确范围,面对不合理的需求要根据对产品的理解提出自己的质疑,甚至可以结合业务数据论证需求的合理性。中间新加的需求走排期,如非必要不接受插队。

前端如何判断需求是否站得住脚呢?这就需要前端充分理解业务,了解业务的前身、现状和将来规划,它形成的闭环是怎样的?是否偏离业务本来的目标,如何进行调整?当你理解了 PD 为何要这么做,你才能用你的论据和数据进行探(Si)讨(Bi)。

产品过程中需要的要素,如文案、链接、图片、配置等,需要 PD 及时给到,一般是测试阶段给到,如果延期提供,需要提前给测试明确情况,如果集成或者验收前都没能提供,前端要及时抛出问题。

设计

设计在前期会更多和 PD 沟通业务流程、交互逻辑,甚至比 PD 更加了解产品的实现流程。最终前后端也是按设计稿实现,因此交互和视觉稿一定要在前后端系分前评审。

前端需要根据交互稿进行完整的业务推演,逻辑穷举,如果有问题,及时抛出,不健全的交互在项目后期肯定会出现状况和争执。

交互稿应明确标明交互细节,未明确的范围前端要主动和交互确认,避免因遗漏细节,在后期提出未达成一致的变化范围,前端有理由拒绝。

在交互上,如果有难以实现或者投入产出比不大的实现,可以先和交互同学聊,并将产生的额外工作给到 PD、PM,让项目组一起权衡,是否对产品发展有利。

前端

前端不仅在技术上有专业素养,对业务的输出和责任感也是核心职责。

在需求阶段,我们可以做的事情包括:

  1. 提前安排手里的工作,调整优先级和投入,做技术储备等
  2. 各评审前,通读 PRD 和设计稿、系分,在会上要有自己的输出,给合作方产生信任感

在开发阶段,除了完成编码,前端还要保障代码质量,比如在集成阶段前进行整体的 Code Review,一些问题常会在这个阶段被发现。同时,把控手里工作进展,定期过进度,提前抛出风险(找团队、PM),不要让炸弹在手里默默爆发。

对于投入情况、业务变动,也需要及时同步给团队,方便 TL 统筹安排,了解业务现状。

后端

对于业务来讲,数据是核心价值,系统设计也围绕着后端来进行。PD 在需求阶段会更多和开发打交道,有时小型项目会直接由开发担任 PM 角色,因此前端需要和后端保持密切沟通。虽然后端对系统整体流程设计有更多责任,但前端和后端是合作关系,交互流程需要一起参与讨论,这可以避免不合理的设计留到项目后期。

接口由前端消费,所以前端更加关心数据结构的可预测性,一般由前端来统一制定消费接口,并和后端核对,设计过程中,按照最佳实践和规范制定字段。有不合理的设计,或者有安全风险的接口,要向开发提出,并同步主架构来把控整体接口质量。

由于后端代码是黑盒,而前端是大家可以直观“感受”到的,并且由于发布机制差异,导致各域会有前端“比较容易修补和发布”的印象,因此对于问题的处理上,前端有必要用正确的眼光来看待:

  1. 对于线上问题,如果有较大影响,本着为产品负责的态度,前端可以快速止血,如果问题在后端,必须后端及时解决根源问题
  2. 需要由前端来修补的问题,明确问题界限,非前端责任域,要明确拒绝承担额外的成本和风险

在联调阶段,后端应该保障接口的可联调性,充分自测,提供测试账号和数据(如果不便,前端不要自己去造数据),如果联调能力不达标,前端要及时提出,并根据情况同步给团队。

后端对接口需提供各状态的结构和详细字段枚举,不接受直接透传上游,前端只和接口直接提供方对接。

测试

测试是项目健康的把关者,在评审阶段,应当明确用例,这有助于开发者自测,也明确了验收范围,真正做到对项目质量把关。对于存量业务的影响,前端也要主动提出,这有利于测试评估时间。

对于 bug,测试需要提能追溯的缺陷链接,避免口头传递,否则容易引起缺陷遗漏。

当项目整体的测试工作未就绪,比如遗漏了某些地方,而测试同学未意识到,此时前端同学可以主动告知,避免在验收阶段出现缺陷拥堵,影响项目进度和质量。

最后

大家都不容易,各有各的苦,得饶人处且饶人。我还是倡导大家和谐共处,共同保障一个温馨的打工环境。