Blog do Andre Fonseca

Muito tenho escutado neste últimos dias sobre a questão do sucesso ou não do uso de metodologias ágeis.Principalmente com relação a entregas. Primeiro preciso dizer que não sou um doutor no assunto, nem pretendo ser, muito menos um profundo conhecedor, mas considero que tenho uma pequena vivência no assunto que me permite tecer alguns comentários sobre o assunto.

A poucos dias atrás eu deu uma palestra numa PythonCampus ( foi na Estácio de Madureira) para um público de cerca de 50 a 80 pessoas.  Nessa palestra, mesmo que o tema principal tenha sido falar de como fazer grandes produtos em python, aproveitei para passar alguns pontos de vista para a galera que está começando agora.

Antes de mais nada é válido dizer que apesar que já está a um bom tempo na estrada, por várias vezes me sinto como eles: sem saber para que lado “atirar”.  Hoje, como profissionais de TI, somos bombardeados a todo momento com toneladas de post de blogs, twitters, artigos, livros, lista, etc dizendo qual será ou quais serão as próximas grandes tecnologias do momento.  Frente a esse quantidade exagerada de coisas, ficamos num “mato sem cachorro” tentando dimensionar nosso tempo para investir em algo que nos garanta um bom futuro.

Bem frente a isso, tenho um péssima notícia: não tem uma resposta pronta, somente o famoso depende. Cada caso vai pedir uma coisa meu caro e quanto mais saber mais opções terá e com isso, mais chance de acertar a escolha.

Embora o assunto seja fascinante e dê “pano para a manga”, o que gostaria aqui, hoje, de falar é quanto a reaproveita conhecimento.

