Orçando um clone da Netflix e a importância das softskills

Estou meio atrasado na discussão, mas decidi escrever este artigo após ler um tweet sobre o tema à tarde. Um outro júnior enfrentando o mesmo desafio. Retomo essa discussão para demonstrar como as softskills importam e, no fim, são elas que separam os sêniors de qualquer outro estágio.

Primeiro que é surreal qualquer pessoa pedir para um único dev produzir um clone da Netflix. Mas, esse é o tipo de solicitação corriqueira para profissionais freelancers e independentes. Não vou entrar nos méritos das complexidades técnicas e apenas destaco que ninguém faz uma Netflix sozinho, contudo alguém faz uma Netflix.

O que quero dizer é que, em geral, não existe sistema impossível. E se a própria Netflix fosse impossível, ela mesmo não existiria. A questão é que sistemas complexos levam tempo, consomem dinheiro e exigem recursos. Porém, embora ninguém faça uma Neflix sozinho, certamente alguém consegue iniciar uma N..e..t..f..l..i..x..

Essa quantidade de pontos é proposital para demonstrar que você pode iniciar pelo "N" e algum momento chegar no "X". Tem até nome para isso: mínimo produto viável. E é aqui que chega o ponto mais importante da discussão: a ausência das softskills.

Quando um profissional chega ao ponto de perguntar para outros profissionais como orçar um projeto desse, certamente tem pouca experiência com desenvolvimento na prática. Mas, mais ainda, pouco sabe sobre "briefing" e gerenciamento de expectativas e essa é, sem dúvidas, a parte mais importante da negociação.

Acredito que uma das situações mais difíceis de lidar como profissional iniciante é ter o domínio da situação. Aqui entram inúmeras softskills que só o tempo tem a ensinar, então tudo que posso fazer é sintetizar. A primeira coisa básica que ser feita é questionar o cliente com um belo "por que?" (não dessa forma, claro).

Quando alguém está buscando por um clone da Netflix, na maioria das vezes (falo por experiência própria), a pessoa não está buscando por um clone da Netflix. Ela está querendo algo que está nas entrelinhas. Bons profissionais vão investigar isso. Vão procurar desvendar esse grande mistério.

É extremamente complexo colocar em palavras como esse movimento acontece e aqui que voltamos no "por que?". Não há melhor forma de começar sem ser perguntando. Insistindo profundamente nas perguntas e aprimorando elas. Se eu pudesse dar um exemplo, seria algo como:

— [dev] Me diga, por que a Netflix é uma inspiração para esse projeto?
— Poxa, eu acho que eles são uma empresa fantástica. É muito fácil mexer na interface, encontrar um vídeo e dar play. Não tenho que pensar muito, é só clicar.
— [dev] Então além da interface, você gosta de como a Netflix mostra as sugestões de filmes e séries?
— Com certeza, acho que a Netflix conhece mais a mim do que eu mesmo.
— [dev] E como você visualiza essa aplicação em sua plataforma de cursos?
— Ah... eu quero que seja fácil para o aluno ver os cursos e que novos cursos sejam sugeridos para ele com base no que ele está cursando, além de ter uma interface parecida para que ele saiba usar a plataforma!
— [dev] Compreendo, e você tem muitos cursos para oferecer no momento?
— No momento não, mas pretendo começar a montar uma base de cursos assim que o sistema tiver no ar.
— [dev] Entendo perfeitamente! Você concorda que a interface da Netflix dá um enorme destaque a "quantidade"? Não falta conteúdo, é uma interface bem preenchida de vídeos.
— Sim, é verdade...
— [dev] Se você, por exemplo, iniciasse essa plataforma com poucos conteúdos, muito provavelmente a mesma interface passaria uma sensação de vazio enorme para os alunos e todo o potêncial das suas aulas seria despediçado...
— E como poderiamos resolver isso?
— [dev] Bom, acredito que possamos nos inspirar na usabilidade da Netflix e até em um sistema de recomendação mais enxuto, mas ao mesmo tempo priorizar outras coisas que deem mais destaque aos seus cursos e sejam compatível com um lançamento mais rápido...

Essa é uma conversa boba e totalmente simulada, mas na maioria das vezes a sensação é exatamente como construir uma teia de aranha. De fio em fio, você forma um emaranhado complexo de soluções. Depois de entender muito bem o que o cliente de fato está buscando, você passa a mediar a conversa para expectativas mais realistas.

