Programador Exorcismo

Há muito material sobre como a introdução de sistemas de informação ajudou as empresas a se livrarem de perdas, reduzirem custos e reduzirem o roubo. É maravilhoso quando se acaba com o mal em um volume tão grande.

Meu artigo é sobre um mal menor. Sobre sabotagem de implementações, sobre o eterno "Estou fazendo tudo certo, é culpa do seu programa", sobre inchaço, sobre pequenos assuntos corporativos e resistência à mudança.

Tudo no artigo é de experiência pessoal, com exemplos de uso. Eu não pretendo singularidade e divulgação completa do tópico, não há verdade mais elevada aqui, tentei evitar generalizações, não impo nada.

Apenas a experiência de usar algumas ferramentas e exemplos de como eles me ajudaram.

Gravando ações do usuário com parâmetros de tempo

Sinceramente, não me lembro por que fiz isso, mas foi útil várias vezes. O desenvolvimento é simples e desajeitado, não leva mais que uma hora. Não aplicável em qualquer lugar, pois pode consumir muitos recursos e os dados ocupam uma quantidade significativa de espaço em disco; portanto, é necessário monitorá-lo.

O princípio é simples:

• registra quando o usuário abre o formulário (documento, diretório, relatório, processamento);
• toma notas quando ele fechou;
• registra quando ele o gravou (se for um objeto armazenado, como um documento ou diretório);
• registra se era um objeto novo ou antigo;
• registra tudo o que você precisa saber sobre o objeto - link, tipo nome, nome de usuário, nome do formulário.

Como resultado, temos uma tabela grande com dados e vários dígitos calculados. Por exemplo, conhecemos o "cheque médio" - quanto tempo leva para criar o recebimento de uma fatura por um contador. Sabemos quantas vezes um contador retorna a um documento criado anteriormente para alterá-lo e quanto tempo ele gasta nele.

Vou dar exemplos de quando o mecanismo foi útil.

O primeiro é a eliminação da sabotagem mesquinha da implementação. Foi introduzido um mecanismo para escolher um pedido no armazém - o lojista deve marcar os itens coletados na caixa. Os lojistas foram informados claramente - sem fanatismo, trabalhem com o sistema somente quando houver tempo livre.

Um dia depois, o gerente de expedição vem correndo, diz - os lojistas se recusam a carregar o carro, dizem que precisam direcionar dados para algum sistema e isso leva 2 horas por dia. Claro, eu rapidamente explico que ninguém lhes deu tais ordens. Eu abro meu relatório, eu vejo - eles gastam 20 minutos por dia com todos . Ele disse ao gerente, ele disse aos lojistas - isso é tudo, não havia mais tais declarações deles.

Segundo exemplo. Findir solicita algumas funcionalidades para gerenciar dinheiro. O importante não é porque quer, mas porque esse ciclo contábil não é suficiente para os mais altos. Em uma reunião geral, perguntam a ele - por que, quando os dados aparecerão? Ele diz - há erros, não funciona, escreveremos uma tarefa para os programadores finalizarem. Abro o relatório, mostro que nem ele nem as meninas entraram no documento ou no relatório. É isso aí, a introdução mudou.

O terceiro exemplo. A contabilidade diz: precisamos expandir a equipe, aumentamos o fluxo de documentos. A gerência, consciente do meu relatório, é solicitada - forneça estatísticas, o que cresceu lá e onde.

A primeira contagem na testa - o número de documentos e o número de linhas neles - mostrou que o fluxo de documentos não aumentou.

Tudo bem, acho que, talvez algo complicado nos documentos, possa ficar mais difícil elaborá-los.

Eu olho para o "cheque médio" e sua dinâmica para dois contadores - não, parece que não cresce, não cai.

Ocorreu-lhe que um contador de longa data havia saído recentemente de licença de maternidade e dois novos estavam em seu lugar. Eu tinha dados para todos os três, eu comparo - bah, aqui está. Dois novos contadores inserem documentos mais lentamente que um antigo.

Tudo, a expansão do estado foi cancelada, basta aguardar até que eles encham a mão. Ao mesmo tempo - um pouco de automação.

Do terceiro exemplo segue o quarto , já positivo. Vendo a dinâmica da “verificação média” por tipo de objeto, começamos a usá-la para analisar a automação das operações e as consequências das mudanças. Se a “verificação média” crescer, analisamos os motivos, observamos as pessoas viverem e melhorarem.

