Analista de negócios e analista de sistemas em TI. Classificou as notas

Problema


Alguns de meus amigos, colegas, gerentes, eycharov, representantes do "negócio" em suas cabeças formaram uma confusão entre os tipos de analistas. O conceito de "analista" é usado para profissões completamente diferentes - analista de negócios (BA), analista de sistemas (SA), analista de dados, analista de UX, analista de segurança da informação, analista de processos de negócios e 5 a 10 outros, todos essas espécies têm muitas diferenças. Agora, sobre os dois específicos, os mais confusos, mas muito diferentes nas realidades domésticas de TI.



Quem se beneficiará com este artigo:
Paracomo
Analista e colegas— , , . — , , .

: xml- , -.
HR, , . «, ».

: java, .
Alveje a seleção e a distribuição de recursos que estão prontos para executar uma combinação específica de responsabilidades de trabalho, melhorar a comunicação em equipes. 

Exemplo: Para uma posição que requer máxima comunicação e flexibilidade, um "técnico" é selecionado sem o desejo de desenvolver essas habilidades.

Em geral, "Felicidade para todos, por nada"

Premissas


Este artigo fala mais sobre TI.

O valor "destilado" das postagens é considerado. Na vida real, especialmente em equipes que desenvolvem habilidades em forma de T (modelo de desenvolvimento de competências de um funcionário de profissões relacionadas), é mais complicado e confuso, mas se o seu analista não é o Janus de vários lados, a transição entre responsabilidades diferentes não é uma tarefa fácil.

Parte principal


Ao me comunicar com a BA e a CA de empresas e projetos de vários tamanhos, vi uma discórdia em conceitos que geram polêmica. Como geralmente acontece, a falta de terminologia geralmente aceita interfere na distribuição de tarefas e responsabilidades no projeto entre aqueles que são capazes de cumpri-las com a maior eficiência. Para apelar para uma fonte objetiva nessas disputas, decidi procurar opiniões na rede.

Eu compartilho os resultados das minhas pesquisas.

A análise de negócios e a análise de sistemas em TI são conjuntos de práticas, métodos e tarefas que simplificam o desenvolvimento de sistemas de informação necessários para resolver os objetivos de negócios das organizações. A confusão entre esses dois conceitos existe não apenas no ambiente doméstico, portanto:

https://en.wikipedia.org/wiki/Systems_analyst :

Um analista de sistemas normalmente está confinado a um sistema atribuído ou determinado e geralmente trabalha em conjunto com um analista de negócios. Esses papéis, embora tenham alguma sobreposição, não são os mesmos.

Como fontes que poderiam estabelecer a “linha divisória” entre a SA e a BA, tentei usar os códigos de conhecimento da BA, literatura profissional geralmente aceita, documentos regulamentares e artigos sobre vários recursos. Não consegui encontrar uma divisão claramente articulada. E é por causa disso:

  • , , — , . « », ( ), . 
  • ( / . ., BABOK, ., PMI Guide to business analysis . .), . , - -, . , . . -, « , , , , . , , , , - ». . PMI IIBA «system analyst» , «business analyst» .
  • ( ) , . , — . — , , , . — , , , , , .

Nesta situação, ofereço minha visão, com base na experiência em empresas de TI russas, tanto por parte do cliente quanto por parte do contratado no desenvolvimento de sistemas de informação. Essa abordagem ajudou no trabalho do autor Alan Vongsavanh, que estudou a literatura e os resultados de várias entrevistas e reuniu uma lista das habilidades básicas que compõem a maior parte das atividades de rotina da BA e da CA (a maior parte do tempo de trabalho):


* Fontes estrangeiras usam os termos mais apropriados "tecnologia focada" e "negócios focados".

Onde:
Identificação de requisitoso processo de determinação de requisitos de várias fontes por meio de entrevistas, seminários, análise de tarefas, fluxos de trabalho e documentos e outros métodos
Conhecimento de negócios, , -
.
-
 ,
 
,
( )
conhecimento de tecnologias, programação, criação e configuração de bancos de dados e outros aspectos técnicos, normas e regras para o desenho de soluções

Juntas, essas ações permitem formar um ciclo completo de análise de requisitos, trazendo-o do cliente para o desenvolvedor e, depois disso - trazendo o produto acabado da equipe de desenvolvimento para o cliente. Essa interação recai facilmente nas estruturas, por exemplo, é assim que aparece no modelo V, modelo em cascata ou metodologias flexíveis:





Por que essa separação


As habilidades exigidas pela BA e pela CA são similares de nível superior, mas o diabo está nos detalhes. Um analista de sistemas precisa de habilidades técnicas muito mais práticas para uma atividade completa; ele está muito mais próximo de um grupo de especialistas técnicos e deve entender melhor sua linguagem (sem isso, é difícil conseguir respeito na equipe, o que significa que é impossível transmitir sua visão). O bacharelado em TI está mais configurado para se comunicar com os negócios, sua tarefa é determinar a necessidade (sofrimento), encontrar, formular e propor uma solução para o problema do cliente comercial que usa sistemas de TI, para "vender" essa solução de alguma forma. A proximidade e o entendimento do usuário ajudam o BA a priorizar com mais eficiência as tarefas, a descrever requisitos e limitações não funcionais em um caso específico.

