Excursão ao passado
Trabalho para a ICL Services há mais de 4 anos e comecei como especialista em suporte técnico em um grande projeto. Agora eu lidero o grupo de ITSM na direção de Service Desk - minhas competências estão concentradas na implantação e configuração de sistemas de ITSM, gerenciamento de processos de TI (Incident, Change, Problem Management). Na verdade, sem exagero, posso dizer: as pessoas mais hábeis na área de SD trabalham no meu grupo.
A peculiaridade de uma grande empresa, que descobri após trabalhar nela cerca de seis meses a partir do momento da contratação, é a seguinte: as pessoas raramente compartilham suas melhores práticas. Não porque fossem gananciosos, mas simplesmente porque eram profundamente preguiçosos para explicar aos colegas qual era o benefício. Afinal, como costuma acontecer, na maioria das vezes, todos aqui eram técnicos com relacionamentos de longa data.
E então eu chego - e vejo que um tem scripts lindos que permitem que parte do trabalho seja feito automaticamente, o outro mantém uma programação de seus turnos em um aplicativo em nuvem e nunca confunde os turnos (e naqueles tempos densos ainda usamos Excel), o terceiro escreveu um simples um aplicativo web que exibe todos os campos do aplicativo em uma tela para não perder tempo trocando as abas do sistema ITSM e abrindo-as ao verificar os aplicativos.
Mas esses desenvolvimentos permaneceram individuais e não foram compartilhados com toda a equipe do projeto, para não mencionar quaisquer implementações em projetos semelhantes. Como disse meu líder, sempre reinventamos nossa bicicleta por conta própria - e eu estava certo nesse caso. Claro, havia também um fator humano: por exemplo, havia alguém mais experiente, e ele não podia usar as melhores práticas dos "jovens". E um clássico especial - "mas com ele temos um conflito pessoal, não vou usar as ferramentas que ele usa . "
Foi um sucesso para mim e, em geral, para todo o nosso departamento, novas abordagens aos processos foram introduzidas e testadas. Toneladas de documentação, uivos de usuários e grupos de suporte - tudo está como de costume. Consegui levar a cabo as melhorias que vi, mas o mais importante, consegui envolver quase todos os rapazes no trabalho conjunto no serviço. Afinal, você sabe do que é capaz uma equipe que se uniu contra um problema? O problema não tem chance. O cliente introduziu um novo indicador - a porcentagem de erros ao preencher os aplicativos. No início era cerca de 10% por equipe, ou seja, cerca de 200 aplicativos apresentavam erros menores e significativos.
Os líderes de linha e projeto disseram: “é impossível reduzir ainda mais a porcentagem de erros - as pessoas são pessoas e sempre estarão erradas ”. Nós replicamos um aplicativo da web escrito por nosso especialista líder, definimos pontos de controle e coletamos informações regularmente sobre esses indicadores, resolvemos casos específicos: quando o próprio sistema ITSM substitui os campos necessários do Active Directory, o que procurar. O resultado não demorou a chegar - em seis meses, trouxemos a% de erros por mês para o nível criticamente baixo de 0-0,6% por equipe.
E nesse ponto da minha carreira, percebi duas coisas:
- Quero trabalhar em uma equipe bacana , e todo o resultado do trabalho é muito melhor do que até mesmo o funcionário mais engenhoso pode fazer. Essa decisão definitivamente me levará à gerência mais tarde.
- Quero combinar as conquistas de caras talentosos e legais em um único sistema que seja melhor, mais confiável e mais rápido do que o que você tinha antes.
Início do projeto
Em 2019, fui convidado para liderar o projeto Digital SD, dentro do qual tínhamos que tornar nossos serviços mais competitivos com a ajuda de tecnologias modernas: Aprendizado de Máquina, vários bots de voz e texto, plataformas omnicanal, autoclassificações e aplicativos de resolução automática. Ou seja, todas aquelas coisas que elevam a experiência do cliente a um novo patamar sem aumentar os custos de mão de obra de prestação de um serviço.
Honestamente, depois de olhar para todo o hype em torno da IA, no começo eu estava muito cético sobre a tarefa. E parece que a direção está correta e o objetivo é bom, mas algo estava errado aqui.
E o problema era que ninguém sabia exatamente o que precisava ser desenvolvido. Existem muitas direções, em que se agarrar? Normalmente em tais momentos, em artigos ou livros, eles escrevem com segurança: “já sabíamos como e para onde nos mover”. Então, isso não é sobre nós. Fiquei com o product owner e fiz uma lista de perguntas que precisávamos responder ao projetar o produto:
- Que funcionalidade útil oferecemos ao usuário e ao cliente?
- Como isso se integra ao serviço atual?
- Como você deve alterar seus fluxos de trabalho atuais para que isso funcione e seja benéfico?
- Como e em quais tecnologias isso deve ser feito?
- Como deve ser construído um modelo de solução econômica?
Mas fizemos isso muito bem: reunimos um grupo de especialistas de SD entre gerentes de projeto, gerentes de linha, especialistas técnicos, escrevemos histórias de usuários, fizemos um mapa de valor - aqui está uma pequena parte disso:
em paralelo, junto com os desenvolvedores, descrevemos a arquitetura de nível superior, obtendo assim um ponto de partida no projeto ...
SCRUM trabalho
Portanto, nossas apresentações: Product Owner, PM, Scrum Master e Development Team. Um sprint de trabalho com duração de 2 semanas. A tarefa é organizar o processo de lançamento do produto de tal forma que ...
Mas falando sério, era necessário levar em consideração os requisitos de todas as partes interessadas, lidar com as dores e entender o que realmente precisa ser feito, o que pode ser feito depois e o que não deve ser feito.
Tínhamos 3 grandes áreas de atividade:
- . , , , .
- . , «» .
- . HR, , IT, . .
Conseguimos estabelecer o trabalho normal apenas no 3º sprint: percebemos mais ou menos que precisamos focar nas áreas 1 e 2, porque os gerentes de projeto falam de dor, e os chefes de serviço de suporte falam de desejos.
Não vou esticar o artigo e dizer como o Agile é legal em si e como ele ajuda muito. Mas aqui está o que realmente posso dizer depois de trabalhar neste modo por cerca de 30 sprints:
- Scrum é uma abordagem de trabalho. Você investe recursos e metodologia e obtém suprimentos.
- – . , , , . , , , , « », – .
- . , , . , , – . PM – , , , – , – .
Tenho menos experiência desse tipo, então esse grande e pesado fardo recaiu em maior medida sobre o Product Owner: comparar as expectativas das partes interessadas com a realidade, entender claramente as capacidades de minha equipe, ter um olho limpo, entender a situação do mercado, equilíbrio entre direcionar recursos para funcionalidade útil, experimentos e "mal necessário" - segurança de soluções, organização de arquitetura de serviço, ambientes, documentação.
- PM . , . -. Devops , , : , /. , , Agile - , : , , .
- - – . , -. , . , PM -, . , . , , !
Não começamos o desenvolvimento do zero. Tínhamos muitos desenvolvimentos na empresa que podiam ser usados de uma forma ou de outra - havia apenas dois autoclassificadores.
Senti um déjà vu quando coletei tudo isso de diferentes projetos, divisões, como uma vez coletei desenvolvimentos em meu primeiro projeto.
Começamos a desenvolver o sistema de diálogo com várias bibliotecas de código aberto - e uma delas foi DeepPavlov. Não tínhamos muita experiência com ele e nas nossas tarefas a qualidade do reconhecimento revelou-se medíocre. Logo mudamos para o Rasa e lá as coisas correram muito melhor - e ao retreinar o modelo em nossos dados específicos, obtivemos um reconhecimento bom e seguro dos diálogos.
O layout dos próprios diálogos era feito manualmente - naquele momento havia caras no SD que assumiram essa tarefa. Nosso desenvolvedor Python líder escreveu rapidamente um programa de marcação e alimentamos o modelo com algumas dezenas de milhares de conversas. Os fragmentos foram tirados bem curtos, de 3 segundos cada - assim o resultado ficou melhor.
Inicialmente, tínhamos 2 máquinas virtuais no Windows e no Linux, alguns dos serviços só funcionavam no Windows. Mas quando começamos a trazer os primeiros desenvolvimentos para o piloto, percebemos rapidamente que 2 máquinas virtuais para um projeto é muito caro, precisamos refazê-lo. Agora usamos uma máquina virtual no Ubuntu para produção. Claro, são todos isolados e cada projeto tem sua área.
Também percebemos rapidamente que configurar duas máquinas virtuais, aumentar e depurar todos os serviços, abrir portas e outras configurações leva um tempo absolutamente indecente. Depois disso, fizemos uma solução de CI / CD baseada em Docker - tanto para o código principal quanto para a parte de ML.
Em algum momento do 9º ao 10º sprint, fomos confrontados com um pedido de muitos clientes para fazer seu próprio sistema de reconhecimento de voz. A maioria dos clientes não estava pronta para transferir suas informações confidenciais para as "nuvens" para terceiros. Então, escrevemos esse sistema e agora podemos oferecê-lo onde é importante ter toda a arquitetura dentro do perímetro de segurança - por exemplo, para empresas intimamente relacionadas ao estado. Ou coloque-o em nossa infraestrutura, sabendo com certeza que dados sigilosos não chegarão a terceiros.
Implantamos um sistema de monitoramento de componentes, configuramos verificações de saúde e integramos o sistema a um canal de chat no Telegram.
E, finalmente, vou falar sobre mais uma sutileza que pode ser útil para alguém ao projetar seu bot de bate-papo. Inicialmente, todo o nosso código era bastante monolítico e era trabalhoso fazer alterações nele. Dividimos o chatbot em duas grandes partes: o bot de base e a personalização. Tivemos que reescrever a lógica - mas graças a essa separação, pudemos implantar rapidamente os componentes básicos e comuns do bot e editar apenas o que era personalizado para cada projeto específico.
Resultados do projeto
Compreendemos claramente a natureza de nicho de nossa história: não seremos capazes de competir com produtos embalados que foram desenvolvidos por uma dúzia de anos, e não há necessidade disso. Nosso nicho é fornecer ferramentas de automação em qualquer estágio de um projeto de serviço, desde a pré-venda até o vencimento do contrato. Em outras palavras, inicialmente não tínhamos o objetivo de fazer o Google - mas o objetivo era fazer um designer que ajudasse a vender o Service Desk, ajudasse a reduzir o custo da prestação de um serviço e desse oportunidades adicionais aos clientes e seus negócios.
Também observei um ponto interessante para mim: raramente uma solução embalada no mercado pode cobrir completamente a dor de um cliente e, ao mesmo tempo, conseguir um preço. Ou o cliente paga a mais pela funcionalidade, que não utilizará posteriormente, ou algumas das melhorias terão que ser feitas por especialistas ou especialistas do fornecedor selecionado, caso ele a aceite.
E aqui temos uma tarefa de integração interessante e bastante difícil, além de oferecer puramente nossas próprias soluções de automação, construir um sistema para o cliente a partir de nossos desenvolvimentos e soluções de terceiros que já estão no mercado, se adequar à funcionalidade do cliente e manter tal sistema como serviço. Talvez eu fale dos resultados desse trabalho nos próximos artigos, se houver interesse.
A maioria de nossas ferramentas e desenvolvimentos já foram implementados nos serviços atuais, estamos testando alguns e iremos refinar alguns no BAU. O chatbot ainda se sente o pior de tudo, hoje é o menos útil para projetos - talvez porque as expectativas agora são muito altas. Todo mundo quer um robô inteligente que possa perceber a fala humana, responder calmamente a todas as perguntas do usuário, ser capaz de lidar com interrupções, ter integração em todos os sistemas, aprender a si mesmo sem intervenção humana e, com o tempo, reconhecer cada vez mais intenções.
Mas qualquer desenvolvedor que seja bem versado no assunto entende o quão difícil é essa tarefa - afinal, mesmo aumentando a funcionalidade e aumentando o número de intenções que um bot pode reconhecer, podemos piorar o reconhecimento de intenções existentes. Mas isso foi uma digressão - em geral, parece-me que, no entanto, cumprimos a tarefa principal do projeto.
O que aconteceu na saída
1. Assistente de voz inteligente e designer de roteiro para isso. Elimina a necessidade de automatizar o fluxo de entrada de chamadas, reconhece a fala do usuário, voz em texto e transmite para mail, chat, sistema ITSM, dependendo da configuração. Ele pode se integrar com vários sistemas diferentes, seja com conectores prontos ou com aqueles que escrevemos.
2. O discador com o mecanismo do assistente de voz.Elimina a necessidade de chamar o conjunto de números especificado e, em seguida, coleta as respostas do usuário dependendo do cenário. Chamadas regulares são possíveis, há uma configuração para o número de perguntas repetitivas para esclarecer quantas vezes e após a que horas devo ligar de volta. Armazena dados em chamadas feitas junto com resultados de chamadas e gravação de chamadas. Agora é usado para lembrar os engenheiros sobre o patching para um projeto implementado para uma grande varejista de alimentos internacional, no departamento de RH ao organizar entrevistas para cargos de massa, em planos de coletar informações sobre a qualidade dos pedidos resolvidos em uma grande rede de restaurantes fast food.
3. Um chatbot para criar um aplicativo, redefinir uma senha e um designer de script para ele.Sabe como solicitar informações primárias para registrar uma solicitação, registrar uma solicitação no sistema ITSM e retornar um número de solicitação. No momento em que o artigo for publicado, ele aprenderá a mostrar uma lista de aplicativos abertos com a capacidade de adicionar informações a eles ou fechá-los. Ele pode se conectar a diferentes sistemas ITSM, com ou sem acesso à API.
4. Ferramenta para controle de qualidade. Ele sabe um pouco até agora: ele rastreia chamadas, reconhece se a operadora cumprimentou ou não, identifica palavras geradoras de conflito, companheiro em um diálogo, tem uma interface completa para o controlador de qualidade. Eles fizeram isso sozinhos, mas pode ser útil no CC.
5. Auto-classificador.Ele é capaz de analisar aplicativos no sistema ITSM, preenchê-los e enviá-los aos grupos de soluções necessários. Pode levar em consideração a disponibilidade, carga de trabalho e especialização dos engenheiros. Por exemplo, você pode configurar a lógica de que todos os aplicativos EDS devem ser enviados para os principais especialistas Vasily ou Andrey: se o Vasily não estiver de serviço, o aplicativo irá para Andrey e vice-versa. Se não ambos, o tíquete será adicionado à linha geral de suporte a aplicativos de negócios. Se Vasily tiver 2 inscrições e Andrey tiver 1, uma nova inscrição será enviada para Andrey. Você pode retreinar o modelo com segurança, aumentando a precisão. A desvantagem do sistema é o seu objetivo.Você não deve esperar 100% de precisão do modelo ou trabalhar em todo o volume de aplicativos. Em uma amostra de teste, obtivemos 90% de precisão para 50% dos aplicativos com dados muito consistentes, onde os usuários estão acostumados a trabalhar com modelos. A segunda desvantagem é o volume de pedidos. Não faz sentido treinar o modelo se você tiver menos de 1000 aplicativos por mês.
6. Ferramentas para aplicativos de solução automática.Este é um conjunto de ferramentas da GUI com scripts que automatizam as ações padrão de um agente de suporte técnico: coleta de logs de sistemas, captura de tela, inclusive no modo de sombra, atualização de políticas e outras coisas específicas de cada projeto. A segunda ferramenta é a automação dos aplicativos em que a aprovação é necessária. A própria ferramenta gera uma carta ao aprovador com links para aprovar / recusar e, com base nos resultados, ela própria dá um comando para conceder acesso, ou gera uma carta com uma recusa.
Em vez de adeus
O inverno está chegando, o projeto fecha no final deste ano, eu
Obrigado pelo seu interesse e pelo seu tempo, não fique doente!