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

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

por Rodrigo Yoshima
em 2 de Julho de 2008 para o blog Débito Técnico

Nesta semana eu e o Phillip Calçado compartilhamos uma coisa: nós lemos artigos numa revista fora do mundo de tecnologia (se é que existe isso hoje em dia) e achamos conceitos ágeis lá. Veja este post no blog gringo dele:

BigPharma Problems & Solutions: Have You Seen This Before?

Na edição brasileira da Harvard Business Review de junho/2008, Tim Brown escreveu um artigo apresentando o “Design Thinking”. Ao ler o artigo ví que Design Thinking é recheado de conceitos ágeis. Muito recheado! É praticamente uma abordagem ágil para a inovação em todas as esferas empresariais.

A abordagem de [Thomas] Edison é um dos primeiros exemplos do que hoje se chama design thinking – metodologia que imbui todo o espectro de atividades de inovação de um etos de concepção centrado no homem… Edison não era um cientista especializado num campo apenas – era, antes, um generalista com aguçado tino comercial. Em seu laboratório em Menlo Park, New Jersey, Edison se cercava de gente com talento para improviso e experimentação. Na prática, derrubou o mito do “inventor genial e solitário” ao criar uma abordagem de equipe à inovação.

Preste atenção nesta parte:

A idéia era justamente não corroborar hipóteses preconcebidas – mas ajudar o investigador a aprender algo a cada lance iterativo.

(grifo meu)

É interessante ver como pragmatismos estão florescendo dentro no mundo empresarial das pessoas espertas e como mais e mais rigidez e controle estão obscurecendo a vida das empresas burras. Design Thinking é uma perspectiva humana para a solução dos problemas. É o envolvimento de cada indivíduo, de cada mente, na busca de uma solução viável e criativa. Isso envolve empatia, raciocínio integrativo, otimismo, experimentação e colaboração. O Design Thinking é a dinâmica de um processo colaborativo de inovação. Relatando um caso de solução para um problema de um grupo de enfermagem da Kaiser (não é a fábrica de cervejas), Tim Brown acrescenta o que colaborou para a solução:

…as equipes de inovação exploraram soluções potenciais por meio de brainstorming e prototipagem rápida… Um teste com protótipos não precisa ser complexo e nem caro. Um protótipo deve consumir apenas a quantidade de tempo, esforço e investimento necessária à geração de um feedback útil a evolução da idéia – nada mais. Quanto mais “acabado” parecer um protótipo, menor a probabilidade de que seus criadores ouçam o feedback – e se valham dele.

Olha que engraçado! A HBR, uma revista tradicionalíssima, está dizendo que meus protótipos visuais estão certos! Quando aquele gerentinho metido torcer o nariz poderei falar: “- Você leu o artigo sobre Design Thinking na Harvard Business Review?”

…o que ocorreu na equipe de enfermagem da Kaiser não foi um avanço súbito e revolucionário, nem o estalo de um gênio – foi fruto do trabalho árduo realçado por um processo criativo de descoberta centrado no ser humano, seguido de ciclos iterativos de testes com protótipos e aperfeiçoamento.

Esta é a parte que mais gostei (comentários meus entre parênteses):

O melhor jeito de descrever o processo de design é metaforicamente (Beck?) – como um sistema de espaços, em vez de uma série predefinida de passos ordenados (Gantt?). Esses espaços delimitam tipos distintos de atividades correlatas que, juntas, formam o continuum da inovação. O Design Thinking pode parecer caótico para um marinheiro de primeira viagem (seu chefe?). Mas, no decorrer de um projeto, os participantes acabam entendendo que o processo faz sentido e produz resultados (um release?), ainda que sua arquitetura seja distinta do processo linear fundado em marcos intermediários característico de outras atividades empresariais.

Este parágrafo no artigo é uma das melhores definições que já ví a respeito da natureza de um processo de design. Desenvolver software é 100% design. Isso foi tão contundente pra mim que contactei o Tim Brown – o autor do artigo – perguntando se ele tinha sido influenciado pelas práticas do Agile Software Development. Veja a resposta dele entre outras coisas:

From: Tim Brown
Date: 2008/7/2
Subject: Re: Article about Design Thinking on Harvard Business Review
To: Rodrigo Yoshima

Hi Rodrigo,
It doesn’t surprise me to hear that software design shares many of the same characteristics as design thinking. You are right that there has not been a lot of interaction between these two communities other than through the computer human interaction folks where I think a lot of these same issues have been discussed.

Thanks for making the link.

Best regards
Tim

On 6/30/08 5:53 PM, “Rodrigo Yoshima” wrote:

> Hi Tim,
> I’ve just read your article about Design Thinking and I’m
> just very very curious about how you put Design Thinking
> pratices together. Design Thinking concepts are very close
> to Agile Software Development Practices. Have you ever
> heard about it? Take a look at www.agilemanifesto.org.
>
> I see that the values of the Agile Manifesto is our flag of
> Design Thinking on Software Development. 100% of the
> software construction is design. Agile Practices are:
>
> – Human centered / Focused on Team Work
> – Iterative / Cyclical / Feed-back based
> – Use a lot of Prototypes / Sketches
> – Empirical
>
> I guess that you can really benefit from the contents
> that our community have being studying for the last 20 years.
>
> Cheers.
>
> Rodrigo Yoshima
> ASPERCOM / MundoJava

Sim! Mais uma vez provamos que o futuro do mundo empresarial é empírico e pragmático. Mais uma vez está provado que rigidez e processos inflexíveis impedem a inovação. Quem só tem martelo na mão só vê pregos pela frente… e sai martelando tudo.

