APinfo - Forum

Fórum : Por que mesmo com novas tecnologias e metodologias, muitos projetos de TI, no Brasil e no mundo, estouram o prazo, o orçamento e a paciência dos usuários ?

Sugerido por : Solange, Juliano, Medeiros

Foruns anteriores

Bom pessoal, pelo que observei no forum..Chego a seguinte conclusão : 1- Nossa área ainda está muito "cru" e longe de ser padrão de trabalho! 2- Estando ha 22 anos na área vivendo projetos desde que não existia metodologia até os tempos atuais com metodologia observo que não é levado a sério os projetos (mesmo com a eficiência que existe qdo do uso correto da metodologia). 3- E "matando o item 2" concordo com diversas opiniões do forum sobre : Vendas determinar prazo/valor, não se renegociar com cliente (Valor/Prazo) no decorrer do projeto, alguns gerentes subestimarem o cronograma por não escutarem sua equipe ref. ao tamanho real do projeto, assumindo o prazo de inicial(VENDAS). 4- Bom mas para uns "Informáticos (sem generalizar)...rs" o que importa mesmo é que já existe a versão 9999.9999 da metodologia yyyy ou então a versão 999.991 da linguagem @#@#@#¨&¨%$; 5- Cenario : Aaaah mas o Usuario só quer um cadastro "Basico", ai vem o Analista "Master plus tabajara" e fala: "Que nada vamos colocar tecnologia de ponta para esse Cadastro de Clientes, vamos usar CMI,WCF,SOA...", pena q o "individuo" só esqueceu do campo de Endereço do coitado do cliente na tela...mas q importa né tem tudo que é de novo no cadastro.. --> E assim caminha a nossa área de TI sempre cheia de perfumaria...mas não atendendo o negócio em mais de 75% das implantações..rs.. --> Um dia quem sabe estaremos com um padrão de trabalho "igualzinho" as areas de Engenharia, Medicina, Advocacia, etc... --> AAaaah ai vem aquela famosa frase : "Desenvolver projetos de TI são mais complexos do que qualquer outra área !" -> Será que é mesmo mais complexo do que realizar uma cirurgia em um ser humano? E ainda usando o mesmo padrão que os outros médicos? Abraços a todos ... a gente chega lá pessoal..

Acho que a maioria dos profissionais que se forma hoje em dia, são apenas tecnólogos e não administrativos, Líderes... Eles pensam na máquina, usam a máquina e acham que a máquina é tudo !!! Esquecem do SER HUMANO, que é a figura principal... Acreditam tanto computador que investem tudo... Até idolatram ele!!! e o HOMEM: seu subordinado, seu colega, seu chefe??? "A maior descoberta do HOMEM ainda é o próprio HOMEM"

Abraço, Orlando.

Falta de cultura em gestão de projetos.

O Cliente é o maior responsavel pelo projeto, não tem como concluir as fases de cada etapa do projeto se o cliente e usuarios não tiver comprometidos, e pura perda de tempo.

Simples, por uma única razão: As metodologias não são soluções e sim produtos que não fazem parte do projeto.

Vamos ver cada nível:

1. passo As metodologias são criadas por profissionais engajados em um ideal de consultorias, entidades de mestrado, pesquisadores, enfim, no fundo buscam fazer suas marcas, impor um modelo e amarrar um cliente eternamente a uma convenção, onde quem a inventa será eternamente favorecido de algum modo, normalmente, financeiramente.

A maioria das metodologias são extremamente burocráticas e teóricas, e sempre citam um projeto perfeito que ninguem conhece que deu certo um dia em algum lugar.

A complexidade de segui-las fornece uma boa desculpa para caso exista erro. É fácil se esconder e barrigar no processo.

As pessoas que a executam são políticas, tremendamente cheias de egos e lutam para que seus "ONUS" não fiquem expostos para seus amigos e concorrentes de trabalho tomando sempre em conta o mínimo de esforço possível.

Contrata-se recursos (pessoas). Recursos deveriam ser objetos sem vida, como notebook, apagador, caneta, martelo. Como bons profissionais as pessoas vão se portar como recursos, afinal é pra isso que foram contratados.

Um problema no projeto com metodologia significa uma trilha diferente e uma não conformidade e não necessariamente um problema.

Pede-se mais tempo para se tratar a não conformidade.

A não conformidade pode ser tratada como mudança de escopo e então pede-se mais tempo para readaptação de escopo.

A readaptação do escopo pode se transformar em um novo projeto e ai é só voltar para o passo 1 do loop eterno.

Hoje no Brasil temos muita cultura do deixa que eu resolvo, mas normalmente essa cara que diz que resolve sabe pouco de muitas coisa e nda de uma coisa só, sendo assim as empresas vendo que esse funcionario diz ser capaz dá um voto de confiança e esse voto sai muito caro, pois ele não consegue atingir o resultado esperado pela empresa, toda empresa tem que ter em mente em contratar pessoas qualificadas para realizar seus projetos e não deixar os "fuções" entrar nesses projetos.

Sou profissional da área com MBA mas a meu ver a TI é um "feudo", tudo que é solicitado à ela, seja um projeto novo ou alteração de já existente, ou vai demorar muito ou custará caro demais, dessa maneira, justificam-se os altos salários/hora cobrados pelas consultorias. Com relação às mudanças nos projetos, às vezes situações simples são transformadas em grandes "mudanças de escopo", ou para a TI poder se ajustar a algo que ela não previu ou para poder fazer alterações no orçamento inicial.

Na minha empresa, eu não tenho esse tipo de problema. Acredito que isso seja pelas técnicas mal-desenvolvidas pelas empresas.

1o. Consultorias apertando o prazo para poder vender e depois dar um jeito no go/no-go.. 2o. As metodologias criam a impressao de que elas funcionam da mesma forma para todos os projetos independentes da tecnologia. Os PMOs nao tem conhecimento tecnico necessario, e nao sao capazes de dimensionar os esforcos e os riscos de algo dar errado.

Estão preocupados em "vender" esses produtos ao mercado e não resolver o problema de atrasos.

Na minha opnião, os prazos sempre estouram, primeiro por falta de comprometimento e comunicação entre as pessoas. Por isso, por mais que sejam criados sistemas e metodologias, estes não serão utéis, se as pessoas não cumprirem com seus compromissos.

Por que apesar de muito estudar e planejar,nem sempre as coisas saem como programado,sou um profissional que trabalho numa gigante do ramo e vejo constantemente os desvios que ocorrem ao longo da jornada,o engraçado é que a verba normalmente está disponível,mas os furos e os desperdícios são eminentes,fazendo com que o lado humano e racional seja sempre colocado em xeque,exacerbando a nossa capacidade de superação,dúvidas,contatem-me.

Falar sobre metodologia e planejamento em TI aliado a gestão estratégica da empresa ainda é muito difícil, principalmente porquê hoje em dia os executivos de gestão (raramente profissionais com experiência tecnológica) simplesmente ignoram os benefícios e focam na redução - sem critérios - de custo a TI é simplesmente encarada como um departamento que deve tudo resolver e que gera custos desnecessários.

Senhores, TI nada tem a ver diretamente com Xbox ou PlayStation e sim com Análise, planejamento e consequentemente investimentos, sempre alinhados com o plano de onde a empresa quer chegar e revisado junto com as mudanças de necessidade e tendências no negócio. Obrigado.

O grande problema de hoje é que o desenvolvimento de sistemas foi banalizado, em muitas empresas acredita-se que as metodologias e metricas são dispensáveis por que uma "telinha" não precisa ser documentada, então um monte de "telinhas" são desenvolvidas indiscriminadamente e o sistema acaba não saido da forma como deve ser... o outro grande problema é o imediatismo das coisas, tipo assim... se o sistema não estiver pronto até tal dia (obs.: o dia não foi definido pelo analista de sistemas) vamos ter prejuízo ou nossa "estratégia" vai por agua abaixo, o que leva com que o sistema seja desenvolvido de qualquer jeito.

Pelo tempo que tenho em consultorias e empresas de grande e médio porte, acredito que esse motivo seja basicamente por 2 fatores: 1o. pela falta de definição consistente por conta das empresas/falta de conhecimento no propósito do projeto e tecnologia em questão; 2o. a concorrência entre as consultorias está cada vez mais acirrada e por conta do "ter que vender", colocam seus preços e prazos contraditórios aos da realidade dos projetos comprometendo assim a integridade dos projetos, e comentem furos e gafes nas metodologias e implantações.

Este sr: "Roberto - IP : 201.87.49****" respondeu o que é METODOLOGIA e ao falar a respeito disso com um usuário, ESTOURA a paciência de qualquer um!

A certificação de metodologias que nos auxiliam a lidar com a execução dos pontos do programa exige a precisão e a definição do processo de comunicação como um todo. Acima de tudo, é fundamental ressaltar que a contínua expansão de nossa atividade faz parte de um processo de gerenciamento das formas de ação.

Todas estas questões, devidamente ponderadas, levantam dúvidas sobre se a determinação clara de objetivos causa impacto indireto na reavaliação das novas proposições. Podemos já vislumbrar o modo pelo qual a necessidade de renovação processual promove a alavancagem do impacto na agilidade decisória, ainda assim, existem dúvidas a respeito de como o início da atividade geral de formação de atitudes deve passar por modificações independentemente do fluxo de informações. Podemos já vislumbrar o modo pelo qual o julgamento imparcial das eventualidades apresenta tendências no sentido de aprovar a manutenção dos índices pretendidos.

Neste sentido, o comprometimento entre as equipes prepara-nos para enfrentar situações atípicas decorrentes das condições inegavelmente apropriadas.

O que temos que ter sempre em mente é que o comprometimento entre as equipes maximiza as possibilidades por conta das novas proposições.

Por outro lado, a constante divulgação das informações aponta para a melhoria do sistema de formação de quadros que corresponde às necessidades

Comunicação. Um projeto é desenvolvido por pessoas. A comunicação é essencial para que o fornecedor oriente seu cliente e deixe claro que o que será desenvolvido é único e específico para o negócio do cliente. Portanto, tanto o cliente e o fornecedor irão aprender, melhorar e entregar o melhor produto no decorrer do desenvolvimento da solução. O fornecedor deve ser honesto e transparente ao informar o cliente que ele não está adquirindo um bem industrial, feito em série como um carro, um computador ou mesmo um conjunto comercial. Se você vende um produto que não necessita de nenhuma customização ou alteração (assim como um editor de texto ou navegador para internet) pois já se sabe a que ele se destina, como se utiliza e quanto tempo você levará para ter a solução em funcionamento e você tem certeza que ele não irá mudar em nenhum momento, com certeza isto não é um projeto.

Podemos dizer que quando a analise de requisitos para um projeto foi realizada sem o devido acompanhamento do cliente, expondo seus principais objetivos e necessidades, o inicio do problema está ai.

Informações faltando e na primeira prévia do projeto o prazo já estará comprometido.

Isso é simples, porque os custos são subestimados, são apertados, a terceirização faz achatar o pagamento do profissional ,o lucro do projeto é dividido entre prestadoras de serviço, então gente inexperiente é contratada e os recursos são limitados ( tempo e pessoas).

Primeiro temos que entender que a atividade de desenvolvmento de sistemas é uma atividade artesanal, não é, e acredito que nunca será, uma atividade industrial, onde as máquinas executam repetitivamente as atividades em uma produção seriada. Toda atividade artesanal depende do talento do artesão para ser feita, as métricas existentes apenas ajudam a definir prazos médios para execução das atividades.

O problema começa no momento da venda, o vendedor do serviço raramente tem o conhecimento técnico necessário para a compreensão das dificuldades envolvidas. Por outro lado a forma de venda não ajuda, raramente se tem tempo para fazer o detalhamento das atividades de tal forma que se possa definir o custo e o prazo com alguma precisão. O cliente tem uma imensa parcela de culpa, muitas vezes faz uma concorrência onde o fator único de decisão é o preço, com isso, fatores intangíveis, como qualidade e complexidade ficam relegados para segundo plano.

Depois estes mesmos itens são colocados contra o vendedor do serviço.

Os processos dentro de uma empresa que envolve a questão de consultoria, não depende somento do consultor, mas também da disponibilidade da empresa assim devemos analizar as questões que esses prazos não foram cumpridos.

Falta de compromentimento do consultor. Falta de recursos da empresa. aceitação dos usuários e clientes da empresa. Conhecimento Adequado do que se deseja. entre outros...

Muitas vezes os clientes muda de foco. é interessante firmar um contrado que atenue estes problemas. assim asegurando a empresa para não ter investimento mal sucedido.

Antonio Borges Coordenador TI FUNDEC-RJ

Por que 99% das consultorias para pegar um projeto interessante prometem o prazo que o cliente quer ouvir e não o prazo real. Depois que o projeto atrasa o cliente fica vendido pois fica inviável cancelar o contrato com a consultoria atual e passar o projeto para outra.

Não existe e nem vai existir nenhuma metodologia que comporte esse tipo de cenário.

Pelo fato de não ser pessoas com conhecimento de como funciona o local, as pessoas que trabalham com aquele serviço não serem consultadas de como o produto solicitado vai ajudar na solução de problemas. Muitos problemas dentro de algum projeto é feito por alguem que conhece o caso só de falar e nunca ter trabalhado com aquele serviço, não importa a técnologia ou metodologia que seja criada que quem for utilizar não seja consultado ou ate mesmo colocado junto com os elaboradores para melhor solução dos problemas locais. Este cometário esta sendo feito pelo fato de acontecer algo identico na empresa que eu trabalhava e as pessoas que trabalhariam com aquele produto não serem consultadas .

Em primeiro lugar, não existe uma metodologia 100% eficaz no desenvolvimento de um projeto de software. Entretanto, alguns pontos que sendo observados podem garantir um certo nível de qualidade ao projeto de software.(1) Formulação de um PDI - plano Diretor de Informática (2) Análise de Requisitos do ambiente (3) Seleção criteriosa dos membros da equipe de projeto (4) Definir as prioridades de escopo de projeto (5) Documentação criteriosa (6) Desenvolver relatórios de acompanhamento de projeto tais como custos, PERT-CPM e outros. Mesmo sendo uma sequência de eventos de projeto, estes passos podem e devem ser executados de forma independente.

Devemos dar especial atenção à fase de analise de requisitos, pois nesta fase conseguiremos ter a visão do "ambiente problema" e com a geração dos artefatos de análise (PDI, UML e outros) ter uma exata noção dos desafios do "ambiente solução" a ser construído.

Se alguém estiver interessado posso passar alguns modelos de documentos de análise de requisitos utilizados nos projetos dos quais eu participo.

Sds.,

claudioantonio@bol.com.br

Fala de comprometimento das pessoas, tanto no planejamento quanto na execução. O cliente paga e não quer se comprometer, isso desencadeia um processo que desmotiva equipes. Outro motivo é tentar criar um cronograma fixo nas primeiras de projeto, pensando que se esta conseguindo mapear as tarefas.

Pq ? Bom...simples... Cada dia se exige mais...mais..mais.....e paga-se...menos...menos..menos..

O que motiva um cidadão a sair de casa ? Desafio ? Ah ta..conta isso pra minha sobrinha de 8 anos...

O que motiva é grana....plano de carreira.....etc...

Agora....voltando ao tema do forum......bom...deixa pra la...rsrsrsr

Má gestão. Projetos sendo "vendidos/adquiridos" sem nenhum planejamento. Refletindo em aumento de risco, custo, qualidade, prazo, orçamento, enfim... no final, um alto nível de stress, projeto entregue deficiente, alto custo de manutenção, usuários descontentes. A palavra chave é PRAZO PARA PLANEJAMENTO. PONTO. Se não for possível, não assuma algo em que você não participou do planejamento, se você ficar calado, está automaticamente assumindo a responsabilidade e os riscos do projeto.

Novas tecnologia: muito caro e o cliente nunca quer gastar com elas. O resultado é que acaba gastando bem mais para consertar os problemas com estas economias "mesquinhas". Um outro ponto é que não adianta termos novas tecnologias se não tivermos as pessoas treinadas e os recursos inseridos de forma inteligente nos processos.´desta forma uma nova tecnologia só complica. Novas Metodologias: os clientes não acreditam "nessa porcaria". Acham que não tem tempo para perder com implementações do "mundo perfeito". O resultado é o retrabalho constante da forma convencional sem nenhuma abordagem metodológica o que configura a falta de cultura organizacional para estas teorias.

Atualmente as empresas possuem gerentes de projetos que cursaram, cursos universitários a 10 anos atrás, e ainda possuem a metodologia de software como se fosse uma linha de montagem. Muito não conseguem enteder a diferença entre clipper e java. Os professores que ministram aula nas universidades, se formaram quando o windows 95 estava surgindo. Acredito que por este motivo seja tão dificil implementar novas metodologias. As faculdades no Brasil principalmente, ainda estão engatinhando quando a questão é informática, os treinamento demoram muito a chegar, e quando chegam já se descobriu em outra parte do universo, algo ainda melhor do que o que está chegando aqui.

A vida de programador não é nada fácil, além de todas coisas que temos que saber, ainda temos que conversar sobre a novela (para não deixar os amigos tristes), fazer o curso de inglês, enteder de política, correr com projetos que possuem um prazo curtissímo, e acredite ainda sobra tempo para namorar. Rs.

Porque exige um melhor planejamento por parte gerencial da empresas, que economizam nos salarios dos funcionarios e depois acham que vão ter qualidade, agilidade, solução eficaz, para oferecer aos seus clientes.

Tem empresa que não sabe a diferença de um DBA para um desenvolvedor.

Talvez a resposta esteja na própria pergunta (Novas Tecnologias e Metodologias). O que faz a área de TI ser vanguarda, lucrativa, rentável e atrativa para tantas empresas, profissionais, centros de treinamento, etc. é o fato de sempre existirem coisas novas para aprender, desenvolver e obviamente vender. Talvez se os projetos continuassem a ser desenhados/desenvolvidos utilizando análise estruturada e uma linguagem procedural tipo Cobol sem nenhuma nova abordagem de levantamento ou implementação, provavelmente teríamos um processo extremamente maduro e repetitível (como gosta o pessoal do CMM) e em condições de que as estimativas tenham uma margem de erro muito pequena e os clientes tenham condições de avaliar com critério quando um fornecedor chega dizendo que vai "resolver o problema". Porém, quando se chega com um conceito/método/técnica novo a cada projeto, sendo que as técnicas novas são novidades inclusive para quem está implementando. É a tal história de aprender a pilotar em pleno vôo. Basta ver a velocidade em que empresas como a Microsoft vão lançando suas atualizações (WPF, Silverlight, LINQ, .NET 3.5, etc.). Como se pode implementar, por exemplo, um projeto de longo prazo usando "Silverlight" ? Como uma empresa vai planejar deploy de estações de trabalho com a própria Microsoft tentando apagar da memória o fiasco "Windows Vista" ? O que esperar depois da fusão Oracle + Sun se você optou por banco de dados MySql ?

Concordo q o maior problema eh as pessoas que não sabem se organizar e gerenciar isso acontece na maioria das vezes pois as pessoas que gerenciam o projeto ou seja os "chefes" não sabem o que fazem ou não sabem delegar.

Simples. Jamais a tecnologia vai substituir a organização das pessoas. Se as pessoas envolvidas no projetos não sabem planejar e administrar as ansiedades, é óbvio que o resultado ser ruim.

Os projetos falham, pois os usuários não sabem o que querem, e quando sabem, as famosas tecnologias não ajudam pois falta conhecimento.

A nivel brasil essa é facil, brasileiro quer sempre passar o outro pra tras, empresa muitas vezes nao tao nem ai para o cliente e nao aplicam metodologia alguma, estou numa empresa que faz os projetos sem nem colocar no papel e mesmo assim vende para empresa grandes.

No fim das contas quem negocia é quem tem o dinheiro e quem tem o dinheiro geralmente não manja muito, quer simplesmente lucrar, temos algumas excessoes, é claro.

As metodologias são ótimas ..... no papel e na teoria .... na prática é tudo diferente .... pricipalmente em trabalhos realizados em empresas chamadas de grandes "elefantes brancos" ...

Nao conheco empresa que invista na formacao de seus profissionais(formacao pratica zero), tambem nao conheco nenhuma certificacao que tenha sido sinonimo de conhecimento pratico (educacao formal zero), tambem acho que pessoas que sao formadas na area de informatica, ficando horas e horas na frente de um pc sem conversar com seu colega de trabalho, que fica na mesa ao lado, sobre qualquer assunto que seja, tem um problema serio de relacionamento pessoal no mundo real (gerenciamento e relacionamento de pessoas zero), tambem acho um absurdo que pessoas que ja comecam sua formacao na area de informatica, sem antes ter passado por outras areas da empresa, uma tremenda falta de bom senso. (formacao em negocios zero). Entao com metodologia ou sem isso nunca vai dar certo mesmo...

Leiam o livro 'Death March' do Edward Yourdon e vao entender o porque.

Na minha opinião aqueles que fazem a interface com os clientes ainda cometem um erro, mesmo que sem querer, de criar no cliente ou deixar este criar expectativas falsas sobre o que o projeto é de verdade...

Quando o dono da empresa que trabalho pega uma folha de papel e começa a fazer um monte de rabiscos, falando um monte de coisas muito superficiais, (eu chamo esses rabiscos de diagrama de índio, cheio de bolinhas e flechas que sobem e descem numa coreografia que só faz sentido na cabeça dele), e ele depois de desenhar esse "picasso" ele me faz aquela pergunta idiota : "quanto tempo leva para fazer esse sistema", tenho a resposta na ponta da língua e respondo com a seguinte pergunta: qual o nível de qualidade que voce quer no produto ? 1 - serviço porco (prá ontem) 2 - serviço meia-boca (para segunda-feira, o cara me avisa na sexta-feira) 3 - serviço me engana que eu gosto (uma semana) 4 - serviço razoável (um mes) 5 - serviço bom (6 meses) 6 - serviço para resolver o problema e o cliente satisfeito (mínimo 1 ano) Não adianta se enganar e achar que o profissional de informática é super-herói e que vai fazer milagres. Previsões de prazos é com a mãe Diná, interpretar diagrama de índio é para a FUNAI, entender a línguagem de usuário é para médico de sanatório, agradar a gregos e baianos, só Deus.

Leva a crer que é uma caracteristica da nossa área. Como minizar o estresse da TI? Eficiencia. Se todas as tecnologias e metodologia convergirem para este objetivo, sem dúvida alguma o cenário melhora para nossos clientes e também para nós, pois eficiencia significa mais produtividade, qualidade e, principalmente, cumprimento de prazos e valores.

O Maior problema, na minha opinão, é a falta de métrica tanto para suportar orçamento quanto para medir desempenho. Outro problema é o controle de escopo.

O problema não é a existências de diversas tecnologia e metodologias, mas como são aplicadas. Existe diversos remédios mais se utilizados de maneira errada e para outros fins para os quais não foram desenvolvidos, o resultado é adverso e acaba trazendo mais problemas que soluções. Logo, o problema é falta de capacidade das pessoas dizem conhecer um determinada metodologia ou tecnologia e muitas das vezes conhece bem é até mesmo excelente conhecedor, entretanto, não adianta entender sobre um metríca se não é capaz de sabe onde ela realmente sera eficaz. Podemos fazer um contraste entre o médico e o farmacêutico. Porque nínguem vai ao farmacêutico primeiro e depois ao médico? Porque o farmacêutico entendende de fórmulas(Quimica, Biologiaquimica, Erbacéos e etc...) não entende de diagnóstico e patologias. O médico sim entende desta duas última e tem um conhecimento de farmacologia mais é incampaz de formular p rémédio e conhecer a fundo sua aplicação. Logo, na área de tecnologia e projetos temos esta separação. O Técnicos fazem as ferramentas e dizem como elas devem ser utilizadas para serem eficientes, e cabe aos gerenciadores de projetos o diagnóstico correto e conhecimento sobre os problemas para saberem qual metodologia aplicar e por quanto tempo. Reflitam...

Bom pessoal, após divesas opiniões que andei lendo e também postei ao longo do fórum..Chego a conclusão que a nossa área ainda está muito "cru" e longe de se ter um bom padrão de trabalho. Mesmo estando ha 22 anos na área vivendo projetos desde que não tinha metodologia até os tempos atuais com metodologia observo que não se leva a sério os projetos mesmo com a eficiência que existe qdo do uso correto de uma metodologia. E ai concordo com diversas opiniões do forum sobre : Vendas determinar prazo/valor, não se renegociar com cliente (Valor/Prazo) no decorrer do projeto, alguns gerentes subestimarem o cronograma por não escutarem sua equipe ref. ao tamanho real do projeto acabando ficando com o prazo passado por Vendas ..bom deixa pra la... tem muita coisa para falar.. Bom mas para alguns(sem generalizar) o que importa mesmo é que já existe a versão 9999.9999 da metodologia sei la ou então a versão 999.991 da linguagem XXXXXX; - Aaaaah mas o Usuario só pediu um cadastro "basico" ai vem o Analista "master plus" e fala: "Que basico nada vamos colocar tecnologia de ponta para esse cadastro de clientes" usou até SOA...só esqueceu do campo de endereço do coitado na tela...e assim caminha a nossa área de TI cheia de perfumaria...rs....Um dia quem sabe estaremos com um padrão de trabalho igual as areas de Engenharia, Medicina, Advocacia, etc... AAaaah ja sei alguém vai falar : "Desenvolver projetos de TI são mais complexos..." -Será que é mais complexo do que realizar uma cirurgia em um ser humano? E ainda com o mesmo padrão de outros médicos? Abraços a todos ... a gente chega lá...

Por tem muitos gerentes de projetos q nem sabem q estão fazendo ali, por não serem da área, não ter conhecimento do real problema do usuário, eu mesma trabalhava como coordenador de projetos onde meu gerente mal dava caras no projeto e eu previa e informava todos os problemas mas parece q ele não queria ouvir e acho q até hj não ouve nada a não ser quando o problema chegava lá em cima, e não estou falando de qq projeto não tá, estou falando de empresas multinacionais.... É lamentavel... e o usuário pagava pela não solução do problema dentro dos SLAs estabelicidos. FALTA DE COMPROMETIMENTO acho q é bem por ai... Muitas terceirização, quarteirização... e o comprometimento vai decaindo conforme o grau de envolvimento...

Eu iniciei na área na época em que dados eram gravados/lidos em fitas de papel perfuradas e os estornos eram feitos na tesoura, logo depois veio a era dos cartões de papel perfurados e assim sucessivamente tenho visto as inovações tecnológicas acontecerem. Porém, os atrasos que ocorrem são causados por ferramentas que tentam mostrar fatos e sómente fatos, e isto jamais medirá com eficácia, visto não ser considerado a emoção e sentimento humano nas medidas. Normalmente usuários dentores do conhecimento real de um sistema não são treinados adequadamente para interagir com o técnico de informática independente da tecnologia utilizada, onde as definições não são efetuadas 100% com eficiência e muitos do PMI inexperiente no mercado acabam vendendo e implantando suas idéias hipotéticas acreditando estar construindo a perfeição. Porém, o título da matéria é: "Por que mesmo com novas tecnologias e metodologias, muitos projetos de TI, no Brasil e no mundo, estouram o prazo, o orçamento e a paciência dos usuários ?". Eu acredito que somente depois que os gênios da administração atual implementarem uma universidade onde se passem totais subsídios e treinamentos adequados para uma conversação técnica entre aqueles que conhecem o sistema de suas organizações e os técnicos de informáticas (independente de tecnológia existente), poderemos ver um futuro que chegue quase a perfeição dos prazos vislumbrados. Abraços cordiais a tod(a)os!.

No meu caso estes problemas são ocasionados por que envolvem pessoas e estas são sempre imprevisíveis e não cabem em qualquer que seja a metodologia. Pessoas tem dor de barriga, boa ou má vontade ... inteligência ou simplesmente interesses que algo demore mais ou menos. Se alguém ganha por trabalho vai fazer trabalhar, mas se ganha por hora o que acham que vai fazer ?

