Filosofía Solware
Cómo pensamos la entrega en Solware.
Principios operativos
Preferimos entregar algo real, pequeño y correcto antes que una promesa grande. La entrega es la unidad de valor.
Cuando alguien está bloqueado, el proyecto pierde dinero y confianza. Detectar y comunicar bloqueos es responsabilidad de todos.
No absorbemos cambios en silencio. Cualquier cambio se estima, se propone y se firma.
Si un ticket llega a cliente con bugs, el sistema falló antes de QA.
Un playbook, checklist o prompt bien escrito ahorra semanas. Documentar es programar el equipo.
Cada rol tiene decisiones que puede tomar solo y otras que debe escalar.
Cada bloqueo tiene un dueño y un plazo. Si no avanzamos, es porque decidimos parar.
Dirección establece qué se construye y por qué. El Coordinador convierte esa visión en tareas concretas.
Los malentendidos prolongados cuestan más que la incomodidad de una conversación directa.
Antes vs. Después
| Antes | Ahora |
|---|---|
| Los bloqueos se descubrían al final del día | Los bloqueos se escalan antes de las 4 horas |
| Cada coordinador inventaba su propio proceso | Los playbooks son el punto de partida de todos |
| Los cambios de alcance se absorbían sin costo | Todo cambio se estima y se firma antes de ejecutarse |
| QA se enteraba de los criterios al validar | Los criterios de aceptación se definen en el kickoff |
| Los reportes dependían de quién los pidiera | El reporte diario y semanal es un ritual del Coordinador |
| La documentación vivía en la memoria del equipo | Los playbooks, checklists y prompts están vivos en el Hub |
Los bloqueos se descubrían al final del día
Los bloqueos se escalan antes de las 4 horas
Cada coordinador inventaba su propio proceso
Los playbooks son el punto de partida de todos
Los cambios de alcance se absorbían sin costo
Todo cambio se estima y se firma antes de ejecutarse
QA se enteraba de los criterios al validar
Los criterios de aceptación se definen en el kickoff
Los reportes dependían de quién los pidiera
El reporte diario y semanal es un ritual del Coordinador
La documentación vivía en la memoria del equipo
Los playbooks, checklists y prompts están vivos en el Hub
Qué sí / Qué no
| Hacemos | No hacemos |
|---|---|
| Comunicar bloqueos antes de las 4 horas | Esperar a que el problema se resuelva solo |
| Estimar impacto antes de aceptar un cambio de alcance | Decir sí en la reunión sin número |
| Documentar rechazos con evidencia y criterio | Devolver tickets sin explicación |
| Usar los playbooks como punto de partida | Inventar el proceso en cada proyecto |
| Escalar cuando hay ambigüedad en los criterios | Interpretar sin confirmar |
| Respetar el alcance firmado o renegociarlo formalmente | Absorber cambios en silencio |
| Entregar algo que funciona, aunque sea pequeño | Esperar al perfecto que no llega |
| Actualizar el tablero en vivo en la daily | Dejar el tablero desactualizado para después |
Comunicar bloqueos antes de las 4 horas
Esperar a que el problema se resuelva solo
Estimar impacto antes de aceptar un cambio de alcance
Decir sí en la reunión sin número
Documentar rechazos con evidencia y criterio
Devolver tickets sin explicación
Usar los playbooks como punto de partida
Inventar el proceso en cada proyecto
Escalar cuando hay ambigüedad en los criterios
Interpretar sin confirmar
Respetar el alcance firmado o renegociarlo formalmente
Absorber cambios en silencio
Entregar algo que funciona, aunque sea pequeño
Esperar al perfecto que no llega
Actualizar el tablero en vivo en la daily
Dejar el tablero desactualizado para después