Um pesadelo de T.I.

Bom, esse tipo de situação é bastante complicada.

Aqui eu vejo duas direções, ou você sai do jogo ou vai pra briga !! Faça um relatório mais próximo possível de um papper, com citações bibliográficas que mostrem o quanto as ações da equipe atual podem impactar e prejudicar o projeto em diversas questões.

Direcione ao fim esse relatório pra quem toma a decisão lá em cima, CIO até se for o caso e deixe o pessoal de cima resolver o que querem, afinal você fez sua parte !

This message was edited 1 time. Last update was at 13/12/2009 21:41:07

Kenobi wrote:Bom, esse tipo de situação é bastante complicada.

Aqui eu vejo duas direções, ou você sai do jogo ou vai pra briga !! Faça um relatório mais próximo possível de um papper, com citações bibliográficas que mostrem o quanto as ações da equipe atual podem impactar e prejudicar o projeto em diversas questões.

Direcione ao fim esse relatório pra quem toma a decisão lá em cima, CIO até se for o caso e deixe o pessoal de cima resolver o que querem, afinal você fez sua parte !

Concordo 100%.

Agora, acho que isso é um pouco dificil de acontecer, já que na situação do amigo a equipe nova tinha acabado de ser contratada. será que todos estavam dispostos a comprar essa briga? Acredito em união, mas isso só vem com algum tempo de convivência.

Se a empresa tivesse realmente preocupada com o "como" as coisas seriam feitas, e não apenas com o resultado final, teriam contratado alguém para tocar esse projeto, não digo gerente, coordenador nem nada disso, mas pelo menos um arquiteto, senior lider de equipe, algo assim, para poder tomar as melhores decisões tecnicamente falando. Se era pros coboleiros tocarem o projeto, por que não dar um treinamento pra eles? esse negócio de não ter autonomia pra tomar as decisões em projetos é um dos piores modelos pra se trabalhar, pq vc faz errado, sabe que ta errado, sabe que aquilo vai te causar N problemas na hora da manutenção, e mesmo assim é obrigado a fazer. Isso pra mim significa alta rotatividade, e todo mundo perde.

Se o diretor/gerente/seiLaOQue de TI tivesse o mínimo de conhecimento em tecnologia, saberia que seria necessário uma quebra de paradigmas pra trocar esses sistema pra Java, ou qualquer outra linguagem OO. Saberia também que o povo do cobol se sentiria ameaçãdo, e que iria no mínimo dificultar as coisas, para não perder o controle, e consequentemente, o emprego.

Mario, possivelmente o executivo que está bancado o projeto, acredita que está sendo modernizado e não tem o conhecimento tão baixo nível como este para tomar qualquer tipo de decisão, daí a importância de um relatório completo se possível com o Domain que o executivo conhece, como dados de Gartner, ROI e por aí vai .... Aí o cara pega a atenção do executivo e provavelmente as coisas mudem radicalmente !! Aliás, se eu fosse o executivo e visse um relatório desse tipo, sinceramente faria uma auditoria e quem o fez iria ser no mínimo promovido

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

FrancoC wrote:

Se houvesse um orgao com competencia ele entao realizaria um auditoria na suposta "fabrica de software" de Joazinho e descobre que lá não há processos estabelcidos, controle de qualidade, seus profissionais estao sendo mal remunerados, não há reciclagem na formacao destes, além uma serie de outros problemas.

E aí quem paga o pato?
(...)

Voces defendem que na produção de software nao deve haver responsabilidade legal, faz-se o que quer, como quer, com o custo que se deseja.

O fato é que existem métricas, e é possível medir e avaliar.

O fato de haver processos estabelecidos não indica que ha bom software sendo produzido. A maior parte das empresas que tem processos estabelecidos seguem um modelo stage-gate (tipo waterfall). O processo está lá, mas apenas atrapanha o desenvolvimento. O problema aqui é que não existe um padrão de fato para um processo de projeto de software como existe para as outras áreas.

Depois, não existem realmente métricas para avaliar ou medir coisa alguma que seja relevante. Leia Clean Code do Robert C. Martin e me diga quais métricas garantem as boas práticas escritas lá. Por exemplo : nomes relevantes. Classes, métodos e variáveis devem ser nomeados com nomes relevantes, ou seja, legiveis, buscaveis, intelegiveis e de acordo com o contexto em que se inserem. Nenhuma ferramenta ou métrica indica esta qualidade. claro que vc pode auditar manualmente o codigo e contar o numero de nomes relevantes sobre o numero total de nomes, mas isso ainda não é uma métrica padrão e não ha ferramenta que automatize isso. Outros exemplos são os comentários relevantes e o controle de exceções. A qualidade do código está em coisas que são obvias quando um desenvolvedor lê o codigo, mas não são obvias às ferramentas , aos IDE ou sequer aos donos de projeto.

Não se trata de ter responsabilidade. Isso sempre está presente. Se um cozinheiro intoxicar alguem ele será punido. A questão é que saber que uma comida está envenedada ou é toxica é simples :vc manda para um laboratorio. Mas não existe um organismo para onde vc manda o codigo para saber se está ok. O problema é falta deste detector de código ruim e não a punição em si. essas já existe na lei para todas as profissões (negligência).

MauroOliveira wrote:(...)

pra essas questões sou anti-herói, pois quando se trata da filosofia de uma empresa, vc não pode mudar nada.
Já passei por uma situação parecida com a sua, tentei expor meu lado e quando me chamaram na gerencia, achei que iam me ouvir, mas queriam me deixar num canto pra não incomodar ninguém. Saí de lá imediatamente, memso ganhando menos fui para um lugar onde as pessoas pensavam como eu, e hj pessoalmente tenho isso como uma grande experiencia de vida.

GUJ Master Membro desde: 27/04/2006 21:01:27 Mensagens: 1134 Offline

FrancoC wrote:Na verdade não impediria que coisas assim acontecessem, mas de certa forma seria coibido.

Como?

FrancoC wrote:
Imaginem que inves de produzir sistemas de informacao gerencias, fosse um software que controla a distribuicao de energia do país. Dai o sistema com alguma falha de vazamento de recursos diante de uma sobrecarga de dados no servidor derruba o sistema. O páis inteiro está na escuridão (qualquer semelhanca com fatos reais é pura coincidencia). Ai as autoridades vao atrás da EDP Bandeirante e descobrem que o sistema era fonercido pela empresa de Joãozinho. Joãozinho ganhou da concorrencia pq jogou o preco para entregar o produto para a metade do que a media que havia sido orçado pelos concorrentes.

Pela milésima vez, isso é fantasia sua. Procure se informar. Em uma licitação fazem-se inúmeras exigências das empresas que se candidatam excluindo assim aquelas fundo de quintal. Exigem coisas como um número mínimo de profissionais com mestrado, todos os profissionais precisam ter no mínimo universidade, a empresa precisa ter no mínimo certificações ISO tal tal tal e CMM nível tal. E também pedem certificações para os profissionais também, tipo certificação dessa tecnologia tal e tal.

E jogar o preço lá embaixo qualquer um pode fazer. O problema é que uma licitação envolve um contrato, e esse estipula condições e garantias para a contratante.

Além do mais inúmeras coisas podem ser a causa de uma falha, visto que PCs não foram feitos para se ter confiabilidade. Se o Windows trava o desenvolvedor é culpado? Se a memória dá problema o desenvolvedor é culpado?

Você já está a várias threads insistindo nesse ponto, e por diversas vezes várias pessoas já explicaram e reexplicaram o por que não funciona. Você tem alguma dúvida?

This message was edited 1 time. Last update was at 14/12/2009 16:31:28

FrancoC wrote:
Não, não estou dizendo isso.
Também em momento algum eu disse que ao utilizar Hibernate no lugar de JPA voce esta degradando a qualidade do software, ou que uma arquitetura em MVC é melhor do que Pipeline.
Vocês tem um raciocinio muito raso sobre a engenharia de software.
Imagina uma lei proibindo o uso de Struts 1.
Cada coisa que eu leio aqui.

Sim. Você disse:

FrancoC wrote:Agora uma vez que eles optaram por utilizar Java, C# ou C++ em alguma ponta de suas soluções, terão de utiliza-lo 100% O.O. e seguir as mais recentes práticas e padrões do mercado.

Você disse que eles teriam que utilizar 100% OO. Você disse que eles teriam que usar as mais recentes práticas (struts 1 é pré-histórico). Você disse que eles teriam que usar padrões de mercado (JPA é o padrão definido pela SUN para persistência Java). Caso contrário, poderiam ser punidos.

Nós temos um raciocício raso (Aliás, não gostei desse termo)???

Cada coisa que EU leio aqui.

JavaTeenager Membro desde: 15/10/2009 13:11:25 Mensagens: 193 Offline

