Experimente um projeto ágil
Por mais que a engenharia de software seja uma “ciência” muito nova, está muito perigoso o caminho que os negócios estão impondo para os projetos de software. Perigoso porque é antagônico: de um lado compradores vão ao mercado e perguntam qual fornecedor faz mais barato, e do outro as metodologias estão preocupadas com a “cientificidade” da engenharia e apresentam mais e mais métodos, bem como técnicas que encarecem o processo de construção e controle.
Eu entendo o quanto é difícil para nós, técnicos, aceitarmos a teoria que os projetos de software hoje estão sendo comprados como se fossem commodities. Contudo, por mais quanto tempo vamos fechar nossos olhos para esta realidade?
As propostas de qualidade, as exigências de padrões como CMMI, as ofertas de controle mais adequados com técnicas do PMBok, podem até fazer parte das solicitações de tomada de preços (ou RFP, Request For Proposal), mas na grande maioria dos casos a influência do preço é determinística a escolha vencedora.
A idéia na mente do cliente
Nossos clientes de projetos de software não estão distinguindo em atos o processo de compra de serviços baseados em projetos de engenharia como compras de commodities, apesar de na teoria afirmarem diferenciar. Eu assumo esta afirmativa como uma leitura pessoal, entretanto solicito respeitosamente que você aceite-a como “colaboração do benefício da dúvida”. É com base nesta afirmativa que escrevo todo o texto a seguir neste artigo.
Como não é inteligente ficar colocando a culpa nos clientes, vamos assumir nossas responsabilidades e aprender como nós técnicos contribuímos, e muito, para o cenário de compras de projetos estabelecido hoje no Brasil.
Primeiro defende-se a aplicação de vários padrões de mercado inspirados em fábricas ou engenharia civil. Na minha posição, apesar de admitir que certas analogias são sensatas, afirmo que a maioria destas práticas podem ser inadequadas ao processo de construção e controle de software.
Exemplificando, processos e técnicas baseados em fábricas consideram trabalhos braçais e uma linha de montagem. Francamente, existem pontos de um projeto de software que podemos automatizar por serem braçais, mas a grande maioria das atividades necessárias são trabalhos intelectuais. Também reconheço que ao estudar SDLC – Software Development Life Cycle (ciclo de vida de desenvolvimento) podemos compreender a tentativa de estabelecer uma espécie de linha de montagem. Entretanto, comparar um ciclo de vida de desenvolvimento com uma linha de montagem de carros é uma analogia surrealista em vários aspectos, principalmente quando reconhecemos que em projetos de software temos poucas atividades de “apertar parafuso” ou atividades que poderiam ser efetuadas por um robô.
Um conhecido exemplo da engenharia civil é o famoso gráfico sobre o preço de uma alteração no decorrer do projeto. As analogias com a engenharia civil nos ensinam que mudar um banheiro de lugar em tempo de planta é o esforço de replanejar. Mudar o banheiro após os tijolos estarem no lugar implica em perda de material e retrocesso no estágio da obra. É irracional não concordar que na engenharia civil é assim, mas eu acredito que este exemplo não é devidamente proporcional para a engenharia de software. Minha crença, baseada em práticas ágeis e em meu histórico de realizações defende o seguinte gráfico.
Gráfico do custo do esforço de modificações conforme a fase do projeto. Na eixo ‘x’ temos o custo de investimento percentual da alteração em comparação ao que já foi feito e no eixo ‘y’ temos as fases do ciclo do projeto.
No gráfico observamos que uma mudança de escopo de uma funcionalidade na fase de planejamento custa um esforço de retrabalho em torno de 25% para as duas visões, porém nas fases mais adiantes a diferença de esforço e consequentemente custo é assustadora.
Na minha visão, o exemplo de projetos tradicionais foi fundamentado na analogia com a engenharia civil e não tem histórico de veracidade comprovado, ou se existir, é muito específico.
Este dois exemplos explanados mostram-me que nós, técnicos e fornecedores de projetos de software, somos os principais incentivadores do processo de compra de software como se fosse commodities.
Commodity é um bem material normalmente produzido em massa que possui parâmetros de qualidade muito semelhantes no qual o consumidor não tem muitos mecanismos de diferenciá-los. Para este tipo de produto as técnicas de escolha são baseadas em preço e atendimento.
A revisão dos paradigmas da engenharia de software
O título deste subtópico do texto já começou errado. Propositalmente coloquei desta forma para que o leitor possa visualizar minhas preocupações. As idéias que pretendem mudanças não podem serem apresentadas sem considerar os aspectos humanos das pessoas que precisam entendê-las. De fato, existe uma resistência natural nas pessoas a qualquer proposta que começa com a silaba “re”. É mais fácil despertar interesse de evoluções do que de revoluções. Propostas revolucionárias são fracassadas. Propostas que apresentam o novo de forma suave sem “acordar” os sempre presentes temores dos humanos possuem uma chance de sucesso maior.
Então, ao invés de “a revisão dos paradigmas da engenharia de software”, encontraríamos muito menos resistência das pessoas se o título fosse “uma nova visão para a engenharia de software”. Por que é importante entender isso? É porque qualquer proposta nova sofre do racismo natural a mudança e quando escrevo um artigo fico conversando com meu “leitor imaginário” como posso ajudá-lo a propagar as idéias da matéria.
Sobre os paradigmas, quero expor os seguintes pensamentos:
1- A maioria das propostas de metodologia foram criadas na década de 80 influenciadas com os grandes avanços de hardware patrocinados pela guerra fria entre o bloco capitalista e o bloco socialista.
2- Todas as pesquisas sobre o sucesso em projetos de software realizadas pelo Standish Group nos últimos 15 anos apresentam números catastróficos onde visualiza-se pouquíssimos sucessos e um alto número de fracassos;
3- Os ajustes das propostas de metodologia, ou suas variações evolutivas, foram baseadas na experiência do fracasso na busca incessante de evitar o fracasso. Conclusão: Aumento de controle, processos “pesados” e técnicas míopes;
4- Crescente número de padrões impondo aos fornecedores de software uma espécie de “normatização” visando tornar a concorrência de preço equilibrada (nota do autor: os projetos vão virar commodities).
A compreensão destes pensamentos podem trazer-te uma série de dúvidas sobre onde está o problema, entretanto o ponto mais importante para mim é a ausência de foco no sucesso. Percebam que as propostas novas querem evitar o fracasso ou normatizar a concorrência, não houve um direcionamento específico a realização “projeto de sucesso”.
O aprofundamento neste pensamentos resultarão em duas hipóteses distintas:
1- O sucesso no projeto é uma coisa muito pessoal que os que conseguirão guardam os detalhes mais preciosos a “sete chaves”. Nesta linha justifica-se os pensadores que defendem somente projetos de software como atividades intelectuais que poucos humanos são capazes de realizar;
2- Perdeu-se a referência do que é sucesso. Os valores foram distorcidos com o tempo, as pessoas perderam as referências certas e foram invadidas pelas experiência (lições aprendidas) dos fracassos.
Particularmente posiciono-me na segunda hipótese. Sendo assim, precisamos definir o que é sucesso em projetos de software. Novamente, minha posição pessoal é: Sucesso de software é a satisfação do cliente.
Para o fornecedor que está preocupado com muitos outros valores como rentabilidade, produtividade, previsibilidade, qualidade e outros “dades” existentes, sem problemas. Satisfazer o cliente plenamente é atender todos os valores do cliente respeitando os valores do fornecedor também. É uma sinergia.
O pedido colocado neste artigo é: Ao invés de buscar e implantar técnicas para evitar o fracasso nos projetos de software, permita-se estudar novas técnicas preocupadas em satisfazer o cliente.
As propostas ágeis
Como fugir da mentalidade “quanto menor o preço, melhor o negócio”? Criando controles para congelar tudo no projeto e esquivar-se de prejuízos financeiros? Padronizando todos os fornecedores de software com certificados para que todos tenham o mesmo preço?
As propostas ágeis baseiam-se na compreensão que a compra de um projeto de software segue orientação calçada em um serviço único, exclusivo. Um projeto nunca é igual a outro, por mais que existam padrões e aplique-se “militarmente” uma metodologia.
As principais orientações de um projeto ágil são:
• Aprender com o valor do projeto;
• Foco total na satisfação do cliente;
• Comunicação transparente dentro da equipe e com o cliente.
O maior valor que o projeto trará para o próprio projeto não são as lições aprendidas como erros que precisam ser evitados. A lição válida é aprender com os acertos. Aprender com os erros é uma afirmativa que questiono há alguns anos.
Vou exemplificar com o sentido da palavra experiência. Para mim, experiência se adquire quando você não consegue atingir seu objetivo. Uma analogia engraçada: Um amigo meu ontem ao avistar uma linda mulher desacompanhada indagou comigo que ia paquerá-la. Após alguns minutos ele retorna. Eu pergunto-o: E aí, o que conseguiu? É, ganhei experiência para a próxima – respondeu ele.
Um exemplo que apliquei com sucesso em meu último projeto: Investimos 16 horas para confeccionar documentos de caso de uso que descreviam o fluxo principal, o fluxo alternativo e o fluxo de exceção de determinada tela do sistema. Pedi para os analistas de negócios aprenderem com o próprio projeto. Orientei eles a escreverem somente o fluxo principal e enviarem para o desenvolvimento. Após implementado, os analistas de negócios testavam as telas e escreviam os fluxos alternativos e de exceção. Resultado: Aumentamos a qualidade do produto sensivelmente e reduzimos o tempo de especificação em 50%.
A satisfação do cliente, por incrível que pareça, em muitos projetos é tratada com importância secundária. Sem entender os valores do cliente como iremos atendê-los? Eu concordo que requisitos de negócios são como água, quanto mais congelados mais fáceis são de trabalhar. Entretanto, não permitir que o cliente evolua suas idéias pode fazer com que você entregue o projeto no prazo e com o custo previsto, mas o projeto não seja utilizado pelo cliente.
A melhor forma de atender mudanças evolutivas de escopo sem comprometer o resultado financeiro do projeto é pegar constantemente o feedback do cliente o mais cedo possível. Vamos imaginar como fazemos isso de forma simples:
1- Na entrevista ou nos processos de especificação escreva tudo que o usuário quer, afinal papel aceita qualquer coisa mesmo;
2- Antes de passar ao desenvolvimento, classifique o que o usuário pediu como mais importante com destaque. Mantenha o foco nestes pontos, são os mais relevantes;
3- Planeje duas semanas de trabalho que incluem desenvolvimento e testes básicos;
4- Oriente para que a implementação seja a mais simples possível, ela corre sério risco de ser modificada;
5- Assim que atender os requisitos mínimos de qualidade nos testes que você aplicou, mostre para o usuário.
Trabalhe todas as observações do usuário com maior atenção nesta fase, assim você estará investindo maior esforço em um requisito com maior “maturidade”. Depois disso repita estes cinco passos para todos os conjuntos de funcionalidades afins do projeto. De duas em duas semanas, o projeto será finalizado agradando plenamente o usuário.
Um conselho pessoal que passo como complementar neste ponto é “faça sempre a parte mais difícil primeiro”. No fundo, os clientes pouco estão ligando para cadastros básicos e querem ver mesmo a parte mais importante do software funcionando. Esta prática que aconselho tem inúmeras vantagens, entre elas, se você precisar reduzir escopo para não estourar o orçamento do projeto, é bem mais fácil retirar cadastros simples e listagens do que os principais requisitos do projeto.
Comunicação é um tema tão discutido e tão pouco efetivamente evoluído dentro dos projetos que nos deixa desanimado de escrever. Para mim, o erro já nasce nas universidades que consideram os cursos de informática como ciência exata. Tom DeMarco, em seu livro Peopleware, deixa claro desde a década passada que os problemas em projetos de software estão muito mais relacionados a fatores humanos que técnicos. Conheço muitos programadores excelentes de código que não conseguem se relacionar com seres humanos e acham engraçado quando comentamos que deveríamos colocá-los trancados em uma sala sem janelas e passar por debaixo da porta as especificações e a pizza.
Falta na formação do técnico em informática disciplinas que ensinam o trabalho em equipe, inteligência emocional, resolução de conflitos e comunicação clara (entre outras).
Considerações finais
Mudar o enfoque de quais são os problemas nos projetos que precisam de técnicas para serem resolvidos, trará uma nova realidade de estudo e prática. As técnicas mais comuns que aprendemos hoje foram criadas na tentativa de solucionar uma crise do software que, inclusive, já dura mais de dez anos. Se uma crise dura mais que três anos, para mim, não é mais uma crise, é a nova realidade da vida.
Basear-se também em exemplos de engenharias similares e processos de fábrica não vão propor nenhuma solução efetiva aos problemas de hoje. É importante saber reconhecer e separar o que são trabalhos intelectuais dos trabalhos braçais.
Por último, se o mercado nos força a oferecer nossos serviços como commodities, vamos nos adequar a esta realidade com propostas econômicas e que objetivam a satisfação do cliente.
Experimente um projeto ágil, você vai se surpreender.
Para Saber Mais
Agile Alliance (http://www.agilealliance.org)
The Project Management Life Cycle by Jason Westland
Textos escritos por David Anderson, Randy Miller, Clementino Mendonça e Scott Ambler
Treinamento de MSF + SCRUM + Agile Methods (http://www.fcamara.com.br)
Referências
Agile Software Development: The Cooperative Game by Alistair Cockburn;
Visual Studio Team System Rocks by Fábio Câmara, Clementino Mendonça e outros;
Extreme Programming by Vinícius Manhães Teles;
Modelagem Ágil by Scott Ambler;
Software Engineering with Microsoft Visual Studio Team System by Sam Guckenheimer;
Rapid Development by Steve McConnell;
Code Complete, 2nd Edition by Steve McConnell.
(Artigonal SC #337079)
Todos nós notamos que atualmente o mercado não está mais tão disposto a pagar por qualidade quanto a quinze anos atrás. Na verdade o cliente exige a qualidade a baixo custo, exige que o fornecedor conheça seu negócio e o negócio do seu cliente, exige que a solução, serviço ou produto a ser entregue seja aderente, flexível, robusto e estável. Os tempos são outros, a concorrência aumenta e os modelos de gestão por projetos em alguns mercados se consolida a cada dia como a solução para atingir(...)
Pergunto: A vida então, poderá existir sem projetos? Considero “Projetos de Vida” todo o plano, idéia, sonho ou evento, que possa se tornar realidade, em algum momento de nossas vidas, seja um simples churrasco para os amigos, a redação de um livro, a reforma ou a compra de sua casa, uma viagem para conhecer todos os países do mundo, a realização de um evento ou ainda, o projeto para a edificação de um gigantesco complexo turístico a ser construído na Lua, por exemplo, entre outros tantos...
Este artigo visa analisar as possíveis relações entre as ocorrências de situações de vida, em metas pessoais projetadas e, a possibilidade de ferramentas de gerenciamento de projetos, estabelecidas pelo Guia PMBoK 2004, serem eficazes no tratamento de riscos e apoio à decisões de mudanças que este projeto pode exigir, bem como propor técnicas para identificar e gerir tais processos.
A cultura de projetos está cada vez mais disseminada nas organizações. Os projetos têm diferentes finalidades, sendo que alguns visam reduzir os custos de recursos humanos. Isto, implica em demissões. A pergunta que se faz é: "como gerenciar projetos que envolvem demissão"?".
O Escritório de Gerenciamento de Projetos tem a função de acordo com as politicas e procedimentos da organização, podem ser: suporte para os gerentes de projeto, área estratégica ou unidade de centralização de conhecimento de projetos. A implantação de um escritório de projetos pode ser baseada nas áreas de conhecimento do PMI, como: escopo de trabalho, recursos necessários e a qualidade exigida pelas regras estabelecidas.
Resumo Projetos de engenharia/CAD sempre apresentaram a necessidade do armazenamento de vários estados (versões) dos objetos (documentos de projeto) em tempos distintos. Um projetista precisa experimentar diferentes versões de um projeto até atingir um estado consistente e satisfatório. Tais projetos se caracterizam por possuírem estruturas complexas, coordenadas por grupos de projetistas em ambientes de cooperação. A documentação dos passos de projetos é um recurso fundamental
PMI é a sigla em inglês para Instituto de Gerenciamento de Projetos. Trata-se de uma organização internacional com sede nos Estados Unidos voltada para melhorar o desempenho de profissionais nessa área. O método tem recebido cada vez mais aceitação por parte de empresas nacionais.
* Local de entrega * Definição de preços * Termo de pagamento * Garantia * Suporte ao produto * Seguros * Incentivos * Penalidades * Papéis e responsabilidade * Declaração de trabalho da entregas * Linha base do cronograma * Limitação de responsabilidade * Relatórios de desempenho * Remunerações e retenções * Período de desempenho * Local de desempenho do Fornecedor * Aprovação de subcontratadas * Solicitações de mudanças
A ética permeia as áreas do conhecimento do PMBOK - Project Management Body of Knowledge. Assim, o Código de Ética e de Conduta Profissional do PMI é um documento específico que norteia as obrigações básicas de um gerente de projetos quanto à responsabilidade, respeito, justiça e honestidade. Se o aceite ao código é requisito para a obtenção do certificado PMP (do PMI, o seu cumprimento é requisito para o exercício pleno da profissão de gerente de projetos e para se ter a consciência tranquila!
A consultoria empresarial é uma atividade que cresce cada vez mais no mercado mundial e nacional. Será que voc6e também precisa dela?
O mercado está repleto de opções para software de gestão. São tantas, que as vezes fica mais difícil decidir qual é o melhor software do que qual é a melhor empresa.
A gerência de projetos atribui baixa prioridade para a área de comunicação na fase de planejamento de um projeto, porém, isto a transforma em uma das áreas com maior quantidade de problemas na execução do projeto. Para endereçar esta característica dever-se-ia elaborar um efetivo Plano de Comunicação no projeto, monitorando-o durante sua execução.
A cada dia, as exigências para o gerenciamento de projetos se sofistica em termos de habilidades, competências e ferramentas. Assim, o gerente de projetos além de conhecer as boas práticas contidas no PMBOK do PMI, deve sim assumir uma postura de profissional reflexivo, pesquisador e crítico.
A organização está inserida num meio ao qual condiciona de diversas maneiras (através de sua produção, através das pautas culturais que impõe aos indivíduos que a integram, que por outro lado também integram o meio, etc.) . Mas por outro lado, as características da organização são em parte produto do meio que a condiciona. Produz para a sociedade, mas ao mesmo tempo é produzida por ela.
De forma indiscutível, o gerenciamento dos Recursos Humanos é um item fundamental no projeto, uma vez que são as pessoas que 'fazem as coisas acontecerem'. Como estimular e incentivar as equipes, para que se motivem?
Os indicadores de projetos, além de monitorar o desempenho de um dado projeto, indicam tendências futuras caso a situação permaneça inalterada no projeto. Embora os indicadores não mostrem quais são os problemas existentes, a sinalização evidenciada pelos indicadores aliada à análise de causa-raiz na dimensão analisada (custo, prazos, qualidade, satisfação do usuário dentre outras) permitirá a identificação dos problemas para posterior tomada de decisão e implantação de plano de ação corretivo.
Em 2008 deixe um projeto ágil mudar seus resultados. Se você conseguir se livrar dos racismos sem fundamentos técnicos e permitir a revisão de seus próprios paradigmas, verificará na prática uma nova realidade de satisfação de clientes de projetos de software.
