Pesquisar neste blog

31 de dez de 2011

Retrospectiva – Os 15 artigos mais lidos no TI Especialistas em 2011



Seguem os artigos que foram mais acessados, de um site que sigo:
















Arquitetando tecnologias orientadas a serviços

POR: Boris Lublinsky , traduzido por Rafael Sakurai


[Esta tradução foi adaptada pelo InfoQ Brasil]
Em seu novo artigo, Arquitetando tecnologias orientadas a serviços, Philip Wik apresenta três obstáculos principais para a criação de soluções baseadas em tecnologias de arquiteturas de serviços (Service Technology Architectures - STA):
  • Complexidade: Como podemos modelar a complexidade com o nível correto de detalhes e de abstração?
  • Comunicação e Elementos de Design: Quais são as principais componentes do STA?
  • Execução e Organização para o Sucesso: Como aumentar a velocidade e a qualidade na construção de soluções STA?
De acordo com Wik, o item mais importante a ser considerado ao lidar com problemas da vida real é que:
Precisamos aceitar que há questões sem respostas e que será difícil um entendimento verdadeiro de qualquer entidade, pois há limites para as simbologias e o pensamento, e precisamos lidar com grandes incógnitas. Mas mesmo nesse domínio de mistérios, precisamos agir, e fazemos isto com a ajuda dos frameworks. Um framework nos traz um plano técnico que permite vislumbrar, planejar, desenvolver, testar, publicar e firmar arquiteturas.
Na opinião de Wik, os dois frameworks mais importantes para implementar soluções de STA são o Open Group Service Integration Maturity Model (OSIMM) e o The Open Group Architecture Framework (TOGAF).
A importância do OSIMM vem de sua definição de um processo para criar um roteiro de adoção incremental do SOA, que fornece benefícios de negócios claros em cada etapa. O OSIMM também fornece um modelo quantitativo para apoiar a avaliação dos estados atual e futuro da maturidade do SOA. Já o valor do TOGAF vem de fornecer um framework de arquitetura corporativa, que ajuda a responder a questão de como construir sistemas para alcançar os objetivos do negócio.
Continuando, Wik introduz dois elementos de design fundamentais para o STA. De acordo com ele:
Um princípio é um padrão imperativo. [...] Ele vem do senso comum e do conhecimento humano compartilhado. Princípios são também proposições, talvez razoáveis, mas que não podem ser provadas. [...] Se não seguirmos completamente o princípio, o princípio permanece, mas falhamos.
Em relação aos princípios fundamentais que podem guiar as tecnologias de arquitetura de serviços, Wik usa os bem conhecidos princípios de design SOA, que incluem baixo acoplamento entre serviços, padronização de contratos, autonomia, serviços que não mantêm estados, agregação de serviços e outros. Ao usar esses princípios, Wik alerta:
É um erro construir arquiteturas baseadas na aplicação de princípios em vez de nos princípios em si. Isso traz um enfoque em tecnologia, ao invés de nos guiar na direção dos objetivos de negócio.
Quando se trata de padrões de projeto, Wik novamente sugere aproveitar amplamente a adoção dos padrões de projeto SOA.
Finalmente, o autor sugere a adoção de práticas do Desenvolvimento Ágil, destacando a maior responsabilidade e a maior comunicação obtida com as reuniões diárias do Scrum, e a qualidade e velocidade alcançadas com a programação em pares do XP. Ele defende que essas práticas são fundamentais para atingir princípios de mais alto nível, como a transparência, que possibilitam o sucesso do STA.
Wik conclui seu artigo dizendo que:
O desenvolvimento de serviços se resume à simplificação dos sistemas para alcançar objetivos do negócio, e também simplificar os processos em busca desses objetivos. Não desmerecemos o esforço necessário para dominar ferramentas que podem nós ajudar a criar um STA; mas para chegar aonde queremos, pode ser necessário abandonar velhas ferramentas.
Os padrões TOGAF, UML e Agile/XP têm valor inestimável, mas há momentos em que precisamos jogá-los fora para enxergar o mundo dos serviços corretamente.


30 de dez de 2011

Sistemas baseados em Arquitetura Empresarial – Um fator crítico para o alinhamento estratégico


Sistemas baseados em Arquitetura Empresarial – Um fator crítico para o alinhamento estratégico

É de grande importância que ao realizar o desenvolvimento de aplicações, seja levada em consideração a arquitetura empresarial da organização, que posteriormente será vital para a evolução dos processos, qualidade e integração entre os sistemas de informação que os suportam, além de alinhar as necessidades de áreas de negócio, com requisitos a serem percebidos pela área de TI. O planejamento de uma arquitetura de TI deve estar alinhado à estratégia da organização, de forma, que o negócio seja de fato compreendido pela área responsável pelo desenvolvimento da arquitetura de TI e Informação, proporcionando em médio prazo, maior integração e reutilização de dados e funcionalidades, além de maior agilidade no atendimento aos requisitos do negócio, devido ao fato da arquitetura de informações prover uma estrutura escalável, baseada na estratégia organizacional.Em muitas organizações, o desafio está em prover o alinhamento e integração entre seus setores, tornando seus processos, desde os gerenciais aos ligados ao core, mais planos, evitando desta forma, a inconsistência de dados e informações, provendo, uma maior integração entre as áreas de negócio. Ainda há empresas, por exemplo, que possuem informações inconsistentes, devido à segregação de sistemas e bases de dados que ‘não se falam’, atuando sem comunicação alguma. Esta ainda é uma realidade em muitas organizações, há processos de negócio que passam por diversos sistemas de informação, sem integração entre bases de dados, aumentando o nível de incerteza e inconsistência de informações, acarretando o desperdício de recursos e muitas vezes prejuízos, devido ao retrabalho e ineficiência de processos organizacionais.A crescente automatização de processos nas empresas, durante as últimas décadas, tem feito da TI um fator crítico de sucesso para as organizações, tendo em vista que esta área é responsável por manter todas as informações e base de conhecimento empresarial, além de suportar a praticamente todos seus processos, que são executados com o suporte de seus sistemas.
O levantamento da arquitetura empresarial não é uma atividade que deve ser atribuída exclusivamente a TI, mas que necessita primeiramente de apoio da alta direção, e participação de todas as áreas de negócio, no levantamento de arquitetura de processos e dados, tendo em vista, que deverá estar focada nos processos a serem suportados. Inicialmente, o projeto de levantamento demandará de mais tempo e provavelmente recursos, mas é de grande importância, tendo em vista que proporcionará uma maior integração de dados organizacionais e processos, além de prover uma estrutura fundada na evolução da arquitetura de TI, através de níveis maiores de abstração de dados, acompanhando o crescimento e provável expansão da organização e seus sistemas de informação, posteriormente.
Uma arquitetura de informações baseada na arquitetura empresarial proporciona a organização, sistemas de informação com maior simplicidade, orientados ao suporte a processos, e integração de dados e informações, com foco no atendimento aos principais objetivos e processos da cadeia de valor da organização, além da evolução dos processos de negócio, e a própria evolução dos negócios da empresa. Esta é uma atividade que pode demandar bastante tempo, dependendo do porte da organização, e sua arquitetura de sistemas, tendo em vista que possui um foco na integração entre aplicações e bases de dados. É bastante aplicada durante projetos de integração de soluções já existentes, ou mesmo, durante programas de atualização tecnológica, sendo esta segunda, em muitas ocasiões, uma oportunidade não só para migrar plataformas e aplicações, como também prover a integração destas, gerando resultados esperados e integração entre processos organizacionais.
Desta forma, a TI pode entregar valor ao negócio, através da redução do gap existente entre equipes responsáveis pelo desenvolvimento de aplicações, administração de sistemas, e áreas de negócio, que são as principais partes interessadas desta atividade, além de preparar a médio e longo prazo, uma estrutura capaz de suportar a evolução de seus sistemas de informação e melhoria de comunicação entre os setores da organização.

29 de dez de 2011

SCRUM, KANBAN e XP - Indo além de Projetos de TI

Por: Felipe Muller

Três Metodologias Ágeis e como usá-los em Projetos que não sejam de TI


Muitos gerentes de projeto que trabalham no desenvolvimento de software estão bem familiarizados  entregas e iteração constante em um método ágil. Mas agora, ágil está ganhando terreno em outras indústrias.Aqui está três populares metodologias ágeis, e como elas podem trabalhar em projetos que não sejam de desenvolvimento de software.


1. Scrum


Scrum tem encontrado seu caminho para uma variedade de organizações estruturadas por projetos, incluindo escritórios de advocacia e universidades.


Veja como ele funciona, de acordo com a Scrum Alliance:
  • A lista de desejos priorizados chamado product backlog é criado.
  • Durante a fase de planejamento, a equipe seleciona um pequeno pedaço do topo da lista que desejam, chamado backlog de sprint, e decide como implementar essas peças.
  • A equipe fornece um certo período de tempo, chamado de sprint, para completar o seu trabalho e cumpre a cada dia para avaliar seu progresso.
  • No final do sprint, geralmente de duas a quatro semanas, o trabalho deve estar pronto para entregar a um cliente.
  • O sprint termina com uma revisão de sprint e uma retrospectiva.
  • O próximo sprint, então, começa.
Para Scrum passar para outras indústrias, você teria que: "quebrar os requisitos para um discreto conjunto de itens que poderiam ser trabalhados em um conjunto de iterações", diz Bob Tarne, PMP, engagement manager para IBM Software Group em Lenexa , Kansas, EUA.

Ele usou o exemplo de trabalhar com um editor e ilustrador em um projeto de publicação."Nós quebramos o livro em capítulos e começamos a primeira iteração com o capítulo um", diz ele."Nós escrevemos, ilustramos e realizamos a edição  dentro de um [Sprint]. Nós revisamos no final do [Sprint] e, em seguida, planejamos a iteração dois com o segundo capítulo. "

2. Kanban

Com raízes na indústria automobilística, Kanban é adaptável a projetos que não sejam de desenvolvimento de software, especialmente de recursos humanos e legal, porque os seus princípios não estão associadas a qualquer prática específica, afirma Abdiel Ledesma, PMP, proprietário do Grupo Equation no Panamá e presidente da PMI Capítulo Panamá.Esses princípios são:
  • Visualize o fluxo de trabalho.
Isto pode ser feito usando um cartão de parede, com as colunas representando os estados ou etapas do fluxo de trabalho e as cartas que representam os itens de trabalho.



  • Limite o andamento do projeto. 
"Se a sua equipe estava trabalhando em cinco itens de uma vez e não a fez progressos, reduza esse número para dois ou três", diz Sliger diz. "Selecione o mais importante, os itens de trabalho mais valiosos. Trabalhe sempre na próxima coisa mais importante."



  • Gerencie o fluxo.
O fluxo de trabalho através de cada estado ou etapa deve ser ativamente monitorado, medido e relatado, a fim de avaliar os efeitos positivos ou negativos de mudanças incrementais e evolutiva.



  • Tornar explícito as políticas dos processos.
Garantir uma compreensão explícita do mecanismo de um processo para alcançar uma discussão racional e objetiva dos problemas e facilitar o consenso em torno de sugestões de melhoria.


  • Melhore de forma colaborativa.
Kanban para realmente funcionar, as equipes devem colaborar. "Kanban é bom como qualquer outro método ágil, em que a equipe tem que se reunir para planejar, diariamente preferencialmente em pé, e pode optar por fazer retrospectivas para inspecionar e adaptar o seu processo", diz a Sra. Sliger. "Todos esses itens, e mais envolver a colaboração e melhoria contínua."

Para se adaptar a um projeto de recursos humanos, por exemplo, visualizar o processo de contratação através de uma placa de Kanban. Categorias na placa seriam incluir uma coluna para os candidatos que enviaram currículos, uma coluna para os candidatos que estão qualificados para a posição e uma coluna para os candidatos que se mudaram após o processo de entrevista por telefone. Apoio que fluxo de trabalho com um documento que define quem é responsável por esses diferentes papéis e processo de kickoff o com uma pequena reunião com a participação de todas as partes interessadas.3. Extreme Programming (XP)

O nome por si só pode desligar-se muitas equipes de projetos trabalhando em projetos fora desenvolvimento de software e eles podem estar certos. 


2. Kanban


3. Extreme Programming


XP se concentra em desenvolvimento orientado a testes, lançamentos de pequenas "releases",  e uma estrutura de equipe que inclui o cliente, enquanto que as abordagens tradicionais de gerenciamento de projeto, geralmente adotam, diz Mr. Tarne.


