Приймання й передача в операційну роботу

Приймання (acceptance) — перевірка, що закриває виконання: справжній продукт перевіряють за критеріями, погодженими заздалегідь, ті, хто з ним житиме, або разом із ними. Це не те саме, що тестування, яке роблять розробники, щоб знайти баги. Важливі обидва; але «готово» каже лише приймання.

У Klasna критерії погодили в листопаді: кожна тема іспиту має розібраний приклад і десять задач з оцінюванням; дев’ять репетиторів пройшли демоурок, який оцінила Vira; батьки з телефона доходять від сторінки через тест до заброньованого уроку. Те, що Danylo десять разів пройшов цей шлях на ноутбуці, — корисне тестування, але воно нічого не перевіряє за домовленістю: він не батьки, а ноутбук — не телефон.

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

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

У Klasna за три дні до відкриття діагностичний тест втрачає прогрес, коли зникає зв’язок, а нормальне виправлення займе два тижні. Програма, репетитори й шлях запису проходять. Тож команда приймає їх, записує проблему тесту з обхідним шляхом, власником і строком виправлення та кладе перед Leo. Він як спонсор вирішує відкриватися з нею.

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

Відома проблема (known problem) — збій, про який команда знає і з яким свідомо відкривається. Її запис пишуть для тих, хто з нею житиме, тож він потребує чотирьох полів: що це, одним рядком; що робимо тим часом — обхідний шлях; хто відповідає за виправлення; і до коли.

У Klasna: прогрес тесту втрачається, коли зникає зв’язок. Тим часом підтримка повторно надсилає посилання, а сторінка каже, що тест триває близько 20 хвилин, щоб родини могли це спланувати. Виправлення — на Danylo, до 15 лютого.

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

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

Проєкт закінчується; те, що він збудував, працює далі. З дня відкриття ця робота — операційна, і кожна її частина потребує щоденного власника, який чітко сказав «так».

У Klasna після 1 лютого викладання фізики — операційна робота. Vira відповідає за програму і якість репетиторів. Roman — за розклад репетиторів і виплати двічі на місяць. Продуктова команда Danylo — за тест, сторінку й запис, як за звичайну продуктову роботу в своєму беклозі, а не проєкт із дедлайном. Підтримка відповідає на питання родин.

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

Перевірка для кожної частини проста: якщо щось зламається у вівторок, чи є одне ім’я, якому всі зателефонують, і чи погодилася ця людина?

Перші дні після передачі її перевіряють. Люди досі найкраще знають ліда проєкту, тож проблеми й далі приходять на стару адресу. Те, як лід відповідає, вирішує, чи операційна команда справді перебере роботу.

Правило: передай проблему щоденному власникові й підтверди тому, хто її підняв. У Klasna, коли Leo у вівторок пише лідові проєкту про зламаний запис однієї родини, лід пересилає це продуктовій команді Danylo, яка тепер відповідає за запис, і каже Leo, що зроблено.

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

Переслати — дрібна дія, але саме так передача стає справжньою.

Передачу в операційну роботу (handover to operations) записують на одну сторінку, щоб у понеділок нікому не довелося питати, хто за що відповідає. У ній:

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

У Klasna це програма, репетитори, тест, сторінка й запис із їхніми власниками (Vira, Roman, команда Danylo, підтримка), проблема з прогресом тесту на Danylo до 15 лютого, результати приймання з батьками, що втратили тест, і дві роботи, які лишаються проєкту: перевірка вигод і підсумковий звіт у березні.

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

Передача — це передача відповідальності, а відповідальність не передаси, просто надіславши документ. Вона завершена, коли кожен новий власник прочитав нотатку й підтвердив свою частину, а не коли лід проєкту натиснув «надіслати».

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

У Klasna лід надсилає нотатку в п’ятницю, 29 січня, і просить Vira, Roman, Danylo й підтримку підтвердити до ранку понеділка. Тому, хто не відповів, телефонують — так само, як телефонують спонсорові, що мовчить у відповідь на оцінку зміни: мовчання — не «так».

Підтвердження теж потрапляють у записи. Коли в березні хтось спитає, хто погодився відповідати за тест після запуску, відповіддю буде «так» із датою, а не спогад.

Інструкція дій (runbook) — короткий список кроків, записаний заздалегідь на випадок відомого збою, щоб нікому не доводилося вирішувати під стресом. Для живих уроків в Україні відключення світла й повітряні тривоги — звичайні вхідні дані планування, а не винятки, тож фізика її отримує.

У Klasna на випадок тривоги: спершу безпека, урок зупиняється, репетитор пише в чат уроку. На випадок відключення: репетитор пише в чат, що урок на паузі, і пробує резервний зв’язок до 10 хвилин. Якщо урок не продовжити, репетитор позначає його в розкладі як перерваний, підтримка домовляється про новий слот протягом 7 днів, безкоштовно для родини, а Roman платить репетиторові, коли урок проведено.

Порядок кроків має причини. Родина дізнається першою, тож ніхто не чекає в тиші. Запис дає підтримці діяти; оплата — остання, за проведений урок. І в інструкції дій є власник, Roman, який тримає її актуальною.

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