Os programadores adoram desenhar relatórios de calçados. Se você precisar de um relatório de vendas, fará o despejo de toda a tabela de vendas, com contrapartes, nomenclatura, organizações, contratos, quantidades e quantidades.
Tudo ficaria bem, apenas com a ajuda de um relatório desse tipo é difícil de gerenciar. Analisar - possível se houver muito tempo livre. E quem tem muito tempo livre? O analista tem, por exemplo. Ok, se ele é analista. Afinal, existem análises pelo chamado da alma. Ele tem uma posição, por exemplo, como gerente de vendas, mas ele não quer vender ou não sabe como, mas escolher números em números é uma coisa agradável.
O chefe da hora de escolher o relatório, infelizmente, não. Pelo menos como parte do gerenciamento regular. Ele precisa de informações curtas e abrangentes que respondam a uma pergunta simples: como estão as coisas? Ou de outra maneira: estamos bem?
Como responder a essa pergunta com um calçado? De jeito nenhum. O calçado, por assim dizer, diz à cabeça: você queria informações? Bem, aqui está ela. TUDO! Vamos lá, resolva o problema e procure a resposta para sua pergunta.
Se a cabeça chegar ao programador com sua tarefa, ele tenta "ajudar". Por exemplo, um plano de vendas / relatório de fatos é feito. Bonito, confortável, personalizável. Lá, você pode não apenas comparar o plano com o fato, mas também o fato com o fato por períodos diferentes e, em geral, com qualquer número de tabelas. Qual é o resultado? Outro calçado, só que mais complicado.
Se você chegar ao final do programador novamente, ele dirá: caramba, aprenda a si mesmo, relate e salve a configuração. Filtre os dados, selecione um período para que apenas os dados necessários sejam exibidos. Bem, como opção, servirá. Mas somente se a cabeça souber personalizar. E se você não pode?
Ok, o programador, relutantemente, e rangendo os ossos, fará o relatório ele mesmo. E ele dirá: tudo, engasgue. Claro, ele não diz isso em voz alta, mas vai pensar no assunto. Tudo, a felicidade chegou?
Não. Primeiro, na primeira vez em que ele não configurar, ele precisará executar várias vezes. Ou escreva uma boa tarefa técnica de alta qualidade. E isso, quase sempre, é impossível, porque o líder em terra não sabe de que forma ele precisa de um relatório.
Enquanto o líder está de pé, parece-lhe que basta montar os grupos e ele será capaz de gerenciar o uso do relatório. Depois de receber os agrupamentos, ele desejará um filtro. Depois de receber o filtro, ele entenderá que a classificação é necessária. E assim por diante
Em segundo lugar, um relatório não é suficiente. Afinal, um líder não está interessado apenas em vendas? Além disso, é necessário o movimento do dinheiro. E o trabalho dos funcionários. E pedidos em atraso - tanto para compradores quanto para fornecedores. Isso produzirá vários relatórios e para cada uma ou mais configurações.
Em terceiro lugar, na maioria dos casos, o sistema de informação é um sistema de desktop. Para descobrir como você está, precisa ligar o computador. Você ainda precisa chegar lá. Se o líder é tal que fica sentado em computadores o dia todo, então não há problema. Existem muitos desses líderes?
O gerente deseja assistir a relatórios remotamente via Internet. Desejável - a partir de um smartphone. Isso é muito conveniente - mesmo no almoço, pelo menos no trânsito, pelo menos em uma reunião chata. O programador terá que se preocupar novamente.
Quarto, houve vários relatos. Todo mundo responde a sua própria pergunta. Todo mundo precisa ser aberto e analisado separadamente. Um aberto, o segundo fecha. Máximo - fez uma tela dividida e viu duas de uma vez.
Nos sistemas de desktop, você nem pode examiná-los, como em um smartphone - bem, para que todos os relatórios caiam em um único calçado e você possa rolar os dedos de cima para baixo.
O gerente deseja ver todos os relatórios em uma tela. Este é um desejo humano normal. Mas para o programador, isso é um inferno.
O relatório grande habitual, mesmo configurado e filtrado, fica bem apenas em tela cheia. Se você reduzi-lo pela metade, aparecerão imediatamente barras de rolagem que estragam toda a impressão - mesmo se não houver nada atrás da área visível da tela, a própria mão estenderá a rolagem para baixo ou para os lados para garantir isso.
E se houver três relatórios? Ou quatro? Acontece ass-s. O gerente não tem escolha a não ser visualizar os relatórios tradicionalmente - um por um, em tela cheia.
Mesmo a apresentação de informações na forma de um diagrama não será salva se for exibida, como em 1C, em um documento de tabela. As mesmas barras de rolagem aparecem, é impossível controlar de forma inteligente a escala do gráfico, as emoções estão esquentando.
E qual é o problema? E ela está aí?
É simples e muito simples: o programador adora demais os calçados. Ele foi ensinado dessa maneira, eles pediram um sistema de valores: despejaram tudo o que é e muito mais. E forneça um mecanismo de ajuste elegante.
Essa abordagem é boa para desenvolvedores de soluções in a box, porque elas não têm escolha. Eles não sabem quais informações e de que forma um líder em particular deseja ver, então eles mesmos fazem calçados + ajuste.
Mas programadores em campo, ou seja, para alguns clientes, por algum motivo, seguem cegamente esse paradigma. Eles agem como se fossem desenvolvedores de soluções in a box. E eles fazem todos os sapatos novos.
Amigos são programadores. Eu também sou um programador. Eu também adoro fazer calçados. É simples, interessante e até bonito à sua maneira. Mas os calçados não são adequados para o gerenciamento.
Não estou dizendo que algo está errado com você ou conosco. Apenas proponho resolver um novo problema de engenharia interessante: elaborar um pequeno relatório.
Não um calçado grande em mil linhas, mas um pequeno prato com duas colunas e três linhas. Não é um gráfico robusto que não cabe na tela, mas um minúsculo com três colunas que claramente responde a uma pergunta específica. Não escreva números para que uma pessoa responda a uma pergunta, mas dê uma resposta imediata a uma pergunta - curta, concisa e compreensível.
Isso é incrivelmente interessante. E tudo isso é fácil de algoritmos. O princípio é muito simples - o funil "what if?"
Aqui temos um plano e o fato das vendas - separar tabelas com dados. Traçamos dois relatórios - o plano e o fato das vendas.
Mas e se você os combinar e desenhar imediatamente um plano e um fato em um relatório? Bem, já não é ruim.
Mas e se cairmos em grupos de nomenclatura? Então o relatório será pequeno, pelo menos em altura.
Ok, nós fazemos.
Mas e se você desenhar o mesmo relatório na forma de um diagrama? O histograma usual de duas colunas. O primeiro será o plano, o segundo fato. Você olha e entende imediatamente onde o plano está sendo implementado e onde está a falha.
Mas e se você recontar o plano para o dia atual? Afinal, descartamos todo o plano mensal na primeira coluna, e o fato só o alcançará até o final do mês. Ao longo do mês, olhando para o gráfico, o líder pensará que tudo está ruim. Ou ele terá que descobrir em sua mente que parte do mês já passou. Não, não vamos derivar todo o plano mensal, mas parte dele. No décimo dia - um terço, no décimo quinto - meio, etc. Então o diagrama se tornará mais claro e mais interessante.
Mas e se colorirmos as colunas, dependendo se tudo está bom ou não? Afinal, sabemos se o plano está bem implementado ou não - você só precisa comparar dois números. Deixe a coluna vermelha se tudo estiver ruim. Amarelo - se perigoso. Verde - se for bom.
Mas e se você não exibir colunas para as quais está tudo bem? Por exemplo, se tivermos um gráfico dividido por grupo de itens. Nós produziremos apenas aqueles que são amarelos ou vermelhos. Bem, digamos ao líder que, se não houver coluna, tudo estará bem. Ele entende? Ele precisa de informações para reagir e tomar decisões? Definir tarefas, acentos, em um tapete para causar alguém. Portanto, deixe o sistema falar apenas sobre o que você precisa responder.
Mas e se você remover completamente o gráfico? Já escondemos quase todas as colunas, qual é o objetivo do diagrama, como forma de apresentar informações? Vamos exibir uma pequena placa na qual haverá apenas grupos problemáticos de itens - amarelo e vermelho. Bem, os números, a porcentagem do plano.
Mas e se você não exibir um relatório ao gerente? Por que fazê-lo olhar para algum lugar todos os dias? Vamos fazer o seguinte: se houver algum problema, daremos um sinal a ele. Não nós, mas o sistema que estamos desenvolvendo. Apareceu uma cor amarela ou vermelha - estamos escrevendo uma carta, na vibração ou no SMS, isso não importa. O gerente saberá: se não houver sinais, está tudo bem. Você não pode perder tempo analisando, é melhor apenas trabalhar, fazer algo útil. Claro, a primeira vez que ele ainda entra e assiste - ele não confia em programadores. Você nunca sabe, de repente, o envio de cartas aumentou. Bem, deixe-o tropeçar e se acostume.
Mas e se ele não precisar de informações sobre alguns grupos de nomenclatura? Bem, ele sabe que eles não estão à venda e sempre serão vermelhos ou amarelos. Por que uma pessoa deve ser puxada em vão com sinais desnecessários? Nós limpamos.
Mas e se reportarmos não uma lista de grupos ruins, mas uma linha - tudo é bom ou tudo é ruim? Sabendo a importância de grupos específicos da nomenclatura e o plano geral de vendas, apresentamos pesos e uma função simples que calculará a resposta à pergunta: estamos bem? Vamos dar um coeficiente de 0,1 para grupos desinteressantes, 0,5 ou 0,7 para grupos interessantes, e isso é tudo, temos uma figura grande e bonita. Se o grupo principal vender bem, tudo estará bem conosco.
Mas e se você der ao líder dois números diferentes? Afinal, é claro que tarefas em diferentes grupos podem ser fundamentalmente diferentes. Por exemplo, o grupo principal é um eixo estúpido de vendas. Mas um grupo com uma nova nomenclatura, por exemplo - novo equipamento - não dá um eixo e não pode dar por definição. Lá, uma ou duas vendas por mês são consideradas boas. Você entende? Nem mesmo a quantidade é importante, mas a quantidade. Vendeu uma unidade de equipamento novo - é um feriado! Se você trabalha apenas com quantidades, essa unidade de equipamento novo estará sempre oculta entre a nomenclatura principal. Por que precisamos disso? Que haja dois números: como estão as coisas na linha principal e como estão as coisas nos novos equipamentos. Diferentes critérios de avaliação, escala diferente.
Mas e se colocarmos esses dois números em um? Reescrevemos nossa função com pesos, substituindo os números absolutos pelos relativos. Que a nomenclatura principal seja considerada pela quantidade e a nova pela quantidade. E tudo isso é convertido em porcentagens. Em seguida, os pesos podem ser corrigidos - aumente a nova nomenclatura, pois é importante para nós.
Mas e se considerarmos dois fatores: o plano / fato em um ponto específico e a dinâmica dos últimos dias? Isso acontece. No primeiro dia do mês, eles fizeram uma grande remessa - imediatamente 20% do plano mensal. E todos os nossos gráficos por seis dias mostrarão que está tudo bem. Mas, de fato, nossas vendas tiveram uma participação - e nem uma única remessa por quase uma semana. Do ponto de vista formal, tudo não é ruim, mas não estamos aqui para formalidades? O chefe deve saber que os gerentes estão chutando o trator sem manter a dinâmica de vendas. Não há nada complicado para nós - apenas adicionamos outra variável à função, a dinâmica das vendas, com seu próprio coeficiente de peso. E isso é tudo, beleza.
Mas e se, em nossa função, levarmos em conta não apenas o plano / fato das vendas, mas também o plano / fato do movimento da moeda? Imprimiremos um número infinitamente fino na cabeça, ou uma linha legível por humanos - "tudo é bom", "as vendas são boas, o dinheiro é mais ou menos", "as vendas são de 120%, o dinheiro é de 90%", etc.
E se ...
Isso pode ser continuado indefinidamente. O principal é parar no tempo e deixar o gerente usar a ferramenta, se acostumar com ela, formular feedback. Como programador, entendo que, ao resolver problemas de funil "e se?" existe um desejo irresistível de torná-lo mais simples, melhor, mais informativo e mais útil. Você deve ser capaz de se parar.
O principal é perceber essa tarefa como engenharia. Porque é tal e é. Isso não é beleza ou arcos, é a construção de um sistema de gerenciamento.
O próprio líder não vai lidar com essa tarefa, infelizmente. Ele não conhece todas as possibilidades, todos os dados, todos os relacionamentos. Mas o programador sabe. Mas está calado.
Vamos, saia do seu canto escuro. Você programadores pode fornecer benefícios incríveis para administrar uma empresa. Vocês são engenheiros. Sistema de gerenciamento, automação de gerenciamento é trabalho de engenharia. E a cabeça será sua usuária. Ele gerenciará o uso do seu sistema.