700 mil euros chega para aprender isto

Hey,

Alguma vez te contei a razão pela qual deixei a arquitetura?
A versão curta: não dá dinheiro. É o que digo quando quero despachar quem me ouve. Não é mentira, mas também não é a verdade toda.

A razão mais profunda? Passei três meses só a desenhar portas. Encaixes de madeira. Dobradiças. Puxadores. Três meses. E no fim desses três meses continuava a achar que podia melhorar. Esse é o problema, eu sou obcecado por detalhes que poucos conseguem ver.

É aí, escondido em horas investidas, que mora a miséria do arquiteto.
Eu e os apaixonados pelo processo não distinguimos entre um anexo e um mosteiro. Merece tudo carinho. Começas pelo conceito. Passas para a organização da casa. E investes semanas até ficares satisfeito com a função e estética. Depois fazes zoom. Uma porta são todos os encaixes de madeira. Um armário pode mudar a configuração de uma sala e cozinha. O puxador pode levar a tarde toda a resolver... um zoom sem fim.

Eu sou esse tipo de arquiteto, destinado a não encontrar clientes que consigam pagar tanta hora e obsessão.

Então desisti. Não da paixão, continuo a visitar obras, a estudar, a usufruir. Mas desisti do lado comercial. Se voltar a fazer arquitetura, vai ser uma única vez: a minha casa. Sem condicionalismos. Sem ter que ceder.

Sou obcecado por produto. Gosto de ir em profundidade. Só não aplicava numa área onde isso é valorizado do outro lado.

Ganhar dinheiro é um jogo diferente. É preciso fixar o escopo de trabalho. Entender que um bom projeto de uma semana não é um bom projeto de um ano. Que tempo é decisão de investimento. E que nem tudo merece o mesmo.

Este tipo de decisão aparece todos os dias numa empresa. Normalmente escondido em tarefas.

Esta semana tive dois episódios desses. Mas desta vez usei a inteligência artificial para me ajudar a definir o escopo. Um passou. O outro foi cancelado.

Vou-te mostrar como...

Coloquei a IA a jogar contra mim.

Aconteceu na WhiteFlow, o meu investimento no desenvolvimento de soluções de IA e tecnologia para o estado. Como não temos ninguém para assumir a direção de produto, sou eu que estou com esse papel.

A quantidade de ideias, novas features, bugs, soluções, testes que se cria num software é crítica. Sobretudo, como é o nosso caso, quando usamos a solução e toda a gente tem a liberdade de sugerir melhorias.

Isto tem um lado positivo: toda a gente pode contribuir.
Mas tem um crítico: se não fechas bem o escopo, vai sair do teu bolso.

Um calendário pode demorar 1 dia a construir. Ou uma semana. Ou um mês. Continua a ser um calendário, mas as decisões que tomas para cada versão são completamente diferentes. E o preço também.

Eu já paguei o suficiente para aprender. O projeto que mais derrapou custou-me mais de 700 mil euros. Meses a dedicar a algo sem escopo definido. Das minhas primeiras aventuras na tecnologia. O tipo de erros que pagas caro quando te colocas nestas situações.

Por isso inseri uma fase antes da equipa dedicar tempo a qualquer ideia.

Existe sempre um passo de shaping.

Este passo só tem um objetivo, definir quanto é que estamos dispostos a investir (dinheiro) nesta funcionalidade. Medimos esse custo em tempo.

Mas para eu conseguir saber se vale a pena ou não, é necessário discutirmos em que é que consiste o projeto. De que tamanho é a casa? Quantos quartos tem? Qual o nível de pormenor? É para desenhar as portas? Quantas portas diferentes tem o projeto? Conseguimos reduzir?

Tudo isto são perguntas sem fim, mas fundamentais para tomar decisões. E esta semana a equipa disparou duas ideias que exigiram bastantes perguntas. Uma delas é um excelente exemplo.

Anexar documentos ao agente IA. Pegar num ficheiro e arrastar para uma conversa para servir de contexto ao que queremos que ele faça.

Até onde vai o lado humano?

A conversa começou como começam todas na equipa. Alguém abriu um cartão escreveu os primeiros requisitos.

"Vamos agora começar a usar ficheiros no Agente e temos de ter uma maneira eficaz de os mostrar ao utilizador. Para cada caso, temos de desenhar a melhor forma de os mostrar."

