Mit HabitRPG soll das abarbeiten von Aufgaben und das Ändern von Gewohnheiten wie ein Spiel funktionieren. Der Spaß steht bei der sog. Gamification aber nicht mal an erster Stelle. Sondern es sind die winzigen Belohnungen und die schnell erreichbaren Ziele in Form nächster Level, die dabei helfen sollen, am Ball zu bleiben.
When it comes to usefulness of a Key Performance Indicators (KPI), three things are important: the influence a team has on that indicator, the effort that is necessary for gathering it and the meaning of the indicator.
One famous KPI within IT is MTBF, the „Mean Time Between Failure“. And while there is a certain link between the performance of the team and the MTBF, there is still some probability involved that out of the control of the responsible team.
One Indicator that is more in control of the team is the „Mean time to repair“, MTTR. But how useful is this KPI?
You can use email like SMS and place the complete content into the subject line. To not confuse the recipient, more and more attach EOM, short for „End of Message“ at the End of the subject. This is generally useful, but it has also a few disadvantages, you should be aware.
One very easy enhancement of your subject, is to add a recognisable project name to your subject. I prefer to put it in square brackets at the beginning of the subject line.
Both, recipient as well as sender, benefit from this small addition to the subject. For the sender especially if he receives the answer to this. Having a single word at the beginning of the subject sets the right context. And you have still enough space for putting a reasonable subject line.
There is a couple of principles in IT how to work on things that are piling up. One of them is FIFO, first in – first out, which means that you work on this element first, that also arrived first. This is the classical waiting queue. LIFO, last in – first out, is the exact opposite, i.e. you work first on the element that has arrived last. This is the classical stack approach.
Both approaches have advantages and disadvantages, that make them more or less suitable for certain use cases. And a very well discussed question is, which of them is the best for working on the items in your inbox. My opinion: None of them!
Complaining about too many emails is currently en-vogue and companies are making it into the news with their plans to reduce the mail flood for their employees (e.g. VW) or abolishing it completely. But a closer look to their measures shows, that they are just working on the symptoms instead of attacking the root cause.
The „One-Touch-Rule“ is one of those tips that pop up frequently on blogs and web sites dealing with productivity improvement. The rule basically says, „Open an incoming mail only once and try to deal with it immediately. The idea behind is obvious: Every time you open an eMail, you have to invest time to understand it. This investment is mostly lost, if you close the mail and file it for later.
There is a noteworthy infografic on ridiculouslyefficient.com dealing with five dangerous myths of productivity: http://ridiculouslyefficient.com/the-5-most-dangerous-creative-productivity-myths-busted-infographic/
- Structure kills productivity (see also my article here).
- Saying „Yes“ is best.
- Adding resources increases output.
- „Busy“ is the same as „productive“.
- eMail is the best way to collaborate.
The WAL principle (Write Ahead Log) originates from databases and says that each and every change has to be written first into a log file and then into the database itself. This ensures that, in case of problems, changes are reproduceable.
This principle can also be used outside the database area. It is not only improving the traceability in case of problems, but also ensures a generally better solution. But also the drawbacks are copied from the databases: This solution costs (some) time.