Como me posso preparar para ser atropelado por um autocarro?

Documentação.

Compromissos de código razoavelmente frequentes.

Documentação.

Documentar as suas ideias, os seus desenhos e o seu código. Quaisquer problemas que conheça.

Documentação.

Documente os seus erros explicando qual foi o problema e como o resolveu, e porquê.

E mencionei documentação?

Se trabalha num ambiente onde a política é laxista (para que os devs júnior não se dêem ao trabalho de apresentar alterações à documentação - as actualizações da documentação relevante devem ser mandated ao lado de cada ramo), falta a revisão pelos pares (para que os devs júnior/senior sejam apanhados durante os spates da preguiça compreensível), e/ou a documentação é armazenada separadamente do código (para que possa ser facilmente perdida), então também é importante considerar se o ambiente pode ser alterado para que estes problemas não o sejam. Caso contrário, todo o vosso esforço em escrever documentação pode ser em vão.

Dito isto, nem sempre chegaria ao ponto de lhe chamar uma responsabilidade pessoal: em última análise, se as equipas forem mal geridas e/ou organizadas, então isso não é da vossa responsabilidade; no caso de passarem para um novo emprego, eu apenas entregaria a minha documentação completa e pensaria “bem, se não conseguirem usar e manter isto correctamente, então isso é seu erro… agora boa sorte”.

Essa linha de raciocínio não se mantém no caso “atropelado por um autocarro”, em que se pode estar no processo de instigar tais políticas, mas ainda não o fez. Para este cenário, sugiro simplesmente que encoraje a gerência (e os seus superiores) a começar a levar estas coisas a sério _ o mais rapidamente possível_.

Não faça o contrário. Trabalhe como se NÃO fosse “atropelado por um autocarro” amanhã.

O problema “atropelado por um autocarro” é um problema organizacional e não algo que precisa de ser explicitamente abordado nos seus próprios objectivos de trabalho.

Os seus colegas de trabalho e gestores deveriam estar a pensar nisso, mas penso que é demasiado esperar que os colaboradores individuais trabalhem como se pudessem literalmente ter partido amanhã. Se a gerência não tem conhecimento dos potenciais problemas aqui, significa que eles estão totalmente fora de contacto ou talvez você não seja tão indispensável como pensava.

Na melhor das hipóteses, se você for generoso, talvez queira lembrar as pessoas-chave e os líderes sobre ter apoio em caso de emergência. Mas numa era em que as empresas atiram carreiras “para debaixo do autocarro” por capricho de lucro a curto prazo, o que é que realmente lhe interessa?

As práticas de engenharia diluentes resolvem muitas das questões do dilema “atropelado por um autocarro”. Ir para além disso, a ponto de estar pronto para o desaparecimento imediato e permanente, irá criar muitas despesas gerais para o contribuinte individual. Parece que o ambiente descrito pelo PO poderia beneficiar simplesmente de melhores práticas e pessoal, não há necessidade de ele trabalhar como se pudesse vaporizar a qualquer minuto.

Se está a trabalhar como empreiteiro, eu diria que isso é 100% da responsabilidade do seu empregador. Diga-lhes que o cumprimento dos objectivos que estabeleceram para si significa que outras coisas que pensa que deveriam ser consideradas objectivos não estão a ser feitas; pergunte-lhes se eles querem ajustar os seus objectivos. Eles podem muito bem dizer-lhe para continuar como está, uma vez que o seu tempo é caro e eles querem a melhor relação custo-benefício a curto prazo.

Se está a trabalhar como empregado, pode ter mais margem de manobra para planear a sucessão (ou possivelmente há uma expectativa de que já o esteja a fazer). Mesmo assim, fale com o chefe ou gerente da sua equipa, pois eles precisam de saber sobre o problema e como você está, e pensam que deveria estar, a gastar o seu tempo.

Algumas coisas que ajudariam no planeamento da sucessão:

• Os processos diários devem ser documentados até certo ponto, mas é provável que outras pessoas da sua equipa sigam os mesmos processos e possam ensiná-los a um recém-chegado. Se nem todos utilizam processos semelhantes, esse é um problema actual que deve ser resolvido; junte-se, debata qual a melhor maneira, chegue a algum padrão (consensual ou forçado de cima), e use o padrão, parabéns que o padrão pode ir na sua documentação para o recém-chegado.
• Coisas importantes que são comunicadas via e-mail, reuniões, ou conversas casuais precisam de fazer dele um recurso partilhado, qualquer coisa desde uma pasta de documentos numa drive partilhada até um wiki. Há esta estranha crença (pelo menos onde eu trabalhei) de que se algo é enviado por e-mail para todos os membros de uma equipa, então para sempre essa equipa saberá a coisa; isto não leva em consideração que a composição da equipa muda e que qualquer formação (se acontecer) nunca irá transferir todo o conhecimento, apenas um subconjunto de conhecimento frequentemente utilizado.
• (Possivelmente específico do software) Documentar processos ou decisões de design claramente contra-intuitivos, é importante identificar que o processo é reconhecido como contra-intuitivo e porque é que o é, independentemente disso. Por exemplo, se o seu cliente lhe pediu para fazer algo que parece “incorrecto” (“Eu não sou um especialista no domínio, mas tem a certeza que quer fazer isso?”), e explicou porque achou que era incorrecto e eles confirmaram que era o que queriam (melhor ainda se explicaram porquê), então as razões pelas quais achou que era incorrecto e a explicação de porque era correcto devem ser documentadas. Que o software funciona de acordo com as especificações não vai ser suficiente para uma substituição, eles terão a mesma pergunta que você fez.
• Para qualquer problema que você encontre que leve muito tempo/investigação para resolver, documente o problema, os sintomas, o caminho mais curto para a solução (ou seja: saber o que você sabe agora, qual foi o caminho mais rápido de identificar sintomas para uma solução), e a solução. Os sintomas são realmente importantes para a sua substituição, pois vão atingi-los antes de perceberem completamente o problema.
• O ponto anterior é ainda mais importante no que diz respeito a sistemas antigos, como bibliotecas ou plataformas, onde novas versões estão a ser lançadas mas não são utilizadas no seu produto. Os problemas que encontrar na sua versão (ou pior ainda, nas interacções entre vários sistemas antigos) poderão ser resolvidos em versões futuras e assim a própria existência da falha desaparecerá do conhecimento público, até que seja quase impossível encontrar informação sobre a mesma.

As férias são um bom “treino” para se preparar para coisas como essa. Também ajuda a medir o quão bem você está preparado. Volte ao trabalho após 2-3 semanas e conte os dias e o esforço gasto na limpeza do seu “atraso” - isto pode fazer uma boa aproximação ao “cenário de atropelamento por autocarro”.

Isto também é uma ferramenta útil se quiser melhorar. Analise os itens de atraso que tem de resolver e pergunte a si mesmo o que poderia ser feito para que isso pudesse ser feito por outra pessoa. Num dos trabalhos passados, isto ajudou-me a diminuir a “acumulação de férias” de cerca de três semanas para dois dias em menos de um ano.

• Oh meu Deus, parece que sou o único que tem esta informação, preciso de a documentar para a disponibilizar a toda a equipa.
  Raios, ninguém pode corrigir este bug a não ser eu, preciso de encontrar e treinar um tipo de apoio…

O que vale a pena ter em mente é que geralmente isto é considerado uma responsabilidade da sua gestão , por isso tudo o que fizer para além do necessário está à vontade. Pergunte a si mesmo o quanto você quere lutar bus factor e proceder de acordo.

Eu para um quero ser substituível…

• …para que outro tipo a verificar as minhas coisas do repositório não tenha de voltar para mim a tentar compreender código insustentável
• … …para que outro tipo a olhar para os meus registos em issue tracker não precise da minha ajuda para figure em que estava a pensar enquanto trabalhava nele
• …para que outro tipo a ler as minhas wiki pages não precise que eu explique as coisas lá documentadas
• . …para que eu possa apreciar como coisas que eu fiz cresce e floresce, vivendo a sua própria vida

…para que eu possa concentrar-me em fazer coisas novas sem ser distraído por preocupações com o que ficou para trás.

Pergunte à sua equipa. Pergunte ao seu gerente. Apresente-lhes o assunto exactamente da forma que tem para nós.

Dê-lhes opções. Documentação para um futuro desenvolvedor. Documentação para eles. Pagar a dívida técnica. Qualquer coisa que possa pensar. Dê-lhes estimativas de tempo. Dê-lhes a escolha. Deixe-os pesar contra o seu trabalho diário normal.

Ei, eles podem até decidir que é um risco que vale a pena correr. Mas, na verdade, é a eles que cabe decidir.

E, se decidiram arriscar, então o seu espírito imortal deve deixar de se sentir culpado por isso.

Eu queria chegar e responder a essas perguntas…

A lição mais difícil que já aprendi foi a de não responder a essas perguntas. Mas fazer a pergunta certa para as conduzir, sem suspeitas, a encontrar a resposta por si próprias.

Uma resposta dada é diferente de uma lição aprendida!

Explicação

Existem basicamente dois cenários diferentes que criam o único ponto de falha que o PO está a abordar.

Negócios

Isto pode ser uma decisão consciente ou um resultado de um mau planeamento, processo ou crescimento do negócio. Pode também ser o resultado da inacção ou da incapacidade de reconhecer e abordar a crescente falta de conhecimento.

Independentemente da forma como, o negócio cria a situação em que tem uma super dependência de um único indivíduo ou de um pequeno grupo de indivíduos que formam o núcleo da sua base de conhecimento. Muitas empresas abordam esta questão através de programas de mentoria, formação cruzada e partilha formal e informal de conhecimentos.

Da minha experiência, as que têm mais sucesso nesta área também promovem uma abordagem pedagógica. Com isto quero dizer que raramente é dada uma “resposta” a uma pergunta, mas sim uma discussão e perguntas apontadas pelo(s) especialista(s) que o(s) conduzem a um caminho de aprendizagem e expansão dos seus conhecimentos sobre o produto, processo, tecnologia em jogo.

Isto também oferece uma nova visão e perspectiva ao especialista na medida em que a discussão. O ensino pode, de facto, ir nos dois sentidos.

Employee

Em geral, tem dois tipos diferentes de empregados que acabam nesta posição. O que eu chamo de ‘The Go To’ e ‘The Protector’.

‘The Go To’ é aquele empregado que a maioria dos gestores adora. Ele é aquele que você pode atribuir praticamente qualquer tarefa ou projeto e não precisa se preocupar com isso. Estas são as pessoas que conquistam o seu nicho na empresa e se tornam o go to person e, mais do que provável, aquele que tem as respostas.

‘The Protector’ é aquele empregado que tomou a decisão de proteger o seu território. Eles sentem que ao guardar os seus conhecimentos estão a assegurar a sua posição, importância e futuro na empresa.

Ambos criam inadvertidamente pontos únicos de falha. O Go To‘ fornecendo sempre a resposta rápida e o ’The Protector_‘ não partilhando nenhuma ou toda a informação.

Assim, em resumo, toda a documentação no mundo não resolverá o problema subjacente de um único ponto de falha. Sim, é importante e deve fazer parte de todos os planos de BCP e de preparação para catástrofes. Mas documentação não é realmente partilha de conhecimento no sentido de que alguém deve ser capaz de intervir e executar as suas tarefas sem ter de percorrer um documento de 200 páginas antes de o entregar.

Não responda à pergunta; dê-lhes poder para que a possam responder por si próprios.

Eis o que fazemos onde eu trabalho:

a) Utilizamos um wiki para documentação. Não ficheiros Microsoft Word, ou ficheiros de texto. Um wiki que é pesquisável, totalmente rastreável, etc. (Eu recomendaria Confluence , mas Confluence v4 é um cão tal que sugiro que procure noutro lugar)

• Qualquer processo repetitivo ou delegável deve ser documentado.
• Listas de verificação de “aqui é como nós fazemos _____” devem ser escritas
• As listas de verificação são muito importantes para construir equipas, pois permitem que os processos sejam feitos por qualquer pessoa que possa seguir a lista…

b) Controlo de versões, obviamente

c) Sistema de rastreio de casos/questões, obviamente

d) Comentar o seu trabalho. Isto é a coisa mais matizada, e é tão difícil de ensinar, mas como empreiteiro/independente, você pode ser capaz de tatear isto: Os comentários devem explicar o seu processo de pensamento e o porquê do que está a fazer. Links para documentação, Stack Overflow, etc. são apropriados. Os parágrafos e páginas de comentários são apropriados. Explicar as coisas que tentou e NÃO fez é apropriado. Um dos maiores problemas do código é que se perde o pensamento e o suor que vai para fazer algo funcionar de uma maneira (em oposição a uma maneira diferente). Há um livro, algo como “código bonito” ou algo assim, que tem uma parte dos blocos de comentários numa unidade num dos grandes sistemas abertos VCS Subversion ou Git , penso eu). É bonito porque conta a história. Aqui está o que este código faz. Aqui está como ele funciona. Aqui está como ele é estruturado. (Confesso que este bloco, se bem me lembro, pode não entrar muito na questão do “porquê”)

Um corolário disto é: Quantas pessoas voltam e editam o código só para acrescentar comentários? Todos nós devíamos… muito. Mas, na prática, quase ninguém o faz.

A Netflix tem um sistema a que chamam ChaosMonkey . Essencialmente “quebra” ou emula a quebra de determinados sistemas ao acaso.

Os empregados podem ser considerados como sistemas e uma forma de emular a quebra de um empregado é dar-lhe uma folga não anunciada e não programada. O ChaosMonkey disse-lhe para ir ver um filme sem avisar os seus colegas de trabalho. A curto prazo, o efeito sobre eles é o mesmo que se tivesse sido atropelado por um autocarro.

Isto testa a robustez dos seus sistemas e permite-lhes detectar novas falhas nos seus sistemas que de outra forma poderiam ter passado despercebidas.

Isto pode ajudar na transferência de conhecimento de uma forma redonda e aproximada uma vez que um sistema mais robusto é susceptível de quebrar menos e terá menos bugs grandes que precisam de atenção permitindo às pessoas em questão serem capazes de se concentrar mais na forma como o sistema funciona e porque é que ele faz o que faz em vez de apenas perseguir questões irritantes que consomem tempo valioso de troca de conhecimento.

Desde que escrevi esta resposta, tomei conhecimento de https://www.fdic.gov/news/news/financial/1995/fil9552.html . Basicamente, o FDIC recomenda que os bancos imponham vagas obrigatórias e pagas de pelo menos 2 semanas consecutivas aos principais funcionários dos bancos. O bem-estar dos funcionários é uma consideração secundária. A principal consideração é que isto forçará os bancos a nomear outra pessoa para cuidar das responsabilidades do funcionário que está a vagar. Se o empregado vago estiver a desfalcar, o esquema desmoronar-se-á sob a vigilância do substituto. Isto também significa que o banco não será vulnerável a um ataque de autocarro.

Eu começaria com

1. Standardization

2. Revisões regulares e obrigatórias de códigos/projectos*

3. Eam Spirit

4. Obviamente Documento*. É uma canção antiga. Não vou voltar a cantá-la

O planeamento para isto faz parte de um Business Continuity Planning enquanto se trata de planear desastres maiores do que apenas ser atropelado por um autocarro, mas o processo coloca as peças para recuperar de pequenos incidentes como um jogador chave a ser escalfado, para problemas maiores como um desastre que destrói edifícios, e as pessoas que os ocupam.

Wiki-Como é que se escreve assim como criar um BCP e embora eu não recomende a utilização deste método para o seu negócio, ele fornece uma boa visão sobre os processos e pensamento necessários para criar um. Geralmente os BCP são feitos em abordagens faseadas, lidando com os maiores riscos e preparando-se para cenários mais prováveis em primeiro lugar e respondendo a preocupações de menor risco depois. Mas cada empresa geralmente constrói lá BCP de acordo com as suas próprias necessidades, pelo que o processo exacto varia.

O processo geralmente envolve:

• Identificar áreas de risco
• Documentar os processos envolvidos
• Determinar respostas adequadas a vários cenários
• Elaborar planos para lidar com os cenários

As nossas regras diárias contra pessoas que levam conhecimento para a cova:

• Se alguém escreve um guião/rotinas, então alguém tem de ser o primeiro a utilizar aquilo em produção.
• Se alguém utiliza novos sistemas, então ninguém os utilizará ou suportará até que possa procurar todas as credenciais de acesso necessárias por si próprio, sozinho, à noite, sem pedir a outra pessoa.
• Há também “configuração como código” e testes automáticos para software. Permite ao seu sucessor reverter o seu trabalho.

Na verdade, “coisas que ainda não estão listadas/testadas não existem para nós”. Apenas as coisas que estão listadas são fiáveis.

Chamamos-lhe “ conhecimentos daarcane”. (apenas guardado na cabeça de alguém), e todos se recusam a agir sobre ele.

Obviamente que isso não funciona entre tópicos técnicos e não técnicos. Mas também não esperamos que os técnicos sejam capazes de assumir os cálculos financeiros do departamento de contabilidade. Por isso mesmo o nosso departamento de contabilidade poderia levar “o conhecimento para a cova”, se apenas 1 contabilista alguma vez fizesse esses cálculos.

Porque existe um limite. Se a equipa for muito pequena, então haverá sempre alguém que vai ser atropelado por um autocarro.

Os pontos seguintes devem constar da descrição do trabalho que lhe foi entregue e estabelecida pelos proprietários da empresa. É da sua responsabilidade ter isto em vigor. No entanto, poderá ser o único que tem conhecimentos para os informar que isto é necessário.

• Trabalhe dentro dos padrões bem estabelecidos para a sua área ou organização.
• Documente o que faz.
• Documente em grande detalhe se se desviar dos padrões bem estabelecidos e porque o fez.
• Documente como documentar para a sua organização.
• Se está no topo de uma cadeia de administração do sistema e tem a raiz/super contas de utilizador; crie uma conta que tenha a maior autorização de segurança possível. Gere uma senha longa e aleatória para ela. Imprima-a em papel. Assine. Feche-o num envelope e ** entregue ao conselho de administração e não ao CEO***. Porque um CEO pode separar-se da empresa em más condições e continuar a ter essa palavra-chave. Diga-lhes para a guardarem em segurança, fora do local e da sua utilização(Pode dar-lhe um estatuto de super utilizador na rede em caso de ausência ou outros motivos que se possam aplicar).