mikeagile-blog - Tumblr blog

[mikeagile-blog]

Teoría Cliente-Céntrico

Ser cliente-céntrico significa llevar adelante una estrategia de comunicación en la que el cliente es el centro de todo el modelo de negocio.

Continuando con el master The Power MBA en la parte de Marketing, me parece interesante compartir algunos ejemplos de cómo segmentar a los clientes de tu modelo de negocio.

En primero lugar se habla de las la variables clásicas que podemos utilizar como son :

Geográfica: ¿Dónde viven? País, ciudad...

Demográfica: ¿Quienes son? Sexo, edad..

Firmográfica: ¿Quienes son? Tipo de empresa, sector...

Psicográfica: ¿Cómo son? Urbano, pijo....

Actitudinal: ¿Cómo ven el mundo? Opiniones, reacciones, que consideran importante...

Pero, también deberíamos tener en cuenta en base a la relación con nuestro negocio:

Un consejo, normalmente se suele caer en dos errores típicos a la hora de conocer o crear de customer personas:

Se suelen utilizar plantillas que detallan información que no suele ser importante para tu producto o servicio.

No se consideran las variables realmente importantes en tu modelo de negocio.

3 ejemplos diferentes modelos de negocio:

Primero: En TPMBA tienen en cuenta estas variables de segmentación:

Donde aconsejan construir los customer personas con estas ideas:

Pensar Clientes reales.

Analizarlos con esas variables y entenderlos mejor.

Tener varios customer personas

De los ejemplos de customer personas que han sacado son:

Personas soñadoras que buscan un cambio, un nuevo negocio y donde da igual la edad y otras variables típicas

Los técnicos, ingenieros y/o arquitectos buscan crecer profesionalmente y necesitas ampliar las ideas negocio.

El clásico profesional que le gusta lo que hace pero quiere sentirse actualizado con las nuevas tendencias.

Segundo:  Loewe, que nos cuenta sus variables para sacar sus customer persona:

¿Quién es mi cliente?

¿Para que te compra?

¿Para quién te compra?

¿Dónde y como te compra?

Tercero: en mi eCommerce travisStore.es (@travis.store en instagram)

Consideramos que vamos concretamente a un modelo de negocio de nicho de mercado, es decir, nos centramos en un producto muy claro y para unos clientes muy concretos para vender los collares martingale para galgos.

Las variables que utilizamos para construir nuestros customer personas son:

Actitudinal: clientes que tenga una aptitud de amor por los animales y pensamientos de adoptar, concretamente galgos.

Geográfica: aunque no prioritario nos centramos en España ya que es el lugar donde se abandona la raza “galgo español” pero concretamente ponemos foco en las comunidades donde hay mas adopciones.

Social: utilizamos esta variable ya que los collares que vendemos tienen un componente social, ya que donamos parte de los beneficios a protectoras.

[mikeagile-blog]

Volumen, velocidad y valor.

Recientemente he visto una charla del presidente de JobAndTalent dentro de ThePowerMBA y me he quedado con un concepto clave a la hora de montar un negocio o incluso ofrecer un servicio.

El equipo de JobAndTalent empezó su negocio como una plataforma para ofrecer anuncios de trabajos para competir directamente con los “clasificados” como pueden ser infoEmpleo o infoJobs. 

Por el 2016 tuvieron que “pivotar” su modelo de negocio, gracias a sus análisis, experiencia, datos, clientes... pudieron cambiar, se convirtieron en una plataforma para competir directamente con las ETT, empresas de trabajo temporal.

Algunas de sus claves, por lo que comenta su presidente Félix Ruiz, fueron el volumen, la velocidad y la calidad.

Si comparamos el modelo “CANVAS” de una ETT:

Con su modelo de “CANVAS”:

Podemos deducir que respecto a esas tres claves:

El volumen de datos es un factor importante, o dicho de otra manera, tener muchos usuarios gracias al “network effect” y “segmentación en marketing” es fundamental para conseguir gran cantidad de información de tus usuarios y del mercado.

