timeBox

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.

Você é chamado para fazer parte de um projeto que não vai necessariamente entregar um sistema classicão (do tipo com telinhas, usuários de carne e osso, etc). Sua função é criar uma interface java com um content management de mercado.

Ok.

Você então projeta sua solução com base em JUnit.
Testa a chamada a interface, verifica que está tudo ok e entrega o produto.
Pra não ficar só em código, você até documenta a interface gerada em uma espécie de contrato. Dizendo como ela deve ser chamada e o que se esperar dela e tal. Tudo bonitinho.

Ai alguém chega pra você e diz que sua entrega não está aderente a metodologia da casa.
Afinal, faltou criar o diagrama de caso de uso e seu respectivo documento word de descrição do mesmo.
Então você entrega o tal caso de uso e algumas semanas depois ele volta pra você num e-mail que diz: Seu caso de uso não está aderente as melhores práticas pregadas pela casa para o mesmo. O fluxo básico está usando de termos técnicos e não representa com clareza uma interação entre o ator e o sistema.

Agora me diga. Qual a utilidade de se fazer um caso de uso numa situação como essa? Onde seu trabalho se resume a produzir um serviço de comunicação com uma ferramenta, o qual será chamado por outros serviços?

Qual a utilidade de se engessar de tal forma a quantidade e qualidade da documentação que deve ser feita?

Não pegou a idéia ainda?
Imagine só. Alguém te convida pra ser padrinho de casamento. Um outro alguém te alerta que você deve ir de terno a um casamento. Gravata, sapato, tudo certinho.
Mas o casamento que te convidaram pra ser padrinho será na praia, ali na areia e tal. Sei lá, a noiva viu um assim numa revista e resolveu que o dela seria assim também!

E ai? Você vai aparecer por la de terno? Gravata no sol de meio dia? Sapato na areia?
Seu bom senso vai te dizer alguma coisa sobre isso, não?

Muita gente já tem batido nessa tecla aqui no Brasil em blogs e revistas. Lá fora então, a décadas que esse tipo de coisa é difundida e até tem tido uma evolução no nível de aceitação.
O RUP tem isso, o XP também, o SCRUM. O que não falta é metodologia e escritor famoso defendendo esse ponto de vista. Mas aqui no nosso mercado, infelizmente, ainda estamos engatinhando com tímidas iniciativas.

Eu estou falando de ESCOPO NEGOCIÁVEL + DESENVOLVIMENTO ITERATIVO.

Não é raro eu entrar nesse assunto com alguém e ouvir de volta: “ah…muito legal, mas no mundo real não é assim”, ou então, “você está sendo acadêmico demais”.

Eu? Acadêmico? hehe….Vamos pular essa parte e partir pra alguns dados reais de mercado.

A décadas que o Standish Group vem divulgando o CHAOS Report, um conjunto de estatísticas sobre os resultados obtidos em milhares de projetos ao redor do mundo.
Só pra exemplificar, os dados de 2003 revelam que 34% dos 13.522 projetos pesquisados atingiram o sucesso, ou seja, foram entregues dentro do prazo, custo e ESCOPO FECHADO previsto inicialmente. Do restante, 15% foram cancelados e 51% tiveram prazo e/ou custo aumentados consideravelmente.

Com base nas funcionalidades que foram entregues nos projetos ditos de sucesso, foi perguntado aos clientes dessas funcionalidades, qual o grau de uso que eles estavam tendo sobre elas. A média das respostas foi a seguinte:
7% sempre são utilizadas, 13% frequentemente, 16% as vezes, 19% raramente e pasmem….45% nunca são utilizadas!

É isso aí, a maior parte estourou prazo/custo ou foi cancelada e dos que tiveram sucesso, quase a metade das funcionalidades não serve pra nada NO MUNDO REAL. Legal né???

Imagino que depois de ler isso em 2004, quem passou o ano anterior perdendo contratos ou gastando uma nota com hora extra, deva ter olhado com outros olhos essa questão de escopo negociável + desenvolvimento iterativo.

O problema de negócio que queremos resolver via software é que deve ter o escopo fechado.
As fronteiras que a solução sistémica não deverá ultrapassar é que devem ser delimitadas.

Agora, qual a real complexidade ou até mesmo necessidade dos X possíveis casos de uso, histórias, ou seja lá o que for, inicialmente imaginados pra resolver os problemas (de negócio) contidos no escopo (de negócio) de um projeto?
Não tem como responder isso com precisão ! Nem com ponto de função nem com qualquer outro ponto que seja.

Bem vindo(a) ao mundo real