January 11, 2010 at 01:40Magic Tasks - we solve unscheduled tasks on a par with planned
Often there are tasks that are difficult to put in the plan, because it’s necessary to solve them, but there are more priority tasks for the project. Therefore, in the company I work for, I came up with and recently introduced such a thing as Magic Tasks.
Magic Tasks - these are tasks that are not included in the plan in the short term, but their solution is now necessary.
UPD : Moved to Learn to Work.
Further in more detail about all this.
Suppose you have a development team that is involved in some kind of project and tasks in the plan are always associated with this project. Suddenly, there is a problem that needs to be solved, but its solution is now basically not required, and there are a lot of errors (features) that need to be urgently urgently corrected now, so the team is uploaded N months in advance. Most likely, for this task we will hang the label "expiration date from + N months in advance."
Example: The team is engaged in a mobile project, social network, video service, a reminder, a game (you can add a list as you wish), and then the question arose of how to open an iron door with an electric lock using a mobile phone sensor. The task clearly has nothing to do with the project, but it was very much like to solve it later, so that all users could open their offices in this way by installing software on the server and doing certain operations with the electric lock so that all this is a miracle earned.
What do we see from the task?
1. It is not obvious who exactly except the mobile developer needs to be involved to solve this problem.
2. It is not known without definite research how much time will be spent on solving this problem.
3. Obviously, there are more important problems now than this task.
To help solve this issue come Magic Tasks.
Creation of an expert group to solve the problem.
1. The necessary developers (and other comrades) are selected when it is clear who should do this task.
2. The entire development team is involved.
The solution of the problem.
1. The problem is solved at a time when the developer is not busy with the main task. For example, during work breaks, when he reads the news, or writes on his blog. This will give him unloading, only more profitable for him professionally and profitable for the company in waste of time resources.
2. To solve the problem, an interval is selected, for example, a month, broken down into stages, for example, a week. This means that every week there should be some results on the task, i.e. it should move and end in a month.
3. The solution to the problem is published in the corporate Wiki, where each developer can always see which issues have already been resolved and what needs to be solved.
4. The project manager (or the one who set the task) is the operator of the task and monitors its progress, because he is primarily interested in its implementation.
The advantages of this approach compared to the usual statement in the plan:
+ Planned tasks are not shifted, but are carried out.
+ The team is strengthened by jointly solving the task.
+ The developer fights off the routine by solving a new task (or a task that may not be similar to the one he does every day), which gives him an additional professional growth point.
+ The task that will be needed very much later will be solved now.
+ The task can come from any resource unit of the project, and this gives additional motivation to people who want to not only execute, but also create the best tools for themselves (read the conditions).
+ The team much more clearly represents the specifics of the work of each of the team members, depending on the specific Magic Task.
Cons:
- Ineffective waste of professional resources in those areas in which they do not specialize.
- The task can not always be solved in advance of the predicted time.
I would be grateful for any criticism, comments, additions.
@degravia
Magic Tasks - these are tasks that are not included in the plan in the short term, but their solution is now necessary.
UPD : Moved to Learn to Work.
Further in more detail about all this.
Example.
Suppose you have a development team that is involved in some kind of project and tasks in the plan are always associated with this project. Suddenly, there is a problem that needs to be solved, but its solution is now basically not required, and there are a lot of errors (features) that need to be urgently urgently corrected now, so the team is uploaded N months in advance. Most likely, for this task we will hang the label "expiration date from + N months in advance."
Example: The team is engaged in a mobile project, social network, video service, a reminder, a game (you can add a list as you wish), and then the question arose of how to open an iron door with an electric lock using a mobile phone sensor. The task clearly has nothing to do with the project, but it was very much like to solve it later, so that all users could open their offices in this way by installing software on the server and doing certain operations with the electric lock so that all this is a miracle earned.
What do we see from the task?
1. It is not obvious who exactly except the mobile developer needs to be involved to solve this problem.
2. It is not known without definite research how much time will be spent on solving this problem.
3. Obviously, there are more important problems now than this task.
To help solve this issue come Magic Tasks.
Basic principles.
Creation of an expert group to solve the problem.
1. The necessary developers (and other comrades) are selected when it is clear who should do this task.
2. The entire development team is involved.
The solution of the problem.
1. The problem is solved at a time when the developer is not busy with the main task. For example, during work breaks, when he reads the news, or writes on his blog. This will give him unloading, only more profitable for him professionally and profitable for the company in waste of time resources.
2. To solve the problem, an interval is selected, for example, a month, broken down into stages, for example, a week. This means that every week there should be some results on the task, i.e. it should move and end in a month.
3. The solution to the problem is published in the corporate Wiki, where each developer can always see which issues have already been resolved and what needs to be solved.
4. The project manager (or the one who set the task) is the operator of the task and monitors its progress, because he is primarily interested in its implementation.
The advantages of this approach compared to the usual statement in the plan:
+ Planned tasks are not shifted, but are carried out.
+ The team is strengthened by jointly solving the task.
+ The developer fights off the routine by solving a new task (or a task that may not be similar to the one he does every day), which gives him an additional professional growth point.
+ The task that will be needed very much later will be solved now.
+ The task can come from any resource unit of the project, and this gives additional motivation to people who want to not only execute, but also create the best tools for themselves (read the conditions).
+ The team much more clearly represents the specifics of the work of each of the team members, depending on the specific Magic Task.
Cons:
- Ineffective waste of professional resources in those areas in which they do not specialize.
- The task can not always be solved in advance of the predicted time.
I would be grateful for any criticism, comments, additions.
@degravia