Voo Livre

A beleza do empreendedorismo é de que tudo é possível.

A beleza da TI é que abrange qualquer coisa, no mundo imaterial.

Chega a transformar o físico em digital. Tudo que diz respeito a escrita, por exemplo, pode ser conduzido por meio digital. A reprodução em meio físico é um mero conforto para os que ainda não se acostumaram a ler nas mídias digitais. Salvem as árvores! Mais oxigênio para o mundo.

Estamos nos primórdios dos tempos, ainda há muita mudança a desafiar. Fico imaginando a transformação que ocorrerá na logística. A entrega de mercadorias ainda é uma grande barreira, de custo e de gestão. Grandes transformadores de negócio pensam nos meios de entrega, a partir de drones, carros sem motorista e possivelmente outros meios que não envolvam pessoas e transportes convencionais.

Penso no conceito de micro fábricas. Acredito que alguém vai inventar um jeito de transferir digitalmente os pedidos dos consumidores para centros locais de distribuição, próximos ao consumidor onde os produtos serão materializados em tempo real usando máquinas e robôs. É como se você escolhesse a sua roupa pela seu dispositivo eletrônico preferido, na loja de sua preferência e esta, por sua vez, enviasse um comando para uma micro fábrica instalada próximo a sua residência, e reproduzisse a roupa no mesmo instante. Uma evolução da idéia da impressora 3D, do fax que cuspia o papel do outro lado da linha. Talvez vai chegar o tempo onde você teria a sua própria micro fábrica em casa!

De qualquer forma será preciso distribuir a matéria prima. Mas resolvo isto num instante! Teremos micro fábricas de produzir tecido, a partir do fio. E o fio? mais micro fábricas...

Sei que alguém deve estar pensando que é preciso me internar. A beleza do empreendedorismo é que... vai que acontece.

Empreendedor é teimoso quando é persistente mas a idéia não dá certo. E se funcionar, é um gênio!

Gostaria que as transformações chegassem ao modelo de governo. Algo que permitisse aos povos retirar do poder rapidamente os que não atendem aos anseios da sociedade. Que pudéssemos ficar imunes a corruptos, a incendiários, a ditadores, a gestores de causa própria, aos que pensam no seu bolso e dos amigos. O mundo já tem problemas suficientes a enfrentar para sua sobrevivência e para melhorar as condições de vida de seus habitantes. Imagine um App que fizesse isto! Um rápido clique e pronto: temos uma nova esperança.

Comunicar é preciso

Se pudesse recomendar mudança em currículo para quem faz informática eu sugeriria incluir a matéria comunicação.

A comunicação é tão importante no resultado final do projeto quanto é ter um boa definição dos processos e a sua implementação.

Outro dia, chamei uma viagem no Uber e o aplicativo me respondeu que o motorista estava 11 minutos de distância. Achei muito e resolvi cancelar. Que desespero! Onde estava o botão de cancelamento? Sabia que tinha um tempo para acionar o cancelamento antes que fosse cobrado. Além do mais, tinha decidido ir até a rua principal e pegar um taxi. Depois de clicar em "tudo" três ou mais vezes acabei encontrando o link. Foi um stress.

Pois é, antes de reclamar, preciso olhar para meu umbigo. Em primeiro lugar, temos que entregar o que prometemos. E como sempre digo, para entregar é preciso prometer, ou seja, deixar claro o que vamos fazer. A questão da comunicação trata do "como".

Depois de muitos projetos cheguei a conclusão que o melhor modelo é o que inclui apresentar um protótipo para a solução. Quero que o usuário veja a estrutura de navegação e comunicação que estamos propondo para resolver o seu processo. Como procuramos projetar processos independentes para os diferentes perfis de negócio, o protótipo deve considerar cada perfil.

Temos que ter o cuidado com os nomes dos labels que utilizamos. Existe informação mais perigosa do que solicitar uma data? Data de quê? Invariavelmente a resposta de qual data requer que o analista recorra ao código para "lembrar" do que se trata. Coitado do usuário! Talvez devêssemos ensina-lo a ler código.

A tangibilização da solução através da prototipação traz outros benefícios colaterais, como, por exemplo, a visão se o processo está completo e maduro. Ao navegar - sim! o protótipo precisa ser navegável - o usuário lembra do que ficou faltando na etapa de levantamento. Às vezes, o mecanismo de comunicação que pensamos não se aplica ao volume real de transações. O usuário rapidamente observa as dificuldades. É muito melhor do que descobrir algumas centenas de horas de codificação depois.

Na minha visão o protótipo é importante para qualquer tamanho de projeto. Seja de poucas semanas a muitos meses. É importante para metodologia de desenvolvimento em cascata mas também para o desenvolvimento ágil. Neste último, ao menos antes de cada sprint. Aumenta o projeto? talvez. Mas o resultado é muito mais aderente à expectativa do usuário.

Produtividade em TI

Recentemente saiu um estudo sobre a produtividade do brasileiro em relação aos trabalhadores de outros países.

Somos seis vezes menos produtivos que o primeiro da lista, a Noruega.
Ou seja, o norueguês pode ganhar até seis vezes mais que ainda assim produzirá igual ou melhor que nossos trabalhadores, em média.

Trouxe este tema para reflexão dentro da TI.

Será que um norueguês codifica seis vezes mais rápido que o brasileiro? Certamente não. Provavelmente a produção de código de programa deve ser parecida.

A diferença está na qualidade da entrega e não na quantidade.

A nossa entrega está preocupada com o funcionamento do projeto, nas condições ditas normais de uso - sendo "normal" o que o analista entende por isto.
A deles está preocupada com a maior quantidade possível de ações que o usuário poderia fazer durante o uso do projeto, de forma a tornar o projeto 99% imune a erros, ou, no limite, informando da existência de uma situação não desejada.

O resultado é que o norueguês estará pronto para iniciar o próximo projeto, sem praticamente ser interrompido, enquanto que nós estaremos nos debruçando sobre um mar de ajustes no projeto recém entregue. É quase impossível estabelecer o prazo para o próximo projeto, dado que a quantidade de interrupções não é passível de ser dimensionada.

O que seria eventual - um incidente numa situação muito especial - se torna corriqueiro. Os ajustes vão sendo solicitados a medida que o usuário passa pelas diferentes funcionalidades do projeto. Entra ano, sai ano, o projeto ainda apresenta inconsistências.

Na prática, por aqui, a atividade de sustentação de um projeto acaba sendo a principal da equipe de TI.

Existem ferramentas de planejamento e métodos de trabalho para lidar com esta questão e minimizar o cenário descrito, mas o fato relevante que dificulta a mudança é o cultural.

Nós temos que entender que o projeto é um processo com vida própria, e que a nossa responsabilidade está em projetá-lo para sobreviver num ambiente onde não há uma única ordem e previsibilidade.

A mudança cultural é difícil mas é preciso enfrentá-la pois o gap está ficando cada vez maior e pode se tornar irreversível.