Engenharia de Software: Anatomia de um Projeto Fracassado

Infelizmente este amadorismo é generalizado. Teoricamente alguém deveria sair de uma universidade sabendo gerenciar projetos, mas esta não é a verdade.

---------------------------------------------------------
Cesarcamarg0s.spaces.live.com

Onde eu trabalhava passamos um ano discutindo isso. Sobre qual seria a melhor forma de planejamento sabendo que software é algo abstrato.

Não chegamos a uma conclusão satisfatória.

Deus Ex Machina

Essa memória do Bicalho sobre projetos "ferrados" é longa...

_____________________________________________________________

Sempre programe como se seu cliente fosse um maníaco serial killer que sabe onde você mora.

Ruim mesmo é quando o cliente acredita que o estamos "enrolando" porque o prazo está estourando por causa de uma "pequenina mudança" no escopo do projeto (ou seja, reanálise)

Eu acredito que esta pesquisa é furada. Este índice de 30% de projetos concluídos com sucesso dentro do prazo e orçamentos é superestimado.

na verdade, não só com softwares o índice é tão elevado...
é costume atrasar...pelomenos por aqui

Minha experiência mostra que o fruto das desistências na maioria das vezes tem a ver com gerente inebriado de "superprodutividade". As vezes, o gerente entende de processos, mas não entende de sistemas e desenha um esquema que só funciona na cabeça dele, mas ninguem diz que não pode fazê-lo. Daí os programadores começam e depois de algum tempo percebem que algo melhor surgiu, o leadtime do processo aumentou, etc... para chegar a conclusão que o sistema naufragou.

Abandonar um sistema que tá naufragando é mole e fácil, duro é abandonar um sistema porque lhe empurram outro porque alguem disse "é só um sisteminha que você tira de letra".

--
Se não fosse pelo C, estaríamos usando BASI, PASAL e OBOL.

Acho que tudo se resume em "as pessoas acharem que computadores fazem mágica!"

________________________________________
"Viva como se fosse morrer amanhã.
Aprenda com se fosse viver para sempre."
Mahatma Gandhi

By CataBits

O problema nem de longe é a etapa de planejamento. Por causa de um modismo bobo, tudo gira em torno do "planejamento".

A grande questão é o pré-planejamento. Antes de começar a burrocratizar tudo, é necessário envolver a equipe com a razão de existir do projeto. Todos sabemos que o maior problema de engenharia de software é a produtividade vs. qualidade. A única forma que existe de equilibrar essa equação é motivar. Gosto muito de observar pastores evangélicos, apresentadores de tv, políticos, entre outros para saber como eles fazem para cativar as pessoas, envolve-las numa causa e serem sinceras quando dizem "sim, farei minha parte!".

Do que adianta planejar se seu exército não sente amor pela pátria? Se estão lá só pelo soldo e não querem morrer?

Planejamento é básico. O problema é outro, e está nas ciências humanas.

My Memory About Freaked Up Projects

Ótima matéria! Infelizmente é assim, fazer nas coxas para entregar rápido e ter um volume de desenvolvimento bom, consecutivamente faturar mais. Mundo capitalista é assim, ja perdi as vezes que tive que fazer tudo nas coxas pela exigência do imediatismo e da imprudência de analises meia-boca.

Isso é um mal generalizado, acontece nas melhores famílias.
----
.\o>
. |
. \\

Fazer um projeto, colocar documentação também
não garante nada, eu trabalho numa empresa
grande que tem todos os grupos criados para
isso, dezenas de analistas cuidando da gestão
de requisitos, a gerência tem mestrado na área.
E sabe o que o documento de requisito é?
Uma bela M..., é impressionante o quanto as
pessoas acham que requisito é coisa de tecnologia.
NÃO É, quem teria q aprender a fazer requisito
é o pessoal de negócio.
Eu passei meses batendo cabeça tentando passar
o projeto inteligente, q realmente dissesse
algo sobre o negócio, desisti, aprendi a fazer
o CRUD do jeito que eles queriam e fiz uma
planilha que gera o Crud (só coloco o nome
da entidade, a planilha gera tudo por conca-
tenação) e estou fazendo um documento de
verdade que vou usar para dar aceite no
código que o pessoal do código vai me
entregar.
Só o fato de quase todo livro de Análise
de software recomendar o CRUD já me dá
arrepios (Qual é o caminho feliz do CRUD?
A inserção? A alteração? Ou a exclusão?)

