Fragmental

Removendo algumas teias de aranha do blog. Está sendo um tempo bem difícil com todos estes feriados e tudo mais por aqui mas consegui uma brecha razoável neste natal para colocar algumas coisas em dia.

Como vimos nos últimos capítulos estou em um grande cliente num projeto em Ruby. Na verdade o projeto é uma grande plataforma tecnológica onde Java é usado no produto em si e Ruby no grande conjunto de ferramentas que os desenvolvedores criaram. A parte que eu estou trabalhando neste momento (ou para onde irei voltar dia 2 de janeiro) é um sistema que atesta a veracidade de informações.

Não dá para falar muito sobre o projeto em si mas é algo bem interessante. A empresa cliente é membro de um grande conglomerado de empresas tradicionalíssimas que lidam com tecnologia e engenharia em diversas frentes. Essa empresa em específico tem um problema interessante: ela possui uma mina de ouro em dados exclusivos mas seu sistema é completamente ultrapassado. Mesmo com esse problema em forma de legado seu banco de dados é a fonte mais confiável sobre estes dados que se têm na Oceania e estes dados são necessários para praticamente todas as empresas do país, então ela se mantém como player no mercado.

Como sempre acontece nestes novos (30 anos?) tempos boa parte dos seus clientes não está satisfeita com os serviços e está usando meios alternativos para conseguir as informações que precisa sem passar pelo sistema burocrático e antiquado. Mesmo estes meios sendo mais caros e trabalhosos que o sistema legado ainda assim preferem fugir do sistema atual de alguma forma, qualquer que seja.

Há alguns anos a ThoughtWorks entrou nesta empresa para tocar um projeto que está entregando a fase final em algumas semanas. O trabalho foi tão bem aceito que a empresa adotou o estilo agile & lean de administrar as coisas para si, ao andar pelos dois prédios de 7 andares que a empresa ocupa você vai ver dezenas de cartões pregados na parede formando diversos posteres kanban, do pessoal de marketing até o da produção. Para lidar com o domínio de negócio, algo bem específico e pesado, eles formaram várias pequenas equipes, geralmente com cinco pares de desenvolvedores (100% pair programming), um ou dois analistas de negócios, um representante do cliente (client on-site) e alguns analistas de testes.

Como falei a coisa funcionou bem e o projeto onde eu estou é o segundo com participação da ThoughtWorks. Além dos nossos consultores existem diversos funcionários e alguns consultores empregados por outras empresas: É muito engraçado ver gente que trabalha oficialmente para uma empresa de três letrinhas, CMMi nível 23 e meio praticando agile feliz da vida e comentando como este é o primeiro projeto que vê funcionar na vida.

É interessante ver mais um caso de empresa que muda não para seguir a nova regrinha do jogo mas sim porque precisa mudar. Sei que tem muita gente que discorda de mim mas acho que nos últimos anos as empresas ficaram muito mais maduras com relação ao que adquirem. Há um movimento interessante nas empresas brasileiras que fazem do software seu negócio para retirar terceirizados e colocar sua gente para desenvolver.

Se você perguntar a qualquer analista de mercado ou ler qualquer boa ou má publicação vai ver que isso seria a maior besteira. Ainda que uma empresa como Globo.com, UOL, ig, e etc. dependa do software ela não produz software para viver. Uma empresa deste tipo deveria, segundo a lógica do preto-no-branco, comprar os serviços para uma empresa de desenvolvimento de software. Isso faz sentido e diminui o custo de manter uma equipe de desenvolvimento. O problema é que, como sempre diz minha esposa: economia simplista tende à economia burra.

O modelo funciona no papel e deveria funcionar na vida real mas não funciona. Segundo o pensamento acima quando contratamos uma empresa de software estamos contratando serviços de alguém especializado nisso. Mentira. A grande, grande maioria das empresas que oferecem serviços de consultoria no desenvolvimento não tem a menor idéia do que é desenvolver um software. Seus profissionais são expostos (quando são!) a um treinamento pasteurizado e superficial, os poucos profissionais capacitados destas empresas são por mérito próprio.

Então temos uma equação interessante. Digamos que manter funcionários especializados no desenvolvimento na folha de pagamento custe X. Esse é, por exemplo, o mesmo valor que pagamos à empresa JCN (nome ilustrativo, nem sei se existe uma empresa com esse nome) para alocar seus funcionários na nossa empresa. Se fosse só por isso ia ser um negócio estranho, íamos ter um 0-a-0 no investimento. O problema é que manter um corpo técnico como funcionários da empresa não custa só isso, você precisa investir para que este corpo técnico seja capacitado. Este é o custo que seria evitado contratando os serviços da JCN.

O problema é que após algumas décadas os clientes passaram a perceber que a empresa JCN não investe nada nos seus profissionais. Eles começaram a perceber que a JCN não entende nada de desenvolvimento de software. Alguns clientes não acham que valha a pena fazer algo a este respeito. Continuam na mesma coisa, exigem um certificado CMMi novo e toda vez que fecham um contrato já se preparam para o processo que sem dúvida vai acontecer quando o projeto não for entregue nos termos deste.

Tem outras empresas, no entanto, que não podem ter este prejuízo porque se o software atrasar não vai ser seu gerenciador de estoque que sai do ar, é o seu negócio como um todo, sua fonte de renda. Pelo que já vi na prática essas empresas fazem uma de duas coisas: ou (re-)internalizam o desenvolvimento ou contratam uma empresa realmente capacitada.

A primeira parte é mais cara e trabalhosa, mas pode ser melhor. O cliente adquire uma equipe de desenvolvimento e se preocupa em treiná-los. É preciso que este time entenda como desenvolver software e é por isso que estamos vendo tantos cursos in-company de Scrum, XP e etc. Você já viu consultoria de três letrinhas pagar isso para seus funcionários? Quem está comprando estes treinamentos são os clientes, não os fornecedores. Algo para pensar, não?

No segundo caso o cliente acha uma empresa em que confie para uma parceria. Neste ponto que eu acho que as pequenas consultorias tendem a fazer bastante dinheiro. Um grupo pequeno de desenvolvedores talentosos e motivados pode fazer muito mais do que uma grande corporação de três letrinhas com duzentos funcionários alocados para seu projeto. Palavra de quem já esteve dois dois lados, de quem compra e de quem vende.

O meu cliente atual está indo para a primeira opção. Para chegar lá ele tem que enfrentar dois problemas: 1) é caro e 2) se os dois projetos não saírem até o meio do ano não precisa mais continuar a contratar gente porque a oportunidade vai ser perdida. Neste cenário o que eles fazem é contratar consultores que eles confiem para atuar junto aos seus funcionários e desenvolver o software. Os consultores, mesmo os das empresas de três letrinhas, são minuciosamente entrevistados num processo que lembra o próprio processo seletivo da ThoughtWorks.

Após este tempinho lá e medindo com minha experiência passada eu acredito que estejam no caminho certo. Eles possuem equipes com profissionais muito acima da média a um custo razoável. Estes profissionais estão entregando os projetos e ao mesmo tempo construindo a cara dos departamentos de desenvolvimento. Quando os projetos encerrarem acho que 1/3 do número de pessoas vai ser necessário para manutenção e demais desenvolvimento, como é o aproximado número de consultores não deve haver problema. Os times pequenos já são rearranjados diariamente mesmo.

Claro que o processo de achar consultores é difícil e requer investimento. Seguir este plano é bem mais difícil que fazer uma ligação do tipo: “Alô, é da JCN? Me manda 300 programadores Java, por favor? 30 minutos? Obrigado”. Eu não diria que é uma solução para todos, sequer para a maioria, já falamos um pouco sobre isso aqui.

O que eu digo a respeito da situação na maioria das empresas que está com problemas no desenvolvimento (e qual não está?) é: façam algo. Após tanto tempo comprando dos mesmos fornecedores e recebendo porcaria em troca porque você continua com eles? Após tanto tempo desenvolvendo software ruimd esta forma porqu você continua fazendo isso?

Seja lá o que fizer, faça algo. Só, por favor, não compre soluções de caixinha. Certificados, ferramentas, cursos, livros, vudu… nada disso vai adiantar, pelo menos não sozinho. Descubra a motivação das coisas e veja se aquele eu fornecedor (ou se o produto que ofereces) que diz que faz a práticas X e Y e por iso tem o certificado Z sabe, ao menos, porque ele deveria fazer aquilo.

This entry was posted on Friday, December 28th, 2007 at 3:29 am and is filed under australia, gerencia, metodologias, negocios, thoughtworks. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.