GESTÃO ÁGIL DE PROJETOS - GESTÃO DA COLABORAÇÃO CONSTRUTIVA

Na fase de desenvolvimento, a colaboração eficaz é essencial para o sucesso da iteração. O gerente de projeto pode fazer muito para apoiar a equipe nessa frase e garantir a colaboração desejada. O ciclo Planejar, Executar, Verificar e Agir, ou PDCA, é uma ótima técnica para estimular o comportamento colaborativo. 

Em toda tarefa, os membros da equipe devem fazer um planejamento rápido, geralmente em duplas, concluir a tarefa, pedir que a outra pessoa a verifique e, se o resultado não for o esperado, agir imediatamente para fazer alterações. Se o PDCA for praticado enquanto cada funcionalidade é desenvolvida, vai haver colaboração frequente entre o desenvolvedor do produto e o cliente, exatamente conforme pretendido. 

Em princípio, as equipes ágeis devem trabalhar no mesmo local. Porém, nem sempre isso é viável. Se a equipe principal não estiver no mesmo local, serão necessárias ferramentas e técnicas adicionais para assegurar a colaboração. Na fase de visão, discutimos as ferramentas. Lembre-se de fornecer ferramentas que permitam acesso fácil à informação para todos da equipe principal. Em alguns casos, verificamos até a colocação de uma câmera na sala da equipe, para que os membros da equipe remota pudessem ver o que estava acontecendo. Isso os ajuda a se sentirem parte da equipe, como se estivessem lá. O ideal é trabalhar no mesmo local, mas ferramentas visuais podem ajudar. 

A equipe deve se reunir pessoalmente pelo menos uma vez para se conhecer, idealmente no início do projeto, no planejamento. Outra ótima abordagem é trabalhar junto na primeira iteração para que a equipe realmente se conheça. A equipe principal tomará muitas decisões na fase de exploração. O gerente de projeto deve garantir que haja normas estabelecidas e aprovadas para que a equipe tome decisões. O ideal é definir uma abordagem para tomadas de decisão não unânimes. Seguem algumas sugestões:

• As pessoas devem ser incentivadas a apresentar ideias e estar à vontade para falar.

• Cada um tem a responsabilidade de dizer o que está pensando. 

• Os membros da equipe devem escutar atentamente as ideias apresentadas, já que isso pode gerar outras ideias e soluções. Se a maioria concordar, pode-se tomar uma decisão. Isso evita que o grupo ande em círculos. 

• A lógica de qualquer decisão deve ser explicada e compreendida pela equipe. 

• Quem não concorda deve apoiar a decisão da maioria. 

• Ninguém tem autoridade para vetar uma decisão. 

Embora seja o ideal, uma decisão unânime pode levar mais tempo, o que nem sempre é adequado para o ritmo acelerado dos projetos ágeis. Pode haver tentativas de se chegar a uma decisão unânime, mas o tempo de discussão deve ser limitado, para que as decisões sejam tomadas em tempo hábil. 

Com essa abordagem, as regras são conhecidas e o grupo pode tomar boas decisões com base nas informações disponíveis. 

A colaboração construtiva não ocorre por acidente. Exige o uso do PDCA nas interações diárias, ferramentas eficazes de comunicação visual e normas aprovadas para que a equipe tome decisões.

Vejam a importância do PDCA na Gestão Ágil de Projetos!

Na próxima postagem abordaremos o gerenciamento de problemas e riscos. Até lá!

CONHECENDO O TPM - O QUE É TPM?

Desde o fim da Segunda Guerra Mundial, com o desenvolvimento das indústrias de manufatura e montagem, houve uma demanda natural para investir em novos equipamentos, tornando as máquinas altamente complexas, sofisticadas e automatizadas.

Entre vários países, o Japão embarcou rapidamente no desenvolvimento de tecnologia industrial e se tornou um dos líderes mundiais em aplicações de robôs.

Com maior necessidade de produção de equipamentos mais complexos e aumento no volume, o foco voltou-se para o planejamento da produção, para que a mesma  fosse realizada no tempo correto. 

Foi justamente a combinação da necessidade de cumprimento do plano de produção e a automação dos equipamentos, que acabou despertando nas empresa um maior interesse em aprimorar os processos de gestão e manutenção dos equipamentos, de modo a garantir a produção. Dessa forma teve origem o termo TPM (Total Productive Maintenance), significa Manutenção Produtiva Total em português.

