The Project
- Requirements are maintained in word docs on a shared drive (not Sharepoint) where the filenames are along the lines of "Release - June 2007" that nobody's opened in years. Essentially, they're practically un-browseable and un-searchable in any decent amount of time.
- These requirements were never formally reviewed by anyone. People would show those groups like QA and End User Trainers "how it should work" in a 1 hour meeting.
- Developers tend to "own" things where one feature set is entirely done by a single guy. No recorded code reviews.
The Costly Situation
- Some piece of software has a feature that has been working in production for a couple years.
- An odd behavior comes up it is keeping an order from being Billable. For arguments sake, it is a scenario that hasn't come up in an extremely long time and there's no documentation in the IT Ticketing system of how this was resolved the last time.
- The guy who coded it is no longer with the company.
- None of the "expert" users know how the software SHOULD react in the given scenario.
Cost #1: Operations
The earlier you have that money in the bank, the earlier you're making more money for you. If this is visible to the customer, you run the risk of their simply cancelling and going with a competitor.
So let's say this IT ticket rises through the different levels of support and reaches you, the developer.
Question #1 - Have we ever encountered this scenario before? What did we do last time?
- If you're pretty immature about your requirements maintenance, chances are you're pretty immature about your bug tracking too. For me, this is a classic example of a Broken Window phenomenon in a software development project.
Question (set) #2 - Why is this happening? Is it a bug? Did the requirements cover this when the feature was developed?
There's absolutely no reason for you to look up the requirements. You're not going to try to wade through 10's or even hundreds of Word docs that were meticulously documented but whoever wrote them didn't really think about how to reference back to them. If you're not a developer, the one thing left to do is at least dork around in the stage environment to reproduce the issue.
Cost #2: Support Investigation
Even if the issue is reproducible, without the requirements from when this feature was developed, you probably can't answer the question "is it a bug?" "Why is this happening?" Without the context of the requirements, reproducing the issue can be a significant challenge.
You're still going to need a developer to look into this. However, it is extremely likely that in this scenario the first 2 questions aren't even asked so one could argue that this cost in labor isn't even accrued. :P
OK DEVELOPER SAVES THE DAY. Not Really.
Ok you're investigating the code to answer Question #2. You're likely wading through code you're unfamiliar with. At this point a lot of people will argue that this like ability of the investigator, coding conventions, and quality of code will impact how efficiently this investigation will be accomplished.
Question #3 - What is the context of this code?
Commit messages can help. Code quality can help. However you likely don't have any linkage from a commit message to the actual requirement. That would come in handy, but like we said, that stuff isn't there for you. So the differentiation between "this is by design" or "this is a bug" is close to impossible. It's going to take you some time to figure out what's going on in the code, describe it to somebody, and hopefully have a solution on what the user should do to keep the Order moving forward.
Cost #3: Developer Support
What could have been answered from a requirements lookup has now extended to any other full-up bug investigation in reproducing an issue and passing it onto a developer. You're going to have some back and forth between the developer and others in terms of trying to answer "why is this happening" question.
Question #4 - Is this by design?
You can't tell. Chances are this will be dependent upon your opinion of the guy who wrote it. Either way, it's going to be pretty hard to answer this question. It will be up to some pointy haired person to decide that it is a bug that needs to be resolved right away in the code, that the business needs to update their procedures to be aware of this scenario, or that some behavior change is required to go through some other channels of funding.
Cost #4: Aftermath - Because you haven't come up with what the requirements were at the time the feature was implemented, you can't hold the business accountable for what discussed, reviewed, and implemented. It is generally easier to get a customer to swallow the "this is by design" story if you have the documentation to back yourself up and simply update their processes.
Some people will say that some email will be required to accomplish this but that's in lieu of a decent requirements tracking system. Without this documentation, you're likely going to take up some time to discuss whether it's a bug (money from the IT Bucket) or a new feature that needs to be implemented (money from the Business Bucket).
Either way, in order to move forward, the relationship between business and IT runs more smoothly if the conversation goes down the path of "ok now we know what the thought was when we implemented this, but we'd still like to submit a change request," vs. "we're going to just have to agree to disagree so what are we going to do about it?"
There are a lot of pieces that need to be in place to reduce all the costs identified. However, requirements that are clarified, reviewed, and traceable are key to making all those pieces be in place (and alleviate the cost of that too).
A common reaction of all of this is "Documentation is always out of date when the code is implemented"
This is what User Stories in a Scrum process are meant to alleviate. I'll talk about this in some User Story post, but I'm already getting requests for describing the costs of getting a Release out after a Release Candidate has been cut so that might just be my next post.
No comments:
Post a Comment