I: Origens

Capítulo 3: Sherlock Holmes faz o diagnóstico

O método dedutivo de reconhecimento das patologias corporativas: sete sinais de que o seu projeto está a morrer — de Knight Capital a Target Canada.

Ilustração: Capítulo 3: Sherlock Holmes faz o diagnóstico

Gravura do capítulo: Sherlock Holmes faz o diagnóstico

De que trata este capítulo. O método dedutivo na gestão de projetos. Como aprender a ver o invisível: sete sinais diagnósticos de um projeto moribundo, cada um verificado em catástrofes reais que podiam ter sido evitadas.

Southsea (Portsmouth), 1 Bush Villas, primavera de 1886

Arthur Conan Doyle está sentado na consulta da sua própria prática médica em Southsea, subúrbio de Portsmouth. Tem vinte e seis anos — Edimburgo ficou para trás, o diploma foi obtido, a consulta está montada. Rendimento do primeiro ano: £154; depois a prática crescerá para £250, e o teto de oito anos ficar-se-á por £300. Não é miséria, mas também não é cirurgião em Harley Street: modesto trabalho provincial e, à noite, silêncio.

Neste silêncio, Doyle escreve contos para revistas baratas. Cerca de três libras por conto na London Society — é importante, mas não vira o orçamento. Muito mais pesado é o que acontecerá no fim do ano. Em três semanas da primavera de 1886, escreverá um romance curto sobre um detetive-consultor chamado Sherlock Holmes: Um Estudo em Vermelho. A Ward Lock & Co comprará o manuscrito a 20 de novembro do mesmo ano por £25 — por todos os direitos. Vinte e cinco libras, uma só vez, sem royalties. Assim entrará na literatura a personagem mais rentável do século XX.

Doyle escreve tendo em mente o seu professor de Edimburgo — o Professor Joseph Bell. Bell fazia o diagnóstico antes de o paciente abrir a boca: pela maneira de andar, pela roupa, pela pele das mãos. Seis anos depois, em 1892, Doyle escreverá a Bell: «É a si que devo Sherlock Holmes… em torno do centro de dedução, de dedução e de observação que o senhor ensinava, tentei construir um homem»¹ᵃ.

Nasce assim a personagem que, 140 anos depois, explicará porque a maioria dos projetos corporativos falha antes mesmo do seu anúncio oficial.

Doyle não sabe que está a inventar uma metodologia de diagnóstico de falhas sistémicas. Escreve um romance curto em três semanas e vende-o por vinte e cinco libras.

Baker Street, 221B — domingo, manhã

«Você vê, mas não observa», dirá Sherlock Holmes ao Doutor Watson em «Um Escândalo na Boémia», cinco anos depois, em 1891.

«A distinção é óbvia, embora muitos não a notem. Por exemplo, viu muitas vezes os degraus que sobem da entrada até esta sala?»

«Muitas vezes.» «Quantas?» «Centenas.»

«Então quantos são?» «Quantos? Não reparei.»

«É isso mesmo! Não observou, embora tenha visto. É toda a diferença. Eu sei que os degraus são dezassete, porque tanto vi como observei»¹.

Holmes é o terceiro arquétipo literário de que a nossa investigação precisa: o método de reconhecimento. Verne deu-nos o padrão da criação, Shelley — o padrão da fuga, e Holmes dá o instrumento sem o qual os dois primeiros são inúteis.

Porque a fase mais perigosa da doença não é a agonia, mas o período do falso bem-estar: quando todos têm a certeza de que o paciente está saudável.


O capítulo anterior mostrou o que acontece quando o criador abandona a sua criação. FBI Sentinel, Healthcare.gov, BBC DMI: em cada caso, os sinais da catástrofe eram visíveis muito antes da explosão, mas alguém os via — e ninguém os observava.

Este capítulo é dedicado à observação. A distinguir uma equipa saudável de uma equipa moribunda, um processo vivo de um ritual, adaptação de imitação. Sete sinais diagnósticos (os dezassete degraus de Holmes) que todos veem, mas ninguém conta.

