The post has been translated automatically. Original language: Russian
You open any feed, and there's another article "introduce AI into development." As if no one had ever tried before. AI writes code faster than June, AI automates testing, AI is now a reviewer, a team leader, and a bit of a psychotherapist for a tired backender. It's all true. But there is one point that for some reason is always ignored in these articles: the release is often late not because the code is slow to write, but because the stakeholder has been deciding for two weeks what color the button should be.
We have also implemented AI in development. But they didn't stop there. The real waste of time starts earlier, where the task still sounds like a conversation rather than a screen.
How it used to be — and why "we showed the layouts" doesn't count.
Here it is logical to object: but what, the stakeholder had never been shown anything before, was he sitting in ignorance? They showed it. But there is a caveat.
Previously, the stakeholder left the discussion with a picture in his head. His own, the one he imagined listening to the team recite his own words. He was sure that they understood him exactly as he said. This confidence lived quietly until exactly one moment — until the demo, when what was really done appeared on the screen. And then the picture in my head collided with the picture on the screen, and they didn't always match.
The designer draws the screens, and he does it well, as part of his task: he has selected the icons, maintained the guidelines, thought out the transitions, everything is beautiful. But for a designer, the process is, in fact, a pipeline: he drew the screen, moved on to the next one. Diving into business logic, figuring out why the user ended up at this particular step in the first place and what happens if he swipes in the wrong place is not his task, and demanding this from a designer is just as strange as requiring an accountant to write pitches to investors.
As a result, the stakeholder gets a set of beautiful but loosely connected screens. No scripts, no explicit transition logic. He looks at it and says, "Well, it's probably OK." Not because everything suits him, but because it's hard to tell from the pictures without captions where he actually agreed and where he just nodded out of politeness — and his own picture in his head remained untested.
We could have closed this with detailed descriptions, but then the preparation time increases again, and we return to the same problem of speed, only on the other side.
What changes AI at this point?
AI is not strong here in the artistic part — it does not replace the designer's contemplation and his sense of style. The power lies elsewhere: he quickly immerses himself in the essence of the task and keeps in mind the connections between all the elements at once, without being distracted by which side to turn the icon.
Our process works like this:
- Discussing the task with the stakeholder. The format is a live discussion, not a questionnaire. The stakeholder sets the task based on their needs, and we record and transcribe it in its entirety.
- Extraction and detailing. The AI extracts tasks and functions from the transcript, decomposes them into specific goals and scenarios — without losing the context of the conversation.
- Confirmation. The stakeholder sees not an abstract squeeze, but an accurate statement — and confirms that he was heard correctly.
- The assembly is in the general plan. The confirmed information is integrated into the overall roadmap.
- Terms of reference for developers. The output is not just layouts, but a complete package: screens for the design system, links between them, a complete user flow, flowcharts of business processes and a technical description with a division of responsibility between the front—end and backend.
In practice, it looks like this. We give a tool like Claude Design our design system and a detailed script from the transcript. The output is not individual images, but a linked user flow: the screens are arranged in the correct order, the transitions between them are drawn as a diagram, and each step has a text description of what is happening here and why the user ended up here.
This is not the final design or a replacement for the designer. This is a working draft, with which you can already go to the stakeholder for confirmation and then transfer it to development — rather than drawing screens separately, describing logic separately, and putting everything into a demo presentation separately.
The difference with the old approach is not that the stakeholder didn't see anything before. The difference is that before he saw a set of pictures and had to figure out the logic himself — that is, in fact, he continued to live in his picture in his head. Now he gets a complete document, where the picture, description and a bunch of processes are one whole, and this is no longer his personal idea, but the result with a high probability of matching what will actually happen.
The stakeholder no longer has a picture in his head that he can take with him and then face reality. He has an understanding and a conscious decision about what exactly we are doing.
Why it really saves time
A classic story, probably familiar to every PM: on testing, it suddenly turns out that "I had something completely different in mind." And the favorite quest begins: "find out at which meeting two months ago we discussed this and who nodded at what." Reworking at this stage is expensive, both in time and on the nerves of all participants.
When a stakeholder can walk through a ready-made user flow and see the interconnected screens even before the start of development, the error is not in testing, but in discussion — where fixing it costs one phrase, not a sprint. This is the main saving.: It's not the speed of the code that's growing, but the number of "no, redo" iterations is falling.
But what about the change of requirements?
Returning to the title: a spherical stakeholder in a vacuum, of course, never changes the requirements. The real one changes, and will always change, because his circumstances, priorities, and sometimes just his mood change. This is not a bug in the process, it's a normal part of working with real people, not with perfect textbook models.
The difference is when exactly this shift takes place. Previously, the requirements were most often changed at the demo of the finished product, because it was there that the stakeholder saw the whole result for the first time and realized that he wanted something different. Now the requirements change at the discussion stage, before even one line of code is written. The change in requirements has not gone away. It just got cheaper. Not for free, but cheaper. Still, you'll need a $20 subscription for a couple of services.
The human factor still remains, and that's okay.
It is important here not to fall into the illusion that now you can take one template and stamp all projects in a row with it, like a spherical stakeholder in a vacuum — ideal, without regional specifics and without people who "still wanted it differently." In reality, each project has its own characteristics, and users have their own habits, which often depend even on location: a scenario that works great in Kazakhstan will not necessarily work one—on-one in Uzbekistan.
Therefore, the study of the human factor of a particular environment — those people who will actually work in the product — remains a mandatory stage. AI speeds up the formulation and removes the routine from formalization, but it does not eliminate the need to understand the context of a particular market and specific users.
The universality of the approach
At the same time, the scheme itself: discussion → transcript → detail → confirmation → terms of reference — is not tied to a specific type of product.
It works equally on a mobile application, a web service, and an internal corporate system that will be opened by three people and one bot tester. The subject area is changing, but the logic of the process is not changing.
The checklist: what to check before implementation
- Do you record and transcribe discussions with stakeholders, or are decisions recorded only "from memory"?
- Do you have a single format in which the task turns from a conversation into specific scenarios, rather than remaining in the form of scattered notes?
- Does the stakeholder confirm the statement before the task goes into the plan, or does the confirmation take place after the fact, at a demonstration?
- Are the screens that you show to the stakeholder connected by a single user flow, or is it a set of separate images without explicit transition logic?
- Does the stakeholder see the likely result before the start of development, or does he learn it only on demo?
- Is there a division of responsibility between the frontend and backend in the terms of reference before the start of development, or is it discussed along the way?
- Do you take into account the local characteristics of the audience (habits, region, usage context), or do you use the same scenario for all markets?
A question for you: at what stage do your requirements change most often — during the discussion, while the task is still being formulated in words, or already at the demo of the finished product?
Открываешь любую ленту — и там очередная статья «внедряйте ИИ в разработку». Как будто до этого никто не пытался. ИИ пишет код быстрее джуна, ИИ автоматизирует тестирование, ИИ теперь и ревьюер, и тимлид, и немного психотерапевт для уставшего бэкендера. Всё это правда. Но есть один момент, который в этих статьях почему-то всегда обходят стороной: релиз чаще всего опаздывает не потому, что медленно пишут код, а потому, что стейкхолдер две недели решал, какого цвета должна быть кнопка.
Мы тоже внедрили ИИ в разработку. Но этим не ограничились. Настоящая потеря времени начинается раньше — там, где задача ещё звучит как разговор, а не как экран.
Как это было раньше — и почему «мы же показывали макеты» не считается
Тут логично возразить: а что, стейкхолдеру раньше вообще ничего не показывали, он что, сидел в неведении? Показывали. Но есть нюанс.
Раньше стейкхолдер уходил с обсуждения с картинкой в голове. Своей собственной — той, которую он себе представил, слушая, как команда пересказывает его же слова. Он был уверен, что его поняли ровно так, как он сказал. Эта уверенность жила спокойно ровно до одного момента — до демо, когда на экране появлялось то, что реально сделали. И вот тут картинка в голове сталкивалась с картинкой на экране, и не всегда они совпадали.
Дизайнер отрисовывает экраны — и делает это хорошо, в рамках своей задачи: подобрал иконки, выдержал гайдлайны, продумал переходы, всё красиво. Но для дизайнера процесс — это, по сути, конвейер: отрисовал экран, перешёл к следующему. Погружаться в бизнес-логику, разбираться, почему пользователь вообще оказался именно на этом шаге и что будет, если он свайпнёт не туда — это не его задача, и требовать этого от дизайнера так же странно, как требовать от бухгалтера писать питчи инвесторам.
В итоге стейкхолдер получает набор красивых, но слабо связанных экранов. Без сценариев, без явной логики переходов. Смотрит на это и говорит: «ну, наверное, ок». Не потому что всё устраивает, а потому что по картинкам без подписей сложно понять, где он на самом деле согласился, а где просто кивнул из вежливости — и своя картинка в голове так и осталась непроверенной.
Можно было закрыть это подробными описаниями — но тогда время на подготовку снова растёт, и мы возвращаемся к той же проблеме скорости, только с другой стороны.
Что меняет ИИ в этой точке
ИИ здесь силён не в художественной части — он не заменяет насмотренность дизайнера и его чувство стиля. Сила в другом: он быстро погружается в суть задачи и держит в голове связи между всеми элементами сразу, не отвлекаясь на то, какой стороной повернуть иконку.
Процесс у нас устроен так:
- Обсуждение задачи со стейкхолдером. Формат — живая дискуссия, не анкета. Стейкхолдер ставит задачу исходя из своих потребностей, мы это записываем и транскрибируем целиком.
- Извлечение и детализация. Из транскрипта ИИ вытаскивает задачи и функции, раскладывает их в конкретные цели и сценарии — без потери контекста разговора.
- Подтверждение. Стейкхолдер видит не абстрактную выжимку, а точную постановку — и подтверждает, что его услышали правильно.
- Сборка в общий план. Подтверждённое встраивается в общую дорожную карту.
- Техническое задание для разработчиков. На выходе — не просто макеты, а целостный пакет: экраны по дизайн-системе, связки между ними, полный юзер-флоу, блок-схемы бизнес-процессов и техническое описание с разделением ответственности между фронтендом и бэкендом.
На практике это выглядит так. Мы отдаём инструменту вроде Claude Design нашу дизайн-систему и детализированный сценарий из транскрипта. На выходе — не отдельные картинки, а связанный юзер-флоу: экраны выстроены в правильном порядке, переходы между ними отрисованы как схема, и к каждому шагу идёт текстовое описание — что здесь происходит и почему пользователь оказался именно тут.
Это не финальный дизайн и не замена дизайнеру. Это рабочий черновик, с которым уже можно идти к стейкхолдеру на подтверждение и дальше передавать в разработку — а не отдельно рисовать экраны, отдельно расписывать логику и отдельно сводить всё в презентацию для демо.
Разница со старым подходом не в том, что раньше стейкхолдер ничего не видел. Разница в том, что раньше он видел набор картинок и должен был сам додумывать логику — то есть, по сути, продолжал жить в своей картинке в голове. Теперь он получает целостный документ, где картинка, описание и связка процессов — это одно целое, и это уже не его личное представление, а результат с высокой вероятностью совпадения с тем, что будет на самом деле.
У стейкхолдера больше нет картинки в голове, которую можно унести с собой и с которой потом столкнётся реальность. У него есть понимание — и осознанное решение, что именно делаем.
Почему это реально экономит время
Классическая история, знакомая, наверное, каждому ПМу: на тестировании внезапно выясняется, что «я имел в виду совсем другое». И начинается любимый квест «найди, на каком именно созвоне два месяца назад мы это обсуждали и кто там что кивнул». Переделка на этом этапе стоит дорого — и по времени, и по нервам всех участников.
Когда стейкхолдер может пройти по готовому юзер-флоу и увидеть связанные между собой экраны ещё до старта разработки, ошибка находится не на тестировании, а на обсуждении — там, где её починка стоит одной фразы, а не спринта. Это и есть основная экономия: не скорость кода растёт, а количество итераций «нет, переделайте» падает.
А как же смена требований?
Возвращаясь к заголовку: сферический стейкхолдер в вакууме, конечно, никогда не меняет требования. Реальный — меняет, и будет менять всегда, потому что у него меняются обстоятельства, приоритеты и иногда просто настроение. Это не баг процесса, это нормальная часть работы с живыми людьми, а не с идеальными моделями из учебника.
Разница в том, когда именно происходит эта смена. Раньше требования чаще всего менялись на демо готового продукта — потому что только там стейкхолдер впервые видел результат целиком и понимал, что хотел другого. Теперь требования меняются на этапе обсуждения, до того как написана хоть одна строчка кода. Смена требований никуда не делась. Просто она стала дешевле. Не бесплатно, а дешевле. Все-таки подписка за $20 вам потребуется на пару сервисов.
Человеческий фактор всё равно остаётся — и это нормально
Здесь важно не впасть в иллюзию, что теперь можно взять один шаблон и штамповать им все проекты подряд, как сферического стейкхолдера в вакууме — идеального, без региональной специфики и без людей, которые «всё же хотели по-другому». В реальности у каждого проекта свои особенности, а у пользователей — свои привычки, которые часто зависят даже от локации: сценарий, который отлично заходит в Казахстане, не обязательно сработает один в один в Узбекистане.
Поэтому изучение человеческого фактора конкретной среды — тех людей, которые реально будут работать в продукте — остаётся обязательным этапом. ИИ ускоряет постановку и снимает рутину с формализации, но не отменяет необходимость понимать контекст конкретного рынка и конкретных пользователей.
Универсальность подхода
При этом сама схема: дискуссия → транскрипт → детализация → подтверждение → техническое задание — не завязана на конкретный тип продукта.
Она одинаково работает и на мобильном приложении, и на веб-сервисе, и на внутренней корпоративной системе, которую откроют три человека и один бот-тестировщик. Меняется предметная область — не меняется логика процесса.
Чек-лист: что проверить перед внедрением
- Записываете и транскрибируете ли вы обсуждения со стейкхолдером, или решения фиксируются только «по памяти»?
- Есть ли у вас единый формат, в котором задача превращается из разговора в конкретные сценарии — а не остаётся в виде разрозненных заметок?
- Подтверждает ли стейкхолдер постановку до того, как задача уходит в план, или подтверждение происходит постфактум, на демонстрации?
- Связаны ли экраны, которые вы показываете стейкхолдеру, единым юзер-флоу — или это набор отдельных картинок без явной логики переходов?
- Видит ли стейкхолдер вероятный результат до старта разработки — или узнаёт его только на демо?
- Есть ли в техническом задании разделение ответственности между фронтендом и бэкендом до старта разработки, или оно проговаривается по ходу?
- Учитываете ли вы локальные особенности аудитории (привычки, регион, контекст использования), или используете один и тот же сценарий для всех рынков?
Вопрос к вам: а на каком этапе у вас чаще всего меняются требования — на обсуждении, пока задача ещё формулируется словами, или уже на демо готового продукта?
Share
