ИИ не спасёт от плохих требований
Месяц назад смотрел доклад «Открытая сессия Podlodka AI Crew: Жизнь после SDD, как не убить качество» и понял мысль, которую теперь стараюсь доносить своей команде: нужно тратить больше времени на планирование и сбор требований, код быстро я и сам могу написать.
Я более чем уверен, у всех было такое: не хочется разбираться в требованиях, ничего уточнять, хочется сразу броситься писать код. Ну просто потому, что только после этого ты видишь результат, а пока мусолишь требования, как будто бы ничего и не меняется.
Теперь появился ИИ, и писать код стало так же легко, как листать рилсы. Но на самом деле тут проблема становится ещё острее.
Раньше на разработку уходило большинство времени, грубо говоря: - 15% — планирование - 70% — написание кода - 15% — валидация
Теперь же код пишется очень быстро, но нужно осторожно оперировать требованиями, иначе можно написать кучу кода, в которой нет никакого смысла. Теперь наша задача — правильно описывать требования, можно сказать, ставить ТЗ Кодексу или Клоду.
Теперь, распределение времени здорового человека в разработке выглядит так: - 45% — планирование - 5% — разработка - 50% — валидация
Мы должны проводить больше времени, так сказать, в режиме планирования, иначе на этапе тестирования настанет момент расплаты.
Распределение времени курильщика: - 5% — планирование - 5% — разработка - 120% — валидация
🫠 Я уже пару раз сталкивался с ситуацией, когда кто-то написал какой-то кусок кода, особо не заморачиваясь над промптом или требованиями. А я потом несколько часов переделывал или доделывал.
А вы что думаете? - 💜 — согласен - 😅 — не согласен
· 27.07
Был у нас когда-то на сопровождении процессов айтишник. Каждый разговор с ним превращался почти в баталию, и со временем нежелание общаться стало взаимным.
Я рисовала в Excel показатели и пыталась объяснить: здесь их нужно суммировать, здесь сопоставить, результат записать туда-то. А речь шла о системе для обработки огромного массива данных по региону. Он понимал задачу по-своему и нередко делал совсем не то, что было нужно. Думаю, мы оба тогда искренне считали друг друга людьми, которые не умеют объяснять очевидное.
Сейчас наблюдаю обратную крайность: человек пару минут поговорил с ИИ — и уже считает, что разобрался в новом процессе и готов его автоматизировать. Зачем усложнять, заказчик же всё равно толком не знает, чего хочет. А если его долго слушать, можно вообще никогда не дойти до продукта.
Но я и сама столкнулась с тем же самым уже по другую сторону. Закладываю требования в Cursor, а в процессе работы он постепенно их сокращает, упрощает — и на выходе получается ерунда. Когда же мы сначала разбираем процесс, отделяем детерминированные задачи от недетерминированных, фиксируем правила, ограничения и критерии проверки, работа действительно начинает летать.
Я понимаю, что для многих технарей сосредоточиться на коде, когда процесс уже разложен, а требования понятны и прозрачны, — удовольствие. И я не претендую на их территорию.
Моя роль — быть мостом между задачей, заказчиком, предметной областью и техническим стеком: услышать не только просьбу «сделайте вот так», но и понять, что на самом деле должно работать, где возникнут противоречия, что нельзя отдавать генеративной модели и как проверить результат.
Не «я тоже немного программирую», а «я помогаю команде создавать глубокий профессиональный продукт: извлекать неформализованную логику профессионального мышления, выявлять скрытые требования, замечать смену владельца рисков и учитывать юридические тонкости процедуры ещё до разработки. Это экономит силы и время на тестировании, согласовании и приёмке продукта».
Подскажите мне, пожалуйста, как бы вы назвали такую роль и какие доказательства моей ценности были бы для вас убедительны?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён