Matem o formato CSV

Se você trabalha com dados já deve ter usado um arquvo CSV. Quase todo programa tem alguma forma de importar ou exportar dados nesse formato, quase como se fosse um padrão.

O arquivo CSV é só um arquivo de texto, em que cada linha contém dados de um registro e cada campo de um registro em uma linha é separado por um caracter separador.

"Nome","Instrumento"
"John Lennon","Guitarra"
"Paul McCartney","Baixo"
"Ringo Stars","Bateria"
"George Harrison","Guitarra"

O formato tem muitas vantagens que o tornaram popular desde os primeiros softwares de planilha eletrônica. É tão simples que um ser humano consegue ler e escrever um CSV usando um editor de texto simples. É fácil de implementar e por isso todo sistema tem alguma forma de importar e exportar dados nesse formato.

Mas é um formato que fazia mais sentido quando não existiam redes e por isso não se trocavam tantos arquivos entre computadores diferentes, sistemas operacionais diferentes e softwares diferentes com configurações regionais diferentes. O arquivo CSV di jeito que existe hoje devia morrer de velho ou ser sacrificado, se isso fosse possível.

O maior problema do formato CSV é a forma como ele lida com encodings. Ele não lida. O programa que lê o arquivo precisa adivinhar o encoding em que os dados foram gravados e às vezes não acertam.

Isso significa que às vezes você vai mandar um arquivo CSV para alguém, ele vai tentar abrir no programa dele e todos os caracteres com acento vão virar um monte de lixo. Ele vai dizer que a culpa é sua de mandar um arquivo corrompido.

Alguns softwares vão abrir em um encoding padrão e se seus dados ficarem todos enfeitados com caracteres ilegíveis, problema seu. Quem mandou você não converter o encoding do arquivo para o encoding usado pelo software. Mas como você ia adivinhar que encoding é esse, se  isso não for uma configuração explícita.

Outro problema é que o caracter usado para separar os dados de registro não precisa ser uma vírgula, como o nome do formato implica (CSV = comma separated values = valores separados por vírgula). Aqui no Brasil mesmo, muitos programas usam o ponto-e-vírgula ao invés da vírgula como padrão.

Mas não existe uma forma de indicar no conteúdo do arquivo qual caracter está sendo usado como separador. Você simplesmente usa o separador que escolher e se ele não for o padrão, na hora de abrir o arquivo em algum programa, reza para que exista alguma forma de escolher qual caracter você usou como separador. Senão vai ter que arrumar uma forma de mudar os separadores do arquivo.

No caso do Windows, o separador padrão para um arquivo CSV é uma configuração regional do sistema. Se se seu amigo canadense te envia um arquivo que ele gerou no Windows dele e tem vírgulas como separadores, talvez você vai ter um trabalho extra para abrir o arquivo em seu sistema operacional com configurações regionais do Brasil e ponto-e-vírgula como separador. E nem todo software vai usar a configuração do sistema.

Você pode ter lido isso tudo e achado que é um problema bobo, fácil de resolver. Basta que a pessoa que vai abrir o arquivo fique responsável por configurar o software que vai abrir o arquivo com o encoding correto e o separador utilizado. Mas essa solução só mostra como esse formato tem um problema grave de usabilidade. Você nunca precisa checar o conteúdo bruto e configurar um software antes de abrir um XML ou um DOC. Esses passos adicionais tomam tempo e aumentam as chances de erro e corrupção de dados.

O software poderia ser responsável por tentar detectar o encoding e o separador. Mas detecção de encoding pode falhar. Detecção do separador também. O que pode gerar corrupção de dados sem que o usuário perceba.

Esses problemas poderiam ser evitados se o formato tivesse sido formalmente padronizado décadas atrás. Existe um documento  que define que o separador deveria ser sempre a vírgula, mas como sabemos isso já não é obedecido. Além disso o documento não se preocupa com o problema de encoding. Mesmo que se preocupasse, já existem tanto software que geram arquivos CSV no formato livre atual, que para fazer alguma diferença, um padrão deveria ter um novo nome e de alguma forma ser adotado em massa pela indústria.

