O desperdício do trânsito

O livro Governança da nova TI: a Revolução abordou na página 420 [CASO TELETRABALHO (2002)] uma solução para as perdas do trânsito. Infelizmente nada foi feito e passados doze anos um novo estudo contabilizou que as perdas nos trinta e nove municípios da região metropolitana de São Paulo estão se aproximando da casa dos R$ 70 bilhões ao ano (Firjan: congestionamentos no Rio e em São Paulo custaram R$ 98,4 bi em 2013, http://noticias.uol.com.br/cotidiano/ultimas-noticias/2014/07/28/congestionamentos-no-rio-e-em-sao-paulo-custam-r-984-bilhoes-diz-firjan.htm, acessado em 07/08/2014).

A região metropolitana perdeu 7,8% do seu PIB em 2013 devido aos congestionamentos médios de 300 km por dia. Enquanto os políticos discutem sem embasamento algum o plano diretor da cidade e a ampliação do rodízio,  o município vem perdendo cada vez mais dinheiro. Não é a toa que falta dinheiro para a educação,  saúde e segurança. O desperdício segundo a pesquisa da Federação das Indústrias do Rio de Janeiro (Firjan) é enorme e crescente.
Como o óbvio não vem sendo, é o momento de falar novamente do trivial do trivial.  Antes de pintar centenas de quilômetros de faixas caras inúteis para o transito (velocidade média do ônibus passou de 15 km/hora para 16 km/hora no pico da tarde, Faixas elevam velocidade de ônibus, mas prejudicam carros em SP, http://www1.folha.uol.com.br/cotidiano/2014/06/1464713-faixas-elevam-velocidade-de-onibus-mas-prejudicam-carros-em-sp.shtml, acessado em 07/08/2014) ou gastar milhões em estudos para a ampliação do rodízio de carros é preciso fazer o elementar.  Ou seja, acabar com os carros estacionados nas ruas, avenidas e etc.

Todos os vultosos investimentos realizados no sistema viário devem ser direcionados para que os carros, ônibus, motos e etc. andem. O lugar de carro estacionado é no estacionamento. A péssima escolha do prefeito Fernando Haddad de aumentar a zona azul na cidade (Gestão Haddad acelera criação de vagas de Zona Azul, http://www1.folha.uol.com.br/fsp/cotidiano/178334-gestao-haddad-acelera-criacao-de-vagas-de-zona-azul.shtml, acessado em 07/07/2014) só aumentou o desperdício e as perdas causadas pelo trânsito.

O segundo aspecto obvio é a questão do deslocamento casa-trabalho-casa na cidade de São Paulo. Durante décadas a gestão municipal vem incentivando o deslocamento das sedes das empresas do bem servido (em termos de transporte público) centro da cidade para os caros bairros da zona sul. Como é muito caro morar perto dos centros empresariais,  a distância percorrida pelos trabalhadores vem aumentando cada vez mais e os carros, ônibus, motos e etc. ficam mais tempo nas ruas fazendo com que os congestionamentos sejam cada vez maiores. A solução óbvia de deslocar para o centro da cidade os centros empresariais foi completamente ignorada no novo plano diretor.

O sistema viário da cidade foi planejado assumindo os principais centros empresariais localizados no centro do município, por isto o transporte público tem grande investimento realizado no centro da cidade. O desenho de todo o investimento viário na cidade é o de deslocamento do bairro para o centro e não entre bairros. Este é o principal motivo do gigantesco desperdício de dinheiro público do deslocamento empresarial para a cara zona sul. O centro pode e deve ser utilizado para moradias, pois isto permite que a região tenha vida após o horário comercial. No entanto, é preciso que a região assuma o seu papel de centro empresarial e governamental para que a cidade sofra menos perdas com o transito.

Uma vez que o centro tenha consolidado o seu papel empresarial é possível criar nos bairros mais pobres centros empresariais regionais de menor porte que funcionariam como centrais de teletrabalho. Desta forma o centro é resgatado como região do trabalho,  família e lazer.  As pessoas que vão ocupar as casas e apartamentos novos ou reformados vão poder trabalhar perto e também vão gerar um novo ciclo econômico para a vida noturna da região.

A cidade pode neste modelo explorar todo o potencial do investimento realizado no sistema viário e de transporte público.  É possível não inflacionar o centro e atender as necessidades das pessoas e empresas com a criação das centrais compartilhadas regionais de teletrabalho onde as pessoas podem realizar as suas atividades profissionais e pessoais com o menor deslocamento físico possível.  A digitalização dos negócios já permite o desenvolvimento de inúmeras atividades de presença virtual.

Estas centrais são melhores no primeiro momento do que o deslocamento físico das empresas para a periferia, porque elas permitem o compartilhamento dos recursos entre diversas empresas minimizando assim os riscos e capital necessário.  A dinâmica destas centrais vai gerar na regional um fluxo adicional de negócios por conta das necessidades de alimentação,  transporte,  segurança e educação.  O volume envolvido do fluxo justifica o investimento na periferia em serviços públicos como telefonia, banda larga, saneamento e energia.  A região vai se desenvolver e com isto vai gerar um ciclo de atenção para sub-regionais. A cidade de São Paulo pode com este modelo de recuperação do centro da cidade resgatar um ciclo desenvolvimentista que beneficie toda a população do município sem exclusões, violências e conflitos.

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.

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).