Qualquer semelhança com a realidade não é mera coincidência. Isto quase nunca acontece, não é mesmo?

Este episódio foi editado. Aqui está o link para informações sobre o original no site da Fox.

“Uma boa empresa não é aquela que usa a tecnologia para construir Softwares, mas sim a que usa a tecnologia para destruir problemas. Talvez por isso muitas Fábricas de Software não são boas empresas.”

Coloquei as frases acima no Twitter, mas acho que a reflexão merece mais do que um micro-post.

Gosto também de duas outras frases cujo sentido apontam na mesma direção. A primeira, de autor desconhecido, é mais ou menos assim: “A Informática surgiu para resolver problemas que não existiam antes dela”. A segunda, do Jamie Zawinsk, diz: “Ao ver um problema algumas pessoas poderiam pensar: ‘acho que posso resolver com regular expressions’. Agora elas têm dois problemas”.

O que todas estas frases têm em comum? Elas sintetizam bem a Alienação Tecnológica que as empresas e os profissionais de TI têm ajudado disseminar com bastante afinco – e que tem um pouco a ver com o que tenho falado aqui e aqui.

A Alienação Tecnologica é a utilização da tecnologia como um fim em si e não como um meio para a solução de problemas. Em outras palavras, o pessoal de TI começa com o intuito de resolver um problema do mundo real, mas acaba voltando as prioridades para um código fonte, uma arquitetura, um banco de dados, um Design Pattern, uma técnica nova ou uma documentação os deixam felizes, mas não o usuário. Isso acontece porque no meio do caminho estas pessoas de TI estavam tão preocupadas com o TI-Centrismo que já não sabem mais o que realmente importa. E não estou falando apenas da burocracia que os movimentos ágeis tão na moda atualmente estão tentando derrubar. Estou falando daqueles casos (não raros) onde as pessoas pouco se importam com a utilização de fato do Software pois seus artefatos (código, arquitetura, Banco, etc) são seu motivo de orgulho.

Por inúmero fatores isso acontece com muitas Fábricas de Software. Aliás, vamos pensar por um instante sobre o termo Fábrica. Qualquer tipo de fábrica, exceto a de Software, é definida por uma linha de montagem que produz algo que já existe (escopo mais que fechado e técnicas já conhecidas e testadas). Mas as Fábricas de Software são as únicas Fábricas que precisam produzir algo que ninguém sabe o que é ainda.

A Fábrica de Software é, em minha opinião, uma tentativa exagerada de industrializar ao extremo algo que por natureza têm muitos elementos que tendem a ser “artesanais” (soluções específicas para problemas específicos). Não estou dizendo que não devemos ter métodos e técnicas que facilitem este processo, mas voltando ao início do post, o problema é quando estas técnicas e métodos passam a ter razão de existir em si: a Fábrica fabrica o que não se conhece, mas o que importa é algo foi entregue.

Isto é como se a Ford se orgulhasse mais do seu processo de produção do que dos carros que as pessoas compram por escolha própria. Um engenheiro ou o Designer de carros da Ford deve se orgulhar ao ver as pessoas passeando em seus carros pelas ruas do mundo. Por outro lado, muitos profissionais de TI se contentam com algo que só eles conseguem enxergar. Isso é ou não é um caso evidente de alienação?

“Não ouça os compradores, eles não sabem o que querem” – Steve Jobs.

Algo parecido acontece com os usuários em minha opinião.

“Saber o que quer” é diferente de “saber o que precisa”. O usuário sabe o que quer, mas você NÃO DEVE fazer o que ele quer, você deve fazer o que ele precisa!

O que usuário quer num primeiro momento vai deixá-lo com a falsa impressão que o projeto está indo bem. Mas depois de um tempo ele verá que não é bem assim. Depois de um tempo ele vai querer mudar para o que ele precisava mas não sabia.

O problema de desenvolver com foco no que o usuário quer é que isso é baseado em desejo e como tal é rotineiramente distorcido pelas impressões. Desenvolver baseado no desejo dos usuários o leva a assumir premissas e criar restrições erradas para o desenvolvimento do Software. Isso complicará o seu projeto e provavelmente levará a resultados pouco satisfatórios. O problema é que o usuário vai culpar você por isso e nem vai lembrar das informações imprecisas que ele lhe passou sobre o que ele desejava.

