APinfo - Forum


Por que os projetos de TI atrasam ?



26/04/07, 16:49:52: Antonio antoniomcruz@terra.com.br - IP : 200.169.221****
    A maior causa de atraso é um fenomeno chamado "SCOPE CREEP". É quando no decorrer do projeto, quando o cliente começa a ver o resultado, ela fala: "Não era bem isso que eu queria", ou seja houve falta de entendimento do Escopo. Pode ocorrer também por mudança no negócio do cliente (Business Scope Creep) ou mudança de tecnologia (Technology Scope Creep).


26/04/07, 15:18:11: jdaniel daniel_joao@hotmail.com - IP : 200.182.214****
    As causas que mais contribuem para atrasos em projeto de qualquer natureza são escopo e análise de riscos mal feitas:

    Como em TI escopo é a coisa mais dfícil de definir, o eterno "não foi bem isto que pedi" vai acontecer quando a aplicação estiver pronta e não produzir o efeito que o cliente acreditava que produziria.

    Deveríamos gastar mais tempo definindo escopo e menos tempo escrevendo código.

    Sendo escopo base para identificação de risco em projeto, sabendo quen não conseguimos definir escopo, análise de risco fica para outra discussão...

    Abraços


26/04/07, 11:21:46: antonio antonio.cruz@terra.com.br - IP : 200.169.221****
    Pessoal, Achei interessante o texto abaixo. Se quizerem o texto completo posso enviar por email.

    Texto escrito por um brasileiro que vive na Europa e trabalha em uma empresa sueca.

    "Já vai para 18 anos que estou aqui, uma empresa sueca. Trabalhar com eles é uma convivência, no mínimo, interessante.

    Qualquer projeto aqui demora 2 anos para se concretizar, mesmo que a idéia seja brilhante e simples. É regra. Então, nos processos globais, nós (brasileiros americanos , australianos, asiáticos) ficamos aflitos por resultados imediatos, uma ansiedade generalizada. Porém, nosso senso de urgência não surte qualquer efeito neste prazo.

    Os suecos discutem, discutem, fazem "n" reuniões, ponderações. E trabalham num esquema bem mais "slow down". O pior é constatar que, no final, acaba sempre dando certo no tempo deles com a maturidade da tecnologia e da necessidade : bem pouco se perde aqui.


26/04/07, 09:22:03: Alexandre - IP : 200.233.5****
    Por que o cliente sempre exige a conclusão do projeto em um prazo inferior ao possível. Mas a culpa não é do CLIENTE, a culpa são das CONSULTORIAS que para pegarem o projeto aceitam o prazo exigido pelo cliente pois sabem q depois quando atrasar o CLIENTE não vai ter mais outra escolha.

25/04/07, 20:28:28: cpuvirtual cpuvirtual@hotmail.com - IP : 201.26.5****
    Por que será que os projetos de T.I. atrasam ? 1-Toda organização se divide em 4 partes a saber : -Planejamento -Direção -Ordem -Controle

    Todos esses elementos possuem valores a serem computados no valor do projeto e nenhuma "METODOLOGIA" e nenhum profissional sério podem mudar isso.Qualquer coisa fora disso é delírio...

    Planejamento

    Qual é a cultura do cliente a respeito do que se pretende ?

    Se o cliente não possui O&M consistente, então as chances do projeto atrasar serão enormes, as necessidades a curto, médio e longo prazo devem ser claras e entendidas.

    Direção

    Quem terá poder para dirigir o projeto sobre o controle das informações da empresa?

    Uma empresa externa e nosso depto de O&M ?

    Ordem

    No início foi a palavra, então a palavra se fez ordem, sem o CRONOGRAMA DE ATIVIDADES de primeiro e de segundo plano não existe ações bem executadas, onde estão inscritas as especificações do projeto ? A adminstração dos recursos as vezes requer que determinadas operações fiquem devidamente empilhadas !

    Controle

    As tarefas estão dentro dos prazos ? Claro que não, o "hardware" atrasou tudo ! Pensamos nisto ?

    A execução do projeto está atrasada ?

    Temos um incidente que mostra claramente que os princípios da organização não foram seguidos, diretores que estão perdendo o foco do comportamento do cliente, gerentes estão administrando conflitos de projeto e de organização que não estão claros na definição das novas politicas de adminstração da informação e dos "poderes da ORGANIZAÇÃO" que serão reformulados para que sejam alcançados os resultados previstos inicialmente.

    Quanto demorei para colaborar com minha opinião ?

    Demorei exatamente o tempo de todas as opiniões antes da minha...

    Todos os projetos de T.I. começam atrasados !


25/04/07, 16:40:07: Christian Casza miniero@aunit.com.br - IP : 200.142.7****
    Gerência e tecnologia parecem não saberem caminhar juntos com harmonia. Os projetos normalmente são aprovados apenas após longos períodos de gavetas e discussões inúteis (descrito nos próximos parágrafos).

    Normalmente diretores e gerentes não possuem uma visão crítica adequada em relação à área de TI da empresa. Isso leva a fatos infelizmente comuns como não entender a necessidade que existirá, descartar opiniões técnicas e negligenciar solicitações de fundos para essa área.

    Dessa forma, sem levar em considerações opiniões técnicas, a gerência e a direção nem ao menos têm noção do prazo que a área técnica definiria para a conclusão de um projeto X. E, para complicar, a área técnica fica sabendo do projeto apenas quando este já é uma necessidade real e urgente.

    Ou seja, a maioria dos projetos de TI já começam atrasados. O motivo? É simples: infelizmente brasileiro só é comunicativo para assuntos fúteis (entenda-se: novela, futebol, reality shows etc).

    Obs.: vale a pena lembrar que estou citando um caso muito comum que muito me entristece. Grande parte dos projetos também se atrasam pelo simples fato da quarteirização (empresas de RH e consultorias não saberem selecionar profissionais na área de TI gera grandes atrasos), outros projetos acabam crescendo (normalmente por necessidade de melhores práticas) e outros são simplesmente executados por profissionais desqualificados (fato infelizmente muito comum no Brasil).


25/04/07, 16:39:46: cwlo - IP : 200.142.12****
    os projetos de TI atrasam para que a Apinfo continue cheia de vagas "urgentes" de "início imediato".....

    brincadeira à parte, essa desorganização dos projetos de TI de certa forma é o que movimenta a área... é isso que faz com que os clientes estejam o tempo todo fazendo seus projetos, as consultorias alocando mão-de-obra, e por aí vai....

    se tivéssemos o "nirvana" e os projetos fossem feitos com um mínimo de erros, as empresas implantariam seus sistemas/infra-estrutura e ficariam com os mesmos durante anos a fio, sem precisar refazer tudo a cada troca de diretoria ou atualização de versão do Windows ou da linguagem de programação.....

    se os projetos de TI fossem tão bem-feitos quanto manda as metodologias, onde trabalhariam todos os estagiários e juniores que as consultorias alocam como "plenos" ou "seniores" ? O "sonho" de uma área de TI organizada e regulamentada, de certa forma é um tiro no pé porque acabaria com grande parte da dinâmica que existe hoje. Ninguém poderia, por ex, ser "autodidata" e trabalhar uma parte de carreira com uma linguagem de programação e depois migrar a carreira para uma outra linguagem. Eu mesmo trabalhei com Visual Basic uns 3 anos antes de fazer meu primeiro curso de VB : eu deveria ser "exterminado" da área por causa disso ?....

    Se vendedor desse um prazo para o projeto conforme queria o analista de sistemas, provavelmente não seria necessária aquela equipe de 20 programadores alocados pelo bodyshop, e também a empresa só iria receber pelo projeto quando o projeto acabasse, naquele prazo que o analista de sistemas definiu...


25/04/07, 15:20:02: Fernando tifernando@yahoo.com.br - IP : 201.42.****
    Atrasam por que os prazos são muito curto.


25/04/07, 10:00:55: Mauricio W. mwaldige@hotmail.com - IP : 200.242****
    Quem pode mais ? O Poder do Capital ou a Exatidão da TI ?

    Será que existe este embate ? Ou será que os Capital e TI são aliados, assim como Poder e Exatidão também ?

    Será que os Projetos de TI atrasam ou, como eu já disse lá embaixo, apenas esticam-se ?

    Ora essa, vamos parar com esse Stress de projeto atrasado, vamos pensar diferente, vamos pensar que projetos de TI esticam-se !!!...assim ó:

    Haverá sempre um projeto, que será apenas uma referência do que será construído, durante a construção muita coisa vai mudar porque ninguém nunca foi capaz, e nem será, de projetar sistemas de informação com a mesma precisão que projeta-se prédios ou máquinas, e mesmo que invente-se métodos para isso, compensa mais não usá-los.

    Nessa linha de raciocínio, vale o que um nobre colega disse num post lá embaixo: "A área de TI é muito mais relacionamento do que técnica". Sim, porque como projetos de TI esticam-se mesmo, o importante é gerenciar isso com menos Stress possível, fazendo o cliente (Capital) assumir o risco e o ônus disso, e deixar a TI (Trabalho) trabalhar.


25/04/07, 09:53:53: Oswaldo Simões osfilho@prservicos.com.br - IP : 200.220.18****
    Há quase 10 anos atuando na coordenação e gestão de projetos, utilizando todos os tipos de ferramentas, e processos de Certificação e Controle, tenho insistido muito que os atrasos são criados desde o início do Projeto, até a sua conclusão. Há uma completa falta de comprometimento do Cliente (que necessita da solução), quanto das equipes de análise funcional e desenvolvimento, quanto das empresas de consultoria, que visam exclusivamente a rentabilidade dos projetos, minimizando os custos justo onde não deviam, no custo dos profissionais alocados no projeto. Moral da história: quem administra mal e paga mal terá de fazê-lo de novo.


