finito

Categoria: Requisitos

  • +Conhecimento sobre Requisitos

    +Conhecimento sobre Requisitos

    No capítulo anterior vimos conceitos básicos sobre dois elementos fundamentais para o trabalho com requisitos: Informação e Comunicação. O tema de hoje é Conhecimento – o que devemos aprender e desenvolver sobre cada requisito de um projeto. O papo será mais prático, podes crer.

    Como a conversa no artigo anterior ficou bem “matemática”, segue mais uma fórmula:

    Requisito = (Informação * Confirmação) – Ruído

    Vimos na introdução desta série que a informação representada por um requisito é uma “condição necessária para alcançar certo fim”. Depois, vimos que este “certo fim”, em nosso contexto, é um conjunto de objetivos do negócio. Objetivos que podem ser detalhados e organizados na forma de requisitos do negócio. É suficiente, para o desenvolvimento e condução de um projeto, que se conheça apenas essas informações (condições e fins) devidamente confirmadas e livres de ruídos? Sim, desde que interpretemos a variável “informação” da fórmula acima de uma maneira bem ampla.

    Se você não aprender corretamente os requisitos, não fará a menor diferença o quão bem trabalhe no restante do projeto. -Karl WiegersÉ relativamente comum que se conheça muito pouco sobre um requisito. Assim como são irritantemente corriqueiras as longas e amorfas transcrições textuais transmitidas e recebidas como sendo os “requisitos” de um projeto. É difícil encontrar bons requisitos nesses catataus.

    Assim como será praticamente impossível encontrar um cliente ou usuário que, durante a exposição de seus objetivos e condições, aja mais ou menos assim: “Vou relacionar os requisitos funcionais, anota aí. Prepare-se para os não funcionais. Agora, às restrições. Por fim, falemos sobre regras de negócio”. Este usuário não existe. E não precisa existir!

    Cabe ao analista os processos de estruturação e enriquecimento dos requisitos. Aliás, se ele fizer só isso por um projeto já terá justificado seu salário. Se você acha que isso é muito pouco, por favor, continue lendo.

    Estruturar significa organizar – separar os mais diversos tipos de requisitos e demais informações. Porque cada um deles merecerá um destino diferente. Porque cada um pede tratamento e ferramental específicos. Veremos isso nos capítulos sobre Funções, Atributos, Preferências e Restrições.

    Enriquecer significa obter mais informações e confirmações (feedback) sobre cada requisito. O diagrama ao lado ilustra sete atributos que todo e qualquer requisito (de todo e qualquer projeto) deveria merecer.

    Tipo

    Aqui simplesmente colocamos cada requisito em sua devida caixinha. Na classificação mais básica possível teríamos: Requisitos do Negócio, Funções, Atributos e Restrições. Quem quiser ser mais específico pode diferenciar requisitos de usabilidade, de dados, telas, relatórios, integração, transição, segurança etc. No modelo proposto por Suzanne e James Robertson¹ existem apenas: Restrições, Requisitos Funcionais, Não Funcionais e de Tecnologia. Com certeza há uma separação e nomenclatura mais adequadas para sua organização ou projeto. Esta série utilizará a primeira lista acima em todos os exemplos.

    Fonte

    O nome de quem manifestou aquele requisito pela primeira vez. A tabelinha² Fonte pode, obviamente, ser completada por outras informações como cargo, departamento etc. Em alguns casos não é possível identificar uma pessoa. Quando tudo o que um analista tem em mãos é um edital, por exemplo. Nessas situações (terríveis) registramos apenas o documento e, eventualmente, capítulos e páginas.

    Só não recomendo que se registrem aqui informações sobre o impacto que o projeto terá sobre a pessoa e sua influência. Porque são informações do tipo caixa preta que deveriam ser persistidas em um local menos público.

    Perspectiva

    É o ponto de vista defendido pela fonte. Sugiro uma distinção bem simples:

    • Estratégica: a pessoa está no topo da pirâmide organizacional, é proprietária ou da alta direção.
    • Tática: gerentes, coordenadores ou supervisores. A pessoa está no escalão intermediário.
    • Operacional: na base da pirâmide, onde ficam todos que de fato colocam a mão na massa (ou  no martelo).

    Além dessas, podemos ter perspectivas que não participam diretamente do negócio. Legal, por exemplo, para representar o corpo jurídico da empresa; Técnico para diferenciar todos os requisitos que vieram de TI e assim por diante. Em cada organização ou projeto podem existir pontos de vista diferentes que merecem destaque.

    Repare no diagrama acima que, apesar de qualificar a Fonte, a Perspectiva é um atributo do Requisito. É o primeiro mecanismo do modelo que visa a resguardar a história do projeto. Quando uma pessoa for promovida, mudando assim sua perspectiva, não levará consigo seus antigos requisitos. Fica registrado que, quando aquela pessoa manifestou determinado requisito ainda defendia o ponto de vista “operacional”, por exemplo.

    Valor

    Todo requisito tem um valor (benefício) e um custo. Representamos aqui qual é a contribuição de determinado requisito para a realização dos objetivos do negócio. Podemos utilizar uma escala bem simples, como:

    • Fundamental: a não realização deste requisito resultará em fracasso do projeto. Sua satisfação é incondicional.
    • Importante: este requisito não dá uma contribuição direta para a realização dos objetivos do negócio. É uma função ou característica que pode ser entregue em outro momento. Ainda assim, por algum motivo, ela é importante para o cliente ou usuário.
    • Opcional: requisito que não representa nenhuma contribuição direta ou indireta para a realização dos objetivos do negócio. Deve ser percebido apenas como algo que agradaria o cliente ou usuário caso haja tempo e dinheiro para sua realização.

    Quem precisar de uma escala maior pode utilizar, por exemplo, a sequência de Fibonacci. Costumo recomendar um pequeno subconjunto: 1, 2, 3, 5, 8, 13. Em situações que envolvam quatro ou mais interessados (proponentes de requisitos), sugiro também o uso do Planning Poker para a valorização das necessidades e restrições apresentadas. Geralmente esta ferramenta é utilizada apenas para estimativas de esforço, o que é um desperdício. Quando utilizamos unidades relativas, é importante que valor (benefício) e estimativas (custo) sejam medidos com a mesma régua. Tanto melhor se utilizarmos o mesmo método. No capítulo sobre estimativas e planejamento isso será melhor explicado.

    Este assunto merece livros inteiros. Porque está aqui boa parte dos problemas que presenciamos em projetos. Quanta grana se desperdiça com funções que raramente ou nunca são utilizadas; Quanto tempo é perdido em requisitos que representam nada ou muito pouco para a solução do verdadeiro problema; Enfim, como faz falta uma visão compartilhada sobre aquilo que realmente interessa em um projeto.

    Em praticamente tudo o que compramos ou construímos há prioridades e alternativas. Na lista do supermercado, no carro ou na casa nova pensamos em itens fundamentais, importantes e supérfluos ou opcionais. É curioso como no mercado de software sobrevive, por muito tempo, um jogo de tudo ou nada. Curioso porque software é infinitamente mais maleável que casas, carros e listas de supermercado.

    O que deve ficar, neste ponto, é a consciência de que esta pergunta – “Ilmo. Sr. Usuário, quanto vale esta solicitação?” –  deve ser feita. Imediatamente após a apresentação do requisito. O cliente ou usuário pode se enganar ou, em raros casos, tentar ludibriar o analista. Momento este que aciona o lado crítico do analista: “Me explique, caríssimo Usuário, como a função X (ou o atributo Y) ajudará a ACME a aumentar em 30% o faturamento”. Sim, os objetivos e requisitos do negócio devem balizar todos os demais requisitos. Não há outra maneira de analisar e de fato criticar e priorizar requisitos. Não há!

    Relações com os Outros Requisitos

    Se através do Valor rastreamos cada requisito na vertical (entendendo sua contribuição para a realização dos objetivos do negócio), está naquele pequeno círculo incompleto a rastreabilidade horizontal. Ou seja, o tipo de relacionamento que determinado requisito tem com todos os demais. Quando existe, a relação pode ser de:

    • Dependência: a realização do requisito B depende da realização do requisito A. É através deste mecanismo que agrupamos requisitos, formando um módulo ou uma funcionalidade completa, por exemplo.
    • Complementaridade: a realização do requisito A facilita a realização do requisito B ou simplesmente o completa. Aqui também sinalizamos um agrupamento, desta vez com elementos levemente acoplados.
    • Redundância: requisitos A e B, apesar de uma possível redação diferente, representam a mesma condição – necessidade ou restrição. Portanto, um deles deve ser excluído* do escopo do projeto.
    • Conflito: o requisito A impede a realização do requisito B. Este conflito normalmente se dá entre funções e atributos ou, principalmente, entre funções e restrições. E, infelizmente, boa parte deles só pode ser identificada na bancada de testes. Ainda assim, é recomendável que o analista fique atento aos conflitos em potencial. E registre-os.
    • Substituição: o requisito B substitui o requisito A. Está aqui o mais importante mecanismo de proteção da história do projeto de todo o modelo proposto. Uma vez registrado, nunca mais o requisito deveria ser editado ou apagado. Se determinado requisito precisa ser alterado por algum motivo qualquer, deveríamos registrar um novo requisito e indicar que ele substitui um ou mais existentes. Anotando cuidadosamente o motivo da alteração. No meio de tanto bafafá sobre gerenciamento de mudanças, normalmente perdemos o essencial: uma mudança é, antes de tudo, um requisito. Por isso, deveria ser tratada da mesmíssima maneira (no mínimo).
      * Portanto, o excluído daquela frase deve ser interpretado como uma desativação do requisito mas não sua exclusão física. Porque pode ser bom lembrar e medir, por exemplo, quanta redundância se originou do trabalho de diversos analistas entrevistando diversas pessoas.

    Há outro tipo de rastreabilidade, igualmente necessária mas não contemplada nesta sugestão. Ela trata do relacionamento entre requisitos e elementos da solução. Quem sabe usar (direitinho) a UML não precisa se preocupar com isso. Os demais ficarão com uma bela pulga atrás da orelha.

    É bastante provável que neste momento lhe tenha caído uma ficha: “Caramba! Quanto trabalho!” Entendeu agora porque um analista de negócios ganha tão bem? Brincadeirinha… A mensagem é outra.

    O diabo está nos detalhes. Em projetos, cada requisito é um conjunto de detalhes. O dito cujo se lambuza.É impossível – repito, é impossível realizar este trabalho de análise em um lote muito grande de requisitos. O bom profissional deve saber que boa parte do trabalho de análise de requisitos ocorre em paralelo à elicitação (sic 100x!), ou seja, no momento em que um requisito aparece ele já começa a ser analisado (estruturado, enriquecido, relacionado… você entendeu). A outra boa parte do trabalho de análise de requisitos ocorre imediatamente após um evento de coleta (sic 1000x!)³. Enquanto as informações ali aprendidas ainda estão frescas na memória dos participantes e, principalmente, dos analistas.

    Outra mensagem: se o analista envolvido com requisitos não faz este trabalho ele não está fazendo seu trabalho. Ponto!
    Não há análise, seja de requisitos ou de negócios, feita no atacado, por cima, nas coxas…

    Testes

    E por falar nas coxas… Hora de conversar um pouco sobre testes. Lembra-se da fórmula que abriu este capítulo?

    Requisito = (Informação * Confirmação) – Ruído

    Os testes são os grandes responsáveis por gerar confirmação e também por subtrair ruídos dos requisitos. Não por acaso, é o único atributo do modelo sugerido que mantém relação de muitos para muitos com os requisitos. Este tema também merecerá um capítulo só seu. Por enquanto, é importante o entendimento de que os testes ocorrem em diversos momentos e com propósitos distintos. No início, durante uma entrevista, por exemplo, testamos um requisito no sentido de confirmar i) Nosso entendimento; e ii) Sua (do requisito) real necessidade. Nos momentos seguintes, de forma isolada ou em conjunto, os requisitos são submetidos a baterias de testes que visam a i) Confirmar nosso entendimento; e ii) Confirmar a sua (do requisito) realização.

    Teste é sinônimo de confirmação, feedback, refinamento e aprendizado. Não deveria estar relacionado com coxas.

    Estado

    Enfim, o último atributo básico que todo requisito deveria merecer. Aqui simplesmente posicionamos o requisito em um momento de seu ciclo de vida. Podemos utilizar a mesma nomenclatura das divisões de um quadro kanban, por exemplo: Em Espera; Em Execução; Em Testes; Entregue. Claro, sua organização ou projeto pode requerer uma visão diferente, mais detalhada. O importante é que se saiba, a qualquer momento, qual o estado de cada requisito.

    A Tabela Central

    A tabela² Requisitos possui, além das diversas chaves estrangeiras (ligações com outras tabelas), alguns campos próprios. Mantendo o padrão, relaciono abaixo o que considero o mínimo necessário:

    • Número: sequencial, por ordem de entrada. Serve apenas para identificação e não tem relação nenhuma com a Ordem (posição do requisito no escopo do projeto ou backlog do produto).
    • Descrição: breve texto que exprime aquela necessidade ou restrição. Existem regrinhas de padronização para cada tipo de requisito. Veremos isso no momento oportuno.
    • Justificativa: explicação (opcional) para o requisito. É um campo texto, livre.
    • Material Complementar: Lista (opcional) de links e referências para fontes que completem o entendimento do requisito.
    • Versão: Número da versão do requisito. Cada substituição inserida (veja Relações entre Requisitos acima) se reflete aqui.
    • Analista: Nome (ou código) do analista que efetuou o registro do requisito.
    • Timestamp: (Agora exagerei. Perdão).

    Revendo Tudo

    • Informação é diferença que faz a diferença. (Gregory Bateson)
    • Informação é dado investido de relevância e propósito. (Peter Drucker)
    • A conversão de dados em informação requer conhecimento. (idem)
    • Informação é a principal matéria prima de projetos.
    • Comunicação = Informação * Relacionamentos * Confirmação (Jurgen Appelo)
    • Comunicação (em Projetos) = Requisitos * Relacionamentos
    • Requisito é informação devidamente confirmada e livre de ruídos.
      Requisito = (Informação * Confirmação) – Ruído
    • Requisito, enquanto informação estruturada e enriquecida, é conhecimento produzido por conhecimento.
    • Conhecimento é a capacidade de agir. (Karl-Erik Sveiby)

    Depois deste tour de force, quem sabe o que virá a seguir?

     

    Notas

    1. Em Requirements-Led Project Management (Addison-Wesley, 2005). É do casal Suzanne e James Robertson o modelo Volere, um “modelo de conhecimentos de requisitos” mais completo (e mais complicado) do que o que é sugerido nesta série. Não gosto da forma como o modelo do negócio é (mal) tratado no Volere.
    2. A sugestão aqui apresentada foi concebida, há mais de dez anos, como um modelo E-R (entidade-relacionamento). Quando ela deixou o laboratório e ganhou as ruas, através do treinamento {FAN}, manteve o desenho original. Para surpresa deste que aqui rabisca, o formato se provou bastante didático. No entanto, peço desculpas se a terminologia técnica ou as bobas explicações sobre ela causaram chateação, desconforto ou dúvidas. Neste caso, sou todo ouvidos.
    3. O termo elicitação não existe em língua portuguesa. E sua criação, convenhamos, é totalmente desnecessária. Não porque utilizamos coleta em seu lugar. Mil vezes não! Coletamos lixo ou material para exames clínicos. Não coletamos requisitos.
      Essa terminologia, particularmente a separação entre elicitação e análise de requisitos, é herança maldita das cascatas e cascateiros. No longínquo 1989, Donald Gause e Gerald Weinberg já nos mostravam a correção do termo Explorar requisitos (Exploring Requirements – Quality Before Design. Dorset House). São equivalentes os termos aprender e desenvolver, os meus preferidos.
      Não tem muito tempo que deixamos de chamar requisitos de requerimentos. Passa da hora de abandonarmos palavras que, além de feias, não refletem o real significado do trabalho com requisitos.

     

  • +Requisitos +Informação

    +Requisitos +Informação

    Segue o papo sobre Requisitos e Conversas. Depois dos exemplos da semana passada, hora de um pouco mais de teoria básica. Os temas de hoje são Informação, Comunicação, ruído e a relevância disso tudo para o trabalho com requisitos.

    Em tempos de big data pra cá e muito ruído e contação de histórias vazias pra lá, é sempre bom relembrar o básico, (porque talvez ele já não seja assim tão) óbvio e intuitivo. Do começo: o que é informação? Difícil ser mais direto e eficaz que Bateson: “informação é a diferença que faz diferença“. A fórmula ao lado¹ nos diz a mesma coisa, de um jeito diferente.

    Na prática: o previsível, o corriqueiro, o redundante e o repetitivo não nos ensinam (informam) nada ou praticamente nada. (Esta frase  parece querer confirmar o que ensina.) E o valor daquilo que pouco informa é irrisório ou nulo. Particularmente em projetos, porque informação é sua principal matéria-prima.

    Choque de realidade: talvez você já tenha visto por aí um catatau com dezenas ou centenas de páginas chamado “especificação funcional” (sic) ou algo parecido. Aplique a fórmula ou regrinha acima para ter uma rápida noção do valor, da quantidade de informação de verdade que aquele documento carrega. Lembre-se das redundâncias, ambiguidades, contradições e encheção de linguiça ali persistida. Agora considere quanto aquele entregável (sic 10x) custou: as horas gastas em entrevistas, reuniões, revisões do documento etc. O quão economicamente útil é um documento assim?

    Vale dizer, o problema nem é necessariamente o formato. Tem muito quadro kanban por aí que mal vale uma nota de três reais, apesar da sua belezura e pseudo-modernidade. Antes da forma, deveríamos nos preocupar com o conteúdo.

    + Comunicação

    O Houaiss nos ensina que comunicação é a “transmissão de uma mensagem”. A crença na eficácia desta comunicação de uma via tem causado sérios problemas. Até no frio relacionamento entre computadores há a preocupação com a recepção – com a garantia da entrega de uma mensagem. Na comunicação entre pessoas a questão é um tanto mais complexa.

    Existem diversos modelos² que ilustram todo o processo de comunicação entre pessoas. Vou apelar para um básico³:

    • Transmitida: a informação foi enviada;
    • Recebida: a pessoa na outra ponta recebeu a informação;
    • Entendida: o receptor entendeu a mensagem. Se não, é provável que o processo se reinicie com a transmissão da informação de forma diferente. Este ciclo pode se repetir diversas vezes, até que haja o entendimento;
    • Aceita: o receptor concorda com o que foi informado. Se o ciclo anterior era para compreensão, agora pode existir um ciclo de negociação. Que também pode requerer um reinício – um retorno ao primeiro estado;
    • Convertida em Ação: o receptor faz algo a respeito da informação que recebeu, entendeu e aceitou.

    Em nosso dia a dia, em todo tipo de comunicação, o processo pode ser interrompido em qualquer ponto acima. Você pode, por exemplo, entender o que está escrito aqui e não aceitar e consequentemente não fazer nada a respeito. No trabalho com requisitos é importante que o analista busque o quinto estado – a conversão em ação – de toda informação de fato relevante para o projeto.

    Quando trabalhamos em projetos, particularmente com requisitos, deveríamos ver comunicação da seguinte maneira4:

    Comunicação = Informação * Relacionamentos * Feedback

    A informação vale por si só, por ser “a diferença que faz diferença”. Mas sua simples transmissão não tem valor nenhum. A fórmula acima sugere que a comunicação vai de fato ocorrer se existir um bom relacionamento entre os interlocutores. Mas não basta. Mesmo no mais harmonioso dos ambientes, a comunicação exige mecanismos de feedback que garantam que a mensagem transmitida seja recebida, entendida, aceita e, de alguma maneira, convertida em ação.

    O alcance da definição acima ultrapassa e muito o escopo desta série. Tentarei mostrar apenas a relevância daquela fórmula nos trabalhos de desenvolvimento e análise de requisitos.

    Para tanto, que tal outra fórmula5?

    Resposta = Informação + Confirmação + Ruído

    A confirmação verbal do entendimento é a melhor depois da telepatia. -Jurgen AppeloA confirmação é o tal mecanismo de feedback da fórmula anterior. Precisamos dela, mas nem sempre a conseguimos na primeira resposta. Independentemente da qualidade da pergunta. Por isso consideramos que uma resposta sem confirmação está incompleta. E formulamos a questão seguinte com o único propósito de obtê-la.

    Entre informações e confirmações, invariavelmente recebemos ruídos. Merece este nome – ruído –  aquela palavra, gesto, olhar, sussurro ou tic nervoso que não conseguimos decifrar em um primeiro momento. Pode não ser nada. Mas pode ser uma informação ou mesmo uma confirmação carente de atenção. Decifrar ruídos no sentido de obter boas respostas e excelentes requisitos é uma das artes (secretas?) dos bons analistas.

    Esta série ainda merecerá um ou mais capítulos específicos sobre conversas, perguntas , respostas e ruídos. O básico do básico sobre informação e comunicação foi colocado. No próximo artigo conversaremos especificamente sobre informações em requisitos. Te espero lá.

     

    Notas

    1. Surrupiada do fundamental Managing the Design Factory, de Donald Reinertsen (Free Press, 1997). Ainda devo a entrada deste em nossa biblioteca.
    2. Um dos modelos de comunicação mais referenciados foi criado por Virginia Satir e publicado em The Satir Model: Family Therapy and Beyond (Science and Behaviour Books, 1991). Você entendeu bem: terapia de família! Gerald Weinberg utiliza o Modelo Satir em diversos livros.
    3. Scott Berkun também cita o Modelo Satir em A Arte do Gerenciamento de Projetos (Bookman, 2008). É dele o modelo básico utilizado neste artigo.
    4. Esta fórmula veio de Management 3.0, livro de Jurgen Appelo bastante citado por aqui e em outros lugares.
    5. A última fórmula foi retirada de Redefinindo a Análise e o Projeto de Sistemas, de Gerald Weinberg (McGraw-Hill, 1990) – um livro que todo analista de negócios deveria conhecer. Para não ter o mesmo destino dos analistas de sistemas…

     

  • +Requisitos do Negócio | Exemplos

    +Requisitos do Negócio | Exemplos

    No artigo anterior vimos conceitos básicos sobre requisitos do negócio. Hoje veremos alguns exemplos.

    Na introdução desta série foi apresentado o caso da empresa ACME que servirá como base para todos os exemplos¹. Ele é repetido abaixo, de forma melhor estruturada:

    • Perspectiva Financeira:
      • Aumentar faturamento em 30%. Prazo: 2 anos
    • Perspectiva Clientes:
      • Aumentar base de clientes
    • Perspectiva Processos:
      • Tornar as visitas mais eficientes
        • Reduzir tempo de duração de uma visita
        • Aumentar número de visitas (de 15 para 24/dia)
      • Tornar as visitas mais eficazes
        • Aumentar número de negócios fechados
        • Aumentar valor médio das vendas
    • Perspectiva Aprendizado e Desenvolvimento
      • Como tornar as visitas de vendas mais eficazes?
      • Como tornar as visitas mais eficientes?

    Quanto luxo!, você diria. Afinal, quantas empresas você conhece que apresentam suas necessidades na forma de um Balanced Scorecard (BSc)? Minha intenção com o exemplo acima é outra. É mostrar que esta ferramenta pode compor o cinto de utilidades de um analista mesmo em organizações que não fazem uso dela. Além de relativamente simples, o BSc é útil na busca pela verdadeira raiz de um problema (ou real motivação de um projeto). Acompanhe o diálogo abaixo :

    S: Precisamos de um sistema que torne nosso processo de vendas mais eficiente e mais eficaz.

    A: Por favor, defina eficácia.

    S: Número de negócios fechados, principalmente. Mas também miramos um aumento no valor médio das vendas.

    A: E o que significa um processo de vendas mais eficiente?

    S: Seria um que possibilitasse um número maior de visitas. Trabalhamos com a possibilidade de um aumento de aproximadamente 50%. Menos tempo seria gasto em cada cliente e mais clientes seriam visitados.

    A: Quantas visitas cada vendedor realiza hoje?

    S: Mais ou menos quinze. Acreditamos que um bom sistema viabilize o aumento para cerca de vinte e quatro visitas.

    A: Resultando em mais visitas aos mesmos clientes ou em novos clientes?

    S: Em novos clientes, claro! Hoje não atendemos parte considerável das zonas norte e oeste. E para lá que precisamos crescer.

    A: Aumento que pode ou deve se refletir no faturamento, certo?

    S: Claro! Nossa intenção é um ganho de 30% em um prazo de dois anos.

    O diálogo acima tenta ilustrar a lógica de construção de um BSc. Ele se desenvolve em ordem inversa e o analista tenta chegar na grande motivação para o projeto (no caso, um aumento de 30% no faturamento). Existem ferramentas de uso mais genérico que têm o mesmo objetivo. Uma das mais conhecidas se chama 5 Whys e  foi inventada na Toyota. O nome vem da sugestão de que são necessários, em média, 5 “porquês” para que se alcance a raiz de um problema.

    Vejamos agora como esse papo poderia se desenrolar com a aplicação das questões sugeridas no capítulo anterior:

    A: Qual ou quais problemas você precisa resolver?

    S: Precisamos tornar nossas visitas de vendas mais rápidas e mais eficazes. Ou seja, preciso que meus vendedores façam um número maior de visitas por dia e também que vendam mais em cada cliente.

    A: O que vocês estão buscando? (Qual a motivação para solução destes problemas?)

    S: Acreditamos que podemos atender um número bem maior de clientes. Hoje praticamente não atuamos nos bairros um pouco mais afastados das zonas norte e oeste. Se nossos vendedores forem mais produtivos, então poderemos cobrir uma área bem maior.

    A: Uma base maior de clientes pode significar mais faturamento…

    S: Nossa meta é aumentar o faturamento em 30%.

    A: Não bastaria contratar mais vendedores? (Qual solução está fora de cogitação? Por quê?)

    S: Não, por favor, não! Você já gerenciou vendedores? Sabe o quanto é difícil? Isso também significaria comprar e administrar mais carros e mais celulares… Definitivamente, não pretendemos aumentar o número de vendedores. O que nós queremos, isso sim, é que eles sejam mais produtivos.

    A: Mesmo com esse trânsito caótico?

    S: É aí que vocês entram, não? Afinal, tecnologia é inventada para tornar nossas vidas menos ordinárias, certo?

    Não há uma estratégia ou formato de entrevista melhor ou pior. Nos dois exemplos acima conseguimos resultados semelhantes (e furos idem!). O importante é que haja uma estratégia e que o entrevistador sempre busque pela motivação principal de um projeto. Porque, no final das contas, um projeto só será considerado um sucesso se este grande requisito – o fato motivador – for plenamente atendido.

    E o que fazer se o fato motivador aparecer de imediato, logo na primeira resposta do solicitante? Percorremos o caminho natural do BSc, tentando entender como a empresa espera alcançar o objetivo colocado. Recomendo a lógica do BSc porque ela permite a cobertura das questões mais relevantes. Veja:

    • Perspectiva Financeira: Quanto a empresa espera ganhar (ou economizar) com isso?
    • Perspectiva dos Clientes: O que os clientes receberão de diferente? Ou estamos falando de novos clientes?
    • Perspectiva dos Processos: O que deve ser mudado no trabalho atual de forma a atender novos clientes ou levar coisas novas para os clientes atuais?
    • Perspectiva do Aprendizado e Desenvolvimento: o que devemos aprender e desenvolver de forma a mudar nossa forma de trabalho (nossos processos)?

    Como colocado no início desta série, é nesta última perspectiva que representamos os novos projetos. “Desenvolver um sistema de automação da força de vendas” é uma possível resposta que apareceria ali. É o momento em que normalmente nós de TI somos envolvidos. Insisto: não faremos um bom trabalho se não buscarmos a motivação verdadeira. Ninguém pede um sistema por pedir. Bom, pelo menos ninguém em sã consciência e com boas intenções.

    Nada de Duplos, Triplos ou Infinitos Sentidos

    Se ambiguidade é nociva para qualquer tipo de requisito, para os requisitos de negócio ela pode ser fatal. Os exemplos acima estão repletos de solicitações ambíguas: Aumentar a base de clientes de quanto para quanto? Quanto tempo dura uma visita? E qual seria o tempo aceitável? Qual é o valor médio das vendas atuais? E qual seria o valor ideal?

    A boa notícia é que este tipo de ambiguidade é fácil de matar. Com base em números correntes, que nem precisam ser muito precisos, os representantes do negócio podem projetar suas necessidades e desejos. Por exemplo: se uma visita leva em média 20 minutos (quando bem sucedida, ou seja, quando resulta no fechamento de uma venda), é factível supor uma visita com duração de 15 minutos?

    Temos em mãos um exemplo que prova de maneira inequívoca o valor da modelagem de negócios. É incrível, mas até hoje recebo profissionais que dizem “eu não faço modelagem. Meu trabalho começa nos requisitos”. Por não entender a simples operação ilustrada ao lado, seguem produzindo requisitos de qualidade questionável, para dizer o mínimo. Vamos lá: ao subtrair a situação atual (as is) do modelo projetado (to be) obtemos os requisitos. Conta boba e óbvia, não? Então por que ela ainda causa tanta surpresa?

    Um velho e bom fluxograma pode mostrar com razoável precisão como um vendedor gasta 20 minutos em cada visita de venda. Dados o número de vendedores (20) e a variabilidade do processo (o processo pode mudar dependendo do perfil do cliente), o analista deveria optar pela observação direta como método de estudo. Ele acompanharia 4 ou 5 vendedores munido de um cronômetro e de algo que lhe permita rabiscar diagramas e notas.

    Cronômetro? Rabiscos? Fluxogramas?!? Minhas caras e meus caros: se essas ferramentas resistem, ainda que com nomes (BPMN) e formatos (BPMN!) mais modernos e bonitinhos, é porque não inventamos nada melhor. E se este trabalho lembra muito o trabalho dos extintos analistas de organização e métodos não é mera coincidência. É pura necessidade!

    Nosso caso específico apresenta como um dos maiores desafios o ganho de produtividade dos vendedores. Além da grana, será necessário medir o tempo gasto em todos os processos relacionados. E a medição in loco é a melhor maneira de eliminar ambiguidades e falsas suposições.

    Aliás, vale a pena destacar que os métodos de observação estão ganhando espaço novamente. Trabalhos como Subject to Change (Peter Merholz et al – O’Reilly, 2008) e Change by Design (Tim Brown – Harper Business, 2009) ilustram a criticidade desses métodos para o desenho de sistemas e produtos. Fabrício Teixeira², também das áreas de UX (User eXperience) e design, escreveu sobre isso recentemente. Gerald Weinberg já apresentava sugestões bastante parecidas no distante 1990, no livro Redefinindo a Análise e o Projeto de Sistemas (McGraw-Hill).

    Agregando Perspectivas

    Poucos projetos podem ser piores do que aqueles originados de uma única cabeça. Um projeto saudável considera a perspectiva de diversas pessoas. No entanto, como nos ensinam Gause e Weinberg³, “cada novo ponto de vista produzirá um novo desajuste”. Porque interpretações e requisitos conflitantes surgirão. Porque novos desejos, necessidades e restrições serão manifestados. Ainda assim, devemos buscar (o quanto antes!) por novas perspectivas.

    Imaginem um dos vendedores da ACME, o Gracindo, entrando na conversa:

    V: O Dilermando (gerente entrevistado anteriormente) acha que somos preguiçosos, né? Mas ele já foi pra rua comigo e viu como é duro o nosso trabalho.

    A: Não é isso. Ele acredita, e nós também, que é possível aumentar a produtividade de vocês vendedores. E, pense só, sua comissão pode aumentar em até 50%!

    V: Será? Sei não. Talvez eles mudem a política. Já ouvi falar em premiação dos mais produtivos e coisa e tal…

    A: Mas a premiação de uns não significará a penalização dos outros. Questão de meritocracia. Sejamos mais objetivos: Gracindo, o que te impede de visitar mais clientes?

    V: Tirando os congestionamentos? A lenga-lenga de alguns clientes. Nossa venda tem que ser feita na hora. Conferimos o estoque de um cliente e sugerimos a reposição. Tem uns poucos que são bem rápidos, aceitam nossa sugestão e pronto. Mas tem outros… até parece que estão decidindo uma compra de milhões de reais. Pensam, pensam, pensam… e no fim, na maioria das vezes, acabam alterando muito pouco as quantidades que sugerimos.

    A: E sobre a possibilidade de vender mais nos clientes atuais, você acredita nela?

    V: Nem um pouco. A menos que a gente atualize e aumente nossa carteira de produtos.

    O diálogo acima não ilustra apenas a resistência do Gracindo, que é comum e natural. Ele também está questionando a viabilidade de um dos requisitos de negócio apresentados (aumentar o valor médio das vendas). Seu ponto de vista será considerado? O que o Dilermando pensa sobre isso? E os outros vendedores?

    Outro ponto que merece toda a atenção: Gracindo teme por mudanças (nunca cogitadas oficialmente) em regras de negócio que tratam do cálculo das comissões. De onde veio essa informação/fofoca? E o que há de verdadeiro nela?

    Novos pontos de vista = novos desajustes.

    Testes e Dúvidas

    Cada evento de aprendizado e desenvolvimento de requisitos deve ser imediatamente seguido de uma bateria de testes. Desta forma caçamos ambiguidades, contradições e dúvidas. Relaciono abaixo dúvidas que criei e ainda não consigo resolver:

    • O aumento de 30% dos lucros é factível?
    • Esta meta esconderia outro problema?
    • Se a ACME pretende aumentar o número de clientes atendidos através do aumento da produtividade dos vendedores, então por que ela buscaria também um aumento do valor médio das vendas? Seria este último requisito uma “forçada” de barra? Se sim, qual o objetivo?
    • Gracindo nos leva a crer que Dilermando desconfia dos vendedores. Eles seriam “preguiçosos”? Dilermando pretende fiscalizá-los de alguma maneira? O controle e o papo sobre “meritocracia” (não confirmado) seriam formas de motivação extrínseca e forçada?
    • Ou Dilermando quer apenas o bem de todos e a felicidade geral da nação? Que tipo de pressão ele sofre? É ele o real demandante do projeto ou a coisa veio “de cima”?

    Artigos mais curtos!, prometeu este que vos escreve. E agora empurra-lhes pouco mais de 2000 palavras. Peço desculpas, mas não vi muito sentido em entregar a história acima em pedaços. E as redundâncias (e eventuais contradições) têm fins didáticos.

    Farei o possível para manter o padrão de um artigo com exemplos seguindo um de conteúdo teórico. Sendo assim, o próximo capítulo retoma a teoria. E leva o papo para longe: precisamos conversar sobre Informação, Ferramentas Sociais e… Conversas! Espero não espantá-la(o). Inté!

     

    Notas

    1. Acho que nunca um caso foi tão sugado. Como o inteligente gerador de artigos relacionados mostra abaixo, a história que ilustra esta série não é inédita. Já apareceu aqui e em diversos treinamentos que apresentei como “O Caso do Seu Moreira”. Se finalmente resolvi encerrar a história (com exemplos!) é porque estou em vias de aposentá-la. Os treinamentos que lanço no próximo mês, inclusive o {FAN} 2013, contarão um novo caso.
    2. Não tem muito tempo que comecei a acompanhar o trabalho do Fabrício. Não perco um post, mesmo quando é de caráter mais técnico. Várias leituras, particularmente das rápidas entrevistas que ele faz com outros profissionais da área, sempre me jogam no mesmo lugar: por que a comunidade de AN é tão diferente? Por que nossos papos parecem um tanto mais pobres e repetitivos? Não é desprezível a sobreposição entre as macrodisciplinas AN e UX. Por isso a diferença entre comunidades e profissionais me parece ainda mais gritante e incômoda.
    3. Seus Olhos Estão Abertos? – Donald C. Gause e Gerald M. Weinberg (Makron Books, 1992).

     

  • +Requisitos do Negócio

    +Requisitos do Negócio

    Segunda parte da série +Requisitos +Conversas. O papo de hoje é sobre requisitos do negócio, aqueles que devem explicar e justificar qualquer projeto.

    Falhamos muitas vezes não porque não conseguimos resolver os problemas que encaramos mas porque encaramos o problema errado. –Russel AckoffRequisitos do negócio são requisitos de alto nível que explicam necessidades do negócio e justificam a execução de um ou mais projetos. Requisitos do negócio representam objetivos do negócio. Muito dificilmente esta representação se dará em uma relação de um para um. E raramente este trabalho – a verdadeira definição de um problema – chegará pronto para a equipe que deve encontrar e desenvolver a solução.

    Não se trata de má vontade ou trabalho mal feito, pelo menos não na maioria das vezes. Não há um protocolo universal para comunicação de problemas e requisitos. Assim como não há nem nunca haverá um processo único, uma receitinha de bolo que nos ajude a entender e comunicar requisitos do negócio. Porque, como escreveram Donald Gause e Gerald Weinberg¹, “é impossível definirem-se os problemas naturais do dia-a-dia de uma forma simples, única e totalmente não ambígua”.

    O Início, O Fim e o Meio

    O mapa que orienta esta série indica que a definição dos requisitos do negócio antecede o(s) projeto(s) que deve(m) satisfazê-los. Não estou sugerindo que este seja o processo e sim afirmando que é assim que as coisas acontecem, mesmo na mais bagunçada das empresas. Uma organização, ao reconhecer um problema ou identificar uma oportunidade², decide efetuar uma ou mais mudanças. Mudanças que podem ser planejadas e executadas através de projetos.

    Portanto, o início de um projeto marca o fim do reconhecimento e aceitação de um problema. Colocando de outra forma: o início de um projeto indicaria o término da fase de descoberta e entendimento dos requisitos do negócio. Este é o momento em que a porca torce o rabo e nossos primeiros desafios dão as caras. Veja no pequeno inventário abaixo quais situações lhe são familiares:

    • Você não precisa saber disso, diz o cara de negócios, sonegando informações que lhe permitiriam i) Priorizar requisitos; ii) Criticar requisitos; iii) Saber se está no caminho certo; iv) Ter um propósito na vida que não seja apenas deixar-se levar; dentre outras coisas.
    • Você não é orientado a falar sobre isso pela fantástica metodologia adotada, afinal o importante é entregar dentro do prazo e do orçamento o escopo acordado, seja lá o que isso signifique.
    • Você e seus colegas estão perdidinhos da silva, sem saber o que perguntar e para quem. Mas todo início de projeto é assim mesmo, diz a voz da “experiência”.

    Repare no diagrama acima que TODOS os requisitos de um projeto derivam dos requisitos do negócio. É fácil concluir que a ausência ou o desconhecimento destes torna um projeto um bate papo entre malucos, uma viagem sem destino nem mapas. Assim como deve ser fácil entender que suposições e decisões acerca dos requisitos do negócio viverão até o término do projeto e além.

    Antes que muitos saibam alguma coisa, um deve sabê-lo. – Henrik IbsenÉ de fato natural que o início de um projeto seja marcado por muitas incertezas. Mas é inaceitável que a equipe não saiba o que perguntar e para quem. A primeira grande pergunta é: por que este projeto é necessário? Claro, ela pode ser formulada de outras maneiras. E seguida por outras questões abertas que ajudarão a formar uma primeira visão do projeto. Seguem algumas sugestões³:

    • Qual ou quais problemas de negócio você precisa resolver?
    • Qual é a motivação para que se resolva este problema?
    • O que pode acontecer se ele não for resolvido?
    • Que tipo de solução está fora de cogitação? Por quê?
    • Você entenderá que este projeto foi um sucesso se…
    • Quanto vale esta solução?
    • Quais pessoas ou áreas serão afetadas pela implantação desta solução?
    • Quem poderá influenciar a construção desta solução?

    As duas últimas questões nos ajudam a iniciar o mapeamento de todas as partes interessadas, interesseiras, indiferentes e até as encrenqueiras. Todas as pessoas que surgirem como resposta para a última questão devem ser submetidas ao mesmo questionário acima. No bololô das redundâncias (desejadas), buscaremos por contradições, mal entendidos, suposições tácitas (escondidas) e dúvidas.

    Aliás, criar e semear dúvidas é uma forma de elaborar, amadurecer e testar os requisitos do negócio. Gause e Weinberg sugerem a regra das três interpretações¹: “Se você não puder achar pelo menos três coisas que possam estar erradas com sua compreensão do problema é porque não entendeu o problema”. Depois, ao apresentar essas interpretações aos envolvidos, caminhamos no sentido de eliminar ambiguidades e mal entendidos.

    Este trabalho de reflexão e questionamento não combina com a pressa. Por isso será sempre recomendável que ele ocorra antes que um projeto seja disparado. Desta forma, ele não sofrerá a pressão de um cronograma. Por favor, não me interprete mal. Não estou sugerindo que esta etapa seja longa e demorada. Mas também não vou vender a ilusão do “separe 10% do cronograma para esta fase” ou o engano das iterações 0, -1 etc. Todo projeto é único. Alguns pedirão por algumas semanas de reflexão. Outros serão definidos (ou abortados) em poucas horas. C’est la vie…

    Todos os trabalhos sobre requisitos que mostram alguma preocupação com este momento inicial concordam em algumas recomendações: vá devagar; seja redundante; tenha mente de iniciante; procure por todos os pontos de vista relevantes; ouça e pense, ouça e pense… (repita n vezes antes de abrir a boca). Sugestões que parecem contradizer alguns mantras do mundo moderno. Estariam ultrapassadas? Veremos no próximo capítulo, através da apresentação de um exemplo prático. Inté!

     

    Notas

    1. Seus Olhos estão Abertos? – Donald C. Gause e Gerald M. Weinberg (Makron Books, 1992).
    2. Não passarei a série toda falando sobre “problemas e/ou oportunidades”. Porque o aproveitamento de uma oportunidade é, até a sua realização, um problema. Portanto, toda vez que você se deparar com a palavra “problema” acate esta interpretação, por favor.
    3. Lista surrupiada e adaptada de More About Software Requirements – Karl E. Wiegers (Microsoft Press, 2006). Que por sua vez surrupiou e adaptou de Exploring Requirements – Quality Before Design, de Donald C. Gause e Gerald M. Weinberg (Dorset House, 1989). Autores como Wiegers e Scott Berkun consideram este o melhor livro sobre requisitos já escrito. Ele mereceu uma edição em pt-br, publicado em 1991 pela Makron Books com o infeliz título Explorando Requerimentos de Sistemas. Está esgotado, mas você pode ter a sorte de encontrá-lo nos sebos da vida.

     

  • +Requisitos +Conversas

    +Requisitos +Conversas

    Depois de uma releitura dos conceitos de arquitetura e modelagem de negócios,  por que não uma série sobre outro tema que é muito caro para este {finito}, requisitos? Até hoje, publiquei apenas onze artigos sobre o tema. Eles estão soltos por aqui. E um tanto datados. Além disso, tenho visto um maior interesse pelo tema. Em buscas que caem neste site e papos que rolam por aí.

    Esta série será elaborada em paralelo a uma revisão do material didático de dois treinamentos, {FAN} +Requisitos e {FAN} +Conversas. Os capítulos devem ser um pouco mais curtos e aparecer com mais frequência do que o normal. Nesta introdução aponto o caminho que será seguido e os principais tópicos abordados.

    Uma Base de Conhecimentos

    Faz tempo que uso o nome Base de Conhecimentos para apresentar o diagrama ao lado. A primeira intenção é didática, como tentarei mostrar no restante deste artigo. Mas, ah como eu gostaria de vê-lo devidamente implantando em uma empresa. Porque está ali praticamente tudo o que é preciso saber sobre projetos e requisitos.  Porque não há caixinhas soltas – nenhuma informação que não possa ser rastreada. Enfim, deixa pra lá (por enquanto).

    No lado esquerdo do diagrama temos os quatro elementos fundamentais que compõem qualquer negócio: Objetivos, Recursos, Processos e Regras. Trata-se de um metamodelo de negócio cujo detalhamento está fora do escopo deste trabalho. Se você quiser entender um pouco mais sobre ele, dê uma olhada na série Pensando Negócios. Nos interessam aqui as duas ligações principais entre o modelo de negócios e os requisitos: 1. Requisitos do Negócio representam objetivos; 2. Funções suportam a execução de processos de negócios.

    O diagrama sugere que objetivos de negócio podem ser quebrados em um ou muitos requisitos do negócio. Vejamos como isso poderia ou deveria acontecer.

    Dirigentes da empresa ACME decidem que um de seus maiores objetivos para o próximo biênio é aumentar a lucratividade em 30%. Sabem que este ganho será produto de duas iniciativas principais: a) Aumento da base de clientes; e b) Redução dos custos de vendas. Ambas iniciativas apontam para uma única grande mudança: o processo de vendas deve ser totalmente revisto. Os vendedores devem ser capazes de realizar no mínimo 30 visitas por dia, um aumento de 50% em relação à média atual. A ACME está ciente de que precisa aprender duas coisas de forma que possa realizar o ganho de produtividade dos vendedores: i) Tornar as visitas de vendas mais eficazes (indicadores: número de negócios fechados e valor médio das vendas); e ii) Tornar as visitas mais eficientes (indicador: duração média de cada visita).

    Utilizei uma poderosa ferramentinha para descrever os objetivos do negócio acima: o Balanced Scorecard. Como sugeri em outra oportunidade, sua última perspectiva (Aprendizado & Desenvolvimento) pode ser tratada como fonte (riquíssima) de Requisitos de Negócio. Repare que temos dois grandes requisitos neste momento: aumentar a eficácia e a eficiência das visitas de vendas. No próximo capítulo conversaremos bastante sobre eles.

    Requisitos de negócio, dependendo de sua amplitude e complexidade, podem exigir o lançamento de diversos Projetos. Aqui poderíamos engatar uma conversa sobre programas e portfólios. Mas não é esta a intenção do artigo. Basta entender que determinados requisitos de negócio podem requerer n aprendizados e mudanças (leia-se n projetos).

    Cada projeto é um conjunto de Requisitos. E talvez seja a hora de, pela milionésima vez, apresentar uma definição para essa palavrinha tão maltratada. Antes, uma definição que você só deveria utilizar como piada ou se quiser enrolar alguém (um belo exemplo de maltrato)¹:

    “Ao ler o Guia BABoK® é vital que ‘requisito’ seja tomado pelo sentido mais amplo possível. Requisitos incluem, mas não estão limitados a condições ou capacidades passadas, presentes e futuras em uma organização e descrições de estruturas organizacionais, papéis, processos, políticas, regras e sistemas de informação. Um requisito pode descrever o estado presente ou futuro de qualquer aspecto da organização.”

    Um requisito é simplesmente a expressão de uma necessidade ou restrição. Ponto. Se preferir uma definição mais formal, apele ao Houaiss: re.qui.si.to s.m. condição necessária para alcançar certo fim. PONTO! Para que complicar?

    O que é necessário, isso sim, é uma visão bem estruturada dos principais tipos de requisitos. Como ilustra o diagrama acima, eles são três:

    • Funções – ações que um produto, serviço ou sistema deve realizar ou ajudar um usuário a realizar. Aqui sempre temos um verbo, uma ação. O diagrama sugere que as funções, quando realizadas por um sistema de negócio, invariavelmente suportam (apoiam) a execução de um ou mais processos de negócio. É interessante notar que esta vinculação direta pode não fazer sentido em produtos de uso geral como um editor de textos, por exemplo.
    • Atributos – são características que um produto, serviço ou sistema deve apresentar. Alguns atributos serão gerais – devem caracterizar o produto, serviço ou sistema como um todo. Mas a grande maioria estará vinculada a funções específicas. O diagrama sugere que alguns atributos serão detalhados em termos de Preferências, possibilitando ou facilitando, por exemplo, negociações ou tarefas de personalização.
    • Restrições – são as fronteiras apresentadas e que devem merecer, logo de cara, uma classificação. Existem restrições ao projeto (orçamento, prazos, equipe etc – sim, são exemplos de requisitos!) e restrições ao produto, serviço ou sistema (tecnologia, formas de acesso e distribuição, política de atualização etc). É curiosa e muito comum a confusão que existe entre requisitos do tipo restrição e regras de negócio. É fácil desfazê-la: tire o produto, serviço ou sistema; A restrição segue valendo? Então se trata de uma regra de negócio, não de um requisito.

    Estas definições, nada menos que fundamentais, não deveriam mudar dependendo da escola, metodologia ou ferramental empregado. Uma função será sempre uma função, não importa se ela foi descrita na forma de uma user story, uma especificação de caso de uso ou em um documento pra lá de formal.

    Pretendo bater forte nos conceitos. Martelá-los mesmo. Mas não ignorarei o lado prático, o trabalho real com requisitos. A série obedecerá a sequência sugerida neste artigo, ou seja: Requisitos do Negócio, Requisitos, Funções, Atributos e Restrições. Cada tema  merecerá no mínimo dois artigos. Semana que vem: Requisitos do Negócio – Os únicos que podem manchar para sempre o seu currículo. Soou dramático? Foi esta a intenção. Inté!

     

    Notas

    1. O Guia BABoK® (ainda) não mudou mas eu passo a impressão de estar cada dia mais azedo em relação a ele, né? Não é só impressão não. Mas meu alvo não é mais o BABoK e sim a comunidade que insiste em espalhá-lo sem o mínimo senso crítico. Se senso crítico é uma das principais qualidades esperadas de um analista de negócios, o que dizer? O que fazer? O quanto chorar? Melhor é deixar pra lá.
    2. Não passarei toda a série escrevendo “produto, serviço ou sistema”. Vamos combinar o seguinte: nos próximos capítulos vou escrever apenas “sistema”. Por favor, entenda que pode se qualquer tipo de sistema. Um liquidificador é um exemplo de sistema, ok?

     

  • Use Case 2.0: Você precisa dele?

    Use Case 2.0: Você precisa dele?

    Ivar Jacobson liberou, agora em dezembro, um pequeno livro eletrônico chamado “Use Case 2.0: The Definitive Guide“. Como ele mesmo alerta, não se trata de uma atualização da ferramenta. Afinal, “casos de uso ainda são casos de uso”. Mas o texto propõe alguns novos elementos – novos artefatos de trabalho. Este artigo pretende avaliar as principais alterações sugeridas comparando-as com alternativas já conhecidas.

    ?

    Apesar de toda a má fama que a acompanha, a ferramenta Caso de Uso continua sendo apresentada por muitos, inclusive este que vos escreve, como a mais eficaz no apoio às atividades de “descoberta e descrição dos requisitos funcionais de um sistema”. Os mal ditos sobre os casos de uso têm origem bem identificada. Em dado momento, entre o final dos anos 1990 e início do novo século, tentaram sofisticar demais a ferramenta. Modelos rebuscados e divisões artificiais e redundantes (fluxo disso, fluxo daquilo…) deram enorme contribuição. A gota d’água veio daquela parte da população que tem preguiça de pensar e adora templates repletos de badulaques. Pronto, estava criada a fama – justíssima, dados os casos criados – de que casos de uso eram muito complicados, de difícil elaboração pelos analistas, incompreensíveis para os usuários, detestados e consequentemente ignorados pelos desenvolvedores e distantes demais dos testers (provavelmente os únicos que, se tivessem a chance, talvez gostassem daquilo. Porque era melhor que nada!)

    O advento do Manifesto Ágil quase nos fez crer que Caso de Uso era coisa do século passado. Mas o que seria do mundo se não fossem os teimosos? Alistair Cockburn nunca abandonou os casos. Nem Ivar Jacobson, o pai da criança que agora nos apresenta essa releitura (escrita a seis mãos com Ian Spence e Kurt Bittner, autores de “Use Case Modeling” – Addison-Wesley, 2002).
    O que ela traz de novo a ponto de merecer o “2.0”? Antes disso, qual a motivação para uma nova versão?

    Os autores defendem que o Caso de Uso 2.0 é: Leve, Escalável, Versátil e Fácil de usar. Fica implícita a intenção de oferecer a versão remoçada da ferramenta como alternativa para as User Stories. Apesar de ilustrarem sua utilização até em um processo baseado no modelo waterfall. A falta de um comparativo entre User Stories e Casos de Uso, a exemplo do que fizeram James Coplien e Gertrud Bjørnvig em “Lean Architecture“ (Wiley, 2010), reduz o impacto da proposta. Mas, afinal, qual é a proposta?

    Jacobson reforça uma mensagem que já apresentava em seus tempos de Rational¹: “casos de uso são a cola de todo o ciclo de vida do processo “. Ou seja, eles “suportam a análise, projeto, planejamento, estimativas, acompanhamento e testes de sistemas”, além da captura de requisitos, é claro.

    Um mapa conceitual nos ajuda a entender todos os elementos da proposta e as relações entre eles. Peço desculpas pela redundância mas vou reescrever as partes que representam as maiores alterações (e, tentarei mostrar, os problemas da proposta).

    Os interessados (stakeholders): i) são as fontes dos Requisitos; ii) estão envolvidos e priorizam Casos de Uso; e iii) se comunicam contando Histórias.

    Até aqui tudo bem, até porque o mapa informa que: iv) Requisitos são capturados na forma de Casos de Uso.  Agora, como falamos aqui no interior, a porca torce o rabo (e a proposta se enrola). Porque é colocado que: v) Casos de Uso são explorados através da narração de Histórias; e vi) seu escopo é gerenciado e endereçado como um conjunto de Fatias de Caso de Uso (Use-Case Slice); que, por sua vez, vii) são identificadas (ou têm sua identificação facilitada) pelas Histórias.

    Essas histórias, a princípio, não têm nada a ver com as conhecidas User Stories (não citadas no e-book). Mas é impossível não perceber a intenção de fazer com que elas sejam elaboradas e tratadas da mesmíssima maneira proposta por Kent Beck (em “Extreme Programming Explained” – Addison-Wesley, 1999) e amadurecida por Mike Cohn (“User Stories Applied” – Addison-Wesley, 2004). Uma História, segundo os autores, pode ser qualquer coisa: requisito funcional ou não funcional, um trecho ou fluxo(s) do Caso de Uso, um requisito especial (?) ou ainda um caso de teste. E elas, genéricas (e versáteis assim), ajudariam na identificação de Fatias de Casos de Uso.

    Essas Fatias, apresentadas como “o elemento mais importante do Caso de Uso 2.0”, justificariam-se porque, segundo os autores, “precisamos de uma maneira de dividir casos de uso em conjuntos menores”. Li e reli o documento e continuo não acreditando que o próprio cara que inventou a ferramenta e seus naturais mecanismos de quebra (extensão) e organização esteja propondo tamanha confusão. Talvez meus neurônios não tenham percebido o fim das férias, sei lá. O fato é que a proposta, particularmente suas Histórias e Fatias, não parece fazer muito sentido.

    Um Caso de Uso é uma maneira mais (ou menos) ESTRUTURADA² de se contar e registrar uma história, um causo. Ele sempre possui um Fluxo Principal (ou Básico), uma sequência natural de interação entre um Ator e um Sistema onde todos os passos são bem sucedidos. Todas as variações ou desvios desta sequência principal são capturados e registrados na forma de Fluxos Alternativos (ou Secundários). Está aqui o primeiro mecanismo natural de ‘quebra’ de um caso de uso. Considero-o natural porque ele reflete a forma do usuário pensar. Uma vez registrado o comportamento mais esperado, como Fluxo Principal, a história se desenrola, por exemplo, em uma sequência de “e se”: “e se o cliente não tiver crédito”, “e se não houver estoque disponível” etc³. Casos de uso são tremendamente eficazes na “descoberta e descrição de requisitos funcionais de um sistema” exatamente porque permitem que uma história seja narrada e estruturada da forma mais natural (e próxima do usuário) possível.

    Por que, então, precisaríamos de outros mecanismos de quebra e organização? Para termos elementos ainda menores, que caibam em uma iteração de duas semanas ou em um post-it? Coplien e Bjørnvig, no capítulo 7 do livro citado acima, já haviam dado a receitinha: “qual é a diferença entre a lista de desvios (Fluxos Alternativos) e uma lista de requisitos, features ou User Stories? Quase nenhuma quando olhamos de perto. Podemos formular cada item da lista na forma de User Stories se isso faz com que a gente se sinta mais Agile“. Bem antes deles, no já distante ano 2000, Alistair Cockburn (em “Writing Effective Use Cases” – Addison-Wesley, 2000) já havia sugerido a derivação de uma Lista de Trabalho a partir de um Caso de Uso e seus diversos fluxos (Work List, págs. 172 – 174). Com itens que cabem perfeitamente em um post-it ou, falando mais sério, “cabem” em iterações (sprints) e facilitam o acompanhamento e gerenciamento de um product backlog ou algo parecido. Enfim, Casos de Uso nunca foram monolitos nem nunca levaram a uma situação “tudo ou nada”. Repito: nunca!

    Casos de Uso também podem ser vistos ou utilizados como uma “cola que une todas as etapas de um processo de desenvolvimento” desde a criação da UML (1995-1997) e dos derivados do Processo Unificado (1998~). Não creio que serão as sugeridas Fatias que farão, agora, a mágica de viabilizar tal visão. Porque a verdade é que nós nunca (ou, para pegar um pouco mais leve) raramente utilizamos Casos de Uso em toda a sua plenitude. O faremos agora que ele ficou um pouquinho mais complicado?

    ?

    Observações:

    1. Lê-se a primeira frase destacada na apresentação “Common Chalenges in Use Case Modeling”, de autoria de Ivar Jacobson e com logo da Rational Software (sem data de publicação).
    2. E é esta propriedade fundamental, o fato do Caso de Uso ser uma história ESTRUTURADA, sua principal diferença em relação a outras propostas, particularmente as User Stories. Um Caso de Uso, por natureza, é um conjunto de requisitos que faz todo o sentido para um usuário ou cliente. Um conjunto estruturado. Um conjunto que “entende” sua relação com os demais componentes da solução. Naturalmente.
    3. Destaquei o primeiro (Fluxos Alternativos) mas não cito acima os demais “mecanismos naturais de quebras” dos Casos de Uso. Porque aqui a porca torce o rabo de vez e, preciso admitir, alguns mecanismos não são tão naturais assim (Extends e Includes devem ter passado pela sua cabeça). Para não deixar o tema no limbo preciso dizer que Cenários (combinações de passos dos fluxos principal e alternativos) e Casos de Testes são derivados ou componentes de um Caso de Uso e representam outras formas de “quebra”. Serão mais ou menos naturais dependendo da forma como são elaborados.
    4. Slice of a Pumpkin Pie, foto que ilustra este artigo, é de autoria de TheCulinaryGeek.

     

  • Um Novo Modelo para Casos de Uso

    Um Novo Modelo para Casos de Uso

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

    ?

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

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

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

    Cabeçalho

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

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

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

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

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

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

    Fluxo Principal

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

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

    Fluxos Alternativos / Instruções para Testes

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

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

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

    ?

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

    Obs.:

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

  • Casos de Uso, Requisitos Funcionais e Probleminhas [Atualizado]

    Seqüência obrigatória do último post. A motivação é a seguinte afirmação: “Os passos em um Caso de Uso são Requisitos Funcionais“. A questão parece simples mas esconde alguns “probleminhas”. Minha intenção aqui, além de justificar minha afirmação, é debater os tais “probleminhas”.

    Núcleo da Base de Conhecimentos do ANVariações do diagrama acima aparecem nas oficinas do programa para Formação de Analistas de Negócios (FAN) e pintou também no seminário do último sábado. Todo mundo parece entender o diagrama sem problemas, mas só repara que a frase que negritei no primeiro parágrafo está implícita no desenho quando executamos os primeiros exercícios. Reparem: um Caso de Uso é um conjunto de Requisitos Funcionais. O nome do caso de uso é um Requisito do Usuário – um requisito funcional que carece de detalhamento. Eu realmente não entendia direito a razão de tanta estranheza, os motivos pelos quais tanta gente acha que passos em um caso de uso e requisitos funcionais são coisas totalmente diferentes. Desconfio que o problema esteja em nossas fontes, praticamente em todas elas.

    Alistair Cockburn, em “Writing Effective Use Cases” , diz que podemos utilizar casos de uso em diferentes situações: Descrever um processo de negócio; Documentar o projeto (design) de um sistema; Discutir requisitos (sem descrevê-los); e Representar os Requisitos Funcionais de um sistema. Sobre esta última possibilidade, que é a que nos interessa aqui, Cockburn pede que a gente não se esqueça de duas coisinhas: i) Os Casos de Uso “são realmente os requisitos”; e ii) Mas não representam todos os requisitos.

    A mensagem de Cockburn não ganha muito eco em outros trabalhos muito conhecidos. Karl Wiegers, por exemplo, chega a dizer que “na teoria, um conjunto de casos de uso compreende toda a funcionalidade requerida em um sistema” . O problema é que no mesmo livro, “Software Requirements” , Wiegers sugere que “o analista pega as descrições de casos de uso e começa a derivar os requisitos funcionais”. Wiegers defende enfaticamente a existência de um grande documento, uma SRS (Software Requirements Specification) que deve listar todos os requisitos (funcionais e não-funcionais), regras de negócio e outras informações desenvolvidas pelo analista.

    Em outro trabalho, “More About Software Requirements” , Wiegers ‘desce do muro’, insistindo que “casos de uso não substituem os requisitos funcionais”. Ele rebate a visão apresentada por Kurt Bittner e Ian Spence em “Use Case Modeling” . Os dois autores afirmam que “no final das contas, todos os requisitos funcionais podem ser capturados como casos de uso, e muitos dos requisitos não-funcionais podem ser associados aos casos de uso”. Desnecessário dizer, mas defendo a visão de Cockburn, Bittner e Spence: Casos de Uso são os Requisitos Funcionais.

    Resumo de Tyner BlainAs variações em torno desta visão são curiosas. Tyner Blain, por exemplo, parte de uma uma sugestão de Karl Wiegers para gerar a visão representada pelo diagrama acima. Mas, caramba, não vejo ninguém afirmar com todas as letras que “passos em um caso de uso são requisitos funcionais”. Ou melhor, quase ninguém. Depois de uma rápida vasculhada (googlada?) descobri que Kevin Brennan, VP do IIBA, afirmou que “a maioria dos passos em um caso de uso são, de fato, requisitos funcionais”. Quase… Maioria? Prefiro ser mais direto: todos os passos são requisitos funcionais. Eliminando ambiguidades facilitamos o aprendizado e aumentamos a praticidade de uma ferramenta, no caso, dos casos de uso.

    No seminário da semana passada minha sugestão foi confrontada por alguns participantes, principalmente por uma senhora que ilustrou seu questionamento com um belo e simples exemplo: uma máquina de café. Segundo ela, “tomar um café” é um requisito. . Na sequência ela citou os passos (que seriam executados por quem quer “tomar um café”):

    1. Coloca uma moeda
    2. Seleciona o tipo de bebida
    3. Retira o copo

    O que são os 3 passos acima? Não são funções requeridas pelo usuário para satisfazer sua necessidade ou objetivo maior (tomar um café)? Funções requeridas = Requisitos Funcionais, não? Por que, como sugere Karl Wiegers , eu precisaria extrair requisitos dos passos acima? Para redigi-los de uma forma diferente? Algo como “o usuário precisa de um lugar para colocar a moeda”? Oras… pra quê?

    Mas eu temo que a confusão esconda outro probleminha, ainda mais sério. Considere que o passo 2 tenha gerado algo mais ou menos assim: “o usuário pressiona o botão referente ao tipo de bebida que quer”. Talvez o exemplo não esteja muito legal, mas quem disse que precisa ser um botão? E se a interface for outra? O que eu tento ilustrar aqui é que um caso de uso deve se limitar a explicar o QUE o usuário precisa, não COMO sua necessidade será satisfeita. Colocarei minha preocupação de outra forma: quando um caso de uso entra no domínio da solução, explicando ou apontando como determinado requisito será satisfeito, ele perde sua utilidade. Outras ferramentas, como protótipos, storyboards, modelos e código, são mais adequadas para a demonstração do COMO. Casos de uso existem exclusivamente para explicar o QUE o usuário precisa. Portanto, deveria ser utilizado apenas para o aprendizado e domínio do problema.

    Mas, como tudo em nossa área, há controvérsias. E diversas outras sugestões, mais ou menos lógicas (e / ou viáveis). Quando insisto em minha proposta tenho dois objetivos: criar uma fronteira mais nítida entre problema e solução (SoC? sorry periferia purista); e simplificar – fornecer uma visão mais coesa de todas as informações necessárias para o desenho de uma solução.

    Para encerrar, uma feliz coincidência: há exatamente 1 ano e 1 dia Hugh MacLeod publicava um cartoon que tem tudo a ver com a mensagem aqui: “It’s not what the software does. It’s what the user does.” Deveria virar um poster-lembrete na sala-mesa de todo AN.

    Atualização:

    Logo depois da publicação deste post troquei um breve papo com o mestre José Paulo Papo. Além de confirmar que concorda com minha sugestão, ele enviou uma preciosa dica ignorada na bibliografia abaixo: “Use Cases: Requirements in Context”, de Daryl Kulak e Eamonn Guiney (Pearson Education, 2003). Tks Papo!

    Bibliografia:

    1. Writing Effective Use Cases
      Alistair Cockburn. Addison-Wesley (2001).
    2. Software Requirements
      Karl E. Wiegers. Microsoft Press (1999).
    3. More About Software Requirements
      Karl E. Wiegers. Microsoft Press (2006).
    4. Use Case Modeling
      Kurt Bittner e Ian Spence. Addison-Wesley (2003).

  • Rendiconti: O Seminário GP e o Caso Criado

    Nem divulguei direito por aqui, mas no último sábado participei do Seminário sobre “Gestão de Projetos de Software” promovido pela Tempo Real Eventos. Foi a segunda edição e contou com os mesmos palestrantes do ano passado: Adail Retamal, José Paulo Papo, Juan Bernabó e este que por aqui rabisca. Contou também com a participação especial de Eduardo Coppo. Pleno sabadão, evento de um dia inteiro, e teve 250 participantes! O tema realmente é quente. Pena que não tive a oportunidade de assistir as apresentações. Mas o breve papo com os colegas e participantes valeu o ingresso.

    Juan e a massaMinha palestra foi a segunda, logo depois do Adail. Baita responsabilidade mas, por outro lado, peguei a platéia devidamente aquecida por TOC, Corrente Crítica e as boas sugestões do Adail. Aliás, antes que eu mergulhe nos meus assuntos, vale dizer que o evento é muito rico exatamente pela diversidade de temas e visões. O Papo apresentou o OpenUP e o Juan (como um maestro na foto ao lado), falou sobre Scrum.

    Eu não hesitei nada quando, há mais de um mês, decidi que meu tema seria “Engenharia de Requisitos”. Só coloquei uma tagline na apresentação da palestra: “Uma Visão Prática”. Depois de algumas oficinas, eu sabia que deveria colocar o assunto para um público um pouco diferente: os Coordenadores e Gerentes de Projetos. Tinha umas 3 “provocações” para apresentar… e, como esperado, criei caso.

    Antes preciso falar que a execução consecutiva de oficinas (com 7 horas de duração) está me deixando “destreinado” em palestras. O ritmo é totalmente diferente. As interações, na palestra, só ocorrem no finalzinho, no tradicional momento “Q & A”. Mas errei feio: minha palestra deveria terminar às 12h20. Levei um susto quando olhei o relógio e vi que ainda restavam uns 30′ e eu só tinha mais uns 4 slides… de um total de 64! Falei mais rápido do que o normal. Isso sem contar que alguns slides-piadinhas-de-gosto-duvidoso não ficam 10″ no telão (e que telão tem o auditório da FIAP, imenso!). Mas, para minha satisfação, o momento “Q & A” durou quase meia hora. Satisfação dupla: preenchi o “buraco” de tempo e, claro, confirmei que as provocações surtiram efeito.

    Coffee BreakProvocações: i) Caso de Uso não é documentação; ii) Matriz de rastreabilidade não é solução; e iii) Engenharia de Requisitos não significa burocracia e falta de agilidade. Foram as 3 explícitas. A que mais gerou debate, claro, foi a primeira. Principalmente quando eu disse que não consigo entender quando alguém me explica que “levanta os requisitos e depois escreve os casos de uso”. Melhor, o bicho pegou mesmo quando eu falei que jogo os casos de uso no lixo tão logo eles tenham cumprido sua nobre utilidade: ajudar equipe e usuários e clientes a *aprender* os requisitos. Até de “agilista” eu fui chamado, vejam só! hehe.. “Você está dizendo que só o código basta como documentação de um sistema?” Claro que não foi o que eu disse.

    Caso de Uso é uma ferramenta fantástica. Sem enrolação, e quando bem desenvolvida, ensina o QUE precisa ser feito; tendo o usuário como ponto de partida. Permite que a gente extraia e estude uma parte específica (tarefa ou atividade) de um processo de negócio sem desmontá-lo e sem a necessidade de novos termos ou metáforas. Repito: Caso de Uso é uma ferramenta fantástica. Mas… como documentação de um sistema? Totalmente dispensável. Não sei se convenci alguém, mas o Sr. Xavier disse ter gostado da “forma como defendo meus argumentos”, ou algo parecido. Um problema-polêmica bem maior viria na sequência, numa provocação até então implícita. Uma questão que me me incomodou em todas as oficinas sobre o tema: Os passos de um Caso de Uso são Requisitos Funcionais!

    Incomoda porque é sempre uma surpresa para muita gente. Incomoda mais porque, como escrevi acima, não está escrito em “lugar nenhum”. Será uma bela “varada n’água”, um terrível engano deste que aqui rascunha? Tentarei responder no próximo post. Inté!

    Está aqui a versão completa da apresentação (PPT – 3mb). Completa: Inclui as fotos de Varginha!!

  • Quem Acerta na Primeira?

    Dos diversos vícios que caracterizam nossa área, existe um particularmente perigoso: quando apresentados a um determinado problema, nos contentamos com a primeira solução que aparece. Excesso de confiança? Outra derivação da fatídica – e não inteiramente mentirosa – arrogância que carimba nosso perfil? Sim, mas não é só isso. Há também o fator prazo: “é para ontem!” O cliente, mal acostumado como nossa extrema agilidade, não entenderia caso pedíssemos um tempinho para pensar na melhor solução. Este problema é mais comum em empresas prestadoras de serviços, mas também é percebido em outras organizações de TI. Ou seja, nossas propostas, sejam elas para clientes externos ou internos, quase sempre estão vendendo a primeira solução que pintou em nossas cabeças. Mas quem acerta na primeira?

    A mais importante ferramenta do físico é sua cesta de lixo.
    – Albert Einstein

    As duas mais importantes ferramentas de um arquiteto são a borracha na sala de desenhos e a marreta na construção.
    – Frank Lloyd Wright

    Costumo dizer que, na iteração 0 (nos momentos iniciais do projeto, que antecedem o estudo de viabilidade e a elaboração de uma proposta), o principal trabalho do analista de negócios (AN) é ter uma visão do todo: “2 quilômetros de extensão e 2 centímetros de profundidade“. Para obter esse “instantâneo”, o AN lança mão de suas duas principais armas-disciplinas: A Análise e Modelagem do Negócio e a Engenharia de Requisitos .

    Ao interpretar as dores e os objetivos do cliente, o AN começa a dar um certo “relevo” àquele “instantâneo”. Ele destaca os requisitos de usuários mais críticos – fundamentais para o negócio. Como mostrei na pequena série “Estruturando Requisitos” (link p/ parte 2), cada requisito devidamente *aprendido* pelo AN é – obrigatoriamente – acompanhado do atributo “Grau de Importância”: aquele requisito é Fundamental, Importante ou Opcional?

    Com base nesta classificação o AN tem condições de selecionar os pontos que merecerão sua maior atenção. Sua atuação, agora, depende do tempo que ele tem para a elaboração da Proposta (ou Estudo de Viabilidade, ou Documento de Visão, ou Project Charter…). Seguindo a sugestão apresentada no artigo citado no parágrafo anterior, cada Requisito de Usuário selecionado é transformado em um Caso de Uso. O requisito “Emitir Nota Fiscal”, por exemplo, vira o caso de uso cujo título é “Emitir Nota Fiscal”.

    Ao desenvolver o caso de uso em questão, o AN está “fazendo um zoom” naquele “instantâneo”. Por ser crítico para a solução do problema de negócio, aquele requisito (de usuário) será desdobrado em n requisitos funcionais. Mais que isso: no mesmo momento o AN também pode estar descobrindo ou aprendendo regras de negócio, definições de dados e também alguns requisitos não-funcionais. Informações que podem ser facilmente registradas em um bom modelo para especificações de casos de uso. Para cada requisito *aprendido* segue valendo a mesma questão: ele é Fundamental, Importante ou Opcional?

    Vamos supor que estamos tratando de um projeto com 10 casos de uso. O AN teve tempo suficiente para detalhar um pouco mais 4 deles. Claro, para o detalhamento ele lançou mão de entrevistas, observações, sessões JAD (ou workshops) – as técnicas mais indicadas para aquele projeto e/ou cliente. Respeitando o prazo (que quase sempre é imposto), ele desenhou o melhor retrato possível do problema do cliente. Este retrato é composto por um grande diagrama conceitual (ou mapa de processos), diagramas de processos ou de linhas de montagem (caso os processos de negócio em questão sejam complexos o suficiente para justificar a elaboração destes), a classificação de 10 casos de uso e a especificação (um pouco mais detalhada) de 4 deles. Esta “radiografia” é tudo que a equipe possui para definir qual a melhor solução.

    Equipe? Sim, o desenho da solução deve ser um trabalho em equipe. Em um futuro artigo apresentarei o que chamo de “parlamento” – o formato desta equipe. Vale ressaltar que cada ponto de vista relevante deve estar representado neste momento. Desenvolvedores, especialistas em usabilidade, os “inimigos” da infra, os “chatos” dos DBA’s e, claro, o coordenador do projeto. O AN, óbvio, representa o cliente. Mas não como um “advogado do diabo”. Não agora, em que sua principal responsabilidade é *ensinar* para a equipe o problema que deve ser solucionado. O AN apresenta um conjunto de “Fatos”, o problema definido.

    Começamos aqui a expandir aquilo que Scott Berkun chama de “Espaço do Problema” :

    O Espaço do Problema

    O início dos debates é marcado por um volume relativamente grande e heterogêneo de idéias. O “espaço do problema” aumenta, como ilustra a figura acima (surrupiada do Berkun). Em determinado momento (que variará bastante dependendo do tipo e complexidade do projeto), o time pára de gerar idéias e começa a agrupá-las. É sugerido que se chegue em 3 alternativas de solução: a mais cara, a mais barata e a coluna do meio, por exemplo. Sugestão: as idéias também são agrupadas em casos de uso.

    Os debates, que a partir deste momento podem incluir o próprio cliente (formalmente, via proposta que contemple as 3 alternativas, ou informalmente, na mesa de discussões) visam a redução do número de opções. Gradativamente, por exclusão, ou com o cliente fazendo a escolha de uma das três alternativas apresentadas.

    O problema com este enfoque é que, se por um lado está bem claro o que é fundamental ou importante para o negócio, por outro temos pouca visibilidade da complexidade e custo daquelas alternativas de solução. O “parlamento” foi reunido exatamente para suprir tal necessidade. Mas como isso é feito? O próximo artigo apresentará uma sugestão. Inté!

    Notas:

    1. Mais do que os objetivos ou os atores (e seus objetivos), acredito que o melhor “guia” para o desenvolvimento de requisitos são os próprios processos de negócio. Um dia, num clássico trabalho (The Object Advantage – Addison Wesley (1995)), Ivar Jacobson disse que o “caso de uso é o nosso constructo para um processo de negócio”. Entendo que a análise e modelagem do negócio é indissociável da engenharia de requisitos. Para minha sorte, não estou só.
    2. “A Arte do Gerenciamento de Projetos“, de Scott Berkun – Artmed Editora (2008). Pois é, finalmente o grande livro do Berkun é lançado em pt-br. Para nosso azar o livro foi reeditado lá fora, com novo título (“Making Things Happen“) e conteúdo revisto. Quem mandou demorar?