There are such things in the world - they are called 1C franches. These are partners of the 1C company who sell its software products, help to implement and operate them, and are able to modify them according to the needs of the customer. So, these franches have gone through a rather funny transformation over the years.
Previously as it was. The client had a problem - he called in franch, a programmer came to him, figured out, solved the problem. Either on the spot, or he took it with him and returned with a decision in a few days.
Now this almost never happens. In most cases, you will have to work with three funny characters - a bubble, a straw and a bast shoe. Consultant, analyst and developer.
As it used to be
In a nutshell, I will explain who previously worked in franchises. At the dawn of justice, when franches appeared and grew, two types of people came to work in them - programmers and accountants. Programmers, as a rule, were graduates of universities in the relevant specialties - either direct programmers (such as applied mathematics), or engineers who also studied programming (such as the Faculty of Instrumentation). Occasionally we came across smart guys from technical schools and self-taught. There were almost no random people - so, as part of the experiment, they took, but quickly kicked out.
The programmers, of course, experienced a culture shock from the first months of their work in Franches, because I had to communicate a lot with users and understand subject areas - accounting, production, trade, payroll, etc. But, being intelligent people by nature, they coped with new knowledge quickly enough. In addition, the 1C platform was created to solve business problems, therefore it contains all the necessary abstractions - there was no need to invent how to organize the principle of double entry in a bare DBMS, all the necessary types already existed.
Significantly less often, and not immediately, accountants came to franchises. In fact, these are former clients of Franch - smart girls (well, it's not my fault that accountants are mostly girls) who knew the theory and methodology, and then managed to figure out 1C programs. So they decided that this knowledge and skills could be sold for more than a salary at a factory or in a beer stand.
At first, the Franches did not know how to use these girls and tried to make programmers out of them. But they quickly realized that there was no point in this - it was their knowledge and spiritual relationship with users - the same accountants - that needed to be sold. They called them consultants (or simply cons), and began to load them with relevant work.
They shared something like this. Cons does the methodically complex work, the programmer does everything else, including programming. The projects were attended by both, for synergy.
Somewhere in the process, paladins appeared - programmers who were very well versed in accounting methods. As a rule - accounting and management. These could do almost anything.
The cons were of high quality for one simple reason - they came from the profession for which they were going to consult. Accordingly, it is easy to explain why francs still do not have a single decent cons, for example, in production - not a single successful production worker has yet thought of going to work in francs.
Everyone was satisfied and happy, but the market was growing rapidly, and there was a sorely lack of specialists. The flow of programmers from universities who would like to work in 1C was less than the market demand. The flow of sensible accountants has almost dried up. the profession has almost died out: a modern young accountant with an education is, in fact, a 1C operator.
Without thinking twice, they did the same as the whole world of programming with a shortage of resources - they lowered the threshold for entering the profession. This is where our characters appeared.
Now it's not a programmer or an accountant who comes to work in franchise, but just a person. Who will come out of it is decided in the process. A kind of kinder surprise.
Consultant (bubble)
Kons are now called people who more or less figured out some 1C program. For example, in accounting, or salary. Let me emphasize - it is in the program, and not in the methodology underlying the program. Some of the methodology, of course, in the process of studying the program, they learn, but not in details.
They are saved by the fact that users have also ceased to understand the accounting methodology. Previously, they talked between an accountant who did not know 1C well (from the customer's side) and an accountant who knew 1C well (from the franch's side). Now two operators are talking, it's just that one was poking into the program longer.
Consulting is also carried out by typing. The user asks a question, such as "why my transport does not close to zero?" An early cons would simply say that this is what the legislation says - if TOR are not included in the cost of the goods, then they are closed in proportion to the value of the goods sold. The current cons says "I'll call you back" and goes to the program and look for an answer on the Internet.
Such concessions especially enrage chief accountants, finders, chief economists, commercial directors, etc. - those still from the old school, and the position obliges to understand the profession. If earlier they could talk to the cons in their own language, identify the problem and hear the solutions, now they are simply "removed from the problem" - roughly speaking, they take notes and stenographed their words, so that later "think" and poke around - into the program and the Internet ...
The funny thing is the result of the work of the cons. In most cases, it sounds like "you need to connect a specialist." This is either an analyst (straw) or a developer (bast shoe). True, you have to pay for poking the cons.
Developer (bast shoe)
The 1C developer is a rather strange creature. There are several legends about how these animals appeared on our planet, I will write a separate article about this.
The bottom line is simple: a 1C developer is a piece of a 1C programmer. The piece that can write code. He does not know how to talk to the user, does not know how to come up with the architecture of the solution, does not know what will be affected by his improvements, does not know accounting methods. He simply writes the code on the assignment that was written for him, specifying the names of tables and metadata, scenarios of behavior and user interfaces.
There was a time when 1C developers were very tormented by the question of how they differ from 1C programmers. Being a piece of a specialist is not interesting, so you needed bright, understandable, well-packaged differences.
The first find was "development standards". The beauty, however, is that these standards were drawn up by programmers - from the experience of the pioneers. Accordingly, the programmers had these standards in their blood, and the developers had to learn them.
The second find was the library of standard subsystems (BSP) - a large set of basic functionality for any 1C program. Guess who made the BSP? The same programmers, on the same pioneering experience, when they are tired of carrying around a zoo of different options for implementing the same thing (such as authorization, working with mail, reporting mechanisms, etc.). Developed, respectively, all sat down to learn.
Well, the third find, or rather a whole bundle, was thrown by the Internet. And not only for developers of 1C, but also for everyone who relates to IT. This is a wide range of beautifully packaged techniques for anything pro-IT, like devops, scrum, technical debt management, scenario testing, digitalization, BI, bigdata, etc. The percentage and quality of application of this knowledge in real life for 1C developers is about the same as in the big IT world - something around zero.
However, no one will ever ask for the real application. It is enough to say "I know development standards, BSP and devops" - and you are a 1C developer.
So, a developer is who writes the code. The developer also knows how to "find a place in the code" - this is when he helps the consu. Cons applied the poke method, could not figure out the behavior of the program, "attracts the developer" - he goes into the code and tries to understand what the checkbox affects, what the button does and why everything is red.
True, the developer and the cons do not understand each other well. When a developer finds a place in the code, he can explain its meaning in terms of PL, objects and types, but the console does not speak this language. To talk, they need an interpreter, a straw across the stream of misunderstanding - an analyst.
Analyst (straw)
An analyst in 1C is also a piece of an early programmer. The piece that knew how to understand the structure of metadata, algorithms and processes of data movement, settings, solution architecture and, most importantly, make changes to it.
The "analyst" piece was present in the solution of almost any task that a 1C programmer did. This is as much a part of the problem solving process as testing, writing and debugging code, demonstrating to the client, etc. It was as natural as writing code with your hands instead of your butt. Therefore, it never occurred to anyone to pack the 1C analyst as a separate product.
There are two types of 1C analysts - "it happened" and wow.
Wow - this is when an early 1C programmer who understood the essence of the moment was retrained as an analyst. Developers and consoles appeared, which could not agree either with the client or with each other - accordingly, a gaping, unoccupied niche was formed. Some of the 1C programmers went there - a familiar, simple business, and in view of the blue ocean - very profitable.
It Happened as new analysts who grew out of handymen, economics-law students-managers, elementary school teachers and former Mac employees. The ones who just came and got a job in the franch. Some have "grown" into consoles, others into developers, and still others - into analysts.
The difference between today's cons and analysts is ghostly. This is clearly seen when you read the TK, compiled by such an analyst - the words are correct individually, but in total - such nonsense that it is scary for the country's economy.
Although, I think, you shouldn't worry, tk. the degradation of specialists is quite balanced by the degradation of users. More precisely, the degradation of the customer's specialists into 1C users.
How it works now
Now the process of solving the problem is arranged something like this. The user calls, goes to the manager. The role of this character has not changed over the years - he will either switch, or carefully record the call and pass on. Then the console sits - he calls the user back, and together they poke into the program, trying to solve the problem right away.
In 99% of cases, nothing happens, the console promises to call back and goes to the program on his own. When he gets bored, he calls the developer and asks to “find a place in the code”. The developer pokes, only into the code and metadata, finds something, tries to explain to the consu - a misunderstanding arises. The name of the analyst.
The analyst listens to both of them, often calls the client again. Then he delivers a verdict - revision is needed (thanks, cap), you will have to write TK. The information obtained by the cons and the developer when solving the problem is thrown into the trash heap. the analyst cannot afford to use non-professional data. The client, however, will have to pay for the "task analysis".
The analyst writes the TK, going all the way over again. He agrees with the client, gives it to the developer for implementation and removes himself from the process of solving the problem. If, or rather - when the developer has questions like "will this work for sure?" or "and the client seemed to be talking about something else ...", the analyst will say "shut up and do it."
The developer will do it, the cons will go to take it. It turns out that it is not that, not so, and not for that. Football for four will start - client, cons, developer, analyst. Everyone is reluctant to again delve into the mistakes of colleagues, but everyone wants his work to be paid. The client, however, does not want to pay for the lack of results. But somehow they get out of the hole - either by joint efforts, or with the help of a 1C programmer, who will give everyone a slap on the head, call the client and solve the problem.
So, stop, where did the 1C programmer come from?
1C programmers
And they were still in the bins. True, in very small quantities. Most fled from the profession, but remained in the industry.
Someone created their own business (the same franch), someone does projects in one, someone sat down at the plant as a CIO, but many remained in francs. Those that remained work, as a rule, as project managers, less often as department heads or analysts, and even less often as programmers.
And an interesting tendency is observed - the reciprocal attraction of customers to 1C programmers. Magic works flawlessly - if the client has worked with a bubble, straw and bast shoes, and then talked to the programmer (yes, he just talked), then he flatly refuses to return to the Russian folk tale.
But the client has no choice, 1C programmers are a piece product, they are rare and expensive. True, following the backlash of customers to 1C programmers, there are corresponding trends in the recruitment and training of franch personnel - the laws of the market are in effect. I did it too, looking at unhappy clients. I don't know where this will lead, whether it will somehow affect the market and the quality of services - I really hope that everything will work out.
Well, I didn't just write a fight - I really love this job. And I worry, looking at what it turns into. Otherwise, soon there will be no one to talk to - only bubbles, straws and bast shoes.