O assistente do analista

Eu quero contar uma história: um belo dia alguém da Empresa X disse que era preciso rever a política de cargos e salários para corrigir alguns problemas. Realmente havia sobreposição de funções, cargos de maior responsabilidade com menor remuneração e uma certa confusão sobre as atribuições de cada cargo. Então, uma equipe foi reunida para redefinir essa política. No início do trabalho, ficou bem claro que existiam muitos “Analistas” e “Assistentes” dentro da empresa; foi encontrado até assistente que gerenciava analista.

Pela definição, assistente é quem auxilia em alguma coisa e analista é quem realiza a “análise” de como é, porque é, e o que fazer a partir daí. Considerando então que o assistente segue as orientações de alguém e faz algo já definido, podemos entender que o analista, por sua vez, possui um perfil mais flexivel, sabendo lidar com as variações que o seu trabalho pode apresentar.

Essa então foi a parte fácil. Mais fácil ainda foi promover os assistentes que trabalhavam como analistas para o seu cargo de direito. O complicado foi mostrar aos analistas que apesar de possuírem o cargo, eles desempenhavam as funções de assistente.

Foram abertas oportunidades para essas pessoas de realmente se tornarem analistas. A empresa reconheceu seus erros “estruturais”, apresentou um generoso programa de capacitação e a promessa de aumento de salário aos analistas que concluíssem o programa. Para o espanto da equipe que conduzia essa reestruturação, muitas pessoas nessa situação se recusaram a participar do programa por entender que não era necessário estudar para obter um “status” que já possuíam. Houveram várias discussões sobre os ganhos que a capacitação traz, independente da área.

Essa resistência se mostrou como um problema cultural na empresa. Novamente, a equipe responsável pelas mudanças entendeu que eram necessárias iniciativas não apenas da perspectiva técnica desses profissionais, mas também pessoal. Foram apresentadas à diretoria algumas alternativas para a resolução desse problema, porém veio a seguinte decisão de um dos diretores: “É melhor, financeiramente, a demissão das pessoas que estão resistentes às mudanças para a contratação de outras com o perfil que agora desejamos”.

Conclusão: as pessoas que se indignaram, mesmo recebendo a mais pelo tipo de trabalho que desempenhavam e não concordaram a participar do programa de capacitação, perceberam que apesar do “barulho” que fizeram representavam menos de 2% dos funcionários e, como na prática eram assistentes, poderiam ser facilmente substituídos.

Na sua empresa, essa visão entre assistente e analistas é bem definida? Existe resistência às mudanças? As pessoas se consideram insubstituíveis? E você?

Torre de Hanói usando F#

Lendo sobre F# resolvi implementar alguma coisa para distrair. A sintaxe me lembrou muito Haskell, outra linguagem funcional, assim como a estrutura da documentação, os módulos, as tuplas e as listas também me lembraram Haskell. Foi então que me lembrei de um problema que resolvi na época da faculdade, Torre de Hanói (http://pt.wikipedia.org/wiki/Torre_de_Hanói).

Para encontrar o menor número de movimentos, a estratégia que usei foi bem simples, baseado na regra que um disco maior não pode ficar sobre um disco menor, a função segue os seguintes passos:

1. Movimenta todos os N-1 discos para a torre intermediária;
2. Movimenta o último disco para a torre de destino;
3. Movimenta todos os N-1 discos da torre intermediária para a torre de destino.

A forma como a função “sabe” os movimentos para N-1 discos é algo que a recursão resolve (ainda bem!), o importante é a existência de um caso base que para nós é a solução de Hanoi (1), ou seja, o movimento do disco 1 da torre de origem para a torre destino.

O código que calcula os movimentos, se resume basicamente nas 2 linhas de implementação da função hanoi:

#light

// Função recursiva que gera a lista de movimentos dos discos
// n -> Número de discos
// origem -> Torre de origem
// inter -> Torre intermediária
// destino -> Torre de destino
let rec hanoi (n:int) (origem) (inter) (destino) : (int* string* string) list =
  if (n = 1) then [(1,origem,destino)]
  else hanoi (n - 1) origem destino inter @ [(n,origem,destino)] @ hanoi (n - 1) inter origem destino

// Função que imprime o movimento do disco a partir de uma tupla
let imprime (n,origem,destino) =
  "Move disco " + n.ToString() + " da " + origem + " para a " + destino + "\n"

// Função que aplica o Map a cada tupla da lista
// n -> Número de discos
let imprimeJogadas (n:int) =
   List.map imprime (hanoi n "Torre A" "Torre B" "Torre C")

O resultado da execução:

A escolha da demonstração desse problema se deve ao fato que sua resolução apesar de ser bem pequena explora vários recursos do paradigma funcional e de F# como o uso de funções, recursão, tuplas, listas e funcões de alta ordem.

Espero ter ajudado no trabalho de faculdade de alguém!

Dominação Gloobal

Não é de hoje que ouvimos frases do tipo: “O Google vai dominar o mundo”. Os adeptos de teorias da conspiração são os que mais produzem lendas sobre os perigos do poder desse fenômeno da internet. Steve Ballmer, presidente executivo da Microsoft, já brincou em várias apresentações públicas dizendo: “O Google lê os seus emails!”.

Mas até que ponto todo esse poder, refletido em dezenas de serviços que o Google oferece, representa uma ameaça? Para entrarmos nessa discussão, devemos antes esclarecer os indicadores que caracterizam um monopólio. Primeiro vamos a etimologia: monopólio do grego monos = um, e polein = vender. Conceitualmente, significa uma situação de concorrência imperfeita em que uma empresa detém o mercado de um determinado produto ou serviço impondo preços aos que comercializam. Geralmente, monopólios infringem leis em benefício próprio. Como o Google não se enquadra em nenhuma das duas situações, o mínimo que podemos dizer é que se trata de uma empresa muito grande que desempenha enorme influência nas têndencias do mundo digital e dispõe de uma imensa base histórica de nossos costumes, desejos, segredos e etc.

Ano passado, uma britânica pediu divórcio após ‘flagrar’ o carro do marido em frente a casa de uma suposta amante pelo Google Street View. Esse é o ponto! Por vezes, a informação por si só já é destruidora, imagine quando na “mão” de alguém/empresa mal intencionada.

Discussões sobre a índole do Google à parte, o que mais me impressiona são as correlações entre os serviços disponibilizados por ele. Muitas vezes, quando é lançado um novo serviço, a impressão que temos é do tipo: “Onde esse cara quer chegar?”. É impressionante como o Google aproveita um recurso já desenvolvido e o encaixa em um contexto ou aplicação muito mais rica. Veja um “rascunho mental” sobre as correlações entre alguns serviços oferecidos pelo Gigante, modelado por Leonardo Piedade:

Um serviço que me chamou atenção essa semana foi o Google Voice. Com ele, você pode ter um número de telefone pessoal universal. Universal, por que é um único número para os mais diversos dispositivos. Estranho? Vamos ao exemplo: imagine que você possui um Google Number (como se fosse um número de telefone qualquer). Ele não é vinculado ao seu celular, telefone fixo ou computador. Ele é vinculado à você! Nele é possível incluir todos os números de telefone que possui. Quando perguntarem qual seu telefone, bastará que você diga o seu Google Number, e essa pessoa possuirá ao mesmo tempo seu celular, telefone fixo, ramal do trabalho e etc. Via web, é possível programar para que quando seus amigos liguem para o seu Google Number, ele os redirecione automaticamente para a sua casa e seu celular ao mesmo tempo. Quando sua família ligar, você pode redirecioná-la para sua casa, emprego e celular. Quando seu chefe ligar, redirecione-o direto para o correio de voz. :)

Por falar em correio de voz, através do Google Voice, é possível transformar suas mensagens de voz recebidas em mensagens de texto de forma automática.

Realmente, diante disto, o que nos resta é perguntar: “Onde esse cara quer chegar?”

Veja a história do Google contada em dois minutos aqui.

Assista um vídeo explicativo do Google Voice aqui.

Sourcing + Comunidade = Crowdsourcing

Novamente lendo alguns textos sobre ITIL me deparei com a descrição dos tipos de fornecimento de serviços. Logo, se você tem um trabalho para ser feito, é necessária a decisão de qual a melhor estratégia para realizar esse trabalho. Essas opções apresentam vantagens e desvantagens, algumas descritas no livro Service Design são:

Insourcing: Utiliza os recursos internos da organização.

Outsourcing: Utiliza os recursos de outra empresa através de um acordo formal (contrato).

Co-sourcing: Combinação da utilização de recursos internos e externos.

Multi-sourcing: As atividades são dividas entre várias organizações (parcerias).

Business Process Outsourcing (BPO): O fornecedor gerencia por completo processos de negócio.

Application Service Provision (ASP): Fornece serviços compartilhados, como infra-estrutura por exemplo.

Knowledge Process Outsourcing (KPO): É a evolução do BPO, onde o fornecedor conta com competências de alto nível, para interpretação de dados para a tomada de decisão.

Existe uma opção não listada aqui, considerada por alguns, que é o Crowdsourcing, envolvendo vários recursos, muitas vezes voluntários, as pessoas participam porque gostam e dedicam seu tempo livre para isso. Um bom exemplo são as comunidades open source, que resultaram em produtos como o Linux.

A utilização dessa forma de recurso não é simples, e tem desvantagens como tornar muitas informações púbilicas e não ter o controle da entrega sem um time interno, por outro lado, o custo é baixo e se tira proveito da inteligência coletiva. Uma variedade maior de soluções são propostas e os testes são executados em ambientes diferentes.

Essa forma de trabalho é considerada por muitos como não aplicavel ao ambiente corporativo. Porém, muitas grandes empresas investem em comunidades como apoio ao desenvolvimento dos seus produtos. Alguns poucos já fizeram fortunas baseadas nos produtos do trabalho de milhares de anônimos espalhados na internet, e muitas dessas pessoas continuam contribuindo por considerar que os beneficios que o produto traz para si é recompensador. Há alguns que acreditam que essa é uma das formas de aproveitar melhor os conhecimentos da humanidade que sempre foram extremamente dispersos.

Disciplina X Metodologia

É engraçado como em computação as pessoas se preocupam em usar os nomes corretos. Mesmo assim, alguns nomes são trocados o tempo todo. Um exemplo clássico é o de Disciplina e Metodologia que conceitualmente possuem o seguinte significado:

Disciplina: É como uma estrutura que fornece orientação, permite a análise mesmo para itens não previstos. (O que fazer).

Metodologia: Fornece direções especificas para lidar com situações conhecidas, consiste em um conjunto de métodos, sendo um método a abordagem passo a passo para realizar tarefas. (Como fazer).

Parecem coisas como água e óleo, mas funcionam muito bem quando combinadas, um exemplo, é o próprio RUP (Rational Unified Process) que é uma metodologia divida em disciplinas, ou seja, em níveis superiores é fornecido a forma de fazer e em níveis mais detalhados é uma orientação do que fazer.

As pessoas aprendem esses termos de diversas formas e utilizam como bem entendem, eu nem sei dizer se a descrição feita acima é a mais utilizada. Agora o que fica estranho é durante uma conversa você ouvir a mesma palavra com 4 ou 5 significados diferentes vindos da mesma pessoa. Eu acredito que em conversas técnicas o ideal seria procurar manter a semântica, pois esse é o propósito do uso de conceitos. Não é mais complicado quando é necesssário explicar o que você está tentando dizer?

O melhor de dois mundos

Por muito tempo, as empresas gerenciaram seu software sob premissa. Os softwares eram instalados em seus computadores e quem fornecia o suporte era a equipe de TI interna. Com a evolução da internet muita coisa mudou. Agora o software não está apenas disponível sob premissa, mas também como serviço na internet. Para o computador, web e celular, os serviços na internet oferecem um mundo de novas possibilidades. E é justamente essa equação, S+S (software + serviços), que está criando um novo horizonte e a proposta é que Microsoft e parceiros suportem essa nova composição de uma TI híbrida e altamente combinada.

Mas o que software + serviços significa para uma empresa?

Para exemplificar, imagine-se na pele de um executivo de uma empresa X que depende de um software para seu negócio. Você comprou esse software e o instalou em seus computadores. Seu sucesso depende diretamente de um software que seja compatível com suas necessidades e capacidade de infra. Nesse cenário, sua equipe de TI deve garantir a segurança, disponibilidade e performance desse software, entre outras coisas. Com a expansão de sua empresa, você precisou viajar mais e mais. Mas o software que utiliza não funciona via web ou via celular. Eis que você se sente preso ao escritório. Além do mais, é um processo muito dolorido instalar todos os softwares em uma nova filial, por exemplo. Claro que a esta altura, seu sentimento de limitação realmente te incomoda.

Agora, imagine-se na pele de outro executivo que fez uma escolha diferente. Ao invés de instalar o software, você usa serviços na internet - também conhecidos como SaaS (Software as a Service). Você só depende da internet para conectar seus computadores e celulares e, assim, 'tocar' o seu negócio. E o tal software como serviço deixa para trás muitas preocupações que você poderia ter com sua equipe de TI. Atende prontamente quando seus funcionários estão longe do escritório e oferece escalabilidade caso sua empresa cresça de forma rápida. Mas mesmo assim você, como no exemplo anterior, se sente limitado, pois o software como serviço requer uma conexão constante com a internet e, se algo sair errado, sua empresa literalmente pára. Ainda existe outro ponto: geralmente os softwares como serviço são desenvolvidos para fazerem coisas similares para todos os clientes, o que implica dizer que, por vezes, eles não atendem necessidades muito específicas de sua empresa.

