Blog do Andre Fonseca

A muito tempo venho pensando em uma coisa: O que acontece quando mudamos nosso foco para a direção das pessoas? Se ao invés de focarmos em obter mais lucro, mais dinheiro, mais bens, melhores processos,  equipamentos mais rápidos, a gente simplesmente focasse na pessoa… na pessoa na forma do cliente, na pessoa e sua qualidade de vida, na pessoa que usará aquele novo equipamento, etc.

Existe um grupo de pessoas aqui no Rio, mais especificamente ligados a TI (desenvolvedores, designers, etc)  que proporam exatamente isso:  miraram no ser humano. Isso vem galgado no Small Acts (acesse o link e leia pois vale a pena).  Ao fazermos isso, centra nossas atenções nas pessoas, os resultados foram surpreendentes e nossas ações tem tido repercussões até inesperadas.  São eventos em que, por pura paixão, vamos e levamos toda a nossa “energia” (nenhum de nós ganha dinheiro palestrando, ou fazer qualquer outra coisa afim), são encontros que para muitos parecem organizados e ultra focados como grupos de usuários sendo que na verdade estamos ali para conviver, rever amigos, tomar um chopp e como bons nerds que somos acabamos por falar de tecnologia e similares.

E claro que por vez ou outra surgem boas iniciativas dentro desse encontros e elas, por sua vezes,  em alguns casos viram excelentes projetos e ficam famosas. Mais tudo isso acontece não porque se quer ficar rico ou famoso. Mas porque acreditamos sinceramente nas pessoas e queremos levar essas coisas, que consideramos legais, para as pessoas.

Pode soar para muitos como algo idealista e utópico. De certa forma, olhando friamente e tendo como base o “restante” da sociedade, realmente é.   Entretanto, quando estamos ali fazendo para nós não passa de diversão. Por muitas vezes, me pus “de fora” e fique observando: parecíamos crianças empolgadas.

Insisto que ainda parece um tanto utópico nesse nosso mundo consumista mas quando o foco deixa de ser o lucro, o processo, a empresa e passar ser as pessoas realmente coisas mágicas passam a acontecer. Isso eu falo e qualquer nível de relacionamento. Se pegarmos uma loja e fazermos com que a equipe foque na pessoa e não no dinheiro do cliente veremos vendas aumentar, satisfação do cliente, aumento da propaganda boca a boca, etc. Se pensarmos em ambientes de trabalho, quando temos gerentes “humanos”que focam na pessoas de seus funcionários e não os encara como recurso, todos produzem mais, ficam mais felizes, as coisa fluem sem atritos, etc.  Isso pode ser extrapolado, ouso dizer, para qualquer situação.

Claro que em TI isso não pode ser diferente e ao meu entender possui uma dimensão mais interessante. A maioria das pessoas que trabalham com TI são pessoas que gostam de máquinas. Sim…. elas gostam de máquinas: são seus celulares, seus computadores, seus gadgets, seus video games, e o que mais vier. Poucos são aqueles que gostam de convivência. Isso é algo que para o profissional de nossa área deve ser vencido. Quanto não são os gênios que simplesmente travam quando tem que estar dentro de uma equipe? Quantos problemas temos no desenvolvimento por problemas que nada tem relação com a tecnologia e sim com as relações pessoais da equipe? .

O foco nas pessoas faz que com isso tudo se inverta e verdadeiros progressos se façam. Ao focar na pessoa, os processos se humanizam e passam a levar em consideração essa dimensão. Com isso eles se tornam mais próximos da realidade. Mas factiveis. Softwares são feitos para seres humanos, em sua maioria. E por isso, em sua concepção devem ter o foco no ser humano e não da linguagem, na máquina, etc. Isso que chamamos de experiência do usuário e que vem sendo perseguido pelos grandes players do mercado.

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.

A alguns dias atrás, fiz um workshop sobre metodologias ágeis com o Juan Bernabó na Globo.com. Recomendo fortemente a todos fazerem mesmo que já tenham certo conhecimento sobre o assunto, apliquem nos seus times ou qualquer outro caso.

Durante todo o workshop feito por ele, cujo o objetivo é de apresentar as metodologias principalmente o Scrum, vários jogos, dinâmicas e outras tantas coisas são feita. Entretanto, para mim, o mais interessante  foram as discussões que ocorreram entre as atividades.

Houve um momento que o pessoal colocou os problema encontrados no dia a dia de cada um e suas expectativas quanto ao uso de metodologias ágeis.  A primeira coisa que ficou bastante evidente foi uma expectativa que ao colocar em prático algo ágil todos os problemas desaparecerão, como que por mágica, e que todos serão felizes num ambiente super ideal.