O termo TPM foi originalmente definido pelo JIPM (Japan Institute of Plant Maintenance). É um método de gestão que identifica as perdas existentes no processo de produção e administrativo, que tende a maximizar o uso de ativos industriais e, assim, garantir uma produção de alta qualidade a custos competitivos.

O TPM em seu início incluía cinco estratégias:

a) Maximizar a eficiência dos equipamentos;

b) Desenvolver um sistema de manutenção produtiva que cobrisse a vida útil do equipamento;

c) A participação de todos os funcionários desde a alta administração até “o chão de fábrica”;

d) O envolvimento de todo o pessoal responsável pelo planejamento, uso e manutenção dos equipamentos;

e) Promover a manutenção produtiva por meio da gestão de incentivos às atividades em pequenos grupos autônomos.

No entanto, a JIPM observou o desenvolvimento do TPM em diferentes setores e sua aplicação em todos os departamentos, incluindo administração e vendas. Por conta disso, introduziu uma nova definição e novas estratégias de TPM, a saber:

a) Estabelecer uma organização consolidada para maximizar a eficiência dos sistemas de produção.

b) Fazer a organização focar na prevenção de todos os tipos de perdas para garantir zero falhas, zero acidentes e zero defeitos, de modo a assegurar a vida do sistema de produção por meio de uso de metodologias no chão de fábrica.

c) Ao implementar o TPM, assegurar a participação de todos os departamentos da organização, incluindo vendas e administração.

d) Garantir que todos (desde funcionários do chão de fábrica até a alta administração) estejam envolvidos na implementação do TPM;

e) Conduzir as atividades de pequenos grupos com foco na em perda zero.

Em resumo, podemos dizer que TPM é o conjunto de atividades das quais todos os trabalhadores de uma empresa são solicitados a participar, ou seja, manter um sistema de produção de forma eficiente e total, contando com a participação de todos.

Em nossa próxima postagem, falaremos sobre o histórico do TPM. Até lá!

CONHECENDO O LEAN SIX SIGMA - HISTÓRIA E OBJETIVOS DO 6 SIGMA

A metodologia 6 Sigma foi criada em 1980 pela Motorola. Na década de 90 o método tornou-se popular por ser utilizado com sucesso por empresas como a General Electric e a AlliedSignal.

A preocupação com a qualidade tem sido uma constante desde o início do século XX. Isto deveu-se em parte à maciça migração das atividades agrícolas para uma sociedade industrial.

A década de 80 foi marcada por rápidas tentativas de mudança no conceito sobre qualidade nos EUA, principalmente para imitar os resultados obtidos pelos japoneses que estavam aplicando as teorias do Dr. Deming (William Edwards Deming foi um estatístico, professor universitário, autor, palestrante e consultor estadunidense) e da Qualidade Total, Controle Estatístico de Processo, Just in Time, Kaisen, etc. Reconhecendo-se que a qualidade precisa ser um esforço da empresa como um todo, foi desenvolvido no final da década de 80 nos EUA o prêmio Malcolm Baldrige, um conjunto abrangente de orientações que depois de implementadas envolveria todas as pessoas da empresa.

Neste mesmo período um engenheiro da Motorola começou a estudar o conceito de Deming sobre variação de processo. Este engenheiro estatístico, Mikel Harry, começou influenciando sua própria empresa a estudar a variação como uma forma de melhorar o desempenho.

Essas variações, quando medidas estatisticamente, significam o desvio padrão da média, e são representadas pela letra grega Sigma. A abordagem Sigma tornou-se ponto focal do esforço de qualidade da Motorola, sobretudo depois que as iniciativas de Herry chamaram a atenção do presidente da empresa, Bob Galvin. Em todos os lugares onde ia, Galvin falava do sucesso da melhoria contínua nas atividades da Motorola, o que influenciou muitas pessoas.

Lawrence Bossidy, que após uma carreira bem sucedida na GE, assumiu a AlliedSignal, na época um conglomerado problemático que precisava de um especialista em mudanças. Bossidy percebeu que esta abordagem poderia ajudá-lo a transformar a AlliedSignal na empresa que ele imaginava.

