在工業軟體開發的現階段，我們可以觀察到多種生產角色。他們的數量不斷增加，分類每年都變得更加複雜，自然地，選擇專家和人力資源工作的過程也變得更加複雜。資訊科技（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。
來源： www.habr.com