Igor Musardo

Archive for the ‘Liderança’ Category

Aproveite! Pois não é sempre que temos eventos bacanas em Curitiba! Por isso, não perca a chance de fazer network e netweaving no encontro da Locaweb, eu particularmente já vou a 3 anos seguidos, e sempre é muito bacana o evento em geral, e as palestras sempre agregam conhecimento e despertam novas idéias!

Data: 06/05/2010 (Quinta-feira)
Horário: 08h00min às 17h30min
Local: Estação Embratel Convention Center (Rua Sete de Setembro, 2775)

Inscrições: R$ 50,00 Clique aqui e faça a sua inscrição.

Nos encontramos lá!

Na continuação do post De Júnior à Sênior, o Sérgio Taborda vai além da comparação entre analista júnior e sênior e aborda a “evolução” dos analistas sêniores à cargos de gerentes, o texto também leva a reflexão, por isso também está na íntegra logo abaixo.

Read the rest of this entry »

Encontrei no blog do Sérgio Taborda um excelente texto sobre as diferenças entre analistas júniores e sêniores, como concordo com sua abordagem resolví compartilhar com você. Abaixo segue o texto na íntegra.

Read the rest of this entry »

Achei muito interessante o post que o Augusto Campos do site Efetividade.Net fez sobre as razões pelas quais os gestores de TI que não são valorizados pela equipe e por isso reproduzi o post na íntegra.

Fonte: http://www.efetividade.net/2008/07/03/7-razoes-pelas-quais-o-gestor-de-ti-nao-e-valorizado-pela-sua-equipe/

A tarefa do gestor de TI é repleta de obstáculos, e obter o respeito e o apoio da equipe muitas vezes é crucial para que os objetivos sejam alcançados com menos turbulência.

É difícil definir objetivamente o que faz o gestor aproximar-se verdadeiramente da sua equipe, mas a revista CIO.com, especializada em gestão de TI, resolveu fazer a abordagem oposta: identificou um conjunto de razões pelas quais o gestor de TI das organizações (ou CIO – Chief Information Officer) deixa de ser valorizado pela sua equipe.

O artigo original está disponível em “9 Reasons Why Application Developers Think Their CIO Is Clueless“, de Mike Gualtieri (da Forrester Research), mas preparei uma versão tropicalizada com as principais razões, e suas contextualizações, que você encontra abaixo.

Se você é gestor de TI e puder contar com a colaboração de pessoas de confiança na sua equipe, pode aproveitar os 7 quesitos para fazer um rápido exercício adaptado das janelas de johari, tentando identificar como você se vê, como imagina que os outros o vêem, e como eles de fato o vêem. Se estiver se sentindo particularmente confiante, permita a eles que eles se manifestem sem se identificar!

E se você faz parte de uma equipe de TI, não ceda à tentação de parar após avaliar o seu próprio CIO. Aplique os mesmos critérios para avaliar a você mesmo, e reflita sobre como evitar estas armadilhas no seu próprio plano de carreira!

Vamos aos 7 critérios:

1. O gestor de TI é maníaco por controle: ou, mesmo sem ser maníaco, ele controla tudo assim mesmo, porque os gerentes que respondem a ele não cumprem sua função – ou não recebem a autoridade necessária. Neste caso, segundo a CIO.com, reforçar o controle não é a solução – o gestor precisa substituir os gerentes que não estão desempenhando, ou então dar a eles a autoridade necessária.
2. O gestor de TI é distante: não basta ter uma excelente equipe, ótimas ferramentas e uma infra-estrutura que funciona. O gestor de TI precisa dar o rumo, e isso não pode ser feito a partir da quadra de tênis, ou por telefonemas após uma sessão de rápida leitura de relatórios.
3. O gestor de TI se identifica demais com os fornecedores: quando o gestor veste excessivamente a camisa do fornecedor de ferramentas de desenvolvimento, bancos de dados, armazenamento, sistemas integrados, etc., ele pode se colocar em posições em que a análise técnica fica comprometida, e em que os argumentos que constam no folder trazido pelo representante da empresa favorita são aceitos como se fossem a verdade, toda a verdade e nada mais que a verdade, sem o ceticismo naturalmente aplicado a todos os demais materiais de vendas, e justificando decisões tomadas antes mesmo do processo de análise ser iniciado. Essa influência da marca predileta, como se fossem os faróis de um carro ofuscando os olhos do gestor paralisado no meio da auto-estrada, é percebida por todos.
4. O gestor de TI é um dinossauro tecnológico: ter experiência é importante, mas a tecnologia mudou bastante desde os tempos dos programas em Clipper para DOS. Mesmo quem entrou em cena mais recentemente, com o VB, Delphi e Java, precisa saber que o palco tecnológico é um alvo móvel em alta velocidade, cujos fundamentos precisam ser compreendidos pelo gestor a ponto de ele entender as metáforas e outras figuras de linguagem nas comunicações com sua equipe, e falar no mesmo idioma.
5. O gestor de TI é muito ligado às ferramentas: a equipe de técnicos respeita quem fala o idioma dela, mas o trabalho do gestor é definir o objetivo e as regras do jogo claramente, e aí sair do caminho para que a equipe possa lhe apresentar alternativas e soluções. Nenhum técnico oferece seus melhores resultados quando o gestor quer definir até mesmo como devem ser os loops, as linhas de código, a forma como o cabo deve ser conectado, o endereço IP da máquina. O gestor precisa confiar tecnicamente na sua equipe. Se ele confia mas age assim, ou ele é maníaco por controle (veja o item 1) ou há algo muito errado com a equipe.
6. O gestor de TI acredita em mudanças instantâneas: o progresso não se completa da noite para o dia, e as varinhas mágicas tendem a funcionar muito mais na ficção dos planos e relatórios do que na realidade objetiva percebida pelas pessoas da equipe – e pelos clientes.
7. O gestor de TI não sabe a diferença entre recursos e talento: e por isso age como se todos os técnicos da equipe fossem intercambiáveis, agrupando-os em novos projetos considerando especialmente a questão quantitativa, como se fosse possível afirmar que o projeto X precisa de 2 analistas e 3 programadores, e que na ausência de algum deles, quaisquer outros podem ser incorporados a qualquer tempo. Talento e espírito de equipe fazem maravilhas pelos resultados, e tratar as pessoas como recursos é uma forma segura de não desenvolver nenhum dos dois.
8. O gestor de TI está em permanente campanha para alcançar o cargo máximo da organização: alguns CIOs chegam a ser CEOs (Chief Executive Officer, o administrador de mais alto nível hierárquico), mas não é muito freqüente. Mesmo assim eles tentam, ou aspiram secretamente – e todo mundo percebe. A equipe precisa saber que o gestor está lá para ficar, que *quer* ficar lá, e que as ações dele são guiadas pela estratégia da área de TI, alinhada à da organização, e não a uma campanha secreta em prol da carreira do seu chefe.

Depois de computar sua pontuação (ou a do seu chefe), pare para refletir. Existem muitas formas, estilos e fontes de liderança, mas os líderes reconhecidos de forma duradoura compartilham entre si um atributo: ter conquistado e mantido o respeito de suas equipes.

Identifique os pontos que precisam de melhoria, e faça sua parte na busca por uma equipe melhor, com um líder à altura.

Leia também

• Liderança: saber os conceitos não é o suficiente.
• Liderança e Motivação: como liderar nos momentos difíceis
• Liderança e motivação: 7 dicas sobre como NÃO motivar uma equipe
• Liderança e motivação: quer ser levado mais a sério?
• Liderança: Aprenda a ser um bom ouvinte
• Política do escritório: como sobreviver – e vencer
• Como liderar seu chefe – a dica de Stephen Covey
• Os papas da qualidade

Fonte: http://blpsilva.wordpress.com/2008/06/06/gestao-de-conhecimento-do-time/

Eu tenho pensado um pouco sobre isso nos últimos tempos, então decidi falar aqui no blog porque possivelmente muitas pessoas têm questionamentos semelhantes.

Inicialmente vou contextualizar um pouco para depois ficar mais fácil de expôr algumas idéias. Meu time na Globo.com é formado atualmente por 3 desenvolvedores, 1 especialista em client-side e 2 arquitetos de informação (até semana passada eram 3). Temos um backlog de produto enorme, pois a equipe era formada apenas por 2 desenvolvedores antes da minha chegada em Janeiro. O resto do pessoal se juntou ao time em Março.

Uma coisa importante no Scrum (na verdade, em qualquer metodologia hoje em dia) é que os desenvolvedores sejam versáteis, e consigam atuar de várias formas diferentes, mudando de ferramentas, frameworks e linguagens sem problemas. Para que os desenvolvedores consigam fazer isso, é claro que é fundamental que eles estudem bastante e estejam sempre se atualizando, pois as opções de tecnologias disponíveis estão avançando muito rapidamente.

Outra coisa importante é que mais de um desenvolvedor do time seja capaz de realizar qualquer tarefa específica. Isto é importante pelo compartilhamento do conhecimento e para que seja possível lidar tranqüilamente com problemas pessoais, férias, etc. Neste sentido, precisamos pensar muito mais no conhecimento do time do que no conhecimento de indivíduos separadamente.

