O Caso Abu Dhabi – Usuário Negligenciado

Bem amigos do blog QualidadeBR!

No último domingo, tivemos o encerramento da eletrizante temporada 2009 da F1. E o desfecho do campeonato ocorreu no mais novo circuito da temporada o Yas Marina, localizado no maior emirado dos Emirados Árabes Unidos, Abu Dhabi.

O intuito do post é fazer um breve estudo de caso, de algo que ocorreu na construção do circuito e que também ocorre em projetos de software.

Para começar o estudo de caso do circuito de Abu Dhabi, é preciso antes falar sobre o seu projeto, que custou a bagatela de 1,322 bilhões de dólares (segundo a Wikipedia).

A construção do circuito teve início em fevereiro de 2007, com o “modesto” desafio de construir um dos mais modernos circuitos da F1 no meio do deserto. Alguns números da “singela” construção:

• Uma força de trabalho de 14.000 homens;
• 35 milhões de hora-homem investidos;
• 1,6 milhão de metros cúbicos de terra foram deslocados;
• 720 mil metros quadrados de asfalto;
• 25 quilômetros de cabeamento elétrico;
• 5 mil árvores plantadas;
• 430 mil metros quadrados de terreno foram ajardinados;
• 40 quilômetros de blocos instalados;
• Um hótel 5 estrelas foi construído no meio do circuito.

Ou seja, um construção daquelas que costumamos ver no programa Mega Construções do Discovery Channel.

E como todo projeto, há objetivos a serem alcançados ao término:

• Construir um circuito moderno e de acordo com as novas premissas estabelecidas pela FIA;
• Suportar um grande público e oferecer conforto ao mesmo;
• Uma boa iluminação que permita a realização de corridas noturnas;
• Encerrar o projeto em 2009, antes das inspeções da FIA para o grande prêmio de Abu Dhabi de F1.

Bem, esses são alguns objetivos que eu acredito que poderiam medir o nível de sucesso do projeto do circuito de Yas Marine. Abaixo, segue uma galeria de fotos, que mostra o circuito desde o início da construção até o término.

E além daqueles objetivos que citei, em uma reportagem divulgada no site PlanetF1, Richard Cregan, o administrador do circuito, revelou que os stakeholders do projeto esperavam algo incrível.

Portanto, de acordo com os objetivos citados e a expectativa dos stakeholders o projeto foi um sucesso, afinal o circuito ficou pronto no tempo e com certeza impressionou os stakeholders, dentre eles a FIA.

Eu mesmo comentei no twitter, após assistir os melhores momentos da classificação, que o circuito é fabuloso, nos faz perceber o quanto evoluímos em termos de construções, fazer um circuito daquele em pouco mais de 2 anos é um feito muito impressionante mesmo.

Porém…

Acho que faltou a opinião de alguém na história, não faltou?

Faltou “só” a opinião dos pilotos e dos espectadores.

Pelo que li pela internet e ouvi na narração da corrida, todos os pilotos ficaram impressionados com o circuito, porém poucos ficaram impressionados com o desafio que o circuito proporciona, tanto que o Rubinho disse que o ponto mais perigoso da pista é o túnel da saída do pit-stops, ou seja, pelo visto não é um circuito muito desafiador, até porque, se o piloto escapar em alguma curva, ele terá uma boa área de escape asfaltada para retornar a pista, o que vai causar apenas uma perda de tempo.

Como espectador, achei a pista bem sem graça, quase não há pontos de ultrapassagens, o que resultou numa corrida bem monótona.

Acredito que os stakeholders se esqueceram de dois ingredientes essenciais para uma corrida de F1: o desafio e ultrapassagens. Afinal, a ultrapassagem está para a F1, assim, como o gol está para o futebol.

E na lista de stakeholders da construção do circuito, acho que não foram incluídos os pilotos. (fail)

O ponto que quero chegar

O que ocorreu no projeto do circuito Yas Marina é algo que também ocorre em projetos de TI: a negligência em relação aos usuários.

Os projetos nascem e morrem de acordo com os interesses dos envolvidos, até aí tudo bem. O grande problema é quando esses interesses não incluem os interesses dos reais usuários do fruto daquele projeto. Quem participa do mundo da gerência de projetos ou já teve algum contato, sabe que nem sempre, o cliente será o usuário daquele determinado produto a ser desenvolvido, portanto o cliente tem um papel primordial de representar os usuários. Porém, nem sempre o cliente tem pleno conhecimento sobre o que os usuários esperam daquela determinada solução.

Algo que ocorre com uma certa frequência incômoda em projetos de software, é que eles não são centrados no usuário,  muitas vezes os usuários só terão contato com o sistema após o término do mesmo. E isso deve-se há vários motivos, dentre os quais um muito estranho é o medo do pessoal de TI de se envolver com os usuários, pois eles tem em mente que se forem conversar com os usuários eles irão pedir mais uma “trocentas” mudanças, e mudanças para esses profissionais é algo muito ruim. Afinal das contas, os interesses deles, às vezes se limitam em apenas obter o melhor ROI, e que se dane que a solução desenvolvida não solucione nada, seja difícil de utilizar, e que ainda tenha vários bugs. Para esses “profissionais” isso é até melhor, pois assim eles irão ganhar dando treinamentos e novos contratos de manutenção irão surgir. Ou seja, uma maneira de desenvolver software a lá Dick Vigarista e seguindo a Lei de Gérson, e que a médio e longo prazo não traz nem mais retorno financeiro, já que a fama da empresa já terá se espalhado entre os clientes.

Um outro ponto interessante de se comparar a construção do circuito de Yas Marina com a construção de um software, é que às vezes nós acabamos fazendo o mesmo que a FIA fez, burocratizar e criar padrões demais, e o mais preocupante, padrões fora do contexto da realidade, como por exemplo, criar circuitos que dificultem as ultrapassagens. Por isso, que é bom de vez em quando tirar a cabeça do prato. 😉

Lembre-se que a qualidade é uma questão de ponto de vista, e no desenvolvimento de software o ponto de vista mais importante é o do usuário.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

http://en.wikipedia.org/wiki/Yas_Marina_Circuit

http://www.itv-f1.com/Feature.aspx?Type=General&id=47272

http://www.planet-f1.com/story/0,18954,3213_5658598,00.html

Imagens:

http://www.architecturelist.com/wp-content/uploads/2009/05/yashotel-asymtote.jpg

http://www.ameinfo.com/images/news/1/80441-YasMarina.jpg

http://www.bustler.net/images/uploads/asymptote_yas_hotel_06x.jpg

http://www.thenational.ae/apps/pbcsi.dll/bilde?Site=AD&Date=20090918&Category=NATIONAL&ArtNo=709179849&Ref=AR

 

3P – Piores Práticas de Projeto (parte 2)

Continuamos falando sobre as piores práticas de projeto, mais uma vez com o intuito de alertar e prevenir tais práticas:

Telefone sem fio – a comunicação é essencial não apenas para a sobrevivência do ser humano, mas como também para a dos projetos. Portanto, devemos estar sempre nos perguntando se a informação está sendo gerada, coletada, documentada e passada para a pessoa certa. Segundo o PMI há quatro processos de gerenciamento das comunicações:

• Planejamento das comunicações – determinação das necessidades  de informações e comunicações das partes interessadas no projeto.
• Distribuição das informações – colocação das informações necessárias à disposição das partes interessadas no projeto no momento adequado.
• Relatório de desempenho – coleta e distribuição das informações sobre o desempenho. Isso inclui o relatório de andamento, medição do progresso e previsão.
• Gerenciar  as partes interessadas – gerenciamento das  comunicações para satisfazer os  requisitos das partes  interessadas no projeto  e resolver problemas com elas.

Eu quero eu posso – Essa é uma prática muito natural, sempre achamos que basta querer para poder realizar ou obter algo. Em projetos devemos avaliar o quanto de esforço que ele demandará e se o time está preparado, caso contrário o projeto terá grandes chances de sofrer atrasos, aumento de custo ou até fracassar. Um exemplo dessa prática foi o Pan de 2007, o maior evento poliesportivo já realizado no país, onde devido a falta de preparo dos realizadores e a problemas políticos o orçamento final ficou 1.289% a mais do que estava previsto inicialmente.

Excesso de documentação – documentação é um dos fantasmas em projetos de TI, isso porque o bom senso muitas vezes não é usado. E quando a equipe do projeto tem grande preocupação em documentar ou a metodologia usada tem como base a geração de documentos para tudo, um risco que aparece é o excesso de documentação, onde podemos ainda estar realizando a análise de risco e o prazo do projeto já ter acabado. Uma das medidas para evitar tal prática é sempre averiguar a importância que a documentação terá para o projeto e o que será documentado e o que não será. Lembrando que mais importante do que documentação gerada é software funcionando.

‘Achômetro’ – por último umas das práticas mais utilizadas não somente em projetos de TI, mas como também na nossa vida. Afinal, o ‘achômetro’ tem como base o conselho que segundo o texto de Mary Schmich, que foi transformado em um discurso musicado por Pedro Bial com o nome Filtro Solar:

Conselho é uma forma de nostalgia. Compartilhar conselhos é um jeito de pescar o passado do lixo, esfregá-lo, repintar as partes feias e reciclar tudo por mais do que vale. (“Advice, like youth, probably just wasted on the young”- Mary Schmich)

Devemos usar o ‘achômetro’ somente em momentos que realmente não teríamos como obter um histórico de dados, como por exemplo, no primeiro projeto de uma recém criada empresa. Sempre que possível, precisamos justificar as nossas ações e estratégias com base em informações e não na opinião própria ou de outras pessoas.

Aqui chego ao fim das 3P, mas com certeza há ainda muitas piores práticas de projetos que não foram citadas. Por isso, caso alguém queira colocar alguma prática que vivenciou ou conhece, por favor sinta-se à vontade. O seu comentário será bem-vindo!

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK); Terceira edição, 2004. Project Management Institute, Four Compus Boulevard, Newton Square, PA 19073-3299 EUA.

http://www1.folha.uol.com.br/folha/esporte/ult92u450247.shtml

3P – Piores Práticas de Projeto (parte 1)

Melhores Práticas de Projeto é um dos temas que mais vem ganhando espaço no mundo de TI, pois percebemos que um bom gerenciamento é fundamental para o sucesso do projeto. Mas se temos as melhores práticas, quais seriam as piores práticas?

Abaixo explico algumas das piores práticas de projeto (3P) que devemos tomar cuidado para não cometemos:

Não envolvimento dos stakeholders – Por mais absurdo que possa parecer, essa é uma das práticas que mais acontecem, na qual um ou mais stakeholders (envolvidos com o projeto) não participam ativamente do projeto, ou participam apenas no início, ocasionando vários problemas, como requisitos mal especificados. Este é uns dos problemas que afetam diretamente o prazo e custo do projeto e em determinados casos, pode até representar o fim de um projeto. Um exemplo de não envolvimento dos stakeholders aconteceu com o projeto do Rodoanel, onde grupos ambientais não foram colocados como stakeholders no início do projeto, e esses acabaram gerando impasses para o governo, resultando em grandes atrasos nas obras e aumento do custo.

Contratação de funcionários, quando o projeto está atrasado –  No desespero, muitos gerentes acabam contratando novos funcionários, quando o prazo do projeto já está com seu prazo vencendo, pois acreditam na teoria de quanto mais pessoas mais produtividade. Porém, na prática a história é outra, esse novo funcionário, por mais habilidoso e experiente que seja, terá que receber um treinamento a ser dado por um funcionário, portanto o projeto perderá um funcionário ao invés de ganhar um. Para entender melhor, seria como você contratar um novo jogador de futebol faltando cinco rodadas para o término do campeonato, por mais habilidoso que ele seja, ele terá o seu tempo de adaptação e se ele for colocado em campo, o desentrosamento pode prejudicar o time.

Falta de documentação – essa é umas práticas mais adotadas pelas empresas, por parecer a curto prazo uma boa prática, pois economizará tempo. Porém, a longo prazo ela pode fazer com que o projeto seja o caos. Imagine a seguinte situação: na empresa XPTO Zé é  programador sênior e responsável por um módulo crítico da aplicação, porém não costuma documentar nada que faz, nem ao menos comenta o código. Um certo dia, Zé consegue um emprego melhor e sai da XPTO. E agora como o projeto continuará sem o Zé? Ele era o único que tinha conhecimento sobre aquele módulo e sem esse módulo o projeto não poderá ser entregue.

É pessoal, vocês podem estarem achando que tal situação apresentada não acontece nas empresas, mas por mais incrível que pareça essa é uma das que mais acontece e que faz muitos dos gerentes “arrancarem os cabelos” (quando ainda tem). Por isso o projeto tem que ser documentado e bem documentado.

Documentar no final – Não sei o que é pior, não documentar ou documentar no final do projeto. Uma documentação feita no final do projeto, por mais esforço que se faça, será fraca e imprecisa e a razão para isso é simples, as pessoas acabam esquecendo o que elas fazem. Para exemplificar uma pergunta clássica: o que você comeu ontem no almoço?

Talvez, você até se lembre do que você comeu ontem, mas e antes de ontem, e na semana passada?

Se eu fosse pedir para você me fazer uma documentação do seu almoço por um mês, ela teria que ser feita antes do almoço, onde você colocaria qual o restaurante que você vai almoçar, qual será o pedido, etc; durante o almoço, situação em que você falaria sobre a qualidade da comida escolhida; e após o término do almoço, você iria descrever como foi o atendimento e quanto custou o almoço.

Logo percebemos que a documentação é uma tarefa que tem que ser feita, durante todo o projeto e não somente durante uma determinada etapa do projeto.

Bem pessoal, por hoje é só. Em breve trarei a segunda parte do 3P. Até a próxima!

Fique por dentro das novidades, assine o feed do QualidadeBR.