The term itself is suspect to say the least. To have 'complete' requirements requires the following:
The product owner or vision holder to have a completely defined picture of what he/she wants.
The same person to have a clear understanding of what technology can do to help her/him accomplish said vision.
The same person to have the ability to communicate 100% of this information to a qualified business analyst or product manager type.
The BA/PM type to have absorbed, retained, and understood 100% of the data they have just received.
The BA/PM type to have the angelic written and oral skills to effectively communicate 100% of these requirements to the people who will actually be doing the work.
And finally to have all persons involved agree that these are the requirements and will not change.
See why I think this is a bed time story. The above scenario requires too much of humanity to ever expect what is on paper not to change.
The last company I worked with had a visionary product owner(if not a complete narcissist and manipulator), a great B/A, a great P/M(scrum master actually). A requirements document of over 1000 pages. Hours, Days MONTHS, were spent in meetings interrogating the vision holders to extract these requirements and get them into a form that the dev team could work with.
As with most things, the project started with great intentions and ended with a dead line.
Of the 1000 pages, very little reflects the TRUE state of the system today, just 6 months after launch.
This system's particular issue was that it was so damn big. Hundreds of moving parts, tens of thousands of lines of code. 40 team members, and 2 people(1 really) to specify all the requirements.
Worse yet the project schedule was totally unrealistic. In the end it became a warm bodies approach. Anyone we could teach to program and shove in front of a PC did the work. Needless to say, once in 'support' mode, most of it was redone.
What I am getting to here is two fold. Requirements are very important to get down and try to get agreement from the product owner that they reflect (at least at that moment) what the system should be. The product owner should have to sign to this effect, good god get it in writing.
The team can then estimate based off of those requirements.
If the requirements change, and they WILL, guaranteed, no ifs ands or buts. Then the tasks can be re-estimated and in some cases, the deals renegotiated, time tables adjusted etc. Unless you are one of the 80% of unlucky bastards that will have to eat the change to make a deadline, because the 'system is useless with out this feature and we won't use it'. Etc.
Point being, change happens, change is usually good. To Error is human, to learn from errors and adapt is what makes us good.
Roll with the punches, don't get upset about change. Let the people who get paid to get upset do it. By the time the change requests have gotten to your level, in most cases it has already been through the management wringer, in some cases someone got a foot in their ass, etc. But crap rolls downhill. Look down and you will see it piling at your feet.
Take the change, make sure that it is implemented with the same attentions to quality that makes you a great programmer, and thank your lucky stars you are not one of the 12% of people in this country that is calling for their unemployment benefits next week.
peace.
Grendal.
No comments:
Post a Comment