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.

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

Artigos relacionados:

1. Pensando Negócios – Referências

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.

No related posts.

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?

Artigos relacionados:

1. +Requisitos: Perguntas?
2. +Requisitos do Negócio
3. +Requisitos do Negócio | Exemplos
4. +Conhecimento sobre Requisitos
5. +Requisitos +Informação
6. Casos de Uso, Requisitos Funcionais e Probleminhas [Atualizado]

A Roda da Fortuna

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

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

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

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

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

No related posts.

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.

Artigos relacionados:

1. +Requisitos: Perguntas?
2. +Conversas: Canais & Ferramentas
3. O País do Jeitinho não Inova
4. +Requisitos do Negócio
5. Irritando o ‘seu’ Moreira
6. Use Case 2.0: Você precisa dele?

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:

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:

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:

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:

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:

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.

Artigos relacionados:

1. +Requisitos +Informação
2. +Requisitos do Negócio
3. O Improviso e o Jeitinho
4. +Aprendizado sobre Requisitos
5. +Requisitos do Negócio | Exemplos
6. +Conhecimento sobre Requisitos

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.

Avaliando Canais de Comunicação

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:

Um Modelo para Boas Reuniões

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:

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.

Artigos relacionados:

1. O Improviso e o Jeitinho
2. +Requisitos: Perguntas?
3. +Requisitos +Conversas
4. +Requisitos +Informação
5. +Aprendizado sobre Requisitos
6. Irritando o ‘seu’ Moreira

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

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²:

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.

Modelo SECI

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.

Como Diderot observou e desenhou o trabalho do seleiro.

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á!

Artigos relacionados:

1. Promovendo o Aprendizado Inter-Projetos
2. Aprendizado Interprojetos
3. (Requisitos) Levanta aí que eu Coleto daqui
4. Formas de Transferência de Conhecimentos Inter-Projetos
5. +Conhecimento sobre Requisitos
6. Conceitos Básicos

Como a conversa no artigo anterior ficou bem “matemática”, segue mais uma fórmula:

Requisito = (Informação * Confirmação) – Ruído

Vimos na introdução desta série que a informação representada por um requisito é uma “condição necessária para alcançar certo fim”. Depois, vimos que este “certo fim”, em nosso contexto, é um conjunto de objetivos do negócio. Objetivos que podem ser detalhados e organizados na forma de requisitos do negócio. É suficiente, para o desenvolvimento e condução de um projeto, que se conheça apenas essas informações (condições e fins) devidamente confirmadas e livres de ruídos? Sim, desde que interpretemos a variável “informação” da fórmula acima de uma maneira bem ampla.

Se você não aprender corretamente os requisitos, não fará a menor diferença o quão bem trabalhe no restante do projeto. -Karl WiegersÉ relativamente comum que se conheça muito pouco sobre um requisito. Assim como são irritantemente corriqueiras as longas e amorfas transcrições textuais transmitidas e recebidas como sendo os “requisitos” de um projeto. É difícil encontrar bons requisitos nesses catataus.

Assim como será praticamente impossível encontrar um cliente ou usuário que, durante a exposição de seus objetivos e condições, aja mais ou menos assim: “Vou relacionar os requisitos funcionais, anota aí. Prepare-se para os não funcionais. Agora, às restrições. Por fim, falemos sobre regras de negócio”. Este usuário não existe. E não precisa existir!

Cabe ao analista os processos de estruturação e enriquecimento dos requisitos. Aliás, se ele fizer só isso por um projeto já terá justificado seu salário. Se você acha que isso é muito pouco, por favor, continue lendo.

Estruturar significa organizar – separar os mais diversos tipos de requisitos e demais informações. Porque cada um deles merecerá um destino diferente. Porque cada um pede tratamento e ferramental específicos. Veremos isso nos capítulos sobre Funções, Atributos, Preferências e Restrições.

Enriquecendo Requisitos

Tipo

