Os CIOs precisam equilibrar conhecimento técnico e de negócios, com uma boa capacidade de comunicação, gestão de pessoas e um perfil inovador

CIO Brasil
Publicada em 20 de novembro de 2009 às 08h00

Quanto mais a empresa considera a TI como uma área estratégica, menos valoriza competências técnicas para o CIO. Isso não significa, no entanto, que o gestor da área de tecnologia da informação pode se dar ao luxo de deixar de lado os conhecimentos específicos da sua área.

Assim como os super-heróis das histórias em quadrinho, o CIO precisa ter várias identidades. No momento em que ele está sentado em frente ao board, deve assumir uma postura e um discurso totalmente orientados aos negócios. Já quando encontra-se na mesa de negociação com fornecedores ou conversa sobre o escopo de um determinado projeto com sua equipe, tem de resgatar a bagagem de conhecimentos técnicos.

Essa multiplicidade de visões também se aplica às competências exigidas dos CIOs. Isso porque, além da identidade técnica e de negócios, os profissionais são cobrados por sua capacidade de atender às demandas das diversas áreas da companhia e por gerenciar a equipe de TI e os fornecedores. Além disso, eles precisam encontrar tempo para idealizar produtos e serviços inovadores.

Equilibrar essas diferentes tarefas representa um fator crucial para o sucesso dos gestores de TI. Prova disso é que muitos CIOs foram demitidos ou deixaram a companhia no período de crise por conta da dificuldade em se adequar às novas expectativas das organizações, de acordo com a vice-presidente da consultoria Gartner para América Latina, Ione Coco.

A seguir, seguem as competências essenciais para os CIOs, na visão de especialistas e de profissionais que atuam no setor:

Conhecimento do negócio – Por mais interessantes que as tecnologias pareçam para a equipe de TI, os argumentos técnicos não podem ser utilizados para justificar um projeto para a diretoria e as demais áreas da organização. Assim, os CIOs devem conhecer a fundo o negócio da companhia para entender como as iniciativas da sua área estão alinhadas aos objetivos da organização e quais os resultados práticos esperados.

“Um projeto de TI é um investimento como qualquer outro da empresa e, em muitas ocasiões, pode inclusive concorrer com as demais áreas”, afirma o gerente de sistemas da Basf no Brasil, Ricardo Crepaldi. “Uma reestruturação de parque tecnológico, por exemplo, necessita estar alinhada à necessidade de crescimento da empresa. Não faz mais sentido trocar só por trocar.”, acrescenta o executivo.

Capacidade de comunicação – No dia-a-dia das organizações, boa parte das atividades de TI passa despercebida pelos funcionários da companhia. Na realidade, o CIO e a sua equipe só são lembrados em situações negativas, como quando o sistema cai ou o computador para de funcionar. Com isso, a imagem do trabalho da área de tecnologia da informação fica prejudicada dentro das organizações. E o pior, essa percepção chega até o board da companhia, o que reflete diretamente no humor de investimentos em novos projetos.

O CIO que pretende reverter essa situação precisa estar preparado a estruturar uma melhor comunicação de sua área com todos os stackeholders da organização. Para tanto, precisa investir em ferramentas que o ajudem a divulgar as iniciativas de TI a toda a companhia, bem como criar um canal para que os diversos usuários consigam expressar opiniões sobre produtos e serviços oferecidos pela equipe de tecnologia.

Gestão de pessoas – Os resultados da área de TI também estão diretamente relacionados à capacidade que o CIO tem para recrutar, reter e desenvolver seus colaboradores. Assim, a sócia da consultoria brasileira Career Center – especializada em gestão estratégica e recolocação profissional –, Karin Parodi, aconselha que esses profissionais estejam atentos à gestão de pessoas e não deleguem essa função apenas para a área de recursos humanos.

Essa capacidade de gestão e motivação das equipes é essencial a qualquer profissional em posição de liderança, mas tende a ser ainda mais crítica na TI, uma vez que trata-se de um setor no qual faltam pessoas capacitadas e, portanto, a retenção de talentos é essencial.

Perfil inovador – Quando buscam um profissional para ocupar a posição de CIO, as empresas buscam pessoas com postura voltada à inovação, de acordo com a diretora de TI e telecom da consultoria brasileira de recrutamento de executivos Fesa, Ana Luiza Loureiro Segall.

“Na prática, isso seria, por exemplo, representado por um CIO que, antenado aos lançamentos do mercado no qual atua, percebe uma nova maneira de se relacionar com os clientes e leva essa sugestão à área de marketing”, exemplifica Ana Luiza.

Conhecimento técnico – Um levantamento realizado pela consultoria norte-americana Diamond Management & Technology apontou que um dos pecados que o CIO comete é distanciar-se do conhecimento técnico. De acordo com o estudo, sem essa habilidade, o profissional não consegue saber como o departamento de TI pode contribuir com as demais áreas da organização e não consegue liderar sua própria equipe.

Na mesma linha, uma pesquisa realizada pelo diretor de tecnologia da informação da Halliburton no Brasil, Etienne Vreus, com 111 gestores de TI de empresas brasileiras, aponta que o conhecimento técnico é uma das sete competências essenciais ao CIO atualmente.

Fonte: CIO

Um francês desempregado à procura de trabalho como software developer – Alexandre Gueniot, então com 23 anos – ficou conhecido por ter criado um currículo em flash engraçado e original.

Por conta deste currículo, e no espaço de apenas duas semanas, recebeu 26 ofertas de emprego, 183 emails enviados por fãs e 35 mil acessos à sua página. Para resumir uma longa e feliz história, Gueniot acabou sendo contratado pela Microsoft.

Quanto ao currículo que originou tudo isto, no link: http://web.me.com/agueniot/Data/Flash/cven.html

Havia esquecido disso. Meu amigo Paulo Barros me lembrou que havia mandado isso em 2004.

por Julio Sergio em 19 de Novembro de 2009 à 1:06 pm

O furacão já passou e muita gente começa a tirar da gaveta os planos de trocar de emprego. Mas será que o cenário já é propício para mudar? Se você pensa sair em campo com todas as armas, muito cuidado! A tão falada retomada da economia ainda não aconteceu de fato e as perspectivas continuam obscuras. Pé no chão é fundamental!

Digo isso porque vejo acontecer um fenômeno, que chamo de “pretensão ilusória”. Em cena, dois protagonistas do mercado, ávidos por tentar tirar proveito do pós-crise a todo custo: empregado e empregador. De um lado está o profissional que acredita assistir agora a novas oportunidades e uma remuneração mais atraente; de outro as empresas apostando que encontrarão talentos por salários mais baixos.

Entenderam por que falo de “pretensão ilusória”? As companhias continuam enfrentando o grande problema do século, a escassez de talentos, mas infelizmente mantêm a postura de não querer pagar pelo passe desses talentos. Enquanto isso, muitos profissionais sonham alto e apostam que o cenário do passado vai voltar.

Os tempos são outros e os rumos das companhias terão como norte a questão do custo. A ordem é fazer mais com menos. Alguém duvida? Tenho visto muitas empresas focarem suas contratações em jovens no início de carreira para formá-los como alternativa à falta de orçamento.

Um grande erro, é bem verdade. A curva de aprendizado desses jovens acaba refletindo em um custo maior do que se a empresa optasse por um profissional pronto e preparado para já dar resultados. Não tenho dúvidas que para determinadas posições, não dá para esperar que o profissional seja treinado até ficar no ponto ideal.

Realidade, no entanto, serve de alerta para os profissionais que pretendem se mexer em busca de um novo emprego. Oportunidades virão? Claro que sim. Mas o pano de fundo é bem outro. Até mesmo as empresas do mercado de TI que seguem enfrentando o problema da falta de gente qualificada vem optando por contratar na base da pirâmide.

Se o caminho a trilhar é certo ou errado, não importa. É uma mudança importante para o profissional que está aí no mercado querendo alçar novos vôos. Algumas empresas estão reduzindo salários ou contratando para a mesma função gente mais barata. Então, todo cuidado é pouco e trace um plano no médio prazo. Faça uma análise clara do que a nova empresa pode oferecer em termos de plano de carreira e salário. Só arrisque se perceber que nada mais pode ser oferecido onde você está.

Fonte: HSM

A gigante das buscas está mesmo querendo se infiltrar em novas áreas e está lançando uma nova linguagem de programação chamada Go.

