Retomamos el post anterior de Cómo empezar un proyecto tecnológico I y ahora ahondaremos en la parte de los proveedores digitales.
LA PETICIÓN DE OFERTA
Ya tenéis clara la idea y habéis hecho vuestra lista de requisitos. En este momento es cuando tiráis de agenda y le preguntáis a vuestros contactos a quién conocen que desarrolle webs/apps y que sea Bueno, Barato y Rápido. Tengo malas noticias para vosotros, por lo general, de la terna BBR solo se cumplen las condiciones de dos en dos, a saber:
- Bueno y Barato
- Bueno y Rápido
- Barato y Rápido
Es importantísimo que este último concepto lo tengáis cristalino. Es muy raro que se den las tres a la vez y como recomendación, no es conveniente que os enamoréis de primeras de aquellas empresas que os prometan las tres condiciones juntas a no ser que tengáis pruebas de que efectivamente así funcionan.
En este momento es cuando empiezan los deberes de verdad. Todo proyecto requiere una definición previa del alcance y objetivos y es cuando hay que ponerse a trabajar. Cuanto más definido transmitáis vuestro proyecto, más exacto será el presupuesto que os den. Si los desarrolladores que encontréis son profesionales, os pedirán una consultoría inicial del proyecto donde esté detallada toda las funcionalidades e interacciones dentro de la web/app. Esto dicho de otras palabras es detallar el funcional del MVP (lista exhaustiva de requisitos y funciones) o el árbol de navegación e interacciones (para traducirlo al cristiano sería el “qué pasa si pincho aquí”) con el detalle de todas las acciones que suceden cuando se interactúa con la web/app, como podía ser: “se abre una pestaña”, “manda un mail de confirmación” o “genera un nuevo registro en la base de datos”, por mencionar algunos ejemplos.
También es muy recomendable hacer unos bocetos de cómo sería dicha interfaz y dónde va ubicado cada elemento que conformen vuestro producto digital en el caso de la Interfaz o qué cosas hay que tener en cuenta para el Backend (traducido al cristiano “las tripas de vuestro producto”). Si este trabajo está bien hecho se reducirán al mínimo las fricciones típicas de los proyectos y los malos entendidos ya que el desarrollador sabrá exactamente qué tiene que desarrollar y el cliente sabrá exactamente qué va a recibir. Otro tema complementario será si la UX y la UI del proyecto están bien definidas pero para curaros en salud os dejo más adelante otra recomendación. En cuanto a la decisión de quién debe efectuar este trabajo yo recomiendo que lo intentéis hacer vosotros mismos si sois el cliente o que insistáis a vuestros clientes que lo hagan si sois los desarrolladores. Este trabajo ayuda muchísimo a asentar los requisitos y funcionalidades del proyecto y cuanto más claros estén para ambas partes mucho mejor para evitar malos entendidos. Por otra parte el hecho de que el cliente desarrolle este trabajo como ejercicio previo a la petición de ofertas le dará perspectiva de la envergadura del proyecto y facilitará la gestión de expectativas. Es importante destacar también que, aunque nosotros como clientes nos esforcemos mucho en desarrollar esta primera etapa, es probable que debido a nuestra falta de experiencia podamos incurrir en errores o dejarla incompleta porque no hayamos tenido en cuenta aspectos técnicos por lo que recomiendo validar el trabajo con los desarrolladores antes de aceptar la oferta y comenzar el proyecto. Si tras la validación, los desarrolladores consideran que no es suficiente para desarrollar el proyecto, pedirles que os incluyan una partida de consultoría en el presupuesto y de este modo os curaréis en salud y seréis vosotros los que validéis su trabajo, evitando pasar al desarrollo hasta que la web/app esté a vuestro gusto.
EL PRECIO DE LA WEB, APP O HERRAMIENTA DIGITAL
El precio siempre es uno de los puntos importantes cuando estáis considerando vuestras propuestas económicas. Si, habéis leído bien, he dicho “uno de los puntos importantes” porque como comentábamos antes hay otros dos (recordad la terna “Bueno, Barato y Rápido”) que juegan al mismo nivel dependiendo de vuestras necesidades. Nuevamente, si los desarrolladores que encontréis son profesionales os ofrecerán las dos alternativas siguientes.
-
PROYECTO LLAVE EN MANO
Estos son los de toda la vida, con sus especificaciones, su presupuesto cerrado y sus entregables. Como seguramente habrá un documento de consultoría realizado (o por realizar al comienzo del proyecto), ambas partes sabrán lo que tienen que hacer, lo que tienen que entregar y lo que va a costar. Para llevarlo al símil de una casa, se hacen los planos y una vez aceptado el presupuesto se empieza a construir. El resultado deberá ser acorde a dichos planos. Posiblemente al final os pregunten de qué color queréis las paredes pero no se os permitirá cambiar una columna de sitio porque no os deja ver la tele. Parece un símil muy tonto pero las compañías serias no cambian el alcance una vez está firmado, a lo sumo pequeños detalles. En caso que se quieran modificaciones del alcance seguramente serán objeto de nuevas valoraciones económicas y llegado ese momento seremos totalmente vulnerables y quedaremos expuestos a variaciones sustanciales del presupuesto. El resultado de estas situaciones puede desembocar en fricciones entre cliente y desarrollador. Por este motivo, esta modalidad solo la recomiendo cuando el cliente tiene clarísimo lo que quiere, bien porque es continuación de un proyecto anterior o bien porque tiene la idea validada de alguna manera con los usuarios finales y sabe que va a funcionar. Por otra parte, recordad que es el cliente el que conoce verdaderamente a sus usuarios y que si hay dudas con la UX o la UI como os comentaba en el apartado de “Petición de Oferta” es mejor pasar a la siguiente modalidad.
-
METODOLOGÍAS ÁGILES
Aunque este será tema de otro post específico, os adelanto que se trata de una forma de trabajar en la que el proyecto se divide en sub-proyectos más pequeños en los cuales se establecen los requisitos de los mismos y un tiempo de ejecución. Al final de cada sub-proyecto se realiza una reunión donde se presenta el trabajo realizado y el cliente lo valida. Es en estos momentos donde podríamos darnos cuenta de que tal y como lo teníamos pensado no nos va a funcionar por lo que se pivota y se realiza un nuevo entregable para ser validado y pasar al hito siguiente. Esta forma de trabajar permite mucha más flexibilidad y en la gran mayoría de las ocasiones acaba con un final feliz, además el precio/hora en este tipo de proyectos suele ser menor que en los de llave en mano. Como desventaja presenta que no se tiene un precio exacto de lo que costará el proyecto, teniendo únicamente una aproximación para cada sub-proyecto en los que estarán especificadas las horas de trabajo para cada uno de ellos (con su correspondiente precio/hora) pero siendo susceptibles de aumentar debido a peticiones de cambios en los momentos de validación.
Esta es la segunda parte del post Espero que este post os sirva de ayuda a los que tengáis esa súper idea en mente. Más adelante publicaremos un post de “Cómo hacer el seguimiento de un proyecto digital” y otro de “Mantenimiento de un proyecto digital”.
Si algo no os ha quedado claro y os gustaría que ampliáramos alguna parte del post no dudéis en poneros en contacto con nosotros. Del mismo modo si en vuestro proyecto ya estáis en una fase posterior y necesitáis info de los dos post siguientes que os comentaba estamos a vuestra disposición para echaros una mano.
