U Mundo TI

ShuHaRi : Aprendendo a Aprender

2012-01-16T11:00:00.000-02:00

Todos os dias somos bombardeados com milhões de informações de todos os lados. Dentre elas, muitas dizem respeito a técnicas, práticas e ferramentas que visam ajudar (ou não) a nossa vida e trabalho. Eu já falei aqui sobre várias que me trazem muito apreço. Porém, após escolher quais dessas vamos experimentar, temos a difícil missão de absorvê-las e realmente aprendê-las.

Para mim o Shuhari é uma ótima filosofia a auxiliar neste caminho de aprendizado e incorporação de conhecimento. Ele é composto por três fases distintas em busca do conhecimento de um conhecimento.

Shu : Proteger

Ao começar o aprendizado de uma técnica devemos nos despir de preconceitos e focar no aprendizado de seus conhecimentos. A fase do Shu consiste em guardar os ensinamentos básicos de maneira passional. Segui-los a risca e buscar entender seus porquês para ter um entendimento completo da técnica.

Esta é a fase em que a maioria de nós desiste. Seja por falta de ânimo ou necessidade ou pelo pior dos motivos, a arrogância. Muitos julgam já conhecer o suficiente sem nem ao menos ter arranhado a superfície de um conhecimento pulando, perigosamente, para as demais fases.

Ha : Desapego

Nesta fase começamos a nos desapegar das regras que nos limitam. O conhecimento profundo somado a prática nos permite começar a quebrar os limites da técnica e saber os contextos onde ela melhor se aplica ou não. Esta é uma fase de maturidade onde já somos capazes de tomar maiores decisões sobre aquele conhecimento.

Nesta fase temos um ótimo aproveitamento daquilo que aprendemos. Com a prática e conhecimento ganhamos eficiência e eficácia naquilo que fazemos trazendo melhores resultados.

Ri : Transcendência

Aqui superamos a técnica, a fluidez e naturalidade já fazem parte de você. É aqui que o horizonte se abre a surgimento e casamento com outros conhecimentos. É uma fase de crescimento e aprimoramento.

Relação com outras técnicas

O Shuhari lembra em muito o Modelo Dreyfus. Sendo bastante breve, este modelo divide a evolução da aquisição de uma habilidade em 5 níveis:

Novato: Possui uma rígida aderência as regras a ele ensinadas.
Novato Avançado: Possui um conhecimento vasto sobre as regras porém possui uma limitação em aplicá-las em diferentes contextos.
Competente: Planeja bem as ações em diferentes contextos e já possui uma vivência em um conjunto limitado de situações.
Proficiente: Possui facilidade em se adaptar a diferentes situações e priorizar os aspectos de cada uma.
Especialista: Age de maneira natural e sem entraves entendendo as limitações envolvidas.

Claramente vemos uma correlação entre os níveis 1 e 2 (Shu), 3 e 4 (Ha) e 5 (Ri). E o modelo de Dreyfus é bastante consistente em suas definições com o que vejo na realidade.

Para mim, a problemática em comparar ambos consiste que Dreyfus é um modelo, e como tal sua maior contribuição é auxiliar na identificação de onde um indivíduo se encontra em sua escala. Ainda assim, é bastante difícil para uma pessoa conseguir se julgar de acordo com este modelo, sendo mais aplicável por um observador externo.

Já o Shuhari é uma filosofia de aprendizado que busca auxiliar em como dominar um conhecimento. Sendo mais fácil (e aconselhada) de ser administrada pelo próprio indivíduo que a busca. Considero essa filosofia algo com uma capacidade bastante aguçada de transformar atitudes, apresentando mais benefícios para quem a busca.

Imagens retiradas de:

Suporte para Celular

2011-12-09T16:00:00.000-02:00

É engraçado de se pensar que, em 3,5 anos de blog, o post mais acessado do site é o sobre o Suporte para Notebook. Sozinho ele tem quase 3 vezes mais acesso que o segundo colocado. Até hoje eu não sei dizer o por que deste efeito. Apesar disto me orgulho bastante daquele post, afinal além de ter superado minha falta de coordenação motora, ainda cheguei num resultado satisfatório. Já se passaram 2 anos e ambos os suportes se mostram em perfeito estado até hoje.

Pois bem, mas por que ressuscitar este assunto? Na Intacto temos um amigo oculto um pouco diferente, onde cada um tem que fazer seu presente, usando o máximo a sua criatividade. Como eu tirei o Fernando Aguiar, um cara fã de software livre (isso temos em comum). Por isso decidi tentar uma evolução do projeto inicial do Suporte de Notebook (que é aberto e disponível a todos) que elaborei junto ao Marcelo Bassani. Nesta segunda versão usei o Papel Pluma, que apesar de seu valor bem acima que o Paraná (usado anteriormente) resultou em algo bem agradável.

O resultado final se mostrou bem mais estável que o anterior. Isso por que o Papel Pluma tem 5 mm de espessura (contra 2,5 do Paraná). Além disso seu interior de isopor o torna mais rígido, dando a estrutura menos maleabilidade de movimentos. O fato de ser coberto por um papel mais trabalhado dá um resultado mais agradável no produto final também. E por fim, o Pluma é bem mais fácil de se cortar que o Paraná, levando a bem menos trabalho na confecção. Como desvantagem temos que é preciso mais habilidade, visto que a inclinação do corte tem grande influência no resultado final.

Mas eu não queria deixar de criar algo novo. Então, inspirado por um outro artigo, decidi fazer um suporte para celular. O modelo e resultado se encontram a seguir. Vale o aviso também que as proporções se adequam bem a celulares grandes, como o Galaxy SII que o Fernando possui, mas pode não se encaixar bem com celulares menores.

Baby Steps e o caso do Google Reader

2011-11-21T10:00:00.000-02:00

Já falei do meu apreço pelo Google Reader anteriormente aqui. Pois bem, já faz mais de um mês que se anunciou e concretizou a integração dele com o Google Plus. Não adiantou as pessoas reclamarem antes nem depois pois a mudança veio e, como tem se mostrado, vai ficar. Pois bem, aproveito esse tempo experimentando as mudanças para dar meu ponto de vista da situação bem como um pitaco nas estratégias da gigante de Mountain View.

Pontos Positivos

Apesar de tanta reclamação as alterações do Reader existem e são bem clara a mim. A começar pela nova interface. A interface antiga do Reader não sofreu grandes evoluções durante toda a sua história e já estava defasada em pelo menos duas versões da identidade visual do Google. A nova apresentação se mostrou mais limpa e mais agradável a leitura.

Outra vantagem foi a troca do "like" pelo "+1". Apesar de haver divergências entre muitos acerca disso lembro que o "like" não trazia muitos benefícios a nenhuma das partes (leitores e produtores de conteúdo). Com o "+1" temos agora uma ferramenta de feedback integrada, assim que produz conteúdo pode tirar mais proveito do uso da ferramenta e saber o que as pessoas acham dela.

Apesar das desvantagens, o acompanhamento dos seus compartilhamentos pelo Google Plus é mais coeso e fácil de acompanhar do que ocorria com os "commented" de antes ou mesmo pelo Google Buzz.

Pontos Negativos

Aqui são vários mas focarei nos principais. O primeiro e mais grave foi a mudança na forma de compartilhar conteúdo. Ao se integrar com o Google Plus e deixá-lo como única forma de acompanhar o conteúdo de seus amigos a Google mostrou que não compreendia o intuito da ferramenta. Isso pois a mudança para o Plus te obriga a mudar o foco de atenção de uma ferramenta focada em conteúdo para uma focada em interação.

Outro ponto negativo de se usar o Plus é seu péssimo suporte a leitura dos compartilhamentos sempre te obrigando a seguir o link a página original (fora do propósito de um RSS) e com previews muito fracos. Algo estranho de se observar pois nestes dois pontos, apesar de não ser muito bom, o Google Buzz era mais eficiente.

Ainda acerca do Plus, temos o fato de sua leitura misturar tudo quanto é tipo de notificação dos seus amigos (fotos, pensamentos e piadinhas da firma) com conteúdo relevante. O que era uma das vantagens do Reader anteriormente era a sua capacidade de focar o usuário em conteúdo relevante e diferenciado.

Por fim, a interface e usabilidade ainda precisa de melhoras. O problema de se compartilhar em dois passos (ao invés de um) foi resolvido a posteriori mas ainda temos outros detalhes como o mal aproveitamento do espaço (falta a o modo compacto como existe no docs e no gmail) bem como a caixa de pesquisa dos rótulos.

Baby Steps

Engraçado que o lançamento do Plus foi comparado ao falecido Wave. A Google tenta com força ganhar terreno nas redes sociais mas se mostra sempre um passo atrás dos gigantes já estabelecidos e até novas startups. Na minha opinião isso é devido as estratégias BigBang seguidas pela empresa em seus produtos. Parece que se esqueceram de como é começar com pouco (mas diferencial) e ir escalando a crescendo aos poucos. Um bom exemplo disso é o Google Buzz, ferramenta simples integrada ao Gmail que te agrega apenas o fato de organizar os comentários de seus amigos sobre seus conteúdos (Reader e Twitter por exemplo), a ferramenta teve ótima aceitação. Pena que por concorrer com o Plus, será engolida.

Para mim o Reader foi mais um exemplo de estratégia BigBang mal sucedida. Fazendo um passo de cada vez poderia se ter alcançado melhores resultados. Por exemplo, apenas uma melhoria na interface ou a troca do "like" pelo "+1" já traria evoluções a ferramenta e permitiria analisar a reação das pessoas com as mudanças.

Por fim cabe a nós esperar e ver como será a evolução do Reader pois ou ele ficará capenga como está ou muitos passos pra trás (como no caso do share) serão dados até se corrigir o rumo.

Workchopp II - Qualidade de Código

2011-11-03T11:00:00.000-02:00

É isso aí, não satisfeitos de combinar Empresa, Sabado e Cerveja uma vez, decidimos repetir a dose.
Tudo bem que o workchopp foi dia 15/10 e estou atrasado, mas a experiência vale ainda.

Nesse segundo workchopp queríamos juntar a galera de desenvolvimento em prol da qualidade do nosso trabalho. Foram escolhidas então atividades que pudessem trabalhar a nossa visão em cima daquilo que fazemos.

Atividade 1:

A primeira atividade foi o gildedrose em Java. Dividimos os participantes em duplas e fizemos três rodadas da seguinte maneira:

Primeira Rodada

Cada dupla teve 5 minutos para ler e estudar o código. Depois cada dupla teve 10 minutos para trabalhar na melhoria da qualidade do código. Ao final nos reunimos e fizemos uma retrô rápida de 10 minutos. Todos acharam 10 minutos muito pouco e nada foi alcançado em cima dos códigos.

Segunda Rodada

Pilotos viraram copilotos de outras equipes. Novamente tivemos 5 minutos para discutir, seguidos de 10 minutos de codificação. Ao final, outra retrô de 10 minutos. Desta vez o pessoal botou a mão no código, investindo mais em "extract methods". Uma passada numa bateria de testes mostrou que muitos inseriram erros no código e as melhorias da qualidade (usando PMD) não foram significativas..

Terceira Rodada

Trocam os pilotos novamente. Novamente 5 minutos de preparo seguidos de 10 minutos de codificação. Desta vez, as duplas receberam a bateria de testes completa, antes da rodada. Ao final 10 minutos de retrô. Apesar de singelos os comentários, foi notório ao rodar a bateria que a qualidade do que foi modificado aumentou.

Atividade 2:

Nossa segunda atividade foi um Dojo/Handori. Começamos a codificar uma Calculadora de fórmulas em Strings. Foi um pouco corrido (só tinhamos 40 minutos) mas foi possível mostrar um pouco da prática do Dojo e deixar todos codificarem.

Conclusão

Foi um sábado muito bem aproveitado. Foi muito corrido e faltou tempo pra explorar um pouco mais ambas as atividades. Porém, na restrospectiva foi possível notar que o pessoal estava bem engajado nas discussões de evoluir a qualidade dos trabalhos.

Que venham outros workchopps.

Outras ferramentas para produtividade

2011-09-19T10:30:00.000-03:00

Já falei anteriormente sobre o que considero como Práticas Efetivas.
Já re-visitei o assunto tanto no que toca como essas práticas se complementam com meu uso das ferramentas do Google bem como das Redes Sociais. Hoje quero focar um pouco no uso de outras ferramentas que estão bem ligadas a essas práticas mas que não se encaixam nessas outras categorias.

Notas/Arquivo - Evernote

Ter sempre a mão um lugar para fazer anotações é algo muito importante. O Evernote possui versões tanto para mobile (iOS, Android) como para os demais SOs (Windows, Mac e Linux-wine). Porém o que eu mais uso é a sua versão mobile e web, que me atendem super bem. Sua versatilidade em armazenar tanto notas de texto como fotos são os recursos que mais uso. Porém ele possui muitas outras capacidades, como o armazenamento de audio, além da recente integração com o Skitch.

Além disto ele serve como arquivo de todas as anotações para consultas futuras. Para isso, organizar seus cadernos e observações de notas ajuda bastante.

Arquivo - Gmail + GDocs

A beleza de se ter tanto espaço de email é que você não precisa deletar nada. Sendo assim, eu sempre tenho meu arquivo de informações sempre a mão. Procuro sempre guardar e compartilhar arquivos usando o Google Docs e o Gmail. Não tenho o hábito de deletar nada destes lugares de maneira que possa consultar posteriormente. É de grande satisfação saber que mesmo hoje eu consigo encontrar documentos de anos atrás com facilidade. Claro que a organização correta dos rótulos auxilia bastante, bem como conhecer o uso das consultas do gmail/docs.

Pomodoro

Já falei anteriormente que o uso da técnica do tomate é um dos fatores que melhoram bastante a minha concentração. Para seguir esta técnica a minha ferramenta favorita é o FocusBooster, uma aplicação simples em AdobeAir (roda em qualquer SO) que é bem compatível com o meu uso da técnica. O que eu considero essencial para usá-la é o fato de ter o cronômetro bem visível e não invasivo, a indicação de cor dos minutos finais e um sinal sonoro bem audível. Isso é tudo que necessito de um pomodoro. Apesar de ser bem focado em usar o FocusBooster deixo a indicação de três outras ferramentas que conheço e que podem servir a quem busca ferramentas mais rebuscadas ou diferenciadas.

Tomatoist: Ferramenta web (com extensão para o Chrome). Ideal para quem quer ter seu histórico sempre armazenado.
Pomodairo: Ferramenta também feita em AdobeAir (e de código aberto). É bastante completa com suporte a muitas configurações. Seu destaque está no controle da lista de tarefas com contagem de tomates executados, planejados e interrupções.
Tomighty: Muito similar ao Pomodairo, porém desenvolvido em Java e com algumas opções distintas de configuração.

Para quem gosta de algo mais móvel existem diversas aplicações mobile. Mas neste caso eu ainda prefiro o meu tomate clássico.

Controle de Tempo - RescueTime

O RescueTime é uma ferramenta muito interessante para te ajudar a encontrar Buracos Negros na sua rotina. Não uso ele a bastante tempo pois sua versão para Linux não é estável, porém as versões para MacOS e Windows são bastante satisfatórias. É bastante simples de configurá-lo, ao final da primeira semana já estará 95% configurado de acordo com o seu uso e rotina. Através de seus relatórios será simples encontrar aqueles sites e aplicações que andam te tirando a atenção e te ajudar a melhorar sua produtividade.

GTDwG - Getting Things Done with Google

2011-09-12T10:30:00.000-03:00

Eu queria falar um pouco sobre alguns aplicativos que eu uso pra me ajudar a seguir as minhas práticas. Porém achei melhor quebrar um pouco e começar leve falando sobre o GTD. Como detentor de uma Google Account, nada melhor do que tirar proveito do que a plataforma me oferece então vou tentar explicar um pouco de como uso três ferramentas da gigante para manter minhas tarefas em dia.

Caixa de Entrada - Gmail

Eu recebo toneladas de emails todos os dias (a média fica em torno de 100). Claro que eu não preciso ler todos, mas muitos possuem algo relacionado a coisas que tenho que fazer ou informações interessantes. Por isso eu sigo uma rotina bem simples para organizar meus emails:

Uso bem os filtros e rótulos de mensagens. Eles me dizem o que é mais importante de cara. Afinal, o rótulo da galera da faculdade não precisa ser checado com tanta presteza quanto o do projeto em que você está trabalhando. Além disso, a coloração dos rótulos ajuda a ver a gravidade de cada assunto.
Se não eu não quero ler, marco como lido ou mando pra lixeira. Simples e ponto. Normalmente marco apenas como lido, se algum dia retornar continuará armazenado.
Se já sei o que fazer, ou faço ou coloco nas tarefas (Veremos mais a frente).
Se é importante dedicar mais tempo a ele, para então definir o que fazer, deixo como não lido. O que marca que ele não foi tratado propriamente.

Eu procuro seguir uma política de Zero mensagens não lidas. Isso é bem importante caso você queira evitar a falência do seu email, mas mais importante ainda para seguir estes passos. Afinal, aquele número entre parênteses e o rótulo em negrito me incomodam. Considero isso muito importante para que este processo dê certo, cada item não lido é algo "solto" no ar.

Listas - Google Tasks

Existem inúmera alternativas ao GTasks, porém o fato dele vir integrado ao Gmail é insuperável. Deixando ele sempre aberto, toda vez em que você visitar a sua caixa de entrada você estará em contato direto com o que tem que fazer. Assim, utilizo esta ferramenta de acordo com as seguintes práticas:

Mantenho a lista sempre priorizada (mais prioritários primeiro), para poder sempre ver.
Se a tarefa está relacionada a um email, deixo o relacionamento explícito usando o comando "Add to tasks"
Coloco nomes claros e uso as descrições somente quando necessário (normalmente quando não tem email relacionado). Isso é importante para evitar de ter que "re-processar" o assunto quando for executá-lo.
Se concluir uma tarefa, apenas a marco. Evitar de ter uma tarefa muito grande e deixar de marcar meu avanço nela.
Todo início de dia, limpo as tarefas concluídas no dia anterior.
Reviso a lista com frequência. Ao menos uma vez na semana.

Eu possuo uma lista pessoal e uma profissional, para evitar confusões. Mas ter o menor número possível de listas é um bom hábito.

Agenda - Google Calendar

A agenda no GTD não é igual sua agenda de compromissos. Sua real função é controlar tarefas que possuem uma data para ocorrer (e não um deadline). Por isso sigo dois passos claros aqui:

Tarefas com data para ocorrer são marcadas com tal (Usando o campo de data do próprio GTask).
Emails ou assuntos que não podem ser tratados vão para o Calendário e um aviso é agendado para cair no email (e será então tratado).

Nunca coloque deadlines como datas na sua agenda, senão você não terá tempo de alcançar seu objetivo. No lugar disso, divida bem as tarefas para alcançar sua meta. Outra coisa é usar bem as configurações das notificações do GCalendar. Normalmente coloco o aviso por email com a antecedência que desejo re-processar o assunto, assim ele voltará a minha caixa de entrada quando necessário.

Suporte Mobile

Por fim, a beleza de se ter um smartphone (e no meu caso um Android) é que se tem acesso a tudo isso onde você estiver. Não importa onde estou, adicionar uma tarefa, compromisso ou anotação é simples e indolor. Isso é muito importante pois elimina a preguiça existente para se executar qualquer uma destas atividades, além de ser extremamente prático.

Lembro que toda prática de organização pessoal deve ser lida com muita crítica. Se você gostou de alguma, experimente e adapte para você de maneira que lhe agrade e funcione.

Só não aprende quem não quer

2011-08-30T10:30:00.001-03:00

Pelo visto as minhas idas ao dojobrasilia tem se mostrado bem rentáveis. Parece não existir um dojo do qual não consigamos extrair um aprendizado maneira. E o último se destacou bastante.

A ideia do último dojo era ser uma sessão introdutória sobre como funciona o dojo para algumas pessoas que queriam iniciar seus próprios grupos em outros lugares. Levamos um bolo dessa galera, mas outros bravos guerreiros estiveram presentes. Dentre estes tínhamos duas novatas na área de programação e decidimos usar o dojo para ajudá-las nos primeiros passos dessa caminhada.

Após a sessão uma das novatas veio agradecer pela nossa paciência em explicar e pelo aprendizado. Eu tratei de corrigi-la e esclarecer que o aprendizado foi mútuo. É engraçado de se pensar que em uma sessão onde tínhamos 4 desenvolvedores experientes fazendo um problema simples (e velho conhecido) ainda exista espaço para se extrair aprendizado. É muito fácil ver onde os novatos puderam crescer (TDD, codificação, sintaxe), mas aonde os mais experientes podem ter extraído proveito?

É daí que digo que "só não aprende aquele que não quer". Esta sessão foi muito rica em diversos pontos vou ressaltar os dois mais proeminentes.

O primeiro é um velho conhecido dos dojistas. Mesmo resolvendo um problemas simples e conhecido chegamos a uma solução diferente e elegante. E mais que isso, o caminho que fizemos para chegar até ela foi muito interessante. Isso porque discutimos bastante sobre refatoração de teste no nível semântico, o que foi muito proveitoso.

Mas o ponto mais importante desta sessão foi aprender junto ao Mestre Protzek a paciência e as técnicas para se educar os novatos. Trabalhar bem os conceitos, não só explicando-os, mas repetindo o exercício do aprendizado para melhor fixação. Além disso, também a arte de ouvir os novatos, ouvir em suas ações e ver quando temos um ponto falho na aprendizagem para ser corrigido.

Por fim, creio que cresci muito com todos estes aprendizados. E além de compartilhá-los aqui, queria destacar também a coragem que as novatas mostraram em sentar na cadeira de piloto e codificar junto com todos nós.

WorkChopp Intacto

2011-08-16T08:28:00.009-03:00

Olá pessoal! Sou o @andersonfer_ e tô invadindo o blog do Fabricio pra contar sobre um evento muito legal que organizamos na @IntactoSoftware. Como eu ainda não tenho blog (shame on me), pedi permissão pra falar por aqui! Espero que gostem!

Depois do #agileBR, todos nós voltamos naquela vontade de distribuir o conhecimento adquirido lá entre toda galera. Então tivemos a ideia de organizar um workshop baseado em uma dinâmica que eu assisti, apresentada pelo Emilio Gutter e pela Alejandra Alfonso. Eu sempre fui muito favorável às dinâmicas, jogos e afins pq acho que têm um poder muito grande de quebrar as resistências das pessoas e fazê-las enxergar os benefícios das metodologias e técnicas ágeis para além dos contextos e projetos em que estão inseridas e consequentemente tentar aplicar esses conceitos no seu dia-a-dia.

Optamos por relizar a dinâmica Construindo A Cidade Ágil. Os 2 grupos tinham à disposição papeis coloridos, tesoura e cola pra construir, em 4 sprints de 3 minutos, as user stories que desejassem, a partir de um backlog fornecido. Ao final de cada sprint, para cada user story aceita pelo cliente (eu), os times ganhavam a pontuação (valor de negócio) indicada na story.

Além disso, ao final os times começavam com papéis fixos no time (cortador de triângulo, circulo, retâgulo e colador), que poderiam mudar ou acumular de acordo com a estratégia do time pra próxima sprint, que era decidida numa mini-retrospectiva entre as sprints. A cereja do bolo ficou por conta das mudanças que foram introduzidas nas user stories antes das sprints!

A galera utilizou muitos dos conceitos do SCRUM sem perceber, e foi essa deixa que o @rcoutin utilizou pra apresentar a parte teórica. Esse ponto do WorkChopp foi bem legal, pq eu achava que ia ser mais uma palestra e acabou sendo um debate. As pessoas apresentaram suas visões do SCRUM, o status da implantação nos projetos que fazem parte, bem como os pontos positivos e negativos das experiências que estão sendo feitas em cada um desses projetos e sugestões do que fazer em projetos onde a situação é mais crítica. O compartilhamento de ideias esteve presente todo o tempo e foi muito legal saber que as pessoas se importam com a situação geral da empresa e não estão presas cada uma no seu quadrado.

No final, fomos para o bar celebrar uma tarde de sábado muito produtiva (vou ficar devendo fotos desse momento)! Que venham os próximos!

TDD como ferramenta de aprtendizado

2011-08-08T10:30:00.000-03:00

Na penúltima sessão do DojoBrasilia surgiu a seguinte questão:

Será que o TDD não atrapalha no aprendizado de novas tecnologias?

A grande questão girava em torno de que o respeito estrito as regras ao TDD tornariam o aprendizado lento e enviesado. Isso por que você estaria focado em passar o teste o que estaria limitando sua velocidade no aprendizado na tecnologia, bem como a visão do objetivo final.

Caso do dojoBrasília

No caso da sessão que levantou a questão acho que o principal sentimento de "lentidão" se deve a grande carga de tecnologias novas que estavam envolvidas. Escolhemos iniciar um problema conhecido em não uma, mas várias tecnologias (Backbone.js, Undescore, CoffeeScript, Jasmine, etc). Ao final da sessão a sensação de pouco avanço era justificada pelo tempo gasto compreendendo as tecnologias em questão.

A sessão seguinte não obteve o avanço que muitos esperavam. Mas nela podemos ver como o uso de TDD compensou. Tínhamos apenas 4 casos de teste e não estávamos conseguindo utilizar alguns recursos do Backbone.js que nos pareciam bastante interessantes. Iniciamos então uma série de refactorings testando várias teorias em cima das tecnologias até que no final nosso código estava utilizando os recursos dos frameworks e estava bem mais agradável. Rodamos então nossos testes e todos ficaram felizes com o resultado. Evoluímos e ainda tínhamos a segurança de que nosso código estava funcionando.

Conclusões

O que eu tiro disto é que, apesar de parecer mais lento, o uso de TDD lhe ajuda a ter uma aprendizado mais firme da tecnologia estudada. No exemplo que vimos é claro que o uso de TDD facilitou testarmos hipóteses sobre os frameworks sem perder o que já tínhamos e com a garantia de que estas hipóteses realmente funcionavam. Outro ponto que achei bastante interessante foi que usando TDD fomos obrigados a conhecer mais da interface de cada uma das ferramentas, para que pudêssemos testá-las, isso aprofundou nosso conhecimento.

Um outro ponto interessante é que algumas pessoas podem ter um pouco de pressa em ver o resultado do que estão fazendo. Neste caso acho interessante a abordagem que o James Shore seguiu neste caso. Ele queria testar um novo gerenciador de layout no seu projeto, então ele construiu um outro projeto onde ele testou o novo framework até ter algo que lhe agradasse. Após isso ele foi transferindo o que ele tinha deste "protótipo" (hipóteses) pro seu código através de testes. É muito interessante observar que muitas das hipóteses dele não estavam corretas (assim como as nossas), porém o exercício lhe ajudou a corrigi-las.

Por fim, acredito que o TDD pode sim ser uma boa ferramenta de aprendizado de tecnologias. E convido vocês a experimentar. Eu a usei no meu kata de Scala e, apesar de ser um exemplo bem simples, foi muito proveitoso.

Tirando proveito das redes sociais

2011-07-11T10:00:00.000-03:00

Neste post estou postando minha opiniões e experiências pessoais sem referência a pesquisas e conclusões mais robustas ou de maior reputação.

Muitos amigos tem brincado comigo devido a minha participação em diversas redes sociais. É engraçado observar tais comentários pois eu sempre fui um "later adopter". Ainda mais que isso, sempre fui um cara taxado de "anti-rede-social" tendo em vista minha não adoção serviços como orkut ou facebook.

A verdade é que cada vez mais existe uma socialização das ferramentas na web. De acordo com uma minha amiga, isso faz parte da gameficação das nossa sociedade. Não sei se isso é um fato, mas é real a tendência daqueles que querem criar uma rede social ou tirar proveito das existentes. Não diferente destes, minha participação das redes é bem focada e busco usar cada uma a meu proveito. Afinal, a vantagem destas ferramentas está em compreender aonde está o ponto de equilíbrio. Na minha visão, cada uma destes serviços lhe oferece algumas vantagens em troca de ter um "pouquinho" das suas informações na sua base. Sendo assim a intenção deste post é falar um pouco de como eu utilizo estas ferramentas a meu favor indo além da simples exposição pública.

Google Reader

O Google Reader é hoje a rede social da qual eu tiro mais valor. Para quem não conhece, o gReader é um leitor web de RSS. Isso em si já é uma grande ferramenta, lhe permitindo organizar sua leitura de maneira simples e centralizada. Seu fator social aparece com a capacidade de compartilhar posts que você julga interessante. Essa capacidade amplia a sua abrangência de leitura de maneira muito benéfica, já que você receberá de seus amigos sugestões muito bem filtradas. Afinal, ninguém vai compartilhar algo que não considera interessante.

Eu acredito que o pessoal do Google ainda tira pouco proveito desta rede que pode ser melhorada. Suas informações podem gerar resultados melhores tanto para os leitores quanto para os escritores. Mas de toda forma a "consciência coletiva" age com uma ótima fonte de sugestões de leitura.

Twitter

Eu fui muito resistente ao twitter de início. A idéia de microbloging não me atraiu (como não continua atraindo muita gente), mas acabei compelido a tentar devido a más influências. De início minha resistência se baseava na baixa densidade do conteúdo compartilhado. Para tirar proveito do que é disponibilizado na sua timeline tive que superar/ignorar as guerras de vaidades e os twits vagos.

Superados estes obstáculos consegui tirar proveito da ferramenta ao notar que pessoas que eu curtia o blog compartilhavam bons conhecimentos dentro dos 140 caracteres. Nestes casos eram discussões ou informaçõe interessantes que não justificavam o trabalho de se escrever um post mais elaborado. Este hoje ainda é o maior benefício da rede.

O segundo ponto que eu acho bastante interessante é a capacidade de acompanhar a repercussão e comentários sobre determinados assuntos de maneira facilitada. O uso de hashtags permite a criação e acompanhamento de maneira simples sobre qualquer assunto na ferramenta.

Google Buzz

Nesse bolo o Buzz é o patinho feio. Tendo sido criado para concorrer com o twitter, claramente ele não conseguiu a fama que desejava. Hoje o Buzz é um auxílio em apenas duas frentes que precisam ser muito melhor exploradas. O fato de se integrar com o twitter permite que o processo de discussão se dê de forma mais simplificada. Acho muito mais organizado acompanhar as discussões de um twit pelo buzz, no formato de thread, que na bagunça de replies que o twitter sugere. Por fim, apesar dos vacilos iniciais, o Buzz oferece uma solução mais restrita (menos pública) que o twitter, fora a possibilidade de direcionar o seu público através dos grupos.

Endomondo

O endomondo é uma rede social de praticantes de esportes. O fator da pressão social é algo bastante interessante, mas este não é o fator chave. Tendo suporte a um infinidade de plataformas ele permite através do seu celular você manter o controle centralizado das informações de seus exercícios. Hoje ele permite o registro de quase 50 tipos diferentes de esportes. Ao final todas as informações são concentradas na interface web onde você pode ter um controle mais elaborado das suas atividades e metas.

iCheckMovies

O iCheckMovies é iniciou-se como uma rede para cinéfilos porém, desde a sua integração com o imdb, tem atendido a todo tipo de mídia em vídeo. A ferramenta ainda tem muito que evoluir, principalmente em usabilidade. Seu principal trunfo é não só manter o controle daquilo que você já assistiu mas também de ajudar a descobrir novos itens para assistir. Uma funcionalidade que uso bastante é a de manter uma lista de filmes para assistir (como parte do meu GTD).

Skoob

O Skoob é a única destas redes que tem origem brasileira. Hoje ela não permite um bom controle da reputação de seus títulos e não possui nada para recomendação. Porém ela possui um fácil sistema de inserção de novos títulos bem como uma comunidade ativa no seu controle. Hoje a uso por ser um bom lugar para controlar as minhas leituras. Ele age como um complemento ao meu GTD, permitindo que eu veja a minha fila de leitura, livros desejados e o acompanhamento do que já li.

A experiência de software

2011-04-21T09:34:00.000-03:00

Hoje em dia está muito em voga se falar sobre o desenvolvimento de produtos e serviços de software. Sendo assim as iniciativas e startups estão alta. Mas para quem está no mercado de Brasília (e de alguns outros centros do país) como eu, sabe que a prestação de serviços nas famigeradas "Software Houses" (~~me recuso a chamar de Fábricas de Software~~) é bem comum. Porém, este trabalho costuma ser renegado ou, como eu vejo, tratado sob um ponto de vista um pouco equivocado.

Uma fábrica de software artesanal

Onde se enganam tais pessoas é em que elas estão vendendo. Muitas empresas acreditam, de fato, que vendem software. Eu porém digo que isso é não de todo verdade. Se você é um prestador de serviços e constrói software sob demanda, você não vende apenas o software. Aqui não me refiro aos milhões de outros "artefatos" que são ~~empurrados goela abaixo~~ entregues aos nossos clientes. O que vejo é que vendemos algo que não está limitado ao software que vai pra mão (ou seriam servidores?) do usuário. Nós prestamos toda uma experiência ao usuário com relação a como se construir o software.

Usuários se importam com mais que só o resultado final

Seja o seu projeto de 1 mês ou 1 ano. Seja seu processo cascata, RUP ou agile. Seja sua empresa certificada CMMI, MPS.BR ou ISO. Não importa onde você acha que você se encaixe neste mundo louco de desenvolver software para humanos, tenha a certeza que estes humanos participarão do processo. É justamente esta viagem que nos leva a mostrar alguma coisa no monitor que vendemos para estes caras. Assim, esta experiência é um dos pontos mais importantes de sucesso de um projeto. Compreender e ensinar nossos clientes a viver isto é uma tarefa para nós desenvolvedores.

Não fuja das suas responsabilidades

Nós, profissionais de TI, somos mestres em fugir desta responsabilidade. Desenvolvedores evitam falar com o cliente como vampiros da luz do sol. Gerentes blindam o desenvolvimento com atas, acordos e toda a papelada possível. Mas a grande questão é que nos esquecemos que é nosso papel ensinar e compreender como nosso usuário deve experimentar essa caminhada rumo a solução desejada. Independente do cliente ou da equipe envolvida, existe uma interação que deve ocorrer entre as partes. O que eu vejo nestes artifícios criados são muletas de como fugir da responsabilidade que possuímos de cobrar e educar nossos usuários em como se desenvolver o software.

O trabalho entres as partes deve ser conjunto

Não tem como nos desvencilharmos desta questão. Cada uma das partes guarda um pedaço da solução a que todos desejam chegar. Clientes e usuários possuem o conhecimento do que eles necessitam. Por mais que nós desenvolvedores queiramos acreditar do contrário. Desenvolvedores detém a solução que vai atender aquela necessidade. Portanto, se o usuário não está disponível para o desenvolvedor discutir aquela tela linda que ele bolou, não vai ser um belo documento assinado que vai garantir que ela estará certa. Cabe a nós mostrarmos ao usuário que é dele esta responsabilidade. Vale também nós aceitarmos que é parte do cliente nos exigir e demandar qualidade e apreço no que fazemos.

Profissionais de TI e clientes de TI existem aos montes, uns mais duros e moles que os outros. Minha crença é que estas partes tem que se entender em busca de uma convivência. E para que esta convivência exista eles tem que interagir e conversar. Ambas as partes estão interessadas na mesma coisa, software funcionando. E cada parte só saberá o que a outra busca se elas interagirem. Porém, coloco aqui que a responsabilidade maior de buscar tal diálogo reside em nós, desenvolvedores, afinal software é a nossa praia.

Créditos das Imagens

Você tem o direito de errar

2011-02-26T14:23:00.000-03:00

É incrível como somos treinados desde cedo a observar nossos erros como algo extremamente ruim. O mundo a nossa volta nos incita a nos envergonharmos desles. Na escola, aprendemos a nos distanciar dos colegas repetentes e de média baixa. O garoto que não conseguem jogar futebol acaba por abandonar a educação física. Com o tempo, descobrimos que o melhor a fazê-los é esconder, fingir que não estão lá ou até mentir.
Infelizmente, tais caminhos nos tiram das possibilidades que nosso erros nos proporcionam. Afinal, se errar é humano, negar tais erros deve nos privar de um experiência humana mais rica.

A criatividade em prol de nosso ego.

É no mundo corporativo que a nossa aversão a errar fica mais clara. É comum em entrevistas de emprego, ou em discussões de trabalho, não se encontrar referências aos erros do proponente. Por outro lado, os erros dos demais são sempre mais claros e expostos. Na minha crença pessoal, vejo que nós nos defendemos de nossos erros com medo que eles nos exponham como pessoas frágeis. E é isso que nos leva a discussões cíclicas e centradas no ataque ou até mesmo na omissão perante assuntos importantes.

As vezes não funciona.

Mas esconder nossas falhas não resolve nada. Muito pelo contrário, adiamos a inevitável explosão das conseqüências. Mas não tem problema, afinal, podemos esconder nossos erros de nós mesmos, ou até mesmo projetá-los nos outros. Quem sabe isso possa limpar nossas consciências?

As vezes escolhemos assistir o mesmo filme novamente.

Porém isto não vai evitar de cairmos nos mesmos problemas outra vez. E este ciclo se repete, com novo figurino, cenários e atores. Mas ainda vale a esperança de que o final será diferente?

Na minha opinião a grande questão está em como enxergamos nossos erros. Se insistirmos em vê-los como falhas em nós mesmos, continuaremos a escondê-los ou repassá-los a outras pessoas. Mas a visão mais inteligente nesta questão seria buscar o aprendizado que eles nos trazem.

É preciso errar bastante pra aprender certas coisas.

O melhor exemplo que eu tenho está em como aprendemos a trabalhar na vida corporativa. Na Intacto, eu sou um dos responsáveis pelo treinamento dos novatos. Por muito tempo eu tratei a acolhida destes com um período pesado onde eu tentava adiantar a eles os aprendizados que eu já havia obtido, tentando livrá-los de vivenciar algumas pedras do caminho. Porém (assim como disse o UncleBob), impedi-los que cometer tais erros na verdade apenas os impedia de aprender aquelas lições.

Ao mudar minha estratégia, para permitir que as pessoas cometessem tais erros eu obtive resultados incríveis. Em primeiro lugar, errando e entendendo os fatores envolvidos na prática traz uma compreensão mais intrínseca do que aconteceu, o que leva a um aprendizado mais duradouro. E o melhor de tudo, se permitir ao erro te leva a compreender toda uma gama de experimentação que fazem parte do dia a dia (já dito por Seth Godim).

Temos um grande horizonte a frente.

É se permitindo errar e aprender destes erros que chegamos a novas possibilidade de sucesso. Se erramos e nos negamos a aceitação e lições destas falhas é impossível de superamos estas e prosseguir em busca de novos rumos. Por isso, experimente errar e tente achar nos seus erros aquilo em que você pode melhorar. Superando este problema, você estará um degrau acima o que lhe possibilitará ver novas paisagens.

Do alto vemos longe.

Minha experiência no Dojo Brasília

2010-12-23T17:30:00.001-02:00

Como programador este ano foi muito divertido pra mim. Afinal, foi em janeiro que eu comecei a frequentar o Dojo Brasília. Uma experiência muito rica pra mim que decidi compartilhar um pouco aqui.

O convite inicial me foi feito pelo Ian na primeira semana do ano. Eu não topei de início pois não sacava muito a idéia por trás do coding dojo. Por fim, acabei indo na minha primeira sessão no final de janeiro na qual participei da codificação do Campo Minado. A experiência foi tão boa que acabei viciando. Cheguei, inclusive, a evangelizar um pouco da idéia junto ao Rolim durante a semana de extensão da UnB. Agora o ano se finaliza e chega a hora de fazer uma super retrospectiva de como foi essa experiência.

