A Liderança Tem Lá Seus "Vazios". Será Mesmo?

Suponha que você seja um daqueles profissionais de TI bem conceituados, que vive se atualizando, que tem uma experiência considerável naquilo que faz e que vem conseguindo levar sua carreira com seriedade e sempre tentando, de maneira honesta, subir degraus de forma gradual e consistente até que... Você vira líder de uma equipe!

Tudo parece acontecer naturalmente, afinal você trabalhou duro e estava preparado para esta oportunidade. Você então faz milhares de planos e tenta ressuscitar em sua mente todos aqueles conhecimentos acadêmicos sobre gestão de pessoas, liderança, gestão de equipes, etc.

Logicamente, depois de certo tempo, você começa a perceber que a atividade de líder possui atributos diferentes daqueles aos quais você estava acostumado na época em que trabalhava com atividades meramente técnicas. Toda aquela conversa que você sempre ouvia sobre a responsabilidade maior e a cobrança que aumenta na mesma proporção, começa a fazer sentido. Aliás, você passa a ver que muitos daqueles clichês de liderança que você muitas vezes desdenhou agora não são mais apenas "conversa pra boi dormir". Você passa a ter outras preocupações e outras entregas para fazer, em níveis distintos daqueles de antes.

Em alguns momentos, você não sabe por que, mas sente-se meio sozinho. E essa sensação aumenta à medida que você não é mais executor direto de algumas das tarefas do projeto, mas agora é quem as coordena e as delega. Se você começou a trabalhar num cargo de liderança ou já trabalha em um, certamente essa sensação já passou por pela sua frente alguma ou algumas vezes. Mas, por que será que esse tipo de coisa acontece?

Eu acho que isso é devido ao fato de que, muitas vezes, os bons profissionais são extremamente apegados ao seu trabalho. Gostam muito daquilo que fazem. Têm paixão por aquilo que fazem. É como se cada projeto novo colocado em prática fosse uma espécie de “filho”. Talvez isso explique um pouco o "vazio" que um líder de equipe sente em determinados casos. Como agora ele não está tão intimamente ligado à execução das tarefas técnicas e/ou inerentes ao processo produtivo em si, tendo outras pessoas nessa função, há uma sensação de distância ou até de desconfiança em relação ao que precisa ser feito. Ele sabe que tem de delegar, mas sempre fica com o “pé atrás”, pois não tem aquela certeza absoluta de que estão fazendo as coisas tão bem quanto ele fazia. Que líder de equipe nunca sentiu isso, mesmo que momentaneamente?

Esse tipo de posicionamento pode parecer um tanto egoísta, mas acontece. O que o líder precisa ter em mente é que, a partir do momento em que lhe é incumbida uma liderança de equipe, outras atividades e responsabilidades irão preencher com sobras todos os vazios que ele sente em relação ao que fazia antes. Não raro, ele acabará ainda mais atarefado do que antes. Você, como líder, passa a ser verdadeiramente o representante de um grupo, ao qual recaem muitas expectativas. E faz parte da sua função lidar com elas. Pressão também existe, mas é inerente ao processo. Esta é, sem dúvida, uma mudança de paradigma que pode requerer uma adaptação grande, dependendo do seu perfil, mas que também vai proporcionar um amadurecimento profissional incrível.

Se você está hoje em uma posição de liderança, é porque certamente trabalhou e merece estar lá, ou pelo menos consideram você a pessoa certa para estar lá. Portanto, lembre-se de que você terá outras coisas a mostrar, irá aprender coisas novas, sentirá as diferenças em relação à cobrança, terá de administrar conflitos e verá, finalmente, que aqueles ensinamentos sobre liderança da época da faculdade não eram apenas conversa acadêmica. Eles realmente formarão a base de conhecimento necessária para administrar esse novo rumo da sua carreira. E você não vai querer mais voltar atrás, pode ter certeza.


* Adaptação do texto escrito em 15/01/2009

Leia Mais

Grande ou Pequena? É Tudo Questão de Atitude!

Embora eu me considere um guri, já estou no mercado de TI há uns bons anos. Já vi muita coisa nessa minha “breve” carreira, que ainda tem muita estrada pela frente, mas da qual tenho orgulho de, ao menos até hoje, só ter evoluído profissionalmente. Nessa minha vivência, eu já trabalhei tanto para empresas pequenas quanto para multinacionais do setor. E é aí que eu vejo que tem coisas que acontecem no dia-a-dia e que destoam da imagem que a empresa tem (ou que quer que todos pensem que tem).

Quando você trabalha para uma empresa pequena, tudo parece estar mais próximo de você. Precisa de alguma coisa? Falar com alguém? É só andar alguns metros ou ir à sala ao lado. Quando muito se vai a outro prédio. Isso quando existe outro prédio (empresas pequenas, na sua maioria, não têm mais do que um prédio, se você não sabe). A comunicação então... Essa sim, mais objetiva impossível. Mesmo que ainda existam muitos ruídos, parece ser mais fácil de se resolver os problemas.

Numa empresa pequena, as discussões sobre os projetos também são diferentes. Cada centavo economizado ou cada ação possível para contentar o cliente é muito importante, não apenas institucionalmente, mas é uma questão de sobrevivência. Divergências sobre o projeto? Bah, isso então pode chegar, às vezes, a gritos e "dedo na cara". Tudo para garantir que o trabalho seja bem feito, que o cliente esteja satisfeito e que isso valha para a empresa uma boa reputação, o que fecharia o ciclo com a atração de mais clientes.

Pois bem. E o que muda em relação a uma empresa grande? Em uma grande corporação as distâncias podem ser bem maiores. Muitas vezes, de dimensões continentais. É de praxe ter um pedaço da equipe no Brasil, outra nos EUA e outra na Índia, etc. Hoje em dia, o intercâmbio entre essas nações em termos de tecnologia é algo muito comum. O problema é que há muita gente envolvida, muitos níveis hierárquicos para que a informação consiga chegar ao seu destino. Por diversas vezes me senti de "mãos amarradas" por causa da dificuldade em fazer um desenvolvedor entender um requisito sem estar ao lado dele para apontar a tela ou fazer gestos. A demora com que as coisas acontecem nesse contexto pode ser muito maior do que numa pequena empresa.

Uma coisa que pude perceber é que quanto mais gente se tem, mais há incompetentes “camuflados”. É mais fácil encontrar pessoas que não querem "colocar o seu na reta". Parece que têm medo de falar algo por receio de serem prejudicadas. Falta coragem mesmo. Ainda mais num ambiente onde é comum encontrar indivíduos que já passaram dos 30 ou estão quase lá e que nunca trabalharam em outro lugar antes. Caramba, esses são os mais difíceis de lidar: os mimados. Como é complicado exigir deles uma tarefa que requeira atitude ou que exija que eles se imponham. Eles estão, como diz um amigo meu, sempre com o "[save ass mode]" ligado. Provavelmente nunca vão sair do lugar onde estão, pois não arriscam nada, nunca. Do jeito que está, tá bom. E num ambiente com milhares de pessoas, é bem mais fácil se esconder atrás do “sistema”. Numa empresa com menor número de pessoas, é bem mais complicado, pois você está mais exposto. E nem vou entrar no mérito das questões políticas, que podem, por si só, desvirtuar qualquer padrão mencionado aqui.

Acredito que ser grande é uma questão que está relacionada também à atitude e à cultura organizacional, não apenas ao tamanho da empresa em si. Quer um exemplo? O compromisso com as entregas. Se a empresa usa a TI para atender apenas as suas necessidades internas, temos algo parecido com o estereótipo do serviço público. Só falta uns e outros deixarem o paletó na cadeira para fingirem que vieram trabalhar. Aliás, acho que nem isso falta, porque eu já vi umas dessas... No caso dos recursos, geralmente os atrasos são mais tolerados, pois a demanda é meramente interna. E se você quer melhorar alguma coisa, normalmente é um parto. Se a TI não for a razão de ser da empresa, então, sai de baixo... Eu já tive de ouvir uma vez algo do tipo: - Mas o nosso negócio nem é software, porque essa loucura toda com a qualidade do projeto? Sinceramente, essa foi uma das colocações mais infelizes que eu já vi... Mas, quem era eu para querer salvar alguns milhares de dólares? Esse sim é um ponto que tem relação direta com o tamanho/faturamento da empresa. Ele pode ter ou não um peso maior, dependendo de quanto a empresa se permite “queimar dinheiro” durante um projeto.

Quando a empresa foca a TI para atender os clientes, principalmente aquelas que desenvolvem soluções, aí a coisa muda de figura. O ambiente é, normalmente, mais "profissional" (odeio ter de escrever essa palavra entre aspas), as pessoas precisam cumprir prazos e os projetos precisam ser entregues com qualidade respeitável. Orientação para o cliente é algo que muda completamente a cultura de uma organização. Cada projeto é algo totalmente novo, desenhado para um cliente diferente. O aprendizado é muito grande e o comprometimento das pessoas também. E os custos são mais dimensionados e cobrados. Nesse tipo de ambiente, as distâncias geográficas parecem não atrapalhar tanto, pois cada um faz o seu melhor. Lógico que em todo lugar tem um ou outro sanguessuga. Há de se ter de conviver com eles. Só que eles felizmente sucumbem num ambiente mais profissionalizado.

O que eu percebo é que, quando quem te cobra é o cliente, aquele que realmente paga o seu salário, a tendência é a empresa passar a se comportar como “grande” em termos de atitude. E qualquer que seja o seu tamanho atual, é por essa atitude que, mais adiante, ela poderá se transformar em maior ou menor do que é hoje. 

* Adaptação do texto escrito em 16/11/2007

 

Leia Mais

O Plano e o "Limbo"

Já fazia um ano que o projeto estava em execução. Já tinha sido interrompido uma vez. Deram um tempo para que o pessoal do desenvolvimento "ajeitasse a casa" e voltasse depois, com uma aplicação que pudesse passar pela área de teste de software sem muitos problemas. Teoricamente ela deveria estar estável (sim, porque na primeira entrega, estava um desastre, por isso o projeto foi interrompido). Mas, para a surpresa de todos, a aplicação parecia estar exatamente igual à época da parada total. O prazo já tinha sido esticado (coisa rara, mas dado o estado deplorável do código...), mas ainda assim não seria suficiente para que o produto fosse entregue a tempo e com qualidade. E o melhor de tudo é que os responsáveis pela condução do projeto, os "cabeças" da coisa toda, pareciam estar em outro mundo, como se tudo estivesse indo bem.

O projeto já começou errado. Desde sua concepção já se percebia que o escopo era grande demais para os recursos e o tempo disponíveis. Seguir os requisitos? Isso era comprar uma briga sem razão, coisa de rebelde sem causa. O pior é que ainda tinha mais coisa a ser pensada, mas que ninguém tinha percebido ainda: o futuro. Afinal, tratava-se de um projeto de reescrita de uma aplicação importante para a empresa. Algo que realmente influenciaria na produção e nas vendas. E, algo muito importante a ser considerado pelos tomadores de decisão, é que toda a decisão para o futuro é tomada no presente. Soa meio que filosófico, é extremamente importante para percebermos as consequências dos nossos atos. Mas, nesse caso, todo mundo até então só falava no que tinha acontecido e no que iria acontecer até instalarem a nova aplicação. A partir deste ponto, nada havia sido tratado. Ninguém sequer falou na "barriga" do projeto, tão comum, mas menosprezada até pela cartilha do PMI...

Essa é uma história que diz respeito a algo que muita gente vivencia diariamente nas empresas. Mas que raios é essa tal de "barriga"? Do que estou falando? Bem, acho que um exemplo certamente ficaria mais esclarecedor. Então vamos a ele.

Há uns anos, uma grande universidade brasileira resolveu que era hora de mudar seu ERP e adquirir uma solução mais moderna e integrada, que pudesse fornecer informações estratégicas em tempo real e facilitar a comunicação e a tomada de decisões entre as unidades de ensino da instituição. O investimento estava estimado em R$ 15 milhões, aproximadamente. Até então, a universidade utilizava muita coisa desenvolvida internamente em seus laboratórios, algo não muito sofisticado, mas que funcionava bem e que todo mundo conhecia. Mas aí veio a "necessidade" de se adquirir um ERP de verdade, afinal, todo mundo tinha um.

A exemplo do primeiro caso, ignorou-se a "barriga do projeto" (nome dado por um professor dos tempos de faculdade). Na maioria das vezes, os projetos são pensados e planejados como se tudo fosse correr como o previsto. Parece que, entre a aplicação ser implantada e estar funcionando 100% com todos os usuários treinados, o caminho é linear. Essa representação está na figura a seguir. Suponha que a aplicação seja implantada em módulos e que a fase 1 seja a implantação do primeiro (antes dela teve todo o trabalho de análise, programação, teste, etc.). Nessa fase é importante lembrar que, no momento em que a nova aplicação entrou no ar, a antiga foi descontinuada. Pois bem, logo a seguir, a fase 2 seria a implantação do segundo módulo, e assim por diante. Note que o caminho entre a fase 1 e a fase 2 parece ser algo linear, representado por uma reta, já previsto o treinamento dos usuários e o tempo de adaptação à nova ferramenta. Tudo muito bem planejado, aparentemente. Veja:

Aí é que entra a "barriga". Existe um período que ocorre durante a transição de uma ferramenta para outra que é uma espécie de "limbo", onde os usuários não têm mais as informações das quais dispunham na época da aplicação antiga, e também ainda não têm as novas informações geradas pela nova aplicação, pois ela ainda não foi completamente instalada. Em outras palavras, é um período em que os usuários simplesmente se veem sem informações suficientes para poderem tomar decisões. Esse período é representado pelo pontilhado azul e pela "barriga" da figura a seguir:

Como é possível perceber, a progressão do projeto não é mais uma reta, mas sim algo próximo a uma parábola. E, como a segunda figura mostra, acontece de forma não planejada. Note que os intervalos de tempo (que foram planejados) são os mesmos. O que mudou foi o comportamento da progressão das fases. Sabemos que, sempre que se mexe em um dos elementos do trinômio do projeto (escopo x tempo x recurso), os outros dois naturalmente precisam (ou deveriam) mudar. O que aconteceu nesse caso da universidade foi que o tempo (mal) planejado acabou não sendo cumprido como se esperava, pois a transição de fases utilizou mais tempo do que era previsto devido ao período em que os usuários ficaram no "limbo". E aí, automaticamente, os recursos (dinheiro a mais que foi gasto em treinamento, horas extras, etc.) e o escopo (simplificação de algumas rotinas) mudaram para que se pudesse cumprir o tempo até a implantação do segundo módulo.

Ao fazer o planejamento de um projeto desse tipo (reescrita de uma ferramenta importante), é preciso considerar não apenas a fase de adaptação, mas também a "barriga". As duas normalmente acontecem juntas. Descontinuar uma aplicação antiga logo após ter implementado uma nova também não é uma boa ideia. Certamente isso só aumenta o tamanho da "barriga". É muito importante que a aplicação antiga esteja rodando junto com a nova, pelo menos durante certo tempo, até que a adaptação e o aprendizado estejam concluídos de maneira satisfatória. E, em se tratando de projetos, vale lembrar que a maior surpresa é justamente não haver surpresas. Por isso, quanto mais variáveis forem consideradas no processo de planejamento, a menos surpresas o projeto estará sujeito ao seu final. Esse é o exemplo desta universidade. É algo já ocorrido. É passado. E pensar que o pessoal do projeto que falei no começo do post ainda nem tinha avançado o suficiente no cronograma para chegar a pensar nisso... 

* Adaptação do texto escrito em 13/12/2007

Leia Mais

Seu Chefe Precisa Saber Mais Que Você?

Você está com um baita problema relacionado ao projeto. O código do módulo de faturamento do seu sistema está apresentando uma falha e não está atualizando os campos de previsão de entrega no site, onde o cliente consulta o status do pedido. Você sente que precisa de ajuda para corrigi-la. Seus colegas mais próximos estão todos ocupados e não têm como lhe ajudar. Você precisa corrigir o defeito o quanto antes porque os clientes já estão ligando para o call center e reclamando da falta da informação no site.

Você então recorre ao seu chefe para que ele lhe ajude. Com a prática moderna de trabalho em equipe, é perfeitamente comum ele estar tão próximo de você quanto seus colegas. Parênteses aqui: chefe? Quem tem chefe é índio, diriam os analistas de RH. Onde já se viu as pessoas usarem essa palavra nos dias de hoje, ainda mais nas empresas de TI? Mas sejamos francos: por mais que tenhamos nos acostumado a chamar nosso "superior" de líder, ainda temos nosso DNA de "peão" e ainda o vemos como chefe. E isso ainda leva um tempo pra mudar. Além do mais, falar "chefe" em vez de "líder" ajuda na semântica.

Mas esse não é o assunto em questão. Fechemos os parênteses e sigamos com o exemplo: você pede um auxílio para seu chefe e ele, em vez de abrir o código com você, diz que não domina totalmente aquela tecnologia e, usando suas habilidades de negociação e persuasão, encontra e destaca rapidamente alguém capacitado para lhe ajudar. O problema é resolvido com extrema rapidez e tudo é entregue corretamente. Mas você fica com aquele pensamento em mente: - como o cara é meu chefe se ele sabe menos que eu dessa tecnologia? Aí está uma pergunta para a qual você provavelmente só vai descobrir a resposta depois que estiver no lugar dele.

