Busca

What's up

Webblog in construction

A metodologia Lean

O Lean surgiu após a segunda guerra mundial na fábrica da empresa automobilistica Toyota. A indústria japonesa passava por uma crise onde a demanda do mercado era baixa e ainda sofriam com a falta de recursos, o que inviabilizava manter uma produção em massa como era o habitual na época.

Naquela período o que se sabia era que a produção em massa era a forma mais barata produzir carros porém o mercado não tinha demanda suficiente que justificasse um volume grande de produção.  Começou ai surgir uma nova forma de trabalho, a indústria tinha que se preocupar em adequear sua produção para uma nova demanda de mercado, atender a necessidade dos clientes da melhor forma possível , reduzir custos e conseguir oferecer ao cliente o menor preço. Começou a surgir ai a metodologia Lean.

O lean é composto por 7 princípios:

  1. Eliminar o disperdício;
  2. Amplificar o aprendizado;
  3. Adiar comprometimentos e manter flexibilidade;
  4. Entrega rápida
  5. Tornar a equipe responsável;
  6. Construir integridade;
  7. Visualizar o todo;

Assim como Lean as práticas ágeis buscam o combate ao disperdício e processos enxutos.  Para muitos autores Lean pode ser classificado também como uma filosofia. E essa filosofia tem tudo para funcionar muito bem com práticas ágies🙂.

 

PMI – ACP A Certificação do PMI em métodos ágeis

Já um tempo sem postar … vou falar um pouco sobre a certificação PMI-ACP.

Ainda não tirei essa certificação, então algumas dicas sobre a prova não vou conseguir incluir nesse post. Meus estudos estão apenas no começo … então pretendo ir postando tudo que achar interessante sobre métodos ágeis e dicas importantes para a certificação.

No próprio site do PMI, cita a pesquisa que demonstra o valor dos métodos ágeis no desenvolvimento de software. De dezembro de 2008 a maio de 2011 o uso de práticas ágeis aumentou cerca de 80% nos projetos de desenvolvimento de software.

Essa certificação não se limita apenas aos gerentes de projeto, qualquer pessoa que trabalhe em projetos ágeis pode buscar essa certificação.

Para se inscrever para a prova, o candidato precisa ter seguintes pré-requisitos:

  • Experiência geral de projetos 2.000 horas. Essas horas devem ter sido obtidas nos últimos 5 anos;
  • Experiência em Métodos Ágeis 1.500 horas. Essas horas devem ter sido obtidas nos últimos 3 anos. Essas horas são adicionais as horas geral de projetos;
  • Treinamento em Práticas ou Métodos Ágeis 21 horas.

A prova é composta por 120 questões onde 20 são questões experimentais (não conta pontos) porém o candidato não sabe quais são essas questões experimentais. O tempo para a prova é de 180 minutos (3 horas). Para a maioria das pessoas que fez a prova esse é um tempo suficiente para resolver e revisar todas as questões. O mais importante é você saber gerenciar seu tempo na hora da prova.

Na prova todas as questões são de multipla escolha com 4 possibilidades e apenas uma opção correta.

Para manter a certificação, o profissional terá que reportar 30 PDUs (Professional Development Unit) a cada 36 meses.

Para um detalhamento maior sobre a prova segue o link: http://www.pmi.org/Certification/~/media/PDF/Certifications/PMI-ACP_Handbook.ashx

 

 

Certificação MS-Project 2013

certificaçãoNesse post vou falar da certificação Microsoft Specialist 74-343. Essa prova foi lançada em 05/04/2013 e avalia seu conhecimentos na ferramenta MS-Project 2013 como gerente de projetos.

Dicas de estudo

O livro que utilizei para estudos foi o Microsoft Project 2013 Step by Step (só tem versão em inglês). O livro tem todos os assuntos da prova.

Dicas de blogs

Entrei alguns blogs que me ajudou muito para entender sobre a prova.

http://www.brunocunha.com/blog/gerenciamento-projetos/obter-certificacao-microsoft-project-2013/

http://gerentedeprojeto.net.br/?p=3909

https://imasters.com.br/gerencia-de-ti/certificacoes/certificacao-microsoft-project-2013-dicas-de-estudo/

Nesses blogs encontrei valiosas dicas para a prova. Obrigada aos autores pela contribuição.

Simulados

http://www.dotnetsql.com.br esse simulado é muito bom. Recomendo😉.

A Microsoft recomenda os simulados nos sites MeasureUp e Self Test Software.

A Prova

A prova possui 54 questões, a maioria objetiva. O tempo de duração da prova 2 horas. Para ser aprovado é preciso obter mais de 700 pontos.

As questões das provas são bem interessantes pois testa o conhecimento do candidato na ferramente apresentando questões situacionais de gestão de projetos.

