fbpx
5 atitudes infalíveis para fracassar em um projeto de software
Publicado em: terça-feira, 19 de jun de 2018
Categorias: .NET | Carreira Dev
Tags:

Você já deve ter lido 5 formas de obter sucesso em blablabla, mas com uma quantidade tão de grande de projetos fracassados, não fracassar é um bom começo. A propósito, existem milhares de atitudes infalíveis para se obter o fracasso, a pior é não fazer nada! Mas se você chegou até aqui, você não é daqueles que desistem, então vou listar para você 5 das atitudes negativas que levam qualquer projeto ao fracasso!

Desconhecimento das premissas e ambições do projeto

Premissas e ambições são necessárias para pontuar aquilo que você está desenhando e fazendo. São as premissas que garantem a você um alinhamento estratégico entre tecnologia e negócio, viabilizando as tomadas de decisão usando tecnologia, sem perder a essência do projeto, que está em suas ambições. As ambições dão o destino, mas não a direção, portanto as premissas ajudam a restringir o caminho a ser escolhido para que não se dê voltas. Assegurar-se de ambas as informações te ajuda a tomar decisões de forma mais precisa e lhe permite renegociar, afinal, se uma decisão de negócio fere premissas ou ambições, está claro que você está saindo do rumo, é preciso alinhar expectativas para que ninguém saia nem frustrado nem ferido desse projeto.

Exemplo:

Você constrói um chatbot para o Telegram, mais tarde fazem o pedido para que esse chatbot use o Facebook, e durante mais alguns messes surgem outras demandas para que o chatbot use diversos canais que você ainda não implementou. Ótimo, vamos usar Azure Bot Services, da Microsoft. Se supormos que as premissas incluem não depender de serviços intermediadores, essa estratégia é falha.

Somente de posse da premissa e da estratégia, é possível voltar aos solicitantes e dizer que as coisas não são compatíveis, pois de um lado implementar a integração com diversos canais é algo que custa caro, e exige refactoring constante. Já usando o Azure Bot Services o custo de desenvolvimento é infinitamente menor, no entanto implica em custo por uso. Ou ele aceita o aumento de custo no desenvolvimento ou aceita a utilização do serviço externo. Uma vez que a decisão esteja tomada, todos estão cientes das implicações das suas escolhas.

Não filtrar o que o usuário diz

A tentativa de recriar o pensamento do usuário no código nem sempre é uma boa ideia. Na maioria das vezes quando se tenta fazer isso o resultado é desastroso. A questão é que você é o mais indicado, ou deveria, para tomar as decisões certas na hora de implementar um código de negócio da forma tecnologicamente correta ou mais adequada. Isso significa que as coisas não acontecem exatamente como o usuário diz, pois existem motivos suficientes para que isso não aconteça.

Entenda, seu papel é de mediador entre uma ideia ou conceito e um punhado de código e arquitetura que a implementa. É teu papel discernir sobre isso, portanto, complexidade acidental não ajuda, da mesma forma que simplicidade equivocada também não!

Não prever mudanças

Uma das coisas das quais não podemos controlar nos nossos projetos são os fatores externos que demandam mudanças, hora superficiais, hora estruturais. Estar atento às possíveis mudanças exige um estado de sempre-alerta a respeito das decisões técnicas tomadas a cada grande passo em direção a uma arquitetura. Cada nova restrição pode dificultar, atrapalhar e até inviabilizar a execução de alguma mudança. Enquanto no primeiro tópico aponto o desconhecimento sobre o horizonte de expectativas e ambições do projeto, agora o foco é no produto/projeto que você está trabalhando. E o principal ofensor à mudança são as decisões demasiadamente restritivas. Um cuidado deve ser tomado pois, essas decisões podem gerar um impacto profundo, de forma a demandar, por exemplo, uma refatoração extensa.

Falta de comprometimento com a estratégia técnica

