野火🔥

生命如野火,骄傲而顽强

复杂多人项目Owner思考

1、背景

UGC方向业务场景比较复杂,易同时出现多职能线和多业务线的大需求,而PM经常要求赶在某个版本前上线,使得频繁出现“时间倒排”
当业务复杂遇上需求较大,那么每个业务方人员平均参与人数将大于1人,项目复杂度也会成倍提升。
需求完成情况最终体现在“代码合入”时间节点上,分解开来,便是提测时间点代码质量。如果开发团队没有应对复杂业务逻辑、多业务线、多人项目工程化能力,最终导致项目delay或者采用加班方式解决问题,会遭各方吐槽,长此以往,则失去信任力。

2、Delay一般原因分析

一般出现这类原因有两点:开发者时间评估不准确;缺乏纠偏。

2.1 时间评估问题

  • 需求点把握不足:没能准确的将需求各个模块分解和细化。
  • 核心流程图缺失、整体架构设计缺失:整体认知不足,不能高屋建瓴。
  • 过UI/UE时间评估不足,联调时间评估不足。

2.2 Owner在项目运行中缺少纠偏

  • 没有里程碑或者里程碑过于简略 。
  • 里程碑进展出现问题,不能尽快完成纠偏,导致问题持续、放大,最终导致delay。

3、规避问题方式

3.1 重视技术方案设计

  • RD在提供排期时,需同时提供详细的分解工期,否则该排期不应予以接受。
  • Owner应review各RD的需求分解的合理性。
  • RD内部需要做技术方案,并内部进行技术方案review,技术方案需要包含核心业务流程图(后端API调用流程、主干UI交互流程)。

3.2 重视站会和里程碑

  • 过UI/UE时间点联调时间点是项目进度管理中的重要里程碑。
  • 表格、看板、甘特图都是可选的项目管理工具,复杂项目运行过程中至少使用一种。
  • 要有规律的站会,站会重点review进展和里程碑完成情况。
  • 每次站会需根据实际情况调整分解排期里程碑,出现delay风险需提前周知项目利益方。

3.3 大需求的分解code review

项目内部需有code review里程碑,根据里程碑分解code review。
--- 分阶段code review思考待续 ---

4、总结

  • RD职责:做项目拆解及各分解时间安排,做技术方案。
  • Owner职责:根据各方拆解建立排期和里程碑,并组织站会,站会中回归项目风险点。