What is the best way to start a project or how to make it so that it would not be excruciatingly painful
Good all the time of day. It was the turn to talk about designing projects. From my own experience I know that it is sometimes more difficult to create a project from scratch than to tidy up what is already there. This is largely due to the legacy you or you leave behind. In this article I will try to tell you what it is worth paying special attention to and suggest a short plan for following.
Understanding of the project
Before you plan something, you need to understand what project you need to implement. For myself, I have identified several categories of projects, such as:
- A one-time craft is a project aimed at creating some kind of graphic concept and its further sale to investors. Distinctive features of this type of project are:
- Insane documentation. The basic idea is clear, but business cases are in complete chaos, and there are no logical holes to consider.
- Short time. Up to 3 months from writing documentation to prototype.
- There are no development plans and no further support is planned.
- Small team. Usually up to 5 people, including designers.
- Lack of business processes. All interaction is chaotic, based on interpersonal communication, clarification of key points and / or inventing on the go.
- Roles are blurred. There is no clear division of powers and areas of responsibility.
- No real data. All data is generated for “beauty” and tailored for best display.
- To speed up development, external dependencies are used in full.
- A startup is a project that is configured to implement a specific idea, with subsequent development. Usually, these projects are developed according to a spiral model and, for this reason, have almost the same distinctive features as the first type (one-time craft):
- Clear breakdown into stages. Minimum: terms and a list of functionality that must be implemented in a given period of time.
- Relatively sane documentation. Analytics conducted, benchmarks for the completion stages set, refinements often come during the sprint. Most often use waterfall, despite the fact that Agile claimed.
- Average deadlines for the main functionality. On average, from 6 to 12 months.
- At the initial stages, external dependencies are used, which eventually change to their own implementation.
- Small team. Usually up to 7-10 people.
- There is a separation of roles, but responsibility is blurred.
- A project can mutate. At one stage, the concept or approach to implementation may change. Usually this is due to the requirements of investors, an initially failed idea or errors in architecture.
- Conditionally live data. Running in focus groups or parsing live data from third-party resources. True, this does not always happen ...
- An information system is a project that implements an idea with plans for integration into third-party services.
- There is a development plan.
- Clearly written documentation. Minimum: API description documented.
- You may need to integrate with third-party services, install crutches, or rebuild parts of the system.
- There are intermediate releases, hot fixes.
- Medium team. Usually from 10 to 20-30 people.
- Clear separation of responsibilities.
- Security requirements: after the analysis, cases are created that can lead to the collapse of the system.
- Time is devoted to testing.
- Used by Agile.
- There is almost always a backlog.
- Only external dependencies that are expensive to implement on their own are used. It is practiced on a par with proprietary ones.
- A closed system is a voluminous project designed to serve the specific needs of the Customer, with further refinement.
- Specific customer.
- There is a development plan.
- Design documentation for development. To help users, separate documentation has been written at the request of the Customer.
- Differentiation of user rights.
- There is almost always a backlog.
- Team size is usually larger than average. As a rule, from 10 people to a loss of heart rate.
- Used by Agile. From time to time, additional tasks arrive that must be implemented at all costs.
- Unexpected demonstrations. Demands take place at the request of the senior management, so a workable test circuit will never be redundant.
- Saas solution is a voluminous project with flexible configuration and further customization for a specific customer.
- Multimodular system. The system is divided into several parts. Which can be used individually, even outside the scope of a specific project.
- Clear planning. Minimum: labor costs are estimated for the implementation of features. The time is laid for modernization and refactoring.
- Volumetric documentation. Almost everything is described, as a rule, including test cases.
- As a rule, there are no external dependencies and their own implementations of parts of the system are written. Even if there are third-party implementations.
- Several development teams. Everyone is responsible for their part of the development, be it backing or front.
- Test coverage of everything and everything. Auto, unit, regression, and integration tests are used.
All gradations are conditional and flowing types are most often found. I want to note that all types can mutate into each other, the only nuance is in the cost of modernization. For example, the project was originally a “one-time craft”, and then evolved into a “closed system”. Usually, this leads to a complete or almost complete rewrite of the system or its refactoring. As you know, this is not economically feasible. For the same reason, it is advisable to understand what kind of project you need to create from scratch, and try to determine its future fate.
To determine the type of project, below I have given questions, having received an answer to which it will become clear to you what they want from you:
- Objective of the project?
- A complete list of what needs to be implemented?
- Is there any documentation?
- What are the deadlines? Accurate dates are desirable.
- Is external interaction planned with third-party systems, or will the project have an external API
- Are there any developments?
- Team size?
- Who is responsible for what? Who sets tasks, who accepts, who has veto rights.
- Are there any development plans and what are they?
- Who is the customer?
- Is there a budget for the purchase of turnkey solutions?
- What methodology do you plan to work on
- Are there any analogues?
As you can see, the list is not so big. However, for some unknown reason, few people ask such questions before starting to do anything. You ask why should I understand the type of project ?! You always have to make the project live forever ?! By and large, you are right, but there are nuances, as in a steamy joke. These nuances are resources and timelines. Do not forget that we work for the good of business and carry out the tasks. When you know the type of project, you can sacrifice something without a twinge of conscience to achieve your goals.
Technology selection
In the choice it is better to adhere to the rule: the technology should not be supernova, but also outdated too. If the technology or framework is new, this can result in problems such as:
- Search for qualified personnel
- Prospects for development: in the early stages, development may die, or, conversely, if the technology is old, then the bugs will have to be treated on their own.
- Lack of turnkey solutions for new ones, and lack of updates for old ones.
This list of problems is relevant not only regarding technology, but also to third-party dependencies. All of the above can bury the project in the bud.
Before you choose something specific, think a few times. Create a notorious table of benefits with importance factors for the project.
This example is for a fictional project:
The name of the project functionality. | Project Importance Ratio |
|---|---|
Work with forms | 3 |
Routing | 1 |
Ease of writing animation | 0.3 |
As can be seen from the table, the important criteria for selection are “work with forms” and “routing”. The simplicity of creating animation for this project is not significant. Next, we will upgrade the table by adding new technology columns. In our case, there will be two.
The name of the project functionality. | Project Importance Ratio | Technology 1 | Technology 2 |
|---|---|---|---|
Work with forms | 3 | + | ± |
Routing | 1 | + | ± |
Ease of writing animation | 0.3 | + | - |
Based on the data in the table, we understand that the “Technology 2” work with forms and routing are lame, and creating an animation is like calling Satan. As a result, the specific weight of this technology is 2. You ask why 2? Everything is simple! If you set ±, then in this technology a specific functional is implemented, but with some kind of “crutches”, or it’s more labor-intensive. In our comparison, “Technology 1“ will be more profitable, with a total of 4.3. I think the explanation on the formation of the amounts is unnecessary. This table works not only with technology, but with everything that requires comparison and selection from the list. The main thing is not to forget that the more criteria you write, the easier it will be for you to make a choice.
Architecture
Currently, it is possible to choose from a variety of different services that provide tools for architectural design. True, any of them has drawbacks, for some they are critical, but for someone not. Since I am “oldfag”, I prefer a piece of paper and a pen or a board and a marker.
In order to understand what to grab in the first place, you need to outline the main parts of the system, and then choose the way to build the architecture. As a rule, in practice, only three are used:
Descending - developers push from large nodes of the system and go to smaller ones. The meaning of architecture is that the priority components are large nodes that contain smaller ones.
Ascending - developers push from small parts and go to larger ones. The meaning of architecture is that at first a lot of small components are created, and larger ones are already assembled from them.
Monolith is an indivisible architecture, often referred to as “legacy”. In fact, this is a rigid structure, the change of which requires solutions without “crutches”. This is the worst option, but, like everything in our world, it has the right to exist. The monolith is used to implement specific functionality and do not plan to maintain it in the future. Compared to others, the speed of this approach is many times faster. Well, just because you can close your eyes to a lot.
The choice of architecture depends on the objectives of the project and the speed of development. Usually, the first method is used when the deadlines are not running out, and the number of large modules is small. Its feature is that it is possible to accurately represent the relationship between specific modules. Of the minuses, I can note a long development time associated with a sequence of actions.
The second method is preferred when high development speed is required and there is no understanding of the top-level architecture. A feature is the many small components that are sometimes used in different large units. It is worth noting that almost all development can be performed in parallel, without regard to other tasks. The disadvantages of this approach will be components that do not meet the requirements of the upper-level architecture and, accordingly, they will have to be rewritten or create the possibility of customization.
As practice shows, all development techniques are reduced to a spiral approach, characterized by a gradual build-up of functionality. I do not consider it appropriate to consider it within the framework of this article.
Planning
The so-called “Road Map” will help you do your job more efficiently. In fact, this is a schedule, with conditional deadlines for the delivery of a particular functional. Dates can be postponed, but, as practice shows, with proper implementation of the above points, the amendment will be up to 30%. In practice, this is usually 10-15%. Planning will allow you to track project progress, see sagging, make adjustments in the form of resources or a shift in deadlines, etc.
For which later they will thank you
Any project begins with documentation, and the more it is, the better! So do not be lazy - we document EVERYTHING. Yes, it will take some time, but subsequently it can save you from the wrath of the leadership if something goes wrong, not your fault. Also, do not forget that after you appear on the project people who will have to understand what you have created. And without documents, this will not be easy.
conclusions
This article describes how to act and what to look for when starting a project. These stages are universal for front, back, testing or all together. I deliberately avoided the specifics of technology, so as not to be misleading.
When you have a choice about which technology stack to use, architecture, and you need to determine the time frame for the project, the table below can help you:
Типа проекта / признаки | Одноразовая поделка | Стартап | Информационные системы | Замкнутые системы | Saas решения | Какие-то другие проекты |
|---|---|---|---|---|---|---|
Кол-во людей до 5 | X | X | X | X | ||
Кол-во людей от 7 до 10 | ||||||
Кол-во людей от 10 до 30 | X | |||||
Кол-во больше 30 | X | X | ||||
Срок сдачи до 3х месяцев | X | X | X | X | ||
Срок сдачи от 6 до 12 месяцев | ||||||
Срок больше 12 месяцев | X | |||||
Документация | ||||||
Требования интегрирования с другими системами | ||||||
Конкретный заказчик известен | ||||||
Планируется дальнейшая поддержка | ||||||
Планирование | ||||||
Роли четко разграничены | ||||||
Разрешено использовать внешние зависимости | ||||||
Есть живые данные для тестирования и анализа | ||||||
Требования по безопасности | ||||||
Требуется тестирование | ||||||
Требуется написание документации по продукту или инструкция | ||||||
Требуются модульная реализация | ||||||
Несколько команд разработки | ||||||
Всего |
How to use the table, I think everyone has already guessed, but just in case - exactly the same as with the previous one, only with a small addition in the form of filled cells. It means that the value cannot be used for this project. Also, please note that the table may be incomplete, add the rows that you consider necessary.