Практическое пособие по управлению телевизионным производством

Существует немало сфер, в которых нет места разнообразным «Ой, забыл» и «Я писал, а они не ответили». Просто потому, что на выходе бизнес-процесса должен бесперебойно появляться востребованный продукт, и никаких задержек с этим быть не может. Одна из таких сфер – телевизионное производство: с какими бы сложностями не столкнулась компания и как бы ни старались подвести ее поставщики и подрядчики, включивший телевизор зритель в любом случае должен увидеть качественный и ожидаемый контент.

Сегодняшний гость нашей постоянной рубрики Рассказ от первого лица, руководитель отдела производственной автоматизации компании PikeMediaLab Генрих Петров, знает об этом не понаслышке. И это делает опыт организации этого процесса в ПланФиксе, которым он с нами делится, особенно интересным.

Генрих Петров: Пролог или коротко о нас. Наша компания «ПайкМедиаЛаб» занимается комплексным обслуживанием телевизионных каналов. В настоящее время мы проводим техническую подготовку для более чем 20 телеканалов, вещающих как в России, так и за рубежом. Среди наших клиентов каналы «Мульт» и «МультиМузыка», «Настоящее страшное телевидение» и «Страшное HD», «Русский роман» и «Русский бестселлер», «Моя планета» и «Наука 2.0», и другие.

Как у любого бизнеса, у нас есть множество различных типов задач – производственных, финансовых, юридических, задач по техническому обслуживанию и делопроизводству. Еще три года назад мы решили использовать для управления этими задачами систему автоматизации, и, опробовав пять разных решений, мы остановились в конечном счете на ПланФикс.

Почему ПланФикс?
Во-первых, идеология ПланФикс оказалась достаточно гибкой и позволила нам решать задачи как по управлению производством и проектами, так и по управлению документооборотом.

Во-вторых, построить адаптированную под собственные задачи систему здесь можно без привлечения программистов.

Мы перенесли в ПланФикс не только производственные задачи, но и создали на его базе систему электронного документооборота и внутреннюю службу технического сопровождения. Конечно, не все ещё отлажено до идеала и процесс «доработки напильником» будет длиться ещё некоторое время, но прогресс очевиден.

Дальше я постараюсь без излишней специфической терминологии рассказать и показать, что же у нас получилось.

 

Задачи
Мы определили следующий список задач, которые должны выполняться системой:

  • Контроль производственных процессов
    • Проведение ОТК и редакторского отсмотра; подготовка эфирных версий
    • Подготовка сеток вещания; подготовка рекламных и эфирных плей-листов
    • Производство промо материалов
  • Электронный документооборот
    • Согласование договоров, доп.соглашений и т.п. документов
    • Хранение промежуточных и финальных версий в редактируемом и сканированном форматах
    • Согласование и проведение заявок; оплата счетов
  • Ведение заявок на техническую поддержку
  • Сбор статистики и расчет KPI по выполненным задачам
    • Количество или объём
    • Затраченное время и вид операции
    • Количество возвратов на доработку

Подготовка внедрения
Сам процесс подготовки внедрения виделся так:

  1. Создание структуры проектов и задач (дерево навигации)
  2. Определение необходимых доп.данных в системе
    a. Создание пользовательских справочников
    b. Создание доп.полей проектов и задач
  3. Формирование шаблонов
    a. Проектов
    b. Задач
    c. Повторяющихся задач
  4. Создание виртуальных почтовых адресов
  5. Статусы
    a. Формирование статусных моделей для процессов
    b. Построение автоматических сценариев
  6. Настройка автоматических сценариев
  7. Заполнение данных
    a. Структура компании
    b. Пользовательские справочники
    c. Контрагенты
  8. Пользовательская настройка
    a. Фильтры
    b. Планировщики
    c. Отчёты

Внедрение производственных задач
Итогом нашей работы является то, что каждый зритель видит на экране своего телевизора, поэтому весь производственный процесс подготовки идеально выстроен хронологически. Итог работы – эфирный плей-лист – должен быть сдан в чётко определенное время, ни раньше, ни позже, а каждый из этапов имеет определенную длительность. Это очень похоже на конвейер.

Начинается процесс примерно за 2-3 недели до начала недели вещания с подготовки расписания (по сути – той самой программы передач, которая публикуется практически всеми телеканалами в различных СМИ).

Затем происходит подготовка медиафайлов основных событий (фильмов, программ и т.п.). Файлы проходят технический контроль и редакционную подготовку, происходит разметка под вставку рекламы (куда ж без этого «двигателя»).

На следующем этапе формируется рекламная сетка, простым языком – определяются места и длительность рекламных блоков. Такая рекламная сетка отправляется в рекламное агентство, где происходит заполнение блоков уже фактическими рекламными роликами. Итогом такого заполнения становится рекламный плей-лист, который рекламное агентство присылает нам.

На последнем этапе подготовки рекламный плей-лист импортируется в эфирный день, размещаются различные анонсы, графика и прочая мелочёвка.

По окончании подготовки плей-лист телеканала отправляется в вещательный комплекс, где он проходит финальную проверку.

В общем-то все просто. Однако, каждый из этапов содержит большое количество проверок и различных согласований, в том числе с клиентами или партнерами. При этом на каждом из каналов существуют свои, индивидуальные правила, касающиеся каждого из этапов подготовки.

Весь производственный цикл у нас уже был расписан в виде совокупности технологических карт, что значительно упростило процесс построения системы, начиная от формирование статусной модели и логики переходов, до необходимости дополнительных параметров в задачах или проектах.

Общая схема формирования эфирных телеканалов

Схема приёма и обработки контента

Со статусами мы допустили небольшую ошибку: не учли, что количество статусов ограничено тарифным планом и его нельзя увеличить как, например, количество сотрудников или объём дискового пространства, поэтому делали уникальные статусы под каждый процесс. Впоследствии пришлось некоторые статусы сделать более универсальными и применять один и тот же статус в различных процессах. Например, изначально проверочные статусы были у каждого процесса свои. В последствии оставили один «На проверку». При этом данный статус в одних процессах направлял задачу руководителю подразделения, в других – партнеру или клиенту.

На текущий момент у нас используется 84 статуса (хотя думаю, что можно еще немного оптимизировать). Есть универсальные, есть статусы под конкретные процессы.

Пример статусов

 

Следующим этапом подготовки стало формирование пользовательских справочников:

  • Телеканалы
  • Типы договоров
  • Предмет договора
  • И несколько специализированных справочников, например, по типам брака для входящих медиафайлов.

Почему именно справочники? Если при формировании шаблона задачи необходимо создать дополнительное поле с заранее известными значениями, то предпочтительнее использовать справочники, даже если значений в нём будет всего 2-3, потому что:

  • это экономит время сотруднику при создании задач;
  • это позволяет избежать опечаток и ошибок при заполнении;
  • это позволяет в дальнейшем на основе данных такого поля строить фильтры задач, использовать в планировщике или отчёте, не опасаясь опечаток или ошибок.

Ещё один специализированный справочник – типы работ. В нем описаны все возможные типы работ для каждого подразделения и эти данные используются сотрудниками при формировании аналитик о фактическом времени работы (об этом подробно будет далее).

Типы работ отдела Трафика

 

Следующим этапом было определение под какие задачи требуются специальные шаблоны, построение таких шаблонов и создание повторяющихся задач.

Как уже отмечено выше, процесс подготовки вещания похож на конвейер, где часом ноль является момент сдачи плей-листа в эфирный комплекс и каждая операция проходит в четко заданный промежуток времени. Описание всех процессов займет много времени, поэтому остановимся на подготовке эфирных плей-листов.

Сначала был создан шаблон задачи и настроено доп.поле “Выбор телеканала” ссылающееся на справочник.

Шаблон задачи подготовки эфирного плей-листа

 

Затем на основе шаблона созданы повторяющиеся задачи для каждого телеканала.

Настроено создание подзадачи у основной задачи подготовки:

  • формирование рекламного плей-листа для отдела трафика. Задача формируется в момент создания основной задачи.
  • вещание канала. Задача создается в момент перевода основной задачи в определённый статус.Основная и вложенная задачи процесса подготовки эфирного плей-листа

Назначений у подзадач несколько.
Во-первых, задачи идут по своим статусным моделям и сценариям.
Во-вторых, уменьшение количества почтовых уведомлений у участников. К сожалению, на текущий момент уведомления об изменении статуса задачи нельзя настроить так, чтобы по одному статусу уведомления присылались определённой группе участников, а по другому статусу – нет.

