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.