Eu acredito que possivelmente você tenha visto pelo menos uma vez na vida um gestor dizendo algo mais ou menos assim: Faça o possível, e de qualquer forma, para resolver o problema, depois nos preocupamos com qualidade! Bom, tem gente que escuta isso o tempo todo! Mas pior que esse gestor é o desenvolvedor que diz: Eu faço isso mais rápido se [pular|não executar|suprimir|burlar] as etapas x, y e z! Você me autoriza a fazer assim? Esse filho de uma égua parideira merece arder no fogo do inferno! Esse filho de rapariga merece o olho da rua pois é um câncer para qualquer estratégia técnica. Ok, damos a chance de não demiti-lo na primeira, mas na segunda vez que o mesmo indivíduo ruminante conjurar tal magia, é bom pensar em abrir uma vaga junto ao RH. E se você trabalha comigo: abra seu olho, viu!!! hahah (brincadeira, são vocês são 10).

Retomando

Voltando: Ao olhar inexperiente esse tipo de abordagem sugere comprometimento com a empresa, mas na minha visão, estamos diante de um câncer corporativo. Antes de mais nada precisamos diferenciar uma real crise, de um problema corriqueiro. Ou diferenciar uma questão pontual de um modus operandi. Se não estivermos falando de morte de pessoas, bichinhos fofos, ou perdas financeiras monumentais, não há motivo algum para não seguir um fluxo, eliminar uma etapa ou deturpar uma estratégia tecnológica. Até porque em geral o objeto de corte está relacionado a qualidade direta ou indiretamente. Seja criando mais um consolezinhoDoCapeta ou eliminando etapas estritamente desenhadas para garantir a qualidade, esse profissional não está comprometido com o resultado da empresa, mas com a própria capacidade de agradar o chefe  ou demandante dessa tarefa.

O problema é que com o passar dos meses, com muita sorte, anos, temos uma colcha de retalhos, que pode tornar a gestão impossível e não sabemos se a curto, médio ou a longo prazo. A conta pode chegar antes do que você imagina, portanto, fazer certo, é fazer uma vez só. E está tudo bem se tiver de revisitar o assunto mais tarde, isso não é um problema. Mas dar jeitinhos e sair tomando ações no desespero, geralmente gera um legado tenebroso, daqueles que se joga fora, se paga centenas de milhares de reais ou até milhões de reais para reconstruir do zero. E esse profissional, bonzinho, não é uma ovelha, é um capeta! É um câncer!

Separe o joio do trigo! Não seja o joio!

O Cloud Native .NET é meu principal projeto.

Onde empenho energia para ajudar, acompanhar, direcionar Desenvolvedores, Líderes Técnicos e jovens Arquitetos na jornada Cloud Native.

Conduzo entregando a maior e mais completa stack de tecnologias do mercado.

Ao trabalhar com desenvolvedores experientes, eu consigo usar seu aprendizado com .NET, banco de dados, e arquitetura para encurtar a jornada.

Ao restringir à desenvolvedores .NET eu consigo usar do contexto de tecnologias e problemas do seu dia-a-dia, coisas que você conhece hoje, como WCF, WebForms, IIS e MVC, por exemplo, para mostrar a comparação entre o que você conhece e o que está sendo apresentado.

É assim que construímos fundamentos sólidos, digerindo a complexidade com didática, tornando o complexo, simples.

É assim que conseguimos tornar uma jornada densa, em um pacote de ~4 meses.

Eu não acredito que um desenvolvedor possa entender uma tecnologia sem compreender seus fundamentos. Ele no máximo consegue ser produtivo, mas isso não faz desse desenvolvedor um bom tomador de decisões técnicas.

É preciso entender os fundamentos para conseguir tomar boas decisões.

0 comentários

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

[docker de a a z]

Lives

Fique de olho nas lives

Fique de olho nas lives no meu canal do Youtube, no Canal .NET e nos Grupos do Facebook e Instagram.

Aceleradores

Existem diversas formas de viabilizar o suporte ao teu projeto. Seja com os treinamentos, consultoria, mentorias em grupo.