Fonte: Débito Técnico

Bruno Ferrari, de INFO Online
27/01/2009

SÃO PAULO – A empresa de consultoria e treinamento Brunise iniciou cursos e exames de certificação ITIL V3 Foundation e ITIL V3 Foundation Bridge em português.

A Brunise acaba de ser homologada pela APMG- US, órgão oficial responsável pela disseminação do ITIL no mundo. Segundo Luis Mathô, responsável pelo desenvolvimento de negócios das Américas na APMG- US, o órgão tem reparado no grande interesse por parte de profissionais e empresas que buscam uma maneira de aplicar boas práticas de TI.

Segundo a Brunise, não existem pré-requisitos para a realização dos exames, salvo a comprovação da certificação ITIL V2 Foundation para a certificação do ITIL V3 Foundation Bridge. Mas a recomendação é que o candidato passe por um treinamento antes de realizar os exames, que podem ser feitos online ou em papel.

Receberão o certificado e o pin emitidos pela APMG-US, os candidatos que obtiverem pelo menos 65% de acertos no exame. Para mais informações, consulte o site da Brunise.

Fonte: Info Corporate

De acordo com pesquisa realizada pela revista CIO do Reino Unido, em parceria com empresa de recrutamento Harvey Nash, embora os executivos tenham noção da importância de se construir e manter uma marca pessoal positiva, muitos deles estão falhando ao desenvolvê-la

Mark Chillingworth, CIO UK
Publicada em 19 de janeiro de 2009 às 16h43

Cerca de dois terços dos CIOs e executivos de TI julgam que ter uma imagem pessoal forte é muito importante para a área de tecnologia de suas empresas. Este é um dos principais resultados de uma pesquisa realizada pela revista CIO do Reino Unido, em parceria com a Harvey Nash – empresa de recrutamento de profissionais e terceirização de TI.

Pelo documento, a imagem de um profissional é o que seus colegas pensam no exato momento em que ouvem seu nome. Segundo o levantamento, embora os CIOs tenham noção da importância de se construir e manter uma imagem pessoal positiva, muitos deles estão falhando ao desenvolvê-la.

Aproximadamente 65% dos executivos que participaram do estudo afirmaram que se valem de movimentos físicos (entrar e sair de uma sala, por exemplo) para serem notados na companhia.

Entre os quesitos apontados como métricas para saber se sua imagem pessoal é valorizada, a maioria dos CIOs respondeu que avalia sua popularidade pela influência que possui com o board da companhia e pela capacidade de fazer com que sua equipe se identifique com ele.

Para elaboração da pesquisa, a revista CIO e a Harvey Nash ouviram mil CIOs e diretores de TI de empresas que, somadas, movimentam orçamentos de TI de 14,6 milhões de dólares ao ano.

Fonte: CIO

Mesmo com os terabytes de informações armazenadas nas empresas, ainda faltam ferramentas eficientes para gestão desses dados

Thomas Wailgum , CIO
Publicada em 13 de janeiro de 2009 às 14h59

A intuição tem influenciado as decisões de pessoas e de negócios há séculos. E, aparentemente, essa capacidade ainda sobrevive como uma ferramenta de negócios dentro dos ambientes corporativos.

De acordo com um recente levantamento da Accenture, quase metade (40%) dos principais decisões corporativas são baseadas na intuição dos executivos. A consultoria ouviu mais de 250 profissionais, em julho de 2008, a respeito do uso e do investimento que as organizações realizam em análise de negócios para continuarem competitivas.

Dos entrevistados que disseram que suas companhias tomam decisões baseadas mais em julgamento do que em análise de negócios, 61% deles afirmaram que não têm fontes de dados disponíveis e só cerca de 55% disseram que suas decisões mesclam fatores qualitativos e subjetivos. Além disso, outros 23% dos respondentes informaram que a quantidade insuficiente de conhecimento dos empregados representa uma barreira para a organização. E outros 36% relataram que as empresas encaram uma falta de talentos com capacidade analítica.

O fato de 61% dos entrevistados dizerem que não têm dados disponíveis quando precisam tomar decisões é assustador, tendo em vista os terabytes de informações internas e de clientes armazenadas na maior parte das organizações hoje em dia. E também, claro, representa um indicativo do péssimo estado da gestão de dados dentro das empresas.

O levantamento da Accenture aponta ainda que 39% dos entrevistados informarm que a pouca capacidade da TI representa o maior desafio e outros 27% afirmaram que existe uma falta de habilidade para compartilhar informações por toda a organização..

Assim, as ferramentas de business intelligence, análise de resultados e previsões começam a ser convidadas a participar da festa. Para surpresa da área de TI!

Um recente levantamento do Aberdeen Group levantou porque as companhias têm dificuldade em conseguir informações confiáveis e como as ferramentas de BI e análise ajudam nesse cenário. “Muitas organizações gastam meses e demandam custos significativos para obter os relatórios e as possibilidades de análise que o BI promete. E só para descobrir que diferentes versões da verdade existem sem qualquer caminho para definir qual é a realidade ou formas de aprimorar as informações”, enfatiza David Hatch.

A principal descoberta do estudo da Aberdeen foi totalmente previsível, uma vez que 36% dos entrevistados disse que tem interesse em transformar as decisões baseadas em instinto para as definidas por fatos reais.

Para confirmar isso, 72% dos executivos ouvidos pela Accenture disseram que estão trabalhando para melhorar suas ferramentas de análise de negócios e de BI. Isso porque, dois terços desses profissionais reconhecem que seus instrumentos para tomar decisões são falhos e querem melhorar isso.

Fonte: CIO