寫文檔時最先考慮的應該是誰？

教科書裏總說，stakeholders，利益相關方，這裏有很多人，可能是甲方公司裏的所有人。如果需求方前期給的信息足夠詳細，動筆的時候應該能夠列出核心的幾個利益相關方，每個利益相關方的業務流程如何，甚至部分業務規則和相關的約束。有些業務流程非常復雜，細節很多，圖文混合洋洋灑灑可以寫上好幾頁，這些東西要不要都寫上去？考慮到需求分析文檔通常是項目方拿下項目的第一步，要註意，很有可能項目還不確定是自己的，做不做還不一定呢。通常這種文檔的期限都比較短，一兩天之內就要交差，如果提前已經有成型的段落圖片積累還好，可如果完全從頭開始，怎麽才能用相對短的時間交一個還算像樣的答卷？這時候在那麽多的利益相關者當中更應該考慮誰的感受？

如果有人想找我做一個項目，簡要敘述一下需要我做的功能，我首先關註的是，這個項目我能不能接，也就是根據對方提出的功能列表判斷我現在有沒有這些功能，沒有的話實現難度如何，時間如何，劃不劃算。按著這個思路寫下去，那寫文檔的投入產出比可能不高。甲方看這篇文檔看的是，我（甲方的“我”）希望通過這個項目獲得什麽，這就有點像寫BP，不是單純寫技術多牛，業務水平多高，而是讓投資人從這裏面看到投資回報。因此，如果對方想要流程優化，那就應該寫出新舊流程對比，舊流程不足在哪裏，新流程如何改進；如果要維護便利或安全性，那就得在非功能需求方面多費些筆墨；如果要信息透明度，那應該著重寫數據可視化、統計分析；如果要操作方便，按互聯網公司的流行做法，那應該是給個原型或視頻，而不是給文檔。文字不能簡單地誇自己的產品或服務有多好，多棒，多與眾不同，盡量避免使用副詞、形容詞，盡量列舉出可量化的指標。就像寫簡歷一樣，泛泛地說自己“精通”“擅長”，不如拿出具體的項目成果、獎項、github賬號。

所以，下筆前，要想想自己這篇文檔的投資回報，再寫寫讀者想要的投資回報。

需求分析文檔為什麽很難寫？（續）