One line requirements, what should I do?
Posted by SoftwareArchitect101@reddit | ExperiencedDevs | View on Reddit | 17 comments
I am a technical person. We are supposed to be given requirements via a business analyst, who ideally should analyze the ask by business, impact, various scenarios, and tell us the same. But he is transferring that one line business ask to us. We, as technical people, interpret it in one way. After code development, he doesn't review our outputs functionally. We assume it's okay (an unsaid lgtm), then we ask the business to verify it as well.
During the verification by business, they tell us it's wrong and something else was expected.
How should I communicate to my manager that if this continues, there will be a lot of to and fro s, which will bring unnecessary delays for simple tasks? Also, what is my manager supposed to do, ideally?
This doesn't happen for technical-heavy tasks, but only when business wants a new feature.
Federal-Garbage-8629@reddit
If you have stand up meetings call them out for specific requirements, talk to your teammates. If you Jira tickets keep tagging them for specifications.
We have one project manager who provides perfect ACs on the ticket that you can just develop closed eyes, the other one would have only title and a one liner tickets.
I usually keep asking questions every time.
originalchronoguy@reddit
One line requirements are usually in the realm for principal or architect. Who get vague user requirements and can deliver end-to-end. This expectation exists in the higher echelon of the IC ladder.
SoftwareArchitect101@reddit (OP)
How exactly can I manage the ambiguity? I mean, I'm willing to work but without a lot of business domain knowledge, it's difficult - I'm in a bank
birdynj@reddit
I'm a dev (not really IC anymore though) at a big bank. You will go very far in your career at a bank if you take the initiative to understand the domain and have confidence facing off with the business. It will get you noticed
Additional_Mode8211@reddit
Coordinate with the user who is asking for the feature. Start a public thread to discuss details and get visibility that you are working the problem and have receipts for what you build. It’s much more iterative and isn’t ideal but it’s a good skill to have.
originalchronoguy@reddit
You don't even need to do that. What works for me is you go in like you own the place.
Start developing cadence, start doing the system designs, start assembling the team and start building. Come up with a quick POC to validate to their stakeholders.
At that point, business better hop on and provide the additional context because you already steamrolling at a velocity they need to keep up or they look like they are not holding up their end of the bargaining. Then their stakeholders starts wondering why they haven't kept up to pace.
They hate losing control of the product. But once you start dictating features, milestones, they get railroaded into compliance.
originalchronoguy@reddit
Principal/Staff comes with experience:
Principal = [Business Vision] ->
Staff = [Strategic Pillar] ->
Senior = [Feature Set] ->
Junior = [Technical Task]
Here is a boilerplate Google Gemini response, because I am lazy:
Junior engineers require fully defined tasks; Staff and Principal engineers require only a business intent. At the Principal level, value is not measured by code output, but by the ability to ingest a highly ambiguous, one-line business objective, extract the hidden constraints, and translate it into an actionable, multi-quarter technical roadmap that aligns cross-functional teams."
Why They Get One-Liners
How Principals Process Ambiguity
Example Shift
nana_3@reddit
Realistically users are bad at clearly stating requirements. You are going to have to talk to them to clarify a lot of the time. Usually the best way to do this is to fill in the blanks and let them correct you when you’re wrong. But you should be aiming to do this quickly, not at the end of a finished product. Dealing with the ambiguity of requirements is a senior skill.
There’s like 3 places minimum where you could speak up well before it reaches the “we’ve fully done it and now the business says it’s wrong” thing.
First if you have a 1 line requirement and immediate questions, ask the BA to follow it up or better yet reach out to the requirements maker yourself.
Second if they still want to give you very little info, write down a user guide or a pitch of whatever you’re planning to make and have them sign off on it before you make it.
Third you can make an mvp demo and send a video or live demo program to the requirements maker to verify them.
originalchronoguy@reddit
Bad requirements is simply the reality. And how one deals with reflects their senior skill level. This is well documented in many career ladder and job-description "requirements."
Often spelled out. Take the DropBox career ladder. IC4 Senior dev:
https://dropbox.github.io/dbx-career-framework/ic4_software_engineer.html
Scope Area of ownership and level of autonomy / ambiguity
I can probably provide 30 links to different org's job roles and descriptors that spell these all out in the different IC ladders. The more ambiguous the ask, the more senior/staff you are. It is that simple. Don't take my word for it.
loosed-moose@reddit
Maybe be more involved in defining requirements? You're giving "please just tell me what to do" energy and it's pretty sad.
GumboSamson@reddit
Sounds like written communication isn’t how things are done at your company.
Try a meeting or a phone call before you start implementing?
ttkciar@reddit
Your manager should at least point you in the direction of the people who know what the project entails, so you can pick their brains and work up a proper specification.
Beyond that, your manager might reach out to those people's department and arrange a meeting so you can have that discussion in a structured, scheduled way, instead of you just knocking on their office doors and asking for a few minutes of their time. Whether you do one or the other really depends on the size of the company and its corporate culture.
spacemoses@reddit
Be the business analyst you want to see in the world.
Wide-Pop6050@reddit
You have to address this at the root. When you get a one line request reject it right then and there. If the business analyst doesn’t flesh it out, escalate to their manager
x-jhp-x@reddit
"During the verification by business, they tell us it's wrong and something else was expected." Talk to those people instead, and hammer out requirements. You need to ensure that your tasks have an unambiguous end point, where you can say "now the task is done". If what you have done meets the agreed upon requirements, but they want more or something else, you can then start a new task and repeat the process.
wotamRobin@reddit
Do you have the capacity to reach out directly to said business analysts? I'm sure this process is frustrating for them as well, and that's an opportunity for you to be on their side. The more you can build a relationship, the more they will be happy to chat about small clarifications and have checkins along the way during development.
If you work at a place where your communication is limited, you're best off communicating the problem to your manager first and including its effect on you as well as related to the team's goals. Ask for their opinion on it first, but be prepared to offer a solution if they don't have one.
F0tNMC@reddit
Follow up before starting work with a clear explanation of your interpretation and get a definitive sign off that everyone is on the same page. ABC always be communicating.