Segundo o CIO da rede norte-americana de trens Amtrak, Dee Waddell, para estipular objetivos para o departamento de tecnologia é preciso contar com lideranças que mesclem habilidades estratégicas e experiência prática

CIO/EUA
Publicada em 11 de setembro de 2009 às 12h06

“Dê-me um ajudante de serviços gerais com um objetivo de vida e eu o devolverei como um homem que fez história ou, então, me passe um executivo sem um objetivo e eu o devolverei como um ajudante de serviços gerais.” Essa frase é atribuída a James Cash Penney que, em 1902, fundou a rede de varejo J.C.Penney Stores e tornou-se um dos maiores milionários dos Estados Unidos naquele século.

Por décadas, as palavras desse empreendedor foram repetidas nas universidades de todo o mundo com o intuito de mostrar aos alunos as virtudes de se estabelecer metas audaciosas na vida.

Gerações inteiras cresceram apoiadas na teoria de que quanto mais ambiciosos, melhores eram os objetivos de uma pessoa e as chances de alcançá-los. No entanto, de acordo com o professor de gestão da informação da Universidade da Pensilvânia (nos Estados Unidos), Maurice Schweitzer, muitos dos modernos fracassos corporativos foram ocasionados, justamente, pelo estabelecimento de metas rígidas por líderes que não tiveram a agilidade de reformulá-las no meio do caminho.

Um exemplo dessa situação aconteceu na General Motors (GM) quando um diretor estabeleceu que a equipe de vendas deveria dobrar o número de unidades comercializadas em seis meses. “Para chegar ao objetivo, os vendedores passaram a negociar carros com compradores sem crédito comprovado”, diz Schweitzer, que complementa: “Com isso, uma gestão irresponsável sacrificou a lucratividade em nome de um objetivo inalcançável de formas éticas.”

Estabelecer metas não é ruim, mas torna-se necessário, também, desenvolver mecanismos para acompanhar a performance da equipe durante o período estipulado, bem como os movimentos do mercado no qual a companhia está inserida.

No que diz respeito ao monitoramento do desempenho dos colaboradores, os CIOs devem estar cientes de que é necessário estabelecer indicadores que realmente comuniquem a evolução das tarefas – e não apenas calculem os números de horas trabalhadas em determinado projeto.

O gestor de TI da rede norte-americana de trens Amtrak, Dee Waddell, defende que estabelecer objetivos no departamento de tecnologia depende de um líder que mescle habilidades estratégicas e experiência na execução. Para ele, sem a união de tais conhecimentos, a TI continuará concordando em realizar projetos com prazos muito apertados. “Quando se tem a noção exata de como as coisas são desenvolvidas, as metas tornam-se mais realistas e factíveis”, diz ele.

Além disso, Waddell afirma que outro mecanismo eficiente para o estabelecimento de objetivos é a consulta aos membros da equipe. “Pergunto a eles quais seriam as atividades possíveis para determinados intervalos de tempo”, afirma o gestor da Amtrak, que complementa: “Quando envolvidos na estratégia, os funcionários sentem-se motivados e produzem melhores resultados.”

Stephanie Overby, da CIO/EUA

Fonte: CIO

O Centro de Tecnologia de Informação Aplicada da Escola de Administração de Empresas de São Paulo da Fundação Getulio Vargas – FGV-EAESP, o GVcia, divulga anualmente um amplo retrato do mercado de Tecnologia de Informação (TI), com resultados de pesquisas do uso nas empresas e do comércio eletrônico no Brasil.

O levantamento atual é uma ampliação da amostra do estudo para sua 20ª edição. A pesquisa foi realizada em 5.000 empresas com 2.000 respostas válidas de grandes e médias empresas.

Segundo o estudo, nos servidores corporativos o Linux representa hoje 19% do uso no ambiente operacional.

O sumário dos resultados da pesquisa pode ser encontrado em: http://www.eaesp.fgvsp.br/subportais/interna/relacionad/gvciapesq2009.pdf

Postado por Carlos Henrique Vilela
para o blog CHMKT em 30/06/2009

Enquanto o futuro da conferência anual de planejamento vai sendo definido, decidi resgatar algo muito interessante que foi dito na edição de San Diego, em 2007.

Na ocasião, o Gareth Kay, da Modernista! e o Mark Lewis, da DDB San Francisco, apresentaram um material fantástico, chamado Os 7 pecados mortais, no qual falaram sobre os erros que cometemos todos os dias e que acabam nos impedindo de criar novas possibilidades. Abaixo, seguem os 7 pontos listados e um breve comentário sobre cada um. Concordando ou não com as colocações, é uma leitura que vale a pena.

1) Viver com base em suposições antigas e incontestadas. Na busca por um discurso consistente para marcas, ficamos presos em fórmulas, guidelines, brand books e isso acaba nos limitando. Deixamos de explorar novos discursos. Não levamos em conta que, assim como pessoas, as marcas também podem mudar radicalmente se a cultura popular inspirar essa nova atitude. Portanto, desafie as (velhas) suposições.

2) Nos importamos com os assuntos errados. Nossa busca eterna pelo insight perfeito – capaz de gerar conhecimento, atitude e imagem – é desnecessária. Nosso objetivo deve ser criar energia para que as marcas contagiem as pessoas – mais ou menos da maneira que uma banda de rock faz todo mundo sair do chão.

3) Nosso desejo por simplicidade. Segundo Kay e Lewis, é um pecado a idéia é que, com a evolução do papel do planejador, fomos reduzindo tudo a um só problema, um só consumidor, um só conceito para uma marca, uma só forma simples de escrever um brief, uma coisa só para contar para a criação, só mundo a explorar. Isso nos faz muito simplistas e rasos. Eles fizeram, inclusive, uma analogia com a estrutura molecular. Quando você faz um experimento desses, vai surgindo um sistema cada vez mais complexo, maior e muito mais interessante. Ou seja, a complexidade no trabalho de planejamento (e não na forma como apresentamos) pode criar muito mais possibilidades.

4) Qual a mensagem principal? Passamos o tempo todo tentando escrever a mensagem principal no brief – de forma criativa, clara, límpida, para a criação nos achar inteligentes quando o que mais importa é o território que queremos explorar, o porquê de explorar este território e o problema que originou o caminho que estamos definindo. A teoria do caos, afirmaram, é a inspiração para criar um processo mais criativo.

5) Auto-importância. O que fazemos pouco importa para as pessoas. Ninguém fica louco para ver um comercial ou cai de amores pela sua marca. Há coisa muito mais importantes nas suas vidas. Portanto, para ter alguma chance, desenvolva uma missão social, mais do que uma simples proposta comercial. Seja humilde.

6) Achar que as coisas grandes é que importam. Ficamos o tempo todo buscando inspiração em grandes coisas: macro tendências, exemplos de grandes marcas, grandes mudanças de categoria e consumo, entre outras. Isso nos faz esquecer que, no final, estamos falando com pessoas, que tem suas vidas, que fazem pequenas coisas que realmente são muito mais importantes – buscar o filho na escola, almoçar com a família, comer pipoca e dar risada de uma boa comédia, etc.

7) Aprender e depois fazer. Eles dizem que devemos aprender e construir as idéias enquanto estamos fazendo as coisas, enquanto estamos junto com a criação avaliando a execução. Podemos ter uma idéia durante o processo de produção de um filme, por exemplo, e não necessariamente antes de todo mundo. O processo criativo sempre é orgânico e deve ser feito sem processos formatados.

Fonte: Blog CHMKT

Daniela Moreira, de INFO Online
15 de junho de 2009

Jogo da Intel simula os desafios do dia-a-dia de um gestor de TI em terceira dimensão

Como é estar na pele de um gerente de TI, tendo que lidar com orçamentos, investir em inovação, combater ataques virtuais, contratar e demitir e garantir treinamento e suporte adequados aos funcionários de uma companhia?

Agora você já pode viver essa experiência no simulador em terceira dimensão IT Manager Game 3.0, desenvolvido pela Intel.

O jogador tem como meta tornar a empresa virtual lucrativa e bem sucedida, decidindo quais são as tecnologias que cada funcionário deve utilizar e como elas vão ajudá-los a desempenhar melhor suas funções.

Desafios como ataques de vírus e incidentes que exigem a gestão de equipes podem aparecer no meio do caminho e o grau de dificuldade vai aumentando conforme o jogo evolui e empresa cresce.

O jogo já está disponível em 14 países e 12 idiomas diferentes, incluindo português. Desde a estreia da versão beta, em novembro de 2008, o simulador já atingiu aproximadamente 1 bilhão de pageviews.

Segundo a Intel, são mais de 20 mil jogadores registrados, na maioria profissionais e estudantes de TI, que jogam em média 38 minutos cada um. Estados Unidos, Inglaterra, Turquia e Rússia são os países com o maior número de jogadores.

É possível acompanhar, em tempo real, o ranking dos líderes do jogo e a lista das empresas virtuais mais lucrativas.

O IT Manager Game 3.0 é gratuito e para jogar basta cadastrar-se neste endereço: http://www.nextgenerationcenter.com/email/2404-itmangIII/port/itmgr3.html

Fonte: Info Professional

