Публикация была переведена автоматически. Исходный язык: Русский
И почему команда только из разработчиков дешевле лишь в теории
В IT-проектах часто возникает соблазн упростить команду. Разработчики умеют писать код, проектировать архитектуру, работать с современными инструментами. С появлением LLM-моделей можно даже сформировать опросник для заказчика и собрать черновик технического задания.
Но здесь есть важный нюанс: писать код и формулировать бизнес-логику — это разные задачи.
Разработчик отвечает за «как». Аналитик — за «зачем» и «что именно»
Бизнес-задача редко звучит в технических терминах. Чаще она формулируется так:
— «Нужно, чтобы было удобнее» — «Нужно ускорить процесс» — «Нужно как у конкурентов»
Между этими формулировками и реальной системой — большой пласт уточнений.
Именно аналитик:
- переводит бизнес-язык в системные требования;
- задаёт вопросы, которые сам заказчик может не сформулировать;
- видит скрытые противоречия;
- выявляет вторичную боль за первичным запросом.
Даже при уточнённых требованиях в современных проектах неизбежно появляются изменения и дополнительные запросы. Если изначально логика не проработана глубоко, проект легко попадает в бесконечный круговорот переделок.
Каждая переделка — это дополнительная стоимость. И вот уже стоимость проекта неконтролируемо растет.
Сегодня действительно не каждый проект может позволить себе отдельного аналитика. Во многих командах эту роль совмещает проджект-менеджер. Иногда часть аналитической функции берёт на себя технический лидер.
Но полностью исключить аналитическую работу невозможно.
Потому что систему нельзя построить только на коде. Её нужно сначала правильно понять (подробнее об этом — в нашей статье о важности исследований).
Команда только из разработчиков может создать технически качественный продукт. Но без глубокой проработки задачи велик риск получить решение, которое формально работает, но фактически не решает реальную проблему.
И почему команда только из разработчиков дешевле лишь в теории
В IT-проектах часто возникает соблазн упростить команду. Разработчики умеют писать код, проектировать архитектуру, работать с современными инструментами. С появлением LLM-моделей можно даже сформировать опросник для заказчика и собрать черновик технического задания.
Но здесь есть важный нюанс: писать код и формулировать бизнес-логику — это разные задачи.
Разработчик отвечает за «как». Аналитик — за «зачем» и «что именно»
Бизнес-задача редко звучит в технических терминах. Чаще она формулируется так:
— «Нужно, чтобы было удобнее» — «Нужно ускорить процесс» — «Нужно как у конкурентов»
Между этими формулировками и реальной системой — большой пласт уточнений.
Именно аналитик:
- переводит бизнес-язык в системные требования;
- задаёт вопросы, которые сам заказчик может не сформулировать;
- видит скрытые противоречия;
- выявляет вторичную боль за первичным запросом.
Даже при уточнённых требованиях в современных проектах неизбежно появляются изменения и дополнительные запросы. Если изначально логика не проработана глубоко, проект легко попадает в бесконечный круговорот переделок.
Каждая переделка — это дополнительная стоимость. И вот уже стоимость проекта неконтролируемо растет.
Сегодня действительно не каждый проект может позволить себе отдельного аналитика. Во многих командах эту роль совмещает проджект-менеджер. Иногда часть аналитической функции берёт на себя технический лидер.
Но полностью исключить аналитическую работу невозможно.
Потому что систему нельзя построить только на коде. Её нужно сначала правильно понять (подробнее об этом — в нашей статье о важности исследований).
Команда только из разработчиков может создать технически качественный продукт. Но без глубокой проработки задачи велик риск получить решение, которое формально работает, но фактически не решает реальную проблему.
Поделиться
