What is the best way to start a project or how to make it so that it would not be then painfully painful

Good all the time of day. It was the turn to talk about project design. From my own experience I know that sometimes it is more difficult to create a project from scratch than to put in order what is already there. This is largely due to the kind of legacy you or you leave behind. In this article I will try to tell you what to pay special attention to and suggest a short plan for following.

Understanding the project

Before you plan something, you need to understand what project you need to implement. For myself, I identified several categories of projects, such as:

• One-time hack is a project aimed at creating some kind of graphic concept and its further sale to investors. Distinctive features of this type of projects are:
  
  
  1. Insane documentation. The basic idea is understandable, but in business cases there is complete chaos, but logical holes can not be counted.
  2. Short time. Up to 3 months from writing documentation to the prototype.
  3. There are no development plans and no further support is planned.
  4. Small team. Usually up to 5 people, including designers.
  5. Lack of business processes. All interaction is confused, based on interpersonal communication, clarification of the fundamental points and / or inventing on the go.
  6. The roles are blurred. There is no clear separation of powers and areas of responsibility.
  7. No real data. All data is generated for “beauty” and fitted for the best display.
  8. External development is used to speed development.
  
  
• A startup is a project that is configured to implement a specific idea, with subsequent development. Usually, these projects are developed in a spiral model and, for this reason, have almost the same distinctive features as the first type (one-time hack):
  ')
  
  1. Clear division into stages. Minimum: the terms and the list of functionality that is necessary to be implemented in a given period of time
  2. Relatively imputed documentation. An analyst has been carried out, benchmarks have been set for the stages of completion, clarifications often come during the sprint. The most commonly used waterfall, despite the fact that Agile is declared.
  3. The average time for the delivery of the main functionality. On average from 6 to 12 months.
  4. At the initial stages, external dependencies are used, which eventually change to their own implementation.
  5. Small team. Usually up to 7-10 people.
  6. There is a distinction of roles, but the responsibility is blurred.
  7. The project may mutate. At one of the stages, the concept or approach to implementation may change. Usually this is due to the requirements of investors, initially a failed idea or errors in architecture.
  8. Conditionally live data. There is a run-in on focus groups or parsing of live data from third-party resources. The truth is not always the case ...
  
  
• An information system is a project that implements an idea with plans to integrate into third-party services.
  
  
  1. There is a development plan.
  2. Clearly written documentation. Minimal: API description is documented.
  3. You may need to integrate with third-party services, install crutches, or rebuild parts of the system.
  4. There are intermediate releases, hot fixes.
  5. The team is of medium size. Usually from 10 to 20-30 people.
  6. A clear division of areas of responsibility.
  7. Security Requirements: After analytics, cases have been created that could lead to a system crash.
  8. Takes time testing.
  9. Used by Agile.
  10. Almost always have a backlog.
  11. Only external dependencies are used, which are expensive to implement on their own. Practiced on a par with proprietary.
      
  
  
• A closed system is a voluminous project designed to serve the specific needs of the Customer, with further refinement.
  
  
  1. Specific customer.
  2. There is a development plan.
  3. Design documentation for development. To help users written separate documentation at the request of the customer.
  4. Differentiation of user rights.
  5. Almost always have a backlog.
  6. Team size is usually larger than average. As a rule, from 10 people to loss of pulse.
  7. Used by Agile. Periodically, additional tasks arrive that must be implemented at all costs.
  8. Unexpected demonstrations. At the request of the supervisor, demonstrations take place, so a workable test circuit will never be superfluous.
     
  
  
• Saas solution is a volumetric project with flexible configuration and further customization for a specific customer.
  
  
  1. Multimodule system. The system is divided into several parts. Which can be used separately, even beyond the scope of a specific project.
  2. Good planning. Minimum: an assessment of the labor costs for the implementation of features. It lays time to upgrade and refactor.
  3. Volume documentation. As a rule, almost everything is described, including test cases.
  4. As a rule, there are no external dependencies and written their own implementation of parts of the system. Even if there are third-party implementations.
  5. Several development teams. Everyone is responsible for their part of the development whether it is backing or front.
  6. Coverage tests of all and all. Auto, unit, regression, integration tests are used.
     

All gradations are conditional and most often overflow types are encountered. I want to note that all types can mutate into each other, the only caveat is the cost of modernization. For example, the project was originally a “one-time hack”, and then evolved into a “closed system”. Usually, this leads to a complete or almost complete rewriting of the system or its refactoring. As you understand, it is not economically feasible. For the same reason, it is desirable to understand which project you need to create from scratch, and try to determine its future fate.

To determine the type of project, below I brought questions, having received an answer to which you will understand what they want from you:

• Objective of the project?
• A complete list of what needs to be implemented?
• Is there any documentation?
• What is the timeline? Desirable exact dates.
• External interaction with third-party systems is planned, or will the project have an external API
• Is there any groundwork?
• Team size?
• Who is responsible for what? Who sets tasks, who accepts, who has veto rights.
• Are there any plans for development and what are they?
• Who is the customer?
• Is there a budget for buying ready-made solutions?
• What methodology do they plan to work on?
• Are there any analogues?
  

