Pensamento Sistêmico

“Não importa o que fazemos, o número de defeitos em nosso backlog permanece o mesmo”, um gerente nos disse; Isso para um produto de 15 MSLOC C e C ++ com várias centenas de desenvolvedores onde estávamos trabalhando. O que está acontecendo? O pensamento sistêmico pode ajudar. Em pequenos grupos, as forças em jogo são mais rapidamente vistas e entendidas informalmente, mas no desenvolvimento de grandes produtos — ou qualquer grande sistema — é difícil. Gerry Weinberg destaca dois fatores decisivos nesta situação:

Lei de Weinberg-Brooks: Mais projetos de software têm ido longe demais através da tomada de decisão da gerência baseada em modelos ** incorretos do sistema ** do que todas as outras causas combinadas.

Falácia da Causa: Cada efeito tem uma causa … e podemos dizer qual é qual. [Weinberg92]

Isto reflete o impacto de nossos modelos mentais no sistema, um assunto que será revisitado mais adiante nesta seção.

Problemas decorrentes de modelos mentais e suposições são uma questão. Outra questão é que a adoção em grande escala do Scrum, do pensamento enxuto e dos princípios ágeis não estão isoladas somente no grupo de desenvolvimento. Eles colidem com o gerenciamento de produtos, orçamentação, teste beta, lançamento e políticas de governança e RH. Consequentemente, na adoção ágil em larga escala, é útil ser capaz de se reunir com colegas e efetivamente raciocinar sobre os modelos mentais, relações causais, loops de feedback e mecanismos de controle (ou ilusões de controle) em um grande sistema que está prestes a ser seriamente perturbado. O pensamento sistêmico é uma dessas ferramentas de raciocínio.

Em 1958, o Harvard Business Review publicou “Industrial Dynamics: A Major Breakthrough for Decision Makers,”, um documento histórico de Jay Forrester, professor da MIT Sloan School. Este artigo estimulou o movimento do pensamento sistêmico na educação comercial, e a MIT Sloan School of Management tornou-se conhecida por educar pessoas em sistemas dinâmicos. Os sistemas dinâmicos às vezes são tratados como sinônimo de pensamento sistêmico, embora o último seja um termo mais genérico.

O MIT também atraiu outros pesquisadores orientados a sistemas dinâmicos, como Peter Senge.¹

Em consonância com Lei de Weinberg-Brook, a pesquisa da Forrester mostrou que os tomadores de decisão que receberam modelos dinâmicos de um sistema de negócios e pediram para melhorar o desempenho de seus resultados, geralmente os pioravam [SKRRS94]. A observação foi de que a maioria das pessoas ppssui um julgamento fraco sobre como melhorar fundamentalmente os sistemas, geralmente aplicando “soluções comuns” de “senso comum” e “soluções rápidas” que não criam melhorias sistêmicas duradouras.

Por que o comportamento de um grande grupo de desenvolvimento (um sistema) não é entendido ou guiado com habilidade? A resposta reside, em parte, no comportamento de sistemas estocásticos com filas e variabilidade, conforme explorado no princípio de LeSS sobre a Teoria das Filas . E a mesma resposta reside na teoria do controle: a maioria dos sistemas de interesse, como um grupo de desenvolvimento de produtos, tem complexos laços de feedback positivos e negativos e comportamento não-linear. O comportamento desses sistemas desafia nosso instinto. E então há a questão menor sobre pessoas.

Em resumo, os motivos que não habilitam em melhorar ou orientar um grande sistema incluem (mas não estão limitados a):

• Falta de conhecimento sobre a dinâmica do sistema, os loops de feedback, o comportamento dos sistemas não-lineares e as consequências não intencionais nos sistemas no local de trabalho
• Não compreender as causas raiz de problemas (e como encontrar)
  • causas, não causa; No pensamento sistêmico, assume-se que existem causas múltiplas, indiretas e dinâmicas para problemas
• Não saber se ou por que as decisões rápidas ou de departamento local degradam o desempenho geral de entrega.
  
  
  
  

Em resumo, não são pensadores sistêmicos.²

Essas razões são consequentes na interseção entre gerenciamento e adoção em larga escala de princípios enxutos e ágeis. A equipe de liderança faz parte do sistema sendo perturbado; Se eles não aplicam pensamento sistêmico, eles realmente podem perturbá-lo — e não de uma maneira boa!

Como um resumo da visão de pensamento sistêmico, nós gostamos das 11 “leis” descritas em The Fifth Discipline:

