如何做需求分析，关键信息提取，关键业务抽象

作为一个技术人，肯定不满足于整日的CURD，也幻想这有朝一日能指点江山，挥斥方遒；拿下CTO，迎娶白富美，走上人生巅峰。

软件开发最重要的就是需求分析，需求分析的好与坏直接决定了你最终产品的方向是否跑偏，也就决定了你写的代码是否有实际意义；很多程序员专注于专研“高大上”的技术，三句两句不离高并发、大数据、高可用，而实际做出来的产品除了自己可能100个用户都不到；所以要清楚，技术是为业务服务的，技术也是随着业务的迭代而迭代，杀鸡的时候就用菜刀，直接用铡刀不是不可以，是得不偿失。

写代码之前明白要做什么，这是非常关键的，专业术语叫需求分析。只有在充分理解需求的情况下，你才能在此基础上开始你的表演，不懂需求分析的程序员、或者等别人分析好了让你来CURD的程序员是码农，是码畜，连去外包都不配。

本文以趣任务的实际研发过程，需求分析经历为例，剖析一下如何做需求分析。

那是一个骄阳似火的夏天，我们团队接到一项任务，开发一个任务管理系统，用以支持公司日常事务的在线管理，大致要求：将公司的日常工作录入系统，用系统的方式来分配任务，记录分配结果，并进行在线考核，并在月底统计当月考核结果。

关键信息提取

录入、管理、分配、考核、统计。

进一步分析

先到公司的各个部门走访，采集信息得知，公司的事务十分庞杂，光岗位就有美工、运营、行政、财务、研发、产品、仓库、客服、采购、总经办等十多个，人数数以百计，事务少说也有几百件之多。

在采集了不少信息之后，我们开始分析，虽然事务千头万绪，但我们从事务做的频率来划分，但不外乎以下几种：

每天都需要做的事务，归类为日任务

这类任务的主要特点就是每天都需要安排人去做，而且人员是相对固定的。

一周做一次或几次的事务，归类为周任务

这类任务一般一周做一次，类似周报之类的，或者一周做两次，比如物料采购之类的工作，人员也是固定的。

一个月做一次或几次的事务，归类为月任务

这类任务就是一个月才需要去做一次或者一两次，类似月末盘点，人员相对固定

临时产生的事务，归类为临时任务

此类工作具有随机性，可能是突然来了一件事情，需要一个有空闲的人去做一下，比如新进物料拖运等等，这类事情没有规律，人员也不固定。

有了这个分类之后，就可以开始着手推演了，发动公司所有管理层，大到总经理小到业务组长，梳理自己部门下的工作，按照上面几个分类来进行，工作归为什么类型，然后指定那些人来做，一周时间，基本搞定，很顺利，但在客服部遇到了麻烦

特殊处理

客服部门的工作比较特殊，客服接待这件事情是每天都需要做的，按照上面的规则应该归为日任务，但麻烦的事情在于，人员的不固定，也就是一三五可能是张三接待，二四六又是李四接待，因为掺杂了一个晚班倒班制度，导致人员飘忽不定，之前这个工作安排都是通过客服主管提前两三天手动排班，然后通告大家的，现在用上面的模型搞不定，咋整？难道因为这个客服部的工作就不能上系统了？

经过反复研究，我们创造性的发明了“互动任务”这个概念，即将这类人员不确定的工作梳理出来，事先不指定执行人，只有谁做了这件事情，谁才去“认领”这个任务，如此一来就解决了。

最终经过推演，日任务、周任务、月任务再加上互动任务，已经可以满足所有场景下的事情安排需求，至此任务分类需求提取完成。

下一篇分析任务分配逻辑。