Comprende los básicos de tecnología en producto digital

Hace poco me preguntaron si un buen Product Manager debería saber programar. Bueno, en general me lo preguntan bastante.

Creo que no hay una sola forma de convertirse en Product Manager: puedes venir de un entorno de desarrollo, marketing o negocios y no saber cómo programar. Lo más importante es dominar los fundamentos de varios campos (consulta nuestro artículo sobre carreras de productos), incluido el tecnológico.roduct

Y eso es una buena noticia, porque en este artículo condensado voy a tratar de explicar esos conceptos técnicos que escuchas a diario entre las personas de tu equipo sin entender muy bien lo que hay detrás. Explicado con plastilina, como se suele decir.

La parte del front-end

El front-end se refiere a lo que vemos, a la parte visible del producto (app o web). La interfaz con la que interactúan los usuarios (también se conoce como por «Interfaz Humano-Máquina» por sus siglas IHM). Pongamos un ejemplo: una panadería. El front-end de una panadería serían todos esos alimentos o productos que puedes coger, tocar, o con los que (como futuro cliente) puedes interactuar.

Relacionado con las aplicaciones hablamos de aplicaciones nativas cuando han sido creadas para abrirse en un sistema operativo concreto, por ejemplo, los más comunes iOS y Android. ¿Qué es un Sistema Operativo? Es un conjunto de programas, reglas, aplicaciones, etc. Piezas, en definitiva, que componen el sistema En el ejemplo de la panadería, el sistema operativo sería el local, el espacio físico que se ha utilizado para poner la panadería.

Por otro lado, las web apps o apps híbridas son todas aquellas aplicaciones que se pueden abrir en diferentes sistemas operativos debido a que usan en su mayoría frames o estructuras que referencian/embeben páginas webs. Pueden ser accesibles usando los navegadores o pueden tener una parte nativa y otra parte web.

En el ejemplo de la panadería una app nativa sería una tienda totalmente adaptada y customizada en base al local, las limitaciones de obra del local y la comunidad de vecinos donde se instala la tienda, y una app híbrida sería algo más parecido a instalar una franquicia de panaderías con una serie de componentes prefabricados o preestablecidos independientemente del local donde trabajemos.

Seguro que has oído hablar de HTML, CSS y Javascript, ¿verdad? Pues estos conceptos (o sus derivados) son lenguajes de programación utilizados para desarrollar el front-end. Cada uno de ellos tiene una función propia:

• HTML para definir la estructura del sitio. Define el orden de los elementos y también es donde encontraremos todo el contenido estático (más concretamente, los textos y las imágenes). Sería como el mobiliario de la panadería y su distribución.
• CSS para añadir la capa gráfica al sitio web (colores, tamaños y estilos de letra, reglas de visualización específicas). Serigrafía, branding y aspectos más relacionados con el estilo de la panadería.
• Javascript para hacer el sitio dinámico. Puede definir las acciones que se ejecutarán en relación con un evento (clic en un botón, por ejemplo), pero también las interacciones con otras aplicaciones (Google Analytics, entre otras). En nuestra panadería, serían por ejemplo las acciones que ocurren al apretar los botones de la máquina que corta el pan, la acción/interacción de pedir la vez, o encargar un determinado pan sin trazas ni alérgenos.

Y el último punto importante sobre el front-end: ¡el responsive design! Este término describe el comportamiento específico de un elemento en función del tamaño de la pantalla o del dispositivo. El CSS (capa gráfica) evoluciona para tener un sitio legible y fácil de navegar en todos los tamaños de pantalla y ofrecer una experiencia optimizada, especialmente en los móviles. Es decir, que tu producto se adapta y se comporta de forma diferente a nivel visual dependiendo de si el usuario lo está viendo en una app, en una tablet, en un laptop o en una pantalla de ordenador de sobremesa.

Cuando un sitio se diseña principalmente para su uso en móviles, se habla de diseño mobile first (a partir de ahí, los demás formatos de pantalla se adaptan).

La parte del back-end

Aquí no hay interfaz visible. En cambio, nos encontramos con la parte algorítmica y la implementación de las distintas reglas de negocio. Este back-end es también el que permite el acceso a la base de datos.

