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)

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.

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.

Apresentei o DSRP (Distinções Sistemas Relacionamentos Perspectivas) de forma muito breve e quase irresponsável alguns meses atrás. Abstração é o luxo do expert? Não sou expert. Foi relaxo de aprendiz mesmo. Acontece que ele é tão simples, mas tão simples, que chega a levantar suspeitas. 

Os objetos de estudo podem ser complicados e complexos, bagunçados e imprevisíveis. Modelos e métodos que apoiam o estudo não precisam – aliás, não podem ser assim. Veja a simplicidade desconcertante de propostas como Scrum e Kanban, por exemplo. O DSRP vem na mesma linha. Mas, claro, tem um propósito bem mais ambicioso: nos ajudar a pensar melhor. Ao exemplo.

Distinções

O que é conhecido está definido – tem identidade e fronteiras. Não fosse assim, não conseguiríamos nem nos expressar. Nomeamos as coisas, comparamos e escolhemos ideias. Determinamos o que está dentro e o que está fora do escopo de um projeto. Pronto, agora podemos aplicar a regra das Distinções aos requisitos.

Antes, porém, uma definição básica: requisitos são condições para alcançar determinado fim. Ponto. Projetos têm fins – nada a ver com as datas em um cronograma nem com a grana que se pretende torrar. Há pelo menos um objetivo de negócio ali, seja qual for. Requisitos são condições que, quando e se plenamente satisfeitas, aumentam as chances de realização daquele objetivo.

Todo requisito é único. Ele merece um nome, número e etiquetas. Pede por informações que demarquem suas fronteiras. E a primeira distinção que realizamos refere-se ao seu tipo: É uma função (algo que o sistema deve fazer ou ajudar a fazer) ou um atributo (uma característica do produto/sistema)? 

Cada requisito é diferente, assim como sua margem de contribuição (valor) para a realização do objetivo maior. Aquilo que é fundamental deve ser entregue e não se fala mais nisso. Requisitos importantes serão satisfeitos, um dia. Os opcionais não comprometem a busca pelo objetivo. Mas podem agradar alguém cujo humor e motivação sejam fatores críticos de sucesso.

A régua utilizada é simples: Fundamental, Importante, Opcional. Podemos fazer uma distinção mais sofisticada, utilizando a sequência de Fibonacci, por exemplo. Não importa. Desde que tal diferenciação aconteça tão logo um requisito seja apresentado.

Se não diferenciamos os requisitos não podemos compará-los. Se a comparação é impossível, qual tomada de decisão faria sentido?

Sistemas¹

Todo requisito pode ser visto como o todo ou parte de algo maior. Se o próprio projeto pode e deve ser visto como “uma condição para alcançar determinado fim”, temos que um projeto é também um requisito. Depende do ponto de vista. Ou, melhor dizendo, depende do ponto de corte: da definição daquilo que se pretende estudar.

Um projeto é um conjunto de requisitos. E requisitos podem ser estruturados em partes menores. Uma função, por exemplo, pode ser descrita na forma de casos de uso. Assim sendo, ator, objetivos, pré e pós-condições, fluxos principal e alternativos e os passos desses fluxos são partes do todo chamado requisito funcional (ou simplesmente Função).

Requisitos podem ser distribuídos em módulos, versões, plataformas etc. Requisitos podem ser descobertos e explicados através de casos de uso, histórias de usuários, protótipos etc. O importante aqui é a estrutura e as idas e vindas entre o todo e as partes – análise e síntese.

Vale a pena recuperar um alerta que faço: “O diabo mora nos detalhes. Em projetos, cada requisito é um conjunto de detalhes. O dito cujo faz a festa.”

Relacionamentos

Se fazem parte de um todo – o projeto – é natural que os requisitos tenham inúmeras e fortes relações entre si. Não é possível compreender um requisito se não sabemos como ele se relaciona com os demais.

Um requisito pode depender de outro, por exemplo. Sua realização não é possível até que o outro seja satisfeito. Relações de complementaridade também são comuns: o requisito B enriquece o requisito A, mas não há dependência. 

Requisitos podem ser redundantes. Neste caso, um deles deve sair do escopo. Assim como um daqueles em relação conflituosa: quando a realização de um impede a satisfação do outro. Infelizmente, muitos conflitos só são descobertos quando é tarde demais: na bancada de testes ou, pior ainda, em produção.

Por fim, mas não menos importante: um requisito pode substituir outro. Quando as relações de substituição são bem registradas, temos boa parte da história de um projeto e dos diversos rumos que ele tomou.

Ops!, não era o fim. Requisitos também se relacionam com outras coisas. Com testes, por exemplo, numa típica relação de muitos para muitos. Explico: todo requisito merece vários testes (unitários, de integração etc); E alguns testes validam vários requisitos numa pancada só. Muitos para muitos. Há mais relacionamentos, mas você já pegou a ideia. Hora da última peça do tabuleiro DSRP.

Perspectivas

Como fixado na definição original, qualquer coisa ou ideia pode ser o ponto de vista ou aquilo que é visto. Vale para tudo, e é particularmente importante quando falamos de requisitos. Um mesmo requisito pode ser interpretado de formas diferentes ou mesmo ter valores distintos dependendo da perspectiva – de quem ou o que o observa. Ao desenvolver requisitos, o bom analista se preocupa em capturar todos os pontos de vista relevantes. Ele promove o debate e ajuda a dissolver os inevitáveis conflitos.

Coincidência?

Nossa Paulo, com exceção das figurinhas, não tem nada diferente do que você apresenta desde a primeira edição do FAN.

Para falar a verdade, é praticamente a mesma ideia que utilizo desde 2000 e que apresentei numa palestra em 2004. Aqui no finito, ela apareceu pela última vez há quatro anos. Coincidência? Sorte? Isso importa?

Conclusão

Usar o DSRP significa aplicar 4 regras simples. Espero ter demonstrado isso acima. Pretendo elaborar novos exemplos, utilizando casos do dia a dia. Porque também preciso mostrar como o DSRP é extensível e acomoda de forma natural outras vertentes e ferramentas do pensamento sistêmico.

Notas

1. Derek Cabrera, o criador do DSRP, confessa ter hesitado na escolha do nome para a segunda regra: Sistema ou Estrutura (Structure)? Infelizmente, em minha humilde opinião, ele fez a pior escolha. Por outro lado, a tradução para o português não exigiu a troca de nenhuma letrinha.
2. Utilizei a ferramenta de modelagem DSRP, o MetaMap, para criar as imagens acima. Ela não deve ser adequada para uma completa Engenharia de Requisitos. Mas é supimpa para clarear ideias.

Vira e mexe, em algum telejornal, tem um analista de sistemas dando suas opiniões sobre  trânsito, clima, política ou pastel de feira. Eles são onipresentes. Na TV. Parece que o mesmo não pode ser dito em muitas organizações.

Nos últimos tempos, em contato com empresas dos mais diversos ramos e portes, me deparei com o mesmo problema: a Análise de Sistemas sumiu! Alguém com o boné “analista de negócios” se vira para desenvolver um conjunto disforme de entregáveis (sic). Essa geléia vai direto para o colo de programadores que, sem alternativas, se viram. Ir de uma especificação de caso de uso direto para o código é como ir do porco para o prato de feijoada sem passar pelo fogão.

Talvez eu esteja deveras obsoleto (e o uso de “deveras” é prova inconteste disso). Afinal, muitos nem saltam mais de casos de uso para o código. Pulos modernos partem de user stories. Em ambientes sofisticados, estórias devidamente acompanhadas por protótipos low-fi. Coisa fina.

Nada disso importaria se eu não me deparasse, em irritante frequência, com duas questões: 1) Os desenvolvedores “pastam” para decifrar o que precisa ser feito; 2) A manutenção de sistemas parece um jogo de enigmas sem fim.

O super-entregável que cumpre o papel de matéria-prima para os desenvolvedores é obrigado a assumir responsabilidades demais. Quem disse que casos de uso ou estórias devem responder questões técnicas? Onde está escrito que esses artefatos devem entrar em minúcias de APIs, SPs e tabelas de um banco de dados? E desde quando a aproximação entre desenvolvedores e clientes/usuários torna o “pensar e desenhar soluções” (aka Análise de Sistemas) algo supérfluo?

A UML, que nasceu há quase vinte anos, tinha uma resposta para a documentação de sistemas. E essa resposta nunca se limitou a dois ou três diagramas rabiscados em momentos iniciais de um projeto. Mas ela morreu ou está moribunda. Dizem por aí que colocaram DSLs em seu lugar. Luxo de pouquíssimos. Um ou outro, um pouco mais esperto, não reinventou a roda: desenvolveu sua linguagem específica a partir da UML. Alguém viu algo do tipo por aqui?

Porque não vi em em lugar nenhum. O que vi, isso sim, foi um monte de sistemas com manutenção caríssima. E um tanto de desenvolvedores-caçadores-da-rastreabilidade-perdida.

Encontrar culpados? Pura perda de tempo. Lancemos mão de nosso senso de oportunidade: com vocês o programa FAS – Formação de Analistas de Sistemas. É baratinho e rápido, saca só:

1. Compre (e LEIA) “Utilizando UML e Padrões”, de Craig Larman (Bookman, 2007).
   Obs. A) Se em algum canto de seu HD encontra-se solitário e perdido um tal de EA (Enterprise Architect), talvez você prefira o livro “UML 2.0 – Do Requisito à Solução”, de Adilson da Silva Lima (Érica, 2008).
   Obs. B) Se você ficar com medo de alguém lhe acusar de não ser “ágil”, então leia também “Modelagem Ágil – Práticas Eficazes para a Programação eXtrema e o Processo Unificado” de Scott  W. Ambler (Bookman, 2004). Apenas evite o capítulo 24 e suas (seis) generosas páginas dedicadas à “Modelagem Ágil de Negócios”. Deixe esse papo para os Analistas de Negócios.
2. Aplique, Inspecione, Adapte e dissemine o que aprendeu.

E quando alguém disser que você está obsoleto apenas responda: “O que posso fazer, sou um Analista de Sistemas”.Antes que alguém estrebuche: não estou diminuindo a Análise de Sistemas nem dizendo que a leitura de dois ou três livros substitui quatro anos na cadeira da escola. A sugestão acima apenas pretende sanar uma parte dos probleminhas correntes em algumas organizações.

A verdadeira Análise de Sistemas vai muito além do escopo ali proposto. E tem em sua base o estudo, dentre outras, de: Teoria da Informação, Teoria Geral dos Sistemas, Cibernética, Sistemas Dinâmicos, Sistemas Adaptativos Complexos, Pensamento Sistêmico, Teoria da Evolução, Teoria dos Jogos… Ops! De qual Analista de Sistemas estamos falando?

Notas

1. Where’s Wally…, a foto utilizada, é de William Murphy.
2. Prometo não voltar ao tema. Até o ano que vem. Ou até encontrar Wally…

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.

Comecemos pelas boas novas. As definições básicas foram todas revistas. A verborragia que tanto atrapalhava e comprometia o entendimento do guia foi, em grande parte, eliminada. Tomemos como exemplo a própria definição da Análise de Negócios: ela foi abreviada de 43 para 27 palavras. Sai aquele papo sobre “…atividades e técnicas para servir como ligação entre parte interessadas…” – um terror, e entra “viabilizar mudanças em organizações através da definição de necessidades e recomendação de soluções”. Boa!

A nova versão também troca a definição de Requisito proposta pelo IEEE por uma bem mais enxuta: “representação utilizável de uma necessidade”. Enxuta e curiosa. Porque prevalece um entendimento técnico em detrimento da definição fixada em dicionários. Requirement, segundo o Oxford, é uma “coisa necessária ou desejada”. Aqui no Brasil tomamos a liberdade de traduzir Requirement como Requisito, termo que o Houaiss define como uma “condição para alcançar determinado fim”. A Navalha de Occam adaptada para analistas de negócios ensina que, na dúvida (entre definições de um mesmo termo), deve prevalecer o que facilita a vida de uma pessoa de negócios, não a do técnico. Por isso termos como “requisitos não funcionais” deveriam ser abolidos ou apresentados com ressalvas e as devidas adaptações para leigos. Infelizmente, isso não ocorreu.

