Era só uma questão de tempo mesmo. Mas é bacana, uma vez que comunicação é uma necessidade em grande parte do nosso mundo rural e/ou subdesenvolvido, e com as redes wireless, nos libertamos da necessidade de caros investimentos em cabeamento. O próximo passo que está sendo dado é libertar da dependência dos provedores de energia elétrica, que também não chegam nestes rincões.

A primeira notícia, prata da casa, é do professor Marcelo Zuffo, da USP que desenvolveu um sistema wireless movido a energia solar em postes.

A idéia, obviamente, não é nova. Essas redes que podem ser montadas rapidamente e a uma fração do custo de uma rede cabeada se mostra especialmente útil tanto nos ambientes inóspitos quanto em áreas afetadas por desastres naturais. Algumas ONGs também já estão apoiando iniciativas mais organizadas neste sentido, como o projeto Green WiFi.

Não bastassem juntar duas tendências bacanas como WiFi e energia alternativa, podemos ainda juntar ao conceito de inovação movida a crowdsourcing e citar mais um exemplo.

Crowdsourcing é uma palavra que está na moda ultimamente, que não deixa de ser uma forma requentada do que o conceito de open source fez pela indústria tecnológica nos últimos anos, aplicada a outras formas de produção que usam a web e o potencial de alcançar uma gama imensa de pessoas e talentos pela web.

E quando a rede não chega longe o bastante, você pode mandar pessoas de moto irem levar e buscar seus pacotes IP (ou suas mensagens de email) como fazem no Camboja. (eu lembro de ter visto coisa parecida sobre a Índia, porém usando ônibus, mas não achei a referência. Acho que foi no google tech talks).

Aposto que você nunca mandou seu motoboy ir buscar seu email. Pelo menos, não o eletrônico ;-).

Ubiquidade, de verdade, é isso aí.

Veja abaixo alguns dos comerciais no YouTube:

PC lotado
Macs não travam
Upgrades

Hoje o Erick Schonfeld, do blog TechCrunch, escreveu um artigo interessante sobre se o Google deveria usar os métodos tradicionais de propaganda - rádio, TV e jornais - para melhor estabelecer sua marca. Mas uma frase no último parágrafo do artigo me chamou a atenção:

I’d love to see an ad campaign for Google Docs along the lines of the “I’m a Mac/I’m a PC” Apple ads

Enquanto eu lia, já imaginava uma propaganda semelhante às acima, com o Mac e o PC conversando entre si, mas de repente uma voz onipresente diz “Hello, I’m Google Docs, and I run anywhere”.
Se eu tivesse um pouco mais de habilidade artística, faria um filmezinho assim no Youtube

E você, tem sugestões de uma propaganda para o Google nesses moldes? Escreva aí embaixo nos comentários. Quem sabe não enviamos todas as sugestões para o TechCrunch?

Renato Mangini é arquiteto de software sênior. Foi sócio fundador da Vetta Technologies e da Vetta Labs e recentemente criou uma startup de tecnologia para desenvolver o wapawapa. Sua formação acadêmica inclui um bacharelado em Ciência da Computação e um mestrado inacabado, ambos pela UFMG, e cursa agora um MBA no Ibmec.

Hoje eu vou falar sobre a parte mais curta e alta da curva de pareto, e como levantar mais o nível desta faixa.

O grande problema do “herói” é descobrir onde ele está. O segundo problema é você poder pagar o que ele sabe (ou acha) que vale. E o terceiro é como mensurar se o que você está pagando (caro) por ele, vale a pena.

Raramente, uma empresa é feita só de heróis, como o Google, e quando é o caso, são talentos mais difíceis de reter. Como conciliar todas estas dificuldades?

Uma das soluções é colocar os heróis para brigar entre si. Aviso: muitos não irão topar, afinal, existe uma demanda para eles no mercado. Mas vale lembrar que alguns são muito competitivos e podem gostar do recado, sobretudo se houver uma regra de avaliação justa e imparcial, e se o prêmio compensar.

Foi com este pensamento que foi criada uma interessante variante de outsoucing chamada TopCoder, citada no meu post da ESPN. Funciona assim: uma empresa quer o desenvolvimento de um determinado componente, geralmente, de alto valor agregado, seja devido à complexidade, seja devido ao desempenho ou ao prazo. O jeito mais prático de resolver o problema é jogar na rede e dar um bom prêmio para a melhor solução, num esquema de competição com regras claras.

Claro que você não vai pedir, num esquema destes, o desenvolvimento de um sistema grande e complexo, porque a própria natureza do desenvolvimento destas coisas é interativa, variável e um tanto sujeita a imprevisibilidades. É outsourcing pura e simples. Só que outsourcing direcionado para os “all stars”.

Um interessante efeito colateral deste site é que algumas empresas usam o site para deixar pequenos projetos e propectar mão-de-obra. Afinal, uma experiência fala mais que currículos bonitos não é mesmo?

“The process was kind of secretive,” says Michael North, the NFL’s director of broadcast planning and scheduling, who’s been with the league for 15 years. “We would go into the room, lock the door and emerge 10 weeks later: ‘Here’s your schedule. Play it.’”

Afinal, “scheduling” é complexo, o mundo real e a logística envolvida é complicada e computadores não dão conta, não é mesmo?

Isso até bem pouco tempo atrás.

Eis que um dia, bate à porta da NFL um sujeito canadense chamado Rick Stone, que havia desenvolvido um sistema para agendar o calendário da NFL, levando em conta todas as restrições do mundo real e maximizando, claro, o lucro da NFL.

“More than anything, Rick has developed a tool to prioritize, in any given season, certain factors and constraints that lets us figure out which of these schedules are delivering as close to optimal as we can get.”

Pode parecer uma tarefa fácil, mas tente conciliar as agendas de dezenas de times com as agendas das emissoras de rádio e TV com a proximidade de feriados, a concorrência de outros esportes pelo mesmo espaço de mídia e atenção de público. Para ser mais exato, o sistema leva em consideração cerca de 6000 fatores para montar uma grade de 256 jogos.

Para saber mais sobre esta curiosa história, confira aqui.

Os melhores algoritmos estão acertando em cerca de 80%.

Tem loteria esportiva nos estados unidos?

Independente do valor de se conseguir prever o desempenho ou não dos times no campeonato (afinal, as pessoas fazem apostas, os anunciantes gostam de avaliar o potencial dos jogos e dos times, etc), quanto será que a visibilidade deste concurso não rende para a ESPN? Imagine você ser o canal de esportes que além de passar e comentar o jogo, ainda mostra previsões.

Ou a quantidade de papo de buteco que isso rende.

E o que achei mais interessante: o artigo do Ourobouros é impressionantemente didático. O autor foi muito perspicaz em identificar perfeitamente como funciona a nossa metodologia e os pontos-chave que tornam nossa pesquisa bem diferente de muita coisa já feita; na verdade o artigo até acrescenta alguns pontos (e talvez de forma mais sucinta ao que eu e o Maurício escrevemos na época da aceitação. Considerando que temos uma imensa dificuldade de explicar nossas técnicas para a grande maioria dos biólogos e bioinformatas justamente porque elas são pouco usuais, achar alguém que leu e nitidamente entendeu o que fizemos, e consegue explicar de forma simples e objetiva, é extremamente gratificante, acreditem!

Finalmente, enquanto o nosso estudo cruzava dados de estudos bem diferentes envolvendo expressão genética de restrição calórica em uma mesma espécie (camundongos) o autor vai mais além e sugere fazermos um cruzamento inter-espécie. Ótima (e audaciosa!) idéia, e quem sabe um futuro alvo de pesquisa do Labs+Biomind…

(…)Outra questão é iterar o mais cedo, prototipar em papel e validar, seja conversando com um amigo que se encaixe no perfil do usuário. A comunicação é o mais importante. O objetivo é sempre o de alinhar o pensamento. Para isso tentamos fazer um trabalho em equipe mais alinhado, definir em conjunto o cronograma, as técnicas que vamos usar. Para geração de idéias, tentamos fazer seções de brainstorm em conjunto com cardsorting interno, o que agiliza o processo de discussão e alinhamento de idéias. Toda solução rascunhada é iterada. O processo fica mais leve e nosso pensamento mais alinhado durante o projeto, como consequência, a produtividade aumenta. É basicamente isso.

A gente pegou emprestado o termo que veio da área de TI e adaptamos à nossa metodologia. Mas, isso não veio exclusivamente da gente. O que a gente tem estudado é como adaptar nosso processo de UX ao processo de desenvolvimento de softwares, por isso temos experimentado empregar os princípios e temos aprendido boas lições.(…)

Achei muito interessante porque contrasta um pouco com a noção que se tem, por exemplo, do trabalho com agências de publicidade por exemplo. O processo de criação e ajustes em artes gráficas geralmente é dispendioso. Há até quem advogue que agências de publicidade deveriam cobrar a cada revisão de peça (que o cliente faça o briefing mais bem feito…).

Não tem como não comparar com as velhas metodologias dos grandes documentos de especificação em que o vai e volta de especificação e produto custa tempo e dinheiro de ambos os lados.

Por outro lado, nem todo tipo de serviço permite que o cliente seja tão interativo. Para muitos clientes, o tempo gasto ajudando a desenvolver o sistema (ou a experiência de usuário, ou o livro, etc) não é nada irrelevante. Um dos desafios das metodologias Agile é justamente que o cliente perceba o ganho global em termos de tempo de desenvolvimento (e nem sempre isso é possível) através da interatividade.

Quem implementa as metodologias ágeis lembra-se de colocar na conta o valor que o cliente dispende explicando o que quer que seja implementado?

Mas isso nunca é problema quando se tem alguma criatividade. O extremo mais precário é um dos meus exemplos preferidos: são comuns em cidadezinhas do interior os “jericos” - carros inteiros construídos a partir de sucata, usando motores estacionários (feitos para serrarias, máquinas agrícolas pequenas, etc.). Daí para competições rústicas envolvendo esses carros, jipes e fuscas é um passo.

(Foto: Marco Antônio Teixeira)

Algumas soluções técnicas pouco convencionais (gambiarras mesmo) fizeram história no automobilismo brasileiro. Em 1969, os jovens Emerson e Wilson Fittipaldi disputaram os Mil Quilômetros da Guanabara ao lado de lendas como Ford GT40 e Alfa P33, a bordo de um Fusca de 400 cavalos, vindos de dois motores acoplados por uma junta elástica de borracha!

(Foto: obvio.ind.br)

Nos anos 1970 e 1980, qualquer um que pensasse em esportivo no Brasil tinha que falar do Opala, e necessariamente do “veneno” - modificações no motor como troca de carburador, bicos injetores e comando de válvulas para deixar o motor seis cilindros do que hoje é um dos maiores clássicos brasileiros ainda mais bravo e, obviamente, divertido.

(Foto: Opala Club de Bragança Paulista)

A chegada da injeção eletrônica ao Brasil com o Gol GTI, em 1989, foi o início de uma grande mudança: agora um programa de computador, sensores e atuadores eletrônicos passariam a ditar o comportamento (e o consumo) do motor, e a era do veneno clássico, dos carburadores Quadrijet e de tantos outros truques começava a terminar.

Só que a história não acaba aqui! No início dos 1990 tomava força também, no mundo todo, uma outra revolução: a do software livre e aberto. Programadores de computador, cientistas da computação, hobbyistas e entusiastas chegavam à conclusão de que o código-fonte dos programas não devia ser trancafiado a sete chaves numa catedral, mas sim compartilhado e melhorado de forma cooperativa e distribuída.

Essa cooperação e o livre fluxo de informação levava ao desenvolvimento de programas e sistemas mais robustos, seguros e eficientes. E o que isso tem a ver com carros esportivos ? A resposta é simples: já que o software domina o seu carro, domine o software e você vai conseguir um “veneno” que de virtual não tem nada!

Provavelmente o exemplo mais famoso disso é a MegaSquirt, um sistema completo de injeção eletrônica, com todos os sensores e um microprocessador de 8 ou 16 bits que controla os bicos injetores e ignição das velas, baseado em software livre. A Mega Squirt é comprada pelo correio, aos pouquinhos, montada nos mais diferentes tipos de carros, e configurada de diversas formas conforme os objetivos da preparação, na melhor tradição DIY (Do It Yourself, “faça você mesmo”):

Componentes da MegaSquirt

(Foto: Marcelo Garcia)

Para “conversar” com a MegaSquirt e fornecer uma interface para o piloto / mecânico / programador / usuário, usa-se um outro software livre, o MegaTunix, originalmente desenvolvido para o Linux e hoje disponível em diversos sistemas operacionais, incluindo o Windows.

Uma das funções mais divertidas do MegaTunix é emular os caríssimos “relógios autometer” (mostradores incluindo conta-giros, termômetros, razão ar/combustível, etc.): tudo é mostrado no monitor de um notebook ou palmtop, e o usuário pode definir exatamente qual o visual ele quer.

MegaTunix rodando em notebook conectado à MegaSquirt

(Foto: Marcelo Garcia)

E é a flexibilidade do código aberto que permite que sistemas assim sejam tão interessantes. O Marcelo Garcia, que forneceu fotos e consultoria para esse artigo, dá um exemplo da liberdade a que se tem acesso: ele conta que é possível, usando bastante engenhosidade, um fogão, multímetro e outros truques, atualizar o firmware da MegaSquirt para que ela usasse sensores de temperatura de qualquer carro em qualquer motor. Uma mão na roda para quem tem carros antigos (dos quais não se encontram mais peças originais) ou exóticos (cujas peças custam uma fortuna).

Calibrando sensores de temperatura no fogão

(Foto: Marcelo Garcia)

É claro que há limites para o que é possível fazer com software; nem o hacker mais brilhante do mundo vai fazer seu Uninho 1.0 rodar 25 km/l ou andar junto com o Opalão seis cilindros do seu tio. Mas saber que o “veneno” feito-em-casa ainda existe apesar de todas as inovações tecnológicas das últimas décadas é muito, muito bacana - e dá um outro sentido à expressão computador de bordo!

]]> http://blog.vettalabs.com/2008/09/19/software-livre-no-seu-carro-veneno-open-source/feed/ http://blog.vettalabs.com/2008/09/17/o-mito-do-heroi-no-desenvolvimento-de-software/ http://blog.vettalabs.com/2008/09/17/o-mito-do-heroi-no-desenvolvimento-de-software/#comments Wed, 17 Sep 2008 13:58:36 +0000 Leonardo Kenji http://blog.vettalabs.com/?p=247 Vou continuar aqui um papo que eu comecei num fórum do mundo.it. (vc tem que se cadastrar para acessar. É chato, mas é de graça, e até bem rápido prá dizer a verdade)

Existe uma prática, ou crença, mais ou menos disseminada na gestão de projetos de TI, que é a figura do herói.

Prá quem nunca desenvolveu em equipe, o herói é aquele desenvolvedor bem acima da média, cujo esforço e talento individuais são fundamentais para “salvar” aquele projeto que estava atrasado, ou quase batendo os prazos, ou no caso mais comum, quando o prazo já está estourado e estamos falando de minimizar os danos.

Em inglês, o herói é o que chamamos de “big guns”. Quando a coisa está feia no front, traga os maiores canhões que puder para vencer a batalha.

Em alguns casos, a indústria vende a promessa que o herói será recompensado, mas você também vai ouvir vozes dissonantes dizendo que é bobagem tentar ser o herói.

Como é de se esperar, existem poucos heróis por aí. As empresas de TI disputam estes caras a tapa, e muitas vezes o passe deles se eleva (ou não, também é comum o excelente profissional de TI ralar do mesmo jeito por uma variação a mais no salário que não é proporcional ao seu talento).

Mas o fato é que existe um pouco dessa cultura da “equipe de gente normal com um cara muito bom liderando”. Até aí, nada de novo, afinal, nada melhor que trabalhar com gente boa de serviço que saiba compartilhar o conhecimento para elevar o nível geral do time e incutir algum pequeno senso saudável de “competição” ou de “não quero ficar muito prá trás”.

O problema vem quando as empresas montam esquemas de incentivos em que o jogo perde a graça, se por exemplo for o time da Albânia com o Ronaldinho no ataque. Quando as empresas privilegiam ou premiam apenas os heróis, o resto da equipe pode simplesmente chegar à conclusão que a meta do prêmio é inalcançável, e aí começa-se a “montar” no trabalho de quem se sobressai, ou assumir sempre que ele vai solucionar tudo.

Isso fica ainda um pouco mais complicado se você pensar numa indústria onde a caça aos talentos é intensa. Qual o impacto para um projeto se o seu herói é comprado pela concorrência? Quanto tempo você leva para achar outro herói?

É interessante pq muito se vê por aí sobre profissionais da área de TI que reclamam da falta de investimento no profissional por parte das empresas. Muito disto vem da idéia dos empresários que “eu posso estar gastando para capacitar o profissional para a concorrência, pq não estou disposto a pagar por uma pessoa mais capacitada“. E aí vira aquele jogo de empurra, das empresas reclamando do ensino e etc. Mas quais são as políticas destas empresas para incentivar seu corpo técnico?

Outro dia ouvi um exemplo interessante aplicado a uma equipe de vendas de um produto que não tem nada a ver com tecnologia, mas como se sabe, desenvolvimento de software não é feito com tecnologia, mas sim com seres humanos.

O exemplo era o seguinte, muito simples: é muito comum premiar os melhores vendedores como forma de incentivo. O problema aqui é o mesmo do herói. O bom vendedor é bom sempre, é um talento inerente. Então os prêmios vão sempre para as mesmas pessoas.

Pois bem, propuseram um modelo de incentivos baseado em metas que eram alcançáveis por qualquer um da equipe. E sem sorteio.

Mais especificamente, fizeram um acordo com um fabricante de artigos de couro, e compraram em grande quantidade de pastas bacanas, que todos os vendedores adoravam. E fizeram a seguinte proposta: vamos supor que cada vendedor venda em média 10 unidades do produto, e que o bom vendedor venda 60 unidades. Quem vendesse 20 unidades ganharia, sem sorteio, as pastas.

O resultado, como você pode imaginar, é que a grande massa de vendedores que vendia 10 unidades, pensou ao mesmo tempo que mais 10 unidades não era uma meta fácil, mas era bastante factível. Não só isso, mas os que vendiam 30 unidades, “passavam” as 10 unidades restantes para outros e negociavam uma parte da pasta… bem, histórias de varejo são quase sempre divertidas :-).

Desenvolvedores e vendedores são espécies muito diferentes entre si. Mas é certo que seres humanos respondem a incentivos.

A conta não é difícil de fazer. Se vc tem um “herói”, ele vai ganhar a pasta de qualquer jeito mesmo, mas qual o valor do incremento de produtividade na grande massa de vendedores “normais”?

O processo de desenvolvimento de software se torna cada vez mais organizado e mensurável a cada dia que passa, com o uso de processos mais organizados de desenvolvimento. Mas o que os gerentes de projeto fazem com estes números, além de levantar alertas a cada prazo perdido, pressionando e aliviando os desenvolvedores?

Quantos destes gerentes saem da rotina diária de monitoramento e pensam estrategicamente o que fazer com estes dados? Qual a vantagem para o seu projeto se você conseguir criar um incentivo que melhore a produtividade do seu time em 10% ou 15% por exemplo?

Talvez seu “prêmio” possa até ser bem legal… mas você precisa saber o que mexe com o coração e o ego do seu time. São pessoas, como todas as outras. Ninguém sacrifica família e vida pessoal por um pendrive. Bons funcionários demandam reconhecimento.

O cínico vai dizer que é “a cenoura na frente do burro”, mas para mim, me parece um trato razoável. Cumpra o prazo e você está fazendo a sua parte. Faça melhor dentro da sua capacidade e você é premiado pelo esforço extra. Mas só funciona com prazos que não são artificiais. Não se consegue incentivar ninguém sem ser justo.

Quantos gerentes vêem as pessoas atrás dos números? Pessoas devidamente motivadas são capazes das coisas mais geniais. Às vezes, o que falta, é saber dar a devida chance. Bolar o incentivo correto, claro, é uma das grandes questões aqui.

Outras questões são “qual a política da sua empresa para melhorar o desempenho da camada média de desenvolvedores” e “como não transformar a política de incentivos num cabo de guerra na estimativa de prazos”…

Será que existe um jeito? O RH da sua empresa sabe quais cordas puxar para incentivar a produtividade das pessoas? Ou o estímulo é aquela espada pendendo sobre a cabeça de cada um, chamado “desemprego”?