Is the scheduling of oncall work something worth making better? | Hacker News Reader

Is the scheduling of oncall work something worth making better?

oncallscheduler.com

3 pointsTimeWeSp5 comments

All of us who have worked oncall for years, know how stressful and difficult it can be. Among all the pain though, I've always felt that the scheduling of who-works-when is something which should be solvable in a great way. I've tried to build something which solves oncall scheduling. This post is a shameless plug for that thing. But besides trying to get someone to click on the link, I would also love to get some feedback and hear some input from all of you who work oncall. Is the scheduling painful enough to be worth my time to solve? What I've tried to do with this tool is: Make the scheduling FAIR. There's math and an algorithm deciding the schedule. All scheduling actions are available for all to see in a log. Make the people who get scheduled have great CONTROL over when they work or (more importantly) _don't_ work. Maintain a PREDICTABLE and STABLE schedule at least several months into the future, which doesn't get all scrambled if someone leaves the team and their shifts become holes in the schedule. Make the scheduling FULLY AUTOMATED so nobody needs to think about it more than at most once/quarter.

What do you think? Is this a problem worth trying to solve for real? If you look into the tool, do you think it looks like a good solution, or does it miss the mark somehow?

To the author: what is the algorithmic approach to determine a schedule?

Once you add a couple of constraints or complications (e.g. can't be on-call two nights in a row, or on-call weekends count 1.5x because they are more "painful"), it quickly becomes a fairly general constraint satisfaction problem. This is a field with deep mathematics involved and decades of academic literature. As far as I know, reaching the state-of-the-art is extremely hard, and it is usually advised to use an off-the-shelf solver (a SAT [1] solver, or a constraint-programming solver like Gecode [2], or something more specific like OptaPlanner/TimeFold [3]).

If in addition you introduce happiness and/or fairness maximization, then you may want optimality guarantees, and then you need a full-blown MIP solver (which means slower solves, and the faster MIP solvers are expensive).

That said, the model used here seems to have a special structure, so a custom (greedy?) algorithm may make sense. Any pointer for more details on the model?

[1] http://www.satcompetition.org

[2] https://www.gecode.org

[3] https://timefold.ai/

Oh, you're going way farther in optimizing the schedule, than I know how to collect data to do. If I could collect detailed info about how each oncall rotation members feels about every single shift, I could use a model like what you describe. I remember these models from school... But that was a long time ago. I'd have a lot of reading to do.

What I built now, is pretty simple, but I think it solves the problem pretty elegantly: * Each user has a set of credits. You get credits when you get a shift assigned. You pay credits to other people who are assigned shifts. * You can self-assign shifts (which makes you earn credits). * You can bid credits to avoid getting scheduled for certain dates/holidays(e.g. Memorial Day)/importantEvents(e.g. Super Bowl Sunday). * Shifts which nobody has self-assigned are auto-allocated up to a given time horizon in the future. The auto-allocation of the next shift, assigns it to the person with the lowest value of "currentCredits + bidsToAvoidThisShift * rotationMemberCount / 2". - The exact algorithm isn't that important. But what it does is: it gives a shift to the person with the least credits (and they'll then get a bunch of credits), but it avoids giving shifts to people who have bid to avoid that specific shift.

The real value is that there is an algorithm doing the assigning. That makes this feel FAIR to all involved. If you didn't bid to avoid working on Christmas, don't complain about working then. But you'll also get more credits to work on Christmas, because you get everything that others bid to avoid working on Christmas (which means you will work fewer shifts in total over the year).

I see, thanks. So it's more like a bidding system. That is also interesting, but from a game theory perspective then.

> The real value is that there is an algorithm doing the assigning. That makes this feel FAIR to all involved.

You're right, that is very important. I think convincing people the schedule is fair is the hardest part, and indeed having a decision process everyone understands makes it easier.

+1 to that. You're right it's more of a bidding system, where game theory is needed to figure out if it'll be a balanced "game".

There are several aspects to it that aim to make it feel fair. First there's the credit system, and people who take less desirable shifts getting more credits, so they end up working fewer shifts in total. But there are also limitations on what the scheduling admin can do. E.g. they can't assign credits to themselves, or enter "block periods" (= a calendar time when someone is blocked from being assigned any shifts, e.g. because they're on parental leave or military leave, or something like that). There's also a "credit accounting log", which shows all the transactions in the system, and how those transactions changed the credit balances of all the rotation members. I hope (and think) that the kind of geeky game-prone people who work tech oncall jobs might appreciate the game-like nature of this system.

Reply on news.ycombinator.com