This exercise is taking place entirely inside my head, since I don’t know any software company that actually does it this way. Also, since this is MY dream, everything has been set up for the convenience and peace of mind of a community weenie. But I admit… I’m being a bit disingenuous when I say that. See the question at the very bottom of this post.
Up to several weeks before the patch:
- I have been getting patch notes as work is completed.
- I am getting ALL of the patch notes, meaning a note for each completed task. The programmers and designers have indicated which notes they do not believe should be made public, and their opinions carry considerable weight, but the actual decision to post or not post is up to me and the producer. If we are not certain why the programmer or designer has tagged a note as Do Not Release, all we have to do is ask, and the answer is provided in complete sentences without the arrogant son of a bitch smirking and saying “because I said so.” However, I have learned over time that the response to such obnoxiousness is not “try again or I’ll punch you right in the junk.” If the person with the information is behaving badly, the problem is one of management – a manager is encouraging this attitude, and without fixing the manager, the problem will merely continue for the next thousand years.
- I have been translating the notes into plain English as I go along, and checking with the programmers to be certain I have not changed the meaning of the notes.
- When I see a note certain to cause drama, I raise the issue with the producer immediately. The item may require additional research, volunteer input, rephrasing, or outright removal. Honestly, sometimes people are working in a vacuum, and may not have considered the repercussions of their decision. This is rarely because the programmer or designer is stupid, but because he lacks the data he needs to make the right call. My job includes providing that data, if my company does not have many internal metrics. If I am lucky and my company DOES have those metrics, my job is communicating that information with the context of how the users behave. A community person serves the community – and a development team is as much a part of the community as the customers are.
Back to the potential drama. It might be best for the game if we just go ahead and kick the hornet’s nest. But even if I think the producer is forty kinds of wrong, my job is to advocate for change right up until patch day, and then to shut up and post it as though it were my idea. Unlike patch note phrasing (my job), deciding what things go in or out of the game is HIS job. My job may be eating bees, but I’d rather have it than his job, which looks to me like a combination of spreadsheets and pure political ass. Gah. Technically, you probably could pay me enough to be a producer, but I wouldn’t enjoy it.
One week before the patch day:
- I receive notice from the producer or his designated minion that there will be a patch at a certain time and date. I immediately post this information to the community in as many ways as I can, including but not limited to the patcher itself, my community web page, the product’s blog, and the marketing website. (The marketing website and the community website are not the same webpage, having different goals, different language, different purposes, and different people controlling them.)
One day before the patch day:
- I receive notice from the producer that everything is going swimmingly, and we will indeed be patching on the morrow. I immediately post this information, along with my best guess as to how long the servers will be down.
- I have learned that the programmer’s estimate means “actual server downtime” and he is NOT including the amount of time the servers will be up but not available to players due to testing. I have given up attempting to explain that all I care about is whether or not my players can PLAY.
- I have drawn my own conclusions as to how intelligent the producer is and added or subtracted time accordingly.
- I have cross checked the estimate I was given with customer service and QA.
- I may add an hour or two to the official estimate based on the patch notes, because certain types of changes have not once failed to break the servers in the decade I have been watching MMOs run patch days.
- The person in charge of taking down the servers was told in advance what time patch day festivities would kick off, and took down the servers on schedule. He made an in-game announcement thirty minutes prior to doing so, to take care of the players who do not read announcements on the patcher or the web. He did NOT learn about the patch from reading the company website, and if he did, the producer got punched in the junk.
- I hang out on forums, and I have forum moderators at my fingertips via IM. Forum traffic is insane, because the players who normally post during the day while they are at work are now joined by the players who normally play during the day. I have prepared a statement about why we do not patch at 4 AM on Tuesdays, why we always “screw over” the same group of players by patching at the same time every month, etc. I have already discussed this topic with the producer, and totally lost the argument, so the topic is closed. I made him help write the explanation, though. I cut and paste from this statement repeatedly.
- I address the drama-prone note to the best of my ability. A significant number of players mainly want to hear the explanation and be reassured that we didn’t just randomly nerf the most popular weapon in the game by 50%, but rather, we did it for valid reasons… such as the massive improvement we made to the statistic that had been so pathetic that everyone felt compelled to get that one particular weapon. This explanation is given a test drive first internally, then on the boards, and the final refinement goes on the website and added to the patch notes. Since the population on the boards is a minority of the player base, what is essentially a draft explanation is fine… but they’re so vociferous that they can hammer a piece of coal into a diamond.
- I do not collect any feedback whatsoever on patch day while the servers are down, though I might finish getting information from those who played on the test server. All other feedback being sent in on patch day is being based on what people think of my patch notes, not the actual patch. The development team does not need data based on anything but results.
- Two hours before the estimated time of return, I start asking questions. Hint: When the programmer in charge stares at me wild-eyed and cannot articulate a response, I add three hours to the estimate and post the new time immediately without pestering him for more information. I also post the reason for the delay. The truth is always better than reposting “we are working as hard as we can” fourteen times. If I have a producer who is not smart enough to recognize the value of truth, it is my job to attempt to compensate, and help the players to see that the developers are in fact working. This can be done by describing the process, the number of people working, or any other details that can be scraped up. I am the only window to the development team that the players have, and parroting boilerplate is not good customer service.
If I am not able to get the information I need, I take it up with the producer after patch day if he is frantic, and on the spot if he’s just sitting there playing a competitor’s MMO.
- If the downtime has wildly exceeded even my worst case estimate, I stop posting times and retreat into “as soon (TM) as possible.” I also stay on the job. It is vitally important to the sort of user who is camping the website to see changing time stamps, and proof that I will in fact post at 1:30 AM just to let them know the score. That user is disproportionately influential among his less-anal retentive friends. Also, once downtime has gone six hours or more overdue, the most senior community person is the one who needs to be posting, to prove to the customers that the company is serious. Staying on task during a disaster is why senior personnel get paid the big bucks. Well, buck, but compared to the rest of the team, it looks like a big one. Forcing a low level person to bear the load after bedtime is crappy, intolerable behavior, and that sort of manager should be punched in the junk.
- I announce the return of the servers, but I hang around for another hour doing shots with the exhausted and hilariously insane team. I’m still hanging out in case either a) the servers need to come right back down, or b) the servers are going to come back down the following day. Admittedly, if it’s 1:30 AM, I may go straight to bed, but the customer service team has my phone number, and they know they can wake me up to make a post.
After the patch:
- I gather followup feedback according to specific, scheduled benchmarks and present it to a producer who has not been drinking recently, and he takes action according to established protocols. Message board traffic is only one data point, and used as supporting, NEVER primary, evidence.
That is my selfish, selfish dream. Well, in a DREAM some of those steps would be skipped and we’d go straight to doing celebration shots because the servers are up on time with no trouble, but even on a bad patch day, communication and teamwork can go so well that I think I’m dreaming.
Here’s why I dare to dream: Which of those steps in my dream would not be in the best interests of the producer, the development team, and the customers?