There are problems we should be solving, but they're not part of any requirements. That's where you come in. Use your professional skills to help us shape a solution that will make our customers happy, without breaking the bank.
I've been on most sides of the equation when it comes to this. I started as a help desk technician. Then I tried to help define the requirements that we needed. I've been a consultant where I fulfilled the requirements. Now I'm a customer again. When you're a customer, you don't care how it works, just that it works. At least that was my opinion back then. Now, I push back. I ask why. I get the details that drive to the question, "What business problem does this solve?" You should to.
You are the expert
You were hired or at least you are probably working as the subject matter expert. If you didn't push back or give reasons why the requirement they've given is poor/bad why wouldn't they keep doing this? When someone asks;
Customer: Hey SME, Add this checkbox on Incident called "Outage"
You: I can do that, but why do you want this?
That's all this post is about.
Until they give you the reason, or the business problem this solves. I'd wait to do it.
I've spent countless hours head down working on code that never got released because I never asked this. Sure. They are paying you either via payroll or via a contract, but, if you didn't ask you wouldn't be doing you're job. It's critical you ask.
How I handle poor requirements
I'll go over adding that field above.
Customer: Hey SME, Add this checkbox on Incident called "Outage"
You: I can do that, but why do you want this?
Customer: Don't ask why, just do it.
You: If I didn't ask, you could hire anyone to do this.
I've done this in the past, and knowing why is crucial to ensuring this is the right thing to solve the problem.
When you don't present a problem, it's concerning because you might not be considering other factors.Customer: Like what? Less is worst!
You: Licensing, whose maintaining the value of the field, what is going to keep it in check,
and setting an expectation that anyone can add an arbitrary number of fields on incident.Customer: This is just for reporting. We want to know when and for what customers an incident is considered an outage.
You: ...🤦♂️
You can see how this might keep going down different ways. Maybe the right call here is use the cmdb_ci_outagetable. Maybe the right call is to use a metric. In any case. Adding a field is probably not the right way to solve this.
Let me end here by quoting Chuck's ending remarks;
- First, Seek to understand their needs. Don't take their solution at face value when you haven't understood the problem. Ask why.
- If necessary, consult the community for additional knowledge in the matter.
- Offer options.
- Finally, make your recommendation based on their needs.
Chuck Tomasi
By asking why, you could short circuit any solution saving you and colleagues loads of time, the customers money, and wasted resources.