Gerenciamento de Serviços

MODELO DE GOVERNANÇA ÁGIL E ENXUTA

Conheça uma abordagem de alto desempenho para a contratação, execução, gestão e governança de times de produtos de software.

5. Gerenciamento de Serviços

Boas práticas na gestão de serviços

Esta seção trata da metodologia, dos fluxos e das definições a respeito dos serviços e seu gerenciamento, conforme parâmetros de governança amplamente difundidos no mercado e especificamente para atividades de software e afins.

O conteúdo que será apresentado a seguir envolve a metodologia e os artefatos sugeridos, a serem utilizados como norteadores do padrão mínimo da operação. Portanto, avalie eventuais customizações, de acordo com o seu cenário específico.

5.1. Metodologia (sugerida)

O padrão mínimo sugerido em termos de metodologia de software, tais como o fluxo e artefatos vinculados será apresentado neste tópico.

Como citado anteriormente, adaptações poderão ser realizadas no que está sendo exposto aqui, isso, obviamente, desde que você saiba o que está fazendo e avalie os possíveis impactos nas atividades específicas do GlassBox.

5.1.1. UPSTREAM

É fato que a tomada de decisão não costuma e nem deveria ser rápida, porém o fluxo de desenvolvimento é dinâmico. Então, como resolvemos este problema?

Para tratá-lo, a prática de mercado derivada do método Kanban orienta que separe-se a porção que remete à decisão de negócio – o “UpStream” – da porção que remete ao fluxo de entrega – o que é chamado “DownStream“. Isso permite que cada sistema seja tratado ao seu tempo, mas de uma forma que não gera gargalos na operação.

Vejamos então um pouco mais sobre o UpStream:

UpStream é executado de forma com que a curva da incerteza diminua ao longo das suas etapas de refinamento, comportando-se de forma similar a um funil de projetos, porém mais visual e enxuto… no início temos necessidades e ideias coletadas e ao final da execução definem-se os itens priorizados já no nível de um item de trabalho para o time de desenvolvimento, ou seja, já com maior nível de certeza do que precisa ser feito e com maior percepção do valor de negócio que a feature pode agregar. Logo, as features, nesta etapa, já estão prontas para comprometimento junto ao time de desenvolvimento.

Lembrete: estamos olhando para a perspectiva do Kanban, e sendo assim, o modelo não é prescritivo… o importante é que você consiga ter uma visão da necessidade até o ponto de comprometimento, sem que simplesmente sejam ‘tirados pedidos’, mas avaliando-se a real necessidade do trabalho que deverá ser feito pelos desenvolvedores (isso garante valor de negócio e vida longa ao produto).

5.1.2. DOWNSTREAM

Tomadas as decisões necessárias em termos de priorização, deve-se “puxar” um ou mais itens do “Backlog Priorizado” para o “Backlog Selecionado”, ou seja, do backlog de opções, as features prontas para comprometimento em UpStream devem ser movimentadas para a situação “A Fazer”, em DownStream. Isso define e representa o efetivo comprometimento do time para com a construção das funcionalidades priorizadas, conforme os requisitos de negócio que foram levantados.

PO e a equipe de desenvolvimento deverão detalhar o item até um nível considerado suficiente para o estabelecimento de uma comunicação eficaz entre todas as partes envolvidas, sendo que, buscando o uso de práticas de desenvolvimento modernas e enxutas, que focam no que realmente é necessário neste quesito, o mercado tem utilizado o BDD – Behaviour Driven Development como uma ferramenta que cumpre bem esse propósito.

Veja abaixo uma representação gráfica de como funciona o padrão mínimo do DownStream:

5.1.3. Fluxo Completo

O fluxo envolvendo UpStream e DownStream poderá envolver customizações (como o Kanban, usado como modelo sugerido, não é prescritivo), tal como expresso no quadro abaixo:

Embora não obrigatório, visando facilitar a visualização e execução dos diferentes sub fluxos, principalmente ao usar a abordagem do Kanban (nada impede que seja utilizado Scrum ou outro método ágil), orienta-se que sejam criadas algumas classes de serviço básicas.

Abaixo, um exemplo de como essas classes poderiam ser representadas:

Você pode visualizar também na figura abaixo, um outro quadro de exemplo referente ao padrão de desenvolvimento na forma de um fluxo completo:

