Dica de Leitura: O Milênio da Inteligência Competitiva

Conforme prometido, aqui vai mais um livro sobre o tema "Inteligência Competitiva" e que também foi um dos que usei como base para meu trabalho de conclusão da faculdade. Diferente do livro anterior, que era mais teórico, este é  voltado para a tomada de decisões, utilizando ferramentas práticas. Em O Milênio da Inteligência Competitiva, Jerry P. Miller e a equipe do Business Intelligence Braintrust procuram demonstrar a operacionalização da IC no dia-a-dia das empresas e como conseguir os melhores resultados a partir das informações disponíveis no ambiente, sem desrespeitar os padrões éticos e legais.

Uma das partes mais interessantes (e um dos diferenciais) do livro é o fato de o autor dar ênfase à utilização da IC por empresas de pequeno porte. Segundo ele, o processo não precisa ser de uso exclusivo das grandes corporações, podendo ser tão útil quanto para as empresas pequenas, desde que bem estruturado e organizado. Há uma série de cases de empresas desse tipo que usam a IC para conseguir vendas acima das médias do seu segmento, por exemplo. 

O livro não apresenta uma estrutura teórico-didática. Ele é puramente descritivo e, volta e meia, o autor retoma assuntos tratados em capítulos anteriores, por isso a leitura pode ficar um pouco cansativa. Recomendo que seja lido aos poucos. Mas, no fim, ele cumpre com seus objetivos de mostrar a aplicação da inteligência competitiva nas empresas e o que fazer para operacionalizar o processo e obter as melhores informações sobre seus concorrentes e sobre o mercado.

Dados do Livro:
Título: O Milênio da Inteligência Competitiva

Autor: Jerry P. Miller

Editora: Bookman
Páginas: 294

Leia Mais

Demissão: O Lado de Quem Fica

Dias atrás eu conversava com um colega de trabalho na hora do cafezinho sobre diversos assuntos do meio corporativo e situações que a gente vivencia durante a carreira. Não lembro exatamente por que, mas começamos a falar sobre um processo que sempre mexe, de uma forma ou de outra, com o andamento das atividades de uma equipe: a saída de um de seus membros.

Por mais que muitos acreditem que ninguém é insubstituível, sempre há um impacto considerável quando uma pessoa deixa o time. Até se encontrar um substituto, as tarefas da pessoa que saiu acabam tendo de ser executadas pelos que restaram, aumentando suas agendas. E, mesmo depois de contratada uma nova pessoa para a posição, ainda há um tempo razoável de treinamento e ambientação até que ela possa, efetivamente, produzir. Isso é custo para a empresa, embora muita gente ache que eles só se limitem aos encargos referentes à demissão.

O fato é que não é simples para o líder lidar com esse tipo de acontecimento, nem quando o colaborador pede demissão, nem quando você precisa demiti-lo. Particularmente não acredito em posicionamento 100% profissional no que diz respeito ao relacionamento com os colegas. Ora, você passa a maior parte do seu dia com eles. Impossível não desenvolver amizades ou, ao menos, admiração por alguns. Isso, sem dúvida, pesa na hora da saída. Também não é fácil quando você vê um membro do time com baixo rendimento sair ou precisar “ser saído”, como se diz por aí.  

Lidar com uma demissão anunciada é um pouco menos doloroso. Se a pessoa vem dando sinais de que quer sair ou de que sua saída é questão de tempo, devido ao seu baixo desempenho, o líder tem ao menos a chance de planejar e mitigar os efeitos dessa já prevista perda de um componente da equipe. Você pode pensar em possíveis candidatos que estejam em outros times, ou então analisar os muitos currículos que estão disponíveis no RH. Mesmo assim, ter de comunicar oficialmente a pessoa de que ela não será mais parte do time é complicado. Mais do que isso, é preciso ser transparente, justo e deixar claro os motivos que estão levando a empresa a tomar aquela decisão. O demitido tem o direito de saber onde errou, de que teve vários feedbacks que não foram absorvidos por ele, ou qualquer que seja a razão de sua saída. Isso certamente fará com que ele pense e leve essas dicas para os próximos empregos que tiver. Acho que é por aí que as coisas devem acontecer. Mas você terá de saber lidar com os inconformados também, e aí suas habilidades de negociação e autocontrole serão ainda mais necessárias. Não há receita de bolo, mas a chave é a tranquilidade e a sensibilidade que o líder deve ter, além, é claro, do respeito pelo indivíduo em questão. 

