softify.pro - Insiders

Há uma forma simples de fazer um software de armazém parecer convincente.
Abrir um painel.
Mostrar alguns números a verde.
Adicionar um gráfico.
Colocar algum stock num mapa do armazém.
Terminar com um relatório.
Tudo parece estar bem.
E, ainda assim, tudo pode estar errado.
Porque a um armazém não interessa quão bonito o painel parece.
Interessa-lhe se cada parte do sistema concorda sobre o que realmente aconteceu.
Isso tornou-se a parte interessante da mais recente experiência softify.pro Flow.
Não outro ecrã.
Não outro KPI.
Não outro relatório.
Algo muito menos visível.
Consistência.
Começou com um armazém.
A demo atual do softify.pro Flow funciona com vários ambientes de armazém sintéticos.
Diferentes IDs de armazém.
Diferentes capacidades.
Diferentes estruturas de zona.
Sem inventário de produção.
Sem dados de clientes.
Sem informação operacional real.
Mas a lógica do processo comporta-se como se tudo isso importasse.
Porque na logística real, importa.
Assim que um armazém é selecionado, esse contexto torna-se parte de tudo o que se segue.
Flows.
SSCCs.
Movimentos.
Operadores.
Analytics.
Relatórios.
Isso soa óbvio.
Torna-se consideravelmente menos óbvio quando o mesmo processo começa a aparecer em várias partes diferentes da aplicação.
Depois abrimos outra vista.
Operational Analytics.
De repente, o armazém parecia completamente diferente.
Sem posições de armazenamento.
Sem setas de movimento.
Em vez disso:

• Flows concluídos,
• encomendas ativas,
• utilização do armazém,
• exceções,
• entradas,
• saídas,
• tempo de processamento.

A representação visual tinha mudado.
O armazém não.
Essa distinção tornou-se importante.
Porque por baixo dos KPIs continuavam a existir registos individuais.
IDs de Flow.
SSCCs.
Zonas.
Estados.
Operadores.
Tempos de processamento.
Vista diferente.
Mesma realidade operacional.
Até aqui, tudo bem.

Operational Analytics — estado agregado do armazém, com os registos Flow subjacentes ainda visíveis.

88% só é útil se o sistema o conseguir explicar.
Suponhamos que o painel diz:
Utilização do armazém: 88%.
Útil.
Mas incompleto.
Algumas posições estão ocupadas.
Algumas estão reservadas.
Algumas permanecem livres.
Esses estados não são intermutáveis.
O número só se torna fiável se o sistema ainda conseguir explicar de onde veio.
Cinco Flows concluídos?
Mostre-os.
Duas encomendas ativas?
Mostre-as.
Uma exceção?
Qual?
88% de utilização?
O que está ocupado?
O que está reservado?
O que permanece livre?
Um painel deve resumir a realidade.
Não deve substituí-la.
Depois mudámos o idioma.
Neerlandês.
O armazém permaneceu o mesmo.
Os IDs de Flow permaneceram os mesmos.
Os SSCCs permaneceram os mesmos.
Os operadores permaneceram associados aos seus registos.
Só o idioma mudou.
Mais tarde, o mesmo estado operacional apareceu em croata.
Depois em francês.
É aqui que o software multilingue se torna muito mais interessante do que botões traduzidos.
Uma má tradução é fácil de notar.
Uma mudança de estado causada por uma mudança de idioma é muito mais perigosa.
Imagine mudar de alemão para francês e perder silenciosamente o Flow selecionado.
Ou reconstruir um filtro contra o armazém errado.
Ou mostrar o SSCC correto dentro do contexto de processo errado.
A interface pode continuar a parecer perfeita.
O sistema não seria.
Por isso, o Flow segue uma regra simples:
O idioma pode mudar as palavras. Não pode mudar a verdade.
Depois o Flow adquiriu um histórico.
O Browse & Drill-down não se esforça particularmente por parecer impressionante.
Talvez seja precisamente por isso que é útil.
Selecione um Flow.
O seu contexto aparece.
Armazém.
Zona.
Estado.
Operador.
SSCC.
E depois a cadeia de documentos.
ASN.
Receção de mercadorias.
Movimento de armazém.
Ordem de picking.
Picking.
Expedição.
FLOW.
Sete passos.
O processo já não é apenas um estado atual.
Tem um passado.
E isso muda a pergunta.
Em vez de:
O que está a acontecer?
podemos perguntar:
Como chegámos aqui?
Essa é uma pergunta muito melhor quando algo acaba por correr mal.

Um Flow, um SSCC, uma cadeia de documentos — do ASN até à conclusão.

O SSCC torna-se o fio condutor.
À primeira vista, um SSCC parece aquilo que é.
Um identificador.
Um número longo numa tabela.
Mas ao longo do Flow torna-se algo mais útil.
Um fio condutor ao longo do processo.
Siga-o e outras coisas começam a ligar-se.
Um armazém.
Um Flow.
Uma zona.
Um estado.
Um operador.
Uma cadeia de documentos.
Eventualmente, um relatório.
O mesmo objeto logístico físico é agora visível a partir de várias partes diferentes da aplicação.
Útil.
Também perigoso.
Porque cada vista adicional cria mais uma oportunidade para o sistema contar uma história diferente.
E é aí que as coisas ficam interessantes.
Suponhamos que o Analytics diz que o Flow está ativo.
O Drill-down diz que o SSCC pertence a esse Flow.
A cadeia de documentos diz que a operação avançou mais.
O relatório diz outra coisa.
Qual está correto?
Isto não é um problema específico do Flow.
É um dos problemas mais antigos no software empresarial.
Diferentes partes do mesmo sistema desenvolvem gradualmente a sua própria versão da realidade.
Um ecrã lê o estado transacional.
Outro lê um agregado.
Outro depende de dados em cache.
Um relatório calcula algo de forma ligeiramente diferente.
Uma exceção é resolvida operacionalmente mas desaparece dos relatórios.
Cada componente funciona.
O sistema completo mente.
Normalmente de forma educada.
Por isso abrimos o Report Center.
Visão geral operacional diária.
Stock e ocupação.
Desempenho do Flow.
Rastreabilidade SSCC.
Exceções e SLA.
A mesma história operacional apareceu novamente.
Flows concluídos.
Encomendas ativas.
Utilização do armazém.
Exceções.
Entradas.
Saídas.
Tempo de processamento.
Mas desta vez a questão não era se o relatório parecia correto.
A questão era:
Consegue defender-se a si próprio?
Um bom relatório dá-lhe um número.
Um sistema melhor consegue explicar de onde vem esse número.

Relatórios a partir do mesmo estado operacional — não uma segunda versão da realidade.

A exceção continuava lá.
Um dos detalhes mais discretos revelou-se um dos mais importantes.
Os dados de demonstração contêm uma exceção.
Aparece no Analytics.
Aparece no Drill-down.
Aparece na rastreabilidade SSCC.
Aparece no Report Center.
E permanece visível em Exceptions & SLA.
É exatamente isso que deve acontecer.
Recuperar operacionalmente de uma exceção não significa que a exceção deva desaparecer do histórico.
"O processo continuou" e "nada aconteceu" não são a mesma afirmação.
Na logística, essa diferença importa.
Neste ponto, tínhamos um problema de testes.
Não um problema de software.
Um problema de testes.
Tínhamos agora o mesmo armazém representado como:

• analytics,
• Flows individuais,
• históricos SSCC,
• cadeias de documentos,
• relatórios,
• e vistas de exceções.

Cada um podia ser testado independentemente.
Abrir.
Clicar.
Filtrar.
Verificar.
Aprovar.
Seguinte.

Isso seria fácil.
Também perderia a parte interessante.
Porque seis marcas verdes não provam que seis vistas concordam entre si.
Entra o COCO.
Outra vez.
O COCO já tinha lidado com o Flow antes.
Autenticação.
Utilizadores.
Funções.
Ambientes de base de dados.
Idiomas.
Execução em desktop.
Depois veio a logística.
Armazéns.
Inventário.
Picking.
Movimentos.
Exceções.
Documentos.
Ubuntu.
Red Hat Enterprise Linux.
Desta vez demos ao COCO algo ligeiramente diferente.
Não um ecrã para verificar.
Uma história para seguir.
Pega neste armazém.
Pega neste Flow.
Pega neste SSCC.
Abre o Analytics.
Abre o Drill-down.
Muda o idioma.
Olha novamente.
Abre o relatório.
Encontra o mesmo Flow.
Encontra o mesmo SSCC.
Encontra a exceção.
Compara.
Depois compara novamente.