25/04/07, 01:05:36: Paulo César paulo.cf@ig.com.br - IP : 201.16.2****
    Amigos.

    Sou coordenador de projetos, e por todos os clientes que passo, por mais que se tente colocar ordem na casa, o cliente sempre acha que tem razão, e o jeito dele, e as prioridades dele são sempre mais prioritárias!. o mais importante para se seguir o schedule de um projeto fielmente, fazer com que o seu cliente entenda primeiramente, que quem dá as cartas é vocÊ! Sucessos

    Paulo César Coordenador de Projetos / Analista de negócios BI / Web


24/04/07, 16:40:56: Eu - IP : 200.162.121****
    Pq o pessoal de vendas pinta de ouro o projeto, dá prazos bons PRO CLIENTE, vende, embolsa os porcentos deles, joga a bomba na mão da equipe de desenv, e vai embora vender outro projeto no mesmo esquema.

24/04/07, 13:48:37: Artur Clemente arturclemente@clubegp.com.br - IP : 201.29.9****
    Amigos o atraso de um projeto tem-se a vários fatos correlacionados. Como assim Artur? O projeto e composto de módulos que se unem para realização de um projeto. O projeto depende até da política da empresa que estamos atuando. Por isso quando realizamos um projeto precisamos primeiramente desenvolver o escopo de modo que atenda as necessidades da solução e da política da empresa.. Mas não paramos por aí, precisamos nos preocupar com o Tempo, Custo, Qualidade, Recurso humano que pouco se preocupam na qualidade desses profissionais, Comunicação, Calcularem o Risco, o gerente precisar ter habilidade para gerenciar conflitos Por isso um bom conhecimento de gerenciamento de projetos é importante, não só ter uma certificação, mas saber como fazer e viver com a pressão, pois não existe projeto fácil.

24/04/07, 13:09:02: Ricardo Assis ricardo@thcs.com.br - IP : 200.168.15****
    Geralmente os projetos atrasam pois os prazos estipulados para o seu termino sao extremamente pequenos visto o contexto do mesmo. Mesmo com planejamento e metodologia a ser aplicada, devido um projeto ser sempre uma caixa preta e nem sempre quem estipulou o seu escopo esta totalmente confortavel, ou seja, sempre tem surpresa por ai. Portanto para minimizar este problema e preciso a aplicaçao de ferramentas adequadas de gestao porem como vimos nao resolve o problema por inteiro.

24/04/07, 12:30:44: Rodrigo - IP : 200.231.17****
    Os projetos de TI atrasam devido ao despreparo tanto do pessoal de tecnologia como dos clientes. Normalmente o problema esta na concepção do projeto, mais exatamente na parte de planejamento. Nesta etapa deve-se definir o escopo e os requisitos necessários e nesse momento sem a aplicação de uma metodologia ocasionam-se problemas futuros. Creio que a disciplina de gestão de projetos vem nos ajudar nesse problema.

24/04/07, 11:14:56: Leonardo leonardo@mindsnest.com.br - IP : 200.162.121****
    Por vários fatores. - Clientes não são educados, pra eles o sobrinho hacker pode fazer qquer coisa mais rápido e barato; - Clientes acham tudo fácil, e não fornecem o que é pedido; - Empregadores querem sempre pegar a mão de obra mais barata para maximizar os próprios lucros; - Competência é confundida com arrogância e vice versa; - O cliente nao sabe ouvir "não"; - O empregador não sabe dizer "não"; - Quem promete e não cumpre ao invés de ser punido, ganha um tempo e dinheiro extras, e quem prometeu no tempo certo não arruma clientes;

    e por aí vai...


24/04/07, 10:19:00: José Luiz - IP : 200.100.21****
    Falta de qualificação, experiência, planejamento e o principal: comunicação

24/04/07, 09:12:25: Tiago Schraiber tiagoau@gmail.com - IP : 200.138.21****
    Em um nível mais filosófico, os projetos de TI atrasam porque a sociedade não está preparada para a ciência da computação, que possui poucas decadas. O processo de amadurecimento será árduo e tudo que vocês relataram faz parte desta evolução.

24/04/07, 08:34:56: Furukawa - IP : 200.162.52****
    Existe dois jeitos de se executar um projeto em TI. O jeito certo e o jeito rápido.


22/04/07, 22:42:21: Vingador - IP : 201.21.1****
    As empresas não querem gastar e só contratam gente meia-boca. Estou cansado de ver isso. Tem muito recém formado fazendo trabalho de analista pleno e daí a receita para o desastre. Já vi isso em dois projetos que foram para o buraco. Outra coisa são uns gerentes idiotas que acha que sabem de tudo e demitem e contratam como bem querem. Tb é receita para o desastre.

    No final das contas isso não faz diferença, pois o que importa e que role uma grana para as consultorias e para os chefinhos....


22/04/07, 20:19:47: Marcelo - IP : 200.206.218****
    Porque senao nao rola grana!!

22/04/07, 02:10:31: Marcelo Queiroz krizard@gmail.com - IP : 200.153.131****
    Senhores, na empresa onde trabalho isso ocorre muito pouco, porem o overtime e absurdo. A maior causa seria uma divisão incorreta das atividades e pouco monitorada, a qual deveria ser distribuída pelo índice de acerto de cada profissional e que cada superior se responsabilizar e monitorar os erros de seus profissionais (pois é ele seleciona os profissionais). Uma estimativa boa e fácil de se aplicar é a APF e a utilização de algumas pratica de metodologias (por exemplo, RUP) resolve este problema. Também não ser esqueça que fazer tudo que o cliente quer só serve para vender e não para concluir o projeto com sucesso e a pós-venda esta em um projeto funcional e estável.

21/04/07, 17:10:43: Erivelton eopaes@yahoo.com.br - IP : 201.74.15****
    São diversos fatores: 1.O fato da profissão não ser regulamentada tras ao mercado muitas pessoas despreparadas e que só aumentam a complexidade do problema. 2.Em muitas empresas quem faz análise de requisitos não tem conhecimento suficiente para captar os requisitos do projeto. 3.Faltam pessoas com capacidade de articulação maior na negocioção dos prazos e para não perder o negócio fazem cronogramas fora da realidade.


21/04/07, 15:19:55: Antonio antoniomcruz@terra.com.br - IP : 200.148.125****
    O Vitor tem razão. Quanto mais realista são as previsões menos competitivas elas se tornam no mercado.

    O barato sai caro. O menor prazo e menor custo nem sempre são as melhores opçoes.


21/04/07, 12:44:20: Victor Sardinha jsardinha@hotmail.com - IP : 200.158.****
    O fato simples é que os planejamentos geram cronogramas estaticos enquanto a realidade é dinâmica.

    Sempre existem gargalos nos processos que resultam atrasos.

    Deve se levar em consideração a teoria das restrições ao se planejar qualquer projeto.

    O problema é que quanto mais realista foram as previsões menos competitivas eles se tornam no mercado.

    E o resultado final é que o comercial vende o mais barato e depois os gerentes de projetos tem que fazer o milagre de vender o restante da realidade.


21/04/07, 11:16:15: Vitor Almeida vitoralmeidasilva@yahoo.com.br - IP : 201.13.208****
    Os dois principais problemas: falta de comunicação com os clientes (levando os profissionais a desenvolverem soluções que eles não conhecem 100%) e inflexibilidade de prazos (que não será realista baseado no conhecimento do negócio que eles tem).

21/04/07, 11:04:59: Fabiano fabiano_asouza@hotmail.com - IP : 201.42.****
    Senhores; O fato é que cada vez mais as escolas e faculdades formam pessoas incapazes de gerir qualquer projeto, seja ele qual for. A lógica não se estende somente a programação, ela dever ser estendida a projetos, a vida. Os contratantes nunca sabem o que almejam, o projetitsta geralmente é algum almofadinha recém formado que não tem conhecimento prático nenhum, e como todos sabemos, a teoria na prática é outra. Levando em conta tal situação é sabido que os projetos em sua grande maioria não atrasa pela indisponibilidade financeira ou pela falta de materiais, mas sim pela indisponibilidade técnica de quem o desenvolve.

21/04/07, 10:02:13: Ana Maria - IP : 200.126.209****
    Fazia tempos que não via um fórum com tanto consenso.

    Já que o problema esta bem definido, poderíamos partir para a próxima etapa. O que pode ser feito para soluciona-lo ? Sera que existe alguma saída viável, que não passe por metodologias e processos complexos que acabam não sendo possíveis de seguir no mundo real ?

    Acredito que os usuários possuem pouca confiança nos profissionais de TI, em relação aos prazos dos projetos, isto faz com que eles coloquem os prazos cada vez menores, na esperança de que no final a solução fique pronta no tempo correto. Acaba virando uma bola de neve.

    Uma solução possível é negociar o prazo inicial do projeto com bastante folga, isto com certeza vai ser difícil, mas sera menos desgastante do que ficar adiando o projeto várias vezes ao longo do desenvolvimento. mas neste caso é fundamental cumprir o prazo original.

    Trabalho em uma empresa onde TI não é terceirizado e os problemas de atraso também são frequentes....


19/04/07, 22:58:04: Silvio Teixeira - IP : 201.20.21****
    Simplesmente por dois fatores:

    Falta de Comunicação Escopo Aberto


19/04/07, 19:55:48: Alexandre alexandre@gmail.com - IP : 201.29.123****
    Alguém aqui já trabalhou no Brasil com projetos definidos e bem projetados ??? Projetos no Brasil é igual Branca de Neve, Papai Noel, tudo lenda.

19/04/07, 17:01:31: Márcio marcioper@hotmail.com - IP : 200.168.175****
    Motivos de atraso. 1- O levantamento lógico, o negócio, o entendimento, não estão totalmente concluídos ou o cliente dificulta e retem as informações cruciais para o sucesso do projeto lógico. Na homologação do projeto lógico aparecem vários quisitos não levantados ou incompletos causando atrasos e comprometendo o cronograma. 2- O projeto físico depende de um lógico bem elaborado e a equipe de desenvolvimento e o gerente do projeto devem ser profissionais qualificados para o total sucesso da homologação e implantação do físico. Prometer profissionais qualificados ao cliente e depois colocar profissionais em formação no desenvolvimento, obviamente vai comprometer na qualidade e haverá atraso na entrega do projeto de TI. A negociação dos prazos é fundamental diante do cliente, pois se houver um dos problemas acima, compromete a credibilidade e haverá desgaste no final na renegociando prazos. Eu, prezo muito pela qualidade dos serviços e o prazo negociado e estabelecido em cronograma MS Project deve ser cumprido cada atividade com muito comprometimento. Os desvios ñunca devem ultrapassar 10 %.

