0

The organization I'm currently working at, have no business analysis approach.

Due to that lack, all the changes/upgrades we are doing or trying to do are hellish. The technical person has trouble trying to understand our requirements, we yell at the technical person telling him almost literally that he is "not smart" enough to understand what we are trying to do.

As the issue happen, again and again, I would like to improve this process.

As we are a small structure, we don't need yet big functional requirements yet.

I would like to start simple functional requirements that can be easily understood by a technical person.

Questions are the following:

  • What kind of business analysis methodology, should I look at?
  • How can I use that methodology to structure the functional approach and get it done to something more technical?
  • As the structure I'm working at is not big, I'm unsure if it is the right approach. However, if it is not, what approach should I try?

Thanks

  • 2
    Please don't yell at the technical person or call him stupid. They do have feelings you know. – Muhammad Aug 4 '17 at 16:03
4

Your biggest problem is a toxic work environment.

As you note,

we yell at the technical person telling him almost literally that he is "not smart" enough to understand what we are trying to do.

If someone were to do that to me, I'd immediately demand an apology. If I didn't get one, it'd clearly be time to update my resume... or perhaps even go to HR and make sure the other person updates their resume. A work environment where people resort not just to blaming, but to outright insulting others' capabilities, is not one that could be considered acceptable nor healthy.

Either your concerns are founded (he's not smart enough), or they're not. If they are founded, then just fire him and get a new one. Don't waste time with insults. If they're not founded, you're burning a valuable bridge here. Sooner or later he's going to quit and, depending on the size and nature of the local talent pool, he may warn other potential hires to steer clear of your company. You'll be stuck with the bottom of the barrel - developers too desperate to avoid applying to work at your company, and also too complacent to quit despite the toxic environment.

There are two main (broad) approaches to solving your requirements problem.

Broadly speaking, you can solve this in a traditional way, or an Agile way - or in some mixture of the two.

If you want to go the traditional route, then before the developer even starts working (and, consequentially, before the schedule 'starts'), the requirements need to be defined, then sent to the developer. Then the developer needs to redefine the requirements in terms that he understands; in what he plans to give the (internal) client. Then the client needs to look over the new, developer-defined requirements, and sign off on them. Then the developer starts working. And then, at the end, when the client complains that they don't have what they asked for, the developer is entitled to reply "Not my problem. You signed this off."

There are other ways to go about it, but the general goal is to ensure that there is agreement between the clients and the developer on the requirements before any work is done. The better that agreements is mutually understood (and the less the requirements change afterward, see below), the better off you'll be.

The biggest problem I've found with the traditional approach is changing requirements. Not only do actual requirements change over time (new technology comes out, an important contract falls through, etc.), but users never actually even know what they need, until that need is fulfilled.

Agile therefore eschews rigid planning for iteration and adaptation. The developer works for a week or two (or a day or three, etc. - exact time doesn't matter much, as long as it's short), then shows what he's made to the client. At which point the client tells the developer what to change. At this point, it would be downright curmudgeonly to call the developer stupid for not getting the requirements right - not much time was spent on them upfront, and only a short amount of development time has been spent. And with the next iteration, the product becomes a little closer to what the client needs, then a little closer, then a little closer, until they're finally satisfied.

As noted, there's no reason you couldn't combine the two, to a point. Start with the upfront requirements gathering/agreement, and sign it off. Then work on it for a short time, show it to the client, update the plan, and sign it off again. Then repeat.

  • hi @sarov, thank you for your update. I do agree about the toxic work culture. It is something I mentioned and I'm changing bit by bit. Before it was even worse but I spare you the details. One of the thing though is the following: How do you create business requirements? That was more what I was thinking when I asked my question – Andy K Aug 4 '17 at 14:15
  • @AndyK My company? Through the traditional approach described above. The client creates the first wave of requirements, sends them to developers. A developer rewords them into program features, sends them to client to sign. – Sarov Aug 4 '17 at 14:22
  • 2
    Just keep in mind at all times the actual goal: to create shared understanding of the requirements between the developer and the client. As with all communication, if that fails, it is both parties' fault. And you'd be better served trying to improve your process to prevent future failure that you'd be throwing insults and blame around. Remember those two axioms, and the rest should sort itself out one way or another. – Sarov Aug 4 '17 at 14:25
  • Adding to what was said above, I can recommend you try wireframing/mock-ups. I have found it to be an excellent tool to allow the developers and non-developers talk to one another effectively. Wireframing can be done by the non-developers in your team. This will help when talking to end users as well. – Muhammad Aug 4 '17 at 16:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.