A coisa toda deslanchou quando CRMs e ERPs começaram a ganhar versões web, direcionando-se para um modelo centralizado, eliminando a necessidade daquelas instalações em clientes, controle das versões, módulos e todo aquele inferno toda aquela via sacra que é controlar isto.

Os softwares web evoluíram, mas ainda precisavam do bendito refresh a cada ação. Surge então, a brilhante idéia baseada em uma API Microsoftiana esquecida ao léu, concebida ainda na década de 90, onde na ocasião os desenvolvedores a chamaram de XMLHttpRequest e tinha como objetivo iteração entre Outlook e Internet Explorer, provendo acesso ao Outlook Web Access. Ah sim, isso é conhecido pelos stakeholders como Ajax.

Com o advento desse tal Ajax, as telas baseadas em funcionabilidades puderam evoluir para telas baseadas em eventos – o que pode ser conversa para outro post – Com essa utilidade, softwares web-based aumentaram em quantidade astronômica e junto levaram a complexidade às alturas !

Essa tal de complexidade, começou a exigir dos softwares comunicação com outros softwares, iteração com diversos dispositivos: hardware hospedeiro; ferramentas e dispositivos físicos plugados na máquina cliente, ou seja, na máquina que está acessando o software via browser. De frente à toda essa necessidade, no ínicio teimaram em prover tudo isso com sua Linguagem de Programação Preferida e Bala de Prata ™. O resultado ? Perda de desempenho, muito dinheiro gasto com códigos que apenas satisfazem a necessidade da linguagem (i.e. Java, oi ?) e noites sem dormir.

PHP é uma excelente linguagem que muitos programadores PHP ainda não conhecem porém, não insista em controlar a impressora do cliente com a tal linguagem por que você simplesmente tomará na cabeça !

Disso, surgiu, assim digamos, um novo tipo de programador: o poliglota. Isso não quer dizer que entender ahn, COBOL e PHP torne-o passível de ser tachado como tal. Martin Fowler em entrevista à Paulo Silveira na Agile Brazil 2010, afirmou sem titubear que o programador poliglota é aquele que trabalha com mais de uma linguagem de programação em um mesmo software.

Neal Ford, tem uma visão um pouco mais abrangente sobre poliglotismo: ele afirma no livro The ThoughtWorks Anthology que o grande ponto do poliglotismo é aproveitar o que cada linguagem que roda sobre a JVM tem de melhor a oferecer. Ele dá exemplos de Java + Groovy; Java + JRuby e até Java + Jaskell. Isso é sem dúvidas infinitamente melhor do que tentar fazer uma aplicação em PHP e testá-la com Ruby e Cucumber sem qualquer tipo de integração direta =P

Desenvolver desta forma é mais comum do que se pensa ! Os primórdios dos Internet Banking’s foram construídos – e assim continuam – desta forma. Nada de arquitetura SOA ! – O banco ABN AMRO tem um artigo sobre SOA publicado no JISTEM-USP – É utilizado Java e PHP com o módulo PHP-Java bridge para tal mágica. Empresas como Facebook, Last.fm, Google, Yahoo! utilizam mais de uma linguagem para uma mesma ferramenta como é anunciado na rede. Isto demanda profissionais com algumas características:

• Livre de tecnologia. Os fanboys de linguagem de programação ficam a ver navios;
• Domínio da teoria. Não basta ficar preso às facilidades de uma linguagem X ou Y; Faz-se necessário conhecer o por quê das coisas, pois uma linguagem pode ser mais ou menos easy-to-use do que a outra;
• Interesse em conhecer novas formas e padrões: não adianta forçar-se a programar com o estilo Java com linguagens como Ruby. Camel case não é o padrão em Ruby;
• Vontade em conhecer novas linguagens. No livro The Pragmatic Programmer é pelos autores recomendado que você aprenda uma linguagem nova a cada ano, e;
• Estar apto a mudar tudo quase tudo, sempre!

Diante de tudo isso, qual linguagem “investir”? Eu levo em consideração a minha vontade na linguagem. Não é porque a linguagem Scala não está no topo dos mais procurados que eu não partiria para aprendê-la e usá-la em meus projetos e experimentos pessoais. É questão de afinidade com a linguagem. O mercado? Virá atrás de você de forma natural.

Artigo originalmente postado por mim no até então blog Ready to Sail, hoje, o planet da Vex.

Salvador Dali, 1931 - The Persistence of Memory

Já conversei com pessoas que batem o martelo facilmente dizendo:

- É por tempo.  Eu programo em brainfuck há seis anos, logo sou sênior.

Será mesmo ?

Em tempos modernos, fica ainda mais complexo fazer uma avaliação deste tipo para programadores, arquitetos ou engenheiros de software, pois, não é somente uma linguagem de programação que está em análise. É todo um contexto que abrange desde a escolha do ambiente de desenvolvimento até relacionamento com stakeholders e domínio em metodologias e paradigmas de desenvolvimento.

Se temos a análise temporal como inválida, então o que espera-se de um dito sênior ?

Para tal, conversei com três pessoas que estão diretamente envolvidas com estes aspectos.

Creio que sim. Existem os profissionais seniores, porém muitas pessoas, e empresas, acabam confundindo o nível do profissional com o seu tempo de experiência.

Em minha visão, o tempo de experiência é importante, porém, não determinante para rotular um profissional, ou seja, é perfeitamente possível existirem seniores com 3 anos de experiência e juniores com 15 anos.

O profissional Júnior, é aquele que já desempenha as tarefas com certa autonômia, porém, necessita de um maior tempo de pesquisa e em alguns casos de orientação.

Por sua vez, o pleno já demora um tempo menor para realizar as mesmas tarefas além de não necessitar de orientações referente aquela tarefa. O que difere o pleno de um sênior é a visão holistica, ou seja, para ser um profissional sênior é preciso possuir habilidades complementares as necessárias para o desenvolvimento daquela tarefa, isso ajuda acima de tudo no desenho de uma melhor solução além de maior facilidade no tratamento de problemas.

Outro ponto que vale ser observado, é que muitas vezes o sênior é destacado para tarefas simples, que não exige um conhecimento avançado, como seguir um procedimento de criação de usuário. Esse fato, além de desmotivar o profissional, gasta recursos de forma imprudente, já que são os seniores que deveriam criar os procedimentos a serem seguidos, além de desenhar soluções para problemas e corrigir falhas críticas ou em serviços críticos.

Vinícius Bufoni, coordenador de engenharia web na Vex

Este é um assunto interessante. Na maioria dos lugares as pessoas usam “anos de experiência” como medida para classificar. Esta é, na minha experiência, uma das piores maneiras de se fazer este tipo de classificação. Uma pessoa que desenvolve em, digamos, JSP e Servlets Java por 10 anos não necessariamente tem 10 anos de experiência desenvolvendo software, ele tem experiência desenvolvendo JSP e Servlets! E mesmo assim, tempo gasto em uma tecnologia não está diretamente relacionado com proficiência nesta. Enfim, utilizar tempo para medir experiência é, normalmente, uma besteira.

A forma com que eu tenho lidado com esta relação entre níveis de desenvolvedores, atualmente, é usando algo chamado modelo Dreyfus de aquisição de conhecimento: http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition .

Normalmente eu tenho as áreas em que eu considero que meu time deve ser competente (este post: http://fragmental.tw/2009/11/24/i-wish-i-knew-that-before-getting-this-job-–-slides-and-long-notes da uma idéia sobre quais seriam estas áreas) e uso o Dreyfus para tentar entender onde cada um está nestas competências. Tem funcionado relativamente bem para mim mas ainda é, como sempre será, problemático e, por muitas vezes, injusto.

Phillip Calçado, consultor na ThoughtWorks

Do meu ponto de vista um profissional sênior é acima de tudo auto suficiente, é o tipo de profissional em que você não precisa passar o que deve ser feito, ele geralmente entende seu papel em uma equipe e como pode contribuir.

Um profissional Sênior consegue tomar decisões e assumir responsabilidades, ele não depende de alocações e precisa de muito pouca supervisão gerencial e técnica.

Geralmente um profissional Sênior também, está sempre atualizado e esta sempre ligado em tendências do mercado e em como adaptar estas novidades a sua realidade nos projetos em que esta envolvido.

“Tempo” de experiência na verdade não é tão importante, mas a diversidade e intensidade da experiência da pessoa é extremamente importante, se ele esteve envolvido uma grande diversidade de projetos e atuou em papeis dos mais diversos, um profissional sênior geralmente consegue se adaptar pois já trabalhou em diversos papéis e com diversos times.

No caso de grandes empresas de Internet, como o Yahoo!, é vital que o profissional sênior entenda de e tenha tido vivência com projetos de grande escala, e que entenda de Sistemas, arquiteturas e plataformas que funcionem com grandes volumes de acesso e demandam muita performance.

Não gosto muito destes rótulos, mas um profissional Pleno depende de um nível de supervisão/apoio maior. Um Pleno também tende a ser mais inseguro na tomada de decisões e definições mais complexas.

Mas a principal diferença é a experiência, bagagem de conhecimento. Em entrevistas sempre pergunto qual foi o maior desastre da carreira da pessoa, espero que ele me diga quais foram os erros e o que ele aprendeu com isso. Isso mostra maturidade em relação a tentativa/erro, onde não se deve temer cometer erros e que sempre devemos aprender com eles e continuar tentando. Isso é chave para ser inovador.

Antônio Carlos Silveira, diretor de Produto e Engenharia, Yahoo! América Latina

Cada um tem seus métodos de análise, mas ficou evidente que contar os dias no calendário já não é mais tão convincente como parecia

Random Hack of Kindness São Paulo 2010 por danicuki

Eventos como Yahoo! Open Hack day; Google Developer Day; o recente Random Hack of Kindness; Coding Dojo (o de Sampa no IME da USP está meio inativo ao que consta); e vários outros movimentos iniciados até por empresas, como a própria Caelum que já abriu as portas para criar um ambiente onde programdores pudessem se juntar e desenvolver suas coisas, ou mesmo que fechado ao grupo de programadores da mesma como já ouvi relatos de programadores.

O que leva esse bando de programador malhucos das cavernas a participarem com empolga̤̣o destes eventos Рmuitas das vezes apenas com free lunch e Internet 0800 ? Ṣo desocupados ? Loucos ?

Yahoo! Open Hack Day Brazil 2010 por Antônio Carlos

Simples: adoram o que fazem ! São essas pessoas que geralmente criam tendências, aplicam ideias e tomam iniciativas nas corporações em que trabalham; São os mesmos developers que passam horas a fio programando com vários livros de nomes nonsense à tira-colo; ou que criam projetos pessoais para suprir uma necessidade própria e acabam chamando a atenção de muita gente – vide tantas startups bem sucessidas criadas e mantidas por programadores.

Geralmente esses mesmos programadores conhecem pelo menos duas linguagens. O motivo ? Curiosidade ! Pouco importa se Ruby on Rails fará sucesso no mercado coorporativo ou se Python não agrada o chefe. É legal para eles, então, investem tempo nisto.

Sempre em busca de novos conhecimentos, fanáticos pela arte em programar e fazer coisas novas; de novas formas e com novas ferramentas. Criam coisas, compartilham o feito e ainda passam a diante o novo conhecimento com artigos, blogs ou seminários. São programadores sempre motivados que buscam fazer uma análise crítica sobre suas próprias formas de programação buscando a evolução das ideias.

Vida social ? Muito bem, obrigado ! Nestas idas e vindas acabam conhecendo pessoas, lugares e oportunidades diferentes. Trocam ideias, conversam, trocam contactos das redes sociais; juntam-se em botecos ou equivalentes tornando o simples ato de programar em grupo em praticamente uma festa completa !

1.”The early years”.

O meu primeiro computador veio tarde, foi um 386, mas foi o suficiente para me introduzir no mundo dos computadores e me deixar completamente fascinado. Quando comprei meu primeiro modem foi que a coisa começou a tomar força, acessava as BBSs e quando finalmente a internet apareceu, tive certeza o que queria fazer da minha vida.

Desde cedo comecei nos esportes, durante vários anos fui atleta profissional, nadava duas vezes ao dia, de segunda a sábado. Começava de madrugada, das 5 às 6:30, a tarde, das 4 às 5 tinha preparação física, e das 5 às 7:30 era o treinamento principal na água. Eu nadava em média média 12 a 14km por dia.

Meu primeiro livro foi a história do Kevin Mitnick, não deu outra, ele foi minha maior referencia e inspiração na infância/adolescência, comei a estudar programação, Linux, BSD, montei um grupo hacker, comecei a andar com os melhores hackers do Brasil e além da natação, computador era uma das coisas que eu mais gostava no mundo.

Nunca fui bom aluno, sempre achei um saco a escola e a forma como ensinavam as coisas. Tomava broncas homéricas quando meu boletim chegava. Um dia, para deixar meu pai feliz, larguei a coisa mais importante da minha vida, para mostrar o quanto eu estava empenhado em estudar. Saí da natação e resultado, nada mudou. Só que mais tarde eu entendi que tudo aquilo foi importante para eu ingressar no mundo profissional. Deixei de ser hacker e comecei a entender como o mundo dos negócios funcionava. Mergulhei no software livre, que acabou me abrindo todas as primeiras portas.

2. Totalmente direto quando o assunto é Java. Por quê tamanho desdém por uma das linguagens mais utilizadas no meio corporativo ?

De jeito nenhum, deixei de ser radical ainda novo, acho o Java uma excelente linguagem e plataforma de desenvolvimento, foi responsável por uma expansão brutal do nosso mercado, mas infelizmente em todos os problemas que eu encontro na vida, existe uma solução mais interessante que o java. Você que trabalha comigo aqui na Vex, sabe que temos uma área web, outra de redes, outra de sistemas embarcados e agora teremos aplicativos desktop e mobile e mesmo assim o Java não entra como minha primeira opção em nenhuma delas.

3. Como um bom programador você deve possuir uma linguagem que tenha mais afinidade e como consequência, habilidade. Qual seria e por quê ?

Depois de tantos anos programando, percebo que não existe uma linguagem que te acompanha para o resto da vida como sua melhor linguagem, em cada momento ou fase da minha vida eu tive uma linguagem de programação mais presente, a que até hoje nunca foi superada na minha opinião, o C, mas tem suas aplicações limitadas, obviamente eu não usaria e não uso C para uma serie de aplicações, mas considero uma linguagem pura e eficiente, elegante quando bem utilizada. Em linguagens de script para servidor, gosto muito do Python. Para desenvolvimento web, confesso que o Rails tem roubado os meus holofotes. Programei muito em muitas outras linguagens, de Assembly a Visual Basic ou Delphi, acredite, programei nessas linguagens. Mas teve fase da minha vida que fui apaixonado por Lisp. Também fui apaixonado por C++ e PHP e também programei bastante no quase falecido Pascal.

4. De developer à manager. Você tinha como objetivo este “desvio” na carreira ou chegou como uma boa oportunidade ?

Nunca tive a pretensão de ser chefe, mais importante ainda, nunca tive interesse em ser chefe. Sempre fui extremamente técnico, minhas leituras sempre foram regadas a tópicos bem profundos da tecnologia. Por este motivo eu admirava empresas gringas que valorizavam bons engenheiros, eu imaginava que poderia continuar como engenheiro e ainda assim ter um nível salarial comparado a um gerente ou diretor. Mas ei, eu estava no Brasil, a cena de tecnologia era praticamente nula, eu tive que mudar minha mentalidade e subir a escadinha dos cargos, hoje eu sei que as coisas são bem diferentes e hoje já é possível ser um eterno engenheiro com um bom salário, ainda não é fácil, pois são raras as empresas que dão boas condições no Brasil. Mas desde então passei a estudar e aprender este outro mundo, marketing, finanças, vendas, gestão de pessoas, política, etc. Ainda bem que eu tive essa vontade de ser eterno engenheiro e não consegui, assim como várias outras vontades na minha vida que eu não realizei, hoje todas elas são minhas metas de vida, para tornar isso realidade para alguém. Pratico hoje o que eu busco amanhã, meu funcionário ideal é aquele que tem amor incondicional pelo que faz, assim como eu tive e tenho pela tecnologia.

5. Seguindo a nomeclatura do mercado, temos cargos baseados em níveis por, em teoria, conhecimento: Júnior, Pleno e Sênior. Assumindo que você está em busca de um profissional dito sênior, qual seria sua forma ou metodologia para tachar Foolano ou Ciclano adequado ao título ?

Vale lembrar que eu sou totalmente contra as formas tradicionais de organização de recursos humanos, muitas empresas acabam errando ao fazer isso. Falando especificamente de engenharia de sistemas, o conhecimento técnico é sempre um pré-requisito para um sênior, um candidato que se propõe a trabalhar com um determinado assunto e não domina completamente o assunto é eliminado imediatamente. Além disso, o cargo Senior pressupõe que o engenheiro tem muita experiência prática, escreveu centenas de milhares de códigos, passou por dificuldades em diversos tipos de sistemas diferentes. Mas eu ainda assim penso que cada pessoa é única, não pode ser tratada genericamente, já tive gênios na minha equipe que eram completamente loucos e anti-sociais, impossíveis de trabalhar em equipe, uma maçã podre que todos nós sabemos qual destino tem. A história de vida de cada um tem importância, outras aptidões, estilo de vida, equilíbrio e controle emocional também formam um profissional Sênior.

6. Mantendo a linha sob o foco de níveis em cargos, quais seriam as diferenças fundamentais entre um programador pleno e sênior ?

Este é tema para um artigo, mas resumidamente, eu gosto de definir as características para cada um dos cargos, aplicar uma pontuação a cada uma delas e definir os interva-los para os cargos propostos, como você mencionou poderia ser Junior, Pleno e Sênior.

Por exemplo:

1. Formação acadêmica (x pontos)
2. Linhas de código escrita (y pontos)
3. Tempo de experiência (z pontos)
4. … (n pontos)

• Junior – 10 pontos
• Pleno – 20 pontos
• Sênior – 30 pontos

Essa metodologia funciona muito bem se muito bem testada e validada, mas como mencionei acima, muitas empresas utilizam algo similar de forma completamente errada. Quantas empresas que conhecemos que definem para um engenheiro de sistema que a formação acadêmica é um pré-requisito? Um detalhe besta que faz com que perca-se pessoas brilhantes. Vale lembrar o que eu já mencionei várias vezes, os melhores programadores que eu conheci na vida não tinham formação acadêmica.

7. Com o “boom” das metodologias ágeis, começaram a preocupar-se mais com processos de desenvolvimento de software. O que temos atualmente, porém, são muitas empresas sem processos e metodologias mesmo que primárias para gerenciar a produção (de software). Como gestor, qual sua visão sobre esta falta de processos e qual a solução que você indicaria para uma possível adoção ?

Quando eu comecei a trabalhar não falava-se muito neste assunto, anos mais tarde eu me vi em meio a implantação de ISO 9001 e CMMI. O CMMI é uma das coisas mais radicais que eu vi na vida, impraticável, não se da um peido sem levantar os requisitos, prazo, riscos, conseqüências e pedir permissão e após autorizado registrar em log, relatórios, lições aprendidas, etc. Sou totalmente contra alguém fazer algo do tipo, pelo jeito muitas pessoas são, não foi a toa que surgiu as metodologias ágeis, que se preocupa somente com o que realmente funciona. Meu conselho para este de prática é, aprenda as melhores, utilize somente o que fizer sentido. Não seja radical, pois as vezes a melhor metodologia é não ter metodologia.

8. É comum ler pela rede a seguinte expressão: “Desenvolva para mudanças”. Para tal, é fundamental o foco na qualidade do software produzido/mantido. Apesar de óbvio, não é isto que realmente acontece. A qualidade, no mundo real, é sim um fator “negociável” e por isso falhas, insatisfação do cliente e o retrabalho aumentam drasticamente. Em seu ponto de vista, qual o problema em fazer da qualidade uma constante ao projetar software ?

O dia em que o chefe absoluto da sua empresa for um engenheiro que passou por tudo isso que você esta passando, pode ser que isso não mais aconteça.

8++. Como você tem mantido organizadas atividades profissionais na Vex e projetos pessoais ? Utiliza-se de ferramentas ou técnicas de organização pessoal ou tem mantido tudo nos renomados checklists (i.e. Remember The Milk) ? E como tem feito uso de tais ferramentas ? (dica de @chanelym)

Já inventei muito para me organizar, hoje eu posso dizer que eu alcancei uma forma prática e funcional de me organizar bem. Eu pratico muitos conceitos do GTD e tenho duas principais ferramentas, um gerenciador de tarefas, utilizo o Things (http://culturedcode.com/things/), que me acompanha em meus computadores, iPhone e futuramente no iPad, e um bom calendário (iCal), paralelamente utilizo muito o AddressBook, tudo sincronizado com Push.

Chegou a hora delas, as palavras finais…

Novamente, obrigado por aceitar o convite
Parabéns pela iniciativa do blog, continue sempre escrevendo, foi um prazer responder a sua entrevista. Boa sorte e continue firme e forte, pois enxergo em você um potencial muito grande.

Meu blog empoeira às vezes, mas para quem quiser visitá-lo: http://blog.marcelotoledo.org.

Topei ! Respondi 8++ questões as quais podem ser vistas acessando o blog dele.

Agradeço o convite e deixo aqui um convite formal para um bate-papo numa (un)conference qualquer. o/

O check-in para a prova é um pouco tenso colocando ainda mais medo em quem vai fazer a prova. Documentos em inglês, assinar em três lugares diferentes, marcar hora de entrada, guardar itens no guarda-volumes e entrar liso, apenas com o crachá da instituição em uma baiazinha apertada de 1x1 metro quadrado onde mal cabe você e o computador.

Essa baia tem um além do PC - totalmente travado e rodando Windows 2000 - um fone para os ruídos externos não atrapalhar-te durante a prova. Bem acima há uma câmera filmando todas suas ações e a única coisa permitida é utilizar o teclado, mouse e uma folha de anotações com apagador e canetão para lousa.

Na minha prova, resumidamente caiu: PHP 4, 5, diferenças entre 4 e 5 e uma pergunta de PHP 3. Design patterns caiu umas quatro ou cinco questões. Admito que era necessário pensar, não era perguntinha boba como do tipo: "o padrão que faz tal coisa é : ..., ..., ...". Era necessário analisar a melhor solução com as patterns lá descrimidas e fazer sua escolha. Gostei dessa parte

Havia perguntas cabulosas onde era alterada várias vezes e de várias formas um objeto copiando, referênciando e tudo mais; para no fim ele requerer a saída de todas variáveis que aquele objeto teve durante o ciclo de vida.

Caiu coisas sobre segurança, PDO, SQLite, perguntas específicas de banco de dados - coisas como definir transação, prepared-statements, ... - comparação de tipos, coisas sobre arrays e refatoração de código. Neste último ele fornecia um código legado em PHP 4 e pedia a versão em PHP 5. Nada complexo, coisas simples, somente para testar se você conhece PHP4

O tempo de prova é excelente. 90 minutos para 70 questões. Eu finalizei a prova restando pouco mais de 40 minutos. Super tranquilo. Fiz sem pressa, na calma, lendo e pensando nas soluções.

É totalmente permitido pular questões e depois voltar nelas, porém, não fiz isto. Fui na sequência. Direto !

Ao fim, ele mostra as questões que possívelmente não tenham sido respondidas e pergunta se você quer finalizar a prova. Clicando que sim, ele confirma novamente e informa que não há mais volta :O

Ao confirmar novamente, aparece uma barrinha de "loading...". Ela ficou por alguns segundos, que mais pareciam uma eternidade. Respirei fundo e olhei para a tela novamente. Vi em negrito e em h1: Congratulations ! You passed (..) [alguma coisa a mais que eu nao lembro]

Respiro de alívio e ao mesmo tempo ergui as mãos e falei meio que sem voz: Eu consegui !

Saí da salinha mais do que depressa e ao chegar na recepção já havia um "comprovante" da prova informando que eu havia passado, com data, hora e meu código da prova.

Agora estou esperando chegar a certificação pelos correios e pelo que andei olhando no Flickr, junto virá um adesivo Zend Certified PHP 5 para eu colar na testa onde quiser.

A prova exige que você tenha vivência com a linguagem. Não adianta "decorar", comer livros ou fazer cursos de verão. Esqueçam. Precisa saber o que acontece quando as coisas dão certo e principalmente: o comportamento das coisas quando dão errado. Como por exemplo:

Você pode - e deve - pesquisar por simulados online e realizar testes com a linguagem. A melhor coisa que você pode fazer é ler o manual do PHP. Melhor fonte para aprender bem o PHP. Há também o Zend Self-test que você poderá tentar também.

A primeira edição da Revista TI Digital saiu no começo de março, porém, aqui na Terra da Maçã, chegou às bancas apenas na semana passada.
As matérias da revista estão focadas no desenvolvimento de software no geral, seja PHP, Java e qualquer outra ferramenta livre ou proprietária.

Uma das matérias da edição foi os prós e contras de ser freelancer ou um contratado normal. A matéria ao meu ver ficou balanceada, havendo quem defendesse totalmente o salário "fixo"; outro que defende o salário fixo, porém, sempre pega uns freelas e outro que vive apenas como freela

Apresentando o lado 100% freelancer da matéria eu procurei  expor minha experiência nessa área, abordando a liberdade que há em trabalhar desta forma; aspectos como liberdade em escolher ferramentas e métodos de trabalho e também o lado gerencial da coisa.

Li o ponto de vista dos demais entrevistados, concordo com certos pontos apontados por eles, mas não acredito em "estabilidade financeira". Um freelancer pode ficar sem projetos assim como um funcionário regular pode ficar sem emprego. Tudo depende do momento, do seu trabalho e claro, de seus contatos

Não repudio quem trabalha assim, cada qual joga seu jogo, quem sabe até, eu experimente trabalhar em agência para ver como é !

Por fim, quem leu a revista e tenha algo a considerar sobre esta matéria, por favor, fique à vontade para perguntar, criticar ou elogiar

Ser freelancer não é uma tarefa fácil, quem é freelance sabe muito bem como que é o dia-a-dia. A grande diferença é que além de exercer a profissão de forma autônoma, você precisa gerenciar seu negócio, relação com clientes e seu tempo.

A idéia é ir adequando suas tarefas na ordem que melhor combinar no seu dia-a-dia, mas como isso leva um tempo e essas adequações só vêm com o passar do tempo (e experiência) vou listar algumas idéias aqui que podem lhe serem úteis.

1. Separando seus horários.

Obviamente, você como freelance, tem toda a autonomia do mundo para controlar seus horários, logo, é fundamental separá-los para dedicar-se às tarefas com mais empenho. Aqui funciona assim:
Pela manhã, eu leio o meu Scrum e minha agenda (de papel) vendo e separando os compromissos das tarefas. É fundamental ter em mente que Compromisso é diferente de tarefa.

Um compromisso é algo que tem dia e hora para começar e para acabar. Podemos assumir como exemplo a visita a um cliente ou levar seu cachorro para passear, por exemplo

Uma tarefa é algo que tem um dia para começar e acabar, mas não estritamente tem uma hora para começar e finalizar. Como por exemplo, postar no seu blog ou aprontar aquele orçamento bacana do seu futuro cliente (amém).

Depois de ver que não tenho compromisso algum naquele dia, vejo as tarefas que tenho que cumprir para manter-me em dia e dou o start. Sempre atento ao Scrum e a agenda sigo durante o dia, atualizando eles quando finalizo algo.

No fim da tarde, com as tarefas em dia, eu planejo o próximo dia, definindo prioridades e atualizo Scrum e a agenda.
Na parte de noite, como não tenho mais a faculdade, eu dou um tapa no escritório, estudo alguma coisa ou simplesmente não faço nada.

Resumo: vejo minhas tarefas, desenvolvo-as, atualizo scrum e agenda, preparo as novidades, estudo ou descanso.

2. Fazendo as coisas funcionarem

Obviamente no papel (ou na tela) é tudo mágico e simples, porém, eu sei muito bem que no dia-a-dia a porca torce o rabo.

Você até consegue organizar suas prioridades antes das 8hs. Mas depois, é cliente ligando, problemas aparecendo, uma verdadeira loucura !

Para contornar isto, é simples: organize-se ! Sim, é simples. Antes das 8hs esteja de pé e acordado em seu local de trabalho. Até as 8:30hs tenha sua lista de pendências diária pronta e seu "roteiro" definido.

Se já tomou seu café, dê o start nas tarefas, agora caso seje igual a mim, então, tome um café da manhã esperto e comece a fazer as coisas funcionarem.

Se nesse intervalo algum cliente ligar querendo uma visita sua, tente negociar para o dia seguinte (consulte sua agenda antes !) marcando um horário certo e tão rápido quanto desligar o telefone, já anote este evento em sua agenda. É batata ! Não tem erros !

Após finalizar suas tarefas do dia, se ainda houver tempo, planeje seu próximo dia, e tente andar com seus projetos pessoais, afinal ficar na mesmisse sempre pode custar caro no futuro

3. Analisando as evoluções

O Scrum (sim, falo muito dele pois, é bem eficiente !) permite que você controle suas tarefas semanalmente, ou seja, se você tropeçar em alguma coisa durante a semana, você perceberá que isto lhe atrasou - ou não - e se aplicável planeje novamente sua agenda para colocar as coisas em dia.

4. Vendo resultados

A adoção de um "padrão de organização" é meio sofrida às vezes, mas é bem recompensador depois que você consegue usá-la no dia-a-dia. Após uma semana você verá que não irá passar o dia arrancando os cabelos com deadlines chegando, compromissos esquecidos e "sobrecarga" de horários na sua agenda, pois você não irá agendar nada além do que você tem de disponível na semana.

Tudo que citei aqui pode parecer super óbvio, porém, não é o que nós costumamos aplicar no nosso dia-a-dia. Contamos muito com nossa memória, que às vezes pode funcionar muito bem, mas infelizmente ela não implementa uma agenda.

O modelo que mostrei no começo do post, foi baseado no modelo que o Alexandre implementa - ou implementava na época - e foi ele quem me apresentou isto. Gostei, apliquei e depois nunca mais larguei. Recomendadíssimo !

O conteúdo do site é em inglês, porém, para quem consegue ler vale muito a pena. O site é o http://freelanceswitch.com/.

O Alexandre e eu, criamos um blog com o mesmo foco, só que totalmente brasileiro que também está valendo a leitura. O Vida de freela mantém o mesmo foco do FreelanceSwitch.com

Freelancers. Uni-vos!

Post rápido lembrando que nos próximos dias 9, 10 e 11 de Nomebro estará acontecendo na UNICID o Conisli 2007 com várias palestras sobre Software Livre e desenvolvimento. Se você puder participar, vale a pena inscrever-se ainda dá tempo!
Estudantes tem 50% de desconto na inscrição. Não esqueça de levar o comprovante de pagamento e comprovante de escolaridade hein!

Até lá