Pouco tempo depois, durante a década de 90, quando Bossidy introduziu o método 6 Sigma em suas empresas da AlliedSignal (que estava há alguns anos à beira da falência), as vendas dobraram enquanto a produtividade e os ganhos cresceram enormemente. Houve uma redução de US$ 1,2 bilhões nos custos. O método 6 Sigma foi adotado por outras empresas como a Texas Instruments e a General Electrics com igual sucesso.

A GE divulgou alguns números para demonstrar a eficácia do método 6 Sigma:

GE Medical Systems: o scanner de diagnóstico desenvolvido com o método 6 Sigma teve o tempo de diagnóstico reduzido de 3 minutos para 17 segundos.

GE Plastics: aperfeiçoamento de um processo de produção de plástico que alcançou o volume de 1,1 bilhão de libras, o que aumentou o faturamento e possibilitou o fechamento de um contrato com a Apple.

Giros de estoque foram de 5,8 para 9,2.

Em 4 anos a GE economizou mais de US$ 1,5 bilhão com o

programa 6 Sigma.

OBJETIVOS DO 6 SIGMA

Visão: Orientar a indústria para desenvolver, processar e entregar produtos e serviços no padrão 6 Sigma, isto é, reduzir variação, defeitos, erros e falhas, estender a qualidade para além das expectativas dos clientes.

Meta: Produzir mercadorias e serviços dentro da qualidade 6

Sigma, o que significa:

 Eliminar defeitos

 Reduzir custos de desenvolvimento e produção

 Reduzir tempo de ciclo e níveis de inventário

 Aumentar a margem de lucro

 Melhorar a satisfação dos clientes

A meta do 6 Sigma é chegar próximo a zero defeito, erro ou falha, isto é 3,4 ppm ou 3,4 defeitos por milhão.

Estratégia: Usar uma estrutura dirigida por dados para atacar defeitos e melhorar o nível Sigma de seus produtos e serviços.

Benchmark: Ser usado como parâmetro para comparar o nível de qualidade entre empresas, unidades de negócio, departamentos, processos, máquinas, produtos, etc.

Realmente o Lean 6 Sigma é muito envolvente, funcional e eficaz! Na próxima postagem falaremos mais detalhes sobre o que é o 6 sigma. Até lá! 

GESTÃO ÁGIL DE PROJETOS - COMO CONTROLAR SEM INTERFERIR NO DESENVOLVIMENTO

A fase de exploração nos projetos ágeis é diferente das fases de desenvolvimento não ágeis. O papel do gerente de projeto é observar e orientar, em vez de liderar, colocando-se em segundo plano e liderando através de coaching. Pode ser uma adaptação difícil para gerentes de projetos tradicionais. Deve-se diminuir um pouco o controle, uma situação muito diferente e difícil para alguns gerentes. Em vez de controlar, seu papel é eliminar empecilhos à equipe. Isso pode ser feito ouvindo com atenção as reuniões diárias em pé para identificar problemas e depois agindo, fazendo acompanhamento e dando andamento com o pessoal. Com isso, a equipe se mantém produtiva e focada no desenvolvimento do produto. 

Equipes sempre precisam de recursos, não necessariamente de outras pessoas. Precisam de informações e ferramentas para executar o trabalho, como acesso a especialistas e treinamento. O gerente de projeto deve garantir que as necessidades de cada membro da equipe sejam atendidas visando à produtividade. A equipe sempre deve ser proativa na priorização das funcionalidades e estimativa das tarefas. É função do gerente de projeto garantir que essas atividades ocorram e ajudar a equipe somente nos momentos de dificuldade. 

Uma das formas mais importantes de deixar a equipe assumir a liderança é apoiando suas decisões. Mesmo discordando de uma decisão, pode ser melhor deixá-la seguir adiante e aprender com os resultados. Aprendemos muito com nossos erros, então permitir que alguns aconteçam gera grandes oportunidades de crescimento. Caso acredite que uma decisão terá impacto significativo no projeto, discuta sua preocupação com a equipe e altere a decisão. 

Às vezes, além da equipe, devem-se apoiar partes interessadas experientes. Se a Gestão Ágil for novidade, dedique tempo para garantir que a diretoria esteja se adaptando a processos ágeis. 

Seguem alguns exemplos de problemas comuns: 

