O resultado esperado é sempre “Ganhar mais” ou “Gastar menos”, de preferência “Ganhar mais gastando menos”! Terá melhores resultados quem conseguir entender bem essa relação:
Quanto maior a complexidade, maior o empenho. Logo, maior o impacto negativo sobre a produtividade.
Sobre Complexidade
No desenvolvimento de um sistema enfrentamos diferentes complexidades. Podemos classicá-las como:
- Essencial – Aquela que não pode ser evitada.
- Acidental – Aquela que “escolhemos” adicionar ao projeto.
Outra classifcação relevante para complexidade seria:
- Domínio – Inerente ao problema de negócio que estamos tentando resolver
- Solução Técnica – Com relação as técnicas e tecnologias (frameworks, ambientes operacionais, etc) que optamos por adotar
- Legado – Soluções que precisamos continuar suportando, alheio a nossa vontade.
Embora não seja uma regra de ouro, podemos estabelecer duas relações entre as classificações que acabamos de propor:
- Complexidade Essencial = Domínio
- Complexidade Acidental = Solução Técnica + Legado
Em suma, geralmente, a única complexidade que geralmente não pode ser evitada, de forma alguma, é a complexidade do domínio. As demais, somente serão toleradas se forem indispensáveis para atender as demandas do domínio (pensando em disponibilidade e assertividade [entre outros atributos não funcionais acordados com o negócio])
A complexidade do domínio também é a única que o “negócio” entende.
Complexidade é Custo
Agora, proponho uma nova leitura. Vamos trocar a palavra complexidade, que usamos acima, por custo.
Logo, temos:
No desenvolvimento de um sistema enfrentamos diferentes complexidades custos. Podemos classicá-los como:
- Essencial – Aquele que não pode ser evitado.
- Acidental – Aquele que “escolhemos” adicionar ao projeto.
Outra classifcação para complexidade custos relevante seria:
- Domínio – Inerente ao problema de negócio que estamos tentando resolver
- Solução Técnica – Com relação as técnicas e tecnologias (frameworks, ambientes operacionais, etc) que optamos por adotar
- Legado – Soluções que precisamos continuar suportando, alheio a nossa vontade.
Embora não seja uma regra de ouro, podemos estabelecer duas relações entre as classificações que acabamos de propor:
ComplexidadeCusto Essencial = DomínioComplexidadeCusto Acidental = Solução Técnica + Legado
Em suma, geralmente, a única complexidade o único custo que geralmente não pode ser evitado, de forma alguma, é a complexidade o custo do domínio. Os demais, somente serão tolerados se forem indispensáveis para atender as demandas do domínio (pensando em disponibilidade e assertividade [entre outros atributos não funcionais acordados com o negócio])
A complexidade O custo do domínio também é o único que o “negócio” entende.
Implicações da relação Complexidade e Custo
A única complexidade (ou custo) que o negócio entende e que, naturalmente, está disposto a pagar é a relacionada ao domínio. Não há muita sensibilização pela infraestrutura de nuvem, nem pela estratégia de persistência, nem sobre as estratégias de teste, nem com a integração com o banco de dados legado. Para o negócio, todas essas são questões acidentais – são custos que escolhemos e que deveriam ser evitados.
Voltemos a relação com a qual iniciei este post:
Terá maiores chances de êxito quem entender que as Complexidades/Custos Acidentais implicam em aumento do empenho e são um obstáculo à produtividade.
Como justificar complexidade/custo acidental
O custo total de um sistema pode ser descrito como:
Como desenvolvedores profissionais, buscando a produtividade, devemos tomar decisões visando reduzir o custo total empenhado.
Geralmente, há um trade-off entre o custo para desenvolver e para manter. Ou seja, quando optamos por uma estratégia que irá reduzir o custo de manutenção, aumentamos o custo de desenvolvimento. Quando optamos por uma estratégia que irá reduzir o custo de desenvolvimento, geralmente optamos por aumentar o custo de manutenção.
De forma empírica, geralmente é mais inteligente optar por reduzir o custo de manutenção para minimizar o custo total. Mas a resposta definitiva depende de cada caso.
Quando optarmos por adicionar complexidade a um projeto, precisamos verificar se haverá redução no custo para desenvolver ou para manter. Caso não haja nenhum ganho, será difícil justificar essa opção.
De qualquer forma, é sempre melhor reconhecer que estamos falando de custos e é dessa forma que devemos debater com (e sensibilizar) o negócio.
Por exemplo:
- Testes reduzem o custo total significativamente, pois reduzem o custo de manutenção (embora podendo aumentar um pouco o custo de desenvolvimento)
- Adotar o framework XPTO facilita a adoção de novas features, reduzindo o custo da manutenção
- Um banco de dados NoSQL diminui as dificuldades para persistência de dados novos mais adaptados a novos cenários de negócio (manutenção mais baixa)
Concluindo
Desenvolvimento profissional é, em boa dose, a arte de escolher complexidades (custos) com eficiência. Todo custo para atender o domínio é bem atendido pelo negócio (e geralmente aceito). Todos os outros custos devem ser justificados com base no impacto para o custo total.
Lembre-se, recurso/funcionalidade/benefício não percebido pelo negócio, no final do dia, é só custo. Por definição, custos devem ser cortados.