Eis que você e você mesmo (é a dualidade do eu!) se encontram e chegam a conclusão de que seria muito melhor juntarem “software sob premissa + software como serviço” pois, empresas não podem conviver com esse sentimento de limitação. Precisam de que a tecnologia ofereça flexibilidade e suporte para que seu negócio cresça e seu software deve ser capaz de servir como uma luva para as necessidades de seu negócio tão logo se faça necessário.

Com a equação "software sob-premissa + software como serviço", temos o S+S (Software mais serviços) que é o melhor dos dois mundos para você e para você mesmo. (?!) :)

Do bit ao dinheiro

Bom, talvez eu esteja “chovendo no molhado” mas, mesmo assim, queria comentar sobre um aspecto da dicotomia entre a vida acadêmica e a profissional. Quando estamos na graduação, somos doutrinados a ter um pensamento técnico, buscamos nos tornar especialistas em tecnologia, seja ela qual for. Isto fica bem claro quando conversamos com estudantes e recém-formados. Porém, esse tipo de pensamento não serve para os cargos de decisão.

Com o tempo esses profissionais se tornam executivos de TI, sendo que muitos deles tendem a se focar no know-how, assim como aprenderam, e se esquecem que no ambiente corporativo é importante conhecer bem o modelo de negócio da empresa para se concentrar no know-why.

Imagine uma reunião de diretoria onde são apresentadas propostas sobre a expansão da empresa, a necessidade de redução de custos, aumento das vendas e outras. Obviamente que para apoiar essas estratégias é solicitado a participação da área de TI que, rapidamente com sua forma de pensamento equivocado, surge com vários “planos bem elaborados” para converter todos os sistemas para SOA, incluir mais relatórios, implantar governança baseada em ITIL e Cobit, migrar sistemas para as tecnologias atuais, virtualizar máquinas do datacenter ou implantar outra tendência atual. Será que esses planos estão realmente alinhados com as necessidades do negócio?

Em geral tais planos devem passar por aprovação e é ai que acontece o inverso, executivos que por sua vez não têm conhecimento em TI aceitam as idéias sem criticá-las, ou seja, ambas as partes erram, a primeira por não pensar nos resultados reais para o negócio e a segunda por não exigir argumentos claros sem o costumeiro "tecniquês". Isto acontece muitas vezes de maneira silenciosa nas empresas, faltou o tão comentado “alinhamento entre TI e negócio”, desta vez por ausência de competência dos gestores de TI que não perceberam que o conhecimento técnico que possuem deve guiar as decisões ao invés de ser o foco delas.

As conseqüências disso são projetos fracassados, baixos resultados, investimentos literalmente jogados fora. Esse é um dos motivos pelo qual a TI continua ocupando o lugar da “área de serviço”, quando poderia ser a “vitrine” das empresas.

Utilidade X Garantia, simples?

Estava lendo um material sobre ITIL e me deparei com um conceito relativamente simples:

Utilidade (Utility): É o que o cliente precisa, caracteriza o que o serviço faz.

Garantia (Warranty): É como o cliente precisa, caracteriza como o serviço é entregue (entenda entrega como o serviço em produção).

Na prática também parece simples, a “Utilidade” é descrita pelos requisitos funcionais e a “Garantia” é descrita pelos requisitos não-funcionais.

No entanto é ai que começam alguns dos problemas. Em geral, os requisitos não-funcionais (usabilidade, confiabilidade, desempenho e suportabilidade) são descritos de forma incompleta e nesse “deslize” as promessas feitas para o cliente e para si mesmo dizendo que, dessa vez, nesse novo projeto, “tudo vai ser diferente”, devem tomar mais tempo para acontecer.

Existem desculpas para os requisitos mal escritos. Um argumento padrão é aquele “Não há como ter uma boa estimativa de carga”, mas e quanto a estimativa de capacidade do sistema? Que tipo de profissional não conhece o resultado do seu trabalho!?

Como um sistema pode ser entregue sem ao menos um conjunto de testes de confiabilidade e desempenho? Isso parece um absurdo mas é a realidade em muitas empresas no Brasil. Depois de pronto, o sistema é implantado e aos poucos os problemas surgem. O diagnóstico em produção é mais dificil do que no ambiente de testes e, em muitos casos, o cliente paga para arrumar o que ele já pagou para não estar “quebrado”.

O conceito “tão simples” do efeito da combinação de Utilidade e Garantia exige bem mais trabalho do que parece para ser posto em prática. A habilidade de entrega de um serviço com determinado nível de garantia é realmente um grande diferencial competitivo.

Links:

• http://www.baguete.com.br/blogs/post.php?id=3,246
• http://itilblues.wordpress.com/2007/12/14/itil-v3-utility-and-warranty-two-sides-of-the-same-coin/