Desarrollo de software a medida con Laravel

Una aplicación de negocio no trata, en su mayor parte, del negocio.

Si cuentas el código de cualquier sistema de este tipo, la parte que codifica cómo funciona de verdad tu empresa es una minoría. El resto es el aparato que toda aplicación así necesita antes de poder hacer nada útil, y esa distinción es lo más provechoso que se puede entender antes de encargar una, porque es donde se ganan y se pierden los presupuestos.

El veinte por ciento que es realmente tuyo

La parte valiosa de un desarrollo propio es la que un producto nunca podría haberte dado: tus reglas de precio, tu cadena de aprobación, el camino de un trabajo desde presupuestado a planificado a facturado, la excepción que se aplica a un cliente por motivos que vienen de hace una década.

Ahí es donde debe ir el pensamiento, y en un proyecto mal llevado ahí es donde el pensamiento se acaba, porque el presupuesto se consumió haciendo funcionar la infraestructura.

La pregunta que conviene hacerle a un proveedor no es qué framework usa. Es qué proporción de la estimación se gasta en cosas que son idénticas en todas las aplicaciones que ha construido.

Qué necesita una aplicación de negocio en Laravel antes de hacer nada útil

La lista es más larga de lo que se espera y nada de ella es negociable.

Alguien tiene que entrar, y alguien tiene que poder restablecer una contraseña sin un desarrollador. Personas distintas tienen que ver cosas distintas, impuesto en algún sitio mejor que un elemento de menú oculto: la autorización no es la autenticación, y la diferencia se ve la primera vez que una exportación alcanza registros que su operador no debía ver.

El trabajo tiene que ocurrir fuera de una petición web. Generar un documento, enviar un correo, una importación nocturna, recalcular una cifra. Eso significa una cola, que significa reintentos, que significa trabajos seguros de ejecutar dos veces - y una cola construida a la ligera es cómo un cliente recibe tres veces la misma factura.

El esquema necesita un historial en vez de un estado actual, para que un cambio se pueda revisar y reproducir en otro entorno. Hay que aceptar ficheros de gente de fuera de la organización sin que eso sea un incidente de seguridad. Y tiene que haber pruebas sobre los caminos donde el dinero y el estado cambian, o en el segundo año nadie se atreverá a tocar el sistema.

Laravel trae todo eso de serie, con una calidad que la mayoría de los equipos no alcanzaría construyéndolo, y - más importante - con una forma que el siguiente desarrollador reconoce. Un framework propio inventado hace cuatro años por alguien que ya se fue es el tipo de software a medida más caro que existe.

Las integraciones suelen ser el alcance real

La parte de estos proyectos que se desborda casi nunca son las pantallas.

Es que la aplicación tiene que ponerse de acuerdo con una contabilidad, un ERP, una pasarela de pago, una empresa de transporte, un CRM y una hoja de cálculo, ninguno de los cuales se diseñó para ponerse de acuerdo con nada. La ingeniería de hablar con ellos es sencilla. Las decisiones no.

Qué sistema es dueño del nombre de un cliente, y qué pasa cuando cambia en el otro lado. Quién asigna el número de factura. Qué hace un abono en cada lado. Cómo se aplica un pago parcial. Qué pasa cuando un sistema está caído y el otro ya ha registrado la operación.

Son decisiones comerciales con aspecto técnico, y se resuelven con tu gente de finanzas y de operaciones en vez de estimarlas nosotros. Este tipo de trabajo está en ingeniería de integraciones; en un desarrollo a medida es con frecuencia la mitad del proyecto, y un plan que lo trata como una línea al final es un plan que se retrasa.

Cómo se desarrolla un proyecto Laravel a medida

Por fases, cada una terminando con algo desplegado que la gente pueda usar de verdad.

La primera fase coge un flujo de principio a fin - no el contorno de cinco - porque eso es lo que obliga al esquema a encontrarse con datos reales. También es lo que produce una estimación del resto que valga algo, lo que una cifra dada en la semana uno no hace.

Cada fase se acota por escrito antes de empezar. Donde tengas desarrolladores, están en los pull requests desde la primera semana; así se transfieren las convenciones, y es la única forma en la que el sistema sigue siendo mantenible cuando dejamos de trabajar en él.

La migración de los datos existentes va en paralelo, no al final. El sistema nuevo se reconcilia contra el viejo, registro a registro, hasta que coinciden - las discrepancias son hallazgos y no errores, y siempre hay más de las que alguien predijo.

Qué recibes de un proyecto Laravel a medida

Al cierre de cada fase, una aplicación funcionando en infraestructura que controlas.

Junto con ella: el repositorio y su historial completo, con una compilación y un despliegue que no dependen de nosotros. Migraciones en vez de un volcado de base de datos. Una descripción escrita del modelo de datos, de cada restricción y de lo que evita, porque una restricción que nadie puede explicar es una que un futuro desarrollador borrará. Pruebas sobre los caminos que mueven dinero o cambian estado. Y las decisiones de integración registradas, incluidas las que discutimos, porque son lo que necesita un desarrollador nuevo y lo que un documento de entrega siempre omite.

Dónde comprar gana a construir

Esta respuesta a veces es no, y es más barato oírla ahora.

Si un producto cubre la mayoría y el hueco es gusto en vez de proceso, compra el producto y configúralo. La comparación honesta es cinco años contra cinco años, no el año uno contra el año uno, y a la vista larga configurar gana más a menudo de lo que la gente espera.

Si el proceso todavía se está inventando, un desarrollo pondrá en hormigón una decisión que nadie ha tomado. Mantenlo manual hasta que la forma deje de moverse.

Si el volumen es tan bajo que la versión manual cuesta una hora a la semana, automatizarlo es una afición y no una inversión.

Y si nadie dentro de la empresa está mejor cuando funciona - ninguna persona concreta cuyo trabajo se vuelva más fácil -, se abandonará por bueno que sea. Ese es el fallo que hemos visto más a menudo, y nunca es técnico.