Modelo de gerenciamento de TI em uma empresa de produtos

Se você se tornou líder em TI, tem grandes problemas - é bastante difícil encontrar os modelos descritos de organização de produção e os KPIs definidos para CTO e CIO. A tarefa de qualquer gerente de qualquer setor é monitorar os concorrentes, “estado da arte” - exemplos e trazer as melhores práticas para sua empresa. Por experiência própria, direi que você precisará fazer um círculo de amigos e compartilhar exemplos com outras estações de serviço em bares, reuniões, visitas de referência e conferências.

imagem

No Habré, não consegui encontrar conteúdo sobre modelos e métricas de gerenciamento, mas como realmente não é suficiente, decidi compartilhar minha experiência.

Vamos começar respondendo à pergunta por que nossa empresa é responsável pelas estações de serviço:

  1. Equipe. A estação de serviço é responsável por selecionar e manter uma forte equipe de engenheiros, bem como por seu envolvimento.
  2. .IT- , , .
  3. . , IT- , .
  4. . IT- IT – , , , .
  5. . . , CISO ( – ). IT- .

Agora vamos ver as métricas que ajudarão você a ver a imagem de sua responsabilidade. Em algum lugar, as métricas são derivadas, porque medir diretamente não vai funcionar.

1. Equipe


Métricas


  • integridade das funções de TI. Pelo que? A resposta é que, devido à baixa equipe, segue-se a impossibilidade de cumprir as tarefas planejadas. A prioridade da contratação é definida estritamente de acordo com o indicador de pessoal. Quanto menor o nível de pessoal, maior a prioridade de sua vaga para RH. Tudo é simples.
  • "Fluidez" no contexto de funções. Pelo que? Uma alta / crescente rotatividade de pessoal significa que você tem um clima de equipe ruim, problemas com processos ou salários. Problemas de cluster ajudarão a sair - entrevistas com funcionários.
  • Porcentagem de funcionários que chegam às recomendações dos funcionários atuais (indicador de referência). Uma porcentagem crescente sugere que seus engenheiros gostam de trabalhar para você; eles estão prontos para recomendar sua empresa a pessoas próximas e apenas a conhecidos.

2. Arquitetura


Ainda há um campo para experimentação. Mas ainda:

Minhas métricas


  • Desvios arquitetônicos. O que é isso? Desvio arquitetural - você encontrou na produção uma implementação que não atende ao padrão arquitetural aprovado. Pelo que? O cenário de TI é um enorme sistema interconectado que deve funcionar de acordo com as regras. Se você não seguir as regras, o sistema simplesmente não seguirá.
  • PageSpeed Insights -. - . ? . – , , Google -.

3.



  • - .
  • TOP . ? , .
  • TOP .? , . «» , .
  • Crash-free .

4.



  • IT – — , , . ? , Gartner, IT . . , , , , . , , overpriced .
  • TOP . ? . , , , .
  • -% .

5.



  • /. ? , , .
  • SLA .? , , IT — , ...

O leitor pode perguntar: "Mas e quanto a métricas importantes, como o tempo de mercado, o número de implantações automáticas e o número de manuais, algo sobre a densidade de solicitações pull?" A resposta é sim, eles uma vez olharam para eles, agora não são relevantes para nós. Isso é normal para métricas, cada uma com seu próprio ciclo de vida.

Agora, vamos aos recursos de TI no DomClick. Não citarei clássicos com seus “desenvolvimento, implementação, manutenção, operação” - descreverei funções em um nível diferente de abstração:

  1. Desenvolvimento de Produto. Equipes que criam produtos através da venda dos quais a empresa recebe a principal receita. Existem equipes mistas de negócios e TI. Existem ROs e CJEs que respondem à pergunta “o que fazer” e “que prioridade”, os engenheiros respondem à pergunta “como fazer”.
  2. (ore). , «» . , , , API Gateway, , ..
  3. . , – , , .
  4. - (Web Core) , web- , UI-, .
  5. . - : , . «» , , , . — .
  6. . , , , , , k8s, .
  7. DevOps. . .
  8. . , IT . , , .
  9. R&D. , . - VR/AR, , -.
  10. . , IT- . , (, , ) . , , , - IT .
  11. IT . ( ). IT — . .
  12. Data Science. IT DS RecSys ML. OCR NLP – , , - . , OCR. DomClick.
  13. . , . , , .
  14. . , , , scrum

O layout das funções no DomClick é parecido com o seguinte:

imagem

No lazer, recomendo a leitura de um artigo do nosso chefe de desenvolvimento de serviços internos e principais, bem como de um engenheiro da divisão de Desenvolvimento e Manutenção de Infraestrutura . Ficará um pouco claro o que os caras estão fazendo.

Uma função não é necessariamente uma grande equipe de pessoas. Algumas funções podem consistir em uma pessoa, mas devem ser, alguém deve resolver esse problema. Talvez a princípio você seja você.

O layout dessas funções fica a seu critério, pois depende da competência de seus funcionários. Vou dar apenas duas dicas da prática pessoal:

  1. . , . , - k8s , - , - .
  2. , . – ore , . , .

Temos características distintivas interessantes que simplificam bastante o trabalho e os conflitos de nível sobre a questão das prioridades. Lembre-se de que a TI, além de criar e vender produtos, também é necessário mudar para novas versões de produtos relacionados à API, realizar refatoração, eliminar vulnerabilidades e analisar problemas de raiz:

  1. Cada equipe dedica 20% de seu tempo à cota de engenharia. Nesta cota, tentamos resolver todos os problemas acima e pesquisamos se houver tempo. Importante: os bugs e bloqueadores de segurança cibernética NÃO estão incluídos em 20%, são eliminados devido à cota de alimentos.
  2. Grandes áreas de desenvolvimento de produtos (várias equipes ágeis trabalham em um produto) têm sua própria equipe de plataforma pequena, o que geralmente garante que o "caftan não saia" e resolve apenas os problemas de engenharia desse produto.

Finalmente


  1. – , .
  2. , .
  3. . , IT 2020 , - (Web Core), R&D, — 2019.

All Articles