Magic Tasks - we solve unplanned tasks on a par with planned ones
Often there are tasks that are difficult to put in a plan, because Like them, they need to be solved, but there are more priority tasks for the project. Therefore, in the company of which I work, I have invented and introduced such a thing as Magic Tasks recently.
Magic Tasks - these are tasks that are not included in the plan in the short term, but their solution is now needed.
UPD : Transferred to Learn to Work.
')
Further more about all this.
Suppose you have a development team that deals with a project and the tasks in the plan are always associated with this project. Suddenly, there is a task that needs to be solved, but its solution now, in principle, is not required, and there are a lot of errors (features) that need to be urgently and urgently corrected now, so the team is loaded for N months in advance. Most likely on such a task we will hang the label "shelf life from + N months ahead."
Example: A team is engaged in a mobile project, social network, video service, reminder, game (you can add to the list as you wish), and then the question arose how to open the iron door with an electric lock using a mobile phone sensor. The task obviously has nothing to do with the project, but I would like to solve it very much so that later, it would be possible to give all users the opportunity to open their offices in this way, installing software on the server and doing certain operations with an electric lock so that all this is a miracle earned.
What do we see from the task?
1. It’s not obvious who, apart from the mobile developer, needs to be involved in this task
2. It is not known without a specific study how long it will take to solve this problem.
3. Obviously, there are more important problems now than this task.
Magic Tasks come to the rescue of this issue.
Creating 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 participating.
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, in the breaks between work, when he reads news, or writes to his blog. This will give him unloading, only more profitable for him professionally and profitable for the company in the waste of time resources.
2. To solve the problem, an interval is chosen, for example, a month, with a breakdown 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 be completed in a month.
3. The solution of the problem is published in the corporate Wiki, where each developer will always be able to see which issues have already been solved, and what needs to be solved.
4. The project manager (or the one who set the task) is the task operator and monitors its progress, because He is interested primarily in its implementation.
The advantages of this approach compared with the usual formulation of the plan:
+ Scheduled tasks are not shifted, but executed.
+ The team is strengthened by the joint solution of 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 is much clearer about the specifics of the work of each of the team members, depending on the specific Magic Task.
Minuses:
- Inefficient waste of professional resources in those areas in which they do not specialize.
- The task can not always be solved in the predicted period.
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 needed.
UPD : Transferred to Learn to Work.
')
Further more about all this.
Example.
Suppose you have a development team that deals with a project and the tasks in the plan are always associated with this project. Suddenly, there is a task that needs to be solved, but its solution now, in principle, is not required, and there are a lot of errors (features) that need to be urgently and urgently corrected now, so the team is loaded for N months in advance. Most likely on such a task we will hang the label "shelf life from + N months ahead."
Example: A team is engaged in a mobile project, social network, video service, reminder, game (you can add to the list as you wish), and then the question arose how to open the iron door with an electric lock using a mobile phone sensor. The task obviously has nothing to do with the project, but I would like to solve it very much so that later, it would be possible to give all users the opportunity to open their offices in this way, installing software on the server and doing certain operations with an electric lock so that all this is a miracle earned.
What do we see from the task?
1. It’s not obvious who, apart from the mobile developer, needs to be involved in this task
2. It is not known without a specific study how long it will take to solve this problem.
3. Obviously, there are more important problems now than this task.
Magic Tasks come to the rescue of this issue.
Basic principles.
Creating 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 participating.
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, in the breaks between work, when he reads news, or writes to his blog. This will give him unloading, only more profitable for him professionally and profitable for the company in the waste of time resources.
2. To solve the problem, an interval is chosen, for example, a month, with a breakdown 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 be completed in a month.
3. The solution of the problem is published in the corporate Wiki, where each developer will always be able to see which issues have already been solved, and what needs to be solved.
4. The project manager (or the one who set the task) is the task operator and monitors its progress, because He is interested primarily in its implementation.
The advantages of this approach compared with the usual formulation of the plan:
+ Scheduled tasks are not shifted, but executed.
+ The team is strengthened by the joint solution of 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 is much clearer about the specifics of the work of each of the team members, depending on the specific Magic Task.
Minuses:
- Inefficient waste of professional resources in those areas in which they do not specialize.
- The task can not always be solved in the predicted period.
I would be grateful for any criticism, comments, additions.
@degravia
Source: https://habr.com/ru/post/80432/
All Articles