From a business standpoint, schedules are vital; businesses must coordinate their activities, and the schedule is the major junction of alignment. So the use of a schedule is seen as a binding agreement, the Holy Grail of the endeavor. So it is set in stone, early in the process, and rarely negotiated.
From a development standpoint, schedules are vital, too. But they are fluid - things change as design uncovers hidden assumptions, and new requirements are uncovered. As new work is added, the sane assumption is that the schedule will expand. But because of the business importance of the schedule, it cannot expand. So in the grand tradition of "Good, fast, cheap; pick any 2", the time dimension is fixed, and the only variables are cost and quality.
Now, compunding this is the problem that attempting to maintain quality by spending more money doesn't work. If the bosses intend to give bonuses to the existing team to reward them for overtime (a rare and noble group of bosses, indeed), it will work to a certain extent, until the team hits the wall from overwork. If the plan is to increase the team, they run into Brook's Law - adding manpower to a late project makes it later. The effort of bringing the new people up to speed, and keeping the larger team in communication will swamp any benefits of added manpower.
So it appears that the only likely outcome is for quality to go down.
Now that I've painted a doom and gloom scenario, I'll give some suggestions on how to better survive when you're working in a shop where schedules are set in stone.
- Learn how to estimate your work accurately. If you don't have a good feel for how long it will take you to develop a piece of software, you can make accurate estimates
- Learn your company's overhead load. Some companies have a process that's very streamlined - developers are allowed to spend most of their time developing. Others have lots of meetings, documentation, etc., that consume time that would otherwise be spent developing. Knowing what percentage of your work day will really be free to use for develop the software is critical to your estimation process. Your original estimate should be adjusted by this factor to get a 'real day' estimate.
- Get a feel for your boss's estimate slop - how much does s/he adjust your estimate when adding it to the overall schedule? Some managers take your words as gospel. Others, more cautious, add a few days/weeks/months to your numbers to get a 'safe' schedule. Knowing this will allow you to pad your estimate a bit to account for a brave manager's lack of adjustment.
- Learn how often developers are called on to support code in the field. Field support always trumps development work, because paying customers trump potential customers. This, of course, introduces a whole new set of issues with schedules, because at any moment your development time may be pre-empted by a support call that may take the rest of the day and into the night, as well as blossom into a string of meetings, conference calls, and possibly site visits. So the percentage of time you might spend dealing with the field will be a factor in your estimations.
Technorati Tags --
Software
SoftwareDevelopment
Computers
Programming
No comments:
Post a Comment