Esta linguagem visa combinar velocidade e manutenção no desenvolvimento (como o Python) com a leveza e agilidade da linguagem compilada C ou C++.

Go irá suportar multi processadores com suporte também a vários servidores.

A empresa está interessada no desenvolvimento desta nova linguagem de programação devido às atuais linguagens não estarem satisfazendo os engenheiros da empresa, que estão vendo os computadores ficarem cada vez mais rápido e as tradicionais linguagens e seus recursos não estarem acompanhando esta evolução.

O Google diz que irá tirar o máximo proveito desta nova linguagem adaptando para os novos hardwares existentes e futuros, simplificando a análise e sintaxe de programação além de evitar as corriqueiras sobrecargas presentes em linguagens como C e seus arquivos de bibliotecas.

Você poderá ver mais sobre o assunto, sabendo como instalar o compilador, os pacotes disponíveis, tutoriais, documentações e outras explicações no próprio site do Go, aqui: http://golang.org/

Fonte: Dicas para computador

Postado por Phillip Calçado
para o Blog Fragmental em 14/11/2009

Neste curto período no Brasil eu tive a oportunidade de conversar com muita gente, tanto do Rio quanto de outros locais que vieram para workshops ou eventos. Como não é novidade para ninguém o Brasil está cada vez adotando mais metodologias menos burras -ou “ágeis” se você preferir.

E algumas coisas se repetem constantemente. Uma delas é um problema comum em projetos e clientes onde eu já estive mas mostra-se de maneira curiosamente popular no Brasil. É o problema da quebra de paredes.

Mas quebrar paredes não era bom? Sim, é! Quebre as barreiras impostas por processos e ferramentas inúteis. Quebre as paredes que não deixam desenvolvedor conversar com cliente, quebre as barreiras que não deixam um time ser multifuncional!

Só cuidado para não quebrar as barreiras que protegem o time.

Scrum é o sabor favorito do Brasil e creio que a forma como ele é ensinado ajuda a causar problemas. O sujeito que assume o papel do Scrum Máster Jedi lê na sua apostilinha que seu papel é remover impedimentos. O cara não sabe direito o que é o tal do impedimento mas por algum motivo ele acha que é basicamente ser uma polícia do processo. A grande maioria das pessoas que eu conheço que têm “Scrum Master” como cargo têm como única tarefa ter certeza que todos estão nas reuniões certinhas e que o Scrum está sendo seguido conforme o jefe mandou.

E aí vem a ilusão de que o processo por si só vai resolver os problemas. Vamos colocar todos os desenvolvedores numa mesa tão pequena que não caiba um mousepad, vamos deixar o cliente ligar para o desenvolvedor cada uma das 232 vezes que ele muda de idéia durante o dia e a mágica dos times auto-gerenciáveis, auto-motivados e auto-limpantes vai fazer tudo funcionar.

Não vai.

Times auto-gerenciáveis evitam desperdício. São ótimos. Cliente poder falar com desenvolvedor evita desperdício. É ótimo. Tudo é maravilhoso, exceto pelo fato que as pessoas ainda são as mesmas.

Uma pessoa que fazia de tudo para destruir o seu projeto não vai melhorar só porque agora faz parte do time. Um cliente que é extremamente indeciso vai perturbar tanto o desenvolvedor que ele não vai conseguir escrever uma linha de código. Um sujeitinho metido a comandante de tropa nazista não vai melhorar porque agora não chamam ele de gerente mas de Product Owner.

Minha palestra no Caelum Day semana passada –que ainda não está disponível mas estará em breve- foi sobre reduzir o tamanho dos ciclos de feedback durante o desenvolvimento. Este é o ciclo do desenvolvedor que desperdiça 5 minutos esperando um servidor de aplicações subir para ver se algo funciona ou não. Estes ciclos técnicos são relativamente simples de resolver, existem técnicas e tecnologias para isso.

Mas trabalhar escrevendo código é apenas uns 50% do que eu faço hoje em dia. Eu também tenho que gerenciar escopo, tempo, recursos e pessoas durante um projeto. A parte do desenvolvimento de software é bem mais fácil –é o que eu gosto de fazer- mas esta outra parte sempre me dá mais trabalho porque eu não me interesso em aprender mais do que o necessário sobre isto.

E uma das coisas que eu aprendi aos trancos e barrancos e hoje em dia considero parte do necessário para um Iteration Manager, Scrum Master ou qualquer coisa que você prefira é que os tais dos ciclos de feedback existem também for a do aspecto técnico. Como gerente de iteração você precisa zelar para que seu time consiga produzir sem problemas. Você não os manda fazer as coisas –eles se gerenciam- mas seja lá o que eles resolvam fazer você precisa ter certeza de que não existe nada roubando tempo deles.

E, infelizmente, ao contrário dos ciclos técnicos eu não consigo listar técnicas e padrões para reduzir os ciclos de gerência de projeto. Minha sugestão inicial é que é melhor um time sem gerente de iteração do que um time com um gerente ruim. Se você tem um pequeno ditadorzinho como desenvolvedor movê-lo para Scrum Master só vai fazer tudo piorar.

A segunda é cuidado se implantar o comunismo na sua empresa. Tornar as pessoas “iguais” vai resolver alguns deles mas vai criar novos. Esta coisa de “todos juntos vamos de mãos dadas, cantando a canção e entregando valor pra missão” é balela. Você sempre vai ter o cliente indeciso, o Scrum Master ditador, o desenvolvedor que não produz nada… métodos ágeis vão deixar os problemas aparentes mas alguém tem que agir, eles não se resolvem por mágica.

Um exemplo relativamente recente de como você precisa prestar atenção aos ciclos foi, para mim, o meu último release do Globo Vídeos dentro da Globo.com. O Vídeos foi o primeiro time de projeto ágil na empresa –não foi o primeiro usando Scrum porque nós nunca usamos exatamente Scrum- e tínhamos um prazo ridículo e uma equipe pequena para entregar um dos sites mais importantes da empresa.

Olhando para o nosso modo de desenvolver eu percebi que não havia condições. Mesmo com todo o aparato ágil que estávamos criando a quantidade ridícula de reuniões e passos burocráticos que um desenvolvedor realizava no seu dia-a-dia iria consumir uns bons 30% do tempo de cada um. Minha proposta para o time foi simples: “nós tínhamos 6 desenvolvedores. A partir de agora nós temos 5. Eu vou parar de escrever código e cuidar apenas da burocracia.”

Para alguém que ama escrever software isso foi uma decisão bem complicada –ok, eu saia tarde todos os dias só para ter alguma chance de escrever umas linhas de código- mas foi a melhor coisa que eu fiz. Eu passei a ir a todas as reuniões –onde nada de útil era discutido-, escrever documentação e preencher formulários, resolver bug da versão antiga, acompanhar os testes requeridos para alguma coisa entrar no ar e todas estas atividades de valor zero para o projeto.

Este era um projeto onde o cliente mudava de idéia o tempo todo e eu tive que isolar o cliente da equipe e atuar como proxy. O cliente só via o trabalho semanalmente, basicamente. E foi entregue no prazo e continua no ar até o momento.

E esta foi só a primeira vez que tive que fazer isso. Depois desta eu não acho que houve um projeto sequer onde eu não tenha que ter feito algo semelhante, seja preenchendo formulários para deixar o time livre para escrever código ou gastando 30% do meu tempo apenas para ter certeza que o GERENTE DE PROJETO (em maiúsculas porque era assim que ele se apresentava) estava feliz e recebendo todos os dados que ele achava interessantíssimos.

É a parte mais chata do meu trabalho, mas negligenciar esta parte é uma das grandes causas de problemas em adoções de métodos ágeis. Existe toda uma engenharia de processo que precisa ser feita. Ao usar métodos ágeis não vai aparecer nenhum duende mágico para fazê-la para você. Achar que você pode ter um Scrum Master que não faz esta engenharia só porque “times se auto-gerenciam” é muita ingenuidade. Ou burrice.

Fonte: Blog Fragmental

Postado por Abel Avram para o InfoQ, traduzido por Yan Borowski em 12 Nov 2009 09:43 AM

Fabrice Marguerie, um arquiteto de software e consultor, escreveu o artigo Como detectar e evitar vazamentos de memória e recursos de aplicações. NET, publicado no MSDN. O artigo   explica como vazamentos de memória e recursos podem acontecer durante a programação para. NET e como evitá-los.

Linguagens como C #, fazendo a limpeza da casa através de um coletor de lixo de memória, não tem vazamentos de memória em seu sentido original quando perde um programa de acesso completo a um local de memória. Segundo Fabrice, vazamentos de memória ocorrem quando uma localização de memória já não é necessária, mas o programa continua a manter pelo menos uma referência a ele. O coletor de lixo iria reclamar que a memória se era inacessível, mas a memória se torna um vazamento, desde que ela é referenciada pelo programa e não é mais utilizada.

Fabrice também enumera uma série de recursos de sistema operacional que podem ser sujeitos a vazamentos similares:

• O sistema utiliza objetos do usuário para suportar o controle da janela. Eles incluem: aceleradores de tabela, Carets, Cursores, Hooks, ícones, menus e janelas.
• Suporte a Objetos GDI gráficos: Bitmaps, Brushes, Contextos de dispositivo (DC), Fontes, DCs de memória, Metafiles, paletas, canetas, Regiões, etc
• Objetos do Kernel de apoio para gerenciamento de memória , execução do processo e inter-processo de comunicação (IPC): arquivos, processos, threads, semáforos, temporizadores, tokens de acesso, Sockets, etc

Estes recursos são limitados, as chaves do Registro GDIProcessHandleQuota e USERProcessHandleQuota contendo o número máximo de objetos de usuário e GDI que um processo pode usar. Os valores padrão são 10.000 para estas alças. Embora este número seja suficiente para a maioria das aplicações, a utilização de muitas delas fará com que o sistema atinja outro limite de 65.536 alças para uma sessão do Windows. Fabrice relatou que bateu este limite muito mais cedo, em cerca de 11.000.Sua conclusão é que os recursos de sistemas devem ser cuidadosamente utilizados e liberados quando não mais necessários.

Fabrice enumera as seguintes causas de vazamentos, explicando como funciona cada um deles:

• Usando referências estáticas
• Evento com a falta de cancelamento – essa é considerada, pelo autor, como a fonte mais comum de vazamentos
• Evento estático com a falta de cancelamento da referência
• Não chamar o método Dispose
• Usando um método Dispose incompleto
• A utilização indevida BindingSource com Windows Forms
• Não usar a chamada Remove no WorkItem/CAB

O autor continua o artigo, oferecendo aconselhamento sobre como evitar vazamentos:

• O criador ou proprietário de um objeto, e não o seu utilizador, é responsável pelo escoamento
• Sempre remova a referência de um Event Listener quando a mesma não é mais necessária, isso poderia ser feito com o Dispose() para a segurança
• Quando um objeto não gera mais eventos, todos os seus Listeners devem ser removidos através da atribuição de "null" para o objeto
• Quando uma referência é usada por um Model e pela sua View, é recomendado passar   um clone   do objeto referenciado   para a View,   evitaando assim que se perca quem está usando o que
• Chamadas aos recursos do sistema devem ser colocadas em blocos com "using" que forçam automaticamente uma chamada Dispose, ao sair do bloco

Fabrice conclui pela introdução de uma série de ferramentas úteis para lidar com objetos e vazamentos: GDILeaks (EXE), dotTrace, .NET Memory Profiler, SOS.dll, WinDbg.

Fonte: InfoQ

Para divulgar seus cursos, o Bruno Avila que mantém um blog muito bom, o Avante!, que reúne sites e dicas bem interessantes para web designers, criou vídeos engraçados que acabaram se tornando virais muito bons.

Seguem dois vídeos:

Desabafo de um Desenvolvedor Web

O desabafo de um Web Designer

O site dos cursos é: http://cursos.brunoavila.com.br/

Apresentação sobre o Google Wave, no segundo dia do Google I/O 2009, em São Francisco, na Califórnia. O novo produto open-source, será uma ferramenta para comunicação e colaboração online, onde o principal objetivo da mesma será unir email, mensagens instantâneas e todo tipo de mídia em uma arquitetura flexível cheia de funcionalidades.

O projeto vem sendo construido desde 2004 pelos irmãos Lars e Jens Rasmussen (criadores do Google Maps) em conjunto com Stephanie Hannon (todos funcionários do Google na Austrália). Não, não foram 5 anos de trabalho. O Wave ficou parado por algum tempo e, em 2007, voltou a ser construido a todo gás. Segundo Lars, podemos dizer que o Wave “é como seria o email, se ele tivesse sido lançado hoje”.

