Da mesma forma que um jogador de futebol quer pôr em prática nos jogos aquilo que aprende ao longo dos treinos, também o típico estudante de informática tem a vontade de mostrar que é capaz de pôr o conhecimento que adquiriu ao longo dos anos em prática. Eu não sou exceção.

Esta é a história de como (mais) um projeto para os tempos livres ficou pelo caminho. Os ingleses gostam de lhe chamar Post-mortem.

A Ideia

Como é normal, todo este projeto começa por uma ideia. Por mais simples que ela seja, a ideia é o ponto de partida para o brainstorming e, portanto, ter a ideia clara e concisa é essencial para a conseguir transmitir a outras pessoas.

A ideia não necessita de ser original, mas deve acrescentar valor a soluções já existentes, até porque ter uma ideia original não é, obviamente, fácil. Mas nem esse foi o objetivo inicial. O objetivo inicial sempre foi construir algo que pudesse pôr em prática os conhecimentos aprendidos ao longo dos anos. E isso significa que este projeto não nasceu de uma ideia, mas, ao contrário, a ideia nasceu da necessidade de desenvolver um projeto.

Usando uma metáfora da biologia, tal como Lamark explicava que determinados caracteres eram adquiridos por necessidade, também a ideia para este projeto surgiu pela necessidade de ter haver uma ideia para se poder desenvolver um projeto. E começar um projeto sem uma ideia é como marcar um casamento sem primeiro saber a opinião do parceiro: é bem provável que esteja destinado ao fracasso.

Terminando a metáfora: a ideia deve aparecer, assim como Darwin explicou para a biologia através da seleção natural, de uma forma natural e espotânea. A ideia pode aparecer enquanto falamos com um amigo (foi assim que surgiu este blog), enquanto utilizamos um determinado serviço e nos deparamos com a falta da funcionalidade X ou quando damos por nós a pensar a mítica frase “era tão fixe se aqui se pudesse fazer X” (não esqueci que muitas das ideias aparecem enquanto relaxamos a tomar banho, as chamadas shower thoughts).

A Visão

Ter uma ideia é o primeiro passo, mas para a partir da ideia se conseguir construir uma visão, simples e concisa, é necessário conseguir delinear o âmbito (scope) do nosso projeto.

Se a ideia é o ponto de partida para o brainstorming de funcionalidades, a visão demonstra que o resultado desse brainstorming foi digerido, pelo que algumas ideias daí resultantes foram aproveitadas, outras reajustadas e, a maioria delas, descartadas.

Construir a visão de um projeto não deve ser só uma formalidade. Deve sim ser um passo que é dado e que permite à equipa estar sincronizada sobre as prioridades desse projeto e como se vai acrescentar valor à solução a ser desenvolvida.

Idealmente a visão é o alicerce de um projeto e a pedra angular sobre a qual este é construído. Se determinada feature faz, ou não, sentido na nossa aplicação, é uma pergunta que apareceu ao longo desta experiência e que poderia ser respondida caso existisse uma visão clara, sólida e concisa do projeto.

A visão permite, ainda, que a equipa consiga estabelecer o chamado Definition of Done (DoD), permitindo manter, com consistência, a qualidade ao longo de toda a aplicação.

A Equipa

Tratando-se de um projeto para ser desenvolvido nos tempos livres, o projeto passou rapidamente de algo pessoal para uma equipa de 3 pessoas. Desenvolver um projeto em equipa envolve, antes de tudo, conseguir explicar a ideia do projeto. A visão, portanto. E isso implica ter uma ideia muito concreta, desenvolvida e matura.

Trabalhar em equipa fornece a um projeto uma visão mais alargada, permitindo que a ideia original seja iterada várias vezes, criando várias vezes a discussão de se determinada funcionalidade deve, ou não, ser incluída.

A Stack Tecnológica

Encontrar uma stack tecnológica para desenvolver o projeto significou balancear três grandes variaveis:

• As tecnologias que são necessárias/ideais para desenvolver o projeto.
• As tecnologias que cada membro da equipa sabe/tem experiência.
• O quanto cada pessoa está disposta a sair da sua zona de conforto e aprender uma tecnologia nova.

Conseguir conjugar estas três variáveis foi, na verdade, algo mais simples do que estava à espera. Muitas das vezes esta stack é imposta ao developer, mas nos projetos pessoais temos sempre a liberdade de nos podermos aventurar em novas tecnologias.

A Comunicação

A comunicação entre a equipa deve ser algo que permita a várias pessoas trabalharem à distância e com horários diferentes, tal como um projeto deste tipo obriga. Apesar do Skype ser a ferramenta mais utilizada para conversação por áudio, o Slack é, sem dúvida, uma ferramenta muito boa e que funcionou bastante bem entre nós. As integrações do Slack com as diversas plataformas, como por exemplo GitHub e PivotalTracker, permitem que todas as pessoas estejam up-to-date com o estado atual do projeto.

A Gestão de Expectativas

Quando se desenvolve um projeto nos tempos livres (“na brincadeira”, como se diz na gíria) é normal não existir uma data limite para lançar o projeto. Neste caso tal não era verdade: devido ao mercado e à situação a que se destinada, era necessário ter uma primeira versão funcional em pouco mais de um mês.

Levou algum tempo a configurar o ambiente de desenvolvimento e até configuramos bots de deploy automático para os droplets do DigitalOcean (o que veio a revelar-se tempo “perdido”); configuramos várias integrações entre os vários serviços (repositório Git, Slack, VSOnline, Git Flow, etc). Não queríamos só fazer o projeto, queríamos ter um bom processo por detrás do projeto, configurar serviços, automatizar ações. E isso levou a que a margem da manobra para cumprir o prazo ficasse ainda mais curta.

À medida que a data limite se aproximava e “arranjar” tempo livre para o projeto se tornava complicado, era psicologicamente desgastante e desmoralizante ter que cortar funcionalidades de forma a conseguir terminar a tempo. E há medida que se foi cortando funcionalidades, perdia-se valor da solução, e perder valor era mais uma “facada” psicológica. E repete-se o ciclo.

Think it big, build it small

Esta é a grande lição que aprendi e, por conseguinte, a mensagem que quero passar. Pensamos o sistema bastante completo e tentamos implementar essa grande complexidade de uma só vez. Para o conseguir (dentro da data limite), era necessário dispender mais tempo do que aquele que, efetivamente, tínhamos disponível. E a falta de progresso à medida que o prazo se aproxima é demasiado desmoralizante. Ao fim de alguns “cortes”, acabamos por desistir.

Não podia haver melhor maneira de aprender o porquê do scrum propôr sprints de 1 a 2 semanas e de se investir na integração contínua. Humanamente, é bastante moralizante ver um projeto a avançar sem ter que contar linhas de código, mas vendo pequenas features a serem integradas, aos poucos, no produto.

É importante pensar em grande, pensar como a aplicação vai escalar, como se comporta com 10 e com 10 000 pessoas, mas principalmente pensar em pequenas features com funcionalidades básicas e, a partir daí, iterá-las (quantas vezes necessárias), de forma a que a cada iteração a sua funcionalidade se aproxime cada vez mais da visão do projeto. Primeiro o rascunho e só depois a obra de arte.

Resumindo: arquitetar a solução em grande plano é importante, mas começar a construí-la com pequenos passos incrementais é fundamental. Não só para validação da ideia/conceito, mas porque ter resultados visíveis permite-nos ganhar força e motivação para continuar. Atenção: isto não significa construir a aplicação mal. Que seja clara a diferença entre uma má arquitetura e uma prova de conceito com potencialidade para crescer.

O Sentido Pedagógico

Como é claro, nem tudo foi em vão! Para além da forte componente pedagógica de aprender com os erros, fazer deploy de uma aplicação é muito mais do implementar funcionalidades. A experiência ganha ao arquitetar a solução e pensar como encaixar as várias “peças do puzzle” é um dos elementos que distingue um Engenheiro Informático.

Quanto à componente de gestão de projeto, principalmente ao nível da visão e da definição de prioridades, fiquei rendido ao chamado pitch de elevador.

Costuma-se dizer que se demora 10% do tempo a fazer 90% do código e 90% do tempo a terminar os restantes 10%. É importante, até mesmo num projeto menos sério (como este desenvolvido nos tempos livres) traçar metas e objetivos, sob pena de ser mais um projeto que ficará, inevitavelmente, a meio. Mas também é importante não ter datas tão restritivas e inflexíveis. Aproveitemos os projetos pessoais para aplicar a máxima “done when it’s done”.