About organizational structure and bureaucracy
Hello, habrasoobschestvo.
Not so long ago [about a year - that was how much time the article “in the table” lay] we sat with a friend and thought about the organization of an IT company. In a really big IT company, we didn’t work, the whole life was spent in the IT departments of organizations for which IT is not the main type of business. So, although we have an idea about the organizational structure, we are not familiar with the details of its application to a decent-sized office, whose life is the implementation and maintenance of software.
It turned out after two hours of reflection, we have about such a picture, the main provisions of which are explained under the cut.
')
So, we have an organization that runs fairly large IT projects, implements them in the country, and spends a lot of time supporting them. Also, from the introductory, we assume that accounting is outsourced.
It also makes sense to mention here that there is a specificity in supporting large databases and systems for processing this data - there are already several working solutions that need to be supported.
To begin with, let's write down what the organization should do.
Each item is, in fact, a department, although some it makes sense to put together. For example, final testing makes sense to combine with technical documentation, and implementation - with maintenance.
There are several reasons for this association:
For such a scheme, there is another reason, which will be discussed below.
With the development, everything is simpler, there is a department for developing system and application software, a department for web technologies, and a department for working with databases has been allocated (since there is a large amount of work with databases).
With regard to the development of technical specifications and contracting - these are typical managers who work on a project basis with the task "to agree with the customer, to issue tasks to performers, and to ensure that everything is on schedule." The director will surely look forward to these eagles in the office every reporting period and will never delegate the opportunity to give them overclocking to his deputy.
There are a couple of points that are not entirely clear. This is a study of software and the development of software architecture.
The task of the software department is to formulate methods, write formulas, work out the customer’s business process methodology. A sort of expert pool, thoroughly versed in the subject, ready to give a solution on any conceptual issue.
The software design department, rather, should be engaged in the study of the conceptual integrity of the product, give the development department a skeleton that needs to be covered in meat. As a project office is a place where managers sit, so is the software engineering department a place where team leaders sit.
Both tasks do not relate to production or operating activities. Rather, these are certain R & D departments that look ahead, collect optimal solutions, put them into practice and lead the development.
Thus, we get three branches - development, development and technical support. Each project passes the initiation stage in the project office, conceptual development in the development department, writing technical documentation in the operational department, development, and then is transferred back to the maintenance department for implementation.
Such a project path theoretically should allow to identify conceptual flaws and factual errors within the organization, without bringing them to the customer.
Here you need to make a small lyrical digression.
In 2007, a completely non-formalized task “to make them good” arrived. After finding out who exactly and exactly how it is necessary to “do well”, a healthy document was born in which all this was written. The way to harmonize the document, frankly, was thorny and winding, and took into account the interests of all. Now I understand that if it were all to write, it would have turned out if not 1C, then something similar; then it was completely unclear to me. “Okay,” I thought, “garbage, where ours did not disappear! ..” and got to work. Four months later, a prototype was ready, and I went to take it.
It turned out that everything is not so: that is inconvenient, this is not true, then the business process has changed in general ... well, in general, I think everyone can imagine this situation. Grunting, I got back to work.
After a few iterations (and after distraction from writing regulations and changing the concept), the program was adopted, and after a few more months, it was introduced and put on alert. By that time, due to a change in the internal structure of the organization, a change in priorities, etc., 75% of the written TK initially lost its relevance. But this is not really a problem. The problem is that in the pursuit of the speed of writing software, all these changes were not documented. Accordingly, at the present time (yes, yes, it still works, which is surprising) exactly one person can accompany the software, that is, me. And since there is no maintenance contract, I don’t have any reason to write any documents (and the software itself is on Delphi). As a result, they call me once a year, I correct some little things for a period of not more than a week, and forget about this software for another year.
It is impossible in principle to transfer such support anywhere. And it is precisely this story that led me to propose a scheme of responsibility between the writing of the technical project and the software, as well as between the writing of the software and its implementation.
So, in our ideal structure, potential errors, like those described in the previous paragraph, will have to be filtered twice - when sending a document from technicians and when transferring software to implementers. Every disruption is a subject for review by department heads and the project manager. These are absolutely clear milestones on which the project depends. Moreover, the processes on each side of the milestones are controlled by different departments, which allows avoiding dilution of responsibility and transfer “on parole”.
The production part is. It remains to add the financial director, the department of the administrative staff, lawyers and HR department, and the organizational structure of our IT company is ready.
The composition is formed as “representatives of the development department under the leadership of a steep specialist from the software design department with the support of a software technology methodologist under the strict control of the manager diligently satisfy the customer”. So this approach allows using not only “classic” waterfalls, but also flexible technologies, where the manager acts as a product owner. The only thing is that it requires a small overhead to give feedback to the technical documentation department, which should not slow down the process too much.
On the basis of the project’s path in the drawn organization, as well as the division of responsibilities for development, development and support, we get interesting results about the personal qualities of the heads of these departments:
Since I’m never a manager, and this scheme and justification is just a reflection of “on the subject”, I strongly ask you not to kick with your feet, but rather to make practical comments and constructive criticism that might be very useful to others.
Not so long ago [about a year - that was how much time the article “in the table” lay] we sat with a friend and thought about the organization of an IT company. In a really big IT company, we didn’t work, the whole life was spent in the IT departments of organizations for which IT is not the main type of business. So, although we have an idea about the organizational structure, we are not familiar with the details of its application to a decent-sized office, whose life is the implementation and maintenance of software.
It turned out after two hours of reflection, we have about such a picture, the main provisions of which are explained under the cut.
')
Introduction
So, we have an organization that runs fairly large IT projects, implements them in the country, and spends a lot of time supporting them. Also, from the introductory, we assume that accounting is outsourced.
It also makes sense to mention here that there is a specificity in supporting large databases and systems for processing this data - there are already several working solutions that need to be supported.
To begin with, let's write down what the organization should do.
- Writing technical specifications on the list of technical requirements and their coordination with the customer;
- creation of full-fledged technical documentation (since we focus on the subsequent support of projects);
- development of methodological and mathematical software;
- solution architecture development;
- creation of software;
- testing;
- implementation;
- escort.
Structure description
Each item is, in fact, a department, although some it makes sense to put together. For example, final testing makes sense to combine with technical documentation, and implementation - with maintenance.
There are several reasons for this association:
- For the testing and technical documentation department:
- integration testing actually checks the program for compliance with the specification, i.e. technical project;
- correctly defined method of final testing will reveal not only actual, but also logical errors - that is, when the program does not fall, but the result differs from the designed one;
- written software looks like a black box, which allows you to abstract from its insides;
- For the implementation and maintenance department:
- contacts of representatives of technical support and representatives of the customer are being established, since implementation and maintenance are “in one bottle”;
- “Zero implementation” is performed at the testers site, which will allow to run in various installation scenarios and gain combat experience at home.
For such a scheme, there is another reason, which will be discussed below.
With the development, everything is simpler, there is a department for developing system and application software, a department for web technologies, and a department for working with databases has been allocated (since there is a large amount of work with databases).
With regard to the development of technical specifications and contracting - these are typical managers who work on a project basis with the task "to agree with the customer, to issue tasks to performers, and to ensure that everything is on schedule." The director will surely look forward to these eagles in the office every reporting period and will never delegate the opportunity to give them overclocking to his deputy.
There are a couple of points that are not entirely clear. This is a study of software and the development of software architecture.
The task of the software department is to formulate methods, write formulas, work out the customer’s business process methodology. A sort of expert pool, thoroughly versed in the subject, ready to give a solution on any conceptual issue.
The software design department, rather, should be engaged in the study of the conceptual integrity of the product, give the development department a skeleton that needs to be covered in meat. As a project office is a place where managers sit, so is the software engineering department a place where team leaders sit.
Both tasks do not relate to production or operating activities. Rather, these are certain R & D departments that look ahead, collect optimal solutions, put them into practice and lead the development.
Thus, we get three branches - development, development and technical support. Each project passes the initiation stage in the project office, conceptual development in the development department, writing technical documentation in the operational department, development, and then is transferred back to the maintenance department for implementation.
Such a project path theoretically should allow to identify conceptual flaws and factual errors within the organization, without bringing them to the customer.
Here you need to make a small lyrical digression.
Let's quickly automate it!
In 2007, a completely non-formalized task “to make them good” arrived. After finding out who exactly and exactly how it is necessary to “do well”, a healthy document was born in which all this was written. The way to harmonize the document, frankly, was thorny and winding, and took into account the interests of all. Now I understand that if it were all to write, it would have turned out if not 1C, then something similar; then it was completely unclear to me. “Okay,” I thought, “garbage, where ours did not disappear! ..” and got to work. Four months later, a prototype was ready, and I went to take it.
It turned out that everything is not so: that is inconvenient, this is not true, then the business process has changed in general ... well, in general, I think everyone can imagine this situation. Grunting, I got back to work.
After a few iterations (and after distraction from writing regulations and changing the concept), the program was adopted, and after a few more months, it was introduced and put on alert. By that time, due to a change in the internal structure of the organization, a change in priorities, etc., 75% of the written TK initially lost its relevance. But this is not really a problem. The problem is that in the pursuit of the speed of writing software, all these changes were not documented. Accordingly, at the present time (yes, yes, it still works, which is surprising) exactly one person can accompany the software, that is, me. And since there is no maintenance contract, I don’t have any reason to write any documents (and the software itself is on Delphi). As a result, they call me once a year, I correct some little things for a period of not more than a week, and forget about this software for another year.
It is impossible in principle to transfer such support anywhere. And it is precisely this story that led me to propose a scheme of responsibility between the writing of the technical project and the software, as well as between the writing of the software and its implementation.
Returning to the organizational structure
So, in our ideal structure, potential errors, like those described in the previous paragraph, will have to be filtered twice - when sending a document from technicians and when transferring software to implementers. Every disruption is a subject for review by department heads and the project manager. These are absolutely clear milestones on which the project depends. Moreover, the processes on each side of the milestones are controlled by different departments, which allows avoiding dilution of responsibility and transfer “on parole”.
The production part is. It remains to add the financial director, the department of the administrative staff, lawyers and HR department, and the organizational structure of our IT company is ready.
On the composition of the project team
The composition is formed as “representatives of the development department under the leadership of a steep specialist from the software design department with the support of a software technology methodologist under the strict control of the manager diligently satisfy the customer”. So this approach allows using not only “classic” waterfalls, but also flexible technologies, where the manager acts as a product owner. The only thing is that it requires a small overhead to give feedback to the technical documentation department, which should not slow down the process too much.
Unity and struggle of opposites
On the basis of the project’s path in the drawn organization, as well as the division of responsibilities for development, development and support, we get interesting results about the personal qualities of the heads of these departments:
- Deputy Development Director - keen on a broad outlook, always striving for new knowledge, new technologies. His department almost always works in pure minus, but the ideas born in him give food to the rest of the departments, moving the company forward. Convinced optimist.
- Deputy The Operations Director is a cautious, experienced worker who sees everything three steps ahead, and therefore is more likely to be a pessimist, although I most often call him a retrograde. His department brings a stable, but small income, and he does not want everything to become dust because of the new trends of the innovator.
- Deputy the production director is the most balanced of all, the first deputy. It serves as a balance between the innovator and the traditionalist, adheres to evolutionary theory. He brings most of the profits, providing all the bonuses, and the director - a new car, and therefore calm.
- The financial director considers revenues and expenses and from time to time gently reminds the innovator that if this goes on like this, the director will not receive his annual Porsche Cayenne, and all the rest will receive his bonus.
Conclusion
Since I’m never a manager, and this scheme and justification is just a reflection of “on the subject”, I strongly ask you not to kick with your feet, but rather to make practical comments and constructive criticism that might be very useful to others.
Source: https://habr.com/ru/post/230899/
All Articles