How to find a vector of software development? Planning as a science
The basic principle on which we develop Macroscop today is “to hear the user and do that and in the way he needs.” We didn’t just come up with such a strategy for ourselves, but got it from our own experience, and this path took us 6 years. We told about it in one of the previous posts . At the same time, we are confident that the way of exclusively meeting the current needs of users cannot make the company the absolute market leader. And if you want it, you need to do something that no one does, to embody in your development what others seem impossible.
How to determine the vector of product development and combine its usefulness and innovativeness? In order to make our new developments more likely to “hit the target,” it was decided to conduct an in-depth study and, based on its results, plan a new version. Macroscop's development strategy is determined by the product manager of the company, and by what algorithm he acted:
In order to find all the options for new features, enhancements and improvements, Macroscop product manager:
')
• communicated with real users of the product. These were personal conversations with dozens of people at meetings or via skype, during which their current needs, ideas and problems were discussed;
• communicated with the technology leaders of the industry at exhibitions, forums and conferences;
• communicated with the technical support and quality group of the company in order to understand their vision of the necessary changes and improvements based on the analysis of user problems;
• analyzed the annual goals of the developers (each employee of the company formulates his personal goals at the beginning of the year);
• analyzed about 10 thousand ratings and comments to the demo version of Macroscop from those who tested it;
• analyzed which video analytics modules are purchased more often;
• analyzed requests for software improvements from large customers;
• asked sales managers, pre-engineers and partners training specialists to make their own vision of the necessary improvements and developments based on their communication with partners within their areas of activity.
On the whole way of collecting and processing ideas, we did not rule out anything and did not change, considering that there can be no nonsense in the users' proposals. The result was about 250 points. Without discarding or deleting anything, we simply excluded all duplicates, as a result 130 preliminary ideas remained.
If we were unlimited in resources, we would implement all 130 ideas. But it was necessary to choose specific tasks. To do this, we weighed each idea by 10 parameters. If you do not go into details, it all came down to 2 parameters - innovation and the need for users right now.
An entire set of scales with varying degrees of influence was responsible for the need: the wishes of users directly, the wishes of managers, the wishes of developers, etc. The second assessment, the assessment of innovativeness, was made speculatively: we ourselves sat down and thought how innovative an idea was.
Next, we built such a graph: innovation was postponed on one axis, on the second - the need for users right now. Each idea turned into one of the points on this graph with coordinates (weight of innovation; weight of need)
Obviously, you cannot implement all 130 tasks within the next versions, but you should choose those that are closer to the area (+ ∞; + ∞). That is, the ideal task is superinnovational and necessary for users right now, the one for which users are ready to pay money today and use it.
We divided the schedule into 3 zones:
1 zone (above the red line) - these are the ideas that must be implemented necessarily. They have both a high level of innovation and a high level of need.
2 zone (between the red and green lines) - we solve these tasks whenever possible.
Zone 3 (below the green line) - non-innovative and unnecessary tasks (by the way, most of these 130 ideas got there). And we don't make them.
As a result, we received a list of priority functions and improvements that users need and at the same time are very likely to single out us in the market and allow us to strengthen our leadership position.
There is a formula: goal = dream + deadline. And without clear deadlines, all our plans were not goals. The situation was complicated by the fact that we (like many developers) sometimes sinned by delaying the internal release dates of the versions that we set ourselves.
Therefore, it was necessary to think over real, but ambitious deadlines for the implementation of new functions and improvements according to the list we will observe.
Pavel Durov said that every month you need to release a certain number of improvements. In his blog, he described 7 improvements on VKontakte every month: 7 improvements in November, 7 improvements in December, etc.
We found the position “Do what you want, but release 7 updates per month and rhythmically develop your product” strong and decided to apply it in Macroscop (naturally, having adapted it to our specifics).
The product manager of the company discussed a new strategy and a period of 1 month with the developers, and after long discussions of constructive discussions, they agreed that we will release a new version every 1.5 months.
When the technical director, who is responsible for testing new versions of the product, learned about the term of 1.5 months, he said that this is impossible, because now we are testing each version for 3 months. Because the developers add only new features and improvements, and they are testing not only new products, but ALL FUNCTIONAL from scratch. The version that came from the developers is a black box, which they have to check up and down.
As a result, after another dispute of constructive discussions, we decided that every 1.5 months we will release a new version, but every second version will be internal. That is, we will do it, we will implement in it a certain number of improvements, but we will not give it to the tests. Then we will make the next version, and here its quality group will take in tests.
Total it turns out that every 1.5 months we release a version, but the user leaves every second, tested version. To understand how many improvements we have to release every 1.5 months, we analyzed the previous speed of our development and got the same figure 7, which in our case included: 1 completed innovation step (some kind of new video analysis module or a significant improvement of the current module) + 2 important user functions or significant improvements + 4 other functions or improvements.
Another important aspect that we have introduced to improve the quality of the product is the direct communication of developers with users. Previously, the chain of receiving requests from users was very long: the user said something to his manager - the manager said this to the product manager - the product manager said this to the developers, and finally, they developed it. As a result, sometimes it turned out that what the developers did was not quite coincide with what users initially needed. And it turned out not through the fault of any particular person, but simply because there were many links in the chain, and some of the information on each such link was lost.
Now that we have a clear list of what needs to be done, we need to understand how to do it as well as possible. And for this, Macroscop developers communicate with users - they call or come to them on objects and understand, and how they want it to look. And, it should be noted, in the course of such validations of our hypotheses, we find many things that we were not aware of.
We have developed and introduced all these innovations 2.5 months ago. In order to understand how accurately we focused and whether we built the development process correctly, much more time must pass. However, according to the plan, at the end of September we released 1 new internal version, in which we implemented 7 planned improvements.
Turning planning into an exact science
How to determine the vector of product development and combine its usefulness and innovativeness? In order to make our new developments more likely to “hit the target,” it was decided to conduct an in-depth study and, based on its results, plan a new version. Macroscop's development strategy is determined by the product manager of the company, and by what algorithm he acted:
1. Reveal all ideas. There may be many, many
In order to find all the options for new features, enhancements and improvements, Macroscop product manager:
')
• communicated with real users of the product. These were personal conversations with dozens of people at meetings or via skype, during which their current needs, ideas and problems were discussed;
• communicated with the technology leaders of the industry at exhibitions, forums and conferences;
• communicated with the technical support and quality group of the company in order to understand their vision of the necessary changes and improvements based on the analysis of user problems;
• analyzed the annual goals of the developers (each employee of the company formulates his personal goals at the beginning of the year);
• analyzed about 10 thousand ratings and comments to the demo version of Macroscop from those who tested it;
• analyzed which video analytics modules are purchased more often;
• analyzed requests for software improvements from large customers;
• asked sales managers, pre-engineers and partners training specialists to make their own vision of the necessary improvements and developments based on their communication with partners within their areas of activity.
On the whole way of collecting and processing ideas, we did not rule out anything and did not change, considering that there can be no nonsense in the users' proposals. The result was about 250 points. Without discarding or deleting anything, we simply excluded all duplicates, as a result 130 preliminary ideas remained.
2. Weigh each idea
If we were unlimited in resources, we would implement all 130 ideas. But it was necessary to choose specific tasks. To do this, we weighed each idea by 10 parameters. If you do not go into details, it all came down to 2 parameters - innovation and the need for users right now.
An entire set of scales with varying degrees of influence was responsible for the need: the wishes of users directly, the wishes of managers, the wishes of developers, etc. The second assessment, the assessment of innovativeness, was made speculatively: we ourselves sat down and thought how innovative an idea was.
3. Visualize the distribution
Next, we built such a graph: innovation was postponed on one axis, on the second - the need for users right now. Each idea turned into one of the points on this graph with coordinates (weight of innovation; weight of need)
Obviously, you cannot implement all 130 tasks within the next versions, but you should choose those that are closer to the area (+ ∞; + ∞). That is, the ideal task is superinnovational and necessary for users right now, the one for which users are ready to pay money today and use it.
We divided the schedule into 3 zones:
1 zone (above the red line) - these are the ideas that must be implemented necessarily. They have both a high level of innovation and a high level of need.
2 zone (between the red and green lines) - we solve these tasks whenever possible.
Zone 3 (below the green line) - non-innovative and unnecessary tasks (by the way, most of these 130 ideas got there). And we don't make them.
As a result, we received a list of priority functions and improvements that users need and at the same time are very likely to single out us in the market and allow us to strengthen our leadership position.
Translate idea into goal
There is a formula: goal = dream + deadline. And without clear deadlines, all our plans were not goals. The situation was complicated by the fact that we (like many developers) sometimes sinned by delaying the internal release dates of the versions that we set ourselves.
Therefore, it was necessary to think over real, but ambitious deadlines for the implementation of new functions and improvements according to the list we will observe.
Pavel Durov said that every month you need to release a certain number of improvements. In his blog, he described 7 improvements on VKontakte every month: 7 improvements in November, 7 improvements in December, etc.
We found the position “Do what you want, but release 7 updates per month and rhythmically develop your product” strong and decided to apply it in Macroscop (naturally, having adapted it to our specifics).
The product manager of the company discussed a new strategy and a period of 1 month with the developers, and after long discussions of constructive discussions, they agreed that we will release a new version every 1.5 months.
When the technical director, who is responsible for testing new versions of the product, learned about the term of 1.5 months, he said that this is impossible, because now we are testing each version for 3 months. Because the developers add only new features and improvements, and they are testing not only new products, but ALL FUNCTIONAL from scratch. The version that came from the developers is a black box, which they have to check up and down.
As a result, after another dispute of constructive discussions, we decided that every 1.5 months we will release a new version, but every second version will be internal. That is, we will do it, we will implement in it a certain number of improvements, but we will not give it to the tests. Then we will make the next version, and here its quality group will take in tests.
Total it turns out that every 1.5 months we release a version, but the user leaves every second, tested version. To understand how many improvements we have to release every 1.5 months, we analyzed the previous speed of our development and got the same figure 7, which in our case included: 1 completed innovation step (some kind of new video analysis module or a significant improvement of the current module) + 2 important user functions or significant improvements + 4 other functions or improvements.
User - the main expert
Another important aspect that we have introduced to improve the quality of the product is the direct communication of developers with users. Previously, the chain of receiving requests from users was very long: the user said something to his manager - the manager said this to the product manager - the product manager said this to the developers, and finally, they developed it. As a result, sometimes it turned out that what the developers did was not quite coincide with what users initially needed. And it turned out not through the fault of any particular person, but simply because there were many links in the chain, and some of the information on each such link was lost.
Now that we have a clear list of what needs to be done, we need to understand how to do it as well as possible. And for this, Macroscop developers communicate with users - they call or come to them on objects and understand, and how they want it to look. And, it should be noted, in the course of such validations of our hypotheses, we find many things that we were not aware of.
We have developed and introduced all these innovations 2.5 months ago. In order to understand how accurately we focused and whether we built the development process correctly, much more time must pass. However, according to the plan, at the end of September we released 1 new internal version, in which we implemented 7 planned improvements.
Source: https://habr.com/ru/post/314040/
All Articles