Hello. This is Osaka from the Webmaster Support Department.
It's been almost a year since I moved from the Coding Factory Department (hereafter referred to as the CF Department) to the Webmaster Support Department (hereafter referred to as the WS Department). I'm still absorbing a lot of new knowledge, but every day I realize (or am I painfully aware?) the difficulties and joys of running a website.
What is the difference between the normal "web production" that was originally done by the CF department and the "operations" handled by the WS department?
In this article, I would like to introduce some of the more difficult aspects of operations work that I have noticed after working in this field for a year, as well as the ideas I come up with when creating operations.
The most difficult thing about operation is "prioritization"
Basically, what I do is the same as when I was in the CF department. My scope of work includes both "direction and coding." However, the big difference is that each task is very detailed and the speed required is fast. In normal web production, you just have to quietly create the number of pages ordered by the deadline, but in operations work, there are situations where you need to "change the specifications by the day after tomorrow, so I need a quote by today," and you have to prioritize responding to those requests even if it means stopping your planned work.
It is particularly difficult to decide which task to start with, and if you are only working on high-priority tasks, you may not be able to get to the tasks you had originally planned, which can be troubling. On the way home late, I often have a self-reflection session in the car.
The biggest difference between production and operation
The biggest difference between how we work on regular web production and operational tasks is that we have increasingly started using backlog (a project and task management tool) as our main means of communication.
I have used backlog since I was in the CF department, but I only used Git to share production files with customers, and mostly used it as a production aid, such as email for basic communication. However, now it is not uncommon for all communication to be done through backlog.
I feel that the response and response speed is much faster than with email.
First, at the beginning of each day, I line up the backlog of projects and check which ones are addressed to me and are unread. During the day, when I'm coding and checking the operation of my code in Chrome, I make sure to check the backlog notification whenever it comes up. This "checking each time" is very important for operations, and it's a big change from when I was doing regular web development.
In the evening, when all the backlog notifications have cleared, it's a moment of relief and I think, "I've worked hard today too."
When the unread message sign appears on backlog, I check it immediately.
What is important to me in production
There have also been changes in the way the site is operated. There are two things that I value most when operating the site.
1. More can be gleaned from the code
Due to the nature of the operation, we have been coding by reading from existing code more and more. This is a big difference from normal production where we create a page from scratch.
When I'm coding, I sometimes think that the process of checking this code is similar to my favorite method of arranging shogi games. Arranging shogi games is a learning method in which you follow the steps of a shogi game (a record of the moves made by players) and then rearrange them to consider the intention behind them.
Both game records and coding data are merely strings of symbols, but I find it fascinating how they reveal a human element that makes you say, "That person wouldn't write it like that."
When it comes to coding, I sometimes read from the code and proceed with the production, such as "This is written with the assumption that the slider JS will be inserted," or "There was a place on another page where I coded using the same class naming convention...it wasn't in the module collection, but if it's just this part, let's check to see if the style is written so that it can be used generically."
2. I've started thinking more about where my products will go
For example, when producing a landing page, it is important to focus on the specifications of the page and proceed with production, but when it comes to operation, it is even more important to "anticipate what will be expected when this page is put into operation."
Anticipating the work that will come next, I try to make the ball (volume of work) as small as possible for the next worker, saying things like, "With the code we have put together now, it looks like it will be a lot of work to make detailed updates. If we continue to update this page once a month, it will take too much time, so let's suggest replacing the image parts with device text."
It may be a small thing, but I feel that carefully accumulating these kinds of things is important for operation.
As part of the operations team
I often work with designer Asada to discuss how things should be displayed on web pages.
I felt like I had only just begun to climb the huge mountain that is operations, but just the other day a fellow member of the WS club told me, "Osaka-san, it feels like you've been here for three years already."
I'm not sure if this is because it brings stability or what the intention behind it is, but I felt happy to have been recognized as a part of the operations team.
I want to keep working hard so that next time, customers will say the same thing to me.
モノサスアーカイブ