Mostrando postagens com marcador complexidade. Mostrar todas as postagens
Mostrando postagens com marcador complexidade. Mostrar todas as postagens

domingo, 19 de junho de 2016

Lei de Little - Sobre as taxas e buffers

Eu juro que eu não planejava escrever sobre a Lei de Little novamente quando fui deitar no sábado e eu não planejava um texto domingo de manhã, antes de sair para comprar a carne do churrasco para ver o meu Flamengo massacrar o São Paulo pelo Campeonato Brasileiro. Mas o twitter ficou pequeno novamente, então vamos lá.

Como vocês já repararam na introdução, não esperem nada muito formal, de métricas, palavras chaves, SEO para blog and so on. Se algo ficar confuso, senta o dedo nos comentários. =)

Eu iria usar o meu texto anterior sobre o assunto, pois ainda concordo com cada linha do que está lá, mas percebi que faltava algo.

As taxas. Lá eu comento sobre a inexistência do equilíbrio entre as taxas de entrada e de saída de um sistema complexo. Entretanto, por incrível que pareça, parece que uma das confusões está no termo taxa. Taxa é:

Uma taxa é uma relação entre duas grandezas. Trata-se de um coeficiente que exprime a relação existente entre uma quantidade e a frequência de um fenómeno. 

Exemplos de fenômenos: clientes querendo comer (restaurante), clientes querendo falar com o gerente (banco) ou idéias sendo desenvolvidas (desenvolvimento de produto). A Lei de Little foi estabelecida para casos semelhantes aos dois primeiros fenômenos. Nos tempos atuais, as pessoas transferiram e adaptaram a Lei de Little pra o terceiro fenômeno. Só se esqueceram de um detalhe. No desenvolvimento de produtos (onde fluem idéias e/ou demandas), não existe o equilíbrio entre a taxa de entrada e de saída. Um restaurante ou um banco possui horário de funcionamento. Você consegue facilmente fechar a frequência do fenômeno dentro deste espaço. Além disso, esta previsibilidade de funcionamento faz com que as taxas diárias 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 é sequer possível fechar a frequência do fenômeno, assim como dados que provem que dentro deste fechamento de frequencia, a entrada foi igual a saída. Está lançado o desafio.

Desprezar isso ao adaptar a Lei de Little é possível, como era possível desprezar o atrito com o solo e a resistência do ar nas equações durante o ensino médio. Acontece que, depois que entramos na faculdade, não fica mais tão simples desprezar atrito. Na vida real, desprezar o atrito pode ser fatal. Onde eu quero chegar? Não acho que desprezar o atrito "sistema em equilíbrio" possa ser tão catastrófico para a adaptação da Lei de Little aos sistemas complexos. O que eu acho perigoso é esquecermos desta adaptação e usarmos a lei como verdade absoluta nas nossas análises e decisões.

Como diz um grande amigo, realidade é briga de rua!

Além disso, para fechar e eu poder ir comprar a matéria prima do meu churrasco, a comunidade Kanban hoje está discutindo se realmente temos filas dentro de um sistema Kanban. O argumento principal é de que não temos disciplina de fila, portanto temos buffers. E aí eu pergunto:

É possível 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 análise, juntando o que eu sei de teoria das filas, lei de little e de comportamento de buffers, eu diria que a Lei de Little não faz mais o menor sentido. Novos fatos tendem a modificar a minha opinião e tenho certeza de que novos fatos surgiram depois deste despretensioso post.

E aí? Já pensou nisso? A área de comentários é toda sua!

terça-feira, 2 de julho de 2013

Rapidinha - Será que você sabe o que é um silo?

Hoje vi algo que me deixou preocupado. Em uma comunidade que fala de agilidade, vi o assunto silo surgir de uma forma estranha. Silos em nada se parece com divisão de frentes de trabalho. Silos não se comunicam, silos são isolados. Divisão em frentes de trabalho é uma forma de lidar com a complexidade: descentralização.

Quando estamos lidando com sistemas complexos, quanto mais centralizamos decisões e ações, caminhamos a passos largos para o caos. Da mesma forma, se você acredita que ser multidisciplinar é ter um bolo de atividades e um bolo de pessoas "puxando", você também me parece caminhar a passos largos para o caos.

Multidisciplinaridade pode (e deve) acontecer com frentes de trabalho. Trazendo um pouco dos conceitos do Kanban para este post, se temos um limite ideal do work-in-progress, alguém ficou ocioso e não pode puxar mais nenhuma atividade, esse alguém vai ajudar na etapa do processo onde o gargalo apareceu. Essa técnica também tem um pé na teoria das restrições:
  1. Identify the system's constraint(s) (that which prevents the organization from obtaining more of the goal in a unit of time)
  2. Decide how to exploit the system's constraint(s) (how to get the most out of the constraint)
  3. Subordinate everything else to the above decision (align the whole system or organization to support the decision made above)
  4. Elevate the system's constraint(s) (make other major changes needed to increase the constraint's capacity)
  5. Warning! If in the previous steps a constraint has been broken, go back to step 1, but do not allow inertia to cause a system's constraint.
Descentralizar, atuando em várias frentes, é uma forma de lidar com a complexidade e não de formar silos. Os silos são "entidades" isoladas. Cuidado com as crenças limitantes. O conceito depende de contexto. Cuidado com os sempres e nuncas, mesmo implícitos.

Como eu prometi, esse post seria uma rapidinha. Discussões serão muito bem vindas nos comentários.

Até a próxima.

sábado, 16 de março de 2013

Os passos para uma transição ágil

Muito se fala sobre agilidade, principalmente desde o manifesto. As pessoas já vinham há uma década buscando formas diferentes de desenvolver software, como Scrum e a Extreme Programming. Mas em 2001, o conhecimento da época foi "verbalizado" pelo manifesto, na forma de 4 valores e 12 princípios.

Não, esse não é mais um texto sobre agilidade e seus princípios. Percebi que muito barulho foi feito em cima dessa nova forma de desenvolver software, muitas empresas nasceram ágeis, mas muito pouco foi falado sobre como realizar uma transição do modelo tradicional para o modelo ágil.

segunda-feira, 27 de agosto de 2012

O Poder da Iteração

Depois de um pouco mais de um ano com o meu cliente que trabalha com gerenciamento de risco, rastreamento de frotas por GPS, estou aos poucos conseguindo demonstrar o poder do desenvolvimento iterativo. Neste sistema estamos, gradualmente, aumentando o nosso amadurecimento nos processos ágeis. Sim, não adianta apenas uma pessoa ser experiente em determinado assunto. O que importa é o time. O todo não é a soma das partes, mas a soma da interação entre elas.