Qualidade Manaus

Paremos um instante essa nossa vida corrida que dizemos ter. Olhemos ao nosso redor. Com calma… Observe o tanto de variáveis passíveis de um bom elogio e nós, por um motivo ou outro, preferimos guardar pra si esse sentimento tão bom que é o reconhecimento.

O reconhecimento não fere quem recebe, não tira pedaços de quem o pronuncia. O reconhecimento não deixa a pessoa preguiçosa pelo simples fato de ter recebido um elogio. Tira a idéia da cabeça que elogio demais enjoa! Ele engrandece. Faz a pessoa quem recebeu, lutar para sempre ser merecedora de um elogio sincero, de coração.

Não temas, reconheça. Isso fará você aumentar sua interação com as pessoas. Ele neutraliza, desarma, desativa e reduz o efeito do ciúme e da inveja. Experimente reconhecer o bom trabalho de um colega que você diz ser “invejoso”. Veja a reação dele. Mas faça isso de maneira sincera, real.

O reconhecimento faz diferença em todos os campos de sua vida, seja familiar ou profissional. Lembra daquele prato saboroso que sua mamãe sabe fazer? Fale isso pra ela, sempre que possível. Isso melhora a auto-estima dela e a sua. É o poder do reconhecimento.

Mapeie as pessoas, de maneira natural. Seja o frentista, secretária, amigo, motorista, chefe, subordinado, mãe, pai, filhos, entregadores de pizza, lavadores de carro, escritores de blog, autores de livro. Reconheça, de coração. Você receberá em dobro cada palavra dita.

Ainda tenho muito que conhecer sobre o poder do Reconhecimento. O Livro The Power of Aknowledgment (Judith W. Umlas) ajudou bastante! Mandei um e-mail para a autora parabenizando pelo excelente conteúdo. Ela prontamente respondeu agradecendo e enviando os 7 princípios do reconhecimento que eu transcrevo abaixo:

• The world is full of people who deserve to be acknowledged.
• Acknowledgment builds intimacy and creates powerful interactions.
• Recognizing good work leads to high energy, great feelings, high-quality performance and terrific results. Not acknowledging good work causes lethargy, resentment, sorrow and withdrawal.
• Truthful, heartfelt and deserved acknowledgment always makes a difference, sometimes a profound one, in a person’s life and work.
• It is likely that acknowledgment can improve the emotional and physical health of both the giver and the receiver.
• Practice different ways of getting through to the people you want to acknowledge.

Reprinted from The Power of Acknowledgment with the permission of IIL Publishing, New York © 2006

O pode do reconhecimento é enorme, basta você saber usá-lo.

Obrigado a você, querido leitor, por simplesmente ler. Mas se comentar, melhor ainda. O comentário aumentaria a auto-estima, faria querer escrever sempre mais (ou menos), aumentaria a interatividade…

Forte Abraço!

Post Publicado simultaneamente no Blog Renato Borges

Mais sobre o assunto: http://thepowerofacknowledgment.com/

No post De Desenvolvedor para Gerente de Projetos: Quebrando vínculos, tratei do assunto da mudança de papéis no meu desenvolvimento profissional. Agora, coincidência ou não, passo por situação semelhante: de Gerente de Projetos (GP) a Analista de Negócios (AN). Mas nessa situação, nada de quebrar vínculos! Pois as áreas estão muito bem relacionadas.

Recentemente participei de um congresso que tratava sobre o assunto, informando as iniciativas tomadas para entender/conciliar os dois papéis. Uma das apresentações foi ministrada (muito bem!) por Suzandeise Thomé, uma das principais especialistas no assunto.

A título de conhecimento, vamos á definição dos dois papéis:

Gerente de Projetos – pessoa responsável pela realização dos objetivos do projeto

Analista de Negócios – profissional que serve como ligação entre as partes interessadas, no intuito de compreender a estrutura, políticas e operações de uma organização e recomendar soluções que permitam que a organização alcance suas metas.

A principal idéia a ser vendida para o bom funcionamento é a Colaboração efetiva entre os papéis. Como os dois papéis podem colaborar para que a empresa atinja seus objetivos? Através de responsabilidades claras documentadas e mutuamente acordadas, comunicação constante e aberta, envolvimento do patrocinador e parceria baseada em confiança e respeito mútuos.

Mas sabemos que da formulação da idéia a real execução das atividades, muita coisa pode sair errada. Entender bem os canais de comunicação e as fronteiras do domínio do negócio é um grande passo para a colaboração, visto que na comunicação acontece a maioria dos problemas.

Domínio do Negócio - Fonte: IIBA

O PMBOK (Gerente de Projetos) e o BABOK (Analista de Negócios) contêm as melhores práticas das áreas. As sobreposições de responsabilidades existirão e cabe ao AN e GP trabalharem de maneira colaborativa em algumas delas, como por exemplo, no documento de visão ou na análise de stakeholders.

Cada uma das áreas, AN ou GP, tem seus desafios e méritos. Como profissional, gostaria de fazer o máximo possível, mesmo estando em um só dos papéis. A mistura de papéis ainda deve permanecer por algum tempo, mas a sua distinção já deve ser levada em consideração. O objetivo deve ser sempre gerar valor para empresa e seus negócios (AN). Valor esse que será atingido gerenciando bem os projetos (GP).

Eu continuo sendo um Analista de Negócios, que uso conhecimentos em GP, não gerenciando o Escopo do Produto e seus requisitos, mas prezando pelo prazo, custo e qualidade, comunicando-os ao cliente. Entendeu? Acho que não. Mas essa é a situação atual.

Forte Abraço!

Post publicado simultaneamente em Blog Renato Borges.

Fontes de Consulta:

http://www.iil.com/brasil/

http://www.theiiba.org/

Estava eu estudando português (curso de Gramática Aplicada aos Textos, Ulisses Infante – 2001) tentando melhorar meu desempenho em concursos e me deparei com um assunto que não pude deixar de relacionar com gerenciamento de projeto: sintaxe.

“Como o texto é um conjunto articulado de frases, há algo mais do que uma simples seqüência – há um constante jogo de referências mútuas que as tornam coesas. (…) É importante perceber, no entanto, que o sucesso desse trabalho de construção depende também da qualidade individual de cada uma das frases que, organizadas, constroem um texto.”

Os profissionais do texto, tal como os gerentes de projetos, tem procedimentos para controlar a qualidade do trabalho. Para o primeiro a frase deve ser curta e permitir ao leitor assimilar uma idéia ou fato de cada vez. Isso não é muito diferente do GP, no qual as atividades devem seguir essas características.

Construir uma frase ou um projeto é trabalho de pedreiro: cada tijolo apóia o que lhe é posto em cima e nenhum deve atrapalhar a harmonia do conjunto. “Quando se trabalha direito, faz-se um muro; quando não há noção de equilíbrio e continuidade, fica-se com uma pilha de tijolos”.

Por conseguinte, o desenvolvimento de um projeto tem muitas similaridades com o desenvolvimento de texto. Devem ter uma ligação do início ao fim, um sentido, várias concordâncias e regências; Onde colocar uma vírgula, um ponto final? Precisa de complemento verbal? Falando nisso… “Deixa-me” voltar a estudar. 

Forte abraço!

Post Publicado simultaneamente em Blog Renato Borges

O ITIL™ (Information Technology Infrastructure Library) é o modelo de referência para gerenciamento de processos de TI mais aceito mundialmente. As boas práticas foram criadas pela secretaria de comércio (Office of Government Commerce, OGC) do governo Inglês, a partir de pesquisas realizadas por Consultores, Especialistas e Doutores, para desenvolver as melhores práticas para a gestão da área de TI nas empresas privadas e públicas.