As you can see, the list is not that big. True, for some unknown reason, very few people ask such questions before they begin to do anything. You ask why I understand the type of project? Always have to do so that the project lived forever ?! By and large, you are right, but there are nuances, as in the obscene joke. These nuances are resources and terms. Do not forget that we are working for the benefit of the business and carry out the tasks. When you know the type of project, you can without a twinge of conscience something to donate to achieve the objectives.

Technology selection

In choosing the best, follow the rule: the technology should not be supernova, but also outdated, too. If the technology or framework is new, it can result in such problems as:

• Search for qualified personnel
• Prospects for development: in the early stages, the development may die or, on the contrary, if the technology is old, then the bugs will have to be treated themselves.
• The lack of ready-made solutions for new ones, and the lack of updates for old ones.
  

This list of problems is relevant not only with respect to technology, but also to third-party dependencies. All of the above can bury the project on the vine.

Before you choose something specific, think a few times. Create a notorious table of benefits with importance coefficients for the project.

This example is for a fictional project:

The name of the project functionality.	Importance factor for the project
Working with forms	3
Routing	one
Easy to write animation	0.3

As can be seen from the table, the important selection criteria are “working with forms” and “routing”. The simplicity of creating animation for this project is not significant. Next, we update the table by adding new technology columns. In our case there will be two.

The name of the project functionality.	Importance factor for the project	Technology 1	Technology 2
Working with forms	3	+	±
Routing	one	+	±
Easy to write animation	0.3	+	-

Based on the data in the table, we understand that with “Technology 2” work with forms and routing are lame, and creating animation is like calling Satan. As a result, the proportion of this technology is 2. You ask why 2? It's simple! If you put ±, then this technology implements a specific functionality, but with some kind of “crutches”, or more labor-intensive. In our comparison, the “Technology 1“ will be more profitable, with a total of 4.3. I think explanations on the formation of sums are superfluous. This table works not only with technologies, but also 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 architecture design. True, any of them has flaws, for someone critical, and for someone not. Since I am “oldfag”, I prefer the leaf and the pen or the board and the 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 a way to build an architecture. As a rule, in practice they use only three:

Descending - developers are repelled from large nodes of the system and go to smaller ones. The meaning of architecture is that the primary components are large nodes that contain smaller ones.

Ascending - developers are repelled from small parts and go to larger ones. The sense of architecture is that many small components are first created, and larger ones are already assembled from them.

Monolith - architecture indivisible into parts, often referred to as "legacy". In fact, it is a rigid structure, the change of which requires solutions without “crutches”. This is the worst option, but, like everything in our world, has the right to exist. Monolith is used to implement specific functionality and do not plan to support it further. Compared with the others, the speed of this approach is much faster. Well, just because you can close your eyes to many things.

The choice of the type 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 tight, and the number of large modules is small. Its peculiarity lies in the fact that it is possible to accurately represent the connection between specific modules. Of the minuses I can note the long development time associated with the sequence of actions.

The second method is preferred when high development speed is required and there is a lack of understanding of the high-level architecture. A special feature is the many small components that are sometimes used in various large nodes. It is worth noting that almost all development can be performed in parallel, without regard for the remaining tasks. The disadvantages of this approach will be the components that do not meet the requirements of the high-level architecture and, accordingly, they will have to be rewritten or create the possibility of customization.

As practice shows, all development methods are reduced to a spiral approach, characterized by a gradual increase in 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 get the job done more efficiently. In essence, this is a schedule with conditional deadlines for the delivery of one or another functional. Dates can be transferred, 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 deadlines, etc.

What will they thank you for later?

Any project begins with documentation, and the more of it, the better! So do not be lazy - we document everything. Yes, it will take time, but later it can save you from the wrath of the leadership, if something goes wrong, not your fault. Also, do not forget that after you on the project there will be people who will have to understand what you have created. And without documents to do it will not be easy.

findings

This article describes how to act and what to look for when starting a project. These stages are universal for the front, back, testing, or all together. I deliberately avoided specifics on technologies in order not to be misleading.

When you have the choice of which technology stack to use, the architecture, and you need to determine the time frame for the project, you can help the table below:

Type of project / features	Disposable crafts	Startup	Information Systems	Closed systems	Saas solutions	Any other projects
Number of people under 5		X	X	X	X
Number of people from 7 to 10
Number of people from 10 to 30	X
Qty more than 30	X	X
Deadline for up to 3 months		X	X	X	X
Deadline 6 to 12 months
Term more than 12 months	X
Documentation
Integration Requirements with Other Systems
The specific customer is known
Further support is planned.
Planning
Roles are clearly demarcated.
External dependencies allowed
There is live data for testing and analysis.
Safety requirements
Testing required
Required to write product documentation or instructions
Modular implementation required
Multiple development teams
Total

How to use the table, I think everyone already guessed, but just in case - exactly the same as with the previous one, with only a small addition in the form of filled cells. This means that the value cannot be used for this project. Also please note that the table may be incomplete, add rows that you deem necessary.