thegoodfellas/blogset-br huggingface dataset:
incluindo presidencia, diretoria e gerencia.Sabemos que a mentira deriva de um ambiente onde a confianca esta baixa ou sequer existe. Sabemos tambem que e uma caracteristica existente no ser humano e ate em outros animais. Nosso cerebro sente um certo prazer, pois ele e desafiado. Inclusive, seu cerebro mente para voce varias vezes por dia.Vamos refletir sobre agentes exteriores que contribuem para a propagacao da mentira de uma corporacao.O primeiro agente, na minha visao, e a forma como e planejada e executada a distribuicao de bonus. Da forma como e feita hoje em dia, (1) prejudica os relacionamentos internos; (2) prejudica a eficiencia da corporacao, ao contrario do pensamento comum; (3) fomenta a competicao nociva, em detrimento da colaboracao; (4) favorece um ambiente fertil para a mentira. Existem outros.O objetivo deste post e ser curto e nao focar nestes quatro fatores que destaquei. Se surgir alguma duvida sobre o paragrafo anterior, sinta-se a vontade para debatermos nos comentarios.Um segundo agente, ja deixei uma pista, e o ambiente hostil a fomentacao da confianca. Varios fatores contribuem para isso, (1) Cobrancas publicas; (2) Prazos apertados; (3) Falta de visibilidade, dentre outros.Mais uma vez, o foco nao e esse. Deixo os comentarios a disposicao para um bate papo sobre isso.A introducao foi longa por estarmos tratando de um assunto delicado. As pessoas nao metem porque sao mas. Bem, algumas sim.***Uma maxima da gestao moderna e que voce nao melhora o que voce nao ve. Gestao moderna que esta ai desde a decada de 70, pelo menos, com Demming, Ohno, Drucker e CIA.Mas ver, de forma cristalina, todos os processos da sua empresa, detalhados em numeros, pode entrar em choque com uma necessidade de grande parte da empresa: mentir.Sabemos como resolver o problema do ambiente nocivo a confianca, mas mais uma vez nao e o foco aqui.Como ver e mentir?Atraves de numeros relativos. Ao relativizar voce nao mexe com um assunto delicado pre-existente. Lembre-se que o sistema e elastico. Ao introduzir um agente de mudancas, estamos gerando uma pressao interna. Precisamos de habilidade para lidar com essa propriedade elastica.Boa parte da comunidade lean, sabe que a criacao de um ambiente de confianca e fundamental para o aumento da eficiencia. Entretanto, sabe que e muito importante medir. Se voce nao consegue introduzir mudancas, meca. Eu acredito muito nessa linha de pensamento.Mas ao medir, voce pode expor numeros e entrar em choque com muita gente. Se a sua empresa nao esta pronta para ver esses numeros, torne-os relativos.Ex: Quando fizemos a mudanca XPTO, reduzimos em X% a quantidade de bugs em producao. Reduzimos em Y% o leadtime medio. Z% das funcionalidades nao retornaram para desenvolvimento. W% do nosso tempo agora e usado criando valor direto para o cliente.E uma solucao simples que pode salvar a aprovacao de um trabalho que pode fazer toda a diferenca para a saude da empresa. Nao apenas a saude financeira, mas a saude do organismo empresa.E e uma abordagem natural para a maioria das empresas, que estao acostumadas a ver o seu retrato atraves das porcentagens.Baseado nos processos de transicao que eu vi
acontecer, se eu tivesse que escolher uma acao indispensavel, esta seria a metrificacao. Metrificacao de aspectos que ajudem a empresa a melhorar, evoluir. Alguns exemplos sao o leadtime, throughput, takt time, touch time. Estes sao numeros que, se melhorados, ajudarao a empresa a aumentar a eficiencia. Ajudarao a empresa a poupar dinheiro.Utilize metricas sempre, procure metricas do passado. Se o ambiente for hostil a metrificacao, encontre uma forma de contornar e jogar com as resistencias.Afinal, essa nao seria a maior qualidade de uma agente de transicao?
Entretanto, se investigarmos um pouco mais, vamos encontrar causas sistemicas como causas raizes.E fundamental change agents e gestores de todos os niveis conhecerem e exercitarem a habilidade de usar os efeitos sistemicos a seu favor. Tambem e de grande importancia aprender a investigar corretamente as causas raizes, para que as solucoes trabalhem em beneficio na melhoria da organizacao como um todo. Se voce atacar causas superficiais, voce resolvera apenas problemas superficiais. Se voce atacar as causas raizes, voce estara resolvendo problemas profundos da organizacao.
ele nao conhecia ate entao. Neste momento, historias sao canceladas, outras aparecem, prioridades mudam. E impressionante ver o sistema ganhando vida.Tambem e bastante normal percebermos este estado reflexivo do AN quando os desenvolvedores o chamam para tirar um duvida complexa e critica. Nestes casos, e muito comum esta reflexao ser promovida ate em quem pediu aquela funcionalidade.A causa raiz para estas historinhas e muito simples. Poderiamos chamar de grau de frescor da informacao. Quanto mais fresca e a informacao, mais qualidade ela tem. Como consequencia temos uma alavancagem clara do processo de aprendizado e o desenvolvimento flui de uma maneira mais eficiente.Nao e o Scrum, XP, Lean, Kanban que resolvem o problema da sua corporacao. O que vai resolver a maioria dos seus problemas sao os ciclos curtos de inspecao e adaptacao. Poderiamos chamar ciclos curtos de feedback e acao.Neste contexto, o papel do AN e muito importante e requisitado. Visando acabar com os maiores desperdicios em um processo de desenvolvimento, nao so paga a presenca "full time" de um AN, como retorna lucros sobre a medida em um curto periodo de tempo.O trabalho dele seria o detalhamento continuo do backlog, fazendo de forma continua, alimentando a entrada do fluxo, e a solucao de duvidas que possam (irao) aparecer no restante do time.O resultado e um produto final com muito mais qualidade e, na grande maioria dos casos, mais barato e em menos tempo.Acho que e facil perceber o que acontecera no mundo competitivo que vivemos....As empresas que acordaram para este fato e estao se reinventando, olhando para dentro, entendendo os seus processos e os melhorando de forma continua estarao anos luz a frente das empresas que ainda estarao dormindo e precisarao passar por todo processo de aprendizado.Nao acontece como uma virada de chave. Para a sua empresa deixar seus processos enxutos, exigira um processo arduo de aprendizado e retroalimentacao. Fundamental.Isso nao e verdade apenas no contexto de desenvolvimento de software. Ja exemplifiquei como "leanizei" a minha criacao de canarios e temos estes principios e valores aplicados nos lideres de todos os segmentos de mercado no mundo, tanto na industria quanto na prestacao de servicos.Deixo abaixo, novamente, um video da montagem final do Boeing 737, com as praticas fundamentadas na legenda.https://www.youtube.com/watch?v=Ihtl-SZLU9o
Criamos o video de pre lancamento da Change Management Brasil. Assistam e, se gostarem, curtam e compartilhem. Estamos criando conteudo de primeira e o proximo video ja esta planejado. Fishbowl durante o AgileTour em MaringaDurante o fishbowl deste fim de semana, uma pessoa perguntou o que fazer quando a resistencia esta muito grande. O que fazer quando middle e top management comecam a resistir ao norte da visao?O primeiro ponto para refletir e que nada garante que a transicao vai dar certo, mesmo lendo todos os livros do Kotter, Mary Lynn, Drucker, Demming e fazendo todos os cursos oferecidos pelo mercado. E o motivo para isso pode ser expressado na teoria da complexidade. A organizacao e um organismo vivo, que possui vontade propria, que pensa. Podemos prever algumas reacoes aos estimulos, mas a maioria e impossivel. Nenhuma teoria e praticas anteriores podem garantir o sucesso de um processo de mudanca organizacional.O segundo ponto e que o senso de urgencia pode estar baixo, a complacencia pode ter se espalhado e o momento simplesmente nao permite que voce faca mais alguma coisa para tirar o projeto de mudanca da inercia. E se o senso de urgencia esta baixo, pouca coisa podera ser mudada. Existem alguns termometros que devem ser utilizados para medir o senso de urgencia.Se voce esta conseguindo extinguir com facilidade pequenas picuinhas, problemas rasos, existe algum senso de urgencia. Se nao consegue, o senso de urgencia e zero. Se consegue resolver com facilidade alguns problemas no nivel gerencial, seu senso de urgencia esta elevado. Se nao, o nivel esta baixo, mas ainda pode existir. Se voce consegue resolver problemas envolvendo o top management e a empresa como um todo, o senso de urgencia esta elevadissimo e se for mantido assim, existem grandes chances da transicao fluir sem problemas ate o fim.Um exemplo deste ultimo caso e a questao do bonus por meritocracia e a supervalorizacao das motivacoes extrinsecas. Se a transicao estiver com senso de urgencia suficiente na visao "se tornar a melhor empresa para se trabalhar no ramo que atuamos para assim atrair os melhores profissionais do mercado" a guiding coalition conseguira mexer neste ponto tao delicado. Entretanto, se a visao estiver mal definida, mal comunicada ou nem existir, fica dificil elevar o senso de urgencia. Sem senso de urgencia, atividades ludicas poderao ser vistas como palhacada.E dificil entrar neste assunto sem tentar analisar o que e falhar em um projeto de transicao. Tecnicamente e nao completar o projeto. Mas, filosoficamente, sera que poderemos considerar uma falha, caso uma semente muito forte tenha sido plantada, que podera germinar com forca para completar o projeto um, dois anos depois?Fica a reflexao. Ha algumas semanas, coloquei em pratica uma iniciativa que me martelava desde que li a primeira pagina do livro do Don Reinertsen - The Principles of Product Development Flow: Second Generation Lean Product Development - O Custo Medio Por Demanda.O conceito em si e muito simples.TL;DR: Defina o que voce precisa medir de custo por semana (incluindo sempre o custo do time de desenvolvimento) e divida pela quantidade de demandas entregues
naquela semana.CMD = $ Semana / TH da Semana$ Semana == Custo da SemanaTH da Semana == throughput == entregas na semanaSimples, hein?Nos preparar para o estado em que calcular este valor se torna simples e onde reside a dificuldade. Outra dificuldade que costumo encontrar e mostrar as pessoas como usar essa ferramenta de forma eficiente.Para chegarmos no estado em que essa formula sera util para a sua empresa, precisamos aprender e compreender a teoria dos sistemas, a teoria das restricoes e, talvez o mais dificil, passar a olhar e metrificar as coisas certas, no momento certo. Infelizmente, no mundo corporativo de hoje, as pessoas teimam em dar maior foco a controle e a metrificar grandes batches, aka, requisitos funcionais. Vamos ver o que podemos fazer com relacao a isso.Don Reinertsen criou e evoluiu um excelente framework economico no livro citado no inicio desse artigo. Ao nos presentear com essa obra ele nos diz: vamos parar de usar metricas proxy como pontos de alavancagem ou como justificativa para esses pontos de alavancagem no sistema. O que sao metricas proxy? Lead time, cycle time e throughput. Metricas essas super valorizadas, de forma justa, pelo pessoal do Lean (faco parte "desse pessoal"). E pelo que pudemos observar no inicio deste post, que fala sobre uma metrica final, elas sao muito importantes. A formula usa diretamente o throughput. O que esta errado entao no que as empresas Lean ja fazem hoje? Parar no throughput.E sobre as metricas da gestao 1.0? Nao servem para nada aqui. Controle de horas e uma grande entrega em grandes lotes no final de grandes ciclos nao nos ajudam em nada, nao nos mostram pontos de alavancagem, nao nos mostram oportunidades de otimizacao. Assim como o Gantt Chart, que tambem e inutil aqui. Chega no final do projeto, todos os gestores tradicionais ajoelham no milho com o cliente sobre os atrasos, sobre os bugs, sobre o que ficou para tras. Mandam um grande "UFA" depois dessa reuniao e fazem uma festa para comemorar o "sucesso" do projeto. Isso geralmente da certo, porque nesses casos, o cliente nao esta muito preocupado com o sucesso do produto, mas apenas em encontrar uma forma de mascarar os numeros e obter uma promocao ou aumento. E o ciclo vicioso recomeca no projeto seguinte.Isso pode funcionar em grandes empresas, com diversas camadas de gestao, que pouco se importam com o resultado final. Empresas em que o grande objetivo e ser promovido e "crescer" na carreira. Mas isso e fatal para as empresas que precisam do resultado e que, principalmente, querem o resultado. Querem um produto de qualidade entregue, se possivel antes do prazo. Querem estar dentro do processo e nao apenas passar para frente e lavar as maos. Empresas em que sua sobrevivencia depende do produto e nao onde o produto (ou numeros mascarados) servem apenas como alavanca pessoal. Se voce esta em uma empresa onde controle de horas, chicote e Gantt Chart sao as ferramentas principais, definitivamente esse post e essa ferramenta nao e para voce. Peco desculpas por apenas agora ter dito isso. Um
bom resto de dia para voce.Aos que ficaram, por que esta errado parar no throughput? Por que medir lead time e throughput nao e suficiente?Agora e que a diversao comeca.Vamos comecar pelo grafico de uma das empresas onde eu ja implantei o CMD.Uma observacao: Forjei essa ferramenta com o nome de Ticket Medio, fazendo um paralelo com a industria do entretenimento, que foi de onde eu tirei a ideia. Apesar de dias depois tentar entrar com o nome mais compativel, Custo Medio por Demanda, o nome Ticket Medio ja tinha pego com muita forca e as minhas tentativas de mudar foram em vao. Entao o mercado vai decidir esse nome. O conceito e mais importante, mas precisamos comunicar a ideia corretamente. Vamos decidir juntos se Ticket Medio e tao ruim assim. =)Chega de bla bla bla.Este grafico mostra a variacao do TM em uma das empresas onde foi implantado. A linha azul representa o TM por demanda. A linha vermelha e o TM por story points. O TM foi implantado na semana do dia 14/09. Como tinhamos os dados passados, fiz tambem um calculo retroativo. Observem a forma erratica das series ate a semana do dia 07. O grafico acima e de um produto.Nessa empresa, o impacto da visibilidade do nosso custo semanal foi imediato. Na apresentacao da metrica, que ocorreu em uma quarta de uma semana com TH baixo, precisei explicar pouco as consequencias de um alto TM. Isso criou um ponto de alavancagem de imediato e que se mostrou extremamente eficiente: o time passou a tomar melhores decisoes no dia a dia. Aquele refactoring que no final vai agradar apenas ao desenvolvedor, passou a ficar para depois. Aquela tomada de decisao que levava dias, passou a ser realizada na dimensao de minutos. Agora, quando um desenvolvedor esta a muito tempo em uma tarefa, com as ideias bloqueadas, ele quase imediatamente chama o time, em vez de esperar 1 ou 2 dias. Essa mudanca de comportamento, nas decisoes do dia a dia, no minuto a minuto, tiveram um impacto estrondoso na "quantidade de demandas entregues X dinheiro que esta sendo investido". Muito mais que o ganho financeiro nos custos, teremos o nosso produto pronto muito mais rapido, reduzindo nosso custo de atraso e fazendo com que a empresa ganhe dinheiro mais rapido.E possivel perceber a teoria dos sistemas em seu estado mais puro aqui? Derivamos algumas formulas, falamos de custo e chegamos no lucro como objetivo principal. Como eu disse, nessa empresa nao foi necessario discorrer por longos minutos sobre os impactos de um alto TM, e muito menos falamos algo parecido com: precisamos aumentar e estabilizar nosso throughput. Simplesmente aconteceu.Outra caracteristica que achei muito interessante nessa iniciativa foi que quase todos os numeros ja estavam disponiveis. Os que nao estavam, poderiam ser perguntados, como eu fiz para comecar esse trabalho. Mas eles estavam invisiveis, portanto, eram inuteis.Mas o que fazer quando a empresa nao reage positivamente as primeiras explicacoes sobre as implicacoes financeiras das mas decisoes? Bem, nesse caso, precisamos nos aprofundar mais nos impactos.Em outra empresa, outra iniciativa, outro
com maca. Ou pera com maca quando sao parecidos. O importante e notar que ao comparar dois projetos, voce nunca estara comparando maca com maca. Nunca.O que e preciso?Medir o TH de forma pratica, eficiente e estavel;Para isso precisamos garantir a homogeneidade entre as demandas e que as coisas grandes sejam realmente excessoes no fluxo;Se usa story points, meca o TM absoluto (por demanda) e o TM dos pontos. Coloque os dois no mesmo grafico e acompanhe a evolucao. Se a evolucao das duas linhas estiver proxima, talvez seja um indicio para remocao das story points. TM ajudando em uma tomada de decisao, mais uma vez de forma cientifica;Tenha os dados de cada semana como em uma fotografia semanal. Nao perca os dados de outra semana. Nao remova as informacoes pertinentes aquela semana. O motivo esta nos dois proximos pontos;Mantenha estavel a sua logica para o calculo do custo semanal ate o fim do projeto. Isso quer dizer que se voce considera so o salario dos desenvolvedores, mantenha assim ate o final. Se voce considera os custos completos (github, code climate, luz, agua, telefone, gas...) faca assim ate o final. Nao vai fazer diferenca para o proposito do TM se voce considera essas dimensoes ou nao, porque o que importa e o fator comparativo entre as semanas. Se comecou de um jeito, va assim ate o final;Considere sempre a variacao no time. Em uma semana, entrou um novo dev em um dos times de uma das empresas (vago huh? =) ). Ele entrou na quinta, assim adicionei na planilha 2/5 do custo semanal dele. Na semana seguinte, o custo total semanal foi considerado.E o proposito dessa ferramenta?Ajudar as pessoas envolvidas em processo de desenvolvimento de software (ainda nao sei se da para portar para outras areas) a tomar melhores decisoes no dia a dia, da hora em que levanta a hora que vai se deitar. Uma consequencia direta de melhores decisoes, mais que entregar mais, e a estabilizacao do sistema. E impressionante como todas as decisoes que emergiram dos desenvolvedores a partir da implantacao fizeram o sistema caminhar para essa estabilizacao (vide o grafico de exemplo). Isso eu pude perceber nas duas iniciativas usadas aqui como exemplo. Uma mais cedo e a outra um pouco mais tarde.EDIT: Tambem emergiram decisoes interessantes por toda a empresa, mas como possuem impactos de longo prazo, ainda estamos estudando os efeitos.E estabilizacao traz previsibilidade.Uma consequencia inesperada foi o transporte do uso do TM para outras areas de uma das empresas. Essa experiencia se encontra ainda em estado embrionario e podera ajudar na resposta se podemos ou nao portar para outras areas. Mas ja adianto que parece que isso ajudou muito no comercial, fazendo as pessoas focarem nas vendas certas e reduzir a perda de dinheiro com clientes que nao valiam a pena. Nada como a visibilidade do taximetro. =)Mas ainda existem dois propositos secundarios: Usar uma forma cientifica de encontrar pontos de alavancagem e extinguir o determinismo da gestao, a trazendo para o lado cientifico da coisa.Celso, quando posso usar essa parada?Assim que voce achar necessario.
So deixe-me saber como esta e como esta evoluindo. Tambem pode gritar em caso de duvidas. Estou estruturando consultoria em cima disso, entao caso tenha interesse, me contacte tambem. Bora tornar o desenvolvimento de software no Brasil mais eficiente. Chega das rodas enferrujadas da engrenagem da gestao antiga.Estarei no AgileBrazil na proxima semana e o meu proposito com esse post e fundamentar um monte de conversas que ja estao marcadas para Porto de Galinhas. Se voce estiver por la, nao deixe de me chamar para bater um papo. Vou adorar. =)Essa e a primeira versao estruturada dessa ferramenta, portanto aceito feedbacks e debates. O que eu nao vi? O que estou perdendo? Como podemos evoluir isso?Ha muito tempo, um grande amigo de olho puxado me disse: "Gestores dizendo que as coisas nao fluem porque as pessoas nao se esforcam e um diagnostico simplista, preguicoso e fora da realidade."O nome desse amigo e Rodrigo Yoshima.Essa frase esta ultrapassando a barreira do tempo e continua muito valida hoje em dia.Amplie suas capacidades de visao e de analise. Voce nao vai se arrepender e o sistema "Sua Empresa" colhera rapidamente os beneficios dessa mudanca de mindset.No exemplo que dei do TM alto, nao era esforco que faltava, mas melhores decisoes.Saia do determinismo e entenda o seu sistema.
Eu juro que eu nao planejava escrever sobre a Lei de Little novamente quando fui deitar no sabado e eu nao planejava um texto domingo de manha, antes de sair para comprar a carne do churrasco para ver o meu Flamengo massacrar o Sao Paulo pelo Campeonato Brasileiro. Mas o twitter ficou pequeno novamente, entao vamos la.Como voces ja repararam na introducao, nao esperem nada muito formal, de metricas, palavras chaves, SEO para blog and so on. Se algo ficar confuso, senta o dedo nos comentarios. =)Eu iria usar o meu texto anterior sobre o assunto, pois ainda concordo com cada linha do que esta la, mas percebi que faltava algo.As taxas. La eu comento sobre a inexistencia do equilibrio entre as taxas de entrada e de saida de um sistema complexo. Entretanto, por incrivel que pareca, parece que uma das confusoes esta no termo taxa. Taxa e:Uma taxa e uma relacao entre duas grandezas. Trata-se de um coeficiente que exprime a relacao existente entre uma quantidade e a frequencia de um fenomeno. Exemplos de fenomenos: clientes querendo comer (restaurante), clientes querendo falar com o gerente (banco) ou ideias sendo desenvolvidas (desenvolvimento de produto). A Lei de Little foi estabelecida para casos semelhantes aos dois primeiros fenomenos. Nos tempos atuais, as pessoas transferiram e adaptaram a Lei de Little pra o terceiro fenomeno. So se esqueceram de um detalhe. No desenvolvimento de produtos (onde fluem ideias e/ou demandas), nao existe o equilibrio entre a taxa de entrada e de saida. Um restaurante ou um banco possui horario de funcionamento. Voce consegue facilmente fechar a frequencia do fenomeno dentro deste espaco. Alem disso, esta previsibilidade de funcionamento faz com que as taxas diarias possam facilmente ser replicadas para uma taxa semanal, mensal, semestral ou anual, permitindo o estudo do sistema por diferentes perspectivas. Eu gostaria muito que me trouxessem dados provando que em desenvolvimento de produtos e sequer possivel fechar a frequencia do fenomeno, assim como dados que provem que dentro deste fechamento de frequencia, a entrada foi igual a saida. Esta lancado o desafio.Desprezar isso ao adaptar a Lei de Little e possivel, como era possivel desprezar o atrito com o solo e a resistencia do ar nas equacoes durante o ensino medio. Acontece que, depois que entramos na faculdade, nao fica mais tao simples desprezar atrito. Na vida real, desprezar o atrito pode ser fatal. Onde eu quero chegar? Nao acho que desprezar o atrito "sistema em equilibrio" possa ser tao catastrofico para a adaptacao da Lei de Little aos sistemas complexos. O que eu acho perigoso e esquecermos desta adaptacao e usarmos a lei como verdade absoluta nas nossas analises e decisoes.Como diz um grande amigo, realidade e briga de rua!Alem disso, para fechar e eu poder ir comprar a materia prima do meu churrasco, a comunidade Kanban hoje esta discutindo se realmente temos filas dentro de um sistema Kanban. O argumento principal e de que nao temos disciplina de fila, portanto temos buffers. E ai eu pergunto:E possivel ter Little sem filas, apenas com buffers? Como Little se aplicaria
a um sistema sem disciplina de fila?Juro que eu acabei de pensar nisso, relacionando Little ao questionamento atual da comunidade Kanban. Em uma primeira analise, juntando o que eu sei de teoria das filas, lei de little e de comportamento de buffers, eu diria que a Lei de Little nao faz mais o menor sentido. Novos fatos tendem a modificar a minha opiniao e tenho certeza de que novos fatos surgiram depois deste despretensioso post.E ai? Ja pensou nisso? A area de comentarios e toda sua!