Como produzimos um projeto de 1 mês e meio em 9 dias

Após terminar um projeto crítico, achei que fosse interessante compartilhar o nosso problema e qual foi nossa estratégia, ferramentas que utilizamos e decisões que tomamos aqui na F.biz.


Hoje em dia sou líder técnico na F.biz, especializado no Front-end. Já testei e experimentei bastante nos meus últimos 9 anos de trabalho nesta agência: desde quando aprendia um truque ou outro no javascript, até tentativas de implementação de metodologias, processos de trabalho, padrões de desenvolvimento ou mudanças culturais. Algumas com sucesso e outras fracassadas.

Surgiu um projeto para a construção de um e-commerce. Nada muito desafiador do ponto de vista técnico, pois já temos experiência com isso. Poderia pegar esse cara e testar alguns conceitos novos, aperfeiçoar outros mais amadurecidos. Essas coisas que programador gosta de fazer. Fizemos o primeiro 1/4 do projeto e entregamos a um parceiro que daria continuidade.

Saí de férias e fui muito feliz por 30 dias.

Uma semana depois da minha volta, fiquei sabendo que tivemos muitos problemas com o parceiro. O contrato seria finalizado e precisaríamos produzir internamente. Eram apenas 12 dias até a entrega daquela etapa.


WTF, OMG, etc.

Mantivemos o sangue frio e analisamos o que já estava pronto. O código estava muito longe do que consideramos uma entrega de qualidade. Além disso, percebemos que boa parte daquele 1/4 que havíamos adiantado tinha diversos problemas causados pela edição do terceiro.

Ao invés de perder um tempo precioso entendendo, corrigindo e refatorando o código, decidimos refazer o trabalho.

Reunimos uma equipe de 3 desenvolvedores focados em HTML/CSS e um focado no JS. A partir daí, basicamente gastamos 1 dia e meio planejando e 7 dias e meio desenvolvendo, testando e aprimorando.


Planejamento

Antes de codificar, sabíamos que precisávamos planejar bem os próximos passos já que o tempo para desenvolver o projeto era curto. Além disso deixamos a equipe mais próxima para garantir que nenhum problema fosse omitido durante o processo.

Definição e separação dos módulos

Todas as páginas foram impressas e com 2 canetas hidrográficas analisamos, marcamos e nomeamos os módulos. Com a cor vermelha indicávamos aqueles que seriam construídos do zero e a cor azul aqueles que já existiam e seriam apenas implementados.

Separação dos módulos nas telas impressas

Depois disso, categorizamos, agrupamos e ordenamos em pilhas de folhas separadas o que poderiam ser feito em paralelo. Isso, para garantir que um desenvolvedor conseguisse começar e terminar um módulo sem depender de outro.

Delegação e comunicação

Foi de extrema importância um esclarecimento inicial sobre o projeto. Sentamos e conversamos sobre o que era o projeto, qual era a situação atual e qual era o plano para produzí-lo dentro do prazo.

Para delegação das tarefas, utilizamos o conceito do Kanban: criamos cards com as tarefas e ordenamos por prioridade, seguindo a lógica da categorização. Sabendo disso, cada pessoa foi trabalhando dentro do seu “escopo”.

Padrão de desenvolvimento

Na F.biz temos alguns padrões de desenvolvimento que ajudam a manter uma certa identidade e organização nos projetos. Na prática, economizaram um tempo valioso evitando perguntas do tipo “como nomear?”, “onde jogo isso ou aquilo?”, “como crio um novo arquivo?”, etc.

Além disso, definimos padrões específicos para o projeto e sempre comunicávamos no caso de alguma atualização ou mudança.


Dev ♥ Doc

Mesmo tendo pouco tempo para produzir, o projeto é complexo e terá bastante tempo de vida útil. Era essencial uma boa organização e documentação.

Tivemos 2 frentes de desenvolvimento e documentação: Hyojun.guideline e Gitbook.

Stylesheet Guideline

Temos um projeto na F.biz chamado Hyojun.guideline que basicamente é um site com elementos criados em cima do Twitter Bootstrap. Eles nos ajudam a organizar e formatar a explicação e exemplificação dos módulos de um projeto. Consideramos esse cara o “ambiente de desenvolvimento do front-end”.

A cara do nosso Stylesheet Guideline

Aqui existem todas as cores, famílias tipográficas, tamanhos de fontes e espaçamentos base utilizados no projeto. Além disso, todos os módulos são listados com suas variações, explicações relevantes e código de exemplo para facilitar a manutenção no longo prazo.

Como esse projeto é grande, temos uma categorização extensa para os módulos. A lista de páginas que temos dentro da Guideline são:

Tipografia, módulos, páginas “mock-up” para teste

Todos os módulos da guideline contém um título, uma descrição, um exemplo do resultado visual e o código explicado.

Alguns exemplos de módulos da guideline em questão:

Sempre colocamos todas as variações dos módulos e qualquer informação relevante da construção do código.

Módulos mais complexos podem conter outros módulos menores. Nestes casos criamos links para garantir que o leitor entenda que aí são só implementações de algo que já existe.

Procuramos categorizar os módulos por escopo ao invés da clássica divisão por “página”.


Toda etapa de desenvolvimento aconteceu inteiramente no ambiente da Guideline, ou seja, qualquer desavisado pensaria que o time tivesse apenas trabalhando em documentações. Estes módulos já eram criados dentro de includes que seriam inseridos nas mock-up pages, como em um quebra-cabeça.

Conforme criávamos módulos suficientes para a construção de uma página, algum membro da equipe trabalhava nesses mock-ups — versão estática e navegável do site com todas as variações.