Набор статусов процесса производства эфирного плей-листа

 

Сценарии процесса производства эфирного плей-листа

 

В итоге у нас получилась следующая схема:

  1. За 7 дней до даты вещания автоматически создаётся основная задача пока без подключения исполнителей.
  2. Тут же создается подзадача по формированию рекламного плей-листа.
  3. Отдел трафика (занимается рекламой) ведёт подзадачу – принимает данные от рекламного агентства, добавляет внутреннюю рекламу, корректирует, согласовывает и т.д.
  4. По завершении подзадачи рекламного плей-листа автоматическим сценарием изменяется надзадача – в неё добавляются исполнители – отдел планирования. При этом подзадача по формированию рекламного плей-листа должна закончиться не позднее, чем за 3 дня до даты вещания.
  5. Далее основную задачу ведет отдел планирования. Формируется, проверяется и согласовывается эфирный плей-лист.
  6. По окончании подготовки основная задача переводится в определённый статус и по этому статусу автоматическим сценарием создается подзадача для специалистов эфирного комплекса, по которой они понимают, что электронный плей-лист можно брать в работу. Дополнительно в этой же подзадаче выкладывается печатная версия эфирного плей-листа в формате Excel.
  7. Специалисты эфирного комплекса проводят свои проверки, уведомляют о результатах проверок и проводят вещание эфирного дня телеканала, по окончании которого переводят свою подзадачу в статус «Выполненная».
  8. По этому статусу у основной задачи автоматическим сценарием меняется статус для импорта специального лога о фактическом прохождении событий в эфире телеканала. Сотрудник отдела планирования сверяет данные о запланированном порядке выхода событий в эфире т/к с фактическим и готовит специальный отчёт.
  9. Руководитель отдела планирования закрывает задачу.

В дальнейшем для удобства были настроены фильтры и планировщик на котором видно всё движение задач

Планировщик процесса формирования эфирных плей-листов по этапам

Настроены аналитики затраченного времени и отчёты, по которым видна загрузка сотрудников отдела и количество задач, возвращенных задач на доработку исполнителем (по статусной модели).

Отчёт о затраченном времени

 

Итоговая статистика за период

Путем незначительных манипуляций с Excel получается финальный отчёт по отделу показывающий детальную статистику, в которую можно добавить коэффициенты сложности операций и получить KPI сотрудника.

А вот так выглядит планировщик в эфирном комплексе

Планировщик эфирного комплекса

 

Создание электронного документооборота
Пожалуй, самым сложным был именно этот этап. Собственных знаний процессов не хватило, поэтому большое спасибо нашим финансистам и делопроизводству за терпение и уделённое время)).

Типов договоров в нашей компании немного. Всего три:

  • АХО (административно-хозяйственные)
  • Технические
  • Производственные

С АХО и Техническими проблем не возникло. А вот производственные договоры добавили нам несколько непростых часов и даже дней размышления. По итогам, финальный вариант работоспособен, но не идеален. Пожалуй, основным минусом является большое количество уведомлений пользователям, но пока вариантов улучшить данное решение мы не нашли.

Сложность заключается в том, что у нас несколько вариантов производственных договоров в зависимости от количества оказываемых услуг. Некоторые каналы у нас идут по полному циклу сборки от А до Я. Некоторые только по каким-либо составляющим, например, только по подготовке контента или по хранению медиафайлов или по рекламному сопровождению.

Соответственно, в каких-то из договоров требуется согласование руководителей всех производственных подразделений, в каких-то только части, а в каких-то нужно согласовать всего с одним. Плюс, хотелось построить универсальный шаблон. Исходя из этой логики был создана вот такая конструкция.

Шаблон задачи доходного договора

Тип договора и Предмет договора – это поля со ссылкой на соответствующие справочники. Тип – это уже перечисленные три варианта. Предмет договора – это перечень услуг:

Справочник «Предмет договора»

Поле «Регулярная отчетность» управляет автоматическим созданием подзадач по закрывающим документам (будет описано ниже).

Поле «Требуется загрузка в Директум» влияет на переход по статусной модели (у одного из наших клиентов установлена система «Директум» и мы обязаны загружать туда документы, ждать согласования и только потом отправлять их на подписание руководителями компании).

Далее логические поля согласования по отделам. Фактически, где флаг установлен, в тот отдел попадет этап согласования.

