Ir al contenido

hecho a medida

Desarrollo de software a medida para empresas de Estados Unidos

La ingeniería es la misma esté donde esté. Sustituimos la hoja de cálculo y el fichero Access por un servicio con esquema, migraciones y registro de auditoría. Lo que cambia con un cliente estadounidense es el papeleo y el reloj, así que ambos van por escrito antes de empezar.

Pedir presupuestoUn formulario de cinco campos. Lo que vuelve es un alcance, un precio y una fecha para la auditoría.

USA

El marco contractual es un MSA con un statement of work por fase. La ley aplicable, la moneda de facturación y la cesión de propiedad intelectual las fija usted, y el solape con su horario entra en el SOW como un número de horas y no como una promesa en una web. Trabajamos con husos horarios de Estados Unidos todos los días, y la reunión diaria cae dentro de su mañana y no al final de ella.

18 días hasta la primera versión que funciona


El shadow IT está tachado porque no se porta. En cuanto el proceso tiene dueño y registro, las copias privadas dejan de merecer mantenimiento.

Hojas de cálculo

Excel, un fichero Access y una conciliación que alguien hace a mano cada mañana.

  • spreadsheet + emailExcel · Outlook
  • access.mdbAccess
  • manual reconciliationpeople
  • shadow ITunowned

Un servicio

Un servicio de dominio, un cliente web, un esquema con migraciones, un registro que solo añade.

  • domain serviceGo
  • web clientTypeScript
  • postgresschema + migrations
  • audit logappend-only

18 días hasta la primera versión que funciona

El shadow IT está tachado porque no se porta. En cuanto el proceso tiene dueño y registro, las copias privadas dejan de merecer mantenimiento.

Cómo va el trabajo

El primer día se dedica a mirar cómo se trabaja, no a especificarlo. Los documentos de requisitos describen el proceso que alguien desearía que existiese.
  1. 01días 1–2

    Ver cómo se hace el trabajo

    Nos sentamos con quien lo hace y leemos las fórmulas de su hoja. Las excepciones que resuelven sin pensar son las que rompen una compilación el día quince.

  2. 02días 2–5

    Modelar los datos y cerrar las reglas

    Esquema, estados, quién puede cambiar qué. Aquí salen las discusiones, y tenerlas aquí cuesta una fracción de tenerlas el día antes de salir a producción.

  3. 03días 4–12

    Construir un camino completo

    Un camino entero desde la entrada hasta el informe, en producción, usado por la gente que hace el trabajo. Un entorno de demostración no dice nada sobre si la cosa se puede usar.

  4. 04días 11–18

    Migrar y apagar el fichero viejo

    Importar el histórico, correr los dos una temporada y quitar el permiso de escritura de la hoja. Un sistema que nadie está obligado a dejar no se deja nunca.

Qué hace la plataforma y qué hace una persona

La mezcla cambia a lo largo del proyecto. Más plataforma al principio y más personas alrededor del cambio, cuando las preguntas abiertas dejan de ser técnicas.
Cada fichero generado se revisa como una merge request por el ingeniero que responderá por él más adelante.
Qué hace la plataforma y qué hace una personaQuién hace quéNotas
Leer las consultas de Access y las fórmulas de Excel que hayPlataformaSalen como reglas legibles con las que alguien puede discrepar en una reunión.
Decidir qué reglas son reales y cuáles son costumbresIngenieroSolo su gente sabe que la excepción de los martes existe por un proveedor concreto.
Servicio, esquema y migracionesPlataformaGenerados a partir del modelo acordado y revisados línea a línea antes de entrar.
Las pantallas donde la gente viveLos dosEl camino diario lo diseña una persona. Los formularios de administración de alrededor no lo necesitan.
Importar y conciliar el históricoLos dosCargar es mecánico. Decidir qué hacer con las filas que nunca cuadraron no lo es.
El plan de cambioIngenieroQué fecha, quién está de guardia y cuál es la vuelta atrás.

El equipo que lo construye

Más de diez años dentro de sistemas ajenos y decenas de migraciones entregadas: procesos en Access y Excel, clientes en VB6 y Delphi, monolitos PHP, administración de pólizas en AS/400, plantas de producción sostenidas por macros. Planificación, siniestros, facturación, inventario, expediciones, informes. Todo eso lo hemos construido antes, y la forma del trabajo se repite mucho más de lo que nadie espera.


La auditoría es la manera barata de comprobarlo usted mismo. Trabajo acotado con un entregable escrito: el modelo de datos tal como lo entendemos, las reglas sacadas de su hoja de cálculo y un plan por fases con precios al lado.

Preguntas que nos hacen los ingenieros

¿Qué stack, y podrá mantenerlo nuestro equipo?
Go en el servidor, TypeScript en el navegador, Postgres debajo. Deliberadamente aburrido: un equipo competente lo coge sin un curso, y nada ahí dentro depende de que un proveedor siga existiendo el año que viene.
¿De quién son el código y los datos?
Suyos desde el primer commit. Repositorios, canalización de despliegue, base de datos, todo suyo. Si toma el relevo después de la fase uno, la entrega forma parte de la fase y no de una negociación.
¿Cómo ponen el precio?
Cerrado por fase. La auditoría produce el alcance y la cifra llega con él, normalmente a los dos días de tener acceso.
¿Pueden trabajar junto a nuestros desarrolladores?
Sí, y normalmente sale mejor así, porque sus ingenieros tienen el conocimiento del dominio y acaban siendo dueños del código. Nos organizamos alrededor de lo que su equipo ya cubre.
¿En cuánto pueden empezar?
A los dos días de firmar el statement of work, más o menos, y la auditoría puede correr mientras se cierra el contrato. Casi todos los proyectos tienen un primer camino funcionando delante de usuarios reales antes del día doce.

Enséñenos la hoja de cálculo

Mándenos la forma del proceso y cuánta gente lo toca, más o menos. Volvemos con lo que cubriría la auditoría, cuánto tarda y cuánto cuesta.

Pedir presupuesto

La primera respuesta viene de un ingeniero, y suele preguntar quién es hoy el dueño del proceso.