Requirements Engineering In The Real World
Aug. 2nd, 2013 08:46 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rЕсли смотреть глобально, ситуация более чем хреновая.
По теории, где-то в вышине, на уровне облаков, между всевидящими богами и мудрецами в высокой белой башне обитают почти всевидящие и более чем мудрые люди, которые пишут requirements specification.
Все стандартные процессы во всех руководствах по менеджменту начинаются с того, что вороне где-то бог послал кусочек техзадания, и она уже взгромоздилась на ели с ним во рту, и единственная задача - приобретённое не уронить.
Кое-где ради моды вписаны requirements engineer и requirements engineering. Но там рассказано только с того момента, когда надо брать в клюв и взлетать на ветку.
Ладно, любая аналогия убога, но, если вылить воду, получится что-то подобное.
Есть совсем уж тайные знания, обладателей которых я практически в индустрии не встречаю. Собственно, кроме Volere я ничего приличного и не видел. У большинства так называемых специалистов по requirements engineering это слово вызывает только недоумение. Про остальных можно и не вспоминать.
Тут уже нормально объясняется, где требования добывать, что с ними делать, как оценивать важность, как, что и куда записывать, чтобы в этом можно было потом разобраться. Но это тоже о идеальной ситуации в идеальном мире.
В реальности техзадание пишет всяк, кто подвернётся менеджеру под руку. Короче говоря, люди свободные от полезной деятельности.
Как правило, они ничего не знают, в предмете не разбираются и выражать мысли в письменной форме умеют плохо. Последнее особенно ярко видно, когда за написание спецификации берутся программисты. Собака всё понимает, но не может не только говорить.
Что будут делать люди, которым надо сформулировать требования на то, в чём они не разбираются?
У некоторых наглость зашкаливает настолько, что они решают писать на уровне своего понимания. В результате получаются элементарные истины, слишком общие для того, чтобы быть полезными, вперемежку с невыполнимой отсебятиной и чистым незамутнённым бредом.
Люди умные или ленивые (что, собственно, одно и то же) находят что-то похожее и копируют. При этом, зачем, как и почему возник исходный текст их совершенно не заботит.
Согласно теории они должны бегать по экспертам, задавать вопросы, созывать обсуждения, проверять, насколько описание соответствует хотя бы здравому смыслу....
На практике никто этого не делает. Не столько потому, что лень, сколько из-за нежелания экспертов тратить время на подобную ерунду. Сформулировать, что нужно делать, им влом и некогда, а под нос бурчать про придумавших всякий бред идиотов и выполнять невыполнимое - это сколько угодно.
В лучшем случае эксперты кинут какой-нибудь протухший документ, где можно найти что-то отдалённо относящееся к вопросу. Естественно, гораздо проще экспертов не беспокоить, покопаться в помойках, которые по недоразумению называются архивами документов, и найти нужное.
Нужное, естественно, не для дела, а для копирования в качестве новых требований.
К самым ярким примерам относится задание:
- Начальство приказало переходить на DOORS, так что мы скопировали требования от старой системы. Никто этим не пользовался, всё общение шло неформально, но сейчас надо сдавать проект, так что придётся исправить написанное в соответствии с готовым продуктом.
Между прочим, не какой-нибудь веб, а кондовое немецкое автомобилестроение.
Порой, сравнивая разные версии, видно, что требования начинали создавать эксперты, в предмете хорошо понимавшие, и, хоть мутно и путано, но пытавшиеся что-то полезное сделать. Потом их вынимали на более неотложные и важные задачи, а тексты попадали в руки людей левых, но старательных. Те, как прилежные школьницы, переписывали всё красиво, теряя структуру, связи и кусочки смысла, после чего наполняли оставшееся водой до необходимых объёмов и уровня детализации.
Фактически, для существующих процессов необходима requirements archeology, то есть систематический поиск во всяком доисторическом дерьме черепков и косточек, а потом воссоздание по ним правдоподобных образов вазочек и птичек.
Иногда на самом деле приходится это делать, получая на выходе что-то полензое. Но чаще всего по законам карго-культа люди вновь и вновь возводят самолёт из соломы.
По теории, где-то в вышине, на уровне облаков, между всевидящими богами и мудрецами в высокой белой башне обитают почти всевидящие и более чем мудрые люди, которые пишут requirements specification.
Все стандартные процессы во всех руководствах по менеджменту начинаются с того, что вороне где-то бог послал кусочек техзадания, и она уже взгромоздилась на ели с ним во рту, и единственная задача - приобретённое не уронить.
Кое-где ради моды вписаны requirements engineer и requirements engineering. Но там рассказано только с того момента, когда надо брать в клюв и взлетать на ветку.
Ладно, любая аналогия убога, но, если вылить воду, получится что-то подобное.
Есть совсем уж тайные знания, обладателей которых я практически в индустрии не встречаю. Собственно, кроме Volere я ничего приличного и не видел. У большинства так называемых специалистов по requirements engineering это слово вызывает только недоумение. Про остальных можно и не вспоминать.
Тут уже нормально объясняется, где требования добывать, что с ними делать, как оценивать важность, как, что и куда записывать, чтобы в этом можно было потом разобраться. Но это тоже о идеальной ситуации в идеальном мире.
В реальности техзадание пишет всяк, кто подвернётся менеджеру под руку. Короче говоря, люди свободные от полезной деятельности.
Как правило, они ничего не знают, в предмете не разбираются и выражать мысли в письменной форме умеют плохо. Последнее особенно ярко видно, когда за написание спецификации берутся программисты. Собака всё понимает, но не может не только говорить.
Что будут делать люди, которым надо сформулировать требования на то, в чём они не разбираются?
У некоторых наглость зашкаливает настолько, что они решают писать на уровне своего понимания. В результате получаются элементарные истины, слишком общие для того, чтобы быть полезными, вперемежку с невыполнимой отсебятиной и чистым незамутнённым бредом.
Люди умные или ленивые (что, собственно, одно и то же) находят что-то похожее и копируют. При этом, зачем, как и почему возник исходный текст их совершенно не заботит.
Согласно теории они должны бегать по экспертам, задавать вопросы, созывать обсуждения, проверять, насколько описание соответствует хотя бы здравому смыслу....
На практике никто этого не делает. Не столько потому, что лень, сколько из-за нежелания экспертов тратить время на подобную ерунду. Сформулировать, что нужно делать, им влом и некогда, а под нос бурчать про придумавших всякий бред идиотов и выполнять невыполнимое - это сколько угодно.
В лучшем случае эксперты кинут какой-нибудь протухший документ, где можно найти что-то отдалённо относящееся к вопросу. Естественно, гораздо проще экспертов не беспокоить, покопаться в помойках, которые по недоразумению называются архивами документов, и найти нужное.
Нужное, естественно, не для дела, а для копирования в качестве новых требований.
К самым ярким примерам относится задание:
- Начальство приказало переходить на DOORS, так что мы скопировали требования от старой системы. Никто этим не пользовался, всё общение шло неформально, но сейчас надо сдавать проект, так что придётся исправить написанное в соответствии с готовым продуктом.
Между прочим, не какой-нибудь веб, а кондовое немецкое автомобилестроение.
Порой, сравнивая разные версии, видно, что требования начинали создавать эксперты, в предмете хорошо понимавшие, и, хоть мутно и путано, но пытавшиеся что-то полезное сделать. Потом их вынимали на более неотложные и важные задачи, а тексты попадали в руки людей левых, но старательных. Те, как прилежные школьницы, переписывали всё красиво, теряя структуру, связи и кусочки смысла, после чего наполняли оставшееся водой до необходимых объёмов и уровня детализации.
Фактически, для существующих процессов необходима requirements archeology, то есть систематический поиск во всяком доисторическом дерьме черепков и косточек, а потом воссоздание по ним правдоподобных образов вазочек и птичек.
Иногда на самом деле приходится это делать, получая на выходе что-то полензое. Но чаще всего по законам карго-культа люди вновь и вновь возводят самолёт из соломы.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-08-02 07:15 am (UTC)no subject
Date: 2013-08-02 02:47 pm (UTC)Если, вдруг, соберусь писать книжку и если случайно напишу, можно будет проголосовать деньгами.
no subject
Date: 2013-08-02 03:34 pm (UTC)вот может висит где нибудь в сети документик, который составлен мастерски, как надо
но я боюсь что таких примеров нет
хотя может есть.
no subject
Date: 2013-08-02 03:51 pm (UTC)Смотришь презентацию о том, как люди всё замечательно, чудесно и круто сделали. Потом приходишь на место, выясняешь, что внутри, показываешь народу эту самую презентацию, про то, как у них якобы всё круто. Они читают и веселятся.
Это как с бестселлером.
Можно найти книжку про то, как не надо писать. Можно про то, как у одного один раз получилось. Можно найти общие схемы. Но, когда доходит до дела, определяет личный талант и личные знания.
Тем более, "коллективом" ещё никогда ни одного бестселлера написать не удалось. С техзаданием то же самое.
no subject
Date: 2013-08-04 02:17 pm (UTC)но к сожалению это практически единственный пример на моей памяти - обычно это "клиент что-то хочет такое (и руками водить в воздухе", а даже если клиент знает что хочет, то его требования доходят через длинную цепочку sales engineer, product managers, etc.
no subject
Date: 2013-08-04 04:13 pm (UTC)no subject
Date: 2013-08-02 07:46 am (UTC)какая-то хрень детектед
а так, да, примерно и есть - за полгода жизни проекта удавалось заставить более-менее писать требования только одного джуниора, который конечно делает это в меру своих скромных возможностей - более матерые инженегры и эксперты просто топырят пальцы под разными углами и пишут код как обычно - [mizulina] [mizulina] и в продакшен
no subject
Date: 2013-08-02 02:40 pm (UTC)А вот интересно иногда поиздеваться над языком и посмотреть, что получится.
Насчёт же экспертов, тут похоже как с экономистами в начале девяностых: можно брать кого угодно и обучить, только не старых советских спецов.
no subject
Date: 2013-08-02 09:50 am (UTC)Как правило, они ничего не знают, в предмете не разбираются и выражать мысли в письменной форме умеют плохо. Последнее особенно ярко видно, когда за написание спецификации берутся программисты.
Наглядный пример - жж.
я им даже писал как-то, что они совершенно зря пытаются объяснять про имена кластеров и прочую хрень, и что пусть сапоги сапожник тачает, а тексты - пишет копирайтер-пиаровец. Обиделись, как обычно - на это ж мозгов не надо.
no subject
Date: 2013-08-02 02:49 pm (UTC)no subject
Date: 2013-08-02 02:06 pm (UTC)no subject
Date: 2013-08-02 02:34 pm (UTC)no subject
Date: 2013-08-05 06:58 pm (UTC)no subject
Date: 2013-08-05 07:02 pm (UTC)Техзадание должно быть адекватным. Чего бывает чрезвычайно редко не только в вебе.
no subject
Date: 2013-08-16 06:41 am (UTC)В России, "Требования" пишут специалисты, как правило один человек, носитель знаний предметной области. Это лицо со стороны Исполнителя. Как правило этого достаточно для разработки.
no subject
Date: 2013-08-16 06:43 am (UTC)Вопрос
Date: 2014-01-13 09:52 am (UTC)Re: Вопрос
Date: 2014-01-13 10:25 am (UTC)Для применения на практике: "Mastering the Requirements Process" by Suzanne and James Robertson
Остальное нужно читать осторожно, потому что большая часть литературы по теме представляет из себя банальности вперемежку с откровенным бредом.