La velocidad debería ser algo prioritario, y mas si se trata de una “startUp tecnológica”, donde la APP o el Big Data que hay por detrás son los apoyos tecnológicos que se requieren para ganar esa velocidad de la que hablan, tener un reducido time to market.

La calidad viene dada de su éxito en la segmentación y saber separarar datos, entender al usuario, experiencias y atención al cliente.

Por comparar, he visto que en muchos cursos de los fundamentos del Big Data hablan de los mismo pilares que en JobAndTalent y ThePowerMBA.

Tres pilares dentro de un contexto de Big Data

Volumen: Se refiere a la cantidad de datos que son generados cada muy poco tiempo. Realmente es la característica más asociada al Big Data, ya que hace referencia a las cantidades masivas de datos que se almacenan en diferentes bases de datos con la finalidad de procesar dicha información.

Velocidad: Constantemente hay datos en movimiento por las constantes interconexiones que se realizan, es decir, a la rapidez en la que son creados, almacenados y procesados en tiempo real. Y, en el mundo digital tan cambiante es imprescindible la velocidad a la hora de tomar decisiones en cualquier campaña de marketing o a la hora de ofrecer un servicio a un cliente.

Valor:  La incertidumbre de los datos, es decir, al grado de fiabilidad de la información recibida puede ser dudosa, por ello es necesario invertir tiempo para conseguir datos de calidad que aporte valor aplicando soluciones y métodos que puedan eliminar datos imprevisibles.

[mikeagile-blog]

Business Model Canvas

Recientemente estoy cursando de The Power MBA y arrancando un proyecto personal, concretamente una tienda online www.travisStore.es. El primer módulo de formación se trata de aplicar el modelo Canvas, por lo que comparto el modelo del eCommerce que he montado.

[mikeagile-blog]

Product Management

Después de casi cinco años de project manager en BBVA, coordinando los desarrollos de las apps para Android, iOS y versión HTML5, aplicando metodología ágiles, scrum y SAFe a gran a escala, he aterrizado en un medio de comunicación, Vocento, donde el negocio es muy diferente y nos centramos más en producto que en proyectos.

El objetivo es sacar producto coordinando a diferentes equipos de grupo como son:

Diseño

UX

Maquetación

Desarrollo Back-End

Desarrollo Front-End

Infraestructura y devOps

¿Cómo cuadran con sprints del producto con tantos equipos?, uno de los consejos es reducir los sprints al mínimo, por ejemplo una semana consiguiendo entregas cortas, e intercalar funcionalidades, de diferentes equipos para no tener a otros bloqueados. 

Pero, hemos conseguido sacar producto digitales:

Desarrollo Mobile First de infoPlayas https://goo.gl/InWBG5

Desarrollo Mobile First de infoEsquí https://goo.gl/TfQA6z

[mikeagile-blog]

Principios ágiles

El retorno temprano de la inversión, medible, mediante incrementos definidos e iterativos del producto (sprints).

La alta visibilidad del avance del proyecto permite identificar y resolver temprano los problemas para prever si aportar de valor.

Colaboración continua del cliente a lo largo de todo el ciclo de desarrollo del producto.

Visibilidad del dueño del negocio para tomar decisiones necesarias para cumplir sus metas.

Mayor importancia a la adaptación a las necesidades cambiantes del negocio que a los cambios a los requisitos.

Reducción de los desperdicios del producto y del proceso.

¿Como aporta valor el desarrollo de un proyecto agile?

Se adapta a las necesidades cambiantes del negocio, dándole a la organización la posibilidad de agregar, cambiar, o eliminar requisitos más flexiblemente.

Hay una retroalimentación temprana y constante por parte del cliente dado que el cliente está involucrado a lo largo de todo el desarrollo. Por eso, terminarán con un producto final que ellos usarán y les gustará.

El dueño del negocio está empoderado y puede recibir y revisar información crítica necesaria para tomar decisiones para dirigir el proyecto hacia la meta a lo largo de todo el proceso de desarrollo.

Una medición temprana del retorno sobre la inversión permite tener entregables definidos en cada iteración, temprano en el proceso.

