Regardless of the scale of the project, even with a limited budget and deadlines, you can not refuse to draw up project documentation. You risk losing not only money, but also an irreplaceable resource - time.
You came up with a business idea. Wonderful! Before you start calculating the profit, you need to understand how promising it is. Even if you see 10 similar successful projects, it does not mean that your 11 will repeat their success. For at least two reasons:
You need to analyze the market and competitors. Thanks to it, you will not only get an idea of the real competitors of your project, but also an analysis of what makes your competitors successful, their weak points, and performance indicators. Specialized companies conduct such research.
Even if your project doesn't involve direct sales, you need a plan. Even if your task is educational and you do not get even an indirect profit from the project, your expenses will be quite real and financial. The exception will not be the case when you can do everything yourself - in this case, your costs will be determined by your time, and it is also worth something.
Anyone can make an approximate business plan. The plan is best divided into 3 blocks, indicating the control points:
What is important to consider when compiling it:
Don't forget to take into account taxes and accounting expenses, including commissions for transfers and payments.
Naturally, there should be three plans:
We recommend that you create a small table and add the coefficients to the settings (variables) so that you can experiment with the numbers. The details of this plan are entirely up to you.
It is at this stage that the main KPIs of the project are laid, which in the future will need to focus on.
If the expenses are more or less clear, then the income level is much more complicated. The most reasonable approach is to start from the average values for the industry, competitors, or projects that are as close as possible.
In order to get this data, you can order a study, or conduct it yourself.
An important part of any business plan is the description of possible risks. In addition to identifying them, we recommend at least briefly describing the scenario for the actions/ costs necessary to eliminate them.
In addition to fixing the risk itself, it is necessary to assess the probability of its occurrence and the costs entailing its occurrence. Risk management is a separate area, which has been written quite a lot of books, but in General you can assess the overall risks for your investment.
If the business plan is a table with numbers, then the roadmap is more like a list. The document is drawn up for the next year, after which it is updated. It should reflect all stages of project development and development. The document format is usually free-form. We recommend that you include the following information:
If a project is implemented in a dynamic area, it can represent a tree with different scenarios. For example, if your project is related to blockchain, then a significant change in the legislation governing such technologies may have a significant impact.
In addition to the external functionality of the project, you need to think about the following:
You need to start describing processes from the most basic ones, moving on to secondary ones, and describing subprocesses. Processes are described in the form of flowcharts.
If you already have an infrastructure and the project you are launching becomes a part of it, then you need to describe how it integrates into your existing processes.
The described processes will allow you not only to formulate more precisely the requirements for the technical implementation of the project, but also to maintain the company's knowledge base.
This is the primary document that defines the requirements for the project and its functionality. Requirements are grouped into blocks, such as requirements for the catalog, layout, and SEO.
If a particular item can be implemented in different ways, please describe your expectations of its operation. Do not rely on “standard functionality” - this wording is only acceptable if we are talking about a standard element of a commercial product, such as a CMS. With such vague wording, you create a "gray area” that can serve as a" time bomb” and spoil relations with your contractor.
Do not rely on the fact that developers are professionals and will understand you correctly or ask the right questions. There is a chance, but you didn't come to the casino.
Let's look at the example of several real cases (below we give quotes with the wording of clients):
The filter is directly related to product properties.properties can be of different types, and there may be separate requirements for filtering results. At the same time, filtering is one of the most important factors that affect conversion rates and your target audience. This functionality should be discussed with the developers. We recommend that you first study similar projects with successful solutions.
Search can also be implemented in different ways, especially when there is a large amount of data, because in this case, questions arise about its performance. To determine which way to go, we recommend that you study the query statistics for existing resources and the wordstat statistics. The most flexible in terms of settings and fast-acting is ElasticSearch.
This point requires clarification not so much technical as organizational. Again, this is a functionality, not the main goal-increasing loyalty, and as a result, increasing sales. Only reviews from real users are valuable, and not all of them will be positive. Therefore, you need to think about who will respond to reviews, and, most importantly, how they will be replenished - perhaps through additional motivation of your customers. Check whether your requirements provide the functionality needed for this, and you have thought through the appropriate process.
In any integration, even regular integration should include the following list of data:
If integration involves receiving data, then you must describe what should happen when it is received, preferably accompanied by a business process that involves both a failure in integration and a rollback to previous versions of the received data.
I would like to say something about this common format separately - the format as a structure is very good. But it has several significant drawbacks:
Code placement, account setup, and debugging are separate subprojects. The TOR for this stage takes 8-10 pages for extended e-Commerce. Installation and configuration can also be implemented differently, depending on the specifics of your project and accounting system. It is optimal to approach this issue at the final stage of the project after receiving expert advice.
Often such functionality is implemented as a form, but in reality it often requires close integration with the sales system, so even this seemingly simple functionality requires clarification.
Using internal banners implies the logic of their output. It must be described, taking into account how banners will be displayed on mobile devices. Do not forget that internal banners are ineffective. Their functions are much better performed by other blocks.
The discount system is a fairly complex functionality that can have many implementations from a simple fixed discount on a product, to a discount for a certain group of users on a certain category of products. The discount system needs not only a description, but also support on the side of the systems that you plan to integrate with.
We do not recommend limiting the use of any technologies, if they are not due to low availability or specific requirements for client SOFTWARE. If you have any concerns and you are not very well versed in technology, it is better to describe them in a free form in a separate block, and ask the contractor or third-party specialist to comment on them.
A question that occurs quite often. The adviser is an extension installed in the user's browser. in Other words, you can't influence it. It works mainly on the basis of micro-markup of data, which is done for search engines. That is, marking up data otherwise you will not give it " food”, but you will lose in SEO. Various blocking scripts appear periodically, but they are active until the next update of the Adviser. Note that if your offer appears in the Adviser, you will be happy to do so. Remember that the process of making a purchase decision involves getting to know several offers, and the adviser is only one of them. Price is not always the deciding factor. The solution to this question lies in the area of your unique trading offer, and how you communicate this information to the client.
This is the case when the requirement should not just be declared, but should be explained: what it is caused by or what the purpose is. I.e., the actual requirement is not indicated in the document, but only the result is made. It is important not to forget the following points - the real value of each requirement, and that some requirements may be only hypotheses. The real value is the ratio of how much the implementation of the item will bring or how much you will lose in its absence and how much you will spend on its implementation.
For SEO project requirements, it is better to take one of the checklists offered by SEO studios and attach it to this document. Then you will be able to control and get the result you need. With regard to SEO tricks, keep in mind that some of them will not work with the expected effect after changing the search algorithm, and some tricks may cause blocking in it. Therefore, we recommend only "white" methods of promotion.
Batch data processing is an important tool for almost any project. But it should imply the logic of data processing - creation, deletion, and the possibility of returning to earlier versions.
Prototype development is an integral part of launching a website or mobile app. Allows you to simulate the logic of the project with minimal costs, think through navigation, and solve usability problems.
The project is implemented interactively and tested using user scenarios. It can be developed for both the user part and the administrative panel of the project.
This is an important technical document that should be clear to you as a customer, project Manager, and developer. It should include all relevant information collected in the previous stages. It should be sufficiently detailed regardless of the methodology that your project will use (Waterfall/Agile). Assume that if something is not in the TOR, it will not be in the project. The cost of TK can be up to 15% of the cost of its implementation.
During the project implementation process, you may need to update it, this is absolutely normal, but do not forget to update the document that will form the basis of the project documentation. But keep in mind that making changes may affect the timing and final cost of the project.
As soon as your project gains momentum, it will begin to develop and constantly modernize, and the people involved in the project (including various contractors) will be replaced as a kaleidoscope, in order to provide information about the logic of work, previous decisions and the overall architecture. To do this, you need to maintain the Knowledge Base. There are many solutions from specialized SOFTWARE to wiki in Bitrix 24.