День 1810. #Оффтоп
Самая Сложная Часть Создания ПО — не Кодирование, а ТЗ. Окончание
Начало

ИИ не может создавать ПО, только код
Создание и поддержка ПО имеет гораздо больше общего с вождением автомобиля, чем с игрой в шахматы. Здесь больше переменных, и правила основаны на суждениях. Когда вы создаёте ПО, у вас может быть желаемый результат, но маловероятно, что он будет таким же строго рассчитанным, как в шахматах. ПО редко создаётся раз и навсегда. Добавляются функции и исправляются ошибки — это постоянная эволюция.

В разработке есть инструмент, позволяющий приблизить наши проекты к строго контролируемому механизму правил шахмат: технические задания. В лучшем случае ТЗ описывает ожидаемое поведение пользователей и ход выполнения программы. Чтобы купить товар, пользователь нажимает эту кнопку, создаёт эту структуру данных, запускает этот сервис. Однако чаще нам вручают списки пожеланий функций, макеты на салфетке и нечёткие документы, и говорят, чтобы мы из этого сделали что-то рабочее. Хуже того, требования меняются или игнорируются.

Недавно меня попросили помочь команде создать опросник для помощи людям по вопросам здоровья. Приложение должно было работать в регионах без надёжного интернета, поэтому решено было проводить опросы через SMS. Как только я начал слушать описание требований, я понял, что это будет проблемой. Одно дело, когда компания спрашивает вас по шкале от 1 до 10, насколько вероятно, что вы снова воспользуетесь их сервисом. Совсем другое дело — создать многоэтапный опрос с вопросами с несколькими вариантами ответов о симптомах. Я не отказался, но упомянул все возможные точки сбоя в этом процессе и хотел, чтобы команда чётко определила, как мы будем обрабатывать поступающие ответы на все вопросы. Номера вариантов ответа через запятую? Что если число в ответе не соответствует ни одному из вариантов?

После всех этих вопросов команда пришла к выводу: лучше не делать это приложение. Как ни странно, я бы сказал, что это успешный результат работы. Было бы более расточительно продолжать работу без чёткого разрешения всех потенциальных ошибок. Сможет ли ИИ так же разубедить клиентов создавать приложение? И будет ли вообще задавать наводящие вопросы, предупреждая обо всех возможных проблемах?

Чтобы создать функционирующее ПО с помощью ИИ, необходимо знать, чего вы хотите, и уметь ясно и точно это определить. Бывают случаи, когда я пишу ПО только для себя и не осознаю некоторых трудностей и проблем, пока фактически не начну писать код.

За последнее десятилетие индустрия программного обеспечения перешла от каскадной методологии (Waterfall) к гибкой (Agile). Waterfall точно определяет, что вы хотите, ещё до написания кода, а Agile обеспечивает достаточную гибкость, чтобы вы могли вносить изменения по ходу.

Много проектов, использующих Waterfall, потерпели неудачу, потому что люди думали, что знают, чего хотят, и могут точно описать это, но были разочарованы в конечном продукте.

Возможно, ИИ лучше подойдёт для переписывания уже имеющегося ПО, под новое оборудование или новые версии языков и фреймворков. По-прежнему существует гигантское количество ПО, написанного на устаревшем языке и всё меньше людей этот язык изучающих. Если вы точно знаете, чего хотите, возможно, вы сможете заставить ИИ производить ПО быстрее и дешевле, чем команда программистов-людей. Я верю, что ИИ сможет сделать уже созданное ПО быстрее, чем программисты-люди, но это потому, что кто-то по ходу разработки понял, что это ПО должно делать.

ИИ может неплохо справляться с созданием ПО по модели Waterfall. Проблема в этой модели - в людях. Не там, где подписанные ТЗ передаются команде программистов для написания кода, а во всём том, что было до этого. ИИ может делать некоторые необычные вещи, но он не может читать ваши мысли или подсказывать, чего вам следует хотеть.

Источник: https://stackoverflow.blog/2023/12/29/the-hardest-part-of-building-software-is-not-coding-its-requirements/
Автор оригинала: Jared Toporek (консультант в разработке ПО, создатель приложения Keenforms).