Комментарии 8
Ты мне кажется очень резво перескакиваешь в 1999-й год.
Работа с требованиями всегда существовала в традиционной инженерии и системной инженерии, только ей кажется не уделялось особого внимания.
Там насколько я понимаю, была следующая цепочка запросов:
любой более-менее сложный объект невозможно сделать одной организации, нужно сотрудничество нескольких
чтобы сотрудничество получилось, надо выдать партнёрской организации задание на создание части объекта (ТЗ)
чтобы выдать задание на создание части объекта, нужно сначала спроектировать объект целиком
чтобы спроектировать правильный объект целиком, надо поставить задачу на его проектирование
и вот тут были разные школы:
а) школа духа auftragstaktik — когда постановка на проектирование идёт на уровне цели, критериев успеха и, возможно, ограничений
б) школа «детальных и иерархических требований» — пока не до конца понятно, как она появилась, но она базируется на вроде бы логичной концепции, что если мы опишем модель применения объекта целиком, то сможем выйти на его свойства. по факту это получается уже не постановка задачи на проектирование, а его первый этап — функциональное проектирование. при этом было неочевидно, что функциональное проектирование опасно делать в отрыве от конструктивных возможностей.
При этом в системной инженерии задача производства и сборки большого объекта из поставок разных организаций никуда не девалась и появилась целая иерархия уровней требований — а по сути, форматов частей заданий на поставку, например, в ISO 29148:
Business Requirements
Stakeholder Requirements
System Requirements
Software Requirements
Такой иерархический, синий по СД подход очень импонирует людям, взращенным в культуре порядка и подчинения. То, что он не очень уж однозначно и хорошо работает, было понятно конструкторам внутри машиностроения, строительства и т.д., но наружу это особо не выносилось.
-
Как человек, которому приходилось много раз переделывать свой код, могу сказать, что в такой ситуации возникает естественная гипотеза и запрос — «дайте нормальное ТЗ»! А нормальное ТЗ дать не могут, потому что код типа легко править и нет желания заниматься фазой проектирования. Кто должен проектировать в типовой связке «заказчик» + «младший разработчик»? Никто не проектирует, поэтому остаётся только договариваться о процедуре приёмки, которая в идеале основана на модели использования.
А модель использования — это серая зона проектирования между заказчиком и разработчиком. Вот и возникает обманчивое желание сделать правильные БИЗНЕС-требования, которые-де станут путеводной звездой для конструктора-непроектировщика.
А дальше есть отдельная эпопея, как понятие бизнес-требований (по сути это требования к capability организации) оказалось извращено до «идеи о функциях и свойствах софта, которые выдвигают представители бизнеса».
У меня заняло много лет дойти до понимания, что нормальное БТ — это «организация X должна формировать и отправлять клиентам коммерческое предложение», без упоминания каких-либо систем в явном виде. Может по-этому требования стали больным местом, красной тряпкой и местом споров.
Вопрос о требованиях - это вопрос о границах проекта. потому что требование "Организация Х должна формировать и отправлять клиентам коммерческое предложение" можно реализовать вообще без софта, с использованием Word и электронной почты, а можно поддержать софтом в той или иной мере. Граница - очень подвижная. Основной смысл использования моделей, с моей точки зрения, в том, что они позволяют представить потенциал софта: какие решения поддержать просто, а какие - нет. А если функционал софта закрыт описанием через требования, как черный ящик, то это уже нельзя, и сплошь и рядом возникают проколы, когда бизнес требует сложные фичи, думая что это просто и наоборот, не просит удобного, не зная, что это можно несложно сделать.
С использованием Word и электронной почты, но без софта. :) Рыбы не знают, что живут в воде.
вот смотри, получается, что у БА возникает очень большой соблазн сразу от требований вида:
- организация должна формировать и отправлять клиентам коммерческое предложение
перейти к требованиям к системе вида
- ИТ-система должна позволять сформировать коммерческое предложение для клиента
- ИТ-система должна позволять отправить коммерческое предложение клиенту
и может дополнить их количественными ограничениями
и да, в этот момент уже функции «закрыты» таким описанием, Word и Outlook отброшены по непонятной причине
я делаю вывод, что пропущено создание концепции ИТ-решения, т.е. генерация, презентация, обсуждение и выбор конкретного набора технологий для автоматизации того или иного участка деятельности
предлагаемый тобой и индустрией DDD частично заменяет концепцию ИТ-решения, но опять-таки неявно наводит команду на один конкретный вариант автоматизации по принципу «мы умеем 1С, поэтому всё будет в 1 С»
Проблема требований безусловно является больным местом разработки ПО, но один из важных шагов ее решения вы упоминаете в названии вашей статьи говоря о концепте. Прежде чем начинать работать над требованиями к новому продукту хорошо бы поработать над его концепцией, которая в первом приближении должна отвечать на вопросы: зачем этот продукт нужен, какие проблемы он решает, как он их решает, как оценивать результат решения этих проблем, какие риски связаны с его разработкой, внедрением и использованием, как минимизировать эти риски и т.д. В зависимости от специфика продукта, концепция может быть совместно разработана маркетологами, аналитиками, экспертами, разработчиками, в идеале при участии специалистов заказчика и потенциальных пользователей. Концепция должна быть компактной, наглядной, простой для понимания всеми заинтересованными лицами, и самое главное она должна способствовать формированию общего видения разрабатываемого продукта. Далее, разработанная концепция может использоваться в качестве карты, указывая где и какие требования искать, какие интерфейсы и структуры данных должны быть реализованы, какие сторонние программные средства и компоненты должны быть использованы и т.д.
Спасибо за наблюдение про разных "бизнес-аналитиков", очень точно! Название одно и то же, а хотят везде разного, в последнее время даже REST и SQL :)
В строительстве есть концепция ΒΙΜ (Building Information Model), которая полностью описывает будущий объект строительства, включая проект, материалы, работы, ресурсы, время и затраты, причем до мельчайших подробностей, буквально до дверных ручек, и разные части проекта могут быть наложены друг на друга, чтобы выявить коллизии.
Примерно такое же может быть полезно и в разработке софта, в том числе с выявлением коллизией (например, трассировкой требований). Но сапожник без сапог - упирается в инструменты моделирования, которых пригодных для работы нет пока. А какие есть - или слишком дороги, или неудобны. Вот и живут одни и те же требования одновременно в разных местах и в разных версиях, и ничего с этим не поделать. А никому это и не надо особенно.
Такие инструменты есть (из распространенных Enterprise Architect). Но при этом в таком режиме - с трассировкой требований, выявлением противоречий и т.п. - используются только в некоторых специальных областях с высоким требованием надежности, например, при проектировании бортового софта автомобилей (в современном автомобиле софт управляет не только автопарковкой, но и, например, тормозами - нет прямого привода от педали тормоза на колодки). Потому что сильно сложно и дорого.
Какие нужны требования: развитие концепта