Quality, fast, inexpensive - divide and conquer
Already written many articles on how to quickly launch projects. Make the simplest version that will show the very essence of the project and run it - say many people with experience. And I absolutely agree with that. However, not all projects can be done in such a dynamic format. I would like to present some thoughts about such cases.
Everything written below concerns projects that are not initially looking for investors and their journey begins not with presentations and business plans, but with the purchase of a domain and two developers. In turn, this does not mean a complete lack of planning and business analysis.
So, you have an idea, such a good idea, well thought out, promising. However, you still do not know exactly how it will generate income. You can make paid subscriptions, or sell the service “piece by piece” or take a one-time payment for registration. Monetization models seem not much, some yes work.
')
And here it is a mistake that will make itself known not very soon. Moreover, sometimes it seems that this error is not at all - users buy, only somehow it is not enough, they all signed up for a month. Maybe the product is bad? Most likely no.
The fact is that an erroneous opinion at the beginning of the project is the main thing to do, and then marketers will sell. If you are creating a product or service that you intend to sell initially, you need to think about the following things:
It is quite simple to answer these questions, because it is much easier to evaluate 1-2 features than at the end to estimate how much the whole service will cost in the complex. Secondly, it is necessary to enter the market as quickly as possible. Only he can show you the most effective ways to develop the service in the future.
It would seem simple moments, but they are rarely forgotten against the backdrop of global technological challenges, development plans and the desire to make the perfect project.
And it is not necessary to do this at the very beginning. As soon as some mass of functionality appeared, you just need to select the one that can be offered to the user and start such a mini-service.
Surely many of you will think: "Here again, crutches crammed." Yes, sometimes it is accompanied by not very beautiful solutions. However, launching such small parts of the project will save you from the problem of heavy deadlines. When the development has already been going on for 4-5 months, but in order to roll out what is needed, 3 more is needed. And again, if we design the architecture taking into account this moment, then the developers will not grieve too much about the govnokod.
All of the above essentially reveals the idea that you need to run as quickly as possible. The next problem, which is similar to the previous one, is only expressed more technically.
Very strange, how is that? But it happens. Your idea is very specific, but as soon as it develops in your head, many branches appear and they all seem very cool and useful. At the same time, the essence almost does not change. And then there are periods when one direction gets more priority, the other less and vice versa. As a result of all this commotion, we get a large pile of raw functionality, which is a long time to finalize and ashamed to sell.
The solution is also in many ways common - we take what works and are trying to sell. If at least a little goes - we develop, if not - we stop development.
Most likely it will be a very ambiguous situation. There may be parts of the project that cannot be abandoned, because they are fundamental and need to be done well. And here launching a mini-service assembled from a pile of ready-made parts will give you time to complete important things without haste without sacrificing quality.
The same method can be used by project managers in order not to escalate the situation and not to put pressure on the developers.
Thus, it is possible to get out of crises, when all the deadlines are out, and the project is in an incomprehensible state. Obviously, such emergency releases should not take more than a week. But this week you need to switch all the forces, and then calmly continue the main development.
And the last problem that I would like to say
If your project does not consist only of standard solutions, but involves some research, then often you will not be able to estimate the exact dates, and the designated ones will be thwarted. This happens because it is impossible to accurately determine how long it will take to solve a problem that the team has not previously encountered or has only partially dealt with.
This moment is very important to consider otherwise you can get lost in the questions “when?” And “why?”
Unfortunately, we have not yet managed to find a systematic approach to solving this problem that would work in each case. And while in our projects we use the following methodology.
Set a short period of time, say 1 day. These intervals measure progress. It all starts with the fact that the question “how to solve the problem?” Appears and then a chain of such “how?” Is built. Sooner or later, we arrive at a final decision. All the way to find a solution, we set the time for emerging tasks. But without a global deadline.
And so on until it is clearly defined how much effort will be required. Of course, if progress has stalled, then an analysis is made of everything that has been resolved and understood. Reasons for stagnation and options for continuing research are identified.
It turned out maybe a little messy, so I will summarize a brief result.
If you have an idea and decided to implement it, then before plunging into design, design and programming, consider the following questions.
Monetization
You are going to sell. This is probably not the main goal, but nevertheless an important component. So decide exactly what you can sell in a month. And also think about the format in which you will present it. Such experiments are best set up as quickly as possible. Time you will definitely save.
Ideal vs releases
Develop a quality product, otherwise you will not feel the joy of the project. However, accept the fact that small releases with ineffective or ugly solutions will allow you to win a significant amount of time to develop the main product.
It’s not possible to do everything on the move, there will be many adjustments of a different nature in the process. If you take a long time, and want to provide a result to it, then with a high degree of probability you will not meet. Because you get bogged down in refactorings, wanting to rewrite something and so on. It will happen anyway. Natural evolution probably any project. But if you understand this and periodically do “dirty” releases, then the main development will not be like a solid return of technical debts and linking in the quagmire of deadlines.
Estimation of time for solving new tasks
Divide the entire pool of tasks into typical ones that are easy to evaluate and research. This will relieve from a number of problems with management. Deadlines will be observed better, and developers will be satisfied with the fact that they are given to solve interesting problems and are not in a hurry with the results.
All this is a consequence of personal experience and reflects many things about which they write in books about startups. But as practice has shown, there are moments that need to be felt in order to understand their significance. And the above describes not only what to start the project with, but how to save it if the described problems have already appeared.
Everything written below concerns projects that are not initially looking for investors and their journey begins not with presentations and business plans, but with the purchase of a domain and two developers. In turn, this does not mean a complete lack of planning and business analysis.
So, you have an idea, such a good idea, well thought out, promising. However, you still do not know exactly how it will generate income. You can make paid subscriptions, or sell the service “piece by piece” or take a one-time payment for registration. Monetization models seem not much, some yes work.
')
And here it is a mistake that will make itself known not very soon. Moreover, sometimes it seems that this error is not at all - users buy, only somehow it is not enough, they all signed up for a month. Maybe the product is bad? Most likely no.
The fact is that an erroneous opinion at the beginning of the project is the main thing to do, and then marketers will sell. If you are creating a product or service that you intend to sell initially, you need to think about the following things:
- What is the minimum functionality you can sell?
- What can be done from this faster without losing quality?
- How much will we take for it?
It is quite simple to answer these questions, because it is much easier to evaluate 1-2 features than at the end to estimate how much the whole service will cost in the complex. Secondly, it is necessary to enter the market as quickly as possible. Only he can show you the most effective ways to develop the service in the future.
It would seem simple moments, but they are rarely forgotten against the backdrop of global technological challenges, development plans and the desire to make the perfect project.
And it is not necessary to do this at the very beginning. As soon as some mass of functionality appeared, you just need to select the one that can be offered to the user and start such a mini-service.
Surely many of you will think: "Here again, crutches crammed." Yes, sometimes it is accompanied by not very beautiful solutions. However, launching such small parts of the project will save you from the problem of heavy deadlines. When the development has already been going on for 4-5 months, but in order to roll out what is needed, 3 more is needed. And again, if we design the architecture taking into account this moment, then the developers will not grieve too much about the govnokod.
All of the above essentially reveals the idea that you need to run as quickly as possible. The next problem, which is similar to the previous one, is only expressed more technically.
We do not know what we want to receive as a result.
Very strange, how is that? But it happens. Your idea is very specific, but as soon as it develops in your head, many branches appear and they all seem very cool and useful. At the same time, the essence almost does not change. And then there are periods when one direction gets more priority, the other less and vice versa. As a result of all this commotion, we get a large pile of raw functionality, which is a long time to finalize and ashamed to sell.
The solution is also in many ways common - we take what works and are trying to sell. If at least a little goes - we develop, if not - we stop development.
Most likely it will be a very ambiguous situation. There may be parts of the project that cannot be abandoned, because they are fundamental and need to be done well. And here launching a mini-service assembled from a pile of ready-made parts will give you time to complete important things without haste without sacrificing quality.
The same method can be used by project managers in order not to escalate the situation and not to put pressure on the developers.
- Determine the list of all system features
- Choose those that can be sold
- We leave only finished or requiring minimal effort to complete
- Finish them and run
Thus, it is possible to get out of crises, when all the deadlines are out, and the project is in an incomprehensible state. Obviously, such emergency releases should not take more than a week. But this week you need to switch all the forces, and then calmly continue the main development.
And the last problem that I would like to say
Timing and Innovation
If your project does not consist only of standard solutions, but involves some research, then often you will not be able to estimate the exact dates, and the designated ones will be thwarted. This happens because it is impossible to accurately determine how long it will take to solve a problem that the team has not previously encountered or has only partially dealt with.
This moment is very important to consider otherwise you can get lost in the questions “when?” And “why?”
Unfortunately, we have not yet managed to find a systematic approach to solving this problem that would work in each case. And while in our projects we use the following methodology.
Set a short period of time, say 1 day. These intervals measure progress. It all starts with the fact that the question “how to solve the problem?” Appears and then a chain of such “how?” Is built. Sooner or later, we arrive at a final decision. All the way to find a solution, we set the time for emerging tasks. But without a global deadline.
And so on until it is clearly defined how much effort will be required. Of course, if progress has stalled, then an analysis is made of everything that has been resolved and understood. Reasons for stagnation and options for continuing research are identified.
It turned out maybe a little messy, so I will summarize a brief result.
If you have an idea and decided to implement it, then before plunging into design, design and programming, consider the following questions.
Monetization
You are going to sell. This is probably not the main goal, but nevertheless an important component. So decide exactly what you can sell in a month. And also think about the format in which you will present it. Such experiments are best set up as quickly as possible. Time you will definitely save.
Ideal vs releases
Develop a quality product, otherwise you will not feel the joy of the project. However, accept the fact that small releases with ineffective or ugly solutions will allow you to win a significant amount of time to develop the main product.
It’s not possible to do everything on the move, there will be many adjustments of a different nature in the process. If you take a long time, and want to provide a result to it, then with a high degree of probability you will not meet. Because you get bogged down in refactorings, wanting to rewrite something and so on. It will happen anyway. Natural evolution probably any project. But if you understand this and periodically do “dirty” releases, then the main development will not be like a solid return of technical debts and linking in the quagmire of deadlines.
Estimation of time for solving new tasks
Divide the entire pool of tasks into typical ones that are easy to evaluate and research. This will relieve from a number of problems with management. Deadlines will be observed better, and developers will be satisfied with the fact that they are given to solve interesting problems and are not in a hurry with the results.
All this is a consequence of personal experience and reflects many things about which they write in books about startups. But as practice has shown, there are moments that need to be felt in order to understand their significance. And the above describes not only what to start the project with, but how to save it if the described problems have already appeared.
Source: https://habr.com/ru/post/162429/
All Articles