Agora, quando a demissão é algo que você não esperava, é bem mais difícil. Se o colaborador resolve aceitar uma proposta de outra empresa e comunica seu desligamento, você, inevitavelmente terá de administrar o efeito surpresa e “se virar” para repor a perda. Inclui-se aí comunicar o cliente para o qual sua equipe trabalha e gerenciar uma possível insatisfação por parte dele. Também é complicado, de uma hora para outra, encontrar uma reposição. Ainda mais sendo no curtíssimo prazo. Vêm todos aqueles custos que mencionei: procurar, recrutar, contratar, treinar, etc. Nesses casos, a equipe também é pega de surpresa e é preciso ainda trabalhar os ânimos internos, a fim de que o ambiente não perca o equilíbrio. Quando um membro do time pede demissão, você provavelmente terá de ouvir mais do que falar, uma vez que é ele quem explica suas razões para decisão já tomada. Sendo alguém competente, você pode argumentar para que ele fique, mas nem sempre é uma boa ideia. Eu parto do princípio de que, sendo esse colega inteligente, maior de idade e dono de sua vida, suponha-se que saiba o que é melhor para si. Resta pouca coisa a não ser aceitar o fato e tentar encontrar uma solução da forma mais rápida, adequada e menos impactante possível. Considero de bom tom desejar sorte, sucesso e passar um último feedback ao agora ex-colega. É bom que ele saiba a importância que teve, os pontos onde ele pode melhorar, etc. Nunca tente desmerecer a decisão que ele tomou ou a empresa para onde ele está indo. Você pode ser o líder da equipe, mas não é o dono da vida dos seus colegas. Procure agir com a mesma transparência e ética também nessas situações.

Logicamente, alguns pontos acima podem variar, de acordo com a maneira como a pessoa resolve sair da empresa. Uma coisa é agir corretamente, comunicar sua saída, fazer a transição das tarefas para seus colegas, enfim, deixar as portas abertas. Outra coisa é sair sem terminar nada nem passar instruções, deixar tudo bloqueado, sem que as pessoas possam acessar para continuar de onde você parou, falar mal da empresa, não respeitar os prazos do contrato, etc. A observância ou não desses pontos pode indicar o quão trabalhosa será a busca por um novo colaborador ou mesmo como ele será visto pelos colegas e pela empresa.

Outro erro bastante comum é a dicotomia “solicitar um aumento versus aceitar uma proposta de outra empresa”. Muita gente liga as duas coisas, ou seja, tem uma proposta externa e condiciona sua permanência a um aumento de salário, simplesmente. Em alguns casos, o tiro pode sair pela culatra. Particularmente, acho errada essa abordagem. Se você acredita estar recebendo uma remuneração aquém do seu rendimento, jogue limpo e converse com o seu líder. Esclareça a situação e mostre, a partir dos resultados que você vem obtendo, o porquê do seu pedido. A tendência é que seja aceito, caso se justifique. Muita gente tem medo ou vergonha, mas a época do chefe já foi. Os líderes de hoje, em geral, são mais abertos e flexíveis. No caso de haver realmente insatisfação com a empresa e com o trabalho, sem oportunidade nenhuma pela frente, procure novos ares. Não tente um simples aumento. Isso não vai resolver o problema central, só vai deixá-lo ainda mais frustrado no médio prazo. É bom separar as duas coisas. Você deve pedir aumento apenas quando quer ficar, mas achar que seus vencimentos não condizem com sua produtividade. Se você quer sair, saia. Não barganhe sua permanência em um ambiente que não lhe agrada só por uns reais a mais. Até porque se corre o risco de ouvir um não e ficar sem emprego, ainda mais se a pedida for algo fora da realidade. Blefar, indo na linha do “se colar, colou”, nem pensar. É ainda pior. Além de antiético, isso só fará mal para você. Sempre é possível deixar as portas abertas ou fechadas. Eu prefiro a primeira opção. O mundo dá muitas voltas e o mercado de TI é muito dinâmico. Você um dia poderá voltar para aquela empresa. E a maneira como você saiu terá muita influência nisso.

Existe ainda um terceiro caso, que é mais extremo, mas nem tão raro quanto parece: o de demissões em massa, os famosos layoffs. É aquela situação em que todos da sua área ou setor são demitidos de uma só vez, por custos, pela área não ser mais necessária, etc. É mais comum em empresas de grande porte, mas já vi acontecer em empresas pequenas/médias. Só que nem sempre saem todos. De vez em quando, ficam um ou dois. E eles têm de absorver o trabalho dos que saíram. Já passei por esse processo em duas empresas, mas sempre fui o que ficou (digo "o" que ficou justamente porque, nos dois casos, fui o único da área/setor a permanecer). É muito complicado ter de fazer sozinho o que um grupo de cinco ou dez pessoas fazia antes. São tempos difíceis, onde se trabalha muito e se aprende muito, da mesma forma. Calma e organização são imprescindíveis. Do contrário, você pode surtar, literalmente. A parte boa em ser o único que não foi demitido, é que deve haver um bom motivo para isso. E essa explicação deve estar na qualidade do seu trabalho. Meu pai sempre diz que "quem trabalha bem não vai pra rua". Creio que ele tem certa razão nisso. Muita gente competente é mandada embora num layoff? Sim. Mas se você ficou, é porque talvez a empresa veja em você algo diferente, seja comprometimento, visão, competência, etc. Algum diferencial você tem. Pense nessas situações também como uma forma valorização pessoal.

Na minha carreira já vivenciei todos os casos acima. Não posso dizer que foram simples de se lidar. Para quem fica, às vezes, é tão difícil quanto para quem sai. Por isso, jogar limpo e ser transparente sempre é melhor para os dois lados. Organização ajuda bastante também. Se você tem um processo interno bem elaborado e robusto, consegue minimizar os impactos. E, é claro, algumas características pessoais são fundamentais: 1) resiliência, para poder dar a volta por cima; 2) persistência, para poder manter a ordem e a tranquilidade do time e 3) empatia, para entender e colocar-se no lugar de quem está indo embora, a fim de evitar julgamentos equivocados. Mas as surpresas são muitas, inegavelmente. Nunca se sabe o que se pode esperar de um momento como esse. Portanto, esteja preparado!

Leia Mais

QTP Tips: Repositório de Objetos Global x Local

Para as pessoas da área de testes que usam o QTP (QuickTest Professional) como ferramenta para a criação de testes automatizados, certamente esta é uma questão recorrente, em especial quando se está iniciando um novo projeto ou um suite de regressão para uma aplicação existente.

Afinal, o que é melhor? Utilizar um repositório de objetos global, onde todos os scripts vão compartilhar os mesmos objetos ou deixar um repositório sendo utilizado localmente, para cada script criado?

O uso de um repositório local pode parecer mais fácil, especialmente se você estiver desenvolvendo seu script através da função Record/Playback. Você clica no botão de gravar, segue os passos definidos na aplicação e, ao final, todos os objetos com os quais você interagiu estarão gravados no repositório daquele script. Grosso modo, bastaria clicar no play para que o QTP executasse automaticamente as mesmas ações gravadas previamente. Sua única preocupação seria ajeitar o código VBScript gerado, parametrizar algumas entradas e pronto: utilizar o script sempre que precisar.

Conheço muita gente que utiliza a ferramenta dessa forma. Mas, a meu ver, há dois problemas com esse tipo de abordagem que podem aparecer individualmente ou simultaneamente, dependendo de como estiver o seu projeto:

1 - Manutenção: a menos que exista apenas um script interagindo naquela aplicação, haverá um grande trabalho com a manutenção dos objetos. E é bem fácil entender por que: à medida que o suite vai crescendo e dezenas de scripts passam pelas mesmas telas, qualquer mudança em um objeto em comum ou nas suas propriedades significa cada um dessas dezenas de scripts terá de ser acessado para que sejam feitas as mudanças necessárias nos seus repositórios de objetos locais. Especialmente em aplicações web, é comum os desenvolvedores alterarem características de objetos em uma página ou formulário. Imagine que uma dropdown utilizada em todos os seus scripts tenha mudado alguma propriedade usada na verificação? O QTP não vai reconhecer o novo objeto durante a execução a menos que este seja capturado de novo. E essa alteração teria de ser feita em todos os scripts, pois o objeto foi gravado uma vez em cada um deles. Isso certamente demandaria algumas horas de trabalho. Utilizar programmatic descriptions também não resolve, pois, embora essa técnica não precise de objetos físicos gravados no repositório, ela requer que as propriedades dos objetos que foram escolhidas para a validação não mudem. Se a página mudar, você não precisa alterar nos repositórios, mas terá de alterar o código VBScript de cada teste. Ou seja, dá na mesma, praticamente.

