Let’s face it, sometimes we are stuck and we do not know what to do. This can feel terrible and I want to give you a simple system to help you figure out where to look first to unstuck yourself.
Most things in life involve answering (at the least) these two questions. The first question is: “What do we need to do?” (requirements gathering). The second question is: “How will we do it?” (designing or specifying).
“The hardest single part of building a software system is deciding what to build. No other part of the conceptual work is as difficult in establishing the detailed technical requirements, including the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the results if done wrong. No other part is more difficult to rectify later. Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements.” —Fred Brooks
The basic planning process in software engineering revolves around these two steps, first gathering requirements and then designing a solution to meet those requirements.
A requirement is a carefully written down description of a criteria that the work is supposed to satisfy. There might be many ways a design can satisfy a requirement, but it should be straightforward to see if the requirement has been met by looking at the finished piece of work. A specification or design is then simply a plan for building something that will satisfy the requirement.
And… that’s the framework. That’s it.
(Image: Making Things Happen by Scott Berkun)
That diagram right there is the framework in figuring out what to do.
Because now when you are stuck you can place yourself into either one of these three categories:
- Do you not know what to do? That means that the requirements are unclear, then figure that out.
- Do you not know how to do it? That means that you need some help with your design, then figure that out.
- Do you know what and how but you just need to do it now? That’s a motivation problem, figure that out.
Final note, I also like is that this maps almost 1:1 to the PRD and RFC framework that Hashicorp describes in this blog post How HashiCorp Works.
Remixed and adapted from Making Things Happen by Scott Berkun. There might be some words in here that I straight up copied, but I found the framework so useful to figure out what to do I wanted to share it anyway.