Software de código aberto, software de autoatendimento

O senhor já usou aquelas máquinas de caixa de autoatendimento em uma mercearia ou supermercado?

caixa de autoatendimento

O que me fascina nos dispositivos de checkout de autoatendimento é que a loja está obrigando o senhor a fazer o trabalho que eles normalmente pagariam aos funcionários para fazer. Pense nisso por um minuto. O senhor está desempenhando o papel de cliente pagante e o o funcionário do caixa. Sob os olhos atentos das câmeras de segurança e de pelo menos um monitor humano, naturalmente, mas ainda assim. Continuamos a nos examinar. Não apenas de bom grado, mas com entusiasmo. Por esse breve momento, estamos trabalhando para o supermercado com o menor salário possível: nenhum.

Esse é o paradoxo do self-checkout. Mas, para mim, não é nenhum enigma: ninguém mais naquela loja se preocupa em fazer o check-out de Jeff Atwood quase tanto quanto Jeff Atwood. Eu sempre escolho o checkout de autoatendimento, exceto em casos extraordinários. As pessoas com maior interesse no resultado do processo de checkout são as mesmas pessoas que o autoatendimento coloca no comando: eu! Como isso poderia não funcionar? É o alinhamento perfeito do interesse próprio.

Não quero dizer isso como uma crítica aos funcionários do supermercado. Eles são (geralmente) competentes e amigáveis o suficiente. Eu deveria saber; trabalhei durante todo o ensino médio e parte da faculdade como caixa do Safeway. Eu me esforçava ao máximo para ser bom no meu trabalho e fazer com que os clientes passassem pela fila o mais rápido possível. Tenho certeza de que eu conseguiria fazer o check-out de uma pessoa mais rápido do que ela mesma poderia fazer. Mas há apenas um eu e, no máximo, meia dúzia de outros caixas trabalhando na loja, em comparação com as multidões de clientes. Isso não tem escala.

Se o senhor combinar o ângulo do interesse próprio e a questão do dimensionamento, o checkout de autoatendimento parece óbvio, uma vitória para todos. Mas o autoatendimento tem seus próprios problemas:

  • E se o item que o senhor está digitalizando não for encontrado ou não puder ser digitalizado?
  • Algumas das máquinas de autoatendimento têm regras bastante elaboradas e não óbvias para evitar fraudes e roubos. Além disso, a interface do usuário às vezes pode não ser a ideal nas máquinas.
  • Como o senhor lida com cupons? Cartões de fidelidade? A compra de 20 itens do mesmo item? O senhor está escaneando o item errado?
  • As estações de autoatendimento têm pouca gente. A proporção entre funcionários monitores e máquinas de autoatendimento é de aproximadamente 1:4, segundo minha experiência. Se o senhor tiver algum problema, pode acabar esperando mais tempo do que em um caixa tradicional com atendimento humano.
  • Como o senhor registra itens como frutas e legumes que não têm códigos UPC e precisam ser pesados?
  • E quanto a itens incomuns, de formato estranho ou de tamanho grande?
  • Os clientes que têm problemas durante o autoatendimento podem achar que são estúpidos ou que fizeram algo errado. Adivinhe onde eles vão colocar a culpa por esses sentimentos?

Há certos rituais para usar as máquinas de caixa de autoatendimento. E nós sabemos disso. Nós, programadores, entendemos fundamentalmente os obstáculos que os caixas de autoatendimento fazem os clientes passar. Afinal, elas são dispositivos projetados por nossos colegas programadores. Cada item tem de ser escaneado e, em seguida, cuidadosa e individualmente colocado na área de ensacamento, que funciona como uma balança para verificar se o item foi movido para lá. Um de cada vez. Em uma sequência rigorosa. Repetido exatamente da mesma forma todas as vezes. Vivemos esse sistema todos os dias; ele é completamente natural para um programador. Mas não é natural para as pessoas comuns. Já vi muitos clientes na minha frente lutando com os caixas de autoatendimento, confusos com o funcionamento desse dispositivo misterioso que parece tão dolorosamente óbvio para um programador. Fico frustrado a ponto de quase querer correr e ajudar o senhor mesmo. O que anularia o propósito de um dispositivo de autoatendimento.

Estava pensando nisso enquanto lia o artigo de Michael Meeks, Medindo o verdadeiro sucesso do OpenOffice.org. Ele chega a algumas conclusões deprimentes sobre o estado atual do OpenOffice, um concorrente de código aberto de alto nível do Microsoft Office:

Por mais cruas que sejam, as estatísticas mostram um quadro de lento desinteresse por parte da Sun, combinado com uma espetacular falta de crescimento na comunidade de desenvolvedores. Em um projeto saudável, esperaríamos ver um grande número de desenvolvedores voluntários envolvidos, além disso, esperaríamos ver um grande número de empresas semelhantes contribuindo para o conjunto de códigos comuns; não vemos isso no OpenOffice.org. Na verdade, muito pelo contrário. Na verdade, é exatamente o contrário. Parece que temos o menor número de desenvolvedores ativos no OO.o desde o início dos registros: 24, o que contrasta negativamente com a baixa recente do Linux, de mais de 160. Mesmo que seja visto da maneira mais positiva, o OpenOffice.org está, na melhor das hipóteses, estagnado do ponto de vista do desenvolvimento.

Isso é preocupante, porque o desenvolvimento de software de código aberto é o melhor setor de autoatendimento. Como observa Michael, o projeto está, infelizmente, se prejudicando:

Acabar com o sistema político ossificado, paralisado e gerrymandered do OpenOffice.org. Em vez disso, coloque os desenvolvedores (todos eles) e aqueles que contribuem ativamente no comando. Isso, por sua vez, deve ajudar a eliminar as muitas etapas do processo, terrivelmente desmotivadoras e disfuncionais, usadas atualmente para impedir que o código seja incluído, e deve ajudar a atrair voluntários. Quando eles forem atraídos e estiverem ativos, ouça-os sem ser condescendente.

Na verdade, uma vez que o senhor destrói os dois motivadores intrínsecos de autodeterminação e autonomia em um projeto de código aberto, eu diria que a situação não é melhor do que a de um software tradicional de código fechado. O senhor criou uma máquina de checkout de autoatendimento tão dolorosa de usar, tão estranha de operar, que dá ao conceito de autoatendimento um nome ruim. E isso é de partir o coração, porque o autoatendimento é a alma do código aberto:

Por que meu bug não foi corrigido? Por que a interface do usuário ainda é tão desagradável? Por que o desempenho ainda é ruim? Por que ele consome mais memória do que o necessário? Por que a inicialização está ficando mais lenta? Por quê? Por quê? A resposta está nos desenvolvedores: O senhor nos ajudará a tornar o OpenOffice.org melhor?

Para que os projetos de software de código aberto sobrevivam, eles devem garantir que apresentem o mínimo possível de barreiras ao desenvolvimento de software de autoatendimento. E quaisquer barreiras que apresentem devem ser muito baixas. radicalmente baixo. Pedir a seus clientes que aprender programação C++ para melhorar sua experiência com o Open Office está muito longe de pedir que eles operem um scanner e uma tela sensível ao toque para melhorar sua experiência no caixa. E se o senhor não consegue convencer um público de programadores, que estão inclinados a entender e adorar esse tipo de coisa, quem exatamente são os senhores? que o senhor espera convencer?

Portanto, se o senhor está tendo dificuldade em fazer com que os desenvolvedores de software participem do seu projeto de código aberto, eu diria que a comunidade não está falhando no seu projeto. Seu projeto está falhando com a comunidade.