Cómo externalizar el desarrollo de un producto tecnológico en una startup

Introducción

A lo largo de los últimos años, he conocido un gran número de emprendedores que no sabían nada de tecnología, a pesar de que la startup que estaban impulsando necesitaba este tipo de desarrollo. Esto me ha ayudado a elaborar mis propias estadísticas, en las que he detectado que alrededor del 70% de startups tiene problemas al externalizar desarrollo tecnológico.

Dichos problemas, según la propia percepción del emprendedor, se deben principalmente a lo siguiente:

• Siempre terminan alargándose los plazos de entrega, no recibiéndose en las fechas previamente acordadas.
• No se cumplen las expectativas sobre el producto recibido. Se esperaba algo distinto, tanto a nivel general como en los múltiples detalles.
• El equipo de desarrollo no es flexible. Se producen quejas por los cambios, pues no tienen en cuenta de que una startup puede ir evolucionando en la forma de ver el producto.

Pero, ¿hay algo que pueda hacer una startup para paliar esos problemas que surgen al externalizar el desarrollo de producto?

La mejor solución es lograr establecer una metodología de trabajo entre la startup y la empresa de desarrollo. A pesar del gran número de cosas por hacer, conseguiremos una gran mejora si nos centramos, principalmente, en los siguientes detalles:

• 1.- Identificar claramente qué partes externalizar.
• 2.- Dar especificaciones claras y concisas de lo que se desea.
• 3.- Establecer un proceso de validación progresiva y flexible al cambio.

1.- Identificar claramente qué partes externalizar

Para crear una plataforma digital se tienen que cubrir distintas áreas de trabajo, desde las más conceptuales a las más específicas y técnicas. Todas las áreas son fundamentales y se pueden visualizar como distintas capas a definir y crear:

• Negocio: Objetivos, estrategia, etc… determinada por el CEO, directivos y fundadores.
• Experiencia de usuario: Las principales actividades que realizaran los usuarios y los aspectos relacionados (emociones, etc…)
• Interface de usuario: Flujo de la herramienta, wireframes y diseño gráfico.
• Contenido: Copys, redactores, fotógrafos, …
• Programación y estructura de datos: Analistas y desarrolladores.
• Servidores: Hosting, dominios, …

Las principales características a considerar al crear la plataforma son:

• Especificar de arriba abajo: Primero es la definición de negocio y a partir de esta capa se tiene que ir "bajando" y concretando las otras capas según lo especificado en la capa superior.
• Pero con un diálogo: Ya que los conocimientos expertos de una capa pueden ayudar a mejorar o optimizar la plataforma. Por ejemplo, posibilidades o limitaciones técnicas pueden hacer cambiar alguna de las especificaciones de negocio.
• Guardando la coherencia entre sí: de manera que si por ejemplo elegimos un lenguaje de programación concreto el servidor tiene que ser compatible

2.- Dar especificaciones claras y concisas de lo que se desea

Normalmente, un emprendedor no tiene claro qué es lo que quiere. Se trata de algo bastante normal en las startup que buscan crear algo nuevo, que en lugar de hacer una apuesta clara sobre cómo quieren que sea el producto, lo definen de manera ambigua, delegándolo al equipo de desarrollo.

De esta manera, el equipo de desarrollo se encuentra con que tiene que dilucidarlo todo, tomar decisiones de negocio, encontrar un flujo de clientes… Es decir, realizando tareas que no se corresponden con su papel. Y al no poseer los conocimientos suficientes, las decisiones de negocio que toma del equipo de desarrollo suelen ser malas , por lo que el resultado es malo y muy distinto a lo que el emprendedor quería.

Así que, a través de estas herramientas, podemos especificar lo que queremos que se “vea” en nuestro producto, dejando que el equipo de desarrollo se encargue de crear los elementos internos necesarios. El problema surge cuando el emprendedor, al no saber de tecnología, no sabe como dejar claro aquello que se tiene que ver.

Para paliar este problema, se puede dar unas especificaciones claras y precisas de lo que se desea a través de estas herramientas:

1. Mapa de flujo de la experiencia del cliente.
2. Especificaciones de funcionalidades: Wireframes.

2.1.- Mapa de flujo de la experiencia del cliente

Este mapa nos ayudará a determinar cuál es el camino que queremos que recorra el cliente. Pero, como sabemos que no todos nuestros clientes recorrerán el mismo sendero, tendremos que añadir distintas bifurcaciones.

Visualmente hablando, la definición de un camino sería el siguiente:

Gracias al hipertexto de la web/móvil encontraremos múltiples caminos, por lo que será conveniente especificar su estructura a través de un mapa jerárquico y relacional, como podremos ver en el siguiente ejemplo:

Con el fin de que quede todo mucho más claro, a continuación tenéis otro ejemplo con más información asociada:

2.2. Wireframes

Una vez disponemos de una estructura base, la siguiente tarea será especificar cada paso, que consiste –en la mayoría de casos–, en establecer cada una de las pantallas de nuestra web.

Para ello utilizamos los Wireframes. La función de un wireframe –también conocido como plano de pantalla–, es la de representar la arquitectura visual de nuestro sitio web para que conecte con la estructura conceptual, ayudando a establecer la funcionalidad y relaciones entre sus diferentes plantillas y pantallas. Es decir, con los wireframes podremos determinar la funcionalidad, de forma que el equipo de desarrollo la entienda y disponga de especificaciones claras y precisas de cómo debe ser el resultado de su trabajo. Además, los wireframes deben ir acompañados de descripciones más detalladas en aquellos elementos que sean necesarios, pues una imagen no siempre es suficiente para explicar la función que tiene que realizar el producto. Un ejemplo sería el de determinar lo que sucederá al hacer clic en un botón o el movimiento que deberá tener una imagen en la cabecera.

Un ejemplo de visual de wireframe es:

En este otro caso, el wireframe es más parecido al resultado final por el diseño incluido:

Un ejemplo de wireframe para móvil:

3. Establecer un proceso de validación progresiva y flexible al cambio

Cuando el emprendedor visualiza la realidad de un producto termina viendo las cosas de otra forma: se da cuenta de que la teoría siempre es distinta a la práctica, ya que aparecen detalles que hasta el momento no se habían considerado, como la aparición de nuevas oportunidades o el descubrimiento de que la forma de funcionar no era la más adecuada.

Con el fin de paliar estos problemas, se aconseja trabajar con algún tipo de “metodología ágil de desarrollo”. Dentro de las metodologías ágiles, existen múltiples tipos, como Scrum o Kanban, cada una de ellas con particularidades que se adaptan a distintos modos de trabajo.

En este artículo no nos detendremos en explicar cada una de estas metodologías ya que, aunque son muy útiles, necesitarían un post completo para aprender a aprovecharlas al 100%. Sin embargo, sí que presentaremos una serie de consejos útiles basados en estas metodologías, que de aplicarse, se percibirá un salto de calidad en la relación existente con el equipo de desarrollo. Cada startup podrá adentrarse entonces en el uso de Scrum, Kanban o cualquier otra metodología que se mejor se adaptase a su método de trabajo.

Así que, para establecer un proceso de validación progresiva y flexible al cambio, se trabajará en función a unos objetivos constituidos periódicamente, que serían los siguientes:

1. Establecer adecuadamente los objetivos.
2. Fijar un periodo de tiempo para obtener los resultados deseados.
3. Crear una buena dinámica de reuniones fijas.

3.1. Establecer adecuadamente los objetivos

Para fijar objetivos, están muy extendidos los criterios SMART (del inglés Specific, Measurable, Achievable, Realistic, Time-base), los cuáles desglosaremos a continuación:

• Specific (Específicos): hay que ser lo más concreto y específico posible para poder identificar los objetivos que se desean alcanzar.
• Measurable (Medibles): para poder comparar de forma tangible si se ha alcanzado realmente el objetivo.
• Achievable (Alcanzable): el fin no tiene que resultar inalcanzable, pero tampoco estar por debajo de las posibilidades de la startup.
• Relevant / Results-based (relevante / orientado a resultados): deben ser unos objetivos que, de conseguirlos, nos aporte resultados de valor.
• Time-base (Acotados en el tiempo): debe existir un tiempo definido en el que deban ser alcanzados.

