[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fszXYR7esxMqhSNH_i-9e-PxMK3s1udRCBfR_5KapU20":3,"$fMjZvcDme22vqDmk_y95q3AjXj3-NZxS3LiJ2aof-qxQ":22},{"id":4,"slug":5,"titleFr":6,"titleEn":7,"titleKm":8,"contentFr":9,"contentEn":10,"contentKm":11,"excerptFr":12,"excerptEn":13,"excerptKm":14,"tags":15,"createdAt":21,"updatedAt":21},115,"back-foc-collaboration-sdk","Back et FOC : comment on a mis fin à deux ans de frustrations en une réunion","Back and FOC: How We Ended Two Years of Frustration in One Meeting","Back និង FOC ៖ របៀបដែលយើងបញ្ចប់ភាពខ្វះខាតក្នុងការ Meeting មួយ","## Deux équipes, une incompréhension structurelle\n\nChez DJUST, les APIs ne sont pas consommées uniquement par des clients externes. L'équipe FOC — Front of Customers, les développeurs qui construisent et maintiennent notre SDK Front — est le premier consommateur interne de nos APIs Backend.\n\nPendant longtemps, cette relation fonctionnait \"à peu près\". Le Back développait des endpoints, le FOC les intégrait dans le SDK, les clients finaux utilisaient le SDK. En théorie, une chaîne simple. En pratique, une source de friction permanente.\n\nLes symptômes sont apparus progressivement dans les rétros :\n\n> *\"Monter un point pour les problèmes d'évolutions qui impactent le FOC sans prévenir\"*\n\n> *\"Trouver un point d'entrée front pour communiquer avec les intégrateurs front\"*\n\nCes actions revenaient d'une rétro à l'autre, trimestre après trimestre, sans vraiment être résolues. C'est le signe classique d'un problème structurel qu'on panse sans jamais traiter la cause.\n\n---\n\n## Les frustrations des deux côtés\n\nLa réunion de clarification a eu lieu en octobre 2025. Ce qu'on a mis à plat :\n\n**Du côté Back :**\n- Le FOC implémente parfois des choses \"à leur manière\" sans consulter le Back au préalable\n- Des décisions d'architecture Front impactent le comportement attendu des APIs Backend sans qu'on soit au courant\n- On découvre après coup que le SDK fait des appels qu'on n'avait pas anticipés\n\n**Du côté FOC :**\n- Le Back change des contrats API sans prévenir — et le SDK se retrouve cassé du jour au lendemain\n- On n'est pas consulté lors de la conception des nouvelles features qui vont toucher le SDK\n- On est le premier à découvrir les bugs et incohérences des APIs, mais on n'a pas de canal clair pour les remonter\n\nLe constat rédigé à chaud après la réunion :\n\n> *\"Frustrations des 2 côtés. Les deux équipes se reprochent de 'faire des choses sans en parler aux autres' et de ne pas s'écouter.\"*\n\nCe n'est pas une question de mauvaise volonté. C'est une question de structure : sans framework clair, chaque équipe optimize localement au détriment du global.\n\n---\n\n## La vision qu'on a construite ensemble\n\nLe vrai travail de la réunion n'était pas de lister les frustrations — c'était de formuler une vision partagée. Ce qu'on a posé :\n\n**Le FOC est un partenaire privilégié du Back, qui a la charge de développer un SDK utilisé par l'ensemble des partenaires. Le SDK est une extension du produit DJUST, générique, qui doit évoluer au même rythme que son produit.**\n\nCette phrase semble simple, mais elle change beaucoup de choses. Elle dit que :\n1. Le SDK n'est pas un projet parallèle — c'est une extension du produit. Sa qualité est la qualité du produit.\n2. Le FOC n'est pas un client lambda — c'est un partenaire privilégié avec des droits ET des responsabilités spécifiques.\n3. \"Évoluer au même rythme\" — le SDK ne peut pas être en retard d'une release sur le Back. Ce n'est pas acceptable.\n\n---\n\n## Les trois casquettes du FOC\n\nOn a ensuite décliné cette vision en trois rôles distincts, qui coexistent :\n\n### En tant que partenaire standard\n\nLe FOC utilise nos APIs comme n'importe quel intégrateur externe. Il doit :\n- Utiliser la documentation (README, Swagger) comme référence\n- Être autonome sur les APIs publiques disponibles\n- Ne pas avoir accès à des \"raccourcis\" non documentés\n\nC'est important. Si le FOC a besoin de raccourcis pour implémenter le SDK, c'est que notre documentation est insuffisante pour les partenaires externes. Le FOC est notre premier signal qualité.\n\n### En tant que partenaire privilégié\n\nParce qu'il est le premier consommateur de nos nouvelles APIs, le FOC a des responsabilités supplémentaires :\n- **Remonter immédiatement** tout problème rencontré en phase de lancement (manque de doc, bugs, comportements inattendus)\n- **Être consulté** sur la définition des standards API — il a une expérience unique d'avoir implémenté des dizaines de FOC clients\n- **Participer à la conception** des futures fonctionnalités qui toucheront les contrats API\n\n### En tant que responsable du SDK\n\nC'est le rôle le plus contraignant : le FOC doit être au courant *en amont* des évolutions roadmap pour pouvoir planifier l'implémentation SDK en parallèle du développement Back. Pas après. Pas le jour de la release. En amont.\n\n---\n\n## Les actions concrètes\n\nLa vision, c'est bien. Les actions, c'est mieux. Ce qu'on a décidé :\n\n**1. Finaliser les standards API avec le FOC**\nDes APIs simples, cohérentes et bien documentées réduisent naturellement les frictions. On ne peut pas demander au FOC d'être autonome si nos APIs sont ésotériques. Responsable : le Tech Lead.\n\n**2. Un référent FOC dédié par feature**\nPour chaque feature qui touche les APIs, un référent FOC est désigné par le Head of FOC. Ce référent :\n- Est consulté sur les choix API dès la conception\n- Participe au Kick-Off Feature\n- Communique au Back comment il va implémenter la partie SDK\n- Met à jour le SDK en parallèle du développement Back\n\n**3. Anticipation des évolutions tech**\nOn a listé des cas concrets d'évolutions tech qui avaient impacté le FOC sans prévenance :\n- Le passage au nouveau DAM — le FOC a découvert les changements lors de la mise en production\n- Le monitoring SSR — une décision d'architecture qui avait des implications FOC que personne n'avait anticipées\n\nLe principe : toute évolution technique qui touche le comportement de nos APIs doit être présentée au FOC *avant* d'être développée.\n\n---\n\n## Ce que ça change concrètement\n\nSix mois après cette réunion, voici ce qu'on observe :\n\n**Ce qui marche mieux :**\n- Le projet Carte Achat de Niveau 3 a été le premier test du nouveau process. Un message formel a été envoyé à l'équipe FOC en amont pour les informer de l'impact API et leur demander des retours préliminaires. Le Head of FOC a confirmé l'importance de la démarche immédiatement.\n- Les breaking changes sont maintenant communiqués en amont via nos release notes. Le FOC sait quoi préparer avant la release du jeudi.\n\n**Ce qui reste difficile :**\n- La discipline sur les kick-offs feature. Quand on est dans le rush d'un sprint, la tentation de \"finir d'abord, aligner ensuite\" est forte.\n- Le SDK a tendance à prendre du retard sur le Back malgré les bonnes intentions. La roadmap commune reste un chantier.\n\n**Ce qu'on a appris :**\nUne réunion ne résout pas un problème structurel. Elle pose les bases. Le vrai travail, c'est de tenir les engagements dans la durée — et d'ajuster quand ça glisse.\n\n---\n\n## Pour les Engineering Managers\n\nSi vous gérez une équipe Backend dont les APIs sont consommées par un partenaire interne (SDK, intégrateur, équipe Front), voici ce que j'ai appris :\n\n**Ne présumez pas que \"ils savent ce qu'on fait\".** La transparence par défaut n'existe pas entre équipes. Il faut des rituels explicites.\n\n**Distinguez les rôles.** Un partenaire interne n'est pas un client externe et n'est pas non plus un membre de votre équipe. C'est une catégorie à part, avec ses droits et ses responsabilités propres.\n\n**Le SDK est votre premier signal qualité.** Si votre partenaire interne a besoin de workarounds pour implémenter son SDK, c'est que vos APIs ont un problème. Écoutez-le.\n\n**La vision commune précède les process.** On a essayé de résoudre les frustrations avec des actions concrètes pendant des mois, sans succès. Quand on a posé la vision en premier (le FOC est un partenaire privilégié, le SDK est une extension du produit), les actions ont suivi naturellement.\n\n---\n\n*Chetana YIN — Novembre 2025*\n*Engineering Manager chez DJUST. OMS, Payments, Cart.*","## Two Teams, One Structural Misunderstanding\n\nAt DJUST, APIs aren't just consumed by external clients. The FOC team — Front of Customers, the developers who build and maintain our Front SDK — is the primary internal consumer of our Backend APIs.\n\nFor a long time, this relationship worked \"well enough.\" The Backend developed endpoints, the FOC integrated them into the SDK, end clients used the SDK. In theory, a simple chain. In practice, a constant source of friction.\n\nThe symptoms appeared gradually in retrospectives:\n\n> *\"Set up a meeting about evolutions that impact the FOC without warning\"*\n\n> *\"Find an entry point to communicate with front integrators\"*\n\nThese actions kept coming up retro after retro, quarter after quarter, without ever being truly resolved. That's the classic sign of a structural problem being patched without ever treating the root cause.\n\n---\n\n## The Frustrations on Both Sides\n\nThe clarification meeting took place in October 2025. What we laid out:\n\n**From the Back side:**\n- The FOC sometimes implements things \"their way\" without consulting Backend beforehand\n- Front architecture decisions impact expected API behavior without us knowing\n- We discover after the fact that the SDK makes calls we hadn't anticipated\n\n**From the FOC side:**\n- Backend changes API contracts without warning — and the SDK breaks overnight\n- We're not consulted during the design of new features that will affect the SDK\n- We're the first to discover API bugs and inconsistencies, but there's no clear channel to report them\n\nThe assessment written immediately after the meeting:\n\n> *\"Frustrations on both sides. Both teams accuse each other of 'doing things without telling others' and not listening.\"*\n\nThis isn't a question of bad will. It's a structural problem: without a clear framework, each team optimizes locally at the expense of the whole.\n\n---\n\n## The Shared Vision We Built\n\nThe real work of the meeting wasn't listing frustrations — it was formulating a shared vision. What we established:\n\n**The FOC is a privileged partner of the Backend, responsible for developing an SDK used by all partners. The SDK is a generic extension of the DJUST product that must evolve at the same pace as the product.**\n\nThis sentence seems simple, but it changes a lot. It says:\n1. The SDK isn't a parallel project — it's a product extension. Its quality is the product's quality.\n2. The FOC isn't just another client — it's a privileged partner with specific rights AND responsibilities.\n3. \"Evolve at the same pace\" — the SDK cannot lag one release behind the Backend. That's not acceptable.\n\n---\n\n## The Three Hats of the FOC\n\nWe then broke down this vision into three distinct roles that coexist:\n\n### As a Standard Partner\n\nThe FOC uses our APIs like any external integrator. It must:\n- Use documentation (README, Swagger) as reference\n- Be autonomous on available public APIs\n- Not have access to undocumented \"shortcuts\"\n\nThis is important. If the FOC needs shortcuts to implement the SDK, it means our documentation is insufficient for external partners. The FOC is our first quality signal.\n\n### As a Privileged Partner\n\nBecause it's the first consumer of our new APIs, the FOC has additional responsibilities:\n- **Immediately report** any problem encountered during launch phase (missing docs, bugs, unexpected behaviors)\n- **Be consulted** on API standards definition — it has unique experience from implementing dozens of client FOCs\n- **Participate in the design** of future features that will affect API contracts\n\n### As SDK Owner\n\nThis is the most demanding role: the FOC must know *in advance* about roadmap evolutions to plan SDK implementation in parallel with Backend development. Not after. Not on release day. In advance.\n\n---\n\n## Concrete Actions\n\nVision is good. Actions are better. What we decided:\n\n**1. Finalize API Standards with the FOC**\nSimple, consistent, well-documented APIs naturally reduce friction. We can't ask the FOC to be autonomous if our APIs are esoteric. Owner: the Tech Lead.\n\n**2. A Dedicated FOC Reference Per Feature**\nFor every feature touching APIs, a FOC reference is designated by the Head of FOC. This person:\n- Is consulted on API choices from the design phase\n- Participates in the Feature Kick-Off\n- Communicates to Backend how they'll implement the SDK part\n- Updates the SDK in parallel with Backend development\n\n**3. Anticipating Tech Evolutions**\nWe listed concrete cases where tech evolutions impacted the FOC without warning:\n- The new DAM migration — the FOC discovered changes at deployment\n- SSR monitoring — an architecture decision with FOC implications nobody had anticipated\n\nThe principle: any technical evolution affecting API behavior must be presented to the FOC *before* development starts.\n\n---\n\n## What Changed Concretely\n\nSix months after this meeting, here's what we observe:\n\n**What's working better:**\n- The Level 3 Purchase Card project was the first test of the new process. A formal message was sent to the FOC team in advance to inform them of API impact and request preliminary feedback. The Head of FOC confirmed the importance of the approach immediately.\n- Breaking changes are now communicated in advance via release notes. The FOC knows what to prepare before Thursday's release.\n\n**What remains difficult:**\n- Discipline on feature kick-offs. When you're in sprint rush, the temptation to \"finish first, align later\" is strong.\n- The SDK tends to fall behind Backend despite good intentions. The shared roadmap remains a work in progress.\n\n**What we learned:**\nOne meeting doesn't fix a structural problem. It sets the foundations. The real work is holding commitments over time — and adjusting when things slip.\n\n---\n\n## For Engineering Managers\n\nIf you manage a Backend team whose APIs are consumed by an internal partner (SDK, integrator, Front team), here's what I learned:\n\n**Don't assume \"they know what we're doing.\"** Default transparency doesn't exist between teams. You need explicit rituals.\n\n**Distinguish roles.** An internal partner isn't an external client and isn't a team member either. It's a separate category with its own rights and responsibilities.\n\n**The SDK is your first quality signal.** If your internal partner needs workarounds to implement their SDK, your APIs have a problem. Listen to them.\n\n**Shared vision precedes process.** We tried to resolve frustrations with concrete actions for months, unsuccessfully. When we established the vision first (FOC is a privileged partner, SDK is a product extension), actions followed naturally.\n\n---\n\n*Chetana YIN — November 2025*\n*Engineering Manager at DJUST. OMS, Payments, Cart.*","## ក្រុម ២ ដែលមានភាពខ្វះខាតដោយសារ Structure\n\nនៅ DJUST ក្រុម FOC (Front of Customers) — developers ដែលបង្កើត SDK Front — គឺជា consumer ខាងក្នុងដំបូងគេនៃ APIs Back។\n\nរយៈពេលយូរ ទំនាក់ទំនងនេះដំណើរការ \"ល្អបន្តិចបន្ហោច\" ។ ប៉ុន្តែការបារម្ភបន្តិចម្តងៗ ក្នុងការ retrospectives :\n\n- FOC ដឹងអំពី breaking changes តែនៅ deploy ហើយ\n- Back ដឹងថា SDK ប្រើ endpoints ដែលមិនបានរំពឹង\n- មិនមានចាំណែងច្បាស់លាស់\n\n---\n\n## Vision ដែលបានបង្កើតជាមួយគ្នា\n\n**FOC = partenaire privilégié du Back ដែលទទួលខុសត្រូវក្នុងការអភិវឌ្ឍ SDK ។ SDK = extension ផលិតផល DJUST ។**\n\nការចែករំលែក Vision នេះបានផ្លាស់ប្តូរអ្វីៗ — SDK មិនមែន projet ផ្សេងទៀតទេ ជា extension ផលិតផល។\n\n**FOC ម្នាក់ ③ HistoryCap**\n1. ជា partenaire standard ដូច integrator ខាងក្រៅ\n2. ជា partenaire privilégié — report bugs API ទាំងដំបូង consult API standards\n3. ជា SDK owner — ត្រូវដឹងជាមុននូវ roadmap evolutions\n\n---\n\n## Action Concrètes\n\n- Finalize API standards ជាមួយ FOC\n- Référent FOC dedicated ក្នុង feature នីមួយៗ — participates in kick-off\n- Communication proactive : breaking changes ត្រូវប្រាប់ FOC មុន release\n\n---\n\n## ការរៀន\n\nVision ចែករំលែក > process — ត្រូវវាងមុន ។ SDK ជា quality signal ដំបូង — ប្រសិន FOC ត្រូវ workarounds APIs ខ្លួនទ្រង់ problem ។\n\n---\n\n*Chetana YIN — វិច្ឆិកា ២០២៥*\n*Engineering Manager នៅ DJUST*","Le FOC et le Back se reprochaient mutuellement de ne pas s'écouter. Après des mois de rétros sans résolution, une réunion a tout changé — en posant d'abord une vision claire du rôle du SDK et du partenariat Back/FOC.","FOC and Backend were accusing each other of not listening. After months of unresolved retros, one meeting changed everything — by first establishing a clear vision of the SDK's role and the Back/FOC partnership.","FOC និង Back បានស្តីបន្ទោសគ្នា ។ ក្រោយ retrospectives ច្រើនខែដោយគ្មានការដោះស្រាយ Meeting មួយបានផ្លាស់ប្តូរអ្វីៗ ។",[16,17,18,19,20],"Management","API","SDK","Collaboration","Architecture","2026-02-20T19:00:00",[]]