Além disso, a BA possui requisitos excessivos inerentes ao sistema, pensa nos objetivos de negócios e não deve ser restringida pelos recursos da tecnologia, o que é inaceitável para uma CA. Às vezes, esses requisitos excessivos de BA ajudam a encontrar soluções verdadeiramente inovadoras.

Existem limitações, no entanto. Para a BA, esse é o escopo de um domínio ou de uma indústria estudada (por exemplo: conhecimento aprofundado das regras bancárias); para a BA, trata-se de uma tecnologia e um sistema (por exemplo: excelente experiência com produtos da Oracle). Essas restrições podem ser um obstáculo na transição entre equipes, projetos e empresas, mas podem ser rapidamente eliminadas, se desejado, e com a ajuda de colegas.

Quase sempre, o analista da equipe desempenha ambos os papéis em maior ou menor grau (portanto, eu gostaria de evitar disputas sobre a combinação "e nós também temos um virologista"). Em alguns casos, analistas podem não ser necessários; em alguns casos, um especialista pode desempenhar plenamente as duas funções. Isso não viola as regras, mas indica uma combinação de funções, o nível de maturidade e o valor de um especialista em particular. No caso de um funcionário experiente, isso é bastante normal, mas a vaga de bacharel em administração de empresas com conhecimento de SQL, JS e API em um site conhecido parece estranha.

https://en.wikipedia.org/wiki/Systems_analyst :

Alguns profissionais dedicados possuem conhecimento prático em ambas as áreas (análise de negócios e sistemas) e conseguem combinar com êxito essas duas ocupações, efetivamente desfocando a linha entre analista de negócios e analista de sistemas.

Exemplo abstrato:


Ivan - BA empresa "Empreiteiro".
Eva é analista de sistemas na Executor.
A empresa "Cliente" precisa de uma grande revisão do sistema existente. 

Nesta situação, as tarefas de Ivan (BA): identificar os requisitos funcionais e não funcionais do Cliente e da Contratada, eliminar as contradições entre as partes interessadas para determinar uma solução aceitável, criar protótipos, interagir com o cliente durante o processo de desenvolvimento, realizar uma demonstração e aceitação do trabalho. Fazendo tudo isso junto com Eva.

Tarefas de Eve (CA): projetar a revisão da maneira ideal, descrever seu impacto no sistema, limitações e possíveis melhorias, criar uma especificação, decompor e transferir as tarefas para o desenvolvimento e monitorar sua implementação oportuna de acordo com os requisitos. Para fazer tudo isso junto com Ivan.

Em vez de saída


De cada ferro, é possível ouvir que, com o tempo, a complexidade dos problemas de negócios e suas soluções de TI aumenta exponencialmente. Junto com isso, a pilha de tecnologia está se desenvolvendo intensa e extensivamente, em amplitude e profundidade. Escolher a composição correta das tecnologias pode fornecer vantagens competitivas inovadoras, mas também pode ser destrutivo; geralmente, a escolha é feita nos próximos anos, colocando os desenvolvedores em uma estrutura estreita. 

A situação atual exige que os analistas de TI (1) tenham um conhecimento profundo da área de negócios, características dos processos internos, ambiente externo e tendências, (2) conhecimento não menos profundo das tecnologias, geralmente seu uso prático.

Você pode ser um idealista, procurar um gênio e exigir dele um alto entendimento de várias áreas de conhecimento, se não polares. Você pode ir à terra e entender que essa dualidade de deveres provavelmente levará a um fakap em ambas as direções. Sentar em duas cadeiras não é uma boa prática. 

Se a complexidade do projeto exigir BA e CA, primeiro você precisa formar um conceito de qual nível de conhecimento de negócios e recursos técnicos é necessário de um especialista e traduzi-lo em uma vaga publicada, em uma entrevista e em uma estratégia de teste. Sempre se quer "tamanho único", mas vivemos na vida real, onde provavelmente irá complicar a pesquisa e aumentar o preço da atração de uma "ferramenta múltipla".

Para colegas que se descobriram ou planejam trabalhar na BA ou na CA, aconselho que você execute o mesmo procedimento e entenda honestamente se deseja (1) procurar a semente da verdade em muitas vezes desafiar algoritmos e lógica, mudando constantemente os negócios ou (2) pesquisar e projetar complexos sistemas confusos, mas interessantes. Isso ajudará a encurtar o caminho para o pico selecionado e reduzir o desconforto de estar fora de lugar na busca de uma "posição bonita". 

Apêndice



Bem, Glavred, agora está mais claro? =)

All Articles