Esse tal Feedback

Se existe uma palavra que causa inquietude no ambiente de trabalho, essa palavra é feedback. Tem gente que, só em ouvi-la, já sente vontade de se esconder, com medo de alguma crítica “injusta” que possa receber sobre o seu desempenho ou atitudes. 

De certo modo, esse estereótipo é um pouco culpa da forma como a maioria dos líderes endereça as questões: houve-se mais a palavra feedback quando algo não está indo bem do que quando as coisas estão às mil maravilhas. 

Mas a verdadeira missão do feedback está além de apenas criticar. Em vez de entender a palavra como “retorno”, como é comumente colocada, deve-se analisar os radicais que a compõem. A palavra feedback pode ser lida também como “retroalimentação”, algo que vai se incrementando à medida em que recebe mais conteúdo. Filosoficamente falando, eu acho mais adequado dizer que o feedback representa um agente impulsionador de autodesenvolvimento. Explico: a maior contribuição desse tipo de processo é justamente fazer com que a pessoa que está recebendo o feedback possa desenvolver e potencializar aquilo que tem de melhor e corrigir ou ajustar aqueles pontos nos quais ela ainda é deficiente. O resultado disso, sendo bem trabalhado, é um profissional melhor, mais maduro e mais eficiente. 

  

Parafraseando um trecho de um episódio do Pica-Pau, personagem de desenho animado criado por Walter Lantz (os mais nerds entenderão): em todos esses anos trabalhando nesta indústria vital (a de TI, especificamente), você acaba vendo como as empresas tratam essa questão, e aprende muito com isso, desenvolve pensamentos próprios a respeito e chega a algumas conclusões interessantes. Algumas delas:

O feedback formal.

A maioria das empresas possui um sistema formal de avaliações ou feedbacks periódicos, as chamadas reuniões 1:1 (one on one). Justamente para evitar aquela máxima de que o feedback é algo negativo, a forma como você o comunica faz toda a diferença. Não existe autodesenvolvimento sustentado apenas por correções a serem feitas nem por potencialidades destacadas. Numa reunião de 1:1, daquelas que acontecem de tempos em tempos, é preciso que o feedback seja utilizado para os dois casos, de acordo com o ocorrido. E sempre bem embasado. Só relatar problemas vai transformar o feedback em “fodeback”, com o perdão da expressão. Da mesma maneira, as coisas não são sempre perfeitas, sempre há o que melhorar. Nesses encontros, é importante que se relatem os dois lados, para que se compreenda melhor onde o desenvolvimento se dará.

O feedback deve ser oportuno.

Oportuno significa que deve ser dado na hora certa. Por mais que numa reunião formal as potencialidades e oportunidades de melhoria devam ser relatadas, é preciso também haver feedbacks pontuais. Esses são tão efetivos quanto. Talvez até mais que. Não espere apenas pelas reuniões formais para comunicar um feedback a alguém. Se os intervalos entre elas forem grandes, você deixa de dar a chance da pessoa corrigir uma falha e evitar que o erro aconteça “n” vezes mais durante os próximos períodos. Também pode esquecer-se de elogiar algum objetivo atingido no momento, podendo passar a impressão de que não era tão importante, mesmo sendo.

Em geral, todo feedback é verdadeiro.

Opa! Como assim? E se alguém estiver errado ao meu respeito? Estarei eu recebendo um feedback injusto? Bem, não necessariamente. Excluindo-se aqueles poucos casos tóxicos onde realmente há intensão de prejudicar ou favorecer deliberadamente o avaliado (prática que, felizmente, não tenho mais visto nas empresas), eu diria que sim, todo feedback é verdadeiro. As pessoas veem aquilo que você faz elas verem. E é a partir disso que elas tiram suas conclusões. Você pode pensar não estar sendo visto da forma correta, mas, muitas vezes, é você que não está passando a imagem correta a seu respeito. Esse é um exercício de reflexão bem difícil, mas que pode explicar muita coisa. Tente ver se o problema não é a mensagem ou imagem que você está transmitindo.

Ouvir é melhor do que falar.

Essa talvez seja uma das chaves para o sucesso do feedback. É outro exercício complicado, especialmente para um feedback negativo, cuja primeira reação natural é a de não concordar com ele ou de não ter percebido os erros que levaram a recebê-lo. Em menor escala, há também a exacerbação causada pela euforia perante o recebimento de diversos elogios. Mas o ponto aqui é que sempre tendemos a querer falar mais do que ouvir nessas horas, seja para justificar-se, seja para gabar-se de algo. A sabedoria popular nos diz que não foi à toa que Deus nos deu dois ouvidos e apenas uma boca. Creio que, nesse caso, é bem por aí: o grande barato do feedback é justamente aprender para impulsionar nosso desenvolvimento. E aprende-se mais ouvindo, sem dúvida. Não significa que você não deve falar, mas sim que deve aproveitar ao máximo aquilo que está lhe sendo dito. A reunião de feedback é, primeiramente, para comunicar, não para discutir. Mas pode se transformar em oportunidade, se você souber aproveitar.

Reação ao feedback.

A forma como se encara um feedback diz muito a respeito da sua maturidade profissional. Se ouvir é mais importante que falar, lidar com aquilo que se ouviu é essencial. Eu admiro e valorizo as pessoas que reconhecem os pontos de melhoria como oportunidade e trabalham para atingi-los. Tive ótimas experiências, mesmo com aquelas poucas pessoas que vi fazerem cara feia, pois com elas tive exemplos de como as coisas não devem ser encaradas. Logicamente que, quando bem comunicado, o feedback tende a ser encarado da melhor forma possível. Mas a reação das pessoas dirá muitas coisas, inclusive sobre como lidar com cada uma delas no futuro.

O feedback é um caminho de duas vias.

Da mesma maneira que você pode ser responsável por passar um feedback a alguém, é preciso que você receba um retorno sobre o seu trabalho. Caso contrário, o processo fica sem sentido, pois apenas uma das partes é avaliada. Você pode receber feedbacks das mesmas pessoas que avaliou ou de outras acima, do lado ou abaixo de você. Mas é vital recebê-los. Afinal, o seu trabalho não é perfeito e você não é melhor do que ninguém para não ser avaliado. É um exemplo que você deve dar. Seja sempre humilde e entenda que sempre há o que melhorar. E que o feedback pode vir de onde menos se espera.

Todo feedback é para o bem. Compre e venda essa idéia.

Eu sempre procuro deixar claro que a intenção do feedback é sempre ajudar as pessoas a fazerem melhor o seu trabalho e buscar desenvolvimento. Eu acredito muito nisso mesmo. Jamais irei passar um feedback que não tenha essa motivação. Eu quero que o trabalho da minha equipe seja bem feito. E quero que as pessoas ao meu redor se beneficiem do sucesso do grupo. Por isso, até os feedbacks negativos devem ser vistos como oportunidades, nunca como críticas vazias. A postura deveria ser sempre esta. Mas você tem de acreditar nisso, para que as pessoas ao seu redor percebam e acreditem também. 

Essas são algumas coisas que aprendi a respeito do feedback. Confesso que passei a dar mais importância a ele quando me coloquei do lado do avaliador, mas, como já estive (e ainda estou) do outro lado, procurei aprender com as experiências anteriores e evitar aquilo que eu achava errado. Felizmente, tenho visto que as empresas estão modernizando essa ferramenta e a utilizando de uma forma bem mais produtiva. Pra mim isso fez e tem feito uma grande diferença. E pra você?

 

Leia Mais

Dicas Para Criar um Documento de Test Strategy

Que um projeto de software requer planejamento e definições claras, todo mundo sabe. O mesmo vale para a parte relativa aos testes do software. Assim como as demais, a fase de testes precisa estar bem organizada para evitar surpresas e comprometer qualquer um dos itens do trinômio do projeto (custo x escopo x tempo).

Quando se define uma estratégia de testes, deve-se colocá-la de forma explicita para os interessados (stakeholders) do projeto. E, para isso, existe um documento chamado Test Strategy, ou Estratégia de Testes. De acordo com a empresa e o processo vigente, esse documento pode ser também chamado de “Plano de Testes”, “Definição de Testes”, entre outros. Irei utilizar Test Strategy por ser de uso mais comum.

Tentarei, baseado em experiências anteriores, vividas ao longo da minha breve carreira, elencar uma série de pontos que considero importantes no estabelecimento de um documento desses. Indo direto ao ponto, cada empresa tem um processo interno de TI diferente e, por isso, alguns itens podem ou não ser relevantes, mas mencionarei aqueles que eu acho fundamentais, supondo que você precise desenhar um processo de testes desde o início.   

O Test Strategy funciona como um "desenho" do processo, sendo enviado às partes interessadas e, normalmente, necessitando de um approval antes de ser oficializado. É comum serem geradas algumas versões até que se chegue à definitiva. E mesmo esta ainda pode sofrer pequenos ajustes no decorrer da implantação do processo, uma vez que fatos novos ou não considerados antes podem surgir. 

Considero importante que o documento contenha, ao menos, as seções a seguir. Algumas podem estar ou não subdivididas, isso dependerá da preferência de quem escreve ou de formatos padrões que cada empresa adota para suas documentações. O mesmo vale para a ordem de apresentação de cada seção:

Capa

Parece óbvio dizer que um documento precisa de capa, mas ela é sua carta de apresentação. É através dela que os interessados irão identificar do que o documento se trata com exatidão. Em formato digital, o nome do arquivo também deve ser de fácil identificação. Uma boa capa apresenta:

- Título: nomenclatura usada para definir o documento (Test Plan, Test Strategy, Test Definitions, etc. e suas variantes em português);

- Nome/Logotipo/Timbre da Empresa: importante para identificar que se trata de um documento interno e de uso corporativo. Em algumas empresas, por exemplo, esse tipo de documento sequer é descartado e uma lixeira comum; há umas especiais só para eles, ou então são triturados para preservar a segurança das informações;

- Área/Sistema/Projeto: referência ao objeto do teste, o que será testado. Pode-se mencionar também se o sistema é novo ou se é uma reescrita;

- Autor e Data de Criação: usado como referência para que se saiba a idade do documento e quem foi que o elaborou.

Histórico de Versões/Revisões

Como já mencionado, um documento de Test Strategy pode ter várias versões até ser considerado pronto. Isso porque ele é analisado por diversas pessoas, que podem contribuir apontando problemas ou fazendo sugestões. Para que se tenha a real noção do quanto de esforço foi desprendido para a criação do documento, manter um histórico de revisões é fundamental. Além disso, este registro nos permite saber em qual ponto da história determinada modificação foi inserida, fato que pode ajudar a entender acontecimentos no futuro. Pode ser uma seção bem simples, contendo apenas:

- Data: registro do dia em que a inclusão/alteração foi feita;

- Versão: qual a versão corrente do documento. A forma de numerar fica por conta dos padrões adotados pela empresa;

- Autor: quem fez as modificações;

- Descrição das Alterações: o que foi feito durante aquela revisão, quais seções do documento foram alteradas e por que.

Índice/Sumário:

Parte óbvia. Utilizada como guia para que se saiba em que página está cada item e facilitar a navegação visual.

Introdução:

Costumo dizer que é pela introdução que você faz uma pessoa se interessar mais por uma leitura. No caso do Test Strategy, não é muito diferente. Documentação técnica em geral é bem sisuda e, se você conseguir ser objetivo e passar a mensagem correta, pode ser a diferença ente um leitor ler todo o documento ou apenas partes deles. Por, isso, inclua na introdução:

- Propósito do documento: o quê motivou a criação deste documento? Qual a sua razão? Sobre o que ele versa? No caso de um novo sistema, você pode mencionar que uma necessidade nova de negócio gerou uma nova aplicação e que esta precisa ser testada corretamente. Caso seja uma reescrita, você pode passar um breve histórico da verão anterior e as limitações que levaram a uma modificação, que também precisa ser testada. Esses são apenas dois exemplos, isso pode variar de acordo com o projeto;

- Objetivos: quais são os objetivos de teste que se pretende atingir com o processo proposto no documento?  

- Escopo de Teste: defina aqui exatamente o que vai ser testado: módulos, sistema inteiro, integração com outros sistemas, etc. É muito importante para cobranças futuras e serve como base para possíveis negociações, caso sejam necessárias mais adiante;

- Referências: qualquer documentação auxiliar que originou o documento atual ou que possa ser usada como complemento;

- Recursos Humanos: Quantas pessoas serão necessárias para o desenvolvimento do projeto de testes e em quais funções elas serão alocadas. Aqui é apenas um número usado para estimativas, não necessariamente precisa conter nomes.

Ferramentas Utilizadas

Essa seção deve conter todas as ferramentas necessárias para a realização das tarefas de testes. É importante também mencionar possíveis necessidades de licenças de usuários, mas aqui, teoricamente, a ferramenta já foi adquirida, portanto é mais uma questão de liberação do que qualquer outra coisa. Algumas ferramentas do mercado atendem a mais de um dos itens abaixo. Basicamente, são elas:

- Ferramenta de Gerenciamento: se houver, listar qual ferramenta (suíte) está sendo utilizada para gerenciar e/ou integrar todo o processo de teste;

- Test Design: ferramenta que será utilizada para a confecção dos test cases ou scripts automatizados; 

- Test Execution: aplicação que será usada para execução e registro dos resultados dos test cases ou scripts automatizados;

- Bug Tracking: utilizada para abrir/gerenciar/reportar os defeitos encontrados;

- Métricas: O que será usado para coletar e comunicar as métricas do projeto. Pode ser um simples relatório, obtido através do próprio suite de testes ou até mesmo um arquivo PowerPoint com as informações.

Gerenciamento de Defeitos

Aqui deve ser relatado como será conduzido o processo de gerenciamento dos defeitos encontrados durante o teste. É um ponto muito importante, uma vez que o simples ato de abrir um ticket pode envolver outros times além do de teste, como desenvolvimento e business. Por esse motivo, quanto mais claro estiver essa parte do processo, melhor. É igualmente importante que os padrões estabelecidos aqui sejam consenso entre o time de testes e os demais times que possam estar envolvidos. Devem estar descritos itens como:

- Fluxo e Status do Defeito: quais os caminhos que um defeito deve seguir a partir do momento em que é encontrado e/ou inserido no sistema de bug tracking até ter um destino final, e como cada fase será denominada. Por exemplo, o defeito terá como status inicial "Open" e final "Closed", podendo passar por outros status à medida que vai sendo trabalhado. Mencionar também quais pessoas/funções estão incumbidas de cada parte do fluxo ou mudança de status do defeito e a interação entre elas. 

- Níveis de Severidade: varia de empresa para empresa, mas pode-se usar a convenção adotada pela maioria, que vai de 1 a 4, onde 1 é o mais alto e 4 o mais baixo. É possível utilizar uma tabela informativa contendo o nível e sua respectiva descrição;

- Tipos de Defeito: classificação de cada tipo de defeito que pode ser encontrado durante o projeto. Pode ir desde os mais comuns, como defeitos de código, ambiente e dados, até outros relacionados ao design dos testes e requisitos ou problemas em outros artefatos.  

-  Principais campos de um Defeito: listar todos os campos que serão obrigatórios e opcionais de serem preenchidos no momento de abrir um defeito. Devem constar na lista ao menos o nome do campo, sua descrição e alguma flag que indique se ele é obrigatório ou não. Obviamente, a ferramenta de bug tracking deve ser configurada para refletir essas definições. Incluem-se aqui campos como código, data de abertura, data de fechamento, severidade, criticidade, área de negócio, responsável, etc.

Critérios de Entrada e Saída do Teste

São aqueles obtidos quando determinadas ações acontecerem. Listar quais são essas ações e qual função é responsável por ela. Ambos dependerão de um acordo entre os membros do projeto. 

Os critérios de entrada dizem respeito a tudo aquilo que deve ser configurado antes dos testes serem criados ou executados. Por exemplo, esses critérios podem ser obtidos quando as seguintes ações ocorrerem:

- Os dados da baseline estarem previamente setados, a fim de que se saiba quais são as configurações iniciais do banco para futuras comparações de resultados esperados versus atingidos;

- O ambiente de testes deve estar funcionando corretamente; 

- O processo de gerenciamento de defeitos foi estabelecido e aprovado;

- As reuniões de status do projeto foram previamente agendadas;

- Entre outros.

Já os critérios de saída,, por exemplo, podem ser atingidos quando as seguintes ações ocorrerem: 

- Todos os test cases ou scripts foram escritos e aprovados para execução; 

- Cada test case ou script foi executado ao menos uma vez antes de um ciclo regular, tendo seu tempo de execução registrado e funcionamento atestado; 

- Os testes aprovados foram executados em um ciclo regular de testes;

- Os defeitos encontrados foram gerenciados conforme o processo definido;

- Entre outros. 

Entregas/Deliverables

Esta seção diz respeito ao que será entregue ao final do processo de teste cada vez que ele for executado, ou seja, os produtos que serão mostrados para os interessados e que serão usados para demonstrar os resultados do processo e se chegar ao valor do trabalho em si. Atenção: aqui não são mostrados os resultados, apenas os produtos finais que serão usados para atingi-los, tais como:

- Test Cases Manuais ou Scripts Automatizados;

- Histórico de Execuções de testes;

- Relatórios Diversos (Status, Execução, Métricas, Defeitos, etc.).

Ambiente de Teste 

Normalmente são listados aqui todos os critérios que devem ser preenchidos para que o processo de teste seja realizado com sucesso em um determinado ambiente, como:

- Ambiente: em qual ambiente os testes serão utilizados. Podem ser ambientes específicos ou compartilhados (ambientes de teste, desenvolvimento, produção, pré-produção, etc.); 

- Colaboração: estabelecer quais são as equipes que deverão estar envolvidas na manutenção do ambiente (analistas de negócio, time de infraestrutura, DBAs, time de testes, desenvolvimento, etc.);

- Acesso: como se dará o acesso ao ambiente (máquina física, virtual, com uso de token, etc.) e os servidores utilizados;

- Dados: que tipo de dados serão usados (dados fictícios, de produção, cópias de produção); 

- Qualquer outra informação relevante que seja relativa ao ambiente.

Estrutura do Time e Responsabilidades

Deve ser descrita toda a estrutura da equipe e quais papéis cada membro tem. Pode ser utilizada uma tabela simples para listar isso, contendo colunas como: função, nome dos membros e responsabilidade de cada um. Colocar um campo contendo o contato da pessoa também pode facilitar na hora de procurar ajuda.

Adicionalmente, pode-se incluir fora desta tabela uma subseção relatando possíveis necessidades e estratégias de treinamento para o time, a fim de que se possa executar o processo com mais qualidade. Essas necessidades compreendem treinamento de negócios, processos internos já existentes, treinamento em novas ferramentas que serão utilizadas, conhecimento de sistemas específicos, etc.

Riscos, Dependências, Suposições e Restrições do Projeto

Também podendo ser uma tabela simples, deve considerar todas as variáveis que podem influenciar no sucesso ou andamento do processo de testes. É importante porque relata possíveis pontos deficientes na estrutura atual ou prevê possíveis situações que apresentem desvios dos resultados esperados. A tabela pode conter as seguintes colunas:

- Tipo: se é um risco, dependência, suposição (assumption) ou restrição;

- Titulo: a que se refere;

- Descrição: detalhes do item em questão, o que ele representa, quais possíveis alternativas a ele.

Abordagem do Teste

É uma descrição formalizada da parte operacional dos testes. É como a coisa toda vai funcionar em detalhes e quais padrões deverão ser seguidos. É sempre importante mencionar que é uma seção dinâmica e que alguns padrões podem ser modificados no futuro. Algumas partes importantes:

- Estágios de teste: relatar como o processo se dará desde o começo. Por exemplo: o primeiro passo será a compreensão do negócio e da aplicação, com possíveis treinamentos. Depois, parte-se para a escrita de testes manuais que serão usados nas fases de testes funcionais. Em seguida, serão desenvolvidos scripts automatizados para executar testes de regressão. O passo seguinte pode ser a seleção dos testes a serem executados, seguido da execução dos mesmos e terminando com a apresentação dos relatórios de resultados;

- Padrões de testes: descrever como serão construídos os test cases ou scripts automatizados. Relatar o sistema de nomenclatura, quais campos eles deverão conter, quais os valores esperados para cada campo, por quais status eles passarão entre escrita e aprovação, etc.; 

- Local de Armazenamento: em que pasta ou diretório os testes ou scripts estão localizados/armazenados e como fazer para acessá-los;

- Agenda (schedule): descrever a agenda  do processo, mostrando as datas iniciais e finais de cada atividade prevista; 

- Indicadores: quais serão os critérios utilizados para a geração das métricas, baseados nos resultados obtidos.

Como eu disse, muitos dos padrões aqui relatados podem variar, de acordo com cada empresa e como cada processo é estabelecido. Por esse motivo, procurei não aprofundar muito cada item (acreditem, normalmente o nível de detalhe é maior). Mas acho que estes pontos acima podem ser úteis para a confecção de um bom Test Strategy. O mais importante ter em mente que um documento desses deve ser dinâmico, que a cada novo projeto a documentação tem de evoluir em relação ao projeto anterior. E não deve ser considerada como mera parte burocrática. Ao contrário, mesmo para processos ágeis a documentação é importante. Quanto melhor definida, menos questionamentos gera e mais produtividade se consegue.

Leia Mais

Dica de Leitura: Dois Livros sobre Steve Jobs

Quando não temos todas as informações que gostaríamos sobre um tema que nos interessa, é normal que pesquisemos a respeito. Também criamos conceitos e pedimos uma segunda opinião, não é mesmo?

Eu, como boa parte das pessoas do meio da TI, sempre acompanhei as histórias e empreitadas do fundador da Apple, Steve Jobs. Nunca fui um Apple Lover, mas a relevância desse cara para a minha geração é incontestável. Para mim, formado em Administração, a Apple sempre foi um case de sucesso, sempre achei interessante estudá-la para entender porque a empresa tem tantos fãs, ainda mais tendo produtos tão caros, frágeis e pouco integrados (sim, eu uso Android), ainda que excelentes e, principalmente, revolucionários. 

Mas Steve Jobs passou a ter mais atenção da minha pessoa em sua era pós-iPod. Foi quando a Apple realmente deu seu grande salto. Sempre inovou, e isso não é novidade, mas após a volta dele ao comando da empresa, as coisas tomaram outra proporção. E acho que é o vanguardismo que atrai tantos fanáticos. É como ser fã da Harley-Davidson, só que ao contrário (já que os fãs da Harley são bem tradicionais, pra não dizer conservadores). Eu nunca vi alguém chegar ao ponto em que ele chegou em termos de influência de mercado. Criar um produto (no caso, o iPhone) e dizer para todas as poderosas operadoras de telefonia como elas deveriam trabalhar a partir daquele momento não é pra qualquer um, com certeza. 

O fato é que os livros a seguir provêm um bom embasamento sobre quem foi e o que fez Steve Jobs. Recomendo a leitura de ambos justamente por apresentarem pontos de vista diferentes. Um deles, intitulado "Steve Jobs - A Biografia" faz um relato mais humanista, vindo do próprio cidadão em questão. foram mais de 40 entrevistas em dois anos de trabalho. Já sabendo que tinha pouco tempo de vida, Jobs abriu seu coração e contou suas histórias, arrependimentos, conquistas. Em outras palavras, o livro fala do ser humano Steve Jobs.

Já o segundo livro, "A Cabeça de Steve Jobs", mostra como os outros viam o fundador da Apple. Como suas atitudes foram percebidas ao longo dos anos e quais conceitos e estereótipos ele acabou gerando a respeito de si mesmo. O livro é, até certo ponto, mais técnico, com linguagem mais administrativa e chega ser monótono em determinados momentos. Mas retrata muito bem o quando de Jobs a Apple herdou e explica parte do estrondoso sucesso da "empresa da maçã". É um livro sobre o empresário/visionário Steve Jobs.

A grande sacada em ler os dois livros é justamente a possibilidade de esclarecer conceitos. Aliás, esse é o motivo principal da recomendação de duas obras literárias que entregam visões diferentes sobre um mesmo tema: fazer pensar e criar suas próprias conclusões a partir da sua interpretação dos fatos. E interpretação é uma coisa única, diferente para cada um. Tal exercício só enriquece a mente.

Eu mesmo devo dizer que tive várias surpresas. Qual a minha conclusão? Difícil expressar em poucas palavras. Mas uma coisa ficou clara: Jobs não era um gênio inventivo. Ele não inventou nada. Ele era um gênio visionário, que soube como poucos entender quais produtos tinham potencial e como fazer eles caírem no gosto das pessoas. E mais: criou o sucesso. Fez aquilo que é o sonho de todo diretor de Marketing: criar desejo nas pessoas. E embora o Marketing não crie uma necessidade, Jobs chegou bem perto disso, criando mercados para coisas que não existiam e que, de uma hora para outra, viraram essenciais para a vida moderna. Mudou também o cinema, é bom lembrar. Não fosse a Pixar,  estaríamos atrasados em termos de animação. Eu ainda acho que os produtos da Apple precisariam ter tudo aquilo que mencionei no início do texto, mas é fato que mudaram a forma como vivemos hoje. Isso é o suprassumo da inovação: geração de valor, dinheiro.

Todas as lendas de que ele era rígido, chegando a ser FDP em algumas situações, e coisas assim são verdadeiras. Mas ninguém se destaca no mundo fazendo o mesmo que os outros fazem. Ele sempre quis ser diferente. Prefiro dizer que ele era simplesmente um cara dedicado, obstinado, competente, mas imperfeito, como todo ser humano.

