Planos de implantação de serviços de aplicações influenciadas pela estrutura da equipe
Os desenvolvedores realmente são diferentes. Desde suas funções e responsabilidades até sua colocação na estrutura organizacional, os desenvolvedores geralmente são o "grupo estranho". Você nem pode necessariamente incluí-los no termo "TI" porque as equipes de desenvolvimento oscilam entre fazer parte da TI e fazer parte do negócio.
Mesmo enquanto o DevOps como uma mudança cultural começa a criar raízes, a maioria das organizações continua organizada funcionalmente no que não é tão carinhosamente chamado de silos de TI. Em nossa pesquisa State of Application Services 2019 , descobrimos que quase metade de todos os entrevistados (46%) ainda estavam organizados em "equipes de função única", como "Rede", "Servidor", "Armazenamento" e "Segurança". Mais de um terço (37%) estava trabalhando em equipes de operações combinadas mais adequadas para adotar e aplicar princípios e abordagens DevOps para entrega e implantação de aplicativos. Apenas 15% trabalhavam em equipes pequenas e multifuncionais baseadas em unidades de negócios ou produtos da empresa.
A estrutura é importante porque, em parte, define seu propósito e suas prioridades. Isso, por sua vez, determina as métricas pelas quais o sucesso é medido. Organizações isoladas significam métricas isoladas. Podemos ver isso em nossa pesquisa sobre NetOps e DevOps do verão passado. Observamos diferenças significativas na forma como as equipes eram medidas com base na estrutura. Por exemplo, as métricas mais comuns em todos os tipos de equipe e funções foram:
- Tempo de atividade da rede (60%)
- Tempo de atividade do aplicativo (56%)
- Otimização de processos (40%)
- Tempo médio de resolução (39%)
Mas quando analisamos isso e analisamos as métricas com base nos tipos de equipe, vemos que quanto mais colaborativas — também conhecidas como Semelhante ao DevOps - uma estrutura de equipe é, as prioridades mudam.
|
Função única |
Operações combinadas |
Função cruzada |
Tempo de atividade da rede |
67% |
54% |
50% |
Tempo de atividade do aplicativo |
53% |
58% |
61% |
Otimização de Processos |
34% |
45% |
45% |
Tempo médio de resolução (MTTR) |
43% |
30% |
44% |
Agora, como as métricas pelas quais você é medido se relacionam com os serviços de aplicativos? Bastante, na verdade.
Se seu foco principal é o tempo de atividade da rede, você trabalhará para isso e implantará serviços que atendam a esse objetivo. O mesmo vale para o tempo de atividade do aplicativo. Se essa for sua prioridade, você levará os serviços de disponibilidade muito mais a sério do que as pessoas que estão sendo medidas pela frequência de implantação.
Podemos ver o impacto de uma base de entrevistados composta em grande parte por "equipes de função única" nos planos de implantação de serviços de aplicativos em nossa pesquisa. Isso fica mais evidente quando categorizamos os serviços de aplicativos pelo que eles fornecem para os aplicativos: segurança, desempenho, identidade/acesso, disponibilidade e mobilidade.
Esses resultados refletem o impacto das métricas de equipes de funções únicas. Os desenvolvedores estão preocupados principalmente com a disponibilidade - que geralmente inclui metas de desempenho específicas - e planejam implantar os serviços de aplicativos que oferecem suporte à disponibilidade e ao desempenho. Da mesma forma, o NetOps se concentra nos serviços de aplicativos que oferecem suporte ao tempo de atividade da rede por meio da otimização, dimensionamento e proteção dos protocolos de rede dos quais os aplicativos dependem.
A estrutura da equipe é importante. Não apenas pela necessidade de incentivar uma cultura mais colaborativa, mas pela maneira como isso impacta as decisões — incluindo as escolhas tecnológicas. Objetivos diversos geram atrito e frustração. É uma das razões pelas quais vemos serviços de aplicativos como balanceamento de carga, tradicionalmente implantados e operados pelo NetOps, sendo apropriando-se do DevOps e implantados como parte do aplicativo. Porque em organizações com estruturas de equipes de função única, o tempo de atividade do aplicativo é uma prioridade para os desenvolvedores, mas não para o NetOps.
Para realmente capitalizar o DevOps, as estruturas de equipe — e as métricas pelas quais elas são medidas — devem mudar para modelos mais colaborativos e se afastar das equipes tradicionais de função única.
Porque os silos pertencem às fazendas, não à TI.