Aqui simplesmente colocamos cada requisito em sua devida caixinha. Na classificação mais básica possível teríamos: Requisitos do Negócio, Funções, Atributos e Restrições. Quem quiser ser mais específico pode diferenciar requisitos de usabilidade, de dados, telas, relatórios, integração, transição, segurança etc. No modelo proposto por Suzanne e James Robertson¹ existem apenas: Restrições, Requisitos Funcionais, Não Funcionais e de Tecnologia. Com certeza há uma separação e nomenclatura mais adequadas para sua organização ou projeto. Esta série utilizará a primeira lista acima em todos os exemplos.

Fonte

O nome de quem manifestou aquele requisito pela primeira vez. A tabelinha² Fonte pode, obviamente, ser completada por outras informações como cargo, departamento etc. Em alguns casos não é possível identificar uma pessoa. Quando tudo o que um analista tem em mãos é um edital, por exemplo. Nessas situações (terríveis) registramos apenas o documento e, eventualmente, capítulos e páginas.

Só não recomendo que se registrem aqui informações sobre o impacto que o projeto terá sobre a pessoa e sua influência. Porque são informações do tipo caixa preta que deveriam ser persistidas em um local menos público.

Perspectiva

É o ponto de vista defendido pela fonte. Sugiro uma distinção bem simples:

Além dessas, podemos ter perspectivas que não participam diretamente do negócio. Legal, por exemplo, para representar o corpo jurídico da empresa; Técnico para diferenciar todos os requisitos que vieram de TI e assim por diante. Em cada organização ou projeto podem existir pontos de vista diferentes que merecem destaque.

Repare no diagrama acima que, apesar de qualificar a Fonte, a Perspectiva é um atributo do Requisito. É o primeiro mecanismo do modelo que visa a resguardar a história do projeto. Quando uma pessoa for promovida, mudando assim sua perspectiva, não levará consigo seus antigos requisitos. Fica registrado que, quando aquela pessoa manifestou determinado requisito ainda defendia o ponto de vista “operacional”, por exemplo.

Valor

Todo requisito tem um valor (benefício) e um custo. Representamos aqui qual é a contribuição de determinado requisito para a realização dos objetivos do negócio. Podemos utilizar uma escala bem simples, como:

Quem precisar de uma escala maior pode utilizar, por exemplo, a sequência de Fibonacci. Costumo recomendar um pequeno subconjunto: 1, 2, 3, 5, 8, 13. Em situações que envolvam quatro ou mais interessados (proponentes de requisitos), sugiro também o uso do Planning Poker para a valorização das necessidades e restrições apresentadas. Geralmente esta ferramenta é utilizada apenas para estimativas de esforço, o que é um desperdício. Quando utilizamos unidades relativas, é importante que valor (benefício) e estimativas (custo) sejam medidos com a mesma régua. Tanto melhor se utilizarmos o mesmo método. No capítulo sobre estimativas e planejamento isso será melhor explicado.

Este assunto merece livros inteiros. Porque está aqui boa parte dos problemas que presenciamos em projetos. Quanta grana se desperdiça com funções que raramente ou nunca são utilizadas; Quanto tempo é perdido em requisitos que representam nada ou muito pouco para a solução do verdadeiro problema; Enfim, como faz falta uma visão compartilhada sobre aquilo que realmente interessa em um projeto.

Em praticamente tudo o que compramos ou construímos há prioridades e alternativas. Na lista do supermercado, no carro ou na casa nova pensamos em itens fundamentais, importantes e supérfluos ou opcionais. É curioso como no mercado de software sobrevive, por muito tempo, um jogo de tudo ou nada. Curioso porque software é infinitamente mais maleável que casas, carros e listas de supermercado.

O que deve ficar, neste ponto, é a consciência de que esta pergunta – “Ilmo. Sr. Usuário, quanto vale esta solicitação?” –  deve ser feita. Imediatamente após a apresentação do requisito. O cliente ou usuário pode se enganar ou, em raros casos, tentar ludibriar o analista. Momento este que aciona o lado crítico do analista: “Me explique, caríssimo Usuário, como a função X (ou o atributo Y) ajudará a ACME a aumentar em 30% o faturamento”. Sim, os objetivos e requisitos do negócio devem balizar todos os demais requisitos. Não há outra maneira de analisar e de fato criticar e priorizar requisitos. Não há!

