Eu não acho que seja útil especular sobre as motivações de pessoas que não estão adotando algo que você acha que é uma boa prática ou que estão continuando a fazer algo que você considera uma prática ruim. Neste negócio, as pessoas que se enquadram em uma ou ambas as categorias serão muito mais numerosas do que aquelas com as quais você vai encarar, então pare de enlouquecer.
Em vez disso, concentre-se no problema e nas possíveis resoluções.
1. Escreva uma boa documentação você mesmo
Pode não ser realista esperar que todos em sua equipe direcionem seus esforços para as coisas que você considera um problema. Isso é especialmente verdadeiro se você for um novato em relação à equipe. Eu me atreveria a adivinhar que você é, porque se você fosse um membro fundador da equipe, parece muito provável que você já tenha resolvido esse problema desde o início.
Considere, em vez disso, trabalhar com o objetivo de escrever uma boa documentação e convencer as pessoas a usá-la. Por exemplo, se alguém da minha equipe me perguntar onde está o código-fonte do Projeto A ou qual configuração especial o Projeto A precisa, eu o aponto para o Projeto. Uma página wiki.
Se alguém me perguntar como escrever uma nova implementação do Factory F para personalizar uma coisa para o Client C, eu digo a eles que está na página 10 do guia do desenvolvedor.
A maioria dos desenvolvedores odeia fazer perguntas que possam fazer com que eles pareçam não apenas "ler o código" mais do que odiam ler a documentação, portanto, depois de respostas suficientes dessa natureza, eles irão para os documentos primeiro.
2. Prove o valor da sua documentação
Assegure-se de aproveitar todas as oportunidades para indicar onde a documentação está provando seu valor (ou teria, se usado). Tente ser sutil e evite "eu avisei", mas é perfeitamente legítimo dizer coisas como
For future reference, the wiki page of this project has information about the branch of the core code that was created for ongoing support of release 2.1, so in future we can avoid having to do a full regression test if people who are maintaining released versions check the wiki before checking out the code.
ou
I am so glad I wrote down the steps for doing Task T. I don't really care if no one else ever uses it--it's already saved me more time than what I spent writing it.
3. Obtenha o gerenciamento on board
Após alguns incidentes em que a documentação está comprovadamente economizando tempo / dinheiro, você provavelmente notará um "degelo" distinto em relação à documentação. Este é o momento de pressionar o ponto, começando a incluir o tempo de documentação em suas estimativas (embora, honestamente, eu normalmente atualize / crie documentos enquanto processos longos estão sendo executados, como compilações ou check-ins). Especialmente se for uma contratação recente, é possível que isso não seja questionado, mas sim visto como uma nova prática que você está trazendo de um local de trabalho anterior (o que pode ser bem).
Palavra de cautela: A maioria dos chefes não gosta de fazer as pessoas fazerem algo, especialmente coisas que não estão diretamente ligadas a uma tarefa faturável, então não espere que esse suporte esteja no caminho certo. forma de mandato. Em vez disso, é mais provável que você tenha rédeas relativamente livres para escrever mais documentos.4. Incentivar a documentação quando você a vê
Talvez parte do motivo pelo qual as pessoas não escrevem documentos com a frequência necessária é que ninguém as lê. Então, quando você vê algo de que gosta, certifique-se de pelo menos mencionar que estava feliz por estar disponível.
Se sua equipe faz revisões de código, este é um momento em que você pode inserir uma ou duas palavras sutis para incentivar bons comentários.
Thank you for documenting the workaround for bug B in Framework G. I didn't know about that, and I don't think I could have understood what you were doing without that in there.
Se você tem alguém na equipe que realmente está entusiasmado com a documentação, não faz mal cultivar essa pessoa indo almoçar ou tomar café e certificando-se de oferecer uma pequena validação para neutralizar o desânimo eles podem perceber que o resto da equipe não valoriza muito a documentação.
Além disso, não é problema seu, a menos que você esteja em uma posição de liderança ou gerenciamento. Você pode levar um cavalo à água, mas não pode beber. Se não é o seu cavalo, você pode não estar feliz por estar com sede, mas tudo o que você pode fazer é encher o cocho.