La centralización de las reglas de negocio en el back-end ofrece la ventaja de tener las mismas reglas, independientemente del canal de visualización (aplicación o sitio web).

En nuestra panadería, el back-end sería el horno que hay en la trastienda donde vamos cocinando y fabricando los diferentes tipos de panes, bollería y demás productos en base a una serie de recetas (reglas de negocio) definidas por las personas que dirigen la tienda. Por ejemplo, en una cadena de panaderías, las recetas vendrían dadas por la dirección de la marca y dejarían un margen de creación a las panaderías locales.

Históricamente, el back-end consistía en un único código centralizado que cualquiera podía modificar (llamado monolito). Desde hace varios años, las mejores prácticas promueven una arquitectura descentralizada y dividida en microservicios. Esto quiere decir que nuestro back-end se compone en varios back-ends, cada uno con su propio alcance, que saben interactuar fácilmente entre sí. ¿Habéis escuchado hablar de migrar los sistemas legacy? Se refiere a esto precisamente, a llevar un sistema obsoleto o monolito a una arquitectura basada en microservicios.

Este cambio en la arquitectura técnica tiene una ventaja organizativa, ya que permite una gestión más granular de la propiedad del código: un equipo puede tener ahora su propio microservicio que solo él puede modificar.

¿Cómo podemos trasladar este ejemplo a nuestra panadería? Imaginemos que toda la creación de los panes se lleva a cabo en un único proceso secuencial en el que una persona va moviendo los ingredientes, la masa, el pan, de una parte del proceso a otra. Una parte del proceso no puede comenzar hasta que no acaba la anterior. Esto sería un monolito. ¿Cómo lo descomponemos en microservicios? Por ejemplo, una persona o equipo encargado de los ingredientes, le decimos el tipo de pan y nos suministra los ingredientes en las cantidades necesarias. Otra persona procesa los ingredientes, les da forma, y prepara los productos para el reposo. Cada una de estas personas o equipos serían microservicios.

Salvo raras excepciones, los lenguajes de programación front-end y back-end son diferentes. La persona con el rol de desarrollador que puede trabajar tanto en el front-end como en el back-end se denomina desarrollador full-stack.

Las API

Las APIs permiten la comunicación entre el front-end y el back-end. También se utilizan para hacer que 2 aplicaciones de back-end se comuniquen entre sí, ya sean 2 microservicios de la misma aplicación, o con servicios externos. Para saber más sobre las API, te recomiendo este vídeo.

API son las siglas de Application Programming Interfaces. Si no sabes bien qué es un API y para qué sirve tampoco te va a solucionar saber qué hay detrás del acrónimo (si no lo digo reviento).

Para facilitar la comunicación entre estos sistemas, las API tienen contratos de interfaz que especifican lo siguiente:

• Los datos de entrada previstos.
• El tratamiento que se realizará.
• Los datos de salida.
• Códigos de retorno y su definición.

¡Vamos con nuestro ejemplo! En nuestra panadería, ¿qué sería un API? Sería la persona que atiende a los clientes en el mostrador, que recibe los pedidos de los clientes y devuelve los productos solicitados.

Los contratos en este ejemplo serían los panfletos, menús o carteles donde los clientes tienen el listado de productos que pueden pedir, con sus ingredientes y precios.

En la comunicación entre microservicios en el back-end podría ser una persona encargada de llevar uno o varios productos a la siguiente fase del proceso de creación de panes y pasteles, y los contratos podrían ser un manual o playbook que defina cómo se realiza la interacción entre la persona/equipo que está mezclando los ingredientes y la persona que lleva la mezcla al equipo de amasado.

Obviamente en una panadería, aunque sea grande y exista un manual, lo más probable es que esos contratos sean acuerdos verbales como por ejemplo: “por favor, la próxima vez no tires el bol de ingredientes como si fuera un balón de rugby, te agradecería que lo dejaras en esta mesa, me des una voz y yo vengo a recogerlo”.

Las interfaces se pueden definir o especificar en una herramienta de documentación como Confluence o en herramientas dedicadas como Swagger.