Para Ione Coco, ao contrário do que acontece na maior parte dos casos, as áreas de negócio – e não o CIO – precisam decidir quais projetos de tecnologia da informação devem ser implementados primeiro na organização

Tatiana Americano, da CIO Brasil
Publicada em 08 de junho de 2009 às 17h09

A priorização dos projetos de TI sempre foi uma questão polêmica para as organizações e, de forma geral, representa um ponto de conflito entre os responsáveis pela tecnologia da informação e as áreas de negócio. No entanto, Ione Coco, vice-presidente do Gartner para América Latina, considera que a origem do problema está na falta de entendimento sobre as responsabilidades por esse tipo de decisão.

“Existe uma distorção nas empresas, uma vez que a área de TI assume um papel de definir quais os projetos são prioritários para a companhia”, afirma Ione, que explica: “Mas essa responsabilidade não pode ser do CIO e, sim, do negócio, que deve analisar quais as iniciativas são estratégicas e devem ser implementadas primeiro.”

Ainda de acordo com Ione, o papel da área de TI deve ser o de prover as informações necessárias para a construção do escopo do projeto. “Só que quem precisa defender o investimento como prioritário para a companhia é o dono da iniciativa”, complementa a vice-presidente.

Uma das formas apontadas pela especialista para solucionar esse problema é a criação de uma área voltada exclusivamente a gerenciar os projetos da organização – não só da área de TI – e que esteja ligada ao presidente ou ao CEO da companhia.

Fonte: CIO

por Fábio Akita para o Blog Akita on Rails
em Junho 05, 2009

Obs: alguns dias trás eu escrevi um desabafo sobre o comportamento ruim de um gerente de projetos. Nesta tradução, vamos ver soluções e os cenários corretos. Vamos à tradução:

Em 2004, a revista ‘Software Development Magazine’ entrevistou Gerald Weinberg. Aqui vão algumas de suas respostas (a entrevista completa está no site dele):

Qual foi o melhor conselho relacionado a gerenciamento que você já deu?

Se você culpa seus funcionários, você é um péssimo gerente. Você os contratou, os aceitou, os supervisionou, e dirigiu seu treinamento. Você é responsável. Se você não gosta do que está acontecendo, veja seu próprio comportamento. Mas, se há crédito a ser dado, é deles.

E sobre gerentes que foram contratados em um grupo onde alguns ou todos os funcionários já foram contratados por outra pessoa?

Você não assume um trabalho de gerência de forma passiva. Antes de aceitar a posição, você entrevista todos em seu grupo, e você consegue o apoio deles, ou se livra deles – ou não aceita a posição. Eu não sei porque gerentes não entendem isso. Eles assumem novas responsabilidades como colegiais em seu primeiro encontro às cegas.

E se um funcionário começa a demonstrar mal comportamento depois que ele ou ela o contratou – comportamento que não era aparente na fase de entrevista?

Bem, isso acontece, e é para isso que gerentes são pagos. Pode ser um retrocesso, mas é seu trabalho cuidar disso e terminar o serviço. Infelizmente, poucos gerentes técnicos tem qualquer preparação para isso, é uma coisa que venho tentando remediar por anos – então, por um lado, eu sou culpado, porque fui bem sucedido apenas em alguns casos. Ei, se tudo desse certo o tempo todo, você não precisaria de gerentes.

O que é atribuir a Culpa?

Obs: Leia o artigo completo Beyond Blaming no site oficial do Jerry.

Em uma organização congruente, seu gerente pergunta, “Como anda seu projeto?” e sua resposta, “Estou um pouco receoso que vou atrasar no cronograma.” Isso inicia uma discussão para resolver o problema, de onde vocês dois fazem novos planos para colocar o projeto de volta em dia. Em uma organização de culpa, entretanto, seu gerente pode lhe dizer que somente pessoas inferiores tem pouca confiança. Nesse caso, resolução de problema será substituído por evitar-a-culpa.

Do ponto de vista de um escritor, interações congruentes não são muito dramáticas; as pessoas apenas agem sensivelmente, tem consideração uns pelos outros, terminam seus trabalhos, e se divertem com o que fazem. Esse tipo de comportamento pode não dar uma boa cena de novela, do que seu gerente gritando em ira e você se encolhendo num canto, mas definitivamente resulta em projetos melhores.

Não que uma cultura de atribuir a culpa conduz toda interação de forma culposa, dramática. Sob circunstâncias ordinárias, resoluções congruentes são a regra, mas se as circunstâncias fossem sempre ordinárias, não precisaríamos de gerentes. Quando sentimentos de auto-estima estão em baixa, elas se manifestam de maneira mais dramática em resoluções incongruentes características: atribuir culpa, apaziguamento, ser super-razoável, amável ou odioso e agir de forma irrelevante. Não podemos lidar com tudo isso num artigo curto, então vamos discutir ‘atribuir a culpa’, talvez a forma mais comum e mais diretamente destrutível de estilo de resolução.

Sob estresse as pessoas tendem a perder o equilíbrio, e um ou mais de três componentes essenciais podem ser ignorados, levando ao característico estilo de resolução incongruente. Por exemplo, quando as pessoas falham em levar outras pessoas em consideração, eles caem em uma postura de jogar a culpa nos outros. Aqui vai uma típica ação de atribuir culpa que você vê em organizações de software (palavras em itálico são enfatizados nesse estilo de falar – porque múltiplas palavras enfatizadas em uma sentença linguística são sinais de jogar a culpa):

Gerente, quando o programador chega atrasado para uma reunião: “Você está sempre atrasado. Você nunca demonstra qualquer consideração pelas outras pessoas.”

Por que isso é incongruente? Se o gerente realmente está sentindo e pensando que o programador está sempre atrasado e não tem consideração, ele não está sendo congruente ao dizer isso? Sim, mas não é isso que esse gerente disso. Ele não disse, “é minha impressão que você está sempre atrasado para minhas reuniões.” Em vez disso, ele pronunciou sua impressão de atraso como se fosse um fato científico, nunca oferecendo a possibilidade do programador poder ter uma impressão diferente. Ele generalizou a experiência da sua reunião como se isso necessariamente se aplicasse a todas as reuniões, nunca permitindo a possibilidade de sua experiência não ser a única que conta.

Se o gerente realmente está sentindo e pensando que o programador está sempre atrasado e não tem consideração, ele deveria dizer, “eu acho que você está sempre atrasado, e eu acho que você não está tendo consideração comigo e com os outros. Essa é sua percepção também?” (e deixando de lado as palavras estressadas). Estilo de gerenciamento ainda melhor seria dar ao programador a chance de dar uma percepção diferente antes de lançar qualquer interpretação. No mínimo, isso evita embarassamentos em situações como a seguinte:

Gerente, quando o programador chega atrasado para uma reunião: “Parece para mim que você está sempre atrasado. Essa é sua percepção também?” Programador: “Sim, e eu me sinto mal sobre isso. A razão de eu estar sempre atrasado é que eu tenho que doar sangue para meu filho de 9 anos, que está morrendo de leucemia, e a única hora para doações é bem antes desta reunião.” Gerente: “sinto muito sobre seu filho. Não sabia disso. Vamos marcar a reunião para outro horário para que você não precise se atrasar.”

De forma geral, isso permite a possibilidade de que possa existir outras considerações que contem além daquelas desse único gerente. Por exemplo, talvez o programador está chegando de uma reunião com clientes – uma reunião que por acaso cruza horários com a reunião do gerente.

Mas e se o programador realmente está sempre atrasado, sem uma explicação razoável? O gerente não está no seu direito de culpar o programador? Na realidade não, porque essa situação não é sobre “se tem direito”, mas sim sobre ter o projeto finalizado. Para esse propósito, o problema é resolvido de forma mais efetiva confrontando sem jogar a culpa; com fatos sobre o comportamento inaceitável. Pulando a atribuição de culpa, o gerente mantém a comunicação clara e aberta, maximizando a chance do programador receber a mensagem intencionada. E, claro, receber a mensagem intencionada maximiza a chance (embora não garanta) que o problema irá se resolver.

Quando se atribui culpa, a resolução do problema tem menor chance de acontecer porque os fatos do caso se tornaram uma fator minoritário – o maior fator na atribuição de culpa é “quem é importante e quem é insignificante.” Quando se atribui culpa, a pessoa está dizendo, “Eu sou tudo, você não é nada.” Claro, isso não vem de realmente pensar “Eu sou tudo,” mas do oposto. Dirigir a atenção para outra pessoa – e jogar a culpa é normalmente acompanhado de apontamento de dedo – é um dispositivo de auto-proteção para distrair os outros do desconforto que o inquisidor sente.

Como toda resolução incongruente, atribuir culpa é reforçado por sentimentos de baixa auto-estima. Quando você culpa, você tenta se colocar no alto através de puxar o tapete dos outros, porque você não tem a segurança de que pode aguentar muito – ou mesmo sobreviver – de qualquer outra forma.