O cliente não está trabalhando diariamente com a equipe de desenvolvimento de forma efetiva? 

O cliente anda muito ocupado para passar tempo com a equipe principal? 

Os gerentes estão confusos sobre a abordagem iterativa, achando que suas funcionalidades não serão tratadas? 

Nas primeiras iterações, pode ser muito útil passar mais tempo com a diretoria, acalmando as preocupações. 

Outra fonte de preocupação pode ser a intensidade da abordagem ágil. As equipes ágeis produtivas lidam com isso adotando um ritmo ou cadência. Numa iteração, pode haver muito trabalho nas semanas em que as funcionalidades são desenvolvidas. O gerente deve estar atento a fatores de estresse, ajudando cada membro a gerenciar a carga de trabalho. Deve propiciar semanas menos intensas, para que a equipe possa descansar um pouco e se preparar para a próxima iteração. Note que o gerente de projeto na fase de exploração não é um chefe rígido. Ele faz o possível para maximizar a eficácia de cada membro da equipe, mantendo-a comprometida, produtiva e trabalhando de forma autônoma.

Em nossa próxima postagem, falaremos sobre gestão da colaboração construtiva. Até lá!

CONHECENDO LEAN SIX SIGMA - RELATÓRIO A3

O relatório A3 foi idealizado pela Toyota Corporation e é amplamente utilizado na indústria para analisar e solucionar problemas, tendo esse nome por ter sido desenvolvido em papel tamanho A3. Este método descreve os problemas no relatório em detalhes com base na análise e soluções dos mesmos, fazendo sua organização de cima para baixo e da esquerda para a direita.

O desenvolvimento deste método é baseado no já bem conhecido Ciclo PDCA (planejar, executar, verificar e agir), que considera o diálogo entre o mentor e seus subordinados, a base para a resolução de qualquer problema com sucesso. O modelo determina que por meio do diálogo é possível encontrar a verdadeira causa raiz do problema e assim resolvê-lo em definitivo.

Essa ferramenta é de grande utilidade para a organização, pois registra o resultado final da resolução do problema de forma concisa e, portanto, incorpora um método de resolução de problemas que começa com um entendimento profundo de como o trabalho é realmente executado.

As etapas do A3:

1) Definição do Tema: Ao decidir usar esta ferramenta, é importante primeiro definir quais os problemas serão abordados no relatório A3. Neste momento, você vai tornar claro o problema. É preferível priorizar os problemas reincidentes e aqueles que causam mais transtornos internos.

2) Histórico: O próximo passo é decompor o problema, recuperar o histórico de registro do problema abordado, levando em conta, por exemplo, a quanto tempo ocorre, a frequência e extensão dos danos causados.

3) Condição Atual: Neste momento você vai "definir um alvo". Verifique atentamente qual é a situação atual do problema mencionado acima, levando em conta todas as variantes que permeiam sua condição do momento, fazendo a ilustração preferencialmente por meio de gráficos.

4) Análise das Causas Raiz: Nesta etapa, é necessário fazer uma investigação sobre as razões pelas quais o problema ocorreu. O Relatório A3 parte do princípio básico de que a solução de problemas está diretamente relacionada à sua causa raiz. Dessa forma, identificar a verdadeira causa é o grande desafio para garantir uma solução eficaz e definitiva, já que, até que a causa raiz seja encontrada, há um aumento na probabilidade de ocorrência de retrabalhos e desperdícios, com consequentes prejuízos ao processo.

5) Objetivos: Neste momento você vai desenvolver as contra medidas, ou seja, estabelecer o plano de ação. É muito importante definir quais os objetivos devem ser atingidos. Esses objetivos necessitam ser definidos de forma clara e direta.

6) Plano de Ação: Após a conclusão das etapas anteriores, deve-se dar segmento, executar o plano de ação (ver, por em prática as contra medidas), plano de ação esse que, além de promover a contenção imediata do problema, deve também evitar uma possível recorrência futura.

7) Acompanhamento e confirmação do efeito: Finalmente, é necessário monitorar os efeitos causados  pelas ações tomadas anteriormente, para garantir sua eficácia para resolver o problema. O acompanhamento normalmente ocorre ao longo de três meses, para confirmar que a execução do plano de ação foi suficiente ou se outro método deverá ser aplicado para resolver o problema. Nesta etapa, além de se acompanhar o resultado e os respectivos processos, em caso positivo, deve-se padronizar o sucesso obtido. 

