Tag: Comunicação

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

 

No capítulo anterior vimos, em linhas gerais, como uma organização aprende. A conversa de hoje é sobre socialização, mais especificamente sobre canais de comunicação e ferramentas sociais.

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