This article is meant to answer a single question: how we decide what to implement in 1C:Enterprise platform and when.
We rarely hear this exact wording, but questions like "Why did you do this?", "Why DIDN'T you do this?", "Why don't you do this?", "When are you going to do this?", "Will you ever do this or not?!!!", and so on, come up over and over again.
OK, let's try to explain how we decide what to do.
Of course, there are generally accepted requirements for management procedures.
Unfortunately, these regulate made-to-order developments, but we develop for mass production. And when we say "mass", we really mean it.
These procedures, unfortunately, have been developed for more practical tasks, and we work with a technological platform (framework).
It looks like the latter is not as important as the former.
The very notion of "requirement" doesn't seem quite right in our case. Since we don't have a single end customer that "requires" something, all that we do (potential features) can be described in very different terms (wishes, suggestions, needs, ideas, etc.).
We still don't have a consistent name for this.
Most often we use the term "suggestion", even though it doesn’t quite fit in some cases.
We have many thousands of suggestions recorded. It is impossible to even imagine that we will ever implement them all: not only is it time-consuming and labor-intensive — there’s simply no need for all of them together! So we always ask ourselves: what exactly should we do now? And "now", of course, means many different time ranges.
Also, it is quite simple to list the sources of such suggestions and ideas:
- Software developers
- Partners
- Users
- Corporate management
- Other divisions
- Features implemented in other products on the market (that may not necessarily compete with ours)
- Whatever comes from global IT and business development trends
- Our own ideas
We don't have dedicated analysts focused only on selecting the suggestions to be implemented.
The development team selects the tasks to be solved and determines the direction of our work.
Priorities
Currently, priorities are selected (features are planned) on a team level (even though it used to be centralized).
There is no general list from which to select. Instead, we use a team list.
A team leader discusses the priorities with team members, identifies potential priority tasks, and creates a plan. Naturally, planning frequency is important (there can be several time horizons in planning), but we won't go into too much detail here.
The plan is then discussed with other teams and with project management if needed. Of course, the decisions taken may vary during the discussion.
We always try to have a backlog for our teams, i.e. a list of potential tasks for two or three planning periods ahead ranked by priorities.
The procedure used to select suggestions in teams can vary a little. It is affected by the range of features for which the team is responsible or the personal preferences of the team leader.
Certainly, this sets very high demands for team leaders, architects, and team developers. They need to understand how the platform is used, analyze suggestions of application users and developers, monitor IT trends and understand the development of competing technologies. Competing technologies are not necessarily the technologies developed by business competitors (and very often they are not), but existing and emerging technologies in certain areas. For instance, if we are talking about UI technologies for platforms, we need to pay attention to modern UI frameworks, while universal data processing technologies (such as ORM) are important in the sphere of data processing.
Therefore, the team leader and the team member responsible for a certain platform technology play the role of analysts, among other things. We do not use the exact term "analyst", but this part of work is, of course, extremely important.
How we select what to implement
General directions of development and the critical tasks are agreed on with the head of the company, who may suggest something or affect the decision directly. Of course, when final decisions are made (at the team, project management or corporate management level), administrative subordination comes into play. It doesn't cause any troubles in real life since, generally, we come to a common understanding (consensus). And if opinions differ (and a directive decision is taken), opinions are explained and discussed. Therefore, nobody thinks that the board has too much influence over decision making.
We frequently face difficult choices.
First of all, we must choose between implementing new capabilities or developing existing ones.
There is no bright-line rule: everything is necessary and cannot be sacrificed.
We try to keep a balance. The functionality that is actively used always gives way to multiple development suggestions. We try to identify what is critically needed for effective use and what can critically improve performance. However, if we implement only what application users and developers ask us to implement to expand existing capabilities, some strategic and forward-looking ideas will be left in the dust.
Secondly, we have to make a difficult choice between improving reliability and performance,
or adding new functions. Of course, we need them all.
We analyze current requirements and try to find the optimal balance.
For instance, reliability and performance are the current issues of high priority. This has some substantial reasons behind it.
On the one hand, the use of 1C:Enterprise in corporate environments constantly raises demands for scalability, reliability and performance. Deployments get more and more complex (by the number of concurrent users, operations per unit of time, the scope of functionality, etc.). Requirements for availability also grow. Acceptable technological downtime shrinks, while the cost of error increases.
On the other hand, the emergence of a cloud model also demands increased scalability and reliability. Mass SMB applications are transferred to a cloud (where they are used by thousands of enterprises instead of just one) and require quite different reliability and scalability.
In addition, PC rotation has now slowed down. Therefore, our new functionality (which includes many useful and convenient features) should be supported by 6, 7 and even 10-year old PCs. This demands significant investments in optimization.
Thirdly, we have to choose between current needs and forward-looking developments.
It looks rather evident that if you want to develop a new feature or a brand new technology, it can take months or even years. We invest much effort into forward-looking tasks and areas of development, although we have a lot of important and pressing current needs. Maybe we are not in great need of them now, but if we don't develop them now, we won't have them tomorrow or the day after, when they may become critical.
Once we were blamed for putting too much effort into web-client development. The critics said, "Look, the 1C web client is used by so few users! Invest in something that is used by many". However, we saw (and still see today) web-client development as a vital area of development; if we didn't have a fully functional web client now, we would be significantly behind the competitors and couldn't deploy our products in environments where full functionality in a browser is a pre-requisite for deployment. This would, of course, negatively impact all our users. Fortunately, we now have a big competitive advantage. We have both a web interface and a native interface, and the development of this web interface does not take any additional effort; both interfaces are platform-generated based on the same application, and they look similar.
The same can be said of modern IT development tendencies. We need to take them into account earlier when users still think it is a mere waste of time. If we start to support them when users actively demand this from us, it will be too late.
Therefore, our main task is to find a perfect balance between forward-looking tasks and areas of development, and satisfying current needs.
Standard planning methods and approaches are of little help when forward-looking areas of development need to be chosen. But this is probably a separate matter...
Fourthly, we need to choose between the suggestions we receive and new ideas.
The most ground-breaking technologies that change the world (not only in IT) are rooted in ideas, not user suggestions. Let's talk about office software, for instance. Word processor is quite a straightforward thing that was developed when users said, "We want a typewriter but on our desktops". On the other hand, a spreadsheet is such a wonderful invention that it is difficult to imagine someone suggesting it. We have a lot of examples where we did not go from a ready-made suggestion or a solution implemented in other technologies but invented and implemented our own idea that had a wonderful effect. That's how data exchange technologies, distributed infobases and the data composition system were born. The concept of configuration objects (business objects: catalogs, documents, registers, etc.) that are the cornerstone of 1C:Enterprise platform appeared as an idea of a team of developers.
We do consider developers' ideas to be as important as the suggestions we receive.
Naturally, the ideas selected and implemented must be useful, and we are responsible for that. We don't give way to an idea until we understand how it can be useful.
Is time important?
The time of registering a suggestion should have no effect on the decision.
People regularly complain that they asked for something 5 years ago and it still hasn’t been implemented.
We believe that "requested 5 years ago" is not an argument.
We do not queue or stack suggestions.
We believe that the priorities should be evaluated at each stage in real time.
The situation is changing rapidly: what was useful 5 years ago may be of no use or even harmful today.
All choices should be made in comparison with the current set of other possible tasks and directions of development. We need to take into account both the current state and future considerations. We evaluate what is needed today, tomorrow and the day after tomorrow.
If we don’t have time to implement something in a certain technology at the current stage, the features that have not been implemented are not included automatically in the next stage's plan and are considered on an equal footing with other potential tasks.
By the way, it would be quite amusing if at this very moment we were to start methodically implementing requests received 5-10 years ago.
Do we take into account the number of requests related to a certain suggestion?
Of course, we do, but this is not the most important consideration. This is additional information that helps us select the priority. We understand that the number of requests may be very important in some cases but less important or even irrelevant in others.
Do you take into account the complexity of the task?
Yes, but there is no direct correlation.
We often hear something like "Why didn't you do this? It’d take only a couple of hours".
Well, first of all, often such evaluation does not take into account the reality of development. To fully design a small update (taking into account its impact on different system parts in different situations) takes significantly more time than the implementation of the update. Another important aspect: we cannot afford to implement every idea that comes to our heads, because platform mechanisms are utilized in hundreds of applications for many years.
So, we need to consider several options and select the very best way to solve the task.
By the way, why exactly should we choose something that is easier and faster to implement? In our opinion, we should work on the most important functions. Imagine for a second that we only implemented the easiest things. The system would be rubbish.
We may include a minor task in our plan because it can be completed at a certain time because at the moment we need a time-out between two scheduled tasks, but this is a rare case.
Sometimes we analyze a minor task that is to be included in a plan and understand that its complexity or even the scope of changes would be much more than expected. In some cases, this leads to excluding the task from the plan. For example, if the expected effect does not seem large enough to expend substantial effort or make critical changes.
Sometimes we use the following approach to select priorities:
- We select tasks to solve the most pressing user and developer problems.
- We select the tasks that will have the greatest optimization effect (we use our own evaluation and evaluation of those we consulted).
- We include tasks with the highest ranking from both groups in a certain proportion (in equal parts, for instance) in the amount that would let us meet the deadline in the optimistic scenario.
- We select a certain (initially selected by expert procedures) list of suggestions
- We rank their priority on a 5-point scale:
- from the users’ point of view
- from the application software developers’ point of view (both ours and partners’)
- from the platform development team’s point of view
- The numbers are aggregated, and the suggestions are ranked by priority.
It is a sort of audition or competition, in a way, in which suggestions, ideas, and critical needs are put in line on a catwalk and demonstrate their appeal. We evaluate them while taking into account the opinions of users, developers and our own colleagues and select the most attractive ones. Sometimes there are several rounds of such an audition.
For example, we may take a hundred options and compile a short-list of 20, and then select 5 winners out of these 20. The rest have to wait until the next competition.
Of course, there are other factors (more down to earth, so to speak) that affect our plans.
The current workload of our personnel is one of them.
For instance, if both of the selected priority tasks demand active contributions from the same team member, one of the tasks has to be postponed.
"Urgent inputs" are rather frequent as well. For example, developers of a certain browser decided to change some requirements for applications that use their browser. In this sort of situation, we need to quickly adjust our plans. This is not a rare thing, unfortunately, due to the wide range of our supported platforms (OS, database management systems, browsers, mobile OS, etc.).
As far as automation is concerned...
Our task-tracking and bug-tracking processes are rather well automated and centralized. It is a little more complicated with selecting suggestions. At some stage in the past, we implemented a single automated system for selecting and ranking suggestions. It was a highly complicated system that did not satisfy the real needs of the development team.
Currently, all suggestions are recorded into a register, but there is no unified selection and ranking of suggestions: each team uses its specific methods and automation methods.
We might return to this issue in the future.
As of today, we don't have a generally accessible public list of suggestions.
This turned out to be rather complicated from a methodological, not a technical point of view.
As far as the collection of suggestions is concerned, we've implemented an idea-gathering tool for application users based on the 1cFresh.com service. It works quite well. There are a number of suggestions about the platform (the frontend part), but, of course, this is mostly for functional issues.
Sometimes we arrange targeted surveys on expert forums to get to know their opinions about a certain subject and existing priorities. We usually do this when we start to plan in a certain direction and find out that we need more information.
Since we don't have a public resource to publish suggestions, we gather them carefully from multiple sources (including support desks, forums, communication with partners, developers and users during workshops, etc.). We have it all written down!
We might return to the idea of creating a public resource.
The existing methods of selecting ideas and suggestions are numerous, but we don't want to limit our mission to these: we don't want to merely select the most necessary of all the recorded suggestions; rather we want to create something new that will bring high added value to our developers and users and will make the world a better place.
The overall goal is usually quite easy to put into words: we want to develop the world's best platform for business application development.
Selecting the areas to be developed and features to be implemented is quite an interesting and challenging task. There are a lot of suggestions. We have a lot of ideas. We want to do a lot! And we need to select the optimal range of features that will indeed improve our world significantly.