A equipa técnica apresentou a decisão sobre os tipos de ficheiros.

Como já existe uma cultura de shaping na empresa, a designer pegou na tarefa e foi analisar as várias soluções que existem. Claude, ChatGPT, Dia, Manus... Existe muita gente a resolver este problema, é preciso aprender. Fez o levantamento e apresentou várias ideias para discutirmos.

Uma equipa treinada chega até aqui, define e analisa antes de começar a implementar. Mas uma equipa com super poderes não se pode ficar por aqui. Uma pesquisa, por muito válida que seja, esconde muita informação que o utilizador não vê.

Primeiro esboço da implementação,

É aqui que eu entro. Eu e a IA.

Encontrar os lados cegos

Abri uma conversa no Claude e dei contexto sobre o objetivo.

"Estou a desenhar uma feature para anexar ficheiros ao prompt input do chat no WhiteFlow e estamos a desenhar o scope desta feature. Quero que me ajudes a listar pontos importantes e lados cegos que eu não estou a ver."

Copiei a conversa e colei antes de enviar. Para ele saber até que ponto é que tínhamos chegado, acompanhar os exemplos que tínhamos salientado e os requisitos iniciais da feature.

E é aqui que ele começa a brilhar. Estas são algumas das perguntas que ele fez:

Design e Apresentação
- Esse é o design do prompt input e quando são carregadas no chat? Como fica?
- Como fica em todos os tipos de ficheiros? É sempre igual?
- Qual é o Aspect ratio das previews das imagens?
- Qual é o tamanho dos thumbnails de imagem vs ícones de documento?

Estados e Interações
- Estado de upload: como é o progress bar, loading state, erro, retry?
- Remoção de ficheiros: como o utilizador remove antes de enviar?
- Hover/Preview: que informação aparece? Nome, tamanho, tipo?
- Clique no ficheiro: abre modal? Nova tab? Download direto? Nada?

Limites e Validações
- Qual é o número máximo de ficheiros por mensagem?
- E o Tamanho máximo por ficheiro?
- Tipos de ficheiros não suportados: como mostrar o erro?
- Quando o limite é atingido: toast, inline, disable do botão?

Edge Cases
- Nomes muito longos: como fica? Corta?
- Muitos ficheiros (10+): scroll horizontal? Grid? Collapse com "ver mais"?
- Ficheiro corrompido ou inacessível?

Fiz copy/paste na conversa.

A conversa silenciou durante 3 dias. Ninguém disse mais nada.

Para bom entendedor, meia palavra basta. Aquelas perguntas não tinham resposta, e eles foram atrás delas. A designer teve tempo para pensar, estudar, analisar. Quando voltou, voltou com uma solução pronta para avançar.

Fica aqui um exemplo do nível de detalhe.

Este é apenas o ponto 4 de muitos outros bem estruturados. E tudo isto acontece antes de avançar para implementação e começar a gastar dinheiro. Quando for para construir, a qualidade e robustez do resultado é incomparável ao que seria inicialmente.

No almoço de Natal tive a oportunidade de explicar à equipa o que tinha feito. Como eles também podiam usar a IA para encontrar os lados cegos antes de me apresentarem uma feature. A ideia é simples: se eu vou fazer aquelas perguntas, façam vocês primeiro. E o shaping quando eu apareço fica muito mais sólido.

Transformar isto num padrão

Esta experiência começou como um debate com o LLM. Acabou por me fazer pensar: o que seria se a IA tivesse não só o contexto da feature, como da app, das outras features, e o contexto técnico de decisões passadas?

O Claude lançou recentemente memória entre conversas dentro do mesmo projeto. Consigo passar contexto geral sobre a app nas instruções e, em cada conversa, dar o contexto específico. Ele acumula.

Podia complicar e levar isto para o meu 2brain (o projeto no Obsidian que falei há umas semanas). Mas vou manter simples. Implemento no Claude e volto para te contar como corre.

Isto é um conceito que podes aplicar a qualquer coisa.

Às tarefas que tens que executar. Aos produtos que queres lançar. Ao trabalho que queres delegar. Às apresentações que queres criar. A qualquer coisa que exija tempo e uma boa definição de scope antes de avançar.

Para não enterrares tempo que não tens.

Abraço, Luís.