Gestão de projetos: fórmula para inovar com foco, prazo e resultados

Publicado: Quarta-Feira, 21 de Maio de 2008 10:54

Gestão de projetos: fórmula para inovar com foco, prazo e resultados

Muitas empresas prestadoras de serviços trabalham basicamente com projetos, mas carecem de uma metodologia que lhes assegure os resultados planejados

Cada vez mais as organizações colocam a visão taylorista tradicional de lado e assumem uma posição mais inovadora, seja com base em processos ou em projetos. Muitas empresas prestadoras de serviços trabalham basicamente com projetos, mas carecem de uma metodologia que lhes assegure os resultados planejados.Aquelas que perceberam que o desenvolvimento de projetos, quando realizado com base na experiência, resulta na maior parte dos casos em desperdício de tempo e recursos, iniciam uma busca por alternativas de trabalho mais produtivas e eficientes. O desenvolvimento de uma metodologia de gerenciamento de projetos surge assim quase como uma obrigação na busca de eficiência e resultados.

Afinal, o que é um projeto? Segundo o PMI (Project Management Institute), projeto é um esforço temporário para criar um produto, serviço ou resultado exclusivo. Se ele é temporário, tem início e fim definidos antes do início de sua execução. Dada a natureza de incertezas e indefinições, próprias da atividade de projeto, a sua segmentação em etapas ou fases é um recurso prático fundamental para melhorar a capacidade de gerenciamento e aumentar a taxa de sucesso do projeto. É preciso notar que mesmo com muitas semelhanças, os resultados dos projetos apresentam diferenças.

Uma metodologia de gerenciamento de projetos traça o caminho entre a concepção do projeto e a sua entrega. Ela serve como uma estrada muito bem sinalizada para o gerente de projeto e sua equipe, revelando o que deve ser feito e como ser feito. Uma metodologia de gerenciamento de projetos, como qualquer metodologia de trabalho, se fundamenta em três elementos. O primeiro deles são os processos, ou seja, o conjunto de passos e/ou atividades que ordenam e estruturam o trabalho a ser realizado. Eles podem estar organizados de várias formas, mas normalmente relacionam-se à cronologia a ser seguida. Após, temos as ferramentas de suporte, ou tecnologia, softwares,etc. Em terceiro lugar, vem os padrões, que são formulários, relatórios e controles.

By Paula Zygielszyper

Afinal o que é Segurança da Informação?

Vamos iniciar informando o que não é – não é somente fazer segurança contra hakers, vírus e assemelhados, roubo de informações, e invasão de privacidade. É exclusivamente isto que a maioria das empresas entende como segurança da informação. Contratam um técnico de informática especializado neste aspecto da segurança (muitas vezes é o mesmo técnico ou a mesma empresa que instalou o sistema de segurança ou a rede) para fazer o diagnóstico e indicar / implementar dispositivos e procedimentos para a segurança do ambiente informatizado. Este procedimento implica em duplo risco: 1) põe a raposa a cuidar do galinheiro e 2) não tratam dos demais riscos que ameaçam as informações.

A Segurança da informação é garantir que as informações (em qualquer formato: mídias eletrônicas, papel e até mesmo em conversações pessoais ou por telefone) – estejam protegidas contra o acesso por pessoas não autorizadas (confidencialidade), estejam sempre disponíveis quando necessárias, e que sejam confiáveis (não tenham sido corrompidas ou adulteradas por atos de pessoas mal intencionadas).

Para que haja segurança das informações primeiramente deve ser feita uma Análise de Risco que identifique todos os riscos (vulnerabilidades + ameaças) que ameacem as informações, considerando três categorias básicas – riscos administrativos, físicos e tecnológicos.

Identificados os riscos, o relatório da Análise de Risco deve apontar as soluções que eliminem, minimizem ou transfiram os riscos. É importante lembrar que não se consegue eliminar 100% dos riscos, e aqueles que não são elimináveis devem ser gerenciados para que, ocorrendo um evento que ameace as informações, providências sejam tomadas objetivando garantir, a partir de procedimentos de contingência, a disponibilidade das informações e a continuidade dos processos críticos do negócio.

Finalmente, a alta administração da empresa deve avaliar o relatório da Análise de Risco, e a partir do conhecimento das ameaças e vulnerabilidades, devem decidir, considerando o custo x benefício, quais riscos que devem ser eliminados, quais as providências para minimizar outros e finalmente quais os que devem ser transferidos para terceiros (p.ex. comprar cobertura por seguro e/ou fazer outsourcing).

Como pode ser entendido pelo acima, a segurança da informação é assunto estratégico e deve ser tratado no nível apropriado da organização que é a alta administração (sócios proprietários e/ou diretoria executiva). Não deveria ser simplesmente delegada ao nível tecnológico operacional, o qual tem papel relevante, mas não é boa prática que tome decisões estratégicas que envolvam a Tecnologia da Informação e a continuidade dos negócios.

Victor Antonio Izquierdo é sócio proprietário da ALLSecurity

 

 

 

O Google e a segurança da informação

Há quase dois meses perguntei se você confiaria seus dados ao Google. O motivo era o lançamento do Google Apps for Your Domain, uma suíte destinada às pequenas e médias empresas, que inclui ferramentas básicas de office, calendário e email. O fato desses serviços serem on-line significa manter informações e documentos nos servidores do Google. Eis que de lá pra cá algumas coisas aconteceram. Nenhuma relacionada a esses serviços, mas ao Blogger, ferramenta para publicação de blogs da empresa. Portanto a pergunta continua em pé: você confiaria seus dados ao Google?

 

Blogs do Google hackeados

No dia 7 de outubro, um Sábado, um post apareceu no blog official do Google. Dizia que o inovador serviço de anúncios Click-to-Call, em testes, havia sido cancelado. A blogosfera estranhou, fez algumas suposições durante o fim-de-semana, até que no domingo o post foi tirado do ar.

Este mesmo blog oficial do Google foi acidentalmente apagado em março deste ano. Um leitor, ao descobrir que o endereço do blog estava disponível, recadastrou e colocou uma mensagem no ar. Sorte do Google que esse leitor foi simpático e postou uma mensagem alertando a empresa de que algo de errado tinha acontecido com o blog deles. Logo depois o Google recuperou o backup, voltando ao ar com uma mensagem explicando o acontecido.

Essa semana novamente problemas com os blogs oficiais do Google. O Buzz Blogger, blog que fala sobre o serviço Blogger mostrou uma mensagem um tanto estranha que mais tarde, informaram, foi um engano de algum funcionário da empresa que postou, sem querer, mensagem que deveria ir para o blog pessoal desta pessoa.

 

Segurança da Informação

O que houve nos três casos foram falhas na política de segurança da informação do Google. A definição da segurança da informação diz, segundo a Wikipedia: “Proteger sistemas de informação contra acesso não autorizado, modificação da informação, tanto no armazenamento, processamento ou manipulação(…)”. Fica claro que houve falhas.

A missão do Google é organizar toda informação do mundo, tornando-a amplamente disponível, algo assim. E nós ajudamos ao usar o Gmail, o serviço de Buscas, os orkut, o Google Docs, o Analytics, etc… tudo faz parte de um processo maior que é descobrir hábitos das pessoas e lhes oferecer buscas e anúncios mais relevantes. O perigo está em disponibilizar essas informações para o Google e no dia seguinte descobrir que, por falha na segurança da informação, os dados tornaram-se públicos.

 

Leituras relacionadas

·         Google Apps e a segurança da informação

·         Problemas de segurança atacam o Google

·         O Facebook e a privacidade

·         Fique bem na foto pois ela sempre vai existir

·         Google é um spyware?

By Alexandre Fugita - Techbits (http://techbits.com.br)

Gerenciamento de Projetos

Gerenciamento de Projetos refere-se à definição, planejamento, coordenação, controle e conclusão de projetos. “É uma ciência porque conta com técnicas e processos aprovados e repetitivos para se obter sucesso nos projetos. Gerenciamento de Projetos também é uma arte, porque envolve gerenciamento das pessoas e requer habilidades de intuição para ser aplicada em situações totalmente únicas para cada projeto.” Em outras palavras, gerenciar um projeto significa fazer o necessário para completá-lo dentro dos objetivos estabelecidos

É importante reconhecer que todo tipo de projeto necessita de certo nível de gerenciamento. Quanto maior e mais complexo for um projeto, maior será a necessidade do processo formal, estruturado e padronizado Pequenos projetos necessitam de um processo estruturado, mas não necessitam ser igualmente elaborados ou complexos. Obviamente, existe um custo associado ao esforço de gerenciamento de projetos, entretanto, os benefícios obtidos excedem os custos empregados na tarefa de gerenciamento. Destacamos os seguintes:

• Evita surpresas durante a execução dos trabalhos;
• Permite desenvolver diferenciais competitivos e novas técnicas, uma vez que toda a metodologia está sendo estruturada;
• Antecipa as situações desfavoráveis que poderão ser encontradas, para que ações preventivas e corretivas possam ser tomadas antes que essas situações se consolidem como problemas (pró-atividade);
• Adapta os trabalhos ao mercado consumidor e ao cliente;
• Disponibiliza os orçamentos antes do início dos gastos;
• Agiliza as decisões, já que as informações estão sendo estruturadas e disponibilizadas;
• Aumenta o controle gerencial de todas as fases a serem implementadas devido ao detalhamento ter sido realizado;
• Otimiza a alocação de pessoas, equipamentos e materiais necessários;
• Documenta e facilita as estimativas para futuros projetos;
• Traz a cultura de captar lições aprendidas em projetos anteriores, o que leva invariavelmente a um grande ganho tanto em eficiência como em eficácia na condução de novos projetos.

Importância do Gerenciamento de Projetos

Empresas de todos os setores da economia vêm reconhecendo a importância do gerenciamento de projetos para o sucesso de suas iniciativas. O desenvolvimento de novos produtos, serviços, criação de novas unidades de trabalho, entre outras, todas elas são melhor gerenciadas e produzem melhores resultados quando conduzidas sob a forma de projetos.

Adotar uma forma de organização por projeto e seguir uma metodologia específica de gerenciamento de projetos é de fundamental importância para as organizações se tornarem competitivas frente a grande concorrência que enfrentam e para conseguirem alcançar com sucesso suas metas estabelecidas de custo, prazo e qualidade.

Vale ressaltar que ter boas habilidades no gerenciamento de projetos não significa a inexistência de problemas e o desaparecimento de riscos e surpresas. Neste sentido, um bom gerenciamento de projetos apresenta processos padronizados, elaborados para lidar com qualquer tipo de contingência.

 

 

 

 

20 práticas para aumentar a maturidade de desenvolvimento de software do seu time

Entregar sistemas de software não é uma arte. É uma complexa ciência que requer, dentre vários outros fatores, muito estudo. Para apoiar neste aspecto, compilo artigos que me muito me ajudaram nos últimos anos, escritos por “mestres” na arte de desenvolver sistema e que são uma eterna fonte de inspiração.

1.     Processos ágeis – The Seven Habits of Effective Iterative Development

2.     Projetos Iterativos – Planning an Iterative Project e Iterative Development

3.     Bom planejamento de Projetos – Project planning best practices

4.     Gerência de Riscos – Gambling with Success: Software Risk Management

5.     Estimativa de Tamanho de Software – Estimating Software Development Effort based on Use Cases – Experiences from Industry

6.     Modelagem de Negócios – Effective Business Modeling with UML: Describing Business Use Cases and Realizations

7.     Gerência de Requisitos – So You Want to be a Requirements Analyst? e The Five Levels of Requirements Management Maturity

8.     Modelagem de Casos de uso – Why Use Cases Are Not Functions, Features, Requirements, Use Cases, Oh My e The Top Ten Ways Project Teams Misuse Use Cases – and How to Correct Them.

9.     Escrita Estruturada de Regras de Negócio – Business Rule Overview e Business Rules.

10.  Especificação de Glossário de Termos – Glossary Overview.

11.  Mapas de Navegação e Prototipação – User experience storyboards: Building better UIs with RUP, UML, and use cases.

12.  Análise Robusta e Modelagem de Domínio – Robustness Diagram Overview e Driving Design: The Problem Domain.

13.  Modelagem Arquitetural – Reference Architecture: The Best of Best Practices e Capturing Architectural Requirements.

14.  Modelagem de Estruturas de Análise e Desenho – Driving Design: The Problem Domain

15.  Modelagem Comportamental – Sequence Diagrams: One Step at a Time

16.  Mapeamento Objeto Relacional – The Object-Relational Impedance Mismatch.

17.  Gerência de Mudanças – Software Change Management.

18.  Gerência da Qualidade – Software Quality at Top Speed e Determining Your Project’s Quality Priorities

19.  Desenvolvimento Centrado em Testes Generating Test Cases From Use Cases, Test-Driven Development.

20.  Refactoring e Testes de Unidade – Refactoring, a first example.

By Marco Mendes´s Blog

 

 

 

Matar um Elefante é Facil. Difícil é remover o cadáver!

Observo, com cada vez maior frequência e mais preocupação, a baixa importância dada a gerência de riscos em projetos de TI. A gerência de riscos é um dos princípios chave do RUP e de vários outros processos de software. Apesar disso, observo riscos de toda sorte que surgem, crescem, tomam proporções gigantescas e levam a equipe a níveis de stress e desespero.

A gerência de riscos pode parecer assustadora, mas pode ser realizada em passos simples. Considere um projeto de TI qualquer. Podemos dividí-lo em quatro marcos, associados a zonas de riscos.

• Riscos de Viabilidade – Devem ser mitigados até 10% do prazo de um projeto.
• Riscos de Colapso Arquitetural – Devem ser mitigados até 30% do prazo de um projeto.
• Riscos Logísticos – Devem ser mitigados até 50% do prazo de um projeto.
• Riscos de Entrega – - Devem ser mitigados até 70% do prazo de um projeto.

Os riscos de viabilidade surgem quando o gerente ignora leis fundamentais de estimativas na organização do escopo, prazo, custo, qualidade e riscos na iniciação de um projeto. Diversos projetos são fechados com escopos não realizáveis nos prazos, custos e qualidade acordados. A consequência é na maior parte das vezes a qualidade, dado que alguma variável tem que ceder. Por exemplo, observações exaustivas de Barry Boehm mostram que comprimir um cronograma em mais que 25% do seu cronograma nominal é estatisticamente inviável. Diversas outras observações de Frederik Brooks, em seu clássico livro “The Mythical Man-Month”, mostram que adicionar pessoas a um projeto já atrasado também não funciona. Uma excelente fonte de consulta e aprendizado sobre este tema e o livro “Software Estimation – Demystifying the Black Art“, do autor Steve McConnel. Um artigo rápido sobre este tema é Something’s Gotta Give, do autor Scott Ambler. O resumo aqui é: Se um projeto mostra-se inviável em suas variáveis básicas (qualidade, riscos, escopo, prazo e custo), nao o traga para casa. Dizer NÃO ao final da iniciação de um projeto não deveria ser uma vergonha. Muito pior é perceber dez meses depois que o projeto foi cancelado pelo cliente depois de milhares ou centenas de milhares reais gastos.

Dado que um projeto seja viável, temos que torná-lo livre de riscos técnicos. Para isso, gerentes não podem ignorar que todo projeto merece uma arquitetura executável. Para isso, devemos priorizar os requisitos mais importantes do usuário e de maior dificuldade técnica e gerar códigos que os realizem, em conjunto com todos os requisitos não-funcionais críticos de um sistema. Nunca devemos começar por cadastroa CRUD, dado que isso apenas adia os riscos dos riscos de integração, desempenho, usabilidade, segurança e especialmente de mudanças de escopo. Concentrar a energia central no mais crítico antecipa riscos e promove um mecanismos saudável de mitigação dos mesmos. Nesta fase, o projeto ainda deve ter poucas pessoas, dado que o ambiente está instável. Recomendo, em particular, um excelente artigo de um dos pais do RUP (Phillippe Kruchten) — Common Misconceptions about Software Architecture para removermos mal-entedidos sobre a palavra arquitetura. Exemplos de colapsos arquiteturais são banco de dados ou servidores Web que não escalam ou descobertas tardias que a aplicação não opera em um browser não identificado. Em resumo, para evitarmos um colapso arquitetural devemos implementar e testar entre 5 e 20% dos requisitos mais críticos para termos um arquitetura executável (fundação) que sustente os vintes andares de código que nos aguardam.

Dado que a base técnica do projeto tenha sido criada, é hora da economia de escala. Neste ponto, podemos ter vários desenvolvedores operando em paralelo (como uma linha de montagem) para implementar os diversos casos de uso de um sistema. Entretanto, antes devemos preparar a logística de operação do time. Temos já um líder técnico de desenvolvimento para suporte imediato às dúvidas do time? Temos um processo de micro-gerência nas mãos? Temos um criterioso processo de controle de mudanças definido? Temos ferramentas de micro-gerência como o Mylin para controle fino do tempo gasto por cada desenvolvedor? O ambiente e políticas de gerência de configuração está estável? Conheci (e conheço) gerentes ingênuos que fizeram (e ainda fazem) a alocação de várias pessoas ao projeto sem ter respondido a estas questões. O resultado é ….caótico. Tarefas redudantes, re-trabalho, conflitos no versionamento do código, equipes estressadas e outros sintomas se manifestam.

Finalmente, se o gerente conseguiu chegar até aqui, ele deve se preparar para os riscos de entrega do produto. Um plano de implantação foi definido? Os usuários chaves foram envolvidos? Os ambientes de teste integrado, homologação e produção foram corretamente desenhados e testados? Critérios claros de aceite como percentual mínimo de cobertura de código em testes integrado, curvas de tendência de defeitos ou mecanismos de operação da aplicação da produção foram pensados? Novamente o gerente deve estar atento a estes detalhes para evitar a morte do projeto quase na sua entrega. Uma leitura chave para este processo é o excelente livro do autor Scott Ambler chamado The Unified Process Transition and Production Phases : Best Practices in Implementing the UP.

Afinal, matar um elefante é fácil, mas…

By Marco Mendes´s Blog