Las reglas del juego: Cómo trabajamos (y cobramos) las horas en Elemental Lab

Cuando contratas a un sastre para hacerte un traje a medida, él toma las medidas, corta la tela y te lo pruebas.
Seguramente, en esa primera prueba, la manga te quede un centímetro larga o el pecho un poco ajustado. El sastre coge los alfileres, ajusta y vuelve a coser.
Ese tiempo de ajuste no es un "error" del sastre. Es parte del proceso de hacer un traje a medida.

Con el desarrollo de software pasa exactamente lo mismo.

El software perfecto a la primera no existe. Es ciencia ficción.
Desarrollar tecnología es un proceso complejo, vivo e iterativo. Encontrar bugs (errores) o comportamientos imprevistos es la naturaleza misma de la programación.

Por eso, queremos ser brutalmente transparentes sobre cómo funciona nuestra modalidad de trabajo por Tiempo y Materiales (Bolsa de Horas).
Cuentas claras conservan clientes rentables.

1. ¿Qué horas te vamos a cobrar? (Y por qué es lo justo)

El tiempo que nuestro equipo invierte en detectar, analizar y corregir errores durante el desarrollo activo, es tiempo de trabajo efectivo. Y se factura.

Te cobramos horas en escenarios como estos:

  • La "Prueba del Sastre" (Depuración Estándar): El ciclo normal de "escribir código, probarlo, romperlo y arreglarlo" hasta que la funcionalidad hace exactamente lo que pediste.

  • Sorpresas de terceros (Casos Extremos): Cuando una pasarela de pago cambia sus reglas, cuando un servidor ajeno no responde o cuando hay un conflicto con tecnología que no controlamos.

  • Las Pruebas Finales (UAT): Los ajustes que nos pides cuando estás probando el sistema para que todo quede afinado según el documento inicial.

  • Zonas Grises: Tiempo extra invertido porque un requerimiento inicial que nos pasaste era ambiguo o le faltaba detalle.

2. ¿Qué horas NO te vamos a cobrar? (Nuestra responsabilidad)

Somos profesionales y asumimos nuestros errores. No te facturaremos ni un minuto si pasa esto:

  • Negligencia: Si te pedimos hacer un botón rojo que diga "Comprar" y el desarrollador hace un botón verde que dice "Borrar sistema". Eso lo pagamos nosotros.

  • Romper lo que ya funcionaba (Regresiones): Si implementamos algo nuevo hoy y, por descuido nuestro, rompemos el carrito de compras que llevaba un mes funcionando perfecto.

  • Arreglos "fantasma": Si te decimos "esto ya está solucionado" y a los dos días vuelve a fallar exactamente por el mismo motivo. Ese segundo arreglo va por nuestra cuenta.

3. El error vs. "Se me ocurrió una idea mejor"

Esto es vital.
Si a mitad del proyecto decides que ya no quieres que el cliente pague con tarjeta, sino con transferencia bancaria, o que el diseño ya no te gusta y lo quieres cambiar... eso no es un "Bug".

Eso es un Cambio de Alcance.
Todo cambio sobre la marcha por estrategia, gusto o capricho, es 100% facturable a tu bolsa de horas.

 


 

El Ensayo General: Las Pruebas de Usuario (UAT)

Imagina que contratas a un arquitecto para construir tu casa.
Antes de entregar las llaves, te invita a recorrerla. Es tu momento para abrir los grifos, prender las luces y comprobar que las puertas cierran bien. Si no dices nada y te mudas, no puedes quejarte un mes después de que el baño de visitas no tiene puerta.

En software, a ese recorrido le llamamos Pruebas de Aceptación de Usuario (UAT).
Es el momento en que dejas de ser un observador y te conviertes en el auditor de tu propio sistema.

Es tu responsabilidad ensayar la tecnología con datos reales de tu operación. Y funciona así:

  • Tu ventana de tiempo: Cuando te entregamos un módulo, tienes 10 días hábiles para probarlo y reportar todo lo que encuentres. En esos 10 días, nuestro equipo está a tu entera disposición.

  • Lo que entra: Si hay un error que contradice lo que acordamos inicialmente (un fallo técnico real), lo priorizamos y lo reparamos dentro de tus horas.

  • Lo que cuenta como extra: Si durante las pruebas nos dices "¿podemos poner este botón más grande?" o "¿qué tal si le agregamos este paso al formulario?". Eso es una mejora, y como toda mejora, consume horas.

Cuidado con el silencio.
Si pasan 5 días hábiles y no hemos recibido ningún reporte de errores, o si decides empezar a usar el software para vender y operar con clientes reales... el sistema se da por Aceptado y Aprobado.

La Garantía de 30 Días (Y lo que no cubre)

Cuando el proyecto está terminado y aprobado, Elemental Lab te da 30 días calendario de garantía.

¿Para qué sirve?
Para "Vicios Ocultos". Esos errores que eran humanamente imposibles de detectar en tus pruebas (por ejemplo, que el sistema se sature cuando entran 5.000 clientes al mismo tiempo). Eso lo arreglamos gratis.

¿Para qué NO sirve?
Para "Vicios Aparentes". Si el menú de navegación estaba descuadrado y no nos dijiste nada en tu ventana de pruebas, significa que lo aceptaste así. Pedir que lo arreglemos un mes después, requiere cotizar horas.

(Nota: Esta garantía se esfuma automáticamente si un ingeniero externo a nuestro equipo le mete la mano al código o al servidor).

Nuestras reglas son claras para que la tecnología trabaje para ti, y no al revés.

Share Share Share