Перегляд вихідного коду сторінки ISO 9001 + Scrum + регламент K2 ERP: система якості, тижневі спринти, Zoom-записи, VDoc і Telegram-комунікації

= ISO 9001 + Scrum + регламент K2 ERP: система якості, тижневі спринти, Zoom-записи, VDoc і Telegram-комунікації =

'''Є в IT одна вічна класика.'''

Спочатку всі впевнені, що “ми і так нормально працюємо”. Розробник знає, що він робить. Бізнес-аналітик знає, що хотів замовник. Scrum Master знає, хто що мав здати. Product Owner знає, що продукт має рухатись швидше. Замовник пам’ятає, що “ми це точно десь обговорювали”.

А потім раптом виявляється, що вимога була не зовсім такою, задача закрита без перевірки, запис Zoom ніхто не зберіг, посилання у Telegram не скинули, у VDoc нічого немає, а в баг-трекері написано просто: “поправив”.

І саме в цей момент розробка перестає бути керованим процесом і перетворюється на квест.

Причому не з тих приємних, де в кінці скарб. А з тих, де в кінці Scrum Master із нервовим оком, Product Owner із питанням “хто це погодив?”, замовник із фразою “ми не це мали на увазі”, а розробник із відповіддю: “Ну мені так сказали”.

'''ISO 9001 + Scrum + регламент K2 ERP потрібні саме для того, щоб прибрати цей хаос і замінити його нормальною, прозорою, контрольованою системою роботи.'''

Без магії. Без “десь домовились”. Без задач “на словах”. Без Zoom-записів, які ніхто не може знайти. І без ситуацій, коли результат наче зроблено, але ніхто не може довести, хто його перевірив, хто прийняв і де це зафіксовано.

<div style="background-color:#eaf7ea; border-left:6px solid #1b8f3a; padding:14px; margin:16px 0;">
'''Ключовий меседж:''' ISO 9001 у K2 ERP — це не папери заради сертифікату. Це система, яка робить розробку керованою: кожна задача має опис, виконавця, перевіряючого, критерій готовності, записані зустрічі, збережені матеріали, прозору комунікацію і вимірюваний результат.
</div>

== Якість починається не з релізу, а з процесу ==

Багато хто думає, що якість у продуктовій IT-компанії починається тоді, коли тестувальник відкрив готовий функціонал і почав шукати помилки.

Насправді якість починається набагато раніше.

Вона починається з простого питання:

'''що саме ми робимо, для кого, навіщо, хто це перевіряє і де це буде зафіксовано?'''

Бо якщо це питання не закрите на старті, далі починається народна творчість. Один зрозумів вимогу так, другий — інакше, третій зробив “як швидше”, четвертий перевірив тільки свою частину, а п’ятий потім на Demo намагається пояснити, чому результат не схожий на очікування.

У K2 ERP якість будується на поєднанні трьох речей:

* '''ISO 9001''' — як система управління якістю;
* '''Scrum''' — як метод організації тижневих спринтів;
* '''внутрішній регламент K2 ERP''' — як порядок фіксації задач, Zoom-зустрічей, записів у VDoc і комунікацій у Telegram.

Це не три окремі документи. Це одна логіка роботи.

'''Scrum дає ритм. ISO 9001 дає контроль. Регламент дає доказовість.'''

<div style="background-color:#eef5ff; border-left:6px solid #2f80ed; padding:14px; margin:16px 0;">
'''Головна логіка:''' не можна побудувати якісний продукт на хаотичному процесі. Якщо задачі, зустрічі, домовленості, перевірки і рішення не зафіксовані, компанія фактично керує не якістю, а спогадами учасників процесу.
</div>

== ISO 9001 у продуктовій IT-компанії: що це означає на практиці ==

Для продуктової IT-компанії ISO 9001 — це не про “створити папку з документами і забути”. Це про те, щоб компанія могла стабільно випускати якісний продукт, перевіряти результат, аналізувати помилки і покращувати процеси.

Для K2 ERP це особливо важливо, тому що продукт автоматизує критичні бізнес-процеси: бухгалтерію, фінанси, склад, виробництво, документообіг, CRM, HR, звітність, API, інтеграції та інші напрямки.

У такому продукті помилка — це не просто “кнопка не там стоїть”. Це може бути неправильна логіка документа, некоректний рух даних, помилка в правах доступу, зламана інтеграція, неправильний розрахунок або проблема у клієнта.

Тому ISO 9001 у K2 ERP означає:

* кожна важлива дія повинна бути запланована;
* кожна задача повинна мати опис;
* кожен результат повинен бути перевірений;
* кожна критична зміна повинна мати іншого перевіряючого;
* кожна зустріч повинна мати запис;
* кожен запис повинен бути збережений у VDoc;
* кожне важливе рішення повинно бути передане в Telegram-групу або зафіксоване в задачі;
* кожна помилка повинна давати покращення процесу.

'''Якість — це не фінальний тест перед релізом. Якість — це щоденна дисципліна роботи.'''

== Scrum у K2 ERP: один тиждень, один результат, одна відповідальність ==

У K2 ERP використовується Scrum-підхід із тижневим спринтом.

'''Спринт — це 1 тиждень.'''

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

Scrum-команда в K2 ERP складається з:

'''7 співробітників, які безпосередньо виконують роботу в межах спринту + 1 Scrum Master.'''

Scrum Master не входить у ці 7 виконавців. Він є окремою роллю, яка відповідає за процес, прозорість, дисципліну, Daily Scrum, блокери, Demo, ретроспективу і контроль виконання правил Scrum.

<div style="background-color:#fff7df; border-left:6px solid #f5a400; padding:14px; margin:16px 0;">
'''Важливо:''' Scrum-команда виконує роботу. Scrum Master організовує процес. Product Owner визначає пріоритети і приймає ключовий результат. ISO 9001 вимагає доказів якості. Регламент K2 ERP визначає, де ці докази зберігаються.
</div>

