Profissionais TI - Pra quem respira informação

Meu projeto foi entregue em produção no prazo e orçamento estimado, a metodologia de trabalho foi aplicada e todos os aceites foram recolhidos. Ou seja: missão cumprida, certo? ERRADO!

Tenho uma novidade para você, meu colega de profissão gerente de projetos/PO/ScrumMaster. Existe vida pós entrega, e não importa quão bem você construa seu produto ou serviço, se ele não for devidamente sustentado e o valor não for percebido pelos usuários, sua entrega será prejudicada.

Nesse artigo mostro a vocês os pontos que penso serem cruciais e como podemos de forma simples olhar para cada um deles.

A satisfação de uma entrega é percebida a posteriori, conforme um produto ou serviço vai cumprindo seu papel de utilidade e garantia, os benefícios vão sendo alcançados e o valor sendo percebido. É por isso que uma das etapas mais importantes de um projeto é a TRANSIÇÃO.

A Transição visa estabelecer o diálogo entre quem está construindo algo e quem irá sustentar, além de mapear e documentar os pontos relevantes para o sucesso no pós entrega.

Cada metodologia trata esse conceito de uma forma diferente, mas acredito que o ponto chave da transição é encerrar um ciclo de entregas garantindo que as pessoas, tecnologias e processos estão preparadas para receber a sustentação.

Clique aqui para conferir a abordagem da ITIL sobre a Transição (e demais estágios)

Pessoal, enfatizo que uma entrega pode ser: um sistema completo; alguma nova funcionalidade para um sistema existente; a implantação de um novo serviço, como disponibilização de internet WIFI, reinicialização de senha pelo telefone, etc.

Um projeto deve ser orientado à entrega e sustentação, pois ele só atingirá o sucesso caso os benefícios sejam alcançados e o valor seja percebido no decorrer do tempo.

Já ouviu aquele ditado “Fazer filho é fácil, difícil é cuidar?” Então…

Não quero deixar a entender que conduzir um projeto e entregar um resultado é fácil. Nada disso. É bastante desafiador.

Mas na hora de sustentar, com o sistema em produção, o usuário pressionando e o cliente impaciente, com os resultados da empresa sendo diretamente afetados, com processos sendo atrasados, com pessoas tendo seu trabalho diário prejudicado… meu amigo, a história muda.

O meu ponto aqui é: quando for construir algo, faça-o pensando em quem/como/quando for sustentar.

Descrição do serviço/sistema

O primeiro item da nossa lista é simples, mas importante. A ideia aqui é montar alguns tópicos explicando sumariamente o que é o sistema ou o serviço em questão, qual seu propósito, seu público alvo e pessoas envolvidas. Minha dica é documentar essas informações na 1º página da base de conhecimento dedicada ao produto ou serviço em questão.

Responsável pelo sistema/serviço

Da mesma forma que pessoas e equipes são nomeadas para serem responsáveis por um projeto, o mesmo deve ocorrer para os responsáveis pela sustentação. Aqui o objetivo é simples: mapear quais pessoas e equipes deverão responder pela sustentação (suporte, atendimento, manutenção, alterações, etc) do produto/serviço que está sendo entregue. O ponto é comunicar devidamente essas pessoas e garantir que elas recebam todas as informações com antecedência. Sem surpresas.

E por mais que seja comum várias equipes estarem envolvidas na sustentação de algo, é importante existir um ponto focal, quem orquestrará as outras equipes em prol da sustentação e assumirá o compromisso. É o famoso ownership (propriedade, sentimento de dono).

Gestão de conhecimento: treinamentos, erros conhecidos, manuais de usuário, etc.

Grande parte do que se produz pode ser documentado no momento da construção e durante a operação assistida (etapa crucial para estabilização de alguma entrega).

Em tempo de sustentação, ter documentação fidedigna sobre a entrega é fator chave de sucesso. A documentação gerada durante a construção passa a ser de responsabilidade da sustentação, que a partir daí seguirá os processos vigentes e integrados de gestão de incidentes, requisições e conhecimento.

Além do conhecimento documentado, é comum haver treinamentos para os usuários que utilizarão o sistema ou serviço, mas o mesmo muitas vezes não acontece para quem irá sustentar o serviço. Além de muitas vezes não serem envolvidos na etapa de construção, também não são envolvidos em treinamentos. O ideal é que haja treinamento específico para a sustentação, envolvendo, sempre que houver sentido, todos os níveis da camada de suporte.

Mapa de suporte

A sustentação geralmente é prestada por mais de uma equipe: infra,banco de dados, atendimento remoto, presencial, análise, desenvolvimento, etc. Mesmo que exista um ponto focal quanto à sustentação, faz-se necessário definir a fronteira de cada um. Dessa forma, recomenda-se definir até onde irá o 1º nível de suporte no atendimento daquele serviço, onde o Nível 1 sai de campo para entrada do nível 2º e como e quem acionar para atendimentos especializados de Nível 3 (geralmente relacionado a infra, banco e desenvolvimento).

Mapa de integrações

É muito comum sistemas e serviços possuírem integrações entre si. É de suma relevância documentar quais integrações existem e como elas acontecem. Exemplo: sistema de pagamento possui integração via arquivo XML com sistema de compras; Reinicialização de senhas por telefone possui integração via API com o sistema de administração de domínio (AD).

Catálogo de serviços

Caso a instituição possua catálogo de serviços (se ainda não possui, corre!), recomenda-se evoluir esses catálogo com os novos serviços originados a partir da entrega. Além dos diversos benefícios que o catálogo de serviços fornece (entenda o que é catálogo aqui), metrificar a quantidade de demandas originadas a partir da entrega de um novo serviço ou produto possibilita o entendimento de seus impactos, problemas e oportunidades de melhoria, consequentemente auxiliando a calibração e estabilização do mesmo.