Me parece que o Eiffel tenta endereçar algumas dessas deficiências, principalmente a parte de requisitos, alguém tem alguma experiência prática com Eiffel?

Peguem as tochas, foices e acendam as fogueiras!

O percentual de projetos fracassados é maior no geral. Tempo, custo e escopo ainda podem ser medidos, mas se o que você entrega para o cliente é o que ele quer ou precisa é outra história.
As boas práticas de gerência de projetos que o PMI, ITIL, COBIT pregam, nunca vi sendo implementadas. Mas já vi gerentes estufando o peito e tirando onde de bonzão só porque tem uma certificação PMP ou similar. Se não aplica ou não sabe aplicar o que aprendeu, do que adianta o título? Para pendurar na parede? Só se for.
Não se pode controlar o que não se pode medir e não vejo medições sérias. A falta de planejamento é um erro imperdoável. Planejam mal e por tempo insuficiente. Numa proporção de 2 semanas de planejamento para 2 anos de execução. No Japão um projeto de 2 anos tem 1,5 anos de planejamento e o restante para execução. “Qualquer diferença é mera incompetência.”
Estimativas são feitas assim: lambem o dedo e apontam para o alto, para onde o vento soprar é pra lá que vão. Requisito é balela e risco deve ser um traço de giz no quadro negro.

Legal o artigo, Bicalho.

Só uma pergunta: depois de todas essas pesquisas e as conclusões que podemos tirar deles, será que ainda é adequado falar em Engenharia de Software? Ou, por outro ângulo: será que Engenharia de Software existe?

Abraços

Planejar é uma situação complicada, até por que não faz parte da cultura do empresário brasileiro, dai, como disse um cliente uma vez: "Não é só escrever essas coisinhas ai no computador e o programa já está pronto !", bom, a empresa dele faliu, garanto para vocês que não foi culpa do sistema....

Engenharia de software? Isso até ofende a Engenharia.
O que existe hoje é DESENVOLVIMENTO de software, mas ENGENHARIA de software eu desconheçco. Isso é que nem papai noel, a gente brincando mas sabe que não existe.

Bom, tenho uma frase para tudo isso: It’s the Architecture, Stupid!

Muitos acham que Arquitetura de Software é responsável apenas por desenhar os diagramas que separam as várias layers do sistema. Mas a arquitetura vai muito além disso e é responsável também por alinhar as visões de todos os envolvidos no projeto e levantar todos os requisitos e mitigar os riscos.

Infelizmente, a maioria das empresas/desenvolvedores acham que essa parte é bobagem e/ou perda de tempo.

Cássio Rogério Eskelsen

Excelente post Bicalho !!!

Só gostaria de acrescentar um ponto: o que eu vejo acontecendo hoje no mercado é a unificação das diversas variações da profissão de 'Analista de Sistemas'.

Tive uma palestra na FATEC-SP essa semana onde o prof. mencionou o fato de que na década de 80/90 (quando + ou - se iniciou com mais força a profissão de TI) as atribuições eram bem separadas. Quer dizer, programador era só programador, analista só analista etc.

Hoje temos o 'Analista-Programador' e estamos evoluíndo para o 'Analista de Negócios', que é aquele que DEVE / PRECISA entender do Business, das regras de negócio da área em que atua.

Eu sinto isso na pele, uma vez que trabalho no ramo de comércio exterior, e para as funções de analista que exerço no meu dia=a=dia eu preciso conhecer a legislação e os processos de importação / exportação.

Outra tendência que vejo é a demanda cada vez maior por Business Inteligence. Ao mesmo tempo vejo que muitas vezes esse termo não é muito claro para as pessoas...

Enfim, vou parar por aqui pra não 'enrolar' muito kkkk. Espero ter acrescentado ao post

______________________________________
und ihr werdet die Wahrheit erkennen,
und die Wahrheit wird euch frei machen

Off total, mas é por essa e outras que eu me afastei de desenvolvimento de softwares comerciais... Gente preocupada demais com os "business" e preocupada de menos com todo o resto: ciência e tecnologia mesmo, salvo raras excessões, são só detalhes que não importam muito...

Deixo isso para quem tem saco. Prefiro a idéia de ser pesquisador.

____________________
"Triste época! É mais fácil desintegrar um átomo do que um preconceito" (Albert Einstein).

Cara esse povo precisa refazer o curso de engenharia! a organização tá péssima!

http://culturaatual.blogspot.com/

É claro que esta discussão não termina aqui, mas quero acrescentar a ela algo que muitos desenvolvedores esquecem, por estar mais acostumada com computadores do que com pessoas: gerenciar um projeto é gerenciar pessoas, e esse bicho é complicado!
Já estive em projetos que naufragaram porque os programadores ficavam mudando de ideia o tempo todo sobre qual era a melhor forma de fazer as coisas, e o gerente de projeto não tinha pulso/habilidade para fazer com que a equipe caminhasse o tempo todo para o mesmo lado. O resultado era uma reengenharia total a cada 2 ou 3 meses. Isso também não dá certo.
Esse assunto está longe de ter uma solução, mas tenho plena convicção de que ela passa por uma melhora na valorização das relações pessoais e habilidades gerenciais dos envolvidos.

------------------------
Não entre em pânico! (O Guia do Mochileiro das Galáxias)

"Se traçarmos um paralelo com o mundo real, é como começar a construir um prédio, sem saber quantos andares ele vai ter."

Pior: depois do prédio quase pronto, o designer quer a porta da garagem 1 metro mais a esquerda, justo no lugar onde hoje existe um pilar, e terá que ser removido. Como? É problema de outra pessoa, não dele!

Essa questão do planejamento, inexistente, é desesperadora!
"Vamos pensar neste problema mais pra frente, por enquanto, vai tocando", bem do jeitinho POG de programar.

Ufa... desabafei, eheuhau

_______________________________
Blog FelipeJ.Net

Só tome cuidado com essa comparação com engenharia civil.
Tudo bem que planejamento são necessários para os dois, mas um software é muito diferente de um prédio.
Existem outras analogia melhores Como por exemplo, a do pomar/jardim.

Não sei se esse problema demanda de pressão por parte de clientes que obrigam gerentes de projeto a atropelar as etapas de análise e projeto ou os próprios gerentes que superestimam a velocidade de conclusão do projeto e se vêem obrigados e "engolir" essas etapas.

O resultado é esse, muito bem explanado no post por sinal, que gera índices absurdos de falhas de softs.

Infelizmente, lamentável.

Benjamin Pinto

Ricardo, Adorei o Post. Como sempre vc vem levantando uma polêmica positiva.

robson_franca: Na minha opinião, o diferencial da FATEC era unir, no mesmo curso, as duas linhas: tanto o lado acadêmico (programação, estruturas de dados, sistemas operacionais) como o lado administrativo.

Também fiz FATEC(2001) e também acho que esse é o principal diferencial dela, essa junção entre negócio/tecnico que se dá pela experiência de mercados dos professores que dão aula lá. As melhores aulas que tive eram as historinhas contadas pelos professores, tanto da época dos computadores operados a cartão, quanto aos contos sobre casos de sucesso/fracasso na área.

Ricardo Bicalho: Se traçarmos um paralelo com o mundo real, é como começar a construir um prédio, sem saber quantos andares ele vai ter.

Ricardo, essa frase é interessante e é exatamente isso o que as metodologias ágeis propõe com sucesso: construir um prédio, sem saber quantos andares ele vai ter. Parece estranho mas é isso mesmo. Significa que só será desenvolvido o que precisa ser desenvolvido no momento. As metodologia ágeis, como XP, colocam o usuário na equipe de DESENVOLVEDORES (Analista o escambal) como uma de suas práticas.

Pré-requisitos para se utilizar qualquer metodologia

• - exige comprometimento de todos envolvidos
• - baseia-se na honestidade mútua entre os cliente e os desenvolvedores
• - precisa ter bons desenvolvedores, capazes de lidar com negocio e ter domínio sobre a linguagem de programação utilizada.

Existem muitos outras práticas interessantes, como testes automatizados e servidores para integração contínua.

Para quem quiser quebrar paradigmas:
Vejam: http://agilemanifesto.org/
Leiam: Programação Extrema ( XP ) Explicada - Kent Beck