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 wording that we are rarely asked, but often and even very often specific questions arise - “why did you not do this?”, “Why didn’t you do this?”, “Why don't you do it?”, “When you do it? ”,“ when will you finally do it? !!! ”, ...

    Let's try to describe how we decide what to do when.

    Requirements or wishes?

    In general, there are quite generally accepted requirements management processes.
    Unfortunately, basically, they relate to custom developments, and we have a circulation. Moreover, very, very circulation.
    Unfortunately, they mainly relate to more applied tasks. And we have a technological platform (framework).

    It seems that the second circumstance plays a smaller role in the features of our situation.
    The very concept of “demand” seems (especially in the Russian-language reading) not entirely correct in our case. Since we don’t have one customer who “requires” something, everything that we can do (potential “features”) can be described in very different terms (“wishes”, “offers”, “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 recorded thousands (many thousands) of wishes. Of course, it is even impossible to imagine that we will ever realize them all. Moreover, even if you do not take into account the time and complexity, then they all (all together) are simply not needed! And, therefore, the question always arises - what needs to be done now ?! By “now”, of course, we mean very different time ranges.

    It is easy to list the main sources - where do the wishes come from:
    • Wishes and ideas of developers of applied solutions
    • Wishes and ideas of partners
    • User wishes and ideas
    • Wishes and ideas of company management
    • Wishes and ideas of other units
    • What is implemented in some products on the market (both competing with us and not 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 does not reflect priorities. This is just a listing. Priorities are defined in a more complex way. About it 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 that are implemented.


    The choice of priorities (planning “features”) is now carried out by teams (previously this was done centrally).

    That is, the selection is made not from the general list, but from the team list.

    Team leader Tim, in consultation with team members, prioritizes potential tasks and forms a plan. Of course, the frequency of planning plays a role here (planning can take place over several time horizons), but this is a separate issue.

    The generated plan is discussed with other teams when required, and with project management. In this discussion, of course, decisions may change.

    We try to ensure that the team has a permanent “backlog” - a list of potential tasks, ranked by priority, for 2-3 stages of planning ahead.

    The methodology for selecting wishes in teams may vary slightly. This can be influenced by the features of the spectrum of functionality for which the team is responsible, and the team’s team lead preferences.

    Of course, this approach creates increased requirements for team team leaders, architects and team developers. They should understand how the platform is used, analyze the wishes of users and application developers, monitor IT trends, understand the direction of development of competing technologies. Here, competing technologies are understood not only (and often not so much) as business competitors, as existing and emerging technologies in specific areas. For example, for UI mechanisms of the platform, these 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 the team leader and responsible for some platform mechanism, in addition to all other qualities, also play the role of an analyst. Although this term is not used, this part of the work is very, very important.

    What and how to choose for implementation

    General directions of development and the most significant tasks are agreed with the director of the company. The director can both give recommendations and directly influence the decision. Of course, the choice of final decisions (at the team level, project management, director of the company) is subject to administrative subordination. But in practice this does not cause problems, since in the vast majority of cases it is possible to achieve 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.

    Firstly , the choice between new opportunities and the development of existing ones.
    There is no unambiguous criterion, all this is necessary and nothing can be sacrificed.
    We try to maintain a balance. Actively used functionality always generates a lot of wishes for development. We are trying to highlight what is critically lacking for effective use and what can drastically increase efficiency. But if we implement only what users and application developers ask for the development of existing capabilities, then “development” will remain “overboard” in strategic and promising directions.

    Secondly , the choice between improving reliability, performance and new features.
    Also a difficult choice. Of course, both are needed.
    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. There are quite tangible reasons for this.

    On the one hand, the use of 1C: Enterprise in a corporate environment constantly raises the requirements for scalability, reliability and performance. Implementations are becoming more and more (according to the number of competitive users, the volume of operations per unit time, the volume of functionality, ...). At the same time, accessibility requirements are also increasing. Permissible technological breaks are reduced, 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 in the transition to the cloud (working not at one but at thousands of enterprises) already require a completely different level of reliability and scalability.

    In addition, the process of computer rotation 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 old. It also requires us to make 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 it can take a lot of time to implement it (months, years). And in the presence of very important and very urgent needs now, we are putting significant efforts into promising tasks and directions. Perhaps they are not so urgently needed now, but if they are not done now, then they will not be tomorrow or the day after tomorrow. And then they can already become critical.

    For example, at one time we were reproached that we put a lot of effort into the creation and development of the web client, they said - look, 1C uses the web client, invest better resources in what the majority uses. But we considered (and continue to consider) the development of the web client as a very important area; if we didn’t have a full-fledged web client now - we would lose significantly in comparison with competitors, our products could not be introduced where the presence of full functionality when working in the browser is a necessary condition. And this fact, undoubtedly, would negatively affect all our users as a result. But now we have an important competitive advantage. We have both a web interface and a native interface. Moreover, the development of the 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 current IT development trends. It is necessary to begin to take them into account in advance, when it will seem to users a waste of our time (instead of doing something useful). If you start supporting them when users start shouting about them in a voice, it will be too late.

    Accordingly, our task is to combine perspective tasks and directions in a reasonable proportion with the satisfaction of current needs.

    Typical techniques and planning approaches are poorly used to select promising areas. But this is probably a separate issue ...

    Fourth , the choice between the wishes received 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. A word processor, in general, is an entirely obvious thing, 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 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 came up with and implemented our idea. And it gave a very big effect. So, for example, the mechanisms of data exchange and distributed infobases and a data composition system were born . Yes, and the concept of configuration objects(business objects - reference books, documents, information registers, etc.), which is the cornerstone of the 1C: Enterprise platform, arose as an idea of ​​the 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 don’t put any idea into action until we understand what benefit it will bring.

    How does the “statute of limitations” affect?

    The deadline for recording wishes should not affect the decision.
    You can often come across such a complaint - “it was asked 5 years ago, but you still haven’t done it.”

    Yes, we believe that “asked 5 years ago” is not an argument.
    Wishes form neither a queue nor 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, now may not be very useful, or maybe even harmful.

    And, most importantly, the choice must be made in comparison with the current set of other possible tasks and directions of development. Moreover, it is as of the current moment, but always taking into account the future. That is, we evaluate what we need today, tomorrow and the day after tomorrow.

    If, for example, we did not manage to implement something in some mechanism at the current stage, then the remaining unrealized functions do not automatically fall into the plan of the next stage, but are considered on an equal footing with other potential tasks.

    By the way, if you mentally imagine that we will now begin to systematically implement the wishes received 5-10 years ago, then it will be very funny.

    To what extent do we take into account the number of requests for a specific request?

    In general, we take into account. But this is not the main criterion. This is additional information for priority selection. We understand that there are objects in which the number of appeals can indicate the importance of a wish, and there are objects 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 didn’t do it, because you have to do it for a couple of hours”
    Well, firstly, often (even very often) this assessment from the outside does not take into account the realities of development. To fully design a small change (to take into account its effect in different situations on different system mechanisms) often takes significantly more time than the actual implementation. Well, another important aspect. We can not afford to implement the first solution that comes to mind. Because the mechanisms of the platform are involved in hundreds of applications for many years.

    Accordingly, you need to consider several options for solving the problem and choose the most correct one.

    Secondly, it is not clear why, in fact, you need to choose exactly what is easier and faster to do? It seems that what needs to be done is more important. Again, imagine that we will do everything that is simpler. What kind of system will it be ...

    It happens that we include a small task in the plan because it can be done at a certain point in time, because at this moment, we need a small timeout between two scheduled tasks. But these are rare cases.

    It happens that when analyzing a small task that they wanted to include in the plan, it turns out that the complexity (and sometimes the scale of the changes itself) will be much greater 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 large enough with such effort or such significant changes.

    One of our approaches to the selection of priorities is as follows:
    • Tasks are selected that solve the most acute problems that users and application developers currently have,
    • The tasks that will give the greatest effect on improving the work are selected (according to our assessment and the evaluation of those with whom we consulted),
    • The “most-most” of both groups is included in the plan in a certain proportion (for example, equally), so much as to be in time in the allotted time by optimistic time expenditures.

    We also use, for example, this approach:
    • A certain (initially selected by expert) set of wishes is selected,
    • For each request, priority ratings on a 5-point scale are entered:
      • from the point of view of users
      • from the point of view of developers of applied solutions (ours and partner),
      • from the point of view of the platform development team.
    • The received numbers are summed up and wishes are sorted according to the received priorities.

    This allows you to take into account the views 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 wishes, ideas and critical needs are built 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 attractive ones. Sometimes casting includes several tours.

    For example, first of the hundred applicants, 20 finalists are selected, then, from 20, 5 winners are selected. And the rest are waiting for the next contest.

    In addition to the described methods and factors, of course, there are some more factors (more mundane) that also affect plans.

    Decision making is influenced, of course, by the current situation with the loading of specialists.
    For example, if two tasks selected by priority require the active participation of the same specialist, then one of them has to be postponed.

    Still, periodically, “urgent introductory” happen. For example, the developers of a browser decided to change something in the requirements for applications. Here you have to quickly review plans. Given the wide range of supported platforms (operating systems, DBMS, browsers, mobile operating systems, ...) this, unfortunately, is not becoming such a rare occurrence.

    About automation

    We have centralized and very detailed automated processes for implementing tasks and working with errors (task-tracking, bug-tracking). The selection process is more complicated. At some point, we implemented a unified automated system for selecting and prioritizing wishes. It turned out to be very complicated, but did not cover the real needs of development teams.

    Now the wishes themselves are recorded in a certain registry, but the selection and prioritization of wishes is done not by a single tool, but by each command separately with specific automation techniques and methods.

    Perhaps we will return to this issue someday.

    We have not yet made a publicly accessible public wish list.
    This turned out to be a rather complicated matter (not technically, but methodologically).
    Regarding the collection of wishes, we have implemented a mechanism for collecting ideas for application users as part of the service . It works quite successfully. A number of wishes also appear on the platform there (for the part that is directly visible to users), but, of course, this resource is mainly focused on the functionality of applied solutions.

    On the platform, on the other hand, we made a resource for publishing errors ( ). By the way, it was also not so simple.

    Sometimes we arrange targeted polls on the forum for specialists on the wishes of a particular topic, in order to understand current opinions on priorities. Usually we do this when we start planning in some direction and feel a lack of information.

    Although we do not have a public 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 have everything 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 broader. Not just to choose the most necessary from all the written wishes, but to create something new that will bring significant value to our developers and users and make the world a better place!

    After all, a common goal can be formulated, usually quite simply. For us, this is to create the world's best business application development platform.

    In general, the selection of development directions and implemented functions in our situation is a very fascinating and difficult 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 a better place.

    Also popular now: