I’m convinced that one of the biggest problems in software development today is not a technical problem. It’s a people problem. Code (usually) does exactly what you ask it to, but most businesses don’t really know what it is they want software to do.
They might have a general idea of how some process works today, but often even that is a stretch. Maybe the process is not what it needs to be, or was the result of some now-irrelevant technical limitation. Maybe Sue in accounting hates approving the TPS reports, but just does because she always has. So, the pointy-haired ones ask the nerds to build XYZ, and the nerds build it, and it doesn’t do what the pointy-haired ones really wanted. Over and over and over again.
I’m convinced this is an area where our industry can do better. Maybe it’s just me, but our development tools are improving much faster than our people skills. Tools like Trello or Yammer for communication abound, but even these do you no good if you’re asking the wrong questions. I don’t have all the answers, but I have developed a handful of ‘templates’ I often use when asking customers about projects they want to take on. Here are some useful tips for building requirements or helping others do so:
1) Use a simple template as much as possible
Fill in the blanks: “As a [Role name] I would like to [feature] so that I can [business reason]”. This is the classical agile story card statement, and there is just so much packed into that simple phrase. Who, what, and why. Let the nerds build how.
2) Think business-first for reporting and data visualization
Again, fill in the blanks: “As a [Role name], I think it’s been a [good/bad] [day/week/month/year] when [metric] is [up/down]” Too often developers start from some data and try to throw up every chart and report their tool will spit out. Other times, business owners will ask for an updated version of some mainframe report, without thinking about why and what the report shows. By starting with the business problem, you can understand who is needing what exact numbers, and some value judgment about the metric. The template above only works for time series data. An approach for non-time bound data: “As a [Role name], I need to see what values make up [metric], so that [business reason].”
Another favorite: “As a [Role name], when [metric] is [up/down/within range], I plan to [action]”. Even more than the others, this ties the measure to some specific business need. Oh yeah, you _need_ to see the total value of all widgets sold in Timbuktu? What do you plan to actually do if the number is or isn’t what you want?
3) Report bugs clearly
Bugs are requirements too. They are often (but not always), just requirements that need to be fixed quickly because they cause particular pain to the user. A great way to report them is: “When I do [Steps to reproduce the issue], then [detailed description of bad thing]. I expect [description of desired behavior]” As somebody who’s dealt with both sides of the support desk, I can just about guarantee that this pattern will get you a solution faster than the more common “My [vague reference to thing] bombs. Fix it!” If I get a vague bug report, my favorite template for combating it: “When you say it bombs, what do you mean? Tell me the steps and any error you get.”
4) Don’t forget the environment
Another mistake is to not understand the other hardware and software surrounding a given solution. “Tell me about the hardware and other software you all run” is a must-ask for any new customer. Building a solution for a VMWare shop that runs all SQL Server and IIS with Exchange is different from building the same solution for a firm with Oracle and Apache. More and more, you may find that companies have little or no infrastructure in-house. Building for Amazon EC3 or Azure is different again from on-premise.
So, there you have it, 4 ways you may or may not have thought of to ask your customers what it is they want. If you have more ideas, I’d love to hear about them in the comments!
No comments:
Post a Comment