Hospedagem Profissional

Hospedagem Profissional
Clique aqui e ganhe US$ 10,00 para testar durante 1 mês a melhor hospedagem: Digital Ocean!

segunda-feira, 23 de abril de 2012

Agile BPM (Gestão por Processo Ágil)

Apresentação demonstra com aplicar as práticas ágeis a Gestão por Processo (Agile BPM).

Material disponibilizado no slideshare por Rildo Santos - www.rildosan.com

segunda-feira, 16 de abril de 2012

Cobit 5 - Disponível para download

COBIT 5 é um framework para Governança Corporativa e Gerenciamento de TI.

A versão 5, lançada em 13 de Abril de 2012,  já está disponível para download (é necessário fazer a solicitação e cadastro para fazer o download).

Incorpora as últimas novidades em governança corporativa, técnicas de gerenciamento e fornece princípios globalmente aceitos, práticas, ferramentas e modelos analíticos para ajudar a aumentar a confiança, no valor e de dos sistemas de informação.

COBIT 5 expande a COBIT 4.1 (versão anterior), integrando outras estruturas importantes, padrões e recursos, incluindo Val IT e Risk IT, ITIL® e normas ISO.

COBIT 5 – Promote os seguintes beneficios:

- Manter informações de alta qualidade para apoiar decisões de negócios

- Alcançar objetivos estratégicos e benefícios  através da utilização eficaz e inovadora de TI

- Alcançar a excelência operacional através da aplicação confiável e eficiente da tecnologia

- Manter riscos relacionados a TI  a um nível aceitável

- Otimizar o custo dos serviços de TI e de tecnologia

- Suporte à conformidade com leis, regulamentos, acordos contratuais e políticas

Cobit 5 inclui:

- Cobit 5 - Framework (gratuito)

- Cobit 5 - Enabling Processes (gratuito para membros do ISACA) , cópia impressa ou PDF  US$ 135.00

- Cobit 5 - Implementation (gratuito para membros do ISACA) , Cópia impressa ou PDF  US$ 150.00

- COBIT 5 - Toolkit (gratuito) – É conjunto de recursos que ajuda na implementação do Cobit

- COBIT 5 Framework Overview (gratuito) – Figuras que demonstram o Cobit

- COBIT 5 Bundle - Pacote com as três publicações - Cópia impressa ou PDF  US$ 225.00

Solicite o Cobit 5 Framework

Como Fazer a Integração entre BPM e SOA

Apresentação demonstra uma simples visão de como fazer a integração entre BPM e SOA.
Primeiro é conceituado a BPM, depois a SOA e por fim como fazer a integração.
Também é apresentado um estudo de caso.

Material disponibilizado no slideshare por Rildo Santos - www.rildosan.com

quarta-feira, 11 de abril de 2012

Guia BPM CBOK

Objetivo é Apresentar uma visão geral do BPM CBOK® que é um guia de práticas para Gerenciamento de Processos de Negócio.
Vamos discutir o que é guia BPM CBOK, definir quem é o Analista de Processo de Negócio, o que ele faz, exibir alguns conceitos básicos, tipos de processos, áreas de conhecimentos, ciclo de vida BPM, Nível de Maturidade e Fatores-Chave de Sucesso.

Material disponibilizado no slideshare por Rildo Santos - www.rildosan.com

Analista de Negócio Ágil

Esta apresenta demonstra como o Analista de Negócio pode utilizar os Métodos Ágeis para gerar valor ao negócio.

Material disponibilizado no slideshare por Rildo Santos - www.rildosan.com

Guia de Orientação para Carreira de Analista de Processos

Guia de Orientação da Carreira de Analista de Processos descreve os conhecimentos, práticas, técnicas, competências e ferramentas necessárias para o Analista de Processo realizar suas atividades.

Material disponibilizado no slideshare por Rildo Santos - www.rildosan.com

10 dicas para destruir uma equipe competente

Todos sabemos como é árduo formar uma equipe eficiente. Em muitas situações são anos de tentativas, com erros e acertos até que em um determinado momento a orquestra se forma.

Geralmente ela é entrosada, comprometida, dotada de uma cultura própria, mas que convive com as particularidades. Ela é o sonho de 10 entre 10 empresários inteligentes.

Mas nem todos atingem esse êxito ao formarem seus quadros, porém entre aqueles que conseguem, um bom número se afunda nas armadilhas do processo de gestão e invariavelmente acabam por destruir aquilo que construíram.