Una alta visibilidad del avance del proyecto lleva a una indicación temprana de los problemas.

Desarrollo incremental en lugar de una única entrega completa al final del proyecto.

Reducción de desperdicios del producto y del proceso.

Los principios y prácticas ágiles son disciplinadas y orientadas al valor.

[mikeagile-blog]

Historias que aportan valor

En la metodología de scrum las historias de usuario son los requisitos del software que nos aporta el cliente. Estas historias forman parte de la validación del producto, es decir, son pruebas de aceptación que tiene que aprobar el software.

Las historias de usuario son ejemplos de como funciona el software, si queremos entregar un software de calidad, debemos automatizar estas historias para que en cada sprint se sigan cumpliendo los requisitos del cliente.

Además de que estas historias son la documentación viva del proyecto, vamos a conseguir que el propio cliente nos escriba las pruebas. Si se trata de colaborar con negocio y con el cliente, ¡vamos a trabajar juntos para que las historias de usuario aporte valor!.

El BDD (behavior-driven development) y las historias de usuario son lo mismo. Por lo que recomiendo escribir las historias de usuario en lenguaje Gherkin con el famoso framework cucumber.

Como hemos comentado estos escenarios/historias de usuario sirven como documentación de la funcionalidad del proyecto. ¿Debemos automatizar todo?, en varias ocasiones puede llegar a ser más costoso hacer la implementación de la prueba que el propio desarrollo, por ello hay que automatizar lo que más aporte valor. Tengamos en cuenta que las pruebas automáticas consumen recursos, tiempo, servicios.... aunque no se implementen, siempre aportan valor para que el desarrollador entienda como debería funcionar el software.

[mikeagile-blog]

ATDD sin integración continua, no funciona.

Cuando desarrollamos un proyecto con ATDD & Scrum en un primer sprint se entrega una funcionalidad del software con pruebas de aceptación automáticas, si pasan esas pruebas el código se integrará con Release Candidate. 

¿Que hacemos en los siguientes sprints?

Las pruebas de aceptación tienen que pasar a regresión, y para próximos sprints además de pasar las nuevas pruebas de aceptación para la integración con RC, se deben de pasar TODAS las pruebas de regresión. 

Si no tenemos bien montada la integración continua no funciona, se van acumulando test, se generan falsos positivos, largas esperar en tiempos de ejecución de pruebas, entornos de desarrollo caídos, exceso de mantenimiento de código de test, etc. Las soluciones a esto son:

Lanzar test en paralelo: si desarrollamos HTML5 es tan sencillo como levantar varias instancias en un navegador, lanzar diferentes pruebas y unificar los resultados. Si se desarrollan apps nativas lo tenemos un poco más complicado, existen empresas que ofrecen alquiler de dispositivos para lanzar scripts de pruebas. Por ejemplo appthwack recientemente comprada por el gigante Amazon AWS Devices Farm.

Sandbox, mocks o servicios virtuales: Para lanzar pruebas de un frontal a gran escala no podemos depender de los entornos previos y no debemos abusar de los servicios de producción, podemos saturar el sistema y consumir nuestro producto nosotros mismos. Es interesante montar un sandbox con webservices mocks para estas pruebas. Un servicio interesante puede ser CA LISA.

Planes desatendidos: en el momento en que el equipo no esta desarrollando, lanzar la full regression de las ramas para consumir menos recursos del sistema.

Para montar la integración continua detallo unos planes necesarios para un desarrollo agile.

CI-Feature: Construye la aplicación, lanza los test de aceptación y despliega en entornos previos la rama/feature si todo ha ido bien.

CI-Feature-Test-Regression: Lanza los test de regresión sobre la rama/feature que se esta trabajando. Tener cuidado con este plan, es más interesante lanzarlo en horas en las que el equipo no esta desarrollando para no consumir recursos. 

Create Feature From RC: Sencillo, crear ramas/features desde la release candidate.

Create Hotfix from Master: Crear ramas/features desde la release candiate por si tenemos que apagar un fuero en producción.

Promote Feature to RC: Este plan se ocupa de construir la aplicación, lanzar los test de aceptación y los de regresión. Si todo va bien nos mezclaremos con RC y los test de aceptación pasarán a formar parte de la regresión. Y, por supuesto su despliegue para que el product owner & stakeholders puedan probar el producto antes de sacar release y darnos su valioso feedback.

Promote Hotfix to Master: Si tenemos que apagar un fuego, tendremos que promocionar la rama hotfix a master. Debido a los tiempos de despliegue en este plan no se suelen pasar todas las pruebas, pero si es interesante lanzar unas pruebas CORE de que la aplicación va a ofrecer el servicio esperado. A estas pruebas CORE las podemos llamar smokeTest.

Promote RC to Master: Si tenemos RC estable con las pruebas de regresión/monitorización, podremos pasar de RC a Master tranquilos con buena calidad y con la certeza de que ya se han pasado pruebas.

Regression/Monitoring de RC: Un plan que se debería lanzar todas las noches para no encontrarse posibles bugs antes de sacar versión. Las pruebas automáticas están para lanzarlas las veces que sean necesarias. En varias ocasiones hasta que no se lanzar un test X veces no se detecta un bug, hay que pensar con un tester e intentar romper la app. Mejor darse cuenta en tiempo de desarrollo que en producción.

¿Regression/Monitoring de Master?: En este plan conviene lanzar los smokeTest o pruebas CORE para tener la tranquilidad de que producción esta estable y de que nos damos cuenta de los errores antes que los clientes/usuarios de nuestro producto.

!Que la mejora continua te acompañe!

[mikeagile-blog]

QuX (Quality User eXperience)

¿Cuando se deben escribir los casos de uso de un project?

Empezamos a desarrollar un project y contamos con la gran ayuda de diseñadores y expertos en la usabilidad, les contamos las ideas de lo que queremos desarrollar para que nos “pinten” el camino de como realizar la funcionalidad. 

En algunas ocasiones con un diseño, maqueta navegable o prototipo no es suficiente para que el developer empiece su tarea de un modo ágil. Un nuevo concepto QuX (Quality User eXperience), donde el UX escribe los casos de uso navegables para que el maquetador o developer pueda hacer ATDD desde el primer sprint. Pongamos un ejemplo, como diseñador me piden mejorar la usabilidad de una transferencia, en la que entrego el diseño y el caso de uso:

Con este requisito el developer podrá acometer su tarea con mayor facilidad, teniendo claro los caminos de la funcionalidad que va a desarrollar.

Comparto un project que he publicado en gitHub, es un framework para empezar a aplicar la metodología BDD/ATDD en desarrollo Mobile First.

https://github.com/mikeagile/testing4mobileBanking

Enjoy!

[mikeagile-blog]

Desarrollando Mobile First con integración continua.

Debido a la tendencia empresarial de montar un ecosistema centrado en el móvil, es necesario ser ágil para sacar funcionalidad en el menor tiempo posible y con una calidad excepcional, apoyándose en metodología ágiles y herramientas de integración continua.

Con una tecnología multiplataforma OpenSource (HTML5, CSS3 y JavaScript) podremos tener presencia desde una webApp hasta una web de escritorio con un único desarrollo, y, el cual podemos encapsular en diferentes contenedores nativos para poder publicar en los markets como iTunes y google play con herramientas como crosswalk.

Si realmente queremos hacer un desarrollo ágil para poder sacar el MVP (Minimum Viable Product) y poder hacer TTM (Time to Market) sacando nuevas releases cada poco tiempo, necesitamos utilizar metodología scrum e implementar desarrollo dirigido a test ATDD (Acceptance test-driven development). Dentro de cada scrum sprint se tiene que entregar al PO (Product Owner) la funcionalidad desarrollada más los test de aceptación automáticos. Un ejemplo de funcionalidad escrita en cucumber  “Efectivo Móvil” la podemos implementar en ruby con frameworks capybara para web y calaba.sh para apps nativas.

