← Попереднє редагування Наступне редагування →

Версія за 05:34, 22 червня 2026

ISO 9001 + Scrum + регламент K2 ERP: як побудувати систему якості в продуктовій IT-компанії

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

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

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

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

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

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

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

Ключовий меседж: ISO 9001 у K2 ERP — це не папери заради сертифікату. Це система, яка робить розробку керованою: кожна задача має опис, виконавця, перевіряючого, критерій готовності, записані зустрічі, збережені матеріали, прозору комунікацію і вимірюваний результат.

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

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

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

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

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

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

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

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

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

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

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.

Важливо: Scrum-команда виконує роботу. Scrum Master організовує процес. Product Owner визначає пріоритети і приймає ключовий результат. ISO 9001 вимагає доказів якості. Регламент K2 ERP визначає, де ці докази зберігаються.

Ролі в Scrum + ISO 9001

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

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

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

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

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

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

Якщо ролі розмиті	Якщо ролі визначені
Незрозуміло, хто поставив задачу, хто перевірив, хто прийняв, хто мав зберегти запис і хто відповідає за результат.	Відомо, хто відповідає за вимогу, реалізацію, перевірку, Demo, запис у VDoc, рішення Product Owner і подальші дії.

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;
аналіз результату.

Правило спринту: спринт повинен завершуватися не поясненнями, а результатом, який можна показати. Якщо команда тиждень “щось робила”, але показати нічого — це сигнал проблеми в плануванні, виконанні або контролі.

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

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

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

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

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

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

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

Заборонено: хаотично змінювати Sprint Backlog після старту спринту. Якщо зміна потрібна — вона фіксується, погоджується і має доказ.

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

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

Планування проводиться в 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 потрібен, щоб команда бачила:

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

Суть Daily Scrum: це не довга нарада, не звіт начальнику і не технічна дискусія. Це коротка синхронізація команди з фіксацією результату.

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

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

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

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

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

Погано:

Працював над модулем.

Правильно:

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

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

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

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

Погано:

Буду продовжувати.

Правильно:

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

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

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

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

Важливо: блокер не можна приховувати. Якщо проблема не озвучена вчасно, вона стає ризиком зриву спринту. Краще сказати про ризик у вівторок, ніж пояснювати провал у п’ятницю.

Action Items після Daily Scrum

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

Формат Action Item:

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

Приклад:

Що

Хто

Коли

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

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

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

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

Заборонено: перетворювати 15-хвилинну конференцію на довгу нараду. Daily Scrum — це контроль руху, а не місце для вирішення всіх проблем.

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

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

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

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

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

День

Заплановано задач

В роботі

На перевірці

Виконано

Заблоковано

Ризик невиконання

Готово до Demo

Залишок роботи

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

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

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

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

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

Погано:

Працював.

Правильно:

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

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

не менше 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-групу.

Definition of Done: задача не завершена тоді, коли “код написаний”. Задача завершена тоді, коли результат перевірений, прийнятий і зафіксований.

Demo та Review спринту

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

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

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

Після Demo:

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

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

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

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

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

Хто може бути на 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 або замовника.

Важливо: команда не повинна витрачати більше часу на підготовку красивого Demo, ніж на створення реального продукту.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Показник

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

Після 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-група: ___

План спринту

Показник

Виконання

Показник

Якість

Показник

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

Показник

Блокери

Блокер

Задача

Відповідальний

Action Items

Що зробити

Хто

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

Рішення

Хто прийняв

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

Що покращити

Відповідальний

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заборонено: закривати дефект без повторної перевірки. Дефект не закритий, поки його не перевірив не той самий співробітник, який його виправляв.

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

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

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

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

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

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

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

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

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

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

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

Головне для ISO 9001: якщо результат неможливо підтвердити записом, для ISO 9001 він вважається слабко контрольованим.

Правила дисципліни 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 під запис.

Після спринту формується звіт з цифрами, висновками, записами і діями для покращення.

Невиконані задачі аналізуються за причинами.

Дефекти фіксуються, класифікуються і перевіряються після виправлення.

Результати спринту використовуються для покращення наступного спринту.

Уся важлива інформація повинна бути зафіксована в системі, а не залишатися “на словах”.

Фінальна логіка: Scrum дає ритм. ISO 9001 дає контроль. Регламент K2 ERP дає доказовість. Разом вони створюють керовану систему якості.

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

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

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

Критично: якщо робота не зафіксована, її складно захистити перед клієнтом, командою, керівництвом або аудитом ISO 9001.

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

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 важливо, щоб усе це було не тільки зроблено, а й зафіксовано, перевірено, збережено і проаналізовано.

Головна формула роботи K2 ERP:

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

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

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

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