desenvolver a pensar no futuro

Cada vez mais considera-se uma boa prática desenvolver soluções escaláveis, que possam crescer no futuro e que consigam ir ao encontro das necessidades do cliente daqui a, salvo a expressão, 100 anos.

O problema desta abordagem, desta tendência de tentar “adivinhar” as necessidades do cliente no futuro, é poder muito facilmente deixar de ser uma boa prática para se transformar num autêntico elefante branco.

Temos a responsabilidade e obrigação de perceber que se o cliente, por exemplo, quer uma página web com uma tabela talvez faça mais sentido efectivamente fazermos uma tabela em HTML que demora 1 hora a ser feita (ou coisa que o valha) do que desenvolvermos um backoffice com base de dados e com um editor de conteúdos que permita a inserção de tabelas pré-formatadas.

Afinal que pretende o cliente? Uma página com uma tabela ou uma super aplicação que daqui a “100 anos” ainda estará usável e irá permitir ao cliente mudar a tabela sem a nossa intervenção?

E o tempo de desenvolvimento? 1 hora de trabalho versus 1 semana ou 2?

E alguém perguntou ao cliente se ele efectivamente precisava de uma solução tão escalável?

Então e o time-to-market do cliente? Alguém preocupa-se com isso?

Qual é o tempo de vida do produto (neste caso da página web com a tabela)? Se para o ano o cliente pode já não precisar dela? Então possivelmente fará sentido uma abordagem mais simples…

Alterações? Será que o cliente vai fazer ou nem por isso?

Nos dias de hoje todos caímos na tentação de seguir excelentes práticas de construção de produto esquecendo-nos por vezes das reais necessidades do cliente.

O óptimo sempre foi, e sempre será, inimigo do bom e como já escrevi aqui várias vezes, superar as expectativas do cliente é entregar exactamente aquilo que ele pediu e não “inventar” necessidades que na realidade não existem.

Grande parte de nós gostaria de ter um ferrari, mas na verdade um fiat punto (que também é um carro italiano) é tão eficiente nas ruas da baixa lisboeta como é o topo de gama que ostenta um cavalo rampante.

Até para a semana.

quality assurance no scrum

Desde que adoptei o scrum, tenho feito mais testes do que alguma vez fiz.

O resultado está à vista de todos, temos tido muitos menos bugs nos testes finais de aprovação o que acaba por ser curioso pois como não existem praticamente bugs o cliente sente-se com confiança para pedir sempre alguns melhoramentos. Algo que antigamente com mais bugs era impossível, quer por falta de tempo ou por falta de confiança nos desenvolvimentos.

Após algum tempo a praticar scrum não tenho dúvidas que trouxe melhorias significativas no trabalho, principalmente a nível processual.

Não me canso de dizer que estou rendido ao scrum.

O único (grande) aspecto do scrum que ainda não estou, de todo, convencido é a utilização de sprints em desenvolvimentos web.

Os nossos clientes têm um time-to-market extremamente agressivo e não é concebível que tenham de esperar 2, 3 ou 4 semanas por um package de desenvolvimentos quando podemos ter várias releases durante esse período de tempo disponibilizando de forma gradual e mais atempada as novas features ou correções de bugs.

Eu costumo dizer que o melhor scrum é o nosso scrum. Não é o scrum que vem nos livros mas sim a forma como adaptamos o scrum à nossa realidade. Se forem vocês a adaptarem-se ao scrum, então o objectivo principal do scrum está logo desde o início a falhar. Deve ser o scrum a adaptar-se a vocês e não o contrário. O scrum procura melhorar o funcionamento de uma equipa e não mudá-lo completamente ignorando o meio onde esta equipa está inserida.

É como alguém uma vez disse: “Don’t ask what you can do for scrum, but what scrum can do for you!“. Não foi bem esta frase mas era algo do género. 🙂

Até para a semana.