Unfortunately, some people believe that there is the perfect time management software that solves all the problems with scheduling. This problem cannot be overcome only with the help of technology, habit plays a role in it, not counting the unpredictable nature of software development (for example, do you know how many errors can be detected in your software after its release to the market?).
The PRINCE2 textbook states that an employee is able to work productively only 3.5 days a week (out of a total of 5 days). The rest of the time is occupied by tasks such as meetings, answering calls, attending farewell parties of colleagues and so on. The company's management believes that the staff is able to work productively 4.5 days a week; it's an absolute fantasy; wanting something to be true doesn't make it real. Parkinson's law is probably being misapplied.
Parkinson's Law states that people use all the time given to them to complete a task (for example, folding 1,000 magazines into a pack can take 2 hours, but if you give a person 4 hours to complete this, he will spend 4 hours). This principle is often misunderstood in the sense that you can get more from people if you put pressure on them, force them to meet incredible deadlines.
This approach can give short-term gains, but also leads to discouragement of staff and increased turnover.
There are more reliable ways to improve productivity (for example, hiring a temporary system administrator instead of using programmers to perform technical support work). Parkinson's law is only good for you – it can't be transferred to other people.
The programmer's time is well planned using the method of evidence-based planning of Jole Spolsky, which consists in an unexpected withdrawal from the task, which gives a strong effect. In one company, this practice was generally accepted (i.e. programmers were removed from the task to perform another task). The result was provided for by a schedule that had inaccurate deadlines for delivery, but still the schedule fulfilled its purpose, since tasks were tracked.
In order to eliminate this problem, a system based on the critical path theory was invented, called the 'master/auxiliary programmer'. Let's look at an example of how it works; you have two programmers in the project. One of them is called the main one and has 20 hours of dedicated work, the other is called auxiliary, it has 10 hours of work. If there are 5 hours of new work, they are transferred to the auxiliary programmer. The auxiliary will now be 5 hours behind the main one, but still it can finish its work earlier than the main one. A project cannot be considered complete until the master has finished all his work, so you can intentionally give the main programmer more work than his friend (for example, in a ratio of 65:35).
There is a company that successfully manages time with simple solutions for its private conditions. Here, a central time controller is appointed: if you want to force a programmer to work on something, then he has to be booked through a time controller. This is done by submitting a request for pecypca allocation by e-mail. A simple summary of the work assignment looks like this:
- Client Name: Blue Widgets Inc.
- Job Name: Bug Fix, ID: 59
- Preferred Person: Michael Smith
- When it will be ready: 11:00 a.m. Tuesday (July 26th)
- Job Completion Date: 5:00 a.m. Tuesday (July 26th)
- Estimated Hours: 1-2 hours
- Priority: Normal
The time controller uses this information to enter a new entry into the programmer's calendar in Microsoft Outlook. When a programmer comes to work, he will see that he has several hours to eliminate errors. This system is not perfect, but it is much better than the "run and eliminate fires" approach used elsewhere.
It should be noted that the 'job name' refers to the error ID, a problem resolution system that is absolutely necessary for any software development firm. The project manager should set aside time to resolve errors during quiet periods throughout the week and at suitable checkpoints (e.g., between milestones).
Initially, bugs should be reported directly to the project manager, not to the programmers. Based on this, the project manager prioritizes and redistributes errors or the addition of minor characteristics, they should be transmitted to the programmers in separate portions, and not the whole bunch at once.
Another idea proposed by this company is to create a position called 'service programmer'. The task of this programmer is to perform fixes and changes in old projects.
This allows programmers to start working on new projects without worrying that they can be pulled out at any time to fix bugs in a project they worked on last year.
The best way to eliminate the error is the one who originally programmed it, but after a year its benefits come to naught. The maintenance programmer will have to work hard to understand the business rules of a complex software system that they did not deal with, they are more suitable for easier maintenance of websites.
You'll realize that your project schedule works well if programmers come to you with questions every few days, they know what to do next, and they don't lose momentum. Another sign is that after the end of the project, there are very few registered problems related to the missing functionality (i.e. programmers do not forget to program elements).
Often, poor time management is not the result of poor scheduling, but is due to a problem in project management. The project manager is responsible for setting priorities, not the programmers or the ongoing operations manager. There are real problems here when senior management assigns priorities without understanding the indirect impact on other projects. People worry too much about deadlines, while they should worry more about the loss of time caused by inadequate planning methods.
Notes
Realistically assess the availability of resources. It is necessary to take into account weekends and holidays and the time spent by people on activities not related to projects. The average working week is only 4 days after taking into account weekends and holidays, training, illness, etc. Of these 4 days, at least another half a day is spent on other duties even by dedicated staff - for example, quality control of other projects, line management and meetings.
No comments:
Post a Comment