Na prova tem questões de multipla escolha, questões para escolher um conjuntos de resposta e questões para ordenar um conjutno de ações que será a resposta.

Até o dia 31/05/2014 está disponível o direito à segunda tentativa para fazer a prova através do programa Second Shot. Segue o link: http://www.microsoft.com/learning/pt-br/second-shot.aspx

Fica a dica para a certificação Microsoft Specialist 74-343.

[]’s

[MS-Project] Recurso Custo ou Recurso Material … qual utilizar ?

Trabalhando com o MS-Project temos 3 tipos de recursos:

  • Recurso de Trabalho
  • Recurso de Material
  • Recurso de Custo

Aqui não vou entrar em detalhes sobre cada tipo de recurso. Apenas detalhar melhor a diferença entre um recurso material e o recurso custo.

O Recuros de Trabalho é algum muito fácil de identificar. Tem muitos artigos explicando sobre esse tipo de recurso mas para os outros tipos de recursos podem surgir algumas dúvidas. A aquisição da licença de um software seria um recurso de material ? Ou um recurso de custo ?

Bom, recurso de material, será que é tão simples assim de identificar ? Recurso de Material : usado para acrescentar o gasto com materiais. A aquisição do software, é material ?

Para um recurso de material, as informações que podem ser inseridas são :

  • Taxa Padrão: Taxa de remuneração pelo trabalho (para esse tipo de recurso não tem hora-extra)
  • Custo por uso: Valor cobrado toda vez que o recurso é usado

Um exemplo de tipo de recurso material poderia ser combustível para uma equipamento, o uso de uma máquina …

Recurso de Custo: uma valor inserido manualmente. Pode ser algo que não varia em relação ao tempo de uso. No caso da licença do software, se o valor é fixo, a única questão é saber quantas licenças serão necessárias.

Para um recurso de custo, a unica informação é o nome do recurso. Quando o recurso custo for associando a tarefa, você irá informar o valor do custo.

Associando o recurso de custo a tarefa

Na inclusão do recurso custo apenas a descrição é informada. Os demais campos ficam desabilitados com exceção do campo anotações.

Incluindo o recurso custo

Então com essas informações, fica mais fácil identificar quando um recurso é Material ou Custo.

Fica a dica.

Estimando a duração das atividades em um projeto

Não se gerência o que não se pode medir.” Peter Drucker

Infelizmente se temos projetos e clientes, na maioria das vezes temos que estimar. Temos que saber o prazo de conclusão do projeto e muitas vezes temos que definir prazos para algumas entregas. Nesse momento, o gerente do projeto ou líder precisa conhecer técnicas para saber estimar bem e saber quando aplicá-las.

Aumento arbitrário nas estimativas, a famosa “gordura”, é antiético e um indício de falta de um gerenciamento de projeto. Aumento nas estimativas representa aumentar tempo e/ou custo. E se você acha isso normal … posso te adiantar que não é. As estimativas devem ser realistas e confiáveis. Caso as estimativas da sua equipe não que estejam sendo feitas corretamente porque a equipe desconhece detalhes que precisam saber, ou tem incertezas, essas devem ser mapeadas em oportunidades ou ameaças e pode ser gerenciadas ao longo do projeto pelo gerenciamento de riscos. Esses riscos (ameças e oportunidades) devem ser discutidas abertamente com as pessoas envolvidas e devem ser gerenciados enquanto existirem. O prazo para execução da tarefa não deve ser aumentado, ou multiplicado por X porque um evento pode ocorrer. A probabilidade do evento ocorrer deve ser gerenciada pelo gerente de projeto e não usarmos isso na estimativa.

Nesse post, irei falar sobre algumas técnicas conhecidas para realizarmos estimativas.

  • Estimativa Única – é apresentado um único prazo. A estimativa única é recomendada quanto temos o total conhecimento sobre trabalho a ser feito.  Deve-ser tomar cuidado para não desprezar as incertezas e acabar tendo uma estimativa incoerente, por isso vale a pena usar informações de outras estimativas para efeito de comparação.
  • Estimativa Análogas – esse tipo de estimativa usa informações históricas para determinar a estimativa atual. Essa estimativa é comparada com opinião de especialistas.
  • Estimativas de três pontos – nesse tipo de estimativa é levantados valores para tempo e custo para considera-se os situações para estimativas (O)otimista, (P) pessimista e (M) mais provável para cada atividade. Com esses três valores pode-se chegar ao valor esperado das tarefas através da fórmula de Pert e o desvio padrão das atividades.
  • Estimativa Heurística – heurística nada mais é que “simplificar” um procedimento ou definir substituíções para uma solução. Um exemplo é a regra 80/20 (princípio de Pareto) que diz que 80% das consequências vêm de 20% das causas. “O trabalho do testador representa 30% do trabalho de desenvolvimento”, esse é um outro exemplo desse tipo de estimativa.

