É impressionante como a repetição de uma determinada atividade faz
com que nós, executores, percamos de vista a razão por trás dela. Isso é
comum, mas não é bom na área de desenvolvimento, afinal, se uma tarefa é
repetitiva e não exige reflexão, podemos colocar um robô no nosso
lugar, que além de ser mais barato, vai errar menos.

Participando de alguns grupos de discussão, percebo que muitos profissionais, em diferentes níveis de maturidade, seguem regras sem analisar o contexto em que estão inseridos. Isso é normal em profissionais inexperientes, afinal, ninguém nasce competente,
mas quando falamos de profissionais com mais tempo de experiência, o
argumento “Faço assim por que é o certo” pode justificar uma decisão que
acarretará em prejuízos enormes para o projeto.

São muitos os parâmetros para tomada de decisão em qualquer aspecto
de um projeto, tais como: Valor que será investido, tempo de vida do
projeto, perfil da equipe, nível técnico da equipe, perfil da empresa,
motivações do projeto, investimento em manutenção, quem vai usar o
projeto, etc. Sempre que decidimos por fazer mais do que o necessário,
estamos gastando dinheiro que não é nosso e que poderia ser mais bem
investido (Reclamamos quando os políticos fazem isso, não é?).

Vamos analisar alguns contextos e refletir sobre as práticas que
podem ou não ser utilizadas em cada um. Lembre-se, isso é um exercício
de reflexão e não regra ok? Vamos lá:

Qual a vida útil do projeto e quais são suas motivações?

Nem todo projeto é para a vida toda. Esse
entendimento é essencial, pois desenhar um software para uma empresa é
muito diferente de desenhar um produto que atende a um ramo de negócio. O
que muda de um para o outro? Tudo.

Construir um produto é uma arte. Cada decisão influenciará gerações futuras de clientes e programadores. Desenvolvimento dirigido por testes é uma premissa básica para esse tipo de projeto. A forma de aplicação das tecnologias é diferenciada,
visando menor esforço em uma possível troca. Facilidade de manutenção e
possibilidade de extensão do projeto são características mais
relevantes do que a produtividade do time. As tarefas nesse tipo de
projeto não são repetitivas e pedem por profissionais com experiência.
Métodos ágeis são muito bons para esse tipo de projeto.

Construir um software para atender a uma necessidade específica é
mais simples, pois precisamos atender a uma quantidade inferior de
usuários. Porém, esses projetos acabam se tornando trabalhosos e
repetitivos, fazendo com que as decisões sejam mais influenciadas pela
produtividade do que por qualquer outra coisa. Projetos que não são
feitos para durar tem o custo de alteração alto.

Um grande problema do
mercado é que vemos muitos projetos durando mais tempo do que deviam virando produtos sem ter o design necessário.

Um projeto que atende às necessidades e ao bolso do cliente é um projeto de qualidade.
A responsabilidade sobre as decisões relacionadas ao tempo de vida do
projeto deve ser compartilhada com o cliente, afinal, ele ficará
envolvido com o projeto mais tempo que a gente.

Qual o perfil e o nível técnico da equipe?

Um programador experiente deve encarar os programadores novatos como seus clientes. Não adianta produzir um código, arquitetura ou design que só outra mente brilhante será capaz de entender.

Analisando o projeto podemos perceber qual o perfil do time que ele
precisa. Alguns projetos pedem um time onde os integrantes possuam
experiência, já outros projetos podem ser desenvolvidos com um time
misto, onde as tarefas menos arriscadas e mais repetitivas acabarão nas
mãos dos profissionais menos experientes.

Um dos maiores problemas do
mercado é o apagão de mão de obra qualificada, que faz com que mesmo os
projetos que pedem um time experiente acabem sendo desenvolvidos por um
time misto.

O que podemos fazer quando o time não é experiente? Simples, fazemos o melhor possível com os profissionais disponíveis. Não importa o quão bom nós somos, não fazemos os projetos sozinhos.

Decisões de arquitetura devem levar em consideração os profissionais que irão trabalhar no projeto, pois um bom projeto entregue é muito melhor do que um projeto perfeito desenhado no quadro branco.

Quem vai usar o projeto?

Imagine que está desenvolvendo uma intranet. Geralmente, os usuários
acessam usando no mínimo o mesmo browser (tomara que não seja o IE 6).
Você pode definir um browser padrão para o projeto e só realizar testes
nesse browser. Apesar de parecer “errado” (pelo menos eu tenho esse
sentimento), essa prática simplifica o desenvolvimento, reduz os custos
dos testes e atende as necessidades do projeto. Se não é necessário, não faça, pois o dinheiro não é seu.

Em outra ponta, vamos imaginar o portal de uma prefeitura. Os
usuários acessam usando diferentes browsers, sistemas operacionais e
possuem níveis diferentes de conhecimento em informática. O projeto não
só deve funcionar em todos os browsers, como também levar em
consideração regras de acessibilidade, legibilidade, etc. Construir um
projeto que atende ao grande público necessita de profissionais
experientes com web e uma bateria de testes, o que reflete diretamente
no valor do projeto.

Por mais que existam boas práticas no desenvolvimento para web, temos que avaliar se cada uma dessas práticas é realmente necessária no contexto do projeto.

Conclusão

Cada aspecto de um projeto nos levará a inúmeras reflexões. Toda e
qualquer decisão tomada sem a análise do contexto pode virar um pilar
fraco e fazer com que todo o projeto desmorone. Uma coisa que aprendemos
no modelo ágil é a importância de envolver todo o time e o cliente
nessas decisões, o que possibilita maior entendimento de todos os
envolvidos e mantém o ambiente o mais transparente possível.

Fábricas geralmente possuem padrões bem rígidos de codificação e das
tecnologias que devem ser utilizadas, pois visam à produtividade de seus
profissionais, que possuem os mais variados perfis e níveis de
experiência. Não há problemas na definição de um padrão. O problema
surge quando a fábrica assume um projeto que pede um “padrão” diferente
do que ela segue.

Não há como fugir, ou analisamos as práticas e
tecnologias que vamos usar em cada projeto ou só desenvolvemos projetos
aderentes às nossas práticas e tecnologias.

Como impor regras para cenários tão distintos? Simples, a adaptação ao contexto deve ser nossa principal regra.
Nossa maturidade profissional não está relacionada somente a dominar as
melhores práticas e tecnologias, mas também em saber quando usá-las.

Até o próximo!