Autonomia & Tecnologia

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

33

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
  • Pingback: Guia básico de inteligência emocional para criativos – DEEP()

  • Quando você desenha um gráfico de Gantt está planejando a fantasia.

  • Luiz Henrique

    Muito legal mesmo essa abordagem. A figura onde mostra a evolução do produto, redução de escopo, sempre focando em resolver a dor do cliente cada vez melhor, é sensacional. Muito bom !!!!

  • Luiz Henrique

    Muito legal mesmo essa abordagem. A figura onde mostra a evolução do produto, redução de escopo, sempre focando em resolver a dor do cliente cada vez melhor, é sensacional. Muito bom !!!!

    • Legal que vc curtiu, @disqus_BPMnUUDuVs:disqus! Essa abordagem faz toda a diferença e permite que nós da área técnica deixemos de ser encarados como custo para atuar ativamente como investimento.

  • Marcus Gabaldo

    É um prazer participar do WTTD nos moldes em que o @henriquebastos:disqus propõe. Se há 8 meses atrás eu me deparasse com um tópico como “Funcionalidades são bugs, até que se prove o contrário” eu provavelmente mudaria de página. Quando fiz a inscrição para o curso, achei que aprenderia a programar, mas não foi bem assim. Eu estou aprendendo a programar, é claro que com a ajuda de todos aqui, mas esse não é o ponto. A programação é somente uma das ferramentas para uma solução, repare: uma das ferramentas.
    O “muito além da programação” ou o “foco no valor” são conceitos que, hoje, pra mim faz todo o sentido. Eu estou vivendo isso.
    O Henrique consegue envolver o pessoal nesse processo complexo, porém simples. Obrigado a vocês, Henrique (meu amigo) e a todos que sempre estiveram dispostos a me ajudar nesse nessa jornada.

    • É um grande prazer fazer parte da sua jornada, meu amigo!

  • Pedro Cesar

    Uma dúvida: Nesse curso tem só python pra web ou geral? É que estou querendo desenvolver um sistema que tem parte web e se comunicando com um agente de rede que deve ficar instalado computadores enviando informações. Esse curso cobre isso?? Grato

    • Falaê, @disqus_R5ePmBZCRY:disqus! Sim, a gente explora Python no geral também. Não tem como fazer Python na web sem saber Python no geral. 😉

  • “Pre-optimization is the root of all evil”
    Grande Gabaldo…pudemos ver durante o curso a evolução dele e ele absorvendo todos os insights que a galera dava!!! Realmente inspirador!!!

  • Abelardo

    O desenvolvedor deve se envolver com que “nível de dor do cliente”?
    Se o cliente tem um problema de negócio, já desenhou uma solução de negócio e precisa de sistemas para dar suporte a essa solução: o desenvolvedor é responsável apenas por implementar os sistemas que darão suporte à solução traçada pelo cliente, ou é responsável, também, por analisar o problema, a nível de negócio, traçar uma solução de negócio(operacional, estratégica?) e então desenvolver os sistemas de suporte?
    Acho que os métodos ágeis geram um meio termo: no lugar de o negócio encontrar uma solução e levar para a TI desenvolver, cria-se um processo iterativo, de rápido feedback, onde a solução de negócio evolui com a solução de TI(e daí, para lidar com a ausência inicia da solução finalizada, a necessidade de ser ágil, reagir rapidamente a mudanças de requisitos).

    • “a solução de negócio evolui com a solução de TI” é uma grande frase. É assim que tem que ser. Afinal o negócio e a TI estão SEMPRE em constante evolução. São leis que mudam, regras que se tornam obsoletas, processos de negócios que são otimizados e assim por diante. Temos que mudar o mindset antigo de que PRIMEIRO tínhamos que mapear TUDO para só assim começar a construir o software. É um processo de desconstrução que leva tempo mas é recompensador e o WTTD ajuda e MUITO nisso!!!

  • Cadu De Castro Alves

    Fantástica a história do Marcus. Por coincidência, estou relendo o livro Lean Startup e hoje li justamente o capítulo que fala disso. Como dev experiente, é muito desafiador me desapegar de entregar um projeto com milhares de funcionalidades, quando o que importa é resolver a dor do cliente.

    Espero que o Marcus leve essa experiência pra vida, porque com esse mindset, ele vai bem longe.

    • Show de bola, @cadudecastroalves:disqus! Sim, é sempre um desafio questionarmos nossos pressupostos 🙂

  • Alcione Morais

    Muito boa história só comprava o poder do Python e Django e mais a
    força de vontade do Marcus.

  • Luiz Filipe Cesar

    Parabéns ao Marcos, WTTD e a comunidade. A história é muito inspiradora!

  • Clevertom Fernandes Guimarães

    Interessante esse artigo e também a história de sucesso.
    Estou trabalhando em um projeto desde o ano passado, ou seja, 1 ano, e depois de conversar com o cliente, e ver quais suas maiores necessidades, a modelagem inicial que tinha feito atendia uns 30% das reais necessidades dele.
    Retrabalhei a ideia, modelando conforme esse me disse, quando fui validar com outros clientes esses comprovaram as sugestões do primeiro, então desenvolvi um protótipo, um MVP e quando levei ao cliente, ele adorou a ideia, mas as funcionalidades estavam fora da sua realidade, então ele me disse, “Quero que sua agenda seja igual a do papel”.
    Hoje estou reformulando toda a ideia baseado no Scrum, que (ainda não lí) vai de encontro a chamada para o outro artigo, a entrega de valor, e depois que a gente entrega aqueles 60% do valor de negócio do CLIENTE, talvez os outros 40% nem sejam necessários.

  • Clevertom Fernandes Guimarães

    Interessante esse artigo e também a história de sucesso.
    Estou trabalhando em um projeto desde o ano passado, ou seja, 1 ano, e depois de conversar com o cliente, e ver quais suas maiores necessidades, a modelagem inicial que tinha feito atendia uns 30% das reais necessidades dele.
    Retrabalhei a ideia, modelando conforme esse me disse, quando fui validar com outros clientes esses comprovaram as sugestões do primeiro, então desenvolvi um protótipo, um MVP e quando levei ao cliente, ele adorou a ideia, mas as funcionalidades estavam fora da sua realidade, então ele me disse, “Quero que sua agenda seja igual a do papel”.
    Hoje estou reformulando toda a ideia baseado no Scrum, que (ainda não lí) vai de encontro a chamada para o outro artigo, a entrega de valor, e depois que a gente entrega aqueles 60% do valor de negócio do CLIENTE, talvez os outros 40% nem sejam necessários.

    • Massa d+, @clevertomfernandesguimares:disqus! Quando a gente corrige esse rumo fica tudo bem mais simples. Seria bem legal se vc escrevesse um post no seu blog ou no medium mesmo contando em detalhes esse seu processo. Acho que vai ajudar muita gente. Depois bota o link aqui. 😉

  • Agora eu me lembrei fortemente do #TestFirst

  • Agora eu me lembrei fortemente do #TestFirst

  • Felipe Rodrigues

    Já tinha visto esse vídeo do Marcus e achado bem interessante. Acho que é isso, temos que focar no mais importante.

    Aguardo a abertura das inscrições. Parabéns pela iniciativo WTTD e também pro Marcus!

    • Valeu msm, @disqus_30spxoWFaj:disqus! Eu ainda vou parar pra fazer um papo com o Marcus revisitando todas as mensagens que trocamos no fórum. Acho que vai ser interessante. 🙂

  • Esse insight é sensacional Henrique. Também acredito que o abismo entre a expectativa do cliente e o resultado que muitas vezes entregamos se deve à essa tentativa de tentarmos antecipar todas as suas “necessidades ocultas”. Acredito que a simplicidade das soluções e o foco no “essencial” (do ponto de vista do cliente) é o caminho para diminuir esse abismo. Aguardando ansiosamente pela próxima turma to WTTD. 🙂

    • Exatamente, @tiagoprnl:disqus! É um problemão quando a gente se preocupa tanto sem se preparar para “o que um dia vamos precisar” e esquecemos “do que precisamos hoje”. Vai ser massa ter vc na turma! 🙂

  • Gustavo Coelho

    Texto excelente. O parágrafo sobre a Epifânia > Excel > Project > GANTT conseguiu resgatar com clareza as lembranças de projetos caóticos e sem resultado implementados por antigos clientes. É realmente assim: focam em funcionalidades “legais” e deixam a dor central em segundo plano.
    Valeu, Henrique! #autonomia

    • Show de bola @disqus_VXRWgi7o4l:disqus! É incrível como isso acontece ainda hj. Muito desperdício de energia, tempo e $.

      • Acontece demais!! Estou prestando consultoria para um cliente GIGANTE e é impressionante o quanto eles PERDEM tempo com PROCESSOS ao invés de focarem na solução. É e-mail pra cá, e-mail pra lá e nada de resolverem o problema….

  • O trecho “nos perdemos quando confundimos confiança com certeza” seria cômico, se não fosse trágico; já que ao acharmos que temos certeza, acabamos tomando um monte de decisões em nome do cliente, a maioria delas equivocada.

    A expressão “o cliente quis assim” virou meme na firma, e é usada a cada prejuízo (tempo, dinheiro, paciência e etc) computado.

    • Exatamente, @rbraga:disqus! E quando a gente para pra refletir nessa tragédia, ela se traduz em horas, dias, semanas que os profissionais se dedicam a correr atrás do rabo e não podem ficar com suas famílias, ou ter um tempo de lazer.

  • Marcos Ribeiro

    Muito boa essa abordagem, foco no valor ! E a história do Gabaldo é inspiradora.