?

Log in

No account? Create an account
entries friends calendar profile Previous Previous Next Next
Requirements Engineering In The Real World - vit_r
vit_r
vit_r
Requirements Engineering In The Real World
Если смотреть глобально, ситуация более чем хреновая.

По теории, где-то в вышине, на уровне облаков, между всевидящими богами и мудрецами в высокой белой башне обитают почти всевидящие и более чем мудрые люди, которые пишут requirements specification.

Все стандартные процессы во всех руководствах по менеджменту начинаются с того, что вороне где-то бог послал кусочек техзадания, и она уже взгромоздилась на ели с ним во рту, и единственная задача - приобретённое не уронить.

Кое-где ради моды вписаны requirements engineer и requirements engineering. Но там рассказано только с того момента, когда надо брать в клюв и взлетать на ветку.

Ладно, любая аналогия убога, но, если вылить воду, получится что-то подобное.

Есть совсем уж тайные знания, обладателей которых я практически в индустрии не встречаю. Собственно, кроме Volere я ничего приличного и не видел. У большинства так называемых специалистов по requirements engineering это слово вызывает только недоумение. Про остальных можно и не вспоминать.

Тут уже нормально объясняется, где требования добывать, что с ними делать, как оценивать важность, как, что и куда записывать, чтобы в этом можно было потом разобраться. Но это тоже о идеальной ситуации в идеальном мире.

В реальности техзадание пишет всяк, кто подвернётся менеджеру под руку. Короче говоря, люди свободные от полезной деятельности.

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

Что будут делать люди, которым надо сформулировать требования на то, в чём они не разбираются?

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

Люди умные или ленивые (что, собственно, одно и то же) находят что-то похожее и копируют. При этом, зачем, как и почему возник исходный текст их совершенно не заботит.

Согласно теории они должны бегать по экспертам, задавать вопросы, созывать обсуждения, проверять, насколько описание соответствует хотя бы здравому смыслу....

На практике никто этого не делает. Не столько потому, что лень, сколько из-за нежелания экспертов тратить время на подобную ерунду. Сформулировать, что нужно делать, им влом и некогда, а под нос бурчать про придумавших всякий бред идиотов и выполнять невыполнимое - это сколько угодно.

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

Нужное, естественно, не для дела, а для копирования в качестве новых требований.

К самым ярким примерам относится задание:

- Начальство приказало переходить на DOORS, так что мы скопировали требования от старой системы. Никто этим не пользовался, всё общение шло неформально, но сейчас надо сдавать проект, так что придётся исправить написанное в соответствии с готовым продуктом.

Между прочим, не какой-нибудь веб, а кондовое немецкое автомобилестроение.

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

Фактически, для существующих процессов необходима requirements archeology, то есть систематический поиск во всяком доисторическом дерьме черепков и косточек, а потом воссоздание по ним правдоподобных образов вазочек и птичек.

Иногда на самом деле приходится это делать, получая на выходе что-то полензое. Но чаще всего по законам карго-культа люди вновь и вновь возводят самолёт из соломы.

Tags: , , , , , ,

18 comments or Leave a comment
Comments
alexott From: alexott Date: August 2nd, 2013 07:15 am (UTC) (Link)
где тут кнопка +100500?
vit_r From: vit_r Date: August 2nd, 2013 02:47 pm (UTC) (Link)
Кнопочка тут ни к чему. Любые цифры имеют смысл как база для сравнения. Если бы кто пришёл и сказал "А у нас не так!", можно бы было считаться. Но у меня подозрения, что таких не найдётся.

Если, вдруг, соберусь писать книжку и если случайно напишу, можно будет проголосовать деньгами.

Edited at 2013-08-02 02:52 pm (UTC)
orleanz From: orleanz Date: August 2nd, 2013 03:34 pm (UTC) (Link)
я вот бы удовольствием почитал бы классические примеры, примеры для подражания из этой области

вот может висит где нибудь в сети документик, который составлен мастерски, как надо

но я боюсь что таких примеров нет

хотя может есть.
vit_r From: vit_r Date: August 2nd, 2013 03:51 pm (UTC) (Link)
Нет "примеров для подражания"

Смотришь презентацию о том, как люди всё замечательно, чудесно и круто сделали. Потом приходишь на место, выясняешь, что внутри, показываешь народу эту самую презентацию, про то, как у них якобы всё круто. Они читают и веселятся.

Это как с бестселлером.

Можно найти книжку про то, как не надо писать. Можно про то, как у одного один раз получилось. Можно найти общие схемы. Но, когда доходит до дела, определяет личный талант и личные знания.

