IT bureaucracy
It seemed in 10 years already all the bad things happened to me, but no, every time you come across new and new cockroaches, and it is still unclear which of them is more unpleasant, large and fat, or small and numerous.
Unfortunately, the further, the more I come to the idea that the main problem of development in Russia is the inability to put and adjust the process. And not even the inability, but simply a misunderstanding of the process itself. When you do not know how - it is easy to learn. When you do not understand, but you think that you understand, everything is much more complicated.
A frequent mistake of management, and those people who influence the process in that they believe that everything is simple. That the process of creating software is not much different from the process of building a house. What the Tajiks caught up with, gave them a foreman, a foreman a plan in hand, showed where the plan has the top where is the bottom (so that instead of the lighthouse a well did not work), that's all, get ready to cut cabbage.
But over time, they understand that for some reason it does not work, or it works poorly, or it does not work as it would be desirable. The search for the cause of this state of affairs begins, but it is not the cause that is the consequence. The investigation is confused with the cause and the fight with windmills begins.
')
What am I talking about? No, they did not take away my LJ, didn’t turn off ICQ. But there are worse things. And they are worse because they are not so noticeable that they are not so striking. These are the rules and regulations.
As an example of the harm to the bureaucracy, we don’t need to go far; we all remember our recent past and see the present; it’s not for nothing that the word bureaucracy ’has become a negative connotation. Our officials, the distortions of the Soviet (and modern) system tried to correct with the help of laws, decrees, certificates, orders and other red tape. Not from the good life, but from the misunderstanding that the root of the problems of the system is not in the absence of rules, but in the system itself.
This is reminiscent of a situation with an old or poorly built house, when instead of building a new one, the supports and stretchings are attached to the old one.
But not like this! You can not cover your own incompetence paper. This only exacerbates the problem, creating the appearance of work, the appearance of the result and the appearance of the process. This is a lie! Nothing gets better, just another backup appears.
Do not be afraid to admit your incompetence, and what's more, without this you can never learn anything. As someone correctly said, “only a smart person can say" what a fool I am, "only those who want to learn and want to understand, can admit that he does not know and does not understand. And the one who does not want, he will assure himself that he already knows everything, and all the problems from the fact that they do not follow his rules.
But in general, the bureaucracy is an example of the fact that it is impossible to climb on a tree and not to tear your ass. Bureaucracy, regulations, rules and procedures make the system as strong as a tank, but just as slow and cumbersome. And thus we lose its effectiveness and flexibility. If you are a defense plant, then it is probably worth it. It’s better to make a rocket for 10 years, but when she flies, wow flies! But business needs efficiency. The more efficient you are, the faster you occupy the markets, the more you earn money. Well, it is impossible, at least in the field of development, to create an effective system with the help of regulations. That is why agile development techniques first of all minimize paperwork. Either one or the other. Either reliability or speed and flexibility.
But the bureaucracy lives on. It lives because bureaucratic mechanisms are simple and do not require analysis and a deep understanding of the problem. They are equally applicable to everything, and equally ineffective, but they give a visible and most importantly understandable effect. And the fact that they give a lot of side effects that are not so noticeable, and may not manifest for a long time, is not so important, no one will understand that the next problem that got out is the result of a diseased system. Giving a visible effect immediately, the insidious bureaucracy does not cure the disease, it, for the time being, drives it inside.
Well, for example…
We have a so-called test bench, which includes a server with VMware, on which you can create sandboxes for any developer needs . The test bench was specially created for this, and the virtual machines themselves are rather isolated from each other. But in order to create a virtual machine, you need to fill out an application. The application is only in paper form, and must be certified by the signature of the head of the department.
An interesting story with the test bench itself. TK was written for several months (three or four), several approvals passed, signatures from the heads of different levels ... three months to create a TK for a system, the implementation of which will take 2 weeks to do!
Even names in SVN, we now obey some rules, entered some prefixes, existing users must be renamed. Little things of course, but when there are a lot of such trifles, when you come across them there, where you didn’t think, when your plans collapse just because again somewhere you have to sign something, and paperwork sometimes takes more time than the task itself. ...
We are looking for the keys not where lost, but where there is light
Once you don’t notice, the second one starts to annoy, the third time it starts to enrage, and then you think and not whether to send all this to hell. Because it bothers to justify that because of the next approvals, you again failed to fulfill the promise to do something by that date.
By the way, I still do not understand what is the main motive that prompted the creation of new and new rules? Either somewhere they are taught this way, or it is an attempt to cover the ass, or an attempt to show the appearance of work. Probably, even the authors of the regulations themselves do not understand this. And it may be genuinely surprised when you say that this is all unnecessary. It’s like talking to a medieval lord that a carriage can ride without a horse, it just lacks the engine.
But in the development teams there is an engine - the developers themselves. And they need only gently send in the right direction, instead of what would put a stick in the wheel.
How to direct is a separate topic, and this post is not to teach. He in order to designate the problem. Understanding the problem is half the solution.
Unfortunately, the further, the more I come to the idea that the main problem of development in Russia is the inability to put and adjust the process. And not even the inability, but simply a misunderstanding of the process itself. When you do not know how - it is easy to learn. When you do not understand, but you think that you understand, everything is much more complicated.
A frequent mistake of management, and those people who influence the process in that they believe that everything is simple. That the process of creating software is not much different from the process of building a house. What the Tajiks caught up with, gave them a foreman, a foreman a plan in hand, showed where the plan has the top where is the bottom (so that instead of the lighthouse a well did not work), that's all, get ready to cut cabbage.
But over time, they understand that for some reason it does not work, or it works poorly, or it does not work as it would be desirable. The search for the cause of this state of affairs begins, but it is not the cause that is the consequence. The investigation is confused with the cause and the fight with windmills begins.
')
What am I talking about? No, they did not take away my LJ, didn’t turn off ICQ. But there are worse things. And they are worse because they are not so noticeable that they are not so striking. These are the rules and regulations.
As an example of the harm to the bureaucracy, we don’t need to go far; we all remember our recent past and see the present; it’s not for nothing that the word bureaucracy ’has become a negative connotation. Our officials, the distortions of the Soviet (and modern) system tried to correct with the help of laws, decrees, certificates, orders and other red tape. Not from the good life, but from the misunderstanding that the root of the problems of the system is not in the absence of rules, but in the system itself.
This is reminiscent of a situation with an old or poorly built house, when instead of building a new one, the supports and stretchings are attached to the old one.
But not like this! You can not cover your own incompetence paper. This only exacerbates the problem, creating the appearance of work, the appearance of the result and the appearance of the process. This is a lie! Nothing gets better, just another backup appears.
Do not be afraid to admit your incompetence, and what's more, without this you can never learn anything. As someone correctly said, “only a smart person can say" what a fool I am, "only those who want to learn and want to understand, can admit that he does not know and does not understand. And the one who does not want, he will assure himself that he already knows everything, and all the problems from the fact that they do not follow his rules.
But in general, the bureaucracy is an example of the fact that it is impossible to climb on a tree and not to tear your ass. Bureaucracy, regulations, rules and procedures make the system as strong as a tank, but just as slow and cumbersome. And thus we lose its effectiveness and flexibility. If you are a defense plant, then it is probably worth it. It’s better to make a rocket for 10 years, but when she flies, wow flies! But business needs efficiency. The more efficient you are, the faster you occupy the markets, the more you earn money. Well, it is impossible, at least in the field of development, to create an effective system with the help of regulations. That is why agile development techniques first of all minimize paperwork. Either one or the other. Either reliability or speed and flexibility.
But the bureaucracy lives on. It lives because bureaucratic mechanisms are simple and do not require analysis and a deep understanding of the problem. They are equally applicable to everything, and equally ineffective, but they give a visible and most importantly understandable effect. And the fact that they give a lot of side effects that are not so noticeable, and may not manifest for a long time, is not so important, no one will understand that the next problem that got out is the result of a diseased system. Giving a visible effect immediately, the insidious bureaucracy does not cure the disease, it, for the time being, drives it inside.
Well, for example…
We have a so-called test bench, which includes a server with VMware, on which you can create sandboxes for any developer needs . The test bench was specially created for this, and the virtual machines themselves are rather isolated from each other. But in order to create a virtual machine, you need to fill out an application. The application is only in paper form, and must be certified by the signature of the head of the department.
An interesting story with the test bench itself. TK was written for several months (three or four), several approvals passed, signatures from the heads of different levels ... three months to create a TK for a system, the implementation of which will take 2 weeks to do!
Even names in SVN, we now obey some rules, entered some prefixes, existing users must be renamed. Little things of course, but when there are a lot of such trifles, when you come across them there, where you didn’t think, when your plans collapse just because again somewhere you have to sign something, and paperwork sometimes takes more time than the task itself. ...
We are looking for the keys not where lost, but where there is light
Once you don’t notice, the second one starts to annoy, the third time it starts to enrage, and then you think and not whether to send all this to hell. Because it bothers to justify that because of the next approvals, you again failed to fulfill the promise to do something by that date.
By the way, I still do not understand what is the main motive that prompted the creation of new and new rules? Either somewhere they are taught this way, or it is an attempt to cover the ass, or an attempt to show the appearance of work. Probably, even the authors of the regulations themselves do not understand this. And it may be genuinely surprised when you say that this is all unnecessary. It’s like talking to a medieval lord that a carriage can ride without a horse, it just lacks the engine.
But in the development teams there is an engine - the developers themselves. And they need only gently send in the right direction, instead of what would put a stick in the wheel.
How to direct is a separate topic, and this post is not to teach. He in order to designate the problem. Understanding the problem is half the solution.
Source: https://habr.com/ru/post/90967/
All Articles