Contratar un proyecto de desarrollo de software a medida no debería significar simplemente pagar a una empresa de tecnología y esperar varios meses para descubrir qué recibiste.
Si eres empresario y estás evaluando desarrollar un sistema para mejorar la operación de tu empresa, probablemente tienes muchas preguntas: ¿cuánto va a costar? ¿cuánto tiempo va a tomar? ¿realmente funcionará como lo necesitamos? ¿qué pasa si durante el proyecto descubrimos que algo debe cambiar? ¿quién debe tomar las decisiones? ¿qué debería decir el contrato? ¿en qué momento debería realizar los pagos?
Y quizá la pregunta más importante:
¿Cómo puedo reducir el riesgo de invertir en un proyecto de software que después no cumpla con lo que mi empresa necesita?
Después de muchos años trabajando en proyectos de software, hay algo que considero fundamental: el éxito de un proyecto de desarrollo de software no depende solamente de la empresa que programa. También depende de cómo el cliente organiza, documenta y participa en el proyecto.
Por eso quiero compartir tres consejos que considero especialmente importantes para un empresario que está por contratar un proyecto de desarrollo de software a medida.
1. Debes tener un responsable del proyecto de tu lado
Este es probablemente uno de los consejos más importantes. Cuando una empresa contrata a una compañía de desarrollo de software, normalmente piensa que el proveedor tendrá un jefe de proyecto y, por lo tanto, el proyecto estará gestionado. Sí. Pero falta una parte.
También necesitas a alguien que represente a tu empresa.
No necesariamente tiene que ser un gerente de proyectos profesional ni un especialista en tecnología. Puede ser un gerente, jefe de área, administrador, responsable de operaciones o una persona de confianza que conozca bien el negocio. Lo importante es que tenga autoridad para coordinar con el proveedor y tomar determinadas decisiones.
¿Por qué es tan importante?
Porque una empresa de desarrollo de software puede conocer muy bien la tecnología, pero no necesariamente conoce tu negocio. La empresa de software puede saber cómo construir un CRM. Pero tú sabes cómo trabaja tu equipo comercial, cómo se aprueban las ventas, qué información necesitas para tomar decisiones, qué excepciones existen, qué clientes requieren condiciones especiales, qué procesos son realmente críticos y qué problemas tiene actualmente tu empresa.
Ese conocimiento está dentro de tu organización. Por eso, cuando se desarrolla software a medida, necesitamos que exista alguien capaz de traducir el conocimiento del negocio en decisiones para el proyecto.
PMI ha señalado que la definición de requisitos debe involucrar a los stakeholders relevantes y que estos deben estar alineados respecto del alcance del proyecto antes de comenzar a trabajar en los requisitos.
Imagina este escenario
Tu empresa quiere desarrollar un sistema para gestionar pedidos. La empresa de software pregunta: "¿Qué debe hacer el sistema?". El área comercial dice una cosa. El área de operaciones dice otra. Finanzas agrega nuevas condiciones. El gerente general pide un reporte adicional. Y después aparece el dueño diciendo: "Pero yo también necesito ver esto."
Si nadie está coordinando esas decisiones, el proyecto puede convertirse rápidamente en una colección de pedidos. Por eso recomiendo tener una persona que represente al cliente. No para decirle al proveedor cómo programar, sino para ayudar a responder preguntas como: ¿esto realmente lo necesitamos? ¿quién usará esta funcionalidad? ¿qué prioridad tiene? ¿quién debe aprobarla? ¿esto estaba contemplado? ¿este cambio afecta el alcance? ¿podemos dejarlo para una segunda etapa? ¿qué proceso de negocio estamos intentando resolver?
El responsable del cliente no reemplaza al jefe de proyecto del proveedor
Son responsabilidades diferentes. La empresa de desarrollo debería gestionar su ejecución técnica y su proyecto. Pero del lado del cliente debe existir alguien que pueda representar al negocio, facilitar información, coordinar usuarios, validar decisiones y aprobar entregables.
Esta participación no es una formalidad. PMI señala que los requisitos deben ser recopilados, definidos, documentados, priorizados, probados y controlados, y que la gestión de requisitos involucra también a los stakeholders y sus responsabilidades.
Mi recomendación
Antes de contratar un proyecto de desarrollo de software a medida, pregúntate: ¿quién será la persona que representa a mi empresa durante el proyecto? Si la respuesta es "no sé, veremos quién puede hacerlo", yo lo definiría antes de comenzar.
2. Documenta lo que realmente estás contratando
Este consejo parece obvio, pero en proyectos de software es donde muchas veces comienzan los problemas. He visto situaciones donde el cliente y el proveedor comienzan el proyecto teniendo una idea general de lo que quieren construir, pero no tienen suficientemente documentado qué significa exactamente terminar el proyecto.
Y aquí aparece una frase muy peligrosa: "Eso lo conversamos." Conversar es necesario, pero en un proyecto de software muchas de esas conversaciones deberían terminar convirtiéndose en documentación. ¿Por qué? Porque seis meses después nadie recuerda exactamente la misma conversación de la misma manera.
El software no se puede evaluar solamente diciendo "que funcione"
Supongamos que en el contrato dice: "Desarrollo de módulo de ventas." ¿Qué significa eso? ¿Incluye clientes? ¿Incluye productos? ¿Incluye cotizaciones? ¿Incluye aprobación? ¿Incluye descuentos? ¿Incluye impuestos? ¿Incluye impresión? ¿Incluye integración con el ERP? ¿Incluye reportes? ¿Incluye aplicación móvil? ¿Incluye notificaciones? ¿Incluye capacitación? ¿Incluye migración de información?
La frase "módulo de ventas" puede significar cosas completamente diferentes para dos personas. Por eso es tan importante documentar. IEEE explica que los requisitos de software constituyen la base sobre la cual se construyen posteriormente el diseño, la implementación y la validación del sistema, y señala la importancia de características como completitud, consistencia, trazabilidad y verificabilidad.
Qué deberías documentar en un proyecto de software
No existe un único documento que sirva para todos los proyectos. Dependiendo del tamaño y complejidad, puedes tener un contrato, un Statement of Work, una especificación de requisitos, prototipos, diagramas, historias de usuario, criterios de aceptación, cronograma y otros documentos. Pero como mínimo yo intentaría dejar claramente documentados estos elementos.
Alcance. ¿Qué se va a desarrollar? Y algo igualmente importante: ¿qué no se va a desarrollar? Esto último muchas veces se olvida. Los límites del proyecto son tan importantes como sus funcionalidades.
Requisitos. ¿Qué debe hacer el sistema? Los requisitos deberían describir de manera suficientemente clara las necesidades que la solución debe satisfacer. Pueden existir requisitos funcionales, de seguridad, de rendimiento, de integración, de disponibilidad, de usabilidad, de auditoría o de compatibilidad, entre otros. No necesitas convertir el proyecto de una pequeña empresa en un documento de 300 páginas, pero sí necesitas que las decisiones importantes estén suficientemente claras.
Procesos de negocio. Esta parte me parece especialmente importante para las empresas. Si estás desarrollando software para mejorar un proceso, no documentes solamente las pantallas: documenta también el proceso. Por ejemplo: solicitud → evaluación → aprobación → ejecución → facturación → cierre. Y luego pregunta: ¿quién realiza cada paso? ¿qué información necesita? ¿qué ocurre si se rechaza? ¿qué pasa si falta información? ¿qué excepciones existen? ¿qué reglas de negocio deben cumplirse? Porque un sistema no debería simplemente digitalizar pantallas: debería resolver un proceso de negocio.
Prototipos y diseños. Cuando sea útil, documenta también prototipos, wireframes, diseños de pantallas, diagramas de flujo, diagramas de procesos, modelos de datos, ejemplos de reportes y ejemplos de documentos. Una imagen puede evitar muchas discusiones. PMI incluso recomienda utilizar modelos o prototipos cuando sea necesario para que los usuarios puedan visualizar la solución y detectar inconsistencias o problemas antes de avanzar.
Y hay otro documento que no deberías subestimar: el contrato
El contrato no debería limitarse a decir: "La empresa desarrollará un sistema por X dólares." Para un proyecto de software a medida, debería existir suficiente claridad respecto de aspectos como alcance, entregables, responsabilidades, cronograma, hitos, pagos, criterios de aceptación, cambios, propiedad intelectual, soporte, mantenimiento, confidencialidad, dependencias del cliente y condiciones de cierre.
El American Bar Association recomienda revisar cuidadosamente el Statement of Work, porque allí normalmente se detallan los entregables, fases, cronograma, hitos, precios, responsabilidades, supuestos y otros términos relevantes del servicio tecnológico. Stanford utiliza una estructura similar en sus propios procesos de contratación: requisitos, hitos, tareas, cronograma, presupuesto, entregables, criterios de aceptación, exclusiones y responsabilidades forman parte de un SOW bien definido.
No significa que tengas que copiar un contrato universitario. Significa que existe una lógica bastante clara detrás de una buena documentación de proyecto.
3. No hagas el primer gran pago sin saber exactamente qué estás financiando
Este es un tema que puede resultar incómodo. Pero considero que un empresario debe hacerse esta pregunta antes de comenzar un proyecto de software: ¿por qué estoy haciendo este pago y qué entregable, hito o etapa estoy financiando?
No estoy diciendo que todos los proyectos de software deban tener exactamente el mismo esquema de pagos, ni que nunca deba existir un adelanto. Dependiendo del proyecto, del proveedor, del modelo de contratación y del esfuerzo inicial necesario, puede existir un pago inicial perfectamente razonable. El problema aparece cuando el cliente entrega una cantidad importante de dinero sin tener claramente definidos el alcance, los entregables, los hitos y las condiciones de aceptación. Ahí aumenta la incertidumbre para ambas partes.
El pago debería estar relacionado con el proyecto
Una estructura posible podría ser: inicio → análisis y definición; hito 1 → diseño/prototipo aprobado; hito 2 → primera versión funcional; hito 3 → funcionalidades principales; hito 4 → pruebas y correcciones; hito 5 → puesta en producción y cierre.
No estoy diciendo que esta sea la estructura correcta para todos los proyectos. Es solamente un ejemplo. Lo importante es que exista una relación razonable entre dinero → trabajo → entregable → aceptación. PMI identifica precisamente los pagos por hitos, las condiciones de aceptación y el control de cambios como elementos importantes en contratos de precio fijo. Stanford también establece en sus modelos de SOW que, cuando los pagos dependen de entregables, deben vincularse a hitos definidos y que deben especificarse tanto los criterios de finalización como quién revisará y aceptará los entregables.
Pagar por "avance" no es lo mismo que pagar por un resultado
Aquí hay una diferencia que considero importante. Un proveedor podría decir: "Ya hemos trabajado 300 horas." Pero la pregunta del cliente debería ser: "¿Qué entregable verificable corresponde a esas horas?" Porque en software podemos trabajar muchas horas sin necesariamente haber terminado algo que el cliente pueda utilizar.
Por eso, especialmente cuando hablamos de proyectos por etapas, es útil definir qué se entrega, cuándo se entrega, quién lo revisa, cómo se prueba, qué significa que esté terminado, qué ocurre si no cumple y cómo se corrigen las observaciones. En otras palabras: no solamente debes definir cuándo se paga; debes definir qué significa que el trabajo esté aceptado. PMI ha señalado que la aceptación debe basarse en criterios previamente definidos y que los entregables deberían poder verificarse contra esos criterios.
¿Y qué pasa si durante el proyecto quiero cambiar algo?
Esto también debe estar documentado, porque en prácticamente cualquier proyecto de software aparecerán cambios. A veces porque el cliente descubre una nueva necesidad, a veces porque el usuario encuentra un problema, a veces porque aparece una restricción técnica, a veces porque cambia el proceso de negocio.
El problema no es cambiar. El problema es cambiar sin controlar el cambio. Por ejemplo: "Ya que estamos haciendo el módulo de ventas, agreguemos también comisiones." Después: "Y sería bueno conectarlo con el ERP." Después: "También necesitamos una aplicación móvil." Después: "¿Podemos agregar inteligencia artificial?"
Cada cambio puede parecer pequeño, pero acumulados pueden transformar completamente el proyecto original. Por eso debe existir un mecanismo de control de cambios. PMI recomienda establecer procesos para comunicar, evaluar y aprobar cambios en los requisitos, junto con mecanismos de control documental y trazabilidad.
Un proyecto de software necesita dos equipos
Hay una idea que me parece muy importante para cualquier empresario. Cuando contratas una empresa de desarrollo de software, muchas veces piensas: "Ellos son los responsables del proyecto." En realidad, tienes dos equipos.
El equipo del proveedor, con sus desarrolladores, arquitectos, diseñadores, QA, especialistas, jefe de proyecto y analistas. Y el equipo del cliente, con sus usuarios, responsables de procesos, gerente, especialista del negocio, responsable del proyecto, personas que deben proporcionar información y personas que aprobarán los resultados.
El proyecto necesita que ambos lados funcionen. ISO/IEC/IEEE 12207 establece un marco para los procesos del ciclo de vida del software y contempla la adquisición, suministro, desarrollo, operación, mantenimiento y retiro de sistemas y servicios de software, incluyendo la participación de stakeholders. Además, es aplicable específicamente a sistemas de software personalizados.
Eso es importante porque un proyecto de software a medida no es simplemente "cliente compra software → proveedor programa". Es una relación de trabajo donde ambas partes tienen responsabilidades.
El cliente también puede hacer fracasar un proyecto de software
Esto puede sonar duro, pero es importante decirlo. A veces cuando un proyecto tecnológico sale mal, inmediatamente pensamos: "La empresa de software hizo un mal trabajo." Y puede ser cierto. Pero no siempre.
También puede ocurrir que nadie del cliente tome decisiones, que el cliente no entregue información, que los usuarios no participen, que los requisitos cambien constantemente, que no exista un responsable de aprobación, que los procesos internos no estén definidos, que las personas clave no tengan tiempo para revisar, que se incorporen funcionalidades continuamente o que el alcance nunca haya sido realmente acordado.
PMI identifica precisamente la necesidad de definir roles y responsabilidades de los stakeholders y de gestionar los requisitos de manera estructurada. Por eso, cuando una empresa contrata desarrollo de software, no está comprando solamente programación: está participando en un proyecto.
Cómo debería prepararse una empresa antes de contratar
Si yo fuera empresario y estuviera a punto de invertir en un proyecto importante de software a medida, antes de firmar preguntaría:
- ¿Cuál es el problema de negocio que quiero solucionar? No empieces por la tecnología. Empieza por el problema.
- ¿Quién será responsable del proyecto dentro de mi empresa? Define nombre y responsabilidades.
- ¿Cuál es el alcance? ¿Qué está incluido? Y especialmente: ¿qué está excluido?
- ¿Qué documentos describen la solución? Requisitos, procesos, prototipos, diseños, diagramas o cualquier otro documento que corresponda al proyecto.
- ¿Cuáles son los entregables? No solamente "desarrollo del sistema". Define qué recibirás.
- ¿Cómo sabremos que un entregable está terminado? Define criterios de aceptación.
- ¿Cómo se manejarán los cambios? ¿Qué ocurre si quieres agregar algo?
- ¿Cómo se realizarán los pagos? Relaciona, cuando corresponda, pagos con etapas, hitos o entregables claramente definidos.
- ¿Qué depende de mi empresa? Información, usuarios, acceso a sistemas, decisiones, pruebas, aprobaciones, infraestructura, etc.
- ¿Qué ocurre cuando el proyecto termina? Debes tener claro qué sucede con código, documentación, accesos, infraestructura, datos, propiedad intelectual, garantías, soporte y mantenimiento.
No necesitas saber programar para gestionar correctamente un proyecto de software
Este es otro punto que quiero dejar claro. Si eres empresario y estás pensando: "Yo no sé de programación, ¿cómo voy a controlar un proyecto de software?", no necesitas convertirte en programador. Necesitas entender qué debe entregar el proyecto y cómo comprobar que lo entregado responde a las necesidades de tu empresa.
Tu responsabilidad principal no es decir "usa Laravel", "utiliza PostgreSQL" o "hazlo en React". Eso corresponde al análisis y diseño técnico que deben realizar los especialistas, salvo que existan requisitos tecnológicos específicos de tu organización. Tu responsabilidad como empresario es mucho más importante: explicar qué necesita tu empresa, qué resultado esperas y participar en las decisiones que afectan al negocio. La tecnología debe estar al servicio de ese objetivo.
¿Y si todavía no tengo claro todo lo que necesito?
Entonces no intentes inventarlo todo antes de hablar con una empresa especializada. Esta también es una situación normal. Muchas empresas saben perfectamente cuál es su problema, pero no saben todavía cuál es la solución tecnológica.
Por ejemplo: "Mi equipo comercial pierde mucho tiempo preparando cotizaciones." Eso es un problema, pero todavía no es una especificación de software. A partir de ahí hay que analizar cómo se realiza actualmente el proceso, dónde se pierde tiempo, qué información utilizan, qué sistemas existen, qué tareas son repetitivas, qué reglas de negocio existen, qué se podría automatizar y qué debería seguir haciendo una persona. Y recién después podemos empezar a definir una solución.
Si quieres medir el costo actual de esos procesos manuales, puedes estimarlo con nuestra calculadora del costo de procesos manuales. Y si lo que necesitas hoy es emitir una cotización rápida, puedes hacerlo con el cotizador online gratis.
El objetivo no es tener un contrato lleno de páginas
Quiero hacer otra precisión. Documentar no significa llenar el proyecto de burocracia. Un proyecto pequeño no necesita necesariamente la misma documentación que un sistema empresarial complejo. La documentación debe ser proporcional al riesgo y a la complejidad.
Pero hay una diferencia enorme entre "no quiero burocracia" y "no quiero dejar por escrito lo que estamos acordando". La primera puede ser razonable. La segunda puede convertirse en un problema.
ISO/IEC/IEEE 12207 establece procesos de ciclo de vida aplicables a diferentes tipos de proyectos y enfoques, incluidos enfoques ágiles e iterativos, y no obliga a utilizar una única metodología de desarrollo. Por eso podemos trabajar de manera ágil y, al mismo tiempo, documentar las decisiones importantes. Agilidad no significa ausencia de documentación. Significa evitar documentación que no aporta valor y mantener suficientemente claro aquello que necesitamos gestionar.
Tres consejos que pueden ahorrarte muchos problemas
Si tuviera que resumir todo este artículo en tres recomendaciones para un empresario que está por contratar desarrollo de software a medida, serían estas:
- Ten un responsable de tu lado. Alguien que conozca el negocio, pueda tomar decisiones y coordine con el equipo de desarrollo.
- Documenta qué estás comprando. Alcance, procesos, requisitos, entregables, responsabilidades, criterios de aceptación, exclusiones y cambios.
- No pagues sin saber qué estás financiando. El esquema de pagos puede variar según el proyecto, pero debe existir claridad sobre qué trabajo, hito o entregable corresponde a cada pago.
El desarrollo de software a medida no debería ser un salto al vacío
Cuando una empresa decide desarrollar software personalizado, normalmente está realizando una inversión importante. No solamente de dinero, también de tiempo, personal, información, conocimiento del negocio, atención de los gerentes, participación de los usuarios y capacidad operativa.
Por eso considero que un buen proyecto de desarrollo de software a medida debe comenzar mucho antes de escribir la primera línea de código. Comienza entendiendo el problema. Continúa definiendo el alcance. Después se documentan los requisitos y procesos. Se establecen responsabilidades. Se acuerdan entregables y criterios de aceptación. Se define cómo se gestionarán los cambios. Y finalmente se establece una forma clara de avanzar y realizar los pagos. Después sí: a programar.
Porque desarrollar software no consiste simplemente en construir pantallas. Consiste en transformar una necesidad empresarial en una solución que pueda ser utilizada, validada y mantenida por la organización. Y mientras más importante sea la inversión, más importante es que ambas partes sepan exactamente qué están construyendo, quién debe hacer qué, qué se considera terminado y cómo se tomarán las decisiones durante el camino.
Ese es, para mí, uno de los principios más importantes cuando una empresa decide invertir en tecnología: no delegues completamente la gestión de tu proyecto de software solamente porque no eres una empresa tecnológica. Puedes contratar especialistas para construirlo, pero el proyecto sigue siendo tuyo.
Si tu empresa necesita modernizar procesos, integrar sistemas desconectados o automatizar tareas, también puede ser útil conocer nuestro servicio de transformación digital para empresas y el desarrollo de CRM a medida cuando el proceso a resolver es comercial.
Preguntas frecuentes
¿Quién debe liderar el proyecto del lado del cliente?
Una persona que conozca el negocio y tenga autoridad para tomar decisiones y coordinar con el proveedor. No necesita ser un especialista en tecnología, sino el puente entre lo que necesita la empresa y lo que construye el equipo de desarrollo.
¿Qué es un criterio de aceptación?
Es la condición que define cuándo un entregable se considera terminado y correcto. Debe definirse antes de desarrollarlo, de forma verificable, para saber si cumple con lo acordado.
¿Es normal pagar un adelanto en un proyecto de software?
Puede ser razonable si existe un esfuerzo inicial justificado y si el alcance, los entregables, los hitos y las condiciones de aceptación están claramente definidos. El problema no es el adelanto en sí, sino pagar sin claridad sobre qué se está financiando.
¿Necesito saber programar para gestionar un proyecto de software?
No. Necesitas entender qué debe entregar el proyecto y cómo comprobar que responde a las necesidades del negocio. Las decisiones técnicas corresponden a los especialistas, salvo que tu organización tenga requisitos tecnológicos específicos.
¿Qué pasa si quiero cambiar algo durante el proyecto?
Los cambios son normales. Lo importante es gestionarlos con un mecanismo de control de cambios: evaluar el impacto en alcance, tiempo y costo, y aprobarlos de forma explícita antes de ejecutarlos.
¿Cuánto cuesta desarrollar un software a medida?
Depende del alcance, la complejidad, las integraciones y los procesos a resolver. Por eso conviene definir primero el problema y el alcance, y luego pedir una propuesta. Un punto de partida habitual es un proyecto piloto para validar con bajo riesgo antes de una inversión mayor.
¿Estás pensando desarrollar un software a medida para tu empresa?
Si tienes un proceso que actualmente funciona con Excel, correos, WhatsApp, sistemas desconectados o procesos manuales, probablemente ya identificaste que existe una oportunidad de mejora.
La siguiente pregunta no debería ser solamente: "¿Cuánto cuesta desarrollar el sistema?" También deberías preguntarte: "¿Qué necesitamos definir para asegurarnos de que el sistema realmente resuelva el problema de nuestra empresa?"
En Blionsoft desarrollamos soluciones de software a medida para empresas, partiendo del problema de negocio, los procesos y las necesidades reales de la organización. Si estás evaluando un proyecto tecnológico, podemos ayudarte a convertir esa necesidad en un proyecto con un alcance, procesos, funcionalidades y etapas claramente definidos.
Porque antes de programar, hay algo mucho más importante: saber exactamente qué problema estamos tratando de resolver.
Referencias bibliográficas
- ISO/IEC/IEEE 12207 — Systems and software engineering — Software life cycle processes. ISO
- ISO/IEC/IEEE 16326 — Software life cycle processes — Project management. ISO
- Project Management Institute — Creating clear project requirements. PMI
- Project Management Institute — What a project manager really needs to know about requirements. PMI
- Project Management Institute — Framework for delivering higher quality Statements of Work for outsourced software development. PMI
- Stanford University — Statement of Work (SOW). Stanford
- American Bar Association — Seven Tips for Better Technology Services Agreements. ABA
- IEEE Technology Navigator — Software Requirements. IEEE
