今天这篇文章为杂谈，重点还是整理下我最近几周对于软件需求和业务顾问类人员培养的一些关键点思考。如果你需求或业务顾问类人员希望对你有帮助。
为啥要写这篇文章？
初衷仍然是在当前业务系统的开发和交付中，一个好的软件需求人员往往至关重要。这类人员不仅能够做好产品化的业务建模和需求抽象，同时也能够做好业务用户和软件开发之间的关键衔接。
但是实际情况却是如果你要真正成为一个熟悉某一个专业业务领域的需求人员或业务顾问并不容易。有些人对业务可能很熟，但是没有技术背景对软件工程和研发支撑等内容并不了解，因此难以做好用户和开发之间的衔接，本身也难以做好抽象的业务建模；还有一类人员可能是偏技术出身，但是技术思维思维严重，不能从业务和用户视角来看问题。
真正能够把两方面都做好的需求人员少之又少。
做需求最基础的前导知识是什么？
要做好软件需求分析和需求开发，最基本的前导知识个人认为包括了业务和技术两个方面的内容。
在业务方面即是围绕企业核心业务价值链的大框架的业务理解，从产品研发到生产，物流，市场营销，售后服务，财务和人力资源等组织支撑能力等。对企业这种端到端业务必须有粗粒度的框架性的了解，你可以理解为泛读，重点是形成脉络框架。
其次才是对你从事的业务域的关键业务知识的详细学习，如果你做供应链类系统，有专门的供应链管理类书籍可以阅读，包括基于Scor模型进行对比参考。如果做产品研发，有IPD和HPPD完整的方法论可以参考；每一个业务域你都能够找到对应的专业书籍进行学习。
那么这种学习的重点是什么呢？
简单来讲仍然是核心业务流程，业务流程分解后形成的业务活动，业务活动间的交付集成，业务活动输入输出的业务对象和单据信息。所以你会看到业务流程管理，流程分析方法仍然是最基础的支撑分析工具。
在技术方面重点简单来讲核心是软件工程和数据库。软件工程学习仍然是偏粗粒度地学习，这个需要覆盖IT基础设施和资源层，中间件，应用常用分层模型，同时基于软件生命周期，V模型等清楚地了解一个业务系统，一个软件应用是如何从无到有的，软件开发中涉及到的需求，设计，开发，测试等各个关键角色活动，是如何沟通协同的。
还有一点就是数据库，为什么数据库很重要。任何业务的学习实际都包括了业务流程和业务对象，理解业务对象模型实际对理解核心业务起到很重要的作用。任何一个业务功能的实现你会看到软件功能界面，操作对应的是我们分析完成的业务流程，而操作完成的结果形成的业务对象单据，对应的是数据库。当你理解清楚数据库，数据表对象关系后，你更加容易理解业务，理解业务和技术实现之间如何映射。
需求人员如何培养和指导？
如果我们新招聘一个做需求的新员工，有可能是原来没有做过需求工作，也可能是没有做过当前业务领域的需求工作。有可能有技术背景，也可能完全没有技术背景。
不论是哪种情况。
你首先要去补足的就是前面谈到的业务和技术前导知识，这些知识如果有欠缺就要去快速地补充，以完整自己的概念模型。
但是这些前导知识不足和需求人员本身的实践是并行在一起的，一定不能是全是理论学习，再实践，而是应该快速迭代，一开始不求甚解，先在粗粒度层面需求和业务，然后才考虑如何逐步深入去学习。
因此需求人员进来后，比如你本身做采购管理系统，那么新招聘人员进来后最简单的就是先把系统本身对于的业务，系统主要功能做一个讲解。在这个完成后，就需要安排新员工去熟悉系统，熟悉系统所有的功能。熟悉到什么程度，熟悉到基本能够做UAT测试的程度。如果达不到这个程度，那么对整个系统不算完全熟悉。
在整个业务系统熟悉的过程中。
在这个步骤你重点就是去多使用系统，把每个功能都用熟悉。
第二步是基于你了解的业务流程，来串联当前系统的多个业务功能。你系统里面的招投标，采购请购，采购订单，采购接收等多个功能究竟是什么关系，他们之间是如何完成上下游衔接的。比如你首先要经过招投标管理，供应商认证，物料认证，才能够形成可用的供应商，物料基础信息。其次在创建采购订单前必须要进行采购请购，采购请购通过了才能够创建采购订单，再次采购接收或入库操作一般也需要首先有生效执行的采购订单才行。
上面说了这么多。
希望你理解的就是采购完整的流程你理解清楚后，分解处理的业务关键活动，实际就对应着系统里的多个业务功能。你基于完整流程视角你才能够想清楚这些业务功能是如何衔接的。这步完成后点上的。
第三步是数据模型和数据库，完成业务到技术实现的关键衔接。实际在第二步已经完成了业务流程和业务功能之间的衔接，即一个完整的业务流程对应到系统里面哪些业务功能。而第三步重点则是去了解清楚底层的数据结构，以及数据库。一个业务对象变成了数据对象，而数据对象最终又转变为数据库表持久化存储。
任何一个业务功能，在你完成了黑盒层面的理解后，都需要去了解支撑该功能的底层数据模型是如何的，对应到后台哪些数据库。一个业务操作发生后究竟会影响到哪些数据库表数据发生变化。数据库表和表之间什么样的关联依赖和约束关系等。
到了这里基本就完成了业务到技术层面的关键映射。
第四步即规则逻辑，任何一个业务功能都不是简单的数据库表的CRUD操作，更多的是业务规则和逻辑的实现。实际上到了这里你想通过系统的前端功能使用和操作，去了解清楚全部的业务规则逻辑绝对不可能。
因此你还是需要详细的需求文档配合来对关键的规则逻辑进行学习。
如果你接手一个业务系统，这个业务系统本身没有形成详细的需求文档，那么需求人员很难去全面的了解清楚业务规则逻辑。没有了解清楚业务规则逻辑那么对业务系统也没法做到完全层面的了解。如果你是一个软件开发人员，可能还稍微好点，当你不清楚具体的规则的时候，你可以详细去看源代码，去分析源代码逆向具体的规则逻辑。而需求人员没有想过的前期文档说明，那么简直就是灾难。
软件需求和业务顾问有无差异？
对于企业软件团队里面的软件需求开发和分析人员，和我们常说的IT咨询公司里面的业务顾问有无差异？这个谈下自己的看法。
业务顾问本质仍然是围绕企业业务层面的问题和诉求给出详细的业务解决方案，注意是业务解决方案，业务解决方案的关注点更多是业务组织角色职责划分，业务流程和业务活动，业务边界，业务规则，管控治理规则等方面的内容。
通过业务解决方案更多的是解决当前业务中存在的问题，这些问题包括了流程断点，数据不一致性，信息不及时，底层数据间缺少映射导致无法建立勾稽关系，业务流程和数据无法支撑业务运作或业务决策等。
所以你看到业务顾问本身仍然是对企业核心业务价值链熟悉+流程管理方法论，当然这些完全不足够，业务顾问出业务解决方案本身就是一个问题分析和解决的过程，更加强调从需求调研开始，到差距分析，到方案提出，到验证的完整方法论。在这个方法论里面本身又有大量前人积累下来的分析方法和讨论，比如常说的各种矩阵分析，差距分析，SWOT分析，麦肯锡问题分析七步法，平衡计分卡和KSF关键成功要素等。
简单总结就是业务顾问的解决方案往往会更加抽象会站在单个业务系统的上层，重点是跨系统的一些关键业务方案，跨组织的流程和数据打通。业务顾问关注全局整体需求分析，这个需求分析类似于我们在EA企业架构里面谈到的业务流程建模，业务架构和数据架构分析等内容。而软件需求分析人员一般是单个业务系统里面的需求分析，核心要解决的本系统究竟需要做哪些新增或改进优化才能够满足用户需求。
软件需求人员在宏观层面建模，全局业务理解上可能弱于业务顾问，但是对于具体需求的实现，业务建模能力则更强。也就是说软件需求完成的内容，最终是要交付给开发人员去实现和落地的，你必须要描述和定义清楚，做到完全可实现。业务顾问输出的可能仅仅是业务方案和业务需求，而软件需求人员则一定是到软件需求层面。
对于很多业务顾问你可以看到，业务能力很强，但是技术背景弱，重点就是缺类似大型项目本身的IT建设，软件工程等背景知识，这导致业务顾问在出业务方案的时候往往跟技术实现脱节并将业务方案理想化。
即使在各大IT咨询公司，你可以看到，真正厉害的一定是业务+技术都兼顾的资深咨询顾问，既能够把业务说清楚，给出业务方案，又能够谈关键的技术架构，让最终方案具备可落地实施性。同时兼顾这两个方面的人少之又少。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！