A construção de uma mock-up page é bem simples e quase não contém código, a não ser a própria estrutura:

As páginas estáticas de exemplo são basicamente um conjunto de “includes”

Do ponto de vista do CSS, o desenvolvedor apenas precisa trabalhar na diagramação da estrutura. Normalmente são poucas classes que definem um float aqui, o tamanho da coluna ali e espaçamentos entre elementos — coisas normalmente baseadas na grid.

A construção modular possibilitou que o trabalho fosse bem dividido entre a equipe, sem muitas dependências entre si. Além disso, o desenvolvimento fica “encapsulado” em um escopo, o que facilita bastante resolver erros, más práticas ou código fora do padrão.

Mock-up data

Apesar de simples, esse modelo de trabalho e conceito de organização nos ajudou pois ainda não tínhamos um ambiente funcional que pudéssemos testar. Trabalhávamos apenas baseados nestes módulos “estáticos” utilizando mock-up data para testes.

Pegamos alguns dados do site atual, como nomes de produtos diversos, preços e categorias (do menor ao maior tamanho). Isso ajudou a reduzir problemas recorrente à falta de fluidez nos módulos, pois os textos eram mais próximos da versão final e eram gerados de forma aleatória.

Gitbook

Para documentações sobre instalação do projeto, padrões de desenvolvimento e organização, classes javascript e serviços, utilizamos o Gitbook por ser fácil, rápido e baseado em arquivos Markdown.

Como ele gera arquivos HTML conseguimos garantir que o estilo do documento estivesse normalizado, além disso, o layout, estrutura por “página” e busca facilitam a divulgação e faz com que a leitura seja mais agradável. E os arquivos MD originais são compatíveis com a wiki do Bitbucket ou Github.

Gitbook para start-up, documentações de referência, padrões de desenvolvimento e integrações

Gestão

Para garantir boa visualização do andamento do trabalho, utilizamos os conceitos do Kanban e algumas ferramentas listadas abaixo que nos ajudaram a identificar rapidamente os problemas.

Trello

Ao invés do clássico quadro físico do Kanban, utilizamos o Trello para organizar e acompanhar as tarefas. Os motivos são a simplicidade e rapidez, sem qualquer burocracia.

Exemplo do board de desenvolvimento oficial do Trello

Os cartões foram organizados por contexto, ou seja, um desenvolvedor não necessariamente faria “uma página específica”, mas sim partes que tinham alguma relação entre si. Por exemplo, um card apenas com formulários a serem diagramados, outro com elementos referentes ao processo de check-out, à navegação, à compra de um produto, etc.

Estes cards tinham listas com itens referentes aos módulos e às mock-up pages, que seriam entregues para o time de back-end.

Cada desenvolvedor se inscrevia no card que estivesse trabalhando e ia marcando os itens conforme eram finalizados. Quando uma tarefa era finalizada, mudava de coluna até chegar ao estado “done”.

Usamos bastante as checklists, sistema de comentário e marcação de usuários para que fossem notificados quando algum assunto relevante surgisse.

Team Reporter

Testamos um serviço simples chamado Team Reporter nesse projeto. É um site feio e caro, mas com um conceito simples e que se mostrou muito útil.

No final de cada dia, os membros da equipe recebiam um e-mail contendo um formulário com 4 perguntas:

  • O que você fez hoje?
  • O que fará amanhã?
  • Tem algum problema impedindo o desenvolvimento?
  • A data de sua entrega será impactada?

Na manhã seguinte, todo o time recebia um e-mail com o status geral. Caso houvesse algum problema ou algo que impactasse o trabalho do outro, conversávamos pontualmente sobre isso.

No começo pareceu meio bobo, mas isso reduziu em zero nossas reuniões de status e garantiu que ninguém do time omitisse problemas, além de gerar histórico dos status. Percebemos que em reuniões presenciais, as pessoas geralmente davam status incompletos ou menos relevantes.


Integração

Um outro problema deste trabalho era não termos o ambiente final para testes. Após os 9 dias de desenvolvimento entramos num novo período de integração com o time de back-end de outra empresa.

A guideline nos ajuda bastante no teste, construção e visualização das variações de páginas, mas no final, as páginas “de verdade” estarão em outro lugar.

Uma forma de contornarmos esse problema foi utilizando uma ferramenta muito simples chamada Ngrok. Com ela, conseguíamos acessar o ambiente local dos desenvolvedores.

Basicamente, após instalado, o desenvolvedor rodava na máquina dele e tínhamos acesso a um tunel criado no servidor do Ngrok que nos possibilitava acessar este endereço temporário deles sem muita burocracia de setup de VPN, screenshares ou a espera interminável de ter o ambiente de teste.

Sabemos que não é o ideal, mas a ferramenta ajudou bastante.


TL;DR;

Nada do que foi dito aqui é novidade, mas quis compartilhar como algumas pequenas ações de planejamento e disciplina durante o projeto tiveram um impacto impressionante no tempo de desenvolvimento.

Em resumo, dividiria em alguns pontos importantes:

  • Tempo inicial focado na análise e agrupamento dos módulos;
  • Manter a comunicação constante e clara;
  • Desenvolver baseado em módulos e deixar páginas pro final;
  • Documentar durante o desenvolvimento;
  • Utilizar sistemas de visualização de tarefas e automatizar status diários;

Estes passos garantiram que essa entrega do projeto terminasse com folga e apesar do prazo insano nenhuma pessoa precisou trabalhar durante a madrugada ou finais de semana.