O que eu quero dizer com isso? Quero dizer que para um time andar bem, as escolhas de tecnologias idealmente devem ser moldadas em torno do time. Com a infinidade de opções que temos de frameworks web, APIs javascript/ajax, linguagens e componentes, não podemos nos dar ao luxo de ficar continuamente acompanhando as novidades e avaliando novas opções. Precisamos fazer algumas escolhas, e avançar com elas. É claro que isso pode e deve ser periodicamente revisto, mas é fundamental escolher algumas opções e se concentrar nelas.

Os 3 desenvolvedores do meu time têm experiência muito mais em Java do que em outras linguagens. Nossas aplicações são todas em Java, embora já estejamos fazendo experimentos com outras linguagens. Entretanto, concordo bastante com um artigo que saiu no InfoQ recentemente, que traz a idéia de que Java pode ser a última grande linguagem. Compartilho da idéia do autor de que provavelmente estaremos nos próximos anos escolhendo linguagens de uma forma semelhante à que escolhíamos frameworks Java nos últimos anos.

Java é uma linguagem de propósito geral. Gosto muito da linguagem e da plataforma. Mas com novas linguagens/frameworks direcionados para problemas específicos, é natural que em alguns nichos Java não seja a melhor opção. Penso que isso está acontecendo com mais força em aplicações web. Novas opções como o Grails, Django e Ruby on Rails oferecem um desenvolvimento muito mais produtivo do que Java em algumas aplicações. Java possui ótimos frameworks web, e já é uma linguagem muito madura. Mas quem já utilizou alguma dessas 3 opções que mencionei já pôde constatar o choque de produtividade delas contra a maioria dos frameworks web Java.

Conversei sobre isso com o resto do time e a minha opinião é de que devemos nos concentrar em torno de um conjunto limitado de opções, para que o time tenha um melhor rendimento. Com isso, o ideal é que o time conheça bem 2 ou talvez 3 frameworks web Java, 1 ou 2 das opções de alta produtividade web, e 1 ou 2 opções de framework javascript/ajax (jQuery por exemplo). As escolhas devem ser feitas pelo time em conjunto, de acordo com as aptidões e conhecimento agregado dos membros.

Trabalhando com um conjunto reduzido de opções, fica muito mais fácil compartilhar o conhecimento dentro da equipe, e conseguimos que os desenvolvedores conheçam bem esses componentes escolhidos e sejam produtivos com eles. Não adianta muito que um dos desenvolvedores saque muito do “melhor framework web da história desse país”, mas só ele conheça esse framework.

É melhor que seja utilizada uma opção que o time de uma maneira geral já conheça e seja produtivo. Pode ser que essa 2a opção não produza flocos tão crocantes como aquele outro framework, mas se é uma boa ferramenta para o problema e o time conhece bem, use essa mesma!

É claro que em algumas situações nós precisamos abrir mão de algo que conhecemos bem para utilizar uma opção que se adequa melhor aos outros membros do time. Vamor supor que um dos desenvolvedores saca muito de Tapestry e considera que ele é o melhor framework web Java. Se os outros 3 desenvolvedores já conhecem bem de JSF, provavelmente a melhor alternativa é que o time use JSF, e aquele desenvolvedor abra mão do Tapestry em favor do JSF. Pode ser que o Tapestry seja melhor tecnicamente do que JSF, mas os resultados têm que ser entregues pelo time, então as escolhas têm que ser feitas em torno das aptidões do time como um todo.

Tendo feito as escolhas de tecnologias, o legal é que os desenvolvedores se revezem com alguma freqüência entre as linhas de atuação, para propagar melhor o conhecimento e o time como um todo amadurecer. Eu por exemplo conheço legal de REST, mas os outros 2 desenvolvedores do time já implementaram alguns serviços e clientes REST, e com certeza têm plena condição de trabalhar em qualquer um dos serviços REST que eu implementei.

Aos poucos estamos aprendendo mais da parte client com o especialista do time, e ele também já está aprendendo um pouco de JSF, e com isso vamos todos amadurecendo. Essa gestão de conhecimento do time deve ser muito bem feita, para que os resultados do time vão melhorando progressivamente sprint após sprint. A decisão de se concentrar em algumas escolhas (mesmo que talvez elas não sejam as melhores tecnicamente) é muito importante para que o time se mantenha produtivo.

Todos gostamos muito de software, e de avaliar novidades. Porém, não somos pesquisadores, somos desenvolvedores comprometidos com resultados. Essa decisão das escolhas do time é muito importante. Nosso tempo de estudo é limitado, portanto precisamos ser pragmáticos e focar nos resultados.

O site Efetividade.NET postou recentemente um artigo onde foram relacionadas algumas atitudes e posturas de pessoas que são levadas a sério. Eu particularmente gostei muito do artigo e por isso resolvi linká-lo aqui.

Boa leitura.

Liderança e motivação: quer ser levado mais a sério?