E não se trata de um mero detalhe. Se uma das maiores contribuições de um analista de negócios é a comunicação eficiente e eficaz, o primeiro passo é a adoção de um vocabulário livre do tecniquês e de jargões. Noves fora, o fato é que a simplificação apresentada na nova versão merece aplausos.

Escorando a Estrutura

A estrutura básica, com seis disciplinas (KA – Knowledge Areas) e um “repositório universal” (Competências Fundamentais) está mantida. Alguns nomes sofreram alterações, como Análise Estratégica ao invés de Análise Corporativa. Pequenas alterações que não são apenas cosméticas porque facilitam o entendimento¹.

Uma das novidades na estrutura do BABoK é o BACCM (Business Analysis Core Concept Model – Modelo de Conceitos Centrais). O modelo é formado por seis termos apresentados na seguinte ordem: Mudança, Solução, Contexto, Valor, Partes Interessadas e Necessidades. Uma mudança em um desses “lugares” forçaria uma revisão nas outras cinco “dimensões”. E isso facilitaria uma visão holística.

Honestamente, não entendi bem a novidade. E o checklist que a encerra dá certo frio na espinha – irão os decorebas adotá-lo, para pesadelo das partes interessadas em busca de soluções para problemas que em dado contexto mutante devem gerar algum valor? Não sei se é a santa obviedade que me trai. Ou meus pré-conceitos. De qualquer forma, melhor esperar por experiências ou outras explicações.

Como comentei anteriormente, o BABoK agora apresenta uma nova seção chamada Perspectivas. Estão ali: Agile, BI (Business Intelligence), TI (Tecnologia da Informação), Arquitetura de Negócios e BPM (Business Process Management). O que delimita esse conjunto além do óbvio berço tecnológico? Nada!

Mas o BABoK ensina que as Perspectivas determinariam conjuntos específicos de comportamentos, termos e atitudes. E justificariam definições diferentes para: Escopo de Mudanças; Escopo da Análise de Negócios; Impacto em KA’s; Metodologias e Técnicas; e Competências Fundamentais. Como as Perspectivas não são mutuamente exclusivas, fica a curiosidade em saber como ficaria o caldo no caso de um projeto de BI e de TI guiado por algum método Agile.

Lembrando seus velhos (e maus) momentos, o BABoK oferece um desserviço neste ponto. Que é um tanto comprometedor por falar tanto de tecnologia e muito pouco sobre Negócios. É desta forma que o discurso sobre uma Análise de Negócios ampla, geral e irrestrita (e não mais subordinada a TI) soa falso e cai por terra.

A estrutura original do BABoK, apesar de suas carências, não precisava dessa escora. Precisava, isso sim, rever a maneira como trata a modelagem de negócios. Salpicar o “Pensamento Visual” como uma nova Competência Fundamental ou “Arquitetura de Negócios” como uma Perspectiva é muito, muito pouco.

O Salto que Falta

Acho que ninguém duvidava que a nova versão do BABoK seria consideravelmente melhor que a anterior. Assim como a próxima também será uma evolução. Mas quanto tempo esperaremos por ela? Outros cinco ou seis anos? E a comunidade, como agora, terá generosos dois meses para uma “revisão pública”?

Talvez tenha chegado o momento de discutir uma questão que é maior do que todas listadas acima. Por que o BABoK não vira um Wiki? Por que, a exemplo da Wikipedia, ele não aceita contribuições de todos o tempo todo?

Não acredito em impedimentos financeiros. Vendas do guia não representam nem 10% das receitas do IIBA². E uma versão Wiki não significaria, necessariamente, o fechamento desta fonte de receitas.

Outro fator que deve tornar este momento único – uma janela de oportunidade – é a entrada do PMI no mercado de análise de negócios. Um corpo de conhecimentos de fato aberto e democrático seria uma resposta e tanto. Esperta, no bom sentido, ao reconhecer que sempre haverá mais inteligência fora do que dentro do comitê que elabora o BABoK, por capacitado que ele seja. Seria, acima de tudo, uma resposta catalisadora, que tornaria a comunidade de análise de negócios mais próxima e atuante. O que impede esse salto?

Notas

1. O que não significa que não haverá confusão em outros contextos. Mais sobre isso em um futuro artigo.
2. Em dados de 2012. O relatório financeiro do IIBA é aberto.
3. How to Break In a New Book é uma foto-dica de Jocelyn McAuley.

