Para isto, se estiver afim, preciso do seu e-mail.

abs,

Rildo

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

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

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

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é

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

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

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