Complementando meu comentário anterior, digo que de todos os culpados citados anteriormente o maior deles é o Gestor do Projeto. Tem muita gente "certificada em PMI" por aí, porém sem ter o mínimo de bom senso na aplicação das metodologias. Tem que lembrar que a adoção de qualquer metodologia impacta em um aumento nos custos e normalmente o molho sai mais caro do que a carne. O Gestor do projeto deveria ter um mínimo de bom senso desenvolvendo um "PMI Light" que se adapte ao porte do projeto conciliando os recursos humanos disponíveis com as espectativas do usuário e mostrando por meio de um plano de projeto muito bem detalhado que os prazos necessários e factíveis são aqueles mostrados no plano, e não aqueles "achismos" definidos pelo cliente. A maior parte dos clientes é do tipo "quero-quero" parecem criança, eu quero por que quero e pronto, eu to pagando (Lady Kate).

Concordo com tudo que foi falado até agora, em seguida faço um resumo : - Dificuldade de expressão por parte dos usuários, que normalmente não sabem o que querem, se usuário tivesse alguma capacidade mental não seria usuário, seria analista. - Má fé da empresa fornecedora que vende até a mãe como sendo virgem, mas não entrega, afinal vale tudo pelo lucro, a qualidade que se foda. - Burrice do cliente em acreditar naquela "papo de vendedor". - Burrice do gestor do projeto em definir prazos com meta sem ter um plano que de sustentação para cumprimento das metas; quando o produto de um projeto é apenas um prazo, o projeto fracassa com certeza, afinal quem tem pressa come crú e quente. - Equipe de informática é apenas um bando de "genios geniosos" todos são donos da verdade, cada um simpatizante de uma facção da informática, é o pior tipo de gente que se tem para gerenciar, só tem "estrelas certificadas".

Sinceramente, acho que mtos programadores e gerentes de projeto, focam no que acham que o usuário necessita, sem se preocupar realmente com o levantamento de requisitos e necessidades deles, e também devido a mtas empresas de desenvolvimento não documentarem corretamente os projetos e qdo é necessário durante o processo , a troca de participantes da equipe, as novas pessoas sabem mto poko sobre o escopo do projeto, e entregam sistemas que mtas vezes não estão coerentes ao que o usuário necessita.Claro que não podemos esquecer de que mtos desses usuários imaginam que o profissional de TI é mágico e que fara milagres, e nesse ponto creio que as primeiras reuniões com o cliente devem deixar claro o que é possível e o impossível de ser feito.

Estouram os prazos simplesmente pq os gestores pensam que a área de serviços é igual a área industrial! NÃO se pode tratar serviços como se fossem linhas de produção, minha gente!!! Vamos procurar diretores e gerentes mais competentes para liderar a área de TI e todas as demais áreas de serviços!

Temos tantos métodos para o desenvolvimento e nenhum regime de métas e competências.

Vejo muita falta de qualidade em todas as disciplinas, principalmente na gestão.

Tem muito programador que acha que é artista, principalmente aqueles que enchem a boca pra falar: tenho xx anos de esperiência!!

Concordo com muitos que opinaram sobre a falta de analistas de verdade, com personalidade e humildade, e discordo do excesso de documentação. Acho que falta documentação de qualidade, que realmente tenha um propósito prático e garanta a segurança e desenvolvimento dos projetos.

O lucro é importante, mas também existe o aspecto ser "homem" é fazer direito ou não fazer.

Porque o cara que vendeu o projeto, mentiu sobre tudo, sobre o prazo, sobre orçamento........ enfim só disse o que o usuário precisava ouvir para poder vender seu produto....e depois os coitados do pessoal de desenvolvimento mesmo com uma equipe minimizada e inexperiente tenta entragar o projeto no prazo e ainda leva porrada do usuário que com razão fica impaciente, só quem se dá bem é quem vendeu e o dono da empresa.

Eu não diria Tecnologia, mas METODOLAGIA. Uma metodologia burocrática onde devem ser preenchidos diversos 'artefatos', sendo que a grande maioria nunca será consultado. No máximo, a Proposta e a especificação dos programas (algumas metodologias tem nomes diferentes), sarão revistos caso o projeto apresente alguma irregularidade. E praticamente, cada um desses documentos devem ser submetidos aos usuários para o "De Acordo" e aí prosseguir para o novo artefato. Isto é desgastante para os usuários que quer seu problema resolvido o mais rápido possível. Por outro lado, os supervisores da área de TI dão muita importância a Medodologia, que abrirão um ou outro documento para certificar se está preenchido, nem se preocupando com o "texto".

Prezados, permita-me:

Basicamente ocorrem pelo fato dos projetos estarem mal gerenciados, e, neste contexto, abordo principalmente a falha na definição do escopo e requisitos do projeto devido a falta de alinhamento entre os envolvidos; Atraso na entrega visto ao mal dimensionamento de tempo e recursos necessários e consequentemente a falta do gerenciamento do projeto como um todo, resultante de um planejamento inadequado.

Esse é assunto, bem legal para discussão. Vamos lá. Acredito que os prazos e orçamentos são possíveis de mensurar e atender no prazo e custo final do projeto, porém os requisitos nem sempre são levantados no seu detalhe, muito dos ambientes normalmente já passaram dos prazos de serem atualizados e possuem algumas melhorias que no decorrer da sua vida util foi necessário ser atualizado para atender necessidades emergências, onde caíram no esquecimento após entrarem em produção, esse somente um dos itens que acho entre eles o mais relevante que tenho deparado nos projetos que tenho atuado. Esse histórico de novas atualizações não documentadas, tanto da parte de desenvolvimento, operacional e pessoal que se perde no decorrer dos anos da operação do mesmo, portanto quando se fala de uma atualização, fica difícil levantar todos os requisitos e funcionalidades em sua totalidade, e por conta dos prazos normalmente apertados, não é feita a devida analise com cautela e tempo e são apresentadas soluções incompletas, o que gerará na implantação atraso, falta de recurso, aumento no custo do projeto ... E nem sempre temos um ambiente de teste a altura para homologar a solução e tempo suficiente para testes. Hoje vivemos num mundo de rápido atualização e o tempo é a chave para alavancar os negócios. No ponto de vista, para solucionar esse exemplo de aumento de custo e de prazo de projetos, as corporações devem ter um planejamento e visão futura do que onde querem chegar, iniciando esse projetos com antecedência e sair na frente, claro que terão atualização no decorrer do tempo, porém temos uma base pronto para adaptação menores.

Mas a falha não é apenas dos profissionais de TI. Muitas vezes, o contato com o cliente é intermediado por aquele funcionário que "entende de computador", e, por este motivo, acaba sendo o encarregado de suprir as informações necessárias para o levantamento dos objetivos/necessidades do sistema. E este, por sua vez, dificilmente conhece todos os pormenores dos processos que o sistema precisa contemplar. Em outros casos, o próprio diretor da empresa tem uma visão do negócio e dos processos, quando os funcionários operacionais seriam mais indicados para explicar e definir as necessidades e funcionamentos das áreas. Estas situações se agravam quando, durante a fase de desenvolvimento do software, regras e requisitos tem a necessidade de serem alterados. A possibilidade dessas alterações muitas vezes significa muita perda de trabalho e o recomeço de vários módulos. Nestas situações, os prazos e orçamentos acabam em risco novamente. Como a nossa área ainda é muito jovem (dissertações sobre engenharia e arquitetura de software não são datados de mais de 25 anos), é normal que esta apresente problemas estruturais. Cabe a nós, os profissionais de tecnologia, procurar implantar as regras de conduta que costumam ser mais efetivas, costumam ter mais sucesso. Procurar calcular pontos de função e utilizar métodos de desenvolvimento e projeto são práticas que podem diminuir o risco de fracasso de um projeto, devido a estouro no prazo ou orçamento, ou mesmo devido ao levantamento das regras de negócio, objetivos e funcionamentos dos processos.

Basicamente, muitos profissionais não são capacitados para entender as regras e funcionalidades que certa aplicação deseja contemplar. Levando ainda em conta a complexidade de nosso idioma, o português, existe também a falha na comunicação no que toca apresentar as necessidades e intuitos da aplicação, além dos desejos do solicitante. Conforme torna-se necessário o entendimento aprofundado do funcionamento de uma área de negócios que não TI, há uma dificuldade agravada no sucesso do projeto para contemplar a mesma. Ocorre também um grande problema na contemplação do intuito do sistema, que é automatizar processos visando a melhor e mais ampla percepção de informações gerenciais e operacionais, além de tornar mais rápidos os processos dentro da organização. Muitas vezes estas aplicações acabam por complicar e dificultar o processo operacional e acabam caindo em desuso. Nestas ocasiões podemos definir um valor muito além ou aquém do necessário para a execução do projeto, ou mesmo um prazo totalmente equivocado.

Nao quero criticar ninguem mas o problema não é excesso de documentação e sim a falta dela!!!!!!!!!!!!

Todos acreditam que TI é uma área muito simples, e existem muitos profissionais no mercado sem a devida capacitação. As novas tecnologias não são bem difundidas e as equipes mal lideradas.

O excesso de documentações, burrocracias e outras coisas q tornam o desenvolvimento chato responde à pergunta ....

Falta de Planejamento, definindo-se a especificação funcional a chance de haver problemas no projeto reduz bastante.

Bem, eu acredito que este problema, deve-se a diversos fatores que variam desde a falta do emprego de uma metodologia bem definida e séria para o desenvolvimento de sistemas e para a gestão de projetos, até a criação de espectativas nos usuários, que é sabido que não serão contempladas nos projetos. Acrdito inclusive, que a falta de definição clara das profissões que compõem a área de TI, colabora para este quadro, uma vez que não é possível exercer medicina sem ter diploma de médico, nem engenharia sem ter diploma de engenheiro, entretanto tanto o médico, quanto o engenheiro, ou qualquer outro profissional (habilitado ou não) pode ser programador ou analista de sistemas; e pior, agora pode também ser gerente de projetos. Não quero com isso generalizar, nem desmerecer nenhum profissional, somente acredito que temos que ter ordem em nossa área de TI, exatamente como as outras áreas possuem. Felizmente este quadro já está muito mais organizado do que nos idos de 1986, quando adentrei a área de sistemas. Na minha opinião, estes fatores aliados à falta de paciência dos clientes (sponsers), que geralmente não sabem exatamente o que necessitam, porém sabem que precisam para ontém e acabam "cortando" fases do nosso projeto, com o intúito de cortar "prazo" ou "custos", acabam invariavelmente prejudicando o sucesso do projeto ou em muitos casos inviabilizando-o e colocando em nós, profissionais de sistemas, um rótulo de ineficientes, ineficazes, improdutivos, em fim de "um mal necessário". Quem já não escutou este rótulo ?

O maior problema, é que mesmo com todas as metodologias e modelos de maturidade de projetos disponíveis hoje, o projeto é formado por pessoas que muitas vezes não seguem as premissas e os cronogramas do Projeto, gerando o insucesso desses processos. É por isso que a melhor coisa é ter um PMO, pois este de forma autonoma dentro da companhia pode gerar melhores controles e acompanhamento de resultados. Mas por outro lado, é necessário ter as ferramentas certas para Gestão do Portfólio de projetos e conseguir de preferencia uma solução de colaboração entre a equipe de projetos, do tipo Gerente de Projeto utilizando Project Pro, alimentando um Project Server (Gestão de projetos por portais colaborativos)e a equipe de projeto tendo interação via Project Web Acess e Portfólio Server para gerar visibilidade de BI para os Gerente de projetos e Executivos da Corporação. Seguindo essa receita de bolo e com um pitada de bom senso, os projetos teriam mais sucesso.

As metodologias estão evoluídas e funcionam bem para as etapas de projeto e construção, testes e gestão do projeto como um todo, porém o processo de levantamento de requisitos(que é a primeira etapa) ainda é feito de modo muito empírico. A tarefa de identificação e documentação dos requisitos do sistema deve ser executada por um profissional que tenha as seguintes habilidades:execelente visão de negócio, ótima comunicação e capacidade de documentar com exatidão o que foi levantado. Trata-se do analista de negócios. A questão é encontrar bons analistas de negócios no mercado

Em qualquer projeto existem pessoas envolvidas, onde cada um pode ter objetivos diferentes dentro desse projeto, incluindo objetivos pessoais. Se o gestor não souber controlar essas diferenças e alinhar a equipe de forma que a mesma funcione como uma "engrenagem", todo o trabalho feito até então pode ir por água abaixo. Todos precisam estar focados e cabe a esse gestor perceber quem está saindo dessa direção para tomar providências a tempo. Muitas vezes é necessário tratar cada recurso humano de um projeto individualmente, de forma personalizada. Com uma equipe bem definida e todos sabendo seus respectivos papéis dentro do projeto, a probabilidade de um sucesso em todas as gerências envolvidas, como escopo, riscos e prazos, é muito grande. Sou CIO de uma consultoria de TI e estamos em busca da excelência na gerência de projetos. Para tanto temos certeza de que cada um envolvido num projeto é importante para que o mesmo seja um sucesso.

São vários fatores que contribuem, mas, acredito que o principal seria a falta de comprometimento da empresa para com o seu cliente. Muitas empresas contratam 2 pessoas para terminarem um projeto que seriam necessários 5. Depois não adianta falar que a qualidade está ruim, que foi falta de experência, etc.

Primeiramente quero dizer que esse é um tema de alta significância, parabéns.

Em minha pouca experiência de cerca de nove anos em TI, percebo que a falta de processos, métodos e comprometimento são algumas das principais causas do problema, se contar o fato de algumas Empresas estarem preocupadas apenas com o quanto vão ganhar e deixam escapar a oportunidade de ganhos reais, onde todos ganham com um trabalho de qualidade, com o não retrabalho além de outros fatores. Digo isso, pois a engenharia elétrica, de construção civil e outras, conseguem entregar projetos no tempo, com as características contratadas, por que TI não, talvez por que deixemos nos influenciar ou baixamos a cabeça para coisas que sabemos não dar o resultado esperado, talvez seja hora de dizermos não e ao mesmo tempo propormos soluções baseadas em fatos, números e não mais e axiologia.

O compromisso pessoal com a qualidade nunca será nada sem que o ambiente as Empresas estejam comprometidas com a qualidade e em fazer as coisas bem feitas, afinal a velha frase faz juz, "Uma andorinha só não faz verão".

Obrigado

Quando fui contratado por uma outsource como prestador de serviços para atender uma multi-nacional de grande porte em Guarulhos para Lótus Notes, me surpreendi que na verdade a empresa não precisa de tal profissional. Precisam apenas de 1 analista de suporte PL (falha na contratação). Me surpreendi mais ainda vendo 2 analista de suporte tentando instalar o serviço speedy em uma estação de trabalho (não sabiam como instalar e nem lembraram que havia o proxy da empresa). Depois desta experiência, percebi do porque a área de TI estar essa maravilha.

Abr

Os problemas são muitos: Tem se o escopo do projeto. No levantamento funcional começam os problemas. Falta empenho dos profissionais tanto dos clientes como das consultorias para acompanhamento e definição deste documento. Falta de conhecimento dos sistemas, Gerentes e tecnicos sem conhecimento e sem experiência, troca de profissionais experientes por juniores - nem vou comentar qdo estagiários - Especificações incompletas, sem ambiente, sem usuários, sem equipe de apoio ao projeto... Prazo muito curto e projetos mal vendido... visando apenas o lucro... E assim vai,.... devagar... bem devagarinho...

Trocar um senior por cinco juniors, não é uma idéia ruim, o senior sempre estará pedindo aumentos abusivos, só por estar carregando uma boa parte dos projetos nas costas, aí ele encontra uma boa remuneração em outra empresa, legal, a empresa atual dança.

Acredito que isto acontece porque os projetos se baseiam em profissionais com formação superior, que possuem cursos de Itil, Pmi, Cobit, Iso, etc, porem não tem a sensibilidade, experiencia e nem criatividade para fazer acontecer. Estamos adotando o modelo americano, se não está no manual, para-se o projeto... Não quero dizer com isso que os cursos não são validos, mas sim que os empresários hoje dão muito valor só para isso, e deixam de lado profissionais com larga experiencia, inclusive com conhecimento do envolvimento de cada projeto com negocio da empresa.

Após 15 anos em TI , julgo que os motivos são:

1. Incompetência generalizada da equipe de pseudo-técnicos;

2. Margem de lucro absurdo das grandes consultorias de Outsourcing: - Geralmente vendem um profissional Sênior e alocam um Junior. - Ao invés de alocarem 1 Sênior, eles preferem 5 Juniors. - Geralmente o Gerente do Projeto não tem a mínima experiência como gerente, hoje em dia qualquer estagiario possue as pseudas-certificações(PMI, ITIL, etc)

Bom pessoal, após divesas opiniões que andei lendo e também postei chego a conclusão que a nossa área ainda está muito "cru" e longe de se ter um bom padrão de trabalho, cada um faz do seu jeito, vão se criando formas novas de trabalho em excesso e cada vez mais ficando longe de se ter uma boa forma/padrão de trabalho... Mesmo estando ha 22 anos na área vivendo projetos desde que não tinha metodologia até os tempos atuais com metodologia; observo que não se levam a sério os projetos mesmo com a eficiência do uso da metodologia...,se não existe uma politica correta do uso ai fica no uso "meia boca"... E ai concordo com diversas opiniões do forum sobre acelerar prazos para entregar ao cliente,não renegociar escopo(valor/prazo) no decorrer do projeto, subestimar cronograma ref. a alguns gerentes que não escutam sua equipe no inicio do projeto...bom deixa pra la ... tem muita coisa para falar.. Bom para alguns(sem generalizar) o que importa mesmo é que já existe a versão 999.999 da metodologia sei la ou a versão 999.991 da linguagem XXXXXX e assim caminha a nossa área de TI...

Trabalho em uma empresa CMMi5, pelo menos 90% dos projetos são entregues no prazo, com qualidade e com satisfação do cliente.

O que ocorre com os outros 10% ?.

1) Cliente dificil, que tem politicas de TI que envolvem terceiros e que quando vc assina o contrato vc nem fica sabendo que existe.

2)Usuarios que são verdadeiras caixas-pretas, quando o sistema esta entrando em Homologação,resmunga que ta faltando tal coisa

3)Usuarios que agem de má fé com medo de perder o espaço conquistado por causa do sistema novo....

Enfim,posso afirmar com certeza que a falha de um projeto nao dar certo é culpa exclusivamente de PESSOAS, não de tecnologia,de grana,de prazo,de empresa X ou Y.

Realmente não é um mundo perfeito,mas existe mundo perfeito em outra area ?

Sai tudo errado pois todos acreditam na mentira que é só apertar um botão.

1) O usuário sabe o que quer mas não sabe o que precisa fazer para chegar ao resultado que ele espera, mas ele vê as propagandas dizendo que é só apertar um botão.

2) O Vendedor conversa com o usuário e demonstra que o que ele quer é simples e a empresa dele já fez várias vezes, o pessoal tá cansado de implantar este tipo de projeto, ele tem um pessoal que vai montar um negócio que ele só vai ter que apertar um botão.

3) O Diretor financeiro do usuário que pediu o projeto não quer pagar o quanto vale, já que o projeto é simples demais, basta apertar um botão.

4) A empresa de TI precisa vender mas se colocar e cobrar as horas que o pessoal de TI pediu ele não consegue vender, então corta pela metade o tempo pois afinal de contas... o pessoal tá querendo enrolar, é simples... é só apertar um botão.

Em resumo... A lei da gerson (O importante é levar vantagem em tudo) em TI chama-se assim:

É SÓ APERTAR UM BOTÃO!

Vou repetir um comentário de alguns anos passados, lembrando as Leis de Murphy. Creia, a melhor técnica é aquela que realmente funciona para você, mesmo que ninguém acredite que funcionou como você disse.

Vejamos alguns princípios básicos:

O tempo que demora para executar uma tarefa é 3 vezes superior ao inicialmente previsto. Se ao calcular a duração da tarefa multiplicar-mos por 3 o tempo previsto de modo a obter o resultado correto, nesse caso a tarefa demorará 9 vezes esse tempo.

Os primeiros noventa por centro do trabalho tomam noventa por centro do tempo, e os últimos dez por centro tomam os outros noventa por centro.

O cumprimento dos prazos de execução é inversamente proporcional à rigidez do organograma.

O atraso encurta o trabalho e transfere a responsabilidade para outra pessoa (a autoridade que determinou o prazo) O atraso reduz a preocupação, já que o nível de qualidade desejado deixa de ser o melhor possível e passa a ser o melhor possível dentro do prazo limitado. O atraso evita os outros trabalhos. Como o trabalho está atrasado, os envolvidos nele não recebem novas ordens. O atraso é capaz até de eliminar o próprio trabalho se a necessidade do trabalho desaparece antes de estar concluído.

Se você for esperar o motivo certo para fazer alguma coisa , nunca fará nada.

Quando se tem muito tempo para começar um trabalho o primeiro esforço é mínimo.

Tudo leva mais tempo do que todo o tempo que você tem disponível.

Só sabe a profundidade da poça quem cai nela.

Se você é capaz de distinguir entre o bom e o mal conselho, você não precisa de conselho.

Quem achar que estou apenas brincando nunca trabalhou a sério. (risos).

Abraço

Projetos de TI são complexos por definição. Independente de ser um projeto de TI ou não, há algumas premissas importantes para que se tenha sucesso em um projeto:

1) A empresa realmente quer mudar? 2) TI é vista como área estratégica para a organização? 3) Existe um plano de negócios bem definido pela organização? 4) Os gerentes e os usuários chaves têm poder de decisão ? 5) O projeto foi bem planejado, com EDT bem detalhado e análise de riscos clara e de conhecimento de todos?

Se nada disso existir em uma empresa ou parte deles, o projeto está fadado a acabar ou simplesmente o produto ou serviço a ser entregue será um problema maior do que existia antes. As empresas, leia-se, pessoas que existem nela, precisam acabar com a falta de uso de metodologias e acabar com o emprego do imediatismo exagerado. Tem ações que não podem ser efetuadas do dia para a noite.

Muitas vezes, o cliente tem vaga idéia daquilo que quer. Apresentam planilhas com informações sintetizadas sem terem o dominio necessário para detalhar as entre-linhas das informações. Associa-se a isso a falta de conhecimento técnico sobre TI, pois acreditam que tudo pode ser resolvido por um sistema, assim como estão habituados a fazer em suas planilhas eletrônicas. Quando o projeto chega às mãos do gestor, ele está preocupado em atender o cliente e pouco faz pra atender sua equipe de desenv. Acreditam que os problemas se resolve com telinhas e select´s. Não dominam a íntegra das metodologias de análise, de um projeto de banco de dados, seja modelagem ou gerenciamento; dos conceitos OOP, tão necessários à construção de aplicações complexas/extensas. Levantam todos os anseios do cliente mas esquecem de levar em consideração que a equipe de desenvolvimento também tem pré-requisitos importantes. Infelizmente, muitos gerentes ainda tem em mente apenas 2 itens: O prazo para a entrega do projeto e o prazo para a solução de problemas com o sistema já em produção e o cliente cobrando soluções urgentes para tal. Outro fator que acho relevante é a falta de integração das equipes. Já trabalhei em grupos onde todos buscavam o mesmo objetivo, mas cada um à sua maneira, sem padronização dos processos de desenv., etc. Infelizmente, em TI, "apagar incêndios" ainda é muito mais comum que prevení-los e todos esses desencontros acabam por 'minar' a motivação de toda a equipe. Ainda acho que o tempo dispensado a um bom planejamento é o tempo mais bem gasto num projeto de TI. Conheço sistemas desenvolvidos em um ano que sofrem manutenções ostensivas a quase dez, daí, como pensar em criar melhorias ou algo novo, se o foco, desde a implantação do sistema, é "apagar incêndios"?

Creio que, entre alguns motivos, podemos dizer: 1) falta de clareza no projeto da empresa contratante; 2) falta de organização por parte do profissional de T.I.; 3) Condições de trabalho não adequadas (exemplo: equipamento e recursos); 4) Motivação (por incrível que possa parecer)

-Complexidade: Projetos de software são normalmente mais complexos de que projetos em outras áreas da indústria; -Software é Abstrato: Um software não pode ser tocado ou manipulado ou observado da mesma forma que outro produto qualquer; -Requisitos incompletos: Levantar requisitos para construir um software é uma tarefa difícil; -Tecnologia muda rapidamente: Em nenhuma outra indústria ocorre uma evolução tão rápida quanto na indústria do software e da Tecnologia da Informação em geral; -Melhores práticas não estão maduras: Muito tem se feito quanto no sentido de melhorar os processos e práticas de software, mas assim como o próprio software, estas práticas são relativamente novas e ainda imaturas; -Tecnologia é um domínio muito vasto: As tecnologias envolvidas em todo o ciclo de vida do software, são muitas e muito vastas, além do que uma única pessoa possa dominar; -A experiência em tecnologia é incompleta. A experiência que um profissional adquire no desenvolvimento de software se torna defasada rapidamente. A maioria do conhecimento é adquirida no trabalho; -Desenvolver software vai além do simples ato de desenvolver: requer pesquisa, é um processo de aprendizado; -Trabalho repetitivo é automatizado: A produção de software de uma maneira geral é um processo mais automatizado do que em outras indústrias; -Construção de software significa design. Software não é construído, mas sim desenhado; -Mudanças são consideradas fáceis. Software pode ser modificado rapidamente; -Mudanças são inevitáveis. Nenhum software é perfeitamente planejado no inicio, sempre vai haver mudanças necessárias.

Fonte: https://www.fernandoamaral.com.br/Default.aspx?Artigo=52

Generalizando, depois de 10 anos como desenvolvedor.

Quem não tem a menor idéia de como as coisas são feitas e funcionam é quem define os prazos.

Após 10 anos em TI , julgo que os motivos são:

1 - Incompetência generalizada dos pseudo-técnicos;

2 - Falta de comprometimento dos profissionais envolvidos , principalmente em casos onde o modelo de operação é maldito Outsourcing;

3 - (In)Gerência de projeto mal feita. É impressionante , qualquer semi-desempregado hoje em dia se auto intitula "gerente de projetos";

4 - Falta de coragem de dizer "não".

Trabalho na area de Testes , e minha opinião, para que os prazos sempre estourarem é o seguinte. 0 - Não se tem uma medida para alicar o cronograma. 1 - O cronograma é montado muitas vezes para atender o cliente , mesmo ja sabendo que o tempo não é suficiente. 2 - As areas responsáveis por fazer acontecer, as vezes não são envolvidas ou seja os analistas, desenvolvedores e testadores. 3 - O crongorama é dados mas nem sabem o impacto da alteração. 4 - O crongorama é dado sem gordura ou seja não contempla as indas e vindas da area de desenvolviemnto e testes. 5 - Testes unitrios do desenvlvedor muito mal feito causando muito retrabalho (Não previsto no cronograma) 6 - Falta de acompanhamento diario para verificar o andamento em relação ao que se planejou e oque se realizou e como realizou.

O comentário postado por Júnior está correto. A área comercial de uma empresa é tudo. Começa por aí: se o comercial não for competente o bastante para vender um projeto, que leva em consideração margem, não podem ser consideradas horas extras ou mesmo banco de horas para suprir projetos com prazos subestimados. Além disso, as empresas se preocupam muito em burocratizar os processos que contemplam qualidade, deixando muitas vezes de lado o mais importante: os entregáveis. Como tenho presenciado nos últimos anos, a rotatividade de profissionais também tem sido constante e faz-se tanto pela falta de conhecimentos específicos em tecnologias e processos. Tudo isso é dado ao grande avanço sofrido pela área e pela necessidade de atualização constante de conhecimentos. São vários fatores que levam ao grande stress que nós profissionais de TI sofremos, pois tudo está relacionado a custo, prazo, qualidade e experiência. É muito importante mitigar os impactos causados por essa relação desiquilibrada que tem deixado o promissor mercado de TI muito enfraquecido.

Muitas vezes se estabelece um prazo sem ser levado em conta fatores externos, ou até mesmo imprevistos que acontecem em qualquer projeto. Há também a questão de que o ser humano só consegue ter uma produtividade maior quando se aproxima o prazo final, a maioria das pessoas costumam fazer as coisas na ultima hora, cabe principalmente aos gerentes saber lidar com esse mal costume, isso se eles mesmos também não estiverem "contaminados" com essa "imcopetencia".

