¿Cuáles son algunos de los agujeros más comunes en los contratos de software?

Marcin Zabawa publicó recientemente un artículo sobre este tema en el blog STX Next. Es un experimentado jefe de prestación de servicios y creó una descripción detallada de los escollos más comunes. Vuelva a colocarlo a continuación para su placer de lectura.

5 agujeros en su contrato de outsourcing de desarrollo de software

Cuando selecciona profesionales de software para trabajar, desea que conozcan su juego. Habían pasado por decenas o cientos de proyectos anteriores, por lo que probablemente sean los que tengan una experiencia superior en la relación proveedor-cliente de software. Está fuera de su área de especialización y está a punto de enfrentar el primer desafío: firmar un contrato.

El proceso único de desarrollo de software y el vocabulario hermético ciertamente no ayudarán. También existe una buena posibilidad de que su asesor legal tenga poca o ninguna experiencia con contratos de TI y pueda pasar por alto riesgos y párrafos desfavorables. Si no tiene cuidado, puede enfrentar consecuencias que incluyen:

  • Los derechos de autor,
  • ritmo más lento de desarrollo de software,
  • incapacidad para cambiar efectivamente el contratista,
  • Perdió dinero y tiempo.

Si está a cargo de firmar el contrato, será su trabajo buscar cada hoyo que otros puedan perderse. Esta lista lo ayudará a detectar las trampas más comunes en los contratos de desarrollo de software.

1. Jurisdicción

El mercado de servicios de TI está globalizado. Es común (y rentable) utilizar los servicios de empresas extranjeras, subcontratando a lugares como Ucrania o Polonia. En una encuesta reciente realizada por Deloitte, el 72% de las empresas encuestadas estaban subcontratando su trabajo de TI, y el 31% busca aumentar la tercerización en el futuro. Cuando se le preguntó sobre algunas de las razones detrás de la decisión de subcontratación, el 59% citó la reducción de costos y el 57% quería centrarse más en el núcleo de su negocio.

Usar una mano de obra barata y calificada del extranjero es definitivamente una buena idea, pero siempre debe tener en cuenta las implicaciones. La piedra angular de su contrato con un proveedor extranjero es la jurisdicción a la que está sujeto.

Hay dos asuntos que deben considerarse aquí:

  1. Tribunal competente. El tribunal competente es el tribunal que escuchará cualquier reclamo que se presente en virtud del contrato.
  2. ley que rige. La ley aplicable determina qué ley nacional aplicará el tribunal.

Sorprendentemente, los dos no tienen que coincidir. Naturalmente, desea utilizar la ley y los tribunales de su país, pero para asegurarse de que usted y su proveedor deberán acordarlo expresamente en el contrato .

Sin embargo, hacer cumplir sus leyes y tribunales nacionales no siempre será posible. Aquí hay algunos consejos rápidos sobre cómo proceder cuando las negociaciones son difíciles y no se puede llegar a un compromiso sobre este asunto:

  • Trate de usar leyes extranjeras para ambas partes. Esto hará igualmente inconveniente para cada lado demandar al otro. Una opción común aquí es la ley británica, que se utiliza en muchos contratos internacionales.
  • Insista en su tribunal local, pero acepte aplicar la ley nacional de su contratista. Este es un compromiso justo, aún así puede hacer que las cosas se vuelvan desordenadas en caso de demanda.
  • Sugiera que el contratista contrate un bufete de abogados familiarizado con su legislación nacional para auditar el contrato y ofrezca compensar el costo.

2. Disponibilidad del personal

En el mundo de los servicios de desarrollo de software, generalmente hay 3 tipos de contratos:

  1. Contratos de precio fijo, que especifican con precisión el alcance del proyecto.
  2. Contratos de tiempo y materiales, que no fijan precio ni alcance.
  3. Contratos ágiles, que generalmente fijan el precio hasta cierto punto sin fijar el alcance.

El tipo de acuerdo más común entre las casas de software bien establecidas es el contrato de tiempo y materiales. Esto significa que se le facturará (generalmente cada mes) por las horas que su equipo contratado pasó trabajando en su proyecto.

Al firmar este tipo de acuerdo, generalmente se concentra en

  • tamaño y composición del equipo,
  • transparencia y control sobre las tareas realizadas,
  • El período de notificación en la terminación del contrato.

Lo que puede ser menos intuitivo es asegurarse de que el equipo que ha contratado seguirá estando disponible para usted. Debido a la gran demanda de sus servicios, las empresas de software enfrentan la tentación de redistribuir una parte del tiempo de los miembros de su equipo para acomodar a nuevos clientes o brindar soporte para un proyecto en peligro. Esto significa que no solo desea especificar el tamaño del equipo en el contrato, sino también poner algunos límites a la disponibilidad mínima de cada miembro.

Rotación del personal

Otro caso común entre las casas de software es rotar al personal con frecuencia entre proyectos. Esto se hace para utilizar a las mejores personas en la primera fase de cooperación y luego avanzar al siguiente compromiso.

Tales prácticas conllevan ciertas desventajas. Incluso si la persona que abandona su equipo será sustituida por alguien con la competencia técnica correspondiente, esto puede costarle tiempo adicional (y dinero) ya que la mayoría de los nuevos miembros del equipo necesitarán algo de tiempo para familiarizarse con la base del código, especialmente si no lo hace ‘ t mantener una documentación robusta.

Sin embargo, debe tener en cuenta que la rotación moderada dentro del equipo es normal y tiene un impacto positivo en el rendimiento . Esto se debe a la “naturaleza orientada al proyecto” de los profesionales, como los desarrolladores de software: se aburren muy rápido y su productividad tiende a disminuir después de unos meses de trabajar en un solo proyecto. Reemplazar parte del equipo y traer sangre fresca al equipo puede energizar a todos los involucrados. Recuerde regular el procedimiento de cambio de miembros del equipo para evitar rotaciones rápidas y frecuentes del personal.

3. Derechos de uso

Cuando contrata a un equipo para desarrollar software a medida, espera tener derechos exclusivos para usar todo lo que el equipo crea. Definitivamente, también desea tener el derecho para usted u otro contratista de modificar el software en caso de que decida cambiar de proveedor. Sin embargo, la parte difícil es la forma en que se lleva a cabo el desarrollo de software: en la mayoría de los casos, los desarrolladores usan bibliotecas y componentes que están destinados a ser reutilizables. Estas bibliotecas y componentes pueden ser propiedad de la casa de software o estar bajo licencia de código abierto.

Muchas casas de software tienen su propio conjunto de bibliotecas que han desarrollado de antemano y les gustaría utilizar al trabajar en su proyecto. Esto le brinda un gran valor, ya que le ahorra tiempo a su equipo y, por lo tanto, le ahorra dinero. Las bibliotecas reutilizables en la mayoría de los casos también son menos propensas a errores y errores. Sin embargo, si desea utilizarlos, no espere obtener derechos exclusivos sobre ellos. La casa de software preparará una lista de bibliotecas y le ofrecerá una licencia no exclusiva para usarlas.

Esto está perfectamente bien, siempre y cuando recuerde los conceptos básicos, como hacer que la licencia sea transferible o ilimitada por país y hora. También es extremadamente importante tener el derecho de modificar no solo el código sobre el que tiene todos los derechos, sino también las bibliotecas bajo la licencia.

Tenga cuidado con el código abierto y el ‘copyleft’

Es una práctica común aprovechar las herramientas, componentes y bibliotecas de código abierto al desarrollar software. La abundancia y la versatilidad de las soluciones de código abierto aportan un valor enorme y, en la realidad actual, no es práctico abstenerse de aprovecharlas. Aún así, la abundancia de código abierto viene con una gran cantidad de licencias, que siempre deben tenerse en cuenta.

Hay algunas licencias que no son adecuadas para uso comercial y su incorporación a su software puede generar problemas y costos legales. Aún más peligrosas son las licencias copyleft, que tienen un “efecto viral”. Cualquier trabajo derivado del trabajo con copyleft debe preservar los permisos de copyleft cuando se distribuye, convirtiendo efectivamente su software propietario en código abierto disponible para todos sin costo alguno.

Para mantenerse seguro, debe hacer que su contrato prohíba el uso de software de código abierto con la licencia copyleft. También es una buena práctica para el equipo de desarrollo usar código abierto de una manera que facilite separarlo completamente del resto de la base de código. El contrato debe aplicar esta forma de utilizar el código abierto.

4. Código objeto y código fuente

En virtud de un acuerdo de tiempo y material, puede esperar una demostración de software en funcionamiento cada dos semanas. Cuando paga la tarifa por otro mes de desarrollo, el software que se le presentó debe transferirse a usted.

Dependiendo de la tecnología utilizada en el proyecto, el software a veces puede tener la forma de código objeto, una aplicación que el usuario puede ejecutar. Usted, como usuario, estaría interesado en este formulario, sin embargo , siempre debe recordar insistir en obtener también el código fuente . La diferencia es que no puede analizar o modificar fácilmente el código de objeto, mientras que puede hacerlo con el código fuente.

Hay dos formas diferentes de transferir el código fuente. Muchos de ellos trabajan con repositorios en línea como Github. El contratista puede usar su cuenta para cargar el código fuente y luego compartirlo con usted. Esto es conveniente ya que no tiene que molestarse en administrar y pagar el repositorio, también tiene acceso instantáneo al código desarrollado por su equipo a diario. Al mismo tiempo, confiar en la cuenta del contratista significa que siempre puede desconectarte de sus repositorios. Por esta razón , siempre es mejor ser el propietario del repositorio o crear copias de seguridad periódicas del código desarrollado .

5. Documentación

No importa cuán pequeño sea el software, siempre es bueno tenerlo documentado. Hay 3 tipos de documentación que se pueden generar para el proyecto: documentación técnica, documentación del usuario y documentación del proyecto .

Documentación técnica

La documentación técnica es la más valiosa. Su objetivo es facilitar que los programadores entiendan cómo funciona el código. Es útil cuando un nuevo miembro se une al equipo o cuando decide cambiar el contratista.

La documentación técnica también tiene un impacto positivo en el trabajo del equipo, incluso si el equipo en sí no se modifica. Escribir código es una operación compleja y no es raro que un programador tenga dificultades para comprender su propio código después de 1-2 meses. Tener instrucciones legibles por humanos ayudará a depurar o desarrollar aún más el código en el futuro.

La documentación técnica viene en dos formas:

  • comentarios en línea dentro del código fuente
  • una base de conocimiento separada (almacenada en documentos pdf, wiki, Confluence y otros).

Deberías exigir ambos.

Documentación del usuario

La documentación del usuario es el manual diseñado para el usuario final para ayudarlo a aprender cómo usar el software. A menudo incluye capturas de pantalla y ejemplos de uso.

Si el software que está comprando se distribuirá entre un gran grupo de personas , siempre es importante tener documentación del usuario que pueda ahorrarle dinero en capacitaciones en vivo y más tarde en soporte . También debe tener en cuenta que el software actual tiende a ser complicado y no puede utilizarse de manera eficiente sin una preparación sustancial.

Documentación del proyecto

La documentación del proyecto se refiere a los materiales producidos para gestionar el trabajo durante el proyecto. Tener acceso a la documentación del proyecto es esencial para los contratos de tiempo y materiales porque proporciona transparencia. Usted está pagando por el tiempo utilizado y debe exigir una total transparencia sobre cómo se utiliza. Como el contratista no garantiza el resultado del trabajo, usted corre el riesgo de fallar en el proyecto. Es usted quien debe monitorear la situación y tomar decisiones.

La documentación del proyecto puede proporcionar datos para ayudarlo. Viene en varias formas, como:

  • tarjetas de proyecto,
  • Entradas JIRA,
  • registros de tiempo,
  • gráficos de burndown,
  • estadísticas de velocidad.

Al firmar un contrato, siempre debe asegurarse de que el equipo que contrate estará obligado a producir y mantener continuamente la documentación de diferentes tipos. La documentación técnica y del usuario debe ser transferida a usted tan a menudo como el código fuente, y la documentación del proyecto debe estar accesible para usted en todo momento.

Si va a utilizar herramientas en línea para documentación como JIRA o Confluence, asegúrese de poseer la cuenta especificada en el contrato para que el contratista no pueda quitarle su contenido.

El valor de un contrato bien preparado

Espero que esta lista lo ayude a navegar en las negociaciones del contrato. Un contrato por sí solo no puede garantizar una cooperación fluida y efectiva con la casa de software, pero será una gran protección en caso de que lleguen tiempos difíciles . Conocer los trucos detrás de los contratos de TI también lo ayudará a juzgar la honestidad de su futuro socio justo al comienzo de la cooperación.

Definitivamente vale la pena dedicar más tiempo para establecer bien la cooperación: los beneficios de la subcontratación de desarrollo de software pueden ser enormes. No solo puede reducir el costo general y ahorrarle la carga de agregar un departamento adicional a su organización, sino que también tiende a producir una mejor calidad de trabajo y le brinda más flexibilidad si las condiciones comerciales cambian durante el proceso.

La lista anterior consta de algunos de los casos más interesantes, pero no agota todos los elementos que debe considerar, como las sanciones contractuales o la distinción entre demoras culpables y no culpables . Afortunadamente, estas áreas probablemente serán conocidas por su asesor legal.