Una nova proposta digital que ha de convertir una oportunitat en producte, arquitectura i un primer lliurament defensable.
PRODUCT & PLATFORM ENGINEERING
D’una necessitat real
a un software preparat per evolucionar.
Construir no comença escollint un framework. Comença convertint una oportunitat, un procés o una necessitat de negoci en decisions prou clares sobre producte, dades, arquitectura, interfícies i lliurament.
BUSINESS / SYSTEMDECISION DELIVERY
INPUTBusiness needOpportunity · process · outcome
ENGINEERING DECISIONS
ProductArchitectureDataInterfacesDeliveryQuality
OUTPUTProduct / platformProduction · feedback · evolution
QUAN ENCAIXA
Quan la iniciativa importa més que una simple implementació de requisits.
Product & Platform Engineering encaixa quan hi ha una necessitat rellevant i cal algú que mantingui connectades les decisions de producte, arquitectura i implementació, no només que converteixi una especificació en codi.
Software que connecta processos, dades, usuaris i integracions per donar suport a una part rellevant de l’operativa.
Aplicacions per coordinar fluxos, estats, permisos, documents, decisions i traçabilitat al voltant de processos reals.
Un mòdul o una iniciativa amb prou entitat per necessitar definició, disseny i responsabilitat tècnica pròpia sense refer tota la plataforma.
DEFINE / BEFORE BUILD
El primer lliurament comença molt abans del primer component.
Un backlog pot descriure funcionalitats sense respondre encara les decisions que determinen el cost, el risc i la capacitat d’evolució. Abans d’accelerar la implementació fem explícites les preguntes que condicionen el sistema.
No busquem definir cada detall per endavant. Busquem reduir prou la incertesa perquè el compromís següent sigui responsable i reversible quan sigui possible.
Quin resultat ha de produir
Objectius, usuaris, impacte i límits que permeten saber què convé incloure en el primer abast.
On són els límits del sistema
Responsabilitats, mòduls, contractes i fronteres que eviten convertir un primer lliurament en una arquitectura accidental.
Quina informació sosté el producte
Model, relacions, titularitat, qualitat, permisos i evolució de les dades com a part del disseny, no com un detall posterior.
Com es relaciona amb el que ja existeix
APIs, integracions, esdeveniments i dependències que han de formar part de la solució des de l’inici.
Com arriba a producció
Entorns, CI/CD, testing, observabilitat i estratègia de lliurament coherents amb el risc i la freqüència de canvi.
Com continuarà canviant
Decisions prou explícites perquè el sistema pugui incorporar feedback sense dependre de recordar per què es va construir cada part.
FROM DIRECTION TO PRODUCTION
La direcció tècnica es manté connectada amb l’execució.
Les decisions perden valor si se separen de les persones que les implementen i en verifiquen les conseqüències. Mantenim el context des de la definició fins a producció perquè producte, arquitectura i codi evolucionin com a parts del mateix sistema.
- 01DEFINEDefinir el resultatObjectius · usuaris · restriccions
- 02DESIGNDissenyar el sistemaArquitectura · dades · interfícies
- 03BUILDConstruirFrontend · backend · integracions
- 04VERIFYVerificarComportament · qualitat · rendiment
- 05EVOLVEEvolucionarProducció · feedback · roadmap
ONE SYSTEM / MULTIPLE DISCIPLINES
Frontend, backend o arquitectura no són projectes separats.
Treballem en les capes que el resultat necessita. La composició concreta depèn del producte: algunes iniciatives concentren complexitat en experiència d’usuari; d’altres en dades, integració, permisos, operació o processos interns.
Experiència d’usuari, interacció, accessibilitat i comportament d’aplicacions complexes.
Lògica d’aplicació, APIs, serveis, estat, permisos i separació de responsabilitats.
Entitats, relacions, consistència, traçabilitat, documents i regles que sostenen el sistema.
APIs, serveis externs, sincronització, esdeveniments i contractes amb sistemes existents.
CI/CD, entorns, observabilitat, rendiment, seguretat i capacitat de recuperació.
Arquitectura, documentació i context perquè l’evolució no depengui de coneixement implícit.
ENGINEERING PRINCIPLES
Construir prou. Decidir explícitament. Mantenir marge per canviar.
Un primer abast defensable, no una llista infinita.
Prioritzem el conjunt mínim de capacitats que permet validar la direcció sense convertir “MVP” en una excusa per acumular deute que ja sabem que caldrà pagar.
No totes les decisions mereixen el mateix compromís.
Diferenciem quines decisions són fàcils de canviar i quines creen dependència estructural per invertir anàlisi allà on realment redueix el risc.
Verificar abans d’acceptar.
Testing, integració, rendiment o seguretat s’apliquen segons el tipus de canvi i el seu impacte. Que alguna cosa compili no constitueix prou evidència.
Continuïtat sense dependència artificial.
Decisions, lliurables i coneixement es mantenen explícits perquè el producte pugui continuar evolucionant amb Rabassoft, amb un equip intern o amb altres proveïdors.
CLIENT WORK / PRODUCT ENGINEERING
Fer evolucionar producte sota restriccions reals, no en un greenfield imaginari.
Rabassoft va col·laborar en àrees definides de frontend i producte d’eVins. El treball va combinar modernització tècnica, adaptació als mòduls contractats i resposta a noves prioritats dins d’un calendari de lliuraments exigent.
PERFORMANCE
Les rutes i els components van passar a carregar-se sota demanda, reduint un 80% el JavaScript inclòs en la càrrega inicial i millorant de manera perceptible la velocitat de càrrega.
TYPE SAFETY
Vam reforçar el tipatge estricte i vam reduir el codi sense tipus a les àrees en què vam intervenir, fent visibles durant el desenvolupament inconsistències que abans podien arribar a execució sense ser detectades.
MODULARITY
El frontend va passar a compondre rutes i capacitats segons els mòduls contractats per cada client, evitant carregar i inicialitzar àrees no disponibles i reduint la superfície funcional innecessària en el client.
DELIVERY
Quan el calendari va exigir prioritzar mòduls addicionals, vam reorganitzar el treball, vam assumir la urgència i vam lliurar l’abast prioritari en la data compromesa.
L’abast de Rabassoft es va mantenir en àrees definides de frontend i producte. La plataforma global, el backend i els seus controls d’autorització van continuar sota la responsabilitat de l’equip d’eVins.
Veure el cas d’eVinsPROJECT DEFINITION & TECHNICAL ASSESSMENT
Si encara falten decisions importants, el primer producte pot ser la definició.
Quan una iniciativa encara no permet defensar abast, arquitectura o inversió, un estudi converteix les preguntes obertes en un actiu de decisió abans de comprometre l’execució completa.
El lliurable pertany al client. El pot utilitzar després amb Rabassoft, amb el seu equip intern o amb un altre proveïdor.
Explica’ns què necessites definirOUTPUT / DECISION ASSETCLIENT OWNED
01 / DIRECTIONObjectiu, usuaris i abast inicial defensable
02 / MODELArquitectura, dades, integracions i decisions principals
03 / RISKDependències, incògnites i riscos que condicionen l’execució
04 / ROADMAPFases, estratègia d’implantació i inversió orientativa
START / CONVERSATION
Si tens alguna cosa important per construir, no cal que arribis amb la solució tècnica decidida.
La primera conversa serveix per entendre la iniciativa, el seu impacte i el grau de definició actual. A partir d’aquí podem determinar quin és el pas següent més adient.