Quem é quem em TI?

Na atual etapa do desenvolvimento da programação industrial, é possível observar uma diversidade de papéis de produção. O número deles está crescendo, a classificação está se tornando mais complexa a cada ano e, naturalmente, os processos de seleção de especialistas e trabalho com o potencial humano estão se tornando mais desafiadores. As tecnologias da informação (TI) são um campo de recursos humanos altamente qualificados e escassez de mão de obra. Aqui, o processo de formação de pessoal e a necessidade de um trabalho sistemático com o potencial humano podem ser significativamente mais eficientes do que a seleção direta por meio de recursos da internet.

O artigo aborda questões relevantes para especialistas em gestão de pessoal em empresas de TI: as relações de causa e efeito na evolução dos papéis de produção, as consequências de uma interpretação errônea do conteúdo dos papéis para o trabalho de recursos humanos como um todo, assim como possíveis opções para aumentar a eficiência na seleção de especialistas.

Produção de TI para os não iniciados

Quem é quem em TI – este tema é debatido em várias plataformas. Ele existe desde que a própria indústria de TI surgiu, ou seja, desde o aparecimento das primeiras empresas desenvolvedoras de software no mercado consumidor no início dos anos 90. E há tanto tempo não existe uma visão unificada sobre essa questão, o que cria dificuldades e diminui a eficiência do trabalho de recursos humanos. Vamos tentar esclarecer isso.

Para mim, o tema dos papéis de produção na esfera de TI se tornou relevante e interessante desde o momento em que entrei em uma empresa de TI. Gastei muito tempo e energia emocional para entender o processo de produção. Esses custos superaram minhas expectativas e os gastos com a adaptação a processos em outras áreas: educação, produção material, pequenas empresas. Eu tinha a compreensão de que os processos eram complexos e incomuns, uma vez que, de modo geral, o ser humano está mais adaptado ao mundo material do que ao virtual. Mas houve uma resistência intuitiva: parecia que algo não estava certo, não deveria ser assim. O processo de adaptação levou, provavelmente, um ano, que, na minha compreensão, é uma quantidade absolutamente astronômica. No final, consegui formar uma ideia bastante clara sobre os papéis-chave na produção de TI.

Atualmente, continuo trabalhando nesse tema, mas em um nível diferente. Como chefe do centro de desenvolvimento de uma empresa de TI, frequentemente interajo com estudantes, professores universitários, candidatos, alunos do ensino médio e outras pessoas interessadas em participar da criação de um produto de TI visando promover a marca do empregador no mercado de trabalho de uma nova região (cidade de Yaroslavl). Essa comunicação não é fácil devido ao baixo nível de conhecimento dos interlocutores sobre como é organizado o processo de desenvolvimento de software (DS), levando à incompreensão do assunto em discussão. Após 5 a 10 minutos de diálogo, começa-se a não receber feedback e passa-se a sentir como um estrangeiro cuja fala necessita de tradução. Normalmente, entre os interlocutores há alguém que encerra a conversa e menciona o mito popular dos anos 90: "No final, todos os profissionais de TI são programadores". As origens desse mito são as seguintes:

• A indústria de TI está se desenvolvendo rapidamente, e nesse contexto todos os significados e princípios fundamentais estão em fase de formação;
• em condições de incerteza, é difícil existir, portanto, a pessoa procura facilitar sua compreensão do desconhecido, criando mitos;
• a pessoa está mais acostumada a perceber o mundo material do que o virtual, o que dificulta a definição de conceitos que estão além de sua percepção.

As tentativas de combater esse mito às vezes lembram uma luta contra moinhos de vento, uma vez que há vários aspectos do problema que precisam ser trabalhados. Um especialista em recrutamento precisa, em primeiro lugar, ter uma visão clara dos papéis produtivos em uma empresa de TI em sua forma ideal e real; em segundo lugar, entender como e quando o recurso interno da empresa pode ser melhor utilizado; em terceiro lugar, quais métodos reais podem ajudar a aumentar a conscientização dos participantes do mercado de trabalho e promover o desenvolvimento da marca do empregador. Vamos analisar esses aspectos em mais detalhes.

O ciclo de vida do software como base dos papéis produtivos