Thiagosc wrote:
Pela milésima vez, isso é fantasia sua. Procure se informar. Em uma licitação fazem-se inúmeras exigências das empresas que se candidatam excluindo assim aquelas fundo de quintal. Exigem coisas como um número mínimo de profissionais com mestrado, todos os profissionais precisam ter no mínimo universidade, a empresa precisa ter no mínimo certificações ISO tal tal tal e CMM nível tal. E também pedem certificações para os profissionais também, tipo certificação dessa tecnologia tal e tal.

Em qual mundo isso? Eu que estou fantasiando mesmo? Ja trabalhei em diversos projetos pro setor publico e nunca vi esse tipo de exigencias, profissionais com mestrado ou no minimo superior. Talvez isso existe na esfera federal, mas em nivel municipal e estadual nunca vi isso.

E eu nem falei em licitação. Falo em terceirizacao no setor privado mesmo.

Thiagosc wrote:
E jogar o preço lá embaixo qualquer um pode fazer. O problema é que uma licitação envolve um contrato, e esse estipula condições e garantias para a contratante.
Além do mais inúmeras coisas podem ser a causa de uma falha, visto que PCs não foram feitos para se ter confiabilidade. Se o Windows trava o desenvolvedor é culpado? Se a memória dá problema o desenvolvedor é culpado?
Você já está a várias threads insistindo nesse ponto, e por diversas vezes várias pessoas já explicaram e reexplicaram o por que não funciona. Você tem alguma dúvida?

Errado. Este é apenas a segunda thread que eu levanto essa questão, e na thread anterior encontrei várias pessoas que tem o mesmo pensamento que o meu. O único motivo de um profissional estar de acordo com a desvalorização de sua classe é falta de conscientizacao.

JavaTeenager Membro desde: 15/10/2009 13:11:25 Mensagens: 193 Offline

[favor deletar]

Eu sou totalmente contra uma regulamentação na área de informática, a menos que ela siga as diretrizes da SBC, que regulamenta oficialmente que todos podem praticar a profissão.

Pelos seguintes motivos:

a) Processos em informática mudam muito rápido, e garantem muito pouca coisa. Diferente da engenharia civil, nossos processos ainda são imaturos, e dão poucas garantias. Fora que montar o software, mesmo depois de um processo definido, não é uma tarefa mecânica. O custo para deixar uma solução livre de erros é astronômico, e a burocracia dificilmente acompanharia a agilidade da área;
b) Programadores medíocres vão continuar existindo, mesmo que cursem uma faculdade;
c) Software de risco geralmente está associado a engenharia, que tem regulamentação própria. Por exemplo, todos os softwares já citados nesse tópico (aviões, sistemas médicos, etc);
d) Pisos salariais geram desemprego, ou criam a máfia de assinaturas. Não é possível para um governo tornar um salário artificialmente alto.
e) A área é super ampla, acho difícil fazer uma avaliação profissional genérica.

Agora, sou a favor de mecanismos de certificação mais eficientes. Não seria bacana um "Poscomp" com foco em mercado? Uma prova bem feita certamente tem mais valor percebido que uma lei e valoriza o profissional de qualidade. Como é o caso de algumas certificações de renome, como a da Cisco.

GUJ Master Membro desde: 27/04/2006 21:01:27 Mensagens: 1134 Offline

FrancoC wrote:Em qual mundo isso? Eu que estou fantasiando mesmo? Ja trabalhei em diversos projetos pro setor publico e nunca vi esse tipo de exigencias, profissionais com mestrado ou no minimo superior. Talvez isso existe na esfera federal, mas em nivel municipal e estadual nunca vi isso.

Qualquer projeto no setor público precisa de um processo de licitação onde exigências são feitas. Isso busca evitar por exemplo que políticos contratem amigos ou a empresa da esposa.

Se você conhece alguma empresa pública que contrata empregados sem concurso ou empresas sem licitação saiba que isso é ilegal.

Um projeto grande que seria usado em uma hidrelétrica por exemplo com certeza passaria por um processo de licitação onde as empresas entregariam as suas propostas.

FrancoC wrote:
E eu nem falei em licitação. Falo em terceirizacao no setor privado mesmo.

Empresas com necessidades especiais procuram empresas que possam atender as suas necessidades especiais. Tal "regulamentação" serviria apenas para destruir as pequenas empresas enquanto consultorias e empresas grandes ficariam impunes.