Confira abaixo a apresentação do Google Wave na conferência Google I/O 2009:

Jeff Sutherland, um dos criadores do Scrum, nesse vídeo cobre alguns tópicos relativos a auto-organização dos times Scrum.

Palestra realizada no Google Tech Talk, em 4 de Setembro de 2008.

Rede de varejo adotou solução do Google e planeja, aos poucos, migrar mais soluções para o conceito de cloud computing

por Felipe Dreher | InformationWeek Brasil
em 13 de outubro de 2009

Em fevereiro de 2009, a rede Lojas Renner começou a migrar aplicações para cloud computing. “Temos algumas soluções já funcionando e outras em piloto”, revela Leandro Fachin Balbinot, diretor de TI da rede de varejo, listando como exemplo do que roda em nuvem a ferramenta de controle de projetos corporativos e alguns portais com para compartilhamento interno de informações.

A estratégia de computação em nuvem da companhia nasceu em novembro do ano anterior com a identificação da necessidade de criar um portal de colaboração. Os três meses seguintes foram dedicados à aprovação das iniciativas e definição da arquitetura a ser utilizada.

A avaliação do conceito considerou parâmetros que passaram por escalabilidade e flexibilidade da solução, custo por licença, velocidade de implantação e independência – uma vez que os usuários ganham certa autonomia para lidar com a tecnologia, liberando a equipe de TI para atividades mais necessárias. “A alternativa mais adaptável seria do Google”, revela Balbinot, dizendo que o projeto entrou em produção em junho, promovendo colaboração entre áreas da empresa através de canais formais e redes sociais.

Os sistemas do fornecedor rodam sobre uma camada de soluções de transações internas da corporação. “Isso permite criar fluxos de trabalho com pessoas de outras áreas da empresa, flexibilizando a automatização de processo”, conta. Aos poucos mais coisas vão para nuvem. De acordo com o executivo, e-mail, agenda e mensageria estão sendo migrados para o conceito.

O CIO revela que todo o trabalho foi conduzido de forma a garantir segurança ao acesso das informações. “Fizemos vários testes para ter certeza de que não teríamos problema”, conta, citando cuidados tomados para não colocar aplicações de missão crítica no modelo. “Todas as informações voláteis, que não precisam de armazenagem histórica ou analítica complexa, ficam na nuvem”, revela o executivo, mencionando a existência de uma conexão segura entre Google e rede interna para mover as ações de negócio. Essa conversa entre os sistemas tem como suporte um software de BPM da Oracle.

Balbinot aponta para um fato que precisa ser dimensionado e considerado na migração para cloud: a velocidade das aplicações são, geralmente, mais lentas do que os softwares que rodam dentro da empresa. Mesmo assim, o diretor menciona que o impacto do projeto na infraestrutura tecnológica das Lojas Renner foi “muito pequeno”, uma vez que o poder de processamento encontra-se nos data centers do Google.

“O que tivemos que colocar, nesse início de projeto, foi o planejamento de provisão de usuários para controle de acesso e a parte de conexão segura. Feito isso, é um trabalho muito mais de arquitetura de computacional normal para conectar o sistema de acordo com o que ele precisa”, reflete o executivo, sem mencionar quantas licenças foram adquiridas ou funcionários inseridos na aplicação.

Um dos pontos que facilitou a incursão pela nuvem da rede de varejo reside numa TI baseada em arquitetura orientada a serviços (SOA) o que, na visão do diretor, permite uma conexão capaz de viabilizar modelos tecnológicos híbridos.

O sucesso obtido na experiência até o momento faz com que as Lojas Renner planeje novas tecnologias rodando em cloud. “Tudo que não for estratégico ou crítico, olharemos para migrar num futuro próximo”, arrisca, salientando que aplicações de rotina tendem a ir mais rapidamente para a nuvem. “Pegar uma aplicação interna específica é mais delicado”, avalia o CIO, vislumbrando que as empresas que já possuem uma TI robusta montada partirão aos poucos para o modelo, enquanto empresas nascentes tendem a – em alguns casos – até descartar a hipótese de adquiriremparques próprios.

Fonte: CWConnect