Seu aceite foi tão grande pelo mercado que em 2005 tornou-se uma família de normas internacionais ISO/IEC 20.000. O foco deste modelo é descrever os processos necessários para gerenciar a infraestrutura de TI eficientemente e eficazmente de modo a garantir os níveis de serviço acordados com os clientes internos e externos.

ITIL V3

Hoje ITIL está publicada em um conjunto de 5 livros que descrevem os processos do ciclo de vida de um serviço de TI. Além dessas publicações principais, existem diversas outras publicações que colaboram com o entendimento de áreas específicas.

Em muitas empresas a área de TI ainda é vista como “os meninos da informática” que servem para “arrumar os computadores quando dá problema”. Esta visão está mudando, pois a cada dia que passa os executivos das empresas percebem que está quase impossível a empresa existir sem a TI (Tecnologia da Informação), pois além de estações de trabalhos para os colaboradores, a TI também fornece infraestrutura para os sistemas de gestão da empresa, de relacionamento com os clientes, de vendas, financeiros etc.

Um dos grandes desafios é fazer com que a área de TI da empresa seja guiada pelas estratégias da empresa. Para suprir essa necessidade e indo além, buscar o alinhamento dos serviços de TI com os objetivos da empresa, é que ITIL serve como referência principal.

Nos livros que compõe ITIL pode-se encontrar um conjunto de processos desde a estratégia do serviço até a operação deste, passando por desenho com segurança, disponibilidade e capacidade. Cada um dos processos que compõe ITIL são encontrados:

• Objetivos;
• Entradas e Saídas;
• Indicadores de Desempenho;
• Papéis e responsabilidades;
• Fatores críticos de sucesso entre outros.

Apesar de parecer utópico, ITIL traz na prática muitos benefícios, não só para a equipe de TI, mas também para a empresa como um todo.

“Uma pesquisa feita com 370 CIOs de 14 países aponta que 66% das empresas adota a metodologia ITIL para gerenciar a área de TI.

O estudo foi realizado pela empresa sul-africana de serviços de TI Dimension Data, que avaliou quais são as melhores metodologias de gerenciamento de ativos de TI adotada pelas corporações.

Ciclo de Vida ITIL

Além do ITIL (Infrastructure Technology Information Library), uma biblioteca de procedimentos criada no final dos anos 80 por uma fundação vinculada ao ministério britânico do comércio, o estudo da Dimension Data avaliou outras metodologias, como Microsoft Operations Framework (MOF, adotada por 47% das empresas) e Six Sigma (41%).

Entre 28% e 34% surgem as metodologias Prince 2, ISO, CMMi, ASL, Cobit e TQM. Abaixo dos 20% estão as metodologias Super e Agile. O ITIL obteve também a melhor nota entre todas as metodologias, 3 em uma escala de 1 a 5.

Segundo os entrevistados, o ITIL ganha das outras metodologias porque um grupo de empresas e consultores independentes faz a atualização periódica e sistemática dos processos envolvidos na gestão de TI, que são documentados como uma biblioteca, com termos previamente definidos e padronizados.”

Mas ITIL num é só pra grande empresa não. Em empresas pequenas com um corpo técnico de TI mais enxuto, a tarefa de implantar ITIL acaba por ser mais rápida e com possibilidade de reunir as pessoas chaves de forma mais ágil. E como o grupo é reduzido os controles e resultados são acabam sendo mais fácil de alcançar.

“Se não se pode medir, não se pode controlar, se não se pode controlar não se pode gerenciar, sem gerenciamento não há melhoramento”.

Que tal começarmos a medir, controlar, gerenciar e melhorar os serviços de TI? E por onde começar? Já temos uma boa alternativa, ITIL.

Sobre o Autor:
HELENO dos Santos FERREIRA
ITILv3 Expert
ITILv2 Manager
hiprojetos@hiprojetos.com.br
http://www.hiprojetos.com.br