Curiosa porque trata de uma concorrência entre dois institutos sem fins lucrativos, IIBA e PMI. No entanto, ambos movimentam muita grana e nutrem milhares de negócios mundo afora. Fato que deve tornar esse duelo um tanto mais quente nos próximos meses e anos.

A novidade do PMI não surpreendeu porque parecia um desenvolvimento óbvio. No distante agosto de 2009, em “BABoK: Uma Leitura Crítica”, escrevi o seguinte¹:

O PMBoK é sumariamente ignorado pelo BABoK. Troco, já que o primeiro também ignora o segundo e ainda se mete a falar sobre elicitação (sic) de requisitos? Acho que nunca saberemos. Mas é importante destacar uma terceira perigosa armadilha presente no BABoK. Como vimos, ele possui duas disciplinas, “Planejamento e Monitoramento da Análise de Negócios” e “Gerenciamento e Comunicação dos Requisitos”, de perfil mais gerencial. Ambas invadem o domínio do gerenciamento de projetos sem se preocupar em fixar fronteiras. Criaram pelo menos  duas ‘faixas de Gaza’ e o risco de conflito é alto. Particularmente no que se refere ao gerenciamento e comunicação de requisitos (que inclui a tarefa “Gerenciar Requisitos e o Escopo da Solução”). Viu a palavrinha mágica ali? Escopo!

As faixas de gaza criadas pelo BABoK passaram a justificar eventos e artigos que nos ajudariam a “promover uma convivência pacífica entre gerentes de projetos e analistas de negócios”. Criou-se uma guerra com o objetivo de levantar bandeiras brancas? Se uma função tem caráter gerencial e a outra operacional, por que cargas d’água haveriam conflitos? Não importa mais, o estrago já foi feito.

E a resposta do PMI é pesada. E nem cita o BABoK nominalmente. Ciente do potencial de crescimento da função nos próximos anos², o PMI lança um exame antes mesmo de publicar um BoK ou algo parecido. Por enquanto, ele divulga apenas um esboço (outline) do conteúdo, estruturado em cinco domínios:

• Avaliação de Necessidades
• Planejamento
• Análise
• Rastreabilidade e Monitoramento
• Avaliação (da Solução)

Quem tem um mínimo de intimidade com o BABoK não sentirá dificuldade em fazer um “de-para”. E a relação óbvia das tarefas descritas em cada domínio é com a “abordagem orientada ao planejamento”. Um pouco mais trabalhoso será o relacionamento entre o conteúdo do BABoK e a genérica lista de 40 “Conhecimentos e Habilidades” que encerra o esboço. Se o BABoK tem alguns balaios de gato (Competências Fundamentais e Perspectivas), essa lista do PMI é um primor de confusão. Como nenhum desses “conhecimentos e habilidades” será cobrado diretamente no exame, é de se questionar sua publicação. Para que servem? Se for para desencargo de consciência, esquece. NEGÓCIOS mal são citados ali!

Este será um duelo do tipo Davi X Golias. O PMI tem mais de 500 mil profissionais certificados em todo o mundo. Deve ter batido ou estar em vias de bater o número de um milhão de membros. Suas receitas em 2012 ultrapassaram US$ 170 milhões. O IIBA conta com cerca de 28 mil membros e pouco mais de 3 mil certificados emitidos. Faturou US$ 4,7 milhões em 2012. A diferença de idade – 45 anos de PMI e 10 de IIBA – explica parcialmente a disparidade dos números. Reconhecimento da função, áreas de aplicação e conhecimento da “marca” são fatores que não podem ser menosprezados.

Enfim, o potencial de “estrago” que o PMI pode causar neste mercado é pra lá de considerável. A concorrência é salutar – sempre é – apesar de estranha em um primeiro momento. Se ela se tornou possível é porque um padrão não foi estabelecido. É improvável que isso aconteça em uma área tão ampla e difusa como a análise de negócios. Se a concorrência ajudar a elevar o nível das conversas e, principalmente, da qualidade da análise de negócios praticada, todos sairão ganhando. Sinceramente, eu gostaria de acreditar nisso³.

Notas

1. Por curiosidade reli “BABoK: Uma Leitura Crítica” e todos os 43 comentários que ele mereceu. Que conversa rica. Onde esse tipo de papo tem acontecido atualmente? O que estou perdendo?
2. Nos EUA, esse potencial seria de 19% até 2022, segundo o US Bureau of Labor Statistics. Acho que não temos estudo parecido aqui no Brasil. Mas a revista Você S/A de novembro de 2013 mostrou que analistas de negócios podem ter aumento de salários de até 19% neste ano. Este aumento, três vezes acima da inflação projetada, seria reflexo de uma demanda bem maior que a oferta. A conferir.
3. Mas não acredito. Porque estou cansado de ver certificações sendo usadas como fim, não como meio; Porque não acredito que uma prova de múltipla escolha seja suficiente para definir minimamente quão bom ou ruim é um gerente de projetos ou um analista de negócios; Porque desconfio que o duelo colocado descambará para política, preços, “reputação” e diversos outros fatores, menos para a Análise de Negócios. Enfim, porque tenho muito mais razões para ser cético do que o contrário. Infelizmente. Mas vou torcer para que o IIBA se mexa e resista. Porque acho seu propósito mais nobre e sua visão de análise de negócios mais completa.
4. “White Rabbit vs. Rabbit”, a foto que utilizada neste artigo, é mais uma prova de que a imagem (certa) vale por 916 palavras. Seu autor é JD Hancock.

Driblando a verborrágica definição apresentada no BABoK®, podemos entender que a Análise de Negócios apoia as atividades de descoberta e desenvolvimento de soluções. É natural vincular tal definição ao trabalho em projetos. O BABoK®, em sua versão atual¹, nos empurra neste sentido. O FAN também. Mas este tenta deixar claro que analistas de negócios podem dar contribuições bastante valiosas no dia a dia de uma organização, em áreas como gestão de conhecimentos, gestão de relacionamentos e qualidade, por exemplo. Em empresas prestadoras de serviços eles parecem ter nascido para atividades de pré-vendas. Enfim, a análise de negócios não se limita a projetos.

O BizBok define a Arquitetura de Negócios como um “blueprint que provê entendimento compartilhado da organização e é utilizada para alinhar objetivos estratégicos e demandas táticas”. Apesar de negar essa característica em outros pontos, o BizBok nitidamente apresenta a arquitetura como uma coisa – blueprint – e não um processo. Independente disso é clara a colocação estratégica, a busca por uma alta posição na organização. Posição que não estaria vinculada a nenhum projeto específico. Pela definição acima, a arquitetura gera e define projetos (para alinhar objetivos e demandas).

Seria esta a principal diferença entre análise e arquitetura de negócios? Enquanto a primeira tem caráter operacional e é atrelada a projetos a segunda fica com o filé estratégico, orientando portfólios e iniciativas de grande valor? Não é bem assim.

Uma das primeiras apresentações do arquiteto de negócios soou um tanto patética. O Infoworld, em junho de 2011, apresentou o arquiteto como a profissão mais quente de TI. Mas destacou que ele é “do negócio” e se reporta ao CEO. Como assim, a profissão mais quente de TI não é de TI? O arquiteto seria um tipo de CIO totalmente isento das agruras do dia a dia? Um monte de gente adoraria isso. Mas é por essas e outras que não parece ser uma boa ideia apostar em arquitetos de negócios. O que não nos livra de estudar arquitetura.

A arquitetura nos ajuda a entender, descrever, examinar e explorar negócios. Eu poderia trocar a palavra “examinar” por “analisar”. Isso criaria problemas. Porque permitiria interpretar a análise de negócios como um subconjunto da arquitetura. Não custa repetir: o termo análise é muito ruim e não traduz tudo o que um analista de negócios faz ou poderia fazer. Ele não faz só exames! Assim como ele não se limita a entender, descrever e explorar negócios. O analista precisa resolver problemas. E essa leitura nos permite dizer que a análise de negócios, apesar do nome, é maior que a arquitetura de negócios.