Relações com os Outros Requisitos

Rastreabilidade Vertical e Horizontal

Há outro tipo de rastreabilidade, igualmente necessária mas não contemplada nesta sugestão. Ela trata do relacionamento entre requisitos e elementos da solução. Quem sabe usar (direitinho) a UML não precisa se preocupar com isso. Os demais ficarão com uma bela pulga atrás da orelha.

É bastante provável que neste momento lhe tenha caído uma ficha: “Caramba! Quanto trabalho!” Entendeu agora porque um analista de negócios ganha tão bem? Brincadeirinha… A mensagem é outra.

O diabo está nos detalhes. Em projetos, cada requisito é um conjunto de detalhes. O dito cujo se lambuza.É impossível – repito, é impossível realizar este trabalho de análise em um lote muito grande de requisitos. O bom profissional deve saber que boa parte do trabalho de análise de requisitos ocorre em paralelo à elicitação (sic 100x!), ou seja, no momento em que um requisito aparece ele já começa a ser analisado (estruturado, enriquecido, relacionado… você entendeu). A outra boa parte do trabalho de análise de requisitos ocorre imediatamente após um evento de coleta (sic 1000x!)³. Enquanto as informações ali aprendidas ainda estão frescas na memória dos participantes e, principalmente, dos analistas.

Outra mensagem: se o analista envolvido com requisitos não faz este trabalho ele não está fazendo seu trabalho. Ponto!
Não há análise, seja de requisitos ou de negócios, feita no atacado, por cima, nas coxas…

Testes

E por falar nas coxas… Hora de conversar um pouco sobre testes. Lembra-se da fórmula que abriu este capítulo?

Requisito = (Informação * Confirmação) – Ruído

Os testes são os grandes responsáveis por gerar confirmação e também por subtrair ruídos dos requisitos. Não por acaso, é o único atributo do modelo sugerido que mantém relação de muitos para muitos com os requisitos. Este tema também merecerá um capítulo só seu. Por enquanto, é importante o entendimento de que os testes ocorrem em diversos momentos e com propósitos distintos. No início, durante uma entrevista, por exemplo, testamos um requisito no sentido de confirmar i) Nosso entendimento; e ii) Sua (do requisito) real necessidade. Nos momentos seguintes, de forma isolada ou em conjunto, os requisitos são submetidos a baterias de testes que visam a i) Confirmar nosso entendimento; e ii) Confirmar a sua (do requisito) realização.

Teste é sinônimo de confirmação, feedback, refinamento e aprendizado. Não deveria estar relacionado com coxas.

Estado

Enfim, o último atributo básico que todo requisito deveria merecer. Aqui simplesmente posicionamos o requisito em um momento de seu ciclo de vida. Podemos utilizar a mesma nomenclatura das divisões de um quadro kanban, por exemplo: Em Espera; Em Execução; Em Testes; Entregue. Claro, sua organização ou projeto pode requerer uma visão diferente, mais detalhada. O importante é que se saiba, a qualquer momento, qual o estado de cada requisito.

A Tabela Central

A tabela² Requisitos possui, além das diversas chaves estrangeiras (ligações com outras tabelas), alguns campos próprios. Mantendo o padrão, relaciono abaixo o que considero o mínimo necessário:

Revendo Tudo

Depois deste tour de force, quem sabe o que virá a seguir?

Artigos relacionados:

1. +Requisitos do Negócio
2. +Requisitos +Informação
3. +Requisitos +Conversas
4. +Requisitos do Negócio | Exemplos
5. Casos de Uso, Requisitos Funcionais e Probleminhas [Atualizado]
6. Estruturando Requisitos – Parte 2

Definindo Informação

Na prática: o previsível, o corriqueiro, o redundante e o repetitivo não nos ensinam (informam) nada ou praticamente nada. (Esta frase  parece querer confirmar o que ensina.) E o valor daquilo que pouco informa é irrisório ou nulo. Particularmente em projetos, porque informação é sua principal matéria-prima.