Las APIs REST estandarizan la forma en que se especifican los contratos de interfaces, especialmente a través de una nomenclatura que facilita la comprensión de la acción del servicio. En nuestra panadería sería esa documentación que recibimos cuando montamos una franquicia de panaderías y la mayoría de interacciones ya están documentadas o protocolizadas.

Los códigos de retorno también están normalizados de la siguiente manera:

• Códigos 200 a 299: Solicitud completada con éxito (pan entregado y pago recibido).
• Códigos 300 a 399: Redirecciones, no necesariamente por un problema (¡necesito saber si este pan lleva nueces! Llama a Juanito).
• Códigos 400 a 499: errores del lado del cliente (navegador). Hay que comprobar si la página existe (404) o si tiene derechos de acceso a la página (401, 403). La puerta de la panadería está atascada y los clientes no pueden pasar; tenemos que comprobar si lo han intentado a una hora donde estábamos abiertos y si existe el cartel de abierto/cerrado visible en la puerta. ¿Quizá también una señal acústica par invidentes?
• Códigos 500 a 599: errores del lado del servidor. Hay que consultar los registros del servidor, o pregúntale a nuestra persona favorita del equipo dev (nos hemos quedado sin pan, sin ingredientes, se ha ido la luz, se ha roto el horno, el cliente habla en alemán y el personal todavía no lo controla, etc.).

Para más información, visita la página de la Wikipedia sobre Códigos de estado HTTP

Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy

Alojamiento e intercambios con los servidores

1. Por último, algunas nociones de infraestructura. ¿Sabes lo que sucede cuando accedes a una página web? Esto es lo que ocurre tras bambalinas cuando escribes, por ejemplo, «https://www.media.thiga.co/tag/opinions», en tu navegador:
   1. El navegador envía una petición para recuperar la página (el código HTML) «estrategia-de-producto» que se encuentra almacenada en el servidor que aloja el entorno media.thiga.co/es y a su vez guardada en una carpeta llamada "tag". Por cierto, así, rápidamente, un servidor es un ordenador encendido en algún lugar, conectado a la red, con toda la info, imágenes, código, etc., y configurado en modo servidor para servir esa información.
   2. El navegador recibe la página «estrategia-de-producto», interpreta código, lo transforma en el contenido y muestra la información.
   3. El navegador ve que en el código HTML hay una referencia a un archivo style.css alojado en el mismo lugar y un archivo script.js. Estos archivos contienen el código CSS y JavaScript respectivamente. A continuación, llama al servidor para descargar estos archivos.
   4. El navegador recoge los archivos y aplica, por un lado el estilo CSS y por otro lado la programación de los eventos/acciones descritas en el código JavaScript recibido.
2. 5. ¡Et Voilá! Ya tenemos la página «estrategia-de-producto» correctamente presentada en nuestro navegador.
3.  

4. Se me complica el asunto. ¿Cómo trasladamos esto a nuestra panadería? Vale, mangas arriba, me voy a poner un poco espiritual, ¡agárrate que vienen curvas!

   Imagina que, como usuario, vas por la calle y buscas una panadería (buscas en google “estrategia de producto”) o bien vas directamente a la panadería porque ya la conoces (tecleas la página «https://www.media.thiga.co/es/tag/estrategia-de-producto» en tu navegador). La panadería realmente no existe para tí, está en tu imaginación, hasta que la ves (te avisé, seguimos).

5. Al acercarte a la puerta de la panadería, girar el pomo y entrar en la panadería esta se va construyendo en tu realidad. Frente a tus ojos, en lo que dura un parpadeo se colocan los muebles, el branding, colores, productos, la máquina de cortar pan, la persona que te atiende detrás del mostrador, etc. Esa construcción instantánea a medida que, como usuario, vas entrando en la panadería sería la página «estrategia-de-producto» cargando su código (HTML, CSS y JavaScript). ¡Uf! ¿Lo he conseguido?

6. «Vaciar la caché» es el acto reflejo, casi instantáneo, que nuestra persona de desarrollo nos dice y hace cuando se le informa de una anomalía. Esta caché es una forma de optimizar las llamadas a la red del navegador. Se trata de un tipo de memoria temporal que usan, entre otros, las páginas webs y apps para guardar en tu entorno local (ordenador, móvil, tablet) ciertos contenidos como imágenes, textos, código, para que la próxima vez que accedas a esa página o app lo puedas hacer más rápido. ¿Por qué más rápido? Porque a nivel proceso de operaciones es más rápido y sencillo acceder a info que está en local que a info que está en la nube.

   Concretamente, cuando se consultó por primera vez la página «https://www.media.thiga.co/es/tag/estrategia-de-producto», se descargaron los archivos CSS y JavaScript de esta página en tu local. El navegador puede almacenar estos archivos en la famosa caché. Si vuelves a visitar la página «estrategia-de-producto» para refrescar algún concepto, el navegador no llamará al servidor para recuperar estos archivos sino que los buscará en tu caché.

   Desgraciadamente, el navegador no sabe si el archivo del servidor ha cambiado o no respecto al archivo que tienes almacenado en tu caché, de ahí la necesidad de borrar o «Vaciar la caché» del navegador para tratar de solucionar la anomalía.

   Venga, panadería. Al visitarla por primera vez se construye ante nuestros ojos en lo que dura un parpadeo y esta composición queda grabada en nuestra memoria. Como es la primera vez que vamos a esta panadería, no sabemos dónde está la cortadora de pan y le preguntamos a la persona que hay detrás del mostrador.

7. Con amabilidad nos indica el lugar y vivimos la crujiente experiencia de un pan recién cortado. La siguiente vez que visitamos la panadería no necesitamos preguntar dónde está la máquina para cortar el pan, pues tenemos almacenada su localización en nuestra memoria reciente (caché). Sin embargo, la persona que regenta la panadería ha cambiado la distribución y colocado la cortadora de pan en otro lugar, lo que nos obliga a volver a preguntar y registrar la nueva ubicación (vaciamos la caché y guardamos los nuevos datos).
   
   En el lado del servidor, tanto el almacenamiento del código y los datos como la gestión del rendimiento se delegan generalmente en los alojamientos en la nube, es decir, en servidores compartidos operados por un proveedor.

8. Los tres principales son Google Cloud Platform (GCP), Microsoft Azure y Amazon Web Services (AWS). El alojamiento en la nube se contrapone al alojamiento On Premise, en el que la gestión de la plataforma y el alojamiento de los datos los gestiona la propia empresa.

Con esta última opción, la empresa tiene más control sobre los datos, pero el coste de mantenimiento no se comparte y, por tanto, es más elevado.

La diferencia entre alojamiento en la nube y alojamiento on premise es la misma que si, en nuestra panadería, alquilamos un trastero a una empresa especializada para dejar ahí productos, maquinaria, documentación, etc., y en el caso de necesitar más o menos espacio de trastero vamos negociando con esa empresa de alquiler (alojamiento en la nube); sin embargo, si guardamos todo eso en nuestra panadería, en un espacio adaptado para guardar estos productos, materiales, etc., consumimos un espacio útil de nuestro local pero no tenemos el coste del alquiler (alojamiento on premise).

Por último, es posible que hayas oído hablar de CI/CD (Continuous Integration/Continuous Delivery). Tras este concepto se encuentra la automatización de tareas que facilitan:

• La integración del código de cada programador en un lugar común (llamado «repositorio»), lo que asegura que no haya regresión (Continuous Integration).
• El despliegue en los diferentes entornos (Continuous Delivery).

Una de las herramientas más conocidas de CI/CD es Jenkins. Estas prácticas ofrecen calidad y rapidez. El CI/CD de nuestra panadería se corresponde con una serie de máquinas que, de manera automática, trasladan la creación de nuevos producto desde los ingredientes hasta el horneado y enfriamiento (CI), y una serie de máquinas que llevan los nuevos productos desde la zona de enfriamiento hasta los correspondientes expositores (CD).

No lo véis, pero estoy sudando, la panadería me está dando guerra. Espero de verdad que este artículo te haya ayudado a comprender estos conceptos básicos tan diferentes y abstractos que manejan habitualmente nuestros equipos de desarrollo. Me apetece una tostada recién cortada, ¿a ti no?

1.  

2. Como en el siguiente paso toca ensuciarse las manos, ¿por qué no hacerlo con la formación para Product Managers de Thiga Academy?