Esse o ponto chave do processo. Quando começamos a pontar para o cliente que na fase inicial (onde haverá pouco conteúdo), teremos poucos usuários de entrada e precisamos de um sistema enxuto para garantir um ambiente sustentável, sem gastar rios de dinheiro desnecessário com infra-estrutura e, depois, incrementar feature por feature conforme o negócio for crescendo.

O seu objetivo é entender o bastante para criar argumentos sólidos para vender um MVP. MVP qualquer um pode fazer (alguns mais do que outros), mas em geral o MVP consegue ser entregue em um tempo ideal, consegue operar o negócio e consegue suportar o crescimento. Eu já fechei contratos de 6 dígitos apenas mediando e vendendo o MVP do projeto.

No fim, o cliente quer mesmo é vender, "pagar seus boletos", e essa é a sua melhor arma. Pagar os boletos com menos é o maior atrativo para qualquer cliente sã, do contrário nem vale a pena investir no cliente. Você entregar uma operação mínima vale muito mais do que focar em toda a complexidade do sistema e mergulhar em um mar de frustração por um orçamento totalmente incompatível com os desafios.

O MVP, ainda, por ser menor permite que o orçamento seja melhor dimensionado. Mas até chegar nessa solução, a única pessoa que você precisa convencer é o seu cliente. Convencer a ele que a melhor opção é colocar esse sistema o quanto antes para rodar para que ele comece a faturar, contudo para isso precisam focar no que realmente é importante (um produto mínimo) e depois crescer a altura do negócio.

Vamos ser sinceros, programador não sabe vender. E, infelizmente, quando você é um freelancer independente, você precisa saber vender. Vender não é apenas fechar um contrato a qualquer custo, mas sim mediar aquele cliente para que sua real entrega faça todo o sentido para ele. É como achar aquela peça faltando no quebra-cabeça. Quase ninguém ensina isso no mercado da programação.

Para fechar, tenho um ótimo livro para indicar e ajudar a quem precisa desenvolver melhor essas softskills: "Briefing: A Gestão do Projeto de Design por Peter L. Phillips". Sim, é sobre design. Mas, design é sobre tudo. Tudo que é planejado, arquitetado e solucionado.

E uma das melhores lições que aprendi com esse livro é certamente que existem dois tipos de profissionais, separados por suas softskills, os taxistas e os consultores de viagem. Os taxistas pegam um destino, batem a corrida, deixam o passageiro e seguem para o próximo. Os consultores entendem seu destino, traçam a sua rota, entregam uma experiência personalizada e mediam suas expectativas.

Não se cobre entretanto, caso você seja júnior. Essas softskills vem com o tempo, mas quanto antes você começar a treinar melhor. Provavelmente, suas primeiras abordagens serão ruins e isto é absolutamente normal. Esteja atento a como você pode melhorar na próxima.

Mas, pelo amor de Deus, nunca mais (NUNCA MAIS) orce sem entender de verdade o que o cliente está buscando e medie as expectativas para aquilo que você é capaz de entregar. Uma Netflix? Você não é capaz de entregar. Um protótipo de uma plataforma de cursos sob demanda que utiliza o Vimeo como base para streaming? Com certeza você é.

As vezes acreditamos que os clientes são exagerados demais, contudo a maioria deles apenas não sabe expressar o que de fato querem e soluções alternativas, mais simples e mais baratas, no início podem agradar com muito mais facilidade do que outras.

PS.1: Uma recomendação final, se o cliente ainda insistir que um clone da Netflix é a solução para ele... destaque os custos envolvidos para manter esse tipo de arquitetura e, certamente, ele dará todos os passos para trás que você quiser.

PS.2: E se o cliente ainda insistir que encontrará outro profissional para fazer, então... deixe-o ir, mas não sem antes destacar como um profissional que aceitar esse tipo de projeto provavelmente irá entregar algo muito abaixo de esperado e possivelmente o cercará de diversos atrasos. Focar o quanto você é realista com os prazos, faz muita diferença. MVP costumam ser lançados entre 3 a 6 meses e, dependendo, as vezes menos. Uma vez estava trabalhand com um MVP que tinha lá suas complexidades, a solução foi explodir o sistema em pequenas features e entregar por semana. Ao ver as entregas acontecendo, por mais que o sistema não tivesse pronto para ir no ar, despertava uma sensação de conquista no cliente.

PS.3: Conduza os seus clientes, quem determina o destino é você. Crie confiança suficiente para impor limites claros. Esse tipo de atitude até filtra clientes. Os bons clientes levam muito a sério profissionais que sabem gerir os limites, os mantem atualizados e realizam entregas constantes por menores que sejam.