O COCO segue o mesmo contexto operacional através do softify.pro Flow — analytics, rastreabilidade, mudanças de idioma e relatórios.

Isso muda a natureza do teste.

A questão já não é:

• Cada módulo funciona?

Passa a ser:

• Todos os módulos acreditam que aconteceu a mesma coisa?

Uma pergunta muito melhor.
Muito menos confortável.
Um sistema de armazém deve ter uma memória.
Os operadores podem ver posições.
Os gestores de armazém podem ver KPIs.
O suporte pode usar o drill-down.
Os auditores podem usar relatórios.
O COCO pode ver todos eles.
Mas por baixo dessas perspetivas, deve existir um único histórico.
Um Flow não deve adquirir várias biografias consoante o módulo aberto.
Um SSCC não deve ter vários passados.
Uma exceção não deve existir apenas onde é conveniente.
Um armazém não deve tornar-se outro armazém porque o idioma da interface mudou.
É disso que a atual experiência Flow realmente trata.
Não de painéis.
Não de relatórios.
Nem sequer de ecrãs individuais.
De uma única verdade operacional, expressa de formas diferentes.
Controlo.
Conhecer o armazém.
Conhecer o estado.
Saber o que se está a mover.
Saber a que processo pertence.
Clareza.
Transformar KPIs de volta em registos.
Transformar registos em histórico.
Transformar exceções em evidência.
Transformar um SSCC em algo rastreável.
Flow.
Um armazém é selecionado.
O Analytics começa a descrevê-lo.
Um Flow avança.
O SSCC permanece associado.
Uma cadeia de documentos cresce.
Uma exceção aparece.
O processo continua.
O relatório lembra-se.
Depois o idioma muda.
O armazém continua o mesmo.
O Flow continua o mesmo.
O histórico continua o mesmo.
Essa era a parte esperada.
O que aconteceu a seguir foi mais interessante.
O COCO deixou de testar as vistas independentemente.
Começou a compará-las.
Durante algum tempo, nada de notável aconteceu.
Mesmo armazém.
Mesmo Flow.
Mesmo SSCC.
Mesma história.
Outra vez.
Outra vez.
Outra vez.
E depois o COCO parou.
Não porque a aplicação tenha falhado.
Não falhou.
Não porque um teste tenha falhado no sentido habitual.
Não falhou.
Parou porque duas respostas perfeitamente razoáveis produziram uma terceira pergunta.

Sabemos qual é a pergunta.
O Flow sabe porque existe.
O COCO sabe onde procurar a seguir.

O resto pode esperar.

Control. Clarity. Flow.

Provavelmente devíamos parar de dar ideias à COCO.
A experiência anterior devia ser suficiente.
Uma aplicação real.
Navegação real.
Utilizadores.
Funções.
Bases de dados.
Idiomas.
Evidência.

Um caso de estudo respeitável.
Uma conclusão limpa.
Depois alguém mostrou: Logistics in Motion.
Esse foi provavelmente o erro.

Começou com três armazéns
Nada particularmente emocionante.
Três armazéns DEMO.

• Kalsdorf bei Graz.
• Wiener Neustadt.
• Klagenfurt.

Dados sintéticos.
Nenhuma informação de clientes.
Nenhum inventário de produção.

Exatamente o tipo de ambiente onde nada importante deve acontecer.
Depois foi selecionado o primeiro armazém.
E a aplicação adquiriu contexto.
A partir desse momento, cada ecrã tinha mais uma pergunta associada.

Isto ainda pertence ao mesmo armazém?
O idioma muda apenas a interface?
O processo permanece no mesmo passo?
O inventário ainda concorda?
A referência do documento ainda aponta para o evento certo?
O operador vê exatamente o que é necessário para a próxima ação?

De repente, a parte interessante já não era o ecrã.
Era a continuidade entre ecrãs.

A COCO tende a fazer isso.

A logística não é uma coleção de ecrãs
Vista de fora, o software de armazém pode parecer enganosamente simples.
A mercadoria chega.
É armazenada.
Alguém a encomenda.
É feito o picking.
É enviada.
Concluído.
Exceto que existe todo um mundo operacional escondido entre chegado e enviado.
Esperado.
Recebido.
Verificado.
Disponível.
Reservado.
Movido.
Recolhido.
Bloqueado.
Corrigido.
Expedido.
Auditado.

