在工业软件开发的现阶段，我们可以观察到多种生产角色。 他们的数量在不断增加，分类每年都变得更加复杂，自然地，选择专家和人力资源工作的过程也变得更加复杂。 信息技术（IT）是高素质劳动力资源和人才紧缺的领域。 在这里，培养人才的过程以及需要对人才潜力进行系统化的工作，比利用互联网资源直接选拔要有效得多。
本文讨论了与 IT 公司人力资源专家相关的问题：生产角色演变中的因果关系、对一般人力资源工作角色内容的误解的后果，以及增加生产角色的可能选择。招聘专家的效率。
面向新手的 IT 制造
IT界名人是各个平台讨论的话题。 它的存在时间与整个 IT 行业一样长，即自上世纪 90 年代初消费市场上第一批软件开发公司出现以来。 而在同样长的时间里，在这个问题上却没有达成共识，这给人事工作带来了困难，降低了效率。 让我们试着找出答案。
对我来说，自从我加入 IT 公司以来，IT 领域的生产角色这个话题就变得相关且有趣。 我花了很多时间和紧张的精力试图了解生产过程。 这些成本超出了我的预期，也超出了适应其他领域流程的成本：教育、材料生产、小企业。 我知道这些过程是复杂且不寻常的，因为一般来说，一个人比虚拟世界更适应物质世界。 但直觉上却有抵触：这里似乎有些不对劲，不应该是这样的。 适应过程可能需要一年的时间，在我看来，这简直是一个漫长的过程。 由此，我对IT生产中的关键角色有了比较清晰的认识。
目前，我继续研究这个主题，但在不同的层面上。 作为IT公司开发中心的负责人，我经常需要与学生、大学老师、申请人、中学生和其他想要参与IT产品创建的人进行沟通，以在劳动力市场上推广雇主品牌新领土（雅罗斯拉夫尔）。 这种沟通并不容易，因为对话者对软件开发过程的组织方式认识不足，因此对对话主题缺乏理解。 经过 5 到 10 分钟的对话后，您将不再收到反馈，并开始感觉自己像一个演讲需要翻译的外国人。 通常，对话者中都会有一个人在对话中划清界限，并说出一个 90 年代的民间神话：“无论如何，所有 IT 专家都是程序员。” 神话的起源是：
- IT产业正在快速发展，所有的基本含义和原理都处于形成阶段；
- 在不确定的条件下生存是困难的，所以一个人试图通过创造神话来让自己更容易理解未知；
- 一个人比虚拟世界更习惯于对物质世界的感知，因此很难定义超出他感知的概念。
试图与这个神话作斗争有时感觉就像是在向风车倾斜，因为这个问题有几个方面需要解决。 人力资源专家首先需要清楚地了解IT公司中生产角色的理想和真实体现，其次了解如何以及何时能够最有效地利用公司内部资源，第三，真正的方法是什么有助于提高劳动力市场参与者的意识，并将有助于雇主品牌的发展。 让我们仔细看看这些方面。
作为生产角色基础的软件生命周期
众所周知，任何 IT 公司的所有生产角色都以软件生命周期作为其来源。 因此，如果我们设定在整个IT行业内就这个问题达成统一认知的概念任务，我们必须具体依靠软件生命周期作为每个人都接受和清楚理解的语义基础。 对实现生产角色问题的具体选项的讨论取决于我们对软件生命周期的创造性态度。
那么，让我们以 RUP 方法为例来看看软件生命周期包含的阶段。 它们在内容和术语方面都是相当成熟的链接。 生产过程无论何时何地都始于业务建模和需求的形成，最终（当然是有条件的）咨询用户并根据用户的“需求”修改软件。
如果你回顾一下上世纪末的历史（如你所知，这是“岛屿自动化”时期），你会发现创建软件的整个过程都是由程序员开发人员完成的。 以下是“每个 IT 专家都是程序员”这一神话的根源。
随着生产流程的复杂性日益增加、集成平台的出现以及学科领域向复杂自动化的过渡，随着业务流程的重新设计，与生命周期阶段相关的专业角色的出现变得不可避免。 这就是分析师、测试员和技术支持专家的样子。
以分析师角色为例的职位多样性
分析师（也称为分析工程师，也称为总监、方法学家、业务分析师、系统分析师等）帮助与业务任务和实施技术“交朋友”。 对开发人员的问题陈述的描述 - 这是人们如何描述抽象分析师的主要功能的方式。 他在需求形成、分析和软件设计过程中充当客户和开发人员之间的纽带。 在实际生产条件下，分析员职能列表由组织生产的方法、专家的资格以及建模主题领域的具体情况决定。
一些分析师的位置更接近客户。 这些是业务分析师（Business Analyst）。 他们深入了解该主题领域的业务流程，并且本身就是自动化流程方面的专家。 企业员工中拥有这样的专家非常重要，尤其是在方法论复杂的主题领域实现自动化时。 特别是，对于我们来说，作为国家预算流程的自动化者，分析师中必须有主题专家。 这些员工都是高素质员工，接受过良好的金融和经济教育，拥有在金融机构工作的经验，最好是担任领先的专家。 不是 IT 领域的经验，而是特定学科领域的经验极其重要。
另一部分分析师则更接近开发商。 这些是系统分析师（System Analyst）。 他们的主要任务是识别、系统化和分析客户的需求，以确定满足这些需求的可能性，准备技术规格并描述问题陈述。 他们不仅了解业务流程，而且了解信息技术，对提供给客户的软件的功能有很好的了解，具有设计技能，因此了解如何最好地将客户的利益传达给开发人员。 这些员工必须接受过 ICT 领域的教育并具有工程和技术思维，最好有 IT 经验。 在选择此类专家时，拥有使用现代工具的设计技能将是一个明显的优势。
另一种类型的分析师是技术作家。 他们将文档作为软件开发过程的一部分，准备用户和管理员手册、技术说明、培训视频等。 他们的主要任务是能够向用户和其他感兴趣的各方传达有关程序运行的信息，简洁明了地描述技术上复杂的事物。 大多数技术作家都精通俄语，同时拥有技术教育和分析头脑。 对于这些专家来说，按照标准编写清晰、有能力、详细的技术文本的技能，以及对文档工具的了解和掌握是最重要的。
因此，我们看到相同的角色（顺便说一下，人员配置表中的职位）——分析师，但其具体应用程序的具体形式不同。 他们每个人寻找专家都有自己的特点。 重要的是要知道，这些类型的分析师必须具备通常不兼容的技能和知识。 一个是人文主义者，喜欢进行大量文本文档的分析工作，具有发达的演讲和沟通技巧，另一个是具有工程思维和对 IT 领域感兴趣的“技术人员”。
我们是从外部获取还是自己成长？
对于IT行业的一大代表来说，直接选择互联网资源的有效性随着项目的增长而降低。 发生这种情况的具体原因如下：不可能快速适应公司内部的复杂流程，掌握特定工具的速度低于项目开发的速度。 因此，人力资源专家不仅要知道在外部寻找谁，而且要知道如何利用公司内部资源，从谁那里培养专家，如何培养专家。
对于业务分析师来说，在该主题领域的实际流程中工作的经验非常重要，因此“从外部”招聘他们比在公司内部培养他们更有效。 同时，对于人力资源专家来说，重要的是要了解可以作为该人力资源来源的组织列表，并在选择时重点搜索他们的简历。
相反，为了填补系统分析师和软件架构师等职位空缺，公司内部的培训过程非常重要。 这些专家必须根据当前的生产环境和特定组织的具体情况来组建。 系统分析师由业务分析师、技术作家和技术支持工程师培养而成。 软件架构师——来自设计师（系统设计师）和软件开发人员（软件开发人员），他们获得经验并拓宽视野。 这种情况允许人力资源专家有效地利用公司的内部资源。
生产角色的交叉、融合与演化
从生产过程中的实施来看，还有一个难题——在角色之间建立清晰的界限。 乍一看，似乎一切都是显而易见的：实施已经完成，软件投入商业运行的文件已经签署，一切都已经移交给技术支持。 没错，然而，经常会出现这样的情况：客户出于习惯，与分析师保持密切联系，将分析师视为“魔杖”，尽管系统已经实施，但仍继续主动与分析师沟通。正式支持阶段正在进行中。 然而，从客户的角度来看，谁能比与他一起设置任务的分析师更好更快地回答有关使用系统的问题。 这里就出现了技术支持工程师和分析师角色部分重复的问题。 随着时间的推移，一切都会变得更好，客户习惯了与技术支持服务的沟通，但在使用软件的最初阶段，这样的“内部过渡”并不总是能够在没有双方压力的情况下完成。
当开发需求流作为支持阶段的一部分出现时，分析师和技术支持工程师的角色也会出现交叉。 回到软件生命周期，我们看到实际生产条件与需求分析和问题表述只能由分析师执行的正式态度之间存在差异。 当然，人力资源专家需要了解软件生命周期中角色的理想情况；它们有明确的界限。 但同时，您一定要记住，交叉是可能的。 在评估应聘者的知识和技能时，应注意是否有相关经验，即在寻找技术支持工程师时，可以考虑具有分析师经验的应聘者，反之亦然。
除了重叠之外，生产角色通常也会合并。 例如，业务分析师和技术作家可以作为一个人存在。 在大型工业开发中，软件架构师（软件架构师）的存在是强制性的，而非常小的项目可以没有这个角色：架构师的职能由开发人员（软件开发人员）执行。
历史时期开发方法和技术的变化不可避免地导致软件生命周期也在演变。 当然，在全球范围内，其主要阶段保持不变，但变得更加详细。 例如，随着向基于 Web 的解决方案的过渡以及远程配置功能的增长，软件配置专家的角色已经出现。 在早期的历史阶段，这些人是实施者，即大部分工作时间都在客户工作场所度过的工程师。 软件数量和复杂性的增加导致了软件架构师角色的出现。 加快版本发布和提高软件质量的需求促进了自动化测试的发展和新角色的出现——QA工程师（质量保证工程师）等。 生产过程各个阶段的角色演变与方法、技术和工具的发展密切相关。
到目前为止，我们已经研究了在软件生命周期背景下软件公司内生产角色分配的一些有趣的点。 显然，这是内部人士的观点，每个公司都有自己的看法。 对于我们所有人来说，作为 IT 行业劳动力市场的参与者和负责推广雇主品牌的人，外部观点尤其重要。 这里不仅存在着寻找意义的大问题，而且还将这些信息传达给目标受众的问题。
IT职位的“动物园”出了什么问题？
人力资源专家、生产经理头脑中的混乱以及方法的多样性导致了 IT 职位的种类繁多，成为名副其实的“动物园”。 面试和简单的专业接触的经验表明，人们往往对职位名称应具有的含义没有清晰的理解。 例如，在我们的组织中，包含“分析工程师”一词的职位假定这是一个任务设置者。 然而，事实证明并非所有地方都是如此：有些开发组织中的分析工程师是实施者。 完全不同的理解，你同意吗？
首先，IT岗位的“动物园”无疑降低了招聘的有效性。 每个雇主在开发和推广自己的品牌时，都希望以简洁的形式传达其产品中存在的所有含义。 而如果他自己经常不能清楚地说出谁是谁，那么他自然就会向外部环境广播不确定性。
其次，IT岗位的“动物园”给IT人员的培训和发展带来了巨大的问题。 每一家严肃的IT公司，其目标是形成和发展人力资源，而不仅仅是“挤奶”工作场所，迟早会遇到与教育机构互动的需要。 对于高素质的 IT 人员来说，这是大学的一部分，而且是最好的大学，至少是排名前 100 的大学。
在建立持续的 IT 专家培训流程时，与大学整合的问题大约是大学不了解 IT 公司内部人员的一半原因。 他们对此的认识非常肤浅。 通常，大学有几个专业名称中带有“计算机科学”一词，并且经常发生这样的情况：当他们进行招生活动时，他们依赖的论点是所有专业本质上都是关于同一件事的。 这看起来就像我们相信所有 IT 专家都是程序员的流行神话一样。
我们与大学密切合作的经验表明，“应用信息学（按行业）”专业为我们提供了方法论和技术支持部门的人员，但没有提供开发人员。 而“基础信息学”、“软件工程”则为开发人员准备了优秀的人力资源。 为了不让应聘者一开始就走上一条不适合自己的道路，有必要“拨开IT生产的迷雾”。
是否有可能将一切都归结为一个共同点？
能否在公司内外统一生产角色并达成共识？
当然，这是可能的也是必要的，因为所有开发企业积累的集体经验表明存在共同的、统一的组织生产过程的概念。 这是因为软件生命周期仍然有一个独特解释的概念，而新出现的生产角色（数据科学家、QA 工程师、机器学习工程师等）是软件生命周期的澄清和发展的结果。软件生命周期本身是随着技术和工具的改进以及业务任务的开发和扩大而发生的。
与此同时，由于信息技术是经济中最年轻且增长最快的部门之一，因此很难统一生产角色。 从某种意义上说，这就是宇宙诞生的混沌。 在这里，清晰的组织结构是不可能也不合适的，因为 IT 是一个知识性但又非常有创造力的领域。 一方面，IT专家是“物理学家”——具有发达算法和数学思维的知识分子；另一方面，他又是“抒情诗人”——思想的创造者、承载者和推动者。 他就像艺术家一样，没有一个清晰的绘画计划；他无法将图像分解成多个部分，因为后者将不复存在。 他是信息过程的统治者，信息过程本身是抽象的、无形的、难以测量的，但却是快速的。
在 IT 生产中建立有效的人员工作的方法
因此，为了在 IT 生产角色多样性的背景下建立有效的人力资源工作，人力资源专家需要了解什么是重要的。
首先，IT公司的任何人力资源专家都必须了解其企业的典型情况：谁做什么，谁被称为什么，最重要的是，这些角色在以下条件下的含义是什么：特定的生产。
其次，人力资源专业人员必须对生产角色有灵活的理解。 也就是说，最初他对它们形成了理想的理解，这使他能够自己解决一切问题。 然后必须有一个真实的生产图景：角色在哪里、以什么方式交叉和组合，生产经理对这些角色有什么看法。 人事专家的难点在于将头脑中的真实情况和理想情况结合起来，不是试图强行重建流程来适应自己理想的理解，而是帮助生产满足对资源的需求。
第三，你一定要了解某些专家可能的发展轨迹：在什么情况下外部选拔可以有效，什么时候最好在你的团队中培养一个员工，为他提供发展机会，需要什么素质候选人的数量会让他们向某一特定方向发展，而这些品质在一个人身上是无法兼容的，这对于选择发展轨迹来说最初很重要。
第四，让我们回到这个论点：IT是一个高素质人才的领域，为了更有效地进行人事工作，尽早与大学教育环境融合是必然的。 在这种情况下，每个人力资源专家不仅必须培养直接搜索、问卷调查和面试的技能，而且一定要熟悉大学培养专家的环境：哪些大学为公司培养人才，特定大学内的哪些专业涵盖人才需求，以及谁在背后支持，谁在大学管理和培训专家，这一点很重要。
因此，如果我们有目的地揭穿所有 IT 专家都是程序员的神话，就有必要朝这个方向采取一些步骤，并特别关注我们的大学，因为那里为未来职业的认知奠定了基础。 换句话说，我们需要与教育环境不断互动，例如，使用联合办公中心的现代协作形式、“沸点”以及参与教育强化活动。 这将有助于消除对IT企业的误解，提高人员工作效率，为行业内各类专家的联合培训活动创造条件。
我对参与本文准备和支持本文相关性的同事表示感谢：Valentina Vershinina 和 Yuri Krupin。
来源： habr.com