Projeto EAGLE

Apresentação

Quando foi que perdemos o com.passo?

Aonde estão as chaves?

De minha primeira Grande Visão

Revolucionando a Gestão Teconológica

A Metáfora do Elefante

Outras dimensões de uma Equipe Promissora

Em Busca de Equilíbrio e Lucidêz

Cloud Computing

Encarando a nossa realidade

A Informação em Perspectiva

O Projeto EAGLE e os seus Dados

Índice

A Metáfora do Elefante

É bem conhecida a anedota do grupo de monges cegos que, após serem apresentados pela primeira vez a um elefante, passam a descrevê-lo com a maior precisão e honestidade, absolutamente convictos de seus próprios “pareceres”.
— É uma lança. Ou uma flecha. Diz o que lhe toca a ponta de uma de suas presas.
— De modo algum: trata-se claramente de uma cortina, opõe aquele que entrou em contato com uma de suas orelhas.
— Qual o quê: seguramente é uma gangorra, acrescenta o que foi posto sobre as suas costas.
— É claro que se trata de uma corda, interrompe o que lhe segurou a calda.
— Não, é uma árvore, ou um tronco, retruca o que acariciou uma de suas pernas.
— É uma cobra, com certeza! Afirma o que tocou a tromba do animal.
— Eu estou certo de que estive sob uma tenda. Sem dúvida! Conclui aquele que esteve sob a sua barriga.

Interessante observar que todos os membros do grupo, sem exceção, estão imbuídos das melhores intenções e da mais pura boa vontade, convictos de sua “verdade”. Em função de seu conhecimento e experiência, estão absolutamente “certos” de que é a sua descrição a que melhor define o que têm à sua frente.

Acontece que encontramos ambientes e cenários como este mais frequentemente do que gostaríamos, em nossas organizações corporativas. Em algumas salas, equipes de projetos se reúnem para alinhar as atividades de seus membros, e cada um – por mais dedicado, esforçado e competente que seja – percebe e interpreta o todo em concordância e “alinhamento” com as “cores” (“sabores”, ou “odores”) de sua própria especialidade e/ou responsabilidade. Afinal, todos queremos impressionar, temos um excelente background técnico-profissional, vasta e comprovada experiência em nossa área de expertise, um rico leque de opções metodológicas e uma diversificada toolbox de ferramentas operacionais ao nosso alcance.

De fato, o “panorama geral” de uma reunião de projeto – independentemente de sua periodicidade – tende a refletir (pelo menos em parte) o seguinte quadro:

  1. A alta-gerência (budgets);
  2. As gerências regionais/locais (cronogramas);
  3. Os arquitetos e analistas de negócio (diagrama, especificações, casos de uso etc.);
  4. Os DBAs (MERs);
  5. Os líderes de projetos (gráficos Gantt, PERT etc.);
  6. Os testers (logs e evidências de testes);
  7. Os desenvolvedores (lista de tarefas [TODOs]);
  8. Os operadores e administradores (topologias de rede, scripts e arquivos .bat);
  9. E os cliente(s) – internos e/ou externos, usuários-finais, sponsors… – meio que “perdidos”, mal têm coragem ou ousadia de externar a sua confusão (como que a espelhar, materializar e/ou representar o estado [velado] do restante da equipe; na qual, até por falta de opção, parecem “confiar” sem restrições, pelo menos por algum tempo…), como que racionalizando: “Eles parecem-e-devem saber o que estão fazendo. Afinal, são todos ‘experts’, certo? Devem ser…. já que soam tão complicados (em seus jargões) e se mostram tão convictos de seus argumentos… Não?”

E todos, é claro, com suas “mui bem intencionadas” planilhas (quase nunca up-to-date e não-raramente com informações inconsistentes com as de seus pares). Cada qual “falando em seu próprio dialeto”, baseados em suas próprias “perspectivas”, ideias e concepções (enxergando o “sistema” sob a sua própria “ótica”). Parece familiar?

data green

Dado            valor (escalar) + unidade de medida
Informação      dado + contexto

Ótimo! Conseguimos reunir uma equipe de “valor”, competente e comprometida. Quem é que não quer isto? Mas o fato é que isto, por si só, não basta; não garante o sucesso de nenhum projeto, nem a qualidade de nenhum resultado. Para que possam, de fato, “colaborar” (com eficiência e eficácia), é fundamental que as nossas equipes encontrem (definam e formalizem) um vocabulário comum e inequívoco, a fim de que possam realmente lograr a coesão da qual de fato dependem, para o sucesso que tanto enfatizam. [Se é que realmente é este o seu objetivo…]

EVANS (2004, p.34) usa o termo “ubiquitous language” para definir este requerimento sine-qua-non de um trabalho de equipe profissional. Uma linguagem “cultivada na intersecção de jargões”. E complementa:

quote

Of course, developers do use technical terminology that a domain expert wouldn’t understand. Developers have an extensive jargon that they need, to discuss the technical aspects of a system. Almost certainly, the users will also have specialized jargon that goes well beyond the narrow scope of the application and the understanding of the developers. But these are ‘extensions’ to the [ubiquitous] language. These dialects should not contain alternative vocabularies for the same domain that reflect distinct models.

page

Outras Dimensões de uma Equipe Promissora →

Após reunir motivação e talento, é preciso “saber” mantê-los. Para tanto, nosso domínio (ambiente) deve ser bem compreendido, definido e monitorado.

↑ Topo ↑
 
Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: