APinfo - Forum

Como definir prazos e custos de um projeto de TI ?

Sugerido por : Leopoldo/Marcos

concordo com o Carlos

fechando o post anterior......... mas, por outro lado, é esta dinâmica que faz com que o mercado de TI esteja sempre aquecido. A grande concorrência e oferta de profissionais às vezes é também o que justifica tal "queda de qualidade" na implantação dos projetos. Se por um lado, o cliente sempre quer pagar menos por mais, mudar escopo do meio do caminho, etc., por outro as consultorias não "se negam" a pegar um projeto porque o escopo não está devidamente formalizado e com suporte contratual. Os contratos de TI dizem apenas "fazer um sistema de BI", o cliente compra pelo menor preço, a consultoria afirma ser "altamente especializada" naquele assunto, manda sua equipe de estagiários para a XYZ informática fazer uns cursos de 40 horas (às vezes nem isso) e, pronto : está feito um sistema de BI "nota dez"....... e depois gasta-se o dobro do valor do projeto inicial para consertar o que foi feito ou fazer um novo a partir dos erros cometidos no primeiro projeto..... e assim caminha a humanidade.... para as consultorias é sempre um bom negócio, se a consultoria AAA faz um projeto e a consultoria BBB conserta, e vice-versa....

Para construir prédios e máquinas, além do conhecimento, é necessário matéria-prima e equipamentos que custam muito caro, o que impossibilita que pessoas com pouco capital, façam algum empreendimento para desenvolver atividade autônoma neste segmento. Sem falar no CREA, que é muito mais um obstáculo para empreendimentos, do que um órgão de utilidade pública ou de defesa de classe profissional.

Para construir software é necessário apenas conhecimento, e isso desencadeia uma série de fatores inerentes à atividade de desenvolvimento de software.

Todos querem competir num mercado onde existe muita demanda, e isso ao meu ver, não é um mal a ser combatido. A demanda está ficando cada vez mais exigente com relação à qualidade, e isso significa que o cliente quer saber como o fornecedor faz, não apenas o que ele faz.

O tema "Como definir tempo e custo" está intimamente ligado a como se faz software, e isso realmente é um tema "Ácido" quando tange a competitividade, ou seja, o cara fala que faz mais barato, mas não pode dizer como faz, não consegue explicar como fez e nem entender o que fez !!!...quanto menos poderá estimar quanto tempo vai gastar !!!

Completando o raciocínio do Sandro.Projetos.... Um dos problemas do mercado de TI é a dinâmica dos produtos e serviços oferecidos. Se nem o especialista consegue acompanhar os constantes lançamentos de novas tecnologias, quanto mais o cliente. Uma vez ouvi um especialista em segurança esclarecendo que a preocupação com segurança que temos em nossas casas, com trancas e cadeados, deve ser equivalente no uso de TI, internet, etc. A diferença é que eu, meu pai e meu avô sabemos o que é um cadeado. Agora assumir que o usuário final vai ter uma visão completa e atualizada sobre anti-virus, spam, trojan, spyware, backdoor, DoS, etc. é impraticável. Ainda na comparação com projetos de engenharia civil, a primeira coisa que vc faz ao comprar um apartamento na planta é ver ou visitar outros empreendimentos da construtora. Em TI, principalmente software, é inviável uma empresa querer mostrar a um prospect os projetos "iguais" ao que ele está pedindo, porque nenhum projeto é igual a outro, primeiro porque cada necessidade costume ser específica e, o principal, todo projeto de TI em geral busca utilizar tecnologias de ponta, as vezes até beta. Quem trabalha com Microsoft sabe disso, quem já implantou alguma coisa com .NET, se for vender um novo projeto já tem que repensar muita coisa devido aos lançamentos das ferramentas do VS 2005. Quem teve trabalho para implantar redes Win 2000 estáveis, em um segundo projeto já teve novos problemas em função da mudança para Win 2003, e quem está instalando suas redes com Win 2003 daqui a pouco tb já vai ter que mudar tudo de novo. []'s

continuando o post.... quase como contruir o prédio de novo.Refoçar fundação, rasgar parede, colocar mais pilares, mais vigas, etc,etc., ai fala o preço e o prazo disso, para o cliente, e vamos ver se ele quer realmente..rs, agora depois disso tudo fassam um analogia com os projetos de Software. e v's vão ver o que esta errado e qual o motivo da simples problematia de estimar o prazo e cumprir, olha que na engenharia não tem PMBOK, APF, etodas essas tecnias mirabulantes etc. OS MOTIVOS: 1-EM QUANTO O CLIENTE (DONO), NÃO SABER O QUE QUER, OU MUDAR NO MEIO DO CAMINHO O QUE ELE QUERIA. 2-EM QUANTO OS ENGENHEIROS/ARQUITETOS(PROJETISTAS DE SOFTWARE), INCLUSIVE EMPRESAS DE SOFTWARE, PERMITIREM AS MUDANÇAS NO MEIO DO CAMINHO A PEDIDO DO CLIENTE, USUARIOS, ACIONISTAS ETC.., "A É SO UMA MUDANCINHA NINQUEM VAI MORRER E O PREDIO/SOFTWARE NÃO VAI CAIR.

essas não maximas, dentro disso existem outras variantes mas essas podem ser contornadas ou estimadas, (velocidade dde codificação, mudanças de programadores,maquinas, cinistros, etc.)

em quanto acharem que software é joginho, e brincadeira pra ficar escreve,apaga. isso vai continuar.

mais ai o problema é mais profundo, engenheiro civil,arquiteto tem CREA e Analista de sistemas?, Arquiteto de software?, é regulamentado?, e tem força pra chegar pro cliente(dono) e falar, não pode mudar o projeto, no meio!.

continuando do post abaixo... num projeto de engenharia civel, um proprietario ou construtora, quer contruir um prédio em um lugar, com um padrão espeifico para atender um certo nivel de clientes(pessoas), depois passam para o arquiteto desenhar o prédio, formas, cores, estilo, design, altura(andares), etc, etc. depois chega o desenho para o engenheiro, esse é incumbido de projetar fisicamente o prédio, definindo os calculos estruturais, ferro, bitola, espesuras de pilares, vigas, calculos de carga, tudo para que o desenho artistico do arquiteto será concretizado na pratica e não caia, seje solido, fazem maquetes, ensaios etc., depois de tudo isso, nessa fase o cliente já aprovou o desenho (só o desenho), quem decide as tecnicas de contrução é o engenheio, não cliente, ai a contrução começa, mestres de obras, pedreiros, eletricistas, todos com as plantas na mão seguindo a risca, andar, por andar, vai subindo o prédio, agora vamos supor no meio do prédio o cliente chega e fala, "pocha eu queria 9 andares no começo, mais pensando melhor quero 15 andares, eu to pagando e quero!", o que vc's acham que a equipe (engenheios, arquitetos, projetistas), falam...primeiramente vam rir.., depois "IMPOSSIVEL", sabe por que, fundação, estacas, bitolas de ferro, espessuras de vigas, tudo foi projetado para uma certa carga, e não tem como colocar mais pesso em cima, vai comprometer tudo.A alguem pode falar "da sim", sim da mais é ...

Bom, dei uma olhada nesse forum e lida superficial, estou a 15 anos nessa dura areá, e sempre vi esta questão estar em evidênia, muitas tecnicas, ideias acadêmias, gurus(se acham deuses e donos da solução perfeita), filosofias, etc..etc, e no final nenhuma solução perfeita, que atenda 100% dos casos, os projetos de software continuam se atrasando e com estimativas não preissas.Sabem por que isso dificilmente ira ocorrer, e é quase impossivel.sabem por que. primeiramente um pouco de fisica, já ouviram falar que principio da incerteza, mecanica quantica. analogias:

É Dirceu,

As fases de ajustes por conta de uma eventual mudança de regra de negócio é sempre um risco a ser considerado e é por isso que existe uma estimativa que poucos fazem porque é chato mas serve justamente para que não levemos sustos: Análise de Risco do Projeto. Porque poucos fazem? Porque para termos uma visão bem realista é necessário combiná-la com outras técnicas como Ponto de função, Grafo de atividades...

Pessoal, por mais que utilizemos as técnicas existentes para mensuração de prazos e custos, sempre teremos de realizar os ajustes na fase de desenvolvimento. Como o nome já diz, se trata de uma estimativa que tem uma probalidade de acerto. O fato e que lidamos com pessoas e isto é suficiente para não confiarmos na estimativa. A única forma é criarmos mecanismos para corrigir desvios que certamente ocorrerão.

Pelo que percebi a discussão aqui foi beeemmmm longe, pra uma pergunta simples.

Existem meios para se fazer a medição e avaliação dos projetos de TI, como qualquer outro projeto: PF (pontos de função) para a métrica, PMI para o gerenciamento, MER e UML para o desenho da solução.

Qual o problema?

Há, a programação é uma arte na esfera da criatividade e não pode ser medida nem controlada?

Engano, a programação é apenas o que o tijolo é para a construção, matéria prima, nada mais. A arte e a criatividade são do arquiteto e não do pedreiro.

Quer ser criativo? Invente um produto e saia vendendo, mas não diga que o produto do seu talento não pode ter o preço avaliado, porque não é verdade.

Utilizem as boas práticas do PMI!

Uma das principais falhas sobre o "não-cumprimento" das coisas, seja custos ou escopo, são as tão faladas "lições aprendidas". Dá para contar nos dedos os projetos que, depois de finalizados, são analisados onde acertaram e onde erraram, onde a metodologia utilizada foi bem-sucedida ou não, permitindo a melhoria contínua na tal "maturidade" do processo de desenvolvimento de software. Os clientes e as consultorias ficam "alucinados" porque o budget com o projeto já estourou e mal dá tempo para fazer a GMUD do projeto. Normalmente no dia seguinte que o projeto entra em produção, já acontece a realocação de todo mundo que estava no projeto.

Desculpe pessoal com o mundo globalizado e com o numero cada vez maior de framework, fica dificil imaginar que se consiga implementar qualquer que seja o projeto sem que este passe por seja muito bem definido, tanto tecnicamente quanto no seu custo, penso que existem diversas formas para fechar este dados, a gestão da empresa e quem tem que determinar tudo isto deve se apresentar, mas certamente os custos devem ser apresentados em todas as fases do projeto bem como seu retorno do investimento por fase, com isto se pode determinar se projeto continua ou precisa de uma revisão.

Emendando no comentário do Mauricio....... o problema é que alguém tem que pagar a conta do projeto de TI e do salário do jogador de futebol.... pagar 1 milhão por um projeto é muito ou pouco ? pagar 200 mil por mês para o cara jogar futebol é muito pouco ?...... no futebol ainda temos o atenuante que normalmente um jogador caro pode trazer rentabilidade para o clube através de marketing........ em TI muitos projetos de 1 milhão acabam gastando vários milhões com retrabalho...... e como falar para o CIO da empresa que vale a pena gastar o tal do milhão em um projeto ? só pelo "amor" à tecnologia ?

TI nao e uma ciencia exata (pode pertencer a area de extas mas.........)

Há uma diferença entre cálculo e estimativa. Vejamos:

Calcula-se a velocidade média de um automóvel, medindo o tempo e a distância percorrida.

Estima-se que o ídice de analfabetismo no Brasil está diminuindo, em função do aumento dos programas de alfabetização nas áreas em que identificou-se maiores níveis de analfebetismo.

Tempo e distância, são variáveis que pode-se medir com precisão. Mas, índice de analfabetismo ? aumento dos programas de alfabetização ? áreas com maiores níveis ?....são variáveis pouco precisas.

No universo de TI, creio que seja possível estimar com certa precisão, quanto tempo gasta para desenvolver um sistema de controle de estoques em COBOL. Assim fica fácil aplicar APF, existe experiência de mais de 50 anos com a tecnologia mencionada e com o negócio a ser informatizado.

Agora, como alguém pode ser capaz de estimar quanto tempo gasta para desenvolver um sistema em Java, de apoio a decisão (Business Inteligence) baseado em conceitos de Datawarehouse ? Sim, obviamente esta estimativa pode ser chamada de chute, mas para começar o jogo, alguém tem que dar o primeiro chute, e durante a partida a gente vai vendo o que acontece, ora bolas, vai querer exatificar o futebol ?

Pessoal, impossível que com todas estas boas explicações apresentadas, todos tenham esquecido das Leis de Murphy. Lembrem, a melhor técnica é aquela que realmente funciona para você, mesmo que ninguém acredite que funcionou como você disse.

Para relaxar um pouco, 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

Caro Carlos,

O fato uma metodologia ser um processo com passos bem definidos, utilizando critérios não subjetivos, não o torna uma metodologia exata e de eficácia cientificamente comprovada, como eu acho que era a idéia que o Maurício levantou. O resultado de APF ainda continua sendo um chute, mas como eu disse, os vários anos de amadurecimento da metodologia a fazem funcionar para muitos casos, o que não significa que não devemos procurar formas melhores de medir e estimar custos e prazos de um projeto.

Boa tarde a todos. Respondendo ao enunciado desta pesquisa, segue minha sugestão. (pesquisem, estudem e adotem a métrica USE CASE POINT)

Visto que hoje em dia, sería ideal que os novos projetos de software, fossem desenvolvidos usando-se uma linguagem de programação Orientada a Objetos e um método de Análise e Design também Orientado a Objetos, como temos na Análise e Design ESTURTURADA a métrica estabelecida por APF - Análise por Ponto de Função, nos projetos ORIENTADOS A OBJETO (JAVA,.NET, C++, etc) sugiro que usemos USE CASE POINT, que é a evolução ou adaptação da métrica estruturada APF para o universo dos projetos de software Orientados a Objeto.

Minhas saudações a todos sos profissionais que aqui postam suas opiniões Evandro - Professor e Analista de Sistemas Sr.

A medição é importante em um projeto de desenvolvimento de Software a fim de gerenciá-lo de forma mais objetiva.

“Não se pode gerenciar o que não se pode medir.” – Tom De Marco

“ Métricas de software envolvem um amplo campo de medições que podem ser utilizadas tanto no início do projeto quanto durante o processo de construção do sistema.” – Roger S. Pressman

att,

Luciana Analista Programadora

Normalmente só vemos a crítica destrutiva, aquilo não presta, aquilo não funciona, etc.... No caso da APF é um pouco leviano dizer que ela não é exata, porque é um tipo de análise semelhante a contar quantas tabelas tem um banco de dados ou quantos objetos existem em um diagrama de classes. Os critérios de contagem e complexidade dos arquivos e itens de dados são bem definidos bem como as fórmulas de ajuste e as "14 características gerais dos sistemas". Metodologia é isso, cada um defende a de sua preferência. Ou ainda podemos preferir o caos, trabalhando como apagadores de incêndio, às vezes isso é até mais rentável porque o cliente fica mais desesperado. E na prática é isso que todos procuram, a opção mais rentável......

Caro Darkstar,

APF (Análise por Pontos de Função) nada mais é do que um CHUTE feito de forma mais metódica. E ajustado devido aos vários anos de experiência que as pessoas tem tido com isto. Agora prove que isto funciona de fato. Você pode citar projetos em que a metodologia deu certo, mas isso não tem nada de matemático. Além do mais, existem muitos projetos em que a metodologia pode não ter dado certo (obviamente isto não é uma informação que as empresas disponibilizam publicamente).

"Definir prazos e custos, como dito aqui anteriormente, depende muito mais de fatores subjetivos do que técnicos.

O grande desafio desta década, ao meu ver, é justamente conseguir identificar e tratar matematicamente, os fatores subjetivos dos projetos de TI."

Para isso serve APF...

(continuando o post abaixo)

De tanto mandar e pagar, mandar e pagar, mandar e pagar, o cliente começou a perceber que esta "brincadeira" acaba ficando cara.

O mercado é assim: REAGE SEMPRE, mas há quem prefira agir antes da reação.

A busca de metodologia para projeto, construção e gereciamento de projetos, é uma reação do mercado para não pagar mais caro por soluções de TI.

