如何描述好一个问题。
本周在几个不同的会议上，和不同的同事过问题清单，发现大家很少把问题描述的非常清楚。导致在复盘问题的时候，还需要不断的找到提问的同事询问，到底是什么问题。有些时候，我们能得到具体的答案，有的时候，因为时间太久，他自己也记不清楚了。
那么，如何描述好一个问题，才能够减少沟通？
就像我们上学的时候写记叙文，有六要素，时间，地点，人物，事情的起因，经过，结果。对于描述问题，其实也是大概这么个套路。
- 问题发生的时间，记录时间的用途在于可以用于追溯在那个时间范围，是否有相同的问题发生。
- 问题发生的地点，可以是所在的办公室，具体操作的电脑，使用的哪套系统。
- 与问题有关的人物：操作人员，操作账号
- 事情的起因：就是我们要有什么样的业务，准备开始在系统里面做什么操作。
- 事情的经过：这一部分是需要重点描述的。在做PPT的时候我们知道，一图胜千言，在描述问题的时候，如果用图来描述，也有同样的效果，如果有相关的视频，可能会更加直观。用SAP系统举例，事情的经过包含以下几个重点内容：
a) Tcode：操作的tcode是什么
b) 单据编号：比如采购订单号、销售订单号、凭证号等等
c) 录入内容：在哪个字段，需要录入什么样的信息。
d) 错误信息：这个最好是有全面的截图，以及对应的操作，比如是鼠标点击，回车，或者其他的操作。 - 事情的结果：这个是留着要给后续问题关闭的时候用的。如何解决的问题，是改了开发，还是改了配置，还是用户操作顺序问题等等。
我想，这样记录下来的问题，多半是不需要再找提出人去确认的。如果可能的话，接到这个问题的人自己会找相类似的环境，去测试，或者去复现，看同样的数据和操作，是否会出现同样的结果。
最好，后面还有个“反思”或者延伸思考，如何避免这个问题。
这样记录问题，虽然繁琐，但是能够将问题完整的记录下来，对于其他人也会有比较好的借鉴意义。
一个好的知识库，就是通过一个一个问题，不断的积累，才能够最终构建起来。
