Esse texto é antigo, mas eu precisava deixar passar um tempo para acabar não expondo ninguém. A ideia é compartilhar meus tropeços — para que, quem sabe, assim, quem ler não tropeça igual! Escrevo no presente, mas essa história aconteceu há alguns anos já.

O resumo pode ser lido como todo mundo vê as pingas que eu tomo, ninguém vê os tombos que eu levo. Então quero mesmo é falar desses erros — mais deles do que de como acabei contornando a situação na pressão, com água na bunda, ao melhor estilo se vira nos 30… vamos lá. Senta que lá vem textão!

Erro 1: misturar estudo, aprendizado, curiosidade

Aparece um freela aqui. Coisa que não faço: aplicativo para celular. Mas estudar uma biblioteca X em que eu escrevo código em uma linguagem, e ela transforma em código nativo de aplicação para celular, estava na minha lista de coisas para estudar.

O aplicativo que apareceu como proposta de freela era bem simples e tive uma ideia genial (spoiler: não era genial de verdade):

— Vou pegar esse trampo, me puxo a estudar a biblioteca X e ainda ganho uma grana!

Deu ruim. Logo logo vocês entenderão o porquê, com mais detalhes. Mas o resumo é que estudar leva tempo, e se estimar tempo de projeto com escopo de projeto já é difícil, o risco de errar essa estimativa contando que tens que aprender algo novo é muito grande.

Erro 2: matei minha autonomia

Claro que não era só essa loucura: eu disse pra mim mesmo que só pegaria esse freela se achasse alguém que já tivesse feito algo com a biblioteca X viesse junto. Achei um cara na comunidade, ele topou. Lindo.

Mas… Deu ruim outra vez: esse cara me deu um balão, foi viajar e me deixou na mão. Tudo bem, imprevistos acontecem, erros acontecem, etc. Mas me coloquei em uma situação em que eu era extremamente dependente dele. Quando ele sumiu, fiquei na mão — o que queria dizer que deixei a cliente na mão.

Poderia achar outra pessoas para a parceria no freela, claro… mas aí vem o próximo erro.

Erro 3: matei minha autonomia II, o retorno

Eu estava trabalhando com duas tecnologias muito insipientes. A linguagem em que eu escreveria o código para a biblioteca X já era até grandinha, mas era considerada beta ainda. A biblioteca X em si era alpha ainda — ou pior, experimental, prova de conceito.

O gargalo tecnológico de usar coisas ainda não avançadas, imaturas, não era o problema em si: a ideia era mesmo pegar uma ferramenta nova, em desenvolvimento e com ela desenvolver não só o meu projeto, mas melhorias para essa ferramenta. O gargalo era que existe pouca gente, pouco material, pouca comunidade.

Deu ruim. Quando o cara com alguma experiência me deixou na mão, com pouquíssimas pessoas desenvolvendo nessa linguagem, com biblioteca X, com essas habilidades, não consegui achar outra pessoa. Mais: quando a tecnologia é super nova assim, meu aprendizado foi mega lento pois não tem documentação, não tem StackOverflow, não tem praticamente nada além do código fonte e de um canal no Slack com uma média de 5 mensagens por semana.

Erro 4: ignorar a Lei de Murphy

Bom… quando algo pode errado, (provavelmente) vai dar. E no meio disso tudo muita coisa deu errado: uma pessoa próxima teve que fazer um cirurgia (e, claro, fiquei cuidando dela), tive problemas burocráticos com meu visto e com minha matrícula na universidade (problemas burocráticos desses que consomem tempo pra xuxu), com isso me atrasei com outras coisas que eram mais prioridades que o meu freela (outros projetos de tecnologia, meu doutorado, etc.), meu cachorro ficou doente (precisava levantar ele de 2h em 2h para ajudar ele ir lá fora fazer as necessidades dele, e mais um monte de cuidados extras) etc…

Enfim, minha vida exigiu mais de mim. Normal também… mas junto com os erros 1, 2 e 3… ferrou o freela. Eu me doei pouco ao projeto. Com isso não mantive a cliente por perto e assim cheguei numa situação insustentável.

Sentindo o cheirinho

Há quatro dias da entrega (o prazo total era entre 2 e 3 semanas), eu já tinha levado um balão do meu parceiro de freela, e nas últimas 24h estava me puxando a aprender a biblioteca X sozinho para suprir a lacuna que o cara que me deu balão deixou. Foi quando caiu a ficha de que não conseguiria. Mesmo trabalhando x horas por dia, madruga à fora, não daria.

Sentia um peso nas costas gigante: falhei, me queimei com a cliente. Descumpri minha palavra. É estranho pois eu normalmente daria uma desdenhada na urgência da coisa (claro, não era urgente). Mas me incomodava ter quebrado o laço de confiança que aquele cliente tinha comigo.

Começando a pensar num plano B: conversar

Bateu a dura realidade. Ferrou. Nessas horas que além da comunidade lembro das amizades. Em menos de 15min mandei mensagem para três amigos pedindo 10min de conversa. Pessoas próximas, gente de confiança e com experiência em projetos de tecnologia para me dar uma luz.

Eu estava traçando um plano B: abandonar aquela linguagem de programação e aquela biblioteca X (não aprenderia tudo aquilo tudo sozinho, em tempo), iria para uma solução mais tradicional para projetos como esse no mercado. Teria que ter uma conversa dura com a cliente. Não sabia ainda o que eu podia cogitar, pensar, planejar — e queria trocar uma ideia com essas pessoas para ter um choque de realidade, para ver o que mais eu poderia estar pensando e não estava. Queria conversar também sobre como tentar preservar um pouco da confiança que a cliente poderia ter em mim.

