Ricardo Peters

Avaliador MPS.BR

2011-07-30T09:43:00.001-03:00

Na primeira fase já passei. Agora só falta a prova ;)
http://softex.br/mpsbr/_noticias/noticia.asp?id=3680

Gestão de Serviços (ITIL V3)

2011-07-26T11:16:00.003-03:00

No dias 22 e 23 de julho o Grupo LED esteve em Recife para o curso "Gestão de Serviços (ITIL V3)", disciplina da pós graduação em Governança de TI do CESAR.edu , com carga horária total de 16 horas, coordenada pelo facilitador Ricardo Peters. Estiveram presentes:

Alcilene Dias de França
Cícero Marcelo Trindade Lins
David Saraiva do Amaral Filho
Diogo Lima Catão
Gleibson Rodrigo Silva de Oliveira
Ioná Leite Mota
Massilon Gomes da Silva Júnior
Naize Moreira de Andrade Santos
Vanessa Figueiredo Trajano

Obrigado a todos pela participação!

Cavalgando cavalos mortos

2011-06-23T10:07:00.001-03:00

A sabedoria da tribo Dakota prega que quando você perceber que está cavalgando um cavalo morto, a melhor estratégia é descer do cavalo. Entretanto, no mundo dos negócios, nós tentamos outras estratégias, incluindo:

Comprar um chicote mais forte.
Trocar o cavaleiro.
Dizer coisas como: "Esta é a maneira que sempre montamos este cavalo".
Nomear um comitê para estudar o cavalo.
Visitar outros locais para analisar como eles montam cavalos mortos.
Elevar os padrões para cavalgar cavalos mortos.
Nomear uma Equipe de Elite para reviver o cavalo morto.
Realizar uma sessão de treinamento para aumentar a nossa capacidade de equitação.
Comparar o estado de cavalos mortos ao ambiente atual.
Alterar os requisitos declarando que "Este cavalo não está morto."
Contratar fornecedores para montar o cavalo morto.
Reunir vários cavalos mortos juntos para aumentar a velocidade.
Declarar que "Nenhum cavalo está tão morto que não possa ser chicoteado."
Conceder financiamento adicional para aumentar o desempenho do cavalo.
Fazer uma Análise de Custos para ver se os fornecedores podem montá-lo a um preço mais baixo.
Comprar um produto para fazer cavalos mortos correrem mais rápido.
Declarar que cavalos são "melhores, mais rápidos e mais baratos" quando estão mortos.
Formar um círculo de qualidade para encontrar usos para cavalos mortos.
Rever os requisitos de desempenho para cavalos.
Dizer que este cavalo foi adquirido como custo de uma variável independente.
Promover o cavalo morto a uma posição de supervisão.

Texto Original:

Dakota tribal wisdom says that when you discover you are riding a dead horse, the best strategy is to dismount. However, in business we often try other strategies with dead horses, including the following:
Buying a stronger whip.
Changing riders.
Say things like, "This is the way we have always ridden this horse."
Appointing a committee to study the horse.
Arranging to visit other sites to see how they ride dead horses.
Increasing the standards to ride dead horses.
Appointing a tiger team to revive the dead horse.
Creating a training session to increase our riding ability.
Comparing the state of dead horses in todays environment.
Change the requirements declaring that "This horse is not dead."
Hire contractors to ride the dead horse.
Harnessing several dead horses together for increased speed.
Declaring that "No horse is too dead to beat."
Providing additional funding to increase the horse’s performance.
Do a Cost Analysis study to see if contractors can ride it cheaper.
Purchase a product to make dead horses run faster.
Declare the horse is "better, faster and cheaper" dead.
Form a quality circle to find uses for dead horses.
Revisit the performance requirements for horses.
Say this horse was procured with cost as an independent variable.
Promote the dead horse to a supervisory position.

Oficina Scrum em Brasília

2010-11-05T17:18:00.000-03:00

Aprenda a gerenciar projetos com um framework que é sucesso no ambiente de desenvolvimento de software: Scrum!

http://www.grupoled.biz

Aguarde... III

2010-11-03T15:15:00.001-03:00

"Não há títulos em Times, e não há exceções a essa regra." - Aguarde: 05/11/2010

Aguarde...

2010-10-26T08:46:00.001-03:00

"Os membros do time são “porcos”. Qualquer outro é chamado de “galinha”. “Galinhas” não podem dizer aos “porcos” como eles devem fazer seu trabalho." - Aguarde 05/11/2010

Aguarde 05/11/2010

2010-10-25T10:50:00.002-03:00

"Somos um time de alto desempenho, utilizamos o conceito na prática, mas não somos jogadores de rugby." - Aguarde 05/11/2010

Gestão de Projetos :: Turma 1

2010-02-11T17:05:00.000-03:00

Nos dias 5 e 6 de fevereiro de 2010, realizamos no Hotel Dorisol, em Piedade, Jaboatão dos Guararapes - PE, a minha primeira turma do curso Gestão de Projetos do Programa Excelência em Gestão de Negócios, promovido pela KM Consultores Associados. Nas fotos alguns dos momentos compartilhados entre o grupo. Parabéns a todos!

Sistemas de Informação em Marketing :: Turma 3

2010-02-11T16:36:00.001-03:00

Concluímos, em 30 de janeiro, a terceira turma do curso Sistemas de Informação em Marketing, do CBS/KM (CEDEPE Business School - KM Consultores Associados), realizada no Hotel Dorisol, em Piedade, Jaboatão dos Guararapes - PE. Nas fotos, momentos em que o grupo debatia sobre o tema.
Parabéns a todos!

Certificações em Gerenciamento de Projetos

2009-09-03T10:43:00.001-03:00

Se você pensa em obter uma certificação em gerenciamento de projetos, utilize a tabela a seguir para auxiliar na tomada de decisão:

“Sempre fui e sempre serei desorganizado”

2009-05-02T12:02:00.006-03:00

Ao contrário do que algumas pessoas pensam, desorganização, dificuldade em definir prioridades e uso inadequado do tempo disponível, não são características genéticas que passaram de pais para filhos, mas fruto de influências externas, consideradas por nós como referências na tomada de decisões.

Em algum momento, no entanto, essas pessoas podem ter simplesmente desistido de melhorar, por acreditar que ser disciplinado em relação ao uso do tempo, baseado em suas referências, era simplesmente impossível. A boa notícia, entretanto, é que assim como os maus hábitos foram adquiridos, eles podem ser "desaprendidos" e substituídos por hábitos que podem fazer a diferença.

Atitude que conduz à mudança só é despertada por um profundo desejo de mudar e pela percepção, clara e inequívoca, de que a ela é necessária e possível. Alguém comentou comigo uma vez que: "(...) há sempre muitas iniciativas, mas realmente, pouquíssimas terminativas". Para mudar é preciso vontade, persistência e determinação para ir até onde se propôs ir.

Vale lembrar ainda que, mudanças radicais, apesar de serem possíveis, por vezes são dolorosas e podem parecer desafiadoras demais, levando à desistência, quando não se consegue perceber resultados no curto prazo. A alternativa é uma mudança gradativa, formada de pequenas vitórias nas tarefas e atividades do dia a dia, que aumentam a confiança e o sentimento de progresso. Stephen Covey, autor dos "7 hábitos para pessoas altamente eficazes", ressalta que não somos fruto de nossa genética, mas de nossas escolhas; e nessas escolhas, certas ou erradas, somos soberanos. Portanto, ser ou não desorganizado, usar bem ou mal seu tempo, é sempre uma questão de escolha. Pense nisso!

Na prática: experimente estabelecer um objetivo para a próxima semana. Algo que você queira mudar, mas ainda não teve sucesso. Não escolha nada muito difícil, mas um pequeno aspecto de sua vida que você tem certeza de que, esforçando-se, conseguirá vencer. Coloque como meta, realizar essa mudança durante 30 dias. Se um mês parecer muito, tente apenas uma semana.

Se você tem dificuldade em chegar na hora no serviço, por exemplo, tente acordar 20 minutos mais cedo na próxima semana, e monitore os resultados. Registre num pedaço de papel quantos dias você conseguiu cumprir o acordado, e ao término da semana, tente lembrar-se das razões pelas quais você falhou e o que pode fazer parar que não falhe na próxima semana. Lembre-se também de se dar o crédito pelo seu esforço e mantenha o foco no sucesso alcançado naquela semana. Quando estiver dominando esse objetivo, estabeleça outro um pouco mais desafiador. Não pare mais esse processo, e jamais desista.

*************************************
“I've always been and always will be a messy person”

Despite of some people might think, being messy, having trouble setting priorities and unwise use of time available are not part of our genetic make-up passed throughout generations, but the result of external influences, many times considered by us as reference point in decision-making processes.

At some point of their lives, however, these people could have given up improving their ways, most of all because of the false belief that being disciplined regarding the good use of time, based upon what they have seen, was simply impossible. The good news is that the same way bad habits were acquired, they can be “unlearned” and replaced by better habits that can make a real difference.

Attitude leading towards change can only be acquired by a deep desire of change e by knowing in a clear and unambiguous way, that change is required and possible. Someone once told me that “(...) there are always many initiatives, but only a few finishatives” (something might have been lost translating this into english, sorry about that, but I hope you get the idea, sounds weird in portuguese too ;). To change that desire, persistence and determination are needed to go as far as one had decided to go.

It is good to keep in mind that radical changes, although possible, many times are painful and may seem too challenging, leading to a strong urge to quit when it is hard to notice short term results. The alternative is changing slowly, step by step, achieving small victories on a daily basis. This will increase self-esteem and the sense of progress. Stephen Covey, author of “7 habits of highly effective people” tells us that we are not the product of our genetic make-up but of our choices; and by deciding about these choices, right or wrong, we are totally accountable. So, to be or not to be a messy person, use your time well or not, is always a matter of choice. Think about it!

Practical suggestion: try to establish a goal for next week. Something you want to change, but still haven't been successful doing it. Do not choose something very difficult, but a small aspect of your daily life that you know you can do it if you set your mind into it. Set it as a goal to do that for 30 days. If a month seems too much, do it for a week.

For instance, if you have trouble getting to work on time, try waking up 20 minutes early next week and check the results. Record in a piece of paper how many days you succeeded fulfilling the agreement and, at the end of week, try to remember the reasons why you have failed doing it and what you could do to keep you from failing again next week. Remember also to give yourself credit for your efforts and focus on the success achieved last week. When you have mastered this goal, set another one, a little more challenging. Don't stop this process (ever) and never quit.

Os truques Ninja do Gmail

2009-02-25T10:09:00.003-03:00