Não é segredo que, de maneira geral, todos os papéis de produção em qualquer empresa de TI têm como base o ciclo de vida do software. Portanto, se quisermos estabelecer uma tarefa conceitual que busque um entendimento comum sobre essa questão em toda a indústria de TI, devemos nos apoiar no ciclo de vida do software como uma base semântica aceita e claramente compreendida por todos. A discussão de variantes específicas de implementação das funções de produção se insere em nossa abordagem criativa ao ciclo de vida do software.

Assim, vamos considerar as etapas que o ciclo de vida do software envolve, utilizando como exemplo a metodologia RUP. Elas são elos bastante consolidados em termos de conteúdo e terminologia. O processo de produção sempre começa com o mapeamento de negócios e a definição de requisitos, e termina (de forma condicional, é claro) com a consultoria aos usuários e as melhorias no software com base nas 'desejos' dos usuários.

Se fizermos um breve passeio histórico até o final do século passado (como é sabido, esse foi o período da 'automação insular'), podemos ver que todo o processo de criação de software era conduzido por um programador/desenvolvedor. Aqui está a raiz do mito de que todo profissional de TI é um programador.

Com a complexificação dos processos de produção, a emergência de plataformas integradas e a transição para a automação abrangente de áreas temáticas, juntamente com a reengenharia de processos de negócios, torna-se inevitável o surgimento de papéis especializados, atrelados às etapas do ciclo de vida. Assim, surgem o analista, o testador e o especialista em suporte técnico.

A diversidade de cargos exemplificada pelo papel do analista.

O analista (também conhecido como engenheiro analista, formulador, metodólogo, analista de negócios, analista de sistemas, etc.) ajuda a "integrar" as necessidades de negócios com as tecnologias para sua realização. A descrição da formulação de requisitos para o desenvolvedor é como podemos caracterizar a função principal do analista abstrato. Ele atua como um elo de ligação entre o cliente e o desenvolvedor nos processos de formação de requisitos, análise e design de software. Em condições de produção reais, o conjunto de funções do analista é determinado pela forma de organização da produção, qualificação do especialista e especificidade da área de domínio modelada.

Uma parte dos analistas está mais próxima do cliente. Esses são os analistas de negócios (Business Analyst). Eles entendem profundamente os processos de negócios da área de domínio e são especialistas nos processos que estão sendo automatizados. É muito importante ter esses especialistas na equipe da empresa, especialmente ao automatizar áreas de domínio metodologicamente complexas. Em particular, para nós, como automatizadores do processo orçamentário do governo, é absolutamente necessário que haja especialistas na área entre os analistas. Eles são profissionais altamente qualificados com boa formação em economia e finanças e experiência de trabalho em órgãos financeiros, preferencialmente em posições de destaque. É extremamente importante ter experiência não apenas na área de TI, mas especificamente na área de domínio.

Outra parte dos analistas está mais próxima dos desenvolvedores. Esses são os analistas de sistemas (System Analyst). Sua principal tarefa é identificar, sistematizar e analisar os requisitos do cliente em relação à sua viabilidade, preparar especificações técnicas e descrever a formulação de requisitos. Eles compreendem não apenas os processos de negócios, mas também as tecnologias da informação, têm uma boa compreensão das capacidades do software entregue ao cliente, possuem habilidades de design e, assim, entendem melhor como transmitir os interesses do cliente ao desenvolvedor. Esses profissionais devem ter formação na área de TIC e um perfil de engenheiro-técnico, com experiência em TI sendo desejável. Ao selecionar esses especialistas, ter habilidades de design com o uso de ferramentas modernas será um grande diferencial.

Outra categoria de analistas são os redatores técnicos (Technical Writer). Eles se dedicam à documentação dentro dos processos de desenvolvimento de software, preparando manuais do usuário e do administrador, instruções técnicas, vídeos tutoriais, entre outros. Sua principal tarefa é comunicar de forma clara e concisa informações sobre o funcionamento do programa, descrevendo questões tecnicamente complexas de maneira acessível. A maioria dos redatores técnicos tem excelente domínio do português, além de formação técnica e uma mentalidade analítica. Para esses profissionais, é crucial ter habilidades na elaboração de textos técnicos claros, corretos e detalhados de acordo com os padrões, assim como conhecimento e domínio das ferramentas de documentação.

