当企业上了ERP 或其他信息系统后，随着业务的发展，总会需要新的功能来助力业务发展，这时就会涉及新功能的开发。不论是标准功能的增强定制，还是自开发新功能，都需要编写开发功能说明书。
身为一枚业务顾问，近一年提出超过100多个大小功能的开发与Bug修复，其中在与开发顾问沟通时，发现原来忽视的功能说明书，作用远比想象得大。
1、我们先来看看什么是功能开发说明书（FS）
如果说设计图纸，是建筑设计师想法落地的载体，那么功能说明书，应该是业务顾问想法落地的载体。建造什么样的房子，主体、结构、水暖、消防等等怎么设计，都体现在设计图纸中，项目施工单位就可根据图纸进行建造。
同样的，实现什么样的功能，怎么实现，功能界面长什么样，与用户怎样交互，具体按钮起什么作用，如果不落到功能说明书上，仅凭语言沟通，不仅很难保证沟通双方理解到对方的意思，还不能确保开发出完善的功能。
在SAP中，一般叫FS，是Function Specification的缩写，意思为SAP程序开发功能说明书。此文档主要是包含开发背景，用户需求，并将所有涉及到需要开发的相关信息和数据收纳在一起，这些信息包括功能设计的思路，取数逻辑等等。
好了，知道了什么是功能开发说明书，有些小伙伴可能觉得就按照前人模板，写一写要实现的功能就好了，重点在开发上，不在文档上。真的是这样吗？
2、开发功能说明书对于功能开发重要吗？
如果说产品是用户和产品经理的沟通媒介，那么产品的功能开发应该是产品经理（也叫业务顾问）和开发人员的沟通媒介，而功能说明书是协助功能开发的第一步。缺少这第一步，后边走的路可能都比较曲折。
日常工作中，不止一次发现业务顾问被开发顾问吐槽功能说明书的问题（我也被吐槽过多次）。吐槽什么呢？来听听他们的声音。
“这什么功能？连个FS都找不到，我刚接手，只能看代码了，但这个代码上千行，注释什么也少”
“写的什么逻辑？就一句话，要过滤掉已反馈的信息，什么才叫已反馈的信息，具体逻辑呢？”
“只考虑了一种场景，那其他不满足或多个查询结果的场景呢？”
就连后接手的业务顾问，在程序出现问题时，翻看之前具体实现逻辑呢？没有。各个表之间取数逻辑呢？判断标准呢？处理逻辑呢？希望得到什么结果呢？统统都没有。除了求助开发看代码，还有进行测试，测出大概的逻辑。
另一方面，功能说明书随意写一写也是常有的事，到了功能开发完毕的测试阶段时，才发现，怎么会有这么多的问题。如果该什么时候做的事情，没有做或没做好，即使功能上线时没有问题，运行时也难保会一切顺畅。
经常是功能上线后被用户发现bug，然后火急火燎地找开发修复，又被动又紧急，被开发顾问吐槽逻辑不清也就不足为奇了。 为了避免或减少总是这么被动的处理方式，有无更好的主动方式呢？
当然有，但怎么在功能设计阶段时，就能尽量全面，且清晰考虑各种业务场景呢？还有详细实现逻辑？比如什么字段对应什么取值逻辑，什么按钮对应什么功能，校验有哪些，对应报错有哪些？
答案是，功能说明书可以帮助我们做到这一点！好的功能说明书，不仅帮助开发人员快速理解核心诉求，提高沟通效率，还有助于提高新开发功能的质量，减少Bug数。
3、什么才叫好的功能说明书呢？
我理解好的FS特点是简洁明了，特别是功能比较复杂，逻辑比较绕时，越简洁明了，表明自己想得越清晰，越明白。作为接收方的开发人员，也能更轻松得了解要开发的功能。
日常线上沟通时见过有人总是一大段一大段文字的发出来，全篇只有逗号，工作忙时都不想看他要说啥，只能大眼一扫，难免会漏掉一些信息。但有些人发出来的信息言简意赅，还罗列1、2、3，分层清晰，阅读时很清晰理解对方的意图。
那怎么做到简洁明了呢？
①文章结构，一般FS都会有模板，我们所参照的模板如下：
1.1流程概述明确为什么要开发这个功能，并且在业务流程中所处于哪一步进行该功能操作.1.3场景中，清晰描述中功能菜单在哪里、功能界面长什么样、涉及数据表及新增字段类型、详细一步步的具体实现逻辑。采用模板另一个好处是防止遗忘，因为有场景1，激发往前想一步，是否有场景2、3等等。
②文字内容简练，能写步骤的就Step1、2、3罗列，分情况的不论是①②或A、B、C，都用起来，有重点的可加粗标黄。写出来的逻辑一定要在开发或测试系统中，借助现有数据验证，一验证就会发现一些被我们忽视的细节。 
最重要的还是要在FS书写时想清楚实现逻辑，只有底层清晰了，书写起来更容易，与开发同事对接更高效。另外，业务时间也可多多练习写作能力，将自己生活、工作、学习中的感悟写下来，帮助自己成长。
周末啦，好好休息玩耍，周一又是满满元气的工作。