Copa das Copas? Para quem?

A copa do mundo de futebol de 2014 acabou. Muita gente vem alardeando o resultado positivo da organização brasileira do evento porque não ocorrem as catástrofes que estavam no imaginário de alguns poucos. Durante a copa acontecerem rigorosamente as mesmas coisas que acontecem no dia a dia nacional. Obras civis caíram na cabeça das pessoas, cidadãos foram roubados, drogas foram vendidas à céu aberto, ilegalidades diversas ocorreram por falta de policiamento, preços subiram para a estratosfera e gargalos e congestionamentos ocorrem nos restaurantes, estádios e ruas.

Em outras palavras, foi uma copa mais cara que a da África do Sul em 2010 e um pouco melhor organizada e muito mais cara e pior organizada que a da Alemanha em 2006. Claramente o termo “Copa das Copas” não é realista, para os brasileiros, para a organização da copa no Brasil em 2014.

Dentro do campo, muitos consideraram a derrota do Brasil contra a Alemanha como uma vergonha, humilhação ou tragédia nacional.  Será que uma simples derrota esportiva é merecedora de tal adjetivo? Será que esta derrota é diferente da derrocada do Brasil diante da Rússia na final da medalha de ouro nos jogos de Londres em 2012? Naquela ocasião, o Brasil estava com uma mão na vitória e sofreu uma virada histórica.

Nesta copa, o Brasil foi contundentemente derrotado e humilhado fora do campo por um adversário que o país finge ignorar ou não suspeita existir. A organização que foi muito similar à copa das confederações foi incapaz de perceber e realizar o real potencial de ganho do megaevento copa do mundo de futebol.

Para entender melhor esta critica tão contundente à organização do evento é preciso analisar o seu resultado financeiro. A prefeitura da cidade de São Paulo revelou que o turismo da Copa injetou R$ 1 bilhão na economia paulistana e gastou de forma direta e indireta R$ 460 milhões (R$ 420 milhões em créditos tributários mais 40 milhões como custo operacional do evento) com a copa. Considerando que a carga tributária brasileira representa 36,27% do PIB e assumindo ERRADAMENTE que todos os tributos da arrecadação do turismo na copa na cidade de São Paulo foram endereçados apenas para o município, ou seja, nada para o governo estadual e federal fica claro que o resultado final é uma perda de R$ 97,3 milhões (arrecadação de apenas R$ 362, 7 milhões contra despesa total de R$ 460 milhões). Em outras palavras a população pobre de São Paulo pagou do seu minguado bolso para que a entidade máxima do futebol mundial tenha um lucro bilionário.

Quando pensamos que algo é tão ruim que não pode ser piorado, podemos facilmente perceber que a perda mencionada é apenas a pontinha visível do iceberg. Os números do volume trafegado nas redes sociais como Facebook, Twitter, Google e etc. revelaram que a copa gerou uma enorme movimentação. O volume de interações foi facilmente traduzido pelos empresários americanos em venda de publicidade. Em outras palavras as redes sociais arrecadaram varias centenas de milhões de dólares sem a necessidade de investir um único centavo na copa. O evento paulistano da copa foi praticamente pago apenas pelos pobres da cidade de São Paulo.

É evidente que os impostos gerados pelas vendas nas redes sociais foram arrecadados pelo governo americano e não o brasileiro. Nada tenho contra o investimento realizado na copa em São Paulo, mas fazer o evento sem investir um único centavo na construção de uma rede social foi de uma pobreza de gestão incomensurável. Se existiu alguma humilhação na copa no Brasil, esta foi fazer os pobres paulistanos pagarem para o enriquecimento dos ricos estrangeiros.

Tenho certeza de que alguns vão alegar que o retomo do investimento vai ocorrer com o aumento futuro do turismo pela divulgação da cidade de São Paulo no mundo inteiro. Até acredito que nos próximos 60 meses a cidade recupere o investimento realizado. O meu ponto de discordância veemente é porque esperar CINCO ANOS para capitalizar o evento se o mesmo poderia ter sido feito de forma imediata?

É possível fazer a mesma conta realizada para a cidade de São Paulo para cada uma das outras onze sedes. O resultado é sempre o mesmo. Perdas e mais perdas para os mais pobres. Eu não tenho dúvida que a copa no Brasil de 2014 foi à copa das copas para os ricos empresários do Facebook, Twitter, Google e etc.

A falácia da satisfação do usuário

O grande problema das profecias proferidas pelos falsos profetas é que elas começam com algumas verdades e umas poucas falácias e em pouco tempo aquilo vira uma bola neve em que as verdades iniciais desapareceram na gigantesca nuvem das falácias. Basicamente este fenômeno é o resultado da minúscula capacitação dos falsos profetas que precisam propagandear novas falácias para cobrir os furos, inconsistências e incoerências das falácias anteriores.

 

O último grito da moda é opor a satisfação dos usuários com o SLA (Service Level Agreement) para justificar os benefícios inexistentes do autoatendimento e autosserviço. Alguns apelam (para passar a imagem de intelectuais especialistas) para textos internacionais para justificar os seus argumentos via usabilidade da interface de comunicação do aplicativo de autoatendimento e autosserviço. Estes falsos profetas argumentam com base nas pesquisas de satisfação que é preciso automatizar. Eles dizem que existem conflitos entre o custo, qualidade e satisfação.

 

Infelizmente eles e os seus seguidores mais uma vez mostram desconhecimento e despreparo. Toda e qualquer pesquisa de satisfação deve ser conduzida em função dos parâmetros dos termos do acordo do nível do serviço. O custo é um parâmetro da qualidade entregue. Em alguns casos é o parâmetro de maior peso.  Isto significa que não existe oposição entre o custo e respectivo SLA e a satisfação do usuário.  Se os especialistas de negócio da empresa optaram por contratar uma banda larga de 10M não tem sentido algum que a pesquisa de satisfação realizada pelo fornecedor aponte que os usuários querem 20M de banda larga. O fornecedor deveria estar fazendo o seu trabalho e avaliar a satisfação das suas entregas.

 

Na verdade este é o real pano de fundo para esta falácia. Os falsos profetas querem cobrir sobre o manto da satisfação direcionada ao autoatendimento e autosserviço as deficiências dos fornecedores para entregar dos termos do acordo do nível de serviço. Muitas das empresas terceirizadoras e de consultoria acharam que apenas mudando o nome de Help Desk para Service Desk (SD) elas estariam aptas para competir no mercado profissional da nova TI. Como já ficou claro que estas são absolutamente incapazes de entregar os termos do SLA dos contratos para a abertura e acompanhamento dos chamados, elas apelaram para mais uma falácia para ver se é possível salvar alguma coisa.

 

É absolutamente impressionante como o cenário degringolou após o batismo para Service Desk de um Help Desk medíocre.  Os falsos profetas não dizem por conveniência que as pesquisas de satisfação apontam um profundo desagrado com as entregas do SD. Telefones sempre ocupados, atendimento absolutamente padronizado e sem relacionamento com a realidade,  explicações sem nexo algum e profundas inconsistências nas afirmações.  Este é um aspecto muito crítico, pois cada um dos analistas fala de uma realidade completamente diferente. Uma nova chamada para a central gera uma resposta completamente diferente para o mesmo problema ou chamado.

 

A insatisfação dos usuários com a central não esta relacionada com uma demanda por autoatendimento ou autosserviço, mas sim com a profunda incapacidade do SD de entregar os termos explicitados no SLA. A tentativa dos falsos profetas de mudar o foco para o custo e SLA é pífia. Ela apenas revela que vendas falaciosas foram realizadas e que no mercado brasileiro de TI existem centenas de ilusionistas e iludidos. Muitos fornecedores nacionais de terceirização dizem que não conseguem entregar o SLA do contrato.  A pergunta que não quer calar é porque eles ofereceram este preço para o SLA solicitado na Request For Proposal do cliente? Em geral, eles respondem que era o único caminho para ganhar o contrato. É fácil perceber por que o mercado profissional vem excluindo os amadores que contratam os “derrotinhas de TI”.

O GIGANTESCO CUSTO DO AUTOSSERVIÇO