Registrar valores de métricas

Tecnicamente, esta é uma solução muito simples. Sua essência é simples - é escrita uma consulta que calcula alguns dígitos e os salva no sistema com a frequência desejada. Como resultado, temos a dinâmica a tempo para a figura.

Muitos números não precisam ser memorizados, porque eles são reproduzíveis. Por exemplo, não há necessidade de lembrar o volume de vendas - você sempre pode analisá-lo retrospectivamente.

Mas alguns números podem ser reproduzidos apenas aumentando o banco de dados de backup. Por exemplo, esta é a única maneira de descobrir quantos saldos negativos em mercadorias você possuía há um mês. Quem lê meus artigos anteriores entende que isso é sobre Iceberg .

Primeiro caso de uso. Há problemas com a compensação do pagamento antecipado - uma quantia bastante grande fica suspensa simultaneamente em 60.01 e 60.02. A funcionalidade é típica, não há dificuldades metodológicas - basta indicar a análise correta nos documentos e o avanço será contado. Nas reuniões, a contabilidade diz - não há problema, vamos fazer isso. Em cada reunião subsequente, ele repete - estamos fazendo, há muito trabalho, automatizado mal. Eles olham para mim com desconfiança.

Eu venho, ligo o registro do indicador - a quantia do adiantamento não registrado. Eu acho - não, eles farão isso, dirão que o avanço não reconhecido está crescendo mais rápido do que o corrigem. Divido o indicador em três partes - o valor no início do ano, o valor no início do mês, o valor para hoje.

Na próxima reunião, mostro os números - como foi e como se tornou. Um avanço não reconhecido no início do ano e no início do mês é uma aposta - eles não consertaram nada. O avanço não reconhecido de hoje não mudou muito - o que significa que agora os documentos são normalmente redigidos. Como resultado, erros antigos foram corrigidos em 2 dias.

Segundo caso de uso. Automatizada a cadeia de suprimentos, a função é simples - o programa informa quanto você precisa pedir aos fornecedores, pegá-lo e comprá-lo. Separadamente, o mecanismo especificado grava o nível de déficits atuais. Observamos - o déficit está diminuindo em algumas posições e crescendo em outras. Pessoas diferentes são responsáveis ​​pelos cargos. Na reunião, todos dizem - sim, fazemos tudo como ordenado, olhamos, pedimos. Por que os déficits estão crescendo - não sabemos, a automação provavelmente é ruim, os números são calculados incorretamente. Todo mundo olha de soslaio para mim.

Eu vou de frente - olho para os pedidos feitos aos fornecedores. Não consigo descobrir imediatamente, porque documentos são inseridos e alterados não prontamente - isso é normal, porque O processo de aprovação pode levar vários dias e será ajustado todo esse tempo.

Anotei um registro de dois indicadores individualmente para cada fornecedor - quantos itens estavam disponíveis para pedidos pela manhã, quantos deles foram pedidos durante o dia. E voila - a gerente “boa” (garota legal) encomendou 85-100% do que o sistema exigia, as “ruins” - 15%. Tudo, o trabalho com disciplina se foi. O que é interessante - os fornecedores, vendo este relatório, foram solicitados a entregá-los para uso (os próprios fornecedores, e não o supervisor). A diferença entre o meu e o relatório deles era simples. O relatório deles mostrava resíduos atuais, e o meu ainda mostrava a "vida útil" desses resíduos. Tudo o mesmo Iceberg.

Fixando idéias

Várias vezes ouvi de programadores que as idéias foram roubadas deles, especialmente os chefes. Eles escutam a idéia, depois dizem que não se trata de nada e, depois de algum tempo, passam a ideia por conta própria.

Geralmente tenho muitas idéias, não julgarei a qualidade, mas na verdade existem muitas. Notei há alguns anos que não me lembro deles. Acontece que eu tenho uma idéia várias vezes.

Então vi no site do estúdio Artemy Lebedev que eles estavam escrevendo idéias e acharam que era útil. Decidi fazer o mesmo - no sistema de contabilidade de tarefas, fiz um dividendo para mim mesmo, onde comecei a escrever essas idéias. Estava disponível apenas sob todos os direitos, como Eu precisava apenas.

