July 24, 2014 at 08:53About organizational structure and bureaucracy
Hello, habrasociety.
Not so long ago [about a year - that’s how the article "was in the table" lasted so long], we sat with a friend and thought for questions of organizing an IT company. We did not work in a really large IT company; all our 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 size office, whose life is the implementation and maintenance of software.
It turned out after two hours of reflection, we have something like this picture, the main provisions of which are explained under the cut.
So, we have an organization that conducts large enough IT projects, implements them throughout 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 that the specifics in supporting large databases and systems for processing this data - there are already several working solutions that need to be supported.
First, we’ll write down what the organization should do.
Each item is, in fact, a department, although some make sense to put together. For example, it makes sense to combine final testing with technical documentation, and implementation with maintenance.
There are several reasons for this association:
There is another reason for such a scheme, 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 a database is allocated (since there is a large amount of work with the database).
As for the development of the terms of reference and the conclusion of contracts, these are typical managers who work on a project basis with the task of "agreeing with the customer, assigning tasks to the contractors, and ensuring that everything is on schedule." The director will probably look forward to these eagles in the office every reporting period and will not delegate the opportunity to give them dispersal to his deputy.
There are a couple of points with which it is not entirely clear. This is the study of mathematical software and the development of software architecture.
The task of the software department is to formulate methods, write formulas, and work out the methodology of business processes at the customer. A sort of pool of experts, thoroughly versed in the topic, ready to give a decision on any conceptual issue.
The software design department, however, should rather work on the conceptual integrity of the product, give the skeleton for the development department, which must be covered with meat. Both the project office is the place where managers sit, and the software design department is the place where team leaders sit.
Both tasks relate neither to production nor to operational activities. Rather, these are some departments of research that look forward, collect optimal solutions, put them into practice and manage development.
Thus, we get three branches - development, development and technical support. Each project goes through the initiation stage in the project office, conceptualization in the development department, writing technical documentation in the operations department, development, and then transferred back to the support department for implementation.
Such a project path should theoretically allow the identification of conceptual flaws and factual errors within the organization without bringing them to the customer.
Here it is required to make a small digression.
In 2007, a completely unformalized task “to make them well” was received. After finding out exactly who and exactly how to “do well”, a healthy document was born in which it was all written. Frankly speaking, the way to approve the document was thorny and tortuous, and took into account the interests of all. Now I understand that if I wrote all this, it would have turned out, if not 1C, then something similar; then it was completely unobvious to me. “Okay,” I thought, “bullshit, where ours didn’t disappear! ..” - and sat down at work. Four months later some prototype was ready, and I went to take it.
It turned out that everything was wrong: it’s inconvenient, it’s wrong, here the business process has changed ... well, in general, I think everyone can imagine this situation. Grunting, I sat down to work again.
After several iterations (and after being distracted by writing regulations and changing the concept), the program was adopted, and a few months later it was implemented and stood on alert. By that time, due to changes in the internal structure of the organization, changes in priorities, etc., 75% of the original written TK lost relevance. But this is actually not a problem. The problem is that in the pursuit of the speed of writing software, all these changes were not documented. Accordingly, at present (yes, it still works, which is surprising) exactly one person can accompany the software, that is, I. And since there is no escort agreement, there is no reason to write me any documents (and the software itself on dolphins). As a result, once a year they call me, I rule some little things for a period of no more than a week,
To transfer such support anywhere else is fundamentally impossible. And it was this story that led me to propose a scheme for sharing responsibility between writing a technical project and software, as well as between writing software and its implementation.
So, in our ideal structure, potential errors, similar to those described in the previous paragraph, should be filtered twice - when transferring a document from technical writers and when transferring software to implementers. Each deadline is subject to litigation by the heads of departments 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 avoids the blurring of responsibility and the transfer “on parole”.
The production part is. It remains to add the financial director, the department of the AHO, lawyers and heycharnyu, and the organizational structure of our IT company is ready.
The staff is formed as “representatives of the development department led by a tough specialist from the software design department with the support of a methodologist from the software group, under the close supervision of the manager, are diligently satisfying the customer.” So this approach allows you to use not only the "classic" waterfall, but also flexible technologies, where the manager acts as a product owner. The only thing is that it requires a small overhead for feedback from the technical documentation department, which should not slow down the process very much.
Based on the path of the project in the drawn organization, as well as the division of responsibilities for development, development and support, we get interesting consequences about the personal qualities of the heads of these departments:
Since I’m never a manager, and this scheme and justification is just a figment of thoughts “on the subject,” I strongly urge you not to kick, but rather make sensible comments and constructive criticism that may be very useful to others.
Not so long ago [about a year - that’s how the article "was in the table" lasted so long], we sat with a friend and thought for questions of organizing an IT company. We did not work in a really large IT company; all our 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 size office, whose life is the implementation and maintenance of software.
It turned out after two hours of reflection, we have something like this picture, the main provisions of which are explained under the cut.
Introduction
So, we have an organization that conducts large enough IT projects, implements them throughout 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 that the specifics in supporting large databases and systems for processing this data - there are already several working solutions that need to be supported.
First, we’ll write down what the organization should do.
- Writing technical specifications according to the list of technical requirements and coordinating them with the customer;
- creation of full-fledged technical documentation (since we focus on the subsequent support of projects);
- study of methodological and mathematical support;
- solution architecture development;
- software creation;
- testing;
- implementation;
- escort.
Structure description
Each item is, in fact, a department, although some make sense to put together. For example, it makes sense to combine final testing with technical documentation, and implementation with maintenance.
There are several reasons for this association:
- For the department of testing and technical documentation:
- integration testing actually checks the program for compliance with the specification, i.e. technical design;
- a correctly defined methodology for final testing will reveal not only actual, but also logical errors - that is, when the program does not crash, 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 support department:
- contacts are being established between representatives of technical support and representatives of the customer, since the implementation and maintenance are “in one bottle”;
- “Zero implementation” is carried out at the testers ’site, which will allow to run through various installation scenarios and gain combat experience at home.
There is another reason for such a scheme, 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 a database is allocated (since there is a large amount of work with the database).
As for the development of the terms of reference and the conclusion of contracts, these are typical managers who work on a project basis with the task of "agreeing with the customer, assigning tasks to the contractors, and ensuring that everything is on schedule." The director will probably look forward to these eagles in the office every reporting period and will not delegate the opportunity to give them dispersal to his deputy.
There are a couple of points with which it is not entirely clear. This is the study of mathematical software and the development of software architecture.
The task of the software department is to formulate methods, write formulas, and work out the methodology of business processes at the customer. A sort of pool of experts, thoroughly versed in the topic, ready to give a decision on any conceptual issue.
The software design department, however, should rather work on the conceptual integrity of the product, give the skeleton for the development department, which must be covered with meat. Both the project office is the place where managers sit, and the software design department is the place where team leaders sit.
Both tasks relate neither to production nor to operational activities. Rather, these are some departments of research that look forward, collect optimal solutions, put them into practice and manage development.
Thus, we get three branches - development, development and technical support. Each project goes through the initiation stage in the project office, conceptualization in the development department, writing technical documentation in the operations department, development, and then transferred back to the support department for implementation.
Such a project path should theoretically allow the identification of conceptual flaws and factual errors within the organization without bringing them to the customer.
Here it is required to make a small digression.
Let's quickly automate this!
In 2007, a completely unformalized task “to make them well” was received. After finding out exactly who and exactly how to “do well”, a healthy document was born in which it was all written. Frankly speaking, the way to approve the document was thorny and tortuous, and took into account the interests of all. Now I understand that if I wrote all this, it would have turned out, if not 1C, then something similar; then it was completely unobvious to me. “Okay,” I thought, “bullshit, where ours didn’t disappear! ..” - and sat down at work. Four months later some prototype was ready, and I went to take it.
It turned out that everything was wrong: it’s inconvenient, it’s wrong, here the business process has changed ... well, in general, I think everyone can imagine this situation. Grunting, I sat down to work again.
After several iterations (and after being distracted by writing regulations and changing the concept), the program was adopted, and a few months later it was implemented and stood on alert. By that time, due to changes in the internal structure of the organization, changes in priorities, etc., 75% of the original written TK lost relevance. But this is actually not a problem. The problem is that in the pursuit of the speed of writing software, all these changes were not documented. Accordingly, at present (yes, it still works, which is surprising) exactly one person can accompany the software, that is, I. And since there is no escort agreement, there is no reason to write me any documents (and the software itself on dolphins). As a result, once a year they call me, I rule some little things for a period of no more than a week,
To transfer such support anywhere else is fundamentally impossible. And it was this story that led me to propose a scheme for sharing responsibility between writing a technical project and software, as well as between writing software and its implementation.
Returning to the organizational structure
So, in our ideal structure, potential errors, similar to those described in the previous paragraph, should be filtered twice - when transferring a document from technical writers and when transferring software to implementers. Each deadline is subject to litigation by the heads of departments 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 avoids the blurring of responsibility and the transfer “on parole”.
The production part is. It remains to add the financial director, the department of the AHO, lawyers and heycharnyu, and the organizational structure of our IT company is ready.
About the composition of the project team
The staff is formed as “representatives of the development department led by a tough specialist from the software design department with the support of a methodologist from the software group, under the close supervision of the manager, are diligently satisfying the customer.” So this approach allows you to use not only the "classic" waterfall, but also flexible technologies, where the manager acts as a product owner. The only thing is that it requires a small overhead for feedback from the technical documentation department, which should not slow down the process very much.
Unity and the struggle of opposites
Based on the path of the project in the drawn organization, as well as the division of responsibilities for development, development and support, we get interesting consequences about the personal qualities of the heads of these departments:
- Deputy Development Director - keen, broad-minded, always striving for new knowledge, new technologies. His department almost always works in the net minus, but the ideas that are born in him give food to the other departments, moving the company forward. Convinced optimist.
- Deputy Director of Operations - a cautious, experienced employee who sees everything three steps forward, and therefore rather a pessimist, although most often we call him a retrograde. His department brings a stable, but small income, and he does not want everything to go to waste due to new trends of the innovator.
- Deputy production directors - the most balanced of all, the first deputy. It serves as a balance between the innovator and the traditionalist, adheres to the evolutionary theory. He brings most of the profit, providing everyone with bonuses, and the director with a new machine, and therefore is calm.
- Financial Director - considers income and expenses and from time to time gently reminds the innovator that if this goes further, the director will not receive his annual cayenne porsche, and everyone else will receive his bonus.
Conclusion
Since I’m never a manager, and this scheme and justification is just a figment of thoughts “on the subject,” I strongly urge you not to kick, but rather make sensible comments and constructive criticism that may be very useful to others.