Recentemente, completamente por acaso, a partir da sugestão de uma boa pessoa, nasceu a ideia de anexar um resumo a cada artigo. Não uma anotação, não uma chamada, mas exatamente um resumo. Algo que permita não ler o artigo de forma alguma.
Eu experimentei e gostei muito. Mas isso não importa — o principal é que os leitores gostaram. Aqueles que pararam de ler voltaram, me chamando de grafomaníaco. E outra boa pessoa sugeriu que eu escrevesse resumos para cada artigo antigo. Eu concordei e agora, ao mesmo tempo, estou escrevendo essas pequenas resenhas. Chamei-as de 'shorts'.
Apresento a vocês alguns desses 'shorts', com base em algumas publicações. Quem sabe você encontra algo útil para si.
O gato morreu, a cauda está careca.
Reuniões muitas vezes acontecem sem resultados. Reunem-se, conversam e se dispersam.
Os resultados, ou produtos da reunião, são as decisões. E geralmente elas não existem. E se existem, nem sempre são de boa qualidade.
Se a reunião é limitada no tempo e a decisão deve ser tomada obrigatoriamente, então ela (a decisão) tende a ser de baixa qualidade.
Se a reunião não tem limite de tempo e se prolonga até a tomada de decisão, qualquer decisão é aceita, apenas para que a reunião termine.
Se a decisão foi criada na reunião, ela será aceita — simplesmente porque o cérebro valoriza aquilo que ele mesmo criou.
A percepção da baixa qualidade da decisão virá depois, mas será tarde demais.
Para tomar uma decisão eficaz, é melhor não participar da discussão, mas observar em silêncio.
Em primeiro lugar, o cérebro não estará ocupado criando respostas.
Em segundo lugar, não há pressão para tomar uma decisão.
Após o término da reunião, é possível pensar tranquilamente e tomar uma decisão. Ela será de maior qualidade.
O essencial: ficar em silêncio e ouvir na reunião. Para que os outros não se preocupem, dizer que essa é uma posição consciente.
→
Parasitas latentes
Existem essencialmente duas abordagens para a definição de tarefas e controle de sua execução: parasitária e simbiótica.
A abordagem simbiótica — fazer com que a tarefa seja cumprida.
A abordagem parasitária — fazer com que a tarefa NÃO seja cumprida.
A abordagem simbiótica é direta e simples, mas complicada na execução. Por isso, é rara.
A tarefa é definida de forma que tudo fique claro — objetivos, recursos e limitações.
O controle é realizado de forma que a tarefa seja resolvida com precisão.
A abordagem simbiótica implica deixar parte da responsabilidade (aliás, a maior parte) pela solução da tarefa com o responsável.
A abordagem parasitária é complexa e engenhosa, mas simples na implementação. Por isso, é frequente.
A tarefa é formulada de forma que nada fique claro. Quanto menos claro, melhor.
Preferencialmente, o controle não deve ser realizado de maneira alguma.
Não há responsabilidade para o encarregado da tarefa, toda a ‘macaca’ é transferida para o executor.
A finalidade da abordagem parasitária: manipulação, ego, afirmação pessoal. Por isso é comum no trabalho de mentores com funcionários iniciantes.
Preferencialmente, a abordagem simbiótica é a melhor.
→
Medições vs Ilusões
Se você avaliar o processo e os resultados de sua atividade sem medições, estará sempre errado.
A avaliação sem números depende do estado de espírito. Um mau humor fará parecer que você está desempenhando mal. Um bom humor, o oposto.
Você pode passar uma semana trabalhando mal, e na sexta-feira entregar um bom resultado, fazendo parecer que a semana toda foi bem.
Em princípio, existem dois tipos de métricas: quantitativas e alternativas (mais conhecidas entre programadores como booleanas).
‘Tarefa concluída no prazo’ é uma métrica booleana. É o mesmo que ‘Peça em condições’ (um critério alternativo de qualidade quando não se pode medir em números).
‘Estamos trabalhando bem’, ‘Estamos cumprindo o plano’, ‘Eu sou bom’ — também são métricas booleanas.
É difícil construir um processo de gestão com avaliações do tipo booleano. É recomendável passar para métricas quantitativas o mais rápido possível.
As métricas booleanas geram burocracia e formalismo. Por exemplo, cumprir prazos pode ser alcançado aumentando os mesmos, criando tarefas para si mesmo, praticando atividades sem valor.
Para gerenciar com base em indicadores booleanos, é necessário gastar muito tempo — em reuniões, análises, etc. Porque há informação demais.
Recomenda-se medir tanto o processo quanto o resultado. Assim, a imagem será a mais completa.
Para programadores, recomenda-se o método ‘Planning Poker’ do Scrum.
→
Isso é Esparta
Suponha que você seja um programador e lhe apresentem uma tarefa séria. E você acha que a tarefa não deve ser resolvida — é absurda e prejudicial.
Comportamento típico em tal situação: levar a tarefa para o campo público. Enviar para aprovação com o chefe, iniciar o projeto interno, registrar no sistema, etc.
É aqui que tudo desmorona. A pessoa que trouxe a tarefa não quer ser vista como tola. E, sendo exposta ao público, irá se defender.
Para a pessoa, é importante não perder a face, em um sentido político. O principal na política é nunca reconhecer os próprios erros. Pode-se não fazer nada, mas o mais importante é não admitir erros reconhecidos.
A pessoa fará de tudo para provar que o programador é o vilão, um idiota, um opositor da mudança. E o programador, de qualquer forma, precisará resolver a tarefa.
Em alguns casos, a pessoa fará tudo para que o programador não consiga resolver a tarefa. Então a pessoa será ‘branca’ e o programador será absolutamente ‘preto’ (ele se opôs e, no final, não conseguiu).
Existem várias soluções.
A primeira é se tornar um programador de negócios, entender em áreas relacionadas e definir sozinho o que e como deve ser automatizado.
A segunda é ser o responsável pelas mudanças. Por exemplo, um diretor de desenvolvimento.
A terceira é não se manifestar e apenas fazer o que lhe dizem.
A quarta é o Caminho de Esparta, rápida eliminação de soluções. Mais conhecido como fail fast, fail cheap (fracas rapidamente, baratas).
O mais importante é não tornar isso público. Dizer à pessoa — vamos não perder muito tempo, faremos um protótipo e veremos se a solução é viável ou não.
O protótipo levará pouco tempo. Em caso de sucesso, ambos receberão o que desejam — uma solução adequada e pontos políticos.
Em caso de fracasso, ninguém sairá prejudicado. E a pessoa terá uma melhor relação com o programador.
→
Substitutos
Os negócios não gostam de 1C e seus produtos, desenvolvedores web, sistemas de gestão da qualidade, contabilidade, economistas, projetos de desenvolvimento, Scrum, TOC, controle, KPI e sistemas de motivação.
As empresas apreciam o aumento da rentabilidade por meio da automação, o crescimento da receita a partir da promoção na internet, a melhoria da qualidade dos produtos, uma visão simples e clara dos negócios em números, previsões sobre a situação da empresa, um aumento real da eficiência, a aceleração na execução de projetos em 2 a 4 vezes, o aumento exponencial dos lucros e a redução de estoque, um sistema de gestão preciso, um sistema de avaliação claro e compreensível da situação nos negócios e um sistema de avaliação de trabalho que permite dispensar metade dos gerentes.
As empresas valorizam alcançar metas de negócios. As empresas não apreciam substitutos.
Substituto é quando pediram para alcançar uma meta de negócios, mas receberam um projeto de automação, um site, uma pilha de papéis, uma equipe de funcionários sem clareza ou relatórios ilegíveis.
Substituto é quando o objetivo é substituído pelo meio de alcançá-lo. E todo mundo se esquece do objetivo.
A produção de substitutos se baseia em três pilares: formalismo, gradualidade e conluio.
Formalismo é transferir objetivos para o papel com decomposição. Na verdade, é desviar o foco da meta principal para pequenos detalhes. Ninguém mais se lembra do objetivo — todos discutem os detalhes.
Gradualidade é a baixa velocidade da transição de objetivos para meios. Inicialmente, o objetivo ainda é mencionado de vez em quando. Mas gradualmente, passo a passo, é mencionado cada vez menos. Até que o cliente esqueça sobre ele, afundando nos detalhes.
O conluio acontece porque todos os contratados agem de maneira semelhante. Não há nenhum automatizador que realmente aumente os lucros. Portanto, os clientes não têm muita saída.
O que fazer?
Evitar substitutos e o primeiro passo rumo à sua criação: o formalismo. Pelo menos em projetos internos. Estabeleça um objetivo e converse com o executor sobre isso constantemente. Sobre escalas, recursos, planos, etc. — também. Mas o principal é sobre o objetivo.
Caso contrário, o foco da atenção certamente vai se desviar, e você terá mais um substituto.
→
Wladimir Klitschko
Há um boxeador — Wladimir Klitschko. Ele tem uma característica — o uso constante do jab. Ou seja, mais constante do que outros boxeadores.
O jab mantém o oponente em constante tensão, desgastando-o.
As principais características do jab de Klitschko: simplicidade de execução (relativa, é claro) e constância.
A respeito de como ações simples, mas constantes e úteis podem trazer muitos benefícios, falam muitos autores.
Eu também decidi experimentar. Criei um sistema simples de controle — quais jab job eu fiz hoje.
Foi em uma fábrica. Fiz os jab jobs no horário de almoço (não almoço), ou seja, 1 hora por dia. Fiz o que os outros não fazem (dizem que isso leva ao sucesso).
Configurei verificações de um sistema autoaprimorado, criei ideias para desenvolvimento, implementei ideias de outras pessoas para desenvolvimento, configurei tarefas automáticas, refatorei e otimizei o código.
Todo dia — qualquer tarefa dessa lista. Concluí uma tarefa — incrível. Podem ser várias.
Observei por 3 meses. Durante esse tempo fiz 30 verificações, criei 200 ideias, implementei 80 ideias de outras pessoas, construí processos automatizados de dois departamentos, fiz três otimizações incríveis.
Legal, né? É como se fosse 'entre outras coisas'. Recomendo a todos.
→
Substituto flexível
A palavra 'Scrum' se refere a, no mínimo, duas entidades: filosofia e framework.
A filosofia, ou abordagem ao trabalho, está descrita no livro de Jeff Sutherland.
O framework, ou seja, o algoritmo de ações, está descrito em um documento chamado Scrum Guide.
A filosofia se tornou um framework porque os autores da filosofia queriam ganhar dinheiro com isso (segundo suas próprias palavras).
O framework é muito simplificado em comparação com a filosofia. A principal questão é que o objetivo foi simplificado, ou melhor, eliminado.
O objetivo da filosofia: acelerar a obtenção de resultados. E isso, várias vezes. No livro há exemplos de aceleração em até 8 vezes.
O objetivo do framework: garantir que você tenha Scrum. Está escrito: siga o manual — você terá Scrum, desrespeite o manual — você não terá Scrum.
O framework não pressupõe aceleração na obtenção de resultados, de forma alguma.
As pessoas que ensinam ou implementam Scrum trabalham com o framework. Elas falam e implementam um algoritmo que não leva a nenhum resultado, exceto 'agora temos Scrum'.
A essência é clara. Vender filosofia é muito difícil. Framework é mais fácil.
O framework é um produto. Ele, como se espera, passou pela 'embalagem'. Ele é simples, compreensível, há suporte e muitos especialistas. Isso não lembra nada?
Tudo bem, exceto pelos resultados — que não existem.
Se o cliente não estiver familiarizado com a filosofia Scrum, a implementação do framework será totalmente satisfatória para ele.
Se o cliente está familiarizado com a filosofia Scrum, ele ficará desapontado com a adoção do framework — não haverá aceleração na obtenção de resultados.
Será legal, moderno e contemporâneo, mas nenhum objetivo empresarial será alcançado (exceto para gastar o orçamento em 'algo novo').
Como proceder? Estudar a filosofia Scrum. Ela se baseia na filosofia japonesa de gestão da qualidade, cuja essência é: medições e melhorias contínuas.
Infelizmente, é preciso pensar muito, experimentar, observar e, infelizmente, trabalhar. Se isso não se adequa a você — adote o framework.
→
Fonte: habr.com
