Пост катализирован гл.6 “Как описывать системы” курса Системного мышления.
Ощущение хаоса создаётся, когда типы описания систем спутаны в одно: когда из разных ролей хочется сделать всеобъятное и всеустраивающее нечто. В итоге – онтологический дребезг, ошибки, тёплое с мягким. Кажется, сократили количество текста, а по факту свалили кухню, ванную и спальню в студию 10*15 или, того хуже, коммуналку.
Плохо всем, ни одной функции полноценно не реализовано, зато – компромисс и экономия.
При этом буквально всегда будут существовать описания для разных ролей, в одном ТЗ всегда намешаны и характеристики предметов интереса конечных пользователей, и элементы конструктивных решений и пожелания отдела маркетинга чтобы это легче продать было. А то и стоимостные требования включат.
Для себя решила: чтобы реже возникало чувство хаоса, надо стремиться делать наиболее прозрачным переход от одного типа описания к другому. Вербализовать, что сейчас описание функционала с точки зрения конечного пользователя, а сейчас – стоимость эксплуатации.
Но это более-менее соблюдается обычно в длинных официальных документах, а вот в рабочей переписке – нет. Надо тщательно следить за прозрачностью внезапных переходов от одного обсуждения/описания одного типа на другое и как они связаны. Как и в квартире: грамотное зонирование решает, но на него надо больше ресурсов (мыслетоплива/собранности).
при этом можно выделять различные сценарии работы с описаниями, например:
создаю описания
разбираюсь с созданными кем-то описаниями
обсуждаю / согласовываю описания (при желании, можно разделить на синхронный и асинхронный варианты / сценарии)
для которых могут оказаться различными лучшие практики и подпрактики (где-то - наводящие вопросы, где-то шаблоны формулировок “мне, как [роль] нужно от …”, где-то заранее заготовленные prompts и т.п.)
дальше можно заморочиться “предварительной подготовкой”
сформировать список ролей (и внешних, и внутренних), а лучше - протянуть цепочку (граф, как правило) актер - роль - предмет интереса - предпочтение - намерение - …
сформировать список понятий / терминов из отрасли / домена / сленга, принятого в компании (по-хорошему, конечно, это два разных набора понятий) для каждого из описаний (обязательных, как минимум - но лучше для всех создаваемых / прорабатываемых)
сам набор описаний выступит чек-листом (никакого ли важного описания не забыли), если его оттрассировать к списку ролей, который уже заготовили перед этим…
безусловно, это далеко не всё, что можно применить для разбирательств с хаосом - дополняйте
А ещё в ТЗ будут ограничения, наложенные на систему архитектором надсистемы.
ТЗ – это всё таки документ с определённым вьюпоинтом. Он скорее юридический, с точки зрения требований рудиментарный, потому что требований больше нет.
Поэтому, кстати, уже частенько встречаются ТЗ, которые по сути процедуру приёмки описывают, а не требования.
Ну а вас, как исполнителя, должно волновать, чтобы в ТЗ оказалось как можно больше функциональных требовпний и как можно меньше ограничений. Я после первого прохождения сисмыша ещё в 2020 году довольно успешно даже из ТЗ на ГОЗ много таких вешей повыкидывал, которые заказчик “по инерции” вставлял.
А можно попросить развернуть мысль? Я новичок здесь, но уже несколько раз слышал что “требований больше нет”, и пока это звучит странно, примерно как “смерти нет”. В моей реальности требования повсюду, и я бы хотел разобраться именно в этом аспекте: если будет возможность можно своими словами, или ссылкой на статью?
Тема предельно подробно в системной инженерии раскрывается.
Требований нет, как утверждений в деонтической модальности. Должен, обязан и т.д. Потому что сейчас должен одно, а потом испытали и должен другое. Уточняются на каждой итерации, с открытием новых обстоятельств. А записываются теперь в доксической модальности: Мне кажется, что должно быть…
