Retorno da frente: o campo de batalha de TI
Como um herói conquistador que volta de uma campanha extenuante na paisagem distante que se chama Geórgia, voltei vitorioso. Não sou novo na Engineering. Nem sou novo no escritório. Mas faz um tempo desde a última vez que eu estive aqui.
No último ano e alguns meses, tenho trabalhado com um farmacêutico chefe global especializado no tratamento de doenças raras. Fui estacionado em uma fábrica que produziu imunoglobina e albumina; em outras palavras, coisas sérias. Minha função era treinar seus usuários finais sobre como usar e validar seu software para EBR (Electronic Batch Records). Um pouco sobre o software: é a unidade central no software de produção naquela fábrica. Todo outro software se comunica com ele de alguma forma, seja quem puxou as amostras e quando para ajustes de inventário para os materiais utilizados.
Todo projeto começa com desafios, e então você encontra algumas surpresas. Tentar fazer com que as pessoas gostem de um software que alguém projetou é quase como tentar ensinar truques a um gato. Entrando nisso, você sabe que não será fácil, e você pode se questionar se vale mesmo a pena. Mas no final, você ficará feliz quando tiver sucesso e o cliente estiver feliz.
Passei muito tempo investigando configurações, descobrindo o que acontece quando isso acontece ou se isso faz isso, então o que faz isso. E em um nível básico, essa é a base para validação de software. Cada caminho deve ser testado, cada botão tem que fazer o que deve fazer, e não há nada por acaso. Há uma ótima razão para trazer alguém como eu ou qualquer outra pessoa da equipe Engineering para testar, mesmo (e especialmente) se não escrevemos as instruções do processo. Porque quando nos dão instruções de validação, seguimos os testes cegamente, o que muitas vezes nos leva a encontrar um problema no software ou no caso de teste do qual ninguém mais estava ciente. Depois de muitas horas difíceis testando as instruções, finalmente criamos um produto pronto para uso. Nosso tempo quebrando o software agora pode ser gasto ajudando a produção a corrigi-lo quando o quebram. Durante execuções de produção, eu era um membro-chave do suporte de software, e às 0215, quando tudo dava defeito, eu era chamado para perguntarem "O que fazemos?"
Eventualmente, todos os projetos terminam. A manufatura foi treinada para como corrigir quando as coisas não saem como planejado, a comunicação entre os diferentes sistemas estava ficando forte, e finalmente ganhei minha liberdade condicional.
Conheça Scott Scheeringa
Onde você nasceu/cresceu: Highland, Indiana
Sua educação: Bacharel em Ciências da computação pela Universidade de Indiana
Seu título: Analista de TI sênior
Sua prática na Engineering: Manufacturing Operations, treinamento para software
Localização do seu escritório: Chicago, EUA
Há quanto tempo você trabalha na Engineering: 3 anos (desde outubro de 2017)
Suas áreas de especialização: Suporte de TI e treinamento para software
Projeto mais legal: A cada duas semanas, eu estava em outro lugar, fazendo novas apresentações e treinando novas pessoas em um novo software (para eles). Este projeto me permitiu criar e treinar uma equipe de suporte para ajudar com qualquer problema que as fábricas enfrentassem.
Suas metas de carreira: Estive estudando gestão de projetos no meu tempo livre e espero que um dia se torne o candidato para o desenvolvimento de planos de treinamento e suporte para uma infinidade de projetos diferentes.
Melhor coisa sobre o que você faz: Eu consigo trabalhar de perto com as pessoas aprendendo diferentes processos de manufatura, e ensinando-as algumas coisas ao longo do caminho.
Seus interesses pessoais: Leio muito, principalmente ficção, jogo e, em geral, aproveito a vida.
Filme favorito de todos os tempos: É um empate entre A Princesa Prometida e Starship Troopers.
