What are your stages of product development?

Question

Project management

Suppose you have an idea, but what to do with it?
How to move from a general description to a system one (user scripts, main objects, etc.)? Are there some already proven steps to form a product with a clear description of the properties, characteristics and requirements from the idea?
Something like:
1. General description of the project (what tasks does it solve?)
2. Target audience (who will use it and why?)
3.… (and then what? how?)
Thanks for any advice or links to smart articles!

Answer 1

There is a 50-page article by Yura Himonin about how to develop requirements for software products: pmi.ru/articles/articles/1211/
There are other useful books: school.system-analysis.ru/books/

Answer 2

If you are not a government agency and not a large bureaucratic structure, then the main thing is to write in normal human language. Burn out all bureaucracy with a red-hot iron. There should be no phrases like "our system should carry out interaction functions ...".
You create a product description in order to explain the concept to another person. Explain in human terms.
Very many (90%) underestimate the importance of this and write product documents as if they were transcripts of the CPSU congress.
Plus, there is such a thing as design levels. Do not delve into the details at a high level of description. Put it all in separate documents, otherwise you will get mess.
Accordingly, the TOR will include everything that you consider necessary to explain about the product. Schemes, scenarios, calculations, etc. But it is necessarily structured by levels. You can mix different content on the same level (scenario + formal description, for example), but in no case should you mix different levels.

Answer 3

I didn’t read my colleagues above, I’ll just finish my points, I’m still finalizing those myself. process, but many of them follow one from the other and are meaningfully interconnected through my personal experience and knowledge of the IT device, the web, prog and all that
(the doc describes the technical process for developing a small-scale web application, although mb is suitable for an average)
Preparing for project work
====================================
1. Requirements
1.1. Problem statement (assessment and setting of resource limits and development timeframes)
1.2. Main functions (general description of tasks performed)
1.3. Architecture requirements
1.3.1. Project support plans
1.3.2. Technologies used (based on support plans)
1.3.3. Architectural solution (based on the use of technology, modular, monolithic, layers, etc.)
1.3.3.1. Interfacing with third-party technologies/software
1.4. Description of the target audience (end users, their skills, perception, UX)
1.5. Deadlines (for development, for interface, for testing, for deployment)
2. Terms of Reference (based on requirements and design layout)
2.1. Platform (software bundles, with versions and configurations)
2.2. Project structure (flowchart with sections and subsections FE and BE)
2.3. Business objects (their structure/properties, actions on them, and their behavior)
2.4. Business processes (algorithm of linear processes based on business objects)
2.5. Security policy
2.5.1. Access lists (description of permissions for roles / user groups)
2.5.2. Security measures (library, algorithms, access recovery order, ...)
2.6. Data storage principle
2.6.1. File storage device (formats, storage method)
2.7. Interface layout (basic layout + detailed drafts of all pages)
2.8. Interface behavior
2.9. Design layout (guides, norms, rules, features of a single style)
2.9.1. Palettes (palettes of sections and types of site pages, for printing, service)
2.9.2. Indents, dimensions, geometry, horizontal rhythm
2.9.3. UX / features and rules of interface behavior
2.10. Project roadmap (based on previous points)
 
Architecture design and development
====================================
3. Design (based on the selected security policy, based on TK and requirements)
3.1. Application structure (detailed description; URL map, routing, actions description)
3.1.1. The structure of the web application (modules, controllers and actions)
3.1.2. Internal Route Map of URLs
3.2. The "common domain" object model (UML class diagram)
3.3. Database design (DDL diagram, SQL file, alpha version)
4. Backend
4.1. Preparation of Yii2 application (config, namespaces, controllers, actions, views)
4.1.1. Creation of blank actions (empty files, or configuration and connection of basic ones)
4.1.2. Preparing View-files (creating empty + configuring work with templates)
4.2. Writing MC (control code - calls to functions of common domain classes in actions)
4.3. Development of functions called in the UK (extension of API, library functionality)
4.4. Database development (DDL diagram, SQL file, beta version)
4.5. Implementation of debugging functionality
4.6. Generating application test data in the database View Sample Section
4.7. Description of the key aspects of the code (to simplify the support of the project)
5. Interface
5.1. Basic layout (composition of blocks, based on design layout, grid system selection)
5.2. Interactivity scenarios and UI behavior (description of the interactive part)
5.3. Setting up components and content (setting yii\Asset's, loading UI images)
5.4. Connecting new Jade templates
5.5. Prototype. Basic Jade layout (permissible: approximate according to the layout)
5.6. Javascript/CSS interactivity
5.7. Cosmetics UI (pixel-perfect layout in compliance with all design requirements)
Completion of development. Deployment.
====================================
6. Deployment
6.1. Prelaunch debugging (load testing, security, ..)
6.2. Comprehensive revision of all parts of the application
I have so far completed the first third and a number of points from the UI, the entire part of the design and arch. The database and the application framework (which means that all this can still be changed, rearranged, deleted and added more than once or three more .., be careful!), because I started writing technical specifications (to your bewilderment) somewhere for medium development, realizing that it would be very useful here now and, especially, later.
.. +, among other things, these docks (almost every item on the list is a separate document, file, diagram, or a complete object / set of something useful for projects) helped me better understand the mechanics of software production, the most magical thing that allows code fulfill wishes, i.e. a full-fledged, competent and beautiful implementation of applied tasks (what software is written for, but does not always perform its tasks competently, normally and generally adequately .. and whether it does it at all - I think many have seen these terrible clumsy (including enterprise -oriented) solutions with which there are more problems than good, the same Ultima, by the way, has been implemented in Ulmart for many years, or has already been implemented, I don’t know, but so many years and millions of money have been drained - laughter and sin ..)

Answer 4

Target audience - necessarily at the very initial stages. Without understanding the audience of potential users, there is no point in starting a project at all. And here it is important to understand that definitions like “all Runet users”, or all residents of the city N, or all smartphone users – all this does not work. We need specifics, we need a generalized portrait of a potential user (in principle, there can be several categories of users, and each has its own portrait). Only then will it be clear who the product is being developed for, how to package it, how to promote it, etc.

Answer 5

Which product - custom or for the open market?
For custom:
Study of the interests of stakeholders
Studying the device of automated activity
Analysis of the problem situation of stakeholders
Setting goals for creating a system
Development of business requirements
Creation of a system concept
Development of a feasibility study
Development of technical specifications
Development and testing of a model of user interaction with the system
Development of a strategy and testing methodology
Development of architectural solutions
Prototyping of architecturally significant scenarios
Development and testing of individual scenarios
Regular integration testing and testing of external quality attributes of the system
Documenting the developed scenarios
Deploying and demonstrating scenarios
Training how to work with the system
Collecting feedback from users

Answer 6

There is a standard for developing requirements for systems, it has typical requirements document structures and a description of the process: www.computer.org/portal/documents/82129/160549/IEEE+29148-2011.pdf

Answer 7

- Write the concept first. It is written as they taught at the institute to write theses - goals, objectives, relevance (+ market and competitor research), initial sketches and technical specifications.
“Then, if we need a team, we turn to people, showing this concept.
“Then development begins. A lot depends on the project here. Along the way, a system for recording errors, future features and a log of work performed is introduced.
- Then comes the stage of internal testing.
- Based on the results of testing, errors are corrected or the project is rebuilt.
- Internal testing again.
- Again we correct errors and throw the project for testing to the focus group.
- We correct errors again and check.
- Release and celebrate.

Answer 8

If you approach from the side of the reader (sorry, I read a lot of this). I would recommend making a thesis description of what is important in the product and its main features so that it fits on one page. On the net you can find dozens of items for the description (which can be read above). But the main thing is the first page to interest a person.
All other items depend on the audience of the document. For example, if you are selling a product, then advertising a purchase, if you are looking for an investor, then an explanation of monetization, if this is a diploma, then a description of the graduation menu ... (of course, I exaggerate a lot)
Do not try to cram a lot of points. Instead, write in thesis what you want to prove to readers - and prove it.
God forbid you use GOST standards to describe the minceeper (although the points there are very well thought out)

Answer 9

1. Description of the purpose of the product
2. Implementation technologies (hardware, OS, PL, frameworks, libraries, etc.)
3. List of product roles and their purpose
.... etc. d.
(click on image)