It's a very fun job and I'm struck over and over again by how my background in game design has helped me acclimate to the position. Here are some reasons why.
Playtesting and feedback help a person let go of the prideful notion that they are going to get things 100% right without having to go through iterations.
Business Analysis is a very iterative activity wherein something that seems to make sense after a meeting with one set of SME's doesn't actually hold muster when looked at by a different set of SME's who find holes that the first set didn't know about or consider. This can be a very difficult prospect for someone who takes a lot of pride in their writing (such as myself) wherein one works really hard on a document only to find out in short order that most of what was written needs to be changed. This requires a certain amount of patience that I've had to learn via putting prototypes out for playtesters to critique. This leads right into my next point.
Accepting that prototypes are essential in getting proper feedback helps one realize the importance of creating documentation that people can react to.
This is an interesting lesson as I've learned how important it is to actually write up drafts to get the feedback I need. It's not enough to just explain something to someone. Once an idea is in the form of a document, people can react to it much better and see things about it much more clearly - not only what's right, but also what's wrong. This hearkens back to the notion in game design of how some designers are reluctant to build a prototype. They are content instead to hang on to their idea, just tell people about it, and then believe that the feedback they are given off of their idea description is worth much more than it actually is. Don't get me wrong. It's not worthless, but it's so many levels removed from the truly effective feedback that comes from people who are actually trying to experience a game rather than just listen to a description of such.
In many ways, it's the same thing with Business Analysis. One has to go in and create the process flows, write the user stories, create the context diagrams, and do many of the other things required to document the intent, vision and specific requirements for a software project before one can truly get feedback from others about what's right and what needs to change. Accepting early on that one is writing a particular draft of a document as a means of getting additional feedback is so much more effective than approaching each draft like it's going to be the last one. One attitude is very receptive and welcoming of feedback while the other sees feedback as a threat to one's ego.
Explain things clearly - but succinctly.
In documenting software requirements, one has to explain things clearly to an audience who has not done all of the research and gotten into the guts of the project like a business analyst might. In the same way, a game designer has to write a rule book explaining his game to someone who hasn't been involved in the many iterations of the game's creation. The person reading the rule book only knows about the game what the rule book explicitly lays out.
In writing requirements, it's funny how many times I'm reminded that I need to spell something out. I'm also reminded of how much one has to leave fluff out of it so the reader's patience isn't exhausted.
This is one area where I made a mistake in writing the rule book for Heavens of Olympus. I approached the rule book like I approach teaching a group of people how to play a game. In explaining a rule to a table of gamers, often a brief thematic explanation of what the rule is trying to represent goes a long way in helping the group remember certain specifics. However, in writing a rule book, taking that same approach actually hinders the reader's ability to get to the essence of the game. It comes off as fluff, tries one's patience, and the comments on BoardGameGeek tend to bare this out about how I made this mistake.
Test boundaries and think about extreme scenarios.
Game design forces one to think about all the wonky ways a player might try to approach a game. In so doing, it forces one to consider extreme scenarios that might actually break a game. Software development and requirements gathering can be very similar. Thinking about all of the possible ways a particular software solution can play out helps one see much more quickly where certain danger paths might be.
Conclusion
I feel like there are many corollaries with my new career and what I've learned from my game design and playtesting experiences. I also had a job for a time of being a software usability researcher and I found that tied in very neatly with certain principles of how to make a game more accessible to a player in terms of layout and presentation. When I have more time, perhaps I'll come back and revisit that connection in a future post.