Assim, vemos um mesmo papel (e, por sinal, uma posição no quadro de funcionários) – analista, mas em suas diferentes manifestações práticas. A busca por especialistas para cada um deles apresenta suas peculiaridades. É importante saber que essas variedades de analistas devem possuir frequentemente habilidades e conhecimentos que muitas vezes são incompatíveis em uma única pessoa. Um deles é uma pessoa das ciências humanas, voltada para trabalhos analíticos com grandes volumes de documentos textuais, com boa comunicação e habilidades de fala, enquanto o outro é um "tecnólogo" com pensamento engenheiro e interesses na área de TI.

Devemos contratar ou desenvolver talentos internamente?

Para grandes representantes da indústria de TI, a eficácia da busca direta por meio de recursos online diminui à medida que os projetos crescem. Isso ocorre, entre outras razões, porque a adaptação rápida a processos internos complexos se torna impossível, e a velocidade de aprendizado de ferramentas específicas é inferior à velocidade de desenvolvimento do projeto. Portanto, é fundamental que o especialista de RH saiba não apenas quem procurar externamente, mas também como envolver os recursos internos da empresa, de quem e como desenvolver um especialista.

Para os analistas de negócios, é essencial ter experiência prática dentro dos processos reais da área, por isso, a seleção de candidatos de fora é mais eficaz do que cultivar talentos internamente. Nesse sentido, é importante que o profissional de RH conheça a lista de organizações que podem ser fontes desse recurso humano e, ao selecionar, concentre-se na busca de currículos dessas fontes.

Para preencher vagas como analista de sistemas e arquiteto de software, por outro lado, o processo de formação de talentos dentro da empresa é de extrema importância. Esses especialistas devem se desenvolver em um ambiente de produção ativo e nas particularidades de uma organização específica. Os analistas de sistemas (System Analyst) evoluem a partir dos analistas de negócios (Business Analyst), redatores técnicos (Technical Writer) e engenheiros de suporte técnico (Technical Support Engineer). Os arquitetos de software (Software Architect) provêm de projetistas (System Designer) e desenvolvedores de software (Software Developer) à medida que ganham experiência e ampliam seus conhecimentos. Essa circunstância permite que o profissional de RH utilize eficazmente os recursos internos da empresa.

Interseção, união e evolução de papéis produtivos

Há outra questão complicada em termos de implementação nos processos produtivos – o estabelecimento de limites claros entre os papéis. À primeira vista, pode parecer que tudo é óbvio: o processo de implementação foi concluído, os documentos de entrega do software foram assinados e tudo foi transferido para o suporte técnico. Isso está correto, no entanto, frequentemente ocorrem situações em que o cliente, habituado a estar em contato próximo com o analista e o vendo como sua "mágica", continua a se comunicar ativamente com ele, apesar de o sistema já ter sido implementado e o estágio de suporte formalmente ter começado. No entanto, do ponto de vista do cliente, quem melhor e mais rapidamente que o analista, que definiu a tarefa junto com ele, responderá às perguntas sobre o uso do sistema? E aqui surge a questão da duplicação parcial de funções entre o engenheiro de suporte técnico e o analista. Com o tempo, tudo se ajusta; o cliente começa a se comunicar com o suporte técnico, mas, no início da utilização do software, essa "transição interna" nem sempre é realizada sem stress para ambas as partes.

A interseção entre os papéis de analista e engenheiro de suporte técnico também ocorre quando o fluxo de requisitos para desenvolvimento acontece durante a fase de manutenção. Voltando ao ciclo de vida do software, vemos uma discrepância entre as condições produtivas reais e as diretrizes formais que indicam que a análise de requisitos e a formulação de tarefas podem ser realizadas exclusivamente por um analista. O especialista em gestão de pessoal, sem dúvida, deve entender a imagem ideal dos papéis dentro do ciclo de vida do software, pois eles têm limites claros. No entanto, deve-se ter em mente que a interseção é possível. Ao avaliar os conhecimentos e habilidades de um candidato, deve-se atentar para a presença de experiência adjacente, ou seja, ao buscar engenheiros de suporte técnico, candidatos com experiência de analista podem ser considerados e vice-versa.

Além da interseção, frequentemente observa-se uma combinação de papéis produtivos. Por exemplo, um analista de negócios e um redator técnico podem existir na mesma pessoa. A presença de um arquiteto de software (Software Architect) é essencial em grandes desenvolvimentos industriais, enquanto projetos muito pequenos podem dispensar esse papel: lá, as funções de arquiteto são realizadas pelos desenvolvedores (Software Developer).

