Is the scheduling of oncall work something worth making better?(oncallscheduler.com) |
Is the scheduling of oncall work something worth making better?(oncallscheduler.com) |
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?
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?
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).
> 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.
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.