No ambiente de trabalho, há diversas formas de você chegar a uma posição de liderança. Obviamente, estou falando das formas ditas corretas ou honestas, que não envolvem jogo político ou favorecimentos variados. Dependendo da empresa, também podem existir diferentes tipos e perfis de liderança desejados. Você pode tornar-se líder pela sua capacidade técnica destacada ou por habilidades como capacidade de negociação, organização, etc. E isso implica em lidar com situações diferentes daquelas do mundo meramente técnico. Em outros casos, a empresa pode contratar um líder que venha "de fora", com o intuito de que sua função seja realmente liderar/gerenciar um projeto. E para isso ele não precisa conhecer uma tecnologia a fundo. Talvez nem precise conhecer nada sobre ela. Mas ele certamente precisa ter outras habilidades que façam jus à posição que ele está ocupando. Saber encontrar o melhor recurso para agilizar a entrega de uma tarefa, como no exemplo citado, pode ser uma delas.

Quem trabalha com projetos (e isso também vale pra outras áreas) sabe que sobre o líder ou chefe recai uma carga muito grande de expectativa. Quando ele parece não atendê-la, fica sempre ou aquela pontinha de decepção (porque você depositava certa confiança nele e ele não pôde te ajudar), e/ou uma pontinha de inveja (porque você acha que sabe mais do que ele e isso faz bem para o seu ego). O fato é que o líder ou chefe tem que saber disso e, principalmente, saber lidar com isso. Ele precisa ter jogo de cintura e saber endereçar os problemas para que sejam resolvidos bem mais do que saber resolver propriamente a questão, metendo a "mão na massa". E é por essas habilidades, dentre outras, que ele ocupa essa posição. É melhor trabalhar com pessoas tecnicamente melhores que você do que o contrário. Certamente é melhor para o projeto. Pelo menos, acho que deveria ser visto dessa forma.

Aqui encontramos outro erro em relação a essa figura: o de achar que o líder é/parece ser/se sente superior. Quem sabe paramos de encarar o trabalho do líder como algo assim tão superior ao de um técnico? Ambas as posições são extremamente importantes para a empresa. No fundo, elas apenas possuem atribuições diferentes, mas de grande significância. Obviamente que um líder pode carregar um peso extra em termos de responsabilidade, dependendo de como está estruturada hierarquicamente a empresa. Mas nem sempre isso está refletido nos rendimentos financeiros dele. Pelo contrário, é cada vez mais normal o líder ser apenas um papel e não uma posição. Sendo assim, ele não necessariamente vai ter um salário maior que o seu. É claro que se ele tiver, as sensações descritas anteriormente se intensificam. É preciso certo cuidado antes de simplesmente criticar o papel de um líder. Saiba primeiro se você teria condições e habilidades (especialmente as não-técnicas) para estar no lugar dele. Fora dos nossos olhos, diversas outras situações acontecem, e o líder precisa lidar com várias delas e tomar decisões das quais, muitas vezes, nem ficamos sabendo.

Há várias possibilidades e oportunidades para o papel do líder ou chefe. Você pode se deparar com uma delas um dia. Se você, por alguma razão, receber a tarefa de liderar, pense nisso. É um momento perfeito para treinar a sua empatia e descobrir o quanto você consegue ser resiliente.

* Adaptação do texto escrito em 07/08/2008

Leia Mais

Dica de Leitura: Livro "Feitas para Durar"

É muito comum ouvirmos por aí que as empresas de TI, ou pelo menos a maioria delas, têm uma vida curta. De fato, muitas, especialmente aquelas dedicadas à produção de software, têm um ciclo de vida médio de 3 anos. Isso mesmo, 3 anos! Mas existem empresas que superam (e em muito) essa estatística cruel. A IBM, que está no mercado há mais de cem anos, é um belo exemplo. E assim acontece com tantas outras. Mas, o que, de fato, faz uma empresa tornar-se duradoura? No livro "Feitas para Durar", Collins e Porras dão o veredicto: É a visão que faz a empresa ir além e tornar-se duradoura. Embora o livro não trate especificamente de empresas de TI, é uma lição a ser seguida por empresas de qualquer segmento. O livro utiliza como exemplo empresas que resistiram ao teste do tempo e cuja data de fundação média é em torno do ano de 1897.

Como o próprio Collins define: "Não trata de conceitos de produtos visionários nem de intuições visionárias com respeito ao mercado. Feitas para durar trata de algo muito mais importante, duradouro e substancial: as empresas visionárias. Elas são instituições líderes em seus setores, muito admiradas pelas outras empresas da área e com um longo registro de impactos significativos sobre o mundo à sua volta."É uma ótima leitura para os líderes e gestores!


Dados do Livro:
Título: Feitas para Durar
Autores: James Collins e Jerry L. Porras
Editora: Rocco
Páginas: 408

Leia Mais