How do we decide what to do?
In the article, we will answer only one question - how we decide what and when to implement in the 1C: Enterprise platform.
It is in this formulation that we are rarely asked, but often and even very often specific questions appear - “why did you do it?”, “Why did you NOT do it?”, “Why don't you do it?”, “When you do is it? "," when will you finally do it? !!! ", ...
Let's try to describe how we decide what to do.
')
In general, there are quite generally accepted requirements management processes.
Unfortunately, basically, they are related to custom development, and we have a lot of copies. Moreover, a very, very replicable.
Unfortunately, they are mostly related to more applied tasks. And we have a technology platform (framework).
It seems that the second circumstance plays a smaller role in the peculiarities of our situation.
The concept of “demand” seems (especially in the Russian-language reading) is not quite correct in our case. Since we do not have one customer who “requires” something, then everything that we can do (potential “features”) can be described in very diverse terms (“wishes”, “suggestions”, “needs”, “ideas ", ....).
We have not formed a single name for this subject.
Most often we use the term "wish." Although this does not always accurately reflect specific cases.
We have written thousands (many thousands) of wishes. Of course, it is even impossible to imagine that we will ever implement them all. Moreover, even if time and laboriousness are not taken into account, all of them (all together) are simply not needed! And, therefore, there is always the question - what should be done now ?! “Now”, of course, means very different time ranges.
It is easy to list the main sources - where the wishes come from:
The order of the items in this list is not a reflection of priorities. This is just a listing. Priorities are determined in a more complex way. About this further.
We do not have individual analysts who select realizable wishes.
The development team is responsible for the selection of the tasks and development directions to be implemented.
The choice of priorities (planning "features") is now carried out by commands (earlier this was done centrally).
That is, the choice is made not from the general list, but from the command list.
The team lead team, in consultation with the team members, determines the priorities of potential tasks and forms a plan. Of course, the periodicity of planning plays a role here (planning can be carried out over several time horizons), but this is a separate topic.
The formed plan is discussed with other teams, when it is required, and with the project management. With this discussion, of course, the decisions may change.
We are trying to ensure that the team has a constant backlog - a list of potential tasks, ranked by priorities, for 2-3 planning steps ahead.
Methods of selection of wishes in teams may differ slightly. This can be influenced by the features of the spectrum of the functionality for which the team is responsible, and the preferences of the team lead.
Of course, this approach forms the increased requirements for team lead teams, architects and team developers. They need to understand how the platform is used, analyze the wishes of users and application developers, follow the trends in IT, understand the direction of development of competing technologies. Here, competing technologies are understood not only (and often not so much) business competitors, as well as existing and emerging technologies in specific areas. For example, for UI, the mechanisms of the platform are modern UI frameworks; for the mechanism of working with data, these are universal mechanisms for working with data (for example, ORM).
Thus, it turns out that team lead and responsible for some platform mechanism, in addition to all other qualities, perform the role of analyst. Although we do not use this term, this part of the work is very, very important.
The general directions of development and the most significant tasks are consistent with the director of the company. The director can make recommendations as well as directly influence the decision. Of course, when choosing the final decisions (at the level of the team, project management, director of the company) there is an administrative subordination. But in practice this does not cause problems, since in the overwhelming majority of cases it is possible to reach mutual understanding (consensus) at all levels. And where opinions remain different (and a decision is made), opinions are explained and discussed. Therefore, there is no feeling of “over-administration” of decision-making.
We often (almost always) have a difficult choice.
First , the choice between new opportunities and the development of existing ones.
There is no unambiguous criterion, it is all necessary and nothing can be donated.
We try to keep balance. Actively used functionality always generates a lot of wishes for development. We try to highlight what is critically lacking for effective use and what can radically increase efficiency. But if you only implement what users and application developers are asking for the development of existing capabilities, then development in strategic and future directions will remain “overboard”.
Secondly , the choice between increased reliability, performance and new features.
Also a difficult choice. Of course, you need both.
We assess the level of current needs and try to find a reasonable balance.
Now, for example, issues of reliability and performance have a very high priority. This has quite tangible reasons.
On the one hand, the use of 1C: Enterprise in a corporate environment constantly increases the requirements for scalability, reliability and performance. Implementations are becoming more and more (by the number of competitive users, the volume of operations per unit of time, the volume of functionality, ...). At the same time, increased accessibility requirements. Reduced allowable technological breaks, the price of errors is getting higher.
On the other hand, the transition to the cloud model also requires increased scalability and reliability. Mass programs designed for small enterprises when moving to the cloud (working no longer on one but on thousands of enterprises) already require a completely different level of reliability and scalability.
In addition, the process of rotating computers has slowed down. That is, our new functionality (which includes many useful and convenient features) should work on computers 6-7 and even 10 years of age. This requires us also significant investments in optimization.
Thirdly , the choice between current needs and promising developments.
In general, it seems obvious that if you want to get some new quality or a big new mechanism, then its implementation can take a lot of time (months, years). And in the presence of very important and very urgent needs now, we are investing substantial forces in future tasks and directions. Perhaps they are not so urgently needed now, but if they are not done now, they will not be tomorrow and the day after. And then they can already become critical.
For example, at one time we were reproached that we invested a lot of effort in creating and developing a web client , they said - look, 1C web client is used by few, invest better resources in what most people use. But we considered (and continue to consider) the development of the web client to be a very important area; if we didn’t have a full-fledged web client now - we would essentially lose compared to our competitors, our products could not be implemented where the presence of full functionality when working in the browser is a necessary condition. And this fact, undoubtedly, as a result would have a negative impact on all our users. But now we have an important competitive advantage. We have both a web interface and a native interface. Moreover, the development of a web interface does not require additional efforts (both interfaces are generated by the platform based on the same application) and both interfaces look almost the same.
Also with modern trends in IT. We need to start taking them into account in advance, when it will seem like a waste of our time to users (instead of doing something useful). If you start to support them when users start shouting about them in a voice, then it will be too late.
Accordingly, our task is to combine, in a reasonable proportion, future tasks and directions with meeting current needs.
Typical methods and approaches to planning work poorly for the selection of promising areas. But this is probably a separate topic ...
Fourth , the choice between the received wishes and new ideas.
For example, the most spectacular technologies that change the world (in IT and not only) appear not from the wishes of users, but from ideas. For example, take office software. The word processor, in general, is quite an obvious subject, arising from the wishes of users - “we want a typewriter, but on a computer.” But such a thing as a spreadsheet, hardly anyone could wish for - this is a wonderful invention. And we have enough of such examples, when we did not take a ready-made wish or solution available in other technologies, but invented and implemented our idea. And it gave a very big effect. For example, data exchange and distributed information database mechanisms and a data composition system were born. Yes, the very concept of configuration objects (business objects — directories, documents, information registers, etc.), which is the cornerstone of the 1C: Enterprise platform, emerged as the idea of ​​a development team.
We consider the ideas of the developers no less important than the wishes received.
Of course, it is important (and we understand this responsibility) that the ideas chosen and implemented really bring substantial benefits. That is, we do not allow any idea into the business, until we understand what benefits it will bring.
The deadline for recording a wish should in no way influence decision making.
You can often meet such a complaint - “they asked for it 5 years ago, and you, until now, have not done it”.
Yes, we believe that “they asked 5 years ago” - this is not an argument.
Wishes do not form a queue or a stack.
We believe that priorities should be assessed at each stage at the current time.
The situation is changing very quickly. What was useful 5 years ago may not be very useful now, and it may even be harmful.
And, most importantly, the choice you need to do in comparison with the current set of other possible tasks and directions of development. Moreover, it is as of the current moment, but it is obligatory taking into account the future. That is, we appreciate what is needed today, tomorrow and the day after tomorrow.
If, for example, we didn’t have time to implement something in some mechanism at the current stage, then the remaining unrealized functions are not automatically included in the plan of the next stage, but are considered on equal basis with other potential tasks.
By the way, if you mentally imagine that we will now begin to methodically implement the wishes received 5-10 years ago, it will be very funny.
In general, we consider. But this is not the main criterion. This is additional information for choosing a priority. We understand that there are items in which the number of appeals may indicate the importance of a wish, and there are items where it cannot or can to a very small extent.
It is taken into account, but not at all straightforward.
Often you hear - "why you did not do it, because it does a couple of hours"
Well, firstly, often (even very often) this assessment from outside does not take into account the realities of development. To fully design a small change (to take into account its influence in different situations on different mechanisms of the system) often takes significantly more time than the actual implementation. Well, another important aspect. We cannot afford to implement the first solution that came to mind. Because the mechanisms of the platform are involved in hundreds of applications for many years.
Accordingly, it is necessary to consider several options for solving the problem and choose the most correct one.
Secondly, it is not clear why you actually need to choose exactly what to do easier and faster? It seems that you need to do something that is more important. Again, imagine that we will do everything that is simpler. What will be the development of the system ...
It happens that a small task is included in the plan because it can be done at a certain point in time, because at this moment, we need a short timeout between two scheduled tasks. But these are rare cases.
It happens that when analyzing a small task that we wanted to include in the plan, it turns out that the laboriousness (and sometimes the scale of the changes themselves) will be much larger than expected. In some cases this may result in the task being excluded from the plan. For example, if the expected effect does not seem to be large enough with such effort or such significant changes.
One of our approaches to the selection of priorities is:
We also use, for example, this approach:
This allows you to take into account opinions from different sides of the counter. This counter has at least three sides (users, application developers, platform developers).
It turns out a kind of casting or competition.
In which the wishes, ideas and critical needs are lined up on the podium and demonstrate their attractiveness. And we evaluate them (taking into account the opinions of users, developers and our opinion) and select the most-most attractive. Sometimes casting includes several rounds.
For example, first 20 finalists are selected from a hundred candidates, then 5 winners are selected from 20. And the rest are waiting for the next contest.
In addition to the described techniques and factors, of course, there are some other factors (more mundane) that also affect the plans.
Decision making is influenced, of course, by the current situation with the loading of specialists.
For example, if for two tasks selected by priorities, the active participation of one and the same specialist is necessary, then one of them has to be postponed.
Still, from time to time, there are "urgent introductory." For example, the developers of a browser decided to change something in the requirements for applications. Here we have to quickly revise plans. Given the wide range of supported platforms (operating systems, DBMS, browsers, mobile operating systems, ...) this, unfortunately, becomes not such a rare phenomenon.
We have a centralized and very detailed automated processes for implementing tasks and working with errors (task-tracking, bug-tracking). With the wish selection process more difficult. We have implemented at some point a single automated system for the selection and prioritization of wishes. It turned out very complicated, but did not cover the real needs of the development teams.
Now the wishes themselves are recorded in some registry, but the selection and prioritization of wishes is done not by a single tool, but for each team separately with specific methods and methods of automation.
Perhaps we will ever return to this issue.
We have not yet made a publicly available wish list.
It turned out to be quite a complicated matter (not technically, but methodologically).
In terms of collecting requests, we have implemented a mechanism for collecting ideas for users of applications as part of the 1cFresh.com service. It works quite well. On the platform, there also appears a number of wishes (for the part that is visible to users directly), but, of course, this resource is mainly focused on the functionality of application solutions.
On the platform, on the other hand, we made a resource for publishing errors ( https://bugboard.v8.1c.ru ). By the way, it was also not so easy.
Sometimes we organize targeted surveys on the forum for specialists on the wishes on a specific topic in order to understand current opinions on priorities. We usually do this when we start planning in some direction and feel a lack of information.
Although we do not have a publicly accessible place where wishes are published, we carefully collect them from all possible sources (from the support line, forums, communicating with partners, developers and users at seminars). We all recorded! :)
Perhaps we will return to the issue of creating a public resource.
With all the available methods of selecting ideas and wishes, we see our task more widely. Not just to choose the most necessary from all the recorded wishes, but to create something new that will bring substantial value to our developers and users and make the world a better place!
A common goal can be formulated, usually quite simply. For us, it is to create the world's best business application development platform.
In general, the selection of areas of development and functions implemented in our situation is a very exciting and challenging task. There are many wishes. There are a lot of ideas. I want to do a lot! And you need to choose the optimal set that will make our world the best.
It is in this formulation that we are rarely asked, but often and even very often specific questions appear - “why did you do it?”, “Why did you NOT do it?”, “Why don't you do it?”, “When you do is it? "," when will you finally do it? !!! ", ...
Let's try to describe how we decide what to do.
')
Requirements or wishes?
In general, there are quite generally accepted requirements management processes.
Unfortunately, basically, they are related to custom development, and we have a lot of copies. Moreover, a very, very replicable.
Unfortunately, they are mostly related to more applied tasks. And we have a technology platform (framework).
It seems that the second circumstance plays a smaller role in the peculiarities of our situation.
The concept of “demand” seems (especially in the Russian-language reading) is not quite correct in our case. Since we do not have one customer who “requires” something, then everything that we can do (potential “features”) can be described in very diverse terms (“wishes”, “suggestions”, “needs”, “ideas ", ....).
We have not formed a single name for this subject.
Most often we use the term "wish." Although this does not always accurately reflect specific cases.
We have written thousands (many thousands) of wishes. Of course, it is even impossible to imagine that we will ever implement them all. Moreover, even if time and laboriousness are not taken into account, all of them (all together) are simply not needed! And, therefore, there is always the question - what should be done now ?! “Now”, of course, means very different time ranges.
It is easy to list the main sources - where the wishes come from:
- Wishes and ideas of developers of applied solutions
- Partners Wishes and Ideas
- User wishes and ideas
- Wishes and ideas of the company management
- Wishes and ideas of other divisions
- What is implemented in some products on the market (both competing with us and non-competing)
- What follows from the development trends of IT and business in the world
- Our own ideas
The order of the items in this list is not a reflection of priorities. This is just a listing. Priorities are determined in a more complex way. About this further.
We do not have individual analysts who select realizable wishes.
The development team is responsible for the selection of the tasks and development directions to be implemented.
Prioritization
The choice of priorities (planning "features") is now carried out by commands (earlier this was done centrally).
That is, the choice is made not from the general list, but from the command list.
The team lead team, in consultation with the team members, determines the priorities of potential tasks and forms a plan. Of course, the periodicity of planning plays a role here (planning can be carried out over several time horizons), but this is a separate topic.
The formed plan is discussed with other teams, when it is required, and with the project management. With this discussion, of course, the decisions may change.
We are trying to ensure that the team has a constant backlog - a list of potential tasks, ranked by priorities, for 2-3 planning steps ahead.
Methods of selection of wishes in teams may differ slightly. This can be influenced by the features of the spectrum of the functionality for which the team is responsible, and the preferences of the team lead.
Of course, this approach forms the increased requirements for team lead teams, architects and team developers. They need to understand how the platform is used, analyze the wishes of users and application developers, follow the trends in IT, understand the direction of development of competing technologies. Here, competing technologies are understood not only (and often not so much) business competitors, as well as existing and emerging technologies in specific areas. For example, for UI, the mechanisms of the platform are modern UI frameworks; for the mechanism of working with data, these are universal mechanisms for working with data (for example, ORM).
Thus, it turns out that team lead and responsible for some platform mechanism, in addition to all other qualities, perform the role of analyst. Although we do not use this term, this part of the work is very, very important.
What and how we choose to implement
The general directions of development and the most significant tasks are consistent with the director of the company. The director can make recommendations as well as directly influence the decision. Of course, when choosing the final decisions (at the level of the team, project management, director of the company) there is an administrative subordination. But in practice this does not cause problems, since in the overwhelming majority of cases it is possible to reach mutual understanding (consensus) at all levels. And where opinions remain different (and a decision is made), opinions are explained and discussed. Therefore, there is no feeling of “over-administration” of decision-making.
We often (almost always) have a difficult choice.
First , the choice between new opportunities and the development of existing ones.
There is no unambiguous criterion, it is all necessary and nothing can be donated.
We try to keep balance. Actively used functionality always generates a lot of wishes for development. We try to highlight what is critically lacking for effective use and what can radically increase efficiency. But if you only implement what users and application developers are asking for the development of existing capabilities, then development in strategic and future directions will remain “overboard”.
Secondly , the choice between increased reliability, performance and new features.
Also a difficult choice. Of course, you need both.
We assess the level of current needs and try to find a reasonable balance.
Now, for example, issues of reliability and performance have a very high priority. This has quite tangible reasons.
On the one hand, the use of 1C: Enterprise in a corporate environment constantly increases the requirements for scalability, reliability and performance. Implementations are becoming more and more (by the number of competitive users, the volume of operations per unit of time, the volume of functionality, ...). At the same time, increased accessibility requirements. Reduced allowable technological breaks, the price of errors is getting higher.
On the other hand, the transition to the cloud model also requires increased scalability and reliability. Mass programs designed for small enterprises when moving to the cloud (working no longer on one but on thousands of enterprises) already require a completely different level of reliability and scalability.
In addition, the process of rotating computers has slowed down. That is, our new functionality (which includes many useful and convenient features) should work on computers 6-7 and even 10 years of age. This requires us also significant investments in optimization.
Thirdly , the choice between current needs and promising developments.
In general, it seems obvious that if you want to get some new quality or a big new mechanism, then its implementation can take a lot of time (months, years). And in the presence of very important and very urgent needs now, we are investing substantial forces in future tasks and directions. Perhaps they are not so urgently needed now, but if they are not done now, they will not be tomorrow and the day after. And then they can already become critical.
For example, at one time we were reproached that we invested a lot of effort in creating and developing a web client , they said - look, 1C web client is used by few, invest better resources in what most people use. But we considered (and continue to consider) the development of the web client to be a very important area; if we didn’t have a full-fledged web client now - we would essentially lose compared to our competitors, our products could not be implemented where the presence of full functionality when working in the browser is a necessary condition. And this fact, undoubtedly, as a result would have a negative impact on all our users. But now we have an important competitive advantage. We have both a web interface and a native interface. Moreover, the development of a web interface does not require additional efforts (both interfaces are generated by the platform based on the same application) and both interfaces look almost the same.
Also with modern trends in IT. We need to start taking them into account in advance, when it will seem like a waste of our time to users (instead of doing something useful). If you start to support them when users start shouting about them in a voice, then it will be too late.
Accordingly, our task is to combine, in a reasonable proportion, future tasks and directions with meeting current needs.
Typical methods and approaches to planning work poorly for the selection of promising areas. But this is probably a separate topic ...
Fourth , the choice between the received wishes and new ideas.
For example, the most spectacular technologies that change the world (in IT and not only) appear not from the wishes of users, but from ideas. For example, take office software. The word processor, in general, is quite an obvious subject, arising from the wishes of users - “we want a typewriter, but on a computer.” But such a thing as a spreadsheet, hardly anyone could wish for - this is a wonderful invention. And we have enough of such examples, when we did not take a ready-made wish or solution available in other technologies, but invented and implemented our idea. And it gave a very big effect. For example, data exchange and distributed information database mechanisms and a data composition system were born. Yes, the very concept of configuration objects (business objects — directories, documents, information registers, etc.), which is the cornerstone of the 1C: Enterprise platform, emerged as the idea of ​​a development team.
We consider the ideas of the developers no less important than the wishes received.
Of course, it is important (and we understand this responsibility) that the ideas chosen and implemented really bring substantial benefits. That is, we do not allow any idea into the business, until we understand what benefits it will bring.
How does the "limitation period"?
The deadline for recording a wish should in no way influence decision making.
You can often meet such a complaint - “they asked for it 5 years ago, and you, until now, have not done it”.
Yes, we believe that “they asked 5 years ago” - this is not an argument.
Wishes do not form a queue or a stack.
We believe that priorities should be assessed at each stage at the current time.
The situation is changing very quickly. What was useful 5 years ago may not be very useful now, and it may even be harmful.
And, most importantly, the choice you need to do in comparison with the current set of other possible tasks and directions of development. Moreover, it is as of the current moment, but it is obligatory taking into account the future. That is, we appreciate what is needed today, tomorrow and the day after tomorrow.
If, for example, we didn’t have time to implement something in some mechanism at the current stage, then the remaining unrealized functions are not automatically included in the plan of the next stage, but are considered on equal basis with other potential tasks.
By the way, if you mentally imagine that we will now begin to methodically implement the wishes received 5-10 years ago, it will be very funny.
To what extent do we take into account the number of requests for a specific request?
In general, we consider. But this is not the main criterion. This is additional information for choosing a priority. We understand that there are items in which the number of appeals may indicate the importance of a wish, and there are items where it cannot or can to a very small extent.
How does the complexity of the task?
It is taken into account, but not at all straightforward.
Often you hear - "why you did not do it, because it does a couple of hours"
Well, firstly, often (even very often) this assessment from outside does not take into account the realities of development. To fully design a small change (to take into account its influence in different situations on different mechanisms of the system) often takes significantly more time than the actual implementation. Well, another important aspect. We cannot afford to implement the first solution that came to mind. Because the mechanisms of the platform are involved in hundreds of applications for many years.
Accordingly, it is necessary to consider several options for solving the problem and choose the most correct one.
Secondly, it is not clear why you actually need to choose exactly what to do easier and faster? It seems that you need to do something that is more important. Again, imagine that we will do everything that is simpler. What will be the development of the system ...
It happens that a small task is included in the plan because it can be done at a certain point in time, because at this moment, we need a short timeout between two scheduled tasks. But these are rare cases.
It happens that when analyzing a small task that we wanted to include in the plan, it turns out that the laboriousness (and sometimes the scale of the changes themselves) will be much larger than expected. In some cases this may result in the task being excluded from the plan. For example, if the expected effect does not seem to be large enough with such effort or such significant changes.
One of our approaches to the selection of priorities is:
- The tasks that solve the most acute problems that users and application developers now have are selected,
- We select the tasks that will give the greatest effect on the improvement of work (according to our assessment and evaluation of those with whom we have consulted)
- The plan includes the “best-most” of both groups in a certain proportion (for example, equally), so much so that, in terms of optimistic expenditures, they have time to manage in the allotted time frame.
We also use, for example, this approach:
- Selected some (primarily selected by expert) composition of the wishes,
- For each request, priority scores are entered on a 5-point scale:
- in terms of users,
- from the point of view of developers of applied solutions (ours and partners),
- in terms of the platform development team.
- The resulting numbers are summarized and the wishes are ordered by the priorities obtained.
This allows you to take into account opinions from different sides of the counter. This counter has at least three sides (users, application developers, platform developers).
It turns out a kind of casting or competition.
In which the wishes, ideas and critical needs are lined up on the podium and demonstrate their attractiveness. And we evaluate them (taking into account the opinions of users, developers and our opinion) and select the most-most attractive. Sometimes casting includes several rounds.
For example, first 20 finalists are selected from a hundred candidates, then 5 winners are selected from 20. And the rest are waiting for the next contest.
In addition to the described techniques and factors, of course, there are some other factors (more mundane) that also affect the plans.
Decision making is influenced, of course, by the current situation with the loading of specialists.
For example, if for two tasks selected by priorities, the active participation of one and the same specialist is necessary, then one of them has to be postponed.
Still, from time to time, there are "urgent introductory." For example, the developers of a browser decided to change something in the requirements for applications. Here we have to quickly revise plans. Given the wide range of supported platforms (operating systems, DBMS, browsers, mobile operating systems, ...) this, unfortunately, becomes not such a rare phenomenon.
Pro automation
We have a centralized and very detailed automated processes for implementing tasks and working with errors (task-tracking, bug-tracking). With the wish selection process more difficult. We have implemented at some point a single automated system for the selection and prioritization of wishes. It turned out very complicated, but did not cover the real needs of the development teams.
Now the wishes themselves are recorded in some registry, but the selection and prioritization of wishes is done not by a single tool, but for each team separately with specific methods and methods of automation.
Perhaps we will ever return to this issue.
We have not yet made a publicly available wish list.
It turned out to be quite a complicated matter (not technically, but methodologically).
In terms of collecting requests, we have implemented a mechanism for collecting ideas for users of applications as part of the 1cFresh.com service. It works quite well. On the platform, there also appears a number of wishes (for the part that is visible to users directly), but, of course, this resource is mainly focused on the functionality of application solutions.
On the platform, on the other hand, we made a resource for publishing errors ( https://bugboard.v8.1c.ru ). By the way, it was also not so easy.
Sometimes we organize targeted surveys on the forum for specialists on the wishes on a specific topic in order to understand current opinions on priorities. We usually do this when we start planning in some direction and feel a lack of information.
Although we do not have a publicly accessible place where wishes are published, we carefully collect them from all possible sources (from the support line, forums, communicating with partners, developers and users at seminars). We all recorded! :)
Perhaps we will return to the issue of creating a public resource.
With all the available methods of selecting ideas and wishes, we see our task more widely. Not just to choose the most necessary from all the recorded wishes, but to create something new that will bring substantial value to our developers and users and make the world a better place!
A common goal can be formulated, usually quite simply. For us, it is to create the world's best business application development platform.
In general, the selection of areas of development and functions implemented in our situation is a very exciting and challenging task. There are many wishes. There are a lot of ideas. I want to do a lot! And you need to choose the optimal set that will make our world the best.
Source: https://habr.com/ru/post/277237/
All Articles