Gerente X Capataz

A motivação desse post ocorreu após assistir o vídeo do “Funk da Gerência” (será mais um hit do verão 2010, junto com o “Funk do Anel” rs) nesse excelente post do Rodrigo Panachi.

Pela minha experiência, a analogia do capataz não se encaixa muito quando analisamos bons gerentes. Eu prefiro mais a analogia dos gerentes como os donatários das capitanias hereditárias, afinal segundo a Wikipédia o donatário “constituía-se na autoridade máxima dentro da própria capitania, tendo o compromisso de desenvolvê-la com recursos próprios, embora não fosse o seu proprietário”, ou seja, bem próximo da realidade de um gerente.

Gerenciar não é só sobre controlar pessoas, até porque o modelo de comando-controle já está em declínio na área de TI, principalmente devido a explosão do Scrum nesse ano, ser gerente é saber lidar com as pessoas, saber negociar, liderar, pensar, agir, inspirar, motivar e a lista é longa.

Não é fácil ser gerente, e uma prova disso é que a maioria das pessoas no mundo não são nem gerentes das suas próprias vidas, quanto mais um dia terão capacidades de gerenciar uma área de Teste de Software, por exemplo.

O que leva a pensar que gerentes são meros capatazes é que ainda há MUITOS gerentes capatazes, e o pior é que muitas vezes tais gerentes pensam que são o dono da empresa, eles se iludem com as cifras que caem todo o mês na sua conta bancária, acham que são intocáveis e ainda pensam que chegaram no apíce de suas carreiras  e por isso param no tempo. E tais gerentes não são bons nem para a empresa em si, quanto mais para os seus subordinados.

Portanto, gerentes de plantão e aspirantes tomem cuidado para não serem capatazes. Busquem serem líderes, desenvolver o seu time, ser um intraempreendedor, ter uma excelente relação com os clientes, não parem de aprender e evoluir e entendam a sua empresa e o mercado.

Pra encerrar, segue o vídeo na íntegra da participação do Waldez Ludwig no programa Sem Censura, recomendo: 😉

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

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

 

O caos aumentou!?

A gerência de um projeto está preocupada com várias variáveis, características, fatores, etc que podem influenciar o sucesso do projeto. E quando falamos em variáveis, três se destacam, formando o “triângulo da gerência de projeto”.

Escopo – são as especificações do projeto, o que será desenvolvido e o que não será.

Tempo – período no qual o projeto será desenvolvido até a sua entrega final.

Custo – montante de recursos financeiros a serem investidos para que o projeto possa ser desenvolvido e mantido durante o tempo definido.

Dentre as três, o escopo é a variável principal, pois exerce grande influência sobre o tempo e o custo do projeto.

Escopo maior = tempo maior = custo maior

Escopo menor = tempo menor = custo menor

Um dos objetivos do gerente de projeto é justamente deixar esse triângulo equilibrado, monitorando e controlando cada uma dessas variáveis ao longo do projeto.

No mundo ideal

• O escopo não muda durante o tempo do projeto;
• O trabalho é previsível;
• Não há riscos que afetam o tempo e custo do projeto;
• Todas as atividades são executadas de acordo com o planejamento realizado, respeitando o tempo e o custo.

No mundo real

• O sucesso de um projeto é algo raro:
  • 32% sucesso (no prazo, dentro do orçamento e com escopo completo);
  • 44% mudaram (atrasaram, estourou o orçamento, e/ou reduziram escopo);
  • 24% falharam (cancelados ou nunca usados).
• Quanto maior o tempo do projeto, maior serão as mudanças que ocorrerão no escopo;
• O trabalho não é previsível;
• Existem riscos que podem impactar fortemente o tempo e custo do projeto.

Eu particularmente, fiquei impressionado (negativamente) com o resultado de 2009 que o famoso Chaos Report trouxe (tanto, que estou achando que ele virou anacrônico). Esperava que o resultado fosse o oposto, que a quantidade de projetos com sucesso tivesse aumentado e dos que falharam diminuído.

O Chaos Report prova que ainda estamos lidando de forma equivocada com a gerência e desenvolvimento de projetos de software. E muitos ainda estão acreditando que desenvolvem software no mundo ideal.

E há diversas medidas que podem ser tomadas para tentar melhorar esses resultados, dentre as quais, uma de extrema importância é a maneira que realizamos o contrato. Mas esse é assunto para um próximo post. 😉 Até lá!

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

Fonte:

http://blogs.msdn.com/andredias/archive/2009/07/08/chaos-report-2009-novas-informa-es-velhos-problemas.aspx

Scrum

Há muito tempo, estava querendo fazer um post sobre Scrum. Mas só agora realmente, tomei iniciativa em fazê-lo.

Falar sobre Scrum é algo fácil e ao mesmo tempo difícil. Fácil por ser algo simples, e é difícil, pois há muitas outras pessoas falando sobre ele, então a chance de fazer um “post papagaio” é grande. E quando falo de muitas outras pessoas falando sobre Scrum, não é apenas quantidade e sim muita qualidade. E isso é um ponto muito forte, que vejo do Scrum, ele é muito vivo! As pessoas pesquisam, discutem, “blogam”, etc sobre Scrum.

O intuito desse post é passar algumas opiniões que tenho sobre Scrum, e também “papagaiar” um pouco sobre ele, afinal para muitos ele é ainda apenas mais um buzzword. Espero que gostem, qualquer coisa só “cornetar”, ou melhor, comentar. 🙂

Mas afinal o que é Scrum?

Vou primeiro colocar a definição que entendo como a melhor, do Ken Schwaber, um dos criadores do Scrum, e depois colocar uma definição pessoal:

“Um processo Ágil ou ainda um framework para gerenciamento de projetos Ágeis. É um processo de gerência de projetos, certamente não é uma metodologia, pois isto seria pesado demais.” (Ken Schwaber)

Scrum são boas práticas para gerenciar projetos de forma a otimizar o ambiente de trabalho, motivar as pessoas e satisfazer as reais necessidades do cliente. (Fabrício Ferrari de Campos)

Mas por favor, não se apegue muito as definições, o importante é conhecer as práticas e conceitos que o Scrum traz e os benefícios que podemos ter aplicando-os na nossa empresa.

As características principais do Scrum são:

• Ágil;
• Empírico;
• Incremental;
• Iterativo.

Mas o que significa a sigla Scrum?

Que sigla?… Não, não. Scrum não é uma sigla, é o nome de um tipo de jogada que acontece no jogo de rugby para retornar a bola,  onde é necessário a participação de todos os jogadores. Se um falhar, todos falham. Por isso que você ver uma imagem parecida com essa abaixo, em vários posts sobre Scrum (e não poderia ser diferente nesse…rsrs).

Quem é quem no Scrum?

O Scrum organiza de forma diferente os papéis existentes num projeto:

• Scrum Master: Remove os impedimentos, garante o uso do Scrum e protege o time de interferências externas. Líder colaborador!
• Product Owner (PO): Preocupado com o ROI, se voltará dinheiro para o bolso do cliente, conhece as necessidades do cliente, funciona como proxy em ambientes com mais de um cliente. Gerencia a visão e a entrega!
• Time: Formado geralmente por 4 ou 5 pessoas e multidisciplinar. Ele define metas das iterações, auto-gerenciado e produz produto com qualidade e valor para o cliente. Gerencia a sprint de desenvolvimento.

Como é o processo do Scrum?

Só clicar na imagem para vê-la ampliada.

Como você pode ter percebido, o Scrum tem um processo bem definido e neste ponto ele é rígido, até pelo fato dele determina poucas coisas (tanto que consegui ilustrar num único desenho), mas o que determina você tem que seguir. Por isso, é rígido.

Vantagens e Desvantagens

Como é de praxe ao conhecer algo novo, sempre buscamos saber quais são as vantagens e desvantagens, portanto, segue abaixo as principais vantagens e desvantagens do Scrum:

• Vantagens
  • Os papéis são bem definidos, todos têm conhecimento sobre as suas responsabilidades;
  • É um processo ágil e flexível, tornando melhor a reação as mudanças que ocorrem durante o projeto;
  • É focado no controle e gerenciamento, buscando minimizar os riscos e maximizar a qualidade;
  • Os times são pequenos, a comunicação é mais eficiente;
  • Espírito colaborativo.
• Desvantagens
  • Ausência de práticas de Engenharia de Software, pois é voltada para o gerenciamento do projeto;
  • Necessita a associação de uma outra metodologia de Engenharia de Software, por exemplo XP;
  • É difícil de ser implementada, principalmente devido a resistência de mudanças culturais.

As duas primeiras desvantagens poderiam até ser desconsideradas, pois Scrum é voltado para a gerência de projetos e não para o desenvolvimento.

Scrum é mais uma modinha? Ou veio para ficar?

Acredito que a resposta depende muito da perspectiva que a pessoa tem, pois olhando de fora parece sim mais uma modinha, assim como ocorreu com o PMBOK. Sendo simplista a pessoa poderia até pensar que é apenas mais uma metodologia que tenta ser melhor do que as demais. Porém, para quem tem uma visão interna, que está realmente envolvido com o dia-a-dia do projeto, Scrum veio para ficar sim, ou melhor, os seus valores vieram para ficar.

Daí você pode está se perguntando, mas que valores são esses?

• Transparência;
• Ser empírico;
• Auto-organização;
• Integridade;
• Entrega de valor.

Além disso, o Scrum também tem como base os princípios ágeis do manifesto ágil:

• Indivíduos e iteração entre eles mais que processos e ferramentas.
• Produto em funcionamento mais que documentação abrangente.
• Colaboração com o cliente mais que negociação de contratos.
• Responder a mudanças mais que seguir um plano.

Nossa! Então Scrum é a famosa bala de prata!? Irá resolver todos os meus problemas?

Eu particularmente, sou bastante cético quando alguém fala que tal metodologia, framework, etc irá garantir o sucesso do seu projeto de desenvolvimento de software. Por isso, minha opinião é a mesma com Scrum.

Para mim ele é muito bom! Dentre os conhecimentos que temos sobre metodologias e afins na empresa em que trabalho, é o que melhor se encaixou a nossa realidade e o que trouxe mais melhorias.

Mas voltando a pergunta original do tópico, ele não irá resolver todos os seus problemas, pelo contrário, ele irá torná-los mais visíveis, e esse é um ponto que acho incrível. Pois se algo não estiver indo bem todos irão perceber bem rápido. Aliás uma das ferramentas que o Scrum traz  e que ajuda na visualização do andamento do projeto é o gráfico Burndown.

Qualquer pessoa, consegue identificar pelo gráfico acima, que a quantidade de testes automatizados esperada para o sprint 1 não foi alcançada. Eu poderia listar uma série de causas que fez com que o objetivo não fosse alcançado, afinal o gráfico apresenta um cenário real. Mas não é esse o intuito do post.

Portanto, precisamos nos lembrar que a metodologia em si não irá resolver os problemas, mas sim, poderá nos ajudar. Quem resolve os problemas são as pessoas!!!

Scrum é fácil de ser implantado?

Se fosse fácil qualquer um faria!

Há uma série de obstáculos que fazem com que a implantação do Scrum não seja uma missão fácil, entre eles:

• Não tem como você exigir que haja auto-gestão na sua equipe se ela não é uma característica dos membros da equipe;
• Implantar numa equipe grande demais (mais de 5 pessoas, por exemplo);
• O seu cliente não tem o menor interesse de cooperar. Ele é parecido com uma criança mimada que só quer e ainda bate o pé;
• O único comprometimento que os membros da sua equipe tem, é em relação ao salário deles.

Mas me diga uma coisa, alguém já disse para você que desenvolvimento de software é fácil?

É para todos os obstáculos apresentados há uma ou mais soluções:

• Treine a sua equipe, uma das maiores capacidades do ser humano é da aprendizagem, portanto incentive o seu uso;
• Divida a sua equipe, “modularize” melhor o sistema;
• Converse com o seu cliente, explique que a cooperação dele é fundamental para o sucesso do projeto;
• Motive a sua equipe, mostre que o que ela faz não é apenas garantir a própria sobrevivência.

Portanto, temos que está sempre preparados para superar os obstáculos, transformando-os em motivação. Afinal seria muito chato se você chegasse no trabalho e fizesse sempre o mesmo trabalhinho sem a menor dificuldade. 😉

Última pergunta. Por que falam tanto sobre Scrum?

No meu entender são dois motivos principais:

• Scrum está dando certo na empresas;
• As pessoas gostam de trabalhar com Scrum.

Quando você faz alguma coisa é dá certo, qual é a sua reação? Conta para outras pessoas, não é!? E irá contar para mais pessoas ainda quando você gosta do que está fazendo. Eu mesmo, falo sobre Teste e Qualidade de Software porque gosto, simples assim. E estou agora falando sobre Scrum pelo mesmo motivo. 🙂

Mas por favor, não interprete errado a minha simples pesquisa, não estou falando que usar as práticas do PMBOK não dá certo, ou coisas do gênero.

Minha intenção é que esse seja o primeiro de muitos posts sobre Scrum, afinal esse foi mais um bombardeio de informações. Até mais!

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

Fonte:

Você sabe o que é Scrum? – Nelson Abu

Scrum é um framework? – Luiz Claudio Parzianello

Scrum Gathering 2009 – Primeiro dia – Parte 2 – André Pantalião

SCRUM Processo de Desenvolvimento de Software – Dra. Eliane Martins (UNICAMP)

Magno, A. Apresentação do curso Certified Scrum Master (CSM). São Paulo, Caelum, 2008.

Imagens:

Formação do Scrum – Faculdade Oberlin

Define metas das iterações, auto-gerenciado e produz produto com qualidade e valor para o cliente. Gerencia a sprint de desenvolvimento.

Riscos!? Que riscos?

Riscos é um assunto que deixa muitos incomodados, afinal muitas vezes, principalmente em projetos de software, ele é visto como algo negativo, um empecilho que pode ocorrer e diminuir as chances de sucesso do projeto.

E o perigo maior está quando não identificamos o risco, e o impacto dele pode comprometer todo o projeto. Fazendo uma analogia, seria como você descobrir que o botijão de gás está vazando ao ligar a lâmpada, ou seja, tarde demais… BOOMM!!!

Assustador não é?

Por isso, o gerenciamento de riscos é algo muito importante no seu projeto. A seguir, irei falar um pouco sobre ele, espero que gostem e que possa ser útil. 🙂

De onde vem os riscos?

no Futuro … que pode ser duvidoso e nos forçar a mudanças…

nas Mudanças … que podem ser inúmeras e nos forçam a decisões…

nas Decisões … que podem não ser as mais corretas…

• Do futuro: que pode ser duvidoso e nos forçar a mudanças;
• Das mudanças: que podem ser inúmeras e nos forçam a decisões;
• Das decisões: que podem não ser as mais corretas.

Riscos em Engenharia de Software

• Do futuro: do ambiente interno e externo, mercado, tecnologia, economia, governo, etc;
• Das mudanças: do ambiente, dos requisitos dos clientes, em ambientes tecnológicos, equipamentos, política econômica e tecnológica, leis e programas de apoio a P&D, orçamentos., etc;
• Das decisões: O que produzir? Com que métodos e ferramentas? Com que equipe? Com que nível de qualidade? Com qual orçamento? etc.

O processo de gerenciamento de riscos

Sendo o gerenciamento de riscos um conjunto de técnicas e ferramentas para identificar, estimar, avaliar, monitorar e administrar os acontecimentos que colocam em risco a execução do projeto. Podemos ilustrar o processo de gerenciamento de riscos, proposto pelo PMBOK, da seguinte maneira:

• Planejamento do gerenciamento de riscos – decisão de como abordar, planejar e executar as atividades de gerenciamento de riscos de um projeto;
• Identificação de riscos – determinação dos riscos que podem afetar o projeto e documentação de suas características;
• Análise qualitativa de riscos – priorização  dos riscos para análise ou  ação adicional subsequente  através de avaliação  e combinação de sua probabilidade de ocorrência e impacto;
• Análise quantitativa de riscos – análise numérica do efeito dos riscos identificados nos objetivos gerais do projeto;
• Planejamento de respostas a riscos – desenvolvimento de opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto;
• Monitoramento e controle de riscos – acompanhamento dos riscos identificados, monitoramento dos riscos residuais, identificação dos novos riscos, execução de planos de respostas  a riscos  e avaliação  da sua eficácia durante todo o ciclo de vida do projeto.

Ao meu entender, as quatro primeiras etapas compõem a análise de riscos, que é algo de extrema importância para qualquer projeto, independente da sua natureza.

E para o nosso mundo de desenvolvimento de software a análise de riscos é essencial, pois o nosso projeto está sempre rondado de riscos, e precisamos estar atentos a eles.

É importante lembrar que o objetivo do gerenciamento de riscos é aumentar a probabilidade e o impacto dos eventos positivos e diminuir a probabilidade e o impacto dos eventos adversos ao projeto.

Tem como garantir que nenhum risco irá afetar o meu projeto?

Não. Infelizmente não tem como garantir que os riscos não irão causar impacto no seu projeto. Mas calma, nem tudo está perdido. Podemos utilizar três estratégias para lidar com os riscos e diminuir a probabilidade deles ocorrerem:

1. Prevenir: como já diz aquele velho e bom ditado popular “prevenir é o melhor remédio”, e no gerenciamento dos riscos essa é a melhor ação que podemos executar. Muitas vezes precisamos realizar mudanças no plano do projeto para eliminar a ameaça que um risco pode apresentar. Podemos também isolar os objetivos do projeto do impacto que o risco pode oferecer ou ainda flexibilizar o objetivo que está sendo ameaçado pelo risco;
2. Transferir: essa é uma ação que não elimina o risco, e sim passa o gerenciamento dele para um terceiro. Por exemplo: você irá terceirizar uma determinada parte do seu sistema para outra empresa. Um dos riscos que você terá é do atraso da entrega dessa parte do sistema, e para tentar compensar o impacto que esse risco poderá ter para a sua empresa, você pode colocar no contrato uma multa em caso de atraso;
3. Mitigar: o foco da mitigação de riscos é a redução da probabilidade e/ou impacto de um risco até um limite aceitável. Um exemplo, seria a realização de TDD para diminuir a probabilidade e impacto do risco de falhas do sistema, já que aumentaria a qualidade do desenvolvimento do software.

O que pode acontecer se não houver uma análise dos riscos no meu projeto?

Como diria um professor meu: “coisas horríveis irão acontecer”.

A análise de riscos é fundamental para o gerenciamento de riscos e um fator chave para o sucesso do seu projeto. É uma maneira de agir proativamente diante dos riscos e é muito melhor do que agir de forma reativa, pois talvez dependendo do risco que não foi tratado e do impacto ocasionado por ele, poderá ser muito tarde para tomarmos alguma providência.

A análise de riscos pode ter algum impacto para a minha área de testes?

Sim, e se bem realizada poderá ser um impacto muito benéfico para a equipe de testes. Pois será mais uma fonte de consulta na hora da elaboração dos testes e ainda poderá ajudar na priorização da execução dos testes. Por exemplo: na análise de riscos de uma manutenção do software está descrito quais áreas poderão ser afetadas pela manutenção, ou seja, novos bugs poderão ser introduzidos nessas áreas. Sendo assim poderemos focar os testes de regressão primeiro nas áreas que tem maior chance de ter sido impactada e desta maneira, podemos encontrar a falha mais cedo = menos $$$ gasto com o bug.

Além do mais, sabemos que garantir que 100% do sistema não tem falhas é algo muito difícil e na maioria das vezes não viável. Portanto com a análise de riscos podemos garantir por exemplo, que 90% das falhas do sistema foram encontradas e que os outros 10% possam ser falhas de baixo impacto no sistema. Já sem uma análise de riscos poderíamos talvez, garantir que 99% das falhas foram encontras, mas daí o 1% que faltou pode ser uma falha crítica. Aí já sabe neh…

Sendo tão importante, por que às vezes a análise de riscos não é realizada?

Pois muitos preferem ficar na segurança e conforto da ignorância. Sabe aquelas pessoas que falam, nem precisa testar está funcionando. Então, uma das razões para essa pessoa falar isso é que ela sabe que se você for testar irá achar um monte de falhas que irá dá mais trabalho para ela.

Com os riscos o cenário é parecido. Se você for fazer uma análise de riscos, com certeza irá encontrar muitos riscos e ainda terá várias outras “razões” para evitar a  análise de riscos:

• Análise de Riscos “consome” tempo precioso dos membros da equipe do Projeto ;
• Análise de Riscos demonstra “ Análise de Riscos demonstra problemas que “só atrapalham”;
• Análise de Riscos tem tendência de “ Análise de Riscos tem tendência de trazer “más notícias”;
• Análise de Riscos pode levar a “ Análise de Riscos pode levar a situações “embaraçosas”;
• Análise de Riscos acelera a necessidade de levantar questões que, cedo ou tarde, deveriam ser percebidas pelo Cliente do Projeto.

Portanto, se você não quer ter nenhuma explosão no seu projeto, por favor, identifique, analise, administre e controle os seus riscos. Caso contrário, você um dia poderá ter uma surpresa desagradável ao chegar ao trabalho.

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.

www.inf.ufsc.br/~cybis/ine5617/Analise_riscos.ppt (Walter de Abreu Cybis)

www.pmimg.org.br/…/GestaoRiscosProjetos_LucioDiniz_31082004. (Lúcio J. Diniz)

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.

TRIZ – Teoria da Resolução de Problemas Inventivos

Pessoal, hoje vou falar sobre essa metodologia que se propõe a ajudar em algo que é muito comum em nosso dia a dia, os problemas.

Os problemas em uma organização de TI, geralmente são os geradores de conflitos, que podem ser entendidos como situações de oposição, desacordo ou incompatibilidade entre pelo menos duas pessoas ou grupos.

E podemos ter duas visões a respeito dos conflitos:

• Conservadora: Eles tendem a considerar os conflitos como indesejáveis. Sendo causados por pessoas problemáticas, que insistem em não ajustar-se e devem ser, sempre e assim que possível, suprimidos.
• Progressista: Os conflitos são encarados como inevitáveis. Se geridos com habilidade, podem ser muito benéficos, contribuir para o desenvolvimento das pessoas e organizações e revelar questões importantes, como, por exemplo, as falhas que uma determinada solução que estava para ser adotada continha.

Na área de Teste de Software estamos sempre descobrindo problemas e ao relatar tais, podemos acabar gerando conflitos, devido a existência de pontos de vista diferentes, por exemplo: a equipe de Teste percebeu uma inconsistência e falta de padrão na maneira de validação dos campos, que hora é feita com caixa de mensagens (message box)  e hora utilizando rótulos (labels)  e decide reportar tal problema para a equipe de desenvolvimento, que por sua vez entende que isso não é um problema, pois a validação é feita de acordo com cada formulário, podendo portanto ser diferente. Surgi assim um impasse, entre a equipe de Teste e a de Desenvolvimento, que dependendo dos grupos, só poderá se resolvido com a ação do gestor do projeto.

Quanto a resolução de conflitos há cinco possíveis abordagens:

1. Enfrentamento –  é o método mais utilizado pelos gestores de projeto. Envolve a cooperação franca no sentido de criar uma solução que satisfaça a todas as partes envolvidas (ganha-ganha).
2. Compromisso – quando o enfrentamento não funciona, costuma-se tentar o compromisso, onde as partes conflitantes barganham até chegar a uma solução aceitável por todas. Pode ser adequado quando há um impasse, todas as partes precisam ganhar alguma coisa e não há tempo.
3. Moderação – corresponde a acomodar ou favorecer. Busca-se desarmar o contexto emocional e focar no objetivo a ser atingido, mesmo que seja necessário uma das partes sacrificar suas próprias demandas para satisfazer as das outras partes.
4. Imposição – é um estilo competitivo, controlador ou dominador de resolver os conflitos. Podendo ser legítima, quando a situação é crítica, há muito em jogo, princípios importantes estão em risco, a relação entre as partes não é muito importante e uma resolução rápida é necessária.
5. Recuo – aqui tenta-se evitar completamente o conflito ou adiá-lo. Será uma solução temporária, porque o problema não é resolvido. Podendo ser uma opção quando não se poderia ganhar, acredita-se que o problema pode desaparecer por si só ou o atraso é, em si, um ganho.

