问候！我叫Sergey，我是业务/系统分析师。我在IT行业工作了大约8年，从支持测试到支持分析一直到分析（业务和系统）一直到现在。我尚未分别作为企业和系统分析师工作。在一般的专业活动中，包括实践和个人访谈，尤其是对潜在候选人的访谈，我逐渐了解了市场期望分析师提供哪些技能。哈伯（Habr）很久没看到关于这个主题的新文章了，所以我决定自己准备材料。我认为这篇文章对谁有用：- 初级业务/系统分析师；
- 希望继续提高专业水平的分析师。技能专长
- 也许是招聘经理。
我必须马上说，以下几点是我对分析师专业化的主观看法，这是在实践中形成的。如果您的公司运行成熟的Scrum，而产品所有者离您仅一米之遥，并且为团队分配了设计师和建筑师，则可能不需要上面的某些功能。但是，至少所有这些技能都不会是多余的，并且会使分析人员在他的问题上更加胜任。当然，您需要了解我没有列出分析师的所有技能和能力（相同的符号，业务技能，sql等）。商业分析
与业务客户交谈时，您需要了解其语言可能与您的语言有很大不同。可以这样一种方式表达业务需求，即批准过程中的多个参与者对该需求的含义有不同的理解。产生了歧义，这对于团队在开发的后期阶段是非常昂贵的。当有多个业务客户时，每个问题都提出了自己的要求，这一问题最为严重。例如，当集成两个系统时，每个系统都有自己的业务代表。案例研究：花了一个月的时间来开发将活动清单从第一对象转移到第二对象的功能。在验收测试阶段，发现客户期望完全不同的功能-复制而不是转移活动。在重做功能和详细说明歧义的过程中，IT团队首先与客户就MVP达成协议，其次，需要与业务问题的根源打交道。假设仅由于复制活动本身的功能不足，无法加载活动模板而需要复制功能。
我遇到了一些案例，这些案例是我在描述开发声明而未确定业务目标的情况下制定出来的：完成工作对业务有什么实际帮助？这种改进会减轻企业的痛苦吗？通常，这种无目的的改进会在测试阶段就带来不愉快的后果，当时开发人员和测试人员都不理解我们为什么设计此功能。更糟糕的是，开发人员和测试人员没有收到分析师的回答，如果回答了，他们通常会自己提出分析师：分析师自己制定的目标。
与客户一起写下目标，以便绝对地在过程中的所有参与者随时了解他们为什么做工作。在实践中，我遇到了不同的客户，其中一些客户还没有立即准备好邀请分析师参加他们的离线会议。分析人员还必须对此进行努力：同意并展示协调良好的协作的结果。, — UX- — « », , . : , , windows-, . , .
许多分析师，包括我在内，在制定要求的过程中都面临着一个艰难的截止日期，他们采用了以下技巧：他们给该过程的参与者写了一封信，并在截止日期前答复了该信，并提出了同意/提出评论的要求。否则，需求将被自动确认为同意。如实践所示，这种方法没有什么好处。显然，与供应商合作并达成协议后，您必须诉诸这种方法，但仍要避免默契，尝试理解参与者为什么不希望现在就给您答案，并尽快解决问题。最好以书面形式记录一个事实，即没有从这样的人那里得到答案，您会在此项目中看到以下风险。但是，工作流程不能停滞不前，因此您被迫继续进行分析工作，而先前定义的风险应让流程中的所有参与者都清楚。在开发两个系统的集成的过程中，主管面临着形成两个系统中用户行为的需求的形成，但是缺乏直属部门的直接相同需求的明确协调，而该部门的直接雇员是系统的用户。
后来发现，该部门的负责人根本不理解为什么所有这些改进以及它们如何帮助优化他负责的领域的流程。
通常，批准过程的参与者只是害怕签名，因为他们不完全了解更新后的业务过程的某些部分。作为业务分析师，您的任务是消除这种误解。
花几个小时，但要向开发人员介绍客户，当前的业务流程，痛苦和开发计划。通常，有上进心的开发人员不仅可以很好地完成工作，了解他们为谁编写代码，还可以做出宝贵的贡献：他们提供优化，解决方法，更愿意提出澄清的问题。如有必要（且缺乏混乱），请吸引客户参加这样的会议。通常，业务代表愿意同意此类举措。- 教客户回答“什么？”问题，而不是以“如何”的格式提出要求
客户不应从“操作方法”位置制定业务/用户要求：我们需要此屏幕上的按钮来生成报告；我们需要在本节中链接到外部系统；等等在过程的初始分析阶段，在设计本身之前，客户不应提供解决方案。相反，教会客户解决问题的“痛苦”：我们需要每周生成一份报告，并由员工手动进行补充并发送给管理层；在与客户合作的过程中，我们需要分析其他信息，并且由于CRM系统中不可用，因此我们必须在浏览器中打开一个新选项卡并登录到相邻系统。了解了客户的痛苦后，您可以作为专家来提供优化流程及其自动化的选项。例如，自动将生成的报告发送到员工的邮件，使员工免于使用该报告的手动工作，原则上，将数据从相邻系统自动下载到CRM，等等。在许多情况下，这种方法将面临现实：期限和优先事项。但是无论如何，您都是诚实的尝试。
毫无疑问，接受系统用户的要求时要考虑到他在业务流程中的作用。实际上，在很多情况下，部门负责人会形成普通员工将要行使的职能要求。将系统的用户划分为多个角色，针对一个角色而增强的功能不会在另一角色下“蒙蔽”。一次，在系统框架内，我们实现了与客户交易清单的显示。
假定经理和普通员工都可以使用该列表。不幸的是，我们无法从客户那里了解到需要将修订的UI部分分为两个列表/屏幕：一个用于管理和分析目的的经理列表，另一个用于进行操作活动的员工列表。
结果是某个怪物，随后必须将其最终确定下来。
从UX应用最佳实践：计算角色-用户模型。说服客户将每个字符的要求分开。与第二个分析器可以同时使用，也可以与UX设计器一起使用。在攻击过程中，尝试两个角色：一个人首先提出很多想法，可行且不太实际，其次是批评这些想法，分解它们，将它们写下来，重新考虑。然后切换角色并执行相同的工作。如实践所示，此方法将大大加快功能需求的编译过程并提高其质量。但是有一个困难，就是两位专家都应该在任务范围内。在其中一家公司中，实际上是一年之内，我们的团队设法将引入改进的过程从完善的管理经理级别转移到了Waterfall到某种Scrum。是的，客户一直以来对IT团队不断要求的积压的积压工作的“明确”截止日期正在推迟，而这种言辞却通过两周的发布，MVP解决方案和对变更的快速响应而逐渐得到缓解。是的，有各种各样的顾客。有些人真的很生气。但是，业务分析师必须自己解决此问题，也必须在经理的参与下解决此问题，在任何情况下，他都不应对团队提出“争吵”。团队应具有良好的工作积极性，而业务分析师在激励形成过程中的角色是关键之一。说真的 在与客户沟通的过程中，我听到分析同事的口头上可笑的声音，当我的分析同事打扰客户而没有听完他的声音时，我想让他参加有关谈判或基本道德的课程。尝试听对话者的声音，然后听他讲话。尽量避免使用寄生语，减少对话中的“烦恼”。刚开始时很难，但是，请相信我，客户很难听到这样一位无法清晰，清晰地表达自己想法的分析师。寄生虫可能会受到开发人员，设计人员，测试人员的影响，但不会影响将IT团队与业务部门联系起来的业务分析师。 :
- " ".
- ", : ".
系统分析
或者，在俄语中为顺序图。即使从开发的角度来看，这些图也将被证明是有用的，而从验证其自身需求的角度来看，这些图将是有用的。通常，在描述消息流时，我在自己的过程中发现了“漏洞”。例如，无关的API。要快速“绘制”一系列图，请使用Confluence的PlantUML插件。在我看来，键入代码比用笔调整块和箭头的位置要快。但是这部分的每个人都有自己的经验和偏好。
在分析方面，Swagger编辑器允许您关闭需求中的漏洞。他们错过了该属性的某个地方，而忘记了在JIRA中创建任务以完成数据库的某个地方。不要试图记住Swagger语法，而是为不同类型的API（目录，过滤器等）创建模板，以简化将来的生活。
- 积极使用目标浏览器中的开发人员工具来分析服务器的客户端请求和响应
首先，在初始接受过程中，您可以检查自己描述的API。有时，通过传出请求检查某些改进要比通过UI检查更快，以便尽早了解问题的根源。作为分析人员，您将需要更少的时间来检查开发人员的实施情况：传出数据，传入数据以及UI中的结果。
其次，您可以验证正确的呼叫顺序。毕竟，您自己在序列图的框架中对其进行了描述。这种方法使我们的团队可以毫不拖延地对sprint进行相当棘手的改进。 :
- " JavaScript". JSON, , HTML, http / https, .
- . , . " . , , ". , , , .
此外
您甚至可能喜欢它，并且想要向UX分析发展。无论如何，至少从与您的团队中的UX设计师找到通用语言的角度出发，研究相关的文献和设计工具将至少受益。通常，作为分析师的您需要详细描述并写下的要求，随后设计师会对其进行调整。毕竟，您并不孤单，实际上，您正在设计用户体验。要使用相同的波长，请进行用户体验分析。例如，在业余时间使用Sketch或Figma，不时向设计人员显示结果。这样的分析经验永远不会是多余的。 :
- " ".
- " ".
- ". ".
- ". ".
***感谢您阅读本文！首先，感谢您的反馈。其次，提供有关文献，资源，最佳实践，个人经验和建议的建议。