== Ролі в Scrum + ISO 9001 ==

У Scrum є три базові ролі:

* '''Scrum Master''';
* '''Product Owner''';
* '''Team / команда'''.

У K2 ERP ці ролі доповнюються практичними спеціалізаціями, які потрібні для ERP-розробки:

* бізнес-аналітик;
* розробник;
* тестувальник;
* бухгалтер-консультант;
* галузевий консультант;
* архітектор або технічний керівник;
* відповідальний за документацію;
* відповідальний за клієнтську комунікацію.

Це важливо, бо ERP — це не тільки код. ERP — це бізнес-логіка, дані, документи, довідники, ролі доступу, інтеграції, звітність і реальна робота клієнта.

'''Кожна роль повинна мати свою зону відповідальності.'''

<div style="background-color:#f5f5f5; border-left:6px solid #777777; padding:14px; margin:16px 0;">
'''Якщо ролі розмиті:''' незрозуміло, хто поставив задачу, хто перевірив, хто прийняв, хто мав зберегти запис і хто відповідає за результат.
</div>

<div style="background-color:#eaf7ea; border-left:6px solid #1b8f3a; padding:14px; margin:16px 0;">
'''Якщо ролі визначені:''' відомо, хто відповідає за вимогу, реалізацію, перевірку, Demo, запис у VDoc, рішення Product Owner і подальші дії.
</div>

== Scrum Master: не роздає задачі, а тримає процес ==

'''Scrum Master — це відповідальний за успіх Scrum-процесу в команді.'''

Він є зв’язком між менеджментом, Product Owner і командою, але не є людиною, яка вручну роздає задачі кожному співробітнику. Команда повинна бути самоорганізованою і самоврядною.

Основні обов’язки Scrum Master:

* створює атмосферу довіри в команді;
* проводить Scrum-зустрічі як фасилітатор;
* організовує Zoom-зустрічі;
* контролює, щоб зустрічі були записані;
* контролює, щоб записи були збережені у VDoc;
* контролює, щоб посилання на записи були надіслані в Telegram-групу;
* усуває перешкоди;
* робить проблеми та відкриті питання видимими;
* контролює дотримання Scrum-практик;
* стежить за актуальністю Sprint Backlog;
* веде Daily Scrum Meeting;
* фіксує Action Items;
* контролює оновлення статусів задач;
* допомагає Product Owner готувати backlog;
* організовує Demo та ретроспективу.

Scrum Master не підміняє Product Owner, технічного керівника або бізнес-аналітика.

'''Scrum Master не керує людьми вручну. Scrum Master керує процесом, прозорістю, дисципліною, записами, блокерами і доказовістю виконання Scrum-подій.'''

== Product Owner: одна точка прийняття продуктового рішення ==

'''Product Owner — це єдина точка прийняття остаточних продуктових рішень.'''

У K2 ERP цю роль фактично виконує керівник компанії або призначена ним відповідальна особа.

Product Owner відповідає за:

* product vision;
* стратегію розвитку K2 ERP;
* пріоритети Product Backlog;
* очікування клієнтів, партнерів і зацікавлених сторін;
* цінність задач для продукту;
* ROI;
* підготовку зрозумілих і тестованих вимог;
* приймання результату наприкінці спринту;
* рішення, що потрапляє в реліз;
* рішення, що повертається на доопрацювання.

Product Owner може ставити задачі команді, але не повинен під час спринту хаотично роздавати задачі конкретним співробітникам.

'''Product Owner визначає “що і навіщо потрібно зробити”, а команда визначає “як саме це зробити в межах спринту”.'''

== Scrum-команда: 7 людей, які відповідають за результат ==

'''Scrum-команда K2 ERP — це 7 співробітників, які безпосередньо виконують роботу в межах спринту.'''

Команда бере на себе зобов’язання перед Product Owner щодо виконання обсягу робіт на спринт.

До команди можуть входити:

* розробники;
* бізнес-аналітик;
* тестувальник;
* бухгалтер-консультант;
* галузевий консультант;
* архітектор або технічний керівник;
* інший спеціаліст, необхідний для виконання задач спринту.

Команда відповідає за:

* оцінку задач;
* декомпозицію задач;
* прийняття рішень щодо реалізації;
* розробку функціоналу;
* самоперевірку;
* участь у тестуванні;
* відстеження власного прогресу;
* демонстрацію результату;
* відповідальність за результат перед Product Owner.

'''Команда відповідає не за активність, а за готовий результат спринту.'''

== Product Backlog: не смітник ідей, а керована черга розвитку ==

'''Product Backlog — це пріоритизований список бізнес-вимог, технічних вимог, задач, дефектів, покращень і майбутніх можливостей продукту.'''

У Product Backlog можуть бути:

* нові модулі;
* новий функціонал;
* покращення існуючих модулів;
* дефекти;
* технічний борг;
* зміни в базі даних;
* API та інтеграції;
* документація;
* задачі з тестування;
* задачі з продуктивності;
* задачі з безпеки;
* задачі з навчання команди;
* інфраструктурні задачі;
* звернення клієнтів, які стали продуктовими вимогами.

За Product Backlog відповідає '''Product Owner'''.

'''Product Backlog — це не смітник ідей. Це керована черга розвитку продукту.'''

== Sprint Backlog: що команда реально бере в роботу ==

'''Sprint Backlog — це набір задач, які команда бере в роботу на конкретний спринт.'''

Кожна задача повинна мати:

* назву;
* опис;
* тип;
* пріоритет;
* оцінку складності або часу;
* виконавця;
* перевіряючого;
* критерій готовності;
* статус;
* ризик;
* очікуваний результат.

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