Por conta da longevidade e abrangência da adoção do formato CSV, nós somos reféns dos problemas desses arquivos, obrigados a implementar sistemas que continuem processando esse formato só porque outros sistemas se sentiram na obrigação de dar suporte a CSV, como num círculo vicioso.

Equipes de tecnologia odeiam gerentes não técnicos

Ao conhecer uma pessoa, o profissional de tecnologia começa a classificar: esse pessoa é técnica ou não? Ela já teve que configurar um banco de dados ou uma fila de mensageria? Ela sabe como usar criptografia? Ela consegue entender a arquitetura de um sistema olhando para um diagrama? O quanto ela entende de tecnologia?

Isso não acontece porque técnicos se consideram uma casta diferente que só se relaciona com pessoas da mesma turma. O problema todo se resume à comunicação. Se você precisa explicar algo para uma pessoa que também é técnica, pode levar em conta que ela já sabe conhece algumas informações básicas, e isso torna a explicação mais fácil. E isso torna o trabalho do técnico mais fácil.

Outro problema são as expectativas mágicas que os leigos têm em relação aos técnicos. Por não saber como as coisas funcionam, tentam imaginar como devem funcionar. Por isso na hora de explicar um problema técnico que está tendo, pessoas não técnicas tentam explicar de uma forma que talvez não vá fazer muito sentido para o técnico. Pode ser uma reclamação de que um documento importante sumiu, fazendo o pessoal do CPD perder tempo recuperando o arquivo do backup quando na verdade a janela do Word estava só minimizada.

Por isso, uma situação que cria muita insatisfação é quando o gerente de uma equipe de tecnologia não é uma pessoa com perfil técnico. Normalmente alguém que está no cargo porque tem experiência em gerir pessoas, projetos, clientes. E para muitas empresas, essa estratégia parece natural, já que funciona com outras áreas da empresa, em que os especialistas são os membros da equipe e o gestor só coordena e cobra. Por que a equipe de TI seria especial?

O problema de comunicação entre técnicos e não-técnicos afeta o dia a dia da relação com o gerente. O gerente da equipe é uma das pessoas com que o profissiona de tecnologia mais vai ter que interagir. Se ele não for técnico, você tem esse desgaste a mais de energia tentando explicar conceitos básicos, preparando uma aula só para passar um status do andamento de um projeto.

Dependendo do gerente, suas expectativas mágicas podem causar muito stress para a equipe, principalmente quando ele é responsável por estabelecer os prazos. Para o gerente não-técnico, uma mudança no sistema pode parecer trivial, algo que vai tomar algumas horas. Mas olhando com mais cuidado, um técnico pode detectar que isso vai exigir mudanças grandes que podem tomar meses. E se o gerente não tiver como renegociar esse prazo (ou simplesmente quiser mostrar serviço para seus superiores), a equipe é quem paga o pato de trabalhar fora do horário de serviço para entregar o que foi pedido.

Nem toda empresa pode ou consegue achar alguém com o perfil de gerente técnico. É possível fazer uma equipe técnica e um gerente não-técnico funcionarem juntos, mas é mais difícil. Esse gestor precisa ter humildade e facilidade para aprender um pouco sobre a tecnologia usada por sua equipe, não necessariamente entendendo os detalhes de quem bota a mão na massa, mas o suficiente para entender uma conversa sobre o assunto. Também é importante ter confiança com a equipe, pedindo dos profissionais feedback quando o lado técnico afetar seu trabalho.

Algo que pode ajudar é utilizar a cultura de equipes autogerenciadas, muito difundida na comunidade de métodos ágeis. Nesse caso, o gerente funcionaria mais como um facilitador.

De qualquer forma, ter um gerente técnico pode ajudar muito na hora de contratar novos membros para sua equipe. Na hora da seleção o gerente vai saber o que realmente importa na prática, enquanto o candidato pode se sentir mais motivado de saber que vai trabalhar com alguém que entende o lado dele.

