O que é Big Data e por que você deve se importar?

Escelente vídeo desenvolvido pela Forbes, utilizando LEGOS, explica o por que é importante se preocupar com o Big Data.

Você provavelmente já ouviu o termo “Big Data”, mas você sabe o que isso significa? Usamos alguns Legos para ajudar a explicar o que é e como as empresas estão usando para melhorar seu marketing.

Top 12 Prioridades para a Modernização do Data Warehouse

No artigo “Data Warehouse Modernization – In the Age of Big Data Analytics”, Philip Russom lista 12 prioridades para um projeto de modernização do Data Warehouse.

Think of the priorities as recommendations, requirements, or rules that can guide user organizations into successful strategies for implementing a modernization project. – Philip Russom

As 12 prioridades são:

  1. Embrace change;
  2. Make realignment with business goals your top priority;
  3. Make DW capacity a high priority on the technology side;
  4. Make analytics a priority, too;
  5. Don’t forget the related systems and disciplines that also need modernization;
  6. Don’t be seduced by new, shiny objects;
  7. Assume that you’ll need multiple manifestations of modernization;
  8. Know the tools and techniques of the modern data warehouse environment (DWE);
  9. Adjust the large-scale architecture of your DWE;
  10. Reevaluate your DW platform;
  11. Consider Hadoop for various roles in the DWE;
  12. Develop plans and recurring cycles for DW modernization.

O artigo completo, pode ser encontrado neste link https://tdwi.org/bpr/dwmodernization.

4 razões pelas quais sua implementação ágil não está funcionando

Em uma interessante postagem, Robert Pieper, descreve 4 razões pelas quais a implelemtação ágil pode não funcionar de maneira adequada.

  1. You’re not limiting risk
  2. Lead time
  3. Consistent cost overruns
  4. No one knows why

Agile frameworks are designed to help you be light on your feet, but they don’t promise you’ll succeed in using them as intended. – Robert Pieper

O post completo do Robert Pieper pode ser lido em: https://blog.scrum.org/4-reasons-agile-implementation-isnt-working/.

Segurança: análise de riscos (ISO/IEC 27002)

A análise de riscos é utilizada para identificar os riscos que a organização possui. Um risco, dano ou perda da informação é determinado pelas ameaças, ou melhor, a chance desta ameaça ocorrer e suas consequências.

Quando a ameaça se materializa, o risco se efetiva.

Vulnerabilidade – fraqueza, associada aos ativos da organização.
Ameaça – uma ocorrência; um fato; explora a vulnerabilidade

PROBABILIDADE é igual a uma CHANCE

Quanto MAIOR a Probabilidade MAIOR o Risco

Risco – é o potencial em que uma dada ameaça irá explorar as vulnerabilidades para causar perda ou dano imediato.

Gerenciamento de Risco – processo que trata as ameaças, riscos e medidas de segurança. É um processo contínuo na qual identifica, examina e reduz a um nível aceitável uma ameaça.

Os objetivos da analise de riscos, são:

  • Identificar ativos e valores;
  • Determinas as vulnerabilidades e ameaças;
  • Determinar os riscos e as ameaças que podem causar danos nos processos operacionais;
  • Determinar o equilíbrio entre custos de um incidente e custo das medidas de segurança.

Análise de Risco Quantitativa

Pretende calcular com base no impacto do risco, a perda financeira e a probabilidade de que uma determinada ameaça torne-se um incidente de segurança.
Os custos das medidas, não devem ser maiores que o valor do objeto a ser protegido do risco.

Análise de Risco Qualitativa

É baseada em cenários e situações. A chance é analisada com base nos sentimentos das pessoas.
Medidas podem ser tomadas para reduzir o risco residual a um nível aceitável.

Medidas para reduzir o risco

As medidas podem ser de redução da chance do evento ocorrer ou da redução de suas consequencias ou a combinação das duas.

Tipos de Medidas de risco

  • Redução: usada para reduzir ameaças;
  • Preventivas: usadas para prevenir incidentes;
  • Detecção: usadas para detectar incidentes;
  • Repressivas: usadas para parar as consequencias de um incidente;
  • Corretivas: usadas para recuperação de danos causados por um incidente.

Lições aprendidas, são realmente aprendidas pelas equipes?

Um item importante que existe em toda a empresa, mas é muito notório em projetos chama-se: “Lições Aprendidas”. Como o próprio nome diz, devemos aprender algo sobre algum item/entregável/status/comunicação/etapa do projeto que ocorreu durante alguma fase do projeto.

É através das Lições Aprendidas que podemos tornar recorrentes os resultados desejados; e impedir a recorrência dos resultados indesejados

Durante os últimos anos, pude participar de vários projetos, alguns com o escopo pequeno ou simples, outros complexos. Alguns com equipes formada por recursos juniores outros com equipes formadas por profissionais seniores e com grande experiência em sua área de conhecimento.

Em alguns projetos é obrigatório a entrega formal de um documento contendo todas as lições aprendidas pela equipe do projeto aos patrocinadores do mesmo.

Lessons Learned (original: http://www.thefreedomchase.com/wp-content/uploads/2014/04/Entrepreneurial-Lessons.jpg)Em todos os projetos, ocorreram situações onde uma resposta precisava ser aplicada, porém não tínhamos nos preparados para tal situação. Uma ação teve que ser tomada/executada e com isso um resultado foi obtido. Mas, se ocorrem situações em que não houve um planejamento prévio, significa que o planejamento falhou? Pode ser que sim, pode ser que não. Depende do caso…

Bom, mas o que devemos aprender com esta etapa do projeto que não deveria ser esquecida ou ignorada?

Entendo que podemos aprender a evitar que determinadas circunstâncias se repitam, isso vale para a mesma empresa ou não e/ou para projetos semelhantes. Não devemos ter como lições aprendidas a resposta para uma situação. Devemos usá-la como um conhecimento prévio, de modo que determinadas circunstâncias não ocorram novamente.

Escrever, relatar e documentar é algo que muitas empresas não identificam valor, pois a própria empresa não tem a cultura de documentar e ler. Logo, pra que escrever?! Entretanto, existem clientes que precisam saber o que o prestador do serviço aprendeu durante a execução do projeto.

Mas o que devemos levar em conta quando vamos listar/estudar as lições aprendidas?

Vejamos alguns exemplos:

  • O que aprendemos sobre o projeto em geral?
  • O que aprendemos sobre gerenciamento de projetos?
  • O que aprendemos sobre comunicação?
  • O que aprendemos sobre o orçamento?
  • O que aprendemos sobre como trabalhar com os patrocinadores?
  • O que aprendemos sobre como trabalhar com os clientes?
  • O que aprendemos sobre as atividades que ocorreram de forma como foram planejada?
  • O que aprendemos sobre as situações que não ocorreram de forma satisfatória?
  • O que aprendemos que devemos mudar?