A mudança dos períodos históricos nas abordagens e tecnologias de desenvolvimento inevitavelmente leva à evolução do ciclo de vida do software. Globalmente, é claro que suas etapas principais permanecem inalteradas, mas ocorre uma detalhamento delas. Por exemplo, com a transição para soluções web e o aumento das capacidades de configuração remota, surgiu o papel de especialista em configuração de software. Em uma fase histórica inicial, esses eram os implementadores, ou seja, engenheiros que passavam a maior parte do tempo de trabalho nas instalações dos clientes. O aumento nos volumes e na complexidade do software levou ao surgimento do papel de arquiteto de software (Software Architect). As demandas por acelerar o lançamento de versões e aumentar a qualidade do software contribuíram para o desenvolvimento de testes automatizados e o surgimento de um novo papel - QA engineer (Quality Assurance Engineer), e assim por diante. A evolução dos papéis em todas as etapas da organização do processo produtivo está significativamente ligada ao desenvolvimento de métodos, tecnologias e ferramentas.

Assim, discutimos alguns aspectos interessantes sobre a distribuição de funções produtivas dentro de uma empresa de desenvolvimento de software no contexto do ciclo de vida do software. É evidente que essa é uma perspectiva interna, específica para cada companhia. Para todos nós, como participantes do mercado de trabalho na indústria de TI e responsáveis pela promoção da marca do empregador, é especialmente importante ter também uma visão externa. E aqui existe um grande problema, não apenas na busca por significados, mas também na transmissão dessas informações ao público-alvo.

Quais são os problemas do "zoológico" de cargos em TI?

A confusão na mente de profissionais de RH, organizadores de produção e a variedade de abordagens levam a uma grande diversidade, um verdadeiro "zoológico" de cargos em TI. A experiência de entrevistas e contatos profissionais mostra que frequentemente as pessoas não têm uma compreensão clara da carga semântica que deve acompanhar os nomes dos cargos. Por exemplo, em nossa organização, os cargos que incluem o conceito de "engenheiro analista" supõem que esta pessoa é responsável pela definição de tarefas. No entanto, não é assim em todos os lugares: existem empresas de desenvolvimento onde o engenheiro analista é um implementador. Uma compreensão completamente diferente, não concorda?

Em primeiro lugar, o "zoológico" de cargos em TI, sem dúvida, reduz a eficácia da recrutação de pessoal. Cada empregador, ao desenvolver e promover sua marca, deseja transmitir de forma concisa todos os significados existentes em sua produção. E se ele mesmo muitas vezes não consegue dizer claramente quem é quem, é natural que ele transmita uma incerteza para o ambiente externo.

Em segundo lugar, o "zoológico" de cargos em TI cria enormes problemas na formação e desenvolvimento de profissionais de TI. Cada empresa de TI séria, focada em formar e desenvolver seu potencial humano, e não apenas em "explorar" sites de busca de emprego, cedo ou tarde se depara com a necessidade de interagir com instituições de ensino. Para profissionais de TI altamente qualificados, este é o segmento de universidades, preferencialmente as melhores, pelo menos aquelas que estão classificadas entre as 100 melhores.

O problema da integração com as universidades na construção de um processo contínuo de formação de especialistas em TI reside em parte na falta de compreensão por parte das universidades sobre quem é quem dentro de uma empresa de TI. Elas possuem uma visão muito superficial sobre isso. Geralmente, as universidades têm várias especializações com a palavra "informática" nos nomes, e muitas vezes, durante sua campanha de admissão, baseiam-se na tese de que todas as especializações na verdade tratam do mesmo assunto. E isso se assemelha à crença popular de que todos os profissionais de TI são programadores.

A experiência da nossa estreita colaboração com as universidades mostra que a especialização "Informática Aplicada (por Indústrias)" nos fornece profissionais para os departamentos de metodologia e suporte técnico, mas não para desenvolvimento. Enquanto isso, "Informática Fundamental" e "Engenharia de Software" preparam um excelente recurso humano para desenvolvedores. Para não direcionar os candidatos inicialmente por um caminho inadequado, é necessário "dissipar a névoa" que circunda a produção em TI.

É possível trazer tudo para um denominador comum?

É possível unificar os papéis de produção e chegar a um entendimento único deles tanto internamente quanto externamente à empresa?

