Usando Working Sets no Eclipse

Quem não tem mais de uma workspace do Eclipse que levante a mão. Alguém!? Alguém!? Tenho certeza que todos que trabalham com o Eclipse há algum tempo, por mais organizado que seja já se pegou gerenciando duas, três, quatro ou mais workspaces.

Isso sempre foi um problema pra mim, especialmente pelo modo que o Eclipse gerencia suas configurações, que são particulares para cada workspace. Isso é bom, é um modelo legal e funciona super bem. Não era bom pra mim pois eu estava teimando em usar as workspaces de forma errada, então eu sempre tive um sério problema com as configurações, pois elas estavam sempre diferentes entre cada workspace.

Eu sempre tentei separar os projetos por clientes, por área de interesse ou por atividade. Uma workspace de projetos open source, outra do cliente ABC, outra do cliente XPTO, outra de projetos que eu estava estudando o código e assim por diante. Os problemas na hora de trabalhar eram vários, por exemplo: um repositório criado numa workspace era só dela, um atalho configurado na outra ficava só lá, um bookmark também, ou templates de código também. Resumindo, a bagunça ficava gigante e a redundância de configurações então nem se fala.

Então resolvi jogar tudo pra uma workspace só. Problema resolvido!? O das configurações sim, mas de brinde ganhei um novo: performance. Outro hábito não muito bom que eu tenho é o de manter todos os projetos abertos. São tantos projetos (141 atualmente) que só pra abrir o Eclipse demorava muito tempo. Depois, pra abrir/buscar um tipo (CMD+SHFIT+T), por exemplo, demorava de mais para indexar, limpar a workspace então nem pensar. A solução que eu encontrei foram as Working Sets, um recurso que sempre esteve ali presente e eu nunca dei bola.

As Working Sets são grupos de trabalho que podem concentrar um ou mais projetos e funcionam como se fossem várias workspaces. No meu caso as working sets caíram como uma luva para a minha antiga distribuição de workspaces. Ao invés de usar várias workspaces por clientes, agora mantenho uma única workspace com várias working sets, algumas de clientes, outras de estudo, etc. Isso resolveu o meu problema de configurações completamente e com as working sets eu posso escolher em que vou trabalhar num determinado momento e ver somente aqueles projetos, resolvendo também o problema de performance.

E para quem quiser usar as working sets, seguem algumas dicas.

Ativando a visualização por working sets

O passo essencial é trocar a visualização de Projetos para Working Sets, isso é bem simples. Veja a imagem a seguir:

eclipse_ativar_working_sets

Gerenciando suas working sets

No próximo passo você deverá criar as suas working sets e associar cada uma delas com os projetos que quiser.

eclipse_visualizando_working_sets

Crie, modifique ou remova qualquer working set.

eclipse_gerenciando_working_sets

Trabalho feito, agora basta escolher em qual working set quer trabalhar e pronto, paz e sossego.

eclipse_go_into_working_set

Lembre-se que você pode optar por fechar ou abrir todos os projetos de uma working set bem como “ir e voltar” para qualquer uma delas.

Escopo, o inimigo do sucesso

Os grandes e temidos arquitetos de sistemas adoram quando precisam especificar um escopo de um grande projeto, geralmente este trabalho é tido como o supra-sumo da empresa, onde somente o melhor dos melhores pode executar, onde a responsabilidade de sucesso ou fracasso está em jogo e no entender da empresa nada deve ser apressado, o arquiteto precisa de tempo para pensar em todos os detalhes, de todos os recursos que precisar para esmiuçar o escopo ao máximo, pensar em tudo que o cliente irá desejar, tudo mesmo.

O que muitos não vêem é que, com isso, a receita para o fracasso já está praticamente concluída. O trabalho e esforço de semanas ou até meses onde o arquiteto deu tudo de si, não passa, simplesmente, da pura arte da adivinhação, de previsão do futuro, de achismo e nada mais. O que ele achou que o cliente desejaria, o tempo que ele achou que iria demorar, os prazos que ele tirou da cartola e os resultados que ele sonhou acontecer dificilmente serão alcançados. Isso não acontece por falta de capacidade do arquiteto, pelo contrário, em alguns casos ele é realmente O cara da empresa e possuidor de vasta experiência, mas tentar prever o futuro não é uma ciência exata.

Apenas uma observação aqui: Não sou contra o levantamento de requisitos e especificação de escopo, pelo contrário, acho que é um trabalho de extrema importância, apenas não concordo com a forma que este trabalho é feito na grande maioria dos projetos, onde o pensamento e a organização em cascata impera.