Algumas dicas que aprendi para refinar as buscas por mensagens no Gmail e achei interessante compartilhar. Esses atalhos facilitam bastante, e também estão disponíveis na página de busca do gmail. N!ao utilize as aspas, apenas as expressões entre elas.

"is:unread" - Para localizar todas as mensagens que ainda não foram lidas
"from:email@gmail.com is:unread" - Para localizar todas as mensagens não lidas de um e-mail específico
"has:attachment" - Localiza mensagens que possuem anexos
"is:chat" - Localiza conversas de chat armazenadas
"from:email@gmail.com is:chat" - Muito bem! Você entendeu a idéia.
"is:starred" - Retorna mensagens marcadas com
"subject:" - Pesquisa no assunto das mensagens
"to:me macetes" - Pesquisa todas as mensagens enviadas para mim que contenham a palavra "macetes" em qualquer lugar da mensagem.
"to:me -macetes" - Pesquisa todas as mensagens enviadas para mim que não possuem a palavra "macetes
"after:2008/2/25 before:2010/2/26" - Pesquisa todas as mensagens com data posterior a 28 de fevereiro de 2008 e 26 de fevereiro de 2010.

Um vôo atípico para Salvador

2009-02-02T21:04:00.003-03:00

No último sábado, foi a primeira vez que viajei para Brasília, fazendo conexão em Salvador e levando o triplo do tempo que levaria em um vôo direto, sem reclamar. Valeu a pena saber falar inglês e estar no lugar certo, na hora certa...

Fui à Brasília para fazer uma prova, mas em especial para passar alguns momentos com a família. Ao chegar no salão do aeroporto em Recife, e confirmar que o vôo estava atrasado, vi um grupo do que pareciam ser norte-americanos sentados juntos conversando e falando inglês em alto e bom tom, como se ninguém perto deles entendesse mesmo o que estavam dizendo.

Deduzi rapidamente que eram músicos, pelo tipo de chapéu que cada um usava e em especial porque um deles tinha um pequeno violão (muiiiito legal) de onde estava tirando um som sensacional. Por gostar de música, acabei sentando próximo, para ficar ouvindo e me distrair do maçante atraso a que, infelizmente, estamos sendo obrigados a nos acostumar aqui no Brasil.

À minha frente, numa mesinha de café, um deles conversava (em inglês) com um brasileiro enquanto tomavam café. Também falavam alto, e não pude deixar de ouví-los, mesmo sem querer. O brasileiro perguntou: - Vejo que vocês são músicos, estão de férias aqui no Brasil?
O outro respondeu: - Na verdade estamos em uma turnê com a Banda...
- E qual é a banda de vocês? O brasileiro perguntou.
- A banda da Alanis Morissette.

Foi nesse momento que meu queixo caiu, os ouvidos abriram ainda mais e os olhos começaram a moverem-se descontroladamente para todos os lados procurando, procurando... Para minha alegria, o brasileiro também se surpreendeu e (quase tirando as palavras da minha boca) perguntou:

- Uau, vocês fizeram um ótimo show ontem à noite! Onde ela está?
- We are hanging out here... The big boss is over there... E ele apontava para a sala VIP da TAM.
Nesse momento acho que eu era o único (além do outro brasileiro, é claro) que sabia que eles tocavam com a Alanis, e ela estava ali, na salinha... Maldito cartão fidelidade vermelho! O meu ainda é branco... :(

Bem, fiquei mais atento e percebi a movimentação discreta dos comissários que vieram pelo cantinho e rapidamente a conduziram pelo corredor de embarque em direção ao avião. Acho que só eu percebi, afinal ela estava com óculos escuros que ocultavam metade de todo o rosto e saiu cercada de gente comum, e não seguranças. Tudo muito rápido e sutil.
Uou! Alanis ia no meu vôo pra Salvador... Deixa estar... No avião eu chego lá para falar com ela...

Encurtando: não consegui falar com ela. Ela sentou cinco fileiras na minha frente, fechou a janela e colocou duas pessoas: uma no meio e outro no corredor. Uma fileira de músicos da banda na frente, atrás e do outro lado; os óculos ficaram durante o vôo... o acesso ficou difícil. Parecia que ela não estava no clima para tirar uma fotografia mesmo... Mas valeu só a curtição.

Minha música favorita dela é "You Learn" e adoro o cd "Jagged Little Pill" além do "Acústico".

Gestão do Conhecimento na Prática

2009-01-30T09:40:00.003-03:00

Ontem concluímos as atividades da minha primeira turma de Gestão da Informação e Processos Organizacionais da FBS (Fafire Business School), curso de Pós-graduação aqui em Recife, Pernambuco. Muita qualidade nas participações e um clima dinâmico e descontraído durante os encontros foram o destaque. Aprendi bastante com os novos amigos (da esquerda para a direita) Anderson, Thiago, Moisés (esses dois, velhos amigos), Mauro e Charles, além das mocinhas Melina e Valéria. Uma imagem do momento de descontração proporcionado durante o "Guarascoito" (Guaraná+Biscoito), servido no padrão das melhores cozinhas internacionais.
Meu sincero agradecimento pelos bons momentos!

O e-mail de mil e uma utilidades

2008-12-19T10:57:00.003-03:00

Lembro-me que há cerca de doze anos, quando eu trabalhava como estagiário na Radiobrás, o e-mail ainda era um ilustre desconhecido para algumas pessoas. Houve ocasião em que uma das colegas fez questão de lembrar à chefe que um cliente gostaria de conversar com ela com urgência e que já até havia passado um "ê-maíu" reclamando; alguns levantaram a cabeça como se tivessem escutado algo novo, e apertaram os olhos, curiosos. A chefe, sempre cortês, procurou resolver rapidamente a questão:
"Obrigada; por favor diga a ele que responderei o e-mail ainda hoje".

Naquela época, poucas pessoas tinham acesso a contas de correio eletrônico, e os webmails gratuitos ainda estavam começando a construir seus modelos de negócio. De lá para cá, é difícil encontrar alguém que ainda não tenha compreendido a importância dessa ferramenta. A rápida troca de mensagens, tornou-se uma maneira de tornar formal acordos que antes eram verbais e informais.

Não é raro encontrar pessoas que esqueceram as regras básicas da boa educação e que numa conversa face a face, após combinar alguma coisa de seu interesse com a outra pessoa, acabam por solicitar: "Me mande um e-mail, para que eu não me esqueça". Em outras situações, entretanto, essa é a ação mais inteligente, em especial no ambiente corporativo: muitos acordos são realizados em reuniões sem ata, ou através de ligações telefônicas. Para garantir que os acordos foram entendidos por ambas as partes, essa "formalização" normalmente se dá via e-mail. As pessoas guardam aquela mensagem como se fosse um documento que comprova o que foi dito e acordado, para que, se a contra-parte esquecer-se disso no futuro, possa ser lembrada de que foi combinado. Concordo com isso. E-mails contam histórias. Nós temos a memória curta, e defendo sempre colocar as coisas no "papel" (ou seria no video ;), ou seja, tirar as idéias da cabeça e colocá-las por escrito para nos certificar-mos de que estão claras o suficiente e de que foram corretamente entendidas. Muitos conflitos são evitados nas organizações através dessa prática. Pouco a pouco, o correio eletrônico vem substituindo memorandos e o famigerado caderninho de assinaturas (aquele que toda secretária pede para você datar e assinar quando está entregando ou recebendo um documento), considerando as confirmações de recebimento e leitura oferecidos pela maioria dos programas; mas o danado do caderninho ainda persiste...

E-mail é um recurso simples que facilita bastante a comunicação. Mas as vantagens não vêm sem alguns efeitos colaterais indesejáveis. Dois grandes problemas prejudicam a comunicação oferecida por essa fantástica ferramenta: o SPAM (Receber mensagens que não te interessam, tão irritantes quantos as propagandas pouco ecológicas que chegam pelo correio) e a ignorância. Correntes e ppts anexados são dois dos maiores desperdiçadores de tempo nos últimos dez anos.

Um exemplo corporativo: um gerente coordena 10 colaboradores. Para manter o gerente informado de suas ações (e evitar que ele depois diga que não sabia o que estava acontecendo), por receio ou falta de confiança, cada mensagem enviada pelo colaborador para outras áreas da empresa ou para clientes, é também copiada para o Gerente. Se em um dia de trabalho, o colaborador enviar 10 mensagens, o gerente terá que acompanhar:

100 mensagens por dia;
500 por semana;
2000 por mês e
24.000 por ano.

Resultado: o gerente não lerá as mensagens dos colaboradores e não responderá aquelas que forem realmente importantes pela dificuldade em separar o joio do trigo, passando a ignorá-las. Por mais ilógico que isso possa parecer, já trabalhei em empresas onde isso era uma prática frequente. O volume de mensagens era absurdo.

Outro exemplo curioso são as listas que agrupam, setores, diretorias ou (ai, ai) toda a empresa. Pense bem: será que um colaborador deve se dirigir a toda a empresa? Não me entenda mal, sou a favor da liberdade de expressão e do livre fluxo de informações, mas será que todos os colaboradores têm o discernimento para identificar que tipo de informação interessaria a todos? A coisa piora quando, após enviada a mensagem para essa lista, começam as respostas, que atingirão a todos da lista; assim, uma mensagem indesejada enviada a 5oo colaboradores, reúne em si o potencial de receber 500 respostas... Com certeza, são raras essas mensagens e esse não é um recurso que deve estar acessível para toda a organização. O e-mail não existe para ser utilizado como "transferência de responsabilidade", mas como instrumento de cooperação e troca eficaz de informações.

Algumas sugestões sobre como proceder:

E-mail não é chat; evite enviar mensagens fazendo apenas uma pergunta, pois elas serão respondidas com respostas curtas que podem gerar outras perguntas (PING-PONG) ... às vezes é melhor telefonar, esclarecer e depois registrar via e-mail.
Você está enviando o e-mail somente para as pessoas que precisam ser envolvidas?
Os que receberão uma cópia, realmente precisam dessa informação?
A mensagem contempla apenas um assunto? Facilita a comunicação e a organização lidar apenas com um assunto por vez.
A linha de assunto (Subject) é a mais importante: ela resume o conteúdo do e-mail? Se você precisa de uma resposta, vale a pena colocar no assunto "Favor responder até dia 20/12 às 12h".
Defina, logo no início as principais ações (e os responsáveis por elas);
O conteúdo é objetivo? É preciso respeitar o tempo das pessoas que lerão a mensagem. Seja preciso e claro.
O conteúdo foi revisado? "Ténicas dr redacao e o bom usa da gramtica".
O anexo é realmente necessário? Anexos tornam as mensagens mais pesadas e aumentam o tráfego na rede. Não seria interessante enviar o link para que todos tenham acesso?
Não há nada mais irritante do que ler uma mensagem enorme, que contempla o vai-e-vem de mensagens para os envolvidos e descobrir posteriormente que aquilo não tem importância ou relevância para você. Se for realmente necessário enviar o histórico de outras mensagens junto com o e-mail, destaque os pontos relevantes logo no início; faça um resumo e não obrigue o leitor a ler todo o conteúdo do e-mail para entender do que se trata.

E você conhece outra dica? Alguma história interessante sobre o uso do e-mail?

Bom final de semana!

O bom filho à casa torna

2008-10-18T21:37:00.008-03:00

Já faz algum tempo desde que concluí o MBA em Gestão Empresarial no CEDEPE, em Pernambuco. Essa semana tive a grata satisfação em receber e aceitar o convite para retornar, mas agora para atuar como facilitador para a turma do MBA em Marketing no próprio CEDEPE, agora, CBS (CEDEPE Business School).

Esta é a minha primeira turma, e devo dizer que o pessoal é o máximo: ótimo astral, participativos e interessados, enfim: profissionais de sucesso, tenho certeza! Mesmo estudando o sábado inteiro o pessoal mostrou a que veio na disciplina de Sistemas de Informação em Marketing.

Um facilitador não poderia pedir por uma turma melhor em seu primeiro curso no CBS. Parabéns a todos! Saíram bem na foto! As mocinhas em maior número têm a tarefa de analisar o contexto de marketing para o Hotmail; em menor número, mas não em desvantagem, a equipe que vai revolucionar o marketing do Gmail. Na próxima sexta veremos os resultados! Que vença a melhor equipe!

A estimativa de meu novo projeto foi feito por outro gerente de projetos e é totalmente irreal, mas foi aprovada. O que posso fazer?

2008-09-26T11:04:00.002-03:00

A. Refazer a linha de base. Fazer o projeto com as novas estivamtivas que você acha que estão corretas.

B. Mudar a estimativa e informar que o gerente de projeto anterior era incompetente.

C. Documentar o que você descobriu e apresentar alternativas às partes interessadas.

D. Não fazer nada. Ter uma estimativa é o que conta. Ninguém espera que você realmente trabalhe dentro das estimativas.

Mesmo sabendo o que precisa ser feito no projeto, é realmente necessário criar um Termo de Abertura?

2008-02-26T15:09:00.003-03:00

A. Um termo de abertura sempre deve ser criado, por mais simples que seja.

B. Um termo de abertura é opcional, pois em pequenas organizações o nível de informalidade é elevado não possibilitando a elaboração de muitos documentos.

C. Um termo de abertura é necessário se a equipe do projeto for maior do que 40 pessoas.

D. Um termo de abertura só é necessário se você ainda não sabe o que é um projeto.

Como conduzir um Kickoff Meeting

2008-02-26T12:42:00.005-03:00

O que é:
Encontro entre os integrantes do projeto com o objetivo do motivar a equipe e criar interesse pelo produto do projeto, esclarecendo a todos os objetivos do projeto. Outro aspecto importante é deixar claro o apoio executivo na organização em relação ao projeto.

O kickoff meeting deve ser planejado com cuidado, pois coloca o projeto no rumo certo para seu sucesso. Os participantes entenderão o quê estão fazendo e, mais importante, o por quê estão fazendo o trabalho do projeto. É interessante identificar as origens de um projeto, seu valor para a organização e que necessidades da mesma serão atendidas com o projeto.

O que não é:

Oportunidade para adquirir estimativas de tempo para atividades do projeto e atribuir responsáveis a essas atividades, afinal, todos os membros do projeto estarão participando...

Como conduzir um kickoff meeting?
(adaptado de PMI, Community Post, acesso em 26 de fevereiro de 2008)

Inicie com uma breve apresentação dos executivos envolvidos no projeto. Peça a uma dessas pessoas que descreva o projeto, e mostre como o projeto se enquadra na estratégia de negócios da organização e especifique como seu produto agregará valor à organização.
Peça ao patrocinador do projeto para falar sobre a necessidade de negócio que o motivou a financiar esse projeto e sobre como isso pode ser valioso para a organização e seus clientes. Peça que ele explique o fator mais importante a ser considerado: se o Tempo (velocidade para o mercado), Custo (restrições no orçamento), ou Qualidade (Satisfação dos clientes). É importante que ele reforce porque o projeto é crucial. Em seguida, o patrocinador apresenta o gerente de projetos.
O gerente de porjeots deve apresentar as principais partes interessadas no projeto (stakeholders), que devem incluir clientes internos e/ou externos, colaboradores-chave de outros departamentos da organização, principais contatos dos fornecedores (ou terceiros), membros de entidades regulatórias (se for o caso) e a equipe de gerenciamento do projeto. Cada participante de explicar sua ligação com o projeto e o papel que deverá desempenhar para seu sucesso.
Permita que todos os presentes façam perguntas para esclarecer qualquer informação que não tenha sido compreendida. As melhores pessoas para responder a essas perguntas estão reunidas nesse encontro.
Em seguida, o gerente do projeto fala brevemente (com o auxílio de imagens ou gráficos) sobre o escopo do projeto e seus riscos (ambos identificados apenas em seu nível mais genérico) e sobre as premissas e restrições do projeto. Você apresenta o plano de comunicações para os relatórios semanais primários para a equipe, fornecedores, gerentes sêniores e patrocinadores e os planos de atualização e gerenciamento de mudanças no projeto.
Dê oportunidade para um curta discussão sobre a apresentação do gerente de projetos e agradeça a todos por sua presença e preciosa contribuição para o projeto no final do encontro.

Sou o responsável por um kickoff meeting. O que é mais útil incluir neste encontro para que o projeto seja bem sucedido?

2008-02-26T11:59:00.003-03:00

A. O kickoff meeting não é tão importante assim; é melhor dedicar tempo para o trabalho no projeto o mais rápido possível, deixado o kickoff meeting de lado.

B. Solicitar aos membros da equipe que tragam suas estimativas para as atividades e programação de férias.

C. Garantir a qualidade do cofee-break e divulgar isso, para que as pessoas se sintam motivadas a comparecer.

D. Não trabalhar no cronograma do projeto, mas manter o foco na comunicação e nos objetivos do projeto.

Therac-25

2008-02-13T16:19:00.003-03:00

Os acidentes do Therac-25 são os acidentes mais sérios relacionados a falha em computadores.

Aceleradores lineares são dispositivos que aceleram elétrons a fim de criar feixes de luz que podem destruir tumores com um mínimo impacto do tecido saudável local. Estes dispositivos eram normalmente mecânicos em sua totalidade até o início da década de 70.

O Therac-25, máquina criada pela empresa AECL (Atomic Energy of Canada Limited) para produzir radiação a ser utilizada no tratamento Radioterápico, foi desenvolvida utilizando uma tecnologia diferente da usada nas máquinas anteriores, o que fez que a máquina fosse mais compacta, versátil, e deveria também ser mais fácil de usar.

Os predecessores do Therac-25 foram o Therac-6 (que produzia raio-x apenas) e Therac-20 (que produzia feixes de elétrons e raio-x). A Família Therac-20 era controlada por um PDP-11 (a máquina não é do tipo stand-alone); o projeto possui o controle através de travas mecânicas. Já no Therac-25 as funções de segurança foram colocadas no software.

Apesar desse investimento em Software, o projeto do Therac-25 teve partes inter-relacionadas e reutilizadas do Software das máquinas antigas. Porém os testes realizados aparentemente não tiveram uma grande preocupação com o Software.
A máquina trabalhava com dois tipos de tratamento:

A radioterapia de feixe de Elétrons direto, que aplicava desde doses fracas 5 MeV (milhões de elétrons-volts) até doses elevadas de 25 MeV, durante um curto período de tempo;
Terapia com Raios X, que usava o feixe de 25 MeV passando por uma chapa que o convertia em Raios X.

Os acidentes aconteciam quando o feixe de alta intensidade era ativado sem o target ter sido rotacionado para seu lugar. O software da máquina não detectava que isto havia acontecido e não podia detectar que o paciente estava recebendo uma dose letal de radiação, ou evitar que isso ocorresse. O feixe de alta intensidade atingindo diretamente os pacientes causava a sensação de um forte choque elétrico e a ocorrência de queimadura.

Entre as principais causas dos acidentes investigados pelos pesquisadores, têm-se :

Ausência de procedimentos de análise, projeto e verificação (teste);
Ausência de gerenciamento de projeto e planejamento de manutenção;
Negligência no projeto de interface;
Tratamento falho de comunicação com hardware (race condition);
A documentação começou a ser feita quando os acidentes foram reportados;
Apenas hardware foi testado inicialmente;
Após os acidentes, hardware e software foram testados em separado e sem nenhum planejamento a cada modificação. Apenas a modificação do software foi considerada.
O software do THERAC-25 era similar ao do seu predecessor, o THERAC-20. Esse software tinha erros que podiam se manifestar em certas circunstâncias. Porém, no THERAC-25, o software também foi projetado para assumir maior responsabilidade pela segurança e alguns mecanismos de proteção por hardware, usados no THERAC-20, foram removidos do novo projeto. Como resultado, em determinadas situações em que o THERAC-20 queimaria alguns fusíveis, o THERAC-25 irradiou, fatalmente, alguns pacientes;
O software considerava que os sensores sempre funcionavam corretamente, e não havia como verificar isto;
O sistema de controle não operava sincronizado com a interface usada pelo operador da máquina, e caso o operador mudasse a configuração da máquina muito rapidamente, o sistema não atribuia os valores digitados para os controles (o que levava a aplicação das doses letais). Não suportava intruções concorrentes;
Overflows* podiam fazer o software não executar procedimentos de segurança;
O dispositivo responsável por sincronizar o hardware é removido, mas o software não possui sincronismo e o software falha na tarefa de manter invariantes essenciais: o feixe de elétrons ou o feixe mais forte de radiação e a chapa se interferem na geração de raios X;

As overdoses ocorreram entre 1985 e 1987, a máquina estava em funcionamento desde 1983.

Serão citados alguns acidentes:

No primeiro, a AECL foi notificada e respondeu que nenhum problema poderia ter ocorrido. A paciente, apesar de ter desenvolvido uma vermelhidão e inchaço em volta da área do tratamento, continuou a ser submetida ao tratamento com o Therac-25, a reação foi tida como normal, conseqüente do tratamento, ou de sua doença.

Outro acidente ocorreu quando a máquina se desligou após mostrar a mensagem “H-tilt”, a mensagem de “no dose” e “Treatment pause” ao operador ativá-la. Após isso o operador tentou reativá-la, mais 5 vezes, após o operador da máquina chamou um técnico que não encontrou problemas na máquina.

Com a descrição destes acidentes pode-se observar que houve falha no projeto de Software, que deveria ter sido realizado com mais cuidado, já que foi escolhido utilizar o Software para realizar os controles de segurança. No caso de optar por reuso do sistema anterior, deveriam ser realizados testes mais cuidadosos. Não houve preocupação com a usabilidade do sistema, como podemos observar pelas mensagens de erro passadas do sistema, além das mensagens supracitadas, outras mensagens de erro, como “MALFUNCTION 1 ... 64” eram demonstradas ao usuário, sem que nem ao menos no manual, houvesse maiores explicações sobre elas. Falhas do lado dos operadores e médicos também ocorreram, por desconsiderar as reclamações dos pacientes e continuar com o tratamento. A AECL deveria ter levado em consideração os contatos feitos pelos médicos e hospitais dos pacientes acidentados, realizando novos testes no Therac-25, assim que o primeiro acidente ocorreu.

Em 1987, após o 6º acidente, a FDA declara que o Therac-25 não está de acordo com a lei dos Estados Unidos da América e pede que a AECL avise seus clientes que o aparelho não deve ser utilizado para tratamento de rotina.

Histórico dos Acidentes

Kenneston Regional Oncology Center (1985)

Paciente em tratamento de CA de mama recebe overdose
Máquina estava operando há 6 meses; após uma investigação superficial, técnicos concluíram que não havia risco de overdose.
Paciente desenvolveu uma queimadura profunda na área do tratamento. Tratamento persistiu e o paciente continuou a sentir dores cada vez maiores, perdendo o movimento em um dos braços
No total foram 15 os acidentes reportados em diferentes locais, antes que a máquina fosse
tirada de operação.
Todos os acidentes envolveram morte ou deixaram seqüelas para o resto da vida
Inabilidade dos órgãos de fiscalização em detectar e reconhecer a ocorrência dos acidentes.
Negligência da empresa durante o projeto e análise de segurança do software de controle.
Falta de um planejamento de manutenção: a medida que acidentes eram reportados, correções foram feitas, mas deram origem a outros acidentes.

Conclusões

Dispositivos mecânicos de segurança foram eliminados (procedimento relativamente comum, tendo em vista a redução de custos). Colocar demasiada confiança em software é errado. Produtos não podem ser desenvolvidos de forma que uma simples falha de software possa causar uma catástrofe. Dispositivosmecânicos de segurança adicionais devem ser mantidos.
A análise de segurança do dispositivo não levou em conta o software desenvolvido.
Tendência a acreditar que a causa do acidente havia sido determinada sem uma evidência adequada e sem examinar todos os fatores que contribuíram para o mesmo.
Assumir que corrigir um erro em particular iria prevenir futuros acidentes. Sempre existe
um outro erro...
Acidentes em sistemas complexos devem ser vistos do ponto de vista do processo de
engenharia empregado e não pelo uso de software. Será que algum dia poderemos
desenvolver software com zero erro?

Características de desenvolvimento do software

Ausência de procedimentos de análise, projeto e verificação (teste).
Ausência de gerenciamento de projeto e planejamento de manutenção
Negligência no projeto de interface
Tratamento falho de comunicação com hardware (race condition)
Documentação começou a ser feita quando os acidentes foram reportados
Apenas hardware foi testado inicialmente. Após os acidentes, hardware e software foram testados em separado e sem nenhum planejamento a cada modificação.
Reusabilidade não garante que o novo produto vai funcionar a contento e pode levar a projetos de baixa qualidade e potencialmente perigosos.
Cursos de programação e experiência em programação não garantem a produção de software de qualidade
Apesar de que o uso de boa prática de engenharia de software não se pode prevenir todos os erros, mas é possível eliminar grande parte deles. É portanto um requisito mínimo.

Referências:

LEVESON, Nancy. “An Investigation of the Therac-25 Accidents”, University of Washington e Clark S. Turner, University of California, Irvine, IEEE Computer, Vol. 26, No. 7, July 1993, pp. 18-41

http://sunnyday.mit.edu/therac-25.html

http://en.wikipedia.org/wiki/Therac_25

http://pt.wikipedia.org/wiki/Therac-25

http://www.cs.washington.edu/people/faculty/leveson.html

http://www.cin.ufpe.br/~if668/Aulas/ICC%20-%20sistemas%20e%20complexidade.pdf#search=%22TIMELINE%20DO%20THERAC%20%22

http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html

Aprovado na certificação PMP

2008-01-02T08:08:00.000-03:00

Quando acordei na sexta passada logo cedo, não estava muito certo de que seria bem sucedido. A noite anterior foi de ansiedade, e por mais que eu repetisse para mim mesmo que era melhor descansar, o bom sono demorou horas para dar as caras. Algumas coisas fugiram do planejamento: era pra estudar ainda uns dois meses e enfrentar o desafio lá pro finalzinho de fevereiro, mas não haviam datas disponíveis nas instalações do Prometric Testing Center (ABA) aqui em Recife nesses meses. A última data era hoje.

O problema é que não dava para adiar mais. Desde 2002, quando ouvi que existia um livrinho chamado PMBOK, que reunia as melhores práticas em gerenciamento de projetos, fiquei empolgado com o que li e pensei como seria me tornar um Gerente de Projetos. Pra ser sincero, naquela época, nem sabia direito o que era isso, mas a semente já estava plantada. Foi sendo regada, virou sonho, atingiu a maturidade da obsessão. Eu escolhi o caminho mais longo: queria entender tin-tin por tin-tin tudo que estava escrito ali, não me preocupava com prova ou título. Em 2005 (eu acho) tive a oportunidade de participar (ainda que por apenas algumas sessões) de um grupo de estudos aqui em Recife, onde os colegas me apresentaram livros e técnicas que encurtaram bastante a caminhada. Passei a conhecer pessoas que já tinham passado pela experiência e percebi que era algo trabalhoso, desafiador, mas de forma alguma impossível (aqui lembro e agradeço ao Sérgio Angelim, Paulo Camargo, ao Heron e ao Klinger Menezes). Investi tempo e dinheiro. Termos como Escopo, Estrutura Analítica de Projetos, Qualidade, PMO, Estruturas Organizacionais, Ciclos de Vida, Riscos, Mitigação, Contingência, ADM, PDM, PERT/CPM, só para citar alguns, tornaram-se mais familiares e aos poucos foram incorporados às "hemácias do sangue" como dizem por aí.

Hoje, cinco anos depois da inspiração inicial, e 4 horas de tensão e 200 questões em inglês depois, compartilho com vocês a alegria de ter obtido sucesso nessa empreitada! Quem me conhece um pouco mais sabe o trabalho que deu. Mas valeu. Para quem não sabe direito o que é isso, abaixo segue uma breve explicação sobre a certificação do PMI. Termino 2007 com o coração cheio de alegria por mais essa meta profissional alcançada!

Agradeço a Deus, em primeiro lugar. Também agradeço de coração aos que me incentivaram a estudar e a persistir e àqueles que de uma forma ou outra, ao lerem essa mensagem também se alegram com a vitória de um amigo, filho, irmão e companheiro. Claudinha, sua paciência e seu amor é que me deram força!

Atenciosamente,
Ricardo Peters, (Finalmente!) PMP

__________________________________

O PMI (Project Management Institute) é a organização mais conhecida no mundo na promoção das melhores práticas em Gerenciamento de Projetos. Foi fundada em 1969 e oferece a certificação PMP (Project Management Professional, ou Profissional de Gerenciamento de Projetos) desde 1984. É considerada como desenvolvedora de padrões pelo ANSI (American National Standarts Institute) e tem a distinção de ser a primeira organização a ter seu programa de certificação reconhecido pela International Organization for Standardization (ISO) 9001. Há mais de 150.000 membros espalhados por 150 países.

A certificação PMP é um rigoroso processo que avalia o conhecimento no campo do Gerenciamento de Projetos. O exame testa o conhecimento em abordagens, metodologias e práticas em gerenciamento de projetos. Ela garante a empregadores e clientes que você possui uma sólida base nas práticas e disciplinas de gerenciamento de projetos. O GP, assim como a Engenharia, Tecnologia da Informação e outros, possui seu próprio conjunto de qualificações e habilidades. A certificação comprova suas habilidades, experiência, e conhecimento para dirigir projetos que alcançarão sucesso. Para se certificar é preciso pelo menos 4500 horas de experiência em gerenciamento de projetos, que se traduz em um mínimo de 3 anos, além de excelente conhecimento em inglês.
http://www.pmi.org

Elogio do Aprendizado - Bertolt Brecht

2007-12-12T21:37:00.001-03:00

Elogio do Aprendizado
Bertolt Brecht

Aprenda o mais simples!
Para aqueles cuja hora chegou
Nunca é tarde demais!
Aprenda o ABC; não basta, mas aprenda!
Não desanime! Comece! É preciso saber tudo!
Você tem que assumir o comando!
Aprenda, homem no asilo!
Aprenda, homem na prisão!
Aprenda, mulher na cozinha!
Aprenda, ancião!
Você tem que assumir o comando!
Freqüente a escola, você que não tem casa!
Adquira conhecimento, você que sente frio!
Você que tem fome, agarre o livro: é uma arma.
Você tem que assumir o comando.
Não se envergonhe de perguntar, camarada!
Não se deixe convencer!
Veja com seus próprios olhos!
O que não sabe por conta própria, não sabe.
Verifique a conta É você que vai pagar.
Ponha o dedo sobre cada item
Pergunte: o que é isso?
Você tem que assumir o comando.

Bertold Brecht, "Elogio do Aprendizado",
in: Poemas 1913-1956, São Paulo, Brasiliense, 1986, p.121.

Como construir um Termo de Abertura de Projeto?

2007-11-19T16:46:00.004-03:00

Olá! Montei um blog apenas para assuntos relacionados a gerenciamento de projetos. O artigo que se encontrava nesse link foi revisado e agora está disponível em:
http://partesinteressadas.blogspot.com/2010/04/como-construir-um-termo-de-abertura-de.html

Links sobre Métricas de Software

2007-08-18T16:37:00.000-03:00

http://www.apinfo.com/artigo44.htm - Alvaro Eduardo Gomes apresenta de forma simples e objetiva aspectos importantes sobre as métricas e estimativas de software
http://itmanagement.earthweb.com/entdev/print.php/2214031 - Tim Chou fala sobre os custos ocultos do software.
http://www.softwaremetrics.com/
http://www.totalmetrics.com/

Links sobre Gerenciamento de Projetos

2007-08-16T09:36:00.000-03:00

http://www.clubepmp.com.br/pmbok-3rd/ (indicado por Paulo Gabriel)
Apresenta os processos do Gerenciamento de Projetos, com informações sobre entradas e saídas.