# Handbook Minimum.run
Este proyecto nace con el objetivo de compartir y reflejar los procesos que seguimos en minimum.run, desde nuestra visión hasta qué herramientas usamos.
Este documento, nos sirve no solo para organizar y documentar los procesos dentro de la empresa, sino también para contar al mundo cómo nos organizamos y cómo funcionamos.\
\
Con él explicamos de forma transparente cómo puedes usar el **no-code** para crea proyectos, fundar tu propia agencia no-code, o implementar el no-code en tu empresa actual.
Sin embargo, también tenemos una visión de contar y explicar qué es lo que estamos haciendo para conseguir **hacer mejor profesional a aquella persona que lo lea.**
El contenido debe ser lo más práctico y útil posible, explicando las cosas para que una persona cuando llegue, pueda tener una noción básica de todas las fases de cómo funcionamos.
### Estructura del Handbook
Aquí tendremos la **estructura del handbook,** dividido en las distintas páginas y secciones que compondrán el mismo. La idea es que cada una de las personas del equipo que tiene más conocimiento vaya escribiendo cada una de las partes.
Después, nos encargaremos de darle una reforma a la escritura para que tenga una voz y tono común.
1. [**Introducción: ¿Qué es el No Code?**](/introduccion/introduccion-que-es-el-no-code)
2. [**Cómo nos organizamos**](/organizacion-del-equipo/como-nos-organizamos)
3. [**El proceso de Minimum**](/el-proceso-de-minimum/minimum-shape-up)
4. [**Herramientas**](/herramientas/stack-de-herramientas-minimum)
5. [**La empresa**](/la-empresa/valores)
# Introducción: ¿Qué es el No Code?
En este primer módulo de introducción, hablaremos sobre el objetivo de este Handbook, sobre Minimum.run y sobre el nuevo paradigma del No Code.
## El Handbook
Este documento es una guía práctica que irá actualizándose a medida que mejoremos nuestros procesos y nuevos aprendizajes que vayamos obteniendo en el universo no-code y su utilización, para que pueda tomarse de referencia y ayuda a todos aquellos que quieran trabajar en este ecosistema.
## Minimum.run
Antes de nada, si no conoces [minimum.run](http://minimum.run), somos una **agencia de no-code y compañía hermana de mendesaltaren** (boutique líder de diseño en producto digital que ha trabajado con las principales empresas de España), con el objetivo de ayudar a otras empresas a **resolver problemas de negocio validando hipótesis sin código**.
Para ello nos centramos en aportar valor y reducir riesgo lanzando e implementando rápidamente con la ayuda del no-code que iteramos basándonos en datos.
Dicho de otra forma, conseguimos reducir a semanas procesos que pueden tardar meses para validar ideas, problemas o hipótesis de negocio.
Las principales líneas de trabajo son el **Product Marketing y la validación a través de MVP,** aunque también hemos desarrollado productos propios que nos ayudan a ser más eficientes.
Nuestro equipo se compone de diferentes perfiles especializados en diseño de producto, data, nuevas tecnologías y negocio, creemos que esta alineación ayuda a potenciar el uso de las herramientas no-code y optimizar el proceso para cumplir nuestra misión.
## ¿Qué es el No Code o herramientas sin código?
Los principios del movimiento no-code, en el que se utilizan herramientas sin código, se basan en empoderar a todas las personas para puedan ser capaces de crear y utilizar los beneficios de la programación sin necesidad de aprender a escribir código. De esta manera, facilitamos la creación webs o apps y su mantenimiento en el tiempo por personas con perfiles ajenos a la programación. Es **poder crear cualquier cosa en internet.**
Lo que antes requería de un equipo de programadores que supiesen lenguajes de programación y varios meses de desarrollo, ahora puede ejecutarse mediante las plataformas de desarrollo no-code por aquellos que no tengan este background técnico.
En la actualidad utilizamos principalmente herramientas no-code como Zapier o Integromat para automatizar tareas y conectar productos, Airtable para crear bases de datos o Webflow para crear webs y productos increíbles sin código, pero cada día surgen nuevas herramientas que facilitan y agilizan crear soluciones digitales.
Si quieres aprender más sobre este nuevo paradgima, te dejamos un [curso gratuíto de Introducción al No Code](https://www.nocodehackers.es/cursos/construye-tus-ideas-con-no-code), por parte de [Nocodehackers](https://www.nocodehackers.es/).
### ¿Por qué el No Code está cambiando el mundo?
La evolución de las herramientas hacia un modelo "**API First",** en el que prima el ofrecer el servicio o funcionalidad de forma que pueda ser consumida por otras aplicaciones ha propiciado que sea más viable que nunca poder crear productos digitales a base de **combinar servicios mediante su API.**
Además, la aparición de herramientas que añaden una capa de abstracción visual a este proceso como **Integromat, Zapier o IFTTT** han hecho que esta conexión esté al alcance de un mayor número de personas que no tengan esos conocimientos técnicos.
A esto se le suma la **madurez de herramientas como Shopify, Webflow o Bubble,** que ofrecen una solución suficientemente versátil y robusta como para cumplir las necesidades de muchos tipos de negocios, a una velocidad mucho mayor que tradicionalmente.
El No-code no trata simplemente del **qué se puede hacer,** si no que hay un gran apartado de **quién puede hacerlo. Poder empoderar a perfiles no técnicos a crear,** permite liberar al equipo técnico y desarrollar soluciones a problemas de negocio en mucho menos tiempo.
Todos estos aprendizajes, los estamos contando a través de **Nocodehackers,** nuestro proyecto formativo.
Hemos condensado en un **curso introductorio de menos de una hora,** que permite tener una visión amplia y general del ecosistema.
Puedes [**acceder desde aquí.**](https://www.nocodehackers.es/cursos/construye-tus-ideas-con-no-code)
# ¿Cómo nos organizamos?
En este módulo veremos la organización interna a nivel de Equipo, Proyecto y Documentación y archivos.
No es solo el uso de herramientas no-code lo que nos permiten agilizar y lanzar proyectos, la organización de la empresa es un punto clave para potenciar los procesos que aplicamos en nuestro día a día.
Creamos procesos adaptados a estas herramientas, conociendo sus limitaciones y ventajas.
En este sentido, destacamos 3 elementos organizativos:
1. [**Organización de Equipo**](/organizacion-del-equipo/como-nos-organizamos/organizacion-de-equipo)
2. [**Organización de Proyecto**](/organizacion-del-equipo/como-nos-organizamos/organizacion-de-proyecto)
3. [**Organización de Archivos**](/organizacion-del-equipo/como-nos-organizamos/organizacion-de-archivos)
# Organización de Equipo
## Estructura
### Management Team
Es el equipo directivo, quien tiene la visión y se encarga de liderar los procesos, la gestión y la operativa dentro de la empresa.
En Minimum tenemos 2 figuras que cubren la parte de Management:
* CEO - Jorge Lana
* CPO - Danny Saltaren
### Head Team
En este término se conforman las personas líderes de cada segmento de nuestra estructura a la hora de trabajar con empresas, siendo estos:
* Project Manager
* Head of Build
* Head of Design
* Head of Data
### Squads
Antes de tener la primera llamada de kick-off con un cliente, nuestra Project Manager configura los integrantes del Squad, los squads son equipos de trabajo que participan activamente en diferentes fases del proceso pero con delimitaciones en áreas de liderazgo.
En cada uno de estos Squads de trabajo, existirá una figura lider de Diseño, Data y Build para acometer el proyecto, además de compañeros expertos en cada una de estas áreas.
**Ejemplo de Squad:**
**Proyecto Web de Minimum**
* **Definición y arquitectura web:** Jesús y Alba (Líder de Build)
* **Wireframes y Diseño:** Jorge y Sandra (Líder de Diseño)
* **Maquetación y Buid:** David y Alba
* **Data:** Jesús y Fani (Líder de Data)
Como puedes observar, en los equipos algunos integrantes participan en 2 o más fases del proyecto, esto nos da una visión holística y nos permite crear sinergias dentro del equipo de trabajo o squad.
#### **¿Cómo se asignan los squads?**
Dependiendo del tipo de proyecto podemos encontrarnos diversas configuraciones e inclusiones del equipo por las fases del proyecto que nos encontremos, aún así, intentamos seguir un proceso definido que desglosaremos en su sección dedicada.
Para ser fieles a los ritmos de trabajo y visión de minimum.run, intentamos que el equipo de data esté presente siempre que pueda para ir planificando la iteración actual y mejorar las futuras, permitiendo avanzar con fundamentos claros que facilitan la toma de decisiones.
El objetivo de estas squads es obtener la máxima agilidad para llegar a lo más lejos posible dentro de cada ciclo de iteración. Así pues, vemos formados distintos equipos que se apoyan entre sí durante las diferentes fases del proceso, desde operaciones al lanzamiento y mantenimiento del proyecto.
#### **¿Cómo se organizan los squads?**
Las herramienta principales que utilizamos a la hora de organizarnos, de las cuáles hablaremos en profundidad más adelante en el handbook, son las siguientes:
* **Holded:** Nos permite tener centralizadas todas las tareas de los proyectos que tenemos en activo, así como tener una visión general del roadmap de proyectos.
* **Slack:** Nuestra herramienta de comunicación con el equipo y con clientes.
* **Notion:** Nos proporciona más información sobre el proyecto y generar la documentación asociada, así como generar un espacio colaborativo con el cliente.
* **Google Meets:** Nuestra herramienta para las comunicaciones síncronas, apoyada con **Google Calendar** para gestionar tanto los encuentros internos como externos.
**Podrás encontrar más información sobre cómo usamos nuestras herramientas en el apartado** [**Herramientas**](/herramientas/stack-de-herramientas-minimum)
## Gestión de equipo
### Organización de la semana
Creemos en la autonomía de los equipos y su capacidad de gestión, pero dado a que tenemos varios proyectos activos a la vez es necesario una organización que permita tanto alinear a los propios integrantes de la squad como ayudar a conocer el estado de los proyectos al resto de los equipos y así gestionar la carga de trabajo y ejecución correcta del proceso.
Nuestra semana se compone de **tres dinámicas principales** para coordinar el trabajo:
### Planning General
{% hint style="success" %}
**Planning**: una reunión de 30 minutos todos los lunes para organizar el trabajo de la semana de toda la empresa.
{% endhint %}
Estas plannings son lideradas por la/el Project Manager y nos sirven para planificar la semana, conocer el estado general de los proyectos y las tareas debemos abordar, además de prever posibles bloqueos o participación de algún miembro de otro equipo si fuese necesario.
Aparte de una **planning general** en la que se reúne todo el equipo existen otras reuniones específicas por cada área que se realizan antes de participar en la principal. Estas se gestionan entre los integrantes de los diferentes departamentos con el objetivo de alinear y simplificar las tareas que se van a ejecutar. Tienen un objetivo mucho más de gestión que informativo.
### Daily
{% hint style="success" %}
**Dailys:** reuniones diarias de Martes a Jueves para compartir la organización del día.
{% endhint %}
A lo largo de la semana, realizamos una breve **daily** en la que compartir con el resto del equipo en lo que estamos trabajando y posibles bloqueos, para tener visibilidad del trabajo de todo el equipo y poder tomar decisiones informadas. Tienen dos características principales:
* **Escritas**. Nos permite reflexionar de manera individual y organizar las tareas y objetivos del día, además de prever posibles bloqueos que surjan que necesiten la ayuda de otro miembro del equipo. La realizan todos los miembros del equipo y la reflejamos en **en un hilo común de mensajes en Slack.** Es una manera de que todos podamos estar al tanto de que están haciendo los demás y su disponibilidad, lo cual es muy útil a la hora de pedir información o ayuda a tu compañero.
* **Síncronas.** Cada día compartimos con todos los miembros del estudio un resumen de nuestra daily escrita en una video llamada de 30 minutos, para poder visibilizar en qué estamos trabajando y poder planificar de una manera más ágil. También nos sirve de punto de contacto entre todos los miembros del equipo cada día.
### Detros
{% hint style="success" %}
**Detros:** una sesión compuesta por Demos y Retros en la que compartir con el equipo, generalmente los viernes.
{% endhint %}
Según avanza la semana llegamos al viernes, otro día clave que se centra en valorar cómo se ha ejecutado la semana, ver cómo se pueden desbloquear aquellas tareas que pudiesen tener una complejidad no esperada, pedir feedback o realizar un brainstorming improvisado para encontrar soluciones o mejorar procesos si fuese necesario. Estas son las llamadas **Retros**.
Para visualizar el trabajo de los distintos equipos, todos los viernes del mes menos el último se **realiza una demo** permitiendo compartir conocimientos, experiencias y el trabajo que se haya realizado, llamándose así **Detro (Demo + Retro).**
Después de realizar la Detro, instauramos un bloque de tiempo de 2 horas llamado **Día Minimum**, en las que no trabajamos en proyectos para terceros, si no que este espacio consiste en tratar diversos temas en los que se intenta **trabajar sobre proyectos interno**s, procesos o metodologías, entre otros. También puede usarse para trabajar con personas de otro equipo.
El objetivo es evitar que se deje de lado aspectos que puedan llegar a ser críticos si no se les presta la atención adecuada debido al trabajo del día a día.
# Organización de Proyecto
En Minimum, siempre buscamos tener un proceso que nos sirva para adaptarnos a los distintos tipos de proyectos según su tipología y que nos permita ser eficientes a la hora de trabajar y gestionarnos internamente.
Para ello, contamos con la figura de una **Project Manager dentro del equipo.**
## El proceso de un proyecto en minimum.run
Principalmente dentro de la propuesta que se ha enviado al cliente, estimamos el tiempo en el que se va a realizar el proyecto. Normalmente la duración suele rondar varias semanas dependiendo del nivel de complejidad del mismo.
{% hint style="info" %}
Un proyecto de media tiene una duración de **4 a 8 semanas**, gracias a las herramientas no-code.
{% endhint %}
Todo esto se refleja dentro del roadmap que se define en la propuesta que enviamos al cliente, este se encuentra en Notion y desglosa las tareas clave que se van a realizar basándose en nuestro proceso.
### Gestión del Proyecto
A todo nuevo proyecto que entra, se le asigna un número correlativo, que nos permite tenerlo identificado de manera única entre las diferentes herramientas que utilizamos (Google Drive, Asana, Figma, Notion, etc).
Cuando un proyecto entra en el estudio, atraviesa diferentes fases, dependiendo de su tipología, pudiendo realizar el proceso completo o sólo una parte del mismo. Las partes principales son:
* **Pre-kick off**
Realizado por el Project Manager, tiene una serie de tareas que se centran en **tener preparado todos los espacios necesarios donde va a vivir el proyecto.**
Entre estas encontramos el documento de **Figma** si fuese necesario, recabar y centralizar la información del cliente en un brief, crear ficha específica en **Notion**, complementar los datos del cliente, convocar la reunión de kick off y crear una carpeta específica con el número y nombre del proyecto en **Google Drive**.
* **Kick Off**
Es el momento en el que realmente empieza el proyecto. Consiste en **agendar, alinear y generar la documentación del proyecto** que está basada en la reunión que se realiza al principio.
Convocamos una reunión de **1 hora con el cliente,** en la que se presentan a los principales interlocutores del Squad que van a trabajar en el proyecto y se hace un repaso del **alcance del proyecto y roadmap.**
* **Shape**
Dentro de shape existen varios procesos que permiten bajar a tierra las necesidades del proyecto y **crear los cimientos sobre los que se construirá y lanzará el producto.**
1. Pasamos primero por la **definición del producto**. En esta fase inicial del proyecto, un miembro del equipo se encarga de extraer la estructura actual del sitio web o producto de la empresa (en caso de que tengan) y plasmarlo en Figma en un formato visual que nos permita plantear mejoras a nivel de usabilidad y accesibilidad en la página.
2\. Posteriormente, se plantea una estructura alternativa con mejoras y se crea un **concepto visual**, que ayude a comunicar efectivamente y mostrar al cliente cómo se vería su web o producto.
3\. A continuación, el equipo de diseño plantea **Wireframes** que serán presentados al cliente junto con la nueva estructura de páginas. Después de la confirmación del cliente, se procede a replantear esos Wireframes de forma más detallada e incluyendo el feedback del cliente.
4\. Paralelamente se realizan las tareas de SEO, Etiquetado en Google Analytics y Tag Manager y diseño UI, que se implementarán en la siguiente fase.
* **Build**
Completada la anterior fase, hacemos tangible el proyecto. Para ello, varios miembros del equipo trabajan paralelamente con precisión y de forma ágil para ajustarnos al roadmap establecido.
Por un lado **maquetamos el diseño UI e implementamos la arquitectura** que hemos trabajado, por otro, **trabajamos más en profundidad la parte de Data** y se configuran las integraciones necesarias.
Una vez que se combina todo este esfuerzo, llega la parte de **QA**, por un lado nosotros revisamos el proyecto al completo y ajustamos aquello que haya podido desviarse, y por otro, el cliente nos comparte sus impresiones y ajustes que cree necesarios para que podamos realizarlos.
* **Lanzamiento**
Y la última parte, el lanzamiento, tareas que se centran en enviar la documentación al cliente, darle los accesos necesarios, transferir y configurar el proyecto en el espacio del cliente y otros detalles técnicos para empezar a validar el proyecto.
#### Project Manager
Es una figura clave en nuestra organización, se encargan principalmente de gestionar los recursos y equipos asegurándose de ejecutar el proceso para llevar a buen puerto el proyecto. Entre sus tareas, es común la creación del espacio en **Asana y Slack** y su **calendarización en Notion.**
Su participación en el proyecto va desde la pre-venta hasta el lanzamiento del mismo, asegurándose que los recursos han sido asignados correctamente y preveer si pueden surgir dificultades que ralenticen el roadmap.
{% hint style="info" %}
El trabajo del **Project Manager** se centra en cuidar, comunicar, tener clara la visión del proyecto y gestionar las expectativas del mismo.
{% endhint %}
El objetivo principal de esta figura dentro de la empresa es poder centralizar las comunicaciones con el cliente en un único lugar para que el equipo se pueda centrar en sus tareas.
Este perfil debe tener una visión holística del estado del proyecto y recibir feedback del estado del mismo gracias a las **planning y dailies semanales.**
Trabaja mano a mano con los **líderes de las diferentes squads,** para la organización y planificación de todos los proyectos, aportando soporte y comunicando sus necesidades para poder ejecutar correctamente el proceso.
## Cómo gestionamos los proyectos
En minimum.run, buscamos crear espacios que nos faciliten el trabajar en los proyectos de manera asíncrona. Es por eso que después de probar varias herramientas a la hora de gestionar estos proyectos, nos hemos decantado por una serie de **herramientas que nos ayudan a trabajar de forma ágil:**
* **Holded (Gestión de proyectos)**
* **Slack (Comunicación)**
* **Notion (Documentación y Gestión)**
* **Figma (Prototipado y diseño)**
* **Google Suite (Documentación)**
Cada proyecto cuenta con su propia carpeta en **Google Drive** y proyecto de **Asana**, así como un canal de **Slack** compartido con los clientes y otro de gestión interna que utilizamos como centro de control del proyecto junto con su ficha en **Notion,** para poder planificar el trabajo y compartir o generar documentación.
### Canal de Slack
La comunicación más síncrona es una de las partes importantes de la gestión diaria y para ello usamos la aplicación de mensajería Slack.
{% hint style="success" %}
Puedes leer más acerca de cómo usamos Slack **aquí**
{% endhint %}
Cada proyecto dispone de un **canal de comunicación con el cliente,** en el que invitamos a que entre para poder comunicarnos de manera directa, así como un **canal de comunicación interno,** que nos sirve para gestionar internamente el proyecto.
La nomenclatura que usamos es:
* Proj-\[nombre del proyecto] para comunicación interna del equipo sobre el proyecto en cuestión
* Proj-\[nombre del proyecto]-shared para tener una comunicación fluída y directa con el cliente.
{% hint style="info" %}
Las conversaciones sobre cada proyecto, deben ocurrir dentro del canal correspondiente, para poder dar visibilidad a todos los miembros y no generar ruido.
{% endhint %}
### Espacio de Notion
Notion es una herramienta con un gran potencial que usamos para variedad de casos de uso, como por ejemplo para organizar toda la información referente a un proyecto.
{% hint style="success" %}
Puedes leer más acerca de cómo usamos Notion **aquí**
{% endhint %}
Tenemos un lugar llamado **Ficha de proyectos** que es donde recogemos y centralizamos en una tabla los diferentes trabajos que hemos realizado y entran.
Principalmente en su fase inicial, reúne dónde se puede acceder al resto de espacios que conforman el proyecto y presenta de forma clara información clave de este. Así pues se compone de estas propiedades:
**Accesos:**
* **Webflow:** Enlace al proyecto de Webflow.
* **Drive:** Enlace a su espacio en Drive.
* **Figma:** Enlace a su proyecto en Figma.
**Cliente:**
* **Nombre del cliente:** Generalmente será el nombre del cliente como marca.
* **Requisitos:** Enlace a requisitos.
* **Contacto:** Qué persona es la adecuada para hablar sobre el proyecto por parte del cliente.
* **Duración en semanas**. Se muestra el tiempo que tendrá el proyecto y se ve plasmado en la propuesta.
* **Propuesta**. Enlace a la propuesta colgada en Drive.
* **Status.** Si está activo, on hold o terminado.
* **Tipo.** Si es ongoing o one shot
Según avanza el proceso, esta ficha se irá complementando con información extra, entre ellas los miembros del equipo asignados, objetivos del proyecto, fases y tiempo, Roadmap y sobretodo, sub-páginas que contendrán desde el Kick off a documentación que se irá generando.
### Documentación en Google Drive
En Google Drive centralizamos la información correspondiente a la documentación del cliente. Cada cliente tiene un número de proyecto que se organiza dentro de una carpeta compartida en Google Drive.
Además de documentación relativa a la realización del proyecto, en esta carpeta se puede encontrar la propuesta realizada por Minimum.
### Proyecto de Figma
Para aquellos que no conozcan Figma, es una herramienta de diseño vectorial que permite prototipar y compartir los diseños de forma sencilla.
Al inicio del proyecto, tenemos una plantilla que nos ayuda a estructurar el trabajo que se va a realizar en esta herramienta siguiendo el proceso que realizamos en la fase de Shape en diseño.
Se compone principalmente de varias páginas en las que se tratan las tareas que realizamos normalmente.
# Organización de Archivos
A continuación explicamos cómo organizamos documentación y archivos en Minimum.
Como hemos visto anteriormente, además de las herramientas que usamos en el día a día, también gestionamos de forma más eficiente nuestro tiempo usando plantillas, éstas nos ayudan a acelerar el incio del proyecto y agilizar la centralización de los archivos necesarios para su correcta ejecución.
### Accesos a herramientas
Normalmente hay que dar acceso a estas herramientas a los diversos miembros del equipo además de permisos para acceder tanto a secciones de Notion, proyectos de Asana o carpetas de Google drive. Esto está estructurado de tal forma que **podamos dar permisos a zonas específicas a clientes si fuese necesario**, además de su presencia en los módulos de basecamp, donde se encuentra su proyecto.
También utilizamos un gestor de contraseñas, **1password**, que nos ayuda a **centralizar algunos servicios o herramientas no-code**. Esto nos permite tener autonomía a la hora de ingresar puntualmente a proyectos por parte de otros miembros del equipo que no tienen una cuenta específica. De esta forma, también aumentamos la seguridad y actualización de los accesos de forma recurrente.
### Nomenclatura de los archivos
Dependiendo de la herramienta organizamos la presencia de estos de forma distinta. Algunas de estas no permiten agrupar por proyectos por lo que intentamos estandarizar y jugar con las posibilidades que nos ofrecen.
En aquellas que se pueden englobar bajo un directorio específico, marcamos el proyecto con el número que le corresponde, esta sería la carpeta contenedora del resto de archivos.
`[id]_[Nombre del proyecto]`
`[00]_[Minimum.run]`
* **ID** Hace referencia al número del proyecto, partimos desde 00. Se establecen en base al orden en el que se iniciaron los proyectos y son consecutivos. \[00 01 02 03 04 05 06 07 08 09 10 11 ...]
* **Nombre del proyecto** Suele corresponder al nombre de la empresa, pero en casos excepcionales, puede que sea un proyecto que no tenga, con lo que usamos uno temporal para referencia interna.
En ocasiones existen proyectos que forman parte de otros, pero al tener un alcance propio se sigue la siguiente fórmula:
`[id]_[Nombre del proyecto padre] - [Nombre del proyecto hijo]`
Luego, los archivos siguen el patrón de la carpeta madre, es decir, incluimos a quién pertenece precediendo su funcionalidad
`[id]_[Nombre del proyecto] / [Nombre del archivo]`
{% hint style="info" %}
Buscamos que los nombres del archivo sigan tres normas básicas; **Concisos, Concretos y Autoexplicativos.**
{% endhint %}
Con el objetivo de que no sea necesario entrar en estos para buscar en su contenido y permitan ser fácilmente indexables por el buscador de la herramienta.
En el caso de realizar una copia de alguno de los archivos, se incluye al final del nombre entre parentesis.
`[id]_[Nombre del proyecto] / [Nombre del archivo] (COPIA)`
### Notion
**1. Espacio minimum.run**
Nuestra página principal, nos permite tener categorizadas varias páginas clave que posteriormente ramifican en los distintos espacios que ayudan a documentar y gestionar minimum.run.
Aquí podremos acceder tanto a la sección de Equipo como a las páginas públicas que compartimos.
Algunas de las secciones que utilizamos son:
* **Equipo** Todo lo relacionado con las personas que formamos parte de [minimum.run](http://minimum.run), nuestras fortalezas individuales, roles que existen y organigrama.
* **Producto** Aquí encontramos toda la información relativa a Miniumum como proyecto. Principalmente documentación interna tanto como glosario de términos como aspectos más específicos como postventa.
* **Management** Aquí encontramos gran parte de la operativa de Minimum, que nos aportan diferentes vistas para tomar mejores decisiones dentro del estudio, además de la gestión de proyectos.
* **Design** Espacio dedicado para el equipo de diseño, donde dividen cada proyecto en sus tareas específicas y su fecha de entrega.
* **Estrategia** Todo lo relacionado con visión a medio/largo de la compañía. Anual/trimestral, acuerdos y movimientos estratégicos, colaboradores o propuestas internas.
* **Marketing y comunicación** Repositorio en el que encontramos artículos propios y acciones que hemos realizado, además de recaps de las reuniones semanales.
**2. Roadmap**
Espacio que permite **visualizar todas las fases de los proyectos que están en marcha** durante un periodo de tiempo, normalmente la visualización está definida mensualmente.
Dentro de cada fase que aparece en el roadmap se ve qué líderes están asignados a este periodo.
Por otro lado, sustituimos temporalmente de la nomenclatura que mencionabamos anteriormente para usar un emoji que esté relacionado con la temática del proyecto, permitiéndonos detectar rápidamente en la línea de tiempo su posición.
`[Emoji temático]_[Nombre del proyecto] → 🚗_Coches`
Los proyectos que aparecen en este roadmap son elementos creados aparte de la ficha de cliente, por lo que no están relacionados por ninguna tabla.
Marcamos con una tag de status cada proyecto que aparece en el roadmap, estas están generadas en base a las diferentes fases de nuestro proceso.
**3. Ficha de cliente**
Se introdujo brevemente cómo se gestiona el proyecto dentro de Notion, pero no entramos en detalle del contenido que aparece dentro de la ficha de cliente.
Por un lado tenemos el aspecto formal que nos permite tener localizada la información clave del proyecto, esta se compone normalmente de:
Cliente, Contacto, Lead, Canal de comunicación preferido, Tipo de proyecto, Fecha de inicio y cierre, Número de semanas, Semana en la que se encuentra el proyecto, URL que enlacen con las herramientas que se utilicen, Prioridad, Fase en la que se encuentra, Case Study, Business Model, Propuesta enviada, Requisitos, URL de la carpeta de drive, URL del espacio de Basecamp y URL del proyecto de Figma.
En ocasiones el proyecto puede ser hijo de otro, por lo que se crea una relación a ese proyecto madre.
Por otro lado, contiene dos categorías principales, la de documentación y la de integraciones y sus pagos.
Dentro de documentación vemos principalmente tres páginas que son recurrentes, estas son Documentos y Shape. Pueden existir otras que complementen o que tengan una importancia similar a estas evitando que sean una sub-página, como puede ser Integraciones / Funcionalidades, Entrevistas o Case Study.
La otra categoría de integraciones y sus pagos, es más sencilla. Una tabla ayuda a visualizar las herramientas necesarias para llevar a cabo el proyecto y su coste. Esto nos ayuda especialmente a mapear qué se ha contratado y tener presente su transferencia al cliente una vez que se lance el proyecto.
# Minimum Shape Up
## Introducción
En [minimum.run](http://minimum.run) buscamos desarrollar un proceso adaptado a nuestras necesidades y la de los clientes, aprovechando las ventajas que nos ofrece el No-code y circunvalando las limitaciones de estas herramientas.
La tipología de proyectos a los que nos enfrentamos, principalmente se puede dividir en:
* **Product Marketing Sites**
* **MVP**
El proceso que hemos desarrollado - que llamamos minimum Shape Up - recoge principios del proceso de **Shape UP, metodología desarrollada por el equipo de Basecamp,** y tiene por principal objetivo tratar de reducir la **incertidumbre** intrínseca a utilizar herramientas no-code, ya sea por las dudas que puedan surgir en el cliente o sobre la factibilidad del proyecto.
Dependiendo del proyecto, atravesará una o más partes del proyecto, y en esta sección describiremos cada una de ellas en detalle.
### Fases de Minimum Shape Up
Las diferentes fases del proyecto están pensadas para establecer un flujo de trabajo continuo en el equipo y poder distribuir la carga de trabajo en el tiempo. Por lo general, se compone de 4 fases:
* [**Pre-venta**](/el-proceso-de-minimum/minimum-shape-up/pre-venta)
* [**Shape**](/el-proceso-de-minimum/minimum-shape-up/shape)
* [**Build**](/el-proceso-de-minimum/minimum-shape-up/build)
* [**Data**](/el-proceso-de-minimum/minimum-shape-up/data-and-growth)
Es importante entender el proceso desde el primer contacto con el cliente, ya que una parte primordial del éxito de un proyecto reside en acometer retos que técnicamente sean solucionables de manera eficiente con herramientas **#nocode**.
Por último, antes de lanzar un proyecto pasamos por 2 fases:
* [**QA**](/el-proceso-de-minimum/qa)
* [**Lanzamiento**](/el-proceso-de-minimum/lanzamiento)
# Pre Venta
A continuación detallamos nuestro proceso de pre venta, el paso previo antes de tener una llamada con el equipo de Minimum.
## Proceso de Preventa
### Contacto
La primera toma de contacto de un cliente se hace a través de nuestra web [Minimum.run](https://minimum.run)
Mediante un proceso automatizado en **Integromat** y que unen a **Arengu y Pipedrive,** podemos tener una mejor visión de las necesidades de nuestro cliente y entender qué buscan con su proyecto.
Les pedimos que rellenen un breve formulario, y al completarlo recibirán un email en el que pueden reservar una llamada con nuestro equipo.
### Brief de Pre-venta
Una vez rellenado el fomulario en la web, el cliente recibe un email donde puede **reservar una llamada** con el equipo y rellenar nuestro **Brief de Pre-venta,** este formulario nos permite entender el alcance del proyecto y llegar a una primera reunión con el cliente con mucha más información sobre su producto, su marca y el mercado al que se quiere dirigir.
El Brief de preventa está compuesto por las siguientes secciones:
1. **Producto**. Recogemos información sobre el producto, modelo de negocio, propuesta de valor y target.
2. **Proyecto**. Recopilamos datos sobre funcionalidades necesarias, hipótesis a validar (en caso de que sea un MVP), referencias e inspiración, etc...
3. **Integraciones**. En caso de que sean necesarias, se pueden seleccionar las herramientas a integrar en el proyecto
4. **Expectativas**. En este último campo recogemos las expectativas del cliente con respecto a nuestra colaboración.
### Meeting
En esta primera reunión tiene por objetivo tratar de cualificar el Lead en alguna de las tres áreas de nuestro proceso y validar que encaja con nuestro expertise.
Si el Lead es cualificado, se **presenta al equipo para que se realice una estimación.**
### Estimaciones
Es un documento que representa de forma estimada y basándonos en la complejidad del proyecto, el número de horas, recursos y dedicación que nos serán necesarias para cumplir con los plazos que necesita nuestro cliente.
Es muy probable que en esta fase del proyecto se **realicen reuniones con el cliente y parte del equipo de Build,** para poder resolver dudas o identificar posibles problemas que podamos encontrarnos a nivel técnico.
{% hint style="info" %}
Es importante recordar que somos una agencia que trabaja con tecnología No Code, con lo cual en algunas ocaciones se hace complejo llegar al nivel de profundidad que tendría un producto hecho por un equipo de desarrollo con código desde cero.
{% endhint %}
Poder contar con el expertise del equipo que va a ejecutar el proyecto desde el primer minuto nos sirve para reducir riesgo y aportar soluciones sobre las que nos sentimos cómodos aceptando el riesgo del cliente.
Es posible en esta fase que realicemos **Pruebas de concepto**, en las que busquemos demostrar la viabilidad de la solución propuesta, que muchas veces son compartidas con los clientes.
Una vez que entendemos el proyecto, pasamos una propuesta, que si es aceptada, pasará a activarse como proyecto y a la fase de Shape.
# Shape
Shape es la primera fase de nuestro proceso, a continuación te contamos en qué consiste.
## Shape: Definiendo el proyecto
Una vez se da comienzo al proyecto con el **Kick Off, entra en la fase de Shape,** el lugar en el que tratamos de reducir al mínimo la incertidumbre del proyecto.
Cuenta con tres fases:
* **Definición**
* **Concepto visual**
* **Diseño**
En cada una de ellas, avanzamos de la mano del cliente, validando que nuestras propuestas encajan con el objetivo del cliente y que continuamos alineados. Intentamos tener una comunicación lo más constante posible para que vean avances continuamente sobre su proyecto.
### **Definición:**
En esta fase, buscamos organizar y tratar de bajar a tierra la propuesta del cliente. En esta reunión participan habitualmente los representantes de cada una de las áreas que participa en el proyecto (Shape, Build y Data).
{% embed url="" %}
En esta parte del proceso, planteamos la arquitectura del proyecto y la solución técnica por la que optamos, así como entender cuáles son las necesidades del cliente y cómo podemos afrontarlas.
Esta sesión de trabajo requiere tener un conocimiento amplio de la **información de los Brief** proporcionados por el cliente en la pre-venta y el Kick Off, así como de hacer un breve **research** acerca del cliente y su ecosistema.
El objetivo es tener un **Wireframe** de cómo se va a estructurar la web, o en caso de un **MVP un flujo de cómo se va a utilizar.**
Una vez que el proyecto está definido, se valida con cliente y pasamos al Concepto Visual.
#### **Concepto visual**
En esta fase, buscamos alinearnos con el cliente para ofrecer un concepto a nivel visual que represente al proyecto.
Nos centramos en entender bien qué es lo que quieren transmitir y en buscar referencias que nos sirvan para comunicar de manera efectiva la dirección que queremos tomar en el proyecto.
Como referencia habitual realizamos una presentación con el cliente una vez definido en el que se presenta un **moodboard, con referencias aplicadas al cliente,** así como una propuesta de **Branding de mínimos** (Logo, tipografía y colores) en caso de ser necesario.
{% hint style="info" %}
El objetivo de esta presentación es tratar de sacar información valiosa del cliente y ver si la línea visual encaja con lo que tiene en mente.
{% endhint %}
Normalmente cuando presentamos el concepto, si es posible, utilizamos Loom, una herramienta que permite grabar la sesión. Terminada la presentación, se **le envía al cliente el enlace y las diapositivas**, permitiendo que pueda revisarlas con tiempo y utilizar una futura sesión a compartir feedback o resolver dudas.
Para ayudar a validar y alinear con el cliente el desarrollo del resto de las páginas, se trabaja en la creación de una propuesta "fake" de cómo se vería aplicada la línea de diseño en la Home, o pantalla principal. Esta no tiene contenido real, ya que es posible que no tengamos aún todo el material del cliente.
Gracias a la creación de esta propuesta, podemos determinar varios elementos clave como la estructura, módulos, tipografía, iconografía o colores.
### **Diseño**
Una vez que el **Concepto visual está validado por el cliente,** pasamos a la fase en la que diseñamos en **Figma las pantallas definidas en la fase de Definición.**
Una vez que el **Concepto visual está validado por el cliente,** nos reunimos con el equipo de Build para determinar qué es factible de diseñar y determinar el alcance basado en los tiempos que manejamos, permitiendo obtener una mayor autonomía y evitando sorpresas a la hora de maquetarlo.
Asentadas las limitaciones, pasamos a la fase en la que diseñamos en Figma las pantallas definidas en la fase de Definición además de aplicar los aprendizajes obtenidos en la simulación de la "fake home".
Trabajamos con dos documentos de Figma, por un lado el interno, donde el equipo trabaja el diseño y puede gestionar los diferentes artboards para facilitar su proceso. Cuando está completo, se trasladan las diferentes pantallas a otro documento, ordenando y presentando correctamente el flujo.
Durante el proceso de feedback, dependiendo de la madurez en diseño del cliente, se le guía y facilita para poder recoger el máximo de información y ejecutar las observaciones.
Antes de presentarle al cliente el diseño final y comenzar a maquetar, el equipo de diseño vuelve a reunirse con el líder de la squad de Build para identificar si hay algún aspecto del diseño que haya que modificar.
Una vez el diseño está aprobado y compartimos las pantallas con maquetación, se trabaja en la creación de un **toolkit.** Esto es una herramienta en la que recogemos todo el material utilizado en la web, desde la tipografía y sus tamaños hasta los diferentes componentes y su comportamiento. Es la concepción de un pequeño sistema de diseño.
# Build
Una vez finalizada la fase de Shape, es momento de empezar a construír. Te contamos cómo lo hacemos.
## **Build: Construyendo el proyecto**
El equipo de Build se compone de dos pilares principales, por un lado los maquetadores, que se encargan de implementar el diseño usando Webflow y algunas integraciones menores, y por otro lado, aquellos que trabajan en el desarrollo técnico.
Una vez que el diseño ha sido aprobado por el cliente, con todas las pantallas y flujos finales, es el momento de pasar al equipo de **Build** para que puedan construir el artefacto, ya sea una página web en **Webflow,** o un **MVP** más complejo utilizando diferentes herramientas no-code y código cuando es necesario.
Durante la maquetación, la comunicación con diseño sigue siendo diaria, utilizamos **Slack** para comunicarnos feedback ágilmente y levantamos reuniones en puntos que puedan generar fricción o dudas específicas que tengan el suficiente alcance en el correcto desarrollo del proyecto.
En ocasiones, una vez realizada la pantalla principal por parte de diseño, el equipo de Build, puede ponerse a desarrollar o hacer pruebas de concepto de la funcionalidad requerida por el cliente y establecida en el proceso de definición. Visualizar cómo se pueden implementar las partes más complejas ayuda a comunicar rápidamente a la squad de Diseño si hay que realizar algún cambio en el diseño o su planteamiento.
El proceso es fluido, ya que se adapta a cada proyecto, pero podemos definir brevemente la parte de build en estos dos flujos:
* **Product Marketing:** Se realiza el proceso de diseño, y una vez cerrado, se maqueta y se integran las diferentes herramientas No-code como Arengu, Integromat o Airtable.
* **MVP:** Durante el proceso de diseño se investiga y se ejecutan pruebas de concepto de cómo integrar la herramienta correcta de No-code en las necesidades del proyecto, se ejecuta en cascada, de la necesidad más compleja a la más simple en paralelo a diseño. En ocasiones, si el cliente quiere lanzar un nuevo producto, se realiza una landing page siguiendo gran parte del proceso de Product Marketing.
Pese a que parezca estructurado, cada encargo tiene su propia complejidad. Donde el proceso de diseño suele ser end-to-end o formado por sprints, dentro de Build existen más variaciones. Por ello intentamos estandarizar un proceso común que ayude a asentar las bases de los proyectos y, a partir de ahí, acotar y definir las posibilidades que tenemos para implementar los requerimientos del cliente.
# Data & Growth
Pese a que lo hemos dejado en último lugar, el proceso de Data forma parte integral del producto, desde la pre-venta hasta el lanzamiento.
## Data: Midiendo
Aunque en el proceso lo hemos situado como el último paso, la realidad es que la **Data** forma parte integral del producto, desde la pre-venta hasta el lanzamiento, con lo que los perfiles de data están envueltos en casi todas las fases del proyecto.
Es importante entender **cuáles son las necesidades a nivel de analítica** de nuestro cliente y si ya tienen un sistema previo montado - habitualmente en **Google Analytics -** en la preventa.
A partir de esta información, el equipo de **Data trabaja** en desarrollar un **plan de medición,** que responda a los objetivos del cliente y proporcionar una serie de indicadores clave o **KPI** que respondan a las necesidades del proyecto.
Este plan de medición será implementado en **Webflow** (o la herramienta correspondiente) a través de **Google Tag Manager, siguiendo la guía de etiquetado,** un documento que nos permite alinear a todos los equipos sobre qué información vamos a medir y qué atributos es necesario introducir en nuestra web para poder hacer este seguimiento.
Por último, creamos un **Dahsboard** utilizando **Google Data Studio** para poder proporcionar un lugar en el que visualizar la información de manera depurada.
Si el cliente lo desea, damos **nociones básicas de experimentación** sobre cómo puede hacer evolucionar su negocio, interpretar los datos y cómo podría iterar el producto en base a estos. El objetivo es ayudarle a que pueda experimentar y mejorar su negocio, y en caso de que sea complejo o necesite ayuda, seguimos aquí para apoyarle.
El proceso de data se compone de varias checklist que ayudan a estructurar los pasos que hemos comento, principalmente usamos:
* **Checks SEO:** Permite implementar las buenas prácticas de SEO en cada proyecto, diferenciando entre el tipo de proyecto y cómo se define e implementa.
* **Checks DATA:** Se crean las diferentes vistas de Google Analytics siguiendo las buenas prácticas de naming, se define la visualización principal, además de los objetivos y la configuración de Google Tag Manager y Google Data Studio.
* **Checks BUILD:** Guía de generación de contenidos para el cliente, comprobar que las cuentas estén asignadas correctamente, comprobar todos los enlaces funcionen correctamente y verificar otros aspectos formales como el formato de las imágenes.
# QA
Es la fase posterior al proceso de Minimum Shape and Build en el que tanto nosotros, como nuestro cliente nos aseguramos de que todo funciona correctamente.
## Quality assurance: que todo funcione correctamente
Antes de lanzar el proyecto, realizamos un proceso exhaustivo para asegurarnos que se ha implantado adecuadamente todas las fases del proyecto.
Esta se compone de los siguientes pasos:
* **Test user stories:** Durante el proceso hemos definido varios tipos de usuarios que utilizarían el proyecto. Nos ponemos en su posición y realizamos los diferentes flujos que pueden realizar para ver si se completan correctamente y evitar rebotes ocasionados por un mal funcionamiento.
* **Checklist de producto:** Revisamos todo el contenido del proyecto, desde los assets que se utilizan, el favicon, el Open Graph que aparece cuando se comparte un enlace, y sobre todo, si cumple con todas las reglas de SEO.
* **Revisión de cliente:** Compartimos con el cliente el proyecto para que realice un análisis de este, y alinearnos en que todo está correcto.
* **Test con usuarios:** La prueba final, elegir usuarios que cumplan el perfil de uso del proyecto. Permitiéndonos ajustar pequeños detalles que hayan quedado ambiguos.
Durante este proceso, se obtiene distinto feedback relevante que nos ayudan a iterar rápidamente el producto para mejorarlo. Una vez completadas estos test y checklist, está todo listo para su siguiente fase.
# Lanzamiento
Fase final del proceso de Minimum, es donde lanzamos el proyecto y recopilamos feedback de nuestro cliente y de su nivel de satisfacción con nuestros servicios.
## Lanzamiento
Esta parte es crucial ejecutarla correctamente, ya que es el momento en el que trasladamos el ownership al cliente y todo el material necesario del proyecto.
Nos aseguramos de migrar las diferentes integraciones y pantallas de webflow a la cuenta del cliente, en el caso de que no las tuviese, las realizaríamos nosotros y enviaríamos los credenciales de las distintas herramientas.
Comprobamos que el cliente tenga acceso a todo lo necesario. Si el cliente no sabe utilizar las herramientas del proyecto, hacemos una formación específica que le ayude a realizar futuras modificaciones que vayan surgiéndole según avanza su proceso de iteración.
Luego, compartimos los recursos de diseño, estos se componen de:
* **Archivo de Figma:** Este se compone de todos los pasos que se han realizado desde el inicio del proyecto y todas las pantallas del mismo.
* **Pack de assets de redes sociales:** Plantillas que permiten al cliente poder realizar una comunicación más efectiva en rrss.
* **Brandbook:** Toda la información necesaria del proyecto en términos de diseño, desde el logotipo hasta el uso de tipografía se recoge en este documento.
Compartirmos las diferentes demos por cada user story que haya sido generada, para que sirvan de referencia en el futuro.
También realizamos un seguimiento, este se compone de tres pasos:
* **Soporte de bugs:** En ocasiones un proyecto puede sufrir algún tipo de problema inesperado, estamos aquí para arreglar rápidamente el fallo que haya surgido.
* **Seguimiento por hipótesis:** Comprobamos y compartimos el avance del proyecto, validando si se cumple satisfactoriamente las premisas que hemos declarado y aquellas que han fallado, para poder iterar el producto en el futuro.
* **Informes resultados data:** Información cuantitativa del proyecto, nos permite junto a las hipótesis validar los caminos que hemos seguidos y cuales serían los siguientes pasos.
Una vez terminado todo esto, enviamos una encuesta **NPS** (Net Promoter Score) al cliente, que nos ayudará a cuantificar el servicio que hemos realizado y opinión cualitativa que nos ayudará a mejorar nuestro proceso.
# Stack de Herramientas Minimum
En este apartado encontrarás nuestro stack de herramientas actual. En Minimum estamos constantemente mejorando, experimentando y probando herramientas nuevas que nos ayuden a ser más ágiles y ofrecer un mejor servicio, con lo que esta página se estará actualizando constantemente.
En nuestro stack de herramientas puedes encontrar:
* [**Slack**](/herramientas/stack-de-herramientas-minimum/slack)
* [**Notion**](/herramientas/stack-de-herramientas-minimum/notion)
* [**Loom**](/herramientas/stack-de-herramientas-minimum/loom)
* [**Holded**](/herramientas/stack-de-herramientas-minimum/holded)
# Slack
Para la **comunicación más síncrona,** empleamos Slack.
Tras atravesar varias herramientas de comunicación en nuestro proceso, nos hemos decantado por esta herramienta por ofrecer la combinación necesaria de **control sobre notificaciones, gestión y comunicación con cliente** así como el poder tener una comunicación más ágil y fluida entre los miembros de equipo.
Hay tres **aspectos clave de nuestro uso de Slack:**
* **Canales del equipo**
* **Canales por proyecto**
* **Las Juntas**
* **Slack Connect**
### **Canales de equipo**
Estos canales son de **uso interno de minimum,** y son en los que tratamos las comunicaciones internas, sin que el cliente tenga acceso en ningún momento a estos canales.
Los dividimos por **departamentos,** así como **canales accesorios** que nos permiten tratar asuntos más generales.
Utilizamos una **nomenclatura** que nos ayude a identificar el **contenido de cada canal.**
Actualmente, tenemos los siguientes canales:
* \#general
* \#help-feedback-general
* \#team-build
* \#team-ops
* \#team-shape
* \#team-marketing
* \#team-build
* \#team-design
Disponemos también de dos canales especiales: **#ops-daily,** en el que compartimos nuestra daily escrita automáticamente, y #**ops-inspiración,** en el que compartimos con nuestros compañeros recursos interesantes que encontramos en nuestro día a día.
### **Canales de proyecto**
De cara a **trabajar con un proyecto, creamos un canal específico de uso interno.**
En cada canal están únicamente los **miembros del proyecto,** y lo empleamos para centralizar todas las comunicaciones del proyecto, para tener visibilidad.
### **Las Juntas:** Comunicación síncrona
Una de las **funcionalidades de las que más partido sacamos de Slack,** es la posibilidad de crear Juntas.
Salas de audio de conexión inmediata que te otorgan una **flexibilidad y sencillez** a la hora de comentar temas que sean más productivos hablar de viva voz. Por lo general la utilizamos para compartir inquietudes o resolver dudas con los miembros del equipo.
### **Slack Connect:** Invitando a los clientes
Slack Connect es una funcionalidad que nos permite proporcionar **acceso a los clientes a nuestro espacio de Slack,** para tener un canal síncrono de comunicación.
Gracias a esta funcionalidad, podrán tener **acceso únicamente a aquellos canales a los que han sido invitados -** permitiéndote tener un control muy preciso de la información a la que acceden.
En el caso de que una compañía ya tenga su operativa en Slack, nos conectaremos directamente en un canal compartido. En caso de que no sea su herramienta de comunicación interna habitual, crearemos un canal que compartiremos con el cliente que tendrá la siguiente **nomenclatura.**
{% hint style="info" %}
\#proj-\[nombredelproyecto]-shared
{% endhint %}
La principal ventaja de **Slack Connect es** que mientras tengan acceso a un único canal dentro de **Slack,** no te cobrarán por invitar a los clientes, generando un sistema escalable de comunicación con los clientes.
# Notion
Notion es la herramienta que utilizamos en nuestro día a día para la gestión y el almacenamiento de la **documentación relevante de cada proyecto.**
Buscamos dejar reflejado en **Notion** todos los aspectos relevantes de los proyectos, así como la organización interna, usándola principalmente para tres tipos de documentos:
* **Documentación de trabajo**
* **Documentación de consulta**
* **Ficha de proyectos**
* **Espacios personales**
### **Ficha de proyectos**
La **Ficha de un proyecto,** comprende toda la información relativa al proyecto para su **consumo interno,** así como información visible para el cliente, que tendrá en un lugar **centralizado** la información relevante de su proyecto.
Distinguimos entonces entre la **información de consumo interno:** Contiene info a la que no tiene acceso el cliente:
* **Enlaces a workspaces**. Enlaces a Figma, Webflow y
* **Shape**. Todo lo referido a la definición: PRFAQs, riesgos, enlaces a flujos en Miro, definición de KPIs...
* **Integraciones**. Listado de integraciones
* Dudas
* Acceso a la documentación del cliente
Y la **información de cara al cliente, donde encontrará:**
* **Equipo participante en el proyecto**
* **Objetivos**
* **Espacios de trabajo:** Lugares en los que acceder a la documentación de cada fase del proyecto.
* **Requisitos:** Documentación previa a comenzar el trabajo como puede ser el **Brief de Producto, de Marca...** para su consulta.
* **Tiempos y Roadmap**
* **Propuesta aceptada.**
### **Documentación de trabajo**
Dentro de la **Ficha de proyecto,** se genera documentación que se utiliza durante el transcurso del proyecto, ya sea para poder trabajar de manera interna en las distintas propuestas y entregables que se le darán al cliente, como para **presentar y compartir información con el cliente.**
### **Documentación de consulta**
Uno de los principales **valores de** [**minimum.run**](http://minimum.run) es el conocer, documentar y mejorar el proceso que seguimos de cara a nuestros clientes.
Continuamente estamos generando **aprendizajes,** que buscamos convertir en **conocimiento** a través de la documentación y dejar por escrito los procesos, consejos y trucos que usamos en nuestro día a día.
Es por eso que hemos creado una **base de datos,** que contiene toda la **documentación** que se va generando por parte de todo el equipo, con la opción de ser filtrada y buscar aquella más útil para cada situación.
Esta documentación es el primer paso de **consulta cuando surge una duda,** ya que recoge tanto procesos internos como documentación más técnica.
### **Espacios personales**
Los espacios personales **están creados para tener un lugar de trabajo individual para cada miembro de la empresa.**
En él se encuentra tanto un espacio de **libre disposición** para la creación de cualquier tipo de contenido que quiera, así como la **información relevante de la empresa,** como puede ser la política de vacaciones, los miembros del equipo, etc...
El uso de Notion dentro de la organización es algo que está en constante evolución y que buscamos que se adapte a nuestras necesidades, a medida que estas también van evolucionando.
# Loom
**Loom** es una herramienta que nos permite **compartir información** para su consumo asíncrono, ya sea para uso interno o para compartir y trabajar con clientes.
Gracias a esta herramienta, podemos **grabar pequeños fragmentos de vídeo,** en los que se puede mostrar pantalla y que nos sirven para trasladar ideas, compartir conocimiento, explicar cómo se resuelven dudas o poder **compartir avances con nuestros clientes.**
Usar Loom como herramienta nos obliga a **pensar los contenidos** desde la inmediatez, la concrección y el buscar explicar la mayor cantidad de información en el menor tiempo posible, para **crear contenido fácilmente consumible.**
{% hint style="info" %}
La principal ventaja de **Loom** es facilitar la consumición del contenido en el **momento que mejor venga al usuario/cliente.**
{% endhint %}
### Principales usos de Loom en minimum.run
Todos los empleados del equipo tienen **acceso a la cuenta corporativa de minimum.run,** lo que significa que pueden generar, consultar y consumir los **looms que genera todo el equipo. Principalmente,** generamos contenido para uno de los siguientes objetivos:
* **Grabación de documentación de consumo interno**
* **Presentación de propuestas a clientes**
* **Trasladar tomas de requisitos al equipo**
* **Dar/recibir feedback de un trabajo**
* **Compartir consejos/trucos con los compañeros**
### Tips, compartiendo píldoras de conocimiento
Una de las **iniciativas de formación internas, en colaboración entre** [**minimum.run**](http://minimum.run) **y** [**mendesaltaren** ](https://mendesaltaren.com/)**son los Tips.**
Los tips vienen a potenciar la cultura del estudio de **compartir y ayudar a nuestros compañeros, creando un espacio** para que de lugar a compartir aquel conocimiento que pueda ayudar a otros.
Tienen una duración de **5 minutos** y busca explicar conceptos que puedan ayudar a los miembros del equipo a profundizar en temáticas, desde la **comunicación al diseño técnico.**
En este caso, la limitación está impuesta por la herramienta, aprovechando lo que sería una característica de la herramienta que a priori puede perjudicar a la creación de contenido, nos ayuda a ser **concisos** y permitir condensar contenido de mucho valor en muy poco tiempo.
# Holded
Holded es una herramienta que utilizamos para organizar proyectos y tener una visión global de su estado, nos permite asignar tareas a cada miembro del equipo e imputar las horas de trabajo que se dedican a cada tarea. También la usamos tanto para fichar como para solicitar o informar de una ausencia.
### PROYECTOS
Todo el mundo tiene acceso al panel esté o no involucrado en el proyecto, así mantenemos una visión muy transparente de los procesos.
Tenemos plantillas creadas con con las tareas que normalmente se realizan en cada proyecto y las organizamos en 3 categorías siguiendo este esquema de color:
🟣 Morado **= Proyectos One-Shot**\
🟢 Verde = **Proyectos Ongoing** \
◻️ Gris = **Proyectos Propios**
Si entramos en uno de los proyectos hay una serie de iconos que nos permiten cambiar el estilo de visualización de los tableros y tarjetas:
BÁSICO - LISTADO - DIAGRAMA DE GANTT - SHEETS - CALENDARIO
El básico es el estilo predeterminado, pero veremos como a medida que completemos las tareas y asignemos fechas hay vistas como el diagrama de Gantt o calendario que son muy útiles.
#### **PROYECTOS ONE SHOT**
{% hint style="info" %}
#### Llamamos ‘one shot’ a la mayoría de los proyectos, son estos que tiene un roadmap con inicio y fin.
{% endhint %}
Para crear un nuevo proyecto one shot simplemente **duplicaremos la plantilla Morada** y el administrador podrá modificar las tareas existentes añadiendo o quitando dependiendo de las necesidades de ese proyecto concreto.
Existen una serie de tableros predeterminados (SHAPE - BUILD - QA - GROWTH) y cada uno contiene tarjetas con tareas detalladas.
Estas tarjetas contienen una serie de información que irá variando conforme avance el estado del proyecto ej: flechas que indican prioridad, estado,…
Si abrimos cada tarjeta encontramos la siguiente información:
* Título y link de la tarea
* Objetivo: descripción detallada de la tarea
* Categoría en la que se imputarán las horas de trabajo dedicadas a esta tarea
* Espacio para comentarios
También vemos un menú a la derecha donde vamos a detallar la prioridad de la tarea y las horas estimadas y **la persona encargada de la tarea** se encargará de actualizar el estado de la tarea y el tiempo que dedicar a trabajar en ella “ registros horario”.
Mediante la vista de resumen, nos da una visión general y permite ver el progreso y el tiempo real que se ha dedicado.
Los **archivos y notas.** Son apartados que solo las utilizamos para tener las tipografías compradas por cliente o recurso que el maquetador necesite tener muy a mano, sino en nuestro caso documentamos todo en notion.
#### PROYECTOS ONGOING / PRODUCTO PROPIO
En estos proyectos la vista del board es más sencilla pues centraremos las peticiones de clientes ongoing a través de Notion. Pero es importante que existan estos dos tipos de proyectos en holded para garantizar que documentamos las horas que les dedica el equipo.
#### IMPUTAR HORAS EN HOLDED
Algo de vital importancia para comprender si estamos estimando bien las tareas y conocer el tiempo real que dedicamos a cada una de ellas.
La persona que esté trabajando en cada una de las tareas, cuando termine o pause esa tarea tendrá que ir al menú que aparece en la derecha de la tarjeta :
Registros horarios > + > elegir una categoría (especificada en la descripción de la tarea en la tarjeta) > introducir el tiempo que hayamos dedicado > guardar
{% hint style="info" %}
Una persona puede imputar las veces que necesite al día en la misma tarjeta y tarea.
{% endhint %}
#### FICHAR
Debemos ser constantes y fichar cada día al comenzar nuestra jornada laboral y al salir.
Holded permite dos formas de fichar, automática y manual.
* **Automática:** a través de un botón: ENTRAR, tendremos que ir parando cada descanso, pausa para comer, etc…
* **Manual:** podemos escribir franjas horarias de tiempo a mano. Añadir y eliminar es muy sencillo con los botones de + y el icono de papelera.
#### SOLICITAR UNA AUSENCIA
Aquí encontramos un calendario que **incluye los festivos** (en nuestro caso de la comunidad de Madrid) y un panel a las izquierda donde podemos realizar nuestras solicitudes y ver si están pendientes o aprobadas.
Podemos tener una visión muy clara de días disponibles y días usados. Solicitaremos una ausencia o baja laboral de la siguiente forma:
solicitar días > se despliega un menú que iremos completando con el motivo, los días…> solicitar
Automáticamente aparecerá en el panel de la izquierda con la etiqueta “pendiente” hasta que sea aprobada.
Si se trata de ausencias por visita médica o partes de alta o baja laboral incluye una opción de adjuntar documentos que lo justifiquen.
Antes de hacer una solicitud formal de vacaciones informaremos internamente a nuestro responsable de equipo y una vez lo haya aprobado se solicitarán en holded para que quede un registro.
# Valores
### Valores de Minimum.run
* **Somos jugadores de equipo:** No hay espacio para individualismos. Somos mejores juntos y construimos procesos de forma abierta y colaborativa para conseguir los objetivos que nos proponernos como empresa.
* **Desafiamos lo establecido:** Somos pioneros, no solo por usar las herramientas más innovadoras del mercado y tener el mejor talento en el ámbito digital, sino que también Minimum desafía a las agencias tradicionales que tienen procesos lentos y poco transparentes.
* **Generamos una experiencia espectacular.** Además de por tener un proceso ágil, transparente y apostar por una comunicación fluída, nos diferenciamos por buscar la excelencia tanto de forma interna, como en nuestra relación con clientes.
* **Aprendemos y mejoramos continuamente.** Internamente estamos en constante aprendizaje de las últimas soluciones, procesos y tecnologías. De cara a nuestros clientes siempre buscamos mejoras en el proceso, la comunicación y la relación con el cliente.
* **No tenemos miedo al error.** Al desarrollar productos cuya finalidad es validar hipótesis, nos encontramos cómodos en entornos de gran incertidumbre. Analizamos, testeamos y aprendemos e iteramos de forma ágil para ofrecer mejores soluciones.
* **Buscamos el orden.** Dentro de la incertidumbre y las espectativas de crear un producto nuevo, buscamos un perfecto equilibrio mediante procesos que pulimos de forma continua y que nos permiten ser óptimos y eficientes.
* **Somos transparentes.** Analizamos, nos anticipamos y damos feedback directo, sincero y empático a clientes y equipos dentro de Minimum. No tenemos miedo a compartir aciertos y errores porque siempre buscamos innovar y mejorar.
* **Impactamos en resultados.** Todo lo que hacemos lo hacemos desde un punto de vista analítico, con un buen diseño que está respaldado por los mejores profesionales, pero siempre ponemos el foco en mejorar resultados de negocio de nuestros clientes.
# Cultura en Remoto
La sede central de Minimum se encuentra en Madrid. Todas las personas de la organización pueden trabajar de forma presencial en nuestra oficina.
### Horarios **en remoto**
Ser Remote First quiere decir que puedes vivir en Madrid y trabajar en tu casa, o vivir en Alicante e irte un mes de turismo por Alemania y trabajar desde allí. Lo único que pedimos es mantener las horas de solapamiento donde todos estaremos conectados:
{% hint style="info" %}
🕥 Las horas que debes estar disponible son de **10:00 a 15:00 (GMT +1)**
{% endhint %}
Esto quiere decir que:
* Intentamos que todas las reuniones, tanto internas como externas, sean dentro de este horario. No siempre es posible y pedimos que lo comprendas y puedas adaptarte a las excepciones.
* Antes y después de este horario de solapamiento, puedes gestionar tus horas como quieras, siempre que hagas tu jornada semanal de 40hs.
* Lo único que pedimos es que cumplas con tus objetivos y proyectos, y que te coordines con tus compañeros.
### Reuniones en remoto
Hay algunas **buenas prácticas** respecto a las reuniones que podemos utilizar cuando trabajamos con personas en remoto, pero lo cierto es que son aconsejables para trabajar con compañeros de todas las condiciones. Es más fácil olvidarse de un compromiso con un *remoter* ya que no estamos en la oficina de forma física.
#### Respetar el tiempo de los demás
Todos los puntos que figuran a continuación tienen que ver con tener respeto por el tiempo de los demás. Cuando llegas tarde a una reunión de manera repetida, no asistes, cambias la agenda a última hora o no tienes en cuenta su disponibilidad y horario, estás poniendo de relieve de forma involuntaria o inconsciente que **tus necesidades y tu tiempo es más valioso que el de tu compañero**, que se puede permitir quedarse esperando o re-agendar su día sin previo aviso. Ten empatía e intenta prever todas las situaciones siguientes.
#### Flexibilidad
**Si nos esforzamos en aplicar estas recomendaciones** mejorará mucho la salud de la dinámica empresarial y la comunicación con los compañeros en remoto. Pero también debemos entender que siempre se darán casos aislados e imprevistos y que hay que ser flexible.
### Recomendaciones para una cultura remota efectiva y saludable
#### Afina tus estimaciones.
* Las reuniones de 30min son la norma. Excepto cuando se establece una dinámica entre dos personas que trabajan mucho juntas (y por tanto se conocen mejor) o hay un guión bien definido de la misma y nos ceñimos a éste, las reuniones no suelen durar tan poco.
* Las reuniones duran más cuantos más participantes individuales (componentes del mismo equipo) o stakeholders haya (P.ej: cliente, más agencia, más proveedor etc.)
* Consulta a la persona con la que te vas a reunir cuánto tiempo deberías bloquear en la agenda. Puede que tu idea de la reunión no coincida con la de tu compañero. Si estimáis entre todos, será más exacto.
**Lo urgente y lo importante**
Es muy fácil confundir lo urgente con lo importante. Llamadas de última hora, gente que te requiere con dudas, visitas inesperadas... Tanto si eres a quién interrumpen con algo "urgente" o "inesperado" como, **sobre todo**, si eres la persona que interrumpe a un tercero con cosas fuera de calendario, intenta pensar primero en que esa persona puede estar ocupada y tener otros compromisos. Para esto es muy útil:
* **Mirar el calendario de los demás**, al que todos tenemos acceso en Google Calendar.
* Si se trata de dudas y no son bloqueantes, utiliza Slack y te contestarán cuando puedan. En Minimum **nadie espera respuesta inmediata en Slack**, tenlo en cuenta tanto cuando escribes y cuando te escriben.
**Google Calendar es tu amigo**
**Configura tu calendar para que te avise** por tantas vías y tantas veces como creas necesario. Por nuestra experiencia, funciona muy bien que te avise:
* **Notificaciones de correo**: media hora antes
* **Notificaciones de escritorio**: 1h antes y 15 min antes.
También sincronízalo con Slack para tener avisos por más vías y enseñar a tus compañeros que estás reunido. Actualiza automáticamente tu estado así que es cómodo. Puedes hacerlo aquí
#### Indica tu disponibilidad con la funcionalidad de estado de Slack
Si estás comiendo, de vacaciones o en una reunión recuerda [actualizar tu estado y disponibilidad en Slack](https://slack.com/intl/en-de/help/articles/201864558-Set-your-Slack-status-and-availability).
Además, [Slack tiene una app](https://slack.com/app-pages/google-calendar) que sincroniza Google Calendar con tu estado cuando tienes una llamada y te notifica de cuando tienes una call.
# Onboarding de compañeros
Un buen onboarding garantiza que los nuevos integrantes se adapten de forma acelerada a un ritmo de trabajo alto sin generar fricción, es por ello que para nosotros es muy importante.
Los nuevos integrantes de Minimum reciben un email con acceso a su página de Onboarding en Notion. Esta página, contiene una serie de pasos que la persona debe realizar durante su primer día y su primera semana en la empresa.
A continuación podrás ver algunos de los pasos de la check-list a completar el primer día de trabajo en Minimum Run:
### 1. Comprueba tu email
El primer paso es comprobar que tienes acceso a tu dirección de email. En Minimum usamos la suite de Google, con lo que el acceso a tu nueva dirección de correo te tomará tan solo unos minutos.
### 2. Conoce a tu Buddy
Para cada nuevo miembro, y en función de su rol, elegimos un buddy. Se trata de una persona con experiencia dentro de la emprsa que te acompañará durante todo el onboarding y será la persona más adecuada para responder a prácticamente todas las preguntas que tengas. Sin embargo, cualquier persona de la empresa estará más que disponible para ayudarte.
### 3. Comprueba tu acceso
El tercer paso a realizar es comprobar que se tiene acceso a nuestro stack de herramientas (este variará dependiendo de tu perfil en la empresa).
### 4. Working with
En Minimum hay gran equipo humano detrás, y muchos compañeros a los que conocer. No trabajaremos mano a mano con ellos, dada nuestra condición en remoto, pero nos gustaría que los conocieras y añadas tu working with a la lista.
Uno de tus deberes de será **agendar `catch ups`** o encuentros rápidos de 10-15 mins **con todos los miembros del equipo minimum** para tus primeras dos semanas. Puedes encontrarlos en Slack y pedirles disponibilidad para agendar la llamada.
### 5. Completa tu perfil
En este paso debrás completar, tu ficha en todas partes (nuestra web, slack, tu usuario de chrome...) con tu descripción, puesto y foto.
Además de estos pasos, puedes encontrar otros enlaces de interés con nuestros valores, cultura en remoto y metodología de trabajo:
* [**Cultura en Remoto**](/la-empresa/cultura-en-remoto)
* [**Valores**](/la-empresa/valores)
* [**Metodología Shape & Build**](/el-proceso-de-minimum/minimum-shape-up)