The Process:
Tools Management
For the studio, I've been in charge of tools like Jira and Slack for some time. This included evaluating new incoming requests for improvement, monitoring and testing new developments in the given environment, fixing arising issues and composing an explanation or guide to help the users through the experience.
I do not consider myself to be technically talented by default, but that only made this journey more illuminating and caught my interest to grow in this area. It showed me a lot of the ways of debugging, user experience, and how these tools work on a deeper level than what you see as just a user.
Responsibilities
-
Jira Management
-
Slack Management
-
General on- and offboarding
-
Production Meeting Notetaking
-
Time Tracking Checks
-
New project documentation
-
Core Dev Team Management
-
Sprint Beats Schedule across the Studio
-
General Risk Management
-
Sprint Report Template
-
Miro projects clean-up
-
Purchase Request Workflow
-
Game Jam preparations
_logo_svg.png){kind=logo}
Core Dev Team Management
The Core Development team consisted of members that had a technical genius to them and somehow always managed to push the quality the team delivered even further, sometimes beyond expectations. It existed of technical artists, tools programmers, gameplay programmers and graphics programmers.
The technical complexity of their work had been a bit daunting, especially when more projects were being developed in parallel, though their autonomy alleviated much of that.
The work had been a challenge to plan ahead, due to unforeseen work, sudden implications, and especially the longevity of bugs that were in the process of being fixed.
Eventually the technical director, technical art director and I managed to get to a roadmap which we used as a guide to drive our priorities with enough buffer calculated in to facilitate surprises. In the end, it wasn't so daunting a task after all.
On- and Offboarding
When I was selected to be responsible for general on- and offboarding for the studio, I was not expecting much in terms of tasks, but it appeared that a lot of the processes quickly became outdated and needed a re-touch.
There were new processes required for things like integrated outsourcers (and some of them may require less or more information, depending on their time and the information's relevance to their area of expertise), new tools that we used or new workflows we adapted.
And most of all - a lot of people were necessary to be involved in the process, because even though I only worked on the more generic onboarding, it would be good if that eventually pointed to the more discipline-specific content and that was to be determined by leads.
However, most leads had been part of Vertigo for a while, and did not always need as much explanation as someone who has never worked for the studio before. So, it had to be thoroughly tested by people of all different experiences.
Time tracking
For a long while, time was being tracked through WorkTimer. However, it did not request the user to fill in their hours on a regular basis and when it did, it often was ignored.
Therefore, I was assigned to tackle the matter at hand through manual checks. Together with my lead producer we looked into automating this through Excel exports, but before we managed to finish that project, there had been a decision to remove WorkTimer altogether.
This posed a whole different challenge - how were we going to remove a program that holds all legacy data and was used to check our spending?
Though the challenge was imposing at first, it was also a relief; the program had long felt like a hassle, an extra on top of the team's upkeep in Jira. So, finally we were able to discuss how a software already integrated within the team could potentially serve for time-tracking purposes without overcomplicating the process.
Sprint Report Template
Upon the request of the lead producer, I was tasked to create a Sprint Report template to be used across projects to communicate across the team and to stakeholders how well the sprint had gone and how it could be improved.
This was an interesting project to dive into, especially thinking of data it would need without overcomplicating it was a fun challenge to take on.
Hence, I described the sprint goals - together with clarity on which were achieved and which were not -, whether any of the next sprint goals were at risk, and showed the Sprint KPI & burndown chart.
These obviously gave some very interesting insights and could help to determine trends across the different sprints, giving an indication on where we could improve.