The post has been translated automatically. Original language: Russian
And why is a team of developers only cheaper in theory?
In IT projects, it is often tempting to simplify the team. Developers can write code, design architecture, and work with modern tools. With the advent of LLM models, it is even possible to create a questionnaire for the customer and collect a draft of the terms of reference.
But there is an important caveat here: writing code and formulating business logic are different tasks.
The developer is responsible for the "how". Analyst — for "why" and "what exactly"
A business task rarely sounds in technical terms. More often it is formulated as follows:
— "We need to make it more convenient" — "We need to speed up the process" — "We need to be like competitors"
There is a large layer of clarifications between these formulations and the real system .
It is the analyst:
- translates Business language in system requirements;
- sets questions that the customer himself may not formulate;
- He sees hidden contradictions;
- reveals the secondary pain behind the primary query.
Even with updated requirements , changes and additional requests inevitably appear in modern projects. If the logic is not worked out in depth initially, the project easily gets into an endless cycle of alterations.
Each rework is an additional cost. And now the cost of the project is growing uncontrollably.
Today, not every project can really afford a separate analyst. In many teams, this role is combined by a project manager. Sometimes the technical leader takes over part of the analytical function.
But it is impossible to completely exclude analytical work.
Because you can't build a system based on code alone. It must first be understood correctly (more on this in our article on the importance of research).
A team of developers alone can create a technically high-quality product. But without a thorough study of the problem, there is a high risk of getting a solution that formally works, but does not actually solve the real problem.
И почему команда только из разработчиков дешевле лишь в теории
В IT-проектах часто возникает соблазн упростить команду. Разработчики умеют писать код, проектировать архитектуру, работать с современными инструментами. С появлением LLM-моделей можно даже сформировать опросник для заказчика и собрать черновик технического задания.
Но здесь есть важный нюанс: писать код и формулировать бизнес-логику — это разные задачи.
Разработчик отвечает за «как». Аналитик — за «зачем» и «что именно»
Бизнес-задача редко звучит в технических терминах. Чаще она формулируется так:
— «Нужно, чтобы было удобнее» — «Нужно ускорить процесс» — «Нужно как у конкурентов»
Между этими формулировками и реальной системой — большой пласт уточнений.
Именно аналитик:
- переводит бизнес-язык в системные требования;
- задаёт вопросы, которые сам заказчик может не сформулировать;
- видит скрытые противоречия;
- выявляет вторичную боль за первичным запросом.
Даже при уточнённых требованиях в современных проектах неизбежно появляются изменения и дополнительные запросы. Если изначально логика не проработана глубоко, проект легко попадает в бесконечный круговорот переделок.
Каждая переделка — это дополнительная стоимость. И вот уже стоимость проекта неконтролируемо растет.
Сегодня действительно не каждый проект может позволить себе отдельного аналитика. Во многих командах эту роль совмещает проджект-менеджер. Иногда часть аналитической функции берёт на себя технический лидер.
Но полностью исключить аналитическую работу невозможно.
Потому что систему нельзя построить только на коде. Её нужно сначала правильно понять (подробнее об этом — в нашей статье о важности исследований).
Команда только из разработчиков может создать технически качественный продукт. Но без глубокой проработки задачи велик риск получить решение, которое формально работает, но фактически не решает реальную проблему.
Share
