Esse mês uma edição especial do encontro promoveu um dia do evento Geeks On a Plane (Edição Especial). Um oportunidade única para conhecer essa pujante comunidade.

Plenária

Bem humorado, de chinelo e fugindo dos caçadores de investimento o criador e gestor da 500Startups, Dave McClure fez uma apresentação impecável mostrando como atualmente é possível criar uma empresa com pouco dinheiro, em pouco tempo e o que é importante nesse novo cenário.

Skype

O fundador do Skype, Niklas Zennstrõm, esteve no evento contando sua história. Como ele deixou um emprego estável para empreender, como seu empreendimento foi recusado por investidores e todo o esforço que foi construir a empresa, além da dificuldade de como fundador aceitar a venda da empresa.

Painel de Investidores

Carlos Pessoa - Wayra Brazil: aceleradora do grupo Telefonica/Vivo

Eric Acher - Monashees Capital: fundo de investimento “semente” (investimentos muito cedo). Investiu na Baby, Boo-box, Peixe Urbano, Mindlabs

Anderson Thees - Redpoint: novo fundo de investimentos no Brasil com participação da BVCapital

Antoine Colaco – Valor Capital Group: também é novo e tem presença em SV e NY

Bedy Yang - 500 Startups: incubadora e fundo “semente”. Investiu em 7 empresas nos últimos 7 meses

Os principais pontos discutidos no meu entendimento foram:

• É o melhor momento para investimentos e empreender no Brasil em muito tempo. Contudo, por haver dinheiro na mesa eles têm visto pessoas que não são empreendedoras de verdade, do fundo do coração, tentando se aproveitar e isso está dando trabalho para eles;
• A Bedy Yang lembrou que existe uma série de empreendimentos fora do Rio e de São Paulo que valem muito a pena.
• Enxergam com naturalidade os empreendedores que iniciam com um “cópia” de uma idéia. Desde que o empreendedor empreenda de verdade. O mais importante é executar a idéia, original ou não.
• Há muito mercado para startups B2B, não é o foco de nenhum dos investidores no painel que são focados em B2C, mas, há.
• Incubadoras e aceleradoras estão começando a funcionar no Brasil e têm muitos desafios pela frente. Estamos nos anos 70 do Silicon Valley.

Country Managers

No painel com Country Managers do QuinStreet, Airbnb, SurveyMonkey e Foursquare eu particularmente achei interessante que somente do SurveyMonkey era brasileiro. Todos os demais eram estrangeiros e pelas resposta me pareceu que em negócios globais o mais importante é o executivo estar alinhado com a cultura e estratégia do negócio do que necessariamente conhecer as características locais. Me pareceu que os executivos estrangeiros entenderam bem o Brasil, talvez seja mais fácil aprender a cultura local do que a cultura da empresa. Interessante!

Dicas de Startups

Etsy, National Geographic, PicCollage e SendGrid trouxeram dicas muito interessantes em apresentações de 10 minutos. Todas foram ao redor dos conceitos de Lean Startup com muito feedback dos usuários, adaptações e aprendizado.

Magazine Luiza

O Magazine Luiza mostrou como é possível inovar e empreender em uma empresa tradicional. Achei particularmente fascinante o MagazineVocê, uma plataforma de ecommerce realmente inovadora.

Constitui-se na reflexão em busca de uma resposta através do mais adequado conselho ou de forma mais complexa, porém menos objetiva, de um parecer.

Mentoring

A tutoria também chamada de mentoring é um método muito utilizado para efectivar uma interacção pedagógica.

Coaching

Coaching é um processo, com início, meio e fim, definido em comum acordo entre o coach (profissional) e o coachee (cliente) de acordo com a meta desejada pelo cliente, onde o coach apoia o cliente na busca de realizar metas de curto, médio e longo prazo, através da identificação e uso das próprias competências desenvolvidas, como também do reconhecimento e superação de suas fragilidades.

Definições feitas (por Wikipedia) vamos explicar o título: tive a grata oportunidade de trabalhar com as três formas de apoio ao desenvolvimento de um projeto ou meta, pessoal ou coporativamente, em situações onde considero ter havido sucesso e outras que foram um fracasso. Resolvi então pensar um pouco nas características de cada situação e identificar o denominador comum a elas que define, ou não, o sucesso e fracasso.

Compromisso & Resultado

Técnica, didática e conhecimento são muito relevantes e precisam ser cuidadosamente analisados quando se deseja trabalhar com um consultor, coach ou mentor. Contudo, todas essas características ficam muito atrás de duas que identifiquei serem as peças chave de um bom trabalho:

• Compromisso: o compromisso não é algo superficial, sua própria definição denota uma opção pessoal vinculada por vontade própria. Sendo assim o compromisso do profissional (consultor/coach/mentor) com sua organização e objetivo, deve ser algo acima de seus próprios interesses, não tem discussão! E isso está cada vez mais raro de se encontrar. Apesar de ser difícil de mensurar sua existência é muito fácil identificar sua falta, basta se perguntar algumas vezes qual a motivação por trás de cada declaração e observar a próxima característica:
• Resultado: Qual o impacto do seu sucesso ou fracasso na vida do consultor/coach/mentor? Se for simplesmente ou novo contrato ou aditivo então você tem um grande problema, seu resultado não faz diferença para ele, sendo assim é muito fácil, cômodo e provável que você esteja na verdade lançado a própria sorte.
  É claro que na prática seus resultados dependem só de você, mas observe que o impacto sobre os outros é que vão determinar o interesse e a participação deles nos seus.

E por que não acredito nisso tudo? Na verdade não acredito (mais) na crescente onda de consultores/coachs/mentores profissionais que estudam meia dúzia de coisas sobre o assunto e são vendidos como a solução dos problemas, sejam eles quais forem.

Acredito sim, e tive experiências que comprovaram isso, que as melhores oportunidades de usar esse apoio estão na sua própria empresa, ao seu lado.
Pessoas que são impactadas pelo seu resultado, que tem interesse pessoal legítimo no seu desenvolvimento porque terão benefícios nisso (seja realização pessoal ou mais fortemente financeiro e de carreira) tendem a ser os mais indicados.

Em início de carreira ou não aproveite a oportunidade que tiver para identificar seu mentor, coach ou até mesmo consultor e na prática não tenha um, tenha vários desde que cada um tenha compromisso com seu desenvolvimento e que seus resultados tenham algum impacto no próprio resultado deles. Só assim será possível confiar no que eles estão lhe oferecendo. Um pequeno exemplo:

Steve foi um mentor e líder incrível para mim

Tim Cook – Apple

@dbouwman: Some zen slides and passionate delivery at the NoSQL session… Good things! #DevSummit

O código está disponível no Github!

O primeiro dia do encontro de desenvolvedores ESRI foi um dia agitado com muito conteúdo importante e uma plenária dando uma visão importantíssima para todos que trabalham com a tecnologia. Se puder assista a plenária ou fique com meu resumo do dia:

• Com uma API com 900 tipos públicos (expostos), algumas dezenas sendo adicionadas na versão 10.1 a ESRI explica que se trata de uma complexidade necessária para as muitas funcionalidades da plataforma mas reconhece que pode simplificar as coisas, por isso está criando um modelo de objetos mais flat que encapsule parte da complexidade para as operações cotidianas. Essa API não terá os desvios causados pela opção de arquitetura COM atualmente utilizada.
• Uma nova opção de API para desenvolvimento – ArcGIS Runtime – promete muito não exigindo nem mesmo a instalação (roda de um pen-drive) e permitindo a distribuição apenas de módulos específicos (core, geocoding, etc.). Uma boa introdução pode ser vista aqui;
• O suporte 64 bits está no centro de uma revolução de performance que começa nos produtos de servidor e vai parar no desktop. Já imaginou conseguir fazer cálculo de driving distance on the fly? Foi demonstrado com uma base de dados de 4 milhões de registros;
• As APIs nativas para aplicações móveis já incluem Android, Windows Phone7 e iOS com capacidades de edição e com suporte planejado para roteirização e muito mais até Novembro desse ano;
• Anunciando um roadmap agressivo de novas funcionalidade com tempos de release muito mais curtos do que o normal, a ESRI também revisitou seu programa BETA tornando-o um programa continuado. Visite o novo site e se inscreva;
• Adeus SOCs, SOMs e outras características de arquitetura baseadas em DCOM atualmente existentes. Conheça em breve a nova arquitetura totalmente baseada em REST em um Webserver HTTP com todos os seus benefícios de escalabilidade, performance e muito mais;
• Conheça e use o novo gis.stackexchange.com.

Code for America

O destaque do dia vai para a apresentação do Code for America, uma iniciativa (e apresentação) do Tim O’Reilly da O’Reilly Media que propõe-se a resolver os problemas das cidades americanas através de iniciativas de desenvolvimento de software.

A proposta é baseada nos seguintes fatos:

• 84% das cidades norte americanas estão com problemas financeiros;
• A administração pública tem um sistema de contratação ineficiente;
• A administração pública tem silos de tecnologia que afastam a inovação;
• Os talentos não são atraídos para atuar na administração pública.

A partir de uma análise de que essa geração é a mais voltada para a administração pública (não é política, é administração!) de todos os tempos e que isso é uma tremenda oportunidade para aumentar a eficiência e performance da administração pública o objetivo da entidade suportada por grandes empresas é justamente endereçar essas questões.

A visão do Oreilly é bastante pragmática colocando na verdade o governo como uma plataforma que irá impulsionar os próprios cidadãos.

@shoshe: Why is @timoreilly interested in OpenGov? Because he believes govt ought to be a platform. Let citizens do more together #Esri #DevSummit

Essa plataforma é sobre a WEB Social e Dados Abertos que poderão mudar a cidadania.

É impressionante o que essa visão pode fazer e a profundidade que ela tem no desdobramento da administração pública como, espero, possamos ver em alguns anos.

Alguns projetos desenvolvidos dentro da organização:

• http://seaapi.com/
• http://hearnear.org/
• http://septa.mobi/
• http://phillyapi.com/
• http://adopt-a-hydrant.heroku.com/

Considerando que os fatos que impulsionam a iniciativa estão também no Brasil pergunto: será que é possível replicar a iniciativa?

Hoje a ESRI demonstrou uma capacidade de adaptação e mudança impressionante. Para uma empresa de mais de 40 anos ainda liderada pelo fundador e com boa parte de seus precursores na ativa a empresa se posicionou como uma empresa jovem e completamente fiel a uma visão profunda de um mundo melhor através do GIS.

Uma imagem vale mais do que mil palavras. Minhas fotos estão bem ruins (Xperia X10 tem boa resolução mas péssimo foco) mas vou usá-las aqui. Para um set de fotos mais profissional veja o feed oficial.

O que mais chamou a atenção foi o formato da plenária. Com puffs, sofas, mesas, poltronas de diversos formatos e arquibancada o conceito foi criar uma sala de estar. Palco no centro e na frente, muitas TVs para ninguém perder os detalhes além de comida e bebida disponível o tempo todo. Minha primeira reação foi (uma analogia ao Google Developer Day em que eu esperava mais):

Holy cow … Google could learn with ESRI how to do a plenary #epcps

Além disso tudo o conteúdo foi pensado para os mais diferentes objetivos dos participantes: técnicos, comerciais, parceiros, distribuidores. As mídias sociais estavam muito presentes, inclusive com um sinal luminos bastante claro para todos quando o assunto era restrito ao público (que respeitou solenemente o pedido de confidencialidade em determinados assuntos).

A ênfase o tempo todo foi na importância do relacionamento da empresa com seu ecossistema e a julgar pelos Twittes (#epcps) conseguiram ganhar muitos corações. Vários parceiros no mundo todo foram convidados a falar o que contribuiu com diversas visões diferentes. O prêmio de parceiro do ano foi para a 3-GIS, realmente merecido pela conversa que já tive com eles.

O dia todo trouxe muitos insights sobre o GIS mudando o mundo direcionada na abertura pelo Jack Dangermond:

We need to design a world for 9 billion …

Para não correr o risco de desrespeitar a luz vermelha da confidencialidade prefiro deixar para o leitor interessado a sugestão de uma rápida revisão dos twittes que pontuaram em tempo real os vários momentos AHA. (#epcps)

Fica a sugestão para todos que trabalham com tecnologia ESRI por ai: venham ao Business Partner (primeiro seja um) e fiquem para o Developer Summit. É um atalho para anos e anos de esforço em negócios e tecnologia.

O objetivo do evento foi compartilhar com parceiros e distribuidores um pouco das estratégias e conhecimento adquirido com muito esforço e empenho de marketing que a empresa tem feito consistentemente e a trouxe onde ela está, dessa forma é bom parar e ouvir um pouco o que eles tem pra dizer, vamos ao resumo do dia:

Plano de Marketing

Tema bastante conhecido que com exemplos, histórias e indicadores foi debatido no sentido de ressaltar:

• Independente do tamanho da empresa, há benefícios no desenvolvimento de um plano de marketing;
• Desenvolver um plano de marketing economiza tempo e dinheiro no longo prazo;
• Nem todas as atividades de marketing são caras, muitas são gratuitas.

Estratégias para Mídia Social

Foi uma seção bastante prática (por isso não posso dar detalhes) com a participação especial Pedro Torres da ESRI Espanha e Peter Eredics (o GIS_Forester). A principal mensagem foi:

Social Media Strategy @esri #epcps : Make it social – listen, inform, share, impact, engage – your website is not enough

Outros pontos importantes foram:

• É muito fácil fazer mal feito. Mídias Sociais exigem esforço, empenho e constância;
• É tudo sobre CONTEÚDO;
• Ok, também é tudo sobre pessoas, é o P2P de Pessoas pra Pessoas;
• Sua vantagem competitiva está no capital humano;
• Uma boa estratégia foi ter personas diferentes para a empresa e para o profissional, são interesses que se complementam na relação social das mídias sociais. A primeira trata assuntos do mercado e a segunda dos profissionais;
• Conheça seu público, incluindo dia e hora que interagem com você.

A dica do dia foi: comece pelo LinkedIn, é a rede mais fácil para começar.

Alguns recursos sociais usados pela ESRI:

• @ESRI
• facebook.com/Esrigis
• linkedin.com/companies/5311
• esri.com/blogs
• flickr.com/photos/Esri
• youtube.com/Esritv

ThoughtLeadership

O conceito é bastante simples:

Um thought leader é um líder reconhecido em seu mercado. O que diferencia o thought leader de um conhecedor do mercado é o reconhecimento externo de seu profundo entendimento do negócio, as necessidades do mercado e suas correlações.

Trata-se de construir uma visão do futuro e moldar o pensamento do mesmo!

O fundador e atual presidente da empresa, Jack Dangermond, é por definição um Thought Leader, um visionário que teve uma participação muito especial na própria criação do mercado GIS mas se dependesse apenas dele não seria possível cobrir tantas áreas onde a ESRI hoje atua. Dessa forma a ESRI criou um processo bastante completo endereçando desde a identificação do líder adequado até a criação de produtos sustentados por essa liderança passando pelo dia a dia dessa importante ferramenta de marketing.

A apresentação foi feita por Bill Davenhall e Chris Thomas, pensadores a frente da geomedicina e e-gov na ESRI. Observe que o próprio termo geomedicina com 33.000 resultados no Google foi cunhado dentro do processo de ThoughtLeadership da ESRI e hoje há toda uma discussão sobre o assunto que transcede a própria ESRI. Algumas lições aprendidas:

• Para definir-se como um Thought Leader é preciso estar preparado para um novo emprego, não é uma atuação parcial. Prepare-se para ter uma vida pública, ser exposto a críticas e oposições das mais diversas a sua opinião;
• A liderança é toda construída sobre o envolvimento e comprometimento (engagement) com as pessoas e comunidades envolvidas, não existe liderança sem envolvimento – portas abertas para o mundo em todos os instantes;
• Prepare-se para defender suas idéias o tempo todo, comece dentro da sua própria empresa;
• Há um indicador importante a ser medido: quantos convites o líder recebe para palestrar, dar entrevistas (rádio, televisão), participar de análises de mercado, etc.?
• As ferramentas de trabalho passam a ser: blogs, twitter, livros (escrevê-los!), facebook, fóruns, eventos, etc.

Por hoje é só!

• Autoritarismo;
• Micro-gerenciamento;
• Desrespeito as particularidades das pessoas;
• Falta de clareza e da própria comunicação;
• Falta de metas;
• Falta de reconhecimento (inclusive financeiro);
• Falta de ferramentas adequadas de trabalho;
• Ambiente de trabalho pesado;
• Processos pesados e burocráticos;

Note que alguns desses exemplos são igualmente nocivos em qualquer ambiente não mecânico de prestação de serviço (não necessariamente desenvolvimento de software)  que é baseado em pessoas, como firmas de advocacia, consultoria, etc.

Agora uma lista do que é considerado o contrário dos itens acima e também boas práticas:

• Gestão participativa;
• Empowerement;
• Reconhecimento e Meritocracia;
• Respeito;
• Ambiente de trabalho agradável;
• Processos ágeis.

Agora vamos a verdade nua e crua: Cara Pálida, o contrário das más práticas são boas práticas mas só funciona se for honesto, sincero e fizer parte da sua cultura. Já falamos de cultura e volto a repetir: ela exige comprometimento e gestão ativa! E sim cara pálida, ela é sua responsabilidade e não dos seus colaboradores.

Ao descobrir que atuam no primeiro grupo de bullets tenho visto empresas saírem correndo para adotar o segundo grupo sem realmente meditar realmente no que isso significa e representa de impacto em sua própria atuação junto a clientes, parceiros e colaboradores.

Alguns interpretações equivocadas que tenho visto:

Gestão Participativa

Está claro que a visão e estratégia é responsabilidade da direção da empresa? (porque será que chamamos de direção?)

É errado delegar a visão e estratégia e isso só serve para postegar o inevitável fracasso (e se enganar que a culpa não foi da direção).

Gestão Participativa é diferente de democracia. Quantos de nós vivemos uma democracia (sim, o Brasil é uma) sem participar? Pois é, votar não significa participar e tem empresa que acha que colocar tudo em votação é participativo. Não é! Participativo é influenciar, instigar, mudar o rumo, opinar, discutir, ser ouvido.

Empowerement

Todo mundo quer ter autonomia e se superar, mas faz parte da atribuição do gestor ter o discernimento (e bom senso) do que, quando e como. Como gestor você é responsável pelo sucesso da sua equipe e expor as pessoas sem considerar o momento de suas vidas (experiência, maturidade, capacidade) é irresponsabilidade.

Empowerement é diferente de delegar a sua responsabilidade. Está muito mais para motivar, inspirar, confiar e suportar.

Reconhecimento e Meritocracia

Responda rápido: quais os valores da sua equipe? Porque motivos as pessoas trabalham com você? Quais as razões que a levam indicar sua empresa?

De novo: existe uma cultura? Uma estratégia? Sem isso cada funcionário terá seu próprio valor, não haverá uma identificação entre eles e sua empresa e cada um estará buscando uma realização diferente.

Se você não fugiu das aulas de física sabe que os vetores quando dispersos anulam-se e perdem força. É o mesmo com sua equipe: tentar endereçar todas as expectativas individuais sem um direcionamento tem o efeito contrário: gera insegurança, sentimento de favorecimento, descontentamento e além disso aumenta o custo e risco da empresa sem gerar uma gota sequer de alívio no longo prazo (seu turnover não vai melhorar não).

Respeito

Ser educado, não xingar, não gritar … é o mínimo. O respeito que esperamos, como tudo na vida, está nos detalhes: horários respeitados (inclusive de início e término de reuniões), atenção devida ao interlocutor (e não concorrente com outras pessoas, blackberry, email, etc.) , compromissos cumpridos, respeito as diferenças (religião, sexo, cultura).

Ambiente de Trabalho

Na ânsia de criar um ambiente de trabalho agradável tenho visto uma tentativa desenfreada de criar uma casa. Bem, é um ambiente de trabalho, isso significa que os valores ali são participação, comunicação e grupo, não propriedade privada, privacidade (embora deva haver uma preocupação e respeito com a privacidade, esse não é O valor do ambiente de trabalho) ou liberalidade.

Processos Ágeis

Esse é fácil. Já falei da flexibilidade que atrapalha e vale reforçar que o importante na agilidade são os valores e não as práticas embora sem elas você não consiga ser ágil.

A mensagem importante aqui é: There is no silver bulltet!  Mais uma vez, a responsabilidade do sucesso é sua, não delegue para o processo.

Bem, fica registrado: não há atalho para a mudança. Disciplina, honestidade, sinceridade e muito esforço são necessários, contudo a história comprova: compensa!!!

A aplicação chama-se Audience Drawing (sim, para aprender direito vou internacionalizar a interface) e resolve um probleminha que sempre tenho: sortear em um auditório (ou sala) os brindes levados para serem distribuídos após minha palestra. Sempre invento critérios na hora e até já usei o Ruboto no meu X10 que teve uma boa repercussão, mas uma aplicaçãozinha vai cair bem.

Esse post trata do setup do desenvolvimento, vamos aos detalhes::

• Funcionalidades e versões planejadas e estimadas no excelente PivotalTracker (projeto compartilhado);
• Eclipse IDE (esse eu já tinha, mas fica registrado);
• Android SDK (inclusive com plugin no Eclipse);
• SonyEricsson Android SDK Add-on (só pra ter um skin legalzinho do meu celular);
• Um pacote de ícones gratuitos para Android;
• Git no meu windows (isso, não tinha. Só usava SVN);
• Criar repositório do projeto (compartilhado) no GitHub.

Para registrar, contando com o download e a escrita dessa parte (feita entre downloads), levei 30 minutos para fazer o setup (bastante simples, mas continue lendo …).

Na hora de instalar o Git optei pelo msysGit que é um pacote bem próximo ao TortoiseSVN, mas na hora de usar fiz algumas coisas na mão para aprender. O principal que aprendi foi: o instalador empacota o Cygwin e dá alguns problemas de path, principalmente para achar as chaves de criptografia.

A mensagem “Permission denied (publickey)” significa que você não criou, o git não está achando (problema de path) ou você não configurou o github para reconhecer sua chave. Essa página ajuda e minha dica é: verifique que deve haver uma pasta .ssh na raiz do diretório do usuário mas também deve haver uma pasta .ssh na raiz do diretório de instalação do GIT. Os comandos ssh estão usando na instalação, o GIT está tentando ver no home do usuário. Você pode copiar para o home do usuário ou criar um arquivo config no home do usuário conforme as últimas instruções da troubleshooting.

Vou começar lendo o Fundamentals para não fazer muita besteira. Principais lições:

• Não existe um ponto único de entrada. O Android foi feito para reaproveitar até componentes, isso significa que não há método main;
• Activities são sua camada VIEW;
• Meu sorteio com o Random.org vai ter que ser um Service, quem sabe alguém reaproveita.

Só para lembrar o código está compartilhado aqui!

Alguns anos de investimento, alguns sucessos e insucessos, alguma alegria e frustração depois e a empresa olha para sua equipe de desenvolvimento e fica decepcionada que: a) a equipe está infeliz e desmotivada, b) o sucesso que teve no caminho não está necessariamente ligado aos novos processos, c) o processo não garantiu nada e d) gastou muito dinheiro e não viu a receita aumentar por conta desse dinheiro. Na verdade há um sentimento de perda de agilidade, um descontentamento com a qualidade e uma insegurança tremenda se esse é o caminho correto.

A equipe comercial agora está cobrando mais agilidade, entende que esses processos ajudaram mas não estão sendo percebidos como valor para o cliente que não quer pagar por eles. Alguém ouviu dizer que existe um tal de Agile por ai que é uma beleza, poucas regras, flexível, ágil. Vamos adotá-lo! Agora sim podemos atender ao mercado, pergunte ao cliente o que tem valor para ele e deixe todo o resto de lado.

Aqui começam nossos problemas: o cliente vai responder (a verdade) que para ele os relatórios, controles, evidências, diagramas e outras coisitas não são importantes. Importante mesmo é ele ter o que comprou funcionando na data combinada e pronto!

Com essa resposta em mãos a empresa decide ser ágil e eliminar a documentação, se livrar dos diagramas e relatórios e adotar uma comunicação ágil dessas novas metodologias.

Bem, tenho uma notícia triste: essa é a agilidade que atrapalha!

As metodologias ágeis dão muita liberdade em sua adoção porque são baseadas em valores e princípios.

A empresa que buscar flexibilidade, adequação, dinamismo e agilidade sem conhecer muito bem quais são seus valores irá na verdade voltar ao desenvolvimento ad-hoc e cair em problemas iguais ou piores do que a metodologia anterior.

Os valores e princípios são o que mantém a unidade da empresa, preservam a base do que ela é e não tê-los só garante uma coisa: o fracasso!

