Qualitatively, quickly, inexpensively - divide and conquer

    Many articles have already been written on how to quickly launch projects. Make the simplest version that will show the 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 state some of my thoughts about such cases.

    Everything written below refers to projects that are not initially looking for investors and their path does not begin 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, thoughtful, promising. However, you still do not know exactly how it will generate income. You can make paid subscriptions, or sell the service “by the piece” or take a one-time payment for registration. There are not many monetization models, some will work.

    And here she is a mistake that will make itself felt very soon. Moreover, sometimes it seems that this error does not exist at all - users buy, but somehow it’s not enough, they signed up for a month and that’s all. Maybe the product is bad? Probably not.
    The point is that the erroneous opinion at the beginning of the project is the main thing to do, and then marketing specialists will sell it. If you are creating a product or service that you intend to initially sell, you need to think about the following things:

    1. What is the minimum functionality you can sell?
    2. What can be done quickly from this without loss of quality?
    3. How much will we take for this?


    Answering these questions is quite simple, because evaluating 1-2 features is much easier than estimating how much the entire service will cost in the complex at the end. Secondly, you must enter the market as quickly as possible. Only he will be able to show you the most effective ways to develop the service in the future.
    It would seem simple moments, but they are often forgotten against the backdrop of global technological challenges, development plans and the desire to make the perfect project.
    And to do this is not necessary at the very beginning. As soon as there is a mass of functionality, you just need to choose the one that you can offer the user and run such a mini-service.

    Surely many of you will think: "Here again, crutches to fence." Yes, sometimes this is accompanied by not very beautiful decisions. However, by launching such small parts of the project, you will save yourself from the problem of fat deadlines. When development has been going on for 4-5 months already, but in order to roll out what is needed, another 3 is needed. And again, if you design the architecture with this in mind, then the developers will not really grieve over the shit.

    All of the above essentially reveals the idea that you need to start 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 get as a result.


    Very strange, how is that? But it happens. Your idea is very concrete, but as soon as it develops in your head, many branches appear and they all seem very cool and useful. In this case, the essence is almost unchanged. And then there come periods when one direction gets a higher priority, the other a smaller one and vice versa. As a result of all this mess, we get a big bunch of raw functionality, which will be modified for a long time and it’s a shame to sell it.

    The solution is also largely general - we take what works and try to sell. If at least a little goes - we develop, if not - we stop development.
    Most likely a very ambiguous situation will turn out. There may be parts of the project that cannot be abandoned because they are fundamental and must be done well. And here the launch of a mini-service assembled from a pile of ready-made parts will give you time to finish important things comfortably and without haste without sacrificing quality.

    The same method can be used by project managers so as not to escalate the situation and not put pressure on developers.

    1. Define a list of all the system features
    2. Choosing the ones that you can sell
    3. We leave only ready-made or requiring minimal effort to complete
    4. We complete them and run


    Thus, it is possible to get out of crises when all the deadlines are over, and the project is in an incomprehensible state. Obviously, such special releases should not take more than a week. But this week you need to switch all forces, and then calmly continue the main development.

    And the last problem 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 evaluate the exact dates, and the assigned ones will be disrupted. This is because it is impossible to determine exactly how long it will take to solve a problem that the team has not previously encountered or only partially dealt with.
    This point is very important to consider otherwise you can get lost in the questions “when?” And “why?”

    Unfortunately, we have not yet been able to find some kind of systematic approach to solving this problem that would work in each case. And while in our projects we use the following methodology.

    A small period of time is set, say 1 day. These gaps measure progress. It all starts with the question “how to solve the problem?” And then a chain of such “how?” Is built. Sooner or later, we come to the final decision. Along the whole path of finding a solution, we set the time for emerging tasks. But without a global deadline.
    And so on, until it is clearly determined how much effort will be required. Of course, if progress has stopped, then an analysis is made of everything that has been solved and understood. The causes of stagnation and options for continuing the study are identified.

    It turned out maybe a little messy, so I will summarize a short result.
    If you have an idea and you decide to implement it, then before you plunge into the design, design and programming, think about the following questions.

    Monetization
    You are about to sell. This may not be the main goal, but nevertheless an important component. Therefore, decide what exactly you can sell in a month. And also think about in what format you will present it. Such experiments are best done as quickly as possible. You will definitely save time.

    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.
    You won’t be able to do everything on the fly; in the process there will be many adjustments of various kinds. If you take a long time, and want to provide a result for it, then with a high degree of probability you will not meet the deadline. Because you’ll get mired in refactoring, the desire to rewrite something, and so on. It will happen anyway. Natural evolution of probably any project. But if you understand this and periodically make “dirty” releases, then the main development will not be like a solid return of technical debts and getting stuck in a quagmire of deadlines.

    Estimation of time for solving new problems
    Divide the entire pool of tasks into standard ones that are easy to evaluate and research ones. This will eliminate a number of management problems. Deadlines will be respected better, and developers will be pleased that they are given the opportunity to solve interesting problems and are in no hurry with the results.

    All this is a consequence of personal experience and reflects many things that are written 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 where to start the project, but also how to save it if the problems described have already manifested themselves.

    Also popular now: