Like a favorite pair of sneakers or an ideal life partner, I’ve been falling increasingly in love with Google as time passes. From my new Android phone to the recent improvements in Google Maps, the world seems to agree that they’re a company still on the rise.
Over the past few years, I’ve also been using Google Spreadsheet (part of the Google Docs family) as my project management tool of choice. It’s quick, simple, and particularly useful for sharing project status with geographically distributed teams, which is becoming more and more important in today’s global workforce.
Few topics stimulate the troops and drive such rousing conversation around the office watercooler as software development process discussions. I decided to address this topic in my first blog post, not for the cheap emotional thrills, but more as a foundation to lead into future posts on product design methodology.
After having spent about a year-and-a-half with the web team at DIRECTV Latin America, I started to notice that different projects were being managed and developed in different ways, with no standardized process used across teams. In some organizations this might not be a problem, but in our case, many of our resources were shared between teams, and the different processes were causing confusion and frustration. To make matters worse, there were a few examples in which important steps were being skipped accidentally and products were being released with issues. For example, business owners would ask how a recently launched site was performing, but since a web analyst had not been involved in the project, the correct tracking tags had not been included and important goals were not being tracked. That type of thing.
After a couple such incidents, I decided to try and standardize a development process that could be agreed-upon and used by all teams. I created the above diagram to help formalize and communicate the new process.