Vale a pena fazer o curso de machine learning do Coursera?

As plataformas de cursos online surgiram nos últimos anos para realizar o sonho de muita gente: poder assistir aulas formuladas pelas melhores universidades do mundo sem precisar sair de casa, enquanto come um Doritos e veste apenas uma cueca. Esse não era meu sonho, mas resolvi que deveria experimentar esse conteúdo pelo menos pela experiência.

Aprendizado de máquina é um assunto que me interessa, por isso resolvi me matricular neste curso gratuito do Coursera. Já havia estudado o assunto antes por conta própria através de livros e até usado um pouco da teoria na prática. Além de poder aprender mais algumas coisas e solidificar o que já tinha visto, essa foi a chance de conhecer e avaliar um conteúdo didático criado em Stanford. É o equivalente para um amante de café ter a chance de experimentar de graça aquele café que é considerado um dos melhores do mundo, feito com grãos retirados das fezes de um roedor que não lembro o nome.

Antes de saber se você deveria fazer este curso é uma boa ideia ter uma noção do que é aprendizado de máquina. E acho que a melhor forma de motivar alguém a conhecer melhor o assunto, é ter uma noção de suas aplicações práticas. Usando machine learning você pode criar software que reconhece objetos em imagens, detecta fraudes em operações financeiras, dirige um automóvel ou drone, avalia o crédito de pessoas, avalia a probabilidade de um paciente ter uma doença, prevê que um servidor pode sofrer uma falha, e muitas outras coisas que parecem mágica. Mas conhecendo melhor sobre o assunto você vai ver que essa lista que fiz é bem limitada.

Depois de se interessar pelo curso, sua preocupação pode ser em saber se você precisa ser um campeão de olimpíada de matemática para conseguir acompanhar o curso. Este é um assunto que usa muita matemática, mas o curso foi pensado para alunos que pelo menos consigam ler uma fórmula com somatórias, matriz e vetores. Existem até aulas opcionais com álgebra linear básica para ajudar com os conceitos que vão ser usados durante as aulas. E graças ao professor Andrew Ng, as aulas são muito didáticas a ponto de ele fazer todos os passos de cálculos necessários nos exemplos. Em casos em que seria necessário um conhecimento matemático maior, o professor dá uma explicação sobre a intuição do que está sendo feito, mas não é exigido que o aluno saiba resolver uma derivada ou decompor uma matriz, por exemplo. Mas minha opinião é que tendo uma base mais do que básica sobre cálculo e álgebra linear vai tornar o conteúdo muito mais fácil de assimilar e entender, sem deixar que alguns passos nos algoritmos pareçam ter aparecido por mágica.

Saber programar é um pré-requisito. Os projetos a entregar são programas escritos em Matlab ou Octave. Mas não é necessário conhecer uma dessas linguagens, pois algumas das aulas vão te ensinar o necessário para realizar todas as tarefas. Eu mesmo nunca havia usado essas linguagens. Apesar de não ser muito difícil de aprender, muitas vezes perdi muito tempo por detalhes da linguagem que causavam erros nas minhas tarefas. Mas o fato de que você só precisar programar o principal das tarefas, com o código que cuida de preparar os dados e mostrar resultados já pronto, facilitou e economizou muito meu tempo, considerando que é um curso que muita gente vai fazer no tempo livre. E o sistema de envio das tarefas com correção automática funciona muito bem. Você resolve cada passo do exercício, envia para o sistema e ele te diz se você acertou ou não.

Um ponto muito positivo é que todo o conteúdo, por ser ensinado pela mesma pessoa, tenta seguir mais ou menos a mesma notação do começo ao fim. Isso ajuda muito para comparar os algoritmos. Quando você tenta aprender cada uma dessas coisas por fontes diferentes, você acaba vendo notações diferentes que dependem da preferência do autor. É como tentar entender uma história que teve uma parte contada por uma pessoa e o final contada por outra, mas a que contou o final só se refere aos envolvidos por apelidos que você não conhecia.