19/04/07, 07:57:57: MarceloLiberato liberatoesouza@yahoo.com.br - IP : 201.88.74****
    Porque não há estudo de contexto o que compromente o planejamento!

18/04/07, 16:22:46: George - IP : 201.17.146****
    Porque fomos colonizados pelos USA e implicitamente buscamos uma vida como a deles, fast-food!

    ou

    Porque falta bons negociadores de prazos.


18/04/07, 14:10:32: Marco kaishaku@hotmail.com - IP : 201.52.****
    1) Cliente que não sabe o que quer, criando muitos retrabalhos; 2) Equipe de desenvolvimento que não cria builds diários, tornando difícil saber a expectativa que o cliente tem do produto; 3) Não saber priorizar atividades de ambas as partes; 4) Falta de comunicação.

18/04/07, 13:14:48: Caio caiomsilveira@gmail.com - IP : 200.209.8****
    Um dos vários motivos para que isso aconteça é o inicio do projeto sem conhecimento de todo o processo do cliente, sem regras de negocio bem definidas e sem certeza de 90% das regras definidas que muitas vezes ao final do projeto tem-se alterações que saem bem mais caras e com um tempo de produção maior, pois a equipe que começou a desenvolver o projeto já está desmotivada por ter feito algo que será inutil ou que será alterado em 80 ou 90% do seu conteúdo. Não podemos esquecer que a equipe é quem produz, se ela está motivada(de diversas maneiras como um simples elogio ao seu trabalho) a sua produtividade aumenta e o erro quanto aos prazos podem diminuirem ou até mesmo não existirem.

    Concordo em diversos pontos com Mateus Velloso nesse artigo que fala bastante sobre a equipe https://www.linhadecodigo.com.br/artigos.asp?id_ac=1262&pag=1



18/04/07, 12:47:37: Anderson Siq - IP : 200.220.156****
    Trabalho em TI e faço a gestão de projetos. Este problema de atraso têm várias causas: uma que as empresas em sua maioria trabalham de forma imediatista, sejam elas consultorias ou mesmo aquelas que desenvolvem internamente. Muitas, simplesmente desprezam a fase de planejamento, que em projetos é a sustentação de qualquer projeto, pois é dela que nas ce as tarefas a serem executadas e destas o prazo de início e fim dos projetos. Concorrente a isso, gerentes que estão muitas vezes distantes do dia a dia, e acham que tudo é simples, parece que passam a ter a visão do usuário, reduzindo os prazos (isso dá parta fazer em 2 horas, eram 8!). A visão dos outros departamentos que TI faz tudo, resolve tudo e que os problemas são todos resolvidos por ela. Falta uma visão do todo, ou seja, uma determinada alteração ou implementação nasce onde, vai para onde e até onde vai impactar, e isso acaba gerando surpresas durante os desenvolvimento e sérios impactos. O assunto é longo, mas por amostragem, acredito que isso é um problema que não será resolvido tão cedo. Não porque não temos conhecimento, mas sim por falta de vontade. Sendo assim, para que fazer faculdade, pós, cursos diversos, se niguém quer usar metodologia alguma...

17/04/07, 23:43:40: Paulo Augusto - IP : 201.52.57****
    Falta competência!

17/04/07, 22:55:14: Byron S.Júnior - IP : 200.148.9****
    Continuação ...... Em TI é normal recomendarem que abreviem o tempo de planejamento, especificação, regras de negócio, etc. Muitas vezes quando começa o trabalho o Contratante já definiu a data da implantação, as vezes uma data heróica, sem nenhum embasamento. É quando come;ca a pressão pra fazer o prédio a partir do 5. andar. Os Planejadores dizem que agora é só fazer pois já planejaram tudo, sabem todos os detalhes, etc. As vezes o Contratante tem uma visão miope dos processos e não considera dados importantes no planejamento. É comum a equipe que faz o trabalho (Consultoria) não ter participado do planejamento das etapas, mas ficam com a incumbência de levar a culpa. Começar um prédio pelo 5. andar é um dos motivos do atraso.

17/04/07, 22:33:53: Byron S. Júnior - IP : 200.148.9****
    Não existe um motivo único para os atrasos, mas sim um conjunto de motivos. Vou utilizar exemplo figurado pra explicar um deles.

    Ninguém começa a construir um prédio pelo 5. andar. Primeiro tem que fazer a base, depois o térreo, depois o 1. andar, o segundo, terceiro e assim por diante, até chegar no telhado.

    Só que antes tem que fazer uma planta com as instalações, hidráulica, eletricidade, ventilação, etc. (já ouviu falar em especificação do projeto, protótipo, regras de negócio, modelagens, etc.?). O responsável prevê alguns dias de chuva, neblina, atraso na entrega de cimento, alumínio, etc., ou seja, situações que podem comprometer a entrega e aí então define-se uma data de entrega do prédio.

    Uma coisa importante, quem planeja a construção não aceita imposições de quem não é do ramo. Continua ......................


17/04/07, 20:38:54: Marcelo - IP : 200.206.218****
    Porque na area de TI tem dois tipos de pessoas os idiotas e os espertos

17/04/07, 16:56:19: wilson prates - IP : 201.92.230****
    Os projetos atrasam pela falta de planejamento e despreparo dos idealizadores e executores. Na minha opiniao para melhorar o nivel dos profissionais a profisao deveria ser regulamentada e desta forma deveria haver exame como ocorre com os advogados. O poscomp seria um bom exame para avaliar se o profissional tem ou nao condicoes de exercer a profissao

17/04/07, 16:01:25: Rafael Rocha - IP : 201.63.16****
    Na minha opinião:

    Causa 1 - O cliente não entende de tecnologia e as muitas vezes nem de seu próprio negócio.

    Causa 2 - A empresa de TI que presta o serviço não conhece nada do negócio do cliente (alias nem de negócio, gestão e administração) e muitas vezes nem de tecnologia.

    Causa 3 - Não existe regulamentação da área.

    Moral da estória, ambos não falam a mesma língua, os clientes parecem que usam tecnologia por modismo e as empresas de TI parecem mercenárias, e o governo só diverte com a zona do setor.


17/04/07, 13:04:16: Luciana Braga - IP : 200.98.66****
    Caros, No meu ponto de vista os projetos atrasam pela falta de clareza no escopo, ou seja o escopo não é bem definido e isso com certeza afetará no prazo. É necessário ter pessoas capacitadas para definir bem o escopo, pois ele é o passo principal para que o projeto seja realizado dentro do desejado e se houver alteração do mesmo é necessário deixar bem claro para o cliente que acarretará em um novo prazo e custo, nunca deixe de avisar o cliente que possíveis alterações serão implicadas no projeto.E se for uma alteração muito extensa é melhor fazer um novo projeto ao invés de alterar o escopo. o importante é fazer um projeto dentro do escopo,prazo,custo e qualidade esperado pelo cliente.

17/04/07, 12:38:14: Mauricio W. mwaldige@hotmail.com - IP : 200.99.135****
    Sim, é mesmo, o Carlos tocou num ponto muito mais importante do que metodologia super-eficientes, ou consultorias super-gerenciadoras de projetos, ou gerentes super-capazes de informar-se e de contornar problemas.

    Oras...o ponto principal em desenvolvimento de sistemas, é o super-desenvolvedor. Melhor ainda do que um super-desenvolvedor, é uma equipe de super-desenvolvedores que consiga trabalhar em harmonia.

    Essas manias de mercado, de siglas, de metodologias, do nomenclaturas em Inglês, não passam de um esforço para banalizar o que realmente é importante: A EFICIÊNCIA TÉCNICA.

    Nada disso funciona sem que haja eficiência técnica. Não há prazo que possa ser cumprido sem eficiência técnica.

    - Ah sim, mas isso é básico, todo mundo tem que ser tecnicamente eficiente.

    - Claro, é básico, mas há pessoas que tem vocação e habilidades para determinadas atividades, há diferenças entre os seres humanos, há atividades que requerem características humanas que são pouco comuns, há características que são mais importantes do que outras em determinadas atividades. Ou alguém aqui supõe que gerenciar um projeto de um "Pacote Turístico" é a mesma coisa do que gerenciar um projeto de software ? Sim, na visão "Roberto Justus" gerenciar projeto é tudo a mesma coisa. Basta saber fazer carinnhas e vozes, ora bonitinha para seduzir, ora bravinha para amedrontar, que o projeto sai.


17/04/07, 11:45:16: Carlos - IP : 200.142.12****
    Um gande motivo para este problema é a quarteirização : 1.profissional 2.consultoria pequena 3.consultoria grande 4.empresa cliente

    Diversas coisas irritam bastante em nosso mercado e justitifica os atrasos em projetos. Mas nada se compara aos anúncios de consultorias pedindo perfil sênior para ganhar mil reais ou especialistas em 10 ferramentas diferentes com 1 ano de experiência. Ou seja, o cara teria que trabalhar em média 1 mês com cada ferramenta solicitada para atender o que se pede na vaga. Tudo isso para as consultorias pequenas conseguirem "recursos" a preços mais "competitivos".

    Na quarteirização, eu entendo que quem se dá melhor são as consultorias pequenas, porque elas não fazem nada, só bodyshop. Elas só tem site de cadastro de currículo, uma salinha, uma recepcionista e networking. São empresas que não agregam nada ao mercado, só servem de intermediário para onerar ainda mais os valores dos projetos, achatar o salário do profissional, e impedir reais possibilidades de trabalho diretamente nas grandes empresas.

    Ninguém liga se o recurso veio da ABC, XYZ, RTS, YHT, RFD consultoria. O que fica mesmo é que se o projeto da IBM, da Accenture, da Telefonica, etc., deu certo ou deu errado. O cliente também não se dá tão bem asim porque ele está sempre gastando dinheiro com TI, fazendo e refazendo, porque ele próprio não sabe o quer e, mesmo quando sabe, dificilmente consegue implantar soluções adequadas.

    Se não trabalhássemos em consultorias com essa visão de "entro hoje, posso sair amanhã", talvez todos, do estagiário ao gerente de projeto, poderiam trabalhar mais focados, sem ter que trabalhar e ao mesmo tempo ficar procurando emprego.


