分析员是最自由和多方面解释的职业之一，这已不是什么秘密。 而且，尽管存在多达两个专业标准，但每个公司都会分别概述分配给担任该职位的专家的任务范围。 在我的文章中，我想分享我的个人经验，并告诉您分析师在普通项目中可以扮演哪些角色，完成哪些任务以及如果主要项目的使用变得完全无聊，又应从何发展。
我希望我的故事能够帮助您惊奇地发现兄弟的想法，并突出您的成长和发展点。
免责声明
将会进一步讨论的是在非常特定类型的活动中的纯个人经验，包括基于具有自己平台和编程语言的特定系统开发和实现自定义解决方案。
此外，此活动还受到所实施系统的细节以及用作本地标准的内部供应商技术的限制。
嗯，作为蛋糕上的樱桃-这项活动是为血腥企业的利益而进行的。 当我谈论血腥的企业时，我指的是非常大的公司中的项目-几乎所有石油和天然气，大型银行，工业家，零售等。
因此，将在本文中讨论的分析人员是整个上述范式中的一个人。 而且，这是一个非常真实而活泼的人，无论他在阅读过程中在真空中看上去像一匹球形的马。
前戏
总的来说，分析师在太空中的自决权是一个颇具爆炸性的话题。 每当在专业社区，论坛，会议，会议或电报聊天室中提出“这些被诅咒的分析师到底是谁”的问题时，都会激起激烈的嘲讽，在此期间，一些分析师向其他分析师证明，每个人应该和不应该做。
当各种各样的眼神或方法学家开始讨论这个话题时，它甚至变得更有趣（或更悲伤）。
在所有这些工具中，我更喜欢采取一种立场，其实质在于一个词-特异性。 换句话说，每个人都需要了解，分析师的职能和任务集将始终根据最终雇主，项目和团队而有很大差异。
也许您在想-为什么我突然决定我可以谈论它？ 一切都很简单。 列出我在整个项目中更改的角色就足够了：
- 业务分析师；
- 系统分析师；
- UI / UX设计器；
- 技术作家；
- 测试员
- 老师
- 支持。
如果我们要讨论的项目越来越复杂且规模越来越大，那么由几个分析师组成的团队（其中可能会有初学者）将添加其他角色：
在所有这些角色中，我已经工作了将近八年。
市场
但是，让我们从远处开始。 确切地说，随着当前市场上发展的情况。
例如，如果您去找猎头公司并将“分析师”一词带入搜索行，那么关于该主题的所有幻想和解释都将落在我们身上。
当然，普通分析师是最常见的。 没有任何澄清，远离罪恶。 在这些职位空缺的说明中，您可以看到许多不同的有趣功能，任务，工作职责和对候选人的要求。
一些雇主敢于在职位空缺中对业务和系统分析师进行分类，从而实际上为自己挖了一个坑。 他们甚至都无法想象在这场血腥的战斗中有多少分析师被杀死。
精简且功能强大的IT分析师类别非常受欢迎。 通常，在他们的描述中，整个俄罗斯实验领域都有责任，实际上仅限于IT领域。 这些空缺最让我想起了有关tyzhprogrammers的故事，这些故事经常被要求修理真空吸尘器或水壶。
坦白地说，那些至少试图在标题中指出需要“分析”的内容的人正在行动。 因此，“ SQL分析师”，“业务流程分析师”，“需求分析师”，“ 1C分析师”，“销售分析师”，“市场营销分析师”等类型的职位空缺完全不同。 但是，即使有两个相同名称的空缺，这也无法避免任务的差异。
标准品
看来这个故事的重点应该是由专业标准设定的，专业标准的任务是确定特定专业活动的目标，并详尽描述专家的劳动职能，在其实施框架内执行的动作以及所需的知识。和技能。
但事实确实如此。
当然，您需要为标准仍然存在感到高兴，尽管它们是最近才出现的。 秋季系统分析师的标准将是5年。 后来，业务分析的标准得到了加强-他甚至不到一岁。
有趣的是，这些标准已经在专业区域代码级别上声明了企业与系统分析师之间的区别：对于系统分析师，指示代码06，对于业务分析师-08。换句话说，系统分析师被归类为“通信，信息和通信”领域的专业人员“金融和经济学”领域的“技术”和业务分析师。 没有适合您的IT。
如果我们朝着标准所规定的专业活动目标前进，差异将变得更加明显和有趣。 系统分析师（因为他被称为IT领域的专家）被负责以明确的良心处理需求，提到软件，自动化系统，一般来说，是我们喜欢的一切。 反过来，业务分析师不是根据需求工作，而是根据需求工作，但他的目标是着眼于有益于组织的变革。 而且，请注意，不要一味谈论系统或硬件和软件系统。
同时，参与创建各种软件产品的众多人员的工作簿中都有一个简单的“业务分析师”条目。 但是，为什么走得更远，无论我叫谁，我本人都担任了八年，履行着同样的职责。 因此，为了不涉及术语争端，在进一步的叙述中，我将使用最通用和中性的“分析师”一词。
任务
让我们继续具体。
我们的分析师以某种方式参与其中的任何项目都需要执行4个全球任务，我们将其称为预售，预项目，项目和实施。 当然，分析人员可能不会参与所有任务，而是与其中的任何一个单独连接，但是由于我们正在切换到超级英雄模式，因此让我们详细讨论一下每个任务。 我会立即预订；我故意取消了护送的任务，因为 我认为让高级专家来完成这些任务是不合适的。
预售
当然，第一个任务是预售。
值得一提的是，考虑到预售是卖方和项目经理的领地，并不是所有的人也不总是将分析师与这一使命联系起来。 但是，随着时间的流逝，分析人员能够在此阶段证明其有用性和可行性。
首先，预售分析师当然会很有帮助，而且具有专业知识。 而且，无论是主题还是制度。 与销售人员一起参加会议和演示时，分析师会讲与主题相同的语言，并帮助销售人员找出与特殊专业词汇和术语相关的各种情况。 此外，分析师对销售的系统有更深入的了解，并拥有丰富的项目经验，因此分析师可以快速，准确地专注于满足客户需求的可能性，并令人信服地谈论解决类似问题的现有经验。
在一系列成功的会议之后，分析师开始与卖方隔离，然后独自离开客户，对流程，需要更换的现有系统，需要建立的基础结构等进行明确研究。
所有这些活动的结果是未来项目的轮廓，以及初步的技术要求，根据这些要求，可以对工作时间，人工和成本进行初步评估。
预先设计
在销售完成并且签署合同和举行仪式舞蹈以启动项目的组织措施开始执行之后，分析人员不再闲着，而是可以开始前期工作。
在这个阶段，他可能已经掌握了许多研究信息：这些是明确分析的结果，会议的笔记以及团队认可的最终工作声明，如果幸运的话，还有大量的各种客户标准和规定，这些要求在未来的设计中将需要考虑。 换句话说，这是大量的非结构化数据，需要在脑海中处理和制定一个未来解决方案的概念。
通常，此任务对于具有大型团队的大型项目是典型的。 正是在他们当中，分析师成为了技术专家，并决定了从这个意义上来讲，我们将在该项目的基础上开发什么—轮船或飞机。 它还在整个项目中协调团队，帮助选择最佳的技术和实质性解决方案，并确保设计系统的一致性。
分析师逐渐涉足未来项目的背景，绘制了框架并确定可以将哪些条件隔离的组件划分为该框架。 之后，他已经与项目经理一起将团队分配到各个分配的模块中。 重要的是要考虑到未来系统的模块之间的互连，并准确了解可以安全地分配给独立单元的工作量。
在研究了当前可用的所有信息之后，分析人员建立了自动化的概念，在此基础上，未来系统的框架将以较大的笔触投放。 这些决定将构成所有后续工作的基础，并为分析师在独立的区块上解决其本地问题确定方向。 此外，除了概念之外，可能仍是顶层的第一个流程图。 通常，从某种程度上讲，这是使分析师沉浸在项目中的副作用-可用信息分析的结果。 但是在将来，这些图表也将在分析师到客户那里进行详细研究时，由分析师进行指导。
此外，该概念与解决方案的体系结构紧密相关-在这里，分析师已经与领先的开发人员进行了互动，将未来的系统集成到客户的现有环境中，并确定了所需的集成和迁移量（包括启动和常规）。
同时，分析师不仅为即将到来的项目做准备，而且还为客户准备一个工作组-这些人将成为将来对未来系统的主要需求来源。 分析师与工作组举行会议并演示该系统的盒装版本，并特别注意那些将受到即将实施的实施影响的模块和功能。 这里的主要任务是使客户沉浸在系统的上下文中，以降低障碍并以更明智的态度对待需求的产生。 在演示中，分析师“现场”展示了传统知识项目如何适合或将适合现有系统。 TK的第一对接点和客户的实际需求就在这里。
专案
当然，主要工作直接在项目上开始。 在这个阶段角色不断变化。
首先，分析师作为业务分析师与客户紧密合作。 同时，他可以偶尔参加会议和访谈，甚至可以全天候地进入客户区域。 在此阶段，将对公司的流程进行深入研究，确定瓶颈和自动化需求，并就所发现问题的可能解决方案提供咨询。 而且，这些决定不仅可以是系统的，而且可以是行政和组织上的。 根据研究结果，诞生了“按原样”和“将要”业务流程的详细图表和说明，以及事件发展的所有微妙之处和可能的选择。 在此过程中，将识别并收集对未来系统对象的需求。
收集信息后，业务分析师将转变为系统分析师，从而将客户的需求置于特定系统的功能中。 在这一阶段，进行系统模块的设计，同时由经验丰富的分析师独立评估实现特定需求的可行性，并寻找绕过可能的平台限制的方法。 但是，经验不足总是可以通过与项目的主要开发人员进行磋商来弥补的。
在同一阶段，分析师将成为设计师，设计和绘制未来系统接口的布局。 重要的是，不仅要考虑视觉组件，还要考虑UX的基本假设以及所设计对象将参与的过程的逻辑。 所有屏幕形式迟早都必须形成一个单一的逻辑和和谐的画面，并且系统将必须对相同的用户操作做出同等的响应。
一个单独的阶段是设计各种集成和迁移。 这完全取决于分析师的经验及其系统能力。 通常，分析人员必须了解系统在总体环境中的位置，并对与客户其他系统的交互有很好的了解。 至少应在重叠实体，传输数据的规则和细节映射的级别上描述此交互。 设计的技术部分通常由开发人员承担。
在设计完所有解决方案之后，分析师将成为一名技术作家，并撰写一份大型美观的文档，其中提供了有关未来系统的详细说明。 本文档包括先前开发的方案，过程和接口的说明，以及元素应用逻辑的详细说明，以及为了实现设计的解决方案而必须在系统中执行的其他修改说明。 在这里，经过验证的文档结构和现成的模板可帮助您进行分析，以免丢失任何内容。
完成文档编制阶段后，基础工作至少要经过两次审核-团队的首席分析师和首席开发人员。 如果可能的话，还需要其他团队和项目的同事进行外部同行评审。 审核后，文档将发送给客户以供批准。 而且，它不会落在他难以理解的多页Talmud上，而是首先以演示的形式展示，其中包括解释，歌曲，舞蹈和有趣的图片。 此外，分析人员会伴随批准过程，回答客户的问题，更正某些公式，并在必要时提供要求和解决方案。 成功完成批准后，文档将发送至开发。
目前，我们的分析师稍有喘息。 在开发过程中，他当然与该项目的工作联系在一起，但工作量明显较小。 他的任务主要是回答开发人员的问题以及与客户定期更新需求。
开发完成后，分析师将成为测试人员，并对开发的解决方案进行长期，周到和严格的测试。 我会立即注意到我们正在谈论用户测试，但这并不意味着它是肤浅的。 选中每个按钮，每个窗口，每个路线分支，构建所有报告表单，启动所有脚本。 同时，测试分为两个大阶段。 第一步是检查基本功能。 此处的所有内容均应按文档中的说明工作，并且就像经验丰富且知识渊博的用户坐在计算机旁一样。 在验证了所有肯定的使用情况之后，分析人员开始“破坏”系统并从一个经验不足的用户的角度进行测试，该用户太懒惰甚至无法阅读说明。 我还想提请注意以下事实：在此阶段，可能会发生进一步细化需求和最终确定决策的情况。 测试最终完成后，我们就可以开始下一个任务了。
实作
在此阶段，分析人员参与了客户服务器上系统的部署和配置。 最初，建立测试电路，工作组将与项目团队一起对解决方案进行最终测试。 为确保此测试，分析师编写测试用例，考虑客户在有限的测试期间内需要执行的哪种情况才能涵盖最大的功能，并说服工作组一切正常。
当然，测试阶段会再次导致规格要求，系统改进和重复测试的循环，但是客户的不竭希望应该受到时间和人工的限制，试图仅将最关键的时刻投入工作。 无论听起来多么不人道，主要任务是迅速对实际用户投入使用。
在此阶段，分析师变成了培训师，对未来系统的普通用户进行了培训。 培训可以通过多种方式进行：具有实际任务和最终认证的全日制课程，研讨会，网络研讨会，视频，截屏等。 用户指令是并行编写的（尽管通常，它们的开发始于内部测试阶段）。
, , , . , – , .
, , , . , , , .
, , .
Bonus-level
, , .
– . 3-4 . , , , , .
, , . , , .
– . . – .
– , , ..
, , - , , .
Epic-fail
, . . – overqualified.
. , , . , , .
, -. , , , . , . – , . . , .
, . – !