Por outro lado, a adoção de metodologias, é uma ação dos profissionais e empresas que produzem TI, para oferecer serviços adequados às espectativas do mercado.

Definir prazos e custos, como dito aqui anteriormente, depende muito mais de fatores subjetivos do que técnicos.

O grande desafio desta década, ao meu ver, é justamente conseguir identificar e tratar matematicamente, os fatores subjetivos dos projetos de TI.

Creio que seja bem mais fácil estimar prazo e custo, para construir um prédio, ou uma máquina industrial.

Neste tipo de obra de engenharia tradicional, é fácil enxergar a abrangência, e existe uma grande experiência acumulada há cerca de 100 anos, para definir a profundidade e seus detalhes, antes de partir para a construção.

Numa obra de engenharia convencional, seja um prédio ou uma máquina, quem gerencia deve dispor dos seguintes dados:

- o que precisa ser feito (o projeto, desenhos, esquemas elétricos, hidráulicos, etc.)

- as etapas do processo de construção, o que depende e o que pode correr em paraleo

- quanto tempo gasta para certas atividades do processo

- os recursos humanos (quem faz o quê, conhecimento necessário, quanto custa)

- quanto vai ser gasto de matéria-prima

O mundo está cobrando de nós, profissionais de TI, que consigamos construir soluções de TI, da mesma forma que o pessoal constrói prédios e máquinas industriais.

Oras...só se consegue construir prédios e máquinas, com o suporte de TI, e isso significa que também conhecemos a ciência da engenharia e da gestão de recursos.

A dificuldade que existe para definir prazos e custos, não parte apenas do nosso universo de TI, mas sim da incapacidade do cliente de saber o que precisa, de empenhar tempo e recurso para analisar um projeto e dizer se é isso mesmo que ele necessita, antes de iniciar-se a construção.

Geralmente o cliente se posiciona, dizendo indiretamente que seu tempo e recusrso são "preciosos" demais para gastar com "nerds". Até "ontem", o cliente agia assim: deixa o "nerd" fazer, daí a gente consegue analisar, se precisar, a gente manda ele refazer.

Tendencias e modismos sao lindos, porem um dia isso acaba, os clientes ficam espertos, prova disso e que o analista de suorte windows nao e mais o mesmo... A melhor tendencia e a responsabilidade e honestidade com o cliente, agir assim alem de enobrecer favorece seu lado no mercado

Estudem as novas tendencias que estão chegando como: Variancia Quantica; Estimativa Direta e Indireta; e Análise cliente-projeto e tb estude as ferramentas de 5 geração que estão chegando. Com tudo isso terá lucro certo e clientes satisfeitos.

Srs, parem de reclamar e vao aos estudos! Estudem o PMBoK e como definerem projetos e seus metodos de estimativas (Preco Fixo, Preco Variavel com adicional de performance, etc). Leiam e pesquisem Eliyahu M. Goldratt e suas teorias de corrente critica e estimativas. Vao ter muito tempo se divertindo a apredendo a definir projetos. Claro, isso nao te da garantia que os clientes irao aprovar! Em meus ultimos projetos (ultimos anos) nao tive nenhum prejuizo financeiro. Alguns a margem foi reduzida mas nunca prejuizo. Em relacao ao tempo, tive problemas, quase todos relacionados a atividades onde o cliente era o responsavel e o mesmo nao tinha disponibilidade, gerando atraso e consequente multa para o mesmo, conforme contrato.

Concordo com as pessoas que argumentam que a definição de prazos/custos é muito mais politica/comercial do que tecnica. As ferramentas ajudam, mas não permitem chegar a uma solução final.

Temos que deixar de ser otimistas no momento de definir os prazos, sempre existe um ou mais usuários que vão estar contra o projeto e vão atrasar a entrega de informações. Existem sempre as mudanças no meio do caminho e a alteração do escopo (não existe ferramenta que possa evitar isto). Em todo o projeto, em algum momento vai haver um problema de hardware ou alguma incompatibilidade de software. A aquisição de recursos, como por exemplo : contratação de pessoas, disponibilização de hardware, software, definição dos usuários participantes do projeto, aprovação da proposta e etc, estara sempre sujeita a atrasos, influenciada principalmente por fatores politicos.

Quando definirmos os prazos, temos que levar tudo isto em consideração, no inicio vão achar os prazos muitos longos, mas quando os resultados aparecerem e os projetos forem entregues dentro do prazo e com as funcionalidades devidas, vai haver a recompensa.

Pois é, o tempo passa mas a gente continua fazendo a mesma coisa de cinquenta anos atrás: Tranformando idéias em realidades, proporcionando as condições para que se exerça o melhor do pensamento organizado neste velho o bom, mundo caótico.

De certa forma são estas siglas, tendências, modismos, upgrades, que fazem com que a área de TI seja um mercado extremamente aquecido, sempre recebendo novos profissionais e constantemente fazendo e refazendo as soluções.... abraços....

