做这行久了，你会发现很多项目死就死在开头。不是代码写不出来，是根本不知道要写啥。
很多人觉得需求分析就是跟客户聊聊天，拿个本子记下来，完事。大错特错。
系统开发的需求分析阶段的重要工作之一是挖掘那些客户自己都说不清楚的东西。
上周接了个单子，客户是个做生鲜电商的老板。他说要个APP，能下单，能配送，能积分。听着挺简单对吧？
我问他，你们现在的痛点是啥？他说，配送慢，客户投诉多。
我就没急着画原型。我先去他们仓库转了一圈。
结果发现，他们的问题根本不是软件能解决的。是仓库里货位乱得像垃圾堆，拣货员靠脑子记位置，经常拿错。
这时候如果直接开发APP，那就是在垃圾堆上盖高楼，看着光鲜，一脚踩空就塌。
所以，系统开发的需求分析阶段的重要工作之一是业务流程的重塑。
你得敢于告诉客户，你的流程有问题。
那天我跟老板说，哥，你这APP先别急着做。先把仓库理清楚，把条码系统上了。不然你接再多单，也是亏本赚吆喝。
老板脸都绿了，觉得我是不是想坑他钱，不想干活。
我给他算了笔账。他说每天大概500单，每单因为拣货错误导致的退款和重新配送成本是15块。一个月就是2万多。
如果上了条码管理，虽然前期投入大点，但半年就能回本。
最后他听了我的。虽然APP晚做了两个月，但上线后，因为后端稳，前端体验才好。
这就是真实案例。没有那么多高大上的理论，就是算账，就是看现场。
再说说那个“不装”的态度。
很多同行喜欢堆砌术语。什么敏捷开发，什么用户画像，什么痛点洞察。
其实说白了，就是搞清楚谁在用，在什么环境下用，想解决什么麻烦。
我有个朋友，做企业OA系统的。客户需求是“提升协作效率”。
这词太虚了。
我让他去问销售部门，你们平时沟通最烦啥？
销售说，找老板签字要半天，老板不在就卡住。
这就不叫需求了，这叫业务瓶颈。
所以，系统开发的需求分析阶段的重要工作之一是界定边界。
你要知道什么不做，比知道做什么更重要。
有个客户想要个功能，能自动识别客户情绪，然后自动调整报价。
我说，这玩意儿现在技术不成熟，而且容易出错。一旦识别错了，把愤怒的客户当成开心客户，报价低了，亏的是你。
他愣了下，说也是。
后来我们砍掉了这个功能，做了个简单的客服快捷回复模板。
效果反而更好。
有时候，克制比放纵更需要功力。
别总想着炫技。客户要的是解决问题，不是看你的代码有多牛。
还有个小细节，大家容易忽略。
需求文档别写得太长。没人爱看几十页的Word。
最好是用图，用流程图，用原型图。
哪怕画得丑点，只要逻辑通顺，比文字管用。
我见过太多项目，因为需求文档写得模棱两可，开发做出来不是客户想要的，然后反复改，改到最后双方都崩溃。
这时候，系统开发的需求分析阶段的重要工作之一是确认共识。
每个关键点，都要让客户签字确认。
别怕麻烦。现在的麻烦，是为了以后的不麻烦。
当然，我也不是完美的。
我也犯过错。有一次没注意细节，把“月度报表”理解成了“每日报表”。
结果开发出来，数据量太大，服务器直接崩了。
虽然最后修好了，但客户信任度掉了一截。
所以，细心点吧。真的。
别总想着走捷径。
如果你正在纠结要不要开始做系统，或者已经做了但一团乱麻。
不妨停下来，重新梳理一下你的业务流。
别急着找外包，先理清自己。
如果有拿不准的，或者需要人帮你把把关，看看你的需求是不是真的靠谱。
可以来聊聊。
我不保证能帮你省下一半的钱，但我能保证，不会让你走那些我走过的弯路。
毕竟，这行混久了，靠的不是嘴皮子，是实打实解决过的问题。
咱们见面聊，喝杯茶，看看你的流程图。
有时候，一眼就能看出问题在哪。
别自己瞎琢磨了，容易钻牛角尖。