5.1.4. Artefatos

Complementando a visão do fluxo mínimo para o desenvolvimento, visando atender todas as necessidades dos envolvidos no processo de desenvolvimento, idealmente, os artefatos a serem elaborados devem ser os seguintes (ou compatíveis):

Desde que você consiga substituir os fluxos e artefatos apresentados nesta seção, não há qualquer problema em customizar a abordagem que apresentamos aqui, independente da metodologia ágil ou enxuta que você prefira. Entretanto, atente para não se desviar dos objetivos de termos um padrão mínimo na operação:

  1. Garantir a qualidade, eficiência e comunicação ao executar o processo (ou seja: ter um processo – processos não são maus, eles apenas querem garantir que as pessoas tenham um norte a seguir, ok?)
  2. Garantir a rastreabilidade do que foi feito (no presente isso não parece importante, mas no futuro, um dia acabará por ser,  principalmente se você tiver um contrato envolvido (por mais que exista parceria entre as partes… e que o digam aqueles que movem processos judiciais, sejam eles pessoas físicas ou jurídicas)
  3. Possibilitar o trabalho com métricas, garantindo auto-conhecimento e previsibilidade (métricas só são úteis em cenários padronizados; sem padrões, métricas não dizem nada – não acredite em algo diferente disso, pois simplesmente, não é racional)

5.1.5. Por +MVPs

Alternativamente à construção de um backlog do produto por meios menos metodológicos, ao utilizar um modelo de evolução por MVPs, com apoio da estratégia de Lean Inception, que faz com que o foco na concepção seja o pensamento criativo e estratégico, considere os seguintes itens como potencialmente classificáveis no seu modelo de trabalho:

Esta forma de organização faz com que fique evidente o que corresponde ao serviço ‘Desenvolvimento e Evolução de Produtos’ e o que é associado à ‘Sustentação de Produtos’, por vezes, linhas de serviço diferentes no Catálogo de Serviços e classes de serviço distintas num modelo Kanban, já que os referidos fluxos de trabalho são também ligeiramente diferentes na prática da operação.

5.2. Definição de Serviços

Veremos agora como podemos definir os serviços compatíveis com um modelo de desenvolvimento ágil e enxuto.

Primeiro, veremos as linhas de serviço de negócio, e na sequência, os potenciais catálogos de serviço aos quais estão associados, que por sua vez, contêm os serviços técnicos (“atividades-padrão”).

Parâmetros de desempenho serão analisados posteriormente, nos capítulos que tratam os aspectos de “Governança Ágil e Enxuta” e “Contratos e Acordos“.

5.2.1. Serviços

Os serviços de negócio serão definidos como ‘aqueles que são identicáveis além do âmbito técnico’ como independentes e diferentes em razão da sua execução ou natureza específica.

São exemplos de serviços de negócio:

  1. Licenciamento de Produtos de Software – licenciamento perpétuo ou para um determinado período.
  2. Subscrição de Serviço (SaaS) – assinatura periódica (por exemplo: mensal, trimestral, anual).
  3. Desenvolvimento e Evolução de Produtos – execução de serviços de desenvolvimento de software, seja para novos sistemas ou evoluções/ adequações em sistemas existentes.
  4. Suporte e Sustentação de Produtos – suporte e sustentação contínua a um ou mais produtos de software, esteja(m) ou não sob garantia.
  5. Mapeamento, Modelagem e Mapeamento de Processos – conjunto de atividades utilizadas para entregar automatização de processos em sistemas BPMS, por exemplo.
  6. Transferência de Conhecimento – atividades de treinamento, operação assistida, capacitação ou consultoria cuja natureza e condições de prestação dos serviços podem ser quantificadas previamente à formalização do acordo entre as partes.
  7. Consultoria e Outros – atividades que não possibilitam qualquer tipo de análise prévia ou que não seja viável o estabelecimento de parâmetros objetivos para efeito de estimativa e medição da sua execução.

5.2.2. Catálogos

Alguns serviços de negócio por não representarem o menor parcelamento possível, ou seja: o menor grão, e ainda, serem independentes e grandes o suficiente para serem solitados e controlados diretamente pelo requisitante, devem ser contratados e/ou acompanhados através de solicitações de serviço individuais.

Para a finalidade em questão, catálogos de serviço devem ser criados, incluindo os respectivos ‘serviços técnicos’, os quais são organizados em classes (categorias). Estes catálogos, frisa-se, devem ser definidos e remunerados através da métrica UST.

O catálogo de serviços pode ser organizado na perspectiva de atividade e entregável (solicitações com o viés mais técnico, que pressupõe ‘o que deve ser feito’ como atribuição do requerente) ou do produto gerado (solicitações onde o foco é o resultado esperado pelo requerente, o que é evidenciado através de um conjunto de atividades e entregáveis associados).

5.3. Gestão de Serviços

Independente da existência de contratos (externos; outsourcing) ou simplesmente acordos operacionais (internos; insourcing) na prestação dos serviços, é considerada uma boa prática de Governança de TI, a adoção de certas formalizações para início e encerramento de solicitações de serviço, assim como o é, o acompanhamento das expectativas e o monitoramento da operação. Isso garante que ritos importantes sejam seguidos e reportados adequadamente, e ainda, potencializa o alinhamento entre as partes interessadas, a partir do cumprimento das cadências.

5.3.1. Fluxos

O fluxo de gestão dos serviços inicia com a contratação ou acordo realizado entre duas ou mais partes (entre fornecedor e cliente ou entre áreas de uma mesma organização), onde todas as condições de fornecimento serão alinhados (serviços, metodologia, condições, etc.).

Após a formalização do contrato ou acordo, solicitações de serviço (ordens de serviço) são emitidas contendo cada uma um escopo específico de serviços e resultados esperados.

As solicitações de serviço são gerenciadas e encerradas, e depois formalmente recebidas e validadas, com o intuito de fornecer transparência e rastreabilidade ao processo mínimo requerido para a manutenção de um nível de governança meramente suficiente.

Ao final de cada período, todas as solicitações encerradas são agrupadas e uma relação correspondente aos serviços prestados é enviada ao requerente, junto aos comprovantes de recebimento e validação obtidos.

O requerente valida os artefatos recebidos e os serviços prestados, avalia o nível de serviço correspondente e emite seu aceite à entrega, autorizando a emissão da Nota Fiscal ou meramente publica os resultados do período (no caso de insourcing).

5.3.2. Instrumentos

Os seguintes instrumentos devem ser utilizados como burocracia mínima necessária para a execução dos serviços sob um modelo de governança:

  1. Contrato ou Acordo Operacional: serve para ficar acordo entre as partes relacionando os serviços, as condições e o compromisso assumido (envolve eventos tais como: ‘Elaboração’, ‘Formalização’, Aditivo’, ‘Renovação’, ‘Cancelamento’ e ‘Encerramento’).
  2. Ordem de Serviço (OS): definida com o propósito de controle das solicitações e rastreabilidade do que foi solicitado e entregue (envolve os eventos de Abertura, Aditivo e Encerramento).
  3. Termo de Recebimento Provisório (TRP): pode ser físico ou eletrônico, e para uma ou para mais OS desde que dentro do mesmo período de apuração… representa que o serviço solicitado foi recebido pelo requerente mas ainda não foi avaliada a sua aderência com o que se esperava receber.
  4. Termo de Recebimento Definitivo (TRD): é emitido pelo requerente para dar ‘aceite’ a uma ou mais OS solicitadas e executadas.
  5. Demonstrativo de Serviços Prestados (DSP): o executor do serviço, no início de cada período, elabora a relação de solicitações finalizadas no período anterior, e envia para análise e validação dos serviços prestados.
  6. Contagem de Pontos de Função (CPF): no caso de envolver serviços de desenvolvimento e manutenção de software, uma contagem de pontos de função contendo o escopo executado no período anterior, também faz-se necessária (a contagem deve ser realizada/ ‘assinada’ por profissional certificado como especialista em métricas, sendo este o responsável pela correta aplicação da técnica).
  7. Relatório de Prestação de Serviços (RPS): não existindo considerações em relação aos instrumentos anteriormente recebidos, deverá ser emitido pelo requerente um relatório completo dos serviços prestados pelo executor, constando inclusive, informação detalhada do nível de serviço atingido.
  8. Termo de Aceite (TA): ao ser enviado o RPS ao executor, deverá constar também o termo de aceite aos serviços prestados, o que autoriza a efetiva emissão da Nota Fiscal (NF) se houver contratação envolvida (outsourcing).