O evento foi organizado pela Caelum e InfoQ Brasil (mantido pela Caelum) e contou com a participação de alguns palestrantes internacionais bem conhecidos e muitos locais também muito conhecidos. Na repercussão do evento alguém twittou “A Caelum colocou definitivamente o Brasil no panorama de desenvolvimento mundial” (ou algo assim), embora eu discorde do “colocou” porque temos outros ilustres representantes em diversas áreas, com certeza a Caelum é dos mais ilustres representantes tupiniquins nesse panorama na atualidade.

Vamos ao resumo/lições/mensagens:

• Bons profissionais são disputados: o Paulo twittou que se impressionou com a senioridade dos participantes (era de se esperar dada a senioridade das palestras) e acho que muita gente imaginou que isso ia acontecer pois vi Globo.com, Abril Digital, Boldcron/UOL, Imagem e deve ter tido mais alguém procurando bons profissionais. Apesar das ofertas (a Globo pro Rio estava pagando a mudança, 1 mês de hotel e outros mimos de recolocação não muito comuns no Brasil) acho que ninguém conseguiu muito sucesso.
  O que percebi tentando recrutar por lá é que esses bons profissionais provavelmente estão onde querem estar e a motivação para uma mudança  é muito subjetiva envolvendo muito mais qualidade de vida, questões familiares ou algum desafio técnico do que salário ou carreira. Então além do salário atualmente para recrutar é bom pensar no ambiente de trabalho, desafios técnicos/tecnologia, metodologia (fala que usa RUP lá) e principalmente desenvolvimento profissional.
• Soluções Simples para Problemas Complexos: é impressionante como por trás de atual sopa de letrinhas que temos que lidar no fim das contas as soluções são extremamente simples (arquiteturalmente falando, a implementação é que é o desafio). As palestras do Nick Kallen (Twitter) e Randy Shoup  (eBay) ilustraram isso muito bem, apesar dos números impressionantes de dados e uso dos seus sistemas a solução sempre passa por particionamento, processamento assíncrono e cache.
• Arquitetura emergente: com vários outros nomes a idéia de evolução do sistema de forma natural é realmente aplicada muito antes do batismo de arquitetura emergente. Vimos várias ocorrências (Twitter e eBay inclusive) de grandes sistemas que evoluíram passo a passo e são hoje “exemplos“. Boa lição para os adeptos do BDUF.
• Programe: se você trabalha com desenvolvimento de software, seja em que papel for (arquiteto, analista, gerente, diretor), você precisa programar. Claro que não precisa ser sua principal atividade, mas achar que pode exercer um papel de desenvolvimento sem conhecer (de verdade) os desafios do desenvolvimento (que estão na programação) é utopia.
  Conheço vários bons programadores que ao assumir outro papel (como arquiteto) acabaram se distanciando da programação e hoje são péssimos no que fazem. Atualizar-se em desenvolvimento significa necessariamente programar, codificar!
• Testes, Testes, Testes: Vi algumas palestras incríveis sobre TDD e BDD. Uma máxima do Klaus foi “Não testar hoje é anti-ético” e concordo plenamente com a idéia.
  Hoje mais do que nunca está muito fácil automatizar toda sorte de testes, não há desculpas com as várias ferramentas (gratuitas e pagas) disponíveis. (sugiro pesquisar as opções com JRuby que conheci por lá)
• Cuide da sua vida online: reencontrei diversos conhecidos virtuais de longa data, principalmente do GUJ. Participar ativamente de comunidades, contribuir e tudo mais é muito gratificante e com certeza fará diferença para sua vida profissional.

Tecnicamente há muito mais que aprendi no evento, mas o Twitter e o Slideshare estão cheios desse conteúdo.

Aguardemos os próximos eventos.

Há duas formas de mensurar, estimar e medir tarefas que vemos/aprendemos ao nos aprofundarmos em metodologias ágeis, são o famosos Story Points (Pontos ou Pontos de Estória) e Ideal Time (Tempo Ideal).

Definições

Algumas definições importantes de forma rápida e prática:

1. Desenvolvimento de software é um processo empírico e essa declaração traz toda sorte de implicações como incertezas, variáveis externas, mudanças, maturidade, conhecimento e até mesmo erros que devem ser endereçadas no planejamento (incluindo a estimativa), na execução (o processo de desenvolvimento em si), na entrega (e na forma que essa expectativa é gerada e gerida) e até mesmo no ciclo de vida do seu produto/projeto;
2. Velocidade é capacidade de entrega e só é conhecida pela entrega (histórico) que vai levar em conta o ambiente de trabalho, a maturidade da equipe, a estabilidade dos processos e do ambiente, entre outras questões. O principal ponto aqui é entender e aceitar que não existe uma conta de 8h/dia x 10 profissionais x 10 dias úteis x 0,10% do cafézinho = produção de 720 horas de trabalho bem feito;
3. Estimativa é uma E-S-T-I-M-A-T-I-V-A. Há incertezas, há erros e definitivamente não há precisão. O Gráfico de Gantt que fica bonito impresso não serve para muita coisa na parede.

Pontos

São uma medida de complexidade relativa. Não existe uma correlação com tempo cronológico e sim com tamanho e complexidade das tarefas.

Entre suas características podemos citar:

• Exige um bom “baseline” para servir de parâmetro para as definições de ponto. Ou seja, a equipe precisa conhecer bem e de forma uniforme (pessoalmente – não é preciso todos serem iguais) o que considera 1 ponto, 3 pontos (não é multiplicando o item de 1 ponto por 3), etc. Um erro muito comum nesse caso é iniciar-se com uma simples conversão de horas para pontos (ex: 4h = 1 ponto), nesse caso perde-se muito do conceito e dificilmente será possível entrar nos eixos;
• É bem difícil de explicar para o cliente ou fazer uma proposta nesse modelo se o relacionamento com o cliente não é baseado nas premissas ágeis (atualmente é comum adotar SCRUM & cia internamente mas não ter o relacionamento com o cliente nesse modelo);
• Exige alguns ciclos até que se tenha realmente uma relação com capacidade de entrega de forma uniforme e segura;
• Mudanças freqüentes na equipe tem alto impacto no auto-conhecimento e alteram significativamente a capacidade de entrega do time.

Tempo Ideal

Respondendo a pergunta “Quanto tempo, sem interrupções, você levaria para fazer ….” a estimativa resultante é feita em unidades de tempo ideal (geralmente horas).

Apesar de serem horas note que não existe o mundo ideal. Seu time será interrompido, haverá distrações, dias de pouca produtividade e inspiração entre outros fatores que farão uma tarefa de 8hi (hora-ideal) durar 14h cronológicas.

Dito isso, esse modelo ainda é mais fácil de ser adotado com alguma precisão desde o início e a comunicação em tempo ideal é mais fácil com as demais áreas relacionadas.

Considerações finais

Mais importante do que a forma de mensurar, medir ou controlar o desenvolvimento de software é a consistência e a constância dessas atividades, indepentende da abordagem utilizada.

Como algo incerto não existe uma escala certa ou errada. O bom senso nos diz que ao escolher a escala para estimar, seja em horas ideias ou pontos, a ordem de grandeza dos números deve ser diferente (não necessariamente o conceito matemático de ordem de grandeza, podemos ficar só com a idéia) já que o grau de segurança para escolher entre dois números da mesma ordem vai ser igual e não teremos realmente subsídios para escolher entre esses dois números. Por exemplo, uma tarefa pode levar 3hi ou 4hi ? Tanto faz. Agora, ela leva 2hi ou 6hi? Agora sim existe uma diferença.
Da mesma forma a partir de determinado limite qualquer número é válido. A tarefa leva 80hi ou 100hi? Novamente tanto faz, minha margem de erro é tão grande que qualquer um dos dois serve.

Claro que há vários fatores a serem endereçados como planejamento, orçamentação, precificação, dimensionamento de equipe e investimento. Isso tudo fica mais fácil se você não ignorar a natureza empírica do desenvolvimento e o processo criativo humano e lançar mãos de outros meios para respeitar essa natureza como o contrato, por exemplo.