Privalia a la vanguardia del comercio electrónico en México

Este artículo es patrocinado por Privalia. Outlet online lider en ropa, calzado y estilo de vida.

El e-commerce se ha convertido en parte importante de nuestras vidas desde hace ya algún tiempo. Sería inconcebible hoy en día el no tener la posibilidad de comprar diferentes productos en la Internet, sin tener que salir de casa.

La crisis sanitaria de 2020 exacerbó está tendencia y muchos negocios han prosperado en el universo online. No sólo los gigantes mundiales de Estados Unidos y China han visto importantes crecimientos en sus ventas por Internet, sino también compañías de España y América Latina.

Tal es el caso de Privalia, outlet online que se destaca en el sector de ropa y calzado, ofreciendo marcas de primera línea con importantes descuentos. En este artículo, te mostramos un caso de estudio de los aspectos que diferencian al modelo de negocios de Privalia y su propuesta de valor para el público.

Lecciones aprendidas según el PMBOK 6

Este artículo es un extracto de la Guía de fundamentos para la dirección de proyectos sexta edición (PMBOK 6). Puedes conseguir el PMBOK 6 en Amazon.

Las lecciones aprendidas según el PMBOK son muy importante para la gestión de proyectos en una organización, pues es a través de estás que se documentan las causas de los errores y aciertos, conocimiento que luego puede aprovecharse en futuras iniciativas.

A partir de la guía de fundamentos de dirección de proyectos PMBOK sexta edición, se han realizado algunos cambios en la forma de manejar las lecciones aprendidas en un proyecto.

La novedad con la guía PMBOK 6 es que ha quedado establecido cual es la información que se documenta en el registro de lecciones aprendidas, además, se indica como las lecciones aprendidas se pueden registrar en cualquier momento, no solamente al final del proyecto.

Te presentamos a continuación los cambios en las lecciones aprendidas según el PMBOK 6.

Errores clásicos en la gestión de desarrollo de software

Imagen obtenida de: comerecommended.com

En 1996, Steve McConnel, un influyente consultor de la industria del desarrollo del software, público su obra “Desarrollo Rápido: Domesticando Cronogramas Salvajes de Software” (Rapid Development: Taming Wild Software Schedules).

Una de las secciones del libro, describen los errores clásico al tratar de acelerar (o hacer Fastrack) de los proyectos, prácticas de desarrollo de software que son seleccionadas con tanta frecuencia y con los mismos malos resultados predecibles, que merecen ser llamadas “clásicos”, y que siguen estando muy vigentes a pesar que la obra se público hace 17 años.

¿Algunas de estas prácticas erróneas le son familiares?, por ejemplo, ¿Qué hacemos si un proyecto está retrasado?, ¿incorporamos más gente?, ¿que hacemos si algún integrante está dañando la productividad del equipo?, ¿esperamos hasta el final del proyecto para despedirle?, o ¿que haría si le han asignado un proyecto agresivo en fecha?, ¿reclutar a todos desarrolladores disponibles (inclusive si son novatos) e iniciar lo antes posible sin planificación?.

A continuación dejamos la lista, si conoces algún error clásico que no esté incluido, te invitamos a dejar un comentario.

Recomendaciones para la reunión de retrospectiva

Imagen de: Agile Studio

En el marco de trabajo del desarrollo ágil de software y en particular en Scrum, toda iteración (o Sprint), debe concluir con una reunión de retrospectiva, en la cual el equipo, el dueño de producto (product owner), el facilitador y otros interesados se reúnen para conversar sobre lo que salió bien, que salió mal y que acciones especificas de mejora se pueden ejecutar en la próxima iteración.

Muchos son los consejos, recomendaciones y técnicas de facilitación que se pueden aplicar, la idea es facilitar que los integrantes del grupo puedan hablar sin tapujos y libre de temores, expresando libremente sus ideas, admitir los errores propios y buscar soluciones. pmoinformatica.com, "La Oficina de Proyectos de Informática",  presenta las recomendaciones para una mejor retrospectiva, obtenidas de las siguientes fuentes: Retrospectivewiki.org, Propersolutions.com y Marketing Agency Insider.

A continuación los consejos y recomendaciones para una mejor retrospectiva:

Las lecciones aprendidas: Como aprovecharlas

Imagen de: Retos Directivos

Al final de cada proyecto, se puede tomar el tiempo para reunir al equipo y a los interesados (stakeholders) clave, para dejar registrado en un documento que salió bien durante el proyecto y que no salió tan bien. Inclusive, se puede definir un plan de acción con responsables claramente definidos, pero, ¿realmente esto significa sacar el máximo provecho de las lecciones aprendidas?.

Pmoinformatica.com, “La Oficina de Proyectos de Informática”, presenta un nuevo artículo de la serie de lecciones aprendidas. En el post se describe la importancia de implementar la fase de “Actuar” del ciclo de mejora continua de W. Edwards Deming, que significa asignar responsabilidades a las acciones, hacer seguimiento, buscar identificar patrones de mejora o desmejora, revisar las lecciones aprendidas en cada nueva fase o proyecto y establecer metas de mejora continua para el equipo.

A continuación el artículo:

Las lecciones aprendidas en los proyectos

Imagen de: Optimos Software y Consultoría C.A.

Documentar las lecciones aprendidas es uno de los aspectos más importantes de la Gestión de Proyectos en cualquier organización, pues así los errores y aciertos de los proyectos quedan registrados para ser usados en futuras iniciativas, y de esta manera la organización aprenda y mejore continuamente.

Se puede reunir al equipo para conversar sobre que salió mal y que salió bien, pero lo más importante es que de la sesión puedan extraerse directrices sobre lo que se va a hacer de ahora en adelante para que los errores no se vuelvan a cometer y para que los aciertos puedan repetirse en futuros proyectos.

Pero, ¿Cómo se logra esto?, para realmente obtener resultados útiles de las lecciones aprendidas, pmoinformatica.com "La Oficina de Proyectos de Informática" presenta "Las Lecciones Aprendidas en los Proyectos".

Los cambios de alcance en los proyectos de informática

Imagen de: Picasa Web Albums

En un entorno tan dinámico como el de los tiempos actuales, todo proyecto está expuesto a la posibilidad que ocurran cambios de alcance durante su desarrollo.

En proyectos de informática está prácticamente asegurado que una vez que el cliente vea el producto se requerirán “ajustes” respecto al diseño original, además, la necesidad del área de negocio podría variar desde el inicio del proyecto hasta su entrega.

En este artículo se discute los distintos tipos de cambios de alcance que puede enfrentar un proyecto de informática, los posibles impedimentos para negociarlos con el cliente y los peligros representados en los mismos.

Además se expresan una serie de pasos que se pueden seguir para gestionarlos con el cliente.

10 actividades críticas a incluir en todo plan de desarrollo de un software

Imagen de: Picasa Web Albums

En el mundo de la informática, los clientes e inclusive nuestros Gerentes y Directores, esperan que cuando nos presenten un problema de ingeniería de software estemos en capacidad de responder de inmediato ¿para qué fecha cree usted que podría estar desarrollado y entregado?

Sin embargo, debe tenerse extremo cuidado al proporcionar fechas, pues los desarrollos de software suelen presentar muchos imponderables, que deben ser cuidadosamente analizados.

Una de las peores situaciones que se le pueden presentar a un analistas-programador de software, arquitecto, líder de equipo o Gerente de proyecto, es darse cuenta en la mitad de la ejecución, que actividades críticas no fueron consideradas cuando se planificó y comunicó una fecha de entrega.

En este artículo, se exploran una serie aspectos con frecuencia omitidos, pero que deben considerarse en la planificación de todo desarrollo de software. Van desde los tiempos para aprobaciones de los diseños, integraciones de códigos, instalación de ambientes de prueba, entre otros.

Para ayudar a los analistas-programadores, líderes de grupo y Gerentes de Proyectos de Software en esta tarea, presentamos a continuación las actividades críticas que no deben faltar en un plan de desarrollo de software.

Plantilla para documentar lecciones aprendidas

La plantilla de lecciones aprendidas ha sido actualizado a la última edición de la guía del PMBOK 6.

Imagen obtenida de: Picasa Web Albums

Todos los proyectos experimentarán a lo largo de su ejecución situaciones favorables o desfavorables. Una actividad primordial de todo equipo de trabajo es el identificar estas situaciones y analizar lo que se pueda aprender de ellas.

Para ello, existe el instrumento de las "Lecciones Aprendidas", las cuales permiten documentar estas situaciones, analizar sus causas raíz, el impacto que tuvieron en el proyecto y determinar que acciones fueron efectivas para mitigar sus efectos en el caso de las amenazas, y mejorarlos en el caso de las oportunidades. El objetivo es que podamos aprender de nuestros errores, se observa que es un elemento con frecuencia omitido, perdido en el día a día de los equipos de trabajo y los Directores de Proyecto.

Presentamos la Plantilla para documentar lecciones aprendidas de “La Oficina de Proyectos de Informática” en el siguiente enlace.  Está libre de derechos de autor y puede ser usada libremente por nuestros lectores. Se incluye un ejemplo de cómo llenarla, en la pestaña “Ejemplo”.

Algunas prácticas de desarrollo de aplicaciones web para asegurar calidad, mantenibilidad, escalabilidad y seguridad

Imagen de: Picasa Web Albums

En el entorno actual, cada vez más los clientes y usuarios de aplicaciones web exigen desarrollos en menor tiempo, exigiendo un “time to market” cada vez más corto, por lo cual existe la tentación de desarrollar sin prácticas de diseño y programación que aseguren la mantenimiento, continuidad y escalabilidad de las soluciones, mejorando el tiempo a expensas de la calidad.

 
En este artículo se presentan una serie de buenas prácticas en diseño y desarrollo de aplicaciones web y arquitectura orientada a servicios (SOA), abarcando prácticas de ingeniería del software, diseño y programación orientado a objetos, uso adecuado de patrones en el modelo de tres capas y estándares de desarrollo.

Estas prácticas, si bien pueden representar un mayor costo y tiempo cuando se comienza a desarrollar una nueva aplicación, representará beneficios en la capacidad de las aplicaciones de escalar y mantenerse. Presentamos a continuación estas prácticas:

El patrocinador (Sponsor) del proyecto: Rol que debe asumir y lo que no debe hacer

Imagen de: Picasa Web Albums

El rol del patrocinador (Sponsor) es fundamental para la ejecución exitosa de proyectos en cualquier área profesional, incluyendo la Tecnología de Información (TI), pues es quien realiza la principal labor de promoción y la procura del apoyo necesario dentro de la organización.

Sin embargo, ciertas conductas de un patrocinador pueden incrementar los riesgos y conducir al fracaso, que van desde querer inmiscuirse demasiado, no realizar su labor de promoción de los beneficios en los altos niveles de la organización, no proteger el proyecto de cambios innecesarios o ser indiferente al proyecto.

Sin embargo, es necesario que los Gerentes de Proyectos entendamos un aspecto clave: El tener un patrocinador con estas conductas no nos exime nuestra responsabilidad de asegurar el éxito del proyecto, es nuestro trabajo comunicarnos con él o ella acerca de esta situación y hacérselo ver.

Conductas negativas como por ejemplo no trabajar en equipo con el patrocinador o desobedecer sus instrucciones sólo contribuirá acelerar el fracaso del proyecto y por lo tanto el nuestro.

Presentamos a continuación el papel a desempeñar por el patrocinador del proyecto y lo que este no debe hacer.

Acciones preventivas para evitar retraso y retrabajo en proyectos de tecnología de información (TI)

Imagen Obtenida de: Picasa Web Albums

Un aspecto importante a la hora en que seamos participes en proyectos de tecnología de información (TI) o desarrollo de software, es que nuestro día a día tomemos acciones preventivas que nos permitan evitar retrabajos y anticipar situaciones que puedan causarnos retrasos en desarrollos y entregas.

En este artículo exploraremos distintas acciones preventivas que podemos tomar en proyectos de TI, que van desde identificar todos los requerimientos de todas las áreas implicadas desde la fase de análisis, hasta prevenir situaciones con los entornos y ambientes de base de datos.

Las preguntas que debe hacer al encargarse de un proyecto de Tecnología de Información (TI) en ejecución

Imagen obtenida de: Picasa Web Albums

Una situación que puede tocar en algún momento de la carrera de todo Jefe de proyectos de informática, es tener que encargarse de un proyecto ya comenzado. En esta situación es conveniente comenzar con una evaluación del proyecto y lo que se ha hecho en fases anteriores, a efectos de identificar situaciones y tomar acciones correctivas.

Presentamos a continuación las preguntas que debe hacer al encargarse de un proyecto de informática.

Las 10 recomendaciones a seguir al tomar vacaciones

Las características del trabajo en el área de informática podrían llevarnos a pensar que no es posible tomarse unas vacaciones, menos en plena ejecución de proyectos y fechas de próximas entregas.

La clave está en la forma de organizar al equipo, si existen canales de comunicación directos y acciones acordadas previamente entre sus integrantes, clientes e implicados en el proyecto, se puede continuar operando con eficiencia, inclusive en una ausencia prolongada.

Diseño y desarrollo de software en proyectos Fastrack: Como minimizar los riesgos

Imagen proporcionada por Picasa Web Albums

Hoy en día muchos proyectos de informática se están ejecutando bajo un enfoque de “Fastrack”, buscando disminuir el tiempo de desarrollo de software, por medio de la aplicación de diseños prefabricados y la ejecución en paralelo de actividades como el análisis, diseño, desarrollo y pruebas.

La aplicación de este enfoque implica comenzar a desarrollar el Software antes de tener el diseño detallado completo y aprobado en su totalidad, situación que de por sí supone riesgos de retrabajo más adelante en el proyecto, originado en nueva información técnica o cambios en los requerimientos.

En este artículo se exploran las consecuencias negativas de comenzar a desarrollar sin tener un diseño detallado aprobado y se presentan algunas recomendaciones que minimizarán dichos riesgos.