Sugadores de sangue. Classificação do Programador

Quem são os líderes e por que eles são necessários? Qual é a utilidade deles na vida? O que eles fazem? O que eles deveriam fazer?

Por um lado, o líder é tradicionalmente entendido como aquele que gerencia - faz planos, dá instruções, controla o tempo, grita mais alto, toma decisões e é responsável por eles.

Por outro lado, existe uma opinião de que o chefe deve lidar apenas com o desenvolvimento da unidade confiada, sem participar da gestão operacional.

Por outro lado, existem organizações de governo autônomo e turquesa, que na prática provaram que uma entidade como líder não é necessária - é apenas um conjunto de responsabilidades, papéis e pontos de controle que são facilmente distribuídos entre pessoas diferentes.

Então, quem é ele, esse líder, e por que ele é necessário? Um gerente precisa de uma empresa ou precisa de um líder como fonte de renda? Talvez ele justifique sua existência, porque o resultado vale a pena - a renda dos gerentes geralmente é incomparavelmente maior que a renda dos funcionários comuns.

Eu uso um modelo especial para avaliar gerentes, com o qual sugiro que você se familiarize.

Modelo


O modelo é simples de desonrar, mas geralmente é compreensível apenas para programadores. Mas vocês são programadores e tudo ficará claro para você.

Então, imagine uma empresa que automatizou sua contabilidade em um determinado sistema de informação. E ao lado deste sistema está um programador, apenas um. Ele e o chefe do departamento de TI, o codificador e o arquiteto - tudo em um. A situação é bastante comum para pequenas e, às vezes, para grandes empresas - eu, por algum tempo, fui o único programador na empresa.

Então, imagine agora que um programador é o chefe de um departamento e um sistema de informação é, de fato, seu departamento, incluindo pessoal, equipamento, processos, etc. E o departamento, o serviço, o departamento e toda a empresa - este é um sistema. E informação - é também um sistema.

O programador é livre para tratar seu sistema de maneiras diferentes - para desenvolver, manter, excluir, interromper, reduzir ou aumentar a produtividade, substituir por outro, escrever ou excluir documentos, controlar saldos, etc.

O chefe é livre para fazer o mesmo com seu sistema (departamento) - desenvolver, acompanhar, trabalhar como executor, interferir, ajudar, dispersar, substituir pessoal etc.

O modelo é claro: o relacionamento gerente / departamento é o mesmo que o programador / sistema de informação.

Agora vamos olhar para os líderes através do prisma deste modelo.

Slicker


O tipo mais primitivo de programador é aquele que não faz absolutamente nada, mas de alguma forma consegue não ficar sem trabalho. Eu pessoalmente vi isso - ele foi levado para mudar do soft starter integrado 1C 7.7 para 1C 8 e não usou o pé, nem no primeiro nem no segundo, mas se estendeu por um ano - apenas devido ao fato de estar correndo para a Internet para configurar a Internet a tempo, ICQ e baixar músicas de torrents.

Outro exemplo é uma garota que não sabia fazer nada sozinha, mas tinha uma extensa rede de contatos entre os programadores e era, como se costuma dizer, bonita e encantadora, de modo que os caras ajudaram com prazer a resolver completamente suas tarefas. Além disso, os caras trabalhavam em outras empresas.

Você entende que o sistema com esse programador vive sua própria vida, praticamente não depende absolutamente dele, e não há alterações visíveis nele antes de sair.

Entre os líderes desses caras também está cheio - que eles são, que não são. Às vezes, eles são chamados de generais de casamentos, mas é nesses casos em que o chefe pode desempenhar pelo menos funções representativas, por exemplo, para se sentar bem em uma reunião com os clientes.

Esses líderes amam todos os tipos de eventos, reuniões - especialmente aqueles onde há muita gente e não é necessário abrir a boca. Às vezes, são tão infelizes que, se ainda recebem a tarefa da liderança, não conseguem delegá-la normalmente, porque o sistema as ignora completamente, a menos que alguém tenha pena e ajude.

Não faz sentido falar sobre o papel de um programador e de um líder no sistema e seu desenvolvimento, porque não há papel nem desenvolvimento. Este é o caso mais miserável.

Um parente


Esse é um tipo separado de furtividade, com a diferença de que os parentes não precisam fazer muito para permanecer no local. Eles foram trazidos para lá com uma pata desgrenhada e estão sentados. Quem fica o dia todo, quem está antes do jantar, quem está depois do jantar, quem está em casa.

Os familiares já têm um impacto no sistema, pois eles têm medo - você nunca sabe que tipo de rédeas cairá na cauda, ​​pode perder o emprego.

Mas, de fato, eles geralmente não usam essa influência. Seja um elemento do sistema, ou seja, eles não querem executar nenhuma função nele, porque responsabilidades e obrigações aparecerão, pelo menos você precisa trabalhar. Eles não podem desenvolver o sistema, porque isso requer pelo menos algumas competências e uma compreensão do que está acontecendo.

Obviamente, há exceções quando um parente não se comporta como um parente, mas então o excluímos solenemente dessa categoria. Às vezes, os laços familiares até ajudam, tornando uma pessoa mais responsável e eficaz, por exemplo, em uma empresa familiar. A eficiência aumenta porque um parente não tem medo de demissão.

Mas, em geral, na maioria das vezes, esse programador não desempenha um papel na vida do sistema e é o principal na vida do departamento.

Parafuso


Acontece que um programador se transforma em operador. Não é frequente, mas acontece.

Somente realiza trocas, carregamentos e downloads de arquivos, faz backups, entra em documentos, gera relatórios, faz algum tipo de análise de dados, etc. De fato, apenas faz o trabalho do usuário. Na minha vida, vi isso quando, lentamente, pouco a pouco, o programador se transformou em contador.

Se ativado, ou seja, mudou-se para outro departamento e para outra posição - e o inferno com ele, uma transformação tão normal. Mas acontece que funciona como um operador e é chamado de programador. Quem é ele então, no nosso modelo? Apenas um elemento do sistema que ele deveria gerenciar. Quem, então, gerencia e desenvolve o sistema? Ninguém, até que outro chegue e perceba que algo está errado aqui.

Isso acontece o tempo todo com os líderes, especialmente com o nível mais baixo, como líderes de equipe, gerentes de site, administradores de sistemas, etc. Sua posição é uma formalidade, eles não gerenciam nada e não desenvolvem nada, trabalham como todo mundo, apenas têm um pouco mais de responsabilidades, como ir à RAM e fornecer folhas de ponto.

Nem um nem os outros líderes têm influência em seu sistema. Não gerencie, não desenvolva, não responda. O sistema não depende deles.

Polvo


Mas este é um caso completamente diferente. Esse programador, embora não esteja envolvido na programação, é um elemento do sistema de importância única. Por exemplo, ele sozinho sabe como calcular o custo e ajustá-lo de acordo com a estratégia de tributação.

De fato, este é o mesmo operador, apenas mais avançado, percebendo seu valor e vendendo-o com sucesso. Esse programador afirma que somente ele sabe como fazer ajustes para registrar entradas, para que "nada voe". Somente ele pode corrigir o sinal de menos nas costas, para que o subconto não se disperse. Você pode continuar a lista você mesmo.

Esse programador é parte integrante do sistema, seu gargalo, um apêndice que não pode ser cortado. Sem ele, haverá uma crise, e todos, inclusive ele próprio, entenderão isso - tudo depende disso. Ele toma decisões sobre a execução de operações complexas, sobre a resolução de problemas complexos, como erros ao baixar relatórios, etc.

Existem mais gerenciadores desse tipo do que programadores. Cria artificial e intencionalmente condições sob as quais o sistema não pode existir sem elas nem por um dia (isso pode ser visto claramente quando eles saem de férias). Eles coordenam tudo, verificam tudo, especialmente o que é fornecido "no andar de cima", tomam decisões em cada instância do processo (por exemplo, o pedido de um cliente), participam de todas as reuniões.

