HUMAN + ENGINEERED
El entendimientotoma forma.
Criterio humano.Precisión de ingeniería.
Ingeniería de software + productos digitales.
RecorrerEL CONTEXTO HUMANO PRODUCE MEJORES SISTEMAS.
PERSONAS
Equipos reales conrestricciones reales.
FRICCIÓN
Los procesos complejos generanfricción innecesaria.
INTENCIÓN
Un camino más simpley más útil.
¿En qué puede convertirse?
QUÉ CONSTRUIMOS
Software con la formadel trabajo real.
01
Productos digitales
Web · Mobile · Sitios · Plataformas · Experiencias de producto
02
Sistemas de negocio
Procesos · Herramientas internas · Backend · Integraciones · Automatización · Infraestructura
Dos familias, no un catálogo. El problema decide la forma.
INGENIERÍA DE SOFTWARE EN TODO EL RECORRIDO
QUÉ CONSTRUIMOS / 01
QUÉ CONSTRUIMOS / 02
INGENIERÍA DE SOFTWARE EN TODO EL RECORRIDO
Productos digitales
Sistemas de negocio
La interfaz.El comportamiento.El sistema.
Las personas lo usan.
INTERFAZ
Experiencias web y mobilecon la forma de una tarea real.
El software lo sostiene.
COMPORTAMIENTO
Lógica, información e integracionesque hacen que la experiencia funcione.
Un mismo contexto. Decisiones conectadas.
Información
Tener disponibleel contexto que importa.
Decisiones
Hacer explícitaslas responsabilidades.
Flujos
Hacer que el trabajosea posible.
De una experiencia al trabajo que hay detrás.
La ingeniería de software es la disciplina que las conecta.
CÓMO PENSAMOS
¿Qué tiene queseguir siendo cierto?
ENTENDER
¿Quién necesita que esto funcione?
Personas y contextoantes que supuestos.
DEFINIR
¿Qué tiene que hacer el sistema?
Comportamiento, límitesy relaciones.
VERIFICAR
¿Les sirve de verdad?
Volver a la necesidad.Comprobar el resultado.
CONTEXTO HUMANO → CRITERIO DE INGENIERÍA
CÓMO TRABAJAMOS
De un problemaa un sistema.
Tres momentos. Cada uno cierra una decisión y deja una regla que podemos incumplir.
01
ENTENDER
¿Quién necesita que esto funcione?
Empezamos por las personas y el contexto, no por la solución. Lo que se descubre acá decide qué se construye. Lo que no se descubre, se supone.
COMPROMISONo proponemos una forma antes de poder nombrar la fricción.
02
DEFINIR
¿Qué tiene que seguir siendo cierto?
Antes de escribir código acordamos qué no puede romperse cuando el sistema cambie. Esa respuesta gobierna después cada decisión técnica.
COMPROMISOLo que no está decidido queda marcado como abierto. No se rellena con un supuesto razonable.
03
VERIFICAR
¿Les sirve de verdad?
Verificar no es una etapa final: es volver a la necesidad y comprobar el resultado. La ingeniería de software es la disciplina que conecta los tres momentos.
COMPROMISOLo que no se puede comprobar, no se afirma.
CONTEXTO HUMANO → CRITERIO DE INGENIERÍA
CÓMO ELEGIMOS
No empezamospor la herramienta.
Empezamos por el problema. Después elegimos y conectamos las herramientas que mejor encajan con el sistema que hay que construir.
CONSTRUIMOS CON
- JavaScript
- TypeScript
- React
- Next.js
- Node.js
- Flutter
- Python
- Java
- PostgreSQL
- Supabase
- Firebase
INTEGRAMOS CON
- Mercado Pago
- Stripe
- Slack
- Salesforce
- SAP
Ecosistemas con los que trabajamos, entre otros.
EL PROBLEMA DECIDE LA FORMA
SOBRE IRIS
Una empresa de softwareliderada por ingenieros.
IRIS existe porque el software útil no sale de una lista de requerimientos. Sale de entender el trabajo real de las personas que van a usarlo.
- Criterio humano + precisión de ingeniería.
- Pensamiento orgánico + sistemas estructurados.
- Entender problemas reales + construir soluciones técnicamente rigurosas.
- Sensibilidad de diseño + ingeniería de software.
Diseño y software no viven separados. Una decisión técnica es una decisión de producto, y al revés. Por eso la ingeniería está desde la primera conversación, y no cuando ya está todo definido.
HUMAN + ENGINEERED
PREGUNTAS
Lo que nospreguntan primero.
¿Trabajan sobre productos que ya existen?
Las dos cosas. Construimos desde cero y también trabajamos sobre sistemas que ya están funcionando: evolucionarlos, ponerlos al día, integrarlos con lo que ya hay. Lo que cambia no es la capacidad, es cuánto contexto hay que entender antes de tocar nada.
¿Cómo empieza un proyecto?
Por el contexto, no por la propuesta. Primero entendemos quiénes usan el sistema, qué fricción tienen hoy y qué tiene que seguir siendo cierto cuando el software cambie. Recién después hablamos de forma, alcance y tecnología.
¿Cómo eligen la tecnología?
El problema decide. Miramos qué hay construido, qué restricciones existen, quién va a mantenerlo y cómo tiene que poder evolucionar. No imponemos un stack: elegimos las herramientas que encajan con el sistema que hay que construir.
¿Pueden trabajar con nuestro equipo técnico?
Sí. Podemos llevar una solución de punta a punta o integrarnos al equipo que ya está. Las dos formas funcionan. Lo que no cambia es que hablás directamente con las personas que construyen.
¿Qué pasa después del lanzamiento?
Lanzar no es terminar. Podemos seguir con mantenimiento, soporte, evolución y nuevas iteraciones cuando el proyecto lo necesita. No viene incluido por defecto en todos los casos: se acuerda junto con el alcance, para que no aparezca como sorpresa después.
¿Cómo cotizan?
No cotizamos antes de entender el problema. Primero acordamos alcance, incertidumbre y forma de colaboración; después proponemos la modalidad de trabajo que corresponde. Los plazos dependen de lo mismo, así que tampoco damos fechas antes de esa conversación.
¿De quién es el código?
Una vez cumplido lo acordado, recibís y controlás el código desarrollado específicamente para tu solución. Lo que no se transfiere es lo que no es nuestro para transferir: componentes preexistentes, herramientas internas, software de código abierto y servicios de terceros, cada uno con su licencia. Los términos exactos se fijan en cada acuerdo.
SI FALTA UNA PREGUNTA, ESCRIBINOS
HUMAN + ENGINEERED
Traé el contexto.Construimos el sistema.
Hablemos
contacto@somosiris.devIRIS / INGENIERÍA DE SOFTWARE + PRODUCTOS DIGITALES