Hoje acordei com um desafio pela frente. Tinha que tirar os pontos da minha cirurgia de apendicite realizada há duas semanas. Bom, para o pessoal da saúde ou para quem já foi para a faca, ter receio desse procedimento é infundado, mas confesso que não acho nada agradável a ideia de ter fios pretos da sua barriga, em suma, estava desconfortável com a tarefa.

Read the rest of this post »

Apesar de discordar dessa afirmação, existem boas razões para que os profissionais considerem que o Analista de Negócios é o Product Owner e vice-versa. Faz um tempo que quero escrever sobre o assunto para a comunidade de analistas de negócios, mas como meu mapa astral mostrou, sou tanto prático quanto teórico, então esperei colocar a mão na massa do lado PO da equação, já que tenho vivido apenas do lado BA nos últimos anos.

Read the rest of this post »

A estratégia é gerada a partir de dois processos fundamentais distintos, de forma deliberada e de forma emergente. Apesar desses dois processos possuírem momentos e naturezas profundamente diferentes, é possível fazer uso de ambos de forma equilibrada, permitindo que a organização extraia o melhor de cada um no momento correto. Neste artigo, uma antiga analogia criada para facilitar a compreensão das estratégias emergentes e pregar a sua coexistência harmônica com a estratégia deliberada foi estendida e utilizada como base para a criação de um modelo visual com o objetivo de fomentar a compreensão e consequente discussão do assunto.

1- Introdução

A analogia criada por Mintzberg (1998) serviu como base para a elaboração e proposição de um modelo visual cíclico que permita o equilíbrio entre o uso das estratégias deliberadas, compatíveis com as abordagens clássica e sistêmica e o aproveitamento das estratégias emergentes, compatíveis com as abordagens evolucionária e processual. Abordagens estas apresentadas por Whittington (2002).

Além de estender a analogia, o modelo proposto no presente artigo tem como objetivo, através da simplificação de uma realidade complexa e dinâmica pela separação e sequenciação das suas partes, favorecer a compreensão e consequente crítica e discussão do modelo, eventos estes que podem trazer ainda mais luz sobre o assunto.
As abordagens estratégicas propostas por Whittington (2002) são apresentadas no item 2 com foco para as linhas imaginárias desenhadas pelo autor para criar os quadrantes representar os resultados buscados pela organização e os processos de geração da estratégia.

No item 3 é apresentado o conceito de estratégias deliberadas junto às abordagens a elas alinhadas. O mesmo ocorre no item 4, desta vez com as estratégias emergentes e suas abordagens. A analogia de Mintzberg (1998) é resumida no item 5, e o modelo proposto apresentado no item 6 de forma visual e descritiva. 

Read the rest of this post »

Para que a certificação CBAP® (Certified Business Analysis Professional) seja respeitada internacionalmente, o IIBA® definiu critérios claros (com isso não quero dizer fáceis) para que ela seja obtida.

O primeiro critério é a experiência. É necessário possuir 7.500 horas de trabalho como analista de negócios nos últimos 10 anos. É claro que nem eu, nem você provavelmente nos reconhecíamos como analistas de negócios há seis ou sete anos, mas temos que lembrar que o ponto aqui são as atividades que você exercia e não o seu cargo. As dicas para compreender quais atividades são essas estão dentro do próprio BABOK® e eu as citei neste post.

O segundo critério é conhecimento sobre pelo menos quatro das seis áreas de conhecimento do BABOK®. Isso se demonstra através de uma prova que, ainda não pode ser feita no Brasil (o IIBA SP está trabalhando para trazer a prova para cá). Neste ponto gosto de lembrar que conhecimento não significa crença absoluta. Você pode (e deve) ter suas próprias opiniões sobre a análise de negócios, mas precisa conhecer o BABOK®. Acredito ser uma obrigação do profissional conhecer seu BOK a fundo, comprar o PDF, imprimir e rabiscar. Ahh, antes que eu me esqueça, por um bom tempo, essa prova será em inglês, sem querer, transformaram inglês em uma competência fundamental do analista de negócios.

O terceiro é segundo grau completo. Não tenho muito a dizer a respeito disso, meu pai, por exemplo, não poderia se candidatar à certificação, mas acredito que não está nos planos dele. Como hoje precisamos de segundo grau para tudo, é algo meio pro forma, para diminuir a fila. Isso me lembra quando solicitavam terceiro grau para o cargo de webdesigner lá em 2000 (hoje temos cursos específicos, mas na época era para diminuir a fila mesmo).

O quarto são vinte e uma horas de treinamento em cursos relacionados à análise de negócios nos últimos quatro anos. Acho que nesse quesito o IIBA® foi bastante bondoso, são umas cinco horas por ano em média, contudo, existe um porém: esses cursos precisam ser oferecidos por Endorsed Education Providers (EEPs), algo como provedores endossados de educação. Trata-se de empresas que tiveram seus cursos avaliados pelo IIBA, seu conteúdo possui relação com as áreas de conhecimento do BABOK® ou com as competências fundamentais (veja o resumo do BABOK® para saber do que estou falando).

Read the rest of this post »

