É 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á:
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.
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.
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.
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.
Denis Ferrari é um profissional com foco em qualidade e melhoria das técnicas e metodologias de desenvolvimento de software. Especialista na plataforma .NET, atua como Arquiteto de Software na Mindworks. Escreve artigos para os principais portais de desenvolvimento e também para o blog Heróis da TI. Capixaba, atua na comunidade local através de palestras gratuitas e participação ativa nos principais grupos sobre .net e metodologias ágeis.
You must be logged in to post a comment.
