Gerenciamento de Projetos

Há anos atrás (5 a 6 anos) eu recebi da Microsoft em parceria com Senac SP, um CD apresentando uma nova versão do Projetc MS e com ele um vídeo super instrutivo do pai dos Projetos, Ricardo Vargas, com o título “Construindo Resultados com Gerenciamento de Projetos”.

Apesar dos projetos sempre existirem (de uma forma ou de outra), não era como hoje… na época poucas empresas davam valores (reais) a atuação das boas práticas, técnicas e frames de Gerencimento de Projetos. Eu particularmente, já cheguei a ouvir de gerentes de TI que isto era mais um modismo.

O tempo passou e aí está a prova! Atualemnte é uma atividade natural dentros das empresas, mas que em minha particular opinião esta atividade não é uma rotina!

Hoje vemos inúmeras faculdades oferecendo cursos de pós e MBA na  área. E ao longo deste tempo percebi também que o número de vagas para área de gerenciamento de projetos cresceu e FOI (ESTÁ SENDO) RECONHECIDA!

Hoje a função de “Administrador/Gestor de Projetos”  é  de extrema importância nas empresas.

Não mais fazer por fazer e vamos ver o que dá.  Esta ação “de fazer e ver o que dá “… creio que não voga mais (no sentido de valer).  Envolve tempo, dinheiro, pessoas,criatividade, raciocínio, …

Gerenciar um projeto não é somente estar na frente de uma máquina (computador, notebook, …), abrir o Project da Microsoft (MSProject) ou Clarizen ou qualquer outro App de gerencimento de Projetos e sair digitando… é conhecer o negócio, é analisar os recursos, é orçar, é minimizar as margens de erro (riscos), é ouvir pessoas e ideias, é conversar e colher informações com responsáveis  e pessoas conhecedoras da essência do projeto…

Processar todos estes dados e gerar informações tangíveis. É criar e inovar com estas informações. E principlamente enxergar o cenário. O MSProject é apenas uma ferramenta.

É difícil! Pois nem sempre aquele molde já aplicado no projeto anterior servirá para o próximo projeto.

Mesmo porque cada projeto é um projeto. E,  em geral, o projeto é o ponto de partida daquilo que ainda não existe, mas que ao ver o escopo, a documentação e as ações deve dar uma visão real de como ele será.

Creio que sempre teremos que usar as normas, regras das melhores práticas adequando-as a cada tipo de projeto. Acho que a chave esteja aí. Não é fácil, mas também não é uma missão impossível, né?!

Particularmente, estou retomando tudo que aprendi anos atrás e alinhando as novas diretrizes, mas voltadas a projetos em TI e Administração, que são as minhas áreas. Gerenciar riscos, capital humano  e recursos alheios  é, a cada projeto, um desafio!

Enfim… na época, quando recebi este vídeo fiquei em “estado de graça“, encantada! Pois nunca havia visto um profissional falar com tamanha segurança, conhecimento e tamanha visão sobre projetos.

E assim, como Ricardo Vargas, sou da área de exatas (porém, Análise de Sistemas) e somos educados e treinados durante toda a vida acadêmica a sermos fazedores/executores, a realizar cálculos matemáticos, codificações em mil linguagens de programação, compilação do banco de dados, vetores, pipes, fazer aquela rotina ou aquele módulo a rodar… e não a planejar. Rede Pert e suas conexões (a fundo mesmo) só fui aprender na Pós na Fatec. E que com o tempo tentei entender um pouco mais sobre PMI.

O planejamento aprendi na raça, com o tempo, com alguns livros e conforme as atividades que surgiam nas empresas em que trabalhei. A lei do interesse e da sobrevivência 😉

Ps.: Hoje não sei se todas as faculdades na graduação incluem em sua grade, aulas dedidacas ao planejamento.

Bom … só acho que todos que estão envolvidos de alguma forma com gerencimento de projetos,  indiferente se você trabalha com TI, Engenharia, Logística, … deveria ver estes vídeos que são condensados mas que ajudam a ter a visão de “exercer projetos”.

Quando o assunto é Projetos… Deus no céu e Ricardo Vargas na Terra 🙂

Parte 1/3

Parte 2/3

Parte 3/3

Um abraço, 

Luciana

http://www2.imasters.com.br/perfil/luciana_costa

https://lucianacosta.wordpress.com

Anúncios

Programando em equipe – Parte2

Continunação

 

Programador procedural no mundo orientado a objetos:

* Reduza a visibilidade da classe – Nunca deixe público e exposto pela classe algo que somente está sendo usado por ela internamente (atributos e métodos). Quanto mais coisas públicas as classes possuírem, menos flexibilidade de manutenção ela terá.

* Use sobrecarga de métodos – Dê preferência à sobrecarga de métodos em vez de ficar implementando controle de lógica baseado na passagem de parâmetros.

* Longas listas de argumentos – Métodos com muitos parâmetros refletem em geral a falta de percepção de que está faltando a criação de um objeto que contivesse estes dados devidamente encapsulados, utilizado posteriormente como agregação.

* Classes sem métodos ou sem atributos – A classe é a expressão de um componente portador de características e comportamentos. Salvo em raros casos, na utilização consciente de design patterns.

* Reutilização de código – Na POO podemos reutilizar código de duas formas: por herança ou agregação. Sempre faça uma análise crítica no caso de qual utilizar, mantendo em mente de que a agregação é a forma mais flexível. Entretanto, existirão casos de herança (considere casos de classes abstratas). De forma alguma faça CTRL+C e CTRL+V nas classes por menor que seja a circunstância!

* Polimorfismo sempre – Use indiscutivelmente quando puder argumentos, variáveis, tipos de retornos polimórficos. Não existe nenhuma outra coisa na POO que ofereça mais flexibilidade e manutibilidade como a codificação polimórfica.

* Classes Enormes – Isso é uma das picaretagens mais feias que podem ser feitas contra o patrimônio OO!!! Nunca faça classes longas, cheias de métodos, resolvendo tudo……é o famoso canivete suíço. Passe um pente fino nas classes usando a SRP – Single Responsability Principle – na qual afirma que cada classe deve ser implementada para resolver apenas uma situação, uma responsabilidade! Busque a granularidade certa entres as classes do seu projeto, considerando, é claro, o escopo em questão.

* Métodos Enormes – Métodos grandes, cheios de controle de fluxo normalmente devem ser analisados e fracionados em métodos menores com visibilidades mais restritas.

* Abuso em Recursos Estáticos – Outra ofensa contra o patrimônio OO! Na POO não existem funções e variáveis globais perdidas no espaço mágico do mundo encantado! Tudo é objeto se relacionando com outro objeto através de seus estados e ações. Classes que apresentam abusos deste recurso expressam que o programador (autor) não conseguiu visualizar as abstrações e seus relacionamentos dentro do contexto da implementação. Recursos estáticos representam um escopo especial que é compartilhado por todos os objetos de uma classe e devem ser usados para satisfazer somente este caso.

* Nunca Reinvente a Roda – O Java tem 14 anos (desde 1995) de existência e apresenta uma série de recursos agrupados pelas plataformas. Fora isso, existem muitos produtos proprietários, open-source ou pagos e, por esse motivo, nunca tente elaborar ou inventar algo do zero antes de pesquisar a fundo! Porque na maioria dos casos você vai achar alguma coisa pronta (classe, componentes, framework, especificação, produto open-source ou proprietário pago com preço acessível) para resolver aquilo que você está necessitando!

* Encapsulamento – Sempre esconda as estruturas internas de uma classe e controle o acesso ao estado dos objetos através do encapsulamento usando a padronização JavaBean.

* Implemente as Regras Arquiteturais – Se uma classe é a última da hierarquia, declare como final!! Se um método não pode ser anulado, declare com final! Se um argumento ou variável não deve ser mudado, declare como final etc… Ou seja, impeça ou force polimorfismo, libere ou restrinja visibilidades em herança ou agregações. Entenda seu domain model e expresse-as no modelo de classes!

* Ciclo de vida dos objetos – Sempre programe pensando em cooperar com o coletor de lixo!! Ou seja, analise bem os escopos de criação dos objetos (estático, instância ou local) e os libere (atribuindo null para as referências) logo após verificar que não irá mais utilizá-los. Perceba que esta prática deixa o código claro e legível.

* Modere a Criação de Objetos – Sempre seja moderado na criação de objetos, nunca criando mais do que você precisa, sendo que o coletor de lixo é muito eficiente, mas não faz milagres. Quando possível, tente reusar os mesmos objetos reiniciando-os ao seu estado inicial. Analise cada new que você declarar!! Em aplicações de médio/grande porte isso pode resultar em uma grande economia e conseqüentemente performance.

Controlando condições excepcionais:

* Controle de Erros – Nunca use como controle de erros com retorno de booleano ou códigos de erros! Em Java existe uma mecânica padronizada chamada de tratamento de exceções. Lance exceções indicando as condições excepcionais, usando classes existentes no core do JSE ou não tenha receio de criar as suas próprias quando necessário.

* Propagação de Exceções – Nunca propague uma exceção ocorrida de dentro de uma camada lógica para fora da mesma, sendo que a outra camada cliente não deve conhecer detalhes internos de execução. Neste caso propague outras exceções mais significativas referentes ao contexto da camada/componente/classe ou serviço.

* Exceções Polimórficas – Nunca use o tratamento de exceções de forma polimórfica! Sempre encadeie os catch de todas as exceções, deixando o código claro e legível para o próximo programador amigão do peito!

* Comendo Exceções – Nunca faça um try sem colocar nada no catch! No mínimo, tem que existir uma impressão da lista do trace ou substitua, se possível, o try por um if identificando a condição.

* Fluxo de Controle em Exceções – Nunca use um try/catch como fluxo de controle!! Ou seja, não baseie nenhuma lógica condicional no controle de exceções. O próximo programador agradece a legibilidade do seu código.

Bom, pessoal, estas foram as “pérolas” que eu já peguei espalhadas por ai! A área de comentários fica livre para quem quiser complementar ou dar sua opinião. Para quem deseja realmente ter uma boa base sobre o assunto, sugiro a leitura e a prática do Java Code Convention e o livro Head First OOA&D – (em português Análise e Projeto Orientado a Objetos). 

fonte: fernando franzini – imasters

:: LUCIANA COSTA ::

Programando em equipe – Parte1

O desenvolvimento de um software consiste em um grupo de pessoas manuseando os mesmos arquivos fontes e componentes. Se um indivíduo deste grupo não conseguir escrever a sua parte de forma clara, de fácil compreensão e manutenção, o projeto estará comprometido a uma série de conseqüências problemáticas. Entendo que isso é uma situação de peso, uma vez que a manutenção representa em média 80% do tempo de vida de um sistema.

Ao longo das consultorias em projetos de que venho participando, diagnostiquei que os programadores em geral não sabem o significado de se “Programar em Equipe”. Percebo que é um problema de nível cultural e acredito que isso possa ser revertido se cada um pensasse da seguinte forma:

Eu estou trabalhando em uma equipe, por isso eu tenho que me esforçar ao máximo para implementar este requisito da forma mais simples, clara e de fácil manutenção possível…porque haverá algum momento no ciclo de vida do desenvolvimento que um companheiro de equipe precisará alterar ou complementar o que eu fiz e inevitavelmente eu também precisarei manusear algum código que foi construído por outra pessoa.

Acredito que o fato acontece por 3 motivos:

  • Pessoas remanescentes de outras tecnologias/ferramentas nas quais não existiam esta filosofia.
  • O desconhecimento de que na tecnologia Java existe um padrão de codificação.
  • A falta de uma sólida base de princípios de projeto orientado a objeto.

1. Pessoas remanescentes de outras tecnologias/ferramentas nas quais não existiam esta filosofia:

Eu percebo que atualmente existe uma galera muito inteligente e esforçada que vem migrando de outras tecnologias para o Java e que realmente tem conseguido produzir softwares funcionais, entretanto 100% deles deixam muito a desejar neste ponto. Percebo que o pessoal traz seus costumes e hábitos de programação para dentro do Java.

2. O desconhecimento de que na tecnologia Java existe um padrão de codificação:

Em Java existe uma forma padrão de como se deve ser escrito um código fonte. Ou seja, o autor não tem a liberdade de ficar usando/inventando uma série firulas, gafs, comentários, regras de espaçamentos sem coerências, delegação de nomes para identificadores completamente malucos etc….. Existe um documento chamado “Java Code Conventions” que possui todas as regras e diretrizes previamente estudadas e estabelecidas para que qualquer pessoa em qualquer lugar no mundo possa escrever o mesmo código fonte. Isto quer dizer o que? Quer dizer que uma pessoa de um lado do mundo pode abrir o código fonte de uma outra pessoa, do outro lado e ter a sensação de que ela mesma que escreveu! Sendo que ambos devem seguir a convenção de codificação.

3. A falta de uma sólida base de princípios de projeto orientado a objeto:

Fácil manutenção está intimamente ligada à utilização de princípios e diretrizes da filosofia orientada a objetos e é aqui onde o galera mais deixa a peteca cair! Como é incrível ver o pessoal mesmo usando uma tecnologia OO conseguir programar usando conceitos procedurais/globais e fazer uma coisa simples OO virar um monte de macarrão trançado. Sempre lembrando que a POO é uma filosofia e pode ser furada fácil, fácil, em qualquer parte do projeto.

Segue abaixo a lista resumida dos erros mais comuns:

* Estado do objeto – Não use variáveis de instâncias para controle de fluxos locais! Variável de instância é usada para definir estado do objeto durante seu ciclo de vida. Caso precise controlar algo localmente, use variáveis locais.

* Declaração de variáveis – Somente declare e inicialize as variáveis locais antes (o mais próximo o possível) de serem usadas! Único momento onde é aceitável declarar uma variável muito longe de sua utilização é em caso de utilização fora de escopos de controle de fluxo ou loop. Mesmo assim, mantenha em mente que você deve declarar sempre o mais perto possível.

* Escopo de variáveis – Sempre reduza os escopos das variáveis o máximo possível! Nunca declare uma variável fora de um escopo lógico (while, if, do/while, for) se você só vai precisar da variável dentro dele.

* Nomeação de variáveis – Independente do seu escopo (instância ou local), os nomes das variáveis devem ser auto-explicativos! Não coloque nomes sem sentido ou com apenas um caractere! Único lugar aceitável para se colocar uma variável com um único caractere é no contador de um for, o resto tem que possuir um nome significativo dentro do contexto de implementação. Outra coisa, não faça nomes grandes demais, resuma ou procure um sinônimo menor.

* Nomeação de classes e métodos – Nome de classe geralmente é um substantivo que reflete a abstração da automação de alguma coisa do mundo real, e os nomes dos métodos devem ser verbos que refletem ações que um objeto da classe faz. Qualquer coisa que passar disso fará com que o projeto fique completamente ilegível e confuso! Única possibilidade de exceção a este caso seria a possível utilização de design patterns dentro da arquitetura.

fonte: fernando franzini-imasters

:: LUCIANA COSTA ::

Parceria SERT e SENAI

Olá Pessoal,

 

Sempre digo que quem tem informação… tem poder. Quem tem conhecimento… consegue enxergar novas portas e gerar novas oportunidades.

A SERT em parceria com a rede SENAI e SENAC está oferencendo opotunidades e novos horizontes a quem busca uma recolocação no mercado de trabalho.

E desde outubro (com imenso prazer) faço parte deste mega projeto.

🙂

Mega em todos os sentidos! 😉

Um projeto que não é apenas papel. É estratégia! É ação!

(digo com certeza, pois estou envolvida diretamente nele – E RELATO AOS PROJETOS QUE ESTOU ENVOLVIDA!)

Foi primeiramente planejado todo um escopo didático (planejamento, profissionais, material didático e material de apoio, …) cujo objetivo é preparar as pessoas para as novas exigências do mercado e reflexos da globalização.

Os alunos possuem aulas de Habilidades Gerais e Habilidades Específicas. Onde uma habilidade complementa a outra habilidade.

E imagine! Esta soma já está colhendo resultados produtivos e já podemos sentir alguns resultados iniciais com a formação das primeiras turmas (INF 1 a 7) -> Trabalhamos não apenas para treiná-los e sim capacitá-los, no quesito pessoa, profissional, perfil, entre outros pontos que nós trabalhamos em sala.

Eu (Profª Luciana) trabalho junto aos alunos desenvolvendo as Habilidades Específicas (área de tecnologia- Informática)- > que envolve a capacitação e desenvolvimento de perfil técnico para habilitá-los ao mercado de trabalho.

Porém, em Habilidades Gerais, contamos com o apoio e experiência de nossas amigas profissionais (Rosa e Cris) que dão todo o embasamento para desenvolvimento do auto-conhecimento, do  senso-crítico, auto-imagem de nossos alunos/profissionais.

E sabe o que é mais interessante nisto?

É perceptível que os profissionais envolvidos no front-job (Eu, Vania, Rosa, Cris) não estamos apenas em prol a um projeto e sim estamos envolvidas de corpo-alma e coração. 

O quanto isto é bom? Nem precisa responder, né?!

O sorriso responde, os shows em sala de aula respondem, o desempenho dos treinandos respondem! E os resultados… são visíveis! Mas sempre digo a cada treinando… que eles devem estar abertos a receber um leque (imenso) de informações que vão ajudá-los na vida profissional e pessoal.

É uma soma! E toda soma deve ser uma VITÓRIA! É esta sementinha que planto a cada dia. Assim espero que todos os treinandos (alunos) entendam cada palavra nossa, cada atividade, cada observação, pois como digo: “O currículo deles é o nosso currículo, portanto, plantamos neste período sucesso” -> O sucesso deles é o nosso sucesso!

Pois é, vamos plantando as sementes para que elas tornem grandes árvores, fincadas com raízes extensas e firmes e cheia de frutos.

( https://lucianacosta.wordpress.com/2009/01/27/turma-inf2-parabens/)

Prosperidade a todos!

:: LUCIANA COSTA ::

 

 

 

 

Novidades para 2009

Olá pessoal,

Novas no ar!

Pois é estamos chegando ao fim do ano de 2008. Hoje já é 1º de dezembro, mais alguns dias… e pronto… já estaremos no ano de 2009.

Fazendo uma retrospectiva até a presente data: não tenho do que reclamar. Foi um ano brilhante. Imaginei (e planejei ser um ano de adaptações, experimentações, …) e foi além do que planejei. Isto é ótimo!!! Inclusive tive que readaptar projetos para atender a nova demanda provocada pelo fator mercado de trabalho durante os último 8 meses. Maravilha!!!

Sinônimo de que o planejamento estava encaixado e bem projetado.

Bom, como estava falando… 2009 está chegando, porém é durante o ano anterior que devemos fazer novos planejamentos e projetos visando estratégias e ações para o próximo ano. Importante também fazermos o estudo de orçamentos, impostos, custos e porque não a santa margem de lucro 😉

Afinal somos filhos de Deus e merecemos ter algum retorno, né?!

Com o foco voltado para o planejamento de projetos do próximo ano, dentre vários deles (por enquanto) em planilhas e arquivos no momento, um já encontra-se em andamento na qual já me permite aprensentá-lo :

-> o nosso site que está em desenvolvimento ->  LUCIANACOSTA.COM

Isto mesmo, sem o Br.

Sairá do forno, quentinho para inauguração prevista a partir de 05/01/2009.

 

Agora com domínio próprio teremos mais conteúdo, maior flexibilidade, fórum,  dentre outras tecnologias afim de propagar informação.

De ante mão já comunico que nosso e-mail também mudou para : contato@lucianacosta.com

Pois é!  Projetos mil.

:: LUCIANA COSTA ::