FrancoC wrote:
Errado. Este é apenas a segunda thread que eu levanto essa questão, e na thread anterior encontrei várias pessoas que tem o mesmo pensamento que o meu. O único motivo de um profissional estar de acordo com a desvalorização de sua classe é falta de conscientizacao.

Várias quem? Deve ter tido um ou dois, no máximo. Desvalorização da classe são os baixos salários e condições de contratação que obrigam os profissionais a fraudarem a CLT. Nenhum desses casos seria resolvido por regulamentação. A própria regulamentação visa "defender a sociedade" e não o profissional, ou seja, tudo continuaria igual com a diferença que estaríamos pagando taxas.

Agora você nunca explicou em detalhes como os processos e softwares seriam analizados para verificar a sua integridade. Isso é impossível porque ao contrário da engenharia civil, informática muda a todo momento, novas tecnologias e processos são introduzidos o tempo todo. A menos que você deseje congelar a área de TI no tempo, é impossível estabeler padrões.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

ViniGodoy wrote:
Agora, sou a favor de mecanismos de certificação mais eficientes. Não seria bacana um "Poscomp" com foco em mercado? Uma prova bem feita certamente tem mais valor percebido que uma lei e valoriza o profissional de qualidade. Como é o caso de algumas certificações de renome, como a da Cisco.

Em tese concordo com essa ideia,mas quem faria esse teste e como vc certifica que alguem sabe programar ? aliás o que é "saber programar" ? Acho que o problema é mais embaixo.

1) Não ha um corpo claro do que significa "programar bem". Para mim , programar bem é programar limpo. Para outras pessoas é programar com testes, para outras é simplesmente que o software funcione. Embora hoje se assista a um foco em métodos agíeis como pair programing isso não garante que seja feita boa programação. apenas garante que todos programam igual.

2) Não existe um processo de coordenação de projeto de desenvolvimento de software, mas vários. Isso mostra a imaturidade acadèmica e prática nessa area da administração, mas não na área da informática. se projetos de sotware são mal gerenciados, é problema do gerente que é um elemento administrativo - ao contrario do arquiteto civil que sabe do que se trata a prática do problema. Enquanto isto não foi bem claro e explicito não haverá avanço.

3) Por outro lado um processo brilhante não garante bom código nem boa programação.

O exemplo mais próximo que tenho é o das certificações ISO. A ISO 9001 que as empresas adoram apenas certifica o processoe não o produto. A ISO 20000 que faz isso. Mas veja-se quantas empresas têm iso 20000 e quantas têm e publicitam a iso 9000
Em software é a mesma coisa, a empresa procura um CMMI nivel 5 (que seria equivalente à iso 9001) mas não em ter um bom produto de software.

Tendo a empresa iso 20000 ou não existe o procom para me queixar do produto e da empresa. Mas um cara que compra um softwware queixa-se a quem ? Aliás nos EUA todos vêm como uma licença que exime o produtor de qualquer problema que software cause...

JavaBaby Membro desde: 11/11/2009 09:56:06 Mensagens: 98 Offline

ViniGodoy wrote:Eu sou totalmente contra uma regulamentação na área de informática, a menos que ela siga as diretrizes da SBC, que regulamenta oficialmente que todos podem praticar a profissão.

É melhor investir em Tanque de Guerra que em Educação.

Pelos seguintes motivos:

a) Processos em informática mudam muito rápido, e garantem muito pouca coisa. Diferente da engenharia civil, nossos processos ainda são imaturos, e dão poucas garantias. Fora que montar o software, mesmo depois de um processo definido, não é uma tarefa mecânica. O custo para deixar uma solução livre de erros é astronômico, e a burocracia dificilmente acompanharia a agilidade da área;

Nem UML as pessoas sabem lidar ainda

b) Programadores medíocres vão continuar existindo, mesmo que cursem uma faculdade;
c) Software de risco geralmente está associado a engenharia, que tem regulamentação própria. Por exemplo, todos os softwares já citados nesse tópico (aviões, sistemas médicos, etc);
d) Pisos salariais geram desemprego, ou criam a máfia de assinaturas. Não é possível para um governo tornar um salário artificialmente alto.
e) A área é super ampla, acho difícil fazer uma avaliação profissional genérica.

Enquanto a Economia do Brasil estiver em níveis como os da Africa não se pode esperar muito.

Agora, sou a favor de mecanismos de certificação mais eficientes. Não seria bacana um "Poscomp" com foco em mercado? Uma prova bem feita certamente tem mais valor percebido que uma lei e valoriza o profissional de qualidade. Como é o caso de algumas certificações de renome, como a da Cisco.

