Como complementar CMMI y SCRUM

srum plus cmmi or not scrum plus cmmi

Recientemente, hablando con un antiguo compañero, surgió el tema de que podría aportar SCRUM a CMMI y viceversa. Tras un debate intenso y productivo llegamos a las siguientes conclusiones que me gustaría compartir con vosotros.

Mejoras que CMMI aporta a SCRUM

  1. CMMI ayuda a determinar de una manera más formal las mejoras que se pueden introducir en los procesos, por ejemplo mediante las métricas o las auditorías internas.
  2. La planificación formal ayuda a capturar y dar seguimiento a las decisiones de gestión del proyecto, especialmente cuando los proyectos y la organización crecen y la presión aumenta.
  3. Ayuda a involucrar de manera común al resto de la organización y a los actores externos, tanto en el seguimiento de los proyectos como en el aprendizaje y difusión de las mejoras.
  4. Define más claramente los roles a nivel de equipo y fuera de los equipos, hecho que facilita la asunción clara de las responsabilidades.
  5. Facilita que se determine la formación que no puede adquirirse autónomamente por los miembros de los equipos, especialmente importante en proyectos grandes.
  6. Normaliza la realización de ciertas tareas, de manera que puede reaprovecharse mejor el conocimiento, se es más eficiente y se evitan problemas de calidad.
  7. El desarrollo más formal de requisitos de cliente ayuda a estimar y planificar mejor el proyecto que un simple “roadmap” de producto.

Ventajas de implementar CMMI usando SCRUM

  1. Los procesos que se definen se suelen realizar realmente, ya que se diseñan ligeros y de un seguimiento frecuente y compartido por el equipo.
  2. El aprendizaje en los proyectos es continuo, mediante las reuniones SCRUM y las retrospectivas, y esto suele llevarse fácilmente de vuelta a los procesos.
  3. La verificación y el seguimiento a los riesgos se realizan de una manera manual mediante las reuniones del equipo y las demostraciones al cliente.
  4. Los proyectos pequeños no se ven penalizados por metodologías pesadas. Se pueden definir “perfiles de proyecto” que añadan nuevos procesos y actividades sólo para “proyectos grandes”.
  5. Los miembros del equipo están en contacto frecuente con el jefe de proyecto, hecho que le aporta información muy valiosa para la planificación y seguimiento del proyecto.
  6. La planificación de las tareas basadas en un roadmap ayuda a mantener el trabajo centrado en las prioridades de cada momento y evitar realizar trabajo innecesario.

Espero que estas conclusiones os resulten interesantes y os animen a utilizar CMMI y/o SCRUM.

¡Nos vemos en próximas entradas!

Publicado en Metodologías

¿Qué es Big Data?, ¿como se usa? y ¿para que sirve?

Big Data

Hoy vamos a hablar sobre el Big Data, uno de los conceptos de moda en el mundo informático. En la actualidad contamos con una gran cantidad de artículos, e información, y en todas las encuestas a los CIOS aparece entre los primeros lugares la necesidad de implantar un sistema de Big Data.

Sin embargo, observamos una gran confusión sobre «en qué consiste realmente». En las mismas encuestas, cuando se pregunta sobre, qué es Big Data, comprobamos una gran dispersión en las respuestas ofrecidas. Empecemos entonces por tratar de aclarar «qué es Big Data«.

Denominamos Big Data a la gestión y análisis de enormes volúmenes de datos que no pueden ser tratados de manera convencional, ya que superan los límites y capacidades de las herramientas de software habitualmente utilizadas para la captura, gestión y procesamiento de datos.

Dicho concepto engloba infraestructuras, tecnologías y servicios que han sido creados para dar solución al procesamiento de enormes conjuntos de datos estructurados, no estructurados o semi-estructurados (mensajes en redes sociales, señales de móvil, archivos de audio, sensores, imágenes digitales, datos de formularios, emails, datos de encuestas, logs etc,) que pueden provenir de sensores, micrófonos, cámaras, escáneres médicos, imágenes.

El objetivo de Big Data, al igual que los sistemas analíticos convencionales, es convertir el Dato en información que facilita la toma de decisiones, incluso en tiempo real. Sin embargo, más que una cuestión de tamaño, es una oportunidad de negocio. Las empresas ya están utilizando Big Data para entender el perfil, las necesidades y el sentir de sus clientes respecto a los productos y/o servicios vendidos. Esto adquiere especial relevancia ya que permite adecuar la forma en la que interactúa la empresa con sus clientes y en cómo les prestan servicio.

No obstante, el asociar el concepto Big Data a grandes volúmenes de datos no es nuevo. La gran mayoría de las empresas ya llevan mucho tiempo manejando grandes volúmenes de datos y han desarrollado DataWarehouses y potentes herramientas analíticas que les permiten tratar de forma adecuada esos grandes volúmenes. La evolución de la tecnología y los menores costes del almacenamiento han hecho que los volúmenes manejados por estas aplicaciones hayan aumentado de manera muy importante.

Las ‘Vs’ del Big Data

¿Cuál es entonces la diferencia entre las aplicaciones analíticas y de gestión y los nuevos conceptos de Big Data? Las diferencias se asocian, en la mayoría de los artículos de referencia, a tres palabras, las tres ‘Vs’ del Big Data: Volumen, Variedad y Velocidad (3Vs). Sin embargo, en base a la experiencia adquirida por las empresas pioneras en esta aventura, se ha ampliado la definición original, añadiendo nuevas características como son la Veracidad y Valor del dato (5Vs)

Hablamos de Big Data cuando los volúmenes superan la capacidad del software habitual para ser manejados y gestionados. Este concepto se encuentra en continuo movimiento porque los avances tecnológicos permiten tratamientos de volúmenes mayores. Cuando hablamos de grandes volúmenes nos referimos a tratamientos de Terabytes o Petabytes. Esto permite incluir en este tipo de proyectos informaciones (por ejemplo logs) que hasta la fecha no se utilizaban porque la tecnología no permitía procesarlos en un tiempo razonable. El concepto de volumen es muy variable y cada día que pasa eleva lo que podemos considerar grandes volúmenes de datos.

En el concepto de variedad nos referimos a la inclusión de otros tipos de fuentes de datos diferentes a las que se utilizan de forma tradicional. Nos referimos a información obtenida en diferentes Redes Sociales, en el número cada vez mayor de dispositivos electrónicos conectados, la explotación de sensores que permiten conocer los movimientos y hábitos de vida, de información externa de diversas fuentes, etc.

La información que procesan los Datawarehose es información estructurada que ha pasado por numerosos filtros de calidad para poder garantizar que la información de salida tiene una precisión y una exactitud determinada. Sin embargo, cuando hablamos de Big Data nos referimos a información que puede estar semiestructurada o no tener ninguna estructuración. La gestión de esta información desestructurada precisa de una tecnología diferente y permite tomar decisiones basadas en información que tiene importantes grados de inexactitud. Muchos de estos algoritmos se relacionan con los tratamientos de sistemas avanzados de lógica difusa.

Por último, el concepto de velocidad se refiere a la rapidez con que los datos se reciben, se procesan y se toman decisiones a partir de ellos. A la mayoría de los sistemas tradicionales les es imposible analizar de forma inmediata los grandes volúmenes de datos que les llegan, sin embargo, incorporar el concepto de tiempo real es imprescindible para sistemas de detección del fraude o la realización de oferta personalizadas a los clientes.

Pero, no menos importante al barajar este concepto, es la veracidad, esto es, confianza de los datos, extraer datos de calidad eliminado la imprevisibilidad inherente de algunos, como el tiempo, la economía etc, para, de esta forma, llegar a una correcta toma de decisiones

Finalmente, se añade el valor. La importancia del dato para el negocio, saber que datos son los que se deben analizar, es fundamental. Tanto que ya se empieza a hablar del científico de datos, un profesional con perfil científico, tecnológico…y visión de negocio.

Espero que este pequeño resumen os haya resultado util e interesante.

¡Nos vemos en próximas entradas!

Publicado en Tecnologías

La responsabilidad de un Junior

Economia de un proyecto

Hoy voy a contar una pequeña anécdota de la que fui protagonista cuando apenas llevaba 6 meses trabajando, tras acabar la carrera.

Por aquel entonces yo era un junior, sin mucho conocimiento de nada, con una enorme cantidad de ingenuidad encima y mi trabajo consistía principalmente en arreglar temas de accesibilidad WEB y diseño WEB.

Cuando me dijeron que iba a ser asignado al equipo de una importante empresa de seguros me sentí emocionado, hasta ese momento había trabajado siempre desde la sede de mi consultora e iba a ser mi primera experiencia trabajando directamente en las oficinas de un cliente final. Nada más llegar, en mi primera charla de presentación, se me comunica que el proyecto es crítico y que lleva más de dos meses de retraso, por lo que se espera de mí un alto nivel de compromiso, que me esfuerce al máximo y que sepa estar a la altura. Fue un recibimiento frio y extraño, pero para un recién licenciado que desborda entusiasmo y está deseando demostrar que es capaz de comerse el mundo, sonaba a desafío interesante, así que sin perder un minuto me puse con las tareas que me habían asignado.

Fueron dos semanas de locura extrema, jornadas de hasta 12 horas seguidas, (por supuesto sin reconocerse ni pagarse las horas extras, algo de lo que me enteraría a posteriori), sábados trabajando como un laborable más, (una vez más sin percibir ninguna remuneración por ello), y un nivel de estrés insano… y eso que yo solo me dedicaba a aplicar un nuevo CSS a los distintos formularios de la página WEB del cliente. Aun así, estaba contento en líneas generales, formaba parte de un equipo súper comprometido y me veía a la altura de mis compañeros veteranos en cuanto a esfuerzo y dedicación.

Para mi sorpresa, y esta es la parte divertida, a las dos semanas me dicen que quieren que asista a una reunión de seguimiento con el cliente. Recuerdo los nervios que sentí en ese momento, mi primera reunión con los responsables de un proyecto y con el cliente, era algo importante, tal vez se habían fijado en mi trabajo, tal vez me iban a pasar a otras tareas, las posibilidades eran infinitas, así que allí me presente con mi mejor aspecto corporativo y lleno de emoción. Nada más entrar en la sala me di cuenta de que algo iba mal, solo había gente mayor muy seria y preocupada y mi responsable, un analista que supervisaba mi trabajo y que me había dicho que también iba a asistir, no estaba por ningún lado.

No voy a entrar en detalles de lo que hasta la fecha ha sido uno de los peores momentos de mi vida laboral, en resumen diré, que el proyecto que estaba planificado para una duración de 8 meses, ya llevaba casi 3 meses de retraso, que mi incorporación al proyecto había sido una decisión estratégica para que reforzase al proyecto y que no estaba cumpliendo sus expectativas. Como imaginareis, yo no entendía nada, me estaba dejando la piel haciendo todo lo que se me pedía y ahora me estaban echando la culpa de que el proyecto no se cerrase, a mí, a un junior que cambiada los colores de los formularios de la página WEB, desde hacía solo dos semanas. ¿Alguien más ve una incongruencia en la situación?.

¿Qué había pasado?, el proyecto había sido una catástrofe mal dimensionada desde el principio, hasta tal punto que el cliente deseo cerrarlo a la mayor brevedad posible y accedió a ampliar los servicios de la consultora añadiendo al equipo un nuevo consultor senior que fuese capaz de ayudar a cerrar el proyecto de una vez. A pesar de que todo el mundo hacia horas extras gratuitas y se trabajaban los sábados también gratuitamente, la consultora había sobrepasado su presupuesto, por lo que decidió guardarse la última inyección de dinero del cliente para minimizar perdidas y en vez de meter al perfil que el cliente estaba pagando, me metió a mi como refuerzo estrella en el proyecto. Por supuesto semejante situación tenía que explotar por algún lado.

Antes de entrar en la reunión, mi responsable me dijo que no se me ocurriese abrir la boca, que para eso estaba él y que observase y aprendiese. Sin embargo el no estuvo en la reunión y pasado el shock inicial en el que no me podía creer lo que estaba viendo y oyendo, tome la palabra. Explique mi categoría de junior, mis funciones en el proyecto y todo el esfuerzo y dedicación que estaba volcando en que todo lo que se encargaba estuviese bien y dentro de los plazos que se me asignaban, aunque me tuviese que ir a mi casa pasadas las 12 de la noche o sacrificase fines de semana, por lo que no entendía que se me hiciese responsable de la actual situación del proyecto. El gerente y los jefes de proyecto de mi consultora se quedaron en silencio y el cliente me pidió que me fuese de la reunión sin añadir nada más. Nunca olvidare la importante lección que aprendí ese día y el sentimiento de traición extrema que me recorrió en ese momento.

Esa misma tarde me mandaron de vuelta a la sede de mi consultora, donde se me dio una charla sobre el corporativismo y el bien común de la empresa, ya que mi intervención se había considerado desleal y por supuesto había provocado que me echasen de ese cliente. Cuatro meses después dejaba ese trabajo decidido a abrirme camino en el mundo de la gestión de calidad en proyectos de consultoría. Hoy trabajo como asesor de calidad, certificado en ITIL, CMMI y varias ISO, y fue esa reunión la que marco mi carrera profesional.

Lamentablemente en los últimos 7 años he podido ver que en mayor o menor medida, los junior son usados muchas veces como cabeza de turco cuando un proyecto se tuerce y eso no es ni correcto, ni responsable, ni serio. Así que mi recomendación es que nunca aceptéis cargar con más responsabilidad de la que os corresponda, si vosotros no marcáis vuestros límites y os defendéis cuando os intenten endosar cosas que no son vuestra responsabilidad, nadie lo hará por vosotros y tened la conciencia bien tranquila, hacer lo correcto nunca debería ser un motivo de estrés en el trabajo.

Moraleja, cada parte ha de asumir sus propias responsabilidades, no se le puede vender a un cliente que la culpa de que un proyecto estratégico no salga sea de un junior que cambia colores en la WEB, ni esperar poder poner a un trabajador serio y responsable en la picota para que le corten la cabeza y que no diga nada y encima se muestre colaborador. ¿Qué imagen da semejante situación al cliente?.

¡Nos vemos en próximas entradas!

Publicado en Vivencias

La importancia de un buen dato

Data Governance

Hoy veremos algunos de los problemas que suelen derivarse de una mala gestión de datos y como prevenirlos.

En varias ocasiones he podido ver como un proyecto que cumplía con todos los requisitos del cliente y que estaba en fecha, recibía una mala aceptación por que el dato no cuadraba y por tanto todo lo que se ha hecho no vale. Entonces se empieza con el estrés y el agobio, nos vamos de fechas y de presupuesto, se repasan todos los puntos del proyecto, los orígenes de datos, las trasformaciones, el ODS, la carga en el DWH, los Datamart, los universos de explotación y los informes, todo parece estar correcto, pero el dato final sigue sin cuadrar con las expectativas del cliente, ¿qué esta pasando?.

A estas alturas alguien ya le ha preguntado al cliente por la fiabilidad del dato que les están dando y por supuesto el cliente ha respondido que su dato es 100% fiable, que está perfecto y que jamás han tenido un problema con el hasta este momento, algo que ya dijo en su día durante las sesiones de arranque del proyecto y que se dio por válido sin entrar a planificar ninguna tarea que verificase la calidad del dato en su origen… ¡¡¡ERROR!!!

El cliente SIEMPRE tiene plena confianza en su dato, para él su sistema es perfecto y no concibe que en algún momento de sus procesos internos el dato pueda sufrir alguna alteración y pierda consistencia o que directamente su dato estuviese mal desde el principio y se maquillase posteriormente para cumplir con las expectativas de sus informes.

Siempre y repito, siempre, hay que hacer un control de la calidad del dato. Es fundamental que el dato sea correcto ya que sobre él se realizara toda la arquitectura del proyecto, si los cimientos no son correctos corres el riesgo de tener que deshacerlo todo y tener que volver a empezar desde el principio. Además, no basta con chequear la calidad del dato en su origen, es importante que en el proyecto haya un sistema completo de Data Governance que valide y verifique constantemente que el dato no pierde valor ni integridad a lo largo de todo el ciclo de vida del proyecto hasta su explotación final.

En resumen, invertir tiempo del proyecto en garantizar la fiabilidad del dato es una apuesta segura, si el dato es correcto el cliente se sentirá seguro y estará contento con la garantía de tu proceso de calidad, si el dato no es correcto, se identificara el problema en una etapa muy temprana del proyecto y permitirá tomar las medidas necesarias para corregir el fallo sin que ellas afecten a todo el resto del proyecto.

Espero que esta pequeña reflexión os haya resultado interesante.

¡Nos vemos en próximas entradas!

Publicado en Buenas practicas
Sobre el autor:

Antonio María Fernández de Puelles de Torres-Solanot

– Trabajador Social

– Empresario

– Máster en Dirección de Comercio Intenacional

– Máster en Business Intelligence, Big Data, Professional Qualification in Management & Leadership

– Certificación Oficial CMMI

– Certificación Oficial en ITIL V3

– Master en Redes CCNA de Cisco

– Ingeniero en Informática de Gestión

Follow De consultor BI a Trabajador Social on WordPress.com
septiembre 2026
L M X J V S D
 123456
78910111213
14151617181920
21222324252627
282930