diff --git a/_posts/2024-11-13-vmodel-vs-agile-choose-both.en.md b/_posts/2024-11-13-vmodel-vs-agile-choose-both.en.md index a172353..b75a0d8 100644 --- a/_posts/2024-11-13-vmodel-vs-agile-choose-both.en.md +++ b/_posts/2024-11-13-vmodel-vs-agile-choose-both.en.md @@ -20,7 +20,7 @@ A SaaS startup launching a new payment processor needs _specification upfront_ ( The problem isn't the methodologies - it's that managers are forced to choose all-or-nothing. -![False Choice Dilemma](/assets/images/false-choice-dilemma.svg "The False Binary Choice") +False Choice Dilemma --- @@ -39,7 +39,7 @@ Real capacity stays invisible until 60% through development. You plan on Friday' Example: A healthcare team estimated 6 months to build a patient dashboard. They discovered integration issues at month 4 - but they'd already promised go-live to hospital administrators. The last 2 months were panic mode: cutting features, cutting tests, cutting quality. -![V-Model Waterfall Diagram](/assets/images/vmodel-waterfall-diagram.svg "V-Model / Waterfall Approach") +V-Model Waterfall Diagram --- @@ -58,7 +58,7 @@ Example: A healthcare team estimated 6 months to build a patient dashboard. They Example: An agency took an "pure Agile" approach to a CMS rebuild. No specifications. Just "build a dashboard." 3 months and 5 cycles later, the client realized the design was wrong. Entire backend rebuilt. The team had optimized for velocity, not value. -![Agile Iterative Diagram](/assets/images/agile-iterative-diagram.svg "Agile / Iterative Approach") +Agile Iterative Diagram --- @@ -93,7 +93,7 @@ High-performing teams don't choose between V-Model and Agile - they **use both f This is what works. **Not Agile. Not Waterfall. Both.** -![Hybrid Methodology Phases](/assets/images/hybrid-methodology-phases.svg "Why Hybrid Methodology Wins") +Hybrid Methodology Phases --- @@ -181,7 +181,7 @@ Hybrid methodology _only works_ if you can see: Without visibility, hybrid becomes unpredictability. -![Implementation Workflow](/assets/images/implementation-workflow.svg "Implementing Hybrid Methodology") +Implementation Workflow --- diff --git a/_posts/2024-11-13-vmodel-vs-agile-choose-both.es.md b/_posts/2024-11-13-vmodel-vs-agile-choose-both.es.md index a4a67c1..b34f944 100644 --- a/_posts/2024-11-13-vmodel-vs-agile-choose-both.es.md +++ b/_posts/2024-11-13-vmodel-vs-agile-choose-both.es.md @@ -20,7 +20,7 @@ Una startup SaaS lanzando un nuevo procesador de pagos necesita _especificación El problema no son las metodologías, es que los gerentes se ven obligados a elegir todo o nada. -![Dilema de Falsa Opción](/assets/images/false-choice-dilemma.svg "La Falsa Opción Binaria") +Dilema de Falsa Opción --- @@ -39,7 +39,7 @@ La capacidad real permanece invisible hasta el 60% del desarrollo. Planifica con Ejemplo: Un equipo de salud estimó 6 meses para construir un dashboard de pacientes. Descubrieron problemas de integración en el mes 4, pero ya habían prometido la puesta en marcha a los administradores del hospital. Los últimos 2 meses fueron modo pánico: recortando funcionalidades, recortando pruebas, recortando calidad. -![Diagrama V-Model Waterfall](/assets/images/vmodel-waterfall-diagram.svg "Enfoque V-Model / Waterfall") +Diagrama V-Model Waterfall --- @@ -58,7 +58,7 @@ Más de 10 horas por semana en reuniones de standup. Repriorización constante. Ejemplo: Una agencia tomó un enfoque "Agile puro" para una reconstrucción de CMS. Sin especificaciones. Solo "construye un dashboard". 3 meses y 5 cycles después, el cliente se dio cuenta de que el diseño estaba mal. Backend completo reconstruido. El equipo había optimizado para velocidad, no para valor. -![Diagrama Agile Iterativo](/assets/images/agile-iterative-diagram.svg "Enfoque Agile / Iterativo") +Diagrama Agile Iterativo --- @@ -93,7 +93,7 @@ Los equipos de alto rendimiento no eligen entre V-Model y Agile, **usan ambos pa Esto es lo que funciona. **No Agile. No Waterfall. Ambos.** -![Fases de Metodología Híbrida](/assets/images/hybrid-methodology-phases.svg "Por Qué Gana la Metodología Híbrida") +Fases de Metodología Híbrida --- @@ -181,7 +181,7 @@ La metodología híbrida _solo funciona_ si puede ver: Sin visibilidad, híbrido se convierte en imprevisibilidad. -![Flujo de Trabajo de Implementación](/assets/images/implementation-workflow.svg "Implementando Metodología Híbrida") +Flujo de Trabajo de Implementación --- diff --git a/_posts/2024-11-13-vmodel-vs-agile-choose-both.fr.md b/_posts/2024-11-13-vmodel-vs-agile-choose-both.fr.md index 99516ae..f7c6e9a 100644 --- a/_posts/2024-11-13-vmodel-vs-agile-choose-both.fr.md +++ b/_posts/2024-11-13-vmodel-vs-agile-choose-both.fr.md @@ -20,7 +20,7 @@ Une startup SaaS lançant un nouveau processeur de paiement a besoin de *spécif Le problème n'est pas les méthodologies - c'est que les managers sont forcés de choisir tout-ou-rien. -![Dilemme Faux Choix](/assets/images/false-choice-dilemma.svg "Le Faux Choix Binaire") +Dilemme Faux Choix --- @@ -38,7 +38,7 @@ La vraie capacité reste invisible jusqu'à 60% du développement. Vous planifie Exemple: Une équipe santé a estimé 6 mois pour construire un dashboard patient. Ils ont découvert des problèmes d'intégration au mois 4 - mais ils avaient déjà promis le lancement aux administrateurs hospitaliers. Les 2 derniers mois: mode panique, features coupées, tests coupés, qualité coupée. -![Diagramme V-Model Waterfall](/assets/images/vmodel-waterfall-diagram.svg "Approche V-Model / Waterfall") +Diagramme V-Model Waterfall --- @@ -56,7 +56,7 @@ Exemple: Une équipe santé a estimé 6 mois pour construire un dashboard patien Exemple: Une agence a pris l'approche "pure Agile" pour une refonte de CMS. Pas de spécifications. Juste "construis un dashboard." 3 mois et 5 cycles plus tard, le client réalise que le design est faux. Backend entièrement reconstruit. L'équipe avait optimisé pour la vélocité, pas la valeur. -![Diagramme Agile Itératif](/assets/images/agile-iterative-diagram.svg "Approche Agile / Itérative") +Diagramme Agile Itératif --- @@ -88,7 +88,7 @@ Les équipes performantes ne choisissent pas entre V-Model et Agile - elles **ut C'est ce qui fonctionne. **Pas Agile. Pas Waterfall. Les deux.** -![Phases Méthodologie Hybride](/assets/images/hybrid-methodology-phases.svg "Pourquoi la Méthodologie Hybride Gagne") +Phases Méthodologie Hybride --- @@ -166,7 +166,7 @@ La méthodologie hybride ne fonctionne *que si* vous pouvez voir: Sans visibilité, hybride devient de l'imprévisibilité. -![Workflow d'Implémentation](/assets/images/implementation-workflow.svg "Implémenter une Méthodologie Hybride") +Workflow d'Implémentation --- diff --git a/_posts/2025-11-26-from-issue-to-release.en.md b/_posts/2025-11-26-from-issue-to-release.en.md index 80a1ec5..0278025 100644 --- a/_posts/2025-11-26-from-issue-to-release.en.md +++ b/_posts/2025-11-26-from-issue-to-release.en.md @@ -70,7 +70,7 @@ Each issue has: **Issues are the atomic unit of work.** Everything starts here. -![Issue Structure](/assets/images/issue-structure.svg "How Issues Work in Sinra") +Issue Structure --- @@ -100,7 +100,7 @@ Because it's concrete. A capability describes what your product can do. "2FA cap - Blockers and dependencies - Release readiness -![Capability Hierarchy](/assets/images/capability-hierarchy.svg "Issues Grouped into Capabilities") +Capability Hierarchy --- @@ -126,7 +126,7 @@ In Release 2.1 view, you see: - Testing status - Deployment readiness -![Release View](/assets/images/release-view.svg "Capabilities Grouped into Releases") +Release View --- @@ -200,7 +200,7 @@ Let's trace the 2FA feature through the system: - Documentation complete - Deployment successful -![Complete Workflow](/assets/images/issue-to-release-workflow.svg "Full Journey from Issue to Release") +Complete Workflow --- diff --git a/_posts/2025-11-26-from-issue-to-release.es.md b/_posts/2025-11-26-from-issue-to-release.es.md index d6e655b..f39211c 100644 --- a/_posts/2025-11-26-from-issue-to-release.es.md +++ b/_posts/2025-11-26-from-issue-to-release.es.md @@ -78,7 +78,7 @@ Cada issue tiene: **Los Issues son la unidad atómica de trabajo.** Todo comienza aquí. -![Estructura de Issue](/assets/images/issue-structure.svg "Cómo Funcionan los Issues en Sinra") +Estructura de Issue --- @@ -108,7 +108,7 @@ Porque es concreto. Una capability describe qué puede hacer su producto. "Capab - Bloqueadores y dependencias - Preparación para release -![Jerarquía de Capability](/assets/images/capability-hierarchy.svg "Issues Agrupados en Capabilities") +Jerarquía de Capability --- @@ -134,7 +134,7 @@ En la vista de Release 2.1, ve: - Status de testing - Preparación para despliegue -![Vista de Release](/assets/images/release-view.svg "Capabilities Agrupadas en Releases") +Vista de Release --- @@ -208,7 +208,7 @@ Tracemos la funcionalidad de 2FA a través del sistema: - Documentación completa - Despliegue exitoso -![Flujo de Trabajo Completo](/assets/images/issue-to-release-workflow.svg "Viaje Completo de Issue a Release") +Flujo de Trabajo Completo --- diff --git a/_posts/2025-11-26-from-issue-to-release.fr.md b/_posts/2025-11-26-from-issue-to-release.fr.md index a1b4f5d..eb7f357 100644 --- a/_posts/2025-11-26-from-issue-to-release.fr.md +++ b/_posts/2025-11-26-from-issue-to-release.fr.md @@ -75,7 +75,7 @@ Chaque issue a : **Les issues sont l'unité atomique du travail.** Tout commence ici. -![Structure Issue](/assets/images/issue-structure.svg "Comment Fonctionnent les Issues dans Sinra") +Structure Issue --- @@ -103,7 +103,7 @@ Parce que c'est concret. Une capability décrit ce que votre produit peut faire. - Les blocages et dépendances - La préparation pour la release -![Hiérarchie Capability](/assets/images/capability-hierarchy.svg "Issues Regroupées dans des Capabilities") +Hiérarchie Capability --- @@ -127,7 +127,7 @@ Dans la vue Release 2.1, vous voyez : - Statut des tests - Préparation du déploiement -![Vue Release](/assets/images/release-view.svg "Capabilities Regroupées dans des Releases") +Vue Release --- @@ -189,7 +189,7 @@ Traçons la fonctionnalité 2FA à travers le système : - Documentation complète - Déploiement réussi -![Workflow Complet](/assets/images/issue-to-release-workflow.svg "Parcours Complet d'Issue à Release") +Workflow Complet --- diff --git a/_posts/2025-12-01-release-driven-development.en.md b/_posts/2025-12-01-release-driven-development.en.md index b4fffb5..118c471 100644 --- a/_posts/2025-12-01-release-driven-development.en.md +++ b/_posts/2025-12-01-release-driven-development.en.md @@ -52,7 +52,7 @@ Sinra solves this with **release-driven development**: organizing work around co Instead: **We decide what "done" means before we start building.** -![Release-Driven Timeline](/assets/images/release-driven-timeline.svg "How Release-Driven Development Works") +Release-Driven Timeline --- @@ -86,7 +86,7 @@ Instead: **We decide what "done" means before we start building.** It doesn't work. -![Feature-Driven Chaos](/assets/images/feature-driven-chaos.svg "The Problem with Feature-First Development") +Feature-Driven Chaos --- @@ -128,7 +128,7 @@ It doesn't work. It works. -![Release-Driven Success](/assets/images/release-driven-success.svg "The Power of Release-First Planning") +Release-Driven Success --- @@ -166,7 +166,7 @@ One view. Real-time. Accessible to everyone. **When QA asks:** "What needs testing?" **Answer:** Release 2.3 shows 14 untested issues across 2 capabilities. -![Unified Release View](/assets/images/unified-release-view.svg "Everyone Sees the Same Truth") +Unified Release View --- @@ -198,7 +198,7 @@ When Product wants to add a feature: Capacity decisions become **data-driven, not political**. -![Capacity Dashboard](/assets/images/capacity-dashboard.svg "Real-Time Capacity vs. Workload") +Capacity Dashboard --- @@ -234,7 +234,7 @@ Teams report: - 90% higher team confidence - 100% clearer stakeholder communication -![Release Readiness](/assets/images/release-readiness.svg "Deployment Confidence Through Planning") +Release Readiness --- diff --git a/_posts/2025-12-01-release-driven-development.es.md b/_posts/2025-12-01-release-driven-development.es.md index af519be..c09f292 100644 --- a/_posts/2025-12-01-release-driven-development.es.md +++ b/_posts/2025-12-01-release-driven-development.es.md @@ -52,7 +52,7 @@ Sinra resuelve esto con **desarrollo orientado a releases**: organizar el trabaj En su lugar: **Decidimos qué significa "terminado" antes de comenzar a construir.** -![Cronología Orientada a Release](/assets/images/release-driven-timeline.svg "Cómo Funciona el Desarrollo Orientado a Releases") +Cronología Orientada a Release --- @@ -86,7 +86,7 @@ En su lugar: **Decidimos qué significa "terminado" antes de comenzar a construi No funciona. -![Caos Orientado a Funcionalidades](/assets/images/feature-driven-chaos.svg "El Problema con el Desarrollo Funcionalidad-Primero") +Caos Orientado a Funcionalidades --- @@ -128,7 +128,7 @@ No funciona. Funciona. -![Éxito Orientado a Release](/assets/images/release-driven-success.svg "El Poder de la Planificación Release-Primero") +Éxito Orientado a Release --- @@ -166,7 +166,7 @@ Una vista. Tiempo real. Accesible para todos. **Cuando QA pregunta:** "¿Qué necesita probarse?" **Respuesta:** Release 2.3 muestra 14 issues no probados en 2 capabilities. -![Vista de Release Unificada](/assets/images/unified-release-view.svg "Todos Ven la Misma Verdad") +Vista de Release Unificada --- @@ -198,7 +198,7 @@ Cuando Producto quiere agregar una funcionalidad: Las decisiones de capacidad se vuelven **basadas en datos, no políticas**. -![Dashboard de Capacidad](/assets/images/capacity-dashboard.svg "Capacidad en Tiempo Real vs. Carga de Trabajo") +Dashboard de Capacidad --- @@ -234,7 +234,7 @@ Los equipos reportan: - 90% mayor confianza del equipo - 100% más clara comunicación con stakeholders -![Preparación de Release](/assets/images/release-readiness.svg "Confianza en Despliegue a Través de Planificación") +Preparación de Release --- diff --git a/_posts/2025-12-01-release-driven-development.fr.md b/_posts/2025-12-01-release-driven-development.fr.md index 0d9c6d9..ff0c441 100644 --- a/_posts/2025-12-01-release-driven-development.fr.md +++ b/_posts/2025-12-01-release-driven-development.fr.md @@ -49,7 +49,7 @@ Sinra résout cela avec le **release-driven development** : organiser le travail Au lieu : **On décide ce que "fini" signifie avant de commencer à construire.** -![Timeline Release-Driven](/assets/images/release-driven-timeline.svg "Comment Fonctionne le Release-Driven Development") +Timeline Release-Driven --- @@ -80,7 +80,7 @@ Au lieu : **On décide ce que "fini" signifie avant de commencer à construire.* Ça ne fonctionne pas. -![Chaos Feature-Driven](/assets/images/feature-driven-chaos.svg "Le Problème avec le Développement Feature-First") +Chaos Feature-Driven --- @@ -118,7 +118,7 @@ Au lieu : **On décide ce que "fini" signifie avant de commencer à construire.* Ça fonctionne. -![Succès Release-Driven](/assets/images/release-driven-success.svg "Le Pouvoir de la Planification Release-First") +Succès Release-Driven --- @@ -154,7 +154,7 @@ Une vue. Temps réel. Accessible à tous. **Quand QA demande :** "Qu'est-ce qui doit être testé ?" **Réponse :** Release 2.3 montre 14 issues non testées à travers 2 capabilities. -![Vue Release Unifiée](/assets/images/unified-release-view.svg "Tout le Monde Voit la Même Vérité") +Vue Release Unifiée --- @@ -184,7 +184,7 @@ Quand le Product veut ajouter une fonctionnalité : Les décisions de capacité deviennent **pilotées par les données, pas politiques**. -![Tableau de Bord Capacité](/assets/images/capacity-dashboard.svg "Capacité vs. Charge de Travail Temps Réel") +Tableau de Bord Capacité --- @@ -217,7 +217,7 @@ Les équipes rapportent : - 90% plus haute confiance d'équipe - 100% communication stakeholder plus claire -![Préparation Release](/assets/images/release-readiness.svg "Confiance de Déploiement Par la Planification") +Préparation Release --- diff --git a/_posts/2025-12-18-communication-dispersee-features.fr.md b/_posts/2025-12-18-communication-dispersee-features.fr.md index 34cf30a..2c39f6f 100644 --- a/_posts/2025-12-18-communication-dispersee-features.fr.md +++ b/_posts/2025-12-18-communication-dispersee-features.fr.md @@ -322,7 +322,7 @@ Une équipe a passé 2 semaines à réimplémenter une fonctionnalité selon une **Résultat :** Chaque outil fait une chose bien, mais **aucun ne relie le travail au contexte**. -![Communication Dispersée](/assets/images/dispersed-communication.svg "Le Contexte Fragmenté Entre Les Outils") +Communication Dispersée --- @@ -390,7 +390,7 @@ Le commentary est un espace de discussion riche attaché à chaque issue et fonc **Différence Clé :** Les discussions ne flottent pas dans Discord - elles **vivent avec le travail**. -![Commentary Centralisé](/assets/images/centralized-commentary.svg "Le Commentary : Discussions Attachées au Travail") +Commentary Centralisé --- @@ -600,7 +600,7 @@ Parce que **la discussion et la documentation sont au même endroit**. Vous ne synchronisez pas - vous discutez **dans le contexte du travail**. -![Workflow Centralisé](/assets/images/centralized-workflow.svg "De la Dispersion à la Centralisation") +Workflow Centralisé --- @@ -656,7 +656,7 @@ Un dev a réimplémenté une fonctionnalité mal selon une spec Notion obsolète **Citation Product Manager :** > « Fini le 'je crois qu'on en a parlé dans Discord mais je sais plus où'. Tout est là, avec le contexte. Je peux onboard des nouveaux en leur montrant 3-4 fonctionnalités clés et ils comprennent tout. » -![Avant Après Sinra](/assets/images/before-after-sinra-communication.svg "CloudBridge : Avant et Après Sinra") +Avant Après Sinra --- diff --git a/_posts/2025-12-18-comunicacion-dispersa-features.es.md b/_posts/2025-12-18-comunicacion-dispersa-features.es.md index 5b2fb96..1e0b8da 100644 --- a/_posts/2025-12-18-comunicacion-dispersa-features.es.md +++ b/_posts/2025-12-18-comunicacion-dispersa-features.es.md @@ -323,7 +323,7 @@ Un equipo pasó 2 semanas reimplementando una funcionalidad según una spec de N **Resultado :** Cada herramienta hace una cosa bien, pero **ninguna vincula el trabajo al contexto**. -![Comunicación Dispersa](/assets/images/dispersed-communication.svg "El Contexto Fragmentado Entre Las Herramientas") +Comunicación Dispersa --- @@ -391,7 +391,7 @@ El commentary es un espacio de discusión rico adjunto a cada issue y funcionali **Diferencia Clave :** Las discusiones no flotan en Discord - **viven con el trabajo**. -![Commentary Centralizado](/assets/images/centralized-commentary.svg "El Commentary: Discusiones Adjuntas al Trabajo") +Commentary Centralizado --- @@ -601,7 +601,7 @@ Porque **la discusión y la documentación están en el mismo lugar**. No sincronizas - discutes **en el contexto del trabajo**. -![Workflow Centralizado](/assets/images/centralized-workflow.svg "De la Dispersión a la Centralización") +Workflow Centralizado --- @@ -657,7 +657,7 @@ Un dev reimplementó una funcionalidad mal según una spec de Notion obsoleta. E **Cita del Product Manager :** > « Fin del 'creo que lo hablamos en Discord pero no recuerdo dónde'. Todo está ahí, con contexto. Puedo onboardear nuevas personas mostrándoles 3-4 funcionalidades clave y entienden todo. » -![Antes y Después Sinra](/assets/images/before-after-sinra-communication.svg "CloudBridge: Antes y Después de Sinra") +Antes y Después Sinra --- diff --git a/_posts/2025-12-18-dispersed-communication-features.en.md b/_posts/2025-12-18-dispersed-communication-features.en.md index cdaaba9..34a0b75 100644 --- a/_posts/2025-12-18-dispersed-communication-features.en.md +++ b/_posts/2025-12-18-dispersed-communication-features.en.md @@ -322,7 +322,7 @@ A team spent 2 weeks reimplementing a feature according to a stale Notion spec - **Result:** Each tool does one thing well, but **none connects work to context**. -![Dispersed Communication](/assets/images/dispersed-communication.svg "Context Fragmented Across Tools") +Dispersed Communication --- @@ -390,7 +390,7 @@ Commentary is a rich discussion space attached to each issue and feature in Sinr **Key Difference:** Discussions don't float in Discord - they **live with the work**. -![Centralized Commentary](/assets/images/centralized-commentary.svg "Commentary: Discussions Attached to Work") +Centralized Commentary --- @@ -600,7 +600,7 @@ Because **discussion and documentation are in the same place**. You don't synchronize - you discuss **in the work's context**. -![Centralized Workflow](/assets/images/centralized-workflow.svg "From Dispersion to Centralization") +Centralized Workflow --- @@ -656,7 +656,7 @@ A dev reimplemented a feature wrong according to a stale Notion spec. The real a **Product Manager Quote:** > "No more 'I think we talked about it in Discord but can't find where'. Everything is there, with context. I can onboard new people by showing them 3-4 key features and they get it all." -![Before After Sinra](/assets/images/before-after-sinra-communication.svg "CloudBridge: Before and After Sinra") +Before After Sinra --- diff --git a/_posts/2025-12-19-roadmap-incomplete-po-pm.en.md b/_posts/2025-12-19-roadmap-incomplete-po-pm.en.md index 5f1677f..87c4506 100644 --- a/_posts/2025-12-19-roadmap-incomplete-po-pm.en.md +++ b/_posts/2025-12-19-roadmap-incomplete-po-pm.en.md @@ -155,7 +155,7 @@ Your roadmap is a nice Gantt in Excel or a colorful Notion board. Each feature h **Result:** You see the trees (issues), not the forest (release). -![Roadmap Comparison Excel vs Sinra](/assets/images/blog/2025-12-19-roadmap-incomplete-pm-comparison.svg "Obsolete Excel vs Real-Time Sinra") +Roadmap Comparison Excel vs Sinra --- @@ -280,7 +280,7 @@ Billing [▒▒▒▒▒▒▒▒▒▒▒▒] **Response time:** 10 seconds instead of 30 minutes of discussion. -![Real-Time Workload by Developer](/assets/images/blog/2025-12-19-roadmap-incomplete-pm-workload.svg "Complete Visibility of Developer Workload") +Real-Time Workload by Developer --- @@ -322,7 +322,7 @@ Tests [▒▒▒▒▒▒▒▒▒▒▒▒] 0% 🚨 Not started - ✅ No risk of forgetting a critical sub-part - ✅ Instant response to management questions ("Where are we on SSO?" → "58%, backend behind, tests not started") -![Feature Progress with Alerts](/assets/images/blog/2025-12-19-roadmap-incomplete-pm-feature-progress.svg "Granular Visibility of Each Feature") +Feature Progress with Alerts --- @@ -481,7 +481,7 @@ The Sinra **backlog** lets you manage your unplanned issues and features, and es **CTO Quote:** > "Real-time visibility of dev workload changes everything. We can rebalance before a dev gets overloaded and another underutilized. And the Gantt view finally aligns Product and Engineering on the same roadmap." -![TechFlow Results Before/After Sinra](/assets/images/blog/2025-12-19-roadmap-incomplete-pm-before-after.svg "Measurable Impact on PO/PM KPIs") +TechFlow Results Before/After Sinra --- diff --git a/_posts/2025-12-19-roadmap-incomplete-po-pm.es.md b/_posts/2025-12-19-roadmap-incomplete-po-pm.es.md index 6453faf..f10775b 100644 --- a/_posts/2025-12-19-roadmap-incomplete-po-pm.es.md +++ b/_posts/2025-12-19-roadmap-incomplete-po-pm.es.md @@ -155,7 +155,7 @@ Faltan 3 semanas para el deadline. El CTO te pregunta: **Resultado:** Ves los árboles (issues), no el bosque (release). -![Comparación Roadmap Excel vs Sinra](/assets/images/blog/2025-12-19-roadmap-incomplete-pm-comparison.svg "Excel Obsoleto vs Sinra en Tiempo Real") +Comparación Roadmap Excel vs Sinra --- @@ -280,7 +280,7 @@ Los **releases** en Sinra te permiten agrupar múltiples características y obte **Tiempo de respuesta:** 10 segundos en lugar de 30 minutos de discusión. -![Carga en Tiempo Real por Desarrollador](/assets/images/blog/2025-12-19-roadmap-incomplete-pm-workload.svg "Visibilidad Completa de la Carga de Trabajo del Desarrollador") +Carga en Tiempo Real por Desarrollador --- @@ -322,7 +322,7 @@ Pruebas [▒▒▒▒▒▒▒▒▒▒▒▒] 0% 🚨 No iniciado - ✅ Sin riesgo de olvidar una sub-parte crítica - ✅ Respuesta instantánea a preguntas de la dirección ("¿Dónde estamos en SSO?" → "58%, backend retrasado, pruebas no iniciadas") -![Progreso de Características con Alertas](/assets/images/blog/2025-12-19-roadmap-incomplete-pm-feature-progress.svg "Visibilidad Granular de Cada Característica") +Progreso de Características con Alertas --- @@ -481,7 +481,7 @@ Release "Email Campaigns v2" programado para finales de marzo. **Cita CTO:** > "La visibilidad en tiempo real de la carga de los devs cambia todo. Podemos reequilibrar antes de que un dev esté sobrecargado y otro subutilizado. Y la vista Gantt finalmente alinea Product e Ingeniería en la misma roadmap." -![Resultados TechFlow Antes/Después de Sinra](/assets/images/blog/2025-12-19-roadmap-incomplete-pm-before-after.svg "Impacto Medible en KPIs de PO/PM") +Resultados TechFlow Antes/Después de Sinra --- diff --git a/_posts/2025-12-19-roadmap-incomplete-po-pm.fr.md b/_posts/2025-12-19-roadmap-incomplete-po-pm.fr.md index 1e314ba..3089db8 100644 --- a/_posts/2025-12-19-roadmap-incomplete-po-pm.fr.md +++ b/_posts/2025-12-19-roadmap-incomplete-po-pm.fr.md @@ -155,7 +155,7 @@ On est à 3 semaines de la deadline. Le CTO vous demande : **Résultat :** Vous voyez les arbres (issues), pas la forêt (release). -![Comparaison Roadmap Excel vs Sinra](/assets/images/blog/2025-12-19-roadmap-incomplete-pm-comparison.svg "Excel Obsolète vs Sinra Temps Réel") +Comparaison Roadmap Excel vs Sinra --- @@ -280,7 +280,7 @@ Les **releases** dans Sinra permettent de regrouper plusieurs features et d'obte **Temps de réponse :** 10 secondes au lieu de 30 minutes de discussions. -![Charge Temps Réel Par Développeur](/assets/images/blog/2025-12-19-roadmap-incomplete-pm-workload.svg "Visibilité Complète de la Charge par Développeur") +Charge Temps Réel Par Développeur --- @@ -322,7 +322,7 @@ Tests [▒▒▒▒▒▒▒▒▒▒▒▒] 0% 🚨 Pas commencé - ✅ Aucun risque d'oublier une sous-partie critique - ✅ Réponse instantanée aux questions management (« On en est où sur SSO ? » → « 58%, backend en retard, tests pas commencés ») -![Progression Feature avec Alertes](/assets/images/blog/2025-12-19-roadmap-incomplete-pm-feature-progress.svg "Visibilité Granulaire de Chaque Feature") +Progression Feature avec Alertes --- @@ -481,7 +481,7 @@ Release « Email Campaigns v2 » prévue pour fin mars. **Citation CTO :** > « La visibilité temps réel sur la charge des devs change tout. On peut rééquilibrer avant qu'un dev soit surchargé et un autre sous-utilisé. Et la vue Gantt permet enfin d'aligner Product et Engineering sur la même roadmap. » -![Résultats TechFlow Avant/Après Sinra](/assets/images/blog/2025-12-19-roadmap-incomplete-pm-before-after.svg "Impact Mesurable sur les KPIs PO/PM") +Résultats TechFlow Avant/Après Sinra --- diff --git a/_posts/2025-12-20-temps-vs-complexite-estimation.en.md b/_posts/2025-12-20-temps-vs-complexite-estimation.en.md index 6b8e7a7..9200d42 100644 --- a/_posts/2025-12-20-temps-vs-complexite-estimation.en.md +++ b/_posts/2025-12-20-temps-vs-complexite-estimation.en.md @@ -62,7 +62,7 @@ Product Owner: "But... what are the points for then?" **Result:** You create an unnecessary layer of abstraction that hides reality. -![Planning Poker vs Time Estimation](/assets/images/blog/2025-12-20-temps-vs-complexite-planning-poker.svg "Planning Poker: 20 min debate vs Time Estimation: 2 min") +Planning Poker vs Time Estimation --- @@ -81,7 +81,7 @@ Management will **always** convert points to time: Instead of saying directly "5 days", you say "20 points" which everyone converts to "5 days" in their heads anyway. -![Useless Conversion Cycle](/assets/images/blog/2025-12-20-temps-vs-complexite-conversion-cycle.svg "The Lying Cycle of Story Points") +Useless Conversion Cycle --- @@ -291,7 +291,7 @@ You know **exactly** how many days of work are assigned to each person. If you can't estimate in days, **decompose**. -![Forced Decomposition by Time](/assets/images/blog/2025-12-20-temps-vs-complexite-decomposition.svg "Time Forces Decomposition Into Estimable Issues") +Forced Decomposition by Time --- @@ -668,7 +668,7 @@ Instead of "13 points", decomposed into: **Product Manager Quote:** > "With points, I never knew when we'd ship. Now I can say 'in 3 weeks' with 80% confidence. Stakeholders love it." -![TechFlow Before/After Results](/assets/images/blog/2025-12-20-temps-vs-complexite-techflow-results.svg "Measurable Impact: Story Points vs Time") +TechFlow Before/After Results --- diff --git a/_posts/2025-12-20-temps-vs-complexite-estimation.es.md b/_posts/2025-12-20-temps-vs-complexite-estimation.es.md index d55397e..eb66ff8 100644 --- a/_posts/2025-12-20-temps-vs-complexite-estimation.es.md +++ b/_posts/2025-12-20-temps-vs-complexite-estimation.es.md @@ -62,7 +62,7 @@ Los **story points** (puntos de complejidad) son una abstracción inventada por **Resultado:** Creas una capa de abstracción innecesaria que oculta la realidad. -![Planning Poker vs Estimación de Tiempo](/assets/images/blog/2025-12-20-temps-vs-complexite-planning-poker.svg "Planning Poker: 20 min de debate vs Estimación de Tiempo: 2 min") +Planning Poker vs Estimación de Tiempo --- @@ -81,7 +81,7 @@ La gestión **siempre** convertirá los puntos a tiempo: En lugar de decir directamente « 5 días », dices « 20 puntos » que se transforman en « 5 días » en la cabeza de todos de todas formas. -![Ciclo de Conversión Inútil](/assets/images/blog/2025-12-20-temps-vs-complexite-conversion-cycle.svg "El Ciclo Mentiroso de los Story Points") +Ciclo de Conversión Inútil --- @@ -291,7 +291,7 @@ Sabes **exactamente** cuántos días de trabajo están asignados a cada persona. Si no puedes estimar en días, **descompón**. -![Descomposición Forzada por El Tiempo](/assets/images/blog/2025-12-20-temps-vs-complexite-decomposition.svg "El Tiempo Fuerza La Descomposición en Issues Estimables") +Descomposición Forzada por El Tiempo --- @@ -668,7 +668,7 @@ En lugar de « 13 puntos », descomposición en: **Cita Del Product Manager:** > « Con los puntos, nunca sabía cuándo íbamos a entregar. Ahora puedo decir 'en 3 semanas' con 80% de confianza. Los stakeholders lo aman. » -![Resultados TechFlow Antes/Después](/assets/images/blog/2025-12-20-temps-vs-complexite-techflow-results.svg "Impacto Medible: Story Points vs Tiempo") +Resultados TechFlow Antes/Después --- diff --git a/_posts/2025-12-20-temps-vs-complexite-estimation.fr.md b/_posts/2025-12-20-temps-vs-complexite-estimation.fr.md index a8dc30a..5a2e026 100644 --- a/_posts/2025-12-20-temps-vs-complexite-estimation.fr.md +++ b/_posts/2025-12-20-temps-vs-complexite-estimation.fr.md @@ -62,7 +62,7 @@ Les **story points** (points de complexité) sont une abstraction inventée par **Résultat :** Vous créez une couche d'abstraction inutile qui masque la réalité. -![Planning Poker vs Estimation Temps](/assets/images/blog/2025-12-20-temps-vs-complexite-planning-poker.svg "Planning Poker : 20 min de débat vs Estimation Temps : 2 min") +Planning Poker vs Estimation Temps --- @@ -81,7 +81,7 @@ Le management convertira **toujours** les points en temps : Au lieu de dire directement « 5 jours », vous dites « 20 points » qui se transforment en « 5 jours » dans la tête de tout le monde. -![Cycle de Conversion Inutile](/assets/images/blog/2025-12-20-temps-vs-complexite-conversion-cycle.svg "Le Cycle Mensonger des Story Points") +Cycle de Conversion Inutile --- @@ -291,7 +291,7 @@ Vous savez **exactement** combien de jours de travail sont assignés à chaque p Si vous ne pouvez pas estimer en jours, **décomposez**. -![Décomposition Forcée par le Temps](/assets/images/blog/2025-12-20-temps-vs-complexite-decomposition.svg "Le Temps Force La Décomposition en Issues Estimables") +Décomposition Forcée par le Temps --- @@ -668,7 +668,7 @@ Au lieu de « 13 points », décomposition : **Citation Product Manager :** > « Avec les points, je ne savais jamais quand on allait livrer. Maintenant, je peux dire "dans 3 semaines" avec 80% de confiance. Les stakeholders adorent. » -![Résultats TechFlow Avant/Après](/assets/images/blog/2025-12-20-temps-vs-complexite-techflow-results.svg "Impact Mesurable : Story Points vs Temps") +Résultats TechFlow Avant/Après --- diff --git a/_posts/2025-12-22-qa-invisible-tests-disperses.en.md b/_posts/2025-12-22-qa-invisible-tests-disperses.en.md index 5eb3f9b..0d4aa03 100644 --- a/_posts/2025-12-22-qa-invisible-tests-disperses.en.md +++ b/_posts/2025-12-22-qa-invisible-tests-disperses.en.md @@ -86,7 +86,7 @@ Your QA maintains an Excel file with all test cases: **Real Result:** A team discovers 3 weeks after a release that a critical feature had **no test case** defined - it was in an old lost Excel version. -![QA Scattered Across Tools](/assets/images/blog/2025-12-22-qa-invisible-fragmented-tools.svg "Excel, Jira, Notes: Fragmented QA") +QA Scattered Across Tools --- @@ -193,7 +193,7 @@ You're shipping a release with 12 features. - ❌ Marie doesn't know when features will be ready for her - ❌ Testing becomes a bottleneck -![QA Bottleneck At End Of Sprint](/assets/images/blog/2025-12-22-qa-invisible-bottleneck.svg "Testing In Rush Mode: The Bottleneck") +QA Bottleneck At End Of Sprint --- @@ -215,7 +215,7 @@ You're shipping a release with 12 features. Devs don't know what QA tests. QA doesn't know what devs have developed. -![Dev And QA Separated](/assets/images/blog/2025-12-22-qa-invisible-dev-qa-separated.svg "Two Parallel Worlds Without Communication") +Dev And QA Separated --- @@ -276,7 +276,7 @@ In Sinra, **testings** (test cases) are directly linked to **capabilities** (fea **Result:** Dev and QA work in the same system, with shared visibility. -![Testings Linked To Capabilities](/assets/images/blog/2025-12-22-qa-invisible-unified-workflow.svg "Sinra: Dev And QA Unified") +Testings Linked To Capabilities --- @@ -357,7 +357,7 @@ In Sinra, **testings** (test cases) are directly linked to **capabilities** (fea - ✅ Complete history (failed → bug → fix → passed) - ✅ Real-time Dev ↔ QA synchronization -![Complete Test History](/assets/images/blog/2025-12-22-qa-invisible-test-history.svg "Total Traceability: Failed → Bug → Fix → Passed") +Complete Test History --- @@ -388,7 +388,7 @@ In Sinra, **testings** (test cases) are directly linked to **capabilities** (fea **Response time:** 30 seconds instead of 2 hours. -![QA Progression Dashboard](/assets/images/blog/2025-12-22-qa-invisible-release-dashboard.svg "Real-Time Visibility Per Release") +QA Progression Dashboard --- @@ -521,7 +521,7 @@ Release "Patient Portal v3.2" shipped with feature "Export medical record PDF". **Quote from CTO:** > "No more Friday nights wondering if we can ship Monday. I open Sinra, I see QA progression in real-time, and I make fact-based decisions. Game changer." -![HealthTech Before/After Sinra](/assets/images/blog/2025-12-22-qa-invisible-before-after.svg "Measurable Impact: Invisible QA vs Unified QA") +HealthTech Before/After Sinra --- diff --git a/_posts/2025-12-22-qa-invisible-tests-disperses.es.md b/_posts/2025-12-22-qa-invisible-tests-disperses.es.md index d641608..c08fc28 100644 --- a/_posts/2025-12-22-qa-invisible-tests-disperses.es.md +++ b/_posts/2025-12-22-qa-invisible-tests-disperses.es.md @@ -86,7 +86,7 @@ Tu QA mantiene un archivo Excel con todos los test cases: **Resultado Real:** Un equipo descubre 3 semanas después de un release que una feature crítica no tenía **ningún test case** definido - estaba en una versión antigua de Excel perdida. -![QA Disperso Entre Herramientas](/assets/images/blog/2025-12-22-qa-invisible-fragmented-tools.svg "Excel, Jira, Notas: QA Fragmentado") +QA Disperso Entre Herramientas --- @@ -193,7 +193,7 @@ Vas a lanzar un release con 12 features. - ❌ Marie no sabe cuándo las features estarán listas para ella - ❌ Testing se convierte en un cuello de botella -![Cuello De Botella QA Al Final Del Sprint](/assets/images/blog/2025-12-22-qa-invisible-bottleneck.svg "Testing En Urgencia: El Cuello de Botella") +Cuello De Botella QA Al Final Del Sprint --- @@ -215,7 +215,7 @@ Vas a lanzar un release con 12 features. Los devs no saben qué testea QA. QA no sabe qué han desarrollado los devs. -![Dev Y QA Separados](/assets/images/blog/2025-12-22-qa-invisible-dev-qa-separated.svg "Dos Mundos Paralelos Sin Comunicación") +Dev Y QA Separados --- @@ -276,7 +276,7 @@ En Sinra, los **testings** (test cases) están directamente vinculados a las **c **Resultado:** Dev y QA trabajan en el mismo sistema, con visibilidad compartida. -![Testings Vinculados A Capabilities](/assets/images/blog/2025-12-22-qa-invisible-unified-workflow.svg "Sinra: Dev Y QA Unificados") +Testings Vinculados A Capabilities --- @@ -357,7 +357,7 @@ En Sinra, los **testings** (test cases) están directamente vinculados a las **c - ✅ Historial completo (failed → bug → fix → passed) - ✅ Sincronización Dev ↔ QA en tiempo real -![Historial Completo De Tests](/assets/images/blog/2025-12-22-qa-invisible-test-history.svg "Trazabilidad Total: Failed → Bug → Fix → Passed") +Historial Completo De Tests --- @@ -388,7 +388,7 @@ En Sinra, los **testings** (test cases) están directamente vinculados a las **c **Tiempo de respuesta:** 30 segundos en lugar de 2 horas. -![Dashboard Progresión QA](/assets/images/blog/2025-12-22-qa-invisible-release-dashboard.svg "Visibilidad En Tiempo Real Por Release") +Dashboard Progresión QA --- @@ -521,7 +521,7 @@ Release "Patient Portal v3.2" lanzado con feature "Export historial médico PDF" **Cita del CTO:** > "Se acabaron los viernes por la noche preguntándose si podemos lanzar el lunes. Abro Sinra, veo la progresión QA en tiempo real, y tomo decisiones basadas en hechos. Game changer." -![HealthTech Antes/Después Sinra](/assets/images/blog/2025-12-22-qa-invisible-before-after.svg "Impacto Medible: QA Invisible vs QA Unificado") +HealthTech Antes/Después Sinra --- diff --git a/_posts/2025-12-22-qa-invisible-tests-disperses.fr.md b/_posts/2025-12-22-qa-invisible-tests-disperses.fr.md index 4dd9710..d9c95f9 100644 --- a/_posts/2025-12-22-qa-invisible-tests-disperses.fr.md +++ b/_posts/2025-12-22-qa-invisible-tests-disperses.fr.md @@ -86,7 +86,7 @@ Votre QA maintient un fichier Excel avec tous les test cases : **Résultat Réel :** Une équipe découvre 3 semaines après une release qu'une feature critique n'avait **aucun test case** défini - elle était dans une ancienne version Excel perdue. -![QA Dispersé Entre Outils](/assets/images/blog/2025-12-22-qa-invisible-fragmented-tools.svg "Excel, Jira, Notes : Le QA Fragmenté") +QA Dispersé Entre Outils --- @@ -193,7 +193,7 @@ Vous livrez une release avec 12 features. - ❌ Marie ne sait pas quand les features seront prêtes pour elle - ❌ Testing devient un goulot d'étranglement -![Goulot QA En Fin De Sprint](/assets/images/blog/2025-12-22-qa-invisible-bottleneck.svg "Testing En Urgence : Le Goulot d'Étranglement") +Goulot QA En Fin De Sprint --- @@ -215,7 +215,7 @@ Vous livrez une release avec 12 features. Les devs ne savent pas ce que QA teste. QA ne sait pas ce que les devs ont développé. -![Dev et QA Séparés](/assets/images/blog/2025-12-22-qa-invisible-dev-qa-separated.svg "Deux Mondes Parallèles Sans Communication") +Dev et QA Séparés --- @@ -276,7 +276,7 @@ Dans Sinra, les **testings** (test cases) sont directement liés aux **capabilit **Résultat :** Dev et QA travaillent dans le même système, avec visibilité partagée. -![Testings Liés Aux Capabilities](/assets/images/blog/2025-12-22-qa-invisible-unified-workflow.svg "Sinra : Dev et QA Unifiés") +Testings Liés Aux Capabilities --- @@ -357,7 +357,7 @@ Dans Sinra, les **testings** (test cases) sont directement liés aux **capabilit - ✅ Historique complet (failed → bug → fix → passed) - ✅ Synchronisation Dev ↔ QA en temps réel -![Historique Complet Des Tests](/assets/images/blog/2025-12-22-qa-invisible-test-history.svg "Traçabilité Totale : Failed → Bug → Fix → Passed") +Historique Complet Des Tests --- @@ -388,7 +388,7 @@ Dans Sinra, les **testings** (test cases) sont directement liés aux **capabilit **Temps de réponse :** 30 secondes au lieu de 2 heures. -![Dashboard Progression QA](/assets/images/blog/2025-12-22-qa-invisible-release-dashboard.svg "Visibilité Temps Réel Par Release") +Dashboard Progression QA --- @@ -521,7 +521,7 @@ Release « Patient Portal v3.2 » livrée avec feature « Export dossier médica **Citation CTO :** > « Fini les vendredis soir à se demander si on peut livrer lundi. J'ouvre Sinra, je vois la progression QA en temps réel, et je prends une décision basée sur des faits. Game changer. » -![HealthTech Avant/Après Sinra](/assets/images/blog/2025-12-22-qa-invisible-before-after.svg "Impact Mesurable : QA Invisible vs QA Unifié") +HealthTech Avant/Après Sinra --- diff --git a/_posts/2025-12-24-documentation-morte-notion-confluence.en.md b/_posts/2025-12-24-documentation-morte-notion-confluence.en.md index 799a100..2d7c1c2 100644 --- a/_posts/2025-12-24-documentation-morte-notion-confluence.en.md +++ b/_posts/2025-12-24-documentation-morte-notion-confluence.en.md @@ -82,7 +82,7 @@ Lead Dev: "Uh... good question. Maybe the 'Auth System Overview'? Or the 'Quick **Result:** Alex spent 2 hours reading obsolete documentation to eventually learn by reading the code. -![Multiple versions: Nobody knows which is correct](/assets/images/blog/2025-12-24-documentation-morte-multiple-versions.svg) +Multiple versions: Nobody knows which is correct --- @@ -118,7 +118,7 @@ You write a beautiful technical spec in Notion 6 months ago. The code evolves. T **Real Result:** An internal study at a 50-person tech scale-up revealed that **73% of their Confluence documentation was over 6 months old and no longer matched the current code**. -![Timeline of documentation obsolescence over 6 months](/assets/images/blog/2025-12-24-documentation-morte-obsolescence-timeline.svg) +Timeline of documentation obsolescence over 6 months --- @@ -300,7 +300,7 @@ Information scattered across: Nobody knows where to look. Nobody knows which info is correct. Everyone maintains their own mental version of "how it really works". -![Documentation scattered across 6 tools](/assets/images/blog/2025-12-24-documentation-morte-scattered-tools.svg) +Documentation scattered across 6 tools --- @@ -366,7 +366,7 @@ Let's revisit the authentication example. **Result:** Notion doc frozen, code evolves, total desynchronization. -![Traditional approach vs Sinra](/assets/images/blog/2025-12-24-documentation-morte-traditional-vs-sinra.svg) +Traditional approach vs Sinra --- @@ -546,7 +546,7 @@ Developer searches: "OAuth2 refresh tokens" **With Notion + GitHub + Jira separated:** 30 minutes (3 searches in 3 tools). -![Siloed search vs unified search](/assets/images/blog/2025-12-24-documentation-morte-search-comparison.svg) +Siloed search vs unified search --- @@ -606,7 +606,7 @@ New developer implements "CSV Export" feature based on 8-month-old Notion spec. **Product Manager Quote:** > "No more 6 contradictory versions of a spec. We have one capability with description + commentary. It's THE source of truth. If it changes, we update the capability. Simple." -![DataFlow: Before vs After Sinra](/assets/images/blog/2025-12-24-documentation-morte-before-after.svg) +DataFlow: Before vs After Sinra --- diff --git a/_posts/2025-12-24-documentation-morte-notion-confluence.es.md b/_posts/2025-12-24-documentation-morte-notion-confluence.es.md index 8b238e1..13b17eb 100644 --- a/_posts/2025-12-24-documentation-morte-notion-confluence.es.md +++ b/_posts/2025-12-24-documentation-morte-notion-confluence.es.md @@ -82,7 +82,7 @@ Lead Dev: "Eh... buena pregunta. ¿Tal vez el 'Auth System Overview'? ¿O el 'Qu **Resultado:** Alex pasó 2 horas leyendo documentación obsoleta para finalmente aprender leyendo el código. -![Versiones múltiples: Nadie sabe cuál es correcta](/assets/images/blog/2025-12-24-documentation-morte-multiple-versions.svg) +Versiones múltiples: Nadie sabe cuál es correcta --- @@ -118,7 +118,7 @@ Escribes una spec técnica hermosa en Notion hace 6 meses. El código evoluciona **Resultado Real:** Un estudio interno en una scale-up tech de 50 personas reveló que **el 73% de su documentación Confluence tenía más de 6 meses y ya no correspondía al código actual**. -![Cronología de la obsolescencia de documentación en 6 meses](/assets/images/blog/2025-12-24-documentation-morte-obsolescence-timeline.svg) +Cronología de la obsolescencia de documentación en 6 meses --- @@ -300,7 +300,7 @@ Información dispersa entre: Nadie sabe dónde buscar. Nadie sabe qué info es correcta. Cada uno mantiene su propia versión mental de "cómo funciona realmente". -![Documentación dispersa entre 6 herramientas](/assets/images/blog/2025-12-24-documentation-morte-scattered-tools.svg) +Documentación dispersa entre 6 herramientas --- @@ -366,7 +366,7 @@ Retomemos el ejemplo de la autenticación. **Resultado:** Doc de Notion congelado, código evoluciona, desincronización total. -![Enfoque tradicional vs Sinra](/assets/images/blog/2025-12-24-documentation-morte-traditional-vs-sinra.svg) +Enfoque tradicional vs Sinra --- @@ -546,7 +546,7 @@ Desarrollador busca: "OAuth2 refresh tokens" **Con Notion + GitHub + Jira separados:** 30 minutos (3 búsquedas en 3 herramientas). -![Búsqueda siloed vs búsqueda unificada](/assets/images/blog/2025-12-24-documentation-morte-search-comparison.svg) +Búsqueda siloed vs búsqueda unificada --- @@ -606,7 +606,7 @@ Nuevo desarrollador implementa feature "Exportar CSV" basándose en spec de Noti **Cita Product Manager:** > "Se acabaron las 6 versiones contradictorias de una spec. Tenemos una capability con descripción + commentary. Es LA fuente de verdad. Si cambia, actualizamos la capability. Simple." -![DataFlow: Antes vs Después de Sinra](/assets/images/blog/2025-12-24-documentation-morte-before-after.svg) +DataFlow: Antes vs Después de Sinra --- diff --git a/_posts/2025-12-24-documentation-morte-notion-confluence.fr.md b/_posts/2025-12-24-documentation-morte-notion-confluence.fr.md index 9da8768..b3d1ac8 100644 --- a/_posts/2025-12-24-documentation-morte-notion-confluence.fr.md +++ b/_posts/2025-12-24-documentation-morte-notion-confluence.fr.md @@ -82,7 +82,7 @@ Lead Dev : « Euh... bonne question. Peut-être le 'Auth System Overview' ? Ou l **Résultat :** Alex a passé 2 heures à lire de la documentation obsolète pour finalement apprendre en lisant le code. -![Versions multiples : Personne ne sait laquelle est correcte](/assets/images/blog/2025-12-24-documentation-morte-multiple-versions.svg) +Versions multiples : Personne ne sait laquelle est correcte --- @@ -118,7 +118,7 @@ Vous écrivez une magnifique spec technique dans Notion il y a 6 mois. Le code **Résultat Réel :** Une étude interne chez une scale-up tech de 50 personnes a révélé que **73% de leur documentation Confluence avait plus de 6 mois et ne correspondait plus au code actuel**. -![Chronologie de l'obsolescence de la documentation sur 6 mois](/assets/images/blog/2025-12-24-documentation-morte-obsolescence-timeline.svg) +Chronologie de l'obsolescence de la documentation sur 6 mois --- @@ -300,7 +300,7 @@ Informations dispersées entre : Personne ne sait où chercher. Personne ne sait quelle info est correcte. Chacun maintient sa propre version mentale de « comment ça marche vraiment ». -![Documentation dispersée entre 6 outils](/assets/images/blog/2025-12-24-documentation-morte-scattered-tools.svg) +Documentation dispersée entre 6 outils --- @@ -366,7 +366,7 @@ Reprenons l'exemple de l'authentification. **Résultat :** Doc Notion figée, code évolue, désynchronisation totale. -![Approche traditionnelle vs Sinra](/assets/images/blog/2025-12-24-documentation-morte-traditional-vs-sinra.svg) +Approche traditionnelle vs Sinra --- @@ -546,7 +546,7 @@ Développeur cherche : « OAuth2 refresh tokens » **Avec Notion + GitHub + Jira séparés :** 30 minutes (3 recherches dans 3 outils). -![Recherche silotée vs recherche unifiée](/assets/images/blog/2025-12-24-documentation-morte-search-comparison.svg) +Recherche silotée vs recherche unifiée --- @@ -606,7 +606,7 @@ Nouveau développeur implémente feature « Export CSV » basé sur spec Notion **Citation Product Manager :** > « Fini les 6 versions contradictoires d'une spec. On a une capability avec description + commentary. C'est LA source de vérité. Si ça change, on met à jour la capability. Simple. » -![DataFlow : Avant vs Après Sinra](/assets/images/blog/2025-12-24-documentation-morte-before-after.svg) +DataFlow : Avant vs Après Sinra --- diff --git a/_posts/2025-12-26-chaos-backlog-personne-sait-q2.en.md b/_posts/2025-12-26-chaos-backlog-personne-sait-q2.en.md index 6c9c5db..cedbbd7 100644 --- a/_posts/2025-12-26-chaos-backlog-personne-sait-q2.en.md +++ b/_posts/2025-12-26-chaos-backlog-personne-sait-q2.en.md @@ -68,7 +68,7 @@ PM: "We'll... clean up the backlog this week and get back to you." **Spoiler:** The backlog will never really be sorted. The chaos will continue. -![Infinite backlog growth over 2 years](/assets/images/blog/2025-12-26-chaos-backlog-infinite-growth.svg) +Infinite backlog growth over 2 years --- @@ -114,7 +114,7 @@ In a survey of 150 tech teams: **Result:** The backlog is a graveyard of dead ideas that nobody dares to delete. -![Infinite backlog growth over 2 years](/assets/images/blog/2025-12-26-chaos-backlog-infinite-growth.svg) +Infinite backlog growth over 2 years --- @@ -210,7 +210,7 @@ Team analyzed over 1 month: **Result:** "Urgent" becomes noise. The team ignores urgent requests because they change too fast. -![Changing priorities: A typical week](/assets/images/blog/2025-12-26-chaos-backlog-priority-chaos.svg) +Changing priorities: A typical week --- @@ -251,7 +251,7 @@ Nobody remembers the blocked issue. **Result:** Blocked issues die slowly, without anyone noticing. -![38 blocked issues forgotten](/assets/images/blog/2025-12-26-chaos-backlog-blocked-forgotten.svg) +38 blocked issues forgotten --- @@ -337,7 +337,7 @@ Because a flat list doesn't reflect the reality of work: **Result:** Everything becomes a soup of disconnected issues. -![Flat backlog vs structured releases](/assets/images/blog/2025-12-26-chaos-backlog-flat-vs-structured.svg) +Flat backlog vs structured releases --- @@ -488,7 +488,7 @@ Instead of a list of 94 issues, **8 clear capabilities**: **Total:** 10 weeks → **Perfectly aligned with real capacity**. -![Capacity planning: Reality vs Hope](/assets/images/blog/2025-12-26-chaos-backlog-capacity-planning.svg) +Capacity planning: Reality vs Hope **Step 3:** Create issues under each capability @@ -758,7 +758,7 @@ June 28, 2025 **Product Manager Quote:** > "I can finally answer the CEO when he asks 'what are we shipping in Q2'. Before, I'd stammer. Now I show him the release with 6 clear capabilities. He's delighted." -![Vertigo: Before vs After Sinra](/assets/images/blog/2025-12-26-chaos-backlog-vertigo-before-after.svg) +Vertigo: Before vs After Sinra --- diff --git a/_posts/2025-12-26-chaos-backlog-personne-sait-q2.es.md b/_posts/2025-12-26-chaos-backlog-personne-sait-q2.es.md index 570d03e..379a643 100644 --- a/_posts/2025-12-26-chaos-backlog-personne-sait-q2.es.md +++ b/_posts/2025-12-26-chaos-backlog-personne-sait-q2.es.md @@ -68,7 +68,7 @@ PM: "Vamos a... limpiar el backlog esta semana y te respondemos." **Spoiler:** El backlog nunca será realmente ordenado. El caos continuará. -![Crecimiento infinito del backlog en 2 años](/assets/images/blog/2025-12-26-chaos-backlog-infinite-growth.svg) +Crecimiento infinito del backlog en 2 años --- @@ -114,7 +114,7 @@ En una encuesta a 150 equipos tech: **Resultado:** El backlog es un cementerio de ideas muertas que nadie se atreve a eliminar. -![Crecimiento infinito del backlog en 2 años](/assets/images/blog/2025-12-26-chaos-backlog-infinite-growth.svg) +Crecimiento infinito del backlog en 2 años --- @@ -210,7 +210,7 @@ Equipo analizado durante 1 mes: **Resultado:** "Urgente" se convierte en ruido. El equipo ignora las solicitudes urgentes porque cambian demasiado rápido. -![Prioridades cambiantes: Una semana típica](/assets/images/blog/2025-12-26-chaos-backlog-priority-chaos.svg) +Prioridades cambiantes: Una semana típica --- @@ -251,7 +251,7 @@ Nadie recuerda la issue bloqueada. **Resultado:** Las issues bloqueadas mueren lentamente, sin que nadie se dé cuenta. -![38 issues bloqueadas olvidadas](/assets/images/blog/2025-12-26-chaos-backlog-blocked-forgotten.svg) +38 issues bloqueadas olvidadas --- @@ -337,7 +337,7 @@ Porque una lista plana no refleja la realidad del trabajo: **Resultado:** Todo se convierte en una sopa de issues desconectadas. -![Backlog plano vs estructura por releases](/assets/images/blog/2025-12-26-chaos-backlog-flat-vs-structured.svg) +Backlog plano vs estructura por releases --- @@ -488,7 +488,7 @@ En lugar de una lista de 94 issues, **8 capabilities claras**: **Total:** 10 semanas → **Perfectamente alineado con capacidad real**. -![Planificación de capacidad: Realidad vs Esperanza](/assets/images/blog/2025-12-26-chaos-backlog-capacity-planning.svg) +Planificación de capacidad: Realidad vs Esperanza **Paso 3:** Crear issues bajo cada capability @@ -758,7 +758,7 @@ Buffer: 2 semanas **Cita Product Manager:** > "Finalmente puedo responder al CEO cuando pregunta 'qué entregamos en Q2'. Antes, balbuceba. Ahora le muestro el release con 6 capabilities claras. Está encantado." -![Vertigo: Antes vs Después de Sinra](/assets/images/blog/2025-12-26-chaos-backlog-vertigo-before-after.svg) +Vertigo: Antes vs Después de Sinra --- diff --git a/_posts/2025-12-26-chaos-backlog-personne-sait-q2.fr.md b/_posts/2025-12-26-chaos-backlog-personne-sait-q2.fr.md index 22c98f4..3ba9427 100644 --- a/_posts/2025-12-26-chaos-backlog-personne-sait-q2.fr.md +++ b/_posts/2025-12-26-chaos-backlog-personne-sait-q2.fr.md @@ -112,7 +112,7 @@ Dans une enquête auprès de 150 équipes tech : **Résultat :** Le backlog est un cimetière d'idées mortes que personne n'ose supprimer. -![Croissance infinie du backlog sur 2 ans](/assets/images/blog/2025-12-26-chaos-backlog-infinite-growth.svg) +Croissance infinie du backlog sur 2 ans --- @@ -208,7 +208,7 @@ PM : « Oui, mais... tout est urgent. » **Résultat :** « Urgent » devient du bruit. L'équipe ignore les demandes urgentes parce qu'elles changent trop vite. -![Priorités changeantes : Une semaine typique](/assets/images/blog/2025-12-26-chaos-backlog-priority-chaos.svg) +Priorités changeantes : Une semaine typique --- @@ -249,7 +249,7 @@ Personne ne se souvient de l'issue bloquée. **Résultat :** Les issues bloquées meurent lentement, sans que personne ne s'en rende compte. -![38 issues bloquées oubliées](/assets/images/blog/2025-12-26-chaos-backlog-blocked-forgotten.svg) +38 issues bloquées oubliées --- @@ -335,7 +335,7 @@ Parce qu'une liste plate ne reflète pas la réalité du travail : **Résultat :** Tout devient une soupe d'issues déconnectées. -![Backlog plat vs structure par releases](/assets/images/blog/2025-12-26-chaos-backlog-flat-vs-structured.svg) +Backlog plat vs structure par releases --- @@ -486,7 +486,7 @@ Au lieu d'une liste de 94 issues, **8 capabilities claires** : **Total :** 10 semaines → **Parfaitement aligné avec capacité réelle**. -![Planification de capacité : Réalité vs Espoir](/assets/images/blog/2025-12-26-chaos-backlog-capacity-planning.svg) +Planification de capacité : Réalité vs Espoir **Étape 3 :** Créer issues sous chaque capability @@ -756,7 +756,7 @@ Buffer : 2 semaines **Citation Product Manager :** > « Je peux enfin répondre au CEO quand il demande 'qu'est-ce qu'on livre en Q2'. Avant, je bafouillais. Maintenant, je lui montre la release avec 6 capabilities claires. Il est ravi. » -![Vertigo : Avant vs Après Sinra](/assets/images/blog/2025-12-26-chaos-backlog-vertigo-before-after.svg) +Vertigo : Avant vs Après Sinra --- diff --git a/_posts/2025-12-28-dependances-cachees-features-bloquees.en.md b/_posts/2025-12-28-dependances-cachees-features-bloquees.en.md index 4c228de..a4aa67c 100644 --- a/_posts/2025-12-28-dependances-cachees-features-bloquees.en.md +++ b/_posts/2025-12-28-dependances-cachees-features-bloquees.en.md @@ -63,7 +63,7 @@ CTO: "Ah. Nobody explained the context. OK, approved. It'll take 2 days to provi - **Real time needed after unblocking:** 4 days - **Time wasted due to hidden dependencies:** 17 days -![Timeline: feature blocked 3 weeks, but only 4 days of real work](/assets/images/blog/2025-12-28-dependances-cachees-blocked-timeline.svg) +Timeline: feature blocked 3 weeks, but only 4 days of real work --- @@ -138,7 +138,7 @@ Feature: **"Mobile push notifications"** Mobile → Backend → Infra (Redis) → Infra (Firebase) → Security → Mobile (APNs) -![Progressive discovery of dependency chain over 23 days](/assets/images/blog/2025-12-28-dependances-cachees-chain-progressive.svg) +Progressive discovery of dependency chain over 23 days **The Problem:** - ❌ Chain discovered progressively (not anticipated) @@ -192,7 +192,7 @@ Frontend completes the integration. - **Real time needed with clear coordination:** 1.5 weeks - **Time wasted due to poor coordination:** 2.5 weeks -![Teams waiting for each other: total deadlock](/assets/images/blog/2025-12-28-dependances-cachees-teams-waiting.svg) +Teams waiting for each other: total deadlock **The Problem:** - ❌ Contradictory assumptions (everyone thinks the other is doing the work) @@ -509,7 +509,7 @@ Blocks: [INFRA-567] S3 Bucket **Gain:** 11 days saved thanks to anticipation. -![Comparison: traditional approach (17 days) vs Sinra (6 days)](/assets/images/blog/2025-12-28-dependances-cachees-traditional-vs-sinra.svg) +Comparison: traditional approach (17 days) vs Sinra (6 days) --- @@ -563,7 +563,7 @@ Q2 Release - Ping CTO to unblock Feature B - Follow up with design to unblock Feature D -![Complete graphical view of dependencies in Sinra](/assets/images/blog/2025-12-28-dependances-cachees-dependency-graph.svg) +Complete graphical view of dependencies in Sinra **Benefit:** No hidden dependencies. Everyone sees the blockers. @@ -713,7 +713,7 @@ Frontend integrates in 2 days. **Product Manager Quote:** > "Releases don't slip anymore. We know exactly which features have dependencies, and we unblock them proactively. No more surprises 5 days before release." -![Quantum: metrics before/after Sinra](/assets/images/blog/2025-12-28-dependances-cachees-quantum-before-after.svg) +Quantum: metrics before/after Sinra --- diff --git a/_posts/2025-12-28-dependances-cachees-features-bloquees.es.md b/_posts/2025-12-28-dependances-cachees-features-bloquees.es.md index 6db11e1..51d71e2 100644 --- a/_posts/2025-12-28-dependances-cachees-features-bloquees.es.md +++ b/_posts/2025-12-28-dependances-cachees-features-bloquees.es.md @@ -63,7 +63,7 @@ CTO: "Ah. Nadie me explicó el contexto. OK, aprobado. Tardará 2 días en provi - **Tiempo real necesario tras desbloqueo:** 4 días - **Tiempo perdido por dependencias ocultas:** 17 días -![Cronología: feature bloqueada 3 semanas, pero solo 4 días de trabajo real](/assets/images/blog/2025-12-28-dependances-cachees-blocked-timeline.svg) +Cronología: feature bloqueada 3 semanas, pero solo 4 días de trabajo real --- @@ -138,7 +138,7 @@ Feature: **"Notificaciones push móviles"** Móvil → Backend → Infra (Redis) → Infra (Firebase) → Seguridad → Móvil (APNs) -![Descubrimiento progresivo de la cadena de dependencias durante 23 días](/assets/images/blog/2025-12-28-dependances-cachees-chain-progressive.svg) +Descubrimiento progresivo de la cadena de dependencias durante 23 días **El Problema:** - ❌ Cadena descubierta progresivamente (no anticipada) @@ -192,7 +192,7 @@ Frontend completa la integración. - **Tiempo real necesario con coordinación clara:** 1.5 semanas - **Tiempo perdido por mala coordinación:** 2.5 semanas -![Equipos que se esperan mutuamente: deadlock total](/assets/images/blog/2025-12-28-dependances-cachees-teams-waiting.svg) +Equipos que se esperan mutuamente: deadlock total **El Problema:** - ❌ Suposiciones contradictorias (cada uno piensa que el otro hace el trabajo) @@ -509,7 +509,7 @@ Bloquea: [INFRA-567] Bucket S3 **Ganancia:** 11 días ahorrados gracias a la anticipación. -![Comparación: enfoque tradicional (17 días) vs Sinra (6 días)](/assets/images/blog/2025-12-28-dependances-cachees-traditional-vs-sinra.svg) +Comparación: enfoque tradicional (17 días) vs Sinra (6 días) --- @@ -563,7 +563,7 @@ Release Q2 - Contactar CTO para desbloquear Feature B - Hacer seguimiento con diseño para desbloquear Feature D -![Vista gráfica completa de dependencias en Sinra](/assets/images/blog/2025-12-28-dependances-cachees-dependency-graph.svg) +Vista gráfica completa de dependencias en Sinra **Beneficio:** Sin dependencias ocultas. Todo el mundo ve los bloqueos. @@ -713,7 +713,7 @@ Frontend integra en 2 días. **Cita Product Manager:** > "Los releases ya no se retrasan. Sabemos exactamente qué features tienen dependencias, y las desbloqueamos proactivamente. Se acabaron las sorpresas 5 días antes del release." -![Quantum: métricas antes/después de Sinra](/assets/images/blog/2025-12-28-dependances-cachees-quantum-before-after.svg) +Quantum: métricas antes/después de Sinra --- diff --git a/_posts/2025-12-28-dependances-cachees-features-bloquees.fr.md b/_posts/2025-12-28-dependances-cachees-features-bloquees.fr.md index 1c00521..71ab32d 100644 --- a/_posts/2025-12-28-dependances-cachees-features-bloquees.fr.md +++ b/_posts/2025-12-28-dependances-cachees-features-bloquees.fr.md @@ -63,7 +63,7 @@ CTO : « Ah. Personne ne m'a expliqué le contexte. OK, approuvé. Ça prendra 2 - **Temps réel nécessaire après déblocage :** 4 jours - **Temps perdu à cause de dépendances cachées :** 17 jours -![Chronologie : feature bloquée 3 semaines, mais seulement 4 jours de travail réel](/assets/images/blog/2025-12-28-dependances-cachees-blocked-timeline.svg) +Chronologie : feature bloquée 3 semaines, mais seulement 4 jours de travail réel --- @@ -138,7 +138,7 @@ Feature : **« Notifications push mobiles »** Mobile → Backend → Infra (Redis) → Infra (Firebase) → Sécurité → Mobile (APNs) -![Découverte progressive de la chaîne de dépendances sur 23 jours](/assets/images/blog/2025-12-28-dependances-cachees-chain-progressive.svg) +Découverte progressive de la chaîne de dépendances sur 23 jours **Le Problème :** - ❌ Chaîne découverte progressivement (pas anticipée) @@ -192,7 +192,7 @@ Frontend termine l'intégration. - **Temps réel nécessaire si coordination claire :** 1.5 semaines - **Temps perdu à cause de mauvaise coordination :** 2.5 semaines -![Équipes qui s'attendent mutuellement : deadlock total](/assets/images/blog/2025-12-28-dependances-cachees-teams-waiting.svg) +Équipes qui s'attendent mutuellement : deadlock total **Le Problème :** - ❌ Assumptions contradictoires (chacun pense que l'autre fait le travail) @@ -509,7 +509,7 @@ Bloque : [INFRA-567] Bucket S3 **Gain :** 11 jours économisés grâce à l'anticipation. -![Comparaison : approche traditionnelle (17 jours) vs Sinra (6 jours)](/assets/images/blog/2025-12-28-dependances-cachees-traditional-vs-sinra.svg) +Comparaison : approche traditionnelle (17 jours) vs Sinra (6 jours) --- @@ -563,7 +563,7 @@ Release Q2 - Pinger CTO pour débloquer Feature B - Relancer design pour débloquer Feature D -![Vue graphique complète des dépendances dans Sinra](/assets/images/blog/2025-12-28-dependances-cachees-dependency-graph.svg) +Vue graphique complète des dépendances dans Sinra **Bénéfice :** Pas de dépendances cachées. Tout le monde voit les blocages. @@ -713,7 +713,7 @@ Frontend intègre en 2 jours. **Citation Product Manager :** > « Les releases ne glissent plus. On sait exactement quelles features ont des dépendances, et on les débloque proactivement. Fini les surprises à J-5 de la release. » -![Quantum : métriques avant/après Sinra](/assets/images/blog/2025-12-28-dependances-cachees-quantum-before-after.svg) +Quantum : métriques avant/après Sinra --- diff --git a/_posts/2025-12-30-syndrome-multi-projet-rien-navance.en.md b/_posts/2025-12-30-syndrome-multi-projet-rien-navance.en.md index 40f339f..af7cfb5 100644 --- a/_posts/2025-12-30-syndrome-multi-projet-rien-navance.en.md +++ b/_posts/2025-12-30-syndrome-multi-projet-rien-navance.en.md @@ -53,7 +53,7 @@ Manager: "OK. I'll look into that." Manager: "Shit." -![Dev 1 assigned to 4 simultaneous projects with 180% overallocation](/assets/images/blog/2025-12-30-syndrome-multi-projet-developer-overload.svg) +Dev 1 assigned to 4 simultaneous projects with 180% overallocation --- @@ -100,7 +100,7 @@ Team of 8 developers. 6 active projects. **No project finished.** -![6 active projects, none finished after 4 weeks](/assets/images/blog/2025-12-30-syndrome-multi-projet-nothing-finishes.svg) +6 active projects, none finished after 4 weeks **The Problem:** - ❌ Developers fragmented across multiple projects @@ -158,7 +158,7 @@ Your developer spends their day switching between 3, 4 different projects. Resul **5:00 PM:** End of day. Dev 1 realizes they've **finished nothing**. -![Typical day with 6 context switches and 60% time lost](/assets/images/blog/2025-12-30-syndrome-multi-projet-context-switching.svg) +Typical day with 6 context switches and 60% time lost **The Problem:** - ❌ 5-6 context switches per day @@ -174,7 +174,7 @@ Research (Gerald Weinberg, *Quality Software Management*): - **3 projects:** 20% productivity per project (40% lost in switching) - **4+ projects:** <10% productivity per project (60%+ lost in switching) -![Productivity loss by number of projects](/assets/images/blog/2025-12-30-syndrome-multi-projet-productivity-loss.svg) +Productivity loss by number of projects **Result:** Context switching destroys productivity. @@ -565,7 +565,7 @@ Dev 5: 3 projects (Project B, D, E) 🚨 Overallocated - Remove Dev 3 from 2 projects - Remove Dev 5 from 1 project -![Sinra allocation view with overload alerts](/assets/images/blog/2025-12-30-syndrome-multi-projet-allocation-view.svg) +Sinra allocation view with overload alerts **Benefit:** Impossible not to see the overload. @@ -695,7 +695,7 @@ Each project now has **full-time** developers. **Product Manager Quote:** > "Projects finally get finished. Before, everything was late. Now, we deliver on time. The difference? Each dev is focused on a single project." -![Nexus: metrics before/after Sinra](/assets/images/blog/2025-12-30-syndrome-multi-projet-nexus-before-after.svg) +Nexus: metrics before/after Sinra --- diff --git a/_posts/2025-12-30-syndrome-multi-projet-rien-navance.es.md b/_posts/2025-12-30-syndrome-multi-projet-rien-navance.es.md index aff2e94..8b6e5b3 100644 --- a/_posts/2025-12-30-syndrome-multi-projet-rien-navance.es.md +++ b/_posts/2025-12-30-syndrome-multi-projet-rien-navance.es.md @@ -53,7 +53,7 @@ Manager: "OK. Voy a mirar eso." Manager: "Mierda." -![Dev 1 asignado a 4 proyectos simultáneos con sobreasignación 180%](/assets/images/blog/2025-12-30-syndrome-multi-projet-developer-overload.svg) +Dev 1 asignado a 4 proyectos simultáneos con sobreasignación 180% --- @@ -100,7 +100,7 @@ Equipo de 8 desarrolladores. 6 proyectos activos. **Ningún proyecto terminado.** -![6 proyectos activos, ninguno terminado tras 4 semanas](/assets/images/blog/2025-12-30-syndrome-multi-projet-nothing-finishes.svg) +6 proyectos activos, ninguno terminado tras 4 semanas **El Problema:** - ❌ Desarrolladores fragmentados en múltiples proyectos @@ -158,7 +158,7 @@ Tu desarrollador pasa su día cambiando entre 3, 4 proyectos diferentes. Resulta **17:00:** Fin del día. Dev 1 se da cuenta de que no ha **terminado nada**. -![Día típico con 6 context switches y 60% tiempo perdido](/assets/images/blog/2025-12-30-syndrome-multi-projet-context-switching.svg) +Día típico con 6 context switches y 60% tiempo perdido **El Problema:** - ❌ 5-6 context switches al día @@ -174,7 +174,7 @@ Investigación (Gerald Weinberg, *Quality Software Management*): - **3 proyectos:** 20% productividad por proyecto (40% perdido en switching) - **4+ proyectos:** <10% productividad por proyecto (60%+ perdido en switching) -![Pérdida de productividad según número de proyectos](/assets/images/blog/2025-12-30-syndrome-multi-projet-productivity-loss.svg) +Pérdida de productividad según número de proyectos **Resultado:** El context switching destruye la productividad. @@ -565,7 +565,7 @@ Dev 5: 3 proyectos (Proyecto B, D, E) 🚨 Sobreasignado - Quitar Dev 3 de 2 proyectos - Quitar Dev 5 de 1 proyecto -![Vista asignación Sinra con alertas de sobrecarga](/assets/images/blog/2025-12-30-syndrome-multi-projet-allocation-view.svg) +Vista asignación Sinra con alertas de sobrecarga **Beneficio:** Imposible no ver la sobrecarga. @@ -695,7 +695,7 @@ Cada proyecto ahora tiene desarrolladores **a tiempo completo**. **Cita Product Manager:** > "Los proyectos finalmente se terminan. Antes, todo estaba retrasado. Ahora, entregamos a tiempo. ¿La diferencia? Cada dev está enfocado en un solo proyecto." -![Nexus: métricas antes/después de Sinra](/assets/images/blog/2025-12-30-syndrome-multi-projet-nexus-before-after.svg) +Nexus: métricas antes/después de Sinra --- diff --git a/_posts/2025-12-30-syndrome-multi-projet-rien-navance.fr.md b/_posts/2025-12-30-syndrome-multi-projet-rien-navance.fr.md index dfaa9b4..c8f37c5 100644 --- a/_posts/2025-12-30-syndrome-multi-projet-rien-navance.fr.md +++ b/_posts/2025-12-30-syndrome-multi-projet-rien-navance.fr.md @@ -53,7 +53,7 @@ Manager : « OK. Je vais regarder ça. » Manager : « Merde. » -![Dev 1 assigné sur 4 projets simultanés avec surallocation 180%](/assets/images/blog/2025-12-30-syndrome-multi-projet-developer-overload.svg) +Dev 1 assigné sur 4 projets simultanés avec surallocation 180% --- @@ -100,7 +100,7 @@ Vous avez 5 projets actifs. Chaque développeur travaille sur 2, 3, 4 projets en **Aucun projet terminé.** -![6 projets actifs, aucun terminé après 4 semaines](/assets/images/blog/2025-12-30-syndrome-multi-projet-nothing-finishes.svg) +6 projets actifs, aucun terminé après 4 semaines **Le Problème :** - ❌ Développeurs fragmentés sur plusieurs projets @@ -158,7 +158,7 @@ Votre développeur passe sa journée à switcher entre 3, 4 projets différents. **17h00 :** Fin de journée. Dev 1 réalise qu'il n'a **rien terminé**. -![Journée typique avec 6 context switches et 60% du temps perdu](/assets/images/blog/2025-12-30-syndrome-multi-projet-context-switching.svg) +Journée typique avec 6 context switches et 60% du temps perdu **Le Problème :** - ❌ 5-6 context switches par jour @@ -174,7 +174,7 @@ Recherche (Gerald Weinberg, *Quality Software Management*) : - **3 projets :** 20% de productivité par projet (40% perdu en switching) - **4+ projets :** <10% de productivité par projet (60%+ perdu en switching) -![Perte de productivité selon le nombre de projets](/assets/images/blog/2025-12-30-syndrome-multi-projet-productivity-loss.svg) +Perte de productivité selon le nombre de projets **Résultat :** Le context switching détruit la productivité. @@ -565,7 +565,7 @@ Dev 5 : 3 projets (Projet B, D, E) 🚨 Suralloué - Retirer Dev 3 de 2 projets - Retirer Dev 5 de 1 projet -![Vue allocation Sinra avec alertes de surcharge](/assets/images/blog/2025-12-30-syndrome-multi-projet-allocation-view.svg) +Vue allocation Sinra avec alertes de surcharge **Bénéfice :** Impossible de ne pas voir la surcharge. @@ -695,7 +695,7 @@ Chaque projet a maintenant des développeurs **à temps plein**. **Citation Product Manager :** > « Les projets se terminent enfin. Avant, tout était en retard. Maintenant, on livre à temps. La différence ? Chaque dev est focalisé sur un seul projet. » -![Nexus : métriques avant/après Sinra](/assets/images/blog/2025-12-30-syndrome-multi-projet-nexus-before-after.svg) +Nexus : métriques avant/après Sinra --- diff --git a/_posts/2026-01-02-fausse-promesse-user-stories-en-tant-que.en.md b/_posts/2026-01-02-fausse-promesse-user-stories-en-tant-que.en.md index 0d9e73b..870e488 100644 --- a/_posts/2026-01-02-fausse-promesse-user-stories-en-tant-que.en.md +++ b/_posts/2026-01-02-fausse-promesse-user-stories-en-tant-que.en.md @@ -73,7 +73,7 @@ Dev 1 (aside): "The story said 'As a user, I want to log out'. But it didn't say Dev 2: "Welcome to the world of user stories." -![Vague user story generating 45 minutes of questions](/assets/images/blog/2026-01-02-user-stories-vague-meeting.svg) +Vague user story generating 45 minutes of questions --- @@ -128,7 +128,7 @@ Dev: "OK... but concretely, what do I do?" **Result:** 3 clarification meetings before being able to start coding. -![User story generating 15 unanswered questions](/assets/images/blog/2026-01-02-user-stories-questions-unanswered.svg) +User story generating 15 unanswered questions **The Problem:** - ❌ User story describes the "what" (user need) @@ -190,7 +190,7 @@ Your team spends 4 hours per week in "backlog grooming" to transform vague user **The team is exhausted.** -![4 hours of grooming for 8 user stories](/assets/images/blog/2026-01-02-user-stories-grooming-marathon.svg) +4 hours of grooming for 8 user stories **The Problem:** - ❌ 4h of grooming per week (20% of team time) @@ -261,7 +261,7 @@ to be informed of new messages. **Gap between the story (2 lines) and the real implementation (50+ tasks).** -![User story 2 lines vs 50 real tasks](/assets/images/blog/2026-01-02-user-stories-gap-reality.svg) +User story 2 lines vs 50 real tasks **The Problem:** - ❌ User story: 2 vague lines @@ -345,7 +345,7 @@ PO: "Let's add debounce then." **But the team spent 3 grooming sessions (3h total) on this single story.** -![Story re-groomed 3 times before being developable](/assets/images/blog/2026-01-02-user-stories-regrooming-loop.svg) +Story re-groomed 3 times before being developable **The Problem:** - ❌ Story created too vague @@ -416,7 +416,7 @@ Dev: "..." **2 days of development to redo.** -![Developer guesses, codes 2 days, everything needs to be redone](/assets/images/blog/2026-01-02-user-stories-developer-guesses.svg) +Developer guesses, codes 2 days, everything needs to be redone **The Problem:** - ❌ Story too vague @@ -745,7 +745,7 @@ Release: Q1 2026 - ✅ No questions - ✅ Code directly -![Vague user story vs detailed Sinra issue](/assets/images/blog/2026-01-02-user-stories-vs-sinra-issue.svg) +Vague user story vs detailed Sinra issue --- @@ -804,7 +804,7 @@ Sinra uses **capabilities** to group related issues. - See the "big picture" (capability) - Work on clear tasks (issues) -![Capability grouping 5 actionable issues](/assets/images/blog/2026-01-02-user-stories-capability-breakdown.svg) +Capability grouping 5 actionable issues --- @@ -950,7 +950,7 @@ Assigned: Dev 3 **Product Manager quote:** > "At first, I found it tedious to write detailed issues. Then I realized: I was spending the same time in grooming answering questions. Now, I document once, clearly, and the team develops without questions." -![Lumio: before/after Sinra metrics](/assets/images/blog/2026-01-02-user-stories-lumio-before-after.svg) +Lumio: before/after Sinra metrics --- diff --git a/_posts/2026-01-02-fausse-promesse-user-stories-en-tant-que.es.md b/_posts/2026-01-02-fausse-promesse-user-stories-en-tant-que.es.md index 68133e4..77c277b 100644 --- a/_posts/2026-01-02-fausse-promesse-user-stories-en-tant-que.es.md +++ b/_posts/2026-01-02-fausse-promesse-user-stories-en-tant-que.es.md @@ -73,7 +73,7 @@ Dev 1 (aparte): « La story decía "Como usuario, quiero desconectarme". Pero no Dev 2: « Bienvenido al mundo de las user stories. » -![User story vaga generando 45 minutos de preguntas](/assets/images/blog/2026-01-02-user-stories-vague-meeting.svg) +User story vaga generando 45 minutos de preguntas --- @@ -128,7 +128,7 @@ Dev: « OK... pero concretamente, ¿qué hago? » **Resultado:** 3 reuniones de aclaración antes de poder empezar a codificar. -![User story generando 15 preguntas sin respuestas](/assets/images/blog/2026-01-02-user-stories-questions-unanswered.svg) +User story generando 15 preguntas sin respuestas **El Problema:** - ❌ User story describe el « qué » (necesidad del usuario) @@ -190,7 +190,7 @@ Tu equipo pasa 4 horas por semana en « backlog grooming » para transformar las **El equipo está agotado.** -![4 horas de grooming para 8 user stories](/assets/images/blog/2026-01-02-user-stories-grooming-marathon.svg) +4 horas de grooming para 8 user stories **El Problema:** - ❌ 4h de grooming por semana (20% del tiempo del equipo) @@ -261,7 +261,7 @@ para estar informado de los nuevos mensajes. **Brecha entre la story (2 líneas) y la implementación real (50+ tareas).** -![User story 2 líneas vs 50 tareas reales](/assets/images/blog/2026-01-02-user-stories-gap-reality.svg) +User story 2 líneas vs 50 tareas reales **El Problema:** - ❌ User story: 2 líneas vagas @@ -345,7 +345,7 @@ PO: « Pongamos un debounce entonces. » **Pero el equipo pasó 3 sesiones de grooming (3h en total) en esta única story.** -![Story re-groomeada 3 veces antes de ser desarrollable](/assets/images/blog/2026-01-02-user-stories-regrooming-loop.svg) +Story re-groomeada 3 veces antes de ser desarrollable **El Problema:** - ❌ Story creada demasiado vaga @@ -416,7 +416,7 @@ Dev: « ... » **2 días de desarrollo para rehacer.** -![Desarrollador adivina, codifica 2 días, todo está por rehacer](/assets/images/blog/2026-01-02-user-stories-developer-guesses.svg) +Desarrollador adivina, codifica 2 días, todo está por rehacer **El Problema:** - ❌ Story demasiado vaga @@ -745,7 +745,7 @@ Release: Q1 2026 - ✅ Sin preguntas - ✅ Codificar directamente -![User story vaga vs issue Sinra detallada](/assets/images/blog/2026-01-02-user-stories-vs-sinra-issue.svg) +User story vaga vs issue Sinra detallada --- @@ -804,7 +804,7 @@ Sinra usa **capabilities** para agrupar issues relacionadas. - Ver el « big picture » (capability) - Trabajar en tareas claras (issues) -![Capability agrupando 5 issues accionables](/assets/images/blog/2026-01-02-user-stories-capability-breakdown.svg) +Capability agrupando 5 issues accionables --- @@ -950,7 +950,7 @@ Asignado: Dev 3 **Cita de Product Manager:** > « Al principio, encontré tedioso escribir issues detalladas. Luego me di cuenta: pasaba el mismo tiempo en grooming respondiendo preguntas. Ahora, documento una vez, claramente, y el equipo desarrolla sin preguntas. » -![Lumio: métricas antes/después Sinra](/assets/images/blog/2026-01-02-user-stories-lumio-before-after.svg) +Lumio: métricas antes/después Sinra --- diff --git a/_posts/2026-01-02-fausse-promesse-user-stories-en-tant-que.fr.md b/_posts/2026-01-02-fausse-promesse-user-stories-en-tant-que.fr.md index 2736f30..c4d893c 100644 --- a/_posts/2026-01-02-fausse-promesse-user-stories-en-tant-que.fr.md +++ b/_posts/2026-01-02-fausse-promesse-user-stories-en-tant-que.fr.md @@ -73,7 +73,7 @@ Dev 1 (en aparté) : « La story disait « En tant qu'utilisateur, je veux me d Dev 2 : « Bienvenue dans le monde des user stories. » -![User story vague générant 45 minutes de questions](/assets/images/blog/2026-01-02-user-stories-vague-meeting.svg) +User story vague générant 45 minutes de questions --- @@ -128,7 +128,7 @@ Dev : « OK... mais concrètement, je fais quoi ? » **Résultat :** 3 réunions de clarification avant de pouvoir commencer à coder. -![User story générant 15 questions sans réponses](/assets/images/blog/2026-01-02-user-stories-questions-unanswered.svg) +User story générant 15 questions sans réponses **Le Problème :** - ❌ User story décrit le « quoi » (besoin utilisateur) @@ -190,7 +190,7 @@ Votre équipe passe 4 heures par semaine en « backlog grooming » pour transfor **L'équipe est épuisée.** -![4 heures de grooming pour 8 user stories](/assets/images/blog/2026-01-02-user-stories-grooming-marathon.svg) +4 heures de grooming pour 8 user stories **Le Problème :** - ❌ 4h de grooming par semaine (20% du temps de l'équipe) @@ -261,7 +261,7 @@ afin d'être informé des nouveaux messages. **Écart entre la story (2 lignes) et l'implémentation réelle (50+ tâches).** -![User story 2 lignes vs 50 tâches réelles](/assets/images/blog/2026-01-02-user-stories-gap-reality.svg) +User story 2 lignes vs 50 tâches réelles **Le Problème :** - ❌ User story : 2 lignes vagues @@ -345,7 +345,7 @@ PO : « On met un debounce alors. » **Mais l'équipe a passé 3 sessions de grooming (3h au total) sur cette seule story.** -![Story regroomée 3 fois avant d'être développable](/assets/images/blog/2026-01-02-user-stories-regrooming-loop.svg) +Story regroomée 3 fois avant d'être développable **Le Problème :** - ❌ Story créée trop vague @@ -416,7 +416,7 @@ Dev : « ... » **2 jours de développement à refaire.** -![Développeur devine, code 2 jours, tout est à refaire](/assets/images/blog/2026-01-02-user-stories-developer-guesses.svg) +Développeur devine, code 2 jours, tout est à refaire **Le Problème :** - ❌ Story trop vague @@ -745,7 +745,7 @@ Release : Q1 2026 - ✅ Pas de questions - ✅ Code directement -![User story vague vs issue Sinra détaillée](/assets/images/blog/2026-01-02-user-stories-vs-sinra-issue.svg) +User story vague vs issue Sinra détaillée --- @@ -804,7 +804,7 @@ Sinra utilise **capabilities** pour regrouper des issues liées. - Voir la « big picture » (capability) - Travailler sur des tâches claires (issues) -![Capability regroupant 5 issues actionnables](/assets/images/blog/2026-01-02-user-stories-capability-breakdown.svg) +Capability regroupant 5 issues actionnables --- @@ -950,7 +950,7 @@ Assigné : Dev 3 **Citation Product Manager :** > « Au début, j'ai trouvé fastidieux d'écrire des issues détaillées. Puis j'ai réalisé : je passais le même temps en grooming à répondre aux questions. Maintenant, je documente une fois, clairement, et l'équipe développe sans questions. » -![Lumio : métriques avant/après Sinra](/assets/images/blog/2026-01-02-user-stories-lumio-before-after.svg) +Lumio : métriques avant/après Sinra --- diff --git a/_posts/2026-01-13-hebergement-europeen-souverainete-donnees.en.md b/_posts/2026-01-13-hebergement-europeen-souverainete-donnees.en.md index 7cc8fdc..b21d31c 100644 --- a/_posts/2026-01-13-hebergement-europeen-souverainete-donnees.en.md +++ b/_posts/2026-01-13-hebergement-europeen-souverainete-donnees.en.md @@ -59,7 +59,7 @@ DPO: "Exactly." CTO: "We need to change hosts. Now." -![Data in Europe but accessible from the US](/assets/images/blog/2026-01-13-cloud-act-contradiction.svg) +Data in Europe but accessible from the US --- @@ -107,7 +107,7 @@ Amazon is **legally obligated** to comply with the Cloud Act, even if the data i **You have no control.** -![Cloud Act bypasses physical location](/assets/images/blog/2026-01-13-cloud-act-flow.svg) +Cloud Act bypasses physical location **The Problem:** - ❌ Data in Europe, but accessible to the US @@ -160,7 +160,7 @@ Using AWS, Google Cloud, or Azure with European personal data is **legally risky Several data protection authorities (CNIL in France, EDPB at European level) have warned that these transfers are not GDPR compliant. -![GDPR and Cloud Act incompatible](/assets/images/blog/2026-01-13-rgpd-cloud-act-conflict.svg) +GDPR and Cloud Act incompatible **The Problem:** - ❌ Impossible to be GDPR compliant with US host @@ -222,7 +222,7 @@ Your customers entrust you with: **You have lost control.** -![Loss of data sovereignty](/assets/images/blog/2026-01-13-sovereignty-loss.svg) +Loss of data sovereignty **The Problem:** - ❌ Data under foreign jurisdiction @@ -268,7 +268,7 @@ A B2B customer asks where their data is hosted. You answer "Europe". They insist **Deal lost.** -![Lost deal due to US hosting](/assets/images/blog/2026-01-13-deal-lost-hosting.svg) +Lost deal due to US hosting **The Problem:** - ❌ B2B clients demand data sovereignty @@ -467,7 +467,7 @@ Sinra made the choice of **data sovereignty** from the start. - SecNumCloud (ANSSI) = most demanding French standard - ISO 27001 = international security standard -![Sinra data hosted at OVH France](/assets/images/blog/2026-01-13-sinra-ovh-hosting.svg) +Sinra data hosted at OVH France **Quote from Thomas Milcent (Sinra founder):** > "From the start, we wanted our customers' data to remain in France. Not for marketing reasons, but because it's the right thing to do. OVH allows us to guarantee data sovereignty while having reliable and performant infrastructure." @@ -615,7 +615,7 @@ Tight budget. **Quote from TechCorp CTO:** > "Migrating to OVH was the best tech decision of the year. We saved €16k, won 2 big deals we would have lost, and we sleep better knowing our data is truly in France." -![TechCorp: metrics before/after OVH migration](/assets/images/blog/2026-01-13-techcorp-aws-ovh-migration.svg) +TechCorp: metrics before/after OVH migration --- diff --git a/_posts/2026-01-13-hebergement-europeen-souverainete-donnees.es.md b/_posts/2026-01-13-hebergement-europeen-souverainete-donnees.es.md index 81869d9..be0c269 100644 --- a/_posts/2026-01-13-hebergement-europeen-souverainete-donnees.es.md +++ b/_posts/2026-01-13-hebergement-europeen-souverainete-donnees.es.md @@ -59,7 +59,7 @@ DPO: «Exactamente.» CTO: «Tenemos que cambiar de proveedor. Ahora.» -![Datos en Europa pero accesibles desde EE.UU.](/assets/images/blog/2026-01-13-cloud-act-contradiction.svg) +Datos en Europa pero accesibles desde EE.UU. --- @@ -107,7 +107,7 @@ Amazon está **legalmente obligado** a cumplir con el Cloud Act, incluso si los **No tienes ningún control.** -![Cloud Act evita la ubicación física](/assets/images/blog/2026-01-13-cloud-act-flow.svg) +Cloud Act evita la ubicación física **El Problema:** - ❌ Datos en Europa, pero accesibles a EE.UU. @@ -160,7 +160,7 @@ Usar AWS, Google Cloud o Azure con datos personales europeos es **legalmente arr Varias autoridades de protección de datos (CNIL en Francia, EDPB a nivel europeo) han advertido que estas transferencias no cumplen con el RGPD. -![RGPD y Cloud Act incompatibles](/assets/images/blog/2026-01-13-rgpd-cloud-act-conflict.svg) +RGPD y Cloud Act incompatibles **El Problema:** - ❌ Imposible cumplir RGPD con proveedor de EE.UU. @@ -222,7 +222,7 @@ Tus clientes te confían: **Has perdido el control.** -![Pérdida de soberanía de datos](/assets/images/blog/2026-01-13-sovereignty-loss.svg) +Pérdida de soberanía de datos **El Problema:** - ❌ Datos bajo jurisdicción extranjera @@ -268,7 +268,7 @@ Un cliente B2B te pregunta dónde están alojados sus datos. Respondes «Europa **Deal perdido.** -![Deal perdido por alojamiento en EE.UU.](/assets/images/blog/2026-01-13-deal-lost-hosting.svg) +Deal perdido por alojamiento en EE.UU. **El Problema:** - ❌ Clientes B2B exigen soberanía de datos @@ -469,7 +469,7 @@ Sinra hizo la elección de la **soberanía de datos** desde el principio. - SecNumCloud (ANSSI) = referencial francés más exigente - ISO 27001 = estándar internacional de seguridad -![Datos de Sinra alojados en OVH Francia](/assets/images/blog/2026-01-13-sinra-ovh-hosting.svg) +Datos de Sinra alojados en OVH Francia **Cita de Thomas Milcent (fundador de Sinra):** > «Desde el principio, queríamos que los datos de nuestros clientes permanecieran en Francia. No por razones de marketing, sino porque es lo correcto. OVH nos permite garantizar la soberanía de datos mientras tenemos una infraestructura fiable y eficiente.» @@ -617,7 +617,7 @@ Presupuesto ajustado. **Cita del CTO de TechCorp:** > «Migrar a OVH fue la mejor decisión técnica del año. Ahorramos €16k, ganamos 2 grandes deals que habríamos perdido, y dormimos mejor sabiendo que nuestros datos están verdaderamente en Francia.» -![TechCorp: métricas antes/después migración OVH](/assets/images/blog/2026-01-13-techcorp-aws-ovh-migration.svg) +TechCorp: métricas antes/después migración OVH --- diff --git a/_posts/2026-01-13-hebergement-europeen-souverainete-donnees.fr.md b/_posts/2026-01-13-hebergement-europeen-souverainete-donnees.fr.md index b106b63..fc13116 100644 --- a/_posts/2026-01-13-hebergement-europeen-souverainete-donnees.fr.md +++ b/_posts/2026-01-13-hebergement-europeen-souverainete-donnees.fr.md @@ -59,7 +59,7 @@ DPO : « Exactement. » CTO : « Il faut qu'on change d'hébergeur. Maintenant. » -![Données en Europe mais accessibles aux États-Unis](/assets/images/blog/2026-01-13-cloud-act-contradiction.svg) +Données en Europe mais accessibles aux États-Unis --- @@ -107,7 +107,7 @@ Amazon est **légalement obligé** de se conformer au Cloud Act, même si les do **Vous n'avez aucun contrôle.** -![Cloud Act contourne la localisation physique](/assets/images/blog/2026-01-13-cloud-act-flow.svg) +Cloud Act contourne la localisation physique **Le Problème :** - ❌ Données en Europe, mais accessibles aux États-Unis @@ -160,7 +160,7 @@ Utiliser AWS, Google Cloud, ou Azure avec des données personnelles européennes Plusieurs autorités de protection des données (CNIL en France, EDPB au niveau européen) ont averti que ces transferts ne sont pas conformes au RGPD. -![RGPD et Cloud Act incompatibles](/assets/images/blog/2026-01-13-rgpd-cloud-act-conflict.svg) +RGPD et Cloud Act incompatibles **Le Problème :** - ❌ Impossible d'être conforme RGPD avec un hébergeur US @@ -222,7 +222,7 @@ Vos clients vous confient : **Vous avez perdu le contrôle.** -![Perte de souveraineté des données](/assets/images/blog/2026-01-13-sovereignty-loss.svg) +Perte de souveraineté des données **Le Problème :** - ❌ Données sous juridiction étrangère @@ -268,7 +268,7 @@ Un client B2B vous demande où sont hébergées ses données. Vous répondez « **Deal perdu.** -![Perte de deal à cause de l'hébergement US](/assets/images/blog/2026-01-13-deal-lost-hosting.svg) +Perte de deal à cause de l'hébergement US **Le Problème :** - ❌ Clients B2B exigent souveraineté des données @@ -467,7 +467,7 @@ Sinra a fait le choix de la **souveraineté des données** dès le départ. - SecNumCloud (ANSSI) = référentiel français le plus exigeant - ISO 27001 = standard international sécurité -![Données Sinra hébergées chez OVH France](/assets/images/blog/2026-01-13-sinra-ovh-hosting.svg) +Données Sinra hébergées chez OVH France **Citation Thomas (fondateur Sinra) :** > « Dès le départ, on voulait que les données de nos clients restent en France. Pas pour une raison marketing, mais parce que c'est la bonne chose à faire. OVH nous permet de garantir la souveraineté des données tout en ayant une infrastructure fiable et performante. » @@ -615,7 +615,7 @@ Budget serré. **Citation CTO TechCorp :** > « Migrer vers OVH a été la meilleure décision tech de l'année. On a économisé €16k, gagné 2 gros deals qu'on aurait perdus, et on dort mieux sachant que nos données sont vraiment en France. » -![TechCorp : métriques avant/après migration OVH](/assets/images/blog/2026-01-13-techcorp-aws-ovh-migration.svg) +TechCorp : métriques avant/après migration OVH ---