Lançar software é um saco!

Escrito por Aurelio Jargas em 02/03/2012

Primeiro fiz um desabafo no Google+, mas agora eu quero registrar em detalhes, aqui no blog, o porquê lançar software é um saco.

Fazer o software é uma delícia, mas aprontá-lo para o lançamento público, seja a versão inicial ou as posteriores, é um martírio.

Como neste exato momento estou passando pelo martírio, aprontando a versão nova do MoneyLog, quero compartilhar o que acontece.

A parte divertida

Toda a diversão de ser programador acontece antes, quando você tem a ideia em sua cabeça, amadurece ela, depois codifica o primeiro protótipo funcional, e vai aprimorando até chegar no ponto que o programa está bom para o seu uso.

Neste ponto uma decisão crucial: este programa viverá para sempre aqui no meu HD ou vou colocar no GitHub pra que outros possam usar também?

Àqueles que escolhem a primeira opção, eu entendo perfeitamente, pois publicar algo decente dá, muito, muito, MUITO trabalho.

Voltemos ao MoneyLog. Desde o início do ano eu comecei a trabalhar na versão nova. Todos os dias, várias horas por dia, totalizando 255 horas de trabalho até hoje. É um trabalho voluntário, não remunerado, que faço porque quero e porque gosto.

Foi cansativo, claro. Mas eu me diverti muito no processo, resolvendo os vários desafios que pipocam a todo instante. E o resultado me deixou muito orgulhoso, há várias novidades excitantes para anunciar.

Anunciar? Epa. Agora chegou a parte chata.

A parte chata 1: adaptar para uso geral

Para mim, para o meu uso, na minha máquina, no meu navegador, o programa está perfeito. Eu não precisaria mexer em mais nada. Mas como este é um programa que eu publiquei e lanço versões novas de tempos em tempos, ele não é mais só meu.

Ele tem vários usuários, cada um com a sua máquina, o seu navegador, as suas necessidades e o seu próprio nível de conhecimento sobre o programa e sobre as tecnologias que o cercam. Eu prezo pelos usuários e quero que eles tenham a melhor experiência possível com o software.

Assim sendo, não basta o programa funcionar na minha máquina. Eu tenho que conseguir testar em várias configurações e sistemas diferentes, para encontrar os problemas antes de lançar a versão nova. Não são problemas meus, eu não serei afetado por eles, mas isso será a diferença entre uma boa ou má experiência para um usuário.

Adaptar o programa para o uso geral leva tempo, é chato, e sempre vai faltar alguma coisa. Sempre vai ter um usuário com alguma configuração obscura que vai ter problemas, mas isso você só vai saber depois do lançamento.

A parte chata 2: documentação

Mas tá. Mesmo quando eu consigo testar tudo num número suficiente de ambientes e considerar que agora sim, o código está pronto, eu não posso simplesmente chegar e dizer:

“Daí galera, terminei a versão nova do MoneyLog, baixa lá no SVN”

Imediatamente, eu seria inundado com uma série de perguntas:

• Quais as novidades?
• Como usar as novidades?
• Alguma coisa foi removida?
• Tem uma lista completa de todas as mudanças?
• Vai funcionar no meu celular?
• Tem alguma incompatibilidade com a versão anterior?
• Se tiver incompatibilidade, como faço para resolver?
• Como faço a atualização?
• Se der pau, o que faço?
• Onde é o SVN?
• SVN?
• MoneyLog? :)

Entende? Não é assim que brincadeira funciona.

Não basta lançar somente o código. O programa não é somente o código. Deve haver documentação, você deve se antecipar às dúvidas dos usuários e colocar as respostas de maneira clara, seja no README, na tela de ajuda do programa, no manual, no website, onde for.

Se você não fizer isso, tudo o que vai ganhar é uma chuva de dúvidas, que terá que responder individual e repetidamente. Isso, é claro, se você conseguir despertar algum interesse. Um programa sem website, sem uma explicação ou demonstração de uso, dificilmente chama a atenção dos potenciais usuários.

Se você costuma “lançar” software desse jeito, apenas jogando o código no GitHub e achando que isso é suficiente, pare para pensar. Você não está lançando nada, só está salvando teu código num servidor público. Na prática, isso não significa muita coisa.

Mas eu só quero programar! :(

Eu também.

Mas isso só é possível se você fizer programas apenas para uso pessoal e nunca passar para nenhuma outra pessoa.

Porém, compartilhar é algo natural para o ser humano. Você teve trabalho fazendo o programa, é normal querer que amigos e outras pessoas usem ele também. Ou talvez você queira vender seu programa.

O fato é que, a partir do momento que você decide que seu código será usado por outra pessoa fora você mesmo, um universo de novas tarefas e novos problemas será colocado no seu colo e você terá que resolver.

Neste momento você entende que “ser programador” é muito mais do que digitar códigos.

Um exemplo real

Olhe a minha situação atual, de hoje. O código do MoneyLog está pronto no SVN. Não tem mais o que polir nem o que arrumar. Está tudo funcionando como deveria.

Então o que falta para lançar logo essa versão nova?

• Escrever a lista completa de mudanças desde a versão anterior (Changelog). Vou ter que ler todas as mensagens de log, de todas as mudanças, e fazer um resumão. Sabe quantas mensagens são? 500. FEITO
• Preparar um guia sobre as novidades, com fotos, demonstrando como usar. Ou quem sabe fazer um vídeo. Tanto para usuários novos quanto para os já existentes, demonstrar as funcionalidades é a melhor maneira de apresentá-las e ensinar seu uso.
• Escrever um guia de migração para usuários da versão anterior, pois há mudanças que quebraram alguns componentes. FEITO
• Escrever um guia sobre o Dropbox, que agora será possível usar para guardar os dados. Surgirão várias dúvidas, então um FAQ especial tem que ser feito. FEITO
• Escrever um guia sobre configuração, pois aumentou bastante o número de configurações disponíveis e não há documentação sobre elas. Se o usuário não souber o que há e como usar, que sentido faz haver configuração? FEITO
• Escrever um guia sobre os quatro “sabores” que o programa vai ter a partir de agora: Cloud, Browser, Portable, Beta. O usuário vai ficar confuso tendo que escolher uma versão para usar, então devo me antecipar e tornar essa decisão mais fácil. FEITO
• Atualizar o FAQ. As várias mudanças tornaram alguns itens obsoletos, outros ficaram mais simples e talvez alguns não funcionem mais. Preciso conferir um por um.
• Atualizar o website do programa. Ou melhor dizendo, refazer o website. Há muitas novidades, tenho que dar destaque para elas, e o site velho não vai encaixar. Também preciso “apresentar” o programa para quem não conhece. Serão muitos textos e screenshots novos, reestruturação de URLs, vai dar trabalho.
• Pescar o nome de todos que ajudaram a fazer essa versão, com código, com palpites e testes e fazer uma lista de agradecimento. Terei que vasculhar no Changelog, histórico do twitter, meu email e minhas anotações.
• Atualizar o arquivo PAD do programa, para que sites de download sejam notificados que há uma versão nova.
• Preparar as versões em inglês do programa e atualizar o minissite gringo.
• Escrever o texto de anúncio da versão nova, que será publicado aqui no blog, falando sobre os principais destaques e novidades. Uma vez publicado este texto, posso considerar a versão nova oficialmente lançada.

Essas são as tarefas maiores, que eu lembrei agora. Ainda tem as minitarefas tipo mudar o número de versão no código, gerar a versão final, marcar a tag no SVN, conferir links, anunciar no twitter, responder dúvidas pós-anúncio, entre outras.

Bem, mas é isso. Agora preciso voltar ao trabalho e dar um jeito nessa lista de tarefas, senão esse MoneyLog v5 não vai sair nunca :)