'''Sprint Backlog повинен показувати не тільки те, що заплановано, а й скільки реально залишилося зробити.'''

== Спринт: тиждень роботи, який має завершитися результатом ==

'''Спринт у K2 ERP триває 1 тиждень.'''

Результатом спринту має бути '''інкремент продукту''' — готовий, перевірений або принаймні придатний для демонстрації результат.

Для K2 ERP це може бути:

* нова форма;
* новий документ;
* новий звіт;
* новий API-метод;
* нова інтеграція;
* виправлений дефект;
* оновлена документація;
* покращений бізнес-процес;
* частина нового модуля, яку вже можна показати.

Кожен спринт є маленьким циклом повної розробки:

* уточнення вимог;
* проєктування;
* розробка;
* самоперевірка;
* code review;
* тестування;
* предметна перевірка;
* підготовка до Demo;
* Demo;
* аналіз результату.

<div style="background-color:#eaf7ea; border-left:6px solid #1b8f3a; padding:14px; margin:16px 0;">
'''Правило спринту:''' спринт повинен завершуватися не поясненнями, а результатом, який можна показати. Якщо команда тиждень “щось робила”, але показати нічого — це сигнал проблеми в плануванні, виконанні або контролі.
</div>

== Фіксований scope спринту: не перетворюємо тиждень на хаос ==

Scope спринту повинен бути фіксованим.

Після старту спринту Sprint Backlog не повинен хаотично змінюватися.

Змінювати Sprint Backlog можна тільки у виняткових випадках:

* критичний дефект;
* важливий блокер клієнта;
* ризик зупинки системи;
* терміновий hotfix;
* рішення Product Owner про зміну мети спринту;
* виявлення того, що частина scope не може бути виконана без зміни підходу.

Якщо зміна потрібна, вона повинна бути:

* погоджена;
* зафіксована в задачі;
* обговорена в Telegram-групі;
* за потреби підтверджена Zoom-зустріччю із записом;
* відображена у звіті спринту.

<div style="background-color:#fff0f0; border-left:6px solid #e63946; padding:14px; margin:16px 0;">
'''Заборонено:''' хаотично змінювати Sprint Backlog після старту спринту. Якщо зміна потрібна — вона фіксується, погоджується і має доказ.
</div>

== Планування спринту: старт тижня без туману ==

Планування спринту проводиться на початку тижня.

Планування проводиться в '''Zoom із записом'''.

Після зустрічі:

* запис зберігається у VDoc;
* посилання на запис надсилається в Scrum-групу Telegram;
* рішення по спринту фіксуються в Sprint Backlog;
* ключові Action Items фіксуються окремо.

У плануванні беруть участь:

* Product Owner;
* Scrum Master;
* Scrum-команда з 7 співробітників;
* бізнес-аналітик;
* розробники;
* тестувальник;
* консультанти;
* технічний керівник або архітектор;
* за потреби — представники менеджменту, підтримки, продажів або ключові користувачі.

На плануванні визначається:

* мета спринту;
* список задач;
* пріоритети;
* виконавці;
* перевіряючі;
* ризики;
* критерії готовності;
* що буде показано на Demo;
* які задачі потребують участі консультанта;
* які задачі потребують погодження БД, API або прав доступу.

'''Планування спринту без запису Zoom, VDoc і посилання в Telegram-групі не є повністю зафіксованим процесом для ISO 9001.'''

== Daily Scrum Meeting: 15 хвилин, які рятують спринт ==

Daily Scrum Meeting проводиться кожного робочого дня.

'''Тривалість — до 15 хвилин.'''

Daily Scrum проводиться в '''Zoom із записом'''.

Після Daily Scrum:

* запис зберігається у VDoc;
* посилання на запис надсилається в Scrum-групу Telegram;
* Action Items фіксуються в Telegram або в задачах;
* статуси задач оновлюються в системі управління задачами.

Daily Scrum потрібен, щоб команда бачила:

* що зроблено;
* що буде зроблено сьогодні;
* які є проблеми;
* які є блокери;
* чи є ризик невиконання задач;
* чи потрібна допомога.

<div style="background-color:#eef5ff; border-left:6px solid #2f80ed; padding:14px; margin:16px 0;">
'''Суть Daily Scrum:''' це не довга нарада, не звіт начальнику і не технічна дискусія. Це коротка синхронізація команди з фіксацією результату.
</div>

== Три головні питання Daily Scrum ==

Scrum Master по колу ставить кожному учаснику три базові питання.

=== Що було зроблено вчора або з минулої конференції? ===

Відповідь повинна бути конкретною:

* яка задача виконувалась;
* який результат отримано;
* що вже готово;
* що передано на перевірку;
* що закрито.

'''Погано:'''

<blockquote>
Працював над модулем.
</blockquote>

'''Правильно:'''

<blockquote>
По задачі K2-145 реалізував форму списку, додав фільтр по організації, перевірив збереження, передав на тестування.
</blockquote>

=== Що буде зроблено сьогодні? ===

Потрібно розкрити:

* яку задачу продовжує;
* яку частину планує завершити;
* що має бути готово до кінця дня;
* чи буде задача передана на перевірку;
* чи є потреба в допомозі.

'''Погано:'''

<blockquote>
Буду продовжувати.
</blockquote>

'''Правильно:'''

<blockquote>
Сьогодні завершую права доступу по формі, додаю перевірку ролей і передаю задачу бізнес-аналітику на функціональну перевірку.
</blockquote>

=== З якими проблемами зіткнувся? ===

Потрібно чесно назвати блокери:

* немає вимог;
* незрозуміла бізнес-логіка;
* потрібне рішення Product Owner;
* потрібне погодження структури БД;
* є технічна залежність;
* не вистачає тестових даних;
* немає доступу;
* не проходить тест;
* немає перевіряючого;
* потрібна консультація бухгалтера або галузевого спеціаліста.

<div style="background-color:#fff7df; border-left:6px solid #f5a400; padding:14px; margin:16px 0;">
'''Важливо:''' блокер не можна приховувати. Якщо проблема не озвучена вчасно, вона стає ризиком зриву спринту. Краще сказати про ризик у вівторок, ніж пояснювати провал у п’ятницю.
</div>

== Action Items після Daily Scrum ==

Якщо під час Daily Scrum виникає питання, яке потребує окремого обговорення, Scrum Master фіксує його як Action Item.

Формат Action Item:

* '''Що потрібно зробити:''' короткий опис дії.
* '''Хто бере участь:''' відповідальні люди.
* '''Коли це має бути зроблено:''' строк.
* '''Де буде зафіксований результат:''' задача, Telegram-група, VDoc або інша система.

'''Приклад Action Item:'''

* '''Що:''' погодити структуру таблиці для нового регістру.
* '''Хто:''' розробник, архітектор, бізнес-аналітик.
* '''Коли:''' сьогодні до 15:00.
* '''Де фіксуємо:''' задача + Telegram-група + за потреби Zoom-запис у VDoc.

'''Daily Scrum не вирішує всі проблеми. Він виявляє проблеми і запускає окремі короткі дії для їх вирішення.'''

== Чого не можна робити на Daily Scrum ==

На Daily Scrum заборонено:

* розбирати складну архітектуру;
* проводити code review;
* детально тестувати функціонал;
* сперечатися про продуктові рішення;
* читати лекції;
* влаштовувати пошук винних;
* обговорювати задачі, які не стосуються поточного спринту;
* перетворювати Daily Scrum на годинну нараду.

<div style="background-color:#fff0f0; border-left:6px solid #e63946; padding:14px; margin:16px 0;">
'''Заборонено:''' перетворювати 15-хвилинну конференцію на довгу нараду. Daily Scrum — це контроль руху, а не місце для вирішення всіх проблем.
</div>

== Що потрібно підраховувати щодня ==

Після кожного Daily Scrum потрібно оновлювати показники спринту.

Підраховується:

* скільки задач у роботі;
* скільки задач виконано;
* скільки задач на перевірці;
* скільки задач заблоковано;
* скільки задач мають ризик невиконання;
* скільки задач прострочено;
* скільки задач повернуто на доопрацювання;
* скільки задач готові до Demo;
* скільки роботи залишилось у годинах або story points;
* який відсоток виконання спринту;
* чи відповідає темп виконання плану тижня.

'''Приклад щоденного звіту по спринту:'''

* '''Понеділок:''' заплановано 25 задач, у роботі 18, на перевірці 2, виконано 1, заблоковано 1, ризик невиконання 3, готово до Demo 0, залишок роботи 160 годин.
* '''Вівторок:''' заплановано 25 задач, у роботі 16, на перевірці 4, виконано 4, заблоковано 2, ризик невиконання 4, готово до Demo 1, залишок роботи 125 годин.
* '''Середа:''' заплановано 25 задач, у роботі 12, на перевірці 6, виконано 8, заблоковано 1, ризик невиконання 3, готово до Demo 4, залишок роботи 85 годин.
* '''Четвер:''' заплановано 25 задач, у роботі 7, на перевірці 8, виконано 14, заблоковано 1, ризик невиконання 2, готово до Demo 9, залишок роботи 42 години.
* '''П’ятниця:''' заплановано 25 задач, у роботі 2, на перевірці 4, виконано 19, заблоковано 0, ризик невиконання 1, готово до Demo 15, залишок роботи 12 годин.

'''Якщо щодня не видно динаміки виконання, команда керується відчуттями, а не фактами.'''

== Ведення часу і продуктивності ==

Співробітники повинні відмічати час у баг-трекері '''день у день'''.

Опис часу повинен бути зрозумілим:

* що робилось;
* по якій задачі;
* який результат;
* скільки часу витрачено;
* чи завершено дію;
* чи потрібне продовження.

'''Погано:'''

<blockquote>
Працював.
</blockquote>

'''Правильно:'''

<blockquote>
Задача K2-145: реалізував фільтр по організації у формі списку, перевірив збереження, 2 години.
</blockquote>

Для контролю якості і продуктивності можуть використовуватись такі мінімальні орієнтири:

* не менше 10 задач на місяць на співробітника;
* не менше 5 презентацій своїх робіт на місяць;
* не менше 5 статей документації по зроблених частинах продукту на місяць;
* документація повинна бути зрозумілою користувачам;
* робочий день може плануватися як 6 годин виконання задач + 2 години навчання.

== Виконання задач у спринті ==

Під час спринту кожна задача повинна проходити контрольований маршрут:

* заплановано;
* в роботі;
* самоперевірка виконавця;
* code review, якщо потрібен;
* тестування;
* перевірка бізнес-аналітика або консультанта, якщо потрібна;
* готово до Demo;
* прийнято;
* закрито.

Задача не повинна перескакувати одразу з “в роботі” в “готово”, якщо вона потребує перевірки.

Для ISO 9001 важливо, щоб у задачі було видно:

* хто виконував;
* хто перевіряв;
* які зауваження були;
* що виправлено;
* хто прийняв результат;
* де є запис Demo або перевірки.

'''Готовність задачі визначається не словами виконавця, а проходженням узгодженого маршруту перевірки.'''

== Definition of Done: коли задача справді готова ==

Задача вважається виконаною тільки тоді, коли виконані умови Definition of Done.

Для K2 ERP Definition of Done включає:

