finito

Tag: Engenharia de Requisitos

  • Precisamos Aposentar o Requisito

    Precisamos Aposentar o Requisito

    Re.qui.si.to s.m. 1 condição necessária para alcançar certo fim; quesito

    Com pequenas variações, é assim que nossos dicionários definem Requisito. A engenharia, segundo a Wikipédia, entende requisito como uma “definição documentada de uma propriedade ou comportamento que um produto ou serviço deve atender.” Daí para entregável (sic) foi um pulinho. Um entregável inegociável, veja bem. Porque a explicação diz que o produto ou serviço “DEVE atender” aquela condição. 

    Requisito nunca foi o nome ideal para embalar as necessidades, vontades e restrições de nossos clientes e usuários, muito pelo contrário. É um termo ruim pelo que significa – uma condição – que piorou com o uso. Passamos décadas culpando os requisitos e quem os verbaliza (e muda!) pelos problemas e fracassos em nossos projetos. Enfim, se palavra tivesse ficha corrida, a do requisito seria tão extensa quanto a especificação funcional dos infernos. O que nos impede de aposentá-la?

    Substantivo Ruim atrai Verbos Horrorosos

    Requisito é campeão neste quesito. Por exemplo: COLETAR REQUISITOS. Nós coletamos lixo; coletamos material para exames clínicos. Pra que colocar requisitos na mesma cumbuca? Além disso, o verbo coletar dá a entender que requisitos são como frutos maduros no pé. Coitados. Eles despencam de velhos. Maduros, nunca estão.

    LEVANTAR REQUISITOS nos leva para um caminho diferente e igualmente mentiroso. Dos 15 (!) significados do verbo levantar apresentados no Houaiss, apenas um nos atenderia parcialmente: listar como resultado de pesquisa. Pesquisar ou investigar (inquiry) fariam melhor serviço do que listar. Quem lista parece estar tirando pedidos. Alguém tira requisitos?

    Dados os mal entendidos e usos, uma turma legal daqui do Brasil achou por bem tropicalizar o verbo to elicit e assim ganhamos o ELICITAR (sic) REQUISITOS. Elicit significa tirar, extrair. A gente tira dentes e extrai leite de pedra. Mas não conseguimos arrancar requisitos não. Ou seja, abrasileirado ou não, o verbo é ruinzinho também. 

    Não é curioso que a gente ignore a sugestão apresentada no título de um dos melhores livros sobre requisitos já escrito¹, EXPLORAR REQUISITOS? 

    Eu costumo sugerir o DESENVOLVER REQUISITOS. Mas não adianta não. Porque requisito, na cabeça de muita gente, continua sendo um entregável inegociável.

    Repare: uma disciplina com tantos anos de vida ainda busca por um verbo para chamar de seu. Dá uma certa vergonha, não dá? Insisto: o que nos impede de aposentar o termo requisito e seus verbos desajeitados?

    Substantivo Ruim Não Funciona, Complica

    Não funciona porque não explica. Ruim que é, acaba ganhando complementos igualmente ininteligíveis. 

    Para descrever tudo o que um produto ou serviço deve fazer usamos a combinação REQUISITO FUNCIONAL. Teria sido bem mais simples falar FUNÇÃO. Mas houve um tempo em que as pessoas eram pagas pelo número de letras digitadas. Houve? Sei lá, é uma explicação plausível para tamanha complicação (19 toques ao invés de 6). Piora!

    Porque todo produto ou serviço é repleto de ATRIBUTOS. Como a gente chama essas coisas? De REQUISITOS NÃO-FUNCIONAIS!?  

    Se a Ideia Ágil nasceu para combater as complicações, e nasceu, então é questão de coerência a eliminação incondicional dessas aberrações. Elas são de outro tempo. 

    Substantivo Ruim é imune aos bons Adjetivos

    Não adianta apelar para REQUISITO ÁGIL. Imagina: REQUISITO ÁGIL NÃO-FUNCIONAL. Se esta foi uma tentativa de gerar um oximoro, tipo silêncio ensurdecedor, não funcionou; E não teve graça também não. Aliás, esse artifício de anexar o adjetivo ÁGIL quase sempre depõe contra o substantivo e todo o seu passado. Se bobear, compromete o seu futuro também. 

    Enfim, parece que não há adjetivo que renove e dê esperanças para a palavra requisito. Requisito merece o mesmo destino do disquete, um museu. Ou o mesmo castigo do termo requerimento, ficar restrito ao uso por juízes e advogados. Precisamos aposentá-la. Neste caso, qual seria a melhor substituta?

    HISTÓRIA

    Kent Beck queria só assim mesmo: HISTÓRIA. Esse negócio de história de usuário veio depois. Desnecessariamente. 

    Mas, por favor, entenda: História não é sinônimo de requisito. Não há uma relação 1:1 entre eles. Uma história pode conter ou esconder diversos requisitos. O que não faz dela um épico – outro engano comum. Uma história pode ser uma pequena crônica, um conto ou um grande romance. 

    Requisitos nos dão a impressão de algo estático. São documentos entregáveis. São condições para a realização de um objetivo. Ponto.

    Histórias são dinâmicas. Você não as levanta, não coleta e nem elicita. Histórias se desenvolvem. Elas são contadas. São feitas de personagens, ação e contexto. Histórias têm sentido!

    Contamos histórias desde que a gente é gente. De certa forma, para o bem ou para o mal, elas nos ajudaram a chegar até aqui. Ainda bem!

    Já pensou se a nossa evolução dependesse de requisitos ágeis não-funcionais misturados com regras de negócios em uma especificação funcional? 

    Notas

    1. Explorando Requerimentos do Sistema foi como essa obra prima se chamou aqui no Brasil. De Donald Gause e Gerald Weinberg (Makron Books, 1991).
    2. Foto de Viktor Talashuk no Unsplash
  • 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.
  • DSRP: Um Caso de Uso

    DSRP: Um Caso de Uso

    No artigo anterior prometi um exemplo de uso do DSRP, modelo que propõe uma atualização do Pensamento Sistêmico. Fiz opção por um tema caro e comum para quase todos que por aqui passeiam: o desenvolvimento de requisitos.

    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.

    DistinçõesTodo 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¹

    SistemasTodo 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

    RelacionamentosSe 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

    PerspectivasComo 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.
  • +Requisitos: Qualidade

    +Requisitos: Qualidade

    Um erro detectado enquanto um requisito é só isso, um requisito, custa $1. O mesmo engano, em fases avançadas de um projeto, pode custar $100, $1.000 ou até mais. O capítulo de hoje da série +Requisitos +Conversas é sobre a qualidade dos requisitos. Quais são as características de um bom requisito?

    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).

     

  • +Requisitos: Os Atributos

    +Requisitos: Os Atributos

    Nos dois capítulos anteriores foram apresentadas as funções – o que um sistema deve fazer – e formas de descrevê-las. A conversa de hoje é sobre atributos, tudo o que caracteriza um produto ou sistema.

    A literatura técnica tradicional costuma tratar atributos como requisitos não funcionais. O termo é ruim e causa certa confusão. Funcional é um adjetivo. Em nosso curioso domínio, não funcional não é sinônimo de disfuncional. Não pode ser. Ninguém pede por algo que não funcione. Recentemente outros nomes foram propostos, como Requisitos Transversais. Esta série adota a nomenclatura sugerida por Gerald Weinberg e Donald Gause em Exploring Requirements¹ (Dorset House, 1989). É deles uma diferenciação bem clara entre funções e atributos: “Um Porshe 911 Carrera tem mais ou menos as mesmas funções de um Fiat 147, mas muitos, muitos atributos diferentes.”

    Atributos são características ou qualidades. São expressos na forma de adjetivos ou advérbios. Dada uma função, é imenso o número de possibilidades de realizá-la. Os atributos reduzem as alternativas e apontam o caminho desejado.

    Dependendo do produto/projeto, a diversidade de atributos pode ser considerável. Pense em um carro, por exemplo: econômico, versátil, seguro, potente, bonito, moderno e ecologicamente correto são alguns requisitos comuns. Cada um deles demanda explicações e estudos bastante específicos. Para sistemas de informação, a lista de tipos de atributos é igualmente extensa: usabilidade, performance, disponibilidade, segurança, confiabilidade, portabilidade, eficiência, manutenabilidade, reusabilidade e flexibilidade são alguns deles.

    Quatro perguntas nos ajudam a começar e direcionar a prosa:

    • Quais características farão desta uma excelente solução?
    • Você já usou algo parecido antes? Se sim:
      • O que mais lhe agradou?
      • O que mais lhe irritou?

    São várias as formas de registro deste tipo de requisito. É difícil indicar a melhor. Mas é muito fácil identificar uma ruim: é aquela onde tudo (funções, atributos, restrições e regras de negócio) está misturado e descrito na forma de texto corrido. Se os requisitos são tratados assim, não surpreende que os sistemas sejam macarrônicos, porcamente acoplados e de cara manutenção.

    Cada tipo de atributo merece tratamento específico. Requisitos de usabilidade, por exemplo, são mais bem expressos na forma de protótipos e storyboards. E por que não registrar requisitos de dados em dicionários de dados e modelos E-R? O fato é que, na maioria das vezes, as transcrições textuais representam puro desperdício.

    Balanço

    Bom, bonito e barato: escolha qualquer par. Este dito ilustra bem outro desafio no trabalho com atributos. O cliente ou usuário não pode ter tudo. É dever de quem desenvolve os requisitos informar sobre as inevitáveis permutas – explicar que a ênfase em determinada característica pode significar perdas em outros pontos.

    Karl Wiegers, em Software Requirements (Microsoft Press, 1999), desenvolveu uma matriz que ilustra impactos positivos e negativos entre os principais atributos de qualidade. A ênfase em reusabilidade, por exemplo, gera reflexos positivos em diversos outros atributos, como flexibilidade, interoperabilidade, portabilidade e manutenabilidade. Por outro lado, resulta em impacto negativo no custo de desenvolvimento. O balanço ideal não ocorre por acaso. Experiências e testes dos pontos mais críticos e de possíveis conflitos é nada menos que uma obrigação de quem desenvolve a solução.

    Restrições

    Vimos anteriormente que todo e qualquer requisito merece ser enriquecido com um pequeno conjunto de informações. Uma delas é o Valor do requisito, que pode ser representado por uma escala simples como Fundamental, Importante e Opcional².

    Todo atributo valorizado como fundamental torna-se uma restrição. Como nos ensina o dicionário, uma restrição é uma imposição de limite. Ou seja, é algo que deve ser respeitado na íntegra pela solução. Demais atributos, de menor valor, podem e devem ser negociados.

    Devemos separar as restrições em dois grandes grupos:

    • Do Sistema: delimitam as fronteiras da solução;
    • Do Projeto: determinam limites do projeto como prazo e custo, por exemplo.

    Cada grupo tem um público específico: o primeiro interessa aos arquitetos e desenvolvedores; o segundo é de quem vai gerenciar o projeto. É curioso como muitos não percebem este segundo grupo como sendo requisitos. Sempre foram. Sempre serão. E geralmente eles são explorados logo no início de um projeto.

    Igualmente curiosa é a confusão entre restrições do sistema e regras de negócio. Quando alguém classifica “o usuário deve estar logado no sistema” como uma regra de negócio a coisa está feia, muito feia. Porque é muito fácil evitar a confusão: desligue o sistema; aquela restrição segue valendo? Então ela é uma regra do negócio. Simples assim.

    Preferências

    A diferença entre o desapontamento e o deslumbramento não é uma questão de entrega, mas de quão bem o produto entregue satisfaz expectativas. Weinberg & GauseO papo sobre restrições, sejam do projeto ou do sistema, costuma incomodar. É uma conversa fria, racional. Mas necessária. Afinal, não existem projetos sem restrições. Para que um evento (entrevista, reunião) de desenvolvimento de requisitos não termine de forma chata, deixamos para o final um assunto mais quente: as preferências de clientes e usuários. Fazemos duas perguntinhas básicas:

    • Qual é a sua maior expectativa em relação a esta solução?
    • Que parte da nova solução será mais valiosa para você?

    As respostas devem permitir o destaque das funções e atributos que merecerão maior atenção. O trabalho de gerenciamento de requisitos não pode ser visto como uma coisa mecânica – tá pronto / não tá pronto. Gerenciar requisitos significa, em grande medida, gerenciar expectativas.

     

    Notas

    1. Este livro foi publicado no Brasil em 1991 pela McGraw-Hill com o título Explorando Requerimentos de Sistemas. Está esgotado, mas pode ser encontrado nos sebos da vida. A edição eletrônica foi dividida em duas partes. Trata-se do mesmo texto original.
    2. Existem n variações de escalas para avaliação e priorização de requisitos. Como sugerido anteriormente, podemos utilizar a escala de Fibonacci. O método MoSCoW também é bastante conhecido.
    3. A série aproxima-se do fim. Enfim! Além dos famigerados exemplos, o que mais você gostaria de ver por aqui? Qual tema merece mais alguns dedos de conversa?

     

  • +Requisitos: Contando Histórias

    +Requisitos: Contando Histórias

    O artigo anterior apresentou as Funções – os trabalhos que alguém precisa executar. Hoje veremos as opções que temos para registrar esse tipo de requisito. Conceitos básicos sobre como contar um tipo muito especial de história.

    O ato de contar histórias é quase tão antigo quanto andar para frente. Contando histórias nós informamos, ensinamos ou divertimos. Há uma estrutura clássica para histórias que pretendem informar. Elas devem responder a uma sequência pré-determinada de questões: o quê? quem? quando? onde? como? por quê? Este padrão, parte do que é conhecido como pirâmide invertida, foi lançado pelo jornal New York Times em 1861. É utilizado por jornalistas desde então. Variações da sequência surgiram como ferramentas no mundo dos negócios na segunda metade do século passado. Elas ficaram conhecidas por siglas como 5W2H e 6W, por exemplo. Mais recentemente, em The Back of the Napkin (Portfolio, 2008), Dan Roam utilizou a neurociência para justificar sua versão das questões. Em relação à pirâmide invertida original ele apenas trocou a posição das perguntas quando e onde. Se há uma estrutura relativamente bem consolidada para a narração de histórias, por que precisaríamos de algo diferente para o registro de requisitos – das necessidades, desejos e restrições de clientes e usuários?

    Diz a lenda¹ que no final dos anos 1960 Ivar Jacobson, trabalhando em uma empresa de telecomunicações sueca, deu à luz uma ferramenta que apoia os trabalhos de descoberta e descrição dos requisitos funcionais de um sistema. A ferramenta se chama Especificação de Casos de Uso – Casos de Uso para os íntimos. Causo para todos que já frequentaram uma turma do FAN. O termo, bem caipira, serve para a rápida vinculação com histórias curtas narradas em linguagem coloquial. Um caso de uso típico apresenta a seguinte estrutura:

    • Nome do Caso de Uso (O quê?)
    • Objetivo (Por quê?)
    • Ator(es) (Quem?)
    • Fluxos Principal e Alternativos (Como?)

    Comparado à pirâmide invertida, o caso de uso carece de duas informações que ajudariam a entender melhor o contexto: quando e onde. Apesar deste e de alguns outros pesares, esta é a melhor ferramenta para os trabalhos de descoberta e descrição de funções. É uma pena que nosso incurável gosto por coisas “sofisticadas” a tenha complicado demais. Inventamos n nomes para os fluxos (os comos), casos de uso de negócio (uma aberração²) e outras tantas coisas que só bagunçaram o coreto. Não por acaso, são muitos os profissionais que nutrem verdadeiro ódio pela ferramenta. Devo fazer um mea culpa: o modelo que utilizo poderia ser um pouco menos rebuscado. Mas, como explico em sua apresentação, a principal finalidade é didática. E ele tem funcionado bem assim.

    Com a intenção de contrapor as intermináveis “especificações funcionais” inventamos as Histórias de Usuários (User Stories). Sua mensagem é clara: trocamos trocentas páginas de documentos por maior proximidade e mais conversas com clientes e usuários. As histórias são formadas por três componentes: um cartão (onde a história é descrita); as conversas (motivadas pela história); e a confirmação (testes que devem verificar a realização da história). Uma história padrão é contada da seguinte maneira:

    • Como um (Quem?)
    • Eu preciso/quero  (O quê?)
    • De forma a realizar (Por quê?)

    Além das mesmas omissões que vemos em casos de uso, as histórias também abrem mão do como. Talvez seja importante dizer que isso não é uma falha e sim uma característica intencional. O desenvolvedor que deve realizar uma história tem total liberdade para experimentar. Para funcionar bem as histórias de usuários apresentam um pré-requisito fundamental: a proximidade e intensa participação de clientes e usuários. Quando isso não é possível, o número de idas e vindas (ou seja, de experimentações) pode ser muito maior do que o desejável.

    O bode que as histórias de usuários tiraram da sala, a sua maior diferença em relação aos casos de uso, é a descrição do como: como um ator (perfil/usuário) utilizará determinada função. Esta é de fato a parte mais complexa de qualquer história. É também a porção dos casos de uso que mais sofreu nas mãos de “inventores”. Cabe um pequeno exemplo. Por diversas vezes questionaram o pequeno espaço que dedico para o “caminho feliz” (o fluxo principal de um caso de uso). Citando Coplien e Cockburn³, insisto que o fluxo principal não deveria ter mais que sete ou nove passos. Algumas pessoas acham isso arbitrário demais e seguem questionando. O que me obriga a apelar: se não estamos desenvolvendo um videogame (único caso em que faz sentido dificultar a vida do usuário em seu caminho para realizar determinado objetivo), devemos sempre buscar o caminho mais curto possível. Já pensou se você tivesse que dar doze cliques para comprar um livro na Amazon? Até quem construiu os quase sempre disfuncionais caixas automáticos e bancos eletrônicos não ousou ultrapassar o limite de nove passos para a realização de uma transação. Por que você o faria?

    Epílogo

    Organizações são únicas, assim como projetos e histórias. Acreditar em um padrão universal para o registro destas é como crer em Papai Noel. Me contradigo? Afinal, escrevi ali em cima que “a especificação de casos de uso é a melhor ferramenta para a descoberta e descrição dos requisitos funcionais de um sistema”. Sustento minha colocação em duas características dos casos de uso: 1) Não somos obrigados a escrever muito nem muito pouco. Distância e constância da participação de clientes e usuários são os únicos fatores que determinam quanto devemos escrever; 2) Podemos criar um modelo que atenda necessidades específicas de uma organização, equipe ou projeto.

    E o que dizer da deficiência apontada acima, da falta de um lugar para registrar onde e quando? Oras, nada o impede de criar este espaço e chamá-lo de Contexto. Tanto melhor se você referenciar o processo de negócio suportado no causo. Melhor ainda se você combinar presente (as-is – processo de negócio) e futuro (to-be – requisitos) em uma visualização única (PUCS – Process-Use Case Support). Há muito tempo aprendemos que uma história que pretende informar obrigatoriamente responde a seis perguntas básicas. Por mais que gostemos de reinventar a roda, devemos respeitar o óbvio: a roda é redonda; Uma história tem seis respostas.

    Notas

    1. A lenda fala em final dos anos 1960. Na história devidamente documentada, a especificação de casos de uso foi formalmente apresentada por Ivar Jacobson em 1986.
    2. Casos de uso de negócio são uma aberração. Porque a ferramenta caso de uso trata o sistema (negócio) em discussão como uma caixa preta – não queremos nem precisamos ver seu interior, não precisamos entender como o sistema (negócio) realizará determinada função. Nos interessam apenas as interações entre usuário e sistema (negócio). Quando estudamos um negócio, queremos e precisamos entender como ele funciona. Por isso não faz o menor sentido tratá-lo como uma caixa preta.
    3. Em Lean Architecture (Wiley, 2010) e Escrevendo Casos de Uso Eficazes (Bookman, 2006), respectivamente.
  • +Requisitos: As Funções

    +Requisitos: As Funções

    Finalmente retomo a série sobre Requisitos e Conversas. O tema de hoje são as funções. Depois de descobrir por que determinada solução é necessária, devemos nos concentrar no que ela deve realizar.

    Vale a pena relembrar o mapa que guia esta série. No lado esquerdo do diagrama temos a representação do destino da solução. Vemos ali um negócio qualquer² desenhado no mais alto nível possível. Enxergamos apenas seus quatro componentes fundamentais: Objetivos, Recursos, Processos e Regras. Este bloco possui duas ligações com o conjunto de requisitos (em azul). A primeira mostra os Requisitos do Negócio representando os Objetivos. Hoje nos interessa a segunda relação, aquela que diz que Funções suportam Processos de Negócio. Em outras palavras, uma função ajuda alguém¹ a realizar determinado trabalho.

    Função, segundo o Houaiss, é “o uso a que se destina algo”. Uma função sempre representa uma ação. Em conjunto, as funções são tudo o que um sistema deve fazer. Descobri-las é um trabalho relativamente simples. As perguntas que nos ajudam a chegar a elas são:

    • O que o produto/sistema deve fazer por você?
    • Como você gostaria de usar este produto/sistema?
    • O que o produto/sistema não deveria fazer?

    O “relativamente simples” do parágrafo anterior a(o) incomodou? É provável que sim. Afinal, a grande maioria das pessoas que trabalha com requisitos não vê simplicidade em quase nada de seu dia a dia. A complicação neste ponto vem das respostas dos entrevistados. Clientes e usuários não estão acostumados a estruturar suas respostas. Atributos, restrições, preferências, regras de negócios e, não raro, comentários inteligentes sobre a instabilidade do mundo (do clima, dos negócios, do humor do cônjuge etc) vão completar e poluir as funções pedidas. É responsabilidade do analista a faxina em cada resposta. Ele sabe que o trabalho será menos árduo se suas perguntas forem boas.

    A última questão nos lembra que tão importante quanto saber tudo o que o produto/sistema deve realizar é entender o que ele não deve fazer. No trabalho de desenvolvimento de requisitos é crucial que estas questões sejam colocadas em sequência durante um mesmo evento (reunião, entrevista). Desta forma orientamos clientes e usuários a pensar em um número maior de possibilidades.

    Mas, existem casos em que os entrevistados simplesmente não sabem o que pedir. Casos onde não obtemos respostas para as questões acima ou, pior ainda, as respostas são incompreensíveis. Momento de tirar da cartola duas solicitações mágicas:

    • Prezado , por favor, me conte como você trabalha hoje; ou
    • Me mostre como você trabalha hoje

    Se a história motivada pela primeira solicitação não fizer muito sentido, lançamos mão da segunda.  É quando utilizamos a ferramenta social Observação (apresentada anteriormente nesta série). A quantidade de ruídos gerada a partir dessas solicitações é potencialmente maior que aquela originada das três questões anteriores. Por outro lado, a história narrada ou observada pode ser mais conclusiva. De uma forma ou de outra, a história precisa ser registrada. Como fazê-lo? Veremos no próximo capítulo.

    A Nomenclatura Utilizada

    Por que não “Requisitos Funcionais”? A distinção entre requisitos funcionais e não-funcionais é meio grosseira. E cria muita confusão, apesar de ser a nomenclatura mais comum em nossos livros técnicos. Por isso esta série adota os termos sugeridos por Gerald Weinberg e Donald Gause no melhor livro sobre requisitos já escrito, Exploring Requirements – Quality Before Design (Dorset House, 1989).

    A palavra “funcional” adjetiva algo – o qualifica. Ela anda na moda. Tanto que hoje em dia temos até iogurtes funcionais!

    Jobs-to-be-done

    O cliente não quer uma broca com ¼ de polegada, quer um furo de ¼ de polegada. Theodore LevittEm conversas sobre marketing e inovação o termo jobs-to-be-done (trabalhos a executar) é colocado como se fosse um ovo de Brunelleschi³. Quase sempre acompanhado da famosa frase do Levitt. Faz sentido trazer esse papo para cá e fazer duas observações. Uma função é um job-to-be-done – um trabalho que o cliente ou usuário precisa executar. Peço perdão pela obviedade, mas esta primeira observação se fez necessária.

    A segunda tem a ver com a frase do Levitt. Pense bem, o que o cliente fará com o furo de ¼ de polegada? Qual é a sua real necessidade? Pendurar um quadro, uma prateleira? Ou espiar a formosa vizinha?

    Notas:

    1. Não me esqueci de quem utilizará as funções. O tema já foi tratado anteriormente, por isso não fará parte desta série.
    2. Se tirarmos as Regras, aquele mágico metamodelo rabiscado acima representa qualquer tipo de destino, ou, melhor dizendo, qualquer tipo de sistema (você, um hardware, uma cidade – enfim, qualquer tipo de sistema).
    3. Colombo ficou com a fama, mas foi o arquiteto italiano Brunelleschi quem primeiro colocou um ovo em pé. O fez para ilustrar como construiria o famoso domo da Catedral de Florença. E não, esta informação não aparece em Inferno, de Dan Brown.

     

  • +Requisitos: Outro Exemplo

    +Requisitos: Outro Exemplo

    Eu deveria saber que a enésima releitura do causo do Seu Moreira não me daria um pingo de motivação para criar os necessários exemplos da série +Requisitos +Conversas. Além disso, aquela história é longa e relativamente complexa. Minha intenção nesta série é fixar conceitos básicos. Um estudo de caso extenso me afastaria do que é realmente importante. Portanto, a partir deste capítulo apresento um novo problema que deve servir para ilustrar as sugestões já publicadas e todas que estão por vir.

    Antes, um aviso: os exemplos ficam mais ricos quando elaborados por mais de uma pessoa. Ao colocar dúvidas, sugestões ou críticas, você puxa a história para lugares que este escriba, por mais que se esforçasse, nunca imaginaria. Sigo contando contigo.

    Que tal um problema que afeta oito em cada dez adultos? Muita gente tem problemas para organizar seu dia a dia. Eu sei que na Web e nos modernos mercadinhos de aplicações já existem centenas ou milhares de organizadores pessoais. Conheço gente que tem uns dez aplicativos deste tipo instalados em seus smartphones e tablets e segue sem entender porque seu dia é tão bagunçado. Então, por que não tentar desenhar o melhor organizador pessoal de todos os tempos desta semana?

    Meu caro, jogue fora todas as suas ideias pré-concebidas e seja neutro. Você sabe por que este copo é útil? Porque ele está vazio. -Bruce LeeConseguiríamos fazer algo diferente e realmente útil? Neste momento, temos apenas uma folha em branco e uma ideia na cabeça: “organizador pessoal”. Esta ideia é um requisito? Claro! Mas está tão aberto, tão ambíguo, que pode nos levar para qualquer lugar – de uma cadernetinha de papel até um sofisticado sistema para celulares espertos. Vimos em um capítulo anterior que neste momento – quando um nome para a solução é cogitado – as primeiras suposições se consolidam. Isso pode ser um perigo¹.

    Mas é o que temos aqui e em muitos projetos em seu dia zero. Como reduzimos a ambiguidade e o risco das suposições equivocadas logo de cara? Fazendo boas perguntas. Para quem? Neste novo caso teremos duas fontes principais. A primeira eu espero que seja você. A outra fonte será representada por alguns personagens fictícios². Segue um breve papo com o primeiro, Zak, o consultor enrolado:

    – Zak, o que é um organizador pessoal para você?

    – Uma ferramenta que me ajude a listar tudo o que preciso fazer em um dia, na semana e no mês. 

    – Qual ou quais problemas essa ferramenta resolveria?

    – O primeiro é não me deixar esquecer das coisas importantes que preciso fazer. Ele deve me lembrar e cobrar, como se fosse uma atenciosa e chata esposa.

    –  Existem outros (problemas)?

    – Sou meio desorganizado e atendo clientes e projetos diferentes. Queria poder organizar minhas pendências assim, por clientes e projetos.

    Sik, um gripado e sobrecarregado gerente de projetos ouviu a conversa e imaginou outras utilidades para a ferramenta:

    – O Zak falou sobre projetos. Sabe, nunca vi uma ferramenta simples e eficaz que me ajudasse a gerenciar o que precisa ser feito e facilitasse a comunicação com a equipe. 

    – Puxa Sik, mas existem tantas desse tipo por aí. Por que elas não te atendem?

    – São burocráticas demais. Exigem n cadastros e coisas assim. E são travadas em um tipo de visualização do projeto que raramente me diz alguma coisa, os tais gráficos Gantt. Sabe, ando numa onda mais light. Queria ver só um lista simples com uma classificação idem: O que precisa ser feito, O que está sendo feito, O que está sendo testado, O que foi entregue – só isso.

    – Zak, essas necessidades do Sik, se atendidas, nos desviariam muito do atendimento de suas necessidades?

    – Acho que não, pelo contrário. Essa ideia de ver a situação, o estágio atual de cada pendência, é uma boa. Mas o que mais gostei foi do papo sobre facilitar comunicações. Eu poderia passar pendências para meus clientes e colegas diretamente da lista? Isso seria uma maravilha.

    – Porque evitaria o uso de outra ferramenta, né? O fatídico email… – disse Sik.

    Repararam como um único olhar de fora chacoalhou as definições anteriores? O que era, em um primeiro momento, um organizador pessoal, se transformou em uma ferramenta para um gerente de projetos. Isso é bom ou ruim? Na maioria das vezes, é mais que desejável. Porque ainda não nos comprometemos com nada. Nossa folha ainda está em branco. E, por enquanto, estamos buscando apenas um bom entendimento do problema ou dos problemas que precisam ser resolvidos.

    O que nos traz para um outro problema: você! Esta ferramentinha teria alguma utilidade para você? Você imagina outros problemas que ela ajudaria a resolver? Você pode me ajudar a contar essa história?

     

    Notas

    1. Uma vez fui deslocado para gerenciar um projeto porque o importante CIO daquela multinacional havia dito que se tratava de uma iniciativa de Business Intelligence. BI era a sigla da moda naquela época. Passados uns dois meses, quando finalmente aquele time de TI parou de barrar nosso contato com os usuários de verdade, descobrimos que o projeto não tinha nada, nadinha mesmo de BI. Nada de cubos OLAP, dashboards executivos ou coisas do tipo. Praticamente todo o trabalho estava condenado porque duas palavrinhas (ou duas letrinhas) plantadas lá no início guiaram a formação do time, o processo de desenvolvimento de requisitos e toda a arquitetura da solução.
    2. Os personagens fictícios servirão como bela deixa para que possamos explorar uma ferramenta muito útil quando não temos usuários disponíveis para basear o desenvolvimento de requisitos. Personas será o tema do próximo episódio. Até lá, vale a pena dar uma olhada nesta apresentação.
    3. Espero que esta não seja sua única motivação: a melhor colaboração colocada na forma de comentário neste artigo merecerá uma vaga em qualquer treinamento FAN agendado para as cidades de São Paulo ou Curitiba. A vaga é pessoal, intransferível e inegociável. Como todos os comentários são públicos, você saberá os critérios que utilizei para fazer a seleção.