Você foi picado pela mosquinha da análise de negócios? Acredita que ela pode ajudar a resolver problemas que vem atormentando os seus projetos?

Descobriu nela um lugar para as suas habilidades de profissional de negócios que adora TI ou de profissional de TI que adora negócios?

Apesar da procura dos profissionais, há pouca informação formatada para quem está começando então pensei que um guia rápido poderia ser útil.

Como não sou muito formal, escrevi esse guia com a informalidade de uma conversa, tudo de cabeça - sem referências - só o que está fresquinho na cuca.

É um papo que eu levaria com um amigo interessado no assunto.

Convido você a ser também um amigo interessado em análise de negócios e se depois desse “papo” você tiver alguma dúvida,  envie um e-mail (kerber@kerber.com.br) ou comente aqui mesmo no site ok?

Confira as partes abaixo ou no menu ao lado:

• P1: A difícil busca por informações
• P2: O que é análise de negócios?
• P3: A Modelagem de Negócios
• P4: A Engenharia de Requisitos
• P5: Doutrinas 
• P6: Para onde vou agora?
• P7: Resumindo tudo

Faça download do PDF completo aqui.

Bem-vindo e bom proveito!

Como está escrito aqui, estou devorando o “Writing Effective Use Cases” de Alistair Cockburn. Este livro é um clássico e confesso que não sabia exatamente o que eram casos de uso antes de lê-lo.

Eu já os utilizava incentivado pelo também excelente livro UML for the IT Business Analyst: A Practical Guide to Object Oriented Requirements Gathering, de Howard Podeswa, todavia, sem noção do seu total poder.

Uma das informações mais interessantes do livro está escondida entre as recomendações do autor. Ele diz que a mágica dos casos de uso não está no fluxo básico, está nos fluxos de exceção e no seu tratamento.

A idéia é iniciar um caso de uso descrevendo o seu fluxo básico, ou seja, seu “caminho feliz”. Isso é muito tranqüilo e todos costumam saber o que o sistema deve fazer. Depois de fazê-lo, você começa a listar, isso mesmo, apenas listar os possíveis fluxos de exceção.

Segundo Cockburn, se você tentar ir tratando os fluxos de exceção assim que eles forem aparecendo, vai cansar de fazer isso e deixar vários de fora.

Depois de listar esses fluxos, você passa a trabalhar cada um deles.

Mas e a mágica?

Pois é, como disse acima, o caminho feliz todos conhecem, da mãe do cliente ao programador, ali é território amigo, tanto que os nomes dos casos de uso costumam refletir o que deve acontecer. Imagine: “Criar novo usuário“. Não tem dúvida mesmo, o cenário de sucesso é acabar o caso de uso com um novo usuário criado. Acontece que é durante o tratamento de exceções aparecem a maior parte das regras de negócio e as perguntas que, se você deixar para o programador perguntar lá na frente, na execução, vão deixar todos de cabelos em pé. Imagine de novo, fazemos o “Criar novo usuário” e não mapeamos bem as exceções. Tudo vai ok, mas na hora de implementar o programador pergunta: “O que acontece quando o usuário é estrangeiro e não possui cpf?”. CRASH-BOOM-BANG!

Você deve lembrar de algum momento semelhante na sua vida, tanto do lado de quem especifica quando do lado de quem implementa. Eu mesmo já passei por isso nas duas posições.

Aí pergunto: “Por que isso acontece?”, “Por que temos essa aversão a pensar no que pode dar errado?”.

Minha teoria é a de que estamos apaixonados, isso mesmo, apaixonados. Se você é analista de negócios ou é analista de sistemas e levanta requisitos e gosta de fazer isso deve ser como eu, se apaixona por cada novo projeto que cai nas suas mãos. Cada novo sistema ou nova versão de sistema existente é a oportunidade de modelar novas soluções que vão afetar (se possível positivamente) o dia-a-dia de áreas de negócios das nossas empresas ou dos nossos clientes.

Quando estamos apaixonados ficamos cegos, melhor, parcialmente cegos, só vemos o “cenário feliz”. É como acontece nos casamentos. Antes de casar (ou namorar sério) estamos em uma fase na qual vemos todas as possibilidades (boas). Nos vemos passeando na beira do lago, posando para fotos com o belo bebê recém chegado, passeando na praia com aquela mulher elegante e por aí vai. Ninguém tem paciência nessa hora para pensar nos cenários de exceção como: pequenas implicâncias irritantes, a interação com a família dela, os gastos excessivos com sapatos e por aí vai.

Agora chega a conclusão. É claro que não vamos deixar de curtir aquele momento gostoso de namoro novo (com a mulher e com o sistema), mas se o relacionamento é realmente importante, temos que nos prevenir e estudar os cenários de exceção e pensar em como lidar com eles para não ter que encontrar soluções de improviso quando estivermos em fase de implementação (do casamento ou do sistema).

Se pensarmos bem, os melhores casamentos não são aqueles com menos fluxos de exceção, mas sim, aqueles nos quais eles são melhor tratados.

E você, aceita este sistema para cuidar dos seus requisitos na alegria e na tristeza até que o gerente de projetos os separe?