Впровадження ISO 9001 у продуктовій IT-компанії не повинно бути формальністю або набором документів для сертифікації. Для K2 ERP ISO 9001 має працювати як система управління якістю, Scrum — як механізм щотижневого планування, щоденного контролю і демонстрації результату, а внутрішній регламент компанії — як правила фіксації комунікацій, задач, перемовин, рішень і доказів виконання робіт.
K2 ERP розробляється як українська ERP-платформа для автоматизації будь-яких бізнес-процесів: бухгалтерії, фінансів, складу, виробництва, документообігу, CRM, HR, управління проєктами, звітності, API, інтеграцій, аналітики та інших напрямків.
Тому якість у такому продукті — це не тільки відсутність помилок у коді. Якість — це правильна бізнес-логіка, контроль структури бази даних, перевірені права доступу, зрозумілі вимоги, зафіксовані рішення, записані зустрічі, прозора переписка, керовані спринти, перевірені релізи і доказовість кожного важливого етапу роботи.
Головний принцип:
ISO 9001 визначає, що процеси мають бути керованими, перевіреними і задокументованими. Scrum визначає, як команда щотижня планує, виконує, контролює і демонструє результат. Регламент K2 ERP визначає, де саме фіксуються комунікації, записи, задачі, домовленості та підтвердження виконання робіт.
1. Навіщо поєднувати ISO 9001, Scrum і внутрішній регламент
ISO 9001 відповідає на питання:
як забезпечити стабільну якість продукту;
як контролювати процеси;
як фіксувати відповідальність;
як управляти ризиками;
як аналізувати помилки;
як доводити, що робота виконана якісно;
як постійно покращувати компанію.
Scrum відповідає на питання:
як організувати роботу команди;
як планувати короткі цикли розробки;
як щодня бачити прогрес;
як виявляти блокери одразу, а не в кінці тижня;
як демонструвати готовий результат;
як отримувати зворотний зв’язок;
як швидко покращувати продукт.
Регламент K2 ERP відповідає на питання:
де фіксуються задачі;
де ведеться переписка;
як проводяться Zoom-зустрічі;
де зберігаються записи;
де зберігаються домовленості;
як передаються посилання на записи;
як контролюється робочий час;
як підтверджується виконання робіт.
Разом ці три елементи створюють систему:
Scrum дає ритм. ISO 9001 дає контроль якості. Регламент дає доказовість і порядок комунікацій.
2. Основна модель роботи K2 ERP
У K2 ERP використовується Scrum-підхід із тижневим спринтом.
Спринт — це 1 тиждень.
Протягом одного тижня команда повинна:
взяти узгоджений обсяг задач;
виконати роботу;
провести самоперевірку;
передати задачі на перевірку;
виправити дефекти;
підготувати результат до Demo;
показати результат Product Owner, команді, консультантам або замовнику;
зафіксувати результат, рішення, проблеми і покращення.
Scrum-команда K2 ERP складається з:
7 співробітників, які безпосередньо виконують роботу в межах спринту + 1 Scrum Master.
Тобто базова модель:
7 учасників команди + 1 Scrum Master.
Scrum Master не входить у ці 7 виконавців. Він є окремою роллю, яка відповідає за процес, прозорість, дисципліну, Daily Scrum, блокери, Demo, ретроспективу і контроль виконання правил Scrum.
Головне правило:
Команда виконує роботу. Scrum Master організовує процес. Product Owner визначає пріоритети. ISO 9001 вимагає доказів якості. Регламент визначає, де ці докази зберігаються.
3. Канали комунікації та фіксації інформації
Для дотримання ISO 9001 усі важливі комунікації повинні бути зафіксовані.
У K2 ERP діють такі правила комунікації:
усі Scrum-зустрічі проводяться в Zoom із записом;
усі зустрічі із замовниками проводяться в Zoom із записом;
усі перемовини з клієнтами щодо задач, вимог, демонстрацій і приймання робіт проводяться через Zoom із записом;
записи Zoom зберігаються у VDoc;
посилання на запис Zoom після збереження у VDoc надсилається в Telegram-групу;
для внутрішніх Scrum-команд посилання надсилається в Scrum-групу Telegram;
для зустрічей із замовником посилання надсилається в Telegram-групу із замовником;
усі робочі переписки, крім конфіденційної інформації, ведуться в групах Telegram;
приватні повідомлення не використовуються для робочих домовленостей, крім передачі паролів або іншої конфіденційної інформації;
Email використовується переважно для пересилання матеріалів, технічних завдань або офіційних документів;
телефон не є основним способом постановки або приймання задач.
Головне правило:
Якщо домовленість не зафіксована в задачі, VDoc, Telegram-групі або іншій офіційній системі — вона не повинна вважатися контрольованою для ISO 9001.
4. Zoom, VDoc і Telegram як докази ISO 9001
Для ISO 9001 важливо не тільки виконувати роботу, а й мати докази.
У K2 ERP такими доказами є:
запис Zoom-зустрічі;
збереження запису у VDoc;
посилання на запис у Telegram-групі;
задача в баг-трекері;
коментарі в задачі;
історія статусів;
рішення Product Owner;
погодження замовника;
підтвердження Demo;
матеріали, передані Email;
документація у Wiki або VDoc;
звіт спринту.
Для кожної важливої Zoom-зустрічі потрібно фіксувати:
дату;
тему;
учасників;
мету зустрічі;
короткий результат;
посилання на запис у VDoc;
посилання на пов’язану задачу або спринт;
прийняті рішення;
Action Items.
Головне правило:
Запис Zoom без збереження у VDoc і без посилання в Telegram-групі не є повноцінно зафіксованим результатом зустрічі.
5. Робочі групи Telegram
Для кожної Scrum-команди створюється окрема Telegram-група.
У Scrum-групу входять:
Scrum Master;
7 учасників команди;
Product Owner за потреби;
бізнес-аналітик;
тестувальник;
консультант;
технічний керівник або архітектор;
інші відповідальні особи, якщо вони потрібні для спринту.
У Telegram-групі фіксуються:
посилання на Zoom-зустрічі;
посилання на записи у VDoc;
нагадування про Daily Scrum;
короткі рішення;
блокери;
Action Items;
посилання на задачі;
нагадування про Demo;
підсумки спринту.
Для клієнтських проєктів створюється окрема Telegram-група із замовником.
У групу із замовником можуть входити:
представники замовника;
керівництво K2;
Product Owner або відповідальний менеджер;
бізнес-аналітик;
розробники або технічні спеціалісти за потреби;
консультанти;
підтримка.
У клієнтській групі фіксуються:
питання замовника;
посилання на Zoom-записи;
посилання на матеріали у VDoc;
поточні статуси;
уточнення вимог;
погодження результату;
інформація про Demo;
важливі домовленості.
Головне правило:
Робоча переписка повинна бути груповою і прозорою. Приватна переписка не повинна замінювати офіційний канал роботи.
6. Конфіденційна інформація
Не вся інформація може передаватися у відкритих групах.
До конфіденційної інформації належать:
паролі;
токени доступу;
ключі API;
персональні дані;
фінансові дані з обмеженим доступом;
внутрішні комерційні умови;
дані, які замовник прямо позначив як конфіденційні.
Таку інформацію не потрібно публікувати у відкритих Telegram-групах. Вона повинна передаватися через захищений або погоджений канал.
Але навіть у цьому випадку потрібно зафіксувати факт:
який доступ потрібен;
для якої задачі;
хто відповідальний;
кому надано;
коли потрібно відкликати або змінити доступ.
Головне правило:
Конфіденційні дані не публікуються в групах, але факт потреби, відповідальний і контекст доступу повинні бути контрольованими.
7. Ролі Scrum + ISO 9001
У Scrum є три базові ролі:
Scrum Master;
Product Owner;
Team / команда.
У K2 ERP ці ролі доповнюються практичними спеціалізаціями, потрібними для ERP-розробки:
бізнес-аналітик;
розробник;
тестувальник;
бухгалтер-консультант;
галузевий консультант;
архітектор або технічний керівник;
відповідальний за документацію;
відповідальний за клієнтську комунікацію.
Кожна роль повинна мати зрозумілу зону відповідальності.
Головне правило:
Scrum оцінює результат команди, але ISO 9001 вимагає, щоб було зрозуміло, хто виконав, хто перевірив, хто погодив і де це зафіксовано.
8. Scrum Master
Scrum Master — це відповідальний за успіх Scrum-процесу в команді.
Scrum Master є зв’язком між менеджментом, 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-подій.
9. Product Owner
Product Owner — це єдина точка прийняття остаточних продуктових рішень.
У K2 ERP цю роль фактично виконує керівник компанії або призначена ним відповідальна особа.
Product Owner відповідає за:
product vision;
стратегію розвитку K2 ERP;
пріоритети Product Backlog;
очікування клієнтів, партнерів і зацікавлених сторін;
цінність задач для продукту;
ROI;
підготовку зрозумілих і тестованих вимог;
приймання результату наприкінці спринту;
рішення, що потрапляє в реліз;
рішення, що повертається на доопрацювання.
Product Owner може ставити задачі команді, але не повинен під час спринту хаотично роздавати задачі конкретним співробітникам.
Головне правило:
Product Owner визначає “що і навіщо потрібно зробити”, а команда визначає “як саме це зробити в межах спринту”.
10. Scrum-команда
Scrum-команда K2 ERP — це 7 співробітників, які безпосередньо виконують роботу в межах спринту.
Команда є самоорганізованою та самоврядною. Вона бере на себе зобов’язання перед Product Owner щодо виконання обсягу робіт на спринт.
До команди можуть входити:
розробники;
бізнес-аналітик;
тестувальник;
бухгалтер-консультант;
галузевий консультант;
архітектор або технічний керівник;
інший спеціаліст, необхідний для виконання задач спринту.
Команда відповідає за:
оцінку задач;
декомпозицію задач;
прийняття рішень щодо реалізації;
розробку функціоналу;
самоперевірку;
участь у тестуванні;
відстеження власного прогресу;
демонстрацію результату;
відповідальність за результат перед Product Owner.
Головне правило:
Команда відповідає не за активність, а за готовий результат спринту.
11. Product Backlog
Product Backlog — це пріоритизований список бізнес-вимог, технічних вимог, задач, дефектів, покращень і майбутніх можливостей продукту.
У Product Backlog можуть бути:
нові модулі;
новий функціонал;
покращення існуючих модулів;
дефекти;
технічний борг;
зміни в базі даних;
API та інтеграції;
документація;
задачі з тестування;
задачі з продуктивності;
задачі з безпеки;
задачі з навчання команди;
інфраструктурні задачі;
звернення клієнтів, які стали продуктовими вимогами.
За Product Backlog відповідає Product Owner.
Головне правило:
Product Backlog — це не смітник ідей. Це керована черга розвитку продукту.
12. Sprint Backlog
Sprint Backlog — це набір задач, які команда бере в роботу на конкретний спринт.
Кожна задача повинна мати:
назву;
опис;
тип;
пріоритет;
оцінку складності або часу;
виконавця;
перевіряючого;
критерій готовності;
статус;
ризик;
очікуваний результат.
Кожного дня команда оцінює, який обсяг роботи ще залишився для завершення задач спринту.
Головне правило:
Sprint Backlog повинен показувати не тільки те, що заплановано, а й скільки реально залишилося зробити.
13. Спринт
Спринт у K2 ERP триває 1 тиждень.
Результатом спринту має бути інкремент продукту — готовий, перевірений або принаймні придатний для демонстрації результат.
Для K2 ERP це може бути:
нова форма;
новий документ;
новий звіт;
новий API-метод;
нова інтеграція;
виправлений дефект;
оновлена документація;
покращений бізнес-процес;
частина нового модуля, яку вже можна показати.
Кожен спринт є маленьким циклом повної розробки:
уточнення вимог;
проєктування;
розробка;
самоперевірка;
code review;
тестування;
предметна перевірка;
підготовка до Demo;
Demo;
аналіз результату.
Головне правило:
Спринт повинен завершуватися не поясненнями, а результатом, який можна показати.
14. Фіксований scope спринту
Scope спринту повинен бути фіксованим.
Після старту спринту Sprint Backlog не повинен хаотично змінюватися.
Змінювати Sprint Backlog можна тільки у виняткових випадках:
критичний дефект;
важливий блокер клієнта;
ризик зупинки системи;
терміновий hotfix;
рішення Product Owner про зміну мети спринту;
виявлення того, що частина scope не може бути виконана без зміни підходу.
Якщо зміна потрібна, вона повинна бути:
погоджена;
зафіксована в задачі;
обговорена в Telegram-групі;
за потреби підтверджена Zoom-зустріччю із записом;
відображена у звіті спринту.
Головне правило:
Sprint Backlog не змінюється хаотично. Якщо зміна потрібна — вона фіксується, погоджується і має доказ.
15. Планування спринту
Планування спринту проводиться на початку тижня.
Планування проводиться в Zoom із записом.
Після зустрічі:
запис зберігається у VDoc;
посилання на запис надсилається в Scrum-групу Telegram;
рішення по спринту фіксуються в Sprint Backlog;
ключові Action Items фіксуються окремо.
У плануванні беруть участь:
Product Owner;
Scrum Master;
Scrum-команда з 7 співробітників;
бізнес-аналітик;
розробники;
тестувальник;
консультанти;
технічний керівник або архітектор;
за потреби — представники менеджменту, підтримки, продажів або ключові користувачі.
На плануванні визначається:
мета спринту;
список задач;
пріоритети;
виконавці;
перевіряючі;
ризики;
критерії готовності;
що буде показано на Demo;
які задачі потребують участі консультанта;
які задачі потребують погодження БД, API або прав доступу.
Головне правило:
Планування спринту без запису Zoom, VDoc і посилання в Telegram-групі не є повністю зафіксованим процесом для ISO 9001.
16. Daily Scrum Meeting
Daily Scrum Meeting проводиться кожного робочого дня.
Тривалість — до 15 хвилин.
Daily Scrum проводиться в Zoom із записом.
Після Daily Scrum:
запис зберігається у VDoc;
посилання на запис надсилається в Scrum-групу Telegram;
Action Items фіксуються в Telegram або в задачах;
статуси задач оновлюються в системі управління задачами.
Daily Scrum потрібен, щоб команда бачила:
що зроблено;
що буде зроблено сьогодні;
які є проблеми;
які є блокери;
чи є ризик невиконання задач;
чи потрібна допомога.
Головне правило:
Daily Scrum — це не довга нарада, не звіт начальнику і не технічна дискусія. Це коротка синхронізація команди з фіксацією результату.
17. Питання Daily Scrum
Scrum Master по колу ставить кожному учаснику три базові питання.
Питання 1. Що було зроблено вчора або з минулої конференції?
Відповідь повинна бути конкретною:
яка задача виконувалась;
який результат отримано;
що вже готово;
що передано на перевірку;
що закрито.
Погано:
“Працював над модулем.”
Правильно:
“По задачі K2-145 реалізував форму списку, додав фільтр по організації, перевірив збереження, передав на тестування.”
Питання 2. Що буде зроблено сьогодні?
Потрібно розкрити:
яку задачу продовжує;
яку частину планує завершити;
що має бути готово до кінця дня;
чи буде задача передана на перевірку;
чи є потреба в допомозі.
Погано:
“Буду продовжувати.”
Правильно:
“Сьогодні завершую права доступу по формі, додаю перевірку ролей і передаю задачу бізнес-аналітику на функціональну перевірку.”
Питання 3. З якими проблемами зіткнувся?
Потрібно чесно назвати блокери:
немає вимог;
незрозуміла бізнес-логіка;
потрібне рішення Product Owner;
потрібне погодження структури БД;
є технічна залежність;
не вистачає тестових даних;
немає доступу;
не проходить тест;
немає перевіряючого;
потрібна консультація бухгалтера або галузевого спеціаліста.
Головне правило:
Блокер не можна приховувати. Якщо проблема не озвучена вчасно, вона стає ризиком зриву спринту.
18. Action Items після Daily Scrum
Якщо під час Daily Scrum виникає питання, яке потребує окремого обговорення, Scrum Master фіксує його як Action Item.
Формат Action Item:
що потрібно зробити;
хто бере участь;
коли це має бути зроблено;
де буде зафіксований результат.
Приклад:
Що: погодити структуру таблиці для нового регістру.
Хто: розробник, архітектор, бізнес-аналітик.
Коли: сьогодні до 15:00.
Де фіксуємо: задача + Telegram-група + за потреби Zoom-запис у VDoc.
Головне правило:
Daily Scrum не вирішує всі проблеми. Він виявляє проблеми і запускає окремі короткі дії для їх вирішення.
19. Чого не можна робити на Daily Scrum
На Daily Scrum заборонено:
розбирати складну архітектуру;
проводити code review;
детально тестувати функціонал;
сперечатися про продуктові рішення;
читати лекції;
влаштовувати пошук винних;
обговорювати задачі, які не стосуються поточного спринту;
перетворювати Daily Scrum на годинну нараду.
Головне правило:
15-хвилинна конференція — це контроль руху, а не місце для вирішення всіх проблем.
20. Що потрібно підраховувати щодня
Після кожного Daily Scrum потрібно оновлювати показники спринту.
Підраховується:
скільки задач у роботі;
скільки задач виконано;
скільки задач на перевірці;
скільки задач заблоковано;
скільки задач мають ризик невиконання;
скільки задач прострочено;
скільки задач повернуто на доопрацювання;
скільки задач готові до Demo;
скільки роботи залишилось у годинах або story points;
який відсоток виконання спринту;
чи відповідає темп виконання плану тижня.
Приклад щоденного звіту:
| День | Заплановано задач | В роботі | На перевірці | Виконано | Заблоковано | Ризик невиконання | Готово до Demo | Залишок роботи | Коментар |
|---|---|---|---|---|---|---|---|---|---|
| Понеділок | 25 | 18 | 2 | 1 | 1 | 3 | 0 | 160 год | Старт спринту |
| Вівторок | 25 | 16 | 4 | 4 | 2 | 4 | 1 | 125 год | Є блокери по БД |
| Середа | 25 | 12 | 6 | 8 | 1 | 3 | 4 | 85 год | Частина задач на тестуванні |
| Четвер | 25 | 7 | 8 | 14 | 1 | 2 | 9 | 42 год | Готуємо Demo |
| П’ятниця | 25 | 2 | 4 | 19 | 0 | 1 | 15 | 12 год | Demo |
Головне правило:
Якщо щодня не видно динаміки виконання, команда керується відчуттями, а не фактами.
21. Ведення часу і продуктивності
Співробітники повинні відмічати час у баг-трекері день у день.
Опис часу повинен бути зрозумілим:
що робилось;
по якій задачі;
який результат;
скільки часу витрачено;
чи завершено дію;
чи потрібне продовження.
Погано:
“Працював.”
Правильно:
“Задача K2-145: реалізував фільтр по організації у формі списку, перевірив збереження, 2 години.”
Для контролю якості і продуктивності можуть використовуватись такі мінімальні орієнтири:
не менше 10 задач на місяць на співробітника;
не менше 5 презентацій своїх робіт на місяць;
не менше 5 статей документації по зроблених частинах продукту на місяць;
документація повинна бути зрозумілою користувачам;
робочий день може плануватися як 6 годин виконання задач + 2 години навчання.
Головне правило:
Час повинен фіксуватися так, щоб було зрозуміло, що саме робилось і чи відповідають витрати часу результату.
22. Виконання задач у спринті
Під час спринту кожна задача повинна проходити контрольований маршрут:
заплановано;
в роботі;
самоперевірка виконавця;
code review, якщо потрібен;
тестування;
перевірка бізнес-аналітика або консультанта, якщо потрібна;
готово до Demo;
прийнято;
закрито.
Задача не повинна перескакувати одразу з “в роботі” в “готово”, якщо вона потребує перевірки.
Для ISO 9001 важливо, щоб у задачі було видно:
хто виконував;
хто перевіряв;
які зауваження були;
що виправлено;
хто прийняв результат;
де є запис Demo або перевірки.
Головне правило:
Готовність задачі визначається не словами виконавця, а проходженням узгодженого маршруту перевірки.
23. Definition of Done
Задача вважається виконаною тільки тоді, коли виконані умови Definition of Done.
Для K2 ERP Definition of Done включає:
вимога описана;
критерії приймання зрозумілі;
розробник виконав самоперевірку;
код пройшов перевірку, якщо вона потрібна;
функціонал протестовано;
бізнес-логіка погоджена відповідальною особою;
структура БД погоджена, якщо вона змінювалась;
права доступу перевірені, якщо вони змінювались;
API задокументовано, якщо він змінювався;
міграції перевірені, якщо вони були;
документація оновлена, якщо це потрібно;
дефекти виправлені;
задача готова до Demo або прийнята Product Owner;
якщо була Zoom-перевірка або Demo — запис збережено у VDoc, а посилання надіслано в Telegram-групу.
Головне правило:
Задача не завершена тоді, коли “код написаний”. Задача завершена тоді, коли результат перевірений, прийнятий і зафіксований.
24. Demo та Review спринту
Один раз на тиждень проводиться Demo та Review спринту.
Тривалість у K2 ERP — до 2 годин.
Demo проводиться в Zoom із записом.
Після Demo:
запис зберігається у VDoc;
посилання на запис надсилається в Scrum-групу Telegram або групу із замовником;
рішення Product Owner фіксуються у звіті спринту;
задачі, які прийняті, закриваються;
задачі, які не прийняті, повертаються на доопрацювання;
нові побажання потрапляють у Product Backlog.
Demo — це не презентація заради презентації. Це демонстрація реального інкременту продукту.
На Demo команда показує:
що було заплановано;
що реально виконано;
який функціонал готовий;
як він працює в системі;
які задачі не завершені;
які перешкоди виникли;
які рішення були прийняті;
які проблеми залишились;
що потрібно змінити в Product Backlog;
що переходить у наступний спринт.
Головне правило:
На Demo потрібно показувати працюючий результат, а не обіцянки, слайди чи довгі пояснення.
25. Хто може бути на Demo
На Demo можуть бути:
Product Owner;
Scrum Master;
Scrum-команда з 7 співробітників;
бізнес-аналітики;
тестувальники;
бухгалтери-консультанти або галузеві консультанти;
технічний керівник або архітектор;
керівництво компанії;
представники підтримки;
продажі або маркетинг;
ключові клієнти або партнери;
користувачі або представники замовника;
співробітники інших команд, якщо зміни впливають на їхні модулі.
Для клієнтських задач Demo проводиться із замовником або його представниками.
Головне правило:
Якщо робота виконувалась для конкретного замовника, результат повинен бути продемонстрований замовнику в Zoom під запис.
26. Як проходить Demo
Demo має чітку структуру.
26.1. Вступ Scrum Master
Scrum Master повідомляє:
мету спринту;
скільки задач було заплановано;
скільки виконано;
скільки не виконано;
які були блокери;
чи досягнута мета спринту;
що буде показано.
26.2. Показ виконаних задач
Виконавці показують результат у системі.
Для кожної задачі показується:
яка була вимога;
що зроблено;
де це видно в системі;
який сценарій роботи;
який результат отримує користувач;
чи пройдено тестування;
чи потрібне додаткове погодження.
26.3. Оцінка Product Owner або замовника
Product Owner або замовник оцінює:
чи відповідає результат очікуванню;
чи має функціонал цінність;
чи можна прийняти задачу;
чи потрібно доробити;
чи можна включити результат у реліз;
що потрібно запланувати далі.
26.4. Коментар бізнес-аналітика або консультанта
Бізнес-аналітик або консультант перевіряє:
чи відповідає логіка бізнес-процесу;
чи немає помилок у сценарії;
чи потрібно уточнити вимоги;
чи є ризики для користувача;
чи потрібно оновити документацію.
26.5. Коментар тестувальника
Тестувальник повідомляє:
що перевірено;
які дефекти знайдені;
які дефекти виправлені;
що залишилось перевірити;
чи можна вважати функціонал готовим.
26.6. Підсумок Demo
У кінці фіксується:
що прийнято;
що не прийнято;
що потребує доопрацювання;
що готове до релізу;
що переходить у наступний спринт;
які рішення прийнято;
де збережений запис Demo.
Головне правило:
Після Demo не повинно залишатися невизначеності: що прийнято, що не прийнято, що доробляємо і що плануємо далі.
27. Підготовка до Demo
Підготовка до Demo не повинна забирати багато часу.
Для K2 ERP встановлюється правило:
підготовка до Demo не повинна займати у команди більше 2 годин.
На Demo не потрібно готувати великі презентації PowerPoint. Основний формат — показ працюючого функціоналу в системі.
Підготовка включає:
перелік задач для демонстрації;
послідовність показу;
тестові дані;
коротке пояснення сценарію;
визначення, хто що показує;
перевірку, що функціонал відкривається і працює;
підготовку списку питань до Product Owner або замовника.
Головне правило:
Команда не повинна витрачати більше часу на підготовку красивого Demo, ніж на створення реального продукту.
28. Перемовини із замовниками
Усі перемовини із замовниками, які стосуються задач, вимог, строків, приймання, демонстрацій, зауважень або змін, проводяться в Zoom із записом.
Після перемовин:
запис зберігається у VDoc;
посилання на запис надсилається в Telegram-групу із замовником;
ключові рішення фіксуються в задачах або протоколі;
нові вимоги переносяться в Product Backlog або Sprint Backlog;
відповідальні та строки фіксуються як Action Items.
На зустрічі із замовником потрібно фіксувати:
що обговорювали;
які рішення прийняли;
які задачі з’явилися;
які задачі змінилися;
що замовник погодив;
що потребує додаткового аналізу;
хто відповідальний;
який строк.
Головне правило:
Жодна важлива домовленість із замовником не повинна залишатися тільки в усній формі. Zoom-запис, VDoc, Telegram-група і задача — це ланцюг доказовості.
29. Постановка задач від замовника
Первинна задача може надходити як технічне завдання.
Якщо замовник не може самостійно якісно сформулювати технічне завдання, проводиться Zoom-зустріч із записом.
Після такої зустрічі:
запис зберігається у VDoc;
посилання надсилається в групу із замовником;
бізнес-аналітик або відповідальний співробітник формує задачу;
задача вноситься в баг-трекер або backlog;
Product Owner визначає пріоритет;
команда оцінює складність.
Задача повинна бути сформульована так, щоб було зрозуміло:
що потрібно зробити;
де це виконується;
коли або в яких умовах виникає потреба;
який очікуваний результат;
який критерій приймання;
хто перевіряє результат.
Головне правило:
Правильно поставлене питання або задача — це значна частина успішного виконання роботи.
30. Що потрібно підраховувати на Demo
На Demo потрібно підготувати підсумкові показники спринту.
Підраховується:
кількість задач, запланованих у спринті;
кількість виконаних задач;
відсоток виконання спринту;
кількість невиконаних задач;
кількість задач, перенесених у наступний спринт;
кількість задач, повернутих на доопрацювання;
кількість знайдених дефектів;
кількість виправлених дефектів;
кількість задач, готових до релізу;
кількість задач, які потребують документації;
кількість задач, які потребують додаткового погодження;
кількість задач, що мали блокери;
кількість задач, які були змінені під час спринту;
кількість Zoom-зустрічей, записи яких збережені у VDoc;
кількість Action Items, закритих у строк.
Приклад підсумкового звіту:
| Показник | Значення |
| Заплановано задач | 25 |
| Виконано задач | 19 |
| Виконання спринту | 76% |
| Не виконано | 6 |
| Перенесено в наступний спринт | 4 |
| Повернуто на доопрацювання | 3 |
| Знайдено дефектів | 12 |
| Виправлено дефектів | 9 |
| Готово до релізу | 15 |
| Потребує документації | 5 |
| Було заблоковано задач | 3 |
| Zoom-записів у VDoc | 7 |
| Action Items закрито | 12 |
Головне правило:
Demo повинно завершуватися не враженнями, а цифрами, рішеннями, записом у VDoc і конкретним планом дій.
31. Ретроспектива спринту
Після Demo або окремо після нього проводиться ретроспектива.
Ретроспектива проводиться в Zoom із записом.
Після ретроспективи:
запис зберігається у VDoc;
посилання надсилається в Scrum-групу Telegram;
покращення фіксуються як Action Items;
відповідальні та строки вносяться у звіт спринту.
Питання ретроспективи:
що в цьому спринті спрацювало добре;
що заважало роботі;
які задачі були погано описані;
де були блокери;
чому задачі не були виконані;
чи правильно оцінили складність;
чи вистачило тестування;
чи були проблеми з комунікацією;
чи всі Zoom-записи були збережені у VDoc;
чи всі посилання були скинуті в Telegram;
чи потрібні зміни в Definition of Done;
що потрібно змінити в наступному спринті.
Результатом ретроспективи має бути список конкретних дій:
що покращуємо;
хто відповідальний;
до якого строку;
як перевіримо результат.
Головне правило:
Якщо після ретроспективи не з’явилося жодної конкретної дії, ретроспектива була формальною.
32. Звітність по спринту для ISO 9001
Для ISO 9001 результати спринту повинні бути зафіксовані.
Звіт по спринту повинен містити:
номер спринту;
дати початку і завершення;
склад Scrum-команди;
Scrum Master;
Product Owner;
мету спринту;
список запланованих задач;
список виконаних задач;
список невиконаних задач;
причини невиконання;
список дефектів;
список задач, готових до релізу;
рішення Product Owner;
ризики, виявлені під час спринту;
Action Items;
посилання на Zoom-записи у VDoc;
посилання на Telegram-групу або повідомлення з підсумками;
покращення, які потрібно впровадити;
відповідальних за покращення.
Формат звітності може бути таким:
таблиця в системі управління задачами;
звіт у Wiki;
автоматичний звіт із K2 Projects;
окремий документ “Звіт спринту”;
дашборд по команді;
картка або документ у VDoc.
Головне правило:
Звітність по спринту повинна доводити не тільки факт роботи, а й контроль якості цієї роботи.
33. Приклад підсумкового звіту спринту
Спринт: № ___
Період: з ___ по ___
Scrum-команда: 7 співробітників
Scrum Master: ___
Product Owner: ___
Мета спринту: ___
Посилання на Zoom-записи у VDoc: ___
Telegram-група: ___
1. План спринту
| Показник | Значення |
| Заплановано задач | ___ |
| Функціональних задач | ___ |
| Багів | ___ |
| Задач по БД | ___ |
| Задач по API | ___ |
| Задач по документації | ___ |
| Задач високого ризику | ___ |
| Загальна оцінка роботи | ___ |
2. Виконання
| Показник | Значення |
| Виконано задач | ___ |
| Не виконано | ___ |
| Перенесено | ___ |
| Повернуто на доопрацювання | ___ |
| Готово до релізу | ___ |
| Відсоток виконання | ___% |
3. Якість
| Показник | Значення |
| Знайдено дефектів | ___ |
| Виправлено дефектів | ___ |
| Критичних дефектів | ___ |
| Дефектів після Demo | ___ |
| Задач без документації | ___ |
| Задач без перевіряючого | ___ |
4. Комунікації та записи
| Показник | Значення |
| Zoom-зустрічей проведено | ___ |
| Записів збережено у VDoc | ___ |
| Посилань скинуто в Telegram | ___ |
| Перемовин із замовником | ___ |
| Action Items створено | ___ |
| Action Items закрито | ___ |
5. Блокери
| Блокер | Задача | Відповідальний | Статус |
| ___ | ___ | ___ | ___ |
6. Action Items
| Що зробити | Хто | Коли |
| ___ | ___ | ___ |
7. Прийняті рішення
| Рішення | Хто прийняв | Дата |
| ___ | ___ | ___ |
8. Покращення на наступний спринт
| Що покращити | Відповідальний | Строк |
| ___ | ___ | ___ |
Головне правило:
Звіт спринту повинен давати керівництву і команді чесну картину: що зроблено, що не зроблено, чому не зроблено, де це зафіксовано і що потрібно змінити.
34. Метрики якості Scrum + ISO 9001
Для контролю якості потрібно регулярно аналізувати метрики.
Метрики виконання
кількість задач у спринті;
відсоток виконання спринту;
кількість перенесених задач;
кількість задач, доданих після старту спринту;
середній час виконання задачі;
кількість заблокованих задач;
середній час блокера;
залишок роботи по днях;
динаміка Sprint Burndown Chart.
Метрики якості
кількість дефектів;
кількість критичних дефектів;
кількість задач, повернутих на доопрацювання;
кількість дефектів після релізу;
кількість hotfix-релізів;
кількість задач без документації;
кількість задач без тестування;
кількість задач без перевіряючого.
Метрики комунікацій
кількість Zoom-зустрічей;
кількість записів, збережених у VDoc;
кількість посилань, надісланих у Telegram-групи;
кількість перемовин із замовниками;
кількість Action Items;
відсоток закритих Action Items;
кількість рішень, зафіксованих після зустрічей.
Метрики процесу
кількість задач без критеріїв приймання;
кількість задач з нечіткими вимогами;
кількість задач, де змінювався обсяг під час спринту;
кількість задач, які чекали рішення Product Owner;
кількість задач, які чекали перевірки консультанта;
кількість задач, які чекали code review;
кількість Action Items, закритих у строк.
Головне правило:
Метрики потрібні не для покарання, а для управління процесом і виявлення слабких місць.
35. Управління дефектами
Усі дефекти повинні фіксуватися.
Для кожного дефекту потрібно зазначити:
де знайдено;
хто знайшов;
опис проблеми;
критичність;
відповідальний за виправлення;
строк виправлення;
статус;
хто перевірив після виправлення;
чи є запис Zoom-перевірки або Demo;
чи потрібно оновити документацію.
Критичність дефектів:
критичний — блокує роботу або може пошкодити дані;
високий — сильно впливає на бізнес-сценарій;
середній — заважає роботі, але є обхідний шлях;
низький — косметична або незначна помилка.**
Головне правило:
Дефект не закритий, поки його не перевірив не той самий співробітник, який його виправляв.
36. Документація
Для K2 ERP документація є частиною якості.
Кожен співробітник повинен готувати документацію по тих частинах, які він зробив.
Документація повинна пояснювати:
що зроблено;
для кого це призначено;
як з цим працювати;
які є сценарії;
які є обмеження;
які є права доступу;
які типові помилки можуть виникати;
як перевірити результат.
Документація повинна бути написана не для розробника, а для користувача.
Головне правило:
Функціонал без зрозумілої документації не може вважатися повністю якісним для продукту K2 ERP.
37. ISO 9001 і докази виконання
Для ISO 9001 важливо не тільки виконувати роботу, а й мати докази.
Доказами можуть бути:
задача в системі управління проєктами;
коментарі по задачі;
історія зміни статусів;
посилання на коміти;
результати тестування;
скріншоти;
запис Zoom;
запис у VDoc;
посилання в Telegram-групі;
протокол Demo;
звіт спринту;
чек-лист релізу;
запис рішення Product Owner;
запис про погодження структури БД;
запис про перевірку консультантом;
Action Items після Daily Scrum;
результати ретроспективи.
Головне правило:
Якщо результат неможливо підтвердити записом, для ISO 9001 він вважається слабко контрольованим.
38. Правила дисципліни Scrum + ISO 9001 + регламент K2 ERP
Для стабільної роботи компанії потрібно зафіксувати обов’язкові правила.
1. Спринт триває 1 тиждень.
2. Scrum-команда складається з 7 співробітників, які виконують роботу в межах спринту.
3. Scrum Master є окремою роллю і не входить у ці 7 виконавців.
4. Кожна задача повинна мати опис, виконавця, перевіряючого і критерій готовності.
5. Кожного дня проводиться Daily Scrum Meeting тривалістю до 15 хвилин.
6. Усі Scrum-зустрічі проводяться в Zoom із записом.
7. Усі записи Zoom зберігаються у VDoc.
8. Посилання на записи надсилаються в Telegram-групу Scrum-команди або групу із замовником.
9. Усі перемовини із замовниками проводяться в Zoom із записом.
10. Усі робочі переписки, крім конфіденційної інформації, ведуться в Telegram-групах.
11. Приватні повідомлення не використовуються для робочих домовленостей, крім передачі конфіденційних даних.
12. Статуси задач оновлюються щоденно.
13. Блокери фіксуються одразу, а не в кінці тижня.
14. Критичні задачі не приймаються самими виконавцями.
15. Зміни в БД, API, правах доступу і бізнес-логіці проходять додаткову перевірку.
16. Scope спринту після старту не змінюється хаотично.
17. Якщо scope потрібно змінити, це погоджується і фіксується.
18. Раз на тиждень проводиться Demo та Review спринту тривалістю до 2 годин.
19. На Demo показується реальний результат у системі.
20. Якщо робота виконувалась для замовника, результат демонструється замовнику в Zoom під запис.
21. Після спринту формується звіт з цифрами, висновками, записами і діями для покращення.
22. Невиконані задачі аналізуються за причинами.
23. Дефекти фіксуються, класифікуються і перевіряються після виправлення.
24. Результати спринту використовуються для покращення наступного спринту.
25. Уся важлива інформація повинна бути зафіксована в системі, а не залишатися “на словах”.
Головне правило:
Scrum дає ритм. ISO 9001 дає контроль. Регламент K2 ERP дає доказовість. Разом вони створюють керовану систему якості.
39. Що потрібно заборонити
Для дотримання якості потрібно прямо заборонити:
задачі без опису;
задачі без виконавця;
задачі без перевіряючого;
задачі без критеріїв готовності;
закриття задачі без перевірки;
приховування блокерів;
перенесення задач без пояснення причини;
додавання задач у спринт без погодження;
хаотичну зміну Sprint Backlog;
зміну БД без погодження;
зміну API без документації;
реліз без тестування;
Demo без запису Zoom;
Zoom без збереження у VDoc;
VDoc без посилання в Telegram-групі;
усні домовленості із замовником без фіксації;
робочі домовленості в приватних повідомленнях;
демонстрацію неготового функціоналу як готового;
закриття дефекту без повторної перевірки;
формальні Daily Scrum без оновлення статусів;
формальні ретроспективи без дій для покращення;
витрачання часу на красиві презентації замість реального продукту;
перетворення Scrum Master на людину, яка просто роздає задачі;
перетворення Product Owner на комітет без єдиного рішення.
Головне правило:
Якщо робота не зафіксована, її складно захистити перед клієнтом, командою, керівництвом або аудитом ISO 9001.
40. Висновок
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-платформу, яка може стабільно автоматизувати складні бізнес-процеси та замінювати застарілі програмні рішення на ринку.