Dedução contra intuição

Holmes não era génio no sentido romântico — era um observador sistémico. O seu método não é o clarão da iluminação, mas uma sequência disciplinada: recolher dados, descartar o impossível, aceitar o que resta, por mais improvável que seja².

«Nunca advinho», diz Holmes em O Signo dos Quatro. «É um hábito nefasto, destrutivo para o pensamento lógico»².

Compare-se com o modo como se tomam decisões nos projetos corporativos: intuição do gestor, consenso do comité, extrapolação a partir do último trimestre, opinião da voz mais alta da sala — tudo, exceto observação sistemática.

Holmes propõe uma alternativa: não acreditar nem em relatórios, nem em métricas, nem em apresentações, mas observar aquilo que as pessoas fazem e não aquilo que dizem. O primeiro princípio do diagnóstico diz: os dados recolhem-se no local do crime, não no gabinete do investigador.

Aqui estão sete sinais que Holmes teria notado na primeira ronda.

Sinal I: O cão que não ladrou

No conto «Silver Blaze», Holmes chama a atenção do inspetor para «o estranho episódio noturno com o cão». O inspetor objeta: «O cão não fez nada durante a noite.» Holmes: «É esse o estranho episódio»³.

O cão não ladrou porque conhecia o ladrão. O sinal mais importante não estava naquilo que aconteceu, mas naquilo que não aconteceu.

No diagnóstico corporativo, o silêncio torna-se o sintoma mais alarmante: quando nas retrospetivas ninguém levanta problemas, nas revisões de código não há observações sérias, todos os sprints fecham «conforme o plano» e a velocidade de desenvolvimento está estável como o cardiograma de um defunto.

A literatura conheceu este dashboard verde século e meio antes do primeiro sprint. O enredo de Almas Mortas (1842) Púchkin ofereceu a Gógol a partir de uma história real: numa cidadezinha da Transnístria — em Bendery — durante anos não se registava nem uma única morte. O segredo era simples — os nomes dos falecidos não eram riscados, mas transmitidos aos camponeses fugitivos recém-chegados. A estatística mostrava população imortal; na coluna «diminuição» estava um zero impecável. É exatamente assim que aparece uma equipa que aprendeu a não registar o fracasso na reportagem: a métrica reporta velocidade perfeita, porque dela foram cuidadosamente removidos todos os elementos que estragam o retrato. Tchichikov comprava almas que não existem por um registo em que elas estavam vivas — e todo o mecanismo assentava no facto de que o papel há muito tempo deixara de se confrontar com a vida. Um dashboard que há seis meses arde verde é um registo de recenseamento: uma lista de vivos, na qual metade já não respira.

O mesmo cão que não ladrou no estábulo de King's Pyland está calado também no stand-up. Holmes indica ao inspetor Gregory «o estranho comportamento do cão na noite do crime» — e este mostra-se perplexo: «Do cão? Mas ele não se manifestou!» «É isso mesmo que é estranho», responde Holmes. Um ano e meio sem um único bloqueador no quadro é precisamente o cão que não deu voz: não uma prova de que tudo está calmo, mas uma prova de que o portador da inquietação escolheu o silêncio. Uma equipa em que durante meio ano ninguém traz uma má notícia atingiu ou a perfeição (cuja probabilidade Holmes avaliaria sobriamente), ou apreendeu que um bloqueador é confissão de incompetência e aprendeu a sofrer em silêncio. Num e noutro caso, o diagnosticador não se deve alarmar com aquilo que se ouve, mas com aquilo que não se ouve.

As equipas saudáveis fazem ruído, discutem, quebram sprints, levantam bandeiras vermelhas. O silêncio significa uma de duas coisas: ou a equipa atingiu a perfeição (probabilidade próxima de zero), ou as pessoas deixaram de acreditar que serão ouvidas.

