Me gusta escuchar el ding del teléfono varias veces cada día. Quiere decir que un cliente potencial nos ha enviado un email pidiéndonos ayuda para un proyecto o que le mandemos un presupuesto. Se me acelera el pulso y me lanzo a trabajar.

Abro el correo, ilusionado. Según voy leyendo el correo, me vengo abajo. Mis ganas de cerrar un proyecto grande en el que poder sacar pecho y mostrar todo nuestro potencial se vienen abajo. Para muestra de email, uno recibido ayer:

Hola,

tengo una empresa con una aplicación de gestión muy vieja y quiero pasarla a web y móvil. Gestionará empleados, clientes, pedidos, calendarios de trabajo, gestión de nóminas y que se comunique usando un sistema cloud como twilio.

¿Cuánto cobráis por hora? ¿Cuánto me va a costar el proyecto? ¿Crees que lo podréis tener listo en 3 meses?

Un saludo

Recibimos muchos correos como este, de personas que no tienen mucha experiencia haciendo proyectos digitales. Todos cometiendo los mismos errores.

¿Sabes el dicho que dice "Es más fácil ver la paja en el ojo ajeno que la viga en el propio"?

Pues tiene toda la razón. Nosotros hemos metido la pata un montón de veces. Pero lo dejaremos para otro post, que si no nos quedamos sin temas de los que hablar.

Te voy a contar los errores más comunes que se repiten cuando se nos acerca un cliente potencial. Todos somos humanos y los puede cometer cualquiera, aunque ya tengas mucha experiencia haciendo proyectos digitales. Por eso es importante tenerlos presentes a la hora de iniciar un nuevo trabajo.

Estos errores se pueden aplicar tanto a clientes externos como al equivalente a un "cliente", que puede ser tanto otro departamento de tu propia empresa como un jefe directo.

O un emprendedor. O tú mismo con un proyecto interno (que también nos ha pasado a nosotros). Vamos a verlos.

1) No tengo claro lo que quiero, pero es esto

Es el error más habitual y el más delicado de tratar. Hace unos días me volvió a pasar, aunque al final cerré el proyecto con el responsable de la empresa.

Todo empezó bien, con una introducción a través de un cliente pasado. Nos reunimos y me cuenta el proyecto. Todo en líneas generales, pasando por alguna funcionalidad importante y obviando muchos aspectos. Le pido que me especifique un poco más, a ser posible por escrito y saca la respuesta comodín:

".. mejor te lo cuento, que yo lo tengo muy claro en la cabeza, y vosotros (que sois los expertos) ya sacais el resto...", me dice.

Toma de requisitos

Ouch.

En este caso caben dos opciones:

  1. Haces caso al cliente e intentas partir de esa información para ir adelante con el proyecto (SPOILER-> desastre)

  2. Le explicas que es imposible hacerlo de ese modo. Primero porque es información insuficiente y segundo porque puede que la solución que él tenga en la cabeza no sea la mejor para conseguir sus objetivos. Lo mejor es primero hacer una fase de análisis y definición del proyecto. Luego ya se implementa.

El cliente nos hizo caso y fuimos por la segunda opción. Ya no hacemos proyectos del primer tipo. Ya no más.

El problema de la primera opción es arrancar un proyecto con prisas, partiendo de una sola reunión, un email explicativo o una lista de requisitos que provienen del cliente. Normalmente esta información siempre está incompleta y está realizada sin mucho análisis, o conocimiento de otras soluciones potenciales.

Son habituales las carencias en procesos y flujos del usuario, casos no contemplados, no incluir funcionalidad que "se da por entendida" y un largo etcétera, que a la larga se traduce en DOLOR.

Un apaño temporal sería pedirle al cliente una descripción más detallada de estos requisitos. Pero normalmente no es una buena solución ya que sin la guía, herramientas y metodologías adecuadas no es posible definir correctamente un aplicación. Aunque a veces hay clientes con experiencia que aciertan.

Una mala definición nos genera dos grandes problemas: por un lado errores en estimaciones (tiempo-esfuerzo) lo que generalmente termina en conflicto entre las partes debido a retrasos, modificaciones en presupuesto, etc..

Y por otro lado tenemos un problema más difícil de entender a priori: los requisitos planteados por un cliente suelen incorporar mucha funcionalidad que no es ni fundamental ni necesaria, lo que acarrea una complejidad y un coste adicional innecesario.

2) MVP: Keep it simple, sugar. O el síndrome de "no parar de pedir cosas"

Mi primera startup (favmonster) tuve que definir y hacer un MVP. Teníamos un programador, muchas ideas y poco tiempo. Sabía que tenía que recortar en funcionalidad para poder llegar a la presentación ante los inversores en la fecha señalada. Seleccioné solo las features esenciales y seguí adelante.

Lista de requisitos

Me pasé tres pueblos.

A pesar de haber leído decenas de veces que es un error típico y que todos-todos se arrepienten de haber construido algo demasiado grande. El programador estuvo una semana casi sin dormir para poder llegar a tiempo, y algunas features no funcionaban bien.

¿Adivinas por dónde voy? En el segundo MVP... me pasó exactamente lo mismo.

Este error es uno de los más habituales. Provoca que salgas al mercado muy tarde, con prisas, con un producto demasiado complejo y con muchas funcionalidad que luego realmente no van a usar los usuarios.

Y es peor cuando vas viendo que la aplicación avanza, porque la tendencia a centrarse en detalles triviales es muy grande, en vez de trabajar en lo importante.

En serio, el color del botón, si es cuadrado o redondo, o si está en la pantalla X o Y no es lo más importante ahora mismo. Mejor dejar al responsable de UX decidir, que para eso es el que sabe. El esfuerzo debería centrarse en que el MVP vaya a aportar valor real al usuario, a generar una comunidad, a pensar en la estrategia de tu empresa.

El problema, en síntesis, es lanzar un producto demasiado grande sin tener información del mercado y asumiendo muchas necesidades de los usuarios.

3) El milagro fullstack: creer que con un programador lo puedes hacer todo

Esta es buena también, te sonará. Entiendo que hay que optimizar la inversión en desarrollo, pero esto es demasiado. Me escribe un cliente potencial desde US el siguiente correo:

Hey Juan,

estamos buscando un perfil fullstack que sea experto en HTML, CSS, React.js y que en momentos también realizaría las tareas de SQL. Es un puesto muy atractivo ya que también tomaría las decisiones de UX y nos ayudará con el market fit.

El daily rate es de $500/day, pagado mensualmente.

Cheers!

Para lo que nosotros necesitamos 4 personas diferentes él lo quiere en una sola. El hombre-orquesta moderno, el santo grial, el programador fullstack.

No le culpo, cuando monté mi primer equipo (de 2 programadores) me frustré cuando me dijeron que tenían serias carencias para hacer HTML responsive. Que por qué no contratábamos a un experto en HTML/CSS.

"¿pero eso no lo podéis hacer vosotros? si total, es programar...". Perdonadme, estaba empezando.

Programador fullstack

La raíz de este problema suele ser cuando al arrancar un proyecto te planteas si hacerlo con un equipo in-house o contratando externamente (freelance, agencia...). Sin entrar en el debate de cuál es la mejor opción, al elegir la primera opción suele hacerse con algunas ideas erróneas. En muchas ocasiones hemos ayudado a clientes a contratar a su equipo técnico, y la creencia habitual es que contratando un CTO o un par de programadores fullstack es suficiente.

Nada más lejos de la realidad.

Dentro del proceso de creación de una aplicación hay diferentes fases muy diferenciadas, y como tal necesitan especialistas en esas tareas. A nosotros nos gusta diferenciar UX, diseño, maqueta, frontend y backend.

Es posible que puedas solapar algunas de esas fases pero totalmente imposible que un solo perfil se pueda encargar de todas, y menos haciéndolo bien.

En resumen donde un cliente quiere salir adelante con 1 o 2 programadores fullstack, nosotros empleamos a 4 personas diferentes, especializadas en su profesión y con un proceso perfectamente engrasado para encajar con el resto de fases.

4) Imponer una manera de trabajar

Recuerdo un proyecto... No, me equivoco.

Recuerdo el peor proyecto por el que hemos pasado. Un buen cliente, un proyecto muy chulo, con una gran perspectiva de crecimiento a largo plazo… pero tenía un red flag.

El cliente nos exigía adaptarnos a su manera de trabajar, integrados en su equipo y que nos fuésemos a sus oficinas durante el proyecto. Sé que es habitual en la industria gracias a las cárnicas, pero nosotros ya no lo hacemos más.

El resultado fueron problemas, retrasos, conflictos, problemas de jerarquía, fallos poco habituales, tensión, mal ambiente y un largo etcétera. Nos costó mucho hacer entender al cliente que no era una buena manera de trabajar, aunque se hiciera en otras empresas.

Desde que arrancamos con redradix uno de los aspectos vitales para nosotros es crear el mejor lugar de trabajo que fuéramos capaces, con una cultura que haga feliz a nuestros trabajadores y que nos permita rendir al máximo. Si no tenemos eso, no somos los mismos. Es la bandera bajo la que luchamos.

Creemos que es la mejor manera de atraer talento, de que la gente se sienta a gusto y de que rinda en su trabajo. Por "lugar" no solo nos referimos al espacio físico, que también, sino a todo lo que comporta el trato con nuestro equipo: independencia en su trabajo, flexibilidad de horarios, posibilidad de trabajo en remoto, no atosigar al programador con un "jefe de proyecto" respirando en su nuca cada 15 minutos, dotar al equipo de gente buena en lo profesional y lo personal...

Y todo esto completado con la parte física: oficinas amplias y con luz, mesas de trabajo grandes, buenos equipos, pantallas, etc. En definitiva un cantidad de detalles que hemos tenido en cuenta y que son el simple hecho de trabajar en "otro edificio" se desmorona por completo.

Y sin olvidar la metodología de trabajo. Nos va lo ágil.

5) Poco realismo en fechas y entregas o "lo quiero todo para ayer"

Sabemos que este punto es conflictivo y abre un debate interminable. Si tienes una fecha inamovible para salir a producción (campaña publicitaria, hito comercial, fecha especial, etc) no se hable más. Si tiene que estar listo en esa fecha, corremos.

Tenemos un deadline

Vamos a centrarnos en un caso diferente: no tienes una fecha específica y en base a otras razones se marca a fuego una fecha en el calendario.

Muchas veces el deadline de un proyecto es totalmente artificial. Está fabricado por el cliente sin una razón de peso detrás. Los proyectos de creación de un software son complejos, las estimaciones inexactas y los problemas e imprevistos son el pan de cada día. Hay que ser flexibles.

A menudo a medida que se avanza en el desarrollo se descubren nuevas funcionalidades importantes, otras dejan de serlo o el proyecto necesitas pequeños cambios de rumbo. Se necesita flexibilidad en las entregas y una metodología de desarrollo ágil que se adapte al cliente.

Si tu producto va a ser la base de tu negocio y la fuente de ingresos principal, retrasarse una semana por refinar una funcionalidad core no es relevante. Y puede que a mitad del desarrollo se descubra que una funcionalidad muy importante debe cambiar, lo que implica un cambio en la planificación.

Ya no sigo más. Espero que te haya gustado el post. Ah, ¡y si lo compartes nos haces un favor!.

Además, nos gustaría aprender también de tus errores. ¿Te has encontrado con otros problemas graves? Si quieres seguimos charlando en los comentarios :-)