Em resumo, o relatório A3 é uma ferramenta que, caso seja bem executada, tende a trazer ótimos resultados em ações voltadas para soluções de problemas.

GESTÃO ÁGIL DE PROJETOS - CONTROLE E ADEQUAÇÃO DO PLANEJAMENTO

Muitas pessoas que não entendem a Gestão Ágil creem que ela não oferece mecanismos de controle, o que é um grande equívoco. Existem técnicas ágeis específicas para gerenciamento e monitoramento de projetos. 

O escopo é gerenciado pela lista de pendências. Ele é controlado concluindo funcionalidades para diminuir as pendências e acrescentando novas funcionalidades. As equipes comercial e técnica redefinem as prioridades regularmente para definir quais funcionalidades serão implementadas na próxima iteração. Essas alterações na lista de pendências são comuns, mas lembre-se de que o escopo da iteração atual nunca deve ser alterado. 

Depois de aprovada, a lista de funcionalidades da iteração não deve mudar. Velocidade é o termo usado para descrever quantas funções a equipe completa em média por iteração. Isso pode ser calculado analisando as iterações anteriores, supondo que os recursos da equipe e a duração da iteração não mudem. Compreendendo a velocidade normal, pode-se determinar se a iteração atual segue na mesma velocidade. Se o andamento não for o esperado, é preciso investigar o motivo. Caso a velocidade precise ser ajustada nas iterações futuras, será preciso replanejar e diminuir o número de funcionalidades a serem concluídas. A vantagem da velocidade é permitir controle e entendimento do ritmo de desenvolvimento, sendo possível adequar o planejamento de lançamentos ou recursos da equipe conforme necessário. 

Um gráfico de burndown é uma ferramenta que mostra o trabalho a ser concluído. 

O gráfico de pendências compara as funcionalidades e o tempo previsto para concluí-las. O eixo X representa o cronograma do projeto. O eixo Y é o trabalho que deve ser concluído no projeto ou iteração. As estimativas de tempo para o trabalho restante são representadas nesse eixo. A data de início do projeto é o ponto mais à esquerda do gráfico. O término do projeto é o ponto mais à direita e corresponde ao último dia previsto para o projeto ou última iteração. No ponto de partida, o trabalho restante efetivo é o volume total de trabalho restante. Com o tempo, a linha de trabalho efetivo concluído, em vermelho, pode ser comparada ao planejamento geral das iterações, em dourado, para ver se o cronograma está adiantado ou atrasado. Pode-se, então, ajustar as funcionalidades a serem concluídas, ampliar o prazo e custo ou replanejar as funcionalidades para que o planejamento fique compatível com a capacidade de desenvolver funcionalidades. 

O gráfico de burndown mostra claramente se as funcionalidades estão adiantadas ou atrasadas no cronograma e quando todas serão concluídas. O importante é usar essa informação para monitorar constantemente o andamento e fazer os ajustes necessários para maximizar a produtividade da equipe. Usando essas técnicas simples, é possível ter ótimo controle do andamento de projetos ágeis.

Ferramentas valiosas, não?

Em nossa próxima postagem, falaremos sobre como controlar sem interferir no desenvolvimento. Até lá!

ENTENDENDO HAZID E HAZOP

Dentre as diversas metodologias utilizadas pelos profissionais de SST, para identificação e quantificação de perigos e riscos, hoje vamos destacar duas muito importantes: HAZID e HAZOP.

HAZID (Hazard Identification) que em português quer dizer Identificação de Perigos, é uma análise de risco ou identificação de perigo que envolve a investigação qualitativa de perigos. É um brainstorming e uma análise dos riscos potenciais do projeto em estudo, onde são verificados temas referentes a quem pode ser impactado no processo, ou seja, abrangendo todas as partes interessadas (comunidade vizinha, trabalhadores, funcionários em geral, etc). Também são levadas em consideração, quando aplicável, questões referentes a condições naturais, como chuvas, inundações e terremotos. Tais riscos, caso não sejam avaliados adequadamente na concepção do projeto, tendem a apresentar consequências muito graves. Em alguns casos, questões de segurança podem inviabilizar determinados empreendimentos. Em outros casos, o custo de mitigação de riscos pode ser tão alto que acaba por tornar a iniciativa também inviável, economicamente falando.

