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

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

Distinções

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

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

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

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

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

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

Sistemas¹

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

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

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

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

Relacionamentos

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

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

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

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

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

Perspectivas

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

Coincidência?

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

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

Conclusão

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

Notas

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

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

É Necessário?

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

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

É Compreensível?

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

Está Completo?

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

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

É Verificável?

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

É Viável?

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

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

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

Está Priorizado?

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

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

Está Correto?

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

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

Notas

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

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?

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

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

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

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

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

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

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

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

Epílogo

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

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

Notas

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

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

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

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

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

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

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

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

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

A Nomenclatura Utilizada

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

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

Jobs-to-be-done

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

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

Notas:

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

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

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

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

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

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

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

– Qual ou quais problemas essa ferramenta resolveria?

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

–  Existem outros (problemas)?

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

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

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

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

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

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

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

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

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

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

Notas

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

Os dois últimos capítulos – que, dentre outras coisas, mostraram como planejar reuniões e fazer perguntas – trataram de um trabalho bem miúdo do analista de negócios, um trabalho de formiguinha. É curioso como temas assim não merecem muito espaço. Sumiram dos currículos de TI e raramente aparecem em livros ou eventos da área. Será que os temas menores, aparentemente pouco charmosos, são mesmo desimportantes?

Quantas vezes você participou de reuniões que foram pura perda de tempo? Quantas vezes você viu ou foi um facilitador munido de um roteiro eficaz, com questões que foram pensadas e bem ordenadas? Se você participou de um projeto guiado pelo Scrum, com que frequência percebeu que os eventos de planejamento, revisão ou retrospectiva foram planejados e bem executados?

Não é de hoje que convivemos com o mau improviso em reuniões e entrevistas, coisa que aqui em Pindorama conhecemos como jeitinho. É possível que a maioria que o comete o faça por pura falta de conhecimento. Afinal, nem na escola nem no trabalho lhes foi ensinado como planejar e executar eventos que buscam resolver problemas, explorar requisitos, apresentar alternativas de solução etc. Mas também existem, e não são poucos, aqueles que acham que esse papo é bobagem. Confiam em sua agilidade mental e vasta memória.

Velocidade de raciocínio e boa memória são qualidades esperadas de qualquer trabalhador do conhecimento. Mas elas nunca substituem um bom planejamento. Cabe uma comparação com bandas de Jazz, estilo musical onde o improviso é característica fundamental.

Charlie ‘Bird’ Parker e Lester ‘Prez’ Young sempre ensaiavam com suas bandas. Faziam isso durante todo o dia. Ou toda a tarde, dependendo da ressaca. Mas a cada show, nos clubes noturnos, as músicas ganhavam caminhos diferentes. O mundo real sempre será diferente daquele que foi planejado. Bird e Prez forçavam as mudanças ao alterar seus solos. Mas o faziam em cima de bases exaustivamente ensaiadas. Era a base que dava segurança, sustentação para seus belos voos solo. Este é o bom improviso, aquele realizado sobre uma base segura – sobre algo que foi planejado/ensaiado.

Um dia perguntaram para Fred Brooks como um projeto pode ficar com atraso de um ano. “Um dia de cada vez”, ele respondeu. Tudo o que é grande em um projeto, seja bom ou ruim, é resultado de diversas coisas miúdas. Perguntas bem pensadas, apresentadas em eventos bem organizados, geram respostas e requisitos mais ricos. É com estes pequenos tijolos que se fazem os projetos bem sucedidos.

Lá no início desta longa série, em +Requisitos do Negócio, foram apresentadas as questões que normalmente utilizamos na abertura de um projeto. Lembrando:

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

A sequência acima nos ajuda a desenvolver uma linha de raciocínio. Mas, claro, existem infinitas variações. Não é todo entrevistado que tem autonomia ou conhecimento para responder algumas questões. E a natureza do projeto vai impor outras perguntas, mais específicas. O mais importante é sempre se lembrar de que é nos primeiros momentos de um projeto que muitas suposições são construídas. Ao repetir o questionário para pessoas diferentes reduzimos os riscos de interpretações equivocadas.

Vimos no artigo anterior que temos três grandes tipos (ou classes) de eventos: Abertura, Exploração e Fechamento. É na exploração (de requisitos) que esgotamos praticamente todo o nosso arsenal de perguntas. São apresentadas abaixo os tipos de perguntas que fazemos seguidas de alguns exemplos.

Perguntas Direcionadoras

Foco é a palavrinha mágica aqui. É muito fácil, particularmente em momentos iniciais de um projeto, que uma pessoa viaje na maionese, se perca no emaranhado de questões relativas ao projeto (e até de fora dele). Por isso precisamos elaborar perguntas que direcionem os participantes. Exemplos:

• Qual problema você está tentando resolver?
• Quanto tempo temos para a realização deste projeto?
• Quanto você espera gastar?
• Ao concluir esta operação, para onde o usuário vai?
• Vocês utilizam códigos de barras para a identificação de produtos?
• Manga com leite faz mal?

A última questão é uma interessante e didática piadinha. A penúltima, uma deixa para um alerta. Devemos evitar, particularmente nas fases iniciais de um projeto, questões que direcionem para respostas binárias (sim/não). Sendo assim, evitamos o uso de variações do é (são, foram, estão). Obtemos requisitos mais ricos ao utilizar que, quais e como. Aquela penúltima pergunta ficaria melhor assim: Como vocês identificam seus produtos? 

Lembre-se, toda resposta carrega, além de informação, algum tipo de confirmação e alguma quantidade de ruído. Quando fazemos perguntas abertas, como no exemplo acima, forçamos a colocação de algum tipo de confirmação. O entrevistado tende a falar mais, explicar melhor.

Perguntas Criativas

Há momentos em que as viagens devem ser evitadas. Mas também existem aqueles momentos e projetos em que tudo o que buscamos são bons e criativos devaneios. Há o tipo certo de pergunta para motivá-los. Alguns exemplos:

• Há outra forma de resolver este problema?
• De quais maneiras o usuário pode receber essa informação?
• Você pensou na possibilidade de uso de dispositivos móveis?
• Quais outras áreas da empresa veriam utilidade nesta ferramenta?
• O que combina com manga?

Existem eventos que exigem apenas foco. Outros, como os famigerados torós de parpites (brainstormings), demandam generosa porção de questões criativas. O mais comum será o uso de um questionário que saiba combinar os dois tipos de questões.

Perguntas Retóricas

Estas devem ser evitadas a todo custo. Só criam mal estar e nunca geram informação. Alguns exemplos:

• Então, você só tem 10 mil pra gastar, né?
• Por que não procurou a gente antes?
• E você não sabia que fulano é do contra?
• O usuário ignora o aviso, clica aí e espera, né?
• E você achou que manga com pinga e licor de menta cairia bem?

Pior que a combinação da última questão só uma mistura de reunião post-mortem, questões retóricas e jogo de culpa.

Metaquestões

Por fim, temos as metaquestões – perguntas sobre nossas perguntas. Elas nos ajudam a avaliar uma reunião ou até mesmo o processo de desenvolvimento de requisitos. Aos exemplos:

• Estou perguntando demais?
• Me esqueci de perguntar alguma coisa?
• Você quer me perguntar alguma coisa?
• Minhas questões são relevantes?
• Você é a pessoa certa para responder isso?
• Há mais alguém que deveria participar desta conversa?
• Você me receberia novamente?

Sim, algumas delas são perigosas, particularmente as três últimas. Mas são necessárias, principalmente quando estamos prestes a encerrar um encontro e o gelo permanece intacto. Ou, pior ainda, quando as respostas são ruins a beça.

Opa!, quase me esqueci da manga. Segue o derradeiro exemplo: Eu deveria estar falando sobre mangas contigo?

E assim, depois de um longas férias de verão, recomeça a série +Requisitos +Conversas. Espero: i) Seguir contando contigo; ii) Que 2013 seja um ano muito produtivo para todos nós; e iii) Que você não tente combinar manga com pinga e licor de menta.

Notas

Três livros serviram como base para este artigo:

• Exploring Requirements – Quality Before Design, de Gerald Weinberg e Donald Gause (Dorset House, 1989).
• Redefinindo a Análise e o Projeto de Sistemas, de Gerald Weinberg (McGraw-Hill, 1990).
• A Arte do Gerenciamento de Projetos, de Scott Berkun (Bookman, 2008).

Nenhum projeto ocorre sem comunicação. Santa obviedade, diria Robin. Mas o quão bem nos comunicamos em um projeto? Por favor, não me venha com templates de documentos, atas e que tais. Para início de conversa, precisamos conhecer os canais disponíveis, suas vantagens e desvantagens.

O diagrama ao lado¹ sugere a classificação dos canais de comunicação levando-se em conta duas variáveis: Riqueza do Canal e Tipo de Mensagem.