* вимога описана;
* критерії приймання зрозумілі;
* розробник виконав самоперевірку;
* код пройшов перевірку, якщо вона потрібна;
* функціонал протестовано;
* бізнес-логіка погоджена відповідальною особою;
* структура БД погоджена, якщо вона змінювалась;
* права доступу перевірені, якщо вони змінювались;
* API задокументовано, якщо він змінювався;
* міграції перевірені, якщо вони були;
* документація оновлена, якщо це потрібно;
* дефекти виправлені;
* задача готова до Demo або прийнята Product Owner;
* якщо була Zoom-перевірка або Demo — запис збережено у VDoc, а посилання надіслано в Telegram-групу.

<div style="background-color:#eaf7ea; border-left:6px solid #1b8f3a; padding:14px; margin:16px 0;">
'''Definition of Done:''' задача не завершена тоді, коли “код написаний”. Задача завершена тоді, коли результат перевірений, прийнятий і зафіксований.
</div>

== Demo та Review спринту ==

Один раз на тиждень проводиться '''Demo та Review спринту'''.

'''Тривалість у K2 ERP — до 2 годин.'''

Demo проводиться в '''Zoom із записом'''.

Після Demo:

* запис зберігається у VDoc;
* посилання на запис надсилається в Scrum-групу Telegram або групу із замовником;
* рішення Product Owner фіксуються у звіті спринту;
* задачі, які прийняті, закриваються;
* задачі, які не прийняті, повертаються на доопрацювання;
* нові побажання потрапляють у Product Backlog.

Demo — це не презентація заради презентації. Це демонстрація реального інкременту продукту.

На Demo команда показує:

* що було заплановано;
* що реально виконано;
* який функціонал готовий;
* як він працює в системі;
* які задачі не завершені;
* які перешкоди виникли;
* які рішення були прийняті;
* які проблеми залишились;
* що потрібно змінити в Product Backlog;
* що переходить у наступний спринт.

<div style="background-color:#eef5ff; border-left:6px solid #2f80ed; padding:14px; margin:16px 0;">
'''Суть Demo:''' на Demo потрібно показувати працюючий результат, а не обіцянки, слайди чи довгі пояснення.
</div>

== Хто може бути на Demo ==

На Demo можуть бути:

* Product Owner;
* Scrum Master;
* Scrum-команда з 7 співробітників;
* бізнес-аналітики;
* тестувальники;
* бухгалтери-консультанти або галузеві консультанти;
* технічний керівник або архітектор;
* керівництво компанії;
* представники підтримки;
* продажі або маркетинг;
* ключові клієнти або партнери;
* користувачі або представники замовника;
* співробітники інших команд, якщо зміни впливають на їхні модулі.

Для клієнтських задач Demo проводиться із замовником або його представниками.

'''Якщо робота виконувалась для конкретного замовника, результат повинен бути продемонстрований замовнику в Zoom під запис.'''

== Як проходить Demo ==

Demo має чітку структуру.

=== Вступ Scrum Master ===

Scrum Master повідомляє:

* мету спринту;
* скільки задач було заплановано;
* скільки виконано;
* скільки не виконано;
* які були блокери;
* чи досягнута мета спринту;
* що буде показано.

=== Показ виконаних задач ===

Виконавці показують результат у системі.

Для кожної задачі показується:

* яка була вимога;
* що зроблено;
* де це видно в системі;
* який сценарій роботи;
* який результат отримує користувач;
* чи пройдено тестування;
* чи потрібне додаткове погодження.

=== Оцінка Product Owner або замовника ===

Product Owner або замовник оцінює:

* чи відповідає результат очікуванню;
* чи має функціонал цінність;
* чи можна прийняти задачу;
* чи потрібно доробити;
* чи можна включити результат у реліз;
* що потрібно запланувати далі.

=== Коментар бізнес-аналітика або консультанта ===

Бізнес-аналітик або консультант перевіряє:

* чи відповідає логіка бізнес-процесу;
* чи немає помилок у сценарії;
* чи потрібно уточнити вимоги;
* чи є ризики для користувача;
* чи потрібно оновити документацію.

=== Коментар тестувальника ===

Тестувальник повідомляє:

* що перевірено;
* які дефекти знайдені;
* які дефекти виправлені;
* що залишилось перевірити;
* чи можна вважати функціонал готовим.

=== Підсумок Demo ===

У кінці фіксується:

* що прийнято;
* що не прийнято;
* що потребує доопрацювання;
* що готове до релізу;
* що переходить у наступний спринт;
* які рішення прийнято;
* де збережений запис Demo.

== Підготовка до Demo ==

Підготовка до Demo не повинна забирати багато часу.

Для K2 ERP встановлюється правило:

'''підготовка до Demo не повинна займати у команди більше 2 годин.'''

На Demo не потрібно готувати великі презентації PowerPoint. Основний формат — '''показ працюючого функціоналу в системі'''.

Підготовка включає:

* перелік задач для демонстрації;
* послідовність показу;
* тестові дані;
* коротке пояснення сценарію;
* визначення, хто що показує;
* перевірку, що функціонал відкривається і працює;
* підготовку списку питань до Product Owner або замовника.

<div style="background-color:#fff7df; border-left:6px solid #f5a400; padding:14px; margin:16px 0;">
'''Важливо:''' команда не повинна витрачати більше часу на підготовку красивого Demo, ніж на створення реального продукту.
</div>

== Перемовини із замовниками ==

Усі перемовини із замовниками, які стосуються задач, вимог, строків, приймання, демонстрацій, зауважень або змін, проводяться в '''Zoom із записом'''.

Після перемовин:

* запис зберігається у VDoc;
* посилання на запис надсилається в Telegram-групу із замовником;
* ключові рішення фіксуються в задачах або протоколі;
* нові вимоги переносяться в Product Backlog або Sprint Backlog;
* відповідальні та строки фіксуються як Action Items.

На зустрічі із замовником потрібно фіксувати:

* що обговорювали;
* які рішення прийняли;
* які задачі з’явилися;
* які задачі змінилися;
* що замовник погодив;
* що потребує додаткового аналізу;
* хто відповідальний;
* який строк.