Una vez validada la funcionalidad por el equipo y el PO, estas .feature de aceptación pasarán a ser regresión e integrarse con en la app. Para próximas demos de producto sobre nuevas funcionalidades, al lanzarse estas pruebas de regresión al menos podremos saber que el MVP sigue en perfectas condiciones para poder hacer TTM con la seguridad de que no hemos roto funcionalidades previamente desarrolladas.

¿Cómo y donde lanzar las pruebas?

Es necesario que nos apoyemos de herramientas para la integración continua, bamboo de atlassian es una herramienta en la que podemos configurar tareas desatendidas por cada cambio en el código fuente de la aplicación. Un ejemplo de planes de trabajo podrían ser:

Plan de Aceptación: donde se por cada commit del desarrollador se lanzarán las pruebas como requisitos de aceptación hasta conseguir un ok para dar por finalizada la tarea del sprint.

Plan Regresión: Donde de forma desatendida y por un conjunto de cambios en el código fuente, se lanzarán todas las pruebas de regresión definidas como requisitos de aceptación en sprints anteriores para saber que la aplicación sigue funcionando con la calidad esperada.

Promoción de nueva funcionalidad a RC (Release Candidate):  En la cual se lanzarán las pruebas de aceptación y regresión de la app antes de mezclarse. En este punto, es cuando los test de aceptación formarán parte de los de regresión para futuras promociones.

Promoción a Master: Después de pasar las pruebas necesarias y validaciones por el equipo y PO, debe existir una tarea donde se publicará la versión RC a Master (producción) para que los clientes puedan disfrutar de las nuevas funcionalidades de la app.

Gracias a esta metodología y herramientas de IC, en el caso de tener que apagar un fuego en la app, se puede estar en producción en muy poco tiempo con la app probada automáticamente con los requisitos definidos, evitando largas esperas por validación de equipos de testing.

[mikeagile-blog]

Desarrollo mediante pruebas

Hola, vamos a hablar de las metodologías para desarrollo de software mediante pruebas. A continuación explicamos las diferencias entre TDD, ATDD y BDD.

TDD Test-driven development, es una técnica de pruebas unitarias automatizadas para impulsar el diseño y desarrollo del software con desacoplamiento de las dependencias. El resultado de esta  práctica es un conjunto completo de pruebas unitarias que se pueden ejecutar en cualquier momento para proporcionar información y estado de las piezas del software en el que se está trabajando.

El concepto es "conseguir algo de trabajo ahora y perfeccionarlo más tarde." Después de cada prueba se realiza una refactorización para cumplir las especificaciones definidas. El proceso se itera tantas veces como sea necesario hasta que cada unidad está funcionando de acuerdo con las especificaciones deseadas. Desarrollo basado en pruebas es parte de un paradigma de diseño de software más grande conocida como Extreme Programming (XP).

ATDD Acceptance Test Driven Development, también llamado Storytest Driven Development (STDD). Es una técnica utilizada involucrar a los clientes en el proceso de diseño de la pruebas antes de que comience la codificación. Es una práctica de colaboración entre los usuarios, testers y desarrolladores para definir los criterios de aceptación y convertirlos en pruebas automáticas. ATDD ayuda a asegurar que todos los miembros del proyecto entienden lo que hay que hacer para aplicarlo. Las pruebas se especifican en términos de dominio de negocio, cada función debe ofrecer un valor empresarial real y medible, si dicha no aporta objetivo de negocio tendremos que replantear si realmente hay que desarrollar esa función.

BDD Behavior-Driven Development, combina las técnicas y principios generales de TDD con ideas de diseño de dominio de negocio mediante ejemplos. BDD es una actividad de diseño en el que la construcción de piezas funcionales se incrementan por el comportamiento esperado. El enfoque de BDD es el lenguaje natural mediante ejemplos y las interacciones utilizadas en el proceso de desarrollo de software.

Un equipo que utiliza BDD debe ser capaz de proporcionar una parte significativa de "documentación funcional" en forma de que las historias de usuarios aumentan con escenarios o ejemplos ejecutables. BDD generalmente se realiza con lenguaje natural para entender la funcionalidad de aplicación en lugar de exponer pruebas de nivel de código. Se define en un formato de GWT, “GIVEN WHEN & THEN”