在工业软件开发的现阶段，可以观察到各种生产角色。 他们的人数在增加，分类每年都在变得越来越复杂，当然，甄选专家和使用人力资源的过程也越来越复杂。 信息技术（IT）是高技能劳动力和人员短缺的领域。 在这里，员工发展过程，需要人力资源进行系统性工作比使用互联网资源进行直接选择要有效得多。
本文讨论了与与IT公司合作的人员有关的问题：生产角色演变中的因果关系，对人员工作总体上角色内容的误解造成的后果，以及提高专家选择效率的可能选择。
初学者的IT生产
IT中的谁是在各个场所进行讨论的话题。 它的存在与整个IT行业一样多，也就是说，从上世纪90年代初第一批软件开发公司在消费者市场上的出现就可以看出。 在相同的时间内，对于这个问题没有唯一的看法，这会造成困难并降低人事工作的效率。 让我们尝试找出答案。
对我来说，自从我加入IT公司以来，IT部门中生产角色的话题就变得相关且有趣。 我花了很多时间和精力去弄清楚生产过程。 这些成本超出了我的预期，也超出了其他方面适应流程的成本：教育，材料生产，小型企业。 我了解到这些过程是复杂且不寻常的，因为一般而言，人比物质世界更适应物质世界。 但是存在直觉上的抵制：似乎这里有些问题，事实并非如此。 适应过程可能花费了一年的时间，据我了解，这仅仅是一个宇宙量。 结果，我对IT生产中的关键角色有了一个清晰的认识。
目前，我继续在这个主题上进行工作，但是处于不同的水平。 作为IT公司开发中心负责人，我经常不得不与学生，大学教授，申请人，学童和其他想要参与IT产品开发的人进行沟通，以便在新领域（Yaroslavl）上推广雇主的品牌。 由于对话者对软件（软件）开发过程的组织方式知之甚少，因而他们对对话的主题缺乏理解，因此这种交流并不容易。 对话5至10分钟后，您会停止接收反馈，并开始感觉自己像个外国人，其讲话需要翻译。 通常，对话者中有人在对话中划出界线，并表达了90年代的流行神话：“无论如何，所有IT人员都是程序员。” 神话的来源如下：
- IT行业正在迅速发展，在这些条件下，所有基本含义和原则都处于形成阶段。
- 面对不确定性，很难存在，因此一个人试图通过创造神话来促进对未知的理解；
- 与虚拟世界相比，一个人更习惯于对物质世界的感知，因此，他很难定义超出其感知能力的概念。
与这个神话作斗争的尝试有时类似于与风车的斗争，因为需要解决该问题的几个方面。 人力资源专家首先需要以理想和真实的方式清楚地了解IT公司的生产角色，其次要了解如何以及何时最有效地利用公司的内部资源，其次要了解哪些实际方法将有助于增加对劳动力市场参与者的认识，并将为雇主品牌的发展做出贡献。 让我们更详细地考虑这些方面。
软件生命周期作为生产角色的基础
通常，任何IT公司的所有生产角色都将软件生命周期作为来源，这已不是什么秘密。 因此，如果我们设定了在整个IT行业中就该问题达成共识的概念性任务，则我们必须依靠软件生命周期作为公认且明确理解的语义基础。 关于实现生产角色问题的特定选项的讨论，在于我们对软件生命周期的创新态度。
因此，我们将以RUP方法为例来考虑软件生命周期所包含的各个阶段。 就内容和术语而言，它们是格式正确的链接。 生产过程始终无处不在，从业务建模和需求形成开始，（当然有条件地）以用户咨询和基于用户期望的软件改进结束。
如果您在上个世纪末进行了一次历史考察（如您所知，那是一个“岛屿自动化”的时期），那么您可以看到程序员参与了软件创建的整个过程。 这就是每个IT专家都是程序员的神话的根源。
随着生产流程的复杂性，集成平台的出现以及主题领域向综合自动化的过渡以及业务流程的重新设计，与生命周期各个阶段相关的专门角色的出现变得不可避免。 这就是分析师，测试人员和技术支持专家的外观。
职位的多样性以分析师的角色为例
分析师（他也是工程师分析师，还是董事，方法论者，业务分析师，系统分析师等）可以帮助他们与实现业务任务和技术的“朋友”。 针对开发人员的问题说明的描述-这是表征抽象分析师的主要功能的方式。 在需求形成，分析和软件设计过程中，他充当客户与开发人员之间的纽带。 在实际的生产条件下，分析人员的功能列表由组织生产的方法，专家的资格以及模拟主题领域的具体情况确定。
一些分析师离客户更近。 这些是业务分析师。 他们深刻了解主题领域的业务流程，并且本身就是自动化流程的专家。 在企业员工中，此类专家的存在非常重要，尤其是在使方法复杂的主题领域自动化时。 特别地，对于我们来说，作为国家预算程序的自动化者，仅在分析人员中必须是主题专家。 这些都是高素质的员工，具有良好的金融和经济教育经验，并且在金融机构中具有丰富的经验，最好是担任领导专家的角色。 不是在IT领域而是在主题领域工作的经验非常重要。
分析师的另一部分离开发人员更近。 这些是系统分析师。 他们的主要任务是识别，系统化和分析客户需求，以使其满意，准备技术任务并描述问题陈述。 他们不仅了解业务流程，还了解信息技术，充分了解交付给客户的软件的功能，具有设计技能，并因此了解如何最好地将客户的利益传达给开发人员。 这些员工必须具有ICT教育和工程技术思想，最好具有IT经验。 选择此类专家时，显而易见的好处是，可以使用现代工具来获得设计技能。
另一种分析师是技术作家。 他们从事软件开发过程中的文档编制，准备用户和管理员手册，技术说明，培训视频等。 他们的主要任务是能够将有关程序的信息传达给用户和其他有关方面，以简洁明了地描述技术上复杂的事物。 在很大程度上，技术作家会说流利的俄语，具有技术背景和分析能力。 对于这样的专家，最重要的是根据标准汇编清晰，称职，详细的技术文档的技能，以及掌握和掌握文档工具的能力。
因此，我们看到的是相同的角色（顺便说一句，在工作人员名单中的职位）-分析师，但角色各不相同。 为他们每个人寻找专家都有自己的特点。 重要的是要知道，这些类型的分析师必须拥有通常在一个人中不兼容的技能和知识。 一个是人文主义者，倾向于分析大量文本文件的分析工作，具有发达的语音和社交能力，另一个是具有工程思想和IT领域兴趣的“技术人员”。
从侧面还是成长？
对于IT行业的大型代表而言，随着项目的增长，直接从Internet资源中进行选择的有效性下降。 发生这种情况尤其有以下原因：无法快速适应公司内部的复杂流程，特定工具的开发速度低于项目的开发速度。 因此，对于人力资源专家而言，不仅要知道从外部寻找谁，而且要知道如何利用公司的内部资源，从谁那里以及如何发展专家，这一点很重要。
在主题领域的实际流程中，经验对于业务分析人员非常重要，因此“从外部”进行选择比在公司内部进行发展更有效。 同时，对于人力资源专家来说，重要的是要知道可以作为此人力资源来源的组织列表，并且在选择时要着重从他们那里寻找简历。
相反，要填补系统分析师和软件架构师这样的空缺，公司内部的培训过程非常重要。 必须在当前的工作环境和特定组织的细节中组建这些专家。 系统分析师是由业务分析师，技术作家和技术支持工程师开发的。 软件架构师（系统架构师）-从设计师（系统设计师）和软件开发人员（软件开发人员）中获得经验并拓展视野。 在这种情况下，人力资源专家可以有效地利用公司的内部资源。
生产角色的交集，统一与演变
从生产过程中的实施角度来看，还有一个难题：在角色之间建立明确的界限。 乍一看，似乎一切都显而易见：实施已完成，他们签署了将软件投入商业运营的文件，并将所有内容转移给了技术支持。 是的，但是经常会出现这样的情况，尽管客户已经不习惯与分析师保持密切联系并看到分析师的救命稻草，但他们仍然继续积极地与他交流，尽管事实上该系统已经实施并且支持阶段已经正式开始。 但是，从客户的角度来看，比与他一起制定任务的分析师更好，更快的客户，将回答有关使用系统的问题。 这里的问题是技术支持工程师和分析师的角色部分重复。 随着时间的推移，一切都会变得越来越好，客户已经习惯了与技术支持服务进行通信，但是在软件运行之初，如果没有双方的压力，这种“内部过渡”并非总是可能的。
当开发需求的流程在支持阶段的框架内时，也会发生分析师和技术支持工程师的角色交叉。 回到软件生命周期，我们看到实际生产条件和正式设置之间存在差异，需求分析和问题陈述只能由分析师来执行。 人力资源专家当然需要了解软件生命周期中角色的理想情况，因为他们有明确的界限。 但与此同时，应该牢记交叉是可能的。 在评估申请人的知识和技能时，应注意相关经验的存在，即，在寻找技术支持工程师时，应考虑具有分析师经验的候选人，反之亦然。
除了交叉，通常还会观察到生产角色的组合。 例如，一个业务分析师和一名技术作家可以一个人存在。 在大型工业开发中，必须有软件架构师（Software Architect）的存在，而很少的项目可以没有此角色：架构师的功能由开发人员（Software Developer）执行。
开发方法和技术的历史时期的变化不可避免地导致了软件生命周期也在不断发展的事实。 当然，在全球范围内，其主要阶段保持不变，但正在详细说明。 例如，随着向基于Web的解决方案的过渡以及远程配置功能的增长，出现了软件配置专家的角色。 在早期的历史阶段，他们是实施者，即工程师，他们将大部分时间都花在客户的工作场所上。 软件数量的增加和复杂性的增加导致了软件架构师的角色。 加快版本发布和提高软件质量的要求促成了自动化测试的发展，并出现了新角色-QA-engineer（质量保证工程师）等。 在生产过程的组织的各个阶段，角色的演变与方法，技术和工具的发展密切相关。
因此，我们在软件生命周期的背景下研究了有关软件公司内部生产角色分配的一些有趣观点。 显然，这是每个公司特有的内部外观。 对于我们所有人来说，作为IT行业劳动力市场的参与者并负责提升雇主的品牌，从外部看待尤为重要。 在这里，不仅在寻找意义方面，而且在将这些信息传达给目标受众方面都存在很大的问题。
IT帖子的动物园有什么坏处？
人力资源专家，生产组织者的思想混乱以及方法的多样性导致种类繁多，直接导致了IT职位的“笨拙”。 访谈和专业联系人的经验表明，人们通常对职位应遵循的语义负载并没有明确的了解。 例如，在我们的组织中，包括“工程师-分析师”概念的职位表明这是任务经理。 但是，事实证明并非总是如此：在某些开发组织中，分析工程师是实施者。 完全不同的理解，同意吗？
首先，IT职位的“笨拙”无疑会降低员工招聘的效率。 在发展和推广自己的品牌时，每个雇主都希望简短地传达其生产中存在的所有含义。 而且，如果他本人经常无法清楚地说出谁是谁，那么他当然会将不确定性传递到外部环境中。
其次，IT职位的“笨拙”给IT员工的培训和发展带来了巨大的问题。 每一家旨在建设和开发人力资源，而不仅仅是“挤奶”工作场所的严肃的IT公司，迟早都会遇到与教育机构互动的需求。 对于高素质的IT人员来说，这是大学的一个部分，并且至少在TOP-100排名中是最好的。
在大学之间建立一个持续不断的培训IT专家的过程中，与大学整合的问题大约一半是由于大学之间缺乏对谁是IT公司内部人员的了解。 他们对此有非常肤浅的理解。 通常，大学有几个专业，其名称中都带有“信息学”一词，并且经常发生这样的情况，即在进行招生活动时，他们依赖所有专业本质上是同一件事的论点。 看起来就像您依赖一个流行的神话，即所有IT专家都是程序员一样。
我们与大学紧密合作的经验表明，“应用信息学（按行业）”专业为我们提供了方法学和技术支持部门的人员，但没有提供开发人员。 基础信息学和软件工程为开发人员准备了出色的人力资源。 为了不使申请人最初沿着不合适的道路前进，有必要消除IT生产中的迷雾。
是否有可能将所有事物变成一个共同的分母？
是否可以统一生产角色并从公司内部和外部对它们进行共识？
当然，这是有可能而且有必要的，因为所有企业开发人员的累积集体经验证明了生产过程组织的共同，统一概念的存在。 这是由于以下事实：对软件生命周期有一个明确的解释，并且新出现的生产角色（DataScientist，QA-Engineer，MachineLearning工程师等）是对软件生命周期进行改进和开发的结果，技术和工具的改进，以及业务任务的开发和合并。
同时，由于IT是最年轻且发展迅速的行业之一，因此很难统一生产角色。 从某种意义上讲，这就是宇宙起源的混乱。 , – , . , – «»- , , «»-, . , , , , . , , , , .
-
, HR- -.
-, - , : , , – .
-, HR- . , . : , , . , , , .
-, : , , , , , .
-, , – , . HR- , , : , , , , , .
, , – , , . , , , -, « », . -, .
, : .