Since my promotion earlier this year, I have effectively been a producer for the live team in an online non-gaming environment. We have an existing application with customers and a rather large database. The backlog of bug fixes and new features has requests dating back to the day the current system went live. We have a small team of programmers and testers. We have development, test, and live servers. There is a development process, documentation that we seem to be keeping up to date, and programmers with varying degrees of “big picture” versus “get this off my desk as quickly as possible” views.
By headcount, most of my staff is the customer service team, ranging from answering phones to database maintenance (which is a higher level CSR function here). You find an exciting variety of problems when interacting with the customers. Customer service tools are very important; I wish we could spend more programmer time automating things CSRs do frequently, but we have crises and legal requirements ahead of wish list items. Based on the feedback of the customer service team, they are surprised that management is asking for feedback. My new division seems more divided and stratified than my previous one, but then it is five times larger.
All those things I have written over the years about process and organization and documentation and development cycles? I am now in charge of making sure those happen. My project for next week is changing our patch notes process to improve documentation and make sure the CSRs are fully informed about what is intended behavior and what calls for bug fixes. While I got the job because of my professional experience, my experience here may be just as useful.