Camadas de bolo e apps mobile usando javascript e Titanium Appcelerator

Um aviso para que você não perca seu tempo: isto não é um tutorial de Appcelerator, apenas reflexões sobre este tipo de ferramenta baseadas em minha experiência com Titanium Appcelerator. Talvez te ajude a decidir o que usar para desenvolver apps para smartphones e tablets. Ou talvez só te deixe com um pouco de fome, dependendo do horário.

A área de tecnologia se move em saltos muito maiores que outras áreas porque nós usamos muito bem o poder da abstração. Quando uma tarefa é muito complicada de se fazer conseguimos criar uma interface mais simples para essa tarefa, escondendo toda a complicação. Com a complicação escondida em um nível de abstração, essa tarefa pode ser usada como componente de outras tarefas sem que seja necessário pensar muito em seus detalhes.

Isso pode ser observado no desenvolvimento de software com Java, por exemplo. O código Java é um nível de abstração e vai ser compilado para bytecode. O bytecode vai ser rodado por uma máquina virtual que foi escrita e C/C++ e é outro nível de abstração. E o computador executa essa máquina virtual como linguagem de máquina, outro nível de abstração. Esse exemplo poderia ser dividido em vários outros níveis, mas a ideia está aí: cada nível de abstração esconde detalhes para tornar o trabalho de outro nível mais fácil.

Essa é a teoria. Mas muitas vezes um desses níveis de abstração pode não tornar o trabalho mais fácil, ainda mais porque “fácil” é um conceito subjetivo e que depende de contexto. E cada nível aumenta a probabilidade de algo dar errado, porque um erro em um nível mais baixo de abstração vai se propagar para os níveis mais altos. Por isso o valor de usar níveis de abstração não vai necessariamente aumentando a cada nível e por isso não tentamos criar deliberadamente milhões ou infinitos níveis para que o trabalho se torne infinitamente mais fácil.

Eu penso nisso como um bolo com várias coberturas. Na teoria um nível de cobertura deveria tornar o bolo mais gostoso, mais fácil de engolir, mais agradável visualmente. Mas às vezes alguém vai colocar uma camada de chocolate amargo com cacos de vidro e eu não gosto muito de chocolate amargo.

bolo

hmmmmmmmmmmm

Alguns anos atrás estávamos precisando desenvolver apps para iPhone e Android para o Arivo. Como não conheço muito de desenvolvimento para iOS e Android, procurei por soluções que nos ajudassem a acelerar isso, já que precisava ficar mais focado na aplicação web que é a parte principal do Arivo.

Contratar uma agência era uma possibilidade. É um pouco caro demais para o que precisávamos, mas o motivo para não termos escolhido esse caminho não foi financeiro. Nossa aplicação ainda estava mudando muito, o que ia gerar muitas mudanças nas apps e era importante ter mais flexibilidade do que teríamos se contratássemos terceiros para isso. É claro que uma agência iria atender as mudanças no meio do caminho, mas isso ia custar tempo, dinheiro e stress.

Por isso procurei por ferramentas que tornassem esse desenvolvimento mais fácil, ou seja, procurei por algo que me desse um nível de abstração. Além do problema de não conhecer as plataformas iOS e Android, desenvolver para duas plataformas diferentes tomaria muito tempo e esforço. Precisava de algo que me ajudasse a programar apps para as duas plataformas sem ter o trabalho duas vezes.

Existem várias opções no mercado e os critérios que usei, do mais importante para o menos importante:

  • Gerar apps para iOS e Android.
  • Gerar apps nativas. Muitas dessas ferramentas geram apps em HTML5, que na verdade são páginas HTML imitando alguns controles da plataforma, mas que muitas vezes não funcionam exatamente da mesma forma.
  • Usar alguma linguagem de programação que eu conheça bem.
  • Não ter um custo muito alto.

Pesquisei várias opções, como Sencha, RubyMotion, Xamarin, PhoneGap e acabei escolhendo o Titanium Appcelerator. O Appcelerator gera aplicações nativas e usa javascript como linguagem de programação. Pode ser usado gratuitamente mas também tem opções pagas com mais serviços.

No começo, usar o Appcelerator parece um sonho. Criar apps usando javascript ao invés de Objective C e Java sem precisar aprender duas APIs. Rodar as apps nos simuladores, ou em smartphones de verdade, ou gerar os arquivos para envio para a App Store só apertando um botão na IDE. Conseguir desenvolver funcionalidades muito rápido. É a parte doce dessa camada do bolo.

Mas não demora muito para encontrar os cacos de vidro nessa camada.

O primeiro problema é mais uma consequência de gerar apps nativas do que algo causado pela ferramenta. As duas plataformas, iOS e Android tem diferenças de como se comportam e de padrões de interface. Por isso, em alguns casos você tem elementos que se espera aparecerem em uma posição e com um visual que é diferente entre as duas plataformas. O Appcelerator não consegue cuidar automaticamente de todos os casos, então muitas vezes eu preciso enfiar um condicional, um “if (system == ‘android’)” para acertar o resultado final. Poderia uniformizar e ter menos trabalho, mas achava importante respeitar o padrão.

Com o passar do tempo e ao tentar utilizar novas versões é que você começa a encontrar os cacos de vidro maiores e que descem rasgando sua garganta por dentro. Algumas coisas funcionam diferente de uma versão para outra, sem nenhuma documentação sobre essa mudança de comportamento. Você começa a encontrar bugs que foram reportados no fórum do produto e que não foram resolvidos por muitos anos. E você precisa dar um jeito das apps continuarem funcionando para seus clientes, o que significa muita tentativa e erro até conseguir adivinhar como dar uma volta nesses problemas.

Também existem alguns problemas de performance, mas são menores do que esperava de algo que roda javascript. Em celulares de modelos mais antigos a app fica muito lenta a ponto de se tornar um problema de usabilidade. Mas nos atuais funcionam muito bem.

O que é uma pena porque é um produto com muito potencial, e provavelmente se a empresa investisse em qualidade conseguiria resolver todos os problemas. Agora que a Appcelerator foi comparada pela Axway, talvez isso mude, mas eu não vou ficar esperando. No Arivo planejamos criar uma nova versão das apps, provavelmente com uma camada a menos de abstração, mesmo que isso acabe duplicando o trabalho, porque provavelmente muitos dos problemas do Titanium vão ser encontrados nos concorrentes.

Isso é agravado pelo fato de que as próprias plataformas mudam bastante. A cada versão de iOS e Android surgem mudanças e esse tipo de ferramenta que cria um nível a mais de abstração leva um tempo para se adequar e alcançar essas mudanças, ou simplesmente não implementam algumas delas.

No fim diria que não foi um erro usar Titanium Appcelerator, porque ele realmente ajudou com o objetivo de poupar trabalho e lançar rapidamente apps para o Arivo. Mas não recomendaria o uso de uma ferramenta como essa a não ser que a app seja realmente bem simples ou se como nós você tiver a opção de refazer tudo do zero no futuro.

Matem o formato CSV

Se você trabalha com dados já deve ter usado um arquvo CSV. Quase todo programa tem alguma forma de importar ou exportar dados nesse formato, quase como se fosse um padrão.

O arquivo CSV é só um arquivo de texto, em que cada linha contém dados de um registro e cada campo de um registro em uma linha é separado por um caracter separador.

"Nome","Instrumento"
"John Lennon","Guitarra"
"Paul McCartney","Baixo"
"Ringo Stars","Bateria"
"George Harrison","Guitarra"

O formato tem muitas vantagens que o tornaram popular desde os primeiros softwares de planilha eletrônica. É tão simples que um ser humano consegue ler e escrever um CSV usando um editor de texto simples. É fácil de implementar e por isso todo sistema tem alguma forma de importar e exportar dados nesse formato.

Mas é um formato que fazia mais sentido quando não existiam redes e por isso não se trocavam tantos arquivos entre computadores diferentes, sistemas operacionais diferentes e softwares diferentes com configurações regionais diferentes. O arquivo CSV di jeito que existe hoje devia morrer de velho ou ser sacrificado, se isso fosse possível.

O maior problema do formato CSV é a forma como ele lida com encodings. Ele não lida. O programa que lê o arquivo precisa adivinhar o encoding em que os dados foram gravados e às vezes não acertam.

Isso significa que às vezes você vai mandar um arquivo CSV para alguém, ele vai tentar abrir no programa dele e todos os caracteres com acento vão virar um monte de lixo. Ele vai dizer que a culpa é sua de mandar um arquivo corrompido.

Alguns softwares vão abrir em um encoding padrão e se seus dados ficarem todos enfeitados com caracteres ilegíveis, problema seu. Quem mandou você não converter o encoding do arquivo para o encoding usado pelo software. Mas como você ia adivinhar que encoding é esse, se  isso não for uma configuração explícita.

Outro problema é que o caracter usado para separar os dados de registro não precisa ser uma vírgula, como o nome do formato implica (CSV = comma separated values = valores separados por vírgula). Aqui no Brasil mesmo, muitos programas usam o ponto-e-vírgula ao invés da vírgula como padrão.

Mas não existe uma forma de indicar no conteúdo do arquivo qual caracter está sendo usado como separador. Você simplesmente usa o separador que escolher e se ele não for o padrão, na hora de abrir o arquivo em algum programa, reza para que exista alguma forma de escolher qual caracter você usou como separador. Senão vai ter que arrumar uma forma de mudar os separadores do arquivo.

No caso do Windows, o separador padrão para um arquivo CSV é uma configuração regional do sistema. Se se seu amigo canadense te envia um arquivo que ele gerou no Windows dele e tem vírgulas como separadores, talvez você vai ter um trabalho extra para abrir o arquivo em seu sistema operacional com configurações regionais do Brasil e ponto-e-vírgula como separador. E nem todo software vai usar a configuração do sistema.

Você pode ter lido isso tudo e achado que é um problema bobo, fácil de resolver. Basta que a pessoa que vai abrir o arquivo fique responsável por configurar o software que vai abrir o arquivo com o encoding correto e o separador utilizado. Mas essa solução só mostra como esse formato tem um problema grave de usabilidade. Você nunca precisa checar o conteúdo bruto e configurar um software antes de abrir um XML ou um DOC. Esses passos adicionais tomam tempo e aumentam as chances de erro e corrupção de dados.

O software poderia ser responsável por tentar detectar o encoding e o separador. Mas detecção de encoding pode falhar. Detecção do separador também. O que pode gerar corrupção de dados sem que o usuário perceba.

Esses problemas poderiam ser evitados se o formato tivesse sido formalmente padronizado décadas atrás. Existe um documento  que define que o separador deveria ser sempre a vírgula, mas como sabemos isso já não é obedecido. Além disso o documento não se preocupa com o problema de encoding. Mesmo que se preocupasse, já existem tanto software que geram arquivos CSV no formato livre atual, que para fazer alguma diferença, um padrão deveria ter um novo nome e de alguma forma ser adotado em massa pela indústria.

Por conta da longevidade e abrangência da adoção do formato CSV, nós somos reféns dos problemas desses arquivos, obrigados a implementar sistemas que continuem processando esse formato só porque outros sistemas se sentiram na obrigação de dar suporte a CSV, como num círculo vicioso.

Equipes de tecnologia odeiam gerentes não técnicos

Ao conhecer uma pessoa, o profissional de tecnologia começa a classificar: esse pessoa é técnica ou não? Ela já teve que configurar um banco de dados ou uma fila de mensageria? Ela sabe como usar criptografia? Ela consegue entender a arquitetura de um sistema olhando para um diagrama? O quanto ela entende de tecnologia?

Isso não acontece porque técnicos se consideram uma casta diferente que só se relaciona com pessoas da mesma turma. O problema todo se resume à comunicação. Se você precisa explicar algo para uma pessoa que também é técnica, pode levar em conta que ela já sabe conhece algumas informações básicas, e isso torna a explicação mais fácil. E isso torna o trabalho do técnico mais fácil.

Outro problema são as expectativas mágicas que os leigos têm em relação aos técnicos. Por não saber como as coisas funcionam, tentam imaginar como devem funcionar. Por isso na hora de explicar um problema técnico que está tendo, pessoas não técnicas tentam explicar de uma forma que talvez não vá fazer muito sentido para o técnico. Pode ser uma reclamação de que um documento importante sumiu, fazendo o pessoal do CPD perder tempo recuperando o arquivo do backup quando na verdade a janela do Word estava só minimizada.

Por isso, uma situação que cria muita insatisfação é quando o gerente de uma equipe de tecnologia não é uma pessoa com perfil técnico. Normalmente alguém que está no cargo porque tem experiência em gerir pessoas, projetos, clientes. E para muitas empresas, essa estratégia parece natural, já que funciona com outras áreas da empresa, em que os especialistas são os membros da equipe e o gestor só coordena e cobra. Por que a equipe de TI seria especial?

