Dia do programador

beer_code-770x330

Hoje é o dia internacional do programador (e também meu aniversário)

A curiosidade está no critério adotado para a definição da data que não tem uma relação histórica, mas sim matemática. O dia do programador é sempre o 256º dia do ano em alusão a um byte de oito bits (28 ).

Apesar de nos anos bissextos a data ser comemorada no dia 12, achei bacana o fato da data coincidir com o meu aniversário.

Feliz dia do programador!

Anúncios

Projeto com cara de “start-up”

Rocket-fuel

Recebi há uns três meses atrás a tarefa de analisar a viabilidade do desenvolvimento de uma solução para geração de boletos, para que os clientes (contrantes das soluções que a empresa onde eu trabalho desenvolve) paguem as mensalidades correspondentes aos serviços prestados.

A ideia inicial era substituir a solução web atual contratada e implementar features customizadas, para que, além de controlar os títulos enviados ao banco e enviar os boletos aos clientes por e-mail, os clientes pudessem acessar uma página web para a emissão desses boletos, de modo que, esse serviço pudesse ser integrado aos principais canais de atendimento ao cliente da empresa. Os requisitos básicos iniciais eram: desenvolver a solução no menor possível, com um time de apenas dois desenvolvedores, utilizando soluções open-source.

Os dois desafios inicias eram: encontrar uma ferramenta open-source para a geração de boletos em java e pensar em uma abordagem que pudesse resultar na entrega de uma solução completa em um prazo de um a dois meses, com somente dois desenvolvedores.

O primeiro desafio foi vencido já no primeiro dia (sendo adotado o projeto Jrimum), no entanto, desenvolver uma solução completa dentro da nossa abordagem padrão de desenvolvimento era inviável, se considerados o prazo e o tamanho do time.

Foi que, ao olhar para os produtos que já possuíamos havia um projeto que continha boa parte dos dados que eram necessários para a implementação da solução. Boa parte do backend e das interfaces de usuário da parte adminstrativa já estaria bem encaminhada. O problema era que o projeto era “antigo” e continha os conhecidos “problemas de legado”, entre eles, alguns códigos que poderiam — deveriam — ser melhores, a linguagem de programação no front (GWT)  e o padrão arquitetural que não utilizávamos mais nos projetos atuais (eu mesmo nunca havia trabalhado nele).

Como o escopo da solução solicitada era relativamente pequeno, e o aproveitamento do legado resolveria a questão do prazo, as tarefas a serem feitas ficaram claras na minha cabeça: desenvolveríamos um front-end “bonitão” em angular para os nossos clientes emitirem os boletos e complementaríamos backend do projeto já existente.

A minha gerente de projetos concordou com a ideia e a complementou com alguns pontos, finalizei a analise inicial juntamente com a pessoa responsável pelo departamento financeiro (futura usuária da parte administrativa do sistema). E mãos à obra, eu desenvolvi o backend e todas as regras de negócio e o meu colega de time toda a parte de front (com base em outro projeto também já existente).

Todos nós (inclusive minha gerente) assumimos os riscos, nos comprometemos com a entrega e tinhamos a consciência que boa parte da solução seria refatorada – e até mesmo descartada – num futuro breve. Em suma, tudo deu muito certo e entregamos a solução que atendeu a todos os requisitos em menos de dois meses.

O sucesso da solução trouxe novas ideias e o escopo do projeto foi ampliado para atender outras demandas internas da empresa, no sentido de atender melhor o cliente. Tanto que, logo após a entrega da solução já iniciamos um processo de refatoração de todo o backend, com inclusão de novas features,  sendo que, no próximo mês toda a parte legada do sistema terá sido descartada.

Hoje na preparação do apresentação do sprint do projeto, eu percebi algo que no início não tinha me dado conta, de que esse projeto foi conduzido seguindo os princípios do “startupismo”:  entrega rápida de valor, validar o quanto antes a ideia, contar com poucos recursos, etc …

O grande aprendizado dessa experiência pra mim foi que, muitas vezes a gente quer fazer tudo muito perfeito logo de início, e entregar uma solução “super elegante”, com todas as boas práticas possíveis e imagináveis – não que eu seja contra isso agora. Mas que em cenários como aqui descrito, é possível (com o uso de bom senso e um pouco de ousadia) desenvolver uma solução que não é muito bonita num primeiro momento, mas que entrega valor no tempo necessário e com poucos recursos.