Essas são alguns técnicas conhecidas para estimativa de tempo. Essas técnicas são aplicas na Gerência do Tempo no processo de “Estimar a duração das atividades” no PMBOK. Em um próximo post quero faltar sobre técnicas de estimativas Agile. Acho que esse tema sobre estimativas de projetos pode resultar em muitos posts ).

Vamos em frente. Até mais !

Business Case de um projeto

Business Case é um documento utilizado para auxiliar na aprovação do projeto e justificar sua execução. Um projeto com Business Case forte tem, ou pelo menos deveria ter, uma prioridade maior em relação aos demais. O estudo para definir o Business Case auxilia na definição e justificativa a real necessidade do projeto e ajuda a determinar o quanto o projeto está alinhado ao plano estratégico da empresa;

No PMBOK e para quem está se preparando para certificação PMP, considere que há um Business Case definido para cada projeto, e este é utilizado durante o processo de seleção dos mesmos.

Infelizmente, nem sempre é isso que ocorre na vida real. Muitas vezes os projetos são selecionados e priorizados com base em outros conceitos desprezando um estudo sobre o quanto é viável a execução do projeto para a empresa.

No PMBOK, o Business Case é descrito como parte do termo de abertura do projeto. Esse documento ajuda ao gerente de projetos saber porque o projeto foi selecionado e o quanto é importante (ou não) para a empresa.

3-business-case-risks

Feedback: uma ferramenta para desenvolvimento pessoal e profissional

use-o-feedback

Umas das responsabilidades de um GP é trabalhar no desenvolvimento das pessoas da equipe. O próprio guia PMBOK incluí o desenvolvimento da equipe como uma atribuição do GP e fazer isso pode trazer grandes vantagens para o projeto.

Um feedback eficaz pode ser essencial para ajudar no desenvolvimento e amadurecimento da equipe. Agora, quem estiver dando o feedback deve está preparado para fazê-lo. Feedback positivo é fácil de dar, é motivante e não envolve riscos. Dar feedback negativos exige certos cuidados para que não gere ofensas ou desmotivações na equipe.

O objetivo principal do feedback deve ter sempre mudar as pessoas e o ambiente de trabalho para melhor. Porém, um feedback negativo pode trazer alguns riscos mesmo que você esteja dizendo a verdade, porém a verdade, às vezes, dói.

No livro “Inteligencia Emocional para Gerentes de Projetos” o autor aborda a importância do feedback para o amadurecimento e no desenvolvimento das pessoas.

Segue a abaixo algumas dicas para dar feedback construtivos :

  • Basea-se em fatos : Use fatos para embassar suas opiniões. Devemos tomar cuidado com conclusões sem fundamentos.
  • Seja objetivo: falar com clareza para que tudo possa ser esclarecido. Aproveite o momento para deixar claro e dê oportunidade da outra parte se pronunciar, isso também pode te ajudar a se certificar que a outra parte compreendeu o que você queria passar.
  • Seje verdadeiro e preciso: Quanto mais verdeiro for seu feedback mais valor ele terá. Um feedback impreciso será descartado e de nada vai adiantar.
  • Tenha cuidado ao usar as palavras como “sempre” ou “nunca” para descrever situações durante o feedback. Usar essas palavras você pode estar sendo impreciso, exemplo: “Você nunca chega no horário combinado”, a menos que isso seja um fato, difícilmente alguém nunca consegui chegar no horário. Pode ser que um dia a pessoa tenha conseguido chegar no horário. Isso pode ser o suficiente para o individuo preferir ignorar todo o restante que você tenha dito, pelo simples fato de que um dia ele tenha chegado no horário e a sua colocação é vista como uma mentira.
  • Concentre-se também no positivo: mesmo que seje claro os pontos forte de uma pessoa é sempre bom reconhecer. Mostrar que a empresa está vendo e reconhecendo o funcionário pelas suas boas ações motiva. Parabenize sua equipe pelas coisas boas ! Busque está presente nesses momentos, não perca a oportunidade de motivar a equipe.

Eu particularmente acho importante dar feedback para pessoas e acho que esse momento deve ser aproveitado para receber também críticas e sugestões. Deve ser um momento de troca entre as partes envolvidas. Como líder ou gerente de projeto acho importante você se mostrar aberto para escutar a opinião dos membros da equipe. Isso também vai ajudar você crescer como pessoa e como profissional.

Priorizar requisitos com o modelo de Kano

O modelo de Kano foi criado nos anos 80 pelo professor Noriaki Kano. Esse modelo tem como objetivo auxiliar na priorização dos requisistos de um produto ou serviço e com isso atender melhor as necessidades dos stakeholders do projeto.

O modelo está totalmente voltado para o aumento da  satisfação do cliente.

Fazendo uma analogia ao desenvolvimento de um software, todas as funcionalidades serão tratadas como requisitos.  No modelo de Kani os requistos são classificados da seguinte forma:

  • Requisito obrigatório: caso este não seje entregue ou não esteja com o desempenho suficiente, não teremos a safistação do cliente. Agora caso ele tendo sido entregue, não aumentará a satisfação do cliente. Este é o famoso “não faz mais que a obrigação !”. Ele é o mínimo esperado !;
  • Requisto Atrativo: Se tiver ok aumentará a satisfação do cliente, caso não seje entregue não trará insatisfação. Este é o item de luxo do sistema; Requistos atrativos em geral, serão requisitos não solicitado pelo usuário porque afinal, se ele solicitar e não for atendido, na maioria dos casos, vai gerar insatisfação.
  • Requisitos unidimensionais: Esses requisitos trazem a satisfação conforme o grau de desempenho ou coerência;
  • Requisitos neutros / indiferentes: requisitos que não geram nem satisfação e nem insatisfação para o cliente;
  • Requisitos reverso: Caso ele seje entregue pode gerar insatisfação e a ausencia dele gera satisfação.
Fig 2: Modelo KaniFonte: wikipedia.org
Fig 1: Modelo Kani
Fonte: wikipedia.org

As funcionalidades são classificadas, atráves de perguntas, conforme figura 2.

perguntaKano
Fig 2 : Exemplo de perguntas – Modelo Kano.
Fonte: livro Agile Estimating and Planning

De acordo com as respostas é possível avaliar o quanto é importante a funcionalidade e o quanto essa tem influência na satisfação das partes interessadas no projeto.

É possível também utilizar os coeficientes de satisfação (CS) e/ou coeficientes de insatisfação (CI).

Fig 2: Fórmulas de coeficientes de satisfação (CS) e coeficientes de insatisfação (CI)
Fig 3: Fórmulas de coeficientes de satisfação (CS) e coeficientes de insatisfação (CI) .
Fonte: Artigo “MODELO DE KANO PARA A IDENTIFICAÇÃO DE ATRIBUTOS CAPAZES DE SUPERAR AS EXPECTATIVAS DO CLIENTE”

O modelo de Kani serve ajudar a identificar pontos que devem ser levados em consideração na hora de fazer um produto ou executar um serviço. O ponto que eu quero frisar bem é que esse modelo pode ser usado em várias áreas, não apenas em desenvolvimento de software. #FicaADica🙂

Sabe quem é o melhor vendedor do mundo ? O cliente satisfeito. Ele vende sua empresa, sua marca, seu produto e não cobra comissão.

Roger Stankewski

Cadeia de Eventos, uma metodologia mapear incertezas no cronograma de um projeto

A definição do cronograma  é um passo importante e essencial para gestão de projetos. E ele será visto por todas as partes interessadas  mesmo que em diferentes visões. Porém muitas pessoas não tem idéia de quantas incertezas podem estar ocultas ali. Atividades definidas no cronograma podem ter um probabilidade grande de não ocorrer conforme o planejado. Essas incertezas podem ser mapeadas e monitoradas ao longo do projetos através dos eventos, e mais comumente chamados de cadeia de eventos.

Em suma, eventos podem ser definidos como acontecimentos ou incertezas que podem ocorrer e mudar o que foi planejado para uma tarefa, para um grupo de tarefas ou até mesmo no cronograma como um todo. Se um evento que tem um probabilidade grande de acontecer em uma tarefa do caminho critico, isso ira afetar da data de entrega do projeto, então deve ser visto a melhor forma de tratar esse evento.

Uma tarefa pode estar associada um ou mais eventos. Ao mesmo tempo um único evento pode afetar mais de uma tarefa.

Não entenda eventos com fatores que podem apenas atrasar o cronograma, existem eventos que podem antecipar ou cancelar uma ou outra tarefa🙂.

Eventos podem ser:

  • probabilísticos : o evento x tem 20% de chance de acontecer;
  • condicional: se o evento y ocorrer, o prazo da tarefa será aumento em mais 5 dias.

Algumas literaturas sugerem um diagrama para mapear os eventos e gráficos de Gantt podem ser usados para exibir os reflexos dos eventos mapeadas nas tarefas. Com a base line do projeto definida pode-se fazer simulações sobre o que pode acontecer com os prazos, caso um ou mais eventos ocorram e suas consequencias.

O nível de detalhamento que os eventos vão ser mapeados,  irá  depender do nível de precisão que o projetos exige. Temos que lembrar sempre que …como tudo na vida, tudo tem seu preço. O esforço para manter esse nível de gestão deve ser considerado antes da adoção da prática.

Crie um website ou blog gratuito no WordPress.com.

Acima ↑