O fracasso numa situação dessas poderá vir quando o cliente, no meio do projeto, resolver mudar tudo. O arquiteto terá que trabalhar mais alguns meses em um novo escopo? O cliente entenderá que deverá pagar por mais alguns meses de replanejamento de escopo? Como o seu escopo reagirá a mudanças, ele foi preparado para isso?

Ou quando ao final do projeto, somente ao final do projeto, uma versão usável for apresentada ao cliente e ele achar que você se enganou e apresentou a solução de um outro cliente a ele, tamanha a discrepância entre as expectativas do cliente e da empresa. E agora, como fica a situação? Inicia-se um novo projeto!? E quem pagará por isso?

Ou no pior dos casos, durante o desenvolvimento do projeto vê-se que o que o arquiteto previu para 10 meses de trabalho com uma equipe de 5 pessoas estava completamente furado, você vai precisar de 20 meses. Então qual é a brilhante ideia? Aposto a minha sacola de mendorato: “- Vamos dobrar a equipe, com 10 pessoas conseguiremos diminuir o prazo pela metade e assim ficaremos dentro do esperado”. É tiro-e-queda, será um grande fracasso. Ter um escopo flexível e incremental seria muito melhor do que incrementar a equipe para seguir o escopo. Afinal de contas, desde quando nove mulheres juntas são capazes de gerar um filho em um mês? Manusear prazos, expectativas e custos de um produto desta forma, definitivamente não dá certo.

Existe ainda um outro lado, aquelas pessoas que não querem se preocupar com problemas de escopo, que não querem ter problemas ao final do projeto se tiverem que discutir com o cliente sobre determinada funcionalidade está certa ou errada ou se deveria existir ou não, estas pessoas são as adeptas do escopo fixo.

Eu costumo dizer que, em projetos com escopo fixo só têm uma certeza: ele irá fracassar!

O fracasso nestes projetos não precisa ser necessariamente a não entrega do produto. Isso quase sempre acontece, mas milagres podem acontecer e o projeto pode ser concluído e entregue no tempo, mas ainda assim será um fracasso. Será um fracasso para o seu cliente, que demandou o projeto. Assim como dois mais dois são quatro, eu aposto o meu mendorato de novo que o seu cliente certamente mudou de idéia em vários pontos durante o desenvolvimento do projeto, mas você, esperto que é, já tinha o seu escopo fixo e para não sacrificar a “entrega” e seguir o maldito escopo, esfregou na cara do seu cliente que ele não poderia mudar nada, que ele não tinha esse direito, que estava escrito no escopo assim como é gravado em pedra e nada daquilo poderia mudar, em hipótese alguma, e mais, se ele fosse teimoso e insistisse em mudar teria uma saborosa multa à sua espera.

Sem dúvida esse cliente não estará com você num próximo projeto. Este é um tipo de fracasso que é muito pior que o anterior, certamente. Seria preferível não entregar tudo o que estava no escopo, renegociar o escopo, incrementá-lo ou decrementá-lo, mas entregar tudo o que o cliente pediu durante o projeto do que ignorar e trocar a sua opinião por um documento que foi feito em alguns dias ou horas numa tentativa de prever o futuro, que acaba quase sempre de modo frustrante para ambas as partes – para a empresa que trabalha desta forma, nem tanto, pois a essa altura ela já terá recebido todo o orçamento do projeto.

Trabalhar com o escopo de forma iterativa e incremental não é nenhum bicho de sete cabeças, seu pescoço não estará na corda desde que todas as expectativas estejam alinhadas, insira o seu cliente no projeto, faça-o participar de todas as etapas e ele mesmo verá e terá consciência de que em determinados pontos o escopo precisa mesmo ser alterado – para mais ou para menos. Aprenda a negociar e gerenciar expectativas com o cliente e o escopo passará a ser o grande amigo do seu projeto.

Além dos links dos artigos no último parágrafo, o Manoel Pimentel disponibilizou uma ótima apresentação sobre Gestão de Requisitos através de práticas Ágeis e Enxutas, que mostra extamente algumas das formas de se trabalhar com escopo incremental e iterativo.

Tentar ou continuar na mesma?

Qualquer tipo de mudança na organização e pseudo-metodologias de desenvolvimento de qualquer empresa de tecnologia costuma ser um grande pesadelo. Isso é assim por vários motivos.

Geralmente os gerentes e diretores (na maioria das vezes) serão duros e contra qualquer tipo de mudança simplesmente pelo fato de a empresa ter gastado centenas de milhares de dinheiros, logo, pensarão por muito tempo que isso (metodologia customizada) deverá dar algum resultado, o que acaba não acontecendo na maioria da vezes. Essa negligência e fraqueza em assumir logo o prejuízo e tentar mudar – para melhor – acaba acarretando em prejuízos muito maiores no futuro, demissões em larga escala, troca de diretoria e por aí vai, já vi isso antes.

Outra justificativa muito usada para evitar mudanças será a falácia de que “em time que está ganhando não se mexe. Grande parte das vezes falta coragem ou maturidade para enxergar que o time não está ganhando e que precisa ser modificado, sim. Também não é incomum encontrar situações onde a mudança não é vista com bons olhos pois as metodologias pra inglês ver, as certificações (de parede) e demais honrarias são mais valorizadas do que às pessoas e o produto que a organização entrega, então, nesses casos pouca importa se está bom ou ruim.

Mas onde eu quero chegar com esse post? Todas estas situações que falei até agora são conhecidas pela maioria dos desenvolvedores e sabemos que são situações difíceis de serem vencidas, eu mesmo já fracassei em algumas tentativas de mudança diante de tais situações e felizmente já obtive muitos sucessos também.

Recentemente, almoçando com um grande amigo acabamos caindo no papo sobre as nossas empresas e clientes e falamos sobre um caso em especial. Um cliente em que já haviámos trabalhado, onde enfrentamos todas aquelas situações anteriores de uma só vez – acreditem! – continuava na mesma. Com os mesmos problemas de sempre (atraso), mesmos gerentes/diretores e as mesmas pseudo-metodologias e regras internas, a única coisa que não era a mesma eram os clientes, nem preciso dizer o porque.

Mas a disucssão não chegou a ser prática ao ponto de “seja ágil”, “você precisa praticar TDD/BDD”, “agarre-se ao PMBok” ou “se você não aderir ao Scrum não vai ter jeito”, nada disso, não estávamos questionando a metodologia, nem as regras em si, mas sim a resistência em mudar. Fazendo uma breve retrospectiva vimos que 100% dos últimos projetos não haviam sido entregues na data prevista, desses 100%, 100% tiveram o orçamento o estourado e, desses 100%, 100% não atenderam a todas as expectativas do cliente e foram entregues com features a quem do esperado.

Diante de um cenário como esse, por que não deveríamos tentar mudar? Por que não tentar fazer alguma coisa diferente? Se estamos “sendo ágeis com scrum+xp” por que não tentar um modelo mais lento!? Se o RUP/MPS.Br/QualquerCoisa não está dando certo, por que não mudar e tentar outro? Se as metodologias e regras internas não estão sendo suficientes, por que não deveríamos tentar outra? Com um histórico de atrasos e fracassos, o que poderia acontecer de pior, atrasar 9 semanas ao invés de apenas 7!?

Não fique na mesma por muito tempo, mesmo que o seu time esteja ganhando e esteja realmente na frente, experimente mudar, tente melhorar, evoluir. Avalie sempre não só as mudanças, mas veja o que elas poderão fazer por sua organização, por seus projetos, se algo pode ser melhorado, vá em frente, se algo pode piorar, avalie o seu presente e passado e veja se vai, de fato, piorar, ou se você já estava “na pior” e não estava se dando conta. Não seja cético correndo atrás do que está na moda, na crista da onda, isso nem sempre será bom pra você, mas procure sempre avaliar sua situação e ver o que você pode tentar melhorar e o que pode, sem prejuízos, continuar na mesma.

E a qualidade, como você garante?

Durante minhas apresentações sobre Testes de Software existem algumas perguntas que são clássicas, sempre fazem no mínimo uma delas. Por exemplo:

  • Mas com testes, demora mais?
  • E se demora mais, não fica mais caro?
  • E se demora mais e fica mais caro, por que testar?
  • Como eu vou mostrar para o meu cliente um relatório de execução de testes? Pirou!?

Pra quase todas eu respondo sim. Sim, simplesmente escrevendo testes ou trabalhando com TDD/BDD é um pouco mais demorado (medindo exclusivamente em tempo) sim, principalmente no começo de um projeto. Podemos pensar que se demora mais, inicialmente, também fica mais caro, afinal de contas, tempo é dinheiro. Mas depois deste movimento inicial e saindo da inércia o fator de tempo se inverte e o desenvolvimento no projeto torna-se mais rápido e mais barato. Assim como a manutenção do projeto.

