Autonomia & Tecnologia

Funcionalidades são bugs, até que se prove o contrário

Programar é uma atividade cara. Descobrir que a funcionalidade que você programou não precisava existir é mais caro ainda. Por isso é muito importante programar apenas o que realmente importa.

No artigo anterior eu falei sobre como focar no valor. Não deixe de ler. Ficou bem legal e vai te ajudar a tirar melhor proveito deste artigo.

No processo de desenvolvimento, conforme aprofundamos nossas investigações sobre as dores do cliente, vamos aprendendo mais sobre o problema que precisamos resolver.

Quando ganhamos confiança sobre nossa compreensão do problema, é muito comum darmos um salto desastroso rumo a otimização precoce do trabalho.

No instante em que começamos a imaginar a solução, começamos a listar todas as funcionalidades que julgamos necessárias. Enquanto fazemos isso, começamos a perceber que uma funcionalidade influencia a outra, e começamos a planejar uma ordem mais eficiente de implementação das funcionalidades.

O caos disfarçado de epifania vai tomando forma até que alguém abre um Excel para montar uma matriz de dependências das funcionalidades. E a cereja chega ao bolo quando uma alma ingênua abre o Microsoft Project para quebrar as funcionalidades em tarefas e desenhar um gráfico Gantt para ordenar a execução e estimar o tempo do projeto.

É a tempestade perfeita. Tem tudo para dar errado!

Esse problema é tão comum que existe até uma lei sobre esse efeito cancerígeno das funcionalidades.

Jamie Zawinski, um dos criadores do Netscape Navigator que começou como um browser até virar uma massaroca de funcionalidades com a capacidade de ler e enviar e-mails, disse:

“Todo programa expande até que se torne capaz de ler e-mails”.

— Lei de Zawinski

Mas onde será que a gente se perde nesse processo? Nos perdemos quando confundimos confiança com certeza. Assim a gente esquece que desenvolvimento de software tem riscos e que aprenderemos mais e mais sobre o problema durante todo o processo, não apenas no início.

Para evitar que isso aconteça, é preciso reduzir o escopo da solução.

Reduzir escopo é uma das estratégias que acho mais importante. Reduzir escopo não é deixar algo incompleto, mas fazer o que realmente importa de forma simples para reduzir o custo do que se faz e antecipar a entrega do valor do seu trabalho.

Quando você reduz o escopo e foca em entregar valor, o desenvolvimento torna-se o processo pelo qual você resolve a dor do cliente cada vez melhor.

Foi o domínio da estratégia de reduzir escopo que viabilizou a experiência incrível que o meu amigo Marcus Gabaldo viveu no Welcome to the Django.

No meio do curso, enquanto o Marcus ainda aprendia a programar indo muito além da programação, ele vendeu seu primeiro projeto de software.

Logo que ele prospectou o cliente, ele me enviou um e-mail com o assunto: Socorro. No e-mail ele explicava que tinha iniciado as conversas com o síndico do seu prédio para substituir um sistema que não o atendia.

Como foi sua primeira iniciativa, o e-mail continha uma lista de funcionalidades.

Interagindo no fórum com toda a turma, o Marcus deixou a lista de funcionalidades de lado e se lançou a resolver a principal dor do cliente. Desde o início o sistema já tinha um visual bonitão e simples usando o Bootstrap. Mas não tinha login e permissões, por exemplo. A sensação de segurança era dada por uma senha hardcoded, afinal o sistema só tinha um usuário até o momento. A primeira versão foi feita em poucas horas integrando recursos disponíveis na nuvem, mas já resolvendo a dor do cliente.

mvp

Com essa primeira versão, foi possível validar as hipóteses que se tinha sobre o entendimento dos reais problemas do cliente. Essa validação abriu espaço para as próximas iterações onde o problema foi resolvido cada vez melhor.

A velocidade de execução que ele ganhou ao reduzir o escopo e focar no valor, surpreendeu o síndico, o conselho administrativo e o próprio Marcus. Isso aumentou a confiança de todos no processo de entrega de soluções aos problemas reais, em vez de entrega de funcionalidades ou demandas.

Mais pra frente esse aumento de confiança foi determinante para o acordo comercial, para a negociação do preço e os demais detalhes do fechamento do negócio que planejamos conjuntamente no fórum do Welcome to the Django.

A trajetória do Marcus inspirou toda a nossa comunidade e abriu a porta para várias iniciativas de outros alunos que tomaram conta do fórum. Foi incrível ver tanta gente fazendo, torcendo e ajudando como podia.

Foi sensacional presenciar o sonho do Marcus se manifestando ao longo da jornada. Principalmente para alguém que ainda estava aprendendo ao programar enquanto fazia o curso. Sem dúvidas foi uma grande demonstração de como ir muito além da programação.

https://youtube.com/watch?v=y3CUXVQoNtc%3Fshowinfo%3D0

Curtiu? Deixe o seu comentário!

Acompanhe as novidades da nova turma inscrevendo seu e-mail no site do Welcome to the Django.

[]’s, HB!

você pode gostar também
Comentários