<div style="background-color:#eaf7ea; border-left:6px solid #1b8f3a; padding:14px; margin:16px 0;">
'''Правило роботи із замовником:''' жодна важлива домовленість із замовником не повинна залишатися тільки в усній формі. Zoom-запис, VDoc, Telegram-група і задача — це ланцюг доказовості.
</div>

== Постановка задач від замовника ==

Первинна задача може надходити як технічне завдання.

Якщо замовник не може самостійно якісно сформулювати технічне завдання, проводиться Zoom-зустріч із записом.

Після такої зустрічі:

* запис зберігається у VDoc;
* посилання надсилається в групу із замовником;
* бізнес-аналітик або відповідальний співробітник формує задачу;
* задача вноситься в баг-трекер або backlog;
* Product Owner визначає пріоритет;
* команда оцінює складність.

Задача повинна бути сформульована так, щоб було зрозуміло:

* що потрібно зробити;
* де це виконується;
* коли або в яких умовах виникає потреба;
* який очікуваний результат;
* який критерій приймання;
* хто перевіряє результат.

'''Правильно поставлене питання або задача — це значна частина успішного виконання роботи.'''

== Що потрібно підраховувати на Demo ==

На Demo потрібно підготувати підсумкові показники спринту.

Підраховується:

* кількість задач, запланованих у спринті;
* кількість виконаних задач;
* відсоток виконання спринту;
* кількість невиконаних задач;
* кількість задач, перенесених у наступний спринт;
* кількість задач, повернутих на доопрацювання;
* кількість знайдених дефектів;
* кількість виправлених дефектів;
* кількість задач, готових до релізу;
* кількість задач, які потребують документації;
* кількість задач, які потребують додаткового погодження;
* кількість задач, що мали блокери;
* кількість задач, які були змінені під час спринту;
* кількість Zoom-зустрічей, записи яких збережені у VDoc;
* кількість Action Items, закритих у строк.

'''Приклад підсумкового звіту:'''

* '''Заплановано задач:''' 25.
* '''Виконано задач:''' 19.
* '''Виконання спринту:''' 76%.
* '''Не виконано:''' 6.
* '''Перенесено в наступний спринт:''' 4.
* '''Повернуто на доопрацювання:''' 3.
* '''Знайдено дефектів:''' 12.
* '''Виправлено дефектів:''' 9.
* '''Готово до релізу:''' 15.
* '''Потребує документації:''' 5.
* '''Було заблоковано задач:''' 3.
* '''Zoom-записів у VDoc:''' 7.
* '''Action Items закрито:''' 12.

== Ретроспектива спринту ==

Після Demo або окремо після нього проводиться ретроспектива.

Ретроспектива проводиться в '''Zoom із записом'''.

Після ретроспективи:

* запис зберігається у VDoc;
* посилання надсилається в Scrum-групу Telegram;
* покращення фіксуються як Action Items;
* відповідальні та строки вносяться у звіт спринту.

Питання ретроспективи:

* що в цьому спринті спрацювало добре;
* що заважало роботі;
* які задачі були погано описані;
* де були блокери;
* чому задачі не були виконані;
* чи правильно оцінили складність;
* чи вистачило тестування;
* чи були проблеми з комунікацією;
* чи всі Zoom-записи були збережені у VDoc;
* чи всі посилання були скинуті в Telegram;
* чи потрібні зміни в Definition of Done;
* що потрібно змінити в наступному спринті.

Результатом ретроспективи має бути список конкретних дій:

* що покращуємо;
* хто відповідальний;
* до якого строку;
* як перевіримо результат.

'''Якщо після ретроспективи не з’явилося жодної конкретної дії, ретроспектива була формальною.'''

== Звітність по спринту для ISO 9001 ==

Для ISO 9001 результати спринту повинні бути зафіксовані.

Звіт по спринту повинен містити:

* номер спринту;
* дати початку і завершення;
* склад Scrum-команди;
* Scrum Master;
* Product Owner;
* мету спринту;
* список запланованих задач;
* список виконаних задач;
* список невиконаних задач;
* причини невиконання;
* список дефектів;
* список задач, готових до релізу;
* рішення Product Owner;
* ризики, виявлені під час спринту;
* Action Items;
* посилання на Zoom-записи у VDoc;
* посилання на Telegram-групу або повідомлення з підсумками;
* покращення, які потрібно впровадити;
* відповідальних за покращення.

Формат звітності може бути таким:

* таблиця в системі управління задачами;
* звіт у Wiki;
* автоматичний звіт із K2 Projects;
* окремий документ “Звіт спринту”;
* дашборд по команді;
* картка або документ у VDoc.

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

'''Спринт:''' № ___

'''Період:''' з ___ по ___

'''Scrum-команда:''' 7 співробітників

'''Scrum Master:''' ___

'''Product Owner:''' ___

'''Мета спринту:''' ___

'''Посилання на Zoom-записи у VDoc:''' ___

'''Telegram-група:''' ___

=== План спринту ===

* '''Заплановано задач:''' ___
* '''Функціональних задач:''' ___
* '''Багів:''' ___
* '''Задач по БД:''' ___
* '''Задач по API:''' ___
* '''Задач по документації:''' ___
* '''Задач високого ризику:''' ___
* '''Загальна оцінка роботи:''' ___

=== Виконання ===

* '''Виконано задач:''' ___
* '''Не виконано:''' ___
* '''Перенесено:''' ___
* '''Повернуто на доопрацювання:''' ___
* '''Готово до релізу:''' ___
* '''Відсоток виконання:''' ___%

=== Якість ===

* '''Знайдено дефектів:''' ___
* '''Виправлено дефектів:''' ___
* '''Критичних дефектів:''' ___
* '''Дефектів після Demo:''' ___
* '''Задач без документації:''' ___
* '''Задач без перевіряючого:''' ___