Первое поле «Требуется проект договора» отвечает за наличие/отсутствие черновика договора. Если его нет – задача попадает к юристам для его создания, а уже затем запускается процесс согласования.

Исполнителей, участников и аудиторов в шаблоне нет. Они в дальнейшем заполняются автоматическими сценариями в зависимости от условий задачи.

Поле «Связанные задачи». По существующей логике ПланФикса, напрямую можно настроить взаимодействие у связки надзадача-подзадача. Можно настроить связь между задачами, находящимися в одном проекте. Но никак нельзя связать задачи из разных проектов.

В нашей модели, в основном это касается технических договоров и связано с профессиональной деятельностью, финансистам иногда требуются дополнительные сведения – для какой цели заключается тот или иной договор. От этого зависит как правильно поставить оборудование или ПО на бухгалтерский учёт и т.п.

Именно в задачах технической дирекции происходит полное описание проекта,внутреннее обсуждение, корректировка, подводятся промежуточные итоги. Бывает и так, что проект один, а договоров на этот проект несколько. Или они могут быть от разных подрядчиков.Или от одного подрядчика, но разные по типу – например, отдельный договор на лицензирование и отдельный договор на работы.

Поэтому схему построили именно так – в задачах тех.дирекции детали какого-либо проекта, а в задаче договора ссылка. Не совсем изящный вариант – но он работает.

Вот так выглядит статусная модель

Набор статусов согласования договоров

Некоторые статусы никуда не ведут – это связано с тем, что переходом управляют автоматические сценарии, которые направляют задачу в зависимости от начальных условий.

Вот так выглядят автоматические сценарии при создании задачи. Эти сценарии отвечают за добавление в качестве участников руководителей производственных подразделений, у которых установлены флаги согласования.

Набор сценариев согласования договоров

Параметры сценария простые, если установлен флаг в определенном поле – добавляется определенный участник. Таким образом при формировании задачи мы имеем заполненный автоматически список только нужных для данного договора участников.

Сценарий добавления участника

Вот так выглядит список автоматических сценариев при изменении задачи (увы, все не уместились).

Набор сценариев изменения задачи

Задачи этих сценариев также не сложные, они перенаправляют задачу последовательно от одного согласующего к другому. Просто их получилось много и чтобы не запутаться – пришлось даже ввести нумерацию в названии.

Пример задачи

 

Таким образом был построен процесс последовательного согласования документов и получения подписанных экземпляров.
Выглядит процесс так:

  1. Создание проекта (черновика) договора
  2. Согласование технических параметров медиафайлов (при необходимости)
  3. Согласование производственных подразделений
    a. Отдел программирования детских и развлекательных каналов
    b. Отдел программирования познавательных каналов
    c. Отдел трафика
    d. Отдел приёма и обработки контента
    e. Отдел промотирования
  4. Согласование административных служб
    a. Бухгалтерия
    b. Финансовый отдел
    c. Юридический отдел
  5. Согласование с контрагентом
  6. Согласование и подписание руководством компании
  7. Отправка подписанных экземпляров контрагенту
  8. Ожидание подписанных экземпляров
  9. Загрузка подписанных сканированных копий
  10. Перевод задачи в статус «Действующий договор» или «Завершённая»

В финале мы получаем раздел системы, где хранятся все договоры, в редактируемом виде (Word) и отсканированная подписанная версия.
Ну а настроенный планировщик дает возможность всем участникам процесса отслеживать на какой стадии находится определённая задача.

Планировщик договоров по статусам

В случае, если у задачи стоит флаг «Регулярная отчетность», то при переводе в статус «Действующий договор» сценарием создается подзадача по формированию закрывающих документов за текущий месяц. В дальнейшем, когда одна подзадача завершается, по ее закрывающему статусу создается новая на следующий период.

Сценарий создающий подзадачу по статусу и флагу

По аналогии были созданы процессы по формированию расходных договоров и согласованию счетов, которые идут без договора.

Создан процесс регистрации входящей и исходящей корреспонденции.

Настроен проект по ведению графика встреч компании.

Отдельно несколько слов о проекте ведения задач технической дирекции, как одного из самых значимых подразделений.
Проект состоит из:

  • Проекта задач руководства Технической дирекции
    • План-графика бюджета Технической дирекции
  • Проектов внутренних задач подразделений
    • По технической поддержке офисной и производственной части
    • По ведению задач инженерного состава эфирного комплекса

Шаблон по задачам руководителей ТД и бюджета выглядит следующим образом.

Шаблон задачи тех.дирекции

В принципе, ничего уникального. Код бюджета – справочник, строка – порядковый числовой номер, в текущей версии заполняется руками, так как на момент внедрения бюджет уже был сформирован, в дальнейшем прикрутим автоматическую считалку последовательно прибавляющую +1 к последнему значению. Кстати, такой же принцип работает при регистрации входящей корреспонденции.

В этих задачах происходит полное описание проекта, его обоснование, поставленные цели, ТЭО и т.п. информация.

Задачи в данном проекте являются головными задачами имеющими множество многоуровневых подзадач, некоторые из которых должны быть включены в планировщик, другие нет. Поэтому для включения задач в планировщик есть поле с флагом «Включить задачу в план-график».

Планировщик тех.дирекции

 

Пример подзадач

 

Для удобства проведения летучек в этом проекте настроен процесс «Последний комментарий», который по пятницам рассылает напоминание по задачам со статусом «В работе».

Напоминание

 

В самом шаблоне сделано текстовое поле «Последний комментарий» и настроен сценарий, который при добавлении действия в задачу копирует текст комментария в поле.

Сценарий напоминания

Таким образом в планировщике отображается последний комментарий по задаче.

На практике это выглядит так. В пятницу во второй половине дня рассылается автоматическое уведомление (напоминание). Сотрудник, получивший такое уведомление, пишет комментарий с краткими итогами по задаче. И в понедельник утром уже не нужно вспоминать – все кратко отображено на экране.

***

Описать весь используемый функционал в рамках одной статьи практически невозможно – получилось бы много и нудно. Процесс внедрения занял около двух месяцев начиная от написания ТЗ до рабочей версии силами собственной команды без привлечения каких-либо специалистов. В ближайших планах прикрутить 1С бухгалтерию и получать в бюджетных задачах информацию по оплате. Ну а в будущем – идей много, посмотрим…

Генрих Петров 

Заместитель технического директора

 

 

 

P.S. Поделитесь своим опытом использования ПланФикса — наверняка, у вас есть интересные решения и полезные лайфхаки, с которыми интересно будет познакомиться многим нашим читателям. Присылайте свои истории в нашу Службу поддержки с темой «Рассказ от первого лица», я с удовольствием их опубликую.

