This is also called “tickets”. Tickets for tasks that happen repeatedly can have a workflow assigned to them, which can be as simple as a linear sequence of steps, but also more complex, and you can have a software that tracks them. Like, you click a button on your smartphone, and it will show you a list of tickets currently assigned to you, maybe also ordered by priority. When you move the ticket to someone else, it disappears from your list and immediately appears on their list. So the tasks are always remembered and always have a person assigned, until they get closed.
Tickets are usually used for predictable, repetitive tasks with known workflow. But nothing prevents you from creating a generic “workflow” containing only one step “solve the problem”, and using it for everything else.
When a new ticket is created, unless the owner is specified explicitly, the system should automatically assign it to someone. Then you just need the person “on call” who registers everything that happens, and creates a new ticket for that.
There are commercial solutions, such as the infamous Atlassian Jira (most companies use it, most users hate it with a passion), or free solutions… I don’t know what is currently the state of art. There is a list on Wikipedia.
I think every organization should use something like this; many individuals would probably also benefit from a personal ticket system. But there is an overhead with setting up the system (installing the software, setting up the workflows). Not sure of there is an online system where one could just register and start using it… if there is, someone please give me a link; if there is not, sounds like a business opportunity.
If you understand how the system is supposed to work, you could implement a poor man’s version using a spreadsheet. Each row is a ticket. Columns: ticket id, who is it assigned to, workflow type, workflow phase, description. Maybe create a wiki page for each ticket, and have it linked from the spreadsheet.
We use Asana for this. (It’s broadly great, and I don’t understand how Jira isn’t getting its lunch completely eaten. And I’m not just saying that because of my funder.)
I agree with a lot of this, though I think the mental attitude here is still extremely useful. For example, you may be dealing with something outside of your usual ticket system, or a ball may be smaller than something that would justify an Asana ticket.
My model of Atlassian business model goes like this: Take a popular open-source product, and make a crappy version of it with half the functionality and inconsistent UI, but make it possible to create plugins and sell them at your marketplace (where you take a cut). Then sell it for lots of money, and when anyone asks whether it has some functionality X, say “there is a marketplace with many plugins, I am sure there are many high-quality implementations of X”. Write in the contract that you only provide support for the basic installation without any plugins; if plugins are installed, proper functioning of the system is no longer your responsibility, and the customer should call the author of the plugin instead!
This seems to somehow work in practice. On one hand, you can check the checkbox “we provide support”, and also check the checkbox “our product supports X” when someone makes a plugin for X (so you soon provide more functionality than the original open-source project you copied… so when someone later proposes to replace your product with open-source, some manager will ask “but does the open-source solution provide integration with SharePoint?” or something like that), but when the customer installs the plugin for X, the support is no longer your problem. In theory, your product can be configured to do anything, but in practice, the customer is supposed to configure it in their own time, which most customers will refuse to do (somehow, spending $100,000 to buy your software is okay, but spending $10,000 to pay their employee his salary until he figures out how to configure it properly is not), so most customers will use the default settings, or the default settings plus a plugin. (And the integration with SharePoint does not work anyway, but no one is complaining about that, because the people who actually use the software do not care about SharePoint integration.)
This is too cynical, but I haven’t heard a better explanation that would fit the known data.
This is also called “tickets”. Tickets for tasks that happen repeatedly can have a workflow assigned to them, which can be as simple as a linear sequence of steps, but also more complex, and you can have a software that tracks them. Like, you click a button on your smartphone, and it will show you a list of tickets currently assigned to you, maybe also ordered by priority. When you move the ticket to someone else, it disappears from your list and immediately appears on their list. So the tasks are always remembered and always have a person assigned, until they get closed.
Tickets are usually used for predictable, repetitive tasks with known workflow. But nothing prevents you from creating a generic “workflow” containing only one step “solve the problem”, and using it for everything else.
When a new ticket is created, unless the owner is specified explicitly, the system should automatically assign it to someone. Then you just need the person “on call” who registers everything that happens, and creates a new ticket for that.
There are commercial solutions, such as the infamous Atlassian Jira (most companies use it, most users hate it with a passion), or free solutions… I don’t know what is currently the state of art. There is a list on Wikipedia.
I think every organization should use something like this; many individuals would probably also benefit from a personal ticket system. But there is an overhead with setting up the system (installing the software, setting up the workflows). Not sure of there is an online system where one could just register and start using it… if there is, someone please give me a link; if there is not, sounds like a business opportunity.
If you understand how the system is supposed to work, you could implement a poor man’s version using a spreadsheet. Each row is a ticket. Columns: ticket id, who is it assigned to, workflow type, workflow phase, description. Maybe create a wiki page for each ticket, and have it linked from the spreadsheet.
We use Asana for this. (It’s broadly great, and I don’t understand how Jira isn’t getting its lunch completely eaten. And I’m not just saying that because of my funder.)
I agree with a lot of this, though I think the mental attitude here is still extremely useful. For example, you may be dealing with something outside of your usual ticket system, or a ball may be smaller than something that would justify an Asana ticket.
My model of Atlassian business model goes like this: Take a popular open-source product, and make a crappy version of it with half the functionality and inconsistent UI, but make it possible to create plugins and sell them at your marketplace (where you take a cut). Then sell it for lots of money, and when anyone asks whether it has some functionality X, say “there is a marketplace with many plugins, I am sure there are many high-quality implementations of X”. Write in the contract that you only provide support for the basic installation without any plugins; if plugins are installed, proper functioning of the system is no longer your responsibility, and the customer should call the author of the plugin instead!
This seems to somehow work in practice. On one hand, you can check the checkbox “we provide support”, and also check the checkbox “our product supports X” when someone makes a plugin for X (so you soon provide more functionality than the original open-source project you copied… so when someone later proposes to replace your product with open-source, some manager will ask “but does the open-source solution provide integration with SharePoint?” or something like that), but when the customer installs the plugin for X, the support is no longer your problem. In theory, your product can be configured to do anything, but in practice, the customer is supposed to configure it in their own time, which most customers will refuse to do (somehow, spending $100,000 to buy your software is okay, but spending $10,000 to pay their employee his salary until he figures out how to configure it properly is not), so most customers will use the default settings, or the default settings plus a plugin. (And the integration with SharePoint does not work anyway, but no one is complaining about that, because the people who actually use the software do not care about SharePoint integration.)
This is too cynical, but I haven’t heard a better explanation that would fit the known data.
Sounds like a plugin-centric version of embrace and extend.