quem precisa cumprir prazos, se no final a area de TI tem que mudar todos processos para atender a exigencias de custo? Vejo tantas siglas ( PMbook, PM, XP? e no final o que isso agrega para o cliente?

Sinceramente e complicado, meu caso e bem peculiar a area de TI no bradsil, fui convidado a participar de um projeto em uma empresa que promete trabalhos em curto periodo (muito famosa) mas para isso, as pessoas trabalham 16 horas por dia inclusive fins de semana, usam o tal ponto de funçao , e metodologias, mas 16 horas por dia todo dia e sem fim de semana e complicado!!

Pessoal, aqui na empresa é utilizado Ponto de Função como forma que definir prazo e custo. Não vou dizer que é tudo mil maravilhas e que a APF funciona 100%, as vezes temos que "tropicalizar" algumas contagem. Mas posso dizer que "a coisa" funciona, os prazos calculados costumam "bater" com a realidade e por sua vez o custo tb.

Falamos muito em projetos, PMBOK, prazos, preços etc... Será que estas ferramentas realmente nos ajudarão? A nova onda "UML", acredito, ajudará muito a nós profissionais da era digital. Em 90 era a "Qualidade Total", "Defeito Zero", "Reengenharia" e outros modismos... Em 2000 surgiu o Project (by Microsoft) e hoje todos viramos especialistas em projetos... Já pararam para avaliar o potencial do UML tanto para a área de tecnologia da informação quanto para outras áreas? (Administração, Qualidade, RH, etc) Os clientes, tendo esta idéia, sabendo como UML funciona, com certeza saberá pedir e NÓS, da tecnologia, o que realmente necessitam. O que é um projeto senão um conjunto de estudos onde temos atores, entidades e classes interligando-se para um objetivo comum?

Muitas vezes um projeto acaba saindo caro ou se torna um elefante que o cliente não sabe oque fazer com o mesmo, por um fato bem simples, muitos analistas de TI se julgam muito bons e esquecem que quem realmente conhece o cliente é a equipe da operação ou seja o Field Services de telefonia ou microinformática, são eles que estão dia a dia no cliente e que na verdade por melhor que fique a documentação do projeto, quem vai executá-lo é o Field, então precisamos envolver toda a equipe e fazer que todos saibam da importancia do projeto e acima de tudo a importancia do cliente, após esta atitude realizar reuniões com cheklist e chekpoint para sabermos como esta o andamento do projeto.

1. Como conciliar o projeto e desenvolvimento criativo e iterativo com os objetivos (prazo / custo / regras de negócio) dos clientes ?

Dá a impressão que criatividade e interatividade são inimigos da objetividade. Mentalidade Henry Ford.

Quando não há isso no desenvolvimento de um projeto, o produto sai mal feito, há muito retrabalho até que se consiga o resultado adequado, que pederia ser obtido simplesmente deixando a criatividade fluir, com interatividade coletiva.

2. Porque tantos projetos simplesmente ficam mais tempo em projeto/desenvolvimento do que em produção ?

Porque fomos durante algum tempo, péssimos desenvolvedores de soluções adequadas, batendo cabeça, demorando muito além da conta, o cliente se cansa, aceita o Ford Bigode Preto só pra não perder o investimento, utiliza o troço ruim pelo tempo que aguenta, jogo o troço no lixo, e parte pra outra tentativa, já calejado obviamente.

3. Realmente todos os investimentos em projetos de tecnologia são para agregar valor à empresa ou, são as vezes só para "utlizar tecnologia de ponta" ?

Não como uma nova tecnologia ser implementada sem que haja o pioneirismo. Alguém tem que experimentar, alguns que saem na vanguarda se dão bem, outros derrapam na curva, e pode ser ultrapassado por quem vem na tradição, mas para sair na vangurda é importante estar ciente disso.

4. Implantação de sistema as vezes não parece mandato político ? Chega um diretor novo, joga o sistema velho fora e faz tudo de novo ?

Sim, as vezes isso ocorre porque o antigo diretor vitimou ou foi vítima dequele Ford Bigode.

Acho que algumas questões do tema são:

1. Como conciliar o projeto e desenvolvimento criativo e iterativo com os objetivos (prazo / custo / regras de negócio) dos clientes ? 2. Porque tantos projetos simplesmente ficam mais tempo em projeto/desenvolvimento do que em produção ? 3. Realmente todos os investimentos em projetos de tecnologia são para agregar valor à empresa ou, são as vezes só para "utlizar tecnologia de ponta" ? 4. Implantação de sistema as vezes não parece mandato político ? Chega um diretor novo, joga o sistema velho fora e faz tudo de novo ?

Obs: não vamos desviar do tema para ficar no clássico muro de lamentações da área de TI, das consultorias exploradoras, dos gerentes ignorantes, dos usuários imbecis, etc.

Um abraço...

Pessoal, me senti muito bem ao ler os comentários de vocês. Elogio muito, pois me sentia isolado nas minhas idéias, visto pela forma como o mercado tem caminhado ultimamente. No geral expressam o que eu sempre achei: muitas coisas no desenvolvimento de software são subjetivas, e não existe maneira de dar um prazo numericamente exato a algo subjetivo. Basta ver como os software em ultimas instância se classificam LEGALMENTE: da mesma forma que obras de arte, como quadros, livros, etc. E tem gente que acha que faz fábrica disso ... linha de produção, hehehe. Abs.

Não sei não, mas acho que para estimar tempo e custo para um projeto de TI, deveríamos ver como fez Spielberg ou Jabor, nos seus projetos artísticos, vender como eles vendem, produzir como eles produziram.

Tem gente elocubrando teorias para desenvolver software, baseadas no pensamento Henry Ford !!!

Realmente Dorayaki, XP é a única coisa nova e viável que tenho visto nos últimos tempos, em termos de melhorar nossa capacidade de desenvolver software.

Acho que esse negócio de fábrica de software é uma tolice, que inventaram para azarar o pessoal que desenvolve software, e para as empresas que querem parecer grandes, impressionar o mercado, como quem dizem: "Nós desenvolvemos software com mentalidade industrial e os temerosos, caros e intoleráveis programadores, aqui são piões que obedecem e fazem o serviço".

XP baseia-se em comunicação, está mais para tranformar o processo artesanal de desenvolvimento de software, em arte dinâmica, não em processo industrial. XP se processsa como num laboratório de teatro e represetações, do que numa fábrica de processo planejado anteriormente.

Gente, não dá para industrializar o processo de desenvolvimento de software, isso é um engano.

Fazer software é um processo artesanal, abstrair num modelo lógico aquilo que ocorre no mundo real, é uma atividade extremamente criativa, deve ser feito em conjunto, as pessoas têm que adquirir e aperfeiçoar habilidades comunicativas, de expressar verbalmente, na escrita e com desenhos, o pensamento.

Esta é a essência da metodologia: COMUNICAR O PENSAMENTO, de forma rápida e objetiva.

Fábrica é a antítese desta essência. Teatro é a representação mais próxima ao que precisamos praticar em desenvolviento de software. XP, para mim, diz isso.

Acho que métodos ágeis como XP são muito úteis para realizar estimativas de projetos, pois as tarefas do projeto são divididas de forma a ficarem bem granularizadas e permitirem às pessoas que vão realizar o projeto fazer estimativas realistas. Além disso, no jogo do planejamento, o cliente define as prioridades dessas tarefas, nesse nível de granularidade. Talvez o único problema deste enfoque é a necessidade de um modelo de contrato diferente do que estão acostumados os clientes de TI.

O tema é como definir tempo e prazo ? Ah tá, pois é, numa fábrica de verdade, com mentalidade industrial, existe um profissional chamado "Técnico em Métodos e Processos".

Esse profissional geralmente tem formação em Engenharia de Produção, e tem o estudo com enfoque no processo de fabricação, não no produto.

Quando o técnico em processo entra em ação, o produto já está definido, tem o desenho de todo o conjunto, e de cada peça a ser fabricada, com todas as informações necessárias (dimensões, tipo de material, tolerâncias, grau de acabamento, etc), segundo as normas ISO, existentes a mais de 50 anos !!!

Quando numa fábrica pequena mas decente, é o chefe ou o próprio dono quem faz a análise do processo, pensa previamente no que vai ser feito e define o processo, tempos e métodos.

Ah sim, mas tem a fabriqueta que trabalha no ritmo artesanato, ou se tiver sob pressão, no ritmo do "Crioulo-Doido" onde ninguém pensa no processo, fabrica-se cada um do seu jeito, todo mundo correndo, sob pressão, extressado e obrigado a fazer hora extra.

Lamentável, mas esse modelo de fábrica, extingui-se com a abertura de mercado, a indústria brasileira, seja grande ou pequena, trabalha decentemente, respeita o operário, é respeitada mundialmente.

É com eles, que temos que aprender. Lamentável, mas esse monte de siglas, não passam de gíria que "malandrões" de gravatinha querem se dizer sabichões em processo, mas nunca nem viram uma fábrica, nem de vassoura, e querem se postular de doutores em processo...me faz rir.

Pois é, agora virou "moda" esse negócio de "Fábrica de Software", e o pessoal enche a boca para falar isso, como se tivesse um processo industrial para desenvolvimento de software.

O que eu já vi até hoje, o que chamam de fábrica, foi um monte de gente trabalhando amontoada em bancadas, com equipamentos subdimensionados, sem no mínimo ter um modelo de dados para saber de onde vêm e para onde vão os dados processados, componentes diferentes em ambientes de cada desenvolvedor, desenvolvedores que não se comunicam, coordenadores que não fazem o papel de disseminar conhecimento, gerentes que não conseguem aplicar as tais melhores práticas que todos nós sabemos de trás pra frente e de ponta cabeça.

Mas não, preferem chamar de fábrica, mais para rotular o profissional que trabalha com a mão na massa, de "Pião". Pião tem que obedecer, tem que cumprir horário, tem que fazer hora-extra quando o chefe precisa, tem que "dar" a informação que tem ao chefe, preencher ficha em agência de emprego, trabalha em bancada não em mesa.

continuando..... especificamente sobre prazos e custos, fica mais fácil quando imaginamos um cenário onde estamos numa fábrica de software, já com recursos alocáveis, etc. Desta forma até os prazos saem com mais facilidade devido ao provável reaproveitamento de soluções. O problema é que normalmente estamos no cenário "correria": 1.cliente solta RFP com prazo apertado 2.consultoria grande monta proposta com prazo/custo já negociado com cliente 3.consultoria pequena sai contratando os PJs pela APINF0 para projeto de dois meses 4.profissionais pegam o anúncio e começam a trabalhar "amanhã"

o Tal PMBOK foi inventado pra que ????

Querem que eu desenhe ???

continuando.... em projetos de sistemas, temos até algumas boas práticas e metologias, mas eu ainda tenho dúvidas que normalmente dão trabalho:

1 - Como uma boa consultoria tem condições de fazer uma proposta de sistemas (com prazo e custo) para um cliente, sendo que em geral o tempo de análise é curto e as RFPs normalmente não dão toda informação necessária ? Lembrando que este trabalho de proposta pode ser perdido porque vc ainda está tentando ganhar o cliente.

2 - Como fazer a famosa "definição de escopo" que estabelece o que será feito (com prazo e custo) sendo que as metodologias defendem muito o uso do desenvolvimento "iterativo" com constantes revisões de requisitos ?

3 - Que nível de conhecimento técnico o cliente deve ter para validação e homologação de um projeto de software ? É normal falarmos de terceirização, outsourcing, trabalho especialista, etc., mas se o cliente não tiver o conhecimento como ele vai saber o que está comprando ?

4 - Ainda sobre o cliente, se este não tiver a capacitação necessária, dificulta até a compreensão dos prazos/custos do projeto, já que desenvolver software com metodologia normalmente não é tão simples nem tão barato.

continuando...... o comentário anterior é politicamente incorreto, mas é real. Ninguém quer estabilizar um ambiente de SO existente, todos querem instalar a versão nova do SO. Vai ser caro ? Demorado ? Não tem problema, o jogo é dizer para o cliente que o fabricante vai descontinuar o suporte, o que normalmente até é verdade.

O que existe de diferente em projetar um ambiente/sistema de TI em relação a projetos mais "convencionais" como construir um prédio ou fabricar um automóvel é a maturidade do processo "produtivo". Por mais que se venda o uso de "metodologias", em geral a própria metodologia é imatura (quem ainda não ouviu que o SOA é a forma mais moderna de projetar sistemas), quanto mais a tecnologia a ser utilizada. Em TI é normal o investimento no projeto em função da própria TI e não pelo objetivo de negócio. Por exemplo, eu (como técnico) não vou desenvolver o projeto do meu cliente no .NET 2003. Eu vou desenvolver no .NET 2005 (mesmo que beta) porque eu quero me desenvolver na nova plataforma. Insegurança para dar prazo e confiabilidade em uma tecnologia recém-lançada ou beta ? Não importa, sinceramente estou preocupado primeiramente em me desenvolver tecnicamente e, se possível, ajudar meu cliente com seus objetivos de negócio.

Trabalho em TI a mais de 20 anos, o problema de definir custos e prazos é muito mais político/cultural do que técnico. Metodologias, ponto de função, prototipação e etc, existem a muito tempo e dificilmente são aplicadas da forma como deveriam. Na pratica, 90 % dos projetos atrasam, ficam acima do custo previsto ou os dois. Os 10 % restantes geralmente são abortados durante o desenvolvimento. Quem achar esta estimativa muito drástica, pergunte para as áreas usuárias, provavelmente as respostas serão ainda piores.

Temos que colocar em segundo plano a parte tecnica e discutir realmente o motivo pelos quais temos dificuldade de entregar o prometido. Temos que entender as caracteristicas do Brasil, a forma de pensar dos usuários, o jogo politico, a velocidade das mudanças, como os projetos são pagos, avaliados e etc.

Sem este tipo de análise, vamos passar o resto da vida correndo atras do rabo, procurando uma forma tecnica de resolver um problema que envolve fatores que não podem ser medidos com uma regua.

Definir escopo, funcionalidades, e fazer protótipos para avaliação prévia. Excelente !!! Estando claro o objetivo, e as metas para alcançá-lo, já é um bom começo.

O problema maior, é o caminho a ser percorrido para se chagar ao objetivo traçado.

São fatores subjetivos, que vão determinar a diferença entre o estimado e o realizado.

Um dos problemas mais comuns, são os protótipos elaborados muito superficialmente, e continuar com a mesma superficialidade na construção.

Quando colocado em operação, o produto não corresponde às espectativas, resultando em retrabalho e conflitos.

Este filme, creio que todos já assistirem.

Quando a gente tem experiência em fazer algo, já fez várias vezes a mesma coisa, fica mais fácil estimar tempo e custo.

Isso é real em projetos de TI ? Só se for usando tecnologias já existentes a um bom tempo, o que é raríssimo.

Em TI, sempre existe uma nova e desconhecida variável. Todo projeto a ser desenvolvido, depende de um trabalho de pesquisa, de absorção de conhecimentos, de aprendizagem e ensino.

Um dos fatores pouco considerados em projetos que tenho participado, é a capacidade de uma equipe de transmitir informações e conhecimentos entre si.

Metodologia serve para isso, colocar as coisas documentadas para que todos envolvidos possam compreender o que já foi pensado e feito. Poder enxergar a floresta e as árvores, poder comparar tempo estimado e tempo gasto.

Para estimar tempo e custo, é necessário trabalhar de forma metódica. Isso é complicado de ser colocado em prática, mas a metodologia está dispnível, sempre esteve.

Existem várias formas de contrato e cada uma delas é adequada a um caso específico. Deve-se saber ponderar entre o uso de um ou outro tipo de contrato. Pode-se trabalhar com custo reembolsável, onde o contratante paga pelos custos apresentados pelo contratado e paga também a margem de lucro do contratado (é ideal para projetos investigativos). Pode-se trabalhar com contratos de custo fixo (onde se conhece o escopo e inclusive pode-se mensurar o esforço). Enfim, tudo depende da negociação com o contratante, do tipo de projeto e do processo de contratação.

São passos simples, mas dificeis de serem executados. Quanto maior a complexidade do projeto e do ambiente tecnico e corporativo, mais variaveis vão estar em jogo e fica mais dificil estimar o prazo e o custo. Mas em linhas gerais podemos resumir no seguinte:

Levantar o escopo.

Obter a aprovação dos usuários.

Fazer orçamento de cada fase separadamente. A parte de desenvolvimento de software pode ser usado APF, que dá um resultado bom.

Depois tem infra estrutura, instalação, carga de dados, treinamento, documentação, hardware, maquinas rede, suporte apos instalação.

O gerente de projeto tem que colocar tudo em um project, e obter o aval de todos envolvidos.

Dai é fazer as contas para saber quanto tempo vai demorar e quanto vai custar a brincadeira, e torcer para que o cliente aprove o orçamento e mãos a obra.

Acredito que a melhor maneira para se definir prazos e custos de um ou vários projetos é garantir a participação de todos os envolvidos, do planejamento ao encerramento, através de reuniões, palestras, um fluxo de comunicação claro, transparente e objetivo. As metodologias existentes no mercado são amparos e de grande importância para os projetos, estamos aqui falando do meio, isso mesmo, meio, muitas empresa (clientes) vêem equipes e consultorias como as soluções de seus problemas, e não é isso, na verdade eles é que os são de fato. Muitas vezes é preciso ilustrar ao cliente (interno e/ou externo) que prazos e custos são definidos diante de um plano estratégico "x" realizado numa visão "y" da corporação, mas que com o andamento destes projetos a organização pode passar a viver uma nova fase, a implantação de um “módulo” (se aplicável) implica em mudanças e todos sabem o que isso significa, cria uma nova visão para os envolvidos no primeiro plano, teremos aqui novos prazos e custos conseqüentemente. O importante é ressaltar, talvez, metas verticais e também horizontais, estágios de entregas e riscos destes, fotografias do projeto e o impacto dessas “fases” não apenas no plano estratégico de TI mas também da organização.

Isso em concordo com vc em genero numero e grau!! Masssss...........

É chara....não só ponto de função mas muita coisa não tem como ser utilizada em empresas brasileiras. Já escutei várias vezes que documentação do sistema não é necessária então imagine análise um APF, Risco.

É a realidade brasileira que acham que isso não vale a pena mas no final das contas o barato sai caro.

Uma tecnica que tenho usado e apresenta um bom resultado junto ao cliente é a prototipação. Normalmente faço um lista dos requisitos do sistema e em seguida prototipos das principais telas do sistema. Como o Cliente participa desse processo fica bem mais facil a negociação, pois o cliente embora leigo consegue ter uma visao do tamanho do sistema. Isso faz com que o cliente fique envolvido no projeto e acaba se sentindo parte dele.

E chara, ponto de funcao nao se aplicam bem na nossa pratica brasileira!!

Esse seria o trabalho a ser realizado para se ter uma perfeita visão de custo, prazo e risco. Agora, na prática, é muito difícil de ocorrer uma vez que, como já foi mencionado aqui, apresentar um estudo desse para uma empresa (cliente), dependendo da empresa, é atirar no próprio pé. Infelizmente a maioria acha que esse trabalho é desnecessário e os números apresentados inviabilizam um projeto mas o que tenho visto é que as decisões erradas durante as fases iniciais do projeto, no final, mostram um custo muito maior do que os números apresenados por uma análise de risco.

Existem várias formas e técnicas para estimar prazos, custos, pessoas em projetos assim como medidas para estimar os riscos.

Análise por Pontos de função (APF) é uma técnica bastante utilizada para estimar prazo e custo por permitir uma contagem das funcionalidades do sistema dando uma "visão" do tamanho do sistema. Mas o uso adequado de APF é complicado e depende também da experiência do Analista em saber identificr corretamente as funcionaliades e valoriza-las como também no final estimar o peso para a complexidade do sistema e é nessa parte aonde muitos erram.

Também deve ser feita a analise de risco do sistema usando simulações estatísticas (como a Monte Carlo) para avaliar se o prazo definido usando APF esta adequado, ou bem próximo da realidade, como também o custo e a quantidade de profissionais. Para essa análise existem diversas ferramentas que auxiliam esse traalho como o MSProject e uma freeware lançada por um professores da UFRJ especializados em Gerencia de Projetos e Análise de Risco(Eber e Juarez). A ferramentas deles realizam análise de risco usando o excel...

Existem várias metologias e métricas, mas o problema é que o cliente que compra o serviço é leigo em TI e se deixar enganar pela aparencia e aparente funcionalidade e mais ainda pelos preços baixo, então o mesmo não sabe que o sistema é um verdadeiro Titanic, não tem metodologia, nem qualidade, nenhum critério no desenvolvimento e até mão-de-obra pouco qualificada, ou seja , um verdadeiro Lixoware , aqueles que se bobear tem até GOTO ou outras gambiarras do genero

Nao existe uma forma de avaliar tempo e custo de projetos em TI, muitas vezes e um jogo de valores e tempo, o cliente sempre pega o mais barato, ou pior a empresa mais famosa de TI que terceiriza para uma menor com prazo menor!!Eu vi isso acontecer

Tecnicamente existem ferramentas que podem ser utilizadas e que geram uma boa previsão, mas ao meu ver o problema maior é comercial/politico. Em sendo uma consultoria, se voce colocar o valor real e o tempo necessário na primeira proposta, outra empresa vai chegar com um valor mais baixo e voce não vai levar nada. Portanto quase todas colocam valores reduzidos e depois comem o couro dos profissionais, contratam estagiários como programadores, programadores como analistas e etc.

Também procuram formas de aumentar o custo inicialmente contratado. É mais ou menos aquele caso do pedreiro que depois de derrubar a parede da sua casa, fala que o serviço é maior do que ele pensava e que vai ter que cobrar um adicional, caso contrário ele vai embora ...

Anteriores:

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 ?