Analista de Requisitos: Papel, Função ou Cargo?

Antes de criar um post, costumo pesquisar várias referências e vejo o que as pessoas estão comentando sobre o tema, até para evitar fala tanta besteira. Por isto, antes de criar o meu último post, percebi que existem alguns autores que consideram a análise de requisitos como, de certa forma, “morta” e outros que é algo que pode ser desenvolvido por qualquer pessoa com qualquer nível de experiência, basta “saber ouvir”. Este costume, além de te dar um feedback sobre como algumas pessoas andam pensando sobre o assunto, te fornece argumentos suficiente para defender a tua ideia, caso não seja a mesma.

Pois bem, hoje decidi falar sobre o profissional que, como eu, tem no currículo a seguinte descrição de cargo profissional: “Analista/Engenheiro de Requisitos”. É tão incerto determinar se a análise de requisitos é um papel, função ou cargo que os nossos queridos alemães criaram um comitê internacional (IREB) para estabelecer suas boas práticas, independente de quem as esteja utilizando. Mas, vamos tentar discutir sobre isto?

Existe um livro chamado BABOK mantido pelo pessoal do IIBA que, em seu próprio site, o define desta maneira:

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) is the essential standard to help practitioners and their stakeholders deliver business value and create better business outcomes.

BABOK® Guide expands the scope of business analysis, providing essential direction and support for practitioners in areas such as agile, business intelligence, information technology, business architecture and business process management. Available in English and German.

Vale ressaltar que o nosso compatriota Marcelo Neves foi colaborador da versão 3 deste livro.

Voltando ao assunto, neste mesmo livro temos uma citação interessantíssima que diz respeito a este post:

Um Analista Negócio é qualquer pessoa que exerça atividades de Análise de Negócio, não importando qual seja seu cargo, função ou papel. (Tradução livre)

O que nos faz pensar se realmente existe a profissão análise de requisitos ou análise de negócios, já que, como o BABOK diz, pode ser qualquer pessoa desde que exerça as suas funções, cargos ou papéis. Agora ficou confuso, não foi?

Deixa eu tentear clarear mais as cosias tentando explicar a diferença entre função, papel e cargo:

(Detalhe: Fui buscar no dicionário a diferença e acabei ficando quase mais confuso do que estava antes. Vou tentar trazer mais pra o nosso mundo do TI)

Função: Um time ou grupo de pessoas e ferramentas usados para realizar um ou mais processos ou atividades. Um bom exemplo de uma função é a Central de Suporte, que é composta por um número de atendentes de suporte.

Papel: Um papel é um conjunto de responsabilidades, atividades e autoridades concedido a uma pessoa ou time. Papéis são definidos nos processos. Uma pessoa ou time pode ter múltiplos papéis. Por exemplo, no Scrum, o papel de Product Owner é atribuído a uma pessoa, mas o papel de desenvolvedor é atribuído a um time de desenvolvedores.

Percebe a diferença? Minha função é engenheiro de software, porém meu atual papel na empresa é ser programador no time de scrum que participo.

Cargo: Pra mim, dentro deste contexto, é o menos importante. É a penas o título que o colaborador recebe pela posição que ele ocupa no organograma da empresa. Simples, não?

E aí? Analista de Requisitos é uma cargo, função ou um papel?

Calma, chegaremos lá…

Gosto muito de contar histórias. Então, se me permitem, gostaria de compartilhar a minha trajetória para vocês:

Em 2009, comecei trabalha como programador. Naquela época, pouco se falava aqui no Brasil em comunidades que se ajudavam e faziam meetups para o desenvolvimento em comum de um grupo de desenvolvedores. Ou seja, fui fazendo minha faculdade, lendo o máximo de livro que podia e impulsionando a minha própria evolução profissional de forma autodidata. Nesta fase, era visível a quantidade de pessoas que se perdiam no meio a tantas dúvidas e falta de informações importantes em um só local. Uma vez que, assim como hoje, existe um overload de informações na internet só que tudo está embaralhado, fica difícil para quem não sabe o que procurar.

Daí surgiu um gatilho: “Por que não ajudar estas pessoas que estão iniciando a carreira e precisam de uma mentoria para potencializar suas habilidades como programadores?”. E assim surgiu o meu TCC da faculdade.

