Wednesday, February 8, 2012

Design to Product on Android - Risk Management (6 / 17)

In Software Engineering, one of the evil parts of making products is the Project Management aspect of the whole thing.  Ya know, the guys that always tell programmers what they can and cannot do; as well as how everything was due yesterday.

Well, as a small software shop, we have the luxury of being our own managers, for all its amazing glory, and huge amounts of risks.  Everything you do and plan for needs to be evaluated for risks, especially in software.  Even the smallest feature can take weeks to accomplish!

Before designing a game, think heavily about what features should and should not be part of a product.  Yes, it would be great if a game was a simulated virtual reality, or interacted with websites, or touched on databases all over the world to present a real time view of the world in to your digital dream of a game... but all these amazing features have tradeoffs in terms of time involved to make it happen, and problems testing/debugging.  Everything remotely complicated can take large amounts of time to make, and even sometimes simple things turn out to be a lot more complicated than originally planned.

Good project managers have a wide understanding of programming and should give lenient amounts of time to get anything done on software projects.  If this person is you, the rule of thumb is to take any time estimate for getting anything done and multiply it by 3 and that's probably more realistic.  As the manager gains more experience with more varieties of software features and products, their "expert opinion" will likely become more accurate over time.

But I digress, let's focus back on the Risk side of things.  This aspect of the software process is fairly complex but essentially boils down to assessing what is and is not an acceptable risk to take.  This can apply to lots of things, but for our sake, we will focus only on the risk of adding features to our small software project.  Throughout the development cycle, risk assessment and reassessment will happen, so this isn't like we can just up and say "yea, I'm done figuring out the risks for this project".  However, having a good place to start couldn't hurt.

Projects do not need risk assessment, but it sure can save you a lot of time, effort, and headache in the long run.  Unfortunately, it usually requires a well-experienced project manager to make this really effective.

At any rate, things you will want to assess for risks, specifically for games, is what features are worth the time investment.  In other words, what features MUST be in the product versus what features would be nice to have.  There's kind of a 3rd category also, what features can wait for a future patch/release... things that really should exist sooner or later, but can wait.

When considering features that must exist in the product, assess features worth the time involved to make, or can the design of the game change a little bit to cater to time constraints (budgeting, investors, your boss, bills, etc).  There is nothing worse than developing a feature in a product and realize halfway through that you will run out of money or time making it happen -- worse yet, your business may have already paid for supporting services and resources for that feature (art, music, etc), and now you might have to scrap or change the design -- huge waste of time and money.  This is why assessing risk is fairly important, it is an attempt to mitigate as much problems as possible before dumping a lot of effort in to things that really might never make it through to the end of the day.

Did I mention risk management happens throughout the project?  I did?  Let me say it again here, this should be a constant nagging during software development, not enough to drag you down and admit defeat before you start, but should be just close enough to have you on the edge of your seat.  Never be too proud to admit defeat (just 3 more weeks to get this done, I swear!).  Always think about how long things will take and, well, assess if it is worth the time and bother.  At the end of the day, is your hard work worth the risk of ultimately getting money for your efforts?

A specific example to watch out for -- "wow, this anti-aliasing on this button is so awesome cool, but it took me 4 weeks to make happen".  Yea, users will love that their button looks all slick, but if it took you 4 weeks to make happen, that was a lot of time wasted that could have been spent somewhere else!  But don't worry, you have a slick button... and 3 weeks of lost time to play happy fun make-up crunch time with.

"Uh, yea, we're gonna need you to go ahead and come in on Saturdayyy, mmkay... oh and, I'm going to have you come in on Sunday too".  Yes, it was from Office Space, but really, that is what is going to happen if you have to play catch up.  Risk management isn't the magic bullet (nothing in Software Development is) to solve all your problems with time management, but it sure can help give a better perspective on what is and is not important enough to dump a lot of time and money on during the whole ordeal.

No comments:

Post a Comment