PELA MILIONÉSIMA VEZ VOU FALAR : VENDAS MANDA ... TI OBEDECE e o resto é PMI, CMI ,ITIL, TABAJARA metodologia e ai vai..RS. Ja expressei minha opinião e vivencia em projetos ou iniciando no corre corre ou iniciando bem mas sendo "atropelado" no decorrer do projeto pelo gerente FICANDO de mãos atadas por não poder alterar o cronograma por mudança de escopo do cliente e ter de seguir ordens superiores...DIRETORIA/ATENDIMENTO/COMERCIAL; Concordo também com a colocação feita pelo CWLO logo abaixo:

-Tenho mais um item a acrescentar: a falta e dificuldade no processo de estimativa e pré-venda. Normalmente nao se envolvem as pessoas técnicas necessárias ou mesmo quando se envolvem existe o problema de estimar uma solução com arquitetura e cronograma de um dia para o outro. sem falar do fato de que normalmente o ponto de partida é o levantamento feito por vendas em uma reunião de meia hora. Quem nunca teve de ouvir da área comercial que "se não for nesse prazo não vai vender" ? ----------------------- - Portanto qdo o cliente tiver meios judiciais mais fortes referente a um projeto em não conformidade; ai sim todas as areas envolvidas vão pensar 3 vezes antes de acelerar para entregar algo e TI ser mais consultado.

Tecnologia e Metodologia são instrumentos, cada vez mais importantes, para o atingimento de resultados com qualidade, no prazo acordado e ao custo previsto. Ocorre que, atingir metas, não depende única e exclusivamente desses fatores, que a meu ver, são secundários. Primeiro é preciso adotar uma política, seguida de estratégias de atendimento. Os Srs(as) devem estar de acordo comigo no ponto em que dimensionamos recursos necessários ao atendimento das demandas, quando temos uma previsibilidade muito boa da mesma, o que não ocorre quando a "torneira" nunca fecha, ou quando prioridades são modificadas a cada instante, e, em especial, quando as pessoas executoras de tarefas acordadas e tarefas emergenciais, são as mesmas pessoas. Entendo que enquanto as organizações não submeterem toda nova demanda à apreciação de um comitê que possa avaliá-las em função de sua importância para o negócio e não apenas para o seu solicitante, comitê este que tambem as aprove com base em análise de custo benefício, mesmo que intangível, e que por fim, seja este comitê responsável maior pela gestão desse cronograma, a área de TI continuará sendo taxada de não cumpridora de prazos. Espero que minha opinião possa ter contribuido para com esse tema. Até breve. Paulo Barão.

Se cada profissional se conformasse em atuar em sua área e não ficasse tentando se adequar à moda, com certeza todos fariam seus trabalhos mais bem feitos. Sou Administradora e fico frustrada ao perder uma oportunidade na minha área(Processos), para um profissional que tem formação em Pedagogia e fez um curso de Gestão de Projetos! Eis um dos motivos para a falta de cumprimento do planejamento, pois esses profissionais não detêm muito o conceito de planjamento, muito menos de execução do planejado. Será que sabem o significado de PDCA?

Desculpe mudar o assunto, mas foi perguntado: O que é TIC Tecnologia da informação e Comunicação SIGLA ATUAL para TI e Telecom.

Porque tem muito cacique e pouco índio...........

Tenho mais um item a acrescentar: a falta e dificuldade no processo de estimativa e pré-venda. Normalmente nao se envolvem as pessoas técnicas necessárias ou mesmo quando se envolvem existe o problema de estimar uma solução com arquitetura e cronograma de um dia para o outro. sem falar do fato de que normalmente o ponto de partida é o levantamento feito por vendas em uma reunião de meia hora. Quem nunca teve de ouvir da área comercial que "se não for nesse prazo não vai vender" ?

A resposta é simples. POBRE LEVANTAMENTO DE REQUISITOS por parte do analista de requisitos e pelos levantadores de requisitos escolhidos, dificuldade de organização das informações levantadas e pouco uso de técnicas e métricas de engenharia de software.

Acredito que hoje as empresas ou donos do projeto ainda tem muita dificuldade em definir sua verdadeira necessidade. Primeiro abre-se o projeto sem um escopo bem definido. Ai se cria um novo projeto para corrigir o anterior. A palavra é "escopo" bem definido. A respota é objetivo.

As empresas e equipes tem criar a cultura que um projeto é pontual ou uma tarefa então deve ser finalizado.

Uma coisa que apenas estudei e não vejo ser praticado é o estudo dos projetos que falham, na maioria das vezes são colocados de baixo do tapete. Não apredemos nem pontuamos os errors....por tanto continua a se errar.

Concordo com a Bianca e acrescento que nomenclaturas e SIGLAS atrapalham o entendimento do projeto a propósito Bianca o que é TIC?????

O sucesso de um projeto TIC: O profissional de TIC deve ser analista de sistemas, especialista no negócio e focado em melhorias de processos para poder aplicar no projeto(produto final). Motivos: 1) Cada empresa tem suas particularidades em executar determinadas tarefas, sendo assim, é imprescindível que além do levantamento de informações seja feito um acompanhamento/observação da execução das rotinas com os usuários finais envolvidos.

2)Colocar-se na posição do usuário para prever funções na ferramenta que facilitem a execução das tarefas ou obtenção de informações.

3)Existem usuários DE TODOS OS NÍVEIS que não sabem o que querem, como melhorar processos e quais informações seriam importantes

4)Escolher programadores que dominem as linguagens o bd e o ambiente.

5) As ferramentas para o desenho do sistema são apenas um detalhe. O que importa é o nível de experiência da equipe TIC.

Sempre o cliente vai achar o investimento alto e o projeto muito longo, mas esse é o caminho certo. Minha sugestão é que nos especializemos em determinada área e tenhamos um sistema, ferramenta, software seja lá o nome, pronto, para ser customizado.

O Recem contratado , que tem qualidades como : pro-ativo , diferente , dinamico e etc ;para tocar um projeto , quando encontra dificuldades como falta de apoio da gestão , é tachado de 'low profile' quando não consegu levar pra frente , vi isso num grande banco , coitado do profissional , se queimou , tinha pedido a conta de outra grande banco, e acabou pedindo a conta....., Em outra grande empresa de TI , tinha um 'projeto' boca podre, tipo queima-filme de PM , passaram '8' (OITO PMs ) em 3 meses ! , o projeto era somente pra 'ingles' ver que tavam fazendo algo pelo cliente...Todos os profissionais se queimaram.

Falta profissional competente. Vejo por experiência própria nas empresas onde trabalhei.

Na minha opinião os profissionais não estão sabendo usar as ferramentas adequadamente. Existe tambem muita burocracia e enganação, e ate equivocos sobre a propria capacidade por profissionais de diversas camadas. Cada vez mais os desenhos precisam ser mais explicitos para uma clara compreensão do que se pretende. A tecnologia existe para simplificar e não para complicar. Poderiamos ser um pouco mais simplistas em alguns aspectos e tomar cuidado para nao ficarmos perdidos nas sopas de siglas e no vocabulario sofisticado sem nada somar.

Falta de um bom Gerencimento de Projetos

Acredito que o problema não esta na tecnologia ou metodologia, mas sim nas pessoas que são responsáveis pelos projetos e pela própria empresa. Vivemos numa cultura onde o mais importante é o faturamento/lucro que na própria organização das equipes. O mais incrivel é que os problemas que ocorrem posteriormente nao fazem parte do balanco final do projeto.

E concordo plenamente com o amigo Ezequiel. "somente há má profissionais fazendo parte de um time quando o gestor é péssimo".

Infelismente a maioria dos gestores desses projetos acabam tendo atitudes arrogantes e prepotentes. Muitos tem esse comportamente com medo de demonstrar suas própria limitações.

Os prazos estouram por falta de capacidade dos responsáveis pelos projetos ou por interesses políticos dentro das organizações. É comum em uma entrevista o entrevistador dizer que procura alguém diferente, proativo, responsável. Porém se você é contratado e é mostra-se diferente dos demais sem apoio daquele que o contratou, sem apoio da empresa. Você fatalmente será demitido. Em resumo, os projetos atrasam por incompetência da equipe, pela cultura da empresa, pelo vício dos profissionais e por má gestão. Costumo dizer que somente há má profissionais fazendo parte de um time quando o gestor é péssimo.

O dia-a-dia e as exigências do mercado, dificultam nossos dirigentes de encontrarem tempo de planejarem e elaborarem planos que possam trazer significativos resultados. Os projetos exigem alinhamento estratégico e definição de prioridades, de acordo com as metas da companhia, o que às vezes, são focadas em determinados setores ou às vezes, para tomadas de decisões emergenciais. Como às vezes é demorado a decisão de aprovação dos projetos, os eventos contribuem para que o Custo X Prazo e Escopo, não surtam os efeitos desejados.

Nos dias de hoje as empresas procuram um analista desenvolvedor, onde ele analiza, desenvolve, testa, fala diretamente com o cliente, poliglota. Mas quando ele sai do projeto (ou ocorre algum imprevisto), a empresa fica na mão. Se ele faz isso tudo, pra que serve um lider de projeto.

Talvez a melhor resposta seja uma analogia, para com os governos e mundo atual: estouram devido a ganancia dos responsáveis, com interesses pessoais finaceiros e de poder, no qual parte dos sub-alternos os apoiam e se beneficiam, ficando o resto do povo a ver navios. Uma escola ou hospital com computadores moderníssimos não ensina nem cura quem precisa; quando um projeto tem objetivos desfocados, governos e empresas se tornam deficitários, e, o resto já sabemos.

Trabalhei em uma empresa onde tinham ferramentas fantasticas, uma metodologia ótima, mas faltavam profissionais experientes, os analistas eram todos jovens e aprenderam tudo dentro da empresa, quanto a isso tudo bem, mas mandavam eles para projetos complexos sem a supervisão de uma pessoa com mais vivencia, vi coisas absurdas acontecendo e muitos faziam pose , dando a impressão que eram bons profissionais, não aceitavam dicas e se sentiam ofendidos quando tentava ajudar,vejo isso sempre pelas empresas por onde passo, pela falta de mão de obra especializada treinam um estagiário por no maximo um ano e já colocam eles na frente de batalha.

Os problemas são varios, creio que os principais são: 1 - Area executiva/gerencial, formada por pessoas que não são da area. 2 - Falta de Planejamento de cada etapa do desenvolvimento, inclusive deixando de lado etapas essenciais para o bom andamento do projeto. 3 - Corpo técnico muitas vezes teoricos demais e por conta disso, criando aplicações de dificil implementação tanto evolutiva e principalmente corretiva. 4 - Cronogramas com datas,etapas e custos incoerentes. 5 - E o principal, muita politica em todos os niveis, os famosos amigos dos amigos e dos amigos.

Falta de Planejamento adequado de ambas as partes, fornecedores e clientes não se planejam adequadamente, depois é inevitável acontecer problemas como o descrito acima.

Nao concordo meramente em apontar PESSOAS como o problema, tanto pelo fato de nao podermos eliminar o problema "substituindo" as pessoas, quanto por generalizar o fator "pessoas" como foco do problema, o que nao é o caso.

Mais sabio seria aceitar as possibilidades de erro humano, e contorna-los pelas metodologias ja aplicadas propriamente para evitar esses erros.

A comunicação seria um fator relevante, pois no momento em que ela nao ocorre, nao temos mais as formalizações das necessidades - preponderantes ou nao - do projeto, e o devido apontamento dos culpados.

Nao me entendam mal, mas para os que ja possuem certa bagagem de conhecimento e experiencia, a definição de culpados chega a ser primordial em diversas fases da elaboração e entrega de serviços, justamente para sanar rapidamente os focos de atraso e auxiliar em uma possivel analise de tendencias.

porque o departamento de vendas é submisso, os analistas mal preparados, os gerentes carrascos e os programadores mal-informados.

Creio que seja uma conjunção de problemas, em alguns casos fornecedores que prometem muito (além do que de fato podem entregar)e clientes que ao contratarem o fornecedor não se envolvem como deveriam nos projetos, passando a responsabilidade (e culpa) ao fornecedor.Em projetos planejados e implementados a 4 mãos (fornecedor + cliente) os riscos tendem a ficar sobre controle.

O principal motivo dos atrasos são as PESSOAS, não tem nada a ver com tecnologia.

Em alguns projetos, somente foi possível entregá-lo (com atraso!) após a troca de PESSOAS,

E notei o seguinte círculo vicioso:

PESSOAS acham que simplesmente implantar um sistema resolverá seus problemas, sem rever seus processos. E vão atrás de sistemas. Já as PESSOAS que vendem, que não querem perder o negócio, contrata PESSOAS inexperientes, para gastar pouco. Neste momento, conhecemos os Consultores Seniores de 20 anos de idade (concluindo o TCC). Tudo isso gerenciado por uma PESSOA que quer cumprir o cronograma de qualquer jeito - afinal, o Project tem apenas status cronológico, e não qualitativo. Durante o mapeamento, tem as PESSOAS que não querem o sistema, que resistem a passar qualquer informação. Normalmente, nesta fase, tudo é muito simples, parece que essas PESSOAS nem trabalham. Já na fase de validação, estas mesmas PESSOAS, começam a solicitar todos os específicos que não foram mapeados, porque essas PESSOAS lembraram de particularidades impeditivas. Neste momento, a PESSOA que gerencia refaz o cronograma, e a PESSOA que vendeu a solução, procura as PESSOAS experientes, por que o cronograma refeito, foi "enxugado" em 50% pela PESSOA que comprou. Neste momento, proferem-se palavras como "desafio", "pressão", "disponibilidade", "engajamento" pela PESSOA que gerencia para as PESSOAS experientes. Afinal, as PESSOAS inexperientes já estão em outro projeto.

Fica até difícil escolher que PESSOA trocar.

Isso aqui mais parece confessionario do que forum... Respondendo a PERGUNTA DO FORUM, acredito que devamos dividir a resposta em partes. O 1o ponto é que o fator "paciencia" nao exista como referencia em clausula de contrato nenhum, ate por nao termos como prever situações provocadas pelo contratante ou pelo contratado. Como o escopo do serviço é a entrega do mesmo dentro de condiçoes e prazos determinados em contrato, elimina-se a paciencia, tendo em mente apenas a excelencia do serviço prestado. O 2o ponto trata da parte que ressalta as novas tecnologias e metodologias. Quando "eramos poucos no mundo", tais tecnologias e metodologias coexistiam de maneira timida para a necessidade da epoca. Pois bem, essa necessidade aumentou, mudou, criou novas formas e contextos, e as ditas tencologias e metodologias adaptaram-se às novas necessidades. E elas fazem apenas isso, dão a faca e o queijo - tecnologia - e ensinam a fazer o corte - metodologia. Mas e se, ainda assim, continuarmos cortando o dedo? Entendido o problema, o 3o ponto trata do que acredito ser a solução. Os estouros de prazos e orçamentos ocorrem pela FALTA DE COMUNICAÇÃO entre as áreas envolvidas no projeto, por parte do contratado e do contratante. Sem a participação pro-ativa das equipes envolvidas e com falhas na formalização de novas necessidades entre as partes, a entrega do serviço - principalmente os que estiverem "ongoing" - será, em termos de contrato, seriamente comprometida.

Pura incompetencial! Inclusive gerencial. A ganância de fazer o mais rápido sem qualidade técnica...serviços sem pé nem cabeça. Hoje em dia todo ser humano que utiliza um computador para qualquer função, já se considera um profissional da área.Demora muitos anos para realmente ser um programador de aplicação ou um analista de sistemas. Já ouvi de alguns que, por exemplo, o sistema de contas correntes bancário é simples de fazer!!!!!!

Acredito que seja justamente porque os HUMANOS não estudam e se atualizam para aplicar as novas tecnologias e metodologias. Temos Orientação a Objetos desde 1960, porem esta só explodiu a partir de 1990, com o JAVA e INTERNET. Nas decadas de 60,70 e 80 o domínio foi da metodologia ESTRUTURADA e mesmo assim sabemos que vários projetos foram executados dem Diagrama de Contexto, Diagrama Hierarquico de Processo, Diagrama de Entidade Relacionamento. Ou seja, muitos foram criados a partir de descrições verbais dos usuários ou analistas diretamente passas ao programador. Tudo é uma questão de TAMANHO DO PROJETO, grandes projetos com pessas altamente especializadas, conseguem aplicar algums métodos ou técnicas modernos, enquantos pequenos projetos obviamente não se beneficiam do uso ou adoção deste métodos ou técnicas. Como resultado, temos estouro de prazo justamente por falta de adoção de ferramentas de controle tais como cronograma devidamente atualizado e renegociado ao longo do projeto de software.

Porque todos estes itens são dependentes de outro fator: Humanos. E humanos, independentes de "novas tecnologias e metodologias" - ERRAM. Que bom né... No dia em que não errarmos mais, seremos mais "robozinhos tecnológicos, mais metódicos"... Mais medíocres.

Vendo todos esses relatos me pergunto : raramente chegamos a ver projetos atrasarem ou mesmo nao serem entregues em grandes empresas, sérá que porque as grandes empresas investem muito no maio capital que uma empresa possue, o ser humano, será quie isso ocorre porque contratam bons profissionas com salarios descentes e compativeis com a responsabilidade que o profissional vai desempenmhar, sim é isso , e sabe porque ocorre o contrario, justamente porque 90% dessas empresas que tocam projetos contratam mao de obra barata, despreparada, só pensam em custos e seus lucros sejam quais forem , em detrimento de sua ganância que só afunda ainda mais o mercado de trabalho para profissionais de T.I

Porque muitos analistas de negócios não sabem do que precisam e como precisam. Sou consulta de implantação, atendo vários projetos e a novela mexicana se repete..... O cliente quer adotas conceitos antigos, pra atender uma necessidade antiga, seja contábil, seja financeira, enfim....

Implantação combina com mudanças, seja de hábitos, de processo, de tecnologia. Acredito que para a maioria deles ainda não caiu na real. Implantar melhorias, seja de processo, ou de sistemas.

Não há o envolvimento do Gerente de Projetos, desde o início, não há identificação correta dos stakehouders, e com isso não se consegue fazer a identificação e o levantamento correto dos requisitos, definindo-se assim o Escopo do Projeto corretamente. E há outro fator preponderante é a equipe que irá tocar o projeto, o Gerente de Projetos tem que ter muita habilidade com relacionamento humano, para conduzir o projeto até o final. Sem falar em previsão dos riscos e na mitigação destes, além do que projetos por serem inovadores, sempre vem acompanhados de incertezas.

Algumas empresas despreparadas, aceitam o que o cliente está solicitando e não entendem que, na verdade, é necessário uma orientação para este cliente das ações e comportamento que o próprio sistema terá nestas condições. A maioria das empresas só olham o valor do contrato.

Infelizmente, enquanto não for regulamentada a nossa profissão, haverão muitos picaretas trabalhando sem qualificação e tomando lugar de gente séria e que gastou os tubos em treinamento.

Acredito que com isso as Consultorias terão que trabalhar corretamente e deixar a gente trabalhar direito, com prazos decentes e metodologia corretamente seguidas...

Normalmente, os clientes querem projetos autocontroláveis ou automodificáveis. E, o comercial afirma que é possível. Então, .... Aí ..., Ah ! Deixa p'ra lá. Não paga a pena continuar.

Porque existe o plano de manutenção de sistemas, alias alguém tem que garantir o leite das crianças....

Na hora que for inserido um Projeto de TI como um Produto com normas de direito do consumidor no que diz respeito a qualidade, garantia e etc.. igual a um produto que compramos e temos o direito de acionar judicialmente; Ai quero ver Diretor de TI /Vendas/Comercial ter coragem para chegar em reunião e dizer para Gerente ou Analista : "Po meu esse prazo não da o cliente não vai aceitar renegociação de prazo vamos acelerar e entregar e depois vcs correm atras das correções"; Acredito que ai sim teremos as "Forças Maiores" dizendo : "Vamos seguir a Metodologia direito .. fazer direito..testar direito e só entregar qdo estiver OK" eu renegocio e explico para o cliente. Ja atuei em diversos projetos com bom levantamento de requisitos, bom prazo inicial estimado e etc.. andando bem, na hora do Gerente passar uma mudança de prazo adequado devido a uma mudança de Escopo do Cliente; Ai vem a Diretoria e dita : Mantém o prazo e faz "força tarefa" para entregar na data p/ o cliente; AI ACABOU DE NAUFRAGAR UM PROJETO, vi muito gerente se lamentar de estar com as mãos atadas... por isso não culpo tanto gerente de Projeto.. são simples "fantoches" para fazer a coisa andar....

Boa tarde,

Prefiro pensar nesse tipo de assunto da seguinte forma: inúmeros desenvolvedores em inúmeras empresas visando somente sua realização profissional. Desenvolvendo somente código, não se preocupando com os prazos que são imprescindíveis para o término do processo, e outra, ainda temos profissionais sedimentados em suas funções e nem um pouco preocupados em aprender mais e se aprimorar, onde trabalho, é o típico local onde isso ocorre, os funcionários nunca sairão de suas posições e nem adianta tentar implementar novas metodologias, ainda precisamos de muita mudança cultural em nossa área de atuação.

Eu costumo comparar a engenharia de software com a engenharia civil.

A engenharia civil tem centenas de anos. A de software ainda engatinha.

A engenharia civil utiliza basicamente as mesmas técnicas e materiais de sempre, encontrados na natureza. A engenharia de software vem tentando fixar os pés num terreno que muda todos os dias. As ferramentas ainda não foram consolidadas, muita coisa surge e desaparece do dia pra noite.

Ademais, vez ou outra, um prédio desaba ou uma estação do metrô desmorona.

Trabalho numa empresa em que a análise de requisitos nunca é suficiente. Podemos passar anos colhendo os requisitos do projeto, eles sempre mudarão. A verdade é que os usuários querem apertar um botão que resolva toda a vida deles. Isso não existe. Já aconteceu de uma proposta ser entregue, o cliente aprovar, o desenho funcional também, com comprovações por email e no momento dos testes, o cliente dizer que não era nada daquilo que ele tinha pensado...

Tales meu caro,

Voce falou uma verdade: e como tem gente trabalhando de Programador ... Quando deveriam estar advogando, psicologando, pedagogicando, etc !

Ouvi um RH uma vez me dizer que a tendencia do mercado era contratar pessoas de outras areas pra servir de analistas ... Que as minha experiencias nao contavam tanto no contexto de mercado ...

Olha ai a mer ...que ta!

Acho que é porque tem muita gente que nao é da área trabalhando em informatica... Tipo formado em Direito, formado em Letras... Só entram na área para tirar lugar de quem é formado em informática! Ai não sabe muito bem o que estão fazendo e estão no projeto para aprender a fazer e não para agregar.

Eu vivi na pratica tudo isso, trabalhei numa BIG empresa de TI , a segunda do mundo ,com 90 bilhões de dolares anual de faturamento , quando trocou a presidenta/CEO , o novo presidente congelou todos os projetos de TI , houve um pente finíssimo , ele dizia que a maioria dos projetos de TI não tinham fundamento e estavam condenados, e que se gastava demasiado com isso , tudo virava projeto , coisas que não eram necessárias , ele tinha razão , muita gente teve que se contentar e ficar com o que tinha e nada de criar projetos atoa , somente por capricho...

Acho que nao leram o post na integra.

Quanto ao Cobol e DB2, eram as unicas opcoes da epoca, quando a IBM populou o planeta com suas solucoes proprietarias amarradas.

Hoje, a maior parte das linguagens atuais sao bem mais rapidas/estaveis que Cobol, benchmark com DB2 é brincadeira, nao da pra comentar (sic).

Quanto ao fator virus, nao existe ou nao tem condicoes de identicar? Nao posso chamar um arquivo em lote de virus (de macro, por exemplo)?

Ai claro, vai depender da "qualidade" de quem escreveu as instrucoes Batch.

Legado é legado, mas se recorrer ao tempo, vai descobrir que a bolsa desligou recentemente seu ultimo mainframe, idem ao Joquei de SP (que foi o primeiro a ser instalado no pais), e outros cases pelo mundo...

E so pendurar o ambiente em qualquer solucao Unix (independente de fabricante) que a coisa flui que é uma beleza...

Simplesmente, novo, nunca foi sinonimo de eficiente. Por este motivo, implantar algo, somente porque 'e novidade, nao significa nenhuma melhoria, isso na melhor das hipoteses, pois muitas vezes a coisa piora. Por isso uma tecnologia ou metodologia deve ser implantada por ser necessaria e nao por ser novidade. Fora isso esta tecnologia deve ser implantada por pessoas competentes, que sabem sobre a tecnologia e principalmente sabem sobre o negocio sobre onde ela devera ser implantada, pois na maioria dos casos com a terceirizacao, uma pessoa que 'e expert na tecnologia, nao tem a minima ideia do negocio que estara interferindo, e isso 'e sinal de mais problemas. Hoje em dia, como as empresas sao sociedades anonimas, os verdadeiros donos das empresas nao tem a minima ideia das bobagens que as diretorias executam, desde que de alguma maneira apresentem lucros, sem saber que estes lucros poderiam ser muito maiores se as empresas fossem melhores gerenciadas, e quando o lucro cai, geralmente a coisa ja esta feia, e vemos acontecer o que esta na midia agora sobre grandes empresas como General motors e outras em concordata...

Tenho certeza em um exemplo um Sistema ERP a equipe de TI tem que envolver todos departamentos no cronograma.

Infelizmente hoje em varias empresas principalmente as Grandes empresas os Gerentes estão muito defasados profissionalmente e não estão se atualizando com o mercado e estão a muito tempo 5, 6 até mais de 10 anos e ficam acomodados.

hoje os jóvens estão se atualizando e felizmente estão substituindo estes profissionais.

Mas hoje a maior demora de um projeto é o não envolvimento de todos em uma empresa assim prejudicando a imagem do departamento de TI.

É que os projetos não são planejado corretamente. Os Gerentes que os gerencial não elaboram plano de gerenciamento prevendo alterações de escopos. Via de regra o escopo é alterado e a data de entrega continua a mesma.

Quando se tem um ponto fraco na história, pra quem vai a culpa toda? É claro que a TI fica com a culpa dos requisitos que foram adicionados, das dúvidas do usuário, das incertezas no escopo, da falta de compromisso do cliente com o projeto, tudo isso é culpa da TI. O engraçado é que este cenário complexo não muda. E conto até um caso: reunião na semana passada, o usuário não tem certeza do projeto e quer um cronograma que não mude, ou seja, como podemos dimensionar custos e cronograma com base em uma dúvida do Cliente, paciência né? Creio que os profissionais de TI trabalham muito bem, mas a cultura tem que fazer parte de quem não é da TI, pois a responsabilidade do projeto deve ser compartilhada. No mais, creio que este assunto gera uma barreira incrível entre os profissionais de TI e os clientes. A TI por seu lado diz que "o Cliente não sabe o que quer ou não soube pedir", o Cliente por sua vez dizendo que "Eu pedi de forma diferente, a TI que não me entendeu". É muito "pano para manga..."

Compre feito no Brasil.

De Brasileiros de verdade.

Brasileiros compromissados com a causa social.

PMP, PMI, CTPA, PGP ... Bull Shit ! E Nao nas faquiudades ...

E pra ajudar, os nossos velhos, Italianos/Alemaes/Franceses/Japoneses, que trouxeram alguns valores Europeus e Japoneses pra contra atacar essa influencia norte-ameridana, estao todos morrendo.

E nao acredito novos Imigrantes do velho mundo, estariam muito animados pra vir ao Brasil novamente ! E' realmente uma pena tudo isso, para Brasileiros nazionalistas que somos !

Pq? Conto-te Pq... Morei 15 anos fora e faz 5 que estou de volta. Sabe oque pude notar? Que O Brasil como nação não tem valores.

Ou se perderam.

Honra, Mérito, cronograma, trabalho e honestidade técnica estão em qualquer lugar menos na cabeça das pessoas, nem nos corações.

Matriculei-me em um curso de Tecnologia em uma Universidade local, e vejo as barbaridades acontecerem na sala de aula: Preconceito, Desinformação, e oque e' pior: arrogância de entendimento - por parte dos professores.

As pessoas são mal formadas, e chegam a ensinar. Oque os novatos vão aprender com esses tipos ignorantes? Por... nenhuma. Eles estão desaprendendo! E' essa universidade o problema? Não sei.

Saem das Faculdades e vão trabalhar com que valores? Cronograma? Honestidade de Previsão do Termino? Essas coisas se perderam.

Outro fator importante: fomos influenciados por multinacio-anais, como Bancos Americanos por exemplo.

Bancos que trouxeram a política de maquiar a contabilidade, maquiar relatórios, maquiar empréstimos. Oque aprendemos? Na escola nada, no trabalho pior ainda.

Como resolvemos?

O Governo deveria fiscalizar essas Instituições Internacionais e cuidar pra que não desensinem nossa mão de obra. O Governo deveria incentivar o emprego em Firmas de capital estritamente nacional.E' importante para paises como os EUA que nossa mão-de-obra seja totalmente inutilizada. State Department? Maybe...

Fiscalizar a mão de obra desensinada dessas multinacio-anais, como Gerente de Bancos, Gerente de Projetos, para que não saiam por ai se achando no poder de ensinar.

Ia me esquecendo: O Ministério Publico que e' pioneiro em ações de classe, deveria cobrar o Estado Americano pelos danos causados por essas empresas a nossa massa de trabalhadores e recentemente graduados.

O probelma que a culpa sempre é da TI, quando se quer achar um culpado pelo atraso do projeto. Todos os projetos que trabelhei o cliente sempre colocava mais e mais requisitos sem esticar o prazo de entrega e depois a culpa sempre era da TI.

Não sei se em todo mundo é assim, ao menos meus amigos que estão no Canada estão bem felizes, trabalhando com projetos que já foram levantados há meses atrás e com os prazos acordados e assinados e quaisquer alteração tudo é renegociado, sendo assim, o cliente sempre pensa duas vezes antes de pedir qualquer alteração.

Porque existem empresas que não valorizam seus profissionais e exploram à mão-de-obra terceira, e falta de comunicação entre si.

Bom ... além do que ja venho falando sobre a Força de Vendas e da despadronização na forma de se trabalhar na área de TI, assino embaixo a colocação do Vinicius; pois é o que vemos no geral do andamento dos projetos. Na pratica o que vemos em 90% é : Entregar pro cliente que o projeto esta atrasado ai depois vamos correr atras das "cagadas". Para o Zolotareff : Se não conseguem nem utilizar o Pmi, Itil direito devido a "motivos maiores...rs" da Empresa, concorrencia , politicagem e ai vai, vc acredita que as empresa vão conseguir usar People-CMM da forma adequada ? Acho dificil heim !

Estouram os prazos pois têm algumas pessoas acham que fazem milagres, não se dão o valor que merecem e se "prostituem" para não perder o negócio, aceitam prazos curtíssimos e verbas baixas só para "deixar funcionando", e depois ficarem "se explicando"Desde que haja prazo, planejamento, conhecimentos e investimentos as chances de dar errado são muito pequena..

Att.

Os projetos estouram por falta de Mapeamento de Processos realistas - pouco comprometimento de usuários-chaves e principalmente pela direção/comitê que aperta prazos sem ter a noção precisa se o processo (especificado no projeto) foi realmente validado pela equipe de projeto.

Em conjunto a isso, a falta de especialistas em determinados segmentos e etapas do projeto é crucial para garantir a continuidade do projeto e para acompanhar a equipe do projeto, em seus aspectos de detalhamento e tomada de decisão.

Mesmo com tantas ferramentas e tecnologias disponíveis, a comunicação é falha e aquele que desenvolve não conhece tão bem o negócio em si.

Prezados,

Qualquer ferramenta de melhores práticas são importantes. Mas volto no tema chamado: Perfil.

Todas as empresas tendem a aderir novas tecnologias e metodologias, mas elas somente fazem sentido com pessoas que possuam perfil para operá-las.

Eu ainda acho que há muita gente no mercado sem o perfil para tecnologia, ou para médico, advogado, o seja lá o que for, mas sem o perfil para o que faz.

Felizmente, as empresas demoram um pouco, mas logo percebem que a quantidade investida em tecnologia, não retornou o que almejavam. É nesta hora que elas voltam seu investimento em empresas e pessoas realmente capazes de fazer, seja por histórico, seja por excelência, seja por melhores práticas.

Projetos estouram por que alguém errou no processo. Mas se os estouros estão muitos constantes, é porque ninguém sabe o que está fazendo. Seja o contratante, seja o contratado.

CUSTO , CUSTO , E CUSTO, este é o parametro de qualquer projeto, nao venham falar em Metodologia X Y Z, pque nao pratica nenhuma empresa pratica.So server para colocar um certificado enquadrado na recepcao. Magica nao existe, vender solucoes a baixo custo, salarios pifios para profissionais que precisam estar constantemente atualizados. Em TI nao há como fazer magica.

ao Sr. JackSmithAgain.

Caro Sr. JacksmithAgain, lógica não é tão importante !?!?!?! Só diz isto quem é usuario de sistemas comprados em supermercado... (deu pau ???, compra outro). Já o antigo COBOL a que voce se refere, deixe-me ver se é o mesmo COBOL que conheço a 25 anos: É o mesmo COBOL utilizado por TODOS os bancos do MUNDO? É uma das linguagem de programação usadas em TODOS os Mainframes do mundo ?? Ou será por acasou a linguagem que tem o processamento BATCH mais rápido e seguro do MUNDO (sem Hackers ou virus)?? Sr. JacksmithAgain, a lógica é a alma da nossa atividade, sem ela nosso trabalho fica restrito a "copiar e colar"... Claro, se não precisa usar a razão, se não exige inteligencia nem lógica, compra mesmo no supermercado... Te dou um exemplo: Qual das tuas linguagens modernas processa o movimento de um BANCO das 22:00 (fechamento dos caixas eletronicos) até as 06:00 hs (abertura dos caixas eletronicos) tendo que processar tabelas (DB2) com média de 200.000.000 (ou mais) de registros cada uma ??? sem lógica não há como faze-lo... Fui responsável pela triagem e seleção de profissionais de TI em uma grande instituição financeira por 9 anos... O principal teste sempre foi de lógica.

Fabula:

Um jovem e determinado desenvolvedor pergunta a um velho dinossauro (com cabelos brancos): Como voces trabalhavam ??? Hoje nos temos ITIL, PMBOK, CMMI, depuradores super potentes, na época de voces nada disso existia... O que voces faziam ??? E o dinossauro de cabelos brancos lhe responde com toda sabedoria e lógica por ele acumulada: Nós estava-mos desenvolvendo estas ferramentas que voce citou para facilitar a vida de voces...

Abraços Léo

Puxa, tantos comentários e tudo que vi é erro nos projetos, não tem nada ver sobre o cliente não saber o quê quer ou estourar o prazo, isso quer dizer um projeto mal feito, técnicas de Engenharia de Software e metodologias estão aí para ajudar nos projetos, não adianta fazer a moda brasileira que não sai mesmo, quem é da área de Engenharia de Software e já trabalhou na Europa(Alemanha, Holanda,etc), sabe muito bem que os projetos falham porque o fator principal é que são humanos que ministram o mesmo,para quem não conhece o People-CMM é o que chega mais perto de menos erros. Em minha pesquisas publiquei um trabalho sobre erros humanos em projetos na área de TI, a quantificação dos erros humanos nos projetos chegam de 70-90%, se prevenindo e usando técnicas corretas o projeto sem fatores de erros humanos em um indice menos de 10%, o projetotem 92% de chance de acabar no prazo estabelecido e no tempo. DESCULPA PARA QUEM NÃO CONHECE CALCULOS DE ERROS HUMANOS, é da área de Engenharia e envolve calculos avançados e é utilizado nos reatores núcleares e nas linhas ferroviárias da Holanda, e até agora no mundo inteiro os reatores apresentaram uma taxa de erros em projetos e tempo uma média de 5%, tudo que é acima de 90% é considerado normal.

Pessoal vou falar de novo..quem manda em Prazo e Valor é VENDAS.. o resto é levantamento de requisito , cmi, pmi, blablabla --> E para ficar mais interessante a situação; Da para ter uma área mais despadronizada do que TI ??? Engenharia , Medicina, Advocacia..acho que não..essas pelo menos possuem um padrão e não ficam inventando muita perfumaria para cada um fazer do seu jeito.. Mas em TI a coisa ta DIFICIL.. aproximadamente mais de 50 anos de existencia e em vez de evoluir para uma forma de trabalhar e fortalecer mais a área estão cada vez mais inventando metodologias, arquiteturas e etc.. diferentes, porque não tentam pelo menos usar uma metologia universal..um padrão de desenvolvimento universal e assim vai... Já começa pelo próprio cliente qdo possui um padrão diferente de envio das especificações e arquitetura para a consultoria trabalhar já precisa de adequação na forma de trabalhar de um projeto para o outro, isso é produtivo ?? Que metodologia garante uma melhor qualidade se for seguida , disso não temos duvida, mas pelo amor de Deus né chega de versão PMI 2000.3000. , COBIT 9.9999, ITIL 98888..vamos usar a TI_METODOLOGY 1.0 para todo mundo sem exceção e chega né...Aaaahhhh ja sei tem uns mané que vai falar assim : No meu projeto MASTER PLUS TABAJARA existe arquitetura soa é em 3 camadas e se conecta com a lua por isso não da para usar a genéria TI_METOLOGY 1.0 vou usar a PMI 5.000...(acabou de nascer mais uma versão ...rsrs)

Projetos estouram os prazos e custos, pois projetos de informática é algo não mensurável e tudo é subjetivo. O cliente não sabe o que quer, não sabe pedir, ja pelo lado das consultorias, não entendem o que realmente o cliente quer, e no fundo estão muito mais interessado em fechar o projeto, com o maior valor possível, oferecendo e forçando um grande escopo, para então depois passar o projeto todo discutindo e diminuindo o escopo, mas com a inteção de gastar o mínimo possível e ganrantir alta rentabilidade. Infelizmente a área de TI é toda imensurável e subjetiva, que vai desde a capacidade de avaliar e contratar recursos, mensurar projeto, avaliar qualidade, etc. Por outro lado, os envolvidos, consultores, empresas de TI e os clientes, brincam de enganar um ao outro. O consultor ganha por hora, um valor hora que a consultora jura estar se dando bem, pois não paga os exorbitantes impostos e encargos devidos, mas devido a isso não consegue garantir qualidade e produtividade de seus consultores que só querem fazer hora, por razões óbvias. As consultorias estimam os projetos baseados em horas que serão feitas pelos mesmos consultores que agora foram prostituídos, portanto não garantirão o que esta sendo vendido, ai a consultoria muito esperta novamente, promove estimulos e campanhas para aumentar a rentabilidade e entrega dos projetos nos prazos, por exemplo, distribuindo parte da rentabilidade para a equipe, que agora vai dar um jeito de fazer em menos tempo, mas como o produto não é mensurável e muito difícil de se saber se realmente foi entregue o que se pediu, bla, bla... Este assunto é muito longo.

A Colega abaixo está certa.. No final das contas, o cliente se engana achando que está levand vantagem comprando barato e a consultoria entrega um prduto ou atrasado ou de péssima qualidade. E a Acenture é um bom exemplo, ganha os projetos de manutenção evolutiva e põe um bando de recém formado.. coitado do cliente

São duas causas, hoje os clientes só pensam em custos e se enganam quando fazem leilões de projetos achando que a qualidade do projeto será mantida. Não existe mágica senhores de compras!

O segundo motivo, são é a reação das consultorias, que para venderem nesse contexto de menor preço, vendem projetos de forma irresponsável que acabam com problemas de qualidade, ou atraso, manutenção pós golive péssima etc. Um exemplo disso é a Sra Accenture que a anos contrata um monte de juniors, faz uma lavagem cerebral nos coistados, eles ficam achando que trabalham na melhor empresa do mundo e os clientes quando percebem que tem um monte de pica pau, já é tarde.

Pessoal. Logica de Programacao nao tem nada a ver com planejamento!

Tem um povo da epoca do Cobol se vangloriando de usar linguagem arcaicas, sequencias, pra nao dizer um boa parte adora goto!

Pilotar um "Project/Projekt" nao necessita de muita "logica", nada alem do que o conteudo oferecido em escolas do tipo Eurodata/People & afins.

O dificil, e olhar pra necessidade, conhecer os mecanismos, levantar os requisitos, interagir com os interessados e gerir pessoas! Ativos de TI e companhia sao "logicos e exatos". Se houve alguma besteira, alguem "programou/determinou" errado. Pessoas, possuem muito mais variaveis e que fogem do controle natural com certa facilidade.

Experiencia é experiencia, mas IDADE nao quer dizer nada. Tem muito "cabeca branca" no mercado perto da aposentadoria que esta empurrando com a barriga, e outros que nao tem mais interesse em se "novas tecnologias". Claro que a maioria nao é assim, apenas pra justificar a abertura.

Alem disso, o mercado é PROMISCUO! Qualquer desorientado faz curso e disputa vaga pra aprender (fazer cagada) em ambiente dos outros. Sem falar do pessoal multi-lingua que nao sabe nem falar portugues, mas é expert em English 'n' Spanish. Tem muito "ex-lavador de piscina nos EUA" em gigantes de OutSourcing simplesmente porque falam a lingua.

É o famoso lema do "aprende em casa".

São vários fatores que contribuem para isso, tendo em mente os principais:

1)Falta de gerenciamento, métricas adequadas(e, se possível, o mais próximas da realidade plausível) e falta de competência profissional.

2)Desvio conceitual e real do projeto.("Ah, isso é fácil! Deixa aí que eu resolvo rapidinho...")

3)Falta de conhecimento, pouca pesquisa e muito desenvolvimento(o famoso "bate-assopra".)

Para terminar, temos tantas variáveis e tantos "por que", que, em poucas palavras seria difícil "mensurar". E aja aspas e parênteses para os futuros projetos ;-)

Gostaria também de deixar registrado neste fórum, assim como muitos deixaram, o fato da DESVALORIZAÇÃO do profissional da área. Hoje, o acesso fácil à informação, possibilita que muitas pessoas que se interessam na área, acabem estudando e desenvolvendo sistemas. Ótimo o fato de que todos possam estudar e trabalhar com o que querem sem mesmo já possuirem alguma formação acadêmica ou certificação. O problema, é que muitas consultorias gananciosas, acabam descartando um profissional com uma vasta experiência e preferem contratar alguém que está "começando" ou que possui "conhecimentos" em tal tecnologia para assumirem postos onde a experiência faria total diferença.

Gostaria que pessoas envolvidas na contratação de profissionais também estivessem acompanhando este fórum e percebesse a necessidade de VALORIZAR os profissionais da área.

Acredito que o maior problema está nos prazos de entrega dos projetos que são geralmente estipulados por quem não desenvolve sistema e muitas vezes sem utilizar algum tipo de métrica. A métrica mais utilizada é baseada no que o cliente pede e não em métricas sugeridas pela Engenharia de Software. Além de tudo isso como um amigo citou, as condições em que muitos desenvolvedores acabam ficando dentro de um ambiente de trabalho, não são nada favoráveis. Desenvolvimento de software, apesar de toda a técnica e engenharia envolvida, é um processo criativo, e o alto stress a que profissionais como eu, ou seja, desenvolvedores de softare, são submetidos acaba refletindo diretamente no resultado.

OBS: Qual o problema com o SURF amigo? Se não possui algum esporte que goste, poderia pelo menos respeitar.

Pessoal,

Não nos iludamos. Até construções de prédios residenciais costumam ter prazo de trinta meses, com seis meses de tolerância de atraso. Isso dá uma margem de atraso de VINTE POR CENTO no tempo.

Se até na construção civil, que é uma atividade existente há milhares de ano, os atrasos já são esperados, por que na informatica, que historicamente surgiu "ontem", seria diferente?

Além disso, os clientes exigem das consulorias o cumprimento de tarefas complexas em prazos irreais. As consultorias, desesperadas por um dinheirinho em caixa, prometem os céus e a terra e engolem tudo que o cliente exige.

Some-se a tudo isso profissionais desreispetados, submetidos a contratos aviltantes (leia-se PJ) sem a mínima garantia de nada, tendo qu disputar mercado de trabalho com um bando de pseudo-profissionais surfistas que ficam felizes se o salário der para comprar a parafina pra passar na prancha de surfe (a prancha, o papai paga).

Depois as empresas ainda se acham no direito de exigir exatamente o quê?

Pessoal,

Gostei muito de vários comentários que li. Ha muito tempo vivo indignado por projetos darem "tão errado" quando se tem disponível tanto conhecimento e pessoas certificadas em metodologias de gestão de projetos, governança e tantas outras certificações que logo logo estaremos escolhendo até por " diferentes sabores". Acho que não resta muito mais a dizer, mas compilando frases de alguns bons comentários que li, sugiro...

Já que temos clareza dos PORQUES os PROJETOS DÃO ERRADO, o que FAZER PARA:

"Usufruindo dos conhecimentos das Melhores Praticas, por profissionais realmente capacitados para gestão de projetos (e não por iniciantes "filósofos e carreiristas"), QUAIS ATITUTES TOMAR, O QUE FAZER PARA QUE OS PROJETOS TENHAM SUCESSO!?"

Um grande abraço!!

É uma conjunção muito grande de fatores, que tanto pode iniciar na escolha incorreta da metodologia de gerenciamento/desenvolvimento, quanto no time ou pior ainda nas ferramentas adequadas ao desenvolvimento do projeto em questão. Passa ainda pela dificuldade, e falta de cultura, de quantificar a capacidade de produção de cada elemento do time de desenvolvedores. Ainda tem a questão mercadológica, comunicação, contrato, requisitos. Acredito que um painel destes é muito difícil de configurar, e apontar todos os "males", quiçá o maior de todos.

A resposta é simples: Porque não me contrataram para ser o Gerente do Projeto! rsrs... Falando sério, o Gerenciamento de Projetos em TI no Brasil ainda é algo muito recente e quando falamos em gerenciamento de projetos, as pessoas acham que você vai "controlar o trabalho delas", ou seja, há uma resistência "natural" do ser humano quando se fala em organização, controle ou mudança. Quando se fala nestes trê itens juntos então... a cois piora e muito! Acredito que o Brasil ainda é imaturo porque um projeto, mesmo sendo de TI, é um projeto realizado por pessoas e, se elas não forem tratadas como tal, um Gerente de projetos, por mais que tenha técnicas e conhecimento do negócio NUNCA irá conseguir buscar o mais importante: o comprometimento das pessoas. E aí é que acontece o óbvio: os projetos falham, estouram orçamento, tempo e custo.

Simplesmnte por que esquecem que processos são executados por pessoas , e não por máquinas , pessoas mudam ou alteram os processos ou fazem eles serem mais lentos , quem faz um projeto imagina todas as atividades como pedaços de um processo maior , ou pior ainda nem imagina porque às vezes NINGUEM tem conhecimento pleno do processo maior , nem gerentes , nem supervisores , nem diretores , o que eles tem é uma 'teoria' de como é o processo , cada qual interpreta do seu jeito o 'processo maior' e tenta meter na cabeça do outros que ele/ela tem a noção exata 'do processo' e deve funcional de tal jeito , o PM acaba acatando e agrupando as atividades numa planilha qualquer e diz que é 'projeto' , NIGUEM sabe como é o processo porque não fazem 'MAPEAMENTO DE PROCESSOS'

Simplesmente porque o povo brasileiro em geral é desleixado, não gosta de estudar, não gosta de seguir regras, quer fazer tudo do jeito que lhe é mais conveniente.

Trabalhei em uma consultoria de TI (uma dessas grandes que fazem projetos pra bancos) e eles estavam tentando obter a certificação CMMI 5.

Acontece que eles eram incapazes de seguir o modelo CMMI 2, quem dirá o CMMI 5.

Passei por uma situação deste tipo recentemente. Uma implantação que foi adiada em um mês, havia uma ESTIMATIVA de entrega, mas que nao foi real devido aos ajustes que foram sendo solicitados na fase de testes... Depois do adiamento para uma nova data, para que os ajustes fossem terminados, surgiram novos desenvolvimentos a serem feitos... nao fiquei para o fim do projeto, mas o pessoal nao estava mais trabalhando apenas 8h/dia...

Falta de Comunicação e elaboração do projeto. Mas veja só: o tempo que seria necessário para elaborar com exatidão a estratégia e escopo do projeto não seria igual ou maior ao que hoje se atrasa referente aos cronogramas?

Creio eu que cada dia mais as tarefas simples se tornam mais complexas, e tendem a se tornar ainda mais, cada dia mais stakeholders e backgrounds, tornando-se algo impossivel de se mensurar os prazos. Quanto mais pessoas se envolvem em um processo, menos se conhece sobre ele.

Olha la não to falando...rs...Caso real : Ja pediram para entregarmos uma cacetada de telas mais ou menos 10 ..testadas e devolvidas com as devidas correções por uma consultoria quarteirizada e finalizarmos o pacote até quinta para o cliente....bom PROMETERAM mas nem sabiam do impacto das alterações...rsrs... da para ficar sem rir desse gerenciamento/VENDAS..

Olha estou atuando nesta área de projetos faz 2 anos e percebo que a peça fundamental para que o projeto seja bem implementado é a bendita da "COMUNICAÇÃO" não importa o business ou o escopo do projeto muitas áreas envolvidas porém não se conversam entre si de uma maneira clara e objetiva! RESULTADO= RETRABALHO!

acho que o pior nao e isso e sim a magoa de ter escolhido algo tao decepcionante

Gerenciamento inadequado para época, problemas de comunicação entre equipes, auto confiança atrapalha quando não é profissional.

Simples o PRAZO nasce ANTES DO PROJETO. Agora fica uma pergunta: Tem jeito de ser diferente????

Para ser bem sintético : - Falta de governança de TI e corporativa (aspecto cultural) - Falta de alinhamento de TI a negócios - Concepção e Escopo mal definidos (requisitos de negócios) e mal negociado (limites não fechados e contratados claramente e bem documentados) **** normalmente a falha esta aqui por isso sempre estouram prazos e orçamentos - Falha na abrangência e relacionamento de todas areas envolvidas (Comunicação) - Falta de recursos qualificados e bem dimensionados - Falta de experiência na gestão de projetos com a não aplicação dos métodos e boas práticas (no inicio, meio e fim do projeto e principalmente aplicar a lição para os próximos...) - Não considerar que sempre são pessoas, processos e tecnologias na gestão de projetos e em outras areas... normalmente todos se esquecem do fator pessoas (muito problemático) e dão apenas enfase a tecnologia e aos processos Óbvio que sempre existe um risco de um projeto falhar, afinal na vida tudo é assim...Mas se forem observadas algumas boas práticas das metodologias esses riscos podem ser bem minizados e ter sucesso.

Bom dia. É complicado, apesar de ser efetuado o levantamento de horas necessária para um projeto, acabamos tendo que engolir o "prazo" estipulado por outros departamentos como Marketing, vendas e Operação. E desta forma sem o devido planejamento acabamos correndo riscos. Neste padrão as metodologias aplicadas são:BMB - Bumba Meu Boi e FFQ - Faz e Fica Quieto.

Essas sim funcionam. Abraço.

Simples, falta de profissionais qualificados. Não tem essa de que um gerente de projetos gerencia qualquer projeto de qualquer área o cara para gerenciar um projeto de TI tem que conhecer de TI e do negócio alem de saber se relacionar com as pessoas descobrir os caminhos certos dentro de cada empresa para fazer acontecer.

Que dureza... Vou falar novamente : - VENDAS manda ..e TI "obedece"; faz de conta que quem deu prazo foi TI.. - BOM A QUALIDADE É AQUELA QUE VENDAS PROMETEU : O SISTEMA VAI ATÉ CANTAR ..Com Duração de 1 Dia PARA ENTREGA e NÃO se fala mais nisso... - GALERA RELAXA !! PODE CRIAR ATÉ PMI_6.5 E ITIL_9.9, QUE NA HORA DA VENDA a METODOLOGIA PREDILETA VAI SER O "VENDEIXAM 0.001 !!!" ABRAÇOS

Porque é uma das areas mais importantes dentro de uma empresa, por fazer a integraçao, comunicação, compras entre muitas outras coisas, envolve praticamente todas os setores (como se T.I. fosse uma placa mae e a empresa os restantes das peças), entao por, arrisco dizer, ser um dos alicerces, precisa estar muito bem estruturada, e quando ocorre imprevistos pode ser necessario todo um replanejamento, orçamento, mapeamento, etc's.

Com a super valorização de da TI em todos os seguimentos (desenvolvimento, hardware, redes, etc), o cliente sempre procura o menor custo e menor tempo para entrega, além de existir no mercado pessoas que compram sistemas em banca de jornal e querem que o sistema se comporte como um SAP. A sociedade da tecnologia precisam sim humanizar a tecnologia, precisar vender sistema sob a medida do cliente e sobre as condições que ele pode pagar, não se pode oferecer uma Ferrari para um cara que usa o carro só para ir a padaria, tecnologia de ponta exige investimento e sobre tudo tempo.

Penso que o problema estja na hora da venda, normalmente as venda são realizadas para conquistar o cliente, então são prometidos preços e prazos que após o envolvimento da equipe técnica é verificado que para a entrega do projeto será necessário um esforço muito maior do que foi estimado pela equipe de vendas. Quando a equipe de pré-vendas envolver (consultar) a equipe de projetos, penso que os prazos e preços serão mais coerentes e os projetos passaram a ser realizados nos prazos acordados.

Trabalho com desenvolvimento de sistemas a 17 anos. Lamentavelmente tenho visto uma valorização de areas vizam controlar o ciclo de desenvolvimento. Daí contratam mais gerentes de projetos, coordenadores, PMO, PMP experiencia em governança de TI, RUP, CMMI e etc... Lembro-me que quando eu desenvolvia em clipper, delphi, visual basic, asp. Eu chegava a produzir uma tela por dia (complexidade media) e ainda por cima comentava todo o código. Um pequeno sistema com 20 a 25 tabelas, contendo de 10 a 15 formularios não passava de 1 mês e meio. Hoje um projeto desses dura em media 5 meses se tivermos sorte. Acredito que temos que voltar um pouco às origens do desenvolvimento de sistemas. Essa galerinha que esta chegando na area e não quer aprender a fazer codigo, e em pouco tempo quer ser gerente ou se destacar de alguma forma que o afaste de colocar a mão na massa é que ta emperrando todo o processo. Conheci um cara que acabou de formar. O primeiro emprego dele é de tester e já pensa em ser gerente. Já anda com um livro sobre gerencia de projetos.. ah ah ah!!!!! Acredito que podemos ter programadores muito bem remunerados e querendo ser eternamente programadores.... Temos que valorizar o excelente tecnico. E expurgar os “filosofos” que estão sujando a area de TI. Tá tudo errado!!!!! Fui.

Nem tecnologia e nem metodologia podem ser consideradas como fator de insucesso ou de maiores gastos em projetos de TI. Há muitas causas para o estouros tem de projetos e isso vem de muito tempo (há pelo menos duas décadas) e entre as principais, destaco as seguintes: 1. Investimento inadequado, ou seja: A maioria dos "clientes" querem gastar pouco sem limitar a abrangência do projeto; 2. Decorrente do primeiro: a má definição do escopo do projeto. Via de regra as alterações de escopo não são documentadas e nem acompanhadas de um compromisso(principalmente dos "clientes") de investimento adicional. Geralmente faz-se mais do que o combinado, por pressão dos "clientes"; 3. Falta de conhecimento do que seja um projeto e falta de transparência no processo de "venda" e de "compra". "Clientes" mal-informados compram promessas de "vendedores" eficientes (parece até eleição, promessas de candidatos). E a falta de entendimento do que é realmente um projeto, faz com que os "clientes" não especifiquem claramente: a) O que realmente é preciso para o negócio andar; b) o que pode ser feito depois que o projeto inicial terminar, num segundo projeto; e; c) o que deve ser considerado como melhoria e pode ser feito após o produto do primeiro projeto estiver estabilizado.

Creio que muito pode ser discutido em relação a este tema.

Os projetos atuais tem uma percepção muito mais comercial do prática, os clientes não querem investir muito, as consultorias não tem tantos profissionais á disposição. O preenchimento de documentação é muito mais formal que prático, todas empresas utilizam várias metodologias, mas cada uma delas de sua forma, não há preocupação em deixar claro aos SteakHolders, as funcionalidades do projeto.

Acho que e porque tem muita TECNOLOGIA e muita METODOLOGIA, por isso tem pouca ação! Nas decadas de 80 e 90 tinhamos muito menos tecnologia e metodologia ninguem nem tinha ouvido falar, e a coisa andava muito mais rapido. Hoje para desenvolver um projeto tem. Gerente de relacionamento->Gerente de projetos->Coordenador de Projeto->Analista de processos->Analista de sistemas->Analista programador. Fora a equipe da empresa contratante, é muita gente para dar palpite e pouca para executar.

Primeiramente gostaria de dar minha opinião sobre o assunto, quando se tem uma análise mal feita você encontrara dificuldade na implementação, como eu fosse um construtor e que desse uma planta com vários defeitos de construção ao pedreiro, outra coisa que já aconteceu comigo é o espirito de equipe do pessoal envolvido no projeto, só porque um ganha mais que o outro quer ver o oco. Outro fator muito importante é a ganancia da consultoria em pagar R$10 por hora ao empregado e cobrar R$1000, bons profissionais como em toda profissão tem seu preço.

Para empresas de TI pequenas e médias, entendo que o buraco é mais embaixo. A pressão para se vender um produto ou serviço faz com que o vendedor faça promessas tentadoras para o cliente, tanto de custo quanto de prazo, pois necessitam da venda para aumentar seu hall de clientes e conseguir uma posição mais sólida no mercado, com vários casos de sucesso e divulgação da marca. Porém, quando essas promessas chegam à equipe de projeto, elas já estão erradas desde então. A equipe, por sua vez, tenta se adaptar, muitas vezes não consegue, e o prazo e orçamento iniciais ficam totalmente prejudicados. A natureza do usuário/cliente é exigir conformidade com aquilo que foi "acordado" no início, isso é normal e até nós fazemos isso no dia-a-dia. Nesse início encontra-se parte do problema e é aí que devemos levar ao cliente essa conciência, essa aceitação do problema de que ele também faz parte, pois modificações e reestruturações são normais. Essa mentalidade deveria ser incorporada durante as tomadas de decisões, assim como a mentalidade de que qualquer empresa de TI está sujeita a reestruturações. Assim, se alguém chegar pro cliente e falar "é impossível que meu projeto estoure o prazo ou orçamento", desconfie. Desconfie, pois da forma como são levantadas as necessidades do cliente, é muitíssimo natural que haja problemas. Afinal, não vivemos no mundo ideal.

Primeiro o tempo gasto no planejamento é muito menor do que o gasto na implantação, segundo os prazos quase sempre são chuto metros e não representam as estimativas reais de prazo e custo. Terceiro temos muitas ferramentas, mas elas não são usadas e quando são usadas são usadas de forma inadequadas. O principal erro é propor um prazo no chutômetro,mesmo que este chutômetro seja baseado em experiência.É exatamente para impedir os chutômetros que temos a engenharia de requisitos e revisões técnicas (Entender o que o cliente quer ver se é viável de ser feito (o cliente não ta querendo voar para lua), todos esses requisitos são necessários ou ele quer esse requisito por simples capricho, validar todos os requisitos com o cliente e se necessário esticar o prazo. Negociar prazo, custo e finalmente fechar um pacote, propondo um número X de alterações nos requisitos. (caso o cliente queira algumas coisa a mais desse pacote cobrar por isso, afinal fechamos um acordo para aquele pacote). Realizar prototipação é bom, só que muitas vezes o que vai parar na mão do cliente é o protótipo (um projeto cheio de códigos reaproveitados de trocentos outros projetos, resumindo um Frankenstein criado para mostrar alguma coisa para o cliente e apenas para isso ou deveria ser assim).

Na Minha opinião a maior parte destes problemas está diretamente relacionada a falta de preparo dos gerentes de projetos. Em algumas ocasiões temos pessoas bem preparadas para o efetivo sucesso do projeto, mas a realidade a falata de autonomia para o gerente de projeto, que na maioria das vezes não tem voz ativa dentro do processo.

Amei o tema do fórum e muito mais as respostas aqui dadas.

Acho que projetos de qualquer natureza já são, por eles mesmos, muito complexos. As variáveis a serem monitoradas crescem exponencialmente de acordo com o tamanho do projeto. Ou seja, se qualquer uma das pontas falharem, como relataram tantos aqui, o projeto como um todo desanda.

Comprometimento com o projeto em si é fundamental, quando as pessoas estão mais comprometidas com lucro ou os seus empregos, dificilmente você terá bons resultados.

várias opinões que não são a realidade, sabe o que realmente acontece?

falta a valorização do profissional de TI, são descartaveis hoje pelas consultorias, então qual a motivação dele para entregar no prazo?

essa é a realidade e jamais você vai ouvir de um terceirizado ou funcionário seu a insatisfação pela maneira que são tratados, principalmente quando são contratados para um projeto com prazo determinado.

Na minha visão, tudo começa na venda, no momento em que é realizada a estimativa do tempo e na montagem do cronograma REAL, o que na maioria das vezes não acontece. Sendo assim já e um passo para o fracasso do projeto, sendo que a quantidade de horas vendidas não e suficiente para atender o escopo do cliente, respectivamente o prazo e curto e inadequado. Sendo assim o "Nervosismo do cliente" se reflete nas re-negociações de custo e prazo, prejudicando todas as partes. Creio que a metodologia é essencial para todos nos, sendo aplicada como se deve, atendendo casos reais, com métricas cada vez mais precisas. Assim tudo isso é convertido no êxito do projeto e na garantia de um cliente satisfeito.

A culpa é de quem compra, que quer acreditar na história da carochinha, do projeto barato, rápido e com qualidade. Sempre que tiver um comprador trouxa, vai aparecer um vendedor esperto, pra vender um projeto desses. Sempre vai ter empresas, que topam ter esse tipo de vendedor, pra fazer um caixa rapidinho, depois toma bucha lá na frente, porque não consegue entregar, mas o vendedor já embolsou a comissão.

Tem também aquela empresa, que paga caro no projeto e depois quer tirar leite de pedra pra recuperar o prejuízo. Dai força aumentos no escopo que não estavam previstos. É lógico que vai dar bucha.

Estou com o Silvio e não abro : NAO MUDOU NADA, NEM IRA MUDAR... >> VENDAS É QUEM DITA... O RESTO SE SOBRAR É "ESMOLA" PARA TI TENTAR PALPITAR ALGUMA COISA; MAS QUE NÃO MEXA NEM EM VALOR E NEM EM PREÇO, PODE MEXE NO QUE QUISER..

Falta de planejamento, prazos curtos para realização das fases do cronograma, analistas funcionais generalistas, ausência de analistas de negócios especialistas, falta de comunicação interna entre funcionais e técnicos, gerando re-trabalho e conflitos na fase de testes e integração entre sistemas, falta de ferramentas e ambiente específico de testes, falta de conhecimento do negócio por parte do cliente, etc....

Fiz uma pesquisa recentemente, que transformei em artigo e espero publicar em breve. O problema é falta de um escopo bem definido, em resumo. Numa visão PMBOK, de Pekka e Forselius isso arrebenta com qualquer outra KPA relacionada a Escopo. Numa abordagem de engenharia de software, que é mais completa e detalhada, o mesmo se aplica. Isso pode ser verficado nos artigos de Poppendick. O Chaos report de 1994, o Chaos report de 2000, e um estudo da Jama/Ravenflow, definem isso muito bem, através de estudo de mercado e estatística. Na linha do tempo segundo estes estudos, escopo sempre foi um problema. E na minha opinião vai continuar sendo. Quem quiser entrar em contato comigo a respeito do assunto, pode ficar a vontade. luiz.david1@yahoo.com.br

porque nós somos um bando de descarados..... na maioria das vezes vamos pelo caminho mais fácil, que nem sempre é o melhor. abraços Mario

pq na verdade nao mudou nada, nem ira mudar... Os catequistas-mestres da força de vendas do mercado de software, que ditam oque vai ser e o que nao vai ser. eufemismos se multiplicam para simplesmente gerar ilusao.

tenho dito.

A resposta é simples; porque ninguem é perfeito !!!! O mundo não pode ser perfeito mesmo na área de tecnologia.

Tentamos enquadrar os projetos de TI dentro dos padrões de projetos de outras áreas da engenharia. Quando montamos um projeto de engenharia civil, temos 15% do tempo em planejamento e 85% do restante de execução. Na execução ninguém pede ao pedreiro para descrever seu trabalho de subir uma parede, etc..... nos projetos de TI temos o cenário contrário...temos 85% do tempo em planejamento e 15% do tempo em execução e além disso é obrigatório que nossos "pedreiros" forneçam toda documentação possível sobre suas atividades....... Acredito que seja por isso que 80% dos projetos de TI no planeta estouram prazo, orçamento e a paciência dos usuários e patrocinadores!

3 Problemas que afetam e muito o desenvolvimento de SW.

Desconhecer o negócio Não conhecer o negócio Não ter o mínimo conhecimento do negócio!

*Pode ter a metodologia que quiser sem conhecer o negócio nada feito.

As Empresas estão tão perdidas que precisam de sugestões o tempo todo, uma grande empresa multinacional do varejo está há 8 anos tentando implantar seu sistema de ERP e ai nada, nada já se afundou +- uns R$ 1bi.

uma coisa é fato, antes dessas metodologias, dessas politicas de gestores de projetos, eu não via atrasos nos prazos, talvez esteja ai o problema, é muito oba oba para um projeto que muitas vezes é simples, documentar é necessário, metodologias de documentação, acho que esta ai o problema, perde muito tempo nessa parte e a questão é que ainda sai defasado ou com erros que lá na codificação, atrasa tudo, não é na codificação o projeto e sim no estudo de caso até a codificação, pois muitos analistas viajam nessa parte e como sempre, o cliente pede algo e entregam outra coisa, o inicio é o principio do sucesso, o velho português estruturado dá conta e leva menos tempo do que ficar desenhando e associando objetos, mas em ambos os casos, os requisitos do cliente deve ser bem elaborado, deve-se conhecer o cliente e seus anseios para que na hora de orçar e definir prazos não cometa o erro da maioria, atrasar e estourar orçamentos(embora seja quase impossivel nas grandes consultorias o estouro de orçamento)

Em minha opinião isto ocorre porque na maioria das vezes a TI não tratada com o devido respeito pelas áreas de negócio, e os próprios gestores da área de TI não buscam este respeito. Isto provoca um grande problema, pois para agradar os 'amigos', são feitos acordos de prazos que quando fechados, todos já sabem que não serão cumpridos. Não estou querendo generalizar, mas em meu ponto de vista, as pessoas deveriam realmente estimar os prazos, os impactos e os ganhos com critérios adequados, e não somente pensar na auto-promoção com alto escalão. Enfim, aquele velho paradigma, se posso ficar famoso vendendo sonhos, porque vou ficar no anonimato me esforçando para fazer certo.

DA PARA VER PORQUE NÃO DA PARA CUMPRIR PRAZOS EM TI, MAS NEM EM UM FORUM DESSE SE CONSEGUE FAZER AS OPINIOES CONVERGIREM PELO MENOS 50%... UM DIZ QUE A CAUSA É HUMANA O OUTRO DO CLIENTE O OUTRO DO MST.. O OUTRO DO GERENTE.. O OUTRO DA DEDICAÇÃO E DIZEM QUE DA PRA ACABAR COM QUALQUER PROJETO NO PRAZO SÓ BASTA FICAR 24 HORAS TRABALHANDO QUE O SERVIÇO DE 6 MESES VIRA EM UM MES. AGORA IMAGINA SÓ TODA ESSA GALERA SENTADA PARA DEFINIR PROCESSOS , REQUISITOS E ARQUITETURA DE UM PROJETO... VIXI...JA ATRASOU SÓ PARA ESCOLHER O TIPO DE METODOLOGIA JA MORREU UNS DOIS...

Qualquer projeto em qualquer área possui data de inicio, data de finalização tamanho e orçamento, em TI temos levantamento, construção e implantação, para a realização dos projetos temos ferramentas e metodologias para desenvolvimento e gerencia e pessoas, se cada um fizer sua parte não haverá grandes problemas. Atrasos e distorções sempre existem, só não podem ser superiores a um percentual aceitável e pré-determinado. Agora se o cliente e desenvolvedor não respeitarem escopo, métodos e profissionais envolvidos, simplesmente passarem por cima de todos ou quaisquer limites, então o projeto irá naufragar com certeza para alguém. A decisão de manter o projeto dentro dos limites estabelecidos é o melhor caminho e quem decide não fazê-lo deve assumir a própria culpa e não empurrar para os níveis mais baixos o que geralmente acontece.

Pois o entendimento da necessidade não necessariamente deve ser computacional.

Deve ser humana antes.

veja o prazo, faça alocação de profissionais experientes, pague bem, motivação total, e o custo para o cliente faça de acordo com a estrtura montada e faça uma estimativa baseado em tempo previsto, coloque seu lucro com a margem de risco.

nunca dê um valor e um prazo fechado, dê um estimativa de ambos em um período x, que vai depender da complexidade e da iteração do cliente.

O Grande problema é que as empresas de um modo geral não tem como fim a área de Informática, para elas essa área é apenas um "mal necessário", nesse sentido,delegam o trabalho sujo a alguma consultoria, na ilusão de que aquela que apresentar o menor preço pelo projeto será a mais bem escolhida. A consultoria por sua vêz está no seu papel de vender ilusão a quem quer comprar. Isso funciona em qualquer setor, sempre tem alguém querendo comprar alguma coisa por um preço menor e sempre há alguém oferecendo ilusões a quem quer comprar. Para mim cabe às empresas que demandam serviços de Processamento de Dados se profissionalizarem melhor,levando mais a sério essa área tão fundamental , só assim deixarão de comprar gato por lebre.

Na minha opinião isso acontece porque a fase de análise e planejamento nos projetos são vistos por muitas pessoas como algo burocrático, o cliente quer ver logo o resultado do seu produto e a equipe de TI acaba dando pouca ênfase para essas etapas, além disso muitos projetos apresentam riscos que não foram identificados e trabalhados no início das atividades.

Depende muito, há empresas que estouram prazos pq querem que o projeto se estenda para ganharem mais, há profissionais que não sabem exatamente definir prazos e há empresas que apertam a prestadora de serviços para que o projeto seja feito naquele tempo, então quando a questão envolve pessoas fica dificil estabelecer algo assim, pois na equipe há diferentes tipos de pessoa, desde o puxa saco até aquele que não colabora, enquanto os coordenadores não levarem em conta de colocar perfis sociais mais proximos do que ele necessita para o projeto poderá continuar acontecendo estes problemas, pois uma equipe com sinergia cumpre sim os prazos, porém claro dependerá dos fatores acima...

Há n situações, mas a primeira é a negligência, uma idéia de projeto é criada, a empresa com a idéia começa a procurar consultorias que possam concretizar essa idéia, quando conseguem consultorias sérias, essas informam sobre os custos/tempo de análise de projeto, modelagem UML, e diversos outros pré-requisitos para um projeto ser concluído com sucesso... Entretando ao saber desses requesitos 90% das empresas começam a querer pular essa etapa tão importante e por isso acontecimentos não previtos acabam por estourar o prazo e o orçamento. Dos 10% que investem nesses requesitos, no geral apenas 5% conseguem o projeto no prazo e dentro do orçamento, pois o restante (isso inclui os outros 90% também), sempre têm novas idéias para acrescentar no decorrer do projeto, prolongando assim o prazo de conclusão e o orçamento, quando não são novas idéias no decorrer do projeto, há as situações de mudança de legislação, regras internas da empresa, etc...

BOM VAMOS A RECEITA DO CASE DE SUCESSO DE UM PROJETO :

1 - O COMERCIAL VENDE UM PROJETO POR 500 MIL E NO PRAZO DE 1 ANO E NÃO SE FALA MAIS NISSO. 2 - TI CONTRATA A EQUIPE "TABAJARA" P/ LEVANTAMENTO DE REQUISITOS, PASSOU 9 MESES E TEMOS MAIS DE 200 LEV. DE REQUISITOS E UMAS 300 TELAS DE PROTOTIPO. 3 - FORAM-SE 11 MESES E NAO SE ENTREGOU NADA PARA O CLIENTE.. E DE "LAMBUJA" IDENTIFICOU-SE QUE VAI LEVAR UNS 2 ANOS PARA FINALIZAR E O GASTO VAI SER DE 2,5 MILHOES....XI DEU M... 4 - OPA ACELERA AI GALERA VAMOS ENTREGAR ALGUMA COISA PARA O CLIENTE QUE ELE TA P...;ENTREGAMOS ALGUMAS TELAS E AI VEM: NADAAAA ATENDE COMEÇANDO PELO PROTOTIPO, VCS PODEM REFAZER 99%. 5 - ESTRATEGIA TARDIA (1 ANO DEPOIS): AGORA VAMOS TENTAR SALVAR O TITANIC CONTRATAREMOS SENIORES PARA SALVAÇÃO..REFAZER TUDO DESDE PROTOTIPO... AH O CLIENTE COMEÇOU MUDAR ALGUNS ESCOPOS...XI..NÃO COBRA NÃO HEIM..PEGA MAU..AFINAL TAMOS ATRASADO... 6 - REALIZA-SE UMA NOVA ENTREGA AO CLIENTE ,AH AGORA SIM O CLIENTE FICOU SATISFEITOOO COM A QUALIDADE, SÓ QUE O PRAZO JA ERA... 7 - BOM INICIÁ-SE A HOMOLOGAÇÃO, VEM O GASTO FINAL DE +- 3 MILHOES..VIXI..E AQUELA REUNIAO MOTIVACIONAL: PESSOAL O PROJETO TA NO PREJUIZO E ATRASADO VAMOS ACABAR LOGO E IRMOS PARA OUTRO PROJETO QUE VAI SER UM SUCESSO.. 8 - AH MAS O CLIENTE ACABOU FICANDO SATISFEITO COM A QUALIDADE FINAL EXCETO DO PRAZO ..MAS DEIXA PRA LA O PRAZO NÉ..AFINAL O PROJETO FOI UM SUCESSO PARA A CONSULTORIA; AH MAS O CLIENTE TAMBEM FICOU MUITO CONTENTE ..GASTOU 500 MIL POR UMA CASA DE 3 QUARTOS E ENTREGAM UMA DE 8 QUARTOS COM 5 SUITES E PISCINA E SÓ COBRARAM O VALOR DE UMA DE 3 QUARTOS SEM SUITE E SO COM VARANDA..NAO TEM PROBLEMA NÃO PODE ATRASAR MAIS UM POUCO SE VIER UMA DE 10 QUARTOS EU ACEITO..RS -LICOES APRENDIDAS : VIXI TEM UM .DOC LA NO TEMP DA UMA OLHADA ..

Pela combinação das seguintes situações de praxe mais comuns: - Certificação e falta de capacitação; - Poder e incompetência; - Medo de contestar o chefe e de perder o emprego; - Muita pose para esconder falta de conhecimento e muita intimidação para esconder insegurança!

Uma coisa que n entendo, estava vendo na faculdade na cadeira de controle e administracao de projetos um monte de indices e tudos mais que são monitorados no decorrer do projeto, os seus status. Como que mesmo com todos essas parafernálias, ainda temos projetos que se atrasam e tudo mais ?

Diagrama de gant, diagrama de flecha, modelo pert/cpm, bla bla bla. Pega isso tudo e joga no lixo, pq já na prática........

Falhas de análise, gerentes de projeto incapazes de negociar com clientes, promessas de prazos de entrega impossíveis de serem cumpridas, coordenadores de projeto que não tem conhecimento ou técnicas para gerenciar uma equipe desenvolvimento, falta de incentivos ou reconhecimento dos sucessos dos funcionários, ou seja, vários fatores que juntos, mesmo com as melhores técnicas, ferramentas, etc..., geram todo o processo crítico e falho de desenvolvimento, que já ocorria desde os tempos mais remotos, de projetos baseados em um mundo de utópico que no final tornam-se gambiarras que atendem pouco do que o cliente realmente necessita e quase nada do que foi prometio, ou seja, dez pessoas gerenciando enquanto apenas um trabalha realmente... esse é o mundo de TI... rs

Orçar um software é uma tarefa muito difícil e são muitos os fatores que podem gerar desvio, ocasionando o tão indesejado ATRASO ou estouro de Orçamento. Na minha opinião, a tarefa de levantamento de requisitos deve ser muito bem realizada para dar os subsidios necessários para um orçamento acertivo.

É simples. Isto ocorre porque, muitas vezes, os projetos são levados pelo lado político ao invé do lado técnico. Aí, dá no que dá.

As vezes, as consultorias de informatica para venderem seus projetos, estimam horas a menos. Além disso, não informam seus consultores que venderam com horas a menos e depois os GP´s ficam cobrando de seus consultores o cumprimento de prazos. Isso ocorre geralmente em projetos com horas fechadas

Bem, trabalho com projetos de TI faz 10 anos e o que consegui observar nestes anos é que não adianta usar tecnologia fantástias, metodologias maravilhosas se as pessoas não estiverem preparadas.

Apesar de se falar em gestão de projetos há alguns anos, o mercado e principalmente as pessoas em geral não tem maturidade suficiente para trabalharem orientadas por projetos.

É comum confundir projeto com processo industrial, acreditando que um projeto é algo encaixotado, mas como diz a literatura, os gurus de projetos um projeto é um esforço temporário, progressivo e que gera um produto único.

Parece que as pessoas esquecem isso e a primeira coisa que sempre se pergunta num projeto é "Quanto vai custar?", a segunda "Quanto tempo vai levar?". A partir dai, a primeira estimativa que se dá para o projeto, todos assumem que aquilo é a proposta final.

Para resumir, o que acho é que falta maturidade para as pessoas envolvidas direta ou indiretamente em projetos.

Eu realmente estava aguardando desabafos como do colega “cwlo”, que aparentemente foi o único que captou o principal objetivo do post de ontem. Deixei “duas pérolas guardadas” em um texto repleto de reclamações ao estilo MST (cwlo – achei essa ótima!), como vemos a todo momento. Sejamos honestos, é muito mais fácil passar “a batata quente” para o próximo, ao estilo “desenvolvo apenas o que está no documento de requisito”, do que realmente tentar mudar a forma de pensar e agir. O mercado está cada vez mais exigente com a qualidade dos profissionais e prazos curtos, logo, não temos tempo disponível para discussões filosóficas (ou para procurar culpados). Na realidade, temos a capacidade de complicar o que pode (ou poderia) ser simples. Costumo exemplificar da seguinte maneira: Em um projeto de portal de notícias, preciso me preocupar em permitir a escalabilidade do publicador de notícias ou do gerenciador de blogs? Conheço diversos profissionais que perderiam um tempo absurdo bolando um jeito de escalar o blog...

Um abraço a todos!

existe tanta notícia falando que em Tecnologia existe muita vaga para pouco profissional qualificado ? Onde???? Onde existe Muita Vaga? De qual país ou colônia estamos falando?

Se Existem estão nas mãos das consultorias que só procuram por profissionais baratos, por isso esta a zona que está

a resposta é facil: nao haverá metodologias, tecnologias que vao fazer os projetos serem entregues no prazo, nos custos e com a qualidade esperada...e sabe por que? Porque projetos sao feitos por seres-humanos e todos sabem que para projetos de TI especificamente, recursos humanos é que fazem o projetto ter sucesso ou fracasso. Já tá mais do que provado em pesquisas!!! é sempre esse bixinho: o homem!

depois do desabafo.... outro motivo concreto.... devido à concorrência "insana" entre as consultorias, quem nunca viu um projeto começar cheio de recursos sênior e aos poucos a consultoria ir realocando as pessoas para novos projetos ? Ou então desenvolve o projeto somente com estagiários para depois fazer uma "força tarefa" de recursos para apagar incêndio ? Infelizmente até para comportar a quantidade de profissionais do mercado, temos que conviver com empresas melhores e piores. Não existe empresa perfeita porque todas tem a pressão de reduzir custo e aumentar lucro, mas a idéia é tentar perceber se pelo menos o comando da empresa tem coerência nos objetivos e principalmente a empresa tem um histórico razoável. A primeira coisa que vejo em uma consultoria se recebo uma oferta de emprego é o ano de fundação da empresa, histórico e clientes. Quando aparece aquelas consultorias de 2 ou 3 anos de vida com endereço Rua XPTO CJ 1234.... já dá para perceber que é meio fundo de quintal...... a chance de uma empresa dessa ser um novo "Google" é meio difíci.... rs

Os comentários do fórum de certa forma já explicam a razão para a área de TI ser essa "confusão", tem reclamação de tudo : do "patrão" gerente de projeto, do contrato PJ, das consultorias, do usuário que não sabe o que quer, do governo que não regulamenta, dos vendedores de metodologias "enganosas", do gerente de projeto "que não sabe nada", dos diretores, dos "gerentes/coordenadores/analistas" burros/ignorantes e por aí vai....... só faltou lembrarem que enquanto o profissional de TI se comportar como militante do MST, sindicalista, escrever "probrema" "bom censo" ou "sençato", vai passar a vida como o pedreiro que reclama do engenheiro.... por quê existe tanta notícia falando que em Tecnologia existe muita vaga para pouco profissional qualificado ? Infelizmente é preciso se atualizar.... não adianta senioridade em tecnologia de 10 ou 20 anos atrás. É preciso somar isso ao conhecimento de novas tecnologias para realmente oferecer valor ao mercado....... Até os bancos com sua arquitetura baseada em mainframe e Cobol utiliza de forma agregada frontend em baixa plataforma.

O grande problema vem de cima, do Gerente de Projetos. Cada gerente de projeto que domina uma área, com certeza não vai dominar a outra. Exemplo: Ter um gerente de projeto que domina somente redes e infra-estrutura, o que esperar dele para falar de sistemas. Ter um gerente de projetos bom em sistemas e não conhece muito de redes e infra-estrutura da empresa, também fica super complicado. Para quem estuda o PMBOOK, sabe que o Gerente de Projetos deve saber gerenciar qualquer tipo de projeto e não somente na informática, ai complicou mais ainda. Aquele universitário que fez administração e economia faz um curso para tirar certificação PMI e quer gerenciar uma equipe de TI, com certeza fica mais dificil ainda.

As tecnologias são novas e as metodologias ainda imaturas. Quanto a isso, não há dúvidas. Mas as coisas poderiam ser muito melhores do que são hoje se houvesse um real comprometimento das pessoas com um objetivo comum: o resultado final de um trabalho feito em equipe. Porém, a alta rotatividade nos projetos (particularmente nas contratações PJ) tem feito com que os profissionais fiquem mais preocupados com sua própria sobrevivência do que verdadeiramente com o projeto. O cara faz o trabalho de hoje pensando no de amanhã. É difícil obter qualidade numa situação como essa.

Simples, enquanto as empresas envolvidas (contratante e contratada) perderem um tempo precioso com contratos para protegerem seus traseiros, equipes despreparadas e até mesmo desmotivadas e gerentes de projetos que planejam prazos jogando dados, continuaremos vendo nosso credito como profissionais de TI afundando mais e mais a cada dia. E não adianta tentar aquele papinho de falta certificação PMI, SCUM, etc, porque competência e bom censo não está a venda por ai...

Simplesmente por que são feitos por pessoas que cairam de paraquedas se auto-denominando Gerentes de Projetos sem ter a minima noção ou conhecimento do assunto.

O que faltam as pessoas envolvidas no projeto seriam: COMPROMETIMENTO e COMPETÊNCIA.Pois se todos estivessem engajados em entregar um projeto, qualquer metodologia seria eficiente. Pois o que ocorre muito, é que cada um por si e todo mundo querendo puxar o tapete dos outros.Já vi pouquissimos projetos sendo entregues no prazo e muitos com o prazo estourado devido a vários problemas (falta de interesse, problemas de relacionamento entre as pessoas envolvidas, interesses pessoais e muitos outros).Já houve INTERESSE entre as partes, boa parte dos problemas não ocorreriam. Conhecimento é só encontrar as pessoas certas. Aquelas que tem vontade de trabalhar e de aprender, alem de terem boa vontade.

"O programador solitário de antigamente foi substituído por uma equipe de especialistas em software, cada um se concentrando numa parte da tecnologia necessária para produzir uma aplicação complexa. No entanto, as questões que eram feitas ao programador solitário são as mesas questões ques são feitas quando modernos sistemas baseados em computador são construídos:<br> * Por que leva tanto tempo para concluir o software? * Por que os custos de desenvolvimento são tão altos? * Por que não podemos achar todos os erros antes de entregar o software aos clientes? * Por que gastamos tanto tempo e esforço mantendo programas existentes ? * Por que continuamos a ter dificuldade em avaliar o progresso enquanto o software é desenvolvido e mantido ?"Pressman, Roger S - Engenharia de Software, sexta edição - pag. 3 e 4 cap. 1, Outra, "Em vez de perguntar por que o software custa tanto, precisamos começar a perguntar o que fizemos para tornar possível que o software de hoje custo tão pouco? A resposta a essa questão nos ajudará a continuar o extraordinário nível de conquistas que sempre distinguiu a indústria de software"Tom DeMarco [DEM95]" Ivaldo

Olá bom dia a todos.

O despreparo dos proficcionais de TI em Gerência de Equipes ou conhecimento de Negócios (me incluo também pois tb não sou nenhum Expert), dificulta bastante o bom desenvolvimento do projeto. Vejo muitos profissionais que dominam determinada linguagem de programação ou hardware, mas na hora de apresentar uma solução treme!

Hoje o mercado de TI precisa de profissionais com bom conhecimento técnico mas que seja acima de tudo um vendedor, as empresas não buscam mais aquele "Nerd" de óculos fundo de garrafa que sabe consertar computadores, as empresas esperam que cada profissional contratado ajude a ganhar dinheiro, mas muitos dos profissionais de TI não tem essa visão de trazer soluções para a empresa faturar, e quando são gerenciados por pessoas mais despreparadas ainda, a tendência é realmente naufragar.

O Programador é melhor que o PM? O Engenheiro é melhor que o Tecnólogo? Isso é apenas briga de ego, que viciadamente os profissionais de TI passam constantemente, mas qualquer um deles pode errar, somos humanos, e se realmente fossemos perfeitos o mundo não estaria do jeito que está...

As "boas práticas" estão ai para ajudar, mas muitos por aí acham que (por exemplo) o PMBook é uma bíblia, e saber o que está escrito em cada linha lá fará dele "um profeta" em projetos, e se realmente fosse assim, a própria bíblia religiosa já nos teria levado ao paraíso.

Enfim os profissionais ainda precisam de muito para fazerem da TI uma área realmente respeitada pelas empresas e sei que quanto mais nos prepararmos será melhor. Portanto boa sorte a todos.

Existem muitos problemas que causam estouro de prazo. As vezes o proprio cliente que solicita o SW comete equivocos durante a fase de levantamento.Por sua vez, a empresa que fabrica o SW pode atrasar a entrega devido a problemas técnicos (riscos não mitigados) como também problemas inerentes ao esforço (pessoas adoecem, saem da empresa,desviam no desenvolvimento dos UCs.). Agora, para evitar o atrazo na entrega é simples, basta alocar mais recursos (pessoas) ao projeto.Porém, a lucratividade da empresa começa a cair drásticamente. O que a maioria das empresas fazem ? Negociam o prazo de entrega com o cliente.

não podemos culpar a metodologia, seja ela qual for (pmi, itil, cobit, etc). ela vem apoiar o projeto/gestão, e foi baseada na experiência adquirida com outros projetos. nem tudo se aplica a tudo. do ponto de vista de projetos, a falha é do gerente de projetos, seja pela fraca definição do escopo (na minha opnião, a maioria das vezes), pelo planejamento ruim (vejo isso acontecer muito). obviamente, as pessoas envolvidas são responsáveis. pessoas falham, não se comprometem. daí tudo vira uma bola de neve. do ponto de vista de quem contrata, uma vez o escopo (mau) definido, o cliente quer o que foi prometido. ou seja, se errou no inicio, vai errar aé o fim. e não adianta mudanças solicitadas, se quem comprou não quiser pagar a diferença para corrigir. é atestar que o gp (e sua equipe) é incompetente. sou profissional de ti produção, e vejo esses erros básicos (e grosseiros) de projetos todas vez que sou envolvido (por bem ou por mal).

Gostei da resposta do Flavio Casacurta, mas faço algumas ressalvas... No momento de venda de um produto, no momento que o cliente lê o contrato, e este contiver restrições demais, o cliente pede para refazer e aderir do jeito que ele quer. Eu acho o que deve ser feito qdo o cliente atrasar algum insumo (ex: senhas, acesso à rede, etc) é que o projeto seja paralisado até que o cliente cumpra o acordado. Isso eu acho legal, eu só 1x isso acontecer.

No país existe RH para avaliar psicologicamente o candidato, existe funcionários qualificados na empresa para avaliar o conhecimento do candidato, existe a administração para avaliar o salário do candidato, contratando amigos de funcionários, quebrará essas três existências e a empresa se tornará o "Banco da Praça".

A resposta é simples!!!

IMPUNIDADE

Embora estejamos covivendo com tecnologias de última geração, o problema não está nas tecnologias e sim as pessoas que fazem parte deste processo.

As pessoas - nós - somos seres humananos.

Num projeto de TI, que comteple todos os requisitos de qualquer extrategista, falhará se não houverem penalidades para quem não cumprir sua parte.

Basta estabelecer três perguntas: -O que? -Quem? -Quando? E...Quem não cumprir sua parte será penalizado.

Quem topa?

O primeiro a não cumprir sua parte, normalmente, é o solicitador da tarefa.

Já vi casos onde o usuário levou três meses para liberar a senha de acesso ao sistema, o outro foi um parto, levou nove meses para liberar os arquivos para teste.

Se não houver comprometimento e penalidades, as guerras das vaidades, os intereces financeiros, entre outros farão qualquer projeto seja ele de TI ou outro qualquer fracassar.

Quando você compra um carro financiado, existem cláusulas no contrato que prevem que você irá perder o carrro se não cumprir estas cláusulas.

Se você contrata um serviço de TI e ninguém irá perder NADA se não cumprir o contrato, fatalmente este contrato será quebrado, e possivelmente custará mais caro que o previsto, se porventura for concluído.

Flávio

O acordo de pagamento da solução a partir da entrega de um conjunto de "deliverables" que perfazem as fases do projeto (fase1-Proposta Comercial/Técnica, fase2-Especificação de Business Processes, fase3-Implementação, fase4-Homologação e fase5-Go Live). As fases de planejamento do projeto (entendo que são fase 1 e 2) são parcialmente ignoradas, confiando e impondo à equipe técnica a missão de construir nas fases subsequentes o que fora mal planejado, e estes são os heróis que vão garantir a sustentabilidade do projeto. A equipe do projeto começa o trabalho de construção do produto, e como a equipe comercial e de análise normalmente nunca digitou uma linha de código, não sabe a complexidade de construir uma aplicação mal planejada. Aí o tempo passa, o prazo aperta, o custo estoura, e pra quem sobra a bomba? Pros desenvolvedores!!! Que legal! Aí, o stress se estabelece, a equipe é obrigada a trabalhar inúmeras horas por dia, a equipe se esgota e entrega um produto com baixa qualidade, para o início da fase 4. O cliente identifica que a aplicação não atende suas expectativas, o stress aumenta cada vez mais. A equipe começa a se desfazer, desencadeando um processo inevitável de "turnover". Resultado: a consultoria perde o conhecimento. E assim vai, até que ou o cliente desiste, ou a consultoria desiste, ou nenhum dos dois desiste, mas aguardam que a solução caia do céu, e por puro talento da equipe de desenvolvimento, o projeto enfim termina. Chega-se na fase 5, início em produção, aí inicia-se o processo de manutenção do sistema. Não pretendo iterar o algoritmo recursivo. Aos desenvolvedores: vcs têm que aprender vendas e análise!!!!!

Os comentários de "o cliente altera o escopo" não cola.

Se o cliente pediu alterações radicais, foi devido a incompetência dos Analistas, na hora de enxergar a verdadeira necessdade do cliente e deixar claro os limites da solução e também em oferecer melhores maneiras de resolver o problema do cliente. Cliente é..cliente, sempre quer o melhor, no menor prazo, com menor custo. O quanto a frente da empresa vai se prostituir para atender isso, é que vai determinar o sucesso de entrega do projeto.

O que acontece todos os dias, são vendas de projetos enormes, sem nem mesmo existirem (setores de venda, vendem o que o setor de produção ainda considera como prova de conceito), com prazos menores do que o aceitavel e baixo custo. O Prazo diminui, o custo também, então é impossivel contratar mais profissionais. Logo, independente de habilidade do desenvolvedor (mesmo sabendo que tem muita gente horrivel tentando ser desenvolvedor), não tem como o prazo ser cumprido.

O problema é la de cima. Não é do Gerente, nem da equipe, na grande maioria dos casos.

O Gerente tem a obrigação de passar a quantidade de horas exatas, que sua atual equipe consegue fechar a solução, no prazo determinado.

Se o prazo vendido for menor que o necessário, é OutOfResources exception. Como ela é tratada? Geralmente com muita gambiarra...

Falta oferecer salário descente para voltar a atrair mais profissionais qualificados.

Bem.... este é realmente um assunto bem complexo... E creio que há várias razões pela qual isto ocorre.

Uma delas, e a que vejo na empresa onde trabalho atualmente é que, embora a equipe de informática reafirme que um projeto poderá levar mais tempo para ficar pronto, há uma extrema cobrança por parte da alta direção e comercial de que fique pronto antes deste prazo.

Ou seja, o prazo final é fornecido por pessoas alheias ao departamento de informática, e logicamente, este prazo irreal nunca será cumprido.

Não entendo como o meio de pressão resolve o problema, mas se eles ao menos observassem que pela área e objetivos de um projeto que visa oferecer qualidade no produto que é realizado, jamais fariam tal pressão.

Mas claro, como falei no início, este é apenas uma das inúmeras razões pela qual um projeto de software estoura o seu prazo e, consequentemente, seu custo.

Li quase todos os comentários deste FORUM e o que pude ver é que todos os profissionais que aqui colocaram seus pareceres sabem realmente parte ou em todo os problemas do desenvolvimento de uma solução em TI. Concordo com o João Ninguém, com o Kaizen, com aMaria, com o Carlos, Com o Marcelo, Com o Ivaldo, com o Rodolfo, Com o Monari (Carlos), Celso Dias, Rudimar e outros que aqui postaram suas experiências. Gostaria de salientar ao colega Jefferson, que o titulo de Certicação PMI, hoje emdi é muito bom para se arrumar emprego, pois muitas empresas ao publicarrem seus editais solicitam a Certificação. Porém, quero registra ao colega que, já trabalhei com vários certificados PMI e todos os projetos naufragaram em todos os sentidos. Portanto o que precisamosnão é de Diploma, Certificação ou qualquer outro Título e sim habilidade, experiência e também conhecimento da função que execer. E até onde eu conheço, PMI é fundamentado em melhores práticas e processos de Gestão de Projeto e não contempla Engenharia de Software. Como vê a coisa é muito mais que Receitas do PMBOK. Respeitosamente,

Arnaldo

Por que mesmo com novas tecnologias e metodologias, muitos projetos de TI, no Brasil e no mundo, estouram o prazo, o orçamento e a paciência dos usuários ? Quando fiz meu primeiro curso de informática em 1979, linguagem COBOL, o professor disse à classe a seguinte frase: - O computador é burro, ele faz o que vocês mandam (ou seja o que é programado para fazer). Como vocês podem ver, já passou 30 anos e apesar das Tecnologias, Metodologias, Melhores Práticas e outras formas de desenvolvimento de soluções de TI, não podemos dizer somente que Prazos, Orçamentos e a Paciência dos Clientes mas, também temos que analisar se a solução desenvolvida está aderente à necessidade do mesmo. Portanto mesmo que se cumpra o Prazo e o Orçamento nã o podemos dizer que atendemos a necessidade do Cliente. Em relação ao por que, apesar de todos os recursos (Tecnológico, Mélhores Práticas) existentes, não estamos atendendo aos Clientes de forma satisfatória fica aqui uma analogia. 'Não adianta ter o melhor gramado (no estadio de futebol), a melhor chuteira, a melhor bola, o melhor uniforme e o melhor esquema de jogo! Tudo isso não faz um time ganhar a partida ou até o Campeonato! É preciso talento, feeling, empatia, sensibilidade, vivência do profissional, ou seja, HABILIDADE para exercer a função de Identificação do Negócio, dos Requisitos, dos Processos e Métodos e demais habilidades necessárias.'

Mudança de escopo, como alguns aqui já disse. O negócio é muito dinâmico e o usuário desce mudanças goela abaixo do PM e sua equipe. Claro que pode haver algums mudanças pontuais mas isso não pode ser regra. Quando isso vira regra o resultado, na melhor das hipóteses, é atrasar.

Resposta: A pergunta desse fórum já veio acompanhada com a resposta. Óbvio que os projetos atrasam por causa das novas tecnologias.

Justificativa: As empresas vêem nas novas tecnologias o santo graal do negócio. Se a empresa dá prejuízo, deve ser a tecnologia T++ que vai resolver o problema do caixa que vive no vermelho, vai aumentar a produtividade dos funcionários, vai deixar os clientes e os parceiros felizes.

Senhores. O negócio vêm sempre antes da tecnologia. Conserte primeiro o negócio, depois invista em tecnologia.

Segundo um livro que li, um estudo demonstra que as pessoas estão trabalhando 20% mais do que na década de 80. Uau! Em outras palavras, as new techs além de não cumprirem com o prometido, aumentarem em 20% o gasto das empresas com folha de pagamento.

Estamos carecas de saber que a tecnologia nova aparece para resolver o problema que a tecnologia anterior não resolveu. E esta por sua vez cria novos problemas para as tecnologias posteriores resolverem.

Adicione nessa espiral destrutiva as consultorias com prazos mentirosos, funcionários páraquedistas, escopo flutuante, gerenciamento de project (não de projeto), falta de conhecimento do negócio, festinhas e comemoraçõezinhas sem motivo (para dar a impressão de etapa concluída), ou seja, engabelação até o fim.

E aí o projeto atrasa um mês, dois, três...

Por causa do gerenciamento, não era, mas hoje é assim, os gerentes não precisam ser desenvolvedores nas tecnologias usadas, mas conhecedor das mesmas, para saber dimensionar e precificar projetos, muitos sabem os preços de pontos de função, pois já estão pré-definidos, mas não sabem como cobrá-los dos seus desenvolvedores.

Por que falta capacidade em gerenciar projetos, definir escopo, plano de mudanças de escopo, comunicação, riscos entre outros fatores. Precisamos de gerentes de projetos qualificados.

Vejo o problema sob alguns aspectos : 1) Cliente que encomenda o projeto - Define Quanto Pode ou esta disposto a pagar ( a princípio, aqui não vejo problemas desde que, o orçamento seja realista com o projeto desejado, é correto definir quanto pode ser gasto nele ) 2) A empresa contratada para executa-lo calcula qual o lucro que pode obter do projeto ( na prática, na maioria das vezes é só isto que elas pensam . No máximo, pensam em fidelizar o cliente com um projeto bem feito - neste caso, não vejo problemas ) 3) A empresa contrata profissionais ao menor custo possível, sem levar tanto em conta a experiência e/ou casos de sucesso em projetos anteriores . O que vale é quanto menos o profissional cobra, maior o lucro no projeto. De antemão avisam que não pagam horas extras e no caso de PJ, fazem o contrato com horas fechadas ( neste caso, as horas extras ficam por conta apenas do empenho do profissional em fazer o trabalho bem feito e no prazo mas, não ganha $$ nada por isto além de "parabéns". ) 4)Especificações mal feitas, incompletas. 5) Prazos de desenvolvimento irreais para o que esta sendo pedido. Mesmo quando é usada alguma ferramenta para metrificar os esforço de desenvolvimento, no final de tudo são feitos ajustes para diminuir o prazo para diminuir os custos ( ou potencializar o lucro ).

Em resumo, nos meus mais de 20 anos na área de T.I. o que percebo é o que relamente vale é puramente a ganância em detrimento ao bom planejamento e valorização profissional. Bom exemplo disto são empresas que mal ouvem falar em "crise financeira internacional" saem fazendo cortes (leia-se demissões ou dispensas) mesmo que estas crises tenho impacto pequeno e/ou notadamente passageiro.

Por incrível que pareça, o comentário do Jorge Ben Jor aí foi o mais pertinente de todos. O grande problema é a criação. As crianças hoje em dia estao sendo criadas de qualquer jeito, viram marginais, irresponsáveis, acham que podem fazer o que querem, nao têm disciplina, muito menos respeito, nao têm controle de nada, e acham que tudo é facil, principalmente os filhinhos de papai e as patricinhas. Qual a consequencia? Quando entram no mercado de trabalho vira isso. Essa bagunça generalizada, sem compromissos, sem respeito, sem responsabilidade alguma, e achando que sao melhores do que os outros. Nao tao nem aí com coisa alguma. E isso vale pra todos os envolvidos no projeto, seja a empresa contratante quanto quem está gerenciando e executando o projeto. Os pais NAO sabem, ou melhor, NAO querem disciplinar e educar os filhos mais.

O comentário do Motorizer já vale a visita a este fórum, parabéns ...

Um ponto que parece ser comum a todos é a questão do escopo. Os projetos realmente precisam ser mais bem definidos, mas acho que mesmo com as melhores metodologias é impossível chegar no nível de detalhamento desejado. O tempo para este levantamento é muito grande, o usuário muda de idéia, a necessidade do negocio muda, o governo muda as regras, as tecnologias mudam, a concorrência muda e etc.

Será que não estamos querendo o impossível, ...a definição ideal do escopo ...

Mudando um pouco o foco e falando das soluções para o problema, creio que ainda falta uma tecnologia que permita o desenvolvimento rápido de um sistema e que ao mesmo tempo seja flexível para permitir mudanças no meio do caminho.

O computador melhorou muito no visual, gráficos e etc, mas por debaixo de tudo isto, o ambiente de rede, servidores, banco de dados, programação e etc, ainda tem que ser tratados num nível de detalhe muito grande, só quem é da área sabe o trabalho que da domar todos os bits, para obter aquilo que os usuários acham que é fácil .

Porque as EMPRESAS querem comprar pelo menor preço. As CONSULTORIAS querem vender de qualquer jeito. O cliente quer RECEBER mais coisas do que pagou. O Gerente de Projeto quer ENTREGAR o projeto. Os consultores e analistas querem ficar o maior tempo possível no projeto. Vários stakeholders por interesse próprio sabotam o projeto. O prazo geralmente é IRREAL. E assim vai...

Moro num país tropical, abençoado por Deus E bonito por natureza, mas que beleza Em fevereiro (em fevereiro) Tem carnaval (tem carnaval....

PESSOAL NÓS MORAMOS NO BRASIL, SE ESQUECERAM?

Aqui é assim e sempre será... Querem mudar? Eduquem seus filhos!

Também lí um comentário dizendo que os problemas são 100% da gerência do projeto.

Uma boa parte dos atrasos ocorrem após as primeiras entregas, quando o cliente diz : "Não foi isto que pedi", e aí todos conhecem a famosa "zona do desespero". É neste ponto que a equipe e o projeto como um todo ficam comprometidos(se não for bem gerenciada).

E claro, existe também o peso das falhas na gestão de projeto.

A receita é simples: defina o escopo do sistema no campo de golfe ou no almoço. Quando o cliente perguntar quanto custa, responda 'quanto vc tem pra gastar?'. Quando o cliente perguntar quanto tempo vc entrega, diga 3 meses, o tempo padrão de qualquer projeto. Adicione profissionas recém chegados no mercado, mal pagos, sem dinheiro pra se reciclarem. Contrate aquele 'amigo indicado' que voce acha que nao vai dar problema porque foi indicado. Para as vagas que sobraram, demore bastante pra contratar, fazendo os candidatos passarem por inumeros testes pra chegar a conclusão que cara bom requer salario bom. então contrate aquele primeiro zé que foi mal nos testes mas pediu 1200,00 de salario. Como o tempo passou, faça o pessoal trabalhar todo dia até as 23hr, sabados, domingos, até o momento que de tão cansados, não conseguem nem raciocinar mais direito. enquanto isso, de ouvidos a todas as mudanças de requisitos que seu cliente pedir. Atenda a todos os requisitos, até se ele pedir pro sistema fazer café. Em 3 meses voce terá um gerente de projeto na rua, a equipe desgastada pedindo férias (os que sobraram, porque metade foi viver esta mesma experiência em outras consultorias), um cliente enfurecido e um dono de consultoria feliz por dois motivos: porque mesmo assim recebeu e ficou com a maior parte do bolo e porque o mesmo cliente contratará a mesma consultoria pra rememndar o sistema mal feito. Afinal neste pais cliente não processa fornecedor.

Falhas e/ou insuficuência na documentação. Entenda-se por documentação, tudo aquilo que foi acordado com o cliente até a documentação entregue ao Desenvolvedor.

Por isso existem especialistas em cada área. E ainda existe o problema de contratar pessoas sem a devida qualificação para determinada competência.

Também lí um comentário abaixo dizendo que desenvolvedores deveriam entender de negócios.

Just one comment: Cada macaco no seu galho.

grande problema, vemos pessoas sem estrutura nenhuma fazendo parte de projetos complexos, pessoas endividadas, problemas familiares, depressivas, sem capacitação superior e cursos, seja qual área for, é preciso o investimento em conhecimento, aprende-se a pensar, uma pessoa que ler e estuda e não tem problemas sempre cria soluções mais rápidas.

maioria dos problemas se resolve com um bom salário $$$, é isso que falta, um bom salário para tranquilizar os funcionários e assim eles podem dar o melhor de si, agora ganhando pouco, trabalham desmotivados, esperando uma oportunidade melhor e enquanto isso vão levando...

O PROBLEMA É GERAL. E , NA MINHA OPINIÃO , SE DEVE AO ENORME NÚMERO DE INCCARA COMPETENTES ATUANDO NO MERCADO. FAZEM UM CURSINHO QUALQUER E JÁ SE DIZEM ANALISTA DE SIATEMAS. OUTRO PROBLEMAS SÃO AS CONSULTORIAS QUE, PARA TEREM MEIORES LUCROS, CONTRATAM QUEM PEDE MENOS. E, É CLARO QUE QUEM SE SUBMETE A BAIXOS SALÁRIOS NÃO É UM PROFISSIONAL BEM PREPARADO ! ENQUANTO AS EMPRESAS CONTINUAREM COM A IDÉIA DE NÃOINVESTIR EM T.I PROPRIA , ISSO ESTARÁ ACONTECENDO.

Infelizmente, pensá-se no brasil, que dinheiro em informática é custo e não benefício/investimento!

o problema é que pagam muito bem aos analistas de negócios que não entendem nada sobre as tecnologias e acham que tudo é simples, e também o lado do programador que por mais que utilize linguagens como UML e RUP, tem que conhecer o negócio.

Muitos coordenadores de projetos usam UML mas não sabem criar modelos corretos e o programador seguindo afinco faz um sistema ineficaz e fora do que o cliente solicitou, vale a pena usar o velho português estruturado, definindo bem o objetivo do sistema no escopo.

Para mim programador não existe mais, o cara tem que ser um analista também, uma pessoa que conheça as regras de negócio, o problema é que esse profissional custa e normalmente coordena os projetos, um programador que seja um analista e conheça os negócios vai fazer tudo em menos tempo e vai executar da forma correta, mas com salários de 2,3 e 4mil não se arruma um profissional assim, no meu ponto de vista vai de 6mil em diante e quem pagar não terá estouro nos orçamentos e prazos, uma vez que este custo estará embutido.

A verdade deste fenomeno tem uma origem, nâo unica, mas um ponto que vale ser lembrado, Terceirizaçâo, Baixos salarios, vinculos precarios de trabalho, falta investimento em treinamento de empresas de T.I , afinal quantas empresas de T.I possuem departamentos de treinamento ou mesmo verba disponiveis para tâo fim????,,por fim a grande maioria dos projetos sâo feitos por pessoas que sâo contratados como P.J , quarteirizados de empresas que tocam os projetos, ou ate cooperativas é esta falta envolvimento das pessoas que é natural , pois todos sâo suficientemente inteligentes para saber que nâo possuem nenhum vinculo com empresa contratante ou que prestam serviços ,ao final daquele projeto serâo descartados como papel velho e deverâo aguardar que um novo projeto apareça e possam concorrer a uma vaga para atuar nele, por final é até interressante que um projeto atrase pois será mais tempo que o profissional ´permanecerá empregado.

Porque os desenvolvedores não entendem nada das regras de negócio. Desse jeito, vai passar a vida fazendo formulários de cadastro sem nem saber pra quê servem. Cadastrar/incluir/pesquisar/editar. Cadastrar/incluir/pesquisar/editar. Cadastrar/incluir/pesquisar/editar.

O problema do analista, é que a empresa pensa que ele é gerente de programador. O que a empresa não sabe, é que analista sem programador é o mesmo que nada.

Olá. Acho que primeiramente todo analista de sistemas, negócio, coordenador, etc, deveria ter sido programador, todos deveriam começar com a programação, porque na minha opinião, o gargalo de qualquer sistema é a programação. Sempre estoura lá, mesmo aquela "diferença" que falta para terminar o projeto sempre depende da programação. As faculdades ensinam analise mas programação, só dão uma explicada geral. Aí o recém formado sai se achando um baita analista, e sempre subestima a programação. Acho que falta estrutura a todos, porque não tem jeito, o vendedor vai vender o seu peixe e claro que vai falar que se o concorrente vai demorar 6 meses, ele faz em 3. Claro, nas não é ele que vai programar e acho muito fácil, fazer um monte de desenhos falando que mostram a modelagem de dados, a interação com o usuário, etc. Mas sabem como fazer isso, construir isso? Claro que não. Vai sobrar pros programadores. E alie-se a isso alguns usuários que não sabem o que querem, também aqueles que mudam de opinião, aqueles que não conhecem o negócio, etc. e tal.

1. Falta de domínio do negócio; 2. Análise de Riscos precária ou inexistente; 3. Não há estudo de viabilidade e, se há, é ineficiente; 4. Pouca ou nenhuma Engenharia de Requisitos; 5. Projeto mal feito ou inexistente; 6. Corrida para programar;

O principal problema é o planejamento do projeto. Já vivenciei inumeros projetos que são vendidos com um escopo inicial pequeno, bater o martelo quando não há uma análise completa.

Isso acaba acarretando a "descoberta" que o projeto tinha uma complexibilidade maior, que os prazos e valores vendidos não iriam cobrir o custo assim muitas das consultorias adotam a pior medida que é a contratação de profissionais de "risco" que em muitas vezes com o custo baixo para "tampar" o problema de custo mas que acaba afetando a qualidade pois o "tempo" já fica praticamente comprometido pois sobra para os analistas, arquitetos e programadores mais experientes descobrirem como o "buraco" era bem mais fundo.

Acho que a partir desse cenário que alguns devem ter vivenciado é que ocorre o problema do valor do profissional, a qualidade, o prazo que não será "alterado" pois na "prática" basta colocar mais "recursos" que o problema estará resolvido.

Bom, essa é minha opinião.

O ponto focal e inicial do problema é a venda do produto que é feita sem a conciliação técnica de um profissional experiente (preferêncialmente um arquiteto de sistemas). Para o vendedor tudo é fácil de fazer tal qual um pastel de feira ... Tenho uma sugestão simples, trate um projeto de software como se fosse o projeto de um novo carro. Tudo deveser muito bem pensado e avaliado em função de históricos anteriores de construção. Por que dá-se a gestão de um projeto de software a pessoas que nunca construiram um. Que experiência tem aqueles que nunca puseram a "mão na massa" programando ou construindo um banco de dados? A maturidade de um gestor neste momento é crucial, mas infelizmente ouço por ai muitos dizerem que não é necessário que um gestor de projetos tenha conhecimentos técnicos de construção de software. Pensando assim é que vemos os projetos darem muito errado.

Após 27 anos de experiência posso dizer o seguinte:

Hoje as empresas e seus diretores, normalmente não técnicos, deixam-se impressionar por siglas, metodologias e certificações profissionais, não conferindo e nem se importando com a real bagagem e conhecimento de cada um! É como você contratar um recem formado em HAVARD, para substituir seu executivo que, pode até não ter curso superior mas, esta no mercado a 30 anos ! Por melhor que seja um curso ou formação, TRAINEE é TRAINEE ! Sujeito a todos os problemas que a falta de "janela" acarreta. Não adianta um belo cronograma, em rede de PERT CPM com análise de ponto de função e certificação PMP/PMI, se o profissional não conseguir obter a cumplicidade dos usuários e técnicos. Lembram da moda do DOW-SIZE? Quantas empresas "quebraram a cara" ? Não quero aqui, de forma alguma, menosprezar as certificações CMI, PMP,PMI, ITIL ou outra qualquer, Mas sim, lembrar que estas são ferramentas que devem aliar-se a experiência e não substituí-la

Boa tarde; Primeiramente muitas empresas "estouram" o orçamento da empresa pois não não tem muito conhecimento em custos industriais e acabam formando o preço de venda de forma errada, ex: tenho um custo de fabricação de um projeto a R$100,00 e um ICMS de 10%, então muitas empresas consideram que o preço de venda deste projeto é de R$ 110,00. Esta é uma forma errada, pois quando a receita for descontar este ICMS irá tirar 10% sobre o preço final, então, 10% de R$ 110 = R$ 11,11 e não os R$ 10,00 incluidos na formação de preço de venda. Claro, existem outros erros que as empresas cometem, como a elaboração dos custos, rateio das despesas fixas e não entendimento do faturamento objetivo, por isso acabam estourando o orçamento.

Acredito que o problema seja bem óbvio para todos.

Por mais que queira se acreditar, desenvolvimento de software na prática não é ciência exata menos ainda ágil(não falo aqui formalmente dos processos Agile). Vários processos formais, ainda que não mencione isso, nas entre-linhas afirmam que é possível planejar a data de finalização EXATA de um sistema.

Em minha experiência de cinco anos não lembro de nenhum gerente de projetos que se não fosse competente, ao menos fosse digno de aceitar que ele não tem respaldo pra definir prazos ou entender minhas decisões técnicas. Além disso, sabemos que para gastar-se menos com o projeto, contrata-se "profissionais" não exatamente competentes ou sequer com um mínimo de ética pra ter o cuidado de não construir bombas-relógio que explodirão na sexta a noite.

O resultado disso tudo: noites viradas, fins de semana trabalhando, tempo de menos com família, problemas de saúde variados por stress, estafa... tudo por um sistema que não vai facilitar tanto assim a vida de usuário, que aliás raramente é procurado durante o processo.

Eu já conclui que não vale mais a pena bater cabeça e esmurrar ponta de faca e já penso em uma maneira de sair desse mercado.

Desenvolver um sistema nunca foi e nunca será um trabalho simples e rápido. Informática é tecnologia, e tecnologia custa caro mesmo, quem não quer pagar o preco que vale que nao se aventure...

Na minha opinião a culpa não é dos programadores ou analistas. É molecagem das empresas mesmo. As empresas querem lucros altissimos, e reduzem o custo o maximo que podem, pagam porcarias de salarios (para qualquer tipo de trabalho) e querem ter certificado ISO, aqui, certificado ali...Hoje em dia as empresas contratam uma consultoria, que contrata programadores e analistas, os prazos são impostos pela propria empresa (como pode isso? somente os analistas e programadores podem apontar um prazo) que libera uma verba mediocre. Eu acho que as empresas tem que aprender a tratar a informatica como o produto que ela vende. Fica ai contratando molecada para desenvolver sistemas, nao investem um centavo na capacitação do profissional(por isso mesmo contratam consultorias).

Eu estou cansado de ver coisas deste tipo, note os anuncios de oferta de emprego, querem que o profissional conhecam asp, dot.net, php, certificado disso e aquilo, e quando pagam é porcaria que nao serve nem para comprar papel higienico. Estou cansado de ver anuncios para programadores por 800 mangos ou até menos. Eu não achei meu computador e livros na lata do lixo. E quem fez o suado curso de analise de sistemas entao...gastou uma grana preta para nada.

Olá! Muita teoria e pouca prática! Os envolvidos precisam sentar ao lado dos usuários e entender o que eles precisam, não para facilitar o trabalho deles, mas sim para a empresa ganhar dinheiro. Gerentes de projetos e analistas precisam pensar em como a empresa pode ganhar dinheiro.

Ao Sr. "O Crítico"

Concordo com seu comentário e reforço:

A TI tem muita gente ainda. Mas isso há de passar. Aqueles profissionais que amam a profissão e começaram lá, na escovação de bits permanecerão. Obviamente que há muitas exceções, mesmos aqueles profissionais que nunca passaram pela programação, mas sabem o que fazem, também permanecerão.

Enfim, quando o festival de estrelinhas sairem do cenário, a sopa de letrinhas (melhores práticas) poderá ficar legível a todos nós.

Abraços,

A culpa sao dos Gerentes de Projetos e Analistas de Sistemas que nunca foram Programadores ou Analista Programadores.

Com o grande crescimento de certificações para Gerencia de Projetos, cursado por pessoas sem experiencia na Pratica do desenvolvimento de Sistemas, os projetos e sistemas ao redor do mundo sofrem nas mãos de pessoas certificadas ganhando muito dinheiro que só sabem fazer Gant Charts e acrescentarem linhas a projetos.

Tirem esses idiotas do poder e ponham verdadeiros Analista de Sistemas que vieram da Programação que estudaram e que entendem realmente como um sistema deve ser feito e quanto tempo isso levará. Não um bando de metidos que gastaram milhões fazendo PMP, Prince2 e etc, e que realmente não tem noção muitas vezes do que está sendo projetado.

"Proficionais" Forçou. A qualidade está péssima mesmo.

Acho que os projetos não estão dando resultado porque os empregadores estão preocupaos, unica e exclusivmente, com o salário do contratado, não levando em conta a experiência, e/ou, o conhecimento adquirido atravéz de anos de trabalho. Num país onde "universidades" proliferam como praga, a qualidade do ensino esta péssima, sou instrutor de lógica de programação e lógica avançada, em importante instituição brasileira e posso garantir que os proficionais que hoje se formam, não tem respaldo para "tocar" um projeto de grande porte sozinhos. Basta dizer que estes proficionais são iludidos por pessoas (professores) onde, no nosso mundo de hoje já não existem mais "Mainframe", "Cobol" e... "Lógica", tudo é feito na base do "clicar arrastar e colar". Quando fiz meu primeiro curso de programação (1983), a prova final consistia em um balance-line entre 4 arquivos e ao final imprimir um valor (monetário) em extenso, sem utilização de recursos externos, dos 96 inscritos para o curso somente 12 passaram... e estão empregados e tocando projetos de grande porte ainda hoje.

O grupo tem que ter um lider, um lider tem que conhecer o grupo.

Muita teoria (PMI, PMP, Project) e pouca pratica.

Resultado de um punhado de PM (Project Managers com PMP) que so sabem inserir linhas no Project e nao tem a minima ideia do "negocio".

Embora a receita (PMBook) seja universal e aplicavel a padarias, infelizmente o pessoal acha que o modelo resolve tudo - o que nao eh verdade.

Das ultimas 10 interacoes que tive com PMs, infelizmetne apenas 1 prestava, mas acho que sou excecao. Sem dizer, que o fator custo x planejamento, as vezes transforma projetos anuais em implementacoes "nas coxas" realizadas em meses, muita vezes, sem um minimo de documentacao e controle.

Concordo com grande parte dos comentários. Planejamento realmente é uma parte vital para que prazos e faturamento não estourem, mas sem dúvida alguma todas essas novas tecnologias e metodologias acabam por não tratar do cerne da questão: pessoas. Trabalho com Change Management há 7 anos e venho acompanhando muitos projetos e empresas que se esquecem de gerenciar pessoas antes de gerenciar projetos. Fica fácil cumprir metas, prazos e budget quando se apresenta um ppt ou quando se coloca as atividades em um project, mas são as pessoas (times de projeto e usuários), que farão o projeto caminhar e ditarão o tempo e o $$ para isso.

Orientação a objetos e outras culturas por mim consideradas "engenhocas" mediocres são feitas para angariar grana. Tudo que funciona MESMO é procedural (Cobol).

Será que não se reparou que a curva de aprendizado, custo e eficácia dessas "Budegas" são patéticas?

Existem alguns aspectos que devem ser levados em conta. Vou citar 2. Normalmente, no Brasil, quando algum diretor solicita um projeto, o mesmo já tem uma idéia fixa sobre o tempo que ELE acha que o mesmo deve durar. Infelzmente, o gerente de projeto é obrigado a engolir essa estimativa e "se virar nos 30", pois, se ele não aceitar assim, outro aceita. Além disso, há a data de início do projeto, que sempre é "ontem". Aí ele precisa contratar mão-de-obra ASAP, sem ter tempo sequer para um treinamento.

Cá entre nós, porque é disso que nós vivemos. Se não houvessem novas tecnologias e metodologias, ninguém ia fazer downsizing, ninguém ia trocar um sistema client-server por um sistema web, ninguém ia trocar um sistema 3 camadas por um sistema em SOA. Ou seja, de certa forma TI acaba sendo um fim em si mesmo. Se as tecnologias não ficassem obsoletas com a velocidade que ficam, as empresas estariam com os mesmos sistemas há decadas executando apenas um esforço mínimo de manutenção. Mesmo os bancos com seus antigos sistemas COBOL já passaram a manter o COBOL/DB2 no transacional e fazer o front-end em baixa plataforma..... De certa forma, essa "desorganização" da área é que permite tantas consultorias, tantos projetos, tantos profissionais, etc.

A existência de tecnologias e processos não garante o sucesso de nenhum projeto, porque as pessoas formam a base desse tripê. A pergunta seria: quantas empresas de TI se preocupam com a qualidade dos seus processos?. Isso implicaria em mudanças, principalmente na contratação de pessoas competentes. Quando a situação fica realmente crítica, a empresa volta a sua atenção aos problemas, quando na verdade deveria mitigar os riscos. Acompanhar e controlar as atividades são apenas partes de um processo de gerência de projetos.

Bom dia a todos!

Sou gerente de projetos Certificado PMP. Existem algum fatos que devem ser considerados:

Primeiro - a culpa por qualquer atraso ou aumento de custo em um projeto é 100% do Gerente.

Segundo – A maioria dos gerentes não Planejam de forma adequada o Projeto. Qualquer problema diferente do planejado deveria constar do Plano de Gerenciamento de Riscos, para que ações preventivas ou corretivas possam ser adotadas de forma adequada (identificando os riscos o quanto antes, para que o prejuízo possa ser o menor possível).

Existem áreas de gestão que são fundamentais para que tudo de certo, porém a principal é o fator humano, ter pessoas com a capacidade e habilidade adequada para gerenciar e desenvolver os projetos.

Qualquer dúvida, ou maiores detalhes vocês podem encontrar no PMBOK. Abraços

Bom dia a todos

Sou gerente de projetos Certificado PMP. Existem algum fatos que devem ser considerados: Primeiro - a culpa por qualquer atraso ou aumento de custo em um projeto é 100% do Gerente. Segundo – A maioria dos gerentes não Planejam de forma adequada o Projeto. Qualquer problema diferente do planejado deveria constar do Plano de Gerenciamento de Riscos, para que ações preventivas ou corretivas possam ser adotadas de forma adequada (evitar que o prejuízo possa ser o menor possível ou seja identificado o quanto antes).

Qualquer dúvida, ou maiores detalhes vocês podem encontrar no PMBOK. Abraços

É culpa da propaganda enganosa. Muitos gestores de projetos chegam no cliente e prometem melhor produto, melhor preço e menor prazo. Em boa parte dos casos, o profissional que faz a elicitação de requisitos não está bem preparado. Em 100 por cento dos casos os desenvolvedores NUNCA são consultados. Software não custa barato e envolve fator humano e tecnologico, portanto não dá pra apostar em milagres quando se apresenta uma proposta ao cliente. - Uma regra que eu conheço é a seguinte: maior tempo de planejamento implica em menor esforço de implementação e menor risco de retrabalhos.

Vejo que nossa categoria profissional sofre com o canibalismo do mercado como qualquer outra e como nao poderia deixar de ser, ainda com o agravante do limbo a que estmos sujeitos. A consequencia disso e esta qualidade de produto e/ou servico que ja temos fama em oferecer. O advento da evolocao em praticas e metodologias de projetos e uma constante. O mercado aceita isso e cobra o seu preco, alguns acham que esse preco seja tao alto a ponto de nao permitir que os pobres profissionais nao tenham vida social por conta de suas enormes demandas.

Estes caras e que precisam gastar algum tempo revendo seus projetos de vida em vez de criticar os proprios colegas que tambem tentam seu espaco.

Acredito que o real problema ocorre na definição do escopo...

Quando vendem o projeto, a fase de "pré-venda"se torna a fase de planejamento\levantamento e isso resulta em um levantamento MAL FEITO e INCOMPLETO.

Bom, com isso vocês já sabem qual o final da história

Porque complexidade das demandas tem evoluido junto com as ofertas de solução, isto é, conforme aumentamos nossa capacidade de atender o usuário (novas tecnologias, metodologias, maior capacidade de processamento, mais disco) este também passa a exigir mais. Ora, basta ver o tipo de sistema que existir no começo dos anos 70 e o que tem hoje. Não existiam gerenciadores de bancos de dados, tinha gente que tinha que todo dia regerar os indices do banco de dados (quem lembra do Clipper???!!!). Hoje temos interfaces gráficas (que exigem noçoes de design do programador), temos arquitetura cliente/servidor, 3 camadas, n camadas, para quebrar a complexidade das aplicações, temos gerenciadores de bancos de dados (perda de dados e recriar indices são coisas simplesmente inaceitáveis), aplicações na web para o usuário acessar de qualquer lugar (na decada de 80 a Web sequem era imaginável). E tudo tende a evoluir tanto as demandas quanto os métodos e tecnologias que vamos usar para atendelas, e o nivel de dificuldade e complexidade vai continuar aumentado demandando mais gente e tornando o trabalho dos gerentes de projeto cada vez mais dificl. Sorte pra nos que vamos ter mais emprego!

Infelizmente no Brasil temos o problema cultural do jeitinho e do favor acima da qualidade do trabalho, que afeta clientes, consultorias e consultores: - Os clientes acham que sai mais barato omitir informação na hora da RFP e do pré-levantamento para que possam "embutir" o que realmente precisam no sofware sem serem cobrados por isso.

- As consultorias cada vez mais estão precionadas por orçamentos baixos, encargos altos, mudanças absurdas de leis e regulamentações que geram mais custos sem nenhuma contrapartida do governo e principalmente pela baixa credibilidade, fruto de décadas de projetos fracassados. Mas tem muita culpa em manter amiginhos e filhos de amiguinhos em posições de liderança e comercial, no Brasil se vende software na confiança, se faz proposta sem descrever ou saber o que deve ser feito e sem consultar um técnico para avaliar a viabilidade do que foi pedido.

- Os consultores são na verdade a alma disso tudo, Gerentes, Analistas, Programadores são a alma das consultorias.MUITOS são o exemplo da cultura do jeitinho, que começa no curriculo floreado de aptidões que não possuem, vai pelo dia a dia sem planejamento da carreira, sem treinamento adequado para a função pretendida e etc. Pessoas mal preparadas em funções mal definidas, geridas por quem nem consegue gerenciar suas próprias finanças pessoais sem a mesada do papai. Infelizmente é isso que tenho encontrado em volume absurdo nas empresas por onde trabalhei. Tem muita gente boa, mas esses não sobem tão rápido, não ganham tantas promoções e nem tem tanto poder de decisão.

Os altos salários de informática trouxeram uma massa enorme de pessoas que a melhor habilidade que possuem é conseguirem boas indicações dos seus amigos!!!

E esse é na minha opnião o grande problema que temos hoje em dia!!!

Porque não há um planejamento adequado tanto da parte do cliente, tanto quanto da parte do profissional de T.I Infelizmente, a grande maioria não sabe negociar prazo, valor, custos e acaba com a paciência dos usuários. Um bom profissional hoje é aquele que consegue similar tudo isso além de atender todas as necessidades do cliente. Bom atendimento, entrega dentro do prazo, saber cobrar o necessário e saber faturar também.

Falta de uso de ferramentas e metodologias corretas de gestão. Exemplo: Critical Chain Project Management.

Vários fatores: Gerentes de projetos incompetentes, falta de autonomia ou apoio dados aos gerentes, montagem de equipe técnica fraca, fraca estrutura de gestão e apoio aos projetos da empresa, escopo mal definido, prazos definidos com base em critérios comerciais e não técnicos (este é um dos mais freqüentes), alterações de escopo sem devida revisão do projeto por pressões de clientes ou mesmo da empresa, metodologia mal aplicada ou estrutura mal montada, excesso de carga ao gerente de projetos.

Que gerente nunca viveu uma destas situações? Recebeu uma equipe imposta, não eram os profissionais adequados, mas eram os que estavam sobrando na empresa. Recebeu um projeto já com custos e prazos fechados, mas sem que alguém soubesse exatamente qual era o escopo. Deu um prazo, custo e recursos para o projeto, mas foi duramente pressionado a reduzi-los para não perder o contrato. Solicitou apoio ao patrocinador, à área de Gestão, mas acabou se sentindo sozinho do processo. Foi obrigado a interromper e retomar o projeto várias vezes por receber projetos com maior prioridade (quando não teve que levar juntos mais projetos que sua capacidade). Confiou nos pareceres da equipe técnica, mas ela estava altamente equivocada. Por vários motivos, teve que gerenciar, analisar, especificar, programar, homologar e implantar o projeto sozinho.

Se você, gerente de projetos, nunca passou por isto é uma excessão rara. Se passou por tudo isto e conseguiu entregar o projeto em dia, escreva um livro que será best-seller.

Por tudo isto, corre a bem humorada história, que os projetos tedem sempre a passar por suas três fases: 1 - A fase do OBA OBA OBA 2 - A fase do EPA EPA EPA 3 - A fase do AI AI AI

Abraços.

Simplesmente por que NOVE MULHERES NÃO FAZEM 1 FILHO EM 1 MÊS.

Por que o cliente SEMPRE altera o escopo, e NUNCA entende que alteração de escopo gera alteração de prazo(e quase sempre, de valores também).

Porque o escopo nunca é bem definido inicialmente, e as pessoas responsáveis pela gestão não aplicam as boas práticas de controle de mudanças de escopo. GERENCIAMENTO DE ESCOPO! Este é o caminho!

Simples! porque nao se aplica a teoria na pratica. Ja conheci diversos profissionais da area de TI, principalmente gerentes que acham que metodologias, documentacao, metricas, processos e etc... e tudo frescura! os caras querem e sair prototipando codificando e entregando do jeito que vai saindo... quando nao, aplicam as metodologias parcialmente... as vezes o comercial promete coisas impossiveis... e o resto da estoria nos ja conhecemos: atrasos, mudancas no escopo, retrabalho, bla bla bla...

as falhas estao no treinamento\conhecimento do proprio cliente que não tem o escopo e nem assessoria para criar o macro do projeto, definir um fluxo com os detalhes. Na outra ponta a falha de comunicacao entre vendas, gerentes e desenvolvimento que contam com o ovo sem a galinha.

Simplesmente por quê não tem GERENTE DE PROJETO competente o suficente para dar conta do recado. Os norte-americanos são muito melhores.... ;-D

Acredito que isto ocorra por alguns fatores, porém, o dia em que os Gestores de Projetos estiverem preparados para realizar a verdadeira gestão não só sobre os projetos, mas principalemnte das pessoas, muitos destes problemas devam ser sanados. Um projeto só pode dar certo quando conta com 100% de envolvimento e comprometimento por parte do time. Aí cabe às empresas pensarem num melhor preparo também de seu corpo de Gerentes, trabalhando de fato suas lideranças.

Pelo que vemos é praticamente unanime a situação do comercial vender um projeto para o cliente em 1 ano e TI entregar em 2 anos, ou seja vende por 500 mil e gasta ao final do projeto uns 2,5 milhoes em recursos, retrabalhos etc..e ainda para melhorar tem medo de cobrar do cliente as mudanças de escopo no decorrer do projeto não se impõe em questão de prazos e valores. Sempre fugindo da realidade. Exatamente como nós mesmos passamos nas situações de compras pessoais, em TI acaba sendo o mesmo blabla... promete-se : "Bem Usamos CMI, PMI , ISO e tudo que quiser" ; qdo passou 1 mes e a coisa pega ai pode tirar tudo isso ai e só codificar para entregar os pacotes que ja estão atrasados pro cliente. Quem sabe um dia isso ai melhora.

A grande maioria dos projetos é pra ontem e todo tecnologia e metodologia não são aplicadas por completo. A grande maioria dos projetos novos e manutenções são levantamentos de quase 90% juntamente com o usuário e 10% dos desenvolvedores. É muito fácil colocar a culpa nas consultorias nos analistas e nos programadores o difícil é assumir que errou.

Acredito que isso ocorre principalmente porque o brasileiro tem o péssimo hábito de querer ter vantagens uns sobre os outros. Então, fica uma briga para ver quem mais terá vantagem sobre uma venda. Infelismente vem da raiz do brasileiro. Fico feliz que vejo que aos poucos isso vai modificando. Mas ainda falta muito.

Por que, desculpem-me, é uma prostituição geral. A área comercial quer vender a qualquer custo. O cliente quer um off-road, a comercial tem um fusca e acaba vendendo uma ferrari. O Gerente de negócio quer mostrar serviço e não sabe o que fazer, não conhece o seu papel e fica perdido entre planilhas, prazos, planos, escopo, alisar o cliente, alisar o patrao. O programador está só a espera do próximo projeto que pagará mais. Ou seja, é um mix de tudo que já foi dito aqui.

Um projeto só atrasa pelo erro do gerente de projeto ao estimar e conduzir o projeto. E em segundo quando o gerente engole imposições da diretoria da empresa.

Infelizmente o ser Humano não sabe dizer NÃO. Para não perder uma venda, um projeto, dizem SIM, podemos fazer, podemos atender. Mesmo que a solicitação seja por exemplo uma UTOPIA um SONHO, mas não podemos perder vendas, projetos, e ai é dito que se atende, que se faz no prazo que o cliente quer... Temos que aprender a ser realistas e positivos, nunca prometer aquilo que sabemos que não será cumprido, só para não perdermos a oportunidade o cliente. Só que dessa forma perdemos o cliente e ainda ganhamos mais dores de cabeça e propaganda negativa.

Porque a maioria dos projetos ainda seguem o péssimo modelo waterfall, utilizando um modelo muito falho, com fases rigorosamente definidas e burocráticas, onde quando o caso de uso chega no programador para ser codificado, o cliente já mudou de idéia, todo o trabalho e tempo foi perdido. Então como fazer para desenvolver o que o cliente quer o mais breve possível? Hum, acho que teria que ser muito "Ágil"... Agil? Agil, isso me lembra XP, Scrum... Exatamente, hoje só agilidade funciona. Boa sorte a quem ainda "pensa" o contrário.

Por que as métricas para definição dos prazos e dos custos de um projeto são feitas inicialmente por análises estimadas (APF - Ponto de Função), porém todos sabem que os projetos sofrem mudanças durante seu desenvolvimento, sejam elas no Modelo Lógico, no Projeto Detalhado (Análise) ou na Construção (Programação), estas mudanças acabam impactando nos prazos de todas as fases (Análise, Construção, Testes). Vemos também projetos sendo iniciados sem um maior preparo por parte dos gestores, não sabem o que querem, sem o conhecimento do que é possível ou viável, acabam por definir os requisitos do sistema de forma incompleta ou incorreta. Vemos empresas privadas participando de licitações do tipo “menor preço” para prestação de serviços para o Governo, algumas destas querem apenas formar portfólio, não conseguem obter lucro, pois não estudam o mercado previamente, não calculam os riscos e as margens de erro corretamente, imaginam que com grandes clientes a sua venda para multinacionais seria mais lucrativa. Enfim, sabemos que o trabalho realizado em TI é altamente especializado, e esse nível de qualificação não foi alcançado apenas através de cursos e diplomas, a experiência é fator primário para a execução de projetos com êxito.

Graduado em Economia e sempre atuando como programador e analista para Main Frame, conclui que os prazos estouram pela INCAPACIDADE de DEFINIR PRAZOS e pela extrema CA-PA-CI-DA-DE em agradar a êste ou àquele porque, bem,...... (autoexsplicativo). Qual é o prazo para se fazer um boa PAMONHA? Um bom pamonheiro poderia dizer: " Compro a semente, planto o milho e faço a pamonha. 2 palitos ". Tudo bem! Objetivíssimo! Como manda o figurino! Só que, por mais rápido que êle possa ser, existe nesse exemplo um tempo que, pela própria NATUREZA não pode ser alterado: SÃO OS 3 MESES NECESSÁRIOS PARA O MILHO CRESCER E FORMAR A ESPIGA. Voltemos a frase: "....planto o milho e faço...". Foi ESQUECIDA a etapa de COLHER o milho (e outras: transportar, debulhar,). Pelo que já observei, os prazos são definidos nesse esquema: Umas etapas são esquecidas, outras tem a sua natureza mudada, e assim vai. Mas como mudar isso tudo? Desculpem-me, não sei. Mas, penso que todos concordam ser isso uma consequencia da nossa vida muito corrida. E não podemos culpar a ninguém. Todos nós, tanto aqueles que nos impõem os prazos quanto nós que devemos cumprí-los, estamos SEMPRE COM PRESSA.

Estão esquecendo o básico, pessoas que nasceram com o Dom para a informática, não confundindo com aquelas que adoram brincarcom games no computador. A esperiência de décadas se perdeu num amontoado metodológico acadêmico, próprio para quem não tem experiência nem bom censo. Acima de tudo as pessoas tem de ter um excelente raciocínio lógico para ser um programador, mas para ser um analista de sistemas e um arquiteto de dados, tem de ter um excelente raciocínio abstrato ou analógico, conseguindo fazer correlações inimagináveis. E hoje tudo passa pelos RH, que antigamente faziam esses testes, mas hoje não, tudo é na base da aparência e da superficialidade, mesmo porque a maioria do pessoal de RH não entendem como pensam as pessoas super dotadas, acho mesmo que eles não as suportam. Então como G

Na minha visão, deve-se aumentar o esforço em métricas de estimativa de esforço e prazo. Muitas empresas definem tais esforços baseados em experiencias anteriores. Se 75% dos projetos de TI atrasam (segundo ITGI), é muito o provavel que as estimativas anteriores também falharam. Sendo assim, melhorar a estimativa de prazos e custos, baseando-se na realidade de cada projeto, pode aumentar esta acuidade de planejamento. Entretanto, um ponto importante é a percepção de valor que um projeto de TIC traz a uma organizaçao. Qual é o valor do ERP, CRM, segurança da informação, governança de TIC? Acredito que uma boa gestao do valor de TIC aos negocios, incluindo todo o ciclo de vida de investimentos, pode ajudar no ajuste da percepção de qualidade de um projeto de TI. Comumente, os fornecedores de tecnologia prometem o paraíso, e após o go live de um projeto, nota-se que o paraiso não é tão paradisíaco assim.. e ai vem as frutraçoes, os apelos a custos e prazos, etc. Na minha humilde opinião, nao compete só a area de TIC, mas a mesa diretora de uma organizaçao, definir qual o valor de TIC a seus negócios. Entendendo-se as expectativas, fica mais fácil gerenciar as eventuais frustações.

Posso relacionar alguns motivos: 1-) Falta de foco e comprometimento das equipes e profissionais responsaveis pelo desenvolvimento e do próprio usuário. 2-) Projetos sem escopo fechado ou escopo bem claro e definido. Os projetos não podem ter sucesso se o escopo é alterado durante o andamento do projeto. O planejamento e atingir a meta é item PRIMORDIAL; 3-) Terceirização dos serviços - os profissionais chegam no projeto sem ter participado de sua criação e são obrigados a "dar conta do recado". Depois de alguns meses, são desalocados... Qual o comprometimento e estímulo para este profissional ? 4-) Processos lentos e burocráticos. Apesar da documentação ser extremamente necessária, a mesma pode ser objetiva e suscinta, evitando atrasos em sua confecção. 5-) E por fim, os usuários sempre querem um prazo menor do que pode ser atendido. Isto resulta em um "atraso", que na verdade foi uma alteração da data de término do projeto, sempre antecipando a data da entrega.

Sou economista e atuo em projetos há 4anos. Ainda a maior dificuldade para o sucesso dos projetos nas empresas é a dificuldade de conciliar a gestão e a expectativa dos stakeholders.Vejo muitos funcionários em cargos de liderança da área operacional querendo dar uma "passadinha" pelo projeto para incrementar o cv e não buscam entender realmente o que é um projeto e qual a sua essencia, suas etapas. Sem o envolvimento dos funcionários não conseguimos progredir, mas o foco real destes gestores deveria ser: contratar profissionais capacitados,sem priorizar ao máximo o preço(diferente de custo) e orientar a sua equipe operacional para entender a necessidade do projeto,seus objetivos e situá-los nos momentos críticos.

Isso é simples, porque todo mundo esquece da margem de erro, nenhum projeto é perfeito.

Cada projeto é especifico com problemas especificos mas dá pra identificar alguns fatores de acordo com as experiëncias q tive. 1) ti é uma matéria exata com muita gente inexata na área.Em outras áreas de exatas as pessoas não são tão subjetivas como em ti. 2)gerencia e liderança indicadas por amizade e não por competência.3) As equipes não tem um arquiteto de software e adotam experiencias do ouvir falar e não algo prático e especifico do projeto. Fora esses fatores ainda tem aqueles projetos dentro do prazo mas péssimos para fazer manutenção e também aqueles q demoram tanto pra sair q a maioria das funções já estão obsoletas antes mesmo de serem usadas.

Porque dão mais importância a tecnologia que vão utilizar à real necessidade do cliente. Demoram mais tempo escolhendo ou implementando uma tecnologia da moda, ao invés de concentrar o esforço ao que o cliente quer. Já vi participei de muitos projetos que não foram pra frente por causa disso.

Endorso o comentário do Clodoaldo (11/05/09, 12:03:43: Clodoaldo - IP : 189.18.9**** ) acrescentando, de acordo com Ricardo Vargas, que o brasileiro é um emplementador nato, raramente planeja e que vai fazer, e quando faz, o faz de forma precária.

Entendo que o grande número de profissionais atuando na área de TI que demonstram despreparo técnico, intelectual e emocional, para exercer a função como gestores de informação. Isso porque a capacitada técnica e intelectual de um gestor de informação é um fator determinantemente para se obter uma visão ampla e bem definida sobre a sistematização de processos e por decorrência uma ótima base para se definir, de forma clara, uma estratégia assertiva de atuação.

Porque simplesmente, não me contrataram para fazer parte da equipe.

É o desejo pelo lucro fácil e investimento mínimo, fazendo das empresas de TI verdadeiras consultorias de RH. Onde, só se selecionam profissionais mediante questionários elementares, sem que se procure ao menos conhecê-lo. O grande serviço que a consultoria deveria fornecer seria a garantia de se ter boa mão de obra, mas no lugar disso ela oferece mão de obra barata. O que se vê também é o desprezo de profissionais chave na elaboração da concepção do projeto, como o de Analistas de Sistemas e Arquitetos. O que se faz é aproveitar o programador para tudo, tendo ele experiência ou não.

Outro conceito negligenciado é o de base de conhecimento. Erros comuns vivem sendo repetidos e nunca analisados para deixar de acontecer. Os vendedores realmente prometem muitas vezes o impossível, mas a área de tecnologia nada faz para se proteger. O fundamental, antes de tudo, é toda empresa de TI investir em metodologias e, antes de tudo, na manutenção de sua aplicação.

Pessoal, o resumo de tudo isto é o seguinte: * Em primeiro lugar... isto não tem nada haver com universidades e etc.. pois, muitos dos nossos colegas profissionais são "Autodidatas" e ao mesmo tempo, excelentes profissionais... o que é conhecido de muitos e deixando o orgulho de lado, sabemos que muitos, são excelentes profissionais e da mesma forma, como as pessoas que partem das universidades... isto é totalmente indidferente. * Em segundo lugar... o resumo de tudo isto é: Devido a muita concorrência de mercado (como ocorre para tudo e qualquer ramo atividade), começou-se a se tratar os "Serviços de Consultoria" (Que é o caso) como venda de "Peixes e Bananas" e devido a isto, o que resultou foi: A vontade de se pegar um cliente e não perdê-lo a qualquer custo por motivos de receita e consequentemente, aceitam-se tudo, prometem-se tudo e como para o tipo de serviço que é totalmente "Análitico", acaba-se não comportando o prazo dado (que torna-se totalmente inviável) e daí a questão que se encontra agora em debate. Ou seja, cliente quando se trata de consultoria, sendo a consultoria competente e responsável... jamais terá razão (o cliente), ora que, eles contratam serviços de profissionais para a realização daquilo que não sabem e precisam; Consultoria não é venda de produtos.

Eu vejo por duas situações que para mim são principais. Primeiro - a má formação dos universidades onde o analista que sai formado hoje nem sequer aprendeu a fazer uma analise de requisitos, gerando assim uma falta de entendimento entre o usuario e o analista e a contradição do que se aprende nas universidades e do que realmente é o mercado lá fora como por exemplo o fato de muitas das empresas não seguirem metodologias, vendem um prazo muito curto para o projero para não perder o cliente, aceita tudo o que o cliente quer alterando o escopo a todo o momento e assim tem muitos outros motivos

Eu vejo por duas situações que para mim são principais. Primeiro - a má formação dos universidades onde o analista que sai formado hoje nem sequer aprendeu a fazer uma analise de requisitos, gerando assim uma falta de entendimento entre o usuario e o analista e a contradição do que se aprende nas universidades e do que realmente é o mercado lá fora como por exemplo o fato de muitas das empresas não seguirem metodologias, vendem um prazo muito curto para o projero para não perder o cliente, aceita tudo o que o cliente quer alterando o escopo a todo o momento e assim tem muitos outros motivos

Será que tudo isso não teria alguma relação direta com a situação que o mundo está passando atualmente.

Amigos,

Tem muita gente nesta área. Vamos dar tempo ao tempo né? Ainda vivemos o "boom" da TI.

Logo, logo o mercado estabiliza e quem fica é aquele profissional que realmente não larga tecnologia por nada.

Assim como em outras profissões, a aptidão e a paixão pelo que se faz sempre prevalece.

Quanto as melhores práticas? Na minha opinão é uma tentativa desesperada de por o trem nos trilhos. Ajudam? Sim, claro. Mas não acho que tais metodologias, que são tão recentes, entendem a complexidade e as dificuldades de um projeto, principalmente por serem geridos por pessoas.

As melhores práticas ainda precisam ser refinadas, mas já é um começo.

Abs,

Infelizmente as pessoas não realizam o planejamento do projeto. È necessario receber a demanda e dedicar um tempo para o planejamento. A Teoria "FACA NO DENTE E PONTO DE FERVURA, NÃO FUNCIONA!", só leva o caos a equipe do projeto.

PROFISSIONAIS ALTAMENTE INCOMPENTES... COM GERENTES DE PROJETOS PERDIDOS E ALÉM DO MAIS MUDANÇA DE ESCOPO DIARIAMENTE

Devido as vendas mal feitas, que estimam os projetos em tempos impossíveis de acontecer...

É um cabo de força que graças a deus a TI sempre ganha, os prazos estouram obviamente de propósito, só assim o fornecedor tenta extrair mais dinheiro para o projeto, renovar e etc. Dêem graças a deus por isso por que assim seus empregos estão garantidos. Parem com essa bobagem de falta de capacidade

Existem inúmeros fatores, mas acredito que os mais impactantes são:

- má definição de escopo no início do projeto, e isso pode ser causado pelo skill reduzido do gerente de projeto ou comunicação ruim/com ruídos entre o solicitante e o gerente do projeto; - mudança do escopo durante o projeto.

Apesar de ser usado novas práticas metodológicas e técnicas na condução dos projetos, na grande maioria das vezes o que falta é um planejamento, este nunca bem feito pois normalmente temos a iniciativa de executarmos algo primeiro antes de planejarmos. Isto se deve pela vontade/Proatividade de entregarmos rápido os artefatos de projeto esquecendo ou automaticamente pulando a fase de planejamento onde deveríamos investir grande parte do tempo.

Tudo isso acontece porque as metodologias são burocráticas em excesso (as vezes um "cabidão de emprego" e sustentaculo de muitas escolas) não apresentando flexibilidade e estando distantes da realidade, os Gerentes de TI prometem prazos irreais por não ter pessoal e tecnologia suficientes por problemas de orçamento(as pessoas ficam sobrecarregadas de tarefas fora o projeto)e, no caso de Consultorias, elas querem atender mil Clientes de uma vez. Quanto aos usuários alguns preferem "jogar a bomba" em cima da TI e não querem assumir custos adicionais por mudanças do escopo original.

Com relação a esse problema eu vejo dois problemas principais:

1) Profissionais na área de negócio e analise incapazes de exercer bem suas atividades ou sem condições de orçar o valor devido por causa da concorrencia.

2) Alto nível de terceirização do mercado, onde as empresas, querem o "pastel" frito na hora sem pagar impostos e investir no capital humano.

Atuo nesta área a muito tempo e estou cansado da falta de respeito de gestores com relação a objetivos irreais que transmitem a seus subordinados. Os profissionais de TI em sua grande maioria trabalham como consultores (PJ), não tem nenhum benefício além do salário e ainda são "obrigados" a trabalhar aos finais de semana e feriados (alguns viram madrugadas) para satisfazer e enrriquecer seus contratantes. Eu acho que cabe a nós exigir respeito e impor nossos limites para que o mercado comece a nos respeitar com prazos e especificações descentes!!

Estourar prazo, custo, alteração no escopo, tudo isso é normal, faz parte do processo de criação de sistemas. É por isso que os projetos devem ser gerenciados. A industria é nova, muitos erros ainda serão cometidos e resolvidos. Algumas necessidades básicas precisam ser resolvidas como: A idéia de junior, pleno e sênior. Como pode alguém ter senioridade com menos de 35 anos? Como pode uma consultoria iniciar um projeto sem planejamento ? Como pode um projeto ter sucesso sem desenvolver uma equipe ? Como pode um profissional de TI trabalhando continuar procurando emprego, sem ao menos tentar melhorar a situação atual? Como pode vivermos com ferramentas de produção em fase Beta? Como pode um Gerente de Projetos ser certificado, falar inglês, ter MBA e não conhecer a área de atuação ao menos para se relacionacionar com o pessoal de desenvolvimento ? Como pode as consultorias continuar a trabalhar com especifidade desnecessária como analista de sistema financeiro, desenvolvedor dot net, CHEGA DISSO, quem é desenvolvedor, desenvolve em qualquer linguagem, quem é analista de sistema, analisa qualquer sistema.

abraços a todos amigos de ti que fazem acontecer.

Porque muitas pessoas sem conhecimento(gerentes,diretores,analistas) estão querendo ganhar em cima das que tem conhecimento(programador).

Todo programador sabe que é fácil ser gerente/diretor/analista, pois qualquer programador consegue fazer o serviço de um gerente, diretor e analista... mas o inverso não é verdadeiro.

Por que projetos na área de TI têm características distintas as quais não são levadas em consideração durante o seu gerenciamento. O caminho para o sucesso está em estudar casos de sucesso. A adoção de tecnologias e/ou metodologias novas ou velhas faz pouca, ou nenhuma, diferença ignorando-se tal problema.

Muito simples!!! Primeiro - Profissionais não qualificados. Segundo - Interesses pessoais. Terceiro - Esquemas internos (propinas,vantagens,...). Quarto - (no caso Brasil) falta de legislação para algumas profissões. Quinto - Falta de escrúpulos das pessoas.

Ou seja, isso nunca vai mudar! Estou no mercado de TI tem uns 12 anos e só vi isso nas empresas ( olha que são GRANDES empresas ), entra tecnologia nova, metodologia nova, arquiteturas novas, etc ...

Esse problema, na maioria das vezes é ocasionado pela falta de planejamento do projeto, recursos e alocação dos usuários envolvidos. A falta de comunicação, principalmente a forma que a mesma é difundida, também podem trazer grandes atrasos nos projetos. O escopo deve ser muito bem definido e incluído principalmente o que NÃO FAZ PARTE DO ESCOPO.

as empresas tem que dar mais oportunidade para quem esta ingressando na faculdade no primeiro semestre!!!!!!!!!!!!!!!

O motivo principal é que durante a execução do projeto o usuário sempre pede novas requisições e ao invés de estender o prazo mantém o tempo do mesmo. E também quando efetue novas funcionalidades a demora na funcionalidade do código.

Porque as metodologias e tecnologias tem que ser utilizadas a favor dos projetos e nao da forma como sao utilizadas. Todo projeto eh um empreendimento unico e esta premissa deve ser analiaada com seriedade antes de encarar ou forcar uma metodolgia padrao. Metodologia nao substitui experiencia, bom senso e motivacao para realizar o projeto.

Nas noites de frio é melhor nem nascer Nas de calor, se escolhe: é matar ou morrer E assim nos tornamos brasileiros Te chamam de ladrão, de bicha, maconheiro Transformam o país inteiro num puteiro Pois assim se ganha mais dinheiro

A tua piscina tá cheia de ratos Tuas idéias não correspondem aos fatos O tempo não pára

Eu vejo o futuro repetir o passado

Tenho 6 anos de experiência como Analista de Processos e Negócios, participei de projetos de implantação de sistemas, de implementação de novos sistemas e de customização de sistemas em produção. Minha percepção é de que existe uma distância muito grande entre as áreas de negócio e as de programação e infra-estrutura. As áreas de negócio tem uma percepção simplista da TI, sendo assim não aceitam prazos de implementação factíveis com o problema. As equipes de programação, por sua vez, desenvolvem soluções que não atendem ao negócio devido ao prazo insuficiente e, principalmente, devido a fata de definição de regras de negócio, informações necessárias, processos etc. Criaram-se os papéis de analistas de processo e de negócio, analistas de requisitos e gerentes de projetos. Percebo que os analistas normalmente são pessoas com pouco conhecimento dos processos de negócio e, consequentemente, não conseguem abordar corretamente os clientes, além de não conseguirem especificar a solução. Os gerentes de projeto, normalmente, não tem poder de negociação sobre o prazo e, na prática, fazem o papel de "cobrar" a execução de atividades em um prazo insuficiente. Acho que temos tecnologias suficientes para atingir altos níveis de informatização nas empresas, mas são necessárias metodologias que aproximem os desenvolvedores do "universo" dos negócios. Acredito que o papel de analista de negócios ou processos deve ser feito por desenvolvedores seniores e não simplesmente por pessoas que não tenham experiência em desenvolvimento. Acredito que a metodologia SCRUM direciona neste sentido: os próprios desenvolvedores planejam o trabalham, gerenciam o escopo, o prazo e, principalmente, defininem os requisitos junto às áreas de negócio. Estou correto?

abraços

Ewerton Silva

Este tema faz parte da área de estudo Engenharia de Software, existem estudos que comprovam que mais de 80% dos projetos de softwares fracassam por: Requisitos fracos, falta de apoio do patrocinador do projeto, casos de uso não levantados e as famosas agendas secretas de projetos, quer dizer issues que não foram tratados, pois os usuários chaves não informaram ou simplesmente esqueceram. HOje entendo que sistemas são criados para automatizar processos, porém percebo que as empresas e consultorias esquecem que existem humanos operando os sistemas. Analisando as caracteristicas humanos o que temos: medo, tristeza, alegria e raiva, quatro sentimentos basicos que podem ser trabalhados para auxiliar no envolvimento de todos os stakeholders dos projetos. Por último vale lembrar que corrigir erros na fase de planejamento custa 1x, na fase de prototipo 10x,na fase de execução 100x e na fase de produção 1000x, por isto muitos sistemas morrem muito antes de entrarem em produção.

As consultorias são caras, os prazos são fechados de acordo com investimentos (R$) e não com a capacidade normal de produção dos desenvolvedores. Proporcionalmente o custo com remuneração aos desenvolvedores é baixo, ao tempo que esgotam a capacidade produtiva dos mesmos ao máximo, ou tendo de fazer subcontratações (estilo PJ, repassando o risco aos desenvolvedores) para catalizar o projeto. Em resumo: existe uma relação conflituosa entre o que pode ser feito e o quanto pode se ganhar.

Essa é fácil de responder.

Por mais que as tecnologias e as metodologias evoluam, ainda assim elas são geridas por seres humanos. Não adianta nada somente a tecnologia evoluir se as pessoas não acompanham esta evolução evoluindo também.

Os projetos geralmente estouram o prazo por não ter alguém no controle de planejamento, pois quando se estipula prazos tem que visar bem na frente as falhas também, tem pessoas quando entram em um projetos ou coordena um,tem a visualização que por ter diversas tecnologias espalhadas tudo vai dar certo e não é bem assim, sabemos que tudo que é novo pode vir a dar errado.E quanto aos usuários,pela minha experiência acompanhada em alguns projetos,tive a visão que os projetos são feitos sem uma avaliação dos mesmos ou sem nenhuma opinião sendo que,são os usuários quem iram fazer uso.

Primeiro- estas tecnicas usadas para gerenciamento de projetos NÂO SÂO, DO PONTO DE VISTA MATEMÁTICO. FORMAIS e adequadas com respeito ao processo de desenvolvimento de software. Elas simplesmente são usadas para vender cursos e certificaçãoes.

Segundo- as equipes em geral, não sabem dentificar o problema a ser resolvido. Por exemplo,nos projetos em J2EE, os elementos das equipes ficam mais concentradas em achar um framework para resolver um problema que ainda nem sabem qual é.

Terceiro - a formção acadêmica das equipes. Cada vez mais é empregada metodologia do imediatismo para fazer projetos, a filosofia da tentiva e erro, da "orelhada" e assim por diante.

Quarto - Minha experiência com gerentes de projetos de software é que em geral(salvo algumas exceções) eles não tem a menor experiência do que seja desenvolver software abordam os problemas superficialmente, etc.

Minha experiencia Eu participei de um projeto enorme de um grande Banco. Nas reuniôes com gerente de projeto ele falava um monte de coisas e mostrava um monte de gráficos a respeito do andamento do cronograma(lógico com o uso destas técnicas de gerenciamento). Em resumo ele falava de uma data de finalização e eu disse a ele, que nem em dois anos daquela data prevista o projeto estaria pronto (não deu outra). Mas eu disse com base, primeiro o cliente nao tinha uma ideia precisa do que ele pretendia, uma especificação informal(mesmo documentada) ja desencadeia um monte de coisas erradas... Em resumo, dá para identicar uma série de pontos que interferem para um bom resultado de um projeto de software(em grande ou pequena escala) que estas pesudo técnicas de gerenciamento não captam.

A resposta está na pergunta: Falta um bom projeto e uma metodologia. Tendo esses dois bem alinhados e utilizados com maestria, o sucesso será quase inevitável (99%). O grande problema é que todo projeto é mal dimensionado e quando se vai utilizar uma metodologia, o profissional acha que entende muito do assunto (metodologia) e acaba cometendo erros infantis por ficar amarrado nela.

Sinceramente

OS Usuários e clientes precisam entender que desenvolver sistema demanda tempo e dinheiro. Quanto a estourar prazo quem nunca chegou atrasado no serviço que atire a primeira pedra e quanto a estourar orçamento, que atire a primeira pedra quem nunca levou um prejuizo. Paciencia do usuário..isso é a decorrencia de um minimo de prejuizo e atrasona entrega.

Acredito que a maioria dos projetos, não só de TI, mas de engenharia, infra-estrutura, etc., possuam atrasos e estouros no orçamento devido a um problema que acontece mesmo de seu início, no caso, na fase de comercialização dos mesmos.

Muitos projetos são mal dimensionados, ocorrendo problemas de estimativa, escopo não entendido claramente e detalhado com pouca profundidade, e muitas equipes são formadas com os profissionais que estão disponíveis, que nem sempre são os mais preparados para determinadas posições.

Amigos, Projetos tem vários segmentos, vários envolvidos. Podemos ter muitas situações que nos impessam de concluir no prazo estipulado, aliás muitas vezes pelo contratante, que geralmente não entende o processo ou tem urgência, mas não quer pagar pela mão de obra. Somos fadados a trabalhar em um prazo para ontem em um projeto que demandaria 20 pessoas e tem 10 trabalhando. Nesta hora temos que fazer como aconselha nosso amigo e agir como psicólogos, usar terapia reversa ou simplesmente negociar novos prazos se o cliente não estiver satisfeito. Afinal temos que trabalhar...

Porque muita gente acha que profissional te TI é MAGICO, ou ROBÔ que não dorme, não come, não vai ao banheiro..

Porque os projetos envolvem pessoas e pessoas tem dias bons e ruins, produtivos e improdutivos...umas acomodan-se e outras não. Para equalizar custo, os projetos envolvem pessoas sênior e outras nem tanto. Pessoas tendem a defender seus interesses pessoais, agem por pressão ou suas decisões são tomadas por interesse pessoal ou por falta de conhecimento.

Acho que nós coordenadores de projetos deveríamos ser formados também em psicologia e pedagogia...e fazer uso da psicologia infantil em determinadas horas...pra mim tem funcionado.

Este ano completei 46 anos de profissão (é isso mesmo), tenho 62 anos e iniciei minha carreira no Banco Novo Mundo em 1963 com 16 anos. Minha especialização é grande porte e desde 1975 trabalho com vsam , db2 , cobol e cics e acho que nisso reside o nosso sucesso passado Com apenas estas ferramentas , informatizamos o Brasil (os sistemas dos bancoe em atividade foram desenvolvidos de 1968 a 1975) e tinhamos tempo para conhecer o negócio O maior erro foi delegar ao usuário a tarefa de conduzir o projeto pois ele não entende de sistemas de informação e via de regra do negócio

Primeiro é importante ter o conceito de Sistema em mente. Segundo é questinar a qualidade e preparo do profissional(TI), desde aquele que aprova a solicitação, aquele que intermedia o negócio com o cliente(usuário) até aquele que programa. Os "cases" da vida vieram justamente para ajudar e ajustar todo o trabalho, eliminando falhas e esclarecendo as regras de negócio, customizando, criando tabelas, fazendo nosso trabalho entre outros, enfim fazendo aquilo que antigamente um "analista de verdade" fazia. No entanto era muito mais caro(cheguei a ganhar 57 salários mínimos) e não se tinha tanta preocupação. Parece-me que as tecnologias de desenvolvimento encobrem muito a deficiência e preparo do profissional de TI. Nossos clientes sempre teram diversas necessidades, cabe a nós sabermos interpretar e transformar esse sonho em realidade da melhor forma possível. Não estou dizendo que devemos voltar no tempo, mas sim que pessoas se esqueceram de aprender com o passado. O problema nunca sera das máquinas e nem dos fronts ou becks, mas sim de quem as/os desenvolvem. []s.

Porque nunca ninguém tá satisfeito. Qto mais se avança na tecnologia, mais o usuário exige.Vc nunca consegue satisfazer o cliente. O resultado é sistemas mais e mais complexos, 150 mil funções para um negócio que, se bem estruturado, necessita de apenas 1000, novos vírus a cada dia, redes incompatíveis com o sistema proposto, profissionais meia boca e usuários muitas vezes "burros". É o samba do criolo-doido.

Na maioria das vezes o projeto é mal gerenciado, o gerente se acha mais importante que a equipe e o cliente, sem contar que na maioria das vezes é odiado pela equipe.

Primeiramente falando no atraso da entrega e o fracasso dos projetos, temos empresas que pensam apenas em faturar as horas desenvolvendo sistemas para "funcionar" (podemos citar fábricas de software) e acabam esquecendo de pensar na qualidade final do produto, qualidade de código fonte(manutenabilidade).

Também não poderia deixar de citar empresas que não valorizam os desenvolvedores e analistas, contratando de forma ilícita e injusta, pagando merrecas o que causa grande rotatividade no decorrer dos projetos. Partindo deste ponto, posso dizer também que as empresas não conhecem os potenciais e limites de seus funcionários, o que influencia na demora ou na baixa qualidade das tarefas desenvolvidas.

Isso e obvio, a área de Ti no Brasil è um fracasso. Quer muito, pagando pouco. A Cultura do empresário brasileiro. Querem software livre para não pagar licença, mão de obra barata e projetos, hardware básico, software free. Ainda tem pessoa que trabalham por qualquer dinheirinho, paciência, salve-se que puder. por isso entou na faculdade novamente para corrigir essa bug.

meu caso é simples...! querem tudo pra ontem com custo tendendo a zero...

logo, faz-se tudo na correria, gerando retrabalho e aumento de tempo na entrega. e nisso o usuário fica p. da vida!

e é isso!

Construimos casas a milhares de anos, o desenvolvimento de sistemas tem pouco mais de meio seculo, ainda temos muito o que aprender ...

Uma planta, uma maquete, um engenheiro, um arquiteto e etc dão conta dos projetos de construção mais sofisticados.

Na área de informática isto ainda não esta bem estruturado, tem gente que quer que o mesmo profissional faça o papel do engenheiro, do arquiteto, do mestre de obras e do pedreiro. O resultado é o que todos nós já conhecemos.

Tive um professor na faculdade que dizia que o computador era o idiota mais rápido do mundo.

Mesmo para programas mais simples, temos que prever todas as possibilidades, exceções, falhas na segurança e programar uma ação para cada uma delas. O nível de detalhe é tão grande, que muitas vezes os próprios usuários, não possuem esta percepção pois muitas ações são tomadas de forma intuitiva e pelo bom senso.

Não conheço nenhuma metodologia viável, capaz de extrair todo este conhecimento dos usuários e colocar no papel, para ser utilizado pelo pessoal de TI.

Na pratica os projetos acabam indo pela tentativa e erro, o usuário tem uma idéia do que ele necessita, o pessoal de TI começa a desenvolver com base no que entendeu que seria a necessidade do usuário, os ajustes vão ocorrendo, o tempo vai passando e no final, entre mortos e feridos, o usuário acaba com uma coisa parecida com aquilo que ele estava necessitando ...

O computador precisa deixar de ser tão burro, as tecnologias de inteligência artificial deveriam evoluir, para que o computador resolvesse sozinho as coisas mais básicas e a programação tivesse como foco apenas as regras de negócio.

Anteriores:

92 - Networking é importante ? Como criar e manter ?

91 - Quem desenvolve software livre trabalha de graça para quem pode pagar ?

90 - A área de TI perdeu status nas empresas ?

89 - Qual tecnologia será destaque em 2009 ?

88 - O que pode queimar o filme de um profissional de TI ?

87 - Deixe sua mensagem otimista de final de ano.

86 - Como fazer um bom currículo para TI ?

85 - Que tipo de oportunidade a crise econômica pode trazer para o mercado de trabalho em TI ?

84 - Nova lei de estágio já em vigor

83 - Existem boas oportunidades de trabalho em TI, fora das grandes cidades ?

82 - Lei para regulamentação da área de TI, em votação no senado

81 - Comente o resultado da pesquisa Impostos e taxas em TI e a nova planilha de comparação de salários

80 - Qual área ou tecnologia sera destaque em 2008, no mercado de TI ?

79 - Deixe sua mensagem otimista de final de Ano.

78 - Nova lei do estágio em votação no Senado - prós e contras

77 - Vale a pena obter certificações no início da carreira ?

76 - Inglês fluente em vagas de TI, necessidade ou exagero ?

75 - Ainda existem boas possibilidades de trabalho em tecnologias antigas, como por exp: Cobol, Assembler, Novell, Dataflex, Clipper e etc ?

74 - Como ser bem sucedido na área de TI ?

73 - Proposta do governo : + 10% Impostos para PJ

72 - Por que os projetos de TI atrasam ?

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 ?