Boa tarde Eu gostaria de contar uma história curta que aconteceu comigo não muito tempo atrás e está conectada tanto às expectativas de carreira quanto a uma percepção errônea do que está acontecendo na realidade. Como um empregador pode enganar ou inconscientemente prejudicar a motivação da equipe.
Chegando a uma cidade da província de Moscou, eu ia conseguir um emprego como chefe do departamento de TI de alguma empresa. Depois de concluir o desenvolvimento profissional em Moscou e todas as etapas do trabalho, da primeira à terceira linha, percebendo que gosto da gestão e da gestão de pessoas / processos e posso fazê-lo, comecei a procurar uma vaga.
Detalhes sob o corte.
Eu não estava especificamente distraído com as vagas dos transformadores quando a empresa precisou de “especial, ceifador e jogador” (é quando uma pessoa precisa soldar placas e escrever configurações 1C); esperei pacientemente por uma boa oferta. Após 2 meses, o vice-chefe do departamento veio até mim com uma proposta que era difícil não concordar. A direção acabou de aparecer, uma empresa de escala federal, criando um departamento de suporte e desenvolvimento na região, os planos eram grandiosos e totalmente consistentes com minhas expectativas. Foi possível construir uma equipe e processos a partir do zero, otimizar e integrá-los aos processos existentes. Todos chamaram a posição com as funções de "coordenador / chefe de suporte técnico". Bem, eu estava pronto para a batalha.
Objetivos iniciais:
- Suporte na primeira e segunda linhas.
- Criação da Base de Conhecimento
- Criando documentação do usuário
- Aprofundar o processo comercial para a implementação de "consultas comerciais"
- Para preparar as regras para interações entre unidades dentro da estrutura da metodologia ITIL Service Desk (planejei retirar apenas o processo de aprovação de aplicativos e incidentes + redação de SLA, porque sei que ninguém dará uma implementação tediosa de um processo totalmente formalizado, e não funcionará)
- Contrate pessoal de suporte.
Criação de documentação
O que eu queria: Como tinha que manter o sistema de informações adquirido e costumava lidar mais com a infraestrutura de hardware, decidi entrar no curso das coisas gradualmente e pelo lado mais óbvio para mim - solicitei as regras dos processos automatizados pelo sistema e a documentação para ela. E tive a primeira surpresa - não havia documentação para o sistema comprado por "dinheiro". Havia slides esboçados pelo desenvolvedor no joelho, como certas funções estão envolvidas no processo, e isso é tudo. A empresa teve mais 4 meses de suporte ao contrato, quando puderam ser contatados com perguntas sobre a operação do sistema. Não havia projeto interno para a implementação do sistema, os prazos foram estabelecidos por acordo e um documento do Excel, que indicava as datas para a implementação de determinadas melhorias. Sim, após minha contratação, o sistema foi complementado por mais 5 meses.
O que aconteceu: Com um pecado ao meio, vários processos são descritos na forma de diagramas do Visio. Módulos do sistema parcialmente descritos. Devido ao prazo, a comunicação com os desenvolvedores do sistema adquirido se tornou ainda pior. Pelo que entendi, a documentação não era obrigatória no momento da compra.
Conclusão: Um sistema inacabado não documentado é mal descrito sem a ajuda de desenvolvedores. Tente estabelecer um processo de comunicação.Criação da Base de Conhecimento
O que eu queria: O suporte na primeira linha deveria coletar um certo conjunto de perguntas dos usuários; supunha-se que os gerentes já tivessem esse pool, pelo menos parcialmente. Mas, após negociações com o chefe do departamento de vendas, ficou claro que não havia pool e o processo seria assim: o usuário chama, se estiver conectado à parte técnica, ajudamos, se com a parte comercial, ligamos de volta. Como a parte comercial das respostas não era de todo, os primeiros usuários não deveriam ter muita sorte. Mais uma vez, durante a conversa, percebi que os negócios realmente não valorizam novos usuários e estão prontos para assumir esses riscos.
Para esclarecer, com essas fontes o quadro parecia bastante vago, mas tomei isso como um desafio.
O que aconteceu: Um documento foi criado para cobrir o volume inicial de consultas de negócios. O procedimento para trabalhar com a empresa não pôde ser regulamentado. A empresa pode esquecer de responder a uma nova pergunta "não da lista". Eu tive que solicitar novamente, mantendo o controle. Uma base de conhecimento foi criada com base na docuwiki com uma descrição dos problemas, arquitetura do sistema, ações básicas da segunda linha de suporte e administradores. Não foi possível descrever a configuração para criar um novo produto no sistema, porque ele foi criado de maneira semiprogramável e era necessário descrevê-lo junto com os programadores.
Conclusão: Criar uma base de conhecimento que sacrifique a lealdade do cliente é o passo errado. Se a empresa fizer isso, um ônus adicional recairá sobre o suporte na forma de desculpas por defeitos e contenção de clientes negativos adicionais.Recrutamento de pessoal
O que eu queria: Para selecionar funcionários, fui à minha equipe metodicamente: selecionei uma lista de competências e fiz perguntas para uma entrevista por telefone para essas competências. No início, todas as perguntas tinham o mesmo peso e, após algumas entrevistas, percebi que todos os candidatos são igualmente adequados para a vaga e em um ritmo que você pode contratar pessoas por um longo tempo. Todas as competências receberam peso e o processo foi mais divertido.
Tabela de competências de primeira linha:
Este modelo foi enviado para aprovação pela gerência, mas a resposta "aplicar não aplicar" não retornou.
Peguei a primeira pessoa sob recomendação de um colega antigo sem modelo (trabalhei por uma semana). O próximo chefe levou. As três restantes (meninas) foram recrutadas em parte com a minha participação, mas sem pedir minhas recomendações e não estar interessado em opiniões. Admissão a motivação e orçamentos materiais que não recebi.
O que aconteceu: Foi recrutado um departamento divertido, mas que não atendia totalmente aos requisitos, onde os funcionários fazem um excelente trabalho com a primeira linha, mas para uma imersão mais profunda no sistema, é necessário um processo adequadamente estruturado de treinamento e transferência de conhecimento. Comigo, pessoas com RFPs acima da média do mercado perderam a motivação intangível aos olhos devido a um processo de trabalho definido incorretamente.
Conclusão: prepare para o novo funcionário motivado a quantidade de trabalho. Caso contrário, isso afeta muito a lealdade ao empregador e ao sistema. Entenda o processo de motivação da equipe - material e imaterial.Processo de trabalho
O que eu queria: Depois de iniciar o sistema, começamos a encontrar as primeiras dificuldades: a interface antiga parecia horrível e funcionava contra todos os conceitos de fácil utilização. O fluxo principal de chamadas foi para a insatisfação com a interface, e não com o processo de negócios. Os usuários simplesmente não puderam fazer uma solicitação. Os principais erros foram imediatamente levados à equipe de desenvolvimento recém-recrutada, mas aqui enfrentamos um segundo problema: não havia comunicação não apenas com aqueles que apoiavam o sistema de fora, mas também não havia priorização para consertar o sistema - todos os esforços foram dedicados à criação de novos. funções e produtos, não foi possível alocar uma pessoa para corrigir erros elementares que reduziriam pela metade o número de chamadas.
O que aconteceu: Depois de apontar novamente os problemas para a gerência, ele ainda deu permissão para fazer correções e o fluxo de chamadas diminuiu três vezes.
Conclusão: estabelecer o processo de priorização de tarefas, discutindo a ordem de interação com a equipe de desenvolvimento.Diante de cada uma das tarefas acima, eu sempre entrei na gerência com sugestões para otimizar processos e tentar coordenar minha visão com a visão da empresa, mas sempre me deparei com o emprego do gerente (um problema no sistema) ou recebi a resposta "até agora" e "não queremos formalizar demais" " Eu também sabia que estava planejado expandir o departamento para 5 pessoas e vi que era necessário entender como o processo e os recursos de suporte seriam gerenciados. Eu já comecei a suspeitar que as autoridades haviam mudado de planos para mim por causa de minhas constantes tentativas de implementá-las. Não era mais chamado coordenador ou chefe, não participava de comícios relacionados ao desenvolvimento do sistema.
Depois disso, decidi preparar uma estratégia e entender se estou fazendo isso. Porque o chefe não se comunicou comigo em termos de estratégia. A estratégia foi direcionada imediatamente para uma pessoa superior em TI em Moscou e, para mim, a imagem do meu trabalho mudou. Então a estratégia foi direcionada de Moscou aos meus chefes diretos e eu entrei em confronto com o chefe local.
Conclusão: Analise a estratégia da unidade. Definir planos de curto e longo prazo. Discuta a visão com liderança.A segunda parte do "Marleson Ballet"
Após o episódio descrito acima, o chefe direto praticamente parou de falar comigo. E comecei a pensar em sair. Inicialmente, vi um projeto interessante que, depois de superar certas dificuldades com a interação correta de todos os participantes do processo, poderia ser concluído com êxito, tendo recebido um forte departamento de suporte motivado com os KPIs certos e com indicadores de saída claros que são compreensíveis para os negócios. Agora, vi que o departamento estava caindo na rotina sem realmente desenvolvê-lo. Duas tarefas se tornaram uma prioridade - atender chamadas e descrever bugs (não melhorias) do sistema usando o gitlab, que os desenvolvedores corrigiram.
Outra história é o processo de "teste", como o gerente chamou, que também propusemos realizar. Ninguém entendeu esses procedimentos, nem um testador separado. Teste funcional da “caixa preta” sem nenhum indicador de desempenho por toda a equipe antes do lançamento. Nenhum outro método foi utilizado. Os funcionários recrutados não puderam participar efetivamente dos testes devido à falta de experiência na esfera do desenvolvimento e à falta de treinamento. As datas de lançamento falham constantemente ou lançavam sem teste.
Conclusão: o departamento não pode lidar efetivamente com dois grandes processos em paralelo. Haverá dois processos em andamento de alguma maneira.
O confronto continuou. O gerente conseguiu inverter todos os elementos de gerenciamento que eu considerava importantes:
- visão estratégica
- controlar
- gestão
- motivação
Pontos mágicos como "lealdade à empresa na forma de vir trabalhar mais cedo e sair mais tarde" também foram expressos.
Tendo finalmente perdido minha motivação, convidei o chefe para falar sobre minha posição na empresa e a decisão de deixá-la, onde me disseram que o departamento em sua forma atual se adequa a todos e que não há planos para desenvolver elementos individuais. Como resultado, saí da empresa, tendo adquirido experiência prática na tentativa de realizar minha visão do trabalho do departamento de suporte.
O que aconteceu: experiência, experiência e novamente experiência.
Conclusão: Quais erros eu gravei para mim:
- Para não perder tempo - corrija e coordene os planos com antecedência
- Defina claramente sua estratégia. Se houver omissões - resolva os problemas imediatamente
- Decida um fluxo de trabalho confortável para si mesmo. Encontre um compromisso entre sua motivação material e não material
- Talvez eu tenha passado muito tempo entendendo essas coisas. Muito estava na superfície
Também gostaria de ouvir dos colegas suas histórias e nuances de implementação, das quais, inexperiência, não prestei atenção.