一个软件项目开始前,真正应该准备的不是需求文档一个软件项目开始前，真正该准备的，不是需求文档
找到了就开始写需求文档。功能列一堆，流程图画一堆，能写的全写上。然后开发公司报价，几万到几十万不等。公司选一家觉得合适的，签合同，开工。但这里头有个问题——需求文档写得再细，方向要是本来就有问题，那后面所有东西都是照着错的在走。做了几年产品设计，我发现好多公司把力气花在了写文档上，却没花时间想清楚一件事：这个软件做出来，到底要解决什么。第一件，把业务目标定实了。
先别急着写需求，坐下来把一件事聊透：这东西做出来，希望业务上有什么变化。是销售多签单，还是客服少接电话，还是用户下单更快。目标越具体越好。比如销售多签单——多多少算多，多20%需要软件帮什么忙。没这个数，后面所有判断都是飘的。第二件，把用户场景理清楚。
好多公司说“用户需要”，其实是他自己觉得需要。真正用的人根本不打开。比如内部管理工具，普通员工一天忙到晚，还有空登录系统填表吗。要是没有，这需求打一开始就不成立。第三件，把核心功能圈定住。
前面两件事想清楚，功能列表是自己长出来的，不需要硬凑。销售要多签单，那软件到底给他什么——客户信息更好查，还是合同生成更快。用不上的功能堆上去反而拖慢他。核心功能定下来，别的先放一边。把最有用的那几件做好，比凑一堆功能强得多。第四件，然后再去找开发。
这时候开发公司问你，你能说清楚的不是功能列表，是你想解决什么问题、替谁解决、解决到什么份上。好的开发团队，这时候给你的建议才值钱。先定目标，再理场景，再圈功能。这三件事做踏实了，需求文档是顺带出来的，开发反而快得多。准备做软件的公司，要是还在埋头写需求文档，不妨先停下来，问自己那个最要紧的问题：这东西做出来，到底解决什么。评论区可以聊聊——做软件项目的时候，有没有“方向跑偏了，全白干”的经历。
我是小晨儿，前互联网产品设计团队负责人，现独立产品设计顾问。专注App/小程序/数据大屏的产品设计与全链路复盘。
这里会持续记录我对产品设计的观察与思考。
如果你有产品想要落地，或正在纠结某个设计方向，欢迎来聊聊。
夜雨聆风