quinta-feira, 23 de junho de 2011

Rowan e Nós

Independente do contexto profissional de cada um e do formato de contratação que nos propomos, temos que impor uma certa postura profissional coerente, visando qualidade em todos os serviços que entregamos, valorizando ao máximo o profissional que somos por nossas obras e não somente pelo valor do rendimento que recebemos ao final de um período.

Relendo este grande artigo clássico que foi replicado não só no mundo corporativo como também no meio militar, me veio a reflexão do que deve ser realizado por todo e qualquer profissional independente de sua área de atuação.

Foi a partir deste famoso artigo que surgiram ao redor do mundo expressões do tipo "Dar conta do recado" que virou sinônimo de trabalho realizado com qualidade. A reflexão que proponho aqui é: Estamos dando conta do recado?

A resposta parece simples, mas envolve uma série de fatores que temos que levar em consideração. será que exigimos de nós, no dia-a-dia, o máximo que podemos oferecer como pessoa e como profissional em nossos ambientes de trabalho? Será que não condicionamos a extração do nosso melhor a algum tipo de reconhecimento externo, material ou não? Quanto podemos render mais em relação ao que estamos rendendo atualmente independente de condições externas ? Buscamos motivação externa para nosso melhor rendimento ou nosso entusiasmo (motivação interna infinita) dá conta do recado?

Cada um deve refletir nessas perguntas buscando as respostas dentro de si. Confesso que da minha parte, revendo minha trajetória e até alguns momentos atuais, percebi que eu poderia ser bem melhor do que estava sendo. Hoje não digo que dou "conta do recado" sempre, mas estou buscando reverter este quadro de paralisia que às vezes assola nossos ânimos, tentando isolar fatores externos da excelência que devo buscar em meus trabalhos.

E você, Está dando conta do recado?

terça-feira, 21 de junho de 2011

O Retorno

Como vocês devem ter percebido, houve um espaço muito grande entre a última postagem e a penúltima datada de 2009.

Naquela época me pareceu interessante ter um blog técnico e ao mesmo tempo eu queria aproveitar a onda dos blogs, mas após iniciar meu intento, percebi que a grande maioria dos assuntos técnicos interessantes já eram abordados por outros blogs, incluindo blogs das referências sobre estes mesmos assuntos.

Essa observação arrefeceu muito meu ânimo para escrever posts exclusivamente técnicos e passei este tempo todo com o "blog de molho". Foi então que neste ano tive a idéia de proporcionar minha visão sobre assuntos do profissional de TI, técnicos ou não, causando ou procurando causar alguma reflexão e debates interessantes entre os leitores.

A partir daí, reativei o blog com o primeiro post do ano de 2011 e agora este atual explicando um pouco o contexto atual. Não deixarei de postar assuntos técnicos, porém eles não serão o foco principal do blog. Pretendo manter escritas periódicas sempre com intento de criar textos e discussões que sejam catalizadores de mudanças e reflexões positivas na vida profissional de cada leitor e, quem sabe, proporcionar caminhos a seguir para a melhoria da área de TI de uma forma geral.

Conto com vocês, caros leitores, para atingirmos este objetivo.

segunda-feira, 13 de junho de 2011

Ótimo Negócio: Aluguel de Mentes

Cenário

O mercado de trabalho de TI no Brasil é muito próspero e vem passando nos últimos anos por uma crise de necessidade por profissionais qualificados o que,
naturalmente, torna tais profissionais mais caros, assim, sendo profissionais com um salário superior à média de salários das diversas profissões, empresas
buscam alternativas para diminuir o custo de contratar e manter um profissional de TI em seus quadros.

A forma de contratação CLT, nesta situação, é muito onerosa e, mais e mais empresas, especialmente as de médio e pequeno porte, normalmente consultorias, optam por outros formatos de contratação como por exemplo o de Pessoa Jurídica ou simplesmente PJ.

As consultorias fazendo isso diminuem, e muito, o custo de manutenção do profissional, pois o profissional PJ não é um funcionário efetivo da empresa e sim
uma empresa prestadora de serviços, retirando, em partes, o vínculo com o profissional enquanto pessoa física. Além dos aspectos tributários, outros fatores contribuem para a diminuição deste custo, como ausência de 13o salário, férias remuneradas, pagamento de INSS, fundo de garantia, dentre outros.

Recentemente vem se criando uma tendência de "beneficiar" o profissional PJ com alguns dias de férias remuneradas ao ano e algum outro benefício menor.

Em contrapartida, as empresas que contratam neste formato repassam parte do "lucro" que obtiveram por não pagar os impostos do formato CLT para o profissional e este também paga menos impostos, obtendo, assim, um montante liquido mensal maior em relação ao que obteria no CLT com a vantagem ainda deste valor poder ser gerenciado da forma como o profissional PJ desejar.

O Grande Negócio

Expondo estes aspectos, aparentemente esta forma de contratação estabelece uma excelente relação ganha-ganha entre empresa e profissional.