Passaram-se os anos e eu fui trabalhando e me evoluindo cada vez mais como programador em diferentes equipes, empresas e, principalmente, culturas. Todos os locais em que trabalhei, fiz algo que talvez tenha sido essencial para chegar onde estou: Observar.

Se v0cê é programador e está lendo isto, você se identificará com a seguinte frase: “Eu sou programador, não preciso falar com o cliente.” ou “Por que o cliente quer falar comigo se eu sou ‘apenas’ o programador da equipe”? Pois é…

Existe um estereótipo de que deve haver uma segregação onde determinados cargos supostamente não devem se comunicar com outros que estejam muito abaixo do seu nível hierárquico.

Mas, curioso e teimoso que sou, pensei: “Por que não?! Qual mal vai me fazer de, pelo menos, ouvir uma reunião de um analista de requisitos com um stakeholder?” E isto fez toda a diferença. Não me mantive “dentro da caixa” que as faculdades ou até mesmo teus companheiros de trabalhos te impõem. Questionei, escutei, aprendi, ousei.

Nas primeiras reuniões eu não entendi NADA x NADA!!! Mas, sabe por que? Simplesmente porque eu não conhecia o domínio do sistema em que as pessoas estavam conversando, além das técnicas de levantamento de requisitos. Fui persistente e pedi permissão ao meu chefe para participar de uma reunião de levantamento de requisitos do projeto no qual eu era programador.

Detalhe: Primeira reação: “Pra quê?!”

Resposta: Para saber como é o seu dia-a-dia, admiro muito o seu trabalho. (Levantar a bola as vezes funciona)

Então lá estava eu, participando de uma reunião onde eu tinha total conhecimento do domínio do sistema e, voilà, entendi tudo e até mesmo a técnica que estava sendo utilizada para a extração de requisitos. Até fui ousado e comecei a dar sugestões para os stakeholders sobre determinados tópicos (Neste momento, meu chefe me olhava meio de lado enviando alguns sinais que preferi não traduzir)

Pra encurtar a história e não deixar este artigo tão longo, sempre fui um programador curioso. Sabe um segredo que eu sempre fazia quando chegava em uma empresa? Olhava para uma função e dizia para mim mesmo: “Vou ter aquela função”. E, acreditem senhores, sempre consegui. Nunca passei por cima de ninguém, nunca tirei cargo de ninguém para que eu entrasse no lugar, apenas fui esperto o bastante para aprender com os melhores e estar atento as oportunidades. Claro, você precisa estar preparado para quando isto acontecer.

Com isto, após várias reuniões, perguntas diárias ao meu ex-chefe, leituras e mais leituras, aproximação dos stakeholders para entender os seus reais problemas, parei e pensei comigo mesmo: “Estou pronto para ser um analista de requisitos”. E foi isto o que aconteceu, comecei a dar sugestões melhores, ter insights significativos, pedir ao meu chefe para exercer esta função em projetos pequenos que, com o tempo, foram se tornando maiores e hoje, graças a Deus e ao meu esforço, estou neste área há mais de 4 anos.

Com isto, respondendo a pergunta do título deste artigo, EU responderia que a análise de requisito é muito mais uma habilidade que você precisa desenvolver do que uma função, cargo ou papel. Com esta habilidade, você consegue exercer qualquer um destes rótulos, basta estar preparado para isto. Mas, para aqueles que preferem rotular tudo, eu diria que seria um papel, pois qualquer pessoa preparada o suficiente para isto pode extrair requisitos da melhor forma possível.

Uma dica para programadores: É muito comum vocês focarem apenas nos assuntos da área operacional. Ou seja, linguagem de programação, melhores stacks, design patterns e etc. No entanto, assim como toda e qualquer área, é preciso que se tenha um conjunto de ferramentas em quase todas as áreas que envolvem o negócio que você faz parte. Mesmo que não seja um conhecimento aprofundado, saiba pelo menos do que se trata. Imagina que amanhã apareça uma oportunidade internacional onde se precise de um engenheiro de requisitos senior que, dentro seus papéis, um deles é o levantamento de requisitos. E agora? Desistir da vaga? Pense nisto. É preciso ter coragem para desenvolver suas habilidades interpessoais, de negócios e outras que vão além da área técnica.

Um forte abraço a todos os leitores.