Não costumo fazer traduções porque em geral não gosto delas: a maioria parece um arremedo do original e quando prestam você está no máximo lendo o texto do tradutor e não o do autor. Mas o texto “The other half of ‘Artists ship’” do Paul Graham é tão bom que não consegui me segurar. Tecnicamente o que vem aí abaixo é mais uma versão do que uma tradução (o original, por exemplo, não tinha nenhuma referência nem tantas ênfases em itálico): uma versão minha para o que o autor disse que pode inclusive não ter nada a ver com o que ele quis dizer. Então o que você vai ler aqui não é exatamente o que o Graham escreveu originalmente. Portanto, se você se sente à vontade para ler textos em inglês, vá em frente, clique no link acima e esqueça a minha versão. Caso contrário, corra para aprender inglês — todo programador que se preza sabe ao menos ler inglês — e contente-se com minha versão ridiculamente patética neste meio-tempo.
Uma das muitas diferenças entre as empresas grandes e as pequenas é que as grandes tendem a desenvolver procedimentos de auto-proteção contra erros. Uma empresa que está iniciando anda mais ou menos como um bebê: esbarra nas coisas e cai o tempo todo. Empresas grandes são mais ponderadas.
O acúmulo gradual de verificações em uma organização é um tipo de aprendizado baseado nos desastres que aconteceram com ela mesma ou com organizações parecidas. Depois de assinar um contrato com um fornecedor que declara falência e não entrega o que deveria, por exemplo, uma empresa pode passar a exigir que todos os fornecedores provem sua solidez antes de fazerem uma oferta.
À medida que as empresas crescem elas invariavelmente desenvolvem mais dessas verificações, seja em resposta a desastres que sofreram ou, provavelmente com mais freqüência, por contratar pessoal oriundo de empresas ainda maiores que trazem consigo seus dispositivos de proteção contra tipos de desastres novos.
É natural que as organizações aprendam com seus erros. O problema é que quem propõe novas verificações quase nunca considera que a verificação em si tem um custo.
Toda verificação tem um custo. Considere, por exemplo, o caso de exigir que os fornecedores comprovem solidez. Parece mera prudência, não? Mas na realidade pode ter custos significativos. Existe obviamente o custo direto de tempo de gente dos dois lados para fornecer e verificar provas de solidez. Mas os custos que realmente importam são os que nunca chegamos a conhecer. Como, por exemplo, a empresa que seria a melhor fornecedora, mas não se candidata porque não pode se dar ao luxo de despender o esforço necessário para ser verificada. Ou a empresa que seria a melhor fornecedora, mas fica logo abaixo do limite considerado para a solidez — que obviamente foi puxado para cima, já que não há nenhum custo aparente para aumentá-lo.
Sempre que alguém em uma organização propusesse uma nova verificação, deveria ter que explicar não só o benefício mas também o custo. Não importa quanto o trabalho de análise fosse ruim, esta meta-verificação iria ao menos lembrar a todos que deve haver um custo e fazê-los procurar por ele.
Se as empresas começassem a fazer isso, encontrariam algumas surpresas. Joel Spolsky palestrou recentemente na Y Combinator sobre venda de software para clientes corporativos. Ele disse que na maioria das empresas software que custe até aproximadamente $1.000 dólares pode ser adquirido pelos gerentes sem necessidade de aprovações adicionais. Acima desse limite as aquisições de software geralmente precisam ser aprovadas por um comitê. Mas bajular esse processo é tão custoso para os fornecedores de software que não faz sentido cobrar abaixo de $50.000 dólares. O que significa que se alguém produz algum produto pelo qual normalmente cobraria $5000, acaba sendo obrigado a vender por $50.000.
O propósito do comitê presumivelmente é garantir que a empresa não desperdice dinheiro. Apesar disso, o resultado é que eles acabam gastando dez vezes mais.
Verificações de aquisição vão sempre ser caras, porque quanto mais difícil for fazer você comprar algo, mais o preço vai aumentar. E não necessariamente linearmente. Se for suficientemente difícil lhe vender algo, quem for o melhor em fazer as coisas simplesmente não vai querer perder tempo. Os únicos que vão vender para você são as empresas especializadas em vender para você. Quando chega a este ponto você já está afundado em um nível inteiramente novo de ineficiência. Os mecanismos de mercado normais não vão lhe proteger, porque os bons fornecedores nem estão mais no mercado.
Essas coisas acontecem o tempo todo nas maiores de todas as organizações: governos. Mas verificações estabelecidas por governos podem causar problemas bem piores do que superfaturamento. Verificações estabelecidas por governos podem aleijar toda a economia de um país. Até mais ou menos 1400, a China era mais rica e tecnologicamente mais avançada que a Europa. Uma das razões para a Europa ter conseguido ultrapassar foi que o governo chinês restringiu viagens de comércio longas. Com isso só sobraram os europeus para explorar e eventualmente dominar o resto do mundo. Incluindo a China.
Mais recentemente, a lei Sarbanes-Oxley praticamente destruiu o mercado americano de ofertas públicas. Essa não foi a intenção dos legisladores que a escreveram, eles simplesmente queriam acrescentar algumas verificações sobre empresas públicas. Mas esqueceram de considerar o custo. Esqueceram que empresas na iminência da abertura geralmente estão com os cintos bem apertados, e que o peso de algumas verificações a mais pode ser fácil para a General Electric enfrentar mas são o que basta para evitar que empresas mais jovens sequer considerem uma oferta pública inicial.
Quando você começa a pensar no custo das verificações, começa a fazer outras perguntas interessantes. O custo está aumentando ou diminuindo? É mais alto em algumas áreas do que em outras? Onde ele cresce de forma descontínua? Se grandes organizações começassem a fazer perguntas desse tipo, descobririam algumas coisas bem assustadoras.
Eu acredito que o custo das verificações está na verdade aumentando. O motivo é que o software ocupa uma posição importante nas empresas, e que as pessoas que escrevem software são atingidas de um modo peculiar pelas verificações.
Programadores são um tipo de trabalhador diferente na medida em que os melhores preferem trabalhar duro. Este não parece ser o caso na maior parte das ocupações. Quando trabalhei com fast food, nós não preferíamos os tempos atarefados. E quando aparava gramados, eu definitivamente não preferia quando a grama estava alta depois de uma semana de chuva.
Programadores, no entanto, gostam quando escrevem mais código. Ou, mais precisamente, quando publicam mais código. Programadores gostam de fazer a diferença. Os bons, pelo menos.
Para os bons programadores, um dos melhores aspectos de trabalhar para uma empresa pequena é que há poucas verificações para publicação. Em empresas iniciantes, não há nenhuma verificação externa. Se você tiver uma idéia para um recurso novo pela manhã, pode escrevê-lo e enviar para os servidores de produção antes do almoço. E quando pode fazer isso, você acaba tendo mais idéias.
Em empresas grandes, o software precisa atravessar várias aprovações antes de poder ser liberado. E o custo de fazer isso pode ser enorme. Eu estava conversando recentemente com um grupo de três programadores cuja empresa havia sido adquirida há alguns anos por uma empresa grande. Quando eram independentes, eles podiam liberar modificações instantaneamente. Agora, eles disseram, o mais rápido que poderiam disponibilizar o código nos servidores de produção é em duas semanas.
Isto não os tornou simplesmente menos produtivos. Fez com que odiassem trabalhar para o comprador.
Aqui vai uma evidência do quanto os programadores gostam de poder trabalhar duro: esses caras pagariam para poder publicar código de imediato do jeito que estavam acostumados. Perguntei se eles trocariam 10% do preço de aquisição pela habilidade de publicar código de imediato e todos os três instantaneamente disseram que sim. Então perguntei qual seria a percentagem máxima do preço de aquisição que trocariam. Eles disseram que preferiam não pensar nisso, pois não queriam descobrir o quão alto iriam, mas tive a impressão que seria mais ou menos a metade.
Esse pessoal teria sacrificado centenas de milhares de dólares — talvez milhões — só para poder disponibilizar mais software para os usuários. E sabe de uma coisa? Seria perfeitamente seguro permitir que o fizessem. Na verdade, o comprador estaria bem melhor; não somente esses caras não quebrariam nada, eles teriam conseguido fazer muito mais. No fim das contas o comprador está tendo performance mais baixa a custo mais alto. Do mesmo jeito que o comitê que aprova aquisições de software.
Assim como o maior perigo de ser difícil de ser convencido a comprar não é pagar superfaturado, mas o fato dos melhores fornecedores nem mesmo quererem vender para você; o maior perigo de aplicar verificações demais a seus programadores não é torná-los improdutivos, mas fazer que os bons programadores nem mesmo queiram trabalhar para você.
A famosa máxima de Steve Jobs “artistas publicam” é aplicável nos dois sentidos. Artistas não são somente capazes de publicar. Eles insistem nisso. Assim, se você não deixar as pessoas publicarem, não terá nenhum artista.
Muito bom o texto. Eu assino o feed do Graham, mas não li o texto em inglês por preguiça. E com o seu incentivo
“Mas o texto “The other half of ‘Artists ship’” do Paul Graham é tão bom que não consegui me segurar.”
eu tive que ler.
Eu percebi isso em uma empresa que trabalhei(não era de software). Difícil seria mostrar a eles estas idéias. Com este texto eu posso mostrá-los com os argumentos do Graham o que eu pensava/penso sobre a situação.
Bom, não precisamos do “melhor” fornecedor. Precisamos de um fornecedor adequado. E o fator risco é sem dúvida importante. Só nos arriscamos quando isso significa criar possibilidades maiores de retorno. Se a diferença entre esses fornecedores não for significativa o suficiente para justificar o risco, para quer corrê-lo. E, em caso de fornecedores, além da solidez, iremos exigir também qualidade, o que minimizará essa possível “diferença”.
Não sei quanto aos números (10x parece muito), mas é claro que isso é verdade. Contudo dinheiro não é tudo. Talvez a empresa queira gastar mais, porém garantindo que a aquisição foi a mais adequada. Mas concordo que a coisa poderia ser, em muitos casos, mais enxuta.
“Verificações de aquisição vão sempre ser caras, porque quanto mais difícil for fazer você comprar algo, mais o preço vai aumentar. E não necessariamente linearmente. Se for suficientemente difícil lhe vender algo …” Estranho isso, pois estamos falando de práticas comuns em praticamente todas as empresas. Um sistema de qualidade não tornará uma empresa “suficientemente difícil” tão facilmente.
Concordo que o governo, em especial, deva se preocupar em facilitar as coisas para empresas pequenas, em favor do país.
Eu descordo que “desorganização => ambiente mais criativo”, ou que “procedimentos definidos => criatividade tolida”. Num ambiente desorganizado nada é tolido, não só a criatividade, mas também os erros, os retrabalhos, os problemas de comunicação (implementamos a coisa errada), etc.. No ambiente organizado, dependendo da cultura da organização, podemos ou não ter um ambiente criativo. A questão aqui não é ter procedimentos, mas sim como foram concebidos esses procedimentos.
Agora, admito que é bom estar no controle, em se tratando de programação, e fazer o que quer. Por isso acho que todo desenvolvedor deveria conduzir projetos de interesse particular nos horários vagos . Numa empresa de desenvolvimento cujos requisitos dependem do cliente (serviços de desenvolvimento), vamos ter de formalizar os requisitos, etc..
Mas o comprador tem essa segurança? Pelo visto não. É como entrar num site desconhecido e comprar no cartão de crédito (corporativo) um jatinho que custa 10 milhões por 1 milhão. Quem tem dinheiro para comprar o jatinho vai preferir pagar os 10 milhões e garantir não só que o jato vai chegar, mas que ele vai voar sem resolver cair derrepente. Não vale a pena o risco! Veja, não estou dizendo que descordo do que está sendo colocado, só estou tentando dar o que acredito ser a visão de quem está do outro lado da história.
A propósito, publicar aqui é “colocar em produção”? Não entendo porque um programador se sentiria frustrado por estar desenvolvendo uma série de melhorias para uma nova versão do software que só será disponibilizada daqui a 6 mêses, por exemplo. Acho que não entendi o ponto aqui.
Concluindo, acho que precisamos, sim, de processos, mas devemos pensar esses processos de modo a mais do que simplesmente evitar inibir a criatividade, mas incentivá-la. Empresa grande não é sinônimo de empresa altamente burocrática. É claro que quanto maior mais distância, mais dificuldades de comunicação, mais necessidade de procedimentos, mais custos operacionais. Mas isso não significa menos qualidade, menos criatividade nem menos lucratividade.
Para se buscar boas publicações, deve-se existir um meio que motive a colaboração e que incentive à pesquisa e melhoria contínua, de forma que não retarde a fazer o que está sempre sendo feito mas de uma forma que possibilite à inovação através do conhecimento e talento pessoal.
Agora, isto no mundo real não existe, porque vivenciamos um escopo fechado, em um mercado parte capitalista e parte socialista, onde o comprometimento nem sempre é saudável a ponto de quase não termos incentivos que nos beneficiem, seja financeiro, seja através da oportunidade ou recursos posteriores.
Quando você não depende destes aspectos, você começa a transcender naquilo que o motiva através do seu conhecimento e novas descobertas, possibilitando assim novas publicações inovadoras e empreendedoras.