Consejos para saber si aceptar o no un nuevo proyecto Drupal

Después de 14 años haciendo proyectos web y móvil para clientes en distintas industrias (muchos en Drupal, otros no) uno mira hacia atrás y puede darse cuenta que al menos un 20% de los clientes o proyectos realizados no los hubiera vuelto a ejecutar. Digo 20% para que no me corten la cabeza en mi empresa ;)

Han sido experiencias malas para el cliente y experiencias malas para tu compañía o para ti en particular. Eso cuando no pierdes salud o hasta la camisa en un proyecto de desarrollo. Quién trabaje en el mundo del desarrollo de proyectos web y mobile sabrá lo que le digo. Muchas veces el ansia de vender, la necesidad de dar trabajo a tus equipos, el tan aclamado “esto es un proyecto estratégico”, nos hace entrar en algunos proyectos que desde el minuto uno están condenados al fracaso.

Gracias a Dios, no pasa siempre y por eso seguimos vivos y haciéndonos mayores :) También es verdad que el responsable muchas veces no es el cliente, nadie te obliga a aceptar el proyecto.

En este contexto, os cuento algunas de las pistas que a día de hoy nos hacen declinar la entrada en algunos proyectos de desarrollo. Voy a personalizarlo con Drupal, donde se hace a veces incluso más evidente.

Alcance claro o presupuesto aproximado: En muchas ocasiones nos llegan clientes pidiendo un presupuesto y un análisis de algo que ni ellos tienen claro y donde, además, se cierran en banda a la hora de darte un presupuesto. “Para eso te escribo, lo que cuesta me lo tienes que decir tú”.

Después de 2 semanas de trabajo y dedicación de varios componentes de tu equipo, donde prácticamente escribes los requisitos, resulta que el presupuesto que tenía en la cabeza no da casi ni para pagar la propuesta que has hecho. Nos hemos encontrado diferencias de hasta de 10 órdenes de magnitud. Para hacer una propuesta sólida, es necesario tener o mucha y muy clara información de requisitos o bien del presupuesto disponible (cualquier directivo o manager serio sabe cuánto se puede gastar).

Por favor, estimado cliente, necesito una de las dos opciones para darle un buen servicio:

• Requisitos claros tanto técnicos, como funcionales y nosotros nos encargaremos de darle el equipo, planificación y precio acorde (ya con los riesgos que queramos asumir).

• Si no, un presupuesto aproximado de inversión o gasto y en base a requisitos de más alto nivel, podemos ofrecer una solución acorde y realista.

El análisis o diseño es trabajo que supera el alcance de una propuesta y que creemos que hay que facturar por el. Además hay que hacerlo con el cliente absolutamente involucrado para que tenga valor.

Drupal no es suficiente

Por muy bueno que puedas ser en Drupal, en el mundo actual y para cumplir objetivos digitales hacen falta otros perfiles para llevar un proyecto de desarrollo in-house al éxito. De hecho, si tu equipo Drupal de Backend es bueno, con las historias de usuario claras y con el UX/UI validado, el backend en Drupal 8 es rápido y efectivo. Pero necesitas más:

• Estrategia/Analítica: El equipo que se encarga de fijar los objetivos digitales y que estén impregnados en todas las capas del proyectos además de KPIs claros que el cliente luego pueda medir.

• Product Owner: La persona responsable del producto, del acabado, de los objetivos, de la coherencia.

• UX/UI: Clave a nivel de orientación a objetivos de conversión, entendimiento del target, adaptación a móviles, etc. Siempre en comunicación con los equipos de Backend (UX) y Frontend Drupal (UI) para ser realistas, para ser eficientes.

• SEO: Al menos un paquete básico, si luego tu estrategia es la adquisición que menos que un SEO durante todo el ciclo de vida y generando los planes y guías necesarias teniendo en cuenta todos los stakeholder del proyecto.

• QA: Aquí nosotros tenemos obsesión, lo pague o no el cliente, nuestra metodología Agile QA en proyectos Drupal es clave diferencial de nuestros proyectos, sobretodo en los más ambiciosos.

Podemos hablar de más perfiles para casos concretos pero creo que estos son indispensables en un proyecto digital junto con los expertos Drupal de back y front, donde tenemos un equipo excelente pero que no puede ocuparse de todo.

Hay muchas posiciones del cliente en las que hay que entrar a evangelizar, y si no es posible, quizás es mejor dejarlo...

“Yo no pago por gestión, yo quiero desarrolladores”: No lo llamaría gestión, lo llamaría preocupación por los objetivos digitales del proyecto y por tanto del producto digital final. Para nosotros es clave que si esta figura no la puede asumir el cliente (pasa muy pocas veces), exista dentro del proyecto por nuestra parte como figura clave.