Voltando ao assunto da PythonCampus, durante a apresentação aproveitei para pergunta para a galera presente, como um pequeno censo, quantos usavam determinadas linguagem. As duas que foram mais votadas foram java e .Net. Um brve parenteses antes de continuar: Ao contrário do que a maioria pensa . NET  não é uma linguagem e sim uma plataforma de desenvolvimento. Tanto que existe muitas linguagens que foram feitas para rodar dentro do .NET (C#, ASP.NET, VB.NET, IronRuby, IronPython, etc).

Dado que o mercado ainda demanda por profissionais que saibam usar essas duas tecnologias, .NET e Java, fiquei pensando como seria que uma pessoa poderia dar o passo adiante rumo a uma coisa mais produtiva e diferente.  Quando falamos com alguém que a vida toda trabalhou com Freelas (aqueles projetos pessoais que a gente cobra; aquele site do tio- entendeu?) e  que por isso usou bastante PHP, por exemplo, fica mais fácil apresentar para ele Python e Rails ; a pessoa já está acostumada com aquela natureza dinâmica e não burocrática e agora apenas aprenderá algo com mais ordem e etc.

Mas quando falamos de caras de Java, vem logo a imagem daquele moleque andando de roupa social  ou terno pelo centro do rio e trabalhando em grandes consultorias que cobram os olhos da fuça para fazer um helloworld e ainda por cima não entregam no prazo e nem perto do que o usuário queria.  Antes que me atirem pedras ou coisas afins, eu sei que nem toda a culpa é da linguagem tem muito do profissional.  Tendo essa perfil em mente, fica díficil converser aquele cara que ele deve aprender outro coisa. Ele não quer se esforçar muito mais e fica colocando defeito nas coisas para justificar sua preguiça.

Diante esse cenário caótico fiquei matutando um jeito que poderia servir de transição suave e assim, sem grandes revoluções e sim evoluções, levaria aquele cara para dentro de um mundo novo de possibilidades.

Para o caso do java, graças ao grande oraculo, aka Google, eu encontrei o Grails. o Grails é um spin off do raisl para a plataforma java usando a linguagem Groovy que roda dentro da JVM.  O GRails é uma implementação do rails em groovy. Segundo o próprio site do produto é rails melhorado pois pegar o que há de melhor e aprimorar frente as experiências da galera.

A parada é realmente boa e vale a pena baixar e testar. Com a vantagem de ainda ser Java embora a sintaxe do groovy seja muito produtiva caso resolva se lançar de cabeça. Assim como em Ruby on Rails, como muita pouca linha de código você consegue ter um site no ar.

Bem essa volta toda para dizer para a galera acordar para as coisas que estão acontecendo, para acordarem que não terão vida fácil,  não existe mais a linguagem solução e sim uma caixa de ferramenta e por aí segue.

Quem lida com desenvolvimento de sistemas o tempo todo, ainda mais quando tem uma certa experiência – ou até é o mais experiente do grupo, sabe que o tempo todo deverá tomar decisões. Decisões estas de natureza diversa: desde uma contratação, uma demissão, quais tecnologias, qual arquitetura, licenças(argh), etc.  Claro, pelo menos no meio que convivo, as decisões de carater mais técnico tendem a ser mais “leves”  e, erroneamente, não é dada a devida importância ou seriedade que o assunto merece. Isso tem impacto direto sobre muitos produtos “estranhos”que acabam sendo entregues que, para o usuário leigo, pode até passar desapercebido porém alguém com perfil mais técnico chega a ser gritante.

Imagine você que seu time está começando um novo projeto. O dono do produto começa a conversar de forma ampla do que ele espera e das interações que ele espera que os usuários terão, etc. Ele aproveita e também fala sobre a quantidade de acesso que ele espera para aquilo, tempos de respostas, etc. Quem é desenvolvedor, assim como eu, nessas horas não consegue escapar de ir já imaginando a arquitetura do projeto, como as coisas vão interagir, etc. Pela experiência que tenho isso pode ser uma armadilha fatal.

Otimizações e arquitetura prematuras, no meu ponto de vista, são uma das maiores fontes de problemas de projetos. Dentro do príncipio Lean (justo necessário) de desenvolvimento, devemos nos ater aos problemas que existem e não aos que existirão. Fazer a coisa de forma a facilitar evoluções sim mas não “dê um passo maior que a perna”. O que vejo são verdadeiro monstros de empilhamento para um requisito de baixo número de usuários, zero de evolução, etc. Um exemplo para facilitar: Imagina que o cliente quer que você faça um site para empresa dele. Esse site será pouco acessado e servirá apenas, num primeiro momento, para ser uma página informativa da empresa. Num futuro, assim que os negócios decolarem, ele irá desenvolver uma mega ferramenta, mas não agora… já vi muito gente fazendo sistemas em mil camadas, com cache, banco de dados oracle mega 3 plus, etc… Sendo que, se fizesse tudo com html estático, funcionaria perfeitamente.

Prefiro que as coisas evoluam organicamente. Isso significa dizer, que a medida da necessidade as coisas vão sendo alteradas para melhor atender. Novamente insisto que também não é para fazer uma parada em html e depois querer com pouco esforço torná-lo dinâmico.  Pense em Darwin: evolução é perpetuação do mais aptos ao ambiente.  Simplificando seria que a medida que nossos sistemas vão crescendo vamos deixando as coisas que funcionam bem dentro daquele contexto de requisitos e vamos alterando ou trocando as coisas contrárias.

Diante de tudo dito acima, fica claro que bom sistemas são aqueles que mudam !!! Não pense que conseguirá fazer uma aplicação mágica que será capaz, depois de  ”pronta”, de se adaptar a todos cenários possíveis. Até porque precisamos de trabalho né . Software não é como um prédio, associação que muitos fizeram e fazem erroneamente . Software está muito mais parecido com algo orgânico que vai crescendo e sofrendo mutações.

Num próximo artigo pretendo trazer a questão do empilhamento e horizontalidade. Essas duas coisinhas que quase ninguém sabe ao certo os seus reais valores e como (e quando) usá-los.

Acontecimentos recentes no mercado de automóveis, de uma forma surpreendente, tem colocado em xeque o modelo da Toyota que ficou famoso se tornou  uma referência em gestão e processos na última década.  O pessoal que tem lido jornal tem visto esses dias várias notícias informando a enorme quantidade de recall que a fábrica toyota e suas afiliadas estão fazendo no Japão e no mundo, decorrente de erros nos seus processo de fabricação,  laudos fradulentos de segurança, etc.  Tudo isso colocou em dúvida a verdadeira eficiência do modelo que se tornou a nova moda dos hippies da administração e processos do mundo.

No início do século XX  o mundo vivia sua revolução industrial impulsionado pela novo modelo Ford de produção em escala.  Em detrimento ao maneiro artesanal e caseira da fazer as coisas que tornavam os produtos “incrivelmente caros”, agora tudo é feito em grande quantidade e de forma seriada. Surge as fábricas.   Esse modelo ultrapassa o contexto industrial e começa a permear todo o comportamento social:  convívios, formas de negócio,  gestão e administração, etc.  Tudo agora deve ser grande; gigante… Não existe espaço mais para pequenos atos.  Empresa familiares dão lugar para grandes corporações, pequenos negócios de esquina agora fazem parte de cadeias de lojas e por aí seguimos.

Com a vinda da segunda guerra mundial, em nome do esforço de guerra, esse modelo de grande escala ganha mais força: tudo deve ser feito aos milhões.  Pequenos defeitos e erros de cálculos são tolerados pois, estatisticamente, representam uma porcentagem infinitesimal frente ao todo.  Porém do outro lado do mundo, ao final do conflito, existia um Japão arrasado, sem homens, sem recursos naturais abundantes, sem espaço, destruído por duas bombas nucleares.  Nesse país um sonhador  vindo de uma família de empreendedores tenta construir um futuro. Assim nasce a Toyota.

A Toyota, (diversas fontes dizem que ela foi fundada em 1937, porém acredito que a sombra da empresa que conhecemos hoje começou no pós-guerra)  ao contrário da Ford (a grande Ford com suas imensas indústrias no USA)  estava num contexto de escassez. Tudo faltava.  Não havia aço, não havia homens, faltava tudo… Não existia espaço para desperdício. Não havia margens para erro.  Usando toda a herança cultural japonesa de perfeição,  a Toyota criou todo um universo de processos visando a redução e até a eliminação total de todo e qualquer processo ou coisa que não gerasse valor para o cliente final dela.

Nos anos que seguiram esse conjunto de boas práticas e regras se mostrou extremamente vencedor e hoje a Toyota é maior fabricante de carros do mundo superando  de longe qualquer outra.  Hoje eles são os melhores, a referência,  a meta a atingir.

Assim como o modelo Ford, nos seus áureos tempos, ultrapassou os limites  das fábricas para fazer parte de tudo na cotidiano das pessoas, o modelo toyota também achou seu caminho em outras áreas como administração, gestão de projetos, desenvolvimento, etc.  Da década de 80 a até atuais dias passou a ser o hippie do momento, o novo frisson dos intelectuais e vanguardistas do mercado.  Não tardou para que a “forma Toyota” de fazer as coisas fosse traduzida para outras realidades. Principalmente em desenvolvimento de softwares que até esse momento era predominantemente  do jeito Ford com conceito de fábricas de software e encadeamento de atividades (o famigerado cascata – waterfall).

Logo nosso dia a dia de desenvolvedores e gestores de projetos deixou de ser sopas de letrinhas como PMI, CMM, RUP, UML , etc para ser JIT (Just in Time – o justo na hora certa),  KANBAN,  cadeia de valores, etc.

Entretanto, nos últimos anos, notícias de que a Toyota estaria fazendo recalls se tornaram frequentes nos jornais do mundo. Recall é o processo que a empresa chamada todos os usuários (compradores) de um determinado produto a o levarem de volta para consertar algo que possua um defeito de fabricação oriundo de erros de projeto, processo, etc.   por mais transparente e honesto que seja o processo, ele sempre acaba manchando a reputação da empresa… Isso só fica pior quando falamos de uma empresa que “vende” que tudo que faz é perfeito (isso também vem da própria cultura japonesa).  Tais fatos sairam do ambito da economia para entrarem no ambito da gestão, pois  muito se vendeu nos últimos tempos que o processo Ford não funciona e que a salvação era o Sistema Toyota.

Seguidores  estão em panico pois tais fatos colocam em xeque seu grande salvador.  Mas será que realmente que esses acontecimentos são o sinal que esse processo não é tão bom quanto pensávamos? Será que devemos procurar um novo jeito? Será que devemos voltar ao que “funcionava” antes? E agora quem poderá nos ajudar?

Confesso que gostaria de ter essa resposta mas acho que somente o tempo dirá, embora, acredite numa máxima de Buda : ” o caminho sempre será o equilíbrio” . Possívelmente esse seja um processo pelo qual o mercado precise passar para deixar de criar “balas de prata” e passe a usar a inteligencia de seus profissionais para resolver cada problema.  Não existe solução única. Existe é inteligência, criatividade e vontade de evoluir.

Agora tais problemas também podem ser  culpa de um processo mal gerido de crescimento onde os atuais administradores da empresa esteja rompendo com as bases culturais que nortearam a empresa até hoje.  Eu vi um processo semelhante a esse acontecer dentro da michelin com a morte dos herdeiros naturais da empresa.  Por isso, mais uma vez a cautela e prudência são as melhores amigas nesse momento ao analisar os fatos.

Penso que é preciso olhar com a mente aberta aos fatos e se permitir questionar. Fé cega a gente deixa para as religiões.

Participo de uma lista de discussão e por estes dias surgiu uma troca de e-mail cujo o assunto final foi a questão da segurança na aplicação.  Dentro do acalorado debate,  apareceram os que são a favor de considerar a segurança na aplicação e outros que acham que isso é um exagero.  Teve até quem disse, que segurança é “manter os funcionários felizes”.

A nossa dependência dos sistemas é cada vez maior. É também cada vez maior a quantidade de informações sobre a nossa pessoa que estão nas “nuvens”.  Diante disso é impossível dizer que a segurança da informação não é um assunto importante.  Não faltam hacker dispostos a roubar nossas senhas, encher nossas caixas de e-mail com spams, nos infectar com algum “vírus” capaz destruir, etc.  O mundo virtual  já foi um lugar mais seguro.

Pensando em nossa aplicações …primeiro, temos que evitar as otimizações prematuras… Vejo muito sistema sendo feito por aí em que o time de desenvolvedores acabam se afastando dos requisitos do cliente e criam verdadeiros monstros  - do ponto de vista de retorno de investimento, manutenção e etc – que não agradam a ninguém. Nisso eu incluo a questão da segurança.  Não pode dar o mesmo peso para segurança para um sistema financeiro e um outro que apenas encurta a Url.

Por isso a discussão é válida desde que a coloquemos dentro do contexto correto.  Isso não significa que jamais devemos pensar em fazer sistemas seguros.  Quero dizer que devemos dosar.   Essa é a mais difícil das tarefas.  Pois muitos podem dizer que o esforço de fazer será o mesmo esforço de fazer muito ( exemplo: o esforço para criptografar os dados do banco é tal que se torna interessante fazer também o trabalho de senhas e esquemas também).

Devemos fazer sistemas para o mundo real. Nele, sempre terá alguém mal intencionado capaz de fazer um ação danosa.  Por isso, backup, proteção de senha, etc fazem parte da discussão de arquitetura da aplicação, mas novamente, tendo o cuidado de dosar evitando os excessos. Um bom começo seria listar quais ações que podem ser tomadas, quantificá-las, qualificá-las (por complexidade,  custo, retorno, etc), e outras coisas afins.  Tendo a lista podemos apresentá-la para o cliente e, uma vez que o assunto é mais técnico,  tentar mostrar os prós e contra de investir nisso para o cliente. No final a decisão é dele.

Agora,  uma coisa que acredito e espero que seja um senso comum,  são os problemas de simples solução que já fazem parte de nosso folclore. Coisas do genêro de SQL Injection, senhas fortes, dados de cpf e afins criptografados, no meu entender,  devem ser tratados dentro do desenvolvimento mesmo que não haja uma anuência clara do cliente. Esses problemas são conhecidos e por muitas vezes, numa discussão de escopo, eles ficam subentendidos.  Ou deixa claro que não irá fazer e explica o motivo e já inclui o esforço nas estimativas.

Questões de diretórios,  permissões de escritas, proteção de arquivos de configurações, esses sim podem ser negociados e eu pessoal acho que deve.  Lembrando de nunca esquecer de achar a dosagem certa. Como dizem alguns farmacêutico: a diferença entre o remédio e o veneno é a dose.

No fim, o famoso bom senso reina absoluto novamente.

No meu trabalho precisei realizar uma tarefa que consistia em pegar um arquivo xml e gerar um outro arquivo, também em xml,  a partir dos dados do primeiro.  A princípio pediram que fizesse “na mão” mas como sou pago para pensar e não para executar as coisas feito uma máquina, parti para criar algo que fizesse isso de forma automática.

Para fazer o trabalho criei um script em Groovy por ter uma certa intimidade com a linguagem e pela facilidade que ela oferece para manipular dados em formato xml (veja o trecho abaixo).

O script após pronto funcionou perfeitamente, porém com um problema residente no fato do arquivo de saída ter sido salvo com codificação padrão do sistema operacional (o lixo do Microsoft grava tudo em ANSI ).  No primeiro teste que fiz com os dados acusou o erro com caracteres acentuados.

O desafio foi achar uma forma, simples, de alterar o encoding do arquivo de saída para o valor que eu quero. Após muitas pesquisas no google, leituras de doc, etc… A solução extremamente elegante que achei foi (veja trecho abaixo).

Aqui você informe que ao invés do objeto file usar um writer com valor de caracter padrão, ele deve usar um que use o UTF-8. Para quem está familiarizado com padrões de projeto é um Decorator.

O ser humano por mais desbravador e aventureiro que seja seu espírito ( estamos tentando ir para todo lado, entender tudo, etc)  sempre vive um desconforto frente a possibilidade de experimentar o novo.  Que criança nunca “torceu o nariz” quando a mãe mandava provar uma comida que não tinha visto antes; que pessoa num recuou frente a um possibilidade de ir em direção a uma oportunidade nova; quem nunca sentiu insegurança quando se formou e agora terá de enfrentar um mundo novo…  O problema é quando esse desconforto virá medo paralisante e inconscientemente nos tornamos agressivos com relação aos agentes da mudança.

Temos vivido um momento muito interessante dentro do mercado de TI : todo o processo, o “como fazer”, qualidade, e muitas outras coisas, tem sido questionado, paradigmas quebrados, novos processos, novas metodologias, novas linguagens, e muitas outras que se continuasse poderia facilmente escrever páginas e mais páginas só com a lista.  Isso acaba gerando um estado de CAOS (caos não é desordem, é ausencia de ordem) , num sentido que não existe uma forma única de fazer mais nada. Isso é algo ímpar e altamente interessantes pois as possibilidades são quase que infinitas.  Por outro lado, para o pessoal menos aberto a mudanças, ou até menos preparado para oque está acontecendo, isso representa uma “escuridão” plena, na qual não é possível enxergar o terreno por onde se caminha. O medo, ou melhor, o receio não é algo ruim, nem deve ser evitado, ele é um recurso importante de nossa inteligência pois nos impede de colocar a “mão na aranha e ser picado”, mas ele não pode ser nunca paralisante.

O receio frente a mudanças deve ser tratado com serenidade e inteligência, onde um bom primeiro passo seria procurar entender melhor essa novidade. Além de entendê-la verificar se ela trará algum valor para seu trabalho ou empresa. E por fim, dar um chance, verdadeira (famoso coração aberto, mente aberta, entrega total) a proposta e vivenciando num universo controlado julgá-la. Em diversos casos relatados por colegas que tentaram trazer novidades, ou fizeram consultorias contratadas para promover algum tipo de mudança, e outras possibilidades,  sempre ouvi exemplos de reativos: pessoas que se recusavam a ouvir, entender e até mesmo tentar aquilo. Alguns partiam para atitudes agressivas, criticando de forma cega e tendo atitudes de sabotagem.

Quando o medo (receio) frente a mudança se torna agressividade – agressividade aqui diz respeito ao bloqueio e criticas mordazes -  isso acaba virando um jogo perigoso e, em minha opinião, NUNCA é (ou será) bom para nenhuma empresa.  Em muitos casos,  as coisa ficam num clima de guerra onde existe o pessoal que defende a mudança “com unhas e dentes” e outros que contrariam as mudanças “com unhas e dentes” .  Sei que existem milhares de técnicas, dinâmicas, e outras coisas, que podem miticar esse clima, mas um vez esse ambiente criado sempre existirá um desgaste que poderia ser evitado se as pessoas agissem como humanos e fossem mais desbravadoras.

Antes que confundam e passem a pensar que estou incentivando a aceitar toda e qualquer mudança, quero dizer que não sou a favor de sairmos agora experimentando tudo de novo que for divulgado ou criado.  Ainda acredito na questão da sustentabilidade – empresas que são muito vanguardistas  acabam pagando um preço de falta de profissionais e manutenabilidade no longo prazo, por exemplo – embora também penso que, profissionais principalmente de TI, devem sempre estar estudando e lendo sobre as novidades que estão surgindo até mesmo para ter uma opinião concreta sobre o assunto e um dia decidir se vale ou não a pena usar aquilo.

Como sempre digo, o caminho sempre estará no meio.   Ser fechado e averso a tudo novo e agir de forma agressiva ( criticando, trabalhando para falhar a iniciativa, defamando as pessoas, etc) é estupidez e uma tremenda burrice. Agora ser um viciado em novidades e sair usando versões noturna (nightbuilds) de tudoé loucura e inconsequência juvenil demais para um profissional.  Ponderar entre o já conhecido e sob controle e a novidade é algo que só traz benefícios e exemplos disso não faltam no mercado.

Todo mundo sonha em um dia ter algo que possa dar dinheiro ou sucesso sem fazer  grandes esforços. Nesse desejo muitas empresas e pessoas lucram bilhões com vendas de livros de auto-ajuda, revistas “especializadas”, palestras, cursos, workshops, programas de televisão. A verdade que, como diz um conhecido, todos eles falam coisas parecidas mas nunca parecem revelar o “pulo do gato”… não contam aqueles passos cruciais para obter o tão sonhado sucesso, embora que em seu marketing sempre se colocam como detentores do segredos dos famosos , ou dos ricos, ou dos sucedidos, etc. Para mim, se existir algum fator comum para todos que são nossas metas, sinceramente, eles são o sacrifício, o trabalho (muito trabalho), a perseverança, etc .

Somos a geração fast-food (comida rápida). Somos adultos que fomos criados dentro dos apelos das grandes lanchonetes, refrigerantes, entre outras coisas: viver o agora e já.  Somos pessoas que ao contrário de nossos avós (isso mesmo avós e não pais) não temos paciência para nada… Esperar é um verbo que desconhecemos a conjugação e quando somos obrigados a lembrá-la ficamos irados. Ninguém tolera filas, demoras, etc. Isso por um lado é excelente: temos pressa em viver e com isso fazemos com que, principalmente, a tecnologia evolua de forma a nos saciar essa necessidade de imediato. Porém o lado ruim disso tudo é a questão de, exatamente, não termos paciência, nem sabermos esperar.

Sobre nossa terra de que é nossa vida, ninguém colhe sem antes semear

Costumo dizer para os meus amigos que “ninguém colhe antes de semear”. Alguns poderiam dizer que isso não faz sentido, pois podem pegar os frutos da árvore, me logo respondo que se não foram eles alguém aquilo plantou. Bem, voltando ao assunto, senão vou me perder nesse mar de filosofia, a questão é que o trabalho é o caminho para se obter qualquer coisa.  Um bom exemplo disso que estou falando é a questão da magreza: hoje sermos magros e atléticos tornou-se uma obrigação, além das já normais, termos que malhar. Com isso, o mercado descobriu uma “mina de ouro” :  equipamentos, livros, métodos milagrosos que farão qualquer um perder peso sem fazer esforço… uma vez um professor de academia me disse algo: “para emagrecer basta gastar mais do que você ingere, simples assim, sem formulas mágicas”.

O Vinicius Teles, Be on The Net (ImproveIt), nessa última edição do RailsSummit que aconteceu nesse mês de outubro em São Paulo, fez uma excelente palestra falando exatamente sobre isso. Optando por uma abordagem genial, falando sobre sua própria biografia, ele mostrou que o sucesso, seja ele, financeiro, político, artístico, ele é fruto de pequenas escolhas (por vezes consideradas insignificantes) e, claro, de muito sacrifício e trabalho. Ele cita, por exemplo, o fato de várias vezes, mesmo tendo dinheiro, optado por guardar dinheiro ao invés de comprar um carro. Eu vou além, o sucesso é feito do suor e lágrimas nossos.

Em informática isso não é e, em minha humilde opinião, nunca será diferente disso. Por vezes ficamos pasmos frente ao sucesso estrondoso de algum cara que inventou algum produto e agora meses depois do lançamento está multi-milionário, famoso, viajando o mundo para ensinar a forma de conseguir um feito parecido.  Exemplos: 37signals, twitter, facebook, wordpress, django, rails, hibernate, Google, etc.  Nas entrevistas sempre é dado foco ao glamour, mas o que não nos contam,  são as jornadas duplas,  as dificuldades,  a falta de apoio … o quanto essas pessoas sofreram e trabalharam para conseguir.  Outra coisa é que eles são 0,1%; existem milhares por aí, noites sem dormir, comendo pão com pasta de amendoin no almoço, e que não conseguiram a fama e o dinheiro.

Uma outra coisa que considero interessante é a questão da paciência: parece que ninguém consegue entender que as coisas não irão acontecer “da noite para o dia”. Tudo na vida demanda tempo. Eu desconheço, além do miojo, que fique pronto e comece a dar frutos em cinco minutos.  Por isso, outra coisa para vencer (se é que possa falar assim – estou parecendo aqueles palestrantes de auto-ajuda)  é perseverança e paciência.  E como se tivéssemos que atravessar um mar bravo para podermos chegar na ilha do tesouro.  Temos que ter mais firmeza e calma para investirmos, principalmente se queremos criar um produto. Pesquisa de produto é algo sério e leva TEMPO. Cansei de ver gente que começou a trabalhar com informática agora é já quer ser considerado senior pois leu 5 livros sobre o assunto, assina o feed de 40 blogs, e por aí vai a loucura. Infelizmente não adiante enganar, precisa de estrada. O máximo que vai acontecer é enganar durante um tempo… é o caso do pessoal de reality show, por exemplo: eles tem algo não concreto e por isso duram pouco, logo caem no esquecimento do público, só ficam aqueles que trabalham e dão duro.

Existe um outro ditado que sintetiza bem a mensagem que é : “A única situação que sucesso vem antes do trabalho é no dicionário”.

Pessoal, a palestra foi sensacional… não pela conteúdo ou pelo autor (eu) mas pela pessoal que foi lá assistir. Em plena quinta-feira, meio de semana, o pessoal adiou a volta para casa, outros trocaram a saída, para irem assistir minha palestra no encontro mensal do riojug. O quorum foi de aproximadamente 40 pessoas (valor bastante expressivo).

Foi uma excelente conversa, com bastante interessante, discussões , etc.  Obrigado a todos que foram. Aproveito faço um pedido : Comentem com sugestões de melhorias e assim me ajudem na próxima vez ser melhor.