• Os problemas de hoje provêm das “soluções” de ontem.
• Quanto mais forte você empurra, mais forte o sistema empurra de volta.
• O comportamento piorará antes de começar a melhorar.
• A saída fácil geralmente traz o problema de volta.
• A cura pode ser pior do que a doença.
• Mais rápido é mais lento.
• Causa e efeito não estão intimamente relacionados no tempo e no espaço.
• Pequenas mudanças podem produzir grandes resultados … mas as áreas de maior alavancagem são muitas vezes as menos óbvias.
• Você pode ter seu bolo e comê-lo também — mas não todos de uma só vez.
• Dividir um elefante pela metade não produz dois elefantes pequenos.
• Não há culpa.

O lema interno da Toyota é “Bons pensamentos, bons produtos.” Pensamento sistêmico é um conjunto de ferramentas de pensamento para ajudar…

• veja sistemas dinâmicos—uma organização de desenvolvimento é um sistema de pessoas e políticas com loops de feedback sutis e consequências não desejadas
  • Podemos aprender a ver e assim melhorar o sistema com diagramas de loop causal criados em uma oficina
• veja modelos mentais—razões por trás das decisões sub-otimizadas são suposições e raciocínios equivocados
  • Diagrama de loop causal e Cinco Por Ques expõem isto
• veja otimização local—Outra origem de decisões sub-otimizadas é a otimização local , tomando a “melhor” decisão sob o ponto de vista de uma pessoa ou departamento, ao invés da otimização global para o objetivo enxuto em nível de sistemas de entreguar valor rapidamente com alta qualidade e moral alto .
  
  
  
  

Esta introdução é organizada em torno das seguintes áreas no pensamento sistêmico: Aprender a ver (1) sistemas dinâmicos , (2) modelos mentais , (3) causas raiz , e (4) otimização local .

Ver os Sistemas Dinâmicos: Introdução

Complexidade Estática versus Dinâmica

Muitos de nós, especialmente em engenharia e finanças, somos educados para dominar a complexidade de detalhes estáticos — aprender a analisar e gerenciar informações (requisitos, análise financeira, …), decompor estruturas complexas em mais simples e assim por diante. Ou seja, a complexidade de uma natureza estática, de informação ou estrutural.

Por que os grandes sistemas de software tendem a degradar, com cada vez mais tempo gasto em defeitos? O que poderia acontecer se os EUA invadir o Iraque? Ver a dinâmica por trás dessas questões envolve a análise da complexidade das dinâmicas.

Em contraste com a educação de detalhes estáticos, muitos de nós não recebemos educação formal na análise de complexidades dinâmicas³, especialmente a dinâmica do local de trabalho. Talvez exista uma crença que é suficiente confiar no senso comum no local de trabalho. A Forrester demonstrou que o “senso comum” não é tão simples em sistemas complexos e mostrou que é possível educar formalmente as pessoas para que se tornem melhores pensadores da dinâmica do sistema no local de trabalho usando modelos de sistemas dinâmicos visualizados em diagramas de fluxo [[Forrester61]] (Http://www.amazon.com/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ref=sr_1_1?ie=UTF8&qid=1413582840&sr=8-1&keywords=Industrial+Dynamics).

Os diagramas de fluxo abrangem fluxos materiais, financeiros e de informação, estoques (variáveis ​​com uma quantidade, como dinheiro ou número de defeitos), o impacto de decisões e políticas e relações de causa e efeito. Uma simplificação popular é o diagrama de loop causal que se concentra em relacionamentos de causa-efeito e loops de feedback em um sistema [Sterman00]. Há uma variedade de notações similares; Todos elas mostram ações (variáveis), ligações causais e atrasos. Em [Weinberg92] isso é chamado de diagrama de efeito.

A Primeira Lei da Diagramação: modele para conversar

Uma ferramenta para aprender a ver a sistemas dinâmicos é um diagrama de loop causal, idealmente esboçado em um quadro branco em uma Retrospectiva Geral do LeSS com colegas. Antes de ir mais longe, aqui está a Primeira Lei de Diagramação

O valor primário nos diagramas está na discussão enquanto diagramamos - nós modelamos para ter uma conversa.

Quando um grupo se junta para esboçar um diagrama de loop causal em um quadro branco (Veja os atos de discussão e pensamento que são mais importantes quando se faz diagramação, Valtech Índia.), o valor primário é a conversa e a compreensão compartilhada que eles chegam enquanto estão criando o modelo. Sua visualização como um diagrama fácil de ver é importante para tornar concretas e inequívocas as ideias (no quadro branco) -os modelos mentais das pessoas- porque as palavras podem ser confusas e incompreendidas. Mas ainda assim, o diagrama é secundário para o que as pessoas adquirem: aprendizado e um entendimento revisado através de uma discussão.

Dica concreta de modelagem: começamos escrevendo em notas adesivas para definir variáveis​​. Uma nota pode ter “velocidade da funcionalidade” ou “nro. de defeitos”. Colocamos estas notas em um quadro branco. Então, esboçamos as linhas de ligação causal entre as notas adesivas. Haverá (ou deveria ter) muita reescrita, apagamento e redesenho durante a sessão de modelagem. O resultado mais significativo é a compreensão; Além disso, alguns participantes vão querer tirar uma foto digital do esboço do quadro branco.

Ver os Sistemas Dinâmicos: Diagramas de Loop Casual

Os diagramas de loop causais são usados ​​regularmente nas introduções ao LeSS, para ajudar a ver a dinâmica do que está acontecendo no desenvolvimento em grande escala. É útil compreendê-los por esse motivo. E para ser mais útil para você, recomendamos que você faça isso junto com colegas em um quadro branco. Modele para conversar. Quando? Provavelmente durante uma Retrospectiva Geral do LeSS.

O aspecto prático desta dica é mais importante do que somente aprecia-la. É vago e de baixo impacto sugerir “ser um pensador sistêmico”. Mas se você e quatro colegas tiverem o hábito de ficar juntos em um grande quadro branco, esboçando diagramas de loops causais juntos, então há uma prática de impacto concreto e potencialmente alto que conecta “ser um pensador sistêmico” com “realizar pensamento sistêmico”.

Os seguintes exemplos parecem estéreis quando apresentados em um livro. Mas imagine que você estava em um quadro branco com outras pessoas e os diagramas foram esboçados durante uma conversa animada. É assim que sugerimos “realizar” pensamento sistêmico.

Notação e exemplos

Os diagramas de loops causais contêm muitos elementos; o seguinte subconjunto será explorado através de um cenário.

• Variáveis
• Ligações causais
• Efeitos opostos
• Restrições
• Metas
• Reações; Reações rápidas
• Efeitos de interação
• Efeitos extremos
• Atrasos
• Loops de feedback positivo

O seguinte cenário simplificado é para uma determinada organização. Não é uma generalização.

Variáveis​​ {: style = “color: # 1997C0”} — Os diagramas de loop causais incluem variáveis​​ (ou estoques), como velocidade (taxa de entrega) das funcionalidades do software e número de defeitos . As variáveis ​​têm uma quantidade mensurável.

Ligações causais {: style = “color: # 1997C0”} — Um elemento pode ter um efeito sobre outro, como se a velocidade da funcionalidade aumentar e o número de defeitos aumentar também; Ou seja, mais código novo, mais defeitos.

Agora é hora de se deparar com Lei de Weinberg-Brook e a Falácia da Causação. É fácil esboçar um diagrama; É algo mais que modelar uma visão. Por exemplo, considere a relação entre a quantidade de desenvolvedores e a velocidade da funcionalidade.

A natureza de qualquer relação causa-efeito na verdade não é óbvia, embora seja comum que as pessoas tirem conclusões, como por exemplo, mais desenvolvedores significa melhor velocidade. Adicionar pessoas durante o desenvolvimento pode reduzir a velocidade (um sub-elemento de “Lei de Brooks” [Brooks95]). Ou, mais programadores ruins podem realmente diminuí-la. Um argumento pode ser utilizado é remover desenvolvedores terríveis podem melhorar velocidade.

Efeitos opostos {: style = “color: # 1997C0”} — Um efeito de ligação causal pode estar na mesma direção ou em direção oposta; Se A subir, então B sobe, ou vice-versa. O efeito oposto é mostrado com um ‘O’ na linha. Suponha que os defeitos que subam coloquem um atraso no sistema, diminuindo a velocidade das novas funcionalidades porque as pessoas passam mais tempo consertando ou a trabalhando em torno de erros.

Restrições {: style = “color: # 1997C0”} — A menos que você possa encontrar pessoas para trabalhar de graça, há uma restrição na quantidade de desenvolvedores, com base no fornecimento de verba.

As restrições não são ligações causais. À medida que o fornecimento de verba aumenta, não significa que a quantidade de desenvolvedores irá aumentar.

Metas e Reações {: style = “color: # 1997C0”} - Pessoas, departamentos e sistemas têm metas, como maior velocidade da funcionalidade. As metas geralmente geram pressão para que as pessoas reajam (ou ajam), com a intenção de alcançar a meta. Mas, como existe a Falácia da Causação e a Lei de Weinberg-Brooks para lidar, as pessoas devem ser cautelosas ao assumir quais ações ajudarão. Agora, uma meta e uma pressão para a reação são mostrados:

Uma meta com recompensa não somente cria pressão para agir, mas também cria pressão para mostrar atuação e resultados, devido à medição de disfunção gerada por recompensas. E a medição de disfunção de pode ser proporcional ao valor percebido da recompensa porque as pessoas estão sendo motivadas a obter uma recompensa, e não a melhorar o sistema [Austin96]. Observe como as recompensas podem realmente degradar o desempenho do sistema. Visualmente, a dinâmica do sistema pode ser ..

É bastante interessante que todas essas dinâmicas tenham sido adicionadas pela introdução da recompensa, e ainda não há conexão necessária entre a parte superior desse modelo e a parte inferior.

Não há garantia de que a velocidade da funcionalidade tenha melhorado — ou mesmo tenha sido trabalhada.

A remoção do sistema de recompensa é uma solução de causa raiz da disfunção. Outra contramedida (menor) é o princípio Saia e Veja do pensamento enxuto (ver o que realmente acontece no local de trabalho) e do comportamento da gestão:

Reações de solução rápida {: style = “color: # 1997C0”} — Uma solução difícil e lenta para o objetivo de maior velocidade é contratar grandes desenvolvedores, aumentar o treinamento e a educação do pessoal existente e Rrmover trabalhadores terríveis. A alternativa é chamada de solução rápida, uma reação que espera alcançar o objetivo rapidamente e com menos esforço. Às vezes, uma solução rápida funciona bem no curto e longo prazo, realmente fortalecendo o sistema. Às vezes, não … daí, “mais rápido é mais lento”. Por exemplo, as pessoas podem acreditar que aumentar o número de desenvolvedores aumenta a velocidade da funcionalidade. E elas podem, assim, desejar que a contratação de mais desenvolvedores solucione o problema da velocidade de forma mais rápida e fácil. ‘QF’ indica a solução rápida:

Efeitos de interação {: style = “color: # 1997C0”} — Existe a restrição do fornecimento de caixa na contratação. Uma solução difícil e lenta é obter mais dinheiro. Uma solução mais rápida é contratar desenvolvedores muito mais baratos. Nesse caso, o nível de fornecimento de caixa agora tem um efeito de interação com outros vínculos causais. Pouco dinheiro tende a fortalecer a taxa de contratação de desenvolvedores muito mais barato, então há pressão para aumentar as taxas de contratação.

Pode-se simplesmente desenhar um vínculo de causalidade (oposto) diretamente de fonecimento de caixa para taxa de contratação de desenvolvedores muito baratos, mas isso simplesmente diz que menos dinheiro leva a mais contratação de desenvolvedores extremamente baratos. Não é exatamente o que queremos dizer; Em vez disso, queremos mostrar o efeito de interação - esse efeito A influencia o efeito B. Isto é feito mostrando um vínculo causal entrando em outro vínculo causal. Por exemplo, de fornecimento de caixa para a linha de correção rápida entrando em taxa de contratação de desenvolvedores muito baratos:

Efeitos extremos {: style = “color: # 1997C0”} — Trabalhamos com alguns desenvolvedores muito baratos com excelente habilidade e alguns desenvolvedores muito caros que são terríveis, mas, em média, você obtém o que você paga — quando contrata de um grande grupo de mão-de-obra muito barata, o nível médio de habilidade é menor. No modelo, queremos mostrar que o impacto da contratação de mão-de-obra muito barata no número de desenvolvedores pouco qualificados é um efeito significativamente maior do que a média.

Para mostrar um efeito extremo no modelo, use uma linha grossa:

Atrasos {: style = “color: # 1997C0”} — Um problema na contratação no desenvolvimento de software é a falácia da variância do programador — a crença equivocada de que a variância do programador (em termos de produtividade, Qualidade do código, etc.) é relativamente pequena. No entanto, os estudos de variância do programador sugerem uma média de quatro vezes mais rápida no quartil superior versus o quartil inferior [[Prechelt00]] (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.4788). Um pouco significativo. Além disso, o modelo COCOMO - baseado em estudos grandes e longitudinais — mostra que a capacidade do pessoal de desenvolvimento é, de longe, o fator mais importante para a produtividade [Boehm00]. E, em média, programadores muito fracos criam código de má qualidade (design pobre) e mais defeitos, criando outro arrasto no sistema.

Mas os impactos desses efeitos não são imediatamente óbvios. Por exemplo, leva um tempo relativamente longo depois de contratar um grande grupo de programadores fracos antes que os impactos de mais e mais códigos e design incorretos começarem a ser sentidos. Da mesma forma, a média diminuição na velocidade da funcionalidade (por causa do poderoso impacto da variância do programador) não aparecerá imediatamente.

Para mostrar esses efeitos de atraso no modelo, use uma linha dupla através da linha de efeito:

O atraso tem uma influência intrigante no poder educacional ou corretivo em um sistema. Se um impacto ou consequência não intencional for atrasado, não se sente o efeito (dor ou ganho) e, portanto, não se vê claramente como A influenciou B, ou mais sutilmente como *A influenciou B que influenciou por A *.

Portanto, não se aprende ou corrige erros - na política, ações de gerenciamento, ferramentas e assim por diante. Da mesma forma, uma melhoria gradual através da prática kaizen de pensamento enxuto pode demorar muito tempo; É necessária uma paciência e uma visão para ver se e como as coisas melhoram.

Loops de feedback positivo {: style = “color: # 1997C0”} — Loops de feedback negativos ou positivos ⁵ e os atrasos são onde as coisas começam se tornar mais sutil em um sistema - e na compreensão de um sistema. Por exemplo, como se tornar um melhor programador? Em parte, por meio de tutoria de grandes programadores e vários exemplos de grande código. Mas um escritório com muitos desenvolvedores de baixa habilidade não gera muitos bons exemplos de código, nem atrai nem retém o pequeno grupo de grandes programadores que podem atuar como mentores. Eles preferem trabalhar em outro lugar.

Agora, o grupo de desenvolvimento começa a entrar em uma espiral descendente auto-reforçada — um conjunto de loops de feedback positivos. Felizmente, a tendência descendente é limitada pelo fornecimento de caixa.

Mais programadores excelentes — que poderiam criar um código excelente e orientar os outros — sairão. Portanto, há um código cada vez menor de qualidade para se identificar e aprender. A porcentagem de programadores fracos cresce ainda mais e a velocidade da funcionalidade diminui. O código torna-se mais bagunçado, estranho e duplicado, e a capacidade de implementar funcionalidades rapidamente diminui. Uma vez que a velocidade da funcionalidade está diminuindo ainda mais, há mais pressão para contratar ainda mais programadores muito baratos. Tudo isso leva a múltiplos laços de reforço positivos no sistema, por exemplo:

Dica: Você pode encontrar loops de feedback positivo ao encontrar ciclos com um número par de relacionamentos de efeito “Oposto”. Existem vários exemplos no modelo acima.

Conclusão

O cenário de exemplo é apenas isso - um exemplo. Um diagrama de loop causal pode visualizar dinâmicas ricas em um sistema de trabalho. São melhor criados por um grupo em um quadro branco.

Entender os Modelos Mentais

Os diagramas de loops causais anteriores refletem os modelos mentais das pessoas, o que pode estar errado. É interessante notar que os modelos de causalidade das pessoas são influenciados pela pontualidade (atraso) e pela qualidade do feedback no sistema.

A implicação dos “modelos mentais” é melhorar nossa habilidade meta-cognitiva para ver e questionar nossos próprios pressupostos e cadeias de raciocínio. Estamos fazendo avanços de lógica defeituosos? Isso também implica quando se trabalha com outros para discutir (pesquisar em vez de abusar) os modelos mentais de nossos colegas.

Entender estes modelos mentais é o primeiro passo; muda-los é a parte ainda mais difícil do segundo passo. Essa arte está além do alcance desta introdução, embora uma adoção bem-sucedida de LeSS deve envolver mudanças na mentalidade e visão entre muitos grupos.

Uma dica para melhor entender os modelos mentais (crenças, cadeias de inferência, …) jogando na dinâmica do sistema é fazer a seguinte pergunta durante uma oficina de modelagem e, em seguida, esboçar as respostas. “Vamos falar sobre os pressupostos por trás desse modelo. O que nós acreditamos ou assumimos em termos de fatos e efeitos que nos levaram aqui?”

As respostas são esboçadas no modelo do quadro branco, por exemplo:

Exemplo: A Dinâmica do “Mais Rápido é Mais Lento”

Com o vocabulário de soluções rápidas, atrasos, loops de feedback positivo e modelos mentais, é fascinante ver que pode haver uma melhoria aparente de curto prazo em uma variável como resultado de uma solução rápida, mas também uma degradação gradual da mesma variável - a dinâmica “mais rápido é mais lento”. Esta é uma dinâmica recorrente no local de trabalho e uma causa de fraqueza. Por isso vale a pena outra ilustração.

A história do Microsoft Word e a secreta caixa de ferramentas do desenvolvedor: um exemplo clássico da dinâmica de ‘melhoria’ a curto prazo e degradação no longo prazo é a história do primeiro lançamento do Microsoft Word para Windows [[ Spolsky04]] (http://www.amazon.com/Joel-Software-Occasionally-Developers-Designers/dp/1590593898/ref=sr_1_1?ie=UTF8&qid=1413597951&sr=8-1&keywords=Joel+on+Software). Foi lançada anos mais tarde do que desejado. Por quê? Porque os gerentes tentaram seguir o cronograma original e empurraram os desenvolvedores para atendê-lo.

A história ilustra por que pensamento ilusório é identificado como um dos desperdícios no pensamento enxuto. Neste caso, o desejo de insistir em (aparentemente) seguir um cronograma implica no equívoco ou o desejo de que as estimativas de desenvolvimento não são estimativas, mas são compromissos - um mito comum que impulsiona a degradação de um sistema.

O próximo modelo ilustra um resumo da dinâmica do que aconteceu quando os gerentes empurraram as pessoas para manterem o cronograma original e por que essa reação rápida para lentidão do progresso pareceu tornar as coisas mais rápidas no curto prazo, mas na verdade mais lentas no longo prazo. Veja a dinâmica da pressão do crongrama e a caixa de ferramentas secreta.

Como uma solução rápida, os gerentes da Microsoft exortaram, subornaram (com recompensas em potencial) e ameaçaram os desenvolvedores do Word para manter o cronograma original. Consequentemente, os desenvolvedores previsivelmente puxaram a sua secreta caixa de ferramentas de desenvolvedor — as muitas práticas relacionadas ao hackeamento do código sujo (sem testes, sem comentários, ignore defeitos conhecidos, programação de copiar-colar, design fraco, …) para aparentemente entregar uma funcionalidade mais rápido. Você vê, os desenvolvedores também possuem reações rápidas para seus problemas.

As táticas pareciam ter funcionado como magia. À medida que os gerentes pressionavam os desenvolvedores, as “funcionalidades” eram entregues mais rapidamente quando as pessoas usavam a secreta caixa de ferramentas, o que reforçava a crença de que pressionar os desenvolvedores ajudava. Mas essa aparente aceleração realmente teve um efeito tardio para tornar as coisas mais lentas, o que é explorado a seguir. Uma vez que o gerenciamento não viu rapidamente o efeito tardio da caixa de ferramentas secreta, e porque eles acreditavam que os gerentes não deveriam estar frequentemente procurando em detalhes no código-fonte ou eles próprios programadores mestres, eles não aprenderam com esta dinâmica.

Uma exploração mais detalhada da dinâmica do sistema mostra por que as coisas ficaram mais lentas a longo prazo e por que a primeira versão do Word para Windows foi lançada anos mais tarde do que o desejado, ilustrado neste modelo …

Naturalmente, muitos códigos sujos acabaram tornando as coisas mais lentas. Mais sutilmente, os desenvolvedores ignorariam a lista de erros de defeitos abertos cada vez maiores para — em vez disso — gerar novas funcionalidades. Isso levou a um longo atraso entre a criação de um defeito e sua correção. Acontece que isso aumenta significativamente a variabilidade e o tempo para corrigir um defeito por causa do efeito negativo de um bug de vida longa (por exemplo, devido a soluções alternativas e ao acoplamento) e porque os desenvolvedores esqueceram por muito tempo o contexto detalhado do código relacionado ao defeito e, portanto, precisa redescobrir lentamente esse contexto - com um código confuso e cada vez mais sujo que os rodeia.

O leitor astuto também pode notar os vários laços de feedback positivos que reforçam o ciclo de degradação; Esta é uma das razões pelas quais o produto foi lançado anos depois do previsto.

Solução? Os princípios Pare e Conserte e Saia e Veja do pensamento enxuto. Primeiro, ao invés de tentar ir mais rápido quando há problemas, os professores-gerentes encorajam as pessoas a ir mais devagar e ajudá-los a aprender a ver a dinâmica do sistema e as causas raiz e corrigir estes — para melhorar o sistema de desenvolvimento. Ao avançar mais devagar, a Toyota - os mestres do pensamento enxuto - tornou-se uma das empresas mais rápidas ao redor do mundo. Segundo, para que os gerentes vejam o verdadeiro local de trabalho para saber o que está acontecendo. O “lugar real” no desenvolvimento de software é o código, o que sugere que os gerentes de primeiro nível são mestres programadores que freqüentemente avaliam o código.

As pessoas da Microsoft não refletiram sobre a situação até depois do lançamento. Quando eles finalmente realizaram uma retrospectiva, isso levou a uma política de zero-defeitos, o que significa que a primeira prioridade era consertar erros conhecidos no código em desenvolvimento — para reduzir a zero a lista de defeitos abertos antes de escrever mais código de nova funcionalidade.

Verificando (e Ouvindo) a Otimização Local

“Todo mundo está fazendo o melhor que pode, mas a taxa de transferência dos sistemas está degradando. Como pode isso?”. Este é o paradoxo da otimização local — quando uma pessoa ou um tomador de decisão departamental otimiza para a visão local ou interesse próprio. A parte que toma a decisão com frequência acredita que está tomando a melhor decisão, mas porque “melhor” é uma otimização local que, na verdade, subotimiza o throughput geral do sistema. Isto é resultado da “mentalidade do silo”, do mal-entendido, do medo, da informação limitada, dos feedbacks tardios, da ignorância, do carreirismo, da avareza e de outros transtornos de aprendizagem organizacional comuns.

Um pequeno grupo de produtos de 30 pessoas não tem tempo ou dinheiro para se envolver em muitas bobagens ou desperdícios. Mas as grandes empresas, com grandes grupos de produtos, processos centralizados e grupos de ferramentas, um “escritório de gerenciamento de projetos” centralizado, e assim por diante, parecem ter aumentado a otimização local e o desperdício para uma forma de arte. As burocracias governamentais são o exemplo por excelência, é claro. Como tal, quando você serve como um guia na adoção ágil em larga escala, ver (ou ouvir) e lidar com a otimização local é singularmente vital.

Por exemplo, os departamentos de segurança legais e corporativos implementam uma política que parece terrivelmente importante em sua perspectiva. Com o objetivo de evitar a perda de propriedade intelectual (PI), o departamento legal decreta que “ninguém deve colocar qualquer informação nas paredes”. Ou, em resposta à pressão de redução de custos, a administração das instalações diz: “É importante garantir que nossas paredes não estão sujas ou danificadas”. E assim eles encerram uma prática em pensamento enxuto, gerenciamento visual (geralmente feito em paredes), e eles inibem uma prática bem conhecida de inovação, trabalho de quadro de grupo. Os advogados podem conseguir reduzir a perda de PI (na verdade, isso é questionável) e as instalações que as pessoas terão sucesso em manter as paredes limpas - ao custo de inibir o grupo de desenvolvimento de produtos de inovar e colaborar. Finalmente, a empresa cai com menos e menos PI, mesmo protegida porque as ferramentas de inovação e entrega rápidas foram desativadas, mas os advogados cumpriram com sucesso seu mandato da equipe executiva para “garantir que nossa PI esteja protegido”. E a política mobiliária tem paredes claras. Eles fizeram o seu melhor.

Abaixo uma citação de e-mail real da política mobiliária em uma organização que desativou o gerenciamento visual nas paredes. Você pode identificar as otimizações locais e os modelos mentais conduzindo isso?

A partição cúbica de trabalho individual pode ser personalizada. Mas as coisas obviamente maiores do que a partição ou que danificam a harmonia do ambiente de escritório são restritas.

Também vemos otimização local em grupos centralizados que fazem escolhas de ferramentas de software para outros. A mentalidade comum é escolher uma ferramenta que seja melhor para reduzir algum custo suposto (curiosamente, esses grupos raramente recomendam ferramentas livres de código aberto) ou o melhor em fazer algo complicado ou melhor para o trabalho de um trabalhador especializado (embora todos precisem usar a ferramenta), em vez de maximizar o objetivo global de um rendimento mais rápido do sistema para os clientes.

Na adoção em larga escala de princípios Scrum ou ágeis, a maioria dos problemas “Sim, mas …” que são criados são exemplos de otimização local, como, “Sim, mas … e sobre relatórios de gerenciamento *?” ou mais frequente, “Sim, mas … e sobre *?" Então, as políticas e as práticas são retorcidas, atendendo o objetivo de relatar ou algum outro objetivo secundário e não o principal objetivo de otimizar a taxa de entrega de valor. Às vezes, vemos *otimização local para o caso extremo ou raro*. Por exemplo, uma pessoa responsável por fazer uma escolha de ferramenta centralizada para a empresa apresenta um cenário para um caso complexo ou raro de uso e, em seguida, escolhe a ferramenta que se encaixa, subotimizando um caso de 5% em vez de otimizar para facilidade e velocidade para o caso de 95 por cento.

Outras otimizações locais são devidas ao desconhecimento de novas formas de trabalhar. Isto é especialmente comum em grupos de produtos em larga escala. Por exemplo, uma vez ajudamos um grande grupo de produtos em rede na Europa a adotar Scrum e a prática de integração contínua (CI) combinada com um sistema CI que continuamente integrou, construiu e testou automaticamente o produto. Depois de algum tempo, um gerente tradicional externo examinou o que estava acontecendo e recomendou que as práticas de integração fossem alteradas — porque não havia um plano de integração escrito sobre como um gerente de integração humana deveria integrar manualmente todo o software e, claro, não havia um gerente de integração. Eles queriam “otimizar” o trabalho de um gerenciador de integração que não era mais necessário. Eles não podiam ver que seu modelo de trabalho antiquado tinha sido eliminado com a CI. Esta história se repete em todos os departamentos de um grande produto estabelecido: otimização local em torno das formas de trabalho existentes, como teste manual, departamento de arquitetura separado, equipes de componentes e assim por diante. Um treinador que trabalha para introduzir o Scrum de grande escala no nível da empresa tem uma montanha de pensamento de otimização local semelhante a tratar.

No pensamento enxuto e nos métodos ágeis, o foco está nos objetivos de sistemas globais: Entregar valor rápido com alta qualidade e moral — otimização global. Tente considerar as decisões à luz desse objetivo. Para desenvolver uma cultura de “otimizar o todo”, desafie todas as decisões e políticas com a questão:

Esta decisão ou política se concentra em entregar valor ao cliente externo rapidamente ou se concentra nos interesses de um departamento, pessoa, política interna / prática ou caso raro?

No LeSS, o Product Owner é responsável por escolher metas de alto valor que **poderiam levar a produtos potencialmente lancáveis (no final do Sprint) e que maximizem os impactos desejados e que deliciem o cliente, mantendo um ritmo sustentável e alto qualidade de engenharia **. Esse objetivo explícito é destinado a orientar o sistema para otimização global e não local.

Conclusão

Além de se tornar um pensador sistêmico, incentive outros a aprender mais sobre esse tópico. Sugerimos que você tente se juntar em um quadro branco com colegas para esboçar um diagrama de loop causal, de modo que sendo pensadores sistêmicos e fazendo pensamento sistêmico vocês estarãoo conectados no local de trabalho.

Leituras Recomendadas

• W. Edwards Deming’s Out of the Crisis é um trabalho mestre do, indiscutivelmente, mais conhecido pensador sistêmico e especialista em qualidade. Ele abre com o objetivo modesto: “O objetivo deste livro é a transformação do estilo da gestão americana … Que requer toda uma nova estrutura, desde a fundação para cima”. Deming também defende o Sistema de Conhecimento Profundo em que os gerentes devem (1) apreciar que existe um istema *, (2) compreender a variação de causa comum e a de causa especial (a teoria da fila está relacionada à variação), (3) compreender limitações do conhecimento e erros de raciocínio e (4) conhecer psicologia credível e resultados da pesquisa social para que as políticas relacionadas ao comportamento ou à motivação *não sejam baseadas no “senso comum”. O núcleo do livro se centra em torno de seus famosos 14 Pontos para Gestão, incluindo (por exemplo), “Eliminar a gestão por objetivo. Eliminar a gestão por números, metas numéricas. Substituir liderança. “
  
• Jay Forrester’s Industrial Dynamics é um texto clássico sobre a sistemas dinâmics - bem escrito e perspicaz. Embora escrito no início da década de 1960, é tão relevante hoje como quando publicado. Ele vai além da modelagem causa-efeito para também modelar o fluxo e inventários de informações, dinheiro e material em sistemas. O livro inclui modelagem matemática formal, mas isso não é obrigatório para apreciar a dinâmica do sistema.
• Weinberg’s Quality Software Management: Systems Thinking e An Introduction to General Systems Thinking valem a pena. Escritos a partir da perspectiva de um consultor experiente em desenvolvimento de sistemas.
  
• Senge’s The Fifth Discipline é um clássico que defende a necessidade de liderança para aplicar o pensamento sistêmico (é a quinta disciplina) e outras disciplinas fundamentais para uma grande e sustentável empresa. As outras discipilinas incluem líderes com (1) domínio pessoal e (2) reflexão sobre suas crenças e raciocínioa defeituosoa, a (3) definição e comunicação de uma visão compartilhada significativa, e (4) a capacidade das equipes para aprender. Recomendamos ignorar - pelo menos durante os primeiros anos de prática - a noção de “arquétipos” apresentada no livro. Era bem concebido como um auxílio de aprendizagem, mas foi observado para distrair e intimidar as pessoas de aprender e aplicar modelos básicos de sistemas dinâmicos. Os “arquétipos” não fazem parte da dinâmica original do sistema.
  
• The Fifth Discipline Fieldbook é um recurso aprofundado, escrito do ponto de vista de muitos profissionais e consultores.
  
• As escritas de aprendizagem organizacional de Argyris, Putnam, McLain e Schön. Os conceitos importantes incluem aprendizado de duplo ciclo e diálogo de alta defesa / consulta elevada. Os trabalhos clássicos incluem Action Science e Organizational Learning.
  
• As publicações e recursos disponíveis através da Society for Organizational Learning.

---

Notas:

1. Senge escreveu The Fifth Discipline, sobre pensamento sistêmico e organizações de aprendizagem, denominado “um dos livros de gestão seminal dos últimos 75 anos” pela Harvard Business Review. Veja** [Senge94].




2.
Outro motivo: Acreditar é possível ter mais controle do que o atual. A ciência da complexidade sugere limites fundamentais para prever e controlar os sistemas sociais semi-caóticos [Stacey07]. Esta é uma lata bastante grande de vermes que permanecerá aberta neste livro.




3. Macroeconomia, psicologia, sociologia e biologia são exceções, entre outras.




4. Básico” não significa trivial ou fácil de resolver. Por exemplo, “motivação” e “qualidade” são problemas básicos, mas não fáceis.




5. Loops de Feedback ocasionalmente é usado neste livro no sentido coloquial do feedback, ao invés do senso de sistemas dinâmicos.