Como posso mudar a cultura desleixada da empresa? [fechadas]

Às vezes, quando tenho um problema que precisa ser resolvido, acho que a maneira mais fácil de resolvê-lo é escrevendo um pequeno programa como uma ferramenta pessoal. Eu não o deixo super utilizável ou robusto, pois sou o único a usá-lo e não tenho tempo para refiná-lo e testá-lo completamente.

Então, um colega de trabalho vê o programa e pede, porque ele encontrou o mesmo problema e a ferramenta pode ajudar. Dou a ele o aviso de isenção de responsabilidade "Não é bonito, mas vai dar certo" e deixo que ele o tenha.

A próxima coisa que sei é que meu superior está me ligando, dizendo que ele está tentando fazer com que o software funcione no computador de um cliente, mas está mostrando uma mensagem de erro X. WTF ?? Esse software não está pronto para lançamento, nem me disseram que precisava estar pronto para lançamento. Mas, por alguma razão, meu superior achou que era bom o suficiente e o liberou sem informar o desenvolvedor original.

Agora, esse problema específico é fácil de corrigir com a MessageBox.Show("DO NOT GIVE TO CLIENTS!");. No entanto, o problema é indicativo de um problema muito mais profundo: a cultura da nossa empresa é desleixada. Software desleixado está OK e processos desleixados estão OK. Não se preocupe com o futuro - faça um esforço suficiente para fazê-lo mal funcionar agora, coloque os binários em um arquivo .zip e envie-o. Bom o suficiente para o trabalho do governo.

Esta é uma pequena empresa com 10 funcionários em período integral, está crescendo e existe há algum tempo. Não me interpretem mal; Adoro trabalhar aqui e amo a empresa. Não me diga para correr; Quero fazer parte da melhoria da empresa. Como você começa a trazer boas mudanças para esse tipo de cultura?

A única maneira de mudar é fazer com que todos vejam as desvantagens de uma cultura desleixada e, talvez mais importante, tenham o apoio da gerência para corrigi-la. Na realidade, porém, isso não acontece e você não poderá alterá-lo. Essa pode não ser a resposta que você esperava ouvir, mas depois de cinco anos tentando ou falhando em vários empregos para mudar a cultura desleixada, posso dizer com alguma autoridade que geralmente não vale a pena fazer o esforço.

O primeiro passo seria descobrir se mais alguém conhece ou se importa com a cultura desleixada; se você é a única pessoa que vê algum problema, seus esforços são em vão.

Pode ser necessário conversar com um colega de trabalho e um chefe e explicar que você era um protótipo e não estava pronto para os clientes usarem. Se eles quisessem que estivesse pronto para uso dos clientes, você poderia fazer essas alterações com tempo suficiente, mas não pegue as coisas "rápidas e sujas" e as repasse para os clientes. Só porque algo funciona não faz bem ser a lição a aprender. Embora você tenha renunciado, há algo a ser dito para respeitá-lo, caso contrário, é isso que pode acontecer.

Você não pode consertar estúpido. Se o seu chefe estiver fazendo coisas como você descreve, é improvável que você possa mudar isso. Especialmente se ele não é o proprietário - lembre-se, ele tem pressão vinda de outra direção, e essa direção assina seu cheque de pagamento. O mesmo com seus outros colegas de trabalho. O melhor primeiro curso de ação que você pode tomar é adquirir o hábito de se proteger. Use técnicas como essa caixa de mensagem que você descreve. Guarde todos os emails. Obtenha o máximo que puder na forma escrita. Dessa forma, você não aguenta o peso quando a estupidez atinge. Então, à medida que for promovendo, institua as mudanças que você deseja com as pessoas sob sua supervisão.

Outro dia, um colega me contou a história de uma ferramenta de teste simples para permitir que um engenheiro de um laboratório emita um único comando em um widget e altere uma variável que acompanha o comando. Isso foi escrito há 9 anos e, pela última vez que ele sabia, ainda está em uso hoje. Uma ferramenta que foi escrita em algumas horas com testes mínimos para provar, em laboratório, que algo funciona, foi a base de toda uma ferramenta de teste de laboratório de engenharia. Depois de escrever o código, ele existe. Se faz algo útil e é visto por outras pessoas, as pessoas vão querer. Se for bom no que faz, as pessoas pedirão para fazer o X. Em seguida, você sabe que sua ferramenta simples é um componente significativo.

Acho que a primeira responsabilidade é do desenvolvedor de software garantir que qualquer pessoa que veja o código ou use a ferramenta entenda que é um protótipo ou não um sistema de produção e diga por que é esse o caso. Parece que você fez isso, no entanto, seus colegas de trabalho deixaram de assumir essa responsabilidade. Para resolver isso, eu recomendaria falar com eles, reiterando que este não era um código de produção e foi escrito apenas para facilitar seu trabalho. Se acharem útil, talvez ofereça-se para trabalhar na ferramenta ou apoie outras pessoas que a trabalham para aprimorá-la e torná-la mais adequada para produção.

Quanto ao processo organizacional ou à cultura, espere que demore um pouco. Comece definindo um exemplo. Se você não leu The Pragmatic Programmer , faça isso. Tome nota de dicas como Cuidado com o seu artesanato, Seja um catalisador da mudança (mostre maneiras melhores às pessoas), Não viva com janelas quebradas, Corrija o problema, não a culpa. Parece que você reconhece alguns problemas abordados por essas dicas, então comece a trabalhar e a dar um exemplo aos seus colegas.

Até os tomadores de decisão não controlarem mais as conseqüências do código incorreto e estarem dispostos a pagar / mudar suas formas de solucionar o problema.

Essas são decisões difíceis para empresas pequenas e em crescimento. Eles não sabem onde colocar todos os seus esforços. Existe um risco de tornar o código muito robusto quando as regras de negócios e, às vezes, linhas inteiras de negócios aparecem, mudam e desaparecem durante a noite.

Esforce-se para escrever um bom código. Certifique-se de informar a todos as conseqüências para que eles possam tomar decisões informadas. Se um código incorreto for colocado em produção, fique de olho nele, se puder, e continue sugerindo aprimorá-lo, especialmente se essa parte do negócio se tornar crítica.

Fazer as pessoas esperar pelo que você vê como código minimamente viável parece estar além das expectativas atuais.

Eu apontaria que parte do problema aqui é que você escreveu uma ferramenta rápida e suja em primeiro lugar. Concedido, havia boas razões. Concedido, ele fez o trabalho. Mas descobri que qualquer coisa que resolva um problema cairá na armadilha de uma solução "boa o suficiente", se você começar a distribuí-lo.

Se o seu colega quiser, diga educadamente a ele que não está totalmente funcional e você ficará com as chaves. Você pode executá-lo de vez em quando. Ou adicione a funcionalidade extra, de preferência desde o início do projeto.

Todas as minhas ferramentas rápidas e sujas neste momento vêm de um arquivo esqueleto altamente testado. Isso permite que eu vá rapidamente, me fornece um ponto de partida de trabalho e me esquece de adicionar todas essas arestas contundentes necessárias. Não preciso me preocupar com a biblioteca getopts e suas peculiaridades. Não preciso me lembrar de detalhes sobre gerenciamento de memória quando uso python. Crie o programa para que ele execute uma tarefa simples e apenas uma . Isso facilita o teste se eles estão tentando dobrá-lo de forma.

Por fim, tire proveito da arquitetura de máquinas de estados finitos. Se você conhece todos os estados possíveis, é muito mais fácil garantir que, não importa o que aconteça, o usuário nunca poderá pular as trilhas. Eu tenho um programa que escrevi para seguir esse paradigma. Ele aceita arquivos de entrada arbitrários, que são lidos por byte a byte. Mesmo se o cliente mandasse ler um executável binário, não haveria problemas. Como ele não encontrou nada do que estava procurando, seu buffer interno seria preenchido. Isso faria com que ele fosse limpo, encerrado e relatasse ao usuário que eles precisam que eu olhe para ele.

Bem, a resposta não tem muito a ver com programação, exceto que o software é um bem do qual é difícil julgar facilmente a qualidade.

Talvez você não consiga mudar a cultura, porque as pessoas podem não ter um motivo real para não serem desleixadas, porque as pessoas afetadas pela qualidade do software não têm muito a ver com o processo. Por exemplo, pode ser necessário que seus clientes comprem e usem software para realizar seus trabalhos, mas têm pouca participação pessoal na eficácia desse software, porque eles não serão pessoalmente culpados por seus problemas ou recompensados ​​por suas virtudes (em grande parte porque ninguém realmente sabe se o software concorrente seria melhor). Portanto, você pode precisar atender apenas às solicitações de recursos sem demorar muito , mas não precisa se preocupar muito com a falha. Portanto, todos podem ser bastante desleixados, sem consequências (para quem toma decisões que afetam você).

Não sei se é esse o caso, mas se for difícil você mudar a cultura, já que as pessoas que você está tentando mudar não ficarão melhor se o fizerem.

Se eles ficarem melhores, talvez você tenha mais facilidade, pois é possível convencê-los do porquê. Infelizmente, se não houvesse algum tipo de situação política que tornasse OK a desleixada , provavelmente não seriam desleixadas em primeiro lugar, por isso é provável que seja difícil. Você sempre pode tentar o argumento "algum dia você pode ter um trabalho que exija fazer as coisas da maneira certa" (talvez seja mais diplomático ...)