Get best of the week

IT management model in one product company

If you became a leader in IT, then you have big problems - it’s rather difficult to find the described models of production organization and KPI's set for CTO and CIO. The task of any manager of any industry is to monitor competitors, “state of the art” - examples and bring best practices to your company. From my own experience I’ll say that you will have to create a circle of friends and share examples with other service stations in bars, at meetings, reference visits, and conferences.

image

On Habré I could not find content about management models and metrics, but it really is not enough, so I decided to share my experience.

Let's start by answering the question why our company is responsible for service stations:

  1. Team. The service station is responsible for selecting and retaining a strong team of engineers, as well as for their involvement.
  2. .IT- , , .
  3. . , IT- , .
  4. . IT- IT – , , , .
  5. . . , CISO ( – ). IT- .

Now let's see the metrics that will help you see the picture of your responsibility. Somewhere metrics are derivatives, because measure directly will not work.

1. Team


Metrics


  • completeness of IT functions. What for? The answer is that due to low staffing, the impossibility of fulfilling the planned tasks follows. The priority of hiring is set strictly according to the staffing indicator. The lower the staffing level, the higher the priority of your vacancy for HR. Everything is simple.
  • "Fluidity" in the context of functions. What for? A high / growing staff turnover means that you have a poor team climate, problems with processes, or wages. Cluster problems will help exit - interviews with employees.
  • Percentage of employees arriving on recommendations from current employees (referral indicator). A growing percentage suggests that your engineers like to work for you, they are ready to recommend your company to their close people and just acquaintances.

2. Architecture


There is still a field for experimentation. But still:

My metrics


  • Architectural deviations. What is it? Architectural deviation - you have found on production an implementation that does not meet the approved architectural standard. What for? IT landscape is a huge interconnected system that must work according to the rules. If you do not follow the rules, the system simply will not.
  • PageSpeed Insights -. - . ? . – , , Google -.

3.



  • - .
  • TOP . ? , .
  • TOP .? , . «» , .
  • Crash-free .

4.



  • IT – — , , . ? , Gartner, IT . . , , , , . , , overpriced .
  • TOP . ? . , , , .
  • -% .

5.



  • /. ? , , .
  • SLA .? , , IT — , ...

The reader may ask, “But what about such important metrics as the time that market, the number of automatic deployments vs the number of manual, something about the density of pull requests?” The answer is yes, they once looked at them, now they are not relevant for us. This is normal for metrics, each has its own life cycle.

Now let's move on to the features in IT in DomClick. I will not quote classics with their “development, implementation, maintenance, operation” - I will describe functions at a different level of abstraction:

  1. Product Development. Teams that create products through the sale of which the company receives the main income. There are mixed business and IT teams. There are ROs and CJEs that answer the question “what to do” and “what priority”, engineers answer the question “how to do”.
  2. (ore). , «» . , , , API Gateway, , ..
  3. . , – , , .
  4. - (Web Core) , web- , UI-, .
  5. . - : , . «» , , , . — .
  6. . , , , , , k8s, .
  7. DevOps. . .
  8. . , IT . , , .
  9. R&D. , . - VR/AR, , -.
  10. . , IT- . , (, , ) . , , , - IT .
  11. IT . ( ). IT — . .
  12. Data Science. IT DS RecSys ML. OCR NLP – , , - . , OCR. DomClick.
  13. . , . , , .
  14. . , , , scrum

The layout of functions in DomClick looks like this:

image

In my spare time, I recommend reading an article by our head of internal and core services development, as well as an article by an engineer from the Infrastructure Development and Maintenance division . It will be a little clear what the guys are doing.

A function is not necessarily a large team of people. Some functions may consist of one person, but they must be, someone must solve this problem. Perhaps at first, you yourself.

The layout of these functions is left to your discretion, because it depends on the competence of your employees. I will give only two tips from personal practice:

  1. . , . , - k8s , - , - .
  2. , . – ore , . , .

We have interesting distinctive features that greatly simplify the work and level conflicts over the issue of priorities. You remember that IT, in addition to creating and selling products, it is also necessary to switch to new versions of API-related products, conduct refactoring, eliminate vulnerabilities, and analyze root problems:

  1. Each team devotes 20% of its time to the engineering quota. In this quota, we try to solve all the above problems and do research if time is left. Important: 20% do NOT include cybersecurity bugs and blockers, they are eliminated due to the food quota.
  2. Large areas of product development (several agile teams work on one product) have their own small platform team, which generally ensures that the "caftan does not leave" and solves only the engineering problems of this product.

Finally


  1. – , .
  2. , .
  3. . , IT 2020 , - (Web Core), R&D, — 2019.

More articles:


All Articles