Get best of the week

IT业务分析师和系统分析师。整理成绩

问题


我的一些朋友，同事，经理，eycharov，脑海中的“企业”代表在分析师类型之间造成了混乱。“分析师”的概念适用于完全不同的职业-业务分析师（BA），系统分析师（SA），数据分析师，UX用户，信息安全分析师，业务流程分析师以及其他5-10位这些物种有很多差异。现在介绍这两个具体问题，这两个问题最困惑，但在国内IT现实中却大不相同。



谁将从本文中受益：
至怎么样
分析师和同事分析师-自我识别，以便根据兴趣和对未来的看法正确分配培训和发展，求职方面的努力。同事-了解什么是直接职责，什么是分析师的不寻常负担。

示例：要求BA提供服务的xml方案的描述，而CA需要对业务领域的监管文档有一定的了解。
人力资源在招聘的第一阶段和后续阶段更容易筛选候选人，并获得更相关的答复，以正确描述职位空缺。在“应有的位置”提高员工的工作满意度。

示例：具有Java知识的BA空缺，在CA上悬挂了大量的演示和销售。
到头针对准备好执行特定工作职责组合的资源进行选择和分配，改善团队之间的沟通。 

示例：对于需要最大程度的沟通和灵活性的职位，选择了“技术人员”而不希望发展这种技能。

总的来说，“所有人的幸福，一无所有”

假设条件


本文讨论有关IT的更多信息。

考虑职位的“提炼”价值。在现实生活中，尤其是在开发T型技能的团队（相关行业员工的能力发展模型）中，这种情况更加复杂且令人困惑，但是如果您的分析师不是多面的Janus，那么在不同职责之间进行转换就不是一件容易的事。

主要部分


与来自各种规模的公司和项目的BA和CA进行交流时，我看到了引起争议的概念不一致。通常情况下，缺乏公认的术语会干扰那些能够以最高效率完成任务的人在项目中的任务和责任分配。为了求助于这些争端的客观来源，我决定在网上寻求意见。

我分享搜索结果。

IT中的业务分析和系统分析是一组实践，方法和任务，可简化解决组织业务目标所需的信息系统的开发。这两个概念之间的混淆不仅存在于家庭环境中，因此：

https : //en.wikipedia.org/wiki/Systems_analyst：

系统分析师通常限于分配或给定的系统，通常将与业务分析师一起工作。这些角色虽然有些重叠，但并不相同。

作为可以在SA与BA之间建立“分界线”的资源，我尝试使用BA知识代码，普遍接受的专业文献，法规文件和有关各种资源的文章。我找不到明确表达的区分。这就是为什么：

  • , , — , . « », ( ), . 
  • ( / . ., BABOK, ., PMI Guide to business analysis . .), . , - -, . , . . -, « , , , , . , , , , - ». . PMI IIBA «system analyst» , «business analyst» .
  • ( ) , . , — . — , , , . — , , , , , .

在这种情况下，我根据客户和承包商在信息系统开发方面在俄罗斯IT公司工作的经验，提出我的愿景。这种方法为作者Alan Vongsavanh 的工作提供了帮助，该人研究了文献资料和几次采访的结果，并收集了构成BA和CA日常活动的主要部分（大部分工作时间）的基本技能列表：


*外国来源使用更恰当的术语“以技术为中心”和“以业务为中心”。

哪里：
确定需求通过面试，研讨会，任务分析，工作流和文档以及其他方法从各种来源确定需求的过程
商业知识, , -
.
-
 ,
 
,
( )
技术知识，数据库编程，创建和配置以及设计解决方案的其他技术方面，标准和规则

通过这些操作，您可以形成一个完整的需求分析循环，将其从客户带到开发人员，然后将最终产品从开发团队带到客户。这种交互很容易落在框架上，例如，这就是在V模型，瀑布模型或灵活方法中的样子：





为什么如此分离


