finito

Tag: Gerald Weinberg

  • 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
  • Se Apaixone pelo Problema

    Se Apaixone pelo Problema

    Nos dois artigos anteriores (1 | 2) tentei mostrar a necessidade de uma maior preocupação com o Domínio do Problema. Eles se concentraram no porquê. O texto de hoje ilustra como podemos nos apaixonar por problemas. A correta definição de um problema é parte do problema¹. Não é uma definição simples. Porque as diversas partes interessadas não enxergam o mesmo problema. Ou não o veem da mesma maneira. Talvez algumas nem reconheçam o problema. Isso pode ser consequência de uma organização meio biruta – sem noção do que quer. Porque o ambiente é cada vez mais incerto e dinâmico. O mais provável é que seja uma mistura disso tudo.

    É certo que o jeito Ágil de pensar – com iterações curtas e feedback rápido – nos ajuda a compreender e delimitar melhor o problema enquanto desenvolvemos e entregamos a solução. Mas qual é o marco zero? Qual deve ser o nosso ponto de partida? Se a gente soubesse o quanto esse primeiro passo influencia o desenho da solução seríamos um tanto mais cuidadosos.

    Qual é o problema? Por que é um problema? Quem é afetado por ele? O que está envolvido? O que pode acontecer se a gente não resolver o problema?

    Desenvolver o sistema X ou o app Y; Aumentar o market share; Reduzir os custos do processo Z; Melhorar a nossa imagem; Aumentar o faturamento em tantos milhões. Nada disso é problema.

    Todas as frases acima sinalizam possíveis soluções. Mas dizem muito pouco ou nada sobre o problema. Foi por isso que o pessoal da Toyota inventou o 5 Porquês. Porque geralmente precisamos de cinco enxadadas para alcançar a raiz do problema.

    Tratar a ferramenta 5 Porquês como guia para uma entrevista 1:1 é um desperdício e tanto. Porque ela só prova todo o seu potencial quando é combinada com outras ferramentas em uma Investigação Sistêmica². Este processo de descoberta deve envolver o maior número possível de interessados, interesseiros e encrenqueiros. Todos juntos no mesmo lugar. As respostas para cada porquê se desdobram em potenciais componentes do verdadeiro problema.

    É um engano relativamente comum entender o Pensamento Sistêmico como uma forma de “ver o todo”. Ver o todo é só uma PARTE desse jeito de pensar. Se vemos só essa parte, perdemos o TODO do Pensamento Sistêmico.
    (A recursividade é intencional. Na dúvida, releia o parágrafo).

    Uma Rica Fotografia

    Orientados pela ferramenta 5 Porquês podemos desenvolver uma Rica Fotografia (Rich Picture, no original em inglês). Esse modelo vem de uma das diversas propostas do Pensamento Sistêmico, a Soft Systems Methodology (SSM), de Peter Checkland. A fotografia é rica porque apresenta o contexto em toda a sua riqueza de diversidade, estrutura, relacionamentos e pontos de vista. DSRP: Distinções | Sistemas | Relacionamentos | Perspectivas. São as quatro regras que, em conjunto, nos ajudam a enxergar e compreender o mundo como ele realmente funciona. Ou seja, nos ajudam a pensar sistemicamente.

    Devemos evitar a definição prévia do tipo de fotografia que queremos. Processos ou cadeias de valor não são indicados porque restringem, logo de partida, a forma como vemos o problema. Além disso, passa da hora da gente entender que esse jeito linear de criação de valor não é onipresente, muito pelo contrário. Enfim, a Fotografia Rica deve nascer sem moldura, grades ou guias. As fronteiras e a lógica do modelo devem emergir. Partimos do problema como apresentado na primeira vez – mesmo que seja um simples “precisamos de um app” – e perguntamos: Por que precisamos de um app?

    As discussões em torno das respostas nos permitem identificar as partes envolvidas e as relações entre elas. A classificação dos relacionamentos – forte, fraco, direto, indireto, entrada, saída, colaborativo, conflituoso, rápido, devagar etc – enriquece a fotografia. Parte da fotografia pode ser capturada na forma de um Mapa Causal (CLD – Causal Loop Diagram). Assim o modelo fica com um jeito de filme – ganha dinâmica.

    Como essa fotografia é produto de um processo colaborativo, é de se esperar que ela capture diversos pontos de vista. Condenamos o processo e o ambiente se alguma perspectiva for favorecida ou ignorada. Se uma pessoa chave não puder participar, adie o encontro. Aliás, a falta de agenda pode ser um sinal de que o problema não é assim tão relevante. Pelo menos, não para aquela pessoa.

    Um subproduto desejável da elaboração da Rica Fotografia é uma igualmente rica análise dos stakeholders (ou partes interessadas). Em uma única reunião somos apresentados não apenas às pessoas envolvidas (holders) mas também ao seu grau de envolvimento, aos seus pontos de vista e interesses (stakes). Isso é de suma importância em qualquer iniciativa porque, como ensinou Gerald Weinberg em The Secrets of Consulting (McGraw-Hill, 1985), “a despeito do que o cliente possa lhe dizer, sempre existe um problema. Não importa o que pareça a princípio, o problema é sempre com as pessoas”.

    A bola chega redonda para DeMarco e Lister, que em Peopleware (Makron Books, 1990) emendam: “os principais problemas de nosso trabalho não são de natureza tecnológica mas sim sociológica”.

    Conclusão

    Vale a pena repetir sempre: não é o modelo; não se trata do entregável (sic). É o processo de elaboração que nos interessa. São as conversas que importam. É a criação de uma visão compartilhada do problema o que buscamos. Isso, por si só, fará você se apaixonar pelo problema? Talvez não. A sugestão aqui apresentada deve te deixar mais íntimo do problema. E problemas, assim como as pessoas, podem nos decepcionar quando desnudados. O que fazer com essa desilusão é outra conversa.

    Que não será a próxima. Se hoje apresentei uma sugestão para tratar de um problema interno e específico, no próximo artigo eu pretendo falar sobre problemas externos e gerais – problemas que nos motivam a criar produtos ou serviços. Desconfio que eles sejam um tanto mais atraentes. Veremos.

    Notas

    1. Gerald Weinberg? Russell Ackoff? Tantos já falaram sobre isso que fica difícil decidir a quem creditar aquela frase.
    2. Como eu queria que a gente tivesse adotado em português um termo bastante comum entre os pensadores sistêmicos: Inquiry – investigação, pesquisa. É bem melhor que análise, descoberta e exploração. Porque explica melhor o trabalho que realizamos.
    3. Heart-it foi compartilhada por The ReflexMan no flickr.
  • 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.
  • +Requisitos: Os Atributos

    +Requisitos: Os Atributos

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

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

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

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

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

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

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

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

    Balanço

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

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

    Restrições

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

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

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

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

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

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

    Preferências

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

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

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

     

    Notas

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

     

  • +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

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

     

  • Calculando a Dolorosa – Um Pequeno Guia para a Formação de Preços

    Calculando a Dolorosa – Um Pequeno Guia para a Formação de Preços

    “Hoje em dia sabemos o preço de tudo e o valor de nada“. Esta frase famosa é atribuída a Oscar Wilde, escritor irlandês que viveu entre 1854 e 1900. Em outro mundo, outros tempos. Mas a frase, com milhares de aparições no Google, parece atual. Seja como álibi, desculpa ou provocação. Se você é um trabalhador do conhecimento – se faz do que carrega na cuca uma profissão – permita-se um minuto de reflexão sobre ela. Como você define seu preço – seja ele um salário ou honorário por serviços prestados? Ele define de fato o valor que você acredita representar/entregar? Ou apenas se acomoda em uma faixa definida pelo mercado?

    O tema parece cercado de um certo tabu. Fui puxado para ele depois de assistir a um vídeo de um famoso “guru” da tecnologia tupiniquim¹. Ele iniciou a conversa dizendo que esse negócio de cobrar por hora não faz mais sentido. Não na Economia do Conhecimento. Certo! O problema é que no resto do papo (um número de palavras que começa pela mesma letra) não tocou mais no assunto. E aí, se não por horas, vou cobrar como?

    Nunca gostei da unidade “homem/hora” ou “hora técnica” (sic) porque ela é furada como um queijo suíço. Serve para trabalhos braçais e repetitivos. Mas não tem nada a ver com o trabalho criativo ou do conhecimento. Por dois motivos principais:

    • Uma excelente ideia de solução pode aparecer em uma fração de segundos. Ela vale uma fração de seu valor-hora?
    • “Todo esforço caminha no sentido daquilo que está sendo medido“. Esta frase de Tom DeMarco deveria ser chamada de lei. Se o cliente ou empregador mede (pede) horas, horas ele vai receber. Porque corpo presente não é evidência de mente presente.

    Mas o que fazer se, apesar de todos os argumentos, o mercado ainda compra (e vende) horas? Eu insisto – teimo mesmo – em cobrar por serviço. Foram raras as vezes em que um cliente topou. O que me obriga a sempre ter na manga um taxímetro. Conta fácil, que só exige uma estimativa um pouquinho mais pensada sobre uma das seis dimensões que me ajudam a formar o preço de determinado serviço. Mostrarei abaixo o esquema que muito me ajuda. Na expectativa que ele lhe seja útil também, seja na hora de negociar um salário ou o valor de seus serviços.

    Preço é Estratégia

    Com certeza não é sua única arma estratégica, mas o preço sintetiza toda a sua estratégia. Como já escreveu Gerald Weinberg², “a determinação de preços tem muitas funções e a permuta de dinheiro é apenas uma delas“.  Através do preço você:

    • Define seu mercado;
    • Se diferencia da concorrência;
    • Atrai (ou repele) determinados clientes (ou empregadores); e
    • Delimita seus custos.

    Pense nisso: de certa maneira, seu preço diz quem você é! Por isso é tão importante dedicar um tempinho toda vez que um preço precisa ser definido.

    O ponto de partida não tem mistério nenhum. Você precisa de uma estimativa de custos e de uma margem de lucro. Ou de um valor médio de mercado. Você escolhe se ele representará um preço mensal, o valor total de um serviço ou a fatídica “hora técnica”. Este será seu preço base, aquele que aparece no centro do diagrama ao lado.

    O diagrama exibe as dimensões ou fatores de ponderação que mais considero quando vou precificar um serviço. São seis dimensões de três tipos diferentes. Perfil do Freguês e Duração e Frequência podem funcionar como inflacionadores ou redutores do preço (+/-). A primeira indica apenas o quão atraente ou repugnante é aquele cliente. Ele é um mala ou um amor de pessoa? O histórico (vivido ou pesquisado) do cliente o fará aumentar ou reduzir o preço final.

    A dimensão Duração o ajudará a contrabalancear os efeitos do perfil do freguês. Por exemplo: o cliente é muito chato, mas é um trabalho de curtíssima duração. Ou seja, “dá para aguentar sem a necessidade de furar seus olhos“.

    Mas esta dimensão tem seu peso próprio. Até que ponto é desejável que aquele serviço ocupe sua agenda por um longo período? É a sua necessidade de uma certa estabilidade que o fará utilizar esta dimensão como um fator de inflação ou deflação de seu preço.

    As duas dimensões do lado direito do diagrama, Criticidade e Complexidade, funcionam apenas como itens inflacionários. A Criticidade indica o quão valioso (e provavelmente urgente) é aquele serviço para o cliente. Quase sempre há uma relação direta entre valor, urgência e… Risco! Por isso esta dimensão representa acréscimos ao preço base.

    Assim como a Complexidade, uma dimensão que lhe permite avaliar o quanto de seu cérebro será exigido na realização daquele trabalho. Não faz sentido, por exemplo, que você tenha um mesmo preço quando ministra um treinamento corriqueiro e quando faz uma consultoria daquelas bem cabeludas. Se lhe falta uma mínima noção sobre o tamanho da encrenca, aumente o fator complexidade. Se o cliente não consegue explicar a própria dor, idem. Normalmente isso é sintoma de um problema maior em estado de espera por uma luz – a sua luz!

    As duas últimas dimensões funcionam como lembretes de que alguns fatores podem justificar uma redução do preço. A Oportunidade de Aprendizado é contraponto da complexidade. Acontece mais ou menos assim: “ok, o trampo é deveras difícil. Por outro lado, tenho a oportunidade de aprender a lidar com a tecnologia X e com o método Y”. Pronto, já tens uma boa desculpa para, antes mesmo de o cliente pedir, ceder um generoso desconto. Faz bem para a relação que o cliente seja comunicado de suas intenções (de aprendizado). Weinberg² de novo: “o preço não é uma coisa; é um relacionamento negociado.”

    Por fim temos o Posicionamento, a contribuição daquele cliente ou serviço para sua colocação no mercado. Se prestar serviços para determinada organização enriquecerá seu currículo ou portfólio, talvez você ache justo cobrar um pouco menos. Se a execução de um dado serviço o ajudará a se diferenciar, talvez ele valha o investimento – e é assim que você veria o desconto concedido, como um investimento.

    Matemática

    O modelo “matemático” acima tem muito pouco de matemática. Sua aplicação depende, como vimos, de alguma intuição e muito tato. Depende também de boas informações sobre o cliente (ou empregador) e sobre o serviço a ser executado. Como foi colocado, as dimensões devem ser vistas como lembretes. E é claro que eu espero que você tenha os seus.

    Ao ponderar o que tem valor para você, o preço aparece naturalmente. Se é verdade que hoje ninguém sabe o valor de nada, prove através do preço que o seu valor você conhece bem. E que sua dolorosa é justa.

     

    Notas

    1. Outra coisa que invejo em Gerald Weinberg, além da qualidade de seus escritos e de sua imensa produtividade, é sua não parcimônia ao detonar trabalhos alheios. Nada de jogo sujo ou briga de egos ou por espaço. Em seus livros ele cita artigos que não gostou, dá nome aos bois, mostra o que não gostou e apresenta seu lado. Sei lá o motivo, mas aqui em Pindorama a gente vive pisando em cascas de ovo. Apesar de alguns bois implorarem para ter seus nomes berrados.
    2. Trechos surrupiados de um livro que, caso dependesse do título, não mereceria a leitura. Estou falando de “Consultoria – O Segredo do Sucesso”, trabalho do Weinberg publicado pela McGraw-Hill em 1990. O título original era apenas “The Secrets of Consulting“. Mas as editoras tupiniquins morrem de inveja das distribuidoras que traduzem nomes de filmes.
    3. A imagem que ilustra este artigo é do sr. mzocoxito.

     

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

  • Repensando a Análise de Negócios

    Repensando a Análise de Negócios

    eria muita incoerência de minha parte se, após a palestra que apresentei no BA Brazil, seguisse tocando minha vidinha da mesma maneira. Aquelas provocações motivaram o maior redesenho que o Programa {FAN} já recebeu. O que, por sua vez, pediu por um rejuvenescimento deste {finito}. Não vou roubar seu tempo repetindo o que o programa já diz. Minha intenção neste artigo é outra. Que tal ver a Análise de Negócios de uma forma um pouco mais ampla?

    Relembrando e reforçando as duas provocações que apresentei:

    • Não devemos seguir espalhando por aí que “o importante é que a Análise de Negócios seja realizada, não importa por quem”. Esta colocação, por bem intencionada que seja, gera dois efeitos muito negativos: i) parece diminuir a importância e simplificar (no mal sentido) a Análise de Negócios; e ii) deprecia todos que escolheram a Análise de Negócios como profissão. Pergunta (retórica): na ausência de analistas de negócios, como podem a profissão e respectivo corpo de conhecimentos evoluir?
    • Apesar de dever seu ressurgimento à TI, está chegando a hora da Análise de Negócios decretar sua independência. Por definição, analistas de negócios ajudam uma organização a descobrir e desenvolver soluções para problemas de negócios. Qualquer tipo de problema! Mas…

     

    Definições Destroem

    A definição destrói Não há nada definitivo neste mundo. – Bob DylanNão precisamos ser radicais como Dylan, mas é sempre saudável alguma reflexão sobre definições e nomes. Pense um pouco sobre o termo “Análise de Negócios”. Talvez você perceba, como eu (depois de monte de gente¹), que ele é ruim pra chuchu. Veja o que diz o Houaiss:

    • análise s.f. 1 estudo das diversas partes de um todo 2 investigação; exame
    • negócio s.m. 1 transação comercial 2 local onde se realiza essa transação 3 algo que não se sabe ou não se lembra o nome; qualquer coisa; trem (em mineirês e fora do Houaiss)

     

    Pegando apenas o que nos diz respeito, podemos concluir que Análise de Negócios é “o estudo das diversas partes de um local onde se realizam transações comerciais”. O estudo por si só? Não faz sentido. Ou faz tanto quanto propor “a investigação de um trem“.

    Reforço a definição que sugeri no início do artigo: “analistas de negócios apoiam a descoberta e o desenvolvimento de soluções para problemas de negócios”. Os analistas apoiam – o que significa que suas atividades nunca são um fim em si mesmas. Eles apoiam dois tipos de atividades: de descoberta e  desenvolvimento (de soluções para problemas de negócios). Veja o diagrama abaixo:

    O losango já foi utilizado por vários autores para ilustrar o caminho para a solução de problemas, dentre eles Scott Berkun² e Tim Brown³. Berkun o chamou de “espaço do problema”. A figura indica que nós aumentamos esse espaço – cogitando e validando alternativas de solução – antes de selecionar, desenhar e construir a mais adequada. Brown nomeia as pontas do losango de maneira um pouco diferente. A primeiro seria de divergência – quando criamos escolhas, a segunda de convergência – quando fazemos escolhas. Quase escondo a provocação nas palavras entre parênteses: a análise – o estudo das diversas partes de um todo – é só parte do trabalho! Ela não tem sentido nenhum sem sua cara metade, a síntese. Houaiss:

    • síntese s.f. 1 reunião de elementos diferentes num todo coerente 2 operação intelectual que apreende o todo partindo dos elementos que o constituem 3 exposição abreviada e genérica; resumo

     

    Se a análise é o estudo das partes, a síntese as combina na elaboração de um todo. Não há processo ou método para solução de problemas que não obedeça essa ordem. Exatamente por isso o termo “análise” é tão ruim¹. Não se trata de chatice de dublê de filólogo. Nomes e definições podem ser perigosos ou até mesmo destrutivos. Se não, como explicar que muitas empresas utilizem analistas de negócios apenas em 1/5 das funções sugeridas no diagrama acima?

    Ainda não cheguei ao cúmulo de sugerir a troca do nome da disciplina ou da profissão. Não sou louco o suficiente. Apenas insisto para que a Análise de Negócios seja vista de forma mais ampla. Reparem, ela nem se limita ao losango no modelo acima. Existem outras três áreas, não limitadas aos projetos, que merecem o apoio dos analistas de negócios. São elas:

    • Gestão de Relacionamentos: se os analistas de negócios funcionam como uma ligação entre todas as partes interessadas de um projeto, é natural que se espere deles uma considerável contribuição na gestão de relacionamentos: gerenciamento de expectativas; resolução de conflitos; averiguação da satisfação de clientes e usuários etc
    • Gestão do Conhecimento: uma responsabilidade muito maior do que a danosa e usual percepção de que os analistas devem “documentar tudo”. Existem documentos – existe a necessidade deles, mas há algo muito maior sendo gerado a cada projeto, por menor que ele seja. É conhecimento novo. Algo que, se não for corretamente gerenciado, será desperdiçado.
    • Manutenção da Qualidade: algo que deve ser incorporado em toda e qualquer função. Os analistas de negócios têm condições de zelar não apenas pelo que desenvolvem, mas também pela qualidade de todo o trabalho executado em um projeto e fora dele.

     

    Para Pensar e Repensar

    Você pode estar perguntando, com razão, o que esse papo tem a ver com as duas provocações que abriram este artigo. Tudo:

    • Cabe um mundo inteiro na distância entre analistas de negócios e tiradores de pedidos. A Análise de Negócios lida com domínios cognitivos de maior dificuldade: Solução de Problemas, Análise e Síntese; Pensamento Criativo; Pensamento Sistêmico; Complexidade etc. Entender ou pretender que qualquer outro profissional possa executá-la, mesmo em projetos aparentemente mais simples, é ingênuo e perigoso.
    • Mais importante é entender que a Análise de Negócios não existe sem os analistas. A disciplina definhará se não houver quem a defenda e estude  como uma especialização.
    • Ao propor o modelo acima forço um distanciamento de TI. Até então utilizava disciplinas da Engenharia de Software – Modelagem de Negócios e Requisitos – para mostrar o que os analistas de negócios podem fazer. Elas seguem existindo e continuam importantes para os analistas. Mas devem ser percebidas como itens de uma caixa de ferramentas que precisa ser consideravelmente maior e mais diversificada. Todas as empresas estão carentes de bons solucionadores de problemas. Um time especialista em solução de problemas, qualquer tipo de problema, seria uma cartada e tanto. Você não acha?

     

    Notas

    1.  Esse papo de Análise + Síntese é quase tão velho quanto andar pra frente. Só foi requentado neste artigo porque parece esquecido ou ignorado quando o assunto é a Análise de Negócios. Gerald M. Weinberg, falando para analistas de sistemas em “Redefinindo A Análise e o Projeto de Sistemas” (McGraw-Hill, 1990), já tinha feito o mesmo. Pelo que sei, Weinberg foi o primeiro a destacar o quão ruim é o termo “Análise” e a propor um tal Sintetista. Desta leitura derivei outra provocação: o analista de sistemas falando para o analista de negócios, “eu sou você amanhã”.
      Weinberg teve vários títulos publicados no Brasil mas, salvo engano, estão todos esgotados. Analistas de negócios deveriam ler todos que encontrar nos sebos da vida.
    2. Em “A Arte do Gerenciamento de Projetos“, Bookman (2008).
    3. Em “Design Thinking – Uma Metodologia Poderosa para”, Campus (2010). A editora deu uma bela barbeirada no título, tanto que temo pela  tradução. Se puder, opte pelo original: “Change by Design” (Harper Business, 2009).
    4. A Extensão Ágil do BABoK®, em fase de revisão pública, é muito feliz ao sugerir uma divisão muito parecida com aquela ilustrada pelo losango acima. Só há um termo diferente: Delivery (entrega) ao invés de Desenvolvimento.