Como vimos o método do enfrentamento é o mais utilizado e juntamente com ele podemos adotar a metodologia sistemática TRIZ (Teoria da Resolução de Problemas Inventivos), criada por G. S. Altshuller, um brilhante pensador de origem judaico-russa. Ela é orientada ao ser humano e baseada em conhecimento, para a resolução de problemas inventivos.

Pela TRIZ os conflitos são contradições, ou seja, declarações que afirmar coisas aparentemente incompatíveis ou opostas. Ela configura-se como a abstração, compilação e organização das melhores formas de resolver problemas na forma de estratégias e princípios. Isso aconteceu, primeiro, nas engenharias mais antigas (os primeiros estudos de Altshuller envolveram soluções da engenharia mecânica, civil, elétrica e química) e, atualmente, acontece em todas as áreas do conhecimento (publicidade, artes, pedagogia, administração, etc.).

O primeiro passo é a identificação das contradições, lembrando que quanto mais a contradição parecer impossível de resolver, melhor. Isso significa que o pano de fundo está posicionado para que não sejam facilmente aceitas as soluções de compromisso e, portanto, que cresce o potencial de chegar a solução verdadeiramente inventiva.

Após formular a contradição, necessitamos resolvê-la. A solução envolve quatro possibilidades, apontadas pelos princípios de separação: no espaço, no tempo, no sistema e conforme  a condição.

Para entender melhor, vamos utilizar essa metodologia para solucionar o seguinte problema:

A fábrica de software TXY é reconhecida por entregar os projetos no tempo hábil, porém há um projeto que está com atraso e a gerência de projeto já está preocupada com tal atraso e para tentar evitá-lo, foi decidido o encerramento dos testes prematuramente. No entanto a equipe de Testes está relutante a essa decisão e se justifica dizendo que o encerramento prematuro dos testes trará como  conseqüência uma maior necessidade de manutenção do sistema o que custará muito mais caro para a empresa, portanto percebeu-se que o encerramento dos testes prematuramente resultará em mais custos no futuro.

No exemplo acima, encontramos a seguinte contradição: Precisamos garantir a qualidade do software, mas não temos tempo hábil para isso. Formulada a contradição vamos tentar utilizar os princípios de separação em busca de idéias:

• Separação no espaço
  • Aumentar a equipe de desenvolvimento, em busca de uma aceleração do desenvolvimento para que haja um maior tempo para os testes.
• Separação no tempo
  • Expandir a capacidade no tempo: trabalhar até mais tarde e se necessário trabalho durante o final de semana.
• Separação conforme a condição
  • Negociar com cliente um maior prazo, justificando com a garantia de maior qualidade do software.
• Separação no sistema
  • Alguns recursos do desenvolvimento executarão testes em paralelo com a equipe Testes.

Como podemos perceber existem diversas possibilidades de solucionar os problemas sem que o projeto precise ser atrasado e sem encerrar a etapa de testes prematuramente. E as idéias de solução que não sejam imediatamente viáveis podem ser novamente analisadas com o uso do método de separação, até que alternativas “ganha-ganha” sejam encontradas.

Concluirmos que a utilização da metodologia TRIZ é capaz de gerar idéias inventivas em um curto espaço de tempo, a fim de encontrar a melhor maneira para solucionar os problemas. E percebemos que a resolução dos problemas muitas vezes, depende apenas de boa vontade das partes e da capacidade de pensar em conjunto, tendo como foco o bem para todos e não o de um único ser.

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

Fonte:

De Carvalho, M. A. Resolvendo Conflitos na Gestão de Projetos através da metodologia TRIZ. Revista Mundo Project Management (Mundo PM), Rio de Janeiro, Ano4, nº20, p. 18-22, Abr/Mai 2008.

http://www.decarvalho.eng.br/triz.html