Por Henrique Meira
Um livro que descreve o que o open source é, discute razões de negócios para se usar o open source, e descreve como um projeto open source trabalha no dia-a-dia. Ele ajuda a decidir onde o open source é certo para o projeto, e, se for, quais passos devem ser tomados para proceder e alguns erros que devem ser evitados".
O livro está sob a licensa Creative Commons Attribution - NonCommercial. Ainda em inglês, e pode ser acessado pelo link: http://dreamsongs.com
Publicado originalmente no endereço http://www.dicas-l.com.br
quarta-feira, agosto 30, 2006
terça-feira, agosto 29, 2006
As fabricas de Software
Por Farmy Gonçalves Ferreira da Silva.
"Há algum tempo no Brasil temos convivido com as fabricas de software ou software houses como são conhecidas. Mas será que podemos conceitua-las como fabricas? Será que elas estão dentro desse modelo? Bom, novamente vamos ver a figura do engenheiro de sistemas, e de seu papel para que esse conceito seja implantado.
Bom como disse há algum tempo convivemos com as fabricas de software, com as tão famosas software houses, e em muitos casos convivemos com softwares de péssima qualidade.
Não é raro em nosso e-mail solicitarem profissionais com certificados de CMMI, ou com conhecimento de técnicas de qualidade como Scrum ou XP. Essa necessidade é um fator relevante párea este artigo afinal quem nunca viu um software de péssima qualidade, ou uma solução que não atendia as reais necessidades de nossos clientes.
A culpa é o prazo apertado, a analise mal feita, ou o domínio mínimo da linguagem pelo programador. Embora vários pontos podem ser vistos como culpados, toda software house sabe; que ela consome intensivamente a mão-de-obra, consumindo mais capital humano por valor produzido do que deveria se esperar de uma industria moderna.
A tendência é de aumentar a demanda por software, não pela qualidade dos mesmos, ou pela forma que são fornecidos, mas sim pelo valor mínimo que eles possam agregar ao cliente em si. Por isso, muitos deles correm o risco de investirem em uma solução.
Embora essa tendência seja crescente na próxima década, a demanda por software deva crescer exponencialmente, ainda trabalhamos como nos primórdios, técnicas de qualidade e metodologias para isso não foram adotadas pelo mercado de software e talvez por esse fato ainda não se pode chamar as software houses de fabricas de software.
Nesse momento perguntamos, o que vai mudar? E como se preparar para a mudança?
Na verdade eu acho que a pergunta mais pertinente é, como reestruturar as software houses para serem conhecidas como fabricas de software? Nesse momento vamos ver novamente uma figura muito conhecida por vocês em meus artigos, quem projeta uma software house é um engenheiro de software.
Parece absurdo, mas sim, é ele. E muitos vão dizer: “É um absurdo, para ser uma software house você precisa a penas conhecer bem o mercado e criar um software que atenda essa necessidade”. Sim eu direi, mas uma fabrica não funciona assim; para ser uma fabrica de software você precisa antes de tudo possuir a infra-estrutura de uma fabrica essa infra-estrutura pode ser definida como escopo, pois não é apenas especo físico, mas sim o somatório do espaço físico com a qualidade aplicada, é implementar técnicas da ISO9000 na infra-estrutura, utilizar modelos de papeis do RUP na definição dos setores e das equipes, criar a interoperabilidade entre os setores e criar a maturidade dos processos ordenados, documentados e implementados com as técnicas de PMI e CMMI. Mas diante de tantas técnicas o que mais conta é o business plan, e o recovery risk plan ou seja, seu plano de negócios e seu plano de riscos, afinal de contas quem não tem um bom plano de negócios não vai em frente, e quem não sabe os riscos que corre, não conhece o mercado que atua.
Na formação do profissional que quer ser arquiteto de software, ou engenheiro, existe uma diversidade na formação, com no artigo anterior fui questionado sobre como seria a formação desse profissional, deixo aqui a base da sua formação: multidisciplinar.
O Engenheiro deve conhecer, finanças muito bem, administração de empresas, amar, eu disse amar a tecnologia e os padrões de qualidade, conhecer protocolos e infra-estrutura e claro ser um bom analista de sistemas e de negócios.
As disciplinas que você deve cumprir para esta formação ficam a sua escolha. Mas para chegarmos ao patamar onde a produção de software seja vista como uma fabrica precisamos adotar os métodos de qualidade e principalmente a infra-estrutura que deve ser envolvida para atender a cada uma.
Publicado originalmento no endereço: http://www.profissionaisdetecnologia.com.br
"Há algum tempo no Brasil temos convivido com as fabricas de software ou software houses como são conhecidas. Mas será que podemos conceitua-las como fabricas? Será que elas estão dentro desse modelo? Bom, novamente vamos ver a figura do engenheiro de sistemas, e de seu papel para que esse conceito seja implantado.
Bom como disse há algum tempo convivemos com as fabricas de software, com as tão famosas software houses, e em muitos casos convivemos com softwares de péssima qualidade.
Não é raro em nosso e-mail solicitarem profissionais com certificados de CMMI, ou com conhecimento de técnicas de qualidade como Scrum ou XP. Essa necessidade é um fator relevante párea este artigo afinal quem nunca viu um software de péssima qualidade, ou uma solução que não atendia as reais necessidades de nossos clientes.
A culpa é o prazo apertado, a analise mal feita, ou o domínio mínimo da linguagem pelo programador. Embora vários pontos podem ser vistos como culpados, toda software house sabe; que ela consome intensivamente a mão-de-obra, consumindo mais capital humano por valor produzido do que deveria se esperar de uma industria moderna.
A tendência é de aumentar a demanda por software, não pela qualidade dos mesmos, ou pela forma que são fornecidos, mas sim pelo valor mínimo que eles possam agregar ao cliente em si. Por isso, muitos deles correm o risco de investirem em uma solução.
Embora essa tendência seja crescente na próxima década, a demanda por software deva crescer exponencialmente, ainda trabalhamos como nos primórdios, técnicas de qualidade e metodologias para isso não foram adotadas pelo mercado de software e talvez por esse fato ainda não se pode chamar as software houses de fabricas de software.
Nesse momento perguntamos, o que vai mudar? E como se preparar para a mudança?
Na verdade eu acho que a pergunta mais pertinente é, como reestruturar as software houses para serem conhecidas como fabricas de software? Nesse momento vamos ver novamente uma figura muito conhecida por vocês em meus artigos, quem projeta uma software house é um engenheiro de software.
Parece absurdo, mas sim, é ele. E muitos vão dizer: “É um absurdo, para ser uma software house você precisa a penas conhecer bem o mercado e criar um software que atenda essa necessidade”. Sim eu direi, mas uma fabrica não funciona assim; para ser uma fabrica de software você precisa antes de tudo possuir a infra-estrutura de uma fabrica essa infra-estrutura pode ser definida como escopo, pois não é apenas especo físico, mas sim o somatório do espaço físico com a qualidade aplicada, é implementar técnicas da ISO9000 na infra-estrutura, utilizar modelos de papeis do RUP na definição dos setores e das equipes, criar a interoperabilidade entre os setores e criar a maturidade dos processos ordenados, documentados e implementados com as técnicas de PMI e CMMI. Mas diante de tantas técnicas o que mais conta é o business plan, e o recovery risk plan ou seja, seu plano de negócios e seu plano de riscos, afinal de contas quem não tem um bom plano de negócios não vai em frente, e quem não sabe os riscos que corre, não conhece o mercado que atua.
Na formação do profissional que quer ser arquiteto de software, ou engenheiro, existe uma diversidade na formação, com no artigo anterior fui questionado sobre como seria a formação desse profissional, deixo aqui a base da sua formação: multidisciplinar.
O Engenheiro deve conhecer, finanças muito bem, administração de empresas, amar, eu disse amar a tecnologia e os padrões de qualidade, conhecer protocolos e infra-estrutura e claro ser um bom analista de sistemas e de negócios.
As disciplinas que você deve cumprir para esta formação ficam a sua escolha. Mas para chegarmos ao patamar onde a produção de software seja vista como uma fabrica precisamos adotar os métodos de qualidade e principalmente a infra-estrutura que deve ser envolvida para atender a cada uma.
Publicado originalmento no endereço: http://www.profissionaisdetecnologia.com.br
O Engenheiro de Software e a Gerencia de Projetos II
Por Farmy Gonçalves Ferreira da Silva.
"Seguindo a linha de raciocínio do artigo anterior, vamos observar que os projetos de TI são muito mais abrangentes do que pode ser percebido, a palavra chave é o “core business” da empresa e dentro de todas as atividades de uma empresa que procura ser líder no seu mercado, ou seja, obter lucro; ele deve implementar, ou ter implementado, dois projetos muito comentados até hoje: o ERP e o CRM. Aplicações desse tipo são tidas como cruciais pois muitas levam tempo, consomem altas cifras e no fim não atende ao objetivo almejado. SAP, IBM e MICROSOFT possuem os grandes medalhões nessa área por serem empresas já consolidadas no mercado de tecnologia, mas existem vários pequenos fornecedores com histórias de sucesso e boas opções.
Mas qual o papel do engenheiro de software num projeto desse porte? O que envolve um projeto dessa magnitude? Essas e outras perguntas precisam antes de alguns alicerces. Os conceitos sobre ERP podem ser lidos no artigo de nosso companheiro André Guedes os conceitos sobre BI podem ser obtidos no artigo da companheira Scheila Mello e do companheiro Ricardo Mansur. Depois de obtido esses conceitos, podemos discutir o que pode ser realizado pelo engenheiro de software, note que não me focarei no CRM pois ainda não existe um artigo sobre esse assunto que possa auxiliar no conceito básico do assunto, quem sabe não seja um próximo.
A primeira coisa a se saber é, as empresas não são criadas com um sistema de ERP em mente, mas sim um negócio, um ramo ou atividade. Dado este fato, os projetos de ERP são alcançados quando uma empresa atinge um determinado nível de vida e maturidade em gestão. Você deve dizer “maturidade nada, necessidade mesmo”, este é outro fator para a implementação de sistemas de ERP, e por estes motivos, vários problemas precisam ser visualizados. Com dissemos no artigo anterior, gerir projetos é um desafio que necessita mais do que o conhecimento de Tecnologia, e que muitos projetos são geridos por excelentes técnicos mais péssimos gerentes. Esse fator num projeto como o ERP e BI podem levar aos já muitos comentados fracassos dessa área.
Com você deve imaginar existe uma forma, ou melhor, metodologia que define como pensar nos passos da implementação de um sistema de ERP; é agora que entre em cena o nosso Engenheiro de software, afinal ele não é um analista de sistema, mas sim um gestor, um gerente de tecnologia. E entre outras responsabilidades ele precisa expor para a alta gerencia que um sistema de ERP, CRM e BI, geram uma mudança na forma de gerir e na filosofia da empresa, para isso precisa entre outras coisas contar com uma consultoria externa que traga experiência de sucesso e fracasso também, afinal ninguém aprende apenas com acertos. E junto com a consultoria realizar algumas fases para a implementação do projeto, sendo elas:
· Fase 1 – Raio-X
Esta é a fase do projeto, em que os processos e as práticas de negócio são analisados. É o momento em que a empresa é profundamente observada e quando é definida a necessidade de uma solução ERP.
· Fase 2 – Desenvolvimento
É nesse momento que uma aplicação é escolhida e configurada para uma empresa. Também são definidos o modelo de funcionamento da solução e outros aspectos do ambiente.
· Fase 3 – Teste
Aqui, a solução de ERP é colocada em ambiente de teste. É quando os erros e as falhas são identificados.
· Fase 4 – Treinamento
Todos os profissionais são treinados no sistema para saber como utilizá-lo antes da implementação ser concluída.
· Fase 5 – Implementação
O software de ERP é finalmente instalado na empresa e torna-se funcional aos usuários.
· Fase 6 – Avaliação
A solução de ERP é avaliada, observando-se o que é necessário melhorar e o que está ou não funcionando adequadamente. Essa é apenas uma avaliação geral do projeto ERP para referências futuras.
Observem que estas fases envolvem outras metodologias, e devem ser adotadas de forma repetitiva durante toda a vida do sistema de ERP, observe que a necessidade da consultoria se faz necessária principalmente na analise da empresa, pois visões diferentes convergem para um sucesso maior. Um ponto critico em todos os sistemas é o nível de conhecimento dos usuários, observe que a fase de treinamento se dá durante o projeto e não depois que ele esta implementado, afinal isso garante que quando concluído seus usuários já estejam capacitados para a sua plena utilização, por outro lado, nesta definição os testes acontecem durante a terceira fase e novamente a equipe de TI deve ser muito bem gerida e o engenheiro deve ter a capacidade de solucionar problemas como vícios da equipe de desenvolvimento e a influencia da consultoria externa. Uma solução adotada por algumas empresas foi utilizar uma segunda consultoria neste momento.
As tarefas que o engenheiro deve ter em mente quando definir um projeto de ERP são:
· Defina, em detalhes, o que será realizado.
· Liste o que se espera dos novos recursos.
· Combine o processo de implementação com a cultura empresarial.
· Defina as responsabilidades do fornecedor e as dos parceiros em contrato.
· Mantenha o gerenciamento da estrutura sob controle e reforce o comprometimento.
· Teste e treine.
Dessa forma, os projetos de ERP podem obter maior chance de sucesso, lembrando que o comprometimento da gerencia é imprescindível neste contexto, por isso n]ao só o Engenheiro de software como também um gerente empresarial deve estar completamente envolvido neste projeto. Afinal após a implementação de um sistema de ERP, a empresa começa a querer sistemas de apoio a decisão empresarial, os chamados BI “Business Inteligence”, neste caso a função maior do engenheiro é traduzir as necessidades da gerencia em softwares, manter a facilidade de uso e a integridade dos dados apresentados. Um sistema de BI não é tão simples como se pensa, envolvem múltiplas tecnologias e um bom projeto de integração entre os sistemas empresarias.
Um projeto de BI envolve a necessidade de demonstrar pra alta gerencia o impacto das relações transacionas ocorridas dentro do ERP, esses sistemas necessitam de interface simples e de disponibilidade imediata para a alta gerencia, é muito comum em um sistema de BI estar inserido um projeto de portal WEB, pois a facilidade de uso e a interface devem ser o mais amigável para o gestor, nessa fase o banco de dados adotado fica a toda a prova e a responsabilidade do engenheiro passa ser a de estar levantando todas as necessidades informacional da gerencia (relatórios, consultas, pesquisas, etc.) e traga a informação desejada pelo gestor para a tomada de decisão, é comum utilizar uma base de casos e trazer para o gestor o impacto da sua decisão anterior, dessa forma refletindo todo o passado da empresa.
Um projeto de BI começa no DW “Data Werehouse” ou nos departamentos da empresa, com DM “Data Marts”, entendem-se pelos sistemas transacionais e armazenam todos os processos do dia-a-dia da empresa, por este motivo o engenheiro de software precisa ter em sua formação o conhecimento empresarial, saber lidar e qual a informação de cada setor da empresa, ter a capacidade de analisar a sua integridade e validade, determinar o valor dessa informação para o sistema e para a empresa. Conhecimentos que precisam de formações não tradicionais, levanto o posicional para a formação multidisciplinar. Conhecimento de RH e psicologia, finanças e economia, tecnologia e empreendedorismo, contabilidade e direito, banco de dados e rede de computadores; das mais diversas áreas e para os mais diversos propósitos, afinal ele precisa compreender a empresa como um todo.
Não existe uma forma de se começar um projeto de BI, como disse acima, ele pode começar diretamente no DW, quando a empresa já possui seus dados consolidados e armazenados em um único lugar, ou pela definição passo a passo das necessidades departamentais de armazenamento histórico sobre suas atividades esses dados dão origem aos DM, que logo serão consolidados em um DW, o valor de cada informação deve ser considerado e analisado de acordo com a finalidade da empresa e sua cultura, por fim as tecnologias de acesso a essa informação devem ser pesquisadas. Aqui o engenheiro começa a trabalhar diretamente com os setores e com a equipe de TI, logo um membro da alta gerência deve estar inserido neste processo para que o valor de cada dado que componha a informação seja mensurado e forme um repositório informacional integro.
Vimos neste artigo, que gerir projetos não é só, definir o que o software deve ou não fazer, mas muitas vezes discutir e implementar novas metodologias na execução de uma função, compreender cada área da empresa, não esquecendo de citar marketing e relacionamento com os clientes, e saber como disponibilizar essa informação para a gerencia. Será que um analista de sistema tem essa capacidade? Será que um Administrador te essa capacidade? Cada um sabe qual o perfil do gerente de projetos que melhor cabe a sua empresa.
Publicado originalmento no endereço: http://www.profissionaisdetecnologia.com.br
"Seguindo a linha de raciocínio do artigo anterior, vamos observar que os projetos de TI são muito mais abrangentes do que pode ser percebido, a palavra chave é o “core business” da empresa e dentro de todas as atividades de uma empresa que procura ser líder no seu mercado, ou seja, obter lucro; ele deve implementar, ou ter implementado, dois projetos muito comentados até hoje: o ERP e o CRM. Aplicações desse tipo são tidas como cruciais pois muitas levam tempo, consomem altas cifras e no fim não atende ao objetivo almejado. SAP, IBM e MICROSOFT possuem os grandes medalhões nessa área por serem empresas já consolidadas no mercado de tecnologia, mas existem vários pequenos fornecedores com histórias de sucesso e boas opções.
Mas qual o papel do engenheiro de software num projeto desse porte? O que envolve um projeto dessa magnitude? Essas e outras perguntas precisam antes de alguns alicerces. Os conceitos sobre ERP podem ser lidos no artigo de nosso companheiro André Guedes os conceitos sobre BI podem ser obtidos no artigo da companheira Scheila Mello e do companheiro Ricardo Mansur. Depois de obtido esses conceitos, podemos discutir o que pode ser realizado pelo engenheiro de software, note que não me focarei no CRM pois ainda não existe um artigo sobre esse assunto que possa auxiliar no conceito básico do assunto, quem sabe não seja um próximo.
A primeira coisa a se saber é, as empresas não são criadas com um sistema de ERP em mente, mas sim um negócio, um ramo ou atividade. Dado este fato, os projetos de ERP são alcançados quando uma empresa atinge um determinado nível de vida e maturidade em gestão. Você deve dizer “maturidade nada, necessidade mesmo”, este é outro fator para a implementação de sistemas de ERP, e por estes motivos, vários problemas precisam ser visualizados. Com dissemos no artigo anterior, gerir projetos é um desafio que necessita mais do que o conhecimento de Tecnologia, e que muitos projetos são geridos por excelentes técnicos mais péssimos gerentes. Esse fator num projeto como o ERP e BI podem levar aos já muitos comentados fracassos dessa área.
Com você deve imaginar existe uma forma, ou melhor, metodologia que define como pensar nos passos da implementação de um sistema de ERP; é agora que entre em cena o nosso Engenheiro de software, afinal ele não é um analista de sistema, mas sim um gestor, um gerente de tecnologia. E entre outras responsabilidades ele precisa expor para a alta gerencia que um sistema de ERP, CRM e BI, geram uma mudança na forma de gerir e na filosofia da empresa, para isso precisa entre outras coisas contar com uma consultoria externa que traga experiência de sucesso e fracasso também, afinal ninguém aprende apenas com acertos. E junto com a consultoria realizar algumas fases para a implementação do projeto, sendo elas:
· Fase 1 – Raio-X
Esta é a fase do projeto, em que os processos e as práticas de negócio são analisados. É o momento em que a empresa é profundamente observada e quando é definida a necessidade de uma solução ERP.
· Fase 2 – Desenvolvimento
É nesse momento que uma aplicação é escolhida e configurada para uma empresa. Também são definidos o modelo de funcionamento da solução e outros aspectos do ambiente.
· Fase 3 – Teste
Aqui, a solução de ERP é colocada em ambiente de teste. É quando os erros e as falhas são identificados.
· Fase 4 – Treinamento
Todos os profissionais são treinados no sistema para saber como utilizá-lo antes da implementação ser concluída.
· Fase 5 – Implementação
O software de ERP é finalmente instalado na empresa e torna-se funcional aos usuários.
· Fase 6 – Avaliação
A solução de ERP é avaliada, observando-se o que é necessário melhorar e o que está ou não funcionando adequadamente. Essa é apenas uma avaliação geral do projeto ERP para referências futuras.
Observem que estas fases envolvem outras metodologias, e devem ser adotadas de forma repetitiva durante toda a vida do sistema de ERP, observe que a necessidade da consultoria se faz necessária principalmente na analise da empresa, pois visões diferentes convergem para um sucesso maior. Um ponto critico em todos os sistemas é o nível de conhecimento dos usuários, observe que a fase de treinamento se dá durante o projeto e não depois que ele esta implementado, afinal isso garante que quando concluído seus usuários já estejam capacitados para a sua plena utilização, por outro lado, nesta definição os testes acontecem durante a terceira fase e novamente a equipe de TI deve ser muito bem gerida e o engenheiro deve ter a capacidade de solucionar problemas como vícios da equipe de desenvolvimento e a influencia da consultoria externa. Uma solução adotada por algumas empresas foi utilizar uma segunda consultoria neste momento.
As tarefas que o engenheiro deve ter em mente quando definir um projeto de ERP são:
· Defina, em detalhes, o que será realizado.
· Liste o que se espera dos novos recursos.
· Combine o processo de implementação com a cultura empresarial.
· Defina as responsabilidades do fornecedor e as dos parceiros em contrato.
· Mantenha o gerenciamento da estrutura sob controle e reforce o comprometimento.
· Teste e treine.
Dessa forma, os projetos de ERP podem obter maior chance de sucesso, lembrando que o comprometimento da gerencia é imprescindível neste contexto, por isso n]ao só o Engenheiro de software como também um gerente empresarial deve estar completamente envolvido neste projeto. Afinal após a implementação de um sistema de ERP, a empresa começa a querer sistemas de apoio a decisão empresarial, os chamados BI “Business Inteligence”, neste caso a função maior do engenheiro é traduzir as necessidades da gerencia em softwares, manter a facilidade de uso e a integridade dos dados apresentados. Um sistema de BI não é tão simples como se pensa, envolvem múltiplas tecnologias e um bom projeto de integração entre os sistemas empresarias.
Um projeto de BI envolve a necessidade de demonstrar pra alta gerencia o impacto das relações transacionas ocorridas dentro do ERP, esses sistemas necessitam de interface simples e de disponibilidade imediata para a alta gerencia, é muito comum em um sistema de BI estar inserido um projeto de portal WEB, pois a facilidade de uso e a interface devem ser o mais amigável para o gestor, nessa fase o banco de dados adotado fica a toda a prova e a responsabilidade do engenheiro passa ser a de estar levantando todas as necessidades informacional da gerencia (relatórios, consultas, pesquisas, etc.) e traga a informação desejada pelo gestor para a tomada de decisão, é comum utilizar uma base de casos e trazer para o gestor o impacto da sua decisão anterior, dessa forma refletindo todo o passado da empresa.
Um projeto de BI começa no DW “Data Werehouse” ou nos departamentos da empresa, com DM “Data Marts”, entendem-se pelos sistemas transacionais e armazenam todos os processos do dia-a-dia da empresa, por este motivo o engenheiro de software precisa ter em sua formação o conhecimento empresarial, saber lidar e qual a informação de cada setor da empresa, ter a capacidade de analisar a sua integridade e validade, determinar o valor dessa informação para o sistema e para a empresa. Conhecimentos que precisam de formações não tradicionais, levanto o posicional para a formação multidisciplinar. Conhecimento de RH e psicologia, finanças e economia, tecnologia e empreendedorismo, contabilidade e direito, banco de dados e rede de computadores; das mais diversas áreas e para os mais diversos propósitos, afinal ele precisa compreender a empresa como um todo.
Não existe uma forma de se começar um projeto de BI, como disse acima, ele pode começar diretamente no DW, quando a empresa já possui seus dados consolidados e armazenados em um único lugar, ou pela definição passo a passo das necessidades departamentais de armazenamento histórico sobre suas atividades esses dados dão origem aos DM, que logo serão consolidados em um DW, o valor de cada informação deve ser considerado e analisado de acordo com a finalidade da empresa e sua cultura, por fim as tecnologias de acesso a essa informação devem ser pesquisadas. Aqui o engenheiro começa a trabalhar diretamente com os setores e com a equipe de TI, logo um membro da alta gerência deve estar inserido neste processo para que o valor de cada dado que componha a informação seja mensurado e forme um repositório informacional integro.
Vimos neste artigo, que gerir projetos não é só, definir o que o software deve ou não fazer, mas muitas vezes discutir e implementar novas metodologias na execução de uma função, compreender cada área da empresa, não esquecendo de citar marketing e relacionamento com os clientes, e saber como disponibilizar essa informação para a gerencia. Será que um analista de sistema tem essa capacidade? Será que um Administrador te essa capacidade? Cada um sabe qual o perfil do gerente de projetos que melhor cabe a sua empresa.
Publicado originalmento no endereço: http://www.profissionaisdetecnologia.com.br
O Engenheiro de Software e a Gerencia de Projetos
Por Farmy Gonçalves Ferreira da Silva.
Até o início da década de 90, a modernização do ambiente de tecnologia da informação era argumento suficiente para justificar investimentos em novos equipamentos e sistemas corporativos. Porém, nesses últimos 13 anos, a competição entre as empresas e a necessidade premente de redução de custos, aliada ao aumento de produtividade, derrubou os muros dos departamentos de informática e, com eles, a linguagem técnica dos seus profissionais.
A própria distância entre o mundo informatizado e o dos negócios tornou-se infinitamente menor, eliminando inclusive o termo "informática" do linguajar corporativo e colocando em evidência a Tecnologia da Informação ou TI. Em resumo, a utilização de ferramentas tecnológicas para o aperfeiçoamento da informação circulante dentro das empresas e delas com parceiros, fornecedores e clientes - corporativos ou individuais - tornou-se comum.
Esse movimento permitiu que todos os profissionais - não apenas aqueles mais experientes em TI - tivessem acesso aos novos recursos e também passassem a ser assediados por fornecedores e prestadores de serviços. As decisões de compra deixaram de ser exclusividade do líder de TI, sendo divididas com gerentes e diretores de outras áreas de negócio e justificadas, muitas vezes, perante um conselho executivo.
Se no passado, a TI era inquestionável, porque as corporações tinham mais dinheiro e menos recurso intelectual para por à prova as decisões dessa área, agora é quase que vital re-visitar o departamento e seus gastos, avaliando a importância da Tecnologia da Informação para o negócio. A TI passou a ser empurrada pelo “business” tendo a sua importância discutida com muito mais freqüência e profundidade.
Essa mudança foi a principal responsável pelo aparecimento de termos como o retorno do investimento (ROI), cujo objetivo é facilitar a aprovação de novos projetos, o acompanhamento da sua implementação e a medição dos resultados. Esses recursos permitem identificar, por exemplo, em quanto tempo um novo sistema devolve o seu custo aos cofres da corporação na forma de aumento de produtividade e melhoria de desempenho frente à concorrência.
Essa é uma das novas exigências ao profissional de TI, deixando pra traz o cargo máximo de analista de sistemas e trazendo a função de engenharia, pois neste momento o departamento de TI passa a ser colaborador direto do “core business” da empresa, ou seja, passa a gerir a solução desde o departamento de tecnologia até o caminhão que vai pra rua. Este nova tarefa precisa ser apoiada por ferramentas e metodologias, como a forma mais fácil de falar com a equipe de tecnologia é utilizar a sua linguagem, UML esta presente neste processo, mas como agregar a UML com uma metodologia e linguagem que toda a empresa consiga ler e falar? Bom neste momento tomamos carona na pratica mais adotada no mercado de gestão de projetos o PMI. Veremos neste artigo o que vem a ser PMI, onde ele se estende para a linguagem tecnológica de projetos UML e qual o Papel do “Engenheiro de Software”, ou Engenheiro de TI neste contexto.
Antes de tudo, a equipe de TI e a Alta gerenciam da empresa deveria definir o “business plan” (um plano de negócios), para ser possível identificar onde e quando o valor do investimento planejado será encontrado e o quê é essencialmente necessário para que o projeto obtenha sucesso.
Isso é importante para especificar objetivos, acordos com grandes acionistas da companhia e as pesquisas que se fazem necessárias. O case de negócio baliza inclusive como o escopo do projeto deve ser gerenciado e auxilia o refinamento dos processos que serão melhorados com a tecnologia. Em resumo, ele define como o sucesso acontecerá.
Após essa fase, entramos no processo do PMI, que nos diz que: “Na gerencia de projetos existe uma característica forte de interação”. Essas interações pode ser compreendidas como processos, ou etapas de um projeto, portanto no PMBOK, é descrito uma forma de relação entre estes processos ou etapas. Seguindo a seguinte ordem:
1. Processos de um projeto;
2. Grupos de um processo;
3. Interações entre os processos;
4. Adaptações das Interações entre os processos.
Seguindo essa idéia, podemos observar algumas semelhanças com as nomenclaturas da UML, o que facilita a documentação para a equipe de TI.
Então qual as habilidades para se gerir um projeto?
Muitas empresas colocam como diretores ou gerentes de projetos, seus funcionários mais antigos, especialistas altamente gabaritado em uma atividade fim, existem vários casos de sucesso, na verdade a experiência dentro da empresa conta como fator, mas não podemos garantir que um especialista conseguirá exercer as atribuições de um gerente. Numa grande maioria de casos a empresa perde um excepcional especialista e ganha um péssimo gerente.
O importante é que o papel do gerente de projetos não garante o sucesso do mesmo, mas sim a qualificação do profissional quanto a gerencia, desenvolver bem suas habilidades inerentes a esta tarefa, conhecer e aplicar boas técnicas de gerencia e as habilidades de:
· Comunicação;
· Organização;
· Elaboração de orçamentos;
· Solucionar problemas;
· Negociar e influenciar;
· Liderança;
· Formação de equipes e recursos humanos;
Com essas habilidades básicas, o gerente de projeto começa ser qualificado em sua função.
Agora vem as atribuições de um bom projeto, como vimos a cima, os projetos são formados por processos ou etapas, divididos em grupos, e alocados sob interações e adaptações de interações.
O Plano de negócios dá a base para todos os projetos dentro de uma empresa bem organizada, com base no plano de negocio, o gerente define o escopo do projeto junto com a alta gerencia e as áreas de apoio, define o orçamento e o ROI, aloca pessoas em grupos responsáveis por processos ou etapas, faz um plano de risco, um plano de contingência, e define as métricas a serem utilizadas para manter a qualidade e os prazos do projeto. A partir deste momento o projeto começa a ser gerido de acordo com esses planos.
Com o escopo definido, os analistas começam seus trabalhos, observe que os grupos por etapas são definidos pelo gerente e não pelo analista, se cada etapa do projeto já esta definida, a criação de um modelo de documentação fica muito mais fácil, afinal sabemos de antemão quem são os responsáveis, onde esta etapa será atingida e como deverá ser tratada.
É função do gerente ou engenheiro de sistemas definir nos riscos de cada processos (etapa), o custo e o plano de contingência, note que todas essas funções recaem sobre um individuo só, por isso definimos as atribuições desse papel como básicas afinal um bom gerente é generalista, líder, e tem influencia sobre a equipe. Desta forma, ele deve ser capas de traduzir toda a documentação gerada pela equipe de TI para a alta gerencia, como também traduzir todos os aspectos do projeto para a equipe de TI.
O controle de projetos é incremental e abre portas para diversas metodologias, por exemplo, o RUP, que atende a projetos com diversas equipes, documentando o papel do individuo dentro de cada equipe, suas atribuições, interações e prazos. Isso traz para o gestor de projetos uma gama muito grande de possibilidades de controle sobre o projeto, suas equipes e prazos. Desta forma aplica-se mais uma vez a formação do gerente de projetos, que deve definir também qual a metodologia a ser utilizada.
Por fim, gerir projetos requer do profissional, mais atribuições do que simplesmente o tempo de empresa, ou o conhecimento específico de uma tecnologia envolvida, a documentação e as interações são parte critica neste processo, e a capacidade de negociar e solucionar problemas é o fator que mais pesa na decisão sobre o gerente de projetos, afinal os prazos são diretamente afetados por estes parâmetros. O orçamento e o ROI justificam o projeto, mas não são garantidos, e as metodologias dependem diretamente da capacidade organizacional do gestor. Função fim do engenheiro de sistemas.
Publicado originalmento no endereço: http://www.profissionaisdetecnologia.com.br
Até o início da década de 90, a modernização do ambiente de tecnologia da informação era argumento suficiente para justificar investimentos em novos equipamentos e sistemas corporativos. Porém, nesses últimos 13 anos, a competição entre as empresas e a necessidade premente de redução de custos, aliada ao aumento de produtividade, derrubou os muros dos departamentos de informática e, com eles, a linguagem técnica dos seus profissionais.
A própria distância entre o mundo informatizado e o dos negócios tornou-se infinitamente menor, eliminando inclusive o termo "informática" do linguajar corporativo e colocando em evidência a Tecnologia da Informação ou TI. Em resumo, a utilização de ferramentas tecnológicas para o aperfeiçoamento da informação circulante dentro das empresas e delas com parceiros, fornecedores e clientes - corporativos ou individuais - tornou-se comum.
Esse movimento permitiu que todos os profissionais - não apenas aqueles mais experientes em TI - tivessem acesso aos novos recursos e também passassem a ser assediados por fornecedores e prestadores de serviços. As decisões de compra deixaram de ser exclusividade do líder de TI, sendo divididas com gerentes e diretores de outras áreas de negócio e justificadas, muitas vezes, perante um conselho executivo.
Se no passado, a TI era inquestionável, porque as corporações tinham mais dinheiro e menos recurso intelectual para por à prova as decisões dessa área, agora é quase que vital re-visitar o departamento e seus gastos, avaliando a importância da Tecnologia da Informação para o negócio. A TI passou a ser empurrada pelo “business” tendo a sua importância discutida com muito mais freqüência e profundidade.
Essa mudança foi a principal responsável pelo aparecimento de termos como o retorno do investimento (ROI), cujo objetivo é facilitar a aprovação de novos projetos, o acompanhamento da sua implementação e a medição dos resultados. Esses recursos permitem identificar, por exemplo, em quanto tempo um novo sistema devolve o seu custo aos cofres da corporação na forma de aumento de produtividade e melhoria de desempenho frente à concorrência.
Essa é uma das novas exigências ao profissional de TI, deixando pra traz o cargo máximo de analista de sistemas e trazendo a função de engenharia, pois neste momento o departamento de TI passa a ser colaborador direto do “core business” da empresa, ou seja, passa a gerir a solução desde o departamento de tecnologia até o caminhão que vai pra rua. Este nova tarefa precisa ser apoiada por ferramentas e metodologias, como a forma mais fácil de falar com a equipe de tecnologia é utilizar a sua linguagem, UML esta presente neste processo, mas como agregar a UML com uma metodologia e linguagem que toda a empresa consiga ler e falar? Bom neste momento tomamos carona na pratica mais adotada no mercado de gestão de projetos o PMI. Veremos neste artigo o que vem a ser PMI, onde ele se estende para a linguagem tecnológica de projetos UML e qual o Papel do “Engenheiro de Software”, ou Engenheiro de TI neste contexto.
Antes de tudo, a equipe de TI e a Alta gerenciam da empresa deveria definir o “business plan” (um plano de negócios), para ser possível identificar onde e quando o valor do investimento planejado será encontrado e o quê é essencialmente necessário para que o projeto obtenha sucesso.
Isso é importante para especificar objetivos, acordos com grandes acionistas da companhia e as pesquisas que se fazem necessárias. O case de negócio baliza inclusive como o escopo do projeto deve ser gerenciado e auxilia o refinamento dos processos que serão melhorados com a tecnologia. Em resumo, ele define como o sucesso acontecerá.
Após essa fase, entramos no processo do PMI, que nos diz que: “Na gerencia de projetos existe uma característica forte de interação”. Essas interações pode ser compreendidas como processos, ou etapas de um projeto, portanto no PMBOK, é descrito uma forma de relação entre estes processos ou etapas. Seguindo a seguinte ordem:
1. Processos de um projeto;
2. Grupos de um processo;
3. Interações entre os processos;
4. Adaptações das Interações entre os processos.
Seguindo essa idéia, podemos observar algumas semelhanças com as nomenclaturas da UML, o que facilita a documentação para a equipe de TI.
Então qual as habilidades para se gerir um projeto?
Muitas empresas colocam como diretores ou gerentes de projetos, seus funcionários mais antigos, especialistas altamente gabaritado em uma atividade fim, existem vários casos de sucesso, na verdade a experiência dentro da empresa conta como fator, mas não podemos garantir que um especialista conseguirá exercer as atribuições de um gerente. Numa grande maioria de casos a empresa perde um excepcional especialista e ganha um péssimo gerente.
O importante é que o papel do gerente de projetos não garante o sucesso do mesmo, mas sim a qualificação do profissional quanto a gerencia, desenvolver bem suas habilidades inerentes a esta tarefa, conhecer e aplicar boas técnicas de gerencia e as habilidades de:
· Comunicação;
· Organização;
· Elaboração de orçamentos;
· Solucionar problemas;
· Negociar e influenciar;
· Liderança;
· Formação de equipes e recursos humanos;
Com essas habilidades básicas, o gerente de projeto começa ser qualificado em sua função.
Agora vem as atribuições de um bom projeto, como vimos a cima, os projetos são formados por processos ou etapas, divididos em grupos, e alocados sob interações e adaptações de interações.
O Plano de negócios dá a base para todos os projetos dentro de uma empresa bem organizada, com base no plano de negocio, o gerente define o escopo do projeto junto com a alta gerencia e as áreas de apoio, define o orçamento e o ROI, aloca pessoas em grupos responsáveis por processos ou etapas, faz um plano de risco, um plano de contingência, e define as métricas a serem utilizadas para manter a qualidade e os prazos do projeto. A partir deste momento o projeto começa a ser gerido de acordo com esses planos.
Com o escopo definido, os analistas começam seus trabalhos, observe que os grupos por etapas são definidos pelo gerente e não pelo analista, se cada etapa do projeto já esta definida, a criação de um modelo de documentação fica muito mais fácil, afinal sabemos de antemão quem são os responsáveis, onde esta etapa será atingida e como deverá ser tratada.
É função do gerente ou engenheiro de sistemas definir nos riscos de cada processos (etapa), o custo e o plano de contingência, note que todas essas funções recaem sobre um individuo só, por isso definimos as atribuições desse papel como básicas afinal um bom gerente é generalista, líder, e tem influencia sobre a equipe. Desta forma, ele deve ser capas de traduzir toda a documentação gerada pela equipe de TI para a alta gerencia, como também traduzir todos os aspectos do projeto para a equipe de TI.
O controle de projetos é incremental e abre portas para diversas metodologias, por exemplo, o RUP, que atende a projetos com diversas equipes, documentando o papel do individuo dentro de cada equipe, suas atribuições, interações e prazos. Isso traz para o gestor de projetos uma gama muito grande de possibilidades de controle sobre o projeto, suas equipes e prazos. Desta forma aplica-se mais uma vez a formação do gerente de projetos, que deve definir também qual a metodologia a ser utilizada.
Por fim, gerir projetos requer do profissional, mais atribuições do que simplesmente o tempo de empresa, ou o conhecimento específico de uma tecnologia envolvida, a documentação e as interações são parte critica neste processo, e a capacidade de negociar e solucionar problemas é o fator que mais pesa na decisão sobre o gerente de projetos, afinal os prazos são diretamente afetados por estes parâmetros. O orçamento e o ROI justificam o projeto, mas não são garantidos, e as metodologias dependem diretamente da capacidade organizacional do gestor. Função fim do engenheiro de sistemas.
Publicado originalmento no endereço: http://www.profissionaisdetecnologia.com.br
segunda-feira, agosto 28, 2006
Construindo On-line sua Distribuição GNU/Linux customizada
Por José Messias Alves da Silva
Muitos já devem ter se deparado ao instalar várias distribuições GNU/Linux que nem todos os pacotes embutidos na distribuição são utilizados ou são necessários, o que normalmente só acarreta um mau uso do espaço em disco, que fica sendo ocupado por softwares que raramente ou nunca serão utilizados.
Seria muito interessante que pudéssemos escolher os pacotes a serem incluídos em uma distribuição GNU/Linux antes que tivéssemos que baixá-la, o que também economizaria tempo e uso de conexão, adaptando a distribuição às nossas reais necessidades.
Pois bem, isso é exatamente o que faz o site Instalinux, que nos fornece opções para criarmos nossa própria distribuição, selecionando apenas o que realmente precisamos. A princípio, podemos criar um perfil de distribuição selecionando os pacotes a serem inseridos, esquema de particionamento e, por fim, incluir um script final de pós-instalação. Para criar a ISO, decide-se qual a distribuição GNU/Linux será utilizada para a construção e, logo em seguida, mais alguns detalhes de configuração da isso. Ao se concluir a seleção, será disponibilizada para o download um imagem ISO da distribuição escolhida. Pode-se escolher entre as várias distribuições GNU/Linux (Fedora Core, Debian, SuSE e Ubuntu Linux).
Este site apresenta-se bastante interessante para aqueles que possuem link pequeno (como conexão discada) e para os que desejam fazer uma remasterização de sua distribuição GNU/Linux predileta.
Publicado originalmento no endereço: http://www.dicas-l.com.br
Muitos já devem ter se deparado ao instalar várias distribuições GNU/Linux que nem todos os pacotes embutidos na distribuição são utilizados ou são necessários, o que normalmente só acarreta um mau uso do espaço em disco, que fica sendo ocupado por softwares que raramente ou nunca serão utilizados.
Seria muito interessante que pudéssemos escolher os pacotes a serem incluídos em uma distribuição GNU/Linux antes que tivéssemos que baixá-la, o que também economizaria tempo e uso de conexão, adaptando a distribuição às nossas reais necessidades.
Pois bem, isso é exatamente o que faz o site Instalinux, que nos fornece opções para criarmos nossa própria distribuição, selecionando apenas o que realmente precisamos. A princípio, podemos criar um perfil de distribuição selecionando os pacotes a serem inseridos, esquema de particionamento e, por fim, incluir um script final de pós-instalação. Para criar a ISO, decide-se qual a distribuição GNU/Linux será utilizada para a construção e, logo em seguida, mais alguns detalhes de configuração da isso. Ao se concluir a seleção, será disponibilizada para o download um imagem ISO da distribuição escolhida. Pode-se escolher entre as várias distribuições GNU/Linux (Fedora Core, Debian, SuSE e Ubuntu Linux).
Este site apresenta-se bastante interessante para aqueles que possuem link pequeno (como conexão discada) e para os que desejam fazer uma remasterização de sua distribuição GNU/Linux predileta.
Publicado originalmento no endereço: http://www.dicas-l.com.br
quinta-feira, agosto 24, 2006
Wikis podem aposentar conceito de intranet nas empresas
Por Daniela Moreira
Por trás da badalada Wikipedia, enciclopédia livre que conquistou milhões de leitores e ganhou o status de “tão confiável quanto a Britânica”, se esconde uma tecnologia que começa a ganhar adeptos no mundo corporativo: os softwares de wiki. Entre eles, destacam-se pesos-pesados como a IBM, que aposta na ferramenta para facilitar a colaboração a avançar em projetos de uma das suas áreas mais estratégicas: a de inovação.
Para definir o que fazem os wikis, ninguém melhor do que ela, a própria Wikipedia: “software colaborativo que permite a edição coletiva dos documentos usando um singelo sistema e sem que o conteúdo tenha que ser revisto antes da sua publicação”.
O conceito é realmente simples - textos publicados na web que podem ser modificados por qualquer usuário, via browser, sem a necessidade de autorização prévia, aliados a um sistema que registra todas as alterações e as exibe, de forma transparente, tornando a construção do conhecimento muito mais fluída.
As aplicações são as mais diversas. Na web, é possível encontrar desde guias de viagem e sites de notícias até verdadeiros manuais de tecnologia, abordando temas como Mac, Linux e Java, todos construídos colaborativamente. Dentro das empresas, as possibilidades também são infinitas. “É possível desenvolver produtos, elaborar propostas comercias de forma cooperada, criar um wiki que ajude a definir as melhores formas de atender um cliente ou estabelecer políticas de recursos humanos, por exemplo”, explora Sérgio Lozinsky, líder em estratégia corporativa para América Latina da IBM Global Business Services.
Os wikis são um dos elementos da chamada Web 2.0, de forma bastante geral, baseia-se em um novo paradigma de produção de conteúdo, que parte dos usuários para os próprios usuários - sites de compartilhamento de vídeos (como o YouTube), de fotos (Flickr), bookmarks (Del.icio.us), blogs e redes sociais atestam a crescente popularidade do modelo.
No mundo corporativo, a aplicação deste modelo pressupõe não mais uma comunicação hierarquizada, que parte da cúpula para a base, mas uma construção difusa das idéias dentro da empresa. Em outras palavras, sai de cena a intranet e entram os wikis.
No Brasil, este é um modelo ainda não muito difundido entre as empresas. “Sabemos de algumas experiências, mas ainda está muito restrito a empresas da área de Tecnologia da Informação. No futuro, esta tecnologia poderá ser usada por empresas da área farmacêutica, para criar um novo remédio, por exemplo. Pensando além, podem ser criados wikis que extrapolam o ambiente interno e se estendem à cadeia de parceiros das empresas”, especula o executivo da IBM.
O conceito é novo, mas não totalmente inexplorado em terra tupiniquim. O Peabirus, plataforma para criação de redes orgânicas (que, em uma comparação simplista, funcionam como as redes sociais, cujo principal expoente no Brasil é Orkut) que reúnem diferentes elos de cadeias produtivas - empresas, pesquisadores, entidades setoriais, entre outros -, estréia nesta semana um wiki voltado a apresentar os projetos que estão sendo criados e discutidos dentro do ambiente.
“O Wikirus será aberto à visitação pública, mas só poderá ser editado pelos próprios participantes do Peabirus, que hoje são mais de mil, em diferentes cadeias produtivas”, explica Rodrigo Mesquita, diretor da empresa Raduim Systems, criadora da plataforma. “Além disso, teremos o Educarus, que será um wiki voltado, inicialmente, à definição das políticas de conduta dentro do Peabirus”, acrescenta.
Mas como toda boa idéia, o wiki pode se tornar um complicador dentro da empresa, em vez de um facilitador, se não for adotado da forma correta, observando-se alguns cuidados. Lozinsky, que participa de um wiki com mais de mil membros (em apenas dois meses de vida) dá algumas dicas para o sucesso de um wiki corporativo:
1. Massa crítica
Muitos wikis nascem dentro da própria organização, em um pequeno grupo, e vão ganhando a adesão de outros membros da empresa, o que facilita a criação da cultura. Mas quando a empresa opta por criar um wiki, é preciso um esforço para gerar massa crítica - ou seja, fazer com que de fato as pessoas participem da sua elaboração. “Não bastam três pessoas para fazer um wiki, é preciso reunir diversos talentos para que ele faça sentido. Além disso, cada colaborador vai ter que ter algo a doar e algo a receber daquele wiki, senão não voltará lá”, opina o executivo da IBM.
2. Cultura
Tentar impor a criação de wikis dentro de uma companhia vai totalmente de encontro à própria proposta da livre colaboração, portanto, antes de tudo, é preciso observar se a empresa possui uma cultura colaborativa. A solução e pode estar na criação de campanhas incentivo e divulgação para que as pessoas experimentem e, se sentirem à vontade, adotem a prática.
3. Atualização
O wiki é um texto vivo, e para que continue fazendo sentido, tem que estar em constante atualização. “Se você entrar em um wiki de manhã e voltar à noite, sem notar nenhuma diferença, ele está fadado a morrer”, vaticina Lozinsky.
4. Administração
Embora pressuponha a liberdade de intervenção geral e sem hierarquia, todo wiki tem pelo menos um administrador, responsável pela moderação daquele ambiente. Como na Wikipedia, os administradores removem eventuais incorreções e vandalismos. É necessário também que este gestor esteja envolvido com a área de TI, que garantirá a segurança e a infra-estrutura do projeto.
5. Investimento
Uma das vantagens dos projetos de wiki é que eles não exigem um investimento inicial alto. Estão disponíveis para download softwares gratuitos que permitem implementar o sistema sem grandes despesas. Os custos, alerta Lozinsky, poderão vir no futuro, associados à governança destes wikis, caso eles venham a vingar, exigindo recursos humanos responsáveis por questões como ética e segurança, entre outros.
Softwares gratuitos que podem ser usados para criação de wikis:
- MediaWiki
- MoinMoin Wiki Engine
- Twiki
Publicado originalmento no endereço: http://www.idgnow.com.br/
Por trás da badalada Wikipedia, enciclopédia livre que conquistou milhões de leitores e ganhou o status de “tão confiável quanto a Britânica”, se esconde uma tecnologia que começa a ganhar adeptos no mundo corporativo: os softwares de wiki. Entre eles, destacam-se pesos-pesados como a IBM, que aposta na ferramenta para facilitar a colaboração a avançar em projetos de uma das suas áreas mais estratégicas: a de inovação.
Para definir o que fazem os wikis, ninguém melhor do que ela, a própria Wikipedia: “software colaborativo que permite a edição coletiva dos documentos usando um singelo sistema e sem que o conteúdo tenha que ser revisto antes da sua publicação”.
O conceito é realmente simples - textos publicados na web que podem ser modificados por qualquer usuário, via browser, sem a necessidade de autorização prévia, aliados a um sistema que registra todas as alterações e as exibe, de forma transparente, tornando a construção do conhecimento muito mais fluída.
As aplicações são as mais diversas. Na web, é possível encontrar desde guias de viagem e sites de notícias até verdadeiros manuais de tecnologia, abordando temas como Mac, Linux e Java, todos construídos colaborativamente. Dentro das empresas, as possibilidades também são infinitas. “É possível desenvolver produtos, elaborar propostas comercias de forma cooperada, criar um wiki que ajude a definir as melhores formas de atender um cliente ou estabelecer políticas de recursos humanos, por exemplo”, explora Sérgio Lozinsky, líder em estratégia corporativa para América Latina da IBM Global Business Services.
Os wikis são um dos elementos da chamada Web 2.0, de forma bastante geral, baseia-se em um novo paradigma de produção de conteúdo, que parte dos usuários para os próprios usuários - sites de compartilhamento de vídeos (como o YouTube), de fotos (Flickr), bookmarks (Del.icio.us), blogs e redes sociais atestam a crescente popularidade do modelo.
No mundo corporativo, a aplicação deste modelo pressupõe não mais uma comunicação hierarquizada, que parte da cúpula para a base, mas uma construção difusa das idéias dentro da empresa. Em outras palavras, sai de cena a intranet e entram os wikis.
No Brasil, este é um modelo ainda não muito difundido entre as empresas. “Sabemos de algumas experiências, mas ainda está muito restrito a empresas da área de Tecnologia da Informação. No futuro, esta tecnologia poderá ser usada por empresas da área farmacêutica, para criar um novo remédio, por exemplo. Pensando além, podem ser criados wikis que extrapolam o ambiente interno e se estendem à cadeia de parceiros das empresas”, especula o executivo da IBM.
O conceito é novo, mas não totalmente inexplorado em terra tupiniquim. O Peabirus, plataforma para criação de redes orgânicas (que, em uma comparação simplista, funcionam como as redes sociais, cujo principal expoente no Brasil é Orkut) que reúnem diferentes elos de cadeias produtivas - empresas, pesquisadores, entidades setoriais, entre outros -, estréia nesta semana um wiki voltado a apresentar os projetos que estão sendo criados e discutidos dentro do ambiente.
“O Wikirus será aberto à visitação pública, mas só poderá ser editado pelos próprios participantes do Peabirus, que hoje são mais de mil, em diferentes cadeias produtivas”, explica Rodrigo Mesquita, diretor da empresa Raduim Systems, criadora da plataforma. “Além disso, teremos o Educarus, que será um wiki voltado, inicialmente, à definição das políticas de conduta dentro do Peabirus”, acrescenta.
Mas como toda boa idéia, o wiki pode se tornar um complicador dentro da empresa, em vez de um facilitador, se não for adotado da forma correta, observando-se alguns cuidados. Lozinsky, que participa de um wiki com mais de mil membros (em apenas dois meses de vida) dá algumas dicas para o sucesso de um wiki corporativo:
1. Massa crítica
Muitos wikis nascem dentro da própria organização, em um pequeno grupo, e vão ganhando a adesão de outros membros da empresa, o que facilita a criação da cultura. Mas quando a empresa opta por criar um wiki, é preciso um esforço para gerar massa crítica - ou seja, fazer com que de fato as pessoas participem da sua elaboração. “Não bastam três pessoas para fazer um wiki, é preciso reunir diversos talentos para que ele faça sentido. Além disso, cada colaborador vai ter que ter algo a doar e algo a receber daquele wiki, senão não voltará lá”, opina o executivo da IBM.
2. Cultura
Tentar impor a criação de wikis dentro de uma companhia vai totalmente de encontro à própria proposta da livre colaboração, portanto, antes de tudo, é preciso observar se a empresa possui uma cultura colaborativa. A solução e pode estar na criação de campanhas incentivo e divulgação para que as pessoas experimentem e, se sentirem à vontade, adotem a prática.
3. Atualização
O wiki é um texto vivo, e para que continue fazendo sentido, tem que estar em constante atualização. “Se você entrar em um wiki de manhã e voltar à noite, sem notar nenhuma diferença, ele está fadado a morrer”, vaticina Lozinsky.
4. Administração
Embora pressuponha a liberdade de intervenção geral e sem hierarquia, todo wiki tem pelo menos um administrador, responsável pela moderação daquele ambiente. Como na Wikipedia, os administradores removem eventuais incorreções e vandalismos. É necessário também que este gestor esteja envolvido com a área de TI, que garantirá a segurança e a infra-estrutura do projeto.
5. Investimento
Uma das vantagens dos projetos de wiki é que eles não exigem um investimento inicial alto. Estão disponíveis para download softwares gratuitos que permitem implementar o sistema sem grandes despesas. Os custos, alerta Lozinsky, poderão vir no futuro, associados à governança destes wikis, caso eles venham a vingar, exigindo recursos humanos responsáveis por questões como ética e segurança, entre outros.
Softwares gratuitos que podem ser usados para criação de wikis:
- MediaWiki
- MoinMoin Wiki Engine
- Twiki
Publicado originalmento no endereço: http://www.idgnow.com.br/
quarta-feira, agosto 23, 2006
Quais são as 10 tecnologias para 2007?
Por Redação do Computerworld
Na abertura da XI Conferência Anual do Gartner, que aconteceu nesta terça-feira (22/08), o vice-presidente de pesquisa da consultoria, Carl Claunch, destacou os sistemas que estarão em 2007, como o EMI (Enterprise Information Management) e o aumento do esclarecimento em relação ao grid computing (portais, sistemas de mensagens instantâneas), assim como virtualização.
O analista acredita que a inovação da TI se manterá no atual ambiente econômico e que haverá ainda uma redução de produtividade em relação ao open-source, apesar de a tecnologia aparecer na lista de destaques para o próximo ano. Em evidência , portanto, estão virtualização, grid computing, service-oriented architecture (SOA) e open source, somados a outras tendências de longo prazo, como o AJAX.
“Hoje as empresas estão mais familiarizadas com grandes servidores divididos em vários outros. O que perceberemos é a integração e virtualização dessas estruturas físicas, o que facilitará o trabalho dos operadores e usuários”, destacou.
Entre os produtos com mais maturidade, o analista ressalta os de desenvolvimento, operação de sistemas e segurança. Com menos amadurecimento, estão aplicações corporativas, de fluxo de trabalho, integração de serviços e virtualização.
Em relação às tecnologias de internet, as principais, de acordo com Claunch, serão as que possuem princípios de links globalizados, descentralização e extensão. “O Google está bem porque é eficiente na coleta de idéias. Ele é capaz de identificar o quanto importante um site é”, afirma.
As 10 tecnologias destaques em 2007 para o Gartner.
1. Virtualização
2. Grid Computing
3. Service-Oriented Architecture (SOA)
4. Enterprise Information Management (EIM)
5. Open Source
6. Acesso à informação
7. Ajax
8. Mashup Composite Model
9. Computação Persuasiva (do ingles, Pervasive Computing)
10. Coleta inteligente de dados.
Publicado originalmento no endereço: http://www.idgnow.com.br/
Na abertura da XI Conferência Anual do Gartner, que aconteceu nesta terça-feira (22/08), o vice-presidente de pesquisa da consultoria, Carl Claunch, destacou os sistemas que estarão em 2007, como o EMI (Enterprise Information Management) e o aumento do esclarecimento em relação ao grid computing (portais, sistemas de mensagens instantâneas), assim como virtualização.
O analista acredita que a inovação da TI se manterá no atual ambiente econômico e que haverá ainda uma redução de produtividade em relação ao open-source, apesar de a tecnologia aparecer na lista de destaques para o próximo ano. Em evidência , portanto, estão virtualização, grid computing, service-oriented architecture (SOA) e open source, somados a outras tendências de longo prazo, como o AJAX.
“Hoje as empresas estão mais familiarizadas com grandes servidores divididos em vários outros. O que perceberemos é a integração e virtualização dessas estruturas físicas, o que facilitará o trabalho dos operadores e usuários”, destacou.
Entre os produtos com mais maturidade, o analista ressalta os de desenvolvimento, operação de sistemas e segurança. Com menos amadurecimento, estão aplicações corporativas, de fluxo de trabalho, integração de serviços e virtualização.
Em relação às tecnologias de internet, as principais, de acordo com Claunch, serão as que possuem princípios de links globalizados, descentralização e extensão. “O Google está bem porque é eficiente na coleta de idéias. Ele é capaz de identificar o quanto importante um site é”, afirma.
As 10 tecnologias destaques em 2007 para o Gartner.
1. Virtualização
2. Grid Computing
3. Service-Oriented Architecture (SOA)
4. Enterprise Information Management (EIM)
5. Open Source
6. Acesso à informação
7. Ajax
8. Mashup Composite Model
9. Computação Persuasiva (do ingles, Pervasive Computing)
10. Coleta inteligente de dados.
Publicado originalmento no endereço: http://www.idgnow.com.br/
segunda-feira, agosto 21, 2006
Quem paga a conta do software livre?
Por Ricardo Bánffy
Outro dia, em uma palestra na Assembléia Legislativa sobre o uso de software livre na administração pública, eu ouvi, pela ducentésima vez, alguém perguntar de onde, afinal, vem o dinheiro para custear o desenvolvimento de tantos programas. Não fiquei surpreso por ouvir a pergunta. Mas fiquei muito surpreso que as primeiras respostas não dessem conta de alguns fatos importantes. Me senti compelido a pedir o microfone à mesa e colocar, eu mesmo, por terra os temores do meu colega.
Esta é uma das perguntas clássicas que pessoas inocentes ou mal-intencionadas adoram fazer. Eu prefiro acreditar que este rapaz (devia ter mais ou menos a minha idade, logo, vou chamá-lo de rapaz) era do primeiro grupo, embora ele estivesse cercado de pessoas que faziam, evidentemente, parte do segundo.
Uma noção errada que muita gente ainda tem é de que software livre é feito nas horas vagas de profissionais que, depois de voltar pra casa do trabalho, fazer jantar, levar o cachorro passear e colocar os filhos para dormir, ainda encontra tempo para escrever software.
Bom... Não quero desmerecer estes heróis, mas eles não estão sozinhos.
Muita gente escreve software livre das 9 às 6. Alguns, inclusive, usam gravata.
Mas que coisa feia... Essas pessoas, sendo pagas por seus empregadores, ficam brincando de fazer software que depois vão dar pros outros?
Não é bem isso.
Para responder esta pergunta, eu vou citar alguns exemplos.
O Produto que Quase Servia
Algum tempo atrás, trabalhando na empresa de um amigo, havia um cliente que tinha a necessidade de autenticar os usuários da sua intranet contra um domínio em um servidor Windows NT. É uma necessidade comum. O cliente, um banco internacional, tinha optado por construir sua intranet com um servidor de aplicações chamado Zope (do qual eu gosto bastante, como evidencia o "powered by" que permeia meu site). Localizamos um componente para o Zope que permitiria fazer exatamente isto (e mais um monte de outros truques que não vêm ao caso agora). Mas havia um problema: No primeiro teste na rede do banco, o componente não funcionou. Examinando o código-fonte dele, descobrimos que ele não funcionaria por motivos relacionados à arquitetura da própria rede do banco (e que não seria, de forma alguma, modificada). Conversamos e decidimos que o caminho mais fácil seria arrumá-lo. Algumas horas depois, conversando com o "dono" do projeto via IRC (ele vive na Austrália), dois de nós se tornaram colaboradores "oficiais" (nossos nomes estão na página do produto). Poucos dias depois, não só o problema da autenticação estava resolvido, como o produto tinha tido melhoras muito expressivas em seu desempenho com a implementação de várias otimizações. E nós nem mesmo precisamos desvendar os becos escuros do Windows por onde é feita a autenticação.
Resumindo: Melhorar um produto de terceiros tornou possível entregar, rapidamente, uma solução que atendia as necessidades do cliente. Como um efeito colateral, outras empresas que criam soluções baseadas em Zope têm uma opção melhor para integrar suas aplicações às redes Windows dos seus clientes. Se ninguém tivesse precisado da funcionalidade, ela não teria sido implementada ou permaneceria minimamente funcional, exatamente como a encontramos. A necessidade, e não as forças do mercado, guiam a evolução do software livre.
Os outros exemplos não são em primeira mão, mas ilustram outras formas de se usar software livre.
Tenho Caixas pra Vender
Lá por 2000, a IBM tomou conhecimento de três coisas. Primeiro: ela não tinha uma solução UNIX muito boa em termos de preço/performance. Isso estava fazendo com que seus concorrentes, entre eles a Sun, levassem seus clientes embora. Segundo: Eles tinham servidores baratos, poderosos, baseados em hardware Intel, que poderiam reverter isso, se, ao menos, a IBM tivesse um sistema operacional UNIX-like para colocar neles. Terceiro: Eles dependiam da Microsoft para fornecer o único sistema operacional disponível para toda a linha de servidores Intel. Isto é, eles dependiam da mesma empresa que era parceira no desenvolvimento do OS/2 e que lançou um produto, o Windows 3, para concorrer justamente com o OS/2. Que Deus o tenha.
Nas palavras da IBM (eu uma vez conversei com um VIP responsável pelos esforços de Linux da IBM - ainda estou procurando o cartão dele), em 2000, o Linux não estava bom o bastante para aplicações críticas. Foi quando eles decidiram que, em vez de portar novamente o AIX para Intel (existiu uma versão dele que rodava nos PS/2 mais parrudos), eles investiriam recursos para tornar o Linux "enterprise-ready". Trocando em miúdos, a IBM achou que o mercado de sistemas operacionais proprietários para PCs estava morto (a Microsoft consome todos os recursos desse "ecossistema") e que não valeria a pena investir num AIX/x86 quando, por menos dinheiro, eles poderiam ajudar a deixar o Linux capaz de atender às demandas dos clientes.
Brigas judiciais à parte (a SCO, ex-Caldera, acha que a IBM roubou código e usou "métodos proprietários" dela para colocar no Linux), a IBM fez várias contribuições de código para o kernel e drivers do Linux em áreas importantes como escrita em discos e suporte a multi-processamento com acesso não-uniforme à memória (que tinha sido desenvolvido por uma empresa que a IBM comprou, a Sequent, especializada em computadores com dúzias de processadores). Também fez e bancou vários estudos sobre como o uso de servidores Intel rodando Linux é economicamente vantajoso em relação ao emprego de máquinas RISC rodando versões proprietárias de UNIX (inclusive os pSeries da própria IBM). Debaixo da mesma bandeira, favoreceu o desenvolvimento de versões do Linux para seus mainframes.
Resumindo: Ao investir (junto com outras empresas) no desenvolvimento do Linux, a IBM conseguiu várias vitórias importantes. Ela agora tem uma linha de servidores Linux de baixo custo competindo com enormes vantagens com soluções RISC dos seus concorrentes e mesmo com servidores baseados em Windows. A IBM é o único produtor de mainframes reportando crescimento das vendas no segmento, com empresas consolidando dezenas de servidores menores em um único equipamento. Como um efeito colateral disso, o kernel do Linux deu um salto impressionante de qualidade. Onde, anos atrás, eu teria que instalar um Windows, eu hoje posso usar um sistema operacional moderno e modular, que usa um kernel firme como uma rocha (minha máquina de desenvolvimento detém o meu recorde doméstico de 61 dias sem um boot - quebrado não por um crash, mas por uma falta de energia), com discos que não perdem dados quando a energia falha (graças ao journal), com excelente suporte a máquinas com mais de um processador (que, infelizmente, não é meu caso) e que não serve como meio de cultura para pragas digitais como o Blaster ou Slammer. E ela ainda encontra tempo para registrar pelo menos umas 30 tentativas de contágio por worms a cada dia.
Uma Caixa Nova
Na mesma linha de raciocínio, Intel e HP perceberam que lançar o processador Itanium no mercado sem um suporte expressivo de software aplicativo seria suicídio. Em vez de pedir gentilmente à Microsoft (na verdade, eles gastaram bastante dinheiro mandando programadores deles para ficarem dentro da Microsoft ajudando no trabalho) que portasse o Windows para o Itanium (lição de história: a falta de aplicativos e de suporte do Windows foi o último prego no caixão dos processadores MIPS, PowerPC (em PC-likes) e Alpha) e rezar para que ele estivesse pronto ao mesmo tempo em que o processador fosse lançado, a HP decidiu apostar em mais 2 cavalos extras. Um deles, o port do HP/UX (o UNIX proprietário da HP) para o Itanium e, em outra, no port do Linux para o processador. Com um processador de 64 bits no mercado há algum tempo, a HP hoje pode vender suas soluções com uma escolha maior de sistemas operacionais em vários mercados que não estariam acessíveis não fosse essa decisão. Hoje a HP vende os equipamentos HP/UX sobre Itanium aos seus clientes HP/UX tradicionais, vende máquinas Itanium rodando Windows para seus clientes Windows e vende máquinas Itanium rodando Linux para os clientes que preferem Linux. E, claro, vendem máquinas Intel também.
Publicado originalmento no endereço: http://www.linhadecodigo.com.br
Outro dia, em uma palestra na Assembléia Legislativa sobre o uso de software livre na administração pública, eu ouvi, pela ducentésima vez, alguém perguntar de onde, afinal, vem o dinheiro para custear o desenvolvimento de tantos programas. Não fiquei surpreso por ouvir a pergunta. Mas fiquei muito surpreso que as primeiras respostas não dessem conta de alguns fatos importantes. Me senti compelido a pedir o microfone à mesa e colocar, eu mesmo, por terra os temores do meu colega.
Esta é uma das perguntas clássicas que pessoas inocentes ou mal-intencionadas adoram fazer. Eu prefiro acreditar que este rapaz (devia ter mais ou menos a minha idade, logo, vou chamá-lo de rapaz) era do primeiro grupo, embora ele estivesse cercado de pessoas que faziam, evidentemente, parte do segundo.
Uma noção errada que muita gente ainda tem é de que software livre é feito nas horas vagas de profissionais que, depois de voltar pra casa do trabalho, fazer jantar, levar o cachorro passear e colocar os filhos para dormir, ainda encontra tempo para escrever software.
Bom... Não quero desmerecer estes heróis, mas eles não estão sozinhos.
Muita gente escreve software livre das 9 às 6. Alguns, inclusive, usam gravata.
Mas que coisa feia... Essas pessoas, sendo pagas por seus empregadores, ficam brincando de fazer software que depois vão dar pros outros?
Não é bem isso.
Para responder esta pergunta, eu vou citar alguns exemplos.
O Produto que Quase Servia
Algum tempo atrás, trabalhando na empresa de um amigo, havia um cliente que tinha a necessidade de autenticar os usuários da sua intranet contra um domínio em um servidor Windows NT. É uma necessidade comum. O cliente, um banco internacional, tinha optado por construir sua intranet com um servidor de aplicações chamado Zope (do qual eu gosto bastante, como evidencia o "powered by" que permeia meu site). Localizamos um componente para o Zope que permitiria fazer exatamente isto (e mais um monte de outros truques que não vêm ao caso agora). Mas havia um problema: No primeiro teste na rede do banco, o componente não funcionou. Examinando o código-fonte dele, descobrimos que ele não funcionaria por motivos relacionados à arquitetura da própria rede do banco (e que não seria, de forma alguma, modificada). Conversamos e decidimos que o caminho mais fácil seria arrumá-lo. Algumas horas depois, conversando com o "dono" do projeto via IRC (ele vive na Austrália), dois de nós se tornaram colaboradores "oficiais" (nossos nomes estão na página do produto). Poucos dias depois, não só o problema da autenticação estava resolvido, como o produto tinha tido melhoras muito expressivas em seu desempenho com a implementação de várias otimizações. E nós nem mesmo precisamos desvendar os becos escuros do Windows por onde é feita a autenticação.
Resumindo: Melhorar um produto de terceiros tornou possível entregar, rapidamente, uma solução que atendia as necessidades do cliente. Como um efeito colateral, outras empresas que criam soluções baseadas em Zope têm uma opção melhor para integrar suas aplicações às redes Windows dos seus clientes. Se ninguém tivesse precisado da funcionalidade, ela não teria sido implementada ou permaneceria minimamente funcional, exatamente como a encontramos. A necessidade, e não as forças do mercado, guiam a evolução do software livre.
Os outros exemplos não são em primeira mão, mas ilustram outras formas de se usar software livre.
Tenho Caixas pra Vender
Lá por 2000, a IBM tomou conhecimento de três coisas. Primeiro: ela não tinha uma solução UNIX muito boa em termos de preço/performance. Isso estava fazendo com que seus concorrentes, entre eles a Sun, levassem seus clientes embora. Segundo: Eles tinham servidores baratos, poderosos, baseados em hardware Intel, que poderiam reverter isso, se, ao menos, a IBM tivesse um sistema operacional UNIX-like para colocar neles. Terceiro: Eles dependiam da Microsoft para fornecer o único sistema operacional disponível para toda a linha de servidores Intel. Isto é, eles dependiam da mesma empresa que era parceira no desenvolvimento do OS/2 e que lançou um produto, o Windows 3, para concorrer justamente com o OS/2. Que Deus o tenha.
Nas palavras da IBM (eu uma vez conversei com um VIP responsável pelos esforços de Linux da IBM - ainda estou procurando o cartão dele), em 2000, o Linux não estava bom o bastante para aplicações críticas. Foi quando eles decidiram que, em vez de portar novamente o AIX para Intel (existiu uma versão dele que rodava nos PS/2 mais parrudos), eles investiriam recursos para tornar o Linux "enterprise-ready". Trocando em miúdos, a IBM achou que o mercado de sistemas operacionais proprietários para PCs estava morto (a Microsoft consome todos os recursos desse "ecossistema") e que não valeria a pena investir num AIX/x86 quando, por menos dinheiro, eles poderiam ajudar a deixar o Linux capaz de atender às demandas dos clientes.
Brigas judiciais à parte (a SCO, ex-Caldera, acha que a IBM roubou código e usou "métodos proprietários" dela para colocar no Linux), a IBM fez várias contribuições de código para o kernel e drivers do Linux em áreas importantes como escrita em discos e suporte a multi-processamento com acesso não-uniforme à memória (que tinha sido desenvolvido por uma empresa que a IBM comprou, a Sequent, especializada em computadores com dúzias de processadores). Também fez e bancou vários estudos sobre como o uso de servidores Intel rodando Linux é economicamente vantajoso em relação ao emprego de máquinas RISC rodando versões proprietárias de UNIX (inclusive os pSeries da própria IBM). Debaixo da mesma bandeira, favoreceu o desenvolvimento de versões do Linux para seus mainframes.
Resumindo: Ao investir (junto com outras empresas) no desenvolvimento do Linux, a IBM conseguiu várias vitórias importantes. Ela agora tem uma linha de servidores Linux de baixo custo competindo com enormes vantagens com soluções RISC dos seus concorrentes e mesmo com servidores baseados em Windows. A IBM é o único produtor de mainframes reportando crescimento das vendas no segmento, com empresas consolidando dezenas de servidores menores em um único equipamento. Como um efeito colateral disso, o kernel do Linux deu um salto impressionante de qualidade. Onde, anos atrás, eu teria que instalar um Windows, eu hoje posso usar um sistema operacional moderno e modular, que usa um kernel firme como uma rocha (minha máquina de desenvolvimento detém o meu recorde doméstico de 61 dias sem um boot - quebrado não por um crash, mas por uma falta de energia), com discos que não perdem dados quando a energia falha (graças ao journal), com excelente suporte a máquinas com mais de um processador (que, infelizmente, não é meu caso) e que não serve como meio de cultura para pragas digitais como o Blaster ou Slammer. E ela ainda encontra tempo para registrar pelo menos umas 30 tentativas de contágio por worms a cada dia.
Uma Caixa Nova
Na mesma linha de raciocínio, Intel e HP perceberam que lançar o processador Itanium no mercado sem um suporte expressivo de software aplicativo seria suicídio. Em vez de pedir gentilmente à Microsoft (na verdade, eles gastaram bastante dinheiro mandando programadores deles para ficarem dentro da Microsoft ajudando no trabalho) que portasse o Windows para o Itanium (lição de história: a falta de aplicativos e de suporte do Windows foi o último prego no caixão dos processadores MIPS, PowerPC (em PC-likes) e Alpha) e rezar para que ele estivesse pronto ao mesmo tempo em que o processador fosse lançado, a HP decidiu apostar em mais 2 cavalos extras. Um deles, o port do HP/UX (o UNIX proprietário da HP) para o Itanium e, em outra, no port do Linux para o processador. Com um processador de 64 bits no mercado há algum tempo, a HP hoje pode vender suas soluções com uma escolha maior de sistemas operacionais em vários mercados que não estariam acessíveis não fosse essa decisão. Hoje a HP vende os equipamentos HP/UX sobre Itanium aos seus clientes HP/UX tradicionais, vende máquinas Itanium rodando Windows para seus clientes Windows e vende máquinas Itanium rodando Linux para os clientes que preferem Linux. E, claro, vendem máquinas Intel também.
Publicado originalmento no endereço: http://www.linhadecodigo.com.br
domingo, agosto 20, 2006
Saiba como manter os bons profissionais em seu time.
Por Danielle Sarraf.
Especialmente em economias aquecidas, as pessoas mais competentes são assediadas para trocar de emprego, e as empresas sabem que os melhores saem primeiro. No Brasil, a movimentação de executivos está em alta e a empregabilidade para os bons profissionais, também.
Existem importantes ferramentas para melhorar a retenção de funcionários. Algumas são bastante óbvias, como, por exemplo, melhorar tanto o clima como a comunicação dentro da empresa, em todos os níveis. Ressalte-se que o estilo gerencial deve ser sério, porém muito democrático, pois empresas punitivas ou deprimidas perdem seus melhores talentos.
Também são necessários os planos de carreira, pois os profissionais de hoje querem saber para onde aponta seu futuro, e desejam participar ativamente do aprimoramento de suas competências, que deverão ser desenvolvidas para conquistar uma promoção ou a transferência cobiçada.
Uma atividade em alta para executivos é o coaching, através da qual a própria empresa contrata um tipo de “personal trainer” profissional. Ele participa de reuniões periódicas com profissional, buscando ajudá-lo a melhorar seu relacionamento com outros funcionários, aprimorar comportamentos e, assim, impactar positivamente no seu desempenho, evitando desgastes e colaborando, para que permaneça na empresa.
Outro importante fator de retenção relaciona-se diretamente à remuneração. As companhias competitivas devem pagar salários e benefícios alinhados ao mercado, às vezes até oferecendo recompensas a longo prazo - as chamadas “algemas de ouro”.
Exemplos de recompensas são os stock options - opções para adquirir ações da empresa, a preços favoráveis, em datas futuras - ou a possibilidade de participar num IPO (Initial Public Offering), que consiste na opção de adquirir novas ações no momento da primeira abertura do capital em bolsa, permitindo a compra a preços da abertura, normalmente seguida de enorme revalorização das ações. É uma maneira de acumular patrimônio entre os funcionários, de todos os níveis.
As empresas sabem que o seu verdadeiro patrimônio da empresa sai pela porta do escritório todas as noites, para retornar no dia seguinte. Só que alguns, às vezes, não voltam. A organização que somente se preocupa em contratar, treinar, chefiar, remunerar e demitir, acaba perdendo de vista a mais importante da atividade relacionada com o capital humano: a retenção dos melhores talentos.
Danielle Sarraf é advogada formada pela PUC/SP com MBA pela Fundação Dom Cabral. Trabalhou com consultoria tributária e societária durante alguns anos de sua carreira, até que virou headhunter, sua ocupação atual. Na coluna Headhunter, a consultora fala de temas relacionados ao comportamento profissional e oportunidades de desenvolvimento de carreira. E-mail:
daniellesarraf@hotmail.com .
Publicado originalmente no endereço http://www.idgnow.com.br
Assinar:
Postagens (Atom)
