Como a Apple conseguiu fazer tudo certo fazendo tudo errado

A wired escreveu uma interessante reportagem sobre como a Apple conseguiu se tornar uma empresa muito bem sucedida indo completamente contra a maré, e como o culpado por isto funcionar é uma pessoa apenas: steve jobs.

Enquanto a maioria das empresas trata seus funcionários como deuses, oferecendo as maiores regalias para eles, na apple eles são tratados como lixo por jobs. Basta lembrar o filme “Piratas do Vale do Silicio” para imaginar como ele trata seus subordinados. Todos são humilhados, ridicularizados e temem por seus empregos, porem todos apreciam seu chefe, e fazem de tudo para agradá-lo.

Na apple todos são iguais. Se o vice-presidente chegar atrasado, ele terá de buscar por uma vaga no estacionamento como qualquer outro funcionario. Porem, Steve Jobs não. Se ele estiver atrasado e a vaga de deficientes estiver vaga, é ela que ele irá ocupar. E ele geralmente o faz, a ponto de que os funcionarios da empresa trocaram o emblea de deficientes pelo emblema da Mercedes.

Empresas como a microsoft produzem apenas o sistema operacional, empresas como a macromedia produzem software de qualidade e empresas como a dell produzem o processador. Ou seja, cada empresa se especializa em uma área e nela produz os melhores resultados. Não na apple. Na apple todo o pacote é desenvolvido. Do mouse ao processador, do sistema operacional ao emoticon. Isto faz com que todo o pacote possua a qualidade que a Apple espera de seus produtos, e se seus clientes estão insatisfeitos é por sua falha, não por que terceiros relaxaram no desenvolvimento de produtos.

A maioria das empresas ve blogs e fãs como publicidade gratuita. Diversos presidentes de empresas possuem blogs aonde anunciam quais os futuros projetos da companhia, e incentivam seus funcionários a comentarem sobre suas atividades em seus blogs pessoais, mesmo que seje para reclamar. Na apple, por outro lado, cobre-se de segredo todo e qualquer novo projeto da empresa. Seus funcionarios tem de assinar contratos aonde se prontificam a não comentar com ninguem, até mesmo parentes, no que estão trabalhando. Até o próprio Steve Jobs cuida para manter o trabalho da empresa em segredo, chegando a cobrir com um pano o protótipo do iPod Hi-Fi que levara para casa para experimentar. Tal absurdo chega ao ponto de que os funcionários de um projeto são proibidos de comentar com outros funcionários da empresa sobre o que estão a desenvolver. Muitos sequer sabiam que existia algo chamado iPod sendo desenvolvido na empresa até pouco antes deste haver sido lançado para o publico,

Curioso ver como uma pessoa com uma mentalidade tão retrograda de administração consegue produzir tanto sucesso. Desde que retornou à Apple em 1997 (ele havia sido demitido da empresa que ele próprio fundara), Steve Jobs consguiu tirar a empresa do fundo do poço e fazer com que ela se tornasse um gigante, lider no mercado de mp3 players, inovadora no ramo de celulares e alvo do desejo de dezenas de pessoas em termo de sistema operacional (eu sempre quis ter um OsX pr’eu).

Talvez seja sua aura de realidade distorcida. Steve Jobs faz com que mesmo o mais rudimentar projeto pareça inovador, com que a mais entediante tarefa seja uma tarefa vinda de deus. Jobs possui um estilo quase único de administração, aonde ele tenta se envolver em todas as camadas de desenvolvimento. Do angulo do monitor, à quantos parafusos vao haver na base do notebook, chegando ao cumulo de discutir coisas ao nivel do pixel!

É uma antitese esta empresa, que se propóe a pensar diferente com algumas táticas tão antiguadas de gerncia.

Fonte: Wired

Sincero Pedido de Desculpas

Lembro quando eu estava apenas engatinhando em programação, quando eu trabalhava no laboratório de pesquisas, a famosa Sala 1734. Lá eu dedicava parte da minha vida acadêmica aos estudos de algoritmos genéticos, vida artificial, resolução de problemas de quimiometria, além das normais atividades ligadas à jogatina, bebida e festas. Somente depois de três anos estudando computação foi que finalmente pude dedicar de corpo e alma à esta profissão.

Apesar da minha inexperiência, produzi excelente resultados, otimizando algoritmos já existentes para que aproveitassem melhor os recursos disponíveis, alem de ajudar no desenvolvimento de versões mais rápidas destes (o processo de otimização de um algoritmo genético levava horas, e tão cedo terminava a máquina ficava osciosa. Eu ajudei a reduzir o tempo consumido e a criar filas de testes de modo a permitir melhor aproveitamento das máquinas). Dediquei-me de corpo e alma, e por vezes fazia da minha univesidade minha segunda casa defacto.

Foi então que entrei em discussão com um de meus professores, na cadeira de Engenharia de Software. Me fervia a mente ter de me sujeitar a preencher os sem números de diagramas e organizar as dezenas de tabelas de documentação que meu professor ensinava como ferramentas básicas de um bom e estruturado projeto. Lembrava dos meus códigos, bem estruturados em arquivos ordenados, encapsulados de modo a permitir que um pudesse ser substituido por outro conforme a necessidade, e como para nenhum deles havia um diagrama sequer, uma tabela de documentação (apesar de que eles possuiam alguma documentação… eu SEMPRE documentei meus codigos), uma página de referencia citando o que já havia sido feito e o que poderia ser feito. Meu raciocinio era de que “O trabalho de pesquisa as vezes é algo momentaneo. Eu tenho uma idéia e preciso verificar se ela está correta ou não, e não posso perder tempo documentando isso quando poderia estar programando defacto”.

Alguns semestres mais tarde me vi frente a um problema onde eu sabia a resposta, porem não possuia as habilidades de programação necessárias para realizá-lo. Um de meus colegas possuia as habilidades para realizá-lo, mas não sabia como responder. Juntou-se a fome com a vontade de comer. Tentei explicar para ele como fazer, mas somente depois que rabisquei em uma folha de papel um diagrama com todos os passos que o sistema deveria realizar que este foi programado corretamente. Um excelente sucesso. Mais tarde, com o papel ainda em mãos, percebi o quão errado eu estivera na discussão com meu professor.

Alguns anos mais tarde, quando iniciei minha recente carreira como programador web, me vi novamente frente a diversos problemas onde a falta de documentação dificultava a capacidade de dar manutenção à códigos antigos. E me vi eu sendo o defensor de padronização, reutilização e documentação de código, enfrentando resistência daqueles que acreditam que “perder tempo documentando” iria somente atrasar suas já atrasadas tarefas de programação.

O mundo dá voltas. Nunca substime qualquer ensinamento que lhe for dado.

Estágios de Programação

Programando profissionalmente para uma pequena empresa web me perimtiu visualizar os mais adversos estágios de programação que um poderia imaginar. Os estágios iniciais foram-me apenas relatados, como se fossem estórias de terror de tempos imemorávis.

Inicialmente cada programador era responsável por um projeto. Ele recebia o layout do design, cortava-o do jeito que o convinha programar, organizava a base de dados de acordo com sua lógica, sempre sem utilizar chaves estrangeiras uma vez que estas não existiam nas rudimentares versões de mysql utilizadas outr’ora. As ferramentas de gerência da página de internet eram geradas com um script, que era basicamente um copy-pasta de outros projetos. Bugs eram resolvidos com dificuldade, e toda melhoria no sistema gerava uma quantidade enorme de re-trabalhos e bugs causados porque algo foi mudado que não deveria. Este é o estágio “Cada um por si, e o manual nos acuda!“

O segundo estágio envolve os primeiros passos de centralização do processo de trabalho. Todos os projetos são reunidos e os banco de dados centralizados em um um único servidor. Ferramentas “padronizadas” e testadas são reutilizadas em novos projetos. A programação, porem, continua caótica. Uma vez que os arquivos são abertos diretos do servidor, se duas pessoas tiverem de trabalhar em um mesmo projeto e tiverem de editar um arquivo centralizado, como o arquivo de CSS do site, haverá conflitos por perca do trabalho do primeiro tão cedo o segundo sobre-escrever o arquivo salvo deste. A aparente organização do servidor defato torna dificil trabalhar em time, fazendo os programadores a se forçarem a trabalhar sozinhos para evitarem as dores de cabeça de ter de compartilhar os recursos do servidor. Este é o estágio “Um servidor para todos governar e na desorganização aprisioná-los“

Até o momento não falei em programação orientada a objetos. Esta incrivel opção, introduzida no PHP 3, melhorada no PHP4, divinizada no PHP5, e em processo de trancedencia no PHP6, permite que dados e funções sejam encapsulados de acordo com o contexto destes. $contato_sexo não mais irá receber qualquer valor, mas $contato->setSexo($value) irá tratar o valor de acordo que somente valores válidos sejam retornados com um $contato->getSexo(). Uma vez que as funções do objeto ficam centralizadas num arquivo apenas, é possível organizar o código de modo a re-aproveitar o código em diversos outras funções do site. O programador fica todo bobo com as possibilidades da progarmação orientada à objetos que começa a fazer tudo, por mais ridiculo que seja, utilizando objetos. Este é o estágio “$this->programacao->incrementarEstagio()“

Outro estágio é o de separar o código em camadas. Temos uma camada que conecta com o banco de dados, outra camada que trata de processar as requisições do usuário e organizar os dados vindos do servidor, e uma terceira camada que exibe estas informações seguindo um código simples e fácil de compreender em HTML com pouca inclusão de código PHP (pois a camada de processamento dos dados já deixou tudo arrumadinho para esta). Aqui somos defato programadores profissionais, com códigos limpos e de fácil leitura. Separando as camads, é possivel substituir os códigos de uma de modo a atender as necessidades e limitaçõs do servidor. Programamos o site com mysql, mas o servidor utiliza Oracle ? Sem problemas, basta trocar a camada de banco de dados para Oracle. Esta é a fase “Quer programar como?“

O próximo passo consiste na sequencia do segundo. A estruturação da base de dados agora deixa de ser função do programador, e passa para as competentes mãos de um analista. Chaves estrangeiras são respeitadas, nomes de variáveis padronizadas, alem de todo um trabalho de indexar as tabelas de modo a agilizar sua consulta. O servidor centralizado deixa de simplsmente armazenar os arquivos, mas passa a controlar estes com ferramentas de controle de versão, como o CVS e o SVN. Vemos a divisão da equipe de desenvolvimento em progamadores de módulos e macacos de programação, onde os primeiros desenvolvem as ferramentas que serão utilizadas em todos os projetos que os segundos irão processar. Este é o estágio “Dividir para programar“.

Antes de dar seqüência, quero deixar claro que não há nenhum preconceito para com os macacos de programação. Estes são parte vital da companhia, uma vez que sem eles para finalizarem projetos baseado nos frutos do trabalho dos programadores de módulos não haveria dinheiro algum entrando na empresa. Um necessita do outro para realizar suas funções.

Muito bem, muito bem. Temos agora um ambiente bem organizado de trabalho. Porém ainda não tratamos do árduo processo de personalizar a dar manutenção ao site do cliente. A vantagem de ter o código quebrado em dezenas de arquivos diferentes é que se for necessário corrigir um, basta substituí-lo sem grandes danos aos demais. Porém, o que ocorre quando uma melhoria num módulo tem de ser aplicada em dezenas, centenas!, de clientes diferentes, cada um com uma personalização diferente para o módulo ? E se o site tiver de ser traduzido para um novo idioma, o que fazer ? Para resolver este dilema passamos a nos utilizar de Markup Languages, como XML e YAML. Organizando o código de modo a buscar nestes arquivos os dados personalizados do cliente, podemos muito bem alterar nossa programação sem temer que pornografia apareça em meio ao site daquele cliente filiado à igreja. Este é o estágio “Admirável Configuração Nova“.

Estes são os estágios perceptiveis da organização do processo de trabalho desta empresa. A cada passo que damos é mais um passo para a maturidade desta. Nossos futuros passos, porém, ainda são muitos, e não temos uma noção concreta de para qual direção eles nos levam.