do you have business analysts?

Curious if people have business analysts on their team? Someone that writes business requirements/functional specs that has excellent business domain knowledge. They hand this off to Developers to write TechSpecs. Perhaps they do some testing.

Or are the programmers responsible for gathering the business requirements.

do you think they are valuable? we had 1 where i presently work, but they recently got rid of him. i think it was a mistake.

Patrick
Tuesday, July 27, 2004

We have an entire group of them.  Their value is debatable.  When the domain knowledge and communication skills are up to par they are invaluable to a project - when either is not up to snuff they are a great hinderance.

I do wish more business oriented programmers would become business analysts.  I think that would be a reasonably good transition - as long as they don't start writing code for their specs.

...
Tuesday, July 27, 2004

My experience is the same as ...

Good analysts are very valuable. But analysts who are there because they sucked up to the boss, have big chests, or were moved into "analysis " because they were lousy developers are a major drain.

Anony Coward
Tuesday, July 27, 2004

I function on my current team as a business analyst.  If you are working on a project that requires highly specialized domain knowledge and you have a good one who really understands the business and the code, it is a good thing to have.

If you are working on say, a word processor, then you probably don't need one.

name withheld out of cowardice
Tuesday, July 27, 2004

yes, we have a highly specialized business product. the business analyst that we had was good! He knew his stuff.
he wasn't actually let go just moved to another department.

one of the so-called faults about him was that he didn't really mingle with the co-workers. gee, the co-workers are complacent with bad attitudes - i can't blame him!

the feeling of the company is that they want the customers to drive the requirements and have the developers capture these and turn these into functional requirements then tech specs.

Patrick
Tuesday, July 27, 2004

We get pretty vague scopes, and generally we have to make our own business and tech specs.  The big problem I have with that is I can't be both a technology expert and a business expert.  I have spent most of my life becoming an expert at translating business rules into technology, and now I'm asked to create the business rules essentially just from talking to people.  People that don't necessarily understand their own business.  So I have to figure out how they're running the business!

It's a wild concept, really.

sir_flexalot
Tuesday, July 27, 2004

We've got 8 plus 2 assistant business analysts  for 2.5 developers.

They gather requirements and write them out pretty much verbatim, call it a spec and then say can you knock something about a bit like that. Sometimes they give you photocapies of the notes they took in a meeting 6 weeks ago and call that 'requirements'.

They then test the application against some mythical set of criteria, dreamt up in the bath I think.

Sometimes they do a bit of support. Sometimes I correct the data they screwed up doing the support.

Business analysts can be a good idea. I worked on 2 large projects where there business analysts seconded from various departments working with systems analysts with an IT background. That worked as well as could be expected.

copper's nark
Tuesday, July 27, 2004

Our business analysts are programmers

Our programmers are business analysts


We don't hire geeky l33t programerz.  It's more important to have a person that understands the business 100% and programming 90% than the other way around.  We don't hire architecture astronauts.

Formerly someone else
Tuesday, July 27, 2004

We have a group of "business analysts".  There usefullness is debatable.  One of the group is pretty good and has a pretty large domain knowledge, the others range from mediocre to really bad.  We still get incomplete requirements and developers still have to do a lot of requirements gathering and cleaning up of the design, but that's fine with me (less chance for my job to be offshored and it's a break from pure coding).

almost anon
Tuesday, July 27, 2004

i absolutely agree to the above that business knowledge is more important that technical knowledge.

Patrick
Tuesday, July 27, 2004

worked with a business analyst in my last job.  she did everything from writing up technical specs, to testing/compliance, to doing back and forth with clients.  she made my job 10x easier.  she also brought in delicious cookies.  ah, i miss her...

Kenny
Tuesday, July 27, 2004

then you get the Business Analysts with no domain business knowlege (they transferred from another department during a re-org years ago), but they've been with the company 80 hojillion years and no one will fire them.  They typically also lack anything resembling technical skills or even a basic understanding of the limitations of program code or the time involved in developing.

These guys are like an anchor around your neck.  You have to use their specs because they're the business analyst.  Challenge them and it's laughed off because hey, you're just the programmer, not a business person.  What do YOU know about requirements?

muppet
Tuesday, July 27, 2004

I think the biggest problem with a dedicated business analyst is that it takes a lot of time (or smarts) to get to the stage that you know enough about the business logic to make informed decisions.  You need someone who has worked in the field for a while.  Developers, by default, because they are writing the code, should become experts in the domain (or at least experts in how things are currently coded for their domain).  Someone who isn't writing code to represent the business rules is going to have a harder time clarifying those rules in their mind.

almost anon
Tuesday, July 27, 2004

By the way.  Business analysts aren't being outsourced.  Hmmm....

Formerly someone else
Tuesday, July 27, 2004

I consider myself a developer and a business analyst. While developing applications I had to attend to endless meetings with users to understand their requirements. After a few months I could discuss with them about business related topics.  Sometimes they asked for my advice as they knew I understood them.  When people (users) were replaced by others, the new ones always came to talk to us about the applications of course, but also about the other stuff…it was great.  Being a business analyst (and developer at the same time) opens the world to you.  If some day you get tired of developing software you can easily switch to any other business/management related area.

Cecilia Loureiro
Tuesday, July 27, 2004

So far most of the business analysts I met were knowledgeable on the business side and next to 0 when it came to software development. The requirement documents and/or business models they produced were full of inconsistencies (terminology, content, ...) and incomplete at all times from technology/system perspective. Typically an architect would have to clean up the mess and create a technically usable business model.

Or you get a tech guy who plays the business analyst. Chances are you'll end up with a technology driven business requirement. Then you need a business guy to straighten things up.

Things don't stop here; there is constant feedback into business requirements from the development team, even from QA. The business analysis is in fact part of the development.

It all comes down to teamwork.

Dino
Tuesday, July 27, 2004

In response to your question, yes we have business analysts.
Those that know their their stuff seem to have been here for ages but they're always being overcommitted with work. Net result - it's almost impossible to get their assistance sometimes.

As for those that don't know their stuff...

TheGeezer
Tuesday, July 27, 2004

  Recent Topics

  Fog Creek Home