Desta vez, caminhando no sentido inverso, apontaremos aquelas atitudes e práticas que servem para acabar de vez com uma equipe invejável.

Vamos lá:

1. Atue coberto de soberba e crie um mito sobre você mesmo. Para os seus colaboradores você sempre tem razão;

2. Seja grosseiro ao tratar com as pessoas. Trate-as com desrespeito, com expressões e atitudes rudes e duras;

3. Preocupe-se excessivamente na sustentação da sua autoridade. Preferencialmente imponha-se pelo medo causado, sem se preocupar em ser respeitado de verdade;

4. Persiga e prejudique as carreiras daqueles que são mais críticos. Para estes não abra espaço nem oportunidades. Eles são do contra e não merecem atenção;

5. Trabalhe e exija metas absurdas e inalcançáveis, sempre sob a ótica de que quanto mais pressão melhor;

6. Mantenha um clima de profunda e aguda exigência sobre tudo. Aproveite a oportunidade e elimine o senso de tolerância;

7. Esteja sempre bravo e irritado;

8. Cultive o stress como um valor, crente de que quanto mais melhor;

9. Prestigie seus colaboradores por critérios subjetivos, dignos de uma boa psicologia corporativa de botequim. Deixe de lado o conceito de meritocracia;

10. Atue de forma que a confiança na sua palavra seja nenhuma, afinal de contas você não deve satisfações a ninguém;

 

Por: Gustavo Chierighini, fundador da Plataforma Brasil Editorial em Saia do Lugar

terça-feira, 3 de abril de 2012

Comparativo PMBOK x Scrum

Este é um ótimo artigo escrito por Élio Rodrigues em seu site http://elirodrigues.com

Sempre houve muita polêmica entre os “partidários” do PMBOK e Scrum, muitos acreditam precisar optar, mas as diferenças começam no entendimento da natureza distinta, mas não excludente que os permeia. O PMBOK é um guia de boas práticas, dividido em grupos e processos [1], já o Scrum é um framework (estrutura) com cerimônias, artefatos e papéis definidos [2]. Como comparar um guia a uma estrutura?

Sendo uma estrutura, o Scrum permite adições e exclusões, desde que não interfiram em seus 3 princípios: Transparência, Inspeção e Adaptação [2]. Desse modo, pode-se dizer que tecnicamente seria possível adicionar processos adaptados do PMBOK ao Scrum, mas vale a pena?

O Scrum se adapta mais a projetos cujo escopo é mutável e/ou parcialmente desconhecido. No PMBOK não conhecer o escopo (ou pelo menos parte dele) inviabiliza o planejamento e assim, a execução do projeto. O Scrum aceita incertezas, trabalha com priorizações (valores de negócio) e ciclos curtos de entregas. O PMBOK trabalha com riscos, pode priorizar entregas (embora não comente sobre isso)  e fazer ciclos de entregas (planejamento em ondas sucessivas). Futuramente vou apresentar um processo híbrido, mas por hora, irei apenas fazer um comparativo entre PMBOK e Scrum.

Metodologia

Para realizar esta análise, tomei como linha de base o PMBOK, por possuir processos em maior granularidade que o Scrum, facilitando comparativos. Listei todos os processos, criei uma escala de 0 a 4 pontos (0 – Não atende e 4 – Atende completamente) demonstrando o grau de atendimento, pontuei o Scrum em relação a cada processo e adicionei comentários com o racional.

A quarta edição do PMBOK está estruturada em 5 grupos de processo, 9 áreas de conhecimento (ou disciplinas) e 42 processos. Na metodologia utilizada, cada processo vale até 4 pontos, deste modo, o total possível de pontos é de 168 (4 pontos x 42 processos).

Obs: A análise foi subjetiva e pessoal, é passível  de discussão e por isso disponibilizei a planilha paradownload, caso alguém deseje complementar o estudo.

Resultados

De acordo com a análise realizada, o Scrum atende a 42% dos processos do PMBOK (somando 70 dos 168 pontos). A Figura1 apresenta o atendimento percentual de cada uma das nove Área de Conhecimento, ficando clara a ausência de processos para tratativa de Custos, Riscos e Aquisições no Scrum e a forte ênfase em Integração, Escopo, Tempo e Recursos Humanos.

Figura1 - Mapeamento dos processos do PMBOK versus Scrum