O movimento físico importa.
Mas é a transição de estado que torna esse movimento compreensível para o software.
E quando essas duas realidades deixam de coincidir, alguém acaba por ter um mau dia.



Um armazém é mais fácil de compreender quando o movimento é visível, não apenas registado.
É por isso que o nosso trabalho de logística nunca realmente começou com menus, dashboards, ou tecnologia.
Começa com o Flow material.

Onde entra a informação?
Onde é que muda?
Onde é que se pode perder?

Onde é que alguém é forçado a perguntar a outra pessoa o que aconteceu?
Onde é que um passo manual se torna silenciosamente a parte mais fraca de um processo de outra forma automatizado?
Às vezes a resposta é uma nova interface.
Às vezes uma integração.
Às vezes um scanner.
Às vezes simplesmente um melhor modelo de estado.

Mais software não é automaticamente melhor software.
O objetivo não é a automação pelo seu próprio bem.
O objetivo é um processo que permanece compreensível.

Control. Clarity. Flow.

O processo começa antes do primeiro registo.
Antes da receção de mercadoria.
Antes do picking.
Antes do movimento de inventário.
Antes da primeira transação.
O Flow faz uma pergunta muito básica:
Em que armazém estamos a trabalhar?
Parece quase trivial.
Não é.
O contexto do armazém pertence a tudo o que se segue.
Inventário.
Documentos.
Localizações.
Picking.
Realocações.
Histórico de auditoria.
Exceções.

O processo pode parecer perfeitamente saudável enquanto opera no contexto errado.
Esse é exatamente o tipo de problema que uma captura de ecrã raramente revela.
E exatamente o tipo de fronteira que a COCO gosta de questionar.

O idioma é fácil até deixar de ser
Alemão.
Inglês.
Croata.
Norueguês.
E outros.

Um perfil de utilizador define os idiomas disponíveis.
O operador muda de idioma enquanto a aplicação está ativa.
A interface muda imediatamente.
O processo de negócio não pode.
Essa distinção importa.
O armazém não se move porque a palavra para armazém mudou.
A ordem de picking não recomeça porque o utilizador selecionou outro idioma.
Uma reserva não desaparece.
Uma exceção não pertence subitamente a outra transação.
O processo permanece onde está.
Só a sua representação muda.
Isso parece óbvio.

Até percebermos quantas aplicações tratam uma mudança de idioma quase como uma nova sessão.

Uma aplicação de negócio multilingue não deveria.
O estado de apresentação pode mudar.
O estado de negócio tem de permanecer estável.
Isso torna a mudança de idioma um teste de regressão surpreendentemente útil.
Uma pequena funcionalidade.
Uma linha de falha muito boa.
A COCO gosta de linhas de falha.

Passo a passo, a aplicação começa a acumular histórico
A mercadoria chega.
O processo avança.
A receção de mercadoria é registada.
O inventário muda.
O estado do armazém reflete a nova realidade.
O picking começa.
O stock torna-se reservado.
O operador recebe uma tarefa.

Uma vista móvel reduz todo o processo ao que importa naquele momento exato:
Posição.
Localização de armazenamento.
Quantidade.
SSCC.
Operador.
Nada mais.
Nada menos.
Isso é importante.
A interface móvel não é um segundo processo de negócio.
É outra vista do mesmo processo.
A aplicação de armazém pode saber tudo.
O operário de picking não precisa de saber.
A Clarity nem sempre significa mostrar mais informação.
Às vezes clarity significa ter a disciplina de esconder quase tudo.

Depois alguém digitaliza a localização errada
É aqui que um fluxo de trabalho logístico se torna mais interessante do que uma lista de funcionalidades.
A localização esperada é uma coisa.
A localização digitalizada é outra.
O Flow para.
Não falha.
Para.
Há uma diferença.
O estado do processo permanece visível.
O stock afetado permanece compreensível.
A exceção torna-se explícita.

A Ajuda contextual explica o que é relevante para a situação atual.
O utilizador resolve a discrepância.
O processo continua.
Este momento diz mais sobre o software operacional do que várias páginas de capturas de ecrã do percurso ideal.
A logística real não é difícil quando tudo está correto.
A logística real torna-se difícil quando algo está quase correto.
Um sistema útil não esconde isso atrás de um dashboard verde.
Dá à exceção um estado.

Uma razão.
Um histórico.
E um caminho a seguir.

Os documentos lembram-se do que as pessoas esquecem

À medida que o fluxo de trabalho progride, as referências começam a acumular-se.
ASN.
Receção de mercadoria.
Movimento de armazém.
Picking.
Expedição.
Flow.
A parte interessante não é que os documentos existam.
A parte interessante é que contam a mesma história que o processo.
Porque é que este stock está aqui?
Que receção o introduziu?
Que operação o reservou?
Que picking o consumiu?
Que expedição o moveu para fora?
Foi resolvida uma exceção antes do passo seguinte?
Qual era o armazém ativo?
O que aconteceu antes do estado atual?
Quando o estado e a documentação são produzidos pelo mesmo processo, a rastreabilidade torna-se mais fácil de confiar.
Quando não são, as pessoas acabam por começar a reconstruir o histórico.
Geralmente em Excel.
Geralmente sob pressão.
Geralmente depois de algo já ter corrido mal.
A COCO prefere evidência antes desse momento.
Aparentemente, a COCO também viaja
Houve outra pequena alteração entre execuções.
O Ubuntu teve a sua execução.
O Red Hat Enterprise Linux 10 ficou com a seguinte.
A COCO continuou.
Sem cerimónia.
Sem "modo Red Hat" especial.
Sem fluxo de trabalho reescrito.
Sem teste convenientemente simplificado.
O mesmo Flow.
Terreno diferente por baixo.
Uma execução anterior da COCO já tinha testado a aplicação em Ubuntu Linux.
A atual passou para Red Hat Enterprise Linux 10.
Ambiente de trabalho diferente.
Bibliotecas de sistema diferentes.
Empacotamento diferente.
Ambiente operacional diferente.
Mesmo armazém.
Mesmos estados de negócio.
Mesmas transições de inventário.
Mesmas mudanças de idioma.
Mesma lógica de exceções.
Mesma evidência.
Essa é uma forma bastante boa de testar software multiplataforma.

Não anuncie que é multiplataforma. Mude-o de lugar. Depois veja o que se parte.

Estado do idioma.
Contexto do armazém.
Comportamento de diálogos.
Temporização.
Temas.
Transições de processo.
Tratamento de exceções.
Evidência.
Os sistemas operativos têm formas surpreendentemente criativas de expor suposições.

O Ubuntu expôs algumas.
O Red Hat está a expor outras.
Isso é útil.

Porque a engenharia multiplataforma não é a capacidade de iniciar o executável duas vezes.

É a capacidade de mudar o ambiente sem mudar o significado do processo.
Um operador de armazém não deveria importar-se se a aplicação corre em Ubuntu ou Red Hat.
Uma ordem de picking também não deveria importar-se.
Nem um registo de auditoria.
Se as diferenças de plataforma começarem a mudar o comportamento de negócio, o software não é verdadeiramente multiplataforma.
É apenas portátil.
A COCO parece consideravelmente mais interessada na primeira definição.
Nós também.

A COCO não decide o que significa logística correta
Esta parte importa.
A COCO não se torna uma especialista em armazém apenas por conseguir seguir um fluxo de trabalho de armazém.
Os humanos continuam a definir a correção.
Os humanos decidem quando o inventário fica disponível.
Os humanos definem o que significa uma entrega bloqueada.
Os humanos decidem quem pode corrigir uma quantidade.
Os humanos definem que movimento requer um registo de auditoria.
Os humanos decidem como é uma resolução de exceção válida.
Os humanos decidem quando um envio está verdadeiramente completo.
O trabalho da COCO é diferente.

Repetir.
Observar.
Comparar.
Lembrar.
Deixar evidência.

Depois fazê-lo novamente depois de o software mudar.
E outra vez.
E outra vez.
Sem se aborrecer.
Sem decidir que o resultado da semana passada é provavelmente ainda válido.
Sem saltar a exceção irritante porque o almoço é daqui a doze minutos.
O futuro glamoroso dos testes de IA contém uma quantidade surpreendente de repetição.
Consideramos isso uma funcionalidade.

A evidência muda a conversa
Os testes tradicionais terminam frequentemente com uma frase perfeitamente razoável:
"Funcionou quando o testei."

A COCO está interessada na frase seguinte.

O que exatamente funcionou?
Que armazém?
Que utilizador?
Que idioma?
Que estado de processo?
Que sequência?
Que documento?
Que valor de inventário?
O que aconteceu imediatamente antes do passo de teste?
O que mudou imediatamente depois?
Pode outro engenheiro compreender o resultado sem perguntar à pessoa que realizou o teste?
É aí que o teste de regressão se torna mais do que cliques repetidos.
Um ecrã pode estar correto enquanto o processo está errado.
Uma janela de picking pode parecer perfeita enquanto o inventário já divergiu.
Um documento pode existir enquanto o estado que devia tê-lo criado nunca ocorreu.
Uma aplicação pode mostrar 100% enquanto um registo de auditoria discorda silenciosamente.
A COCO segue o Flow porque é no Flow que estas contradições se tornam visíveis.

Algures entre Control e Flow
Há uma simetria interessante aqui.
Um bom software de logística tenta reduzir a incerteza dentro de uma operação.
Um bom teste tenta reduzir a incerteza sobre o software que o executa.
Um pergunta:
Onde está o artigo?
O outro pergunta:
Como sabemos que o software ainda o sabe?
Um pergunta:
Este movimento foi concluído?
O outro pergunta:
Que evidência prova que o estado mudou corretamente?
Um pergunta:
Pode o próximo turno continuar?
O outro pergunta:
Pode o próximo engenheiro compreender o que aconteceu?
Perguntas diferentes.
O mesmo instinto.
Tornar o estado visível.
Preservar o raciocínio.
Reduzir a quantidade de conhecimento que existe apenas na cabeça de alguém.
Talvez seja essa a ligação que não planeámos originalmente.

Excelência de engenharia sem a faixa
Ninguém clica num botão de Engineering Excellence.
Não existe nenhum.
E provavelmente não deveria existir.
A excelência de engenharia aparece indiretamente.
O contexto do armazém sobrevive a uma mudança de idioma.
O mesmo processo sobrevive a outra plataforma Linux.
Um movimento de stock permanece rastreável.
Um operário de picking móvel vê exatamente o que é necessário e mais nada.
Uma exceção interrompe o processo sem destruir o seu estado.
A janela de ajuda explica o contexto atual em vez de mostrar documentação genérica.
A cadeia de documentos concorda com a sequência operacional.
O próximo engenheiro pode compreender o que aconteceu sem perguntar à pessoa que por acaso estava lá.
Há bastante teatro disponível no software moderno.
A IA pode gerar demonstrações impressionantes.
Os dashboards podem animar-se.
Os números podem mover-se.
Os vídeos podem parecer muito convincentes.
Nada disso prova que duas operações de inventário não possam silenciosamente produzir um resultado incorreto.
Nada disso prova que uma exceção ainda possa ser reconstruída semanas depois.
Nada disso prova que o trabalhador de armazém, o despachante, e o programador estão a olhar para a mesma verdade operacional.

A excelência de engenharia começa num lugar menos fotogénico.

Com consistência.
Com evidência.
Com limites.

Com a vontade de manter as partes aborrecidas aborrecidas.
A fiabilidade invisível raramente produz a captura de ecrã mais dramática.
Até se começar deliberadamente a procurá-la.

Control. Clarity. Flow.
Control é saber que armazém, que processo, e que estado estão ativos.
Clarity é compreender o que mudou, quando mudou, e porquê.
Flow é permitir que a operação continue sem perder a história por trás dela.
Isso funciona para a logística.
Funciona para os testes de software.
Funciona surpreendentemente bem para a própria engenharia.
A primeira experiência Flow deu à COCO a Administration.
Utilizadores.
Funções.
Bases de dados.
Idiomas.
Depois alguém deu-lhe um armazém.
Depois vários idiomas.
Depois picking móvel.
Depois inventário.
Depois realocações.
Depois exceções.
Depois documentos.
Depois outro sistema operativo.
A este ponto, provavelmente devíamos parar de adicionar coisas.
Provavelmente não vamos parar.

Control. Clarity. Flow.

O Ubuntu teve a sua vez.

O Red Hat tem a atual.

O Flow continua a mover-se.

A COCO continua a observar.
E algures a meio da última execução, tornou-se óbvio que há outra pergunta à espera atrás desta.

Nós sabemos o que é.
A COCO sabe o que é.
Tu não sabes.
Ainda.

Podíamos dizer-te.

Mas depois talvez deixasses de verificar se apareceu um novo artigo Insiders.
E isso estragaria a experiência.

À engenheira ou ao engenheiro que abre este repositório pela primeira vez: Bem-vindo.
Talvez esteja aqui porque algo falhou.
Um serviço parou de responder.
Uma implementação comportou-se de forma inesperada.
Um alerta acordou-o a meio da noite.
Ou talvez esteja simplesmente curioso sobre como esta plataforma funciona.
Seja o que for que o trouxe aqui, saiba:
Este projeto foi construído exatamente para momentos como este.
Não para eliminar problemas difíceis.
Mas para tornar os problemas difíceis compreensíveis.
Encontrará código.
Encontrará documentação.
Encontrará especificações.
Mas, mais importante:
Espero que encontre justificações.
Alguém antes de si fez perguntas difíceis.
Alguém reuniu evidências.
Alguém tomou decisões.
Alguém explicou porquê.
Essas explicações fazem parte da plataforma.
Trate-as com o mesmo respeito que o código-fonte.
Um dia, irá melhorar algo.
Talvez seja um bug minúsculo.
Talvez seja uma capacidade totalmente nova.
Seja o que for que altere, lembre-se: Um dia, outra pessoa herdará o seu trabalho.
Deixe-lhe mais do que software funcional.
Deixe-lhe compreensão.
Explique a sua intenção.
Documente os seus pressupostos.
Preserve as suas evidências.
Conte a história por trás da decisão.
Essa história pode um dia poupar a alguém horas - ou dias - de investigação.
Não tenha medo de substituir tecnologia.
Substitua bibliotecas.
Substitua fornecedores.
Substitua modelos de implementação.
Substitua linguagens de programação.
Substitua arquiteturas, se necessário.
Mas antes de substituir uma ideia, compreenda porque é que ela existiu.
Progresso sem compreensão é apenas mudança.
Progresso construído sobre compreensão torna-se evolução.
Haverá momentos em que a plataforma o surpreenderá.
Trate esses momentos como presentes.
Cada surpresa revela algo que a arquitetura ainda não tinha compreendido.
Investigue com paciência.
Reúna evidências.
Melhore com ponderação.
E deixe a lição para aqueles que se seguem.
É assim que o conhecimento de engenharia cresce.
Também haverá momentos em que nada de interessante acontece.
Esses momentos também contam.
Sistemas silenciosos são frequentemente sistemas saudáveis.

Se o COCO recuar para segundo plano,
porque os incidentes se tornam mais curtos,
porque as explicações se tornam mais claras,
porque a integração se torna mais fácil,
porque os engenheiros confiam nas evidências, então a plataforma está a ter sucesso.
Fiabilidade invisível é uma das formas mais elevadas de excelência de engenharia.
Não meça este projeto pelo número de automações que executa.
Meça-o por perguntas como estas:

• As pessoas são interrompidas com menos frequência?
• Os engenheiros compreendem os sistemas mais profundamente?
• As decisões importantes são mais fáceis de explicar?
• O conhecimento operacional sobrevive a mudanças de equipa?
• Os erros repetem-se com menos frequência?
• Os novos engenheiros tornam-se eficazes mais rapidamente?

Esses são os resultados que vale a pena preservar.
Por fim, lembre-se: Nenhum manual está completo.
Nenhuma especificação prevê todos os futuros.
Nenhuma arquitetura sobrevive inalterada para sempre.
Isso não é uma fraqueza.
É um convite.
Observe a realidade.
Questione pressupostos.
Melhore a plataforma.
Ensine aqueles que vêm depois de si.
E quando, um dia, o seu próprio tempo como responsável terminar, deixe um sistema mais calmo, mais claro, mais compreensível, e mais digno de confiança do que aquele que herdou.

Se cada geração fizer isso, o COCO nunca ficará verdadeiramente obsoleto.
Porque o seu maior ativo não será o seu software.
Será a disciplina de engenharia transmitida pelas pessoas que continuam a construí-lo.
Obrigado por se ter tornado um deles.
O próximo capítulo já não está neste manual.
O próximo capítulo está no código que está prestes a escrever.

O Manual da COCO

Porque o software evolui.
Uma boa arquitetura evolui mais devagar.
E uma boa filosofia deveria sobreviver a ambos.

softify.pro