Avenida O

Hablemos de software innovador. Episodio 2

Natalia C. Alfaro para El Observador En este segundo capítulo de la mini serie Hablemos de software innovador vamos a…

Por Blog

Tiempo de Lectura: 3 minutos
Hablemos de software innovador. Episodio 2
Facebook Twitter Whatsapp Telegram

Natalia C. Alfaro para El Observador

En este segundo capítulo de la mini serie Hablemos de software innovador vamos a entender cómo una plataforma tecnológica exitosa va mucho más allá de programar código que falle poco. Si no que más bien inicia desde el entendimiento real del problema. En caso que se haya perdido el episodio anterior de click aquí para leerlo. 

Siendo completamente honestos a pesar de los esfuerzos de que los indicadores corporativos funcionales de bienestar y cohesión tomen un papel fundamental en determinar el valor de una empresa -con excepción de las ONG y otras fundaciones sin fines de lucro- ustedes y yo trabajamos día a día para hacer dinero.

Nos abocamos tantísimo en aumentar capacidad de producción, triplicar ventas, optimizar al cuadrado todos los recursos.

También a buscar la pócima mágica para lograr entrar en ese camino a la transformación que lo que hacemos es agregar capas sobre capas a procesos, herramientas sobre herramientas y fallos sobre fallos…

Otros dirán bueno también aprendizajes sobre aprendizajes y si… al final todos los caminos llegan a Roma pero usted decide si ir en una lancha o un avión. 

Si esto le está pasando…

Entonces, si esto le ha estado pasando a la empresa donde trabaja una de las razones más evidentes es que se está enfocando tanto en dar soluciones con gratificación inmediata que no está entendiendo el problema real que debe resolver. (póngale la escala que sea: proceso o producto). 

Puntualmente, si usted utiliza el marco de trabajo SCRUM el dueño de producto junto con los otros miembros del equipo SCRUM antes de ponerse a proponer cualquier idea y solicitar a diseño unos “wireframes” para luego escribir historias de usuario debería de mínimo haber utilizado las primeras 3 fases del proceso de design thinking:

  1. Empatía: una hipótesis del problema y hacer una primera interacción con un taller a profundidad con el cliente.
  2. Definición: realizar sesiones de definición y análisis de nicho, avatar, customer journey y porqué no un análisis de las 5 fuerzas de porter.
  3. Ideación: la inflatable sesión de lluvia de ideas (aunque no es el único formato) para luego tener otra sesión de presentación y pivote de ideas con el cliente (esto les va aumentar las probabilidades que les acepten el prototipo sin tantos cambios) y si encontramos una solución procedemos a entrar en el flujo de desarrollo ágil y en caso que no se encuentre una solución adecuada ir de regreso a la etapa de empatía pero NO ir a desarrollo ya que perderá mucho tiempo y dinero. 

Como ven, a pesar que en teoría estoy proponiendo “dar más vueltas” al inicio esto nos va a proporcionar muchos beneficios entre ellos:

  • Mayor seguridad de aportar valor al cliente con un proceso o producto que sea escalable.
  • Que se encuentre previamente validado con el mercado.
  • Contar con historias de usuario y criterios de aceptación sean transparentes como el agua.
  • Permitir un plan de entregas donde se note el incremento real del producto porque pudimos planear mejor, hacer monitoreo efectivo y corregir de una manera adecuada sobre la marcha.
  • Como consecuencia reduce la cantidad de “bugs” o errores del software posterior a la entrega. 

¡No se pierda el próximo episodio donde hablaremos puntualmente sobre el ciclo de desarrollo!