Quem tem acompanhado nosso pequeno mas agitado Fórum deve ter reparado: ainda há muita indefinição em torno do currículo e do job description de um Analista de Negócios. Os últimos debates, particularmente com o Ronan Lúcio e o Leandro Mendonça, me deram uma grande ajuda em uma decisão: qual item deveria sair de meu backlog (de artigos e temas represados – haha) e vir para cá, para o blog. Há tempos adio esta publicação, com a falsa esperança de conseguir desenhar um mapa completo que mostre os caminhos para a Formação de um Analista de Negócios (AN). Passou da hora dessa discussão se tornar pública. Ao mapa (versão Beta):
Antes, os créditos: foi o André Wolff quem deu a sugestão de usar um desenho parecido com aqueles mapas que apareciam nos livros da Wrox. E algumas caixinhas acima só apareceram por causa de depoimentos (e desejos) dos colegas Leandro e Ronan.
Talvez o meu rabisco não dê esta impressão, mas ainda há muito espaço a ser preenchido ali. Tentei destacar o fundamental, inclusive no tópico ‘Formação Complementar’. E, claro, não contemplo nenhum treinamento de ‘Habilidades Sociais’ (Soft Skills). O desenho trata exclusivamente de ‘Habilidades Técnicas’ (Hard Skills). Cabe uma breve descrição de cada caixinha:
FAN – Entendendo o Negócio é o programa que ‘roda mundo’ há pouco mais de um ano. Sua versão ‘oficina’ (workshop – 7 horas) dá uma visão geral de tudo que está inserido no tema “Modelagem de Negócio”. O curso (35 horas) permite o detalhamento e prática de alguns temas, particularmente a modelagem de negócios com UML e sua extensão EPBE (Eriksson-Penker Business Extensions).
A relativa complexidade da EPBE e, principalmente, da Modelagem de Negócios, justifica a existência de um módulo avançado, o FAN – Modelando Negócios com UML/EPBE. Imagino um curso 100% prático, com a modelagem de um negócio “inteiro”. Teria algo entre 32 e 40 horas. Imagino… teria… Sim, por enquanto este módulo é só uma idéia.
FAN – Business Patterns segue no mesmo caminho. Só o livro de Eriksson e Penker apresenta algumas dezenas de patterns. Debatê-las e praticá-las em um treinamento faz todo o sentido. O problema aqui é nosso nível de maturidade quando o assunto é modelagem de negócios. Ou seja, é idéia para a próxima Copa do Mundo. E olhe lá!
Apesar de meu “apego” à EPBE, não posso ignorar a crescente demanda por profissionais que dominem a Modelagem de Processos de Negócios com BPMN. Não tenho condições de oferecer tal treinamento. Por isso este módulo não tem a marca “FAN”. É o mesmo caso do Modelagem com Aris/EPC.
Destaquei dois módulos em Formação Complementar que estão diretamente relacionados com a Modelagem de Negócios: i) Balanced Scorecards & Mapas Estratégicos, ferramentas que enriquecem consideravelmente um modelo de negócios – facilitando o entendimento de objetivos, metas, oportunidades e problemas; e ii) BPM (Business Process Management), um universo em si. Tanto que, neste ponto, imagino apenas um treinamento de introdução ao BPM. Reparem, BPMN está em outro canto.
Segurei a tentação de colocar caixinhas SOA e Arquitetura Corporativa aqui por dois motivos: estamos tratando da Formação de Analistas de Negócios. Lotar o módulo Formação Complementar pode gerar muita dispersão de atenção. Mantive o básico. Pelo menos, enquanto as duas áreas de cima não estiverem melhor resolvidas. Vamos então ao amplo e “polêmico” módulo Engenharia de Requisitos:
FAN – Entendendo o Usuário também faz parte do programa que tenho apresentado. A oficina (7 horas) trata do básico, com ênfase no Desenvolvimento de Requisitos. O treinamento de 35 horas permite uma maior exploração de algumas técnicas, particularmente a especificação de casos de uso e a realização e facilitação de entrevistas, sessões JAD etc.
Como temos visto no fórum, o tema ‘Casos de Uso’ é mais cabeludo e incompreendido do que imaginamos. Por isso ele merece um módulo adicional, Escrevendo Casos de Uso, que desenvolvo há 2 meses. Deve se transformar em um curso prático, de 40 horas. Isso tudo? Sim, pelo que descobri, o tema merece. Mas deve existir uma versão oficina (7 horas) também.
E faz todo o sentido que o roadmap contemple também o módulo Escrevendo Users Stories. É uma alternativa aos casos de uso. Tenho lá minhas restrições, mas não posso ignorar sua adoção e eficácia em alguns projetos. Só não me habilito a formatar e oferecer tal treinamento.
Assim como, por enquanto, me manterei relativamente distante do Gerenciamento de Requisitos. É importante destacar que quando falo Gerenciamento de Requisitos estou falando também de Gerenciamento de Mudanças.Coloquei aqui apenas dois módulos: No OpenUP e No Scrum. (Obs: “No” não está em inglês, ok?).
Derivam deste último módulo duas sugestões para a formação complementar: Gerenciamento de Projetos e Scrum. Não é para o AN se bandear para o gerenciamento de projetos, please! Acontece que suas atividades se entrelaçam demais com aquelas de um gerente de projetos. É legal que ele conheça a disciplina de uma forma mais ampla.
Por fim, abri um módulo que é meu “xodó” mais recente: uma oficina que exercite exclusivamente as diversas técnicas de descoberta, aprendizado e descrição de requisitos: Entrevistas, JAD, 6 Hats… Xodó meu, não sei se há demanda. Quero crer que sim. É outro item de meu backlog que anda clamando por atenção. Sua aparição aqui pode dar o empurrão necessário.
Aliás, a grande motivação para este post é exatamente essa: empurrões! Algumas definições & idéias! E, claro, uma deixa-provocação: será que alguém (alguma instituição) consegue oferecer todo esse roadmap como um programa único? Alguém aí quer tentar preencher as caixinhas não assinadas? E colocar novas caixinhas? É isso. Inté!
The Um Roadmap para Analistas de Negócios by finito, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Brazil License.
Artigos relacionados:
- Para que serve o Analista de Negócios?
- O Mundo Ágil precisa de Analistas de Negócios?
- O Jogo dos 7 Erros para Analistas de Negócios
- Modelagem de Negócios: Os Diagramas
- BABoK = REBoK? Conversando sobre Análise e Modelagem de Negócios
{ 1 trackback }
{ 9 comments… read them below or add one }
Paulo,
Não posso deixar de dar os parabéns pela iniciativa!
Não sabe como fico feliz em ver estas opções no mercado.
Espero que o “povo” compreenda a importância dessas abordagens para o sucesso dos projetos e dê a devida atenção a estes assunto.
Só uma sugestão: Se o curso/oficina não vai ser exatamente de “Gerência de Projetos”, que tal um nome mais sugestivo? Algo do tipo “Gerência de Projetos para Analistas de Negócios”.
[]s
Ronan
Valeu Ronan. De novo, muito obrigado!
Olha, acho que um curso de Introdução ao Gerenciamento de Projetos já atenderia bem. Com o AN tendo boas noções de gerenciamento de riscos, escopo, prazos.
Já no caso do treinamento Scrum não tem alternativa, né? Ali, eu acho, ele entra de cabeça. E, para atender sua indicação, deve treinar bem o papel de PO (Product Owner). Ops.. acho que deveria ter destacado isso no corpo do texto! Perdão.
Abraços,
Paulo
Paulo,
Penso da mesma forma. Para o AN ser um bom PO (e isso é essencial quando trabalhando com um time ágil) é importante que ele conheça bem o framework, inclusive a cultura da equipe.
Se ele vai interagir com o time é importante que entenda, também, como eles pensam.
[]s
Ronan
Paulo,
Adorei sua iniciativa de tentar organizar todas essas caixinhas! Sei que essa saudável discussão vai longe. Aqui seguem minhas primeiras impressões.
Faz muito sentido a sua separação entre a modelagem de negócios e a engenharia de requisitos. Ver os termos “BSC” e “Casos de Uso” num mesmo diagrama é um alívio para minha alma. Acredito que “o negócio” só respeitará TI quando entendermos que só temos emprego porque existe um negócio (ninguém me conhece nesse fórum e já estou arrumando encrenca…) e quando soubermos vender melhor os nossos serviços, como você mesmo disse em sua oficina em SP… A formação de um analista de negócio como você descreve é um grande avanço nessa direção.
Arquitetura Corporativa:
Esse é um tema para muitas conversas, mas entendo que um Analista de Negócios senior pode e deve se envolver neste assunto. O fato do BABOK listar Arquitetura Corporativa (Enterprise Architecture) como um input e não como parte integrante da Análise Corporativa (Enterprise Analysis) é no mínimo confuso. Dá a entender que o desenvolvimento da Arquitetura Corporativa não é atividade de um analista de negócios. Como assim??? Um dos temas que integrantes do IIBA nos EUA trazem à tona é o papel do analista como estrategista, envolvido justamente na Análise Corporativa. Concordo que o tema ainda está imaturo, mas temos que encontrar o espaço ideal pra isso no seu diagrama. Acho até que não deveria ser na parte de Formação Complementar, mas preciso estudar mais esse assunto…
Gerenciamento de projetos:
Concordo com o comentário do Ronan. “Gerenciamento de Projetos para Analistas de Negócios” descreve bem a habilidade necessária ao analista de negócios. Ele não só tem que entender de gerenciamento de projetos como tem que ser capaz de trabalhar em parceria com o gerente do projeto. Gerenciamento de escopo, principalmente, tem que ser feito a quatro mãos.
“Soft skills”:
Depois de algumas experiências frustrantes, reconheci que até um ótimo trabalho técnico de análise de negócios fica comprometido sem os “soft skills”. Para nós engenheiros/programadores/amantes de tecnologia, é difícil aceitar que um projeto é constituido por pessoas, cada uma com seu perfil psicológico, suas experiências (ou traumas) e seus interesses pessoais. Requisitos nascem de interações entre pessoas, portanto a maneira como requisitos são discutidos, documentados ou validados influi diretamente na qualidade do resultado. Para mim, um ótimo analista de negócios é um ótimo gerenciador de conflitos, inclusive de conflitos pessoais que surgem no meio de reuniões, e até mediador de politicagens relaciondas a projetos em grandes ou pequenas empresas. Quando você diz que não sabe se haverá demanda por uma oficina que trate somente de técnicas de elicitação de requisitos (entrevistas, JAD, 6 hats, etc.), acho (e espero) que você terá uma agradável surpresa… para mim o segredo do bom analista de negócios está justamente aí. Se bem feitas, essas interações fazem com que os usuários enxerguem o analista como aliado, e não como “lá vem mais um de TI…” E isso leva a uma parceria de sucesso.
Por enquanto é só.
-Suzandeise Thomé
Paulo,
Penso igualmente. Demonstrar as atividades de um AN são de suma importância para outras pessoas da equipe que participam do processo.
Abraços,
Marcos Martins
Suzandeise, Marcos e Ronan. Antes de mais nada, muito obrigado pela participação.
Suzandeise,
Suas observações são valiosíssimas. Me permita comentá-las:
Arquitetura Corporativa:
Da forma como vejo EA (Enterprise Architecture), ela é um universo que ultrapassa as fronteiras que definem o corpo de conhecimentos da análise de negócios. Gosto de ver EA como um (coeso) conjunto de 4 Arquiteturas: do Negócio, de Tecnologia, de Informações e de Aplicações. Apenas a 1ª se encaixa no BoK do Analista de Negócios. Tanto que no I módulo de minhas oficinas eu digo que o AN, quando não trabalhando em projetos, trata principalmente da manutenção da Arquitetura do Negócio.
Sei que há uma forte tendência na adoção desta função em grandes empresas: o Arquiteto Corporativo – seria o braço direito do CIO. Temo que esta visão se consolide. Acredito que há espaço (e justificativa) para a existência de um comitê (ou escritório – blergh) de Arquitetura: com 1 membro para cada parte que citei acima. Vamos ver…
De qualquer maneira, acho que a inserção de uma ‘caixinha’ de “Arquitetura do Negócio” faz todo sentido. E você está certa: ficaria no grande módulo “Modelagem de Negócios”. Está anotado para a próxima versão do roadmap.
Gerenciamento de Projetos
Eu ainda não consegui imaginar como seria um curso de *Gerenciamento* de Projetos para AN’s. Entendi as colocações suas e do Ronan. Mas não consigo ver o programa do curso.
Soft Skills
Concordo contigo. Mas devo confessar um certo ceticismo. A grande maioria de cursos de ’soft skills’ que vejo por aí (Liderança, Comunicação etc) exalam um forte cheiro de xamanismo neo-zen-budista. Nada contra, mas realmente não tive coragem de ‘misturar bolas’.
Mas, claro, vários módulos apresentam de forma implícita a prática de várias ‘habilidades sociais’. Além daquele destacado por ti (Entrevistas, JAD…), eu colocaria também o Escrevendo Casos de Uso e o FAN – Entendendo o Usuário.
Que nosso papo prossiga! Rico assim.
Abraços e, de novo, muito obrigado.
Paulo
Suzandeise,
Sincronicidade! Fico muito feliz quando nossos papos estão em total sintonia com os papos que estão rolando em outras paradas… paradas que sempre parecem estar na nossa dianteira!
Saca só: no último dia 13 o ZapThink, uma das melhores referências quando o papo é SOA, publicou um artigo que toca justamente em um ponto que acabamos de debater aqui: The Business Analyst vs. the Enterprise Architect: http://zapthink.com/report.html?id=ZAPFLASH-2008813
Apesar de não concordar 100% com a definição que eles dão para o EA, achei o artigo fantástico. Vale a lida e várias relidas.
Abraços,
Paulo
Tenho acompanhado seu trabalho, e confesso, que ele é muito bom, de longe supera
a expectativa.
Gostaria de conversar contigo a respeito de algumas idéias sobre o tema
Analista de Negócio.
Para isto, se estiver afim, preciso do seu e-mail.
abs,
Rildo
RT: : Blog Post: Um Roadmap para Analistas de Negócios – http://bit.ly/LETUk