O problema de comunicação entre técnicos e não-técnicos afeta o dia a dia da relação com o gerente. O gerente da equipe é uma das pessoas com que o profissiona de tecnologia mais vai ter que interagir. Se ele não for técnico, você tem esse desgaste a mais de energia tentando explicar conceitos básicos, preparando uma aula só para passar um status do andamento de um projeto.

Dependendo do gerente, suas expectativas mágicas podem causar muito stress para a equipe, principalmente quando ele é responsável por estabelecer os prazos. Para o gerente não-técnico, uma mudança no sistema pode parecer trivial, algo que vai tomar algumas horas. Mas olhando com mais cuidado, um técnico pode detectar que isso vai exigir mudanças grandes que podem tomar meses. E se o gerente não tiver como renegociar esse prazo (ou simplesmente quiser mostrar serviço para seus superiores), a equipe é quem paga o pato de trabalhar fora do horário de serviço para entregar o que foi pedido.

Nem toda empresa pode ou consegue achar alguém com o perfil de gerente técnico. É possível fazer uma equipe técnica e um gerente não-técnico funcionarem juntos, mas é mais difícil. Esse gestor precisa ter humildade e facilidade para aprender um pouco sobre a tecnologia usada por sua equipe, não necessariamente entendendo os detalhes de quem bota a mão na massa, mas o suficiente para entender uma conversa sobre o assunto. Também é importante ter confiança com a equipe, pedindo dos profissionais feedback quando o lado técnico afetar seu trabalho.

Algo que pode ajudar é utilizar a cultura de equipes autogerenciadas, muito difundida na comunidade de métodos ágeis. Nesse caso, o gerente funcionaria mais como um facilitador.

De qualquer forma, ter um gerente técnico pode ajudar muito na hora de contratar novos membros para sua equipe. Na hora da seleção o gerente vai saber o que realmente importa na prática, enquanto o candidato pode se sentir mais motivado de saber que vai trabalhar com alguém que entende o lado dele.

Vale a pena fazer o curso de machine learning do Coursera?

As plataformas de cursos online surgiram nos últimos anos para realizar o sonho de muita gente: poder assistir aulas formuladas pelas melhores universidades do mundo sem precisar sair de casa, enquanto come um Doritos e veste apenas uma cueca. Esse não era meu sonho, mas resolvi que deveria experimentar esse conteúdo pelo menos pela experiência.

Aprendizado de máquina é um assunto que me interessa, por isso resolvi me matricular neste curso gratuito do Coursera. Já havia estudado o assunto antes por conta própria através de livros e até usado um pouco da teoria na prática. Além de poder aprender mais algumas coisas e solidificar o que já tinha visto, essa foi a chance de conhecer e avaliar um conteúdo didático criado em Stanford. É o equivalente para um amante de café ter a chance de experimentar de graça aquele café que é considerado um dos melhores do mundo, feito com grãos retirados das fezes de um roedor que não lembro o nome.

Antes de saber se você deveria fazer este curso é uma boa ideia ter uma noção do que é aprendizado de máquina. E acho que a melhor forma de motivar alguém a conhecer melhor o assunto, é ter uma noção de suas aplicações práticas. Usando machine learning você pode criar software que reconhece objetos em imagens, detecta fraudes em operações financeiras, dirige um automóvel ou drone, avalia o crédito de pessoas, avalia a probabilidade de um paciente ter uma doença, prevê que um servidor pode sofrer uma falha, e muitas outras coisas que parecem mágica. Mas conhecendo melhor sobre o assunto você vai ver que essa lista que fiz é bem limitada.

Depois de se interessar pelo curso, sua preocupação pode ser em saber se você precisa ser um campeão de olimpíada de matemática para conseguir acompanhar o curso. Este é um assunto que usa muita matemática, mas o curso foi pensado para alunos que pelo menos consigam ler uma fórmula com somatórias, matriz e vetores. Existem até aulas opcionais com álgebra linear básica para ajudar com os conceitos que vão ser usados durante as aulas. E graças ao professor Andrew Ng, as aulas são muito didáticas a ponto de ele fazer todos os passos de cálculos necessários nos exemplos. Em casos em que seria necessário um conhecimento matemático maior, o professor dá uma explicação sobre a intuição do que está sendo feito, mas não é exigido que o aluno saiba resolver uma derivada ou decompor uma matriz, por exemplo. Mas minha opinião é que tendo uma base mais do que básica sobre cálculo e álgebra linear vai tornar o conteúdo muito mais fácil de assimilar e entender, sem deixar que alguns passos nos algoritmos pareçam ter aparecido por mágica.

Saber programar é um pré-requisito. Os projetos a entregar são programas escritos em Matlab ou Octave. Mas não é necessário conhecer uma dessas linguagens, pois algumas das aulas vão te ensinar o necessário para realizar todas as tarefas. Eu mesmo nunca havia usado essas linguagens. Apesar de não ser muito difícil de aprender, muitas vezes perdi muito tempo por detalhes da linguagem que causavam erros nas minhas tarefas. Mas o fato de que você só precisar programar o principal das tarefas, com o código que cuida de preparar os dados e mostrar resultados já pronto, facilitou e economizou muito meu tempo, considerando que é um curso que muita gente vai fazer no tempo livre. E o sistema de envio das tarefas com correção automática funciona muito bem. Você resolve cada passo do exercício, envia para o sistema e ele te diz se você acertou ou não.

Um ponto muito positivo é que todo o conteúdo, por ser ensinado pela mesma pessoa, tenta seguir mais ou menos a mesma notação do começo ao fim. Isso ajuda muito para comparar os algoritmos. Quando você tenta aprender cada uma dessas coisas por fontes diferentes, você acaba vendo notações diferentes que dependem da preferência do autor. É como tentar entender uma história que teve uma parte contada por uma pessoa e o final contada por outra, mas a que contou o final só se refere aos envolvidos por apelidos que você não conhecia.

O melhor do curso para mim são as ferramentas que ele ensina para que você entenda se sua solução de machine learning está funcionando bem, e o que você pode fazer para melhorá-la. É esse o conhecimento que eu esperaria de alguém que fosse usar esses algoritmos na prática.

Vejo poucos pontos negativos, que são pequenos perto das qualidades do curso. Algo que me incomoda um pouco são as questões que aparecem no meio dos videos. Muitas vezes eles nem estão testando se você entendeu a teoria que está sendo ensinada, mas verificando se você está acordado e prestou atenção na notação que o professor acabou de usar. Outra coisa que me fez falta, que se deve mais ao formato, é não ter um material que possa consultar facilmente depois. É impraticável procurar no meio dos videos algo que você não lembra direito onde viu, por isso recomendo anotar principalmente as dicas que são baseadas na experiência do professor Andrew.

Talvez algumas pessoas possam se sentir incomodadas pela falta de formalidade técnica que o assunto é tratado, mas considerando que aprendizado de máquina é uma área em que os métodos funcionam mesmo sem os matemáticos entenderem muito bem, acho que o conteúdo habilita alguém a se tornar um praticante. Um conhecimento mais formal seria necessário apenas para quem deseja se tornar um pesquisador na áreae nesse caso este curso funcione bem como uma introdução geral.

Por tudo isso digo que vale muito a pena fazer o curso de machine learning oferecido pela Universidade de Stanford pelo Coursera. Valeria a pena mesmo se fosse pago, sendo grátis eu tenho a vontade de visitar meus amigos programadores e obrigá-los a assistir essas aulas.

Negócios que qualquer programador poderia criar

Depois que o Bill Gates se tornou rico e a profissão de programador se tornou mais conhecida, existe uma expectativa de que pessoas com a habilidade de escrever softwares se tornem empreendedores. Existem incubadoras e investidores nos Estados Unidos que só investem em empresas que têm desenvolvedores em seu time de fundadores. E nos churrascos de família seus parentes estão sempre olhando para você e se perguntando porque você ainda não criou o próximo Facebook.

man-791505_640

“Quando você ficar rico lembra que eu te dei a maior linguiça rs.”

E muitos deles pensam em seguir esse caminho, mas esbarram na desculpa da falta de ideias. Eles olham para o que o Google faz e sentem que não tem capacidade técnica suficiente ou que vão precisar de muita ajuda para construir algo. Ou olham para sistemas que as empresas compram como ERPs, CRMs, sistemas de RH e não entendem os problemas que esses produtos resolvem, e por isso não sabem como poderiam criar algo assim.

Mas um programador não precisa ter PHD em Stanford ou ter sócios que entendem de um domínio muito específico de negócio para criar um produto e começar uma empresa. Existem problemas que já estão a seu alcance, e pessoas dispostas a pagar para resolver esses problemas.

Para ilustrar vou dar exemplos de algumas empresas que começaram com produtos que são tecnicamente muito fáceis de construir. Ideias tão simples que provavelmente já passaram pela cabeça de muito programador, mas que por acharem que era simples demais também devem ter pensado que não teriam como lucrar com elas. Ideias que quando você vê funcionando como empresas, fica se perguntando como não pensou nisso antes (mesmo já tendo pensado nisso).

Buffer

A Buffer é uma ferramenta que posta atualizações em suas redes sociais em horários agendados ou calculados. Sua empresa pode usar a ferramenta para divulgar um link em todas as suas redes sociais sem ter o trabalho de entrar em cada site e postar o conteúdo no horário certo.

O básico desse serviço pode ser feito por um script que execute no horário certo (usando um job de cron por exemplo) e faça chamadas de API para disparar a postagem do conteúdo. E na verdade, foi assim que eles começaram.

Hoje a Buffer tem receita de mais de U$ 600 mil/mês, com pelo menos 46 mil clientes, de acordo com seu dashboard aberto na Baremetrics.

StatusPage

A StatusPage fornece um site onde uma empresa que tem serviços online pode mostrar informações sobre o status de seus serviços, e fornecer atualizações a seus usuários sobre os problemas que estão afetando sua disponibilidade. Por exemplo, o Kickstarter usa o StatusPage para atualizar seus clientes sobre o progresso de alguma correção no site caso ele saia do ar por problemas técnicos.

O serviço deles é basicamente um site, algo que poderia ser feito por alguém que não sabe programar. Bastaria saber configurar um CMS. É um serviço tecnicamente fácil de fornecer.

Mas os clientes da StatusPage vêem valor no que eles oferecem. A última vez que a StatusPage divulgou números de sua receita foi em janeiro de 2014, quando atingiram U$ 25mil/mês.

StoreMapper

A StoreMapper fornece uma busca de lojas físicas para que um comércio que tenha vários endereços ou fábrica que fornece produtos para várias lojas permitam que um cliente encontre um endereço onde pode fazer a compra usando seu site.

Criar algo assim poderia ser muito complexo, a não ser que você fizesse como a StoreMapper e usasse a API do Google Maps para exibir os resultados. Isso torna a implementação do serviço muito mais fácil.

Atualmente a StoreMapper tem 889 clientes e receita de U$ 15 mil/mês, de acordo com seu dashboard aberto no BareMetrics.

A sua ideia

Que fique claro que não estou dizendo que é fácil criar uma empresa. O básico de cada exemplo que listei pode ser implementado por qualquer programador, mas é claro que com o tempo esses empreendedores foram melhorando o produto para que ele forneça muito mais valor a seus clientes. Além disso, o sucesso de uma empresa não depende só da parte técnica.

O que quero dizer é que boas ideias para negócios podem vir de problemas que estão a seu redor e que podem ter soluções simples que estão ao seu alcance.

O desafio do software simples de gerenciamento de projetos

Todas as pessoas têm projetos. Desde o casal planejando o casamento, passando pelo designer criando um novo site para um restaurante até uma empresa que vai construir uma nova turbina. E é por isso que existem tantos softwares nessa categoria.

Castelo de areia

Projeto Castelo de Areia 3. Os outros tiveram problema de scheduling e budget.

Mas projetos têm diferenças em escala e natureza, e variam demais dependendo de quem os executa ou em que área se aplicam. Por isso existem, dentro da categoria de softwares de gestão de projetos, diversos subtipos. Existem sistemas para quem quer aplicar tudo o que aprenderam em um curso certificado internacionalmente de gestão de projetos e existem os mais simples e genéricos que ajudam grupos menores a se organizar.

Os sistemas mais complexos normalmente têm uma única forma certa de serem usados. Seguem as práticas do PMBOK e outras técnicas mais específicas ensinadas em cursos de MBA ao redor do mundo. São ferramentas vendidas aos CIOs que querem aplicar essa teoria que aprenderam. A maioria dos usuários não tem muita opção, são forçados a usar o sistema que o chefe do chefe deles escolheu.

Para capturar o mercado que esses sistemas complexos ignoram, surgiram muitas ferramentas mais simples para gerenciamento de projetos. A maioria deles parece com uma lista de tarefas suplementada com recursos para facilitar a colaboração com outras pessoas. É o mundo das pessoas que só precisam saber o que precisa ser feito e o que foi feito. Pessoas que normalmente não gostam ou não sabem usar um gráfico de Gantt.

Esses softwares mais simples têm como mercado alvo principal empresas menores, profissionais liberais ou até grupos ou indivíduos sem ligação com uma entidade com fins lucrativos. Por isso são mais baratos, às vezes até de graça.

Exemplos desses sistemas mais simples: Basecamp, Asana, Flow e Runrun.it.

Diferente dos sistemas mais complexos, esses softwares costumam ser adotados pela equipe, não forçados como uma decisão hierárquica para toda a organização. Mas isso, combinado com seu preço baixo e a natureza simples de suas interfaces, pode ser uma faca de dois gumes.

Hoje em dia todo software vendido pela internet tem a palavra “simples” ou “fácil” no texto de seu marketing. A ideia é que empresas menores não querem comprar algo que vá exigir treinamento, querem uma ferramenta que um leigo vá bater o olho e intuitivamente possa usar, ou algo bem próximo disso. Todos esses sistemas de gerenciamento são vendidos assim.

Existem infinitas maneiras de se organizar para conduzir um projeto. E projetos, dependendo de sua natureza, podem exigir peculiaridades para que tenham esse tipo de controle. Essas ferramentas optaram por simplicidade para oferecer flexibilidade, para que possam ser usadas na maior variedade de projetos possíveis. Mas existe uma linha tênue entre ser simples e ser genérico demais.

Algumas pessoas vão olhar para esses softwares e achar que são genéricos demais, que não fornecem estrutura ao trabalho suficiente para auxiliar o andamento de um projeto. Eles dependem de disciplina de quem vai usá-los. O sistemas mais complexos são impostos, os mais simples precisam lutar para que a equipe não tenha um motivo para trocar para outra ferramenta do mesmo tipo, já que seu custo não vai ser muito diferente.

E o maior desafio é que eles dependem da disciplina da maioria dos membros da equipe. Se alguns membros não alimentam o sistema da forma como a equipe espera que o façam, o sistema se torna inútil. A adoção sempre fica limitada ao limite da paciência dos membros menos organizados e disciplinados. Esses membros poderiam ser ejetados da equipe, mas isso nem sempre é possível e o custo de experimentar outra ferramenta é sempre menor.

Isso criou a figura do “chato do Basecamp” ou “polícia do Asana”, ou qualquer coisa equivalente para sua ferramenta. É a pessoa que precisa cobrar os outros membros para que eles usem corretamente o software.

No final, mesmo sendo genéricos, essas ferramentas acabam tendo formas mais otimizadas de serem utilizadas de acordo com a forma como foi montada a experiência de usuário. Mas a maioria das pessoas é resistente a ideia de mudar a forma como gosta de trabalhar só para se adequar ao fluxo de uma ferramenta que eles nem sabem se vai lhes dar algum retorno. Por isso essas ferramentas tentam não fazer o que os softwares maiores e mais complexos fazem que é vender uma solução casada com uma metodologia fechada.

Esses desafios abrem espaço no mercado para ferramentas que sejam construídas com nichos mais específicos desde sua concepção.

Já usei várias dessas ferramentas em diversos projetos e não pode dizer que as acho ruins. Só que o fato de que elas são intercambiáveis, alguém poderia ter escolhido outro software da mesma categoria e o projeto teria o mesmo resultado, mostra que ainda não temos uma ferramenta definitiva. Não temos o Microsoft Office ou Google da gestão de projetos.

E talvez isso seja impossível pela diversidade de formas de se trabalhar, ou precise realmente ser fragmentado para formas otimizadas para cada tipo de projeto que precisem ser vendidas junto da ferramenta, ou ainda, pensar em como construir uma solução que atenda bem até as pessoas que não querem usá-la mas fazem parte do projeto. Enquanto isso, eu continuo na minha busca pelo software perfeito para mim.

Sua Liderança Molda a Cultura De Sua Empresa (E Não O Fliperama Na Sala De Recreação)

Escrevi um post no blog da Arivo que achei que seria relevante postar aqui. Não se aplica apenas a TI, mas muitas do que escrevi foi baseado no que eu vejo na área.

Aqui está o link:

https://arivo.com.br/blog/blog/2013/11/21/sua-lideranca-molda-a-cultura-de-sua-empresa-e-nao-o-fliperama-na-sala-de-recreacao/