一次项目迭代的回顾

最近一个迭代接了一个需求，自己提了一个需求总的来说，做的一般般，核心问题在于工作量的预估跟实际的工作量差别较大，导致开发质量一般，自测质量一般，最后上线质量也一般

请求录制和录制布局需求

即使把改动的技术点整理了出来，但没有做好的点也很多

• 技术点整理的太粗糙，没有暴露细节
  • 例如请求录制的整个流程没有串联起来，只是把请求录制、处理请求这些点列出来，但没有把整个流程串联起来作为改动点的一个
  • 例如录制布局，只是把更新布局作为一个点，但没有把各种视图、各种视图操作组合都整理完（例如全屏+收起、会控、共享），导致隐藏的工作量没有被纳入
• 没有合理的评估工作量，工作量评估过于乐观
  • 不愿去准确的评估工作量，把技术改动点整理好了之后，直接开始开发了，历史的惯性和人的惰性
• 产品定义模糊
  • 需求评审的时候就有一个模糊的点，但大家没有去跟进，等到提测的时候，测试拿出来反馈，gg
• 协同方心各不一
  • 测试评审的时候，测试就知道整个需求不可能高质量完成，但我理解成可以在封板前基本功能ready，封板后bugfix，这里的信息差带来了录制布局直接不上了
  • 服务端投入时间偏晚

日志上传

这个是我自己提的需求，犯了几个问题

• 争取设计资源过晚，浪费了一天的开发工作量
• 需求设计和设计同学理念不一致，需求出现反复，改来改去
• 开发自己提的需求，产品思维欠缺，同时又没有拿出来评审，导致需求出现反复
• 需求变更后，已经来不及了，但还是硬上，影响了其他需求的高质量交付

综合回顾

• 详细设计文档要写，这个只能不断锤炼自己的架构能力了
  • 难点在于不知道要如何完成，例如会中profile，真的就是一边写一边才知道要做什么，很多时候是写完了第一步才知道第二步怎么做
• 产品定义要清晰、测试要点要明确，各方理解要一致，避免模糊
  • 各方时间投入点要确认，如果一开始就有问题，就尽早调整减少需求量或者下个迭代，不要冲刺（冲刺意味着赶工）
• 避免需求开发时间重叠，一旦有重叠，要迅速确定优先级，避免多线并行的情况，宁愿优先级低的delay，也不要两个质量都不高
• 坦然面对和接受自己的不足（包括需求拆分能力、工作量评估能力、协同方协调能力、工程实现能力），并持续提升自己的能力