2 - Um repositório local pode jogar contra a organização do processo: com os mesmos objetos repetidos em vários lugares, fica difícil ter uma ideia do tamanho do repositório, da quantidade de objetos manipulados até de se estabelecer um padrão de nomenclatura ou classificação, por exemplo. Isso fica ainda mais difícil quando há várias pessoas envolvidas na criação dos scripts, pois elas podem seguir padrões distintos. E mesmo que um sistema de nomenclatura ou classificação exista e seja seguido por todos, ainda assim não se terá a visualização nem as características globais de todos os objetos. Também pode acontecer de as pessoas terem capturado objetos diferentes entre os scripts para uma mesma página da aplicação, pois cada uma delas interagiu com aquela tela de forma diferente.

Particularmente, considero que a abordagem de se ter um repositório global, compartilhado por todos os scripts, seja mais adequada. Ela tem algumas limitações, mas me parece melhor do que manter um repositório para cada script, desde que bem feita. Algumas coisas que eu pude notar com o tempo e que podem ajudar bastante:

Defina alguns padrões mínimos antes de tudo: É muito importante, antes de começar qualquer script ou capturar os objetos, estabelecer os padrões a serem utilizados. Há muitas formas de criar padrões e muitas opções de critérios. Eu diria que, no mínimo, deva-se considerar:

·      Local de armazenamento: A partir da versão 10, o Quality Center introduziu uma aba chamada “Test Resources”, onde podem ser criados e armazenados, por exemplo, bibliotecas de funções, recovery scenarios e repositórios de objetos. Você pode estabelecer uma estrutura de pastas internas e armazenas esses dados ali, diretamente no servidor. O QTP pode ser integrado ao Quality Center e aproveitar a mesma estrutura;

·      Padrões de nomenclatura dos objetos: os objetos ficam ordenados no repositório primeiramente por tipo. Portanto, todos os objetos de mesmo tipo ficarão agrupados um abaixo do outro ao se visualizar o repositório. Nem sempre os desenvolvedores se preocupam com algum sistema para nomear ou classificar os objetos ou então não há no projeto algo que considere isso. Vê-se de tudo nesses ambientes! Então, ter um padrão de nomenclatura facilita a identificação e utilização. Renomeie os objetos capturados para um padrão estabelecido, de preferência por tipo. Você pode até aproveitar o nome original, mas ponha um prefixo que identifique o seu tipo, ao menos. Por exemplo, use “img“ para imagens, “dpw” para dropdowns, “edt” para editboxes, etc. No caso de sistemas web, não se esqueça de estabelecer um padrão para nomear cada página armazenada também, pois elas serão como diretórios que conterão os demais objetos.

Capture todos os objetos antes de iniciar a criação dos scripts: Essa é uma parte importante do processo que vai gastar um tempo considerável no começo, mas que certamente irá economizar muito mais tempo lá na frente. Definidos local de armazenamento e padrões de nomenclatura, acesse a aplicação e utilize o QTP para capturar e renomear todos os objetos possíveis, não apenas aqueles que você acredita que irá precisar. Só depois que o repositório estiver com todos os objetos capturados, associe o script a ele. Assim, ao gravar os passos pelo QTP, a ferramenta já vai identificar e reconhecer os objetos do repositório (sem ficar adicionando-os como se fossem novos) e irá colocá-los no código VBScript automaticamente e da forma como você os definiu. Isso é muito útil especialmente em aplicações web, que possuem diversas páginas e as usam para separar os objetos. Uma vez feito isso, você só precisará adicionar novos objetos quando e se a aplicação mudar, o que é uma manutenção razoavelmente pequena.

Mantenha os objetos do tipo checkpoint localmente. Diferentemente dos demais tipos de objetos, os checkpoints só dizem respeito ao script que estão validando e, portanto, não faz sentido enviá-los para o repositório global. E, no caso de ser usado o controle de versão (QTP 10 ou superior), você não precisa ficar fazendo check-out/check-in do servidor cada vez que precisar atualizá-los. Basta abrir o objeto e alterar manualmente ou rodar o script em update mode, para que os novos valores sejam atualizados. Resumindo: ao final, haverá um repositório com todos os objetos interativos vindos do servidor (repositório global) e apenas os checkpoints do script corrente como objetos locais.

Como nem tudo é perfeito, e sempre algo pode sair diferente do que se espera, há algumas observações que considero importantes serem feitas para o bom funcionamento dessas dicas:

1 – Até a versão 9.2, quando ainda era uma ferramenta da Mercury, o QTP não mostrava os objetos tipo checkpoint no repositório. Você só conseguia editá-los se fosse direto ao código, clicasse com o botão direito em cima do nome do checkpoint e selecionasse a opção “checkpoint properties”. Se por acaso o seu checkpoint estivesse escrito em forma de variável parametrizada (utilizando-se a referência da data table em vez do nome), você simplesmente não teria como acessá-lo. A partir da versão 9.5 (já como produto da Hewlett-Packard), os checkpoints passaram a ser tratados como qualquer outro objeto, estando disponíveis no repositório, visualmente. Dessa forma, ficou muito mais fácil editá-los ou renomeá-los, bastando um click em cima deles para isso. Portanto, a utilização de alguns padrões mencionados antes pode depender muito da versão do QTP que você está utilizando.

2 – Uma coisa que notei é que a migração de versões pode causar certa incompatibilidade ao converter os repositórios de objetos. Uma vez migramos da versão 9.2 direto para a versão 10 (sem passar pela 9.5). Acontece que os repositórios criados na versão 9.2 não eram prontamente reconhecidos pela versão 10. Ao tentar gravar um script em uma página cujos objetos já estavam no repositório, o esperado era que o código VBScript utilizasse esses objetos. Mas o QTP sempre os adicionava localmente, como se fossem novos. Em alguns casos, o simples fato de editar o repositório e excluir e incluir um objeto novamente já fazia o QTP reconhecer normalmente os demais. Mas houve casos em que isso não funcionou. Daí o jeito foi gravar o código e editar manualmente cada objeto não reconhecido. É uma grande mão-de-obra, mas é necessário. Da versão 10 para a 11 isso não aconteceu mais.

3 – A versão 10 apresenta um bug no gerenciamento de alterações nos objetos locais de diferentes actions, quando feitas diretamente pela janela do repositório. Se você possui um script com mais de uma action e abre o repositório de objetos, notará que há uma dropdown onde é possível escolher a action cujos objetos devem ser mostrados. Suponha que o script esteja aberto na Action1. Abre-se a janela do repositório e, como padrão, a Action1, que estava sendo utilizada, aparece com seus objetos. Se por acaso a Action2 for selecionada na dropdown, for feita qualquer mudança em um checkpoint, por exemplo, e acionado o botão de salvar, essa alteração não fica gravada. Só funciona se for alterada a mesma action que estava sendo usada na tela do script. Se você quiser alterar alguma coisa nos objetos da Action2, deve fechar o repositório, voltar para a tela principal do script, selecionar a Action2 e só então abrir o repositório e alterar os objetos dela. O pior é que, no meu caso, só descobri isso depois de alterar dezenas de checkpoints. Por isso, preste atenção nesse detalhe se estiver usando a versão 10. A partir da 11 isso não acontece mais.

Essas dicas são oriundas da minha experiência com a ferramenta, espero que sejam úteis de alguma forma para quem trabalha com ela e que resolva algumas dúvidas que vocês tenham. São sugestões apenas, mas funcionaram bem no meu caso e creio que podem ser úteis para outras pessoas. Prometo que tentarei colocar mais algumas dicas aqui no blog referente à utilização do QTP como ferramenta de automação de testes. Fiquem ligados!

Leia Mais

Foto-legenda: O Centro 5

Existem alguns lugares que acabam fazendo parte da nossa história. O Centro de Ciências Econômicas da Unisinos, em São Leopoldo - RS é um desses lugares para mim. Conhecido como Centro 5 (o campus da Unisinos é dividido em centros), abriga os Cursos de Administração, Comércio Exterior, Ciências Contábeis, etc.). 

Sou formado em Administração de Empresas e passei sete anos da minha vida nos corredores do Centro 5. Diz muito para mim essa foto em especial, pois foi tirada no dia da minha formatura, em 2005, poucas horas antes da cerimônia de colação de grau. Esta placa fica no fim do corredor principal, que dá de frente para a Biblioteca e para o Centro Comunitário, o famoso "prédio redondo").

Sou muito grato à instituição, não apenas pela formação, mas pelas amizades e experiências que tive lá dentro. E claro, pelas oportunidades profissionais decorrentes dos conhecimentos adquiridos naquelas salas de aula. Por isso, a foto, além de uma lembrança, pode ser considerada uma homenagem e um agradecimento pela minha passagem por uma das melhores universidades do Brasil, seja em termos de ensino, seja em termos de estrutura. 

Obrigado, Unisinos!

Leia Mais