É fácil saber que o cliente está satisfeito ou insatisfeito, mas será que você sabe separar o satisfeito do contente?
Um cliente insatisfeito é aquele que sempre critica o fornecedor, coloca defeito em tudo e diz que se pudesse voltar atrás, nunca escolheria o dito fornecedor. O satisfeito é aquele que fala bem, que indica o fornecedor para outras pessoas e que sempre fala bem do serviço prestado.
Bom, mas se o satisfeito só fala bem, qual é a do contente?
Vou citar um exemplo simples e bobo, mas sempre ocorrem essas situações nas empresas e nos projetos.
Imgine-se agora, do lado do cliente: você precisa produzir um evento, uma inauguração de uma sede nova por exemplo, e precisa contratar um buffet. Você repassa ao buffet que deseja 4 tipos de queijos e 5 tipos diferentes de salgados e 3 tipos de bebidas. Muito simples, claro, momento de crise queremos economizar.
Agora, vejamos os 3 cenários:
Cenário A: o fornecedor não possui os 4 tipos de queijo requisitados pelo cliente, contudo, sem consultar o cliente, substitui um dos tipos de queijo por um sexto tipo de salgado. Em contrapartida, adiciona mais um tipo de bebida e tudo dentro dos padrões de qualidade solicitadas pelo cliente.
Cenário B: o fornecedor atende os requisitos do cliente, mas pra fazer um agrado para o cliente, por ser a primeira vez que esse cliente o contrata, resolve adicionar mais um tipo de salgado e também, tudo dentro da qualidade espearada.
Cenário C: o fornecedor atende os requisitos do cliente, dentro da qualidade esperada e nada mais.
O fornecedor do cenário A errou. O cliente ficará insatisfeito, pois pediu 4 tipos de queijo e não 3, a substituição não resolve, não atende o que o cliente desejava, ou seja, cliente insatisfeito. Lição aprendida 1: nunca faça nada diferente do que o cliente quer sem antes consultá-lo, ele não olhará o que você fez a mais e sim o que você deixou de fazer.
O fornecedor do cenário B errou também. O cliente ficará satisfeito, e mais que isso, ficará CONTENTE, já que o fornecedor o atendeu e ainda deu um "plus" sem cobrar nada a mais por isso. Da próxima vez que você contratar esse fornecedor, irá querer o "plus" sem cobrança adicional e se o fornecedor cobrar, você ficará insatisfeito com ele, se perguntando "antes ele fez, agora tá com mesquinharia". Se põe no lugar do cliente, é o não é? Lição aprendida 2: nunca dê o "banho de ouro" a não ser que seja extremamente estratégico, pois o que o cliente quer é que os requesitos sejam entregues conforme solicitado.
O fornecedor do cenário C acertou. O cliente ficará satisfeito (mas não contente) pois o serviço foi feito conforme combinado e os requisitos atendidos conforme o esperado. Lição aprendida 3: faça somente o que for requisitado, assim, você não perderá dinheiro e seu cliente ficará satisfeito da mesma forma.
Em resumo, cliente insatisfeito nunca devemos ter, precisamos entender e atender as necessidades de nossos clientes. Cliente contentes, a vezes ou nunca, pois assim, atendemos o que nosso cliente deseja, mas perdemos dinheiro pois entregamos coisas a mais, que custam dinheiro e muitas vezes o cliente não irá dar valor nisso no futuro. Clientes satisfeitos, sempre, pois assim atendemos o que nosso cliente deseja, recebemos o justo pelo trabalho e todos saem ganhando.
Até a próxima.
30 de novembro de 2009
26 de novembro de 2009
Cursos online gratuitos
Lendo algumas reportagens essa semana, li sobre educação on-line gratuita e achei um curso (vários aliás) que valem a pena.
A FGV disponibilizou vários cursos on-line gratuitamente para que quer se atualizar em alguns assuntos específicos.
São vários mini-cursos, como Balanced Scorecard, Gestão de Custos, Gestão de Marketing e outros em diversas áreas de atuação.
Pena que a conclusão do curso não dá direito a um certificado, apenas um "atestado" de participação, mas vale a pena investir um pouco do tempo para melhorar seu conhecimento
Acesso o site: www5.fgv.br/fgvonline/CursosGratuitos.aspx e veja se tem algo que lhe interesse.
Até mais.
A FGV disponibilizou vários cursos on-line gratuitamente para que quer se atualizar em alguns assuntos específicos.
São vários mini-cursos, como Balanced Scorecard, Gestão de Custos, Gestão de Marketing e outros em diversas áreas de atuação.
Pena que a conclusão do curso não dá direito a um certificado, apenas um "atestado" de participação, mas vale a pena investir um pouco do tempo para melhorar seu conhecimento
Acesso o site: www5.fgv.br/fgvonline/CursosGratuitos.aspx e veja se tem algo que lhe interesse.
Até mais.
4 de novembro de 2009
Gerente, você tem autonomia?
A pergunta acima deveria ter uma resposta simples e objetiva: Sim. Mas não é bem isso que acontece.
As empresas nomeiam seus gerente com o simples objetivo de promover um "velho de casa", um funcionário, muito bom na sua função, mas que precisa de uma promoção para que não acabe saindo da empresa. Uma forma errada de se nomear um gerente, pois você perde um excelente funcionário e ganha um péssimo gerente.
Em projetos acontece o mesmo, você pega um excelente analista de sistema ou até mesmo um programador e o nomeia para ser um gerente de projetos. Primeiro projeto dele, adivinha? Prazos estourados, escopo não existe mais, custo foi para o espaço e a comunicação do projeto nem se fala... pois ninguém sabe de nada do que se passa no projeto, pois o técnico decidiu fazer as coisas por conta própria, ao passo que não sabia nem o que podia fazer e por isso travou tudo no projeto.
O fato é que o gerente de projetos primeiro tem que ter conhecimento do que está fazendo e não é pra conhecer da área especifica do projeto e sim de gerencia de projetos (você pode não conhecer nada de construção civil, mas pode gerenciar o projeto de construção de um prédio gisgantesco se conhecer as técnicas de gerenciamento de projetos). Segundo, precisa de autonomia para exercer a função, como negociar prazos, custos, escopo e qualidade, sem tem que ficar recorrendo a todo instante ao "dono da empresa" pois não tem poder para tomar decisões referente ao projeto.
O mais engraçado de tudo isso, é que o GP é sempre cobrado por resultados, buscar a satisfação do cliente, garantir que o projeto aconteça dentro do prazo, custo e escopo contratado. Cobrado é, mas em vários lugares, não tem autonomia para buscar otimização do custo, negociar prazos, negociar custos, negociar qualidade da entrega, buscando garantia a satisfação do cliente, sem onerar o custo do projeto e garantindo escopo contrato pelo cliente.
Um GP sem automomia, é semelhante a um gerente de lojas de roupas que não pode dar desconto em um produto pois não é autorizado pelo dono.... é ridículo, mas isso acontece ainda nos dias de hoje.
O gerente precisa de limites até aonde pode negociar, mas não pode ser privado de algumas liberdades e alçadas para negociar.
Gerentes, negociem a sua autonomia, definam o que podem fazer e o que não podem, estabeleça seus limites antes de assumir um projeto ou posição de gerencia e usem com sabedoria a autonomia concedida.
Até a próxima e muito sucesso a todos.
As empresas nomeiam seus gerente com o simples objetivo de promover um "velho de casa", um funcionário, muito bom na sua função, mas que precisa de uma promoção para que não acabe saindo da empresa. Uma forma errada de se nomear um gerente, pois você perde um excelente funcionário e ganha um péssimo gerente.
Em projetos acontece o mesmo, você pega um excelente analista de sistema ou até mesmo um programador e o nomeia para ser um gerente de projetos. Primeiro projeto dele, adivinha? Prazos estourados, escopo não existe mais, custo foi para o espaço e a comunicação do projeto nem se fala... pois ninguém sabe de nada do que se passa no projeto, pois o técnico decidiu fazer as coisas por conta própria, ao passo que não sabia nem o que podia fazer e por isso travou tudo no projeto.
O fato é que o gerente de projetos primeiro tem que ter conhecimento do que está fazendo e não é pra conhecer da área especifica do projeto e sim de gerencia de projetos (você pode não conhecer nada de construção civil, mas pode gerenciar o projeto de construção de um prédio gisgantesco se conhecer as técnicas de gerenciamento de projetos). Segundo, precisa de autonomia para exercer a função, como negociar prazos, custos, escopo e qualidade, sem tem que ficar recorrendo a todo instante ao "dono da empresa" pois não tem poder para tomar decisões referente ao projeto.
O mais engraçado de tudo isso, é que o GP é sempre cobrado por resultados, buscar a satisfação do cliente, garantir que o projeto aconteça dentro do prazo, custo e escopo contratado. Cobrado é, mas em vários lugares, não tem autonomia para buscar otimização do custo, negociar prazos, negociar custos, negociar qualidade da entrega, buscando garantia a satisfação do cliente, sem onerar o custo do projeto e garantindo escopo contrato pelo cliente.
Um GP sem automomia, é semelhante a um gerente de lojas de roupas que não pode dar desconto em um produto pois não é autorizado pelo dono.... é ridículo, mas isso acontece ainda nos dias de hoje.
O gerente precisa de limites até aonde pode negociar, mas não pode ser privado de algumas liberdades e alçadas para negociar.
Gerentes, negociem a sua autonomia, definam o que podem fazer e o que não podem, estabeleça seus limites antes de assumir um projeto ou posição de gerencia e usem com sabedoria a autonomia concedida.
Até a próxima e muito sucesso a todos.
30 de setembro de 2009
Grupo do 5%
Hoje li um texto em um blog que achei interessante e expressa uma realidade em nossas vidas. Esse texto fala sobre a existência de um grupo de 5% das pessoas que realmente fazem a diferença. De cada 100 pessoas, somente 5 fazem algo diferente e se destaca das outras 95, que só servem para fazer volume.
Vejo que em todos os lugares isso é uma realidade. Somente um pequeno grupo se destaca, aparece e é realmente bom no que faz. E o resto? O resto faz volume.
Peguemos por exemplo uma empresa de desenvolvimento de software, quantos programadores são realmente bons? Quantos analistas de sistemas, engenheiros de software fazem realmente um bom trabalho e são competentes?
Parei, pensei e vi que nas empresas que passei, não passa de 5%. Nos clientes que passei, poucos são as pessoas que fazem a diferença.
Quantas vezes você procurou um serviço diferenciado na sua cidade e quantas empresas você encontrou? 5%? Faça as contas, você verá que não passa disso.
E então? Você faz parte desse grupo seleto de 5% que faz a diferença?
Veja o texto original clicando aqui.
Vejo que em todos os lugares isso é uma realidade. Somente um pequeno grupo se destaca, aparece e é realmente bom no que faz. E o resto? O resto faz volume.
Peguemos por exemplo uma empresa de desenvolvimento de software, quantos programadores são realmente bons? Quantos analistas de sistemas, engenheiros de software fazem realmente um bom trabalho e são competentes?
Parei, pensei e vi que nas empresas que passei, não passa de 5%. Nos clientes que passei, poucos são as pessoas que fazem a diferença.
Quantas vezes você procurou um serviço diferenciado na sua cidade e quantas empresas você encontrou? 5%? Faça as contas, você verá que não passa disso.
E então? Você faz parte desse grupo seleto de 5% que faz a diferença?
Veja o texto original clicando aqui.
15 de setembro de 2009
Emprego ou Trabalho?
Quando eu era pequeno, meu pai sempre falava que eu deveria fazer direito, me tornar um advogado ou quem sabe prestar um concurso e ter uma vida estável. Minha mãe dizia que eu deveria prestar concurso público e me estabilizar, ter salário fixo, segurança de emprego, 30 dias de férias, 13o. e tudo que um bom "empregado", com sua carteira assinada tem.
Bom, não fiz direito como o meu pai queria e até hoje, só prestei um concurso público. A 5 anos trabalho em regime de PJ, aonde tenho minha empresa, que presto serviço a outras empresas, quase que um emprego. Não tenho 13o., nem férias, nem segurança de emprego, pois ao final do contrato, saio com uma mão na frente e outra atrás.
Fiz tudo ao contrário do que aprendi, mas não me arrependo. A cada dia, é um desafio, pois tenho que provar que sou bom no que faço e garantir que sempre terei "trabalho".
O que eu tenho, não é emprego e sim trabalho. Sou como uma empresa, que se o cliente não estiver satisfeito, ele irá procurar outro fornecedor.
A grande verdade, é que muitos não querem esse desafio, de se superar a cada dia, de buscar o seu melhor, de fazer o seu melhor. Preferem a estabilidade e a segurança de seus empregos ao invés de fazer o que realmente gostam, com paixão.
Aprendemos de nossos pais, escolas e colegas de trabalho que devemos ter EMPREGO. Mas isso não é mais real, o que temos que ter é TRABALHO e garantir que sempre o teremos.
As empresa buscam hoje profissionais capazes de se superar a cada dia, de apresentar resultados melhores a cada mês, de se adaptarem as mudanças na velocidade de luz e sempre estarem inquietos e inovando.
Empregado não faz isso, pois vive na.... (claro!)... Zona de Conforto.
Quem não tem segurança de emprego, como o empreendedor, o empresário, os profissionais liberais, os autônomos, tem que mander seu nível de serviço superior à concorrência para conseguir novos trabalhos.
Pense bem, se você é mau atendido em uma loja, você volta nela? Claro que não, você procura outro fornecedor.
Funcionários são como fornecedores, mas eles NÃO SABEM disso, infelizmente. A empresas entendem que o funcionário é um fornecedor, e elas SABEM disso.
Por isso, ao invés de ficar querendo um EMPREGO bom, faça o seu melhor naquilo que você gosta, procure TRABALHO.
Sucesso e até a próxima.
Bom, não fiz direito como o meu pai queria e até hoje, só prestei um concurso público. A 5 anos trabalho em regime de PJ, aonde tenho minha empresa, que presto serviço a outras empresas, quase que um emprego. Não tenho 13o., nem férias, nem segurança de emprego, pois ao final do contrato, saio com uma mão na frente e outra atrás.
Fiz tudo ao contrário do que aprendi, mas não me arrependo. A cada dia, é um desafio, pois tenho que provar que sou bom no que faço e garantir que sempre terei "trabalho".
O que eu tenho, não é emprego e sim trabalho. Sou como uma empresa, que se o cliente não estiver satisfeito, ele irá procurar outro fornecedor.
A grande verdade, é que muitos não querem esse desafio, de se superar a cada dia, de buscar o seu melhor, de fazer o seu melhor. Preferem a estabilidade e a segurança de seus empregos ao invés de fazer o que realmente gostam, com paixão.
Aprendemos de nossos pais, escolas e colegas de trabalho que devemos ter EMPREGO. Mas isso não é mais real, o que temos que ter é TRABALHO e garantir que sempre o teremos.
As empresa buscam hoje profissionais capazes de se superar a cada dia, de apresentar resultados melhores a cada mês, de se adaptarem as mudanças na velocidade de luz e sempre estarem inquietos e inovando.
Empregado não faz isso, pois vive na.... (claro!)... Zona de Conforto.
Quem não tem segurança de emprego, como o empreendedor, o empresário, os profissionais liberais, os autônomos, tem que mander seu nível de serviço superior à concorrência para conseguir novos trabalhos.
Pense bem, se você é mau atendido em uma loja, você volta nela? Claro que não, você procura outro fornecedor.
Funcionários são como fornecedores, mas eles NÃO SABEM disso, infelizmente. A empresas entendem que o funcionário é um fornecedor, e elas SABEM disso.
Por isso, ao invés de ficar querendo um EMPREGO bom, faça o seu melhor naquilo que você gosta, procure TRABALHO.
Sucesso e até a próxima.
1 de setembro de 2009
Zona de Conforto
Muito se fala da tal "Zona de Conforto", que as pessoas acomodadas estão nesta zona. Mas o que é realmente uma "zona de conforto"?
Bom, em muitos projetos que passei na minha vida inteira, tive que lidar e muito com essa tal Zona de Conforto, seja por usuários que enfrentei, empresas que não queriam mudar a sua forma de trabalhar, membros da equipe que se acomodavam por achar que já eram auto-suficientes e tantos outros que se encontravam em uma redoma de vidro, protegido do mundo exterior.
Encontra-se na Zona de Conforto aquele indivíduo que acredita ser auto-suficiente, não quer evoluir, por achar que a já está em uma situação confortável, que não precisa mais mostrar seu valor.
Esse indivíduo, pode ser um profissional que achar, com seus anos de experiência, nunca vai ser demitido da empresa que trabalha a anos. Pode ser uma pessoa que não quer mudar sua forma de trabalhar, porque isso pode dar muito "trabalho", que ela pode não se adaptar ou pode ser demitida, porque se mudar, não vai saber realizar seu trabalho da nova forma.
Pode até mesmo ser uma empresa, que tem seus processos "burrocráticos" mas como a empresa está viva a 40 anos no mercado, prefere não mudar, não evoluir, simplesmente por achar que não precisa mais mostrar seu valor ao mercado.
A verdade seja dita, essas pessoas e profissionais vão gradativamente perdendo seu valor e seu espaço para as pessoas e empresa que se inquietam e não se deixam entrar na "Zona de Conforto".
Em implantações de sistemas, principalmente em ERP's, passamos muito disso. Usuários boicotam o sistema, colocam a culpa no sistema dizendo que o mesmo não serva, que não presta e que o sistema atual é melhor (mesmo que o sistema atual seja antigo, lento, ruim, com poucas informações, mais difícil de usar...). Essa colocação é perfeitamente normal. Pessoas não gostam de mudanças, não gostam de reaprender o que fazem, não gostam de coisas novas... e não diga que não é verdade só porque você gosta de inovação, mudanças, melhorias... se você gosta, parabéns, você faz parte de um grupo seleto.
Mudar é difícil, sair da rotina é complicado, mudar a forma de fazer algo que você faz a anos é quase impossível.
Mas na área de tecnologia, temos que vencer as barreiras e estar constantemente "fugindo" da "zona de conforto". Inquietar-se é a solução.
Nunca fique satisfeito com o que conhece, busque mais, esqueça as coisas velhas e parta para o novo.
Nunca ache que está seguro no seu emprego, mostre resultados a cada dia, divulgue, faça seu marketing pessoal.
Nunca se convença de que a sua maneira de executar uma tarefa é a melhor forma, busque novas formas, com menos tempo, menos custo... mais resultado.
Não deixe que a idade acabe com sua motivação de aprender. Vejo pessoas mais velhas, com seus 40, 50 anos que param de inovar, de mudar, de conhecer coisas novas, por acharem que já sabem de tudo. Use sua experiência do passado para mudar o presente.
Agora se você vive fugido da Zona de Conforto, mas é um gerente ou um líder e precisa tirar seus subordinados e seguidores desta zona, a melhor forma é gerar o desconforto, "cutucar" a pessoa, colocar um certo medo (moderado, é claro) e claro, oferecer ganhos a essa pessoa.
No próximo post escrevo quais ganhos você pode oferecer... porque não é só dinheiro que resolve.
Até a próxima.
Bom, em muitos projetos que passei na minha vida inteira, tive que lidar e muito com essa tal Zona de Conforto, seja por usuários que enfrentei, empresas que não queriam mudar a sua forma de trabalhar, membros da equipe que se acomodavam por achar que já eram auto-suficientes e tantos outros que se encontravam em uma redoma de vidro, protegido do mundo exterior.
Encontra-se na Zona de Conforto aquele indivíduo que acredita ser auto-suficiente, não quer evoluir, por achar que a já está em uma situação confortável, que não precisa mais mostrar seu valor.
Esse indivíduo, pode ser um profissional que achar, com seus anos de experiência, nunca vai ser demitido da empresa que trabalha a anos. Pode ser uma pessoa que não quer mudar sua forma de trabalhar, porque isso pode dar muito "trabalho", que ela pode não se adaptar ou pode ser demitida, porque se mudar, não vai saber realizar seu trabalho da nova forma.
Pode até mesmo ser uma empresa, que tem seus processos "burrocráticos" mas como a empresa está viva a 40 anos no mercado, prefere não mudar, não evoluir, simplesmente por achar que não precisa mais mostrar seu valor ao mercado.
A verdade seja dita, essas pessoas e profissionais vão gradativamente perdendo seu valor e seu espaço para as pessoas e empresa que se inquietam e não se deixam entrar na "Zona de Conforto".
Em implantações de sistemas, principalmente em ERP's, passamos muito disso. Usuários boicotam o sistema, colocam a culpa no sistema dizendo que o mesmo não serva, que não presta e que o sistema atual é melhor (mesmo que o sistema atual seja antigo, lento, ruim, com poucas informações, mais difícil de usar...). Essa colocação é perfeitamente normal. Pessoas não gostam de mudanças, não gostam de reaprender o que fazem, não gostam de coisas novas... e não diga que não é verdade só porque você gosta de inovação, mudanças, melhorias... se você gosta, parabéns, você faz parte de um grupo seleto.
Mudar é difícil, sair da rotina é complicado, mudar a forma de fazer algo que você faz a anos é quase impossível.
Mas na área de tecnologia, temos que vencer as barreiras e estar constantemente "fugindo" da "zona de conforto". Inquietar-se é a solução.
Nunca fique satisfeito com o que conhece, busque mais, esqueça as coisas velhas e parta para o novo.
Nunca ache que está seguro no seu emprego, mostre resultados a cada dia, divulgue, faça seu marketing pessoal.
Nunca se convença de que a sua maneira de executar uma tarefa é a melhor forma, busque novas formas, com menos tempo, menos custo... mais resultado.
Não deixe que a idade acabe com sua motivação de aprender. Vejo pessoas mais velhas, com seus 40, 50 anos que param de inovar, de mudar, de conhecer coisas novas, por acharem que já sabem de tudo. Use sua experiência do passado para mudar o presente.
Agora se você vive fugido da Zona de Conforto, mas é um gerente ou um líder e precisa tirar seus subordinados e seguidores desta zona, a melhor forma é gerar o desconforto, "cutucar" a pessoa, colocar um certo medo (moderado, é claro) e claro, oferecer ganhos a essa pessoa.
No próximo post escrevo quais ganhos você pode oferecer... porque não é só dinheiro que resolve.
Até a próxima.
4 de agosto de 2009
Regulamentação da profissão em T.I.
Recentemente li uma reportagem sobre a regulamentação da profissão de T.I. e se isso era bom ou não para as empresas no país. Há anos escuto que está no plenário uma proposta de regulamentação da profissão de analistas de sistemas, programadores, administradores de rede, etc, etc... mas que isso não sai do papel.
No inicio, quando eu ainda vazia faculdade e logo após me formar, era totalmente a favor de se regulamentar a profissão... isso foi a cerca de 10 anos atrás. Hoje, tenho minhas dúvidas.... será que vale a pena? Será que o Brasil está preparado para isso? Parece uma coisa tão boba... regulamenta, criar um conselho para administrar tudo isso e pronto, estamos com a profissão regulamentada, com salários compatíveis a nossa responsabilidade e outras coisas mais.
Contudo, quando começei a partir para o lado gerencial da coisa, percebi que isso traria alguns malefícios. A escassez de profissionais na área de TI é evidente, falta mão de obra, qualificada ou não, falta e isso é uma verdade no país.
Os grandes centros demandam profissionais a todo momento, são projetos fechando, negócios sendo fechados e não tem gente para executar.
Se a regulamentação da profissão fosse aprovada, qual beneficio teríamos? Mais falta de profissional? Empresas trabalhando de forma ilegal, pois terão que contrar pessoas sem estarem devidamente habilitadas à prestar o tipo de serviço necessário?
Outra grande questão é se a sociedade tem ganhos com isso: uma profissão é regulamentada quando a sua atividade pode oferecer riscos a sociedade, como médicos, advogados, engenheiros e outras, mas e T.I? Realmente oferece risco à sociedade? Você pode dizer: e se o programador vez o sistema de controle de vôos? Ah... tudo bem, isso pode realmente oferecer um risco, mas convenhamos... que maluco deixaria um sistema desses na mão de um estagiário?
A grande questão: quanto se ganha e quanto se perde se isso realmente sair do papel? Será bom para nós profissionais que temos o diploma universitário e poderemos conseguir nossa credencial? E nossos colegas que resolveram se formar em Adminstração, contabilidade ou outro curso e exerce a atividade de analista de sistemas ou até mesmo programadores, vamos dispensá-los de nossas equipes, mesmo sendo bons profissionais?
Na minha opinião, o Brasil ainda não tem a maturidade suficiente para seguir com essa regulamentação.... talvez daqui alguns anos isso mude, mas não espere isso no curto e nem médio prazo.
No inicio, quando eu ainda vazia faculdade e logo após me formar, era totalmente a favor de se regulamentar a profissão... isso foi a cerca de 10 anos atrás. Hoje, tenho minhas dúvidas.... será que vale a pena? Será que o Brasil está preparado para isso? Parece uma coisa tão boba... regulamenta, criar um conselho para administrar tudo isso e pronto, estamos com a profissão regulamentada, com salários compatíveis a nossa responsabilidade e outras coisas mais.
Contudo, quando começei a partir para o lado gerencial da coisa, percebi que isso traria alguns malefícios. A escassez de profissionais na área de TI é evidente, falta mão de obra, qualificada ou não, falta e isso é uma verdade no país.
Os grandes centros demandam profissionais a todo momento, são projetos fechando, negócios sendo fechados e não tem gente para executar.
Se a regulamentação da profissão fosse aprovada, qual beneficio teríamos? Mais falta de profissional? Empresas trabalhando de forma ilegal, pois terão que contrar pessoas sem estarem devidamente habilitadas à prestar o tipo de serviço necessário?
Outra grande questão é se a sociedade tem ganhos com isso: uma profissão é regulamentada quando a sua atividade pode oferecer riscos a sociedade, como médicos, advogados, engenheiros e outras, mas e T.I? Realmente oferece risco à sociedade? Você pode dizer: e se o programador vez o sistema de controle de vôos? Ah... tudo bem, isso pode realmente oferecer um risco, mas convenhamos... que maluco deixaria um sistema desses na mão de um estagiário?
A grande questão: quanto se ganha e quanto se perde se isso realmente sair do papel? Será bom para nós profissionais que temos o diploma universitário e poderemos conseguir nossa credencial? E nossos colegas que resolveram se formar em Adminstração, contabilidade ou outro curso e exerce a atividade de analista de sistemas ou até mesmo programadores, vamos dispensá-los de nossas equipes, mesmo sendo bons profissionais?
Na minha opinião, o Brasil ainda não tem a maturidade suficiente para seguir com essa regulamentação.... talvez daqui alguns anos isso mude, mas não espere isso no curto e nem médio prazo.
27 de julho de 2009
Agora.... de volta a ativa
Mais um dia, mais uma semana começa, mas agora tenho internet móvel da Vivo, posso acessar a net aonde que quiser... em casa, no trabalho, na rua, em viagens.... que sucesso.
Pena que não funciona tão bem como dizem nas propagandas mas dá pro gasto, até consegui baixar alguns videos, seriados, músicas....
O que irrita é que as vezes você não consegue se conectar, fica falando que a porta não está aberta e a conexão cai de vez em quando. Mas até que tem uma boa velocidade, não chega a ser uma ADSL de 1mb, apesar da conexão acusar 3,6mb contudo ocila muito, as vezes chega a não entrar nos sites e ai tem que esperar e tentar novamente.
Bom, mas é melhor que ficar sem net.....
Abraços... até a próxima.
Pena que não funciona tão bem como dizem nas propagandas mas dá pro gasto, até consegui baixar alguns videos, seriados, músicas....
O que irrita é que as vezes você não consegue se conectar, fica falando que a porta não está aberta e a conexão cai de vez em quando. Mas até que tem uma boa velocidade, não chega a ser uma ADSL de 1mb, apesar da conexão acusar 3,6mb contudo ocila muito, as vezes chega a não entrar nos sites e ai tem que esperar e tentar novamente.
Bom, mas é melhor que ficar sem net.....
Abraços... até a próxima.
30 de junho de 2009
Novas Postagens
Ae galera, estou demorando mais para colocar as postagem pois estou de emprego novo. Agora estou em outra cidade e por enquanto, sem internet em casa.... mas logo isso irá acabar....
Agora estou trabalhando em uma empresa maior, filiada a TOTVS, fazendo gerenciamento de projetos. A área da empresa é diferente, mas gerenciar projetos de TI é sempre igual, só muda o escopo.....
Até a próxima....
Agora estou trabalhando em uma empresa maior, filiada a TOTVS, fazendo gerenciamento de projetos. A área da empresa é diferente, mas gerenciar projetos de TI é sempre igual, só muda o escopo.....
Até a próxima....
Delphi 2009 - Parte II
Hoje passei o dia tentando migrar minhas aplicações para Delphi 2009. Com muito suor consegui converter os componentes como disse anteriormente, mas tive que criar alguns para substituir (por sorte) 2 componentes da RXLib que não compila no D2009 nem a pau.
Ai, fui tentar é claro, compilar minhas aplicações e já me deparei com um problema. Utilizo aplicações em 3 camadas e ai para minha surpresa o método GetTableName do DataSetProvider sofreu mudanças nos parâmetros, ao invés de String ele utilizar WideString.... fala sério, tive que trocar tudo... até compila, mas dá pau depois.
Beleza a aplicação servidora funcionou!
Fui para a aplicação cliente, depois de, é claro, sofrer trocando os componentes da RxLib pelos meus novos componentes, consegui finalmente compilar a versão. Aproveitei e também atualizei meu Socket Connection para a nova versão do Delphi 2009.... ai começou a primeira decepção. O novo Socket simplesmente não funciona, a aplicação não localiza nenhum servidor de aplicação e não consegui conectar à minha aplicação servidora.... como descobri? Troquei o socket, voltando para a versão do Delphi 2007 e adivinha... funcionou.
Os problemas não pararam por ai, meu componente de relatórios não funcionava mais... eu entrava para editar o relatório, e.... pau.... Access Violation (se fosse em tempo de design, fechava o Delphi).
Bom, deixei o componente de relatório de lado e depois que consegui compilar e executar minha aplicação, comecei a testar. Primeira tela, 100% de sucesso... funcionou. Segunda tela... pau! Sem explicação... essa tela funcionava certinho pensei.... mas para minha frustração a tela estava codificada corretamente, o problema estava novamente no Delphi 2009. Não sei exatamente porque, mas parece que o Delphi mudou a implementação da propriedade "Provider Flags" do TSQLQuery. Antes, quando eu queria apenas trazer um campo na consulta e manusear o dado deste campo (alterar o valor dele) e não quisesse gravá-lo (sem inserção ou alteração), bastava eu deixar todas as propriedades como FALSE e assim, ao inserir ou alterar, o campo não sofria alterações. Muito útil quando se tem campo FK em uma tabela e o valor precisa ser mostrado. Acontece, que desta forma, no Delphi 2009 não funciona, o DELPHI simplesmente tenta gravar o campo, e como ele não existe na tabela sendo gravada.... pau.
Putz, o que que a Embarcadeiro e a equipe da Codegear fizeram com o Delphi? Inventaram um monte de coisa nova e estragaram o que funcionava bem antes......
Bom, qual minha saída? Voltar para o bom e velho Delphi 7. Acho que é por isso que a maioria esmagadora ainda utiliza essa versão do Delphi....
Bom, até a próxima.
Ai, fui tentar é claro, compilar minhas aplicações e já me deparei com um problema. Utilizo aplicações em 3 camadas e ai para minha surpresa o método GetTableName do DataSetProvider sofreu mudanças nos parâmetros, ao invés de String ele utilizar WideString.... fala sério, tive que trocar tudo... até compila, mas dá pau depois.
Beleza a aplicação servidora funcionou!
Fui para a aplicação cliente, depois de, é claro, sofrer trocando os componentes da RxLib pelos meus novos componentes, consegui finalmente compilar a versão. Aproveitei e também atualizei meu Socket Connection para a nova versão do Delphi 2009.... ai começou a primeira decepção. O novo Socket simplesmente não funciona, a aplicação não localiza nenhum servidor de aplicação e não consegui conectar à minha aplicação servidora.... como descobri? Troquei o socket, voltando para a versão do Delphi 2007 e adivinha... funcionou.
Os problemas não pararam por ai, meu componente de relatórios não funcionava mais... eu entrava para editar o relatório, e.... pau.... Access Violation (se fosse em tempo de design, fechava o Delphi).
Bom, deixei o componente de relatório de lado e depois que consegui compilar e executar minha aplicação, comecei a testar. Primeira tela, 100% de sucesso... funcionou. Segunda tela... pau! Sem explicação... essa tela funcionava certinho pensei.... mas para minha frustração a tela estava codificada corretamente, o problema estava novamente no Delphi 2009. Não sei exatamente porque, mas parece que o Delphi mudou a implementação da propriedade "Provider Flags" do TSQLQuery. Antes, quando eu queria apenas trazer um campo na consulta e manusear o dado deste campo (alterar o valor dele) e não quisesse gravá-lo (sem inserção ou alteração), bastava eu deixar todas as propriedades como FALSE e assim, ao inserir ou alterar, o campo não sofria alterações. Muito útil quando se tem campo FK em uma tabela e o valor precisa ser mostrado. Acontece, que desta forma, no Delphi 2009 não funciona, o DELPHI simplesmente tenta gravar o campo, e como ele não existe na tabela sendo gravada.... pau.
Putz, o que que a Embarcadeiro e a equipe da Codegear fizeram com o Delphi? Inventaram um monte de coisa nova e estragaram o que funcionava bem antes......
Bom, qual minha saída? Voltar para o bom e velho Delphi 7. Acho que é por isso que a maioria esmagadora ainda utiliza essa versão do Delphi....
Bom, até a próxima.
5 de junho de 2009
Delphi 2009
Semana passada resolvi instalar o Delphi 2009 e iniciar a conversão dos meus componentes e projetos pessoais, que estavam no Delphi 7, para essa nova versão.
O primeiro problema foi instalar no meu notebook, deu uma dor de cabeça lascada. Instalava, mas faltava componentes, tentava desintalava, trava o instalador, apaguei tudo, limpei os registros do Windows, tentei instalar novamente e travava no meio do caminho. Bom, até que depois de umas 10 tentativas, finalmente consegui. O engraçado que na máquina de casa, um desktop, instalou de primeira… vai entender.
Desempenho.
Logo de cara, percebi que é um tanto mais pesado que o Delphi 7 no meu notebook (AMD 64, HD80Gb 4200 rpm e 1 GB de memória) mas até que aceitável a demorar para abrir. No micro de casa (AMD 64 X2, HD 250 SATA 7200 e 2 GB de memória) até que foi rápida a inicialização.
Porém, a demora só na entrada. Compilação achei mais rápida, as ajudas (hints) abrem bem mais rápido que no Delphi 7, e não fica dando aquelas malditas travadas do Delphi 7 aonde ele fica procurando sabe lá o que no seu HD.
Interface
Mudou de mais em relação ao Delphi 7, mas essa mudança já vem desde a versão 8. Particularmente, acho a interface do Delphi 7 mais produtiva e fácil de trabalhar, mas é falta de costume. A busca rápida por componentes ajuda bastante, mas o estilo Visual Studio, ainda não me agrada muito.
As opções do menu são praticamente as mesmas, mudando pouca coisa em relação a versão 7. A parte de opções mudou bastante, mas só na questão de disposição, pois as opções são as mesmas.
Convertendo Componentes
Bom, ai começa o seu problema. Muitas coisas mudaram na linguagem, principalmente na questão de variaveis String e Char. Como vocês sabem (se não sabem, vão saber) que na versão 2009, o tipo String foi alterado o charset para Unicode16 e isso trouxe algumas mudanças. Muitas funções não aceitam mais o caracter Char e você terá que realizar a conversão para AnsiChar (basta fazer a chamada da funçao “AnsiChar()”, é simples de resolver, mas enche o saco ter que mudar tudo). Muitas funções tiveram incrementos de parametros, o que geram diversos erros de compilação, já que o parametro não é opcional.
Tive problemas com vários componentes de terceiros (os meus não deram), mas como eu tinha os fontes, consegui ajustar. Só não consegui converter a biblioteca RXLib, mas como eu utilizo apenas 3 componentes desta biblioteca, criei os meus próprios para substituir, já que o projeto foi abandonado e nem compensa perder tempo com essa biblioteca (se você utiliza, vai ter dor de cabeça para arrumar, alguns tipos e classes do Delphi utilizados na RXLib mudaram na versão 2009).
Em resumo, se você depende de componente de terceiros, tenha certeza de que o fornecedor já tenha preparado os componentes para Delphi2009 ou que você tenha os fontes, certamente você terá que mexer neles. Se você depende de um componente de terceiro e não tem ele para versão 2009, esqueça, não migre ainda.
Convertendo as aplicações
Bom, como tive que me desfazer da RxLib, estou ainda tendo que trocar os componentes desta biblioteca pelos meus próprios componentes. Ainda estou nesta fase e já está dando bastante trabalho. Depois que terminar, conto a vocês qual foi o resultado.
Finalizando…
Até o momento, achei a ferramenta bastante estável, coisa que não vi desde a versão 7. Quem já utilizou a versão 2007 não achará tanta diferença na interface, mas vai encontrar diferenças na parte de código, pois algumas coisas referente a linguagem mudou. A parte de edição de código, achei muito boa, pois ficou as dicas referente às funções tem links que ajudam a pesquisar no help e abrem muito rápido (bem diferente da versão 7). Tem vários auxilios de código, “code completation” muito interessante, lembrando o NetBeans quando se fala em Java (por exemplo, você escreve try e ele já monta a estrutura com o finnaly e end no final).
Gostei muito do Delphi2009, só preciso me acostumar com a nova interface, mas, sou suspeito em dizer, pois sou fã do Delphi desde sua verão 3.0 e utilizo essa ferramenta desde 1997, mas se você também gosta da linguagem, saiba que o pessoal da CodeGear (agora da Embarcadeiro) fez um excelente trabalho na versão 2009.
Só uma coisa me deixou desanimado: seus programas compilados em Delphi 2009 não rodarão em máquinas com Windows 98 (pelo menos é o que a CodeGear declarou) em virtude das mudanças feitas no charset de Strings, que passou para Unicode 16 que não é suportado por versões do Win98, ME e algumas versões mais antigas do Windows 2000.
Se deseja migrar para Delphi 2009 mesmo assim (como eu fiz) eu recomendo cautela, avalie seu componentes, seus sistemas, seus clientes e veja se não irá gerar mais dor de cabeça para você. Caso você não tenha problemas em ter que rodar seu sistema em Win98 e nem com componentes, vá em frente, arrisque e boa sorte.
Até a próxima.
3 de junho de 2009
Vai abrir uma empresa? Pense bem antes.
Hoje estive lendo algo sobre como é difícil abrir uma empresa e isso me fez lembrar uma "aventura" que tive em um passado recente.
Decidi que queria abrir uma empresa para minha esposa, pois seria melhor do que ela arrumar um emprego no comercio da cidade e ter a sorte de quem sabe, conseguir um salário comercial que mal chegaria a 600 reais por mês.
Foi ai que começamos a verificar alguns tipos de negócios e achamos que seria interessante adquirir uma franquia, pois a chance de sucesso seria muito maior. Conseguimos diversos contatos, entrevistas e até propostas com valores e tudo mais, tinhamos o "perfil" procurado pelos donos das franquias. Perfeito, agora só precisa do principal: o dinheiro, a grana, a "bufunfa"....
Ótimo, aonde conseguir? humm... resposta: Projer, um programa do governo para novas empresa e projetos, com possibilidades de até 80% do valor com limite de 500.000,00, e tudo com auxilio do Sebrae, de forma simples (como é divulgado) e rápido.
Certo? Não, errado.
Você deve ter um plano de negócio muito bem elaborado, que justifique o seu projeto e que ele seja rentável e que você tenha como pagar o financiamento.
Fizemos o plano de negócios, ficou excelente, projeto totalmente rentável, não tinha como não ser aprovado e o nosso empréstimo.
Com o plano de negócio assinado e aprovado pelo consultor do Sebrae (que por hora, não podemos reclamar devido ao seu excelente atendimento), fomos ao banco e adivinha? Projeto aprovado e dinheiro liberado? Doce ilusão.
Infelizmente esse projeto do governo, facilidade de se conseguir dinheiro para inicar o seu próprio negócio é uma ilusão.
Primeiro: os bancos não fazem a menor idéia que existe esse tipo de projeto ou financiamento. Os funcionários do Banco do Brasil e Caixa Econômica estão despreparados, não sabem dar respostas.
Segundo: quando descobre-se uma pessoa no banco que conhece esse tipo de financiamento, você descobre que você tem que ter 1 ano ou mais de empresa aberta... opa... como assim? se estou querendo o dinheiro para começar o negócio, como posso ter empresa com faturamento comprovado de 1 ano? Ridículo, mas é isso mesmo que acontece.
Terceiro: se pelos programas do governo para abrir empresas simplesmente não existem ou ninguém sabe que existe (só a pessoa que faz a propaganda na TV), recorre a quem? Bancos e instituições financeiras, porém, os juros são tão altos que inviabilizam qualquer projeto de nova empresa, porém, esses juros são ignorados pela maioria que abrem seu negócio e "quebram" em menos de 1 ano.
E ainda tem todos os "pepinos" de uma empresa... isso que comentei é apenas para começar o seu negócio, a partir daí você tem outros problemas, como encargos (descobri que o maior sócio da empresa é o governo, que tem retirada mensal muitas vezes maior que a do dono), funcionários (encargos trabalhistas, podem chegar à 103% sobre o valor que você paga a seu empregado), bancos, administrar o negócio de forma correta, e por ai vai.
E ai? Pensou direito? Quer encarar e abrir seu próprio negócio?
Se sim, ai vão algumas dicas minhas:
1. Conheça o negócio primeiro. Não abra uma loja de roupas se você não sabe nada sobre moda, isso só vai fazer você comprar e vender errado.
2. Trabalhe como empregado naquilo que quer abrir, conheça as "manhas" do negócio, pegue dicas com as pessoas (meu pai sempre disse isso....).
3. Não tem como trabalhar antes, recorra a amigos, parentes, amigo do seu vizinho, reuniões de associações comerciais... ou seja, vá atrás de informações de como funciona o ramo de atividade do negócio que deseje abrir.
4. Não abra um negócio apenas pelo dinheiro, por exemplo dizer: "vou abrir uma loja de importados porque dá dinheiro" só que você não entende nada deste ramo e não gosta de ter que trabalhar vendendo produtos.... Em suma, faça algo que você goste, as chances de dar certo são maiores.
5. Prepare-se para passar um tempo sem retirar nada da empresa, tenha dinheiro em caixa particular para se manter entre 3 à 8 meses para pequenos negócios, esse período será quase impossível tirar algum dinheiro da empresa.
6. Fuja dos altos juros. Se tiver que recorrer e empréstimos, tente buscar amigos, parentes que ofereçam dinheiro a juros baixo. Faça um contrato com seu parente ou amigo para que fique algo formal. Se não tiver escolha, visite vários bancos, converse com os gerentes e tente busca o juros mais baixo. Se você tem conta pessoal em algum banco, vá nele primeiro, por já ter um relacionamento com o banco pode ser mais fácil.
7. Aprenda a administrar uma empresa. Você sabe o que é fluxo de caixa? Contas a Pagar? Contas a Receber? Demonstrativo de Resultado? Lucratividade? Bom, se algum destes itens já fez você coçar a cabeça, vá estudar antes. Recorra ao Sebrae é um ótimo lugar para começar. Faça os cursos que estão disponíveis no site do Sebrae (são de graça). Não tem internet, vá até o Sebrae de sua cidade ou de uma cidade próxima, faça todos os cursos que conseguir, aprenda a administrar seu negócio antes de abri-lo, pois não adianta chorar sobre o leite derramado.
Bom ai estão algumas dicas, se quiserem mais, deixe seu comentário que nos próximos post posso colocar mais dicas e informações para vocês.
Até mais.
Decidi que queria abrir uma empresa para minha esposa, pois seria melhor do que ela arrumar um emprego no comercio da cidade e ter a sorte de quem sabe, conseguir um salário comercial que mal chegaria a 600 reais por mês.
Foi ai que começamos a verificar alguns tipos de negócios e achamos que seria interessante adquirir uma franquia, pois a chance de sucesso seria muito maior. Conseguimos diversos contatos, entrevistas e até propostas com valores e tudo mais, tinhamos o "perfil" procurado pelos donos das franquias. Perfeito, agora só precisa do principal: o dinheiro, a grana, a "bufunfa"....
Ótimo, aonde conseguir? humm... resposta: Projer, um programa do governo para novas empresa e projetos, com possibilidades de até 80% do valor com limite de 500.000,00, e tudo com auxilio do Sebrae, de forma simples (como é divulgado) e rápido.
Certo? Não, errado.
Você deve ter um plano de negócio muito bem elaborado, que justifique o seu projeto e que ele seja rentável e que você tenha como pagar o financiamento.
Fizemos o plano de negócios, ficou excelente, projeto totalmente rentável, não tinha como não ser aprovado e o nosso empréstimo.
Com o plano de negócio assinado e aprovado pelo consultor do Sebrae (que por hora, não podemos reclamar devido ao seu excelente atendimento), fomos ao banco e adivinha? Projeto aprovado e dinheiro liberado? Doce ilusão.
Infelizmente esse projeto do governo, facilidade de se conseguir dinheiro para inicar o seu próprio negócio é uma ilusão.
Primeiro: os bancos não fazem a menor idéia que existe esse tipo de projeto ou financiamento. Os funcionários do Banco do Brasil e Caixa Econômica estão despreparados, não sabem dar respostas.
Segundo: quando descobre-se uma pessoa no banco que conhece esse tipo de financiamento, você descobre que você tem que ter 1 ano ou mais de empresa aberta... opa... como assim? se estou querendo o dinheiro para começar o negócio, como posso ter empresa com faturamento comprovado de 1 ano? Ridículo, mas é isso mesmo que acontece.
Terceiro: se pelos programas do governo para abrir empresas simplesmente não existem ou ninguém sabe que existe (só a pessoa que faz a propaganda na TV), recorre a quem? Bancos e instituições financeiras, porém, os juros são tão altos que inviabilizam qualquer projeto de nova empresa, porém, esses juros são ignorados pela maioria que abrem seu negócio e "quebram" em menos de 1 ano.
E ainda tem todos os "pepinos" de uma empresa... isso que comentei é apenas para começar o seu negócio, a partir daí você tem outros problemas, como encargos (descobri que o maior sócio da empresa é o governo, que tem retirada mensal muitas vezes maior que a do dono), funcionários (encargos trabalhistas, podem chegar à 103% sobre o valor que você paga a seu empregado), bancos, administrar o negócio de forma correta, e por ai vai.
E ai? Pensou direito? Quer encarar e abrir seu próprio negócio?
Se sim, ai vão algumas dicas minhas:
1. Conheça o negócio primeiro. Não abra uma loja de roupas se você não sabe nada sobre moda, isso só vai fazer você comprar e vender errado.
2. Trabalhe como empregado naquilo que quer abrir, conheça as "manhas" do negócio, pegue dicas com as pessoas (meu pai sempre disse isso....).
3. Não tem como trabalhar antes, recorra a amigos, parentes, amigo do seu vizinho, reuniões de associações comerciais... ou seja, vá atrás de informações de como funciona o ramo de atividade do negócio que deseje abrir.
4. Não abra um negócio apenas pelo dinheiro, por exemplo dizer: "vou abrir uma loja de importados porque dá dinheiro" só que você não entende nada deste ramo e não gosta de ter que trabalhar vendendo produtos.... Em suma, faça algo que você goste, as chances de dar certo são maiores.
5. Prepare-se para passar um tempo sem retirar nada da empresa, tenha dinheiro em caixa particular para se manter entre 3 à 8 meses para pequenos negócios, esse período será quase impossível tirar algum dinheiro da empresa.
6. Fuja dos altos juros. Se tiver que recorrer e empréstimos, tente buscar amigos, parentes que ofereçam dinheiro a juros baixo. Faça um contrato com seu parente ou amigo para que fique algo formal. Se não tiver escolha, visite vários bancos, converse com os gerentes e tente busca o juros mais baixo. Se você tem conta pessoal em algum banco, vá nele primeiro, por já ter um relacionamento com o banco pode ser mais fácil.
7. Aprenda a administrar uma empresa. Você sabe o que é fluxo de caixa? Contas a Pagar? Contas a Receber? Demonstrativo de Resultado? Lucratividade? Bom, se algum destes itens já fez você coçar a cabeça, vá estudar antes. Recorra ao Sebrae é um ótimo lugar para começar. Faça os cursos que estão disponíveis no site do Sebrae (são de graça). Não tem internet, vá até o Sebrae de sua cidade ou de uma cidade próxima, faça todos os cursos que conseguir, aprenda a administrar seu negócio antes de abri-lo, pois não adianta chorar sobre o leite derramado.
Bom ai estão algumas dicas, se quiserem mais, deixe seu comentário que nos próximos post posso colocar mais dicas e informações para vocês.
Até mais.
16 de maio de 2009
Atualização do Site de Apostilas
Depois de um longo e tenebroso inverno, eis que o site de apostilas foi atualizado....
Bom, não faz tanto tempo asim....
Adicionei para vocês, queridos leitores deste blog, mais 3 documentos. Agora sobre o MS-Project.
Para quem está iniciando o uso desta ferramenta, sempre se depara com uma questão: por onde começar?
Por isso, montei um roteiro básico de como montar um cronograma de um projeto, por onde e quais opções você deve acessar antes de sair preenchendo a planilha com suas atividades.
Também adicionei, uma apostila de como você pode acompanhar seu projeto, utilizando a técnica de valor agregado no MS-Project
E por fim, adicionei uma pequena apresentação, que fala um pouco sobre gerenciamento de projetos segundo o PMI.
Visite e baixe suas apostilas no site: http://site.pop.com.br/emersonz
Bom, não faz tanto tempo asim....
Adicionei para vocês, queridos leitores deste blog, mais 3 documentos. Agora sobre o MS-Project.
Para quem está iniciando o uso desta ferramenta, sempre se depara com uma questão: por onde começar?
Por isso, montei um roteiro básico de como montar um cronograma de um projeto, por onde e quais opções você deve acessar antes de sair preenchendo a planilha com suas atividades.
Também adicionei, uma apostila de como você pode acompanhar seu projeto, utilizando a técnica de valor agregado no MS-Project
E por fim, adicionei uma pequena apresentação, que fala um pouco sobre gerenciamento de projetos segundo o PMI.
Visite e baixe suas apostilas no site: http://site.pop.com.br/emersonz
3 de maio de 2009
Site de Apostilas, apresentações e documentos
Olá, acabei de colocar no ar um novo site, de minha autoria, para publicar meus documentos, apostilas, apresentações, exemplos e outros.
Ele conterá algumas coisas que publicarei neste blog em formato PDF para baixar e outras apostilas, apresentações e textos, que já produzi e venho reproduzindo ao longo dos anos.
A página é bem simples, mas está separada por assunto, pois o unico intuito é divulgar as minhas apostilas e não a de terceiros.
Para começcar, já disponibilizei 3 apostilas pequenas:
1. Apostila básica de UML
2. Apostila sobre RUP
3. Apostila sobre Design Patterns.
Visite a página e baixe os arquivos, são de uso livre, você pode ler, copiar, alterar desde que cite o nome do autor destes documento (no caso, eu) .
Endereço: http://site.pop.com.br/emersonz
Ele conterá algumas coisas que publicarei neste blog em formato PDF para baixar e outras apostilas, apresentações e textos, que já produzi e venho reproduzindo ao longo dos anos.
A página é bem simples, mas está separada por assunto, pois o unico intuito é divulgar as minhas apostilas e não a de terceiros.
Para começcar, já disponibilizei 3 apostilas pequenas:
1. Apostila básica de UML
2. Apostila sobre RUP
3. Apostila sobre Design Patterns.
Visite a página e baixe os arquivos, são de uso livre, você pode ler, copiar, alterar desde que cite o nome do autor destes documento (no caso, eu) .
Endereço: http://site.pop.com.br/emersonz
1 de maio de 2009
Scrum – Vantagens e Desvantagens
Olá, hoje vou contar um pouquinho mais sobre o Scrum e o que estou achando deste framework ou processo (ou como você queira chamá-lo).
Na empresa que estou atuando atualmente, está em processo de implantação de uma metodologia baseada no Scrum. Nestes 5 meses que se passaram desde a adoção e implantação da metodologia percebi algumas vantagens e desvantagens da metodologia como um todo.
Vamos a algumas vantagens que percebi durante esse tempo:
- Motivação maior dos programadores. O comprometimento dos programadores realmente aumentou assim como a motivação. Foi muito interessante ver o empenho dos desenvolvedores em atingir a meta que era de “entregar o sprint” ou seja, eles se comprometiam em entregar aquilo que eles disseram que iriam entregar no prazo de 1 sprint (na empresa, foi adotado Sprints semanais).
- Visualização do projeto. Os projetos passaram a ter uma visualização melhor dentro da organização, antes ficavam ocultos e só os gerentes de projeto sabiam o que se passava no projeto. Como todo projeto passou a ter um Backlog com tudo que deve ser entregue fica mais fácil a visualização por todos os membros da equipe.
- Diminuição dos bugs. O prazo deixa de ser o mais importante e a qualidade passa a ser o centro das atenções. O programador não tem mais um prazo que lhe é imposto e sim a equipe se compromete a entregar aquilo que ela consegue no prazo do Sprint (1 semana, 2 semanas, 1 mês), porém, tem que entregar sem nenhum erro e a funcionalidade não pode mais voltar com erro. Os índices na empresa mostraram que o re-trabalho diminuiu.
- Prioridades podem ser alteradas. Isso realmente é uma vantagem em projetos em que o cliente tem dúvidas do que é mais importante. Quando se trabalha com metodologias como a do PMI, isso é travado, pois qualquer alteração na sequencia das atividades, detona o planejamento e a execução do projeto, mas com Scrum não, pois só não se mexe no Sprint, mas aquilo que ainda não foi planejado no Sprint, pode ser alterada sua ordem sem problemas, desde que já se tenha os requisitos da funcionalidade prontos.
- Funcionalidade que agregam valor, vêem primeiro. Um dos itens que independente da metodologia pode ser aplicado, contudo, no Scrum esse critério é bastante enfático, pois o que agrega maior valor ao negócio do cliente, deve sim ser entregue primeiro mas muitos gerentes não se atentam a isso, preferem entregar o que é mais fácil primeiro (bem típico do ser humano... faz o que é mais fácil primeiro e deixa o difícil por ultimo).
Bom, existem outras vantagens, mas vou deixar para outro dia... agora vamos a algumas desvantagens:
- Projeto não documentado. No inicio, documentação parece ser inútil, muitos perguntam: “Para que gastar tempo escrevendo? Vamos codificar que é melhor”, contudo, existem projetos conturbados, requisitos mal escritos geram dor de cabeça mais tarde. A falta de documentação de software gera custos na hora da manutenção e no suporte, pois na hora de alterar alguma funcionalidade, sem documentação, o analista ou programador poderá ficar perdido ou alterar algo que não poderia ser alterado. Esse é um dos principais problemas que vejo na metodologia. Sugiro uma adaptação e não abandonar totalmente a documentação e sim ser mais seletivo, documentando aquilo que é necessário realmente.
- Prazo. Bom, se a equipe de produção determina o prazo, como vamos passar uma posição ao cliente de quando o projeto acaba? Alguns dizem que é possível dar datas com o Scrum, mas não é a prática que é pregada. Vejo isso como um problema, pois o cliente sempre perguntará: “quando que vai terminar esse projeto?”... ou nunca perguntaram para você? Tudo bem, o cliente recebe funcionalidades periodicamente, assim você pode negociar o prazo final... porém, nem todo projeto é assim.
- Falta planejamento do escopo. A metodologia não aborda nenhum tipo de planejamento do escopo apenas que deve-se ter um Backlog. Contudo, esse backlog sofre mudanças e fica a cargo da equipe avaliar e controlar esse backlog. A equipe tenderá sempre para o cliente, pois ele busca a satisfação do mesmo, porém, pode deixar escapar itens que não era para serem feitos, ou seja, o risco de ser feito itens fora do escopo aumenta e a empresa pode perder dinheiro com isso.
- Papéis indefinidos. No Scrum só existem 4 pessoas: O usuário, o Product Owner (PO), o Scrum Master (SM) e o Team (time), mas cadê o analista de negócio, o analista de sistema, o testador.... ah sim, está tudo dentro do time... será que está mesmo? Um programador testar o que o outro fez, nem sempre funciona é necessário um testador que saiba o que está fazendo. Programador nem sempre sabe modelar, é necessário uma pessoa com experiência em análise de sistemas. O PO acredito que tem que ser o analista de negócio e o time tem que ser composto por pessoas com diversas competências, senão a coisa não funciona. Outro detalhe, o usuário, através do PO é quem diz ao time o que ele quer e pra que, mas as vezes, o usuário não sabe o que quer e ai entra o analista de sistema, que tenta interpretar o que o usuário deseja... mas no Scrum só existe o time. Se o time tiver as competências necessárias, funciona, caso contrário, vai sair você sabe o que.
Conclusão
Acredito que nenhum processo ou metodologia seja perfeita para sua empresa ou para a minha. Todas tem suas vantagens e desvantagens. Particularmente, gostei de várias teorias do Scrum, de outras, nem tanto. Mas como é um Framework, você pode adaptá-la para a sua realidade e criar um processo para a sua empresa. Por exemplo, na empresa não foi extinto o documento de requisito, que deve ser documentado e assinado pelo cliente, pois sabemos que sem esse documento, podemos facilmente perder o controle do escopo do projeto. O importante, é que sua empresa tenha um processo definido, que seja seguido por todos e que seja continuamente melhorado, seja ele derivado do Scrum, XP, RUP ou qualquer outra metodologia.
Até a próxima!
15 de abril de 2009
Scrum X RUP
Nos dias atuais, fala-se muito de processos, qualidade de software, médotos ágeis, e outros jagões do mundo do desenvolvimento de Software.
O RUP (ou IRUP após a aquisição da Rational pela IBM) é um método da engenharia de software, que utiliza a abordagem da análise orientada a objetos em sua concepção. Utiliza a UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) como base para sua documentação do sofware. Utiliza o ciclo de vida do sofware em espiral ou iterativo, aonde é possível determinar o tamanho de cada iteração, tendo assim, um pedaço ou release do sofware de tempos em tempos, o que nada impede que toda a iteração seja o sofware como um todo (não recomendável, é claro).
O RUP preza pela documentação (tanto visual utilizando a notação da UML como escrita), controle de escopo, controle dos requisitos, controle da qualidade, pelo time com papéis bem definidos, etc, etc.
O RUP, apesar de ser uma metodologia pesada, aconselhável para grandes times e grandes projetos, é possível de se adaptar para projetos menores, tornado-o "utilizável" em projetos de menor escala com equipes menores.
O Scrum, é uma metodologia (ou framework como alguns defendem) baseada no métodos ágeis (manifesto ágil) que parte do principio, que produto pronto é produto "rodando". O Scrum defende a idéia de mais código e software rodando do que documentação, mais negociação do que avaliação de escopo x contrato.
No Scrum não existem papéis definidos como no RUP. Só existem 3 funções: Product Owner (PO), Scrum Master (SM) e Time (Team). Essa equipe faz tudo: define requisitos, analisa a melhor forma de implementar, treina os usuários, implanta e controle escopo (será que controla?).
É uma metodologia bastante ágil, aonde se pode ter entregáveis (ou funcionalidades) prontas em um espaço de tempo bem curto, algo que pode varia entre 2 a 4 semanas.
É baseada também no metodo espiral da engenharia de software, que leva em conta o o processo de iteração, mas ao contrário do RUP, aonde você fica livre de determinar o tamanho da iteração, no Scrum o tempo máximo é de 4 semanas, que são chamados de Sprint´s.
Conclusão:
Não vou dizer quem é melhor que quem... mas em resumo, as duas metodologias são bastante parececias em alguns principios mas bem diferentes em outros. A escolha entre uma ou outra, vai desde o tamanho do projeto, tamanho de equipe, até mesmo o tamanho da empresa que deseja adotar um dos métodos.
Já vi várias empresas terem sucesso tanto com Scrum como com RUP, assim como, já vi projetos de implantação de RUP e Scrum afundarem... não tem como dizer qual é a melhor, somente vivenciando e definindo aonde você e sua empresa quer chegar.
Até a próxima, prometo escrever mais sobre essas duas metodologias, e vocês poderão tirar suas conclusões.
Não deixem de conferir os links:
pt.wikipedia.org/wiki/IBM_Rational_Unified_Process
pt.wikipedia.org/wiki/UML
www.scrum.org.br (Scrum user-group no Brasil)
scrum4you.wordpress.com (blog fo Boris, um nome importante no "meio" Scrum)
O RUP (ou IRUP após a aquisição da Rational pela IBM) é um método da engenharia de software, que utiliza a abordagem da análise orientada a objetos em sua concepção. Utiliza a UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) como base para sua documentação do sofware. Utiliza o ciclo de vida do sofware em espiral ou iterativo, aonde é possível determinar o tamanho de cada iteração, tendo assim, um pedaço ou release do sofware de tempos em tempos, o que nada impede que toda a iteração seja o sofware como um todo (não recomendável, é claro).
O RUP preza pela documentação (tanto visual utilizando a notação da UML como escrita), controle de escopo, controle dos requisitos, controle da qualidade, pelo time com papéis bem definidos, etc, etc.
O RUP, apesar de ser uma metodologia pesada, aconselhável para grandes times e grandes projetos, é possível de se adaptar para projetos menores, tornado-o "utilizável" em projetos de menor escala com equipes menores.
O Scrum, é uma metodologia (ou framework como alguns defendem) baseada no métodos ágeis (manifesto ágil) que parte do principio, que produto pronto é produto "rodando". O Scrum defende a idéia de mais código e software rodando do que documentação, mais negociação do que avaliação de escopo x contrato.
No Scrum não existem papéis definidos como no RUP. Só existem 3 funções: Product Owner (PO), Scrum Master (SM) e Time (Team). Essa equipe faz tudo: define requisitos, analisa a melhor forma de implementar, treina os usuários, implanta e controle escopo (será que controla?).
É uma metodologia bastante ágil, aonde se pode ter entregáveis (ou funcionalidades) prontas em um espaço de tempo bem curto, algo que pode varia entre 2 a 4 semanas.
É baseada também no metodo espiral da engenharia de software, que leva em conta o o processo de iteração, mas ao contrário do RUP, aonde você fica livre de determinar o tamanho da iteração, no Scrum o tempo máximo é de 4 semanas, que são chamados de Sprint´s.
Conclusão:
Não vou dizer quem é melhor que quem... mas em resumo, as duas metodologias são bastante parececias em alguns principios mas bem diferentes em outros. A escolha entre uma ou outra, vai desde o tamanho do projeto, tamanho de equipe, até mesmo o tamanho da empresa que deseja adotar um dos métodos.
Já vi várias empresas terem sucesso tanto com Scrum como com RUP, assim como, já vi projetos de implantação de RUP e Scrum afundarem... não tem como dizer qual é a melhor, somente vivenciando e definindo aonde você e sua empresa quer chegar.
Até a próxima, prometo escrever mais sobre essas duas metodologias, e vocês poderão tirar suas conclusões.
Não deixem de conferir os links:
pt.wikipedia.org/wiki/IBM_Rational_Unified_Process
pt.wikipedia.org/wiki/UML
www.scrum.org.br (Scrum user-group no Brasil)
scrum4you.wordpress.com (blog fo Boris, um nome importante no "meio" Scrum)
9 de abril de 2009
Seus executáveis estão grande? Compacte-os
Se você está com problemas com o tamanho dos executáveis e DLL´s do seu sistema, não se desespere, existe uma solução: UPX.
O UPX é um aplicativo gratuito, capaz de compactar os executáveis de sua aplicação, tornando-os menores para que possam ser transportados mais facilmente.
Ele mantém o executável da forma original, sem comprometer seu funcionamento, deixando até 50% menor que o arquivo original (já cheguei a 70% menor).
Isso ajuda muito, quando fazemos atualizações de aplicações e que depende de uma rede interna com alto tráfego de dados. Com aplicativo menor, o consumo de banda será bem menor na hora de atualizar os executáveis.
Veja alguns exemplos de compactação:
Winamp.exe --> Tamanho Original: 1.314 kb depois de compactá-lo: 507 kb
winword.exe --> Tamanho Original: 11.756 kb depois de compactá-lo: 5.725 kb
Se estiver com medo de ter algum problema como defeitos no software depois de compactá-lo, fique tranquilo, é muito difícil ocorrer. Utilizo ele em ambientes de produção já há algum tempo e não tive problemas até hoje.
Também não há uma redução de performance ao abrir o executável, não que seja perceptível.
Também não sobrecarrega memória ao usar o aplicativo compactado.
Não há necessidade instalar nada nas máquinas para executar o aplicativo compactado, já que ele permanece com a extensão .exe e é executado normalmente, como se não tivesse compactado.
Se interessou? Então baixe o UPX no site upx.sourceforge.net e teste.
O UPX é um aplicativo gratuito, capaz de compactar os executáveis de sua aplicação, tornando-os menores para que possam ser transportados mais facilmente.
Ele mantém o executável da forma original, sem comprometer seu funcionamento, deixando até 50% menor que o arquivo original (já cheguei a 70% menor).
Isso ajuda muito, quando fazemos atualizações de aplicações e que depende de uma rede interna com alto tráfego de dados. Com aplicativo menor, o consumo de banda será bem menor na hora de atualizar os executáveis.
Veja alguns exemplos de compactação:
Winamp.exe --> Tamanho Original: 1.314 kb depois de compactá-lo: 507 kb
winword.exe --> Tamanho Original: 11.756 kb depois de compactá-lo: 5.725 kb
Se estiver com medo de ter algum problema como defeitos no software depois de compactá-lo, fique tranquilo, é muito difícil ocorrer. Utilizo ele em ambientes de produção já há algum tempo e não tive problemas até hoje.
Também não há uma redução de performance ao abrir o executável, não que seja perceptível.
Também não sobrecarrega memória ao usar o aplicativo compactado.
Não há necessidade instalar nada nas máquinas para executar o aplicativo compactado, já que ele permanece com a extensão .exe e é executado normalmente, como se não tivesse compactado.
Se interessou? Então baixe o UPX no site upx.sourceforge.net e teste.
6 de abril de 2009
Apoio Gerencial
Navengando pelo site do Sebrae, encontrei uma porção de documentos que são muito úteis para aqueles que estão buscando por informações a respeito de regras de negócio de uma empresa. Não são materiais muito complexos nem extensos, tem linguagem simples que qualquer terráquio consegue entender.
Os textos dão uma boa noção de Fluxo de Caixa, Custos Diretos e Indiretos, Formação de Preço de Venda, o que é Contabilidade, Ativos, Passivos, entre outras dicas, informações e o mais interessante, com exemplos simples, que facilitam o entendimento.
Se você é daqueles que está começando, ou quer entender um pouco mais de regras de negócio, vale a pena passar lá e baixar alguns destes documentos, pelo menos, quando você for fazer uma entrevista com algum cliente seu, ou quando estiver desenvolvendo um software, não vai ficar "boiando" na conversa, quando o usuário começar a falar de "débitos" e "créditos" da contabilidade, nem o que custo direto e indireto....
O site é www.sebrae.com.br/atendimento/instrumentos-de-apoio-gerencial.
Os textos dão uma boa noção de Fluxo de Caixa, Custos Diretos e Indiretos, Formação de Preço de Venda, o que é Contabilidade, Ativos, Passivos, entre outras dicas, informações e o mais interessante, com exemplos simples, que facilitam o entendimento.
Se você é daqueles que está começando, ou quer entender um pouco mais de regras de negócio, vale a pena passar lá e baixar alguns destes documentos, pelo menos, quando você for fazer uma entrevista com algum cliente seu, ou quando estiver desenvolvendo um software, não vai ficar "boiando" na conversa, quando o usuário começar a falar de "débitos" e "créditos" da contabilidade, nem o que custo direto e indireto....
O site é www.sebrae.com.br/atendimento/instrumentos-de-apoio-gerencial.
1 de abril de 2009
Seus arquivos nas nuvens
Semana passada, navengando pela internet, descobri algo, não tão novo assim, mas me chamou a atenção: um serviço da Microsoft o SkyDrive (ou Disco nas nuvens???).
Todos tem uma conta no Windows Live, ou se preferir, do MSN, mas nem todos viram esse serviço que a Microsoft oferece gratuitamente no seu site www.windowslive.com do qual permite você armazenar até 25 GB de arquivos, é isso mesmo 25GB.
Se você precisava de espaço na internet para postar seus arquivos, acho que encontrou... pois 25GB é um bom espaço.
Com esse serviço você pode disponibilizar seus arquivos na internet, podendo compartilhá-los com quem quiser ou torná-los públicos para que qualquer pessoa possa baixar.
O serviço não é novo, a algum tempo já existem provedores que oferecem discos vituais... mas ainda não tinha encontrado nenhum que fosse de 25GB e de graça.
A Google, por exemplo, não tem (ainda, pois há rumores do gdrive).
Para usá-lo é muito simples, basta se conectar no site do windows live (use o link acima), usando sua conta do MSN e habilitar o serviço, acessando o menu do site "Mais", irá se abrir várias opções, e uma delas é o SkyDrive.
Lá você poderá criar novas pastas, criar pastas particulares, aonde só você poderá acessar, pastas públicas para postar arquivos comuns e compartilhá-los com seus amigos.
Ao postar um arquivo público, o SkyDrive oferece uma opção de enviar um link para esses arquivos públicos para os contatos do seu MSN ou para qualquer e-mail de sua preferência.
Desta vez, a Microsoft saiu na frente com esse serviço gratuito.
Bom, como nem tudo são "flores", o tamanho de cada arquivo é de no máximo 50 mb, ou seja, não dá pra deixar um filme inteiro lá para alguém baixar, você terá que quebrá-lo em vários arquivos menores. :-(
Todos tem uma conta no Windows Live, ou se preferir, do MSN, mas nem todos viram esse serviço que a Microsoft oferece gratuitamente no seu site www.windowslive.com do qual permite você armazenar até 25 GB de arquivos, é isso mesmo 25GB.
Se você precisava de espaço na internet para postar seus arquivos, acho que encontrou... pois 25GB é um bom espaço.
Com esse serviço você pode disponibilizar seus arquivos na internet, podendo compartilhá-los com quem quiser ou torná-los públicos para que qualquer pessoa possa baixar.
O serviço não é novo, a algum tempo já existem provedores que oferecem discos vituais... mas ainda não tinha encontrado nenhum que fosse de 25GB e de graça.
A Google, por exemplo, não tem (ainda, pois há rumores do gdrive).
Para usá-lo é muito simples, basta se conectar no site do windows live (use o link acima), usando sua conta do MSN e habilitar o serviço, acessando o menu do site "Mais", irá se abrir várias opções, e uma delas é o SkyDrive.
Lá você poderá criar novas pastas, criar pastas particulares, aonde só você poderá acessar, pastas públicas para postar arquivos comuns e compartilhá-los com seus amigos.
Ao postar um arquivo público, o SkyDrive oferece uma opção de enviar um link para esses arquivos públicos para os contatos do seu MSN ou para qualquer e-mail de sua preferência.
Desta vez, a Microsoft saiu na frente com esse serviço gratuito.
Bom, como nem tudo são "flores", o tamanho de cada arquivo é de no máximo 50 mb, ou seja, não dá pra deixar um filme inteiro lá para alguém baixar, você terá que quebrá-lo em vários arquivos menores. :-(
27 de março de 2009
Projeto Highlander - Parte II
Continuando nossa saga pelo projeto Highlander.....
Após nossa reunião de abertura, iniciamos nossos trabalhos de levantamento de requisitos, realizando as reuniões com os usuários chaves, coletando necessidades, documentos, montando atas de reunião.... e ai, vem o primeiro problema...
Quando se faz um projeto, que existe um escopo, a tendência normal (para não dizer a regra para gerenciar projetos) é segui-lo mas o cliente não entendeu muito bem o que era escopo. Os levantamentos seguiam uma lista de personalizações contratadas em escopo, mas o cliente não queria que fosse desta forma, mas que o levantamento fosse detalhando ao máximo todos os processos da empresa, praticamente, ignorando o escopo contratado.
Com 1 mes de projeto, o mesmo quase caiu por terra. A empresa (minha empresa) cedeu e assim, praticamente, abrimos o escopo do projeto.... só que detalhe.... o prazo se manteve (10 meses no total).
Regra número 1 para projetos de sistemas: nunca feche o escopo e dê um prazo antes de ter em mão os requisitos detalhados aprovados pelo cliente. Se depois de todos os requisitos aprovados, o cliente pede alteração, imagine antes disso....
Bom, até a próxima....
Após nossa reunião de abertura, iniciamos nossos trabalhos de levantamento de requisitos, realizando as reuniões com os usuários chaves, coletando necessidades, documentos, montando atas de reunião.... e ai, vem o primeiro problema...
Quando se faz um projeto, que existe um escopo, a tendência normal (para não dizer a regra para gerenciar projetos) é segui-lo mas o cliente não entendeu muito bem o que era escopo. Os levantamentos seguiam uma lista de personalizações contratadas em escopo, mas o cliente não queria que fosse desta forma, mas que o levantamento fosse detalhando ao máximo todos os processos da empresa, praticamente, ignorando o escopo contratado.
Com 1 mes de projeto, o mesmo quase caiu por terra. A empresa (minha empresa) cedeu e assim, praticamente, abrimos o escopo do projeto.... só que detalhe.... o prazo se manteve (10 meses no total).
Regra número 1 para projetos de sistemas: nunca feche o escopo e dê um prazo antes de ter em mão os requisitos detalhados aprovados pelo cliente. Se depois de todos os requisitos aprovados, o cliente pede alteração, imagine antes disso....
Bom, até a próxima....
24 de março de 2009
Projeto Highlander
Conheçam o projeto Highlander......
O projeto Highlander começou a uns 2 anos e 5 meses, por volta de novembro de 2006, iniciando o projeto tudo certinho, montando o plano do projeto (levamos 1 mês para montar o plano base do projeto). Seguimos todas as práticas do PMBOK, definindo escopo, prazo, premissas, restrições, riscos do projeto, plano de ação para caso o risco ocorresse, ou seja, ficou documentado tudo que iramos fazer e também não fazer (o mais importante na minha opinião, pois define os limites do projeto).
O prazo inicial do projeto era de 10 meses, aonde faríamos os levantamentos dos requisitos (4 meses), depois o desenvolvimento, testes de unidade, testes de integração, treinamentos, rodar em paralelo e por fim, implantar o sistema. Somando, deu cerca de 4000 horas de projeto (2000 só de desenvolvimento) com uma equipe de 4 pessoas, sendo uma delas um gerente.
Fizemos a reunião de abertura, chamamos os gestores de área e demos o ponta pé inicial no projeto, e já tínhamos um problema: o analista de sistema que faria os levantamentos, estava recém chegado à empresa, não conhecia nada do sistema nem da empresa e o seu primeiro dia foi na apresentação do plano do projeto para assinatura dos gestores (ele nem participou do planejamento).
Bom, apesar deste transtorno no inicio, começamos a fazer os levantamentos de requisitos... e ai começa a nossa novela.
Até mais.... no próximo post vou continuar a contar as sagas deste projeto....
O projeto Highlander começou a uns 2 anos e 5 meses, por volta de novembro de 2006, iniciando o projeto tudo certinho, montando o plano do projeto (levamos 1 mês para montar o plano base do projeto). Seguimos todas as práticas do PMBOK, definindo escopo, prazo, premissas, restrições, riscos do projeto, plano de ação para caso o risco ocorresse, ou seja, ficou documentado tudo que iramos fazer e também não fazer (o mais importante na minha opinião, pois define os limites do projeto).
O prazo inicial do projeto era de 10 meses, aonde faríamos os levantamentos dos requisitos (4 meses), depois o desenvolvimento, testes de unidade, testes de integração, treinamentos, rodar em paralelo e por fim, implantar o sistema. Somando, deu cerca de 4000 horas de projeto (2000 só de desenvolvimento) com uma equipe de 4 pessoas, sendo uma delas um gerente.
Fizemos a reunião de abertura, chamamos os gestores de área e demos o ponta pé inicial no projeto, e já tínhamos um problema: o analista de sistema que faria os levantamentos, estava recém chegado à empresa, não conhecia nada do sistema nem da empresa e o seu primeiro dia foi na apresentação do plano do projeto para assinatura dos gestores (ele nem participou do planejamento).
Bom, apesar deste transtorno no inicio, começamos a fazer os levantamentos de requisitos... e ai começa a nossa novela.
Até mais.... no próximo post vou continuar a contar as sagas deste projeto....
20 de março de 2009
O principio.....
Bom, esse é o primeiro post do primeiro blog que eu crio....
Quem sabe vou escrever toda semana, contando um pouco das histórias engraçadas, tristes e até mesmo inacreditáveis das coisas que vivi e vivo no dia-a-dia no trabalho....
Sabe como é, um profissional de TI tem muitas histórias e até se parece um pouco com pescador, mas acreditem.... essas histórias são reais.
Vocês vão ouvir falar muito das comicas histórias com usuários, colegas de trabalho, o projeto Highlander e outros fatos e aventuras "informatiqueses".
Bom, até mais... até o próximo post....
Quem sabe vou escrever toda semana, contando um pouco das histórias engraçadas, tristes e até mesmo inacreditáveis das coisas que vivi e vivo no dia-a-dia no trabalho....
Sabe como é, um profissional de TI tem muitas histórias e até se parece um pouco com pescador, mas acreditem.... essas histórias são reais.
Vocês vão ouvir falar muito das comicas histórias com usuários, colegas de trabalho, o projeto Highlander e outros fatos e aventuras "informatiqueses".
Bom, até mais... até o próximo post....
Assinar:
Postagens (Atom)