从开拓的角度去分化项目需求

项目首先得理解需求，如果不理解需求，谈不上分解了，我不相信不理解需求的人能做好项目分解的事情，但现实生活中就有而且还不少这样的同行，在不理解业务需求的情形下就说大略、几条SQL语句搞定，这是极其不卖力的表现。
理解业务后，我们一样平常会从横向、纵向分解需求，横向拆分是指拆分业务功能，纵向拆分是指业务功能落地生命周期的拆分，这也是我在事情中利用的分解方法。

横向指的是项目的功能，比如，我们常见的OA系统紧张有考勤、员工管理、薪资管理、绩效管理等等，WMS系统则紧张有仓库管理、商品管理、供应商管理、入库管理、出库管理、PDA、RF等等，是不是这些功能，我们都分解成一个个独立的功能单元进行开拓呢，其实在现实项目中并不是这样，还要看各个业务功能的耦合度，如果耦合度比较高，则建议合并成一个功能点，这样更随意马虎管理及业务实现，这也是DDD（领域驱动设计）所提倡的，各个业务需求的边界是非常主要的，如果落地前没有梳理清楚，后期实现是非常棘手，乃至可能直接导致项目的失落败。

纵向指的业务落地的生命周期，单个功能的需求剖析清楚明了是紧张任务，然后便是根据需求设计业务模型、数据模型、技能实现模型，及采取哪种办法、哪种措辞来实现，还有为了担保业务的正常运行，需不须要考虑高可用、高并发，及如何办理，末了针对一个单元任务形成一个整体的方案。

项目的业务需求分解是一个繁芜的过程，既要对业务需求熟习，也要有技能沉淀，缺一不可，最主要的还是要在实际的项目中多实践。
如果有什么问题，可以加我微信，多多互换，共同进步。