Base Militar ou TI?

Você sabe onde você trabalha? Imagino que sim. Você sabe em que empresa Trabalha? Imagino que sim. Você percebe a diferença de uma base militar para o seu setor de TI? talvez a resposta seja não. Não é culpa sua, nem tudo a gente muda, querendo ou não certas coisas não valem a pena serem mudadas.

Por que não valeria a pena mudar algo? Quantas vidas você tem? Uma só. Certas coisas não mudam, mas por que continuar pensando na caixa? É isso mesmo, você deve estar pensando dentro da caixa.


Pensando dentro da Caixa

Você não deve seguir as coisas como são em sua empresa. Esse pensamento vai colocar você centro de um caixa, essas rédeas mentais travam a evolução da organização e a melhoria do processo e dos produtos da empresa.



Para inovar você precisa esquecer o que aprendeu, esqueça as regras, o cavalo só é livre e está sem rédeas. Como que você consegue se sentir bem com esse tipo de modelo? Só existe uma resposta se você falar que sim a resposta é você gosta de sofrer amigo. Mas nem todas as pessoas tem essa vocação pra ser comandados, coordenados.

Como um profissional de TI você tem a obrigação de pensar, como você pode ser tão inteligente para resolver problemas de software e ao mesmo tempo não conseguir resolver os problemas de processo que você tem.

Calma não estou lhe culpado, pois a culpa muitas vezes é do Gerente. Sim, por que vocês sabem como que alguns gerentes rodam os projetos de desenvolvimento de software, não? Bem, o nirvana deles seria ter um instrumento como esse.


Ferramenta de Gestão

Como ainda não é possível esse tipo de sofisticação gerencial os gerentes ruins apelam para um método militar chamado de Comando e Controle. Sim isso é muito utilizado pelos gerentes de desenvolvimento de software, as vezes tais diretivas vem do dono da empresa.

O Gerente Comandante só existe por que existe o "Dono" de empresa General. Tal anomalia não é exclusiva de empresas que não são de software. Bom caso esteja curioso podes ler o artigo da Wikipedia sobre C2, percebes que isso não está associado a TI e sim a militarismo.

Vamos começar com palavras chaves do método de Gerenciamento Comando e Controle:
  • Comando
  • Controle
  • Autoridade
  • Direção
  • Comandante
  • Hierarquia
  • Unidade (Grupo de Desenvolvimento)
Neste modelo o planejamento é feito pelo Comandante e os comandados não planejam, eles acatam as missões(Atividades) normalmente o comandante não esta preocupado como eles vão atingir a missão(artefato/conclusão) e nem se eles vão morrer(sair do projeto) por que ele enxerga os soldados(pessoas) como recursos, se um sair outro entra.

Neste modelo existe um monopólio de informações, só o comandante(gerente) tem a big picture e ele não passa todos os detalhes pra todos as os soldados(desenvolvedores), neste modelo o foco em máquinas de guerra(ferramentas) é alto e os soldados(grupo) não pode escolher as armas que utiliza(ferramentas).

Ainda é possível que você não esteja em um modelo 100% comando e controle mas isso não muda o fato de que ele existe e de que você pode estar inserido nele, aceitar esse fato está longe de ser a primeira ação para modifica-lo.

Como as pessoas mudam?

Depende da pessoa, mas em geral de forma lenta e vagarosa, quando falamos de organizações estamos falando de mudanças mais lentas ainda. Por que estamos falando de um grupo de pessoas, logo o mal é mais enraizado ainda. Um ano é mais do que suficiente para fazer uma empresa sair da idade da pedra lascada para a os século XV.

Você não deve se contentar com a vagarosamente da evolução da sua empresa. Para aprender as vezes as pessoas tem que quebrar a cara, toda ação por mais que fique sem resultados na hora fica no sub-consciente e um dia isso leva a uma mudança. Algumas empresas estão mais preparadas para as mudanças, algumas conseguem evoluir e se adaptar mais rápido e são essas empresas que vão ser as lideres de mercado.

Voltando ao C2...

Bem voltando ao método de gerenciamento Comando e Controle, eu não pode deixar de dizer que neste método os soldados(desenvolvedores) tem mais medo do comandante(gerente) do que de errar. Isso é um fator de imposição brutal a evolução. Uma rebelião sempre cai bem nesses cenários. Se o Comandante(Gerente) não confia em sua tropa(grupo) ele deveria trocar de grupo, logo o grupo não se impõe, por que eles não tem a noção de colaboração, eles não tem a noção da liberdade e com isso a empresa perde, perde muito.

Lição Básica: As pessoas não gostam disso

No Geral as pessoas não gostam de serem tratadas desta forma. Isso não é a maneira correta de se trabalhar, isso promove o individualismo, os culpados, o atritar, as desculpas e finalmente o fracasso.

Algum vez em sua vida meu amigo gerente comandante você perguntou para as pessoas se elas gostam desse método? Se se sentem bem com isso? Por que ninguém reclamou isso não faz com que o problema não exista.

E Se o Comandante não vê o problema?

Não poderia ser mais natural, como que alguem que não está envolvido no processo de desenvolvimento de software poderia enxergar os problemas do grupo? Quantas horas por semana ele passar na sala do grupo? Quantas sessões de retrospectivas ele já fez?

Seria milagre se ele soubesse dos problemas, como medida de praxe o Comandante ignora o soldado que quer lhe dar Feedback, sim o comandante tem medo do feedback e ainda mais em publico.

O desenvolvimento vira um jogo de gato e rato. Sendo que os desenvolvedores tentam fugir das porradas do gato e assim é muito difícil de ver o que funciona e o que não funciona bem.

Quem está melhor posição não decide!

O Comandante(Gerente) é inebriado pelo poder; Logo ele não pode permitir que as decisões sejam feitas, quem esta executando(o desenvolvedor) tem mais informações e esta em posição mais correta de tomar certas decisões do que o comandante(gerente) mas ai o que o comandante faz? Burrocratiza o processo passando toda e qualquer decisão significativa por ele.

Os soldados devem ser obedientes, as ordens, aos planos, ao sistema. Você não precisa aplicar esse método com desenvolvedores por que é muito fácil convence-los do que você quer fazer, para isso basta você fazer com que eles se sintam parte do projeto, faça com que eles se sintam donos da solução, assim você estará gerenciando pela liderança e os seus colaboradores poderão se tornar um equipe.

Popular posts from this blog

Kafka Streams with Java 15

Rust and Java Interoperability

HMAC in Java