Sesión 7 y 8 – Data Driven

Mg Renzo Roca Ramos

1
 Data Driven

• Las empresas Data Driven están basadas en la

información y los datos son el centro de todos sus
procesos y de su toma de decisiones.

Datalake
•
–
El uso masivo de datos les proporciona una mejora en
la toma de decisiones, posicionamiento de mercado y
Rolesrentabilidad.
y
Acceso
• Las principales ventajas son: – Desarrollar una cultura
más innovadora y analítica – Mejorar e innovar en
nuevos productos y servicios – Incrementar la
penetración en el mercado – Consolidar información –
Optimizar procesos existentes y reducir coste
 Data Driven

Datalake –
Roles y
Acceso
Datalake –
Nuevos roles y
RolesFunciones
y
Acceso
Diseño de una Plataforma de Datos
Gestión de Proyectos de
Data
Introducción y
visión global
 Proyectos
Operaciones y
Producto
El ciclo de vida de un proyecto
Etapas del ciclo de Proyecto de Data
Evaluación del caso empresarial
Identificación de datos

Adquisición y filtrado(filtering) de datos

Extracción de datos
Validación y limpieza(cleansing) de datos
Agregación y representación de datos
Análisis de datos(DataAnalysis)
Visualización de datos
Usos de los resultados del análisis
 Etapa 1: Evaluación del Caso Empresarial

Todo Ciclo de vida de analisis de Big data debe comenzar con un alcance empresarial bien definido y un
entendimiento claro de la Justificación, Motivación y Metas de la ejecución del análisis.

En la etapa de evaluación del caso empresarial es necesario Crear, Evaluar y Aprobar un caso empresarial antes de
proceder con las tareas reales y prácticas de análisis.

La evaluación de un caso empresarial de análisis de Big Data ayuda a las personas encargadas

de Tomar las Decisiones a entender los Recursos Empresariales qué se necesitarán y a

saber qué retos empresariales se enfrentaran durante el análisis.

La identificación más detallada de los KPI durante esta etapa ayuda a determinar los
objetivos y alcanzar las metas

Para que un problema empresarial sea considerado un Problema de Big Data, debe estar
relacionado con una o más caracteristica de Big Data.

Otro resultado de esta etapa es la Determinacion del Presupuesto necesario para llevar
acabo el proyecto de analisis.
 Etapa 2: Identificación de Datos

La etapa de identificación de datos esta orientada a identificar los datasets

necesarios para el proyecto de análisis, así como las fuente de los mismos.

Identificar una amplia variedad de Fuentes de Datos puede aumentar la

probabilidad de encontrar Patrones y Correlaciones ocultos.

Los datasets requeridos y sus fuentes pueden ser internos o externos de la

empresa .

Datasets Internos : Se compila y combina una Lista ( Data Marts y Sistemas

Operacionales )
Dataset Externos : Se compila y combina una Lista de posibles proveedores
externo de datos ( Mercado de Datos )
 Etapa 3: Adquisición y Filtrado(filtering) de Datos

Se recopilan los datos de todas las fuentes de datos identificadas en la

etapa anterior, luego, los datos son sometidas al filtrado (filtering)
automático de Datos Corruptos o Datos Sin Valor para los objetivos del
análisis.
Los Datos Clasificados como Corruptos pueden incluir registros de valores
faltantes, sin sentido o tipos de datos inválidos.
Tanto los Datos Internos como Externos deben ser guardados una vez que
se generan o entran en la empresa.
Para los Análisis por Lotes, los datos se guardan antes del análisis.
En el caso de Analisis en Tiempo Real, los datos primero son analizados, y
luego guardados en disco.
 Etapa 3: Adquisición y Filtrado(filtering) de Datos

Se agrega metadata a los datos provinientes

de fuentes Internas y Externas
 Etapa 4: Extracción de Datos

La etapa extracción de datos, esta orientada a extraer distintos

datos y a convertirlos en un formato que la solución subyacente de
Big Data pueda usar para el análisis de datos.

El alcance de la extracción y la conversión requeridas dependerá

de los tipos de analíticas y las capacidades de la solución de Big
Data.

La extracción de datos es una actividad de recuperación de datos

con el objetivo de obtener o extraer información estructurada o
semiestructurada
 Etapa 4: Extracción de Datos

En palabras resumidas, la extracción de datos es una actividad de recuperación de datos con el objetivo

de obtener o extraer información estructurada o semiestructurada desde

documentos legibles por una computadora para luego ser utilizados con X oY finalidad.
 Etapa 5: Validación y Limpieza (cleansing) de Datos

Los Datos inválidos pueden producir sesgo y errores en los resultados de

los análisis. Los datos de entrada del Análisis de Big Data pueden no estar
estructurados y no haber sido validados.
La etapa de Validacion y Limpieza de Datos está orientada a establecer
normas de validación, a menudo complejas, y a eliminar cualquier dato
inválido conocido.
La Validación de Datos puede ser usada para examinar dataset
interconectados con el fin de completar datos válidos faltantes.
Para el Análisis por Lotes, pueder realizar validacion y limpieza de datos
por medio de una operacion ETL offline.
Para la Analítica en tiempo Real, se requiere un sistema basado en
memoria más complejo para validar y limpiar los datos en la fuente.
 Etapa 5: Validación y Limpieza (cleansing) de Datos

Los métodos más usados para aplicar la limpieza y validación de datos a un Data
Set son los siguientes:
✓ Análisis
✓ Transformación de Datos
✓ Eliminación de duplicados
✓ Método Estadístico
 Etapa 6: Agregación y Representación de Datos

La etapa de Agregación y Representación de Datos está orientada a la

integración de múltiples datasets para llegar a una vista unificada.

1.Estructura de los Datos : Aunque el formato de los datos puede ser el

mismo, el modelo de datos puede ser diferente.
2. Semántica : Un valor etiquetado de forma diferente en dos datasets
diferentes puede significar lo mismo; por ejemplo “apellido“ y “last name“
 Etapa 7: análisis de datos (data analysis)

La etapa de Análisis de Datos está orientada a realizar la tarea real de

análisis, lo cual involucra uno o más tipos de Analítica.

El enfoque adoptado para ejecutar esta etapa se puede clasificar como

Análisis Confirmatorio y Análisis Exploratorio este último esta relacionado
con la Data Mining.

Analisis Confirmatorio de datos : Enfoque Deductivo ( Hipotesis )

La Causa del fenomeno investigado

Analisis Exploratorio de Datos : Enfoque Inductivo

Los datos son explorados , para comprender las causas
 Etapa 8:Visualización de Datos

La etapa de Visualización de Datos esta orientada a utilizar

técnicas y herramientas de Visualización de Datos para
comunicar gráficamente el resultado del análisis, de forma
que los usuarios del negocio puedan interpretarlos
efectivamente.

El analizar cantidades masivas de datos y hallar información

útil puede tener poco valor si los únicos que pueden entender
los resultados son los analistas.

Los resultados pueden ser presentados de diversas formas, lo

cual puede afectar su interpretación.
 Tipos de Visualización de Datos

➢ Filtrar
➢ Resumir y sintetizar información
➢ Ordenar
➢ Describir y caracterizar distribuciones
➢ Encontrar anomalías
➢ Encontrar agrupaciones
➢ Detectar correlaciones
Formas de visualizar los datos

Gráfico de Barra
Tablas
Gráfico Circular
Nube de palabras
Infograma
Gráficos de Línea
 Etapa 9 : Uso de los resultados del análisis

La etapa de Uso de los Resultados del Análisis está orientada a

determinar como y cuando se pueden aprovechar los datos
procesados de análisis.

Para laToma de Desiciones Empresariales ( Dashboard )

Los resultados del analisis generan “Modelos“ que encapsulen

nueva información sobre la naturaleza de los patrones y relaciones
que existen en los datos que fueron analizados.

Un modelo pueden ser usados para mejorar la lógica del proceso

empresarial y la del sistema de aplicaciones, y pueden conformar la
base de un nuevo sistema o software
 El Éxito / Fracaso de un proyecto

• Exitosos Son aquellos en los que no hay duda de

que fueron un éxito por entregables y tiempos
• Discutidos Son aquellos en los que hay dudas sobre
si tuvieron éxito o fueron un fracaso
• Fallidos Son aquellos en los que no hay duda de que
fueron un fracaso
 La Gestión de proyectos
En administración de empresas, la gestión de
La Gestión de Proyectos tiene como objetivo proyectos es la disciplina que estudia la
asegurar la correcta ejecución de todas las planificación, organización, motivación y
actividades del mismo, siguiendo la definición del control de los recursos con el propósito de
ciclo de vida, y gestionando todos los aspectos alcanzar uno o varios objetivos
relacionados como los hitos, entregables,…

La gestión del proyecto es importante porque

garantiza que lo que se está entregando
está bien hecho y proporcionará un valor
real frente a las oportunidades de negocios.
¿El Por qué de una metodología de gestión de
proyectos?
 Metodologías (métodos) de gestión de proyectos

Ciclo de vida PMBoK (PMI)

“Predictivo” Prince2
Métrica
MSF
….

Ciclo de vida
“Adaptativo” Scrum
(incremental, Kanban
iterativo, ágil) DSDM
SAFe
….
 La Gestión del Cambio (y los proyectos)

La gestión del cambio busca facilitar y conseguir la implementación exitosa de los procesos de transformación,
lo que implica trabajar con y para las personas en la aceptación y asimilación de los cambios y en la reducción
de la resistencia a los mismos

Tiene como principal objetivo identificar los riesgos que puedan

dificultar la adopción del nuevo entorno o situación y planificar y ejecutar
un conjunto de actividades que
- suavicen/mitiguen/eliminen/reduzcan esos riesgos..
- … comunicando, demostrando valor…
- … y alineando las personas con la nueva realidad y los objetivos
estratégicos y capacitándoles

Para ello, hay que planificar y ejecutar un conjunto de actividades orientadas:

- tanto a reforzar la aptitud (formación en los nuevos procesos, políticas, entorno,…)
- como, sobre todo, a promover la actitud de los futuros usuarios
(motivación para la aceptación de la misma)
-
Posteriormente tendremos que evaluar y medir los resultados del proceso de la adopción
Los Stakeholders de un
Proyecto
 Definición
del proyecto:
Ejemplo de
documento de
Project
Charter
Metodología de Gestión “Ágil”
de proyectos
Equipo de un proyecto de DATA
 “El manifiesto ágil”

Valores Principios
• Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y
continua de software con valor.
• Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los
procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
• Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con
preferencia al período de tiempo más corto posible.
• Los responsables del negocio y los desarrolladores trabajamos juntos de forma
cotidiana durante todo el proyecto.
• Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el
entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
• El método más eficiente y efectivo de comunicar información al equipo de desarrollo y
entre sus miembros es la conversación cara a cara.
• El software funcionando es la medida principal de progreso.
• Los procesos ágiles promueven el desarrollo sostenido. Los promotores,
desarrolladores y usuarios debemos mantener un ritmo constante de forma indefinida.
• La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
• La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
• Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
• A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo para, a
continuación, ajustar y perfeccionar su comportamiento en consecuencia.
 “El manifiesto ágil”
Valores Principios
“El manifiesto ágil” Resumen
Pilares:
- Transparencia
- Inspección
- Adaptación
Valores
- Compromiso
- Foco
- Franqueza
- Respeto
- Coraje
Conceptos básico
- Iterativo – incremental
- Equipos automotivados y
autogestionados
- Colaboración constante con el
cliente

Modelo
- 3 artefactos
- 5 eventos
- 3 – 4 roles
 La gestión ágil
de proyectos con
Scrum

32
 Metodología Scrum, ¿Qué es?

• Scrum es un proceso de gestión que reduce la

complejidad en el desarrollo de productos para
satisfacer las necesidades de los clientes.
• Los Scrum Masters, equipos de desarrollo y
Product Owners trabajan juntos alrededor de
requisitos y tecnologías para entregar productos
funcionando de manera incremental aplicando su
experiencia.”
• Scrum es un marco de trabajo simple que promueve
la colaboración en los equipos para lograr desarrollar
productos complejos, siempre adaptados a las
últimas tendencias del mercado y necesidades del
cliente y stakeholders ya que permite cambios sin
tener que esperar a que el producto originalmente
especificado esté realizado.

“3 pilares soportan toda la implementación del control del proceso empírico: transparencia, inspección y adaptación”
 Las “Ceremonias” (eventos) en Scrum
Sprint
Sprint es un contenedor para el resto de eventos de
Scrum. La duración del Sprint se determina por un horizonte
de planning aceptable, determinado por el propio equipo Scrum
junto al Product Owner.
No hay fases en Scrum, sólo Sprints.
No existen Sprints específicos de testing, hardening,
release o análisis.
Un Sprint normal tendría los siguiente eventos o ceremonias:
• El Sprint Planning al comienzo del Sprint
• Daily Scrums a diario
• Un Sprint Review al final del Sprint para inspeccionar el
incremento realizado.
• Y, finalmente, una Retrospectiva para inspeccionar el
equipo y levantar mejoras que se apliquen en el siguiente
Sprint.
https://jeronimopalacios.com/scrum/
Sprint Planning
Es una reunión que se realiza al comienzo de cada Sprint
donde participa el equipo Scrum al completo; sirve para
inspeccionar el Backlog del Producto (Product Backlog ) y que
el equipo de desarrollo seleccione los Product Backlog
Items en los que va a trabajar durante el siguiente Sprint.
Estos Product Backlog Items son los que compondrán el Sprint
Backlog.
Durante esta reunión, el product owner presenta el Product
Backlog actualizado que el equipo de desarrollo se encarga de
estimar, además de intentar clarificar aquellos ítems que crea
necesarios.
Si bien en el Sprint Planning participa el equipo Scrum al
completo, no participan los stakeholders.
En el Sprint Planning se inspeccionan el Product Backlog,
los acuerdos de la Retrospectiva, la capacidad y
la Definition of Done y se adaptan el Sprint Backlog, Sprint
Goal y el plan para poder alcanzar ese Sprint Goal.
El Sprint Planning se divide en dos partes:
• En la primera parte de la reunión se trata Qué se va a
hacer en el siguiente Sprint
• Y, en la segunda parte, se discute el Cómo.
Daily Scrum
Es una reunión diaria de 15 minutos en la que
participa exclusivamente el Development Team.
En esta reunión todas y cada una de las personas
del Development Team responden a las siguientes
preguntas:
1.¿Qué hice ayer para contribuir al Sprint Goal?
2.¿Qué voy a hacer hoy para contribuir al Sprint Goal?
3.¿Tengo algún impedimento que me impida entregar?
Sprint Review
El Sprint Review es la reunión que ocurre al final del
Sprint, donde el product owner y el Develpment
Team presentan a los stakeholders el incremento
terminado para su inspección y adaptación
correspondientes.
En esta reunión, organizada por el product owner se
estudia cuál es la situación y se actualiza el Product
Backlog con las nuevas condiciones que puedan afectar
al negocio.
Sprint Retrospective
Su objetivo es reflexionar sobre el último Sprint e
identificar posibles mejoras para el próximo.
El marco de referencia de Scrum
 Los “Artefactos” en Scrum
Product Backlog
Es un inventario que contiene cualquier tipo de trabajo
que haya que hacer en el producto: requerimientos, casos
de uso, tareas y dependencias. Es la principal fuente de
información sobre el producto en Scrum, una lista, en cualquier
formato, que contiene todos los requerimientos que
necesitamos implementar en el producto.
Esta lista es el resultado del trabajo del Product Owner (quien
lo gestiona en exclusiva) con el cliente, los distintos
stakeholders, sponsors, comités, etc, y refleja el estado real del
trabajo pendiente de implementar en el producto, así como el
ya realizado.
Su principal función la de priorizar aquellos elementos que
tienen más valor en cada etapa y detallarlos para que el equipo
de desarrollo sea capaz de valorarlos y ejecutarlos.
Un Product Backlog contiene distintos elementos:
• Funcionalidades
• Bugs
• Historias de usuario: una forma de expresar elementos
de un Product Backlog. Para obtener el máximo valor de
una historia de usuarios es necesario expresarlas desde
el punto de vista del usuario.
• Tareas técnicas
• Trabajo de investigación
Sprint Backlog
Se trata de una lista de elementos en los que trabajar
durante la etapa de Sprint.
Estos elementos normalmente se componen de tareas técnicas
más pequeñas que permiten conseguir un incremento de
software terminado.
Todo el trabajo que el Development Team haya seleccionado
para hacer durante el siguiente Sprint pasa al Sprint Backlog.
El Sprint Backlog permite visualizar, durante cada Sprint,
aquellos elementos que aún no han empezado a desarrollarse,
aquellos que sí y quiénes están trabajando en los mismos, así
como aquellos que están esperando a desplegarse o están
completamente terminados.
Este artefacto permite entender cuál es la evolución del trabajo
durante el Sprint, así como hacer un análisis de riesgos.
Incremento
Es el resultado del Sprint, es la suma de todas las tareas,
casos de uso, historias de usuario y cualquier elemento
que se haya desarrollado durante el Sprint y que será
puesto a disposición del usuario final en forma de software,
aportando un valor de negocio al producto que se está
desarrollando.
Construir software de manera ágil se basa en hacerlo de
manera iterativa e incremental. Mediante las iteraciones,
nos aseguramos que todo el ciclo de vida del software
(planificación, diseño, desarrollo, testeo y entrega) ocurre
en 4 semanas o menos.
Otros
Definition of Done (DoD): Documento que define qué
se considera hecho en un equipo Scrum. Establece una
serie de criterios comunes para especificar cuando un
ítem está completamente terminado y que aplique a
todos los ítems que forman parte del incremento.
Definition of Ready (DoR): Documento que define
cuándo un requerimiento (historia de usuario o similar)
se considera listo para que el equipo de desarrollo
pueda entenderlo, valorarlo e incluirlo en un Sprint
Planning con idea de acometerlo en un Sprint.
Burndown Chart: Gráfico de trabajo pendiente a lo
largo del tiempo que muestra la velocidad a la que se
están completando los objetivos, requisitos, o historias
de usuarios. Permite extrapolar si el equipo podrá
completar el trabajo en el tiempo estimado.
 El “Equipo” Scrum

• Dueño de un Producto (Product Owner)

Responsable de maximizar el valor del producto y del trabajo del
Equipo de Desarrollo. Responsable de gestionar la Lista del
Producto (Product Backlog).
• Equipo de Desarrollo (Development Team)
Los profesionales que desempeñan el trabajo de entregar un
incremento de producto “Terminado”, que potencialmente se
pueda poner en producción, al final de cada sprint. Estructurado y
empoderado para organizar y gestionar su propio trabajo.
(Entre 3 y 9 miembros)
• Scrum Master
Responsable de asegurar que Scrum es entendido y adoptado.
Está al servicio del Equipo Scrum.

Los equipos son autoorganizados y multifuncionales y tienen todas las

competencias necesarias para llevar a cabo el trabajo sin depender de otras
personas que no son parte del equipo
Los equipos Scrum entregan productos de forma iterativa e incrementar,
maximizando las oportunidades de obtener retroalimentación. Las entregas
incrementales de producto “Terminado” aseguran que siempre estará disponible
una versión potencialmente útil y funcional del producto
http://agilismoatwork.blogspot.com/2011/12/implantando-roles-agiles-parte-ii.html
 Equipos “tradicionales” vs “ágiles”

Un equipo “tradicional” es un equipo de Un equipo “ágil” es un equipo autoorganizado

individuos asignados a un proyecto para compuesto por individuos motivados y
entregar un resultado prescrito focalizados en entregar el mayor valor para
específicamente apropiado a nivel de su cliente en el menor tiempo posible.
experiencia de los miembros del mismo.
 Técnicas: Descripción del producto
Mapa de historias: diagrama de temas, épicas e historias que indica las secuencias de las características que se lanzarán con el tiempo.
Temas: una colección de épicas o historias de usuario relacionadas.

Épicas: gran historia de usuario que no puede completarse en una iteración. Las épicas se dividen en historias de usuario más pequeñas
para completar en distintas iteraciones.

Historias de usuario: breve descripción escrita que

representa un requisito o funcionalidad del proyecto utilizando
el lenguaje común del usuario. Las historias de usuarios son
descripciones cortas y simples de una característica contada
desde la perspectiva de la persona que desea la nueva
capacidad, generalmente un usuario o cliente.
La historia define a alto nivel un requisito, conteniendo
suficiente información para que los desarrolladores puedan
estimar el esfuerzo para implementar dicho requisito.
Las historias de usuarios a menudo se escriben en tarjetas o
notas adhesivas y se organizan en tableros, mesas o software
de colaboración para facilitar la planificación y el debate.

Tareas: explican cómo se van a realizar las historias de

usuario. “Suelen tener una duración máxima de 16 horas. “
 Técnicas: Priorización de los requisitos

ROI, VAN, TIR

Método 100 puntos: A cada interesado se les da 100 puntos para que puedan distribuirlos entre las historias de usuario en función de lo
que consideran que agregará más valor.
Análisis Kano
- Calidad requerida (Must be): no generan satisfacción cuando se cumplen porque son atributos básicos, pero dan lugar a gran
insatisfacción cuando no se cumplen.
- Calidad unidireccional (Resultado): dan como resultado la satisfacción cuando se cumplen e insatisfacción cuando no se cumplen
porque fueron ofrecidos por el vendedor
- Calidad entusiasmo (Delighters): proporcionan satisfacción cuando se logran plenamente, pero no causan insatisfacción cuando no se
logran porque no son esperados por el cliente ni fueron mencionados antes de la compra.
- Calidad indiferente: aspectos que no son ni buenos ni malos; no generan satisfacción o insatisfacción del cliente.
- Calidad inversa: un alto grado de atributos resulta en la insatisfacción de algunos clientes.
MoSCoW
- Must have
- Should have
- Could have
- Won’t have
Puño a cinco
…
 Técnicas: Estimación tiempos
(Sprint Planning Meeting)
• Tiempo ideal
• Puntos de historia: son un número que indica la complejidad
relativa de las historias de usuario. Por ejemplo, a una historia de
mínimo esfuerzo se le podrían asignar 1 punto, otra historia de
esfuerzo medio 8 puntos y una historia de gran esfuerzo podría tener
55 puntos de historia.
• Póker de planificación: técnica para calcular una estimación basada
en el consenso para estimar el esfuerzo o el tamaño relativo de pocas
historias de usuario
• Tallas de camisetas, Estimación por afinidad…
• Sistema de cubículos
Técnicas: Seguimiento (El método Kanban)

Kanban significa señal o letrero en japonés.

El método consiste en colocar el nombre de las actividades y una breve descripción en tarjetas que se pegan en un
tablero. Cada tarjeta o actividad va fluyendo desde la recepción de la orden hasta que el trabajo se encuentra
terminado. Estos tableros suelen tener gran visibilidad para el equipo y pueden ser en formato físico o digital.

• Kanban utiliza el enfoque Lean del “sistema pull”

y “justo a tiempo”.
Los miembros del equipo “retiran” (pull) las tarjetas que van
a ser procesadas y las trabajan hasta su finalización.
• Con los tableros Kanban se pueden coordinar de manera
simple las actividades del equipo y sus interrelaciones con
otros interesados. El tablero es considerado un radiador
de información que no requiere de gran tecnología, puede
ser una simple pizarra con post-it dónde los miembros del
equipo los van cambiando de casillero.
Técnicas: Seguimiento (El método Kanban)

kanban , tablero Kanban y el método

Kanban

Trabajar sin estrés (Kanban) - https://www.youtube.com/watch?v=I-H-WXAX_oM

Técnicas: Seguimiento (Sprint)

Solicitud Tiempo de Tiempo Entrega al

respuesta de ciclo cliente

Backlog Listo para empezar Work in Progress Hecho

Tiempo de entrega

Tiempo ritmo (Tackt time): ritmo necesario para satisfacer la demanda del cliente

Rendimiento (Throughput): capacidad promedio de producción de los miembros

del equipo
 Técnicas: Seguimiento (Sprint)

Gráfica de trabajo pendiente (Burndown Chart): representa el trabajo pendiente de finalización frente al tiempo restante.
Es un radiador de información utilizado para mostrar el progreso de la iteración a través del tiempo y para estimar el rendimiento diario del equipo.
 Herramientas y plataformas de apoyo a la gestión de
proyectos

Remember the milk

RTM
Todoist
Planview Microsoft ToDo
CA Technologies PPM
Microsoft Project
…
Wrike
Microsoft Planner
Toggle Plan
Basecamp
Trello
…

Microsoft Teams
Atlassian Confluence Chatter
Redbooth Slack
Citrix Podio Jive
Samepage …
https://www.softwareadvice.com/resources/social-collaboration-tools/
https://blog.hubspot.es/marketing/herramientas-gestion-p
Herramientas y plataformas de apoyo a la gestión de
proyectos
“Nuevas metodologías” para un “nuevo entorno”
Actualiadad
La “mentalidad” ágil en las organizaciones
Organizaciones tradicionales vs “ágiles”

Organizaciones tradicionales vs “ágiles”

Tradicional “Ágil”

Dinámica interna Estable y fija Estable y dinámica

Liderazgo Jerarquía “Top-down” Los líderes establecen la dirección y remueven los

obstáculos
Estructura En “silos” Equipos “ágiles” cros-funcionales

Reglas Burocracia “Marco a alto nivel” con libertad de actuación

Filosofía del talento humano Los individuos son considerados como una Los individuos empoderados y motivados son
“commodity” considerados como una ventaja competitiva
Un ejemplo práctico de
“Organización ágil
 Un ejemplo práctico de
“Organización ágil

Transformación en ING (A): Agile – Harvard Business School

 Un ejemplo práctico de
“Organización ágil

Transformación en ING (A): Agile – Harvard Business School

Un ejemplo práctico
de Organización ágil

Transformación en ING (A): Agile – Harvard Business School

 Un ejemplo práctico
de Organización ágil

Transformación en ING (A): Agile – Harvard Business School

“En resumen: “Nuevas metodologías” para un “nuevo entorno”
Tarea Grupal parte 2 ( Presentación 22/04)
En equipo desarrolla, en base al caso elegido la clase pasada, lo siguiente:
o Defina el plan para desplegar
la cultura Data Driven a un siguiente nivel :
- ¿Como se llevaría a cabo su implementación?( cómo desplegarías las fases)
- ¿Qué tipo de datos utilizaría la empresa y cómo los integrarías? ( UDA)
- Selecciona una proyecto de Data de la empresa , definiendo la necesidad de
negocio, los beneficios de su implementación y menciona qué ventajas se
obtendrían.
- Se presentará en una PPT