Transparência - Panacéia dos Butcherts

Eu já tentei tratar um scrum "mecânico" ( parte 1 , parte 2 , parte 3 ) e, neste artigo, tentarei escrever um medicamento universal para "queima". Por si só, "queimando", "fervendo", etc. - isso é bom, significa que você não se importa ( mas a indiferença é um passo em direção ao desânimo ou, como é habitual em TI, ao esgotamento ). Muitos materiais foram escritos e filmados sobre o assunto dos danos causados ​​pelo esgotamento, por exemplo: aqui , aqui , aqui ou aqui .

Uma sabedoria comum diz: "Buttherts são o motor do progresso". Mas geralmente acontece assim: está queimado => uma solução superficial é adotada rapidamente, mascarando o problema => a solução ganha vida => continua a queimar. Em outras palavras, em vez de resolver e fazer um diagnóstico, imediatamente procedemos ao tratamento. Vou tentar ilustrar isso com exemplos.


Primeiro, vamos definir o termo "transparência". O guia Scrum define desta maneira:

Aspectos significativos do processo devem estar visíveis para os responsáveis ​​pelo resultado. A transparência exige que esses aspectos sejam definidos por um padrão comum, para que os observadores compartilhem um entendimento comum do que está sendo visto.

Aspectos importantes do processo devem estar visíveis para os responsáveis ​​pelo resultado. Esses aspectos devem ser definidos por um padrão comum, para que os observadores compreendam igualmente o assunto.

Essas definições se aplicam apenas ao processo, quero considerar o conceito de forma mais ampla. Não me comprometerei a fornecer definições científicas exatas, mas tentarei descrever a "transparência" através das condições necessárias para sua existência. Portanto, para transparência, você precisa:

• O objeto que alguém precisa ;
• Um objetivo comum para todas as partes interessadas relacionadas à instalação;
• O desejo de todas as partes interessadas em alcançar a meta;
• A capacidade de todos se comunicarem em um idioma, ou seja, a capacidade de desenvolver uma estrutura conceitual que seja significativa para todas as partes interessadas ( por exemplo, termos como ROI e Redux , parece que eles estão em planos diferentes e distantes, embora muito espaçosos em ambientes de informação específicos ).

Se essas condições necessárias forem atendidas, você poderá iniciar o processo de construção de transparência: definindo uma tarefa, definindo critérios de sucesso na solução de um problema, desenvolvendo um método para avaliar critérios. Como pode ser:

Primeiramente, respondemos às principais perguntas:

• Para que você está indo?
• Qual é o propósito?

A seguinte sequência de ações é possível:

• Definimos a terminologia ( por exemplo, todos entendem a tarefa finalizada da mesma maneira, e não para o desenvolvimento é quando o código é escrito, e para os negócios é quando o cliente começa a usar os resultados );
• Concordamos em aspectos-chave e como mediremos sua condição, como perceberemos os resultados ( por exemplo, nos reunimos uma vez por dia, examinamos o plano, determinamos nossa condição em relação a esse plano );
• Incorporamos nosso plano.

Separadamente, quero enfatizar que a coerência e a adoção geral de acordos são importantes, sem as quais é difícil conseguir engajamento. De fato, nos sistemas de tomada de decisão ( por exemplo, no exército ) a base conceitual é uniforme, as ações e os critérios de avaliação são claros, mas quanto é aceito ( existe empatia ) pelos participantes é uma grande questão.

Espero ter conseguido revelar minha ideia de transparência, depois tentarei dar alguns exemplos de situações que podem ser melhoradas se a transparência for adicionada.

Sou uma criatura trêmula ou tenho o direito?

Recentemente, parece-me que a questão do esgotamento profissional no ambiente de TI tem sido muito aguda ( atenuações temáticas inteiras são realizadas sobre esse tópico, por exemplo, PiterJS , onde houve um relatório da minha colega Zhenya Kot bunopus ).


Nosso trabalho é intelectual, a mentalidade é analítica, bem, você mesmo está sabendo. Parece-me que há uma tendência de inventar dificuldades onde elas não existem. Às vezes, isso acontece precisamente por falta de transparência ( aqui estão alguns resultados de pesquisa: um e dois ), e não por causa da grande quantidade de trabalho: não há informações necessárias - eu mesmo as elaborarei ( lembre-se da mentalidade analítica ), tirarei conclusões da suposição - elaborarei um plano e ir à guerra com castelos no ar. Aqui estão as perguntas que podem nos interessar ( especialistas em TI ):

• Mas estou fazendo bobagem? Como meu trabalho melhora o mundo?
• Quão bom sou no meu negócio?
• Sim, eles sabem quem eu sou? Quem são eles? O que eles se permitem?
• O que vem a seguir? Para onde eu vou? Eu vou com aqueles?

As perguntas estão corretas, é importante que uma pessoa reflita sobre o passado, pense no presente e planeje o futuro. É importante pensar nas pessoas que estão por perto. E, transferindo-o para o trabalho, é claro, podemos esperar que os próprios trabalhadores procurem respostas para essas perguntas, esclareçam o que os preocupa. Mas você pode simplesmente tornar tudo isso transparente e, em seguida, as pessoas se concentrarão em assuntos mais altos e resolverão problemas no próximo nível, visando otimização, inovação etc. Existem inúmeras ferramentas para fornecer esse tipo de transparência. Aqui estão alguns exemplos:

• Os objetivos, missão e estratégia da empresa são abertos e compreensíveis para os funcionários e são bem conhecidos. Todas as tarefas táticas são ensinadas através da comunicação com a estratégia; é sempre claro para qual objetivo atual esse ou aquele trabalho é necessário. Está claro não apenas o que precisa ser feito, mas também porque é que precisa ser feito.
• Os funcionários recebem regularmente feedback sobre os resultados de seu trabalho: realizações, pontos de crescimento ( por exemplo, 360 ou 1 a 1 pesquisas ). Planejamento de desenvolvimento conjunto e inspeção da dinâmica de alcance deste plano.
• A estrutura organizacional descrita e as comunicações dentro dela: o que e com quem você pode conversar. Contratos sociais, cartões de visita da equipe etc.
• Um sistema de motivação transparente, uma árvore de carreira e, possivelmente, gamificação desse processo. Você pode se inspirar em exemplos de litros ou 2GIS e criar sua própria cultura na qual os funcionários entendem como determinar e influenciar seu nível de motivação material.

Agora, no entanto, como sempre, todos estão ocupados procurando o "lugar de uma pessoa neste mundo", e se as ferramentas forem fornecidas para se definir pelo menos no trabalho, esse funcionário será um pouco mais harmonioso e feliz, e poderá haver menos casos de desgaste profissional.

Cruzadas

Nós, brancos, adoramos quebrar lanças em guerras sagradas: Reagir vs Angular , iOS vs Android, OOP vs funcionalidade, etc. Mas, infelizmente ou felizmente, não há "bala de prata". Há uma tarefa e soluções específicas. Quando nos deparamos com a escolha de tecnologia, estrutura, arquitetura etc., com um alto grau de probabilidade, estamos em um domínio "confuso", de acordo com o modelo de Kenevin , e, como resultado, não há resposta certa. Nesta situação, é desejável perceber e corrigir o problema que está sendo resolvido, entender quais alternativas estamos considerando, quais critérios temos para tomar decisões. É necessário coletar esses dados juntos, fazer uma escolha e também documentá-los. Com o tempo, vale a pena retornar a esses artefatos e reconciliar-se com o local para onde estamos nos movendo. Tudo é mutável: o mundo, a empresa, a equipe, pessoas específicas, condições etc., portanto, quando temos informações sobre quais áreas e por que escolhemos, é mais fácil ajustar o caminho com base nesse conhecimento. E para não cair na situação clássica de rasgar um colete no peito : “Mas quem já inventou tudo isso ?! Parece que as pessoas não eram adequadas, uma vez que isso é empilhado. Aqui está a resposta correta, é óbvio. Vou salvar todos e refazer tudo. "

Acho que muitas pessoas estão familiarizadas com a situação quando, na tentativa de construir um "maravilhoso mundo novo", mudam seus líderes, a equipe, para aqueles que estão prontos para queimar a Babilônia, mas o resultado não é uma fênix, mas um duende.

Você pode tentar não cortá-lo do ombro, mas analisar retrospectivamente todos os erros e imprecisões, rastrear a lógica das decisões técnicas, levar em consideração os riscos e apresentar uma nova hipótese. E a base para a tomada de decisões não será "todos eles são tolos ...", mas "as condições mudaram e já estamos resolvendo um novo problema".

Parece-me que é difícil tomar as decisões técnicas certas o tempo todo. Você pode aprender a configurar experimentos, avaliar os resultados obtidos e planejar as próximas etapas, levando em consideração as novas informações recebidas. E pode ser mais fácil se você tiver artefatos disponíveis para todas as partes interessadas que descrevam a lógica das decisões técnicas.

Implemente agile / scrum / kanban / lean em cp * ki compactado

Há um eterno debate no ambiente ágil: “Por onde começar a transformação: da cultura / valores / mentalidade ou mecânica / rituais / artefatos?”. Um dilema clássico de frango e ovo. Minha posição é que, para um treinador ágil "forte e independente", pode acontecer que uma equipe através da mecânica gradualmente chegue à atenção plena. Porém, mais frequentemente, se você começar com a mecânica e implementar algum tipo de abordagem como um culto à carga, provavelmente obteremos ceticismo e decepção na metodologia e, na pior das hipóteses, também ganharemos odiadores. Como isso pode acontecer está bem descrito no Scream Guide ( aqui uma tradução ardente ).

Portanto, sou a favor de analisar quanto dos valores ágeis se aplicam ao seu caso e só depois prosseguir com a aplicação de uma estrutura ou técnica. Não há teste universal, mas existem documentos decisivos ( por exemplo: teste ágil e guia ágil ): primeiro pense se o scrum condicional ajudará ou não no seu caso ( outro exemplo de tabela de teste ).



Vejamos um exemplo: uma empresa se deteriora porque o desenvolvimento é lento, uma decisão é tomada - vamos implementar scrum / kanban / lean, porque acelera o desenvolvimento ( por isso não significa ). E, com o tempo, concluímos: "isso é charlatanismo e truques de marketing, não funciona". Uma história familiar? Minha opinião é começar com transparência. Vamos entender o que exatamente incomoda. Vamos começar a falar nos mesmos termos e entender os termos da mesma maneira. Vamos formular as perguntas: "Qual é o problema?", "Como entendemos que é ruim?", "Como entender o que é melhor?", "Como determinamos o que é bom?", "Todos perceberam o problema e perceberam ela como um problema ( por exemplo, não os caprichos de gerentes estúpidos )? ” E quando tudo ficou transparente, nesse momento você pode procurar soluções. De fato, "desenvolvimento lento" pode significar:

• Não há um processo normal de implantação; implantar alterações nos produtos é uma dor. Opções de solução - implemente a cultura DevOps , execute CI / CD ;
• Negócios e desenvolvimento não aprenderam a falar. Parece aos negócios que o desenvolvimento não entende nada e, ao contrário, acredita que os negócios não sabem o que querem. Soluções possíveis - tente criar uma definição de objetivos, criar um mapeamento de impacto ou usar OKR ;
• A estrutura hierárquica é preenchida com microgerenciamento, em que há uma lenta adoção de decisões táticas devido à necessidade de coordenação com as superiores. Opções de solução - treine pessoas em facilitação, conduza experimentos com confiança ( assista a um vídeo motivacional com o TED );
• A lista continua.

Pode haver muitas situações; para cada uma delas, existem ferramentas de melhoria próprias. E frequentemente a implementação de agile / scrum / kanban / lean / etc. parece martelar pregos com um microscópio e, de fato, criar a aparência de atividade violenta, mas sem procurar uma solução para o problema. Portanto, a regra “não se torne um ídolo” funciona aqui: você não deve procurar uma bala de prata nas abordagens / metodologias / estruturas de hype, primeiro apenas perceba o problema que está resolvendo e escolha uma ferramenta de solução depois disso. E acontece que, tendo embarcado no caminho da melhoria contínua ( conscientização do problema, formalizando o trabalho com ele, transparência, encontrando soluções por meio de experimentos ), você construirá seu processo como qualquer coisa, mas funciona perfeitamente para você.

Por que eu sou tudo isso

De acordo com o modelo Kenevin, quase todo o nosso trabalho de TI está em um domínio confuso, o que significa que a opinião de especialistas não funciona aqui e não há respostas corretas. E uma das opções possíveis para uma existência confortável é um processo empírico que começa com transparência. Parece que essas são verdades comuns, mas parece que nem sempre são lembradas.

Se você leu esse lugar e foi bombardeado pelo artigo de outro capitão populista, tente se perguntar:

• Por que está queimado?
• Por que isso me enfureceu?
• O que poderia ser diferente, para não me causar tais emoções?

Escreva tudo isso nos comentários: coloque todos os pontos sobre i e torne essa pergunta transparente.
Resumindo: a opacidade pode levar à desintegração da sociedade em grupos, guerras santas, manifestos , etc. Mas você pode sentar e tentar falar o mesmo idioma e ouvir um ao outro. Toda transparência!

Obrigado pela ilustração, Sai Kin !