1. Pela análise do site da empresa que já existia, notei que eles não tinham a mínima idéia sobre o que é um site e para que ele serve. Assim, recomendei a meu colega que tentasse falar com o pessoal de marketing (quem tinha pedido a proposta foi o responsável por TI). Se o marketing não soubesse como a empresa deve ser vista pelos clientes no mundo online, eles iriam continuar com um site tosco só que utilizando tecnologias modernas.
2. Sugeri que ele falasse com os donos da empresa para descobrir a “Visão” que eles tinham sobre site, se eles sabiam para que ele serviria, qual seria o público que ele atenderia (clientes, público em geral, fornecedores, parceiros, etc) e se eles sabiam como o site da empresa deles deveria ser diferente da concorrência. Mas acima de tudo isso, que ele obtivesse o comprometimento da alta direção para o projeto.
3. A proposta deveria ser divida em etapas, sendo a primeira um trabalho de Arquitetura de Informação, Design e Usabilidade antes de começar a desenvolver o projeto. Os responsáveis da empresa deveriam aprovar um protótipo básico antes de iniciar o desenvolvimento.
4. Ele deveria discutir com as diversas áreas da empresas que iriam colocar conteúdo no site se todos os itens de informação seriam mesmo escritos e atualizados (dá trabalho manter o conteúdo atualizado e muitas empresas não levam isso em consideração).
5. Depois de aprovado, viria os aspectos técnicos, como a escolha da plataforma onde esse conteúdo seria publicado, onde seria hospedado, quais as tecnologias que a equipe de TI da empresa teria que lidar. Sugeri encontrar um CMS (OpenSource) já pronto que o time da consultoria tivesse experiência. Recomendei analisarem o WordPress,  Drupal ou Joomla. Desenvolver plug-ins para esses softwares seria uma forma de integrar com outros sistemas (ex, intranet).
6. O desenvolvimento deveria ser feito em etapas bem definidas com aprovações formais ao final de cada etapa. Deveriam começar com o site só com conteúdo (sem as aplicações), depois disso no ar, continuasse com as aplicações para os usuários uma a uma, depois para a Intranet, e então integrações com os sistemas legados (ERP, CRM, etc). Se tentassem fazer tudo de uma vez, seria grande a chance de fracasso. Entregas pequenas e freqüentes é a melhor estratégia para sites web.
7. Durante a construção deveriam ter sempre em mente as regras de SEO (Search Engine Optimization). Sugeri contratar um especialista nisso.
8. A equipe de desenvolvimento da consultoria deveria contratar um excelente Webmaster que seria o responsável pelo html compatível com todos os browsers relevantes e sistemas operacionais e pela implementação das “firulas” em javascript.
9. Quanto a vídeos, sugeri criar um Canal no Youtube para a empresa. No site colocariam só o player do Youtube. Isso tem a vantagem de não precisar pagar banda e os usuários poderiam assinar o canal do Youtube para receber as atualizações dos vídeos.
10. Quanto a redes sociais, eles deveriam manter uma conta no Twitter (com atualização freqüente, senão não serve para nada e só prejudica a imagem). Deveriam ter grupos no Orkut e Facebook. Se quisessem um grupo mais restrito poderiam usar o Ning (http://www.ning.com/) que possui todas as ferramentas para criar uma rede social própria. Outra opção seria criar aplicações para o Facebook e Orkut (OpenSocial), mas antes deveriam fazer uma análise sobre os interesses dos usuários nessas redes. O principal ponto é convencer a empresa que manter uma rede social custa. Precisa de gente dedicada a isso. Se não fossem alocar ninguém para essa função, então deveriam se questionar para que eles querem integração com as redes.

Meu colega seguiu esses conselhos, mas teve que apresentar uma proposta para elaboração de um “Business Plan” antes do desenvolvimento do site dado que a alta direção da empresa e a área de marketing não souberam dizer para que precisavam de um site… pelo menos a consultoria ganhou o trabalho, pois todas as outras concorrentes só apresentaram propostas técnicas sem o cuidado em descobrir as necessidades reais da empresa.

Deixe nos comentários o que você acha e se deixei de lado alguma coisa.

Emprestei um de um amigo e levei para casa no fim de semana. Logo no sábado tive que impor regras rígidas de tempo de uso para minhas filhas (6 e 10 anos). Elas sairam no tapa pelo direito de mexer o máximo de tempo com as aplicações mais interessantes para elas, o Virtuoso HD (piano), o U Connect (jogo), o Labyrint Lite (jogo), o Adobe Ideas (desenho) e principalmente o Pocket Pond (lago de carpas virtual com direito a esmagar umas libélulas).

No Domingo mostrei para minha vó de 86 anos que ficou encantada. Até escreveu seu nome no Adobe Ideas (ela é analfabeta e mal sabe escrever o nome) e queria saber se eu é que tinha inventado aquilo (quem dera…). Minha mãe exigiu que meu pai comprasse um para ela mesmo não sabendo bem para que, já que nunca sentou na frente de um computador. Meus tios e tias também se admiraram com a qualidade dos vídeos e do som, e com a praticidade do dicionário no iBook.

O problema foi tirar o iPad do meu sobrinho de 3 anos que entrou no time-slice com minhas filhas. Ele fez desenhos, tocou o piano e mudava de aplicações como se sempre tivesse feito aquilo.

A conclusão é que acabei involuntariamente vendendo mais alguns iPads para o Jobs sem ganhar comissão…

Depois do acesso difícil, o começo da pista é bem sinalizado e com uma área com banheiros e bebedouro. Por uns 100 ou 200 metros, a pista é estreita e dá a volta na Barragem. Quando começa os 14 kms da pista efetivamente, vemos que ela é larga mas metade dela é para os carros de manutenção, ficando a outra metade para ir e vir das bicicletas. Como não havia carros, todos usavam a pista inteira.

Eu gostei muito da pista e da vista. É um ângulo da cidade que nunca vemos. Mas desde que você não olhe para o rio ou respire muito fundo. O cheiro, em alguns momentos, era muito forte e a visão de coisas boiando no rio nos lembra do descaso com que essa cidade, tanto seus moradores quanto seus governantes, tratam ele.

Não sei se num dia de sol forte será possível andar pela ciclovia sem passar mal. Ontem, com chuva, o passeio foi bem agradável.

No final da pista, há novamente uma área de descanso com estacionamento. Mas ai nota-se um problema que poderia ter sido evitado. Os banheiros tinham filas e estavam imundos. Não sei o que esses engenheiros da prefeitura tem na cabeça para construir um único banheiro que só serve a uma pessoa por vez. Havia espaço para um banheiro muito maior. Senti falta também de uma lanchonete. Decididamente essa área não foi projetada para ciclistas, pois não havia como prender as bicicletas enquanto se usava o banheiro.

Em resumo, se você não levar em conta o acesso ruim da Vila Olimpia, os inexistentes acessos no meio do percurso, os poucos banheiros e o cheiro do rio, é um passeio que vale a pena. Vi várias capivaras, alguns patos, e algumas paisagens de São Paulo bem interessantes.

Quando terminarem o trecho até o Villa Lobos, acredito que vá ficar bem melhor, ainda mais que vai ficar bem mais perto de casa. No final do passeio, minhas pernas estavam quase se desmanchando…

Alguns adeptos da Engenharia de Software encaram o Desenvolvimento de Software como um processo mensurável que chega ao resultado desejado se as técnicas  forem corretamente aplicadas. Em alguns casos, é dado pouco valor ao ser humano que é considerado somente uma das engrenagens do processo.

Outros afirmam que a Engenharia de software está equivocada porque Desenvolver Software é uma arte. É um trabalho criativo feito por pessoas com todos os “defeitos” dos seres humanos como amor, ódio, paciência (e a falta de), desejos, necessidades, interesses. Portanto devemos evitar tolher a criatividade dos desenvolvedores com burocracias, fórmulas prontas, controles, métricas, etc. Todos os problemas do desenvolvimento de software podem ser resolvidos fazendo o que o ser humano faz de melhor, se comunicar.

Eu acho que é uma arte. Um programador usa a criatividade para codificar assim como um pintor precisa ser criativo para pintar um quadro. Mas assim como um pintor, o desenvolvedor precisa aprender técnicas, precisa desenvolver um processo pessoal de execução da arte, precisa transferir  da melhor maneira as idéias para o mundo físico, como disse Brooks, “Como criadores de coisas, a incompletude e inconsistência de nossas idéias tornam-se claras apenas durante sua implementação”.

Mas há uma situação no Desenvolvimento de Software que é preciso ir além da arte e as técnicas de Engenharia voltam a ser de suma importância.

Ocorre quando o sistema a ser desenvolvido é maior que a capacidade de uma única pessoa para construí-lo num tempo aceitável.

Diferente de uma pintura que é criada para expressar idéias para os sentidos e o prazer de outras pessoas, o software existe para resolver um problema de alguém (mesmo um jogo resolve um problema, o de como ocupar o tempo ocioso). O problema pode ser bem grande exigindo um software bem complexo. Quanto mais complexo, mais pessoas precisam trabalhar no seu desenvolvimento e os problemas de comunicação começam a ter um peso maior no tempo. Mais pessoas, mais falhas de comunicação podem ocorrer. Mais pessoas, e mais problemas decorrentes da diferença de “estilo” entre  programadores.

Softwares grandes demandam  planejamento,  técnicas de engenharia,  documentação,  meios adequados de comunicação,  processos,  controle. Só que tudo isso na medida certa. Não adianta, por exemplo, planejar tudo antes, pois, como todos sabem, os requisitos vão sofrer alterações. Mas precisa de algum planejamento mínimo antes de começar a executar. Não adianta exigir documentação de todos os aspectos do software. Boa parte deles vai ficar desatualizada. Precisa só dos documentos que comunicam informações que outros precisam saber para continuar com o trabalho (Isso que código é a única documentação que importa é balela, com certeza código não é o melhor documento para um usuário final ou para o pessoal de infra).

E nessa “medida certa” é que reside todo o problema. Quem sabe qual é a medida certa? Para quem acredita nos processos de engenharia, a medida certa é mais. Para quem acredita nas pessoas e interações entre elas, a medida certa é menos. Encontrar alguém para quem  a medida certa é a adequada é o segredo do sucesso. Se você souber de alguem assim, me avisa.

Justin R. Erenkrantz, Michael M. Gorlick, Richard N. Taylor publicaram um trabalho (http://bit.ly/hlfOi) onde eles generalizam o REST. Além de troca de informação, eles definiram uma forma de trocar programas entre as aplicações.

No CREST, uma url representa um recurso computacional. A aplicação cliente envia um programa (expressão) para o servidor origem que o avalia e retorna seu resultado que pode ser um primitivo (inteiro, string, etc) ou outro programa, uma closure, uma continuation, ou pares nomes/valores que podem conter os mesmos tipos de resultados acima.

Há duas formas de operação: remote e spawn. Na forma remote, o código é avaliado e o resultado retorna para o cliente. Na forma spawn, o cliente envia o código que fica armazenado no servidor origem que retorna uma url desse novo serviço para o cliente utilizar.

Continuations e Closures estão na base do CREST. Como closures mantém o estado entre invocações, CREST permite que as aplicações possam ser facilmente escaláveis pois qualquer servidor origem pode processar os recursos computacionais.

No paper publicado eles fornecem mais detalhes, inclusive com os axiomas que orientam o desenvolvimento de aplicações utilizando essa técnica. Vale uma leitura atenta.

Era uma vez uma garotinha bonita e fofinha que vivia em um sitio lindo lá no interiorzão de São Paulo.  Era uma menina trabalhadora que ajudava sua mãezinha a cuidar dos afazeres da casa enquanto seu pai andava pelo sitio em seu alazão cuidando da roça e das criações.

No domingo ia para a missa na cidade com toda a família. Naquela época ainda não prestava tanta atenção no que o padre dizia como agora e assim seus olhos sempre encontravam os olhos de um garoto magrinho com pinta de galã e uma linda troca de sorrisos acontecia.

Quantas vezes aquele garoto maroto ia até o sitio da menina roubar uma goiaba, uma manga ou então as deliciosas jabuticabas que ela tanto gostava. Ele não diz, mas as frutas não eram o real motivo para dar uma passadinha ali.  Era, talvez, um encontro inesperado, uma nova troca de olhares, ou quem sabe, até mesmo um “dedinho de prosa”. Como era bom aquele tempo, onde a inocência ainda reinava e as coisas eram mais belas.

Eles foram crescendo e a amizade também logo se transformando em um namoro “das antigas”. Permissão dos pais para sentarem juntos no mesmo sofá. Permissão dos pais para irem juntos à missa com a onipresença do irmão da moça.

Era um namoro inocente, mas o rapaz não era de todo inocente. Ele fazia parte da famosa turma da queixada, aquela que quando chegava nas festas e que elas realmente começavam. Tinha seus casinhos aqui e ali. Nada muito sério. Coisas de adolescente como diriam as pessoas da época. Quando estava com ela, entretanto, o coração batia mais forte. O beijo roubado quando o irmão se distraia era tão excitante que até valia o risco de apanhar do brutamontes.

A vida corria solta, mas as dificuldades eram muitas. O trabalho na roça não apresentava futuro. Se quisessem construir uma vida juntos, ele teria que encontrar novos caminhos. Um desses caminhos apareceu quando a saudosa tia Angelina e tio Virgilio o convenceram a vir para São Paulo morar com eles. Ele aqui, ela lá. Como doía esta saudade! Mas valeria a pena.

O trabalho era duro aqui também. Sem estudo nem profissão, as portas eram estreitas. Mas a força de vontade era grande, e com muito sacrifício eles conseguiram se casar e vieram morar na cidade grande dividindo o quintal com parentes.

A pressa era grande e logo tiveram o primeiro filho. Que dificuldade era carregar aquele menino gordinho nos braços subindo a rua de terra poeirenta para visitar as tias.  A mãe ainda era uma menina. O pai então, era O entendido. Dava caldo de feijão nos primeiros meses para o moleque, levava-o para o centro da cidade nos seguros ônibus da época e outras coisas que um pai saindo da adolescência faz.

A vida seguia no ritmo lento, ele estudava e trabalhava, ela cuidava da casa e do filho. Lá fora a Revolução de 64 corria solta, mas eles não se importavam. Não entendiam o que acontecia. Só viam a economia melhorando e novas oportunidades aparecendo. Logo compraram um terreninho com dinheiro emprestado e começaram a construção da casa de quarto e cozinha. O mutirão para pôr a laje apareceu até no jornal. Os bois e cavalos passeavam na porta de vez em quando recordando da vida no sítio. Quantas vezes tiveram que buscar água na chácara que havia perto.

Cinco anos depois do primeiro filho veio a filhinha. Uma menina linda que chegou querendo abraçar o mundo com seus bracinhos como ainda quer até hoje, apesar de já não serem mais bracinhos. Aquariana de gênio forte insistia em brigar com o irmão mais velho que não queria leva-la nos bailinhos.

Os pais já eram mais maduros e a vida já não era tão dura. Tinham até televisão preto e branco. Logo compraram o primeiro carro, um fusquinha meia boca, que quando iam passear no interior, tinha que ir atrás de um caminhão para iluminar o caminho.

Perseguiam firmemente o objetivo de formarem seus filhos com caráter e princípios cristãos. Mesmo que os pequenos prazeres ficassem para depois. Mesmo que a vida fosse monótona e cansativa. Mas eles tinham um ao outro para se apoiarem. Tinham um amor que vencia as dificuldades e os levavam pelo caminho do bem.

Quarenta anos se passaram desde aquele sim trocado na frente de Deus e seus pais. Quarenta anos de luta, tristezas, mas muito mais alegrias. Alcançaram o objetivo como poucos conseguem. Seus filhos, formados, bem casados, lhes deram muitas alegrias. Algumas já têm nome e outras, ainda por vir, também terão.

Ela tem uma bondade extrema. Tanta que precisa distribui-la pelos asilos e hospitais deste mundo. Dedica-se com paixão a Cristo e a comunidade.

Ele ainda batalha para manter a família. Um homem íntegro, carinhoso com esposa. Ainda lhe dá flores no aniversário de casamento.

E assim como viveram até então, ainda vão viver felizes para sempre.

Como manter os processos nessas situações? Não é fácil. No desespero, o bom senso vai para ralo e todos saem correndo para tudo quanto é lado. Coisas como: “Vamos abandonar o ‘daily meeting’! Não podemos perder esse tempo!”, “Vamos microcontrolar os desenvolvedores e suas tarefas!”, “Review e Restrospectiva? Nem pensar nesse prazo que temos…”, e por ai vai.

Passamos por isso recentemente. Todas essas idéias de abandonar o processo ágil surgiram nas intermináveis reuniões que fizemos para tentar endereçar o problema de entregar muito em pouco tempo.

Depois de muito pensar para defender o processo ágil que tanto apreciamos, chegamos a uma forma que, senão ideal pelo manifesto ágil, pelo menos está funcionando razoavelmente.

O projeto é grande e temos quatro times com 5 ou 6 pessoas cada trabalhando em partes do software com alguma dependência entre eles. O prazo é super apertado.

Estabelecemos dois “daily meetings”, um as nove da manhã, o que força todos a chegarem no horário de trabalho, onde cada integrante do time diz o que vai fazer naquele dia e quais são os impedimentos. As dezoito horas fazemos um novo “daily” para que todos digam se as tarefas foram ou não para o “Done” e já planejamos como endereçar as tarefas não terminadas para que no dia seguinte elas possam ser resolvidas definitivamente.

As dezenove horas fazemos um “Scrum of Scrum” com representantes de cada time trabalhando no projeto. Eles falam sobre os problemas enfrentados e sobre o que eles precisam dos outros times.

O “review” está espalhado durante o “sprint”, a cada história terminada, o PO (“Product Owner”) avalia se está “Done” mesmo. Restrospectiva foi para o saco… No final do projeto, se sobrevivermos até lá, faremos uma retrospectiva do projeto como um todo para tentar evitar essas marchas.

Horas extras rolam soltas e débitos técnicos também. Mas tudo está sendo testado exaustivamente para garantir uma qualidade aceitável. O time está ativamente discutindo as histórias tentando simplificá-las e recusando mudanças que o PO apresenta de vez em quando que possam impactar o que já foi feito.

Na correria, algumas integrações de código dão problema. O Git deveria ter um aviso: “Não use se estiver com pressa!”. Mas  toda integração só vai para homologação depois de passar por todos os testes.

Até agora, parece que vamos entregar no prazo. Vai ter muito trabalho depois do lançamento para arrumar a casa, mas o site vai estar no ar na data que o negócio precisa. Não é para isso que nos pagam?

UPDATE: Acho que achei o erro. Configuração do WordPress de privacidade ativado para bloquear buscadores. #fail.

Com um qubit podendo assumir dois estados simultaneamente e toda a complexidade que isso acarreta, quem vai programá-los? A complexidade dos algoritmos e das linguagens necessárias para resolver a classe de problemas adequados à computação quântica pode estar além da capacidade dos atuais programadores. A quebra do paradigma pode ser difícil ou até mesmo impossível para a maioria dos profissionais atuais.

Talvez só a futura geração de programadores, aqueles que ainda não nasceram, dominarão essa nova forma de pensar. Para nós sobrarão os sistemas “legados”…