segunda-feira, 26 de julho de 2010

Escalabilidade "built-in"

Num momento em que muito se fala de Cloud Services, Cloud Computing, e em que começam a surgir muitas empresas a apostar forte nessa área, seria tolice não apanhar a onda e não analisar mais a fundo as várias opções actualmente existentes no mercado que podem suportar as necessidades infra-estruturais de um novo serviço web.

Em primeiro lugar, é de salientar que a utilização dos cloud services pode trazer grandes benefícios para um empreendedor em TIC:
- Redução das preocupações e do tempo despendido na gestão da infra-estutura de hardware e software (o fornecedor do serviço é que terá de ter esse trabalho); 
- Acesso a soluções profissionais (backups, storage, largura de banda...) com baixo custo, devido à larga escala;
- Modelo pay-as-you-go, sem necessidades de grande investimento inicial;
- Escalabilidade "built-in" = Fácil capacidade de expansão da infra-estrutura.

No entanto, nem todos os serviços "cloud" são iguais e muitos deles nem passam de uma mera virtualização de servidores físicos em servidores virtuais, o que dificulta um bocado a sua aplicabilidade, pois continuam a existir limites virtuais de memória, processamento, espaço em disco... e todas as preocupações de escalabilidade continuam presentes: necessidade de load-balancers,  algoritmos tolerantes a faltas... e por aí fora.

Em http://www.informationweek.com/news/software/hosted/showArticle.jhtml?articleID=210602537 são listadas algumas startups que estão a apostar nesta onda. Algumas delas, como a Kaavo ou a Elastra nem sequer são donos de uma cloud própria mas sim fornecem serviços de integração e disaster recovery para outras clouds como a da Amazon ou Google.

Os tipos de serviços disponibilizados por uma cloud são, geralmente:
- criação de máquinas virtuais;
- espaço em disco infinito;
- bases de dados estruturadas; 
- filas de mensagens;
- servidor web escalável até milhões de utilizadores em simultâneo;
- CDNs (Content Delivery Networks) que permite a disponibilização de conteúdos (ficheiros, vídeos, etc..) a partir de vários DataCenters espalhados pelo globo e sem perda de performance devido aos acessos em simultâneo dos vários utilizadores.

Estes serviços são pagos mensalmente (ex: $0.15 por GB por mês), tendo em conta a quantidade de dados transferida para dentro e fora da nossa conta, bem como a quantidade de dados guardados em disco. Apenas os servidores virtuais é que têm um modelo diferente, semelhante aos planos de alojamento web habituais: x por mês fixo, com limites de tráfego e disco.

Como escolher o fornecedor adequado para a nossa solução? 
Ou melhor, a pergunta pode até ser: 
Como definir a solução adequada tendo em conta os serviços prestados pelo fornecedor escolhido?

A forma mais correcta de responder a estas perguntas, passa por conhecer os vários serviços e planos de preços, bem como as limitações apresentadas caso a caso.

A resposta não é fácil. No entanto, vou tentar esclarecer alguns conceitos no próximo post para se delinear uma estratégia de adopção da cloud para o nosso projecto. 

Diverte-te!

domingo, 25 de julho de 2010

Ideias há muitas!

Por vezes pensamos que as nossas ideias têm tanto potencial, que a própria ideia em si vale uma quantia imensurável de dinheiro e, portanto, devemos tudo fazer para a proteger...

Na verdade vos digo: se uma ideia nunca passar de ideia para se tornar em algo concreto, o seu valor é muito pouco ou mesmo nulo.
Portanto, em vez de esconderes as tuas ideias, mostra-as ao mundo, partilha-as sem receio com os teus amigos e verás que essa atitude em vez de ser um risco (por te poderem "roubar" a ideia), pelo contrário, irá contribuir para a evolução da própria ideia, e o momentum criado irá trazer a motivação extra para que a ideia se torne em algo real.

Tornando-se em algo real, o seu valor cresce drasticamente, e aí sim podes pensar em proteger o "produto" através da criação de uma marca ou patente.

Mas nem todas as ideias se transformam em produtos vencedores. A mesma ideia pode inclusivamente ser concretizada de formas tão distintas por diferentes equipas que um produto pode ter um sucesso extraordinário e o outro não passar de um protótipo...

Derek Sivers, Presidente da HostBaby, apresenta este tema de uma forma bastante elucidativa no seu blog http://sivers.org/multiply

"It's so funny when I hear people so protective of ideas. (People who want me to sign an NDA to tell me the simplest idea.)

To me, ideas are worth nothing unless executed. They are just a multiplier. Execution is worth millions.

Explanation:

AWFUL IDEA = -1
WEAK IDEA = 1
SO-SO IDEA = 5
GOOD IDEA = 10
GREAT IDEA = 15
BRILLIANT IDEA = 20

NO EXECUTION = $1
WEAK EXECUTION = $1000
SO-SO EXECUTION = $10,000
GOOD EXECUTION = $100,000
GREAT EXECUTION = $1,000,000
BRILLIANT EXECUTION = $10,000,000

To make a business, you need to multiply the two.

The most brilliant idea, with no execution, is worth $20.
The most brilliant idea takes great execution to be worth $20,000,000.

That's why I don't want to hear people's ideas.

I'm not interested until I see their execution."

Em conclusão:
Ideias há muitas! Aposta na concretização!

Diverte-te!

terça-feira, 20 de julho de 2010

É mais fácil dar um passo noutra direcção...

...quando já se está a dar um passo em alguma direcção!

Foi com este pensamento que hoje acordei, e que fui mentalmente explorando ao longo do dia.

Por vezes pensamos que a partir do momento em que temos um plano bem definido e nos começamos a mexer de acordo com o planeado, devemos colocar "umas palas nos olhos" para esquecerrmos por completo as outras alternativas existentes e nos cingirmos ao plano. A verdade é que o acto de planear não passa de especulação ou adivinhação e só à medida que avançamos num projecto é que começamos a ter o conhecimento relevante que nos ajude a tomar decisões informadas.

Mudar de direcção durante o trajecto não é tão difícil assim. E, seguindo uma metodologia Agile, o resultado pode ir muito mais ao encontro das expectativas.

O que é difícil é ultrapassar a barreira da inércia inicial! Se planearmos logo de raiz fazer uma aplicação perfeita, com todos os detalhes explicitados ao milímetro, a barreira da inércia sobe; e torna-se um fardo para ultrapassar.
Se, em vez de planearmos tudo ao detalhe, formos gradualmente criando o conceito da aplicação (começando com algo muito simples e desenvolvendo apenas o que é mesmo essencial) a barreira da inércia torna-se apenas uma pedra no caminho, que podemos "chutar" para o lado sem grande dificuldade.

Num post anterior, apresentei a falta de entusiasmo como o inimigo nº1. Aqui, apresento a inércia como o inimigo nº2.

Como combater a inércia?
Bastam duas fases:

Fase 1 - Começar a mexer em qualquer direcção que seja mais fácil, directa, natural, motivante (mas mostrando logo algo como resultado, nem que sejam apenas uns drafts ou umas ideias gravadas em audio/video);

Fase 2 - Alinhar a direcção gradualmente, à medida que se vai avançando (através da gestão de prioridades, com remoção de excessos de ideias acumulados).

Esta é uma outra forma de ver o Agile. E é por isso que eu gosto.

Diverte-te!

segunda-feira, 19 de julho de 2010

A partir de agora também vais poder "postar" aqui

No último mês estivemos tão activos no google wave (a discutir ideias para mini-aplicações) que fui descurando a inserção de novos posts neste blog.

Não por falta de assunto (tenho um conjunto bem grande de temas em lista de espera) mas apenas porque 4horas por semana não dá para muito...

Para que isto não volte a acontecer (este blog ficar "parado" por 1 mês) resolvi tornar todos os elementos da equipa como "autores". Isto quer dizer que a partir de agora vais poder ser tu a "escolher o tema de debate" e dar a oportunidade aos outros elementos de comentar sobre esse tema.

Existem expectativas por discutir, metodologias por dar a conhecer, ferramentas por apresentar... Conto contigo para lançar um novo olhar sobre estes temas! (ou outros)

Envia-me um email com o email que pretendes usar para publicar neste blog. Também se aceitam OpenIDs! ;)

Diverte-te!

sábado, 19 de junho de 2010

As pessoas gostam é de se divertir!

Quantas vezes já pensaste numa ideia de negócio que se baseia na enorme utilidade de uma aplicação e ficas:
"xiiiiiiiii, isto dá mesmo bué jeito. Toda a gente vai querer pagar para usar isto!..."

Desengana-te.
A maioria das pessoas não investe muito na "utilidade". No entanto, gasta muito dinheiro no divertimento.

Senão, faz uma auto-reflexão: Quantas vezes já foste a um bar à noite, onde cada bebida é a 5€, e pensaste: "5€? Que chulice... " "Ok. Quero duas!"
E agora um outro exemplo em que viste uma aplicação na net, que parece super-interessante e que poderia trazer uma grande vais-valia para o teu dia-a-dia, e pensaste: "É a pagar? Esquece..." mesmo que seja por 1€!

Esta tendência natural das pessoas pode comprovar-se com o sucesso financeiro que os jogos tipo FarmVille estão a ter. As pessoas gostam é de se divertir!

E é por isso que é TÃO IMPORTANTE criar aplicações que, para além de serem úteis, sejam também "engaging" e "enjoyable" e façam com que as pessoas fiquem "addicted" (num bom sentido) ao ponto de as partilharem com os amigos.

Diverte-te!

sábado, 12 de junho de 2010

Metodologias de Desenvolvimento Agile

Depois de alguma pesquisa relativa a este tema, cheguei às seguintes ilacções:

Noutras metodologias, a interface é desenhada logo com todas as funcionalidades possíveis mas a maioria é fake, não funciona. Isto torna-se fuleiro pois se o projecto terminar a meio nota-se que o software está por acabar e não pode ser mostrado aos futuros utilizadores.

A metodologia Agile, baseia-se na utilização de ciclos de desenvolvimento mais pequenos, mas em que no final de cada ciclo todas as funcionalidades visíveis no protótipo/aplicação estão a funcionar.

Ou seja, se o projecto terminasse aí, o software já era usável. Limitado, é certo, mas sem dar a entender que tem "pontas soltas" (funcionalidades por terminar).

Só nós é que sabemos que está por terminar. Enquanto que a percepção exterior é de que está acabado! Com poucas funcionalidades, mas acabado!

Isto é óptimo! Pois permite:
- uma entrega mais rápida de algo que pode ser colocado em produção, enquanto o desenvolvimento continua;
- obter feedback dos utilizadores finais mais depressa, que permite perceber se estamos a ir na direcção certa;
- maior flexibilidade para mudar de direcção se se verificar que a ideia original não serve;

No limite, as várias versões poduzidas podem até ser usadas em paralelo, por diferentes tipos de targets, pois nem toda a gente necessita de todas as funcionalidades.

O problema do software complexo (com muitas funcionalidades) é que torna complicadas as coisas simples. E, para certas pessoas, não há necessidade...

Ou seja:

AIM HIGH, START EASY!

Vejamos um exemplo na prática.

Quando pensamos em desenvolver um site, a primeira coisa que começamos a rabiscar é um layout com um menu, logotipo, algum conteúdo...
E depois, quando vamos desenvolver, acontece disto http://www.eb23-paranhos.rcts.pt/ UNDER CONSTRUCTION.
Em algumas das páginas criadas no menu ainda não se sabe muito bem o que queremos colocar, e ficam em construção (por vezes indeterminadamente).

A proposta Agile é começar de forma simples e com aquilo que é mais prioritário. Por exemplo, um site com apenas o logo e os contactos. Mas tendo por objectivo acabar com um produto fechado em cada ciclo, nem que o produto seja mesmo muito simples.
O grande problema é que a motivação se vai naturalmente detriorando ao longo do projecto... à medida que a novidade vai desaparecendo. Concordam comigo, certo?

Já agora, relativamente ao "under construction", vários sites indicam que não se deve usar por várias razões. Exemplo http://www.cs.utah.edu/~gk/atwork/

Concluindo,
segundo aquilo que pude constatar, o objectivo é apontar inicialmente para um produto o mais simples possível. E só depois de atingir esse objectivo é que se avança com alterações e alterações e alterações... mas sempre tendo por meta terminar cada ciclo com um produto fechado. Interessante, hein?

Portanto já sabes: AIM HIGH, START EASY!

Diverte-te!

terça-feira, 8 de junho de 2010

Expectativas - Competências da Equipa


Falando em termos individuais, o gráfico ao lado pretende demostrar que o percurso até obtermos todos os conhecimentos que necessitamos para desenvolver um projecto de sucesso ainda é longo. No entanto, podemos contar com o conhecimento previamente adquirido (what we know sufficiently), com uma lista de tópicos que podemos, queremos e vamos explorar (what we know that we don't know) e ainda com a certeza de que pelo caminho da busca de novos conhecimentos vamos encontrar "what we don't know that we don't know", o que irá fazer crescer o círculo azul (pois passamos a saber mais uns assuntos que não sabíamos) e, mais tarde, depois de maior investigação, irá fazer parte dos nossos conhecimentos pessoais.

Uma boa forma de ajudar ao processo de obtenção de todos os conhecimentos necessários, é chamar novos elementos para a equipa. Nesta fase inicial, em que ainda se está a constituir a equipa, um dos principais focos prende-se com o contributo que cada novo elemento poderá trazer para a competência global do grupo.
O ideal será que cada novo elemento venha complementar os conhecimentos já existentes no grupo, fazendo crescer a área do "what we know sufficiently" e também a lista de tópicos a explorar (área azul). Desta forma, iremos maximizar o nosso conhecimento àcerca daquilo que precisamos de saber e garantir o sucesso do projecto.
É um factor preponderante garantir que o conhecimento não é apenas detido por cada elemento em separado, mas sim que seja partilhado abertamente entre toda a equipa. Daí a importância da criação do blog individual, para partilha do conhecimento actual bem como dos novos conhecimentos adquiridos no processo de Enlightened Community Engagement.

Para já, e como forma de apresentação mútua, iremos partilhar (usando o Wave):
- aquilo que cada um sabe que sabe o suficiente;
- aquilo que cada um sabe que não sabe o suficiente mas seria interessante saber;

Apenas para que conste, os elementos da equipa ainda não foram apresentados pois o grupo ainda não está "fechado". No entanto, a partilha de competências individuais no wave irá permitir saber quem já está interessado em fazer parte deste projecto, e com quem podemos contar.

Diverte-te!

sexta-feira, 4 de junho de 2010

Criar um blog

A minha principal missão na equipa (que vou detalhar num post posterior) é garantir que todos têm as condições necessárias para evoluir pessoalmente e profissionalmente. No entanto, a evolução muitas vezes passa por fazer-te sair da tua zona de conforto e esse processo pode criar uma grande inércia...

Mas a evolução pessoal, depende principalmente de cada um e dos desafios que está disposto a aceitar e ultrapassar. Não basta concordar com a estratégia e depois não fazer por a seguir. É NECESSÁRIO DAR UM PASSO EM FRENTE! por pequeno que seja.

Resolvi, por isso, partilhar convosco umas dicas que retiro da minha própria experiência.

Criar o nosso próprio blog, não é uma coisa que surja naturalmente, principalmente se nunca fomos muito de escrever num diário ou sempre tivemos um low-profile (que era o meu caso).

Quando vemos os nossos amigos começar um blog, chegamos a pensar: "mas o que raio de tão importante é que ele tem pra dizer ao mundo?" e a verdade, é que não tem de ser nada que possa um dia aparecer nos jornais ou ser lido por 1 milhão de pessoas. É apenas a partilha da sua própria experiência e motivações pessoais. Ou até o que alguém disse e que eles acharam interessante partilhar com os amigos.

Não se trata de nos armarmos em importantes e dizer ao mundo que as nossas opiniões devem ser ouvidas. Trata-se apenas de partilhar com os outros aquilo que nos vai na alma para podermos esperar que os outros partilhem também um pouco de si. Basicamente, é uma forma de estarmos mais perto de quem gostamos que partilhe connosco as suas opiniões.

Primeiro passo - Escolher o serviço

A criação de um blog, é tão simples como escolher um serviço, fazer o registo e escolher um nome.

Exemplos de serviços de blog:
http://wordpress.com/
http://blogs.sapo.pt/
http://www.blogger.com

Já agora, o blogger tem algumas limitações em termos de comentários. Não é possível anexar files nem links. O que é chato. Se puderem experimentar um dos outros para ver se não têm essa limitação, óptimo ;)

Segundo passo - Treinar a escrita

Não se pretende aqui aprender a escrever ;p mas sim mentalizarmo-nos para escrever um bocadinho todos os dias.
No meu caso, comecei pelo Facebook. Nem sequer tive de ser criativo. Peguei num livrinho de "pensamentos de auto-confiança" que tinha lá por casa e resolvi partilhar uma frase todos os dias mal chego a casa.
O engraçado é que a minha família foi comentando cada frase ou dizendo apenas "like" e foi-se criando um ciclo de interacção interessante ;)

Daí, passei para o Blogger. Os primeiros blogs que criei foi mesmo só isso: criei. Exemplo: http://nomorearbitrarycode.blogspot.com (um post apenas)

Para este (empreendedorismo divertido) a motivação é maior pois mexe com a minha forma de pensar. Também sinto a "obrigação" de continuar a escrever para tentar desenvolver em vós o bixinho do desenvolvimento pessoal bem como tentar levar-vos a partilhar as vossas opiniões. É MUITO IMPORTANTE A PARTILHA DE OPINIÕES para se criar uma equipa consistente.

Terceiro passo - Escrever sem receio

Mesmo que ainda não te sintas à vontade para começar a partilhar as tuas opiniões pessoais em relação àquilo que te motiva, começa a partilhar algo que encontraste na net, ou algo que alguém disse. Usa o teu blog como repositório pessoal de cenas interessantes: por exemplo apresentações do slideshare ou imagens do flikr. Começa a ler blogs de outras pessoas e partilha connosco alguns dos seus posts. Começa a inserir também comentários nesses blogs para que despertes o interesse no teu. Partilha... partilha... partilha... e sem receio de represálias. Verás como a experiência te fará crescer pessoalmente e ver os blogs de uma forma diferente.

Diverte-te!

terça-feira, 1 de junho de 2010

Expectativas - Tempo

Uma das possíveis causas para a falta de entusiasmo, apresentada num post anterior, é a existência de diferentes expectativas por parte dos vários elementos da equipa em relação a determinados aspectos do projecto.

Para evitar que isso seja um problema, é necessário esclarecer as expectativas de cada um logo de início. Este post refere-se a expectativas temporais.

Tendo em conta

- a estratégia de Enlightened Community Engagement, que pretende a criação de uma comunidade de seguidores para cada um dos elementos da equipa (recorrendo a serviços como o Blogger, Flikr, Twitter, Facebook, sei lá...) e um maior conhecimento mútuo entre os vários elementos da equipa

- bem como a forte aposta na metodologia (e não em objectivos puramente técnicos)

pode adivinhar-se que haverá uma fase inicial algo prolongada de research (obtenção de novos conhecimentos) e de exposição dos conhecimentos adquiridos.

Nesta fase inicial, teremos como principais objectivos:

- a criação do nosso blog pessoal (ou outro método adequado/entusiasmante para partilha de conhecimento com a equipa e o mundo) mostrando as nossas opiniões e/ou motivações relativas a metodologias e tecnologia;

- seguir e comentar o "blog" dos outros elementos da equipa, por forma a se ir criando um espírito de equipa que ainda não existe. ISTO É MUITO IMPORTANTE!

- a criação da lista de mini-aplicações que servirá de base à fase seguinte. Espero contributos de todos! Pois sei que há por aí grandes ideias à espera de florescer :)

Esta primeira fase irá durar até inícios de Setembro, altura em que as nossas ideias e conhecimento acerca de metodologias irão começar a assentar. Lembrem-se, 4 horas por semana!

Na segunda fase, iremos cordialmente seleccionar uma mini-aplicação (que seja alvo de motivação por parte de todos), para começarmos a aplicar as metodologias na prática. Sendo a primeira vez, e tendo por objectivo a QUALIDADE, a minha previsão é que esta fase se prolongue até ao NATAL. Lembrem-se das 4 horas por semana e do facto de continuarmos a partilhar os nossos feelings nos blogs, neste caso acerca da aplicação das metodologias na prática.

No final desta fase iremos avaliar o resultado, e seguir em frente com uma nova mini-aplicação.

A terceira fase terá também uma duração aproximada de 4 meses, pretendendo-se olear os processos internos e utilizar outras metodologias que não seja possível usar na fase anterior. Continuaremos a manter o contacto com a comunidade, através dos nossos "blogs" e provavelmente começaremos a ter algum feed-back em relação à primeira mini-aplicação desenvolvida.

A quarta fase, será muito semelhante à terceira. Iremos desenvolver a nossa terceira mini-aplicação e prevê-se um aumento acentuado da interacção com a comunidade.

No final desta fase, já com processos internos oleados e um conhecimento amadurecido das tecnologias, metodologias e forma de trabalhar da equipa, iremos ter a base para decidir o que fazer a seguir.
As opções podem ser várias:
- continuar a desenvolver apenas mini-aplicações, por forma a dar continuidade ao processo de desenvolvimento das nossas capacidades pessoais;
- avançar para um projecto mais ambicioso e complexo (o projecto tecnológico inicialmente traçado);
- ficar por aí, se as coisas entre a equipa não funcionarem.

Isto tudo é mera especulação, e faz parte das minhas expectativas.
Fico à espera de comentários.

Diverte-te!

sexta-feira, 28 de maio de 2010

Uma estratégia contra a falta de disponibilidade

Para esta, vou precisar da vossa ajuda...

4 horas por semana, é demasiado tempo para dedicar a esta causa?

Diverte-te!

Outras directrizes estratégicas com implicações tácticas

Muitas vezes a estratégia é vista como uma coisa de muito alto-nível. No entanto, certas opções estratégicas têm implicações tácticas...

No nosso caso, existem alguns exemplos desses:

estratégia 1 - "As aplicações devem garantir um elevado nível de interactividade"

implicação: tirar partido da "tecnologia" AJAX e ainda mais do COMET, para permitir que o servidor faça updates instantâneos ao conteúdo de um site

estratégia 2 - "As aplicações devem poder interagir com os serviços já existentes"

implicação: usar standards e APIs previamente desenvolvidos pelos outros serviços, como por exemplo o IMAP (email), XMPP (para chat), Google Maps, Facebook Connect, ...

estratégia 3 - "usar a tecnologia que permita o maior desempenho na elaboração dos protótipos, permitindo desenvolver um maior número de alternativas antes de nos fartarmos do processo"

implicação: Os protótipos não têm de ser desenvolvidos usando a mesma tecnologia que o produto final, nem estar alojados no destino final.
O Flash Catalyst (http://www.adobe.com/products/flashcatalyst/) parece ser uma boa opção táctica para prototipagem.

Diverte-te!

Mini-Aplicações

Este post vai aglomerar a lista de possíveis mini-aplicações a desenvolver. A ideia é mencionar pequenas coisas (fáceis de implementar) que podem melhorar o nosso dia-a-dia (e portanto, que torne o seu desenvolvimento interessante e motivante) e para as quais nunca se reuniram as condições para as fazermos.

Para começar a lista, aqui vão uns exemplos:

- Automatizar a combinação de jogos de futebol (ou outros eventos). É uma treta estar sempre a receber imensos emails...

- Envio de SMSs usando as contas online da optimus, tmn, vodafone. Já que são à borla, e até é mais fácil escrever no PC que no telemóvel...

- Calendarização de SMSs. Para nunca mais nos esquecermos de um aniversário ;)

- Serviço online de agregação de alertas do google. É mais fixe ver todos os updates de alertas numa página do que estar a receber imensos emails que depois ficam desorganizados...

- Listas de email publicadas online. Para facilitar o envio de emails para várias pessoas.

- TableTalk Live. Blog familiar privado.

- VPN made simple. Para facilitar coisas como partilhar uma pasta com um amigo remoto.

Diverte-te!

Áreas Funcionais da Equipa

O Blog http://www.ixd101.com/2009/09/play-to-your-strengths-and-team-up-with.html apresenta um triângulo com três pilares do design de serviços TI:

- Behavioral
- Visual, and
- Technical

Normalmente, diferentes áreas são responsáveis por cada um desses pilares. Mas por vezes é bastante difícil discernir a que área pertence uma determinada actividade pois estes pilares vivem em estreita ligação e o resultado da actividade de um tem consequências nos outros.

Tendo em conta as métricas de evolução apresentadas no post anterior, e fazendo o mesmo exercício adaptado ao nosso caso, pode adivinhar-se que é necessário identificar um pilar adicional: Business

A imagem apresenta os nossos 4 pilares do desenvolvimento de serviços TI, enquadrando também as métricas que mais dizem respeito a cada um.

Diverte-te!


Métricas de Evolução


Para se saber se se está a prestar um serviço de qualidade, é necessário ter uma forma de medir essa mesma qualidade. As métricas podem tomar formas muito distintas e têm normalmente um carácter subjectivo.

No que se refere a serviços de TI, que será o objecto das nossas actividades, existem algumas áreas que podemos adoptar como base para avaliação da qualidade do trabalho desenvolvido. Tornando como hábito a avaliação da qualidade nessas áreas, para as mini-aplicações a desenvolver, será possível verificar uma evolução materializada da qualidade e maturidade no resultado das nossas actividades.

As diferentes áreas a avaliar (definidas por nós, e sujeitas a revisão) são as seguintes:

1 - Usability
2 - Functionality
3 - Graphics
4 - Content
5 - Security
6 - Performance
7 - Accessibility
8 - Availability
9 - Scalability
10 - Flexibility
11 - Maintainability
12 - Engagement

Como será de esperar, a classificação será uma média subjectiva das avaliações de toda a equipa.
Isto irá permitir envolver todos os elementos na evolução dos processos internos de desenvolvimento, promovendo uma melhoria constante dos processos.

! Curiosidade
Os 12 vértices de medição da qualidade, podem ser representados num icosaedro (que é um sólido geométrico platónico com 12 vértices - http://www.uff.br/cdme/platonicos/platonicos-html/icosaedro-br.html) ou num dodecágono (que é um polígono com 12 vértices - http://pt.wikipedia.org/wiki/Dodec%C3%A1gono).

O gráfico-aranha da imagem (em inglês: spider chart) é baseado no dodecágono, e mostra de forma integrada uma possível classificação para cada vértice. O nosso objectivo como equipa (e como aposta de desenvolvimento pessoal) será maximizar a área do polígono assimétrico formado pela classificação dos vértices.
Diverte-te!

quarta-feira, 26 de maio de 2010

Engaging People with an Engaging Strategy

PESSOAS, FERRAMENTAS, PROCESSOS
são os três vértices da gestão empresarial.

Nos posts anteriores, estes vértices já foram explorados muito ao de leve, mas sempre numa vertente de relacionamento interno entre as equipas e nunca no que toca ao relacionamento com a sociedade.

O Protótipo de Projecto Empresarial que pretendemos criar, nunca seria representativo de uma possível futura realidade, se o relacionamento com o exterior não fosse também abordado.

Esta é normalmente matéria da área de marketing e relações públicas, no entanto, pela sua importância estratégica, foi desenvolvido um modelo que engloba todos os pontos até agora abordados e que pretende representar a Estratégia Global da Equipa.

Este modelo, pretende passar a mensagem de sermos pessoas cativantes com uma estratégia de sedução, onde cada elemento da equipa mantém a sua própria identidade e cria a sua própria comunidade em redor dos temas que vai explorando e sobre os quais vai escrevendo.

É uma estratégia de 4 fases, que serão integradas nas restantes actividades a realizar em equipa. As 4 fases são:
- Search for new methodologies (ex: usando o slideshare)
- Write about it (blog, twitter...)
- Apply them to a real project (ex: nas mini-aplicações)
- Share (with the team, or the global community)

A nível individual, o resultado final desta estratégia (criada por nós e denominada Enlightened Community Engagement) é o desenvolvimento pessoal e a criação de laços inseparáveis com a comunidade.

As repercussões para a equipa são:
- Um ambiente de inovação constante
- Melhoria na qualidade
- Melhores produtos
- Satisfação dos utilizadores
- Valorização da Marca e da Empresa
- Optimização de Processos

Como estratégia de sedução, irá atrair:
- Consumidores
- Parceiros
- Os Media
e unir ainda mais os próprios elementos da equipa.

...e o melhor de tudo é que podes por em prática esta estratégia antes mesmo de os detalhes técnicos dos projectos ocuparem todo o espaço do teu pensamento!
"Before the project starts
the process is already in place."
As outras empresas vão desejar ser como nós :D

Diverte-te!

Metodologias

Já está bastante explícito, nos posts anteriores, que o nosso enfoque inicial não será num projecto tecnológico em específico mas sim nas metodologias e ferramentas a utilizar, no desenvolvimento de um qualquer projecto tecnológico.

A questão que se coloca agora é: estás a falar do quê, mesmo?

Se também te colocaste esta mesma pergunta, não te preocupes. Já estamos habituados a que, nas empresas, haja uma certa cultura do "bota prá frente! o que interessa é atingir o objectivo!", não sendo a qualidade uma questão fundamental. E metodologia tem tudo a ver com qualidade!

Fazendo uma pesquisa no google, é possível encontrar alguns artigos interessantes como http://computerworld.uol.com.br/gestao/2009/08/05/metodologias-de-desenvolvimento-qual-a-mais-adequada/, que tentam servir de guia para orientar o programador na escolha da melhor metodologia de desenvolvimento a usar para um determinado projecto.

Mas as metodologias não existem apenas para programação. Aliás, existem para tudo e mais um par de botas! É preciso é saber encontrá-las.

Uma coisa que descobri recentemente é capacidade do www.slideshare.net de fornecer informação muitíssimo valiosa no que toca a metodologias e estratégias. Apresentando a informação em diagramas e tópicos, é possível verificar mais rapidamente se "aquilo" nos poderá interessar e permite uma pesquisa mais eficiente de informação interessante.

Experimenta e faz uma pesquisa por: SCRUM, UX ou Social Marketing e verás como estou certo.

O slideshare pode, então, ser uma boa fonte de novas metodologias.

Quanto a ferramentas, isso normalmente é mais fácil de saber aquilo que existe pois: ou já conhecemos e usamos ou já ouvimos falar e talvez gostássemos de experimentar.

Na área de programação/design temos por exemplo:

Linguagens de Programação: PHP, Java, Perl, Ruby on Rails, Pyton, .NET, ActionScript, JavaScript, Erlang...
Ambientes de Desenvolvimento: Eclipse, VisualStudio, Macromedia, Zend, Flash Studio, Photoshop, Gimp, FreeHand, Audacity...
Plataformas de Desenvolvimento: JBOSS, ExtJS, Flex...
Ambientes: Web, Desktop, Wap, iPhone, Apresentações CD...

E depois há ainda coisas como:

Etapas: Arquitectura da Informação, Design de Interacção, Casos de Uso, Modelo relacional da BD, Programação Back-Office, Programação da Interacção, Design Gráfico, Testes de Usabilidade...
Chavões: AJAX, Comet, WebSockets, Google Wave

Noutras áreas que não programação, é preciso procurar mais um bocadinho. Mas a procura é sempre interessante ;)

Diverte-te!

TROCA TUDO

Este lema apresenta duas faces principais:
  • Os objectivos passam a ser os meios;
  • E os meios passam a ser os objectivos.
Na prática, isto significa o seguinte:

Em vez de definirmos as metodologias de desenvolvimento com o intuito de atingir objectivos tecnológicos...
...vamos mas é definir objectivos tecnológicos, com o intuito de praticar a aplicar metodologias de desenvolvimento.

O importante não será o projecto tecnológico, mas sim a aprendizagem. E isso é bom tanto em termos de crescimento pessoal como profissional, trazendo um grau de motivação e entusiasmo muito superior a qualquer projecto que se foca em objectivos e requisitos.

O objectivo passa a ser tornarmo-nos mestres em metodologias de desenvolvimento, que poderemos depois aplicar num qualquer projecto que queiramos desenvolver (em conjunto, ou mesmo noutro contexto).

Numa fase inicial, os objectivos tecnológicos serão escolhidos de entre uma lista de "mini-aplicações" (com o requisito único da simplicidade) e podem nem sequer estar relacionadas com o nosso projecto tecnológico principal. Esta lista terá o contributo de todos os membros, e os projectos serão escolhidos por grau de simplicidade e motivação geral em relação aos mesmos.

Tendo o enfoque na metodologia, os requisitos serão flexíveis... ou melhor, elásticos.

Antes de começar a existir um grau ínfimo de saturação em relação ao desenvolvimento dessa "mini-aplicação", damos o projecto por terminado, partilhando a experiência de utilização da metodologia adoptada (para aquele caso em específico) com os restantes elementos da equipa.
Serve?
É adequada?
Poderia ser usada num projecto de maiores dimensões?
Quais foram as dificuldades encontradas?
Foi uma experiência interessante ou frustrante?
Bora aplicá-la novamente?
É este o tipo de perguntas às quais irão surgir algumas respostas.

Diverte-te!

Enfoque na Metodologia

Devido aos factores financeiros, existe uma tendência crescente nas empresas para a Gestão por Objectivos, sendo estes muitas vezes associados a objectivos tecnológicos ou objectivos por projecto.

Este facto, faz com que muitas vezes se descure uma parte estremamente importante e interessante do desenvolvimento: que é a metodologia.

O enfoque em objectivos puramente tecnológicos, tem a vantagem de fazer com que o projecto termine mais depressa mas perde-se algo pelo caminho. E esse algo é ainda mais importante que a finalização do projecto em si. A apresentação http://www.hackerteen.com/files-ht/enjoy/empreendedorismo_cp.pdf, na sua mensagem final, esclarece exactamente aquilo que não se aproveita com este tipo de gestão.

Para que serve a nossa carreira?
Para que servem os objetivos profissionais?

O que nos move não é o lugar onde queremos chegar (um emprego numa grande empresa, por exemplo), mas sim essa jornada! É isso que nos mantém vivos e com vontade de ir mais longe!

E é também isso que nos faz procurar novas coisas e aprender cada vez mais.

Daí a importância do enfoque na metodologia e não nos objectivos específicos.
  • Se te focares nos objectivos, aprenderás a fazer um projecto igual ao que acabaste de fazer;
  • Se te focares na metodologia, terás uma boa base para fazer qualquer projecto que te apareça pela frente!
Daí que, um dos grandes lemas da nossa viagem será:
TROCA TUDO

Diverte-te!

terça-feira, 25 de maio de 2010

Falta de ENTUSIASMO - o maior risco do empreendedor

Continuando a exposição da importância do entusiasmo constante no sucesso de qualquer projecto, este post apresenta a falta de entusiasmo como o maior risco a colmatar.

Em segurança, para se tentar evitar novos incidentes é necessário fazer uma root cause analysis, que é como quem diz: chegar à origem do problema.

Considerando a Falta de Entusiasmo o nosso maior possível problema para o protótipo de empresa, então o desafio prende-se em desvendar quais serão as razões que poderão levar a essa falta de entusiasmo. Esta análise deve ser aprofundada posteriormente, e poderia até ser alvo de uma investigação académica com resultados bastante interessantes. Vamos, para já, mostrar apenas um cheirinho dos benefícios que daí podem advir.

Considere-se que:

falta de ENTUSIASMO <- projecto pouco interessante

significa que a causa directa para a falta de entusiasmo é o facto de o projecto ser pouco interessante.

Outras causas directas podem ser apresentadas:

falta de ENTUSIASMO <- espectativas diferentes de um elemento em relação ao projecto

falta de ENTUSIASMO <- espectativas diferentes de um elemento em relação à equipa
falta de ENTUSIASMO <- falta de empenho

A verdadeira origem do problema pode não ser uma destas causas directas acima mencionadas, mas sim uma cadeia de causa-efeito que termina na falta de entusiasmo. É esta cadeia que se pretende detectar e desmaterializar atempadamente.

Exemplo:
falta de ENTUSIASMO <- falta de empenho <- falta de cumprimento de objectivos <- objectivos demasiado exigentes <- metodologia incorrecta <- mau planeamento estratégico

Do exemplo anterior, pode deduzir-se que a verdadeira origem do problema da falta de entusiasmo (para a cadeia apresentada) se deve a um mau planeamento estratégico. Logo, uma das formas de quebrar esta cadeia é ter uma estratégia bem delineada logo de início. É esse o substracto do conteúdo deste blog :)

Reflecte um pouco sobre este assunto, e completa o raciocínio enviando-me as tuas próprias CADEIAS DE ENTUSIASMO.

Diverte-te!

ENTUSIASMO

O blog http://curtavida.com/entusiasmo-combustivel-sucesso na série "Leis do Triunfo" apresenta o ENTUSIASMO como o combustível para o sucesso. Na verdade, até
os gregos acreditavam que só pessoas entusiasmadas eram capazes de vencer os desafios do quotidiano. Esta sensação mágica, permite-nos agir com determinação para fazer dar certo o que planeamos, superando mesmo os desafios mais difíceis!

Se formos esperar ter as condições ideais primeiro, para depois nos entusiasmarmos, jamais nos entusiasmaremos com alguma coisa, pois sempre teremos razões para não o fazer.

Não é o sucesso que traz o entusiasmo, é o entusiasmo que traz o sucesso. E por esse motivo é necessário garantir entusiasmo ao longo de todo o processo de criação do nosso próprio emprego. Eu diria mesmo que o ENTUSIASMO é o nosso bem mais precioso, no que toca ao sucesso dos nossos empreendimentos.

Fazendo parte de uma equipa, onde cada pessoa tem a sua vivência individual e cujo nível de entusiasmo em relação ao projecto comum irá naturalmente variando ao longo do desenvolvimento da actividade, torna-se importante garantir que o ENTUSIASMO COLECTIVO é sempre uma realidade presente e que qualquer indício de falta de entusiasmo seja atempadamente acompanhado como se de um importante incidente se tratasse.

Afinal, o entusiasmo é ou não o nosso bem mais precioso?

Diverte-te!

Protótipo de Projecto Empresarial

A ideia de criação de um protótipo de projecto empresarial provavelmente não é super inovadora, no entanto pode ser uma metodologia enriquecedora e divertida para se avançar de forma mais segura no sentido de um projecto mais sério.

Em específico, a ideia principal desta nova aventura que agora começa não é construir apenas um projecto tecnológico, mas sim um projecto empresarial. Este, por sua vez, poderá promover o desenvolvimento de vários projectos tecnológicos.

Existem várias opções estratégicas que irão guiar o desenvolvimento desta "empresa":

- A primeira prende-se com a evolução do target dos serviços que formos desenvolvendo. Começando por targets menos exigentes, conseguiremos mais facilmente fornecer serviços completos aos nossos utilizadores. Depois vai-se evoluindo. Exemplo de evolução do target: Velhotes -> begginers -> techies;

- O marketing será muito direccionado para "vender" a empresa/marca em si e não só focado no serviço/produto tecnológico. Isto será conseguido através de uma metodologia de community engagement, baseada numa relação/comunicação aberta entre os membros da empresa e a comunidade que se irá criar à sua volta. Os projectos tecnológicos desenvolvidos terão sempre um objectivo social adequado ao seu target específico, com o intuito de criar um ecosistema sustentável entre a empresa e a sociedade;

- O desenvolvimento dos projectos tecnológicos seguirá metodologias consideradas boas práticas e que sejam adequadas, nomeadamente Agile Development, User Experience Design, Maketing Web 2.0, entre outras. Estas metodologias serão por nós transmitidas à comunidade, bem como a nossa experiência na sua utilização. Se não as conhecermos, vamos primeiro investigar e começar a escrever sobre isso num blog. Depois de as dominarmos aplicamo-las nos projectos. Desta forma enriquecemos os nossos conhecimentos e competências pessoais (que podemos aplicar noutros contextos), ao mesmo tempo que garantimos que os projectos são desenvolvidos com as melhores práticas;

O conceito fulcral é: Arquitectar uma Empresa como quem arquitecta um Site ...com prototipagem, experimentação, beta release, etc...

Se temos pessoas, conhecimentos, metodologias e ferramentas, podemos criar um protótipo de empresa com as várias áreas a funcionar e a interagir entre elas. Este protótipo de empresa (tal como qualquer outro protótipo) servirá para verificar o que funciona e o que não funciona (na empresa), sendo a base para se fazerem melhorias nos processos internos de gestão empresarial e relacionamento entre áreas.
No final, ao verificar que os processos estão oleados, poderemos pensar em dar o passo seguinte, com garantias de sustentabilidade, formalizando a criação de uma empresa real.

Diverte-te!