Jogar a culpa nos outros engana as pessoas pouco sofisticadas, ou cuja própria auto-estima seja bem baixa. O observador inteligente, entretanto, enxerga a quantidade de atribuições de culpa como uma medida segura de quão inadequado o inquisidor se sente. Mais do que isso, se jogar a culpa nos outros é o estilo de comunicação de projeto preferida, então se torna uma medida de quanto um ambiente se degradou – quão pouca comunicação é dirigida a assuntos de projeto, comparado à quantidade que é dirigida diretamente a estufar a baixa auto-estima do comunicador.

Em uma organização onde se joga culpas, não é somente o gerente que faz isso, como ilustrado por estes exemplos:

Programador, quando o gerente pede para falar com um candidato ao trabalho: “Por que você não faz isso você mesmo? Não vou fazer seu trabalho por você. Se fosse mais organizado, não precisaria me pedir essas coisas.”
Cliente, quando o gerente de projeto pergunta sobre a possibilidade de rever os requerimentos: “Você nunca acerta nos requerimentos da primeira vez. Se eu digo uma vez, já disse mil vezes. Faça o trabalho certo da primeira vez, daí não vai precisar me perturbar com revisões.”

Como Jogar a Culpa Machuca um Projeto

Claro, pessoas não são perfeitas, então é impossível conduzir um projeto grande sem ocasiões onde as pessoas são incongruentes. Gerenciamento normal de projetos pode lidar com essas situações – quando elas são excepcionais. Mas quando todo o ambiente encoraja jogar a culpa, cada nova situação complica ainda mais a incongruência. Fred Brooks uma vez perguntou, “Como um projeto de um ano acaba ficando dois anos atrasado?” Sua resposta foi “um dia de cada vez.” Nossa resposta é “uma comunicaçao incongruente de cada vez,” como o exemplo seguinte ilustra:

Um dos programadores estava desenvolvendo um módulo que produzia relatórios impressos quando era testado. O gerente colocou muita pressão no programador para que ficasse pronto no prazo, sem desculpas permitidas. O programador produziu um relatório e o gerente estava contente (embora ele tivesse demonstrado isso, claro – era “somente uma parte esperada do trabalho” na cultura de jogar a culpa). Um mês depois, outra pessoa tentou usar esse módulo e descobriu que ele não havia sido finalizado de jeito nenhum. O programador usou um Word para produzir um relatório falso que se parecia exatamente como um relatório de teste deveria se parecer. Ele pensou que isso lhe daria mais tempo (levou um mês, afinal de contas, até alguém descobrir) para finalizar o módulo. Infelizmente, como era muito trabalho, um mês não fora o suficiente.

O gerente culpou o programador. O programador não disse nada, porque nessa cultura de jogar a culpa, dizer alguma coisa só trás mais acusações na cabeça. A pessoa que reportou o incidente disse que nessa organização, falha não é permitida sob nenhuma circunstância. Pessoas que tem problemas em um projeto e conseguem prever atrasos não conseguem gritar por AJUDA! e receber assistência apropriada. De acordo com os gerentes, cada programador é responsável por atingir os prazos que concordaram. Estimativas inexatas “não eram permitidas” e perfeição deve ser atingida no primeiro dia – caso contrário você é colocado no pilar da culpa. Nessa situação, relatórios falsos são a regra, não a exceção (nota do Akita: para ser mais claro, substitua ‘relatório falso’ por qualquer dessas ‘gambiarras’ que vemos comumente em código.)

Jogar a culpa é o segredo negro do fracasso de muitos projetos. Uma cultura de jogar a culpa machuca um projeto de pelo menos seis grandes maneiras:

1. As pessoas se comprometem com planos que sabem que não conseguem atingir, pelo menos para atrasar o recebimento da culpa. (nota do Akita: já ouviu aquele programador que parece sempre “tenho muita coisa pra fazer, por isso não posso nem fazer direito, nem ajudar os outros” – o paradoxo: como pode “ter muita coisa” se foi ele mesmo quem concordou, em todas as vezes, com o que fazer?)
2. As pessoas escondem fatos que os gerentes precisam para controlar o projeto, como no exemplo acima. (nota do Akita: lembrem-se, “não ter problemas, é um problema” – significa que estão sob o tapete.)
3. Quando os problemas são finalmente revelados, as pessoas evitam sair com idéias de soluções criativas, por medo de levarem a culpa caso não funcione, ou simplesmente se fazem de joão-sem-braço.
4. Em operações de rotina, uma grande parcela dos esforços de cada um é devotado em se posicionar para não levar a culpa quando a hora chegar. (nota do Akita: exemplo, “a culpa é da outra equipe, a responsabilidade não é minha, ou só minha.”)
5. As pessoas que porventura se sentem seguras o suficiente para se focar no trabalho, se vêem gastando bastante tempo checando a confiabilidade na comunicação com os outros.
6. As pessoas se sentem mal a maior parte do tempo, e gastam muito tempo em tarefas improdutivas ou simplesmente olhando para as paredes.

A Aparência e Sentimento da Incongruência

Organizações podem mudar de uma cultura de jogar a culpa para uma cultura de congruência. Para fazer essa mudança, o primeiro passo é medir, ou pelo menos detectar – mas como medir atribuição de culpa? Na realidade, um consultor experiente consegue detectar uma organização de atribuição de culpa com poucos minutos de contato, porque os sintomas estão por todos os lados. De fato, as pessoas da organização já sabem que é uma cultura de jogar a culpa – mas, claro, numa cultura dessas, jogar a culpa é indiscutível e, mais ainda, a indiscutibilidade também é indiscutível. Paradoxalmente, a existência da indiscussabilidade torna mais fácil detectar a atribuição de culpa. O gerente de um projeto manda um e-mail dizendo que não haveria mais discussão sobre a moral do projeto, e que ele não prestaria mais atenção a questões do assunto porque todos deveriam estar gratos por estar trabalhando num projeto tão legal. Esse tipo de coisa só poderia acontecer numa organização onde se joga a culpa.

Executivos

Uma cultura de jogar a culpa começa no topo. Membros do nível superior de gerenciamento tem costume de enxergar as outras pessoas da organização como fontes de problemas. Os funcionários são vistos como “ingratos” por seus trabalhos, salários, benefícios e oportunidades dadas a eles. São vistos como tendo “falta de ética apropriada de trabalho”, “não saber dar valor”, “ter problemas de autoridade” e “resistir a mudanças”. Essas percepções deixam a alta gerência num dilema: “será que eu as demito, ou demito quem as contratou?”

Esse tipo de gerente sente que está tentando realizar uma visão sem ter o suporte necessário, o que os deixa no limbo. A experiência interna de inércia desses executivos é normalmente uma dor de cabeça contínua e crônica – a menos que as margens de lucro estejam muito baixas. Nesse caso, eles tem sentimentos mais apurados, como dor no peito e queimação no estômago. Suas baixas auto-estimas se refletem adiante na forma de frequentes downsizings, re-engenharias (nota do Akita: aqueles que em vez de encarar os problemas, ficam achando mais uma “metodologia” da moda para implementar, achando que isso resolve alguma coisa), evitar problemas mais sérios, e-mails fúteis e, claro, humilhar subordinados (nota do Akita: aqueles que largaram seu sub-gerente trabalhando, achando que estavam fazendo direito, e só recebem feedback negativo meses depois, quando é conveniente – que é um tipo de humilhação). A si mesmos, eles normalmente praticam comportamentos viciados e auto-destrutivos (que não podem ser discutidos, mas costumam ser assunto de fofocas.)

Gerência do Meio

Enquanto a alta liderança é incongruente, os gerentes do meio constantemente recebem mensagens misturadas. Cantarolam aos gerentes de projetos de sua importância e, então descobrem que seus sêniores os “bypassaram” (passaram sobre eles) para intervir diretamente em projetos ou mudaram as regras sem os consultar. Eles se sentem como se estivessem vivendo numa montanha-russa – sem conseguir prever se um determinado dia ou semana será bom ou ruim. Depois de serem publicamente humilhados algumas vezes, eles decidem que sua melhor estratégia é tentar ficar longe de problemas, sem chamar a atenção (nota do Akita: aqui começa a rotina do batedor-de-cartão conformado).

Em uma organização de atribuição de culpa, a alta gerência tenta (talvez de forma inconsciente) ensinar os gerentes do meio suas próprias atitudes de jogar a culpa. Quando um gerente de projetos reclamou da sua inabilidade de fazer os programadores trabalharem mais rápido, o Vice-Presidente de Desenvolvimento disse, “se seus cachorros não vão pular mais alto, encontre uma vara mais longa para bater neles.” Vivendo num inferno de incongruência vindo de cima, aparecem os problemas de sobrevivência da gerência do meio. Como faziam quando eram crianças, eles descobrem como acalmar, agradar ou evitar os donos do poder. Ao fazer isso eles asseguram sua sobrevivência – e passam a culpa para níveis mais baixos.

Funcionários

Na parte de baixo de uma organização de atribuição de culpa, os funcionários normalmente estão procurando por outro lugar para trabalhar a menos que a empresa esteja em uma condição estável e com pouca competição – ou se suas aposentadorias estão próximas. A maneira para sobreviver é se esconder e aparecer somente para pegar o contra-cheque (nota do Akita: e em épocas de depósitos automáticos, nem isso.)

