PAULO FERNANDO VASCONCELLOS NOGUEIRA

Blog

  • +Requisitos: Qualidade

    +Requisitos: Qualidade

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

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

    É Necessário?

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

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

    É Compreensível?

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

    Está Completo?

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

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

    É Verificável?

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

    É Viável?

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

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

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

    Está Priorizado?

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

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

    Está Correto?

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

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

     

    Notas

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

     

  • +Requisitos: Os Atributos

    +Requisitos: Os Atributos

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

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

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

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

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

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

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

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

    Balanço

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

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

    Restrições

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

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

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

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

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

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

    Preferências

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

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

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

     

    Notas

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

     

  • +Requisitos: Contando Histórias

    +Requisitos: Contando Histórias

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

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

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

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

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

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

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

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

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

    Epílogo

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

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

    Notas

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

    +Requisitos: As Funções

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

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

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

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

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

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

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

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

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

    A Nomenclatura Utilizada

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

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

    Jobs-to-be-done

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

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

    Notas:

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

     

  • Três Meses em Um Post

    Três Meses em Um Post

    Quando sumo daqui, podes crer, é porque estou desenvolvendo e distribuindo meu palavrório em outros meios. Minhas resistentes hérnias de disco me custaram todo o segundo semestre do ano passado. Por isso estou, literalmente, correndo atrás do prejuízo. Prejuízo que não é – nunca é – apenas financeiro. As ideias e sugestões apresentadas na forma de artigos durante todo 2012 careciam de ar, de contato com a vida real. Precisavam de feedback – de confirmação. Apresento neste artigo meus achados e perdidos.

    Arquitetura de Negócios

    A série Pensando Negócios foi condensada em uma palestra com cerca de noventa minutos de duração. Tive a oportunidade de apresentá-la em Belo Horizonte e São Paulo. Quando nem o título da palestra é uma certeza – “Arquitetura de Negócios” ou “Criando Negócios em Tempos Difíceis”? – qualquer retorno é bem vindo. Foram duas as minhas motivações: 1) Validar o Conteúdo; e 2) Confirmar a viabilidade de um evento maior, em formato oficina (workshop). Conclusão? O tema gera considerável interesse, apesar da notável nebulosidade que o cerca.

    Sigo dependendo de mais testes. Antes, trabalharei em nova versão do tabuleiro. Ele precisa se tornar uma ferramenta que sintetize todos os principais conceitos apresentados. Para tanto, é mais que necessário que ele consiga exprimir comportamento e não só a estrutura de um negócio. Será um desafio e tanto. E uma boa maneira de aprender mais.

    A Empresa ConectadaPor falar em aprender, saiu por aqui A Empresa Conectada (Novatec, 2013), de Dave Gray. Por beber nas mesmas fontes (Hamel, Ackoff, Senge, Geus, Takeuchi & Nonaka etc) e trazer o pensamento sistêmico para a cumbuca dos negócios, será referência obrigatória em meu trabalho. Dave Gray, que eu só conhecia pela co-autoria de Gamestorming (que também saiu por aqui, pela Alta Books), surpreende com um livro consistente, bem fundamentado e muito direto:

    “Quanto mais à prova de idiotas for o sistema, mais as pessoas agirão como idiotas.”

    “Clientes felizes são o melhor departamento de marketing que qualquer empresa poderia ter.”

    “Liderança é trabalhar com pessoas. Gerenciamento é trabalhar com sistemas.”

    “As pessoas trabalham mais arduamente quando têm paixão pelo trabalho e estão comprometidas com o sucesso. Elas ficam motivadas a realizar quando estão conectadas com o propósito do trabalho, quando entendem o sistema – de que maneira todas as peças e partes se encaixam – e quando têm o poder de melhorá-lo.”

    O Novo Novo FAN

    Tem pouco mais de um ano que liberei a nova versão do programa {FAN} Formação de Analistas de Negócios com quatro módulos. Não posso culpar apenas minhas hérnias pelo fato de não ter testado de maneira adequada o novo formato. Não é fácil vender novos programas de treinamento. Ainda mais quando se usa nomes como {FAN} +Conversas! Mas, apesar dos pesares, tudo o que fiz nas últimas dez semanas foi testar e testar e testar o novo conteúdo. Para tanto, o apresentei em duas turmas abertas e três turmas fechadas. Nas turmas abertas aprendi que a separação entre +Requisitos e +Conversas não faz muito sentido, mesmo que boa parte do público insista em dizer que quer “só requisitos”. A boa notícia é que os módulos já foram desenhados de forma a facilitar um merge (sic). Experimentei a combinação, com carga horária reduzida, em uma turma de pós-graduação da Federal de São Carlos. O resultado foi bastante positivo.

    No entanto, eu precisava de mais problemas de verdade – precisava de testes que só são possíveis em empresas. Ganhei oportunidades em uma grande empresa da área financeira e outra que presta serviços de pesquisa e desenvolvimento combinando hardware e software. Não podia querer maior diversidade. Posso dizer que o FAN “aguentou o tranco”.

    A sequência da série sobre Requisitos e Conversas dependia desta generosa bateria de testes. Espero retomá-la em breve e farei o possível para concluí-la até junho. Também em junho retomarei as turmas abertas, com o FAN refletindo essas dez semanas de aprendizado. Para comemorar seis anos de vida, o programa virá com uma série de novidades.

    O Velho finito

    Agora em maio o finito completa nove anos de existência. Não são muitos os blogs que podem se preparar para comemorar o décimo aniversário. Elaborei uma listinha com coisas que este espaço pode ser/ter. Mas, antes de colocar a mão na massa, eu queria merecer algumas sugestões de minha meia dúzia de leitores. O que você gostaria de ler/ver por aqui? Quais temas devem merecer mais espaço? O que você faria de diferente?

    Agradecimentos

    Simone, Angelita, Ariane, Jaqueline, Valesca, Érica, Igor, Jean, Renato, Célio, Feio, Alberto, Carlos, Andrei, Anderson, Rodrigo, Fernando, Paulo… sei que cometo injustiças quando tento me lembrar todos que apoiaram os eventos dos últimos três meses. O fato é que não me esqueço de todos que fizeram um esforço extra, seja nos necessários feedbacks, seja por divulgar meu trabalho ou por topar viagens e outros sacrifícios. Minha dívida com vocês só faz crescer.

    Three Things, a imagem que ilustra este artigo, é do conskeptical.

     

  • Stoos Connect: Um Resumo

    Stoos Connect: Um Resumo

    Aconteceu na última sexta-feira (25/jan) o Stoos Connect, evento sediado em Amsterdam e transmitido para todo o mundo. Derivado do movimento Stoos, a reunião se propôs a debater liderança, gerenciamento e novas práticas, dentre outras coisas. Este artigo apresenta um breve resumo das conversas.

    Todo evento muito longo – este durou cerca de oito horas, contando os intervalos – é cansativo. Se houvesse uma variação de formatos e maior participação da plateia talvez não fosse uma experiência tão extenuante. Confesso que abandonei o barco depois das 18h30 – depois de seis horas e meia de palestras. Algumas foram bem curtas, duraram cerca de cinco minutos. Outras, as melhores, tiveram cerca de vinte minutos de duração. A diversidade de temas ajudou a prender a atenção.

    O que não significa que não tenha havido redundâncias. A ideia de que o gerenciamento tal qual é conhecido hoje está obsoleto foi recorrente. Começou com Jaap Peters, que foi lá na raiz: citou The Principles of Scientific Management de Frederick Taylor. Está neste trabalho uma colocação que de certa forma sintetiza TUDO o que se entende sobre negócios e gerenciamento (e a vida…) desde o início do século 20: “No passado, o homem foi o primeiro. No futuro, o sistema será o primeiro.”

    Gerenciamento *1911 †1970 -Niels PflaegingQuando você vê uma ênfase doentia em planejamento e processos está assistindo a realização da profecia de Taylor. Planos e processos são arquitetados para que alguém seja dispensado de utilizar a única coisa que o diferencia de um ornitorrinco: o cérebro. Ok, o ornitorrinco é um bicho diferentão. Mas você entendeu meu ponto. O que há de nefasto e hoje facilmente condenável na proposição de Taylor¹ e contemporâneos é a separação entre o pensar e o fazer, como destacou Niels Pflaeging em sua fala. Aliás, o título da palestra de Niels é uma provocação por si só: O Gerenciamento é Dispensável.

    Quem acha que essa ideia só faz sentido em organizações com maduros trabalhadores do conhecimento precisa urgentemente conhecer O Que Importa Agora, de Gary Hamel (Campus, 2012). Aliás, Hamel foi a cereja que faltou ao bolo do Stoos Connect.

    Daniel Pink, autor de O Cérebro do Futuro (Campus, 2007) dentre outros, reforçou a mensagem sobre gerenciamento com outras palavras. Gerenciamento é uma tecnologia. Como toda tecnologia, ele ficou obsoleto. Seria urgente, portanto, um “recall” das organizações.

    Possíveis executores deste “recall” foram convidados – via Skype – por Peter Vander Auwera. Ele apresentou um grupo chamado Corporate Rebels United. Vale a pena dar uma olhada no manifesto.

    Rolaram palestras com temas mais específicos, como Vendas Nobres (não seria um oxímoro?), por Lisa Earle McLeod e Cultura Corporativa (três erros comuns que as empresas cometem) por Dawna Jones. Dawna fez uma colocação que merecia mais tempo e melhores explicações: “Podemos utilizar os mesmos princípios da natureza para guiar um sistema-negócio”. Quais princípios? Todos? Tá falando sério?

    Jurgen Appelo, autor de Management 3.0, não surpreendeu. Entrando na terceira parte do evento, não choveu no molhado. Optou por um tema bem específico: motivação e remuneração. Jurgen oferece um necessário contraponto à ideia de que a motivação intrínseca (de um trabalhador) bastaria: “Todos temos contas para pagar no final do mês”. Grana é importante. Bônus são importantes. E podem funcionar sim como motivadores. Mas é preciso saber fazer. Jurgen propõe um mecanismo simples, transparente e com bastante potencial. “Merit Money“, um artigo sobre o tema, será disponibilizado em breve.

    Perdi a apresentação do Steve Denning, mas ele publicou um generoso resumo aqui.

    Em suma, foi um evento legal. Eu esperava algo mais interativo e variado – não uma sequência muito longa e cansativa de palestras. Como o “diagnóstico” (do estado atual das coisas) é bem conhecido e a concordância com ele é o que leva uma pessoa para um evento desse tipo, era de se esperar mais propostas, mais ideias novas. Mas valeu a pena – valeu uma tarde de sexta.

    Para quem ficou curioso, creio que as palestras logo serão disponibilizadas via Youtube ou algo assim. Você pode ter notícias através do site do evento ou no grupo no LinkedIn.

     

    Notas

    1. Niels Pflaeging colocou que Taylor é herói e anti-herói do gerenciamento. No geral, Taylor tem sido apresentado como o grande culpado pelo estado atual das coisas no mundo dos negócios. É merecido? Por profecias como aquela citada neste artigo, poderia ser. Sinceramente, acho sua contribuição – seja para o bem ou para o mal – um tanto exagerada. Tamanho caos não pode ser produto do trabalho de apenas uma pessoa.

     

  • +Requisitos: Outro Exemplo

    +Requisitos: Outro Exemplo

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

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

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

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

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

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

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

    – Qual ou quais problemas essa ferramenta resolveria?

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

    –  Existem outros (problemas)?

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

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

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

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

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

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

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

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

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

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

     

    Notas

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

     

  • Pipoca!

    Pipoca!

    Entrada diferente em nossa biblioteca. Para começar o ano, filmes ao invés de livros. Fiz uma pequena seleção de títulos que divertem e/ou ensinam. Só uma coisinha lhes dá liga: negócios. Espero que você goste.

    A Roda da Fortuna

    (The Hudsucker Proxy – Irmãos Coen, 1994)

    A Roda Da FortunaUm filme para ver e rever. Tim Robbins mostra como uma inovação pode catapultá-lo para o alto escalão de uma empresa. Paul Newman está impagável no papel de um executivo. Comédia nota 10. De quebra, você aprende um pouco sobre modelagem de negócios.

    Também é dos irmãos Coen uma das mais hilárias histórias de projetos já filmada, Matadores de Velhinha (The Ladykillers, 2004). Tom Hanks faz uma boa caricatura de um gerente de projetos. Nunca foi tão fácil colocar a culpa pelos fracassos em um time. Que time!

    O Sucesso a Qualquer Preço

    (Glengarry Glen Ross – James Foley, 1992)

    Contraponto para as comédias acima. Mostra como é o ambiente de uma empresa que estimula a concorrência interna de maneira doentia. Al Pacino, Jack Lemmon, Kevin Spacey, Alec Baldwin e Ed Harris dão show de interpretação.

    Amor sem Escalas

    (Up in the Air – Jason Reitman, 2009)

    Os Homens Que Encaravam CabrasO trabalho de Ryan Bringham (George Clooney) é viajar e demitir. O bom do filme é o quanto ele nos faz refletir. Tem uma ou outra pitada de comédia e romantismo. Mas é sombrio e ilustra bem uma história recente do “primeiro mundo”.

    E por falar no Clooney. Ele participa de uma das melhores comédias dos últimos anos, Os Homens que Encaravam Cabras (The Men Who Stare at Goats – Grant Heslov, 2009). Ok, é sobre o exército, não sobre negócios. Mas assista e me diga se aqueles gurus não têm tudo a ver com alguns “consultores” de negócios que vemos por aí. Ah, os métodos e remédios dos “consultores”…

    Trabalho Interno

    (Inside Job – Charles Ferguson, 2010)

    Trabalho InternoA crise de 2008 (ainda sem fim) tem rendido bons filmes. O mais didático deles é este documentário narrado por Matt Damon (da Trilogia Bourne). Ilustra bem como a banca internacional e os governos criaram a mais séria crise do capitalismo depois da grande quebra de 1929. Outra utilidade: aprender a contar uma história pra lá de complexa de forma simples e objetiva.

    Sobre o mesmo tema merecem destaque outros três filmes. Grande Demais para Quebrar (Too Big to Fail – Curtis Hanson, 2011) foi feito para a TV mas tem jeitão de cinema. E conta com atuações impecáveis de William Hurt e James Woods. Mostra como grandes bancos e o governo americano lidaram com a crise logo que ela estourou.

    Uma perspectiva diferente do mesmo fato é mostrada em O Dia Antes do Fim (Margin Call – J.C. Chandor, 2011). O título em português é divertido, entrega todo o suspense da trama. Trata-se de uma dramatização do que teria ocorrido em um grande banco de investimentos na noite em que um analista de riscos descobriu o tamanho do rombo que eles criaram. A primeira cena com Kevin Spacey é estarrecedora. A sinceridade do CEO interpretado por Jeremy Irons (“Não estou aqui por causa de minha inteligência”) é desconcertante.

    Oliver Stone não perderia a chance de aproveitar a crise para retomar uma história iniciada em 1987. Produziu e dirigiu Wall Street: O Dinheiro Nunca Dorme (Wall Street: Money Never Sleeps, 2010). É inferior aos três anteriores, mas vale pelas atuações de Michael Douglas e Shia LaBeouf.

    Tempos ModernosContei agora, nove sugestões. Quero crer que para todos os gostos. Mas falta um para a lista ficar redonda. Que tal um clássico, pioneiro ao levar o mundo dos negócios para o cinema? Tempos Modernos (Modern Times – Charles Chaplin, 1936) dispensa comentários.

    E suas dicas, quais são?

     

     

     

     

  • O Improviso e o Jeitinho

    O Improviso e o Jeitinho

    Convite para uma reflexão sobre a série +Requisitos +Conversas.

    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.

     

  • +Requisitos: Perguntas?

    +Requisitos: Perguntas?

    O capítulo anterior apresentou os principais canais de comunicação e ferramentas sociais que utilizamos no trabalho com requisitos. Antes, em +Requisitos +Informação, vimos que uma Resposta = Informação + Confirmação + Ruído. Buscamos requisitos em respostas. Mas, como as obtemos? O que perguntamos?

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