A riqueza é definida pelo volume de informações que trafega em determinado canal. Lembre-se, “informação é a diferença que faz diferença”. Boletins e relatórios são os mais pobres. Qual a razão? Simples: palavras, números e eventuais gráficos raramente ou nunca comunicam o contexto, história, sentimentos etc. Estas informações (ou confirmações ou ruídos – todos igualmente necessários) só são capturadas no tête-à-tête, em tempo real. Por isso, desde que a gente é gente, a forma mais rica de troca de informações e conhecimentos é o cara a cara. As vídeo-conferências são boa alternativa quando o encontro pessoal não é possível. Mas elas não têm o mesmo potencial das reuniões que permitem apertos de mão e abraços.

Como nosso tema central são os requisitos, a segunda variável é ainda mais relevante. O bom analista sabe que todo requisito nasce com considerável dose de ambiguidade, de incertezas. Se tudo o que precisássemos fosse uma confirmação binária – sim ou não – então os outros canais seriam suficientes. A maior parte do trabalho com requisitos – da descoberta ao desenvolvimento – não pode se dar esse luxo. Trocando em miúdos: a maior parte do trabalho com requisitos deve se dar na base do cara a cara. O “maior parte” soou ambíguo demais para ti? Então, crava aí: de 50% a 80%, dependendo do ineditismo do projeto².

Ferramentas Sociais

Existem inúmeras ferramentas sociais – ferramentas que utilizamos para trocar informações e experiências, apresentar soluções, debater problemas, fofocar, avaliar, motivar e conviver. Nos interessam aquelas que fazem uso do canal mais rico, o cara a cara. Nesta categoria, praticamente todas as ferramentas derivam de dois únicos modelos: Reuniões e Observações.

Não faria muito sentido, dados o espaço e o foco desta série, que eu inventariasse e classificasse cem, vinte ou mesmo dez ferramentas sociais. Existem bons livros que já fizeram isso por nós³. Portanto, limitarei este artigo à apresentação dos dois modelos principais.

Reuniões

O que trato aqui como reunião é qualquer encontro que envolva duas ou mais pessoas. No trabalho com requisitos é comum o uso do termo entrevista, que não deixa de ser uma reunião. Temos apenas três tipos de reuniões:

• Abertura / Apresentação: de uma ideia, proposta ou de um problema. Normalmente é configurada para motivar uma primeira rodada de debates acerca do tema exposto.
• Exploração: de ideias e alternativas. É neste tipo de encontro que acontece a maior parte do desenvolvimento de requisitos. E é este tipo de reunião que apresenta o maior número de variações.
• Fechamento / Prestação de Contas: acerca de um projeto, iteração ou tarefa específica. É uma conclusão que, em alguns casos, resulta em nova abertura ou no planejamento desta.

É importante que tenhamos um modelo para a configuração das reuniões, independentemente de seu tipo. Um dos melhores que já conheci é apresentado como framework 7P’s⁴. O desenho ao lado ilustra seus componentes:

As reuniões nunca foram tão visuais como hoje. Nos livros citados³, praticamente todas as ferramentas são visuais. Tim Brown, em Change by Design (Harper Business, 2009), tem uma boa explicação para isso: “Palavras e números são bons, mas é desenhando que podemos revelar simultaneamente as características funcionais e o conteúdo emocional de uma ideia“.

Cabe um último alerta sobre reuniões. Deve existir um e apenas um condutor  (ou facilitador. De Bono chama de presidente!) da reunião. E é humanamente impossível que esta pessoa conduza e simultaneamente faça os registros necessários (desenhos, especificação de casos de uso, histórias, lista de atributos etc). Por isso sempre recomendo a presença de um segundo profissional, responsável pela externalização (conversão, mesmo que parcial, em conhecimento explícito) daquilo que está sendo debatido ou apresentado.

Observações

Nós sabemos mais do que podemos dizer. -Michael PolanyiA observação é uma ferramenta em fase de redescoberta. Como ilustrado no artigo anterior, Diderot lançou mão dela para aprender diversos ofícios. Agora, séculos depois, estamos aprendendo a aprender observando o trabalho ou o cotidiano dos outros. Porque começamos a entender que “sabemos mais do que podemos dizer”.

Existem dois tipos principais de observações:

• Ativa: o observador ocupa o lugar do observado por um certo tempo, executando seu trabalho. Literalmente, “calçamos os sapatos” e “sentimos as dores” do usuário ou cliente. Não vale que seja por apenas alguns minutos, apenas para “ver como é”. Não, na observação ativa dedicamos o tempo necessário para literalmente sentir dores. Rica que é, difícil explicar sua pequena adoção em terras tupiniquins. Será preguiça?
• Passiva: aqui há de fato apenas a observação atenta. Em alguns casos, ela deve ser silenciosa e, se possível, escondida. Explico: não é raro que o observado, quando ciente da observação, passe a atuar – falseando ou exagerando seus gestos, falas, caras e bocas. Se ele deixar de ser quem é, de fazer o que realmente faz e como o faz, a observação estará perdida. As conversas, quando necessárias, devem ser separadas da observação. Interrupções constantes também comprometem o trabalho de observação.

