sexta-feira, 19 de dezembro de 2008

O e-mail de mil e uma utilidades

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!

sábado, 18 de outubro de 2008

O bom filho à casa torna



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!

sexta-feira, 26 de setembro de 2008

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

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.

terça-feira, 26 de fevereiro de 2008

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

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

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)
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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?

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.

quarta-feira, 13 de fevereiro de 2008

Therac-25

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

quarta-feira, 2 de janeiro de 2008

Aprovado na certificação PMP

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