| Tecnoloiga, Marketing e Empreendedorismo.COM
O mercado atual, no que se refere a tecnologia da informação, se consolidou em um modelo de trabalho extremamente pautado nas tercerizações e nas contratações baseadas em pessoas jurídicas devido a todas as questões financeiras que provavelmente você que está lendo este artigo já deve estar cansado de saber (caso você não saiba, mande um e-mail e terei o maior prazer em explicar), e tal cenário, apesar de sanar alguns problemas e facilitar algumas situações gerenciais, criou outros problemas que fazem muitos gestores de equipes de TI literalmente perderem o sono com tais dificuldades gerenciais, problemas que na sua grande maioria estão ligados ao fator “gestão de pessoas”.
Vamos enumerar alguns destes problemas:
1) Por ser um modelo de contratação baseado em pessoas jurídicas, os distratos são mais fáceis e é muito comum um colaborador chegar da noite pro dia e se desligar da empresa/projeto deixando seus gestores com o problema deste desfalque não planejado.
2) É difícil, pra não dizer quase impossível, criar um plano de carreira que possa ser motivador financeiramente além de proporcionar a oportunidade de realização para profissionais que não ambicionam carreiras gerenciais, profissionais que queiram única e exclusivamente atuar em contextos técnicos.
3) É difícil definir uma estrutura de cargos / papéis / salários que seja justa e motivadora ao mesmo tempo, que de forma transparente permita ao profissional saber o que ele precisa fazer pra chegar ao patamar financeiro que ele ambiciona em curto, médio e longo prazo.
4) Muitos profissionais ruins e pouco produtivos conseguem esconder suas limitações e falta de produtividade dentro do time, levando com isso méritos da realização de todos os demais ou levando todos ao fracasso da não entrega ou da falta de qualidade do trabalho que acaba sendo atribuída ao time como um todo e não somente ao indivíduo.
5) Facilmente vemos alguns profissionais extremamente sobrecarregados e outros osciosos dentro de seus projetos.
6) Gestores que muitas vezes não geram resultados tão efetivos ao projeto quanto alguns profissionais mais envolvidos na realização acabam sendo muito melhor remunerados e tal discrepância salarial desmotiva o profissional que se vê garantindo a entrega.
7) Quando o profissional questiona sobre quais perspectivas existem pra ele na empresa quando ele não tem mais para onde crescer verticalmente, a empresa fica sem resposta e fatalmente em pouco tempo também perderá este talento.
Estes são só alguns dos muitos problemas que podemos presenciar hoje de forma muito comum em times de TI desde os menores até os grandes, onde seu gerenciamento é basicamente baseado em modelos hierárquicos de cargos e salários.
Daí vem a pergunta, “como é possível resolver isso?”.
Antes de responder, vamos primeiro fazer um pequeno exercício de reflexão nos colocando no lugar de um profissional que trabalha em baixo de uma estrutura hierárquica e que tem acima dele um determinado gestor, e que para ele poder ganhar mais ou ter mais oportunidades de realização precisa ser promovido para este cargo acima dele que hoje é ocupado por este gestor, com isso as alternativas que lhe restam são esperar que seu gestor seja promovido e que com isso ele tenha a chance de ocupar o seu cargo, esperar que seu gestor seja demitido e que com isso ele tenha a chance de ocupar o seu cargo, esperar que seu gestor morra e que com isso ele tenha a chance de ocupar o seu cargo ou então mudar de emprego… se você fosse este profissional, como você se sentiria? se você fosse este profissional, o que você faria? se você fosse este profissional, o que você gostaria que fizessem por você?
Pode ser que você ache que tudo isso que eu estou apresentando aqui seja pura e simplesmente fictício e fora da sua realidade, pode ser que você nuca tenha se deparado com nenhum destes problemas, pode ser que você esteja extremamente feliz e satizfeito com a forma como você gerencia seu time de TI ou como você é gerenciado dentro de um time de TI e todos estes cenários que eu te apresentei são surreais e improvavéis, pode ser que você acredite no papai noel, no coelhinho da páscoa e no sací-perere, enfim se este for o seu caso, agradeço por ter lido este post até aqui e te recomendo não perder mais tempo por aqui, caso contrário peço que você leia a sequência deste artigo e debata comigo sobre a proposta que será apresentada para sanar tais problemas se não na sua totalidade, pelo menos na sua maioria.
No próximo post vamos tentar responder estas perguntas…
Quando vejo um trabalho bem feito, e que pode de alguma forma ajudar outras pessoas, faço questão de divulgar o máximo possível, e o site www.herokugarden.com é um exemplo deste tipo de trabalho.
Direcionado para aqueles que estão começando a estudar Ruby on Rails, o site Herokugarden provê um ambiente on-line completo para você estudar, desenvolver, publicar e armazenar seu repositório de forma muito simples, prática e objetiva, e a propósito, é de graça.
Durante o barcamp locaweb de rails que aconteceu no mês passado (mar/2009), este foi o ambiente com o qual fiquei “brincando” enquanto trocavba idéias e aprendia um pouco mais sobre Rails.
Se você acessar o link das features (http://herokugarden.com/features) poderá ver tudo que está a sua disposição, é realmente muito bacana.
Eu só testei superficialmente, mas me arrisco a dizer que pra galera que curti trabalhar como free lancer e que uma hora está aqui, outra ali, esta seria uma alternativa muito bacana pra organizar seus trabalhos e flexibilizar suas atividades quanto a local de trabalho e infra-estrutura disponível, ou seja, em qualquer lan-house, você pode desenvolver seu projeto.
Experimentem, e se acharem falhas, por favor, voltem com suas críticas.
Vejam a notícia, e na sequência a minha crítica:
O Núcleo Softex Campinas realizará, no dia 15 de abril, o curso “APF- Análise de Ponto de Função”. Direcionado aos profissionais que lidam com medição ou validação da medição e software do APF, o objetivo do curso é capacitar o participante em sua aplicação.
O programa acontecerá no campus da Unicamp e deve apresentar conceitos, exemplos de aplicação e exercícios práticos. O treinamento segue o formato recomendado pelo IFPUG – International Function Point Users Group e é baseado no Counting Practices Manual Versão 4.2 (CPM 4.2).
Mais informações no portal www.cps.softex.br
Crítica:
Depois de muitos anos trabalhando com desenvolvimento de software, me sinto a vontade para dizer que é um fato, um triste fato que o uso de métricas para planejamento e validação de desenvolvimento de projetos de software não é uma das disciplinas mais respeitadas, muito pelo contrário, o mercado está cheio de “especialistas” que com sua “experiência” e “expertise” são capazes de ver a especificação de um projeto e na base do “olhômetro” dizer o tempo necessário para este desenvolvimento… Balela, não preciso nem dizer que a margem de erro é absurda e os atrasos constantes.
Sou a favor do uso de métricas, sou a favor do uso de índices e coeficientes não apenas para melhorar a acertividade de um planejamento como também para validadar o resultado de um desenvolvimento e assim verificar a necessidade ou não de se ajustar os coeficientes usados no planejamento inicial.
Olhando por esse ponto de vista, acho louvável a iniciativa da Softex, mas a minha crítica se deve ao fato de que na minha humilde e modesta opinião, APF (que a anos atrás quando eu utilizei tinha uma margem de erro da ordem de 30% segundo especialistas) está desatualizada em relação as tendências e necessidades atuais do mercado.
As técnicas, os métodos, as ferramentas em uso atualmente, que visam atender as necessidades de economia e agilidade no desenvolvimento de projetos de software, fazem da APF uma ferramenta desatualizada, onde seus critérios de complexidade de uma funcionalidade baseado em quantidade de atributos e interfaces de entrada/saída dentre outros elementos de que ela se utiliza, estão aquem da capacidade de se mensurar de forma rápida outros elementos inerentes a um projeto como design, interoperabilidade entre plataformas como on e off line, mobile e etc, além de uma série de outras considerações que renderiam muito assunto para este post.
Por isso minha crítica, e minha sujestão, se possível, pelo menos usem algo como UCPF (use case point function/ pontos de função por caso de uso), evoluam para métodos ágeis como SCRUM que proporcionam novas perspectivas para adoção de métricas, enfim vamos buscar evoluir, aquilo que pode ser evoluido e melhorado, mas caso isso não seja viável pra você, então use APF mesmo, mas use alguma coisa além do seu “feeling”.
Quando comecei a ouvir sobre “métodos” (não concordo com o termo metodologia dentro do contexto de desenvolvimento de software, metodologia é a ciência que estuda o método, método é o que usamos propriamente dito) ágeis de desenvolvimento de software, procurei artigos que abordassem estudos de caso em cenários que realmente refletissem a realidade da maioria das pessoas que se envolvem em processos de desenvolvimento de software.
Pessoas como primeiramente o cliente, aquele que tem uma necessidade a ser atendida por meio de uma ferramenta de software que precisa ser desenvolvida dentro de um contexto de custo e prazo com qualidade e condições de continuidade e manutenção dentro da vida útil desta ferramenta, o desenvolvedor que precisa entender essa necessidade do cliente dentro de contextos funcionais, identificar os demais requisitos não funcionais para então escolhendo uma ferramenta de desenvolvimento, desenvolver esta solução para o cliente, e por fim existe alguém no meio do caminho (um gestor de projetos ou um SCRUM Master como caracteria o método SCRUM) que trabalha para gerenciar a espectativa do cliente, a produção do desenvolvedor com o objetivo de chegar a conclusão do projeto com uma ferramenta de software entregue dentro das especificações/necessidades do cliente.
Em meio a tudo isso, falando específicamente da proposta do SCRUM, temos a promessa de que por meio de um modelo de gestão ágil, o cliente terá aos poucos (a cada sprint) um elemento de software paupável, capaz de ser avaliado e se aprovado, devidamente publicado em produção, isso em um processo cíclico, contínuo até a conclusão do projeto, ou seja o cliente tem sempre algo pra ver, testar, mudar se quiser e com isso a dinâmica do projeto muda, a visão dos envolvidos muda, a realidade de desenvolvimento do projeto muda, muito mais foco no que é necessário, muito mais foco no que é utilizável, muito menos foco no que é burocrático.
Bom, parece um sonho perfeito, mas se é tão bom assim, o que falta para vingar de vez? o que falta para vermos o papel SCRUM MASTER presente cada vez mais nas fábricas de software e núcleos de desenvolvimento? o que falta para vermos SCRUM como parte do conteúdo das matérias relacionadas a “METODOLOGIAS” de desenvolvimento de software nas faculdades? Na minha humilde opinião, falta coragem para testar, para arriscar, para quebrar paradigmas que acomodam as empresas desenvolvedoras de software sob a falsa segurança de poder gerenciar suas entregas e controlar seus desvios de percurso por trás de gigantescos cronogramas em PROJECT onde o cliente só consegue se deparar com elementos entregáveis do projeto depois de meses de trabalho da equipe de software, depois de muito dinheiro gasto e com isso mesmo que ele não esteja muito satizfeito com o que vai receber, vai ser obrigado a se sujeitar a isso para não ter prejuízo…
Ao contrário do que muitos dizem, não vejo SCRUM como um modismo, vejo como uma evolução na forma de se pensar projetos de software, na forma de se desenvolver projetos de software, mas principalmente na forma de se relacionar entre os 3 principais envolvidos no processo de desenvolvimento de software, o desenvolvedor, o gestor e o cliente, pois o SCRUM os colocar em um contexto de colaboração, cumplicidade, e não mais naquela rivalidade do “só vou fazer o que foi especificado lá trás e pronto” ou “se mudar o escopo vai ter que mudar o prazo, e vai ficar mais caro…” como se vê na maioria dos contextos.
SCRUM ajuda a dar a TI a visibilidade de apoiador, viabilizador, aliado, e com isso todos nõs que trabalhamos com desenvolvimento de software porque gostamos disso, teremos além do prazer de ver um produto concluído e entregue, a satizfação do nosso cliente não somente no que ele está recebendo mas também na forma como ele participou também no desenvolvimento deste produto.
Ganha a empresa que vendeu o projeto, ganha o desenvolvedor, ganha o cliente, enfim… ganhamos todos nós!
Eu acredito no SCRUM, e você?
Estou entrando agora no mundo RoR (Ruby on Rails) e estou lamentando não ter tido a oportunidade de ter entrado antes.
Estamos passando por um momento em que muito tem se falado sobre agilidade em desenvolvimento de software, não vou entrar no mérito da questão se isso é um modismo, uma necessidade ou um amadurecimento do mercado, o fato é que está acontecendo, os profissionais estão buscando alternativas para se desenvolver software mais rápido, com mais qualidade e com menor custo.
Daí, muito se tem ouvido sobre processos ágeis, métodos ágeis, ou seja, um foco muito grande no processo de desenvolvimento e na gestão deste processo, por isso o grande destaque que se tem dado principalmente ao XP e ao SCRUM (que merece uma atenção especial).
Mas um outro aspecto do desenvolvimento ágil que também precisa de muita atenção é justamente o aspecto tecnológico, o ferramental, tecnologias que tornem o processo de desenvolvimento mais ágil também, e neste contexto quem mais vem chamando a atenção na comunidade nos últimos tempos sem sombra de dúvidas é o Framework Rails para a linguagem Ruby.
Um casamento perfeito, uma linguagem poderosíssima (que possui suas limitações como qualquer outra, abordarei isso em outro post) que possibilitou a criação de um framework altamente produtivo e com grande qualidade no produto final, o código gerado.
Mas o mais legal em tudo isso, é o fascínio que a linguagem Ruby é capaz de despertar em quaquer desenvolvedor que goste realmente de programar, pois o poder que ela possui por trás do seu dinamismo é capaz de dar asas ao pensamento criativo de qualquer programador.
Programar Ruby on Rails é prazeroso, é divertido pois muito do trabalho braçal que o desenvolvedor tinha em codificação para transações de persistência, validações e outras mais pode ser reduzido a umas poucas linhas de código que fazem todo esse trabalho com maestria, sem contar a beleza que se vê no código gerado, claro, limpo, fácil de compreender e de manusear.
O resultado não poderia ser outro, o desenvolvedor fica mais focado na solução, no projeto a ser produzido, e isso com mais produtividade e menos desgaste.
Enfim, eu poderia continuar jogando um monte de confete nesta plataforma que conquistou minha admiração, mas o melhor jeito de você confirmar se o que eu estou falando é verdade ou não é pondo a mão na massa, recomendo que você pesquise a respeito, leia, faça downloads, instale e “brinque”, mas cuidado, você com certeza vai sentir uma certa frustração em ter que voltar para o JAVA ou para o C# no seu dia a dia depois de ver como é “animal” programar em Ruby on Rails.
Para ajudar, seguem algumas referências legais:
Designed By :