Funcionários são desencorajados de pensar criativamente – novas idéias são interpretadas como jogar a culpa na gerência ou tentar usurpar seus poderes e prerrogativas. Funcionários não são recompensados por competência – mas são frequentemente punidos por “descuido” percebido. Funcionários não procuram seus gerentes – exceto quando há problemas. Então, a maior parte do esforço é gasto em tentar dar nome aos bois em vez de resolver o problema.

O estilo de jogar a culpa varia de organização para organização. Pode ser de forma dura, vingativa, direta ou indireta – mas é sempre contagiosa. Algumas organizações refinaram sua maneira de jogar a culpa a um alto grau de sutileza – sem gritos, meramente lançando um olhar, ou um e-mail, ou um telefonema, ou uma visitinha se as coisas são realmente ruins. Em outras organizações, a atribuição de culpa é na gritaria, raivosa e frequentemente feita na frente de uma platéia – para assegurar que todos entenderam a mensagem de quem está certo, quem é o “bonzão”, quem está no comando, e quem deve ficar invisível.

Nesse tipo de ambiente, se defender se torna comum. Para aqueles sem poder formal ou autoridade, parece que aqueles com poder não se importam com eles – e os baniriam sem nenhum remorso. Então eles se sentem no direito de retaliar (adiantado, e em segredo), e em evitar seus gerentes e seus problemas.

Independente do estilo, jogar a culpa do topo sempre gera medo, desconforto, erros, acidentes e respostas passivo-agressivas de baixo. Aqueles embaixo se sentem pequenos e agem de um lugar sem poder. A falta de segurança emocional efetivamente corrói os níveis de confiança e torna qualquer tentativa de congruência extremamente arriscada. O ambiente deles soa assustador e é – tanto para a pessoa que regrediu para imaturidade emocional e, tristemente, para a pessoa no topo que está jogando a culpa.

Aqueles na camada de baixo de qualquer grande organização podem facilmente vir a sentir um senso de dependência àqueles acima deles na hierarquia. Quando jogar a culpa é o modo primário de lidar com pessoas, essa dependência é exacerbada (nota do Akita: quase uma síndrome de Estocolmo). Então, de um sentimento de dependência, as pessoas facilmente geram um sentimento de hostilidade. À medida que essa hostilidade aumenta também aumenta a experiência debilitante de vergonha – aquele juíz excessivamente crítico que existe latente em todos nós, humanos.

A Aparência e Sentimento de Congruência

A maioria das pessoas que experimentaram uma organização congruente não vão tolerar a miséria de trabalhar em uma organização de atribuição de culpa. Mas muitas pessoas sequer tiveram essa experiência, e tem dificuldade em acreditar em congruência. Vamos ver o que aconteceria se uma dose saudável de congruência pudesse ser magicamente aplicada em larga escala a uma organização incongruente de projetos.

Executivos

Se pudéssemos magicamente instalar congruência nos programas internos desses executivos que jogam culpa, o estilo deles mudaria dramaticamente. Por exemplo, se eles verdadeiramente considerassem os outros envolvidos em sua comunicação, possivelmente acreditariam nas intenções das pessoas de contribuir, de serem produtivos, de pertencer e de aprender – e interpretariam desvios desse ideal como evidência de gerenciamento não efetivo. Sua crença no valor inerente de todas as pessoas com respeito saudável pelas limitações do contexto do trabalho traria energia, esperança, agradecimento, compreensão e gratidão entre seus funcionários.

Um executivo congruente que realmente não acreditasse nas boas intenções dos funcionários diria ‘Sem desculpas! Você terá isso pronto em Outubro.’ Mas, com funcionários cujas intenções são ruins, esse estilo (ou qualquer outro) não funcionaria mesmo.

Quando a alta gerência mantém seu compromisso com congruência, eles vêem que a maioria dos trabalhadores aprecia a oportunidade que o negócio lhes proporciona para desenvolver suas capacidades, sentido, relacionamentos e recompensas monetárias. Eles também sabem como agir quando o trabalhador ocasional não parece apreciar ou ser produtivo. Gerentes que sabem como usar seu poder de forma congruente geralmente conseguem os resultados que procuram – não perfeição, que eles sabem que não devem esperar.

Esses líderes sabem que possuem um tipo especial de poder – poder que usam com consciência e sensibilidade. Eles não deixam de cobrar daqueles que lideram, mas demonstram o mesmo nível de integridade que procuram nos outros. E se não conseguem encontrar os níveis de comprometimentos que requisitam dos outros, eles são abertos quanto a isso. Eles sabem que de vez em quando serão fracos e vulneráveis e precisam de apoio – talvez até para ver o valor de suas próprias visões. Eles usam sua consciência dessa realidade humana para cultivar sua capacidade de empatizar e de ter compaixão por si mesmos e pelos outros.

Executivos congruentes sabem que seu trabalho principal é desenvolver as capacidades de sua organização, não apenas empurrar os mesmos velhos produtos e serviços porta afora. Eles se envolvem de maneira séria nos esforços de melhoria da organização e simultaneamente envolvem outros da organização para conseguir os esforços na vida real, prática operacional e tomada de decisão. Eles sabem que sinergia é necessária para o desenvolvimento da organização e sabem que sinergia vem com conexões de alta qualidade entre as pessoas – independente de nível.

Gerência do Meio

Quando o pessoal do topo começa a operar com congruência, os gerentes do meio recebem mensagens claras e diretas – não mensagens misturadas com duplos sentidos. As comunicações são mais abertas, tornando mais fácil saber mais sobre o que está acontecendo. Dada informação de alta qualidade, eles sabem mais como podem ser úteis, conseguindo mais facilmente se unir a seus líderes em suas visões. Saber mais claramente as direções estratégicas desejadas, e sentir que eles contam nesse processo, os libera para contribuir de forma mais generosa e consciente – em vez de meramente jogar com segurança. Sucesso se torna um objetivo que todos podem compartilhar.

Dada sua posição única de vantagem, as pessoas do meio tem dados mais úteis para ajudá-los a prever problemas, projetar linhas do tempo realistas e predizer tendências. O que eles vêem, ouvem, pensam e sentem é valorizado e eles estão numa posição de iniciar comportamentos que evitam que fraquezas dos projetos cresçam até o fracasso. Eles conhecem a necessidade de interdependência, então se problemas maiores acontecem, eles podem ser considerados para oferecer – e também procurar – por informações importantes. Eles não estão envergonhados nem com medo daqueles que os contrataram. De fato, têm orgulho de seus compromissos com a organização – e sabem que não se trata apenas de compromissos como prazos e orçamentos, mas sobre a verdade sobre esses prazos e orçamentos.

E como congruência que vem do topo também vai para baixo, gerentes do meio notam a diferença entre seus líderes. Eles respondem ao modelo passando isso a seus constituintes. Todos na organização sabem o que está em jogo em cada trabalho bem feito, então todos se sentem seguros em dizer o que está errado, o que está atrapalhando e o que precisa ser consertado. Relatórios honestos de fatos e sentimentos são genuinamente apreciados e não colocam as pessoas em risco de serem humilhadas ou perderem seus empregos. É por isso que organizações congruentes entregam seus projetos como prometido.

Gerentes do meio congruentes encorajam comunicação de alta qualidade. Sua crença na habilidade das pessoas de aprender e mudar em direção a mais congruência tornam aqueles ao seu redor mais responsivos. Com radiação de congruência a partir do centro da organização, todos podem ter um lugar, posição e função de importância e valor – então as coisas acontecem da maneira correta.

Funcionários

Trabalhar na linha de frente de um negócio onde a liderança de cima é congruente, é uma experiência inteiramente diferente de trabalhar numa organização de atribuição de culpa. Compromisso e energia são a norma, não a exceção praticada por novos funcionários até eles “aprenderem como as coisas funcionam por aqui.”

Organizações congruentes suportam uma ideologia que fazer direito no mercado está ligado a lidar direito com os funcionários assim como com os clientes. A perspectiva da liderança inclui consciência global sobre a existência de múltiplos fatores não-lineares, a importância das conexões entre as várias partes do todo e a necessidade de todas as partes saberem seu valor. Os funcionários sentem que esta é uma empresa indo para algum lugar, onde crescimento é um estado natural e o esforço de todos conta. (nota do Akita: essa é a semente para equipes auto-gerenciadas.)

Trabalhadores numa organização congruente tendem a ter uma visão ampla e podem normalmente manobrar como necessário para atingir as mudanças demandadas pelos clientes. Os funcionários confiam que o que vêem e ouvem é real. Eles compartilham do entusiasmo de criar o futuro. Eles podem não gostar de tudo que acontece – por exemplo, nem sempre acham que estão sendo recompensados adequadamente pelo o que estão dando – mas não se sentem num padrão crônico de diminuição, descrédito e desvalorização do que fazem. Eles podem arriscar a congruência sabendo que isso vai agir como um catalisador para otimizar resultados de sucesso que beneficiam a todos.

Congruência é o grande segredo por trás dos sucessos de muitos projetos. Uma cultura de congruência ajuda um projeto de pelo menos seis grandes maneiras:

1. As pessoas se comprometem com planos somente depois de negociações abertas, então os planos tem mais chances de serem realistas logo no começo. (nota do Akita: a equipe se compromete apenas com aquilo que realmente acredita que vai entregar – não existe “tenho coisas demais para fazer”)
2. As pessoas vêm rapidamente com fatos, que os gerentes precisam para controlar o projeto, tão logo se tornarem conhecidos, então os gerentes podem agir mais rapidamente com movimentos pequenos para corrigir os problemas. (nota do Akita: cultura ágil que aceita a mudança.)
3. Quando problemas são revelados, as pessoas vêm rapidamente com idéias de soluções criativas, aumentando as chances de soluções rápidas e efetivas.
4. Uma boa parte dos esforços de todos é devotado a terminar o trabalho e ajudar os outros a terminar o trabalho deles.
5. Porque a falabilidade humana é considerada normal, uma quantidade apropriada – mas pequena – de tempo é gasto garantindo a confiabilidade da comunicação.
6. As pessoas se sentem bem a maior parte do tempo, e por isso são produtivas a maior parte do tempo.

Congruências em Grandes Esforços de Desenvolvimento de Sistemas

No percurso de desenvolvimento de sistemas, as pessoas engajam em numerosos atos de comunicação – sobre requerimentos, prazos, problemas interpessoais, designs, progresso e mais. É por isso que comunicação individual efetiva é importante em todos os projetos, grandes e pequenos. Isso dito, isso se torna ainda mais importante à medida que crescem os esforços de desenvolvimento. A quantidade de comunicação necessária sobe de forma não-linear com o tamanho do projeto, então o efeito de estilo de comunicação imperfeita é aumentada. Portanto, se a qualidade individual de comunicação se mantém constante à medida que o projeto cresce, a qualidade geral da comunicação decai. (nota do Akita: quantidade de conexões entre pares cresce segundo uma Lei de Potência.)

Por exemplo, um certo nível de congruência de comunicação pode ser adequado para produzir um produto com 25 mil linhas de código, mas totalmente inaceitável para um produto com 2,5 milhões de linhas de código. Para desenvolver sistemas grandes ou complexos, então, não é suficiente prestar atenção aos problemas técnicos – aceitando que o estilo existente de comunicação será adequado. Gerentes também devem melhorar a cultura de comunicação do projeto e, portanto, precisam prestar atenção à congruência.

Para tornar as coisas piores, se não for gerenciado direito, projetos difíceis tendem a diminuir a congruência – porque o estresse tende a subir quando a expectativa de qualidade decai. Não somos criatura altamente lógicas o tempo todo, mas temos sentimentos, assim como pensamentos em resposta a responsabilidades difíceis. Quando esses sentimentos internos são fortes o suficiente, eles se traduzem em estilos característicos de resolução sob estresse. Se nosso estilo característico é incongruente, as comunicaçoes se tornam menos efetivas e o trabalho se torna ainda mais difícil, criando um ciclo vicioso.

Congruência, claro, é apenas um dos fatores em comunicação efetiva – outros fatores incluem coisas como tempo, memória, platéia adequada e dados precisos. Mas sem congruência, seus esforços de melhorar esses fatores “lógicos” serão sempre seriamente sabotados, junto com sua habilidade de construir sistemas maiores, mais complexos ou mais confiáveis.

Atingindo Congruência

Quando Deming disse, “Coloque o medo fora do ambiente de trabalho,” nós achamos que ele estava falando sobre mudar a organização que atribui culpa a uma organização congruente. Esse tipo de mudança é apresentada a uma pessoa de cada vez – de preferência começando do topo – um passo de cada vez. Os passos podem ser quebrados em seis partes: Conscientização, Aceitação, Autoria, Articulação, Aplicação, Ativismo. Vamos olhar como cada um deles aparece no contexto de um indivíduo tentando mudar a organização que atribui culpa.

Conscientização

Conscientização diz, “Isto está acontecendo. Isto é real.” Conscientização vem da experiência, quando eu me permito experimentar o mundo ao meu redor como ele é – não como deveria ser, ou como eu acho que deveria ser, ou como alguém me diz que deveria ser.

Conscientização é sempre o primeiro passo e provavelmente o mais difícil, porque geralmente não estamos conscientes que não estamos conscientes. Aqui vai um exemplo pessoal de como falta de conscientização pára o processo de mudança antes mesmo de começar:

Jerry estava participando de uma reunião de projeto em uma empresa de software – uma reunião chamada pelo presidente da empresa para descobrir o que estava acontecendo em um projeto atrasado. Depois de alguma persuasão, um dos programadores disse que estava com medo de ir até o Nat, o Gerente de Desenvolvimento, com problemas, por causa da recepção que teve. Nat ficou com a cara vermelha, se levantou e gritou nervoso “Como pode dizer isso? Minha porta estava sempre aberta para ouvir seus problemas! A única coisa que não vou tolerar é se você fica todo tenso quando chega, ou se não tem uma solução para propor!”
Na voz mais calma que conseguia (é difícil ficar calmo quando alguém está tão nervoso, mesmo se não diretamente a você), Jerry se virou ao Presidente e perguntou se Nat alguma vez foi até ele com problemas. Quando o Presidente disse que sim, Jerry perguntou se o Nat estava sempre calmo e carregando uma solução proposta. Antes do Presidente poder responder, Nat interrompeu: “Por que eu iria com um problema se não era importante o suficiente para se excitar a respeito? E, se eu tivesse uma solução, por que eu iria até ele?”
Embora estivesse claro para todo mundo na sala que o Nat estava demandando que os outros “façam como eu digo, não como eu faço”, ele era incapaz de ver a incongruência. Faltando conscientização, não havia jeito do Nat mudar – e de fato ele nunca mudou, até o dia que o Presidente o demitiu para que pudesse procurar por pastos mais verdes.

O caso do Nat é bem típico. Já que incongruência é uma defesa, pessoas incongruentes sobem todos os tipos de escudos que fecham a informação sobre congruência. Sua própria incongruência e a dos outros é invisível – isso é aceito, especialmente se é o normal na organização. Essa invisibilidade torna muito difícil alcancá-los com qualquer tipo de informação sobre o assunto.

Em outras palavras, quando você está sendo incongruente, você está perdendo sua habilidade de ver o que está acontecendo no mundo (dentro e fora). Então, não sabe que precisa mudar. E, mesmo se souber, não tem nenhuma idéia do que mudar para. Não admira que é tão difícil transformar uma cultura incongruente, quando o primeiro passo – conscientização – já é tão difícil de conseguir.

Conscientização vem da experiência, quando você se permite experimentar o mundo ao seu redor – não como ele deveria ser, ou você gostaria que fosse, ou como alguém lhe diz que gostaria que fosse. Mas numa organização que atribui culpa, onde as pessoas se protegem dessa experiência, se tornar consciente normalmente requer ajuda. Ajudar os outros a se conscientizar demanda habilidades para desenvolver ambientes seguros e construir relacionamentos. Demanda paciência e carinho para observar por sinais de conscientização e ajudar a construí-lo. Também demanda fé e um comprometimento de que “parte do meu trabalho é ajudar as pessoas da minha equipe a se desenvolver – a parte mais importante.” Se não acredita nisso, então certamente não tente ajudar. Caso contrário, vai se encontrar dizendo “Você não está consciente de quão ruim você é, mas eu vou torná-lo consciente!”

Mas conscientização da situação geral não é suficiente – você também precisa de auto-conscientização. “Este sou eu. Isso é meu.” Você pode estar consciente da jogatina de culpa, mas enquanto meramente apenas disser “Esta é uma organização de atribuição de culpa,” você não está fazendo coisa alguma para mudar isso. Quando você diz, “Eu sou parte desta organização de atribuição de culpa,” você está dando um passo. Você deve ver a jogatina de culpa como uma parte de si mesmo e de seu comportamento – não apenas alguma coisa que “eles” fazem (a você).

Auto-conscientização é normalmente seguido ou de vergonha ou de culpa. Algumas pessoas reagem com raiva, a si mesmos ou a algum alvo conveniente. Ainda assim, auto-conscientização dá sensação de poder – o pensamento de que já que me pertence, é meu para eu fazer alguma coisa a respeito.

Aceitação

Aceitação move o processo de mudança além de alto-culpa e diz, “Eu não sou uma pessoa má porque faço isso. Minhas intenções são boas, embora minhas ações possam não ser efetivas.”

Aceitação significa que você entende que tomar a responsabilidade não é a mesma coisa que se culpar. Portanto, você tem clemência de si mesmo e de suas imperfeições humanas. Você pára de ser raivoso. Perdoa a si mesmo por não ter feito melhor no passado, baseado no seu entendimento presente e padrões. E, enquanto perdoa e aceita a si mesmo, você ganha compaixão pelos outros envolvidos – aumentando as chances de conseguir se comunicar com eles e efetuar mudanças.

No ponto quando você está tentando alcançar aceitação, é crítico que não seja punido ou humilhado por alguém. Você precisa de ajuda em suportar suas costas, do contrário você pensa tão pouco sobre si mesmo que não poderia fazer qualquer coisa sobre a situação. Claro, em uma organização que atribui culpa, pode ser difícil, por um tempo, evitar esse tipo de punição, que é o motivo pelo qual autoria e aceitação normalmente acontecem internamente, e se mantém internos por algum tempo.