Dados dos Livros:
Título: Steve Jobs: A Biografia
Autor: Walter Isaacson
Editora: Companhia das Letras
Páginas: 632

Título: A Cabeça de Steve Jobs
Autor: Leander Kahney
Editora: Agir 
Páginas: 304

Leia Mais

E se o Capitão Nascimento fosse Gerente de Projetos?

Projeto de software é coisa séria. Mas, à medida que passamos um tempo trabalhando com isso, vê-se quase de tudo: desde cenas ou acontecimentos dos quais nos arrependemos de ter presenciado até alguns dos quais simplesmente achamos graça mais tarde. Enfim, histórias não faltam. Personagens sempre aparecem e acabam se tornando ícones da vida real para nós. Uns viram exemplos de trabalho bem feito, outros não. Há algum tempo, quando assistia uma reprise do filme "Tropa de Elite", comecei a pensar sobre muitas cenas que, se traduzidas para o mundo dos projetos corporativos, poderiam facilmente ser identificadas por muitos que trabalham na área. 

À época do lançamento, o filme acentuou um movimento que no Brasil é extremamente comum: a avalanche dos bordões. É impressionante como essas coisas pegam. Nas ruas a gente vê muito isso. É batata: basta um novo bordão aparecer num filme ou no "Zorra Total" ou um novo "artista" lançar um sucesso popular que no dia seguinte estará na boca do povo, sendo usado em diversas situações corriqueiras.

Embora simples, é possível notar que muitas coisas relatadas aqui acabam acontecendo mesmo no dia-a-dia. Logicamente que temos um tom de sarcasmo em muitas das frases a seguir, mas no fundo sabemos que há um pouco de verdade e quase nenhum exagero. Para quem é da área técnica, especialmente desenvolvimento e teste de software, as expressões utilizadas certamente são bem familiares. Prometo que explico para quem não entender, basta solicitar.

Talvez esse post possa não ter um apelo intelectual muito relevante, mas confesso que as frases começaram a surgir na minha cabeça e não consegui evitar. Tudo bem que é um texto bem menos ortodoxo do que os de costume, mas, depois de tantos outros mais sérios, achei que seria interessante postar algo mais descontraído. 

Basicamente, comecei a imaginar como o Capitão Nascimento se comportaria se fosse Gerente de Projetos. As frases a seguir foram baseadas em trechos do filme, facilmente reconhecidos por quem já assistiu. Claro que nem todas as frases utilizadas foram faladas pelo personagem mencionado, mas poderiam ter sido, caso ele tivesse esse cargo. Reservei-me ao direito de usar a censura (em forma de asterisco) para as palavras de baixo calão. 

Como seria a reação dele às diferentes situações de um projeto? Sabendo das suas facetas, tais como seu jeito rude e firme para resolver problemas e sua capacidade de mandar tudo às favas em nome de suas convicções, o que ele faria se estivesse nessa função? Devo dizer que, além de divertido, foi um exercício de reflexão. O resultado desse devaneio você vê a seguir:

O Projeto na Versão Tropa de Elite (Com Cortes):

Approval no “Canetaço”

- Sabe por que você é o zero-um?

- Não senhor!

- Porque você vai ser o 1° a dar o approval nessa m*! Aprova, p*!

- Não senhor!

- Aprova! (tapas na cara)

- Eu aprovo, senhor!

- O zero-um aprovou!

- Êeeeeeeeeeeeeeeeee...

Rodando os Testes - 1
- A essa altura do campeonato e você tá sem o SRS, zero-três?
- Esqueci, senhor!
- Ah, esqueceu? E se um companheiro seu ficar doente durante a fase de testes e precisar que o senhor assuma o lugar dele? Vai fazer o que com esses Casos de Teste? Vai colocar no lixo?
- Não, senhor!
- Vai enfiar no c*?
- Não, senhor!
- Então imprime esse SRS, p*!


Rodando os Testes - 2
- Bom dia filho, queria pedir sua permissão pra revisar a suas tarefas de teste, posso ficar à vontade?
- Sim senhor.
- Zero-quatro, dá uma geral nesse diretório aqui.
- Ihhh, senhor! Olha só o que eu achei... Só esse caso de teste “Não rodado” tem mais "steps" que a escada lá da favela!
- De onde veio esse Caso de Teste, meu filho?
- Eu ganhei, senhor.
- Ganhou não, filho da p*! Perdeu! Tô encaminhando pra outro Testador! Tá demitido! Vambora!

Antes de Iniciar o Deploy

- Os senhores estão bem?

- Sim, senhor!

- Os senhores estão feridos?

- Não, senhor!

- Algum dos senhores está cansado?

- Não, senhor!

- Então hoje vocês vão aprender a carregar TODO o banco de dados global!

Durante o Deploy na madrugada...
- O senhor está dormindo, seu zero-cinco?
- Não, senhor!
- Segura esse Post-Install aqui, seu zero-cinco.
- Mas senhor...
- Seu zero-cinco, se o senhor não segurar esse Post-Install, o senhor vai explodir o projeto, vai explodir seus colegas, o senhor vai ME explodir... O senhor vai deixar esse projeto afundar de novo, seu zero-cinco?
- Não, senhor! Não, senhor!
- Contamos com o senhor, seu zero-cinco!


Uma hora depois do início do Deploy...
- Dezesseis, o senhor é o novo DEV Lead!
- Eu desisto, senhor!
- Fala mais alto, para que todos os seus colegas vejam como o senhor é um fraco!
- EU DESISTO, SENHOR!
- Vocês estão fazendo seu gerente muito feliz!


Na sala de reunião do time de Dev...
- Eu fiz exatamente como o senhor mandou, seu gerente! Mas é que são aqueles filhos da p* da área de testes: eu rejeitava os defeitos e eles reabriam, eu rejeitava e eles reabriam. É a guerra do projeto...
- 50 defeitos de severidade 1 só esse mês em uma mesma aplicação? É muito defeito! Precisamos reduzir número de defeitos já, antes do Go-Live!
- Mas senhor, esses defeitos estão todos com prioridade máxima...
- P* que pariu! Me dá esse relatório aqui! Deixa eu ver... Olha aqui! C*, tem 15 defeitos de recursividade na mesma rotina! Ô Estagiário, tu quer f* comigo? Mais do que um defeito de recursividade tem que ser considerado como duplicado!
- Mas senhor, são todos com combinações diferentes...
- Ô Estagiário, tu por acaso é do Business?
- Não senhor...
- Então faz o que eu tô mandando, pô!


Durante o Post-Install
- Seu zero-dois! Em quanto tempo o senhor acha que dá pra rodar o script de regressão, seu zero-dois?
- Em 10 minutos tá pronto, senhor!
- 10 minutos? Hahaha. O senhor é um fanfarrão, seu zero-dois! Vocês vão ter 10 SE-GUN-DOS pra rodar esse script! E ainda ter que passar sem erro! AGORA!
- Senhor, a ferramenta de automação tá demorando pra rodar o script, senhor! Acho que tem que otimizar, mas eu não sei se consigo, tá muito ruim esse código..
- Tá com nojinho, zero-dois? Tu vai meter a mão e otimizar esse script AGORA!


Após o Post-Install
- Essa p* não é mais minha! Essa p* agora é do Business!



Reunião Final com o Business
- Você aí do Business! Viu quem deu o No-Go aqui?
- Não vi não senhor!
- Viu sim!
- Não vi não senhor!
- Como que não viu se você estava aqui?
- Não vi não!
- Viu sim, pode falar!
- Não vi!
- Fala, filho da p*!
- Foi um de vocês!
- (Tapa na cara) Foi um de nós o c*! Foi você! Você que afundou esse projeto! Você que financia essa m* aqui!



* Adaptação do texto publicado em 08/05/2008 

Leia Mais

Até Quando o Idioma Será uma Barreira?

Semana passada, depois de vários meses pensando e planejando, finalmente iniciei meu curso de mandarim. Isso mesmo. Vou aprender a falar chinês. Tecnicamente falando, será meu quarto idioma, além do português (nativo), inglês (usado no trabalho, diariamente) e espanhol (aprendido por hobby e gosto pessoal, embora não seja fluente, pois não pratico todos os dias). Gosto também de italiano, mas não posso considerá-lo nesta lista, já que e meu conhecimento é apenas superficial e não tenho prática alguma. Quem sabe um dia...

Mas por que escolhi logo o mandarim? Bem, antes de tudo, é preciso entender porque eu quis aprender mais um idioma. 

Eu tenho uma necessidade mental de estar sempre absorvendo conteúdo. Não consigo evitar. Preciso estar aprendendo algo todo dia, senão fico com a sensação de que o dia foi em vão. Por mais que eu goste de futebol, não foram poucas as vezes que deixei de ver um jogo, até mesmo do Inter, para assistir um documentário interessante. Depois da graduação e pós-graduação, é normal você dar um tempo para descansar. Eu não consigo. Se não estou formalmente envolvido com algo, fico lendo, assistindo documentários, fazendo alguma certificação, etc. Mas tem vezes que você sente saudades do ambiente acadêmico ou da interação com colegas em uma turma. E tem a questão da disciplina. É mais fácil assumir um compromisso quando você está pagando por ele. 

Embora ainda receba convites de antigos professores com quem mantenho contato, não me sentia com vontade de encarar um mestrado, dados os horários incompatíveis com minha agenda atual e o nível de dedicação que eu teria de ter e que não é possível hoje, até porque, dar atenção à família é importante também. Sendo assim, achei que aprender um novo idioma se encaixaria nas minhas necessidades de aprendizado versus tempo disponível.

Eu queria tentar algo diferente, que fugisse um pouco das línguas latinas e anglo-saxãs, que são parecidas entre si. Dedicar-me formalmente a aprender Italiano ou Alemão, embora eu tenha curiosidade sobre elas, não me traria aquele ar de novidade total ou talvez não representasse a quebra de paradigma que eu procurava. Resolvi então que aprenderia uma língua oriental. Como japonês, árabe e coreano não possuem um apelo comercial tão significante, a escolha pelo mandarim foi quase que natural. E já nas primeiras aulas eu pude ver que realmente é bem complicado e desafiador. Terei cinco anos bem interessantes pela frente. Comparo o aprendizado de uma nova língua a uma criança aprendendo a falar. Leva uns cinco anos até que ela se expresse corretamente, com fluência, no próprio idioma. E quando ela aprende a escrever, começa com palavras e frases mais simples, até outras mais complexas. Quando se começa a aprender um bnovo idioma, mesmo sendo mais velho, acontece algo bem parecido. Mas devo dizer que gostei bastante e, embora saiba que não vai ser fácil, sei que vou conseguir aprender, porque tenho uma certa facilidade para essas coisas. 

A China é cada vez mais uma potência econômica, devendo ser a maior do planeta em alguns anos. Falar mandarim com certeza vai ser bem útil. Mesmo assim, são poucos os brasileiros que falam. Há mais chineses falando português hoje do que brasileiro falando mandarim. Isso pode ser um ponto a meu favor, lá na frente. Ao menos, eu penso assim. Mas não estou aprendendo só para fins profissionais. Imagino que falando inglês, espanhol e, daqui a uns anos, mandarim, eu possa viver e trabalhar em praticamente qualquer lugar do mundo. Aprender um novo idioma, mais que isso, te dá acesso a toda uma cultura diferente, expande a sua mente. E, como disse Einstein, depois que sua mente se abre para uma nova ideia, ela nunca mais volta ao tamanho original. É isso que encanta. Estar em um país completamente diferente, com outra cultura, outros costumes, outro jeito de viver e conseguir se comunicar com as pessoas é algo mágico. 

Embora tenha usado meu humilde exemplo como base para ilustração, o assunto principal deste post não sou eu. A questão aqui é o aprendizado de uma língua estrangeira, que, por incrível que pareça, ainda é um tabu no Brasil. E digo que ainda é um tabu por dois motivos:

1 - O Brasil não tem um segundo idioma, nem oficial, nem extraoficial. É o português e pronto. Uma segunda língua não é disseminada decentemente, nem na escola. O inglês transmitido nos ensinos fundamental e médio raramente vai além do  "verb to be", por exemplo. Na Europa é comum países com dois idiomas oficiais. E naqueles onde há só uma língua nativa, não é tão difícil encontrar alguém que fale inglês. Lógico que há exceções e resistências, mas o default é você conseguir falar inglês na maioria dos países do velho continente. 

