A COCO ataca novamente

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.