Sim, o usuário não vai lhe dizer o que ele precisa porque ele não sabe! Pior, por sua natureza, entender o que o usuário realmente precisa é mais “arte” do que ciência. Você precisa saber lidar com pessoas. Você precisa saber que o usuário é um ser humano como outro qualquer e que está muito confuso sobre o seu problema. O usuário define seus softwares tal como um casal apaixonado olha para o céu e vê cachorrinhos nas nuvens. E ele faz isso porque o nosso cérebro funciona assim: por associações. É por isso que vira e mexe ele olha outro software que não tem nada a ver com o seu problema e diz: eu preciso disso! Então você começa a desenvolver e aprende a duras penas que não era nada daquilo… e você muda um pouco aqui, muda um pouco ali e quando vê já está com um Software Frankenstein nas mãos.

O usuário define seus softwares tal como um casal apaixonado olha para o céu e vê cachorrinhos nas nuvens.

É neste ponto que você deve deve ter a “astúcia” de abstrair os desejos do usuário, considerar as informações relevantes sobre o que ele está lhe falando e propor soluções que, pelo seu conhecimento, devem agregar mais valor do que aquilo que o usuário pensava antes. E você terá que saber argumentar com ele sobre esta “nova” solução. Porém, compre mesmo esta briga! Não desista tão facilmente de convencê-lo a “fazer do seu jeito”. Demonstre confiança no que você esta falando. Baseie-se em estudos, fatos, exemplos. Conquiste a confiança dele antes de qualquer coisa. Não existe receita de bolo para isso e eu acredito que é por isso que estes templates de Casos de Uso ou qualquer outra coisa do tipo falham. Não me refiro ao artefato em si, mas o modo como ele é concebido: geralmente um processo burocrático, formal, nada humano e extremamente chato!

Finalmente, quando você consegue fazer O QUE O USUÁRIO PRECISA pode até ser que exista algum atrito no inicio – porque ele ainda não tem certeza que precisa daquilo. Mas conforme o tempo passa ele entenderá melhor porque as coisas estão tomando o rumo que estão tomando – ele aprende junto com você o real problema. E eis que o usuário passa a querer o que ele precisa e é aí que está a chave do sucesso.

Nota: Este post é uma “extensão” do comentário que fiz neste outro post.

Um dos problemas de desenvolvimento do Software, especialmente no Brasil, é o TI-Centrismo.

O TI-Centrismo prega que TI é o centro do Universo. Desta forma, muitas das decisões tomadas no ciclo de vida de desenvolvimento do Software visam “proteger” TI.
- “Não pudemos mudar isso, é padrão de TI!” = TI-Centrismo
- “Não dá para fazer assim, o banco não permite” = TI-Centrismo
- “Não vou deixar meu código feio assim. Deixa essa animação pra lá” = TI-Centrismo
- “Vamos fazer o Café com Leite, senão vai dar muito trabalho.” = TI-Centrismo

Precisamos mudar isso! Precisamos deixar o TI-Centrismo e adotar o Usuário-Centrismo. Pode não parecer mais isso muda muita coisa.

Programadores odeiam código feio. Por outro lado a parte estética da aplicação e as animações são sempre deixados para o final. O problema? Bem, muitas vezes perde-se muito tempo tentando fazer aquela arquitetura super hiper robusta com o super hiper design pattern onde não precisa.

Mas por que a estética, incluindo animação é importante? Porque isso deixa o usuário num estado mental muito melhor. Isso faz com que o usuário:

1. Perdoe erros mais facilmente
2. Tenha maior pré-disposição para aprender a mexer na aplicação

Fizeram uma experiência com dois caixas eletrônicos idênticos em termos de usabilidade e implementação. Um bonito e outro feio. O Caixa mais bonito teve uma avaliação muito melhor do que o caixa mais feio. No Caixa mais feio as pessoas reclamaram muito mais dos erros (propositais) do que no caixa mais bonito. Uma coisa é o usuário bater o olho numa coisa bonita e falar: “Uau… que legal isso. Bem, agora deixa eu ver como eu uso!”. Outra coisa é ele falar “Nossa! Que coisa medonha, como eu uso isso?” O estado mental é tudo. A motivação é tudo. E coisas feias definitivamente desmotivam.

Quando abandonamos o TI-Centrismo e adotamos o Usuário-Centrismo nossa percepção muda. Eu prefiro perder tempo fazendo uma animação que vai agregar mais valor à experiência do usuário do que aplicando aquele super ultra design pattern que li no ultimo livro que ostento na minha estante e que só vai servir para eu exercitar o que aprendi. E isso tem a ver com outra coisa que eu chamo de Tradeoff com foco no valor agregado (assunto para um outro post).

Em muitos casos o TI-Centrismo é como uma religião. Só espero não ser condenado como Galilei Galilei por tentar mostrar que o centro do Universo não é o que os devotos pensam.

Ao adotar o Usuário-Centrismo comecei a me perguntar se os POGs que tanto incomodam os programadores que pregam boas práticas em 100% do Software (TI-Centrismo) são realmente um mal em todos os contextos. Eu ousaria dizer que, no Usuário-Centrismo existe o POG do Mal e o POG do Bem. Imagine que você precisa implementar uma animação em Flex e que, como um bom programador, você tentou fazer da melhor forma possível. Mas não teve jeito! Você vai ter que colocar um Timer para fazer funcionar perfeito (típico POG para resolver problemas de tempo em animações em Flex). Mas você é um programador “bonzão”. Você jamais vai fazer este POG. Então você se recusa. Afinal de contas, para quê animação, não é mesmo? Mas a pergunta é: Tal animação vai agregar valor à experiência do usuário? Sim! O POG vai ser fonte potencial de problemas? Não! O POG vai ser difícil dos programadores entender? Não (nada que um comentário simples não resolva). Então, por que que eu vou me recusar de fazer algo que mais agrega à experiência do usuário do que, de fato, prejudica TI? Porque eu sou adepto do TI-Centrismo. Eu não faço software para o usuário, eu faço para mim. Para o meu ego.

Eu quis manter o diagrama acima simples e por isso o fiz “incompleto”. No caso da complexidade, por exemplo, mesmo que POG pareça “comprometer a complexidade” é preciso colocar isto na balança pois também acredito que não há mal algum em algo complexo, encapsulado e que pouco vai ser mexido. Mais um vez, é o que eu chamo de Tradeoff com foco no valor agregado.

O TI-Centrimo começa nas Universidades ou quando o iniciante está aprendendo a programar. Nesta época, sem experiência e capacidade para julgar, os professores colocam na cabeça das pessoas que a performance do sistema é um problema independente do contexto. Em outras palavras, aprende-se que sempre se deve otimizar um simples “for” (tentar transformar 200 iterações em 100 por exemplo). Aprende-se que se deve preocupar com a performance desde o início. Mas o que não é dito é que código otimizado é mais complexo. O que não é dito é que o gargalo de performance corresponde a um percentual muito pequeno do código do seu software. O que não e dito é que você geralmente não sabe onde está este gargalo e que no final das contas você vai perder muito tempo tentando otimizar código onde não é preciso, adicionando complexidade ao seu código e deixando de fazer outras coisas que agregam mais valor. Isto é TI-Centrismo!

O TI-Centrismo cria tantas restrições para se fazer um bom trabalho que Software de qualidade do ponto de vista do usuário é praticamente impossível. O TI-Centrismo é respaldado (entre outras coisas) pela alienação do programador. Softwares existem porque alguém precisa usar. Este alguém é o usuário. Ele é a razão do software existir. Mas muitos programadores esquecem disto e o seu código passa a ter uma razão de existir em si. Este programador aplica Design Pattern porque ele gosta. Ele aplica boas práticas porque ele gosta. Ele faz código otimizado porque ele gosta. Mas ele não gosta de perder tempo com animação – que as vezes é o que vai agregar valor à experiência final.

Você pode adotar o Usuário-Centrismo e continuar apreciando código bonito e de qualidade. A diferença é que o Usuário-Centrismo vai lhe fazer pensar que o seu código tem que ser bom para lhe permitir fazer um Software cada vez melhor não para você, mas sim para o usuário.

O que jamais podemos esquecer é que fazemos softwares para os usuários. Então ele deveria ser o centro do universo, e não TI.

Minha filosofia: mais importante do que saber o que implementar é saber o que não implementar para não perder tempo. Se eu entendo que têm coisas que raramente acontecem eu deixo pra lá. Quando acontecer? O usuário que se foda!

Não que eu não me importe com o usuário. Muito pelo contrário. Eu só deixo de fazer estas coisas que acontecem raramente para focar em coisas que acontecem com freqüência. No fundo, estou pensando em atender o usuário na maioria dos casos – o que realmente vai fazer diferença para ele no seu dia-a-dia. Não existe o Software perfeito e o usuário vai me xingar de qualquer forma. Mas não vai xingar a maior parte do tempo (porque a app ficou ruim pois perdi tempo desenvolvendo para a exceção). Ela vai me xingar só na hora da exceção.

O problema? O pessoal de TI vive desenvolvendo software para a exceção sem ao menos questionar a importância da exceção. Mas a exceção adiciona complexidade ao Software em todos os sentidos. Você vai levar mais tempo para fazer e muitas vezes vai ter uma usabilidade ruim para os casos que não são exceção… ou seja, para a maioria dos casos, justamente onde a usabilidade deveria ser boa. Neste caso, se você tiver mesmo que tratar a exceção faça isto a parte. Não prejudique 99% da usabilidade do seu software por causa do 1%. Se a usabilidade tiver que ficar ruim que fique no caso do 1%. Enfim, trate exceção como exceção, ou melhor, não trate… acredide, muitas vezes você não precisava lê-lo feito.

Pense nos Softwares que vocês usam. Quantas vezes não conseguimos fazer determinadas coisas? Isto é a Apple e a Microsoft falando “foda-se!” para nós usuários. Eles também não tratam todas as exceções. Por que nós, pobres mortais, temos esta ficção nisto? A minha dica é: Mesmo que o usuário bata o pé, se você estiver confiante que não precisa tente postergar. Deixe para fazer por ultimo. No meio do caminho faça coisas bem melhores, coisas que vão desviar a atenção dele. Acredite, lá no final o usuário não vai nem lembrar daquelas besteiras que ele pensava que eram importantes.

Primeiro era apenas o Flash. E os puristas da Web, sonhadores utópicos da Web 100% Semântica, viviam malhando as empresas que usavam Flash, dizendo que ele era proprietário e tudo deveria ser feito seguindo os padrões que chegaram ao nirvana ao passar pelo mais severo julgamento do W3C.

Mas como não poderia deixar de ser o caminho para o paraíso dos padrões Web é longo demais. Agora, não apenas a Adobe mas também a Microsoft (Silverlight) e o próprio Google (quem diria???) não querem mais esperar pelo seu pedacinho do céu. Quem quiser inovar, não pode ficar esperando pelo W3C. Um passo atrás no que diz respeito à padronização, mas quem disse que para o mundo evoluir ele precisa ser padronizado? Você conhece alguma coisa realmente boa que seja toda “certinha”? Oras, a internet só evoluiu desta forma porque ela não é perfeita. Ela é livre. É democrática. É aberta.

É verdade que teríamos muito a ganhar com uma Web totalmente padronizada. Mas levando em consideração o custo desta padronização parece que as empresas perceberam que mais vale ir atrás da inovação. Num certo sentido podemos dizer que o W3C “freou” a Web durante algum tempo, mas parece que daqui para frente veremos coisas realmente impressionantes surgirem graças as iniciativas digamos… “proprietárias” (palavra terminantemente proibida nos templos do Mundo do Software 100% livre).

