This chapter focuses on ways in which the development team can understand the real-world needs of the stakeholders and users of a new system or application. As most systems are built to solve a particular problem, we'll use problem analysis techniques to make sure we understand what the problem is.
But we should also recognize that not every application is developed to solve a problem; some are built to take advantage of opportunities that the market presents , even when the existence of a problem is not clear. For example, unique software applications, such as SimCity and Doom, have proved their worth to those who like computer games and mental challenges or who just enjoy modeling and simulating or playing games on their computers. So, although it's difficult to say what problem SimCity or Doom solvedwell, perhaps the problem of "not having enough fun things to do with your computer" or the problem of "too much spare time on one's hands"it seems clear that the products provide real value to a large number of users.
In a sense, problems and opportunities are just flip sides of the same coin; your problem is my opportunity. It's a matter of perspective. But since most systems do address some identifiable problem, we can simplify the discussion and avoid the problem/opportunity schizophrenia by focusing on the problem side of the coin only. After all, we like to think of ourselves as problem solvers.
We'll define problem analysis as
In so doing, the problem domain must be analyzed and understood , and a variety of solution domains must be explored. Usually, a variety of solutions are possible, and our job is to find the solution that is the optimum fit for the problem being solved.
In order to be able to do problem analysis, it would be helpful to define what a problem is. According to Gause and Weinberg ,
This seems like a sensible definition, one that at least should eliminate the common problem of developers often thinking that the real problem is that the user doesn't understand what the real problem is! According to the definition, if the user perceives something as a problem, it's a real problem, and it's worthy of addressing.
Still, based on this definition, our colleague Elemer Magaziner notes that there are a number of ways to address a problem. For example, changing the user's desire or perception may be the most cost-effective approach. Doing so may be a matter of setting and managing expectations, providing workarounds or incremental improvements to existing systems, providing alternative solutions that do not require new system development, or providing additional training. Practical experience shows many examples where changing the perception of the difference has led to the highest-quality, fastest , and cheapest solutions available! As problem solvers, it is incumbent on us to explore these alternative solutions before leaping into a new system solution.
However, when these alternative activities fail to reduce the gap sufficiently in perception and desire, we are left with the largest and most expensive challenge: to actively change the distance between perception and reality. This we must accomplish by defining and implementing new systems that narrow the difference between as desired and as perceived .
As with any complex problem-solving exercise, we must start with the goal in mind. The goal of problem analysis is to gain a better understanding, before development begins, of the problem being solved. The specific steps that must be taken in order to achieve the goal are listed below.
Let's work through each of these steps and see if we can develop the team skills we need to move on to providing solutions.