Aparentemente...

Aparentemente, pois este vínculo é bastante frágil, uma vez que o profissional PJ, na maioria das vezes, não se sente integrante de uma equipe com
objetivos, valores e missões convergentes, ele perde a identidade com a empresa onde trabalha, pois muitas vezes, atua terceirizado e até mesmo "quarteirizado" dentro de outras empresas chamadas "clientes", mesmo assim esta relação pode durar pouco tempo já que o profissional pode ser alocado em um projeto distinto numa outra empresa "cliente".

É muito comum a forma de trabalho acima citada para quem é PJ e este formato nada mais é que o formato de aluguel, sendo a empresa contratante o "corretor", o profissional PJ o "objeto" e a empresa onde o profissional atua em última instância o "inquilino". Daí, o negócio é matemático, o "objeto" tem um custo de manutenção x (salário negociado e uns poucos "benefícios") e o "corretor" cobra do "inquilino" um valor de aluguel superior ao custo de manutenção x, estabelecendo aí o grande negócio das consultorias.

As Consequências

Acontece que no meio deste grande negócio se encontra um ser humano, o "objeto" do contrato, que realmente se sente como tal e a pergunta é: O que faz este profissional permancer numa empresa cujas relações de trabalho são configuradas conforme expostas acima?

Em alguns casos, aspectos não relacionados à consultoria e sim ao cliente final ("inquilino"), como ambiente, localização e flexibilidade de horários. Mas e se a relação entre "corretor" e "inquilino" terminar ou se desgastar, o que resta para o profissional? E se algum outro "corretor" estiver disposto a pagar um custo de manutenção maior pelo "objeto"? O que prende o "objeto" ao corretor se não houver um bom "inquilino"?

Uma das respostas a estas perguntas se dá através da observação do próprio mercado de trabalho: Alta Rotatividade !

Ela se dá não só por isso, é verdade, pois esta pode ocorrer pela ganância de profissionais menos maduros e/ou inexperientes, pela alta demanda por profissionais que pressiona os salários para cima ("custo de manutenção do objeto"), dentre outros, mas principalmente, ao meu ver, pela desumanização da relação entre empresas e profissionais.

O que fazer?

Creio que é hora das empresas reverem as relações que estabelecem na prática com seus profissionais. Principalmente as relações onde o profissional é PJ, abrindo espaços para benefícios próximos aos que o formato CLT pratica, humanizando mais as relações com ele, permitindo que ele tenha o direito de ficar doente algumas vezes no ano sem ser punido na remuneração que recebe ao final do mês, de poder descansar um período no ano sem se preocupar como irá repor os dias de descanso, de não ter que se desgastar anualmente com negociações junto ao seu contratante para que seu salário não fique menor a cada ano diante das mordidas da inflação.

O que podemos fazer? Mobilização? Divulgação? Lutar por nossos direitos? Como? Os que lerem este post, favor colocar a sua opinião, traga sua experiência à tona, traga exemplos de onde esta humanização já ocorre para que nós, profissionais de TI, tenhamos um norte, uma direção, uma esperança! Quanto mais comentários, mais pontos de vista, maiores são as chances de aproveitarmos grandes lições.

Aqui compartilhei um pouco da minha visão e aguardo que compartilhe a sua também caro leitor.

sexta-feira, 3 de julho de 2009

Javadoc turbinado

Nos diversos cursos java que ministro, sempre ocorrem duas perguntas fatais quando eu apresentava o assunto javadoc, a primeira é se havia javadoc da api java em português e a segunda se havia uma ferramenta de busca embutida na documentação. A resposta para tais perguntas é que não havia. Porém, recentemente andando pela página da Sun vi que há um projeto a respeito intitulado DocWeb que apresenta não só uma ferramenta de busca por nomes de atributos, classes, métodos, construtores, mas também tradução para uma série de línguas, inclusive português. Em relação a tradução, o trabalho é da comunidade e menos de 5% da documentação foi traduzida para o português, mas você pode acelerar o processo sendo um colaborador na tradução do javadoc, basta se cadastrar para a tarefa na página do projeto. Bons códigos!

quinta-feira, 21 de maio de 2009

Desenvolvedores e SOA

Ao depararmos com novos assuntos relacionados à tecnologia temos visões distintas dependendo da experiência que temos, dos projetos nos quais estamos envolvidos dentre outros aspectos, porém, quando aparece um tema novo de conteúdo mais genérico envolvendo uma visão horizontal de sistemas a tendência é visualizar tal assunto como algo complexo.

Pela característica horizontal destes assuntos, torna-se necessário o mapeamento do que é relevante para cada papel dentro de um processo de desenvolvimento de software. Um destes assuntos é SOA (Service Oriented Architecture). Desenvolvedores em geral podem imaginar que isso é assunto para arquitetos de software e de sistemas em geral, mas, pelo contrário, SOA trás um leque de novas frentes de desenvolvimento que devem ser atacadas para que desenvolvedores se preparem para atuar em grandes projetos.

Esta apresentação ajuda os desenvolvedores a terem esta visão. Este post visa justamente ser um auxílio inicial e um empurrão àqueles que desenvolvem e querem se preparar para atuar em projetos cuja arquitetura seja voltada a serviços.

Boa leitura!

segunda-feira, 18 de maio de 2009

Métricas e o café !


A JSR-275 é uma API do java para tratamento de unidades de medidas e será utilizada como tipo de diversos atributos que armazenam valores cujo valor final é conhecido somente se associado a uma unidade de medidas.
Por exemplo, se um atributo armazena a distância entre dois pontos, o valor armazenado, suponhamos 100, é sempre relativo à unidade de medida que se considera. Assim, pois, se falarmos que 100 é o valor e que a unidade é km daí sim tiramos a informação concreta e real.
Basicamente esta API trata de elementos mensuráveis (Measurable) e das medidas propriamente ditas (Measure). Estes por sua vez estão sempre vinculados às chamadas dimensões (Quantity), que representam a natureza relativa à medida em questão. Estas dimensões estão representadas na API, algumas delas são representadas abaixo, enfatizando que as demais são formadas por derivações das dimensões básicas ou transfomações das mesmas aceitas pela comunidade:
DimensãoUnidade (SI)Quantity (JSR-275)
Tamanho metros (m) Length
Massaquilogramas (kg) Mass
Duração segundos (s) Duration
Corrente Elétricaamperes (A)EletricCurrent
Temperatura Termodinâmica Kelvin (K)Temperature
Intensidade Luminosa candela (cd)LuminousIntensity
Quantidade de Substância moles (mol) AmountOfSubstance

Além das dimensões a API representa também as unidades de medidas. Há a separação entre as medidas do sistema internacional de medidas e as não SI.
Nas aplicações de mercado, frequentemente é necessário realizar conversões das diversas unidades de medida, o que é plenamente suportado pela API. Uma boa estratégia para lidar com valores que representam unidades de medida é persistir os valores num determinado grupo de unidades de medidas, por exemplo, o SI e na camada de apresentação realizar as conversões quando necessário com apoio da API.
Neste site encontram-se algumas conversões comuns entres as diversas unidades de medidas. Bons códigos!

Estudo sobre complexidade arquitetural


Um excelente estudo realizado pela NASA endereça um dos assuntos mais críticos contidos em grandes sistemas computacionais, como apresentado, o sistema de controle aeroespacial: Como lidar com o crescimento da tamanho e da complexidade de um software ao longo do tempo e entre diferentes projetos realizados com base em um mesmo domínio? O estudo, apesar de ser baseado no domínio aeroespacial, pode ser aplicado a qualquer sistema que tenha as características por ele apresentado. É uma leitura rica e repleta de reflexões possíveis para a nossa realidade e enfatiza basicamente os seguintes aspectos:
  1. A importancia no investimento em arquitetura de software
  2. A necessidade de se enxugar ao máximo os requisitos diminuindo complexidade
  3. Tratar o acréscimo de complexidade no software em todas as fases do projeto
  4. Tratar sistematicamente desde os requisitos a disciplina de "proteção a falhas"
Estes aspectos acima citados, ganham grande enfoque e estão diluídos em 16 recomendações "macro" abaixo listadas:
  • Difundir a consciência de complexidade entre as diversas camadas do sistema para todos os participantes de um projeto
  • Documentar os motivadores e bases para os requisitos e seu objetivo-chave para o negócio, promovendo eliminação de requisitos desnecessários, diminuição de sua complexidade e amarração com o escopo.
  • Difundir o conhecimento do negócio, com todos os seus aspectos multidiciplinares
  • Introduzir a análise arquitetural o mais cedo possível no projeto
  • Realizar revisões arquiteturais
  • Dar maior suporte e investir em arquitetos de software
  • Envolver os usuários finais desde o inicio e continuamente no processo
  • Decisão "Make-or-Buy" (COTS) baseada na facilidade de separação desta do restante do sistema e da complexidade no processo de testes
  • Investir numa arquitetura de referência
  • Estimular a difusão tecnológica entre equipes e projetos
  • Usar ferramentas de análise estáticas de código e "code compliance"
  • Padronizar a terminologia usada para definir os diversos tipos de falhas de sistema, através da definição de um padrão léxico para proteção a falhas e definição de um conjunto de principios e funcionalidades que caracterizem arquiteturas de software a respeito de desta disciplina.
  • Estabelecer a revisão dos requisitos ou proposta baseada nos aspectos de tratamento de falhas.
  • Desenvolver a cultura de proteção a falhas e autonomia de sistemas
  • Pesquisar técnicas de contenção de falhas
  • Coletar e USAR métricas de software (Como medir complexidade das fases de software)?
Vale a pena o estudo do documento completo. Ele trás ainda boas referências e pequenos estudos práticos. Bons estudos!