=== Комунікації та записи ===

* '''Zoom-зустрічей проведено:''' ___
* '''Записів збережено у VDoc:''' ___
* '''Посилань скинуто в Telegram:''' ___
* '''Перемовин із замовником:''' ___
* '''Action Items створено:''' ___
* '''Action Items закрито:''' ___

=== Блокери ===

* '''Блокер 1:''' ___
** '''Задача:''' ___
** '''Відповідальний:''' ___
** '''Статус:''' ___

* '''Блокер 2:''' ___
** '''Задача:''' ___
** '''Відповідальний:''' ___
** '''Статус:''' ___

=== Action Items ===

* '''Action Item 1:''' ___
** '''Хто:''' ___
** '''Коли:''' ___

* '''Action Item 2:''' ___
** '''Хто:''' ___
** '''Коли:''' ___

=== Прийняті рішення ===

* '''Рішення 1:''' ___
** '''Хто прийняв:''' ___
** '''Дата:''' ___

* '''Рішення 2:''' ___
** '''Хто прийняв:''' ___
** '''Дата:''' ___

=== Покращення на наступний спринт ===

* '''Що покращити:''' ___
** '''Відповідальний:''' ___
** '''Строк:''' ___

<div style="background-color:#eef5ff; border-left:6px solid #2f80ed; padding:14px; margin:16px 0;">
'''Суть звіту:''' звіт спринту повинен давати керівництву і команді чесну картину: що зроблено, що не зроблено, чому не зроблено, де це зафіксовано і що потрібно змінити.
</div>

== Метрики якості Scrum + ISO 9001 ==

Для контролю якості потрібно регулярно аналізувати метрики.

=== Метрики виконання ===

* кількість задач у спринті;
* відсоток виконання спринту;
* кількість перенесених задач;
* кількість задач, доданих після старту спринту;
* середній час виконання задачі;
* кількість заблокованих задач;
* середній час блокера;
* залишок роботи по днях;
* динаміка Sprint Burndown Chart.

=== Метрики якості ===

* кількість дефектів;
* кількість критичних дефектів;
* кількість задач, повернутих на доопрацювання;
* кількість дефектів після релізу;
* кількість hotfix-релізів;
* кількість задач без документації;
* кількість задач без тестування;
* кількість задач без перевіряючого.

=== Метрики комунікацій ===

* кількість Zoom-зустрічей;
* кількість записів, збережених у VDoc;
* кількість посилань, надісланих у Telegram-групи;
* кількість перемовин із замовниками;
* кількість Action Items;
* відсоток закритих Action Items;
* кількість рішень, зафіксованих після зустрічей.

=== Метрики процесу ===

* кількість задач без критеріїв приймання;
* кількість задач з нечіткими вимогами;
* кількість задач, де змінювався обсяг під час спринту;
* кількість задач, які чекали рішення Product Owner;
* кількість задач, які чекали перевірки консультанта;
* кількість задач, які чекали code review;
* кількість Action Items, закритих у строк.

'''Метрики потрібні не для покарання, а для управління процесом і виявлення слабких місць.'''

== Управління дефектами ==

Усі дефекти повинні фіксуватися.

Для кожного дефекту потрібно зазначити:

* де знайдено;
* хто знайшов;
* опис проблеми;
* критичність;
* відповідальний за виправлення;
* строк виправлення;
* статус;
* хто перевірив після виправлення;
* чи є запис Zoom-перевірки або Demo;
* чи потрібно оновити документацію.

Критичність дефектів:

* '''критичний''' — блокує роботу або може пошкодити дані;
* '''високий''' — сильно впливає на бізнес-сценарій;
* '''середній''' — заважає роботі, але є обхідний шлях;
* '''низький''' — косметична або незначна помилка.

<div style="background-color:#fff0f0; border-left:6px solid #e63946; padding:14px; margin:16px 0;">
'''Заборонено:''' закривати дефект без повторної перевірки. Дефект не закритий, поки його не перевірив не той самий співробітник, який його виправляв.
</div>

== Документація ==

Для K2 ERP документація є частиною якості.

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

Документація повинна пояснювати:

* що зроблено;
* для кого це призначено;
* як з цим працювати;
* які є сценарії;
* які є обмеження;
* які є права доступу;
* які типові помилки можуть виникати;
* як перевірити результат.

Документація повинна бути написана не для розробника, а для користувача.

'''Функціонал без зрозумілої документації не може вважатися повністю якісним для продукту K2 ERP.'''

== ISO 9001 і докази виконання ==

Для ISO 9001 важливо не тільки виконувати роботу, а й мати докази.

Доказами можуть бути:

* задача в системі управління проєктами;
* коментарі по задачі;
* історія зміни статусів;
* посилання на коміти;
* результати тестування;
* скріншоти;
* запис Zoom;
* запис у VDoc;
* посилання в Telegram-групі;
* протокол Demo;
* звіт спринту;
* чек-лист релізу;
* запис рішення Product Owner;
* запис про погодження структури БД;
* запис про перевірку консультантом;
* Action Items після Daily Scrum;
* результати ретроспективи.

<div style="background-color:#eaf7ea; border-left:6px solid #1b8f3a; padding:14px; margin:16px 0;">
'''Головне для ISO 9001:''' якщо результат неможливо підтвердити записом, для ISO 9001 він вважається слабко контрольованим.
</div>

== Правила дисципліни Scrum + ISO 9001 + регламент K2 ERP ==

Для стабільної роботи компанії потрібно зафіксувати обов’язкові правила.