17/04/07, 10:43:15: Antonio - IP : 200.169.221****
    Se não prometer o prazo e o preço que o cliente quer, não vende. É essa a metodologia utilizada pelo depto Comercial e Pré-Venda. Após a definição de prazo e custo, feitos pela pré-venda, é que entra o Gerente de Projeto, com prazo e orçamento curtos. O Gerente de Projeto tenta negociar o escopo com o cliente, baseado no prazo e orçamento que ele tem disponível. Não consegue, porque no contrato, o cliente tem direito a tudo e mais um pouco. (O contrato havia sido muito bem elaborado para convencer o cliente a comprar). O gerente de Projeto constata que não tem tempo, não tem dinheiro e tem que fazer tudo. Se não fizer.... RUA.

    Resultado: Projeto atrasado, orçamento estourado, cliente insatisfeito.


17/04/07, 10:29:02: Eduardo Santos eduardo.henrique@orbitall.com.br - IP : 200.190.7****
    Concordo com todos os amigos que já deram suas opniões e acrescento uma coisa. O gerenciamento de projetos, muitas vezes, está sendo feito por pessoas que entendem de tecnologia e não de projetos. Vejo todos os dias empresas recrutando Gerente de Projetos com forte formação técnica. Chegar à fase de execução de um projeto com um escopo bem definido e um cronograma factível não é coisa fácil. Os interesses são muitos e precisam ser negociados. Quando você coloca um profissional especialista em TI na posição de Gerente de Projetos ele com certeza vai criar a melhor solução, mas talvez não seja aquela que caiba dentro do prazo e do custo. A empresa que quer contratar ume especialista em alguma tecnologia, harwares ou softwerer para gerenciar um projeto deve certificar-se que essa pessoa também possua transito em todas as camadas da empresa e muito boa penetração e negociação com o cliente, entre outras coisas características que devem ser observadas em um Gerente de Projetos.

17/04/07, 10:04:37: Marcelo - IP : 200.142.1****
    TI hoje em dia e uma area de relacionamento e nao de sistemas ou produtos de software, muits ja me falaram "Cativa o cliente ok". Hj em dia nao somos mais profissionais de sistemas ou produtos e sim de relacionamento. O resto e o de menos!!

17/04/07, 09:41:36: Mauricio W. mwaldige@hotmail.com - IP : 200.99.135****
    Sim, muito oportuna a abordagem do Luiz Cláudio (abaixo) quando disse sobre a frustração dos profissionais de TI, ao confrontar metodologia com o dia a dia de uma TI corporativa.

    Costumo traçar um paralelo com a área de TI que produz sistemas, com a indústria de máquinas, pois em 1985, entes de eu partir para TI, eu era operário especializado e depois fui Técnico em Métodos e Processos de Fabricação em uma grande indústria fabricante de máquinas sob encomenda, especialmente para a indústria automobilística.

    Numa indústria não há essa loucura, ninguém vende uma máquina a ser fabricada sob encomenda dizendo que ela já está pronta, na indústria não há operários e líderes capazes de fabricar a tal máquina pulando etapas de planejamento e projeto.

    Mas em TI ? Alguém é capaz de vender um sistema dizendo ao cliente que será necessário empenho dele para planejamento e projeto ?

    Isso é o que prega a metodologia, mas quem consegue vencer a força do capital, daquele que manda e paga, apenas com idéias bonitas ?

    Metodologia é interesse de quem fabrica, não de quem compra.

    Não é só porque o mercado exige as certificações, que uma empresa que tem quadros pendurados nas paredes aplica metodologia. Pegue o banco de dados e verifique se há um modelo relacional, se as regras de negócio estão ali implementadas...quá-quá-quá...quase nunca.

    Só no banco de dados já dá pra perceber como é a realidade. Se verificarmos a arquitetura de camadas, componentização, orientação a objetos...bom, e melhor parar, isso ainda é um mito sob a ótica da qualidade, mas há discursos muito convincentes.


16/04/07, 21:16:20: Luiz Claudio luiz.rodrigues@clarify.com.br - IP : 201.68.17****
    Nossa realidade de TI mostra que a maioria dos profissionais que trabalham nos projetos não tem conhecimento sobre gestão de projetos sob a ótica de uma metodologia, por isso a probabilidade da geração de retrabalhos em diversas etapas do projeto são uma constante, aliados ainda a ineficiência dos processos de levantamento, definição e validação das especificações, ministro curso sobre gestão de projetos e percebo a frustação dos profissionais da nossa área quando confrontam uma metodologia contra o dia a dia de uma TI corporativa.

16/04/07, 20:25:44: Mauricio W. mwaldige@hotmail.com - IP : 200.99.135****
    Na verdade deveríamos dizer que os projetos de TI esticam-se, ao invés de atrasam, porque as pessoas não conseguem abstrair com a precisão desejada, ou seja, o usuário nunca sabe bem o que quer, o analista não consegue especificar com precisão, e o sistema construído fica sempre diferente do esperado.

    Isso é assim mesmo. Todo mundo erra, todo mundo vai errar.

    A questão é conseguir errar menos e conseguir fazer o cliente assumir os riscos e o ônus dos erros.

    Por que não há tanto erros na indústria de máquinas ou de navios ?

    Porque para transoformar aço em produto, os métodos de levantamento, projeto e construção são seguidos rigorosamente. As pessoas envolvidas aceitam gastar muito tempo planejando e projetando, ninguém sai construindo nada que não esteja projetado porque simplesmente não dá, um soldador não vai emendar um pedaço de ferro se não estiver no desenho, porque um operário especializado segue métodos de trabalho e não se faz gambiarra e ponto final.

    Em TI é tudo abstrato...do abstrato passa para o volátil e daí ao relaxo.

    Vejam só, para que serve PK-FK para um programador C ou Java ? Pra nada !!!

    Para que serve o DBA para o gestor do projeto sem a menor noção técnica ? Pra nada !!!

    Nesse linha de raciocínio as coisas vão acontecendo, e os projetos esticando.

    Aí vem o pessoal da metodologia e qualidade, que também não sabe o que é PK-FK !!!... Vão mudar as siglas e nomenclaturas e os problemas vão continuar os mesmos.

    E TODO MUNDO PEGA ESTICA E PUXA...E VIVA A TURMA DA XUXA !!!


16/04/07, 16:23:39: Shyn rubens_shyn@yahoo.com.br - IP : 201.52.24****
    Acho válida todas as opiniões mas, o que tem me chamado muito a atenção quando verifico as vagas disponíveis para gestores de projeto, em todos os sites, são as inúmeras exigências que as empresas fazem mas, querem pagar um valor que não condiz com as exigências feitas para a função. O que acaba acontecendo? Promovem ou contratam alguém para a função, sem base suficiente, e este profissional tem que "adivinhar" o que está acontecendo. Ou seja, não há planejamento que consiga arrumar estes erros. Fora isso, as diversas interpretações que existem nas empresas contratantes que não fazem a mínima idéia do que é Projeto e do que é Processo! Concordo também com as opiniões que apontam a responsabilidade para quem vende o projeto e sobra para os implantadores "apagarem o incêndio". Porém, com as dificuldades e falta de conhecimento que as empresas têm sobre o que é um Projeto, o pessoal de Vendas pode vender o que quiser, que a empresa compra. Implantar, bom, isto é outra história. Perdi um projeto porque a consultoria contratada como staff do diretor presidente, dizia que eles entendiam muito (ambíguo) de TI e sugeriram uma solução que não entregava o retorno que a empresa precisava. Agora que a empresa voltou a me procurar e tive que refazer a análise, descobrimos que ela precisará gastar 400% em cima do que gastou, para "arrumar a casa"! Resultado: a empresa disse que TI é comoditie e qualquer um faz e não poderia custar tão caro. Minha resposta? Bom, se tivessem verificado que seu staff não entendia nada de TI e tivessem feito um planejamento correto, tudo isto teria sido evitado. Resumo da ópera: eles estão tentando se virar com o que tem.

16/04/07, 12:28:09: Carlos - IP : 200.142.12****
    O comentario abaixo do Fabio ilustra um pouco uma das razões dos projetos em TI darem tanto problema : a falta de unidade dentro da própria área de TI. Se existe "rixa" entre infra-estrutura X desenvolvimento, imaginem então entre gerente X equipe, analista X cliente, fornecedor X fornecedor, área comercial X área de projetos, etc.

    Respeito a indignação do comentário porque realmente existem situações absurdas, mas entendo que a ponderação é o caminho. Eu já vi tanto programador quanto analista de infra olhando para um problema sem ter a menor idéia do que fazer e se dizendo "especialista" no assunto. Isso ocorre principalmente quando a solução para alguma situação demanda pesquisa, e todo mundo já passou por isso.

    Já vivi situações onde a consultoria estressou com o cliente porque a equipe de um projeto não teria internet e eles precisariam acessar o MSDN ou Technet para desenvolver o projeto. Na visão do cliente, se são especialistas, porque eles precisam o tempo todo ficar "procurando" na internet como fazer as coisas ?

    Diante da diversidade de situações como essa, sinceramente, como conseguir estimar um projeto com prazos/recursos realmente seguros ? Como estimar prazos/recursos principalmente quando os projetos buscam utilizar tecnologias "beta" e recém-lançadas, exatamente para não perder a onda ?

    Abraços.......


16/04/07, 11:23:13: edu eduprogramador@terra.com.br - IP : 200.153.68****
    Os projetos atrasam pq infelizmente o cliente não tem cultura que para um projeto de TI eficiente é necessario estudo , analise , elaboraçao e testes. Tente falar para seu cliente que para um determinado projeto vai precisar de 3 meses para estudo de casos e levantamento de dados, mais 1 mes para elaborar o projeto e definir o cronograma e mais 6 meses para desenvolver e 3 para implantar.... Ele simplesmente não vai aprovar o projeto!!! E tb vai achar o custo absurdo.... Então o que todo mundo faz, pede 1 semana pra analise, promete o projeto pra 4 meses e faz em 8 e depois ao inves de 3 meses para implantar leva 6 e deixa o software cheio de bugs para o cliente testar.

16/04/07, 10:58:34: Fabio alves.mc@gmail.com - IP : 200.152.196****
    Eu atuo numa empresa que possui dois lados: O pessoal de projeto, também conhecidos como galáticos e o pessoal de infra, conhecidos como burros de carga! Os galáticos iludem o cliente, prometem mil maravilhas, recebem milhões de prêmios, recebem os maiores salários e nunca atrasam um Go Live, agora adivinhem pq eles entregam o projeto no dia exato? Pq eles têm alguém pra jogar a culpa e é claro que a culpa é sempre da infra. Vejam o seguinte exemplo: O sistema entrou no ar e está lento, resposta dos galáticos: Isso é infra, aciona o pessoal do banco. Aí lá vai os troxas procurarem o que está causando a lentidão e depois de horas se matando, encontramos selects buscando informações em máquinas de desenvolvimento, em localidades diferentes, ué isso é culpa da infra ou do idiota que programou aquilo? Infelizmente a falta de planejamento e conhecimento gera tal situação, o que mais me indigna é a falta de ética no nosso mundo de informática, onde pessoas egoístas esquecem que fazem parte de uma mesma empresa e saem julgando e defamando outras áreas pela pura falta de conhecimento do que eles estão fazendo. Eu estou um pouco indignado, mas não generalizo, temos excelentes profissionais, mas onde trabalho, tenho péssimos desenvolvedores que podemos também chamá-los de Bagres, pois se esquivam de tudo, menos de receber os prêmios e promoções!!

16/04/07, 10:41:19: Neutron - IP : 200.177.101****
    Os bons profissionais e as boas consultorias, usando as ferramentas hoje disponíveis (PMI, ponto de função, etc) sabem estimar quanto tempo leva e quanto custa um projeto. Mas quem tem coragem de apresentar a conta para o cliente?

    É ai que tudo começa a desandar. Pra segurar o cliente, são feitas promessas irreais, cortes de custos, redução de prazo, eliminação de etapas. O resultado é problema na certa!!!

    O cliente sabe disso, mas também tem que ceder a pressões internas por redução de gastos.

    Se a consultoria é durona e não cede a pressão, o cliente fecha com outra, e o projeto atrasa. É sempre assim!!!

    Depois entra a politicagem pra ver de quem é a culpa, e a correria de todo mundo tirando da reta. Alguém já viu esse filme?


16/04/07, 09:03:23: Julio Martins juliomartins@stilrevest.com.br - IP : 201.63.2****
    Na grande verdade as empresas (clientes) enxergam projetos de TI como um conjunto de procedimentos de fácil conclusão, não investem, contam com profissionais mal qualificados, treinados nos módulos dos sistemas utilizados. Por outro lado as empresas gestoras de softwares cobram absurdos por produtos que nem sempre atendem ás expectativas dos clientes e quaisquer implementações geram custos altissimos. Todo este conjunto de problemas acabam gerando resultados nem sempre satisfatórios á ambas as partes que por sua vez culpam-se entre si. Ou seja, para implantarmos algum projeto, sejamos o mais simples possivel e que não tentemos inventar a Roda.

    Julio Martins Analista Sistemas


16/04/07, 08:23:32: Eduardo easouza@oi.com.br - IP : 200.222.105****
    Em geral, os projetos relacionados a área de informática sempre atrasaram. Nos dias de hoje com a terceirização/quarteirização da área os profissionais que são escolhidos para executar a tarefa não possuem conhecimento do negócio da empresa. Além disso, se o projeto envolver outras áreas de atuação, o que sempre ocorre, fica mais difícil ainda. Na minha opinião, antes de se montar um cronograma de um projeto, é necessário um período de levantamento para que se tenho uma idéia, mesmo que em geral do escopo.

16/04/07, 00:23:03: cid cipriano cicpriano@hotmail.com - IP : 200.207.210****
    Pq a área de TI virou uma grande pizzaria. Cliente deseja "Calabreza", oficializa "Milho com muzzarela" comercial entende "meio calabreza e meio milho", gerente de projeto vê que o prazo não é suficiente e propõe: só milho. Especificador define só a Muzzarella e esquece do milho. Analista está sobrecarregado e na pressa sai muzzarella.Gerente dá a ordem rapidinho: Tira a muzzarella e põe calabreza e diz pro cliente: Sai HOJE sem falta!!!

15/04/07, 03:51:01: MAC - IP : 201.26.175****
    è simples... na area de TI o numero de pessoas tecnicas que tenham bom conhecimento de gestãod e projetos é pequeno, ai an hora de gerenciar chama um cara de administração ou qualquer outra area por que ele manja de projetso, mas nao entende nada do Projeto que esta lidando, ai ficam informações desencontradas todos os dias. Sugiro todo mundo sentar a budnma em algum lugar e começar a ler PMBok, pode nao resolver de imediato, mas a médio prazo vai resolvei isso sim

14/04/07, 22:43:12: Marcelo - IP : 200.171.91****
    Porque deixamos sair de nosso controle e toda area de TI desde profissionais ate projetos sao vistos como uma verdadeira baixaria pelos profissionais de TI de fora do pais!!

    abraços


14/04/07, 19:17:30: Alexandre - IP : 201.29.119****
    Na minha visão, todo e qualquer projeto de TI (infra, sistemas, etc...) atrasam por incompetência de todos os envolvidos em definir o escopo do projeto. Como são todos incompetentes, o cliente ou paga muito ou paga pouco e do outro lado acontece o inverso em relação ao recebimento do pagamento. Quando aparece um bom gerente de projetos disponivel no mercado, todos querem pegar o profissional para vicia-lo a entrar no esquema de quanto mais rapido e ganhos mais altos; melhor !!!

14/04/07, 14:37:29: sem nome anonimo@anonimo.com.br - IP : 200.161.11****
    Acredito que o grande culpado é o cliente, que pede para ser enganado. Pressiona ao máximo as consultorias por prazo e preço, mesmo sabendo que é impossível a entrega.

    Se os mesmos clientes colocassem clausulas no contrato para previnir atrasos e demais problema, e acionassem essas clausulas, as consultorias mudariam a forma de trabalhar.Apresentariam projetos mais coerentes.

    Hoje fazem projetos já pensando na renogiação dos mesmos, sabendo que o cliente irá aceitar, apesar do stress.


14/04/07, 12:12:35: Nelson jnguindo@yahoo.com.br - IP : 201.12.136****
    Porque na maior parte das empresas faltam planejamento adequado e pior ainda, o fator pressa e pressão, que acaba avacalhando mais ainda os projetos de TI. Um projeto de TI bem elaborado e bem planejado, com uma equipe extremamente séria e responsável, funcionará perfeitamente.

14/04/07, 11:08:10: marcio marcioduran@terra.com.br - IP : 201.52.9****
    Os projetos de IT atrasam , pelo simples fato das Empresas não saberem definir um Layout de produção para à equipe de trabalho, pior ainda quando o time é liderado pelo gerente da empresa e não da consultoria e ai que tudo termina mesmo.

13/04/07, 15:40:54: Luciana - IP : 200.162.11****
    Porque no momento da venda tudo é possível e tudo o sistema possui, mas depois da analise de necessidades e aderência descobre-se o furo, daí já é tarde.

13/04/07, 02:52:24: Cristiano J. S. - IP : 201.92.21****
    Bom, eu acho que é pela "FALTA DE PROJETO" (Risos) Quando os "Gerentes" de projetos souberem realmente o que estão fazendo, este conceito irá mudar.

13/04/07, 00:19:38: ROBERTO LEMBO lembobet@aclnet.com.br - IP : 201.1.196****
    PORQUE SUBSTITUIEM PRAZOS REAIS POR PRAZOS HERÓICOS: Máquinas trabalham sem parar para cafèzinhos, reuniões e etc. Máquinas sofrem pelas peças. Para as que mais quebram, previsionam estoques para troca imediata. As manutenções, previstas em horas, podem entrar nos cálculos dos prazos, matematicamente, pois, máquinas, não se emocionam. E não trabalham no limite da capacidade. Trabalhei em uma empresa que considerava, para sêses humanos, 6 horas (não 8) como um dia de trabalho: Base de cálculo dos prazos. Por vêzes, havia CORRIDINHAS próximas ao prazo de entrega. Apenas CORRIDINHAS. Não incêndios.

12/04/07, 22:27:05: Alexandre pereirafranco@ig.com.br - IP : 201.69.****
    Alguém conhece bons livros e cursos pertinente ao tema?

    Obrigado


12/04/07, 21:14:01: André Begovacz begovacz@hotmail.com - IP : 200.162.235****
    Os projetos atrasam por muitos motivos... Aliás, qualquer motivo, por menor que seja, se não for devidamente detectado e solucionado em tempo, atrasará o projeto. Pra mim, um dos motivos mais evidentes é que as consultorias prometem ilusões, em tempo recorde, não conseguem (embora tentem) gerenciar expectativas do cliente e mudanças. Tudo isso só para ganhar licitações.... Mal sabem que estão dando tiro no próprio pé! E sim: O usuário final deve participar ativamente do projeto. Toda a equipe de stakeholders, product management e structure deve SIM TER UMA ATENÇÃO ESPECIAL DA PARTE DO FORNECEDOR!!!

12/04/07, 19:28:45: Leopoldo - IP : 200.72.313****
    Gostei bastante da maioria das opiniões, destaco dois pontos :

    O primeiro é que as vezes o usuário precisa de um fusca e nós acabamos criando uma ferrari, o desafio sempre fascina o pessoal de TI...

    Na mesma linha acho que os projetos deveriam atender bem 80% das necessidades dos usuários, os outros 20 %, que são as exceções deveriam ser desenvolvidas em um módulo a parte, ou tratadas até mesmo de forma manual, ou fora do sistema principal. Falo isto porque em todos estes anos de desenvolvimento estou cansado de gastar 80% do projeto cuidando de coisas que um dia podem acontecer... Sei que é politicamente incorreto, mas o ganho que teriamos em tempo de desenvolvimento e custo, certamente seria atrativo para as empresas e os usuários finais.

    Vamos quebrar este paradigma de que os sistemas tem que resolver TODAS as situações.


12/04/07, 16:54:01: Diego Diniz diegodcs@gmail.com - IP : 200.186.15****
    O Chaos Report de 1995, feito pelo Standish Group(www.standishgroup.com - O Relatório pode ser obtido em https://homepages.dcc.ufmg.br/rodolfo/GPS1-Turma11/chaos_report.pdf/ ) ,apontaram que as principais causas desse acontecimento são:

    Falta de Participação do Usuário Requisitos e Especificações Incompletas Requisitos e Especificações Mutantes Falta de Suporte da Gerência Imcompetência Tecnológica Falta de Recursos Expectativas não-realistas Objetivos Não-Claros Divisão do Tempo não realista Novas Tecnologias.

    Pela minha experiência na área, os motivos mais fortes que forçaram os projetos a atrasar foram : Requisitos e Especificações Mutantes e Falta de Participação do Usuário . As metodologias de desenvolvimento que muitas Fábricas de software e consultores utilizam dão margem a que essas coisas aconteçam.E geralmente é difícil se construir algo que não se sabe o que é.


12/04/07, 16:49:32: Renan - IP : 200.241.20****
    São diversos fatores que atrapalham e atrasa os projetos, entre eles estão a falta de conhecimento por parte do próprio cliente que muitas vezes nao enxerga a sua própria necessidade, entao acabam pedindo para incluir novos item e serviços no meio do andamento da elaboração, ou pior, na concepção do produto a ser desenvolvido, isso toma muito tempo pois pode alterar diversos aspectos do software tendo que reve-lo novamente em alguns casos. Ou está realcionado a tbm os negociadores nao ter muita idéia de quanto tempo se leva para desenvolver tal produto, e sempre acaba extrapolando o tempo combinado. Outro fator é o de profissionais cada vez menos comprometido com o trabalho e mais com o dinheiro, é comum profissionais deixarem o projeto no meio e ir trabalhar em outra empresa que forneça condições melhores e salários mais elevados. Acho que esse são alguns dos fatores que atrabalham e atrasão os projetos.

12/04/07, 16:45:23: Eduardo F ceduardodfernandes@gmail.com - IP : 200.185.245****
    Na verdade, a maioria dos projetos atrasam porque as empresas geralmente não tem tempo e nem dinheiro para fazer as coisas do jeito mais rápido e mais barato!

12/04/07, 08:30:59: Fábo Rosato fabiorosato@hotmail.com - IP : 201.63.16****
    Pela minha experiência os atrasos são decorrentes de uma seqüência de erros:

    1) Metodologia de desenvolvimento mal definida e depois mal executada. 2) Especificação dos requisitos ditada pelo cliente e não pelo analista!!! Pasmem!!! 3) Estimativa de esforço baseada em UCP em vez de pontos de função. 4) Métricas de produtividade distorcidas e aplicadas linearmente em todas as fases do desenvolvimento do projeto sem considerar outras variáveis como ambiente, pessoas e etc. 5) Esimativa de esforço feita para atender o fechamento do negócio. 6) Os gerentes acham que as pessoas(recursos) são robozinhos e que produzem modelos, códigos e etc assim como se produz pãozinho na padaria. 7) Os sistemas estão cada vez mais complexos. 8) Existem muitas pessoas (recursos) ruins, mal-formados trabalhando por aí... infelizmente essas pessoas não resolvem problemas, apenas aumentam os problemas dos projetos...


12/04/07, 00:27:41: Henriqe Silva hjss.bh@terra.com.br - IP : 200.150.25****
    Vejo como fator preponderante de atrasos em projetos de ti, a dificuldade na determinação de um escopo que esteja acima dos 90% do real, com isso haverá dificuldades na etapa de metrificação, sem contar no quesito produtividades, que está cada vez mais dificil devido ao turn-over.

12/04/07, 00:16:25: sincero - IP : 201.26.0****
    Acho que os projetos de desenvolvimento de software atrasam porque desenvolvimento de software é tratado cada vez mais como um processo em evolução, sempre mutável.

    Numa comparação com projetos de hardware podemos ver a consequencia a longo prazo dessa mutabilidade do software.

    Vejam se concordam comigo...projetando hardware a coisa é mais fácil de ser estimada e controlada. Por que? Simplesmente é MUITO CARO alterar algo físico depois de projetado e produzido. Imagina alterar 50.000 impressoras HP coloridas porque o Designer diz algum tempo depois, que o botão verde tá fora de moda ou qualquer coisa assim. Ninguém faz isso! Seria loucura! De onde vai tirar a grana pra fabricar de novo? Onde vai jogar fora? Não tem como esconder essas coisas em que foi gasto dinheiro só porque alguém disse que não queria mais.

    Já com sofware..."ah bota ai uns programadores para fazer isso, compile e tá pronto..." não foi cortada nenhuma árvore, nenhuma placa de circuito integrado foi produzida aos milhoes...assim fica fácil sempre alterar. E onde escondemos o lixo? Bem dá uma olhada no histórico do seu Source Safe :-) Na minha oponião essa é a magia do software como solução instantânea e ao mesmo tempo sua ruína em termos de estimativas de projeto.

    Concluindo, ou se escolhe um modelo de projeto hardware-oriented (com seus prós-e-contras) ou continuamos procurando o Graal perfeito de controlar os prazos de um desenvolvimento de software mutante!

    Deixa pra lá...só foi um desabafo!


11/04/07, 17:23:30: Carlos - IP : 200.142.12****
    O comentário abaixo do Ronaldo traz uma questão que não é a única, mas é bastante importante : como uma consultoria conseguiria estimar corretamente prazo/custo/escopo antes de vender um projeto a um cliente, se ela precisa elaborar uma proposta técnica/comercial em pouco tempo e sem ter acesso a toda informação necessária ?

    Em um mundo perfeito, quando um cliente colocasse uma RFP no mercado (o que formalmente só existe em grandes empresas) nenhum fornecedor deveria apresentar propostas se a RFP não desse todas as informações necessárias para desenvolvimento da proposta do projeto.

    Na prática sabemos que quanto maior o cliente, maior a "guerra" entre as consultorias interessadas para tentar ganhar a conta. Isso acaba fazendo com que as empresas de TI estejam sempre "abrindo as pernas" acreditando que isso vai segurar o cliente.


11/04/07, 16:15:35: Ronaldo ronaldoxoliveira@gmail.com - IP : 201.34.20****
    Nossa, só alguns dias e este tema já rendeu boas opiniões. Poderíamos montar um relatório meio que conclusivo. Bem, continuo concordando com todos. Mas gostaria de advertir que PMI não é a solução. Vejam o documento de declaração de escopo. Ao meu ver considero muito superficial para determinar prazo e custo para projetos, principalmente os novos que nunca foram confrontados. Eu não fecharia um contrato com base neste tipo de levantamento. Inclusive há várias opiniões postadas com esta visão também (Detalhamento melhor das reais necessidades do cliente). Lembrando que cada caso é um caso. Veja o exemplo citado do colega: A empresa [A] contrata uma empresa [B] para fazer um projeto de software e esta , por sua vez, contrata uma outra empresa [C] que contrata uns temporários para desenvolver. Este é um caso que os riscos do projeto são altos (Vi nossa, gerência de risco. Não precisa em fazer MBA em gestão de projeto para enxerga isto, rs). Bem onde fica mesmo o calculo dos lucros do projeto? rs. Acho que alguns projetos têm alguém tomando prejuízos, rs.

11/04/07, 15:54:55: Lopes - IP : 200.136.58****
    "ASSIM, ENQUANTO ALGUNS PROFISSIONAIS NÃO MUDAR SEU MODO DE AGIR A PRODUTIVIDADE DIMINUIRÁ MAIS, E OS SEUS OBJETIVOS NÃO SERÃO ALCANÇADOS E O RECONHECIMENTO DE QUE PRECISAMOS SERÁ BAIXO. PORTANTO NÓS COMO PROFISSIONAIS TEMOS QUE MUDAR NOSSO MODO DE AGIR PORQUE SÓ ASSIM PODEMOS CONQUISTAREMOS OS ABJETIVOS E TEREMOS O RECONHECIMENTO QUE PRECISAMOS PARA CRESCER MUITO MAIS. EU TRABALHO COM INFRA ESTRUTURA A 3 ANOS E SEI COMO É DIFICIL PASSAR POR SITUAÇÕES DE PROJETOS E POUCA PRODUTIVIDADE."

    Conhece o Microsoft Word?


11/04/07, 14:08:28: Alesandro Ramos alesandroramos@gmail.com - IP : 200.181.1****
    Na verdade, o que ocorre na maioria das vezes é que geralmente os prazos não são determinados pela equipe de TI, As ordens são dada da seguinte forma: - Me entrega tal coisa em tal prazo.

    Outro fator é a falta de costume em escrever, documentar os projetos. Recentemente tem se questionado esse problema com projetos na area de TI, surgindo varios cursos voltados a projetos. Eu por exemplo estou fazendo um em projetos de redes.

    Fica a dica galera, temos que nos atualizar sempre... Projeto na area de TI parece-me uma area que esta carente no mercado...

    Um abraço a todos!


