Empresário? Empreendedor? WTF?

Nos últimos três meses a minha vida profissional mudou da água para o vinho.
Eu era sócio de uma pequena empresa de web, com uma visão de desenvolvimento web diferente das demais “agencias”. Tirando o primeiro registro da minha carteira que marca uma passagem de 6 meses em uma agência de design, como assistente de Web Designer, eu nunca trabalhei como empregado. Fiquei durante 5 anos da minha vida ajudando dois amigos a erguer uma outra empresa de internet, com ideais também inovadores e uma vontade enorme de mudar a forma com que o desenvolvimento web era feito. Um desses amigos acabou se tornando meu sócio em uma segunda empresa e a partir daí foram 6 anos, erguendo uma empresa e construindo uma comunidade em volta.
Até 2 semanas atrás eu não sabia o que era receber salário, mas sabia o que era pagar vários salários. Eu não tinha que marcar ponto, eu tinha que controlar o ponto. Erguer uma empresa dá trabalho, mas é bom. Você não precisa ter faculdade para isso. Você precisa apenas ter coragem.

Aí você descobre que ter coragem é a parte fácil. O difícil é você pagar imposto, salário, gerenciar expectativas de clientes, se preocupar com a vida dos seus funcionários, entender como a carreira deles pode melhorar, saber movimentar a empresa para o lugar correto no mercado e além de tudo isso não tirar os olhos do fluxo de caixa. É aí que você aprende a diferença entre ser empreendedor e ser empresário. Eu achava isso o máximo. O seu ego vai lá pra cima. É gostoso responder quando alguém te pergunta o que você faz ou no que você trabalha. A resposta vem pronta e ensaiada: “Sou empresário. Tenho uma empresa de desenvolvimento de Internet. Atendo clientes como XKPPYZ, XPTO e etc…” Coisa linda, sabe?

Algo de estranho acontece

Mas teve um dia que algo mudou. O problema é que quando você tem uma empresa e tem contas a pagar, é difícil perceber quando “algo” muda. Esse “algo” pode ser o movimento do mercado ou pior, pode ser você mesmo – como aconteceu comigo. Ninguém vai avisar quando essa mundaça acontecer… O segredo é quanto tempo você demora para descobrir.

Esse “tic” me aconteceu em um momento nada oportuno. Mesmo assim fui em frente. Sempre, sempre, sempre com uma dúvida atrás da orelha para atrapalhar. Mas nesse caso, meu caro, minha dica é siga em frente. Minha decisão já estava tomada. Saí da empresa. Foi algo realmente duro. É difícil você tomar a decisão de deixar para trás algo que você construiu, do nada. Do nada mesmo. Nós NUNCA recebemos nenhum aporte financeiro de NENHUMA empresa. Pelo contrário, tivemos que nos virar, pedir alguns mangalotes na fábrica de dinheiro em momentos difíceis e caminhar com mais uma parcela no bolso. Ah, quem dera ter recebido um aporte financeiro. Mas não. Eu tinha uma empresa que faturava pouco mais de 1 milhão/ano sem a ajuda de ninguém. Isso sim é algo para se orgulhar. Não é coisa de moleque. Mas é óbvio que um aporte financeiro não mata ninguém, né?

Falou demais, cara. Onde quer chegar?

Eu sei que falei demais e provavelmente você ainda não sacou onde eu quero chegar. Aí está o “x” da questão. Onde você quer chegar? Eu não tenho faculdade e nunca fui empregado. Decidi sair da minha empresa para aprender algo novo, realmente. Obviamente havia outros motivos mais específicos e menos “romanceados” como este. Decidi pagar para ver e aprender algo que eu nunca tive. Sabe quando você se alista pra virar soldado e descobre que outro cara também se alistou só que ele fez aquele cursinho e virou sargento direto? Pois é. Eu tinha feito o cursinho de empresário/empreendedor, nunca fui soldado. Como o cara pode se sargento se nunca foi soldado? Por causa disso eu cometi muitos erros. Eu também deixei que outros cometessem erros. O que é muito ruim também já que o erro dos outros, na sua empresa, afeta você diretamente.

Aí você fala: “Espera, você deixou de ser empresário, onde você poderia ficar rico e ganhar dinheiro, pra ser empregado?” Eu respondo: Você está com o mesmo pensamento que eu estava nas primeiras semanas do meu “primeiro” emprego depois de sair da minha principal empresa (sim, eu tenho mais duas). Eu quase pirei nas primeiras semanas. Essa é uma outra história. — Em duas semanas aprendi mais coisas do que em muitos anos da minha vida. Posso falar mais aqui depois, se estiverem interessados. — Mas se você acha que só pode ser rico sendo empresário, nem abra uma empresa. Dinheiro é consequencia, sendo empresário, empreendedor ou empregado. E sim, eu sei que lá no fundo é o dinheiro que importa. Mas ele não vem só porque você decidiu abrir uma empresa. Ele vem porque você é bom no que faz. Você tem que pensar sobre dinheiro de forma estratégica e não como objetivo final. Isso em qualquer área e em qualquer cenário que você se encontra. Decidir abrir ou não uma empresa é também uma decisão estratégica, mas da sua vida. E no final, tudo se resume ao seu comportamento diante de decisões simples na frente da batalha.

A ideia é que você deve seguir seu instinto. Se você for empresário, não seja demasiadamente estúpido e dizer que NUNCA mais trabalhará como empregado na vida. E se você é empregado, meu caro, não diga que abrir empresa é algo difícil. Você pode estar com medo.

Talvez eu nem saiba o que eu esteja dizendo agora. Mas eu já estive dos dois lados da fronteira. Hoje eu sou empregado em uma das maiores empresas de hospedagem do Brasil, tenho uma startup e cuido de um portal. Sou empresário ou empregado? Quem tem que definir é você.
Ter uma empresa ou ser empregado é uma decisão sua e para ambas decisões é necessário ter coragem. Existem vantagens e desvantagens dos dois lados. Como eu disse anteriormente, ganhar dinheiro é possível em qualquer um dos dois cenários, então esse não é o problema. Os passos em cada um dos caminhos são diferentes em diversos pontos, mas se você reparar bem, são mais parecidos do que aparentam.

Posts Relacionados

• Agora é a vez dos desenvolvedores
• ePub: Aprenda a criar um livro digital
• Introdução aos padrões de codificação
• CSS1K
• Um pensamento sobre design para web

Quando há um grande projeto ou sistema onde o código passará por várias pessoas, invariavelmente este código ficará complicado. Tenha em mente que complexidade não é a mesma coisa que complicado. O código pode ser complexo, o que ele não pode ser é complicado. Você tem que conseguir escalar seu código sem precisar de nenhuma (ou o mínimo) modificação na estrutura do HTML.

Existem algumas precauções que nos ajudam a manter o controle durante todo o projeto. Cada projeto merece adaptações destas precauções. Citarei aqui algumas que costumamos utilizar na Visie.

Estruturando o HTML

Não é muito difícil estruturar o HTML. Na verdade tudo o que você precisa está no wireframe. O wireframe te fornece a visão de como será o código HTML puro e simples. A estrutura básica do seu código pode ser baseada no wireframe oficial do layout onde haverá todos os elementos semânticos e importantes necessários para a produção da estrutura principal. Não há ali marcações visuais como degrades, backgrounds e etc. Você consegue enxergar o website de uma maneira enxuta. Obviamente você precisará melhorar o código posteriormente. O wireframe não te dá detalhes como: onde tem um background, onde há um gradiente etc. Por isso, o código criado no wireframe, embora seja um código simples e enxuto, pode ser que precisem de modificações.

Parece óbvio, mas eu preciso dizer que o código desta estrutura precisa ser a mais simples possível porque ela será utilizada em todo o site.

Validação inicial

Depois que este primeiro código foi feito, é necessário que haja uma validação. Essa validação pode ser feita pelo validador do W3C e por um profissional que avaliará a semântica dos elementos escritos.

Muitos desenvolvedores acham que a validação do W3C inútil. Outros são fanáticos demais e dizem que se um site não é válido ele não tem o direito de ser publicado. Os dois extremos estão errados.
Tenha em mente que o validador do W3C apenas avalia a sintaxe do seu código. Ele não avalia por exemplo a qualidade da semântica do código, logo, ele não te diz se você utilizou as tags da forma mais corret.
Mesmo assim é interessante que você valide o código logo na primera versão escrita. Assim há a certeza de que todas as outras páginas estarão sem erros, já que o código inicial será reproduzido no resto do site. Se houver algum tipo de erro ali, ele será multiplicado por todo o site e você não saberá onde se originou.

Nomenclatura de class e id

Assim como é importante ter um código HTML legível, ter um código CSS bem organizado pode ajudá-lo a produzir páginas mais rapidamente. A criação de uma nomenclatura inteligente é o ponto chave para termos velocidade na produção de novas páginas ou na manutenção das páginas existentes.

Já vi desenvolvedores que colocam nomes estranhos para elementos da estrutura principal do site como se ninguém mais fosse ler aquele código. Muitas vezes esse alguém pode ser você mesmo dali alguns meses tentando resolver um problema importante e não conseguindo porque colocou nomes nos elementos de forma aleatória.

O nome do elemento (class ou id) deve estar relacionado com o conteúdo deste elemento. Se você fará um elemento NAV que produza um menu lateral, é melhor que seu nome seja “menulareral” e não “listagemdelinks”.

Modularização do CSS

O código CSS pode aumentar de uma hora para outra. Seu arquivo pode passar de 100 linhas para 1500 em um piscar olhos. É importante que você tenha os códigos que serão utilizados na estrutura global do site em arquivos separados. Existem muitas formas para modular seu código CSS, cabe a você decidir como fazer isso de acordo com a necessidade do projeto. Sentar-se com toda equipe envolvida na produção deste código pode ajudar bastante a boa evolução do projeto.

A modularização CSS melhora a velocidade do site, já que o browser apenas carregará o código de estilo necessário para formatar a página visitada.

Criando elementos com Javascript

Existem muitas ocasiões em que é necessário escrever código HTML que servirá apenas para ajudar a formatar elementos complexos. Infelizmente ainda temos que utilizar estes elementos para dar suporte a compatibilidade visual entre os diversos navegadores. Estes elementos extras fatalmente deixarão seu código mais sujo. Uma opção interessante é que este código seja criado via Javascript evitando que o código HTML original – onde a programação server-side é aplicada e também o código que os leitores de tela e os sistemas leem – seja prejudicado. Isso nos leva a outro nível de controle que é a separação do código Javascript, modularizando os scripts que criarão o HTML dinamicamente.
Normalmente utilizo o jQuery para manipular e criar estes elementos.
Como os robôs de busca e leitores de telas para cegos não entendem Javascript, eles renderizarão apenas o código puro do seu HTML, ignorando o código criado via Javascript. Embora essa prática seja bem confortável, o seu uso não pode ser exagerado. Sugiro que você use somente para criar detalhes visuais que o CSS não dê conta sozinho ou se o site precisar funcionar em navegadores antigos.

Concluindo

Os pontos que citei ajudam a ter um código client-side sustentável por todo o processo. Em cada projeto há maneiras de aperfeiçoar estas táticas. Tente utilizá-las de forma que ajude toda a equipe envolvida e que o legado seja simples de migrar ou executar manutenções. Lembre-se que o código client-side deve ser legível e simples o suficiente para que a sua leitura em diversos meios de acesso seja possível. Lembre-se também que você não está sozinho no projeto e que diversas outras pessoas terão contato com o código nas fases subsequentes.

Posts Relacionados

• Convertidos do Tableless
• Introdução ao CSS 3D – Flip Card
• OOCSS ou CSS do jeito certo
• Nem só de client-side vive um site
• CSS3 – Animation e regra keyframe

Eu não desenvolvo sites para o Internet Explorer 6 se o cliente não pedir. Nas propostas e nas reuniões costumo deixar bem claro que o IE6 está fora da cartilha de browsers compatíveis. Nesse momento é bom conversar com o cliente para entender o mercado dele. Caso ele precise que o Internet Explorer 6 seja previsto, eu aviso duas coisas: 1. O valor da proposta vai aumentar. 2. O tempo de desenvolvimento também.
Claro que os motivos para estas decisões precisam ser explicados. Não vou aumentar o valor da proposta simplesmente porque sou contra o IE6. Mas porque eu terei mais trabalho pela frente.

É muito trabalho, para pouco retorno
Eu não preciso dizer para você que o Internet Explorer 6 é complicado. Você já sabe. Mas o seu cliente não deve saber.
Para que o IE6 passe no teste de satisfação, temos que seguir alguns longos passos:

1.    Previsão de bugs de compatibilidade de CSS e HTML.
2.    Previsão de CSS escrito exclusivamente para o IE6.
3.    Bateria de testes e pente fino de Design em comparação ao layout original e outros browsers.
4.    Manutenção exclusiva
5.    Muito código e limitações de tecnologia

Previsão de bugs de compatibilidade de CSS e HTML.
Não preciso dizer que o IE6 é uma colcha de retalhos. Há dezenas de bugs conhecidos  relacionados ao desenvolvimento com CSS e HTML. Todos estes bugs precisam ser previstos e solucionados.
Muitos desenvolvedores já tem conhecimento destes bugs já preparam o código para que eles sejam previamente solucionados e não haja surpresas posteriores. Infelizmente isso nos leva para o próximo tópico.

Previsão de CSS escrito exclusivamente para o IE6.
Não é nada inteligente escrever código CSS cheio de Hacks. Você acaba misturando código errado com código correto. Sem contar que que usuários de browsers atuais não precisam baixar um código com hacks para solucionar problemas de um browser descontinuado. Por isso, uma solução interessante é criar um arquivo CSS apenas para o Internet Explorer 6. Entenda que nesse arquivo não haverá todo o código do site, apenas o código que servirá para curar os bugs de layout exclusivos do IE6.
Atualmente essa solução é a mais interessante porque o IE6 está prestes a sumir. Quando isso acontecer, basta você retirar a linha que linka esse código e pronto, seu site não suporta mais IE6.

Bateria de testes e pente fino de Design
Invarialmente você precisará gastar um tempo para fazer uma bateria de testes em todo o layout para se certificar de que nada está fora do lugar.
É regra haver diferenças gritantes de alinhamento, medidas e distâncias no layout do Internet Explorer 6  em relação ao layout original e aos outros browsers.

Manutenção exclusiva
Prepare-se para ter alguém cuidando exclusivamente do Internet Explorer 6 durante tempo indeterminado.
Com os browsers atuais, é normal fazermos implementarmos um layout e o resultado ser homogêneo durante as versões posteriores dos browsers. Se você precisar fazer alguma alteração brusca no layout, prepare-se para a manutenção no IE6.

Muito código e limitações de tecnologia
Um exemplo clássico é o suporte ao PNG. Havia um trabalho terrível para replicar sombras e determinados tipos de gradiente por conta do efeito alpha que os designers aplicavam nas imagens. O desenvolvedor client-side precisava fazer tantos slices de imagens quanto nos tempos do desenvolvimento com tabelas. A ideia de que o design deveria trabalhar para o conteúdo era totalmente esquecida. O design deveria ser seguido ao pé da letra, mesmo que isso prejudicasse a informação.
Ainda com o exemplo do PNG. Se quisermos que o PNG funcione no IE6, é necessário a utilização de alguns códigos extras de Javascript. O resultado não é 100%, há um consumo desnecessário de banda e também o browser consome processamento de máquina do usuário. Escrevemos muito código para ter por resultado.

Os exemplos acima são decisivos para o desenvolvimento. Isso precisa ser explicado se seu cliente faz questão do IE6. Contudo, há clientes que precisam dessa compatibilidade por obrigação, por conta de um legado que não é simples de resolver. Aí não tem jeito. Você vai ter mais trabalho e o cliente vai gastar mais. Ninguém fica feliz.

O processo de evangelização é feito nas trincheiras. Então, mãos à obra!

Posts Relacionados

• Google Apps não suportará mais IE6
• Experiência cross-device
• Agora é a vez dos desenvolvedores
• CSS1K
• Um pensamento sobre design para web

Mas não é tempo de comemorar, ainda há muito trabalho a fazer. Há oito anos o Zeldman publicou seu célebre artigo To Hell With Bad Browsers, em que nos explicava porque devíamos abandonar o suporte aos navegadores 4.0. O ponto básico era não ter que fazer várias versões do mesmo site. Uma versão apenas, com bom layout CSS, podia funcionar para todo mundo, com todas as vantagens dos padrões web, mas não nos navegadores 4.0.

Bom, fazem oito anos. OITO LONGOS ANOS! Há oito anos que podemos escrever uma versão só de cada site, desde que saibamos escrever hacks de CSS e ajustes de float para o Internet Explorer 6. Há oito anos que estamos repetindo o fato de que o Internet Explorer 6 é a pedra que restou em nosso sapato. Há oito anos que sonhamos em não ter que escrever hacks.

A morte do Internet Explorer 6 significa apenas isso: poder usar PNG transparente e não ter que escrever hacks (ou não ter que escrever tantos hacks.)

A Microsoft passou oito anos sem atualizar seu navegador para nos dar exatamente o que? PNG transparente? Nesse período, Firefox, Opera, Safari e Konqueror estão trabalhando em coisas como controle de opacidade, CSS transform, bordas com imagem, sombras, media queries, colunas e os maravilhosos novos seletores do CSS3. Coisas maravilhosas que você já pode usar, mas a maioria de seus usuários não vai ver porque usa Internet Explorer.

A morte do Internet Explorer 6 nos leva apenas ao lugar onde deveríamos ter chegado há oito anos: sites sem hacks. A Microsoft ainda está algumas gerações atrasadas e, se queremos usar CSS 3 e HTML 5 um dia, é bom parar de comemorar e voltar ao trabalho. Há um mundo para mudar.

Posts Relacionados

• Novo parser HTML5 – FF4
• Conteúdo, Flash e HTML
• Ah, o maravilhoso mundo real
• Command & Conquer: Tiberium Alliances
• Experiência deve ter começo, meio e fim