4. Logline e Argumento

Parte II — A Linguagem

Todo projeto tem uma razão de existir. A logline é essa razão em uma única frase.

Não é o nome do projeto. Não é uma lista de funcionalidades. Não é uma visão de negócio de três parágrafos. É uma frase que qualquer pessoa lê e entende o que o projeto faz, para quem e por que importa.

Se o projeto sair dessa frase, saiu do projeto.

A logline

Propósito

A logline é o contrato de intenção. Define o norte do projeto antes de qualquer artefato ser produzido.

Quando o escopo cresce sem controle, quando surgem pedidos que "não eram para estar aqui", quando o projeto termina entregando algo diferente do combinado — a causa quase sempre é a mesma: ninguém escreveu a logline.

A logline não impede mudanças. Ela torna as mudanças visíveis e conscientes. Todo software, toda casa, toda campanha tem uma logline invisível; o Corsoo a torna explícita e rastreável.

Estrutura

Para [quem] + [problema ou contexto] + o [produto] + [resolve de que forma]

Exemplos

Corsoo "Para equipes que precisam entregar, o Corsoo integra escopo, cronograma, orçamento, recursos, riscos, papéis e dependências em uma visão única, concisa e indexada."

SAP "Para empresas que precisam operar de forma integrada, o SAP centraliza finanças, estoque, RH e operações em um único sistema."

Calculadora "Para quem precisa calcular, a Calculadora resolve operações matemáticas de forma rápida e confiável."

Uma casa "Para a família que precisa de um lar, a Casa oferece um espaço para viver com conforto, segurança e identidade."

Regras

Máximo 280 caracteres. Se não cabe em 280 caracteres, o projeto ainda não está claro o suficiente para começar.

Uma frase. Ponto final. Não dois períodos, não lista, não parágrafo.

Sem jargão técnico. A logline é lida pelo dono da empresa, pelo cliente, pelo desenvolvedor e pelo designer. Se algum deles não entende, reescreve.

Sem o que o projeto não faz. A logline diz o que é, não o que não é.

O herói é quem usa, não quem constrói. "Para a equipe de desenvolvimento entregar software..." está errado. O herói é quem se beneficia, não quem produz.

Erros comuns

O teste da logline

Uma logline está pronta quando passa nos três testes:

1. Teste do estranho — mostre para alguém que não conhece o projeto. Essa pessoa consegue dizer o que o projeto faz e para quem? Se sim, passou.
2. Teste do escopo — quando surgir um pedido novo durante o projeto, pergunte: isso está na logline? Se não está, é uma mudança de escopo consciente, não uma adição casual.
3. Teste da jornada — o herói da logline consegue completar sua missão com o que o projeto entrega? Se não, o projeto não está completo (ver Capítulo 14).

O argumento

Se a logline é a razão de existir, o argumento é a justificativa de negócio em formato executivo.

Não é um resumo da logline. Não é uma descrição de funcionalidades. Não é um documento técnico. É o artefato que responde, para quem aprova o greenlight: por que o projeto deve existir, quanto custa não fazê-lo e o que a organização passa a ter quando for entregue.

Se o argumento não sustenta a decisão de greenlight, o projeto não está pronto para começar.

A audiência

A audiência do argumento é executiva: CEO, CFO, conselho, investidor, patrocinador. Essa audiência não avalia tecnologia — avalia valor. A pergunta que o argumento responde é:

O que essa organização ganha, deixa de perder ou passa a fazer com esse projeto que não consegue sem ele?

Quando o argumento não está escrito, o projeto depende de apresentação verbal para ser aprovado. Apresentação verbal não é artefato: não é rastreável, não é verificável. O argumento torna a justificativa de negócio parte permanente do projeto.

Estrutura — três seções obrigatórias

Seção 1 — A dor do negócio. Descreve o problema com precisão para aquele negócio, aquele mercado, aquela realidade — não de forma genérica. Quando há números, a dor fica concreta: custo de horas perdidas, taxa de retrabalho, contratos perdidos. Quando não há, a dor é descrita com evidências: situações recorrentes, consequências visíveis, padrões documentáveis. O leitor precisa reconhecer o problema como seu.

Seção 2 — A solução. Apresenta o projeto como resposta direta à dor. Descreve a abordagem, não as funcionalidades: o que muda na forma de operar, o que passa a existir, o que deixa de acontecer. Cada dor da seção 1 tem resposta nesta seção. Se uma dor ficou sem resposta, a solução está incompleta.

Seção 3 — Resultado esperado. Descreve o valor em três horizontes:

• Curto prazo — o que muda imediatamente após a entrega.
• Médio prazo — o que se acumula com o uso contínuo.
• Longo prazo — o que se transforma de forma estrutural.

O resultado não precisa ser numérico, mas precisa ser concreto. "Melhora a produtividade" não é resultado. "A equipe passa a entregar projetos no prazo sem depender de status report semanal" é resultado.

Limites

Mínimo três seções. Máximo duas páginas. Um argumento que passa de duas páginas está substituindo o roteiro — corte até sobrar apenas o essencial para a decisão de greenlight.

Erros comuns

• Argumento genérico — "vai melhorar a produtividade e reduzir custos" é intenção sem substância.
• Dor sem evidência — dor que a audiência executiva não reconhece como sua não convence.
• Resultado sem horizonte — sem distribuição no tempo, ninguém sabe quando esperar retorno.
• Funcionalidade no lugar de resultado — "o sistema terá dashboard em tempo real" é feature. "A liderança decide com dados atuais sem aguardar relatório" é resultado.

O teste do argumento

1. Teste executivo — quem aprova orçamento consegue, após a leitura, justificar internamente a aprovação?
2. Teste da linha direta — cada dor da seção 1 tem resposta explícita na seção 2?
3. Teste do horizonte — os resultados da seção 3 são concretos e distribuídos no tempo de forma crível?

Logline, argumento, roteiro — a escada de precisão

Os três artefatos da fase de desenvolvimento formam uma escada. Cada degrau expande o anterior sem contradizê-lo:

Se o roteiro contradiz a logline, um dos dois está errado — e a conversa que resolve isso é a mais barata do projeto, porque acontece antes de qualquer execução.

O próximo capítulo entra no coração da metodologia: o roteiro.

Corsoo, Engenharia de Organização · corsoo.org

← Engenharia de Organização · Sumário · Próximo: O Roteiro →