11/04/07, 13:23:15: Antonio antoniogeilson@yahoo.com.br - IP : 200.158.130****
    Resumindo, pois não são utilizadas metodologias, ferramentas, e procedimentos, que façam com que esses projetos participem da CRISE DO SOFTARE, Não Fazendo um Levantamento das reais necessidades funcionais e nao funcionais dos projetos, e influenciando principalmente em Aumento de Prazo, e Custos, afetando todo projeto.

11/04/07, 12:44:58: Oswaldo Simões osfilho@prservicos.com.br - IP : 200.220.18****
    Sem querer ser simplista, existe uma sequencia de falhas que acarretam atrazos nos projetos de TI: - Na contratação, nem todas as funcionalidades necessárias são claramente definidas pelo usuário. - O Analista funcional define com base no que o Cliente mencionou, e não questiona estas funcionalidades dentro dos objetivos do negócio. - O Gerente de Projeto, é muito frequentemente forçado a reduzir prazos e custos de forma absolutamente irracional, em função das verbas disponíveis. E nesta situação, lhe é vedada a hipótese de reavaliar, ou escalonar as definições ocorridas nas duas etapas anteriores. - Os recursos contratados em sua grande maioria não apresentam o necessário grau de comprometimento, com o Projeto em função da forma de sua contratação, (horas fixas mensais).

    Portanto há muito o que melhorar em todas as etapas, sem dó nem piedade, e além do mais, seria necessário repensar que os custos de um projeto, não deveriam jamais serem contabilizados como custo, mas como investimento nas áreas operacionais das empresas.


11/04/07, 11:11:40: Antonio - IP : 200.149.20****
    Pela minha experiencia existem alguns motivos muito importantes:

    1 - No levantamento junto ao cliente/usuario não é feita uma verdadeira avaliação do que precisa ser feito.

    2 - Hoje em dia quem determina o prazo de um projeto é a area de negocio e, neste caso o usuario/cliente não tem ciencia de quanto tempo o desenvolvedor fará para a construção do codigo para .

    3 - E por fim, os profissionais contratados para o projeto tem que conhecer as ferramentas que vão utilizar para construção de programas pois, pode ser muito barato contratar um junior mas, que no fim com a extensao do projeto esse recurso fica caro, enquanto se contratassem profissionais com mais experiencia o resultado seria melhor em menor espaço de tempo.

    É claro que existem mais pontos a ponderar mas, acredito que estes sejam os mais importante.


11/04/07, 10:53:54: Carlos - IP : 200.142.12****
    Não é simples e objetivo definir um ou dois motivos. Além disso, se os projetos de TI fossem realmente feitos "como manda o figurino" eles não iriam somente ser feitos no prazo. A própria área de TI teria que ser reciclada de cima abaixo, inclusive eliminando ou rebaixando profissionais nos mais diversos níveis e funções. Costumamos reclamar do gerente de projeto, mas todos os papéis teriam que ser selecionados com muito mais expertise e não do jeito que é hoje.

    Hoje, o cliente quer projeto, contrata a consultoria grande que contrata as consultorias pequenas para "alocar" o pessoal PJ no projeto o mais rápido possível. Aí não tem jeito, programador não é igual pãozinho de padaria : "manda aí 20 programadores, dos bons"........ só rindo que contratando desta forma os projetos vão dar certo........... aí vc joga todo mundo na fogueira e seja o que deus quiser......... tem um ditado que diz que "tudo que é urgente esconde alguém incompetente"....... esse monte de vagas de "urgente início imediato" existem por quê ? Porque sempre tem algum projeto que querem encher de recursos para impressionar o cliente, sem nem saber direito o que terá que ser feito.....


11/04/07, 10:53:40: Carlos - IP : 200.142.12****
    Esta questão é bastante capiciosa.... é como perguntar porque o Brasil não vai para frente......... tudo que foi dito até agora influencia..... por isso que não existe só um fator.

    Os projetos de TI não atrasariam se:

    - Não existissem as consultorias sanguessuga ? talvez - As empresas tivessem seus processos mais maduros e definidos ? talvez - Se a prorização por baixos custos não reduzisse a qualidade dos recursos ? talvez - Se não houvesse tanta pressão por prazo para não perder o cliente ? talvez - Se as metodologias de desenvolvimento fossem realmente utilizadas ? talvez


11/04/07, 08:54:22: Bruno Alfieri bruno.alfieri@pop.com.br - IP : 201.11.40****
    ASSIM, ENQUANTO ALGUNS PROFISSIONAIS NÃO MUDAR SEU MODO DE AGIR A PRODUTIVIDADE DIMINUIRÁ MAIS, E OS SEUS OBJETIVOS NÃO SERÃO ALCANÇADOS E O RECONHECIMENTO DE QUE PRECISAMOS SERÁ BAIXO. PORTANTO NÓS COMO PROFISSIONAIS TEMOS QUE MUDAR NOSSO MODO DE AGIR PORQUE SÓ ASSIM PODEMOS CONQUISTAREMOS OS ABJETIVOS E TEREMOS O RECONHECIMENTO QUE PRECISAMOS PARA CRESCER MUITO MAIS. EU TRABALHO COM INFRA ESTRUTURA A 3 ANOS E SEI COMO É DIFICIL PASSAR POR SITUAÇÕES DE PROJETOS E POUCA PRODUTIVIDADE.

11/04/07, 08:28:00: Edison - IP : 201.11.40****
    Não existe projeto de TI e sim um objetivo à alcançar. Porque projetos demoram muito para sir do papel e a necessidade é maior para atender as urgencias do mercado que a empresa atua e exige rapidez em determinadas soluções. Informática em uma empresa evolui conforme a empresa cresce no seguimento que atua, o que faz a diferença de uma empresa para outra de mesmo ramo é a importancia que é dado à area de Informática e seus recursos humanos.

10/04/07, 22:43:01: Fábio - IP : 201.13.****
    Ao meu ponto de vista, tudo é feito muito rápido. "Temos uma reunião hoje com o cliente pra entregar o projeto ontem...", é mais ou menos assim que se procede.

10/04/07, 22:10:30: Marcelo - IP : 201.6.10****
    Acredito que TI no Brasil nao existam pessoas suficientemente capazes de levar um projeto a serio mesmo porque consultorias de TI nao querem levar um projeto a serio gostam de enolar para no fim alocar mao de obra!

10/04/07, 21:03:32: Adolfo - IP : 201.1.13****
    Falta de uso de metodologias ágeis: pouca participação do usuário durante o desenvolvimento. Não aplicação da programação pareada.

10/04/07, 20:02:59: Consultor - IP : 201.29.137****
    Os projetos de TI atrasam porque ninguém usa uma metodologia definida e de forma clara e objetiva. Sem contar que o alto escalão do projeto fica com medo de perder o emprego, não ganhar a licitação, perder o cliente, etc...

10/04/07, 17:31:07: Sergio Carvalho sv-carvalho@uol.com.br - IP : 200.178.2****
    Existem varios fatores para o insusseco de um projeto. Podemos dividir alguns por fases : >>>>Iniciação : Falta de definição clara dos objetivos do produto desejado. Não se tem claro o que se quer do software ou hardware. >>>>Planejamento : Falta de especificação do escopo do projeto e total negligenciamento dos riscos envolvidos. Sempre existe algo que o cliente quer a mais ou deseja modificar, nunca sendo possível delimitar o produto desejado. Apesar de todos os riscos estejam claros, nenhum planejamento de como encará-los é feito. >>>> Execução : Má interpretação das especificações e falta de planejamento de testes unitários. Geralmente existe uma pressa para se começar a construir e quase nunca se perde o tempo para se entender o que realmente se deseja, sem falar que planos de testes são feitos literalmente "nas coxas". >>>> Controle : Os relatórios do status do projeto geralmente são camuflados para atender o cronograma, em muitos projetos não existe nem mesmo estes controles. Mudanças que ocorrem no meio do processo não são "contabilizadas" e muitas vezes não é feito novo cronograma. >>>> Implantação : Em certos ambientes muitas implantações são feitas sem piloto, e alguns casos os planos de implantação são negligenciados pela equipe de produção. Além disto podemos dizer que fatores criticos de sucesso de um projeto dependem também da comunicação clara dos problemas e soluções aplicados para que se fique claro dos motivos dos atrasos e custos extras.


10/04/07, 15:34:20: Alex alex.salen@terra.com.br - IP : 201.26.87****
    Mais precisamente o maior motivo dos projetos atrasarem é por culpa do gerente de projetos.

10/04/07, 15:04:13: Antonio antoniomcruz@terra.com.br - IP : 200.169.221****
    Existem vários fatores que podem atrasar um projeto, como exemplo:

    Mudança na especificação, Mudança da equipe, Erro de estimativa do tempo das tarefas Falta de recursos

    Para evitar atrasos é necessário um plano de projeto consistente e acompanhamento.


10/04/07, 14:45:48: Flavio Oliveira flavio.marcondes@gmail.com - IP : 201.28.1****
    Os atrasos ocorrem devido a algumas variáveis, como:

    Na fase de levantamente de requisitos e arquitetura:

    - Algumas vezes nem o próprio cliente sabe exatamente de suas necessidades. Nesses casos, se o time ou o arquiteto não tiver uma boa experiência para definir o escopo de forma eficiente e clara, atrasos serão inevitáveis.

    - Ausência total de processos ou utilização de processos de forma burra e inflexível.

    - Ausência de um bom gerente de projeto. Esse fator é essencial. Tem muito profissional querendo gerenciar projetos, mas na minha opinião não é apenas uma questão de vontade. Além de conhecimentos profundos em técnicas de gerenciamento são necessárias qualidades intrínsecas como firmeza nas negociações com o cliente e tomadas de decisões, saber delegar tarefas, entender as necessidades do cliente e comandar o time técnico de forma clara e objetiva. Como nem todos tem essas qualidades acabamos nos deparando com gerentes totalmente passivos que fazem o papel de telefone sem fio entre cliente e equipe de desenvolvimento e apenas cobram datas de entrega, sem prestar qualquer suporte para a equipe.

    O mundo ideal seria então:

    - Clientes com pleno conhecimento de suas necessidades. - Processo maduro, enxuto e flexível. - Gerência de projeto e time técnico focado, capacitado e atuando em suas competências.

    Como a combinação desses fatores e muito difícil no mundo real, os projetos sempre acabam caindo nos mesmos problemas de prazo e redefinição de escopo.