O HAZID possui um diferencial em sua elaboração, porque visa identificar os perigos que não são descobertos espontaneamente, ou seja, o foco não está nos perigos que são óbvios durante o processo de identificação, como por exemplo, quedas do mesmo nível.

Existem vários modelos / templates para HAZID, assim como por exemplo, para a APR (Análise Preliminar de Risco). No entanto, determinados campos da planilha podem ser considerados campos padrão, pois são campos que identificam perigos, causas, consequências, probabilidade de ocorrência, severidade do dano e medidas de controle existentes e / ou que devem ser aplicadas. 

Um HAZID não pode ser preparado apenas pela equipe de segurança da empresa onde os trabalhadores estão em risco, mas deve ser preparado por uma equipe multidisciplinar, composta inclusive pelos profissionais terceirizados envolvidos nas atividades. Desta forma, há a condição de se explorar todos os pontos de vista relevantes no processo.

Já o HAZOP (Hazard and Operability Study), que em português quer dizer Estudo de Perigos e Operabilidade, é um método qualitativo que tem como função identificar os riscos associados ao ambiente de trabalho, identificar anormalidades e apontar as causas raízes das mesmas.

Geralmente, o HAZOP é realizado quando há operações complexas, com utilização de equipamentos críticos no processo, os quais, no caso de falhas, podem acarretar lesões graves nos envolvidos em sua utilização, ou mesmo óbitos. 

A proposta é realizar uma investigação detalhada dos componentes de todo o processo, identificar alterações no padrão estabelecido e detectar problemas que afetem os resultados e a qualidade.

No HAZOP, após determinar o risco, a causa e o possível impacto do problema, são tomadas medidas para corrigir e prevenir essas ameaças. Além disso, ele se concentra em dois pontos importantes:

•  Risco: relacionado à segurança e integridade dos colaboradores, sistemas e meio ambiente;

•  Questões de operabilidade: colocam em risco a produção.

O HAZOP é vital para a organização, porque permite identificar de forma prévia, os cenários com maiores probabilidades de apresentar falhas. Dessa forma, as correções podem ser aplicadas a tempo, antes que situações indesejadas aconteçam.

Tanto o HAZOP quanto o HAZID são ferramentas para identificação de perigos e devem ser usadas para minimizar a possibilidade de ocorrência de incidentes e acidentes.

GESTÃO ÁGIL DE PROJETOS - PLANEJAMENTO E CONDUÇÃO DE REUNIÕES EM PÉ

As reuniões diárias em pé são a força motriz de um projeto ágil. Elas são vitais para o sucesso do projeto, pois são compartilhadas informações críticas visando à eliminação de empecilhos. 

As reuniões devem ser de aproximadamente 15 minutos, rápidas e objetivas. Com os participantes em pé, a reunião tende a ser curta, animada e participativa. Todos da equipe técnica e comercial devem participar, além do gerente de projeto, também chamado de Scrum Master. 

Idealmente, o gerente de projeto não conduz a reunião. Cada membro da equipe traz informações atualizadas. É importante que a equipe relate o andamento em uma sequência diferente a cada dia. Essa rotatividade acrescenta energia às reuniões. Também vale indicar alguém para controlar o tempo, mantendo o grupo focado. Talvez isso seja necessário somente até que o grupo esteja condicionado ao formato da reunião. De 30 a 60 segundos por pessoa devem ser suficientes. Deve-se revezar quem controla o tempo a cada iteração. 

Provavelmente o hábito mais difícil de deixar é o de resolver problemas durante a reunião. Enfrente os problemas depois da reunião, garantindo que somente o pessoal necessário participe da discussão. Faça a reunião sempre no mesmo horário. A consistência é muito importante. 

Devem-se observar alguns aspectos nas reuniões diárias, tais como: 

A equipe está cooperando ou o ambiente fica tenso? 

Estão surgindo riscos que possam afetar as iterações futuras? 

Existe algum problema comum que você possa ajudar a resolver? Após a reunião, é claro. 

A lista de problemas está aumentando? 

Caso a Gestão Ágil seja um conceito novo para a equipe, há algum membro tendo dificuldades? 

