Мечты о новом ПО вместо работающих решений
За последние несколько лет устойчиво натыкаюсь на проблему с аналитиками, которые «пишут» требования по Вигерсу и классике:
1. Требования описывают решение как новую программу, которую надо сделать. Почему именно программу, а не комплекс из существующих и обновленных людей, оргструктуры, процессов, данных и технологий — непонятно. Кому-то пришла в голову идея, начали её «прорабатывать», получилась портянка.
2. Эти требования почти никак не учитывают бизнес-ограничения — сроки, деньги, те же людей, процессы и доступные технологии.
А ведь у ПО помимо стоимости разработки (которая пусть снижается с помощью ИИ), остаётся большая значимая работа по сопровождению. И это совсем не техсаппорт, а время достаточно дорогих людей, которым нужно разбираться с новыми ситуациями и проводить полноценные циклы доработок «по живому».
Особенно наглядно это сейчас проступило на проектах для НКО.
Так что в профессии нужен какой-то радикальный сдвиг от «требований» к разработке прагматичных решений.
Иначе переход от БТ к детальным требованиям к решению в обход концептуального проектирования этого решения и, что важно, убедительного объяснения, почему именно НОВЫЙ софт, так и будет приводить к избыточным фантазиям, уводящим в сторону.
И не только субоптимальным, но и в целом нежизнеспособным решениям.
· 26.12.2025
Соглашусь, но тогда на вход необходимо будет подать иной набор данных, нежели привычный сейчас для всех список требований. Вход уже определяет выход. Расширив вход до контекста, который данный набор БТ породил, как раз можно будет при валидации требований задать центральный вопрос - а верно ли определена "болезнь", корректно ли ее лечить именно новым софтом? Следом и вопросы, связанные с костами подтянутся - можно будет уже сравнить стоимость rnd+эксплуатации со некоей стоимостью реинжиниринга самих бизнес-процессов
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён