Archivo de la etiqueta: destacado

showrooming y webrooming el dilema de la tienda fisica

Showrooming vs webrooming
Showrooming vs webrooming

Showrooming y webrooming  son dos conceptos que tienen locos a las tiendas físicas, puesto que son antagónicos y no está muy claro cual es que tiene más tendencia.

Sin embargo según un estudio de Merchant Warehouse, el 66% de los consumidores dice haber hecho “webrooming”,mirar primero en internet y comprar después en las tiendas físicas. Este porcentaje desciende, en cambio, hasta el 50% en el caso del “showrooming”, en el que el consumidor hace justamente lo contrario, mira primero en las tiendas físicas y compra después en internet.

A la hora de decantarse por el “webrooming”, el consumidor tiene en cuenta factores como evitar los costes de envío asociados al e-commerce (47%) y no tener que esperar para recibir el producto adquirido (23%).

Gracias al “webrooming”, el nivel de estrés que lleva aparejado habitualmente el acto de ir de compras desciende además notablemente. El 37% de los consumidores prefiere mirar primero en internet y comprar después en las tiendas físicas porque las devoluciones son así más sencillas, mientras que el 46% quiere tocar y sentir el producto en las tiendas físicas antes de adquirirlos.

¿Entonces quien gana showrooming o webrooming?

Pienso que, en realidad, depende del tipo de producto y que se produce un mix de situaciones.

Por ejemplo, un coche difícilmente alguien lo compraría por internet sin verlo antes físicamente y hablar con el vendedor para obtener la mejor oferta posible. Y al revés, comprar un televisor, seguramente  mires todas las opciones por web y después irás al comercio de mejor precio para físicamente comprobar que es modelo que tú quieres y cumple con las expectativas que has leído en internet.

Sin embargo, un libro o un DVD o música, es más «friendly» hacer la compra en un Amazon, pues no aporta mucho más valor el comprarlo en una tienda físicamente, de hecho, el «modelo de negocio» de ese tipo de productos se está adaptando a lo «on line» con iTunes, neox y demás oferta vía e-commerce.

más información en: webrooming, ¿la tabla de salvación de las tiendas físicas? : Marketing Directo

Cómo aprovechar la nueva tendencia del showrooming si tienes tienda física y online

 

¿Todas las empresas deberían estar en las Redes Sociales?

Social Medias. Redes Sociales
Social Medias. Redes Sociales

En genérico si deberían tener presencia y estar en las Redes Sociales. Pero no todas las actividades o empresas tienen «necesidad» o ni siquiera «le aporta valor».

Para ello, yo sugiero, tener en cuenta las siguientes premisas:

Lo primero es estudiar si tu entidad/cliente «objetivo» se encuentra en las redes sociales y le puedes «aportar valor». Casos de éxito: http://www.puromarketing.com/42/18112/casos-exito-demuestran-potencial-beneficios-social-media.html

Segundo  «en qué redes» tiene suficiente «masa social» para abordar una campaña y/o un canal de contacto (privado o público). Diferencio entre privado o público porque en no necesariamente toda pregunta o comunicación tiene que ser pública, un canal privado de twitter puede ser de valor o incluso un canal de video en YouTube con material exclusivo, privado, puede ser el valor añadido adecuado.

Tercero realizar una planificación dentro de un Marketing «Media Mix», es decir, pensar en las Redes Sociales como «el medio único» de promoción no tiene sentido en todos los casos. Hay que investigar si es necesario un Media Mix (un mix de medios) que pueden incluir TV, Radio, Prensa … etc , «mass medias» (medios masivos) que hoy por hoy son esenciales para una imagen de marca.

Cuarto, cálculo de costo y ROI. Es decir, no se debe de convertir en un «lastre» para la empresa si no aporta nada. O sea, no estar por estar en las Redes Sociales. Si, después de un estudio, el costo no es asumible, no tiene sentido. El ROI no tiene que ser necesariamente tangible, puede ser intangible, puede verse beneficiado tangencialmente, por ejemplo, con muchas visitas o seguidores que aporten una mejora de la imagen de marca.

Quinto. La implementación debe realizarse por profesionales  (internos o externos) del Social Media. Es mejor no hacer nada que dejarlo en manos de no profesionales de la comunicación, gestión y medio, que pueden transmitir una imagen de dejadez, desorden, ilegalidades, etc, incluso de provocar una crisis. Ejemplo de caso de crisis: http://www.maytevs.com/caso-de-crisis-en-social-media-controlamos-a-nuestro-community-manager/

En conclusión. Estar en las Redes Sociales (RRSS) , debe pasar por una planificación, un ROI y una implementación por profesionales Community Managers para que no ocurra el efecto contrario de lo que se buscar.

13 Formas de Cómo Fallar al Implementar Scrum (Metodologías Agiles)

Una de las mejores formas de aprender es de los fallos. En éste resumen de cómo fallar al Implementar Scrum (Metodologías Agiles), tenemos algunas claves importantes.

Scrum proporciona un marco de procedimientos para ayudar a obtener beneficios de los principios ágiles. Scrum se ha demostrado eficaz muchas veces, en numerosos proyectos, a lo largo de multiples industrias. Es un conjunto bastante simple y directo de prácticas y directrices que (normalmente) dará como resultado una mayor adaptabilidad al cambio, mejora de la productividad, productos de mayor calidad y clientes más felices (a comparación de metodologías en cascada -Waterfall-). Son tan simples y sencillos estos métodos, que muchas organizaciones se esfuerzan por obtener los beneficios de «Agile».

A través de mi experiencia desde 1999 de implementar proyectos ágiles, he sacado unas conclusiones de porqué fallan al adoptar Scrum algunas de las organizaciones que quieren implementarlo.

Veamos las 13 Formas de Cómo Fallar al Implementar Scrum (Metodologías Agiles).

1. Temor de compromiso

Cada día parece que más personas promocionan los beneficios de Agile. Sin duda, a menudo hay muchas cosas que pueden obtenerse mediante la adopción de prácticas ágiles, pero si usted solo se queda con las guindas de las prácticas que son más fáciles de adoptar, o aquéllas que mejor se adapten a su organización, usted probablemente perderá el tren del valor real que aportan las metodologías ágiles. Los principios ágiles se derivaron de décadas de observaciones de lo trabajado en proyectos exitosos y de lo que no funcionó en los que no. Y la práctica de aplicar estos principios al desarrollo de productos ha sido refinada  en los últimos diez años, las metodologías ágil toman lecciones de principios Lean, como Kanban (cuyo origen se remonta a mediados del siglo XX).

Si desea obtener todo el potencial que ofrece Agile, no puede coger a mitad de camino y llorar cuando no se cumplen con las expectativas. Y no debe de apoyarse       en las prácticas ágiles para resolver sus problemas. Ágil es una herramienta muy buena en resaltar ineficiencias en sus procesos de desarrollo de software, pero una vez que esas cuestiones se hacen visibles a través de métodos ágiles, corresponderá a las personas de su organización el resolverlos. Así que si vas hacia «ser ágil» , a continuación, hay que hacer el compromiso de adoptar todos los principios identificados en el manifiesto ágil.

2. La falta de disciplina

Proyectos ágiles exitosos requieren interacción y colaboración. No sólo entre el equipo de desarrollo y de los clientes (o área de negocio), sino también entre sí. Esto no es facilitado a través de equipos funcionales, que simplemente aceptan artefactos de un       equipo, agregan valor y luego va a otro equipo. Los equipos deben ser cruzados. Así que si su organización tiene equipos independiente en áreas, localización, gestión del producto o equipo de instalaciones, entonces prepárate a reorganizarlo si deseas tener éxito con el «Agile». Todas las disciplinas de ingeniería de software (obligatorio) deben completarse dentro de una iteración. Una historia de usuario debe ser desarrollada íntegramente, desde principio a fin, desde los requisitos hasta la implementación, dentro de una iteración. Una vez una historia que se hace, se hace. Si no eres capaz de completar ese ámbito dentro de una iteración, entonces sus historias son demasiado grandes o tus iteraciones son demasiado cortas. También es importante desarrollarlo justo a tiempo. Sólo escribir tantos requisitos como pueden ser completamente diseñado (dentro de una iteración); desarrollo sólo lo que puede aplicarse completamente (dentro de una iteración); aplicar sólo lo que puede ser completamente probado y validado (dentro de una iteración); y así sucesivamente. Esto le permitirá adaptarse rápidamente a los cambios en el mercado, en los requisitos o las requerimientos de los interesados.

3. Una persona cumple varias funciones

Scrum define tres funciones para facilitar las prácticas ágiles. El propietario del producto representa los intereses de todos los interesados del proyecto, asegura el equipo persigue una visión común, posee el product backlog y garantiza el buen rendimiento de la inversión. El ScrumMaster conduce la ejecución del proceso Scrum, enseña los valores de scrum y prácticas a todos los implicados en el proyecto, asegura que todo el mundo sigue sus normas y prácticas y elimina los obstáculos para el éxito del equipo scrum. El equipo de Scrum decide cuántos elementos sobre la historia de producto se comprometerá a completar en un sprint dado y cómo entregar esos elementos. El equipo de Scrum entonces debe cumplir esos compromisos.

Estas funciones funcionan muy bien en la puesta en práctica de los principios ágiles. Sin embargo, ninguno de estos roles son efectivos si se combinan con otro papel por la misma persona. Como ejemplo, el papel de propietario del producto nunca se cumplió por la misma persona cumpliendo el papel del ScrumMaster. Si el proceso funciona bien, debería haber algún conflicto (saludable) entre el propietario del producto y ScrumMaster. Mientras el propietario del producto está trabajando para garantizar que el equipo está trabajando lo más rápido posible, para ofrecer el mayor valor, con el menor costo, el papel de ScrumMaster es garantizar que el equipo está siguiendo el proceso definido, trabajando a un ritmo sostenible. Muchas veces, estos objetivos pueden estar en conflicto unos con otros. Pero es el consenso entre estas dos funciones que garantiza el mejor resultado. Otra responsabilidad del propietario del producto es aceptar o rechazar los productos de trabajo entregados al final del sprint. Si el propietario del producto es también un miembro del equipo, sería difícil ser objetivo para determinar si un producto es aceptable para el lanzamiento. Y si un ScrumMaster es un miembro del equipo, esa persona tendría dificil identificar defectos en un proceso en el cual es un participante activo. El ScrumMaster también tendría menos tiempo para       eliminar impedimentos como un miembro del equipo. Para obtener todo el potencial de Scrum, debe mantener estos roles separados.

4. No se puede cumplir con los compromisos de Sprint

Trabajar en Sprint ofrece ventajas en varios aspectos. Se permite a los equipos trabajo ininterrumpido en un pequeño trozo de la funcionalidad y el desarrollo que la funcionalidad completa. Cuando esta función se completa al final del sprint, el equipo presentará lo que fue construido para obtener retroalimentación de los participantes en el proyecto (que se incorporará en los Sprint sucesivos). Y, mostrar a los clientes software que funciona ,sobre una base predecible, es la mejor manera para construir confianza. Cuando el cliente puede ver la realización de lo que se prometió al comienzo del Sprint, es difícil no confiar en un equipo cuando se dice que puede ofrecer algo en un Sprint. Por supuesto, esta confianza se disipa rápidamente cuando el equipo falla en cumplir con su compromiso asumido en el comienzo del Sprint, especialmente para los experimentados equipos de Scrum.

Una vez que un equipo Scrum tiene cinco o más sprints en su haber, deben tener una idea bastante buena en cuanto a su velocidad, asumiendo que la composición del equipo y la capacidad de mantenerse (al menos) bastante consistente. Esta velocidad debería permitir al equipo mantener un ritmo de desarrollo sostenible en el largo plazo y siempre entregar un determinado número de puntos de cada sprint. Una cosa que interfiere con su capacidad de entregar constantemente un cierto grado de alcance es, por ejemplo, si el Scrum Master permite las interrupciones que se producen fuera del equipo.

Cuando se ejecuta un proyecto ágil, tiene que haber un acuerdo entre el equipo de desarrollo y otras partes interesadas del proyecto para que el equipo se pueda comprometer a cumplir sus promesas, así que cualquier cambio en el alcance o los requisitos (o cualquier otra cosa) debe esperar hasta el sprint siguiente. Esto permitirá al equipo ir codo con codo en el desarrollo sin tener que preocuparse por distracciones externas o interrupciones. Esto no sólo le permitirá al equipo cumplir con su compromiso, sino que también ayudará a mejorar la productividad y la calidad del producto.

5. Grupos de individuos

Agilidad viene en muchas formas. Ser capaz de adaptarse rápidamente sus procesos es un método de ser ágil. Esto requiere trabajo en equipo. No sólo un grupo de ingenieros individuales o especialistas inflexibles, trabajando en su propia pieza, si no un grupo de profesionales trabajando juntos y hacer sacrificios para alcanzar la meta del equipo. A menudo, los equipos de desarrollo tienen personas que trabajan sólo en ciertos tipos de tareas. Es sin duda importante tener personas con conocimientos especializados; de hecho, a menudo es necesario a lo largo del desarrollo de productos. Pero eso no significa que los especialistas sólo deben trabajar en su especialidad. La capacidad de responder rápidamente a los cambios requiere que los miembros del equipo que están dispuestos a trabajar en las tareas que se necesitan en ese momento. Es muy común en equipos de Scrum inmaduros que los miembros del equipo sólo hacen desarrollo, validación o administración de la configuración. Para ser verdaderamente ágil, todos los miembros del equipo deben estar dispuestos a llenar los vacíos que se produzcan. Lecciones de desarrollo Lean nos han enseñado que, si queremos lograr el flujo de trabajo alto, debemos desplazar recursos para aliviar los cuellos de botella cada vez que ocurren. Esto significa que los miembros que tradicionalmente sólo hacen arquitectura, diseño o desarrollo debe estar dispuesto a trabajar en las tareas de diseño, validación o implementación en cualquier momento que sea necesario. Necesitan salir de la costumbre de elegir sólo las tareas de su especialidad. Si bien es importante contar con miembros con conocimiento de dominio específico, es igualmente importante que los miembros del equipo sean cruzados.

6. Falta de auto organización

El valor de la inteligencia de grupo se ha documentado muchas veces y en una amplia variedad de circunstancias. Dos cabezas piensan mejor que uno… y mejor si son siete. Numerosos estudios han demostrado también que la auto-gestión de equipos son más productivos y son mejores en la solución de problemas que los equipos dirigidos por un individuo. Si se les dejan auto-organizarse y tomar decisiones en cuanto a cómo resolver mejor los problemas, los equipos auto gestionados tienden a basarse en la inteligencia colectiva y la experiencia del grupo, en comparación con la de un jefe de equipo. Este enfoque cooperativo no sólo hace al equipo más productivo, sino que además les hace mejores para identificar las oportunidades y el empleo de métodos de mejora. Con el tiempo, el equipo comenzará a funcionar como una unidad, en lugar de un conjunto de personas tras un individuo.

7. Revisiones de Sprint ineficaz

Las Sprint Reviews son algo más que reuniones para revisar lo que se logró durante un sprint. Son oportunidades de oro para poner su proceso empírico en juego. La mayoría de las organizaciones adoptar prácticas ágiles para mejorar su agilidad – su capacidad de adaptarse eficazmente al cambio. Las Revisiones de Sprint facilitan esa capacidad dándole la oportunidad de ver de primera mano lo que fue el desarrollo y la oportunidad de ofrecer comentarios, críticas o sugerencias de todos los interesados del proyecto. Esta información no sólo es bienvenida, se debe alentar. Ayuda a orientar el desarrollo de productos haciendo pequeños cambios en el plan de liberación entre cada sprint. También ayuda a mitigar los riesgos de forma temprana. Los ojos más centrados en la evolución del producto y cuanto antes esto se hace, más eficaz será detectar y corregir problemas.

También muchos equipos utilizan los Sprint Review como una reunión para revisar historias completas, tareas y defectos y hacer cambios en sus herramientas de gestión de procesos. Este tipo de agenda es garantía de que no se pierda en una de las prácticas más valiosas que ofrece Agile.

Por lo tanto, es fundamental que los exámenes de Sprint sea exhibir programas funcionales Y asegúrese de dar a conocer estos Sprint Review a todos los interesados ​​en el proyecto y sean conscientes de ellos. Todos deben ser invitados a asistir y participar. Todos y cada uno debería sentirse lo suficientemente cómodos para dar información, sin temor de ser ellos mismos criticados. Esto es lo que hace un producto de éxito: la incorporación de ideas de un grupo diverso de personas que tienen un interés en el éxito del producto.

 

8. Integración de cascada de hitos

Los métodos de desarrollo ágil están diseñados para maximizar el valor para el cliente. Continuamente centrándose en las necesidades del cliente, se mejora enormemente el éxito del proyecto. Esto no es el caso de ciclos de vida de cascada (Waterfall). Los métodos de cascada son orientados a tareas, mientras que ágiles están orientados al valor. Debido a estos principios contradictorios, es contraproducente intentar alinear un ciclo de vida de desarrollo ágil con hitos en cascada. El plan de Agile es entregar valor al cliente temprano y a menudo, mientras se adaptan fácilmente y eficazmente para cambiar. El plan de en cascada es completar un conjunto predefinido de tareas a tiempo y dentro del presupuesto y se utilizan para entregar un producto que se ajusta a un conjunto de requisitos definidos cerca del inicio del proyecto. Hitos, como alfa y Beta, se utilizan en los ciclos de vida en cascada para ayudar a medir el progreso. Pero utilizando métodos ágiles, el progreso se mide desde el trabajo acabado: software funcional. Si un proyecto en cascada está al 30% hecho, no tendrás absolutamente ningún software funcional. Si un proyecto ágil está al 30% hecho, tendrá un 30% de las características del producto totalmente terminados y entregado a su cliente. Intentar integrar estos dos ciclos de vida no le permite obtener los beneficios de desarrollo iterativo de (Agile), por no hablar de que no tiene sentido. Y si su organización intenta medir el progreso de un proyecto ágil mediante el uso de hitos de la cascada, falla completamente. Este comportamiento nos ocurre cuando se adopta de forma superficial métodos ágiles. No interrumpir prácticas Agile por intentar integrar los principios de la cascada.

9. Definición de procesos alrededor de herramientas

Scrum ha sido cuidadosamente planificada para ayudar a los equipos de desarrollo de producto a poner en práctica los principios ágiles. Un marco de proceso Scrum proporciona métodos, directrices y mejores prácticas para ayudar a obtener los beneficios de apoyo de principios y valores ágiles. Definiendo sus procesos basados en este marco, se adapta mejor para facilitar la adopción de Agile. Sin embargo, si define sus procesos alrededor de una herramienta específica, como para la administración del ciclo de vida, estará limitado a la visión de quienes desarrollaron esa herramienta. Incluso si tuvieron su industria específica y su dominio en mente, es muy improbable que abordaran todas las cuestiones que su organización se enfrenta al desarrollar y ofrecer sus productos. Los procesos deben ser diseñados por la organización, para servir a sus metas y objetivos. Nadie más puede hacerlo, sobre todo no un equipo de desarrollo que nunca ha interactuado con su organización. A menos que la herramienta se desarrolla en casa, ninguna herramienta cumplirá con todos los aspectos de su proceso.

10. La falta de formación

Una vez que su organización adopta Agile, la formación es fundamental para que los interesados comprendan sus funciones y responsabilidades y cómo ejecutar métodos ágiles de manera que obtendrá el máximo valor. También es importante que entiendan los principios ágiles y cómo su práctica puede mejorar sus productos, junto con la satisfacción del cliente. Incluso si todo el mundo tiene experiencia «desarrollando ágil», no puede asumir tengan la necesaria, capacidad para ser exitosos con proyectos ágiles. Para garantizar que todo el mundo está en el mismo campo de juego y tiene expectativas similares (al menos) de qué es Agile, deberá ofrecer formación de alguien que tiene la experiencia (preferiblemente dentro de la industria) y quien tiene un historial comprobado de dominio de éxito dentro de un similar (si no el mismo). Esta formación debe adaptarse a su organización por un experimentado entrenador ágil o entrenador que ha invertido tiempo en la comprensión de su organización. Establecer una base con los conceptos básicos, y después de que sus equipos apliquen de forma efectiva de esas prácticas, pasar a una formación más avanzada. Puede ser prudente seguir con la formación de base tras el primer año para asegurar que nuevos actores (stakeholders) entienden el fundamento y las expectativas de la organización como un todo.

11. Scrum no es Kanban

Otro error tipico es el de intentar meter procesos que pertenecen al área de mantenimiento en un ciclo Scrum. Hay que diseccionar adecuadamente cada fase o ¿Historia – Tarea? para decidir si es Scrum o es Kanban. No todo es Scrum. Nos encontramos en muchos casos equipos alargando Sprints a los Product Owners para poder encajar acciones de resolucion de Bugs, Versionado, Refactoring, Fly Updates (actualizaciones al vuelo)… etc. Cada historia, proyecto, dominio es diferente y no siempre todo se puede encajar en un Sprint de Scrum. La experiencia de un Scrum Master es esencial para ahorrar tiempo y productivizar. .

12. Si haces Scrum haz KISS (Keep It Simple Stupid)

Los técnicos informáticos tienen la tendencia a complicar el código «buscando la simplicidad» en el número de líneas de código. Un código «elegante» no significa encapsular hasta la locura funciones, procesos o código de testeo. Un código elegante es aquel que es entendido por cualquiera y no solo por el que lo ha escrito. Se debe limitar en lo posible Interfaces, Polimorfismos, TDDs… etc. De esa manera, entre otras cosas, el cambio de un técnico por otro (ver punto 5, «Grupos de individuos») está más alineado con la «agilidad» de poder hacerlo. Cuanto menos KISS menos SCRUM. Estamos haciendo «verdadero» Scrum directamente proporcionalmente a lo que nos acerquemos a codificar lo más KISS posible. .

13 Hacerlo uno mismo, ser ágiles

Sobre el papel, Scrum es un marco bastante simple. ¿Leer un par libros, asistir a una reunión de grupos de usuarios aquí y allá, seguir algún blog … ? Bien, mientras que Scrum puede ser simple, no es necesariamente fácil. La puesta de Scrum en práctica y obtener buenos resultados, realmente puede ser bastante desafiante. Si es sólo una cuestión de aplicar métodos documentados en un libro, probablemente sería bastante fácil. Pero es el factor humano el que dificulta el Scrum. Se puede aprender mucho por estudiar casos en Scrum, pero dos proyectos no son iguales. Y menos que se tenga la experiencia de luchar para resolver los problemas, entrenamiento y motivación de los individuos, frente a las críticas y la defensa de los principios de Agile, encontrar el éxito es bastante difícil. Para tener éxito con el Agile, especialmente al inicio, realmente necesita tener un entrenador experimentado ágil. Esta persona puede ayudar a definir un plan de producto, asegúrese de que las funciones y responsabilidades se entienden bien, ayudar a evitar obstáculos comunes y asegurar que está entregando valor poniendo en práctica los principios ágiles. Su entrenador debe provenir fuera de su organización. Aunque es de ayuda tener conocimiento del dominio de su producto, facilita aún más el trabajo tener un entrenador con una perspectiva discriminativa de su organización. Si está comprometido a ser ágil, DEBE COMPROMETERSE A HACERLO BIEN.