Qué poner en una RFP de desarrollo de software (y las 5 cláusulas que te protegen)

Una solicitud de propuesta (RFP) de desarrollo de software es el documento que les dice a los proveedores qué necesita construir, por qué y cómo se juzgarán sus ofertas. Uno bueno contiene cinco cosas: el problema y los objetivos del negocio (no una lista de características deseadas), las limitaciones conocidas (rango de presupuesto, plazos, sistemas existentes, cumplimiento), un alcance claro con lo que entra y sale, los criterios de evaluación con los que realmente calificará y los términos contractuales que regirán el trabajo. La última parte es la que más importa y es la que la mayoría de las RFP dejan en blanco. Cinco cláusulas lo protegen: propiedad de la propiedad intelectual, criterios de aceptación, entrega y documentación, control de cambios y soporte posterior al lanzamiento. Inclúyalos en la RFP en sí, no en el contrato que negocie después de haber elegido, y mantendrá sus opciones abiertas mientras las tenga.

¿Qué contiene una buena RFP de desarrollo de software?

La estructura es sencilla. La disciplina consiste en centrarse en los resultados, no en las soluciones.

1. El problema y el objetivo. Describe lo que está roto o falta y cómo se ve el éxito en términos sencillos. Un buen vendedor propone la construcción; usted describe el resultado. Si especifica la solución en detalle, solo sabrá si pueden seguir las instrucciones.
2. Restricciones y contexto. Rango de presupuesto, cronograma, los sistemas con los que debe integrarse, los datos que tocará y cualquier obligación regulatoria. Ocultar el presupuesto hace perder el tiempo a todos y produce ofertas que no se pueden comparar.
3. Alcance, explícito en ambos lados. Enumere lo que está dentro y, lo que es igualmente importante, lo que está fuera. La mayoría de las disputas comienzan en la brecha entre lo que una parte supuso que estaba incluida y la otra no.
4. Criterios de evaluación. Indique cómo calificará las propuestas: experiencia relevante, enfoque técnico, equipo, precio y los términos a continuación. Los vendedores escriben según lo que midas.
5. Las cláusulas protectoras. Las cinco siguientes. Incluirlos en la RFP, no en el contrato posterior, es lo más importante que separa a un comprador que mantiene el control de otro que no.

Este es también el documento donde ya debería estar resuelta la decisión construir vs comprar software. Una RFP es para una construcción. Si todavía tienes peso, resuélvelo primero.

¿Qué 5 cláusulas te protegen en una RFP de software?

Estos son los términos que deciden quién tiene el poder cuando el proyecto esté terminado. Pídalos por adelantado, mientras varios proveedores todavía quieren el trabajo.

Cláusula	Lo que asegura	¿Qué sale mal sin él?
Propiedad de propiedad intelectual	Eres propietario del código fuente, los activos y el derecho a modificarlos	El proveedor es propietario del código y usted le otorga la licencia de su propio sistema
Criterios de aceptación	Una prueba objetiva de "hecho" antes del pago final	Discusión interminable sobre si el trabajo cumple con las especificaciones
Entrega y documentación	Código, credenciales y documentos que permiten que otro equipo se haga cargo	Estás encerrado porque sólo ellos entienden cómo funciona
Control de cambios	Un proceso y una tasa acordados para los cambios en el alcance	Facturas sorpresa o negativa a ajustarlas según aprendes
Soporte y mantenimiento	Tiempos de respuesta y costos definidos después del lanzamiento	Un sistema vivo sin que nadie esté obligado a arreglarlo

¿Por qué la propiedad de la propiedad intelectual pertenece a la RFP y no al contrato?

Porque el equilibrio de poder cambia en el momento en que eliges un proveedor. Antes de firmar, tienes varios interesados ​​y una comparativa limpia. Después de firmar, tiene un proveedor y un sistema a medio construir que no puede mover fácilmente. Una cláusula que no cuesta nada acordar en la primera semana puede costar una renegociación, o una reconstrucción, en el sexto mes.

La propiedad de la propiedad intelectual es el ejemplo más claro. Indique claramente que todo el código fuente, los recursos de diseño y los materiales relacionados pasan a ser de su propiedad previo pago, sin que se requiera una licencia residual para ejecutarlos o cambiarlos. Las empresas de renombre lo aceptan sin fricciones. Un proveedor que se resiste porque quiere conservar su código le está diciendo algo útil antes de que haya gastado nada.

La aceptación es la segunda cláusula que la gente lamenta haber omitido. Defina lo que significa "terminado" como una prueba que el sistema pasa o falla, acordada de antemano. Sin él, el último diez por ciento de un proyecto se convierte en una negociación en lugar de una entrega, y su pago final es la única palanca que queda para forzar su finalización.

¿Cómo le mantienen el control el traspaso, el control de cambios y el soporte?

Estos tres deciden si usted es propietario de un sistema o simplemente alquila el acceso a las personas que lo construyeron.

La transferencia es la propiedad hecha realidad. El contrato debe requerir un código fuente funcional en un repositorio que usted controle, instrucciones de implementación, configuración del entorno, credenciales y documentación lo suficientemente buena para que un equipo competente que nunca haya visto el proyecto lo ejecute y amplíe. Pídalo como un entregable con su propio paso de aceptación, no como una cortesía al final. Si el traspaso es vago, usted está encerrado sin importar lo que diga la cláusula de propiedad intelectual, porque en la práctica nadie más puede tocar el sistema.

El control de cambios protege a ambas partes. Tus necesidades cambiarán durante la construcción; eso es normal. Lo que desea es una forma acordada de manejarlo: cómo se solicita un cambio, cómo se cotiza y a qué tarifa. El objetivo no es impedir el cambio sino quitarle la sorpresa, de modo que un nuevo requisito se convierta en una pequeña conversación predecible en lugar de una disputa.

Soporte y mantenimiento es la cláusula para el día después del lanzamiento, que es cuando el software realmente comienza a funcionar. Define qué pasa cuando algo se rompe: tiempos de respuesta, quién es el responsable, cuánto cuesta y por cuánto tiempo. Un sistema activo sin obligación de mantenimiento es un pasivo a la espera de su primer incidente. Aquí también es donde aparece la diferencia entre comprar un consejo y comprar un resultado. Un socio que sigue siendo responsable una vez que el sistema está en producción es una propuesta diferente de uno que desaparece en el momento de la entrega.

La conclusión práctica

Trate la RFP como el lugar donde establece los términos, no solo como el lugar donde describe el trabajo. Acordar las cinco cláusulas (propiedad de propiedad intelectual, aceptación, traspaso, control de cambios y soporte) cuesta casi nada mientras los proveedores siguen compitiendo y hay mucho que agregar una vez que se ha elegido una. Escríbalos con anticipación, califique las propuestas en función de ellos y mantendrá el control del sistema por el que está pagando. Si desea un segundo par de ojos sobre un informe antes de que se publique, díganos qué está creando; es el tipo de definición de alcance con el que de todos modos comienza nuestro trabajo de software personalizado.