野火🔥

复杂多人项目Owner思考

2018/04/18 Share

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职责:根据各方拆解建立排期和里程碑,并组织站会,站会中回归项目风险点。
CATALOG
  1. 1. 1、背景
  2. 2. 2、Delay一般原因分析
    1. 2.1. 2.1 时间评估问题
    2. 2.2. 2.2 Owner在项目运行中缺少纠偏
  3. 3. 3、规避问题方式
    1. 3.1. 3.1 重视技术方案设计
    2. 3.2. 3.2 重视站会和里程碑
    3. 3.3. 3.3 大需求的分解code review
  4. 4. 4、总结