Autoria

Autoria é o primeiro ponto de decisão, quando você diz, “Eu tenho escolhas. Eu posso fazer alguma coisa a respeito.” Com algum encorajamento, você aceita que é responsável por escolhas na sua vida. Você entende que não precisa reagir, mas que pode escolher suas respostas – que você consegue criar, em grande parte, seu próprio contexto interpessoal. Você sabe que existem algumas partes do contexto que pode controlar e algumas que não pode; e sabe precisamente qual é qual.

Articulação

Articulação é o compromisso público de mudar e dizer “Eu vou a público com isso (para assumir responsabilidade e conseguir suporte.)” Articulação não é efetiva se tentada antes dos pré-requisitos estarem nos lugares. Se não consegue aceitar a si mesmo ou como você se refletia para o mundo, ou se não sabe que tem escolhas ou sente que pode ganhar suporte com essas escolhas, então falar para fora é meramente uma bravata não efetiva.

Mas quando os pré-requisitos estão nos lugares, você não consegue ser efetivo mantendo silêncio – você precisa decidir falar. No processo de falar você transforma sua conscientização interior para outro tipo de experiência. Você se ouve e nota a resposta que recebe dos outros. Você torna público, se quiser, a si mesmo – sua posição mental e emocional.

Inicialmente, claro, você precisa procurar lugares para abrir suas expressões verdadeiras e honestas de seus pensamentos e sentimentos. Quando se acostuma mais com o poder de seu verdadeiro você, então consegue procurar o tipo de suporte que o desafia e o confronta, em vez do tipo de suporte que o protege ou consola.

Passos iniciais da articulação congruente normalmente são desajeitados. É por isso que um ouvinte responsivo e receptivo satisfaz um dos requerimentos para promover desenvolvimento e congruência.

Aplicação

Aplicação diz, “Estas são minhas escolhas (minhas novas maneiras de resolução).” Você consegue aprender a ser congruente, primeiro no contexto mais imediato, seguro e encorajador. Então expande os contextos nos quais consegue responder congruentemente. Não tente “não ser incongruente”. Esse comando paradoxal somente envolve incongruência e perfeccionismo. (“Se não consigo ser perfeitamente congruente o tempo todo, eu não valho nada.”) Foque na congruência, pratique congruência e os “músculos” da incongruência vão simplesmente atrofiar.

Com suporte e prática você consegue começar a usar e testar congruência nos seus relacionamentos imediatos. Sugerimos que continue a desenhar para o sucesso, de tal forma que esses testes iniciais de sua nova habilidade sejam feitos dentro de ambientes onde seja mais factível que lhe dêem o benefício da dúvida. À medida que experimenta sucesso, então você consegue se centrar até mesmo em arenas mais turbulentas e de conflito. Em outras palavras, uma vez que você “entende o recado”, não marche à sala do presidente e anuncie que, a partir de agora, todas as partes culpadas devem parar de jogar a culpa, ou caso contrário.

Ativismo

Ativismo diz, “Agora que eu consigo fazer diferença em mim e em meu mundo mais familiar, vou ajudar a espalhar isso pela organização.” Ativismo é liderança aplicada, começando pelo ponto onde você tem competência suficiente em ser congruente para alcançar e ser pró-ativo – antecipando, iniciando, instigando – mas não infligindo. Você não consegue operar de uma posição de incongruência e forçar outras pessoas a serem congruentes. (“Eu preciso culpá-los, porque eles também jogam tanto a culpa (nota do Akita: “sabonetam”). Quando eles mudarem, então eu serei capaz de mudar.”)

De qualquer forma, você não deve infligir congruência a qualquer um. Congruência é contagiosa – quando dirigida de forma consciente para criar um ambiente seguro, de cultivo, produtivo. Pode se espalhar mais devagar do que você gostaria, mas uma vez que começa a se mover, é difícil parar.

Fonte: Akita on Rails

Matthew Hotle
8 de maio de 2009

Descobertas chave

• Mudar sua estrutura organizacional deveria ser o último recurso.
• Recursos humanos qualificados e determinação são mais importantes do que uma melhor estrutura organizacional.

Recomendações

• Não faça mudanças organizacionais para solucionar problemas nos processos. Foque primeiro o próprio processo.
• Use atribuições rotativas de tarefas e outros incentivos para gerar determinação se a segmentação for sua opção.
• Assegure-se de que os acordos de nível de serviço (SLAs) tenham sido implementados antes de realizar a mudança organizacional.

O QUE VOCÊ PRECISA SABER
Os clientes costumam perguntar se deveriam dividir seu pessoal entre projetos (geralmente associados a desenvolvimento, na verdade se referem a trabalho líquido e novo, e a projetos de aperfeiçoamento) e suporte. As empresas que já se encontram nessa situação perguntam se seria melhor dividir o pessoal ou se deveriam voltar a ser uma empresa de estilo misto. Se isso soar mais como um estilo de tomada de decisões do tipo “será que a grama está mais verde”, então é mesmo. A maioria das empresas que cogita dividir suas estruturas organizacionais seguindo esses preceitos está na verdade tentando solucionar uma de várias questões relativas a seus processos:

• Os projetos estão atrasados (embora sem ultrapassar o orçamento) porque os recursos alocados para eles foram transferidos para a área de suporte.
• As qualificações da área de suporte estão totalmente unificadas, sem nenhum backup ou contingência.
• Os requisitos de recursos para suporte estão fragmentados.
• O pessoal qualificado para a área de suporte ou não está disponível, ou logo não estará mais disponível devido a aposentadorias ou transferências.
• Relacionamentos problemáticos entre os diferentes grupos geram problemas significativos de gestão e estado de espírito.

Mudar simplesmente a estrutura organizacional não irá solucionar nenhum desses problemas. De fato, mudar a empresa irá, todas as outras coisas mantendo-se as mesmas, tornar os problemas ainda piores durante seis a 18 meses, simplesmente porque, além de possuir processos problemáticos, a empresa enfrentará a distração de um novo quadro organizacional. Há bons motivos para mudar um empresa (esta pesquisa não se refere a quando mudar, mas a como mudar), mas fazer isso deve ser algo cuidadosamente avaliado e ponderado com o potencial das mudanças nos processos de solucionarem efetivamente os problemas, e não apenas mudarem o pessoal de lugar.

ANÁLISE
A primeiro regra para mudar um desenho organizacional: Não faça isso!

É claro, isso nem sempre é verdade. Porém, modificar os relacionamentos de reporte e o lugar das pessoal com certa freqüência é um dos principais problemas que as divisões de aplicações enfrentam. É relativamente fácil porque os relacionamentos e a dimensão do controle são algo sobre os quais os gestores têm controle direto, e o mais importante, é fácil ver que uma mudança está sendo feita. Porém, há dois problemas aqui:

• Mudar a estrutura de uma empresa resultará entre 6 a 18 meses de ruptura. Alguns se associam a seus chefes; enquanto outros não se sentem à vontade com eles. Independente disso, quando os relacionamentos de reporte organizacional forem modificados, haverá um período de acomodação entre os novos associados e sua gestão. Haverá também um período de tempo em que as partes da empresa sujeitas às modificações deverão se realinhar para que o trabalho possa fluir novamente pela nova estrutura de gestão.
• Os maus processos continuam sendo maus. Isso é realmente fundamental aqui. Muitas empresas tentam mudar seus quadros organizacionais para solucionar um problema dos processos, mas isso não funciona. Solucione o problema primeiro, e então escolha uma estrutura organizacional que funcione.

Grande parte das atividades nas empresas tem origem em relacionamentos informais e em processos implícitos. Status ou poder já foram atribuídos nas estruturas já existentes. Muitas empresas têm muito pouca consciência desses aspectos, e os danificam ou destroem durante os processos de reorganização. Infelizmente, algumas das estruturas e processos que deveriam ter sido modificados sobrevivem ao processo de reorganização.

Para colocar isso tudo no contexto desta discussão, muitas empresas estão de problemas de RH e de planejamento através da segmentação de suas estruturas organizacionais. Vamos presumir que haja bons motivos para dividir a empresa, incluindo aqueles citados acima. Qual é a mecânica dessa separação?

Aspectos Fundamentais de uma Divisão das Áreas de Projetos/Suporte
Se você estiver prestes a segmentar sua empresa, então o seguinte conjunto de passos será crucial ao fazer isso:

