Тема 6, урок 1 з 2. Онлайн-дошки та управління проєктами. 120 хвилин
У тебе є ідея, бриф, економіка, айдентика, пітч і база знань. Немає
списку робіт. Сьогодні ти складеш його у файл ~/www/tasks.json:
кожна задача — девʼять полів. Завтра roadmap.html прочитає цей файл.
tasks.json: дія, виконавець, дата, ознака готовності.| Етап | Хв | Що робимо |
|---|---|---|
| Навіщо дошка | 10 | думати простором, а не списком; спільне поле зору |
| Практика: брейншторм | 20 | мовчазна генерація, ≥ 25 карток без критики |
| Афінне групування | 20 | 40 стікерів → 5 кластерів, назви після групування |
| Пріоритезація | 15 | матриця «цінність × зусилля», MoSCoW, «усе must» |
| MVP і анатомія задачі | 15 | тренажер MVP, дія + виконавець + дедлайн + DoD |
Практика: tasks.json | 30 | дошка пріоритезації, генерація й валідація JSON |
| Автоперевірка й підсумок | 10 | check11 6, у кого 100 % must |
tasks.json,
критерій no_media діє й сьогодні.Список зберігає порядок. Дошка зберігає відношення
У списку є тільки «вище» й «нижче», і цей порядок випадковий. На дошці картку можна посунути ближче до іншої, підняти вище за важливістю, обвести разом із сусідками. Відстань між картками стає інформацією.
Записана ідея стає спільною: її рухає команда, а не автор. І всі дивляться на одне зображення, а не на свою версію розмови.
tasks.json.На дзвінку команда 40 хвилин обговорювала функції голосом і скидала їх у чат. Наступного дня двоє памʼятають різні домовленості. Що саме змінить дошка?
Спершу кількість. Якість — потім і окремою дією
Вигадувати й оцінювати — різні роботи, і вони заважають одна одній. Тому на етапі генерації не критикують: фраза «це не спрацює» зупиняє всіх у кімнаті. Оцінювати будеш через 15 хвилин.
Перша озвучена ідея задає рамку, і команда вигадує її варіації. Тому перші 5 хвилин кожен пише сам і мовчки.
| Правило | Що це означає на практиці |
|---|---|
| Кількість перед якістю | ціль — 25+ карток за 10 хвилин, а не 5 «хороших» |
| Ніякої критики | слова «ні», «не спрацює», «нереально» заборонені до кінця таймера |
| Спершу мовчки | 5 хвилин кожен пише сам, тільки потім читаємо вголос |
| Дикі ідеї вітаються | «телепорт обідів» породжує «попереднє замовлення» — урізати легше, ніж вигадати |
| Добудовувати чуже | «і ще можна…» замість «але ж…» |
| Одна ідея — одна картка | картку з трьома ідеями неможливо ні згрупувати, ні пріоритезувати |
| Коротко й дієсловом | «показувати меню на завтра», а не «меню» |
На третій хвилині генерації хтось каже: «це дурня, у нас на це немає грошей». Далі за 10 хвилин команда видає 6 карток замість звичних 25. Чому правило «не критикувати» — не про ввічливість?
Учитель каже: «спершу 5 хвилин пишемо мовчки, кожен сам, і лише потім читаємо вголос». Навіщо цей етап, якщо все одно все буде озвучене?
Спершу «ці схожі», і тільки потім — «як це назвати»
Після генерації на дошці 30–40 карток. Склади схожі в купки, мовчки й швидко, а назви дай потім, дивлячись на те, що зібралося. Цей прийом зветься афінною діаграмою.
Намалюєш підписані рамки до групування — отримаєш свої очікування, а не структуру ідей: половина карток осяде в рамці «Інше».
Команда перед брейнштормом намалювала на дошці 5 підписаних рамок: «Дизайн», «Код», «Маркетинг», «Гроші», «Інше». Що станеться з ідеями?
Дві осі, чотири квадранти, один порядок роботи
Картку оцінюють за двома шкалами. Цінність — наскільки річ наближає до вирішення проблеми користувача. Зусилля — скільки роботи вона коштує.
Оцінюй порівнянням. На питання «наскільки це цінно?» відповіді немає, а на «що цінніше — оце чи оце?» — є. Рухай картки одна відносно одної, доки розташування не викликає заперечень.
Поки нічого не працює, твої здогади про користувача лишаються здогадами. Тому й починають із першого квадранта.
Картка «Додати темну тему» опинилась у квадранті «низька цінність / малі зусилля». Напарник каже: «це ж двадцять хвилин, давай зробимо зараз». Що відповісти?
Чому роботу починають саме з квадранта «висока цінність / малі зусилля»? Адже в квадранті «висока цінність / великі зусилля» цінність теж висока.
Чотири слова, які перетворюють матрицю на рішення
Матриця показує, де картка лежить. MoSCoW каже, що команда з нею робитиме. Кожне слово — обіцянка, а не відтінок важливості.
| Категорія | Що означає | Перевірка одним питанням |
|---|---|---|
| must | без цього немає сенсу випускати взагалі | якщо цього не буде, продукт можна не показувати? |
| should | важливо, але випуск без цього болісний, а не неможливий | чи є обхідний шлях, хай і незручний? |
| could | покращує враження, зробимо, якщо лишиться час | чи помітить хтось відсутність? |
| won’t | свідомо не робимо в цій ітерації — і це записано | чи можемо чесно сказати «цього не буде»? |
Найважче — must. Питання до кожної картки: якщо цього не буде, чи є сенс
показувати продукт? «Буде гірше» означає should.
won’t теж лишається в беклозі: незаписане «ні» повертається
на кожній зустрічі.
check11 6. Дошка попереджає вже на третині.Навіщо тримати в беклозі задачі з категорією won’t, якщо їх
свідомо не робитимуть?
Якщо важливе все — важливого немає
«Пріоритет» означає «те, що йде першим», а першим може йти рівно одне. «У нас десять пріоритетів» означає «ми не змогли вибрати». Черговість усе одно зʼявиться — її задасть настрій того, хто першим сів працювати.
Дванадцять «обовʼязкових» функцій за той самий час стають дванадцятьма розпочатими і жодною завершеною. Продукт, у якому жоден сценарій не доходить до кінця, коштує нуль, а не половину.
Твоя команда вирішила, що всі 12 функцій — обовʼязкові, бо «інакше ніхто не користуватиметься». Що станеться до захисту і що робити зараз?
Не «урізана версія» і точно не «усе, але наполовину»
MVP — minimum viable product: найменша версія продукту, якою людина вже може скористатися й отримати результат. Урізана версія — це коли від кожної функції відрізали половину. MVP — це один ланцюг, зроблений повністю: від проблеми користувача до результату.
Обери з дванадцяти функцій ті, що входять у першу версію.
Оцінки в годинах ілюстративні: вони складені для уроку.
Команда зробила красивий екран профілю з аватаркою, темну тему й анімовану заставку. Замовити обід у застосунку не можна. Що в них вийшло?
«Зробимо всі 12 функцій, але кожну наполовину» — чим це гірше за «зробимо 4 функції повністю», якщо роботи однаково?
Заведи картки, розтягни їх по матриці — MoSCoW і tasks.json зʼявляться самі
Заведи свої картки замість прикладів і перетягни їх зі «стосу ідей» у матрицю. Пріоритет проставиться сам — за квадрантом.
Клік по картці відкриває її поля. Кнопка внизу збирає
tasks.json і перевіряє його правилами check11 6.
Дедлайни підставляються від сьогоднішньої дати браузера (must +7 днів, should +14, could +21, won’t +28) — заміни їх на реальні. Оцінка зусиль береться з положення картки, доки не виставиш її вручну.
must — це наслідок того, куди ти поклав картку.Ти розклав 15 карток і бачиш: 11 із них у квадранті must,
дошка світить попередженням. Що це насправді означає?
Девʼять полів, які роблять беклог машинозчитуваним
Файл tasks.json читає програма: roadmap.html
і check11 6. Тому кожна задача описана однаково.
done_criteria — JSON такого не пробачає.«Лендинг» — це тема, а не задача. Задача починається з дієслова:
зверстати, підключити, налаштувати,
опублікувати.
| Погано | Добре | Що змінилося |
|---|---|---|
| Форма | Підключити форму відгуку до bin/form-handler |
зʼявилась дія і місце, де перевіряти |
| Зробити красиво | Замінити кольори в deck.html на змінні brand.css |
«красиво» стало перевірюваним |
| Доробити аналітику | Порахувати break_even_units і вивести в analytics.html |
видно, коли саме задача завершена |
Критерій — це факт, який видно очима. «Готово, коли зверстано» не означає
нічого. «Готово, коли секція видима на сабдомені, а дані беруться
з responses.csv» — означає.
Епік — велика ціль на кілька задач: «лендинг», «збір відгуків». Задача
з effort більше 4 — це епік, який не розбили. Перевірка чекає
≥ 3 різні епіки, у кожному ≥ 2 задачі.
> або
Out-File -Encoding utf8, отримає UTF-16 або BOM, і json.load
падає на ньому. Правильний спосіб — у практиці нижче.У беклозі є задача: "title": "Лендинг",
"done_criteria": "зробити лендинг". Що з нею не так?
tasks.jsonВиконуй по черзі. Галочки зберігаються — сторінку можна закрити.
Кроки 1–4 — на онлайн-дошці, 5–9 — на цій сторінці. До сервера підключаєшся аж на кроці 10.
Відкрий Miro, FigJam, Padlet або Trello, натисни Create new board
і впиши назву продукту — ту саму, що в brief.html.
Дошка відкриється порожня, назва буде видна у вкладці браузера.
Вийшло дві дошки на команду — лишіть одну: вчитель дивиться один екран.
Постав таймер на 5 хвилин. Додавай стікери (у Miro — подвійний клік по полю), по одній ідеї на стікер, з дієслова. Не говори й не читай чужі.
За пʼять хвилин біля тебе буде 8–15 своїх стікерів.
Ідеї закінчились — пиши свідомо слабкі: відсіювати будеш на кроці 6.
По черзі читай свої стікери вголос. На чужу ідею відповідай «і ще можна…» й одразу додавай стікер. Дублікати не видаляй — постав на них крапку.
На дошці стане щонайменше 25 стікерів — стільки вчитель рахує очно.
Почулося «але ж це не спрацює» — поверни таймер і добери ще пʼять карток без оцінок.
Мовчки тягніть стікери один до одного, усі одночасно. Картку, яка підходить у дві купки, поклади між ними.
Коли рух припиниться, підпиши кожну купку стікером іншого кольору: одне-два слова. Купок має бути пʼять.
Назви написані до групування — зітри їх: інакше картки розкладаються під назви, а не за схожістю.
Відкрий вкладку Дошка пріоритезації, натисни Видалити приклади. Впиши ідею в поле Нова картка й натисни Додати картку. Повтори щонайменше 12 разів.
Картки стануть у смугу Стос ідей з підписом «без пріоритету», лічильник «карток у матриці» покаже 0.
Назва-іменник на кшталт «Лендинг» завалить пункт
titles — пиши «Зверстати секцію відгуків на лендингу».
Тягни картки мишею зі стосу в квадранти: вище — цінніше для користувача, правіше — більше роботи. Без миші те саме робить поле Місце в матриці.
Під назвою картки стане must, should,
could або won’t і оцінка зусиль; лічильники внизу
перерахуються самі.
Напис «більше третини» означає must понад 40 %: перечитай їх питанням «чи є сенс показувати продукт без цього».
Відкрий вкладку MVP і став галочки, поки лічильник ланцюг проблеми не покаже 4 / 4, а вердикт — «Це MVP».
Повернись на онлайн-дошку, створи колонку MVP, перенеси в неї 3–5 своїх карток і підпиши рядком «проблема → що робить користувач → що отримує».
У колонці 8 карток — це вже не перша версія: прибери все, без чого сценарій замикається.
Клікни по картці — під матрицею відкриються поля. Заповни Епік, Виконавець (свій логін, не «команда»), Дедлайн, Оцінка зусиль, Статус і Критерій готовності.
Критерій — те, що видно очима: «секція видима на сабдомені й дані беруться
з responses.csv». Від 25 символів і не переказ назви.
Потрібно ≥ 3 різні епіки, у кожному ≥ 2 задачі, зусилля ≤ 4.
Задача на 5 балів зусиль — це епік: розбий її на дві-три
менші, інакше epics буде червоний.
tasks.json і перевір валідністьНатисни Згенерувати tasks.json унизу дошки. Зʼявиться напис «Зібрано N задач», текст файлу й список правил із ✓ та ✕.
Виправ усе з ✕ і натисни кнопку ще раз. Коли рядки зелені — натисни копіювати над текстом файлу.
Збережи текст у файл у кодуванні UTF-8 без BOM. У PowerShell 5.1
знак > дає UTF-16, а -Encoding utf8 дописує три
невидимі байти: json.load падає на обох.
$json = Get-Clipboard -Raw
[IO.File]::WriteAllText("$HOME\Desktop\tasks.json", $json, (New-Object Text.UTF8Encoding $false))
Валідний файл команда виводить назад із відступами, битий — називає рядок і символ.
Expecting property name — це зайва кома після
останнього поля: прибери її й повтори.
Відкрий FileZilla. Хост — sftp://91.219.61.4, ім’я
користувача — твій логін, порт — 22. Натисни
Швидке зʼєднання й перетягни tasks.json у теку
~/upload/.
Відповідь mv: cannot stat означає, що файл не
завантажився: подивись у праву панель FileZilla й перетягни ще раз.
Команда має не вивести нічого. Назвала файл — видали його,
інакше no_media не зарахується.
Червоний рядок називає id задачі. Виправ її на дошці,
згенеруй файл заново, залий і запусти check11 6 ще раз —
спроби не обмежені.
Червоний json_parse блокує оцінку: доки файл
не парситься, решту правил нема на чому перевіряти.
tasks.json →
~/upload/ → ~/www/. Скриншоти й експорти дошки
критерій no_media не пропустить.check11 6Система прочитає твій tasks.json із сабдомену й
звірить його з правилами, які ти сьогодні розбирав. Спроби не обмежені.
Демонстраційний режим: результат згенеровано для показу.
На сервері ця кнопка запускає check11 6 від імені учня
і читає ~/.progress/11-6.json.
json_parse блокує оцінку, бо якщо файл не парситься, решту правил
просто нема на чому перевіряти — перевірка зупиняється на першому рядку.
no_media діє наскрізно весь модуль. У ~/www/ і
~/upload/ не має бути відео й звуку: .mp4 .mov .avi .mkv
.webm .mp3 .wav .flac. Файлів понад 2 МБ там теж бути не повинно.
Скриншот дошки — типовий спосіб випадково
завалити цей пункт.tasks.json: ти вголос читаєш критерій
готовності й пояснюєш, як його перевірити очима.Це те, що бачить учитель, коли виставляє оцінку.
| Складник | Вага | Результат |
|---|
tasks.json дві задачі з пріоритетом
wont. У їхньому done_criteria письмово
пояснити, чому ми свідомо не робимо це в цьому модулі.must питанням «якщо цього не буде, чи є сенс
показувати продукт?» і перевести в should усе, що його
не пройшло.check11 6 до зеленого: усі девʼять полів, ≥ 12 задач,
≥ 3 епіки, effort ≤ 4, критерії готовності ≥ 25 символів.roadmap.html через fetch читатиме саме
твій сьогоднішній tasks.json. Що погано описав сьогодні — побачиш
завтра намальованим.Методики тут не вигадані на уроці — у кожної є автор і документ.
РРРР-ММ-ДД — RFC 3339, профіль ISO 8601
для інтернету.
datatracker.ietf.org · RFC 3339Частина чисел на сторінці — ілюстративні, і це підписано
прямо в підписах до схем. Це розподіл 5 / 7 / 9 / 5 у воронці MoSCoW
і оцінки в годинах у тренажері MVP (4, 6, 3, 4 і решта). Так само
складені смуги виконаного у схемі «усе must», приклади карток
і назви кластерів. Вони зроблені для уроку, щоб порівнювати варіанти між
собою, і не є даними реального проєкту. Правила, межі (60 % зусиль, 40 %
задач, effort ≤ 4) і формати мають джерела вище й у
urok-09-джерела.md поруч із цією сторінкою.