Choque de realidade: talvez você já tenha visto por aí um catatau com dezenas ou centenas de páginas chamado “especificação funcional” (sic) ou algo parecido. Aplique a fórmula ou regrinha acima para ter uma rápida noção do valor, da quantidade de informação de verdade que aquele documento carrega. Lembre-se das redundâncias, ambiguidades, contradições e encheção de linguiça ali persistida. Agora considere quanto aquele entregável (sic 10x) custou: as horas gastas em entrevistas, reuniões, revisões do documento etc. O quão economicamente útil é um documento assim?

Vale dizer, o problema nem é necessariamente o formato. Tem muito quadro kanban por aí que mal vale uma nota de três reais, apesar da sua belezura e pseudo-modernidade. Antes da forma, deveríamos nos preocupar com o conteúdo.

+ Comunicação

O Houaiss nos ensina que comunicação é a “transmissão de uma mensagem”. A crença na eficácia desta comunicação de uma via tem causado sérios problemas. Até no frio relacionamento entre computadores há a preocupação com a recepção – com a garantia da entrega de uma mensagem. Na comunicação entre pessoas a questão é um tanto mais complexa.

Existem diversos modelos² que ilustram todo o processo de comunicação entre pessoas. Vou apelar para um básico³:

Em nosso dia a dia, em todo tipo de comunicação, o processo pode ser interrompido em qualquer ponto acima. Você pode, por exemplo, entender o que está escrito aqui e não aceitar e consequentemente não fazer nada a respeito. No trabalho com requisitos é importante que o analista busque o quinto estado – a conversão em ação – de toda informação de fato relevante para o projeto.

Quando trabalhamos em projetos, particularmente com requisitos, deveríamos ver comunicação da seguinte maneira⁴:

Comunicação = Informação * Relacionamentos * Feedback

A informação vale por si só, por ser “a diferença que faz diferença”. Mas sua simples transmissão não tem valor nenhum. A fórmula acima sugere que a comunicação vai de fato ocorrer se existir um bom relacionamento entre os interlocutores. Mas não basta. Mesmo no mais harmonioso dos ambientes, a comunicação exige mecanismos de feedback que garantam que a mensagem transmitida seja recebida, entendida, aceita e, de alguma maneira, convertida em ação.

O alcance da definição acima ultrapassa e muito o escopo desta série. Tentarei mostrar apenas a relevância daquela fórmula nos trabalhos de desenvolvimento e análise de requisitos.

Para tanto, que tal outra fórmula⁵?

Resposta = Informação + Confirmação + Ruído

A confirmação verbal do entendimento é a melhor depois da telepatia. -Jurgen AppeloA confirmação é o tal mecanismo de feedback da fórmula anterior. Precisamos dela, mas nem sempre a conseguimos na primeira resposta. Independentemente da qualidade da pergunta. Por isso consideramos que uma resposta sem confirmação está incompleta. E formulamos a questão seguinte com o único propósito de obtê-la.

Entre informações e confirmações, invariavelmente recebemos ruídos. Merece este nome – ruído –  aquela palavra, gesto, olhar, sussurro ou tic nervoso que não conseguimos decifrar em um primeiro momento. Pode não ser nada. Mas pode ser uma informação ou mesmo uma confirmação carente de atenção. Decifrar ruídos no sentido de obter boas respostas e excelentes requisitos é uma das artes (secretas?) dos bons analistas.

Esta série ainda merecerá um ou mais capítulos específicos sobre conversas, perguntas , respostas e ruídos. O básico do básico sobre informação e comunicação foi colocado. No próximo artigo conversaremos especificamente sobre informações em requisitos. Te espero lá.

Artigos relacionados:

1. +Conhecimento sobre Requisitos
2. +Requisitos: Perguntas?
3. +Requisitos do Negócio
4. +Aprendizado sobre Requisitos
5. +Requisitos do Negócio | Exemplos
6. +Conversas: Canais & Ferramentas