É consenso há alguns anos que no Brasil os profissionais qualificados de TI estão em falta. Em contrapartida existe uma enorme vastidão de falsos profetas que gritam aos quatros ventos os diversos benefícios inexistentes do autoatendimento e autosserviço. Em geral estas pessoas não são capazes sequer de enumerar as diferenças o autosserviço do autoatendimento. Elas apenas espalham falácias. A moda delas agora é gerar barulho sobre a automatização do runbooks. Para os profissionais despreparados a automatização é condição necessária e suficiente para a redução do custo. Na lógica dos exploradores de falácias, a eternização do desperdício de dinheiro resultante da automatização de uma cara solução ruim e pobre é apenas um detalhe.

 

Recentemente a Anatel divulgou uma nova regulamentação para as operadoras de telecomunicações. O artigo “Cancelar serviço de tele será automático” (http://www1.folha.uol.com.br/fsp/mercado/153197-cancelar-servico-de-tele-sera-automatico.shtml, acessado em 20/03/2014) revelou que as operadoras estarão obrigadas a oferecer por autoatendimento (não é autosserviço) o cancelamento de serviços de telecomunicações. As operadoras lutaram com extrema força e intensidade contra esta automatização.

 

As perguntas que não querem calar são: “Porque as operadoras não querem os benefícios de redução dos custos do autoatendimento propagandeados pelos falsos profetas?”; “Porque é preciso uma intervenção da agência reguladora para automatizar o processo de cancelamento dos serviços se existem as enormes vantagens afirmadas pelos defensores do autoatendimento e autosserviço?”.

 

A resposta para estas duas perguntas é uma só. Existe um gigantesco aumento de custo com o autoatendimento para o cancelamento de um serviço. O fato dos falsos profetas terem dificuldades com os conceitos de autoatendimento e autosserviço e em fazer contas elementares em nada muda esta realidade. É provável neste momento que os leitores queiram saber como o custo das operadoras aumenta com o autoatendimento do cancelamento dos serviços pelo usuário contratante. A resposta é bem simples e óbvia para todos os que já solicitaram o cancelamento de um serviço via central de atendimento de uma corporação. Uma das primeiras perguntas que é feita para o usuário é o motivo do cancelamento. A resposta para esta pergunta direciona a política comercial da operadora. Por exemplo, existem muitos casos onde a operadora de crédito estorna a necessidade de pagamento da anuidade do cartão de crédito em função da solicitação de cancelamento pelo usuário. Em outros casos as operadoras de telecomunicações oferecem vantagens e descontos para o usuário para evitar o cancelamento. Em todos estes casos as operadoras estão trabalhando com o custo da perda de um cliente. Este é o real motivo das operadoras quererem o atendimento humano para o cancelamento dos serviços.

 

No Service Desk de TI existe o mesmo fenômeno de custo superior para as solicitações e reclamações dos usuários. A existência de organizações internas e terceirizadoras de Service Desk absolutamente incapazes de trabalhar na realidade da segunda metade do século XXI revela porque tantos defendem falácias. São empresas que vivem eternamente da busca de milagres para resolver o seu problema de falta de capacitação. No passado o problema era o custo dos encargos trabalhistas. Veio a lei da desoneração da folha de pagamento e nada mudou para estas companhias. Elas eram fracassadas e continuaram sendo. Agora eles buscam o milagre da automatização do runbooks e autoatendimento e autosserviço para resolver o seu problema de capacitação. Novamente é um caso aonde do fracasso elas vieram e no fracasso elas permanecem. São empresas que não entenderam ainda que precisam contratar os profissionais formados nas boas escolas de engenharia e não os “derrotinhas de TI”.

 

É simplesmente impossível revolver problemas de capacitação e éticos com pessoas despreparadas e sem valores. Não importa o estado da arte da tecnologia em uso. Seguir as falácias dos falsos profetas como resposta aos problemas é apenas uma escolha fácil e inútil. As operadoras de telecomunicações também querem o atendimento humano e não automatizado para o cancelamento dos serviços porque elas sabem o alto valor deste canal de comunicação. As informações oferecidas pelas pessoas no ato do cancelamento são usadas para direcionar os investimentos delas. O Service Desk de TI precisa da humanização do atendimento das requisições, reclamações e cancelamentos para identificar os lugares onde a organização de TI precisa investir e onde deve desinvestir.

 

O gerenciamento do ciclo de vida dos serviços é feito com base nas novas solicitações, cancelamentos e reclamações. É evidente que é preciso ter profissionais no Service Desk adequadamente capacitados para realizar esta tarefa. Muitas empresas terceirizadoras oferecem apenas um HELP DESK com o nome de SERVICE DESK. Elas formam o chamado mercado das falácias onde ilusões são vendidas e compradas. Muitas empresas com enormes deficiências éticas e de capacitação sustentam os mercadores das falácias. Normalmente, as empresas terceirizadoras de baixa qualidade e preço usam o estratagema do falso Service Desk nas vendas. Quando questionados tanto os vendedores como os compradores das falácias se defendem com a famosa desculpa perpetuada pelo “molusco mor brasileiro” do não sabia ou com a tradicional desculpa da cultura nacional.

 

Na pratica a maioria dos que buscam os milagres dos falsos profetas apenas não tem capacidade para fazer. Eles usam as muletas das falácias para não fazer e para impedir os capacitados e éticos de fazer, pois se os formados nas boas escolas fizerem do Service Desk uma organização preparada e lucrativa vai ficar clara a incompetência deles. Em resumo os mercadores de falácias não fazem e não querem que os outros façam porque isto evidenciaria a precariedade intelectual deles. Lamentavelmente tal postura é dominante no Brasil e o resultado é um Service Desk que emprega apenas jovens inexperientes de baixo salário e produtividade e não oferece perspectiva alguma de carreira. As empresas perdem milhões de Reais anuais com tal escolha. É muito fácil perceber a diferença existente de Service Desk pela comparação entre a realidade dos Estados Unidos e do Brasil. Basta olhar o público presente no congresso do HELP DESK INSTITUTE. Nos Estados Unidos é comum uma presença em massa de cabelo branco nos congressos. Isto significa que os profissionais desenvolvem a sua carreira dentro da organização do Service Desk. No Brasil, a presença de cabelo branco na plateia é extremamente limitada e quase nula. Mesmo entre os palestrantes é rara. Este é o maior indicador de falta de plano de carreira e profissão de iniciantes. Enquanto nos EUA a central de serviços gera lucro, no Brasil é um centro de custo. É bastante óbvio que o estratagema americano de qualificação de longo prazo tem um resultado muito melhor do que o brasileiro. Infelizmente muitos não querem enxergar o óbvio e instem no enxugamento do gelo dos “derrotinhas de TI”. Para eles só resta o bordão: “Que venham as falácias”.

Controle de qualidade para o prazo de um projeto de TI

Um caminho para avaliar se o controle do prazo do projeto é bom é a comparação com um padrão de mercado. Os consultores em gerenciamento de projetos de TI e os gerentes do escritório de gerenciamento de projetos sabem que os controles do prazo dos projetos tem enorme peso na variação na qualidade da iniciativa. Não é obrigatório que um gerente de projetos certificado com vários anos de experiência saiba desenvolver um bom cronograma para os projetos. A avaliação do cronograma pode ser muito subjetiva se não existir um conjunto de critérios objetivos.

Todas as organizações com um escritório de projetos bem estruturado tem um conjunto de princípios gerais da qualidade para o cronograma. A revisão dos prazos com base nas diretrizes evita uma grande parte do impacto dos defeitos nas entregas do projeto (nunca deve ser esquecido que o prazo de um projeto é um modelo que estima os acontecimentos futuros e ele deve refletir a realidade o máximo possível). O Defense Contract Management Agency (DCMA) oferece uma lista de 14 pontos que pode ser utilizada para a avaliação da qualidade dos prazos do projeto. O DCMS faz parte do Department of Defense (DoD) do governo federal dos E.U.A e trabalha com os fornecedores para gerenciar o tempo, custo, e desempenho dos projetos.

O calculo da qualidade dos controles das métricas de prazo leva em conta todas as atividades, o prazo real das tarefas completadas, as ações incompletas, as estimativas de comparação e as dependências do cronograma. O controle da lógica do prazo avalia se as todas as tarefas precedentes para a execução de uma atividade foram realizadas e finalizadas. Em um projeto existe uma cadeia logística de atividades que deve ser realizada em uma determinada sequência, por isto um bom projeto não deve ter tarefas órfãs. Em geral todas as atividades tem no mínimo uma ação prévia ou sucessora. Um bom controle de qualidade do prazo ocorre quando até 5% das atividades são tarefas do tipo “lógica ausente”.

O Controle das estimativas dos prazos precisa que os valores sejam os mais realistas possíveis. Trabalhar com um colchão de segurança para o prazo de cada uma das atividades impacta o caminho crítico do projeto e impede o desenvolvimento de soluções inteligentes. As margens de segurança do prazo devem ser trabalhadas se necessário depois da identificação do caminho crítico real. O controle da margem de folga dos prazos das atividades do cronograma é feito para minimizar o impacto no caminho crítico planejado do projeto. Um cronograma de boa qualidade tem menos de 5% das tarefas com folgas planejadas.

O controle dos tipos de relacionamento é feito para validar 90% das tarefas com relacionamento do tipo fim - início. O uso relacionamento tipo fim - início para as atividades permite o estabelecimento de um fluxo lógico para o cronograma. O controle das restrições é feito para todas as atividades com relacionamento do tipo precisa terminar antes, precisa começar antes, precisa começar até uma data específica e precisa terminar antes de uma data específica. A gestão das restrições faz com que a administração do cronograma do projeto seja dinâmica e possa ser facilmente atualizada. O controle das restrições identifica as tarefas incompletas que tem restrições de prazo. Um cronograma de qualidade não tem mais de 5% de suas tarefas com restrições.

O controle de altas flutuações nos prazo identifica todas as tarefas com variação total acima de 44 dias úteis. Uma tarefa com alta variação no prazo normalmente indica que esta faltando uma atividade predecessora ou sucessora. A porcentagem de tarefas com alta variação no prazo deve ser menor que 5%. O controle de flutuação negativa identifica todas as tarefas com flutuação menor que zero. Este controle identifica as tarefas que podem atrapalhar a conclusão de outras atividades dentro do prazo. Não pode existir no cronograma tarefas com flutuação negativa.

O controle de duração das atividades identifica as tarefas da base de comparação com prazo maior que 44 dias.  Os bons gerentes de projeto sabem que estas tarefas devem ser quebradas em atividades com prazo menor. O correto é que no máximo 5% das tarefas tenham duração acima de 44 dias. O controle dos dados invadidos identifica as tarefas com início ou fim antes do começo do projeto ou começo ou fim depois do encerramento do projeto.  A estimativa do início e fim das atividades deve ser feita depois do cronograma geral do projeto. O acompanhamento do cronograma do prazo não pode permitir datas futuras para as tarefas realizadas. Nenhuma atividade realizada pode ter data futura em um cronograma de qualidade.

O controle dos recursos identifica todas as tarefas que não têm os recursos humanos ou custos atribuídos. Um cronograma de qualidade tem todos os recursos para a execução das tarefas. O controle das tarefas perdidas é usado para identificar todas as tarefas que estão planejadas para terminar pelo acompanhamento do prazo realizado do projeto depois da data planejada para o encerramento da iniciativa. Durante o acompanhamento dinâmico das realizações do projeto é possível que existam tarefas que estão atrasadas. O gestor precisa assegurar o realinhamento do cronograma com os prazos da base de comparação.

O controle do caminho crítico avalia a integridade do cronograma usando o caminho crítico. O resultado esperado de um atraso de 1000 dias no caminho crítico é um atraso de mil dias na entrega do projeto. O cronograma passa pelo teste do caminho crítico se a data de encerramento do projeto é compatível com o atraso introduzido na duração do caminho crítico. O índice de comprimento do caminho crítico determina se a data de encerramento do projeto é realista em relação à data de entrega planejada. O índice do comprimento do caminho crítico precisa ser maior que 1.0 para passar no teste. O índice de realização da base de comparação compara a quantidade de atividades para data ao número de tarefas completadas em uma determinada data com as atividades planejadas para estar completadas nesta data. O índice deve ser maior que 1.0.

Resumo

Estes controles podem ser utilizados como um sistema de qualidade para avaliar e melhorar o cronograma do projeto.  Os critérios podem ajudar na avaliação da capacidade do fornecedor de desenvolver e entregar um cronograma robusto. Os bons gerentes de projeto sabem que existem péssimos cronogramas no mercado brasileiro. Os critérios do DCMA são uma ferramenta poderosa para medir a qualidade e utilidade do cronograma que elimina a subjetividade das análises. 

Anúncios na sua revista do Flipboard

Muitos pequenos produtores independentes de conteúdo precisam viabilizar economicamente os trabalhos para permitir a sua evolução e melhoria continua. É possível criar um catálogo próprio de produtos e serviços no Flipboard. A revista do seu blog pode virar uma fonte de descobertas de novas oportunidades. Com o Flip It bookmarklet é possível publicar à venda de produtos e serviços na revista.

Os produtos publicados na revista tem o preço anunciado permitindo que os leitores tomem decisões de compra. Lembre que é apenas um anúncio e os leitores vão realizar a compra no site de comércio eletrônico. É possível misturar os anúncios com artigos, fotos, vídeos e áudios criando  uma estória atraente. É fácil compartilhar o conteúdo com anúncios nas redes sociais e criar a cultura de uma nova revista semanal ou mensal. É simples trabalhar neste contexto com uma revista sazonal com conteúdo para a temporada de férias de verão. É uma nova direção para desenvolver um modelo de negócio novo sem custo algum e oferecer dicas excelentes para a sua comunidade.

A importância do usuário

Infelizmente ainda existem muitos que optam por ignorar as necessidades dos usuários nos projetos de TI. São milhares de casos de fracassos nos negócios por conta desta postura inadequada. O Black Friday do Brasil de 2013 é um exemplo claro onde necessidades foram ignoradas e negócios foram perdidos. Não é um caso único. É mais uma repetição de um erro que vem sendo cometido por décadas.

O final do ano é o momento onde o alto escalão das empresas está pensando nas decisões que vão favorecer os seus clientes. É um momento de virada onde as organizações estão pensando no que elas estão fazendo de errado e buscando alternativas. As companhias precisam respeitar o que os seus clientes sentem sobre a tecnologia utilizada, pois as pessoas com boas experiências falam com 15 pessoas e os com experiências ruins falam com 24 pessoas sobre o atendimento real e virtual.

O CIO precisa estar atento, pois os clientes internos tem o mesmo comportamento dos externos. Eles também falam sobre a sua experiência com a organização de TI. Eu tenho visto diversos casos onde o desenvolvimento de nova ferramenta para o usuário ignora totalmente as suas necessidades diárias. Os códigos estão sendo escritos, os prazos estão sendo cumpridos, mas ninguém está levando em conta a experiência que o usuário vai ter com a aplicação.

Todos sabem que os usuários não são os únicos influenciadores. Em um projeto existem vários influenciadores e patrocinadores que direcionam os resultados da iniciativa. Alguns deles podem demitir o gerente do projeto. Isto significa que é preciso um gestor com grande poder de orquestração e comunicação para caminhar com sucesso entre os diversos grupos. O gerenciamento das expectativas dos usuários passa por este equilíbrio. A organização de TI deve responder as necessidades dos usuários com facilidades que resolvam os desafios do negócio. Como os profissionais de TI não são os usuários da aplicação, eles tem uma dificuldade natural para capturar todas as necessidades dos requisitos. Por isto é tão comum eles ignorarem algumas e criar uma experiência do usuário horrível. De nada adianta desenvolver um produto tecnicamente funcional sem usabilidade prática. Por este motivo é fundamental escutar e envolver os usuários.

Para evitar o problema da comunicação é importante que o CIO pense como um usuário por algum tempo diariamente.  Os desenvolvedores precisam levantar da cadeira e visitar os outros departamentos para sentirem na pele as necessidades dos usuários e entender como eles usam e pretendem usar as ferramentas. O testemunho é um excelente caminho para aprender os requisitos. O gerente do projeto precisa ser capaz de entender a rotina da área onde a ferramenta estará sendo utilizada para compreender as necessidades sem precisar de um intérprete. É preciso Ir além dos detalhes técnicos para traduzir as necessidades dos usuários em projetos viáveis. São raros os profissionais com tais capacitações, por isto é importante reter estes talentos.

O gestor precisa fazer reuniões face a face com os influenciadores e impactados. É preciso superar possíveis medos e interagir olho no olho. Os encontros com os outros departamentos não podem ser oportunidades isoladas e únicas. Muitos projetos morrem porque existe uma única oportunidade para o usuário. O fale agora ou cale para sempre não funciona no desenvolvimento de aplicativos. Empresas como o Google trabalham o tempo todo com o público interno para encontrar o ponto de viabilidade de um projeto de projeto. É preciso explicar claramente o impacto de cada desejo para evitar rebuliços. As considerações sobre as prioridades da alta administração devem ser utilizadas para oferecer a perspectiva real do projeto para o usuário.

Para entender o ponto de vista dos usuários é importante pesquisar a satisfação dele com o processo de desenvolvimento. Em alguns casos as respostas dolorosas são de elevada utilidade no aprendizado do caminho do sucesso. Apenas não repetir erros anteriores faz com que o projeto de software melhore muito. A pesquisa é uma forma de valorizar e facilitar a participação do usuário no projeto. A pesquisa precisa ser honesta e sincera para gerar bons resultados de aprendizado e participação. O usuário não quer responder perguntas que são projetadas para respostas positivas. Nunca devem ser perguntadas na forma de sim ou não, as questões sobre os relacionamentos ou entregas. Peça sempre maiores esclarecimentos sobre estas respostas. Elas serão muito úteis nas próximas etapas do projeto.

Runbooks - Solução ou Problema?

Eu não tenho nenhuma estatística oficial, mas na maioria das organizações de TI que visitei no Brasil nos ultimos dois anos, o runbook vem sendo utilizado da forma mais medíocre possível. Os conceitos são mal entendidos, arquitetados e efetivados. O seu uso pode ser incrivelmente melhorado se existir o entendimento que é preciso menos falácia e modismo e mais planejamento e ação. Não é porque a organização de TI tem acesso a um novo martelo que tudo deve ser visto como prego. Não tem sentido algum usar um runbook quando a central de serviços precisa de um roteiro.

Não é porque esta sendo utilizado um runbook que acabou a necessidade de documentação. A base de conhecimento e inteligencia coletiva exige documentaçao. Eu conheço vários casos de pessoas que estão escrevendo runbooks que são apenas uma lista de ações para criar um operador virtual do sistema. Se por qualquer motivo existir uma falha não prevista e o processo fracassar não existe espaço para uma decisão humana. O pensamento inteligente pode evitar o aumento da gravidade e impacto do problema. O runbook está sendo utilizado nestes casos apenas um roteiro que esta sendo lido e executado por uma máquina sem inteligencia alguma.

Tipicamente os roteiros exigem a inteligencia de uma pessoa para que as coisas não vão de mal à pior. Quando um trem sai dos trilhos, as decisões e escolhas precisam da inteligência humana. As tecnologias são desenvolvidas para que as pessoas sejam mais produtivas. Não tem sentido algum converter uma açao mecânica que pode ser facilmente realizada por um script ou programa simples em uma tarefa informatizada que precisa de novos dispositivos. Não existe relação favorável entre o custo e o beneficio.

A automação do runbooks é um estratagema viável economicamente para a automatização do Service Desk quando os alertas de exceção explodem nos olhos de uma pessoa e as decisões são processadas por um cérebro humano e apoiadas pela infraestrutura. É evidente que os técnicos da central vão perder com o runbooks uma parte da execução de suas atividades desejadas do trabalho diário. Em alguns mais críticos vão aparecer problemas para reter os talentos mais proeminentes pela transformação de enfrentar um desafio profissional de solução de uma necessidade do negócio em um mero apertar de um botão. É de fato um problema motivacional concreto que muitas organizações de TI vão ter que enfrentar nos próximos anos. Em vários casos, o estratagema de manter a inteligência do processo e posicionar decisões no lugar correto é a melhor solução.

 

Isto significa que a automatizaçao dos processos da central precisa ser planejada com a visão da engenharia que endereça a necessidade dentro do prazo. A atuação de supetão que quer enfrentar um problema estrutural durante uma crise sem planejamento algum faz o negócio perder dinheiro e clientes. À improvisação em cima de improvisação nas crises gera blecautes graves, pois a falta de planejamento e documentação fazem com que o time de operadores não exerguem as soluções simples e fáceis. São diversos casos de fracassos onde o óbvio não foi feito e a recuperação automatizada não minimizou o impacto dos erros.

O sistema de monitoraçao dos processos precisa ser inteligente e dizer o que está errado. As exceções pela dificuldade dos computadores de contextualizar as informações derivadas de uma mudança do perfil do desempenho das aplicaçoes precisam de tratamento manual. Um exemplo clássico deste tipo de situação é a variação do número de visitantes em uma página de internet de um dia para outro. As visitas na página podem crescer centenas de vezes de um dia para outro por causa de uma reportagem no jornal ou televisão. É evidente que o tempo de resposta será completamente diferente. Apenas a capacidade de análise de um ser humano será capaz de capturar corretamente o entendimento da diferença de desempenho, compreender os motivos e trabalhar em um caminho eles de controle de danos. Todas as medidas da automação do runbooks vão ser ineficientes e ineficazes neste tipo de situação porque não foram previstas na automatizaçao destes processos.

Isto significa que em todas as monitorações são necessários olhos humanos, pois as pessoas conseguem ler os gráficos de desempenho muito melhor que os computadores. É a capacidade analitica delas de descobrir porque as coisas estão ocorrendo de forma diferente do planejado que gera a vantagem competitiva da monitoração assistida. As melhores monitorações da infraestrutura de TI são feitas pela vigilância das metricas de negócio como vendas projetadas ou quantidades de entregas. As metricas de baixo nível dos sistemas dificilmente conseguem explicar a totalidade do fenômeno e não servem como indicadores de previsão.

Infelizmente existem milhares de casos onde o runbook foi erradamente interpretado e desenvolvido. Sem a correta integração dos processos de negócio com o sistema de monitoração a utilidade da automação é muito baixa. As respostas do runbook precisam da inteligência humana para formar um poderoso sistema de compreensão dos problemas. Este caminho permite que os engenheiros da operação fiquem focados em descobrir o desconhecido do desconhecido em vez de gastar tempo em fazer o óbvio. Cada vez em que são descobertos os critérios de desempenho que sinalizam corretamente um problema é possível usar um runbook para monitor as condições automaticamente. Os modelos estatísticos podem ser usados para as análises de regressão e previsão para apresentar as alternativas do esforço de solução.

Os sistemas precisam adquirir urgentemente a capacidade de auto recuperação. É preciso que cada componente dos sistemas estejam integrados com a arquitetura de alta disponibilidade para que os administrativos e engenheiros construam uma infraestrutura correta sem repetição dos erros e fracassos passados. Em outras palavras o esforço do desenvolvimento de um código mais confiável do sistema exige ações que assegurem que o problema nunca aconteça. É evidente que existem falhas de prevenção difícil, por isto o começo deve ser com as falhas que podem ser fácilmente descobertas onde o sistema pode ser recuperado com muita traquilidade de forma automática. Em geral é o caso onde a maioria dos fatores e variáveis estão sob controle. Para os casos de causas complexos das falhas vai ser preciso estabelecer um processo interativo de melhoria continua entre correções e problemas para corrigir todas as falhas e eliminar todos os erros. Basicamente é um estratagema onde são eliminadas em primeiro lugar as situações onde ocorrem os problemas e depois é feito um esforço para eliminar os erros. Um sistema com indisponibilidade baixa para 80% dos casos tem disponibilidade total maior que um sistema com disponibilidade de 100% para 60% dos casos.

Este tipo de situação mostra que a central de serviços efetiva é capaz de escolher o melhor local para disputar as suas batalhas. Em todas as organizações de TI existem pendências e soluções de contorno para a causa raiz do problema.  As pessoas precisam ser motivadas para manter a operação para o usuário usando sempre que necessário uma fita adesiva e grampo nas soluções seguras. Não é errado trabalhar ao redor de uma situação específica para resolver de forma segura e estável e sustentável um problema. É sem sombra de dúvida um estratagema válido para manter a aplicação disponível. O problema em sí pode ser tratado em outra oportunidade com melhor relação entre o custo e o benefício.

A maioria das pessoas não acredita na idéia de sistemas com autorecuperaçao das falhas. Infelizmente existem muitos gestores que acreditam que a sua infraestrutura de TI é tão evoluída que as indisponibilidades por causas óbvias nunca vão acontecer com eles. Na prática não existe tal situação de evolução. Isto significa que a engenharia precisa ser criativa para manter o menor nível possível de indisponibilidade. A realidade dos erros e falhas é expressa no SLA formal ou informal. É o melhor mecanismo para comunicar a expectativa do nível de qualidade de um serviço.

É preciso entender que o controle das aplicações passa pelo usuário. Um exemplo clássico ocorre na plataforma do servidor da rede IIS da Microsoft plataforma. Existem situações de erros no gerenciamento das aplicaçoes porque o clássico ASP não é perfeito na liberaçao dos recursos utilizados se a codificaçao não for absolutamente precisa. Muitas vezes não é possível controlar o código dos programas adquiridos de terceiros, no entanto é possível monitorar os programas e reiniciar o gerenciamento das aplicaçoes quando os erros específicos na liberação dos recursos começarem a aparecer.

Vários sistemas operacionais, como Solaris e Windows resolvem automaticamente os erros. Sempre que um serviço falha ele é reiniciado. Se ele falha mais do que X vezes o serviço é indisponibilizado para que o administrador intervenha. É uma óbvia solução para alta disponibilidade. A automatizaçao da limpeza ou uso de técnica de otimização dos registros mais antigos do sistema de arquivo quando ele esta próximo da sua capacidade máxima é uma forma inteligente de usar o runbook para o autodiagnostico e antecipação da resolução do problema da grande quantidade de informações do volume. Também é possível trabalhar com tentativas controladas e automatizadas para subir os serviços que falharam por problemas na rede ao invés de esperar por uma nova tentativa no boot de amanhã.

A automação é muito útil quando é preciso explorar a facilidade das aplicações de registrar as mensagens de erro específicas no log e automaticamente identificar a falha e o problema e conseguir consertar e iniciar o serviço sem a intervenção humana.

Todas as organizações de tecnologia têm falhas comuns e repetitivas na sua infraestrutura. Nem todas estas falhas vão causar indisponibilidades especialmente se a infraestrutura é de alta disponibilidade. Por causa disto é preciso ser prático e realista e nunca fingir que as aplicações são perfeitas. A boa gestão não se ilude com o pensamento que a reinicialização da aplicação que falhou é uma solução boa o suficiente para resolver o problema. É preciso pensar e entender o que ocorreu. O runbook é muito bom para automatizar a solução de contorno, mas não deve ser entendido como resposta definitiva. Tipicamente o runbook é muito útil para a organização de TI e Service Desk para assegurar a correta execução do plano de contingência, orientar e coordenar as pessoas nas urgências, pois a automatização faz com que todos conheçam as suas responsabilidades pessoais, os níveis de escalaçoes e os limites em cada nível e para facilitar o entendimento dos processos dinâmicos com tantas variáveis que a documentaçao completa de todas as situações exige um esforço monumental do time. Em geral a completa automatizaçao é uma atividade que dura alguns anos nestes casos.

Os runbooks devem conter somente os conteúdos relevantes para ajudar as pessoas pela evolução da comunicação. Tudo o que foi documentado pode ser traduzido em códigos. Os códigos sem erros do runbooks permitem um comportamento da infraestrutura mais previsível e controlado. É uma clara situação de melhoria do Controle, Transparência e Previsibilidade (CTP) do ambiente.

Gerenciamento de Serviços de TI

O CIO pós-PC precisa priorizar tarefas, tomar decisões sobre os prazos com base em evidências reais. Ele também precisa cumprir as promessas, gerenciar os riscos, ser persuasivo, empreender soluções para os problemas e não ter medo de inovar. Os projetos de IT Service Management (ITSM) exigem que o CIO tenha menos orgulho da complexidade tecnológica existente e realize mais ações de simplificação. É fundamental para o sucesso de um projeto de ITSM o entendimento que ele é menos relacionado com a tecnologia e mais com os processos. É preciso entender um conceito que é óbvio, mas que é largamente ignorado. Se o gerenciamento de incidentes não funciona no papel, não é a tecnologia que vai resolver. Antes de baixar um pacote de melhores práticas como o ITIL é preciso fazer a lição de casa e envolver os influenciadores e as pessoas impactadas no desenho do projeto. Caso por qualquer motivo, o processo apresente falhas, o envolvimento e participação das pessoas, vai fazer com que seja possível identificar a causa raiz e encontrar uma solução de contorno. A inteligência coletiva vai permitir uma rápida evolução do processo e início de ciclo de melhoria contínua para cada interação.

 Falsos profetas

Como em todos os projetos vão existir forças de resistência. Muitas pessoas não vão colaborar e várias vão ter medo das novidades. Aprender a lidar com o medo do novo e dissonância cognitiva é fácil. A comunicação honesta e transparente gera o alinhamento político pelo entendimento. Membros da equipe que fingem adesão e tem atitude em relação ao projeto pautada apenas pelo sucesso ou falhas precisam ser reavaliados.

É preciso ter um time orgulhoso com a mudança proposta. Um projeto de ITSM pode ser extremamente difícil se membros da equipe entenderam que é melhor deixar as coisas como estão. É comum encontrar os caçadores de culpados que assumem que tudo o que foi descrito nos livros de melhores práticas deve ser seguido rigidamente para os novos processos e os problemas são sempre causados pelos usuários.

É preciso evitar a contratação para a equipe do projeto de profissionais sem capacidade de comunicação. Em geral, eles incapazes de manter o foco na tarefa programada. Também devem ser evitadas as pessoas que tradicionalmente mantêm uma agenda oculta em relação à iniciativa. Estes profissionais apenas pareceram que estão do lado do projeto. As incertezas em relação às motivações destas pessoas geram problemas que em geral são insolúveis. Também existem as pessoas que insistem que o projeto é apenas um truque de modismo ou marketing.

O perfil de membros da equipe que oscilam facilmente de posição conforme o sucesso ou falhas normalmente são a primeira causa da sabotagem da sustentabilidade de longo prazo da iniciativa de ITSM. Como todos nós sabemos, estas forças fazem parte da cultura organizacional das empresas. É este cultura que faz com que pequenas mudanças sejam sempre mal entendidas pela interpretação errônea.

Muitas vezes apenas os conceitos envolvidos criam tanta discussão e comentários que a ideia é inviabilizada. O tempo do CIO não pode ser monopolizado para responder perguntas como: Quando será feito? Porque ninguém o discutiu o assunto comigo? Quem vai decidir sobre as mudanças nos perfis profissionais? Estas situações causam danos graves aos trabalhos do projeto. O equilíbrio cultural de uma organização passa pelas pequenas coisas conquistadas diariamente pelas mudanças e ideias. As ondas de perturbação causadas pelas mudanças são dissipadas rapidamente pelo canal de comunicação permanentemente aberto. A colaboração coletiva das pessoas para os assuntos de ITSM fazem com que cada problema do processo de mudança seja seriamente entendido e resolvido.

TI oculta

É muito comum encontrar CIOs afirmando que existem sistemas ocultos rodando no ambiente suportado. Entregar qualidade comprovada para o desconhecido é muito difícil e é a causa raiz do fracasso de milhares de projetos de ITSM. Os usuários não querem saber se são sistemas ocultos que rodavam na infraestrutura sem o conhecimento do suporte ou se são programas identificados e plenamente conhecidos. Eles querem qualidade de entrega. Não são admitidas perdas com o projeto.

Isto significa que é preciso perguntar sobre todos os sistemas em uso no gerenciamento de configurações no início do projeto para que não existam interrupções nos sistemas porque foi adotada uma melhor prática. Um bom estratagema para evitar o problema da TI oculta é conversar com os donos dos serviços de negócio e descobrir quais sistemas estão sendo utilizados pela empresa em todos os locais. Redes de varejos precisam considerar as pequenas lojas também.

Uma vez identificados todos os sistemas é possível usar os padrões da ISO/IEC 20000 para determinar se a qualidade proposta endereça a necessidade. Se sim, o processo é formalizado. Se não, é desenvolvido um projeto de transição para o processo. Este é caminho mais efetivo para construir a confiança no projeto diante das incertezas da TI oculta. É preciso considerar tudo o que está trabalhando bem, endereçado as metas e satisfazendo os usuários no projeto de ITSM. Isto inclui a SHADOW IT.

Resistências

É preciso enfrentar as resistências contra o projeto ativamente. O principal objetivo deste trabalho é vencer o desafio de comunicar com clareza todos os aspectos do projeto e criar um balanceado nível de entendimento das motivações e resultados. É fundamental que os colegas percebam que o diálogo franco e direto é o melhor caminho e que o CIO está escutando com muito cuidado todas as observações. Todos na organização precisam descobrir pela coerência dos propósitos que o projeto não é uma ameaça para o seu emprego. O CIO precisa trabalhar com vigor para assegurar que o projeto endereça as expectativas e sentimentos de todos os impactados e influenciadores. Para fazer isto é preciso escutar com atenção todas as conversas. Sempre é bom deixar claro que todos estão no mesmo barco.

Gestão das sugestões

 

É muito provável que o CIO receba várias opiniões sobre o gerenciamento dos serviços de TI. O CIO deve ser capaz de escutar, mas precisa ter em mente que ele será cobrado pelo prazo de entrega do projeto e que todos vão cobrar o cumprimento do cronograma. Isto inclui os que fizeram sugestões. Nunca esqueça que a empresa em todas as esferas quer o projeto entregue. Existem razões diferentes, mas todos querem um final feliz. Isto significa que o suporte para os donos dos serviços e processos precisa ser planejado e entregue com todos lendo a mesma página do trabalho. As sugestões para a adoção do ITSM devem ser bem vindas, no entanto a chave para levar o projeto para o sucesso depende da habilidade de filtro e negociação para que as principais expectativas dos influenciadores sejam entregues dentro da proposta de orçamento, cronograma e qualidade.

Controle, Transparência e Previsibilidade (CTP)

É fundamental que o CIO seja claro e honesto com o projeto. É melhor ser honesto sobre os reais propósitos da iniciativa e não agradar a todos do que enfrentar um verdadeiro turbilhão de pressão das pessoas durante a execução do projeto. Nunca ceda à tentação de falar sim para tudo. Sempre use dados reais e confiáveis para tomar decisões. Usar a intuição para decidir vem comprometendo o sucesso de diversas iniciativas de ITSM. Busque sempre advogar as decisões com coerência, honestidade e transparência. O escopo e Service Level Agreement (SLA) proposto pelo projeto só pode ser alterado via gerenciamento de mudanças. O projeto não é uma receita de bolo ou conjunto de instruções ou corpo de conhecimento. Não faz parte do âmbito da iniciativa manter um esforço de flexibilidade pleno para o escopo. As alterações do escopo e gols devem ser feitas dentro do possível desde que não exista comprometimento da qualidade do projeto.

 

 

 

ERROS COMUNS NO DESENVOLVIMENTO DE SOFTWARE

Fuga da realidade

O gerente e time do projeto precisam ser capazes saber dizer sim e não para as solicitações de mudança do escopo. Em vários casos é preciso negar à mudança do escopo e colocar ela na fila da próxima versão ou atualização. É preciso entender que mudanças contantes no escopo mantam um projeto. A soma de diversas solicitações gera o problema do estouro. O conjunto de inocentes pequenas mudanças sem novos recursos e aprovações ampliam sobremaneira os requisitos do projeto e impactam o prazo, custo e qualidade. Mudanças contantes levam o prazo de entrega para muito longe do requisito inicial e aumentem fortemente os custos. Muitas vezes a qualidade do software é negligênciada pela falta de tempo para os testes.

Universo das mudanças

O primo problemático das mudanças contantes do escopo é a sua amplitude. Existem muitos projetos que são grandes demais e tem escopo com amplitude de cobertura demasiada. Em geral é melhor nestes casos escolher projetos de menor porte que avançam em passos menores até que o portfólio dos projetos entregue o escopo amplo desejado. É importante que o escopo trabalhado seja bem definido e fácilmente gerenciavel. Desta força é possível definir com clareza as tarefas necessárias para as entregas e estabelecer pontos para a passagem de bastão para o próximo projeto entregar o incremento do escopo total desejado. Em diversos casos os projetos massivos de dados como o big data fracassam pela complexidade ou pela dificuldade do usuário final de absorver tamanho volume de conhecimento. Em vários casos, as pessoas que cuidam do dia a dia da iniciativa não tem condições de aprender simultaneamente o software e as mudanças do negócio.

Comunicação pobre

Existem boas razões para não convidar todos os membros para todas as reuniões do projeto. No entanto, não existe justificativa para não comunicar com clareza as decisões tomadas. A maioria dos projetos de software fracassado passa por decisões discutidas e tomadas sem o conhecimento de todos os membros do projeto. O desconhecimento das decisões tem com como resultado um produto que não endereça os requisitos. Não tem sentido algum em manter requisitos secretos.

Foco na forma

Muitos projetos fracassam dramaticamente porque a funcionalidade real da aplicação é tratada com menos ênfase que o formato do painel de instrumentos. É muito fácil errar no endereçamento dos requisitos quando o formato do painel de instrumentos é desenvolvido antes da finalização de todas as funcionalidades requeridas pelo projeto. É evidente que se o alvo do projeto for desenvolver o formato de um painel de instrumentos, este objetivo deve ser entendido como a funcionalidade requerida.

Capital intelectual jogado no lixo

As falhas da gestão em escutar o capital intelectual colaborativo já levaram milhares de projetos de software para o fracasso. Muitos gerentes preferem fuzilar os mensageiros que querem ajudar na solução dos problemas enfrentados pelos desenvolvedores do que resolver o cenário descrito no conteúdo da mensagem. São pessoas que entendem que desconhecer o problema é o melhor caminho. Todos os gestores que pensam sabem que quanto mais cedo um problema for enfrentado, a sua solução será mais fácil e barata. A escolha de caminho não funcional para o gerenciamento limita o projeto do desenvolvimento do software. A demora excessiva para corrigir os erros encarece fortemente o custo total.

Alocação falha de recursos

Muitas vezes nos projetos fracassados, as pessoas contratadas para uma determinada atividade são desviadas para trabalhar em iniciativas completamente desvinculadas da proposta. Não é preciso ser um gênio em gestão de projetos que este desvio desnecessário gera atraso e aumento do custo.

Promessas exageradas

Prazos irrealistas e promessas otimistas ao excesso dos vendedores são duas das principais causas dos fracassos nos projetos de software. Muitos profissionais falam “sim” para todos os pedidos dos usuários sem pensar nas conseqüências de médio e longo prazo. Este é o caminho mais rápido para a insatisfação, frustração e decepção. Projetos conduzidos irresponsavelmente rapidamente naufragam. Em geral. Nestes casos, o time de desenvolvedores passa a gastar todo o seu precioso tempo justificando os prazos pouco realistas.

Tecnologia errada

Muitos desenvolvedores ávidos por novidades escolhem tecnologias inadequadas para os projetos de software. Bons programadores conseguem equilibrar as ações e resultados com as novidades. A nova tecnologia oferece vantagem relevante para o projeto? Esta sendo adotada uma tecnologia que já apresentou problemas em outros países? Não é fácil escolher o estado da arte correto da tecnologia de um projeto de software. Este é o principal motivo pelo qual é preciso selecionar um time experiente formado nas boas escolas de engenharia para levar o projeto para o sucesso. Muitos desenvolvedores inexperientes ou despreparados escolhem para os seus projetos de software tecnologias em estado beta lançada no mês passado para não ter custo de licenças. Em todos os casos este estratagema é o caminho mais rápido para o fracasso.

Fazer ou comprar

Muitos desenvolvedores preferem projetar e desenvolver as suas próprias ferramentas de gestão e bibliotecas de rotinas padrões. Uma das principais desvantagens de reinventar a roda em relação aos frameworks e biblioteca padrões é a perda da inteligencia coletiva do mercado. Ferramentas de gestão e bibliotecas de rotinas padrões de mercado são otimizadas no desempenho e qualidade. É possível economizar muito tempo e dinheiro em desenvolvimento e testes com a utilização de soluções prontas de mercado. O desenvolvedor que não reinventa a roda e foca o seu tempo na essência do software gera um resultado melhor e mais barato. Os engenheiros experientes formados nas boas escolas de engenharia são excelentes desenvolvedores porque eles têm a mente de empreendedores na execução das tarefas dos projetos. Eles não perdem tempo. Eles usam sempre que possível rotinas otimizadas de alta qualidade.

Protótipo errado

É algo óbvio, mas infelizmente é um erro comum. O time de desenvolvimento que esta trabalhando no protótipo de uma aplicação precisa escrever funcionalidades iguais ao sistema do projeto real. A línguagem e tecnologia do protótipo podem ser diferentes do sistema que está sendo projetado, no entanto, as funcionalidades precisam ser iguais para que o trabalho não seja jogado fora. O protótipo é sempre uma imagem virtual do produto real que está sendo desenvolvido. Não tem sentido algum usar uma estrutura de banco de dados diferente no protótipo. Isto é apenas tempo e dinheiro jogado no lixo. Para fácilitar o protótipo é válido usar um banco de dados diferente do produto desde que seja possível fazer a sua migração de forma fácil e transparente. É um estratagema que reduz ao mínimo o trabalho no protótipo é permite maior velocidade na sua entrega para os usuários. As pessoas vão poder com isto realimentar o projeto com as suas impressões e com isto fazer ajustes e correções no escopo, nas funcionalidades e nas facilidades dentro do cronograma e orçamento previsto.

O datacenter é nosso. Com brasileiro não há quem possa.

Na última semana de Outubro de 2013 a Câmara dos deputados deve iniciar a votação do marco civil da internet. Depois do Snowden foi incluído no projeto um dispositivo para que os dados dos brasileiros sejam armazenados no Brasil. Foi revelado que o deputado federal Molon afirmou no dia 18 de setembro de 2013 que o governo do PT pretende obrigar o armazenamento dos dados dos brasileiros no Brasil pelas grandes empresas multinacionais de internet porque essa é a única língua que os Estados Unidos entendem (Relator do Marco Civil da Internet defende pressão financeira contra espionagem, http://www1.folha.uol.com.br/poder/poderepolitica/2013/09/1343807-entrevista-com-alessandro-molon.shtml, acessado em 29/10/2013).

Grandes empresas de redes sociais como Google, Facebook, LinkedIn e etc. serão afetadas com a medida, pois poderão ser obrigadas a construírem no Brasil datacenters. Em função da pressão contra as inconsistências da justificação, foi criada uma nova interpretação para justificar a medida polemica.  A argumentação da necessidade de segurança jurídica para o armazenamento dos dados dos brasileiros no Brasil (foi revelado que os partidários da exigência da instalação de centros de dados dentro do país entendem que é a forma de fazer com que as grandes empresas internacionais de internet cumpram a legislação nacional. Fonte: Com marco civil, governo vai insistir em armazenamento local de dados da internet, http://tecnologia.uol.com.br/noticias/reuters/2013/10/28/governo-vai-insistir-em-armazenar-dados-da-internet-localmente.htm, acessado em 29/10/2013) cai por terra quando olhamos as argumentações utilizadas pelo grupo de artistas “Procure Saber” para querer a censura nas biografias no Brasil.

Os artistas do grupo “Procure Saber” justificam a sua solicitação de manutenção da censura das biografias não autorizadas pela demora da justiça brasileira em julgar e condenar as inverdades que eventualmente fossem publicadas. Qual o sentido de postular mais uma atribuição para uma justiça brasileira que é extraordinariamente lenta?  Lembro que a clara inconstitucionalidade do plano Collor do começo dos anos 1990 não foi julgada pelo Supremo em 2013.

A base governista ainda não entendeu que a ausência destes datacenters no Brasil está relacionada com a fraca competitividade e produtividade nacional. Foi revelado que na opinião da Brasscom, o mercado de datacenters no Brasil vai crescer naturalmente pela evolução da competitividade (Armazenamento local de dados: a nova batalha no Marco Civil, http://idgnow.uol.com.br/blog/circuito/2013/10/25/armazenamento-local-de-dados-a-nova-batalha-no-marco-civil/, acessado em 29/10/2013).

O Brasil perdeu para o Chile o primeiro datacenter da empresa Google na América Latina por estes dois motivos.  Claramente o ambiente de negócios nacional é uma barreira para a indústria do conhecimento.  Foi revelado que o Calegari afirmou que o mercado chileno de tecnologia de informações é bem mais maduro que o brasileiro (Google escolhe Chile para seu primeiro data center na América Latina, http://computerworld.uol.com.br/tecnologia/2012/09/06/google-escolhe-chile-para-seu-primeiro-data-center-na-america-latina/, acessado em 29/10/2013).

É muito fácil observar este fenômeno na comparação entre a indústria de manufatura automotiva e a do conhecimento. Tanto para datacenter como para automóveis a indústria enfrenta problemas de impostos elevados e outras barreiras tributárias do Brasil em relação ao Chile. No entanto, estas limitações não impediram que os gigantes do setor automobilístico como a Mercedes escolhessem o Brasil para as suas fábricas.  Estas empresas fizeram tal escolha porque elas podem automatizar todos os processos e usar a mão de obra nacional apenas para as atividades operacionais.

No caso do datacenter a mão de obra precisa gerenciar a estrutura com conhecimento e inteligência para que os serviços oferecidos sejam de alta qualidade dentro do padrão mundial de empresas como a Google. A grande vantagem do Chile é que ele conta com engenharia forte e qualificados profissionais de TIC. O Brasil com engenharia moribunda e foco em certificados elementares não é competitivo em termos de qualificação. Este é o real motivo pelo qual as grandes empresas de redes sociais são resistentes em instalar um datacenter no território nacional.  Elas sabem com clareza das limitações da qualificação da mão de obra nacional.

A Câmara deveria olhar holisticamente o fenômeno e fazer as mudanças necessárias na indústria brasileira de educação.  As empresas como Facebook, Google LinkedIn e etc. vão em função da fraca competitividade e produtividade do setor de TI nacional escolher fechar a sua representação no Brasil e operar no seu modo inicial aqui no Brasil.  Foi revelado que o Garotinho disse que o Magrani afirmou que a exigência de armazenamento dos dados no país inviabiliza a operação atual do Facebook no Brasil (Facebook teme mudanças na lei, diz deputado Anthony Garotinho, http://www1.folha.uol.com.br/poder/2013/10/1361363-facebook-teme-mudancas-na-lei-diz-deputado-anthony-garotinho.shtml, acessado em 29/10/2013).

Para as grandes empresas de internet a mudança para o modo sem escritório de representação não é tão grande assim. É bastante claro que o grande perdedor desta disputa será o brasileiro. A Brasscom e a camara-e.net entendem que a obrigatoriedade no armazenamento dos dados dos brasileiros no Brasil impactará negativamente a competitividade do país durante algumas décadas (Armazenamento local de dados: a nova batalha no Marco Civil, http://idgnow.uol.com.br/blog/circuito/2013/10/25/armazenamento-local-de-dados-a-nova-batalha-no-marco-civil/, acessado em 29/10/2013).

Espinhos do big data

Até o momento muito tem sido falado sobre as vantagens do big data. No entanto, muito pouco é dito sobre as desvantagens. Com o big data duas pessoas ou até mesmo uma mesma pessoa usando dispositivos diferentes podem ter que pagar preços diferentes para os mesmos produtos nos portais de comércio eletrônico.  Isto acontece porque o preço ao consumidor está sendo influenciado pelo perfil. Usuários da Apple em geral tem na tela dos seus computadores preços mais caros do que outras plataformas.

 O consumidor precisa estar atento com esta nova característica do comércio digital para não pagar mais caro pelos produtos ou serviços apenas porque tem um perfil de maior rendimento. O big data oferece a vantagem da  individualização dos clientes. No entanto, este benefício deveria ser utilizado pelos gestores para  aumentar vendas e não para subir preços conforme o perfil. É evidente que esta distorção gerencial vai gerar no médio e longo prazo uma oportunidade de negócio.

Se um perfil de maior renda continuar a gerar um preço maior para os mesmos produtos no comércio digital,  então os perfis de menor renda serão utilizados para as compras digitais.  Estes perfis poderão ser utilizados por intermediários para oferecer descontos nas compras para as pessoas de mais renda e usuários Apple.  Eles podem viabilizar o negócio cobrando uma ínfima parcela da diferença de preços e entregar os produtos para as pessoas de maior renda.

A continuidade deste processo vai distorcer de tal forma a vantagem da individualização do big data que em vários ele vai perder à sua serventia. Os portais de comércio digital precisam urgentemente revisitar à sua estratégia antes que o mercado responda com a inviabilização do investimento no big data. Para o momento é recomendável que os consumidores consultem os preços dos produtos e serviços utilizando computadores e perfis diferentes para que não paguem preços mais caros pelos produtos e serviços adquiridos.

FUTURO DA NUVEM

A revolução da nova TIC baseada em serviços e conexão total esta fazendo com que a internet das coisas cresça em velocidade abismal. Por volta de 2025 teremos nuvens conectando e integrando todos os objetos à nossa disposição. Isto inclui os objetos de uso pessoal como carros, relógios, roupas, sapatos, óculos e etc. De uma forma planejada ou não, as pessoas vão ser o centro do universo virtual. Tudo o que os nossos olhos veem poderão ser processados e armazenados nas nuvens por exemplo.
 

Apesar da aparência, não será uma conexão do cérebro com a nuvem. O cérebro humano vai comandar interfaces sensoriais dos diversos dispositivos através dos olhos, voz, mãos, nariz, expressões e etc. É possível afirmar que as pessoas vão comandar um exocerebro. A mão dupla da comunicação vai amplificar os sentidos humanos. As pessoas vão poder processar o que está acontecendo nas suas costas ou até mesmo escutar conversar distantes por exemplo. Isto significa que a capacidade cognitiva do cérebro humano vai ser catapultada para um nível superior pela ampliação do reconhecimento. Ao ver uma pessoa o óculo pode imprimir na tela a sua ficha e alimentar o cérebro da pessoa com várias informações.

As nuvens acelerarão a evolução da tecnologia para uma velocidade enorme. Com os bilhões de padrões para os comandos de voz armazenados nas nuvens, os engenheiros podem desenvolver interfaces de comunicação cada vez mais simples e naturais. É possível acreditar em décadas cada vez mais prosperas para as tecnologias mais promissoras. O carro inteligente é sem sombra de dúvida uma conquista bastante próxima. Até o ano de 2020 ele estará circulando nas ruas e estradas.

O nível avançando da capacidade interativa da tecnologia habilita uma intensa integração do ser humano com o exocerebro. Os segredos da linguagem corporal vão ser revelados para os interlocutores em tempo real e um observador externo poderá chegar facilmente à falsa conclusão que a tecnologia chegou ao estágio de ler mentes. Na realidade existe apenas uma técnica de Big Data para a leitura corporal. Eu não tenho dúvida que em 2018 este tipo de tópico vai ser o centro da atenção da participação do grande público.

O saber profundo recorrente da linguagem e cognição corporal vai fazer parte da hierarquia dos modelos de previsão e a nuvem vai ampliar os sentidos humanos na habilidade de comunicação. O relacionamento com coisas como lojas, produtos e serviços vai ser baseado na eliminação da distorção das informações. Os relacionamentos e conversas vão acontecer em patamar diferente, pois tudo poderá ser gravado indexado e armazenado. As facilidades de recuperação das informações vão inibir as mentiras.

A ligação em tempo real da nuvem com as pessoas vai influenciar todas as discussões. A fortificação da presença dos fatos vai destruir em segundos os achismos, ilusões e delírios. O mundo vai parecer daqui a 30 anos um lugar completamente diferente do que é agora. O esquecimento vai acabar. Ou as pessoas fazem ou deixam de fazer algo. Sempre será uma escolha. Uma Parte das manchetes filosóficas vai ter forte implicação ética. Qual será o limite da privacidade onde tudo pode ser gravado e recuperado? Qual o papel do governo? O que é previsão e o que é bisbilhotice? Certamente o mundo novo não será um lugar onde é fácil notar a diferença entre o cérebro e exocerebro que é apenas um supercomputador capaz de reagir à consciência humana.

A simplificação conceitual pode levar para distorções fascinantes. Os fundamentos sociais do exocerebro em nuvem precisam contemplar o fato que Mente humana é responsável pelas respostas da nuvem e a tecnologia é apenas um habilitador do reconhecimento milionário da natureza das coisas do mundo real. Os padrões de reconhecimento da linguagem corporal via sensores utilizados pela nuvem para descrever e revelar os processos cognitivos de várias atividades humanas permitem que o exocerebro crie um conteúdo animado do comportamento social. É preciso entender com clareza que a nuvem não é capaz de criar uma mente humana. Ela apenas oferece uma previsão de comportamento das pessoas em função do Big Data dos padrões. Na prática os computadores da nuvem estão apenas recitando para trás um alfabeto de pedaços de informações que estão armazenados.

Como existem centenas de milhares de padrões, o cérebro humano precisa do processamento do exocerebro para conectar os dados e entender as respostas. A essência da inteligência continua sendo privilégio humano. O reconhecimento de padrões com base na voz, imagem e temperatura corpórea é um trabalho para os programas que rodam em supercomputadores. É preciso combinar a análise estatística com a programação especializada. 

Não existe uma loja de conhecimento para a avaliação dos padrões. Apenas o cérebro humano que trabalha com um modelo hierárquico próprio e ainda desconhecido é capaz de entender o significado das informações e estabelecer relacionamento entre os dados entregues pelo exocerebro. A habilidade da nuvem de armazenar uma quantidade massiva de informações e estabelecer o relacionamento entre as variáveis permite o diagnostico dos padrões de reconhecimento da linguagem corporal e o envio imediatamente das diversas possibilidades. Neste contexto de consolidação das informações, A regra de aceleração do retorno vai fazer com que o cérebro humano encontre a resposta mais confiável entre as alternativas oferecidas pelo exocerebro.

Em 2020s o poder de fogo do processamento não invasivo será tão grande que a nuvem desempenhara o papel de exocerebro para armazenamento e processamento do conhecimento que a escola vai precisar ser reinventada. Toda esta capacidade extra alimentará a criatividade dos alunos ao extremo. Todos os que desenvolverem modelos mentais efetivos para a recuperação das informações em um oceano infinito de dados vão estar em enorme vantagem competitiva. É evidente que as interconexões no cérebro humano vão mudar de formato com o exocerebro da nuvem e estaremos diante de uma geração completamente diferente da anterior pré exocerebro.

Apesar do cérebro adulto já ter diversas interconexões sedimentadas por ligações químicas várias conexões redundantes vão ser desfeitas com a nuvem e o ciclo da aprendizagem adulta também será reformatado para um novo modelo com base na utilização de computadores externos. A lógica de uma loja de varejo vai mudar completamente o processamento de dados na nuvem iniciado por um smartphone. A eliminação de atividades repetitivas de cobrança e pagamento vai fazer com que os estratagemas das lojas fiquem focados no cliente e nas vendas. O exocerebro vai mudar por completo o formato do varejo.

Os óculos digitais podem ser utilizados para rastrear o produto ou serviço e informar o nome das pessoas envolvidas, as condições de trabalho, as perdas e desperdícios de energia e a preservação ambiental. Dentro de cinco anos este tipo de tecnologia será comum para todos os membros da cadeia produtiva. Os consumidores poderão os preços nas lojas próximas e internet em tempo real. As informações rápidas entregues pelo exocerebro as pessoas vão mudar comportamentos e decisões. O carro digital é outro exemplo de mudança no varejo. Ao parar no estacionamento do estabelecimento, a loja ou as lojas recebem a lista de compras do cliente e o consumidor recebe de volta no vidro frontal as resposta sobre a sua lista. Ele pode aprovar as compras dentro do carro e ficar esperando pela entrega ou pegar os produtos na loja. Se o varejo for um posto de gasolina, a loja recebe as informações sobre combustível, água, óleo e etc. E pode realizar todos os procedimentos de forma automatizada.

A nuvem vai fazer com que o oceano infinito de informações seja vasculhado pelo exocerebro com critérios bem definidos. O varejo terá mais informações do imaginou sobre os seus clientes. O processamento em tempo real vai gerar vantagens competitivas muito além do que o menor preço. Reconhecer um cliente, familiares e necessidades vai fazer toda a diferença. O grande problema do excesso de informações é que ele é um manto de invisibilidade. É o mesmo efeito que nunca ter visto. O varejo que conseguir integrar e indexador o vídeo interno da sua loja com a capacidade de pagamento do cliente e os anseios e desejos registrados na nuvem vai ser capaz de vender em 2025 muito mais que os seus concorrentes. Até mesmo o computador que projeta a música ambiente da loja pode ser programado para compor o estratagema próprio da loja. A inteligência e conhecimento vai fazer muita diferença nas próximas décadas.