A próxima versão do guia BABoK® propõe entendimento semelhante. Só é uma pena que ela jogue a Arquitetura de Negócios em um balaio chamado Perspectivas que também reúne TI, BI, Agile e BPM². Como ainda não conheço a nova versão, devo conter minhas críticas. Mas não posso deixar de falar que o BABoK®, ao que tudo indica, seguirá maltratando a modelagem e, consequentemente, a arquitetura de negócios.

Porque esta distinção – arquitetura X modelagem – é mais difícil de ser feita. Os objetivos de ambas são idênticos: entender, descrever, examinar e explorar um negócio e seu ambiente. Se utilizamos nomes diferentes, talvez seja porque queiramos livrar uma (a arquitetura) dos vícios e mal entendidos da outra (modelagem). Modelagem sempre teve um vínculo com coisas, com terríveis e temíveis entregáveis (sic). Quase sempre é relacionada com uma documentação que só faz acumular pó. A arquitetura, por sua vez, propõe uma reflexão constante. Pretende ser um processo e também um jeito de pensar negócios. Neste sentido, o analista de negócios deve recebê-la como um novo conjunto de ferramentas. Que o ajudará não só a resolver problemas, mas também a evitá-los. A arquitetura está mais para isso, um “toolkit”, do que para uma “perspectiva” ou um mero “blueprint”.

Só o tempo dirá se as diferenças entre análise e arquitetura de negócios serão interpretadas da forma como foi sugerido acima. Ainda não é possível descartar nem mesmo o surgimento de arquitetos de negócios. Aos analistas deve ficar uma certeza: a arquitetura de negócios precisa ser estudada. Se pretendemos realizar a promessa do BABoK® v3 – catapultar a análise de negócios para uma relevância estratégica – então a arquitetura precisa ser praticada.

Notas

1. Este artigo foi publicado poucos dias antes do lançamento da versão para revisão pública do BABoK v3.
2. Em empresas meio bagunçadas, a contabilidade é repleta de Contas Diversas. O BABoK® já tem uma conta genérica chamada Competências Fundamentais. Agora cria outra, a tal Perspectivas. Se seguir nessa toada, conseguirá bater o recorde de pontas soltas num bok. Atualmente este recorde pertence ao BizBok. Saca só.
3. “better shot of the spiral“, a imagem que ilustra este artigo, é de autoria do zen Sutherland.

Quem explora e desenvolve requisitos deve se preocupar com sete questões fundamentais. São testes executados várias vezes e em diversos momentos de um projeto. Segue a lista¹:

É Necessário?

O requisito realmente dá alguma contribuição, ainda que pequena, para a realização dos objetivos do negócio? Apesar de nossa insistência em perguntar a clientes e usuários pelo valor de cada requisito, a revalidação se paga. Porque podem aparecer funções, atributos ou restrições que, depois de certo tempo, perdem o sentido.

Também não pode existir, em nenhum tipo de projeto, um requisito que não se relacione com nenhum outro. Tratamos aqui de relações de dependência ou complementaridade, como visto anteriormente. Não há uma conta “diversos” em  projetos minimamente sérios.

É Compreensível?

No frigir dos ovos, um requisito é só “uma condição necessária para alcançar certo fim” (Houaiss). Nada justifica que seu entendimento seja difícil. Requisito é informação. E informação é “dado investido de relevância e propósito” (Peter Drucker). Informação é “a diferença que faz diferença” (Gregory Bateson). Por isso enriquecemos cada requisito com um conjunto de características que o explica e justifica: fonte, perspectiva, valor, relações e estado, pelo menos. Cada característica aumenta nossa compreensão sobre o requisito. Claro que, antes de qualquer coisa, a redação do requisito deve ser clara e objetiva. A estruturação não nos isenta da boa escrita.

Está Completo?

Um requisito que apresente pendências não deveria avançar em seu ciclo de vida. O solicitante aguarda alguma informação ou ainda precisa confirmar algo com alguém? Devemos oferecer nosso apoio, resolver as pendências e só então incorporar o requisito.

A recomendação é outra quando a pendência é fruto da insegurança de quem manifestou o requisito. Se é algo de muito valor, então acelere ou antecipe a realização daquele requisito. Coloque-o no topo da fila e faça com que entregas preliminares tranquilizem o cliente ou usuário. Mais sobre isso no último item da lista.

É Verificável?