De uma dessas pessoas ouvi algumas coisas que já sabia (não era urgente mesmo), levei uns puxões de orelha por me sobrecarregar demais, ela reforçou algo que eu já faria (que era falar com uma das outras duas amizades que eu já havia procurado). Com a base budista que compartilhamos, essa conversa me ajudou a aceitar meus erros, tirar um pouco o peso do ombro: não que o problema não existisse, mas resolver a treta toda com um saco de areia nas costas era mais difícil do que só resolver a treta toda. Então olhei pra trás, vi mais claramente as merdas que havia feito, fiz notas mentais para tentar não repeti-las e bola pra frente. Metade dos erros descritos aqui, foi nessa conversa que comecei a ver com mais clareza — sem esse papo não conseguiria falar desses erros pois ainda estaria tudo meio nebuloso.

O outro papo foi bem mais pragmático: por que o prazo é 4 dias a contar de hoje? o que que a cliente vai fazer com esse aplicativo no 5º dia? e trocentas perguntas que eu não conseguiria articular de forma tão direta e clara. Levei mais puxões de orelha: burrada pegar projeto para aprender uma tecnologia, burrada ir para uma tecnologia sem comunidade (“não uso Django porque é a melhor ferramenta, uso Django pois tem uma porrada de gente usando” essa pessoa me disse). Isso tudo também ajudou a ver meus erros de forma mais clara, menos nebulosa. Mas o principal mesmo foi encontrar nesse papo as perguntas certas para, em um momento em que eu temia perder a confiança da cliente, conseguir entender melhor o contexto do projeto e — ao contrário do que eu esperava — trazer a cliente para perto (ou seja, mesmo com meus erros, reforçar a confiança).

A terceira conversa foi ainda mais pragmática: a pessoa embarcou no projeto, vamos fazer essa parada, bora. Ok, não foi bem assim. Mas falei dos meus erros, a pessoa curtiu o escopo do aplicativo e resolveu entrar no projeto para entregar isso comigo.

Arrumando a casa: conversar mais

Bom, eu estava mais calmo, via uma saída: não ia entregar no prazo — isso era um fato. Mas teria que — além de mudar a linguagem de programação e ferramentas tecnológicas — entender da cliente o que ele precisava no prazo (e o porquê), priorizar coisas, combinar um esquema de entregas contínuas etc.

Liguei para a cliente, pedi desculpas, assumi a culpa por desandar tudo. E disse o que eu (ainda) via como solução: em 4 dias entregar um mínimo, ir pegando críticas, comentários e evoluindo o projeto em mais uns dias ou semana até que o escopo inicial fosse coberto.

Dei sorte: a cliente foi compreensiva. Não ficou feliz, claro. Mas tudo bem, entendeu que erros acontecem. O principal foi que ela reconheceu meu esforço em, mesmo com o projeto ruindo, querer entregar valor, querer ouvir o lado dela, alinhar o que entregar — minimizar o prejuízo, talvez.

Sentando a bunda na cadeira e trabalhando

Dias corridos para mim, para a nova parceria no desenvolvimento do projeto. Nos quatro dias úteis (mais um final de semana) conseguimos um mínimo de funções que davam uma amostra da experiência do que seria o aplicativo. Já havia compartilhado o acesso ao aplicativo e ao painel de controle, e marquei um papo para ir lá pessoalmente pegar os primeiros comentários e combinar os próximos passos — tudo isso desse novo esquema de entregas contínuas e proximidade com a cliente.

Finalmente boas notícias!

Graças ao ótimo trabalho dessa nova parceria, a cliente adorou o pouco que viu naquela reunião.

Mais: ela adorou a história de entregas contínuas. Disse que fica muito melhor discutir assuntos técnicos (onde guardar preferências de usuário, como saber se a pessoa está autenticada, como tratar ou formatar tal informação) dessa forma — falar do escopo quando tudo tá no papel é abstrato, assim, com algo em mãos, mesmo que ainda inicial, as necessidades (aparentemente) técnicas fazem sentido para eles também.

E disse que gostou muito da minha sinceridade: prefiro alguém sincero, erros acontecem, a gente erra aqui também — mas o importante é entregar.

Próximos passos

O projeto continuo e foi entregue completo, com sucesso. Ainda teve uma extensão para a página web. Mas o foco aqui é outro, são os erros e as lições. Pode parecer arrogância, mas não é: acertamos em fazer essa primeira entrega, mesmo entregando, sei la, 30% do aplicativo no dia em que o combinado era entregar 100%. A cliente sente que estamos interessados nas dores delas e que estamos juntos para a vida dela ser mais fácil.

A cliente em questão é uma intermediária, e o cliente final do projeto é o cliente dela na verdade. Senti hoje que essa intermediária nos vê como um time se esforçando para que ela entregue um aplicativo de qualidade para a cliente dela: e ela sentiu que é isso que estamos fazendo (mesmo fora do prazo).

Nessa reunião que descrevi, traçamos prioridades concebíveis para os próximos 3 dias e fomos implementando o que falta. Ganhamos tempo, pois entregamos uma espécie de protótipo para ela testar e validar antes cobrir o escopo todo. Com isso todas as outras entregas foram mais certeiras.

Acho que era isso que tinha para compartilhar. Espero que essa sequência de erros aí ajude alguém a fugir de umas ciladas. E espero que esse exemplo de resgate da cliente (de conseguir trazer a cliente pra perto quando o que eu esperava mesmo era tomar umas pedradas) ajude mais gente a alinhar as coisas antes, não deixar chegar no gargalo que chegar.