[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"general-list":3,"footer-feature-tags":4,"slate-glossary-term-metod-kriticheskoy-cepi-ccpm":66},true,[5,14,20,29,34,40,46,52,56,62],{"id":6,"name":7,"hex":8,"translations":9,"count_pages":13},8,"Компания","#f40925",{"ru":10,"en":11},{"name":7},{"name":12},"Company",9,{"id":15,"name":16,"hex":17,"translations":18,"count_pages":6},26,"Главная страница",null,{"ru":19},{"name":16},{"id":21,"name":22,"hex":23,"translations":24,"count_pages":28},2,"Проекты","#3027ff",{"ru":25,"en":26},{"name":22},{"name":27},"Project",15,{"id":30,"name":31,"hex":17,"translations":32,"count_pages":21},33,"ИИ",{"ru":33},{"name":31},{"id":35,"name":36,"hex":17,"translations":37,"count_pages":39},34,"Комментарии",{"ru":38},{"name":36},4,{"id":41,"name":42,"hex":17,"translations":43,"count_pages":45},25,"Задачи",{"ru":44},{"name":42},24,{"id":47,"name":48,"hex":17,"translations":49,"count_pages":51},27,"Рабочие пространства",{"ru":50},{"name":48},3,{"id":45,"name":53,"hex":17,"translations":54,"count_pages":6},"Kanban-доска",{"ru":55},{"name":53},{"id":57,"name":58,"hex":17,"translations":59,"count_pages":61},23,"Диаграмма Ганта",{"ru":60},{"name":58},1,{"id":28,"name":63,"hex":17,"translations":64,"count_pages":61},"Календарь",{"ru":65},{"name":63},{"detail":67,"more":245},{"id":68,"slug":69,"translations":70,"category":84,"tags":91,"letter":122,"og_image":17,"cover":17,"author_name":17,"author_position":17,"author_avatar":17,"faqs":123,"related":155,"views_count":241,"helpful_yes_count":126,"helpful_no_count":126,"created_at":242,"updated_at":243,"published_at":244},381,"metod-kriticheskoy-cepi-ccpm",{"ru":71},{"title":72,"short_definition":73,"tldr":74,"full_explanation":75,"when_to_apply":76,"when_not_to_apply":77,"examples":78,"tips":79,"synonyms":80,"translation_en":81,"seo_title":82,"seo_description":83},"Метод критической цепи (CCPM)","Метод планирования проектов, который убирает скрытые резервы из оценок задач и переносит их в управляемые буферы, защищающие дату завершения.","Оценки задач сокращают примерно на 50%, а «срезанное» время собирают в проектный буфер в конце расписания.\nКритическая цепь — самая длинная последовательность задач с учётом ресурсных ограничений, а не только логических зависимостей.\nТри типа буферов: проектный, питающие и ресурсный — заменяют контроль каждого отдельного дедлайна.\nМетод даёт ощутимый эффект в строительстве и производстве; в IT с нечёткими требованиями результат скромнее.\nВнедрение требует культурного сдвига: команда не должна наказываться за использование агрессивных оценок.","\u003Ch2>Суть метода: почему запас в каждой задаче — проблема\u003C\u002Fh2>\u003Cp>Когда менеджер просит оценить задачу, исполнитель закладывает страховку: «лучше сказать три дня, чем обещать два и не успеть». Это рационально с точки зрения отдельного человека, но разрушительно для проекта в целом. Два психологических механизма съедают этот запас ещё до того, как он мог бы помочь.\u003C\u002Fp>\u003Cp>\u003Cstrong>Закон Паркинсона\u003C\u002Fstrong>: работа расширяется, заполняя всё отведённое время. Если на задачу дано три дня — она займёт три дня, даже если реально требует полтора. \u003Cstrong>Студенческий синдром\u003C\u002Fstrong>: исполнитель откладывает старт до последнего момента, а потом работает в авральном режиме. Страховка потрачена, но не на непредвиденные риски, а на прокрастинацию.\u003C\u002Fp>\u003Cp>CCPM решает эту проблему радикально: скрытые резервы изымаются из оценок каждой задачи и собираются в явные, управляемые буферы. Вместо того чтобы каждый исполнитель хранил свой запас, проект держит общий резерв и расходует его осознанно.\u003C\u002Fp>\u003Ch2>Критическая цепь vs критический путь: в чём разница\u003C\u002Fh2>\u003Cp>Метод критического пути (CPM) строит расписание, опираясь только на логические зависимости задач: задача Б начинается после задачи А. Самая длинная такая цепочка — критический путь — определяет минимальный срок проекта.\u003C\u002Fp>\u003Cfigure>\u003Cimg src=\"https:\u002F\u002Fshtab.app\u002Fblog\u002Fcontent\u002Fimages\u002F2026\u002F08\u002Fcover-136.jpg\" alt=\"Два метода отличаются тем, что считается ограничением при построении расписания\" loading=\"lazy\" decoding=\"async\">\u003Cfigcaption>Два метода отличаются тем, что считается ограничением при построении расписания\u003C\u002Ffigcaption>\u003C\u002Ffigure>\u003Cp>Критическая цепь идёт дальше. Она добавляет \u003Cstrong>ресурсные ограничения\u003C\u002Fstrong>: один инженер не может одновременно работать над двумя задачами, даже если логически они независимы. Критическая цепь — это самая длинная последовательность задач с учётом и логических зависимостей, и конкуренции за ресурсы.\u003C\u002Fp>\u003Cp>На практике это означает, что критическая цепь часто длиннее критического пути и включает задачи, которые CPM считал некритическими. Игнорировать ресурсные конфликты при планировании — значит получать срывы сроков по причинам, которые «не были видны» в расписании.\u003C\u002Fp>\u003Ch2>Три типа буферов и как ими управлять\u003C\u002Fh2>\u003Cp>Буферы — главный инструмент управления в CCPM. Их три вида, и у каждого своя роль.\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>Проектный буфер (Project Buffer)\u003C\u002Fstrong> — размещается в конце критической цепи, перед датой завершения проекта. Защищает финальный дедлайн от накопленных задержек на критической цепи. Это главный индикатор здоровья проекта.\u003C\u002Fli>\u003Cli>\u003Cstrong>Питающие буферы (Feeding Buffers)\u003C\u002Fstrong> — размещаются в точках, где некритические ветки задач «впадают» в критическую цепь. Защищают критическую цепь от задержек на параллельных работах.\u003C\u002Fli>\u003Cli>\u003Cstrong>Ресурсный буфер (Resource Buffer)\u003C\u002Fstrong> — не временной резерв, а сигнал. Ставится перед задачей на критической цепи, чтобы заранее предупредить ресурс: «готовься, скоро твоя работа».\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Мониторинг буферов строится по светофорной логике. Буфер делится на три зоны:\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>Зелёная зона\u003C\u002Fstrong> (0–33% потребления): всё в порядке, вмешательство не нужно.\u003C\u002Fli>\u003Cli>\u003Cstrong>Жёлтая зона\u003C\u002Fstrong> (33–67% потребления): нужно разработать план действий на случай ухудшения ситуации.\u003C\u002Fli>\u003Cli>\u003Cstrong>Красная зона\u003C\u002Fstrong> (67–100% потребления): план действий запускается немедленно.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Ключевой принцип: менеджер не контролирует каждый промежуточный дедлайн — он следит за скоростью потребления буферов относительно прогресса проекта. Если буфер расходуется быстрее, чем продвигается работа, это сигнал к действию.\u003C\u002Fp>\u003Ch2>Пошаговое построение расписания по CCPM\u003C\u002Fh2>\u003Col>\u003Cli>\u003Cstrong>Определить задачи и зависимости.\u003C\u002Fstrong> Составить сетевой граф: что за чем следует, какие задачи можно вести параллельно.\u003C\u002Fli>\u003Cli>\u003Cstrong>Назначить ресурсы и устранить конфликты.\u003C\u002Fstrong> Проверить, не назначен ли один ресурс на несколько задач одновременно. Разрешить конфликты, сдвигая задачи — это изменит критический путь и покажет критическую цепь.\u003C\u002Fli>\u003Cli>\u003Cstrong>Сократить оценки длительности примерно на 50%.\u003C\u002Fstrong> Попросить команду дать «агрессивные, но реалистичные» оценки — те, при которых задача выполняется примерно в половине случаев, а не в 95%. Это болезненный шаг: команда должна понимать, что опоздание при таких оценках — норма, а не провал.\u003C\u002Fli>\u003Cli>\u003Cstrong>Вставить буферы.\u003C\u002Fstrong> Рассчитать проектный буфер (обычно 50% от суммы срезанного времени по критической цепи) и питающие буферы для каждой некритической ветки.\u003C\u002Fli>\u003Cli>\u003Cstrong>Зафиксировать расписание и перейти к управлению буферами.\u003C\u002Fstrong> Дата завершения — это конец проектного буфера. Дальнейшее управление ведётся через мониторинг потребления буферов, а не через отслеживание каждого промежуточного дедлайна.\u003C\u002Fli>\u003C\u002Fol>\u003Ch2>Ограничения метода и типичные ошибки внедрения\u003C\u002Fh2>\u003Cp>CCPM — не универсальный инструмент. Его эффективность зависит от контекста.\u003C\u002Fp>\u003Cp>\u003Cstrong>Где метод работает хорошо:\u003C\u002Fstrong> строительство, производство, фармацевтические разработки, техническое обслуживание — там, где объём работ достаточно определён заранее. Практика внедрения в этих отраслях показывает значительный рост доли проектов, завершённых в срок, и существенное сокращение циклов.\u003C\u002Fp>\u003Cp>\u003Cstrong>Где эффект ограничен:\u003C\u002Fstrong> в IT-проектах с высокой неопределённостью требований CCPM работает хуже. Если объём работ меняется в процессе, буферы быстро исчерпываются не из-за исполнения, а из-за изменений содержания. В таких проектах Agile-подходы справляются лучше.\u003C\u002Fp>\u003Cp>\u003Cstrong>Типичные ошибки внедрения:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Команда продолжает закладывать скрытые резервы в оценки, не доверяя новому подходу — буферы оказываются избыточными, а метод теряет смысл.\u003C\u002Fli>\u003Cli>Менеджеры продолжают требовать соблюдения каждого промежуточного дедлайна — это возвращает студенческий синдром и обесценивает буферное управление.\u003C\u002Fli>\u003Cli>В мультипроектной среде без единого приоритета ресурсы по-прежнему распыляются между проектами — метод буксует без явной приоритизации портфеля.\u003C\u002Fli>\u003Cli>Отсутствие культурного сдвига: если опоздание при агрессивной оценке наказывается, команда быстро вернётся к раздутым оценкам.\u003C\u002Fli>\u003C\u002Ful>","\u003Cul>\u003Cli>Проект имеет чётко определённый объём работ и относительно стабильные требования — строительство, производство, фармацевтические разработки, техническое обслуживание.\u003C\u002Fli>\u003Cli>Ресурсы задействованы на нескольких задачах одновременно и их конфликты регулярно срывают сроки.\u003C\u002Fli>\u003Cli>Команда систематически не укладывается в сроки, несмотря на наличие резервов в оценках.\u003C\u002Fli>\u003Cli>Нужно сократить длительность проекта без увеличения численности персонала или бюджета.\u003C\u002Fli>\u003Cli>Организация готова к изменению культуры планирования: отказу от наказания за использование агрессивных оценок.\u003C\u002Fli>\u003C\u002Ful>","\u003Cul>\u003Cli>Требования к проекту нечёткие и меняются в процессе — в таких условиях буферы исчерпываются из-за изменений содержания, а не из-за исполнения; лучше подойдут Agile-подходы.\u003C\u002Fli>\u003Cli>Команда небольшая, задачи слабо связаны между собой и ресурсные конфликты редки — накладные расходы на управление буферами не оправданы.\u003C\u002Fli>\u003Cli>Организация не готова к культурному сдвигу: если агрессивные оценки будут наказываться, метод не заработает.\u003C\u002Fli>\u003Cli>Мультипроектная среда без единого приоритета портфеля — без явной приоритизации ресурсы продолжат распыляться между проектами.\u003C\u002Fli>\u003Cli>Проект краткосрочный (несколько дней) — затраты на построение буферного расписания превысят выгоду.\u003C\u002Fli>\u003C\u002Ful>","\u003Cp>\u003Cstrong>Dr. Reddy's Laboratories (фармацевтика, портфель НИОКР).\u003C\u002Fstrong> Компания страдала от низкой дисциплины исполнения: только 20% проектов завершались в срок. После внедрения CCPM с приоритизацией портфеля и управлением буферами доля проектов, завершённых вовремя, выросла до 80%. Цикл разработки лекарственных форм сократился на 40%, количество запусков дженериков на глобальном рынке выросло на 51%.\u003C\u002Fp>\u003Cp>\u003Cstrong>Строительный проект в Индонезии.\u003C\u002Fstrong> Традиционное планирование давало срок 541 день. После перехода на CCPM — с устранением ресурсных конфликтов и расстановкой питающих буферов — проект был запланирован на 295 дней (сокращение на 45,5%). Прогнозируемые затраты снизились на 29,6% за счёт более плотного использования ресурсов и сокращения накладных расходов.\u003C\u002Fp>\u003Cp>\u003Cstrong>Крупная IT-организация (обобщённый паттерн из практики внедрения CCPM).\u003C\u002Fstrong> При перегруженных ресурсах и хаотичной приоритизации только около 24% проектов выполнялись в срок. После внедрения Critical Chain для управления портфелем — с фокусом на наиболее приоритетных проектах и без увеличения штата — показатель своевременного выполнения для приоритетных проектов вырос до 85%, для всего портфеля — до 65%. Это типичная картина для организаций, переходящих от хаотичной многозадачности к явной приоритизации портфеля через CCPM.\u003C\u002Fp>","\u003Cp>В Shtab создайте отдельную задачу-буфер в конце цепочки зависимых задач на диаграмме Ганта. Назначьте ей длительность, равную сумме «срезанного» времени по критической цепи (обычно около 50% от исходных оценок). По мере возникновения задержек на задачах критической цепи фиксируйте их в комментариях к задаче-буферу и уменьшайте её оставшуюся длительность на величину задержки. Так буфер будет наглядно «таять», и команда в любой момент увидит, сколько резерва осталось. Если буфер расходуется заметно быстрее, чем продвигается проект — это сигнал к немедленному разбору причин, а не к ожиданию финального дедлайна.\u003C\u002Fp>","CCPM, критическая цепь, Critical Chain, Critical Chain Project Management","Critical Chain Project Management (CCPM)","Метод критической цепи (CCPM): что это и как работает","Метод критической цепи (CCPM) — как срезать оценки задач, куда перенести резерв и как управлять буферами вместо дедлайнов. Механика, кейсы, ограничения.",{"id":51,"slug":85,"hex":86,"icon":17,"order":51,"translations":87},"pm-classic","#3a4058",{"ru":88},{"title":89,"description":90},"Классическое проектное управление","Традиционные методологии и инструменты PM: PMBOK, PRINCE2, PMI, WBS, RACI, диаграмма Ганта, критический путь, EVM, управление рисками и заинтересованными сторонами.",[92,98,106,114],{"id":61,"slug":93,"kind":93,"hex":94,"order":61,"translations":95},"methodology","#5e79ec",{"ru":96},{"title":97},"Методология",{"id":99,"slug":100,"kind":101,"hex":102,"order":99,"translations":103},7,"estimation","tool","#cc5649",{"ru":104},{"title":105},"Оценка",{"id":107,"slug":108,"kind":109,"hex":94,"order":110,"translations":111},11,"planning","phase",12,{"ru":112},{"title":113},"Планирование",{"id":115,"slug":116,"kind":117,"hex":118,"order":45,"translations":119},16,"risk","other","#ff6a6a",{"ru":120},{"title":121},"Риски","М",[124,131,137,143,149],{"id":125,"order":126,"translations":127},1671,0,{"ru":128},{"question":129,"answer":130},"Чем критическая цепь отличается от критического пути?","\u003Cp>Критический путь (CPM) строится только на логических зависимостях задач и показывает самую длинную последовательность работ по времени. Критическая цепь добавляет к этому ресурсные ограничения: один исполнитель не может работать над двумя задачами одновременно. Из-за этого критическая цепь часто длиннее критического пути и включает задачи, которые CPM считал некритическими. Второе ключевое отличие — CCPM заменяет индивидуальные резервы в оценках управляемыми буферами в конце цепочки.\u003C\u002Fp>",{"id":132,"order":61,"translations":133},1672,{"ru":134},{"question":135,"answer":136},"Как рассчитать размер проектного буфера в CCPM?","\u003Cp>Наиболее распространённый метод — метод «квадратного корня» (SSQ): берут срезанное время по каждой задаче критической цепи, возводят в квадрат, суммируют и извлекают корень из суммы. Более простой вариант — взять 50% от суммы всего срезанного времени по критической цепи. Оба подхода дают приблизительный ориентир; точный размер буфера корректируется с учётом исторической неопределённости конкретного типа проектов в организации.\u003C\u002Fp>",{"id":138,"order":21,"translations":139},1673,{"ru":140},{"question":141,"answer":142},"Можно ли применять метод критической цепи в IT-проектах?","\u003Cp>Можно, но с оговорками. CCPM хорошо работает в IT-проектах с чётко определённым объёмом работ — например, при внедрении готового ПО или миграции инфраструктуры. В проектах с высокой неопределённостью требований, где содержание меняется итерационно, буферы быстро исчерпываются не из-за задержек исполнения, а из-за изменений объёма. В таких случаях Agile-подходы справляются лучше, а CCPM может применяться как дополнительный инструмент управления портфелем.\u003C\u002Fp>",{"id":144,"order":51,"translations":145},1674,{"ru":146},{"question":147,"answer":148},"Как управлять буферами: зелёная, жёлтая и красная зоны?","\u003Cp>Буфер делится на три равные зоны по степени потребления. Зелёная зона (0–33% израсходовано): ситуация под контролем, активных действий не требуется. Жёлтая зона (33–67%): нужно разработать план действий и держать его наготове. Красная зона (67–100%): план запускается немедленно. Важно сопоставлять потребление буфера с прогрессом проекта: если 50% буфера потрачено, а проект выполнен на 80% — ситуация лучше, чем кажется.\u003C\u002Fp>",{"id":150,"order":39,"translations":151},1675,{"ru":152},{"question":153,"answer":154},"Как CCPM связан с теорией ограничений Голдратта?","\u003Cp>CCPM разработан Элияху Голдраттом и является прямым приложением теории ограничений (TOC) к управлению проектами. TOC утверждает, что производительность любой системы определяется её узким местом — ограничением. В проекте таким ограничением является критическая цепь: самая длинная последовательность зависимых задач с учётом ресурсов. CCPM концентрирует защитный резерв именно там, где он нужен — на критической цепи, — вместо того чтобы распылять его по всем задачам.\u003C\u002Fp>",{"related":156,"parent":233},[157,164,170,177,184,191,198,205,212,219,226],{"id":158,"slug":159,"translations":160},55,"critical-path",{"ru":161},{"title":162,"short_definition":163},"Критический путь","Самая длинная цепочка зависимых задач в проекте, определяющая минимально возможную длительность проекта.",{"id":165,"slug":166,"translations":167},54,"gantt",{"ru":168},{"title":58,"short_definition":169},"Графическое представление календарного плана проекта с задачами в виде горизонтальных полос на временной оси.",{"id":171,"slug":172,"translations":173},77,"resource-allocation",{"ru":174},{"title":175,"short_definition":176},"Resource Allocation (распределение ресурсов)","Распределение людей, оборудования и других ресурсов между задачами проекта по времени.",{"id":178,"slug":179,"translations":180},76,"float-slack",{"ru":181},{"title":182,"short_definition":183},"Float \u002F Slack (резерв времени)","Резерв времени, на который задачу можно сдвинуть или растянуть без срыва общего срока проекта.",{"id":185,"slug":186,"translations":187},155,"risk-management",{"ru":188},{"title":189,"short_definition":190},"Risk Management (управление рисками)","Систематический процесс выявления, анализа, реагирования и наблюдения за рисками, влияющими на цели проекта или организации.",{"id":192,"slug":193,"translations":194},195,"parkinson-law",{"ru":195},{"title":196,"short_definition":197},"Закон Паркинсона (Parkinson's Law)","«Работа заполняет время, отведённое на её выполнение» — закон Сирила Паркинсона (1955).",{"id":199,"slug":200,"translations":201},207,"bottleneck",{"ru":202},{"title":203,"short_definition":204},"Bottleneck (узкое место, бутылочное горлышко)","Этап процесса с наименьшей пропускной способностью, который ограничивает производительность всей системы.",{"id":206,"slug":207,"translations":208},52,"wbs",{"ru":209},{"title":210,"short_definition":211},"WBS (иерархическая структура работ)","Иерархическая декомпозиция работ проекта на управляемые пакеты сверху вниз.",{"id":213,"slug":214,"translations":215},56,"pert",{"ru":216},{"title":217,"short_definition":218},"PERT (оценка по трём точкам)","Метод оценки длительности задач через три оценки: оптимистичную, пессимистичную и наиболее вероятную.",{"id":220,"slug":221,"translations":222},75,"dependency",{"ru":223},{"title":224,"short_definition":225},"Dependency (Зависимость)","Связь между задачами или проектами, при которой одно не может начаться или завершиться без другого.",{"id":227,"slug":228,"translations":229},65,"baseline",{"ru":230},{"title":231,"short_definition":232},"Baseline (базовый план)","Утверждённая версия плана проекта по содержанию, срокам и бюджету — точка отсчёта для контроля отклонений и изменений.",[234],{"id":235,"slug":236,"translations":237},206,"theory-of-constraints",{"ru":238},{"title":239,"short_definition":240},"Теория ограничений (Theory of Constraints)","Методология Голдратта: производительность всей системы в каждый момент задаёт одно самое слабое звено — ограничение.",5,"2026-08-25T22:37:28.688953+03:00","2026-08-25T22:37:28.688980+03:00","2026-08-25T22:37:28.822297+03:00",[246,268,295],{"id":227,"slug":228,"translations":247,"category":250,"tags":253,"letter":266,"cover":17,"updated_at":267,"published_at":17},{"ru":248},{"title":231,"short_definition":232,"translation_en":249},"Baseline",{"id":51,"slug":85,"hex":86,"icon":17,"order":51,"translations":251},{"ru":252},{"title":89,"description":90},[254,260],{"id":39,"slug":255,"kind":117,"hex":256,"order":39,"translations":257},"artifact","#888ca0",{"ru":258},{"title":259},"Артефакт",{"id":6,"slug":261,"kind":117,"hex":262,"order":6,"translations":263},"concept","#4b5370",{"ru":264},{"title":265},"Концепция","B","2026-04-25T22:42:17.413625+03:00",{"id":269,"slug":270,"translations":271,"category":276,"tags":279,"letter":293,"cover":17,"updated_at":294,"published_at":17},61,"change-request",{"ru":272},{"title":273,"short_definition":274,"translation_en":275},"Change Request (Запрос на изменение)","Формальный документ, которым запрашивают изменение объёма работ, сроков, бюджета или других параметров проекта.","Change Request (CR)",{"id":51,"slug":85,"hex":86,"icon":17,"order":51,"translations":277},{"ru":278},{"title":89,"description":90},[280,283,286],{"id":39,"slug":255,"kind":117,"hex":256,"order":39,"translations":281},{"ru":282},{"title":259},{"id":6,"slug":261,"kind":117,"hex":262,"order":6,"translations":284},{"ru":285},{"title":265},{"id":287,"slug":288,"kind":109,"hex":262,"order":289,"translations":290},14,"process",22,{"ru":291},{"title":292},"Процесс","C","2026-04-25T22:42:17.323214+03:00",{"id":296,"slug":297,"translations":298,"category":303,"tags":306,"letter":293,"cover":17,"updated_at":313,"published_at":17},72,"contingency-plan",{"ru":299},{"title":300,"short_definition":301,"translation_en":302},"Contingency Plan (план реагирования на риск)","План действий на случай, если риск всё-таки наступит: что именно делает команда, чтобы снизить ущерб.","Contingency Plan",{"id":51,"slug":85,"hex":86,"icon":17,"order":51,"translations":304},{"ru":305},{"title":89,"description":90},[307,310],{"id":6,"slug":261,"kind":117,"hex":262,"order":6,"translations":308},{"ru":309},{"title":265},{"id":115,"slug":116,"kind":117,"hex":118,"order":45,"translations":311},{"ru":312},{"title":121},"2026-04-25T22:42:17.574403+03:00"]