Acceptance and handover to operations

Acceptance is the check that closes delivery: the real thing, checked against criteria agreed in advance, by or with the people who will live with it. It differs from testing, which the builders do to find bugs. Both matter; only acceptance says "done".

At Klasna the criteria were agreed in November: every exam topic has a worked example and ten graded practice tasks; nine tutors passed a demo lesson Vira scored; a parent on a phone gets from the page through the test to a booked lesson. Danylo clicking through the flow ten times on his laptop is useful testing, but it checks nothing as agreed: he isn't a parent, and a laptop isn't a phone.

The evidence for the last criterion is three waiting-list parents trying it on their own phones on the live site, with each outcome recorded: two booked, and the third lost the test halfway when the power went out. A speed score or the contractor's report that booking works are claims about parts, not checks of the criterion.

A failed acceptance check close to a fixed date seems to leave two choices: move the date or quietly open anyway. There is a third, honest one: accept what passes and record the failure as a known problem, then let the sponsor decide in writing to open with it.

At Klasna, three days before opening, the diagnostic test loses progress when the connection drops, and a proper fix takes two weeks. The program, the tutors and the booking flow pass. So the team accepts those, writes the test problem down with a workaround, an owner and a fix date, and puts it in front of Leo. He decides, as sponsor, to open with it.

What changes is not the product but the status of the compromise. Without the record and the sponsor's written decision, opening with a known flaw is a quiet compromise that surfaces later as a surprise or a blame. With them, it is a decision anyone can find, with someone responsible for closing it. Saying nothing is never one of the honest options.

A known problem is a failure the team knows about and opens with on purpose. Its entry is written for the people who will live with it, so it needs four fields: what it is, in one line; what happens meanwhile, the workaround; who owns the fix; and by when.

At Klasna: test progress is lost when the connection drops. Meanwhile support resends the link and the page says the test takes about 20 minutes, so families can plan for it. Danylo owns the fix, due 15 February.

Each field does a job. The one-line description lets support recognize the problem when a family writes in. The workaround means nobody improvises. The owner and the date turn "we'll fix it" into something that can be checked and chased.

Two things don't belong. Who caused the bug helps nobody fix or work around it, and it turns a working note into blame. A promise that it will never happen again can't be checked; an owner and a date can.

A project ends; the thing it built keeps running. From the opening day that running is operational work, and every part of it needs an everyday owner who has explicitly said yes.

At Klasna, after 1 February teaching physics is operations. Vira owns the program and tutor quality. Roman owns tutor schedules and the payouts twice a month. Danylo's product team owns the test, the page and booking, as normal product work in their backlog rather than a project with a deadline. Support answers families' questions.

The other half of the handover is just as important: the project team stops owning it. Until March the project lead keeps only what closes the project, the benefits check and the closing report, not daily fixes. If the project quietly keeps doing operational work, the new owners never really take over, and the project never really ends.

The test for each part is simple: if something breaks on Tuesday, is there one name everyone would call, and has that person agreed?

The first days after a handover test it. People still know the project lead best, so problems keep arriving at the old address. How the lead answers decides whether operations really take over.

The rule: route the problem to its everyday owner and confirm to the person who raised it. At Klasna, when Leo messages the project lead on Tuesday about a family's broken booking, the lead forwards it to Danylo's product team, who own booking now, and tells Leo it's done.

The tempting alternative is to fix it yourself, quickly, because you know the system best. Each such fix teaches everyone that the project still owns physics: the next problem comes back to you, and the new owners never build the habit. The opposite mistake, "not my problem any more", is right about ownership and wrong about the family, who is left waiting. And reopening the project until every bug is gone confuses normal product work after launch with unfinished delivery.

Routing is a small act, but it's how a handover becomes real.

A handover to operations is written down, on one page, so nobody on Monday has to ask who owns what. It holds:

• what was handed over and where its documents live;
• who owns each part from the opening day, as confirmed by them;
• known problems, each with a workaround, an owner and a date;
• the acceptance results, including the checks that failed, so nobody argues later about what "done" meant;
• contacts, and what the project still does until it closes.

At Klasna that means the program, tutors, test, page and booking with their owners (Vira, Roman, Danylo's team, support), the test-progress problem owned by Danylo until 15 February, the acceptance results with the parent who lost the test, and the project's two remaining jobs: the benefits check and the closing report in March.

Two things stay out. The full chat history hides what matters under noise. A promise that the project team will fix any problem until March undoes the handover: operations never take physics over if the project keeps catching everything.

A handover is a transfer of responsibility, and responsibility can't be transferred by sending a document. It is complete when each new owner has read the note and confirmed their part, not when the project lead presses send.

The confirmation catches the gaps that matter most. An owner may read the note and say: "I didn't know payouts for interrupted lessons were mine", or "support doesn't have the link-resend instructions yet". Each such answer, on Friday, is a problem fixed before the opening rather than discovered on Tuesday by a family.

At Klasna the lead sends the note on Friday 29 January and asks Vira, Roman, Danylo and support to confirm by Monday morning. Anyone who hasn't answered gets a call, the same way a sponsor's silence on a change note gets a call: silence isn't a yes.

The confirmations also go into the record. When someone asks in March who agreed to own the test after launch, the answer is a dated yes, not a memory.

A runbook is a short list of steps written in advance for a known disruption, so nobody has to decide under stress. For live lessons in Ukraine, power outages and air-raid alerts are ordinary planning inputs, not exceptions, so physics gets one.

At Klasna, for an alert: safety first, the lesson stops, and the tutor writes in the lesson chat. For an outage: the tutor writes in the chat that the lesson is paused, then tries a backup connection for up to 10 minutes. If the lesson can't go on, the tutor marks it as interrupted in the schedule, support agrees a new slot within 7 days, free for the family, and Roman pays the tutor once the lesson is delivered.

The order has reasons. The family hears first, so nobody waits in silence. The record lets support act; payment comes last, per delivered lesson. And the runbook has an owner, Roman, who keeps it current.

How it fits together: accept against agreed criteria, record what's open with owners, hand every part to a confirmed owner, and plan for disruptions. The next lesson asks, in March, whether the launch actually worked.