Requisitos e Conversas
O desenho do novo novo FAN Essencial: só Requisitos e Conversas. Um apêndice para a última série: o que o OODA pode nos ensinar sobre o tal sensemaking? E sobre requisitos e conversas?
Tem pouco mais de um mês que promovi o encontro de celebração dos 18 anos do FAN. Além da desculpa para rever amigos e revisitar memórias, acho que eu queria confirmar a vontade de continuar falando sobre aqueles assuntos. Não tinha passado nem doze horas do encerramento e cá estava eu rabiscando um novo programa. Trouxe para a mesa poucos princípios, ideias e palpites:
O nome FAN precisa permanecer; A sigla perdeu o sentido1.
O FAN sempre foi cuidadoso2 com os detalhes e com o trabalho de formiguinha. O que me remete ao Taleb3: “A macrobaboseira é mais fácil de pôr em prática do que a microbaboseira.”
Portanto, libere o FAN das macrobaboseiras: nada de metodologias, frameworks, máquinas de sensemaking4, topologias para times e resenhas de *BoKs5. Só isso deve liberar umas quatro horas da carga!
Se concentre nos pequenos trabalhos. Destaque os conhecimentos, habilidades e hábitos coletivos que fazem diferença na hora de definir, desenvolver e entregar bons projetos.
Lembre-se do novo mote: Não se aprende sozinho o que só se faz em conjunto.
O sobrenome ou subtítulo chegou antes do nome: Conversas e Requisitos.
A lógica é de uma simplicidade desconcertante: bons projetos começam com bons motivos e bons requisitos. Ambos emergem de boas conversas.
E, olha só!, toda boa conversa é coisa de gente. Ou seja, grande parte do programa tende a ser imune aos avanços das IAs.
Qual parte não é ou não precisa ser imune? Testes, redação formal e documentação. Que esses trabalhos e o uso de inteligências artificiais para realizá-los façam parte do novo FAN.
Só não coloque IA no nome, por favor!
Que assim seja: FAN Essencial
O Programa
Errei na primeira versão que tornei pública. Porque elaborei o programa a partir de quatro perguntas mal amarradas. A última estrutura do velho FAN girou em torno de oito trabalhos essenciais do Analista de Negócios6. Agora, para falar com todo o time e todos os times, eu preciso de uma estrutura nova. A espinha dorsal do curso tem seis itens. O FAN Essencial vai mostrar como:
Organizar e conduzir entrevistas e oficinas de requisitos
Desenhar mapas e modelos para facilitar e orientar as conversas
Elaborar perguntas de forma a enriquecer entendimentos e requisitos
Registrar requisitos de modo a testar e formalizar entendimentos
Mapear requisitos para guiar e garantir a gestão de seu ciclo de vida
Usar IAs para descobrir pontos cegos, testar requisitos e gerar documentos
Gosto de detalhar a forma como pretendo entregar cada um dos tópicos. Isso funciona como um contrato com os participantes: entreguei tudo? Entretanto, a extensão do programa quase sempre gera uma preocupação: dá tempo? Sempre deu. O FAN clássico, em turmas abertas, tinha 14 horas de carga. O novo tem doze.
O Sistema
Aquelas 14 horas do FAN clássico eram entregues em dois dias consecutivos. Geralmente sexta e sábado. Distribuição que reflete um problema comum dos treinamentos corporativos: eles são desenhados para atrapalhar o mínimo possível o dia a dia. E daí se sete horas de aula em um único dia é carga desumana? E daí se 60%~80% do curso é perdido?
Em 2019, um ano antes da pandemia, comecei a brincar com aulas online. Porque:
Precisava aumentar a eficácia e a transferibilidade das aulas e cursos7;
Precisava dar uma boa resposta para os cursos de $1,99; e
Queria passar menos tempo na estrada e mais tempo com a família.
Fixei o limite de duas horas por aula. Recomendo o máximo de três aulas por semana. Com as seguintes intenções:
Dar tempo para que a reflexão e o sono possam cumprir sua parte do processo de aprendizagem8.
Dar tempo para que os participantes possam experimentar, em seu contexto, o que foi apresentado naquele encontro. Nenhum exemplo ou exercício em sala de aula substitui essa experiência.
Criar tempo e espaço para que aquela aula possa ser debatida. Usando quadros virtuais, documentos compartilhados e grupos no Whatsapp, por exemplo. O que não falta é recurso. Falta o hábito. Ou será que é tempo9?
O que precisa ser feito?
Este subtítulo foi minha tagline por anos10. A pergunta tem dois pais. Peter Drucker, numa entrevista11 para a falida Business 2.0, disse o seguinte:
Crie um hábito. Escreva a pergunta
"O que precisa ser feito?"
no topo de cada página da sua agenda. Cole-a abaixo do relógio na parede da sala onde você realiza as reuniões de projeto. Adicione-a à sua assinatura de e-mail. Faça disso um esporte; veja quantas vezes, durante suas reuniões de projeto, você consegue perguntar e responder: "O que precisa ser feito?"
O outro pai é Fred Brooks:
A correta definição sobre o que precisa ser feito é a parte mais difícil de um projeto. Nenhuma outra compromete tanto quando mal executada. E nenhuma é mais difícil de ser corrigida.
Menos badalada, por incrível que pareça, é a seguinte distinção12:
O que precisa ser feito → requisitos
Como será feito → especificações
Se você soubesse quantos projetos e produtos fracassaram porque essa separação não foi entendida. Se você parar para pensar em quantos fracassos já estão contratados pelo mesmo motivo…
No velho FAN, lá pelas tantas, eu sacava o bom humor de Karl Wiegers13:
Verdade cósmica número 1: se você não entender bem os requisitos, não fará a menor diferença o quão bem trabalhe no restante do projeto.
OODA Mata vários Coelhos
Um apêndice não solicitado para a série aparentemente mal encerrada no post anterior. Adendo no estilo “entendeu ou quer que desenhe?”
Você só precisa concordar com os rótulos do eixo vertical: Concreto x Abstrato. Aqui em baixo, o mundo real; Lá em cima, as infinitudes que carregamos em nossas mentes. O OODA, quando usado corretamente, tem duas funções: sense-making e decision-making. A primeira corresponde ao lado esquerdo da matriz: Observação e Orientação.
John Boyd, o inventor desse papo, nos lembra que a Observação é a única parte do modelo que recebe entradas. A Orientação funciona a partir desses inputs. E é ali, na Orientação, que se ganham ou se perdem batalhas e guerras. É ali que uma pessoa ou organização se prova ágil. A matriz acima, em sua arrogante simplicidade, não mostra isso. O desenho original do Boyd não dá margem para dúvidas:
Agora, costurando todo o post, pense bem:
Será mera coincidência o fato de Drucker, Brooks, Wiegers e Boyd chamarem a nossa atenção para o mesmíssimo quadrante?14
Cotação
Não morda o meu dedo, Olhe para onde estou apontando.
No lugar de uma sigla, que tal fã? Entusiasta? Ventilador? Opa, ventilador tem duas utilidades. Por que não? Aliás, fan funciona como verbo também. São fantásticas essas palavrinhas multiuso.
Ou chato. Por exemplo: A redação de funções* deve seguir um único padrão
Verbo + Substantivo + [complemento]
Verbo no infinitivo. Vocabulário do negócio, sem traduções nem interpretações.
*Ah, e nós falamos FUNÇÕES, não requisitos funcionais. Chato assim.
A Cama de Procusto. Nassim Nicholas Taleb (Objetiva, 2022).
Sensemaking machines eu surrupiei do último livro do David Anderson, The Value Flywheel Effect: Power the Future and Accelerate Your Organization to the Modern Cloud (IT Revolution, 2022). Rivaliza, no pior sentido, com o último do Appelo que eu “resenhei” nos posts anteriores.
Guias para corpos de conhecimentos.
8 trabalhos que eram apresentados assim:
Pouquíssimas vezes, e só por solicitação de clientes, eu medi esse tipo de coisa através de provas. Em casos mais raros ainda, e de forma não premeditada, consegui chegar no nível 3 do modelo de avaliação do Kirkpatrick. Ainda sonho com o dia em que conseguirei medir, em reais ou dólares, o retorno de um projeto de aprendizagem.
“Não aprendemos com a experiência… aprendemos refletindo sobre a experiência”, ensina John Dewey. E dormindo com elas, ensinam diversos neurocientistas. O sono ajuda a selecionar e fixar o que foi importante durante o dia.
Alerta de pergunta retórica. Porque falta de tempo nunca é desculpa quando o assunto é sério e o interesse é legítimo.
Voltou a ser. Por tempo indeterminado.
Foi uma das últimas entrevistas de Drucker, em 2005. Ele faleceu em novembro do mesmo ano.
Outros pares possíveis: problema x solução, upstream x downstream, análise de negócios x análise de sistemas.
Não, o par discovery x delivery não representa bem essa moeda. Não faz sentido, assim como não faria Observação x Ação.
More About Software Requirements (Microsoft Press, 2006).
ps: Ah, macrobaboseiras de novo!?!