100 pessoas

Durante esse mais de 1 ano de blog, a maioria dos posts foram sobre Teste e Qualidade de Software. O próprio nome do blog tem a palavra Qualidade. Mas até hoje não falei sobre o fator de maior impacto na qualidade de um software, o fator humano. Afinal, sem pessoas não há software.

Então vou aproveitar o centéssimo post para falar um pouco sobre nós. E neste primeiro post sobre gestão de pessoas, irei falar sobre o processo MAIS IMPORTANTE, o de contratação. Espero que gostem.

O caso Google

Já virou clichê falar sobre o Google para exemplificar algo bem feito. E não é diferente quando falamos em pessoas, afinal a política de recursos humanos do Google é excelente e inovadora, sendo uma das razões (na minha modesta opinião) pela qual o Google tem a força e influência que tem hoje. Pois para manter o alto nível de qualidade prestado, é necessário funcionários brilhantes, inspirados e motivados.

Um processo seletivo, normalmente, é terminado após três fases no caso de vagas de estágio. E para vagas de efetivo, principalmente para cargos pleno e sênior o processo é constituído de uma ou duas fases.

Já no Google o processo seletivo tem de seis a oito fases [1]. Daí você pode pensar mais pra quer tantas fases? E o motivo é simples: para conhecer melhor o futuro profissional.

E esse processo é super importante tanto para a empresa quanto para o candidato, afinal ambos poderão se conhecer melhor. E para realizar uma boa e longa contratação o profissional deve ter um perfil que agrade a empresa, e vice-versa.

Podemos até fazer uma analogia com o casamento: você não irá casar com a pessoa, após ter saído apenas duas ou três vezes com ela, geralmente, vocês irão levar anos até dá esse importante passo.

E quando você assina um contrato com uma empresa, você está firmando um compromisso com ela, portanto a semelhança com um casamento existe.

Mas como atualmente divórciar e mudar de emprego é algo fácil (para não falar que está na moda), já estamos acostumados com essa rotatividade.

Como identificar a pessoa certa?

Melhorando o processo seletivo!

E quando falo em melhorar não é apenas aumentar o número de entrevistas, mas como também inovar no processo de seleção.

Inovar Fabrício? Inovar é difícil.

Nem tanto, e vou até ajudar apresentando uma idéia que ainda não coloquei em prática, mas assim que puder irei colocar. Na empresa em que trabalho, participo de um Enduro a Pé quase todo mês com o pessoal. O Enduro é um tipo de prova que exige um bom trabalho em equipe. Ao participar de uma prova dessa, mesmo sendo a primeira vez, várias características podem ser identificadas na pessoa, e num ambiente mais confortável e informal você poderá conhecer muito melhor o seu candidato.

enduro

E não só no Enduro mais como em vários outros esportes é possível identificar características importantes no candidato, que em uma entrevista talvez não apareceriam ou poderiam ser mascaradas.

Lógico, que se num determinado processo seletivo, os conhecimentos técnicos sejam mais importantes do que as características pessoais, uma outra abordagem pode ser usada. E uma fase imprencidível seria a aplicação de uma avaliação de conhecimentos técnicos, que poderia ser feita até na prática. Fazendo o candidato passar um dia ou uma tarde com a equipe com a qual ele poderá trabalhar no futuro. Desta maneira você irá avaliar ao mesmo tempo, tanto os conhecimentos técnicos como as características pessoais do candidato.

E a característica  trabalho em equipe, que é um dos principais para qualquer profissional de TI, pode ser melhor avaliada utilizando as práticas citadas, pois você terá a sua impressão e ainda o feedback dos membros da equipe sobre o candidato. E a opinião deles poderá te ajudar e muito, afinal das contas, eles que irão trabalhar diretamente com aquela pessoa. 🙂

Para encerrar o centésimo post :), vou deixar uma frase parafraseando o grande Charles Chaplin:

“Conhecer a sua equipe – esta é a base para o sucesso do seu projeto.”

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

Fonte:

[1] Eleita a melhor empresa, Google também é abandonada por funcionários (G1)

O melhor da semana 12/07 a 18/07

Pessoal,

Segue a lista do melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. 🙂

Abraços! E tenham uma ótima semana!

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

Introdução ao Teste de Software: uma abordagem prática

Aproveitando o “Jabá Day” (rsrs)…

Quem me segue pelo Twitter, participa da lista do DFTestes, ou acompanha o blog Ensinar, já deve está sabendo que irei fazer um curso de Teste de Software na empresa que trabalho.

Para mim será uma experiência nova, pois nunca dei um curso de Teste de Software, pelo menos não de uma maneira formal.

O curso intitulado “Introdução ao Teste de Software: uma abordagem prática” faz parte da grade de cursos do primeiro Ensina aí!, que é uma sequência de cursos e palestras feitas por amigos e funcionários da Voice Technology, que dentro do possível serão abertos a pessoas de fora também.

Neste curso irei abordar de maneira introdutória a área de Teste de Software. E como sei que se eu fosse passar somente a teoria, muitos iriam aproveitar o tempo para tirar um bom cochilo (hehe), vou usar uma abordagem mais prática, visando deixar mais dinâmico e divertido o curso. 🙂

Segue abaixo, maiores detalhes sobre o curso e um breve FAQ:

Conteúdo:

  • Conceituação de Teste de Software
  • A importância do Teste de Software
  • Quando os testes devem começar?
  • Modelos do processo de desenvolvimento de software e o Teste de Software
  • O processo de Teste de Software
  • As atividades de Teste de Software
  • Verificação X Validação
  • Padrão 829 para documentação de Teste de Software,
  • Teste de Caixa Branca e Caixa Preta
  • Tipos de testes
  • Elaboração de Caso de Teste
  • Preparação do ambiente de teste
  • Teste manual X teste automatizado
  • Reportando falhas
  • Gestão de falhas
  • Ferramentas de bug tracking
  • Quando os testes devem parar?
  • Ferramentas de gestão de Testware
  • Mitos do Teste de Software
  • Carreira – Teste de Software
  • Certificações

Inscrição: por e-mail (ensinaai@voicetechnology.com.br).

Valor: gratuito.

Data: 27, 28 e 29 de julho. Das 19:00 às 22:30.

Carga horária: 10 horas.

Local: Voice Technology – Rua Líbero Badaró, 293 – cj. 30 A Centro – São Paulo (Edifício Conde de Prates).

Público Alvo: interessados em Teste de Software e iniciantes na área.

Total de vagas: 15. (vagas esgotadas)

Com que frequência irá ocorrer esse curso?

Irá depender de dois fatores: o feedback recebido nesta primeira realização e a procura pelo curso.

Não poderei participar dessa vez, poderei participar na próxima?

Claro! Aliás, aqueles que não podem participar desta primeira realização, por favor envie o e-mail demonstrando o interesse, pois assim será mais fácil de montar a segunda turma.

O curso será sempre o mesmo, ou haverá cursos mais avançados/específicos?

Novamente dependerá da procura pelo curso. Se você quiser sugerir algum assunto a ser abordado, sinta-se à vontade em comunicar. Assim, se várias pessoas sugerirem o mesmo assunto ou parecido, a probabilidade de ser realizar o curso é maior. Logicamente, que dependendo do conhecimento do ensinador, não vai me pedir um curso de culinária mexicana. (rsrs)

Tenho outras dúvidas, o que faço?

Envie um e-mail para ensinaai@voicetechnology.com.br com a tag [DÚVIDAS].

Ahh… há vários outros cursos que serão dados no primeiro Ensina aí!, se você quiser saber maiores detalhes, só acessar o link abaixo:

http://ensinar.wordpress.com/2009/06/26/primeiro-ensina-ai-cursos-gratis/

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

Assine o feed

4º Encontro Mensal da ALATS São Paulo

O encontro dessa vez terá como tema a automatização de testes, com a presença do grande Elias Nogueira ministrando a sua palestra intitulada “Automação de Teste de Software – Mitos e Verdades”.

Mais uma vez será uma bela oportunidade de conversar com o pessoal da área e ainda conhecer mais sobre Automação de Teste de Software, pena que dessa vez não poderei ir. 😦

Segue abaixo maiores detalhes sobre o encontro, retirados do site da ALATS – São Paulo:

Data: 29 de Julho (quarta-feira)
Horário: 18:30 – 22:00

Objetivo: Aumentar o contato entre profissionais da área de Teste de Software e Garantia da Qualidade, bem como estimular a troca de conhecimentos, experiências e práticas de sucesso.

Tema do Encontro: Automação de Teste de Software – Mitos e Verdades
Agenda:
18:30 Credenciamento e Networking entre os Participantes
19:00 Automação de Teste de Software
20:00 Coffee break e Networking
20:30 Continuação da apresentação
21:30 Espaço aberto para discussão de temas da ALATS e da comunidade de Qualidade de Software em geral
22:00 Encerramento

Palestrante: Elias Nogueira, CSTE. Graduado em Análise e Desenvolvimento de Sistemas pela Ulbra – Canoas/RS. Arquiteto de Teste de Software na In|Metrics, Instrutor de Teste de Software na Iterasys e Consultor em Automação de Teste na Testanywhere.

Local: IMAM – Rua Loefgreen, 1.400 – Vila Mariana – próximo a Estação de Metrô Santa Cruz, estacionamento no local (não incluso)

Inscrições:

A participação na palestra Vale 3 PDTS para a renovação da CBTS

Reserve pelo e-mail sp@alats.org.br

Bônus: A Iterasys sorteará entre os participantes 1 vale desconto em seus treinamentos no valor de R$ 400,00.

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

Assine o feed

P.S.: Para quem não sabe o Elias Nogueira torce pro Internacional, então sugiro para quem é corintiano ir com a camisa do Corinthians (hehe), e quem não é, pode levar um saquinho de pipoca ou um lenço para o nosso amigo colorado (rsrs).

O melhor da semana 05/07 a 11/07

Pessoal,

Segue a lista do melhor da semana (ela tá quase precisando mudar de nome, para “o melhor de Sarah Pimentel”, fazer o que… ela arrebenta!), espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. 🙂

Abraços! E tenham uma ótima semana!

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

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).

Fonte: Colégio Oberlin

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.

O ciclo de trabalho do Scrum

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.

Sprint 1 - 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?

Comparação pesquisa feita no Google

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.

O melhor da semana 28/06 a 04/07

Pessoal,

Chegamos a mais um o melhor da semana. Espero que gostem da lista dessa semana:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. 🙂

Abraços! E tenham uma ótima semana!

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

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:

Processo de Gerenciamento de Riscos

  • 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”.

Cena do filme Tropa de Elite

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)