提 Issue 的好习惯

测试或使用产品难免会遇到 Issue(问题)。那么,在较为规范化的团队产品管理工具(无论 Trello、Tower、GitLab 等等)中向工程师、设计师、产品经理自己或任务团队成员提 Issue,都有必要将 Issue 提得「有模有样」,具体表现为:

  • 描述 Issue 背景,可以的话,尽量还原遇到 Issue 的场景
  • 附上必要的材料,如图片、视频(毕竟现在录制视频那么方便)
  • 描述系统环境、产品版本号
  • 描述期望得到的结果,以及为什么
  • 提出解决方案(有时候未必知道,那可以寻找参考)
  • 指定 Issue 解决者(若不清楚谁可解决,可先指定给产品负责人)
  • 指定 Issue 可归属于哪个版本解决(也就是设立 Milestones,尤其当自己是负责人时)
  • 打上 Issue 标签,例如属于用户体验?还是 bug?
  • 指定哪天可以完成(也就是 Due Day,一般 Issue 解决者自己决定,或与项目负责人商榷)
  • Issue 的标题要有意义且有指向性,像「首页有问题」就不是个好标题

除此之外:

  • 一次只提一个 Issue,即便 Issue 相关也要做好拆分以便回溯
  • 在 Issue 所在的地方讨论,而不是在其它沟通渠道讨论,同样有利于团队回溯
  • 谁提 Issue,就应该谁来 Close Issue,也就是说,最终检验 Issue 有没有被解决,由提 Issue 者判定

你可能感兴趣的:(提 Issue 的好习惯)