Can requirements be clear at all?
Hey!
Welcome back to another week of musings.
I've been knee-deep in a project that requires my full attention, and I've been lacking proper exercise and leisure time. So, this week, there were not many interesting links. I do hope you had a restorative weekend!
Was this forwarded to you? You can subscribe here!
Things I discovered in the past week
- This video, about the gaming industry in Guatemala, was released earlier in the year. It is in Spanish, so you might want to turn on the auto-translation.
- This is an absolutely random recommendation, but I've been using the iOS Freeform app to create quick diagrams on my phone. Sometimes, I go to the office and show a quick diagram during a coffee break, which, looking back, might be a weird sentence to a lot of people.
As engineers, we complain a lot about how requirements should be clear in an attempt to reduce the rework of features. But in practice, requirements are never clear unless we work on a very clearly defined problem space. If not, then the only constant will be change and how easy it is for our systems to take it.
Nobody really knows
This might be the reality of your team or even your organization if the team reflects the larger culture. In this case, multiple things might be at play.
We are not building for the customers; instead, we're building what the leadership team is asking for. Consultants or similar might inform them, but it boils down to making what we're being asked for. These requirements come as very high-level leadership style asks, and we "refine" them as we discover the results from analytics or whenever leadership changes their mind (which, in my experience, happens way too often).
Another thing I've seen is that we're attempting to experiment, but the system wasn't built for that, so it feels not like we're a/b testing but instead building feature A, testing it, and then shutting it down and doing feature B all over again. Then deciding on the winning feature and "doing that for real."
We make it hard for ourselves
Another thing that tends to happen is that, in the same line as the A/B testing, over time, we make it hard for ourselves to create change.
Maybe you've been in conversations where the requirement "is impossible" or would take a long time to implement. Over time, it erodes trust between product managers (PMs) and engineers. I've seen it end with teams trying to avoid having requirements for engineering because they believe it won't be done in time. This creates a lot of toil because if, by some miracle, the experiment works, the "quick solve" will be inherited by engineering, and now, they need to support it.
Other times, I've seen people leverage scope creep to get to their actual requirements. The project never ends where we agreed. Instead, you "just add this" until you're done.
No time to meet. We need to execute
This is a mode where teams define "requirements" at a very high level and jump straight to coding. Why meet for 5 minutes to save 5 hours of coding? Sadly, this creates a lot of churn and a lot of rework. If you feel like you're in this situation, it might happen that the team or organization lacks a strong documentation or meeting culture.
I'm not talking about design reviews, approvals, etc. It can be more of a lightweight document, at least to outline what we plan on building, and meetings that have an agenda and notes with action items.
Clarifying expectations and outcomes helps build better products and avoid re-work or toil.
Your turn!
Have you ever wondered, " Why are requirements never clear?" If you share that frustration with me, let me know by replying to this email about how you deal with the situation.
Happy coding!
website | twitter | github | linkedin | mastodon | among others