Product Manager

Clase 8 - Software Development

Introducción
La clase de hoy va a estar orientada a nuestras tareas como PMs para con el equipo de
desarrollo. Como idea general, debemos proveer visión sobre el producto, es decir, comunicar
qué vemos en el futuro de ese producto. Luego, existen otras tareas que vamos a llevar a cabo,
pero esa es nuestra razón de ser.

Product Roadmap

¿QUÉ ES?
Según Marty Cagan en su libro “Inspired”, como PMs debemos responder a esta pregunta
fundamental: ¿en qué deberíamos trabajar con nuestro equipo de producto? Con equipo de
producto se refiere al equipo de desarrollo.

Esa pregunta se responde fácilmente con un product roadmap, que consiste en un diagrama de
Gantt en el cual ponemos todos los logros que tendrá el equipo con el tiempo. Es una
herramienta de planificación y visibilidad.

La definición de product roadmap que da el autor del libro es que se trata de “una lista
priorizada de features y proyectos en los que tu equipo estará trabajando. A menudo esos
product roadmaps se analizan por trimestre o anualmente” . Por esto último es que generalmente
se propone un gantt para mostrarlo.

BENEFICIOS DEL PRODUCT ROADMAP

Es como el guión de una película:

● Provee dirección al proyecto: la claridad con la que se exponen los logros en el tiempo
hace que todos los miembros, internos y externos al equipo, tengan visibilidad respecto
a lo que sigue.

● Unen los objetivos del negocio con la estrategia del producto: cada reunión de review
que hacemos con los stakeholders del proyecto demuestra en qué estuvimos trabajando,
por consiguiente, se puede plantear en ese espacio la necesidad de alinear objetivos,
viendo en el roadmap las diferencias entre objetivos.

● Facilitan la colaboración: al tenerlo visual y recurrible cuando necesite el equipo, se

pueden plantear ideas e inmediatamente plasmarlas en él. Si no existiese esta
herramienta, estaría toda esa información sólo en la cabeza del/la PM.

● Ayudan a priorizar: como es la visión futura, la decisión respecto a qué tomar en el sprint
se decanta sólo por lo que diga el roadmap.

● ¡No sólo se trata de features y fechas de entrega! Se ponen los logros, eso significa qué
objetivo de negocio vamos a estar alcanzando. Por ejemplo: “Aumentar un 10% la
cantidad de usuarios con la nueva landing page”.
¿CÓMO ARMAR UN PRODUCT ROADMAP?
En algunos casos, los roadmaps vienen armados desde el management, es decir, los arman los
stakeholders, y nosotros/as nos adaptamos a una visión más táctica del corto plazo. En otros
casos, depende enteramente de nosotros/as.

Abrimos en A y B el armado del roadmap, porque podemos ser PMs que trabajen en una
empresa donde se desarrolle el producto a lanzar directo al mercado, o bien seamos parte de
una agencia que vende el servicio de PM a otra que lo requiere. Entonces, a veces este/a PM
tercerizado/a, además de presentar el roadmap para que todas las partes entiendan los
objetivos en el tiempo, debe dar una visión de costos del proyecto. Esta última tarea
tradicionalmente la cumplen los Project Managers, pero si esta figura no está en mi equipo la
debo cumplir yo.

Tomemos como referencia que B es un PM que trabaja en la empresa que desarrolla su propio
producto. A, en cambio, es un PM tercerizado, y debe demostrar tiempos y costos del proyecto.

Caso real de Banco Supervielle 2020/2021.

Comenzamos con las primeras 3 etapas que son de planificación.

1. Brief.
A. Requerimientos del cliente.
B. Ideas de funcionalidades para personas usuarias.

2. Pantallas y objetivos.
A. Definir lista de pantallas y sus componentes. Evaluar con el cliente.
B. Definir los objetivos de negocio a cumplir
 3. Presupuesto en tiempo y costo.
A. Envía los costos a la persona que nos contrata de la otra empresa.
A y B. En esta instancia, el cálculo es en base a la experiencia de desarrollar
funcionalidades similares. Se introduce en el gantt la conclusión.

El resto de los pasos son para A y B. Son fases de ejecución, porque hasta aquí tuvimos que
lograr que se acepte nuestra propuesta de planificación. Luego de aceptada, en las etapas 4, 5,
y 6, lo diseñamos, desarrollamos, testeamos y publicamos.

4. Pre-producción.
Wireframes.
Diseño de base de datos.
API

5. Producción.
Diseño final (mobile y desktop).
Maquetación.
Backend.
Frontend.

6. Testeo y publicación.
Testeo y publicación: se testea en el servidor donde se desarrolla, generalmente en un
“ambiente” que es un sitio o app de pruebas, llamado “ambiente QA”, o “ambiente de
testing”, o “staging”. Luego publicamos al store de apps, o directamente subimos
actualización de la web.
Organización

EL PROJECT MANAGER
Los conocimientos del idioma de la tecnología, así como tareas específicas de planificación de
desarrollo, son competencias fundamentales que tienen que diferenciar al perfil del Project
Manager.

● Conocimientos del idioma de la tecnología: cuando como Product Managers generamos

nuevas tareas en el backlog, puede que un Project Manager nos acompañe facilitando la
explicación técnica al equipo de desarrollo. Lo traduce en lenguaje técnico, es decir,
genera una descripción de bloques de código a desarrollar, y cómo se deben
estructurar.
● Tareas específicas: con esto anterior se puede estimar la tarea, esto es, decir cuánto
tiempo va a demorar el equipo en desarrollarla.

HISTORIAS DE USUARIO
Las historias de usuario -también llamadas user stories en inglés- definen una funcionalidad: en
una sola frase, debe quedar claro quién (rol) hará una acción (objetivo), para satisfacer una
necesidad (motivación). El título de una historia de usuario debe mapear una funcionalidad de
nuestro producto o software.

Supongamos que vamos a lanzar una funcionalidad de reproducir una canción en Spotify:
 ● Título de la historia: reproducción manual de canción
● Descripción: como oyente premium, quiero apretar el botón play para poder escuchar mi
canción favorita al instante.
En el mejor de los casos, no creamos una historia de usuario para frontend y otra para backend,
sino que el corte de funcionalidad debería ser transversal. En el ejemplo de Spotify, no es que
hago una historia que desarrolle el ícono de play, y en otra la búsqueda del audio de la canción
cuando el botón es apretado, sino que esa historia contiene ambas partes.

Brief
Es el instrumento que define los objetivos comerciales y de comunicación de un desarrollo,
empresa o campaña, sintetizando datos previamente elaborados, estableciendo acciones a
realizar, y definiendo las responsabilidades de los involucrados. Se utiliza en marketing y en
desarrollo de software.
Generalmente, trabajando en proyectos y productos -ya sea en una empresa donde se desarrolle
algo propio, o como agencia tercerizada- vamos a toparnos con briefs, o directamente
tendremos que crearlos.

EJEMPLO REAL - BRIEF

Te paso el brief de lo que nos están pidiendo… estimo que no es complicado.
Necesito armar una landing que esté linkeada desde una web o desde redes sociales donde se
anoten participantes a un concurso.
Datos a completar:
Nombre, apellido, DNI, cómo nos conociste, email, teléfono.
Además, esto contendrá las bases y condiciones del juego y debo tener un backend para poder
bajar la información para recopilarla.
Calculamos que van a entrar entre 500 y 1000 personas.
Esta página estará online sólo un mes, y debería arrancar a principios de marzo.

En el ejemplo anterior, podemos encontrar la información súper resumida de qué, cómo, cuándo
y quiénes deberían llevar adelante ese proyecto. Obviamente, con este documento no alcanza
para ponerse a trabajar, necesitan reunirse las partes para aclarar cada punto.
INTERACCIONES CON EL EQUIPO
Durante el proceso de empezar un nuevo proyecto, en el cual ya hay un equipo asignado,
tenemos que conversar el brief en profundidad con el mismo. Los 3 tips sobre interacciones que
debemos tener en el equipo son:
1. Validar el brief con el equipo de trabajo.
2. Ser flexibles al conversar con el equipo de desarrollo; puede que este equipo sugiera
cambios que impacten sobre el brief, y en tal caso habrá que tomarlos en cuenta, y
desafiarlos con la persona que armó el brief.
3. Dar el máximo nivel de detalle posible: luego del brief, debemos crear las historias de
usuario que profundicen cada punto del brief. Para ello, utilizamos herramientas
colaborativas como JIRA, Mural, Trello, Asana, Excel, YouTrack, etcétera.

Pre-producción, producción y programación

PRE-PRODUCCIÓN
Llamamos pre-producción al proceso previo de programar el código del producto que queremos
lanzar. Antes de comenzar con esa tarea de desarrollo, debemos asegurarnos de aspectos de
diseño de flujos UX, y de arquitectura de software. Es decir, si damos startup a un proyecto, esta
pre-producción se hará continuamente, cada vez que quiera generar una nueva funcionalidad.
Será necesario, antes de trabajar en cada funcionalidad, diseñar los siguientes aspectos:
● Wireframes.
● Arquitectura de APIs.
● Bases de datos.

WIREFRAMES
Los wireframes son representaciones esquemáticas de los elementos que formarán parte de la
interfaz de usuario. Son esquemáticas porque no se trata de los elementos definitivos de la
interfaz, sino que son componentes genéricos, que en el diseño de alta calidad se van a
reemplazar.

En el ejemplo vemos al mismo producto, representado en la primera imagen por un wireframe

(diseño genérico pero que representa la experiencia final), y en la segunda hay un diseño en alta
calidad, tal como queríamos que quede el producto.

Generalmente se acostumbra a alcanzar el wireframe completo de la funcionalidad que

queremos luego desarrollar y luego el proceso se puede abrir en 2 subequipos:
● Diseño se ocupa de la versión visual final, como la imagen de la derecha.
● IT se ocupa de hacer la siguiente etapa de la pre-producción: la arquitectura de APIs.
APIs
Una API - application programming interface, o interfaz de programación de aplicaciones- es un
conjunto de funciones y métodos, que permite conectar dos softwares entre sí, para intercambiar
datos y mensajes, y utilizar funcionalidades ya existentes. Uno de los ejemplos más populares es
utilizar el login de Google para registrarse en un sitio:

Es decir, mi sistema le envía a Google un email y contraseña que escribe en un formulario de

login, y en la API de Google se resuelve si esa combinación es verdaderamente de un usuario de
Google.

Cada API tiene endpoints, que te entregan diferente información. Por ejemplo, la de Google
podría tener estos endpoints:
RegistroUsuario
Nombre
Apellido
Dni
Url donde hizo click
Fecha y hora
ip
loginAdmin
User
pass
traerListaUsuarios
fecha_desde
fecha_hasta

Si mi sistema necesita traer el DNI, le pregunta a Google desde su API, y a su vez consulta al
endpoint RegistroUsuario. Esos endpoints se escriben en formato ruta, del tipo
API/RegistroUsuario.
Lo que debe hacer el equipo antes de encarar el desarrollo del proyecto, es saber a qué APIs va
a tener que conectarse para desarrollar las funcionalidades, y qué APIs debe construir para
nuestro producto. Con estas últimas, entregará la info necesaria para que los flujos se puedan
completar.

ESTRUCTURA DE LA BASE DE DATOS

Una base de datos es una colección de información, almacenada de forma organizada, para ser
encontrada y utilizada fácilmente. Los datos se encuentran organizados y relacionados entre sí,
a fin de ser recolectados, consultados, gestionados y utilizados por sistemas de información.

Ejemplo

Nuestro equipo debe generar un esquema como el de la imagen para saber cómo se van a
relacionar entre sí, y que de esta manera:
● No se duplique información.
● Se cuide la economía del sistema.
● Sean encontrables los datos.
● Sea completa la información para los objetivos del negocio, y para la salud del sistema.
PRODUCCIÓN Y PROGRAMACIÓN
Con las tareas de pre-producción terminadas, estamos listos para diseñar en alta calidad la app
o web y para programarla.

DISEÑO MOBILE FIRST

Para diseñar en alta calidad, recomendamos usar esta técnica. El concepto de diseño mobile
first implica plantear el proceso de diseño, teniendo en cuenta el teléfono en primer lugar. Esta
forma de trabajo nos obliga a pensar en el teléfono como punto de partida, priorizando lo
esencial de un producto, y haciendo foco sólo en lo que tiene sentido para este dispositivo.
Una vez que la aplicación está diseñada, podemos preguntarnos cuál es la mejor forma de llevar
lo hecho para el teléfono a otros dispositivos, extendiendo y escalando el contenido, y
repensando la diagramación.
Todos los dispositivos tienen usos diferentes, hay que tener en cuenta las características
particulares de cada uno de ellos. Resulta más sencillo tener pocos elementos, e ir agregando
más cosas a medida que van creciendo, que empezar por el diseño para pantallas grandes, y
luego ir quitando cosas cuando no entran.

LENGUAJES DE PROGRAMACIÓN
Esta debería ser la última etapa de un proceso en el cual hicimos la tarea previa para que la
funcionalidad la desarrollemos una sola vez. Esto no significa que luego no se pueda mejorar, al
contrario: una mejora también debe pasar por el proceso de pre-producción, aunque será más
rápido que el de una funcionalidad o producto nuevo.

¿QUÉ ES LA PROGRAMACIÓN?
Es el proceso de escribir instrucciones para la computadora, en el formato y sintaxis que el
lenguaje de programación requiere, a fin de que se realice determinada acción. Se trata de
escribir la solución a un problema factible de ser resuelto por una computadora. La
computadora resuelve el problema, no nosotros.

Programar es comunicar, porque al escribir una solución debo tener en cuenta que otra persona
que también programa debe poder interpretarla y modificarla.
FRONT-END Y BACK-END
En el universo de la programación, se suele hacer una diferenciación entre desarrollo front-end y
back-end, según las funciones que cumple:

● Front-end: maquetación, lógica visible de un sitio web. Es lo que puede ver un cliente, y
con lo que interactúa.

● Back-end: desarrollo de APIs del lado de los servidores y bases de datos. Se conecta la
base de datos con la interfaz de la web/app.

Si bien pareciera que al desarrollar sólo el frontend de un sitio el mismo ya está completo, por
ejemplo, no entenderíamos si se terminó pagando un producto, tampoco si se generó una orden
para determinada cosa. Todo eso lo resuelve el backend.

Principales lenguajes de Frontend (lo que sucede en el cliente):

● JavaScript
● HTML y CSS*

Principales lenguajes de Backend (lo que sucede en el servidor):

● Python
● Java,
● Ruby
 ● PHP

*HTML y CSS son lenguajes, pero no de programación. Sirven para dar estructura y estilo al sitio.

FRAMEWORKS

Un framework, o marco de trabajo, es un conjunto de herramientas y clases que nos permiten

solucionar un problema o funcionalidad. Los frameworks están escritos en uno o más lenguajes
de programación. Además, establecen una estructura determinada para el código y todos los
archivos, así como una metodología de armado del proyecto.

DIFERENCIAS ENTRE WEB & APP

Para nuestro producto deberemos elegir si desarrollar una app o un sitio web, y a su vez, dentro
de esas clasificaciones, se puede hacer de diferente manera, lo cual nos llevará más o menos
tiempo, pero tendrá más o menos funcionalidad para determinadas acciones.

1. SITIO WEB RESPONSIVE

● Los lenguajes que utiliza son HTML + JS + CSS.
● Utiliza grillas que se adaptan a cualquier resolución. Quizás puede usar alguna
librería de frontend, como Bootstrap o Tailwind.
● No tiene en cuenta el Sistema Operativo, siempre es la misma web a la que se
accede desde una dirección del navegador.
● Pueden aplicarse mejoras progresivas que el usuario no va a notar, porque no se
las tiene que descargar.
● Requieren una conexión a internet para funcionar.

Ejemplos: landing de producto o servicio, o sitio de currículum propio.

2. APLICACIONES WEB (Web Apps o Progressive Web Apps)
● Seguimos utilizando HTML + JS + CSS quizás con algún framework, pero
agregando todo el backend necesario para que la aplicación resuelva la lógica.
● No tiene en cuenta el Sistema Operativo, siempre es la misma web a la que se
accede desde una dirección del navegador.
● Puede que te ofrezca interactuar con el navegador o sistema operativo, pidiendo,
por ejemplo, acceso a la ubicación, a la cámara, permitiendo generar un acceso
directo al escritorio de tu teléfono, etc.
● No requieren actualizarse, el usuario siempre está viendo lo último.
● Requieren una conexión a internet para funcionar.
● No permiten aprovechar al máximo los componentes de hardware del teléfono.

Ejemplos: online banking de los bancos, accediendo desde el sitio web, plataforma
Coderhouse, pedidosYa.com, mercadolibre.com, etc.

3. APLICACIONES NATIVAS (para teléfonos y tablets)

 ● Se descargan e instalan desde el store. Deben actualizarse.
● Pueden hacer uso de las funcionalidades del sistema operativo.
● Se desarrolla con el Software Development Kit (SDK) de cada sistema operativo.
● Se diseñan y programan para cada plataforma (iOS, Android).
● No siempre requieren internet para funcionar.
● Permiten utilizar el hardware (cámara, GPS, etcétera) de manera fluida y
completa.
● Tienen una interfaz basada en las guías de cada sistema operativo, lo cual
favorece la usabilidad. De todos modos, de ser necesario, se puede modificar.
● Es un desarrollo mucho más caro que el siguiente y los anteriores, porque
requiero saber mínimamente 2 lenguajes (uno para cada sistema operativo), por
lo tanto seguramente serán 2 personas las que lo desarrollen.

Ejemplos: la mayoría de las apps conocidas actuales entran en esta categoría. Es muy
raro que una red social o app conocida no sea nativa. Por ejemplo: Instagram, Tik Tok,
etc.

4. APLICACIONES HÍBRIDAS (para teléfonos y tablets)

● Combinación entre ambas anteriores.
● Una vez desarrollada la web, se compila en una App Nativa.
● Permite tener un mismo código.
● Con librerías es posible acceder a las funciones del teléfono, aunque no tan
eficientemente, y de manera incompleta.
● Frameworks: React, Angular, Ionic, Phonegap, Apache Cordova.

Ejemplos: Netflix, Amazon, Evernote.

CONCLUSIÓN
El desarrollo de aplicaciones híbridas tiene una curva de aprendizaje mucho más suave que el
desarrollo nativo. Para desarrollos nativos, se requiere tener conocimientos en lenguajes de
programación, como son Java / Kotlin / XML, para Android, y Swift / Objective-C para iOS,
además de las herramientas y particularidades específicas de cada plataforma.