O melhor do curso para mim são as ferramentas que ele ensina para que você entenda se sua solução de machine learning está funcionando bem, e o que você pode fazer para melhorá-la. É esse o conhecimento que eu esperaria de alguém que fosse usar esses algoritmos na prática.

Vejo poucos pontos negativos, que são pequenos perto das qualidades do curso. Algo que me incomoda um pouco são as questões que aparecem no meio dos videos. Muitas vezes eles nem estão testando se você entendeu a teoria que está sendo ensinada, mas verificando se você está acordado e prestou atenção na notação que o professor acabou de usar. Outra coisa que me fez falta, que se deve mais ao formato, é não ter um material que possa consultar facilmente depois. É impraticável procurar no meio dos videos algo que você não lembra direito onde viu, por isso recomendo anotar principalmente as dicas que são baseadas na experiência do professor Andrew.

Talvez algumas pessoas possam se sentir incomodadas pela falta de formalidade técnica que o assunto é tratado, mas considerando que aprendizado de máquina é uma área em que os métodos funcionam mesmo sem os matemáticos entenderem muito bem, acho que o conteúdo habilita alguém a se tornar um praticante. Um conhecimento mais formal seria necessário apenas para quem deseja se tornar um pesquisador na áreae nesse caso este curso funcione bem como uma introdução geral.

Por tudo isso digo que vale muito a pena fazer o curso de machine learning oferecido pela Universidade de Stanford pelo Coursera. Valeria a pena mesmo se fosse pago, sendo grátis eu tenho a vontade de visitar meus amigos programadores e obrigá-los a assistir essas aulas.

Negócios que qualquer programador poderia criar

Depois que o Bill Gates se tornou rico e a profissão de programador se tornou mais conhecida, existe uma expectativa de que pessoas com a habilidade de escrever softwares se tornem empreendedores. Existem incubadoras e investidores nos Estados Unidos que só investem em empresas que têm desenvolvedores em seu time de fundadores. E nos churrascos de família seus parentes estão sempre olhando para você e se perguntando porque você ainda não criou o próximo Facebook.

man-791505_640

“Quando você ficar rico lembra que eu te dei a maior linguiça rs.”

E muitos deles pensam em seguir esse caminho, mas esbarram na desculpa da falta de ideias. Eles olham para o que o Google faz e sentem que não tem capacidade técnica suficiente ou que vão precisar de muita ajuda para construir algo. Ou olham para sistemas que as empresas compram como ERPs, CRMs, sistemas de RH e não entendem os problemas que esses produtos resolvem, e por isso não sabem como poderiam criar algo assim.

Mas um programador não precisa ter PHD em Stanford ou ter sócios que entendem de um domínio muito específico de negócio para criar um produto e começar uma empresa. Existem problemas que já estão a seu alcance, e pessoas dispostas a pagar para resolver esses problemas.

Para ilustrar vou dar exemplos de algumas empresas que começaram com produtos que são tecnicamente muito fáceis de construir. Ideias tão simples que provavelmente já passaram pela cabeça de muito programador, mas que por acharem que era simples demais também devem ter pensado que não teriam como lucrar com elas. Ideias que quando você vê funcionando como empresas, fica se perguntando como não pensou nisso antes (mesmo já tendo pensado nisso).

Buffer

A Buffer é uma ferramenta que posta atualizações em suas redes sociais em horários agendados ou calculados. Sua empresa pode usar a ferramenta para divulgar um link em todas as suas redes sociais sem ter o trabalho de entrar em cada site e postar o conteúdo no horário certo.

O básico desse serviço pode ser feito por um script que execute no horário certo (usando um job de cron por exemplo) e faça chamadas de API para disparar a postagem do conteúdo. E na verdade, foi assim que eles começaram.

Hoje a Buffer tem receita de mais de U$ 600 mil/mês, com pelo menos 46 mil clientes, de acordo com seu dashboard aberto na Baremetrics.

StatusPage

A StatusPage fornece um site onde uma empresa que tem serviços online pode mostrar informações sobre o status de seus serviços, e fornecer atualizações a seus usuários sobre os problemas que estão afetando sua disponibilidade. Por exemplo, o Kickstarter usa o StatusPage para atualizar seus clientes sobre o progresso de alguma correção no site caso ele saia do ar por problemas técnicos.

O serviço deles é basicamente um site, algo que poderia ser feito por alguém que não sabe programar. Bastaria saber configurar um CMS. É um serviço tecnicamente fácil de fornecer.

Mas os clientes da StatusPage vêem valor no que eles oferecem. A última vez que a StatusPage divulgou números de sua receita foi em janeiro de 2014, quando atingiram U$ 25mil/mês.

StoreMapper

A StoreMapper fornece uma busca de lojas físicas para que um comércio que tenha vários endereços ou fábrica que fornece produtos para várias lojas permitam que um cliente encontre um endereço onde pode fazer a compra usando seu site.

Criar algo assim poderia ser muito complexo, a não ser que você fizesse como a StoreMapper e usasse a API do Google Maps para exibir os resultados. Isso torna a implementação do serviço muito mais fácil.

Atualmente a StoreMapper tem 889 clientes e receita de U$ 15 mil/mês, de acordo com seu dashboard aberto no BareMetrics.

A sua ideia

Que fique claro que não estou dizendo que é fácil criar uma empresa. O básico de cada exemplo que listei pode ser implementado por qualquer programador, mas é claro que com o tempo esses empreendedores foram melhorando o produto para que ele forneça muito mais valor a seus clientes. Além disso, o sucesso de uma empresa não depende só da parte técnica.

O que quero dizer é que boas ideias para negócios podem vir de problemas que estão a seu redor e que podem ter soluções simples que estão ao seu alcance.

O desafio do software simples de gerenciamento de projetos

Todas as pessoas têm projetos. Desde o casal planejando o casamento, passando pelo designer criando um novo site para um restaurante até uma empresa que vai construir uma nova turbina. E é por isso que existem tantos softwares nessa categoria.

Castelo de areia

Projeto Castelo de Areia 3. Os outros tiveram problema de scheduling e budget.

Mas projetos têm diferenças em escala e natureza, e variam demais dependendo de quem os executa ou em que área se aplicam. Por isso existem, dentro da categoria de softwares de gestão de projetos, diversos subtipos. Existem sistemas para quem quer aplicar tudo o que aprenderam em um curso certificado internacionalmente de gestão de projetos e existem os mais simples e genéricos que ajudam grupos menores a se organizar.

Os sistemas mais complexos normalmente têm uma única forma certa de serem usados. Seguem as práticas do PMBOK e outras técnicas mais específicas ensinadas em cursos de MBA ao redor do mundo. São ferramentas vendidas aos CIOs que querem aplicar essa teoria que aprenderam. A maioria dos usuários não tem muita opção, são forçados a usar o sistema que o chefe do chefe deles escolheu.

Para capturar o mercado que esses sistemas complexos ignoram, surgiram muitas ferramentas mais simples para gerenciamento de projetos. A maioria deles parece com uma lista de tarefas suplementada com recursos para facilitar a colaboração com outras pessoas. É o mundo das pessoas que só precisam saber o que precisa ser feito e o que foi feito. Pessoas que normalmente não gostam ou não sabem usar um gráfico de Gantt.

Esses softwares mais simples têm como mercado alvo principal empresas menores, profissionais liberais ou até grupos ou indivíduos sem ligação com uma entidade com fins lucrativos. Por isso são mais baratos, às vezes até de graça.

Exemplos desses sistemas mais simples: Basecamp, Asana, Flow e Runrun.it.

Diferente dos sistemas mais complexos, esses softwares costumam ser adotados pela equipe, não forçados como uma decisão hierárquica para toda a organização. Mas isso, combinado com seu preço baixo e a natureza simples de suas interfaces, pode ser uma faca de dois gumes.

Hoje em dia todo software vendido pela internet tem a palavra “simples” ou “fácil” no texto de seu marketing. A ideia é que empresas menores não querem comprar algo que vá exigir treinamento, querem uma ferramenta que um leigo vá bater o olho e intuitivamente possa usar, ou algo bem próximo disso. Todos esses sistemas de gerenciamento são vendidos assim.