Em seguida, a empresa decidiu sistematizar o trabalho com propostas de racionalização - arquivamento, avaliação, contabilidade de implementação etc. Me perguntaram se é possível automatizar, eu disse - tudo já está automatizado, mostrou seu mecanismo. Eu o modifiquei um pouco para que houvesse votação, comentários, contabilidade de implementação, definição de tarefas etc. Mas esse não é o ponto.

O ponto principal é que as idéias se tornaram públicas e fixas, e tornou-se difícil roubá-las. A minha é quase impossível, porque no momento em que o sistema foi aberto para os usuários, ele já continha várias centenas de meus registros.

O primeiro caso de uso nem exigiu minha participação. Muitas pessoas leem idéias e, quando alguém fez uma proposta em algum lugar, os leitores disseram-lhe abertamente - bem, havia uma ideia, olhe no sistema, há uma discussão lá. Se eu não estava presente nessa conversa, o inventor foi enviado a mim e, geralmente, ele começou a frase com “você propôs essa ideia, eu li, é interessante, vamos implementá-la ...”.

O segundo exemplo está relacionado à promoção de um sistema de propostas de racionalização. Naturalmente, anexei o rastreamento de leitura à funcionalidade de corrigir idéias. E aconteceu que os funcionários de alguns departamentos, realmente tentando mudar seu trabalho para melhor, começaram a fazer suas propostas ao sistema. Mas apenas propostas relacionadas à automação foram implementadas, porque eles foram endereçados a mim, mas foi interessante para mim.

Nas reuniões, os gerentes foram perguntados - como você está com a implementação das propostas? Alguma idéia útil da sua equipe? Muitos responderam amigavelmente - não, nada de interessante, toda bobagem. Eu mostro o relatório - eles não entraram no sistema, não leram uma única idéia, sem mencionar a implementação. Para o caso, eles perguntaram aos funcionários - você pode dar verbalmente aos seus gerentes ou enviar por correio suas sugestões? Não, dizem eles, não houve essa desova e, em geral, temos medo de levantar a cabeça.

Os dados fornecidos, o processo saiu do chão.

Captura de dados

O objetivo desse mecanismo é expandir os recursos de versão. Geralmente, o controle de versão (padrão e não padrão) captura as alterações nos dados primários - diretórios, documentos etc. Na prática real, isso não é suficiente.

Por exemplo, o "voou de volta" com diferentes variações da "mosca". A maneira tradicional é examinar as alterações nos documentos que podem afetar ou gerar um backup, carregar detalhes no Excel e comparar as revoluções.

O problema também é que uma pessoa deve acompanhar o momento do "spin-off".

Como resultado, ele criou um mecanismo simples que armazena lindamente a estrutura complicada das revoluções e reage às mudanças. E a área de dados para correção, convolução e periodicidade - é configurada por meio de uma consulta.

Sem entrar em detalhes, o mecanismo sinalizou sobre alterações na área de dados (“a recuperação ocorreu”) por uma hora (esta é a frequência da operação da tarefa.), Indicou a área de dados, indicou o período e tornou possível encontrar os dados primários.

Sim, e permitiu “aceitar as alterações” - se tudo fosse honesto, os dados alterados se tornariam a referência e o rastreamento já estava em andamento nas alterações.

Primeiro caso de uso. As pessoas começaram a reclamar de picos de energia no armazém (“olho para as 10 da manhã, olho para as 5 no almoço e já prometi ao cliente, e não sou boba, vejo que não há movimentos há uma semana”). A contabilidade diz - não temos nada a ver com isso, todos os documentos são executados em um dia, sem correções retroativamente. Nós olhamos para o mecanismo - voila, os saldos hoje estão mudando, porque o momento do mês anterior mudou. Bisbilhotando - o contador introduziu um novo documento há um mês. Perguntamos - o que você está fazendo? Eu não tenho tempo, ela diz.

Segundo caso de uso. Gravei dados de vendas - simplesmente porque testei o mecanismo nessa área de dados. Acreditava-se que os dados de vendas mudam por no máximo uma semana e, em casos raros, quando erros são cometidos. E aqui estou: as vendas do mês passado mudaram. Você entende que, no mês passado, o gerente de vendas já recebeu um prêmio. Vejo que o contador mudou - o que você está dizendo? Aconteceu que o gerente forçou, porque ele era esperto demais, confundiu o cliente. Após esse incidente, o contador parou de fazer isso.

