As I noted in my last post, it’s really easy to hate meetings (I’m certainly not the biggest fan of them either), but that doesn’t mean that all meetings are inherently worthless. Some meetings can help give focus and clarity to your work, and that’s a requirements meeting.
Odds are we’ve all seen this comic, which does a pretty good job of summarizing all the ways communication falls apart during the software development process, and how easily it is get focused on something completely differently than what the customer wanted or needed. It also shows the importance of taking time up front to figure out exactly what the customer needs before you start trying to build something.
It’s particularly tempting to blow off a requirements meeting for work you’ve gotten from someone else in your organization and the project seems simple enough. You should still take the meeting. In fact, if you weren’t there when the original work was being discussed, you should absolutely be looking for a requirements meeting with the customer. It’s tempting to accept getting requirements second-hand because the person giving them to you met with the customer, but that’s not good enough. Trust me, I’ve blown projects making that very same assumption.
The main benefit of having the requirements meeting is that it gives you a chance to ask the right questions. Keep those focused on the problem users are trying to solve, because that’s the information that’ll guide every decision you make, from the architecture, to scope, and even how to prioritize work. Questions that define and capture the users’ problems form the foundation of the work you end up doing. If you get this part wrong, you’re going to have a long, painful slog just to end up with something the user considers adequate.
Another benefit of a requirements meeting is that it lets you manage customer expectations. In the aforementioned project where I disregarded the requirements meeting and ruined the project (from the customer’s point of view), they wanted plugin functionality that wasn’t available to plugin developers (thanks to the limited components I had to work with). If I had taken the meeting, I could have told them that while I could build something that solved their problem, building the feature they wanted was high-risk, and even if I could have reversed-engineered it, it’d have been incredibly brittle.
If you do the requirements meeting right, you should have enough information and context to be able to focus on the things that will have the most impact on the customer’s problem. You would also have set expectations with the customer that you’d deliver something that solves the problem, without letting them get fixated on any specific implementation. This lets you go back and define a feature set that meets the customer’s needs, is doable for you given the business constraints (budget, time, etc.), and is prioritized around the things most important to them. Software development, like everything else in life, involves trade-offs, and spending time understanding the customer’s problem ensures you have the information needed to make the right trade-offs that still leave you with happy customers.
When it comes to project meetings, it’s easy to blow them off as a waste of time, but meetings with the customers to discuss requirements are vital. Keep in mind that the purpose of these meetings is to define the problem, not to list features. Without this meeting, you’re effectively relying on a game of telephone to understand just what your users want to accomplish. You also miss out on a crucial chance to temper customer expectations away from “I’m fixated on this particular feature” to “as long as I can accomplish {X}, I’m fine.” Taking a requirements meeting and having the right approach to it defines success and leaves you with all the options of how to achieve it. Of course, if you don’t care about success, the feel free to telephone it in.