Designing IT product development processes
Introductory
Before you is the first part of a three-part general work, the introductory part of a series of articles on designing IT product development processes.
This introductory article is of a philosophical nature, a certain way of looking at things, at what way it makes sense to go in building workflows on a product. It is not a dogma, naturally it is not a law. It is food for thought for product managers and heads of product development departments, as well as heads of departments that indirectly influence the product. For all those who have a beginner's level, the article leaves explanatory definitions for the terms used. Perhaps someone will find it meaningful and be able to add to this view with their own experience and circumstances of the IT product using this approach, which will ultimately help the product solve its organizational and production problems.
The beginning of beginnings
At the initial stages of formation of software of the period of the 90s, 2000s, the approach to program design was conditional, to a greater extent determined by the developers themselves. With the growth of competition and quality of products on the market, to create products based on personal interpretation of the developer's understanding is at least incorrect. The modern approach to product development requires a comprehensive design of development processes as some form of overall product design and processes of work on this product such an engineering system of interactions, which includes:
- interface design;
- marketing ideas and solutions;
- business-user interaction;
- creating neat code broken down by business process segments and contexts for easier management and refactoring in the future.
Refactoring
However, not all companies have yet gained an understanding of such a systematic approach.
Fighting the system is already a system
The classic approach in product development, which originated in the late 20th century, has today reinforced the image of a kind of system that runs on a flow, which in turn is difficult to track, make changes or integrate tools that will help to at least stabilize the processes in product and team management, reducing the business costs of the IT product. In the long run, this approach looks more unstable, labor-intensive and economically unprofitable, because in the long run, more resources are spent on IT product rework, endless search for the causes of errors that were made at the stage of designing common workflows, and the same endless struggle with the consequence in the form of pouring budgets and time into patching production holes. In our opinion, one of the reasons is the inability in principle, or unwillingness of business (product owner) for some personal reasons, attitudes, thinking stereotypes or simply fear, to build organizational processes and build internal relations between departments of IT-product in a more systematic way, as a kind of common organism that functions for the sake of achieving a common goal.
In this paper we propose to consider an alternative to such an outdated and simply destructive (in our opinion) model related to the production of IT products. This alternative implies the initial design of processes in a nascent product that has received funding or the gradual integration of “order” into the already functioning processes of working products on the market. Integrating “order” into already functioning processes may be painful due to the scale and circumstances of the internal mess, however, it is at least a way to correct mistakes and build a systematization of the product in management, both between teams, within teams, and within the source code of the product.
In our understanding, the basis of a systematic approach to the production processes of work on IT-product is such an alignment of production processes, in which all participants of the process of work on the product, it is important to accept the fact that it is collective cohesion in achieving a common goal for the development of the product, will help to achieve higher and better results, in contrast to the individual game of individual teams working “on the stream” in their own sandboxes, in isolation from the general course and policy of the IT-product. Of course, this issue should be solved by the product managers, such working conditions and processes should be created, in which such tug-of-war will be inadmissible, because such “tug-of-war”, through misunderstandings and conflicts, will give birth to internal discord and misunderstanding, waste of time and finances. Therefore, it is necessary to build a process of symbiosis between business, design and development, with the help of internal “languages of communication” regarding each of the directions, where design and development understand and take into account the interests of business, through representatives of the business side (marketers, analysts), and also build a common language within their own development environment (design/front-end) with the help of tokens, which will be discussed below, and business, in turn, understands its target audience (users) and is able to explain and convey their key needs to the development teams.
Interface design, as a form of user interaction with the interface, is an important part of the overall process design phase. If interface design (ux/ui-design) is not taken into account, if it is neglected, then good design will be replaced by bad design from developers, who will do their own way, relying on their dry view and experience in the field, eventually making interface design, but not the one that the product needs, or designing the architecture of the product so that the introduction of any changes in the architecture or interface design, will be impossible or so costly that it is easier to start all over again. Eventually, a well-designed interface will be replaced by a poorly designed interface, because the form itself will remain - the interface will still be designed, but not by ux/ui-designer, which is unacceptable in the current conditions of competition of products on the market. Therefore, the initial design of production processes and product is of great importance, because developers alone hardly have the experience and time to study customer needs, business goals and quality interface design.
In our understanding, the basis of a systematic approach to the production processes of work on IT-product is such an alignment of production processes, in which all participants of the process of work on the product, it is important to accept the fact that it is collective cohesion in achieving a common goal for the development of the product, will help to achieve higher and better results, in contrast to the individual game of individual teams working “on the stream” in their own sandboxes, in isolation from the general course and policy of the IT-product. Of course, this issue should be solved by the product managers, such working conditions and processes should be created, in which such tug-of-war will be inadmissible, because such “tug-of-war”, through misunderstandings and conflicts, will give birth to internal discord and misunderstanding, waste of time and finances. Therefore, it is necessary to build a process of symbiosis between business, design and development, with the help of internal “languages of communication” regarding each of the directions, where design and development understand and take into account the interests of business, through representatives of the business side (marketers, analysts), and also build a common language within their own development environment (design/front-end) with the help of tokens, which will be discussed below, and business, in turn, understands its target audience (users) and is able to explain and convey their key needs to the development teams.
Interface design, as a form of user interaction with the interface, is an important part of the overall process design phase. If interface design (ux/ui-design) is not taken into account, if it is neglected, then good design will be replaced by bad design from developers, who will do their own way, relying on their dry view and experience in the field, eventually making interface design, but not the one that the product needs, or designing the architecture of the product so that the introduction of any changes in the architecture or interface design, will be impossible or so costly that it is easier to start all over again. Eventually, a well-designed interface will be replaced by a poorly designed interface, because the form itself will remain - the interface will still be designed, but not by ux/ui-designer, which is unacceptable in the current conditions of competition of products on the market. Therefore, the initial design of production processes and product is of great importance, because developers alone hardly have the experience and time to study customer needs, business goals and quality interface design.
