About IT business and not only
All good new year!
Colleague, you in the article well identified key problem points that you can meet in the IT (and not only) business.
But an objective assessment and recommendations for each of these points ("what actually happened, and what to do") is a question that is debatable.
// By the way, the same goes for your previous article.
You talked about a graduate of the VMK, who easily scattered your team leads and went to California, then the traces are lost.
This is a well-known story from Soviet times, when the factories did not like hot graduates who did several standards per unit of time.
They didn’t like it, because "that today is a feat, tomorrow is a plan."
Tomorrow, this graduate will leave for California, or will overgrow with family and mortgage, and will turn into the same non-catching team-lid mice that you fired because of him.
You stepped on a rake, and you didn’t notice a blow to the forehead.
This is irrespective of the actual quality of those team leads (depending on, their dismissal was either your mistake or they had to be fired not in connection with a graduate of the VIC).
You write about the business, but the business is not about shock exploits alone in a single task, with a high bus factor.
Business is about solving large-scale tasks by a team that moves slowly (yes, with such team-leads as you have, with employees who think of taking their offspring-pick-ups to kindergarten, etc.), but surely as an icebreaker, and irreversibly sweeps away everything in its path and with a high degree of probability reaches the planned results.
According to my colleagues who studied this question, the task that one motivated genius-rockstar will do in N time, a team of five people will do in 3xN time.
And I think this assessment is adequate.
Note that the final appreciation will be about 15xN - because you need not only to pay 5 salaries, but to pay them 3 times longer. And this does not include other expenses - a large office, more computers and other expenses.
But this is a team. With proper management, it is guaranteed to come to the planned result.
And, if we are talking about business , the team is on the shoulder of the task in terms of volume and scale, with which the loners can no longer cope.
That is, for the most part you write "no matter how you are treated, wipe out, draw conclusions and move on."
Let's talk about the rowers
Apparently, we are talking about developers (programmers) and in part about QA-engineers.
Recently, developers are fashionable to compare not only with the rowers, but also with the workers "at the bench."
Let's see if this is true.
To begin with, the developer is an engineer, and the worker, even the most qualified, is the worker.
And this is a fundamental difference, from which everything else follows, up to 180-degree differences.
Can the developer replace tester, analyst, PM'a?
Tester - easy.
Create test cases for your code, all "call out" and write autotests.
Moreover, the developer still writes unit and integration tests.
Yes, it will be a little worse, because The author will test his code with a curious eye (but you can give it to another developer).
Analytics - if not easy, but easy.
For part of the developer's training course is precisely the study of the subject area, problem statement and modeling. And unfashionable now OOP - and at all about "it".
PM? Well, if the developer is more or less able to look at the tasks from above, is more or less sociable and generally friendly with his head, then, if there is no experience, then with difficulty, with less quality, but he can.
Is reverse replacement possible? Especially if we are honest with ourselves, and we recognize that testers, analysts and PM mainly go to graduates of technical universities, who openly “do not pull” programming (and lately, “go into IT”) hand, and it is on these positions, in the development of the unit-exception comes)?
A tester - with difficulty, starting, most likely, from a junior position, from additional study of languages and development platforms, development patterns (rather than testing), Computer Science in general, a paradigm shift in thinking, but it can.
In other words, it can, but not everyone, and with very great effort and expense.
Analyst? If there is a background in part of engineering education and work, it is likely to be able, but less likely than a tester.
Because with the rare exception of strong analysts (and indeed analysts , not “analysts”), those who have not mastered the development go into the so-called analysts.
And the fact that development requires a certain psychological warehouse (introversion, perseverance, high concentration; yes, now there are attempts to remake the industry, so that, on the contrary, hyperactivity is needed, but including this problem we are discussing), and modern ones analysts "in this sense are clearly farther from developers than testers.
And in general, the concept analyticsThis is not about the role that was called "analytics" in modern development processes.
In other words, no more than yes.
PM? As the saying goes, "no time to explain." With a high degree of probability there is no, with really single exceptions.
And if we are not talking about the system, when the company purposely grows PM / line managers from developers, not from testers and analysts.
But in the case of the factory and workers, the situation is rather a mirror one.
By and large, if you send a director, an accountant, a marketer for a 3-month course, then somehow, they will be able to replace a turner, a welder, a locksmith of the initial discharges.
But can a worker after 3 months of course replace these roles?
It is possible that a highly skilled worker will be able to replace an accountant (not the main one) after the courses and reduce the flow rate with the loan and transfer funds and funds between accounts (will he be interested in that is another question).
Director, marketer, etc? There is clearly more difficult, if not to talk about obvious exceptions.
If anything, the reasoning above about different professions and roles is not to elevate someone relative to others, and vice versa.
This is about the fact that there are certain roles in the production process, and about the objective value of each role, which is determined, including (in) substitutability by representatives of other roles.
This is about the fact that all these fashionable conversations in recent years about "rowers", "developers at the machine" - this is just a systematic attempt to downplay the role of developers.
Those who move this topic will end up with nothing, for there is the nature of things from which everything else flows. A developer is an engineer , not a rower or worker (with all due respect to the latter).
And sooner or later, everything will return to normal, because it cannot work any other way, or everything will break when everyone leaves for QA, analysts, PM'y, and nobody wants to go to the developers (and no one will ).