Com certeza, é possível e necessário, porque a experiência coletiva acumulada de todas as empresas desenvolvedoras demonstra a existência de conceitos comuns e unificadores na organização do processo produtivo. Isso é consequência do fato de que existe um conceito de ciclo de vida de software unanimemente interpretado por todos, e os novos papéis de produção (Data Scientist, QA Engineer, Machine Learning Engineer, etc.) são consequência do esclarecimento e desenvolvimento do ciclo de vida de software em si, que ocorrem com o aprimoramento de tecnologias e ferramentas, bem como com o desenvolvimento e crescimento das tarefas de negócio.

Ao mesmo tempo, é difícil unificar os papéis de produção, porque TI é um dos setores mais jovens e em rápida evolução da economia. Em certo sentido, isso é um caos do qual surgiu o universo. Uma estrutura organizacional clara aqui é impossível e inadequada, porque a TI é uma área intelectual, mas extremamente criativa. Por um lado, o profissional de TI é um 'físico' intelectual com pensamento algorítmico e matemático desenvolvido, por outro lado, é um 'lírico' criador, portador e promotor de ideias. Assim como um artista, não possui um plano claro para criar sua obra, não consegue decompor a imagem em partes, pois a última deixará de existir. Ele é o mestre dos processos da informação, que são em si mesmos abstratos, intangíveis, de difícil mensuração, mas velozes.

Caminhos para construir um trabalho efetivo de recursos humanos na produção de TI

Então, o que é importante que um especialista em RH saiba para estabelecer um trabalho de recursos humanos eficaz em meio à diversidade de papéis na produção de TI.

Primeiramente, qualquer especialista em recursos humanos de uma empresa de TI deve ter uma noção da situação que é característica de sua própria empresa: quem faz o quê, quem e como é chamado, e o principal – qual o significado desses papéis no contexto da produção específica.

Em segundo lugar, o especialista em RH deve ter uma compreensão flexível dos papéis na produção. Ou seja, inicialmente ele forma uma perfeita compreensão deles, que permite que ele mesmo entenda tudo. Em seguida, deve haver uma imagem real da produção: onde e em quais pontos os papéis se cruzam, se unem, qual a percepção desses papéis entre os líderes de produção. A complexidade para o especialista de recursos humanos está em conciliar na mente a situação real e a ideal, não tentar impor processos à sua perfeita compreensão, mas ajudar a produção a atender à demanda por recursos.

Em terceiro lugar, é essencial ter uma noção das possíveis trajetórias de desenvolvimento de certos profissionais: em quais situações a seleção externa pode ser eficaz, e quando é melhor desenvolver um colaborador dentro da própria equipe, oferecendo-lhe oportunidades de crescimento; quais características dos candidatos permitirão que eles se desenvolvam em uma direção específica; quais dessas características podem não ser compatíveis em uma mesma pessoa; e o que é inicialmente importante para a escolha da trajetória de desenvolvimento.

Em quarto lugar, voltamos à tese de que TI é um campo de profissionais altamente qualificados, onde para um trabalho de recursos humanos mais eficaz, a integração precoce com o ambiente educacional universitário é inevitável. Nessa situação, cada especialista em RH deve desenvolver não apenas as habilidades de busca direta, trabalho com currículos e entrevistas, mas também deve se familiarizar com o ambiente de formação universitária dos profissionais: quais universidades formam profissionais para a empresa, quais especializações dentro de universidades específicas atendem às necessidades de pessoal, e, o que é importante, quem está por trás disso, quem dirige e realiza a formação dos especialistas nas universidades.

Assim, se quisermos desmistificar a ideia de que todos os profissionais de TI são programadores, é necessário realizar uma série de passos nesse sentido e prestar especial atenção às nossas universidades, onde são estabelecidas as bases da percepção da futura profissão. Em outras palavras, é necessário um constante envolvimento com o ambiente educacional, por exemplo, usando o formato moderno de trabalho conjunto em centros de coworking, 'pontos de fervura', participação em intensivos educacionais. Isso ajudará a destruir percepções errôneas sobre a empresa de TI, aumentará a eficácia do trabalho de recursos humanos e criará condições para a cooperação na formação de diversos especialistas de nosso setor.

Agradeço aos colegas que participaram da preparação e manutenção da relevância deste artigo: Valentina Vershinina e Yuri Krupin.

Fonte: habr.com