[{"data":1,"prerenderedAt":295},["ShallowReactive",2],{"article-alternates":3,"article-\u002Fit\u002Flifestyle\u002Flinear-async-standup-toplantisiz-hafta":13},{"i18nKey":4,"paths":5},"lifestyle-001-2026-05",{"de":6,"en":7,"es":8,"fr":9,"it":10,"ru":11,"tr":12},"\u002Fde\u002Flifestyle\u002Flinear-async-standup-12-person-team","\u002Fen\u002Flifestyle\u002Flinear-async-standup-meeting-free-week","\u002Fes\u002Flifestyle\u002Flinear-async-standup-equipo-12-personas","\u002Ffr\u002Flifestyle\u002Flinear-async-standup-12-personen-wochentaglos","\u002Fit\u002Flifestyle\u002Flinear-async-standup-toplantisiz-hafta","\u002Fru\u002Flifestyle\u002Flinear-async-standup-12-kisilik-ekip","\u002Ftr\u002Flifestyle\u002Flinear-async-standup-12-kisilik-ekipte-toplantisiz-hafta",{"_path":10,"_dir":14,"_draft":15,"_partial":15,"_locale":16,"title":17,"description":18,"publishedAt":19,"modifiedAt":19,"category":14,"i18nKey":4,"tags":20,"readingTime":26,"author":27,"body":28,"_type":289,"_id":290,"_source":291,"_file":292,"_stem":293,"_extension":294},"lifestyle",false,"","Linear + Async Standup: 12 Kişilik Ekipte Settimane Senza Riunioni","Gestione dei cicli, aggiornamenti giornalieri e pattern di escalation dei blocchi: disciplina per coordinare i team oltre le riunioni sincrone.","2026-05-08",[21,22,23,24,25],"async-first","linear","gestione-team","cycle-planning","blocker-escalation",8,"Roibase",{"type":29,"children":30,"toc":278},"root",[31,39,46,51,56,61,67,72,77,82,89,94,99,105,110,115,121,126,231,236,241,247,252,268,273],{"type":32,"tag":33,"props":34,"children":35},"element","p",{},[36],{"type":37,"value":38},"text","Man mano che il team cresce, il numero delle riunioni si moltiplicata esponenzialmente. In un team di 3 persone, 2 standup a settimana sembrano ragionevoli; a 12 persone, il calendario di ognuno si riempie di blocchi viola e nessuno trova una finestra di 2 ore consecutive per lavorare senza interruzioni. La soluzione non è fermare la crescita, ma trasferire il coordinamento del team verso un'architettura asincrona. In Roibase, dal tardo 2023 gestiamo un team di prodotto di 12 persone — ingegneria, design, product — attraverso settimane senza riunioni. I nostri strumenti: Linear e una metodologia basata su cicli + disciplina di aggiornamenti giornalieri asincroni.",{"type":32,"tag":40,"props":41,"children":43},"h2",{"id":42},"cycle-planning-blocchi-di-due-settimane-scope-netto",[44],{"type":37,"value":45},"Cycle Planning: Blocchi di Due Settimane, Scope Netto",{"type":32,"tag":33,"props":47,"children":48},{},[49],{"type":37,"value":50},"La struttura dei cicli in Linear assomiglia ai sprint, ma la differenza è critica: ogni ciclo definisce un perimetro di delivery e non esce mai da esso. Usiamo cicli di 2 settimane. Tre giorni prima dell'inizio di un ciclo, il product lead refina tutte le issue, assegna label di priorità (P0\u002FP1\u002FP2) e stima la taglia (non basata su punti, ma su sizing S\u002FM\u002FL). P0 = bloccante, deve essere consegnato prima della fine del ciclo; P1 = obiettivo; P2 = nice-to-have, se abbiamo tempo nel ciclo.",{"type":32,"tag":33,"props":52,"children":53},{},[54],{"type":37,"value":55},"Nessuna riunione di planning. L'inizio del ciclo è asincrono: nel canale Slack dedicato #cycle-kickoff scriviamo il titolo del ciclo, un riassunto dello scope e la data di delivery target. Il team legge tutte le issue entro 24 ore, le assegna a sé stesso (auto-assegnazione è disciplina), e chiede nel thread dei commenti eventuali dettagli tecnici non chiari. Il product lead scansiona Linear una volta al giorno, risponde e, se c'è conflitto di scope, riprioritizza. Questo processo costa 2-3 ore totali, ma nessuna riunione di 12 persone.",{"type":32,"tag":33,"props":57,"children":58},{},[59],{"type":37,"value":60},"Possiamo cambiare lo scope a ciclo iniziato? Sì, ma solo dopo che il proprietario dell'issue sposta manualmente lo stato da \"Backlog\" a \"Todo\" in Linear. Niente scope creep automatico. Con questa disciplina, il ciclo inizia con 18 issue e termina con 19, ma 14 tra P0 e P1 sono completate — una velocity del 78%. Dodici ore di meetings risparmiato.",{"type":32,"tag":40,"props":62,"children":64},{"id":63},"daily-update-non-report-di-status-segnali-di-progresso",[65],{"type":37,"value":66},"Daily Update: Non Report di Status, Segnali di Progresso",{"type":32,"tag":33,"props":68,"children":69},{},[70],{"type":37,"value":71},"In un team asincrono, al posto dello standup quotidiano, ognuno scrive ogni giorno tra le 09:00 e le 10:00 nel proprio profilo Linear un commento nel formato \"Cosa ho consegnato ieri \u002F Cosa faccio oggi \u002F Blocchi\". Ma noi l'abbiamo semplificato ulteriormente: tutti scrivono il progresso direttamente nel commento dell'issue. Ad esempio: \"Flusso di checkout — integrazione API al 60%, scrivo i test, nessun blocco\" oppure \"Sistema di design — componenti Figma completati, pronto per il passaggio al dev\".",{"type":32,"tag":33,"props":73,"children":74},{},[75],{"type":37,"value":76},"Questo non è un report di status, è un segnale di progresso. Chi legge non conosce la situazione, ma riceve il segnale: verde = c'è avanzamento, rosso = c'è un blocco. Se c'è un blocco, mettiamo l'emoji 🔴 + il prefisso \"BLOCCO:\" nella prima riga del commento. Il product lead e il tech lead cercano questa emoji in Linear (ricerca salvata) ogni 30 minuti, e se la trovano intervengono entro 1 ora.",{"type":32,"tag":33,"props":78,"children":79},{},[80],{"type":37,"value":81},"Il vantaggio critico dell'aggiornamento giornaliero asincrono è questo: ognuno scrive nel proprio contesto. Lo sviluppatore non scrive alle 09:00 con context switch, ma scrive dal commento dell'issue nel mezzo della sessione di coding del mattino. Il designer scrive alle 18:00 mentre chiude Figma. Il tempo medio di completamento (dal quando un'issue si apre a quando si chiude) è sceso a 3,2 giorni — durante il periodo di standup sincrono era 4,8 giorni. Il motivo: l'escalation pattern dei blocchi è più veloce.",{"type":32,"tag":83,"props":84,"children":86},"h3",{"id":85},"blocker-escalation-soglia-di-4-ore",[87],{"type":37,"value":88},"Blocker Escalation: Soglia di 4 Ore",{"type":32,"tag":33,"props":90,"children":91},{},[92],{"type":37,"value":93},"C'è una regola rigida per il rilevamento dei blocchi: se un'issue non mostra progresso per 4 ore consecutive, il proprietario aggiunge automaticamente il label \"blocco\" in Linear e menziona la persona responsabile. Ad esempio, se uno sviluppatore backend aspetta una risposta dall'API, menziona il lead frontend; il lead frontend risponde entro 2 ore o apre un thread asincrono. Tutto rimane nel thread dell'issue Linear — niente contesto perso.",{"type":32,"tag":33,"props":95,"children":96},{},[97],{"type":37,"value":98},"La soglia di 4 ore non è arbitraria: i dati di Roibase da Q1 2024 mostrano che se un blocco non viene escalato entro 4 ore, il ritardo medio è 1,3 giorni. Se viene escalato entro 4 ore, il ritardo scende a 0,4 giorni. Per mantenere questa disciplina, usiamo un webhook Linear + uno script personalizzato: se un'issue rimane statica per 4 ore, un DM Slack automatico arriva al proprietario (\"Issue X non ha movimento — c'è un blocco?\"). Niente follow-up manuale, l'automazione forza la disciplina.",{"type":32,"tag":40,"props":100,"children":102},{"id":101},"leccezione-al-modello-asincrono-critique-del-design-settimanale",[103],{"type":37,"value":104},"L'Eccezione al Modello Asincrono: Critique del Design Settimanale",{"type":32,"tag":33,"props":106,"children":107},{},[108],{"type":37,"value":109},"È possibile un sistema completamente asincrono? No. C'è un'eccezione: il critique del design settimanale. Dal team di 12 persone partecipano solo i designer + il product lead (5-6 persone), 45 minuti, screen share di Figma. Perché serve una riunione sincrona? L'iterazione di design può essere asincrona, ma la decisione di design richiede giudizio collettivo — \"questo deve essere un pulsante o un link?\" impiega 3 giorni su Linear, 8 minuti in una conversazione dal vivo. Differenza critica: nel critique del design il decisore è uno solo (il product lead), non si cerca il consensus, si raccolgono gli input.",{"type":32,"tag":33,"props":111,"children":112},{},[113],{"type":37,"value":114},"Anche in questa riunione c'è disciplina asincrona: prima della riunione, tutti i mockup di design vengono caricati su Figma e collegati all'issue Linear. I partecipanti guardano 1 giorno prima e lasciano commenti. Nella riunione si risolvono solo i conflitti o si prendono le decisioni critiche. In media, da una riunione di 45 minuti escono 12-15 decisioni di design, tutte registrate nell'issue Linear. Due ore dopo che finisce la riunione, il designer applica le decisioni su Figma e il handoff al dev inizia.",{"type":32,"tag":40,"props":116,"children":118},{"id":117},"cultura-asincrona-loop-di-feedback-numerico",[119],{"type":37,"value":120},"Cultura Asincrona: Loop di Feedback Numerico",{"type":32,"tag":33,"props":122,"children":123},{},[124],{"type":37,"value":125},"Affinché la disciplina asincrona si autosostenga, servono metriche. Alla fine di ogni ciclo in Roibase estraiamo da Linear i numeri:",{"type":32,"tag":127,"props":128,"children":129},"table",{},[130,154],{"type":32,"tag":131,"props":132,"children":133},"thead",{},[134],{"type":32,"tag":135,"props":136,"children":137},"tr",{},[138,144,149],{"type":32,"tag":139,"props":140,"children":141},"th",{},[142],{"type":37,"value":143},"Metrica",{"type":32,"tag":139,"props":145,"children":146},{},[147],{"type":37,"value":148},"Obiettivo",{"type":32,"tag":139,"props":150,"children":151},{},[152],{"type":37,"value":153},"Realtà (Q1 2026)",{"type":32,"tag":155,"props":156,"children":157},"tbody",{},[158,177,195,213],{"type":32,"tag":135,"props":159,"children":160},{},[161,167,172],{"type":32,"tag":162,"props":163,"children":164},"td",{},[165],{"type":37,"value":166},"Velocity del ciclo (completion P0+P1)",{"type":32,"tag":162,"props":168,"children":169},{},[170],{"type":37,"value":171},">75%",{"type":32,"tag":162,"props":173,"children":174},{},[175],{"type":37,"value":176},"78%",{"type":32,"tag":135,"props":178,"children":179},{},[180,185,190],{"type":32,"tag":162,"props":181,"children":182},{},[183],{"type":37,"value":184},"Età media dell'issue (apertura → chiusura)",{"type":32,"tag":162,"props":186,"children":187},{},[188],{"type":37,"value":189},"\u003C4 giorni",{"type":32,"tag":162,"props":191,"children":192},{},[193],{"type":37,"value":194},"3,2 giorni",{"type":32,"tag":135,"props":196,"children":197},{},[198,203,208],{"type":32,"tag":162,"props":199,"children":200},{},[201],{"type":37,"value":202},"Tempo di escalation blocco (label → risolto)",{"type":32,"tag":162,"props":204,"children":205},{},[206],{"type":37,"value":207},"\u003C6 ore",{"type":32,"tag":162,"props":209,"children":210},{},[211],{"type":37,"value":212},"4,7 ore",{"type":32,"tag":135,"props":214,"children":215},{},[216,221,226],{"type":32,"tag":162,"props":217,"children":218},{},[219],{"type":37,"value":220},"Context switch per giorno (quante issue per persona al giorno)",{"type":32,"tag":162,"props":222,"children":223},{},[224],{"type":37,"value":225},"\u003C3",{"type":32,"tag":162,"props":227,"children":228},{},[229],{"type":37,"value":230},"2,4",{"type":32,"tag":33,"props":232,"children":233},{},[234],{"type":37,"value":235},"La metrica del context switch è critica: lo scopo del lavoro asincrono è il deep work, ma se una persona tocca 6 issue al giorno, è frammentata lo stesso. Una media di 2,4 è sana — un'issue al mattino, una al pomeriggio, revisione la sera.",{"type":32,"tag":33,"props":237,"children":238},{},[239],{"type":37,"value":240},"Questi numeri vengono postati automaticamente nel canale Slack #metrics ogni settimana (Linear API + Zapier). Ognuno nel team vede la propria performance rispetto al resto. Quando il feedback loop è numerico, la disciplina asincrona diventa cultura. Un developer nuovo al team sente dal peer al secondo lavoro \"perché non stai scrivendo commenti su Linear?\" — non dal manager. Questa pressione culturale è la garanzia della assenza di riunioni.",{"type":32,"tag":40,"props":242,"children":244},{"id":243},"prospettiva-del-founder-non-è-il-tempo-è-leconomia-del-contesto",[245],{"type":37,"value":246},"Prospettiva del Founder: Non è il Tempo, è l'Economia del Contesto",{"type":32,"tag":33,"props":248,"children":249},{},[250],{"type":37,"value":251},"Il ROI della gestione asincrona non si calcola in ore. Se un team di 12 persone non fa 2 riunioni a settimana, pensiamo di aver guadagnato 24 ore — ma è fuorviante. Il vero guadagno è azzerare il costo del context switching. In uno standup sincrono, tutti fanno context switch nello stesso momento; dopo la riunione passano 15-20 minuti a tornare al context precedente. Con gli aggiornamenti asincroni, ognuno scrive al proprio ritmo, zero context loss.",{"type":32,"tag":33,"props":253,"children":254},{},[255,257,266],{"type":37,"value":256},"Usiamo questa disciplina anche nei lavori di ",{"type":32,"tag":258,"props":259,"children":263},"a",{"href":260,"rel":261},"https:\u002F\u002Fwww.roibase.com.tr\u002Fit\u002Fbranding",[262],"nofollow",[264],{"type":37,"value":265},"brand identity",{"type":37,"value":267}," di Roibase: il feedback del cliente si apre come issue in Linear, il designer risponde in modo asincrono, l'iterazione di revisione gira senza riunioni. Il numero di meeting con il cliente è sceso del 60%, la velocità di delivery è salita. Perché il designer può proteggere 3 ore consecutive di design session al pomeriggio invece di rompersi per una riunione alle 10:00.",{"type":32,"tag":33,"props":269,"children":270},{},[271],{"type":37,"value":272},"Il trade-off critico della disciplina asincrona è questo: le decisioni spontanee rallentano. Se serve una decisione architettonica urgente, un thread di commenti su Linear impiega 4 ore, una Zoom 15 minuti. È accettabile — perché non ogni decisione è urgente. Per 1-2 decisioni urgenti a settimana, una riunione sincrona è più efficiente che 10 riunioni di routine.",{"type":32,"tag":33,"props":274,"children":275},{},[276],{"type":37,"value":277},"Il sistema Linear + standup asincrono non riduce l'overhead operativo, lo sposta: invece di organizzare riunioni, si fa igiene di Linear (tagging delle issue, update della priorità, flagging dei blocchi). Ma è il lavoro di 30 minuti di routine quotidiana di una persona (il product lead), non 1 ora di riunione di 12. Il sistema scala. Se salissimo a 18 persone, lo stesso pattern funziona — cresce il volume di issue, non il numero di riunioni.",{"title":16,"searchDepth":279,"depth":279,"links":280},3,[281,283,286,287,288],{"id":42,"depth":282,"text":45},2,{"id":63,"depth":282,"text":66,"children":284},[285],{"id":85,"depth":279,"text":88},{"id":101,"depth":282,"text":104},{"id":117,"depth":282,"text":120},{"id":243,"depth":282,"text":246},"markdown","content:it:lifestyle:linear-async-standup-toplantisiz-hafta.md","content","it\u002Flifestyle\u002Flinear-async-standup-toplantisiz-hafta.md","it\u002Flifestyle\u002Flinear-async-standup-toplantisiz-hafta","md",1778306635718]