6 min de lectura
¿Cuál es la cultura de NocodeHackers Solutions?
Lo más importante a la hora de enfrentarse a desarrollar cualquier agencia es la cultura del equipo.
La cultura se basa en entender qué comportamientos premias y cuáles castigas, como dice nuestro socio Danny Saltaren. Y ello tiene un impacto directo en tus procesos, el grado de satisfacción de los clientes con los proyectos que haces y tu tranquilidad mental.
En nuestro caso, las personas que forman parte de NocodeHackers solutions deben compartir una serie de valores y actitudes que hagan que lo que hacemos es posible. Con el tiempo hemos ido aprendiendo que quizá nuestra manera de operar y comportarnos no es la de una agencia de desarrollo al uso, lo que hace precisamente que tengamos cierta ventaja competitiva que no es posible replicar. Y en este capítulo precisamente intentaré desglosarte las cosas que hacen nuestra cultura relevante y diferente.
Somos parte del equipo de producto de la empresa. No una agencia más.
Lo habitual cuando empiezas un proyecto con una agencia es que partas de una serie de necesidades o requisitos funcionales por parte del cliente. Como primer paso, deberás hacer una definición del alcance de lo que debes construir, listando todas las tareas a acometer. Una vez aprobado el presupuesto, llega el momento de construirlo, donde lo normal es ajustarse a lo que inicialmente se había definido, luchando cualquier modificación en alcance que se salga de lo inicialmente pactado.
Y si bien esto es algo que realmente tiene todo el sentido del mundo, es algo que no va con el tipo de proyectos que habitualmente trabajamos.
La razón es que cuando un cliente nos contrata es porque se enfrenta a un reto en el que hay una gran incertidumbre, ya sea por ser una nueva línea de negocio que no está validada o es un reto operativo complejo.
Por su propia esencia, los proyectos con alta incertidumbre son imposibles de estimar.
Lo que está escrito en el alcance de la propuesta no es más que un punto de partida sobre el que se podrán dar infinitos caminos.
A nosotros nos gusta acompañar al cliente en este proceso, entendiendo ambos que es un camino a recorrer durante el que es probable que nos encontremos:
Cambios en el alcance: Ya sea por peticiones del cliente o sugerencias propias.
Imposibilidades técnicas: Quizá nos encontremos algún bloqueo propio del stack tecnológico que hayamos elegido.
Propuestas de mejoras: Muchas veces de manera proactiva sugerimos posibilidades de hacer las cosas de manera diferente a lo inicialmente planteado, aunque sea más trabajo para nosotros, siempre que consideremos que tiene sentido para el proyecto.
Al final, nuestro objetivo es que el proyecto salga lo mejor posible, para lo cual nos gusta entrar a entender bien el negocio del cliente, el reto al que se enfrenta y tomar una posición bastante activa a la hora de tomar las decisiones de producto. Es cierto que siempre hay una parte final de decisión por parte del cliente, pero en el 90% de las veces nos hace hacer mejores productos trabajar de esta manera.
Esto conlleva por un lado dos grandes aspectos:
Hay que ser muy conscientes de que el roadmap puede cambiar
Si el proyecto cambia demasiado, puede que haya que renegociar la propuesta para adaptarse a las necesidades de proyecto.
Hablaremos en la parte del proceso en más detalle acerca de esta fase, pero sin duda son dos aspectos de los que debemos ser conscientes (y hacérselo saber al cliente) en cualquier proyecto hecho en No-code.
Nos esforzamos en reducir la incertidumbre
Si el principal reto que abordamos es precisamente la incertidumbre, nuestra misión es tratar de reducir la incertidumbre lo antes posible.
Es por eso que en nuestra manera de trabajar buscamos constantemente el mínimo producto viable que nos permite validar que lo que quiere el cliente y lo que queremos construir es lo mismo.
Y esto puede parecer sencillo pero en realidad es quizá la parte más compleja de cualquier proyecto. Ante cualquier idea de un cliente le acompaña una visión en su mente de como debe ser la solución. Puede que esté más o menos definida pero sin duda sabrá lo que quiere.
Sin embargo puede que la solución a la que lleguemos nosotros sea diferente a lo que se imaginaba, ya sea por mal entendimiento del problema a resolver o porque creemos que es una mejor solución al problema al que se enfrenta el cliente.
Si empiezas a trabajar en el proyecto y el primer punto de validación con el cliente es (por poner un ejemplo) en dos semanas, puede que te encuentres con que esa discrepancia era relevante y no era lo que el cliente buscaba. Ahora te encuentras con dos semanas menos de proyecto y trabajo que debes empezar de cero.
Nuestro objetivo es enfrentarnos a ese feedback del cliente lo antes posible.
Si podemos hacer una versión lo suficientemente buena como para poder grabar un pequeño loom y compartírselo a los dos días de iniciar el proyecto, mucho mejor que hacerlo una semana después. Esto nos permite poder enseñar cosas tangibles al cliente lo antes posible para que valide si era lo que tenía en mente. A su vez, nos permite a nosotros centrarnos en la validación técnica necesaria para comprobar que lo que queremos hacer técnicamente es viable.
Una vez que tengamos esta prueba de concepto validada, entramos en la fase de construcción y refinamiento, donde cogeremos la base que ya tenemos y nos aseguraremos de que es robusta y cumple todo el feedback que nos ha dado el cliente.
Esta manera de trabajar precisamente es algo que forma parte de nuestra cultura y lo que suele garantizar el éxito de los proyectos que hacemos. Hablaremos en futuros capítulos en más detalle de cómo lo hacemos.
¿Qué tipo de personas forman parte del equipo?
Sabiendo que constantemente nos enfrentamos a proyectos con alta incertidumbre, el tipo de perfiles que forman parte del equipo tiene una serie de características bastante particulares (y nada sencillo de encontrar). La incertidumbre no es algo que todo el mundo sea capaz de llevar bien, pues es frustrante tener que destruir trabajo hecho por no haber entendido bien al cliente, o que cambie el scope de lo que tenías que hacer y ahora sea el doble de complejo y complicado.
Es por eso que las personas que formamos parte del equipo de NocodeHackers Solutions tenemos una tolerancia particular a la incertidumbre y al desapego de las soluciones que construimos.
Esto nos lleva a que los perfiles que forman parte del equipo habitualmente reúnen las siguientes características:
Tienen experiencia laboral previa, entre 2 y 3 años de mínimo. Se han curtido en proyectos complejos, ya sea de desarrollo, diseño o innovación.
Son innovadores, les gusta estar constantemente probando las nuevas herramientas y nuevas funcionalidades que van saliendo en el mercado o de las herramientas que más utilizan en su día a día.
Son capaces de hablar directamente con clientes: Esto es algo realmente clave dentro de nuestro equipo, ya que queremos acercar al máximo el entendimiento de las necesidades de los clientes a la persona que construye.
Buscan soluciones creativas: Tener límites obliga a que en ocasiones tengamos que dar vueltas a un proyecto hasta que encontramos una manera de solucionarlo de una manera bastante frecuente.
Un cierto grado de inconsciencia: Muchas veces tenemos que ofrecer soluciones sin estar al 100% seguros de que funcionará. Podemos hacer pruebas de concepto para reducir riesgos, pero debes vivir con esa sensación constante de vértigo ante nuevos retos.
No quiere decir que todo el equipo tenga estas cuatro cualidades desarrolladas al máximo, pero sí que es algo que se denota de cómo funcionamos. Y todo ello es parte de nuestro proceso y nuestro modelo de gestión de clientes.
No creemos en los Project Managers
Habitualmente conforme crece una agencia y cada vez hay más proyectos a la vez, se tiende a contratar personas que su rol es ser el punto de contacto con el cliente y el equipo de desarrollo, haciendo de transmisor de las necesidades al equipo y de los problemas y necesidades al cliente.
Sin embargo, cuando desarrollamos herramientas en No-code este rol no tiene sentido. Creemos que la persona que construye debe estar lo más cerca posible del cliente, con la menor cantidad de intermediarios posible entre la necesidad y la solución.
La razón de ello es que la velocidad que tenemos a la hora de construir es realmente elevada y muchísimas veces es mucho más rápido el construir una funcionalidad directamente que hacer un "buen" entendimiento, bajarlo a una serie de requisitos, convertirlo en una tarea, asignárselo a la persona correspondiente y que luego lo ejecute.
En todo ese proceso pasan habitualmente dos cosas:
Se invierte más tiempo en definir e intentar transmitir la solución, que en resolverlo. Esto aplica principalmente a pequeños cambios o modificaciones en el proceso, no tanto a nuevas funcionalidades o arranques de proyectos, pero se da continuamente situaciones en la que lleva más tiempo escribir lo que hay que hacer que cambiarlo.
No tener el conocimiento técnico del proyecto, puede llevar a decisiones malísimas: Si la persona que está hablando con el cliente no entiende en profundidad las herramientas con las que se va a construir se pueden tomar decisiones críticas sobre el proyecto, sin tener en cuenta las posibilidades de la herramienta en la que está construido, o la arquitectura que tenemos implantada. Esto por supuesto, se soluciona con Project Managers que sepan construir, pero entonces ¿por qué no construir directamente?
Malentendidos: Esto (extra) es fruto de esa intermediación. En el proceso de entendimiento y transmisión de las necesidades se pueden entender distintas partes del proceso de manera diferente y que lo entregado no sea lo esperado.
Por ello nosotros buscamos que la persona que construye el proyecto sea la misma persona que interactúa con el cliente.
Cabe decir que no siempre lo conseguimos ya que en este caso Álex, suele ser la primera persona de contacto del cliente y a veces es necesario que esté implicado en el proyecto y haga esa fase de discovery. Sin embargo esto es así únicamente en proyectos en los que luego se vaya a implicar técnicamente en el desarrollo, aunque no recaiga toda la ejecución en él.
Por supuesto esto requiere de la madurez del equipo, que sea capaz de afrontar la gestión con clientes de manera autónoma, por lo que la mayoría de nuestro equipo viene de tener experiencias previas gestionando clientes como freelance, lo que da un auténtico plus a la hora de gestionar estas situaciones. Los momentos tensos se pueden dar, sin embargo ahí es donde la fuerza del equipo puede estar para apoyar y entrar en los momentos que sean necesarios a hablar con el cliente y buscar una solución.
Compartimos nuestros aprendizajes y nos apoyamos a resolver las dudas
Es imposible ser experto o experta en todas las herramientas que usamos en nuestro día a día. Habitualmente surgirán problemas y bloqueos que harán que te quedes bloqueado y puede que no seas capaz de avanzar. O quizá no sepas si la manera en la que actúas es la correcta y hay otra manera de enfocar el problema.
Es por ello que nos esforzamos en compartir nuestro conocimiento, a través de dinámicas internas y generando documentación (aunque siendo sinceros podríamos mejorar esto) y levantar la mano ante cualquier problema que nos encontremos.
El jugar en equipo es clave para poder construir productos que realmente estén bien técnicamente y nos permite enfrentarnos a retos más complejos al sumar las habilidades de los diferentes miembros del equipo.
Pero sobre esto, hablaremos en detalle en el apartado sobre cómo trabajamos. Continuaremos exponiendo cuál es nuestro proceso y nuestra manera de trabajar con nuestros clientes.