finito

Tag: FAN

  • Delações Não Premiadas

    Delações Não Premiadas

    Meus parabéns pelo marco! Tive a honra de participar de uma das turmas do FAN em São Paulo e sei o quanto ele me ajudou a entender melhor o meu trabalho e a alavancar o desenvolvimento do sistema. Por idas e vindas da vida acabei me desligando do projeto e da área de Análise de Negócios, mas todo o conhecimento adquirido com o FAN vão continuar sempre comigo… Muito obrigado!
    – Diego “Drugue” Queiros (finito, 21/6/17)

    Como vivi e trabalhei sem este material até hoje?!
    – Pedro Walter Tang Vidal (Floripa, abr/17)

    Nos faz enxergar além dos “BOKs” com experiências verdadeiras e inspiradoras.
    – Eduardo Araujo (SJC, jan/17)

    Um dos poucos cursos “livres” que entrega o que promete.
    – Marcelo Abreu (Sampa, out/15)

    Foram 20 horas muito bem aproveitadas!
    – Fernanda Oviedo Bizarro (Floripa, mai/17)

    “O que precisa ser feito” é demonstrado de uma forma tão natural que enriquecerá qualquer profissional, seja ele analista de negócios, de testes, analista de sistemas…
    – Jairon Alves Lima (Bebedouro, set/15)

    Se a apostila fosse colorida, em papel couché e capa dura eu dava 10 🙂
    – Carlos Felipe (Rio, out/16) – deu 9!

    Parabéns por sempre incentivar a discussão e o pensamento crítico.
    – Daniel Moro de Andrade (Floripa, abr/17)

    Mostrou de forma clara e com um humor peculiar “o caminho das pedras” do verdadeiro e factível analista de negócios.
    – Domingos Vargas (Sampa, set/13)

    Muito dinâmico, prático e nada massante. Tema abordado de maneira objetiva e fomentando a vontade de aprender mais e aplicar na vida real.
    – Graziele Torres Canário (Sampa, set/13)

    Conteúdo rico, atualizado, esclarecedor e dinâmico, atingindo os objetivos propostos.
    – Ricardo Toledo (Sampa, ago/13)

    Ótima didática, ótimos exemplos. A indicação de literatura por tópicos facilita muito a busca por conhecimento.
    – Maria Bethania Almeida (BH, jun/13)

    Esta foi a primeira vez que participei de um treinamento cujo conteúdo está em linguagem não técnica. Isto é simplesmente fantástico!
    – Diego Giglio (Bebedouro, set/15)

    Os dois treinamentos do programa FAN que participei foram decisivos para minha carreira. Ajudaram no meu posicionamento frente ao mercado de trabalho, proporcionaram novos desafios profissionais e pude, de fato, utilizar praticamente todas as técnicas abordadas em situações reais, sempre com uma taxa de sucesso e aceitação altíssimas. Fruto de uma didática e conteúdo com base teórica consistente e sempre exemplificada pelas situações relatadas pelo Paulo. Recomendo!!
    – Jean Rozan Streleski (Sampa, 2008)

    Não dei 10 porque é cansativo! 🙂
    – Daniele A. Ferraz (Sampa, jul/15), deu 9

    Dinâmico, Claro, Divertido, Inspirador.
    – Erika Angelim (Sampa, mai/14)

    Foi simples, coeso e de fácil entendimento.
    – Thiago Augusto Alves (BH, abr/14)

    Realmente fantástico. É um curso que de fato muda a vida das pessoas.
    – Vagner Henrique Ferreira (Sampa, ago/14)

    Foi um evento dinâmico e fantástico; rico em detalhes.
    – Marco Moribe (Sampa, jan/08)

    Indico a nota 9 porque o treinamento sai do convencional. Superou minhas expectativas.
    – Caroline Sardi (Sampa, mar/14)

    Um dos cursos mais didáticos e dinâmicos que já fiz.
    – Jonas Raphael Schuler (Sampa, mar/14)

    Excelente dinâmica de ensino e o conteúdo é interessantíssimo.
    – Thiago Oliveira (Sampa, mar/14)

    O curso possui uma lógica muito clara e consistente.
    – Paulo Cattai (Sampa, ago/13)

    As discussões são muito ricas e ajudam a fixar o conteúdo.
    – Rodrigo Bianchetti (Sampa, jun/13)

    O Workshop pode ser definido como um banho de esclarecimento acerca do papel do Analista de negócios.
    – Rodrigo C. Maia (Sampa, jun/07)

    Atual e Necessário para os profissionais de TI. Trouxemos toda nossa equipe.
    – Umberto Nanini (Sampa, jun/07)

    Incomparável pelo ponto de vista prático e por ser guiado pela experiência.
    – Carlos M. Eastman (Sampa, 2009)

    Ótimo treinamento o Paulo Vasconcellos é um tremendo profissional e gente finíssima! Esse treinamento é o resultado de uma vida toda pesquisando e trocando ideias sobre o assunto tem muito insight bom para o dia-a-dia de quem viveu projetos de software na prática. Absolutamente recomendo.
    – Marcos Henrique Fedato (13/6/17, via LinkedIn) Participou do FAN em Jan/17.

    Eu gostei demais da experiência, foram dias em que tive muita dificuldade para dormir, inclusive, tamanha a quantidade de informações e o entusiasmo que tomou conta de mim.
    – Ramila Rossa (Floripa, mai/17)

    Como (infelizmente) pouco se vê, você Paulo é um instrutor que alia de forma brilhante um grande conhecimento e experiência com uma excepcional habilidade de transmitir tudo isso.
    – Márcio d’Ávila (BH, ago/15)

    O FAN – Formação de Analistas de Negócios está comemorando 10 anos. Esse curso sem dúvidas foi um divisor de águas em minha vida Profissional. Parabéns Paulo Vasconcellos!
    – Stanley R. Souza (Sampa, jan/17 via Facebook)

  • Delações Não Premiadas

    Delações Não Premiadas

    Meus parabéns pelo marco! Tive a honra de participar de uma das turmas do FAN em São Paulo e sei o quanto ele me ajudou a entender melhor o meu trabalho e a alavancar o desenvolvimento do sistema. Por idas e vindas da vida acabei me desligando do projeto e da área de Análise de Negócios, mas todo o conhecimento adquirido com o FAN vão continuar sempre comigo… Muito obrigado!
    – Diego “Drugue” Queiros (finito, 21/6/17)

    Como vivi e trabalhei sem este material até hoje?!
    – Pedro Walter Tang Vidal (Floripa, abr/17)

    Nos faz enxergar além dos “BOKs” com experiências verdadeiras e inspiradoras.
    – Eduardo Araujo (SJC, jan/17)

    Um dos poucos cursos “livres” que entrega o que promete.
    – Marcelo Abreu (Sampa, out/15)

    Foram 20 horas muito bem aproveitadas!
    – Fernanda Oviedo Bizarro (Floripa, mai/17)

    “O que precisa ser feito” é demonstrado de uma forma tão natural que enriquecerá qualquer profissional, seja ele analista de negócios, de testes, analista de sistemas…
    – Jairon Alves Lima (Bebedouro, set/15)

    Se a apostila fosse colorida, em papel couché e capa dura eu dava 10 🙂
    – Carlos Felipe (Rio, out/16) – deu 9!

    Parabéns por sempre incentivar a discussão e o pensamento crítico.
    – Daniel Moro de Andrade (Floripa, abr/17)

    Mostrou de forma clara e com um humor peculiar “o caminho das pedras” do verdadeiro e factível analista de negócios.
    – Domingos Vargas (Sampa, set/13)

    Muito dinâmico, prático e nada massante. Tema abordado de maneira objetiva e fomentando a vontade de aprender mais e aplicar na vida real.
    – Graziele Torres Canário (Sampa, set/13)

    Conteúdo rico, atualizado, esclarecedor e dinâmico, atingindo os objetivos propostos.
    – Ricardo Toledo (Sampa, ago/13)

    Ótima didática, ótimos exemplos. A indicação de literatura por tópicos facilita muito a busca por conhecimento.
    – Maria Bethania Almeida (BH, jun/13)

    Esta foi a primeira vez que participei de um treinamento cujo conteúdo está em linguagem não técnica. Isto é simplesmente fantástico!
    – Diego Giglio (Bebedouro, set/15)

    Os dois treinamentos do programa FAN que participei foram decisivos para minha carreira. Ajudaram no meu posicionamento frente ao mercado de trabalho, proporcionaram novos desafios profissionais e pude, de fato, utilizar praticamente todas as técnicas abordadas em situações reais, sempre com uma taxa de sucesso e aceitação altíssimas. Fruto de uma didática e conteúdo com base teórica consistente e sempre exemplificada pelas situações relatadas pelo Paulo. Recomendo!!
    – Jean Rozan Streleski (Sampa, 2008)

    Não dei 10 porque é cansativo! 🙂
    – Daniele A. Ferraz (Sampa, jul/15), deu 9

    Dinâmico, Claro, Divertido, Inspirador.
    – Erika Angelim (Sampa, mai/14)

    Foi simples, coeso e de fácil entendimento.
    – Thiago Augusto Alves (BH, abr/14)

    Realmente fantástico. É um curso que de fato muda a vida das pessoas.
    – Vagner Henrique Ferreira (Sampa, ago/14)

    Foi um evento dinâmico e fantástico; rico em detalhes.
    – Marco Moribe (Sampa, jan/08)

    Indico a nota 9 porque o treinamento sai do convencional. Superou minhas expectativas.
    – Caroline Sardi (Sampa, mar/14)

    Um dos cursos mais didáticos e dinâmicos que já fiz.
    – Jonas Raphael Schuler (Sampa, mar/14)

    Excelente dinâmica de ensino e o conteúdo é interessantíssimo.
    – Thiago Oliveira (Sampa, mar/14)

    O curso possui uma lógica muito clara e consistente.
    – Paulo Cattai (Sampa, ago/13)

    As discussões são muito ricas e ajudam a fixar o conteúdo.
    – Rodrigo Bianchetti (Sampa, jun/13)

    O Workshop pode ser definido como um banho de esclarecimento acerca do papel do Analista de negócios.
    – Rodrigo C. Maia (Sampa, jun/07)

    Atual e Necessário para os profissionais de TI. Trouxemos toda nossa equipe.
    – Umberto Nanini (Sampa, jun/07)

    Incomparável pelo ponto de vista prático e por ser guiado pela experiência.
    – Carlos M. Eastman (Sampa, 2009)

    Ótimo treinamento o Paulo Vasconcellos é um tremendo profissional e gente finíssima! Esse treinamento é o resultado de uma vida toda pesquisando e trocando ideias sobre o assunto tem muito insight bom para o dia-a-dia de quem viveu projetos de software na prática. Absolutamente recomendo.
    – Marcos Henrique Fedato (13/6/17, via LinkedIn) Participou do FAN em Jan/17.

    Eu gostei demais da experiência, foram dias em que tive muita dificuldade para dormir, inclusive, tamanha a quantidade de informações e o entusiasmo que tomou conta de mim.
    – Ramila Rossa (Floripa, mai/17)

    Como (infelizmente) pouco se vê, você Paulo é um instrutor que alia de forma brilhante um grande conhecimento e experiência com uma excepcional habilidade de transmitir tudo isso.
    – Márcio d’Ávila (BH, ago/15)

    O FAN – Formação de Analistas de Negócios está comemorando 10 anos. Esse curso sem dúvidas foi um divisor de águas em minha vida Profissional. Parabéns Paulo Vasconcellos!
    – Stanley R. Souza (Sampa, jan/17 via Facebook)

  • Dez Anos de FAN

    Dez Anos de FAN

    Hoje o programa FAN – Formação de Analistas de Negócios – completa dez anos de estrada. Um marco não planejado. Confesso, no texto que segue, que até tentei matar minha malhada vaquinha leiteira. Por sorte não consegui. Agora, junto com a comemoração, chegam novos desafios.

    Era uma vez…

    No segundo semestre de 2006 eu estava mais perdido que político safado em tempos de delações premiadas. Prestes a completar o primeiro ano de carreira solo, ainda não tinha um conjunto bem definido de ofertas. “Consultoria” é um balaio que aceita qualquer coisa e, pelo visto, qualquer um. Eu precisava de um abridor de latas e portas. Num belo dia, em um grupo de discussão, alguém¹ escreveu que “analistas de negócios não agregavam porcaria nenhuma para o projeto”. Era tudo o que eu precisava.

    Em junho de 2007 apresentei, em São Paulo, a primeira edição do FAN. Um palestrão com sete horas de duração disfarçado de oficina. Agradou. Abriu portas. E o que aprendi nos últimos dez anos é muito mais do que havia colecionado nos vinte anos anteriores. Nessa década, quase tudo no programa mudou. Exceto um princípio e dois pilares.

    Que ? Como

    O princípio que quebra gelos é uma citação de Fred Brooks²: “A correta definição sobre o que precisa ser feito é a etapa mais difícil da construção de um sistema. Nenhuma outra compromete tanto um projeto quando mal executada. E nenhuma é mais difícil de ser corrigida.”

    Rabisco dois círculos. O primeiro representa o QUE, o outro o COMO. O primeiro é o Domínio do Problema, território dos analistas de negócios. O segundo, Domínio da Solução, grande área dos analistas de sistemas e desenvolvedores. Coisa boba – simples – que na pré-história do FAN foi espinafrada por alguns. Hoje me divirto quando vejo papos modernos sobre “duas trilhas, design e desenvolvimento”, “User Stories devem ser separadas entre QUE e COMO” e por aí vai.

    Dois Pilares

    Os dois pilares do FAN são duas disciplinas: Modelagem de Negócios e Engenharia de Requisitos. Infelizmente, repito até hoje que a primeira é a mais mal tratada que conheço. Maltratada porque merece poucos estudos, livros, artigos etc. A área avançou, fora do domínio de TI, nos trabalhos de gente como Dan Roam, Alexander Osterwalder, Dave Gray, Sunni Brown e David Sibbet, dentre outros. Mas é pouco e muito pobre em termos de base teórica. Faltam consistência, coesão e ambição. Mas é muito mais do que é oferecido pelo pessoal de TI.  Todas as turmas do FAN pós-palestrão foram convidadas a modelar à mão. Porque só modelando e abstraindo podemos entender, explicar, domar ou pelo menos dançar³ com esses sistemas complexos chamados “negócios”.

    A Engenharia de Requisitos, por sua vez, é rica em livros, artigos, palestras e… tropeços.
    Pare e pense um pouquinho no termo “Requisito Não-Funcional”. Pense como um leigo.
    Horrível, não? E você vai elicitá-lo (sic), eliciá-lo ou coletá-lo? Por que insistimos em verbos e substantivos tão desastrados? E o que dizer da interpretação de REQUISITO como sendo um “entregável” (sic) ou uma “representação utilizável de uma necessidade”? Puxa, nosso dicionário diz apenas que requisito “é uma condição necessária para alcançar determinado fim”. Para que complicar?

    Compreender fins e meios; Conhecer e se comprometer com as pessoas envolvidas; Ajudá-las a resolver problemas. É disso que trata a Análise de Negócios. Não é pouca coisa.

    Fracassos Retumbantes

    Por muitos anos tive que responder a seguinte questão: “e o seu livro, já saiu?” A primeira apostila do FAN era um ensaio de quase 100 páginas que tinha jeito de livro. Ingênuo, prometi a sua publicação dezenas de vezes. E elaborei planos mil, até uma gráfica on-demand. Pivotei (sic), sem vergonha nem piedade. Não era hora, não era o assunto. Não era negócio.

    Assim como não foram bons negócios diversos derivados do FAN: FAN4Scrum, FDP (Formação de Donos de Produtos), Scrum para Negócios, FAN +Ágil… Experimentos que nunca mereceram mais de quatro edições. Do ponto de vista financeiro, foram mesmo belos tombos. Usando outras perspectivas – aprendizagem e viagens – não tenho do que reclamar.

    Uma Tentativa de Assassinato

    Há pouco mais de dois anos tentei matar o FAN. Por diversas razões, achei que passava de hora de dar um fim honroso para o programa. Cheguei a procurar um concorrente e propor um debate que se encerraria de forma dramática – com sangue! Ele não topou, eu desisti da ideia e o FAN ganhou roupa e propósito novos.

    Tirei do esperançoso flit o conceito de trabalhos a executar e redesenhei o FAN como um conjunto de oito trabalhos essenciais. A vaquinha leiteira virou ponta de lança de um ambicioso projeto: ajudar a formar sete bilhões de pensadores sistêmicos.

    Planos

    Reli alguns posts antigos deste finito. No início do FAN eu publicava rendicontis (prestações de contas). Acho que transparência ajudou o produto. Por outro lado, os planos e promessas não realizados ainda me deixam sem jeito. Além disso, está na moda dizer que “planejar” é trabalho inútil. O pós-moderno “deixa a vida lhe levar”. Não caio nessa. Aliás, acho que ninguém cai. Por curta que seja a viagem, você antevê a rota.

    Pedestre na contramão não atrapalha quase ninguém. Por isso meu terceiro lançamento deste ano vai cuidar da disciplina que, como disse acima, é muito mal tratada: a Modelagem de Negócios. Na próxima terça-feira (27/6) lançarei formalmente o produto, numa aula aberta e gratuita: Imagens da Organização.

    E o FAN? Oras, segue vivo e em frente. Com uma edição comemorativa – no formato clássico – acontecendo em São Paulo nos dias 30/6 e 1/7.

    Agradecimentos

    Se eu colocar um nome aqui cometerei injustiças mil. Na edição comemorativa, mesmo com quórum mínimo, alcançarei a marca de cinco mil participantes. Cada um, de um jeito ou de outro, ajudou o FAN a chegar até aqui. Para todos, sem exceção, o meu muito obrigado.

    Notas

    1. O santo em questão um dia me pediu que eu parasse de contar essa história. Porque sua frase estava fora de contexto. Escondo o santo, mas não o milagre. Dentro ou fora do contexto, o fato é que aquela frase me trouxe até aqui.
    2. A colocação original do Brooks aparece no artigo “No Silver Bullet”, de 1986. Este artigo e outros aparecem na edição comemorativa de 25 anos do livro O Mítico Homem-Mês (Campus, 2009).
    3. Donella Meadows é quem trata com mais delicadeza um tema duro e difícil, o Pensamento Sistêmico. Se não por outro motivo, a simples sugestão para aprendermos a “dançar com sistemas” é um convite e tanto para conhecer sua obra póstuma Thinking in Systems – A Primer (Chelsea Green Publishing, 2008).
    4. 10, fotografia de Leo Reynolds, ilustra este artigo.
  • Dez Anos de FAN

    Dez Anos de FAN

    Hoje o programa FAN – Formação de Analistas de Negócios – completa dez anos de estrada. Um marco não planejado. Confesso, no texto que segue, que até tentei matar minha malhada vaquinha leiteira. Por sorte não consegui. Agora, junto com a comemoração, chegam novos desafios.

    Era uma vez…

    No segundo semestre de 2006 eu estava mais perdido que político safado em tempos de delações premiadas. Prestes a completar o primeiro ano de carreira solo, ainda não tinha um conjunto bem definido de ofertas. “Consultoria” é um balaio que aceita qualquer coisa e, pelo visto, qualquer um. Eu precisava de um abridor de latas e portas. Num belo dia, em um grupo de discussão, alguém¹ escreveu que “analistas de negócios não agregavam porcaria nenhuma para o projeto”. Era tudo o que eu precisava.

    Em junho de 2007 apresentei, em São Paulo, a primeira edição do FAN. Um palestrão com sete horas de duração disfarçado de oficina. Agradou. Abriu portas. E o que aprendi nos últimos dez anos é muito mais do que havia colecionado nos vinte anos anteriores. Nessa década, quase tudo no programa mudou. Exceto um princípio e dois pilares.

    Que ? Como

    O princípio que quebra gelos é uma citação de Fred Brooks²: “A correta definição sobre o que precisa ser feito é a etapa mais difícil da construção de um sistema. Nenhuma outra compromete tanto um projeto quando mal executada. E nenhuma é mais difícil de ser corrigida.”

    Rabisco dois círculos. O primeiro representa o QUE, o outro o COMO. O primeiro é o Domínio do Problema, território dos analistas de negócios. O segundo, Domínio da Solução, grande área dos analistas de sistemas e desenvolvedores. Coisa boba – simples – que na pré-história do FAN foi espinafrada por alguns. Hoje me divirto quando vejo papos modernos sobre “duas trilhas, design e desenvolvimento”, “User Stories devem ser separadas entre QUE e COMO” e por aí vai.

    Dois Pilares

    Os dois pilares do FAN são duas disciplinas: Modelagem de Negócios e Engenharia de Requisitos. Infelizmente, repito até hoje que a primeira é a mais mal tratada que conheço. Maltratada porque merece poucos estudos, livros, artigos etc. A área avançou, fora do domínio de TI, nos trabalhos de gente como Dan Roam, Alexander Osterwalder, Dave Gray, Sunni Brown e David Sibbet, dentre outros. Mas é pouco e muito pobre em termos de base teórica. Faltam consistência, coesão e ambição. Mas é muito mais do que é oferecido pelo pessoal de TI.  Todas as turmas do FAN pós-palestrão foram convidadas a modelar à mão. Porque só modelando e abstraindo podemos entender, explicar, domar ou pelo menos dançar³ com esses sistemas complexos chamados “negócios”.

    A Engenharia de Requisitos, por sua vez, é rica em livros, artigos, palestras e… tropeços.
    Pare e pense um pouquinho no termo “Requisito Não-Funcional”. Pense como um leigo.
    Horrível, não? E você vai elicitá-lo (sic), eliciá-lo ou coletá-lo? Por que insistimos em verbos e substantivos tão desastrados? E o que dizer da interpretação de REQUISITO como sendo um “entregável” (sic) ou uma “representação utilizável de uma necessidade”? Puxa, nosso dicionário diz apenas que requisito “é uma condição necessária para alcançar determinado fim”. Para que complicar?

    Compreender fins e meios; Conhecer e se comprometer com as pessoas envolvidas; Ajudá-las a resolver problemas. É disso que trata a Análise de Negócios. Não é pouca coisa.

    Fracassos Retumbantes

    Por muitos anos tive que responder a seguinte questão: “e o seu livro, já saiu?” A primeira apostila do FAN era um ensaio de quase 100 páginas que tinha jeito de livro. Ingênuo, prometi a sua publicação dezenas de vezes. E elaborei planos mil, até uma gráfica on-demand. Pivotei (sic), sem vergonha nem piedade. Não era hora, não era o assunto. Não era negócio.

    Assim como não foram bons negócios diversos derivados do FAN: FAN4Scrum, FDP (Formação de Donos de Produtos), Scrum para Negócios, FAN +Ágil… Experimentos que nunca mereceram mais de quatro edições. Do ponto de vista financeiro, foram mesmo belos tombos. Usando outras perspectivas – aprendizagem e viagens – não tenho do que reclamar.

    Uma Tentativa de Assassinato

    Há pouco mais de dois anos tentei matar o FAN. Por diversas razões, achei que passava de hora de dar um fim honroso para o programa. Cheguei a procurar um concorrente e propor um debate que se encerraria de forma dramática – com sangue! Ele não topou, eu desisti da ideia e o FAN ganhou roupa e propósito novos.

    Tirei do esperançoso flit o conceito de trabalhos a executar e redesenhei o FAN como um conjunto de oito trabalhos essenciais. A vaquinha leiteira virou ponta de lança de um ambicioso projeto: ajudar a formar sete bilhões de pensadores sistêmicos.

    Planos

    Reli alguns posts antigos deste finito. No início do FAN eu publicava rendicontis (prestações de contas). Acho que transparência ajudou o produto. Por outro lado, os planos e promessas não realizados ainda me deixam sem jeito. Além disso, está na moda dizer que “planejar” é trabalho inútil. O pós-moderno “deixa a vida lhe levar”. Não caio nessa. Aliás, acho que ninguém cai. Por curta que seja a viagem, você antevê a rota.

    Pedestre na contramão não atrapalha quase ninguém. Por isso meu terceiro lançamento deste ano vai cuidar da disciplina que, como disse acima, é muito mal tratada: a Modelagem de Negócios. Na próxima terça-feira (27/6) lançarei formalmente o produto, numa aula aberta e gratuita: Imagens da Organização.

    E o FAN? Oras, segue vivo e em frente. Com uma edição comemorativa – no formato clássico – acontecendo em São Paulo nos dias 30/6 e 1/7.

    Agradecimentos

    Se eu colocar um nome aqui cometerei injustiças mil. Na edição comemorativa, mesmo com quórum mínimo, alcançarei a marca de cinco mil participantes. Cada um, de um jeito ou de outro, ajudou o FAN a chegar até aqui. Para todos, sem exceção, o meu muito obrigado.

    Notas

    1. O santo em questão um dia me pediu que eu parasse de contar essa história. Porque sua frase estava fora de contexto. Escondo o santo, mas não o milagre. Dentro ou fora do contexto, o fato é que aquela frase me trouxe até aqui.
    2. A colocação original do Brooks aparece no artigo “No Silver Bullet”, de 1986. Este artigo e outros aparecem na edição comemorativa de 25 anos do livro O Mítico Homem-Mês (Campus, 2009).
    3. Donella Meadows é quem trata com mais delicadeza um tema duro e difícil, o Pensamento Sistêmico. Se não por outro motivo, a simples sugestão para aprendermos a “dançar com sistemas” é um convite e tanto para conhecer sua obra póstuma Thinking in Systems – A Primer (Chelsea Green Publishing, 2008).
    4. 10, fotografia de Leo Reynolds, ilustra este artigo.
  • Os 8 Trabalhos do Analista de Negócios

    Os 8 Trabalhos do Analista de Negócios

    Há quem veja a análise de negócios como algo pequenininho – uma breve e chata etapa que antecede a construção de uma solução. Outros temem que ela esteja se tornando um monstro imenso. Todos nós – praticantes, evangelistas e rolando leros – temos culpa no cartório. Especialmente no caso do monstro. A área nunca precisou dos exageros que foram cometidos. Nunca pediu por adendos meio esotéricos ao seu corpo de conhecimentos. Que tal um retorno ao básico?

    Um Método

    Não importa se sua empresa usa Scrum, DevOps, Kanban, um combo de boas práticas ou o velho conhecido go horse. A Análise de Negócios merece um método pra chamar de seu. Um método com três características principais:

    • Flexibilidade: para lidar com problemas de qualquer natureza. Ênfase em qualquer natureza, por favor. Não servimos apenas TI.
    • Interoperabilidade: a Análise de Negócios não existe por si só. Seu método deve combinar muito bem com qualquer outro utilizado pela organização.
    • Integridade: para fazer o serviço completo. A correta delimitação da Análise de Negócios é um problema recorrente. Mais sobre isso abaixo.

    Quatro Etapas

    Não precisamos reinventar rodas. Quais áreas mais avançaram quando o assunto é método de trabalho? Tem essa que você pensou. E tem o Design Thinking. Área que lida com uma variedade de problemas equivalente ou maior do que a nossa. Seu losango duplo (Double Diamond) nos serve como uma luva ao propor quatro etapas bem nítidas:

    • Descoberta: Houston, temos um problema!
      E a correta identificação do problema faz parte do problema. Assim como a descoberta e mapeamento de todos os envolvidos.
    • Exploração: Cabral não fazia ideia do que tinha descoberto.
      É explorando – estudando o contexto e desenvolvendo requisitos – que ganhamos a exata noção do que precisa e do que pode ser feito.
    • Desenvolvimento: A construção, enfim!
      Selecionada a melhor alternativa de solução, é hora de desenvolvê-la. E o bom analista de negócios participa da construção, como não?
    • Entrega: Ou o fatídico encontro com o mundo real.
      O ambiente deve ser preparado. Os afetados devem ser amparados. E nós devemos estar prontos para as inevitáveis mudanças. Falemos, portanto, de entregas – no plural.

    Oito Trabalhos

    Há tempo é uma guerra delimitar com precisão as responsabilidades do analista de negócios. De onde se esperava assertividade veio muita ambiguidade. E a confusão proliferou. Gerenciamento de Projetos, Análise de Sistemas e, pasmem, até Suporte são áreas “invadidas” por analistas de negócios sem bússola. Por isso é tão importante fixar os trabalhos essenciais da Análise de Negócios. Eles são oito, dois em cada etapa descrita acima:

    • Entender os Objetivos do Projeto
      Conhecer o problema a ser resolvido ou a oportunidade a ser aproveitada. Enfim, buscar a resposta para a primeira grande pergunta: Por que o projeto é necessário? Sem resposta não há projeto. Sobra um papo de malucos… projeto não.
    • Conhecer as Pessoas Envolvidas
      Quem será afetado por aquela mudança? Quem poderá influenciar o projeto? O mapeamento é simples. E é crucial para o sucesso do projeto. Porque, no final das contas, são as pessoas que vão aprová-lo ou não.
    • Estudar o Contexto
      Quais áreas do negócio serão afetadas? Quais processos estão envolvidos? Há necessidade de mudanças em políticas e regras? É neste trabalho que desenhamos os mapas que vão orientar todo o desenvolvimento do projeto.
    • Desenvolver Requisitos
      Mapas em mãos, hora de traçar o caminho. E é sempre bom lembrar: requisitos são condições para alcançar determinado fim. O fim foi demarcado lá em cima, no primeiro trabalho. Agora estudamos as condições para alcançá-lo. Repare que o analista DESENVOLVE requisitos. Não coleta, não levanta nem elicita (sic).
    • Avaliar Alternativas de Solução
      Porque todo problema tem mais de uma solução. Inclusive a não solução! O analista facilita o debate. Rico e importante que é, difícil explicar a razão de ser tão negligenciado.
    • Apoiar o Desenvolvimento
      E isso não significa empurrar uma montanha de entregáveis (sic) para o time de construção. Analistas de negócios participam ativamente do desenvolvimento, testando a solução e gerando, diariamente, informações para todo o time.
    • Preparar o Ambiente
      Ajudar as pessoas que terão seu cotidiano afetado por aquela mudança. As treinamos, sim. Mas, em alguns casos, é a preparação emocional a que mais importa. Não são poucos os projetos que pecam nesse ponto. E depois ajudam a propagar a tal “resistência às mudanças”.
    • Acompanhar o Uso da Solução
      Porque alteramos o contexto e, inevitavelmente, mudanças ocorrerão. Dizer que o cliente não sabe o que quer é apelar para uma desculpa simples e quase sempre equivocada. O bom analista entende que entre a(s) entrega(s) e o término oficial de um projeto há mais coisas do que informa aquele bonito gráfico Gantt.

    Que fique claro: os trabalhos acima não são exclusivos do analista de negócios. A cada etapa ele está apoiando alguém, trabalhando com alguém. Sejam os clientes e usuários, sejam gerentes de projetos ou desenvolvedores, não importa. O que interessa aqui é a afirmação: o bom analista de negócios domina os trabalhos acima.

    Depois, claro, ele vai acrescentar outras responsabilidades. Se trabalha em empresa de prestação de serviços, por exemplo, lhe interessa aprender a Elaborar Propostas. Se está em uma startup desenvolvendo o próximo killer app, vai elaborar uma etapa de exploração bem diferente – livre para criar. Enfim, uma vez dominado o essencial, o analista vai agregar novas atribuições, técnicas e ferramentas.

    Infinitas Técnicas e Ferramentas

    JTBD¹ (Jobs to be Done) ou Trabalhos a Executar. É a ferramenta-conceito que norteou o desenvolvimento da sugestão apresentada acima. O analista deve dominar o que precisa ser feito. Ou seja, ele compreende a motivação para aquele trabalho e a teoria que o embala. E é um atento colecionador de técnicas e ferramentas que o ajudam a executar seus trabalhos. A riqueza de seu cinto de utilidades reflete a complexidade do nosso tempo. Porque, como ensina a Lei de Ashby, “só a variedade absorve variedade”.

    O que não significa entulhar o corpo de conhecimentos com modelos e modas que só criam confusão. Antes de qualquer coisa, façamos BEM o essencial.

    Notas

    1. JTBD é uma ferramenta-conceito apresentada por Clayton M. Christensen para provocar inovações. Serve para desenhar produtos e serviços. E serve para desenhar funções e profissões. A ideia combina bem com o que foi apresentado no artigo O Futuro das Profissões.
    2. Project Infinity é o nome da imagem utilizada. Compartilhada por woodleywonderworks via flickr.
  • 7 Habilidades Essenciais do Analista de Negócios

    7 Habilidades Essenciais do Analista de Negócios

    Visão do Todo

    Em um mundo cada vez mais imediatista e cheio de gente focada¹ no próprio umbigo, é preciso alguém que veja o lá e o amanhã além do aqui e agora. O analista sabe que melhorias locais podem piorar o resultado global. Entende que mudanças, por melhores que sejam, sempre vão desagradar alguém. Ele precisa enxergar o todo.

    Se vai chamar isso de análise de impacto ou gestão de mudanças não faz muita diferença. Mas a adição do Pensamento Sistêmico ao seu cinto de utilidades não é nada menos que fundamental.

    Imparcialidade

    Se o analista tomar partido – ficando sempre na defesa de uma das partes envolvidas – condena todo o seu trabalho. Empatia não significa apoio incondicional. O que deve nortear suas decisões e sugestões são os objetivos do negócio e de cada projeto. Nada além disso².

    Pragmatismo

    É natural, portanto, que o analista seja bastante pragmático. Se há um objetivo colocado e em dado momento acordado, é pra lá que ele vai. Se surgiu alguma discordância em relação ao objetivo, é ela que ele tenta entender e desfazer. Se não há um objetivo e ninguém sabe para onde vai, o analista pragmático briga pela sua definição. Se ele perder a briga, sai em busca de outra.

    Saber Ouvir

    Qualidade cada vez mais rara. Saber ouvir não é saber esperar a vez de falar. É prestar atenção e demonstrar respeito. É entender que cada vírgula, expressão corporal ou suspiro pode conter informação. Por isso o analista ouve com os olhos pregados em seu interlocutor e não em um bloco de anotações. Ele sabe que 75% das informações não estão nas palavras que são ditas. Seus olhos captam mais que os ouvidos. Seus olhos o ajudam a ouvir direito.

    Modelagem

    Quanto tempo você demora para entender o significado da seguinte definição: “superfície plana limitada por uma circunferência, cujos pontos são equidistantes do centro”?

    Não importa, você teria sido bem mais rápido se eu tivesse simplesmente desenhado um círculo³. Nosso cérebro é melhor equipado para processar imagens do que palavras. É por isso que o analista rabisca e desenha o tempo todo. É por isso que a Modelagem de Negócios não pode ser um apêndice ou puxadinho no corpo de conhecimentos do analista de negócios. Se o nosso grande desafio é promover comunicações eficazes, saber modelar é imprescindível.

    Síntese

    O analista não se deixa enganar pela incompleta alcunha que recebeu. Ele não faz só exames e estudos. Sua análise não significa nada – não agrega valor algum – quando não é seguida da síntese. Pelo pai dos burros, síntese é a reunião de diversas partes diferentes em um todo coerente. Para o analista, na prática, significa colocar seu cérebro para trabalhar. Síntese não é resumo nem coletânea de melhores momentos. Síntese é criação. Se ela não ocorreu, então o cara tirou um pedido. E isso não tem nada a ver com análise (e síntese) de negócios.

    Comprometimento

    Que graça tem o trabalho que se encerra nas preliminares? E quão eficaz pode ser uma documentação – por bons modelos que contenha – se desacompanhada de seu autor? O papel ou qualquer meio mais moderno, digital, não consegue capturar todo o conhecimento adquirido e desenvolvido por um analista. É triste insistir nisso até hoje. Mas o analista só prova seu valor quando participa de cabo a rabo de qualquer iniciativa ou projeto. Sua disponibilidade para quem está criando a solução significa conhecimento transferido em tempo real via banda larga. Sua participação nos testes significa qualidade. E quem melhor do que ele para preparar o ambiente que receberá as mudanças? Enfim, o analista termina o que começou. Mais que isso: se compromete com a qualidade da entrega. Ciente de que cada entrega causa novos desarranjos e mais oportunidades de aprendizado e melhoria.

    Conta de Mentiroso

    Aqui no interior de Minas se diz que 7 é conta de mentiroso. Por isso preciso citar uma oitava habilidade essencial: o analista de negócios gosta de gente. Ele é um animal social e incorpora todas aquelas qualidades que costumamos chamar de “habilidades sociais”. Ficou por último mas, dentre todas listadas acima, esta é a habilidade mais importante que um analista de negócios precisa mostrar. Gostar de gente é seu ponto de partida.

    Há exatos 7 anos o FAN era lançado. Muita coisa mudou desde então. Menos a essência da Análise de Negócios. Este artigo é uma pequena comemoração.

    Notas

    1. Só utilizei o termo focada porque a intenção era ilustrar algo ridículo. Metacrítica?
    2. Mas, se você quiser ou precisar, inclua aqui ética, honestidade e outras questões morais.
    3. Exercício proposto por Penny Pullan e Vanessa Randle em Business Analysis and Leadership (Kogan Page, 2013).
    4. Seven about to happen three different ways, de John Watson, ilustra este artigo.
  • Três Meses em Um Post

    Três Meses em Um Post

    Quando sumo daqui, podes crer, é porque estou desenvolvendo e distribuindo meu palavrório em outros meios. Minhas resistentes hérnias de disco me custaram todo o segundo semestre do ano passado. Por isso estou, literalmente, correndo atrás do prejuízo. Prejuízo que não é – nunca é – apenas financeiro. As ideias e sugestões apresentadas na forma de artigos durante todo 2012 careciam de ar, de contato com a vida real. Precisavam de feedback – de confirmação. Apresento neste artigo meus achados e perdidos.

    Arquitetura de Negócios

    A série Pensando Negócios foi condensada em uma palestra com cerca de noventa minutos de duração. Tive a oportunidade de apresentá-la em Belo Horizonte e São Paulo. Quando nem o título da palestra é uma certeza – “Arquitetura de Negócios” ou “Criando Negócios em Tempos Difíceis”? – qualquer retorno é bem vindo. Foram duas as minhas motivações: 1) Validar o Conteúdo; e 2) Confirmar a viabilidade de um evento maior, em formato oficina (workshop). Conclusão? O tema gera considerável interesse, apesar da notável nebulosidade que o cerca.

    Sigo dependendo de mais testes. Antes, trabalharei em nova versão do tabuleiro. Ele precisa se tornar uma ferramenta que sintetize todos os principais conceitos apresentados. Para tanto, é mais que necessário que ele consiga exprimir comportamento e não só a estrutura de um negócio. Será um desafio e tanto. E uma boa maneira de aprender mais.

    A Empresa ConectadaPor falar em aprender, saiu por aqui A Empresa Conectada (Novatec, 2013), de Dave Gray. Por beber nas mesmas fontes (Hamel, Ackoff, Senge, Geus, Takeuchi & Nonaka etc) e trazer o pensamento sistêmico para a cumbuca dos negócios, será referência obrigatória em meu trabalho. Dave Gray, que eu só conhecia pela co-autoria de Gamestorming (que também saiu por aqui, pela Alta Books), surpreende com um livro consistente, bem fundamentado e muito direto:

    “Quanto mais à prova de idiotas for o sistema, mais as pessoas agirão como idiotas.”

    “Clientes felizes são o melhor departamento de marketing que qualquer empresa poderia ter.”

    “Liderança é trabalhar com pessoas. Gerenciamento é trabalhar com sistemas.”

    “As pessoas trabalham mais arduamente quando têm paixão pelo trabalho e estão comprometidas com o sucesso. Elas ficam motivadas a realizar quando estão conectadas com o propósito do trabalho, quando entendem o sistema – de que maneira todas as peças e partes se encaixam – e quando têm o poder de melhorá-lo.”

    O Novo Novo FAN

    Tem pouco mais de um ano que liberei a nova versão do programa {FAN} Formação de Analistas de Negócios com quatro módulos. Não posso culpar apenas minhas hérnias pelo fato de não ter testado de maneira adequada o novo formato. Não é fácil vender novos programas de treinamento. Ainda mais quando se usa nomes como {FAN} +Conversas! Mas, apesar dos pesares, tudo o que fiz nas últimas dez semanas foi testar e testar e testar o novo conteúdo. Para tanto, o apresentei em duas turmas abertas e três turmas fechadas. Nas turmas abertas aprendi que a separação entre +Requisitos e +Conversas não faz muito sentido, mesmo que boa parte do público insista em dizer que quer “só requisitos”. A boa notícia é que os módulos já foram desenhados de forma a facilitar um merge (sic). Experimentei a combinação, com carga horária reduzida, em uma turma de pós-graduação da Federal de São Carlos. O resultado foi bastante positivo.

    No entanto, eu precisava de mais problemas de verdade – precisava de testes que só são possíveis em empresas. Ganhei oportunidades em uma grande empresa da área financeira e outra que presta serviços de pesquisa e desenvolvimento combinando hardware e software. Não podia querer maior diversidade. Posso dizer que o FAN “aguentou o tranco”.

    A sequência da série sobre Requisitos e Conversas dependia desta generosa bateria de testes. Espero retomá-la em breve e farei o possível para concluí-la até junho. Também em junho retomarei as turmas abertas, com o FAN refletindo essas dez semanas de aprendizado. Para comemorar seis anos de vida, o programa virá com uma série de novidades.

    O Velho finito

    Agora em maio o finito completa nove anos de existência. Não são muitos os blogs que podem se preparar para comemorar o décimo aniversário. Elaborei uma listinha com coisas que este espaço pode ser/ter. Mas, antes de colocar a mão na massa, eu queria merecer algumas sugestões de minha meia dúzia de leitores. O que você gostaria de ler/ver por aqui? Quais temas devem merecer mais espaço? O que você faria de diferente?

    Agradecimentos

    Simone, Angelita, Ariane, Jaqueline, Valesca, Érica, Igor, Jean, Renato, Célio, Feio, Alberto, Carlos, Andrei, Anderson, Rodrigo, Fernando, Paulo… sei que cometo injustiças quando tento me lembrar todos que apoiaram os eventos dos últimos três meses. O fato é que não me esqueço de todos que fizeram um esforço extra, seja nos necessários feedbacks, seja por divulgar meu trabalho ou por topar viagens e outros sacrifícios. Minha dívida com vocês só faz crescer.

    Three Things, a imagem que ilustra este artigo, é do conskeptical.

     

  • BA Brazil 2011: Balanço, Reflexos e Reflexões

    BA Brazil 2011: Balanço, Reflexos e Reflexões

    Aconteceu na última semana, em Porto Alegre, a 1ª Conferência Brasileira de Análise de Negócios – o BA Brazil 2011. Transcrevo neste artigo minhas experiências e considerações sobre o evento. E trago para cá conversas e provocações que, acredito, merecem reflexões e debates.

    ?

    Se fosse preciso resumir tudo em uma única palavra ela seria: Show! Show de organização. Show diversificado. Show com lotação praticamente esgotada. O BA Brazil provou a força da comunidade e como o trabalho voluntário move e remove montanhas. Se alguém ainda tem dúvidas sobre a combinação dos termos “planejamento” e “métodos ágeis” ou sobre a utilização dos últimos fora da seara do desenvolvimento de sistemas é porque não viu o BA Brazil. Créditos para o time do IIBA e todos os parceiros que ajudaram a viabilizar o evento. Evito citar nomes para não cometer nenhuma injustiça. Todos estão de parabéns.

    Infelizmente, por problemas de agenda, não pude ver praticamente nada dos dois dias de palestras e espaços abertos. Mas tive tempo suficiente para rever amigos de Brasília, Floripa, Sampa e Rio. E, claro, pude assistir a palestra de abertura ministrada por Shane Hastie. Shane explicou “porque precisamos de Análise em Projetos Ágeis”. Você acha estranho que esse tipo de “explicação” ainda seja necessária? Eu achava. Mas a conversa do Shane foge do lugar comum. E mira dois alvos: também fala sobre métodos ágeis para analistas de negócios. Seu discurso é sereno, objetivo e bem ilustrado. Seria impossível e injusto destacar algum ponto. Prefiro resumir assim: eu queria que mais executivos e agilistas tivessem a oportunidade de ouvir e conversar com Shane. Só isso.

    Eu tive essa oportunidade, em cafés, viagens de táxi e jantares. E as primeiras coisas que você nota em Shane, além do profundo conhecimento dos temas que aborda, são sua humildade e generosidade. Em questão de pouquíssimas horas “viajávamos” pelas necessárias revisões do BABoK®, a sentida ausência dos casos de uso no draft da extensão ágil¹, a corrupção no Brasil (e suas similaridades com a África do Sul, país onde Shane morou por alguns anos), a beleza das mulheres de Porto Alegre, churrasco, caipirinhas (with two you get to the limit of liability!) e nossas experiências profissionais. Não necessariamente nessa ordem.

    Em outro dia, quando compartilhávamos a mesa com Suzandeise Thomé, Luiz Parzianello, Marcelo Neves e Willen Dijkgraaf, chamei a atenção para a forma como Shane destacava sua não concordância com algum tema. Por exemplo: “Arquitetura Corporativa”. Shane desacelera e calibra a dicção, frequentemente soltando um “fundamentally wrrrrrong!”.  Aquele “Wrrrrrong” soa como um trovão. E não deixa a menor dúvida sobre sua posição. O que não significa que a conversa tenha se encerrado, pelo contrário. Está apenas começando!

    Acompanhei de longe a repercussão do restante do evento. Pelos comentários a única conclusão possível é de um retumbante sucesso. E a certeza de que a versão 2012 é só questão de tempo. Que assim seja!

    Reflexões

    Minha palestra aconteceu logo na sequência, ainda na manhã da quinta-feira. Falar logo após a abertura do Shane já era uma responsabilidade e tanto. De carona no presente-provocação sugerido pelo Luiz Parzianello, uma responsabilidade quase insuportável. Quando me convidou, Parzianello sugeriu o título de minha fala: “Para você, o que é Análise de Negócios?”

    Abri o papo confessando a dificuldade em condensar em quarenta e cinco minutos uma resposta que, a primeira vista, deveria ser muito simples e direta. Mostrei que apelei para um oráculo (Bob Dylan?!?) e para o pai dos burros (Houaiss) em uma busca infrutífera por inspiração. Quem leu meu artigo anterior já conhece o final da história. Meu problema não era definir a Análise de Negócios mas sim justificar a definição. E não havia mais nenhuma razão para manter implícitas ou autocensuradas duas provocações:

    1. Há, no meu ponto de vista, exagerada e arriscada ênfase na macrodisciplina  “Análise de Negócios” em detrimento de seus praticantes principais, os Analistas. Algo como: “o importante é que a Análise seja feita, não importa por quem”. Concordo que a área não carece de muros ou testes como aqueles que vemos em Direito, Medicina, Engenharia e afins. Por outro lado, se não existirem profissionais especializados e orgulhosos de sua área, como podem a disciplina e respectivo corpo de conhecimentos evoluir? Não é de hoje que é notória a baixa autoestima dos Analistas de Negócios, particularmente dos tupiniquins. Existem razões mil para tanto – sendo a principal a confusão com “tiradores de pedidos²”. Mas não melhoramos a situação com o discurso vigente. Em suma: se queremos uma Análise de Negócios forte e reconhecida precisamos fortalecer e reconhecer os Analistas de Negócios. Eles não são nada menos que fundamentais para o futuro da disciplina.
    2. Não estava escrito em nenhum slide que utilizei mas acho que falei mais ou menos assim: “Se tivermos legítima preocupação com a Análise de Negócios em médio e longo prazos, então é hora de decretar sua independência de TI“. Reconheci que devemos ser eternamente gratos pelo fato de TI ter ressuscitado e viabilizado a área. Mas é chegada a hora de debater se queremos ou podemos limitar o uso da disciplina exclusivamente em problemas de negócios que envolvam Tecnologia da Informação. Apresento novamente mea culpa. Tenho vinte e cinco anos de vida profissional e sempre trabalhei com TI. Meu trabalho se limita a TI. Mas meu trabalho é só um grãozinho de areia, sem falsa modéstia. Quero crer que o público presente, pelas questões apresentadas, entendeu bem o recado. Até quando sugeriu, para minha concordância, que o Analista de Negócios é o Novo Novo Analista de Organização & Métodos.

    Testando o {FAN}

    Se o {FAN} 2012 precisava ser puxado até o limite, ele conseguiu em PoA. Foram duas turmas, uma delas não programada originalmente. E entre os quase setenta participantes uma diversidade grande, muita sede, muitas dúvidas e bastante colaboração. Ligeiras conclusões:

    • O programa está perigosamente no limite de sua carga horária. Já penso seriamente em uma versão com 20 horas distribuídas em três ou cinco dias. Na próxima semana, em turma fechada e com 24 horas ao meu dispor, farei novo teste.
    • Algumas atividades podem “sujar” mais paredes. A turma via o curso do Shane ao lado e gostava de todos aqueles displays.
    • Aliás, posso contemplar em algumas turmas o trabalho de derivação de casos de uso em histórias e tarefas. E tornar a montagem de diagramas PUCS uma atividade mais interativa, fazendo toda  a sala montar um único diagrama.
    • Preciso rever o último sprint, que acontece logo após um coffee-break. É um tour-de-force com cerca de duas horas de duração e sem nenhuma interrupção – nenhuma atividade prática. É uma longa história que conto, mostrando como os analistas de negócios trabalham em conjunto com o time de desenvolvimento em busca de uma solução. É legal – acho que todos gostam. Mas chego ali estourado, com voz e pernas extenuados. Ok, preciso melhorar minha condição física. Mas acho que é possível quebrar aquela história de forma a torná-la menos cansativa.

    Tks!

    Suzandeise Thomé, Luiz Parzianello e Marcelo Neves, pelo voto de confiança e pela oportunidade. Oferecer tão generoso espaço para um chato e crítico frequente do IIBA é prova incontestável da maturidade e do espírito democrático dos Chapters brasileiros. Vocês sabem, seguirei chato e crítico. Mas seguirei também um fã incondicional do trabalho de vocês. Parabéns!

    Thank you, Mr. Shane Hastie, for your generosity, the shared knowledge and the patience with my bumbling english. 

    Simone Kosmalski, pela hospitalidade, atenção e organização.

    Melissa Trevisan e Marta Py, pelo trabalho, força e confiança.

    Willem Dijkgraaf, pelo apoio e pelo feedback.

    E muito obrigado a todos que tornaram o BA Brazil 2011 possível.

    Observações:

    1. Shane justificou a ausência (de casos de uso na extensão ágil do BABoK®) dizendo que a técnica já está devidamente coberta no BABoK® 2.0. Mas alertei, a ele e ao Parzianello (que também trabalha naquela extensão), que talvez o texto esteja passando a impressão (equivocada) de que no mundo ágil só se trabalha com histórias de usuários. Prometi ser mais específico na leitura crítica que publicarei antes para eles e depois aqui no {finito}.
    2. Perdi a oportunidade de fazer um teste de DNA e tirar dúvidas sobre a paternidade do termo “tirador de pedidos”. Mas aproveito para registrar aqui outra coisa que o Analista de Negócios NÃO é: “traficante de picuinhas!” Qualquer dia compilo todos os “criativos” termos criados para desmerecer e desmotivar o mau uso da profissão.
  • {FAN} 2012

    {FAN} 2012

    Lancei na última semana, em São Paulo, a versão 2012 do {FAN} Formação de Analistas de Negócios. É uma versão especial porque celebra o quinto ano do programa. Aproveitei o impulso do BA Brazil, que acontece daqui a duas semanas em Porto Alegre, para antecipar o lançamento. Apresento neste artigo a estrutura, alterações e extensões da oficina.

    ?

    Não acredito que um dia o núcleo duro do {FAN} seja alterado. Desde o longínquo junho de 2007, quando foi apresentada ao público pela primeira vez, esta oficina está estruturada em torno de duas grandes disciplinas: Modelagem de Negócios e Requisitos. Aprendi depois de um tempo que deveria utilizar uma explicação relativamente simplista para justificar a estrutura: a primeira disciplina nos ajuda a entender um negócio; a outra concentra-se no entendimento das necessidades e restrições de usuários e outros interessados. Cada uma merece 50% da carga horária. A divisão arbitrária – um dia para cada disciplina – tem fins didáticos. Os participantes devem entender que lançam mão de ambas simultaneamente durante toda a sua participação em um projeto. Eles entendem.

    Assim como entendem o fato deste evento não se basear na estrutura proposta pelo BABoK®. É fácil fazer um ‘de-para’ quando necessário. Como o foco da oficina não é a certificação, mas o trabalho prático com a Análise de Negócios, nunca ninguém reclamou. Cito o corpo de conhecimentos oficial quando necessário, seja para destacar algum problema ou boa solução. Tanto que falo até hoje sobre a versão 1.6 e seu bom capítulo sobre “Elicitação” de requisitos.

    Deixo a impressão, até aqui, de que não mudou muita coisa no {FAN}. É que comecei pelo que não mudou. Vamos às alterações. A versão anterior, que utilizei até outubro deste ano, tinha 200 slides no arquivo de apresentação. A nova versão conta com exatos 299! Um acréscimo de praticamente 50% e a mesma carga horária? Como isso seria possível?

    Fiz um levantamento de todos os tópicos que, a partir da interação com os participantes, exigiam improvisos em um quadro branco. Apesar de gostar de toda aquela dinâmica, percebi que perdia um tempo precioso rabiscando. Pior: ficava muito tempo de costas para a plateia. Todos os improvisos que ficaram frequentes mereceram slides. Praticamente todo um novo tópico sobre estimativas, priorização e definição de escopo brotou dessa decisão.

    Eliminei também o ridículo “ditado” de uma especificação de caso de uso que servia como exemplo. Mantenho a apresentação passo-a-passo de um caso, mas agora os alunos ficam livres para prestar atenção no que de fato interessa. Três atividades práticas os deixam rabiscar e abusar do novo modelo que apresentei no artigo anterior.

    E por falar em atividades práticas: são 11 no total. E, a partir de agora, nenhuma é opcional. Elas totalizam cerca de 240 minutos, quatro horas de um total de quatorze. Ou seja, cerca de 30% da oficina é totalmente prática. Parece pouco, mas me lembro dos tempos em que o {FAN} era FAN e tinha apenas 4 atividades. E de sua “pré-história”, quando não havia exercício algum.

    Todos os exercícios são posicionados de forma a reforçar ou demonstrar a parte teórica recém apresentada. E são baseados em um mesmo problema de negócio. Mantenho a estratégia de não fixá-lo nas apresentações ou na apostila. Isso permite que a cada turma eu possa sugerir um novo. Também possibilita que em cursos fechados sejam utilizados projetos reais dos clientes. Na última edição eu ressuscitei o imbróglio do ‘seu’ Moreira – português fabricante de pãezinhos que precisa dobrar a produtividade de seus vendedores. Em PoA eu devo trocar a nacionalidade do preocupado e seu produto: de pão para vinho.

    Outra mudança significativa está no número de ferramentas apresentadas, particularmente no módulo de modelagem. Incorporei novas sugestões, inspirado principalmente por dois trabalhos: Business Model Generation¹ (o ‘canvas’) e Gamestorming². Mantenho o Pensamento Visual como método de modelagem, mas sem a ênfase que ele mereceu nas versões anteriores. Ao ‘esconder’ o método e apresentá-lo apenas no final do primeiro dia eu consegui, por incrível que pareça, facilitar seu entendimento.

    No final do segundo dia também acontece um momento flashback, desta vez revendo todo o evento e demonstrando um método para definição do escopo inicial de um projeto. Conto uma história onde o analista tem dez dias úteis para entender um problema e, junto com o time, tentar descobrir a melhor solução. Funciona realmente como uma grande revisão da oficina, da famosa fotografia 2km X 2cm até o detalhamento de casos de uso. É uma das partes que eu costumava improvisar e que ficou muito melhor com o apoio visual pré-concebido.

    Agora deixei a impressão de que foi tudo perfeito no ‘teste beta’ que executei, o que não é verdade. Peguei uma turma que ficou muito silenciosa (assustada?) no primeiro dia. No segundo, se soltaram e interagiram bem mais, comigo e entre eles. Mas fiquei com a pulga atrás da orelha: a sobra de trinta minutos em cada dia é real? Só terei certeza depois das duas oficinas no BA Brazil. Encontrei um bug mais sério só no segundo dia, o mal posicionamento da atividade #8. Mas foi muito pouco para evento tão extenso. Sorte de principiante? Hehe… pode ser.

    Outro probleminha: a apostila está mais bonita, melhor diagramada. Agora ela tem espaço para a resolução dos exercícios. Não pretendo mais distribuir blocos separados para eles. Acontece que o pessoal ficou com dó da apostila. Muitos não quiseram rabiscá-la. Mesmo com minha promessa de que a versão digital está disponível para download. O que fazer? Ah, se eles vissem como trato meus livros de papel…

    Meio & Mensagem

    Mudanças cosméticas; inserção pontual de ferramentas; maior cuidado com atividades práticas. O {FAN} nunca ficou parado no tempo e em seus quatro anos e meio de vida sempre apostou que podia ser bem melhor. Mas a nova versão traz uma mudança maior, não citada até agora.

    Em meu entendimento, a “onda” em torno da Análise de Negócios passou. Assim como já ficou para trás a “moda” Scrum. É uma aposta que torno pública: vocês verão muitos entusiastas de primeira hora vestindo novas roupas, estampando novas cores e reciclando promessas. Trata-se do melhor momento de todas as ondas. Porque o que fica é o que de fato interessa. O que passou era entusiasmo (e oportunismo) e nada além disso.

    O {FAN} 2012 incorpora esse espírito. Entende que a Análise de Negócios, que a necessidade dela, sempre existiu e sempre vai existir. Mas há um tanto de mea culpa no novo discurso. Motivado, principalmente, pelo advento dos Arquitetos de Negócios. Eles não seriam sugeridos se nós, envolvidos com a formação de analistas de negócios, tivéssemos feito um bom trabalho. Mas é só outra moda. Não deve preocupar.

    Preocupa, isso sim, que os bons analistas de negócios não desanimem. Para isso acho que é fundamental provar sua criticidade no cotidiano de uma organização. Não apenas na solução de problemas de TI. Analistas de negócios não dão manutenção em sistemas! Analistas de negócios não são “tiradores de pedidos”! Analistas de negócios apoiam a descoberta e o desenvolvimento de soluções para problemas de negócios. Qualquer tipo de problema.

    Posicionados a partir da definição acima os analistas de negócios se verão desafiados por domínios cognitivos de maior dificuldade. Não basta a análise – o estudo das diversas partes de um todo (Houaiss). O analista não é nada menos que fundamental na síntese – na destilação da tese proveniente daqueles que têm problemas e da antítese colocada pelos eventuais provedores de soluções. É peça fundamental – meio e mensagem – em um diálogo verdadeiramente produtivo.

    Enfim, o {FAN} 2012 traz uma mensagem otimista embalada em belos desafios. Desenha-se em torno de duas disciplinas que definem as habilidades técnicas que um analista de negócios deve desenvolver. Mas é guiado por um conjunto que, por falta de termo melhor, tenho chamado de Habilidades Essenciais: Solução de Problemas, Análise, Síntese, Gestão do Conhecimento e Aprendizagem Organizacional, Comunicação Corporativa, Pensamento Criativo, Pensamento Sistêmico, Pensamento Visual, Teoria da Complexidade etc. Eu sei, assusta. Mas posso garantir: é apaixonante. Por isso seguirei teimando que essa é uma das melhores profissões do século XXI. Quem sobreviver (à onda), verá.

    Extensões do {FAN}

    Há meses brigo com uma ideia: liberar módulos curtos, com três horas de duração, para apresentação e aprofundamento de tópicos específicos do programa {FAN}. Como é impossível prever sua aceitação, farei testes reais em janeiro do próximo ano. Não exigirei participação prévia no {FAN} tradicional de 14 horas. Esta primeira geração do que estou chamando {FAN Fast} é formada por quatro módulos:

    • Introdução à Análise de Negócios: apresentação da área, seu corpo de conhecimentos & habilidades e as responsabilidades de um analista de negócios em uma organização e em projetos. Tiro curto dirigido a todos que ainda precisam conhecer a função/profissão e saber como tirar melhor proveito dela em suas empresas.
    • Aprendendo Requisitos, Contando Causos e Histórias: aprendizagem, estruturação e desenvolvimento de requisitos de forma prática e direta. Há tempo muita gente tenta contratar apenas o segundo dia do {FAN}, aquele que trata especificamente de requisitos. Este módulo é para eles e todos que queiram mergulhar um pouco mais no tema.
    • Conversando (e Rabiscando) a Gente se Entende: novamente inspirado pelos livros citados acima. Ferramentas práticas que facilitam a comunicação com usuários, clientes e outros interessados. Outras ferramentas, além daquelas apresentadas no {FAN}, serão exercitadas aqui.
    • Trabalhando com Scrum e outros Métodos Ágeis: para analistas e gente de negócios que precisam saber como se comportar (hehe) em projetos guiados pelo framework Scrum ou outros métodos ágeis. O que muda na atuação de um analista? E o que não deveria mudar? Evento prático e divertido que mostra a importância de um analista na formação de um “time de (dono de) produto” e no trabalho com métodos ágeis.

    Todos os módulos são ‘levemente acoplados’. Ou seja, você contrata apenas aquele ou aqueles que te interessar. Não haverão (muitas) referências cruzadas, nem mesmo com o {FAN} tradicional. Nesta primeira leva, apenas uma restrição: os módulos acontecerão durante a semana, em dias consecutivos e em período noturno. Em breve publico as páginas dos eventos e divulgo a agenda.

    Upgrade

    Em 2010 ofereci, de graça, um FAN Upgrade. Foi muito curto e serviu para rever amigos. Passados quase dois anos, hora de agendar uma nova atualização. E ela se dará através da participação no evento tradicional, com 14 horas de duração! Desta vez o evento será pago (assim quem se inscreve realmente participa, né?) Mas terá descontos progressivos. Quanto mais antiga sua participação no FAN, menos você paga. Quem participou das turmas de 2007 e 2008, por exemplo, tem desconto de 50%.

    O Upgrade está agendado em programação especial de férias: acontecerá em São Paulo, nos dias 13 e 14 de janeiro. O site da Tempo Real Eventos já está recebendo inscrições: http://www.temporealeventos.com.br/?area=15

    ?

    Observações:

    1. Business Model Generation – Inovação em Modelos de Negócios
      Alexander Osterwalder – Alta Books (2011)
    2. Gamestorming – A playbook for Innovators, Rulebreakers, and Changemakers
      Dave Gray, Sunni Brown e James Macanufo – O’Reilly (2010)
    3. “Creating Solutions”, de HikingArtist.com, é o título do cartoon utilizado neste artigo.
  • Um Novo Modelo para Casos de Uso

    Um Novo Modelo para Casos de Uso

    Apresento neste artigo um novo modelo para a especificação de casos de uso. Foram dois os empurrões que me trouxeram para esta nova proposta. Vários participantes de meus treinamentos pediram por um modelo que não tivesse apenas fins didáticos. Algo que eles pudessem adotar em seu dia a dia. Além disso, ideias recentes apresentadas por James Coplien, Gertrud Bjørnvig e Ivar Jacobson me fizeram rever alguns pré-conceitos em relação à ferramenta. Mantive boa parte do desenho original – a preocupação com a estruturação dos requisitos – mas incorporei vários novos elementos. Como ainda não tive muitas oportunidades para testar o novo modelo, contarei com seu retorno.

    ?

    Antes de mais nada, os créditos. A principal provocação para o novo modelo veio de “Lean Architecture” (Wiley, 2010), de James Coplien e Gertrud Bjørnvig. O casal, por sua vez, cita os trabalhos de Rebecca Wirfs-Brock (“Designing Scenarios” – Smalltalk Report, nov-dez/1993) e Constantine e Lockwood (“Software for Use: A Practical Guide to Models and Methods of Usage-centered Design” – Addison-Wesley, 1999). Me convenceram da utilidade e necessidade do uso de duas colunas nos fluxos. E provam, em seu livro, como as especificações podem ser ágeis e enxutas. Na semana passada o “pai” dos casos de uso, Ivar Jacobson, publicou um artigo sobre Casos de Uso 2.0. Dele ganhei a confirmação de que casos de uso: i) são tão ágeis quanto você; ii) escalam o quanto você precisar; iii) não tratam apenas de requisitos funcionais; iv) não se limitam a projetos de sistemas; e v) nem aos requisitos – valem em todo o ciclo de vida de um projeto. Usei todas as novas sugestões como complementos ao modelo que utilizava anteriormente e que era fortemente baseado no trabalho de Alistair Cockburn, “Escrevendo Casos de Uso Eficazes” (Bookman, 2008).

    Aos iniciados, letrados e usuários super-avançados de casos de uso e afins, um aviso: o modelo aqui sugerido segue tendo como principal motivação o uso didático. Por isso, talvez o modelo não tenha nenhuma utilidade para vocês. Pensei nos iniciantes e em todos que precisam rever seus (pré)conceitos sobre a ferramenta. Me preocupei, principalmente, com todos que precisam de um tipo de guia (e de limites) enquanto aperfeiçoam sua técnica. Vamos ao que interessa.

    O modelo anterior era muito pequeno (formato A5), o que impedia seu uso em casos ‘de verdade’. O novo modelo foi diagramado em formato A4 paisagem. Frente (acima) e verso (logo mais) podem ser impressos em uma única folha ou em separado, como explicarei mais tarde. A frente condensa todas as informações fundamentais sobre um caso de uso. Vou apresentá-la por partes.

    Cabeçalho

    Segue a preocupação com a identificação da fonte e respectivo ponto de vista (estratégico, tático, operacional ou técnico). Incorporei um sofisticado “controle de versões”. Ele me ajuda a reforçar um grito: “joga o caso no lixo! (tão logo dele tenha brotado algum derivado)”.

    Finalmente me lembrei dos ícones que determinam o nível de detalhamento do caso. Não, prezadas fábricas de software (sic), não contemplei o tal nível “pré-sal” que vocês insistem em pedir. Mas a nova versão da ostra, quero crer, não gerará mais dúvidas nem piadinhas.

    O campo “processo / atividade” serve para referência cruzada com algum diagrama do negócio, de preferência com o PUCS (Process-Use Case Support) ou um diagrama de atividades.

    “Valor”, que talvez ainda seja rebatizado “Benefício”, indica como o cliente ou usuário valoriza o caso em questão. “Custo” é a estimativa de esforço do time de desenvolvimento (expressa em unidades relativas, pontos de casos de uso ou qualquer outra unidade de medida). A possível avaliação benefício/custo pode determinar a “Ordem”, a posição do caso no cronograma (ou, de preferência, no backlog do produto). Daí o espaço “Iteração”, onde deve ser registrado a iteração projetada para o trabalho neste caso. Quem não “itera” pode ignorá-lo, sem problemas.

    Contexto, Pré e Pós-Condições

    Não se trata de um filler, vulgo “encheção de linguiça”. O Contexto nos ajuda a posicionar o caso de uso no projeto, indicando suas relações com outros elementos. É aberto para possibilitar até mesmo o desenho de um pequeno diagrama de casos de uso. Mesmo que fujas dos temidos (e mal compreendidos) extends e includes da vida, você deve achar alguma utilidade para o espaço. Pré e pós-condições não pedem por maiores explicações. Ah, só preciso dizer que elas são um tipo muito especial de Regras de Negócio. Regra do negócio, e não aquele papo de “o usuário tem que estar logado no sistema (sic)”. Pronto, disse.

    Fluxo Principal

    A conversa devidamente explicitada. Eu evitava o modelo com duas colunas por morrer de medo daqueles que acham que, para cada intenção do ator o sistema deve, obrigatoriamente, dar uma resposta. Desperdício imperdoável de tempo que culminava em obviedades assim: Ator: Indentificar Cliente / Sistema: Exibir nome do cliente. Terrível! Mas Coplien e Bjørnvig me convenceram de que, apesar dos mestres do óbvio, este modelo é realmente mais eficaz.

    Ainda assim, o espaço disponível para descrição dos passos do ‘caminho feliz’ segue exíguo para todos aqueles que não acreditam nos limites sugeridos por Coplien (máximo de 7 passos) ou Cockburn (máximo de 9 passos). Só evitei numerá-lo, como no modelo antigo, para deixar o formulário um pouco menos poluído.

    Fluxos Alternativos / Instruções para Testes

    Está aqui o trecho que mais me custou mais tempo. O número de fluxos alternativos pode ser muito grande, dependendo do caso de uso. Mas a questão não era só essa. Queria contemplar também um espaço para um tipo de Caso de Testes. Acho que consegui matar os dois coelhos. O trecho acima aparece na parte da frente do modelo e em metade do verso. Por isso eu disse que o verso pode ser impresso de forma independente. Ele também contempla outras regras de negócios e outros tipos de requisitos. Quando o espaço não for suficiente, basta imprimir ou utilizar mais páginas apenas com o verso do modelo. Aos campos.

    Indicamos o número do passo afetado e o tipo de registro (fluxo Alternativo o Teste). Na sequência, o motivo para o desvio ou então alguma instrução para a execução de testes. Há ainda uma coluna para comentários e outra para a indicação da iteração que deve contemplar a realização deste fluxo alternativo. Esta ideia combina bem com os slices propostos por Ivar Jacobson no referido artigo. Combina ainda mais com as sugestões apresentadas em “Lean Architecture” (em resumo: em um projeto tocado por um método iterativo, os incrementos são fluxos dos casos de uso. Ex: em uma iteração você entrega o fluxo principal, na seguinte dois fluxos alternativos e assim por diante).

    Se a ferramenta é escalável, como confirma Jacobson, o modelinho também deve ser. Daí a diagramação do verso, exibida abaixo.

    ?

    Utilizarei este modelo nas próximas edições de meus treinamentos. Acho que só depois de duas ou três experiências terei noção das alterações necessárias. Ou seja, novidades sobre o tema só no final de novembro. Enquanto isso, se você quiser brincar um pouco com o modelo, faça o download aqui: bit.ly/UCfinito. Claro que estou contando com seu retorno, experiências, críticas e sugestões. Desde já agradeço. Abraços!

    Obs.:

    1. Nunca antes na história deste blog o nome de uma imagem combinou tanto com o conteúdo. “Extracting Knowledge” é de autoria do HikingArtist e foi legalmente surrupiada no Flickr.
    2. Depois de meus canhotos rabiscos, todo o trampo artístico e de diagramação foi do mano Gus Vasconcellos, da Opção Artes Gráficas. Não sei o que seriam de meus rabiscos sem a colaboração dele.