 |
gildot |
 |
| |
| | Project Wars, ou como nao matar um projecto de TI. | | |  | Contribuído por BladeRunner em 30-08-02 20:32
do departamento nice-to-hear-from-you-again-pal | |  | |  | | |  leitao escreve "Boas. 'A uns tempos escrevi uma especie de whitepaper relativo 'a engenharia de software e gestao de projectos, que tenta explicar a razao porque muitos projectos de TI falham. Coloquei este documento disponivel aqui. Isto foi escrito com gestores de projecto em vista, mas penso poder ser util para qualquer pessoa envolvida em tecnologias de informacao. Comentarios sao bem vindos." | | | | | | < Trabalhar em área de Segurança (ignorancia em pt) | Desenvolvimento de software em Windows > | | gildot Login | | | Referências | | |
| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Pela minha experiencia em gestão de projectos, a maior causa de falha num projecto TI é a falta de concretização dos seus intervenientes.
Este tipo de intervenientes adora planear e desenhar soluções mas depois quando as tem que implementar arranja sempre qualquer coisa para o distrair que o afasta da sua tarefa. Normalmente arranca muito bem e muito dedicado mas depois ou porque descobriu uma tecnologia nova ou porque os artigos do Gildot estavam muito interessantes começa a divergir. E isto, sem se aperceber porque no fundo ele pensa que esta a adquirir novos conheciemntos que ate serão uteis para o projecto. Aí os projectos começam a derrapar no tempo e eis que surge a falta de motivação. E chegou a um ciclo vicioso. O projecto não avança porque ele não esta motivado e ele não fica motivado porque o projecto não avança!
A unica forma de evitar a falha quando os intervenientes tem esta caracteristica, e no mundo de TI existem muitos, é uma analise constante da produtividade de cada um. Porque se o "ponto da situação" for feito já no ciclo vicioso o caso fica muito complicado!
Nuno Paulino aka Rollerball
|
| | | | | por Anonimo Cobarde em 02-09-02 1:08 GMT (#6)
|
| Ou seja... a tua solucao é fazer o "ponto da situação" regularmente, para lhe dar cabo da cabeça, ele começa a considerar-te uma ama seca, chateia-se e volta pro Gildot e pras novas tecnologias. :-)
|
| | | | Parabéns pelo artigo, mas deixaste escapar 2 pontos interessantes (ok, o primeiro está em parte implícito no artigo).
1) A informática numa empresa pode ser vista de várias formas:
- Aumento de eficiência através da automatização de processos.
- Manutenção do negócio em funcionamento (foi o caso de muitos projectos do ano 2000).
- Custo do negócio (normalmente esta visão leva a projectos cujo impacto no negócio não é sequer medido).
- Reputação do gestor em causa (muito típico em Portugal, afinal quem é que se quer gabar de gerir um projecto de 10 mil contos quando pode gerir um de 10 milhões de contos).
O teu artigo pressupõe que a visão correcta é apenas a primeira ignorando qualquer componente organizacional que dá origem às outras visões. Por isso considero o artigo incompleto.
2) Os projectos de informática são baratos (comecem a olhar para o custo de umas máquinas industriais ou, por exemplo, de uma clínica e digam-me, se conseguirem, que o software e hardware para gerir isso é caro). Em conjunto com a falta de percepção do impacto da informática do negócio isto leva a desastres constantes (as estimativas de falhanços na área de informática apontam para 75 a 80% de projectos falhados).
Por estranho que pareça são os projectos mais caros (não obrigatoriamente os tecnicamente mais complexos, como bem sabemos) que têm menores taxas de falhas. Porquê ? A maior parte dos estudos sobre o assunto parecem apontar para uma razão óbvia: quanto maior o custo, maior o envolvimento da empresa do projecto, o que permite identificar erros mais cedo e fazer uma gestão mais correcta do projecto.
|
| | | | Este artigo é muito bom, especialmente para geeks, porque muitos desses são os que precisamente evita planear projectos, mesmo os que são complexos, em parte porque perde a piada de desenvolver software uma vez que investir tempo no planeamento dos projectos é a parte chata dado que tudo é teórico e os resultados do projecto só se vêem depois dos programadores o implementarem. Resumindo, dificilmente algum geek vai ler este artigo e achar que tem de mudar a sua forma de desenvolver mesmo projectos de tamanho médio ou grande. Quem sabe mais tarde mudem de atitude com mais experiências de projectos falhados.
No entanto, existe certamente outro tipo de pessoas que se identifica com aqueles tiveram projectos que falharam pelas causas apontadas e gostaram do artigo porque de certa forma abre os olhos para aquilo que chamo principio de soluções para evitar os problemas que levam aos falhanços.
Porém o artigo não é muito claro sobre os métodos que deveriam ser seguidos para evitar esses falhanços. Claro que é preciso fazer análise de requisitos, análise de riscos , planear a execução e testes do projectos, frequentemente revendo tudo o que foi definido para trás para não deixar pontas soltas ou situações não previstas.
Talvez esteja fora do âmbito do artigo ser mais explícito e recomendar metodologias para cada coisa explicando como e porquê. Na verdade isso são assuntos extensos que dariam matéria para vários semestres de análise de sistemas em currículos de universidades, e por isso não fizesse muito sentido entrar em detalhes neste artigo.
Porém, aproveito para complementar e recomendar este livro sobre a aplicação de casos de uso que explica como podem ser usados para descrever projectos e seus requisitos fazendo análise de riscos para ordenar as prioridades do projecto para evitar que este não falha, e partindo daí para a modelagem do projecto através da documentação de casos de uso, recorrendo obviamente a UML para cedo tornar os projectos o mais claro possível a patrocinadores, clientes, utilizadores e equipa de desenvolvimento para que todos fiquem em sintonia antes de passar à implementação.
Admito que este trabalho de planeamento não é para mim e muitos outros a parte mais interessante porque normalmente é uma chatice teórica que tem de ser revista frequentemente. Porém, é vital para o sucesso de projectos de tamanho médio ou grande.
Algumas ferramentas CASE podem ajudar, mas em geral as que conheço são limitadas porque nem sempre vão de acordo com a minha visão das necessidades.
Nesse sentido, tenho desenvolvido alguns formatos XML para documentar projectos com análise de requisitos e riscos, arquitectura de sub-sistemas, casos de uso e actores envolvidos e mais tarde definição de diagramas através de UML a partir desses dados.
Espero um dia ter disponibilidade de divulgar esses formatos de XML uma vez que acredito que atendem as necessidades de muitas outras pessoas e pelo que pude entender não existiam formatos exactamente para isto.
|
| | | | | | Um livro que eu não posso deixar de recomendar para quem esteja interessado em gestão de projectos de informática é o Mythical Man-Month. É fácil de achar mesmo em livrarias portuguesas. Apesar dos seus quase 30 anos continua extremamente actual.
|
| | | | | Vou lendo devagarinho... Não entendo esta figura: http://scaletrix.com/nuno/ projectwars/costefficiency.jpg. Só entendo as abcissas (technical suitability); das ordenadas, especulo que "quanto maior, melhor"; não entendo o que representa a curva vermelha; não entendo a divisão em regiões "aceitáveis" e "não aceitáveis".
|
| |
|