Gestão de mudanças

Eventualmente será necessário realizar mudanças, como atualizações de versão, migração de tecnologia, deploy de funcionalidades, dentre outras. A própria entrega em produção já é, por si só, uma mudança. Para definir minimamente esse processo, responda ao menos as perguntas abaixo:

• Quais são os tipos de mudança existentes para esse serviço ou sistema?
• Quem pode solicitar a mudança?
• Com quanto tempo de antecedência deve-se solicitar a mudança?
• Precisa da aprovação de alguém? Se sim, quem?
• Existe janela para essa mudança ou pode-se executar a qualquer hora do dia?
• Quem é responsável por executar a mudança?
• A mudança será automatizada? Se sim, por meio de qual fluxo?
• Há backup e/ou versionamento para o que está sendo mudado?
• Caso dê errado, como será o rollback?

A materialização do processo de mudanças pode ocorrer dentro do próprio catálogo de serviços, onde é possível configurar e documentar os pontos supracitados.

Gestão de eventos

Praticamente todo sistema ou serviço deveria ser, de alguma forma, monitorado. Um servidor deve ser monitorado quanto a seu processador, memória, disco e rede. Um link de internet deve ser monitorado quanto a sua disponibilidade, um sistema deve ser monitorado quanto a seu desempenho e operabilidade e assim por diante. Além de manter a TI informada, a gestão de eventos é crucial para prevenir e evitar desastres, pois através dela podemos criar gatilhos que nos alertam quando algo tende a virar um problema. Um exemplo seria um gatilho que alertasse quando o espaço em disco de um servidor estiver chegando próximo ao limite, possibilitando que alguém tome alguma ação antes que o incidente ocorra. Há diversas ferramentas gratuitas e de código aberto que apoiam nesse sentido, como Zabbix, Nagios e Centreon.

Política de backup

Será necessário armazenar, no longo prazo, algum dado? Durante quanto tempo? Quais dados ou arquivos deverão entrar na rotina de backup?

Essas são perguntas importantes a se fazer antes de implantar um sistema em produção, afinal de contas, no mundo de TI tudo pode acontecer, e ter contingência de dados relevantes não só é importante, como é fator de sobrevivência.

Contudo, fazer backup de tudo e para sempre também está errado, pois se transforma em um desperdício(storage, fitas de backup, etc). Defina exatamente o que, onde e por quanto tempo dados deverão ser armazenados contingencialmente.

Gestão de acessos

Um assunto geralmente problemático é a gestão de acessos. Corriqueiramente há mudanças nas equipes, demissões, contratações e demais fatores que impactam nesse ponto. Por isso é importante definir qual a estrutura de perfil e permissões a ser utilizada, quem pode solicitar qual tipo de acesso, quem aprova a liberação do acesso e qual equipe irá, de fato, atender aos chamados relacionados.

Gestão do fornecedor

Muitos sistemas ou serviços são implantados com o apoio de fornecedores terceiros, mas não é raro encontrarmos equipes que não possuem acesso ao contrato e muitas vezes ficam limitadas na intermediação junto ao fornecedor. Por isso deve-se repassar o contrato às equipes responsáveis pela sustentação, os SLAs acordados e as ferramentas e métodos de acionamento do fornecedor. Essas informações também são muito bem vindas na base de conhecimento da entrega.

Resumindo/Concluindo

Ao finalizar alguma entrega, garanta que os itens abaixo foram alvos de mapeamentos, definições e principalmente de diálogos:

• Descrição do sistema/serviço
• Responsável pelo sistema/serviço
• Gestão de conhecimento
• Mapa de suporte
• Mapa de integrações
• Catálogo de serviços
• Gestão de eventos
• Política de backup
• Gestão de mudanças
• Gestão de acessos
• Gestão do fornecedor

Tudo bem, mas o que eu faço com todas essas informações?

Na prática, um checklist com esses pontos já é um começo, além de ser essencial compartilhar as informações levantadas com todos os envolvidos. Quanto ao armazenamento, o ideal é ter uma área em sua base de conhecimento que agrupe as informações de todos os sistemas e serviços implantados. Um ponto único de conhecimento para entender o que é sustentado pela organização. E sem desculpas: caso não possua base de conhecimento, um diretório na rede contendo as informações agrupadas por pastas já é um começo.

Galera, cada organização possui sua realidade, dessa forma, os pontos aqui levantados podem (e devem) ser adaptados de acordo com a necessidade.

Independente da documentação e das definições, não deixem de promover o diálogo e o alinhamento constante. Documentação é importante, mas quem garante o sucesso é a COMUNICAÇÃO entre as pessoas, e a boa comunicação é aquela amplamente transmitida e totalmente entendida por quem a recebe. Tenha certeza que as pessoas envolvidas estão conversando o mesmo idioma e trabalhando em prol do mesmo objetivo. Ninguém pode ser pego de surpresa.

Ah! Mais uma coisa: e-mail não é um método de comunicação eficiente, mas sim um método de formalização! Converse para se comunicar, envie e-mail para formalizar  -  se necessário.

Documentação é importante, mas quem garante o sucesso é a comunicação.

Caso tenham interesse, me acionem que posso encaminhar exemplos práticos dos pontos citados nesse artigo, inclusive com alguns modelos de documentação e checklist.

Por hoje é só. Fiquem ligados nos próximos artigos.

Um abraço e até a próxima.

PS: que tal entender a ITIL de vez por todas? Segue meu ebook com exemplos práticos que finalmente farão você entender qual o papel de cada estágio e como utilizar as melhores práticas no dia a dia. Dá uma conferida ITIL Simplificado: como entender e utilizar o framework.