关于问题追踪系统的简要论述
起源
问题追踪（Issue Tracking）的概念起源于客服部门。用户打电话反映问题，客服就创建一个工单，后续的每一个处理步骤、每一次与用户的交流，都要更新工单，记录全部信息。这是问题追踪的前身。
BIM 咨询团队的主要工作内容之一，就是编写问题报告，将设计问题反馈给相关人员。目前问题报告使用电子文档编写，这种信息记录和传递的方式存在先天不足，工作流不规范，效率低，依赖人员的责任心。
设想一个信息系统，允许成员间互相指出问题，系统负责记录和追踪，督促责任人解决。每个问题应该包含该所有相关信息和历史，使得他人只需查看问题记录，就能了解其所有过程。管理者也可以随时总揽全局，查看问题的解决情况和统计数据。这个系统具有精细的权限管理能力，简单明了的管理工具，还有强大的扩展能力，方便未来新增功能和其他系统对接。如果将所有待办事务都视作广义的问题，该系统不仅可以用来替代问题报告，而且可以应用在项目管理的各个层面。这就是问题追踪系统。
流程
问题追踪系统已成为互联网开发团队的标准配置。在软件开发中，最传统的问题追踪，也就是缺陷追踪，基本工作流程如下：
- 发现问题并提交
- 相关责任人讨论解决
- 提交人确认问题解决
- 提交人或管理员关闭问题
- 在基本流程框架下，需要根据行业和工作模式的不同，填充大量的细节，才能形成一个完善好用的问题追踪系统。我在华艺 BIM 团队服务时，已经对这个想法做了一定深度的探索，并编写了软件原型，可供参考。
简析
利益
使用问题追踪系统代替传统问题报告，短期内就能获得以下好处：
- 及时透明的信息传递
- 确保问题落实到位的能力
- 提升团队的科技属性和竞争力
- 长期来看，通过对问题追踪平台持续深化，也可将其发展成为强有力的通用型项目管理工具。
问题
目前市场上存在多种所谓的建筑设计协同平台，使用这类产品后，通常会发现如下问题：
- 功能繁多复杂，学习推广成本高
- 平台难以融入现有工作流程
- 需要新功能只能等待软件更新
- 此外，平台的研发和维护成本也极高。
我从中学到的几点是：
- 不应该一开始就建立一个大而全的系统，而应专注于一个痛点，精雕细琢，产出小而美的产品。
- 不应该直到功能完备才交付成果， 而应该让用户在早期就参与使用，开发团队积极倾听反馈，快速迭代。在这个过程中，用户与产品互相熟悉，共同成长。
- 平台的核心思想要足够普适，软件架构要具备扩展弹性，用户能通过简单开发实现新功能。