Perguntas para controle

Tarefas de controle funcional, projetos, etc. existe, por exemplo, em 1C: Gerenciamento de documentos, provavelmente muitos já viram. Lá você pode controlar qualquer objeto (ou quase qualquer), definir uma data e um lembrete é exibido.

Eu não gostei do típico, porque ele não permite que você faça o controle em vários estágios - por exemplo, para fazer o lembrete aparecer 10 vezes em intervalos de uma semana. Portanto, criei meu mecanismo simples, cuja principal diferença é que ele permite manter um histórico de controle e esticá-lo por qualquer período de tempo.

Por exemplo, inicio uma mudança nos processos de negócios. Estou escrevendo cartas, tendo reuniões, etc. Eu escrevo essa pergunta no meu sistema, coloque um ponto de controle - em uma semana, escrevo um comentário como "pergunte ao Vasya novamente". Depois de uma semana, vejo um lembrete, pergunto a Vasya novamente, Vasya diz "aah, ouça, temos um bloqueio, até agora não há tempo". Ok, eu digo, eu coloco o próximo ponto - em uma semana. Vejo um lembrete, entro - vejo uma história. Eu pergunto a Vasya novamente, Vasya novamente tem um bloqueio. Eu digo - Vasya, você já disse isso. Vasya jura que essa foi a última vez. Depois de uma semana, o movimento ainda começa.

Parece algum tipo de bobagem banal, e parece que tudo isso pode ser resolvido pelo correio, mas, como afirmado no início do artigo, eu não finjo a verdade. O uso dessa ferramenta e abordagem me ajudou várias vezes quando é banal obter algo de pessoas que não lhe obedecem. Você não pode definir uma tarefa para eles, e ultrapassar o limite nessa situação específica não é uma brincadeira de criança - as pessoas não farão nada.

Contabilidade de custos de automação

Tecnicamente, é muito simples. Há uma contabilidade de tarefas e projetos no sistema. Em cada tarefa, há uma certa avaliação dos custos do trabalho - horas ou pontuações para o planejamento do pôquer. Conhecemos os salários dos programadores. O cliente, sua unidade e gerente são conhecidos.

Tomamos o salário do programador e o distribuímos para as tarefas resolvidas em um mês. Acontece o custo de resolver um problema específico. Pode ser montado por projeto, por cliente, por unidade.

O primeiro exemplo de uso é a proteção contra colisões, como "eles não lidam conosco, não resolvem nossos problemas". Abrimos o relatório, olha - sim, a empresa gastou 250 tr na automação da contabilidade para o último mês. Ou 1,5 milhão de rublos por ano, por exemplo.

Aqui o truque é que ele é avaliado em rublos - uma unidade de medida que é compreensível para o diretor. Se você disser "resolvemos 113 tarefas do departamento de contabilidade", ele não penetrará - ele dirá que mais precisa ser feito. E quando você diz "você gastou 1,5 milhão em suas tarefas", ele teria vergonha de dizer "gaste outros 2 milhões do meu dinheiro com eles!". Na maioria das vezes, ele suspirava e perguntou ao escritório de contabilidade quais eram as tarefas para as quais 1,5 milhão de rublos deveriam ser gastos.

O segundo exemplo é mais interessante. Frequentemente, os programadores reclamam que estão executando algum tipo de funcionalidade sob as instruções do usuário e, em seguida, ele não usa essa funcionalidade. Ao mesmo tempo, ele continua reclamando que seu trabalho é mal automatizado.

Decidimos ficar mais interessantes. Nas tarefas resolvidas, eles começaram a indicar não apenas o cliente, mas também os nomes dos metadados - documentos, diretórios etc. que foram criados ou finalizados na solução desse problema.

Bem, então é simples. Ele pediu ao chefe do serviço de qualidade para automatizar a verificação dos instrumentos de medição. Solução tecnicamente simples - existem instrumentos de medição, um cronograma de calibração e um documento que fixa o fato da verificação. Após a automação, como esperado, os usuários inseriram um instrumento de medição, um documento de verificação e um gráfico.

E nós calculamos os custos. Digamos que isso seja 30 tr. Conhecemos os metadados, o número de objetos que conhecemos, dividimos um no outro - acontece que em nosso sistema 30 tr são gastos em contabilizar um instrumento de medição Embora o próprio instrumento de medição custe 1 tr.

Quando o chefe do serviço de qualidade da próxima vez em uma reunião começa a dizer que ele precisa automatizar alguma coisa, perguntamos educadamente - como está o "calibre vernier de ouro", por conta de uma verificação de que a empresa gastou 30 tr?

Suporte à contabilidade de custos

Em nós, no suporte técnico, sentou-se uma pessoa - o oficial de serviço. Eu sempre ouvi dele algo como "como ela conseguiu, o idiota estúpido, pergunta a mesma coisa todos os dias". No começo, não prestei muita atenção - você nunca sabe, a pessoa não se lembrava, ou somos os culpados. Então, de maneira indireta, descobri que alguns usuários deliberadamente iniciam ataques DDoS ao suporte técnico, porque não gostam do departamento de TI.

Organizou uma solução de programação simples. Eles fizeram um documento para corrigir chamadas para o suporte técnico. Em geral, quando uma pessoa precisa automatizar algo, ele escreveu a tarefa de qualquer maneira, mas quando tinha uma pergunta, ligava ou escrevia no Skype.

A pessoa de serviço inseriu o sobrenome e o tempo aproximado de serviço no documento. Foi possível ler os logs do Skype por meio da API, mas decidiu não fazer isso - você não contará com a comunicação pessoal e a correspondência dessa maneira.

Bem, então é simples. O custo total do suporte técnico é conhecido pelo parágrafo anterior. Dividimos o dinheiro no momento da apelação, obtemos a figura - que tipo de pessoa e departamento quanto dinheiro a empresa gasta em si mesma.

O primeiro caso de uso é comum. Quando alguém diz que não responde às perguntas dele e ele está indo mal, mostramos a figura. Olha, meu amigo, a empresa gasta 20 tr em suas perguntas por mês.

O segundo exemplo de uso é mais interessante. Chamamos isso de "custo da incompetência". Infelizmente, nossos RHs não eram muito versados ​​nos meandros da contabilidade e não sabiam como verificar os requisitos de vagas nos programas Conhecimento dos Programas 1C, mas não queriam nos enviar testes. Portanto, contamos com contadores que não sabiam como manter registros em um computador.

E agora há um contador que recebe 30 tr. por mês, excluindo impostos. E há o custo do suporte técnico fornecido a esse contador. Por exemplo, 20 tr por mês - programadores são caros. Acontece que o contador custa à empresa 50 tr por mês. Por exemplo, o vice-contador-chefe custa o mesmo valor.

O diretor ficou um pouco surpreso com esses números. Uma coisa é ouvir: “gastamos 50 tr. por mês para suporte técnico dos usuários ”- tudo bem, você precisa. Uma questão completamente diferente - “a incompetência desse contador nos custa 20 tr. por mês ". Há menos pedidos de suporte técnico.

Inesquecível

Quando chamamos o custo de automação, o cliente experimentou inconveniência, mas apenas temporariamente. Ele será repreendido, talvez eles escrevam um pouco bem, e esqueça. Ele recebe indulgência e pode começar tudo de novo.

Essa abordagem não nos convinha, porque tudo voltou à situação de "programadores são ruins". Portanto, agimos de forma simples - começamos a usar as estatísticas acumuladas dos custos de automação.

Tecnicamente, isso é simples - já tínhamos todos os dados, de clientes, departamentos e metadados. E começamos a abolir as indulgências.

Quando chega a conversa de que não estamos resolvendo alguns problemas ou que alguém está mal automatizado, simplesmente levantamos o relatório e mostramos o valor acumulado. Porquetivemos estatísticas divididas por metadados, o valor foi bem dividido em duas partes - boa e ruim.

Bom é a funcionalidade usada. Mau - não utilizado. Alguém ruim era duas vezes melhor.

Análise de versão

Os sistemas de versão em 1C e no mesmo CouchDB funcionam da mesma maneira - eles simplesmente armazenam versões de objetos no momento da gravação. Alguns finalizam esses sistemas - por exemplo, não salvam versões se nada no objeto foi alterado.

Nossos usuários, após vasculharem a análise de seu trabalho, incluindo o uso de versão, começaram a reescrever documentos com mais frequência. Bem, apenas por precaução.

Ficamos chateados porque poderia perder um dos instrumentos de influência e proteção de seus interesses. Mas a mente do programador sugeriu uma solução - deixe que eles se reescrevam o quanto quiserem, analisaremos e analisaremos as versões para mudanças significativas.

Contadores, por exemplo, são pessoas astutas, mas têm medo de estragar a contabilidade - se sobrescrevem um objeto, mudam alguns adereços insignificantes, como um comentário. Formalmente, a versão é nova, mesmo se filtrada pela presença de alterações.

Adicionamos uma entidade como ver significado. Eles simplesmente listaram as propriedades dos objetos, cuja mudança, provavelmente, é um reflexo normal do trabalho de uma pessoa, e não um BID. Havia várias visualizações no mesmo tipo de objeto. Por exemplo, alterar um item no envio é uma grande alteração. Alterar a conta não é tão sério, mas ainda é um trabalho. Alterar a hora de um documento em uma data - não, infelizmente, apenas travessuras infantis.

Então, temos estatísticas de mudanças em termos de significado. Os usuários, é claro, se atrapalharam e começaram novamente o DDoS'it - alteram um atributo importante, em um minuto ou um dia. Ingênuo.

Afinal, temos a oportunidade de comparar versões não sequencialmente, mas, por exemplo, a primeira e a última, e ignorar alterações intermediárias. Quando o trimestre é fechado, o documento, com uma alta probabilidade, já está no estado de destino e você pode compará-lo com segurança com a versão mais recente na data de criação.

Automação de Correlação e KPI

Muitos programadores, seus superiores e diretores estão preocupados com o impacto da automação nos negócios. Existem custos para programadores, projetos concluídos e tarefas resolvidas. E existem KPIs de pessoas, departamentos, direções e seus líderes.

Supõe-se que a automação deve ser benéfica ou, como se costuma dizer em piadas, "benefício". Mas o que realmente acontece geralmente não é conhecido.

Com base no exposto, fica claro que tínhamos muitos números sobre automação. E havia departamentos de KPI que solicitaram essa automação. Algo foi considerado automático no sistema - por exemplo, vendas. Algo foi considerado manualmente, no Excel ou em outro lugar. Mas havia todos os KPIs - eles acabaram de introduzir algum tipo de sistema de motivação.

Nós, como verdadeiros programadores, automatizamos a contabilidade de todos os KPIs. Aqueles que não puderam ser calculados de acordo com o sistema, apenas baixados do Excel. Temos todos os números que caracterizam o trabalho dos funcionários e departamentos da empresa.

Adicionamos a nós mesmos mais um indicador - o número de funcionários no departamento. Só porque existe esse estereótipo - a automação pode muito bem reduzir o número de pessoal necessário, especialmente manutenção, como contabilidade ou economistas.

Com KPI e custos de automação, é muito fácil calcular a correlação, porque todos os dados são armazenados com referência a datas. Por exemplo, concluímos um projeto de automação no valor de 200 tr. em janeiro - o KPI da respectiva unidade deve mudar. Não imediatamente, mas, digamos, em fevereiro, março ou mesmo junho. Mas deve. Caso contrário, qual é o objetivo?

Curiosamente, houve uma correlação. Por exemplo, no trabalho de compras, realizamos um projeto de automação de TOC e seus KPIs aumentaram. Mesmo as vendas cresceram desde eles eram o objetivo da automação de compras, no final.

Mas havia exemplos da falta de correlação. Por exemplo, a implementação do CRM não trouxe nada. Criar um site, em vez do anterior, não trouxe nenhum efeito.

Toda a automação da contabilidade trouxe apenas um efeito negativo, especialmente no tamanho de sua equipe, apesar de todos os nossos esforços para conter esse câncer da empresa.

Mas a automação dos economistas de contabilidade teve um efeito positivo - perdemos dois funcionários. Eles não foram demitidos - eles mesmos foram embora, por seus próprios motivos. Mas sugerimos - não vamos pegar novos ainda, ver como vai, automatizamos muito lá. O diretor concordou e tudo deu certo.

Após a correlação calculada, o gerenciamento começou a olhar de maneira diferente para a automação. Bem, para programadores, é claro. Especialmente considerando que ninguém nos ordenou que calculássemos essa correlação - essa foi nossa iniciativa.

É verdade que o diretor foi substituído e tudo teve que começar desde o início. Porém, cerca de seis meses depois, o novo diretor também apreciou o cálculo da correlação.