Isso ai é um Marketing febril e medíocre uma ração para Países mesmo de 5º Mundo, ou investi em educação ou vamos ficar a mercê dessa industria de golpistas.

sergiotaborda wrote:Esse tipo de prática e postura é inaceitável.

Pessoas com ideias como essas deveriam ser expostas como fraude profissional. É o mesmo nivel de um médico violentar uma paciente ou um cozinheiro mijar na soupa. Eu coloco à votação do todos se acham ético que o nome dessas pessoas e empresa que as mantém no cargo seja divulgado.

Não podemos continuar aceitando esse tipo de coisa. Isso não é apenas um detrimento à nossa profissão , mas a todos os profissionais e à inteligência e cultura humana como um todo.

Concordo plenamente com isso.

Depois de fracassado o projeto, a culpa ainda vai ser dos caras novos e se duvidar o dinossauros vão fazer parecer que a linguagem nova "não serve" ou não atende as necessidades da empresa.

Isso polui o mercado, estimula más práticas, deprime os profissionais e acarreta mais um sem fim de estragos.

Não sei até quando as pessoas vão continuar acreditando em histórias bonitas contadas por RHs, no momento de uma contratação. Todo mundo aqui já viveu milhões de histórias absurdas no trabalho, eu vivi um monte e já contei várias aqui.

Não li todas as mensagens até aqui, mas concordo com os que falaram para você sair desse lugar. Obviamente, quem deve decidir isso é você. Como você mesmo falou, existem pontos positivos em estar nesse lugar, então, enquanto isso for vantajoso para você, segure a onda e vá em frente. Na hora que não for mais vantajoso, saia do lugar. Coloque tudo numa balança e decida.

A pior coisa que existe é ver alguém aceitando se submeter a uma situação incômoda, seja ela causada por repressão/intimidação, por atraso tecnológico, por forma de pensar da empresa etc, chorar rios por causa disso, mas não tomar uma atitude para mudar. Se aceitar, não chore. Se não aceitar, mude.

Entendo que esse assunto leva a temas muito profundos e está enraizado na nossa cultura. Somos submissos por padrão. Esse nosso péssimo costume tem origem na nossa história, por isso talvez é que se veja tantos casos desse tipo por aí, tantas histórias tristes relacionadas a trabalho.

Nesse ponto, eu tendo a ter a mesma opinião do Sérgio Taborda, mesmo que em alguns momentos pareça ser bem radical. Não acho que isso seja errado. Na verdade, eu costumo dizer que problemas absurdos se resolvem com soluções absurdas.

Não vou me estender muito, mas, acho que o que eu posso dizer para ajudar é:

- Não aceitem situações de submissão, em hipótese alguma, em contexto nenhum. O único que sai perdendo com isso é quem aceita.

- Tentem entender o limite da responsabilidade do(s) chefe(s) e a partir de onde começa a sua. Isso é realmente muito sutil e muito difícil de perceber, mas é um prato cheio para gestores mau intencionados (ou muitas vezes sem noção) repassarem suas responsabilidades para as camadas de baixo, afinal, é mais fácil culpar quem está embaixo na hierarquia.

- Tomem suas precauções para poderem ditar o ritmo e os rumos das suas próprias vidas, para não precisarem correr risco de se verem obrigados a aceitar situações de submissão. Isso inclui, por exemplo, reserva financeira. Façam reserva financeira, imediatamente!

E não se esqueçam: um dia nós seremos os dinossauros. Um dia vamos estar com 20, 30 anos de TI nas costas e um bando de moleques cheios de idéias revolucionárias vai aparecer para mudar a forma como fazemos as coisas. Coloquem-se no lugar dos dinossauros de hoje, somente por um momento.

Não, não estou querendo defender esses dinossauros. Realmente existem muitas pessoas que ficaram presas à práticas ruins do passado, mas isso tudo é inevitável. Isso faz parte da evolução da área e tinha que acontecer assim. Talvez nós mesmos não iremos passar por isso, por já estarmos numa fase da evolução da computação que favorece a busca por boas práticas, mas nem todo mundo é assim. Não sabemos o que vai acontecer no futuro. Então, não acho legal criticarmos o que não conhecemos. Como o Kenobi falou, saia do jogo ou parta para a briga, mas tentando evangelizar ao invés de tentar empurrar goela abaixo.

Notícias, artigos e o maior fórum brasileiro sobre Java