[{"data":1,"prerenderedAt":295},["ShallowReactive",2],{"article-alternates":3,"article-\u002Fru\u002Flifestyle\u002Flinear-async-standup-12-kisilik-ekip":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":11,"_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 человек","Управление циклами, ежедневные обновления и эскалация блокировок — дисциплина координации команды без синхронных встреч.","2026-05-08",[21,22,23,24,25],"async-first","linear","upravlenie-komandoy","tsiklicheskie-tsikly","eskalatsiya-blokirovok",9,"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","По мере роста команды количество встреч растёт экспоненциально. В команде из 3 человек две ежедневные синхронизации кажутся разумными; в команде из 12 человек календарь каждого заполняется фиолетовыми блоками и никто не находит 2-часовое окно для непрерывной работы. Решение — не остановить рост, а перенести координацию команды на асинхронную модель. В Roibase с конца 2023 года мы управляем 12-человеческой product-командой — разработка, дизайн, product management — в неделях без встреч. Инструмент: Linear. Метод: cycle-based planning + async daily update дисциплина.",{"type":32,"tag":40,"props":41,"children":43},"h2",{"id":42},"планирование-цикла-двухнедельные-блоки-чёткая-область",[44],{"type":37,"value":45},"Планирование цикла: двухнедельные блоки, чёткая область",{"type":32,"tag":33,"props":47,"children":48},{},[49],{"type":37,"value":50},"Структура цикла в Linear похожа на спринт, но различие критично: каждый цикл определяет scope доставки и не выходит за его пределы. Мы используем двухнедельные циклы. За 3 дня до начала цикла product lead уточняет все issue'ы, назначает priority-метку (P0\u002FP1\u002FP2) и оценку (не points, а S\u002FM\u002FL sizing). P0 = критичное, должно быть доставлено до конца цикла; P1 = целевое; P2 = хорошо иметь, но если будет время в цикле.",{"type":32,"tag":33,"props":52,"children":53},{},[54],{"type":37,"value":55},"Планирующей встречи нет. Старт цикла асинхронный: в выделенный Slack-канал #cycle-kickoff пишется название цикла, краткое описание scope'а и целевая дата доставки. За 24 часа вся команда читает все issue'ы, self-assign'ит их в Linear (дисциплина self-assign), уточняет неясные технические детали в комментариях. Product lead один раз в день просматривает Linear, отвечает, если есть конфликт scope'а — переставляет приоритеты. Этот процесс занимает 2-3 часа, но без единого 12-человеческого совещания.",{"type":32,"tag":33,"props":57,"children":58},{},[59],{"type":37,"value":60},"Можно ли менять scope в середине цикла? Да, но после ручного сдвига issue из \"Backlog\" в \"Todo\" в Linear. Нет автоматического scope creep. Благодаря этой дисциплине цикл начинается с 18 issue'ями, заканчивается 19, но 14 из них P0\u002FP1 завершены — velocity 78%. Двенадцать часов не потрачены на встречи.",{"type":32,"tag":40,"props":62,"children":64},{"id":63},"ежедневное-обновление-не-отчёт-о-статусе-а-сигнал-прогресса",[65],{"type":37,"value":66},"Ежедневное обновление: не отчёт о статусе, а сигнал прогресса",{"type":32,"tag":33,"props":68,"children":69},{},[70],{"type":37,"value":71},"В асинхронной команде вместо ежедневного синхронного standup каждый день в 09:00–10:00 каждый пишет в профиль Linear комментарий в формате \"Что я задеплоил вчера \u002F Что я делаю сегодня \u002F Блокировки\". Но мы ещё больше упростили: пишем прогресс-комментарии прямо в issue. Например: \"Checkout flow — интеграция API 60% готовы, пишу тесты, блокировок нет\" или \"Design system — компонент Figma готов, handoff dev'у готов\".",{"type":32,"tag":33,"props":73,"children":74},{},[75],{"type":37,"value":76},"Это не отчёт о статусе, а сигнал прогресса. Читающий не узнаёт статус, а получает сигнал: зелёный = прогресс идёт, красный = есть блокировка. Если блокировка, в первой строке комментария ставим 🔴 emoji + префикс \"BLOCKER:\". Product lead и tech lead ищут этот emoji в Linear сохранённым запросом каждые 30 минут, если есть — вмешиваются в течение часа.",{"type":32,"tag":33,"props":78,"children":79},{},[80],{"type":37,"value":81},"Критичное преимущество асинхронного ежедневного обновления: каждый пишет в своём контексте. Developer не выходит из кодовой сессии в 09:00 для встречи, а пишет note в issue после обеда, когда заканчивает feature. Designer закрывает Figma в 18:00 и пишет progress. Среднее время от открытия issue к закрытию упало с 4,8 дня до 3,2 дня — благодаря ускоренной escalation pattern блокировок.",{"type":32,"tag":83,"props":84,"children":86},"h3",{"id":85},"эскалация-блокировки-4-часовой-порог",[87],{"type":37,"value":88},"Эскалация блокировки: 4-часовой порог",{"type":32,"tag":33,"props":90,"children":91},{},[92],{"type":37,"value":93},"Для определения блокировки используется жёсткое правило: если issue 4 часа не показывает прогресса, ответственный автоматически добавляет blocker-метку в Linear и упоминает соответствующего человека. Например, backend-разработчик ждёт API response — упоминает frontend lead'а, тот отвечает в течение 2 часов или открывает асинхронный thread. Весь процесс остаётся в Linear issue thread — контекст не теряется.",{"type":32,"tag":33,"props":95,"children":96},{},[97],{"type":37,"value":98},"4-часовой порог не произвольный: данные Roibase за Q1 2024 показали, что если блокировка не escalate'ится за 4 часа, среднее задержание составляет 1,3 дня. Если escalate за 4 часа — задержание 0,4 дня. Чтобы сохранить эту дисциплину, используется Linear webhook + custom скрипт: если issue 4 часа не меняет статус, sabot'у автоматически идёт Slack DM (\"Issue X не двигается — есть блокировка?\"). Нет ручного отслеживания, автоматизация force дисциплину.",{"type":32,"tag":40,"props":100,"children":102},{"id":101},"исключение-из-асинхронности-еженедельный-дизайн-критик",[103],{"type":37,"value":104},"Исключение из асинхронности: еженедельный дизайн-критик",{"type":32,"tag":33,"props":106,"children":107},{},[108],{"type":37,"value":109},"Полностью асинхронная система возможна? Нет. Одно исключение: еженедельный дизайн-критик. Из 12-человеческой команды только дизайнеры + product lead участвуют (5-6 человек), 45 минут, Figma screen share. Почему синхронная встреча нужна? Итерация дизайна асинхронна, но дизайн-решение требует коллективного суждения — вопрос \"это кнопка или ссылка?\" решается асинхронно 3 дня, синхронно 8 минут. Критичное различие: на критик'е лицо, принимающее решение одно (product lead), consensus не ищется, input собирается.",{"type":32,"tag":33,"props":111,"children":112},{},[113],{"type":37,"value":114},"Даже на этой встрече есть асинхронная дисциплина: до встречи все мокапы вгружаются в Figma, привязываются к Linear issue, участники за день смотрят и комментируют. На встреч только разрешаются конфликты или берутся критичные решения. В среднем за 45 минут встречи принимается 12-15 дизайн-решений, все записываются в Linear issue. Спустя 2 часа после встречи дизайнер применяет решения в Figma, начинается dev handoff.",{"type":32,"tag":40,"props":116,"children":118},{"id":117},"асинхронная-культура-численный-feedback-loop",[119],{"type":37,"value":120},"Асинхронная культура: численный feedback loop",{"type":32,"tag":33,"props":122,"children":123},{},[124],{"type":37,"value":125},"Чтобы асинхронная дисциплина сохраняла себя, нужны метрики. В Roibase в конце каждого цикла из Linear извлекаются метрики:",{"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},"Метрика",{"type":32,"tag":139,"props":145,"children":146},{},[147],{"type":37,"value":148},"Целевое значение",{"type":32,"tag":139,"props":150,"children":151},{},[152],{"type":37,"value":153},"Фактическое (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},"Cycle velocity (P0+P1 completion rate)",{"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},"Среднее время issue (открытие → закрытие)",{"type":32,"tag":162,"props":186,"children":187},{},[188],{"type":37,"value":189},"\u003C4 дня",{"type":32,"tag":162,"props":191,"children":192},{},[193],{"type":37,"value":194},"3,2 дня",{"type":32,"tag":135,"props":196,"children":197},{},[198,203,208],{"type":32,"tag":162,"props":199,"children":200},{},[201],{"type":37,"value":202},"Время эскалации блокировки (blocker-метка → разрешение)",{"type":32,"tag":162,"props":204,"children":205},{},[206],{"type":37,"value":207},"\u003C6 часов",{"type":32,"tag":162,"props":209,"children":210},{},[211],{"type":37,"value":212},"4,7 часа",{"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'ей (за день на сколько issue'ы человек дотронулся)",{"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},"Метрика context switch'ей критична: асинхронность нацелена на deep work, но если человек за день дотрагивается до 6 issue'ев, то даже асинхронно работа фрагментирована. 2,4 среднее здорово — утро 1 issue, после обеда 1 issue, вечер review.",{"type":32,"tag":33,"props":237,"children":238},{},[239],{"type":37,"value":240},"Эти метрики еженедельно автопостятся в Slack #metrics-канал (Linear API + Zapier), каждый видит свою производительность. Feedback loop числовой — асинхронная дисциплина становится культурой. Новый разработчик на 2-й неделе слышит от peer'а \"почему ты не пишешь progress в Linear?\" — не от manager'а. Этот культурный pressure — гарантия асинхронности.",{"type":32,"tag":40,"props":242,"children":244},{"id":243},"взгляд-founderа-не-время-а-экономика-контекста",[245],{"type":37,"value":246},"Взгляд founder'а: не время, а экономика контекста",{"type":32,"tag":33,"props":248,"children":249},{},[250],{"type":37,"value":251},"ROI асинхронной команды не считается в часах. Если 12-человеческая команда не проводит 2 встреч в неделю, мы сэкономили 24 часа — это неправильный расчёт. Истинный выигрыш: нулировать стоимость context switching. На синхронном standup все одновременно switch контекста, после встречи 15-20 минут уходят на возврат в старый контекст. На асинхронном обновлении каждый пишет в своём потоке — context loss = 0.",{"type":32,"tag":33,"props":253,"children":254},{},[255,257,266],{"type":37,"value":256},"В work'ах Roibase по ",{"type":32,"tag":258,"props":259,"children":263},"a",{"href":260,"rel":261},"https:\u002F\u002Fwww.roibase.com.tr\u002Fru\u002Fbranding",[262],"nofollow",[264],{"type":37,"value":265},"идентичности бренда",{"type":37,"value":267}," мы применяем эту же дисциплину: feedback клиента открывается issue в Linear, дизайнер асинхронно отвечает, итерация revision крутится без встреч. Количество client-встреч упало на 60%, скорость delivery выросла. Потому что дизайнер не ходит на 10:00 встречу и не теряет flow, а проводит 3-часовую design session после обеда.",{"type":32,"tag":33,"props":269,"children":270},{},[271],{"type":37,"value":272},"Критичный трейдофф асинхронной дисциплины: спонтанное решение замедляется. Если нужно срочное архитектурное решение, Linear comment thread'ом 4 часа, Zoom'ом 15 минут. Это приемлемо — не каждое решение срочно. На неделю 1-2 срочных решения — провести синхронную встречу для них лучше, чем проводить 10 рутинных встреч на неделю.",{"type":32,"tag":33,"props":274,"children":275},{},[276],{"type":37,"value":277},"Linear + асинхронная standup дисциплина не уменьшает операционный overhead, а смещает его: вместо организации встреч нужна Linear hygiene (issue tagging, priority update, blocker flagging). Но это 30-минутная daily routine одного person'а (product lead), не 1-часовая встреча 12 человек. Система масштабируется. На 18 человек один и тот же pattern работает — растёт не количество встреч, а volume issue'ев.",{"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:ru:lifestyle:linear-async-standup-12-kisilik-ekip.md","content","ru\u002Flifestyle\u002Flinear-async-standup-12-kisilik-ekip.md","ru\u002Flifestyle\u002Flinear-async-standup-12-kisilik-ekip","md",1778306636673]