Porque projetos de TI demandam tanto esforço, energia, custam caro e ainda por cima atrasam?

Pessoal

Aqui vai uma possível resposta para esta questão que infelizmente faz parte do dia-a-dia da maioria de nós. Neste post estão reunidos insumos do Martin Fowler, Uncle Bob, Adriano Tavares e outros. 

http://nelsonbassetto.com/blog/2014/02/porque-projetos-de-ti-demand...

Exibições: 565

Comentar

Você precisa ser um membro de PanGea para adicionar comentários!

Entrar em PanGea

Comentário de Nelson Bassetto em 4 março 2014 às 19:22

Muito boa discussão!! A maioria dos pontos colocados até então vão de encontro também ao que o Tomas Erl (um cara que é referência em SOA) intitulou uma vez como "Miopia em TI". Escrevi a respeito aqui: http://nelsonbassetto.com/blog/2012/09/shortsightedness-in-it-thoma...

Comentário de Fábio Almeida em 28 fevereiro 2014 às 17:23

É isso Henrique, existem muitas empresas que não valorizam o software.

O Martin Fowler uma vez comentou sobre isso em um artigo sobre software Utilitário vs Estratégico (http://martinfowler.com/bliki/UtilityVsStrategicDichotomy.html) ele inclusive comenta um artigo muito bom de Nicholas Carr (IT Doesn’t Matter - http://hbr.org/2003/05/it-doesnt-matter/ar/1) . Um comentário extraído do artigo de Martin Fowler:

"software is like sewage pipes, I want it to work reliably and I don't want to know about the details".

Comentário de Jaguaraci Silva em 28 fevereiro 2014 às 11:50

Desenvolver software envolve processos, ferramentas e pessoas. Gerenciar todas as variabilidades, o que inclui: pontos de vistas, necessidades, requisitos...não é fácil. Parece trivial o que escrevo, mas é o cerne de todos os problemas na construção do software. Se do ponto de vista de quem gerencia cria-se um cronograma basedo no PMBok, que não leva em consideração o próprio processo de construção, já há um grande gap e dificilmente isso será visto.

Comentário de Ricardo JP Baraldi em 28 fevereiro 2014 às 8:05

Sr, tive o privilegio de trabalhar em USA Asia e Europa. Posso dizer que todos meus jefes la eram melhores q eu tecnicamente, cheios de certificacoes e com grande conhecimento do negocio. No Br os executivos de TI simplesmente sao amigos de algueim, nao conhecem nada ou seu conhecimento esta super-defassado. La fora vc sendo um enterprise architect  ganha tanto como diretor e nao necessita virar burocrata para ganhar bem. Como eles nao tem condicao de contestar nada e como todo o mundo e tercerizado os prazos sao chutados la encima, e eles aceitam. Nao entendo como algueim q ganha 20K nao se digna a fazer um simples MBA, falar ingles  ou tirar o PMP. Por isso os projetos (qualquer um) triplicam o prazo , o orcamento e o responsavel fica porque e amigo de algueim. So q isso retorna desacreditando as profissoes baixando os salarios e nao dando o valor para as certificacoes que tem realmente la fora. O dia q profissionalizemos os executivos gerara um efeito cascata e o resto da cadeia naturalmente se assemelhara ao 1ro mundo. Eu mesmo sofro isso e tenho 30 anos de ti. abs

Comentário de Henrique de Miranda Gontijo em 27 fevereiro 2014 às 23:10
Um outro ponto é a questão de valor agregado. Infelizmente, no Brasil, software não é valorizado da mesma maneira que é nos países de 1o mundo. Nos países de 1o mundo, como nos EUA por exemplo, o profissional de computação tem um dos melhores salários. E para se pagar bons salários, as empresas precisam ser rentáveis. A meu ver, no Brasil as empresas não pagam o devido valor e isso acaba se refletindo em toda a cadeia do projeto (recursos, prazos, qualidade do software, equipes desmotivadas, alta rotatividade). Porque as empresas no Brasil não valorizam software? Fica a pergunta.
Comentário de Adriano Tavares em 26 fevereiro 2014 às 23:19

Tem uma imagem do toolscloud.com que mostra as ferramentas da infra-estrutura deles, incluindo Jenkins e Sonar. Dá uma olhada:

Comentário de Adriano Tavares em 26 fevereiro 2014 às 23:12

É isso aí Rafael. 

Comentário de Rafael Fontoura em 26 fevereiro 2014 às 23:05

É verdade, Adriano. Confundi aqui. O Jenkins somente gerencia os jobs para geração de builds, recuperação de código do repositório e execução de tarefas pré/pós builds.

Comentário de Adriano Tavares em 26 fevereiro 2014 às 23:03

Pessoal, esse calculo não é feito pelo Jenkins e sim pelo Sonar. O Jenkins é para integração contínua. O Sonar que calcula e exibe métricas de qualidade. 

De uma forma beeeemmmm resumida o débito técnico calculado pelo plugin do Sonar é o custo da má qualidade acumulada, medida em homem-hora.

Debt(in man days) =  cost_to_fix_duplications + cost_to_fix_violations +
  cost_to_comment_public_API + cost_to_fix_uncovered_complexity +
  cost_to_bring_complexity_below_threshold

Segue o link sobre o calculo do débito técnico com Sonar: 

http://www.sonarqube.org/evaluate-your-technical-debt-with-sonar/

Comentário de Nelson Bassetto em 26 fevereiro 2014 às 22:46

Fala Deiverson. Também acho que tem um fundo cultural sim. É comum encontrar gestores de TI que valorizam muito o conhecimento sobre o negócio e sobre os sistemas legados, e pouco o conhecimento técnico. 

Rafael, não conheço o Jenkins, mas parece bem legal. Pelo que entendi, ele deve fazer uma análise de código, provavelmente considerando o nível de acoplamento entre classes, o nível de coesão (classes que fazem muita coisa são pouco coesas e mais difícil de manter), a quantidade de código duplicado, etc., chegando a uma estimativa de esforço para correção do que foi encontrado. Dai, se ele tiver o valor médio da hora do profissional, fica fácil mensurar. 

Parece uma análise bastante válida, mas acho que acaba não sendo completa se não levar em consideração o que está fora da fronteira de um sistema apenas. Por exemplo, a duplicidade de código e dados entre sistemas distintos, a forma como os sistemas se integram - um sistema acessa diretamente a tabela do outro? Ou seja, está diretamente acoplado ao modelo de dados do outro, etc. 

Novos comentários são bem-vindos! 

Evento TDC2016

Badge

Carregando...

© 2017   Criado por Adriano Tavares.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço