Статуси задач та блокування полів

Канбан Tasks — статуси, дозволені переходи, автоматизація та які поля редагуються в якому статусі.

Стосується канбану Tasks і таблиці Creatives. Що означає кожне поле картки задачі, коли воно обов’язкове чи ховається — Поля картки задачі. Що саме відбувається в перші секунди після переходу в Ready for Production, і чому задача іноді повертається в Backlog — Автоматизація задач у канбані. ⚠️ Область дії: усе нижче (статуси, автоматизація, валідація, блокування назви) стосується виключно задач з Work Stream = Performance. Задачі інших Work Stream (Product, Web, Brand, SMM, HR тощо) автоматизацію/валідацію/блокування назви не проходять взагалі — рухаються довільним/спрощеним флоу поза межами цього документа.

1. Список статусів (у порядку процесу)

Таблиця й усі наступні розділи описують флоу тільки для Work Stream = Performance.

2. Діаграма переходів

ReadyForProduction / InProgress / TechCheck / CreativeCheck в діаграмі — це Ready for Production / In Progress / Tech Check / Creative Check (без пробілів через синтаксис mermaid).

3. Таблиця дозволених переходів

Те саме, що на діаграмі вище, але словами — з умовою для кожного переходу.

Ready for Production вимагає обидві Complexity

Design Complexity і Marketing Complexity не потрібні, щоб створити задачу — бриф пишуть раніше, ніж оцінено обсяг роботи. Але без них задача не заїде в Ready for Production: саме там відповідь уперше потрібна, бо Design Complexity рахує Points, а без обох прогон не запуститься.

Поки хоч одна порожня, пункт Ready for Production неактивний, а колонка на дошці картку не приймає. Раніше задача переїжджала, прогон падав на валідації й вертав її в Backlog з червоним банером — тепер вона просто не переїжджає.

Деталі про те, де саме стоять зірочки, — у Поля Task і Creative.

In Progress вимагає Assignee

Задача не заїде в In Progress, поки не вказано Assignee. In Progress означає, що хтось уже робить роботу, тож картка мусить казати хто: без цього вона висить у колонці без відповідального, а на Done хендлер проставляє Assignee на кожну Creative-картку, яку створює — і проставити нема чого, пак лишається безхазяйним теж.

Це умова входу, а не блокування поля: Assignee лишається редагованим у будь-якому статусі (розділ 4), просто до його заповнення перехід закритий. На практиці:

• у селекті статусу на сторінці задачі In Progress неактивний, поки поле порожнє;
• на дошці колонка не приймає картку — вона не перетягнеться;
• щойно Assignee вказано, статус відкривається одразу, без збереження й перезавантаження.

Інших статусів це не стосується: задача без Assignee спокійно проходить автоматизацію і доходить до Done. Не стосується й неперформансних напрямів — у них графа статусів немає взагалі.

Крок назад з In Progress — це не перезапуск автоматизації

Перехід In Progress → Ready for Production існує для одного випадку: задачу взяли в роботу помилково — не ту картку перетягнули, не на ту людину. Це твердження про виконавця, і скасовувати його поверненням у Backlog було б надто дорого: Backlog — це скидання, він відкриває теги й на виході знову ганяє автоматизацію. Тому цей перехід просто рухає картку назад у чергу.

Що при цьому не відбувається:

• прогон не запускається, automation.state не стає pending, задача не блокується;
• Task Name, план назв Creative і Drive-папка лишаються тими самими — виробництво вже називає свої файли за ними, і перейменовувати їх нема за чим: від Ready for Production і далі всі поля, які впливають на назву, і так закриті (розділ 4), тож новий прогон прочитав би рівно те саме.

Перезапустити автоматизацію, як і раніше, можна лише через Backlog — це єдиний статус, де теги відкриваються, а отже єдине місце, де в прогону є що прочитати по-новому.

Умова входу лишається спільною для всіх шляхів: обидві Complexity мають бути заповнені. Вони редагуються в In Progress, тож якщо їх звідти прибрали — перехід назад теж не пройде, поки не повернуть.

Повернення в Backlog доступне з кожного статусу, де задачу ще можна виправити

Backlog — не крок процесу, а його скидання: єдиний статус, де теги й назва відкриваються знову, а отже єдиний спосіб виправити задачу з неправильним тегом. Раніше цей шлях був закритий після In Progress, і ціна була така: задача, що доїхала до перевірки з помилкою в тегах, не виправлялась взагалі — її лишалось тільки покинути й переписати заново. Тому Tech Check і Creative Check тепер теж ведуть назад.

Що робить повернення дешевим — те, що до Done задача нічого не матеріалізує: є назва, план назв і Drive-папка, і все. Картки з’являються тільки на Done, тож задача, яка повертається, не тягне за собою напівфабрикатів. Ні папку, ні файли повернення не чіпає — наступний прогон перейменує їх під новий план (розділ нижче), зберігаючи id папки, тож усі раніше розшарені посилання далі працюють.

Done і Archived — фінальні

З них повернення в Backlog немає, і Archived лишається термінальним. Причина не в тому, що відкат технічно складний — те саме скидання спрацювало б. Причина в тому, що завершений пак перестає бути тільки нашим: mark_pack_launched віддає його в кабінет, звідти приходять звіти про запуск проти опублікованих Kumquat назв, і проти тих самих назв написані всі рядки аналітики. Повторний прогон згенерував би рівно ті рядки, на яких обидві половини зійшлись.

Пак потрапляє у фід інтеграцій саме тому, що він у Done або Archived (Task.offered_to_integrations), тож «його можна запустити» і «його не можна відкотити» — це один і той самий факт. Тому це правило графа переходів, а не окрема перевірка.

Якщо в завершеній задачі виявилась помилка — її архівують і брифують нову.

Заборонені переходи (явно)

• Будь-який “стрибок” вперед в обхід Ready for Production — з Backlog не можна потрапити одразу в In Progress чи будь-що далі. Ready for Production — це той єдиний перехід, який запускає автоматизацію; без нього немає ні назви, ні Drive-папки.
• Стрибки вперед між перевірками — Tech Check → Done в обхід Creative Check, і будь-що подібне.
• Кроки назад з перевірок у Ready for Production — з Tech Check і Creative Check назад ведуть тільки In Progress і Backlog. Робота вже здана на перевірку, і питання там не в тому, хто її виконавець.
• Backlog → Done/Archived напряму — заборонено за визначенням (немає проміжних станів виробництва).

4. Які поля коли редагуються

Принцип: назва (Task Name і похідні Creative Name) — це не поле, яке хтось вписує руками; вона генерується автоматизацією з тегів. Тому блокуємо не саму назву, а набір полів, від яких вона залежить — щоб хтось випадково не змінив тег і не розсинхронив назву з уже створеною Drive-папкою.

Але не всі поля картки годують автоматизацію, і закриваються вони не одночасно. Поля поділені на групи, і кожна група має власний момент, коли перестає редагуватись:

І матриця «група × статус» — ✓ означає «редагується»:

Читається так: Backlog — єдиний статус, де можна правити теги й походження. Далі до Creative Check лишаються відкритими бриф і планування — складність, пріоритет, виконавець, дедлайн можна уточнювати, поки задача в роботі.

Коли роботу прийняли (Done), картка стає звітом: редагуються рівно два поля — Test Status і Manual Launch, і то тому, що жодне з них про саму задачу не висловлюється. Test Status — це вердикт кабінету про креативи, який приходить через тижні після здачі (його ж пише інтеграційний API, окремим шляхом повз цю таблицю); виняток дає змогу виправити його руками. Manual Launch — це позначка, що пак у кабінет піднімає людина, і дізнаються про це якраз тоді, коли Done робить це чиєюсь роботою; раніше прапорець замерзав на тих самих дверях, які він і відкриває. Нічого, крім Slack-пінга на вході в Done, його не читає, тож пізніша правка нічого не розсинхронить. Усе інше закрито — включно з описом і з цілою карткою Variations: до Done її блоки якраз і були брифом майбутніх креативів, а на Done ті креативи вже існують і несуть власну копію цих значень, тож правка тут не змінила б нічого, крім самої задачі. Усе, що про завершену задачу ще варто сказати, пишеться коментарем. Коментарі полем задачі не є й під цю таблицю не підпадають, тож вони доступні в Done і Archived, як і в будь-якому іншому статусі.

Заборона тепер справжня. Раніше заблоковані поля лише виглядали сірими в інтерфейсі, а сама платформа зміну приймала — інтеграція, скрипт чи прямий запит могли переписати теги в будь-якому статусі й тихо розсинхронити назву. Тепер спроба змінити закрите поле відхиляється з повідомленням, у якому перелічені саме ті поля, і сказано, куди перемістити задачу, щоб їх відкрити.

Розблокувати — тільки ручним поверненням у Backlog, і тільки з Ready for Production, In Progress, Tech Check або Creative Check (див. розділ 3). З Done і Archived повернення немає, тож там теги зафіксовані назавжди.

Посилання на Google Drive у Performance-задачі не редагується взагалі, в жодному статусі — включно з Backlog. Папку створює автоматизація — вона ж записує і посилання, і внутрішній id папки, з якого малюється список файлів на картці. Вписаного руками id немає звідки взяти, тож ручне посилання вказувало б на папку, якої прогон не наповнює, а наступний прогон його все одно перезапише. На формі створення блоку Google Drive немає зовсім: папки на той момент ще не існує. В інших воркстрімах (Product, Web, Brand, SMM, HR) автоматизація не запускається, тому там посилання вписується руками як і раніше.

Роль теж вирішує. Хто має доступ лише на читання, бачить картку повністю в режимі перегляду — без жодного редагованого поля. Раніше форма показувала звичайні контроли, а кожне збереження відхилялося вже після спроби, без пояснення.

Поки автоматизація працює, задача заблокована повністю

Від моменту, коли задача потрапила в Ready for Production, і до моменту, коли прогон відзвітував, задачею володіє бот. Він генерує назву, картки креативів і Drive-папку з того стану задачі, який побачив на старті — тож правка, зроблена в цей момент, у прогон би не потрапила, а частину тегів бот міг би ще й перезаписати сам. Тому на час прогону блокуються всі поля задачі, не тільки назву й теги: Test Status, Priority, Task Owner, Assignee, Deadline, опис. Це ширше за будь-який рядок матриці вище — на час прогону задачею володіє не статус, а бот.

Відкритими лишаються два речі:

• Статус — щоб задачу можна було повернути в Backlog, якщо прогон завис;
• Коментарі — вони про прогон, а не вхідні дані для нього.

Блокування знімається щойно прогон відзвітував — далі задача живе в Ready for Production скільки завгодно довго й редагується в межах рядка «Ready for Production» матриці вище: назва й теги вже зафіксовані, бриф і планування вільні.

Прогон триває секунди, тож у нормі блокування непомітне. Якщо картка висить із написом «Automation running…» довше кількох хвилин — дошка позначить її як «Automation stuck», і вихід один: перетягнути назад у Backlog.

Reopen-for-edit: цикл виправлення

1. Задача в Ready for Production, In Progress, Tech Check або Creative Check → творець/Task Owner помічає, що тег/назва невірні. (З Done і Archived цього циклу немає — вони фінальні.)
2. Вручну переміщує задачу назад у Backlog → назва, теги й походження розблоковуються.
3. Виправляє потрібні теги.
4. Знову переміщує в Ready for Production — це й є повторний запуск.
5. Бот генерує новий Task Name і новий план назв, перейменовує Drive-папку на місці й перейменовує в ній файли під новий план.
6. Успіх → задача лишається в Ready for Production; помилка — бот знову поверне її в Backlog.

Кроку «видалити картки креативів» тут більше немає, і причина проста: картки створюються на Done, а з Done повернення немає — отже задача, яку повертають, карток не має взагалі. Прогон, який упав, їх теж не робить, тож і сміття по собі не лишає.

Що прогон робить із Drive при повторному запуску

Папку перейменовує, а не створює нову. Посилання Drive адресується за id папки, а не за її назвою, тож перейменування зберігає всі раніше розшарені лінки і не рухає жодного файла. Якщо змінився Product — папка ще й переїжджає в іншу батьківську. Раніше створювалась нова порожня папка, а стара лишалась зі всім вмістом під назвою, на яку вже ніхто не вказував.

Файли всередині перейменовує під новий план. Це не косметика: gdrive-sync стикує файл із карткою рівно за рядком до розширення, тож файли зі старими назвами після зміни тегів просто загубились би. Перейменування набагато дешевше за перезалив — вміст не рухається, хеш той самий, тож усі вже згенеровані з нього ассети лишаються чинними. Постер-сайдкар їде за своїм відео автоматично: у них спільний stem, і саме за ним іде звірка.

Пари підбираються обережно. Назва починається з координат самої картки ({варіація}-{Task#} або {варіація оригінала}-{Task# оригінала}), а далі йдуть теги задачі. Прогон перейменовує тільки ті пари, у яких ці координати збігаються, — інакше LOC-задача, у якій в Backlog підмінили Origin Creative, перейменувала б роботу одного оригінала на назву іншого. Якщо кількість карток змінилась або координати розійшлись, файл лишається зі старою назвою, а Task Owner отримує в Slack список таких файлів.

План назв: що бачить дизайнер до Done

Прогон Ready for Production записує на задачу список назв майбутніх карток. Це не технічна дрібниця, а контракт: дизайнер називає завантажені у Drive-папку файли саме цими назвами, і рівно за назвою gdrive-sync потім чіпляє файл до картки. Тому назви фіксуються тоді, коли фіксуються теги, — за цикл до того, як самі картки з’являються.

Поки план стоїть, ці назви належать цій задачі: інша задача, яка спробує спланувати таку саму, буде відхилена з «These creative names are already taken», і в помилці буде видно, хто саме їх тримає. Перевірка дивиться і на наявні картки, і на плани інших задач поза Backlog — план задачі, яку повернули в Backlog, нічого не резервує, бо її якраз перетеговують.

Локаль у назві — це пара Geo + Language (обидва сегменти в кінці, …_CA_FR). Тож дві LOC-задачі з одного оригінала на одну мову й різні гео дають різні назви, і план другої з них проходить — так само, як їх пропускає правило дублікатів, яке порівнює саму пару Geo+Language. Раніше Geo в назву не входив, обидві задачі впирались в ту саму назву, і друга відхилялась як «These creative names are already taken».

5. Успадкування статусу Creative від Task

• Creative-рядки в таблиці Creatives не мають власного поля “Status” як джерела правди — воно дзеркалить статус батьківської Task автоматично на рівні платформи (не ручне поле).
• Наслідок для блокування назви: як тільки батьківська Task потрапляє в Ready for Production і її прогон завершується, всі її Creative Name так само фіксуються й блокуються — синхронно зі статусом Task, без окремої логіки на рівні Creative.

6. Дублікати варіантів (LOC / WHT / ADPT / RSZ)

Похідні задачі роблять із готового креативу іншу його версію: LOC — переклад під іншу мову, WHT — версію під іншу платформу, ADPT — адаптацію під інший сорс, RSZ — ресайз під інший розмір (Resolution). Одну й ту саму версію одного оригінала система робити двічі не дає.

Що вважається «тією самою версією»:

Порівнюються лише картки того самого Task Type — WHT-версія ніколи не конфліктує з LOC-версією. Власні картки цієї ж задачі не враховуються, тож перезбереження задачі з тими самими тегами дублікатом не вважається.

Що ви побачите:

• Повний збіг — задачу зберегти не вийде: конфліктні теги підсвічуються, а в помилці видно назву картки, яка вже покриває цю мову/платформу. Той самий збіг перевіряється ще раз під час прогону автоматизації — це важливо, коли оригінали підтягуються через Legacy Remap і форма їх заздалегідь не бачить. Тоді задача просто повернеться в Backlog з помилкою.
• Частковий збіг (тільки для LOC) — збіглася або мова, або гео, але не обидва. Це не блокує: показується попередження, зберегти можна. Такий сусідній варіант буває і цілком нормальним (та сама мова на інше гео), і ознакою помилки в гео — вирішує людина.

Якщо новий варіант справді потрібен попри наявний, попередню картку треба видалити: перевірка дивиться лише на невидалені картки. Змінити статус старої картки для цього не достатньо.

7. Окремі рішення та відомі межі

1. Reject з Tech Check → In Progress, дизайнер доробляє відео → знову йде в Tech Check (не в Creative Check). У Backlog з перевірки теж можна, але це інший випадок — коли причина саме в тегах, а не в самому відео.
2. Creative Check не обов’язковий. З Tech Check задачу можна прийняти прямо в Done. Технічна перевірка — остання, якої задача потребує, коли креативній стороні нема чого додати; ганяти таку задачу через другий апрув тільки заради того, щоб його поставили не глядячи, робило другого рев’ювера вузьким місцем, а не перевіркою.
3. Reject з Creative Check → In Progress, доробка → знову в Creative Check.
4. Запуск у кабінеті — це не статус задачі, а Test Status креатива. Окремого статусу Testing у задачі немає: Robby, запускаючи папки задач у статусі Done, звітує про запуск кожного креатива через інтеграційний API, і той ставить креативу Date Launched та переводить його Test Status з Not Tested у In Test. Задача при цьому лишається в Done — і на її картці видно саме бейдж Test Status. У Archived її переводить людина, коли тест завершено.
5. Manual Launch на Done — це лише сповіщення. Done + Manual Launch = true дає пінг у UAM-канал; папок під окремі гілки більше немає — усе лежить у {Product}/{Task} під кореневою папкою диска.