Extraímos requisitos das observações? Sim, e o curioso é que a fonte daqueles requisitos é o próprio analista-observador e não o usuário que foi observado. Porque é impossível que o analista faça uma observação totalmente isenta. Ele carregará as necessidades e restrições percebidas com sentimentos seus, não do observado. Isso não é um problema quando a observação é de fato atenta e atenciosa.

A observação pode criar de forma mais rápida e natural um componente fundamental para boas comunicações: empatia. Infelizmente, acho que não tenho muito mais a dizer sobre essa ferramenta. Veja bem: a melhor maneira de ensinar alguém a observar é convidando-a para observar um trabalho de observação. Sacou?

Então, depois de extrapolar e muito o limite auto-imposto de mil e poucas palavras por capítulo, só restam um lembrete:
Comunicação = Informação * Relacionamentos * Feedback

e uma provocação⁵: “Para criar bons relacionamentos você deve convencer as pessoas de que se preocupa com elas. A única maneira de convencê-las é se preocupando realmente.”

Estou prestes a encerrar a “primeira temporada” da série. Como ela é muito longa, você e eu merecemos um descanso. Mas há outro motivo: estou iniciando uma nova bateria de testes de boa parte das sugestões que ainda serão apresentadas. Dependo desta confirmação para seguir o trabalho. Conto com sua compreensão.

Notas

1. Surrupiado de Comportamento Organizacional, Stephen Robbins (Prentice Hall, 2002).
2. Um projeto de sistema que se propõe a substituir outro sistema, por exemplo, não exigirá tanto encontro tête-à-tête. Aliás, se for uma simples substituição, a maioria das reuniões e entrevistas devem ser feitas com o próprio substituído. A isso chamamos Engenharia Reversa, técnica que ainda pode aparecer no decorrer desta série.
3. Gamestorming, Dave Gray, Sunni Brown e James Macanufo (O’Reilly, 2010);
   Visual Meetings, David Sibbet (Wiley, 2010);
   The Back of the Napkin, Dan Roam (Portfolio, 2008). Eu fugiria da edição nacional deste, uma lástima. De qualquer maneira, caso te interesse, foi traduzido como Desenhando Negócios e publicado pela Campus (2010).
4. Surrupiado de Gamestorming, listado acima. Os 7 P’s do nome, do original em inglês, são Purpose, People, Process, Product, Prep, Practical Concerns e Pitfalls. Eu sei, é barra forçada para parecer original. Este modelo, com pequenas variações, deve existir desde a época em que morávamos em cavernas. De qualquer maneira, não dá para negar sua utilidade.
5. O Líder Técnico, Gerald M. Weinberg (Makron Books, 1994).

Para esta sequência precisamos recuperar duas citações do artigo anterior:

• A conversão de dados em informação requer conhecimento. (Peter Drucker)
• Conhecimento é a capacidade de agir. (Karl-Erik Sveiby)

De carona nas afirmações acima conclui que “requisito é conhecimento produzido por conhecimento”. Estamos falando de aprendizagem – aprendizagem organizacional. Como uma organização aprende? Como ela gera (produz) e dissemina conhecimentos¹?

A resposta exige que saibamos que existem apenas dois tipos de conhecimentos²:

• Tácito: pessoal, específico de um contexto, difícil de comunicar. Existe em duas dimensões:
  • Técnica: comumente identificado como know-how (saber como fazer);
  • Cognitiva: crenças, valores, ideais, percepções, emoções e modelos mentais.
• Explícito: codificado, transmitido de maneira formal e sistemática.

O conhecimento tácito reside nos corações e mentes das pessoas. É aquele que vai embora da empresa todo dia lá pelas cinco ou seis da tarde³. O explícito fica – persistido em documentos, sistemas, bancos de dados, pôsteres, mensagens em correios eletrônicos e redes sociais etc.

A aprendizagem organizacional – a geração e disseminação de conhecimentos – se dá nas conversões de conhecimentos ilustradas no diagrama ao lado.

Na socialização – de conhecimento tácito para tácito – a troca se dá através de conversas e da observação ou experiência direta, tête-à-tête. É como se inicia um processo de aprendizado. Aqui temos razoável largura de banda – quantidade de informações transmitidas. Por outro lado, temos também um problema de escalabilidade. Pense em uma reunião com dezenas ou centenas de pessoas. A eficácia do aprendizado via socialização é inversamente proporcional ao número de participantes.

Ao sintetizar conhecimento tácito em explícito temos a externalização. Quando critico as verborrágicas especificações funcionais estou apontando para este quadrante. São notórias nossas dificuldades neste tipo de conversão de conhecimento. Mas não são novas. Diderot também penou bastante para transcrever naquela que seria nossa primeira enciclopédia um conhecimento que até então (circa 1750) era exclusivamente tácito. Ele queria explicar pelo menos o básico sobre todos os trabalhos artesanais da época. Descobriu que a observação ativa (para aprender) e as imagens (para explicar) eram as ferramentas mais eficazes. Hoje, no trabalho com requisitos, Diderot ainda tem muito a nos ensinar.

A conversão de conhecimento explícito em outro formato explícito é o que acontece na combinação. É o que faz um desenvolvedor, por exemplo, quando parte de modelos e especificações para criar código. É importante entender que combinação é síntese – criação de um novo todo a partir de partes distintas – e não uma mera tradução de formatos (ou o fatídico e dispendioso passar a limpo). Na combinação não há conhecimento novo sendo gerado. Por isso cada conversão deste tipo deve ser avaliada com carinho. O produto da conversão deve ter inequívoco valor para alguém ou para a organização. Um modelo ou documento que só existe porque “a metodologia exige” é grana que escorreu pelo ralo.

Por fim, temos a internalização – a conversão de conhecimento explícito em tácito. É o aprendizado que se dá a partir do que está escrito, desenhado ou registrado de alguma forma. Ao contrário da socialização, aqui temos grande potencial de escala (de atingir grande número de pessoas). Por outro lado, a banda não é tão larga – a quantidade de informações passíveis de transmissão é consideravelmente menor.

Essas conversões não ocorrem de maneira isolada ou única. A sequência descrita acima acontece infinitas vezes dentro de uma organização, formando uma espiral. Pois é, a aprendizagem organizacional é naturalmente iterativa (iterar = repetir) e incremental (construída a partir dos produtos das etapas anteriores). Dá pra imaginar o espanto e desalento dos papas dessa matéria quando apresentados aos cansativos debates sobre processos plan-driven versus change-driven. Porque essa divisão não existe!

O modelo SECI, nome do diagrama acima, não é uma proposta de processo ou método. É a conclusão de uma pesquisa²: é assim que as organizações aprendem, intencionalmente ou não. Reconhecer o modelo é o primeiro passo para uma conversa séria sobre aprendizagem organizacional e gestão do conhecimento.

Sintetizando: Nós conversamos sobre necessidades e restrições com nossos usuários e clientes (socialização); Durante e depois das conversas nós transcrevemos parte daquele aprendizado – estruturando requisitos, redigindo especificações de casos de uso, rabiscando modelos etc. (externalização); Criamos outras derivações dos requisitos – como mockups, storyboards, protótipos ou versões alpha e beta – de forma a confirmar que todos os envolvidos compartilham o mesmo entendimento (combinação); o confronto com esse conhecimento explicitado na forma de modelos ou versões de um sistema (internalização) nos dá novas certezas e dúvidas – novas necessidades e restrições – sobre as quais vamos conversar, o que nos remete ao início deste parágrafo.

Desta vez ficou fácil cravar o tema da próxima parte. Será sobre canais de comunicação e ferramentas sociais.
Porque tudo começa na socialização. Até lá!

Notas

1. Conhecimento é uma das cinco dimensões de um sistema sociocultural (de uma empresa, por exemplo). Quando apresentei o tema na série anterior, Pensando Negócios, escrevi que são dois verbos – duas preocupações – que caracterizam a forma como uma organização trata cada dimensão. Os verbos são Gerar e Disseminar. Neste novo contexto eles podem ser trocados por apenas um: Aprender. Se o tema lhe interessa, recomendo a leitura das partes V e VI daquela série.
2. Os pais do modelo aqui apresentado são Hirotaka Takeuchi e Ikujiro Nonaka. Recomendo dois trabalhos: Gestão do Conhecimento (Bookman, 2008) e Knowledge Management – Classic and Contemporary Works, coletânea de artigos compilada por Daryl Morey, Mark Maybury e Bhavani Thuraisingham (MIT Press, 2000). Os artigos clássicos de Takeuchi e Nonaka são de 1995/96. Um deles está neste último livro. Outro deu origem ao método conhecido como Scrum.
3. Tenho quase certeza de que o autor original desta brincadeira foi Thomas Stewart, autor de outro livro fundamental sobre aprendizagem organizacional: Capital Intelectual (Campus, 1998).