Está claro que as reuniões em pé podem trazer muitas informações preciosas. Fique atento e aja conforme necessário. Uma boa sugestão é sempre terminar a reunião com uma mensagem positiva. Faça a equipe compartilhar alguma vitória desde a última reunião. Por exemplo: 

A empresa realmente gostou do que viu na análise do produto? 

Alguém da equipe técnica solucionou um problema difícil e sente orgulho disso? 

Compartilhar as vitórias mostra à equipe o progresso realizado e mantém uma dinâmica favorável. Se a equipe for pequena, trabalhar no mesmo local e estiver cooperando intensamente a cada dia, as reuniões diárias podem parecer menos valiosas, pois todos já sabem o que está acontecendo. Nesse caso, a reunião pode ser feita com menos frequência, duas ou três vezes por semana, para garantir o andamento e verificar o ritmo da equipe. Semanalmente, podem-se convidar outras partes interessadas para a reunião. 

Pode ser proveitoso que gerentes de negócios, gerentes de tecnologia e usuários do produto que não façam parte da equipe principal saibam do andamento do projeto, por exemplo. Quanto maior o envolvimento, melhor. 

Permita uma sessão de perguntas de cinco minutos ao final da reunião para os participantes adicionais. Uma reunião de 15 minutos pode ser incrivelmente importante e proveitosa. Concentre-se em tornar suas reuniões em pé focadas e proveitosas.

Viram como são importantes as reuniões em pé?

Em nossa próxima postagem, falaremos sobre controle e adequação do planejamento. Até lá!

DIFERENÇA ENTRE ITERAÇÃO E INTERAÇÃO

Há algum tempo faço postagens sobre Gestão Ágil de Projetos e um dos termos usados têm chamado a atenção:

ITERAÇÃO

Algumas pessoas tendem a confundir ITERAÇÃO com INTERAÇÃO, o que é até natural.

Dessa forma, vou explicar de modo resumido e objetivo, a diferença básica entre esses dois conceitos.

Quando se fala em iteração, consideramos a repetição de um determinado processo que gera sequência. No contexto dos métodos ágeis, o desenvolvimento iterativo representa um intervalo de tempo (time box) para execução de um projeto, que é dividido em tarefas funcionais específicas, gerando um refinamento até que o projeto atinja um nível satisfatório para suas metas estabelecidas.

Já interação, refere-se a influência recíproca entre uma coisa e outra, entre uma pessoa e outra. Também é o agrupamento das relações e/ou das ações que se efetivam entre os indivíduos de um determinado grupo ou entre os grupos de uma mesma sociedade/organização/empresa. Por exemplo: a interação da teoria e da prática, interação entre departamentos de uma mesma organização

E aí? Ajudou?

A PARÁBOLA DA VAQUINHA E O PRECIPÍCIO

Um mestre passeava por uma floresta com seu fiel discípulo, quando avistou ao longe um sítio de aparência pobre e resolveu fazer-lhe uma breve visita. Durante o percurso, ele falou ao aprendiz sobre a importância das visitas e as oportunidades de aprendizado que temos, também, com as pessoas que mal conhecemos.

Chegando ao sítio, constatou a pobreza do lugar, sem calçamento, casa de madeira, os moradores – um casal e três filhos – vestidos com roupas rasgadas e sujas. Então, aproximou-se do senhor e perguntou-lhe:

– Neste lugar, não há sinais de pontos de comércio e de trabalho. Como a sua família sobrevive aqui?

O senhor respondeu:

– Nós temos uma vaquinha que nos dá vários litros de leite. Uma parte do produto nós vendemos ou trocamos na cidade vizinha por comida e a outra produzimos queijo e coalhada para o nosso consumo, e assim vamos sobrevivendo. O sábio agradeceu, se despediu e foi embora.

No meio do caminho, voltou ao seu discípulo e ordenou-lhe:

– Aprendiz, pegue a vaquinha, leve-a ao precipício ali na frente e jogue-a.

O jovem arregalou os olhos e questionou o mestre sobre o fato de a vaquinha ser o único meio de sobrevivência daquela família; mas, como percebeu o silêncio do seu mestre, cumpriu a ordem: empurrou a vaquinha morro abaixo e a viu morrer.