Muitas das regras para esta metodologia ágil são projetadas especificamente para tratar de codificação, projetar e testar. Ter planejamento, por exemplo: Um projeto tradicional faz planejamento na frente; XP diz para planejar o lançamento a um nível elevado, mas o plano de cada iteração em seu início (ou a cada duas semanas).


Mas XP oferece algumas lições aprendidas para projetos além de TI.


"O mais poderoso das práticas ágeis é o reconhecimento das pessoas como o ativo mais valioso de projeto e  a liderança como catalisador", disse Ledesma diz. 


"XP tem cinco valores que podem ser enfatizado em muitos tipos de projetos (além desenvolvimento de software) : Simplicidade, comunicação, feedback, respeito e coragem". Esses valores podem, e devem ser aplicados a todos os projetos em todos os setores, o Sr. Tarne diz. "Comunicação é um grande exemplo", diz ele. "Eu vi uma série de projetos que  descarrilou por causa das comunicações pobres".





Marco Gandra: Grupos no Linkedin

Marco Gandra: Grupos no Linkedin: Com prazer, informo que ultrapassamos a marca de 1.000 filiados ao Grupo de Gerentes de Projetos em TI e 3.000 no Grupo Analista de Negóci...

28 de dez de 2011

Workflows em Java com Bonita



Este é o primeiro de uma série de artigos que têm como objetivo apresentar os conceitos e as práticas do uso de Workflows em Java. Inicialmente, abordaremos um pouco sobre os conceitos que envolvem este tema e temos como objetivo levar ao seu entendimento a importância que existe em compreender esta tecnologia. Explicaremos como este entendimento permitirá uma maior agilidade no desenvolvimento e como pode agregar qualidade ao produto final. Em seguida, iniciaremos demonstrando como seu sistema pode ser construído em Java usando a biblioteca aberta denominada Bonita.

O Incrível Mundo dos Workflows

Embora seja considerado um tema de discussão antiga, podem ser encontradas, ainda hoje, diversas correntes divergentes quanto ao que é e quais as atribuições de um Workflow. O objetivo, neste momento, é esclarecer o que são fluxos de trabalho, quais as suas atribuições e como podem ser aplicados, tentando desmistificar este incrível mundo dos Workflows.
Muitos dos conceitos desta área são encontrados em nosso cotidiano. A sequência de tarefas realizadas quando nos levantamos da cama até o momento em que chegamos ao trabalho destaca uma série de atividades executadas todos os dias por muitas pessoas: levantar, escovar os dentes, tomar banho, tomar o café da manhã, dirigir-se ao trabalho, etc.


Deste exemplo, observamos um conjunto de estados que se modificam a partir de ações. Temos, então, o estado "dormindo", que necessita da ação "acordar" para que se passe para o estado "escovando os dentes". Para chegar ao estado "tomando café da manhã", será necessário executar algumas atividades, "como escovar os dentes" e "tomar banho". Embora possa ser considerado um exemplo simplório, é importante para clarear as ideias básicas de um Workflow.

Em uma visão macro, abordando questões de negócio de uma empresa, temos relatórios que estão aguardando validação e que, para chegarem até o chefe do setor, devem ser analisados e, logo após, aprovados. Para aqueles formados na área de engenharia de sistemas, alguns conceitos anteriormente aprendidos podem surgir, como o de Máquinas de Estado. De fato, um fluxo de trabalho contém esta ideia, mas a amplia consideravelmente.


Conforme a evolução das tecnologias que circundam os Workflows foram avançando, diversas características foram agregadas, muitas vezes criando termos novos que possivelmente criaram mais dificuldades para entender este tema. Uma definição encontrada na internet destaca que fluxos de trabalho são "Processos de Negócio que consistem de múltiplas atividades que devem ser executadas em uma sequência válida. Atividades representam qualquer unidade de trabalho, que pode ser, por exemplo, uma simples chamada de telefone".

Entretanto, a definição mais difundida é a da Workflow Management Coalition (WfMC), órgão criado e gerido por um grupo de empresas e outras partes interessadas neste assunto. A WfMC descreve: "Workflows preocupam-se com a automação de procedimentos nos quais documentos, informações ou tarefas são trocados entre participantes, conforme um conjunto definido de regras, com o objetivo de alcançar, ou contribuir, para uma meta global de negócios".


Considerando a definição proposta pela WfMC, podemos esclarecer um fluxo de trabalho através de um rápido exemplo real, como um fluxo de pedidos de compra. Nele percebemos a participação de entes que devem executar tarefas como, por exemplo, o técnico que deve verificar o estoque dos produtos que compõem o pedido e a aprovação financeira, realizada pelo analista financeiro. Outro termo comum nesta área, e que merece um esclarecimento, é o termo Workflow Engine ou, traduzido para nosso idioma, Mecanismo de Fluxo de Trabalho. Uma vez definido um fluxo de trabalho, cabe operacionalizá-lo e um mecanismo de workflow é o responsável por esta ação. Cabe a ele tratar uma entrada, o fluxo de trabalho descrito em uma linguagem, e gerenciar as transições entre os estados e as tarefas que cada participante possui, além da execução destas pelos seus responsáveis.



As linguagens de definição de processos são estruturas formalmente organizadas que permitem aos responsáveis pela idealização de um fluxo descreverem os passos e as tarefas que cada participante terá. Neste contexto, podemos destacar as linguagens eXtensible Process Definition Language e a Business Process Management Notation 2. A primeira é mantida pela WfMC, enquanto a segunda é mantida pelo grupo BPM.org. A linguagem BPMN2 diferencia-se da XPDL não apenas na sintaxe, mas também na forma de apresentação, uma vez que ela também pode ser usada de maneira visual, permitindo a construção de fluxos de trabalho adotando elementos gráficos pré-estabelecidos.



Ambas linguagens não encerram o assunto, pois diversas outras já foram sugeridas, embora muitas não tenham alcançado o êxito pretendido. Atualmente, a linguagem BPMN2 possui maior evidência, sendo adotada como linguagem padrão dos Mecanismos de Workflow mais utilizados do mercado.



Finalizando, é importante diferenciar os conceitos de Workflows e BPM, pois percebe-se, nos analistas de sistemas e negócio, confusão quanto aos limites de cada um. Pretendendo não se estender neste assunto, será adotada a ideia de BPM encontrada no site Cio.com: Worflows são a base para o BPM. Deste ponto de vista, um BPM é um Workflow com alguns "enfeites". Do ponto de vista de um analista de negócios, contudo, estes adornos são tão importantes para as pessoas que desejam que seus processos de negócio sejam rodados de forma eficiente, que cabe criar um termo específico para designar isto.

Ei, seu sistema é um Workflow!

Desenvolver um sistema não é uma tarefa trivial. Contudo, pode ser ainda mais conturbada quando os responsáveis por sua criação não possuem conhecimentos além daqueles referentes à sua área de atuação. Sistemas de Workflow são um exemplo prático disto. A partir das descrições do negócio de uma empresa, é simples observar que determinada aplicação pode ser modelada facilmente como um fluxo de trabalho, mas não é tão fácil para aqueles que nunca estudaram o assunto. Conscientes ou não, os analistas terminam abdicando de adotar práticas ou reusar soluções existentes que poderiam agilizar e embutir maior qualidade ao produto.
Este esforço supérfluo é comum no desenvolvimento de sistemas, principalmente pela falta de cultura em determinadas tecnologias.
Visando exemplificar, pode-se considerar esta simples descrição inicial de um sistema, dada por um cliente fictício: gostaria de um sistema para facilitar a publicação de notícias em meu sítio na Internet. Os repórteres enviam as notícias de suas casas e o redator revisa. Depois, eu devo publicá-las, uma a uma, evitando notícias que ferem interesses de patrocinadores.Para um analista de sistemas com bons conhecimentos em Workflows é bastante fácil identificar um fluxo de trabalho no qual notícias passam por, no mínimo, três passos antes de serem acessíveis ao usuário externo. 


Um fato comum é a construção quase completa de uma engine própria, contendo código específico da aplicação entrelaçado com o gerenciamento do fluxo de trabalho. Adotando os termos comuns na área de desenvolvimento de aplicações, pode-se dizer que o código encontra-se com centenas de comandos if e switch totalmente desnecessários, que visam a apenas controlar em qual direção o fluxo deve prosseguir. Obviamente, uma simples engine eliminaria todo este esforço.

Workflows em Java

Em Java há muitas opções para trabalhar com Workflows. São muitas as bibliotecas disponíveis. Contudo, este artigo destaca as soluções jBPM, da JBoss e o Bonita, da Bonita Open Solutions. Ambas são soluções livres e possuem uma forte comunidade guiando seu desenvolvimento. Cabe destacar aqui uma lista extensa de engines de Workflow disponíveis para Java, que está disponível em http://java-source.net/open-source/workflow-engines.
Cada engine listada neste site possui características diferentes. Cabe ao desenvolvedor que acabou de verificar que o seu sistema é um Workflow, selecionar aquela que melhor atende aos seus requisitos.

Primeiros Passos com Bonita

Chegou a hora, finalmente, de colocarmos a mão na massa e iniciarmos a criação de um fluxo de trabalho. Para isto, adotaremos o mecanismo de workflow da BonitaSoft, denominada simplesmente de Bonita. O Bonita é uma suite bastante abrangente de Workflow. Com ela é possível definir seu processo, ou fluxo de trabalho, através de uma ferramenta gráfica própria e muito simples de usar. Também fornece uma interface gráfica muito bem elaborada, através da qual é possível interagir com instâncias de seu fluxo, seja gerenciando as tarefas disponíveis ou executando-as.


O foco deste artigo são os desenvolvedores de sistemas, portanto, vamos nos ater especificamente à engine que suporta a execução de processos no Bonita. Isto significa que não usaremos a interface gráfica já fornecida na suite, entretanto, usaremos o Bonita Studio para desenhar nosso fluxo de trabalho. Para alcançar nosso objetivo, inicialmente baixe o Bonita através do link http://www.bonitasoft.com/. Uma vez instalado, execute-o e você terá uma tela semelhante à da figura abaixo:

Agora podemos criar nosso processo clicando na opção Create a new process graphically. Vamos criar um fluxo de trabalho para gerenciar a publicação de notícias em um site. Nossas notícias precisarão passar por 3 passos antes de serem acessíveis. Primeiro, deverão ser criadas, depois revisadas e só então publicadas. Contudo, uma notícia ainda pode ser rejeitada caso não seja aprovada após a revisão.
Temos, então, 5 atividades, sendo 3 humanas e 2 automáticas. Para saber se é uma atividade humana, observe o ícone no lado esquerdo superior dos passos. Para definir uma atividade como humana, clique na atividade e selecione a opção "Human" na lista de "Activity type". Uma atividade humana requer uma ação direta de uma pessoa para que haja a transição de um estado para outro. A automática, como o próprio nome sugere, ocorre sem qualquer intervenção humana. Este fluxo pode ser testado apenas clicando no botão RUN, que fica na barra de ferramentas.


Ainda precisamos fazer alguns ajustes ao nosso fluxo. Como pode ser observado na figura, a atividade Revisar e Publicar possuem duas possíveis transições. Então, como a engine vai saber qual seguir? Precisamos definir algumas informações que serão usadas para que a engine tome esta decisão. Para isto, clique na atividade Revisar e na aba de detalhes, clique na opção Data. Agora clique em Add e a janela da figura abaixo irá aparecer. Selecione a opção "List of Options" e preencha conforme indicado.

Repita os mesmos passos para a atividade Publicar. Agora, selecione a transição que parte da atividade Revisar para a atividade Publicar. Preencha o campo Condition com o valor decisao == "Revisada". Repita isto para as transições Revisar -> Rejeitada, Publicar->Arquivar e Publicar -> Rejeitada. Mas lembre-se de colocar o valor correto no campo Decision. Para publicar, por exemplo, o valor deve ser decisao == "Publicada". Vamos testar o nosso fluxo? Clique em RUN e veja como ficou.


Marco Gandra: Analista de Sistemas ou Analista de Negócios

Marco Gandra: Analista de Sistemas ou Analista de Negócios

27 de dez de 2011

Como resolver um conflito?

Por: Carla Poletti


A capacidade de resolver conflitos é uma das habilidades fundamentais para se obter um ambiente de trabalho agradável, em que predominem o respeito e a cooperação.
Baseado na teoria de Marshall B. Rosenberg, criador da Comunicação Não-Violenta, existem alguns passos que podem ser dados para que seja atingido esse objetivo.
1- Buscar Empatia: Capacidade de se colocar no lugar do outro, sendo o outro. Repare bem, não é o que você faria neste lugar, mas sim o que o outro, dentro das possibilidades dele pode fazer.
Exemplo: Um colaborador atrasou meia hora para chegar a uma reunião importante.  Isto te gerou raiva. O que no seu padrão, faria com que você brigasse ou ficasse de cara feia.
Dica: Perceba os seus sentimentos e não reaja imediatamente. Antes de qualquer coisa, procure saber o que aconteceu. Sabendo disto, procure se colocar no lugar dele, que na maioria das vezes, também está desconfortável com a situação.
2- Relatar os fatos sem julgamentos: Olhe para o fato com a maior objetividade que conseguir. Este talvez seja o passo mais difícil, pois normalmente já avaliamos e julgamos o outro através dos nossos filtros de valores, o que alimenta o mal estar.
Neste caso, o fato é que houve um atraso de meia hora. O julgamento que costumamos fazer é de que o outro não está nem aí, é um irresponsável e etc. Normalmente reagimos a estes pensamentos.
Dica: Relate só o que houve.
Exemplo: Na reunião do dia tal, você atrasou meia hora. O que aconteceu com você?
3- Lidar com os sentimentos: Em algumas situações, poder expressar seus sentimentos pode dissolver o conflito, em outras, pode agravar. Às vezes, esperar um pouco para que você possa estar emocionalmente mais distante do fato, pode te ajudar
Dica: Quando já não estiver mais movido pela emoção. Abra espaço para conversar. Com isto, o outro também pode falar o que se passa com ele.
Exemplo: Busque saber, qual a dificuldade que a pessoa teve para cumprir o horário.
4- Perceber a necessidade ou o desejo que não foi atendido: Este é o momento em que você pode aproveitar para se conhecer melhor, saber qual a razão que levou este fato a te incomodar tanto.
Exemplo: Ás vezes, algo gera raiva porque abala a confiança. Ainda mais em um ambiente de trabalho, em que o sucesso de um, muitas vezes, depende do outro.
Dica: É importante aqui, você cuidar para não entrar no lugar de vítima ou de perseguidor, e sim perceber o que pegou em você.
5- Compromisso: Com a consciência do que faltou, busque algo prático que possa ser feito, ou seja, como esta necessidade ou desejo pode ser atendido. Neste caso, como você pode confiar neste colaborador, ou ainda, em que ele é confiável.
Às vezes, pedir para que o outro se comprometa a mudar pode ser um jeito, mas cuidado para que isto não vire outro conflito.
Dica: Perceba se o compromisso do outro é algo que você acredita que ele vá cumprir, ou se você já sabe, que é um compromisso feito só para se livrar do problema.
Exemplo: Se esta é uma pessoa que tem um padrão de atrasar, ela pode se comprometer a chegar no horário, mas vocês dois já sabem que não vai funcionar, e você só vai esperar ela atrasar de novo para brigar mais ainda.
Este é um jogo muito comum, em que a pessoa espera o outro falhar novamente para falar: “Agora Te peguei!” E, neste caso, reforçar a crença de que realmente as pessoas não são confiáveis.
Por isto, seja muito honesto com você, perceba se realmente este compromisso é algo que você acredita que o outro vá cumprir.
Senão, busque uma outra maneira de estabelecer esta confiança de que você necessita!
Lembre-se, toda a mudança exige determinação e prática. Por isto, procure experimentar estes passos com quem confia, perceba qual a sua maior dificuldade e como ela pode ser superada.
Acredito que esta é uma forma saudável de solucionar muitos dos conflitos do dia a dia.
Experimente!
Carla Poletti, psicóloga, foi integrante da equipe de Roberto Shinyashiki no Instituto Gente, é especialista e se desenvolveu nas principais escolas de terapia, tais como Terapia Corporal, Renascimento, Programação Neuro Lingüística e Formação Biográfica, processo desenvolvido pela Antroposofia. Atualmente, Carla atua em sua clínica O-Núcleo Psicologia.