User eXperience (UX)

Recentemente estive conversando com um amigo que transita entre São Paulo e Rio de Janeiro. Estávamos conversando sobre os planos para 2015 e para a minha surpresa ele pretendia trabalhar com UX a partir do segundo semestre de 2015. Foi uma revelação surpreendente porque o assunto Experiência do Usuário que é bem conhecido nos países mais avançados está em estágio embrionário no Brasil.

A visão nacional do atendimento ao consumidor é muito parecida com a que foi apresentada no artigo “Por que o atendimento ao cliente continua ruim – parte 1” (http://www.4hd.com.br/blog/2015/01/07/por-que-o-atendimento-ao-cliente-continua-ruim-parte-1/, acessado em 26/01/1015). O Roberto Cohen traduziu e reproduziu partes do artigo “WHY IS CUSTOMER SERVICE SO BAD?” publicada na revista “A CROSS THE BOARD, JAN/ FEB 2006” que detalhou os motivos para o atendimento ruim (Inexistência de concorrência, Marca concorrida, Mini monopólios e Preço baixo).

Questões como monopólio, poder da marca e etc. foram citadas como motivos para a ausência de investimento no atendimento ao usuário. Naquela época em 2006 existia uma lógica racional por traz destas escolhas. No entanto, será que estas motivações ainda prevalecem em 2015?

Um dos setores que mais cresceram nos anos do pífio crescimento do PIB brasileiro do governo Dilma é o e-commerce. O maior desafio do comercio digital é conquistar a confiança dos consumidores. Muitos são arredios ao e-commerce pelos escândalos de segurança. Todos os dias os brasileiros são bombardeados de notícias ruins sobre invasões de sites e vazamento de informações sensíveis dos consumidores.

A conquista da confiança passa pela credibilidade do ponto de venda. E a credibilidade é consequência do pré-venda, da entrega e do pós-venda. Em outras palavras, a credibilidade do comércio digital está diretamente ligada com a experiência do usuário. Este é o real motivo deste tema ter alcançado a dimensão que alcançou nos Estados Unidos e Europa. Umas das consequências deste estratagema é o elevado faturamento das lojas de roupas destes países com os turistas brasileiros.

Uma experiência do usuário dentro do prometido gera tamanha satisfação para o consumidor que ele se sente compelido a compartilhar a experiência escrevendo um comentário sobre a empresa em sites ou redes sociais. Este é o caminho para a confiança. Os não consumidores leem os comentários compartilhados e passam a ter confiança nas promessas daquele ponto comercial.

Quando encontramos americanos e europeus investindo bilhões de dólares em experiência do usuário, eles não estão agindo feito loucos que queimam notas de 100 dólares. Eles estão na realidade encontrando novas formas de ganhar mais dinheiro.

Espero que tal qual o meu amigo muitos se juntem à onda da experiência do usuário e ganhem muito dinheiro com os novos negócios.

Como exemplo prático de experiência de usuário vou usar um caso que aconteceu comigo. Recentemente eu ganhei uma camisa de uma marca que eu não conhecia. Ao abrir a caixa tinha um enorme destaque para a mensagem que dizia que aquela camisa foi confeccionada com mão de obra legalizada e que em toda a cadeia produtiva existe um rigoroso controle para que não exista mão de obra escrava. Era apenas uma mensagem, mas diante dos escândalos de mão de obra do setor têxtil brasileiro eu me senti mais feliz e satisfeito ao saber que estarei usando uma camisa que não é o resultado da exploração humana. Isto é concretamente um caso de experiência do usuário. Eu já considero esta marca nas minhas compras de camisa e a recomendo. Este é o efeito cascata positivo da experiência do usuário.

A questão da Experiência do Usuário é tão intensa na indústria têxtil que ela está mudando o perfil de compras dos brasileiros. O artigo “Viajantes brasileiros compram no exterior R$ 12 bilhões em roupas” (http://www1.folha.uol.com.br/mercado/2014/10/1530175-viajantes-brasileiros-compram-no-exterior-r-12-bilhoes-em-roupas.shtml, acessado em 26/01/2015) revelou que os brasileiros compraram 5 bilhões de dólares em roupas no exterior em 2014 (60 mil toneladas em roupas). Este valor foi praticamente o faturamento anual das quatro maiores redes de varejo têxtil (Riachuelo, Renner, C&A e Marisa) em 2014. Claramente as pessoas estão buscando um nível de experiência que não é oferecido no Brasil.

Como exemplo das barreiras criadas pela Experiência de Usuário negativa, eu vou usar novamente um caso que ocorreu comigo no dia 26/01/2015. Eu estava esperando para atravessar uma rua até a abertura do farol de pedestres. Neste instante um carro moderno e luxuoso parou em cima da faixa de pedestres me obrigando ao desvio. O motorista sem qualquer pedido de desculpas ou início de frase com “por favor” perguntou uma informação sobre qual direção deveria tomar para chegar em uma determinada rua. Eu respondi sem interesse algum de ajudar que era só seguir em frente e fui embora deixando ele falando sozinho. Não dei uma informação errada, mas sabia que a mesma não ajudaria em nada. A principal consequência da Experiência de Usuário negativa foi o meu total desinteresse na colaboração com ele.

Nas empresas temos nitidamente o caso da Experiência de Usuário negativa na organização de Tecnologia de Informações e Comunicações (TIC). Muitas vezes os jovens analistas que são nativos digitais nutrem tantos preconceitos sobre serem experts de TIC apenas porque nasceram na geração digital que ignoram o que está sendo dito pelos mais velhos de cabelos brancos que são nativos analógicos. Estas posturas geram experiências ruins e raramente as organizações de TIC das empresas recebem elogios espontâneos dos seus usuários.

Para quem quiser saber mais sobre User eXperience e Customer experience (CX) seguem-se alguns endereços interessantes:

http://en.wikipedia.org/wiki/User_experience

http://uxmyths.com/

http://en.wikipedia.org/wiki/Customer_experience

https://hbr.org/2013/09/the-truth-about-customer-experience

Previsibilidade no Software

Quando pensamos que os falsos profetas de TI estão no ostracismo, eles aparecem com mais falácias para tentar enganar as empresas usuárias de Tecnologia de Informações e Comunicações (TIC). Em 2014, foi publicado no Brasil um artigo que afirmava que era impossível prever o custo e prazo do desenvolvimento de um software usando o Agile Software Development por causa de diversos aspectos. Uma das dificuldades apontadas era a comunicação na língua brasileira. Segundo o autor, a língua nacional dificulta o entendimento das regras de negócio pelo analista de desenvolvimento.

Em geral, escolas ruins formam e diplomam profissionais pobres. É um fato lamentável, mas faz parte da nossa realidade. No entanto, é preciso ter claro entendimento de que as dificuldades dos profissionais em comunicação e expressão não tem relacionamento algum com a falta de previsibilidade do custo e prazo do desenvolvimento de um software. Profissionais despreparados geram resultados pobres, por isto, a sua contratação significa na prática jogar dinheiro no lixo.

É muito comum a situação onde um profissional despreparado resolveu um problema e criou dois ou mais. Também é comum este perfil criar diversos problemas sem sequer arranhar a solução do desafio inicial. Infelizmente na área de TI no Brasil existem muitos profissionais totalmente despreparados para trabalhar em 2014. Estas pessoas trabalham como se ainda estivéssemos no ano 2000. Todo profissional qualificado e gabaritado de TI sabe que antes de escrever o código ele precisa traduzir em um fluxo todas as informações fornecidas pela empresa usuária. Este fluxo precisa ser testado em relação à realidade operacional do solicitante para identificar as falhas e esquecimentos. Não importa se as entregas serão feitas em módulos pequenos. É preciso que o fluxo esteja claro tanto para o desenvolvimento, como para os usuários do software.

É desta forma que os profissionais formados nas boas escolas de engenharia conseguem desenvolver aplicações com previsibilidade de custo, prazo e qualidade. Estas pessoas têm pleno conhecimento da operação do negócio e dos aspectos técnicos do desenvolvimento de software. Os mercadores de falácias querem iludir o mercado com a falta de previsibilidade, porque eles não conseguem entregar o que prometem nas propostas. Estes prestadores de serviços de desenvolvimento vivem em um mundo de ilusões e enganações.

O Agile Software Development permite a previsibilidade nas entregas do desenvolvimento de software pela modularização e reutilização de códigos. O uso da biblioteca de rotinas permite ao desenvolvedor trabalhar com as peças testadas e aprovadas para criar novas funcionalidades. É possível estimar com alta dose de acerto o custo e prazo das entregas. Também é possível repetir estes passos infinitas vezes com o mesmo resultado. Nunca na história de TI o desenvolvimento de aplicações de software foi tão previsível.

Inovação na TI brasileira

Os Chief Information Officer´s (CIOS) brasileiros já revelaram em reuniões, congressos, artigos que estão sendo pressionados para apresentar inovações nas organizações que trabalham. A maioria deles declarou que as restrições orçamentárias são a maior barreira para as inovações. Os CIOS alegam que tem dinheiro apenas para manter os sistemas atuais funcionando. Eu não tenho dúvida alguma que o orçamento de Tecnologia de Informações (TI) é curto. Em 2007 afirmei que isto iria ocorrer caso as práticas equivocadas na gestão da tecnologia continuassem. Infelizmente os livros de governança publicados não foram esclarecedores o suficiente para mudar a postura de fazer o mínimo possível. No entanto, será que os executivos de TI não estão mais uma vez usando a muleta da falta de dinheiro para justificar o fracasso da inovação da TI Nacional?

A regra básica para que os profissionais de TI consigam propor inovações é que eles entendam o negócio da empresa. As inovações não são meras trocas de tecnologia. Em outras palavras, elas não podem ser manifestadas em adoções primárias tecnológicas como por exemplo liberar o uso do iPhone ou trocar o Windows XP por Windows 8. O artigo “Autoatendimento com qualidade e relacionamento próximo do cliente” publicado na revista SupportWorld número 18 exemplifica mais um caso onde o entendimento do negócio inexiste. O texto mostra de forma destacada a seguinte afirmação: "O autosserviço reduz os custos, garante a disponibilidade a qualquer momento e em qualquer localização". Apenas no texto completo é apresentado de forma tímida que o autor está falando em redução significativa do custo com suporte técnico.  O artigo apresentou uma enorme gama de argumentos para justificar a hipótese favorável ao autosserviço. São justificações sem consistência alguma para o negócio. 

O texto abordou apenas a tecnologia pela tecnologia em todo o artigo. Todas as explicações foram baseadas em premissas sem sentido para o negócio. Existiu um claro despreparo empresarial, pois em nenhum momento foi feita a avaliação do custo total do autosserviço. A pergunta corporativa mais importante sobre o assunto (o que é melhor “reduzir o custo do suporte pelo autosserviço e aumentar o custo total do negócio” ou “manter o custo do suporte e reduzir o custo total do negócio”) não foi endereçada.

Em nenhum momento o artigo apresenta uma resposta para o desafio empresarial de reduzir o custo do negócio. A ausência da conta inteira do autosserviço revelou tanto o desconhecimento de importantes variáveis do negócio como a falta de disposição de sair da zona de conforto de tratar a tecnologia apenas pela tecnologia. O fracasso da inovação em um cenário onde o perfil profissional desconhece o negócio é inevitável.  Os CIOS que querem e precisam inovar precisam urgentemente ajustar o perfil profissional da sua equipe pela contratação de profissionais qualificados e experientes.

A formação de uma equipe de TI pela contratação de profissionais qualificados formados nas boas escolas de engenharia tem a vantagem adicional de contar com um time formado por seres humanos com valores éticos e morais elevados.  Pessoas honestas conseguem trabalhar facilmente em regime de colaboração e produzir inovações permanente. Inovar exige a inteligência coletiva multidisciplinar. Pessoas de confiança são capazes de trocar experiências em grupo e criar coisas novas. Não existe neste meio a pratica de furtar ideias. Um dos principais pilares da inovação é a confiança. Os CIOS nacionais que querem entrar no jogo da inovação precisam urgentemente revisitar as suas equipes. O salário pago para profissionais preparados gera elevado retorno em termos de inovações.

TI IMPORTA?

O atual momento dos modelos de previsões é de baixa. Os erros recentes nas previsões do último Super Bowl e Copa do Mundo de Futebol de 2014 elevaram o tom dos questionamentos. O aumento do nível de desconfiança é muito saudável, mas não pode ser usado como argumento para desacreditar todas as previsões. Uma das previsões mais famosas para a área de TI foi a do Nicholas Carr publicada no artigo “IT Doesn’t Matter” em Maio de 2003.

Todos os novos artigos e livros do Carr apontaram que o futuro da TI estava na direção da sua transformação para commodity e utility tal qual a energia elétrica ou água. Após apenas uma década as previsões do Carr viraram realidade no formato que eu chamo de Serviço de Valor Agregado de TI. Em 2014 é possível comprar TI como utility ou serviço de valor agregado de TI nas lojas virtuais da Salesforce, Amazon, Google, Apple e etc. A realidade corporativa do que é chamado pelo mercado de Bring Your Own App (BYOA) é a prova material de que os serviços de valor agregado de TI vieram para ficar.

É bastante claro que os usuários estão adquirindo estes serviços conforme as suas necessidades. Eles não precisam entender a infraestrutura e software que suportam os serviços.  Basta conhecer e entender as funcionalidades e facilidades. Este é o motivo pelo qual os usuários não precisam da área técnica de TI para decidir pela compra. A chamada Shadow IT ou TI invisível é a principal consequência deste fenômeno.

É impossível não reconhecer o acerto do Carr em relação à velha e ultrapassada Tecnologia de Informações e Comunicações (TI ou TIC). O mundo como estamos vivendo em 2014 é baseado na nova TI. A Tecnologia de Informações e Comunicações de serviços de valor agregado adiciona conteúdo ao negócio.  É evidente que o perfil profissional do departamento de tecnologia mudou. A nova TIC exige capacitações que explorem os recursos de Tecnologia de Informações e Comunicações para transformar e habilitar negócios.

Os profissionais precisam trabalhar como engenheiros que desenvolvem inovações com base nas peças básicas do lego formado pelos serviços de valor agregado. Um perfil de saber profundo é necessário. É preciso avaliar os custos e benefícios para identificar a opção de mais valia. Em alguns momentos será melhor trabalhar com a elasticidade e custo variando conforme o uso e em outros será melhor escolher um modelo de custo fixo devido ao elevado nível de utilização.  Mais do que fazer meras contas, a engenharia de TIC precisa estabelecer modelos confiáveis para prever a demanda futura.

Quanto melhor for esta inteligência corporativa de TI, maior será a capacidade do negócio de operar no ponto de menor custo e máximo lucro. Os profissionais do Service Desk vão desempenhar neste contexto um papel fundamental na engenharia da nova Tecnologia de Informações e Comunicações. Eles vão capturar as informações deste Big data e estabelecer o contexto adequado. Esta ação é fundamental para o estabelecimento do modelo de previsão do uso de TI e escolha das peças do lego que vão formatar o negócio digital.

É evidente que a central de serviços vai ser formada por profissionais formados em escolas de qualidade com muita experiência de vida. É um perfil muito diferente do que vemos atualização nos Help Desks que insistem em serem chamados erradamente de Service Desks. Na central de serviços da nova TIC, os profissionais vão ser valorizados pela sua capacidade de comunicação, inteligência e experiência.  Eles vão ocupar posições com visão de longo prazo dando fim ao ciclo de contratações de iniciantes formandos em escolas duvidosas com elevada rotatividade. A nova TIC prevista pelo Nicholas Carr chegou em 2014 com os serviços de valor agregado.

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. 

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.

 

 

 

SLA: Verdades e Mitos

Existe uma excelente noticia para o mercado brasileiro. O SLA que até pouco tempo atrás era um ilustre desconhecido, vem sendo debatido com intensidade pelos profissionais de TI. Infelizmente, a boa noticia acaba por aí. Muitos estão criando autênticos mitos sobre o SLA. Em alguns casos existe o imaginário que o SLA gera a imunidade contra as falhas e em outros está sendo parida a falsa ideia de que ele é capaz de conter custos ou estabelecer limites ou parametrizar negociações. Existem alguns casos em que o SLA descrito no contrato é visto como algo desconectado ao serviço entregue.

 O SLA de um serviço de TI nada mais é do que a expressão numérica da realidade da infraestrutura do fornecedor. Em outras palavras é obrigação do prestador de serviço definir realisticamente e objetivamente as condições de entrega. Fornecedores honestos e sérios oferecem os seus SLAs com evidencias de comprovação. É da competência do cliente verificar se os fatos apresentados são capazes de produzir o SLA ofertado. Se o cliente precisa de SLA diferente do oferecido ele tem que ter a consciência que o fornecedor terá que fazer investimentos na sua infraestrutura tecnológica e humana. Em outras palavras, não existe negociação de SLA. É muito raro que um fornecedor faça um investimento para entregar um SLA mais aprimorado para um único cliente. Os casos onde este cenário gera retorno de investimento são raríssimos.

 Entre as evidencias, o cliente deve avaliar o plano de negócio de cinco anos do fornecedor.  É este planejamento que permite que o cliente conheça e entenda como o SLA das entregas será mantido ao longo do tempo. Olhar o plano resolve apenas parte do problema, pois não existe fornecedor capaz de fazer entregas com variabilidade zero. Não adianta ter um contrato afirmando que o tempo de resposta para um chamado é de 10 minutos sem nenhuma variabilidade (por exemplo, +5% e -10%), pois todos sabem que durante um contrato de três anos em diversos momentos, o tempo de resposta será diferente. Este tipo de contrato só gera conflitos e descontos. Este é o motivo porque existem tantas reclamações, multas e quebras de contrato na terceirização no Brasil.

 Se o fornecedor não apresenta um plano de negócio, então o melhor caminho é fugir dele. Se o provedor não tem uma analise estatística dos SLAs entregues atualizada, então ele não é o fornecedor adequado para empresas honestas e sérias. O SLA é base para a decisão de compra de um serviço de TI. O preço é consequência dele. Apesar de o preço incluir os investimentos para manter o SLA dentro dos limites de controle ao longo do tempo. O gestor de TI precisa ir além. O CIO precisa exigir ganhos de produtividade do fornecedor ao longo do tempo. Afinal a repetição dos processos leva a melhoria contínua e a redução do tempo gasto. Portanto, as empresas usuárias de TI precisam negociar os SLAs dentro da realidade, mas em condições de minimização dos custos no longo prazo.

O METADADO É UM AMEAÇA PARA A PRIVACIDADE?

INTRODUÇÃO

 

O mundo pós-Snowden fez o metadado sair do restrito universo da tecnologia e ganhar o foco dos holofotes da imprensa. Após varias décadas de ostracismo, muitos estão interessados nele. Até agora a maioria das pessoas desconhecia por completo o significado da palavra metadado. Foi preciso a citação pelo Presidente Obama do termo para que as luzes fossem acessas. A revelação que tanto a duração das chamadas, como os números de telefones estão sendo monitorados e rastreados para evitar atos terroristas intensificou a preocupação com a privacidade. As afirmações que os conteúdos das chamadas e nomes envolvidos não estão sendo analisados em praticamente nada contribuíram para tranquilizar as pessoas. Agora que foi entendido que o metadado do correio eletrônico e redes sociais também está sendo monitorado e rastreado, as pessoas estão alarmadas com a intensidade potencial da invasão de privacidade.

 

METADADO

 

O metadado revela as informações sobre o conteúdo trafegado. Em outras palavras são os dados sobre os dados. As informações estruturadas do metadado são um cabeçalho do conteúdo que descrevem, explicam, localizam e permitem a gestão dos dados para fácil recuperação, uso e gerenciamento das informações. O metadado descritivo é um recurso para descobrir e identificar o título, resumo, autor e palavras-chave. Ele define como os dados do conteúdo estão organizados. O metadado administrativo revela os detalhes dos dados. Por exemplo, quando e como foi criado, tipos dos arquivos e quem tem acesso. Em outras palavras, o metadado resume as informações sobre os dados para facilitar a sua identificação, localização e manipulação.

 

O metadado de um e-mail é formado pelo nome, endereço de e-mail e IP do remetente, nome e e-mail do destinatário, data, horário, fuso horário, identificador único do e-mail e e-mail relacionado, registro do login do cliente do correio com endereço IP, formato do cabeçalho do cliente do correio e assunto do e-mail. O metadado de uma ligação celular é formado pelo número do telefone do chamador, número de série dos telefones envolvidos na chamada, horário e duração da ligação, localização geográfica dos participantes e número do cartão de ligação.  O metadado do Facebook é formado pelo nome do usuário e informações do perfil como data de aniversário, local de nascimento, histórico profissional e interesses, identificador único e nome do usuário, dispositivo, assinaturas de serviços (matrículas) e localização do usuário, data, horário e fuso horário da atividade.

 

O metadado dos navegadores na internet é formado pelas atividades e páginas visitadas pelo usuário com data e horário, dados e detalhes do login do usuário como preenchimento automático, endereço IP do usuário, provedor de acesso, detalhes do hardware e sistema operacional, versão do navegador e cookies e cache dos sites visitados.

 

BIGDATA , METADADO E A PRIVACIDADE

 

O Bigdata do metadado armazenado consistentemente pode facilmente transformar os diversos pedaços de informações em um conteúdo significativo sobre a pessoa. Basta cruzar o metadado com as informações publicadas pelos usuários na internet de acesso público. A capacidade de mineração e exploração dos dados é um fator decisivo para a privacidade. Países com profissionais de TIC de primeira classe estão em clara vantagem neste tema, pois não é preciso invadir computadores ou quebrar as leis para invadir a privacidade. A combinação dos detalhes do metadado com o comportamento público nas redes sócias permite montar os pedaços de dados e projetar conclusões possíveis sobre a saúde de uma pessoa pelo volume de contato com laboratórios clínicos, médicos, operadoras de saúde, institutos especializados e etc. Não é necessário invadir as conversas para saber o assunto discutido. Os registros do metadado das chamadas podem revelar muito sobre o conteúdo das ligações. Por exemplo, é possível descobrir diversos detalhes sobre os negócios nacionais e internacionais de uma pessoa pelo número dos telefones chamados.

 

CONCLUSÕES CIRCUNSTANCIAIS

 

É preciso uma afirmação clara e precisa sobre o que está sendo feito com o metadado capturado. Como a tecnológica do Bigdata permite tirar conclusões circunstanciais sobre as ações, atividades e atitudes das pessoas, a questão da captura por atacado do metadado é um assunto muito maior do que a conceituação se ela é legal ou não. É preciso um claro e preciso entendimento sobre as conclusões são circunstanciais que em muitos casos podem não ser verdadeiras. O impacto do uso do metadado para concluir e decidir é muito alto e sério. A vida real das pessoas pode ser fortemente afetada por conclusões circunstanciais e frágeis. 

O FUTURO DA ORGANIZAÇÃO DO ITAAS

O FUTURO DA ORGANIZAÇÃO DO ITAAS

 

A necessidade de reduzir o custo unitário das transações digitais está levando a organização do iT as a Service (iTaaS) na direção de melhores serviços. O departamento de tecnologia está sendo fortemente pressionado para mudar a qualidade das suas entregas. Atualmente as demandas são bastante divergentes por conta das falhas tradicionais no suporte da inovação. A organização de Tecnologia de Informações e Comunicações (TIC) está reagindo ao novo mundo movimentado pela força da mobilidade. O estágio final deste processo vai resultar em um departamento de TIC bastante diferente do que é hoje em relação aos papéis e responsabilidades.

 

O surgimento e domínio da era do Chief Information Officer (CIO) que administra a tecnologia para assegurar que ela vai habilitar os valores da conquista da estrategia do negócio vai gerar um ciclo totalmente novo do desenvolvimento de aplicações onde a organização de tecnologia será vista como uma extensão da mudança contínua e crescente do negócio. O ápice do processo de reestruturação da organização de TIC vai acontecer provavelmente entre 2015 e 2016. No primeiro momento a organização da nova TIC vai exercer o papel de ser o motor do negócio. A gestão vai entregar serviços de valor agregado de TIC com preço e velocidade em situação competitiva de mercado global. É a era do fim do ciclo do “coxambro” e do mais ou menos. Competências mais elaboradas da engenharia farão parte da rotina diária. Certificados elementares perderão completamente o valor.

 

"O que aprendi é que a melhor forma de comunicação é dar instruções por escrito, combinadas com diagramas sempre que possível", diz Schaedler. "Muito se perde na comunicação verbal", diz ele.

Fonte: Sete pesadelos de terceirização e como evitá-los, http://cio.uol.com.br/gestao/2012/11/21/sete-pesadelos-de-terceirizacao-e-como-evita-los/, acessado em 30/11/2012.

 

A habilidade da comunicação escrita será enormemente valorizada. A tendência da afirmação “A habilidade de projetar soluções em nuvem é baseada em procedimentos arquitetônicos e métodos muito antigos. Caso você compreenda o que eles são e tenha experiência na utilização dessas abordagens, você não correrá o risco de reinventar a roda no mundo da computação em nuvem.” do artigo “O que faz o arquiteto de computação em nuvem?” (http://computerworld.uol.com.br/carreira/2012/11/20/o-que-faz-o-arquiteto-de-computacao-em-nuvem/, acessado em 30/11/2012) será consolidada e a experiência profissional ganhará enorme relevância. O preconceito ao cabelo branco só vai sobreviver nas empresas falidas. Tecnologias consagradas nas últimas três décadas do século XX vão ganhar novo uniforme. Quem tiver experiência e capacitação vai sair muito na frente.

 

A produtividade da monitoração da tecnologia e do desenvolvimento das aplicações de negócio vai levar o mercado brasilieiro na direção da perícia, otimização, terceirizacão classe mundial, gestão efetiva dos fornecedores e administração financeira ativa de TIC. As quatro afirmações do artigo “Sete pesadelos de terceirização e como evitá-los” confirmam que o caminho do plano de negócio e Controle, Transparência e Previsibilidade (CTP) das entregas entraram em vortex positivo crescente.

 

1.    “Quando o fornecedor de outsourcing começa a mudar pessoas em sua equipe, fazendo com que seus funcionários tenham que explicar detalhes do trabalho para os novos funcionários em vez de realizar os próprios trabalhos, é hora de se preocupar.”

2.    “O aplicativo foi adiado por mais três semanas, e ainda foi entregue cheio de problemas.”

3.    "Nossa oportunidade de publicidade se foi"

4.    "A janela para a ação de marketing foi fechada, já que outros projetos não podiam ser adiados, e tivemos que acabar desistindo do app.”

Fonte: Sete pesadelos de terceirização e como evitá-los, http://cio.uol.com.br/gestao/2012/11/21/sete-pesadelos-de-terceirizacao-e-como-evita-los/, acessado em 30/11/2012.

 

As entregas com base no ciclo contínuo de melhoria levarão a organização de TIC na direção da procura de novos caminhos para entregar as capacidades dos serviços com redução do custo unitário da transação. As variáveis das necessidades do negócio estão cada vez mais sensíveis ao custo total. O iTaaS não tem fronteiras geográficas neste novo mundo. Provedores locais vão competir com os globais. A organização de tecnologia das pequenas e médias empresas são agora unidades de lucro que oferecem serviços integrados ao negócio.

 

Cerca de 90% das iniciativas de TI não serão bem-sucedidas nos próximos três anos por causa do aumento da complexidade do ambiente de negócios.

Fonte: Líderes de TI não terão sucesso em 90% dos projetos das áreas de negócios, http://computerworld.uol.com.br/especiais/2012/10/29/cio-nao-tera-sucesso-em-90-das-entregas-os-negocios-em-3-anos/, acessado em 30/11/2012.

 

O processamento e entrega dos serviços de apoio ao negócio da empresa será completamente centralizado conforme o foco e valor da área de negócio. A perspectiva do marketing e entrega dos serviços será baseada na competitividade. A inovação (lembrando que inovação não é obrigatoriamente uma novidade) é uma ação prioritaria da organização da nova TIC. Ela é um fator chave de sucesso para que a tecnologia adicione valor real ao núcleo duro do negócio da firma. No mundo digital do Big data as informações são inseparáveis dos produtos e serviços ofertados e vendidos pela companhia. Esta aptidão está cada vez mais explícita no mundo dos negócios. A característica de inovação do novo jogo do poder social faz com que todas as pessoas e líderes do negócio façam parte da cadeia de valor da tecnologia. A liberdade individual para decidir como compartilhar as informações e colaborar com os projetos de negócio vai criar o foco de inteligência coletiva para o uso compartilhado das informações. Os serviços de valor agregado da tecnologia vêm incentivando a adoção deste novo modelo. É uma arquitetura corporativa que aumenta o princípio da pesquisa e desenvolvimento em tecnologia.