Knight Capital, 1 de agosto de 2012. Um dos maiores market makers na NYSE. Às 9h30 da manhã, hora de Nova Iorque, a empresa ativou um novo algoritmo de negociação. Em 45 minutos, o sistema realizou posições erradas no valor de sete mil milhões de dólares. A perda ascendeu a 440 milhões de dólares antes de impostos; os write-offs finais levaram a cifra a cerca de $460 milhões⁴ᵃ. A empresa perdeu mais do que todo o seu dinheiro em caixa — $365 milhões nas contas na véspera — pelo que foram necessários $400 milhões de financiamento de resgate em três dias⁴.

A SEC realizou uma investigação e publicou os resultados em 2013. Detalhe-chave: no deploy do novo código, um dos oito servidores não recebeu a atualização. Nele ficou o código antigo (o módulo de teste «Power Peg»), sem uso há nove anos — desde 2003 — mas não removido do sistema. Quando o servidor recebeu sinais de negociação, o Power Peg começou a executá-los pela lógica escrita para o ambiente de teste. Resultado: transações caóticas a preços de mercado com volumes enormes⁴.

O cão que não ladrou: ninguém perguntou porque é que código morto de nove anos ainda está em produção. Todos viam o Power Peg no repositório de código, mas ninguém observava.

A SEC estabeleceu: a Knight Capital não tinha procedimentos adequados de controlo de deployment nem testava o sistema completo antes do lançamento⁴. Tradução para a língua de Holmes: o crime não foi cometido pelo algoritmo. O crime foi cometido pelo silêncio (durante anos) sobre a dívida técnica que todos viam e ninguém nomeou como problema.

Sinal II: Incompatibilidade das provas

Holmes nunca formula uma teoria antes de recolher os factos. «Erro imperdoável: construir teorias sem ter dados. Imperceptivelmente para si próprio, começa-se a adaptar os factos à teoria, em vez de construir a teoria a partir dos factos»⁵.

No diagnóstico corporativo, isto tem esta forma: o painel de controlo mostra luz verde, mas os utilizadores queixam-se; a velocidade de desenvolvimento cresce, mas o tempo de entrega das funcionalidades aumenta; a equipa reporta alta moral, mas as melhores pessoas vão-se embora.

Quando as métricas contradizem a realidade, Holmes confia invariavelmente na realidade.

Target Canada, 2013–2015. Em março de 2013, a Target Corporation (segundo maior discount retailer dos EUA) entrou no mercado canadiano. No primeiro ano abriram 124 lojas; no final de 2014 a rede expandiu-se para 133 pontos. As perdas totais da aventura canadiana ultrapassaram os 7 mil milhões de dólares dos EUA (incluindo um write-off de $5,4 mil milhões pré-imposto)⁶.

Em janeiro de 2015, a Target Canada fechou. Completamente. Todas as 133 lojas. 17 600 trabalhadores perderam o emprego⁷.

A investigação da Canadian Business estabeleceu: o sistema de gestão de dados de produto (SAP) continha dados tão sujos que as lojas não podiam encomendar corretamente mercadoria. Tamanhos, preços, descrições — tudo continha erros, pelo que as prateleiras estavam vazias ou preenchidas com a mercadoria errada, e os compradores chegavam, viam o vazio e iam-se embora para sempre⁸.

Incompatibilidade das provas: a reportagem corporativa mostrava que todas as 133 lojas estavam abertas e a funcionar. Tecnicamente era verdade — as lojas estavam de pé, as caixas funcionavam, os funcionários vinham aos turnos. Mas as prateleiras estavam vazias, porque o sistema que devia enchê-las de mercadoria mentia sobre que mercadoria existia, em que quantidade e a que preço.

Holmes diria: você olha para o dashboard, mas não observa a prateleira. A métrica «133 lojas abertas» é uma prova que leva a um beco sem saída, ao passo que a prova verdadeira é: a tia Janine de Montreal, que veio comprar toalhas e foi-se sem nada.