Quando lhes dizem que precisam ser delegados, eles se referem ao emprego - simplesmente não há tempo para sentar e pensar, escrever instruções e entregar as coisas. Em geral, essa é sua desculpa favorita - o emprego que eles criaram artificialmente. E mais multitarefa.

A situação às vezes parece ridícula, especialmente quando um gerente mais alto muda e começa a perguntar ao nosso elemento-chave - o que você está fazendo? E o mais importante - por quê? A resposta geralmente é "tão aceita" ou, se ele conseguisse fixar sua indispensabilidade nos padrões da empresa, "assim deveria ser". Quem aceitou, quando aceito, por que aceitou - ou não há resposta ou não pode ser pronunciada, porque "Eu pensei nessa porcaria sem sentido" parece tão.

Tanto o programador quanto o gerente gradualmente começam a acreditar em sua exclusividade. Às vezes, até começam a sentir pena de si mesmas e exigem piedade dos outros, ou até induzem essa piedade dos mais altos a aumentar sua renda.

Ocorre que um programador ou gerente chave faz alterações no sistema, ou seja, age favoravelmente nela. Mas ele quase sempre não se concentra em se livrar do sistema. Por exemplo, um programador pode escrever um processamento interessante para a formação de pacotes de documentos, o que salva as pessoas do trabalho de rotina, mas apenas o programador usará esse processamento. Se eles pedirem que ele ensine outra pessoa, ele encontrará várias desculpas, como "sim, para explicar mais, deixe-me fazer melhor".

Os líderes fazem o mesmo, aprimorando o sistema por si mesmos. Por exemplo, houve um diretor de vendas que eliminou uma condição: me dê uma porcentagem das vendas de todo o departamento, e distribuirei o prêmio como quiser. Você entende que, para o pessoal de vendas, esse se torna o principal motivo para trabalhar para esse líder - não "vender mais", mas "gostar mais". O gerente não poderá explicar o algoritmo de distribuição, porque esse algoritmo não existe.

Como resultado, para o programador, para o gerente, o resultado é um: o sistema não pode existir nem se desenvolver sem ele.

Luva


Existem programadores que alteram sistemas como luvas. Eles realmente não sabem programar, lembram a implementação, resolvem pequenos e grandes problemas dos usuários e beneficiam a empresa.

Em qualquer situação de crise, quando há mais mal do que bem do sistema, eles dizem: é hora de mudar para outro sistema.

Felizmente, agora não há problemas com isso, principalmente devido à mistura de nichos na linha de produtos, o mesmo 1C. Você pode usar o UT 10.3 para alternar para o soft starter, depois para o KA 1, depois para o KP 3.0, depois para o KA 2, depois para o ERP, cuspir em tudo e implementar o UNF, então algum tipo de perversão como o USHP (se o setor permitir), surpreendentemente, retorne ao SCP. Cada transição tem no mínimo um ano. Conte a si mesmo o quanto você pode sustentar essa estratégia. Você conheceu esses programadores? Eu conheci.

Como é um líder semelhante? Ele muda incessantemente a metodologia, a abordagem básica da administração. Hoje ele define um plano para um mês, amanhã ele define um plano para um ano, depois muda para Agile, depois para TOS, depois para Lean, depois para 4-4-5, depois para orçamento, depois para um modelo sem orçamento. Isso não é ruim se o chefe conhece todas essas técnicas, pelo menos você pode praticar a aplicação delas.

Mas geralmente tudo é mais prosaico - esse líder resolve todos os problemas através da reestruturação. Ele cria dois de um departamento, depois dez, depois outro, depois recruta um novo departamento de novas pessoas, depois cancela e os coloca nos departamentos antigos, inventa novas postagens e escreve instruções, processos e padrões ou de uma maneira muito infantil - muda as divisões para divisões, divisões para departamentos, departamentos para equipes, equipes para distritos, etc.

A essência da abordagem, tanto para o programador quanto para o gerente, é a mesma: embora existam mudanças em larga escala, ninguém chegará ao fundo dos resultados. E se você chegar ao fundo, sempre poderá otmazatsya: estamos em plena mudança, agora é simplesmente impossível responder sua pergunta, voltar em um mês ou procurar a resposta você mesmo.

O impacto no sistema é aterrador em escala, mas sem significado em seu resultado e eficácia. Estas são apenas mudanças por uma questão de mudança, apenas em escala colossal.

O que é especialmente ruim é que outras pessoas se acostumam a esse comportamento e gradualmente esquecem que essas mudanças tiveram um começo e deve haver um fim. Eles esquecem a cadeia de mudanças, qual sistema ou metodologia mudou e por quê. Como resultado, depois de um tempo, você pode simplesmente repetir toda a gama de alterações novamente, e ninguém notará. Na prática, observei essa imagem e calculei a frequência do ciclo - 4 anos.

Obviamente, não é necessário falar sobre nenhum benefício para a empresa de um programador e gerente desse tipo.

Plyushkin


Plyushkin é o personagem de “Dead Souls”, de Gogol, um pequeno mercenário ganancioso que arrastava e guardava tudo o que encontra, até os mínimos detalhes.

Esses programadores da Plyushkin amam todos os tipos de repositórios de soluções e códigos, como o git, mas são usados ​​para outros fins. Em vez de procurar uma solução para o problema, eles baixam estupidamente tudo o que tem capacidade ou dinheiro suficiente em disco (para soluções pagas). Eles são armazenados em pastas organizadas, classificadas; às vezes, tentam incorporá-las ao sistema para mostrar aos usuários ou ao diretor, se apresentando como se fossem suas e justificando sua existência.

Eles mesmos realmente não sabem fazer nada, então usar as pequenas coisas de outra pessoa para eles é a única maneira de sobreviver na profissão. Para mudanças sérias, eles não têm força, competência e coragem.

Você pode reconhecer esses Plyushkins observando a interface do sistema deles - ele estará cheio de ícones de vários complementos, cujo significado não ficará claro para ninguém. Todos os tipos de painéis de funções, duplicação da árvore de metadados, classificação universal de tabelas, gerenciamento de trocas em um banco de dados que não utiliza trocas, um monte de relatórios, mesmo para outros sistemas, etc.

Os executivos da Plyushkina se comportam da mesma forma. Eles lêem blogs, artigos, todos os tipos de grupos nas redes sociais sobre como fazer alterações úteis com pouco esforço. Devido à natureza não sistemática na escolha dos métodos, ao entendimento dos problemas de seu departamento e da própria implementação, eles geralmente ficam sem sentido.

Por exemplo, Plyushkin assistirá na TV que o novo jovem governador está realizando reuniões em pé, dizendo que isso aumenta a eficiência - e é isso, aproveite, subordinados. Anteriormente, sentados em uma estupa, eles empurravam a água, agora você estará em pé. Ou ele lerá outra prática recomendada de que todos os funcionários devem escrever um relatório diário manualmente, eles dizem que não se trata de copiar e colar no computador, mas de palavras reais e sinceras - e aqui, ensaios diários, menos uma hora do horário de trabalho.

Esses programadores e gerentes têm um impacto menor, e principalmente prejudicial, no sistema. encha-o com lixo e barulho descontrolado.

Acompanhante


Existem programadores que quase sempre, para a solução de tarefas mais ou menos complexas, são chamados de terceirizados. O projeto de introdução do sistema, lançamento de um novo subsistema, integração com o site, desenvolvimento de um novo documento, adição de adereços - um programador externo é necessário para tudo.

Existem os mesmos líderes, eu pessoalmente vi. Precisa de um sistema de motivação? Otimização de processos de negócios? Desenvolvimento de estratégia? Análise de sistema de gestão? Há apenas uma resposta - estamos procurando especialistas externos.

O impacto no sistema, ao que parece, é, mas quase sempre torto e prejudicial, porque o consultor trabalha com apenas uma parte do mosaico.

Por exemplo, cria um sistema de motivação para processos tortos. Ou escreve uma estratégia, sem considerar a motivação para sua implementação. Ou, nosso nativo - faz a automação do instantâneo do processo, que perde relevância um ano antes do final do projeto, embora isso não seja importante, porque metas e motivação também não são levadas em consideração.

Como resultado, é sempre torto, com um viés em alguma direção. Tanto a cabeça quanto o programador. Mas o principal é que o papel deles nesse processo de desenvolvimento é zero.

Tolerado


Este é o tipo mais comum de programador - aqueles que fazem tudo o que lhes dizem. Consequentemente, eles fazem mudanças sem sentido no sistema, dando-o, peça por peça, para a realização das ambições doentias de alguém. Esta é a maioria de nós, o que posso dizer.

E esses líderes - a granel. São todos aqueles que admitem especialistas externos em automação, implementadores da ISO 9001, burocratas internos de todos os tipos, que precisam fornecer vários relatórios, pedaços de papel, passar por milhões de aprovações, aprender músicas e preparar cenas para eventos corporativos, etc. Em geral, quem abriu parte de seu sistema a um ataque externo, como uma varanda para pessoas sem-teto, e agora não sabe como expulsá-las de lá, para não sentir o cheiro de tudo.

Como resultado, o sistema de informações e o sistema de gerenciamento de departamento ou empresa tornam-se como Frankenstein inibido, incapazes de dar um passo.

Essas pessoas são pragas, porque sob o disfarce de "e eu Che, eles me disseram para" destruir seus sistemas.

Normal


Existem programadores normais no mundo que decidem por si mesmos o que fazer com o sistema, conhecendo os objetivos que enfrentam. Se as metas são definidas curvas, elas não são tímidas e as ajustam, e todos conseguem concordar.

Existem gerentes normais que estão constantemente empenhados em melhorar a eficiência de seu sistema, e eles fazem isso de maneira cuidadosa, consistente e profissional.

Nem um nem outro entra no sistema, exceto em casos de emergência.

Nenhum deles vinculou o sistema a si próprio, e a qualquer momento eles podem sair, e o sistema continuará funcionando, embora pare de se desenvolver.

O único problema é que nem um nem o outro existe.

Questão chave


Há conhecimento, experiência, competências espalhadas por diferentes pessoas que nunca conseguem concordar. Alguns são capazes de criar sistemas de motivação, outros são estratégia, terceiros objetivos e indicadores, quarta automação, quinto sistema de gerenciamento. Mas eles nunca trabalham juntos ao mesmo tempo.

O desenvolvimento é sempre consistente, você pode vê-lo em projetos que às vezes são concebidos nas empresas.

Por exemplo, um sistema de motivação baseado nos processos atuais está sendo introduzido. Se for visível que os processos estão torcidos, isso será ignorado para não exceder a escala e o orçamento do projeto.

Ou a otimização dos processos é iniciada, mas a automação não a acompanha, resultando em um terrível híbrido das versões nova e antiga de ambas.

Eu já falei sobre automação muitas vezes, especialmente externa, através dos esforços de terceirizados. Eles simplesmente fazem um elenco automatizado de processos sem sentido, motivação desmotivada, objetivos incomensuráveis ​​e sem um sistema de gerenciamento em geral.

Corridas sem fim são obtidas - cada parte do sistema se alterna, o que só agrava o estado de toda a população.

Solução


A solução é simples de desonrar - para integrar o desenvolvimento. Altere todas as partes do sistema ao mesmo tempo para que não haja desequilíbrio entre elas.

Como o principal problema é o desequilíbrio, a incompatibilidade de partes do sistema entre si. Embora pareça que o problema esteja em uma parte específica.

Por exemplo, muitas vezes eles derrubam a automação - é o culpado por tudo.

Nós, programadores, geralmente culpamos os processos, eles dizem que há uma bagunça e somos forçados a automatizá-la.

Os implementadores de sistemas de motivação reclamam de processos, indicadores não automatizados e falta de objetivos. Etc.

Mas o problema real é o desequilíbrio que cria a corrida do desenvolvimento, e a empresa nunca obtém os benefícios de todas as partes do sistema de negócios.

Implementa o ERP e aproveita 10% das possibilidades, porque não há processos para o resto. Ele implementa um sistema de classificação e não o utiliza, porque o cálculo dos indicadores não é automatizado. Ele escreve objetivos estratégicos, mas nunca os alcançará, porque os processos não são reorganizados de acordo.

Há apenas um ponto: cada parte, por si só, não é ruim, mas todas juntas não funcionam, porque estão em desequilíbrio.

Voltar para executivos e programadores


O modelo que te disse não é apenas para rir. Ela é para entender a situação em um local específico, em uma empresa específica, com um líder específico.

Eu escolhi a analogia com um programador por uma razão simples - eu também sou programador e vocês são programadores. Certamente, se você explicar o papel e a influência das líderes para as meninas do RH, terá que criar um modelo diferente. Porque o pensamento que quero transmitir é um, mas pode haver muitos modelos - eles são apenas para facilitar a compreensão.

Mas, como me parece, os líderes são atavismo. Os negócios não precisam deles. Eles são como um mau hábito que você odeia, mas tem medo de desistir. Os líderes criam a ilusão de suporte, estabilidade e gerenciamento de negócios. Eles, como, “assumem responsabilidade”, “tomam decisões”, “coordenam” e similares, palavras sem sentido.

Todas essas palavras foram inventadas pelos próprios líderes. Tente, por diversão, convencer o líder de que ele não é necessário. Ele diz a você tantas coisas quão ruim seria sem ele que seus ouvidos seriam puxados. Mas ouvir o próprio chefe sobre o motivo pelo qual a empresa precisa dele é o mesmo que pedir à pessoa condenada a levar um tiro, por que ele deveria viver.

Espero que o modelo de comparação de um gerente com um programador o ajude, durante conversas semelhantes e semelhantes, a não esquecer por que um gerente é necessário.

Onde colocá-lo?


Não é necessário colocar uma pessoa, mas o modelo geralmente aceito de um líder - "um grande chefe com um grande salário". De fato, aqueles que querem se tornar um líder estão realmente se esforçando para isso?

O modelo de Belbin dá uma boa resposta. Um líder comum é uma composição indefinida de responsabilidades pouco claras, que você só precisa classificar através das funções e selecionar um trabalho adequado para uma pessoa em particular.

Você pode coordenar as ações das pessoas online? Ok, seja o coordenador.

Você pode inspirar, apoiar, levar as coisas adiante? Ok, seja um motivador.

Você pode terminar os projetos em pouco tempo? Ok, seja um finalizador.

Você tem uma visão, sabe para onde ir, pode oferecer as idéias certas? Ok, seja um gerador.

Você pode analisar, ter em mente muitos parâmetros do sistema e entender suas vulnerabilidades? Ok, seja analista.

Todos esses papéis não são liderança. São apenas papéis, esse trabalho.

Se você diz às pessoas o que fazer, isso não significa que você está no comando. O despachante também diz aos motoristas de táxi para onde ir. Ele não fala, ele falou. Ele foi substituído pelo sistema.

Se você sabe como inspirar pessoas, isso não significa que você está no comando. Alguém só precisa assistir ao filme certo para se inspirar, e você fode com ele não desistiu de sua motivação. E alguém em casa ficará tão inspirado em casa que ela não parecerá suficiente.

Se expandirmos a "liderança" tradicional nas prateleiras de papéis e competências, nada restará dela. Então, por que precisamos de um líder assim? Além disso, com o layout, verifica-se que ele não pode realmente desempenhar nenhum dos papéis.

E o rei está nu, como a história dizia.

Source: https://habr.com/ru/post/pt435168/


All Articles