Projeto é uma coisa, software é outra.
Desenvolvimento Ágil, Gerenciamento, LEAN, Metodologia, PMI, SCRUM, XP 5 Comments »Estava sem nada de interessante pra fazer ontem a noite e fui ler um livro que me emprestaram chamado Gerenciamento de Projetos – Como gerenciar seu projeto com qualidade, dentro do prazo e custos previstos.
Eu sabia que iria me estressar lendo o livro. Só pelo subtítulo já fica claro.
Mas ai pensei “o livro fala de projeto, não fala de software.”
Essa é a grande questão.
Não é que os defensores dos projetos e todas suas técnicas estejam errados, a questão é enxergar que a idéia de “projeto” não se encaixa em qualquer coisa que se produza nesse mundo.
Software é uma dessas coisas.
A idéia de software tem uma série de características muito especificas que a distancia daquilo que projetos tradicionais se dispõem a tratar.
Não é a toa que coisas com Lean, Scrum, XP e uma série de outras, apareceram focadas em produção de software.
Então por isso resolvi transcrever alguns trechos do livro, que fala de gerenciamento de projeto de forma geral, e colocar logo abaixo opiniões minhas baseadas somente na idéia de software e no que aprendi lendo e usando algumas metodologias que nasceram especificas para software.
Escopo
Controlado a partir de planejamento e documentação de itens que passam de uma área para outra, alem de procedimentos formais, formulários e sistemas de monitoração.
Se a idéia é ter um inicio, meio e fim bem definidos, alem de um custo fechado, então é razoável se preocupar tanto em identificar e formalizar o escopo.
Agora, se isso vai trazer algo de útil pro seu cliente daqui a 1 ano e meio, quando o tal projeto terminar, sem praticamente gerar um novo projeto só pra corrigir as falhas do original, aí já é outro papo.
Não é melhor esquecermos esses formalismos todos e partirmos pra uma definição de escopo gradual, algo como….”vc me diz o que quer….eu faço em algumas semanas….você diz se ficou legal….e continuamos nesse ciclo até você achar que deve parar.” ???
Prazo
O tempo é um padrão importante para avaliar o sucesso de um projeto e faz com que ele seja diferente do trabalho de natureza operacional ou de processo.
Exatamente! Projeto é um conceito que prevê a existência de inicio, meio e fim. Um processo de negócio não se encaixa nesse conceito. Processos evoluem continuamente e rodam através dos sistemas que construímos.
O que fazemos na maioria das vezes é apoiar um processo de negócio com soluções de TI. Nosso trabalho se assemelha muito mais a uma prestação de serviço do que a venda de um produto ou projeto.
Qualidade
As pressões exercidas por outros fatores, como custo e tempo, podem provocar negociações nas quais a qualidade será comprometida em favor do cronograma ou do orçamento.
Pois é. O tempo aperta, o esporro come solto, a qualidade é mandada pra você sabe onde, e os sistemas orientados a gambiarras são gerados. O mais engraçado é que muitas vezes, após ver que o produto final ficou uma porcaria, o cliente ainda paga de novo pro fornecedor criar novos softwares que corrijam o antigo. Já ouviram falar em coisas como: “batch para correção de base de dados rodando todo dia a noite” ou “Cobertor curto. Resolva um problema aqui e automaticamente crie outro ali” ?
Custo
Em última análise, os projetos resumem-se a dinheiro e gastos. O gerente de projeto é o responsável por manter os projetos dentro do orçamento aprovado.
Fechar o orçamento de construção de um prédio com X andares, cada qual com X apartamentos de X metros quadrados, usando X materiais, não chega a ser um trabalho para mágicos. É quase que uma questão puramente matemática.
Ninguém chega pra uma construtora e diz: “Eu quero fazer um prédio pra investir meu dinheiro. Não sei exatamente como, só sei que preciso investir minha grana. Tem que ficar pronto até o meio do ano. Quanto custa?”
Mas é exatamente assim que se faz software pra apoiar processos de negócio. O cliente não tem muitos detalhes do que vai solucionar o problema dele. O que ele sabe mesmo é que tem um problema e que possivelmente um software pode resolvê-lo. Fechar orçamento e prazo num cenário desse é pedir pra errar. O melhor é fechar um contrato de prestação de serviço.
Recursos Humanos
Quantas pessoas e com quais qualificações serão necessárias durante qual período de tempo, nesse projeto?
Esse modelo pressupõe que equipes são descartáveis. O que talvez influencie no uso da expressão “recurso” em muitas empresas de TI, ao invés de “pessoa” ou “profissional”.
Mas enfim, se sua empresa vive de fazer essa coisa chamada projeto, se os membros das equipes ficam cada vez mais produtivos e entrosados no decorrer dos projetos, então pra que encará-los como custo e não como investimento? Você pode ate manter os profissionais durante algum tempo após o projeto, mas vê-lo primordialmente como um custo mostra que você não enxerga muito bem as características do ramo de negócio em que sua empresa se encontra.
Um time de futebol INVESTE em jogadores, e quanto melhor o jogador, mais retorno FINANCEIRO pro time ele gera. Seja em títulos, bilheteria ou publicidade agregada.
Uma empresa de TI funciona de forma muito parecida. Ou pelo menos deveria.
Recent Comments