29 Comments

      1. Мне кажется умирает сам принцип, где есть «Отдел программирования детских и развлекательных каналов».
        Когда трёхлетний ребёнок у бабушки первый раз увидел телевизор, был очень удивлён, что за него кто-то будет решать, что именно ему смотреть и что рекламу (куда ж без этого «двигателя») нельзя промотать.

        1. Потребление контента растет, индустрия растет. Люди как хотели развлекаться, так и будут хотеть, даже больше, потому что меньше будут заняты выживанием.

          А программу теперь составляют алгоритмы, да. Ну и что? Переименуют отдел, изменят процессы — перенастроят некоторые планировщики в Планфиксе 😀

          1. Согласен, можно и перенастроить всё, если не хочешь умереть. Пожелаю PikeMediaLab не останавливаться в интеграции Планфикса, создать в нём алгоритм для составления индивидуальной программы для каждого зрителя, и главное, потока идей для создания интересного контента. Как сделаете, я чур первый в бетатестеры.

            1. Алексей, спасибо за пожелания. «…алгоритм для составления индивидуальной программы для каждого зрителя» это называется нелинейное телевидение или Video on Demand (VOD). И наша компания активно занимается этим направлением как одним из множества.

  1. Спасибо за пример и подробности! Очень полезно видеть такие разборы. Почерпнул идей.

    Вижу плэйсхолдеры для ролей и отделов в исполнителях задач, например [Делопроизводство]. Заменяете потом на конкретных исполнителей или оставляете группу? Как не размывать ответственность, если несколько исполнителей?

    1. Стас, здравствуйте.
      В шаблоне задачи устанавливаем параметр «Первый принявший исполнитель, остальные участники». Таким образом у каждой задачи есть конкретный исполнитель.

  2. Спасибо за такой подробный кейс. Есть что взять на заметку.
    Есть 3 вопроса 🙂

    1) Вы пишете
    «В итоге у нас получилась следующая схема:
    За 7 дней до даты вещания автоматически создаётся основная задача пока без подключения исполнителей.»

    Вопрос: Как вы автоматически создаёте задачу по условию «за 7 дней до даты Х»? Именно автоматически.

    2) Вот по этому бизнес-процессе — http://prntscr.com/mxatar
    Не понял, а как он запускается сам? Там же условие «Задача создана или изменена». А если в течение пятницы по задаче я не делал никаких действий?

    3) Как думаете, сколько трудочасов ушло у всех людей на внедрение работы по таким правилам от идеи до реализации?

  3. Сергей, здравствуйте.
    Отвечу по пунктам.

    Вопрос: Как вы автоматически создаёте задачу по условию «за 7 дней до даты Х»? Именно автоматически.

    Настроен шаблон задачи который имеет длительность 7 дней.
    В названии используются переменные «Плей-лист {{Задача.Выбор т/к}} {{Задача.Закончить работу}}». В итоге имеем название у задачи, например, «Плей-лист Мульт 15 марта»
    Далее по этому шаблону настроена повторяющая задача с условием повторения каждый день.
    То есть каждый день по каждому телеканалу создается задача с датой эфира на 7 дней вперед.

    1. 2. Сергей, а Вам удалось посеять зерно сомнений. Эту «плюшку» встроили недавно. Понаблюдаю и вернусь с ответом.

      3. Сложно сходу сказать. Внедрение ПФ шло неотрывно от основных процессов, которые, естественно, имеют высший приоритет.
      Примерно 330-360 человекочасов.
      Доработки согласно пожеланиям сотрудников еще порядка 80 часов.

  4. Спасибо за ответ. Стало понятно. У вас каждый день такие задачи нужны. Я думал, что я упустил какую-то магию и можно создавать задачу автоматически до даты Х в любой нужный момент 🙂

  5. а если кто-то из Исполнителей/Аудиторов/Постановщиков увольняется, а он прописан во многих сценариях, правилах? Тогда руками везде нужно его заменить на другого сотрудника?

    Что предусмотрено на этот счет в ПФ?

    1. Леонид, здравствуйте.
      Помимо описанного способа с ролями, в ПланФиксе реализована функция «передать задачи», которая находится в карточке сотрудника и внутри карточки вкладка в виде стрелки.
      И в случае увольнения сотрудника можно передать все его задачи на другого исполнителя.
      Передача ролей постановщик\аудитор\участник может быть реализована при помощи массовых изменений. Необходимо настроить фильтр на уволенного сотрудника, выбрать задачи удовлетворяющие фильтру, нажать на кнопку изменить и задать необходимые изменения.

      1. А подскажите, описанный вами метод через «передать задачи» по функционалу — полная копия функционала «роли»? Или нет? Хочется понять, когда надо использовать первый способ, а когда второй. Если убрать фактор «кому как удобно»

        1. Сергей, здравствуйте.
          Для сценариев, на наш взгляд, оптимально использовать группы пользователей.
          Однако, могут быть ситуации, когда у конкретной задачи конкретный исполнитель.

          Например. В сценарии задаем группу исполнителей. В шаблоне условие — первый принявший исполнитель, остальные либо отключаются, либо участники (все равно).
          В результате имеем ряд задач в которых исполнитель конкретный сотрудник.
          Допустим этот сотрудник увольняется. Вот в этом случае и используем функционал «передать задачи» (передаются только задачи, где сотрудник исполнитель).
          Кстати там же есть и временная передача «Задать ВРИО», например, на время отпуска .

    1. Александр, здравствуйте.
      Хранение медиаданных происходит в системах МАМ (MediaAssetManagment). Там же хранится полное описание каждого тайтла в зависимости от типа хранения или использования.
      Сейчас мы прорабатываем возможность интеграции между МАМ и Планфксом (есть идеи). Возможно, по результатам напишем новую статью.

        1. Конечно используем. Например, договоры лежат в редактируемых и сканированных версиях.
          Есть база знаний (своего рода Wiki) с большим объемом документов.
          Есть внутренние документы отделов и компании к целом.
          Есть отчетные документы.
          Есть даже не большие по объему временные медиафайлы. Но их мы стараемся не держать в большом количестве и длительное время.
          За 6 месяцев набралось чуть более 20 Гб.

Добавить комментарий