# '''Спринт триває 1 тиждень.'''
# '''Scrum-команда складається з 7 співробітників, які виконують роботу в межах спринту.'''
# '''Scrum Master є окремою роллю і не входить у ці 7 виконавців.'''
# '''Кожна задача повинна мати опис, виконавця, перевіряючого і критерій готовності.'''
# '''Кожного дня проводиться Daily Scrum Meeting тривалістю до 15 хвилин.'''
# '''Усі Scrum-зустрічі проводяться в Zoom із записом.'''
# '''Усі записи Zoom зберігаються у VDoc.'''
# '''Посилання на записи надсилаються в Telegram-групу Scrum-команди або групу із замовником.'''
# '''Усі перемовини із замовниками проводяться в Zoom із записом.'''
# '''Усі робочі переписки, крім конфіденційної інформації, ведуться в Telegram-групах.'''
# '''Приватні повідомлення не використовуються для робочих домовленостей, крім передачі конфіденційних даних.'''
# '''Статуси задач оновлюються щоденно.'''
# '''Блокери фіксуються одразу, а не в кінці тижня.'''
# '''Критичні задачі не приймаються самими виконавцями.'''
# '''Зміни в БД, API, правах доступу і бізнес-логіці проходять додаткову перевірку.'''
# '''Scope спринту після старту не змінюється хаотично.'''
# '''Якщо scope потрібно змінити, це погоджується і фіксується.'''
# '''Раз на тиждень проводиться Demo та Review спринту тривалістю до 2 годин.'''
# '''На Demo показується реальний результат у системі.'''
# '''Якщо робота виконувалась для замовника, результат демонструється замовнику в Zoom під запис.'''
# '''Після спринту формується звіт з цифрами, висновками, записами і діями для покращення.'''
# '''Невиконані задачі аналізуються за причинами.'''
# '''Дефекти фіксуються, класифікуються і перевіряються після виправлення.'''
# '''Результати спринту використовуються для покращення наступного спринту.'''
# '''Уся важлива інформація повинна бути зафіксована в системі, а не залишатися “на словах”.'''

<div style="background-color:#eef5ff; border-left:6px solid #2f80ed; padding:14px; margin:16px 0;">
'''Фінальна логіка:''' Scrum дає ритм. ISO 9001 дає контроль. Регламент K2 ERP дає доказовість. Разом вони створюють керовану систему якості.
</div>

== Що потрібно заборонити ==

Для дотримання якості потрібно прямо заборонити:

* задачі без опису;
* задачі без виконавця;
* задачі без перевіряючого;
* задачі без критеріїв готовності;
* закриття задачі без перевірки;
* приховування блокерів;
* перенесення задач без пояснення причини;
* додавання задач у спринт без погодження;
* хаотичну зміну Sprint Backlog;
* зміну БД без погодження;
* зміну API без документації;
* реліз без тестування;
* Demo без запису Zoom;
* Zoom без збереження у VDoc;
* VDoc без посилання в Telegram-групі;
* усні домовленості із замовником без фіксації;
* робочі домовленості в приватних повідомленнях;
* демонстрацію неготового функціоналу як готового;
* закриття дефекту без повторної перевірки;
* формальні Daily Scrum без оновлення статусів;
* формальні ретроспективи без дій для покращення;
* витрачання часу на красиві презентації замість реального продукту;
* перетворення Scrum Master на людину, яка просто роздає задачі;
* перетворення Product Owner на комітет без єдиного рішення.

<div style="background-color:#fff0f0; border-left:6px solid #e63946; padding:14px; margin:16px 0;">
'''Критично:''' якщо робота не зафіксована, її складно захистити перед клієнтом, командою, керівництвом або аудитом ISO 9001.
</div>

== Висновок: якість — це не героїзм, а система ==

'''ISO 9001, Scrum і регламент K2 ERP повинні працювати як єдина система.'''

Для K2 ERP це означає, що кожен тиждень команда проходить повний керований цикл:

* планування;
* Zoom-запис;
* VDoc;
* Telegram-фіксація;
* виконання;
* щоденний контроль;
* усунення блокерів;
* перевірка;
* тестування;
* Demo та Review;
* приймання;
* звіт;
* аналіз;
* покращення.

Спринт тривалістю '''1 тиждень''' дозволяє швидко рухатися. Daily Scrum Meeting тривалістю '''до 15 хвилин''' дозволяє бачити проблеми одразу. Demo та Review спринту тривалістю '''до 2 годин''' дозволяє Product Owner, Scrum Master, команді, консультантам, підтримці, керівництву та замовникам бачити реальний результат.

Для ISO 9001 важливо, щоб усе це було не тільки зроблено, а й '''зафіксовано, перевірено, збережено і проаналізовано'''.

<div style="background-color:#101828; color:#ffffff; padding:18px; margin:18px 0;">
'''Головна формула роботи K2 ERP:'''

Scrum-команда з 7 співробітників виконує роботу. Scrum Master організовує процес. Product Owner визначає пріоритети і приймає ключовий результат. Zoom фіксує зустрічі. VDoc зберігає докази. Telegram забезпечує прозору комунікацію. ISO 9001 забезпечує контроль якості, доказовість, аналіз і постійне покращення.
</div>

Кожен спринт повинен давати '''вимірюваний результат'''. Кожна задача повинна мати '''відповідального'''. Кожен критичний результат повинен мати '''перевіряючого'''. Кожна зустріч повинна мати '''запис'''. Кожен запис повинен бути '''збережений у VDoc'''. Кожне важливе рішення повинно бути '''передане в Telegram-групу або зафіксоване в задачі'''.

Саме така система дозволяє K2 ERP розвиватися швидко, але не хаотично; масштабувати команду, але не втрачати контроль; працювати із замовниками прозоро; випускати новий функціонал, але зберігати якість; будувати українську ERP-платформу, яка може стабільно автоматизувати складні бізнес-процеси та замінювати застарілі програмні рішення на ринку.

'''K2 ERP — якість не на словах, а в процесі.'''