Os fiéis dos Padrões Web, que muitas vezes também são seguidores da ceita Software 100% Livre, só precisam entender que a sua religião não é necessariamente melhor que as outras. A iniciativa privada sempre alavancou a evolução tecnológica e justamente pelo fato da Web ser democrática isto vai continuar acontecendo. Ao invés de eu me preocupar se vou ficar sob o controle do Google, da Microsoft ou da Adobe eu vou é mais procurar fazer parte da festa. Aos fiéis, resta rezar esperando que o mundo um dia se veja livre destes pobres pecadores que não seguem a risca os mandamentos do mundo do Software 100% Livre e da Web 100% semântica.

OBS.: O Objetivo desta crítica não é pender para um lado nem para o outro. Eu acredito na Web Semântica, mas não 100%. Eu acredito no Software Livre, mas não 100%. Eu acredito em iniciativas proprietárias, mas não 100%. Todo radicalismo é contraditório ao bom senso.

O Silvio Moreira, que não se considera blogueiro mas tem um blog, foi falar que a blogosfera morreu (confesso que li o post dele às pinceladas porque achei o início do texto formal e prolixo demais). E vejam só a blogosfera repercutindo o post dele. Acho que isto ainda vai dar muito o que falar na suposta moribunda blogosfera.

Em minha opinião o que está ocorrendo é uma seleção natural. Uma espécie de Darwinismo Digital que permitirá que apenas os melhores blogs sobrevivam. A falácia que o Silvio Moreira comete nada mais é do que Generalização Apressada. Acho que ele deveria fazer como o seu chará de sobrenome e assumir de vez o caso com o Mister M (Isso foi só para ser engraçado. Sim, estamos na blogosfera!).

Muitos criticam as RIAs da Plataforma Flash por não serem RIAs que seguem os padrões Web (Web Standard). Mas eu tenho a impressão que se olharmos esta questão com mais cuidado vamos concluir que justamente por não seguir os padrões estas RIAs possuem a tendência de serem muito mais viáveis que as RIAs que utilizam os padrões. Vejamos por quê.

1. ActionScript

Apenas recentemente o ActionScript apareceu entre as 20 linguagens de programação mais usadas. Quando eu falo nos treinamentos de Flex que as pessoas tem que usar uma “nova linguagem” muitos torcem o nariz. Mas primeiro é preciso ressaltar que o AcionScript foi desenvolvido respeitando os mesmos padrões (ECMAScript) que o JavaScript – o que diminui a curva de aprendizado. No entanto o ActionScript não é JavaScript e se no curto prazo isto pode parecer um problema (ter que aprender uma nova linguagem) no médio prazo você verá que isto é um grande benefício.

Quem já teve a oportunidade de usar o Browser do Google deve ter percebido o quanto algumas aplicações rodam mais rápido. Isto se deve ao fato do JavaScript ser “pré-compilado” no Chrome depois do primeiro acesso. Em outras palavras, parece que só agora as empresas estão percebendo que para aplicações complexas interpretar o JavaScript já não é mais viável. No entanto, o ActionScript, que já é compilado há muito tempo, continua sendo infinitamente mais rápido que o JavaScript no Firefox, no Internet Explorer e no Opera.

Além disso, o ActionScript 3 é muito mais Orientado a Objetos e já tem suporte total ao E4X, funcionalidades estas que ainda aparecerão no JavaScript um dia (ninguém sabe quando). O fato é que é muito mais fácil para a Adobe introduzir novas funcionalidades no ActionScript do que uma nova versão do JavaScript ser aprovada e todos os browsers a suportarem.

2. W3C

Assim como deve demorar para o Firefox, o Internet Explorer, o Chrome, o Opera, e outros browsers suportarem a versão mais recente do JavaScript demora para eles suportarem a versão mais recente do HTML e outros padrões. Eu não sei se você sabe, mas para um conjunto de tags no HTML ser aprovado leva um bocado de tempo. São quatro fases até alguma coisa ser finalmente recomendada pelo W3C. Isto quer dizer que por mais que as novas Rich Internet Appications exijam novas funcionalidades elas só se tornarão realidade na medida em que o W3C for mais ágil na evolução dos padrões.

No caso da Adobe é diferente. Ela controla o SWF e pode adicionar novas funcionalidades muito antes do W3C. Inclusive, funcionalidades que talvez nunca existam nos padrões Web.

3. Flash Player

Se o usuário quiser ver um vídeo no HTML sem ser Flash Vídeo você estará dependendo do Windows Media Player ou do Quick Time ou de outro formato de vídeo qualquer se é que eles existem ainda. Além disso, pode acontecer dele ter o Windows Media Player mas não ter o Codec. Quer coisa mais chata do que isso? No Flash Player o usuário tem áudio e vídeo integrado. Ele não precisa de outro player nem um codec específico porque ele já tem o Flash Player.

Agora, imagine também que você pode compartilhar com segurança bibliotecas de Interface de Usuário entre aplicações mesmo elas estando em diferentes domínios. Imagine também poder persistir objetos complexos nos Cookies além de simples strings. Imagine também poder fazer duas interfaces de usuário conversarem entre si de uma maneira segura mesmo estando em diferentes domínios. Eu estou falando de Runtime Shared Library, Shared Objects e Local Connection. Tudo isto são funcionalidades desejáveis para atender alguns requisitos das Rich Internet Applications que você não tem com os padrões Web mas tem na Flash Platform.

4. FXG vs. SVG

A próxima novidade da Adobe que fará muita gente torcer o nariz é o FXG (Flex Graphics). Em muitos sentidos FXG faz o mesmo que o SVG. E o motivo pelo qual a Adobe resolveu não seguir este padrão pode ser lido na integra aqui.

Falando de forma resumida, a Adobe resolveu não usar o SVG porque ele é limitado demais para o que a Adobe quer oferecer de funcionalidade nas RIAs da Flash Platform. O FXG vai permitir tirar melhor proveito do Data Binding, terá uma sintaxe mais concisa e poderá tirar bom proveito das novas funcionalidades do Flash Player 10 como o 3D.

Enfim, creio que a Adobe fez muito bem em não adotar o SVG dada a lentidão que os padrões evoluem. Para se ter uma idéia o SVG está em desenvolvimento desde 1999 e ainda tem um suporte muito fraco nos browsers. O SVG mal foi adotado e já está ultrapassado.

Conclusão

Equipes extremamente talentosas como a do Google podem desenvolver boas RIAs viáveis usando os padrões Web. Mas sabemos que no mundo real as coisas não são bem assim.

É verdade que as RIAs da Plataforma Flash tem uma grande empresa no controle e isto incomoda muita gente. Parece que num mundo onde grande parte das coisas funcionam com base na confiança as pessoas de TI ainda vivem na utopia de que a tecnologia deve ser “imparcial” em si. Por isto, elas tem medo de que grandes empresas estejam no “controle” de determinadas tecnologias. Tal medo nas pessoas é até justificável. O problema é que vem a mente uma série de “e se” que por medo as fazem recusar algo que não é necessariamente ruim: “e se a Adobe resolver não dar mais suporte ao Flash Player”; “e se a Adobe resolver cobrar pelo uso do Flash Player”, etc. Bem, ao invés de me preocupar com estas hipóteses baseadas no medo eu prefiro me voltar para os indícios. E nos últimos quatro anos eu não vi muitos indícios capazes de me fazer acreditar nestes “e se”. Mas vejo sim o W3C lento demais para saciar a minha sede de desenvolver boas RIAs viáveis. Seria perfeito poder desenvolver boas RIAs viáveis utilizando só os padrões Web. Mas infelizmente o mundo não é perfeito.

Que tem muito gerente incompetente, assim como muitos “subordinados”, todo mundo já sabe. Mas, o que eu quero entender é o meio e não o fim. Quero entender é porque a maioria dos gerentes de TI são uns bostas. Ao contrário do que você pode pensar isto não é um desabafo. Já tive contato com muito gerente bosta, mas enquanto escrevo este texto não penso em nenhum deles. Na realidade o que me motiva escrever este texto é um receio que um dia eu jogue neste time. E porque isto também pode acontecer com você, tentarei criar um cenário que tenta explicar alguns dos motivos pelo qual isto acontece.

Tudo começa quando você decide fazer um curso de exatas. Você toma esta decisão porque odeia os assuntos relacionados a humanas. Você, provavelmente odeia ler e quando pega um livro vai direto aos exemplos. Você só quer ver código e acha que tudo mais além disso é desnecessário.

Os anos passam e agora você é um bacharel em Ciência da Computação que mesmo depois da faculdade continuou atuando de modo a aprimorar suas competências técnicas. As pessoas respeitam você como técnico e é notável como você se destaca no time. E justamente por estar acima da média, justamente por estar se destacando dos demais, a empresa decide que você merece reconhecimento. Então você se torna gerente.

Saem os Design Patterns, a OOP, o Refactoring e entra a liderança, a comunicação e a criatividade. Oras, isto tudo não teria mais a ver com humanas? Isto é justamente aquilo que você deixou de lado pois sabia que não tinha aptidão. Mas você não pode dizer não para esta proposta e deixar de ganhar mais do que você ganha como técnico, não é mesmo? Quem sabe você, além de ser um bom técnico, é um líder criativo que se comunica muito bem com as pessoas, não é mesmo?!

Bem, no início os seus subordinados respeitam você. Afinal de contas você conquistou este respeito enquanto você era um deles. Sempre que é preciso falar de coisas técnicas você ainda agrega muito à equipe. O problema é que você continua agregando valor muito mais como um técnico do que como um gerente. E quando surgem os primeiros problemas nos quais você deveria exercer sua capacidade de liderança você falha. Ao falhar repetidas vezes a equipe vai tendo a impressão de que você não faz nada como gerente.

Os anos passam e você não investe em aprender a ser um bom gerente porque os livros que falam disso são chatos: eles não tem código. Além do mais você odeia ler. Mas você acredita que chegou aonde está por méritos próprios e é muito orgulhoso para reconhecer que precisa recomeçar do zero. Também não lhe sobra tempo para se atualizar no mesmo ritmo que a sua equipe técnica evolui e aquele respeito que eles tinham por você desaparece. Neste momento você já não agrega valor nem como técnico nem como gerente. Então as pessoas começam a comentar pelos corredores que você de fato é um bosta que não sabe o que fala e que não faz nada.

Moral da história: ao te nomear como gerente a empresa não sabia que estava tomando uma decisão duplamente equivocada. A empresa não sabia que estava perdendo um excelente técnico e ganhando um péssimo gerente. Você é bom de exatas, mas agora ocupa um cargo onde saber resolver uma equação diferencial não faz a menor diferença.

“Existiria algo nesta inovação que só seu idealizador, Steve Jobs, foi capaz de enxergar? Algo não tão evidente que o torna tão superior aos demais Smartphones do mercado?”

Eu nunca me importei com o ultimo ultramoderno celular XYZ 500 que tira foto com excepcional qualidade e faz cafezinho. Também sempre achei o IPod muito caro embora eu admire a sua superioridade como produto. Apenas quando eu estive na MAX em 2005 eu comprei um IPod Shuffle (e só fiz isso porque era para dar de presente para minha namorada). O que isto quer dizer? Que embora eu trabalhe com tecnologia eu não sou nenhum aficionado por Gadgets.

Mas depois que eu vi um amigo mexendo no seu IPhone, pela primeira vez eu me senti predisposto a pagar tão caro por algo que talvez eu nem precise de verdade. Mesmo assim eu ainda passei mais de um mês aqui nos EUA resistindo à tentação. Mas desta vez eu não fui tão forte e resolvi pagar $ 399,00 num IPhone. E valeu cada centavo!

Como uma criança com seu brinquedinho novo eu passei a noite inteira mexendo no meu IPhone. E quanto mais eu mexia mais eu queria conhecer sobre ele. Não apenas sobre suas funcionalidades, mas principalmente como a Apple conseguiu criar algo tão inovador e fascinante. Existiria algo nesta inovação que só seu idealizador, Steve Jobs foi capaz de enxergar? Algo não tão evidente que o torna tão superior aos demais Smartphones do mercado?

A primeira coisa que se nota no IPhone – e que não é mais novidade pra ninguém – é o fato dele não ter teclado. E ao contrário do que Steve Ballmer da Microsoft disse, é justamente por não ter teclado que o IPhone é tão superior. Afinal de contas, para que você precisa de um teclado quando você está vendo fotos? Para que você precisa de um teclado quando você está vendo um vídeo? Para que você precisa de um teclado quando você está ouvindo música? Em todos estes casos o teclado ocupa um espaço desnecessário no dispositivo.

Mas o problema com o teclado vai além do espaço físico que ele ocupa o tempo todo. O problema é que ele não é propício para acessar a maioria das funções dos aplicativos. E é por isso que no caso dos computadores existe o Mouse. Aponte e clique simplesmente. Isto é muito mais intuitivo. Imagine por um instante que não existe mouse e tudo que você precisa fazer você tem que fazer pelo teclado. Como você saberá qual tecla, ou combinação de teclas, você tem que pressionar para, por exemplo, alinhar um texto à direita no Word? Talvez as teclas “SHIFT + ]” pudessem ser mapeadas para esta funcionalidade se não houvesse outra maneira mais fácil de fazer isso. Mas definitivamente isto não é nada intuitivo.

Podemos dizer que o Mouse nos permite estender o teclado. Pois o que são as teclas de um teclado além de botões? Assim, na interface do Word existe um botão com um ícone para alinhar o texto à direita. Uma vez que você pode apontar e clicar neste botão, os desenvolvedores não precisam atribuir comandos diferentes aos “botões do teclado” para prover esta funcionalidade. E o melhor disto tudo é que você pode ter botões específicos para cada tipo de aplicação. É por isso que a interface do Photoshop é tão diferente da interface do Word. Pois imagine ter que usar uma combinação de teclas que faz algo no Word e a mesma combinação que faz algo totalmente diferente no Photoshop?

A maioria dos celulares tem um botão direcional para dar acesso a funcionalidades de navegação na interface. Eles têm também um botão de cada lado que hora servem para escolher entre mais de uma opção, hora possuem outra funcionalidade específica dependendo da interface. Embora esta tenha sido uma solução plausível para um dispositivo como o celular, ela ainda é muito limitada porque todos os aplicativos têm que se adaptar a este esquema de Interação limitado. Em outras palavras, o Software deve se adaptar às teclas. E o motivo é simples: As teclas não podem mudar.

Mas eis que surge o IPhone com seu Touch Screen e sua capacidade de “eliminar” os botões fixos. No IPhone os botões não são Hardware, mas sim Software. Hardware não muda, mas software sim. Os botões podem mudar para atender a cada aplicativo específico. Cada aplicativo tem seu conjunto de botões. Cada aplicativo tem a sua interface pensada a desenvolvida para oferecer a melhor usabilidade possível. Para navegar entre as fotos você possui um conjunto de botões, para ouvir música outro, para fazer ligações outro e assim por diante. E o teclado do IPhone não fica aparecendo quando ele não é necessário pois até o teclado também é Software e não Hardware.

Enfim, o que só Steve Jobs foi capaz de enxergar? Ele viu que os outros Smartphones eram como computadores sem Mouse. Pequenos computadores com teclados que impediam que os softwares pudessem ter uma boa usabilidade pela falta de um dispositivo de apontar e clicar. Steve Jobs percebeu que não era o Software que tinha que se adaptar aos botões (teclas) e sim os botões que tinham que se adaptar ao Software (quando você cria uma interface você coloca os botões no lugar mais conveniente). O IPhone pode fazer para os celulares o que o Mouse fez para o Desktop: torná-lo finalmente simples de usar. E embora o IPhone tenha uma série de outras inovações dignas de Oscar, isto já é o bastante para aplaudirmos de pé este grande visionário: Steve Jobs.

Nesta apresentação Steve Jobs explica o problema dos Smartphones atuais: “Eles têm teclado. E as teclas não podem mudar”:

O IPhone é tão fácil que até uma criança que mal sabe falar consegue mexer:

Dá até pena do Steve Ballmer da Microsoft ao vê-lo falar que o IPhone não é bom porque não tem teclado:

As imitações serão inevitáveis daqui pra frente:

Por isso a Apple tem mais de 300 patentes do IPhone.