Question:
Any tech writers out there ever worked as a business analyst Resume?
I've heard the job can sometimes be a good next step for a tech writer (I've
also heard that tech writing can be a good next step for a business
analyst). I've seen postings at software companies, consulting firms,
financial services companies, and elsewhere, and there seems to be a wide
variety in the job descriptions. I'm intrigued by the jobs that include a
lot of needs analysis and product design. But I've never had an opportunity
to talk to a business analyst about what the job entails.
So, my question -- have you ever worked as a business analyst? Ever worked
closely with one? Any thoughts on the overlap between tech writing and
business analysis?
Answer:
-I have done some work as a Business Analyst in my last job. People with different backgrounds worked on projects: accounting, administration, law, computer science, and me (mixed of computer science and communication). To me, it seemed like the two job profiles (TW and BA) are compatible. You write about the product, but you have more power over solving issues.
If you want to know if you are right for the job, you might find the following sites useful.
Business Analyst Skills Evaluation
http://www.waldentesting.com/infotechtests/other/busan.htm
eWeek article about Business Analysts (April 2003)
http://www.eweek.com/article2/0,3959,1023750,00.asp
I like this one: "Ideally, an IT business analyst is both tech-savvy and a great communicator because these two sides of a company often speak very different languages." Sounds like a job for TWs to me!
-If you're the sort of tech writer that pulls down $50/hr, an entry-level
business analyst job may be a step down. If you only make half that, it's
probably a step up. Depending on the size of the organization, there may
be more room for advancement as an analyst, and it's often a good
stepping stone to project management.I've driven projects from the Statement of Work that gets the contract, to
the software requirements specification, done the alpha testing, wrote the
test plan for client beta testing, and written the training materials and
the manual. The first two are really analyst-type functions much more than
tech writer functions, but being able to write clearly doesn't hurt any
there either.Most projects aren't like what I just described. I'm usually married at
the hip to an analyst to decides what the goals, the business rules, and
the functional requirements of the project are. Projects live or die
painfully based on the quality of the requirements handed to you by the
analyst. Where a tech writer just has to plan documents, the analyst gets
to plan the entire product.
Scene between Ace the mechanic and Danny the cop, from the movie _Running
Scared_ (as best as I can remember it, anyways...)
"Can you do something with this?"
"What, you want ray guns, missiles, oil slick, you wanna be James Bond?"
"I dunno, just... ...not this"
"Let me tell you what you want: you want to come and go like the wind, right?"
"Right."
"Invincible, invulnerable, invisible."
"And I want it Thursday at 9."
"It won't be invisible until 5."
That's a program analyst at work. The customer? They have no idea what
they want, but they know "it should integrate with our existing database,
solve all of our problems, and it should be orange". That statement is
completely meaningless, and it is the analyst's job to make order out of
that chaos. Suppose the system needs to take data from somewhere, do
something to it, and then put it somewhere else. Suddenly there's
three business rules: 1) Get the data, 2) magic happens, 3) output the
new and improved data. Then you look at those oversimplifications of the
process and start to break them down. Where's the data come from? What's
the data dictionary? Error-correction and sanity-checking? Will the user
need to review records and make spot corrections? You answer all of those
questions and a host of others, and pretty soon "get the data" is ten
pages of subparagraphs under 'functional requirement #1: import data'...
It requires a lot of the same knowledge that good technical writers
already have, but there's a further level of abstraction; instead of
documenting 'what is' or 'what hopefully will be soon', you're inventing
something based on what you think is the best way to solve the problems
the client needs solved - which aren't always the problems they _ask_ you
to solve - and then documenting it, and working with the client to ensure
that what you're doing is going to work for them.