En el caso que nos ocupa –saber como subcontratar el desarrollo tecnológico–, es sumamente importante considerar que, en cada periodo los objetivos tienen que aportar un valor y resultados claramente visibles para los emprendedores.

Es decir, que si nos encontráramos ante un objetivo demasiado ambicioso, deberíamos fraccionarlo en pequeñas metas o sub-objetivos, para que cada uno pueda alcanzarse en la periodicidad establecida y comprobar a su vez los resultados. Por ejemplo, si la web contara con perfiles de usuarios, el primer objetivo podría ser establecer una buena estructura en la base de datos, con los campos adecuados para la creación de esos perfiles, además de visualizar el resultado en la base de datos y comprobar las relaciones entre ellos. No hay que dejar pasar el tiempo y comprobar que los datos dispuestos en los perfiles de los usuarios sean los adecuados.

Otro aspecto fundamental es consensuar los objetivos entre el equipo de desarrollo y la startup. Éstos no tienen por qué fijarse de forma unilateral, ya que entonces no se cumplirían algunos de los criterios descritos anteriormente.

3.2. Fijar un periodo de tiempo para obtener los resultados deseados

Es sumamente importante establecer siempre una misma periodicidad a la hora de ir cumpliendo los objetivos.

De este modo, podremos conocer tanto el ritmo de trabajo como la capacidad del equipo de desarrollo. Aun así, es normal que al principio surjan desajustes, ya que puede que algunos objetivos no se consigan y que otros sean muy poco ambiciosos. Por ello es importante insistir en respetar los periodos de tiempo, de manera que conforme se avance, se conozca cuál es la capacidad real en el desarrollo del trabajo, y poder ajustar más eficientemente los objetivos.

Al cabo de un tiempo habrá un buen entendimiento entre el equipo de desarrollo y la startup, por lo que será más fácil consensuar dichos objetivos. Esto no sería posible si cada periodo tuviera plazos diferentes, dificultando en gran medida el aprendizaje de la capacidad de desarrollo del equipo.

3.3. Crear una buena dinámica de reuniones fijas

Una vez tenemos claro la importancia de que los objetivos se establezcan en periodos fijos, es el momento de definir las reuniones que se realizarán para finalizar la fase y poder pasar a la siguiente.

En dichas reuniones se tendrá que abordar las siguientes cuestiones:

1. ¿Se ha hecho el trabajo? Se revisarían los objetivos del periodo anterior para comprobar si se han alcanzado. De no haberlo conseguido habría que averiguar el por qué. En este punto hay que recordar la importancia de que el emprendedor pueda visualizar unos resultados de valor para el correcto avance de la startup.
2. Ponerse al día para informar sobre noticias y acontecimientos que hayan transcurrido desde la última reunión.
3. Resolver dudas. Es de vital importancia solucionar cualquier tipo duda que se presente, ya sea por parte de la startup o por el equipo de desarrollo. Para ello, lo mejor es tener en cuenta estas premisas:
   • Seleccionar las dudas más importantes, ya que quizás en una única reunión no puedan resolverse todas ellas. Así que, como mínimo, deberían resolverse las más relevantes. En caso de ser necesario, se podría realizar una reunión independiente para resolver todas las dudas y problemas con el fin de evitar que las reuniones periódicas se hagan demasiado largas.
   • Identificar las dudas de forma objetiva, ponerlas en contexto y delimitarlas.
   • Profundizar en cada una de ellas para conocer los detalles.
   • Por último, dar solución.
4. ¿Qué nos gustaría hacer? Plantear cuál seria el siguiente paso que se debería abordar.
5. ¿Qué nos comprometemos a hacer en este periodo? Consensuar los objetivos que se asumirán para esta etapa. Recordemos que la finalidad de estas reuniones son elegir y especificar claramente los objetivos.

Otro aspecto fundamental a tener en cuenta sería la duración de estas reuniones, las cuáles deberían durar entre 90 o 120 minutos como mucho. Este tiempo debería ser suficiente para ir al grano, habiendo realizado un trabajo previo de valoración en los objetivos de la fase para poder plantear los de la siguiente. Una reunión demasiado larga podría convertirse en algo pesado y tedioso.

Resumen

En definitiva, para poder disminuir los problemas que surgen en la startup al subcontratar el desarrollo de un producto, recomendamos: