2010年，定制化的需求如雪花般纷至沓来，公司迅速拥抱了敏捷开发模式。为了适应市场对“快速响应”的要求，研发团队进行了重组。敏捷教练不仅让产品特性Owner参与特性识别，还特意邀请文档工程师加入会议，目的并不是让他们编写复杂的技术文档，而是通过这种方式将原本模糊的需求转化为可验证的用户故事。 在这个过程中，大家把“编写需求文档”这个环节去掉了，转而用一种新的结构化方式来替代它。这个新的结构化文档模型被拆分成了三大块：第一块是特性定义，用一句话说明这是个什么东西；第二块是特性清单，用表格形式列出要做的事情；第三块是特性手册，用流程来解释怎么使用它。把这些模块放进特性文档平台后，系统工程师只需要把需求条目拖进去，就能实现需求跟踪的可视化。 这种界面看起来像是Word那样熟悉，实则藏着结构化的骨架。多人可以一起协同编辑内容，更新起来就像拼乐高积木一样方便。通过这一模式，团队用同一套内容同时产出了特性定义、清单和手册。交付周期从之前的一周缩短到了几天，质量却得到了保障。一次开发可以复用在多个终端上，文档交付的成本直接降低了50%到80%。 有一次冬天，我在PTC的用户大会上分享了自己过去踩过的坑：当初被“Word文档够用就行”的想法逼到了绝境，只能在各种模板、格式和版本号之间来回折腾。结果我刚讲完坐下来，几位不同公司的参会者就递上名片说要改善文档工作。但当我听到他们说其实是想请我帮忙优化Word模板时，笑容瞬间僵在脸上。我当时只好建议他们先补上写作培训这一课。 原来在敏捷时代里的研发项目中，特性Owner、架构师、测试人员和开发人员都会一起拆分场景。大家要用“使用者视角”把最佳业务流程、数据表结构以及UI路径都写清楚，让文档本身具备模块化的基因。就这样，传统需求文档退场了，特性文档登场了。它就像乐高积木一样可以拆可以拼，正好给了结构化文档展示的舞台。