finito

Tag: Donald C. Gause

  • 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
  • Dentro do Buraco

    Dentro do Buraco

    “Não morda o meu dedo, olhe para onde estou apontando.“
    – Warren McCulloch

    “Para o observador casual, definições do problema podem parecer desperdício. É tempo gasto longe do teclado e a educação ocidental nos ensina que estamos enrolando ou sendo improdutivos quando estamos ‘só conversando’. Mas o Lean é cheio de paradoxos como esse.”

    “Muito do Lean é baseado no Pensamento Sistêmico e uma definição de problema bem colocada pode levar o time para além de suas preocupações com a solução – para uma compreensão mais ampla do contexto.”

    “O Lean nos pede para reduzir tensões e inconsistências no sistema. A definição do problema articula um objetivo consistente. São comuns os projetos que sofrem porque seus participantes não estão resolvendo o mesmo problema. Uma definição de problema bem escrita oferece uma visão consistente de direção. Como tal, ela pode ser uma poderosa ferramenta para o time e para a gestão.”

    “Uma boa definição do problema pode funcionar como um catalisador para a auto-organização.”

    “Em uma verdadeira organização Ágil aqueles que são responsáveis pela solução do problema participam da definição do problema. Essa definição deve ajudar a canalizar a energia da organização na direção correta.”

    Lean Architecture | James Coplien e Gertrud Bjørnvig
    Wiley, 2010 – Págs. 68~74

    Eu sabia que não estava sendo original quando escrevi que Histórias – de Valor ou de Usuários – são catalisadoras. Só não lembrava a origem.“Antes de iniciar um sprint de criação-de-valor-para-o-cliente precisamos de um backlog inicial do produto. E para gerar esse backlog nós precisamos da visão do produto. Muitas organizações também acham útil a criação de um roadmap preliminar, definindo uma série de releases incrementais. Chamo as atividades que criam esses artefatos de envisioning ou product-level planning.”

    “O envisioning não deve ser confundido com um pesado e cerimonioso processo de planejamento. No Scrum, nós não acreditamos que podemos (ou devemos) conhecer todos os detalhes de um produto antes de começarmos. Entretanto, nós entendemos que o financiamento de um produto não pode começar sem uma visão; sem um entendimento adequado acerca dos clientes, das features e da solução em alto nível; nem sem uma ideia de quanto o produto vai custar.”

    “Não gastamos muito tempo ou esforço no envisioning porque queremos rapidamente passar do estágio do achismo – quando a gente pensa que conhece as necessidades dos clientes – para as etapas de feedback rápido – para os sprints de criação de valor.”

    Essential Scrum | Kenneth Rubin
    Addison-Wesley, 2013 – Pág. 287

    “O primeiro passo no Scrum é a elaboração da Visão do Produto pelo Product Owner.”

    Scaling Lean & Agile Development | Craig Larman e Bas Vodde
    Cap. 12 – Scrum Primer, por Pete Deemer & Gabrielle Benefield
    Addison-Wesley, 2009 – Pág. 311

    1. Uma VISÃO projeta um futuro onde determinado problema deixa de existir. Uma VISÃO assume o entendimento prévio desse problema.
    2. Ignorar a definição do problema e tratar o envisioning como o “estágio do achismo” (guessing, no original) é frágil e perigoso.
    3. Entender que a elaboração da VISÃO é responsabilidade exclusiva de um PO é detonar, logo de cara, uma boa oportunidade de formar um time de verdade.

    “A diretriz fundamental de qualquer sistema verdadeiramente enxuto consiste em estabelecer e entregar valor definido pelo cliente”.

    “ não devemos gastar esforços ou recursos antes de termos um profundo entendimento do valor definido pelo cliente.”

    Sistema Toyota de Desenvolvimento de Produto | James Morgan e Jeffrey Liker
    Bookman, 2008 – Págs. 45~46

    “A característica organizacional definidora do modelo do Spotify é o conceito de squads com ‘baixo acoplamento e alto alinhamento’. A tese central aqui é que ‘alinhamento permite autonomia – e quanto maior o alinhamento, mais autonomia é possível dar’. É por isso que a empresa passa tanto tempo alinhando todos com objetivos e metas antes de iniciar um trabalho.”

    Tempo Talento Energia | Michael Mankins e Eric Garton
    figurati, 2017 – Pág. 163

    1. A distância que separa a Toyota do Spotify é a mesma que separa o Japão da Suécia. Mas uma coisa elas parecem ter em comum: tempo pra pensar.
    2. Não é curioso que esse tempo para pensar não seja considerado trabalho? Repare na frase destacada no último parágrafo acima. Coplien e Bjørnvig, citados lá no início, já haviam alertado para essa característica bem ocidental de não relacionar esse tipo de conversa com trabalho.

    “Quando você dispara qualquer coisa nova, há forças te puxando para todas as direções. Há coisas que você pode fazer, coisas que você gostaria de fazer e coisas que você precisa fazer. Comece pelo que precisa ser feito. Comece pelo epicentro.”

    Rework | Jason Fried & David Hansson
    Crown Business, 2010 – Pág. 72

    “Tome uma grande decisão sobre sua Visão de forma antecipada e todas as futuras pequenas decisões se tornarão bem mais fáceis.”

    Getting Real | 37signals
    37signals, 2006 – Pág. 43

    “Todo o trabalho com requisitos é precedido por algum tipo de processo de iniciação: alguém tem uma ideia de que algo deve ser desenhado e construído.”

    “Se não formos cuidadosos, a ideia inicial vai colocar todo o processo em um caminho improdutivo do qual nunca vamos nos recuperar. Se os participantes não começarem pensando em conjunto, vamos perdê-los antes de ganhá-los.”

    “Como podemos sintetizar a grande variedade de pontos de partida potenciais em uma plataforma única e sólida para a exploração de requisitos? Uma solução possível é entender cada projeto como uma tentativa de resolver algum problema e então reduzir cada ponto inicial a uma forma comum de descrição do problema.

    “Um problema pode ser definido como: A diferença entre as coisas conforme são percebidas e as coisas conforme são desejadas.”

    Exploring Requirements: Quality Before Design | Donald Gause e Gerald Weinberg
    Dorset House, 1989 – Pág. 49

    “A palavra problema sempre significa algo ruim, como em ‘Houston, temos um problema’ Mas as inovações bem sucedidas sempre envolvem mais atenção ao problema do que às soluções. Einstein um dia disse, “Se eu tiver 20 dias para resolver um problema, gastarei 19 para defini-lo”.

    The Myths of Innovation | Scott Berkun
    O’Reilly, 2007 – Pág. 127

     

    “O problema não é o problema. O problema é a sua atitude em relação ao problema.”

    – Capitão Jack Sparrow

    1. Pois é, terceirizei a argumentação. Parti dos originais e a tradução é livre, provavelmente enviesada e eventualmente desastrada. Por  favor, não morda o meu dedo.
    2. Se você não entendeu minha motivação, por favor, veja o artigo anterior.
    3. Se tem o que acrescentar, por favor, comente!
    4. Aquela foto bem sacada de dentro do buraco é da Alexandra Brovco.
  • +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 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.

     

  • Gerald M. Weinberg

    Gerald M. Weinberg

    Clássicos devem ser revisitados de tempos em tempos. Na literatura, música e cinema eles estão sempre à disposição, mesmo em um país desmemoriado e viciado em blockbusters e best-sellers como o nosso. É uma pena, mas o mesmo não pode ser dito sobre os trabalhos clássicos da área de TI.

    Um dos mais famosos, “O Mítico Homem-Mês“, de Fred Brooks (Campus, 2009), só foi publicado aqui 34 anos depois de seu lançamento original. Não sei se isso explica o fato dele ter vendido menos de mil unidades. A verdade é que, com números assim, não devemos esperar que outros clássicos ganhem novas edições. Sorte nossa que existem os sebos. Foi em alguns deles, que conheci via Estante Virtual, que pude encontrar vários trabalhos de Gerald M. Weinberg.

    Weinberg é autor de dezenas de livros, inclusive romances. O conhecia por causa de dois títulos, “Quality Software Management” (Dorset House, 1991) e “Exploring Requirements – Quality before Design” (Dorset House, 1989), escrito a quatro mãos com Donald C. Gause. Não são poucos os que consideram este o melhor livro sobre requisitos já escrito. Para minha surpresa, ele foi publicado no Brasil. “Explorando Requerimentos de Sistemas” saiu aqui pela Makron Books em 1991. Não dê bola ao título – é sobre requisitos, não necessariamente de sistemas (de informação). Tanto que nos dados de catalogação constam: Desenho Industrial e Produtos Novos. É coisa fina, Clássico com “C” maiúsculo. Leitura mais que obrigatória para todos que lidam, de uma maneira ou de outra, com Requisitos.

    Enquanto elaborava o novo Programa {FAN} paquerava minha surrada edição do “Exploring”. Me perguntando se teria tempo para algo “tão antigo”. Tentei apenas folhear aleatoriamente e pimba!, me vi obrigado a relê-lo de cabo a rabo. Foi então que surgiu a curiosidade por outras obras do cara.

    “Seus Olhos Estão Abertos?” aparece na seção de “auto-ajuda” de alguns sebos. É hilário. Equívoco talvez provocado pelo sub-título: Como Definir, Analisar e Resolver Problemas… Seus… e dos Outros. É obra curta, com 140 páginas, e leve. Também foi escrito com Donald Gause e publicado por aqui pela Makron Books em 1992.

    Mais provocador e pesado é “Redefinindo a Análise e o Projeto de Sistemas” (McGraw-Hill, 1990). Se os analistas de sistemas tivessem prestado atenção ao que sugeria Weinberg, talvez hoje os analistas de negócios não fossem necessários. A quarta parte deste livro, por exemplo, ensina a entrevistar. A anterior, a observar. Pois é, habilidades raras e caras aos atuais analistas de negócios.

    Uma das melhores provocações aparece quase no final do livro, na parte VII chamada “A Mente do Projetista”. O autor mostra a reação de espanto de um cliente que estava recebendo seu sistema três meses antes do previsto e por 60% do custo orçado. Ilustra o espanto através de um diálogo tão didático, mas tão didático, que nos deixa por entender porque até hoje discutimos formas de contratação de projetos de software. Weinberg não tem segredo nem fórmula mágica nenhuma: “seria ridículo se as matérias importantes fossem deixadas por último”. Ou seja, ele cortou do escopo tudo o que não era importante para o negócio daquele cliente, só isso. Neste caso, cerca de 20% do backlog era formado por “bobeirinhas” (ah, naqueles tempos esses termos não eram utilizados).

    Por fim, mas não menos recomendado, um livro diferentão: “O Líder Técnico“. Lançado em 1994 pela Makron Books, prometia no subtítulo ser “Um Guia Personalizado para Desenvolvimento de Líderes Solucionadores de Problemas”. Entendeu porque o livro pulou em minhas mãos? Pois é, o tema tem tudo a ver com aquele profissional que (ainda) chamamos de Analista de Negócios. E um livro que diz que as escolas estão erradas porque não nos ensinam a errar, roubar e copular merece toda a atenção do mundo! Explicando (mais ou menos): “Não é por acaso que o erro, o roubo e a cópula são as três principais estratégias para se desenvolver ideias”. Liderança, Inovação e Solução de Problemas. Três temas quentíssimos (hoje) tratados com maestria em um título com 26 anos de idade (o original é de 1986). Torna perdoáveis até as quedinhas para a “auto-ajuda” e a citação de “Como Fazer Amigos…”

    Weinberg navega com tranquilidade por várias disciplinas, não poupando exemplos de outras áreas quando eles facilitam o entendimento de algum conceito. Mas sua escrita – ô inveja! – é de uma clareza e um bom humor raríssimos. Alguns trechos surrupiados aleatoriamente dos títulos citados:

    “Sem liderança para administrar o fluxo de ideias, dois técnicos especializados em uma sala formam uma discussão, três uma passeata e quatro um motim.”

    “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.”

    “A parte mais complicada de certos problemas consiste justamente em reconhecer sua existência.”

    “Em qualquer trabalho com requisitos, todo tipo de envolvimento dos usuários deve ser empregado.”

    “Um projeto que esteja em estado de emergência durante o trabalho de requisitos estará em estado moribundo na etapa de entrega.”

    “Poderíamos evitar a maioria de nossos transtornos segurando nossas línguas na saída, quando estamos inclinados a fazer promessas que iremos lamentar. Se deixarmos a especificação suficientemente vaga, teremos uma maior folga para manobrar quando descobrirmos o que queremos ou não fazer. Se fizermos isto corretamente, poderemos até convencer o cliente de que as falhas são características.”

    “São necessárias incontroláveis necessidades e exagerada auto-imagem para ser um analista/projetista de sistemas – para estudar o que as pessoas fazem e dizer-lhes como reprojetar suas atividades. Em outros contextos, em outros tempos, teríamos sido chamados moralistas ou inquisidores. E todos nós sabemos quanto bem fizeram os inquisidores.”

    “Tenho certeza de que o mundo seria um lugar melhor se os escritores e o pessoal dos sistemas fizessem uma pausa agora e recordassem para si mesmos quão pouco eles conhecem realmente. Se fizessem isso, seguramente admitiriam um maior equilíbrio em suas palavras e em seus trabalhos.”