A primeira coisa que me agregou no Dojo foi a experiência de codificar em equipe. Certamente esta é uma oportunidade sem igual. Colocar suas idéias junto as dos demais, isto em um contexto onde todas são analisadas sem filtros, gera uma oportunidade de crescimento incrível. Ao longo das sessões vi que muitos conceitos e hábitos meus estavam muito errados, outros ainda eram válidos e o melhor de tudo, vi muita coisa que desconhecia. Trocar idéia com pessoas experientes como o Pedroso como gente que estava engatinhando no desenvolvimento foi algo bastante valioso.

Com a experiência a gente acaba se expondo pouco a essas trocas de informações com outras pessoas. Passamos a acreditar que o desenvolvimento ao estilo "lobo solitário" é mais "rápido" e parece atender melhor as nossas necessidades. E assim perdemos a oportunidade de nos expormos a esse processo de cruzamento e evolução de idéias.

Eu sempre gostei de ler sobre outras tecnologias e linguagens. Infelizmente não me dei muitas oportunidades de experimentá-las. Durante os dojos pude ter contato com tudo isso além de ter o direito de botar a mão na massa. Codificamos em JavaScript, Perl, C, Java, Ruby e Phyton. Fizemos desde problemas matemáticos a jogos. Brincamos bastante. E essa mistura de tecnologias e projetos pode parecer bizarra a alguns, mas é justamente isto que gera uma oportunidade única. Estando exposto a um novo ambiente, com novos paradigmas, recursos e problemas você fica mais atento aos detalhes e as possibilidades a sua frente. Quando você retorna ao seu código habitual você começa a notar diversas questões que não via antes. É graças a estas situações inusitadas que você se permite vislumbrar novos caminhos. Depois deste ano, meu ferramental como desenvolvedor deu uma bela incrementada.

E um dos principais pontos que foram aprendidos no Dojo foi o TDD. É incrível como esta técnica é unânime entre todos os dojos que você procurar. Mais incrível ainda foi que, apesar de conhecer a técnica de nome a alguns anos, sempre a achei distante da minha realidade. Foi então neste ano que vi o quanto ela é aplicável na maior parte dos contextos em que desenvolvo. Depois de vencida a barreira inicial, e de trazer a mesma para o dia-a-dia, é difícil tirar a técnica do sangue. Hoje já aplico ela a todos os projetos onde tenho que desenvolver (inclusive os legados) e tenho até dificuldade em não usá-la. Codificar com TDD te traz uma segurança enorme que é sentida a cada vez que você roda seus testes e sabe que seu software está garantido.

A cada sessão de dojo estávamos livres para tentar o código que desejássemos. Não tínhamos restrição de tempo ou escopo. Nosso objetivo era chegar no código que mais nos satisfizesse. Chegamos a gastar sessões inteiras apenas refatorando nossos códigos. Assegurados por nossos testes estávamos livres para testar diversas possibilidades e idéias. O importante não era apenas ter um código que rode, mas um código que agrade e agregue.

Tenho certeza que tem muitas outras lições aprendidas durante este meu primeiro ano de Dojo Brasília. Fico no aguarde do ano de 2011 que com certeza trará muitos novos aprendizados. Caso você seja de Brasília, deixo o convite a participar dos nossos encontros. Para isso basta entrar no nosso grupo de e-mail e se apresentar. Caso não seja daqui, procure algum dojo na sua cidade ou crie coragem e inicie o seu.

Imagens retiradas de:

Práticas Efetivas

2010-10-09T09:24:00.004-03:00

Um dos blogs que eu mais curto acompanhar é o efetividade.net. Neste último mês está rolando por lá uma série de artigos [1][2][3] sobre ferramentas de produtividade pessoal. Nesta série de artigos o Augusto Campos tem chamado bastante a participação do público e eu estive enrolando pra contribuir com a discussão. Porém eu acho que as ferramentas são muito vazias sem conversar antes sobre as práticas e técnicas que as suportam.

Vale lembrar que o que vou falar funciona para mim. Deixo esta observação pois acredito que cada um deve buscar as práticas e ferramentas que melhor lhe atendam usando e abusando de adaptações e trocas ao longo de suas vidas e experimentos.

Porque?

A primeira questão importante é o porque de precisarmos ser efetivos no nosso dia-a-dia. Se você não sente a necessidade, talvez nem precise seguir esta discussão. Mas se sente, sabe que a resposta é bem fácil de se encontrar.

Felicidade é chave.

Eu acredito fortemente que quando você não é efetivo no seu dia-a-dia você não alcança um grau satisfatório de felicidade¹. Isso é dito pelo próprio GTD. Você realiza a todo o tempo compromissos pessoais com você mesmo. Isso acontece em todo grau de coisas, das pequenas as grandes. Conforme estes compromissos não são satisfeitos sua confiança em si mesmo diminui e a começa a surgir a sensação de descontrole sobre as coisas que ocorrem ao seu redor. Não digo que você precisa controlar tudo que acontece contigo, mas que devemos ocupar a posição de condutores de nossas próprias vidas, e não apenas sentar e deixar acontecer.

Portanto, saber ser efetivo é a chave para voltar a confiar em si mesmo, em suas decisões e ações. Não quer dizer que devamos ter todo o plano detalhado da sua vida definido para os próximos 5 anos. Mas temos que ter confiança que podemos assumir compromissos consigo sem aquela sensação de que o vôo de uma borboleta pode nos tirar de curso.

Aceitar os seus limites

De início devemos que aceitar que somos limitados. Não que limites sejam ruins, pois limites representam desafios a serem superados. Estes limites se encontram em diversos níveis: limites fisiológicos, mentais, temporais, transporte dentre muitos outros. Muitas pessoas se recusam a aceitar isso e outros gostam de sonhar em modificá-los (quem nunca pediu por um dia de 36 horas?). Muitos destes limites podem ser minimizados ou alterados, mas muitos outros nos devemos aceitar e aprender a conviver com eles.

É importante respeitar nossos limites.

O primeiro grande vilão que devemos aceitar são os temporais. Uma semana tem 7 dias e um dia tem 24 horas e isso não vai mudar na Terra por um bom tempo. Aceite também que você tem outras necessidades. Dormir, comer, ir ao banheiro, se exercitar, namorar e se divertir não são luxos, são algo que toda pessoa precisa constantemente. Então, aceite que você está dentro de uma time-box e que você terá que trabalhar com esta restrição.

Aceitando seus limites começa por algo que eu faço com bastante rigor e flexibilidade (?). É como eu divido meu tempo. Dividir o tempo é uma parte importante do planejamento. Mas é importante também saber que você deve não só respeitar o seu planejamento como saber quando ele pode ser flexibilizado. Neste ponto bom senso é algo de extrema importância e neste bom senso vive o respeito aos seus limites. É desta prática que eu tiro algumas regras básicas como:

Dormir de 7 a 8 horas por dia. Sono é importantíssimo para quem quer ter a mente em ordem. Eu sei que cada pessoa tem seu metabolismo, mas experimente dormir 8 horas por uma semana e veja os resultados.
Não planejar mais que 30 horas da minha semana. Guardar 25% da sua semana não é gordura, é aceitar que pelo menos 25% da sua semana não pode ser prevista. Dependendo das atividades que você desempenha eu diria que você não devia nem prever mais que dois dias. Mas planejar gastar todas as suas 40h é fato que vai te levar a gastar mais tempo ou não chegar onde você gostaria.
Respeitar suas necessidades biológicas. Comer, se exercitar e tirar um descanso são importante não só pro corpo como para a mente.
Sou chato com meus compromissos e tenho muita facilidade em manter uma rotina, mas é importante saber quando uma regra deve ser quebrada.

Leitura em 15 minutos

Com a minha graduação, trabalho e mestrado eu acabei deixando de ler por um bom tempo. Tinham vários livros que eu desejava ler, mas a desculpa de não ter tempo deixava-os nas prateleiras de casa. Certo dia, conversando com o Rolim, ele me contou desta técnica bem simples.

Ler toma menos tempo do que você imagina

Consiste em um compromisso pessoal de ler uma certa quantidade de páginas por dia (no meu caso comecei com 10). O número não precisa ser exatamente este, pois sabemos que depende muito da tipo de leitura e tudo mais. Mas este pequeno compromisso te leva a avançar pequenos passos todo dia e te demanda pouco tempo.

Ler, para mim, é um prazer e uma necessidade. Esta prática simples me fez terminar uma grande quantidade de livros que estavam apenas juntando poeira. Além disso, ler um pouco de cada vez te ajuda a absorver melhor o conteúdo dos livros e meditar sobre o que você acabou de ver.

Técnica do tomate

Esta técnica (também conhecida como pomodoro) está bastante famosa atualmente. É uma técnica bem simples que consiste nos seguintes passos:

Crie uma lista de tarefas que você tem a fazer.
Escolha uma para ser realizada.
Marque em um cronômetro 25 minutos.
Trabalhe até o cronômetro tocar apenas naquela tarefa (não vale se distrair com outras coisas)
Quando o cronômetro tocar. Pare o que está fazendo e tire um descanso de 5 minutos.
Repita o procedimento.

Você nunca mais vai olhar pra um tomate com os mesmos olhos

Esta técnica é perfeita para quem trabalha com atividades que tem muito pontos de distração. Isso vale em especial para quem trabalha na frente do computador. Você com certeza tem diversas fontes de distração ao seu redor (twitter, email, gtalk, RSS). Com esta técnica eu consigo me focar em apenas uma atividade por vez e saber que ao final de 25 minutos eu poderei ver outras coisas, relaxar e depois voltar a ela, ou ir para uma outra atividade (caso tenha terminado ou apareça algo mais urgente).

O poder de concentração que se ganha é incrível e o ganho de rendimento é excepcional. Com o tempo, o hábito de se concentrar durante o tomate (como chamamos o período de 25 minutos) e depois relaxar na pausa, se mostra uma combinação poderosa para auxiliar na resolução das tarefas. Para desenvolvedores aconselho fortemente ver o material que o Pedroso está disponibilizando sobre esta e outras técnicas [1][2].

GTD - Getting Things Done

O GTD é uma técnica um pouco complexa, e aconselho fortemente ler o livro da técnica. Vou tentar sumarizar um pouco de como utilizo a técnica, mas não se limitem apenas ao que eu relatar aqui. O primeiro ponto que a técnica reforça, é que a sua mente é um lugar perigoso de se confiar. Nós assumimos diariamente diversos compromissos internos e nos esquecemos deles. Isto nos causa uma sensação de desconfiança conosco. Por isso, nós devemos remover os compromissos e ações guardamos em nossa mente e passá-los a um sistema confiável. Desta forma não perderemos estas informações, e elas estarão ali quando precisarmos. Nesta técnica nós temos alguns elementos que lhe ajudarão a organizar suas ações.

Tirar as coisas da sua mente é o passo mais importante.

O primeiro elemento é a caixa de entrada. Ela é o local onde o toda informações que você precisa processar vão estar. Pedidos, contas a pagar, emails, recados, lembretes. Tudo aquilo que você ainda tem que analisar e tomar uma decisão estará na sua caixa de entrada. Quando você tem algo na caixa de entrada você está seguro que uma hora você vai poder recorrer a ela para realizar sua analise.

O elemento seguinte é a(s) lista(s) de tarefas. Você pode possuir quantas desejar (eu possuo apenas duas: pessoal e profissional). O mais importante sobre elas é que, quando um elemento da sua caixa de entrada é processado ele deve ser inserido na sua lista de tarefas como um projeto e um conjunto de ações que você deve realizar para finalizar aquele assunto. Caso as ações sobre determinado assunto demandem menos de 2 minutos, é aconselhado que você faça isto naquele momento, evitando de entulhar sua lista de tarefas com coisas muito pequenas.

Todo material que você tem realizado a suas tarefas é aconselhado de estar armazenado em um arquivo de referência. Este local será sua fonte de informação quando você precisar saber sobre algo que você já fez ou precisa saber.

Por último temos o calendário. O calendário serve para armazenar assuntos da sua caixa de entrada que não precisam ser tratados no momento. Você então agenda eles para que entrem na sua caixa de entrada no momento específico em que deveriam ocupar a sua mente.

O grande segredo nesta dinâmica é estar sempre "zerando" a sua lista de tarefas. Pois estes são seus elementos já processados e neles já constam as ações que você acredita que tem que tomar para finalizar cada assunto. Conforme suas tarefas se esgotam você começa a processar suas caixa de entrada (que vai gerar novas tarefas). E isso prossegue até que tudo esteja vazio =]

Este é um jogo contínuo e interminável, mas a sensação de controle passada por quem segue esta técnica é algo impressionante. Ter um sistema confiável que controla de maneira persistente aquilo que você tem que realizar e se preocupar liberta a sua mente da preocupação de se lembrar de cada detalhe de tudo que você precisa fazer. Sobrando assim mais tempo pra pensar em coisas mais interessantes.

Finalizando

Ter domínio sobre seu tempo e alcançar com efetividade seus objetivos é um elemento chave para a minha felicidade. Tentei compartilhar aqui um pouco das técnicas que uso no meu dia-a-dia. Produtividade pessoal é um assunto que me fascina bastante e espero ser inspirado a escrever um pouco mais sobre ele mais pra frente.

Comentários:

¹ - Sei que felicidade é um tema polêmico. Mas considerem aqui apenas um conceito genérico de felicidade, não precisamos entrar na filosofia do assunto.

Referências:

Imagens retiradas de:

Chefes, Cargos e outros detalhes

2010-08-04T21:34:00.004-03:00

Hoje ficou um post um pouco longo, mas acho que vale a reflexão.

Chefes

Eu já falei a 1 ano atrás sobre por que não acredito na necessidade dos chefes. Recentemente o @faa85 mandou uma série de vídeos clássicos do Waldez Ludwig (video1, video2 e video3) falando sobre o novo mercado de trabalho (se você não viu, eu aconselho ver). Nem precisa falar que a fala dele é bem alinhada com o discurso do pessoal do manifesto 2.0. Resumidamente o que ele nos diz é que não existe mais espaço, na indústria da informação, para os antigos capatazes (atuais gerentes), nem antigos escravos (atuais funcionários), e que hoje as relações se moldam de uma forma mais horizontal e guiada pelo conhecimento.

Mas isto é chover no molhado. O que me traz a discutir novamente é o fato de que eu realmente acreditava que, nos trabalhos intelectuais, não existia espaço para chefes. Mas tenho visto que isto não é verdade para muitos, e acho que vale abrir espaço para algumas observações que fiz.

Primeiramente, entenda o que é um chefe. Este cara (também chamado de Gerente ou Coordenador) é uma pessoa encarregada de estabelecer cronogramas, fazer planos, distribuir tarefas e assegurar que tudo ande nos trilhos. Caso algo saia dos trilhos, ações corretivas devem ser tomadas para que tudo volte ao normal.

Na minha visão não precisamos mais desta figura. Na indústria do conhecimento a equipe é bem capaz de alcançar tudo isso quando lhe apresentam um objetivo. Mas vale então mostrar meus achados empíricos de impedimentos ao estabelecimento deste cenário.

1º Detalhe: "Praticidade"

É muito ruim para a maioria das pessoas sair da posição de ter que apenas acatar decisões para efetivamente tomá-las. Muitos acreditam que não estão preparados ou tem apenas preguiça desta nova atividade. Afinal, tomar decisões implica em discutir, argumentar e expor sua opinião aos demais. Neste caso seria melhor receber ordens do chefe. Afinal, ele sabe bem mais que você (será?).

2º Detalhe: "Responsabilidade"

A culpa quando algo sai errado é do chefe. Afinal, ele que tomou as decisões erradas. Mas quando estas são tomadas pela equipe fica complicado, pois agora a responsabilidade é de todos. Temos a vantagem das glórias serem compartilhadas, mas isso não supera o medo de muitos de se arriscar naquilo que se faz. Deixe que o chefe decida, afinal, se der errado, a culpa não é minha.

Estes dois detalhes levam toda a idéia de compartilhamento, transparência e auto-organização pro buraco. Pois impedem de maneira drástica qualquer medida em prol de uma estrutura menos hierárquica. Mas será que eles realmente impedem um ambiente 2.0? Será que não vale nos arriscarmos um pouco e obter novos resultados no lugar da segurança dos resultados que já conhecemos?

Cargos

Cargos são aqueles nomezinhos que você coloca no seu cartão de visita, assinatura de email (não vale certificações, sobre isso o @unclebobmartin já falou) ou conta pra suas tias. Eu por exemplo já usei uma penca:

Cientista da Computação
Analista de Sistemas
Analista Desenvolvedor
Diretor de TI e GQ
Empresário
Etc ..

Mas nada disso diz alguma coisa. Ou será que diz? Um dia desses uma colega de trabalho me perguntou o que colocar no campo "cargo" de um formulário, eu disse "coloca analista de sistemas" e se iniciou uma breve discussão se aquilo a enquadrava ou não no que ela desempenhava. No meio de TI existem diversos definições de cargos, algumas muito"estranhas" a mim. Afinal, o que diferencia um Testador de um Analista de Teste? É uma cabeça sem corpo? E se o cara que desenvolveu também testar ele é o que? E se ele conversar com o cliente? A combinatória disso leva a um caos total. Por isso que eu gosto do termo que o amigo @alegomes usou em sua última apresentação: "Engenheiro de Software". Algo que abrange tudo relativo a produção de software (algo que se espera de qualquer um neste meio).

Infelizmente, cargos carregam muito mais que isso. As pessoas não querem saber apenas do significado. Elas querem saber do que eles representam socialmente. Por isso a briga pelo cargo de Arquiteto, Líder de projeto e Gerente são grandes (apesar de ter muita dessa gente fazendo o serviço de ponta-a-ponta =P).

Conclusão

E aonde eu quero chegar neste meu post?

Assim como disse o Waldez Ludwig, cada vez mais vejo que o mundo da gestão do conhecimento é para poucos. Pois comportamentos como estes que eu observo só me levam a crer que muitas pessoas ainda preferem o viver no (não tão) seguro mundo 1.0. Preferem não se arriscar em um mundo sem fórmulas mas que pode levar a um trabalho muito mas feliz. Não cabe a mim criticar estas decisões, mas vale colocar aqui que existe um universo muito mais belo fora desta caixa, basta abri-la e sair.

Mestrado Finalizado

2010-07-08T14:32:00.005-03:00

É com muito prazer que no dia 25/06/2010 (apesar da sonolenta participação da nossa seleção contra Portugal) meu mestrado finalmente teve sua última avaliação. Chegando assim em favorável resultado final. Além de agradecer por tudo que passou, o que eu mais queria aqui era contar um pouco como foram esses 3 anos 3 meses e 18 dias de pesquisa.

Com certeza você não vai achar nada disso nos meus artigos =P

Meu mestrado era uma incógnita desde o princípio. Apesar de muita gente esperar que eu fosse fazer algo do gênero, eu não tinha tal intenção. Tinha acabado de me formar e a Intacto estava indo muito bem e demandando muito esforço. Porém, no dia 07/03/2007 o senhor Alê fez sua defesa do mestrado e eu estava lá. Sua apresentação apresentou o universo da computação ubíqua, o que me deixou bastante animado. O projeto dele apresentava um middleware que focava na integração entre dispositivos baseando-se na adaptabilidade de serviços. O nome desse treco era UbiquitOS e me chamou muito a atenção. Toda essa idéia de usar dispositivos do ambiente e trocar serviços de maneira inteligente era o tipo de coisa que eu estava buscando.

Durante a apresentação milhões de idéias já começaram a pipocar na minha cabeça, mas uma foi mais forte. Uma das limitações do middleware era que ele só se comunicava usando Java. Tendo sido meu TG em redes e tendo alguma experiência de mercado pensei: "Opa, bora jogar SOA nessa parada". No mesmo dia já negociei com a Carla Castanho e com o Alê e eles gostaram da idéia (ou pareceram gostar).

Quase isso, mas com muitos artigos pra embasar a idéia.

Foi então que entrei como aluno especial no mestrado e nasceu o grupo UnBiquitous. Éramos 3 Doutores (Carla Castanho, Ricardo Jacobi e Pedro Berger), 1 Mestre (Alexandre Gomes), Eu e dois alunos de TG (Estevão Passarinho e Humphrey Fonseca). Durante o 1º ano pesquisamos bastante e nossos trabalhos geraram até uma melhoria no middleware. O Passarinho foi o responsável por colocá-lo para suportar diversas tecnologias de rede (pois antes era fixado em bluetooth). Este primeiro ano me rendeu a proposta do meu trabalho. Tudo me levava a crer que era só criar um protocolo que fizesse o meio de campo entre os dispositivos e o software. Cheguei inclusive a alterar o middleware para falar uma princípio deste protocolo, que por convencimento do Bassani, era baseado em JSON (levando a uma solução mais leve). Por isso minha proposta de mestrado era: "Um protocolo SOA de alto nível para arquitetura de redes ubíquas". Pois eu realmente acreditava que este era um problema de rede.

No segundo ano eu já era aluno efetivo do mestrado. Avancei bastante no desenvolvimento do middleware e consegui chegar a uma versão estável que foi publicada no google.code. Porém as pesquisas e conversas com a Alba Melo me levaram a crer que eu precisava de uma arquitetura em cima disso tudo, além disso aquele meu protocolo era na realidade um conjunto de protocolos. Isso garantiu a minha qualificação que ficou com o título de "DSOA: uma arquitetura orientada a serviços para o contexto de computação ubíqua".

Fica a pergunta no final: O que eu faço com isso mesmo?

O terceiro ano foi pesado na escrita de artigos, revisões, mais pesquisa e ajustes, tanto nos textos como no código. Todo esse trabalho foi compensado com uma publicação no GPC2010 e no LNCS. Mas o ponto mais importante disso tudo foi voltar a me atentar na importância das aplicações no projeto. Foi finalizada a implementação do middleware em duas versões. Foi construído o protótipo de uma aplicação e foram realizados muitos testes.

Mas o que eu mais queria apresentar aqui era algo que não fica registrado em nenhum artigo, repositório ou dissertação. É aceitar que na pesquisa muita coisa muda. O projeto nasceu acreditando que o problema estava na rede e que um protocolo resolveria tudo, no meio vimos que uma arquitetura seria a solução e por fim que o conjunto de tudo era importante, mas o mais importante eram as aplicações. Isso então levou ao título final do trabalho "Um conjunto de soluções para a construção de aplicativos de computação ubiqua".

É claro que neste meio tempo tivemos muitas outras coisas e muita ajuda. Mas isto deixaria este post muito maior do que já está. Por isso vou terminar com a reprodução do agradecimento da dissertação.

Um trabalho como este não chega ao ponto de ser aceito por uma banca de mestrado sem ter tido a colaboração de muitas pessoas. Apesar de o autor do trabalho ser apenas um, o esforço de muitas pessoas foi desprendido para que se chegasse ao resultado apresentado, e com sucesso. Agradecer a todos que participaram deste processo é abrir brechas a falha de esquecer alguém muito importante. Apesar da dificuldade da tarefa me arrisco aqui agradecer a aqueles que colaboraram.

Primeiramente gostaria de agradecer a Deus que me deu forças, inspiração e energia para superar três anos, três meses, 18 dias e mais de 1000 horas de empenho neste projeto. Agradeço também por ter colocado pessoas muito especiais em meu caminho e ter me agraciado com bons frutos ao longo do tempo.

Agradeço à minha mãe, meu pai e meus irmãos que por mais que tenham visto um pouco de loucura na computação ubíqua não minimizaram os incentivos nesta minha empreitada.

Deixo meu agradecimento especial a Pah (Paloma Braga) que mais que companheira e revisora foi minha co-autora, assessora de marketing e injetora de energia ao longo de todo este trabalho.

Agradeço aos professores Ricardo Jacobi e Carla Castanho que apostaram em um aluno (na época) desconhecido para orientar nos caminhos nebulosos da computação ubíqua. Ao senhor Alê (Alexandre Gomes) que confiou a mim esta tarefa importante de dar prosseguimento em seu trabalho. Contei também com a colaboração de muitos professores como Jõao Gondim e Pedro Berger que compartilharam conversas, opiniões, e conhecimentos de suma importância ao longo do trabalho. Agradeço em especial a professora Alba Melo que me acompanha desde os tempos de graduação, sempre me auxiliando com dicas importantes nas pesquisas que desenvolvi e ao professor Mário Dantas que não só compartilhou idéias junto ao grupo como aceitou ser um dos validadores deste trabalho.

Muitos foram aqueles que botaram a mão na massa e deixaram a sua marca não só espiritual mais codificada no uOS. Fica então registrado um grande obrigado aos senhores Passarote (Estevão Passarinho), Lucas Lins, Lucas Quintella, Beatriz Marília e Marcelo Bassani que deixaram a marca de seus esforços nos fontes deste trabalho. Fica também a aposta nos senhores Carlos Botelho, Lucio Scartezini, Lucas Pessoa e Bruno Zumba que se dispuseram a continuar nesta nossa linha de pesquisa.

Fica também meu obrigado ao pessoal da família 13 e da Intacto pelo apoio dado ao longo desta empreitada. Em especial ao Carlitos que foi meu incentivador (e desertor) de engajar no mestrado, e me auxiliou nos momentos de aperto. Também fica o obrigado a equipe do Karmonitor que dividiu o laboratório comigo nestes últimos nove meses e se mostraram ótimos companheiros.

Por fim a Rosa e o Daniel da secretaria que salvaram muitas barras e deslizes meus e as ``guardetes'' dentre muitos outros que deixaram a marca de seus esforços neste trabalho. Aos citados e muitos outros que por acaso eu venha a ter esquecido o meu muito obrigado.

PS: Assim que sair a publicação da dissertação colocarei o link aqui.

EDIT [04/08/2010]: Minha dissertação pode ser encontrada aqui.

Por que trabalhar?

2010-04-22T22:03:00.003-03:00

Essa é uma questão que deve passar na mente de muitas pessoas e a sua resposta (ou falta dela) é importantíssima para o que você deseja em curto, médio e longo prazo. Mas antes vou contar uma pequena história.

Como desempenhar mal seu trabalho

Nas duas última semanas passei por uma série de tarefas burocráticas. Eu precisava tirar alguns documentos e como todos sabem isso é certeza de muitas idas e vindas a diversos órgãos, bancos além de ligações e consultas ao google e conhecidos. Nos muitos lugares que visitei, nas muitas filas que dividi com outros que passavam pela mesma odisséia, encontrei diversos funcionários responsáveis por lidar com o público. Muitos mal humorados, de respostas curtas e grossas, outros calmos e prestativos. Dentre estes casos um fator me chamou a atenção e pode ser exibido na seguinte situação:

Em um dos órgãos que visitei, era necessário o agendamento de hora para atendimento com um bom tempo de antecedência. Eram 6h40 e eu estava na fila das 7h30. As 6h50 aparece uma pessoa responsável por realizar a primeira triagem. Esta se dirige a todos e diz em voz alta: "(...) e quem não tiver o novo formulário XXX-YYY preenchido não adianta nem entrar que não vai conseguir (...) e vocês tem até as 11h pra resolver isso (...)". O primeiro senhor da fila se dirigiu a ela e explicou que tal informação não estava no site quando ele agendou (um mês antes) e ela respondeu : "Isso já faz uma semana que está no site. Se o senhor quiser entrar pode entrar, mas vai perder seu tempo." depois de um pouco de discussão retrucou "Eu só estou obedecendo ordens.". O senhor, insatisfeito com o tratamento decidiu prosseguir e protestar.

Passadas mais duas triagens e 45 minutos depois o senhor chegou a mais uma atendente. Esta o recebeu e mais uma vez o questionou sobre o formulário XXX-YYY. O senhor mostrou sua queixa e seu ponto de vista. Prontamente a senhorita explicou calma e pausadamente que este novo procedimento era obrigatório e o próprio sistema não o permitia prosseguir. Ela o instruiu que o preenchimento do novo formulário era rápido e não demandava mais que 30 minutos. Ainda acrescentou ao senhor que se ele resolvesse esta questão antes das 11h seria prontamente atendido e não perderia mais do seu tempo. Satisfeito com a atenção e com a visão de uma solução o senhor prosseguiu a fim de resolver sua situação.

Por que eu faço o que eu faço?

Podemos ver que as duas pessoas que lidaram com aquele senhor passaram para ele a mesma informação. Porém, o resultado obtido foi bastante divergente. O que realmente diferenciou a ação de ambas foi que uma delas sabia o objetivo de seu trabalho ao passo que outra preferiu se "esconder" atrás de ordens.

Saber aonde você quer chegar com o seu trabalho é a chave para desempenhá-lo bem. E como podemos ver isto não é exclusividade dos trabalhadores do conhecimento. Sem saber aonde você tem que chegar e como seu trabalho afeta as pessoas relacionadas é quase impossível desempenhar um papel relevante. Sem objetivo tudo que sobra é a execução cega de um autômato humano durante a sua tarefa. Afinal, sem isto você não passa de uma peça em uma engrenagem ao melhor estilo "tempos modernos".

Encontrar o objetivo de nosso trabalho e de nossas atividades é o primeiro passo antes de tentar compreender como executá-las. Com isto, todo o resto se desenrola de maneira facilitada. Isto é válido, principalmente, quando se trata de trabalho em equipe. Em uma equipe é comum a divisão de tarefas, principalmente onde o trabalho de um depende do de outro.

Em uma equipe sem um objetivo comum claro, incorremos em uma situação de conflito de interesses. Cada um tem por objetivo cumprir apenas sua tarefa e prosseguir para a próxima. Quando esta afeta negativamente o trabalho do próximo, é muito mais complicado retornar àquela atividade (já que ela não é mais o objetivo). Já em uma equipe com um objetivo comum não existe tal conflito, afinal, todos os interesses convergem em um mesmo ponto. E assim todos tem uma maior liberdade de influir no trabalho geral, já que é claro como cada atividade colabora com aquele fim.

Meu trabalho e minha felicidade

Mas buscar o objetivo no seu trabalho tem um impacto ainda maior que garantir um bom resultado final. Isto garante a você uma maior satisfação naquilo que você faz. Quantas vezes você não desempenhou uma tarefa que achava desnecessária? Qual o ânimo você teria de levantar todos os dias da cama, ir ao trabalho, digitar por 8 longas horas um fonte que você nem sabe pra onde vai? Você trabalharia 6 meses em um projeto que ao final seria jogado no lixo? Qual empenho você desprenderia em atividades com estes cenários a vista? Com certeza seria mínimo.

Agora imagine você trabalhando em um projeto que gera retorno ao seu cliente. Trabalhar na confecção de um aparelho que vai inovar o mercado? Ensinar e mudar a vida de pessoas? Qual é seu ânimo agora? Saber onde você tem que chegar e como seu trabalho afeta as pessoas nos enche de expectativas e energias para aquela atividade.

Ganhar dinheiro é importante em um mundo capitalista. Mas ser feliz é começa a ser um fator importante em uma sociedade 2.0 . Muitas pessoas acordam de manhã e vão ao trabalho contando as horas para voltar para casa. Estas pessoas vendem 1/3 de sua felicidade por um preço. Muitas se escondem atrás de "ordens", "do sistema" e outras desculpas para não mudar o foco do seu trabalho. Mas se esquecem que todo trabalho tem uma razão, basta a cada um buscá-la. Achar tal objetivo é um fator multiplicativo de satisfação. Afinal quando uma pessoa realiza bem seu trabalho ela afeta positivamente não só a si mesma, mas a sua equipe, seus clientes (se for o caso), usuários. E isso produz uma imensa inércia benéfica a todas as partes.

Confiança

2010-02-25T08:02:00.003-03:00

"No gift is more precious than trust."

Ditado Jedi

Já falei aqui no blog sobre algumas visões minhas em cima de como deve funcionar uma equipe de trabalho. Hoje vou voltar no assunto, mas para falar sobre outra perspectiva, a confiança.

Sabemos bem que confiança é a chave para todo tipo de relacionamento. Se você não confia em alguém você não consegue se relacionar bem com esta pessoa. Porém um relacionamento onde tem confiança se desenrola com mais tranqüilidade, gerando melhores resultados (e alegrias) a todos.

Muitas vezes nossa relação de confiança nasce de maneira simples e descomplicada. Um bom exemplo é quando você compra algum equipamento. Se alguém próximo lhe indica uma determinada marca, você compra e fica satisfeito, se estabelece um vínculo de confiança junto a marca. Com certeza você estará disposto a indicar esta empresa a outras pessoas, e espera que este vínculo se repita.

Muitas vezes esta confiança se estabelece de maneira mais complexa. Recorremos a contratos, garantias a fim de assegurar que um determinado nível de "confiança" se estabeleça na relação.

Mas em todos os casos de relacionamentos onde se tem confiança uma regra é geral. Mesmo o mais fortes dos relacionamentos demanda menos esforço para sucumbir que para se erguer. E é aqui que entra o meu ponto neste post.

Confiança na equipe

"Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done."

Agile Manifesto

Uma das características mais notáveis em equipes ágeis é a simplicidade na hierarquia. Sabemos bem que muitas das hierarquias estabelecidas nas empresas busca o controle da produção. É neste controle onde morre a confiança na equipe. Criamos formulários, templates, pesados processos a fim de assegurar que tudo ande nos eixos. Não que estas ferramentas não sejam importantes, mas sim que muitas vezes seu objetivo é bastante distinto em cada tipo de organização.

Existe muitos kilômetros de diferença entre dizer:

"Você deve seguir o template TMP_2008_2145_PPS nesta tarefa."

E dizer:

"Cara dá uma olhada no template de PPS no repositório que ele pode te ajudar bastante."

Bem disse Hunter em seu livro "O monge e o executivo" que aquele que não delega responsabilidades aos membros de sua equipe é desonesto com ela. Sem confiança não se delega responsabilidades e sem isto a equipe é impedida de crescer e evoluir.

Como confiar ?

Quando você está na equipe e você confia nela esta confiança retorna a você. É incrível como confiança e transparência são coisas que andam juntas. Se você é transparente aos demais isto gera confiança e assim os demais serão transparentes a você. Esta transparência é a base para estabelecermos feedbacks que tenha real valor (e não palavras vazias em um formulário) e que sejam no tempo certo (e não só quando a vaca foi pro brejo) e assim crescer.

Confiar é uma aposta, você deve confiar primeiro e só poderá colher seus frutos no futuro. É claro que se quebra a cara neste caminho, mas isso faz parte do aprendizado. Quando falhamos em colocar adequadamente nossa confiança devemos corrigir isto pontualmente (e não burocratizando toda a equipe). Vivemos em uma era de colaboração e a confiança é um dos elos dessa corrente. Confie e colherá os resultados.

Suporte para NoteBook

2010-02-04T08:08:00.009-02:00

Hoje em dia usar laptop é um hábito de muitos. Eu mesmo uso laptop diariamente desde 2005 e não tenho pretensões de usar um PC como ferramenta principal de trabalho tão cedo. A mobilidade a praticidade e principalmente a privacidade que o laptop te traz, foram fatores determinantes nesta minha escolha.

Porém como já me foi alertado pela nan, o laptop tem sérios problemas ergonômicos. Temos que escolher entre ter a melhor postura para digitar ou a melhor postura para visualizar a tela, nunca ambos ao mesmo tempo. Fora isto, o teclado da maioria dos notebooks não é adequado para longas horas de digitação. Sobre o touchpad, nem se fala. Por isso já fazem mais de 6 meses que eu utilizo um suporte de notebook com um mouse e teclado usb quando estou na Intacto. Isso melhorou bastante a minha postura e tenho sentido bons resultados com a experiência.

Hoje utilizo o Notepal S, mas ele tem a desvantagem de "esconder" os controle frontais do laptop, por isso, quem estiver interessado em comprar um suporte, aconselho buscar outros modelos mais interessantes como este.

Uma outra opção é você fazer o seu próprio suporte, este post traz ótimas idéias sobre o assunto. Mas eu e o bassani decidimos seguir um pouco a linha deste cara, e fazer nosso próprio suporte de papelão (no caso papel paraná).

No post original o traçado era bastante bonito, contando com bordas arredondadas. Como nós sabíamos do trabalho que ia dar pra recordar em um papel tão duro, fizemos apenas linhas retas.

O resultado ficou bem agradável e estável.

Além disto o suporte resiste a Macs e a PCs =P.

Segue o projeto que seguimos.

A pedidos segue uma imagem do que usamos de uma folha do papel paraná. Uma folha destas custa R$10,00 e deve render entre 6 e 8 suportes. Dá um bom trabalho pra cortar usando estilete e canivete. Demoramos algo em torno de 2 tomates (1 hora) pra fazer este. Mas quem gosta de meter a mão na massa, vale a pena. Além do mais quem quiser pode personalizar a vontade, inclusive tentando outros materiais.

Twitter Trial

2009-11-08T09:46:00.003-02:00

Hoje fazem 15 dias que fui para o twitter, então vou falar um pouco dessa experiência e de como ela tem sido. Pra quem for ler, saiba que estas são as minha impressões pessoais sobre a ferramenta, e por isso seu experimento pode obter resultados inesperados.

Eu me considero lento em absorver novas ferramentas. Mas isso faz parte do meu jeito de lidar com as coisas, gosto de estudar e analisar antes de mergulhar. Antes de entrar no twitter eu estudei a ferramenta, procurei muitas opiniões. Nenhuma me levou a visualizar utilidade para mim ou ao menos gostar da ferramenta. O twitter sempre se apresentava como uma mistura de rede social e rss. Em resumo, uma ferramenta que não me agrada e outra que me agrada bastante. Mas após a entrada da Intacto (@IntactoSoftware) na ferramenta, decidi entrar também e ver como funcionava na pele (@nukdf). Seguem então minhas impressões e dicas para quem ainda vai entrar neste universo.

Seguir

Esse é o ponto principal do twitter. Se você está na ferramenta você segue alguém. A grande questão é quem seguir e porque seguir. Aqui fica a cargo de cada um definir suas preferências, mas não se distancia muito de como você povoa seu RSS com os feeds que mais lhe interessam na blogosfera.

No twitter, temos diversas pessoas tuitando sobre os mais diversos assuntos. Nesses meus 15 primeiros dias adicionei apenas pessoas que ou eram próximas ou que já conhecia seu conteúdo de outros lugares (blogs, listas, etc). Com alguns eu acertei, com outro errei. E com isso fui adicionando e removendo conforme foi indo.

Muitas pessoas tuitam com uma freqüência enorme, outras menos. Uns falam de trivialidades outros sobre assuntos mais relevantes. E ainda temos as pessoas que simplesmente não tuitam, apenas seguem.

Existem muitos perfis que apenas tuitam os posts de seus blogs. Para mim este não é o grande forte da ferramenta. Bons blogueiros sabem usar o twitter para divulgar suas opiniões mais "rápidas" e compartilhar coisas que possam interessar seus leitores. Utilizando melhor a ferramenta.

Escolher quem seguir é o ponto chave para saber se você vai tirar bom proveito ou não da ferramenta.

Os 140 caracteres

Se você tem algo interessante para divulgar, talvez o twitter seja um bom lugar para fazê-lo. Assim como os blogs, flogs e comunidades em redes sociais, para se divulgar informações no twitter bem, deve-se definir quem será seu público alvo. No caso do twitter, por usar característica mais voltada para "redes sociais" isto pode ser mais nebuloso que em outras ferramentas. Porém, tenha em mente que caso você fique divagando no twitter sobre aonde você vai a cada instante, aquele link interessante sobre novas metodologias de desenvolvimento pode acabar não sendo visto. E este tipo de mix pode atuar contra você.

Aqui também vale um pouco de experimentação, é tão fácil de se postar e se ver entre trivialidade que eu mesmo me vi postando coisas que não devia nestes 15 dias de uso. Mas o bom senso é algo que nos ajuda em todos os lugares.

Ferramentas

Nem experimentei usar o twitter na sua interface natural. Já de cara não me agradou e pareceu que não ia me agregar muitos recursos. Por isso já procurei de cara uma ferramenta para me ajudar a organizar essa bagunça.

Hoje estou usando o TwitterDeck e estou satisfeito. A ferramenta tem alguns pontos a melhorar, mas atende ao que necessito. Um de seus recursos mais interessantes é o de cadastrar uma pesquisa e receber a notificação de twits que casam com o que você busca. Mas este recurso também existe em outras ferramentas.

Existem muitas outras por aí (Twitterrific, Twitterfox/Echofon, HootSuite) acho que cabe a cada um descobrir qual tem os recursos que realmente lhe interessam.

Conclusão

Bem, ainda estou experimentando a ferramenta. Já obtive bons resultados neste experimento e já tive minhas decepções. Mas até agora justifica continuar seu uso.

BlogDay 2009

2009-09-01T16:26:00.003-03:00

Hoje é o Blog Day, o dia dedicado ao conhecimento de novos blogs. A ideia é que cada blogueiro divulgue uma lista de cinco outros blogs interessantes e, de preferência, ainda pouco conhecidos. A data 31/08 foi escolhida por parecer com a palavra blog (3108). Sendo assim, vamos aos meus cinco indicados.

Agile Way : Blog do Flávio Steffens. Acompanho-o desde o blog "MudandoUmaPequenaEmpresa". É um blog bem leve e de fácil absorção sobre como usar as metodologias ágeis no dia a dia.
Efetividade.Net : Blog sobre como tratar as coisas do dia a dia profissional e profissional sem desperdício, sempre com boas dicas guias.
Misko Hevery : Especialista em testabilidade e qualidade de software. Uma boa leitura pra quem quer desenvolver código de qualidade.
Graffiti : Sempre antenado com o que acontece ao cenário de TI colaborando com críticas ácidas e bem formadas.
JBox : Mantendo informado os otakus brasileiros do que está acontecendo no cenário nacional e mundial da animação.

Instruções para participar

Liste cinco novos Blogs que você ache interessantes.
Notifique esses cinco bloggers de que serão recomendados por você no BlogDay 2009.
Escreva uma descrição curta dos Blogs e coloque um link para os blogs recomendados.
Publique no BlogDay (no dia 31 de Agosto) esse post.
Junte a tag do BlogDay usando este link:
http://technorati.com/tag/blogday2009 um link para o site do BlogDay:http://www.blogday.org

Precificação em Ponto de Função

2009-08-23T21:20:00.002-03:00

Estou nessa de ponto de função a algum tempo. Não só participei de sua implantação, como hoje esta é a forma mais utilizada na Intacto para o controle de nossas métricas. Converso com muitos amigos, e muitos me questionam sobre algumas questões sobre pontos de função. A realidade é que sempre fui um cara de desenvolvimento, meu principal objetivo foi sempre transformar sonhos em código em execução. Utilizo a APF como forma de me auxiliar neste caminho, e discuto muito sobre ela com a minha equipe de forma que tenhamos transparência com relação a esta métrica.

Em um de meus posts anteriores falei sobre como a utilização de APF pode ser traiçoeira. E hoje venho aqui pra falar mais uma vez destes perigos. No caso de hoje é sobre a homegeinização que o pessoal de negócios tende a trazer sobre esta ferramenta. Houve-se muito no mercado sobre os preços de PF que algumas empresas praticam. Estes preços são utilizados por muitos "homens de negócio" para questionar seus custos e pressionar suas equipes. Mas aí que está o problema. Como dito anteriormente, a técnica de APF apenas lhe dará o tamanho do seu software. Tamanho não lhe diz tudo sobre custo, complexidade nem prazo.

Aqui temos um ponto importante, as empresas começam a utilizar a técnica de APF, obtem uma leve base de mercado e histórica e começam a substituir a antiga medida de homem-hora por PF. Aí que temos o erro, onde o uso falha, e não a técnica. Para mostrar isso um exemplo. Vou começar em como fracassar com a APF primeiro.

PF Fixo

Este é o exemplo clássico. Uma empresa, com base em informações de mercado, históricas e de custo determina um preço fixo ao seu ponto função, digamos 10,00 R$/PF. O custo da empresa é de 8,00 R$/PF, o que é uma boa margem aos "homens de negócio". A empresa consegue um projeto de um sistema de cadastro de clientes a este valor. Ao final do projeto chega-se a conclusão de que o custo finalizou em 10,00 R$/PF, levando a empresa a uma situação sem lucro. Sabiamente, os "homens de negócios" decidem pro aumentar o PF da empresa para 12,00 R$/PF. Novamente, a empresa consegue mais um sistema de cadastro de clientes. Ao final deste projeto, observa-se que o custo foi de 6,00 R$/PF. Os "Homens de negócio" ficam bem felizes, afinal, ao que tudo indica finalmente chegaram a um bom preço. Um novo sistema aparece sob o mesmo preço praticado anteriormente. Este sistema é para desenvolver um controle de documentos. Ao final do sistema descobre-se que o custo por PF foi de 15,00 R$/PF. Os "Homens de Negócio" ficam irritados, e se questionam o que deve ter ocorrido de errado.

Todos os valores e histórias são fictícias, mas podem ocorrer em uma empresa perto de você.

Conclusão

O que ocorrer neste caso é um caso clássico de mal uso da técnica de APF. Ao se decidir utilizar a técnica de APF não podemos tratar todos os casos da mesma maneira. Variáveis como:

Base Histórica
Entendimento do Negócio
Reuso
Riscos
Capacidade da Equipe

Dentre muitas outras devem ser consideradas neste caminho.

Ao meu entendimento, a melhor forma de se trabalhar com APF é baseada na experiência e na boa medida destas variáveis apresentadas. Se você está iniciando agora neste caminho, você deve partir de uma base que você conheça. Conte seus sistemas passados, faça uma pequena base histórica. Ao analisar um novo sistema, lembre-se da sua base histórica, verifique seus riscos envolvidos e quanto eles adicionam aos custos e considere-os em seus cálculos. Desta maneira vá evoluindo sua base histórica e sua experiência a cada caso.

Espero ter ajudado aos marinheiros de primeira viagem.

Diga não aos Chefes

2009-07-23T08:44:00.003-03:00

O Texto a seguir foi enviado por mim a lista interna na empresa recentemente.

Achei válido compartilhá-lo, pois sempre fui averso a visão feudal do chefe roteador de emails e planilhas.

Vamos começar analisando o conceito clássico de "chefe". Tipicamente o chefe é o cara engravatado que passa o dia em um escritório atrás de uma bela mesa, ele tem uma secretária (as vezes nem tão bela) e ele opera em 2 sentidos. No 1º sentido, o chefe recebe diretrizes de cima, e repassa estas as pessoas abaixo. No 2º sentido, o chefe cutuca as pessoas abaixo dele, elabora algumas planilhas e envia estas acima.
Tudo bem, é uma visão simplista e bem antiquada, mas muito "chefe" (chame de supervisor, gerente, etc) opera bem próximo disto, muitos não fazem muito mais do que receber objetivos, delegar tarefas, rotear emails e elaborar planilhas. No fim, só mais uma peça em uma grande engrenagem. Para muitos isso parece funcionar bem, trabalhar 8x5, receber suas tarefas, digitar-digitar-digitar e entregar ao fim da semana é o bastante.
Mas esse modelo não serve na Intacto, aqui receber ordens e obedecer as cegas não basta. Todos devemos trabalhar como um time, onde decisões e ações são compartilhadas e discutidas, onde todos conhecem os objetivos (e não apenas as tarefas) e trabalham em conjunto em busca destes objetivos. E nesse nosso time, nossos objetivos são traçados pelos nossos clientes/usuários.
Bem, é neste cenário que a figura do chefe não cabe, mas cabe um papel que (não) pode ser confundida com ele, é a do treinador (procurem por coach na literatura). Como somos um time, quem está no papel do treinador no momento é quem forma a equipe, cada um com as características necessárias para chegar aos objetivos da partida. É o treinador que elabora a estratégia de jogo e discute ela com a equipe pare que estes entendam antes da partida. Ele mantém o foco em uma visão global enquanto todos estão jogando e indica aonde mudar e melhorar.
E cada um tem seu papel, igualmente importante. Tomar decisões em equipe, se ajudarem, se comunicarem, afinal o jogo é cooperativo e só assim todos podem ganhar juntos.
Desta forma, cada um na equipe interage uns com os outros e com o treinador, para melhorar as estratégias, antes, durante e depois do jogo. Afinal uma equipe vence junta ou perde junta, e é apenas com essa colaboração e espírito de equipe que o time pode alcançar seus objetivos.
Bem, depois desta discussão, faço-lhes um pergunta típica minha: "Quem é seu chefe?"

Quality Saturday

2009-03-19T12:21:00.002-03:00

Olá Pessoal,

A Intacto em conjunto com a Cjr está organizando no dia 28/03/2009 uma tarde para conversarmos sobre qualidade de software.

Não conhece? Venha conhecer.

Não está encontrando ? Venha encontrar.

Praticas ? Venha trocar idéias.

Inscrições gratuitas e informações no site www.cjr.org.br/qualitysaturday.

Divulgação

2008-06-25T12:00:00.003-03:00

Olá,

Já faz um tempo que não atualizo. Mas isso é por que decidi escrever melhor antes de publicar. Uma boa prática de fato. Juntamente gostaria de agradecer aos comentários do último post, e eles serão de grande valia para o que está por vir.

Bem, dando uma interrupção para divulgar um outro blog. A um bom tempo sou leitor do efetividade.net , sempre tem artigos interessantes, principalmente na área de TI (apesar de termos artigos de cunho geral), mas segue a divulgação do site:

Ajude a sustentar a Wikipédia e outros projetos, sem colocar a mão no bolso, e concorra a um Eee PC!

…e também a pen drives, card drives, camisetas geeks, livros e mais! O BR-Linux e o Efetividade lançaram uma campanha para ajudar a Wikimedia Foundation e outros mantenedores de projetos que usamos no dia-a-dia on-line. Se você puder doar diretamente, ou contribuir de outra forma, são sempre melhores opções. Mas se não puder, veja as regras da promoção e participe - quanto mais divulgação, maior será a doação do BR-Linux e do Efetividade, e você ainda concorre a diversos brindes!

Att

Quem conta um Ponto, Aumenta um Conto

2008-06-03T07:41:00.002-03:00

Bem, hoje o assunto é ponto de função, e como tem se tornado nos poucos post, começarei com uma historinha minha dentro da área.

Eu estudo ponto de função a 2 anos. Do início dos meus estudos em PF até começarmos a utilizar esta técnica na empresa foram 2 meses. Antes do ponto de função, nossa estimativa era bastante empírica, utilizávamos nossa experiência e estimávamos no "olhômetro" cada funcionalidade ou caso de uso do sistema. Nem preciso dizer que em 2 anos, após começar a utilizar o PF já temos uma pequena base histórica da nossa produtividade, nossas taxas de erros de previsão e diversos fatores que influenciam em nossos projetos. O que vale ressaltar aqui é que com as informações desta base de dados, juntamente com a experiência adquirida, hoje nos é possível prever e orçar com muito mais certeza um projeto.

Mas não foi pra ficar falando dos benefícios da APF que eu vim discutir hoje, meu ponto hoje é o papel e o uso da APF no mercado hoje em dia. Desde que iniciei os meus estudos neste assunto, uma metáfora sempre ficou na minha cabeça e sempre a tomei como a melhor forma de explicar "o que é ponto de função", a metáfora da casa e o metro quadrado: "O Ponto de Função é o metro quadrado do software. Posso lhe dizer que existe uma casa de 200 m² e isso lhe dará uma boa noção do tamanho desta casa, porém isto não lhe dará informações sobre custo ou esforço desprendido na construção desta casa, afinal ela pode ter piso de mármore e torneiras folheadas a ouro ou ser feita de materiais mais comuns, ela pode ter sido construída em um bairro de classe média próximo ao centro da cidade ou no alto de um penhasco." (Coloquei entre aspas pois não me lembro onde ouvi esta história, nem achei a fonte)
Coloquei em destaque o que mais me marcou desta história, é que o ponto de função não lhe determina o esforço, nem o custo do seu projeto.

Bem, fazendo uma pequena pausa, vamos ao que me inspirou a este post. Na minha empresa, hoje temos uma noção de quanto temos capacidade de desenvolver, temos inclusive alguns números que envolvem nossa produtividade em PF. Na semana anterior nos veio um cliente e durante nossa reunião questionou quanto nossa fábrica era capaz de produzir em PF/mês, e prontamente informamos os dados que temos. Neste ponto o cliente nos perguntou quanto tempo demoraríamos para absorver uma demanda maior, informávamos que dependia do tamanho da demanda e de como planejaríamos este aumento. Bem o cliente gostou dos números, saiu satisfeito e espero que tenhamos um bom negócio. Porém ao sair da reunião algo me incomodava, e fiquei meditando no assunto. O que me incomodou foi o fato de termos tratado PF como uma unidade "padrão", como se minha fábrica de software produzisse "balinhas" e eu dissesse que produzo X balinhas por mês e se você quer uma produção de 3X basta eu comprar mais maquinário. Meu problema é que eu não produzo "balinha", o problema que eu enxerguei (e que me causou desconforto) foi que tratamos PF como "balinhas", desconsiderando o fato que o custo de 1 PF é bastante distinto de um sistema para outro.

É importante ressaltar esta questão, pois isto nos volta ao que serve o PF (nosso m²). Pois imagine você que alguém lhe diga que tem um sistema de 2000PF para ser desenvolvido, lhe pede um prazo e custo sem mais informações. É impossível determinar, afinal podemos ter um imenso sistema CRUD, ou mesmo termos um sistema de simulação aeroespacial, que terão esforços por PF bastante distintos. Eu compreendo que nós, que cuidamos de muitas equipes, precisamos de alguns números para nos auxiliar em planejamento e a acompanhar o andamento dos projetos. Minha crítica aqui vem de utilizarmos estes números sem critérios, afinal falarmos em produtividade sem noção do negócio do cliente é, no mínimo, voltarmos a técnica do "chutômetro", agora porém, com números.

Let's Agile UP

2008-05-29T20:13:00.003-03:00

Então finalmente eu fui pro lado Agile da força. Na verdade isso era inevitável, só faltava o impulso final para decolar. Mas antes, vale contar a história.

Em novembro do ano passado foi-me atribuída os cargos de Diretor de TI e Diretor de GQ (Garantia de Qualidade) dentro da Intacto. Abrindo um parêntese, para quem não sabe a Intacto é a empresa da qual faço parte e sou sócio fundador a mais de 3 anos. Por trás destes nomes pomposos estava embutida duas vontades da empresa: Primeiramente, formalizar e aprimorar o controle sobre o processo de desenvolvimento nas duas principais áreas da empresa (Fábrica de Sofware e TV Digital) e aumentar a qualidade dos produtos gerados pela empresa. Sob esta responsabilidade (juntamente com a liderança de um grande projeto que estava à meu encargo) tivemos o início da implantação de algumas políticas de controle dentro da empresa. Estas políticas foram benéficas e trouxeram um maior grau de controle para os líderes dos projetos, e uma maior visibilidade dos mesmos para toda a equipe. Juntamente tomamos medidas para a criação de uma base de conhecimento afim de consolidarmos as lições aprendidas nos projetos, bem como os treinamentos, cursos e workshops desenvolvidos dentro da empresa. Enfim, trabalhamos muito e tivemos um bom resultado.

Porém, nem tudo estava bem, desde sempre faltava algo. Todos sabíamos o que estávamos fazendo, os porquês, e agora tínhamos uma maior visibilidade disso. Mas faltava algo para unir tudo isso, e este algo nos foi interpretado pela formalização do nosso processo de desenvolvimento. Desde a fundação da empresa, devido a nossa formação acadêmica, temos seguido um processo bastante similar ao RUP, sempre foi uma intenção a formalização e documentação do nosso próprio processo. Porém devido a sermos uma equipe pequena e em contante evolução, nossos esforços acabavam por não tendo frutos junto aos documentos gerados. Bem, desde que foi lançado o OpenUP este me agradou bastante. Sua estrutura simples e leve, bastante focada em produtos rápidos me atraiu bastante. Acredito que esse foi meu primeiro passo efetivo dentro do mundo Agile.

Bem, desde o início deste ano a empresa se encontra em um bom ritmo de crescimento. Nossa equipe mais experiente se mantém, gerando bons resultados, os novos colaboradores foram se adaptando bem ao ambiente, e as ferramentas utilizadas se mostraram de grande valia. Porém neste cenário, agora mais maduros e com um esboço de processo em andamento, não nos é mais permitido adiar a formalização de nossas práticas. Então, à um mês me foi atribuída esta tarefa, minha primeira reação foi retomar meus estudos do OpenUP e juntar com o conhecimento que nos tinha sido gerado dentro da empresa. Até momento está indo muito bem estas definições, e minha crença é que teremos uma versão beta para ser apresentada a equipe no próximo mês e espero bons resultados.

Mas depois de tudo que foi dito, você se pergunta : "Onde diabos tem Agile nessa história ?". E aí que vem o complemento a tudo isso. No início desta última definição estava eu tentando fazer o que qualquer pessoa vidrada e sem noção da realidade faria ao começar a ler sobre processos. Me vi escrevendo checklists, modelos de documentos, e em pouco tempo me vi desanimado na tarefa que me foi dada. Não me parecia certo tudo o que estava fazendo, parecia que eu ia colocar pesos de chumbo no encalço de uma equipe que sempre respondeu satisfatoriamente. Já faz um bom tempo que leio sobre Agile e processos de desenvolvimento em listas e blogs e nos últimos tempos o números de cases de sucesso vem aparecendo de forma crescente. Por causa destes cases tive uma certa afinidade com o Scrum. E como dito anteriormente só me faltava um estalo para que toda essa sopa de informação começasse a fazer sentido. Este estalo acabou me vindo com o post do Guilherme Chapiewski veio a inspiração que faltava. Desta inspiração me surgiu 2 vontades: Primeiro em finalizar uma versão light do nosso processo, formalizando o que fazemos hoje e aprimorando o já é feito. E em segundo que eu queria experimentar o Scrum na empresa.
Para a primeira vontade foi fácil, fiz um post no grupo Agile-Brasil onde me foram dadas as dicas para juntar o OpenUP e o Scrum. E para a segunda vontade basta aguardar um pouco. Atualmente me encontro no fim de um projeto e iminência de alguns novos, por tanto tenho tempo de estudar, me preparar um pouco melhor e preparar minha equipe para colocarmos o Scrum em prática no próximo projeto. Minha idéia é fazê-lo por partes, primeiro tentarei estabelecer o conceito de Sprint e de Daily Meeting. Vamos com calma para que todos possam ir engolindo em pequenas doses, e assim possamos apertar nossos parafusos com o tempo.

Bem é isso, post grande e bem próximo do anterior (essa nem eu esperava). Mas tem sido dias de bastante animação. Quando as coisas funcionam e parecem estar nos eixos, nossas espectativas sobem e nos enchem de esperanças e vontade de trabalhar.
E é por isso que digo :

"Let's Agile UP"

Unbiquitous

2008-05-27T21:36:00.003-03:00

Opa, mal criei o blog e ela já ficou meio empoeirado.

Para iniciar as postagens oficiais do blog, vou falar um pouco das pesquisas das quais faço parte no meu mestrado na Universidade de Brasilia.
Desde o início de 2007 temos um grupo na Universidade chamado UnBiquitous. O Grupo foi fundado por 2 Doutores, 1 Mestre, 1 Aluno especial (Na época eu) e 2 alunos de graduação. Na época acabávamos de ter nossa primeira publicação na universidade na área de computação ubíqua, decorrente do trabalho realizado pelo (então recém) Mestre Alexandre Gomes.

O trabalho produzido pelo Alê foi a construção de um middleware para disponibilidade de serviços em ambientes ubíquos. Nome complexo e pomposo, mas resumidamente foi a construção de um software que permita que diversos dispositivos presentes em um ambiente possam compartilhar recursos entre si de forma fácil e simplificada. Desta forma eu poderia facilmente utilizar o teclado do meu celular pra digitar um email na tela da minha televisão.
Foi a apresentação do trabalho do Alê que me trouxe para este meio "ubíquo". Desde então fundamos o grupo de pesquisa e dedicamos nossos primeiros 4 meses pesquisando o que havia acerca do assunto e definindo nossos objetivos dentro do mundo ubíquo.

Na área de computação ubíqua existem diversos projetos, muitos deles se destacam, principalmente pelo apelo comercial que a idéia teve no mercado de dispositivos móveis. Nosso primeiro desafio antes de definir nossos objetivos foi definir quais características escolheríamos para determinar que tal assunto era ubíquo (visto que as intersecções com outras área é extremamente vasta) por isso nos atentamos a duas características:

Capacidade de se Comunicar: Nada pode ser ubíquo sem poder conversar antes com o universo a sua volta. Assim sendo, nossa pesquisa teve que se voltar para meios que facilitassem, assegurassem, ou viabilizassem a comunicação entre aplicações e dispositivos, de preferência sem amarrações a linguagens, tecnologia ou hardware.

Ser pervasivo: Aqui a palavra pervasivo se refere fortemente ao conceito explicitado por Mark Weiser em seu artigo "Design Calm Technology" acerca da periferia da sua atenção. Neste Sentido, nossos estudo devem buscar trazer a tecnologia para um uso tão natural do ser humano que apenas a utilidade fique e não o meio que a viabiliza.

Sob estas duas premissas foi possível diferenciar nosso foco e nossos objetivos de outros grupos de estudos espalhados mundo afora. Como o grupo foi formado após a Tese de Mestrado que trouxe o UnbiquitOS à vida, e devido a sua proposta especial perante outros middlewares, o UbiquitOS serviu de base para definirmos os próximos passos. Sob ele delineamos diversas áreas a serem estudadas, dentre elas :

Perfil : Adaptabilidade e estabelecimento de perfis de usuário
Infra-Estrutura : Capacidade de acessar diversos tipos de Redes (Lógicas e de Enlace)
Segurança : Garantia da capacidade de assegurarmos a autenticidade de um dispositivo e de seus dados.

Existem outros áreas, mas fica para um post mais específico falar sobre cada uma delas. Em cima da áreas foram divididos vários grupos específicos para se dedicarem as mesmas. Neste ponto o grupo cresceu de 6 para por volta de 45 pessoas, este acréscimo de pessoal trouxe um grande encargo de gerência, mas trouxe ânimo para continuarmos o desenvolvimento da idéia.
Hoje estou a cargo do u-redes, grupo responsável pela parte infra-estrutura do projeto. Neste grupo temos hoje 3 projetos em andamento sendo um deles minha tese de mestrado, somos no grupo 4 pessoas, maiores detalhes ficam para um post futuro

Primeirão

2008-05-16T18:02:00.000-03:00

Então,

Não sei se terei leitores. Da mesma forma não sei se este blog alcançará seus objetivos. Mas depois de muito tempo lendo o que existe na blogosfera e participando de algumas listas, decidi divulgar algo que sei, ou que acho que sei, ou de que nada sei.
Primeiro vamos aos motivos deste blog. Bem, a idéia me surgiu pois leio bastante sobre diversas áreas do desenvolvimento de software (Gerência de Projetos, Testes, Análise de Requisitos, Java, Ruby, etc) , do conhecimento e das artes (Tecnologia, Ciência, Cinema, Animação Japonesa, etc) e do meio acadêmico (Computação, Algorítimos, Redes, Computação Ubíqüa, etc). Bem dentro de tudo isso, eu participo de diversos grupos de discussão, no mestrado participo de um bom grupo de pesquisa, na minha empresa tenho canal aberto de comunicação com todos os setores, ainda organizo eventos de animação japonesa.
Bem, dentro de todo esse ambiente onde o conhecimento flui, as vezes é bom consolidarmos as idéias de maneira escrita. Essa é uma das minhas maiores dificuldades. Por hora escrevo mal. Portanto, aí está o objetivo número 1:

Objetivo Número 1 : "Expressar melhor as idéias, em especial de forma escrita"

Afinal, quem é GP tem que se comunicar, e normalmente isso será feito de maneira escrita. Melhorar este ponto fraco será de grande valia.
Outro ponto fraco é minha capacidade de produzir conhecimento. Temos na empresa implementada uma filosofia, e uma política associada, de transferência de conhecimento entre todos os membros do nosso corpo de colaboradores. Hora, a gente estuda, lê e vivencia tanto que acaba que não dá valor pra isso. Portanto, passar isso pra frente é o objetivo número 2 :

Objetivo Número 2 : "Transferir o conhecimento adquirido, e obter o feedback do mesmo, aprimorando assim o que se sabe, ou se acha que sabe"

Afinal, a gente não sabe tudo, escrever aqui o que sei, obter o feedback de eventuais leitores para corrigir os erros, e aprender mais sobre os assuntos expressados.
Este feedback nos leva a construção do próximo objetivo :

Objetivo Número 3 : "Expressar idéias acerca dos assuntos de interesse, e obter as idéias de outros"

Por diversas vezes tenho idéias que quero expressar sobre determinados assuntos, e por estas idéias não caberem em um lugar formal (como uma base de conhecimento ou um grupo de pesquisa). Agora terei um espaço pra poder expressar estas idéias.
Por último, algumas destas idéias eu quero que dêem sucesso, quero que as pessoas as conheçam e que opinem, ajudem. E assim leva ao último objetivo do blog :

Objetivo Número 4 : "Divulgar os projetos pessoais e obter o feedback acerca destes".

Bem, acredito que seja isso. São muitos objetivos para apenas um blog. Talvez a falta de foco atrapalhe, mas como uma primeira experiência, espero que traga um crescimento e que alguns destes objetivos sejam alcançados.

Grato a quem ler