當企業上了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書寫時想清楚實現邏輯，只有底層清晰了，書寫起來更容易，與開發同事對接更高效。另外，業務時間也可多多練習寫作能力，將自己生活、工作、學習中的感悟寫下來，幫助自己成長。
週末啦，好好休息玩耍，週一又是滿滿元氣的工作。