OK, so I'm kind of a movie fanatic. Some of the best movies I think are the ones that aren't temporally sequential (think Pulp Fiction, Momento, The Usual Suspects), those that illuminate the plot by describing the plot's timeline out of sequence. You be the judge whether this works for describing the roles and goals of Software Development.
What do you think a bug is?
This seemingly trivial, yet deceptively complicated question is at the heart of a High Quality Software Development Lifecycle.
Wikipedia's definition is: A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. Italics added.
The emphasis placed on this definition being on "error", flaw, failure or fault really summarizes quite well the industry confusion on this topic. However, almost the entire definition lies in the one word: unintended. Allow me to explain.
While some may argue this point, as I will describe in the remainder of this article, I think this definition will be quite difficult to refute primarily because of its simplicity.
A bug is a difference in functionality, design or measurement of how software actually works as compared to the specification.
So, even if an error arises in an application, how does the specification say it was supposed to work? If a tester says that this piece of the software is not supposed to work this way and the developer says it is, who wins? Easy, neither wins, the specification is always right and it is written from the customer and business' perspective. If it's not clear enough to be "right" then Bug the Spec itself and continue to refine the specification until it is clear enough to Test and Code the Software.
May the odds be ever in your favor!
OK, so what? What's the big deal? How is this simple definition revolutionary?
As it happens, defining a bug this way accurately describes the roles and goals of every person involved in the Software Development Lifecycle.
Since we started with bugs, we'll start with Tester role. So, to define something as a bug, even to define something as an error, flaw, failure or fault you must reference the how the specification accurately describes how it should function.
The first thing a Tester tests is the Specification. The Tester reviews the specification for enough detail to ensure that they can determine, once coded, whether software meets the specification. If there simply isn't enough detail within the specification to allow them to test the behavior, then they may write a Spec Bug to identify areas of specification that require further detail to make the spec testable and dev-able. Testers help clarify the specification ahead of Development to make the development process smooth and seamless.
Similarly, the Developers require enough detail within the specification to code the software.
All Roads Lead to Rome
OK, well, not Rome so much as PM (Product Management). Wait, did you say Product Management (specifically Technical Product Management)? Didn't you mean Project Manager? What's the diff?
Quite a lot actually. Project Managers typically manage Projects which is quite different from managing the creation of a Product. Project Management responsibilities briefly cover the following:
Scope Tracking - In vs. Out of Scope Items
Managing External Dependency Communication and Deliverables
Managing and Tracking Schedule and Progress
Project Status Collection and Communication
So, what exactly does a Technical Product Managers do?
Define Customer Personas (who will use or benefit from the software)
Define Customer/Persona Goals
Define the Hierarchy of Product Areas
Define the Requirements, Workflows and Data Flows within the Product
Define the Requirements for the Product
Determine Product Design for Usability, working with Graphic Designers for look and feel
Leverage SME understanding of functional areas for Product Design
Track Workflow Progress and Accuracy to Design
If you think about how cars must be designed, you can start to break down the car into various areas such as the combustion system, propulsion system, breaking system. Once the areas are broken down then you need to determine the requirements for those systems and finally you need to determine the exact designs for how the systems should perform.
OK, so what if I don't have a Product Manager?
The Good, The Bad, The Ugly
Have you ever heard the most ungodly rattling sound come from your or someone else's car engine and you almost immediately think to yourself "Oh no, it's going to explode!" You may be familiar with that same sensation if you don't have a Capable Technical Product Manager or if you've been mistakenly assigned a Project Manager, Customer Product Manager or Strategic Product Manager instead.
One of the most damaging effects it has is the slow-code or re-code effect. Imagine what it would be like to pave a road simultaneous while you're trying to drive on that same road. This is akin to trying to design software (Product Management) while simultaneously trying to develop software. This drastically slows down the coding process and lowers the quality of the design because developers don't have early or often access to SMEs during the development cycle as the Product Manager would. It can also cause re-coding either late stage in the SDLC or having to rethink features after they've already been released to production.
Even if you do consciously choose to have the Developers perform the role of Product Management it is preferable and highly advantageous to bring the Product Management work (performed by devs) to a 50% completion level prior to commencement of Development. In the agile methodology, this provides enough runway of design detail to be able to develop quickly and effectively for a period of time so as to not have to stop too frequently to pave more Product Management runway.
Without Product Management, Test often does not have enough detailed requirements or design to test except trying to make the software error. Without a detailed description of what the software should do, besides how the coders coded it, the Testers has no frame of reference with which to test against. This is the origin of the term "Works as Coded" - the arch-enemy of software projects everywhere. The Tester is simply left trying to make software "error", but cannot validate the software functions as designed because there is no design.
Aside from these very damaging effects, there's a laundry list of other SDLC symptoms you may be familiar with that are often caused by a lack of a Product Management. Here are some:
Unclear or non-existent Requirements
Slow Coding from lack of Specificity
Only "Testing" for Errors and not Functional, Design or Performance Requirements
Not Testing for Feature Completeness (how do you know if all of the functionality necessary is there?)
Completion of 90% of the project in 50% of schedule/Last 10% takes 50% of schedule
High Requirements and Design Bug Rate
Developers Multiplication (needing many more developers to overwhelm the Product Management work during the dev cycle)
Customer complaints that the software doesn't do what they need
Low customer retention/satisfaction
Not having detailed specifications of the software requirements and design causes a number of issues throughout the larger Product Lifecycle from the beginning of the SDLC all the way through Operations where the software lives and is being used and interacted with by the customer. Should you happen to have extremely skilled developers that double as Product Managers then count your lucky stars, they are far and few between.
Technical Product Manager - For The Win
The Technical Product Manager is the team member that sews the seeds of software by describing, in detail, precisely who the software is designed for (multiple personas), the core and non-core workflows and internal/external/manual workflows achieved by the software, the dependencies on which the software relies and the designs of each.
The SDLC is started and completed by the Technical Product Manager. The PM starts the SDLC by creating the product areas, workflows and specification, refines the specification further during the coding and testing phases until completion of the spec, tracks design changes, corrections and accuracy during testing and finally verifies the software design near completion in User Acceptance Testing.
Of course, this is just a brief description of the importance of the Technical Product Manager, which is one of Goal-Driven Solution's areas of expertise. We will be writing a number of articles around the broad and varied topics of SDLC including details on the venerable Customer and Strategic Product Management positions.
Needless to say that the Product Manager is the linchpin role that makes or breaks a successfully executed software project. All of the roles of the team are quite critical, but only the Product Manager is the driver for Development, Testing and Delivery.
If you like it, please share this article.