BA和CA所需的技能在顶级方面相似，但细节之处在于魔鬼。系统分析员需要更实际的技术技能来从事全面的活动，他与一组技术专家之间的距离要近得多，并且应该更好地理解他们的语言（如果没有这个，很难在团队中赢得尊重，这意味着您无法传达您的愿景）。 IT中的BA更加配置为与业务进行通信，它的任务是确定需求（痛苦），找到，制定和提出使用IT系统解决业务客户问题的解决方案，以某种方式“出售”该解决方案。与用户的亲近和理解有助于BA更加有效地确定任务的优先级，描述特定情况下的非功能性需求和限制。

而且，BA对系统有内在的过度需求，它以业务目标为出发点，不应受到CA所不能接受的技术能力的限制。有时，此类过多的BA要求有助于找到真正的突破性解决方案。

但是有局限性。对于BA，这是一个领域或研究行业的范围（例如：对银行业规则的深入了解），对于BA，这是一种技术和系统（例如：在Oracle产品方面的出色经验）。这些限制可能会成为团队，项目和公司之间过渡的障碍，但如果需要并在同事的帮助下可以很快消除。

几乎总是，团队中的分析师或多或少地扮演着这两个角色（因此，我想避免关于合并“并且我们还有病毒学士学位”的争议）。在某些情况下，可能不需要分析师；在某些情况下，一位专家可以完全扮演这两个角色。这并不违反规则，而是表明角色，成熟程度和特定专家的价值的组合。对于经验丰富的员工来说，这是很正常的，但是在知名站点上具有SQL，JS和API知识的初级BA职位空缺看起来很奇怪。

https://zh.wikipedia.org/wiki/Systems_analyst：

一些敬业的专业人员在这两个领域（业务和系统分析）都具有实践知识，并且设法成功地将这两个职业结合在一起，从而有效地模糊了业务分析师和系统分析师之间的界限。

抽象示例：


伊万-BA公司“承包商”。
Eva是Executor的系统分析师。
公司“客户”需要对现有系统进行重大修订。 

在这种情况下，Ivan（BA）的任务是：确定客户和承包商的功能和非功能要求，消除相关方之间的矛盾，以确定可接受的解决方案，创建原型，在开发过程中与客户进行交互，进行演示展示并接受工作。与夏娃一起做这一切。

Eve的任务（CA）：以最佳方式设计修订版，描述其对系统的影响，局限性和可能的​​改进，创建规范，分解任务并将其转移到开发中，并根据要求监视其及时实施。与Ivan一起完成所有这些工作。

代替输出


随着时间的流逝，随着时间的流逝，业务问题及其IT解决方案的复杂性呈指数级增长。随之而来的是，技术栈正在广度和深度上进行密集而广泛的发展。选择正确的技术组合可以提供突破性的竞争优势，但也可能具有破坏性，通常是在未来几年做出选择，使开发人员处于狭窄的框架内。 

当前的情况要求IT分析师（1）对业务的主题领域，内部流程的特征，外部环境和趋势有深入的了解，（2）对技术的了解程度不低，通常是其实际使用情况。

您可以成为理想主义者，寻找天才，并要求他对各种（即使不是极地）知识领域有很高的了解。您可以脚踏实地地了解，这种双重职责很可能导致双向失败。坐在两把椅子上不是一个好习惯。 

如果项目的复杂性需要BA和CA，则首先需要形成一个概念，确定专家需要什么级别的业务知识和技术功能，并将其转化为已发布的空缺，面试和测试策略。人们一直希望“一种尺寸能适合所有人”，但我们生活在现实生活中，在现实生活中，它更有可能使搜索复杂化，并增加吸引“多功能工具”的价格。

对于已经发现自己或打算在BA或CA工作的同事，我建议您执行相同的步骤，并诚实地自己了解自己是否想要（1）在经常违抗算法和逻辑的情况下寻找真理的种子，不断改变业务，或（2）研究和设计复杂的产品令人困惑但有趣的系统。这将有助于缩短到达所选峰的路径，并减少在追求“美丽位置”时不适当的不适感。 

附录



好吧，格拉夫雷德（Glavred），现在更清楚了吗？=）

More articles:


All Articles