最近一个迭代接了一个需求，自己提了一个需求总的来说，做的一般般，核心问题在于工作量的预估跟实际的工作量差别较大，导致开发质量一般，自测质量一般，最后上线质量也一般
请求录制和录制布局需求
即使把改动的技术点整理了出来，但没有做好的点也很多
- 技术点整理的太粗糙，没有暴露细节
- 例如请求录制的整个流程没有串联起来，只是把请求录制、处理请求这些点列出来，但没有把整个流程串联起来作为改动点的一个
- 例如录制布局，只是把更新布局作为一个点，但没有把各种视图、各种视图操作组合都整理完（例如全屏+收起、会控、共享），导致隐藏的工作量没有被纳入
- 没有合理的评估工作量，工作量评估过于乐观
- 不愿去准确的评估工作量，把技术改动点整理好了之后，直接开始开发了，历史的惯性和人的惰性
- 产品定义模糊
- 需求评审的时候就有一个模糊的点，但大家没有去跟进，等到提测的时候，测试拿出来反馈，gg
- 协同方心各不一
- 测试评审的时候，测试就知道整个需求不可能高质量完成，但我理解成可以在封板前基本功能ready，封板后bugfix，这里的信息差带来了录制布局直接不上了
- 服务端投入时间偏晚
日志上传
这个是我自己提的需求，犯了几个问题
- 争取设计资源过晚，浪费了一天的开发工作量
- 需求设计和设计同学理念不一致，需求出现反复，改来改去
- 开发自己提的需求，产品思维欠缺，同时又没有拿出来评审，导致需求出现反复
- 需求变更后，已经来不及了，但还是硬上，影响了其他需求的高质量交付
综合回顾
- 详细设计文档要写，这个只能不断锤炼自己的架构能力了
- 难点在于不知道要如何完成，例如会中profile，真的就是一边写一边才知道要做什么，很多时候是写完了第一步才知道第二步怎么做
- 产品定义要清晰、测试要点要明确，各方理解要一致，避免模糊
- 各方时间投入点要确认，如果一开始就有问题，就尽早调整减少需求量或者下个迭代，不要冲刺（冲刺意味着赶工）
- 避免需求开发时间重叠，一旦有重叠，要迅速确定优先级，避免多线并行的情况，宁愿优先级低的delay，也不要两个质量都不高
- 坦然面对和接受自己的不足（包括需求拆分能力、工作量评估能力、协同方协调能力、工程实现能力），并持续提升自己的能力
标签：需求,迭代,回顾,项目,录制,能力,工作量,测试 From： https://www.cnblogs.com/qwj-sysu/p/17626634.html