Anos depois, ele resolveu largar tudo e voltar àquele lugar, pedir perdão e ajudar a família. Quando se aproximou, do local avistou um sítio bonito, com árvores floridas, carro na garagem e crianças brincando no jardim. Ficou desesperado, imaginando que a família tivera de vender o sítio para sobreviver. Chegando lá, foi recebido por um caseiro simpático, a quem perguntou sobre as pessoas que ali moravam.

Ele respondeu:

– Continuam aqui.

Espantado, entrou correndo casa adentro e viu que era mesmo a família que visitara antes com o mestre. Elogiou o local e perguntou ao senhor (o dono da vaquinha):

– Como o senhor melhorou o lugar e agora está bem?

O senhor, entusiasmado, respondeu: – Nós tínhamos uma vaquinha que caiu no precipício e morreu. Daí em diante, tivemos de fazer outras coisas e desenvolver habilidades que nem sabíamos que tínhamos e, assim, alcançamos o sucesso que seus olhos vislumbram agora.

Muitas vezes temos que nos desvencilhar do que estamos habituados para podermos conhecer nossas verdadeiras habilidades. Cada dia, é uma oportunidade de refletirmos sobre a “nossa” vaquinha e empurrá-la morro abaixo...

GESTÃO ÁGIL DE PROJETOS - LEVANTAMENTO DOS REQUISITOS

Os projetos ágeis preveem e comportam alterações. Em projetos ágeis, é essencial identificar e documentar requisitos com base na necessidade de negócio atual. 

Na fase de especulação, discutimos o uso de fichas para documentar funcionalidades. Agora vamos discutir abordagens e técnicas para documentar as funcionalidades e requisitos. 

Uma ótima técnica é manter um analista de negócios trabalhando uma ou duas iterações à frente da equipe de desenvolvimento ágil. O analista de negócios se adianta à equipe e garante que as funcionalidades da iteração seguinte estejam claramente definidas pela empresa. Além disso, se as necessidades de negócio mudarem, o analista pode especificar as novas funcionalidades desejadas ou identificar aquelas que se tornaram desnecessárias na lista de pendências. 

Há várias técnicas para identificar os requisitos. Uma técnica comum é utilizar casos de uso. São empregados diagramas ou imagens para mostrar a relação entre um ator e um sistema ou processo para atingir um objetivo específico. Um ator pode ser uma pessoa, empresa, organização, departamento, programa de computador ou sistema computacional — qualquer entidade que possa tomar uma decisão. Os casos de uso são usados para documentar requisitos em projetos de TI ou outras áreas. Abaixo segue um exemplo de caso de uso com seus principais componentes: 

O ator realizando o evento, como alguém indo a um caixa eletrônico. 

O sistema ou processo com quem o ator interage, como o caixa eletrônico. 

A caixa completa, que representa os limites do requisito. Qualquer coisa fora da caixa está fora do escopo. O interior da caixa indica que tipo de coisa o ator pode fazer com o sistema, como depósitos, consultar o saldo e sacar dinheiro. O exterior da caixa mostra os atores que podem interagir com o sistema, como a equipe de manutenção, gerentes que recebem relatórios informativos ou até um ladrão. 

O texto de um caso de uso também pode ser usado para descrever a situação em detalhes. O caso de uso ajuda os interessados a ver como um requisito atende às suas necessidades através de funcionalidades. 

Outro elemento registrado é a ficha de requisitos de desempenho. São semelhantes às fichas de funcionalidades, mas descrevem um requisito aplicável a várias funcionalidades. Por exemplo: o departamento de contabilidade pode ter um requisito de desempenho quanto ao tempo permitido para o processamento de uma fatura recebida. Em uma central de atendimento, o requisito pode ser atender a cada chamada em até X minutos. Aqui está um exemplo de ficha de desempenho. Cada requisito deve ter uma identificação única e uma breve descrição. O fator de dificuldade ajuda a empresa a definir a prioridade do requisito. Por último, a seção de testes de aceitação descreve como verificar se o requisito foi cumprido após o desenvolvimento produto. 

É essencial documentar os requisitos em qualquer projeto. Nos projetos ágeis, os requisitos evoluem continuamente. Um analista de negócios trabalhando à frente da equipe principal vai ajudá-la a se preparar para cada iteração concentrando-se nas funcionalidades e requisitos relevantes.

Na próxima postagem, falaremos sobre planejamento e condução de reuniões em pé. Até lá!