Calma, não vai pensando que encontrou a fórmula mágica! Até porque ela não existe ou se existe está muito bem guardada. O objetivo do post é apresentar um exemplo de passos até o aceite de um programa.  Os conhecimentos foram desenvolvidos através de conversas com a equipe em meu local de trabalho e consulta a literatura de GP.

“Um programa é definido como um grupo de projetos relacionados gerenciados de modo coordenado para a obtenção de benefícios e controle que não estariam disponíveis se eles fossem gerenciados individualmente”
PMBOK, 4º Ed.

A principal dificuldade é conseguir “vender” uma visão comum para todas as partes do programa, ou seja, para os patrocinadores dos projetos. Até porque o programa vem para juntar o que há muito vinha separado, podendo compartilhar recursos e alinhamento com os objetivos estratégicos.

Projeto - Programa

Por onde começar? De baixo para cima ou de cima para baixo? (tempo para pensar).
Ok, começamos pelo meio. Vamos aos passos.

1) Conversa informal

Quando o cliente não vai até você, consiga uma oportunidade de conversa informal com ele, colete algumas informação e venda a sua idéia do programa. Siga em frente somente se tiver sucesso nesse passo. Ou seja, o cliente mostrou interesse e abriu as portas para você.

2) Definir objetivo

- Buscar as intersecções entre as diversas partes. O que cada um está fazendo que o outro pode utilizar? Para isso, exige uma série de entrevistas com as pessoas chaves de cada área, o que é muito difícil, pois determinadas pessoas são avessas a mudanças e não compartilham informações. Pra que mudar? Encontramos a primeira barreira!

Nós, como Analista de negócios ou Gerente de Projetos, temos que nos virar para coletar as informações e juntamente com o patrocinador começar a plantar a semente do programa: o seu objetivo.

3) Identificar os níveis

- Verifique os envolvidos em todos os níveis. Às vezes é melhor começarmos com a área técnica, pois eles já conhecem em parte o dia a dia de seus usuários, de acordo com cada tipo de empresa. Caso seja no Governo, o número de níveis pode ser bem maior.

4) Procurar aliados

- Diante da complexidade de níveis, quanto maior o número de aliados, melhor. Sem preconceito, mas preferindo as pessoas que tem influência no negócio.

5) Identificar ponto focal, representante do cliente.

- Onde todo mundo decide, não se chega a lugar nenhum. Essa pessoa deve convocar representante das áreas, participar das reuniões, organizar informações dos diversos setores e projetos, decidir e passar para o nível decisório acima. Nesse momento, não colete muitas informações, isso poderá ser feito após o aceite do programa.

6) Amadureçer as idéias

- Finalizado a coleta macro. É isso mesmo? Podemos seguir em frente? Os projetos listaram todas suas dificuldades? Os projetos conhecem como devem interagir e sabem dos benefícios de agir integrado? Nesse momento, os envolvidos devem estar alinhados, com um horizonte comum, falando a mesma língua.

7) Mapa mental de cada parte do programa

- Um mapa mental pode ser utilizado para apoiar a apresentação e entendimento das idéias, diante do objetivo central. Crie ramos para os projetos, indicando seu papel dentro do programa.

Entender o estado atual

- Sem perder muito tempo, relembre o cliente suas atividades fins, como elas estão sendo realizadas e algumas dificuldades de trabalhar isoladamente dos outros setores. A representação com uma Cadeia de Valor, através de uma figura, pode ajudar.

9) Definir onde chegar

- Diante do estado atual, proponha uma infraestrutura de funcionamento do modelo de negócio, indicando os benefícios do mesmo. Esboce um modelo de integração no qual todos devem estar alinhados. Uma figura com o cenário proposto pode ajudar.

10) Metodologia de trabalho

- O cliente precisa saber que o sucesso do Programa não tem uma fórmula mágica, mas um método de trabalho para atingir o objetivo traçado. Para o sucesso, a metodologia precisa ser seguida. E isso vale para as mudanças que podem aparecer.

11)  Desenvolver EAP (Estrutura Analítica de Projeto)

- Mostre os pacotes de trabalho, distribuidos entre as fases do programa. O cliente entenderá que muito trabalho deverá ser realizado (ou não), justificando assim um investimento no programa. O cliente deve perceber que você tem a organização necessária para a execução do programa, passso a passo.

12)  Apresentar… Armas!

- Diga a sua produtividade. Diga o que você oferece. Se possível, mostre casos de sucesso. Transmita confiança. Nesse momento o cliente deve entender que você é a solução para os problemas.

13)  Assinatura

- Apresente novamente, com o mesmo entusiasmo e com todos os aliados, para a pessoa que assina o programa. O patrocinador principal, aquele que investe o dinheiro. Torça por sua assinatura, oficializando o aceite.

Com o aceite da proposta, organize os documentos e padronize o acompanhamento dos projetos. Mantenha o patrocinador informado sobre a situação de todos os projetos do programa. O sucesso do programa vai depender do sucesso dos projetos que o compõe.

Bastante atenção para o gerenciamento de mudanças. Crie uma definição de quem poderá solicitar/aprovar as mudanças, deixando claro o impacto da mesma para o projeto e conseqüentemente para o programa.

Post publicado simultaneamente no blog Renato Borges.

A Estrada

Prezado leitor, imagine-se na seguinte situação: viajar na estrada e você é o piloto. Imaginou? Começou o seu projeto: Quantos quilômetros a percorrer? A estrada está em boas condições? Como será o fluxo? Condições do tempo? Condições do carro? E, a sua principal escolha: viajar de dia ou à noite?

Durante o dia: você pode conhecer a estrada, obstáculos e curvas. Onde acelerar mais. Os pontos de ultrapassagem. Quais as curvas perigosas. Você dirige prestando atenção em todos os detalhes dentro e fora da estrada.

À noite: o farol é seu melhor amigo. Sua visão não vai muito longe. Seu principal guia são as faixas na estrada. Os carros no sentido oposto são facilmente identificados pelos faróis. Não existe paisagem, apenas a estrada.

No início de cada projeto, o GP pode fazer esse questionamento: de dia ou à noite? Para os primeiros projetos a melhor escolha seria o dia. A visão é ampla. Pois você deve conhecer a equipe, o ambiente organizacional, o caminho a percorrer e que obstáculo o espera. Inevitavelmente o projeto irá demorar mais. Afinal, você está adquirindo confiança.

Para os próximos, tenha preferência pela noite. Você já conhece a paisagem, não precisa revê-la constantemente. Apesar da visão reduzida, as ferramentas estão ali e você sabe de sua capacidade, do conhecimento e motivação da equipe, onde acelerar e onde frear. É você e sua equipe buscando o objetivo, de maneira mais rápida e ágil.

Mas não se acostume a dirigir somente à noite, pois às vezes aparece um buraco que você não conhece e acaba ocasionando um acidente. Por isso, de tempos em tempos, refaça o seu caminho durante o dia. Mapeie sempre os obstáculos. Verifique o que mudou.

Gerenciar Projetos é isso: conhecer a estrada, conhecer seu carro e administrar da melhor maneira esses recursos para que você consiga chegar à próxima cidade. Seja de dia ou à noite.

Post publicado simultaneamente em Blog Renato Borges.

“… a stakeholder in an organisation is any group or individual who can affect or is affected by the achievement of the organisation’s objectives…” Freeman (1984, p. 46) – Project Management Journal – Vol 41

O GP passa grande parte do seu tempo medindo o desempenho do projeto e se comunicando com os stakeholders. No plano de gerenciamento das comunicações do projeto, tem a atividade identificar as partes interessadas, que, se você não fizer bem, pode acarretar complicações no futuro do seu projeto.

Basta identificá-los? Claro que não. Você deve conhecer as características de cada parte, traçando o perfil. As perguntas mais simples são: Tem poder de decisão? Tem interesse no projeto? Com essas duas respostas o GP já consegue identificar como deve tratar cada Stakeholder. Fiz uma breve planilha com um gráfico para exemplificar. O gráfico visa identificar qual o perfil que prevalece entre os stakeholders, permitindo presumir se um projeto écomplexo (muitas ações!) ou não no que diz respeito a comunicação.

Gerenciamento de Stakeholder

Eu adiciono a essas informações o perfil “pessoal” de cada um, que consiste em descrever o stakeholder: “-Quais são suas preferências: gráfico ou relatórios; É exigente; Prefere reuniões mensais; É formal; Aceita brincadeiras; etc”. Registrando-as para consulta futura. Apesar de parecerem simples, essas informações são importantes para o GP, principalmente antes de uma reunião. Pois o GP vai preparado, conhecendo um pouco do perfil do stakeholder, adaptando-se assim a sua necessidade.

Outro fator que facilita o trabalho é manter o registro das ações realizadas. “Quais informações foram passadas? O que ficou decido? O Cliente reclamou de algo recentemente? Alguma pendência?”. Pois repetição de informações deve ser evitado, a não ser para tirar dúvidas ou frisar uma informação. Para isso, não precisa ser um sistema complexo de controle. Uma planilha excel atende. Confira o exemplo.

Ações Stakeholder

Por conseguinte, não entre para a estatística dos projetos que falham por conta da comunicação. Com simples atitudes você consegue gerenciar seus Stakeholder, bem como suas expectativas, finalizando seu projeto com sucesso.

Download da Planilha

Post publicado simultaneamente em Blog Renato Borges.

Não é minha intenção fazer uma série de postagens sobre erros em sites. Até por que o http://sembugs.blogspot.com faz muito bem esse papel.

Mas a circunstância pediu. Me vi no papel de cliente, chateado, fora do horário habitual (comercial) de funcionamento dos Call Centers, querendo entrar em contato com a empresa para relatar o fato e fazer passar um pouco a raiva, acessei o site da Chevrolet e fui direto para o tão conhecido e mais acessado “Fale Conosco”.

Na pior das hipóteses, todas as páginas poderiam apresentar algum tipo de erro ou falha (verifique a diferença entre os dois). Mas a “Fale Conosco” não! É a porta de entrada para a empresa! E não pode apresentar erro. Por conseguinte, deve ser uma das mais testadas! Não perceberam isso, e acabei recebendo a tela abaixo, como resposta dos meus 15 minutos digitando a reclamação.

11/09/10 - 20h - Tela retorno de solicitação - Erro

Grande parte dos sistemas Web são formados por formulários. Resumidamente, o que devemos testar em um formulário?

1)      Campos obrigatórios
2)      Campos vazios
3)      Tamanho dos campos
4)      Caracteres especiais ( ‘, $,%,*,””, etc..)
5)      Sem falar dos campos mascarados como Dinheiro, Data, CPF…

Mas, conforme tela horrível acima, o trabalho não para por aí. Uma mensagem legível e clara deve ser exibida para o usuário na existência da falha, informando o que está errado e porque está errado. Não simplesmente exibir “você esqueceu de digitar algum campo” ou “você excedeu o limite de caracteres em algum dos campos”ou “limite de tempo excedido” ou simplesmente uma mensagem do servidor. Qual campo foi esquecido? Ultrapassei em quantos caracteres? Qual o meu limite de tempo?

Em um sistema que se preze, o usuário deve fazer o mínimo de perguntas possível para entender o contexto da situação. É claro que, diante dessa premissa, não é só o testador que está envolvido, mas também o responsável pela usabilidade, pelo processo, pela análise e layout do sistema, por exemplo.

Bem, tentei usar o site da Chevrolet para facilitar minha vida, mas acabei ficando mais decepcionado. Se não é para funcionar, melhor nem colocar no ar! Terei que usar o agradável Call Center, que possivelmente será mais uma novela.