Functional analysis is the Devil

Disclaimer: In my career, I’ve worked with smart people that happened to be analysts. Awesome people always bring great things to the team, no matter what they do. This is a hate-the-sin-not-the-sinner post.

The art of requirements gathering

The life-cycle of a project starts with requirements gathering. Smart people ask questions about the problem, write down a solution in JIRA and leave it to the nerds to translate that to code.

When everything is translated from JIRA to Java and the nerds didn’t make too many mistakes, the thing is Done and can be shown to the users.

Whether it’s Waterfall or Agile, we believe in a PBS or Backlog that consists of tasks. When these are Done, so is the project.

Software development brings together 3 kinds of expertise :

  • Domain specialists know the problem and its context inside out.
  • Technical experts understand the best ways to design and build solutions.
  • Managers know how to keep such a project on track.

Functional analysts are none of these. We bring in people who don’t understand the problem space and have little understanding of the technologies used in designing a solution. They just create interference on the line between domain and tech experts. Ouch.

We have a word for writing down specifications in such detail that there is no room for interpretation. It’s called coding, not requirements gathering. JIRA is just a fluffy communication channel on top of that. It tells you how many tickets you have, not how good the result is.

The magic of agile software development happens when domain and tech experts get together and design a better solution. Something they could not have come up with two weeks ago. The cross-pollination of knowledge between these two fields of expertise is your superpower. An intermediary that plays Chinese Whispers is your Kryptonite. Ouch.

Are your developers playing catch-up with requirements that changed yet again?

Are your domain experts disappointed at the results of your demo’s?

Do your analysts have to relay every question back to the customer?

Do you feel like nobody understands each other?

Cut out the middleman. A software developer should talk directly to the domain experts. Let them bond. Typing is just 20% of the job. Both parties can learn from each other and grow an awesome product.

Isn’t that what you’ve set out to do?

Building software is hard, but don't let that stop you.

If you're building a product and feel like you could use a supportive techie in your corner, let's set up a quick chat to see if I can help you.