4 ms·

Your 2nd point rubs me the wrong way, though it could just be the wording. Depending on the organization, by the time it got to you, there may have already bee

Your 2nd point rubs me the wrong way, though it could just be the wording. Depending on the organization, by the time it got to you, there may have already been discussions about scope and business need. Unless you're an SME, your evaluation of what is needed is not better than that of those who are requesting the work. Sure, your knowledge of the effort is better, but that's not the same thing. There's a decent chance you're going to come across as difficult to work with and then you're going to build a solution that doesn't fully meet their needs. I get where you're coming from, but I've spent time on the other side. Requirements take negotiation and collaboration.

kthejoker2 3y ago
You can spin the second questions as wanting to understand why this hasn't been done before, and what the current workarounds are. It gives you some sense of the affordances you need and the current value of having done nothing so far. It also helps with prioritization - is it a must, a should, a could, a wish?
shireboy 3y ago
To be sure, part of the challenge for me on that one is to ask it while not being a jerk. Yes, it’s a negotiation. Maybe you and I work in different circles, but in my experience people ask for features they don’t need all the time. They have a business problem, ask for what they think is the technical solution, but may not know the technical options available to solve the business problem. They may ask for a 500 page report so they can find a customer that meets x criteria, but really, better search would help them more. I had a customer sink hundred thousands into cryptographic digital signatures. I suggested the “business analyst” and upper management discuss with legal, and indeed in this case a checkbox sufficed instead. As a dev I like to say my job is to translate English into nerd. Non- or semi- technical people should communicate the business problem and then together we’ll work towards the best solution. Sometimes the solution is code.

kthejoker2 3y ago

You can spin the second questions as wanting to understand why this hasn't been done before, and what the current workarounds are. It gives you some sense of the affordances you need and the current value of having done nothing so far. It also helps with prioritization - is it a must, a should, a could, a wish?

shireboy 3y ago

To be sure, part of the challenge for me on that one is to ask it while not being a jerk. Yes, it’s a negotiation. Maybe you and I work in different circles, but in my experience people ask for features they don’t need all the time. They have a business problem, ask for what they think is the technical solution, but may not know the technical options available to solve the business problem. They may ask for a 500 page report so they can find a customer that meets x criteria, but really, better search would help them more. I had a customer sink hundred thousands into cryptographic digital signatures. I suggested the “business analyst” and upper management discuss with legal, and indeed in this case a checkbox sufficed instead. As a dev I like to say my job is to translate English into nerd. Non- or semi- technical people should communicate the business problem and then together we’ll work towards the best solution. Sometimes the solution is code.