Контент-календар: ресурси, погодження й резерв

Слот не дорівнює готовому матеріалу

Календар поєднує тему, потребу, формат і виробничий процес. У кожного слоту мають бути ID, умовний день, owner, reviewer, час підготовки, час перевірки та статус. Дата публікації без цих полів приховує роботу, яку хтось мусить виконати.

Наш календар охоплює 30 днів: 12 навчальних слотів і аналіз на 29–30 дні. Це не рекомендація постити саме тричі на тиждень. Число обране для вправи; студент може аргументовано змінити його. Дата вебінару не встановлена, тому не можна автоматично перетворити умовний день 13 на анонс «сьогодні ефір».

Розбір першого періоду

У C01 карусель потребує 60 хвилин, у C02 текст — 45, у C03 демонстрація — 90. Разом production: 195 хвилин. Три перевірки по 20 хвилин дають ще 60. Додаємо резерв 60: 195 + 60 + 60 = 315 хвилин при бюджеті 360. Залишається 45 хвилин, а не 105: резерв уже зайнятий своєю функцією.

У четвертому періоді додатково є 45 хвилин аналізу: 195 + 60 + 60 + 45 = 360. Там немає вільного часу для ще одного матеріалу без перенесення або зміни формату. Періоди тут 1–7, 8–14, 15–21 і 22–30 дні; останній навмисно довший, але його бюджет не збільшено.

Рахуйте обмеження, а не лише суму

Навіть якщо загальний бюджет не перевищено, reviewer може бути недоступний у потрібний день. У C03 release на день 6, review на день 5. Якщо погодження можливе лише на день 7, запис «reviewer: peer» не вирішує конфлікт. Перенесіть слот, оберіть готовий погоджений матеріал або погодьте інший реалістичний процес.

Не вимагайте «надолужити ввечері» як стандартного плану. Окремо перевіряйте доступність людей, послідовність етапів і те, чи одна людина не отримала дві несумісні задачі. Наш бюджет — сумарний навчальний ресурс; у реальній команді потрібні також індивідуальні навантаження.

Рух статусів

Простий процес: draft → review → approved → scheduled → published. Це опис вашого робочого файлу, не обіцянка автоматичного планувальника на сайті. Зміна факту після approved повертає матеріал на review. Статус scheduled не доводить, що публікація відбулася або виглядає правильно.

Перед умовним release перевіряються факти, TOV, доступність, посилання та наступна дія. Після нього потрібен огляд фактичного результату. Якщо знайшли неправдиву гарантію або витік даних, зупиніть матеріал незалежно від близькості дедлайну. Вправу виконуємо в симуляції, без доступу до реальних акаунтів.

Що робити, коли план не вміщується

Зменшіть обсяг, спростіть формат без втрати ключової користі, перенесіть низькопріоритетний слот або перевикористайте вже перевірений матеріал. Не викреслюйте перевірку, щоб арифметика виглядала красивою. Кожна зміна має зберегти зв’язок із потребою й бути відображена в decision-log.md.

Наприклад, заміна відео 90 хвилин на текст 45 звільняє 45 хвилин production, але лише якщо текст справді пояснює потрібну дію. Review не зникає, а новий формат має власний критерій доступності. Перераховуйте весь період після кожної заміни.

Практика

1. Переплануйте щонайменше чотири слоти та поясніть зміни.
2. Порахуйте budget для всіх чотирьох періодів.
3. Розв’яжіть ситуацію з недоступним reviewer перед C03.
4. Зазначте, що повертає approved-матеріал на перевірку і хто ухвалює рішення.

Готово, коли: бюджет і строки узгоджені, резерв збережено, а процес витримує затримку погодження без прихованого скасування QA.

Методичні джерела

• W3C WAI: доступність як частина виробничого процесу

Приклади, вправи та рішення — оригінальні матеріали SEOWORK.