Existem infinitas maneiras de se organizar para conduzir um projeto. E projetos, dependendo de sua natureza, podem exigir peculiaridades para que tenham esse tipo de controle. Essas ferramentas optaram por simplicidade para oferecer flexibilidade, para que possam ser usadas na maior variedade de projetos possíveis. Mas existe uma linha tênue entre ser simples e ser genérico demais.

Algumas pessoas vão olhar para esses softwares e achar que são genéricos demais, que não fornecem estrutura ao trabalho suficiente para auxiliar o andamento de um projeto. Eles dependem de disciplina de quem vai usá-los. O sistemas mais complexos são impostos, os mais simples precisam lutar para que a equipe não tenha um motivo para trocar para outra ferramenta do mesmo tipo, já que seu custo não vai ser muito diferente.

E o maior desafio é que eles dependem da disciplina da maioria dos membros da equipe. Se alguns membros não alimentam o sistema da forma como a equipe espera que o façam, o sistema se torna inútil. A adoção sempre fica limitada ao limite da paciência dos membros menos organizados e disciplinados. Esses membros poderiam ser ejetados da equipe, mas isso nem sempre é possível e o custo de experimentar outra ferramenta é sempre menor.

Isso criou a figura do “chato do Basecamp” ou “polícia do Asana”, ou qualquer coisa equivalente para sua ferramenta. É a pessoa que precisa cobrar os outros membros para que eles usem corretamente o software.

No final, mesmo sendo genéricos, essas ferramentas acabam tendo formas mais otimizadas de serem utilizadas de acordo com a forma como foi montada a experiência de usuário. Mas a maioria das pessoas é resistente a ideia de mudar a forma como gosta de trabalhar só para se adequar ao fluxo de uma ferramenta que eles nem sabem se vai lhes dar algum retorno. Por isso essas ferramentas tentam não fazer o que os softwares maiores e mais complexos fazem que é vender uma solução casada com uma metodologia fechada.

Esses desafios abrem espaço no mercado para ferramentas que sejam construídas com nichos mais específicos desde sua concepção.

Já usei várias dessas ferramentas em diversos projetos e não pode dizer que as acho ruins. Só que o fato de que elas são intercambiáveis, alguém poderia ter escolhido outro software da mesma categoria e o projeto teria o mesmo resultado, mostra que ainda não temos uma ferramenta definitiva. Não temos o Microsoft Office ou Google da gestão de projetos.

E talvez isso seja impossível pela diversidade de formas de se trabalhar, ou precise realmente ser fragmentado para formas otimizadas para cada tipo de projeto que precisem ser vendidas junto da ferramenta, ou ainda, pensar em como construir uma solução que atenda bem até as pessoas que não querem usá-la mas fazem parte do projeto. Enquanto isso, eu continuo na minha busca pelo software perfeito para mim.

Sua Liderança Molda a Cultura De Sua Empresa (E Não O Fliperama Na Sala De Recreação)

Escrevi um post no blog da Arivo que achei que seria relevante postar aqui. Não se aplica apenas a TI, mas muitas do que escrevi foi baseado no que eu vejo na área.

Aqui está o link:

https://arivo.com.br/blog/blog/2013/11/21/sua-lideranca-molda-a-cultura-de-sua-empresa-e-nao-o-fliperama-na-sala-de-recreacao/

1 ano de startup: lições aprendidas

Imagem

Faz 1 ano que eu e meu sócio colocamos no ar o Arivo, um sistema de CRM para pequenas e médias empresas. Não gosto muito de chamar a empresa de startup, porque isso faz as pessoas lembrarem do filme do Facebook e de empresas que recebem investimento de milhões e escritórios com máquinas de sorvetes, e nós não temos e nem fomos atrás dessas coisas. Mas acho que temos ingredientes o suficiente para poder usar essa palavra para nos definir.

