5 preguntas que deberías facer antes de contratar calquera desenvolvemento web

Hai unha asimetría de información que complica moito as decisións de compra en desenvolvemento web. O cliente sabe o que quere conseguir. O provedor sabe como se fai. E no medio hai un espazo onde se producen a maioría dos malentendidos, os proxectos que non saen como se esperaba e as facturas que se disparan sen que ninguén entenda moi ben por que.

A forma máis efectiva de reducir esa asimetría non é converterse en experto técnico antes de pedir un orzamento. É facer as preguntas axeitadas. As que revelan como traballa realmente o provedor, que prioriza e que vai pasar cando as cousas non saian exactamente como estaban previstas.

Pregunta 1: de quen será o código cando remate o proxecto?

Esta pregunta parece obvia. A resposta non sempre o é.

Hai provedores que traballan con frameworks propietarios, con construtores visuais de licenza privada ou con compoñentes que son seus e que non se transfiren co proxecto. Neses casos, o cliente recibe unha web que funciona pero que non pode manter, modificar nin traspasar a outro desenvolvedor sen perder funcionalidades ou pagar licenzas adicionais.

A resposta que buscas é inequívoca: o código desenvolvido especificamente para o teu proxecto é teu. Podes levalo a outro provedor, podes modificalo, podes facer con el o que necesites. Sen condicións nin letra pequena.

Se a resposta inclúe matices do tipo «depende dos compoñentes» ou «hai partes que son da nosa plataforma», afonda antes de asinar. Eses matices poden converterse en dependencias custosas a longo prazo.

Pregunta 2: que documentación entregades co proxecto?

Un proxecto de desenvolvemento web sen documentación é un proxecto que só pode manter quen o construíu. Se ese provedor non está dispoñible no futuro (porque cambia de prezos, porque desaparece ou simplemente porque non conseguides coordinarvos), empezades practicamente de cero.

A documentación mínima que debería acompañar calquera proxecto serio inclúe: descrición da arquitectura do sistema, instrucións para o contorno de desenvolvemento, documentación das integracións e APIs empregadas, e unha guía para as tarefas de mantemento máis habituais.

Un provedor que non documenta non é necesariamente deshonesto. Pode ser simplemente que traballa rápido e sen procesos. Pero o resultado para o cliente é o mesmo: dependencia.

O que revela a resposta

Se o provedor responde con precisión («entregamos un documento de arquitectura, un README con instrucións do contorno e un manual de usuario para as funcionalidades a medida»), estás a falar con alguén que traballa con procesos. Se a resposta é vaga ou o tema parece incomodalo, é un sinal de que a documentación non forma parte habitual da súa forma de traballar.

Pregunta 3: como xestionades os cambios de alcance durante o proxecto?

En case todos os proxectos de desenvolvemento, o cliente pide algo que non estaba no briefing inicial. Non por falta de planificación, senón porque é imposible anticipar todos os detalles antes de ver como o proxecto vai tomando forma. A pregunta non é se vai ocorrer, senón como se xestiona cando ocorre.

Un provedor maduro ten un proceso definido: o cambio avalíase, orzaméntase e apróbase antes de executalo. Hai transparencia sobre o impacto en prazo e custo antes de que ninguén comece a traballar no novo.

Un provedor sen un proceso definido absorbe os cambios sen dicir nada ata que o proxecto remata e a factura final non se parece á inicial, ou vainos rexeitando un por un e xera tensión co cliente.

Ningunha das dúas situacións é boa. O que queres é un proceso claro acordado antes de empezar.

Pregunta 4: que inclúe o soporte despois da entrega e durante canto tempo?

O lanzamento non é o final do proxecto. É o momento no que o proxecto empeza a vivir en condicións reais, con tráfico real, con usuarios reais que fan cousas que ninguén anticipou nas probas.

Sempre aparece algo despois do lanzamento. Un comportamento inesperado nun dispositivo concreto. Un erro que só ocorre en certas condicións. Unha integración que falla con datos reais que non existían no contorno de probas. O que diferencia os provedores non é se isto ocorre, senón como responden cando ocorre.

Que deberías esperar

Un período mínimo de garantía despois do lanzamento (habitualmente entre 30 e 90 días) no que os erros atribuíbles ao desenvolvemento se corrixen sen custo adicional. E unha proposta clara do que pasa despois dese período: se hai un contrato de mantemento, con que tempos de resposta e a que custo.

Se o provedor non ten unha resposta clara a esta pregunta, estás a asumir un risco que non orzamentaches.

Pregunta 5: podedes amosarme un proxecto similar ao meu que xa entregastes?

Non un portfolio xenérico. Un proxecto concreto, cunha descrición honesta dos retos que tivo e de como se resolveron, e a poder ser coa posibilidade de falar co cliente dese proxecto se tes dúbidas.

Isto separa axiña os provedores que teñen experiencia real no tipo de proxecto que necesitas dos que teñen experiencia xeral pero nunca resolveron nada parecido ao teu.

Un provedor que fixo integracións con ERP pode amosar como o fixo, que problemas apareceron e que se aprendeu. Un que nunca o fixo pode presentalo como se fose sinxelo porque non sabe exactamente con que se vai atopar.

Como interpretar a resposta

A mellor resposta é un exemplo concreto con contexto real. A segunda mellor é a honestidade: «non fixemos exactamente isto, pero resolvemos problemas similares nestes proxectos e isto é o que aprendemos». O que non queres é unha resposta xenérica que esquiva a pregunta ou un portfolio de capturas de pantalla sen ningún contexto sobre como se construíu o que se ve.

Checklist: sinais dun provedor técnico maduro

• Responde a todas as preguntas anteriores con precisión e sen incomodidade.
• Fai preguntas antes de orzamentar, non despois.
• O orzamento detalla o alcance con precisión suficiente para saber exactamente que inclúe e que non.
• Propón un proceso de validación antes do lanzamento, non só unha entrega final.
• Ten referencias de clientes dispostos a falar da súa experiencia.
• É capaz de dicirche cando algo non ten sentido ou cando hai unha solución mellor ca a que pediches.

Preguntas frecuentes

É normal que o provedor non queira revelar detalles técnicos antes de asinar?

Ata certo punto, si. Ningún provedor vai compartir a súa metodoloxía completa antes de que haxa un acordo. Pero as 5 preguntas deste artigo non piden segredos técnicos: piden información sobre procesos, condicións contractuais e experiencia previa. Un provedor que se nega a responder estas preguntas antes de asinar está a poñer os seus intereses por riba dos teus desde o principio.

Que pasa se o provedor máis barato responde ben a todas as preguntas?

Que probablemente é unha boa opción. O prezo non é o único indicador de calidade, e hai provedores que traballan ben e cobran menos porque teñen estruturas de custo máis eficientes ou porque están nunha fase de crecemento na que priorizan construír carteira. As preguntas non están pensadas para eliminar os provedores económicos, senón para descartar os que non teñen procesos claros, sexa cal sexa o seu prezo.

Cal é o mellor momento para facer estas preguntas?

Antes de pedir o orzamento, se é posible. Moitas destas preguntas pódense facer na primeira conversa ou reunión exploratoria. Facelas nese momento ten 2 vantaxes: axúdache a decidir se paga a pena seguir adiante con ese provedor antes de investir máis tempo, e indícalle ao provedor que es un cliente que sabe o que pide, o que adoita traducirse nun trato máis profesional desde o principio.

Tamén che pode interesar: O custo real dunha web barata · Cando externalizar e cando contratar · Como saber se a túa axencia actual che está a servir ben

En Baqueiro respondemos a estas 5 preguntas antes de que as fagas, porque forman parte de como explicamos a nosa forma de traballar desde o primeiro contacto. Se tes un proxecto en mente e queres empezar con bo pé, falemos.