Тем более, "коллективом" ещё никогда ни одного бестселлера написать не удалось. С техзаданием то же самое.
alexott From: alexott Date: August 4th, 2013 02:17 pm (UTC) (Link)
я кстати вспомнил один из проектов где я учавствовал, в котором было грамотно организовано с точки зрения требований, use cases, и т.п. Это был проект для билайна, под названием Beepay XP (http://www.cnews.ru/reviews/free/telecom2009/case/Jet/). Аналитики билайна собрали и формализовали требования, подготовили use cases, на основе которых мы уже потом делали разработку.

но к сожалению это практически единственный пример на моей памяти - обычно это "клиент что-то хочет такое (и руками водить в воздухе", а даже если клиент знает что хочет, то его требования доходят через длинную цепочку sales engineer, product managers, etc.
vit_r From: vit_r Date: August 4th, 2013 04:13 pm (UTC) (Link)
Ну да. Честно говоря, мне тоже известны единичные случаи. Но это на фоне "стандартов индустрии" почти не заметно.
norian From: norian Date: August 2nd, 2013 07:46 am (UTC) (Link)
> Собака всё понимает, но не может не только говорить

какая-то хрень детектед

а так, да, примерно и есть - за полгода жизни проекта удавалось заставить более-менее писать требования только одного джуниора, который конечно делает это в меру своих скромных возможностей - более матерые инженегры и эксперты просто топырят пальцы под разными углами и пишут код как обычно - [mizulina] [mizulina] и в продакшен
vit_r From: vit_r Date: August 2nd, 2013 02:40 pm (UTC) (Link)
какая-то хрень детектед

А вот интересно иногда поиздеваться над языком и посмотреть, что получится.

Насчёт же экспертов, тут похоже как с экономистами в начале девяностых: можно брать кого угодно и обучить, только не старых советских спецов.
kormikblog From: kormikblog Date: August 2nd, 2013 09:50 am (UTC) (Link)
Все верно. Но - все экономят и вообще, зачем "когда ща секретарша все напечатает" (реальные случаи).

Как правило, они ничего не знают, в предмете не разбираются и выражать мысли в письменной форме умеют плохо. Последнее особенно ярко видно, когда за написание спецификации берутся программисты.

Наглядный пример - жж.

я им даже писал как-то, что они совершенно зря пытаются объяснять про имена кластеров и прочую хрень, и что пусть сапоги сапожник тачает, а тексты - пишет копирайтер-пиаровец. Обиделись, как обычно - на это ж мозгов не надо.


vit_r From: vit_r Date: August 2nd, 2013 02:49 pm (UTC) (Link)
Ха. Секретарша - это ещё приемлимый вариант. Могут поручить каким-нибудь практикантам. Эти ещё и писать без ошибок не умеют.
guamoka From: guamoka Date: August 2nd, 2013 02:06 pm (UTC) (Link)
Requirements hacking.
vit_r From: vit_r Date: August 2nd, 2013 02:34 pm (UTC) (Link)
Хаккеры делают что-то работающее. Пусть даже и ломающее. Тут же во многих случаях получается просто вещь в себе.
fridental From: fridental Date: August 5th, 2013 06:58 pm (UTC) (Link)
Идеальных ТЗ не бывает, потому что невыгодно задействовать программистов, которым требуется идеальный ТЗ. По крайней мере так у нас в вебе.
vit_r From: vit_r Date: August 5th, 2013 07:02 pm (UTC) (Link)
Чтобы говорить о слонах, надо для начала с ними познакомиться.

Техзадание должно быть адекватным. Чего бывает чрезвычайно редко не только в вебе.
unregistered From: unregistered Date: August 16th, 2013 06:41 am (UTC) (Link)
Все описанное относится к настоящему времени в Германии?

В России, "Требования" пишут специалисты, как правило один человек, носитель знаний предметной области. Это лицо со стороны Исполнителя. Как правило этого достаточно для разработки.
vit_r From: vit_r Date: August 16th, 2013 06:43 am (UTC) (Link)
Это относится к настоящему времени в Германии, России, Штатах и много чего ещё. "Достаточно для разработки" ещё не значит, что выполненный по требованиям продукт будет правильным.
theaspect From: theaspect Date: January 13th, 2014 09:52 am (UTC) (Link)

Вопрос

А можешь посоветовать литературу по RE?
vit_r From: vit_r Date: January 13th, 2014 10:25 am (UTC) (Link)

Re: Вопрос

Для общего развития: "Exploring Requirements" by Donald C. Gause and Gerald M. Weinberg

Для применения на практике: "Mastering the Requirements Process" by Suzanne and James Robertson

Остальное нужно читать осторожно, потому что большая часть литературы по теме представляет из себя банальности вперемежку с откровенным бредом.
18 comments or Leave a comment