O erro de começar pela solução quando criamos software · luizmellodev

Nós desenvolvedores sempre temos ideias inovadoras e geniais. Ideias que quebram padrão, que mudam o jogo, que ninguém nunca fez antes. Isso é ótimo e faz parte da área. Ou você não teve isso ainda? Vai me dizer que nunca pensou "Essa ideia vai me deixar milionário!"??

Mas existe um ponto que eu demorei pra entender: nem sempre o foco tem que ser sobre criar algo nunca feito antes. Demorei pra me tocar que muitos softwares famosos já existiam antes. O que mudou não foi a ideia, foi o foco do problema.

Sou desenvolvedor iOS e várias vezes já pensei “queria fazer um app de Y”. Logo depois vinha a dúvida clássica: “por que alguém baixaria o meu se já existem milhões iguais?”. Essa pergunta sempre me travava.

Até que comecei a estudar dois conceitos que mudaram minha forma de pensar produto:

inovação incremental
Challenge Based Learning (CBL, que vi durante o programa Apple Developer Academy).

Inovação incremental é um conceito antigo em estratégia de produto. Em vez de tentar criar uma ideia nova, o foco passa ser em melhorar algo que já existe usando contexto real, limitações práticas e experiência direta do usuário. Não é reinventar a roda, é ajustar a roda para um cenário específico.

Já o CBL, usado pela Apple em contextos educacionais e de desenvolvimento, parte de outra lógica: você não começa pela solução. Você começa pelo problema. Primeiro define o problema concreto, depois investiga o contexto, e só então pensa na implementação. Em vez de perguntar “qual app eu vou criar?”, você passa a perguntar “qual problema real eu quero resolver?”.

Isso ajuda bastante a sair da mentalidade de precisar criar algo revolucionário o tempo todo.

O mais engraçado desse post é que enquanto eu fazia o rascunho, eu percebi que esse conceito de inovaçao incremental acontece quase que diariamente por devs que postam aqui no TabNews, e talvez eles nem saibam desse conceito. Quer ver alguns exemplos?

O moyseys criou um gerenciador de senha pessoal. Não porque o mundo precisava de mais um, mas porque ele queria algo sob controle dele.

O crawfy criou o Cloka porque não queria depender da nuvem para rastrear tempo. Ferramentas já existiam, mas não do jeito que ele precisava.

E o JAugusto42 criou um scanner SCA porque os existentes eram lentos, cheios de ruído e falsos positivos, o que atrapalhava a priorização dos times. O problema não era ausência de ferramenta, era a qualidade da experiência.

Em todos esses casos o ponto de partida foi um problema real, não uma busca por algo novo, invoador que nunca tivesse sido feito.

Parando de falar dos outros e falando de mim, há um tempo atrás eu resolvi criar um app do TabNews, pra mim. O objetivo dele era bem simples: eu queria receber notificações quando saísse newsletter. Só isso. Nada de glamour ou inovações. Eu não queria ficar abrindo meu email toda hora mas também não queria ter que ir atrás da newsletter. Escrevendo isso me dei conta que sou um usuário chato... Enfim, queria que ela viesse até mim, mas não por email. Essa era minha dor, extremamente específica, né? Mas como dev, a ideia de programar algo por dias/semanas pra resolver um problema super pequeno é muito encantadora!!! kkkkkk

Depois de implementar o MVP do app, com notificações de newsletter funcionando através de cloud functions e cronjob, percebi: “Perfeito! Já está pronto. Por que não lançar? O trabalho já foi feito, vai que alguém queira esse app também”.

Mas aí veio a pergunta de sempre: “mas por que alguém baixaria isso se o site já existe e ainda não ocupa espaço de armazenamento no iPhone?”.

Foi aí que percebi que estava olhando pra isso do jeito errado. A questão não era se o app era inovador. Era se ele resolvia uma necessidade real, mesmo que pequena.

Desde então, antes de começar qualquer projeto novo, tenho tentado passar por algo assim:
1. Qual é o incômodo/problema real?
2. Em que situação isso acontece?
3. Será que outras pessoas sentem essa dor além de mim?
4. Que soluções já existem e o que exatamente elas resolvem ou deixam de resolver?
5. Dá pra resolver isso de forma mais simples ou mais direta?

Só depois disso eu penso em stack, design, features e etc.

Na maioria das vezes isso leva a um projeto pequeno, bem específico, que resolve um recorte do problema, a famosa validação com MVP. E é justamente isso que inovação incremental costuma ser: ajustes locais em problemas reais, não reinvenção completa de produto.

No fim das contas, o erro não costuma estar em criar algo que já existe. O erro costuma estar em começar pela solução sem entender direito o problema.

Vocês tem o hábito de criar projeto pensando só na feature/ideia ou vocês pensam pela dor também?

Se alguém quiser compartilhar exemplos de apps, libs ou ferramentas que nasceram de uma necessidade própria, acho que rende uma discussão boa aqui!

Momento jabá: Pra quem tá curioso sobre o app,o link tá aqui embaixo. Sou dev iOS, entao fiz uma versão iOS apenas, hehehe.

Nele eu adiconei widgets, uma versão pra apple watch, sistema de notificações, weeky e daily digest sobre os posts relevantes, sistema de pastas, TTS (text-to-speech), anotações, sistema pra "grifar/marcar" textos de um post e algumas outras coisas. Dá uma chance, vai que você goste!

Link: https://apps.apple.com/us/app/tabnews-reader/id6755933359?l=pt-BR

Além do TabNews Reader, tenho outros apps, mas o Muda Plant se destaca por justamente ser um app que usa inovação incremental. Eu vi um problema, e resolvi atacar com uma pequena solução. Tá curioso? veja meu outro post!!

Referências massas pra aprender mais:

CBL -
https://medium.com/zeroeumas/cbl-challenge-based-learning-497580ff29d
https://developeracademy.ifce.edu.br/cbl/index.html

Inovaçãoo incremental -
https://masschallenge.org/articles/incremental-innovation
https://graduate.northeastern.edu/knowledge-hub/what-is-incremental-innovation
https://en.wikipedia.org/wiki/Disruptive_innovation

Olá, boa noite. Adorei seu post, e faz muito sentido. Vou começar o curso de ADS agora, me formei em TI recentemente no IFMS, e sempre gosto de fazer projetos pessoais que resolvam problemas meus ou projetos apenas para estudar e praticar.
Por mais que eu seja jovem e não tenha entrado no mercado de trabalho ainda, posso dizer alguns casos que pensei de uma maneira parecida, mesmo sem saber dos conceitos.
Finalizei hoje um app para android que é basicamente um sistema de registro de vendas para facilitar a vida dos vendedores dos eventos das igrejas da minha cidade, pois eles faziam esses registros em uma planilha. Criei um app com uma interface bonitinha e organizada, que permite que eles registrem os eventos, os produtos, as vendas + uma tela de estatísticas para apresentar as informações a partir dos dados.
Outro caso é um software que eu inclusive divulguei aqui no TabNews, que é o TaleArchitect. Ele é um app desktop para auxiliar em worldbuilding para escritores e mestres de RPG (principalmente). Eu quis desenvolver esse app para me auxiliar a organizar os eventos de um livro que estou escrevendo ao mesmo tempo que eu estudava e explorava conceitos novos na área de programação. Se você quiser saber mais sobre esse projeto você pode olhar no meu perfil.
Valeu pelo post amigo! Realmente apresenta uma visão válida e que toca no ponto principal da profissão de dev: resolver problemas. Não é sobre ser inovador, mas sobre resolver um problema real!