A questão que o curso colocou, e que realmente achei genial, é que Scrum não é uma ferramenta somente de soluções. Ela tem muito mais um aspecto de mostrar os problemas e forma simples e rápida procurar resolvê-los.

Sendo assim, quem não está preparada para ver os problemas, gargalos, etc de sua empresa, ao adotar qualquer coisa no sentido, vai achar que a ferramenta não serve. Isso porque tem a expectativa errada. Verá muito mais problemas do que solução.

Uma outra coisa que o Bernabo falou que me fez mudar a forma de pensar foi que ser ágil não significa não ter problema : a questão é exatamente contrária, evidenciam os problemas e procura-se soluções. Contra medidas nas palavras do Juan.

Enfim, ao vermos a questão ágil não como mais um processo e sim como uma forma de levantar os problemas e buscar contra-medidas, fica claro a razão do sucesso e que simplesmente seguir uma cartilha não é o perfil ideal a buscar.

Ultimamente em meu trabalho o pessoal tem conversado sobre qual seria um bom perfil de profissional para a empresa. Essa discussão, embora pessoalmente eu não goste desta coisa que rotular, acabou indo para um lado bem interessante.  O que seria interessante nos dias de hoje : um “clínico geral”ou um especialista.  Com toda certeza a maioria das pessoas diriam os dois. A segunda questão que coloco é : qual a proporção ? Mais clínicos ? Mais especialistas? Igual ?

Cada vez mais se fala que hoje é importante sermos poliglotas no que diz respeito a tecnologia/linguagens. É impossível você querer galgar posições no mercado sem ao menos conhecer mais de duas coisas (linguagens, SOs, Bancos, etc) . Com toda a certeza, muitos dos times que estão por aí, vão querer pessoas que sabem mexer com o sistema operacional (não precisa ser um gênio ou commiter do linux, mas saber usar bem vale) , pessoas que conheçam mais de uma coisa e assim tenham capacidade de sugerir soluções diversas, etc.  Isso se “agrava”quando falamos em profissionais SENIORs (experientes) .

Ninguém quer um cara que só saiba Java e por isso só quer fazer tudo em Java. Pode ser que o melhor caminho esteja no uso de Ruby, Python , Php, Erlang, etc.

É cada vez mais procurado, admirado … pessoas que sejam multidisciplinares. Mas isso tem um preço.

O preço que vejo na maioria dos casos que temos pessoas que tem um conhecimento raso sobre tudo. São capazes de fazer o trivial (aquele passo a passo dos tutoriais) porém se algum situação exigir um conhecimento extra elas patinam e parte desesperadas para o google ou listas.  Isso, ainda sim, pode parecer interessante, entretanto, ter especialistas é algo bom. Eles são aqueles caras que conhecem poucas tecnologias mas as conhecem bem e a fundo; são capazes de fazer desde o trivial ao mais avançado.

A questão é que ao desejar um poliglota com fluência em tudo, as empresas optam pelos dois extremos da mesma reta. Não vou dizer que isso seja impossível de encontrar pois, eu mesmo conheço pessoas que são, para mim, ponto fora da curva.  A questão é que levar essa cobrança a todos vai gerar decepção e por consequencia desconforto.

Querer que um cara seja tão bom em programar client side (css, html, javascript – jquery e jquery ui,etc- , e outras coisas) e ao mesmo tempo seja ninja na parte server é querer que o cara seja goleiro e atacante do mesmo time  ao mesmo tempo. Ter noção e conseguir safar a onça é uma coisa, agora saber a fundo destalhes de tudo é algo que deixo para as mentes mais avançadas.

Insisto que isso não é impossível porém exige muita dedicação e tempo. Coisa que uma pessoa que trabalhe pode não ter muito. Tempo para aprender, tempo para se aprimorar  e tempo para se manter atualizado em tudo.

Em contexto como pesquisas e universidades, onde os prazos são mais elasticos, isso pode ser possivel mas em empresas a coisa é menos provável.

Enfim, deixo a pergunta que fiz lá no início: Clinicos ou Especialistas? Qual proporção?

A um tempo atrás alguém postou um comentário aqui no blog perguntando como ele poderia testar a questão do upload de arquivo usando o Selenium.

Bem, pedindo ajuda para o grande sábio Google, encontrei a página (clique aqui) com um trecho de código que reproduzo parte abaixo mostrando como fazer.

Pelo jeito ele somente irá funcionar para o IE pois os demais browser não aceitam que você digite no campo de file. (Me corrijam se eu estiver errado).

Espero que ajude:

Já a um tempo desde que fui apresentado a todo o movimento ágil por meio do Guilherme Chapiewski, Alexandre Martins, Evandro Flores… e desde que fui levado a novas tecnologias e linguagens por estes e por outros como Henrique Bastos,  que sempre que conversamos sobre o assunto com o pessoal que ainda não conhece nada sobre o tema, ouço toda vez as mesmas perguntas e frases:  Você usa ágil por ser idealista; você gosta dessas metodologias por ser nerd e gostar desses modismos; Ágil não é para gente que quer ganhar dinheiro? Python é coisa de universidade!  Ruby on Rails é para pequena empresa!

Uma primeira coisa que gostaria de deixar claro: Sou capitalista e gosto de ganhar dinheiro. Não tenho absolutamente nada contra os demais regimes econômicos existentes, nem a políticas, teses sociais e etc.  Sou um cara que acredita no trabalho e que devemos ganhar dinheiro com ele. Só isso.  Sendo assim, como uma empresa,  busco o lucro. E quanto maior minha margem de lucro melhor.

Margem de lucro, quando estudei macro economia na faculdade, em termo simples,  é quanto porcentos de dinheiro que você ganha frente ao custo daquela coisa que você “está vendendo”. De certa forma, vendemos nossas horas de trabalho… de um jeito que prefiro, vendo meu conhecimento para criar software.  Horas soa como operador de máquina. Operário.  Seguindo com o raciocínio,  para maximizarmos nossos “lucros”como desenvolvedores, temos que gerar o maior valor agregado para o nosso cliente com menor esforço possível.

Esforço no nosso caso é arquitetar soluções, criar ambientes, codificar, testar, instalar a solução para o cliente e depois dar a manutenção dele.  Claro que isso pode não aplicar a todos, mas pelo menos algumas das coisa citadas são feitas. Bom, se existir algo que me facilite realizar as tarefas acima e ainda permita que eu gere um alto valor para o cliente, seria sensacional, não ?! É exatamente isso que encontrei a adotar essas “novas” tecnologias (Python e Ruby existem a tanto tempo quanto Java)  e o fato de ser ágil .

Essas linguagens me permitem fazer com menos… Ágil permite eu me livrar de burocracias que não me ajudam e tomam meu precioso tempo.  Enfim, escolhi usar essas coisas pois quero ganhar mais dinheiro com menos esforço. Muitos, com certeza, irão me criticar dizendo que estou fora do ideal da comunidade. Eu gosto de ajudar e contribuir. Faço isso sempre que posso, a questão que o motivo principal que me mostrou valer realmente a pena em aprender coisas novas, investir para me inserir em novas formas de gestão foi o fato de eu ver que isso ajuda a melhorar meu trabalho e a ganhar dinheiro.

Um erro comum das pessoas que entram nessa nova onda é achar que só existe idealismo envolvido que o resto é mal ou desprezível. Dinheiro não é mal, é de fato o que move nosso mundo. Por que não mostrar que ser ágil, usar uma tecnologia aberto para fazer as coisas, usar uma linguagem mais simples, pode ser um meio de aumentar lucro? Pois é exatamente o que acontece.  Usar Git ao invés de CVS ou SourceSafe(exagerei)  é lucro: não pago licença por algo que é muito bom e além disso ganho com recursos que facilitam a vida do time.

Acredito firmemente que é preciso dar um sentido menos utópico as coisas.

Bem era isso… aguardo a opinião de vocês.

Outro dia no meu trabalho estava desenvolvendo em par com o Bernardo Heynemann e comentei com ele que por vezes sentia falta de uma IDE de desenvolvimento pois “ajudava” muito o autocomplete que tinha com Eclipse quando desenvolvia com Java. Na mesma hora ele me “corrigiu”dizendo que um editor de texto é ferramenta mais que suficiente para se desenvolver, desde que, a tecnologia (entenda a linguagem / plataforma) seja boa.  Confesso que fiquei com aquela conversa na cabeça tentando digerir o que ele tinha me dito.

Como assim boa? Java não é uma linguagem boa? Bem nem vou me aventurar por este caminho pois sei que acabará tendo milhões de xiitas de diferente lados querendo me “queima vivo”.  A questão é que quando a coisa é concisa e bem projetada, o uso de uma IDE, que tenha recurso muito bons de completar automaticamente, sugestão, organização de importação, etc, se torna desnecessário, pois as coisas são intuitivas e naturais.  Um bom exemplo sempre ajuda.  Se temos dentro de um biblioteca (api, app, ou qualquer outro nome que queira) métodos e arquiteturas simples que representam bem o domínio do problema que elas pretende resolver, você verá que vai descobrir seu funcionamento de forma natural e errará muito pouco.  Imagine que você tem um boa api de envio de SMS. Ela com certeza terá uma função, interface, método, que enviará o SMS com um nome sugestivo ou parecido a enviaSMS.

Pode parecer idiota mas não são raros os casos que fogem a este bom senso. São muitos que de forma consciente ou inconsciente criar verdadeiros monstros com coisas do tipo:  session_factory.instance(); factory.correct_impl, factory_receive_valor({chave:valor}); executor = Executor.new; executor.processa(factory,out);

De propósito misturei algumas sintaxes para que não caracterizasse nenhuma tecnologia especifica. O que mostrar que algo monstruoso como acima, serviria para imprimir uma mensagem de “Hello World” na console.  Novamente insisto que o exemplo pode parecer óbvio que é exagerado, mas existem coisas ai fora nesse nível.

Voltando a questão da IDE e a conversa com o Bernardo, finalmente caiu a “ficha”: quando se tem algo bem feito, um editor de texto basta. Para botar um tempero na coisa, quero sugerir um teste para meus leitores Javeiros: tentem durante um dia inteiro de trabalho somente usar um editor de texto de sua preferência. Pode ter cor para realçar sintaxe mas nada de sugestão e completar automaticamente.  Sei que alguns conhecido vão rir disso pois já fazem assim com qualquer linguagem que trabalhem, mas desde que Java cresceu muito, muitos esqueceram que existe um javac para compilar as classes e nem sabem mais usá-lo embora sejam considerados senior em suas atividades.

Ai vai mais um aviso: antes que peguem suas tochas e foices para me perseguir e matar, não estou dizendo que vocês são ruim ou fracos, estou dizendo que a tecnologia pode não ter ido para uma direção legal.  Isso também se aplica a outras linguagens. Veja C# ou qualquer outras coisa .NET; C++, etc. Tenta se entender com classpath, compilar as classes em uma pasta, organizar o diretorio de saída, construir um arquivo para fazer um deploy da aplicação (se for web ou enterprise ai a coisa fica ainda pior), na “mão” e ainda ser produtivo. Eu dou a colher de chá no desafio acima para usar o ANT e até o maven.

A um certo tempo atrás, numa empresa onde trabalhei, ganhei o apelido de “leitor de javadoc”. Isso porque sempre que podia olhava o javadoc para ver as explicações das classes, quais métodos, quais recomendações. Para mim, este tipo de inciativa que contribui para uma boa solução. Em python, sempre temos a oportunidade para irmos para interativo e digitar o dict para inspecionarmos algo. Em Ruby  você tem uma documentação tão boa quanto javadoc, etc.

E novamente volto ao ponto inicial da conversa:  sem falsa demagogia ou interesses maldosos, para um bom desenvolvedor usando uma boa tecnologia, um simples editor de texto basta.

Até a próxima pessoal. E aguardo os comentários de vocês com críticas, respostas e opiniões sobre o assunto.

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.

Pessoal, hoje recebi um email sobre uma vaga de emprega. Não conheço a empresa nem a pessoa que está divulgando, entretanto, como conheço a lista onde ela foi postada, reproduzo aqui para que o pessoal que acompanha o blog possa saber:

Olá Pessoal.

Estou com uma vaga urgente, mas eu não consigo encontrar profissionais no mercado, gostaria muito de pedir a gentileza quem tiver alguns profissionais para me indicar eu ficarei muito grata, ou mesmo encaminhar para a lista de contatos de vocês pedindo que entrem em contato comigo.

Segue abaixo o perfil da minha vaga:

Quantidade: 01 vaga

Perfil: Analista Desenvolvedor C# .Net

Nível: Pleno

Requisitos Indispensáveis: Windows Forms, Web Services, Orientação a Objetos, Oracle.

Requisitos Desejáveis: Conhecimento em Seguro Saúde.

Contrato: PJ hora aberta.

Início: Imediato

Período: projeto de 10 meses com possibilidade de prorrogação.

Local: São Paulo – Morumbi.

Quantidade: 01 vaga

Perfil: Analista Desenvolvedor Java

Nível: Pleno

Requisitos Indispensáveis: Java-Spring, Orientação a Objetos, UML, Oracle, Websphere/WSAD.

Requisitos Desejáveis: Conhecimento em Seguro Saúde.

Contrato: PJ – hora aberta

Início: IMEDIATO

Período: Projeto de 10 meses com possibilidade de prorrogação.

Local: Morumbi – São Paulo

Interessados ou indicações favor encaminhar o currículo para tania@dbsitservices.com.br.