作为程序员，需求分析真的很重要

我是一枚普通院校毕业的大专生,从毕业算起,今年是做码农的第四个年头.我相信一起出来的很多人已经走到了经理,或者更高的位置.我的四年很普通,依然还在开发一线.所幸,我经历的公司,加班不多.不过并不会让我闲着,一个需求昨晚了,还有另一个,甚至一个人当几个人用,经常熬夜至深夜2、3点也是常有的事.很多时候,为了应付上面交代的任务,需求也没怎么消化,直接开干,也是因此写了无数bug,付出了本该与家人相伴的时间作为代价.我也试图走出困境,去阅读过源码、花好几千买教程学习,希望写出一行漂亮的代码,做出一个好的技术方案.但事与愿违,常常因为看不懂的英文文档,陌生的技术概念,经常学到一半就放弃了.不过今年运气似乎运气比较好,有了一些不一样的变化.

到问题的尽头去看看

学会透过表象看本质,去了解一门技术的背景.去了解它解决的需求.这似乎是从小就在接受的教育.一个比较熟悉的场景就是数学课上,老师带领我们推导数学公式.扪心自问我没有推导过一次,就算推导也是死记硬背,我只记住了公式,只记住了某个场景的问题,有对应的公式去套用,只是为了考个试,得到高分.回想起来,这好像是导致我以前做压轴题失败根源.而现在套用别人框架完成业务也好像是去拿公式套数学题.我压根没有去看业务需求,下面分享一个我所经历的一个真实反面案例:

2020年,我跳槽加入了C公司,该公司主要提供机电设备运行咨询／管理服务,我承担后端系统的维护与新功能迭代.其中一个任务派单的功能.老板要求每次去客户那边做设备运维时,要填写任务单,维修记录、签到打卡,并且要有统计的功能,能看到每个人完成单据数量,工作时长等;有审批功能,审批完后才认为任务单据是有效的.当时任务下来,也没多想,那简单啊,不就是任务增删改,简单的审批改个状态.没想到啊,这个几个功能断断续续的修改了一年多,用的人不满意,老板也被搞得不满意.工作人员常常说,这个月有单据,为什么统计看板中没有,好家伙一看他们的任务时几个月前派的,而统计的地方恰恰又是以任务创建时间作为统计依据,这能看到才怪了.

从上面这个案例看,我只顾着功能的本身实现,从来没有实际上运行的情况,也没有真正和老板沟通过他的需求.导致开发出来的东西,不是他想要的.

我为什么认为有了一些不一样的变化

总的来说,要多去挖掘需求方的深层次需求,而不是直接消化结论.就像福特汽车创始人亨利福特说过的：

如果我最初是问消费者他们想要什么，他们应该是会告诉我，“要一辆更快的马车！”这里“要一辆更快的马车”就是一个典型的用户需求，

但这并非是用户的真实需求，用户的真实需求，需要通过分析才能得到。明白这句话我还得感谢这些人:

左耳朵耗子-陈皓: 一个开发大佬,在他的博客专栏中,很多文章都指出技术的源头,并也要求去技术的发源地学习.

我的技术总监: 去年开始,要求我们做功能开发前,需要编写技术设计文档,审核通过后方能进行代码开发.这里列举下我比较中意的地方,文档中的几个问题:

• 目标场景:应该如何使用这个系统和功能,这个功能解决了什么需求.
• 系统设计:系统设计应该涵盖具体的重要设计决定和折中方案。声明每个方案的优缺点，阐述建议方案的原因。如果需要，系统设计应包含功能框架图，流程图等图文表格。

办公室的同事: 在闲聊时,总会给我说每件事后面的背景,影响.例如:前段时间英国女王去世问题.说起这个话题时,我也附和我也知道啊,昨天不在的.我就知道这个事情发了,而他给我分析了这个事情会带来怎样的经济影响.