10/04/07, 11:27:08: Fernando - IP : 201.55.6****
    Simples,...

    Custo é mais importante que qualidade na aprovação da proposta do projeto, prazo curto, lucro exorbitante para a consultoria, gerente de projeto e consultores pé de chinelo..... TI precisa ser regulamentada com urgência...


10/04/07, 11:09:49: José Luiz luizinho@uol.com.br - IP : 201.37.140****
    Os projetos de TI geralmente atrasam porque não é incluído no projeto o Gerenciamento de Risco. As emresas optam por "chutar" de 10% a 20% a mais no orçamente como reserva de risco. O correto é fazer o Gerenciamento de Risco prevendo riscos negativos (prevenção, mitigação e em caso do risco acontecer a correção) e dos riscos positivos (que devem ser provocados ou pelo menos previstos seus efeitos positivos no projeto). Sem o estudo dos riscos o projeto não só pode atrasar mas também pode o mesmo ser vítima do insucesso e de muito prejuízo para as organizações. Veja o exemplo do Metrô que desabou... Faltou gerenciamento de riscos e muita fiscalização nas atividades do projeto (Gerenciamento da Qualidade). Pesquisem as áreas de conhecimento do PMBOK, as áreas de processos do CMMI e também a proposta das nosmas ISO. Caldo de galinha e bom senso nunca fizeram mal a ninguém! Felicidades a Todos.

10/04/07, 10:35:58: Ronaldo ronaldoxoliveira@hotmail.com - IP : 201.34.20****
    Concordo com os comentários colocados até agora. Realmente podem ser vários os pontos que contribui para o atraso. Tem uma frase de um amigo sobre projetos muito interessante: Se começa errado a possibilidade de atraso e quase certa. Gerenciar projetos de software necessita de conhecimento em Tecnologias, Engenharia de Software e Administração.

10/04/07, 10:34:34: Neutron - IP : 200.177.101****
    Dos projetos em que trabalhei, os atrasos foram devidos estimativas apertadas de recursos e prazo em função de pressões por preço e pressa em ter uma data de golive mais cedo possível.

    Com as ferramentas de gestão disponíveis, como PMO, gestão de riscos, ponto de função, project, etc é possível fazer uma estimativas bem precisas de recursos e prazos. Porem, na hora de apresentar a proposta para o cliente, os valores acabam sendo sub-estimados, para vencer a concorrência. Portanto parte da culpa também é dos clientes. Portanto o cliente e a área comercial da consultoria tem a maior parte da culpa.

    O gerente do projeto também tem sua parcela, porque quando o prazo do projeto é curto, deveriam ter uma abordagem pratica, mas ficam procurando pelo em ovo e procedimentos que só enrolam o meio de campo.

    Depois disso tem os próprios consultores, que ficam dando tiro no pé, levantando polêmicas com os clientes, querendo ser mais perfeitos que o rei. Se o cliente comprou um fusca, entrega o fusca, não fica tentando convencer que o melhor pra ele era uma BMW.

    Enfim tá todo mundo nessa panela, os projetos atrasam porque as estimativas são irreais.


10/04/07, 10:16:50: Gamaliel gamaliel@cti.com.br - IP : 200.204.19****
    Olha, o atraso deve-se a diversos fatores, que vão desde o responsável por TI não ter mensurado bem as variáveis até anciedade da diretoria, paradígmas, pessoas que não se comprometem, custos, etc. Muito embora existam metodologias e práticas conceituadas tais como ITIL, COBIT, MSF, PMI, UML e por aí vai, se o Gerente de TI e sua equipe não estiverem afinados e o Gerente de TI não souber aplicar estas práticas e também um excelente negociador, administrador e bom (vendedor), nào é possível mesmo cumprir estes prazos. Projeto é uma coisa muito boa dentro de uma empresa e na vida de um gerente de TI, mais administrar e gerir tal, é uma arte que poucos dominam.

10/04/07, 09:54:11: Joaquim - IP : 200.60.417****
    Os motivos são vários, mas de longe o principal é a deficiência na definição do escopo do projeto e as mudanças durante a fase de desenvolvimento.

    Trabalho em TI a mais de 25 anos e mesmo com o surgimento de novas tecnicas como PMI, CMM, Use Cases e etc, acho que ainda não evoluimos o suficiente.

    Existe sempre uma pressa exagerada em iniciar o projeto, as dificuldades, prazos e custos são minimizadas e no final todos trabalham como loucos, para conseguir entregar alguma coisa para os usuários. O mais interessante é que aprendemos pouco com estes erros, pois acabamos um projeto destes e logo começamos um novo, achando que desta vez vai ser tudo diferente...



Anteriores:

71 - É possível envelhecer e continuar a trabalhar em TI ?

70 - QI (Quem Indicou) e rede de relacionamento são imprescindíveis em TI ?

69 - Especialista ou generalista, quem ganha mais dinheiro em TI ?

68 - O gerente de TI tem que possuir conhecimento técnico ?

67 - Deixe sua mensagem (otimista) para o próximo ano

66 - Qual tecnologia vai ser destaque em 2007 ?

65 - Afinal, o mercado de TI está saturado ou não ?

64 - Windows Vista e WGA - O que esperar ?

63 - Pesquisa 2006 completa : comentários

62 - Comente a prévia da pesquisa 2006 : Certificação - Salário Homem x Mulher

61 - Comente a prévia da pesquisa 2006 : Benefícios - Escolaridade

60 - Comente a prévia da pesquisa 2006 : Sexo - Idade

59 - Java ou .Net, qual tecnologia oferece mais oportunidades de trabalho ?

58 - Como definir pretensão salarial para vagas de TI ?

57 - Como definir prazos e custos de um projeto de TI ?

56 - Certificação : Quais as melhores opções custo/benefício

55 - CLT-flex : Conceito, vantagens e desvantagens

54 - No curto prazo vai surgir alguma tecnologia capaz de eliminar o spam ?

53 - Deixe sua mensagem otimista de final de Ano.

52 - Qual tecnologia vai ser destaque em 2006 ?

51 - A terceirização na area de informática é irreversível ?

50 - Trabalhar em casa. Realidade ou ficção ?

49 - Cobol ! quem ainda usa ? Vale a pena aprender ?

48 - Fábrica de software é uma boa alternativa para empresas e profissionais de TI ?

47 - O profissional terceirizado é discriminado dentro da empresa ?

46 - Desenvolvimento interno ou pacotes como SAP, Peoplesoft e etc ?

45 - Vale a pena pagar por uma recolocação ?

44 - Vale a pena compartilhar conhecimentos técnicos com outros profissionais, ou usuários ?

43 - Como ter uma carreira de sucesso após os 40 anos ?

42 - A Microsoft vai ampliar seu domínio na área de TI ?

41 - Sobram vagas em TI e faltam profissionais qualificados ?

40 - Comente a estratégia do governo de aproximar a carga tributária de CLT e PJ

39 - Qual tecnologia vai ser destaque em 2005 ?

38 - Deixe sua mensagem (otimista) de fim de ano

37 - Quais as perguntas capciosas feitas na entrevista de seleção ?

36 - Como obter o primeiro emprego na área de informática ?

35 - Vale a pena investir em SAP e aproveitar o aquecimento do mercado ?

34 - Concursos públicos para profissionais de TI

33 - Existe um bom mercado para profissionais Linux ?

32 - Comente a pesquisa salarial apinfo 2004

31 - Ser especialista ou generalista, qual melhor opção hoje no mercado de TI ?

30 - Como melhorar os processos de seleção de TI ?

29 - Como superar o trauma da demissão ?

28 - As profissões ligadas e informática devem ser regulamentadas ?

27 - Cursar um faculdade de primeira linha garante um bom emprego ?

26 - Qual tecnologia vai gerar mais emprego em 2004 ?

25 - Um bom emprego pode garantir a estabilidade financeira ?

24 - Como ter sucesso em um processo de seleção ?

23 - O mercado de TI esta sendo mais afetado que os outros, devido a crise econômica ?

22 - Qual a melhor empresa onde voce já trabalhou ?

21 - CLT ou Free ? Quais as características de cada opção ?

20 - SLA Service Level Agreements, este é o caminho ?

19 - Qual a carreira mais promissora de TI ? Programação, redes, web ... ?

18 - Quando vale a pena pagar para obter uma recolocação ?

17 - Qual a principal característica de um profissional de informática de sucesso ?

16 - Quais os maiores defeitos dos profissionais de informática ?

15 - Vale a pena aprender Cobol e outras linguagens voltadas a mainframe ?

14 - Você acha que trabalhar no exterior é uma boa oportunidade para os profissionais de TI ?

13 - Terceirizar projetos significa transferir a inteligência para fora da empresa ?

12 - Os Gerentes de Informática conhecem TI, ou são reféns dos Profissionais de TI que contratam ?

11 - É possível manter uma carreira tecnica após os 40 anos ?

10 - Em qual tecnologia o profissional de IT deve ficar de olho em 2.002 ?

9 - A terceirização dos serviços de informática tem sido boa para os profissionais de IT ?

8 - Vale a pena investir tempo e dinheiro para obter uma certificação ?

7 - A crise nas empresas ponto com, vai reduzir o mercado de trabalho em informática ??

6 - Quais as tecnologias, que mais vão demandar profissionais de informática, nos próximos 2 anos ?

5 - Que dica você daria para quem esta querendo iniciar na área de informática ?

4 - O Linux vai ser um concorrente do Windows ou vai continuar crescendo só entre a turma que gosta de Bits e Bytes ?

3 - Qual o efeito que o monopólio da Microsoft traz para o mercado e para os profissionais de informática ?

2 - As profissões ligadas e informática devem ser regulamentadas ?

1 - Como melhorar a imagem da área de informática junto aos usuários ?