2 - Talvez o Brasil esteja vivendo o seu melhor momento no cenário mundial em toda a história. Hoje todo o mundo sabe que o Brasil existe e que a Capital Federal não é Buenos Aires. Era de se esperar que as pessoas estivessem mais preparadas e mais gente estivesse falando outro idioma, visto que o trabalho, assim como os negócios, está cada vez menos separado pela geografia. Mas os que falam outra língua ainda são poucos, se considerarmos uma população de 200 milhões de habitantes. Talvez China e EUA possam se dar ao luxo (por enquanto), de terem apenas uma língua oficial (se bem que na China há diversos dialetos e nos EUA há muitos latinos falando Espanhol, mas vamos nos ater à questão mais comercial da coisa), pois são as maiores economias e seus idiomas são os mais falados. Logo, ditam as regras. Mas não é o nosso caso. Tomara que um dia seja. Já pensou todo mundo aprendendo português?

Essa questão do idioma fica mais clara quando vejo as dificuldades encontradas pelo RH aqui na empresa. Muitas vagas levam meses para serem preenchidas ou acabam sendo canceladas porque os candidatos não tem um nível de inglês adequado, mesmo que sejam bons tecnicamente. Como a maioria dos grandes projetos e clientes da empresa estão nos EUA, esse é um skill importantíssimo, ainda mais pela interação diária, inerente ao trabalho. Até na sede de São Paulo, maior mercado do país para profissionais de TI, o RH encontra dificuldades semelhantes. Eu achava que isso já tinha mudado, mas, pelo visto, ainda há um longo caminho a ser percorrido. Sinceramente, já passou da hora dos profissionais procurarem essa qualificação. 

Além de tudo isso, estamos às vésperas de uma Copa do Mundo e uma Olimpíada. Como vamos atender os turistas? É sabido que a maioria deles vai usar o inglês para se comunicar. Nossos taxistas, lojistas e demais prestadores de serviços estão preparados? Talvez só a rede hoteleira esteja, e olhe lá. Nas demais áreas, eu creio que estamos longe disso. Basta ir até a rodoviária ou ao aeroporto para ver o tamanho da deficiência e do despreparo em relação a essa questão. 

Claro que tem bem mais gente falando inglês no Brasil hoje do que há 10 ou 15 anos, mas ainda há menos do que seria preciso. Acho que avançamos em passos lentos neste ponto. Talvez a educação não tenha conseguido acompanhar o ritmo do crescimento econômico. Mas há também o fator interesse. Quem quer, sempre dá um jeito. Escolas de idiomas estão por aí aos milhares. Minha esperança é que a Copa e as Olimpíadas possam mudar um pouco as coisas, que deixem um legado além das obras físicas. Mas o bom mesmo era que as coisas mudassem antes, para já estarmos preparados, não só para os eventos esportivos citados, mas para os próximos anos de crescimento pelos quais o país tende a passar. O problema é que o Brasil tende a funcionar de maneira reativa, não proativa. As coisas até tem andado, mas às vezes só andam na base do “pegando no tranco”.

Minha dica é começar o quanto antes. Colocar seu filho numa escola de idiomas ainda na infância certamente o ajudará depois, seja lá qual for a carreira que ele queira seguir. Mas atenção: criança tem de brincar também, não se pode transformá-la em uma máquina de estudar, mas é importante ela saber o quão útil isso pode ser. Na adolescência também é útil, mas é mais complicado, dadas as rebeldias que a idade trás consigo. A vantagem é que, quanto mais novo, mais fácil é para se aprender uma nova língua. É assim nos países desenvolvidos: os idiomas adicionais são aprendidos na infância. É uma mudança de cultura, sem dúvida. Mas eu acho que seus filhos agradecerão mais tarde.

Leia Mais

O Índio e o Executivo

Quando você pensa em um grande zagueiro da história do Internacional, que nome lhe vem à cabeça? O grande Dom Elias Ricardo Figueroa Brander, campeão brasileiro de 1975, autor do "gol iluminado" na final daquele ano contra o Cruzeiro e referência técnica para muitos até hoje?  Ou quem sabe Carlos Alberto Gamarra Pavón, que já foi considerado o melhor zagueiro do mundo, dono de uma incrível habilidade de roubar a bola sem fazer falta (chegou a jogar uma Copa do Mundo inteira sem fazer uma falta sequer)?

Para mim, nenhum dos dois. Que me perdoem os saudosistas, mas o maior zagueiro da história do Sport Club Internacional não fala castelhano. Ele atende pelo nome de Marcos Antônio de Lima, ou, simplesmente, Índio.

Não há como questionar os seus números. Além se ser um dos zagueiros que mais vezes vestiu a camisa Colorada, é o que mais gols marcou, inclusive em Grenais. Um verdadeiro terror para os lados da Azenha/Humaitá. Mas é nos títulos conquistados que Índio comprova, com sobras, a minha tese: desde que chegou ao Inter, em 2005, foram 4 Campeonatos Gaúchos, 2 Libertadores, 1 Mundial FIFA, 1 Copa Sul-Aamericana, 2 Recopas e 1 Copa Suruga. Isso só para citar torneios oficiais. Ainda teve a Dubai Cup, que era torneio amistoso, mas que tinha participação de outros gigantes de futebol mundial. E poderia ter sido ainda melhor, não fossem os diversos vice-campeonatos que ocorreram durante o caminho. 

Sozinho, ele tem mais títulos que a maioria dos clubes Sul-Americanos. Isso não é pouca coisa. É provável que até a sua aposentadoria eu tenha de atualizar os números deste post.  

Atualizado em 14/05/2012: Agora são 5 Campeonatos Gaúchos

Atualizado em 05/05/2013: Agora são 6 Campeonatos Gaúchos

Atualizado em 13/04/2014: Agora são 7 Campeonatos Gaúchos

Com todo o respeito, Figueroa e Gamarra não ganharam nada, se comparados com Índio.

Todo colorado se lembra da imagem emblemática de Índio sangrando em campo durante a final do Mundial de 2006, contra o poderoso Barcelona, após ter sido atingido pelo colega Fabiano Eller numa disputa de bola pelo alto. Jogou o resto da partida com o nariz quebrado. Poucos minutos depois, iniciava a jogada que terminaria com o gol do título.

Mas há ainda algumas lições pessoais e profissionais que podemos aprender com Índio. Analisando a sua carreira até aqui, eu percebi algumas características que poderiam até servir de exemplo para executivos, gerentes, líderes ou demais cargos estratégicos que compõem uma empresa. Figuras como a do executivo são frequentemente associadas às tomadas de decisões. Por eles passa o futuro das organizações. Essas decisões são embasadas por diversos fatores, mas nem sempre explicada pelos mesmos. Em muitos casos, é possível perceber e entender claramente as decisões apenas analisando o perfil daqueles que as tomaram.

Deixo claro é que apenas um exercício de percepção, sem nenhum comprometimento direto com teorias acadêmicas, mas que, nem por isso, as deixam totalmente de lado. Listo algumas das características mencionadas a seguir: 

Resiliência e Perseverança: Já perto dos 40 anos, mas ainda em atividade, não são poucas as críticas que recebeu. Todos os anos ele é apontado como sendo velho para o futebol. E todos os anos ele levanta uma taça, sempre jogando bem. Tem períodos de baixa, como todo atleta profissional, mas sempre dá a volta por cima. Não desanima com as dificuldades e com as pancadas que recebe. Se ele passa um tempo no banco de reservas, trabalha para voltar ao time. E sempre volta, sempre consegue se superar.

É comum encontrarmos dificuldades e tomarmos pancadas durante a vida profissional. O que vai fazer você se diferenciar é justamente a capacidade de reação a essas adversidades. Esse detalhe pode significar um sucesso futuro ou um fracasso imediato, dependendo da sua escolha. Insistir naquilo que você acredita nem sempre é sinal de teimosia. Pode fazer muitas pessoas se surpreenderem com seus resultados, especialmente quando quase ninguém mais acreditava em você.

Capacidade de Adaptação: Depois de certa idade, se um jogador pretende continuar apresentando um futebol de alto nível, tem de aprender a mudar seus hábitos e, principalmente, redobrar os cuidados com sua forma. Índio aprendeu. Não por acaso é um dos mais elogiados pelos preparadores físicos a cada começo de temporada. Recebeu o apelido de “interminável” porque, mesmo com a idade, parece continuar correndo como um guri. Sabe que não pode ter mais o mesmo vigor de um jovem, então procura compensar isso tendo mais disciplina e cuidados extracampo.

Talvez a questão de manter-se atualizado sempre seja um dos maiores clichês do mercado de trabalho moderno. Porém, para uma posição de liderança, especialmente aquelas que lidam com grandes responsabilidades, isso se faz necessário. Saber “ler” o mercado, estar atento ao que acontece à concorrência e mudar os planos ou definir novos projetos é parte do jogo. Aprender um novo idioma para negociar com outros países ou lidar com uma nova tecnologia são fundamentais para manter você, ao menos, competitivo, mesmo depois de uma carreira já consolidada. Se a idade chegou, não deixe que ela limite sua capacidade ou reduza sua vontade de aprender. Deve-se utilizar a experiência adquirida para encontrar os “atalhos do campo”.

Foco: Não existe jogador de futebol santo. Todos aprontam alguma coisa na sua vida pessoal. Índio nunca foi conhecido como boêmio (baladeiro, pra usar uma expressão mais atual), mas já protagonizou episódios polêmicos fora das quatro linhas. Certa vez, foi muito criticado por chegar a um treino com um corte na mão, fato que o deixou alguns dias sem poder jogar. Se o corte foi feito durante os excessos de uma festa ou se foi um acidente doméstico, não importa. Ao contrário de tantos outros jogadores que vemos por aí, cuja vida pessoal aparece mais do que o futebol mostrado em campo, ele evitou polêmicas, seguiu calado, baixou a cabeça e continuou trabalhando duro, intensamente. O assunto se encerrou em poucos dias. E os bons resultados continuaram a vir mais tarde.

Saber realmente o que se quer, onde se pretende chegar e o que é preciso fazer para conseguir isso é o que diferencia as pessoas de sucesso das demais. Não dá pra ignorar os erros e fatores externos que se apresentam no caminho, há de se saber conviver com eles. Mais do que isso: deve-se aprender a minimizar possíveis impactos negativos trazidos por eles e que tendam a desviar você dos seus objetivos. Estratégias de Marketing tem mais sucesso quando estão segmentadas corretamente; objetivos empresariais são mais facilmente atingidos quando se tem um rumo a seguir. Defina o seu foco e trabalhe duro nele. Dificuldades fazem parte do caminho, mas não podem ser o fator determinante.

Humildade: Antes de ser jogador de futebol, Índio era cortador de cana, homem humilde. Não passou por categorias de base. Foi direto da várzea ao profissional. Mas sua humildade não ficou restrita às suas origens. Quando marcou seu 27º gol pelo Inter (hoje já são mais de 30), ultrapassando a marca do lendário Figueroa, Índio, sem querer, acabou fornecendo uma das explicações do seu sucesso no clube. Ao final do jogo, um repórter veio ao seu encontro e lhe perguntou como era a sensação de entrar para a história, ultrapassando justamente um ídolo da torcida. Ele respondeu dizendo: "Eu sou um mero coadjuvante, um simples trabalhador. Ultrapassar em gols o Figueroa me enche de alegria". Ainda viria mais. Como já disse, Índio tornou-se o zagueiro que mais marcou gols na história do Inter. Mesmo com toda a carga histórica do feito, com todas as conquistas que teve, ele ainda se considerava coadjuvante. Sempre foi jogador de exaltar o grupo. Sabe que nada se consegue sozinho. Mesmo estando no topo, ainda quer mais. Acha que pode mais. Quer aprender mais. 

Muita gente confunde humildade com “se fazer de coitado”. Isso é um erro. Ser humilde consiste, acima de tudo, em saber de suas limitações e ter certeza de que não se sabe de tudo; de que sempre há o que aprender e que se deve estar disposto a isso. É também saber respeitar outras pessoas que estão ao seu redor, afinal, você nunca está sozinho, seja em família, seja no trabalho. Assim como comentei sobre estar sempre atualizado e preparado, é igualmente importante ter em mente que você não é perfeito e nem soberano. Trabalhar em equipe requer lidar com pessoas diferentes, com anseios diferentes e com habilidades diferentes, não inferiores.

Todas essas pequenas lições acima são apenas uma forma de demonstrar como sempre é possível obter bons e úteis exemplos das coisas mais simples e distintas. Quando você imaginaria que a história de um ídolo do futebol poderia fornecer contribuições para o uso no dia-a-dia do seu trabalho? Talvez se você olhar apenas com os olhos de torcedor rival, isso não lhe acrescente muito. Mas olhando com os olhos de profissional e de ser humano, tenho certeza de que há muita coisa a ser aproveitada, ou, ao menos, que possa servir como reflexão para a forma como você está agindo no seu trabalho. Talvez o ponto principal aqui seja: não importam as dificuldades que possam aparecer, você sempre pode ser um vencedor. Basta querer e trabalhar muito para isso.

Leia Mais