提 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 者判定