A Target Canada perdeu sete mil milhões de dólares não porque a direção fosse incompetente, mas porque o sistema de reportagem contava uma história que não coincidia com a realidade física, e ninguém quis ir à loja e olhar para as prateleiras. Os dados substituíram a observação, e o painel de controlo substituiu Baker Street.

Sinal III: A lei de Conway como perícia forense

Em 1968, Melvin Conway publicou uma observação que se tornou lei: «As organizações que projetam sistemas são forçadas a reproduzir nesses sistemas a sua própria estrutura de comunicação»⁹.

Holmes apreciaria a elegância desta ideia. Se quer perceber o que está mal com o produto, não olhe para o código — olhe para a estrutura organizacional. O código é apenas uma sombra da organização, projetada no ecrã do monitor.

A lei de Conway não é uma teoria, mas uma prova: perícia forense que indica infalivelmente o culpado.

Se a sua API é composta por sete endpoints incompatíveis, é altamente provável que na empresa existam sete equipas que não falam umas com as outras. Se o percurso do utilizador passa por três interfaces com design diferente, é sinal de que por elas respondem três departamentos diferentes com três chefes diferentes. Se o deploy exige coordenação de cinco repositórios, procure cinco gestores, cada um protegendo o seu território.

O produto torna-se espelho da organização, e um espelho partido reflete inevitavelmente uma organização partida.

Voltemos à Target Canada. O sistema SAP, implementado para a gestão das lojas canadianas, foi configurado por uma equipa de Minneapolis para uma realidade canadiana que essa equipa não compreendia. O regime fiscal canadiano, a rotulagem bilingue, o sistema métrico — tudo isto era «apenas configuração» para pessoas que nunca compraram leite em litros⁸.

A lei de Conway previu o fracasso: uma organização americana criou um sistema que refletia a compreensão americana do mercado canadiano. Estrutura da organização americana, estrutura dos dados americana, compreensão do comprador americana. Melvin Conway poderia ter feito o diagnóstico em 1968, 45 anos antes da abertura da primeira loja.

Sinal IV: O paciente desaparecido

Holmes começa sempre pela pergunta: quem é a vítima? Não «o que correu mal», mas «quem sofreu». Não é sentimentalismo, mas método: a vítima aponta para o motivo, e o motivo — para o culpado.

No diagnóstico corporativo, a vítima é o utilizador, e o sinal mais alarmante surge precisamente quando se deixa de falar do utilizador.

Escute as conversas da sua equipa: se as palavras «utilizador», «cliente», «comprador» soam com menor frequência do que «processo», «framework», «metodologia», é sinal de que o paciente desapareceu, e a equipa trata-se a si própria, esquecendo o doente.

Gerald Weinberg mostrou já em 1971: se os programadores não se encontram com os utilizadores, criam inevitavelmente um sistema para si próprios¹⁰. Não por má intenção, mas por ausência de dados: Holmes não pode resolver o caso sem ir ao local do crime; o programador não pode criar o produto sem ver o utilizador.

Lidl e SAP: sistema de 500 milhões de euros para um utilizador que não existia. Em 2018, o discounter alemão Lidl parou a implementação de um sistema SAP de gestão de inventário de mercadoria após sete anos de trabalho e despesas estimadas pela imprensa em 500 milhões de euros¹¹.

A causa, segundo o Handelsblatt (julho de 2018): a Lidl tentava obrigar a SAP a funcionar segundo a lógica de compras da Lidl, ao passo que a SAP exigia que a Lidl se reestruturasse segundo a lógica da SAP — sete anos de compromissos que não convinham nem ao sistema nem ao negócio¹¹.

O paciente desaparecido: o funcionário do armazém da Lidl, que todas as manhãs decide quantos iogurtes encomendar. Esta pessoa é o utilizador final de um sistema no valor de meio mil milhão de euros, mas não foi consultada.

Em vez disso, perguntou-se aos consultores da SAP (o que pode o sistema?), aos diretores financeiros (qual o orçamento?) e aos arquitetos de IT (qual a arquitetura?) — todas as perguntas certas, mas colocadas às pessoas erradas. Holmes nunca começa uma investigação pelo interrogatório dos advogados do suspeito, mas vai ao local do crime e fala com as testemunhas.

Sinal V: A prova do tempo

Holmes regista não apenas o que aconteceu, mas quando: a cronologia é o esqueleto da investigação.

No diagnóstico de projetos, o tempo diz mais do que qualquer relatório: quanto tempo passa da ideia ao protótipo, do protótipo ao utilizador, da descoberta de um bug à sua correção?

A investigação DORA (DevOps Research and Assessment), publicada pela Google Cloud em 2023, classifica as equipas em quatro níveis de produtividade. As equipas elite fazem deploy várias vezes ao dia por pedido, e o seu lead time — do commit à produção — é inferior a um dia. As equipas de baixa produtividade fazem deploy uma vez por mês ou menos, o lead time é de um a seis meses, e a recuperação após uma falha demora uma semana ou mais¹².

A diferença não é em percentagens, mas em ordens de grandeza.

Mas a métrica mais reveladora não é a velocidade do deploy, mas o tempo de recuperação após uma falha: as equipas elite recuperam numa hora, ao passo que as de baixa produtividade — numa semana ou mais¹².

Holmes diria: a velocidade com que a organização corrige erros diz mais dela do que a velocidade de criação de novidade, porque a criação é ambição, e a correção é caráter.

A Knight Capital recuperou em 45 minutos, mas tarde — 440 milhões de dólares foram perdidos irrecuperavelmente (antes de impostos; os write-offs finais levaram o prejuízo total a ~460 milhões); o Healthcare.gov recuperou em dois meses; a BBC DMI nunca recuperou. A linha temporal da recuperação é o indicador infalível da saúde organizacional.

Se a sua equipa precisa de uma semana para corrigir um bug crítico, isso não é diagnóstico técnico, mas organizacional, pois algures na cadeia entre deteção e correção estão pessoas que aprovam, acordam, planeiam, adiam, esperam — em vez de arranjar.

Sinal VI: O efeito do Doutor Watson

Watson não é apenas o narrador, mas o espelho em que Holmes vê as suas próprias zonas cegas. Watson faz perguntas «tolas» que se revelam as mais importantes, e nota o humano onde Holmes vê apenas lógica.

Cada equipa precisa de um Watson — uma pessoa que não tenha vergonha de dizer: «Não entendo porque estamos a fazer isto.» Não porque seja incompetente, mas porque, se ele não compreende, provavelmente ninguém compreende, mas os restantes têm vergonha de admitir.

Quando desaparece de uma equipa o Watson — pessoa que faz perguntas incómodas — resta uma câmara de eco: todos concordam, todos têm a certeza, mas ninguém verifica as suposições básicas.

Frederick Brooks descreveu este efeito em The Mythical Man-Month: «Acrescentar pessoas a um projeto atrasado torna-o ainda mais atrasado»¹³. Mas uma observação menos citada de Brooks é ainda mais importante: as grandes equipas perdem a capacidade de comunicação, porque o número de canais de comunicação cresce como n(n-1)/2¹³. Uma equipa de 5 pessoas tem 10 canais; uma de 50 — 1225; e com 1225 canais é impossível ser Watson para cada um.

Numa equipa pequena, Watson é natural — qualquer um pode perguntar: «E porquê?» Numa grande organização, o «porquê» exige reunião, apresentação, justificação e aprovação, e no momento em que a pergunta é finalmente colocada, a resposta já não é atual.

A Target Canada perdeu-se em 1225 canais; a Knight Capital — no silêncio da equipa que via o código morto e não colocou a pergunta; e a Lidl — num projeto de sete anos onde ninguém perguntou ao funcionário do armazém: «Isto é-te cómodo?»

Sinal VII: A prova material — git log

Holmes acredita em provas, não em depoimentos: os depoimentos são subjetivos, tendenciosos e amnésicos; as provas são objetivas.

Num projeto de software há uma prova que é impossível falsificar: git log.

A história dos commits conta a verdade que nenhum stand-up contará: quem realmente escreve o código, qual a dimensão das alterações, com que frequência o master se quebra, quem revê e se revê de todo — nada disto é preciso perguntar às pessoas: está visível no registo, que não aprende a responder como o gestor quer.

A frequência dos commits é o mais fácil de ler: se o último commit num módulo-chave é de há seis meses, o módulo está morto — independentemente do que se diga sobre ele no relatório trimestral. Se, pelo contrário, os commits saem a cada hora com mensagens «fix», «fix2», «fix final», «fix final final», isto também é um diagnóstico, apenas o oposto: a equipa em pânico. O tamanho dos commits dá a camada seguinte: um commit médio de 2000 linhas não são iterações, mas um big bang mascarado de trabalho regular; ao passo que um commit de 3 linhas significa o contrário — a equipa tem medo de alterar algo sério. O tamanho saudável fica entre estes extremos.

Autoria. Se 80% dos commits recaem sobre uma pessoa, o bus factor é igual a um: sai essa pessoa — o projeto para. Não porque os restantes sejam incompetentes, mas porque deixaram de tocar no código que consideram «alheio».

Comentários aos commits. «WIP», «asdf», «tmp», «please work» — grito de socorro codificado nos metadados; ao passo que «Refactor auth module to support OAuth2 flow» fala de uma equipa que percebe o que faz e para quê.

Holmes não adivinharia se o projeto está saudável, mas abriria o git log e em cinco minutos saberia a resposta.

Contra o diagnóstico

Tese que enfurecerá os consultores de gestão: a maioria dos frameworks diagnósticos é parte da doença, não do tratamento.

Modelos de maturidade (CMM, CMMI), assessments Agile, scorecards de prontidão organizacional — todos propõem uma abordagem: avalie-se numa escala de 1 a 5, identifique zonas de desenvolvimento, elabore um plano de melhoria.

Holmes riria: pedir a uma organização doente que se diagnostique a si própria é como pedir a um suspeito que conduza o próprio interrogatório.

As organizações mentem a si próprias não por má intenção, mas por distorções sistémicas: a direção sobrestima a saúde (senão teria de agir), o nível intermédio subestima os problemas (senão seriam culpabilizados), e os funcionários rasos calam-se (senão seriam despedidos). Cada nível filtra a informação, e no momento em que ela atinge quem toma decisões, da realidade resta uma sombra alisada.

A Nokia caiu exatamente assim. Vuori e Huy chamaram-lhe «atenção distribuída»¹⁴: quando a organização é tão grande que ninguém vê a imagem completa, a responsabilidade dissolve-se. Cada um responde pelo seu fragmento; ninguém — pelo todo.

Holmes nunca se apoiou na autoavaliação do cliente, mas observou: contou degraus, notou terra nos sapatos, prestou atenção aos cães que não ladravam.

O diagnóstico verdadeiro tem de ser externo e duro, baseado em factos, não em sensações.

Do diagnóstico ao tratamento

Três capítulos acumularam três instrumentos diferentes: Verne mostrou como construir sistemas vivos através de incrementos, feedback e adaptação; Shelley mostrou o que acontece a esses sistemas quando são abandonados; e Holmes deu o modo de reconhecer a doença antes da autópsia.

Mas o diagnóstico não é tratamento, e saber que o projeto está doente é necessário, mas insuficiente ao mesmo tempo. Holmes resolvia crimes, mas nunca os prevenia: chegava depois de o mal já ter acontecido. O seu método funciona para o observador que chega ao local do crime, não para o construtor que quer que o crime não haja.

O ato seguinte coloca outra pergunta: não «como chegámos aqui?», mas «como sair daqui?». Não arqueologia literária dos fracassos, mas prática viva das equipas que sabem manter-se vivas em condições que matam os vizinhos. Deixamos Baker Street e vamos para onde as equipas aprenderam a observar-se a si próprias.


Continua. No próximo capítulo: um bibliotecário de Buenos Aires que descreveu a sua avaliação de sprint em 1941 — sessenta anos antes da sua invenção. Uma lotaria em que se sorteia não dinheiro, mas produtividade; um teatro onde os OKR se interpretam a si próprios; e equipas tão empenhadas em medir a velocidade que se esqueceram de olhar para onde vão. Holmes contou os dezassete degraus. Borges contará os seus story points.


Footnotes:

¹ Arthur Conan Doyle. «A Scandal in Bohemia» (1891). The Strand Magazine (tradução do autor). O diálogo sobre os degraus é um dos exemplos clássicos do método de Holmes.

¹ᵃ Doyle, Arthur Conan. Carta a Joseph Bell, maio de 1892 (verbatim, documentado: Wikipedia, ACD Encyclopedia, referências ao arquivo da Universidade de Edimburgo). Tradução completa: «É a si que devo Sherlock Holmes… em torno do centro de dedução, de dedução e de observação que o senhor ensinava, tentei construir um homem».

² Doyle, Arthur Conan. The Sign of the Four (1890) (tradução do autor).

³ Doyle, Arthur Conan. «Silver Blaze» (1892). The Strand Magazine (tradução do autor).

⁴ SEC Administrative Proceeding File No. 3-15570, October 16, 2013. «In the Matter of Knight Capital Americas LLC» (tradução do autor). Multa $12 milhões. Detalhes do incidente com Power Peg e ausência de procedimentos de controlo de deployment documentados na enforcement action.

⁵ Doyle, Arthur Conan. «A Scandal in Bohemia» (1891). The Strand Magazine (tradução do autor). Fonte exata da citação sobre teorias sem dados — não Um Estudo em Vermelho, mas «Um Escândalo na Boémia»; em Um Estudo aparece uma variante curta desta ideia.

⁶ Target Corporation Annual Report 2014 e The Globe and Mail, January 15, 2015 (tradução do autor). Volume total de investimento na divisão canadiana ultrapassou $7 mil milhões USD; write-off das perdas (pretax losses) atingiu $5,4 mil milhões.

⁷ Canadian Press, January 15, 2015. «Target Canada closing: A timeline of the U.S. retailer's disastrous Canadian venture» (tradução do autor). 17 600 trabalhadores — dados da declaração oficial da Target Corporation.

⁸ Castaldo, Joe. «The Last Days of Target Canada.» Canadian Business, January 2016 (tradução do autor). Investigação detalhada dos problemas com dados do sistema SAP.

⁹ Conway, Melvin. «How Do Committees Invent?» Datamation, April 1968 (tradução do autor). Formulação original da lei de Conway.

¹⁰ Weinberg, Gerald. The Psychology of Computer Programming (1971). Van Nostrand Reinhold (tradução do autor). Observações sobre a relação entre programadores e utilizadores.

¹¹ Handelsblatt, julho de 2018 (fonte primária para o valor €500M e cronologia do projeto eLWIS); Computerwoche, 2018; Lebensmittel Zeitung, 2018 (tradução do autor). O projeto eLWIS foi parado em julho de 2018 após sete anos e cerca de €500 milhões de despesas (≈$580–600 milhões). Regresso ao sistema anterior Wawi.

¹² Accelerate: State of DevOps Report. Google Cloud / DORA, 2023 (tradução do autor). Classificação das equipas por quatro níveis: Elite, High, Medium, Low.

¹³ Brooks, Frederick. The Mythical Man-Month (1975). Addison-Wesley (tradução do autor). Lei de Brooks e fórmula dos canais de comunicação n(n-1)/2.

¹⁴ Vuori, Timo O. e Quy Nguyen Huy. «Distributed Attention and Shared Emotions in the Innovation Process: How Nokia Lost the Smartphone Battle.» Administrative Science Quarterly, Vol. 61, No. 1 (2016), pp. 9-51 (tradução do autor). Investigação da queda da Nokia e dos mecanismos de atenção organizacional.