Se não há a menor ideia sobre como a realização do requisito será testada, é provável que não seja um requisito. Atributos pra lá de ambíguos (tela bonita, processo rápido, operação fácil etc) também comprometem a testabilidade de uma solução. Eles devem ser evitados a todo custo. Todo bom requisito sugere, de maneira clara, pelo menos um teste que comprova sua realização.

É Viável?

O valor atribuído a cada requisito ou grupo de requisitos possibilita seu posicionamento vertical (eixo benefício) na matriz ao lado. Estimativas de custo de cada alternativa de solução² indicam a posição horizontal. Temos assim uma ferramenta que apoia a análise benefício/custo³ de todo o escopo de um projeto.

Pesadelos são descartados sem dramas. Dado o baixo valor agregado de determinado requisito, sua realização só faz sentido quando for uma bobeirinha – algo fácil e barato de construir. É a metade superior da matriz que merece nossa atenção. Se todas as alternativas fossem sonhos, com certeza você não estaria aqui. Projetos dignos de nota sempre oferecem algum tipo de desafio – módulos de muito valor cuja realização envolve alguma complexidade técnica e, consequentemente, alto custo.

Utilizamos valores relativos, tanto para benefícios quanto para custos, quando os números reais ainda estão distantes. Podemos utilizar escalas simples (Fundamental=3, Importante=2, Opcional=1) ou um pouco mais sofisticadas (a sequência de Fibonacci, por exemplo). Esta validação nos ajuda a definir o escopo ideal de uma solução. De quebra, ela sugere prioridades.

Está Priorizado?

A melhor imagem do escopo de qualquer projeto é uma fila indiana. Cada requisito incorporado merece uma posição única. No topo, temos tudo o que é fundamental para a realização dos objetivos do negócio. No fim, tudo o que pode ser cortado sem choro nem vela.

Quando é possível colocar em produção as entregas parciais, então os sonhos serão prioritários. Desta forma antecipamos a realização de valor. Caso contrário – quando tudo deve ser entregue em conjunto – começamos pelos desafios. Depois de entregar o que realmente importa, em havendo tempo e dinheiro, desenvolvemos algumas bobeirinhas.

Está Correto?

Enfim, resta saber se o requisito está correto. E o que garante sua correção? A assinatura do cliente ou usuário no documento de requisitos? Um contrato redigido pelo mais competente escritório de advocacia? Nada disso pode garantir que um requisito esteja correto. Só conseguimos 100% de certeza quando o requisito não é mais “uma condição para alcançar determinado fim”. Só temos total certeza de sua correção quando o fim é alcançado. Isso só é possível com a solução entregue e em funcionamento. O que pode demorar dias, semanas ou até meses para se confirmar.

Tamanha distância não nos livra da busca pela correção dos requisitos. Qualquer coisa – modelos, protótipos, versões alpha e beta e paliativos afins – que minimize o frio na barriga das partes interessadas pode e deve ser utilizada. Desde que haja consciência de que apenas o produto final, devidamente entregue e em funcionamento, terá as respostas definitivas.

Notas

1. A lista acima não tem nada a ver com os famigerados checklists que divertem ou enganam leitores de algumas revistas populares. Porque não é simples como: sim, não, sim, sim, não, não, sim = 17 pontos: tô gordo! Não é possível aplicá-la em um ponto específico do projeto. São validações e testes que analistas e demais envolvidos executam diariamente. Obsessivamente.
2. É de quem vai construir a solução a responsabilidade por apresentar alternativas e respectivas estimativas. Para que esta ferramenta funcione direitinho, a turma de negócio fala sobre benefícios e o time técnico sobre custos. O embate, a tensão criativa, tende a fazer emergir a melhor solução possível.
3. Não estou inventando moda. Foram Tom DeMarco e Timothy Lister, em Peopleware (Dorset House, 1999), que sugeriram a análise benefício / custo. A grafia “análise custo X benefício” carrega dois equívocos: i) a suposta operação ( multiplicação ou subtração) não faz nenhum sentido matemático; ii) a colocação do custo antes do benefício é coisa de gente mesquinha.
4. Este artigo é uma releitura das sugestões apresentadas por Karl Wiegers em Software Requirements (Microsoft Press, 1999).