Acho que sempre que dedicamos tempo a algo, o mais importante é poder dizer que conseguimos aprender algo. E é por isso que achei importante fazer este balanço do que aprendi neste ano. Além disso, quem sabe isto possa ser útil para algum outro desenvolvedor que também esteja pensando em criar sua própria empresa, colocar seu próprio aplicativo no ar, ter seu próprio produto.

Procurar resolver um problema mais claro

Nós tivemos algumas razões para escolher um CRM como produto, mas acho que da próxima vez que lançar um produto vou tentar levar em consideração a questão ‘qual problema queremos resolver?’ ao invés de ‘qual produto lançar?’.

Não estou dizendo que um CRM não resolve um problema. Mas esse tipo de sistema apesar de muito útil para uma empresa, não necessariamente é considerado algo que uma empresa PRECISA ter. Isso significa que menos pessoas estão procurando por isso. E como CRM é um conceito mais dfundido em empresas maiores, oferecer este serviço para pequenas empresas significa que você precisa educar algumas pessoas sobre o conceito.

Some isso ao fato de que CRM é uma das primeiras coisas que as pessoas pensam em fazer quando querem lançar um SaaS. Quando lançamos vimos que existiam alguns produtos no mercado, mas não parecia ser um número tão alarmante quanto se vê na internet em inglês. Mas hoje em dia, cada vez que eu pisco o olho aparecem dois novos CRMs para pequenas empresas. Concorrência é algo saudável, mas quando ela é muito numerosa isso pode causar efeitos ruins para todos, como o achatamento dos preços.

E se eu acho tão problemático um CRM, porque não desistir e fazer outra coisa? Uma das razões eu cito em um dos parágrafos abaixo. Mas também porque já investimos tempo e dinheiro nisto e uma das partes mais difíceis já passou. Além disso, pela experiência de várias empresas de SaaS que esse é um negócio que leva bastante tempo para engrenar. Acho que temos hoje um produto sólido. Mas com certeza quero no futuro lançar outros produtos.

Não faça tudo que seus clientes pedem

Alguns de seus usuários vão perguntar sobre alguma funcionalidade que seu software não tem. Talvez você ainda não tenha implementado a funcionalidade porque não teve tempo, mas na maioria das vezes eles vão perguntar de algo que você nem pensou em fazer. Você, como desenvolvedor, vai sentir que deve implementar isso, que pode garantir mais um cliente pagando, mais uma grana entrando por mês para você poder gastar em games.

Mas a verdade é que esses usuários pedindo por funcionalidades não estão tão investidos assim em seu produto. A maioria das vezes em que cedi e implementei uma funcionalidade específica, o usuário que pediu não se tornou um cliente pago. E depois quase ninguém usou aquela funcionalidade.

Existem duas alternativas melhores para este caso. Uma delas é esperar até que mais usuários peçam pela mesma funcionalidade. Se ela for tão importante assim, mais gente vai pedir por ela. E a segunda é usar o bom senso e tentar chegar em uma versão da funcionalidade que possa ser útil para mais usuários. Talvez essa versão não atenda 100% da necessidade desse usuário que pediu pela funcionalidade, mas se for boa o suficiente para a maioria que precisar dela, ótimo.

Isso parece óbvio, mas quando você acha que vai coseguir fechar mais uma venda para sua empresa escrevendo algumas linhas de código você fica muito tentado a ceder.

Não aposte tudo em uma funcionalidade

Acredito que quem lança um produto na internet conheça vários casos de sucesso e tenha estudado as estratégias que essas empresas usaram para chegar onde estão. Parece simples, parece fácil. É só imitar algumas dessas estratégias, e ir arrumando um espaço para guardar a pilha de dinheiro que vai chegar quando sua empresa bater o Google e a Apple em faturamento.

Ou você tem uma ótima idéia de algo que seu software pode fazer, que vai ser tão legal que seus usuários vão sair na rua contando para todo mundo, tatuar em seus corpos sobre seu software e você vai se tornar um dos maiores casos de marketing viral da história.

Infelizmente, nada é tão fácil. As estratégias das empresas famosas deram certo por conta de vários outros fatores, como networking, timing e um pouco de sorte (e talvez um bocado de dinheiro). A sua ideia fantástica talvez não seja tão fantástica para os outros, ou talvez seja, mas as pessoas não estão espalhando sua mensagem.

Não aposte tudo em sorte. Experimente, implemente essas funcionalidades que podem dar certo e tornar sua empresa um grande sucesso. Mas não conte com isso. Tenha um plano A, B, C, que sejam mais realistas.

Desenvolvimento é a parte mais fácil

Como desenvolvedor, programar é a parte mais fácil do trabalho simplesmente porque você tem mais experiência, foi treinado nisso. Mas além disso, desenvolver um sistema é uma atividade muito mais objetiva que a maioria das outras coisas que você pode fazer por sua empresa, como marketing, vendas, atendimento aos clientes, etc.

Você sabe se conseguiu entregar uma funcionalidade nova ou corrigiu um bug e sabe quanto tempo mais ou menos essas atividades vão tomar. Mas escrever o texto de sua home page, acertar o SEO, enviar e-mails para usuários, são algumas das coisas que você faz e não sabe muito bem se o resultado é bom o suficiente ou se vale a pena gastar um pouco mais de tempo. E talvez mesmo investindo muito tempo, no final o resultado que você esperava pode não ser alcançado.

Por isso é importante ter um roadmap das funcionalidades mais importantes de seu software para que você possa pelo menos entregar essas funcionalidades e ter tempo para fazer outras atividades necessárias. E ter outras pessoas em quem você confia na empresa para dividir e delegar o trabalho também ajuda bastante.

A satisfação de ter seu próprio produto

Acho que o melhor de lançar um produto é sentir um reconhecimento maior do que em outros tipos de trabalho como desenvolvedor. Ver pessoas usando e pagando por algo que você não só codificou, mas que você ajudou a transformar em produto, participando diretamente nas decisões, é muito gratificante.

Você pode desenvolver softwares sobre medida para clientes que te paguem para isso, mas mesmo que seu cliente goste muito do resultado e pague direitinho, você não sente que o sistema qu você fez saiu de suas mãos. Você se sente como uma ferramenta. Se você trabalha em uma grande empresa, desenvolvendo um produto, você não sente que está fazendo tanta diferença, porque existe muita gente envolvida. Muito provavelmente você nem participa das decisões de produto.

Algumas lições mais técnicas

Sobre as principais ferramentas que utilizei:

Ruby on Rails: este framework e a linguagem Ruby me permitem não só criar sistemas muito rápido, mas alterá-los e mantê-los. Já tinha experiência prévia com Rails, por isso não cheguei nem a cogitar outro framework para este projeto.

AngularJS: por muito tempo não utilizei nenhum framework para Javascript. Estudei um pouco dos mais conhecidos e resolvi utilizar o AngularJS neste projeto. Ele me permite fazer algumas coisas bem complexas de forma relativamente simples. Mas de vez em quando algumas coisas que deveriam ser simples são bem complicadas de se fazer, exigindo que você conheça bem como o Angular funciona para conseguir implementar. Ele também é um pouco lento em alguns browsers, como algumas versões mais antigas de IE. Gostei bastante do AngularJS, mas não sei se usaria em um próximo projeto. Acho que ainda não surgiu um framework javascript maduro e simples para ser a escolha definitiva para este tipo de ferramenta.

Bootstrap: anteriormente conhecido como Twitter Bootstrap. Muito útil, me facilitou demais na hora de construir interfaces e páginas. Recomendo para quem não é muito bom em design.

Por enquanto esta é minha avaliação do último ano. Espero aprender mais coisas e talvez até descobrir que estava errado em algo que disse neste post. E quem sabe escrever as lições aprendidas em 2 anos, 5 anos, 10 anos, lições aprendidas escolhendo minha ilha particular comprada graças ao sucesso de minha empresa. E compartilhar o que aprender com outras pessoas, para quem sabe elas possam comprar suas ilhas também :)