Para a área de Riscos foi considerado 1 ponto, referente ao “Mapeamento de Impedimentos” (prática diária de responsabilidade do Scrum Master), pois se a equipe levantar os impedimentos com antecedência, pode-se evitar problemas, uma forma “primitiva” de gerenciamento de riscos. No entanto, acredito que certas características do Scrum previnem problemas comuns e isso seria uma forma de gerenciamento de riscos (I.E. Sprints com tempo pré-definido, revisões de entregas, reuniões de retrospectiva, ter um SPOC*, ter um plano de comunicação etc).

*SPOC = Single Point of Contact

Figura2 - Atendimento do Scrum aos grupos de processo do PMBOK

A Figura2 apresenta o atendimento por grupos de processo e mostra claramente a preocupação do Scrum com Planejamento, Monitoramento e Controle e Execução, deixando fora do escopo doframework os grupos de Iniciação e Encerramento. Ainda assim, considerou-se a “Definição da Visão do Projeto”  como o equivalente ao “Desenvolver o Termo de abertura” (4.1) , pontuando-se com 1 ponto (de um total de 4). Para o ”Encerrar o projeto ou fase” (4.6), foram considerados 2 pontos, pois o Scrum controla o andamento do projeto, o encerramento de cada fase e as lições aprendidas, embora não determine em detalhes como encerrar um projeto (resolver pendencias, encerrar contratos, registro de questões etc).

Figura3 - Atendimento do Scrum por áreas de conhecimento do PMBOK

E finalmente, na Figura3 pode-se ver que das 5 áreas que possuem maior número de processos no PMBOK (Integração, Tempo, Riscos, Escopo e Comunicação), 4 também são priorizadas pelo Scrum, tendo como única exceção a área de riscos.

Conclusão

O Scrum que originalmente era exclusivo do desenvolvimento de software, atualmente tem sido aplicado em diversas áreas como: Recursos Humanos, Finanças, Publicidade, Traduções de textos e ainda pode ser aplicado em muitas outras, que requerem menos formalidade e possuam o ambiente propício. Ainda assim, seus “redatores” tem se preocupado em tornar o framework cada vez mais simples e adaptável, caminho inverso do PMBOK.

Se me permitem uma sugestão, sugiro que o Scrum adote práticas de Gerenciamento de Riscos e não apenas impedimentos e lições aprendidas, estando assim alinhado aos grupos de processos mais significativos (com maior número de processos) do PMBOK, ou seja, cobrindo a maior parte das necessidades de um projeto.

Bibliografia

[1] Introdução a Gestão de Projetos -  http://elirodrigues.com/gestao-de-projetos/gestaoprojetos/

[2] Scrum Guide – http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%20PTBR.pdf

[3] Sopa de letrinhas da Gestão de Projetos - http://clarifygp.wordpress.com/2012/02/16/sopa-de-letrinhas-da-gestao-de-projetos/

Fonte: Élio Rodrigues

segunda-feira, 2 de abril de 2012

5º Princípio do Manifesto Ágil – Motivação

“Construir projetos com indivíduos motivados. Dê a eles o espaço de trabalho e apoio de que necessitam, e confie neles para ter o trabalho pronto” (Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done)

Veja mais em http://manifestoagil.com.br

Este princípio trata de mais um conceito para o qual não existe uma bala de prata: a motivação da equipe. A única certeza que temos sobre esse tópico é que cada indivíduo é diferente do outro e se motiva de forma distinta. Então, como resolver essa questão? Na verdade, não vou propor uma solução ótima. A intenção aqui é apenas identificar pontos que podem auxiliar as empresas a terem empregados mais motivados.

O primeiro deles é justamente a confiança dos superiores no trabalho desempenhado pela sua equipe. É preciso dar autonomia aos seus empregados para decidir como uma determinada tarefa será desempenhada e confiar que essa decisão trará o melhor resultado possível. Essa atitude traz para a equipe auto-confiança, estímulo a buscar sempre realizar o melhor e, em alguns casos, soluções mais rápidas ao cliente.

O segundo é o relacionamento entre a equipe e entre ela e seus superiores. Os sentimentos de equipe e de colaboração devem ser garantidos entre todos e de forma uniforme. Não se pode influenciar no nível de relacionamento pessoal de cada um, mas promover um senso de igualdade dentro do ambiente de trabalho é importante e faz diferença. Nenhum membro da equipe pode se sentir de fora dela, nem mesmo o líder. É preciso que ele se sinta parte da equipe e compartilhe com ela, sempre que possível, os rumos do projeto. Expôr o porquê das decisões e ouvir o que a equipe tem a dizer sobre elas faz com que a mesma se comprometa com o projeto.

O ambiente de trabalho e os recursos disponíveis também são fatores de muita influência na motivação da equipe. Os recursos necessários para o desempenho do trabalho devem estar disponíveis e serem de um nível adequado às necessidades da equipe. Vale também ressaltar que o espaço de trabalho deve tornar o tempo de trabalho mais confortável e agradável e não o contrário.

Por último, mas não menos importante, o aprendizado. As pessoas atualmente estão em busca de trabalhos que possam também lhes trazer retorno intelectual, ou seja, querem aprender coisas novas. Então, sempre que possível, invista em seus empregados. Promova treinamentos, debates, palestras e etc. Mostre que você se importa com o desenvolvimento deles.

Como foi dito anteriormente, não há uma fórmula mágica para a motivação. No entanto, algumas práticas, como as citadas acima, podem ajudar a melhorar a satisfação da equipe. E lembre-se: não apenas ouça o que sua equipe tem a dizer. Realmente preste atenção às suas opiniões e sempre que possível, tome atitudes em relação a isso.

 

Fonte: Paula Nascimento em Scrum Half Blog

E a Gerência no Scrum, como fica? A Teoria Y explica!

É interessante ver a surpresa das pessoas quando falamos dos 3 papéis do Scrum:

   – Product Owner,

   – Scrum Master e

   – Equipe de Desenvolvimento.

Eles logo perguntam: "E o gerente?", "Quem é o gerente no Scrum"?

Não tem gerente. Pelo menos não na forma tradicional. O que temos no Scrum é uma gerência distribuída.

Gerência Distribuída no Scrum

  • O Product Owner é responsável pela macro-gerência, ou seja, ele é o responsável por gerenciar "O Quê" deve ser feito.
  • A Equipe de Desenvolvimento é responsável pela micro-gerência, ou seja, ela é responsável por gerenciar "Como deve ser feito".
  • O Scrum Master é responsável por gerenciar o processo, ou seja, garantir que os valores do Scrum estão sendo postos em prática.

Mas ainda assim, mesmo apresentando essa explicação ainda é possível ver que a surpresa se mantém. Pois como uma equipe vai caminhar sem um gerente para olhar o que está sendo feito, o como está sendo feito?

Simplesmente porque a Equipe de Desenvolvimento no Scrum é uma equipe auto-organizável, capaz de conduzir seus trabalhos e compromissos assumidos planejando a cada dia sua estratégia de trabalho em equipe.

E é aí que entra a explicação pela Teoria Y.

Teoria X e Y

A  Teorias X e Y são dois conceitos antagônicos, criados pelo professor e economista americano Douglas McGregor. Essas teorias apresentam dois perfis comportamentais e de personalidade da relação das pessoas com seu trabalho.

Na Teoria X temos o indivíduo trabalhando por necessidade para alcançar algum objetivo, mas que se pudessem alcançar de outra forma certamente o fariam. Os indivíduos que se classificam segundo a Teoria X não gostam de assumir responsabilidades e preferem ser dirigidos (gestão pelo comando-controle).

Para os indivíduos que se classificam na Teoria Y temos o inverso:

"O trabalho é tão natural como o lazer, se as condições forem favoráveis”.

Embora tenham também seus objetivos e ideais, são indivíduos que possuem motivação natural para o trabalho e o esforço físico e mental empregado no trabalho é tão natural quanto o empregado em momentos de lazer. E não só assumem responsabilidades quanto as buscam também. Para os profissionais que se enquadram dentro dessa Teoria Y, as empresas e organizações adotam medidas inovadoras e humanistas, dentre as quais podemos citar medidas diretamente relacionadas com os valores do Scrum:

Equipes Auto-Organizáveis

Portanto, a Teoria Y explica! Para uma equipe auto-organizável é fundamental que ela seja composta por indivíduos que se enquadrem na Teoria Y.

Indivíduos motivados e comprometidos com o trabalho e as responsabilidades assumidas. E se você não se enquadra nesse modelo… Então "pede pra sair".

 

Fonte: Ester Lima em Scrum Half Blog