• Defina claramente o que é um projeto e quais atividades serão atribuídas à área de suporte. Isso poderá parecer fácil, mas muitas empresas referem-se a um projeto como alguma espécie de massa amorfa de trabalho, ou como qualquer coisa que precise ser administrada. Para os fins desta discussão, vamos presumir que um projeto é algo que contenha um mínimo de 320 horas. Há algum sentido nisso: usando o mínimo necessário de oito horas para o planejamento de tarefas estabelecido pelo Project Management Institute (PMI), vamos presumir que um projeto possua cinco fases (requisitos, análise/design, código, teste e implementação), e que cada uma dessas fases possua apenas três atividades. Cada atividade possui três tarefas associadas a ela. Temos agora um total de 15 tarefas (cinco fases: três atividades por fase e três tarefas por atividade), o que gera um total de 320 horas. Tudo o mais fica a cargo da área de suporte. Geralmente, há três tipos de atividades de suporte: reparo de defeitos, pequenas mudanças ou aperfeiçoamentos, e outros trabalhos necessários para atender aos SLAs. O trabalho de conformidade ou observância regulatória poderá na verdade entrar em qualquer uma das categorias de projetos ou suporte. Se houver uma necessidade consistente de pessoal para realizar essas mudanças, então essas mudanças poderão ir para a área de manutenção. Se a demanda for esporádica, então será melhor lidar com elas como se fossem projetos, colocando-as no topo da cadeia de prioridades.
• Para cada aplicação ou grupo de aplicações, crie um SLA. Ou seja: Suporte consiste no reparo de defeitos, pequenos aperfeiçoamentos, e outros trabalhos necessários para prover suporte aos SLAs (resposta a questões corporativas, realização de análises conjunturais e assim por diante). Aqueles serviços devem ser claramente definidos e codificados em um SLA que proveja à empresa e à divisão de aplicações um mecanismo para atender aos níveis de serviços desejados pela empresa. Isso proverá também um mecanismo para dimensionar a divisão de suporte.
• Com base nos requisitos dos SLAs e de trabalho, dimensione a estrutura organizacional. Infelizmente, é daqui que parte a maioria das empresas que desejam segmentar seu pessoal. Determinar quantas pessoas devem estar na divisão de suporte é um terreno desconhecido até que você determine: (1) a taxa de contratação segundo a gravidade dos defeitos; (2) quantas pessoas a empresa está disposta a pagar para realizar os pequenos aperfeiçoamentos; e (3) quais outros serviços devem ser realizados, quando e como (veja “Administrando a Inexorável Demanda por Trabalho em Aplicações”).

Até agora, tudo isso é razoavelmente simples. Agora, porém, chegamos ao que é talvez o maior impedimento para a realização de uma segmentação: os próprios associados. O reparo de defeitos requer pessoas que estejam acostumadas e dispostas a trabalhar sob pressão, e que sejam muito bons solucionadores de problemas. Geralmente não há pouca oferta de tais recursos humanos, mas é algo que vale a pena observar porque poderá haver pessoas dispostas a realizar o trabalho de suporte e que não possuam as qualificações básicas. O maior problema, porém, é que muitos profissionais de TI simplesmente não desejam realizar somente o trabalho de suporte. Eles consideram uma tarefa de suporte como uma via sem saída, um predecessor da terceirização ou uma mudança que limitará suas perspectivas. Por outro lado, os que pertencem à comunidade de desenvolvedores poderão vir a ver a si mesmos como superiores aos profissionais da divisão de suporte. Ao realizar o trabalho de segmentação, as empresas precisam pensar em como poderão fazer com que seu pessoal se sinta confortável realizando uma tarefa de suporte e disposto a aceitá-la. Há um alguns mecanismos chave para fazer isso:

• Pague um bônus ao pessoal de suporte. Muitas empresas recusam-se a fazer isso, pois consideram que o trabalho de suporte não possui valor agregado.

Fonte: Info Corporate

Dentre as ações que os CIOs devem tomar para manter as operações funcionando diante de uma crise, estão a atualização de todos os contatos, treinamento de funcionários para trabalho remoto e teste das aplicações baseadas na web

Redação do COMPUTERWORLD
Publicada em 04 de maio de 2009 às 08h10

Com o crescimento do registro de casos com diagnóstico positivo da gripe suína, aumenta também a necessidade de um plano de continuidade de negócios que garanta, efetivamente, a operação da companhia em qualquer circunstância ou adversidade.

As discussões trazidas à tona pela epidemia podem ser boas oportunidades para os departamentos de TI renovarem seus projetos de contingência e reconquistarem a confiança dos seus clientes internos. Seguem dez dicas de como desenvolver ou reativar um plano para continuidade de operações:

1- Fique calmo
Adote o comportamento que quer ver nos seus funcionários. Continue a ser produtivo e aumente seus estoques de água engarrafada e higienizador para mãos. “O que os líderes de TI devem fazer é manter o negócio rodando normalmente, mas melhorar as práticas de higiene pessoal”, afirma Richard De Lotto, analista principal para bancos e indústria financeira do Gartner. “Outras pessoas vão seguir o exemplo dado por altos executivos”, diz.

2- Envolva todo o time de executivos no planejamento de continuidade de negócios
Se preparar para uma pandemia não é uma questão de tecnologia, mas de negócios. “A tecnologia da informação não precisa estar à frente desse processo porque trata-se de mais do que fazer backup dos dados”, explica David Potterton, vice-presidente de pesquisa global da IDC Financial Insigths. “Líderes seniores de negócios é que precisam estar à frente da questão. Você precisa entender qual é o seu sistema mais importante e isso é uma questão de negócios, não de tecnologia.

3- Atualize e teste seus contatos
Muitas empresas passaram por cortes nos últimos seis meses. Por isso, as listas de funcionários e as formas de contatá-los podem estar desatualizadas. Renove a lista e teste seu sistema de ligações de emergência. “Você precisa de um canal confiável de comunicação conhecido por todos”, diz De Lotto. “Pode ser um número que o funcionário ligue para ver ser precisa ir trabalhar, ou um sistema automatizado para mensagens de voz”, explica o analista.

Ligue para os proprietários dos imóveis onde estão localizados seus data centers e tenha certeza que terá acesso total às instalações em locais afetados pela gripe. É provável que seja preciso estabelecer um site remoto ou trocar de data center. Se a operação for terceirizada, inclua os fornecedores em seu plano de contingência. “Um centro pode necessitar de trabalho extra, ou você pode precisar evacuar uma área. Existem muitos cenários a serem considerados”, relata Potterton.

5- Teste seus planos e sistemas para trabalho remoto
Muitas empresas confiam na possibilidade dos seus empregados trabalharem de casa para continuar operando durante uma crise de gripe. Entretanto, os sistemas de acesso remoto precisam estar prontos para um grande número de pessoas conectadas ao mesmo tempo. Especialistas recomendam um teste no qual seja permitido a um número significativo de funcionários trabalhar remotamente por um dia. Talvez seja preciso disponibilizar mais portas para sistemas de acesso remoto.

“Tenha certeza que tem alta disponibilidade para todos os seus sistemas de acesso remoto”, recomenda Phil Hochmuth, analista sênior do Yankee Group. “Certifique-se, também de ter um sistema secundário de acesso em caso de falha. É preciso prover o maior número de portas possível”, afirma.

6- Tenha certeza que funcionários importantes contam com acesso banda larga
Acesso discado não basta para funcionário que precisam usar aplicações corporativas por um período grande de tempo. Pessoas importantes na corporação devem ter banda larga, móvel de preferência. “No pior cenário, alguém pode precisar trabalhar enquanto se move de uma área para outra”, diz Hochmuth. O analista recomenda a compra de links móveis de várias operadoras.

7- Teste suas aplicações baseadas na web
Tenha certeza que o e-mail e outras aplicações baseadas na web estejam atualizados. “As aplicações web devem ter o mesmo nível de serviço das versões tradicionais”, diz Hochmuth. “Identifique alguns usuários de alta intensidade e faça alguns testes com eles. Ao mesmo tempo, pegue alguns usuários novos e veja quanto é difícil para eles usarem o acesso remoto”, aconselha o analista. Outra ideia é usar aplicações web voltadas para o mercado consumidor, como Google Docs e Skype, como backup.

8- Treine seus funcionários
Identifique quais aplicações são críticas e precisam continuar rodando em qualquer situação e quem pode garantir isso. Treine seus funcionários para que haja pessoas com as habilidades e certificações corretas em número suficiente para manter os sistemas de missão crítica funcionando. Isso é especialmente importante em mercados regulados, como o financeiro, nos quais os profissionais precisam de certificação para lidar com dados de clientes. “Tenha pessoas certificadas por toda a organização, assim é possível manter as portas abertas”, aconselha De Lotto.

9- Desenvolva um plano de degradação
Considere que terá de rodar sua operação por 13 semanas com apenas 60% do pessoal, recomenda De Lotto. “Saiba o que você não vai fazer para poder rebaixar sem problemas o nível de operação”, afirma. Também crie linhas sucessórias, assim é possível saber quem vai comandar o departamento caso o chefe fique doente. Determine quem vai ficar no comando e garanta acesso aos dados para este profissional.

10- Cuide do seu pessoal
A reação correta para uma pandemia ou outro desastres é saber, primeiro, se seus funcionários estão bem. Depois, preocupe-se com a continuidade dos negócios. “As empresas precisam pensar primeiro nos funcionários. A tendência é olhar para equipamentos e instalações, e não para a força de trabalho”, diz Potterton. As companhias também precisam entender que seus funcionários vão cuidar de si próprio primeiro, depois de seus familiares e, então, pensarão em seus empregos e clientes.

Fonte: CIO

Postado por Vikas Hazrati, traduzido por Acyr Tedeschi em 13 Abr 2009 11:29 AM

