需求最需要关注的是四个因素: 人, 数据 / 信息, 流程, 规则 / 约束. 今天先说说人.
写文档时最先考虑的应该是谁?
教科书里总说, stakeholders, 利益相关方, 这里有很多人, 可能是甲方公司里的所有人. 如果需求方前期给的信息足够详细, 动笔的时候应该能够列出核心的几个利益相关方, 每个利益相关方的业务流程如何, 甚至部分业务规则和相关的约束. 有些业务流程非常复杂, 细节很多, 图文混合洋洋洒洒可以写上好几页, 这些东西要不要都写上去? 考虑到需求分析文档通常是项目方拿下项目的第一步, 要注意, 很有可能项目还不确定是自己的, 做不做还不一定呢. 通常这种文档的期限都比较短, 一两天之内就要交差, 如果提前已经有成型的段落图片积累还好, 可如果完全从头开始, 怎么才能用相对短的时间交一个还算像样的答卷? 这时候在那么多的利益相关者当中更应该考虑谁的感受?
如果有人想找我做一个项目, 简要叙述一下需要我做的功能, 我首先关注的是, 这个项目我能不能接, 也就是根据对方提出的功能列表判断我现在有没有这些功能, 没有的话实现难度如何, 时间如何, 划不划算. 按着这个思路写下去, 那写文档的投入产出比可能不高. 甲方看这篇文档看的是, 我 (甲方的 "我") 希望通过这个项目获得什么, 这就有点像写 BP, 不是单纯写技术多牛, 业务水平多高, 而是让投资人从这里面看到投资回报. 因此, 如果对方想要流程优化, 那就应该写出新旧流程对比, 旧流程不足在哪里, 新流程如何改进; 如果要维护便利或安全性, 那就得在非功能需求方面多费些笔墨; 如果要信息透明度, 那应该着重写数据可视化, 统计分析; 如果要操作方便, 按互联网公司的流行做法, 那应该是给个原型或视频, 而不是给文档. 文字不能简单地夸自己的产品或服务有多好, 多棒, 多与众不同, 尽量避免使用副词, 形容词, 尽量列举出可量化的指标. 就像写简历一样, 泛泛地说自己 "精通"" 擅长 ", 不如拿出具体的项目成果, 奖项, GitHub 账号.
所以, 下笔前, 要想想自己这篇文档的投资回报, 再写写读者想要的投资回报.
来源: http://www.bubuko.com/infodetail-2963611.html