É relativamente comum empresas que não sejam grandes usuárias de seus próprios produtos. Por exemplo, a Embraer pode até ter uma pequena frota de aviões executivos, mas ela não é uma companhia aérea com dezenas de aviões, centenas de rotas e milhões de clientes. É até mesmo possível que a empresa jamais opere sequer uma cópia de seus produtos. Por exemplo, uma fábrica de caldeiras industriais, daquelas feitas para refinarias de petróleo, jamais irá operar um de seus produtos. Como saber se os produtos realmente estão atendendo aos clientes? Bem, nestes casos é absolutamente necessário que a empresa esteja bem sintonizada para ouvir seus clientes e suas reais necessidades.

Mas o que acontece se o fabricante *também* for um grande usuário? Isso pode ser uma grande vantagem, pois os usuários são mais acessíveis e podem até mesmo ser obrigados a testar os novos produtos e compelidos a dizer o que acharam, mesmo antes do produto ser publicamente divulgado. Pois é isso que acontece na Microsoft: a Microsoft é uma grande usuária de vários de seus produtos; seus funcionários são comumente compelidos a usar as versões mais novas, muitas vezes até mesmo antes do lançamento. Isso tem até um apelido interno “dogfooding”, uma alusão ao dono que come a comida que prepara para o seu cachorro, de forma a garantir a sua qualidade.

Esta atitude é comum no ramo de software e não apenas na Microsoft. Por exemplo, em 1980 a Apple proibiu o uso interno de máquinas de escrever, de forma a forçar o uso de computadores mesmo em tarefas de escritório, na época uma novidade.

Evidentemente para esta tática produzir bons efeitos, os usuários internos devem utilizar os produtos de forma parecida aos usuários externos. Se os usuários internos utilizarem os produtos de forma diferente, corre-se o risco de se criar uma realidade interna diferente da realidade externa e aí os produtos param de refletir as reais necessidades dos usuários de mercado.

Um caso delicado são as ferramentas de desenvolvimento: evidentemente a Microsoft é a maior empresa de software do mundo, é justo supor que ter a Microsoft como usuária de seus próprios produtos de desenvolvimento ajudará a criar ferramentas mais avançadas para o mercado, pois teremos como cliente um usuário extremamente exigente. O problema é que eu acredito que as necessidades da Microsoft estão hoje muito além das necessidades da maioria dos seus clientes de ferramentas de desenvolvimento, geralmente organizações bem menores desenvolvendo aplicativos “line of business - LOB” (comerciais). Não porque os clientes sejam “incompetentes”, “burros” ou “desleixados”. É que suas necessidades são efetivamente diferentes. Por exemplo, a Microsoft usa integração contínua, onde um servidor de build compila o projeto a cada check-in de código, há vários anos como forma de descobrir cedo problemas de integração; eu não conheço ninguém que faça isso – nem quem deva. Outro exemplo: quando a Microsoft cria um componente do Office ou do Windows, ele será usado vendido por um preço individual irrisório e utilizado por centenas de milhões de pessoas diariamente; a exigência de qualidade é absurdamente alta e efetivamente existem diversos recursos para garantir isso, como por exemplo, rotinas de testes automatizados. Quem mais precisa da mesma qualidade e está disposto a multiplicar seu custo de desenvolvimento para implantar com eficácia “Test Driven Development”? Pouca gente.

Mas será que a Microsoft se preocupar com a parte mais sofisticada do mercado causa algum prejuízo, afinal “é só não usar o recurso sofisticado”? Eu acredito que sim, por duas razões:

1. Ela induz os desenvolvedores a usar esses recursos sofisticados como se eles fossem uma obrigação, sem uma análise de custo-benefício;

2. Ela “se esquece” do mercado mais simples; a prova disso é que os produtos como Visual Basic 6 e Fox Pro eram efetivamente mais simples e produtivos para uma parcela importante do mercado e estes desenvolvedores ficaram órfãos e acabam migrando para produtos como o PHP.

A Microsoft é uma empresa muito bem-sucedida e isso deve-se em parte ao uso de boas ferramentas de desenvolvimento. É difícil argumentar contra o sucesso, mas eu realmente acho que eles deixaram para trás uma grande quantidade de desenvolvedores de aplicativos LOB, que eram bem atendidos pelo Clipper e depois pelo Visual Basic e Delphi.