Regras de colaboração

Líderes corporativos que buscam crescimento, aprendizado e inovação podem encontrar a resposta em um lugar surpreendente: a comunidade de software de código aberto. Sem saber, talvez as pessoas que trouxeram o Linux para você sejam praticantes virtuosos de novos princípios de trabalho que produzem equipes energizadas e custos mais baixos. Nem estão sozinhos. De qualquer forma, o Linux é um produto altamente competitivo. Estima-se que mais servidores sejam executados no Linux do que em qualquer outro sistema operacional. Ele superou o UNIX como oferta comercial. E suas vantagens vão além do custo e da qualidade, até a velocidade com que é aprimorado e aprimorado. Enquanto os partidários debatem suas limitações técnicas e o tratamento da propriedade intelectual, eles concordam que o sucesso do produto é inseparável de seu modo de produção distinto. Especificamente, o Linux é a criação de uma comunidade essencialmente voluntária e auto-organizada de milhares de programadores e empresas. A maioria dos líderes venderia suas avós por forças de trabalho que colaboram de forma tão eficiente, fácil e criativa quanto os autodenominados “hackers” do Linux. Mas Linux é software, e software é meio estranho. A Toyota, no entanto, é uma empresa como qualquer outra — ou seja, qualquer outra consistentemente classificada entre as organizações de melhor desempenho do mundo. A montadora há muito tempo é líder em qualidade e produção enxuta, e o sucesso do Prius híbrido estabeleceu sua reputação como inovadora. Descobrimos que os métodos gerenciais da Toyota se assemelham, em vários de seus fundamentos, ao funcionamento da comunidade Linux; o Sistema Toyota de Produção (TPS) deve parte de sua alardeada capacidade de resposta às características de código aberto. Na verdade, a própria Toyota está evoluindo para um híbrido entre uma hierarquia convencional e uma rede auto-organizada semelhante ao Linux. (Ao longo deste artigo, usamos o termo “Linux” como abreviatura para a comunidade de software livre/de código aberto que desenvolveu e continua refinando o sistema operacional e outros programas de código aberto. Usamos “Toyota” como abreviatura para o Sistema Toyota de Produção, que compreende a Toyota e seus fornecedores diretos — “nível um” na linguagem automotiva — no Japão e nos Estados Unidos.) A Toyota é notavelmente semelhante ao Linux na forma como combina as principais características dos mercados e das hierarquias. Assim como os mercados, as comunidades Toyota e Linux podem se auto-organizar, mas, diferentemente dos mercados, elas não usam dinheiro ou contratos em momentos críticos. Assim como as hierarquias, a Toyota e o Linux têm baixos custos de transação, mas, diferentemente das hierarquias, seus membros podem pertencer a muitas organizações diferentes (ou a nenhuma) e não estão vinculados a funções e responsabilidades específicas e predefinidas. E, como as hierarquias, os membros compartilham um propósito comum, mas esse propósito emana da automotivação e não dos incentivos ou sanções externas que as hierarquias geralmente impõem. Nesses aspectos, a Toyota e o Linux representam o melhor dos dois mundos. Uma análise de suas características comuns sugere como as organizações de alto desempenho permanecem produtivas e inventivas mesmo sob condições difíceis. Acreditamos que essas lições podem melhorar significativamente a forma como o trabalho na maioria das organizações é feito. terça-feira, 2 de dezembro de 2003 Perto da meia-noite, Andrea Barisani, administradora do sistema no departamento de física da Universidade de Trieste, descobriu que um atacante havia atingido o servidor Gentoo Linux de sua instituição. Ele rastreou a violação até um ponto vulnerável no kernel Linux e outro no rsync, um mecanismo de transferência de arquivos que replica automaticamente os dados entre computadores. Esse foi um ataque sério: qualquer penetração do rsync pode comprometer arquivos em milhares de servidores em todo o mundo. Barisani acordou alguns colegas, que o colocaram em contato com Mike Warfield, pesquisador sênior da Internet Security Systems em Atlanta, e com Andrew “Tridge” Tridgell, um conhecido programador Linux na Austrália em cuja tese de doutorado o rsync foi baseado. Eles direcionaram a mensagem de Barisani (tornada anônima por motivos de segurança) para outro australiano, Martin Pool, que trabalhava para a Hewlett-Packard em Canberra e era líder no desenvolvimento do rsync. Embora Pool não fosse mais responsável pelo rsync (ninguém era), ele imediatamente ligou para o e-mail, primeiro questionando Warfield e Dave Dykstra (outro colaborador inicial do desenvolvimento do rsync, que morava na Califórnia) sobre vulnerabilidades e depois ajudando Barisani a rastrear a falha linha por linha. Pela manhã, horário de Trieste, Pool e Barisani haviam encontrado a localização precisa da brecha. Pool entrou em contato com o atual grupo de desenvolvimento do rsync, enquanto Barisani se conectou com a afiliação frouxa de amadores e profissionais que empacotam o Gentoo Linux, e ele postou um aviso prévio no site do Gentoo. Pool e Paul “Rusty” Russell (um colega de Canberra que trabalha para a IBM) trabalharam durante a noite australiana para escrever um patch e, em cinco horas, os desenvolvedores de usuários do Gentoo começaram a testar a primeira versão. Enquanto isso, Tridge elaborou uma descrição da vulnerabilidade e sua correção, certificando-se (por insistência de Pool) de creditar Barisani e Warfield por seus esforços nos bastidores. Na quinta-feira à tarde, horário de Canberra, o anúncio e o patch foram publicados no site do rsync e, portanto, distribuídos para usuários Linux em todo o mundo. Alguns dias após a emergência, depois de recuperar o sono, Barisani se ofereceu para colaborar com Warfield na criação de um sistema de servidores deliberadamente vulneráveis para fazer com que o hacker do sistema se revelasse. Ninguém autorizou ou dirigiu esse esforço. Ninguém — amador ou profissional — foi pago pela participação ou teria sido sancionado por não participar. O trabalho de ninguém dependia de impedir o ataque. Ninguém se acendeu por medo de responsabilidade legal. De fato, a maior comunidade de usuários foi mantida informada sobre todos os desenvolvimentos. No entanto, apesar da necessidade da mais alta segurança, um grupo de cerca de 20 pessoas, quase nenhuma das quais já havia se conhecido, empregadas por uma dúzia de empresas diferentes, vivendo em tantos fusos horários e se afastando de suas descrições de trabalho, realizou em cerca de 29 horas o que poderia levar semanas ou meses para colegas em cubículos adjacentes. É tentador descartar isso como um exemplo de esquisitice hacker — admirável, sim, mas nada a ver com negócios reais. Considere, no entanto, outra história. sábado, 1 de fevereiro de 1997 Às 4h18, ocorreu um incêndio na fábrica número 1 de Kariya da Aisin Seiki, uma grande fornecedora japonesa de peças automotivas. Em poucos minutos, o prédio e praticamente todo o maquinário especializado em seu interior foram destruídos. O Kariya Number 1 produz 99% do fluido de freio — válvulas proporcionadoras, ou válvulas P, para as operações japonesas da Toyota — peças exigidas por cada veículo que a Toyota fabrica. E a Toyota, fiel aos seus princípios just-in-time, tinha menos de um dia de estoque. O Sistema de Produção Toyota japonês enfrentou a possibilidade de uma paralisação total com duração de meses. Em poucas horas, os engenheiros da Aisin se reuniram com seus colegas da Toyota e com outros fornecedores de primeiro nível da Toyota. O grupo concordou em improvisar o máximo possível de produção. À medida que as notícias se espalhavam pela rede de fornecedores, alguns de nível dois se ofereceram para desempenhar funções de liderança. A Aisin enviou plantas das válvulas a qualquer fornecedor que as solicitou e distribuiu todas as ferramentas, matérias-primas e trabalhos em andamento que não danificados pudessem ser recuperados. Os engenheiros da Aisin e da Toyota ajudaram a montar linhas de produção em 62 locais — oficinas mecânicas não utilizadas, a própria oficina de prototipagem da Toyota e até mesmo uma fábrica de máquinas de costura de propriedade da Brother. A Denso, a maior fornecedora da Toyota, se ofereceu para gerenciar a logística confusa das válvulas de envio para Aisin para inspeção e depois para as linhas de montagem paralisadas da Toyota. Todos ficaram surpresos quando uma pequena fornecedora de eletrodos de soldagem, a Kyoritsu Sangyo, foi a primeira a entregar válvulas de qualidade de produção para a Toyota — 1.000 delas, apenas 85 horas após o incêndio. Outros seguiram rapidamente, e a Toyota começou a reabrir as linhas de montagem na quarta-feira. Cerca de duas semanas após a paralisação, toda a cadeia de suprimentos estava de volta à produção total. Seis meses depois, Aisin distribuiu um guia de resposta a emergências contendo lições extraídas da experiência e recomendando procedimentos para responder a tais situações no futuro. Nenhum indivíduo ou organização planejou esse esforço: em vez disso, pessoas e empresas intervieram onde puderam. Os concorrentes colaboraram. Ninguém na época foi pago por contribuir. Meses depois, a Aisin compensou as outras empresas pelos custos diretos das válvulas que haviam entregue. A Toyota concedeu a cada fornecedor de primeiro nível um honorário com base nas vendas atuais da montadora, incentivando, mas não exigindo, que fizessem o mesmo com seus próprios fornecedores de nível dois. Poucas comunidades parecem mais diferentes do que o mundo anárquico, cafeinado e hirsuto dos hackers e o mundo disciplinado, que toma chá e é limpo, da engenharia automotiva japonesa. Mas os paralelos entre essas histórias são impressionantes. Em ambos, os indivíduos se encontraram e assumiram funções sem um plano ou uma estrutura de comando e controle estabelecida. Uma extensa rede humana se organizou em horas e “invadiu” uma ameaça. Pessoas, equipes e empresas trabalharam juntas sem contratos legais ou pagamentos negociados. E apesar da falta de qualquer medida autoritária ou financeira, essas pessoas trabalhavam como o inferno para resolver o problema. Poucas comunidades parecem mais diferentes do que o mundo anárquico, cafeinado e hirsuto dos hackers e o mundo disciplinado, que toma chá e é limpo, da engenharia automotiva japonesa. Agora, obviamente, essas foram respostas de emergência. Mas uma análise das operações diárias da comunidade Linux e do Sistema Toyota de Produção revela que essas respostas foram apenas intensificações da forma como as pessoas já estavam trabalhando. Obsessão, interação e um toque leve As regras dos mercados são sobre dinheiro e contratos. As regras das hierarquias são sobre autoridade e responsabilidade. Mas no cerne das comunidades Linux e Toyota estão regras sobre três coisas completamente diferentes: como indivíduos e pequenos grupos trabalham juntos; como e com que amplitude eles se comunicam; e como os líderes os orientam em direção a um objetivo comum. Uma disciplina de trabalho comum. As comunidades Linux e Toyota são compostas por engenheiros, então os membros têm as mesmas habilidades que seus colegas e falam a mesma língua. Mas esses grupos são muito mais disciplinados e rigorosos em sua abordagem de trabalho do que outras comunidades de engenharia. Ambos enfatizam a granularidade: prestam atenção aos pequenos detalhes, eliminam problemas na origem e cortam qualquer coisa parecida com excesso, seja trabalho, código ou material. Os membros do Linux, por exemplo, compartilham a obsessão por escrever o mínimo de código, compilar a produção de cada dia antes de passar para a próxima e eliminar as falhas de programação à medida que avançam. Por sua vez, os engenheiros do TPS são incansáveis na aplicação de ciclos curtos de tentativa e erro, concentrando-se em apenas uma coisa por vez, entrando e observando os processos reais. Ambos os grupos levam esses princípios a extremos aparentes. Os programadores Linux reduzem o código em busca não da eficiência computacional, mas da elegância. Os engenheiros da Toyota rejeitam estampas para o capô da Lexus, embora sejam perfeitas e totalmente dentro das especificações, porque o brilho, aos olhos deles, carece de brilho. Comunicação generalizada e granular. Nas comunidades Linux e Toyota, as informações sobre problemas e soluções são compartilhadas amplamente, com frequência e em pequenos incrementos. A maior parte da comunicação de hackers Linux não é entre indivíduos, mas por meio de postagens em listservs abertos e pesquisáveis. Qualquer pessoa pode revisar o histórico de versões do código e os debates do Listserv — não resumos executivos ou resumos, mas a própria atividade bruta. E cada contribuição de código é testada por dezenas de pessoas. Como diz uma famosa metáfora mista de código aberto: “Com mil olhos, todos os insetos são superficiais”. O upload médio para o kernel Linux é de apenas uma dúzia de linhas de código. A versão alfa funcional é recompilada a cada 24 horas, para que os hackers reconciliam seus esforços quase continuamente. Se alguém trabalhasse isoladamente por seis meses até mesmo com a contribuição mais brilhante, ela provavelmente seria rejeitada por falta de compatibilidade com os esforços dos outros. A filosofia de melhoria contínua da Toyota também compreende mil pequenas colaborações. Os engenheiros da Toyota são famosos por “perguntar por que cinco vezes” para acompanhar uma cadeia de causas e efeitos até a raiz do problema. Isso não é um clichê insípido sobre pensar profundamente. Muito pelo contrário, na verdade. O mérito do preceito está justamente em sua superficialidade. Dizer que B causa A é simplista — todas as complexidades de várias interações se resumem a uma única causa e efeito. Mas a cadeia de pensamento necessária para descobrir que C causa B e D causa C leva você rapidamente a um novo domínio, provavelmente o de outra pessoa. Então, em vez de inventar soluções complexas dentro de seus próprios domínios, os engenheiros devem buscar soluções simples além deles. “Fazer seus porquês”, como a prática é conhecida, não tem nada a ver com profundidade, mas com amplitude. E, assim como no Linux, os protocolos de comunicação da Toyota reforçam essa disciplina. Cada reunião aborda apenas um tópico e leva a um resultado específico, mesmo que isso signifique que as mesmas pessoas se reúnam mais de uma vez por dia. As aulas são escritas em um formato padrão em uma única folha de papel A3. E todo mundo aprende a criar esses relatórios, até a dobra do documento que mostra os pontos principais e oculta os detalhes. Líderes como conectores. Em todos os níveis, os líderes de Linux e TPS desempenham três funções essenciais. Eles instruem os membros da comunidade, geralmente por exemplo, nas disciplinas que acabamos de descrever. Eles articulam metas claras e simples para cada projeto com base em sua visão estratégica. E eles conectam pessoas, pelo mérito de estarem muito bem conectados. Os principais programadores de Linux processam mais de 300 ou 400 e-mails diariamente. Fujio Cho, presidente da Toyota, gerencia de forma semelhante inúmeras interações diárias que transcendem a cadeia de comando normal. Nenhuma comunidade trata a liderança como uma disciplina distinta da prática. Pelo contrário, a credibilidade e, portanto, a autoridade dos líderes derivam de sua proficiência como profissionais. O conteúdo das comunicações staccato dos líderes é menor sobre trabalhar do que issoé trabalhar. (Quando o criador do Linux, Linus Torvalds, envia suas dezenas de e-mails diários, ele escreve quase tanto na linguagem de programação C quanto em inglês.) Nas comunidades Linux e Toyota, liderar não é tratado como uma disciplina distinta de fazer. Pelo contrário, a autoridade dos líderes deriva de sua proficiência como profissionais. Ocasionalmente, os líderes precisam realizar atos tradicionais de liderança, como arbitragem de conflitos. Isso, no entanto, é a exceção e é visto como uma pequena falha do sistema. A suposição padrão é que, na medida do possível, os gerentes não gerenciam no sentido tradicional: a rede humana gerencia a si mesma. No Linux, as prioridades de desenvolvimento são decididas não por um CEO, mas por milhares de hackers votando com os pés escolhendo em que trabalhar. Esse tipo de autogestão radical não acontece na Toyota, exceto em emergências. Mas mesmo nas operações diárias, um único trabalhador de produção que vê um problema de qualidade pode parar a linha, e as equipes de projeto têm ampla liberdade para aproveitar os recursos, tomar decisões de compra e buscar as prioridades que definiram para si mesmas. Construindo redes humanas vibrantes As empresas que preparam as bases para a colaboração de alto desempenho devem seguir estes princípios: Implemente tecnologia colaborativa generalizada. Mantenha-o simples e aberto: “pequenos pedaços unidos frouxamente”, em Manifesto Cluetrain A frase feliz do coautor David Weinberger. As ferramentas devem funcionar em conjunto por meio de padrões comuns e ser tão compatíveis quanto possível com as do resto do mundo. Pense nas opções, não na integração, na adaptabilidade, não na eficiência estática. Mantenha o trabalho visível. A menos que haja uma boa razão para não fazê-lo, deixe que todos vejam o verdadeiro trabalho de todos. Permita que as pessoas aprendam a filtrar e classificar por si mesmas. Não abstraia, resuma ou canalize. A forragem é boa. Coloque-o ao alcance de todos. Crie comunidades de confiança. Quando as pessoas confiam umas nas outras, é mais provável que colaborem de forma livre e produtiva. Quando as pessoas confiam em suas organizações, é mais provável que doem de si mesmas agora, na expectativa de recompensas futuras. E quando as organizações confiam umas nas outras, é mais provável que compartilhem propriedade intelectual sem se sufocar com legalismos. Pense de forma modular. A reengenharia consistia em pensar linearmente: gerenciar o processo de ponta a ponta em vez de funções discretas. Essa abordagem promove a eficiência focada, mas inibe a variedade e a adaptabilidade. A modularidade é o contrário: sacrificar a eficiência estática pelo valor recombinante das opções. Pense em equipes e processos modulares. Quanto melhor, melhor. Incentive o trabalho em equipe. Comemore os sacrifícios que as equipes fazem pela empresa em geral, incluindo clientes e fornecedores. Desmonte métricas de desempenho individualizadas e recompensas que colocam as pessoas umas contra as outras. Transações baratas entre muitos estimulam mais inovação do que incentivos caros voltados para poucos. Recompense o grupo e o grupo o recompensará. Juntos, esses três princípios geram um sistema que se adapta continuamente. Repetidamente, as ideias são formuladas em pacotes restritos e testáveis; elas são comunicadas com atenuação mínima por meio de conexões estabelecidas, diretas, de pessoa a pessoa; e, quando os vínculos estão ausentes, líderes e profissionais amplamente conectados os criam conforme necessário. Isso é disciplina, mas não a disciplina de conformidade produzida por controles e incentivos. Pelo contrário, ela se assemelha à disciplina da ciência. Como as comunidades científicas, esses sistemas dependem de procedimentos comuns, regras comuns para comunicação e testes e objetivos comuns claramente compreendidos. O comportamento individual é rigorosamente cauteloso, mas a conquista coletiva é marcada pela inovação contínua e radical. O que eles sabem e como sabem disso No centro do Linux e do Sistema Toyota de Produção, então, está um conjunto de práticas de trabalho, comunicação e liderança que contribuem para uma nova forma de colaboração. Essa colaboração também depende de dois componentes de infraestrutura: um conjunto compartilhado de conhecimento e ferramentas universalmente disponíveis para movimentar o conhecimento. Propriedade intelectual comum. A Licença Pública Geral sob a qual o Linux é publicado exige que todos os distribuidores disponibilizem seu código-fonte gratuitamente para que outros possam corrigi-lo livremente. Esse princípio viral impede que o código seja armazenado em produtos proprietários. Essa transparência, por sua vez, quebra a distinção entre produtor e usuário. Um “cliente” sofisticado como Andrea Barisani é, na verdade, um usuário-desenvolvedor, que corrige falhas e adiciona recursos para seu próprio benefício, depois compartilha essas melhorias com todos os outros. Essa função é impossível quando o código proprietário é licenciado por um fornecedor comercial. Da mesma forma, a cadeia de suprimentos da Toyota se baseia no princípio de que, embora o conhecimento do produto (como um modelo) seja propriedade intelectual de alguém, o conhecimento do processo é compartilhado. Isso quebra algumas distinções entre as empresas. Os fornecedores da Toyota compartilham regularmente amplas lições de melhoria de processos tanto vertical quanto lateralmente, mesmo com seus concorrentes. No Japão, os fornecedores geralmente são exclusivos de um único OEM, portanto, o benefício coletivo dessas informações compartilhadas permanece dentro da cadeia de suprimentos da Toyota. Mas mesmo nos Estados Unidos, onde a Toyota é apenas um dos vários clientes da maioria de seus principais clientes, a montadora faz a mesma coisa por meio da Bluegrass Automotive Manufacturers Association, que dissemina as melhores práticas para todos os membros. Tecnologia simples e abrangente. Embora a informação seja a força vital das comunidades Linux e TPS, seus sistemas de circulação são surpreendentemente rudimentares. Os desenvolvedores de Linux produzem software de última geração usando tecnologia de comunicação não mais sofisticada do que e-mail e ListServs, mas essas ferramentas mundanas são usadas por todos. De fato, o valor atribuído à universalidade é tão grande que e-mails em texto simples, em vez de formatados, são a norma, garantindo que as mensagens apareçam exatamente da mesma forma para todos os destinatários. A Toyota, cujos produtos também são de última geração, também prefere uma tecnologia interna simples e abrangente. Um compartimento kanban vazio indica a necessidade de reabastecimento de peças; um pedaço de fita adesiva no piso da linha de montagem distribui os tempos de conclusão das tarefas em um veículo em movimento. Os problemas de controle de qualidade na linha de montagem são anunciados por meio de pagers e monitores de TV. E todo mundo recebe o alerta. Até mesmo Ray Tanguay, chefe da Toyota Canada, é chamado sempre que uma falha é encontrada na última remessa da Lexus no cais em Long Beach, Califórnia, ou em um compartimento de serviço em qualquer lugar da América do Norte. O poder da confiança e do aplauso Essas colaborações extremamente ricas e flexíveis têm consequências psicológicas positivas para os participantes e poderosas consequências competitivas para suas organizações. Essas consequências são o rico conhecimento comum, a capacidade de organizar equipes de forma modular, uma motivação extraordinária e altos níveis de confiança. Rico conhecimento semântico. Uma rigorosa disciplina de trabalho, propriedade intelectual comum e compartilhamento constante se combinam para distribuir o conhecimento de forma ampla e relativamente uniforme nas redes humanas. Esse conhecimento inclui não apenas as informações formais e sintáticas encontradas nos bancos de dados, mas também o conhecimento ambíguo e semanticamente rico sobre conteúdo e processo, que é a moeda da colaboração criativa. O que queremos dizer com o brilho de uma estampagem corporal com brilho insuficiente? O que, exatamente, devemos discutir com a empresa siderúrgica para corrigir um problema tão mal definido? Esse tipo de pergunta sem resposta fácil é continuamente discutida e resolvida em milhares de colaborações de pequenas equipes. O pensamento diferenciado resultante e o vocabulário comum mais rico sobre esses assuntos são devolvidos ao pool de conhecimento, onde estão disponíveis para refinamento adicional por toda a comunidade. Agrupamento modular. A modularidade é um princípio de design pelo qual um processo ou produto complexo é dividido em partes simples conectadas por regras padrão. Em arranjos modulares de equipes, cada equipe se concentra em tarefas pequenas e simples que, juntas, formam um todo maior. A modularidade permite que uma organização realize vários experimentos paralelos, fazendo muitas apostas pequenas em vez de algumas grandes. Os fornecedores da Toyota se organizaram dessa forma para fabricar válvulas P, operando parcialmente por direção, mas principalmente por meio de voluntariado para fazer o que cada um sabia de melhor. O grupo Gentoo, os especialistas em segurança da Tridge e o círculo de ex-alunos do rsync de Pool eram módulos preexistentes e sobrepostos que misturavam e combinavam funções conforme a emergência exigia. Quando mapeamos os padrões de colaboração diária em todo o esforço de desenvolvimento do kernel Linux, descobrimos que esses arranjos modulares são generalizados e, até certo ponto, se encaixam uns nos outros. Isso cria uma espécie de organograma dinâmico — um gráfico que ninguém escreveu, mas que permite que a comunidade se expanda e se adapte sem cair no caos. Motivação intrínseca. As comunidades Linux e TPS dissociam dinheiro das principais transações. No entanto, apesar dos fracos incentivos financeiros, eles têm um nível de motivação maior do que o encontrado em ambientes convencionais. Os psicólogos descobriram consistentemente que cenouras monetárias e medidas de responsabilidade motivam as pessoas a realizar tarefas restritas e específicas, mas geralmente desencorajam as pessoas de irem além delas. Admiração e aplausos são estimulantes muito mais eficazes de um comportamento superior. “A reputação pessoal do desenvolvedor está associada a cada lançamento”, explicou Linus Torvalds ao colunista de tecnologia Robert Cringely em 1998. “Se você está criando algo para dar de presente ao mundo, algo que representa para milhões de usuários sua filosofia de computação, você sempre o tornará o melhor produto possível.” Cenouras monetárias e medidas de responsabilidade motivam as pessoas a realizar tarefas restritas e específicas. Admiração e aplausos são estimulantes muito mais eficazes de um comportamento superior. Os psicólogos também enfatizam a importância motivacional da autonomia. Os programadores Linux decidem por si mesmos como e onde contribuir e têm a satisfação de produzir algo cuja qualidade é definida não por um departamento de marketing nem por contadores, mas por seus próprios padrões exigentes. O coautor Bob Wolf e Karim Lakhani, do MIT, entrevistaram mais de 800 desenvolvedores de usuários e mais da metade disse que seu trabalho de código aberto é o empreendimento mais valioso e criativo em suas vidas profissionais. O Sistema Toyota de Produção não oferece uma autonomia tão extrema, é claro, e os funcionários não trabalham de graça. Mas, em comparação com seus colegas do resto da indústria automobilística, os trabalhadores da TPS desfrutam de menos controles, maior incentivo à iniciativa individual, menos métricas associadas ao desempenho individual e mais aplausos dos colegas. O orgulho profissional e corporativo, e não o honorário da Toyota, foi a recompensa para a equipe da Kyoritsu Sangyo quando entregou o primeiro lote de válvulas P. Esse mesmo orgulho é sentido por um trabalhador júnior da linha de montagem quando seus colegas confiam nele para experimentar melhorias no processo e parar a linha se algo der errado. Altos níveis de confiança. Quando as informações fluem livremente, a reputação, mais do que a reciprocidade, se torna a base da confiança. Operando sob constante escrutínio, o que é desafiador, mas não hostil, os trabalhadores sabem que sua reputação está em risco e isso serve como garantia de bom comportamento, o equivalente a contratos em um mercado ou auditorias em uma hierarquia. Daí a obsessão da comunidade Linux em reconhecer contribuições de código e incluir endereços de e-mail pessoais nos campos de comentários do Listservs. Daí o generoso crédito público concedido a Barisani e Warfield. Daí a celebração coletiva dos esforços heróicos de Kyoritsu Sangyo. Com sua reputação em jogo, as pessoas têm menos probabilidade de agir de forma oportunista. Com as mesmas informações disponíveis para todos, há menos chances de uma parte explorar a ignorância da outra. E com um vocabulário e uma forma de trabalhar comuns, ocorrem menos mal-entendidos. Esses fatores impulsionam a confiança, o capital social fundamental dessas comunidades. A confiança importaria menos se não houvesse nenhum custo em sair dessas redes ou se as transações fossem de tamanhos radicalmente diferentes (já que isso tentaria pessoas ou empresas a violar as regras quando surgisse uma grande oportunidade). Mas nas comunidades Linux e Toyota, entrar no círculo interno é um privilégio conquistado com dificuldade, e ambas operam em muitas pequenas bolsas. E, claro, onde a confiança é a moeda, a reputação é uma fonte de poder. Em uma rede esparsa, como a maioria dos mercados e hierarquias, o poder deriva do controle ou da intermediação do fluxo de informações e, muitas vezes, da restrição. Em uma rede densa, no entanto, as informações simplesmente fluem em torno do suposto ponto de estrangulamento. Nessas circunstâncias, há mais poder em ser uma fonte de informações do que um coletor de informações. Consequentemente, os indivíduos são motivados a maximizar a visibilidade de seu trabalho e suas conexões com aqueles que estão amplamente conectados. Isso, por sua vez, alimenta a densidade de informações da rede. Transações baratas e muitas delas Até agora, discutimos o conteúdo do trabalho. Mas os modelos TPS e Linux também mudam a economia do trabalho, reduzindo os custos de transação. Os baixos custos de transação tornam lucrativo para as organizações realizar mais e menores transações — internas e externas — e, assim, aumentar o ritmo e a flexibilidade típicos das organizações de alto desempenho. Explorando os 80% negligenciados O famoso Princípio de Pareto determina que as empresas obtêm 80% de seu valor de apenas 20% de seus produtos, clientes ou ideias. Devido aos altos custos de transação, a cauda longa dessa curva — 80% dos geradores de valor incertos — não pode ser explorada. Então, em nome do foco da empresa, a cauda é cortada, segmentada ou redesenhada para deixar de existir. Inovações potencialmente lucrativas morrem com isso. As organizações que reduzem os custos de transação podem aceitar os 80% rejeitados. Eles podem responder aos sinais fracos do mercado, explorar pequenos segmentos e experimentar combinações improváveis de tecnologias. Eles podem fazer uma centena de pequenas apostas em vez de algumas grandes. Por exemplo, Detroit considerava os veículos híbridos um produto intermediário desinteressante: executivos automotivos dos EUA preferiam pesquisas até agora não realizadas sobre tecnologia de células de combustível. Enquanto isso, a Toyota estava construindo o Prius. O híbrido está agora em sua segunda geração e a Toyota espera vender 300.000 em todo o mundo este ano. Os baixos custos de transação da Toyota e a propensão a colaborações em pequena escala ajudaram a manter abertas 80 opções discretas para o motor híbrido até apenas seis meses antes de entregar o design final. As montadoras convencionais precisariam congelar essas variáveis de projeto pelo menos dois anos antes. É nos interstícios da rede humana, e não nas mentes de alguns prodígios, que a maioria das inovações reais nasce. Portanto, são os custos de transação que restringem a inovação ao restringir as oportunidades de compartilhar ideias, habilidades e preconceitos diferentes e conflitantes. “As pessoas de Detroit são muito mais talentosas do que as da Toyota”, comenta o presidente da Toyota, Fujio Cho, com excessiva modéstia. “Mas pegamos pessoas com talento médio e as fazemos trabalhar como equipes espetaculares.” A rede, em outras palavras, é a inovadora. As fontes clássicas de custos de transação são a vulnerabilidade mútua em face da incerteza, interesses conflitantes e acesso desigual às informações. Gastamos dinheiro em negociação, supervisão e restituição para reduzir essas imperfeições. Tanto os mercados quanto as hierarquias incorrem em custos de transação (embora existam hierarquias para economizar neles, como argumentaram Ronald Coase e Oliver Williamson). Usando uma metodologia desenvolvida por J.J. Wallis e Douglass North, estimamos que, no ano 2000, somente os custos de transação em dinheiro representaram mais da metade do PIB não governamental dos EUA! Gastamos mais dinheiro negociando e aplicando transações do que realizando-as. Nas comunidades Linux e Toyota, os acordos são cumpridos não pela sanção de um contrato legal, nem pela autoridade de um chefe, mas pela confiança mútua, reduzindo drasticamente os custos de transação. Isso não é novidade: equipes de pessoas em todos os lugares do local de trabalho convencional operam com base na confiança. A novidade é o quanto a confiança pode se estender, até mesmo para pessoas que não se conhecem, ou mesmo entre aquelas que têm interesses conflitantes. A Aisin confiou a seus fornecedores rivais os projetos da válvula P. Os hackers do rsync trocaram informações confidenciais com pessoas que nunca conheceram. Os fornecedores de componentes da Toyota compartilham diariamente o conhecimento do processo, confiando que a Toyota não o usará para reduzir os preços. Os hackers do Linux confiam uns nos outros para fazer emendas descoordenadas e simultâneas na base de código. Além disso, ter propriedades em comum — já que certos tipos de propriedade intelectual são mantidos nessas comunidades — reduz os riscos monetários entre os co-proprietários. Os custos de transação caem porque simplesmente há menos coisas para negociar. Na comunidade Linux, os custos de transação se aproximam de zero. A Hewlett-Packard pagou Martin Pool para ser engenheiro Linux, mas isso não significa que a HP precisasse ser paga à margem pelos trabalhos noturnos de Pool no rsync. Na comunidade Toyota, os custos de transação, embora não sejam zero, foram radicalmente reduzidos. Quando a fábrica da Aisin Seiki foi destruída, a Toyota e seus fornecedores não processaram uns aos outros nem fecharam contratos de fornecimento de emergência. Eles simplesmente continuaram com o trabalho, confiando que uma restituição justa acabaria sendo feita. Jeffrey Dyer, professor de estratégia na Universidade Brigham Young, estima que os custos de transação entre a Toyota e seus fornecedores de primeira linha são apenas um oitavo dos da General Motors, uma disparidade que ele atribui aos diferentes níveis de confiança. Um modelo para muitos Reúna todos esses elementos e você terá um círculo virtuoso. Uma rede densa e auto-organizada cria as condições para uma confiança em grande escala. A confiança em grande escala reduz os custos de transação. Os baixos custos de transação, por sua vez, permitem muitas transações pequenas, que criam uma rede auto-organizada e que se aprofunda cumulativamente. Dar crédito onde o crédito é devido A comunidade Linux usa um formato específico — um “arquivo de crédito” — para reconhecer as contribuições de seus membros. Se, por exemplo, reconhecêssemos, no formato Linux, as contribuições de pessoas que ajudaram a moldar nosso pensamento para este artigo, veja como ficaria: Em: Mark Blaxill E-mail: blaxill.mark@bcg.com d: Exploração da economia do código aberto s: Grupo de consultoria de Boston em: Paul Carlille E-mail: carlile@bu.edu d: Discussão dos paralelos Linux/Toyota s: Universidade de Boston em: Karim Lakhani E-mail: lakhani@mit.edu d: Discussão dos paralelos Linux/Toyota d: Pesquisa de hackers livres/de código aberto s: MIT Quando o sistema atinge a massa crítica, ele se alimenta de si mesmo. Quanto maior o sistema, mais amplamente compartilhados são o conhecimento, a linguagem e o estilo de trabalho. Quanto maior o capital de reputação dos indivíduos, mais altos são os aplausos e mais forte é a motivação. O sucesso do Linux é uma prova do poder desse círculo virtuoso. O sucesso da Toyota é uma prova de que ela também é poderosa em empresas convencionais que maximizam os lucros. A comunidade Linux e o Toyota Production System são muito diferentes. O fato de conseguirem tanto de forma semelhante aponta para alguns princípios que outros podem seguir. A disciplina da ciência é surpreendentemente adaptável à organização do trabalho corporativo — e até mesmo intercorporativo. Em algumas circunstâncias, a confiança é um substituto viável para contratos de mercado e autoridade hierárquica, não apenas em equipes pequenas, mas também em comunidades muito grandes. Em todas as cadeias de suprimentos, as organizações que conseguem substituir a confiança por contratos ganham mais com a colaboração do que perdem em poder de barganha. Os baixos custos de transação compram mais inovação do que os altos incentivos monetários. Esses princípios atendem às necessidades de crescimento e inovação das empresas de uma forma que os modelos organizacionais tradicionais não atendem. E talvez a eficácia dessas colaborações sugira o surgimento definitivo de algo totalmente novo. Não mercados. Não hierarquias. Mas uma combinação poderosa de ambos — e uma assinatura da sociedade em rede.

Regras de colaboração

Partner Center