If one returned from an extended outer space trip or awoke much like Washington Irving’s Rip Van Winkle and went to a magazine stand, they might think that everyone had multiple 60-inch, 4K, flat screen televisions, Windows 10 computers with two terabyte hard drives, and iPhone Xs. There would be virtually no articles or pictures of two-year-old or even one-year-old “obsolete” products. Similarly, all automobiles would have at least eight airbags, blind spot detection, and backup cameras. For those of us who hadn’t been absent, we would know the reality of the preponderance legacy systems.
Unfortunately, many developers do not seem to be burdened with the reality of “old” systems. Instead, they may think that everyone has state-of-the-art systems and is as technically savvy as they are. They may find it hard to believe that users are not intimate with AES 256-bit encryption or understand the “LTE” abbreviation in 4G cellular networks stands for Long Term Evolution and really applies to the packet core and not necessarily to the OFDM and OFDMA over-the-air protocol. Of course, most of these examples are rather extreme, or are they?
During both the requirements phase and the actual product development process, great care needs to be taken in understanding who the end users are and what their capabilities are, and finally, what the users expect. The casual or limited-experience users, not the power or the most sophisticated users, need to be addressed. This criterion needs to be tempered with reality. Clearly, a software product designed to be used by a developer needs to meet a different set of requirements than a software product aimed at a pre-teen (or grandparent). The title of this article is intended to be a reminder that end users may only be “normal” people with nowhere near the experience, education, or focus of the developer.
Developers often lead sheltered professional lives. This is especially true with engineers (I know, I was one) due to the rigorous nature and structure of their formal engineering education. Courses consist of lectures and reading textbooks, followed by answering questions at the end of each chapter and checking the results listed in the back of the book. Even lab experiments and take-home projects involve sterile environments. Work results are, essentially, binary; it is either right or wrong. As we all know, real-world situations are very different. Instead, a third state, “maybe”, often replaces the convenient but simplistic right/wrong extremes. This notion can be captured by replacing “1s” and “0s” with “0.51” and “0.49” to emphasize the probabilistic instead of deterministic nature of issues and events. To acknowledge and respond to this situation, a few simple, but highly effective, steps can be taken.
- Expose developers to prospects, partners, and customers during the requirements development phase to help them understand, first-hand, the trade-offs that are made in meeting the stated goals of these groups as captured in the requirements gathering phase.
- Give customer service, field engineers, and other customer-facing personnel the opportunity to take an active role during early architectural and design discussions when requirements documents are being reviewed. The real-world exposure to the underlying meaning of the requirements will provide an additional, helpful perspective.
- Ask developers to listen in to customer service calls from customers. They do not, and probably should not, take an active role in the calls. Just listening will provide them with another real-world perspective that will help them do their job.
The three examples described above can be summarized by a simple statement that has been used as a title of another article in this collection, “They Are Not You”. This is not a judgmental statement. It only is a means of highlighting the fact that individuals have different capabilities, skill sets, and responsibilities. Similar to the notion that the act of communications is being heard and understood, not merely speaking, developers must focus on how a product will be used by others, not themselves.
The article in this collection, “What Not How”, discussed the need to focus on what customers want and the fact that customers do not care about the inner workings of how a product’s features or functions are delivered. From a requirements development standpoint, the emphasis needs to be on the what customers want while the developers need to determine how to deliver it. There is however, a third element that developers need to understand. It is the “why” the requirements are what they are. Quite often individuals tasked with developing requirements documents may not be aware of new technologies or different methods that can be employed to meet the fundamental driving force behind the written requirement. If developers understand the “why” behind the requirements and still keep in mind who the end users are and what capabilities they have, they can develop products that can often exceed the expectations of their mere mortal customers.