Tradicionalmente (o termo) Governança de Projeto é utilizado pra descrever o conjunto de regras e processos necessários para garantir o sucesso de um projeto. Tenta tratar o projeto de trabalho como um processo de trabalho. Entretanto, a importância dada à utilização de folhas ponto, custos e horário superam em muito questões mais importantes como: benefícios do projeto, controle de risco, envolvimento de recursos humanos, qualidade, escopo e controle de objetivos. À primeira vista os conceitos de governança e de Metodologia Ágil parecem ser incompatíveis, entretanto, muitos "Agilistas" concordarão que Governança pode fazer mais bem que mau aos projetos Ágeis.

Andrew Clifford sugeriu os seguintes benefícios da governança,

• Aumento do valor das ações porque sistemas de TI são tratados como patrimônio dos negócios.
• Melhora na relação de TI com a empresa porque as exigências de infraestrutura de TI são traduzidas para objetivos mensuráveis.
• Aumento no retorno dos investimentos em TI porque, com o gerenciamento, sua utilização é mais eficiente.
• Redução de erros de projeto porque assuntos técnicos e de aquiescência são identificados mais cedo.
• Custo com implementação de novas regras e padrões internos é reduzido porque são controlados em um ambiente de trabalho eficiente.
• Redução de riscos de longo prazo e de custos devido a fragmentação de padrões porque o gerenciamento tem visibilidade do grau de cumprimento.

Riscos e custos com ‘long-term’ são reduzidos devido a fragmentação de padrões porque o gerenciamento tem visibilidade da diminuição de aquiescência.

• O desempenho da TI é melhor medido enquanto atua como administrador dos sistemas de negócio, o que é particularmente importante para contratos de terceirização governamentais.

Matthew D. Laudato sugeriu que embora governança frequentemente seja um trabalho difícil de aceitar, os benefícios oferecidos à TI precisam ser contabilizados pelo VP ou CIO. Ele recomenda que Governança deve fazer parte do processo Ágil. De acordo com ele,

Faz sentido adicionar um passo ao processo de ‘Sprint Review Time’ (a avalização feita no final de cada sprint) para formalmente documentar o progresso do projeto de forma que seja útil para o resto do negócio. Neste relatório devem estar incluídos, pelo menos, quais características foram completadas, seus custos, seus planos de contingência e que percentual de requerimentos conhecidos foram satisfeitos até aquela data.

Takeuchi e Nonaka da Toyota, tiveram a seguinte opinião sobre governança

Apesar das equipes agirem por conta própria na maioria das vezes, não são incontroláveis. Gerenciamento estabelece pontos de checagem suficientes para prevenir instabilidade, ambiguidade e tensão que podem tornar em caos. Ao mesmo tempo, o gerenciameno evita o tipo de controle rígido que prejudica a criatividade e espontaneidade. Ao invés disso, a ênfase é em “auto-controle”, “controle através de pressão de pares” e “controle por amor

Segundo Ross Pettit, Agovernança Ágil veio pra responder duas questões:

• Estamos agregando valor ao nosso dinheiro?
• As soluções entregues satisfazem todas as expectativas?

A primeira questão trata sobre a efetividade do dinheiro gasto tentando responder às questões, com fatos, sobre medições com amplo escopo, trabalho completo, gastos totais e  verificando tendências com precisão. A segunda questão é sobre a capacidade que a solução tem em acompanhar a variedade de políticas corporativas, incluindo segurança, arquitetura, qualidade, riscos e etc. Ross sugeriu que uma boa governana deve conduzir a:

Uma redução de "surpresas," melhora na confiança e credibilidade, execução alinhada com a estragéia – faz a TI gastar menos esforços com seus próprios problemas e, consequentemente, ser mais responsiva ao negócio.

Desse modo, existem justificativas suficientes sobre a importância da governança e sobre os benefícios que ela pode trazer ao projeto, porém, qual é a melhor maneira pra introduzí-la em um projeto Ágil?

Ross sugere a seguinte abordagem,

• Se governança deve servir como facilitador para agilidade, não pode ser um fardo para as operações diárias. Pra resolver isso, devem existir maneiras consistentes e não-burocráticas de coletar dados pela organização.
• Para avaliar a plenitude da solução, a governança de TI deve manter participação ativa no departamento inteiro, incluindo segurança, infraestrutura, arquitetura, controle de riscos, gerenciamento de negócios, o PMO e etc. Subsequentemente, deve existir participação de todas as disciplinas de TI.
• Governança de TI não poder se transformar num esoterismo religioso, tão pouco transformar-se em "parte da decoração." Nós precisamos ser capazes de comunicar com todos os stakeholders usando a "língua deles," e mais importante, utilizar termos empresariais ao dirigir-se aos negócios.

Dean Leffingwell sugeriu a seguinte abordagem ao definir um processo de governança leve. Segundo ele, o modelo de governança deve.

• Criar diretrizes Ágeis definindo o quê a Metodologia Ágil significa para a empresa e definir, de modo inequívoco, mandatos em termos de testes unitários, retrospectiva, standups, etc.
• Possuir de 3-5 páginas.
• Recomendar mas não determinar.

Desta maneira governança Ágil serve como uma perfeita cola entre gerenciamento e TI. A chave é não exagerar até matar a criatividade e o entusiasmo do ambiente Ágil.

Fonte: InfoQ

Uma das características comuns aos profissionais que hoje assumem decisões estratégicas na corporação é a habilidade de aprender rápido e se adaptar a novas situações

Gordon Watt e Brinley Platts, para CIO UK*
Publicada em 25 de fevereiro de 2009 às 16h04

A liderança de TI vem recebendo a atenção que deveria? Os CIOs têm sido pressionados a funcionar como profissionais cada vez mais influentes para o sucesso dos negócios. Mas isso nem sempre é reconhecido dentro das corporações. Ao contrário, estudos realizados pela Capgemini e a empresa de recrutamento Harvey Nash apontam que os líderes de TI vêm perdendo o poder de influência nas organizações.

Como os CIOs podem reverter essa situação? Movidos por esse paradoxo, nós fomos mais a fundo nos resultados de uma pesquisa intitulada “Expandindo o Mandato do CIO”, criada por Michael Earl e Philip Vivien. Os especialistas identificaram os desafios dos novos líderes de TI e definiram as características desse profissional no futuro. Boa parte das mudanças está relacionada ao perfil dos profissionais, os quais devem deixar de ter um foco predominantemente em tecnologia para contribuir com uma transformação das organizações. E, a partir desses dados, ouvimos alguns dos novos líderes de TI para definir como isso funciona, na prática.

No levantamento, trabalhamos com CIOs que expandiram suas atribuições e descobrimos dois interessantes e inesperados padrões: eles apresentam um leque bastante grande de atribuições em comum – a maior parte delas pouco usual para os profissionais de TI – e, além disso, todos seguem uma similar, mas atípica, carreira.

Para mostrar só um dos atributos comuns a esses executivos, entre as características dos CIOs que conseguiram ampliar seu escopo de atuação está a ousadia. Por conta disso, os profissionais estão em constante busca por novos desafios e, como reflexo direto disso, boa parte dos executivos não segue uma rota tradicional de carreira na área de TI. Assim, muitos já passaram por gerências de negócio fora de tecnologia.

Agilidade para aprender
Esse comportamento comum aos CIOs é mais do que uma extraordinária coincidência? Sim. As teorias e estudos sobre liderança apontam a inteligência emocional e a capacidade de aprender rápido como atributos essenciais ao sucesso de qualquer profissional.

No caso dos CIOs, o que salta aos olhos é a necessidade de aprender rápido. Na prática, isso significa que os profissionais precisam ser ágeis para implementar mudanças de acordo com a situação. Como Warren G. Bennis e Robert J. Thomas explicam no livro Geeks e Geezers: “A habilidade para processar novas experiências, para descobrir o que elas representam e integrar isso ao cotidiano é a assinatura que define o conhecimento dos líderes.”

E o caminho para desenvolver essa agilidade para aprender é praticando. E o espírito audacioso dos CIOs que entrevistamos favorece esse tipo de situação.

A oportunidade para desenvolver essa habilidade de aprender rápido depende de como a TI é vista na organização. Trata-se de um provedor de serviços confiáveis? Ou a TI funciona mais como um parceiro que mostra os caminhos para usar a tecnologia a favor da inovação e da transformação?

Para melhorar suas aspirações, uma mudança necessária passa pela forma de desenvolver essa agilidade de aprendizado. Nesse sentido, é necessário definir objetivos a ser alcançados, com o intuito de buscar novos desafios e testar a capacidade de liderança. Isso significa colocar a determinação e a ambição acima da experiência e do conhecimento já adquirido. O que representa ter coragem o suficiente para aceitar os desafios mais arriscados em vez de buscar o velho caminho do sucesso.

Outro fator de sucesso para o desenvolvimento dos líderes de TI é encorajar e permitir a troca de experiências com outras unidades de negócio da companhia. Finalmente, isso representa promover a Tecnologia da Informação como uma unidade com talentos que podem ser explorados para melhorar o negócio.

*Gordon Watt atuou por 15 anos como CIO de diversas companhias internacionais por 15 anos e hoje trabalha como um pesquisador independente e consultor. Já Brinley Platts atua como membro do CIOdevelopment.com e fundador do programa IMPACT para líderes

Fonte: CIO