Após responder sim para esses questionamentos, intencionalmente, eu inicio a discussão com uma pergunta, desta vez sou eu quem pergunto ao congressista: Como você garante a qualidade do seu produto?

Eis que então abro as portas para chegar no ponto principal desta apresentação sobre Testes de Software, conscientizar as pessoas de que é necessário testar, pois, esta é a forma menos dolorosa para mantermos não só a qualidade, mas também a vida dos nossos produtos. Mesmo assim eu sempre tomo cuidado para não vender a idéia de que testes são a solução pra tudo, muito menos que pelo simples fato de escrever testes para todas as funcionalidades do seu sistema que ele não terá bugs ou problemas, muito pelo contrário. Mas então por que testar? Pois até hoje, testar é a forma mais barata e eficiente que encontramos para evitar que os problemas cheguem ao cliente/usuário. Eis então aí a qualidade do seu produto. E quando eu deixo de falar em “testes” para falar de “qualidade” eu consigo a atenção de todos, inclusive de quem não irá escrever testes, mas quem decidirá se o desenvolvedor terá espaço para escrever testes ou não, os gestores/líderes.

Geralmente quando você não escreve testes qual é a forma utilizada para garantir que o que será entregue ao cliente está funcionando de acordo com o que foi especificado (comportamento)? Não sabe responder!? Bom, então como você faz para garantir que o produto ao menos funciona, esqueça aqui o modelo de negócios, as telas ao menos abrem? O usuário não vai receber nenhuma NullPointerException na cara? Também não sabe responder!? Não tem segurança para responder!? Não fique triste, infelizmente tem muita gente na mesma situação que a sua.

Na maioria das vezes os projetos de software começam com funcionalidades e datas de entrega pré-definidas, contratos rígidos, multas astronômicas, e o pior, fases pré-definidas: requisitos de sistemas, requisitos de software, análise, design, codificação, testes e implantação. Acho que não preciso falar muito do modelo em cascata, o que todos sabemos é que as fases iniciais sempre são feitas pelos “analistas de sistemas” da empresa, na maior moleza gastando mais da metade do tempo e verba do projeto sem gerar nada de útil para o desenvolvimento. O que acontece? Os desenvolvedores simplesmente chutarão os testes (e muitas outras coisas) pois: – não temos tempo agora; – depois eu testo; – a entrega é daqui a 15 dias; – está funcionando sem testes. E o pior, tentarão justificar a ausência de testes devido a este modelo cultural e organizacional falho.

Então o projeto, de fato, começa. Mas e os releases, como ficam? Como você garante que o que será entregue ao seu cliente está funcionando? E que está atendendo a tudo que ele especificou? (estou me repetindo, eu sei, mas é por uma boa causa). Melhor, se sua equipe trabalhou na correção de um bug ou na implementação de uma nova feature, como você garante que o que foi feito está ok e que todo o restante continua funcionando como antes? Certamente o seu cliente não espera que você entregue um relatório de execução da sua suite de testes, mas ele também não espera que você entregue um certificado de garantia ou algo parecido, ele simplesmente confia em você e espera que você faça por merecer.

E você no começo faz questão de parar um desenvolvedor ou analista para testar a funcionalidade que está sendo desenvolvida, ele executa a aplicação, faz um caso que funciona e outro que não funciona, te responde ok em cerca de 45 minutos. Passam-se alguns dias e já existem 5 funcionalidades, o mesmo desenvolvedor vai testar e te da ok em cerca de 4 horas ou mais. Mais algumas semanas e ele já não testa mais todos os casos, só os que funcionam e eventualmente pula uma ou outra funcionalidade pra terminar os testes mais rapidamente, depois de 3 dias ou mais ele te da o ok. Imagine depois que o sistema estiver grande (é mania das empresas querer fazer sistemas gigantes), você vai parar um desenvolvedor por duas semanas ou mais para testar? Ou você vai manter uma equipe de “testadores”? E como você vai explicar as regras de negócio de um sistema de controle de transações comerciais para 5 ou 6 novos funcionários para depois testarem o seu produto? Será que eles saberão o que fazer e como fazer? Pense em muitos problemas aqui.

Essa prática é demorada. Se acontecer (e vai acontecer) um problema seríssimo em produção e você precisar corrigir e entregar rápido, no mesmo dia, como você vai fazer para testar todo o resto do sistema em algumas horas? Certamente você vai pensar (e rezar) que esta alteração foi pontual e que não afetará mais nada no sistema e vai entregar sem testar. Se as novas solicitações forem de features pequenas você não vai querer testar todo o sistema, não vai se preocupar em fazer um teste de regressão, e vai, novamente, rezar e fazer promessas acreditando nos poderes sobrenaturais dos seus desenvolvedores. E o pior é que se alguma vez isso funcionar, esta poderá se tornar uma prática comum na empresa: alterou; compilou? Então está pronto, pode entregar ao cliente.

Se você precisar economizar ou cortar custos, a primeira equipe a dançar será a de “testadores” ou se ela não existir, será o tempo gasto pelo desenvolvedor que fazia os testes manuais. E com isso você não cortará somente custos, nesta altura do campeonato este é o seu menor problema, ou deveria ser a sua menor preocupação, você estará cortando diretamente a qualidade do seu produto! E sem qualidade a confiança que o seu cliente tem em você começará a diminuir, a imagem da sua empresa junto ao cliente começará a perder o brilho e num determinado momento o cliente se dará conta que você entregou o produto em 4 meses e está a 2 anos tentando deixá-lo totalmente funcional, sem muito sucesso.

Não são somente os testes automatizados que irão garantir a qualidade do seu produto, você tem outras alternativas e a mais conhecida são os testes manuais feitos pelo desenvolvedor ou por sua equipe de testadores, porém esta não é uma alternativa barata e nem rápida, isso não é sustentável ao longo da vida de um projeto.

Se você e seu cliente não se importam em esperar 15 dias para uma release sair, tudo bem, não escreva testes; se você não se importa com o alto custo de manter uma dúzia de pessoas para preencher campos e dar ok, tudo bem, continue sem testes; se o seu cliente te paga 5 vezes mais para fazer o produto funcionar do que o ele pagou para ter o produto, tudo bem também, continue sem testes; ou se os seus desenvolvedores são especiais e possuem poderes além da nossa compreensão e isto permite que você não teste, ótimo, você é um sortudo, pode continuar assim. Se alguma forma sem testes automatizados funciona pra você e você consegue garantir qualidade assim e ainda consegue ser uma organização lucrativa, sorte a sua (e coitado do seu cliente). Só que as coisas nem sempre são assim.

Você deve verificar o seu código, sempre! Você deve testar rápido, pois precisa entregar rápido. Você deve ter segurança para alterar, pois sua equipe pode ser nova ou com pessoas que não conhecem o projeto. Você precisa testar tudo o que foi alterado e todo o resto para saber se algo não deixou de funcionar com alguma alteração. E você precisa fazer tudo isso pra ontem, afinal, você está no mesmo planeta que o resto das pessoas.

Se no início do projeto você tivesse feito o que era necessário, se tivesse investido em testes e automatizado todos eles, após a entrega do produto você poderia dedicar os próximos 2 anos que iria passar dando manutenção em código legado (lembre-se que código sem testes já nasce legado) prospectando novos clientes e projetos. Se aqueles minutinhos para escrever os testes não tivessem sido cortados, hoje, quando o produto tiver milhões de linhas de código e centenas de funcionalidades, após uma alteração qualquer, feita por um estagiário que chegou ontem e nem conhece o produto, você conseguirá saber em questão de minutos (ou no máximo horas) o resultado e impacto desta alteração, com um simples click você saberá se pode entregar a release para o cliente, ou não.

Ao final do projeto, sim, este projeto terá um fim e será concluído de verdade, aquele tempinho que parecia estar sendo perdido com testes, pensando que testar uma funcionalidade antes mesmo dela existir é coisa de maluco, pensando que o melhor a se fazer é correr e correr e correr pra entregar logo qualquer coisa ao cliente, tudo isso vai se converter num ganho inestimável para sua organização, você poderá desenvolver novas features, trabalhar em outros projetos ou clientes, movimentar as pessoas entre as equipes, contratar gente nova e inseri-los rapidamente no ‘ritmo’ de trabalho, e o melhor de tudo, o seu cliente manterá a confiança em você, na sua organização e no seu trabalho.

Então, Assim eu termino a discussão: – É mais rápido entregar um produto em 3 meses e levar mais 24 meses ajustando-o para o tornar funcional ou é mais rápido entregá-lo em 4 meses? Ou entregá-lo em 3 meses com menos funcionalidades? – É mais barato arriscar a imagem e confiabilidade da sua organização entregando algo sem qualidade ou é mais barato escrever e automatizar testes?

Formando-se Líder

Algumas coisas vêm e vão sem termos muitas opção de escolha ou poder definitivo sobre elas, como a idade por exemplo, maldita idade, estou ficando cada vez mais velho e não posso evitar isso, seria bem interessante congelar a idade nos 21 ou 22 anos, seria magnífico. Brincadeiras a parte, assim como a idade, a posição que ocupamos numa organização, nosso emprego e o papel que desempenhamos irá mudar, irá evoluir ou retroceder, por méritos do nosso trabalho, por desejo de evolução ou até mesmo simplesmente por acomodação e paciência pra esperar o tempo passar diante de nossos olhos, a certeza é que as oportunidades – assim como a idade – vêm e vão e caberá a nós estarmos preparados para agarra-las ou para recusá-las.

A verdade é que com o tempo, evolução pessoal, crescimento e maturidade, experiência técnica e profissional estarão sendo agregadas constantemente em todos nós, em nosso perfil, e precisamos ser capazes de identificar o momento correto para realizar uma mudança e saber quando estamos deixando de ser importantes em uma área ou função para ser mais importante em outra área ou função, aplicando esse novo conhecimento adquirido.

Pensando exatamente nisso, não exatamente só por pensar nisso, mas dado a diversos outros fatores que também me desmotivaram, comecei a fazer um tipo de auto análise e observação diária do meu trabalho, atitudes e de como estava resolvendo as coisas, agregado com isso comecei a ler sobre o assunto (liderança) e pra minha surpresa identifiquei vários pontos entre a minha real e atual situação com a minha primeira leitura nessa área: Know-How, de Ram Charan. Este post não é uma propaganda do livro, obviamente. Mas quem quiser comprar eu aconselho fortemente. Empolgado com o assunto estou lendo atualmente The World’s Most Powerful Leadership Principle: How to Become a Servant Leader, do mesmo autor do conhecido Monge e o Executivo, James C. Hunter, (que já estou gostando muito, do livro) e Moments of Truth, de Jan Carlzon.

Com base no último livro que li, e seguindo as premissas do próprio, tomei a liberdade de resumir as oito competências que todo líder deve ter, ou pelo menos saber como praticá-las com perfeição e habilidade:

  • Posicionar e reposicionar – Encontrar uma idéia central para os negócios que atenda às necessidades do cliente e que seja lucrativa para a empresa.
  • Identificar mudanças externas – Detectar tendências externas para colocar a empresa na ofensiva, sempre.
  • Comandar o Sistema Social – Reunir as pessoas certas com comportamentos e informações corretos para tomar decisões melhores e mais rápidas afim de alcançar bons resultados.
  • Avaliar pessoas – Aferir pessoas com base em suas ações, decisões e comportamentos, comparando-os com os critérios inegociáveis da função que cada pessoa deverá ocupar.
  • Moldar equipes – Conseguir que líderes altamente competentes e com ego (geralmente) enorme trabalhem em perfeita harmonia e cooperação.
  • Estabelecer objetivos – Determinar o conjunto de metas que equilibram o que a empresa pode vir a ser com o que ela pode alcançar de modo realista.
  • Estabelecer prioridades precisas – Definir o caminho e alinhar recursos, ações e energia para realizar os objetivos da empresa.
  • Enfrentar forças externas ao mercado – Prever e reagir às pressões sociais fora de seu controle, mas que podem afetar a empresa e às pessoas.

E, apesar de não ser exatamente o título do livro e nem ser a idéia central, ele também aborda de forma muito eficiente os principais traços de personalidade que podem ajudar ou interferir com as competências (acima) inegociáveis de um líder:

  • Ambição – Para conquistar algo notável, MAS NÃO vencendo a qualquer preço.
  • Determinação e tenacidade – Para buscar, persistir e realizar, MAS NÃO persistir em um plano que não está dando resultado.
  • Autoconfiança – Superar o medo do fracasso, da reação ou a necessidade de ser amado; usar o poder criteriosamente e NÃO se tornar arrogante ou narcisista.
  • Abertura psicológica – Para ser receptivo a idéias novas e diferentes E NÃO impedir o progresso de outros profissionais.
  • Realismo – Para ver o que pode de fato ser alcançado E NÃO se esquivar dos problemas ou presumir o pior.
  • Vontade de aprender – para continuar a crescer e aprimorar seu know-how E NÃO repetir os mesmos erros.