“Un QA para qué, ¿Me lo tenéis que entregar bien hecho no?”: Aquí solemos evangelizar también porque tenemos muchas herramientas y conocimiento, también en automatización. Es importante que el cliente sea consciente desde el minuto uno que existirán bugs seguro, el objetivo es que sean los mínimos y que haya una estrategia robusta de resolución.

”Yo no quiero UX, yo te paso el diseño y ya tengo los prototipos en mi cuaderno”: No hablamos el mismo idioma, es necesario que se entienda que el ejercicio de UX y, posteriormente, su implementación gráfica va mucho más allá.

“A mi el SEO me da igual”: A nosotros no porque es un proyecto con nuestra firma. Hacen falta una serie de actividades, aunque sean mínimas, para al menos no hacer el ridículo en Google.

Puede que entrar así sea un modelo óptimo para otras empresas y otro tipo de proyecto. La experiencia nos dice que esto no suele salir bien o que el resultado al final no te permite ni siquiera referenciar lo que has hecho. ¿Merece la pena? Como ya os decía antes, nosotros muchas veces hemos entrado en estas condiciones, el negocio es el negocio, pero también muchas de esas veces nos hemos arrepentido.

No entres en mantener u optimizar desarrollos de otros sin estar seguro

Es muy complicado entrar en un cliente a llevar su ecosistema digital desde cero. En muchas ocasiones necesitas desarrollar un nuevo site en Drupal pero mantener a la vez otro. Cuidado con esto porque muchas veces se estropean las relaciones en los proyectos de mantenimiento.

Un fallo que solemos cometer los proveedores cuando llegamos a un cliente es decir: “El Drupal que tienen es una mierda, hay que rehacerlo todo”. Nuestra experiencia nos dice que el próximo que venga detrás nuestra dirá lo mismo y el cliente ya está cansado de esto. Vamos a darle a nuestro cliente desde el principio información real, un estudio fidedigno de lo malo y lo bueno que tiene su sitio y, por tanto, lo complicado o no que será resolver problemas o hacer evolutivos en el mantenimiento.

• ¿Sigue los estándares y buenas prácticas de desarrollo Drupal?

• ¿Está la arquitectura bien montada?¿Política de entornos?

• ¿Dificultad para security updates, o upgrades de módulos? ¿Se ha “tocado core”?

• ¿Estado de la documentación?

• ¿Calidad de código?

Con esto, genera un informe de auditoría de valor y no de sensaciones, que aunque sea a coste, seguro que acerca mucho más las posiciones y hace todo más entendible de cara a un mantenimiento futuro. Si el cliente no entiende que debe abonar una pequeña cantidad por esto, quizás sea una señal. Si lo hace, las expectativas con el mantenimiento estarán luego mucho más cercanas. Ten en cuenta que si para una actualización hay que rehacer el portal, es mejor saberlo de antemano :)

El soporte y mantenimiento no es garantía

Es completamente entendible que los defectos software de tu proyecto se solucionen sin coste durante cierto tiempo: 6 meses, 1 año. Es algo que hay que cerrar previo contrato y creo que es sano para ambas partes. En La Drupalera, intentamos que sea mínimo pero como decía antes, siempre aparecen bugs. Otro tema más importante aún es el servicio de mantenimiento y soporte, por el que no solo se pagan las horas de actividad, sea para un defecto software, para una consulta o para monitorizar algo; sino que se ofrece una disponibilidad, un tiempo de respuesta, una infraestructura garantizada de entornos.

Es importante que se tenga en cuenta que el garantizar que un técnico esté disponible, aunque sea en 8x5 para resolver algo, es algo que cuesta esfuerzo y dinero al proveedor y por tanto es lógico que se intenta cobrar por ello. En muchas ocasiones nos encontramos con gestos de sorpresa. El mantenimiento es clave para las relaciones a largo plazo no solo por la parte técnica, sino para optimizar el producto digital y obtener y mejorar objetivos.

De la misma forma, es cierto que tiene un coste y por tanto es bueno ser transparentes desde el inicio de un proyecto de desarrollo con los modelos de mantenimiento planteados. Nuestra visión es que un producto digital necesita un servicio de mantenimiento proactivo, orientado a resultados, flexible, disponible y eficiente y por tanto bajo distintas modalidades hay que cobrar por dicho servicio. Ese modelo no es equiparable a un servicio de garantía y por tanto las expectativas no pueden ser las mismas.

Sobre el papel, mi visión es que si haces proyectos digitales, necesitas clientes que entiendan digital y que si no, te dejen hacer a ti como compañía que contratan para ello, pero desde fase de oferta y estimación. Hay que intentar entrar en un proyecto con las expectativas de relación, servicio y producto lo más cercanas posibles, será garantía de éxito. Esto te hará crecer a ti como empresa y a ellos generando valor a largo plazo, relaciones estables y casos de éxito.